代码转需求文档这可能是你最不该省的那一步做过的系统越多我就越确认一件事代码里什么都长唯独不长业务逻辑的说明书。前几天一个朋友跟我吐槽。他们接了一个外包项目的二期。一期是另一个团队做的代码在 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 时序图核心交互可选状态图复杂状态流转而且图的命名和描述都是业务语言不是技术术语。是否是否进入请休假管理点击申请休假选择请假类型填写日期与事由点击提交剩余天数充足?流转至Leader审批提示该类型余额不足审批通过?同步至考勤与薪资退回并通知员工看到没没有一个技术术语。产品经理看得懂业务方看得懂测试也能拿着它写用例。什么场景下它最值钱我自己的感受是这几类项目最需要它接手老项目前任团队已经散了代码在但没人说得清业务逻辑。让 Skill 把代码反推成文档至少有一份「不说全对但绝不乱编」的参考资料。二期/三期开发新功能要在旧系统上扩展。先跑一遍 code-to-prd 看看现有模块的边界和能力避免新功能覆盖了旧逻辑。团队扩招新人上手项目最痛苦的不是学技术栈是理解业务。一份从代码反推的 PRD比到处找人问「这个状态是什么意思」高效得多。需求追溯开发过程中发现文档和实现不一致。把当前代码跑一遍生成一份代码中说的事实拿着它和产品对质。谁对谁错一目了然。它不是万能的也有它做不到的事它不知道业务方真正的意图。代码只反映了实现不反映为什么这么做。所以开放问题是必要的。它不知道业务流程的「温度」。比如这个按钮用户很少点、“这个字段改了会被投诉”——这些得和业务方聊从代码里读不出来。如果你连代码都没有它帮不了你。这是底线。但话说回来这些问题不是一个自动化工具有义务解决的。它的职责是把代码翻译成业务语言剩下的业务决策还是得人来做。最后说一句我不觉得 AI 能替代产品经理。但我相信AI 可以帮产品经理省掉那些**「把代码读一遍再翻译成需求文档」**的体力活。一个人一天能读多少代码、记多少业务逻辑、画几张流程图很有限。但一个 Skill 可以在几分钟内跑完整个项目然后把结果摊在你面前这是代码里有的这是代码里没有的你来决定怎么做。把机械的活交给工具把决策的活留给人。这是我理解的 AI 跟人之间最健康的关系。code-to-prd 是我近期做的一个 Skill专治「代码在但文档没」的慢性病。如果你也在维护一个永远欠着文档的项目也许它可以帮到你。GitHub[(https://github.com/DingoNan/skills)]—— 浅木·先生