开头：一天完成过去六周的产品循环

上周二上午 10 点，CREAO 上线了一个新功能。

中午，他们完成了 A/B 测试。

下午 3 点，数据证明这个功能不行，于是他们把它杀掉。

下午 5 点，一个更好的版本重新上线。

三个月前，这样一轮“上线—测试—否决—重做—再上线”的循环，可能要六周。

现在，只要一天。

这家公司最夸张的地方不是“用了 AI”，而是：99% 的生产代码由 AI 编写。

但作者 Peter Pang 说，他们走到这一步，并不是因为在 IDE 里装了 Copilot，也不是因为工程师更会写 prompt。

他们做的是另一件事：

拆掉原来的工程流程，然后围绕 AI 重新搭建一套新流程。

这也是这篇文章最值得讨论的地方：

AI-first 不是使用 AI。AI-first 是围绕 AI 重建组织。

一、AI-assisted 和 AI-first 是两回事

很多公司说自己 AI-first，其实只是 AI-assisted。

典型场景是：

• • 工程师打开 Cursor 写代码；
• • 产品经理用 ChatGPT 起草需求；
• • QA 用 AI 生成测试用例；
• • 团队依然跑同样的 Sprint；
• • Jira 看板、周会、评审、QA 签核，一个都没变。

这当然会提升效率，也许是 10% 到 20%。

但流程没有变，组织结构没有变，权责分配没有变，反馈循环没有变。

这不是 AI-first，只是给旧机器加了一个 AI 插件。

真正的 AI-first，要换一个问题。

旧问题是：

AI 如何帮助我们的工程师？

新问题是：

如果 AI 是主要建设者，我们要怎样重构流程、架构和组织，让 AI 负责构建，人类负责方向和判断？

这两个问题的差别不是线性的，而是乘数级的。

二、不要迷信 vibe coding，生产系统需要 harness

作者特别批评了一类常见做法：vibe coding。

所谓 vibe coding，就是打开 Cursor，不断 prompt，直到某个东西跑起来，然后提交，再重复。

这种方式适合做原型。

但生产系统不是原型。

生产系统需要稳定、可靠、安全、可回滚、可观测、可验证。

当 AI 写代码时，真正重要的不是某一次 prompt 写得多漂亮，而是系统能不能保证：

• • AI 看到足够完整的上下文；
• • AI 写出的代码必须经过测试；
• • AI 不能绕过质量门禁；
• • 出问题后系统能定位问题；
• • 修复后系统能验证问题是否消失；
• • 风险可以被人类审查和阻断。

这就是原文提到的 harness engineering。

我理解的 harness，不是一个单独工具，而是一整套“让智能体可用、可靠、可控”的工程夹具。

它包括：

• • 结构化上下文；
• • 标准操作流程；
• • 可执行测试；
• • CI/CD 门禁；
• • 结构化日志；
• • 自动化监控；
• • 自动分诊；
• • 自动回滚；
• • 人类风险审查。

一句话：

Prompt 是一次性的，harness 才是组织资产。

三、为什么原来的流程会变成瓶颈

作者说，他们去年观察团队工作方式时，看到了三个会杀死团队速度的瓶颈。

1. 产品经理瓶颈

过去，产品经理花几周时间做研究、设计、写需求，这是正常的。

但如果 Agent 两小时就能实现一个功能，那么几周的规划周期反而变成约束。

当构建时间从“几个月”坍缩到“几小时”，产品管理就不能再靠长文档和委员会评审驱动。

产品经理要么进化为“有产品感的架构师”，能跟上快速迭代速度；要么就会被挤出构建循环。

未来的产品设计更像：

快速原型 → 发布 → 测试 → 迭代。

而不是：

调研 → 写文档 → 开会评审 → 排期 → 等开发。

2. QA 瓶颈

同样的问题也发生在 QA。

Agent 两小时写完功能，QA 花三天测边界情况。

这不是质量保障，而是把瓶颈从开发挪到了测试。

所以 CREAO 用 AI 构建测试平台，去测试 AI 写的代码。

这里的关键不是“不要 QA”，而是：

验证速度必须跟上实现速度。

否则，快速 AI 只会制造快速堆积的技术债。

3. 人数瓶颈

CREAO 只有 25 个人，其中 10 个工程师。

竞争对手可能有 100 倍的人。

他们不可能靠招聘追平对手，只能靠重新设计系统。

这也是 AI-first 的根本逻辑：

不是把现有团队变得稍微高效一点，而是让小团队获得大团队级别的产能。

四、第一步不是买工具，而是重构架构

作者做的第一个大胆决定，是统一代码架构。

他们过去的系统分散在多个独立仓库里。一个功能变更，可能要改三四个 repository。

人类工程师还能勉强管理这种复杂度，但 Agent 不行。

因为 Agent 看不到全局，无法理解跨服务影响，也无法在本地跑完整集成测试。

所以作者把代码统一进 monorepo。

原因很简单：

AI 必须看见整个系统，才能理解整个系统。

这是 harness engineering 的基本原则：

你把越多系统转化成 Agent 可检查、可验证、可修改的形态，就能获得越大杠杆。

碎片化代码库，对 Agent 是不可见的。

统一代码库，对 Agent 才是可读的。

这点很重要。

很多团队以为 AI 编程的瓶颈是模型不够强，其实瓶颈可能是自己的系统对 AI 不友好。

五、他们搭了一条 AI-native 工程流水线

CREAO 的技术栈并不神秘，关键是它们被组织成了一条完整流水线。

基础设施：AWS

他们运行在 AWS 上，有自动扩缩容容器服务，也有 circuit-breaker rollback。

如果部署后指标变差，系统会自动回滚。

CloudWatch 是中枢神经系统：结构化日志、告警、自定义指标，都能被自动工作流查询。

关键原则是：

如果 AI 读不懂日志，它就无法诊断问题。

所以可观测性不是给人看的 dashboard，而是给 Agent 读取和推理的信号系统。

CI/CD：GitHub Actions

每次代码变更都经过六阶段管线：

Verify CI → Build and Deploy Dev → Test Dev → Deploy Prod → Test Prod → Release

每个 PR 必须经过类型检查、lint、单元测试、集成测试、Docker 构建、Playwright 端到端测试、环境一致性检查。

没有可选阶段。

没有手动绕过。

管线越确定，Agent 越能预测结果、理解失败。

AI 代码审查：Claude

每个 PR 会触发三轮 Claude Opus 审查：

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

这些不是建议，而是门禁。

人类审查仍然存在，但重点变了：

人类不是逐行看代码，而是判断战略风险。

当一天部署八次时，没有任何人类 reviewer 能持续盯住每个 PR 的细节。

AI 负责规模化审查，人类负责风险判断。

六、自愈反馈循环：真正的核心

这篇文章里最值得借鉴的部分，是他们的自愈反馈循环。

每天 UTC 上午 9 点，自动健康检查工作流运行。

Claude Sonnet 查询 CloudWatch，分析所有服务的错误模式，并生成一份高层健康摘要，通过 Microsoft Teams 发给团队。

一小时后，分诊引擎开始运行。

它从 CloudWatch 和 Sentry 聚类生产错误，按九个严重性维度评分，并在 Linear 自动生成调查工单。

每个工单包含：

• • 示例日志；
• • 受影响用户；
• • 受影响接口；
• • 建议调查路径。

系统还会去重。

如果已有 issue 覆盖同类问题，就更新旧 issue。

如果已关闭的问题复发，就识别为 regression 并重新打开。

工程师推送修复后，同一条流水线继续处理：Claude 审查、CI 验证、六阶段部署、生产环境测试。

部署后，分诊引擎重新检查 CloudWatch。

如果原始错误消失，Linear 工单自动关闭。

这才是 AI-first 工程的闭环：

发现问题 → 分诊问题 → 生成上下文 → 修复问题 → 验证修复 → 自动关闭。

每个工具只处理一个阶段，没有任何工具试图包办一切。

系统靠连接形成智能，而不是靠某一个超级工具。

七、功能从想法到生产，路径也变了

在 CREAO，一个新功能大致这样流动：

1. 1. 架构师把任务写成结构化 prompt，包含代码库上下文、目标和约束；
2. 2. Agent 拆解任务、规划实现、写代码、生成测试；
3. 3. PR 自动创建；
4. 4. 三轮 Claude 审查；
5. 5. 人类 reviewer 检查战略风险；
6. 6. CI 验证类型、lint、单测、集成测试、端到端测试；
7. 7. Graphite merge queue 重新跑 CI，全绿才合并；
8. 8. 六阶段部署管线推进到开发和生产；
9. 9. 功能开关先对内部团队开启，再逐步放量；
10. 10. 指标变差就 kill switch，严重问题自动回滚。

Bug 修复也是同一条管线。

CloudWatch 和 Sentry 发现错误，Claude 分诊引擎创建 Linear issue，人类验证诊断并批准修复，AI 创建 PR，系统重新验证，问题解决后自动关闭。

新功能和 bug fix 使用同一个标准。

一个系统，一套规则。

八、结果：不是用质量换速度

14 天内，他们平均每天进行 3 到 8 次生产部署。

按照旧模式，整整两周可能一次生产发布都没有。

坏功能当天上线，当天被杀。

好功能当天想到，当天上线。

A/B 测试实时验证影响。

很多人会以为这是用质量换速度。

但作者说，用户参与度上升了，支付转化率也上升了。

原因是反馈循环变短了。

每月发布一次，你每月学习一次。

每天发布，你每天学习。

九、工程组织会分成两类人

作者认为，未来工程组织里会出现两类工程师。

第一类：Architect

一到两个人。

他们设计标准操作流程，教 AI 如何工作。

他们构建测试基础设施、集成系统、分诊系统。

他们决定架构和系统边界。

他们定义什么叫“好”。

这个角色最重要的能力不是写代码，而是批判 AI。

当 Agent 提出方案时，Architect 要问：

• • 它遗漏了什么失败模式？
• • 它跨越了什么安全边界？
• • 它积累了什么技术债？
• • 它给出的方案是否真的符合产品目标？

作者说，他的物理学博士训练最有用的部分，不是某个专业知识，而是质疑假设、压力测试论证、寻找缺失部分。

这也是未来工程师越来越重要的能力。

第二类：Operator

其他人大多会成为 operator。

这不是说工作不重要，而是结构变了。

AI 分配任务，人类调查、验证、批准。

AI 创建 PR，人类判断有没有风险。

Operator 做 bug 调查、UI 优化、CSS 改进、PR 审查、验证。

这些工作仍然需要技能和注意力，但不再要求传统模式下那么多架构推理。

作者还观察到一个有意思的现象：初级工程师比高级工程师适应更快。

因为初级工程师没有那么多传统习惯要忘掉。

而高级工程师最痛苦：他们多年积累的稀缺技能，可能被 AI 在一小时内完成。

这不是价值判断，而是转型期的真实摩擦。

十、人的问题不会自动消失

AI-first 不只是技术变化，也会改变人的关系。

作者说，两个月前，他 60% 的时间在管理人：对齐优先级、开会、反馈、辅导工程师。

现在不到 10%。

他从管理者重新变成构建者，每天大多从早上 9 点写到凌晨 3 点，设计 SOP、架构和 harness。

压力更大，但他更享受构建，而不是对齐。

团队关系也发生变化。

过去大量互动是讨论取舍、争论优先级、争论技术决策。

现在这些争论少了，大家反而能聊更多非工作话题，关系变好。

但不确定性也真实存在。

当 CTO 不再每天和人说话，有人会焦虑：

CTO 不找我了，意味着什么？ 在这个新世界里，我的价值是什么？

作者没有假装所有人都开心。

他说转型期会制造焦虑，他没有干净利落的答案。

但他有一个原则：

不会因为工程师引入生产 bug 就开除工程师，而是改进 review、加强测试、增加护栏。AI 也一样。

如果 AI 犯错，不是骂 AI，而是构建更好的验证、更清晰的约束、更强的可观测性。

十一、AI-first 不能只停在工程部门

很多公司只做 AI-first engineering，其他部门仍然手工。

这会制造新瓶颈。

如果工程团队几小时发布功能，而市场团队一周后才写公告，那么市场就是瓶颈。

如果产品团队仍然按月规划，那么规划就是瓶颈。

CREAO 把 AI-native 推进到所有职能：

• • 产品发布说明：AI 根据 changelog 和功能描述生成；
• • 功能介绍视频：AI 生成动态图形；
• • 社交媒体每日发帖：AI 编排并自动发布；
• • 健康报告和分析摘要：AI 根据 CloudWatch 和生产数据库生成。

工程、产品、市场、增长，运行在同一个 AI-native 工作流里。

一个部门进入 Agent 速度，另一个部门停在人类速度，后者就会约束整个公司。

十二、这对工程师、CTO 和行业意味着什么

对工程师来说，价值正在从代码产出转向决策质量。

快速写代码的能力每个月都在贬值。

评估、批判和指挥 AI 的能力越来越值钱。

产品感和品味也越来越重要。

你能不能在用户反馈前，看出一个 AI 生成的 UI 是错的？

你能不能在 Agent 的架构方案里，看出它漏掉的失败模式？

对 CTO 和创始人来说，如果 PM 流程比构建时间更长，就先改 PM 流程。

在扩大 Agent 使用前，先建设测试 harness。

没有快速验证的快速 AI，只是快速移动的技术债。

从一个 Architect 开始，让一个人先把系统建起来并证明有效，再把其他人纳入 operator 角色。

对行业来说，OpenAI、Anthropic 和很多独立团队都在收敛到类似原则：结构化上下文、专用 Agent、持久记忆、执行循环。

Harness engineering 正在成为标准。

作者甚至认为，一人公司会变得普遍。

如果一个 Architect 加一组 Agent 可以完成 100 个人的工作，很多公司就不需要第二名员工。

结尾：真正的优势不是工具，而是重构意愿

作者说，现在大多数创始人和工程师仍然按传统方式运转。

有些人在考虑转型，但真正完成的人很少。

工具已经存在，而且并不专有。

真正的竞争优势不是工具本身，而是：

你是否愿意围绕这些工具重构一切，并承受转型成本。

这个成本是真实的：员工不确定，CTO 每天工作 18 小时，高级工程师质疑自己的价值，旧系统消失而新系统尚未被证明。

CREAO 承受了这个成本。

两个月后，数字开始说话。

他们做的是 Agent 平台。

他们也用 Agent 构建了这个平台。

我的理解

这篇文章最值得传播的地方，不是“99% 的代码由 AI 写”。

真正重要的是：当 AI 真的成为生产者，人类最重要的工作会变成设计系统、定义标准、判断风险，以及决定什么是好。

如果 AI 只是帮人写代码，那么提升可能是 10% 到 20%。

但如果公司把规划、实现、测试、部署、监控、分诊、修复、发布、营销全部重构成 AI-native 的闭环，那么变化就是数量级的。

这不是低成本提效，而是一次组织再造。

所以，“AI-first”这个词被很多人说得太轻了。

它不是买 Cursor，不是装 Copilot，不是让员工学 prompt。

它是把公司改造成一台能让 Agent 持续生产、持续验证、持续学习的机器。

核心观点

• • AI-first 不是把 AI 加进旧流程，而是围绕 AI 重建流程。
• • Prompt 是可丢弃的，系统才是资产。
• • 当构建时间从几个月变成几小时，产品规划就可能成为瓶颈。
• • 没有快速验证的快速 AI，只是快速移动的技术债。
• • 未来工程师的价值，不在于写出多少代码，而在于做出多好的判断。
• • 最重要的能力不是服从 AI，而是批判 AI。
• • 一个部门进入 Agent 速度，另一个部门仍是人类速度，后者就会约束整个公司。
• • AI-first 的竞争优势不是工具，而是围绕工具重构一切的决心。