"Harness Engineering"（挽具工程）正在演变为硅谷科技圈的新方向，无论是Anthropic还是OpenAI，都在积极探索这一工程方法。但要论真正吃透Harness本质的人，眼下仍然不多。就在前不久，硅谷创业公司CreaoAI的Peter Pang发表了一篇题为《Why Your "AI-First" Strategy Is Probably Wrong》的长文，在X平台上点燃了百万量级的阅读与激烈讨论。Peter在文中用翔实数据呈现了Harness Agent系统释放的惊人效能：AI生成了99%的代码量，每个工作日平均完成3到8次生产环境部署，而过去需要整整六周才能跑通的完整产品流程，如今不到24小时就能全部走完。

在《硅谷101》新一期播客中，泓君邀请到Creao的三位联合创始人，共同拆解这家公司对Harness的落地实践，以及对AI-First组织变革的深层思考。几位嘉宾反复重申了一个关键判断：AI-First远不是"用上AI工具"这么简单。要在效率上实现百倍乃至千倍的跃迁，就不能仅仅把AI安置在辅助工具的位子上，必须让它成为全部生产力的驱动核心。组织转型中最难翻越的那道坎，恰恰在于——能否推动每一位团队成员发自内心地把信任交到AI手中。

整场对话里涌现出不少耐人寻味的洞察。在Creao，市场部门已经彻底不用追着开发催排期了，因为开发交付的节奏早已甩开了市场的消化速度。更令人意外的是，当AI承接了大量协调与对齐工作之后，取消产品经理这一角色不但没有引发混乱，反而让团队整体效率大幅跃升。还有一个值得注意的对比：初级工程师对于AI驱动的全新工作方式适应得明显更快，资深工程师反而在转型期间需要更多调整时间。当然，过去十年间积累的技术专长确实在以肉眼可见的速度贬值，但这并不意味着资深工程师就丧失了竞争力——未来的核心能力已不再是写代码本身，而是"精准发现AI规划中的缺陷"以及"判断什么方向值得投入"。

以下为本次播客精华内容的整理：

拆解Harness工程 把大模型的能力逼到极限

泓君：Peter，先请你跟大家解读一下，什么是Harness engineering（挽具工程）？

Peter：这个概念的发源要回到大模型刚刚进入人们视野的那个阶段。最初，圈子里讨论的焦点是prompt engineering（提示词工程），后来逐步演进到了context engineering（上下文工程），彼时的核心关注点仍然停留在"如何跟大模型打交道"。但Harness要做的事情完全不同，我们的目标实际上是"驯化"一整套通用系统。从覆盖范围上看，它比prompt和context engineering要宽广得多，牵涉到工具链的调度策略、沙箱的架构设计，以及各宿主服务之间怎样交互才能确保安全性，你的沙箱冷启动耗时多少，延迟被控制在什么水平……这些全都是Harness的组成部分。

泓君：我的理解是，Harness的工程能力直接决定了大模型能被用到什么极限？之前Kai提过一个很形象的例子：一套Agent系统可以通宵跑完三个人的SEO工作流；而另一套内容流水线跑了两天才有人发现产出的全是废品。这两者之间的巨大落差，恰恰一个是Harness的成功，另一个是Harness的惨败。

Peter：我认为这个例子恰好证明了为什么我们必须认真对待Harness。它的本质就是关于怎么持续地提升一个系统。当系统产出效果差的时候，究竟是需要人来给feedback（反馈）才能改善，还是系统自己就能完成self healing（自我修复）和self improvement（自我优化）——这恰恰是Harness要回答的核心命题。

Harness还有一个非常关键的维度，就是怎样让Agent在推理阶段实现scaling（扩展），具体来说就是你如何把更丰富的上下文、更多样的工具链交付给它，给它更长的时间和更大的空间去完成一个任务。在这个环节，如果你的Harness设计不到位，hallucination（幻觉）和context overflow（上下文溢出）就极容易发生，模型的表现也会随之降级。所以Harness确实是一个高度复杂、需要实战经验积累的方向。

泓君：那当前业界对Harness的共识与非共识分别在哪里？

Peter：很多人把Harness理解成一种静态的东西，即为LLM开发一套配套系统来发挥其优势。但我们的认知与之不同——它是一个持续动态演进的过程。关键在于，你的系统怎么从一个静态状态真正"活"起来，怎么做到self-improve（自我优化），怎么持续捕捉来自市场、产品和用户的各类signal（信号），并推动自己进入快速迭代的轨道。我觉得这一点可能绝大多数人还没有清醒地认知到。

泓君：也就是说，这个迭代的主导权在AI手里，而不是人手里？

Peter：没错，迭代的发动机就是AI本身。人的职责，是思考如何把形色色的信号源源不断地送入AI的反馈回路。

六周压缩到一天 AI驱动的开发节奏到底有多快？

泓君：你有一条在推特上刷屏的内容，讲你们这家25人规模的公司，99%的代码由AI完成。上午十点上线一个功能，中午就做A/B test，下午三点看完数据反馈直接砍掉了一部分，到五点又重写了一个更好的版本。这一天的节奏，放在传统模式里足足需要六周。这就是你们用Harness跑出来的结果。

Peter：我们对Harness的理解分成两个层面：第一个层面是对Creao自身Agent系统的Harness，第二个层面是当用户利用Creao搭建自己的Agent时，我们怎么帮他做好Harness。过去开发一个功能可能要花两三个月来迭代，现在AI辅助coding一两个小时就能完成实现，那如果仍然用同样的时间去设计和测试，这轮效率增益就没什么意义。因此，能不能把设计、规划、测试全部纳入Harness的覆盖半径，对于一家公司能否真正转型为AI-First，起着决定性的作用。

Clark：我想先明确一个观点：迈向AI-First或者AI native（AI原生）的状态，不是简单地在现有流程上叠加AI工具，而是要围绕AI的能力真正重构工作流和组织形态。

之前很长一段时间里，我们团队的情况是每个工程师用AI写代码，每个产品经理用AI撰写PRD（产品需求文档），每个设计师用AI出图。听起来很AI对吧？但实际效果是效率反而下降了——大家的进度和节奏不同步之后，alignment（对齐）成本急剧膨胀，尤其我们还是全员远程的协作模式。于是我们开始重新追问：到底怎样才能让AI在公司运转中像自动化流水线一样跑起来？正是在这个追问驱动下，Peter才设计了一套全新的开发流程和架构方案，也就是那篇文章里描述的具备self-healing（自我修复）能力的Agent Harness。

泓君：能不能具体展开说说，在重组组织架构时，哪些方向发生了实质变化？遇到的瓶颈在哪里？

Peter：首先要解决的永远是人的问题——大家是否愿意接受一套全新的工作方式。我们投入了大量精力来做mindset（思维模式）的对齐。按以前的做法，要做这种级别的转型，往往需要一个资深架构师或工程师花费好几个月来demonstrate（展示）新方式的优势，这个转型成本非常高昂。而现在有AI的助力，整个过程可以大幅缩短，也许一到两周就能把前端、后端、架构到基础设施全部重构完毕，然后让大家直观地感受这套新方式的高效。不管从部署频次、部署可靠性还是最终效果来看，都远远甩开了之前的工作模式。只有这样，才能在极短时间内让整个团队达成思维层面的共识。

关键词: AI, Harness工程, 组织变革, 挽具工程, AI-First

本文内容基于36氪报道独立撰写，仅供学习参考。