TL;DR
Harness Engineering 不是新范式，是软件工程基本功在 AI 时代的强制兑现——你欠的文档债、流程债、架构债，AI 会让你加倍还。
颠覆的真相
AI coding 很火，Harness Engineering 这个词更火。
OpenAI 用它造出了 100 万行代码，Anthropic 在探索让 Agent 自己迭代产品，Cursor 在用几百个 Agent 并行推进大型项目。每个人都在谈这是新范式、新方法论、软件工程的下一个时代。
但拆开看，这些团队做的第一件事是什么？
写文档。定流程。把架构约束编码进工具链。
这不是新东西。这是你本来就该做、但一直没做好的事。
AI coding 不会替你省掉软件工程的基本功——它会让你欠的债，加倍奉还。
大家期待错了方向
AI coding 工具出来之前，大家最烦什么？
写文档。开需求评审会。维护架构规范。定义 DoD。做 code review。这些事费时间、见效慢、没有人愿意当那个 " 非要搞流程 " 的人。
所以大家对 AI coding 的潜台词是：终于可以不搞这些了。让 AI 直接写代码，快速出结果，流程的事以后再说。
现实正好相反。
OpenAI 的团队在五个月内从 1 万行代码扩展到 100 万行，全程 0 行手写代码。但他们做的第一件事，是把 AGENTS.md 瘦到 100 行、把真正的知识分层放进 docs/、让 doc-gardening agent 定期扫描过期文档。他们花了大量时间在信息架构上，而不是代码本身。
Anthropic 的团队让 Agent 跨多个 session 自主开发产品。但他们解决的第一个问题，是 Agent 没有记忆——于是设计了 init.sh、claude-progress.txt、标准化的 git commit 格式。这些东西加在一起，就是一套项目交接规范。
Cursor 的团队用几百个并行 Agent 推进大型项目。他们总结的最重要教训之一：prompt 比 harness 更重要，约束比指令更有效。翻译成人话就是——你定义得越清楚，AI 犯的错越少。
你不搞流程，AI 不会帮你搞。它只会在没有流程的环境里，以更快的速度把问题放大。
没有银弹，但有三条绕不过去的原则
OpenAI 用 linter，Anthropic 用 progress.txt，Cursor 用 scratchpad。具体实现各不相同，没有一套拿来就能用的标准答案。
但往下挖，三家有三个共同点，没有例外。
1. 可见性：Agent 看不见的信息不存在
飞书文档里讨论的架构决策，钉钉群里的产品对齐，企业微信里口头确认的开发规范——对 AI 来说，这些东西不存在。
OpenAI 的团队有一句话说得很直接："Codex 看不见的就不存在。"
这不是 AI 的缺陷，这是事实。所有关键上下文必须显式存在、版本控制、放在 repo 里。你以为 " 大家都知道 " 的东西，AI 不知道。你以为 " 以后再写 " 的文档，AI 现在就需要。
2. 状态持久化：AI 没有记忆，你得替它设计
每次新 session，Agent 从零开始。它不知道上次做到哪里，不知道踩过什么坑，不知道下一步是什么。
Anthropic 的解法是 claude-progress.txt + 标准化 git commit。Cursor 的解法是频繁重写的 scratchpad。形式不同，本质一样：有人得设计跨 session 的信息载体。
这就是你本该写的交接文档、sprint 记录、技术债追踪。以前没人逼你做严，现在 AI 逼你。
3. 质量门禁：不能靠 Agent 自评
Agent 评价自己的作品会系统性偏正——这是 Anthropic 明确说出来的。让 Generator 自我批评，远不如训练一个独立的 Evaluator 来得有效。
OpenAI 的做法是 linter：不通过就不开 PR，没有商量余地。Anthropic 的做法是硬性阈值：任一维度不达标，整个 sprint 重来。
这就是 Definition of Done。以前它可以模糊，靠人判断，出了问题再说。现在它必须明确、可执行、机械化——否则 AI 自己决定什么叫完成，而它的标准往往比你想的低。
底层逻辑
为什么这三条绕不过去？
因为不管是文档、流程规范、linter 规则、progress 文件，还是 git commit message——最终喂给模型的，都是 token 序列。这是无法再进一步抽象的事实。
模型不会开会，不会看眼色，不会靠上下文猜你的意图。它只处理 context window 里的内容。你送进去的 token 质量决定了它输出的质量。
这件事换一个角度看：传统软件工程其实也在做同样的事——只不过 " 模型 " 是人脑，信息载体是文档、会议纪要、口头沟通和代码注释。人脑有容错能力，能猜意图、能靠经验补全缺失的信息。LLM 没有这个容错空间，它只处理被显式送进来的内容。
所以 Harness Engineering 的本质不是新方法论，而是一个重新表述的老问题：
如何把软件工程的知识、流程和约束，转化成高质量的 token 序列，在正确的时机送到模型的 context window 里。
你的文档写得烂，AI 读到的就是烂的。你的 DoD 模糊，AI 就自己决定什么叫完成。你的架构规范只活在老工程师的脑子里，AI 永远不会知道。
这不是 AI 的问题。这是你欠的债。
你准备好了吗？
回到最开始的问题。
那些在喊 Harness Engineering 的团队——OpenAI、Anthropic、Cursor——他们不是发明了什么新东西。他们是在 AI 逼迫下，把软件工程该做的事做严了。
你的团队呢？
关键决策有没有写进 repo？还是散落在钉钉消息、飞书文档和某人的脑子里？
你们的 Definition of Done 是明确的、可执行的？还是 " 大家都懂 " 那种？
架构规范有没有机械化执行的保障？还是靠 code review 时老工程师的眼力？
项目交接靠的是文档，还是口口相传？
这些问题，在纯人类团队里可以将就。工程师有容错能力，可以靠经验和沟通补漏洞。
但 AI 没有。
你们现在给人用的那套流程和文档，够格喂给 AI 吗？
参考文章
- Ryan Lopopolo, Harness engineering: leveraging Codex in an agent-first world, OpenAI, 2026-02-11
- Wilson Lin, Scaling long-running autonomous coding, Cursor, 2026-01-14
- Wilson Lin, Towards self-driving codebases, Cursor, 2026-02-05
- Prithvi Rajasekaran, Harness design for long-running application development, Anthropic, 2026-03-24
