一、先说一个我踩过的坑
上个月做一个会员功能，规则是”连续包月用户，取消后已付费周期内权益保留”。规则是在群里聊定的，我（iOS）看完聊天记录的理解是：到期那一刻权益失效。Android 的理解是：取消那一刻还能用到周期末。后端的理解又是另一回事：他返回的字段里压根没有”到期时间”，只有一个”是否有效”的布尔值。
联调那天三方一对，全对不上。翻聊天记录，产品原话是”取消了当然还能用到月底啊”——这句话同时支持我们三个人的三种理解。
最后后端加字段、两端改逻辑，白花了两天。这种事的根源不是谁水平差，而是沟通介质有问题：群聊、语音、口头传达，天然就是模糊的、易丢失的、无法比对的。 而规则类、逻辑类的需求，恰恰是最经不起模糊的东西。
尤其是一个需求涉及 iOS、Android、前端、后端好几个端的时候——同一条产品规则，后端是校验逻辑，前端是交互提示，客户端是本地展示加兜底，每个端的实现方式都不一样。没有一份统一的、精确的参照物，误解是必然，一致才是运气。
二、解法：规则不靠”聊”，靠一份 AI 生成的 Markdown 文档
后来我在项目里换了个流程，核心就一句话：
任何涉及规则、逻辑的需求，先让 AI 产出一份 Markdown 规则文档，各端对着文档确认，再动手写代码。
第 1 步：把”散装信息”喂给 AI
产品原话、群聊记录、旧代码里的相关逻辑，全部丢给 AI，让它输出结构化文档。关键在 prompt——这是我沉淀下来直接能抄的模板：
1 | 你是资深后端架构师。根据以下信息，输出一份【规则文档】： |
最后一条最重要：宁可让 AI 列出”待确认问题”，也不让它帮你脑补。 脑补出来的规则，就是下一个联调事故。
第 2 步：各端 Review 同一份文档
文档发到群里，各端和产品对着同一份确认。关键变化是：以前的争论是”A 的记忆 vs B 的记忆”，现在的争论是”文档第 3 条这么写对不对”——歧义在写下来的那一刻就暴露了，而不是在联调那天。
确认完一条改一条，改完版本号 +1，变更记录写在文末。
第 3 步：文档即开发依据，也即是验收标准
开发对着文档写，联调对着文档对，出问题先看文档：文档错了改文档（升版本），代码错了改代码。扯皮空间基本归零。
三、前后对比，差距有多大
| 传统沟通（群聊/口头） | AI 规则文档 | |
|---|---|---|
| 歧义暴露时机 | 联调那天 | 写下来的那一刻 |
| 规则变更 | 淹没在聊天记录里 | 版本号 + 变更记录，可追溯 |
| 各端职责 | 靠猜，靠互相问 | 文档里白纸黑字分好 |
| 新人接手 | 找人问，看缘分 | 直接读文档 |
| 喂给 AI 写代码 | 口头描述，丢三落四 | 文档直接作为 prompt 上下文 |
| 维护成本 | 低（但隐性成本极高） | 以前高，现在 AI 扛掉了大半 |
四、为什么这件事以前做不起来，现在能成？
“写文档”不是新发明。以前没人愿意写规则文档，不是不知道有用，是嫌麻烦：整理半小时起步，规则一变文档就腐化，最后大家又回到群里聊天。文档这东西，死于维护成本。
AI 改变的是成本结构：生成 30 秒，改版本一句话的事，格式比人工整，还能直接喂回给 AI 生成代码和测试用例。以前写文档是负担，现在写文档是杠杆。
而且它顺带治好了几个老毛病：信息转述衰减（所有人读同一份，没有二手消息）、测试缺依据（QA 直接拿边界情况表格转用例）、多端实现不一致（各端只看自己那栏职责）。
五、几个坑，提前说
- AI 会”一本正经地补全”。 你没说的规则它敢帮你圆。所以初稿必须逐条人工确认，尤其是数字、顺序、互斥关系这类硬逻辑。这和我上一篇说的”细心”是同一个道理——AI 的产出，人必须把关。
- 文档必须有 owner 和版本。 谁都能改等于没人负责。我们的约定：谁的需求谁维护，改动必须升版本号。
- 别贪大。 一份文档只覆盖一个规则域。”会员到期规则”是一份，”订单全部规则”没人看。
- 文档是起点不是终点。 它替代不了联调和 Code Review，只是让两者有了共同参照物。
六、写在最后
回头看，这个变化挺本质的：
以前的协作是”人对人“——规则活在聊天记录和各自的理解里；现在是”人对文档，文档对人“——规则活在一份所有人共享的、精确的、可追溯的文本里。
而 AI 的角色很有意思：它既是文档的生产者，也是文档的消费者。写代码时把规则文档喂给它，比口头描述靠谱十倍。一份 Markdown，同时成了人和 AI 的共同语言。
如果你团队也有”联调时才发现理解不一致”的老毛病，建议从下一个需求开始试一次：先出文档，再写代码。成本几乎为零，省下的扯皮时间，可能比你想象的多得多。
相关阅读：《AI 时代，比开发经验更重要的三件事》