功能上线三个月了，产品还拿着最初的 PRD 说我有 Bug。
文档写的是「当时准备怎么做」，代码跑的是几轮调整后「现在到底怎么做」。这类争执的根源，是团队默认文档必须永远和系统保持一致——而这件事靠人工几乎做不到。
这篇聊聊我现在的做法：把文档和代码的职责拆开，再用 AI 把代码翻译成产品能看懂的视图。
一、事实是怎么从文档迁移到代码的
一个需求的生命周期里，「事实」的位置是会移动的：
关键点：不一定要等上线。只要真实实现已经存在，并开始持续修改和验证，代码就比文档更接近真实系统。
按钮显示条件、权限判断、状态流转、字段校验，这些一旦写进代码，再人工维护一份 PRD，就是在维护同一个系统的第二份副本。两份副本长期并存，不一致只是时间问题。
二、文档只保留「为什么」
我建议把文档内容分成两类：
长期保留（人写，人维护）
- 业务背景
- 用户故事
- 目标
- 决策原因（为什么选 A 不选 B）
不再人工维护（从代码生成）
- 当前功能细节
- 当前权限规则
- 当前状态流转
- 当前校验逻辑
前者变化慢、代码里也读不出来；后者变化快、代码里本来就有。分清楚之后，每次需求变化只需要判断一件事：这次变化是否改变了「为什么」？ 没有改变，就不用回头改长期文档。
三、有 AI 之后，很多需求不必先写完整文档
传统流程：
想法 → 写文档 → 评审 → 开发 → 看效果
对于局部功能和交互调整，现在可以：
想法 → AI 实现 → 实际体验 → 调整
很多问题，看文档讨论半小时，不如做出来点两分钟。不是不思考，而是没必要过早把思考固化成文档。
四、让 AI 从代码生成「是什么」
产品不需要读代码，只需要仓库的只读权限，再交给一个能读代码的 AI 工具。可以让它生成这些视图：
- 功能说明
- 状态图
- 权限矩阵
- 用户路径
- 影响面分析
下面是一个示意用的提示词写法，具体模块名换成你自己的：
只读分析当前仓库中「审批」模块的实现，不要修改任何文件。
请输出：
1. 审批单的所有状态，以及每个状态之间的流转条件（用 Mermaid stateDiagram 表示）
2. 各角色在每个状态下能执行的操作（权限矩阵表格）
3. 每条结论标注对应的源码文件和函数
如果代码里有和常见业务逻辑不一致的地方，单独列出来，不要自行推测原因。
示意输出大概是这样：
stateDiagram-v2
[*] --> 草稿
草稿 --> 待审核: 提交
待审核 --> 已通过: 审核通过
待审核 --> 已驳回: 审核驳回
已驳回 --> 草稿: 重新编辑
几点实践建议：
- 要求标注源码位置。 方便开发核对，也能让产品知道结论来自代码而不是 AI 的猜测。
- 生成物不入库为「事实」。 需要时现生成，或者在 CI 里定期生成，当作视图看，不要再人工修改它。
- 有争议时以代码为准，回到「为什么」讨论。 如果生成的行为和业务目标不符，那是一个新需求或 Bug，而不是文档没同步。
五、小结
真正该扔掉的不是文档，而是「文档必须永远保持最新」这个默认习惯。
- 产品保留「为什么」
- 代码保存「是什么」
- AI 负责翻译
文档依然存在，只是它应该是代码生成的 View，而不是另一份需要人工同步的事实。
本文由 AI图鉴自动抓取并翻译，版权归原作者所有；如需查看原文请点下方链接。