💡 关于作者 Peter Pang：物理学博士，曾参与 Meta LLaMA 大模型研发，前 Apple 工程师，现为 AI Agent 平台 CREAO 联合创始人 & CTO。

最近，Peter Pang 在 X（推特）上发表的一篇长文引发了刷屏级讨论。他犀利地指出：大多数公司标榜的 “AI 优先”，本质上只是效率提升 10-20% 的 “AI 辅助”。

真正的 AI 原生组织应该长什么样？Peter 的 CREAO 团队给出了一个令人震撼的答案：10 名工程师完成百人规模的工作量，99% 的代码由 AI 编写。一个功能从上线到验证再到迭代，全程不超过一天。

不仅是工程团队，CREAO 还将 AI 原生运营推向了所有职能：工程、产品、市场营销、增长等。

TinTinLand 对原文进行了编译。这套方法论，或许值得每一个正在做 AI 的团队认真看一遍。

📖 原文：https://x.com/intuitiveml/status/2043545596699750791

为什么你的「AI 优先战略」很可能是错的

我们公司 99% 的生产代码都是由 AI 编写的。上周二，我们上午 10 点发布了一个新功能，中午完成 A/B 测试，下午 3 点因为数据反馈不佳将其关停，下午 5 点又发布了改进版本。在三个月前，这样一个迭代需要六周。

我们能做到这一点，并非简单地在 IDE 里加个 Copilot。我们彻底拆解了原有的工程流程，并围绕 AI 进行了重构。我们改变了规划、构建、测试、部署，也改变了整个团队的组织架构。

CREAO 是一个 Agent（智能体）平台。我们有 25 名员工，10 名工程师。我们从 2025 年 11 月开始构建 Agent，两个月前，我对整个产品架构和工作流进行了彻底重构。

OpenAI 在 2026 年 2 月发布了一个概念，准确描述了我们正在做的事情。OpenAI 称之为治理工程（Harness Engineering）：工程团队的首要任务不再是编写代码，而是赋能 Agent 去完成有用的工作。

当出现故障时，修复方法绝不是 “再试一次”，而是：缺失了什么能力？如何让 Agent 能够清晰地理解并执行该能力？

我们独立得出了这个结论，只是当时还没给它起名字。

“AI 优先” 不等于 “使用 AI”

大多数公司只是把 AI 嵌入现有流程：工程师打开 Cursor，产品经理用 ChatGPT 起草需求，QA 用 AI 生成测试用例。工作流没变，效率提升了 10% 到 20%，但结构上毫无变化。

这叫 AI 辅助（AI-assisted）。

而 AI 优先（AI-first）意味着必须围绕「AI 是主要构建者」这一假设，重新设计流程、架构和组织。

两者的差距是数量级的。

很多团队自称 AI 优先，却还在跑同样的 Sprint 周期、用同样的 Jira 看板、走同样的 QA 审核流程。他们只是把 AI 加进了循环，并没有重新设计循环。

最典型的例子就是 “Vibe Coding”：打开 Cursor，不断输入提示词直到跑通，提交代码，循环往复。这只能产出原型。一个生产级系统必须稳定、可靠、安全。你需要一套系统在 AI 写代码时依然能保证这些特性。

你应该构建的是这套体系，而提示词是随时丢弃的。

我们为何必须改变？

去年，我观察团队工作时，发现了三个致命的瓶颈：

产品管理瓶颈

过去几十年，PM 习惯于花数周时间进行调研、设计和编写需求文档。

但 Agent 能在两小时内完成一个功能的实现。花几个月去构思一个只需两小时就能做出来的东西，这显然不合逻辑。

产品经理需要进化为具备产品思维的架构师，以迭代的速度工作。设计应该通过「快速原型→发布→测试→迭代」的闭环来完成，而不是靠委员会审阅需求文档。

QA 瓶颈

同样的逻辑。Agent 发布功能后，QA 团队要花好几天测试边缘案例。结果是：构建两小时，测试三天。

我们用 AI 构建的测试平台取代了人工 QA，专门测试 AI 编写的代码。验证速度必须与实现速度匹配。

人员规模瓶颈

竞争对手人力规模是我们的百倍，而我们只有 25 人。靠招聘追不上差距，只能靠流程重构。

产品设计、产品实现、产品测试 —— 三个环节都需要 AI 深度介入。只要其中任一环节还依赖人工，就会拖慢整条流水线。

重大决策：统一架构

首先必须解决代码库的问题。

我们的旧架构散布在多个独立系统中。一个简单的变更可能需要触动三四个代码库。对人类工程师来说，这尚可应付；但对 AI Agent 而言，这太不透明了。Agent 无法看到全貌，无法推断跨服务的副作用，也无法在本地运行集成测试。

我必须把所有代码合并到一个单体代码仓库（monorepo）。原因只有一个：让 AI 能看到全貌。

这正是治理工程（Harness Engineering）原则的实战应用：将系统转化为 Agent 可检查、验证和修改的程度越高，获得的杠杆就越大。碎片化的代码库对 Agent 是隐形的，而统一的代码库才是可读的。 

我花了一周时间设计新系统：规划阶段、实现阶段、测试阶段、集成测试阶段。然后又花了一周时间用智能体对整个代码库进行重构。

技术栈

以下是我们的技术栈及其具体分工。

基础设施：AWS

我们运行在 AWS 上，配备了容器自动扩容和熔断回滚机制。如果部署后指标下降，系统会自动回滚。

CloudWatch 是中枢神经系统。它涵盖了所有服务的结构化日志、25 个以上的警报，以及由自动化工作流每日查询的自定义指标。每一件基础设施都会暴露结构化的、可查询的信号。如果 AI 读不懂日志，它就无法诊断问题。

CI/CD：GitHub Actions 每次代码变更都经过六阶段流水线：

验证CI → 构建并部署开发环境 → 测试开发环境 → 部署生产环境 → 测试生产环境 → 发布

每个 Pull Request 的 CI 关卡都会强制执行类型检查、Lint 检查、单元与集成测试、Docker 构建、基于 Playwright 的端到端测试以及环境一致性检查。没有可选环节，没有人工绕过的通道。流水线是确定性的，这样 Agent 才能预测结果并推断故障原因。

AI 代码审查：Claude

每个 PR 都会触发三轮并行的 AI 审查，由 Claude Opus 4.6 执行：

• 第一轮：代码质量。检查逻辑错误、性能瓶颈、可维护性。

• 第二轮：安全。漏洞扫描、身份验证边界检查、注入风险。

• 第三轮：依赖项扫描。供应链风险、版本冲突、许可协议问题。

以上是审查关卡，不是建议。它们与人工审查并行，捕捉人类容易忽略的问题。当你一天部署八次时，没有哪个人类审核员能对每个 PR 都保持高度专注。

工程师还可以在 GitHub Issue 或 PR 中通过 @claude 获取实现方案、调试支持或代码分析。Agent 拥有整个单体仓库（Monorepo）的视野，上下文可以在对话中延续。

自愈反馈循环（The Self-Healing Feedback Loop）

这是整个系统的核心。

每天 UTC 时间上午 9:00，自动化健康检查工作流启动。Claude Sonnet 4.6 查询 CloudWatch，分析所有服务的错误模式，并生成一份执行摘要发送至 Microsoft Teams。不需要人主动去触发它。

一小时后，分诊引擎（Triage Engine）启动。它从 CloudWatch 和 Sentry 中聚类生产环境错误，按九个维度对严重程度评分，并在 Linear 中自动生成调查工单。每张工单都包含日志样本、受影响用户、异常接口以及建议的排查路径。

系统自动去重：如果已有工单覆盖了相同的错误模式，它会更新该工单；如果已关闭的问题再次出现，它会检测到回归并重新开启。

当工程师提交修复补丁时，同样的流水线继续处理：三轮 Claude 审查、CI 验证、六阶段部署。部署完成后，分诊引擎会重新检查 CloudWatch，若原始错误已解决，Linear 工单会自动关闭。

每个工具只负责一个阶段，没有工具试图包揽一切。 这种每日循环创造了一个只需极少人工干预的自愈闭环。

💬 “AI 来提交 PR，人只需要审查是否存在风险。”

功能开关与辅助工具

• Statsig 处理功能开关。每个功能都在开关保护下发布。发布模式为：先对团队开启，接着按比例逐渐扩量，最后全量或关停。“紧急开关” 可以瞬间关闭功能，无需重新部署。 如果某个功能导致指标下降，我们几小时内就会撤掉它。烂功能在上线当天就会夭折。A/B 测试也跑在这套系统上。

• Graphite 管理 PR 分支：合并队列会自动变基（Rebase）到主分支，重新运行 CI，只有测试通过才允许合并。堆叠式 PR（Stacked PRs）实现了高吞吐量的增量评审。

• Sentry 报告结构化异常，由分诊引擎将其与 CloudWatch 数据合并，提供跨工具的上下文。

• Linear 是面向人类的界面：自动创建包含严重性评分、日志样本和调查建议的工单。

功能从想法到生产的全流程

新功能路径

1️⃣ 架构师定义任务，包括结构化的提示词、代码库上下文、目标和约束。

2️⃣ Agent 拆解任务、规划路径、编写代码并生成配套测试。

3️⃣ PR 开启。三轮 Claude 审查。人类审核员检查战略风险，而非逐行核对代码正确性。

4️⃣ CI 验证：类型、Lint、单元/集成/端到端测试。

5️⃣ Graphite 合并队列：自动变基、重跑 CI、通过后合并。

6️⃣ 六阶段部署：逐级推进并伴随阶段性测试。

7️⃣ 功能开关：团队试用 → 按比例灰度 → 指标监控。

8️⃣ 紧急关停/自动回滚：指标异常立即撤回；严重问题自动熔断回滚。

Bug 修复路径

• 检测：CloudWatch 和 Sentry 发现异常。

• 分诊：Claude 评分并创建 Linear 工单，附带完整调查背景。

• 修复：工程师介入。由于 AI 已经完成了诊断，工程师只需验证并提交修复代码。

• 验证与发布：走同样的审查、CI、部署和监控流程。

• 闭环：分诊引擎重新验证，若修复成功，工单自动关闭。

两条路径共用同一套流水线。一个系统，一个标准。

变革的成果

在 14 天的时间里，我们平均每天进行 3 到 8 次生产部署。而在旧模式下，整整两周可能连一次发布都没有。

有问题的功能在上线当天就会被撤回，新功能在构思当天就能上线。A/B 测试实时验证效果。

人们总以为我们在 “用质量换速度”，但事实是用户参与度和支付转化率都提高了。因为反馈循环更紧密了：每天发布比每月发布学到更多。

新的工程组织形态

未来只有两类工程师：

架构师

一到两人。他们负责设计 SOP（标准作业程序）来教会 AI 如何工作；构建测试基础设施、集成系统和分诊系统。他们决定架构边界，并定义什么是 Agent 眼中的 “好标准”。

这个角色需要深度批判性思维。你的工作是质疑 AI，而不是跟随它。当智能体提出一个方案时，架构师要找出漏洞：它漏掉了哪些失效模式？越过了哪些安全边界？积累了多少技术债？

批判 AI 的能力，将比生产代码的能力更有价值。这也是最难填补的岗位。

操作员

其余所有人都是操作员。工作依然重要，但结构变了。

AI 向人类分配任务。分诊系统发现 Bug，创建工单，给出诊断，并指派给合适的人。人类负责调查、验证并批准修复方案。AI 提交 PR，人类审核风险。

任务涵盖 Bug 排查、UI 抛光、CSS 优化、PR 评审和验证。这需要专注和技能，但不再需要旧模式下的那种架构推理能力。

谁适应得最快？

我发现了一个意外的规律：初级工程师比资深工程师适应得更快。

初级工程师没有需要打破的 “十年旧习惯”，AI 工具反而放大了他们的影响力。

经验丰富的高级工程师适应最困难。原本需要两个月的工作量，AI 一小时就干完了。在积累了多年稀缺技能之后，这是一件很难接受的事。

这不是评判，而是事实：在这次转型中，适应力比积累的技能更重要。

人性的那一面

• 管理成本骤降：

  两个月前，我 60% 的时间花在管理上（开会、对齐、教练），现在管理时间花费不到 10%。我从管理者转回了建造者，每天写代码到凌晨 3 点。虽然压力大，但我更享受构建，而不是 “对齐”。

• 关系改善：

  我和合伙人、工程师的关系变好了。以前，我和团队的大部分互动都是对齐会议：讨论权衡、争论优先级、在技术决策上产生分歧，非常消耗精力。现在系统解决了这些问题，我们有更多时间聊非工作的话题。

• 真实的不确定性：

  转型期的焦虑是真实的。当 CTO 不再每天找人谈话，成员会担心自己的价值。我没有完美的标准答案，但我坚持一个原则：我们不因 Bug 解雇员工，而是去改进审查流程、强化测试、增加防护机制。对 AI 也是一样。

超越工程界限

很多公司采用了 AI 优先的工程模式，其他一切却保持人工运作。

如果工程部几小时就能出功能，而市场部要花一周才发公告，那市场部就是瓶颈。如果产品团队还在跑月度规划周期，那规划就是瓶颈。

在 CREAO，我们将 AI 原生运营推向了所有职能：

• 产品发布说明：由 AI 根据变更日志和功能描述自动生成；

• 功能介绍视频：由 AI 生成动态视觉效果；

• 社交媒体每日推文：AI 编排并自动发布；

• 健康报告和分析摘要：由 AI 自动分析日志和数据库生成摘要。

工程、产品、市场营销、增长 —— 都运行在同一个 AI 原生工作流中。如果一个职能以 Agent 速度运行，另一个保持人工速度，那么后者就会拖慢一切。

判断及建议

对工程师

你的价值正在从代码产出转向决策质量。快速写代码的能力每个月都在贬值，评估、批判和指导 AI 的能力则在升值。

产品感知和品味很重要：你能在用户反馈之前就看出生成的 UI 有问题吗？你能看一眼架构提案就找出 Agent 遗漏的故障点吗？

学会评估论点、找出漏洞、质疑假设。

对 CTO 和创始人的建议

• 如果你的产品管理流程比构建时间还长，先改 PM。

• 先构建测试框架，再扩大智能体规模。

• 从架构开始，一个人先把系统建起来并跑通。系统稳定后，再让其他人以运营者角色加入。

• 把 AI 原生模式推进每一个职能。改革将会有阻力，部分员工会抵触。

对整个行业的判断

OpenAI、Anthropic 以及多个团队都指向了相同的原则：结构化上下文、专业化智能体、持久记忆、执行循环。治理工程（Harness Engineering）正在成为标准。

这一切的驱动力是大模型能力的进步。CREAO 的整体转变，我都归因于过去两个月 Opus 4.6 的进步。下一代模型会进一步加速。

我相信单人公司（OPC）将会变得普遍。如果一个架构师加上智能体能完成 100 个人的工作，很多公司将不再需要第二名员工。

结语：我们仍然在早期

我接触的大多数创始人和工程师仍在沿用传统方式。一些人在考虑是否要做出转变，真正付诸行动的极少。

工具是现成的，我们没有什么秘密武器。竞争优势在于重构一切的决心，以及愿意承担转型的代价。

阵痛是真实的：员工的不安、CTO 每天工作 18 小时、高级工程师对自身价值的质疑、新旧系统交替那两周的茫然。我们承受了这些代价。两个月后，数字说明了一切。

我们构建 Agent 平台，并且我们用 Agent 构建了它。