Harness时代：一场从"信任人"到"信任AI"的组织革命
引言：当AI从工具变成主导者
2026年的春天，硅谷传来一个令技术圈震动的数据：一家25人的公司，99%的代码由AI完成，每天平均3到8次生产部署，过去需要六周的产品开发流程，如今一天就能跑完。这不是科幻，而是CreaoAI在《Why Your “AI-First” Strategy Is Probably Wrong》中展示的真实案例。
这篇博文之所以在X上获得百万级阅读，不是因为它描述了一个美好的愿景，而是因为它撕开了"AI-First"转型中最那道最难跨越的伤疤——信任。不是对AI能力的信任，而是对AI作为生产力主导者的信任，是对整个组织从"人驱动AI"转向"AI驱动人"这一根本性变革的信任。
CreaoAI成立于2025年11月，25名员工中只有10名工程师。创始人Peter Pang在2026年1月做出了一个大胆的决定：从零开始重构整个产品架构和工程工作流。两周后，新系统上线。如果产品能够自我构建，它就能work。
一、Harness Engineering：工程团队的首要任务不再是写代码
从概念到实践：OpenAI的定义
2026年2月，OpenAI发表了一篇文章，阐述了"Harness Engineering"的概念：Creao其实早就在践行这一理念，只是没有给它命名。
Peter Pang对Harness Engineering的核心定义：
“工程团队的首要任务不再是写代码，而是使Agent能够做有用的工作。当某件事失败时，修复方案永远不是’再努力试试’。修复方案永远是：缺了什么能力？我们如何让这个能力对Agent可见且可执行？”
这个定义揭示了Harness的本质：从"人修复问题"到"系统获得能力"。传统思维是"人出了错，人来修"；Harness思维是"系统缺能力，系统补能力"。
从Prompt Engineering到Harness：认知的三次跃迁
回溯大模型应用的历史，我们经历了三个认知阶段：
第一阶段：Prompt Engineering（提示词工程） 这个阶段人们相信，只要写好提示词，AI就能乖乖听话。但prompt的边界太明显——它太依赖人的表达能力和对AI的理解，同样的需求，换一个表述，结果可能天差地别。
第二阶段：Context Engineering（上下文工程） RAG（检索增强生成）技术风靡一时，核心逻辑是"喂给AI足够多、足够准确的上下文"。但上下文是静态的，而AI处理的任务是动态的；上下文是过去的经验，而任务总是面向未知的场景。
第三阶段：Harness Engineering（挽具工程） Harness不是静态的配套系统，而是"驯化"通用智能的动态过程。它解决的是如何让一个AI系统从"能干活"进化到"会自我优化"的问题。
而Harness要做的是，让整个系统成为一个人机共生的生态系统：AI不仅执行任务，还能根据执行结果调整策略；系统不仅能工作，还能识别自身的缺陷并自我修复。
“Prompts are disposable”：一个反直觉的真相
Peter在原文中提到了一个反直觉的观点：
“A production system needs to be stable, reliable, and secure. You need a system that can guarantee those properties when AI writes the code. You build the system. The prompts are disposable.”
这句话击中了当前AI开发的一个核心误区：很多团队把精力花在打磨prompt上，希望找到"黄金prompt"来解决所有问题。但Harness的逻辑告诉我们：prompt是一次性的，可变的；系统才是核心，需要精心构建。
当你把系统构建好之后，prompt的调整变得无关紧要——因为系统本身会引导AI做出正确的行为。这是一种根本性的范式转换：从"优化prompt"到"优化系统"。
Harness的核心能力：Self-Healing与Self-Improvement
**Self-Healing（自我修复）**不是指系统不会出错——任何系统都会出错——而是指系统能够快速识别错误并自动修复。在Creao的AI-First流程中，Agent驱动的bug triage系统可以在1-2分钟内识别问题、几秒钟内指派给工程师，整个修复-部署cycle压缩到1-2小时。50%以上的低风险修复已经实现了"auto-fixing"——AI自动提交PR，工程师只需简单批准即可。
**Self-Improvement（自我优化）**是更高级的能力。Harness系统内建了自我进化的机制：每一次部署后的数据反馈都会成为AI调整策略的信号。
为什么Harness比想象中更难？
Kai提到的两个案例对比揭示了Harness的本质：
- 失败案例：一个内容流水线跑了两天才发现全是垃圾——AI被当作"更快的工具"，没有反馈闭环
- 成功案例：一个Agent一夜之间干掉三个人做SEO的工作流——AI被嵌入完整的反馈闭环
Harness的难度不在于"用AI"，而在于"构建让AI能够自我优化的系统"。这需要全新的架构思维——不再是"我设计流程、AI执行"，而是"我设计系统、AI在系统中自我进化"。
二、AI-First vs AI-Assisted：不是加法，是乘法
绝大多数公司只是"AI-Assisted"
Peter在原文中一针见血地指出了当前大多数公司的问题：
“Most companies bolt AI onto their existing process. An engineer opens Cursor. A PM drafts specs with ChatGPT. QA experiments with AI test generation. The workflow stays the same. Efficiency goes up 10 to 20 percent. Nothing structurally changes. That is AI-assisted.”
这是绝大多数公司正在做的事情：在现有流程上叠加AI工具。效率提升10-20%，但结构没有变化。
AI-Assisted的特征：
- 同样的sprint周期，同样的Jira看板
- 同样的周会，同样的QA签字
- 只是"在循环中加了AI"，而不是"重新设计循环"
AI-First的本质：重新设计一切
“AI-first means you redesign your process, your architecture, and your organization around the assumption that AI is the primary builder. You stop asking ‘how can AI help our engineers?’ and start asking ‘how do we restructure everything so AI does the building, and engineers provide direction and judgment?’”
AI-First的关键问题转换：
- 不是"AI如何帮助工程师？"
- 而是"如何重组一切，让AI成为主要构建者，让工程师提供方向和判断？"
Peter明确指出：这个差异是乘数级的。
为什么" vibe coding"不是答案
很多人理解的AI编程是：打开Cursor，prompt直到 something works，commit，repeat。
但Peter警告：
“That produces prototypes. A production system needs to be stable, reliable, and secure. You need a system that can guarantee those properties when AI writes the code.”
原型和生产系统是两码事。生产系统需要稳定、可靠、安全。这些属性不能依赖prompt，而需要系统来保证。
三、Creao的三个瓶颈与重构路径
瓶颈一：产品管理瓶颈
传统的产品管理流程：PM花数周研究、设计、撰写需求文档。这种方式已经存在了几十年。
但当Agent可以在两小时内实现一个功能时，数月的规划周期变成了约束：
“It doesn’t make sense to think about something for months and then build it in two hours.”
PM需要进化成"具有产品思维的架构师"，以迭代的速度工作；或者退出构建循环。设计需要通过"快速原型-发布-测试-迭代"的循环来实现，而不是通过委员会评审的需求文档。
瓶颈二：QA瓶颈
同样的动态：Agent两小时完成功能，QA花三天测试边界情况。构建时间2小时，测试时间3天。
Peter的解决方案是：用AI构建的测试平台来测试AI编写的代码。验证必须与实现以相同的速度运行。否则，你只是在旧瓶颈下游十英尺处建了一个新瓶颈。
瓶颈三：人数瓶颈
Creao的竞争对手有100倍甚至更多人力来做类似的工作。Creao只有25人。他们无法通过招聘来达到对等，只能通过重新设计来达到。
三个系统都需要AI贯穿其中：
- 如何设计产品
- 如何实现产品
- 如何测试产品
如果任何一个保持手动，它就会约束整个管道。
四、大胆的决定：统一架构
为什么必须做Monorepo
Peter在重构时面临的第一个问题是代码库：
“Our old architecture was scattered across multiple independent systems. A single change might require touching three or four repositories. From a human engineer’s perspective, it is manageable. From an AI agent’s perspective, opaque. The agent can’t see the full picture. It can’t reason about cross-service implications. It can’t run integration tests locally.”
从人类工程师的角度，多仓库是可以管理的。但从AI Agent的角度，这是不透明的——Agent看不到全貌，无法推理跨服务的影响，无法在本地运行集成测试。
Peter的结论是：必须统一到一个Monorepo。
核心原则：Legibility（可读性）创造杠杆
“The more of your system you pull into a form the agent can inspect, validate, and modify, the more leverage you get. A fragmented codebase is invisible to agents. A unified one is legible.”
这是Harness的核心原则：你的系统越多地以Agent能够检查、验证和修改的形式呈现，你获得的杠杆就越大。 碎片化的代码库对Agent是不可见的；统一的代码库是 legible（可读/可理解的）。
执行：两周重构
- 第一周：设计新系统——规划阶段、实现阶段、测试阶段、集成测试阶段
- 第二周：使用Agent重新构建整个代码库架构
Creao是Agent平台。他们用自己的Agent重建了运行Agent的平台。
“If the product can build itself, it works.”
五、技术栈：六阶段CI/CD管道
基础设施：AWS
- Auto-scaling容器服务
- Circuit-breaker回滚：如果指标在部署后下降，系统自动回滚
- CloudWatch作为中央神经系统：跨所有服务的结构化日志、25个以上的告警、自定义指标
关键原则：如果AI无法读取日志，它就无法诊断问题。
CI/CD：GitHub Actions
每个代码变更都经过六阶段管道：
Verify CI → Build and Deploy Dev → Test Dev → Deploy Prod → Test Prod → Release
每个PR的CI门禁强制执行：
- Typechecking
- Linting
- 单元和集成测试
- Docker构建
- 通过Playwright进行端到端测试
- 环境一致性检查
没有阶段是可选的。没有手动覆盖。管道是确定性的，所以Agent可以预测结果。
六、架构师的价值重估：在AI的90分方案上继续提升
架构师的黄昏？重新定义核心能力
“AI写代码的能力肯定是在我之上的，2026年我就没有写过一行代码。但是从规划的能力上来讲，架构师的价值就是在于找到AI planning的缺陷。”
架构师的核心价值不再是"设计"，而是"批判"。
传统架构师的工作是"从无到有"的创造性工作。AI时代的架构师，面对的不再是一张白纸——AI已经给出了一个"90分的方案"，架构师要做的是在这个方案上找出缺陷。
这不是退步，而是进化：架构师的专业能力从"创造"转向"判断"，从"设计"转向"审视"。
Planning的缺陷：AI还未跨越的坎
AI可以给出90分的规划方案，但仍然存在缺陷：安全缺陷、延迟缺陷。AI擅长在给定框架内优化，但缺乏对框架本身的批判性思考。
AI的Planning能力建立在"统计意义上"的正确知识，而不是"逻辑意义上"的完备。AI可以告诉你"通常这种情况下应该怎么做"，但难以识别"你这个具体场景下，这个’通常做法’为什么不适用"。
人类的架构经验，不是记住了多少设计方案，而是理解了为什么某些方案在特定场景下会失败。这种"失败的直觉"是AI目前难以企及的。
未来核心竞争力：两个方向
方向一：批判性思维与系统审视能力
当AI能够完成大部分"执行性"工作后，人的价值在于能够审视AI的方案。批判性思维是一种"系统性质控"的能力——能够从安全性、可靠性、可维护性、扩展性等多个维度评估AI产出的质量。
方向二：价值判断与优先级决策能力
当feature的数量"远远多过于我们所需要的数量"时，如何判断"什么功能值得做"就成为了稀缺能力。这需要对市场的洞察、对用户的理解、对技术成本的评估——这些都是AI难以独立完成的。
七、SaaS产品的新命题：让Agent能够"看到"和"使用"
从给人看到给Agent看
传统的SaaS产品设计逻辑是"给人看"：dashboard展示关键指标供人决策。但在AI-First的世界里，Agent将成为主要的"用户"——它需要"看到"任务列表、理解任务优先级、自动执行任务并反馈结果。
这意味着SaaS产品需要提供更好的MCP（模型上下文协议）和API来让Agent使用。产品价值不再只是"给人用的体验好不好"，而是"给Agent用的体验好不好"。
数据的消费者变了：从人到Agent
未来的内容消费者可能不是人，而是Agent。
一家公司的市场部门制作了一份营销物料。从人的视角看，可能"审美不好"；但如果真正的消费者是Agent——采购Agent、新闻聚合Agent、内容推荐Agent——那评价标准就完全不同了。Agent关心的是信息密度、准确性、结构化程度，而不是视觉美感。
在AI-First时代，工作的价值不是由"人觉得好不好"来定义的，而是由"消费这个产出的主体是人是AI"来定义的。
八、组织变革的深层阻力：不是技术，是人心
思维模式转变：最昂贵的隐性成本
Peter提到，在整个重构过程中"花的最多的时间就是让大家转变思维方式"。这句话轻描淡写，但经历过组织变革的人都知道，这才是最难的。
AI-First转型面临的最大阻力，不是技术实现的难度，而是认知升级的阻力。
在传统组织中，人的价值建立在"我能做什么"上：工程师的价值是能写代码，产品经理的价值是能写PRD。AI-First转型要求人放弃"我能做什么"，转而接受"AI能做什么"。
对于资深从业者来说，这意味着他们花费数十年积累的专业能力正在贬值。这种"能力折旧"的焦虑，是AI-First转型中最大的心理障碍。
对系统的信任 vs 对人的信任
Peter说："转型最难跨出的一步在于——是否能让所有员工都能做到信任AI。"
传统组织的信任体系建立在"人"上：有"责任人"可以追溯，有"权威"可以裁决。AI-First组织的信任体系建立在"系统"上：不是因为系统不会出错，而是因为系统出错了能够自我修复。
当团队中有人对系统不信任时，他们会不自觉地"复核AI的工作"。这种行为表面上是"负责"，实际上是在引入人工瓶颈，抵消AI的效率优势。
共同目标：转型的催化剂
Peter提到："只要有人觉得还不如人做，改造时间就会被拉长。 这是大多数企业从组织上面临的挑战。"
AI-First转型不是一个人的战斗，而是需要整个团队形成共识。当所有人都真正接受"让AI成为生产力主导者"这个目标，并愿意为此改变自己的工作方式时，转型才能真正落地。
九、展望：Harness的下一步
AI能力的持续进化
2025年11月，Creao开始构建Agent；2026年1月，Peter进行了彻底重构；2026年2月，OpenAI发表了"harness engineering"概念。
一年前让AI主导开发"从技术上来说不成立"，但现在它成立了。这个时间节点的出现，与基础模型能力的提升、Agent架构的成熟、基础设施的完善都密切相关。
可以预见，随着AI能力的持续提升，AI能够主导的工作范围会继续扩大。今天AI在"执行"层面已经超越人类；明天AI在"规划"层面可能也会达到人类的水平。
AI-First不是一个终点，而是一个持续演进的过程。
人机协作的新范式
在可预见的未来，AI不会完全取代人，人也不会完全依赖AI。更可能的图景是：
- AI负责"做"：执行任务、生成方案、优化迭代
- 人负责"判断"：评估AI方案的价值、识别系统缺陷、决定演进方向
- 系统负责"进化"：收集反馈、调整策略、自我优化
这种协作范式要求人具备全新的能力结构：不再需要"能做"的技能，而是需要"会判"的智慧；不再需要"执行经验"，而是需要"批判性洞察"。
组织形态的重新定义
当AI成为生产力的主导者时，组织的形态也会发生根本性变化：
- “部门墙"可能被打破：AI驱动的流程自动跨越职能边界
- “层级制"可能被重塑：当决策可以由AI基于数据实时做出时，传统的"请示汇报"流程变得多余
- “专业分工"可能被重新定义：当AI可以跨界工作时，传统的"垂直领域专家"概念需要更新
当生产力发生根本性变化时，社会组织形态也必然随之变革。 Harness Engineering不仅仅是一种技术实践，它可能是这场变革的序曲。
结语：在信任的废墟上重建
Peter在原文结尾写道：
“When something fails, the fix is never ’try harder.’ The fix is: what capability is missing, and how do we make it legible and enforceable for the agent?”
这句话揭示了AI-First转型的本质：不是技术的升级，而是心智模式的重建。
我们曾经信任人：信任项目经理能够理解需求，信任架构师能够设计系统。现在，我们要学会信任系统：信任AI能够正确决策，信任系统能够快速修复错误。
这是一场艰难但必要的转变。只有完成了这种信任重建，我们才能真正释放AI的生产力潜能，在效率提升100倍、1000倍的道路上继续前进。
而对于每一个个体来说，这场变革既是挑战也是机遇：挑战在于旧的能力正在贬值；机遇在于新的能力正在形成。关键在于，我们是否愿意放下"我能做什么"的执念，去拥抱"我能让系统做什么"的新思维。
AI Native时代已经到来。你准备好了吗？