| name | codebase-to-docs |
| description | 以内容优先、证据支撑的方式,从现有代码库生成详细的架构解析、工作流解析与参考文档体系。 |
代码库转文档
概述
将现有代码库转化为"可阅读、可核验、可维护、可演进"的文档体系。默认目标不是堆结构图或证据路径,而是先讲清系统在做什么、为什么这样设计、如何运行、如何失败、如何恢复,再用证据回溯这些结论。
核心方法: 采用"详细解析型输出",同时覆盖两条主轴:架构解析主轴 + 工作流解析主轴。先规划页面树,再生成正文,再补 Mermaid 图与证据索引。
何时使用
- 用户提出"分析这个仓库并生成架构文档"
- 用户提出"从源码补齐用户文档 / 开发文档"
- 用户提出"现有文档太浅,提升深度"
- 用户提出"反向梳理模块边界、请求链路、异常链路"
- 用户提出"把源码转成可维护的知识库"
不适用: 纯营销文案、与工程执行无关的随笔;换用对应技能。
核心原则
内容优先原则(强制)
- 主体页面以"可顺序阅读的完整内容"为主,证据引用为辅
- 正文先回答:是什么、为什么、如何运行、如何失败、如何验证
- 证据索引统一后置:到章节末或附录,避免打断阅读
- 图必须服务于解释:不是充当装饰
- 禁止"无证据结论":没有被正文解释的结论,哪怕引用很多,也视为不合格
双主轴并行原则(强制)
详细解析型输出必须同时覆盖以下两条主轴:
- 架构解析主轴:上下文与边界、容器/组件关系、请求生命周期、失败模型、部署与运维、横切关注点、架构决策、风险与技术债
- 工作流解析主轴:工作流地图、核心业务闭环、单条工作流深挖、状态流转、异常与恢复、排障路径、回滚与补偿
页面树规划原则(强制)
- 生成前必须先做页面树规划:列出页面路径、页面类型、页面目标、关键流程/机制、是否需要图、是否为长文深挖页
- 禁止边写边发散:禁止先拼正文后补结构
- 长文深挖页定义:architecture/request-lifecycle.md、architecture/failure-model.md、workflows/workflow--deep-dive.md
正常流与异常流原则(强制)
每个核心架构页或工作流页至少包含:
- flow-normal:一条正常流逐跳解析
- flow-exception:一条异常流逐跳解析
逐跳解析必须写明:调用点、被调用点、输入、输出、副作用、失败模式、恢复策略
设计取舍原则(强制)
每个核心页面至少包含 1 组设计取舍:
- 当前方案是什么
- 替代方案是什么
- 为什么没有选替代方案
- 替代方案的代价是什么(复杂度/一致性/性能/运维)
风险与技术债原则(强制)
风险不能泛写。每个风险项至少包含:
工作流程
Step 1:深度校准
1.1 确认范围(完整 / 仅架构 / 仅工作流 / 仅模块 / 仅参考)
1.2 确认 L 级别(L1 / L2 / L3)
1.3 确认输出语言(默认中文)
产出: 范围 + L 级别 + 语言确认
Step 2:页面树规划
2.1 定义主轴(架构解析主轴 + 工作流解析主轴)
2.2 定义页面职责(每个页面解决什么问题)
2.3 标记长文深挖页
2.4 定义每页的关键流程/机制
产出: page-tree + 页面职责
Step 3:证据索引
3.1 收集文件路径
3.2 收集符号(类名/函数名)
3.3 收集配置键
3.4 收集测试用例
产出: evidence-index 草稿
Step 4:系统建模
4.1 结构层建模(C4 Context / Container / Component)
4.2 行为层建模(调用链、数据流、状态流转)
4.3 运行层建模(正常流、异常流、恢复路径)
产出: 结构模型 + 行为模型 + 运行模型
Step 5:内容生成
5.1 先写正文(背景、边界、机制、流程、异常、取舍、风险)
5.2 再补图(结构图、运行时图、工作流图、故障恢复图)
5.3 再补附录证据(evidence-index)
产出: 完整文档
Step 6:四阶段验证
6.1 完整性:页面树、双主轴、正常/异常流、设计取舍、风险、证据、图
6.2 一致性:术语、图文、结论与证据、页面职责、正常/异常流
6.3 深度性:连续叙述、逐跳调用链、输入/输出/副作用、反例/边界、替代方案、结构化风险
6.4 可读性:页面目标、路径/符号/清单堆砌、图后解释、阅读顺序、相关页面
产出: 验证报告
Step 7:问题修复与最终汇总
7.1 修复完整性问题
7.2 修复一致性问题
7.3 修复深度性问题
7.4 修复可读性问题
7.5 最终汇总
产出: 最终文档
输出结构
推荐页面树
docs/
├── index.md
├── overview/
│ ├── architecture-at-a-glance.md
│ ├── workflow-map.md
│ └── reading-guide.md
├── architecture/
│ ├── system-context.md
│ ├── container-and-component-view.md
│ ├── request-lifecycle.md
│ ├── failure-model.md
│ ├── deployment-and-operations.md
│ ├── cross-cutting-concerns.md
│ ├── design-decisions.md
│ └── risks-and-tech-debt.md
├── workflows/
│ ├── core-business-flows.md
│ ├── workflow-<name>-deep-dive.md
│ ├── state-transitions.md
│ ├── exception-and-recovery.md
│ ├── troubleshooting-playbook.md
│ └── rollback-and-compensation.md
├── modules/
│ ├── module-<name>.md
│ └── module-<name>-runtime.md
├── reference/
│ ├── api.md
│ ├── config.md
│ ├── data-models.md
│ └── glossary.md
└── appendix/
├── evidence-index.md
├── assumptions.md
└── verification-notes.md
详细解析型最小页面集(强制)
若范围为完整详细解析,至少必须有:
index.md
overview/architecture-at-a-glance.md
overview/workflow-map.md
architecture/request-lifecycle.md
architecture/failure-model.md
workflows/core-business-flows.md
workflows/exception-and-recovery.md
reference/config.md
appendix/evidence-index.md
常见借口
| 借口 | 事实 |
|---|
| "代码就是证据" | 代码路径不能替代解释;必须先解释原理再引用代码 |
| "先写结构,内容以后补" | 禁止边写边发散;必须先规划页面树再生成正文 |
| "异常流不重要" | 每个核心页面必须包含正常流 + 至少 1 条异常流 |
| "设计取舍很难" | 每个核心页面至少 1 组设计取舍;必须说明替代方案和代价 |
| "风险以后再说" | 风险不能泛写;每个风险项必须包含触发条件、影响范围、可观测信号、缓解动作 |
| "只有架构页就够了" | 必须同时覆盖架构解析主轴和工作流解析主轴 |
| "图后不用解释" | 每张 Mermaid 图后都必须有解释;无解释的图视为无效 |
危险信号
- 主文以证据列表、路径列表、占位条目为主
- 只有总览/参考页,没有深挖页
- 缺少"异常流"章节
- 缺少"设计取舍"章节
- 缺少"风险与技术债"章节
- 缺少 Mermaid 图,或图后没有解释
- 调用链只写步骤,不写失败模式或副作用
- 页面之间没有导航关系
- 风险项缺触发条件或可观测信号
- 存在 3 个及以上"无证据结论"
- 内容密度预算不满足(根据 L 级别)
- 深度预算不满足(根据 L 级别)
示例
差: 先按章节复述代码结构,最后说"整体架构清晰"。
好: 先写背景和系统边界,然后逐跳解释调用链,每跳写明调用点、被调用点、输入、输出、副作用、失败模式、恢复策略,最后补设计取舍和风险分析。
差: "相关文件:src/service/order_service.py。下单流程:验证 → 创建 → 通知。"
好: "下单流程采用三步管道:先验证请求参数和库存,再创建订单记录并扣减库存,最后发送通知到消息队列。每一步失败时触发不同恢复策略:验证失败返回错误信息,创建失败回滚库存扣减,通知失败重试三次后记录到死信队列。证据:src/service/order_service.py -> OrderService.create_order。"
差: "采用队列而不是直接通知。"
好: "当前方案:消息队列。替代方案:直接调用通知服务。为何不选:直接调用会导致下单流程阻塞在通知环节,影响吞吐量。代价量化:队列引入约 10ms 延迟,但吞吐量提升约 5 倍。"
差: "风险:通知可能失败。"
好: "风险:通知服务不可达导致消息堆积。触发条件:通知服务宕机超过 30 秒。影响范围:死信队列堆积,需要人工介入。可观测信号:dead_letter_queue_size 指标超过 1000。缓解动作:告警 + 自动扩容 + 死信队列重试机制。"
验收标准
交付前须将下列待勾选框逐项勾为已满足;全部勾选后,方可将本轮文档生成标为"完成"。
完整性
一致性
深度性
可读性
L 级别预算(根据选定级别)
反模式检查
以上验证项已全部满足,本轮交付物符合本技能质量契约。
参考模板
输出文档的模板位于 reference/ 目录,包含以下模板:
| 模板文件 | 用途 |
|---|
template-docs-index.md | 文档导航首页模板 |
template-architecture-at-a-glance.md | 架构概览模板 |
template-workflow-map.md | 工作流地图模板 |
template-request-lifecycle.md | 请求生命周期模板(长文深挖页) |
template-failure-model.md | 失败模型模板(长文深挖页) |
template-workflow-deep-dive.md | 工作流深挖模板(长文深挖页) |
template-risk-register.md | 风险登记表模板 |
template-evidence-index.md | 证据索引模板 |
validation.md | 验证标准与报告格式 |
使用方法:复制相应模板,将占位符替换为实际内容,按模板结构生成文档。