在 AI 时代，人要学会 思考并执行对的事情，而不是 执着于把事情做对。由于 AI 无比擅长后者，人的价值就会不断趋近于0。传统的“打工思维”在 AI 时代会最快被淘汰。
最近几周，在阅读过一系列 Harness Engineering 相关的博客、公众号文章、长视频，并且在日常工作深度使用 AI 辅助编程工具后，我尝试在本文中记录下自己的理解与思考。
什么是 Harness Engineering
Harness 意为马具、轭具，这里将 AI Agent 比喻成擅长奔跑且需要约束的马匹，它固然可以让我们走的更快更远，但只有套上缰绳、嚼头、鞍鞯这些马具，才能正确地奔向目的地。如果不加约束，也许会在错误的方向上越走越远，白白浪费时间、算力。
常见的几种 AI 辅助编程模式
我是2023年开始注册并使用 AI 工具的，当时高频使用的是 ChatGPT 网页端，尽管相比于今天的v5.4，当时模型的能力还略显稚嫩，但它已经能够与人类进行高质量的自然语言对话了。而逐渐习惯 AI 编程，则是最近一年开始的事。既然要探讨 AI 辅助编程，有必要梳理一下常见的模式，如下表。
| AI 辅助编程模式 | 举例 | 特点 | 不足 |
|---|---|---|---|
| 网页问答式 | ChatGPT，DeepSeek | 一问一答，消除搜索引擎带来的筛选成本 | 难以维持长期会话，无法理解大型项目 |
| 代码补全 | Copilot，各种IDE插件 | 具备一定的上下文意识，tab编程 | 系统设计能力有限 |
| 代理式 | Codex，Claude Code（早期阶段） | 自然语言多轮交互，我看AI写代码 | 缺乏长期记忆 |
【图】
这里列出本人曾经长期使用过的 AI 辅助编程模式，截至目前，使用最多的还是“代理式/Agent”。不过，为了解决缺乏长期记忆、对项目理解有限的问题，已经逐渐开始向 Harness Engineering 转变。
在我看来，AI 之所以在长会话的场景下表现不稳定，是单一的上下文机制导致的必然结果。AI 是一个初始能力很强的人，他可以做任何事情、完成任何任务，这是 AI 的优势，同时也导致了他的缺陷。由于上下文不可控，会出现以下两种问题：
- 注意力分散：使用者提出新的问题时，AI 的注意力仍然停留在老的问题，导致将老问题带来复杂度引入到新问题的解答过程中。
- 上下文腐烂：会话过长后，最早的记忆会被压缩/丢弃。
AI 辅助编程的三个阶段
从 关注点不同 的角度，按照时间顺序，可以将 AI 编程 由浅入深 划分为三个阶段。
注意这只是根据经验进行的划分，实际上并没有官方对此给出明确概念界定。
阶段一：Prompt 提示词优化阶段
这个阶段关心的，是如何写出 更好的提示词，使 AI 聚焦到某个特定问题上，很多时候需要人为构建好约束条件，防止 AI 没找到重点，导致发散思维天马行空；亦或找错了重点，在细枝末节上不停追问。因此产生了 提示词工程师 这样的岗位/技能。
阶段二：Context 上下文构建阶段
这个阶段开始着眼于维护长期会话的需求，由于大型项目持续迭代的需要，我们希望 AI 能够理解项目全景，并保持长期记忆。从而让 AI 在这样的框架下，完成细化的开发任务。因此促生了上下文管理这一核心讨论问题。这方面比较有代表性的是 “RAG（Retrieval-Augmented Generation，检索增强生成）”。通过向量数据库提供持久化存储，形成知识库。在未来的对话中，LLM 在收到问题后，先在知识库中检索，拼接上下文，然后再给出答案。
阶段三：Harness 系统工程阶段
Context 技术为 AI 赋予了长期记忆，使 AI 向“拟人化”迈出了重要的一步。初始状态下的 AI 像一本百科全书，可以对任何问题给出答案，但缺乏对项目现状的认知。我们常说，“要爱具体的人，而非抽象的人类”，在拥有长期记忆以后， AI 已经可以很接近具体的人了。而人只有记忆还不够，需要持续迭代、进化、成为特定工程范围内的专家。
我把这一阶段称为“系统工程阶段”，是因为此时关注的是 Agent 作为一个系统，应当具有分辨执行结果对错（评价）、自我进化（迭代）的能力，这也是 系统 有别于 单一功能 的地方。
Harness Engineering 概念的提出与演进
【图，Mitchell】
Harness Engineering 这个词，最早出现于2026年2月 Mitchell Hashimoto 的博客《My AI Adoption Journey》，他在文中陈述到，“每当 Agent 犯错，就工程化地补上相应的机制，以使未来不再犯同类的错误”。
虽然 Mitchell 是最早提出这个词的人，但我们应当认识到，这种“从错误中学习、持续迭代”、“构建正反馈回路”，是软件工程中早已有之的概念，只不过不叫 Harness 这个名字。
甚至，当前它的主流含义，早已远远超出最初提出时候的范围。现在业内对此的理解是：不去直接调用模型本身，而是去设计模型外部的一整层运行系统 ，包括工具、权限、执行流程、验证机制、日志、反馈回路、状态管理、安全约束，从而让 Agent 在更加可靠的工程环境里完成任务。
也可以概括为，Harness Engineering 是指围绕 Agent 搭建可控、可验证、可观测的运行外壳的工程思想。
软件开发：总体大于部分之和
与个人主导的小工具开发不同，商业化软件的实现和维护是一项系统工程，它包含 需求评估、策划方案、UI设计、软件设计、代码实现、测试验证、bug修复 等诸多环节，涉及到 产品经理、UI/UI设计师、软件工程师、系统工程师、品质/测试工程师 的角色。商业化软件交付的是一个整体，如果最终版本没有验收合格，那么其中的任何一个过程都是徒劳的。可以认为，各个步骤/环节只有对于最终合格的整体才有意义，因此对于软件开发而言，总体大于部分之和。
系统三构件：要素、连接、功能和目标
在学习 Harness Engineering 过程中，我总是会想起德内拉•梅多斯的《系统之美》，正如书中介绍的：
- “系统对外具有整体性，对内则由一整套机制来保持其整体性。”
- “系统并不仅仅是一些事物的简单集合，而是一个由一组互相连接的要素构成的、能够实现某个目标的整体。”
- “系统中存在两种反馈回路：调节回路和增强回路。前者趋向于某一稳定值，后者则不断放大和增强原有的态势。”
【图-系统之美】
为什么是 Harness Engineering
如前文所讲，商业化项目的软件工程，涉及到众多环节、不同角色，因此它是一个系统性问题。系统性的问题需要系统的解决方案，在我看来，Harness Engineering 符合“系统”特征的原因，主要有两点：
- 它对外保持一个整体，对内则由要素、连接、目标三要素有机组成。
- 它具备自我学习、迭代的反馈回路。
因此，自2026年年初以来，在编程领域它的讨论热度始终居高不下，也就不难理解了。
如何设计一个 AI 工作流
我们必须承认，对当下的程序员而言，AI 已经成为一门必修课，而非选修课。于外，所有互联网软件公司都在推行 AI，甚至将 AI 代码生成比例、token 使用数量作为绩效考核指标。于内，我们可以将重复繁杂的编码工作交给 AI Agent 完成，解放自己的时间。
学会AI->使用AI完成日常工作->提高任务完成质量和速度->拥有更多个人时间->学习更多AI。这样正向循环的链条就形成了。
flowchart LR
A[AI能力] -->|+| B[AI使用频率]
B -->|+| C[任务效率与质量]
C -->|+| D[可支配时间]
D -->|+| E[AI学习投入]
E -->|+| A
R((R1 正反馈循环))
R --- A
PDCA 框架——构建正反馈回路
在系统工程领域，存在一个很经典的工程循环框架——PDCA。
- Plan（计划）：围绕目标制定可行的计划，遵循SMART原则。
- Do（执行）：履行计划的各个步骤。
- Check（检验）：校验执行结果，是否达成目标。如果没达成，差距在哪里，造成差距的原因是什么。
- Acquire（提升）：吸收经验，避免下次犯同类错误。总结经验，降低重复建设成本。
所谓 Harness Engineering，在某种程度上也体现了这种思想，让 AI 在约束范围内起舞，通过自我调节，减少由于系统长期运行而产生的熵增。
根据上述信息，遵循 MVP（Minimum Viable Product最小可行产品）我整理出一版搭建 Harness Engineering 的思路，权当作抛砖引玉。
目录结构化
整体的文件夹结构、目录分层如下所示：
your-project/
├─ AGENTS.md
└─ .ai/
├─ subagents/
│ ├─ code-analyst.md
│ ├─ code-implementer.md
│ └─ change-reviewer.md
├─ context/
│ ├─ project-map.md
│ └─ architecture.md
├─ tasks/
│ └─ tasks.md
├─ checks/
│ ├─ build.sh
│ ├─ build.ps1
│ └─ verify_changed_files.sh
└─ memory/
└─ known-issues.md
| 序号 | AI 面临的核心问题 | Harness 解决方法 | 对应文件/文件夹 |
|---|---|---|---|
| 1 | 缺乏持久、稳定、一致的行为规则 | 建立稳定人格 | AGENTS.md |
| 2 | 执行者评估自身失准 | 拆分子Agent，防止单一Agent既当运动员也当裁判 | .ai/subagents目录 |
| 3 | 总写出正确但难以维护的代码 | 约束设计模式，防止自由发挥 | .ai/context/architecture.md |
| 4 | 无法把握项目全貌 | 分模块整理设计思路、方案 | .ai/context/project-map.md |
| 5 | CLI不好用 | 使用明确的任务说明 | .ai/tasks/task.md |
| 6 | 扩散式修改 | 建立代码审查者，限制修改文件、函数数量，限制代码变更行数 | .ai/checks/verify_changed_files.sh |
| 7 | 写出的代码只是看起来对，但无法运行/检验结果 | 建立CI-CD | .ai/checks/build.sh（或者是build.ps1） |
| 8 | 缺乏自我进化 | 经验沉淀，严重错误归档 | .ai/memory/known-issues.md |
文件归一化
所有的规则、脚本文件，都应该使用最朴素的 md、shell 格式，有以下4点好处：
- Open anywhere。人与AI同时可以阅读和编辑。
- 如非必要，勿增实体。遵循单一可信源原则。
- 便于使用 git 进行版本维护。
- 无痛进行模型和工具的迁移，例如从 Codex 迁移为 Claude Code，不需要更改任何文件夹结构和文件内容。
Agent 设计
subagents/
├─ code-analyst.md ---> 分析计划者
├─ code-implementer.md ---> 执行修改者
└─ change-reviewer.md ---> 结果校验者
这里我按照 最小可用原则 拆分出来3个 subagent，分别承担 分析->实现->审查 的角色。每个 subagent 的 md 文件里只写四部分：
- 职责
- 输入
- 输出
- 禁止事项
对于每个 subagent 的内容，可以参考下一篇文章《Harness Engineering 的 AGENTS.md，subagents.md 怎么写？》，此处不再赘述。
软件程序员工作方向的转变
其实在最初写作本文时，我在开头有这样一句话：
全文原创手打，无 AI 参与润色。
review 的时候，我仔细想了想，把这句话删掉了。在这个内容爆发的时代，创作来源是谁并不重要，如果一篇技术文章是成体系、有实用价值的，即便它完全由 AI 生成，又有什么关系？AI 背后是人类几千年历史文化科学技术的积累，远远超过仅仅受了几十年教育的普通创作者。
程序员内核的变化——从“编写代码”到“系统设计”
跟一些同行程序员一样，由于写了十几年代码的关系，古法编程能力 在我心里一直是“优秀程序员”的代名词。但在 AI 时代，这个底层逻辑将很快被改写。程序员千万不要将自己限定在“执行者、码农”的框架内，而是要把自身角色转换为 AI 流程的设计者，从 亲身下地干活 变为 监督 AI 工作。
AI 会替代程序员么？——成熟软件行业对“新手”与“有经验者”的需求变化
同样还有一个广泛讨论的问题，AI 会在多大程度上，替代人类程序员？在我看来，未来的 AI 一定会替代我过去所从事的工作。 这里我强调了 过去，是因为我们不应该忽略，AI 在不断迭代的同时，作为人类我们也是可以持续学习和自升级的。汽车的诞生淘汰掉了马车夫和马具店，同时催生了更加庞大的产业链，制造了上下游更多的工作岗位。
AI“泡沫”？既要冷眼旁观，也要躬身入局
最后我还想讲一点，随着 OpenClaw 在普罗大众中破圈传播，关于 AI 的讨论甚嚣尘上，每隔几天就有新的算法、论文、模型、工具问世，各大厂商争先恐后推出新产品，一片蒸蒸日上的景象，每一个产品问世都恨不得向全世界宣告 “AI 彻底变天了”、“一个人抵得上一家公司”、“彻底颠覆XX行业” 。这些宣传是不是泡沫？当下我们无法判断，只有历史才会给出客观的答案。
在这样的嘈杂中，人不应被冲昏头脑，每有一个新工具问世，就投入 大量时间和精力去尝试。在我看来，这是一种 付出极大机会成本的行为。
使用 AI 的意义应当大于形式，重要的是它帮助我们解决了什么问题，而不是我用了哪些时下最新的工具。冷眼旁观的同时，一定要选择适合自身情况的 AI 产品，学习理解其思想，并深入使用进去，躬身入局，在干中学。
