本文核心观点：AI-First 真正的瓶颈不在模型有多强，而在你有没有一套能让 AI 执行任务的工程底座——测试、CI/CD、监控、任务分诊缺一不可，没准备好就别上。

核心要点：

1. 99% 代码由 AI 写，靠的不是模型，是工程系统

2. AI 时代最稀缺的是工程底座，不是模型本身

3. 团队角色正在分化：评估者（Evaluator）和操作者（Operator）

4. 初级工程师适应 AI-First 比资深更快——没有旧习惯要破

5. 转型焦虑真实存在，原则是"先补底座，分化自然发生"

6. AI-First 是放大器，底座薄放大的就是混乱，不是效率

————————

最近有句话在技术圈很火："99% 的生产代码由 AI 编写。"

说这话的是 CREAO 联合创始人 Peter Pang，他分享了一套让人印象深刻的开发节奏：早上 10 点上线新功能，中午 A/B 测试，下午 3 点数据不行直接砍掉，5 点上线改良版。

同样的功能，三个月前需要六个星期。

听起来很诱人——但问题在于，大多数团队盯着的是"怎么让 AI 多写代码"，而不是"支撑这套节奏的背后是什么"。

那套系统，才是真正值得研究的东西

Peter Pang 的团队能做到这件事，前提不是模型有多强，而是整条工程链路足够扎实。

CI/CD、自动化测试、A/B 灰度、监控告警、秒级回滚——这些东西在 AI 出现之前就应该存在。只不过 AI 时代，这些能力的价值被进一步放大了。

一个测试覆盖率不到 30% 的团队，引入 AI 写代码，结果是交付速度翻倍、bug 产出也跟着翻倍。

这不叫 AI-First，这叫用更快的速度制造更多技术债。

AI 时代最稀缺的，其实不是模型

这几个月大家都在聊 Harness（AI Agent 运行底座）。从 Codex 把工程经验沉淀到仓库，到 Anthropic 的长任务分工和 Harness 减法，再到 Managed Agents 的运行底座托管——

这些拆解下来，回答的是同一个问题：模型之外那层系统，到底还缺什么？

Peter Pang 的案例把这个问题放到一个完整的生产场景里。他的结论很直接：

> 出现问题时，解决方案从来不是"再努力一点"，而是：缺少什么能力？如何让它对 Agent 来说是可见、可验证、可执行的？

这和 OpenAI 年初提出的 Harness Engineering 是同一个方向。他的团队在那之前就已经在这么做了，只是当时还没有这个名字。

所以 AI 出错，真正要修的往往不是那一行代码——而是上下文、约束规则、可验证性这些系统层的东西。

团队结构正在重新分化

Peter Pang 描述了一个有意思的趋势：AI-First 团队里出现了两种典型角色。

评估者（Evaluator）：质疑假设、给论点做压力测试、寻找逻辑漏洞。在他的判断里，批评 AI 的能力将比写代码的能力更值钱。

操作者（Operator）：AI 给人分配任务，分诊系统发现 bug、建工单、给诊断，分配到人。人负责调查、验证、审核风险、批准修复。

工作依然需要技能和注意力，但不再需要从头搭建系统架构的推理能力。

他还观察到一个现象：初级工程师适应得比资深工程师更快。没有十年旧习惯要破除的人，反而觉得 AI 工具放大了自己的影响力。

这个观察有道理，但也有边界。如果一个资深工程师的核心价值本来就在系统设计、风险判断和技术决策上，AI 反而会让这种价值更突出。

适应快慢，可能更取决于核心价值到底在"代码产出"还是"工程判断"上。

转型期的焦虑是真实的

CTO 不再每天找大家聊工作了，有人会想"我的价值在哪"。

Peter Pang 没有完美答案。但他有一个原则：不会因为工程师引入了生产 bug 就责怪人，而是改进审查流程、加强测试、增加护栏。对 AI 也一样，犯了错就构建更好的验证、更清晰的约束、更强的可观测性。

角色变化更像是工程底座补齐之后，组织自然长出来的分工结果。

先补底座，分化会自然发生。

这套打法有明确的适用边界

不是所有场景都适合 AI-First。当验证周期长、试错成本高、数据反馈慢的领域，AI 放大的是风险，不是效率。

底座没补齐的时候强推，和在沙子上盖楼没有区别。

Peter Pang 的案例里还有一个细节：他们的技术栈全部是现成工具，没有任何自研组件。竞争优势不在工具选型，而在决定围绕这些工具重新设计一切的决心，以及愿意承担过程中那些真实成本的勇气。

员工的不确定感、CTO 每天干 18 个小时、两周内旧系统拆了而新系统还没站稳——这些不是副作用，是代价。

最后说一个顺序问题

AI-First 更像一支放大器。

测试强，它放大交付速度。发布稳，它放大试错频率。监控全，它放大学习闭环。架构清楚，它放大 Agent 的理解力和执行力。

但如果这些东西本来就薄，它同样会把混乱、返工和风险一起放大。

对大多数团队来说，今天真正该做的，可能不是再买一个 AI 工具，而是先把自动化测试、CI/CD、监控、任务管理和系统边界补到足够扎实。

先把软件工程做对。然后再谈 AI-First。这个顺序，不能反。