窄任务如何形成可验收增量
一句话收获：窄任务不是限制 AI 能力，而是让影响、失败和验收可定位。
这个场景在解决什么问题
这个场景讲的是：让 Coding Agent 干活时，为什么要刻意把任务切得"很窄"。目标（goal）是展示"AI 负责生成代码、人来审查差异和证据"这种分工。观察点（observation）是：同一个项目里，先执行一个窄任务，验证通过后，再决定要不要进入下一个增量。
为什么值得单独学？因为很多人怕"任务太小浪费 AI 能力"，结果一上来让 AI 大包大揽，出了错都不知道是哪一步错的。这个场景告诉你：窄任务不是贬低 AI，而是把"影响、失败、验收"这三个东西都缩小到能定位的范围。
先理清这条判断链（文字版）
这个场景的四步是一个"小步快跑"的闭环，本质是"冻结基线 → 生成修改 → 跑验证 → 证据准入"：
- 先冻结任务基线——明确这次只做一件很小的事，把范围卡死，不顺手改架构。
- 让 Coding Agent 在这个窄范围内生成修改、补测试、报告差异。
- 依次跑测试、类型检查、最小冒烟，把失败信息回喂给 AI。
- 所有检查通过、结果满足 Spec 后，这个增量才"准入"当前基线，然后再进下一增量。
这条链的核心逻辑是：每一步都小到可以定位，任何失败都能回到一个明确的位置。
逐层详解
第 1 步：冻结任务基线
原文：任务只要求新增一个可查询的只读能力，不顺手改架构。
白话：任务被压到最小——这次只加"一个能查询的只读能力"，其他一概不碰，尤其是"不顺手重构架构"。先立一个明确基线，让范围可锁死。
类比：像修车只修"左前轮胎漏气"，绝不顺手把整车底盘都拆了——问题越聚焦，出了问题越知道往哪看。
举例：订单项目里，这次任务就是"给订单列表加一个按状态筛选的只读查询"，明确不改分页、不动数据库表结构、不重构任何现有模块。范围一句话就能说清。
为什么重要：小范围使失败能够回到明确位置。也就是说，范围越小，一旦失败，你能立刻定位到是"这次改动"引起的，而不是在一片大改动里猜。
怎么验证（证据点）：
- 目标唯一：只有一个清晰目标。
- 非范围明确：明确写了"不做什么"。
- 冻结测试存在：有冻结的测试作为回归底线。
别踩的坑（边界）：任务窄不等于把实现步骤全部写死。意思是，范围窄 ≠ 命令 AI 只能按某一种固定步骤来——范围内 AI 仍然有实现自由。
落地检查：AI 仍可选择实现路径。也就是说，落地时不要因为任务窄就把 AI 绑死，实现方式让 AI 自己选，你只卡范围和验收。
第 2 步：Coding Agent 生成修改
原文：AI 修改相关文件、补测试并报告差异。
白话：Coding Agent 在这个窄范围内干活：改相关文件、补上测试、然后把差异（diff）报告出来给人看。代码的"体力活"交给 AI。
类比：像装修队按你圈好的那面墙施工，完工后把"改了哪里"的照片和清单（diff）拿给你核对，而不是直接说"弄好了"。
举例：AI 改了订单列表接口、加了状态筛选参数、补了一个针对新筛选的单测，然后输出一份 diff，人能看到具体改动了哪几行。
为什么重要：代码劳动由 AI 完成。也就是说，这步的意义在于把"敲代码"这种体力活从人身上转移到 AI，人省下精力去做审查和判断。
怎么验证（证据点）：
- diff 可查看：改动差异能明确看到。
- 新增测试：有新增的测试来覆盖新能力。
- 无范围外文件：没有动到范围之外的文件。
别踩的坑（边界）：生成完成不证明代码正确。意思是，AI 说"改完了"、diff 也生成了，不等于代码就是对的——生成 ≠ 正确。
落地检查：先审查 diff 和依赖变化。也就是说，落地时先看 diff 本身，再看有没有引入新的依赖变化，而不是急着跑。
第 3 步：运行冻结验证
原文：测试、类型检查和最小冒烟依次运行，失败信息回到 AI。
白话：AI 改完后，依次跑三类验证：测试、类型检查、最小冒烟（最小的运行验证）。如果失败，失败信息不是只给人看，而是回喂给 AI，让它知道哪错了。
类比：像质检流水线——装好的车先过灯光测试、再过刹车测试、最后上路慢跑一圈，任何一项报警，都反馈回装配线去修。
举例：加完筛选功能后，先跑 npm test（单测），再跑类型检查（TS 编译），再发一个最小冒烟请求确认接口能返回。要是单测挂了，错误信息直接喂回 AI 让它修。
为什么重要：验证器为 Coding Agent 提供外部反馈。也就是说，验证器是 AI 之外的一个"裁判"，它给出的反馈是客观的，不依赖 AI 自己说"我修好了"。
怎么验证（证据点）：
- 测试结果：单测/集成测试的输出。
- 构建结果：编译/构建是否成功。
- 运行回执：冒烟运行的实际回执。
别踩的坑（边界）：AI 自己说已修复不能替代命令结果。意思是，AI 说"我已经修好了"不算数，必须看命令真实跑出来的结果。
落地检查：失败后只修改当前原因。也就是说，落地时失败后要聚焦当前失败原因去修，不要借机扩大改动。
第 4 步：证据准入
原文：所有检查通过，运行结果满足 Spec，增量进入当前基线。
白话：前面所有检查都通过、运行结果也满足 Spec（规格说明），这个"增量"才被正式纳入当前基线——也就是被认定为"可信的、已完成的一部分"。
类比：像代码合入主干前的"门禁"——所有 CI（持续集成）检查绿灯、功能验收通过，这个改动才被 merge 进主分支成为新的基线。
举例：订单筛选功能的单测通过、类型检查通过、冒烟请求返回了正确的筛选结果，全部满足 Spec 描述，这个增量就正式进入当前基线，成为后续工作的新起点。
为什么重要：准入依赖可复验结果。也就是说，一个增量能不能"进来"，靠的是能反复验证的结果，而不是 AI 的一句承诺。
怎么验证（证据点）：
- 冻结测试通过：之前冻结的测试仍然通过。
- 业务状态正确：业务侧的状态符合预期。
- 变更记录完整：本次改动的记录齐全。
别踩的坑（边界）：一个增量通过不证明整个 Agent 已完成。意思是，一个窄任务做成了，不代表整个大目标就完成了——只是前进了一小步。
落地检查：按课程顺序继续下一机制。也就是说，落地时不要以为"一个增量过了就万事大吉"，要按课程顺序继续去补下一个机制。
落地可行性小结
本场景涉及的技术栈和落地要点：冻结测试（防止回归的固定测试集）、diff（代码差异审查）、类型检查、最小冒烟、Spec（规格说明）、基线（baseline）。
真实落地时要注意：先要有"冻结测试"这个回归底线，否则改了 A 带崩 B 都发现不了；验证要自动化（测试 + 类型检查 + 冒烟形成流水线），让失败信息自动回流给 AI；每个增量的准入标准要写进 Spec，靠可复验的结果判定。常见坑是：任务切得不够窄，导致失败无法定位；以及把"AI 说修好了"当成"真修好了"，跳过命令验证。
回顾
- 窄任务的目的不是限制 AI，而是让影响、失败、验收都可定位。
- 先冻结基线、再生成修改、再跑验证、最后证据准入，是一个小步快跑的闭环。
- 代码劳动交给 AI，人专注审查 diff 和证据。
- 验证器是 AI 之外的客观反馈源，AI 自述不算数。
- 一个增量通过不等于整个 Agent 完成，要按顺序继续补机制。