把蓝图做成项目的唯一真理源 — TEAM OS 里的 D0/D1/D2

一个活动中的项目里，「文档」通常是层叠的化石：三个 sprint 前写一半的设计稿、没人信任的 wiki、上次重写之前才准的规格书、和代码已经走样的 Notion、藏在某个人头脑里的部落知识。这些没有一份是*真理本身*，每一份都是*某种程度的真理*。新人进来无法判断哪一份是对的，于是去问，答案进一步分叉。这是软件项目的默认状态，而 AI agent 让事情更糟、不是更好 — 它会从最先找到的化石那一份开始外推，毫无心理负担。

TEAM OS 用一件东西取代这种状态：蓝图。它不是「文档之一」，不是 wiki，而是一个被构造为「唯一真理源」的项目成果物。任何功能改动、任何新增功能、任何实现微调，都先更新蓝图。代码和蓝图不一致时，在没人做出别的判断之前，蓝图赢。框架对待蓝图的方式，等同于建筑工地对待施工图：代码是建造，蓝图是图纸，图纸没画的地方不能浇混凝土。

完整性的标准是物理的。 蓝图被称为完整，是指拿到它的工程师可以不再做产品决策或架构决策就开始干活，剩下的只是实装层面的代码选择。这是宣布蓝图「完成」之前要跑的检查。如果实装过程中冒出「这件事应该怎么动？」「这归哪个子系统？」这种问题，蓝图就是不完整，答案要先回写到蓝图里再继续。这话听起来像口号，但其实是个可验证的性质：在开发的任何时刻，都可以问「我们刚才被迫做出的、蓝图里没有的决定是什么？」如果答案非琐碎，蓝图就失败了。

蓝图栈宽三层。 D0 是产品定位 — 这是个什么产品、服务谁、MVP 边界在哪里、要满足什么非功能指标、成功怎么度量、系统怎么划分。D1 是产品设计 — 功能详设、用户故事、UI、五种节点定义，以及贯穿其中的数据模型。D2 是技术设计 — 技术选型、节点模块、API、DB 表、EXT 外部依赖、部署拓扑。两条旁路并行：术语表把项目特定词汇一次性固定下来；D9 调研日志把所有非琐碎选型（库、供应商、模型、算法）连同被否决的备选与原因一并记录。

框架早期版本有 D0-D9 九层。 我们删了六层 — 不是因为它们追踪的工作不必要，而是因为每一层都重复了已经在做同样工作的姊妹子系统。D3（任务排期表）被任务子系统吸收。D4（变更日志）变成 type=change 类型的任务。D5（测试用例表）整体解散 — 完整的蓝图本来就定义了所有节点、所有契约、所有 KPI；测试该从蓝图取，不该再写一份。D6（发布检查清单）变成部署 Skill 的完成判定。D7（经验文档）被重构成带三种保鲜期的记忆子系统。D8（记忆存档）变成现代 agent 运行时本来就在做的平台自动保存。最后留下来的是 D0/D1/D2 + D9。删层让蓝图栈变小*而且*更准 — 剩下的每一片现在都有且仅有一个归属。

分类器同构。 同一套「核心 / 副 / 辅助」三分类在系统级和功能级都能用。系统级：抽掉核心系统产品就失去意义；副系统的输出影响 / 门控核心系统；辅助系统不影响核心系统。功能级：核心功能就在核心流程链路上；副功能作为支线接入核心流程（影响或门控）；辅助功能不接入核心流程。一句话两个层级 — 任何新工作都可以不用争论分类边界，就被分进三个箱子之一。

任何流程都解析到五种节点。 TIN 是终端输入：用户直接产生的。DIN 是数据输入：别的系统产生的、由用户中转过来。TOUT 是终端输出：用户能感知的反馈。DOUT 是数据输出：给用户的结构化资产，他可以拿到别处用。STATE 是状态写入：系统绕过用户、直接写中间文件。这就是字母表全部。一个用户故事就是这些节点串起来的一条路径；一个功能就是经过某个子系统的路径集合；一份蓝图就是所有路径的并集，加上实现它们的模块。

数据按它"怎么进入节点图"分类。 信息是流过节点的东西（再分为瞬时、积累性、记录性、临时性四个子类）。规则是节点内部的逻辑（再分为设计师规则、用户设置）。资源是节点引用的东西（再分为设计师定义、媒体素材、用户生成物）。这不是谁在白板上拍脑袋编出来的三类，而是当你问「这个数据在图里干嘛」时，从节点模型里自动落下来的答案。蓝图强制把产品里出现的每个概念（心情、礼物、好感度、对话）在升级成实数据文件之前，先填进这三列横切表 — 在数据库里少一个字段之前，先在定义里抓到这个遗漏。

D2 必须指回 D1。 D2 里声明的每个节点模块都要列出它支撑的 D1 功能。指不出 D1 调用者的模块，不应该存在。这一条比我们用过的任何其他检查，杀死了更多架构漂移。它同时让蓝图可以双向导航：D1 → D2 找实现，D2 → D1 找正当性依据。没有不被任何业务用的模块漂着，也没有声称行为却没有任何模块实现的 D1 功能。

蓝图是一份 git 成果物。 它住在项目仓库里、被版本控制、能 diff、可 review。没有外部服务、没有托管的 wiki、没有需要「记得」什么的模型。被派任务的 AI agent 把蓝图当作普通文件读，把改动作为普通文件写回，紧挨着代码 commit。人类审查者读的也是同样的文件。没有特权通道。这就是为什么 agent 可以从项目进行到一半时进来、用很少几轮就开始干活 — 它读蓝图的方式和任何其他工程师没区别，蓝图告诉它所有东西在哪。

我们并不声称蓝图解决了项目管理本身。意见分歧仍然会发生、决策仍然会老化、艰难选择仍然要靠人去做。蓝图解决的只是「真理在哪里」这一个问题 — 但仅仅是这一个问题被具体地回答了，其余所有事情上的摩擦都会减少一大块。