Peter Pang 是 CREAO 的 CTO。这家公司的数字很极端：25个人，10个工程师，99%的生产代码是AI写的。过去两周每天生产部署3-8次，而按他们旧模式，两周零次发布。

他写了一篇长文，讲这个结果是怎么来的。

AI-Assisted 和 AI-First 是两件事

大多数公司做的是AI-assisted：工程师在IDE里加个Copilot，PM用ChatGPT写文档，QA试着用AI生成测试用例。流程不变，效率提升10-20%。

AI-first是另一件事：围绕AI是主要构建者这个假设，重新设计流程、架构和组织。你不再问"AI怎么帮我们的工程师"，而是问"我们怎么重组一切让AI构建，工程师提供方向和判断"。

差距是乘数级的。

三个瓶颈

Peter Pang观察到自己团队的三个瓶颈，每一个都会杀死AI-first的转型。

产品管理瓶颈。 传统PM花几周研究、设计、出规格文档。但Agent两小时能实现一个功能。当构建时间从几个月压缩到小时级别，几周级别的规划周期就成了新的约束。"花几个月想，然后两小时构建"这件事本身变得不合理了。

QA瓶颈。 Agent两小时交付功能，QA花三天测试角落情况。构建时间压缩了，测试时间没压缩，就在下游造了一个新瓶颈。

人数瓶颈。 竞争对手人多100倍，他们没法靠招聘追上，必须靠重新设计来达到同等产出。

架构先行：让AI能看到全貌

他们先把代码库从多个独立仓库合并成单一monorepo。这对人类工程师来说不是必须的，但对Agent至关重要——Agent看不到全貌，就无法做跨服务推理和本地集成测试。

这就是harness engineering的核心：把更多系统拉入Agent可以检查、验证和修改的形式。碎片化的代码库对Agent是不透明的。统一的代码库是可读的。

自愈反馈循环

这是整篇文章最值得注意的部分，也是一个完整系统在运行的证据。

每天9:00 UTC，健康检查workflow自动运行。Claude Sonnet 4.6查询CloudWatch，分析所有服务的错误模式，生成执行摘要发到Microsoft Teams，没人需要去要。

一小时后，分诊引擎运行。它把CloudWatch和Sentry的生产错误聚类，在9个维度上评分，自动在Linear里生成调查工单，每个工单包含示例日志、受影响用户、受影响端点和建议调查路径。系统会做去重——如果已有工单覆盖同类错误，它更新那个工单；如果已关闭的工单对应的错误复发，它检测到回归并重新打开。

工程师修复后，同样的pipeline处理PR。三个Claude审查通过，CI验证，六阶段部署pipeline推进。分诊引擎重新检查CloudWatch——如果原始错误解决，Linear工单自动关闭。

整个循环：检测→分诊→修复→验证，最小人工干预。

六阶段CI/CD Pipeline

每次代码变更都经过六个阶段，每个阶段不可跳过，没有人工override：

验证CI → 构建并部署Dev → 测试Dev → 部署Prod → 测试Prod → 发布

CI gate在每个PR上强制执行类型检查、lint、单元和集成测试、Docker构建、Playwright端到端测试、环境一致性检查。Pipeline是确定性的，所以Agent可以预测结果并推理失败原因。

三轨AI代码审查

每个PR触发三次并行AI审查，使用Claude Opus 4.6：

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

这些是审查门禁，不是建议。当你每天部署8次，没有人能在每个PR上保持注意力。

新功能路径 vs Bug修复路径

新功能：

  1. 架构师定义结构化prompt，包含代码库上下文、目标和约束
  2. Agent分解任务、规划实现、写代码、自己生成测试
  3. PR打开，三轨Claude审查，人类检查战略风险而非逐行正确性
  4. CI验证 → Graphite合并队列 → 六阶段部署pipeline
  5. Feature gate先对团队开启，逐步放量，监控指标
  6. Kill switch随时可以关闭，熔断机制自动回滚

Bug修复：

  1. CloudWatch + Sentry检测错误
  2. Claude分诊引擎评分严重性，在Linear创建完整调查上下文工单
  3. 工程师调查（AI已做诊断）→ 验证 → 推送修复
  4. 同样审查、CI、部署、监控pipeline
  5. 分诊引擎重新验证，通过则工单自动关闭

两条路径用同一套系统。一个标准。

两种工程师

架构师（Architect）

1-2个人。他们设计标准操作程序（SOP）来教AI如何工作：构建测试基础设施、集成系统、分诊系统，决定架构和系统边界，定义什么对Agent来说是"好的"。

这个角色需要深度批判性思维。你批判AI，不跟随它。当Agent提出计划，架构师找漏洞：它遗漏了什么失败模式？跨越了什么安全边界？累积了什么技术债务？

"我有物理学博士学位。博士教给我最有用的东西是如何质疑假设、压力测试论证、寻找缺失的东西。批评AI的能力将比生产代码的能力更值钱。"

这也是最难招的角色。

Operator（操作者）

其余所有人。AI给人类分配任务。分诊系统找bug、创建工单、展示诊断、分配给正确的人。人调查、验证、批准修复。AI做PR，人类审查风险。

任务包括bug调查、UI优化、CSS改进、PR审查、验证。这些需要技能和注意力，但不需要旧模式要求的架构推理能力。

一个反直觉的观察

Junior工程师比Senior工程师适应更快。传统实践越少的人感觉越有赋权。Senior工程师最困难——两个月的传统工作可以由AI在一小时内完成，这是years构建稀有技能之后很难接受的事实。

CTO角色消失

两个月前，Peter Pang 60%的时间在做人员管理：对齐优先级、开会、提供反馈、指导工程师。

今天：低于10%。

传统CTO模型是赋能团队做架构工作、训练他们、授权。但系统只需要1-2个架构师时，他必须自己做。他从管理转向构建：早上9点到凌晨3点写代码，设计系统的SOP和架构，维护harness。

"压力更大。但我喜欢构建，而不是对齐。"

这不是特例，这是行业方向

OpenAI、Anthropic和多个独立团队都得出了相同结论：结构化上下文、专业化Agent、持久记忆、执行循环。Harness engineering正在成为标准。

模型能力是驱动这个转变的时钟。"我把这个转变完全归因于过去两个月。Opus 4.5做不到Opus 4.6做的事。下代模型会让它更快。"

"我相信一人公司会变得常见。如果一个架构师加Agent能做100人的工作，很多公司不需要第二个员工。"

工具对任何团队都是现成的。我们的栈里没有任何东西是专有的。竞争优势在于围绕这些工具重新设计一切的决策，以及吸收成本的意愿。