为什么你的"AI-First"战略可能是错的——CreaoAI 的全面重构实践

原文链接：Why Your “AI-First” Strategy Is Probably Wrong
作者：Peter Pang（CreaoAI 联合创始人，前 Meta LLaMA 团队）
发布时间：2026-04-13
翻译与总结：2026-04-15

前言

这篇文章来自 Peter Pang 在 X（Twitter）上发布的长文，发布后迅速获得了 3100+ 点赞、9300+ 收藏、160 万+ 阅读，引发了广泛讨论。

Peter Pang 是 CreaoAI 的联合创始人，此前在 Meta 参与 LLaMA 项目。CreaoAI 是一个 Agent 平台，仅有 25 名员工、10 名工程师。他在文中详细描述了如何将整个公司的工程流程、产品流程、测试流程围绕 AI 进行彻底重构，而不是简单地"在现有流程上加一个 AI 工具"。

这篇文章的核心观点与 OpenAI 在 2026 年 2 月提出的 Harness Engineering（驾驭工程） 概念高度一致：工程团队的首要工作不再是写代码，而是让 Agent 能够有效地完成工作。

以下是原文的完整翻译，附带我的结构化总结。

---

总结：五个核心洞察

1. AI-Assisted ≠ AI-First

大多数公司只是在现有流程上"贴"了一层 AI——工程师用 Cursor，PM 用 ChatGPT 写需求文档，QA 试用 AI 测试生成。效率提升 10-20%，但流程本身没有变。

真正的 AI-First 意味着：围绕"AI 是主要构建者"这一假设，重新设计流程、架构和组织。不再问"AI 怎么帮助我们的工程师"，而是问"怎么重构一切，让 AI 来构建，工程师提供方向和判断"。

2. 三大瓶颈必须同时打破

瓶颈	问题	解法
产品管理	PM 花数周做需求，Agent 2 小时就能实现	PM 转型为产品架构师，通过快速原型-发布-测试-迭代循环来设计
QA	构建 2 小时，测试 3 天	用 AI 构建的测试平台来测试 AI 写的代码
人力	竞争对手 100 倍人力	不靠招人，靠重新设计

3. 统一架构是 AI 生产力的前提

分散在多个仓库的架构对人类可管理，但对 AI Agent 来说是不透明的。Agent 无法看到全局、无法推理跨服务影响、无法本地运行集成测试。

解法：统一为单一 Monorepo，让 AI 能看到一切。这是 Harness Engineering 的核心原则——系统越多地以 Agent 可检查、可验证、可修改的形式存在，你获得的杠杆就越大。

4. 自愈反馈循环是核心基础设施

CreaoAI 构建了一个完整的自愈循环：

每日 9:00 UTC 健康检查（Claude Sonnet 4.6 分析 CloudWatch）
→ 1 小时后自动分诊（聚类错误、9 维度评分、自动创建 Linear 工单）
→ 工程师推送修复 → 3 轮 Claude 代码审查 → CI 验证
→ 6 阶段部署流水线 → 分诊引擎重新检查 → 自动关闭工单

5. 工程组织的新二分法

角色	人数	职责
架构师	1-2 人	设计 SOP、构建测试/集成/分诊基础设施、定义"好"的标准、批判 AI
操作员	其余所有人	Bug 调查、UI 优化、PR 审查、验证——AI 分配任务给人类

“批判 AI 的能力将比产出代码的能力更有价值。”

---

原文翻译

开篇

我们 99% 的生产代码由 AI 编写。上周二，我们上午 10 点发布了一个新功能，中午完成了 A/B 测试，下午 3 点因为数据表现不佳而下线了它。下午 5 点我们发布了一个更好的版本。三个月前，这样一个周期需要六周时间。

我们不是通过在 IDE 里加个 Copilot 做到这一点的。我们拆解了整个工程流程，围绕 AI 重新构建。我们改变了规划、构建、测试、部署和团队组织的方式。我们改变了公司里每个人的角色。

CREAO 是一个 Agent 平台。25 名员工，10 名工程师。我们从 2025 年 11 月开始构建 Agent，两个月前我从头重构了整个产品架构和工程工作流。

OpenAI 在 2026 年 2 月发表了一个概念，恰好描述了我们一直在做的事情。他们称之为 Harness Engineering（驾驭工程）：工程团队的首要工作不再是写代码，而是让 Agent 能够有效地完成工作。当某件事失败时，修复方案永远不是"更努力地尝试"。修复方案是：缺少什么能力，以及我们如何让它对 Agent 来说是可读的、可执行的？

我们独立得出了同样的结论。只是当时我们没有给它起名字。

AI-First 不等于使用 AI

大多数公司把 AI 嫁接到现有流程上。工程师打开 Cursor。PM 用 ChatGPT 起草需求文档。QA 尝试 AI 测试生成。工作流保持不变。效率提升 10% 到 20%。结构上什么都没变。

那叫 AI 辅助（AI-assisted）。

AI-First 意味着你围绕"AI 是主要构建者"这一假设，重新设计你的流程、架构和组织。 你不再问"AI 怎么帮助我们的工程师？“而是开始问"我们怎么重构一切，让 AI 来构建，工程师提供方向和判断？”

差异是乘法级的。

我看到团队声称自己是 AI-First，却仍然跑着同样的 Sprint 周期、同样的 Jira 看板、同样的每周站会、同样的 QA 签收。他们把 AI 加进了循环。他们没有重新设计循环。

一个常见的版本就是人们所说的 Vibe Coding。打开 Cursor，提示直到某个东西能用，提交，重复。那能产出原型。一个生产系统需要稳定、可靠和安全。你需要一个系统来保证这些属性——当 AI 写代码的时候。你构建系统。提示词是一次性的。

为什么我们必须改变

去年，我观察了团队的工作方式，发现了三个会杀死我们的瓶颈。

产品管理瓶颈

我们的 PM 花数周时间研究、设计、编写功能规格。产品管理几十年来一直是这样工作的。但 Agent 可以在两小时内实现一个功能。当构建时间从数月坍缩到数小时，长达数周的规划周期就成了约束。

花几个月思考一件事，然后两小时就建好了——这说不通。

PM 需要进化为以迭代速度工作的产品型架构师，或者退出构建周期。设计需要通过快速的原型-发布-测试-迭代循环来进行，而不是在委员会里审查规格文档。

QA 瓶颈

同样的动态。Agent 发布一个功能后，我们的 QA 团队花好几天测试边界情况。构建时间：两小时。测试时间：三天。

我们用 AI 构建的测试平台替代了手动 QA，用来测试 AI 编写的代码。验证必须以与实现相同的速度进行。否则你只是在旧瓶颈下游十英尺处建了一个新瓶颈。

人力瓶颈

我们的竞争对手有 100 倍甚至更多的人在做类似的工作。我们有 25 人。我们无法通过招聘达到对等。我们必须通过重新设计来达到。

三个系统需要 AI 贯穿其中：我们如何设计产品、如何实现产品、如何测试产品。如果任何一个环节保持手动，它就会约束整个流水线。

大胆的决定：统一架构

我必须先修复代码库。

我们的旧架构分散在多个独立系统中。一个变更可能需要触及三四个仓库。从人类工程师的角度看，这是可管理的。从 AI Agent 的角度看，是不透明的。Agent 看不到全貌。它无法推理跨服务的影响。它无法在本地运行集成测试。

我必须把所有代码统一到一个 Monorepo 中。一个原因是：让 AI 能看到一切。

这是 Harness Engineering 原则的实践。你把系统越多地拉入 Agent 可以检查、验证和修改的形式，你获得的杠杆就越大。碎片化的代码库对 Agent 是不可见的。统一的代码库是可读的。

我花了一周设计新系统：规划阶段、实现阶段、测试阶段、集成测试阶段。然后又花了一周用 Agent 重新架构整个代码库。

CREAO 是一个 Agent 平台。我们用自己的 Agent 重建了运行 Agent 的平台。如果产品能构建自己，它就是有效的。

技术栈

以下是我们的技术栈及每个部分的作用。

基础设施：AWS

我们在 AWS 上运行，使用自动扩缩容容器服务和熔断回滚。如果部署后指标恶化，系统会自动回退。

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

CI/CD：GitHub Actions

每个代码变更都经过六阶段流水线：

验证 CI → 构建并部署 Dev → 测试 Dev → 部署 Prod → 测试 Prod → 发布

每个 Pull Request 上的 CI 门禁强制执行类型检查、Lint、单元测试和集成测试、Docker 构建、通过 Playwright 的端到端测试，以及环境一致性检查。没有阶段是可选的。没有手动覆盖。流水线是确定性的，所以 Agent 可以预测结果并推理失败原因。

AI 代码审查：Claude

每个 Pull Request 触发三个并行的 AI 审查通道，使用 Claude Opus 4.6：

• 通道 1：代码质量——逻辑错误、性能问题、可维护性
• 通道 2：安全——漏洞扫描、认证边界检查、注入风险
• 通道 3：依赖扫描——供应链风险、版本冲突、许可证问题

这些是审查门禁，不是建议。它们与人工审查并行运行，在大量 PR 中捕获人类遗漏的问题。当你一天部署八次时，没有人类审查者能在每个 PR 上保持注意力。

工程师还可以在任何 GitHub Issue 或 PR 中 @claude，获取实现计划、调试会话或代码分析。Agent 能看到整个 Monorepo。上下文在对话间延续。

自愈反馈循环

这是核心。

每天早上 UTC 9:00，一个自动化健康工作流运行。Claude Sonnet 4.6 查询 CloudWatch，分析所有服务的错误模式，并生成一份执行摘要通过 Microsoft Teams 发送给团队。没有人需要主动请求。

一小时后，分诊引擎运行。它从 CloudWatch 和 Sentry 聚类生产错误，在九个严重性维度上对每个集群评分，并在 Linear 中自动生成调查工单。每个工单包含示例日志、受影响用户、受影响端点和建议的调查路径。

系统会去重。如果一个已打开的 Issue 覆盖了相同的错误模式，它会更新该 Issue。如果一个之前已关闭的 Issue 再次出现，它会检测到回归并重新打开。

当工程师推送修复时，同样的流水线处理它。三轮 Claude 审查评估 PR。CI 验证。六阶段部署流水线在每个阶段通过 Dev 和 Prod 进行测试推进。部署后，分诊引擎重新检查 CloudWatch。如果原始错误已解决，Linear 工单自动关闭。

每个工具处理一个阶段。没有工具试图做所有事情。每日循环创建了一个自愈循环，其中错误被检测、分诊、修复和验证，几乎不需要手动干预。

我告诉 Business Insider 的一位记者：“AI 会创建 PR，人类只需要审查是否有风险。”

功能开关和支撑栈

Statsig 处理功能开关。每个功能都在门禁后发布。发布模式：先对团队启用，然后逐步百分比发布，最后全量发布或下线。Kill Switch 可以即时关闭一个功能，无需部署。如果一个功能导致指标恶化，我们在几小时内撤回。糟糕的功能在发布当天就会死掉。A/B 测试通过同一系统运行。

Graphite 管理 PR 分支：合并队列 Rebase 到 main，重新运行 CI，只有绿色才合并。堆叠 PR 允许在高吞吐量下进行增量审查。

Sentry 报告所有服务的结构化异常，由分诊引擎与 CloudWatch 合并以获得跨工具上下文。Linear 是面向人类的层：自动创建的工单带有严重性评分、示例日志和建议的调查方向。去重防止噪音。后续验证自动关闭已解决的 Issue。

功能从想法到生产的流转

新功能路径

1. 架构师将任务定义为带有代码库上下文、目标和约束的结构化 Prompt
2. Agent 分解任务、规划实现、编写代码并生成自己的测试
3. PR 打开。三轮 Claude 审查评估它。人类审查者检查战略风险，而不是逐行正确性
4. CI 验证：类型检查、Lint、单元测试、集成测试、端到端测试
5. Graphite 的合并队列 Rebase，重新运行 CI，绿色则合并
6. 六阶段部署流水线在每个阶段通过 Dev 和 Prod 进行测试推进
7. 功能门禁对团队开启。逐步百分比发布。监控指标
8. 如果任何指标恶化，Kill Switch 可用。严重问题触发熔断自动回滚

Bug 修复路径

1. CloudWatch 和 Sentry 检测错误
2. Claude 分诊引擎评估严重性，创建带有完整调查上下文的 Linear Issue
3. 工程师调查。AI 已经完成了诊断。工程师验证并推送修复
4. 同样的审查、CI、部署和监控流水线
5. 分诊引擎重新验证。如果已解决，工单自动关闭

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

成果

在 14 天内，我们平均每天 3 到 8 次生产部署。在我们的旧模式下，整个两周期间甚至不会产出一次生产发布。

糟糕的功能在发布当天就被撤回。新功能在构思当天就上线。A/B 测试实时验证影响。

人们以为我们是在用质量换速度。用户参与度上升了。支付转化率上升了。我们产出了比以前更好的结果，因为反馈循环更紧密了。每天发布比每月发布学到更多。

新的工程组织

将存在两种类型的工程师。

架构师

一到两个人。他们设计标准操作流程（SOP），教 AI 如何工作。他们构建测试基础设施、集成系统、分诊系统。他们决定架构和系统边界。他们为 Agent 定义"好"是什么样的。

这个角色需要深度批判性思维。你批判 AI。你不跟随它。当 Agent 提出一个计划时，架构师找出漏洞。它遗漏了什么失败模式？它越过了什么安全边界？它在积累什么技术债务？

我有物理学博士学位。我的博士学位教给我最有用的东西是如何质疑假设、压力测试论点、寻找缺失的东西。批判 AI 的能力将比产出代码的能力更有价值。

这也是最难填补的角色。

操作员

其他所有人。工作很重要。结构不同。

AI 给人类分配任务。分诊系统发现一个 Bug，创建一个工单，呈现诊断结果，并分配给合适的人。这个人调查、验证并批准修复。AI 创建 PR。人类审查是否有风险。

任务是 Bug 调查、UI 优化、CSS 改进、PR 审查、验证。它们需要技能和注意力。它们不需要旧模式所要求的架构推理。

谁适应得最快

我注意到一个出乎意料的模式。初级工程师比高级工程师适应得更快。

传统实践较少的初级工程师感到被赋能了。他们获得了放大其影响力的工具。他们不需要卸载十年的习惯。

传统实践很强的高级工程师最难适应。他们两个月的工作可以被 AI 在一小时内完成。在多年建立稀有技能集之后，这很难接受。

我不是在做判断。我在描述我观察到的。在这次转型中，适应性比积累的技能更重要。

人的一面

管理坍缩了

两个月前，我 60% 的时间花在管理人上。对齐优先级。开会。给反馈。辅导工程师。

今天：低于 10%。

传统的 CTO 模式说要赋能你的团队做架构工作，培训他们，委派。但如果系统只需要一两个架构师，我需要先自己做。我从管理转向了构建。大多数日子我从早上 9 点编码到凌晨 3 点。我设计系统的 SOP 和架构。我维护 Harness。

更有压力。但我享受构建，而不是对齐。

更少争论，更好的关系

我与联合创始人和工程师的关系比以前更好了。

转型之前，我与团队的大部分互动是对齐会议。讨论权衡。辩论优先级。在技术决策上产生分歧。这些对话在传统模式中是必要的。它们也很消耗人。

现在我仍然和团队交谈。我们谈论其他事情。非工作话题。随意的对话。团建旅行。我们相处得更好了，因为我们不再为系统可以轻松完成的工作而争论。

不确定性是真实的

我不会假装每个人都开心。

当我不再每天和人们交谈时，一些团队成员感到不确定。CTO 不和我说话意味着什么？在这个新世界里我的价值是什么？合理的担忧。

有些人花更多时间辩论 AI 是否能做他们的工作，而不是做工作本身。过渡期会产生焦虑。我没有一个干净的答案。

我有一个原则：我们不会因为工程师引入了一个生产 Bug 而解雇他。我们改进审查流程。我们加强测试。我们添加护栏。同样适用于 AI。如果 AI 犯了错误，我们构建更好的验证、更清晰的约束、更强的可观测性。

超越工程

我看到其他公司采用 AI-First 工程，但把其他一切都留在手动状态。

如果工程在几小时内发布功能，但市场营销需要一周来宣布它们，市场营销就是瓶颈。如果产品团队仍然运行月度规划周期，规划就是瓶颈。

在 CREAO，我们把 AI 原生运营推进到每个职能：

• 产品发布说明：从变更日志和功能描述中 AI 生成
• 功能介绍视频：AI 生成的动态图形
• 每日社交媒体帖子：AI 编排并自动发布
• 健康报告和分析摘要：从 CloudWatch 和生产数据库中 AI 生成

工程、产品、市场和增长在一个 AI 原生工作流中运行。如果一个职能以 Agent 速度运行，另一个以人类速度运行，人类速度的职能就会约束一切。

这意味着什么

对工程师

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

产品感觉或品味很重要。你能在用户告诉你之前，看着一个生成的 UI 就知道它是错的吗？你能看着一个架构提案就看到 Agent 遗漏的失败模式吗？

我告诉我们 19 岁的实习生：训练批判性思维。学会评估论点、发现漏洞、质疑假设。学习好的设计是什么样的。这些技能会复利增长。

对 CTO 和创始人

如果你的 PM 流程比构建时间还长，从那里开始。

在扩展 Agent 之前先构建测试 Harness。没有快速验证的快速 AI 就是快速移动的技术债务。

从一个架构师开始。一个人构建系统并证明它有效。在系统运行后，将其他人纳入操作员角色。

把 AI 原生推进到每个职能。

预期阻力。有些人会反对。

对行业

OpenAI、Anthropic 和多个独立团队收敛到了相同的原则：结构化上下文、专业化 Agent、持久记忆和执行循环。Harness Engineering 正在成为标准。

模型能力是驱动这一切的时钟。我把 CREAO 的整个转变归因于最近两个月。Opus 4.5 做不到 Opus 4.6 能做的事。下一代模型会进一步加速。

我相信一人公司将变得普遍。如果一个架构师加上 Agent 能做 100 人的工作，很多公司不需要第二个员工。

我们还很早期

我交谈的大多数创始人和工程师仍然以传统方式运作。有些人在考虑做出转变。很少有人真正做了。

一位记者朋友告诉我，她就这个话题采访了大约五个人。她说我们比任何人都走得更远：“我不认为有任何人像你们这样彻底重建了整个工作流。”

任何团队都可以用这些工具做到这一点。我们的技术栈中没有任何专有的东西。

竞争优势在于围绕这些工具重新设计一切的决定，以及承受代价的意愿。代价是真实的：员工的不确定性、CTO 每天工作 18 小时、高级工程师质疑自己的价值、两周时间里旧系统已经消失而新系统尚未被证明。

我们承受了这个代价。两个月后，数字说话了。

我们构建了一个 Agent 平台。我们用 Agent 构建了它。

---

我的思考

这篇文章最打动我的不是技术栈的选择（AWS + GitHub Actions + Claude + Statsig + Linear 都是常见工具），而是组织层面的彻底性：

1. 不是加法，是乘法：大多数团队把 AI 当作效率提升的加法项（+20%），而 CreaoAI 把它当作乘法项——重新设计整个循环
2. 瓶颈思维：当构建时间坍缩后，PM 规划和 QA 测试成为新瓶颈，必须同步重构
3. 可观测性即可 AI 化：如果 AI 读不了日志，它就诊断不了问题——这个原则适用于所有想让 AI 参与的环节
4. 人的代价是真实的：高级工程师的身份危机、CTO 从管理者变回 IC、团队的不确定感——这些不是可以忽略的"软问题"

这与我之前研究的 Harness Engineering 三级跃迁 高度一致。CreaoAI 的实践是 Harness Engineering 从理论到实战的一个极好案例。

参考资料

• 原文推文 - Peter Pang (@intuitiveml)
• CreaoAI 官网
• OpenAI Harness Engineering 概念（2026年2月） — 原文中提及 OpenAI 于 2026 年 2 月发布的 Harness Engineering 概念