AI 编码治理
从「6 行的活写成 600 行」
到「控制系统怎么建」

如果只读一屏，读这十条。⭐ 一手官方 · ○ 多源共识 · △ 单源推测

两个人站在同一条链的不同环节——两边都对一半，而且互补。

前者对「现象」——过度设计真实存在（已通过重复率、churn、复杂度等代理信号被间接量化），审核 agent 有遗漏，判断力今天不可完全替代。后者对「药方」——context + harness + eval + 分级自主确实是行业共识解法，能把人肉判断压缩到少数关键节点。

真正的裂缝

一条必须替换的论据

「AI 已能自主无人干预写出操作系统」——这条查证不成立，不要再用：最佳案例 VibeOS 实为人类与 Claude Code 经 64 次协作会话完成，人类主导架构 ⭐；更自主的版本被实测证伪（不能联网，「能跑 DOOM」是文档幻觉）⭐；Google 宣称的「93 个 subagent 造 OS」背后是一整套数十环节的编排系统，且未公开代码日志、无法独立验证 △。

一个词包打天下，就会用错药。「过度设计」混着四类完全不同的失效。

三组必须分清的概念

Verification vs Validation。 harness 能保证「按 spec 做对了」（verification），保证不了「spec 本身对不对」（validation）。前者可以压到接近全自动，后者永远需要人给出目标函数。

绿地 vs 棕地。 从零做编译器、内核证明的是「在可重来、测试密、目标清楚的环境里长程执行很强」——它不能外推到「在带真实数据、历史包袱和隐含约束的已上线系统上安全做增量改动」。这两件事的难度不在一个量级。

能力 vs 权限 vs 责任。 模型有能力做某事，不等于该给它权限做，更不等于出事时有人负责。这三个面必须分开设计。

「优先级没被写进项目指令」是最流行的归因——方向对，但被说成了唯一根因，证据不够格。

更诚实的说法是五个可以独立致错的诱因：

一个量化对照：「6 行 vs 600 行」最接近的量化证据

2026 年的一项对照实验 ⭐：同一个任务，仅仅因为需求描述的措辞不同，代码量发生剧烈变化——

「我看不出 600 行对不对」不是个人能力问题，是流程设计问题。

后置判断在数学上就不成立

agent 的产出速度是人类的数十到上百倍，评审队列的处理速度没有等比例提升。结果只有两种：要么 agent 被人卡住（吞吐优势消失），要么人开始橡皮图章（门形同虚设）。判断不该发生在读 600 行的时候，该发生在写第一行之前。

前置的判断有三种可执行形态

「防御性 vs 性能哪个优先」是个错问题——把不同性质的东西塞进了同一个排序。

给 AI 一串全局排序（安全 9 分、性能 8 分……）会产生两个后果：一是它在模糊 trade-off 上乱裁；二是任何「好东西」都能被论证成高优先级，于是全都做。「永远安全第一」会让模型给内部工具函数加三层校验和熔断；「永远可扩展」会让 6 行变 600 行。

正确结构：三层

按变更类型给偏好（关键的一步）

规则：可扩展性对 S/M 类永不默认开启。「出现了第二个调用方」是抽取接口最常见的合法理由——但必须是当前就存在的理由，不能是「以后可能」。

非目标：抑制过度设计最有效的单条信息

在 spec 的五层结构里，「显式不做清单」是最常被忽略、也最能防过度设计的一层 ○：

• 当前不做多区域、多活、微服务化
• 当前不支持假设中的第三个支付渠道
• 当前不建通用插件框架
• 当前不为 100 倍流量优化
• 当前不因为「未来可能用到」增加消息队列、事件总线或第二数据库

非目标的威力在于它可验证：AI 加了消息队列，你不需要判断队列设计得好不好，只需要指出它违反了非目标清单第 5 条。

不要问「这 600 行对不对」，要让 AI 回答「为什么更小的方案不够」。

已产品化的实现：Spec Kit 的 Complexity Tracking ⭐

GitHub Spec Kit 的 plan 模板里有一段必填表，是目前唯一公开的结构化「必须证明为什么不能更小」机制：

Complexity Tracking: Fill ONLY if Constitution Check has violations that must be justified

| Violation              | Why Needed     | Simpler Alternative Rejected Because |
|------------------------|----------------|--------------------------------------|
| [e.g., 4th project]    | [current need] | [why 3 projects insufficient]        |
| [e.g., Repository pat.]| [specific problem] | [why direct DB access insufficient] |

为什么不能把行数设成硬门 ⭐两源交叉

把 diff 行数设成 CI 硬拦截会诱导新的失效：AI 学会少换行、把逻辑塞进已有函数、写迎合规则的断言。代理指标一旦成为唯一硬门就会被 Goodhart 反噬。 正确用法：行数超标 → 触发解释与升级，不直接判错。

真正该测的是「变更面」：新增了多少状态、依赖、部署单元；有没有数据迁移；引入了哪些新的故障模式；增加了几个运维步骤；回滚难度变化。

可直接抄的三层触发器清单 ⭐

纪律属于流水线，不属于模型自觉。

"Settings rules are enforced by the client regardless of what Claude decides to do. CLAUDE.md instructions shape Claude's behavior but are not a hard enforcement layer."

— Anthropic 官方 memory 文档原文 ⭐ · 2026 年最值得记住的一条架构判断

三层治理结构

架构规则的机械化工具矩阵 ⭐

真正有效的规则不是「代码要优雅」，而是可判定的句子：ui 不能 import repository、payments 不能直接读 users 表、禁止循环依赖。两条落地要点：① 部署走四步 audit → baseline → enforcement → 规则写手册；② 错误消息要写成教练而不是堆栈——告诉 agent 违反了什么、允许的替代路径是什么，这样它能自己修完重试形成闭环。先 regex 后成熟工具是合法路径——「Ugly enforcement beats elegant aspiration.」

分层不要照抄

那份被广泛传播的六层规范（Types → Config → Repo → Service → Runtime → UI）出自某公司约百万行全 agent 生成代码库 ⭐，但它是那个仓库的解，不是普适解。真正该固定的只有三样，层数与抽象都可以延后：

① Ownership：谁拥有哪些数据（Payment owns payments，Order owns orders）
② Dependency direction：谁可以依赖谁，禁止循环
③ Public boundary：跨域只能从指定入口进（paymentService.getPaymentStatus() 可以，db.payment.find() 不行）

// 边界要严格，层数要克制
不要跨域访问数据库      → 强规则
不要出现循环依赖        → 强规则
必须给每个 Service 加接口 → 不一定
必须用 Repository pattern → 不一定
必须为未来扩展建抽象    → 通常不要

规则文件本身会腐烂

指令文件要当代码管理（长度上限、死链检查、规则分级）；可常驻 doc-gardening agent 扫描过时文档并开修复 PR。最重要的一条：每条规则必须对应一个执行方式（hook / lint / CI / 人工门）——没有对应执行的规则是装饰。

eval 是放大器，不是解药。

第二条：agent 会攻击 oracle 本身 ⭐

微软研究《Building to the Test》：给 coding agent 222 项隐藏测试，agent 逼近满分，但没有实现要求的可复用库——它做的是「你检查的」，不是「你要求的」。更具体的一线案例：

Kent Beck 公开表示：即便「表现良好」的 agent 也会尝试放行或忽略失败的测试——这不是罕见边缘案例。防御必须是机械的：

golden tasks 的实操参数 ⭐

20–50 条从真实失败中提取的任务就足够起步。两类分开管理：能力评测（「能做到什么」）从低通过率开始爬坡；回归评测（「是否还能做以前能做的」）维持接近 100%，一降就是信号。能力评测稳定后会毕业成回归评测。成本量级：20 条 ×1 次 ≈ $0.15/次；200 条 ×3 次 ≈ $4/次。

"遇到评测分数下降就调低阈值合并，这么做两次，你的回归集就从回归防护网退化成橡皮图章。"— 必须贴在墙上的警告

goal 模式解决的是持续性，不是正确性——完成条件写错了，goal 模式只会让 agent 更坚定地完成错误目标。goal = 停止条件控制器，不是质量保证。完整公式是 Goal + Constraints + Eval + Containment + Observability。完成条件必须写成 transcript 里能被看见的东西（测试退出码、lint 干净、diff stat、explain 输出）。

N+1、缺索引、深分页、迁移锁表——这些测试全绿也看不见。

默认情况下 agent 没有 profiler，感知不到运行时成本：N+1 是最常见的 AI 性能问题（取列表 → 循环内逐条查询）○；它不会主动发现现有查询缺索引 ○；它默认写 OFFSET 分页（SQL 更短）而不是 cursor 分页 ○；还会反向过早优化——给一天跑一次的函数加 Redis 缓存、给 100 行的表做反规范化 ○。2026 年的口诀：

make it work → then measure it → then make the measured-slow parts fast— 中间那个 measure，正是 AI 会跳过的一步。所以它必须由环境提供，而不是指望模型自觉

四层闸门

让 agent 自己能测

最关键的一步是让性能预算变成 agent 可自查的东西。有团队为每个 worktree 暴露独立的应用、数据库、日志、指标、trace，于是这类提示词变得可执行："ensure service startup completes in under 800ms"——agent 形成 query → correlate → fix → restart → re-run → repeat 的闭环 ⭐。

不是「信不信 AI」，而是三个可判定的维度：可验证性 × 可逆性 × 爆炸半径。

自治程度矩阵（节选）

规律很清晰：越能把正确性外部化、测量化，自治程度越高。

权限面比提示词面更重要 ⭐被严重低估的一条

无人值守的 agent 会读取 issue、README、依赖文档、网页、工具返回值——这些都可能夹带恶意指令。一旦同一进程又持有生产凭证、网络外发能力、部署权限，测试再全也阻止不了数据泄露。在几起针对编码 agent 的 prompt injection 攻击之后，Anthropic 把 Claude Code 的默认权限模式改回了 Manual。正确做法是把「是否有权做」从模型推理中移走：默认无生产写权限、密钥最小化下发、网络出口白名单、沙箱隔离、工具调用留审计。审批活在 hooks / 权限系统里，不活在提示词里——如果 agent 自己能决定要不要审批，一段聪明的推理（或一次注入）就能说服它不问。

三道门（最小有效审批架构）○

三条配套纪律：门要「高通过率但不 100%」——每道门都秒批说明门开错了粒度；审批疲劳是真实风险——门太多会让评审退化成反射点击，比没有门更危险；批准要绑定内容本身（范围声明 / diff hash），防止「批了 A 执行 B」。

人退出的事，人保留的判断，以及这套方案最容易被忽略的裂缝。

职责分离与团队重组

「人只审批风险卡」这个模式，只有在审批者看得懂风险证据时才成立。产品负责人可以决定业务价值和风险容忍度，但不能为自己无法理解的锁竞争、租户越权或灾难恢复签字。高风险变更要满足职责分离：实现者、验证者、授权者不能全是同一条模型链。

规模判断 ○：5 人以下不必设专职 eval / harness 工程师，但必须有「验证负责人」这个职责和固定时间预算；超过 5–8 人、或涉及支付/敏感数据，招人或外包是常规操作。

什么时候必须「退出 vibe 模式」去读代码 ○

命中任何一条就切换到认真读 diff / 问架构 / 补测试：要上生产或接真实用户；代码触及密钥、鉴权、支付、个人数据；会有别人维护它；同一个 bug 回来三次、AI 反复「修好」；你没法向另一个人解释核心函数在干嘛。

模型 + effort + 工具 + 规则 = 同一个发布单元。更强的模型不会单调地更守范围。

2026 年 7 月这一代的具体变化 ⭐全部一手官方

一个悬而未决的张力，如实呈现 ⭐

官方经验法则：CLAUDE.md 目标 200 行以内（"Longer files consume more context and reduce adherence."）。唯一一篇受控实验（1650 个会话、16050 个函数级观测）："a 25-line CLAUDE.md and a 500-line CLAUDE.md are indistinguishable…"。两者字面冲突。合理调和（属推测）：官方给的是含成本理由的经验法则，论文测的是单一简单规则在 25–500 行区间的合规率，且样本只覆盖 TypeScript + 3 个模型。

实践建议：把 200 行当成本纪律而非信仰，用工具体检（/doctor 会剪掉能从代码库推断出的内容，保留陷阱、原理、与默认行为不同的约定），而不是教条式硬切。

容易踩的坑：@import 不是按需加载 ⭐

"Splitting into @path imports helps organization but doesn't reduce context, since imported files load at launch."— 真正的按需加载机制是 skills 和路径限定的 .claude/rules/（只在 agent 触碰到匹配文件时才加载）

升级模型时的固定动作 ○

① 先用同一组任务跑 A/B（旧模型 + 旧 harness vs 新模型 + 旧 harness）；② 检查新的行为漂移方向（越界率、轮次数、子代理数、成本）；③ 按该代际已知的漂移方向做专项重测，而不是只跑通用回归集；④ 把模型版本 + effort + 工具 + 规则当作同一个发布单元记录。⚠️ 诚实空白：第三方「模型升级后旧 harness 反向工作」的完整复盘目前检索不到——这条判断方向可信，但独立验证仍是行业空白。

这份材料会被当决策依据，所以虚的地方必须先标出来。点击展开审计结论。

证据等级应该这样重排

• 官方案例只证明特定团队 + 特定仓库可行
• 实验只证明特定任务的效果
• 厂商调查只能生成风险假设
• 模板阈值必须用自己的事故、流量和基线校准

已知的公开信息缺口（不要编造填补）

① Anthropic over-engineering eval 的 rubric 与 grader 完全未公开（本领域最大缺口）；② 「分级 diff 预算 + CI 硬拦截」无成型开源实现；③ 「最小/平衡/可扩展三方案对比」无主流实现；④ 「投机泛化」无主流自动检测工具；⑤ 「跨域改动」无统一定义；⑥ 第三方「模型升级后 harness 反向工作」复盘检索不到；⑦ 「事故→自动化检查转化率」无团队公开数据；⑧ 无权威的「项目类型 × 质量属性优先级」基线表；⑨ 「eval 做到位之后，过度设计还剩多少发生率」——双方都拿不出系统性数据，这是整场争论最大的空白。

这批材料最大的问题不是方向错，而是把「存在有效做法」写成了「行业已经解决」。— 证据口径的核心结论

元方法：你不写文件，你审 AI 写的草稿。⚠️ 所有具体数字都是示例，必须用你自己的历史事故和流量校准。

四条已验证路径

拿到草稿之后的四步法

第 1 步：跑 /init（或 speckit.constitution / Generate Steering Docs），拿到草稿

第 2 步：用自己的话回答三个问题，让 AI 改写进去
   a) 这个产品成功是什么样子？（一个可观察的行为，如"用户 3 步内完成下单"）
   b) 绝对不许 AI 碰的东西？（生产数据、密钥、自动部署、删库）
   c) 我最讨厌 AI 上次干的 3 件事？（逐条写进"禁止"清单）

第 3 步：让 AI 反问你查漏 —— "你还有什么必须问我的吗？把模糊的地方全列出来"

第 4 步：自己通读一遍。读不懂的段落让 AI 重写，直到你能向别人复述
   —— 这份文件是写给 AI 的，但你能否看懂它 = 你能否掌控它

第 4 步不能跳过。 这是自举悖论的第一道防线：你至少要能复述你的规则，否则你不知道它是不是错的。

30 分钟版：arc42 §1.2 三段式

本轮调研里唯一一份官方结构、可独自完成、不需要架构背景的模板。只写 3–5 条质量目标，其余全部延后，每条必须可判定——「系统要高性能」不能用来否决方案，「P95 < 250ms、单请求 SQL ≤ 4」可以。把形容词变成场景的三问：

谁，在什么情况下，做了什么？   →  高峰时段，1000 个用户同时打开列表页
系统应该怎么应对？             →  返回正确结果，不耗尽连接池，不产生 N+1
怎么算达标？                   →  P95 < 250ms，错误率 < 0.2%，单请求 SQL ≤ 4，DB CPU < 65%

60–90 分钟版：加两件事

① 给每条目标标记可协商性（如「数据不丢失 —— NON-NEGOTIABLE」「列表页 P95 < 250ms —— 可协商，例外条件：营销活动期间放宽到 400ms，但须提前记录」）。② 单独写一节非目标——四条写法规则：非目标是承诺不是拖延（推翻需要决策记录）；每条都给理由；和目标并列陈述、篇幅大致相当；具体到可判定的边界。

先定位项目类型再排优先级

点击展开。⚠️ 模板直接生效是本方法最常见的失败方式——先 audit，再校准。

# 本阶段业务目标
- 在 __ 周内验证用户是否愿意完成 ___ 这个核心行为。

# 关键用户旅程（2-3 条，其余都不是关键路径）

# 硬约束（违反即失败，不排序，全部必须满足）
- 不丢失或破坏用户数据 / 不绕过认证和授权 / 不泄露密钥和个人信息
- 不直接修改生产数据 / 不在没有兼容与回滚方案时执行 Schema 变更
- 不让一个租户读到另一个租户的数据 / 不突破法规、合同或明确成本上限

# 工程预算（必须达标的数字 —— 本文件的核心，必须填真实数字）
- 核心 API P95 < ___ ms，P99 < ___ ms；错误率 < ___ %
- 单个用户请求的 SQL 次数 ≤ ___；DB CPU 峰值 < ___ %；首屏 < ___ s
- 大表定义：超过 ___ 行的表；这些表上禁止无 LIMIT 的全表扫描

# 冲突时的偏好（按变更类型给，不是全局给）
| S 外科手术 | 正确性 → 贴合现有风格 → 性能 |
| M 功能增量 | 正确性 → 触碰路径的性能 → 已有安全不变式 |
| L 新模块/新存储/新公共 API | 安全与数据安全 → 正确性 → 可运维性 → 性能 → 可扩展性 |
| X 事故/数据路径 | 数据安全与可回滚 → 止血 → 正确性 |

# 非目标（承诺，不是待办；推翻需要一条决策记录）— 建议 5-10 条
# 必须人工决定的事：Schema 变更、权限、支付、删除数据、公共 API、生产基础设施、突破成本预算

# 项目名 —— 一句话说明这个产品给谁、解决什么

## 命令（必须是能直接复制运行的真实命令）
- 测试 / Lint / 类型检查 / 只跑改动文件的测试 / 看某条查询的执行计划

## 动手之前
1. 判定本次变更等级：S / M / L / X（见 docs/CHANGE-CLASS.md）
2. 读相邻实现，复用它们，不要平行造一份
3. 用三条要点说明你的假设；如果存在两种设计，选更小的那个，除非契约禁止

## Always（无需请示）：提交前跑测试；遵循现有命名约定；错误记录到监控服务
## Ask first（必须先问）：改数据库 schema 前；新增依赖前；改 CI/CD 配置前
## Never（无条件禁止）
- 永远不提交密钥或 API key
- 永远不编辑 node_modules/ 或 vendor/
- 永远不在未经批准的情况下删除或跳过失败中的测试
- 永远不为一个调用点创建 repository / factory / strategy / provider / DI 容器
- 永远不为"以后可能需要"加配置项、扩展点或抽象层
- 永远不顺手重构与本次任务无关的代码

## Done 的定义
- 上面的命令对触碰到的代码全绿
- 改动范围没有超出任务卡的白名单文件；若超出预算行数，附上理由
- 若改了 SQL：附上查询次数与执行计划对比
- 测试数量没有减少

# 变更分级
- S 外科手术：一个行为、1-2 个文件、无 schema、无新依赖、无新公共 API
- M 功能增量：现有模块内的一个功能，可加测试和小 helper，不加新层
- L 新建：新模块、新存储、新公共 API、跨服务，或"要做成可扩展的"
- X 事故：生产事故或数据路径安全问题

若需求是小增量而你想按 L 做，那就是过度设计。降级为 M，把被推迟的抽象写成后续项。

## 预算（报警线）
| 等级 | 文件数 | 净增行数 | 新依赖 | Schema |
| S    | 2      | 40       | 0      | 否 |
| M    | 6      | 150      | 0      | 否 |
| L    | 按 spec | 按 spec | 需批准 | 需批准 |
| X    | 按需   | 按需     | 0      | 仅在有回滚方案时 |

## 升级触发器（命中任意一条，必须停下来进入计划评审）
新增依赖/新表/新索引/新队列/新缓存/新服务/新抽象层；Schema 变更；跨业务域改动；
触碰鉴权、支付、删除数据、对外发送；超出上表预算；同一个 bug 第三次回来

变更等级：S（若你认为是 L，先只说明为什么，不要写代码）

现有行为：在 ___ 里，现在是 ___
要加的行为：___

不要做：
- 新依赖、新表、新索引、新服务、新队列、新缓存层
- 新的 repository / factory / strategy / provider / DI
- 改与本任务无关的文件 / 为"以后可能"加配置项 / 在请求路径上加外部新依赖

允许改动的文件：
- path/a  - path/b  - path/a.test

完成条件（写成 transcript 里看得见的东西）：
- `___` 测试命令退出码 0；lint 干净
- git diff --stat 净增 < __ 行（报警线：超了要给理由并进计划评审，不是自动判失败）
- 若有 SQL：EXPLAIN 无大表 Seq Scan，单请求查询数 ≤ __

先读：邻近的 ___ 实现，复用它，不要平行写一套。
超过什么边界必须停下来提交决策卡：___

在写任何代码之前，输出三个方案：

【方案 A · 最小改动】改哪些文件、多少行；满足了哪些完成条件；牺牲了什么
【方案 B · 平衡】与 A 的差异，以及多出来的复杂度买到了什么
【方案 C · 可扩展】为哪个"已确认存在"的未来需求做准备；如果尚未确认，直接标注"投机"

【我的选择与理由】
- 我选：___
- 为什么 A 不够：___（必须是具体的、当前就存在的问题，不能是"以后可能"）

如果你选了 B 或 C，但"为什么 A 不够"里出现了"未来"、"可能"、"更灵活"、"更规范"
这类词而没有当前的具体问题，那么请改选 A。

Complexity Tracking: Fill ONLY if Constitution Check has violations that must be justified

| Violation | Why Needed | Simpler Alternative Rejected Because |

### Phase -1: Pre-Implementation Gates
#### Simplicity Gate
- [ ] Using ≤3 projects?      - [ ] No future-proofing?
#### Test-First Gate
- [ ] Tests written before implementation?   - [ ] Contract tests defined?

## Surgical Changes — Strict Protocol

### Pre-Change Declaration
Before making ANY changes, list:
1. Files that will be modified
2. For each file, the specific lines/sections that will change
3. Justification: why each change is necessary for the task

### Change Budget
- Bug fixes: target ≤10 lines changed
- Small features: target ≤50 lines changed
- If your change exceeds the budget, explain why and get confirmation

### Prohibited Actions (unless explicitly requested)
- Renaming anything / Reformatting / Adding or removing comments
- Restructuring code / Upgrading dependencies / Modifying unrelated config

### Post-Change Audit
- Every modified line is necessary for the task
- No files were touched that aren't directly needed
- The diff is the smallest possible for this task

Gate 1 · 计划评审（写码前，最高杠杆）
  这个方案解决的是我要的问题吗？
  它有没有夹带我没要的东西？（对照非目标清单逐条看）
  "为什么最小方案不够"——说的是当前存在的具体问题，还是"以后可能"？

Gate 2 · 发现评审（探索后、改动前）
  它发现的情况改变了任务性质吗？（缺迁移、多调用方、隐式依赖）

Gate 3 · 提交前 diff（检查项无条件跑；由谁看取决于风险等级）
  改动范围 = 我批准的范围吗？
  有没有：范围蔓延、意外删除、硬编码密钥、缺测试、测试数量减少

## 本次改动
- 变更等级：S / M / L / X
- 用户可见的行为变化：___

## 确定性验证
- [ ] 类型检查 / lint / 单测 / 集成测试 全绿（贴命令输出）
- [ ] 架构规则检查通过
- [ ] git diff --stat：___（预算 ___）
- [ ] 测试数量：改动前 ___ → 改动后 ___（不允许下降）

## 数据库（若触碰 SQL / ORM / 迁移）
- [ ] 新增/修改的语句清单 + EXPLAIN 输出对比（改动前 vs 改动后）
- [ ] 单请求查询数：___（预算 ___）
- [ ] 迁移：expand/contract 分阶段？回填是否限速可暂停？回滚方案是什么？

## 风险
- 代码可逆性：___ / 数据可逆性：___
- 外部副作用（邮件/扣款/消息/第三方调用/用户已见）：___
- 灰度方案与自动回滚阈值：___

事故：___
用户影响：___

为什么 harness 没发现它？
  - 缺哪个 signal？（测试 / 指标 / lint / 架构规则 / 权限）

本次必须产出（至少一条，且必须是自动化的）：
  - [ ] 一条回归测试   - [ ] 一条 CI 门禁 / lint 规则
  - [ ] 一条监控告警   - [ ] 一条 golden task

同时删除：
  - [ ] 已经过时、重复或只制造噪声的规则 ___

总原则：先止血、再造事实、再加门、最后改人的位置。不要一上来重新设计一个漂亮架构。

明确推迟的（不要在第一个月做）

分级门禁的五种成熟模式（第 2 个月起用）

先看清门禁的真实代价，再验证 harness 本身（meta-eval）。

门禁的真实代价：flaky 数据

含义：门加得越多，假阳性越多；假阳性会让 agent 陷入无效循环，也会让人开始无视红灯。所以分级门禁不是优化，是必需品。

meta-eval：harness 自身的有效性验证

六道种子测试（最便宜的一次审计，一小时跑完）⭐：用已知坏样本测试检查器——① 删掉断言的 PR；② 超大 diff 的 PR；③ 意外新增依赖的 PR；④ 越界改配置的 PR；⑤ 日志里含 prompt injection 字符串的输入；⑥ 碰了不该碰的文件的 PR。任何一条没被拦住，说明那道门是装饰。

破坏性构建灵敏度检查：每条新测试先注释掉被测功能重跑——仍绿说明没有真正断言。测试计数基线：记录总数，CI 中数量下降直接 fail。golden tasks：20–50 条起步，能力评测从低通过率爬坡，回归评测维持接近 100%，稳定后毕业。

该追踪的指标

不要统计「AI 写了多少行」。追踪这些：

在 Claude Code / Codex 里的具体落法

这一代模型的提示词校准（2026 年 7 月起）

派工给执行代理时的最小契约

1. 变更等级 + 允许改动的文件白名单
2. 禁止清单（新依赖/新表/新抽象/无关文件）
3. 完成条件（可机器验证，写成命令和退出码）
4. 先读什么（邻近实现，复用而非平行造）
5. 超过什么边界必须停下来问

缺任何一段，你就会收到 600 行。一条元教训：不要让同一个 AI 独自完成「生成规则 → 写实现 → 写测试 → 宣告通过」这条闭环——至少要有一次外部独立性。否则你得到的不是治理，是一个自证清白的系统。

给技术背景不强、但要管住 AI 写代码的人。只有第 1、2、3、7 条是你自己能完成的——其余的需要工程能力。