人工智能擅长发散，但不能替你做决定

最开始用人工智能开发需求时，我的做法很简单：把需求整理成一段提示词，交给工具，然后等它写代码。

问题也很直接。没有澄清过程，人工智能按自己的理解填补空白，需求理解出现偏差，一些边界没有被看到，最后做出来的东西和预想完全不同。它不是不会写代码。恰恰相反，代码生成得很快，所以偏差也能很快扩散到多个文件和环节。

后来我开始使用开发工具自带的计划模式，先澄清，再按计划实施。时间过去太久，我已经记不清最先改善的是哪一项，也没有可以拿出来比较的效率数据。能确认的是，它比收到需求就直接开发好一些，但还不够完善。

这段经历留下的第一个判断，到现在仍然没有变：企业要把人工智能放进研发流程，第一步应当明确谁有权决定问题是什么，谁对工程结果负责。生成能力要在这条边界之后发挥作用。

一段提示词承担不了需求的重量

日常交流里的“需求”，经常只是一个起点。

“增加批量操作”，没有说明部分失败怎么处理；“支持修改”，没有说明哪些状态可以改；“做一个导出”，没有说明数据范围、权限、格式和大数据量下的行为。人听到这些话，会把团队惯例、业务背景和过往经验自动补进去。人工智能也会补，只是它补进去的内容未必属于这个项目。

简单提示词开发最危险的地方并非信息少，而是信息少得不明显。指令看上去完整，句子也没有歧义，真正缺失的是没有被说出来的决定：

• 谁可以操作，谁只能查看；
• 正常流程之外，取消、撤回和失败如何恢复；
• 空值、零值、重复提交和并发操作分别代表什么；
• 这次修改是否影响已有数据和其他使用端；
• 用户看到什么，系统实际保存什么；
• 哪些做法只是候选，哪些已经由人确认。

如果没有讨论环节，人工智能只能在三个选择中挑一个：猜测、套用常见做法，或者只实现最表面的路径。任何一个都可能产出结构整齐、能够编译、甚至通过局部测试的错误实现。

计划模式的价值就在这里。它强迫开发动作晚一点发生，让需求先变成问题、方案和步骤。可是计划模式本身也不会自动带来正确答案。一个建立在错误事实上的计划，只会把错误安排得更有条理。

页面做出来，不等于系统已经交付

全人工智能开发刚开始推广时，曾经有一种很乐观的判断：开发门槛已经被人工智能抹平，只要会描述想要什么，任何人都能开发出优秀的系统。原本不从事开发的人也开始直接参与开发操作。

一个复杂业务资料页面很快做了出来。页面看着不错，功能也摆得像模像样。直到后来有人接手，才发现大量页面字段被塞进了数据库的一个巨大 JSON 列。打开页面容易，想弄清一个字段从哪里来、如何查询、由谁约束、改动会影响什么，接手的人直接懵了。

后来留下的工程记录里，这部分数据被逐步迁移到结构化的主表和明细表。相近区域还出现过 JSON 长度截断导致字段丢失、前后端序列化约定不一致导致旧值损坏的问题。这里不能把所有后续缺陷都算在最初那个 JSON 列头上，但它们共同暴露了同一类风险：当数据只剩下一团可以存取的文本，业务含义、约束和演进边界也会一起变模糊。

参与者原本是否从事开发，并不是这个技术问题的原因。人工智能本来就应该让领域专家更直接地参与需求讨论、原型制作和交付过程。真正缺少的是交付前的数据建模和架构评审。团队把“人人可以参与开发”理解成了“任何人都可以跳过专业校验，独立交付系统”。人工智能降低了实现门槛，没有取消工程责任。

人工智能适合把讨论摊开

人工智能在需求阶段最有价值的能力是发散。

人讨论需求时容易沿着最熟悉的正常路径向前走。人工智能可以在很短时间内换几个角度继续追问：如果操作中途失败怎么办？如果两个角色同时处理怎么办？如果已有数据不符合新约束怎么办？网页端改了，移动端是不是仍依赖旧字段？这项规则应该由界面限制，还是由服务端保证？

这些问题不一定都重要，答案也不能直接采用。它们的作用是扩大讨论面，让原本藏在经验里的假设浮出来。

这里很容易走向另一个极端：既然人工智能能想到很多，就让它选一个最合理的方案。这样做只是把早期的“人工智能直接写代码”换成了“人工智能直接写设计”。错误仍然存在，只是提前进入了文档。

人工智能不知道现场真正能接受多少改造成本，也不知道某条看似陈旧的规则背后是否有合同、财务或协作原因。它能比较方案，却不能替团队承担选择的后果。

所以，需求讨论中每个参与者的职责必须分开。

这张表看起来朴素，却决定了后面所有技能、规则和自动化应该怎样设计。

“人确认过”必须能够被检查

很多流程已经有确认步骤，实际仍然会跑偏。含糊的“是否确认”没有指出人究竟批准了哪些内容。

一份很长的方案最后问一句“可以吗”，人往往只确认了大方向。人工智能却可能把整份文档都当成已批准内容。讨论轮次多了以后，早先的建议、后来否决的选项和真正的决定混在一起，连人也很难重新分辨。

有效的确认至少要把内容分成四种状态：

人工确认也不该只发生一次。需求目标、关键取舍、实施计划、高风险操作和最终验收解决的是不同问题，应当分别确认。让人每一步都重新阅读全文同样不可取，确认疲劳会把门禁变成点按钮。因此每个节点只展示本轮新增或改变的决定，同时保留能够回查的完整记录。

一个最小确认卡可以很短：

任务目标：这次要改变什么结果？
已知事实：哪些内容已经核实，来源是什么？
人工智能建议：它提出了哪些方案、边界和风险？
人工决定：最终选择什么，为什么？
明确不做：哪些建议被排除？
未决问题：还有什么会阻止实施？
开始条件：谁确认什么之后可以写代码？

这不是为了多写一份文档。它要防止一件很具体的事：人工智能在一次长对话中把“我建议”悄悄变成“我们决定”。

计划要消费决定，不能制造决定

计划模式解决了从讨论到实施的节奏，但计划的输入仍需要约束。

一份可执行计划应该只消费已经确认的目标、事实和选择。遇到未决问题时，计划可以指出影响、准备备选步骤，但不能为了让文档显得完整而自行选边。计划完成后，人检查的重点也不应是“步骤够不够详细”，而是下面几件事：

• 每个关键步骤能否追溯到一个已确认决定；
• 计划有没有悄悄扩大需求范围；
• 人工智能提出但未确认的建议是否混了进来；
• 风险操作、数据修改和兼容处理有没有单独标出；
• 验收方式能否证明目标达成，而不只是代码已经提交。

如果答案不清楚，增加更多任务、角色和自动化没有帮助。后面的执行只会更快地放大前面的模糊。

这也是为什么企业级人工智能开发不能从“无人值守”开始。自主执行位于很后面。在它之前，团队至少要能稳定回答：人工智能正在执行谁的决定？决定依据是什么？发现新问题后它会继续猜，还是停下来找人？

三种规模，不需要同一套仪式

个人项目、小团队和正式研发团队都需要人掌握决定，但保存证据的方式可以不同。

个人开发一个低风险、可快速撤销的小改动，不必建立复杂状态流。开始前用几句话写清目标、不做什么和如何验证，已经比直接生成代码可靠。只要任务涉及数据删除、权限、安全、跨系统契约或难以恢复的操作，就应把关键决定单独列出并再次确认。

小团队需要共享记录。最低限度是让需求讨论、决定、计划和验收条件拥有固定位置，避免信息只留在某个人的一段对话里。人工智能可以负责整理，人负责确认；后续实现和评审只能引用确认后的版本。

当多个团队、多个代码仓库和多个自动执行角色同时参与时，确认还需要进入系统状态。某个状态不能仅表示“文档已经生成”，而要表示对应负责人已经完成判断，并且通过条件有证据可查。人工智能可以推进允许它推进的步骤，但不能跨过需要人承担责任的边界。

复杂度应该由风险和协作规模推动。流程越重，维护成本越高；门禁太多而没有明确对象，团队很快就会学会机械点击。一个有用的规则是：先使用能阻止当前主要错误的最小约束，等新的失控信号出现，再增加下一层。

判断自己是否还停在“直接生成”阶段

可以用下面几道问题做一次检查：

1. 人工智能开始写代码前，是否能说出任务目标、明确不做的内容和验收方式？
2. 它提出的新方案，会不会未经确认就进入计划？
3. 讨论中被否决的选择，后续是否可能再次出现？
4. 计划里的关键步骤，能否找到对应的人工决定？
5. 人工智能发现事实冲突时，是停止并报告，还是选择一个看起来合理的答案继续？
6. 高风险操作是否需要与普通内容修改不同的授权？
7. 换一个人接手时，他能否看懂哪些是事实、哪些是建议、哪些已经确认？
8. 团队评审的是页面效果，还是同时检查了数据模型、系统边界和维护方式？

如果多数问题答不上来，团队缺少的还不是更多技能。先把需求讨论和人工决定变成可见、可检查的输入。

人工智能当然可以参与整个研发过程。它可以比人更耐心地枚举边界，更快地调查代码，更稳定地整理记录，也能承担大量实现和验证工作。前提是讨论中的发散不会自动变成决定，计划里的完整不会掩盖事实缺口，执行速度不会越过人的判断。

先让人工智能多想几步，再由人决定哪一步值得走。企业级全人工智能开发的第一层，就从这里开始。