阿里巴巴 Harness AI工程化编程实践

杜学友 阿里云开发者

核心观点：AI Coding 的瓶颈正从"模型能力"转移到"流程工程"——模型已经足够聪明，但不稳定，而稳定性必须由外部框架供给。
读完你能带走：一套可抄的 harness 分层结构、一个把"流程当被测对象"的评测方法、4 条用代价换来的踩坑教训，以及一个能迁移到任何 AI 工作流的工程化模式。（文章内容基于作者个人技术实践与独立思考，旨在分享经验，仅代表个人观点。）

引言

我曾经用一个不断膨胀的 CLAUDE.md 解决 AI "不守纪律"的问题——把所有规矩写进去：先写单测、部署前评审、提交前合 master。它确实管用了三天。 然后问题以更严重的形式回来了：规则多到撑爆上下文，模型读完规则就没"脑容量"读代码，于是它开始遗忘、串味、自我矛盾。

那一刻我意识到：对付 AI 的不确定性，堆 prompt 是负债，做框架才是资产。 这篇文章就是这套框架（harness）两个月的演进复盘。

一、harness 是什么，它到底解决什么

harness = 把"AI 该怎么干活"固化成可执行、可约束、可评测的工程框架。 它和"写更好的 prompt"有本质区别——prompt 是一次性的说服，harness 是结构性的约束。模型供给智商，harness 供给纪律。

用过 AI 编码的人大概率遇到过这三个痛点：

这些痛点不是个人运气差——它们有结构性的技术根因。VILA-Lab 对 Claude Code 的逆向工程[1]揭示：Claude Code 的记忆完全基于文件系统（CLAUDE.md + JSONL 日志），没有向量数据库、没有 Embedding。上下文管理靠一条 5 层渐进式压缩管线——从裁剪低优先级提示、截断工具输出，一直到最后手段的全量模型摘要（Auto-Compact）——流程状态细节恰恰会在这一层被丢失。Devin 的 CPO 在 Latent Space 播客[2]中坦承：当记忆达到数千条时，如何在正确的时机检索到正确的记忆——"尚未解决"。

Agent "遗忘"不是 bug，是当前架构的必然代价。遗忘有三重根因——压缩丢失（Auto-Compact 省略"看似不重要"的流程步骤）、检索失败（记忆文件在但没被加载进上下文）、指令遵循失败（信息都在但模型仍然跳步）。harness 的三层设计（规则外置、状态持久化、门禁阻断）恰好对应这三个根因，逐一堵漏。

二、搭建：我的 harness 长什么样

这是全文重点。我的 ~/.claude 不是一堆零散配置，而是一个三层加载模型——核心设计思想只有一句：把上下文当预算来管理。

判断：主会话的上下文是最贵的资源，不是免费的草稿纸*。 所以分层的唯一标准不是"按功能分类"，而是"按何时被读取"——常驻的极小，深的按需加载。*

下面逐层讲清楚：每层放什么、解决什么、付出什么代价。

2.1 常驻入口层：CLAUDE.md+CLAUDE.local.md

放角色、代码偏好、流程触发规则、G1–G8 门禁速查。关键设计是 CLAUDE.local.md 自包含、不依赖全局 @import：新项目接入只需拷一份模版进去就能独立运作。

• 解决：每个项目的流程规范彼此隔离、互不串味。
• 效果：主会话常驻上下文压到 ≤8K，把宝贵窗口留给真正的代码。

2.2 原子规则层：rules/（7 个）

每个规则单一职责、可被按需引用。它们的本质，是把踩过的坑固化成强制约束：

每条规则都是一次事故的墓志铭。 坑只踩一次，之后由规则兜底——这是 harness 最朴素也最值钱的复利。