# 00 总览：一套 AI 辅助大型项目的开发系统

governed_by：D-014、D-020、D-043、D-055
用途：本文是全部正文的入口。读完应该能回答三件事——系统由哪些部件组成、部件之间怎么连、从项目第一天到维护第 N 个月它们怎样配合。各部件的细节在各自的章里。

架构的归纳过程与证据（各独立来源的部件频次、不可省略投票、失败归因）见[架构确定](架构确定.md)；本文只讲结论。

## 1. 一句话

> **AI 辅助开发系统 = 四个平面 + 一条交付线。**

四个平面按职责划分：**知识平面**说什么是真的、要做什么；**执行平面**把事做出来、并能接着做；**控制平面**判断做对了没有、有没有失控、怎么自我修正；**责任平面**是只有人能承担的那部分判断。交付线从意图穿到验收，贯穿四个平面。

这个划分的实际含义是：

- 知识平面是**资产**，随项目积累，换工具不丢。
- 执行平面是**工具**，随时可换——换 AI 编程工具，换的是这一层。
- 控制平面是**纪律**，可以只用文档和人工流程实现，不必先有工具。
- 责任平面是**人**，不可转移，不随模型能力消解。

<a id="component-evidence"></a>

## 2. 四个平面与十四个部件

末列「频次 / 不可省略票 / 失败归因」是独立来源的统计（来源基数见[架构确定](架构确定.md)），本表是[架构确定 §5.1](架构确定.md#component-stats) 的声明缓存：绑定其当前版本、与源机械对账。正文各章不再复制这些数字，逐章的解读在[追溯账本](追溯账本.md)（效力为零）。

| 平面 | 部件 | 回答的问题 | 频次 / 不可省略票 / 失败归因 |
|---|---|---|---|
| 知识 | [10 意图与验收](10-意图与验收.md) | 要做什么、做到什么算完成 | 34 / 9 / — |
| | [11 项目知识](11-项目知识.md) | 项目特有、代码里读不到的事实 | 38 / 10 / 21 |
| | [12 记忆与知识治理](12-记忆与知识治理.md) | 经验怎样变成知识、怎样过期 | 33+16 / 2+6 / 10+11 |
| 执行 | [20 状态工件](20-状态工件.md) | 做到哪了、怎么恢复 | 39 / 11 / 27 |
| | [21 调度与拆分](21-调度与拆分.md) | 谁做、按什么顺序、卡住怎么办 | 38 / 7 / 19 |
| | [22 上下文装配](22-上下文装配.md) | 每次推理看什么 | 47 / 8 / 29 |
| | [23 方法库](23-方法库.md) | 怎么做才对 | 41 / 3 / 11 |
| | [24 工具与执行环境](24-工具与执行环境.md) | 能对世界做什么 | 50 / 4 / 18 |
| | [25 执行者与模型](25-执行者与模型.md) | 谁在生成和行动 | 49+42 / — / 8 |
| 控制 | [30 验证与测试](30-验证与测试.md) | 怎样证明做对了 | 42 / 16 / 32 |
| | [31 守卫与权限边界](31-守卫与权限边界.md) | 什么不许做、能力有多大 | 39+34 / 15+9 / 28+23 |
| | [32 证据与追踪](32-证据与追踪.md) | 凭什么说做过、花了什么 | 41 / 12 / 22 |
| | [33 评估与演进](33-评估与演进.md) | 系统本身在变好还是变坏 | 38 / 9 / 25 |
| 责任 | [40 人的检查点与授权](40-人的检查点与授权.md) | 哪些判断只能人做、谁负责 | 40 / 21 / 19 |

部件清单到此为止。与外部系统的读写、以及一次运行由谁发起，**不是第 15、16 个部件**：它们是同一件事的两个方向——那一侧不归我们管——已收敛为§5 的第六条不变量，落在 [11](11-项目知识.md)、[21](21-调度与拆分.md)、[24](24-工具与执行环境.md) 的一行标注上。裁决过程见[架构确定 §6](架构确定.md#edge-components)。

## 3. 一条交付线

意图确认与冻结 → 从验收条目派生工作项与验证用例 → 每轮先读状态工件 → 派发一个可独立验收的切片 → 装配上下文 → 执行 → 从环境回读事实 → 三态裁定（通过 / 失败 / 未定）→ 证据写回状态 → 状态转换 → 验收。

三条规则贯穿全线：每一步的出口是可版本化、下一步能机器读取的工件；未执行与无法核验记为**未定**，不折算为通过；人只在五处状态转换上出现。

四个闭环是这条线上的回流：**交付闭环**即本线；**上下文闭环**在执行平面内（装配 → 使用 → 外部化）；**记忆闭环**是执行 → 控制 → 知识（经验候选 → 验证与治理 → 晋升为知识或方法）；**改进闭环**在控制平面内（观察 → 归因到层 → 可复现 Case → 修复 → 双路径验证 → 接受或回退 → 删减）。

<a id="default-scope"></a>

**本套正文的默认作用域。** 各章只引用本节，不重复。

**(一) 对象。** 本套正文的对象是这套开发系统本身（含我们依赖的外部机制——触发源、拦截层、判定器，它们同样受本系统的消费计数、误伤计数与退场纪律约束），以及**被交付产品中承载主张的那一部分**。**判据：产品侧的一个对象进入本规范的视野，当且仅当读它是为了回答一条主张——即它是某条"应该怎样"或"现在怎样"的载体。**进入之后它与该主张的其它载体同等对待，适用[11 项目知识](11-项目知识.md) §2 P1 与 P2；它承载的主张若既未映射到一条验收条目、也未登记为一处主张冲突，即为一笔未登记的结构债，处置是按[10 意图与验收](10-意图与验收.md) §2 P1 补建条目、或按 11 §2 P1 登记冲突并声明各载体的范围与版本，二者取一；冲突未消除前，依赖该主张的切片其验收条目逐载体绑定证据——这就是刹车，每次变更都要付逐载体的验证成本，且这个成本按条目可见。
**边界停在这里：本规范管"这条主张有几个载体、哪个权威、冲突时怎么办"，不管"这个载体本身好不好"。** 产品的功能正确性、性能与可维护性由它自己的验收条目承接（[10 意图与验收](10-意图与验收.md)）；产品结构如何改、按什么顺序改是那些条目的**内容**，不是本规范的内容；产品侧的失败与运行观察以"支撑或反驳某条主张的观察"身份进入（[32 证据与追踪](32-证据与追踪.md) §2 P1），其分类法、归因层表与容量模型是项目参数——本规范的归因层表只对本系统自身的失败成立（[33 评估与演进](33-评估与演进.md) §2 P7）。产品运行的资源消耗作为一次动作的可观察前置条件由[31 守卫与权限边界](31-守卫与权限边界.md) §2 P2 承接、作为风险由[40 人的检查点与授权](40-人的检查点与授权.md) §2 P7 承接，不进入成本记账的轴：成本三轴的对象是本系统的消耗，因为它服务的是本系统的优化提案评审。**改进闭环的对象仍只是本系统的机制**：晋升链、Add 与 Thin、到期审计作用于本系统的规则、方法条目、记忆与机制，不作用于产品的结构。

**(二) 一次运行的类型。** 一次运行由两个正交属性描述。**产出类型**：交付型，出口是验收；或事实型（诊断、考古、状态重建、影响面调查），出口是一份带成立条件的事实、一个假设与一组待人裁决项，**不是变更**。**起点状态**：从头，或接手。
§5 各条不变量、控制平面与责任平面的原则对一切运行成立。其余每条原则的适用范围由它自己的**删除条件**尾标承载（取值域含起始档与运行类型限定，见[09 跨工具通用性](09-跨工具通用性.md#two-axes) §4）——本节不列举受影响的原则编号，那样做等于把作用域写成一份需要同步维护的清单。
每次运行在起点处声明它的类型、它的合法停止点与出口；**时限到达是一个合法停止点，其去向是交接而不是阻塞**；事实型运行读到停机条件时记未定并进入下一步，不转阻塞。事实型运行的产物有落点：现行行为的重建结果落[11 项目知识](11-项目知识.md)（带范围与观察时间的现行行为主张集合），状态的重建结果落[20 状态工件](20-状态工件.md)，两者都按[30 验证与测试](30-验证与测试.md) §2 P1 的"结论 + 其成立条件"形式携带成立条件；事实型运行的出口材料是短交接的一个受众参数化视图（同[22 上下文装配](22-上下文装配.md) §2 P1），不是第四类状态工件。

## 4. 平面之间的接口

括号内是明确画出这条关系的独立来源数。

- 知识 → 执行：短入口按需拉取，不全量推送（24）；验收条目派生工作项与用例（12）；状态工件是每轮起点，不回放对话（20）。
- 执行 → 控制：执行事实由环境回读，不信模型自述（21）；子执行者只回结构化结果（18）；确定性判断先由程序做，模型只判残余（18）。
- 控制 → 执行：动作或阶段转换前阻断并回显原因（29）；独立验证者给出裁定与定位（22）；范围与预算在创建时固化、执行中只能收窄（15）。
- 控制 → 知识：证据与轨迹是评估、删减、到期审计的输入（28）；失败驱动规则与方法的增删（22）；状态转换处提取记忆候选并经治理写回（15）。
- 控制 → 责任：超限、门禁失败、告警升级到人（21）。
- 责任 → 知识：人确认并冻结意图（19）。
- 责任 → 控制：不可逆动作只能由人授权（17）。

## 5. 不变量

换任何工具都不变的那一组。它们是各章原则的公共前提，与十四个部件并列，本身不隶属于任何一个部件。**全文只有一处，在[架构确定 §5.3](架构确定.md#invariants)；本文只列标题。**

1. **控制平面独立于执行平面。**
2. **状态外置且朴素。**
3. **知识单一权威。**
4. **事实来自回读。**
5. **责任不可转移。**
6. **边界外不由我们控制。**

## 6. 后期为什么会变慢：按部件的诊断表

大型项目到后期变慢，通常不是生成速度不够，而是某个部件失守。下表按"被多少来源归因"排序，可当作排查顺序。

| 症状 | 最可能失守的部件 |
|---|---|
| 做完了但说不清对不对；测试全绿仍出事 | [30 验证与测试](30-验证与测试.md)（32 个来源归因） |
| 新会话一开始就臃肿；规则越写越多却越不被遵守 | [22 上下文装配](22-上下文装配.md)（29） |
| 规则只写在文档里、从没拦住过任何事 | [31 守卫与权限边界](31-守卫与权限边界.md)（28） |
| 换个会话就失忆；中断后不知从哪继续；重复已失败的尝试 | [20 状态工件](20-状态工件.md)（27） |
| 规则与资产只增不减；改了很多但说不清有没有变好 | [33 评估与演进](33-评估与演进.md)（25） |
| 越权改动、并行互相覆盖、审批被绕过 | [31 守卫与权限边界](31-守卫与权限边界.md)（23） |
| 完成声明查无实据；成本不知去向 | [32 证据与追踪](32-证据与追踪.md)（22） |
| 按过期文档行事；文档与代码对不上 | [11 项目知识](11-项目知识.md)（21） |
| 人被打断到麻木；验收积压无人真判 | [40 人的检查点与授权](40-人的检查点与授权.md)（19） |
| 拆分后互相等待；返工没有尽头 | [21 调度与拆分](21-调度与拆分.md)（19） |
| 确定性的事交给模型做错；工具选错用错 | [24 工具与执行环境](24-工具与执行环境.md)（18） |
| 跨系统重跑灌入重复记录、审计对不上；接入方一变链路就断；无人触发则永不启动 | 第六条不变量（见 §5），标注与落点在 [11](11-项目知识.md)、[21](21-调度与拆分.md)、[24](24-工具与执行环境.md)（9 与 6，场景相关） |

## 7. 从 L0 到 L3

四档不是必经阶段，是**同一套部件在不同规模下的形态**。升级到下一档的唯一条件是：上一档的验证能力跟得上。自主度的上限永远是"能廉价可靠验证的量"。

| 档 | 场景 | 这一档的重点 |
|---|---|---|
| L0 | 一人一工具 | 四个平面都存在，但全部是文档与人工流程：一份验收条目清单、一张模块地图、一份工作项与交接、几条踩坑规则、人自己确认五处。 |
| L1 | 一人多会话 | 跨会话的连续性成为主要问题：状态外置、交接两层、压缩当作事件处理、条目 ID 作为跨会话锚点。 |
| L2 | 团队 | 责任分离与一致性成为主要问题：验证者与生成者分开、写入权与生成权分开、事实门禁上线、记忆与方法进入治理、成本按单元可观测。**第六条不变量通常在这一档第一次真正生效**——组织已有系统进入回路，内部 / 外部标注与跨边界写纪律开始有对象。 |
| L3 | 无人值守 | 前置条件是"有一个不需要人在场就能拒绝坏输出的判定器"；预算与范围创建时固化、活性巡检、机制自身的消费与误伤计数。 |

各章 §3 给出本部件在四档的具体形态。

## 8. 怎么读

- 只想知道整体：读本文，再看[架构图](架构图/README.md)。
- 要落地某一件事：按 §2 的表直接进对应章；每章结构相同——最小职责与接口（含未决）、原则、L0 到 L3、追溯指针。
- 要查某条规则的来龙去脉：[追溯账本](追溯账本.md)给逐章的问题陈述、原章节与主题综合映射、每条原则的证据强度；决策本身查[决策日志](决策日志.md)，效力查其中的生效登记表。账本效力为零，日常执行不必加载。
- 要查证据：[架构确定](架构确定.md) 给统计，[参考资料](参考资料/README.md)给逐来源卡片与主题综合。
- 元治理（一条规则何时算生效、怎样写才跨工具通用）在[08](08-规范效力元治理.md)与[09](09-跨工具通用性.md)，日常阅读可以跳过。

## 9. 当前状态

**正文原则的效力状态只查[生效登记表](决策日志.md#effective-register)，本文不复制那张表也不概述它**——本处此前抄了一句正文的整体效力状态，那是一份会过期的副本（[08 §7](08-规范效力元治理.md)），2026-09-03 删除。读一条原则之前先确认它此刻有没有阻断力，以及它自己的「删除条件」把作用域限在哪里。

已由项目所有者确认的结构性判断：四平面划分、人单列为责任平面、边缘部件按"判据加不变量"处理（不设第 15、16 个部件）（2026-09-02，D-043 与 D-047）；一次运行加载什么由唯一的[上下文合同](../CONTEXT_MANIFEST.md)按运行类型出视图（2026-09-03，D-015）。

**每章是四节**：最小职责与接口（含未决）／原则／L0–L3／追溯指针。各章的问题陈述、源章节与主题综合映射、每条原则的证据强度在[追溯账本](追溯账本.md)（效力为零，默认不加载）——它是证据材料，与[架构确定](架构确定.md)、[来源与证据矩阵](https://github.com/Alan-IFT/dsh-project-std/blob/archive-pre-ts-refactor/docs/%E5%BD%92%E6%A1%A3/%E6%9D%A5%E6%BA%90%E4%B8%8E%E8%AF%81%E6%8D%AE%E7%9F%A9%E9%98%B5.md)同族。

仍待确认的清单见[决策索引](决策日志.md#decision-index)；条数与分组以该文件为准，本文不抄。原 00–07 章已被本套章节取代，保留在[历史版本](https://github.com/Alan-IFT/dsh-project-std/blob/archive-pre-ts-refactor/docs/%E5%BD%92%E6%A1%A3/%E5%8E%86%E5%8F%B2/README.md)中以便追溯。