TL;DR
Harness Engineering 并非什么新范式，它只是软件工程基本功在 AI 时代下的强制兑现——你欠下的文档债、流程债、架构债，AI 会让你加倍奉还。
颠覆的真相
AI 编程很火，Harness Engineering 这个概念更火。
OpenAI 用它造出了百万行代码，Anthropic 在探索让 AI Agent 自我迭代产品，Cursor 则用数百个 Agent 并行推进大型项目。一时间，人人都在谈论这是新范式、新方法论，是软件工程的下一站。
但剥开这层华丽的外衣，这些团队首先做的是什么？
写文档，定流程，将架构约束编码进工具链。
这不是什么新鲜事，这恰恰是你本该做好、却一直没做到位的事。
AI 编程不会替你省掉软件工程的基本功——它只会让你欠下的技术债务，加倍偿还。
大家期待错了方向
在 AI 编程工具出现之前，开发者最烦什么？写文档、开需求评审会、维护架构规范、定义“完成标准”（DoD）、做代码审查……这些事费时费力，见效慢，谁也不愿意当那个“死磕流程”的人。
所以很多人对 AI 编程的潜台词是：终于可以绕过这些繁琐流程了。让 AI 直接生成代码，快速出成果，流程的事以后再说。
现实却截然相反。
OpenAI 的团队在五个月内将代码库从 1 万行扩展到 100 万行，全程未手写一行代码。但他们的第一步，是把 AGENTS.md 精简到 100 行以内，将真正的知识分层放入 docs/ 目录，并让一个“文档园丁”Agent 定期扫描过期文档。他们花了大量时间在信息架构上，而非代码本身。
Anthropic 的团队让 Agent 跨越多个会话自主开发产品。但他们解决的第一个问题，是 Agent 没有记忆——于是设计了 init.sh、claude-progress.txt 和标准化的 git commit 格式。这些东西拼在一起，就是一套项目交接规范。
Cursor 的团队用数百个并行 Agent 推进大型项目。他们总结的最重要教训之一是：Prompt 比工具链（Harness）更重要，约束比指令更有效。翻译成大白话就是——你定义得越清晰，AI 犯的错就越少。
你不建立流程，AI 不会替你建立。它只会在缺乏流程的环境里，以更快的速度将问题放大。
没有银弹，但有三条绕不过去的原则
OpenAI 用代码检查工具（Linter），Anthropic 用进度文件，Cursor 用草稿本（Scratchpad）。具体实现各不相同，不存在一套放之四海而皆准的标准答案。
但深入探究，这三家都遵循三个共同的核心原则，无一例外。
1. 可见性：AI 看不见的信息，等同于不存在
那些在飞书文档里讨论的架构决策、钉钉群里对齐的产品需求、企业微信中口头确认的开发规范——对 AI 来说，这些信息并不存在。
OpenAI 的团队有一句直白的话：“Codex 看不见的，就不存在。”
这不是 AI 的缺陷，而是客观事实。所有关键上下文必须显式存在、纳入版本控制、存放在代码仓库里。你以为“大家都知道”的事，AI 并不知道。你以为“以后可以补”的文档，AI 现在就需要。
2. 状态持久化：AI 没有记忆，你得为它设计记忆载体
每次新的会话，AI Agent 都从零开始。它不知道上次做到哪一步，不知道踩过什么坑，也不知道下一步该做什么。
Anthropic 的解决方案是 claude-progress.txt 加上标准化的 git commit。Cursor 的解决方案是频繁重写的草稿本。形式各异，本质相同：必须有人来设计能够跨越会话的信息载体。
这其实就是你本该写好的交接文档、迭代记录和技术债追踪。以前或许没人严格要求你，现在 AI 逼着你做。
3. 质量门禁：不能依赖 AI 的自我评价
让 Agent 评价自己的作品会产生系统性的乐观偏差——这是 Anthropic 明确指出的。让生成器（Generator）进行自我批评，其效果远不如训练一个独立的评估器（Evaluator）。
OpenAI 的做法是硬性的代码检查工具：不通过就无法发起合并请求（PR），没有商量余地。Anthropic 的做法是设定硬性阈值：任何一个维度不达标，整个开发周期就要重来。
这就是“完成的定义”（Definition of Done）。以前它可以模糊，依赖人的判断，出了问题再补救。现在它必须明确、可执行、机械化——否则 AI 会自己决定什么叫“完成”，而它的标准往往比你想象的要低。
底层逻辑
为什么这三条原则无法绕过？
因为无论是文档、流程规范、代码检查规则、进度文件，还是 git 提交信息——最终输入给 AI 模型的，都是一个由 Token 构成的序列。这是一个无法再进一步抽象的基本事实。
模型不会开会，不会察言观色，也不会根据上下文猜测你的意图。它只处理上下文窗口（Context Window）里的内容。你输入 Token 的质量，直接决定了它输出的质量。
换个角度看，传统软件工程其实在做同样的事——只不过“模型”换成了人脑，信息载体变成了文档、会议纪要、口头沟通和代码注释。人脑有容错能力，能猜意图、能靠经验补全缺失的信息。大语言模型（LLM）没有这种容错空间，它只处理被明确送进来的内容。
所以，Harness Engineering 的本质并非一种全新的方法论，而是对一个老问题的重新表述：
如何将软件工程中的知识、流程和约束，转化为高质量的 Token 序列，并在正确的时机送入模型的上下文窗口。
你的文档写得糟糕，AI 读到的就是糟糕的。你的“完成定义”模糊不清，AI 就会自己决定什么叫完成。你的架构规范只存在于老工程师的脑海中，AI 永远无法知晓。
这不是 AI 的问题。这是你欠下的技术债。
你准备好了吗？
回到最初的问题。
那些在大力推行 Harness Engineering 的团队——OpenAI、Anthropic、Cursor——他们并非发明了什么新东西。他们只是在 AI 的倒逼下，把软件工程本该做好的事情，执行得更严格、更彻底。
那么，你的团队呢？
关键决策是否写入了代码仓库？还是散落在钉钉消息、飞书文档和某几个人的脑子里？
你们的“完成定义”是明确且可执行的？还是那种“大家都懂”的模糊共识？
架构规范是否有机械化执行的保障？还是仅仅依赖代码审查时老工程师的经验判断？
项目交接依赖的是成文的文档，还是口口相传？
这些问题，在纯人类协作的团队中或许可以“将就”。工程师有容错能力，可以依靠经验和沟通来弥补流程上的漏洞。
但 AI 没有这种能力。
你们目前给人使用的那套流程和文档，真的够格喂给 AI 吗？ 这是每个打算拥抱 AI 编程的团队必须直面的拷问。对于希望系统化提升工程能力的开发者，云栈社区的基础与综合板块汇集了大量关于计算机科学原理和工程实践的基础知识，或许能为你补上这一课。
参考文章
- Ryan Lopopolo, Harness engineering: leveraging Codex in an agent-first world[1], OpenAI, 2026-02-11
- Wilson Lin, Scaling long-running autonomous coding[2], Cursor, 2026-01-14
- Wilson Lin, Towards self-driving codebases[3], Cursor, 2026-02-05
- Prithvi Rajasekaran, Harness design for long-running application development[4], Anthropic, 2026-03-24
参考资料
[1] Harness engineering: leveraging Codex in an agent-first world: https://openai.com/index/harness-engineering/
[2] Scaling long-running autonomous coding: https://cursor.com/blog/scaling-agents
[3] Towards self-driving codebases: https://cursor.com/blog/self-driving-codebases
[4] Harness design for long-running application development: https://www.anthropic.com/research/harness-design
发表于 7 小时前
|
查看: 3|
回复: 0
