“挽具工程”（Harness Engineering）在硅谷正迅速达成共识，包括Anthropic和OpenAI在内的众多企业都在积极探索这一新兴工程范式。然而，其深层含义尚未被广泛理解。近期，一篇题为《Why Your “AI-First” Strategy Is Probably Wrong》的文章在社交平台X上引发了百万级阅读和热烈讨论。该文作者Peter Pang，来自硅谷的CreaoAI，详细阐述了Harness Agent系统如何实现前所未有的效率：99%的代码由AI生成，每日可完成3至8次生产部署，曾需六周的产品开发流程如今一日内即可完成。
在最新一期《硅谷101》播客中，主播泓君邀请Creao的三位创始人，深入探讨了公司在Harness实践中的经验，以及在组织向AI-First转型方面的独到见解。嘉宾们强调，AI-First并非简单地“使用AI”，若要实现100甚至1000倍的效率提升，就必须将AI从辅助工具转变为生产力的核心驱动者。组织转型的最大挑战，在于能否让所有员工建立对AI的信任。
对话中呈现了一些引人深思的观察：例如，在Creao，市场部不再需要催促开发进度，因为开发速度已远超市场消化能力；当大量协调工作被AI接管后，取消产品经理反而显著提升了团队效率；初级工程师比资深工程师更能适应AI时代的转型。尽管过去十年积累的专业技能正在迅速贬值，但资深工程师依然具有竞争力，因为未来的核心优势不再是编写代码，而是“发现AI规划中的缺陷”和“判断何为有价值的事物”。
以下是本次深入对话的精要内容摘录：
01 Harness工程深度剖析：如何最大限度地发挥大模型潜力
泓君：Peter，请您首先为我们阐释一下什么是Harness engineering（挽具工程）？
Peter：Harness的概念可追溯至大模型兴起之初，当时人们普遍关注提示词工程（prompt engineering）和上下文工程（context engineering），这些主要聚焦于如何与大模型本身进行互动。
然而，Harness的范畴远超于此，它关乎如何“驯化”一个通用系统。它包含了工具链的运用、沙箱架构的设计、宿主服务间的交互方式、交互的安全性、沙箱启动时间以及延迟等一系列复杂考量。所有这些层面共同构成了Harness工程的核心。
泓君：这是否可以理解为，Harness工程能力决定了我们能从大模型中“榨取”出多少最佳效能？我记得Kai曾提及，一个Agent一夜之间可以完成三个人月的SEO工作流程；但同时也有一个内容流水线，运行了两天却被发现产出全是垃圾。这两者之间存在巨大差异——前者是Harness的成功，后者则是其失败的体现。
Peter：您的例子恰恰印证了Harness的必要性。Harness的本质在于，我们如何持续地提升一个系统的效能。当系统表现不佳时，核心问题在于，该系统是需要人工反馈进行改进，还是系统本身具备自我修复和自我优化的能力？这正是Harness工程的核心所在。
Harness的一个关键点在于，如何在推理阶段实现Agent的规模化扩展，以及如何为其提供更丰富的上下文和工具链，使其能用更长时间完成复杂任务。若Harness设计不当，便极易导致AI产生幻觉（hallucination）或上下文溢出（context overflow），从而降低模型的整体能力。因此，Harness的实施既复杂又需要丰富的经验。
泓君：目前市场对于Harness有哪些共识和非共识的观点？
Peter：许多人错误地认为Harness是静态的，即构建一套配套系统以发挥LLM优势。但我们坚信它是一个动态过程——关键在于如何让一个静态系统真正“活起来”，实现自我改进，并持续快速地适应来自市场、产品和用户的各种信号迭代。这一点，我认为许多人尚未充分认识到。
泓君：这种迭代也是由AI主导而非人类主导的吗？
Peter：是的，它是由AI主导的迭代。人类的角色则在于将各种信号源源不断地输入给AI。
02 从六周到一天：AI驱动的开发流程何其迅速？
泓君：您在推特上发布的一篇热门帖子提到，贵公司25人团队中，有99%的代码由AI编写。你们的日常节奏是：上午10点完成一个新功能，中午进行A/B测试，下午3点根据数据反馈裁减部分功能，下午5点便已重写出更优版本。这种高效工作方式，在传统产品开发模式下通常需要六周时间。这是通过Harness探索出的独特路径。
Peter：在我们看来，Harness分为两个层面：一是针对Creao自身Agent系统的Harness，二是如何协助用户在Creao平台上构建其Agent时进行Harness。传统开发模式下，一个功能迭代可能需要两三个月，而AI辅助编程仅需一两个小时即可实现。若仍投入大量时间进行设计和测试，其意义便不大。因此，如何将设计、规划、测试环节全面融入Harness流程，对于公司向AI-First转型至关重要。
Clark：我想先给大家一个观点：若要实现所谓的AI-First或AI原生状态，并非简单地在现有流程中运用AI工具，而是必须围绕AI能力重新构建工作流程和组织形态。
（图片来源：Peter Pang@intuitiveml）
此前很长一段时间，我们的每位工程师都在用AI编写代码，每位产品经理都在用AI撰写PRD（产品需求文档），每位设计师都在用AI进行图示创作。然而，这并未真正提升我们的效率，反而因为每个人的工作进度和节奏不一，导致对齐成本极高，加之我们仍处于全远程办公状态。
因此，我们不得不重新审视，究竟如何才能让AI在公司运营中真正实现自动化运作。正是在这样的思考下，Peter设计了一套全新的开发流程、架构和产品重构方案，才有了他文章中提到的那种自我修复（self-healing）的Agent Harness。
泓君：您能举例说明一下，在重塑组织架构时，哪些方面发生了变化？瓶颈又在哪里？
Peter：首先需要解决的是人的问题——员工能否接受新的工作方式。我们投入了大量时间来统一思维模式（mindset）。过去，进行此类转型通常需要一个架构师或工程师花费数月时间来展示新工作方式的优越性，这导致转型成本居高不下。
而在AI辅助下，这一过程大大加速。可能仅需一两周，整个系统，包括前端、后端、架构和基础设施，都能完成重构，并向大家展示其显著提升的效率。无论是部署频率、可靠性还是最终效果，都远超传统工作方式。这使得我们能在短时间内统一团队的思维模式，让大家迅速融入新的开发流程。
Kai：实际上，Harness本身更多在于构建一个真正能够让所谓AI-First组织高效运转的系统。许多组织中的人难以改变思维，觉得只要用AI提升效率就足够了。但AI-First要求的是，让AI驱动整个公司的方向，可能你每天的工作方式都是由AI来驱动的，这是一个截然不同的概念。
泓君：是AI给你们布置任务吗？
Kai：是的。如果仍将AI视为一个提升效率的工具，那么使用者效率的提升最多只有十倍，因为一个人一天最多工作24小时。如果期望效率提升一百倍、一千倍，你就不能再仅仅是工具的使用者，而应该是AI主导所有的生产力。人的角色会发生转变，更多在于如何复盘结果的好坏。而且在这个系统中，我不再是实际的工作者，我需要思考如何与这个系统进行配合。这是许多企业在转型过程中没有意识到或难以实现的问题。
泓君：举个例子，你们的系统如何与人配合工作？我认为传统团队在开发产品时，一个很大的痛点可能是团队间的对齐，以及需要将信息同步给每个人，任何一个人如果遗漏了一个信息点，那么他在产品开发时可能就不知道上一版的更新内容。现在，所有这些工作是否都可以交给AI，或者在流程中自动完成了？
Kai：我认为这其中核心还是信任问题。很多人不信任系统，所以对齐成本非常高。在AI-First模式下，对齐工作由AI主导，例如AI会告知市场团队今天工程师将发布哪些功能，市场团队就不需要反复询问工程师了。
泓君：AI怎么知道工程师团队明天能完成所有工作？
Peter：在AI的思维模式下，产品迭代过程中，我们更关注新功能能否提升产品的顶层指标（top line metrics），或者新功能是否有真实的用户使用数据。因此，我们核心聚焦于如何搭建完整的数据链。当这个数据链建立起来后，Agent会通过这些数据来决定：这个功能到底有没有用？我们是否应该上线（roll out）这个功能？或者回滚（fall back）这个功能？
泓君：也就是说，工程师写完代码后，不需要手动告诉AI“我写完了”，现在AI可以根据整个代码质量和项目进度自动做出判断了。
Peter：对，这在传统工程中也有，我们称之为CI/CD流程（持续集成/持续部署）。只不过，在传统的CI/CD流程中，很多是基于规则（rule-based）或单元测试（unit testing）驱动的。但在AI场景下，我们可以有许多AI驱动的测试。例如，现在流行的Playwright可以进行AI驱动的完整端到端测试（end-to-end testing），确保我们发布的S代码中没有明显的破坏性bug。因此，在这个过程中，许多AI驱动的测试变得至关重要。包括代码发布后日志中是否存在错误或事件，所有这些信号都能反馈给AI，用以评估整体代码质量。
泓君：关于让AI编写代码，如何确保其质量？Peter的文章提到，通常情况下，编写代码一天，修复bug可能需要三天。现在有什么新方法可以减少大量时间用于修复工作？
Peter：我认为bug在整个工程中是不可避免的，无论是由AI还是人工编写。因为Harness并非一个静态存在，它不是说我拥有一个系统后只需要维护它，这个系统就不会有bug，也不需要提升了。
Harness过程的核心在于能否发现系统中的漏洞。刚才我们讨论CI/CD流程时提到了，我们有一系列回归测试（regression test）来防止一些bug发布到生产环境（production）中破坏系统，这是第一步。第二步是，即使存在一些边缘情况（corner case）或竞争条件（race condition）的bug发布到系统中，我们如何能在最短时间内识别并及时修复它们？
在传统情境下，这两个步骤都由人工驱动。但在Agent Harness模式下，我们拥有Agent系统驱动。因此，我们开发了Agent驱动的CI/CD系统和Agent驱动的bug分类/定级（bug triage）系统，它们会根据系统中的问题进行分类，然后指派给工程师进行修复。
（图片来源：Peter Pang@intuitiveml）
泓君：您觉得引入这两套系统后，效率提升了多少？
Peter：因为大部分工作由Agent驱动，所以可以并行处理，许多Agent可以同时识别问题。发现一个bug通常只需1-2分钟，指派给工程师则只需几秒钟。工程师再利用Agent进行调查并提出解决方案，整个循环大约需要1-2小时。相比之下，过去我们识别、修复一个bug并将其发布到系统中，可能需要一周的时间。
Clark：是的，这里有一个非常有趣的现象。我们以前有一个很长的功能愿望清单（feature wish list），还有一个需要修复的bug清单。以前市场、产品和工程师总是反复讨论：到底是先修复bug还是先开发功能？现在这两个清单都消失了，因为bug一经发现便立即修复，而功能数量则远远超出了我们的实际需求。
Peter：我们现在有一个自动修复（auto-fixing）系统。对于一些需要修复的问题，如果它们仅存在于风险较低的文件中，AI会自动提交拉取请求（PR），工程师只需简单批准即可发布。目前，超过50%的问题通过自动修复完成。
03 架构师：Harness中的核心角色
泓君：因为我并不擅长编程，只能用写文章来类比。假设我在修改一篇稿件，即使只有一个小错误，我可能需要通读整篇稿件，这花费的时间和我自己重新写一篇是差不多的。如果Agent为您搭建了一个非常优秀的技术框架，但在基础层出现了重大错误，需要工程师来解决，那么工程师是否需要重新学习整个系统？
Peter：我觉得这个问题提得非常好。在我之前的文章中，我也讨论了在AI环境下，工程团队可能分为两类人：一类是架构师（architect），一类是操作者（operator）。架构师在整个系统搭建过程中的作用至关重要。举例来说，在搭建整个Creao系统的过程中，Agent的整体架构、沙箱（sandbox）与宿主（host）之间的交互方式，都是由架构师决定的。
如果Agent直接通过AI编码或“氛围编程”（vibe coding）的方式提供一个解决方案，这个方案通常存在安全隐患或延迟问题。如何优化整个系统，这仍由架构师来决定。不同之处在于，传统上搭建Agent团队可能需要10到20人，但现在，搭建这样一个系统仅需一名架构师，在一个周内即可完成。
Clark：我来补充一点。AI的能力早就很强大了，但为什么它还没有达到人们的预期呢？人们总觉得AI做得不够好，还得人工弥补错误。这里需要有一个概念上的转变：我们必须将AI视为一个系统，而非一个单纯的智能。当系统出现问题时，我们不应只想着纠正这个“智能”，而应该思考如何弥补这个系统。这实际上是我们进行Harness与当前普遍认知最大的不同之处，它是一个动态变化和提升的过程，而非静态的、固定的枷锁来束缚智能，我们需要为其提供成长空间，让它在一个既定规则内不断发展完善。这就像您在养育一个孩子，让它在框架内变得越来越好。
泓君：这个观点很有趣，以前是“解决问题”，现在是“解决系统上的问题”。
Clark：这里还有一个更激进的想法，我们自己发布的内容，未来可能不一定是由人类受众来消费。比如一个市场部门的宣传材料，从人类的审美角度看可能并不尽善尽美。但实际上，当你将这些内容投放市场时，你会发现，阅读这篇文章或图片的可能是一个Agent，它反馈回来的数据结果反而可能更好。
未来购买商品可能会由Agent完成，订阅报纸也可能由Agent操作……那么，你的广告是给Agent看的，还是给人看的？你需要明确你的工作成果最终由谁来消费。针对这个价值点，我们再去思考究竟是提升系统，还是回到最初的人类创作过程中去弥补一些缺陷。
泓君：我相信在未来做出消费决策时，可能是Agent看得更多。但这比我预期来得快得多，整个进化速度非常惊人。
Peter：从另一个角度来看，现在SaaS产品的转型也非常明显。以前许多SaaS产品需要一个供人查看和管理的仪表盘（dashboard）。但至少在目前阶段，我们团队在使用任务管理时，更关心的是Agent能否“看到”并设定这些任务的优先级（prioritize）。所以我们会关注这些任务管理产品是否能为我们的Agent提供更好的模型上下文协议（MCP）和应用程序接口（API）供其使用。
泓君：所以整个进化还是非常迅速的。
Kai：实际上，您刚才提到的问题，也是许多公司在进行AI转型时首先会考虑的。他们觉得在使用AI的同时，如果还需要人工复核一遍，那么与人工操作相比，时间和成本并没有区别。但如果真正将AI系统构建起来，仔细计算，时间和成本会有大幅提升。只不过这个过程需要整个团队有共同的目标，只要有人觉得还不如人做，改造时间就会被拉长。这是大多数企业在组织层面面临的挑战。
04 转型最艰难一步：从信任人类到信任AI
泓君：你们是从公司创立之初就秉持AI-First理念，还是后来逐步摸索形成的？
Kai：我们公司也经历了一个过程，需要认识到谁将是未来生产力的核心角色。2025年上半年，大家普遍认为AI只是辅助人类工作，人类在工作中仍占据主导地位。但到了下半年，我们意识到，如果继续这样下去，企业效率提升将会非常有限。核心问题在于未能真正将生产力工具的“使用者”从人类转变为AI。这种转变需要时间，市场团队和工程团队甚至花了一两个月的时间反复探讨怎样才是更优的工作方式。
Peter：我认为这与AI能力的提升息息相关。在过去一年中，AI的角色从辅助逐步过渡到参与开发，再到如今能够相对主导开发过程，这一转变与基础模型能力、Agent架构及基础设施的提升紧密相连。一年前让AI主导开发，从技术上来说是不成立的，但在我们重构的过程中，当发现AI达到了那个临界点时，整个重构的速度和效果远超一年前的想象。
泓君：你们是从什么时候开始重构的？做了哪些核心工作？
Peter：意识到需要重构是在去年八九月份，其中花费时间最多的就是让大家转变思维方式。真正开始重构代码架构和开发流程是在今年1月，大约用了两周时间，重构了包括现在大家所看到的产品在内的整个架构。
泓君：有哪些您曾认为AI无法解决的问题，而现在AI已经解决了？
Peter：之前AI主要无法解决的是规划（Planning）阶段的问题。比如说，如果我以100分为满分方案，现在它能提供一个90分的方案。我看到这个规划时，可以对它进行一些批评（criticize），然后它能给我一个修改后的方案（revised plan），而不需要我实际去修改规划。一年前，它可能只能给出50分的方案，我可能需要人为地去修改（modify）规划，再去改整个架构。
泓君：您认为AI的编程能力在您之上吗？
Peter：首先，AI的编程能力肯定在我之上，我自2026年以来就没有编写过一行代码。但从规划能力来看，作为一个架构师的价值，无论是CTO还是技术负责人，其核心价值在于发现AI规划中的不足之处。