文 | 硅谷101

“Harness Engineering”（挽具工程）正在成为硅谷的新共识，Anthropic、OpenAI等公司都在探索这一工程范式。但真正理解Harness的人还不多。前不久，一篇题为《Why Your “AI-First” Strategy Is Probably Wrong》的文章在X上获得百万级阅读和热议，作者是来自硅谷CreaoAI的Peter Pang。在这篇文章里，Peter展示了Harness Agent系统激发出的极致效率：99%的代码由AI完成，每天平均3到8次生产部署，过去六周的产品流程，现在一天就能跑完。

本期《硅谷101》播客，主播泓君邀请到Creao的三位创始人，聊聊这家公司对Harness的实践，以及在组织AI-First转型上的深度思考。嘉宾们指出，AI-First不等于“使用AI”，想要把效率提升100倍、1000倍，就不能只把AI当成工具，而要让AI成为所有生产力的主导。组织转型最难跨出的一步在于——是否能让所有员工都能做到信任AI。

这场对话中有一些有趣的观察，比如在Creao，市场不用再追着开发提需求，因为开发速度已经远超市场消化能力；当大量对齐工作被AI接管之后，拿掉产品经理，反而让团队效率大幅提升；初级工程师比资深工程师更适应AI时代的转型；尽管过去十年积累的专长正在快速贬值，但资深工程师仍然有竞争力，因为未来的核心竞争力不再是写代码，而是“找到AI Planning的缺陷”和“判断什么是有价值的”。

以下是这次对话内容的精选：

01 Harness工程详解：如何把大模型“榨”出极限

泓君：先请Peter介绍一下，什么是Harness engineering（挽具工程）？

Peter：Harness的概念可以追溯到大模型刚开始的时候，很多人在聊prompt engineering（提示词工程），之后演变到context engineering（上下文工程），这时候更多的是聚焦在怎么和大模型本身进行交互。

但是对于Harness来讲，我们是在“驯化”一个通用的系统，所以从范围上来讲，它比prompt & context engineering要大很多，涉及到tooling（工具链）的使用，涉及到你的sandbox（沙箱）的架构设计，你的host service（宿主服务）之间是怎么进行交互的？怎么样的交互能够安全？你的sandbox在启动的时间是多少？你的延迟是多少？……这些都是harness的一部分。

泓君：可不可以理解成，Harness的工程能力决定了怎么把一个大模型“榨出”最佳使用上限？我记得Kai有提到，一个Agent可以一夜之间干掉三个人做SEO（搜索引擎优化）的工作流；同时还有一个内容流水线，它跑了两天，才有人发现全是垃圾。这两者之间有巨大区别——一个是Harness的胜利，一个是Harness的失败。

Peter：我觉得这个完全就印证了为什么我们需要Harness。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为主导的迭代。人所需要做的事情，就是怎么把各种各样的信号feed给AI。

02 六周变一天：AI驱动的开发流程有多快？

泓君：你有一篇很火的推特帖子，讲你们25人的公司，99%的代码由AI写，早上10点写了一个功能，中午就进行了A/B test，下午3点就根据数据的反馈把它砍掉了一部分功能，5点又重写了更好的一个版本。这是一天的工作节奏，在传统的开发产品的过程中，它是需要6周的。这是你们用Harness探索出来的方式。

Peter：在我们看来，Harness分为两个部分：一是对Creao自身Agent系统的Harness，二是用户用Creao构建自己Agent时，怎么帮他Harness自己的Agent。传统开发过程中，可能要用两三个月迭代一个功能，现在AI辅助coding只需一两小时实现，如果还用很长时间去设计和测试，就不是很有意义。所以怎么把设计、规划、测试都包含到整个Harness过程中，对公司能不能转型为AI-First至关重要。

Clark：我想先跟大家表达一个观点：如果想做到所谓的AI-First或者AI native（AI原生）这样一个状态，它不是在现有流程上去使用AI工具，而是要围绕AI能力重新构建工作流程和组织形态。

图片来源：Peter Pang@intuitiveml

我们在之前很长一段时间里，每一个工程师都在用AI写代码，每一个产品经理都在用AI写PRD（产品需求文档），每一个设计师都在用AI做图。但其实这样并没有增加我们的效率，反而导致每一个人的工作进度和节奏不一样之后，我们的alignment（对齐）成本变得非常高，我们还是全部远程办公的状态。

所以我们要去重新想，我们到底怎么样才能让AI在公司运营过程中真正地自动化跑起来，才有了Peter设计的一套新的开发流程和架构和新的产品的架构重构，才有了这篇文章里面讲的self-healing（自我修复）的Agent Harness。

泓君：可不可以举个例子，你们重塑组织架构时，哪些方向发生了变化？瓶颈在哪里？

Peter：首先需要解决人的问题——大家能否接受新工作方式。我们花很多时间对齐mindset（思维模式）。以前做这样一个转型，通常需要一个架构师或工程师花费好几个月来demonstrate（展示）新的工作方式更优，但这个转型成本就很大。

现在在AI辅助下，这个过程就会快很多，可能只需要一两周把整个系统，包括前端、后端、架构、基础设施，都进行重构，然后给大家展示它工作起来更高效。不管是部署的频率、部署的可靠性和最后的效果上，都比之前的工作方式有很大提升。这样能在很短时间内对齐思维模式，让大家快速融入到整个开发过程。

Kai：其实Harness本身它更多是在于构建一个系统，真的能让所谓的AI-First的组织高效运转。很多组织上的人，思维难以改变，他觉得用AI提升效率就够了。但是AI-First要求的是，你让AI来driven（驱动）你整个公司的方向，可能你每天工作的方式都是由AI来驱动的，这是完全不一样的概念。

泓君：是AI给你们布置任务吗？

Kai：对。如果还把AI当成一个提升效率的工具，那使用者的效率提升可能最多就是10倍，因为人最多每天可能就工作24小时。如果希望效率提升100倍、1000倍，你不能说你是那个工具的使用者，而是AI应该是所有生产力的主导。人的角色发生变化，更多是在于怎么去复盘结果的好坏。还有在这个系统里，我并不是那个实际的工作者，我应该以怎样的一个方式去跟这个系统配合起来？这是很多企业在做转型时，没意识到或很难去做到的事情。

泓君：举个例子，你们的系统怎么和人去配合工作？我觉得传统的团队开发产品的时候，可能很大的一个痛点就是说，我团队之间要对齐，然后我要把信息同步到每一个人，任何一个人他可能miss掉了一个信息点，那他在产品做开发的时候，可能就不知道我们上一版的更新是什么。现在是不是所有的这些工作都可以交给AI，或者在这个流程中它就可以自动去做了？

Kai：我觉得这里面核心还是信任的问题。很多人对系统不信任，所以对齐成本就非常高。现在AI-First下，对齐由AI主导，比如AI告诉市场团队今天工程师要发布哪些功能，市场团队不用再反复问工程师。

泓君：AI怎么知道工程师团队明天能把所有的工作做完？

Peter：在AI的思维模式之下，迭代一个产品的过程中，我们更侧重的是，这个新的功能能不能够带来产品的top line metrics（顶层指标）的提升，或者新的这个功能能不能有真的用户使用的数据。所以在这个过程中，我们更核心聚焦怎么把整个数据链搭建起来。我们把这个链条搭建起来之后，都是Agent通过这些数据来决定，好，这个功能到底是不是有用的，我们到底要不要roll out（上线）这个功能，或者fall back（回退）这个功能。

泓君：也就是说工程师写完代码以后，不需要手动地跟AI说“我写完了”，现在AI它就可以自动地根据你的整个代码质量，你的进程，去做出它的判断。