💡 关于作者 Peter Pang：物理学博士，曾参与 Meta LLaMA 大模型研发，前 Apple 工程师，现为 AI Agent 平台 CREAO 联合创始人 & CTO。
最近，Peter Pang 在 X（推特）上发表的一篇长文引发了刷屏级讨论。他犀利地指出：大多数公司标榜的 "AI 优先"，本质上只是效率提升 10-20% 的 "AI 辅助"。
真正的 AI 原生组织应该长什么样？Peter 的 CREAO 团队给出了一个令人震撼的答案：10 名工程师完成百人规模的工作量，99% 的代码由 AI 编写。一个功能从上线到验证再到迭代，全程不超过一天。
不仅是工程团队，CREAO 还将 AI 原生运营推向了所有职能：工程、产品、市场营销、增长等。
TinTinLand 对原文进行了编译。这套方法论，或许值得每一个正在做 AI 的团队认真看一遍。
为什么你的「AI 优先战略」很可能是错的
我们公司 99% 的生产代码都是由 AI 编写的。上周二，我们上午 10 点发布了一个新功能，中午完成 A/B 测试，下午 3 点因为数据反馈不佳将其关停，下午 5 点又发布了改进版本。在三个月前，这样一个迭代需要六周。
我们能做到这一点，并非简单地在 IDE 里加个 Copilot。我们彻底拆解了原有的工程流程，并围绕 AI 进行了重构。我们改变了规划、构建、测试、部署，也改变了整个团队的组织架构。
CREAO 是一个 Agent（智能体）平台。我们有 25 名员工，10 名工程师。我们从 2025 年 11 月开始构建 Agent，两个月前，我对整个产品架构和工作流进行了彻底重构。
OpenAI 在 2026 年 2 月发布了一个概念，准确描述了我们正在做的事情。OpenAI 称之为治理工程（Harness Engineering）：工程团队的首要任务不再是编写代码，而是赋能 Agent 去完成有用的工作。
当出现故障时，修复方法绝不是 "再试一次"，而是：缺失了什么能力？如何让 Agent 能够清晰地理解并执行该能力？
我们独立得出了这个结论，只是当时还没给它起名字。
"AI 优先" 不等于 "使用 AI"
大多数公司只是把 AI 嵌入现有流程：工程师打开 Cursor，产品经理用 ChatGPT 起草需求，QA 用 AI 生成测试用例。工作流没变，效率提升了 10% 到 20%，但结构上毫无变化。
这叫 AI 辅助（AI-assisted）。
而 AI 优先（AI-first）意味着必须围绕「AI 是主要构建者」这一假设，重新设计流程、架构和组织。
两者的差距是数量级的。
很多团队自称 AI 优先，却还在跑同样的 Sprint 周期、用同样的 Jira 看板、走同样的 QA 审核流程。他们只是把 AI 加进了循环，并没有重新设计循环。
最典型的例子就是 "Vibe Coding"：打开 Cursor，不断输入提示词直到跑通，提交代码，循环往复。这只能产出原型。一个生产级系统必须稳定、可靠、安全。你需要一套系统在 AI 写代码时依然能保证这些特性。
你应该构建的是这套体系，而提示词是随时丢弃的。
我们为何必须改变？
去年，我观察团队工作时，发现了三个致命的瓶颈：
产品管理瓶颈
过去几十年，PM 习惯于花数周时间进行调研、设计和编写需求文档。
但 Agent 能在两小时内完成一个功能的实现。花几个月去构思一个只需两小时就能做出来的东西，这显然不合逻辑。
产品经理需要进化为具备产品思维的架构师，以迭代的速度工作。设计应该通过「快速原型→发布→测试→迭代」的闭环来完成，而不是靠委员会审阅需求文档。
QA 瓶颈
同样的逻辑。Agent 发布功能后，QA 团队要花好几天测试边缘案例。结果是：构建两小时，测试三天。
我们用 AI 构建的测试平台取代了人工 QA，专门测试 AI 编写的代码。验证速度必须与实现速度匹配。
人员规模瓶颈
竞争对手人力规模是我们的百倍，而我们只有 25 人。靠招聘追不上差距，只能靠流程重构。
产品设计、产品实现、产品测试 ------ 三个环节都需要 AI 深度介入。只要其中任一环节还依赖人工，就会拖慢整条流水线。
重大决策：统一架构
首先必须解决代码库的问题。
我们的旧架构散布在多个独立系统中。一个简单的变更可能需要触动三四个代码库。对人类工程师来说，这尚可应付；但对 AI Agent 而言，这太不透明了。Agent 无法看到全貌，无法推断跨服务的副作用，也无法在本地运行集成测试。
我必须把所有代码合并到一个单体代码仓库（monorepo）。原因只有一个：让 AI 能看到全貌。
这正是治理工程（Harness Engineering）原则的实战应用：将系统转化为 Agent 可检查、验证和修改的程度越高，获得的杠杆就越大。碎片化的代码库对 Agent 是隐形的，而统一的代码库才是可读的。
我花了一周时间设计新系统：规划阶段、实现阶段、测试阶段、集成测试阶段。然后又花了一周时间用智能体对整个代码库进行重构。
技术栈
以下是我们的技术栈及其具体分工。
基础设施：AWS
我们运行在 AWS 上，配备了容器自动扩容和熔断回滚机制。如果部署后指标下降，系统会自动回滚。
CloudWatch 是中枢神经系统。 它涵盖了所有服务的结构化日志、25 个以上的警报，以及由自动化工作流每日查询的自定义指标。每一件基础设施都会暴露结构化的、可查询的信号。如果 AI 读不懂日志，它就无法诊断问题。
CI/CD：GitHub Actions 每次代码变更都经过六阶段流水线：
验证CI → 构建并部署开发环境 → 测试开发环境 → 部署生产环境 → 测试生产环境 → 发布
每个 Pull Request 的 CI 关卡都会强制执行类型检查、Lint 检查、单元与集成测试、Docker 构建、基于 Playwright 的端到端测试以及环境一致性检查。没有可选环节，没有人工绕过的通道。流水线是确定性的，这样 Agent 才能预测结果并推断故障原因。
AI 代码审查：Claude
每个 PR 都会触发三轮并行的 AI 审查，由 Claude Opus 4.6 执行：
-
**第一轮：代码质量。**检查逻辑错误、性能瓶颈、可维护性。
-
**第二轮：安全。**漏洞扫描、身份验证边界检查、注入风险。
-
**第三轮：依赖项扫描。**供应链风险、版本冲突、许可协议问题。
以上是审查关卡，不是建议。它们与人工审查并行，捕捉人类容易忽略的问题。当你一天部署八次时，没有哪个人类审核员能对每个 PR 都保持高度专注。
工程师还可以在 GitHub Issue 或 PR 中通过 @claude 获取实现方案、调试支持或代码分析。Agent 拥有整个单体仓库（Monorepo）的视野，上下文可以在对话中延续。
自愈反馈循环（The Self-Healing Feedback Loop）
这是整个系统的核心。
每天 UTC 时间上午 9:00，自动化健康检查工作流启动。Claude Sonnet 4.6 查询 CloudWatch，分析所有服务的错误模式，并生成一份执行摘要发送至 Microsoft Teams。不需要人主动去触发它。
一小时后，分诊引擎（Triage Engine）启动。它从 CloudWatch 和 Sentry 中聚类生产环境错误，按九个维度对严重程度评分，并在 Linear 中自动生成调查工单。每张工单都包含日志样本、受影响用户、异常接口以及建议的排查路径。
系统自动去重：如果已有工单覆盖了相同的错误模式，它会更新该工单；如果已关闭的问题再次出现，它会检测到回归并重新开启。
当工程师提交修复补丁时，同样的流水线继续处理：三轮 Claude 审查、CI 验证、六阶段部署。部署完成后，分诊引擎会重新检查 CloudWatch，若原始错误已解决，Linear 工单会自动关闭。
每个工具只负责一个阶段，没有工具试图包揽一切。 这种每日循环创造了一个只需极少人工干预的自愈闭环。
💬 "AI 来提交 PR，人只需要审查是否存在风险。"
功能开关与辅助工具
-
Statsig 处理功能开关。每个功能都在开关保护下发布。发布模式为：先对团队开启，接着按比例逐渐扩量，最后全量或关停。"紧急开关" 可以瞬间关闭功能，无需重新部署。 如果某个功能导致指标下降，我们几小时内就会撤掉它。**烂功能在上线当天就会夭折。**A/B 测试也跑在这套系统上。
-
Graphite 管理 PR 分支：合并队列会自动变基（Rebase）到主分支，重新运行 CI，只有测试通过才允许合并。堆叠式 PR（Stacked PRs）实现了高吞吐量的增量评审。
-
Sentry 报告结构化异常，由分诊引擎将其与 CloudWatch 数据合并，提供跨工具的上下文。
-
Linear 是面向人类的界面：自动创建包含严重性评分、日志样本和调查建议的工单。
功能从想法到生产的全流程
新功能路径
1️⃣ 架构师定义任务，包括结构化的提示词、代码库上下文、目标和约束。
2️⃣ Agent拆解任务、规划路径、编写代码并生成配套测试。
3️⃣ PR 开启 。三轮 Claude 审查。人类审核员检查战略风险，而非逐行核对代码正确性。
4️⃣ CI 验证：类型、Lint、单元/集成/端到端测试。
5️⃣ Graphite 合并队列：自动变基、重跑 CI、通过后合并。
6️⃣ 六阶段部署：逐级推进并伴随阶段性测试。
7️⃣ 功能开关：团队试用 → 按比例灰度 → 指标监控。
8️⃣ 紧急关停/自动回滚：指标异常立即撤回；严重问题自动熔断回滚。
Bug 修复路径
-
检测：CloudWatch 和 Sentry 发现异常。
-
分诊：Claude 评分并创建 Linear 工单，附带完整调查背景。
-
修复：工程师介入。由于 AI 已经完成了诊断，工程师只需验证并提交修复代码。
-
验证与发布：走同样的审查、CI、部署和监控流程。
-
闭环：分诊引擎重新验证，若修复成功，工单自动关闭。
两条路径共用同一套流水线。一个系统，一个标准。
变革的成果
在 14 天的时间里，我们平均每天进行 3 到 8 次生产部署。而在旧模式下，整整两周可能连一次发布都没有。
有问题的功能在上线当天就会被撤回，新功能在构思当天就能上线。A/B 测试实时验证效果。
人们总以为我们在 "用质量换速度"，但事实是用户参与度和支付转化率都提高了。因为反馈循环更紧密了：每天发布比每月发布学到更多。
新的工程组织形态
未来只有两类工程师：
架构师
一到两人。他们负责设计 SOP（标准作业程序）来教会 AI 如何工作；构建测试基础设施、集成系统和分诊系统。他们决定架构边界，并定义什么是 Agent 眼中的 "好标准"。
这个角色需要深度批判性思维。你的工作是质疑AI，而不是跟随它。当智能体提出一个方案时，架构师要找出漏洞：它漏掉了哪些失效模式？越过了哪些安全边界？积累了多少技术债？
**批判 AI 的能力，将比生产代码的能力更有价值。**这也是最难填补的岗位。
操作员
其余所有人都是操作员。工作依然重要，但结构变了。
AI 向人类分配任务。分诊系统发现 Bug，创建工单，给出诊断，并指派给合适的人。人类负责调查、验证并批准修复方案。AI 提交 PR，人类审核风险。
任务涵盖 Bug 排查、UI 抛光、CSS 优化、PR 评审和验证。这需要专注和技能，但不再需要旧模式下的那种架构推理能力。
谁适应得最快？
我发现了一个意外的规律：初级工程师比资深工程师适应得更快。
初级工程师没有需要打破的 "十年旧习惯"，AI 工具反而放大了他们的影响力。
**经验丰富的高级工程师适应最困难。**原本需要两个月的工作量，AI 一小时就干完了。在积累了多年稀缺技能之后，这是一件很难接受的事。
这不是评判，而是事实：在这次转型中，适应力比积累的技能更重要。
人性的那一面
-
管理成本骤降：
两个月前，我 60% 的时间花在管理上（开会、对齐、教练），现在管理时间花费不到 10%。我从管理者转回了建造者，每天写代码到凌晨 3 点。虽然压力大，但我更享受构建，而不是 "对齐"。
-
关系改善：
我和合伙人、工程师的关系变好了。以前，我和团队的大部分互动都是对齐会议：讨论权衡、争论优先级、在技术决策上产生分歧，非常消耗精力。现在系统解决了这些问题，我们有更多时间聊非工作的话题。
-
真实的不确定性：
转型期的焦虑是真实的。当 CTO 不再每天找人谈话，成员会担心自己的价值。我没有完美的标准答案，但我坚持一个原则：我们不因 Bug 解雇员工，而是去改进审查流程、强化测试、增加防护机制。对 AI 也是一样。
超越工程界限
很多公司采用了 AI 优先的工程模式，其他一切却保持人工运作。
如果工程部几小时就能出功能，而市场部要花一周才发公告，那市场部就是瓶颈。如果产品团队还在跑月度规划周期，那规划就是瓶颈。
在 CREAO，我们将 AI 原生运营推向了所有职能：
-
产品发布说明：由 AI 根据变更日志和功能描述自动生成；
-
功能介绍视频：由 AI 生成动态视觉效果；
-
社交媒体每日推文：AI 编排并自动发布；
-
健康报告和分析摘要：由 AI 自动分析日志和数据库生成摘要。
工程、产品、市场营销、增长 ------ 都运行在同一个 AI 原生工作流中。如果一个职能以 Agent 速度运行，另一个保持人工速度，那么后者就会拖慢一切。
判断及建议
对工程师
你的价值正在从代码产出转向决策质量。快速写代码的能力每个月都在贬值，评估、批判和指导 AI 的能力则在升值。
产品感知和品味很重要：你能在用户反馈之前就看出生成的 UI 有问题吗？你能看一眼架构提案就找出 Agent 遗漏的故障点吗？
学会评估论点、找出漏洞、质疑假设。
对 CTO 和创始人的建议
-
如果你的产品管理流程比构建时间还长，先改 PM。
-
先构建测试框架，再扩大智能体规模。
-
从架构开始，一个人先把系统建起来并跑通。系统稳定后，再让其他人以运营者角色加入。
-
把 AI 原生模式推进每一个职能。改革将会有阻力，部分员工会抵触。
对整个行业的判断
OpenAI、Anthropic 以及多个团队都指向了相同的原则：结构化上下文、专业化智能体、持久记忆、执行循环。治理工程（Harness Engineering）正在成为标准。
这一切的驱动力是大模型能力的进步。CREAO 的整体转变，我都归因于过去两个月 Opus 4.6 的进步。下一代模型会进一步加速。
我相信单人公司（OPC）将会变得普遍。如果一个架构师加上智能体能完成 100 个人的工作，很多公司将不再需要第二名员工。
结语：我们仍然在早期
我接触的大多数创始人和工程师仍在沿用传统方式。一些人在考虑是否要做出转变，真正付诸行动的极少。
工具是现成的，我们没有什么秘密武器。竞争优势在于重构一切的决心，以及愿意承担转型的代价。
阵痛是真实的：员工的不安、CTO 每天工作 18 小时、高级工程师对自身价值的质疑、新旧系统交替那两周的茫然。我们承受了这些代价。两个月后，数字说明了一切。
我们构建 Agent 平台，并且我们用 Agent 构建了它。