你的 AI-First 战略，大概率是错的（译）

前言

读到了一篇两天斩获150W浏览的 AI Harness实践的落地文章，很有收获，我花了两小时对原文进行翻译。

原文作者Peter Pang，CreaoAI 联合创始人（前 Meta GenAI / LLaMA 团队，xApple 背景）

原文链接：https://x.com/intuitiveml/status/2043545596699750791

现在我们生产环境的代码有 99% 是 AI写的。

举个例子：我们上周二早上 10 点上了一个新功能，中午就能跑完 A/B 测试，下午 3 点数据反馈效果不佳，可以直接砍掉。两个小时候，下午 5 点，改良版就能上线。

而在三个月前，同样的事情要经历六周才能做完，这种级别的提效并不是装个 Copilot 或者其他 Coding Agent 就能实现的。

我们把整个工程流程都重构了，以 AI 为中心重新搭了一遍。

怎么规划、怎么写代码、怎么测试、怎么部署、团队怎么分工，全都推倒重来，公司里每个人的角色和定位都发生了改变。

我们的产品叫 CREAO ，是一个 Agent 平台。团队共有 25 个人，10 个工程师。

我们从 2025 年 11 月开始做 Agent，两个月前我把整个产品架构和工程流程从底层重构了一遍。

OpenAI 2026 年 2 月提了一个概念，刚好说中了我们一直在干的事。

他们叫它 Harness Engineering：研发团队的主要工作不再是写代码，而是让 Agent 能把活干好。

出了问题，答案永远不是再花更大力气，而是完全尝试用Agent处理：Agent 还缺什么能力？怎么让 Agent 看得懂、能执行？

其实我们自己得到了和Harness Engineering同样的结论，只是当时没给它起名字。

AI-First 跟 AI-assisted 完全是两码事

大部分公司使用 AI 的方式就是把 AI 往现有流程上兼容。

工程师开个 Cursor 写代码
PM 拿 ChatGPT 写需求文档
QA 试着让 AI 生成测试用例

这套动作下来，效率只能提升 10% 到 20%，但工作流程纹丝没动，没有任何的结构性改变。

这叫 AI-assisted（AI 助手）。

而 AI-first 完全不一样，AI-first 也叫做 AI-native，本质上是个自上而下的事情，需要你重新设计流程、架构和组织，前提就一个：AI 是主力施工方。

不再思考

AI 怎么帮工程师干活
怎么提升人工效率

而是思考

怎么重构一切，需要重构哪些模块
让 AI 来干活，工程师负责拍板和兜底

二者之间的提效差距是数量级的。

我见过不少团队自称 AI-first，但他们依旧使用老的那一套工作流：Sprint 照旧、Jira 照旧、周会照旧、QA 签字照旧。AI 只是被加进了流水线，但流水线本身一点没变。

还有一种常见提效方法，叫做 vibe coding。通常是开 Cursor，工程师通过调整 prompt 生成一个可用的代码，commit到远程，然后继续下一个需求代码的生成。

这玩意虽然确实能提升效率、解决小需求，但生产环境的系统要的是稳定、可靠、安全。

你得搭一套系统来保证 AI 写出来的代码具备上述属性。可以理解成：Harness 系统是搭建之后可以稳定运行的，而 Prompt 是用完一次就扔的。

为什么我们必须改变？

去年我盯着一阵子我们团队的工作方式，我发现当前工作流有三个致命的瓶颈。

1.产品管理瓶颈

PM 通常需要花好几周调研、画原型、写 PRD。

产品团队几十年都是按这个流程干的。但 Agent 两小时就能把一个功能做出来。当 build 的时间从月级坍缩到小时级，周级的规划周期就成了整条链路上最慢的那一环。

一件事想几个月，但做两小时，这个比例说不过去。

PM 要么进化成能跟上迭代节奏的 Product-minded Architect，要么就得退出 build 的工作流。

应该设计出一套快速出原型 → 上线 → 看数据 → 迭代的工作流来替代原PM的工作流程，而不是继续在评审会上一页页过需求文档。

2.QA 瓶颈

一样的逻测试辑，Agent 能两小时完成交付，但 QA 需要三天测边界边界。当开发两小时，测试三天的时候，测试就成为了链路上最慢的那一环。

我们的做法是用 AI 搭的测试平台去测 AI 写的代码。验证速度必须跟上实现速度，不然你只是把瓶颈从上游挪到了下游十米的地方，瓶颈依旧存在。

3.人力瓶颈

我们的竞争对手在和我们干差不多的事，但团队规模是我们的 100 倍往上。

我们只有 25 个人，靠招人不可能追上这个差距。只能靠重新设计来抹平差距。

产品设计、产品研发、产品测试，三条线都必须让 AI 跑起来。

只要有一条还是纯手工，它就会成为瓶颈，整条工作流就被它卡死。

大胆的决定：统一架构

我做的第一件事是调整代码库。

老的代码架构散落在好几个分布式微服架构务设计的独立系统里，改个功能可能需要跨三四个仓库。

人能处理好分布式微服务架构，但 AI Agent 应付不了。 如果它看不到全局代码，就没法推理跨服务的完整连锁反应，也没办法在本地跑集成测试。

所以，我决定把服务从分布式架构走回单体，我把所有代码收拢到了一个代码仓库。

理由就一条：让 AI 能看见所有东西。 这就是 Harness Engineering 的核心原则。

你把越多的系统拉到 Agent 能检查、能验证、能改的范围里，AI能赋能的杠杆就越大，碎片化的代码库对 Agent 来说是不可见的，只有统一的、全貌的单体代码库才是完整可读的。

我们现花了一周重新设计新系统的四个阶段：规划、开发、测试、集成测试。

又再花了一周，用 Agent 把整个代码库重构了。

CREAO 是一个 Agent 平台。我们用自己的 Agent 重建了跑 Agent 的平台，产品能反过来Build自己，说明它确实能用。 这也是验证我们平台的一个方式。

技术栈

基础设施：AWS

我们的服务以容器的形式跑在 AWS 上，容器能够自动扩缩容 + 熔断回滚。

部署之后如果有指标变差，系统就能够自动回退。

CloudWatch 相当于中枢神经。将全量的服务日志进行结构化，我们配置了 25 个以上告警规则，每天会启动一次自动化流程检查我们的所有自定义指标。

所以基础设施的每个组件都对外暴露AI可读的、结构化的、可查询的信号。AI 读不懂日志，就诊断不了问题。

CI/CD：GitHub Actions

我们使用Github Actions作为CI/CD流水线，每次提交的CI/CD流水线分为六个步骤：

Verify CI（CI前置验证） → Build & Deploy Dev（构建和部署） → Test Dev（发布到测试环境） → Deploy Prod （发布到正式环境）→ Test Prod （正式环境测试）→ Release（对外发布）

我们对 PR 合并设置了一系列的门禁规则，CI 门禁包含：

类型检查
Lint
单元测试
集成测试
Docker 构建
Agent 使用 Playwright 进行端到端测试
环境一致性校验

没有哪一项可以跳过，并且不接受手动放行。因为流水线是确定性的，Agent 能预判结果，也能定位失败原因。

AI Code Review：Claude

每个 PR 自动触发三路并行Code Review，我们使用 Claude Opus 4.6 模型来进行代码CR：

第一路：代码质量——逻辑错误、性能隐患、可维护性
第二路：安全——漏洞扫描、认证边界、注入风险
第三路：依赖扫描——供应链风险、版本冲突、License 合规

代码CR不提供建议维度的审查，而是门禁强规则。AI CR会和人类 review 并行跑，专门检查工程师在高频部署下容易漏掉的东西。因为我们通常一天部署八次，没有哪个人类 reviewer 能每个 PR 都保持足够的专注和细心。

工程师也能在任意 GitHub Issue 或 PR 里 @claude，拿来做实现方案、做调试、分析代码。Agent 看得到整个 monorepo，上下文可以跨会话延续。

自愈反馈闭环

这是整套系统最重要的心脏。

每天早上 9:00 UTC，健康巡检会自动运行。Claude Sonnet 4.6 查 CloudWatch，分析全链路服务的错误日志，生成一份执行摘要推到 Teams，不需要任何手动触发。

一个小时之后，分诊引擎开始工作。它把 CloudWatch 和 Sentry 的生产错误做聚类，按 9 个严重性维度打分，自动在 Linear 里建立审查工单。每张工单带着：样本日志、受影响用户数、受影响接口、建议排查方向。

系统会进行去重，如果同一个错误模式已经有 open issue，就更新那条issue。如果之前关掉过的同类 issue 又冒出来了，系统自动识别为回归并重新打开。

工程师负责处理Issue，在推送修复之后，会走我们上面提到的同一条流水线：三路 Claude 审查 → CI 校验 → 六阶段部署 → 每阶段测试。

上线之后分诊引擎再查一轮 CloudWatch，如果原来的错误消失了，Linear 工单自动关闭。

每个工具只管一个阶段，没有哪个工具能够承包所有任务。日复一日的循环形成自愈闭环：发现 → 定级 → 修复 → 验证，人只在关键节点介入。

我跟 Business Insider 的记者这么形容：AI 提 PR，人只需要看一眼有没有风险。

Feature Flag 配套工具

Statsig 负责灰度：所有功能都在 flag 后面上线，节奏是：先仅对内部可见 → 按比例放量 → 全量上线或者回退。Statsig 提供的 Kill switch 能做到一键关闭功能，不用重新部署，这样就能做到数据不好看或异常后在短短的几小时内下线，烂功能活不过当天。同时，A/B 测试也走这套Feature Flag逻辑。

Graphite 负责 PR 流转：merge queue 自动 rebase 到 main，重跑 CI，全绿才合并，Stacked PR 支撑高吞吐下的分层CR。

Sentry 负责收集全链路服务的结构化异常，和 CloudWatch 一起被分诊引擎交叉分析。Linear 是给人看的那层：自动建的工单带严重性评分、样本日志、排查建议，支持去重防止工单刷屏，修完自动关单。

一个功能从想法到上线的全链路

新功能

Architect 把任务写成结构化 Prompt，带上代码库上下文、目标和约束
Agent 拆任务、定方案、写代码、顺手把测试也写了
PR 开启后，三路 Claude CR 并行跑。工程师 reviewer 只管战略级别的风险，不逐行看代码
CI 校验：类型检查、Lint、单测、集成测试、端到端测试
Graphite merge queue rebase + 重跑 CI，全绿了才合并
六阶段部署流水线把 dev 和 prod 都过一遍，每阶段带测试
Feature flag 的功能先对内开放，再按比例灰度，期间需要盯着指标
有问题随时 Kill switch，严重的话熔断器自动回滚

Bug 修复

CloudWatch + Sentry 捕获异常
Claude 分诊引擎打分定级，在 Linear 建工单，带完整排查的上下文
工程师接手，AI 此时已经把诊断做了，工程师验证一下，没问题后推送修复
走和新功能的同一套审查、CI、部署、监控流水线
分诊引擎复查，如果问题消失，则工单自动关闭

两条路径共用同一套流水线，一套系统，一个标准。

取得的成绩

在过去的 14 天里，我们平均每天进行 3 - 8 次生产环境的部署。如果按照老模式推进，可能两周连一次生产环境的部署都无法完成。

烂功能当天上当天砍，好功能当天想当天上，A/B 测试实时得出结论。

很多人觉得我们是在拿质量换速度，但事实上：用户活跃度上去了，付费转化率也上去了。 我们取得的结果比以前更好，因为反馈循环更紧了。一天上一次线相比一个月上一次线，我们能学到的东西多了几十倍。

新的工程组织

往后只会存在两种工程师。

Architect（架构师）

一个组织只会存在一两个这种角色。他们负责

写 SOP 教 AI 怎么干活
搭测试基础设施
搭集成系统
搭分诊系统

架构和系统边界是他们定的，Agent 的好坏标准也是他们定的。

这个角色需要的是深度批判性思维，你得挑 AI 的毛病，而不是跟着它走。Agent 出了方案之后，Architect 要做的是找其中的漏洞以及不足之处：

哪些故障模式漏了？
哪些安全边界越了？
哪些技术债在悄悄堆积？

我自己是物理学博士，读博教给我最有用的东西，是怎么质疑假设、怎么对论点做测试、怎么找到别人没说、没发现的那部分。

能批评 AI 的人，比能写代码的人值钱。

这也是最难招的角色。

Operator

剩下的工程师，干活依然重要，只是干活的方法变了。

以后会是AI 给人派活。 分诊系统发现 bug，建工单，给出诊断，分配给合适的人。

人负责验证、确认、批准修复。AI 提 PR，然后人看一眼有没有风险。

具体干的事是 bug 排查、UI 打磨、样式调整、PR 审查、上线验证。

这些需要工程师具备技术功底、付出时间和注意力，但不再需要老模式里那种架构级的推理能力。

谁适应得最快

有个规律出乎我的意料，我发现初级工程师比高级工程师适应得快。

初级工程师没多少老习惯要改，反而觉得AI如虎添翼，手里突然多了一堆放大自身能力的工具，不需要花十年攒开发经验才能做出大的产出。

而老练的高级工程师最难受，放以前两个月的活 AI 一小时干完。他们花了好多年磨出来的稀缺手艺，突然不稀缺了。

我不下判断，只说我看到的事实。在这轮转型里，能不能适应比攒了多少经验更重要。

关于人的一面

管理坍缩了

两个月前，我 60% 的时间都花在管人上。我花了大量时间做：对齐优先级、开会、给反馈、带工程师成长此类事情。

而现在这个占比：不到 10%。

传统 CTO 的打法是赋能团队、培养他们做架构、逐步放权。

但如果整个系统只需要一两个 Architect，那第一个必须是我自己，所以我从管理者变成了 Architect，大部分时间我从早上 9 点写代码到凌晨 3 点。SOP 我设计，架构我定，Harness 我维护。

虽然更累，但我享受造东西的过程，不想再回去对齐了。

吵架少了，关系反而好了

我和联合创始人、和工程师的关系比转型前更好。

以前我跟团队的大部分交流都是在对齐：讨论取舍、争优先级、为技术方案拍桌子。传统模式下这些对话不可少，但真的很消耗人之间的情谊。

现在还是会花时间聊，只不过聊别的了。扯扯闲天、聊聊生活、约约团建。

不用再为那些 AI 能搞定的事争来争去，大家相处轻松多了。

焦虑是真实的

并不是每个人都很开心。

在我不再每天逐个找人聊之后，有人开始不安。CTO 不找我说话了什么意思？我在新模式下还有什么价值？这些焦虑和担忧是make sense的。

有些人花在讨论 AI 会不会取代我上的精力，比干活还多。

转型期天然就会制造焦虑，我给不出一个好听的答案。

但我有一条原则：工程师上了一个生产 bug，我们不开人，我们改流程、加测试、加强Harness，对 AI 也一样。 AI 出了错，我们搭更好的验证、写更清晰的约束、建更强的可观测性。

不止工程

不少公司在工程侧搞了 AI-first，其他部门还是全手工。

工程能做到两小时交付，但如果市场一周才发公告，那么市场就是瓶颈；如果产品还在按月做规划，那么产品就是瓶颈。

在 CREAO，我们把 AI-native 推进到了每个职能：

产品发布公告：AI 根据 Changelog 和功能描述自动生成
功能介绍视频：AI 生成动效素材
每日社交媒体内容：AI 编排 + 自动发布
健康报告和数据摘要：AI 从 CloudWatch 和生产库里直接拉数据生成

工程、产品、市场、增长跑在同一条 AI-native 流水线上。如果一个职能以 Agent 速度推进，但另一个还在以人肉速度，那么后者就是整个系统的天花板和瓶颈。

这意味着什么

对工程师

你的价值在从产出代码往决策质量迁移。快速写代码这件事每个月都在贬值，而评估、批评、指挥 AI 这件事每个月都在升值。

产品感觉很关键。AI 生成了一套 UI，你扫一眼能不能看出哪里别扭，不用等用户来投诉？AI 出了一版架构方案，你能不能一秒发现它漏掉的故障模式？

我跟我们 19 岁的实习生说：练批判性思维。 学会拆论证、找漏洞、质疑前提。学会什么算好的设计。这些东西有复利。

对 CTO 和创始人

PM 流程比构建时间还长的话，先从那里动刀。

在放大 Agent 之前，先把测试 Harness 搭好。没有快速验证兜底的快速 AI，就是在快速堆技术债。

从一个 Architect 开始。一个人先把系统搭起来跑通。跑顺了再让其他人以 Operator 身份加入。

把 AI-native 推到每个职能，不只是工程。

做好心理准备迎接阻力。会有人反对。

对行业

OpenAI、Anthropic 和好几个独立团队，各自摸索，最后走到了同一个地方：结构化上下文、专业化 Agent、持久记忆、执行循环。Harness Engineering 正在变成行业共识。

模型能力是推动这一切的发条。CREAO 这次转变，我归因于最近两个月的模型进步。Opus 4.5 干不了的事 Opus 4.6 能干了。下一代模型出来还会再快一截。

我判断一人公司会越来越多。一个 Architect 带着一群 Agent 能顶 100 个人的产出，很多公司根本不需要第二个员工。

还很早

我聊过的创始人和工程师，大部分还在用老办法。有些人在琢磨要不要转，真正动手了的凤毛麟角。

一个记者朋友跟我说，这个话题她大概聊了五个人，我们走得比谁都远：没见过谁像你们这样把整套工作流彻底重建了。

我们用的工具没有一样是自研的，任何团队都能拿到。

真正的竞争壁垒是敢做这个决定——围绕 AI 把一切推倒重来——以及扛住过程中的代价。代价是实实在在的：员工心里没底、CTO 每天干 18 个小时、高级工程师开始怀疑自己值不值钱、有两周时间旧系统拆了新系统还没立住。

我们扛过来了。两个月后，数字自己会说话。

我们做 Agent 平台。我们用 Agent 造了它。