从串行验证、并行协作，到三种工作流各自的 Referee 优化。
前两篇：
前两篇分别解决了两类问题：
- 第一篇：串行验证。 把开发拆成背景、方案、实现、审查、验证，用 Gate 保证"没想清楚就不要写代码"。这套结构适合
dev-workflow，也被bugfix-workflow借鉴。 - 第二篇：并行协作。 把串行链路改成 Router + Worker，让 Analyst、Coder、Reviewer 能提前开始，减少等待。这套结构就是
dev-workflow-router。
但三条路线跑起来之后，新的问题又出现了：
- 每个任务都停下来等人，人变成了瓶颈，能不能用AI来判断；
- AI来判断的话三条路线各自维护一套判断，规则容易分叉；
- AI来判断的话复盘变成 AI 自审，规则可能越改越多，越改越乱；
- 同一个 Skill 要在 DSH、Claude Code、Codex 各维护一份薄壳层，核心必须用同一套迭代。
所以这篇不是再设计一套新流程，而是优化已有的三种工作流：
| 工作流 | 主要解决 | 判断核心 | 这次优化的重点（Referee 独立） |
|---|---|---|---|
dev-workflow |
功能开发、重构、UI、构建配置 | 两轴 Gate（与 dev-workflow-router共用核心） |
独立 Referee 做需求/方案两轴对比；绿/黄继续、红才停 |
dev-workflow-router |
需要并行协作的复杂开发 | 两轴 Gate（与dev-workflow 共用核心） |
独立 Referee 做对比/复盘；共用核心和账本 |
bugfix-workflow |
需系统诊断的故障 | 独立四轴红绿灯（独立核心） | 独立 Referee 做 triage 复核/复盘；复盘改为记录/提案 |
三种工作流的 Referee 都是独立实例 ：每次新建、不共享主会话、不复用其他工作流的 Referee。共用的是 Referee 的运行方式（独立、无工具、单轮、固定输入、结构化输出、规则变更由人批准），不是判断标准。
判断标准是分开的：
dev-workflow与dev-workflow-router共用两轴 Gate 和.gate/v8/账本；bugfix-workflow用独立的四轴红绿灯和.bugfix/账本，与开发工作流不共用判据。
一句话：三种工作流共用 Referee 的运行机制，但不共用判断标准；开发两条线共用 v8，bugfix 独立。
这篇不讨论"怎么让模型写出更好的代码"，而是讨论：怎么让 AI 工作流在真实研发里跑得动、跑得久、还能自己变好。
一、引入 AI 判断 Referee：三种工作流各自的独立判断层
1.1 所有 Gate 都拦人，代价很大
前两篇的 Gate 是"关键决策分别放行"：
| Gate | 什么时候停 | 人要确认什么 |
|---|---|---|
| #0 背景 | 背景梳理完 | 场景、目标、影响范围理解得对不对 |
| #1 方案 | 方案和 AC 写完 | 技术取舍、修改范围、风险能不能接受 |
| #2 实现 | 代码和自检完成 | 实际改动、偏差、真机验证结果 |
这套机制在"少量高价值任务"上没问题，但任务一多，成本就出来了：
| 成本 | 具体表现 |
|---|---|
| 等待成本 | 每个任务至少停两次，人不在就卡住 |
| 注意力成本 | 大量卡片内容重复，人容易只看结论不看依据 |
| 判断疲劳 | 看多了会倾向于"先点确认"，Gate 逐渐形式化 |
| 一致性差 | 不同时间、不同人，对同一类问题的判断不一样 |
| 上下文切换 | 人刚从另一个任务回来，很难重新进入细节 |
更关键的是：大部分任务并不需要人在每一个 Gate 上做决定。
真正需要人的，通常只有三类：
- 方案有实质性取舍，且 AI 给不出唯一合理答案；
- 判断卡在红卡上，必须补充信息或接受代价；
- 要修改"判定标准"本身。
其他情况，AI 应该先给出可核对的判断，人只需要在关键节点抽查，而不是每个任务都全程陪跑。
1.2 Referee 是什么
Referee 是工作流里的独立判断角色。
它不是"再开一个聊天窗口问模型"，而是：
- 无工具：不读文件、不搜代码、不查日志；
- 单轮：一次输入，一次输出，不进入 agent loop；
- 固定输入：只接收主 Agent 拼好的 payload；
- 定长输出：只输出结构化 JSON，不写长篇分析。
它解决的是"判断"这一件事，不负责调查、不负责实现、不负责审查。
可以把它理解成三个角色：
| 角色 | 负责什么 | 不负责什么 |
|---|---|---|
| 主 Agent | 调查、拆解、实现、组织流程 | 不自己给自己发"通过" |
| Referee | 独立判断需求/方案/故障是否成立 | 不取证、不改代码、不定最终结论 |
| Reviewer | 独立审查实现和回归 | 不参与实现推导 |
Referee 的价值不是"比人聪明"，而是：
- 它不受主 Agent 的实现思路影响；
- 它每次从零开始，不带历史包袱；
- 它的输入和输出都是固定的，成本可预测；
- 它可以被人随时抽查、复算、质疑。
1.3 大部分情况下不需要人
这次优化把"人必须确认"改成了"只有红卡和标准变更必须人"：
| 判断结果 | 谁处理 | 是否停下 |
|---|---|---|
| 绿 | 直接进入实现 | 不停 |
| 黄 | 直接进入实现，但带风险 | 不停；人可随时打断 |
| 红 | 人处理 | 停，等补充信息或决策 |
| 标准变更 | 人批准 | 停，等明确批准 |
注意，这里说的是"不需要人在每个 Gate 上确认"，不是"人没有权力"。
人仍然保留：
- 目标和取舍的最终决定权；
- 随时打断、纠偏、否决的权力；
- 红卡的处理权；
- 规则修改的批准权；
- 真机验证和最终交付的确认权。
一句话：AI 负责让流程跑起来，人负责在真正重要的地方踩刹车。
1.4 自进化系统
这次优化不再让 AI "每轮复盘、自己改规则"。那套做法的问题是：
- 复盘变成 AI 自评，容易把自己的判断合理化；
- 每轮都提规则，规则库很快膨胀；
- 人没有时间看大量低价值提案；
- 规则改了之后，没人知道该不该回滚。
新的做法是"记录信号，达到条件才提案"：
text
人打断 / 纠偏 / 负反馈
↓
Referee 记录 human_signal
↓
按 signature 累计同类信号
↓
同类 < 2：只记录案例（record）
同类 ≥ 2：生成规则修改提案（propose）
↓
人批准 → 下一轮生效
人驳回 → 保留案例几个关键点：
- 人的判断最高优先级 ：
human_signal直接记录人的原话和结论，不让 AI 再判一次； - 同类才提案：一次信号可能只是偶发，两次以上才值得改规则；
- 提案必须五样：改哪条、为什么、反例、证伪条件、回滚方式；
- 只有人能批：Referee 和主 Agent 都不能写标准文件；
- 下一轮生效：不能拿刚改的规则去判刚发生的案例；
- 可回滚：规则生效后持续观察，出现反例可以回滚。
这样规则库不会"每轮长一条"，而是"真的重复出现，才值得改"。
1.5 其他补充
可审计。 每次判断都有固定输入、固定输出和账本事件。人可以回看"当时看到了什么、判了什么、为什么"。
可降级。 Referee 起不来、超时、输出不合约时，记录 n/a，由主 Agent 按规则继续，并明确标注"未独立判断"，不伪装成已判断。
成本可控。 Referee 无工具、单轮、短输出；每个任务最多 4 次调用，典型任务 0--2 次。
边界清晰。 Referee 不替代人，不替代 Reviewer，也不替代真机验证。它只做"判断"这一段。
二、红绿灯的设计：把"能不能开工"变成可判定
红绿灯最初是为 bugfix-workflow 设计的：故障修复最怕"原因没查清就直接改"。后来发现，这套"分轴判断 + 强制项"的思路，比简单的"能不能开始"更适合真实工程。
2.1 三种灯色
| 灯色 | 含义 | 默认动作 |
|---|---|---|
| 🟢 绿 | 预期清楚、原因已定位、方案确定、范围可控 | 直接进入实现，不要求人确认 |
| 🟡 黄 | 有合理假设或候选方案，但还缺证据或授权 | 停下（开发工作流带风险放行）；人补充证据，或明确授权"按当前假设试修" |
| 🔴 红 | 目标不唯一、关键证据缺失、原因和方案都没形成 | 停下；只能补充证据后重判，不能授权直接修 |
这里最容易误解的是黄灯。
黄灯不是"差一点绿"，而是"可以试，但要知道自己在试什么"。所以黄灯必须写清：
- 假设原因是什么；
- 支持证据和反证是什么；
- 怎么验证；
- 失败怎么回退。
如果这些写不出来，那就不是黄灯，是红灯。
2.2 四轴 + 强制项
红绿灯不是拍脑袋，而是先看四个轴，再看强制项。
| 轴 | 取值 | 含义 |
|---|---|---|
| 原因轴 | RC1 |
已定位，有静态或运行证据 |
RC2 |
有证据支持，但还没完全核实 | |
RC3 |
未定位 | |
| 方案轴 | FX1 |
修复方案已确定 |
FX2 |
有候选方案，需要选择或验证 | |
FX3 |
没有技术方案 | |
| 证据轴 | EV1 |
运行证据（日志、截图、复现） |
EV2 |
静态证据（代码、配置、调用链） | |
EV3 |
用户报告 | |
EV4 |
推断 | |
| 范围轴 | SC1 |
单点、单页、局部 |
SC2 |
多路径、多页面 | |
SC3 |
跨模块、涉及架构或共享契约 |
强制项是"一票否决/一票停"的检查：
| 强制项 | 含义 | 结果 |
|---|---|---|
H1 |
关键证据补不齐 | 红 |
H2 |
需要授权（例如验证性修复） | 黄，等授权 |
H3 |
目标不唯一，同一功能有多个实现 | 红，先让人指认 |
H4 |
涉及危险操作，需要单独授权 | 黄/红，按操作风险 |
2.3 合成规则
判定顺序很重要，顺序错了会把红灯降成黄灯。
text
1. H3：目标不唯一 → 红
2. H1：关键证据补不齐 → 红
3. RC3 + FX3：原因和方案都没有 → 红
4. H2 / H4 未授权 → 黄
5. RC1 + FX1 + SC1 + H4 已授权（或不涉及）→ 绿
6. RC2，或 RC1 + FX2/FX3，或 RC3 + FX2 → 黄
7. 其余 → 红可以先记一个简单版本：
- 绿：知道为什么、知道怎么修、范围可控；
- 黄：有合理假设或候选，但还需要验证/授权；
- 红：连"修什么"或"怎么修"都还没形成。
2.4 卡片长什么样
不同灯色的卡片，信息密度不一样。
绿灯卡：
text
【F-20261109-01 · 🟢 绿灯】
原本应该怎样：
现在实际怎样：
原因与因果链：
修复方案：
范围（IN / OUT）：
验证契约：
验收标准（AC）：
结论：绿灯不是"随便修"，而是"信息已经足够直接开工"。
黄灯卡：
text
【F-20261109-01 · 🟡 黄灯 · 假设待验证】
假设原因：
支持证据：
反证 / 还没排除的解释：
验证方法：
失败怎么回退：
需要你确认/授权什么：黄灯卡的核心是"可验证的假设"，不是"我觉得可能是"。
红灯卡：
text
【F-20261109-01 · 🔴 红灯 · 原因未知】
现在能确定的：
还缺什么：
建议怎么补：
补到之后怎么验证：
需要你指认/决定什么：红灯卡不给技术方案，只给"复现方向"和"需要补充什么"。
2.5 黄灯授权与红灯不可授权
黄灯可以授权，但授权必须明确：
- "按当前假设试修"
- "先修这版看结果"
- "授权验证性修复"
笼统的"确认"只表示已读，不构成授权。
红灯不能授权直接修。红灯只能：
- 补充证据；
- 补充可验证的假设；
- 转黄或转绿后，再进入实现。
这不是流程洁癖，而是因为红灯意味着"现在还不知道在修什么"。在这种情况下开工，大概率是在制造第二个问题。
2.6 红绿灯和开发 Gate 的区别
| 项 | 开发 Gate（dev-workflow） | 红绿灯（bugfix-workflow） |
|---|---|---|
| 判断对象 | 新需求 + 方案 | 故障原因 + 修复方案 |
| 主要轴 | 需求轴、方案轴 | 原因轴、方案轴、证据轴、范围轴 |
| 绿 | 需求清楚、方案唯一可行 | 原因已定位、方案确定、范围可控 |
| 黄 | 有开放风险，但可继续 | 有假设/候选，需要验证或授权 |
| 红 | 需求或方案不成立 | 原因/方案/证据不足 |
| 停止点 | 红卡 | 黄卡、红卡 |
两者都用"绿/黄/红"，但判断轴不同。不要拿开发的"需求清楚"去套故障的"原因已定位"。
三、Referee 设计：独立、单轮、可校验
3.1 三条原则
第一，无工具。
Referee 不读文件、不搜代码、不查日志。它只接收主 Agent 拼好的 payload。
这不是为了省钱，而是为了防止它从"判断"滑向"探索"：
让它判一下，它开始读十个文件确认；读完十个文件，它开始改代码。
第二，单轮。
一次输入，一次输出。没有多轮追问，没有工具调用，没有"我再看看"。
这样成本可预测，输出可复算，也不会把主会话的历史带进去。
第三，固定输入。
每次调用只给：
- 本次判断需要的结构化事实；
- 当前标准；
- 按需检索的同类案例（最多 5 条）。
不给完整聊天记录，不给实现过程，不给"我已经觉得应该判绿"的暗示。
3.2 三种形态
Referee 在不同阶段做不同的事，但底层机制一样。
| 形态 | 什么时候用 | 输入 | 输出 |
|---|---|---|---|
| 核准 | 人陈述了"旧行为是什么" | text + as_is + 源码位置 |
premise: ok / mismatch / missing |
| 对比 | 开发 Gate 第 3--4 步 | 标准 + 第 0--2 步产物 + 能力域/候选 + L1 结果 | 两轴 + domains + causes + risks + suggestions |
| 复盘 review | Phase 4 触发复盘 | 原判定卡 + 人的原话/结论/证据 + 同类计数 + 标准 | human_signal + same_case_count + action + case_record + proposal |
三种形态的共同点：
- 都只输出 JSON；
- 都不读文件；
- 都不替人做最终决定；
- 都有明确的输出契约。
3.3 复盘输出长什么样
复盘不是"再判一次"，而是"记录人的信号，判断要不要改规则"。
json
{
"human_signal": {
"target": "F-20261109-01",
"quote": "这个文案对所有设备都说会断开连接，WiFi 摄像头不一定",
"verdict": "yellow",
"evidence": ["WiFi 摄像头不必然因该操作断开"],
"signature": "copy_assert_disconnect_unverified_device_scope"
},
"same_case_count": 2,
"action": "propose",
"case_record": {
"id": "C-20261109-01",
"signature": "copy_assert_disconnect_unverified_device_scope",
"verdict": "yellow",
"human_said": "这个文案对所有设备都说会断开连接，WiFi 摄像头不一定",
"cause": "文案断言范围超出已验证的设备行为",
"signal": "human_negative_feedback",
"source": "F-20261109-01",
"status": "observing"
},
"proposal": {
"id": "P-20261109-01",
"clause": "连接状态文案断言约束",
"change": "断言连接/断开结果前，先按设备类型和连接方式确认行为",
"evidence": ["F-20261109-01", "K2"],
"counter_example": "WiFi 摄像头依赖局域网/云端，BLE 断开不必然使其断开",
"falsify": "若实现已按连接方式分支呈现，或产品确认行为一致，则撤回",
"rollback": "删除新增条目，恢复原标准"
}
}几个字段的意思：
| 字段 | 含义 |
|---|---|
human_signal |
人的原话、结论、证据、同类签名 |
same_case_count |
同类信号累计次数（含本次），由主 Agent 统计，Referee 只复核 |
action |
none 无信号 / record 只记录 / propose 出提案 |
case_record |
案例留痕，供后续检索 |
proposal |
规则修改提案，五样齐全才允许提 |
3.4 人的判断最高优先级
这是这次优化最重要的变化之一。
早期版本设计了 B1 盲重判 + B2 归因：
- B1：把原判定卡藏起来，让另一个 Referee 再判一次；
- B2：比较"盲判结果"和"原判定"，归因 A/B/C。
这套设计的初衷是测量"规则稳不稳定"。但放到真实场景里，很容易变成：
人已经明确说"这个判断有问题"，AI 还要再盲判一次，然后告诉人"你该改主意"。
这是错位的。
人的判断是最高优先级：
- 人说"这个文案不对"，就记"文案不对"；
- 人说"这个黄卡太保守"，就记"黄卡太保守"；
- 人说"应该判红"，就记"应该判红"。
Referee 不再复核人，只做两件事：
- 把人的信号记录清楚；
- 判断同类信号是否达到"值得改规则"的次数。
于是流程变成：
text
人指出问题
→ Referee 记录（human_signal）
→ 同类 < 2：只留案例（record）
→ 同类 ≥ 2：出规则修改提案（propose）
→ 人批准：下一轮生效
→ 人驳回：保留案例，不改规则这样既保留了"规则可以进化"，又不会让 AI 反过来审人。
3.5 输出契约与失败降级
Referee 的输出必须可校验：
human_signal字段类型正确；same_case_count是非负整数；action只取none/record/propose；record/propose必须有case_record；propose必须same_case_count >= 2，并且有proposal、falsify、rollback；- 字段名固定，不接受别名。
不合约时：
- 记录
referee_contract: miss； - 主 Agent 按 schema 补正；
- 不改变 Referee 的原始结论；
- 同一判断最多重跑一次。
独立上下文起不来时：
- 记录
n/a； - 主 Agent 按规则继续；
- 明确标注"未独立判断"；
- 不用主 Agent 自评补位，不伪造 Referee 输出。
3.6 成本
Referee 的成本优势来自"无工具 + 单轮 + 短输出"：
| 形态 | 触发率 | 输入 | 输出 |
|---|---|---|---|
| 核准 | 只在人陈述旧行为时 | ~0.3k | ≤80 token |
| 对比 | 非 L2 任务 | ~2.4k | ≤150 token |
| 红卡建议 | 需要时追加 | +0.6k | ≤500 token |
| 复盘 review | 有触发事件时 | ~2.8k | ≤400 token |
每个任务最多 4 次调用，典型任务 0--2 次。
对比之下，如果每个任务都让人完整看三张卡，成本不只是 token，还有人的注意力和等待时间。
四、全流程与角色定义：三条路线怎么落地
4.1 三种工作流对应三条路线
三种工作流对应三条路线，共用"阶段 + 关卡 + 判断"的思想，但组织方式不同。
| 路线 | 适用场景 | 组织方式 | 主要角色 |
|---|---|---|---|
| 串行 dev-workflow | 功能开发、重构、UI、构建配置 | 主 Agent 串行推进 | 主 Agent + Referee + Reviewer |
| Router 路线 | 需要并行协作的复杂开发 | Router 调度多个 Worker | Router + Analyst + Coder + Reviewer + Referee |
| bugfix-workflow | 需系统诊断的故障 | 主 Agent 串行，红绿灯判定 | 主 Agent + Investigator + Referee + Reviewer |
三种工作流的共同点：
- Phase 0 先判断，不直接写代码；
- 实现后有 Checkpoint #1；
- Phase 2 独立审查；
- Phase 3 验证；
- Phase 4 复盘 + 文档 + 交付；
- 判断由 Referee 独立完成，人不逐卡确认。
4.2 阶段总表
| 阶段 | 目标 | 串行路线 | Router 路线 | Referee | 主要产物 | 人工关卡 |
|---|---|---|---|---|---|---|
| Phase 0 | 判断"要不要做、怎么做" | 主 Agent 调查、拆解、方案 | Analyst 交背景/方案/payload | 对比/复核 | 判定卡、方案、AC | 红卡停；绿/黄继续 |
| Phase 1 | 在边界内实现 | 主 Agent 实现 | Coder 实现（可抢跑） | 不参与 | 代码、diff、自检 | Checkpoint #1 真机验证 |
| Phase 2 | 独立审查 | 独立 Reviewer | Reviewer A | 不参与 | 审查报告 | 失败 #2 |
| Phase 3 | 验证 AC | 主 Agent / Reviewer | Reviewer A | 不参与 | 验证报告 | 失败 #3 |
| Phase 4 | 复盘、文档、交付 | 主 Agent + Referee review | Router + Referee review | 记录/提案 | 复盘 JSON、文档、交付 | 最终验收 |
4.3 串行路线角色
| 角色 | 职责 | 写权限 | 主要输出 |
|---|---|---|---|
| 主 Agent | 调查、拆解、方案、实现、验证、汇总 | 唯一写业务代码 | 方案、代码、验证报告、交付 |
| Referee | 独立判断/记录 | 不写代码、不写标准 | 判定 JSON、review JSON |
| Reviewer | 独立审查实现 | 不写业务代码 | 审查报告 |
| 人 | 目标、取舍、红卡、标准批准、真机验证 | 最终决定权 | 确认/否决/授权 |
4.4 Router 路线角色
Router 路线把职责拆得更细，但仍然是"一个主脑 + 多个独立角色"。
| 角色 | 职责 | 写权限 | 输入 | 输出 |
|---|---|---|---|---|
| Router | 编排、派工、快照、放行登记、写账本、展示 | 不写方案、不写代码 | 用户需求、Worker 回执 | 任务台账、卡片、交付 |
| Analyst | 背景、拆解、方案、候选、L1/L2 | 只写自己的工件 | 启动基线、需求 | background.md / plan.md / payload.md |
| Coder | 唯一源码写入者 | 业务代码、资源、配置 | 已确认契约 | 代码、coder.md |
| Reviewer | 独立审查、验证、总结 | 不写业务代码 | diff、AC、证据 | review.md / verification.md / summary.md |
| Referee（对比） | Phase 0 对比/复核 | 无 | payload | 两轴/建议 |
| Referee（复盘） | Phase 4 记录/提案 | 无 | 原卡、人的信号、同类计数 | review JSON |
实例约束：
analyst、coder、reviewer、referee_compare、referee_review五个 Agent ID 必须互不相同；- Referee 每次新建，不复用主会话；
- Coder 是唯一源码写入者；
- Reviewer 不参与实现；
- Router 不代替 Referee/Reviewer 下结论。
4.5 工件与账本
| 路线 | 工件根 | 账本 | 说明 |
|---|---|---|---|
| 串行 dev-workflow | 项目内按任务约定 | .gate/v8/ |
Gate 事件、标准、案例、复盘 |
| Router | .dsh-workflow-router/<task>/ 等 |
.gate/v8/ |
任务台账、快照、回执 |
| bugfix-workflow | 项目内按故障记录 | .bugfix/ |
红绿灯事件、派生规则、复盘 |
账本只追加，不回头改；完整报告在工件里，账本只存事件和摘要。
五、多平台的封装：薄壳层和核心层
5.1 问题：三份规则，迟早漂移
三种工作流都要在 DSH、Claude Code、Codex 三个平台使用，于是问题从"设计流程"变成"同时维护三套平台封装"。最直接的做法是：
- 每个平台复制一份
SKILL.md； - 每个平台再复制一份
gate.md/triage.md/agent-delegation.md； - 改规则时，三份一起改。
短期能用，长期一定出问题：
- 改了一处，忘了另外两处；
- 三个平台的判据、阈值、事件字段逐渐不一致；
- 新平台接入要再抄一遍；
- 出问题时分不清是"规则错"还是"壳写错"。
5.2 薄壳层 + 核心层
这次优化把工作流拆成两层：
| 层 | 放什么 | 谁维护 | 是否平台相关 |
|---|---|---|---|
| 核心层 | 规范、执行细则、阶段规则、判定轴、模板、账本结构 | 工作流维护者 | 否 |
| 薄壳层 | 平台工具名、文件路径、账本路径、上下文目录、平台限制 | 各平台 | 是 |
核心层是唯一事实源。壳层只做三件事：
- 告诉 AI 在当前平台用什么工具；
- 告诉 AI 文件/账本/上下文在哪；
- 把平台差异隔离在最小范围。
一个合格的壳，应该很薄：
Claude 平台壳
| 项 | Claude |
|---|---|
| Worker 启动 | Agent / Task |
| 账本 | .gate/v8/ |
| 上下文目录 | .claude/contexts/ |
| 复盘 | Referee review |
它不应该包含：
- 判据正文；
- 阈值数值；
- 路径清单；
- 事件字段表；
- 卡片模板；
- 阶段规则。
这些东西一旦进壳，就会变成"第二份规则"，迟早和核心层不一致。
5.3 目录怎么放
以三平台为例，可以用这样的结构：
text
docs/workflow/v8/ # 核心层：规范、runbook、Phase 0/4
gate-0-1-spec-v8.md
gate-runbook.md
phase0.md
phase4.md
README.md
docs/bugfix/core/ # bugfix 独立核心
bugfix-workflow.md
triage-runbook.md
retro-runbook.md
referee-runbook.md
.claude/skills/dev-workflow/ # Claude 薄壳
SKILL.md
references/gate.md
references/workflow-core.md
references/agent-delegation.md
.codex/skills/dev-workflow/ # Codex 薄壳
.dsh/skills/dev-workflow/ # DSH 薄壳三条路线各自有核心，但共享同一条原则：
规则只写一遍，平台差异只写一层。
5.4 怎么防止壳层长厚
光靠"记得别写"不够，需要机制。
这次优化加了 check-drift.py 漂移检查脚本，做两件事：
- 检查壳有没有抄判据：壳里出现阈值常量、路径清单、事件字段表，就报越界；
- 检查壳有没有转发到核心：壳必须引用核心文件，不能自己写一套。
检查不通过，就不能合并。
另外还有几条约定：
- 壳里只允许出现"平台事实"：工具名、路径、账本位置、上下文目录；
- 平台差异如果确实需要规则，先改核心层，再在壳里引用；
- 同一份核心，三平台共用；壳的差异只允许是平台事实；
- 新增平台时，只写壳，不复制核心。
5.5 多平台封装的收益
| 收益 | 说明 |
|---|---|
| 升级一次，三端生效 | 改核心层，不用三份一起改 |
| 差异可解释 | 平台差异集中在壳里，排查时先看壳 |
| 可检查 | 漂移脚本能发现"抄判据/漏转发" |
| 可扩展 | 新平台只写壳，不改规则 |
| 可审计 | 核心层是唯一规则来源，版本清楚 |
代价是：
- 核心层要足够稳定，不能天天改；
- 壳层要克制，不能什么都往里塞；
- 需要脚本和约定来维护边界。
但相比"三份规则各写一套"，这个代价是值得的。
六、上下文与成本
多 Agent 工作流最容易失控的地方，不是模型能力，而是上下文。
这次优化的几个做法：
6.1 Referee 只收 payload
Referee 不读文件、不读代码、不读日志。主 Agent 把事实压缩成固定字段，Referee 只看这些字段。
好处：
- 成本可预测；
- 输出可复算；
- 不会被无关上下文带偏；
- 不会从"判断"滑向"探索"。
.2 按阶段读，不预加载
- Phase 0 只读 Phase 0 相关；
- Phase 1 只读实现相关；
- Phase 2 只读审查相关；
- Phase 4 只读复盘相关。
不要求 AI 一次读完所有规则。
6.3 工件只传摘要
交接时传：
- 路径；
- 摘要；
- 关键结论；
- 必要的 diff/证据。
不把完整聊天、完整日志、完整实现过程复制给下一个 Agent。
.4 L2 快通道
有些任务不需要完整对比：
- 纯文档/文案；
- 单文件、单点改动；
- 已有明确先例。
这类任务可以走 L2 快通道：少调 Referee，甚至不调，只写 judgment。
七、落地清单
如果你也想在自己的项目里落地，可以按这个顺序：
- 先定三色：绿/黄/红的含义、默认动作、谁处理；
- 再定轴：原因、方案、证据、范围，以及强制项；
- 写 Referee 契约：输入字段、输出 JSON、失败降级；
- 建账本：事件、案例、提案、标准；
- 定自进化规则：同类 2 次才提案，人批准才生效，支持回滚；
- 拆薄壳：核心层写规则，壳层只写平台事实；
- 加漂移检查：防止壳抄判据、漏转发；
- 跑真实任务：先用 5--10 个任务验证，再扩大范围。
不要一上来就追求"全自动"。先把"判断---记录---提案---批准"跑通，再逐步减少人工介入。
八、总结
这次优化的变化，可以概括为四句话：
- 判断从人转移到 AI Referee：绿/黄继续，红才停；人处理例外，不陪跑每个 Gate。
- 红绿灯用分轴判断代替拍脑袋：原因、方案、证据、范围 + 强制项，黄灯可授权，红灯不可授权。
- 复盘从"AI 再判一次"改成"记录人的信号，达条件才提案"：人的判断最高优先级，规则进化由人批准。
- 多平台用薄壳层 + 核心层：规则只写一遍，平台差异只写一层，靠漂移检查守住边界。
这套东西不能保证 AI 不犯错，但它让错误更早暴露、让判断更可复算、让规则能慢慢变好，也让工程师不用在每个 Gate 上重复做同样的判断。
本文结合项目实践与思考整理，由 AI 辅助成稿，作者负责把关。欢迎批评指正。
工程设计篇：