doc-chain：一站式控制 AI 变更边界的文档依赖网络
一句话：doc-chain 是一站式控制 AI 变更边界的方案。从 PRD 到交互到 UI 到技术方案再到代码，每份文档声明上游来源、每次变更在边界内传播，全链路有迹可循、有界可依。
让 AI 做项目文档或写代码时，你大概率遇到过这些场景：
- 术语漂移：PRD 里叫"用户"，技术方案里变成"客户"，代码里写成"member"
- 改A忘B：PRD 加了新状态，技术方案跟上了，测试用例还在用老状态值
- 越界发挥：让 AI 补个接口字段，它顺手改了响应结构、换了错误码格式
- 代码走样：技术方案写得清清楚楚，代码实现却漏了权限校验、多了未定义字段
这些问题本质上是同一个根因：AI 不知道边界在哪。它不清楚自己的修改会影响哪些下游文档，也不清楚代码实现不能超出文档定义的范围。
doc-chain 的解法很直接：一站式建立文档依赖网络，用明确的上下游关系框定每份文档的权责边界。文档是项目的唯一事实来源，代码是文档的镜像实现。从文档生成到代码落地，边界控制贯穿全程。
1. 核心机制（1 分钟看懂）
doc-chain 只做两件事：
1. 每份文档声明上游来源 2. 每次变更在边界内传播
文档之间的依赖关系长这样：
markdown
PRD-顶层定义
│
┌─────────────────┼─────────────────┐
↓ ↓ ↓
交互-顶层定义 UI-顶层定义 技术-顶层定义
│ │ │
└─────────────────┼─────────────────┘
↓
PRD-订单模块
│
┌─────────────────┼─────────────────┐
↓ ↓ ↓
交互-订单流程 UI-订单页面 技术-订单服务
│ │ │
└─────────────────┘ ↓
测试-订单模块
↑
│
代码实现 & 审计三条边界控制规则：
| 规则 | 场景 | AI 必须做的事 |
|---|---|---|
| 下游不得超出上游 | 写技术方案时想新增接口 | 先确认该功能在 PRD 里有定义，没有就停 |
| 上游变更必须同步下游 | PRD 改了状态机定义 | 扫描所有下游文档，列出影响范围，询问是否同步 |
| 代码不得偏离文档 | 按技术方案写完代码 | 逐项审计：接口路径、字段名、类型、错误码、权限规则 |
任何一条被触发，AI 必须暂停并询问你，而不是擅自继续。
2. 实战用法（直接抄作业）
doc-chain 是一个 Kimi Code CLI Skill。装好后，核心就三种用法：
用法 A：从 0 到 1，文档+代码一站式落地
Prompt 公式 ：
项目背景+按 doc-chain 一站式生成文档和代码
直接复制：
"我要做一个 社区团购小程序 。请用 doc-chain 一站式 完成：先生成 PRD-顶层定义 （模块划分、术语表、状态值、错误码），再为 订单模块 产出 PRD → 交互 → UI → 技术方案的完整文档链，最后按技术方案实现代码并审计一致性。"
AI 的执行路径：
- 生成
PRD-顶层定义.md，头部写入upstream-document依赖表 - 按依赖顺序产出模块文档：
PRD-订单模块→交互-订单流程→UI-订单页面→技术-订单服务 - 每份文档头部声明实际加载的上游来源
- 按技术方案实现代码
- 启动只读 subagent，执行代码-文档一致性审计，产出审计报告
用法 B：文档已有，一站式补代码并校验
Prompt 公式 ：
基于现有技术方案+一站式实现代码并审计差异
直接复制：
"技术方案已确定。请一站式 完成：按 技术-订单服务 文档实现代码，完成后立即检查代码与文档的差异。重点核对：接口 URL/方法/参数、表结构字段、错误码、权限注解。"
AI 的执行路径：
- 读取技术方案文档和上游 PRD 文档
- 按文档实现代码
- 代码变更触发阶段 5 审计
- 产出《文档-代码一致性审计报告》，标注差异项和修正建议
用法 C：需求变更，一站式同步文档+代码
Prompt 公式 ：
修改 [上游]+一站式同步下游文档和代码+重新审计
直接复制：
"PRD-顶层定义里 订单状态 要增加
待成团。请一站式处理：扫描下游影响范围，同步所有相关文档和代码，最后重新执行代码审计。"
AI 的执行路径：
- 暂停上游修改，先分层扫描下游
- 列出影响清单（交互状态机、UI 语义色、技术表结构、测试用例、代码枚举）
- 询问确认
- 级联更新所有下游文档
- 同步修改代码
- 重新执行审计
3. 为什么不会拖慢 AI？
很多人担心："每次改文档都要扫描上下游，Token 会不会爆炸？"
不会。 doc-chain 的触发策略很克制：
- 非文档场景不触发 ：你问"写个排序算法"、"解释这段代码"，doc-chain 完全不加载
- 增量审计：修改模式下只加载变更 diff + 受影响章节，不读全文
- 脚本兜底 ：编号连续性、引用有效性、格式一致性等机械检查由
doc-audit.py执行，不走模型 - 代码审计独立：由只读 subagent 执行，主会话不自己审自己
边界控制是轻量的------只在越界时出声，平时不碍事。
4. 命名体系：模板和产出必须分开
doc-chain 对 skill 内部文件和项目产出做了严格的命名隔离：
| 层级 | Skill 内部（模板） | 项目产出（事实来源） |
|---|---|---|
| 顶层定义 | references/top-level/prd-top-level-template.md |
PRD-顶层定义.md |
| 模块文档 | references/steps/prd-step.md |
PRD-v1-订单模块.md |
关键区分：
- 带
-template后缀的：Skill 内部参考文件，只供 AI 阅读，禁止复制到项目 - 项目产出的：填充了实际内容的文档，是下游文档和代码的唯一合法来源
5. 避坑指南
-
不要跳过顶层定义
错误："直接写订单模块的 PRD"
正确："先检查 PRD-顶层定义 是否存在，没有就先生成"
没有顶层定义约束，模块文档的编号、术语、状态值会在不同模块间打架。
-
不要脑补需求
用户说"加个功能"但没说清楚边界 → AI 必须先列 gap 分析清单 → 用户确认后再输出。doc-chain 强制这个流程。
-
不要绕过上游缺陷
写技术方案时发现 PRD 状态机有矛盾 → 停下来，先回改 PRD → 同步下游 → 再继续。禁止在下游私自"适配"。
-
代码必须审计
技术方案再完美，代码也可能走样。阶段 5 的代码落地验证不是可选项。字段命名风格差异（snake_case vs camelCase）不算不一致，但业务含义必须一致。
-
编号不回收
删除
F005后编号留空，后续从F006继续。复用编号会导致上下游引用错乱。
总结
doc-chain 不增加文档工作量，它做的是在关键节点设置边界检查点，一站式覆盖从文档到代码的完整链路：
PRD 顶层定义 ──→ 模块 PRD ──→ 交互 ──→ UI ──→ 技术方案 ──→ 代码实现
↑ │
└──────────── 变更时回溯上游、同步下游 ─────────────────────────┘你的项目越大、AI 会话越多、文档链路越长，一站式边界控制的价值就越明显。
文档定义边界，代码镜像文档，变更在边界内传播。