为什么还是不能直接把需求丢给 AI？
"帮我增加一个订单取消功能。"
AI 很快找到了订单接口，补上状态判断，更新数据库，增加通知逻辑，甚至写好了测试。你看着一片通过的结果，觉得这次开发大概结束了。
直到产品同事问了一句："已经支付的订单，取消之后钱什么时候退？"
接着，更多问题冒出来。库存要不要释放？优惠券能不能退？订单正在出库怎么办？调用退款接口超时，用户看到什么状态？
代码已经写了不少，需求才刚刚开始变清楚。
需求文字和可交付的软件之间，存在大量需要确认的规则、约束和取舍。 AI 可以帮助发现这些问题，也需要足够的依据才能把它们处理正确。
一句话需求里，藏着很多默认理解
团队沟通经常依赖没有说出口的背景。
产品说"支持导出"，可能默认只导出当前用户有权限查看的数据。开发说"增加一个字段"，可能默认历史数据可以为空。运营说"失败后重试"，可能默认不会重复扣款、重复发券或重复发送消息。
这些默认理解来自过去的讨论、现有流程和业务经验。即使团队成员之间，也未必完全一致。
AI 接到一句需求时，需要从上下文里寻找答案。背景不足时，它可能采用一种常见做法，而且能够把这套做法实现得相当完整。
问题就在这里。实现越完整，团队越容易忽略其中尚未确认的假设。
例如，"取消订单后退回优惠券"看起来合理，但活动规则可能规定部分券不可退。这个答案需要来自业务约定，单靠代码生成无法确定。
AI 能补全方案，团队需要确认依据
开发过程中，总会遇到需求没有覆盖的地方。
字段为空时怎么展示？第三方接口失败后怎么办？同一请求执行两次会产生什么结果？
AI 往往能够提出处理方式。但一项处理方式进入代码以后，就变成了系统对外承诺的一部分。
假设退款接口超时，AI 选择立即把订单标记为"取消成功"。这个实现让流程顺利结束，却留下了一个需要解释的状态。订单取消了，钱是否已经退回？后台还会不会继续处理？
因此，审查时需要追问的不只是"代码有没有问题"，还包括：
- 哪些规则来自明确需求？
- 哪些行为沿用了现有实现？
- 哪些地方由 AI 作了假设？
- 哪些问题还需要负责人确认？
把这些内容写清楚，讨论才有具体对象。
能运行，只验证了交付的一部分
编译通过，说明代码满足了一部分语言和依赖要求。测试通过，说明它在这些测试条件下表现符合预期。
业务正确还需要另一层依据。
假设 AI 把"未支付订单可以取消"理解成"未完成订单都可以取消"，然后根据这个理解编写代码和测试。测试可以全部通过，功能仍然偏离业务要求。
代码和测试共享同一个错误假设时，它们很难互相纠正。
这也是验收标准需要提前明确的原因。至少应当知道，什么输入对应什么行为，哪些条件必须拒绝，以及失败时系统应该保留怎样的状态。
对于订单取消，可以先写出几个具体场景：
| 场景 | 需要明确的行为 |
|---|---|
| 未支付订单取消 | 订单状态如何变化，是否释放占用资源 |
| 已支付订单取消 | 是否允许，退款如何发起和跟踪 |
| 订单已经出库 | 是否拒绝，还是转入其他业务流程 |
| 重复提交取消请求 | 是否返回已有结果，如何避免重复处理 |
| 下游服务失败 | 是否重试，用户看到什么状态 |
每一行都可能改变实现方式，也会决定测试应该验证什么。
一项小需求，也会进入已有系统
需求描述通常聚焦于用户想看到的变化，代码却运行在一个已经存在的系统里。
增加一个字段，可能涉及历史数据、旧客户端和下游订阅者。增加一次状态更新，可能影响报表、定时任务和消息消费。新增一个接口，也可能需要复用已有的权限校验和审计机制。
这些影响很少完整出现在工单正文中。
AI 可以通过阅读代码、检索文档和分析调用关系发现它们。前提是它拿到了正确的项目、足够的访问范围，以及可信的资料来源。
如果只提供需求截图和几个文件，它能够看到的影响范围也就有限。团队需要结合系统实际情况，确认相关模块是否已经覆盖。
发现方向错误越晚，返工越多
AI 让实现变快，也让一个未经确认的决定更快扩散。
一个状态定义，可以进入接口、数据库、页面和测试。一个错误的字段含义，可以被写进多份对象和文档。等到集成阶段发现偏差，修改已经涉及多个地方。
因此，开发前的一些确认仍然值得保留，而且可以直接让 AI 参与。
先请它整理需求理解，列出关键流程和待确认问题。再检查现有实现，给出修改范围、接口影响和验证方式。方向明确之后，继续实施。
这个过程不必写成长篇文档。对于简单改动，几句话就足够。对于涉及支付、库存、权限或跨系统状态的需求，就需要把关键行为讲得更具体。
确认的深度，应当与改动的影响相匹配。
怎样把需求交给 AI，才能继续往前走？
一份能支持开发的任务说明，可以包含五项内容。
目标。 用户遇到了什么问题，完成后应该发生什么变化。
范围。 涉及哪些入口、角色和业务状态，本次交付到哪里。
依据。 相关代码、接口约定、业务文档和项目规范在哪里。
约束。 需要兼容哪些旧行为，哪些操作有权限或环境限制。
验收。 正常、异常和重复执行等场景分别应该得到什么结果。
仍然存在疑问时，可以要求 AI 先列出来，并区分哪些会阻止实施，哪些可以在明确假设后继续推进。
比如，按钮文案尚未定稿，通常不会妨碍先实现已经确认的后端逻辑。退款状态含义尚未明确，则可能直接影响数据模型和接口设计，需要先解决。
这样，团队可以一边澄清问题，一边推进已有依据的工作。
人需要参与到哪里？
AI 可以承担需求整理、代码检索、方案比较、实现和验证。人需要在这些产出里确认业务含义、决定取舍，并判断交付是否满足真实需要。
这个参与过程可以很具体。
开始时，确认 AI 对目标和范围的理解。实施中，处理它发现的业务歧义。交付时，检查改动、测试证据和未验证事项。
回到"增加订单取消功能"这句话，最有价值的第一次交付，可能是一份待确认的取消规则，以及现有订单流程的影响分析。
等这些规则有了答案，AI 才有明确依据去实现退款、释放库存、处理重复请求，并证明它在规定场景下做对了什么。