三跃迁 · Three Leaps

从加速器到解放者 —— AI 在框架与 Harness 约束下走向自主编程的工程之路。

From Acceleration to Liberation — AI’s path to autonomous coding under framework & harness constraints.

本方法论以 v7 deck 「三层引力梯度 × 三跃迁」为主线，融合 v3 第一性原理推导、度量公式与资本论分析。配套幻灯片见 deck/index.html，零基础起步路径见 three-leaps-bootstrap.md。

0 · 阅读地图

#	章节	解决的问题	来源
1	当下困局	为什么必须治理	v7 §02 + v3 三衰减
2	总图：三层 × 三跃迁	整套体系的一张图	v7 §03
3	第一性原理推导	为什么是这三层不是其他	v3 §1
4	L0 工程引力场	AI 装入系统前的地基	v7 §04
5	跃迁① 状态可见	从代码 → 状态	v7 §05 + v3 §8
6	信号 → 意图	L1 到 L2 的桥	v7 §06
7	跃迁② 意图可表达	从命令 → 意图	v7 §07 + v3 §6.4
8	意图 → 执行	L2 到 L3 的桥	v7 §08
9	跃迁③ 系统自收敛	从一次推理 → 持续自治	v7 §09 + v3 §6
10	自主权梯度 R0-R5	把可逆动作交给 AI	v7 §10
11	全景闭环 · 订单团购案例	端到端跑通一遍	v7 §11
12	反模式与边界	何时该停手	v7 §12 + v3 §11
13	角色演化	人去哪里	v7 §13 + v3 §10
14	度量框架	怎么知道在变好	v3 §12
15	未来形态	2030 年的工程师	v7 §14
16	价值终章	企业 / 个人 / AI	v7 §15
附录 A	资本论 C/V/M 映射	价值流向分析	v3 §3
附录 B	V-model 在 AI 时代的变形	验证侧重武装	v3 §4
附录 C	CALMS · DORA · 看板	流的执行节奏	v3 §5
附录 D	MDM 声明式范式跃迁	哲学根基	v3 §6

一句话总纲

在每一个交付时刻，让 AI 生成的制品同时处于「被需要 / 被信任 / 被理解」三重状态。

SCQA

Situation：AI 编码已把生产端边际成本压到接近零
Complication：人类审查能力线性，AI 代码故障率约 3× 高于人工
Question：如何在不阻塞 AI 产能的前提下，让组织对产物始终保持需要、信任、理解
Answer：先建工程引力场（L0），再让模块状态可见（L1），再让业务意图可声明（L2），最后让系统自收敛（L3）—— 三跃迁逐层叠加，把 AI 装进可信的工程系统

1 · 当下困局

1.1 代码生成已超越人类的验证能力

能力
 ↑
 │           AI 编码产出
 │         /  指数增长
 │        / ┌─────────┐
 │       /  │ 能力缺口 │
 │      /   └─────────┘
 │     /  ─ ─ ─ ─ ─ ─  人类审查
 │    /   ─ ─ ─ ─ ─ ─  线性增长
 │   /
 │  /
 └─────────────────────────→ 时间

Sonar 调研：AI 代码故障率约 3× 高于人工。当 AI 产出指数增长而人审线性增长，能力缺口不是”暂时的人手不够”——它是结构性的。

1.2 三重衰减

软件资产同时受三种力量侵蚀：

衰减	来源	表现	失守的代价
价值衰减	业务变化、需求过期	已有功能不再被用	资产腐烂为僵尸代码
架构衰减	依赖腐烂、熵增	模块互相绞缠	架构腐烂为大泥球
知识衰减	人员流动、上下文丢失	没人敢动的”祖传代码”	质量腐烂为技术债

AI 加速产出会同时放大三种衰减——它写得快，但同样写得不被用、写得违反边界、写得没人理解。

1.3 治理的目的：被需要 / 被信任 / 被理解

三重状态	对抗的衰减
被需要 (Needed)	价值衰减
被信任 (Trusted)	架构衰减
被理解 (Understood)	知识衰减

结论：不能让 AI 单纯加速 —— 必须把 AI 装进可信的工程系统。

2 · 总图：三层 × 三跃迁

            L3 · AUTONOMOUS LOOP                  ← 跃迁③ 系统自收敛
            Harness · Agent · Reconciliation         (Apple DDM 思想再创造)
                       ▲
                       │
            L2 · INTENT EXPRESSIBLE               ← 跃迁② 意图可表达
            INTENT → CONTRACT → VERIFIER             (业务意图 → 结构化声明)
                       ▲
                       │
            L1 · STATE VISIBLE                    ← 跃迁① 状态可见
            身份 · 5态机 · 三维健康度                 (系统工程 · DDD)
                       ▲
                       │
       ╔═══════════════════════════════════════╗
       ║ L0 · GRAVITY FIELD                    ║ ← 工程引力场（地基 · 不是阶段）
       ║  框架 · 模块身份 · CI/CD · 运行时       ║   precondition
       ║  · DevOps · 沙箱                      ║   跳过 L0 = 把 AI 放进沼泽
       ╚═══════════════════════════════════════╝

2.1 关键阅读约定

L0 是地基，不是阶段：它先于一切，没有它跃迁不可能发生
L1 → L2 → L3 是跃迁：每一跃迁都改变范式，不是渐进升级
- 跃迁① 从代码 → 状态
- 跃迁② 从命令 → 意图
- 跃迁③ 从一次推理 → 持续自治
L0-L3 不是先后阶段，是协作层：上线之后同一时间每一层都在工作（详见 §11）

2.2 三跃迁内部展开

跃迁③ 内部：HARNESS → AGENT → RECONCILE → GRADIENT → SIGNAL
跃迁② 内部：INTENT FILE → CONTRACT → VERIFIER
跃迁① 内部：IDENTITY → 5-STATE FSM → 3-D HEALTH

2.3 全程贯穿案例

后续每章都用同一案例展开：订单服务支持团购功能。让抽象层级落到一个具体的业务需求上。

3 · 第一性原理推导

这套体系不是经验主义清单，而是从 4 条不可再分事实推导出的封闭系统。如果觉得 §4 之后的机制设计”看起来合理但不知道为什么是这样”，就回到本章。

3.1 四条不可再分事实

事实	表述	来源支撑
F1	AI 编码的边际成本趋零	LLM 算力规模化已是产业事实
F2	人类审查能力线性增长，无法跟随 AI 产能	Sonar：AI 代码故障率约 3× 高于人工
F3	软件资产经历价值/架构/知识三重衰减	业务变化 / 依赖腐烂 / 人员流动
F4	组织生存依赖可信资产的累积；不可信资产是负债	资本论”凝结劳动” + 工程实践

四条事实无法再分解为更基本的命题——它们是 AI 编码时代的”物理学约束”。

3.2 由事实推导三公理

推导	公理
F2 + F4 → AI 输出必须对齐意图	公理 1：意图保真
F2 + F3 → AI 决策必须可回滚	公理 2：动作可逆
F1 + F3 + F4 → 质量必须编码进系统而非事后补救	公理 3：质量涌现

3.3 由公理推导三支柱

公理	支柱	工程轴	失守的代价
意图保真	价值锚定	时间轴	资产腐烂为僵尸代码
动作可逆	边界封控	空间轴	架构腐烂为大泥球
质量涌现	制程内建	因果轴	质量腐烂为技术债

三支柱在时间/空间/因果三个独立轴上工作，两两正交、共同穷尽——单一支柱崩塌产生独特失败模式。

3.4 三公理 → 三跃迁的对应

公理	直接落到的跃迁
公理 1 意图保真	跃迁② 意图可表达（让意图成为可验证契约）
公理 2 动作可逆	跃迁③ 系统自收敛 + R0-R5 梯度（按可逆性让渡）
公理 3 质量涌现	L0 工程引力场 + 跃迁① 状态可见（质量编码进基底与状态机）

3.5 为什么 L0 不是跃迁

跃迁意味着”范式改变”。L0 的六件事（框架/模块身份/CI/运行时/DevOps/沙箱）都是经典软件工程的显性化、自动化版本——它们是物理学约束，不是范式跃迁。

把它们叫”地基”而不是”阶段一”，避免组织把 L0 当成可以草草跑过的入门关。没有 L0，跃迁就只是 PPT。

⚠️ “地基” ≠ “冻结的物体”：L0 框架本身是慢变量但仍是变量，通过 §10.6 反哺循环驱动演进。详见 §4.1「框架是活的慢变量」。

本节回答：本节是推理引擎——证明三跃迁不是选择，是必然。

4 · L0 工程引力场（precondition · 不是阶段）

把 AI 装进系统之前，必须先把”系统”建出来 —— 这是物理学约束。

L0 由六个支柱组成。前三是经典工程治理的延续，后三在 AI 时代被重新强调：

#	支柱	内容	AI 时代的意义
01	框架	领域抽象 · 契约骨架 · 质量基底	框架越好 · AI 价值越大
02	模块身份	`module.yaml`：身份 · 意图 · 状态 · 信号	L1 跃迁的入口
03	CI/CD 门禁	lint · type · test · contract · sec scan	左加速 100× · 右重武装 3×
04	运行时 (NEW)	容器 · K8s · service mesh · registry	AI 写的代码必须能跑起来
05	DevOps 全栈 (NEW)	deploy · log · trace · metric · secret · alert	AI 错了 · 必须能秒级回滚
06	沙箱	隔离 · 可观测 · DDD 边界上下文	AI 只在沙箱中尝试

4.1 框架：机床

借用 v3 资本论视角：框架是凝结度最高的不变资本 (C)。

框架职能	失守代价
领域隔离（限界上下文的物理边界）	模块互相绞缠，重构成本随时间二次方上升
基础抽象（存储/消息/鉴权/观测）	适配器膨胀、依赖混乱
契约骨架（API/事件/错误码标准）	模块间无法协同
质量基底（测试基类/Mock/sandbox/archtest）	每个模块重复造轮子

优秀框架 × 100 个模块 = 100 份高质量产出缺失框架 × 100 个模块 = 100 份混乱（同样速度复制混乱）

框架不是单点能力，是 L0 整层渐进建造的产物

四个职能不能在同一时点全部就位：

蓝图（pre-ADR + 三层骨架 + SDK 签名 + 契约位置 + test-base 占位）
   ↓
CI 让 lint/test/build 在骨架上跑起来（约束开始 enforced）
   ↓
hello-world 走骨架而非裸代码（蓝图被验证可运行）
   ↓
分层填满骨架（骨架变得有内容）
   ↓
archtest 把 README 边界变成机器规则（约束真正生效）
                    ↓
        完整框架 = 蓝图 + 6 项 enforced 能力

重要：框架的”约束”需要 CI 与 archtest 来 enforce。没有它们，框架只是 README，任何 AI 自治承诺都建立在松散约束之上。这是反模式 A1「治理过度」与 A3「梯度失守」的共同根源。

详见 three-leaps-bootstrap.md §3 的渐进建造路径与 P0.0 蓝图能力。

框架是活的慢变量 — 反哺循环（亦称演进引擎）

框架是凝结资本，但凝结 ≠ 冻结。框架不是设计一次然后冻结使用的——它通过反哺循环（Reflux Loop）持续演进：

模块替换 ──► 多 agent 并行重写 ──► 候选差异 + 互审发现 + 偶发新方案
                                                    ↓
            框架升级队列 ◄──────────  harvest（提取共性）
            intent 修订草稿 ◄────────                ↓
                  ↓                                  │
            下一轮模块从更精密骨架启动 ────────────────┘

慢变量：framework 季度演进，intent 月演进，模块周演进——三者节奏不同，但全是活的
反哺方向：模块替换的副产品（候选差异 / 共性问题 / 新范式）回流到 framework 与 intent，让下一批模块更精密
演进引擎：这就是 §10.6 模块即商品的真正机制——商品坏了不只换商品，机床也在被改良

反哺循环是整套方法论的活性来源。没有反哺，framework 退化为冻结教条 → modules 在过期 framework 上挣扎 → 最终回到大泥球。详见 §9.4 reconcile 的 harvest 步骤、§9.5 多 agent 反哺、§10.6 演进引擎、§12 反模式 A8「替换不反哺」、§13.2 演进策展人角色、§14.2 反哺命中率指标。

4.2 模块身份：`module.yaml`

每个模块必须携带一份机器可读的身份卡片。这是 L1 跃迁的入口——没有 manifest，连”哪个模块出了问题”都说不清。

module:
  name: order-service.group-buy
  domain: order

intent:
  goal: 团购下单
  metric: GMV ↑ 15%

contracts:
  exposed: [GroupOrder]
  consumed: [payment.coupon]

lifecycle:
  state: experimental   # → candidate → asset → maintenance → retired

signals:
  collected_by: [ci, otel, sonar]

4.3 CI/CD 门禁：左加速 × 右重武装

V-model 在 AI 时代的变形（详见附录 B）：

   左侧加速 100×                右侧重武装 3×
   AI 编码秒级 ───────────►    静态分析 + 模糊测试 + 契约校验 + 形式化验证

CI/CD 不是 lint 跑一下，是 5-7 层独立门禁的串联：lint → type → test → contract → sec scan → SBOM → coverage gate。

4.4 运行时（NEW · v7 新增强调）

AI 写的代码必须能跑起来——而不是看起来对。这要求：

容器化（Docker / OCI image）
编排（Cloud Run / Container Apps / K8s 按规模选）
服务网格（mTLS / 流量镜像 / 灰度路由）
镜像 registry + provenance

反模式：让 AI 写代码但 PR 合入后没有运行时验证 —— 等同于让 AI 在白板上写代码。

4.5 DevOps 全栈（NEW · v7 新增强调）

AI 错了，必须能秒级回滚。这要求：

能力	用途
部署（progressive delivery）	canary 1% → 10% → 50% → 100%
日志（结构化 JSON）	事后追溯 AI 决策路径
链路（OTel trace）	跨服务故障定位
度量（SLI/SLO + budget）	客观判断”是否好”
Secrets 管理	AI 不应见到明文凭证
Alert + on-call	drift 早发现

回滚是 R 梯度的物理基础：R1-R3 之所以可让渡给 AI，正是因为有秒级回滚兜底。没有 DevOps 全栈，整套 §10 自主权梯度都是空头支票。

4.6 沙箱：受控试错

AI 必须在沙箱里尝试，再逐级解锁权限：

隔离（namespace / network policy / resource quota）
可观测（沙箱内行为可全程审计）
DDD 边界上下文（沙箱即一个有界限的实验场）

4.7 资本论视角：L0 = 凝结度最高的 C

L0 六支柱都是”凝结的过去劳动”。组织在 L0 上每多投入一份功夫，AI 在 L1-L3 的产出精度就上一个台阶。

本节回答：L0 是物理学约束。跳过 L0 = 把 AI 放进沼泽。

5 · 跃迁① 状态可见（L1 · State Visible）

从代码 → 状态。每个模块都有身份、状态机、健康度信号。

5.1 两个维度

L1 不只是”给单模块标个状态”，而是同时建立两个维度：

维度	内容	失守的代价
单模块生命周期	五态机 + 三维健康度	无法判断”模块是否还该活着”
模块间装配关系	系统组合视图 + 契约图	只有模块·没有系统装配·等于系统工程失败

5.2 五态机

意图 → experimental → candidate → asset → maintenance → retired
                                                        ↓
                                                    墓碑 (24h 软删)
       │              │           │              │
       价值评审       业务信号    人审·全门禁     业务衰减

状态	入口条件	回退路径
experimental	意图通过价值评审	删骨架 + 关意图
candidate	业务信号 ≥ 阈值 + 冒烟通过	退回 experimental
asset	全门禁通过 + 人审批	退回 candidate
maintenance	业务信号衰减但仍有依赖	重新激活回 asset
retired	无依赖 + 业务信号归零	24h 内可恢复

墓碑：模块名 / 最后版本 / 对外契约快照 / 依赖快照 / 退役原因 / 退役日期 / 24h 软删窗口。墓碑是”可审计的死亡证明”，不是简单一行日志。

5.3 三维健康度

价值得分 = w1·关联需求数 + w2·契约订阅数 + w3·流量得分    (0-100)
结构得分 = w1·框架合规 + w2·边界一致性 + w3·契约注册一致   (0-100)
工程得分 = w1·覆盖率 + w2·构建通过率 + w3·活跃度衰减加权    (0-100)

衍生信号：

健康警告：任一维 < 30
强制退役建议：任一维 < 10
强制人审：三维全 < 50 持续两周

5.4 信号采集（机械化清单）

维度	信号	采集方式
业务	关联活跃需求数 / 契约订阅数 / 流量触达	需求系统 API + 流量埋点
架构	框架使用合规度 / 跨域依赖数 / 契约注册一致性	静态分析 + archtest
工程	测试覆盖率 / 构建通过率 / 缺陷密度 / 活跃度衰减加权	CI + git + 缺陷追踪

绝对禁止：靠人手填写信号。所有信号必须是机械化采集的衍生量。

5.5 系统装配视图

单模块的健康不等于系统的健康。L1 必须同时维护模块组合图：

user-svc ──► [order.group-buy] ──► payment.coupon
                  │                       │
                  ├──► notify-svc         │
                  └──► inventory          │
                  contract: GroupOrder ◄──┘

SYSTEM · 装配 5 跳 · 最弱节点 65 ──► 系统得分 ≠ 模块均值

系统得分 = min(链路上所有模块的最弱维度)，而不是均值。一个 65 分的关键依赖会拉低整条链。

5.6 案例：团购模块当前状态

case · order-service.group-buy
state · candidate （收集业务信号中）
3-D health · 价值 80 · 结构 65 · 工程 90

L1 的产出是状态可见性——下一步才能在此基础上声明意图（→ §6 桥）。

本节回答：跃迁① 把每个模块从代码变成可观测对象。

模块本身是活的：在 asset 期可能被多次 patch / 一次 replace（详见 §10.6）。状态机的”asset → maintenance → retired”不是宿命的衰退路径，当 framework 或 intent 演进时，asset 也可能因 REPLACE 而焕新——状态机覆盖的是模块的整个活态生命周期。

6 · 信号 → 意图（Bridge · L1 → L2）

看见状态 → 才能描述意图。L1 把每个模块变成”可观测对象”·L2 把每个变更变成”可声明事件”。

6.1 单纯信号是数据洪流

L1 OUTPUT · 信号
─────────────────────────────────────
order-service.discount · 调用率 ↓ 73% / 30d
order-service.group-buy · 错误率 2.1%
payment.coupon · 健康度 91 / 90 / 88
…数百模块的实时画像

→ 没有方向 · 不能行动

数百个模块的实时画像，如果没有”应该是什么”作为对比基准，就只是噪声。

6.2 意图把信号变成判断

L2 INPUT · 意图
─────────────────────────────────────
"让订单服务支持团购，
 支付走券码，p99 < 200ms"
                    │
                    ▼ AI 翻译
contract: POST /orders/group
sla.p99: 200ms · sla.error: 0.5%
depends_on: payment.coupon (≥85)
success: signals.usage ≥ 1k/d

有了意图，每条信号都能被比对：

错误率 2.1% vs sla.error 0.5% → 偏离
payment.coupon 健康度 88 ≥ 85 → 满足

6.3 桥的命题

没有 L1 的状态可见，L2 的意图就只是空头支票。

意图不能凭空声明——它必须基于”现在的真实状态”。L1→L2 的桥保证了意图永远扎根在现实里。

7 · 跃迁② 意图可表达（L2 · Intent Expressible）

从命令 → 意图。不是把 MDM 套用过来 · 是把”声明 + 收敛”的思想范式重新落到代码层面。

7.1 INTENT FILE 四块结构

意图文件不是抽象概念，是这四块：

┌─────────────────────────┬─────────────────────────┐
│ 01 · BUSINESS           │ 02 · CONTRACT           │
│ 业务意图                  │ 技术契约                  │
│ goal: 团购下单            │ api: POST /orders/group │
│ metric: GMV ↑ 15%       │ schema: GroupOrder      │
│ deadline: 2026-Q2       │ events: [GroupCreated]  │
├─────────────────────────┼─────────────────────────┤
│ 03 · QUALITY            │ 04 · LIFECYCLE          │
│ 质量阈值                  │ 生命周期                  │
│ p99: 200ms              │ state: candidate        │
│ error: < 0.5%           │ sunset_if: usage<100/d  │
│ coverage: ≥ 95%         │ review_at: 30d          │
└─────────────────────────┴─────────────────────────┘

每一字段都直接映射到验证器（详见 §7.3）。

7.2 MDM 的创造性应用

不是把 Apple DDM 直接套用，而是借用同构范式：

Apple DDM（设备管理）	软件模块治理
Declaration	Intent file
Reconciliation	Drift detect + AI agent loop
Convergence	持续向意图收敛
Predicates	信号阈值条件
Status channels	三维健康度回写

同构而不是同物：设备拉取 declaration · 模块拉取 intent；设备配置自适应 · 模块自演化。

7.3 字段 → 验证器的直接绑定

不是文档·是可执行：

意图字段	自动绑定的验证器
`sla.p99: 200ms`	k6 性能测试，回归即 fail
`contract: GroupOrder`	合约测试（pact / openapi diff）
`coverage: ≥ 95%`	新增代码覆盖率门禁
`sunset_if: usage<100/d`	reconciler 定时检查 + 自动告警
`depends_on: payment.coupon (≥85)`	装配视图健康度联动

7.4 解决什么业务需求

团购需求不再是 PRD 文档 + 排期会 + Jira 票，而是一份 intent 文件 —— 一边声明、一边交付、一边监控。

这就是 v3 §6 “范式跃迁”的真正落地：从”人在决策环路里”变成”人在期望状态定义环路里”。

本节回答：跃迁② 让意图变成可验证、可收敛、可审计的工程对象。

intent 本身也是活的：业务变化 → intent v2 → 触发模块 REPLACE（详见 §10.6 触发层）。intent 修订率（§14.2）应该是健康的非零值——长期不变的 intent 通常不是稳定，而是与业务脱节。

8 · 意图 → 执行（Bridge · L2 → L3）

声明 → 才需要”执行者”。L1 状态机给出”现在哪里”·L2 意图给出”要去哪”·L3 Harness 是”自动化的去那里”。

8.1 Drift Detect：声明与现实的差距

┌────────── DESIRED STATE ──────────┐    ┌─── CURRENT STATE (L1) ───┐
│ 团购下单                            │    │ api: not implemented      │
│ p99 200ms · 95% cov                │    │ delta: missing            │
│ contract: GroupOrder               │    └───────────────────────────┘
└────────────────────────────────────┘                │
                    │                                  │
                    └─────► drift detected ◄──────────┘
                          desired ≠ current

只有当 desired ≠ current，才有”执行者”存在的必要。Reconciliation 的本质是追平 drift。

8.2 AI Agent · 自主任务循环

· 读取 intent + 当前 signals
· 规划任务 · 分解步骤
· 在 Harness 内调用工具
· 写代码 · 跑测试 · 自校验
· 提 PR · 等门禁 · 收信号
· 未达标 → 回到 01

直到 desired = current (CONVERGED)，循环退出。

8.3 桥的命题

L2 没有 L3，意图就只是写在纸上的承诺。

声明本身不会让团购功能上线。需要一个能把 intent 翻译成 PR、能跑测试、能在失败时重试的执行者。这个执行者就是下一节的 Harness + Agent。

8.4 drift 是双向的

reconciler 默认场景：current 漂离 desired（模块出问题），需要把 current 拉回 desired。但 v7 的反哺循环（§4.1）让 drift 变成双向的：

drift 方向	触发场景	处理路径
current → 漂离 desired	代码 bug / 性能退化 / 依赖中断	传统 PATCH（§9.4）
desired → 主动演进	framework v2 / intent v2 / 业务变化	REPLACE + harvest（§9.4 / §10.6）

第二种 drift 不是”模块坏了”，是”上层进步了”——current 没出错，desired 改变让它”过期”。REPLACE 路径专为这种 drift 设计。

9 · 跃迁③ 系统自收敛（L3 · Autonomous Loop）

从一次推理 → 持续自治。Agent 的上下文与进度·大部分可从 L1 系统状态渐进式披露·不必凭空构造。

9.1 Harness 是工程外壳，不是 Prompt

关键不是更聪明的 AI · 是更稳定的”外壳 + 心跳”。

Harness 五件套（基于 Anthropic 官方）：

组件	作用
系统上下文	注入项目知识、约束、规范（CLAUDE.md / cursor rules）
工具约束	fail-closed 权限 + 命令黑名单
上下文注入	Agent Skills + Progressive Disclosure
记忆与进度	跨 session 状态保持（git log + ADR + memory）
评估循环	持续收敛而非一次推理（CI 全绿 + eval suite）

9.2 渐进式披露：上下文从 L1 系统状态来

Agent 的上下文不需要凭空构造，绝大部分来自 L1 已记录的系统状态：

L1 STATE · 源                              HARNESS · 工程外壳
┌──────────────────────┐                   ┌─────────────────────────┐
│ 系统设计 (DDD)        │                   │      AGENT · 头脑        │
│ API · 契约 (openapi)  │   渐进式披露        │      AI 智能体           │
│ UI 设计 (tokens)     │   ─────────────►   │      plan · act · obs   │
│ 进度 (tasks/PRs)     │                   │                         │
│ 健康度 (3-D 评分)     │                   │   TOOLS · 受控  EVAL · 心跳 │
│ ALL RECORDED         │                   │   白名单动作    持续自校验   │
└──────────────────────┘                   └─────────────────────────┘
                                                     │
        ┌────────────── 回写状态 ◄──────────────────┘
        │
        ▼
   RECONCILE · 系统状态趋向意图 · ∞ loop

这就是为什么 §5 和 §6 必须先建立——L1 状态可见性是 L3 Harness 上下文的来源。

9.3 与 K8s controller / Apple DDM 同构

L3 不是发明新范式，而是借用成熟范式：

维度	Apple DDM	Kubernetes	L3 软件治理
期望状态	Declarations	CRDs	Intent file
拉取机制	Device pulls	Controller watches	Reconciliation agent
条件应用	Predicates	Label selectors	信号阈值
状态报告	Status channels	Status subresources	三维健康度
故障下行为	Offline 自维持	Controller 重启幂等	软删窗口 + 墓碑

9.4 Reconciliation Loop 伪代码

loop:
    1. pull module manifests + intent files
    2. collect signals (CI / git / dependency / traffic)
    3. compute current health score (三维)
    4. detect drift (current vs desired)
    5. choose remediation strategy: PATCH or REPLACE
         PATCH (打补丁) ── 适合：drift 局部 / 模块结构合理 / 修复成本低
         REPLACE (重写) ── 适合：drift 系统性 / 框架已迭代 / 重写成本 ≤ 修补成本
                          ↳ 模块即商品（详见 §10.6）：在框架强约束下，
                            从骨架重新生成 + 让 intent 驱动 AI 写一份新的，
                            往往比修补几年累积的 patch 更可控
    6. apply remediation, 按可逆性 R0-R5 让渡：
         R0-R1 (只读 / 实验代码): AI 直接执行
         R2 (受控外部): AI 自动放行 + audit log
         R3 (跨域写入): AI 提议 + 审查（详见 §10.5 审查方的演化）
         R4 (影响用户): 阻塞 + 强制人决策
         R5 (资金 / 物理): 永不放开
    7. if REPLACE: harvest（反哺循环 · 详见 §4.1 / §10.6）
         (a) 收集 N 个 agent 候选实现的 diff → 提炼为可能的范式
         (b) 收集多 agent 互审的共性问题 → framework / CI / archtest 改进队列
         (c) 收集 intent 表达不充分处（候选实现差异即 intent 不完备）→ intent 修订草稿
         ↳ 反哺产出不立即生效，进入演进策展人（§13.2）评审队列
    8. report status to dashboard + 决策审计存储
    9. 状态变化反馈回 L1 · 下一轮的输入

9.5 多 agent 多模型 · 编队作战

单 agent 单模型是 v7 的初始姿态。在框架与质量基底足够强的前提下，意图 → 状态 → 模块 → 上线的每一步都可以并行运行多个 agent 多个模型，竞争产出 → 择优合并。

9.5.1 为什么编队

不同模型各有所长（长上下文 / 推理深度 / 编码精度 / 工具使用 / 视觉），单模型在每个阶段都是次优解。让多模型分工，组合优势 > 单模型最强。

9.5.2 阶段化编队示例

阶段	多 agent 怎么用	择优规则
意图理解	长上下文模型解析 PRD（Gemini 2M）+ 推理模型提炼 intent.yaml（Claude）+ 验证模型对照检查	三者一致 → 通过；分歧 → 升人
模块实现	3 个 agent 并行实现 → 跑同一套测试	coverage + perf 最高的 PR 入选
代码审查	安全 agent + 性能 agent + 架构 agent + 风格 agent 并行	综合评分；任一 critical 问题阻塞
上线决策	reconciler 综合多个独立健康度模型	多数决放行；少数派理由进审计

9.5.3 择优策略编码进 intent

intent:
  execution:
    strategy: race | majority | ensemble | tournament
    # race      = 多 agent 抢跑，先达标的入选
    # majority  = 多模型投票，多数决
    # ensemble  = 多产出加权合成
    # tournament = 多轮淘汰，最优者上线
    judges:
      - model: claude-opus-4-7
        role: 架构合规
      - model: claude-sonnet-4-6
        role: 性能优化
      - model: gpt-5
        role: 安全风险
    quorum: 2/3      # 超过门槛才能放行

9.5.4 资本论视角：把 V 多倍化

单 agent = 单倍 V；多 agent 编队 = N 倍 V，但只为最高质量产出付费。其余 N-1 份草稿成为”废品”,但从总体成本看仍可能远低于人工返工。关键是 token 成本 < 人工成本 × 节省的返工次数。

9.5.5 反模式

盲投 —— 不同模型如果训练数据高度同质，多数决退化为单数决；选 judge 时要保证模型异质性
裁判即选手 —— 同一模型既写代码又审代码，拖累为自我合理化；判官必须独立模型
无限回合 —— tournament 必须有最大回合数，否则陷入永远迭代

9.5.6 多 agent 不止用于择优 — 也用于反哺

「择优合并」是单向的（N 个候选 → 选 1 个）。但多 agent 编队在替换场景下能产生双向反馈：

副产品	反哺方向
N 个候选实现的差异	暴露 intent 的不完备处 — “三个 agent 写出三种支付容错策略 = intent 没说清楚” → intent 修订草稿
某 agent 偶发出的新方案	提炼为框架的新最佳实践 — “原来这个抽象更适合此场景” → framework 升级队列
多 agent 互审的共性问题	反哺到 framework / CI / archtest — “这种边界经常被违反” → 加新规则、补 archtest、改 SDK 默认

这就是 §10.6 模块即商品的真正动力源——模块替换不只产出新模块，还反哺上层让 framework 与 intent 演进。

关键洞察：单 agent 替换 = 修复一个 bug；多 agent 替换 = 系统进化一次。N 个候选的差异本身比”最优答案”更有价值——它们是 framework / intent 的测试用例。

本节回答：编队作战让 v7 的”AI 单兵”演化为”AI 集群”——这是 §10 R 梯度的并行版本：同一可逆动作，多 agent 抢跑择优；同时是 §10.6 反哺循环的核心引擎：择优只是开始，候选差异回流到上层才是关键。

§9.5 是 §10.5 的工程实现手段：当独立 AI 审查 agent 由”另一个模型”扮演时，§9.5 的”判官必须独立模型”原则恰好提供了 §10.5「独立 AI 审查」所需的可信性。

10 · 自主权梯度 R0-R5

不是”AI 全权” · 是”AI 接管可逆动作”。把可逆动作交给 AI · 把不可逆动作留给人 —— 这才是真正的解放。

10.1 六级梯度

REVERSIBILITY · 可逆度
可逆 ←─────────────────────────────────────────────────► 不可逆

┌─────────┬─────────┬─────────┬─────────┬─────────┬─────────┐
│ R0 READ │ R1 LOCAL│ R2 CTRL │ R3 CROSS│ R4 USER │ R5 IRREV│
├─────────┼─────────┼─────────┼─────────┼─────────┼─────────┤
│ 只读分析│ 本地修改│ 受控外部│ 跨域写入│ 影响用户│ 资金物理│
│ 查代码  │ 改本仓库│ 沙箱 API│ 改其他  │ 删数据  │ 转账    │
│ 提建议  │ 单测护栏│ 测试环境│ 服务·迁移│ 改账单  │ 设备控制│
├─────────┼─────────┼─────────┼─────────┼─────────┼─────────┤
│AI 全自动│AI 自动  │AI 自动放│AI 提议+ │人审·永不│人决策·  │
│         │         │行       │人审      │放开     │红线     │
│ no human│ git回滚 │audit log│staged   │human    │never    │
│         │         │         │rollout  │ gate    │  auto   │
└─────────┴─────────┴─────────┴─────────┴─────────┴─────────┘

10.2 梯度与 Harness 配置的对应

梯度	Harness 配置	兜底机制
R0 只读	仅上下文 + 评估	不写任何东西
R1 本地修改	+ 受限文件编辑工具	git rollback
R2 受控外部	+ 沙箱 API + 测试环境写权限	audit log + 沙箱隔离
R3 跨域写入	+ 跨服务 / 迁移操作权限	staged rollout + 人审
R4 影响用户	–	human gate · 永不放开
R5 资金 / 物理	–	never auto · 红线

10.3 永恒边界

R5 永不放开——这是整个体系的边界条件，无论组织信任度多高、AI 能力多强。

R4 在阶段四（远景）也仅作”阻塞 + 强制人决策”，不进入自动化范围。

10.4 梯度失守 = 灾难

把 R4/R5 也交给 Agent，是反模式 A3「梯度失守」的核心症状（详见 §12）。反模式的代价随阶段递增——L0 失守是浪费，L3 失守是事故。

本节回答：R 梯度把”AI 自主”从一个口号变成可执行、可审计、有红线的工程参数。

10.5 审查方的演化（v7+ 方向）

§10.1 表中 R3 = “AI 提议 + 人审” 是 v7 的初始姿态。在框架与 DevOps 全栈足够强的前提下，“人审”本身可以演化——不是放弃审查，是把审查者从瓶颈解放出来。

三种审查方

审查方	适用场景	节奏	信任来源
人审	框架 / 契约 / 规范的变更（meta 层）	慢但权威	资历 + 责任
独立 AI 审查	实例代码变更（在框架内）	24×7	模型异质 + 框架强约束 + 健康度兜底
多 agent 互审	高分歧 / 高风险场景	并行	多模型多数决（详见 §9.5）

三种审查方的边界条件

关键：审查方升级 ≠ 删除审查。三种审查方在不同场景下并存。

┌────────────────────────────────┬────────────────────────────────┐
│  人审保留（永不消失）             │  AI 审查可承担                 │
├────────────────────────────────┼────────────────────────────────┤
│ · 修改 L0 框架（影响所有模块）     │ · 实例代码（在框架边界内）       │
│ · 新增 R3 → R4 之间的边界规则      │ · intent.yaml 字段绑定的验证场景 │
│ · 修改 R 梯度本身的规则           │ · 健康度阈值已覆盖的常规改动     │
│ · ADR 级别决策                  │ · 已有 archtest 拦截的越界尝试   │
│ · 任何涉及 R4/R5 的提议           │ · 可被 staged rollout 兜底的变更 │
└────────────────────────────────┴────────────────────────────────┘

R3 升级的前提（必须四条全满足）

L0 框架完整就位 —— archtest / contract / 质量基底全部 enforced
DevOps 全栈到位 —— 秒级回滚 + canary + 健康度三维 + on-call
审查 agent 独立 —— 与编码 agent 用异质模型，避免裁判即选手（呼应 §9.5.5 反模式）
决策审计完整 —— 每个 AI 自治决策可结构化查询，事后可复盘

满足后 R3 演化路径：

v7 初始 R3：AI 提议 + 人审
   ↓ 满足前提后
v7+ R3：AI 提议 + 独立 AI 审查（多 agent 互审）+ 健康度兜底 + 可回滚
   ↓
R4/R5：永远不变 — 人审 / 永不放开

本节回答：把”人审”从一个固定角色变成一个可被工程化升级的瓶颈——前提是框架强约束 + 多模型异质 + 健康度兜底全部到位。

10.6 模块即商品 — patch 与 replace 的经济学

模块是框架机床上批量冲压的商品。在质量基底约束下，“修复”不再是默认选项 —— “重写整个模块”往往是更经济的修复方式。

为什么以前是”修复优先”

传统软件工程默认 patch 而非 replace，原因是：

模块平均开发成本 = 数人周
重写 = 重新付出整个开发成本
重写失败的风险 ≥ patch 失败的风险

为什么 v7 之后可以”替换优先”

替换的合理性来自两类前提：基础设施层（能力是否具备）+ 触发层（什么情况下该启动）。两类必须同时满足，否则替换要么不可行，要么沦为反模式 A8「替换不反哺」。

基础设施层（必要条件）：

前提	对成本的影响
L0 框架强约束	模块从骨架生成器启动，复用框架中的 SDK / 契约 / 测试基底 → 重写成本 ↓ 70%+
L2 intent 完整可执行	intent.yaml 是模块的”DNA” —— 重写本质是”按 intent 重新让 AI 生成一份”
L3 多 agent 编队	同一 intent 由 N 个 agent 并行重写 → 择优合并（§9.5）→ 重写时间从天降到小时

触发层（变化驱动）：

触发	含义
framework 已演进	L0 v1 → v2 引入新抽象 / 新 SDK / 新契约 → 老模块必须重写才能利用新框架的精度
intent 已演进	业务变化导致 intent 修订（intent v2）→ 重写本质是”按新 intent 重生”，patch 已无意义

⚠️ 触发层缺失则替换是反模式：如果 framework 与 intent 都没演进，”替换”就是把同一个模块换成同一个模块——这正是反模式 A8「替换不反哺」与 §10.6 反模式「替换不动 intent」的核心症状。

reconcile 决策点：patch、replace、还是 harvest

when drift detected:
    if drift_localized AND patch_cost < replace_cost:
        propose PATCH                       # 传统路径
    elif framework_drifted_significantly OR  # 触发层（必须有演进）
         intent_has_changed_substantially:   # 触发层（必须有演进）
        propose REPLACE                      # 新路径
                                             # 走同一 R 梯度（§10.5）
                                             # REPLACE 后必须 harvest（下一节）
    elif module_age > 6mo AND patch_count > 10:
        # 老模块累积补丁，但 framework / intent 都没演进
        # 提示「演进策展人」（§13.2）评审 —— 是否该升级 framework / intent
        signal: refactor_pressure

反哺引擎：替换的真正价值不在新模块，在反哺上层

模块替换（REPLACE）
       ↓
N 个 agent 并行重写 ────► 候选 1 / 候选 2 / ... 候选 N
       ↓
       ├──► 择优合并（§9.5.2）— 选 1 个上线
       │
       └──► harvest（§9.4 步骤 7）— 提取候选差异 / 互审发现 / 偶发新方案
                ↓
                ├──► framework 升级队列：候选间共性的边界违反、缺失的抽象
                ├──► intent 修订草稿：候选差异暴露的 intent 不完备处
                └──► 范式候选库：单个 agent 的偶发新解
                ↓
        演进策展人（§13.2）评审
                ↓
        通过 → framework / intent 升级 → 下一轮模块从更精密骨架启动

关键洞察：单 agent 替换 = 修复一个 bug；多 agent 替换 = 系统进化一次。框架是机床、模块是商品 —— 商品坏了不只换商品，机床也在被改良。这是 §4.1 反哺循环的核心机制。

反模式（§10.6 内部 4 条）

替换上瘾 —— 任何 bug 都重写：放弃了 patch 在小变更上的成本优势
替换不动 intent —— 重写但 intent.yaml 没改：同样的需求会写出同样的 bug
替换跨过审查 —— 把 replace 当作 R0 自动执行：replace 的代价 ≥ patch，必须走同一 R 梯度
替换不反哺（A8 · 全局反模式 · 详见 §12）—— REPLACE 完事，候选差异 / 互审发现 / 偶发新方案不进 harvest 队列：替换沦为单纯的”重新生成一遍”，错失了系统进化的机会

本节回答：模块的可替换性是 v7 之后的新工程经济学。但真正改变工程经济学的不是”商品可换”，而是”商品被换时反哺机床”——这是 §4.1 反哺循环的活性来源。

11 · 全景闭环 · 订单团购案例

L0 → L1 → L2 → L3 不是阶段，是协作 —— 同一时间，每一层都在工作。

11.1 一个需求从声明到上线

┌────────────┬────────────┬────────────┬────────────┬────────────┐
│ STEP 1·L2  │ STEP 2·L3  │ STEP 3·L0  │ STEP 4·L3  │ STEP 5·L1  │
│            │            │            │   GATE     │            │
├────────────┼────────────┼────────────┼────────────┼────────────┤
│ 人写意图    │ Agent 接手  │ 门禁+测试   │ 人审 PR    │ 上线        │
│ "团购下单"  │ 读取 intent │ CI/CD      │ R3·跨域写  │ 进入状态机   │
│ + p99 200ms│ 分解任务    │ 契约校验    │ 5个证据    │ 候选→资产   │
│            │ 写代码      │ 3次失败→自修复│ 一键放行   │ 持续观察30d │
├────────────┼────────────┼────────────┼────────────┼────────────┤
│ 3 分钟      │ 22 分钟     │ 9 分钟      │ 5 分钟      │ 持续        │
│ 人 · L2    │ AI 自主     │ 系统 · 自动 │ 人 · 守门  │ 系统 · 自演化│
└────────────┴────────────┴────────────┴────────────┴────────────┘

TOTAL · 39 MIN HUMAN-BLOCKING + ∞ SYSTEM-AUTO
对比 · 同样需求·传统流程：3 周排期 + 4 次会议 + 2 次返工

11.2 每一步都在哪一层工作

Step	主要在	同时还在
1 写意图	L2	L0（intent file 经 schema 校验）
2 Agent 接手	L3	L1（读取当前 signals） + L0（沙箱执行）
3 门禁测试	L0	L1（健康度更新）+ L3（drift loop 监控）
4 人审 PR	L3 守门	L0（CI 数据作为审批证据）
5 上线	L1 状态机	L3（持续 reconciliation）

11.3 关键洞察：协作 ≠ 阶段

传统瀑布模型把 L0-L3 视为前后依赖的阶段——必须先建好 L0 再到 L1。v7 的视角是协作：

L0 是 24×7 在跑的地基，每次 PR 都在用它
L1 是 24×7 在更新的状态机，模块每秒都在产生新信号
L2 是开发者每写一个 intent 就在用的声明层
L3 是 24×7 在 reconcile 的 agent loop

同一时间、每一层都在工作——这才是”系统自收敛”的真实形态。

11.4 案例的产出

维度	传统流程	三跃迁全景闭环
人阻塞时长	3 周 + 4 次会议 + 2 次返工	39 分钟
决策记录	散落在 Jira / Slack / 邮件	intent 文件 + 决策审计存储
上线后追溯	凭记忆	trace_id + 健康度三维 + 状态机
退役判断	没人敢动	sunset_if 自动触发

本节回答：全景闭环是检验整套体系是否真跑通的唯一标准——能在 39 分钟内走完一个真实需求。

12 · 反模式与边界

每个跃迁都有失守模式 · 知道边界比知道方法更重要。

12.1 反模式按”阶段 × 后果”二维分布

后果 ↑                              ANTI-PATTERNS
CATASTROPHIC                                       ┌─────────────┐
                                                    │ A3 梯度失守 │
                                                    │ R4/R5 也交  │
                                                    │ AI · 灾难    │
                                                    └─────────────┘
SYSTEMIC               ┌─────────────┐
                       │ A2 意图≠执行│
                       │ 写而不验    │
                       │ 声明沦装饰  │
                       └─────────────┘
REVERSIBLE  ┌─────────────┐
            │ A1 治理过度 │
            │ 门禁 > 编码  │
            │ 实验全门禁  │
            └─────────────┘
              L0          L1          L2          L3 →
              引力场      状态可见     意图可表达   系统自收敛

                     ↗ 越高阶 · 失守代价越大

12.2 八大反模式（融合 v3 + v7 + 反哺循环）

#	反模式	症状	矫正
A1	治理过度	实验模块也跑全门禁；治理时间 > 编码 30%	严格分级，宁宽勿一刀切
A2	意图 ≠ 执行（写而不验）	intent.yaml 没人检查；声明沦为装饰	字段绑定验证器（§7.3）
A3	梯度失守	R4/R5 也交给 Agent；不可逆灾难	R5 永不放开；R4 强制人决策
A4	信号填空	让人手填业务信号	必须机械化采集
A5	AI 建议崇拜	接受率 100%、否决率 0%	健康否决率下限 ≥ 10%
A6	状态机僵化	模块卡某态半年不动	加”超期未迁移”告警
A7	审批仪式化	不看证据点同意	强制勾选证据已查验
A8	替换不反哺	REPLACE 完事，候选差异 / 互审发现 / 偶发新方案不进 harvest 队列；framework / intent 长期不更新即使有信号	reconciler 的 REPLACE 路径强制含 harvest 步骤（§9.4 步骤 7）；演进策展人（§13.2）每周评审 harvest 队列；framework / intent 月度演进率纳入北极星指标（§14.2）

12.3 不在治理范围

不要试图让本方法论解决以下问题：

业务方向错误 —— 再好的治理也救不了”用正确的方式做错的事”
组织协作问题 —— 本方案治理的是制品，不是会议、流程、人际
创意性研究代码 —— 探索/原型/创新无法重武装

这些是人的领地。

12.4 何时停止推进

任一信号出现，停在当前层级而非推进到下一跃迁：

治理活动 > 30% 工程师时间持续两季度
误警率 / 误退役率持续高于目标
团队 < 10 人且模块 < 30（治理 ROI 倒挂）

本节回答：边界感是这套体系存活的前提——治理本身也要被治理（§14.4）。

13 · 角色演化

劳动力流向更高价值的地方。AI 不是来替代工程师 · 是来解放工程师。

13.1 工程师时间分配的迁移

TODAY · 异化劳动                       TOMORROW · 创造劳动
75% 在低价值环节                       100% 在高价值环节

┌─────┬───────────────┬─────┐       ┌─────────────┬─────┬─────┐
│设计 │ CRUD·改typo   │会议 │       │系统设计·意图│守门·│研究·│
│25%  │ 调依赖 50%    │25%  │  ─►  │定义 50%      │审计 │探索 │
│     │               │     │       │              │25%  │25%  │
└─────┴───────────────┴─────┘       └─────────────┴─────┴─────┘
高 V · 低 M（异化）                    高 V · 高 M（创造）

13.2 四个新角色

每个团队都需要：

#	角色	职责	来自哪个支柱
01	框架建筑师 (Architect)	设计 L0 引力场；规则即资本	L0 凝结资本
02	意图设计师 (Intent Designer)	写 intent 文件；把业务翻译成声明	L2 跃迁②
03	外壳工程师 (Harness Engineer)	建 Agent 工程外壳；管心跳节奏	L3 跃迁③
04	AI 决策审计员 (Auditor)	独立于调优工程师；守 R3-R5 红线	R 梯度边界
05	演进策展人 (Curator)	评审反哺循环（§4.1 / §10.6）的 harvest 队列：从候选差异 / 互审发现 / 偶发新方案中筛选哪些进入 framework 升级、intent 修订或范式库	反哺循环的把关者

13.3 AI 决策审计员的独立性

关键原则：AI 决策审计员必须独立于 AI Agent 调优工程师——避免裁判员兼运动员。这是当 AI 自主权进入 R3 跨域写入级别时才必须设立的角色。

13.3a 演进策展人 — 反哺循环的把关者

为什么需要这个角色：反哺循环（§4.1）让模块替换的副产品（候选差异 / 互审发现 / 偶发新方案）持续涌入 harvest 队列。但不是所有 harvest 都该进 framework——盲目纳入 = framework 膨胀失控。需要一个角色周期性评审 harvest 队列，决定：

哪些共性问题入选 framework / CI / archtest 改进队列
哪些 intent 不完备处入选 intent 修订草稿
哪些偶发新方案值得提炼为框架的新范式

和审计员的区别：审计员守边界（R3-R5 不被越界），策展人选演进方向（framework / intent 该往哪走）。两者互补，不冲突。

节奏：周评审 harvest 队列；月评审 framework 升级队列；季度评审 intent 修订草稿。

13.4 资本论视角下的劳动力流向

AI 自主度提升 = V 被 C 替代。释放的 V 必须流向更高价值区域，否则就是”被替代”而非”被解放”：

跃迁	释放的 V	应流向的高价值 V
L0 → L1	模块标记的人工劳动	框架建筑 / 规则制定
L1 → L2	健康度巡检与初筛	健康度模型设计 / 意图设计
L2 → L3	实验模块运维	寿命规则设计 / 回滚机制设计
L3 → 反哺循环	模块代码维护	演进策展（从 harvest 中选范式入框架）
远景	大量审批劳动	战略 / 安全 / 伦理守门

本节回答：角色演化是对”AI 取代工程师”恐惧的工程化回答 —— 不是取代，是迁移到更高价值。

14 · 度量框架

怎么知道在变好。

14.1 北极星指标

资产健康率 = 三维健康度全 ≥ 60 的资产模块数 / 全部资产模块数

这是单一最值得追踪的指标——同时反映价值/结构/工程三支柱的状态。

14.2 各跃迁的次级指标

跃迁	次级指标
L0	治理覆盖率 / 门禁有效性 / CI 全绿率
L1	模块 manifest 覆盖率 / 健康度三维趋势 / 状态迁移率
L2	intent 文件覆盖率 / 字段验证器绑定率 / drift 检出率
L3	AI 建议接受率 / 误警率 / R 梯度违规次数 / 自动退役回滚率
反哺循环	framework 演进速度（季度新抽象数 / 老抽象退役数）/ intent 修订率（成熟意图被 v2 替代的比例）/ 反哺命中率（harvest 队列中真正被采纳到 framework / intent 的比例）

反哺指标的健康水位：

framework 演进速度：1-3 次 / 季度（太低 = 演进断流；太高 = framework 不稳）
intent 修订率：5%-20% / 季度（太低 = intent 与业务脱节；太高 = intent 不该写得太具体）
反哺命中率：20%-50%（太低 = harvest 噪声大；太高 = 演进策展人筛选不严）

14.3 DORA 五指标接入

DORA 指标	治理含义	高性能水位
Deployment Frequency	模块迁移流速	日多次
Lead Time for Changes	单模块端到端工程效率	< 1 天
Change Failure Rate	治理质量	< 5%
Failed Deployment Recovery Time	回滚机制有效性	< 1 小时
Rework Rate（2024 新增）	manifest / intent 质量	↓ 趋势

14.4 季度评审节奏（治理本身的治理）

每季度对方法论本身评审：

哪些信号被证明无效？
哪些门禁拦截的全是误报？
哪些状态迁移规则让团队感到僵化？
哪些反模式实际从未出现，可以从清单删掉？

方法论本身也要进入治理 —— 不能成为不可触碰的圣物。

14.5 治理是必要的监督劳动（边界条件）

按马克思的判断标准：监督劳动是”灰色地带”——是否生产性，取决于是否直接为资本积累创造价值。

治理是生产性的，当且仅当：
    M_保留 = 因避免衰减而保留的剩余价值 ≥ V_治理 = 治理本身消耗的活劳动

违反此边界 → 触发 §12.4「何时停止推进」。

本节回答：度量框架给整个方案一个可测、可批判、可被推翻的对外接口。

15 · 未来形态（2030+）

软件不再”被维护” · 它持续演化。工程师不再”写代码” · 他们守护一个会自己生长的系统。

15.1 自治系统的四个轨道

                       SELF-EVOLVING
                          自治系统
                  Code as Living Infrastructure
                        ●
                       ╱│╲
              ┌─HUMAN ╱ │ ╲ AI ─────┐
              │描绘意图   │   自主收敛│
              └────────  │  ────────┘
                         │
              ┌─SYSTEM   │   VALUE──┐
              │持续演化   │  复利累积│
              └──────────●──────────┘

self-evolving 的具体机制 = 反哺循环（§4.1 / §10.6）：framework 与 intent 不是被设计一次然后冻结的——它们通过模块替换时的 harvest 步骤持续吸收反馈，由演进策展人（§13.2）筛选后升级。复利累积来自这个循环：每一次替换让下一次替换的起点更高。

15.2 不承诺时间表

阶段四（完整自治）的进入条件极严：

持续运行 ≥ 6 个月零重大事故
行业出现成熟的 AI 决策可解释 / 可审计技术
组织已建立独立的 AI 决策审计员角色

任一未达不进入。这不是路线图条款，而是对”过早收尾”的防御。

15.3 永恒红线

无论自治程度多高，R5（资金 / 物理 / 用户不可逆影响）永远不进入自动化范围。这是系统的边界条件，不是阶段问题。

本节回答：未来形态描绘的是方向，不是承诺——方向比时间表重要。

16 · 价值终章 · 企业 / 个人 / AI

这一切是为了什么。

三个主体·三种 work 哲学：

16.1 企业 · COMPOUND · ACCELERATE

资产复利 · 反熵增

资产健康率取代代码量·成为新北极星
交付速度恒定·不随代码库年龄衰减
故障率 ↓ 50% · onboarding ↓ 60%
反哺自己·业务专家直接优化系统
framework 不是被设计出来的，是被演进出来的 — 反哺循环（§4.1）让 framework 与 intent 在每一次模块替换中累积智慧，复利来自这个循环

16.2 个人 · LIBERATE · CREATE

work everywhere · every status

work everywhere · 工位带到任何地方
work every status · 任何状态都能产出
有时间深入业务 · 真正了解用户
各行业工作者都能优化自己的系统·反哺企业与国家

16.3 AI · AMPLIFY · NEVER REPLACE

work everytime

7×24 不休息
在沙箱中 做可逆尝试
守门并执行 而非决策
放大人 而非取代人

16.4 终极命题

AI 不是来替代工程师 · 是来解放工程师。

让 AI 能加速产出而不让组织失去对资产的把握，是这个时代软件工程的根本命题。

本方法论的答案：人在期望状态定义环路里，AI 在持续收敛执行环路里。

附录 A · 资本论 C/V/M 映射

提供一个独立的”价值流”视角，判断治理动作是否生产性。

A.1 三概念在 AI 软件工程中的精确映射

Marx 概念	传统软件工程	AI 时代演化	治理含义
C 不变资本（凝结劳动）	框架 / 基础设施 / 契约骨架 / 代码库	+ 预训练模型 / 向量库 / 评估集	C 越精密，模块产出的精度越高
V 可变资本（劳动力）	工程师工时	工程师 + AI 工具的劳动组合	AI 是 V 的倍增器（同等 V 产出 N×）
M 剩余价值（资产沉淀）	用户付费 + 可信代码资产	同上 + 评估反馈数据	M 被三衰减侵蚀
W 总价值	C + V + M	C + V + M	等式不变，结构变

A.2 关键命题：AI 不是新的价值源泉

劳动价值论的核心命题：只有活劳动（V）创造新价值。AI 是凝结的过去劳动（属于 C），它转移自身价值到产品中，但不创造剩余价值。

两个对称推论：

把 AI 当作”新的程序员”是错误命题——AI 是机床，不是工人
高估 AI 自治 = 把 C 误认为 V → 组织失去价值创造的意识源泉
低估 AI 倍增 = 没用足生产资料 → 组织在产能上被对手甩开

A.3 L0 = 凝结度最高的 C

参见 §4.1 / §4.7。框架是组织最高阶架构智慧的凝结，沿模块的批量复制无限放大。

A.4 三衰减 = M 被熵增吞噬

衰减	资本论解读
价值衰减	已沉淀的 M 因业务变化失去市场承认
架构衰减	已沉淀的 M 因架构腐烂需要重写
知识衰减	已沉淀的 M 因人员流动需要重新理解

治理是对抗熵增的工程化机制——把 M 从”易腐”变为”长期”。

附录 B · V-model 在 AI 时代的变形

把抽象的”质量涌现”落到 V-model 的具体形态。

B.1 变形图

       左侧（AI 加速）              右侧（重武装验证）

           意图定义  ────────────────►  端到端验收
              ↓                              ↑
           架构设计  ────────────────►  集成测试 + 契约校验
              ↓                              ↑
           详细设计  ────────────────►  单元测试 + 形式化验证
              ↓                              ↑
       ┌──────────────┐                       │
       │ AI 编码(秒级) │ ─────────────►  静态分析 + 模糊测试
       └──────────────┘                       │
              ▲                                │
        【加速 100×】                  【验证重武装 3×】

B.2 变形逻辑

传统 V-model 假设左右两侧人力对称——一个开发者写一个测试。AI 时代左侧加速 100×，若右侧不重武装，故障率必然 3× 飙升（Sonar 调研数据）。

V-model 在 AI 时代的本质重写：左侧编码价值 → 右侧验证价值。验证不是事后补救，而是 V 流向 M 的核心通道。

B.3 SWEBOK v4 新增 KA 在三跃迁中的位置

新增 KA	在三跃迁中的位置
Software Architecture	L0 框架的载体，决定 AI 产出精度上限
Software Operations（DevOps）	L0 第 5 支柱（DevOps 全栈）
Software Security	L0 第 3 支柱（CI 门禁中的 sec scan）+ R 梯度的安全约束

附录 C · CALMS · DORA · 看板（流的执行节奏）

C.1 CALMS 在 AI 时代的重新定义

支柱	传统 DevOps	AI 时代
Culture	dev/ops 协同	+ 人/AI 协同（信任校准）
Automation	部署自动化	+ AI 决策自动化（受 Harness 约束）
Lean	消除浪费	重点是淘汰”AI 产出的低价值代码”
Measurement	DORA	DORA + 三维健康度
Sharing	知识沉淀	+ AI 决策审计日志

C.2 利特尔法则破解 AI 产能瓶颈

核心问题：AI 日产 50 个函数，团队日审查 10 个 → 积压 → 漏检率飙升。

利特尔法则公式：

平均周期时间 = WIP / 吞吐量

应用：若想保持 < 1 天审查周期，团队日审查能力 = 5，则 WIP ≤ 5。

C.3 分层快速通道（拉式系统）

按 R 梯度调度审查 WIP：

层级	风险	WIP	决策方式
L1 低风险（90% 自动化测试通过）	R0-R1	20	AI 主导，人抽查 10%
L2 中风险（新特性）	R2	10	AI 起草 + 人审查
L3 高风险（安全/并发/外部接口）	R3	3	专家 + 形式化验证

加权 WIP：高风险卡片占用审查时间 ×2，自动调控。

C.4 看板六实践（David J. Anderson）

Visualize：双环看板可视化（意图环 + 模块环）
Limit WIP：WIP 上限（C.2 核心）
Manage Flow：流速监控（接 DORA Lead Time）
Make Policies Explicit：差异化门禁的策略明文化
Implement Feedback Loops：reconciliation loop（§9）
Improve Collaboratively：季度评审（§14.4）

附录 D · MDM 声明式范式跃迁

D.1 命令式 → 声明式

范式	形态	代价
命令式	人决定何时迁移	人成为瓶颈
声明式	manifest 声明期望，系统持续 reconciliation	一次设计、永久运行

这是 v3 → v7 最深的范式跃迁——治理从”人在决策环路里”变成”人在期望状态定义环路里”。

D.2 Apple DDM 2024+ 的三要素

要素	定义	在三跃迁中的实现
Declaration	管理者定义的 desired state manifest	L2 intent file（§7.1 四块结构）
Reconciliation	设备拉取 manifest 并自动收敛	L3 reconciliation loop（§9.4）
Convergence	持续强制：断网仍维持期望状态	三维健康度持续回写 + 软删窗口

D.3 Harness + DDM 的统一

        ┌──────── 期望状态（intent file）────────┐
        │     由人定义意图、契约、约束、健康阈值   │
        └────────────────────┬────────────────────┘
                             ▼
        ┌──────────────────────────────────────────┐
        │       Reconciliation Loop（持续收敛）     │
        │                                          │
        │   ┌──────────┐         ┌──────────────┐ │
        │   │ 信号采集  │ ◄─────►│ Harness 五件套│ │
        │   │ (机械化)  │         │              │ │
        │   └──────────┘         └──────────────┘ │
        │         │                       │        │
        │         ▼                       ▼        │
        │   ┌─────────────────────────────────┐    │
        │   │   执行修正（按可逆性 R0-R5）     │    │
        │   └─────────────────────────────────┘    │
        └──────────────────────────────────────────┘
                             │
                             ▼
                       现实状态收敛

核心命题：Harness + DDM = 环境级反馈控制系统。两者本质同构，都是从”命令式单次干预”转向”声明式持续收敛”。