AI Coding 的终局，不是写更好的 Prompt，而是给 Agent 套上 Harness

AI Coding 的终局，不是写更好的 Prompt，而是给 Agent 套上 Harness

这段时间，我对 AI 编程有一个越来越强的感受：

很多人以为自己和高手之间的差距，是模型不够强，或者 Prompt 写得不够花。

但真正把 Claude Code、Codex 这类工具用到日常开发里以后，你会发现，差距往往不在模型。

同样是一个需求，有的人能让 Agent 稳定读代码、出方案、写测试、跑验证、做 review；有的人则是让它上来就改，改完发现测试没跑、范围失控、接口兼容性也没看。

这中间差的不是"会不会问 AI"，而是有没有一套 Harness。

所谓 Harness，可以理解成给 Agent 套上的"缰绳"：

不是让 AI 自由发挥，而是让 AI 在明确的规则、流程、边界和验证里工作。

我现在越来越觉得，AI Coding 的真正分水岭，不是 Prompt Engineering，而是 Harness Engineering。

目录

1. Vibe Coding 和 Harness Coding 的区别
2. AI 编程的三次升级
3. 一套可用的 Harness 至少要有五层
4. Agent Team 不是万能药
5. 我现在的个人实践
6. AI 失控的几个信号
7. 普通开发者怎么落地
8. 最值得投入的地方

Vibe Coding 和 Harness Coding 的区别

很多人刚开始用 AI 写代码，基本都是 Vibe Coding。

大概是这样的：

我有个需求
↓
随手写一句 Prompt
↓
AI 开始改代码
↓
我再人工兜底

这种方式做 Demo、脚本、小工具没问题。

但一旦进入真实工程，它的问题就会暴露：

• 需求没理解清楚就开写
• 代码没读全就猜实现
• 旧接口兼容性没检查
• 测试没补，甚至没跑
• 改了无关文件
• 最后一句"已完成"，但没有任何验证证据

这就是典型的"让 AI 自由发挥"。

Harness Coding 刚好相反。

它不是问：

怎么让 AI 写得更快？

而是问：

怎么让 AI 按正确流程稳定交付？

我现在更认可这样一个公式：

AI 输出质量
=
上下文质量
×
约束清晰度
×
验证强度

模型能力当然重要。

但在真实工程里，真正决定稳定性的，往往是这三件事：给了它什么上下文，用什么规则约束它，以及最后怎么验证它。

AI 编程的三次升级

我把 AI 编程的演进分成三层。

最早的一层，是 Prompt Engineering。

这个阶段大家关心的是：

我该怎么说？

比如让 AI 扮演高级工程师、给它 Few-shot、写长 Prompt、加各种"请你一步一步思考"。

这些当然有用，但它只是最内层。

再往外一层，是 Context Engineering。

这个阶段问题变成：

我该给 AI 看什么？

AI 不理解项目，很多时候不是它笨，而是它根本不知道项目事实。

比如一个 Java 8 项目，它可能生成 record；一个 MyBatis 项目，它可能凭空写 Repository；一个老接口二开，它可能直接改返回结构，把兼容性弄坏。

所以必须让它先读：

• 项目规则
• 入口代码
• 调用链路
• 数据对象
• 已有测试
• 构建命令

再往外，才是 Harness Engineering。

这个阶段的问题不再是"怎么说"和"看什么"，而是：

整个 AI 开发系统应该怎么运行？

它关注的是：

• 规则怎么写
• 任务怎么入口
• 流程怎么强制
• 哪些行为禁止
• 完成怎么验证
• review 怎么兜底
• 经验怎么沉淀

Prompt 只是点火器，Context 是燃料，Harness 才是工程系统。

一套可用的 Harness 至少要有五层

我现在比较认可的结构，是五层。

Rules：常驻规则

Rules 负责告诉 Agent：

什么永远不能违反

比如：

• 先理解，再修改
• 只做当前任务需要的最小改动
• 禁止顺手重构
• 修改前先看现有实现
• 测试不能删断言、放宽断言、跳过
• Java 项目运行前先判断 JDK
• 未经确认不 commit、不 push

这类规则适合放在 CLAUDE.md 或 AGENTS.md 里。

但这里有一个坑：

不要把 CLAUDE.md 写成百科全书。

它应该是常驻底线，不是所有细节的垃圾桶。

我现在的做法是：

CLAUDE.md 只保留通用底线
具体任务流程放到 personal skills
项目事实放到项目 AGENTS.md

这样上下文更轻，职责也更清楚。

Workflow：任务入口

只写规则还不够。

因为 Agent 会忘。

更稳的方式，是把高频任务做成固定入口。

我现在给自己做了 5 个 personal wrapper skills：

/dev   开发需求入口
/fix   Bug 修复入口
/test  测试入口
/cr    Code Review 入口
/ship  交付收尾入口

以后正常开发，不再随口说：

帮我改一下这个需求

而是：

/dev 给某个接口增加一个能力，保持旧接口兼容

遇到测试失败：

/fix 这个测试失败，先定位根因再修

准备交付：

/ship 做交付前检查

这类入口的价值，不是少打几个字。

它的价值是把正确流程变成默认路径。

Process Skills：流程内核

Wrapper skill 本身不要写太复杂。

它更像调度器，底层真正跑流程的是 Superpowers 这类 workflow skills。

比如一个开发需求可以被导向：

using-superpowers
↓
brainstorming
↓
writing-plans
↓
test-driven-development
↓
verification-before-completion

新需求必须先做设计，不是上来就改。

这点非常重要。

因为真实开发里，很多返工不是代码写错，而是需求边界一开始就没对齐。

所以我的理想流程是：

需求
↓
Spec
↓
Plan
↓
Task
↓
TDD
↓
Verification
↓
Review

这才是 AI Coding 从"能写"走向"能交付"的关键。

Guardrails：边界和拦截

只靠口头规则，还是不够。

有些事情应该从"提醒 AI 不要做"，升级成"AI 想做也做不了"。

典型边界包括：

• 禁止破坏性 Git 命令
• 禁止自动 push
• 禁止删除用户改动
• 禁止改密钥和凭证
• 禁止为了通过测试删除断言
• 禁止没验证就说完成

如果有 hooks 或权限系统，就把这些做成自动拦截。

这就是从"约定"走向"强制"。

Harness 的本质不是相信 Agent 会自觉，而是让系统把它约束住。

Verification：完成必须有证据

AI 最大的问题不是写错。

而是它经常"以为自己写对了"。

所以我现在对"完成"的定义很简单：

没有验证
不算完成

一次任务结束，至少要回答清楚：

• 改了哪些文件
• 每个文件改了什么
• 执行了什么验证命令
• 验证结果是什么
• 哪些没验证，为什么
• 如果涉及测试，测试覆盖了什么场景，关键断言是什么

这就是 /ship 的价值。

它不是写代码的入口，而是防止"草草收尾"的入口。

Agent Team 不是万能药

很多人看到 Subagent、Agent Team，会本能觉得：

并行 Agent 越多，效率越高

实际不是。

Claude Code 里确实有主 Agent、Subagent，也可以通过 Task Tool 做子任务。但所谓 Agent Team，更像一种 Harness 工作流设计，而不是一个神奇按钮。

我的理解是：

大多数开发任务，应该串行
少数调研任务，才适合并行

比如新功能开发、接口二开、Bug 修复，往往有明确依赖关系：

先理解需求
再设计方案
再写测试
再实现
再验证

这种场景更适合 Subagent-Driven 或主会话串行推进。

如果强行并行，反而容易：

• 重复读代码
• 改动互相冲突
• 上下文分裂
• 最后需要大量人工合并判断

真正适合 Agent Team 的，是项目摸底、批量文档、批量审查、模块扫描这类独立任务。

比如：

Agent A 看 Controller
Agent B 看 Service
Agent C 看 Mapper
最后统一汇总

所以我现在的策略是：

90% 任务走稳定串行流程
10% 任务用并行 Agent 做调研或审查

不要迷信 Agent 数量。

真正决定效率的，是流程质量。

我现在的个人实践

我现在把自己的 AI 开发体系分成四个层级。

CLAUDE.md 管底线

这里不再写长篇大论，而是保留全局规则：

• 启动时先检查 skill
• 先理解再修改
• 最小改动
• Debug 先复现和定位根因
• 测试必须有有效断言
• Java 先判断 JDK
• 交付必须说明验证结果

它的定位是：

任何任务都不能违反的底线

Personal Skills 管入口

我把常用任务做成 /dev、/fix、/test、/cr、/ship。

这相当于给自己建立了一个命令面板。

以后不靠临场发挥，而是把任务送进固定流程。

Superpowers 管流程

真正的流程约束交给 Superpowers：

• 新需求先 brainstorming，产出 spec
• 需要计划就 writing-plans
• 修改生产代码前尽量 TDD
• 完成前 verification-before-completion
• Bug 走 systematic-debugging

这让 Agent 更难跳过关键步骤。

Code Review Agent 管审查

我单独建了一个只读的 code review agent。

它只做一件事：

找真实风险

重点看：

• 需求是否满足
• 是否有无关改动
• 是否破坏兼容性
• 是否缺测试
• 是否有弱断言或跳过测试
• Java 业务代码里是否有事务、幂等、日志、远程调用、Redis 等风险

并且它不能改文件，不能 commit，不能 push。

这样 review 和实现就分离了。

AI 失控的几个信号

我现在会重点观察五个信号。

同一个问题反复修

这说明它没理解根因。

不要继续让它试。

应该停下来，重新走 /fix。

修改范围蔓延

你让它改一个点，它改了一堆文件。

这时候要立刻收住范围。

没验证就说完成

这是最常见的问题。

一句"已完成"没有意义，验证命令和结果才有意义。

简单需求写出复杂实现

50 行能解决的问题，写出 500 行。

这不是高级，这是失控。

使用不存在的类、方法、配置

这说明上下文不够，或者它开始幻觉。

解决方式不是继续问，而是让它回到代码事实。

普通开发者怎么落地

如果你也想从 Vibe Coding 走向 Harness Coding，不需要一上来搞很复杂。

可以先做四件事。

写一个短的 CLAUDE.md

不要追求全。

先写底线：

• 先读后写
• 最小改动
• 禁止自动 push
• 修改后必须验证
• 测试不能跳

建几个高频入口

比如：

/dev
/fix
/test
/cr
/ship

让 AI 每次从正确的门进去。

新需求必须先出 Spec

这一条非常关键。

不要让 AI 边想边写。

先让它把需求边界、影响范围、验证方式讲清楚。

你确认后，再进入实现。

完成前必须有 Verification

没有验证结果，就不要接受"完成"。

至少让它说明：

跑了什么
结果如何
没跑什么
为什么没跑

这比多写十条 Prompt 都有用。

最值得投入的地方

AI Coding 的成熟，不是让 AI 越来越自由。

恰恰相反。

成熟的 AI Coding，是让 AI 在越来越清晰的约束里工作。

Prompt 是起点。

Context 是燃料。

Harness 才是工程系统。

如果说以前开发者的核心能力是写代码，那么 AI 时代，开发者的核心能力会越来越变成：

• 定义边界
• 设计流程
• 建立规则
• 做好验证
• 沉淀经验

也就是从 Coder，变成 Constraint Designer。

真正高效的 AI 开发，不是"我让 AI 帮我写代码"。

而是：

我搭了一套系统
让 AI 稳定地交付代码

这才是 Harness Engineering 最值得投入的地方。

如果你也在用 Claude Code、Codex 或其他 AI 编程工具，不妨先从一个短 CLAUDE.md 和几个固定入口开始。

别急着堆工具。

先把流程跑稳。

觉得有用可以收藏，后面我会继续整理一套更完整的 AI 编程工作流实践。