ARTICLE · 1053234
我们和AI的协作方式:一次交付,三份文档|椅子正经谈 Vol.15
和 AI 协作开发，最难的是让它写出你所处系统里"对"的代码——符合业务规则、符合既有约定、并且下一个人能看懂为什么这么写。
一、怎么写需求
写需求放三块内容：
要解决的问题：谁在什么场景下用它，希望得到什么结果。
已知的约束：老系统、内部有自己的封装、不能引入新东西、数据存在多处需要保持一致等。
我不清楚的部分——这一条最关键。明确写出"以下规则我不确定，你必须先问我再动手"，比如：某些情况是否允许、多处数据要不要同时更新、失败时应该提示还是回滚。
需求末尾留一句：先输出你需要向我确认的问题清单，禁止直接产出代码。
二、第一轮让它读系统
读这个模块里同类功能的实现，系统的分层方式、命名习惯、数据访问写法、返回结果的统一约定。不要写任何代码，先列出观察到的规则，以及不确定、需要确认的地方。
这一步的价值有两个方向：
向内：它把你系统的"写法"总结出来，之后所有产出都会向这个风格靠。比自己写十条规范提示词有效得多——规范是抽象的，范例是具体的。
向外：它会把藏在既有代码里的约定翻出来，包括那些你自己都记不清的。
然后是它反问。这一轮要舍得花时间，因为问出来的问题清单，本质上就是那份没人写的文档。 它问到的典型问题：
这个对象在还没正式生效的阶段，允不允许被替换成另一种格式？
多处数据副本是否都要同步更新？如果只更新一部分，剩下的怎么处理？
存标记的字段大小写不一致，查询和更新按哪种写法？
备份文件放在哪、怎么命名、时间戳精度多少？
中途某一部分失败，是整体回滚，还是保留已完成部分并提示？
这些问题问得越具体，说明它对系统的理解越到位。如果它一个业务问题都没问，直接开始写代码，那大概率不能省事。
三、把提问答案逐条落进文档
每个回答都要成为方案里的一条。口头聊完没落到纸面的规则，等于没说——它下一轮就会被忘掉或者被"合理化"。
不确定就说不确定。明确要求它标注假设：凡是自己推断出来的、没得到确认的地方，必须在方案里单列一个"假设清单"。
四、审方案：只审对错，不审写法
它产出一份《执行方案》，逐条审，而且只审业务对错，不管怎么写：
分支是否穷尽：每种输入组合都有明确归属，没有"这种情况它没提"。
不该动的有没有被误动：哪些数据必须保持不变、哪些绝对不能同步，我会专门反向检查一遍。
异常处理是不是我想要的：失败时是提示、回滚、还是部分完成？它默认会选"继续跑并记录"，但这未必是业务要的效果。
假设清单逐条否掉或确认：这一节是返工率的决定因素。
五、验收：让 AI 自证，人来抽查
① 让它自己做对照表。
输出一张表：执行方案的每一条规则 → 对应实现在哪个方法的哪几行 → 你未实现或做了改动的地方。
② 抽查五个点。
六、出解析：验收通过之后，再让它写一遍
功能可以交付了，但我认为此时只完成了一半。最后一步：
不要修改任何代码。输出这个功能的解析文档：业务规则表、每个文件的职责、完整调用链、数据操作一览、每一条关键约定存在的原因、以及假设与已知限制。
这份文档必须人工校核一遍。AI 解释既有代码时倾向于把现有设计合理化。
七、这套流程的产出
八、这套流程不解决什么
AI 不能替你判断业务。 它会把你没交代清楚的规则填成它认为合理的样子，语气还很确定。方案那一步不能跳，跳了就是把决策权交出去。
越是老系统、内部封装多的系统，它的通用经验越容易失灵。 越要强制它"先读这个系统自己的代码"。
跨层的疑难问题，决定性的观察还是人做的。 AI 的强项是给定线索之后瞬间检索全部旧代码找先例。
解析文档也要人校核，理由见第六节。