夜雨聆风·一个 AI 生成的"大 Diff"让团队多干了三天，问题出在没人拦住"一口气改完"
·别让 AI 自由发挥：团队级 AI 编程，只接受一组可验证的 task，不接受一个大 Diff
·你给 AI 一句话需求，它回你 23 个文件——怎么把"改崩"的风险关进笼子
AI Coding 最容易让团队紧张的地方，是它"出活"太快。快到什么程度？一个需求丢进去，它能一口气吐出同时改接口、改 service、改配置、改测试、改文档的一坨大 Diff。模型自信满满地说"需求完成了"，可评审人面对的是一大片看不懂的变化：不知道每处改动对应哪个需求点，也不清楚哪些测试覆盖了哪些行为。为什么团队会紧张？因为大 Diff 把"改了什么"和"为什么改"都揉进了一坨变化里，人没法一眼看出风险藏在哪。
一、一个真实到肉疼的案例：大 Diff 把团队拖进三天返工
我见过最夸张的一个例子（约举例，行业常见情况）：一个团队让 AI 实现"用户积分系统"，AI 花了约两个小时，生成一个包含 23 个文件、1200 多行代码的大 Diff。Code Review 时，整个团队花了一整天才看完，结果一查全是雷：
1.AI 自己新增了一张数据库表，却没通知 DBA，上线前没人知道 schema 变了；
2.把用户 ID 从 Long 改成了 String，直接导致线上历史数据不兼容；
3.没处理并发，会出现"超扣积分"这种要命的资损问题；
4.测试只覆盖了正常流程，异常流程一个没测；
5.顺手重构了三个不相关的类，把别的功能改出了 bug。
最后这个 Diff 被完全打回。团队又花了三天重新实现——比不用 AI 还慢。
问题不在 AI 笨，而在于你让"开发阶段变成了 Agent 自由发挥"。它一次改得越多，风险越集中，出了事越难定位。这就像让一个新手厨师一次炒十个菜，端上桌你根本分不清哪道咸了、哪道糊了。
二、核心结论：团队不能接受大 Diff，只能接受一组可验证的 task
更稳的做法，是先把计划拆成 task。每个 task 有明确"范围、允许修改路径、验证命令、失败信号、通过信号、验收标准"。开发时一次只跑一个 task，审查时只审当前 staged diff（已暂存的改动）。
一句话：Task 化开发的目标，是把大需求拆成"可执行、可验证、可审查"的小交付单元。团队真正该拒绝的，不是 AI 写代码，而是"一个不可控的大 Diff"。
三、什么样的 task 才算合格？至少要让两边同时答得上
很多计划看着拆了 task，其实只是把一句大需求拆成几句小描述。一个合格 task，必须同时让"干活的人"和"审查的人"都能回答这些问题：
·它服务哪个需求点？→ 要有 featureId、requirementRefs、acceptanceCriteria；
·它遵守哪些长期规则？→ 要有 specRefs（业务规则、工程规范）；
·允许改哪些地方？→ 要有 allowedPaths，精确到文件；
·不该改哪些地方？→ 要有 excludedPaths，防止越界；
·怎么证明新增行为有效？→ 要有 GREEN 验证命令和 expectedEvidence；
·怎么证明存量行为没坏？→ 要有 Regression 验证命令；
·失败时怎么判断要不要阻塞？→ 要有 baseline 和 failureClassification。
如果这些问题还得让 AI 临场拍脑袋，那 task 就没拆到位。
团队可以拿一张评分表给 task 打分（举例权重）：allowedPaths 15 分、GREEN 验证 15 分、Regression 验证 15 分、acceptanceCriteria 15 分、featureId/requirementRefs 10 分、specRefs 10 分、expectedEvidence 10 分、excludedPaths 5 分、依赖关系 5 分。90 分以上优秀，70-89 良好，50-69 合格，低于 50 分不合格——一个 task 至少得 50 分才敢交给 AI 跑。
四、真实拆解示范：一个"新增奖品权益类型"怎么拆成 3 个 task
假设需求是给系统加一种 VIP 会员权益类型，合格的拆法不是"实现逻辑 + 补测试"两刀，而是按功能点切成三个能独立闭环的小 task：
·TASK-001 新增权益类型枚举和映射：allowedPaths 只锁定两个 Java 文件和两个测试文件；excludedPaths 明确排除 service 和 controller；验证走 RED（先让测试失败，证明现在不支持 VIP）→ GREEN（加完枚举测试通过）→ Regression（存量类型不受影响）。
·TASK-002 实现权益类型识别和配置生成：dependsOn TASK-001，必须先有枚举才能写逻辑；同样锁定自己的 service 文件和测试，排除 controller 和 dao。
·TASK-003 完善创建接口参数校验：也依赖 TASK-001，单独审校验逻辑。
注意三个要点：每个 task "实现和验证"绑在一起，不让中间状态不可验证；每个 task 有"修改边界"，不是限制创造力，而是挡住无关改动；task 之间有明确依赖，控制平面按依赖排序，绝不让有依赖的 task 并行跑。粒度上，一个 task 的开发时间控制在 1-4 小时最舒服——太小上下文切换贵，太大难审。
五、执行链路与三方分工：别让一个 Agent 既干又审又调度
拆好 task 后，执行有一套固定链路：控制平面拿任务列表 → 按依赖和优先级排序 → 一次只分配一个 task 给 worker → worker 跑基线测试、写 RED、实现、跑 GREEN、跑 Regression、生成证据、提交 staged diff → reviewer 只审这个 diff。
关键约束有五条：worker 不推进 phase、不提交代码、不修改全局任务状态；控制平面一次只分配一个 task；reviewer 只审 staged diff 不审整仓。这些约束就一个目的——避免一个 Agent "既执行又调度又自评审"，自己给自己放水。
职责由此分清：Planner 负责拆 task、定范围和验证，不写代码；Worker 负责执行单个 task，不改计划、不提交、不推进阶段；Reviewer 负责审 staged diff 和证据，不自己改代码。三方各管一段，风险才兜得住。
六、审查看什么：把 diff 和 task contract 对齐
reviewer 不是看代码风格，而是把 diff 和 task contract 对齐，重点盯四类：
·范围审查：diff 是否只动了 allowedPaths？有没有碰 excludedPaths？有没有顺手重构无关文件？
·需求对应：每处核心改动能不能回到 featureId、requirementRefs、acceptanceCriteria？有没有实现非目标功能？
·测试与回归：新增行为有没有正向测试？边界和异常有没有覆盖？存量行为有没有回归验证？
·证据完整：verification-ledger 有没有 RED、GREEN、Regression 的完整输出？失败有没有正确分类成"新增失败"还是"历史失败"？
严重级别也先约好：critical（数据不兼容、安全漏洞，必须阻塞）、major（遗漏验收、没测试、越界修改，必须修复重审）、minor（命名、注释，可记录不阻塞）。团队真正要拦的是 critical 和 major，minor 别过度纠结，否则 AI Coding 会变成格式拉扯。但也别把 major 当 minor 放过去——遗漏验收和越界修改看着小，上线就是线上故障。
落地清单，照着打勾：
一句话需求有没有先拆成多个小 task？→ 没拆，先别让 AI 动手
每个 task 有没有 allowedPaths + excludedPaths？→ 没有，等于放它自由发挥
每个 task 实现和验证是不是绑在一起？→ 分开的，中间态不可验证
有没有 RED→GREEN→Regression 三段验证证据？→ 只有"跑测试"三个字不行
reviewer 是只审 staged diff、且不是同一个 Agent 吗？→ 自己审自己，等于没审
金句收尾：团队级 AI 编程的底线，不是"让 AI 多写点"，而是"让每一行改动都看得见、审得了、退得回"。
关注我，看懂AI Agent，带你读更多细节