原文：Why Your “AI-First” Strategy Is Probably Wrong
作者：Peter Pang（@intuitiveml），CREAO CTO，前 Meta GenAI tech lead、Apple AI Scientist
我们 99% 的生产代码由 AI 编写。上周二，我们上午 10 点发布了一个新功能，中午做了 A/B 测试，下午 3 点因为数据不通过把它下线了。下午 5 点，我们发布了更好的版本。三个月前，这样一个循环需要六周。
我们不是通过给 IDE 装上 Copilot 走到这一步的。我们拆掉了原有的工程流程，围绕 AI 重新搭建。我们改变了计划、构建、测试、部署和组织团队的方式。我们改变了公司里每个人的角色。
CREAO 是一个 agent 平台。25 名员工，10 名工程师。我们从 2025 年 11 月开始构建 agent，两个月前我从零重构了整个产品架构和工程工作流。
OpenAI 在 2026 年 2 月发表的一个概念恰好描述了我们在做的事情。他们称之为 harness engineering（缰绳工程）：工程团队的首要工作不再是写代码，而是让 agent 能做有用的工作。出了问题，修正方案不是"再努力一点"，而是：缺少什么能力？如何让这种能力对 agent 来说是清晰可执行且有约束的？
我们自己得出了这个结论。当时我们不知道它叫什么。
大多数公司只是在现有流程上嫁接 AI。工程师打开 Cursor。PM 用 ChatGPT 写需求。QA 尝试用 AI 做测试生成。工作流保持不变。效率提升了 10% 到 20%。没有任何结构性的改变。
那是 AI 辅助（AI-assisted）。
AI-First 意味着你以 AI 是主要建造者为前提，重新设计流程、架构和组织。你不再问"AI 如何帮助我们工程师？"，而是问"我们如何重构一切，让 AI 负责建造，工程师提供方向和判断？"
区别是乘数级的。
我看到很多团队声称 AI-first，但依然在用同样的 sprint 周期、同样的 Jira 面板、同样的周会、同样的 QA 签字流程。他们把 AI 加进了循环，但没有重新设计循环。
另一个常见版本是所谓的"氛围编码（vibe coding）"——打开 Cursor，不断写提示词直到跑通，提交，重复。这能产出原型。但生产系统需要稳定、可靠、安全。你需要一个能在 AI 写代码时保证这些属性的系统。你构建的是系统。提示词是可丢弃的。
去年，我观察了自己的团队，看到了三个会扼杀我们的瓶颈。
我们的 PM 花几周时间做调研、设计、编写需求规格。产品管理几十年来一直是这样工作的。但 agent 两个小时就能实现一个功能。当构建时间从几个月压缩到几小时，数周的计划周期就成了瓶颈。
花几个月思考一个东西，然后用两个小时构建它——这没有意义。
PM 需要进化为具备产品思维的架构师，以迭代的速度工作，或者离开构建循环。设计需要通过快速的"原型-发布-测试-迭代"循环完成，而不是在评审委员会上审阅规格文档。
同样的动态。agent 发布一个功能后，我们的 QA 团队花好几天测试边界情况。构建时间：两小时。测试时间：三天。
我们用 AI 构建的测试平台替换了手动 QA，用来测试 AI 写的代码。验证的速度必须跟上实现的速度。否则你只是在下游十英尺处新造了一个瓶颈。
我们的竞争对手有 100 倍甚至更多的人力在做类似的工作。我们只有 25 人。我们无法靠招人追赶。我们必须靠重新设计来达到同等水平。
三个系统需要 AI 贯穿其中：如何设计产品、如何实现产品、如何测试产品。只要其中一个环节是手动的，它就会制约整个流水线。
我得先解决代码库的问题。
我们旧的架构分散在多个独立的系统中。一次改动可能需要涉及三四个仓库。从人类工程师的角度看，这还可以管理。但从 AI agent 的角度看，这是不透明的。agent 看不到全貌，无法推理跨服务的影响，无法在本地跑集成测试。
我必须把所有代码统一到单个 monorepo 里。原因只有一个：让 AI 能看见一切。
这是 harness engineering 原则的实践。你越是把系统的各部分拉到 agent 可以审查、验证和修改的形式中，你获得的杠杆就越大。碎片化的代码库对 agent 来说是隐形的。统一后的代码库是可读的。
我用一周设计新系统：规划阶段、实现阶段、测试阶段、集成测试阶段。然后用另一周用 agent 重构了整个代码库。
CREAO 是一个 agent 平台。我们用自己的 agent 来重建运行 agent 的平台。如果产品能自己建造自己，它就真的管用。
基础设施：AWS。我们运行 AWS 上的自动扩缩容器服务，带断路回滚机制。部署后如果指标恶化，系统自动回退。
CloudWatch 是中枢神经系统。所有服务的结构化日志、超过 25 个告警、每天由自动化工作流查询的自定义指标。每一块基础设施都暴露结构化、可查询的信号。如果 AI 读不了日志，它就诊断不了问题。
CI/CD：GitHub Actions。每次代码变更经过六阶段流水线：
Verify CI → Build and Deploy Dev → Test Dev → Deploy Prod → Test Prod → Release
每个 PR 的 CI 关卡强制执行类型检查、linting、单元和集成测试、Docker 构建、Playwright 端到端测试和环境一致性检查。没有阶段是可选的。没有手动绕过。流水线是可确定的，agent 可以预测结果并推理失败原因。
AI 代码评审：Claude。每条 PR 触发三轮并行的 AI 评审，使用 Claude Opus 4.6：
这些是评审关卡，不是建议。它们和人类评审并行运行，以量捕捉人类遗漏的问题。当你每天部署八次时，没有人类评审员能在每条 PR 上保持注意力。
工程师也可以在 GitHub issue 或 PR 中 @claude 请求实现方案、调试会议或代码分析。agent 能看到整个 monorepo。上下文在对话间延续。
自愈反馈环——这是核心。
每天 UTC 时间 9:00 AM，一个自动化健康工作流启动。Claude Sonnet 4.6 查询 CloudWatch，分析所有服务的错误模式，生成一份执行级健康摘要，通过 Microsoft Teams 发送给团队。没有人需要去问。
一小时后，分类引擎启动。它将 CloudWatch 和 Sentry 中的生产错误聚类，按九个严重维度打分，然后在 Linear 中自动生成调查工单。每个工单包含示例日志、受影响用户、受影响端点和建议的调查路径。
系统会自动去重。如果已开的 issue 覆盖了相同的错误模式，它会更新该 issue。如果已关闭的 issue 复发，它会检测到回归并重新打开。
当工程师推送修复时，同一套流水线处理一切。三轮 Claude 评审评估 PR。CI 验证。六阶段部署流水线在 dev 和 prod 间推进，每阶段都有测试。部署完成后，分类引擎重新检查 CloudWatch。如果原始错误已解决，Linear 工单自动关闭。
每个工具只处理一个阶段。没有一个工具试图做所有事情。每日循环创造了一个自愈闭环：错误被检测、分类、修复和验证，只需要最少的人工干预。
我对 Business Insider 的记者说：“AI 会创建 PR，人类只需要评审是否存在风险。”
Feature Flags 与支撑栈
Statsig 管理 feature flag。每个功能在开关后面发布。发布模式：先开放给团队内部，然后逐步百分比开放，最后全面发布或下线。kill switch（紧急下线开关）可以立即关闭一个功能，无需重新部署。如果一个功能导致指标恶化，几小时内就能撤销。不好的功能在发布当天就死掉。A/B 测试通过同一套系统运行。
Graphite 管理 PR 分支：合并队列自动 rebase 到主分支，重新跑 CI，仅当所有检查通过时才合并。堆叠式 PR（stacked PRs）支持增量评审，在高吞吐场景下保持 review 质量。
Sentry 收集所有服务的结构化异常，由分类引擎与 CloudWatch 数据合并以实现跨工具上下文。Linear 是人类面对的一层：带有严重性评分、示例日志和建议调查方案的自动创建工单。去重防止噪音。跟进验证自动关闭已解决 issue。
新功能路径：
Bug 修复路径：
两条路径使用同一套流水线。一个系统。一个标准。
14 天内，我们平均每天 3 到 8 次生产部署。在旧模式下，整个两周的时间连一次生产发布都做不到。
不好的功能在发布当天就被撤回。新功能在构思当天就上线。A/B 测试实时验证影响。
人们以为我们在用速度换质量。但用户参与度上升了。支付转化率上升了。我们产出的结果比以前更好，因为反馈环更紧密了。你每天发布学到的东西比每月发布多得多。
将来只会存在两类工程师。
架构师（Architect）——一到两个人。他们设计标准操作流程（SOP），教 AI 如何工作。他们构建测试基础设施、集成系统、分类系统。他们决定架构和系统边界。他们定义什么对 agent 来说是"好"的。
这个角色需要深度批判性思维。你批评 AI，而不是跟随 AI。当 agent 提出一个方案时，架构师找出漏洞。它遗漏了什么失败模式？它越过了什么安全边界？它在积累什么技术债？
我有物理学博士学位。读博对我最有用的训练是如何质疑假设、压力测试论点、寻找缺失的东西。批评 AI 的能力将比产生代码的能力更有价值。
这也是最难填补的岗位。
操作员（Operator）——其他所有人。工作本身仍然重要，但结构不同了。
AI 给人类分配任务。分类系统发现 bug，创建工单，呈现诊断结论，分配给合适的人。这个人调查、验证、批准修复。AI 创建 PR。人类评审是否存在风险。
任务是 bug 调查、UI 打磨、CSS 改进、PR 评审、验证。它们需要技能和注意力。它们不再需要旧模型下的架构推理能力。
谁适应得最快？
我注意到了一个意料之外的模式。初级工程师比高级工程师适应得更快。
传统实践经验较少的初级工程师感到更有力量。他们获得了能放大自己影响力的工具。他们没有携带十年需要卸载的习惯。
拥有深厚传统实践经验的高级工程师最难受。他们两个月的工作量，AI 一个小时就能完成。在花了多年时间建立一项稀缺技能之后，接受这个事实很难。
我不是在评判谁对谁错。我只是在描述我观察到的事实。在这个转型中，适应性比积累的技能更重要。
管理消失了。 两个月前，我 60% 的时间花在管理人上：对齐优先级、开会、给反馈、指导工程师。今天：不到 10%。
传统的 CTO 模式说你要赋能团队——让他们做架构工作、培训他们、授权他们。但如果系统只需要一到两个架构师，我得先自己来做。我从管理变成了建造。大多数日子里我从早上 9 点写到凌晨 3 点。我设计 SOP 和系统架构。我维护缰绳（harness）。
更有压力。但我享受建造本身，而不是对齐工作。
少争吵，更好的关系。 我和联合创始人及工程师的关系比以前更好了。
转型之前，我和团队的大部分互动都是对齐会议：讨论权衡、争论优先级、对技术决策有分歧。这些对话在传统模型中是必要的，但也很消耗人。
现在我仍然和团队聊天。我们聊其他事情——非工作话题、闲聊、团建出行。我们关系更好了，因为不再争论那些系统能轻松完成的工作。
不确定性是真实的。 我不会假装每个人都开心。
当我停止每天和团队交流后，一些团队成员感到不安。CTO 不和我说话意味着什么？在这个新世界里我的价值是什么？这些都是合理的担忧。
有些人花更多时间辩论 AI 是否能做他们的工作，而不是实际去做工作。转型期会制造焦虑。我没有一个干净利落的答案。
但我有一个原则：我们不会因为工程师引入了一个生产 bug 就开除他。我们会改进评审流程、加强测试、增加护栏。对 AI 也是一样。如果 AI 犯了错，我们就建更好的验证、更清晰的约束、更强的可观测性。
我看到其他公司采用 AI-first 工程，但留下所有其他环节还是手动的。
如果工程几小时就能交付功能，但市场部要花一周来发布公告，那么市场部就是瓶颈。如果产品团队仍然跑月度计划周期，那么计划就是瓶颈。
在 CREAO，我们把 AI-native 操作推到了每个职能：
工程、产品、市场和增长运行在同一个 AI-native 工作流中。如果一个职能以 agent 速度运行，另一个以人类速度运行，那么人类速度的职能就会制约一切。
对工程师而言： 你的价值正从代码产出转向决策质量。快速写代码的能力每个月都在贬值。评估、批评和指导 AI 的能力每个月都在升值。
产品感或品味很重要。你能看一眼生成的 UI，在用户告诉你之前就发现不对吗？你能看一眼架构方案，就发现 agent 遗漏的失败模式吗？
我告诉我们 19 岁的实习生：训练批判性思维。学会评估论点、找漏洞、质疑假设。学会什么是好的设计。这些技能会持续复利。
对 CTO 和创始人而言： 如果你的 PM 流程比构建时间还长，从那里开始改。
在规模化 agent 之前先建好测试缰绳。没有快速验证的快速 AI 是快速流动的技术债。
从一个架构师开始。一个人搭建系统并证明它能跑。系统跑起来后再把其他人引入操作员角色。
把 AI-native 推入每个职能。
做好遇到抵抗的准备。有些人会反弹。
对行业而言： OpenAI、Anthropic 和多个独立团队都收敛到了相同的原理上：结构化上下文、专用 agent、持久化记忆和执行循环。Harness engineering 正在成为一个标准。
模型能力是驱动这一切的时钟。我把 CREAO 的全部转变归因于最近两个月。Opus 4.5 做不到 Opus 4.6 能做的事。下一代模型会加速得更多。
我相信单人公司将会变得普遍。如果一个架构师加 agent 能做 100 人的工作，很多公司不再需要第二个员工。
我交谈过的大多数创始人和工程师仍然在以传统方式运作。有些人考虑过转型。很少有人已经做了。
一个记者朋友告诉我她大约和五个人聊过这个话题。她说我们比任何人都走得更远：“我觉得没有人像你们这样彻底地重建了全套工作流。”
这些工具对任何团队都是可用的。我们的栈里没有任何东西是专有的。
竞争优势在于围绕这些工具重新设计一切的决心，以及承受代价的意愿。 代价是真实的：员工的不确定性、CTO 每天工作 18 小时、资深工程师质疑自己的价值、旧系统消失新系统尚未被证明的两周真空期。
我们承受了那个代价。两个月后，数字说明了一切。
我们是构建 agent 平台的公司。我们用 agent 构建了它。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。