夜雨聆风2026 年 3 月。我在一个技术群里看到一段对话：
A：「Claude Code 太强了，我让它帮我重构了一个 5000 行的项目，40 分钟搞定。」B：「我用 Claude只能对话啊。」C：「你们不觉得奇怪吗？底层都是 Claude，为什么不同工具差这么多？」
这个问题问到了点上。
底层模型一样。Claude 3.5 Sonnet 就是 Claude 3.5 Sonnet。但 Claude Code、Codex、Cursor、Windsurf 用起来完全不同。
为什么？
答案是：Harness。
你的第一反应可能是：Harness？马具？
对。就是那个意思。马的力量比人大得多，但没有缰绳和马鞍，你控制不了它。Harness 就是给 AI 套上的「缰绳和马鞍」。
这篇文章会讲清楚三件事：
1. Harness 是什么 2. Harness 的四个支柱 3. 为什么 Harness 才是 AI Agent 的真正战场
§01 一个改变一切的发现
2025 年 11 月。OpenAI 发布了 Codex CLI。
我第一时间装上了。试了几个任务，感觉还行，但没有特别惊艳。
然后我看到了一篇博客。作者叫白家杰，他提出了一个概念：Harness Engineering。
他写道：
AI 开发工程化的核心不是「调模型」，而是「设计 Harness」。Harness 决定了 AI 在特定场景下的行为边界、能力上限和可靠性。
我读了三遍。然后回头看我用过的所有 AI 编程工具。
突然全通了。
Jarvis 说：我之前一直以为，AI 编程工具的好坏取决于模型能力。模型越强，工具越好。但 Harness Engineering 这个概念让我意识到：模型只是引擎，Harness 才是整辆车。同样一台发动机，装在拖拉机上和装在赛车上，表现完全不同。
01.1 模型 vs Harness
先厘清两个概念。
模型：AI 的「大脑」。Claude、GPT、Gemini。它负责理解、推理、生成。
Harness：AI 的「身体和规则」。它决定模型在什么场景下、用什么工具、按什么流程、受什么约束来执行任务。
打个比方：
模型决定「能不能做」。Harness 决定「怎么做、做到什么程度、什么时候停」。
概念连接：如果你用过 ChatGPT 和 Claude Code 做同一个编程任务，你一定能感受到差异。ChatGPT 你得一步步告诉它「先读这个文件，再改那行代码，然后跑测试」。Claude Code 你说一句话，它自己读文件、改代码、跑测试、修 bug，全干了。区别不在于模型（底层可能都是 Claude），区别在于 Harness。
01.2 Harness Engineering 的四个支柱
白家杰把 Harness 拆成了四个支柱：
| Rule | ||
| Skill | ||
| Workflow | ||
| Script |
这四个支柱不是独立的。它们互相依赖、互相增强。
Rule 定义边界 ↓Skill 提供能力 ↓Workflow 编排流程 ↓Script 自动执行 ↓结果反馈到 Rule（迭代改进）Stardust 说：我花了三个月才真正理解这四个支柱的关系。一开始我只关注 Skill（写各种技能），后来发现没有 Rule 约束，Skill 会乱用。加上 Rule 之后，发现没有 Workflow 编排，复杂任务还是搞不定。最后加上 Script 自动化，才真正跑通了整个闭环。
§02 Rule：AI 的行为边界
Rule 是 Harness 的第一个支柱。它回答的问题是：AI 能做什么、不能做什么、怎么做。
02.1 CLAUDE.md 的力量
Claude Code 的 Rule 系统是 CLAUDE.md。你在项目根目录放一个 CLAUDE.md 文件，Claude Code 每次启动都会读取它。
一个典型的 CLAUDE.md 长这样：
# 项目规范## 技术栈- Python 3.11- FastAPI- PostgreSQL## 代码规范- 使用 type hints- 函数名用 snake_case- 每个函数必须有 docstring## 禁止事项- 不要修改 migrations/ 目录- 不要直接操作生产数据库- 不要使用 any 类型## 测试要求- 每次修改必须跑通 pytest- 新功能必须有测试覆盖这 30 行文字，彻底改变了 AI 的行为。
没有 CLAUDE.md 的时候，Claude Code 可能会：
• 用 JavaScript 写 Python 项目 • 修改数据库迁移文件 • 不写测试就提交代码
有了 CLAUDE.md，它被约束在一个明确的边界内行动。
核心建议：写 CLAUDE.md 的时候，重点不是「你希望 AI 做什么」，而是「你不希望 AI 做什么」。禁止事项比推荐事项更重要。
02.2 Rule 的层次
Rule 不是一层的。它有层次：
~/.claude/CLAUDE.md | |||
项目/CLAUDE.md | |||
模块/CLAUDE.md | |||
层次越深，优先级越高。项目 Rule 覆盖全局 Rule，临时 Rule 覆盖项目 Rule。
Stardust 说：我一开始只写了全局 Rule，结果发现不同项目的需求差异很大。比如有些项目用 Python，有些用 TypeScript。全局 Rule 写了「用 type hints」，TypeScript 项目就报错。后来我学会了分层，全局只写通用规范，项目级写具体约束。问题解决了。
02.3 Rule 的设计原则
设计 Rule 有几个原则：
原则一：正向约束优于负向约束
# 不好不要写复杂的代码# 好单个函数不超过 50 行嵌套层级不超过 3 层「不要做 X」是模糊的。「做 Y」是可执行的。
原则二：可验证优于主观判断
# 不好代码要写得优雅# 好函数圈复杂度不超过 10没有重复代码块（超过 3 行的重复必须提取函数）AI 无法判断「优雅」，但能计算「圈复杂度」。
原则三：具体数字优于模糊描述
# 不好响应时间要快# 好API 响应时间 < 200ms（P95）数据库查询 < 50ms核心建议：写 Rule 的时候，想象你在给一个聪明但没有常识的实习生写工作手册。它能力很强，但不知道你的偏好和底线。你得说清楚。
§03 Skill：可复用的能力单元
Skill 是 Harness 的第二个支柱。它回答的问题是：AI 会什么、怎么用、什么时候用。
03.1 什么是 Skill
Skill 是封装好的知识和能力。一个 Skill 包含：
举个例子。我有一个 baoyu-post-to-wechat Skill，专门用于发布公众号文章。它包含了：
1. Markdown 转微信 HTML 的方法 2. API 凭证的配置方式 3. 封面图的处理逻辑 4. 错误排查指南
没有这个 Skill，我每次发文章都要重新研究一遍微信 API。有了它，一句话搞定。
Stardust 说：我第一个 Skill 是关于 PDF 导出的。当时我花了一整天研究怎么把 Markdown 转成好看的 PDF。踩了无数坑。转完之后我就想：这个过程能不能记下来，下次直接用？于是写了第一个 Skill。从那以后，我每做完一个复杂任务，都会把过程记录成 Skill。
03.2 Skill 的设计模式
好的 Skill 有几个共同特征：
特征一：自包含
一个 Skill 应该包含所有它需要的信息。不需要外部依赖（除了系统工具）。
# 好的 Skill- 完整的执行步骤- 所有需要的命令- 错误处理方案# 不好的 Skill- 「参考官方文档」- 「用你熟悉的方式」- 「看情况处理」特征二：可验证
每个步骤完成后应该有验证方法。
## 验证步骤1. 运行 `pytest` 确认测试通过2. 检查 `ls output/` 确认文件生成3. 访问 URL 确认服务启动特征三：有陷阱记录
踩过的坑要记下来。这是 Skill 最有价值的部分。
## 陷阱记录1. macOS 的 sed 和 Linux 的 sed 语法不同，用 `sed -i ''` 而不是 `sed -i`2. Python 3.12 的 `type` 语法在 3.11 上不支持3. 微信 API 的 IP 白名单需要几分钟才能生效核心建议：写 Skill 的时候，问自己一个问题：「如果三个月后的我看到这个 Skill，能直接用吗？」如果答案是「还需要查别的资料」，说明 Skill 不够完整。
03.3 Skill 的复用和组合
Skill 不是孤立的。它可以被复用和组合。
复用：同一个 Skill 可以用在不同的项目里。比如「Markdown 转 PDF」这个 Skill，我用它导出了 3 本书。
组合：多个 Skill 可以组合成更复杂的能力。比如：
写作 Skill + 配图 Skill + 发布 Skill = 公众号发布流水线研究 Skill + 写作 Skill + QC Skill = 橙皮书创作流程Stardust 说：我目前有 50 多个 Skill。有些是我自己写的，有些是从社区安装的。它们就像乐高积木，单独看很小，组合起来能搭出很复杂的东西。最近我用 5 个 Skill 组合了一条「公众号全自动发布流水线」，从写作到配图到发布，一句话搞定。
§04 Workflow：任务编排的艺术
Workflow 是 Harness 的第三个支柱。它回答的问题是：复杂任务怎么拆解、怎么编排、怎么保证质量。
04.1 为什么需要 Workflow
简单的任务不需要 Workflow。你说「帮我写个函数」，AI 直接写就行了。
但复杂任务需要编排。比如：
• 「帮我重构这个 5000 行的项目」 • 「帮我写一本橙皮书」 • 「帮我做一次完整的代码审查」
这些任务有多个步骤，需要多次交互，涉及多个 Skill。没有 Workflow，AI 会乱来。
概念连接：Workflow 就像菜谱。你告诉厨师「做一顿法式大餐」，他需要知道先做什么后做什么、每道菜怎么做、什么时候上菜。Workflow 就是这个菜谱。
04.2 Kanban 模式
Hermes Agent 的 Workflow 系统是 Kanban。它把任务分成几列：
每张卡片是一个任务。卡片可以被移动、拆分、合并。
Kanban 的好处是：
1. 可视化：一眼看到所有任务的状态 2. 限制在制品：同时进行的任务数量有限制 3. 流动感：任务从左到右流动，有成就感
Stardust 说：我用 Kanban 管理橙皮书的写作。一本 17 章的书，拆成 17 张卡片。每天推进 2-3 张。看着卡片从 Backlog 流到 Done，比「写完一章是一章」有节奏感多了。
04.3 两阶段审查
复杂任务的 Workflow 有一个关键设计：两阶段审查。
阶段一：执行 - 子 Agent 1：写代码 - 子 Agent 2：写测试 - 子 Agent 3：写文档阶段二：审查 - 审查 Agent：检查代码质量、测试覆盖、文档准确性 - 如果有问题 → 打回重做 - 如果没问题 → 合并这个模式来自软件工程的 Code Review 流程。AI 也需要 Code Review。
核心建议：复杂任务一定要有审查环节。AI 和人一样，会犯错。审查不是不信任，是质量保证。
04.4 Workflow 的设计原则
原则一：每步有明确的输入输出
步骤 1：读取需求文档 → 输出：任务列表步骤 2：逐个执行任务 → 输出：代码变更步骤 3：运行测试 → 输出：测试报告步骤 4：生成文档 → 输出：API 文档每一步的输入是上一步的输出。没有模糊地带。
原则二：失败可回滚
如果步骤 3 失败： - 回滚步骤 2 的代码变更 - 分析失败原因 - 重新执行步骤 2原则三：进度可追踪
总任务：17 章已完成：8 章进行中：1 章剩余：8 章预计完成：明天Stardust 说：我见过太多人用 AI 做复杂任务，结果做了一半不知道做到哪了、还有多少没做。Workflow 的价值不仅是「安排任务」，更是「让进度可见」。
§05 Script：自动化的最后一公里
Script 是 Harness 的第四个支柱。它回答的问题是：重复性工作怎么自动化、怎么保证一致性、怎么节省时间。
05.1 什么是 Script
Script 是可执行的代码片段。它把重复性的操作封装起来，一键执行。
举个例子。我每次写完橙皮书，都要：
1. 跑 QC 检查 2. 导出 PDF 3. 生成封面 4. 发布到公众号
没有 Script 的时候，这四步要手动操作。有了 Script，一句话搞定：
hermes run publish-book --file book.md --theme modernStardust 说：我写过一个 QC 检查脚本，检查橙皮书的 16 项质量指标。没有这个脚本的时候，我得一项一项手动检查，每次花 30 分钟。有了脚本，3 秒出结果。省下来的时间用来写更多内容。
05.2 Script 的设计原则
原则一：单一职责
一个 Script 只做一件事。不要写一个「万能脚本」。
# 好check-quality.py # 只检查质量export-pdf.py # 只导出 PDFpublish-wechat.py # 只发布公众号# 不好do-everything.py # 什么都做原则二：可组合
Script 之间可以组合。通过管道、参数、返回值连接。
check-quality book.md && export-pdf book.md && publish-wechat book.md原则三：有日志
Script 执行过程要有日志。出了问题能追溯。
logging.info("开始检查质量...")logging.info(f"检查项：{len(checks)} 项")logging.warning("第 3 项未通过：缺少 Stardust 说")logging.error("致命错误：文件不存在")核心建议：如果你发现一个操作你做了三次以上，就该写成 Script。第一次手动做，第二次记笔记，第三次写 Script。
05.3 Terminal 的力量
Hermes Agent 的 Script 系统基于 Terminal。它可以直接执行 shell 命令、Python 脚本、Node.js 脚本。
这意味着：
1. 没有限制：任何能在终端运行的工具，AI 都能用 2. 可组合：通过管道连接多个工具 3. 可调试：出了问题，你可以在终端复现
AI 执行 → terminal("pytest tests/") → 返回结果 → AI 分析Stardust 说：Terminal 是 Harness 最被低估的部分。很多人只把 AI 当作「对话工具」，但 AI 真正强大的地方是「执行能力」。它能运行代码、操作文件、调用 API。Terminal 让 AI 从「能说」变成「能做」。
§06 实战：我怎么用 Harness 写橙皮书
讲了这么多理论，来看一个实战案例。
我用 Hermes Agent 写了一本《Autoresearch 橙皮书》，17 章，799 行。整个过程用了 Harness 的全部四个支柱。
06.1 Rule：写作规范
我写了一个 CLAUDE.md，定义了写作规范：
# 橙皮书写作规范## 风格- 第一人称（"我"、"我的"）- 短句（单句 ≤ 25 字）- 先结论后展开## 结构- §NN 格式章节标题- 每章开头有时间线锚点- 每章结尾有向前桥接## 禁止事项- 不用"综上所述"- 不用"值得注意的是"- 不用模糊量词## 必须包含- 每章至少 1 个「Stardust 说」- 每章至少 1 个「核心建议」- 每章至少 1 个表格这个 Rule 保证了全书风格一致。
06.2 Skill：知识库
我用了几个 Skill：
huashu-bookwriter | |
baoyu-article-illustrator | |
baoyu-post-to-wechat |
每个 Skill 封装了一种能力。组合起来，就是一条完整的创作流水线。
06.3 Workflow：Kanban
我用 Kanban 管理写作进度：
Backlog: §01-§17（17 章）In Progress: §03（当前章节）Review: §01-§02（已完成，待审查）Done: （无）每天推进 2-3 章。每写完一章，从 In Progress 移到 Review。审查通过后移到 Done。
06.4 Script：自动化
我用了几个 Script：
qc_check.py | |
export_pdf.py | |
wechat-api.ts |
写完一章，跑 QC。全书写完，导出 PDF。然后一键发布。
Stardust 说：整个流程下来，我最大的感受是：Harness 让写作变成了「流水线」。我不再纠结「下一步做什么」，Kanban 告诉我。我不再担心「风格不一致」，Rule 约束我。我不再重复「导出 PDF」，Script 代替我。我只需要专注一件事：写。
§07 Harness 的未来
Harness Engineering 还在早期。但方向已经很清晰了。
07.1 从个人到团队
现在的 Harness 主要是个人使用。未来会走向团队。
想象一下：一个团队共享一套 Rule、Skill、Workflow。新人加入，读一遍 Rule 就知道团队规范。有经验的人把知识写成 Skill，新人直接用。Workflow 保证每个人的工作有序衔接。
概念连接：这就像公司的 SOP（标准操作流程）。Harness 把 SOP 变成了可执行的代码。
07.2 从手动到自动
现在的 Harness 需要手动设计。未来会自动进化。
AI 会分析你的行为模式，自动提取 Rule。它会观察你重复的操作，自动生成 Skill。它会学习你的工作流程，自动优化 Workflow。
你工作 → AI 观察 → 自动提取规则 → 自动生成 Skill → 自动优化 WorkflowStardust 说：Hermes Agent 的记忆系统已经在做这件事了。它会记住你的偏好、你踩过的坑、你常用的操作。下次遇到类似情况，它会自动应用这些知识。这是 Harness 自动进化的雏形。
07.3 从工具到生态
现在的 Harness 是一个个独立的工具。未来会形成生态。
Skill 可以分享。Workflow 可以复用。Script 可以发布。Rule 可以继承。
想象一个 Skill 市场：
搜索：公众号发布结果： - baoyu-post-to-wechat（宝玉出品，4.8 分） - wechat-publisher-pro（社区出品，4.5 分） - simple-wechat-post（轻量版，4.2 分）你不需要从零开始。站在别人的肩膀上。
核心建议：现在就开始积累你的 Skill 库。每做完一个复杂任务，把过程记录成 Skill。这些 Skill 是你最宝贵的资产。它们是你知识的可执行版本。
§08 给你的三个建议
写到这里，你可能在想：我知道 Harness 很重要，但我该怎么开始？
三个建议。
建议一：从一个 Rule 开始
不要一上来就搭建完整的 Harness。从一个 Rule 开始。
给你的 AI 写一个 CLAUDE.md。内容不用多，20 行就够：
# 我的项目规范## 技术栈[你的技术栈]## 代码规范[你的规范]## 禁止事项[你不希望 AI 做的事]写完之后，用 AI 做一个任务。感受一下 Rule 带来的变化。
建议二：记录你的第一个 Skill
下次你做完一个复杂任务（花了一个小时以上的），花 10 分钟把过程记录下来。
# 任务：XXX## 步骤1. 第一步2. 第二步3. 第三步## 陷阱1. 容易犯的错误2. 容易忽略的细节## 验证1. 怎么确认做对了这就是你的第一个 Skill。
建议三：让 AI 帮你建 Harness
Harness 不需要你一个人建。让 AI 帮你。
你可以对 AI 说：
「帮我分析一下我过去一周的操作，提取出可以复用的 Skill。」
「帮我写一个 Workflow，管理我的日常开发任务。」
「帮我写一个 Script，自动化我的部署流程。」
AI 不仅是 Harness 的使用者，也是 Harness 的建设者。
Stardust 说：我现在的 Harness 里，有一半的 Skill 是 AI 帮我写的。我描述需求，它生成 Skill，我审查修改。这个过程本身就是 Harness 的一部分——用 AI 来增强 AI 的能力。
§09 写在最后
回到文章开头的那个问题：
「底层都是 Claude，为什么不同工具差这么多？」
现在你知道答案了。
模型是引擎。Harness 是整辆车。
Claude Code 之所以强，不是因为它用了更好的模型，而是因为它的 Harness 设计得好。CLAUDE.md 定义了行为边界。Skill 系统提供了可复用的能力。Terminal 赋予了执行能力。Workbench 支持了并行任务。
Codex 之所以稳，是因为它的 Harness 更保守。权限控制更严格，执行流程更规范。
Cursor 之所以灵活，是因为它的 Harness 更开放。IDE 集成更深，自定义空间更大。
Harness 决定了 AI 的性格。
同样的模型，不同的 Harness，表现完全不同。就像同一个人，穿西装和穿运动服，行为方式会不一样。
Stardust 说：2026 年 5 月。我用 Hermes Agent 写了 3 本书、发了 10 篇公众号、维护了 82 个 Wiki 页面。这些不是我一个人干的，是我和 AI 一起干的。Harness 是我们之间的「契约」——它定义了谁做什么、怎么做、做到什么程度。没有 Harness，AI 是一匹野马。有了 Harness，它是我的坐骑。
Karpathy 说过一句话：
"The era of meat computers doing AI research is long gone."
我想加一句：
"The era of using AI without a Harness is also long gone."
2026 年了。不用 Harness 驾驭 AI，就像不用缰绳骑马。
能骑。但跑不远。
这是 Stardust 的第二篇公众号文章。如果觉得有用，欢迎关注。
下一篇，我会讲怎么从零搭建自己的 Harness。
附录：Harness 工具对比
数据截至 2026 年 5 月。各工具功能可能有更新。
