夜雨聆风来源：Peter Pang (@intuitiveml[1]) 在 X 上发布的长文 Why Your "AI-First" Strategy Is Probably Wrong
先上一组数据让你感受一下：
• 99% 的生产代码由 AI 编写 • 每天 3-8 次 生产部署 • 上午 10 点上线一个功能 → 中午 A/B 测试 → 下午 3 点因为数据不好砍掉 → 下午 5 点上线改进版 • 三个月前，同样的流程需要 6 周
这些数字来自 CREAO——一家做 Agent 平台的公司，25 人团队，10 个工程师。他们的 CTO Peter Pang 最近在 X 上发了一篇万字长文，标题很挑衅：Why Your "AI-First" Strategy Is Probably Wrong（为什么你的"AI 优先"策略大概率是错的）。
他的核心论点非常简单，也非常刺耳：
大多数公司声称自己是 AI-First，其实只是 AI-Assisted。
你让工程师用 Cursor，让 PM 用 ChatGPT 写 PRD，让 QA 试试 AI 测试生成——效率提升 10%-20%，但整个工作流程没变。Sprint 还是那个 sprint，Jira 还是那个 Jira，周会还是那个周会。
你只是往旧流水线上贴了一层 AI 的皮。
Peter 做的不是贴皮。他把整条流水线拆了，用 AI 从头建了一条新的。
我花了一个小时把他的原文从头到尾读了一遍。说实话，读完之后我的情绪很复杂——既觉得"卧槽这才是对的"，又觉得"这个代价不是所有人都扛得起"。下面是我整理后的版本，加了不少我自己的判断。
一、为什么必须拆掉旧流程——三个必死的瓶颈
Peter 不是因为"AI 很酷"才决定重构的。他是看到了三个瓶颈，每一个都会在未来 12 个月内杀死他的团队。
瓶颈一：PM 比 AI 慢 100 倍
传统流程里，PM 花几周时间调研、设计、写需求文档。然后工程师花几个月实现。
但现在 Agent 两小时就能实现一个功能。当构建时间从"月"塌缩到"小时"，你那个"周"级别的规划流程就成了最大的瓶颈。
"花几个月思考一件事，然后两小时造完——这件事不 make sense。"
PM 必须进化成能跟上迭代速度的"产品架构师"，否则就得让出构建循环。
瓶颈二：QA 比 AI 慢 10 倍
同样的逻辑：Agent 两小时写完功能，QA 花三天测边界条件。你在上游消灭了一个瓶颈，结果在下游 10 米远的地方造了一个新的。
Peter 的解法：用 AI 构建的测试平台来测 AI 写的代码。验证速度必须和实现速度匹配，否则你的流水线永远在 QA 那里堵车。
瓶颈三：人数比竞争对手少 100 倍
CREAO 25 个人，竞品 2500 人。靠招人追不上，必须靠系统追。
"三个系统必须全部由 AI 驱动：产品设计、产品实现、产品测试。任何一个环节还是纯人工，就会卡住整条流水线。"
这三个瓶颈的共同规律是——当 AI 把某一个环节的速度提升了 100 倍，所有还停留在人工速度的环节都会变成新瓶颈。你不能只快一段，你必须全链路都快。
这就是 Peter 所说的 AI-First 和 AI-Assisted 的本质区别：前者是重新设计整条流水线，后者只是在流水线上加了一个快一点的工位。
二、他到底重建了什么——技术栈与自愈闭环
Peter 花了一周设计新系统，又花了一周用 Agent 重构整个代码库。以下是他重建后的完整技术栈。
第一步：统一为 Monorepo
旧架构散布在多个独立仓库里。改一个功能可能要碰三四个 repo。人类工程师觉得这"还行"，但对 Agent 来说，它看不到全貌——它无法推理跨服务的影响，也无法在本地跑集成测试。
"你的系统里有多少部分能被 Agent 看到、检查、修改，就决定了你能获得多大的杠杆。碎片化的代码库对 Agent 是隐形的。统一的代码库才是可读的。"
这是一个 harness engineering（护栏工程） 的核心原则：Agent 的能力上限不取决于模型有多强，取决于你给它暴露了多少可操作的系统表面积。
六阶段部署流水线
每一次代码变更都要过六道关：
验证 CI → 构建部署 Dev → 测试 Dev → 部署 Prod → 测试 Prod → 发布没有一个阶段可以跳过。没有人工覆盖。流水线是确定性的，所以 Agent 可以预测结果、可以对失败进行归因推理。
三路 AI 代码审查
每个 PR 触发三条并行的 Claude Opus 4.6 审查：
1. 代码质量——逻辑错误、性能问题、可维护性 2. 安全——漏洞扫描、认证边界检查、注入风险 3. 依赖——供应链风险、版本冲突、许可证问题
注意：这不是"建议"，是门禁（gates）。当你一天部署 8 次的时候，没有人类 reviewer 能在每个 PR 上都保持注意力。AI 审查是规模化质量控制的唯一出路。
自愈反馈闭环——整个系统的灵魂
这是我觉得最精彩的部分——
每天早上 9 点，一个自动化健康工作流启动。Claude Sonnet 4.6 查询 CloudWatch 日志，分析所有服务的错误模式，生成一份执行摘要，发到团队的 Teams 群里。没有人请求这件事，系统自己做的。
一小时后，分诊引擎启动。它把 CloudWatch 和 Sentry 的生产错误聚类，在 9 个维度上评估严重性，然后自动在 Linear 里创建调查工单——每个工单附带样本日志、受影响用户、受影响接口、以及建议的排查路径。
重复的问题？自动去重。之前关闭的 issue 又复发了？检测到回归并自动重开。
当工程师推了修复代码，同一条流水线处理它：三路审查 → CI 验证 → 六阶段部署 → 部署后分诊引擎再次检查。如果原始错误消失了，Linear 工单自动关闭。
一个完整的检测 → 分诊 → 修复 → 验证 → 关闭的自愈循环。人类只在"验证修复方向"这一步介入。
我跟你讲，读到这一段的时候我停下来想了很久。这不是"用 AI 帮忙写代码"的故事。这是"用 AI 构建了一个有自主诊断和自主修复能力的有机体"的故事。
三、新的工程组织：只有两种人
Peter 认为未来的工程团队只需要两种角色：
架构师（Architect）
一到两个人。他们设计 SOP（标准操作规程）来教 AI 怎么工作。他们构建测试基础设施、集成系统、分诊系统。他们定义架构边界。他们定义"什么叫好"。
"这个角色需要极深的批判性思维。你要质疑 AI，不是跟随它。当 Agent 提出一个方案，架构师要找到漏洞：它遗漏了什么失败模式？它越过了什么安全边界？它在积累什么技术债？"
Peter 自己有物理学 PhD。他说博士训练给他最有用的东西不是物理知识，是怎么质疑假设、压力测试论证、发现缺失。
"批判 AI 的能力，将比写代码的能力更值钱。"
操作者（Operator）
其他所有人。工作依然重要，但结构变了。
AI 给人类分配任务。 分诊系统发现 bug、创建工单、给出诊断、分配给合适的人。人调查、验证、审批修复。AI 提交 PR。人 review 风险。
任务包括 bug 调查、UI 打磨、CSS 修复、PR 审查、验证。这些需要技能和注意力，但不需要过去那种从零开始的架构推理。
一个我没预想到的发现
Peter 注意到一个反直觉的现象：初级工程师比高级工程师适应得更快。
"初级工程师没有太多传统实践的包袱，他们觉得被赋能了——AI 工具放大了他们的影响力。
高级工程师最难适应。他们花了两个月做的事，AI 一小时就完成了。当你花了多年时间构建一套稀缺技能集，然后发现它在新范式里不再稀缺——这很难接受。"
Peter 特别强调他不是在做价值判断，只是在描述他观察到的现象：在这场转型中，适应性比积累的技能更重要。
四、人的那一面——CTO 从"管理者"变成"建造者"
这一段是整篇文章里最让我触动的部分。Peter 没有把这件事包装成"一切顺利的成功故事"，他非常坦诚地讲了代价。
管理时间从 60% 降到 10%
两个月前，Peter 60% 的时间花在管人上——对齐优先级、开会、给反馈、指导工程师。
现在：低于 10%。
"传统 CTO 的模式是赋能团队去做架构工作，训练他们，授权他们。但如果系统只需要一到两个架构师，我就得自己先上。我从管理回到了建造。我现在每天从早上 9 点写到凌晨 3 点。"
关系反而更好了
这个我真没想到——Peter 说重构之后，他和联合创始人、和工程师的关系变好了。
"之前我和团队的大部分互动都是对齐会议——讨论取舍、辩论优先级、争论技术决策。这些对话在传统模式里是必要的，但也很消耗人。
现在我还是跟团队聊天，但我们聊别的事。闲聊、团建、非工作话题。关系更好了，因为我们不再为那些'系统完全可以搞定的事'争吵了。"
但焦虑是真实的
Peter 没有回避这一点：
"当我不再每天和每个人说话，有些团队成员会感到不安。'CTO 不跟我说话了是什么意思？我在这个新世界里的价值是什么？'这些是合理的担忧。"
他的原则是：我们不会因为一个工程师引入了生产 bug 就开掉他——我们改进审查流程、加强测试、加装护栏。对 AI 也一样。如果 AI 犯了错，我们构建更好的验证、更清晰的约束、更强的可观测性。
五、超越工程——全公司 AI-Native
Peter 看到很多公司只在工程团队推 AI-First，其他部门还是手动的。这等于在流水线上只快了一段。
"如果工程团队几小时就能上线功能，但市场部要一周才能发公告，市场部就是瓶颈。如果产品团队还在跑月度规划，规划就是瓶颈。"
在 CREAO，他们把 AI-Native 推到了每个部门：
• 产品发布说明：从 changelog 和功能描述自动生成 • 功能介绍视频：AI 生成动态图形 • 社媒内容：AI 编排并自动发布 • 健康报告和分析摘要：从 CloudWatch 和生产数据库自动生成
"工程、产品、市场、增长跑在同一条 AI-Native 工作流上。如果其中一个部门以 Agent 速度运转，另一个以人类速度运转，人类速度的那个会卡住所有东西。"
六、我的判断：哪些我认同，哪些我存疑
读完这篇文章，我有三个强烈的感受。
我高度认同的部分
1. AI-Assisted vs AI-First 的区分是精准的。 大多数团队确实只是在旧流程上贴了一层 AI 的皮。你用 Cursor 写代码但还跑两周 sprint，那你就不是 AI-First。Peter 把这个区分讲得非常清楚。
2. 全链路速度匹配的洞察极有价值。 快只快一段没有用。如果你的实现速度是小时级，但你的规划、测试、部署还是天/周级，你的流水线永远在非 AI 环节堵车。这个视角对我们自己的架构迁移非常有启发。
3. "批判 AI 的能力比写代码的能力更值钱"——这句话我要裱起来。 它跟之前 Boris Cherny 说的"我的主要工作变成了 code review"、Keith Rabois 说的"唯一剩下的价值是判断力"，完全一致。三个不同的人，从不同角度，得出了同一个结论。
我存疑的部分
1. "每天 9 点到凌晨 3 点"这个工作强度不可持续。 Peter 自己也说这"更有压力"。一个只有一两个架构师的系统，意味着这一两个人是超级单点。如果 Peter 燃尽了（burnout），CREAO 的整个工程能力就崩了。这不是一个健康的组织设计。
2. "一人公司会变得普遍"这个判断太激进了。 一个架构师加一群 Agent 确实能做很多事，但公司不只是写代码。客户关系、法务合规、资金管理、团队文化——这些东西 Agent 暂时接不住。一人公司可能在特定品类（独立开发者工具、内容产品）可行，但"普遍"？我存疑。
3. 高级工程师"最难适应"这个观察可能有幸存者偏差。 那些适应了的高级工程师可能变成了更强的架构师；那些没适应的可能已经离开了。Peter 看到的"高级工程师适应慢"也许只是那些还在适应中的人，而不是所有高级工程师。
写在最后：你在贴皮还是在重建
Peter 的这篇文章，跟之前我整理的 Boris Cherny、Amole、Keith Rabois 的访谈，讲的是同一场革命的不同切面：
• Boris Cherny 说：编程被解决了，人的价值在 review • Amole 说：让 AI 自己跑增长实验，人的价值在对齐 • Keith Rabois 说：PM 正在消亡，人的价值在判断力 • Peter Pang 说：拆掉整条流水线用 AI 重建，人的价值在批判性思维
四个人，四个角度，同一个结论——当 AI 接管了"做"的部分，人类剩下的唯一价值就是"判断做得对不对"。
Peter 的独特贡献在于：他是目前为止我见过的、用最详实的实战数据证明了这件事可行的人。不是理论，不是预测，是已经跑了两个月、有部署频率数据、有用户参与度数据、有付费转化数据的真实案例。
所以最后的问题留给你——
你现在的团队，到底是在 AI-First，还是在 AI-Assisted？
你是真的把流水线拆了重建了，还是只是在旧流程上贴了一层 Copilot 的皮？
如果答案是后者——那你可能需要认真想想，你还有多少时间。
引用链接
[1] @intuitiveml: https://x.com/intuitiveml
