你的「AI 优先」战略多半是错的

本文翻译自 Why Your “AI-First” Strategy Is Probably Wrong^[1]作者：@intuitiveml^[2]— CREAO AI 联合创始人兼 CTO，前 Meta GenAI 技术负责人（LLaMA 团队），曾任 Apple AI 科学家发布时间：2026-04-13翻译：searchpcc授权：未获明确授权，仅作学习交流，如有异议请联系删除

我们 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-First 意味着你以「AI 是主要建造者」为前提，重新设计你的流程、架构和组织。你不再问「AI 怎么帮助我们的工程师？」而开始问「我们该如何重构一切，让 AI 来建造，工程师提供方向和判断？」

两者的差距是倍乘级的。

我看到很多团队号称 AI-First，却依然跑着同样的 sprint、同样的 Jira 看板、同样的周会、同样的 QA 签字。他们只是把 AI 加进了循环，并没有重新设计这个循环。

常见的一种形式就是所谓的 vibe coding：打开 Cursor，一通 prompt 直到能跑，提交，循环。这能做原型。但生产系统需要稳定、可靠、安全。你需要一个系统来在 AI 写代码时保证这些性质。你要建的是这个系统，prompt 本身是一次性的。

为什么必须变

去年，我观察团队的工作方式，看到了三个会把我们拖死的瓶颈。

产品管理瓶颈

我们的 PM 花几周时间调研、设计、撰写功能规格。产品管理几十年来就是这么做的。但 Agent 可以在两小时内实现一个功能。当构建时间从几个月压缩到几小时，为期数周的规划周期就成了瓶颈。

花几个月思考一件事，然后两小时把它建出来——这没道理。

PM 要么进化成具备产品思维、以迭代速度工作的架构师，要么退出构建循环。设计必须通过「快速原型—上线—测试—迭代」的循环发生，而不是靠在委员会里评审的规格文档。

QA 瓶颈

同样的道理。Agent 交付一个功能后，我们的 QA 团队要花好几天测边界情况。构建：2 小时；测试：3 天。

我们用「AI 搭建的、用来测试 AI 所写代码」的测试平台取代了人工 QA。验证必须以和实现一样的速度推进，否则你只是把旧瓶颈往下游挪了几米。

人头瓶颈

我们的竞争对手用上百倍以上的人在做可比的工作。我们只有 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

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

Verify CI → Build and Deploy Dev → Test Dev → Deploy Prod → Test Prod → Release

每个 PR 上的 CI 门禁强制执行：类型检查、lint、单元与集成测试、Docker 构建、基于 Playwright 的端到端测试、环境一致性校验。没有可选项，没有人工绕过。流水线是确定性的，这样 Agent 才能预测结果、对失败进行推理。

AI 代码评审：Claude

每个 PR 会触发三个并行的 AI 评审通道，使用 Claude Opus 4.6：

第 1 轮：代码质量。逻辑错误、性能问题、可维护性。

第 2 轮：安全。漏洞扫描、鉴权边界检查、注入风险。

第 3 轮：依赖扫描。供应链风险、版本冲突、许可证问题。

这些是评审门禁，不是建议。它们和人类评审并行，在高并发下捕捉人容易漏掉的东西。当你一天部署八次，没有哪个人类评审者能对每个 PR 都保持注意力。

工程师也可以在任意 GitHub issue 或 PR 中 @claude，让它给实现方案、调试会话或代码分析。Agent 能看到整个 monorepo，上下文在多次对话间延续。

自愈反馈闭环

这是整个体系的核心。

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

一小时后，triage 引擎启动。它把 CloudWatch 和 Sentry 的生产错误聚类，在九个严重度维度上给每个簇打分，并自动在 Linear 里生成调查工单。每个工单包含样本日志、受影响用户、受影响接口，以及建议的调查路径。

系统会去重。如果已有 open 的 issue 覆盖了同一错误模式，就更新那条 issue；如果之前已关闭的 issue 再次出现，它会识别出回归并重新打开。

当工程师推送修复时，同一条流水线继续处理。三个 Claude 评审通道评估 PR，CI 校验，六阶段部署流水线经过 dev 和 prod 并在每一阶段测试。部署后，triage 引擎再次检查 CloudWatch。如果原始错误被解决，Linear 工单自动关闭。

每个工具各司其职，没有哪个工具想包办一切。这个日循环构成了一个自愈闭环：错误被检测、分诊、修复、验证，几乎不需要人工介入。

我在接受 Business Insider 采访时说过：「AI 会把 PR 提出来，人只需要评审有没有风险。」

Feature Flag 和配套栈

Statsig 负责 feature flag。每个功能都在开关后面发布。发布模式是：先对团队开放，然后按百分比灰度，再全量发布或直接下线。Kill switch 能即时关闭一个功能，无需重新部署。如果一个功能拖累指标，我们在几小时内就把它撤回。坏功能当天发当天死。A/B 测试也跑在同一套系统里。

Graphite 负责 PR 分支管理：合并队列在 main 上 rebase、重跑 CI，只有全绿才合并。Stacked PR 让评审在高吞吐下依然能增量进行。

Sentry 汇报所有服务的结构化异常，triage 引擎把它与 CloudWatch 合并以获得跨工具上下文。Linear 是面向人的那一层：自动创建的工单带有严重度评分、样本日志和建议的调查方向。去重防止噪声，后续验证让已解决的 issue 自动关闭。

一个功能如何从想法走到生产

新功能路径

1. 架构师把任务定义成一个结构化 prompt，包含代码库上下文、目标和约束。
2. Agent 拆解任务、规划实现、写代码，并生成自己的测试。
3. PR 开启。三个 Claude 评审通道评估它。人类评审者关注战略风险，而不是逐行正确性。
4. CI 校验：类型检查、lint、单元测试、集成测试、端到端测试。
5. Graphite 的合并队列 rebase、重跑 CI，全绿则合并。
6. 六阶段部署流水线经过 dev 和 prod，每一阶段都做测试。
7. Feature gate 对团队开启。按百分比灰度，监控指标。
8. 一旦劣化，随时可按 kill switch；严重问题由熔断器自动回滚。

Bug 修复路径

1. CloudWatch 和 Sentry 检测到错误。
2. Claude triage 引擎打严重度分，在 Linear 创建带完整调查上下文的 issue。
3. 工程师介入调查。AI 已经完成诊断。工程师验证并推送修复。
4. 走同一套评审、CI、部署、监控流水线。
5. Triage 引擎再次核验。如解决则工单自动关闭。

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

结果

过去 14 天里，我们平均每天部署生产 3 到 8 次。在旧模式下，这整整两周里连一次生产发布都可能没有。

坏功能当天下线。新功能当天上线。A/B 测试实时验证影响。

有人以为我们是用质量换速度。实际上用户活跃度上升了，支付转化率也上升了。我们做出比以前更好的结果，因为反馈闭环更紧了。每日发布比每月发布学到的东西更多。

新的工程组织

未来将存在两种工程师。

架构师

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

这个角色需要深度批判性思考。你要质疑 AI，而不是跟随它。当 Agent 提出一个方案，架构师要找出漏洞：它漏掉了哪些失败模式？越过了哪些安全边界？在积累什么样的技术债？

我有物理学博士学位。博士阶段教给我最有用的东西，是如何质疑假设、压力测试论证、寻找缺失的部分。批判 AI 的能力，会比写代码的能力更有价值。

这也是最难招的角色。

操作员

其余所有人。工作依然重要，只是结构不同。

AI 给人类派活。Triage 系统发现一个 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 从 changelog 和功能描述生成。
• 功能介绍视频：AI 生成的动态图形。
• 社交媒体每日贴文：AI 编排并自动发布。
• 健康报告和数据分析摘要：由 AI 基于 CloudWatch 和生产数据库生成。

工程、产品、市场、增长都跑在同一套 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 把它做出来的。

· · ·

喜欢的话，关注公众号或转给朋友。

更多内容在博客 searchpcc.com，或点下方「阅读原文」。

参考链接

[1] Why Your “AI-First” Strategy Is Probably Wrong — https://x.com/intuitiveml/status/2043545596699750791?s=46&t=oDjsBy-f-VCdrYC6Q655dA

[2] @intuitiveml — https://x.com/intuitiveml