夜雨聆风
上周有个朋友问我：你们团队在搞 AI 转型，到底转成什么样算到位？
我没直接回答，把 Peter Pang 在 X 上的一条长帖甩给了他。
Peter Pang，物理学博士，参与过 Meta LLaMA 大模型研发，前 Apple 工程师，现在是 AI Agent 平台 CREAO 的联合创始人兼 CTO。他在这条帖子里详细拆解了 CREAO 的工程实践：10 名工程师扛起了百人级别的产出，生产代码的 99% 由 AI 生成，一个功能从发布到验证到迭代，一天之内走完。
这条帖子之所以值得认真读，是因为 Peter 没有停留在概念层面，而是把技术选型、流水线设计、组织架构调整一层层拆开讲了。读完你会意识到，多数公司理解的"AI 优先"和 Peter 团队实际在做的事情，差距远比想象中大。
我们之前写过一系列关于 AI 组织转型的文章。在《AI 组织落地的续章：从"换水车轮"到"重建工厂"》里，我们讨论了组织需要从"给旧流程加 AI"跨越到"围绕 AI 重建流程"。Peter 分享的这个案例，是我们目前看到的最完整的一线实践——他用一个 25 人团队的真实数据，把我们讨论过的那些原则全部验证了一遍。
以下内容基于 Peter Pang 的 X 原帖整理，我们用自己的理解做了重新梳理和表达。文末附编者按。
来源：Peter Pang 发布于 X
原帖链接：https://x.com/intuitiveml/status/2043545596699750791
你以为的"AI 优先"，可能只是效率微调
Peter 开篇就亮了一组数据：CREAO 99% 的生产代码由 AI 完成。某个周二上午 10 点上线新功能，中午跑完 A/B 测试，下午 3 点因为数据不理想直接下线，5 点改进版重新上线。三个月前，同样的迭代周期是六周。
这个速度的背后，不是简单地给 IDE 装个 AI 插件。Peter 的团队把整条工程链路拆掉重建了——从需求规划到代码编写，从测试验证到部署上线，包括团队的组织方式，全部围绕"AI 作为主要生产力"这个前提重新设计。
CREAO 做的是 Agent 平台，团队 25 人，其中 10 名工程师。从 2025 年 11 月开始做 Agent，两个月前 Peter 主导了一次彻底的架构和流程重构。
他提到 OpenAI 在 2026 年 2 月提出的一个概念——治理工程（Harness Engineering），恰好描述了他们在做的事：工程团队的首要职责从写代码转变为让 Agent 能高效地完成工作。出了问题，思路不是"重试一次"，而是"Agent 缺了什么能力？怎么补上？"
Peter 说他们独立走到了这个结论，只是当时还没给它命名。
AI 辅助和 AI 优先之间隔着一个数量级
Peter 对这两个概念做了清晰的区分。
多数公司的做法是把 AI 塞进现有流程：开发用 Cursor 写代码，PM 用 ChatGPT 写需求，QA 用 AI 跑测试用例。流程本身没动，产出提升了一两成，结构上什么都没变。这是 AI 辅助。
AI 优先则要求你接受一个前提——AI 是主要的构建者——然后围绕这个前提重新设计一切：流程、架构、组织。
Peter 观察到很多团队嘴上说 AI 优先，实际上还在跑老一套的 Sprint、Jira、人工 QA。AI 被加进了循环，但循环本身没有被重新设计。
他特别点名了"Vibe Coding"现象：打开 Cursor，反复调提示词直到代码能跑，然后提交。这种方式只能出原型。生产级系统要求稳定、可靠、安全，你需要一套体系来保障 AI 产出的代码达到这些标准。体系才是核心资产，提示词随时可以丢掉。
三个卡住整条流水线的瓶颈
Peter 回顾了转型前团队面临的三个结构性问题。
产品管理跟不上构建速度。 PM 按传统节奏工作——调研几周，写需求文档几周。但 Agent 两小时就能把功能做出来。花几个月去规划一个两小时就能实现的东西，投入产出完全失衡。PM 需要转型为能跟上迭代节奏的产品架构师，通过"快速原型→发布→测试→迭代"的闭环来做设计决策。
QA 成了最慢的环节。 Agent 两小时写完代码，QA 团队要花三天测边界情况。构建和验证之间的速度差太大了。CREAO 的解决方案是用 AI 搭建专门的测试平台来验证 AI 写的代码，让验证速度追上构建速度。
人力规模追不上竞争对手。 对手的团队规模是 CREAO 的百倍，25 个人靠招聘永远追不上。唯一的出路是让每个环节都由 AI 深度参与——产品设计、代码实现、质量验证，任何一个环节还卡在人工模式，整条线就快不起来。
第一步：把代码库合成一个
Peter 做的第一个重大决策是把散落在多个仓库的代码合并成一个 monorepo。
原来的架构分散在好几个独立系统里，改一个小功能可能要动三四个代码库。人类工程师还能应付，但 Agent 不行——它看不到全局，没法判断跨服务的连锁影响，也没法在本地跑集成测试。
合并的理由只有一个：让 Agent 拥有完整的视野。
这就是治理工程的核心逻辑：你把系统改造得越透明、越可检查、越可验证，Agent 能发挥的杠杆就越大。分散的代码库对 Agent 来说是黑箱，统一的代码库才是它能读懂的东西。
Peter 花了一周做系统设计，又花了一周用 Agent 完成了整个代码库的迁移重构。
技术选型和分工
Peter 详细列出了 CREAO 的技术栈。
基础设施跑在 AWS 上。 容器自动扩缩容，部署后指标异常会自动回滚。CloudWatch 承担了监控中枢的角色——结构化日志覆盖所有服务，配了 25 个以上的告警规则，自动化工作流每天查询自定义指标。核心思路是：所有基础设施都要输出 AI 能读懂的结构化信号。AI 读不懂的日志，等于不存在。
CI/CD 用 GitHub Actions，走六阶段流水线。 验证 → 构建部署开发环境 → 测试开发环境 → 部署生产 → 测试生产 → 发布。每个 PR 必须通过类型检查、Lint、单元测试、集成测试、Docker 构建、Playwright 端到端测试和环境一致性校验。没有可选项，没有人工跳过的后门。流水线必须是确定性的——Agent 需要能预判结果、定位失败原因。
代码审查交给 Claude。 每个 PR 触发三轮并行审查，跑在 Claude Opus 4.6 上。第一轮看代码质量（逻辑错误、性能问题、可维护性），第二轮看安全（漏洞、认证边界、注入风险），第三轮看依赖（供应链风险、版本冲突、许可证问题）。这三轮是硬性关卡，跟人工审查并行运行。一天部署八次的节奏下，没有哪个人类审查者能对每个 PR 都保持高度专注，AI 审查补上了这个缺口。
工程师也可以在 GitHub Issue 或 PR 里 @claude，获取实现建议、调试帮助或代码分析。Agent 能看到整个 monorepo 的上下文，对话可以跨 Issue 延续。
每天自动跑一遍的自愈循环
Peter 认为这是整套系统最核心的部分。
每天早上 UTC 9:00，一个自动化健康检查流程启动。Claude Sonnet 4.6 查询 CloudWatch 的数据，分析各服务的错误模式，生成一份摘要推送到 Microsoft Teams。不需要任何人手动触发。
一小时后，分诊引擎接力。它把 CloudWatch 和 Sentry 里的生产错误做聚类，按九个维度给严重程度打分，然后在 Linear 里自动创建调查工单。每张工单附带日志样本、受影响用户数、出问题的接口，以及建议的排查方向。
去重逻辑也是自动的：已有工单覆盖了同一类错误，就更新而不是新建；已关闭的问题再次出现，系统识别为回归并重新打开。
工程师提交修复后，走同一条流水线：三轮 AI 审查、CI 验证、六阶段部署。部署完成后分诊引擎再查一次 CloudWatch，确认原始错误消失了，工单自动关闭。
每个工具只管一个阶段，没有哪个工具试图包揽所有事情。这个每日循环构成了一个几乎不需要人工干预的自愈闭环。
功能开关和工具链
Statsig 管功能开关。所有功能都在开关保护下发布：先对内部团队开放，然后按比例灰度放量，最后全量或关停。紧急开关可以秒级关闭功能，不用重新部署。数据不好看的功能，上线当天就会被撤掉。A/B 测试也跑在这套体系上。
Graphite 管代码合并：合并队列自动 rebase 到主分支，重跑 CI，测试全过才允许合入。堆叠式 PR 让团队能高吞吐地做增量审查。
Sentry 负责结构化异常上报，分诊引擎把它和 CloudWatch 的数据合并，提供跨工具的完整上下文。
Linear 是面向人的界面：自动生成的工单里有严重程度评分、日志样本和排查建议。
一个功能从想法到上线的完整路径
新功能：
架构师定义任务，给出结构化的提示词、代码库上下文、目标和约束条件。Agent 拆解任务、规划实现路径、写代码、生成测试。PR 开出来后，三轮 AI 审查并行跑，人类审查者只看战略层面的风险，不逐行检查代码正确性。CI 验证通过后进入 Graphite 合并队列，自动 rebase 并重跑测试。然后是六阶段部署逐级推进，功能开关控制灰度，指标异常立即回撤。
Bug 修复： CloudWatch 和 Sentry 捕获异常，Claude 打分并在 Linear 创建工单，工程师验证后提交修复，走同样的审查、CI、部署流程。分诊引擎最后再验证一次，修好了就自动关单。
两条路径共用同一套流水线。一套系统，一个标准。
数据说话
转型后 14 天内，CREAO 平均每天做 3 到 8 次生产部署。之前的节奏是两周可能一次都发不出去。
有问题的功能当天撤回，新功能当天上线。A/B 测试实时出结果。
Peter 说很多人以为他们在拿质量换速度，但实际上用户参与度和付费转化率都在涨。原因很简单：反馈循环变紧了，每天发布比每月发布能学到更多东西。
两种工程师
Peter 把未来的工程角色分成了两类。
架构师，一到两个人。 他们设计 SOP 来教 Agent 怎么干活，搭建测试基础设施、集成系统和分诊系统，划定架构边界，定义 Agent 眼中"什么算好"。这个角色的核心能力是批判性思维——你的工作是质疑 Agent 的方案，找出它遗漏的失效模式、越过的安全边界、埋下的技术债。
能批判 AI 的人，比能写代码的人更稀缺。Peter 说这是最难招的岗位。
操作员，其余所有人。 工作方式变了：AI 给人派活。分诊系统发现问题，创建工单，给出诊断，分配给合适的人。人类负责调查、验证、批准修复方案。AI 提交 PR，人类审核风险。日常工作包括 Bug 排查、UI 打磨、CSS 调优、PR 审查。需要专注和技能，但不再需要从前那种架构级别的推理能力。
一个有意思的发现：初级工程师适应得比资深工程师快。没有十年旧习惯要打破，AI 工具直接放大了他们的产出。反而是经验丰富的高级工程师最难适应——过去需要两个月的活，AI 一小时就干完了。多年积累的稀缺技能突然不再稀缺，这个心理关不好过。
Peter 的总结：在这轮转型里，适应力比技能积累更管用。
转型中的人
管理时间从 60% 降到了不到 10%。 两个月前 Peter 大部分时间花在开会、对齐、辅导上，现在系统接管了这些协调工作。他从管理者变回了建造者，每天写代码到凌晨三点。累，但他说更享受造东西而不是"对齐"。
团队关系反而变好了。 以前跟合伙人和工程师的互动主要是对齐会议——讨论取舍、争优先级、在技术方案上拉锯，很消耗人。现在系统处理了大部分协调问题，大家有更多时间聊工作以外的事。
焦虑是真实存在的。 CTO 不再每天找人谈话，团队成员会担心自己是不是没用了。Peter 说他没有完美答案，但坚持一个原则：不因为出了 Bug 开除人，而是去改进流程、加强测试、增加防护。对 AI 犯的错也一样。
光改工程不够
Peter 指出一个常见的失衡：很多公司工程团队已经跑在 AI 模式上了，但其他部门还是老样子。
工程几小时出功能，市场一周才能发公告——市场就是瓶颈。产品团队还在跑月度规划——规划就是瓶颈。
CREAO 把 AI 原生的工作方式推到了所有职能。产品发布说明根据变更日志自动生成，功能介绍视频由 AI 制作，社交媒体内容由 AI 编排和发布，健康报告和数据分析摘要自动产出。
工程、产品、市场、增长——全部跑在同一套 AI 原生工作流上。只要有一个职能还在人工速度运转，它就会拖慢所有其他部门。
Peter 给出的建议
给工程师： 你的价值正在从代码产出转向判断力。写代码的速度每个月都在贬值，评估方案、发现漏洞、指导 Agent 的能力在升值。产品感知和审美也开始变得重要——你能在用户投诉之前就看出 AI 生成的 UI 哪里不对吗？
给 CTO 和创始人： 如果产品管理流程比构建时间还长，先动 PM 环节。先把测试框架搭好，再扩大 Agent 的使用范围。从架构入手，一个人先把系统跑通，稳定之后再让其他人以操作员角色加入。AI 原生模式要推进到每一个职能，会有阻力，但必须推。
给行业： OpenAI、Anthropic 和多个团队都在指向同一组原则——结构化上下文、专业化 Agent、持久记忆、执行循环。治理工程正在成为行业共识。Peter 把 CREAO 这轮转变的最大推动力归结为 Opus 4.6 近两个月的能力跃升。他判断单人公司（OPC）会越来越普遍——一个架构师加上一组 Agent 就能顶 100 个人，很多公司可能不再需要第二名员工。
写在最后
Peter 在帖子末尾说了一段话，我觉得值得原样引用：
工具是现成的，我们没有什么秘密武器。竞争优势在于重构一切的决心，以及愿意承担转型的代价。
转型的阵痛他也没回避：员工的不安、CTO 每天工作 18 小时、资深工程师对自身价值的怀疑、新旧系统交替那两周的混乱。他们扛过来了，两个月后数据给出了答案。
用他自己的话收尾：我们做 Agent 平台，而且我们用 Agent 做了它。
编者按
读完 Peter 的分享，有几个点值得单独拎出来聊。
"AI 辅助"和"AI 优先"之间的差距，比多数人意识到的要大得多。 给现有流程加个 Copilot，产出提升一两成，这是 AI 辅助。围绕"AI 是主要构建者"重新设计流程、架构和组织，这是 AI 优先。Peter 的团队做到了后者，代价是把整个代码库推倒重来，把组织架构重新定义。多数团队还停留在前者，却以为自己已经是后者了。
治理工程这个概念值得认真对待。 工程师的核心工作从"写代码"变成"让 Agent 能写好代码"。你要构建的是 Agent 的工作环境：统一的代码库让它看到全貌，确定性的 CI 流水线让它能推断故障原因，结构化的日志让它能诊断问题。你在构建的是一个让 AI 能高效工作的系统。
"初级工程师比资深工程师适应得更快"这个观察很扎心，但也很真实。 十年经验积累的手艺，AI 一小时就能复现。经验依然有用，只是价值形态变了：从"我能写出这段代码"变成"我能判断这段代码该不该写"。
最后一个问题留给你：如果你的团队明天开始按 Peter 描述的方式运作，第一个会暴露出来的瓶颈是什么？
如果你对 AI 组织转型这个话题感兴趣，可以回看我们之前的系列文章，从框架到实践路径都有覆盖。Peter 这篇，算是迄今为止最硬核的一线验证。
来源：Peter Pang 发布于 X
原帖链接：https://x.com/intuitiveml/status/2043545596699750791
