少读一点，少猜一点：design-doc v8 - v7 按需路由省Token，v8 统一术语少返工

1 第一个“多”：AI 每次都要通读全套规则

早期的技能包就像一本厚手册。不管是写需求、改设计、修bug，或是简单问个问题，AI 都得把整本手册过一遍。

手册内容齐全本来是优势，但每次都全量读取，成本很高。 上下文窗口容量有限，大量无关规则挤占空间，关键约束很容易被冲淡。不仅响应慢、消耗更高，长任务里还更容易丢失前面的信息。

v7 改成了路由+按需加载：先识别当下要做什么，只加载对应的流程；流程里需要细节时，再去调取对应片段。 好比去图书馆先查索引，而不是从头挨个书架翻。

实际效果：

简单任务不会被复杂规则拖累；复杂任务只加载当下需要的流程；宝贵的上下文留给业务本身，输出更稳、开销更低，规则之间也不会互相干扰。

校验逻辑一点没缩水。改代码依旧要对照设计文档，出现冲突照样按缺陷处理。优化的只是不必要的重复阅读，不是省略必要校验。

v7 顺便理顺了废弃标记和编号：废弃不等于直接删掉，标注清楚原因和分类，后续需要还能回溯；编号优先用短号，不够再自然递增，不用刻意凑固定位数。

2 第二个“多”：同一个词，在不同地方含义不一样

就拿几个常见词举例：“订单”在需求里是用户发起的购买申请，到接口层可能只是一条待支付记录；“客户”有时候指签约公司，有时候只是对接人；“完成”可以是代码合入，也可以代表上线。

人沟通时，靠着经验和语境大多能意会。AI不行，它严格按字面执行。越是要求精准，歧义带来的偏差就越明显。

很多返工，根源不是写得不够细，而是同一个术语，在不同文档里悄悄变了意思。

v8 新增了项目术语共识机制：

每个术语在项目内只有一份权威定义，其他文档只做引用，不再重复写；全局术语表统一索引，想查一个词的含义和出处，直接检索；文档还可以声明用到的术语，人和AI先对齐词义，再往下阅读。

好处很直观：

换协作人、新开对话、换模型，词义都保持一致；评审 ¹时不用反复拉扯名词定义；需求、设计、代码、测试，大家共用同一套语言；同名不同义的问题，能尽早发现并收敛。

它不是强制大家背词典。只登记那些跨文档复用、容易吵起来的词，普通描述性文字照常写。术语本身不属于设计条目，不占用编码，不会给文档增加负担。

3 省下的，不只是 Token

节省 Token 只是一半价值，另一半是减少人与人之间的沟通内耗。两者结合，才是真正提效。

4 落到日常协作里，变化体现在这些地方

改需求的时候，产品不用反复解释，两处“订单”不是一回事；AI 先核对术语定义，再调整文档。

写代码的时候，开发不用纠结“完成”到底到哪个节点才算数，设计里已经统一口径，AI 按这个标准实现。

新人接手项目，不用泡在一堆历史聊天记录里猜上下文；先过一遍术语表，再顺着定义读设计。

多团队、多应用协同的时候，共用一套术语索引，不用各自私建词汇表 ²；遇到同名冲突直接按缺陷处理，避免各说各话。

5 v8 保留的核心原则

• 单一事实来源（SSoT）：一份设计对应一个编码，通过编码引用；文档废弃，但编号保留。
• 决策权归人：定稿、废弃、发版这类关键判断，始终由人来决定。
• 分层文档与模板：从战略 ³到验证按需裁剪，大部分项目从需求和系统设计起步。
• 产品基线：只有纳入基线的正式内容，才作为开发依据。
• 自动化校验：脚本检查编码、状态、引用、术语一致性。

v7 让这套框架变轻，v8 让它变得更准。

6 开源免费，支持商用

designdoc 采用 MIT 协议：https://github.com/reddishz/designdoc 安装配置以仓库 README 为准，v7、v8 的底层机制说明放在技能包内文档。

系列阅读：

• 基础介绍：designdoc
• v5（氛围编程与定稿闸门）：designdoc-vibe
• v6（产品基线）：designdoc-v6
• 本文：v8（含 v7 按需路由）