从代码反推需求文档(L1 补写)
项目特定约定(目录结构、版本制、命名规则)优先参考该项目自己的项目级补丁 skill(见
templates/项目级补丁模板/)。 本 skill 只提供通用方法论。
1. 操作流程
补写 <项目>/docs/01-需求/ 时,按以下顺序操作:
1. 确定模块边界
2. 从前端找:页面、入口、交互动作
3. 从后端找:接口、业务能力、规则与状态
4. 从枚举和模型补充:状态、类型、边界条件
5. 查看项目归档目录,与代码证据交叉核对;任一来源都不能自动取得裁决权
6. 用业务语言重写成需求文档
7. 最后清理:"是否写进了实现细节?"
2. 代码阅读重点
前端
- 页面名称与层级、tab 与分包结构
- 服务调用名称、按钮文案
- 空状态 / 错误状态处理、页面跳转关系
后端
- Controller 对外能力
- 枚举体现的状态和值域
- Biz / Service 中的规则与限制
- 权限校验、状态流转、外部依赖
3. 归档使用规则
可以用归档补充:模块命名、业务意图、代码中不明显的边界规则
不能用归档:覆盖代码事实、把旧方案当成当前事实
4. 不确定信息处理
- 回到代码继续验证
- 用归档做交叉核对
- 仍无法确认 → 写入任务底稿的「待确认」清单,不得混入正式 L1
5. 需求文档推荐模板
代码只能反推候选业务语义。正式 L1 只保留裁决后的当前需求;来源、置信度、实现状态和“待确认”统一留在任务底稿。若意图仍未闭合,交付候选底稿而不是缩水版正式 L1。
每个模块的编号 README(例如 01-xx-00-README.md)或模块说明文档推荐章节:
0. 版本归属 / 适用版本
1. 模块目标
2. 用户价值
3. 页面与入口
4. 功能列表
5. 业务规则
6. 状态流转
7. 系统支撑能力
8. 异常与边界场景
9. 与其他模块的关系
10. 验收标准