AI 不缺智商缺纪律：一场 Harness 工程化实践
AI Coding 的瓶颈正从「模型能力」转移到「流程工程」——模型已经足够聪明，但不稳定，而稳定性必须由外部框架供给。harness = 把「AI 该怎么干活」固化成可执行、可约束、可评测的工程框架。
核心问题
用过 AI 编码的人大概率遇到过这三个痛点：
- 不听话（规则太多，选择性遵守）
- 上下文爆炸（规则常驻窗口，挤压代码空间）
- 自我矛盾（规则间冲突，模型编造折中方案）
根因：模型"理解"了规则不等于"遵守"了规则，你无法用更多的字来对抗概率性的遗忘。
Agent「遗忘」不是 bug，是当前架构的必然代价。遗忘有三重根因：
- 压缩丢失（Auto-Compact 省略"看似不重要"的流程步骤）
- 检索失败（记忆文件在但没被加载进上下文）
- 指令遵循失败（信息都在但模型仍然跳步）
四阶段演进
| 阶段 | 方法 | 问题 |
|---|---|---|
| 拿来主义 | 用开源模板（oh-my-claudecode 等） | 通用规范覆盖不了真实开发流程 |
| 重 prompt 约束 | 把规矩全写进 CLAUDE.md | 三天后崩了：不听话、上下文爆炸、自我矛盾 |
| 减负 + 分层加载 | 常驻 ≤8K，深度内容按需加载 | 长程会话中规则被稀释到注意力衰减区 |
| Agent 调度编排 | dispatcher 状态机 + 文件交接 | 24 agent 过度拆分，维护成本高 |
核心转变：从「用更多的字约束 AI」，到「用更好的结构约束 AI」。
三层加载架构
常驻入口层：CLAUDE.md + CLAUDE.local.md
- 放角色、代码偏好、流程触发规则、G1–G8 门禁速查
- 关键设计：CLAUDE.local.md 自包含、不依赖全局 @import
- 效果：主会话常驻上下文压到 ≤8K
原子规则层：rules/（7 个）
- 每条规则是一次事故的墓志铭
- 坑只踩一次，之后由规则兜底
角色 Agent 层：agents/
- dispatcher：读 state.json + workflow.yaml，决定下一步该调谁——交通警察，只管路由不管业务
- orchestrator：读三角色观点，合成结论——会议秘书，只管合成不管调度
- 三角色评审：requirement-analyst / tech-architect / quality-guardian，各写各的观点段，互不污染
- 流程执行：plan-generator → developer → verifier → deployer → tester
按需上下文层：context/（10 个）
- 完整流程详情、Pre-Mortem 模板、对抗辩论模板、TDD/ATDD 指南等
- 只在进入对应阶段时才被 Read
执行支撑层：skills/（22 个）+ commands/（12 个）
- 把内部 CLI 和研发工具链封装成 AI 可调用的能力
- slash 命令入口：/init-harness、/harness-audit、/learn
稳定性支点：门禁 + Hook
G1–G8 门禁墙（eval 式硬校验）
每个门禁是确定性的 Python 函数，检查产物存不存在、编译过不过、单测通没通。verifier agent 跑完后写 phases/verification.json，任一 gate FAIL 则流程退回 DEVELOPING——不是"建议"，是"阻断"。
hook 拦截（运行时硬约束）
- 状态文件写操作只允许编排层 agent 触发
- 危险操作（git push --force、rm -rf）弹确认
核心原则：流程强制执行必须从 LLM 推理中外置到确定性基础设施。fail-closed（默认拒绝，只放行显式允许的操作）。
19 节点链路
完整流程：需求评审→需求确认→方案设计→方案确认→Pre-Mortem→实施计划→验收标准确认→拉变更→建分支→建 worktree→开发→编译→单测→ATDD→证据链→部署预发→接口测试→上线确认→验收报告
由意图 × 风险动态裁剪：QUERY 不要求任何产物、BUG_FIX/LOW 只查 5 个节点、FEATURE/HIGH 查满 19 个。
硬规则：改完必部署——只要检测到真实业务代码改动，自动把部署预发、接口测试追加为必需节点。
评测平台
核心理念：评测平台是评估者，不是执行者。只检测被试 claude 是否走完了 harness 的每个节点，绝不替它去执行部署或测试。
七维评分：
| 维度 | 权重 | 检查什么 |
|---|---|---|
| 流程完整性 | 22% | 产物文件在不在 |
| 代码正确性 | 22% | 真编译、真跑单测 |
| 门禁通过率 | 15% | G1-G8 通过率 |
| 上下文效率 | 12% | Token 消耗 vs 产出 |
| 人工介入率 | 10% | 需要人介入的次数 |
| 经验复用率 | 10% | pattern/instinct 命中次数 |
| 诚实度 | 9% | 自报结果 vs 真实结果差距 |
关键判断：宁要可复现的「粗糙分」，不要会漂移的「精准分」。
关键洞察
堆 prompt 是负债，做框架才是资产：对付 AI 的不确定性，prompt 约束是说服，不是强制
主会话应退化成一个纯执行器：不是能力不足，是职责收窄——像微服务里的 thin controller
上下文不是免费缓冲区，是稀缺资源：每份 context 只含该阶段所需最小集，用完即释放
评测驱动自进化：有确定性分数，harness 才能自进化——创建→评测对比→激活基线→收集弱项
任何 AI 工作流都可工程化：给它分层的约束、外置的状态、确定性的评分，让每一次改动都能被证明是进步还是退步