代码转需求文档，这可能是你最不该省的那一步
做过的系统越多，我就越确认一件事：代码里什么都长，唯独不长业务逻辑的说明书。
前几天一个朋友跟我吐槽。
他们接了一个外包项目的二期。一期是另一个团队做的，代码在 Git 上，人已经散了。
二期要加三个模块。产品经理看了半天代码，写了份需求文档，洋洋洒洒二十页。
开发拿到手，开工。
两周后，测试发现：三个模块里有两个的业务逻辑和一期不一致。一个是对状态的判断反了，一个是字段校验规则变了------新代码改了旧系统的行为，但所有人都以为"需求文档是对的"。
那张需求文档上没有标注「本需求由代码反推，部分流程未经验证」。
这种事，我见过太多次了。
文档和代码，永远有一个是过时的
做过维护型项目的都知道一个尴尬的事实：
- 需求文档永远赶不上代码
- 代码永远赶不上线上跑的真实逻辑
- 线上跑的逻辑......有时候连开发自己都说不清楚
为什么？因为大部分项目的节奏是：
需求（口头）→ 开发（理解）→ 代码 → 测试 → 上线
在这个过程中，最容易被省略的环节就是文档更新。
改一个字段校验，开发觉得"这么简单改什么文档"；改一个审批流，产品觉得"流程没变啊只是加了个节点"；改一个状态机的判断条件......嗯，状态机的图可能根本就没画过。
结果就是，半年后接手的人面对一团代码，不知道哪些是有意为之，哪些是历史遗留。
不是大家不想写文档。是「从零写文档」这件事，成本太高了。
所以我把这件事反过来了
我一直想做一件事：不靠人回忆，靠代码反推需求。
不管是接手老项目、做二期开发，还是团队扩招需要沉淀业务知识------最可靠的一手资料不是某个人的记忆，而是正在线上跑的那些代码。
所以我做了一个 Skill，叫 code-to-prd。
它的工作方式很简单：
- 你告诉它一个模块名，或者它自己扫描整个项目发现模块
- 它去读代码------读路由、读 Controller、读表单字段、读状态枚举
- 它不写技术设计，它写业务需求文档
- 每一条需求都标注来自哪段代码，不确定的单独列为「开放问题」
- 自动生成 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 时序图（核心交互）
- 可选状态图（复杂状态流转）
而且图的命名和描述都是业务语言，不是技术术语。
#mermaid-svg-BbWoSJFF4ud0jLqe{font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;fill:#333;}@keyframes edge-animation-frame{from{stroke-dashoffset:0;}}@keyframes dash{to{stroke-dashoffset:0;}}#mermaid-svg-BbWoSJFF4ud0jLqe .edge-animation-slow{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 50s linear infinite;stroke-linecap:round;}#mermaid-svg-BbWoSJFF4ud0jLqe .edge-animation-fast{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 20s linear infinite;stroke-linecap:round;}#mermaid-svg-BbWoSJFF4ud0jLqe .error-icon{fill:#552222;}#mermaid-svg-BbWoSJFF4ud0jLqe .error-text{fill:#552222;stroke:#552222;}#mermaid-svg-BbWoSJFF4ud0jLqe .edge-thickness-normal{stroke-width:1px;}#mermaid-svg-BbWoSJFF4ud0jLqe .edge-thickness-thick{stroke-width:3.5px;}#mermaid-svg-BbWoSJFF4ud0jLqe .edge-pattern-solid{stroke-dasharray:0;}#mermaid-svg-BbWoSJFF4ud0jLqe .edge-thickness-invisible{stroke-width:0;fill:none;}#mermaid-svg-BbWoSJFF4ud0jLqe .edge-pattern-dashed{stroke-dasharray:3;}#mermaid-svg-BbWoSJFF4ud0jLqe .edge-pattern-dotted{stroke-dasharray:2;}#mermaid-svg-BbWoSJFF4ud0jLqe .marker{fill:#333333;stroke:#333333;}#mermaid-svg-BbWoSJFF4ud0jLqe .marker.cross{stroke:#333333;}#mermaid-svg-BbWoSJFF4ud0jLqe svg{font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;}#mermaid-svg-BbWoSJFF4ud0jLqe p{margin:0;}#mermaid-svg-BbWoSJFF4ud0jLqe .label{font-family:"trebuchet ms",verdana,arial,sans-serif;color:#333;}#mermaid-svg-BbWoSJFF4ud0jLqe .cluster-label text{fill:#333;}#mermaid-svg-BbWoSJFF4ud0jLqe .cluster-label span{color:#333;}#mermaid-svg-BbWoSJFF4ud0jLqe .cluster-label span p{background-color:transparent;}#mermaid-svg-BbWoSJFF4ud0jLqe .label text,#mermaid-svg-BbWoSJFF4ud0jLqe span{fill:#333;color:#333;}#mermaid-svg-BbWoSJFF4ud0jLqe .node rect,#mermaid-svg-BbWoSJFF4ud0jLqe .node circle,#mermaid-svg-BbWoSJFF4ud0jLqe .node ellipse,#mermaid-svg-BbWoSJFF4ud0jLqe .node polygon,#mermaid-svg-BbWoSJFF4ud0jLqe .node path{fill:#ECECFF;stroke:#9370DB;stroke-width:1px;}#mermaid-svg-BbWoSJFF4ud0jLqe .rough-node .label text,#mermaid-svg-BbWoSJFF4ud0jLqe .node .label text,#mermaid-svg-BbWoSJFF4ud0jLqe .image-shape .label,#mermaid-svg-BbWoSJFF4ud0jLqe .icon-shape .label{text-anchor:middle;}#mermaid-svg-BbWoSJFF4ud0jLqe .node .katex path{fill:#000;stroke:#000;stroke-width:1px;}#mermaid-svg-BbWoSJFF4ud0jLqe .rough-node .label,#mermaid-svg-BbWoSJFF4ud0jLqe .node .label,#mermaid-svg-BbWoSJFF4ud0jLqe .image-shape .label,#mermaid-svg-BbWoSJFF4ud0jLqe .icon-shape .label{text-align:center;}#mermaid-svg-BbWoSJFF4ud0jLqe .node.clickable{cursor:pointer;}#mermaid-svg-BbWoSJFF4ud0jLqe .root .anchor path{fill:#333333!important;stroke-width:0;stroke:#333333;}#mermaid-svg-BbWoSJFF4ud0jLqe .arrowheadPath{fill:#333333;}#mermaid-svg-BbWoSJFF4ud0jLqe .edgePath .path{stroke:#333333;stroke-width:2.0px;}#mermaid-svg-BbWoSJFF4ud0jLqe .flowchart-link{stroke:#333333;fill:none;}#mermaid-svg-BbWoSJFF4ud0jLqe .edgeLabel{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-BbWoSJFF4ud0jLqe .edgeLabel p{background-color:rgba(232,232,232, 0.8);}#mermaid-svg-BbWoSJFF4ud0jLqe .edgeLabel rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-BbWoSJFF4ud0jLqe .labelBkg{background-color:rgba(232, 232, 232, 0.5);}#mermaid-svg-BbWoSJFF4ud0jLqe .cluster rect{fill:#ffffde;stroke:#aaaa33;stroke-width:1px;}#mermaid-svg-BbWoSJFF4ud0jLqe .cluster text{fill:#333;}#mermaid-svg-BbWoSJFF4ud0jLqe .cluster span{color:#333;}#mermaid-svg-BbWoSJFF4ud0jLqe div.mermaidTooltip{position:absolute;text-align:center;max-width:200px;padding:2px;font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:12px;background:hsl(80, 100%, 96.2745098039%);border:1px solid #aaaa33;border-radius:2px;pointer-events:none;z-index:100;}#mermaid-svg-BbWoSJFF4ud0jLqe .flowchartTitleText{text-anchor:middle;font-size:18px;fill:#333;}#mermaid-svg-BbWoSJFF4ud0jLqe rect.text{fill:none;stroke-width:0;}#mermaid-svg-BbWoSJFF4ud0jLqe .icon-shape,#mermaid-svg-BbWoSJFF4ud0jLqe .image-shape{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-BbWoSJFF4ud0jLqe .icon-shape p,#mermaid-svg-BbWoSJFF4ud0jLqe .image-shape p{background-color:rgba(232,232,232, 0.8);padding:2px;}#mermaid-svg-BbWoSJFF4ud0jLqe .icon-shape .label rect,#mermaid-svg-BbWoSJFF4ud0jLqe .image-shape .label rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-BbWoSJFF4ud0jLqe .label-icon{display:inline-block;height:1em;overflow:visible;vertical-align:-0.125em;}#mermaid-svg-BbWoSJFF4ud0jLqe .node .label-icon path{fill:currentColor;stroke:revert;stroke-width:revert;}#mermaid-svg-BbWoSJFF4ud0jLqe :root{--mermaid-font-family:"trebuchet ms",verdana,arial,sans-serif;} 是
否
是
否
进入请休假管理
点击申请休假
选择请假类型
填写日期与事由
点击提交
剩余天数充足?
流转至Leader审批
提示该类型余额不足
审批通过?
同步至考勤与薪资
退回并通知员工
看到没？没有一个技术术语。产品经理看得懂，业务方看得懂，测试也能拿着它写用例。
什么场景下，它最值钱？
我自己的感受是，这几类项目最需要它：
接手老项目：前任团队已经散了，代码在但没人说得清业务逻辑。让 Skill 把代码反推成文档，至少有一份「不说全对，但绝不乱编」的参考资料。
二期/三期开发：新功能要在旧系统上扩展。先跑一遍 code-to-prd 看看现有模块的边界和能力，避免新功能覆盖了旧逻辑。
团队扩招：新人上手项目，最痛苦的不是学技术栈，是理解业务。一份从代码反推的 PRD，比到处找人问「这个状态是什么意思」高效得多。
需求追溯：开发过程中发现文档和实现不一致。把当前代码跑一遍，生成一份"代码中说的事实"，拿着它和产品对质。谁对谁错，一目了然。
它不是万能的
也有它做不到的事：
- 它不知道业务方真正的意图。 代码只反映了实现，不反映为什么这么做。所以开放问题是必要的。
- 它不知道业务流程的「温度」。 比如"这个按钮用户很少点"、"这个字段改了会被投诉"------这些得和业务方聊，从代码里读不出来。
- 如果你连代码都没有，它帮不了你。 这是底线。
但话说回来，这些问题不是一个自动化工具有义务解决的。 它的职责是把代码翻译成业务语言，剩下的业务决策，还是得人来做。
最后说一句
我不觉得 AI 能替代产品经理。
但我相信，AI 可以帮产品经理省掉那些**「把代码读一遍再翻译成需求文档」**的体力活。
一个人一天能读多少代码、记多少业务逻辑、画几张流程图？很有限。
但一个 Skill 可以在几分钟内跑完整个项目，然后把结果摊在你面前：这是代码里有的，这是代码里没有的，你来决定怎么做。
把机械的活交给工具，把决策的活留给人。 这是我理解的 AI 跟人之间最健康的关系。
code-to-prd 是我近期做的一个 Skill，专治「代码在但文档没」的慢性病。
如果你也在维护一个永远欠着文档的项目，也许它可以帮到你。
GitHub：(https://github.com/DingoNan/skills)
------ 浅木·先生