企业官网建设流程全解析

代码转需求文档，这可能是你最不该省的那一步

做过的系统越多，我就越确认一件事：代码里什么都长，唯独不长业务逻辑的说明书。

前几天一个朋友跟我吐槽。

他们接了一个外包项目的二期。一期是另一个团队做的，代码在 Git 上，人已经散了。

二期要加三个模块。产品经理看了半天代码，写了份需求文档，洋洋洒洒二十页。

开发拿到手，开工。

两周后，测试发现：三个模块里有两个的业务逻辑和一期不一致。一个是对状态的判断反了，一个是字段校验规则变了——新代码改了旧系统的行为，但所有人都以为"需求文档是对的"。

那张需求文档上没有标注「本需求由代码反推，部分流程未经验证」。

这种事，我见过太多次了。

文档和代码，永远有一个是过时的

做过维护型项目的都知道一个尴尬的事实：

• 需求文档永远赶不上代码
• 代码永远赶不上线上跑的真实逻辑
• 线上跑的逻辑……有时候连开发自己都说不清楚

为什么？因为大部分项目的节奏是：

需求（口头）→ 开发（理解）→ 代码 → 测试 → 上线

在这个过程中，最容易被省略的环节就是文档更新。

改一个字段校验，开发觉得"这么简单改什么文档"；改一个审批流，产品觉得"流程没变啊只是加了个节点"；改一个状态机的判断条件……嗯，状态机的图可能根本就没画过。

结果就是，半年后接手的人面对一团代码，不知道哪些是有意为之，哪些是历史遗留。

不是大家不想写文档。是「从零写文档」这件事，成本太高了。

所以我把这件事反过来了

我一直想做一件事：不靠人回忆，靠代码反推需求。

不管是接手老项目、做二期开发，还是团队扩招需要沉淀业务知识——最可靠的一手资料不是某个人的记忆，而是正在线上跑的那些代码。

所以我做了一个 Skill，叫code-to-prd。

它的工作方式很简单：

1. 你告诉它一个模块名，或者它自己扫描整个项目发现模块
2. 它去读代码——读路由、读 Controller、读表单字段、读状态枚举
3. 它不写技术设计，它写业务需求文档
4. 每一条需求都标注来自哪段代码，不确定的单独列为「开放问题」
5. 自动生成 Mermaid 流程图和时序图

整个过程不需要你回忆什么。代码里有的，它写进去；代码里没有的，它不编。

真正让我觉得值回票价的地方

1. 它不是「翻译代码」，是「翻译业务」

市面上有一些工具可以把代码转成文档，但它们产出的通常是这样的：

POST /api/vacation/apply→ 提交请假申请
参数：userId, startDate, endDate, type
返回：applyId, status

这叫接口文档，不叫需求文档。

但 PRD 应该是这样的：

员工在【请休假管理】模块选择请假类型（年假/事假/病假），填写起止日期和事由后点击提交。系统校验剩余天数是否充足：充足则自动流转至直属 Leader 审批；不足则提示「该请假类型剩余可用天数为 X 天」。Leader 审批通过后同步至考勤系统及薪资核算模块。

一个是 API 说明书，一个是业务故事。前者给开发看，后者给产品、业务、测试看。

code-to-prd 的写作规范里有一条硬性规定：正文中禁止出现类名、API 路径、数据库表名、HTTP 状态码。出现了就是不合格。

这听起来很简单，但真正做到却很考验功底。因为你得把代码里的技术表达，转换成人能理解的业务叙述。

2. 它是「有据可依」的，不是凭空想象的

这是这个 Skill 最核心的设计原则。

每一条列出的需求，都必须有对应的代码依据。if条件、switch case、数据库字段、表单校验——这些是依据。推测、猜测、“我觉得应该这样”——这些不能作为依据。

不确定的地方，单独列为「开放问题」。

比如：

• 请假已审批通过后，是否允许员工自行撤销？代码中未发现撤销的入口
• 「补休」类型的有效期规则？前端仅展示剩余天数，未明确过期处理逻辑

这些开放问题直接给到产品，让产品确认。一份靠谱的需求文档，应该清楚地标出哪些是确定的、哪些是存疑的。而不是全篇用模棱两可的「可能」「大概」「应该」糊弄过去。

3. 流程图和时序图，是自动配套的

每一份 PRD 至少包含：

• 1 个 Mermaid 流程图（主业务流程）
• 1 个 Mermaid 时序图（核心交互）
• 可选状态图（复杂状态流转）

而且图的命名和描述都是业务语言，不是技术术语。

看到没？没有一个技术术语。产品经理看得懂，业务方看得懂，测试也能拿着它写用例。

什么场景下，它最值钱？

我自己的感受是，这几类项目最需要它：

接手老项目：前任团队已经散了，代码在但没人说得清业务逻辑。让 Skill 把代码反推成文档，至少有一份「不说全对，但绝不乱编」的参考资料。

二期/三期开发：新功能要在旧系统上扩展。先跑一遍 code-to-prd 看看现有模块的边界和能力，避免新功能覆盖了旧逻辑。

团队扩招：新人上手项目，最痛苦的不是学技术栈，是理解业务。一份从代码反推的 PRD，比到处找人问「这个状态是什么意思」高效得多。

需求追溯：开发过程中发现文档和实现不一致。把当前代码跑一遍，生成一份"代码中说的事实"，拿着它和产品对质。谁对谁错，一目了然。

它不是万能的

也有它做不到的事：

• 它不知道业务方真正的意图。代码只反映了实现，不反映为什么这么做。所以开放问题是必要的。
• 它不知道业务流程的「温度」。比如"这个按钮用户很少点"、“这个字段改了会被投诉”——这些得和业务方聊，从代码里读不出来。
• 如果你连代码都没有，它帮不了你。这是底线。

但话说回来，这些问题不是一个自动化工具有义务解决的。它的职责是把代码翻译成业务语言，剩下的业务决策，还是得人来做。

最后说一句

我不觉得 AI 能替代产品经理。

但我相信，AI 可以帮产品经理省掉那些**「把代码读一遍再翻译成需求文档」**的体力活。

一个人一天能读多少代码、记多少业务逻辑、画几张流程图？很有限。

但一个 Skill 可以在几分钟内跑完整个项目，然后把结果摊在你面前：这是代码里有的，这是代码里没有的，你来决定怎么做。

把机械的活交给工具，把决策的活留给人。这是我理解的 AI 跟人之间最健康的关系。

code-to-prd 是我近期做的一个 Skill，专治「代码在但文档没」的慢性病。

如果你也在维护一个永远欠着文档的项目，也许它可以帮到你。

GitHub：[(https://github.com/DingoNan/skills)]

—— 浅木·先生