简诗代码转PRD

接手一个现成的前端或全栈项目，最常见的情况是：代码能跑，但没人说得清每个页面到底在做什么。组件名、路由名和变量名往往只能传达局部信息，产品上下文散落在组件内部、DTO 定义、序列化器和中间件里。当产品经理、新成员或 AI Agent 需要理解系统时，重新梳理一份产品需求文档的成本极高。

从代码反推业务行为

@user_fccf428b/code-to-prd-builder 的工作方式不是简单总结目录结构，而是按一套固定流程重建产品上下文：

• 识别技术栈：根据 package.json、manage.py、requirements.txt 等文件判断框架，再采用对应的解析策略。
• 建立清单：前端项目提取路由、页面标题和组件路径；后端项目则把路由映射为接口、控制器/视图和所属模块。
• 补全全局上下文：整理全局状态、权限条件、枚举常量、API 基础配置、数据模型和中间件。

三阶段逆向流程

1. 全局扫描

第一阶段先不进入具体页面。技能会扫描项目结构，识别 NestJS、Express、Django、FastAPI 等后端框架，或 React、Vue、Next.js、Nuxt 等前端框架，并生成页面清单或接口清单。

对于后端项目，“页面”会被转换为 API 资源组或管理后台视图。路由变成接口，控制器和组件变成处理逻辑，组件交互变成请求与响应流程。

2. 逐页深度分析

第二阶段逐个分析页面或接口。文档会覆盖字段清单、表单校验、表格列、行操作、搜索与分页、页面加载行为、权限可见性，以及页面之间的跳转和数据耦合。

API 依赖也会被区分：如果代码中存在真实 HTTP 调用，就记录方法、路径、触发时机和关键参数；如果页面使用 Mock、fixture 或 Promise.resolve() 桩数据，则会根据页面功能反推建议接口规范。

3. 生成可消费的 PRD

输出通常放在项目根目录的 prd/ 下。每个页面生成独立 Markdown 文件，并附 README.md 作为总览。

文档使用业务语言描述行为。例如，不写“useEffect 在挂载时请求数据”，而写“打开页面时自动加载第一页结果”；不写“组件通过 useState 管理加载状态”，而写“点击搜索后显示加载状态，避免重复提交”。

适用边界与注意点

该技能适合需要从已有代码库重建产品说明的场景，尤其是缺少 PRD、交接文档或业务规则说明的项目。它对以下信息的处理比较有价值：

• 后端 DTO、序列化器和模型约束，例如唯一性、长度限制和枚举选择。
• NestJS 的 Guard、Pipe，以及 Django Admin 中的筛选、内联模型和自定义动作。
• 散落在常量文件、i18n 翻译或组件配置中的状态码和类型映射。
• 模态框、抽屉和动态路由参数这类容易被遗漏的业务逻辑。

但它不会保证所有业务含义都能从代码中确定。遇到缩写变量名、复杂条件分支或没有注释的常量时，技能会标记 [TBC]，而不是猜测含义。项目规模超过 15 个页面时，建议按模块分批审查输出。

如果项目只是静态站点生成器，且没有真实接口、状态管理或业务规则，产出会偏薄；如果是未配置 Django Admin 的后端项目，Admin 相关细节也会缺失。整体上，它是代码理解与 PRD 补全工具，不能替代对业务目标和外部约束的确认。