文档依赖网络：一站式掌控AI变更边界指南
doc-chain：以文档依赖网络精准锁定AI变更边界
用AI编写项目文档或代码时，下面几个典型冲突你大概率遇到过：
- 术语漂移：PRD称“用户”，技术方案换成了“客户”，代码实现又变成“member”。
- 改A忘B：PRD新增状态节点，技术方案同步更新，测试用例却沿用旧的状态值。
- 越界发挥：让AI补一个接口字段，结果它顺手修改了响应结构、替换了错误码格式。
- 代码走样：技术方案描述完整，代码实现却遗漏权限校验、多出未定义字段。
归根结底，痛点只有一个：AI无法感知自己的操作边界。它既不清楚修改会波及哪些下游文档，也不知道代码实现不能超出文档定义的范围。
doc-chain 的解决方案很直接：构建文档依赖网络，用清晰的上下游关系划定每份文档的权责边界。文档是项目唯一的真实来源，代码则是文档的镜像实现。从文档生成到代码落地，边界控制贯穿始终。
1. 核心机制（1 分钟读懂）
doc-chain 只做两件事：
文档之间的依赖关系如下：
PRD-顶层定义│┌─────────────────┼─────────────────┐↓ ↓ ↓ 交互-顶层定义UI-顶层定义技术-顶层定义│ │ │└─────────────────┼─────────────────┘↓PRD-订单模块│┌─────────────────┼─────────────────┐↓ ↓ ↓ 交互-订单流程UI-订单页面技术-订单服务│ │ │└─────────────────┘ ↓ 测试-订单模块 ↑ │ 代码实现 & 审计
三条边界控制规则，简单直接：
| 规则 | 场景 | AI 必须执行的操作 |
|---|---|---|
| 下游不得超出上游 | 写技术方案时想新增接口 | 先确认该功能在 PRD 中已定义，无定义则停止。 |
| 上游变更必须同步下游 | PRD 修改了状态机定义 | 扫描所有下游文档，列出影响范围，请求确认是否同步。 |
| 代码不得偏离文档 | 按技术方案完成代码 | 逐项审计：接口路径、字段名、类型、错误码、权限规则。 |
任何一条规则被触发，AI 必须暂停并向你请示，不得擅自继续。
2. 实战用法（直接套用）
doc-chain 是一个 Kimi Code CLI Skill。安装后，核心用法主要有三种：
用法 A：从 0 到 1，文档+代码一站式交付
直接粘贴：
AI 的执行路径：
- 生成
PRD-顶层定义.md，头部写入upstream-document依赖表。 - 按依赖顺序产出模块文档：
PRD-订单模块→交互-订单流程→UI-订单页面→技术-订单服务。 - 每份文档头部声明实际加载的上游来源。
- 按技术方案实现代码。
- 启动只读 subagent，执行代码-文档一致性审计，输出审计报告。
用法 B：文档已存在，一站式补全代码并校验
直接粘贴：
AI 的执行路径：
- 读取技术方案文档及其上游 PRD 文档。
- 按文档实现代码。
- 代码变更触发阶段 5 审计。
- 输出《文档-代码一致性审计报告》，标注差异项与修正建议。
用法 C：需求变更，一站式同步文档+代码
直接粘贴：
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 会话越频繁、文档链路越长，这一站式边界控制的价值就越突出。