别再把“用上AI”当成 AI First:如何把 99% 代码交给 AI 来写

“99% of our production code is written by AI.”
更狠的是，他们不是拿这句话当宣传口号，而是真的把整个工程系统都围绕这个前提重构了一遍。

很多团队这两年都在喊 AI First。

但大多数时候，这个词真正对应的，不过是工程师开始用 Cursor，PM 开始用 ChatGPT 写需求，QA 试着让 AI 帮忙生成点测试用例。工具是新了，流程没变，组织没变，交付方式也没变。最后的结果通常是效率涨一点，但系统本身并没有发生结构性变化。

Peter Pang 有价值的地方就在这：他给出的不是“AI 帮工程师提效”的经验，而是一套更激进的判断——如果你真的相信 AI 会成为主要构建者，那你就不能只给现有流程外挂一个 AI，而是要把产品、工程、测试、部署、组织方式全部重做一遍。

他们的公司 CREAO 只有 25 个人，其中工程师 10 个。但现在，99% 的生产代码由 AI 编写。他们可以在上午 10 点发一个新功能，中午做完 A/B test，下午 3 点因为数据不好把它砍掉，5 点再发一个更好的版本。三个月前，这样一个循环要走 6 周。

这篇文章最值得看的，不是“AI 又帮大家快了多少”，而是它把一个很多人含糊其辞的问题讲透了：AI First 不是用 AI，而是把整个系统改造成“让 AI 能稳定做事”的系统。

一、真正的 AI First，不是给旧流程外挂一个 AI

文章一上来就先把一个常见误区捅穿了。

很多公司会说自己已经 AI First 了，但他们做的事其实是：

工程师在 IDE 里接了 Copilot 或 Cursor
PM 用 ChatGPT 辅助写 spec
QA 用 AI 帮忙补一点测试
Jira、Sprint、周会、评审、人工 QA 签字这些环节照旧

这叫 AI-assisted，不是 AI-first。

两者最核心的区别在于：

AI-assisted：默认人还是主构建者，AI 是外挂
AI-first：默认 AI 是主要构建者，人负责方向、判断和边界

Peter Pang 的表述很锋利：

真正的 AI First，不是问“AI 怎么帮助工程师”，而是问“我们要怎样重构整个系统，才能让 AI 去构建，而工程师提供方向和判断？”

这个差异看起来像一句话的区别，但在工程实践里是乘法级别的差异。

如果你还沿用原来的节奏——同样的需求规划周期、同样的多人委员会评审、同样的测试节奏、同样的人工发布流程——那 AI 带来的只是局部提速，而不是系统级跃迁。

文章里还顺手点了一下一个很典型的假 AI First：vibe coding。

打开 Cursor，反复 prompt，能跑了就 commit，再继续。这种方式适合做原型，但要上生产，你需要的是一个能保证稳定、可靠、安全的系统。真正重要的不是 prompt，而是你有没有把这些质量约束做成 AI 可读、可执行、可验证的系统能力。

借 OpenAI 今年 2 月提出的一个概念来解释这件事：harness engineering。

也就是，工程团队的首要任务，已经不再是自己下场写每一行代码，而是去搭建一套“能让 Agent 稳定完成有用工作”的约束系统。

当系统出问题时，正确的问题不是“AI 为什么不够努力”，而是：

它缺了什么能力？
这个能力怎么变成 AI 能看懂、能执行、能被强制遵守的机制？

这就是整篇文章的底层逻辑。

二、为什么很多团队即使用了 AI，也跑不出真正的提速

作者接着讲了他们去年亲眼看到的 3 个瓶颈，而且非常典型。

1）产品管理瓶颈

以前 PM 可以花几周时间研究、设计、写规格，这是传统软件组织的自然节奏。

但如果 Agent 两小时就能把一个功能做出来，那么问题就变了：真正拖慢系统的，不再是写代码，而是前面的长 planning cycle。

作者那句话很值得记：

当构建时间从几个月塌缩到几小时后，持续几周的规划周期本身就变成了约束。

所以 PM 不能再只是文档生产者，而要转成一种更像产品架构师的角色：快速提出方向、快速出原型、快速上线、快速测、快速迭代。

2）QA 瓶颈

第二个更残酷。

一个 Agent 两小时把功能做完，QA 再花三天测边角 case。那整个系统还是慢的。

他们的答案是：用 AI 搭测试平台，去测试 AI 写的代码。

也就是说，验证速度必须跟实现速度对齐。否则你只是把旧瓶颈从上游挪到了下游十米处。

3）人头瓶颈

他们公司只有 25 人，但竞争对手可能有 100 倍以上的人力做同类工作。

在这种情况下，靠招聘补齐差距根本不现实，只能靠重构系统补齐差距。

作者最后得出的结论非常清楚：如果产品设计、产品实现、产品测试这三套系统里有任何一套还保留纯手工逻辑，那么整条链路都会被它卡死。

三、他们做的第一个关键决定：先把代码架构改成 AI 看得懂的样子

很多人以为 AI First 的起点是“换个更强模型”或“买更好的 coding agent”。但这篇文章很诚实：他们先动的是代码库结构。

原来的系统分散在多个独立仓库里，一个改动可能要碰 3 到 4 个 repo。人类工程师当然还能 manage，但对 AI 来说，这是一种“不透明系统”。

问题非常直接：

Agent 看不到全貌
它无法推理跨服务影响
它没法在本地完整跑集成测试

所以作者做了一个很重的决策：把所有代码统一进一个 monorepo。

这个动作背后其实就是 harness engineering 的一个核心原则：

你越能把系统收拢成 Agent 可检查、可验证、可修改的形式，AI 给你的杠杆就越大。

一个割裂的代码库，对 Agent 来说近乎“失明”；一个统一的代码库，才是可推理的。

作者自己花了一周设计新的系统结构——规划阶段、实现阶段、测试阶段、集成测试阶段——然后再花一周，借助 Agent 把整套代码库重构掉。

他们做的是 agent platform，而他们又用自己的 Agent 去重构这个 agent platform。这件事很像一场极端的自测：如果产品连自己都构不动，那说明它还不够成熟。

四、真正拉开差距的，不是模型多强，而是整条流水线是不是为 AI 而生

这篇文章最有密度的一部分，是作者把他们整套技术栈拆出来讲清楚。你会发现，这根本不是“配几个 AI 工具”那么简单，而是从基础设施到 code review、从告警到发版，全部围绕“让 AI 稳定工作”来设计。

1）基础设施：AWS + 自动回滚

他们运行在 AWS 上，带 auto-scaling 容器服务和 circuit-breaker rollback。

意思很简单：一旦部署后指标恶化，系统会自己回滚。

CloudWatch 是整套系统的中枢神经：

全服务 structured logging
25+ 告警项
自定义指标
自动工作流每天查询

作者特别强调了一个很关键的判断：

如果 AI 看不懂日志，它就无法诊断问题。

这句话其实值得所有做 Agent 系统的人记住。不是“有日志”就够了，而是日志必须结构化、可查询、可供机器理解。

2）CI/CD：GitHub Actions 六阶段流水线

他们所有代码变更都必须经过固定的六阶段 pipeline：

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

CI gate 覆盖：

typechecking
linting
unit tests
integration tests
Docker builds
Playwright 端到端测试
environment parity checks

重点不只是环节多，而是：没有任何阶段是可选的，没有 manual override，整个 pipeline 是 deterministic 的。

这一点太重要了。因为只有流水线结果足够确定，Agent 才能预测结果、理解失败原因、对下一步做可靠推理。

3）AI 代码审查：Claude 三路并行 review

每个 PR 都会自动触发 3 路并行的 Claude Opus 4.6 审查：

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

作者特别强调：这些不是建议，而是 review gates。

它们和人工 review 并行存在，用来在高频发布环境下兜住人类注意力必然会漏掉的东西。因为当你一天部署 8 次时，没有任何人能始终保持对每个 PR 的高强度专注。

工程师还可以在 GitHub issue 或 PR 里直接 @claude，请它帮忙做实现方案、debug、代码分析。因为它看到的是整个 monorepo，上下文不会像零碎聊天那样断掉。

4）最精彩的一环：自愈式反馈闭环

这部分是整篇文章最值得研究的地方。

他们做了一套真正意义上的“自愈式工程闭环”：

每天早上 9 点，自动健康检查工作流运行
Claude Sonnet 4.6 查询 CloudWatch
分析全服务错误模式
生成 executive health summary 发到 Microsoft Teams

一小时后，另一个 triage engine 运行：

聚合 CloudWatch 和 Sentry 的错误
按 9 个严重度维度打分
自动在 Linear 里创建调查 ticket
附上样例日志、受影响用户、受影响 endpoint、建议调查路径

系统还能：

做错误去重
如果已有开放 issue 覆盖该问题，就更新原 issue
如果已关闭 issue 再次复发，能检测 regression 并重新打开

工程师修复后，后面的闭环继续自动跑：

Claude 三路 review 审 PR
CI 验证
六阶段 deploy pipeline 发布到 dev 和 prod
部署后 triage engine 再去看 CloudWatch
如果原错误已经消失，Linear ticket 自动关闭

这套系统最漂亮的地方在于：每个工具只负责自己的一段，不追求一个工具包打天下。

最后形成的是一条低人工介入的日常循环：发现问题 → 分诊 → 修复 → 验证 → 关闭。

这才是 AI First 真正该长出来的样子。

5）剩下的配套栈，也都是为“快速试错 + 快速回滚”服务的

他们用 Statsig 管 feature flag，所有功能都挂在 feature gate 后面。

标准 rollout pattern 是：

先给内部团队开
再按百分比逐步放量
最后全量发布或者直接 kill

如果某个功能拉低指标，可以不经重新部署，直接开 kill switch 当场关掉。坏功能在发布当天就可以死亡，A/B test 也走同一套系统。

他们还用了：

Graphite：做 PR branching、merge queue、stacked PR
Sentry：提供结构化异常
Linear：做人类面向的任务层，承接自动创建的调查工单

这意味着，AI 并不是在某个孤立点上“帮你写代码”，而是被嵌在整条从代码到运维的链路里。

五、在这套体系里，一个功能是怎么从想法走到生产的？

作者把整个流程拆得非常清楚，我觉得这也是最适合被其他团队拿来借鉴的一段。

新功能路径

架构师把任务定义成结构化 prompt，写清代码库上下文、目标和约束
Agent 先做任务分解、实现规划、写代码、生成测试
系统自动发起 PR，三路 Claude review 并行检查
人类 reviewer 只看战略风险，而不是逐行肉眼验代码
CI 做类型、lint、单测、集成测试、E2E 验证
Graphite merge queue rebase 到 main，再跑一轮 CI，绿了才 merge
六阶段 pipeline 推到 dev 和 prod，每个阶段都有测试
通过 feature gate 先给团队，再灰度，再全量
如有问题，kill switch 或 circuit-breaker 自动兜底

Bug 修复路径

CloudWatch 和 Sentry 发现错误
Claude triage engine 自动打分、建 Linear issue，并附好调查上下文
工程师介入时，AI 已经把诊断做完了，人主要负责验证和修复
修复之后，走同一套 review、CI、deploy、monitoring 流程
triage engine 重新验证，如果问题消失，ticket 自动关闭

作者强调：新功能和 bug 修复，走的是同一套 pipeline、同一套标准。

这其实非常关键。很多团队系统做不稳，就是因为 feature path 一套逻辑，incident path 又是另一套逻辑，最后维护成本越来越高。

六、结果为什么会这么夸张？因为他们把反馈循环压缩到了“按天”

文章里给出的结果非常直接：

在连续 14 天里，他们平均每天做 3 到 8 次生产部署
按旧模型，这整个两周的时间，甚至都不够完成一次正式上线
坏功能可以在发布当天被撤回
新功能可以在被想到的当天上线
A/B test 几乎是实时回流结果

更有意思的是，外界常以为这种速度一定是在牺牲质量换速度，但作者的反馈是：

用户参与度上升了
付费转化提升了
结果反而比过去更好

原因并不神秘：发布更频繁，意味着反馈更密、学习更快。

当你按天发版时，你得到的是高频、短回路的真实市场信号；当你按月发版时，你实际上是在拿更长的等待，换更慢的认知更新。

七、AI First 不是只改工具链，它最后会改掉整个工程组织

文章最后一部分，其实比技术栈更有冲击力，因为它讲的是组织结构会怎么变。

作者认为，未来会越来越清晰地分出两类工程角色。

1）Architect：设计 AI 如何工作的少数人

这个角色人数很少，也许只有 1 到 2 个。

他们负责：

设计 SOP
设计测试基础设施
设计集成系统
设计 triage 系统
决定架构和系统边界
定义“对 Agent 来说什么叫 good”

作者认为，这个角色真正稀缺的不是会不会写代码，而是会不会批判性地审视 AI。

当 Agent 给出方案时，Architect 要能看穿：

漏了什么 failure mode
跨了哪些不该跨的安全边界
在偷偷积累什么技术债

他甚至说，自己物理学 PhD 最有用的训练，不是某个专业知识，而是：如何质疑前提、压测论证、寻找缺失项。

这句话我觉得很重要。因为它其实在说，未来最值钱的，不是能多快地产出代码，而是能不能成为那个持续校正 AI 的人。

2）Operator：执行、验证、收口的大多数人

剩下的大多数工程师，工作仍然重要，但结构会变化。

AI 会：

发现 bug
建 ticket
给诊断
分配给合适的人
生成修复 PR

人负责的是：

调查
验证
做 UI 微调
做 CSS 改进
做 PR 风险判断
做最终确认

这不意味着人没价值了，而是意味着很多过去要求较强架构推理的工作，会被迁移到另一层；而大量工程活动会更像“高质量操作、验证和判断”。

3）最先适应的，未必是传统上最强的人

作者观察到一个很有意思的现象：初级工程师适应得比资深工程师更快。

原因不是因为他们更会写代码，而是因为：

他们更容易借助工具迅速放大产出
他们没有那么多旧习惯要卸载
他们不需要先和十年的工作方式做一轮心理和方法论上的告别

反而是那些在传统工程模型里积累很深的人，转变最痛苦。因为当你发现两个月的工作量可以被 AI 一小时做完时，这不只是效率问题，还是对职业身份的直接冲击。

作者没有做价值判断，但这个观察非常真实：在这轮转变里，适应性可能比既有技能存量更重要。

八、这篇文章真正重要的，不是“99% 代码由 AI 写”，而是它给出了一套判断标准

如果把全文压缩成一句话，我觉得最值得记住的不是那个夸张的数据，而是这个判断：

AI First 从来不是一个工具升级问题，而是一次系统重构问题。

真正决定你能不能把 AI 用到生产级别的，不是 IDE 里多了多少补全，不是 prompt 写得多花，而是你有没有把下面这些东西一起重构：

代码结构是否对 Agent 可见
测试是否足够自动化、结构化、可强制执行
日志和指标是否可被机器理解
发布是否 deterministic
回滚是否自动
triage 是否自动
feature rollout 是否可灰度、可关闭
人的角色是否从“主要构建者”转成“架构者与判断者”

如果这些没变，那你更接近的是“AI 加强版旧组织”；如果这些都变了，你才有机会接近文章里所说的那种乘法级变化。

对很多团队来说，这篇文章最大的价值，不是让你立刻复制 CREAO 的整套系统，而是逼你重新审视一个问题：

你口中的 AI First，到底是在说你用了几个 AI 工具，还是在说你真的开始为 AI 重写你的工程系统？

这两个答案，中间隔着的不是一点效率差，而是一个时代级的组织差距。

写在最后

很多人聊 AI 编程时，讨论的还是哪个模型更强、哪个 IDE 更顺、哪个 Agent patch 更稳。

这些当然重要，但如果只停在这个层面，你看到的依然只是“AI 帮人写代码”。

而 Peter Pang 真正往前推了一步：如果 AI 真的成为主要构建者，那工程团队的核心任务就不再是产出代码，而是设计一套让 AI 能稳定产出价值的系统。

这也是为什么我觉得，这篇文章值得所有技术团队负责人、平台工程团队、AI 工程师都认真看一遍。

因为它讨论的已经不是“工具替换”，而是“工程范式重写”。