为什么你的"AI优先"策略可能是错的
- 来源: X.com - @intuitiveml
- 作者: Peter Pang (@intuitiveml)
- 翻译时间: 2026-04-14
- 原文标题: Why Your “AI-First” Strategy Is Probably Wrong
正文内容
我们 99% 的生产代码由 AI 编写。上周二，我们在上午 10 点发布了一个新功能，中午进行 A/B 测试，下午 3 点因为数据不佳而下线。下午 5 点我们发布了更好的版本。三个月前，这样一个周期需要六周时间。
我们不是靠把 Copilot 添加到 IDE 做到这一点的。我们拆解了整个工程流程，围绕 AI 重新构建。我们改变了规划、构建、测试、部署和组织团队的方式。我们改变了公司每个人的角色。
CREAO 是一个代理平台。25 名员工，10 名工程师。我们从 2025 年 11 月开始构建代理，两个月前我从零开始重构了整个产品架构和工程工作流。
OpenAI 在 2026 年 2 月发布了一个概念，捕捉了我们一直在做的事情。他们称之为 harness engineering（ harness 工程）：工程团队的主要工作不再是编写代码，而是让代理能够完成有用的工作。当某件事情失败时，修复方法从来不是"更努力"。修复方法是：缺少什么能力，我们如何让它对代理来说是清晰可读的、可执行的？
我们自己得出了这个结论。我们没有一个名字来形容它。
AI优先不等于使用AI
大多数公司把 AI 套到现有流程上。工程师打开 Cursor，产品经理用 ChatGPT 起草需求文档，QA 尝试 AI 测试生成。工作流保持不变。效率提高 10% 到 20%。结构上没有任何改变。
这是 AI 辅助。
AI 优先意味着你重新设计流程、架构和组织，基于 AI 是主要构建者的假设。
你不再问"AI 如何帮助我们的工程师？"，而是开始问"我们如何重构一切，让 AI 来做构建，而工程师提供方向和判断？"
区别是乘法效应。
我看到团队声称 AI 优先，却运行着相同的冲刺周期、相同的 Jira 看板、相同的每周站会、相同的 QA 签字流程。他们只是把 AI 加到循环里。他们没有重新设计循环。
一个常见的版本是人们所说的 vibe coding（氛围编程）。打开 Cursor，提示直到某个东西能运行，提交，重复。这能产生原型。生产系统需要稳定、可靠、安全。你需要一个能在 AI 编写代码时保证这些属性的系统。你构建这个系统，提示是可丢弃的。
为什么我们不得不改变
去年，我观察团队的工作方式，看到了三个会杀死我们的瓶颈。
产品管理瓶颈
我们的产品经理花数周时间研究、设计、定义功能规格。产品管理几十年来都是这样工作的。但代理可以在两小时内实现一个功能。当构建时间从数月崩溃到小时，数周的规划周期就变成了约束。
花数月思考某件事，然后两小时内构建它，这是不合理的。
产品经理需要进化为以迭代速度工作的产品架构师，或者退出构建循环。设计需要通过快速原型-发布-测试-迭代循环来完成，而不是在委员会中评审规格文档。
QA 瓶颈
同样的动态。代理发布功能后，我们的 QA 团队花数天测试边界情况。构建时间：两小时。测试时间：三天。
我们用 AI 构建的测试平台来测试 AI 编写的代码，取代了人工 QA。验证必须与实现以相同速度移动。否则你就在旧瓶颈下游十英尺处建了一个新瓶颈。
人力瓶颈
我们的竞争对手有 100 倍或更多的人做类似的工作。我们有 25 人。我们无法通过招聘达到平等。我们必须通过重新设计来达到。
三个系统需要 AI 贯穿其中：我们如何设计产品、如何实现产品、如何测试产品。如果任何一个保持手动，它就会约束整个管道。
大胆的决策：统一架构
我必须先修复代码库。
我们的旧架构分散在多个独立系统中。一个单一变更可能需要触碰三到四个仓库。从人类工程师的角度来看，这是可以管理的。从 AI 代理的角度来看，这是不透明的。代理看不到完整的画面。它无法推理跨服务的影响。它无法在本地运行集成测试。
我必须把所有代码统一到一个 monorepo（单体仓库）中。一个原因：让 AI 能看到一切。
这是 harness 工程原则的实践。你把系统越多地拉入代理可以检查、验证和修改的形式，你获得的杠杆就越大。碎片化的代码库对代理是不可见的。统一的代码库是可读的。
我花了一周时间设计新系统：规划阶段、实现阶段、测试阶段、集成测试阶段。然后又用了一周时间使用代理重新架构整个代码库。
CREAO 是一个代理平台。我们用自己的代理重建了运行代理的平台。如果产品能自我构建，它就是有效的。
技术栈
以下是我们的技术栈以及每个部分的作用。
基础设施：AWS
我们在 AWS 上运行，使用自动扩展容器服务和熔断回滚。如果指标在部署后下降，系统会自动回滚。
CloudWatch 是中枢神经系统。所有服务的结构化日志，超过 25 个告警，自定义指标每天由自动化工作流查询。每个基础设施都暴露结构化、可查询的信号。如果 AI 无法读取日志，它就无法诊断问题。
CI/CD：GitHub Actions
每个代码变更都通过一个六阶段管道：
验证 CI → 构建和部署开发环境 → 测试开发环境 → 部署生产环境 → 测试生产环境 → 发布
每个 pull request 上的 CI 门禁强制执行类型检查、lint、单元和集成测试、Docker 构建、通过 Playwright 的端到端测试，以及环境一致性检查。没有阶段是可选的。没有手动覆盖。管道是确定性的，所以代理可以预测结果并推理失败。
AI 代码审查：Claude
每个 pull request 触发三个并行的 AI 审查通过，使用 Claude Opus 4.6：
- 第一轮：代码质量。逻辑错误、性能问题、可维护性。
- 第二轮：安全。漏洞扫描、认证边界检查、注入风险。
- 第三轮：依赖扫描。供应链风险、版本冲突、许可证问题。
这些是与人工审查并行的审查门禁，不是建议。它们捕获人类在大量 PR 中无法持续关注的遗漏。当你每天部署八次时，没有人工审查员能在每个 PR 上保持注意力。
工程师还可以在任意 GitHub issue 或 PR 中标记 @claude 来获取实施计划、调试会话或代码分析。代理能看到整个 monorepo。上下文跨对话携带。
自我修复反馈循环
这是核心部分。
每天早上 9:00 UTC，一个自动化健康工作流运行。Claude Sonnet 4.6 查询 CloudWatch，分析所有服务的错误模式，并生成执行健康摘要，通过 Microsoft Teams 交付给团队。没有人需要要求它。
一小时后，分类引擎运行。它从 CloudWatch 和 Sentry 聚类生产错误，在九个严重维度上评分每个聚类，并在 Linear 中自动生成调查工单。每个工单包括示例日志、受影响的用户、受影响的端点，以及建议的调查路径。
系统去重。如果有一个开放的 issue 覆盖相同的错误模式，它会更新那个 issue。如果之前关闭的 issue 复发，它会检测回归并重新打开。
当工程师推送修复时，同一个管道处理它。三轮 Claude 审查评估 PR。CI 验证。六阶段部署管道通过开发和生产环境进行测试。部署后，分类引擎重新检查 CloudWatch。如果原始错误已解决，Linear 工单自动关闭。
每个工具处理一个阶段。没有工具试图做一切。日常循环创建一个自我修复循环，错误被检测、分类、修复和验证，最小化人工干预。
我告诉 Business Insider 的一位记者：“AI 会制作 PR，人类只需要审查是否有风险。”
功能标志和支持栈
Statsig 处理功能标志。每个功能在门禁后发布。推出模式：对团队启用，然后逐步百分比推出，然后完全发布或下线。下线开关可以在不需要部署的情况下立即关闭功能。如果功能降低指标，我们在数小时内下线。坏功能在发布的同一天死亡。A/B 测试通过同一个系统运行。
Graphite 管理 PR 分支：合并队列在 main 上变基，重新运行 CI，只有绿色时才合并。堆叠式 PR 允许在高吞吐量下进行增量审查。
Sentry 在所有服务中报告结构化异常，通过分类引擎与 CloudWatch 合并，用于跨工具上下文。Linear 是面向人类的层：自动创建的工单带有严重评分、示例日志和建议的调查。去重防止噪音。后续验证自动关闭已解决的问题。
功能如何从想法移动到生产
新功能路径
- 架构师将任务定义为结构化提示，带有代码库上下文、目标和约束。
- 代理分解任务，规划实现，编写代码，并生成自己的测试。
- 一个 PR 打开。三轮 Claude 审查评估它。人工审查员检查战略风险，而不是逐行正确性。
- CI 验证：类型检查、lint、单元测试、集成测试、端到端测试。
- Graphite 的合并队列变基、重新运行 CI、绿色时合并。
- 六阶段部署管道通过开发和生产环境进行测试。
- 功能门禁对团队打开。逐步百分比推出。监控指标。
- 如果任何东西降级，下线开关可用。熔断器自动回滚严重问题。
Bug 修复路径
- CloudWatch 和 Sentry 检测错误。
- Claude 分类引擎评分严重性，创建带有完整调查上下文的 Linear issue。
- 工程师调查。AI 已经完成诊断。工程师验证并推送修复。
- 相同的审查、CI、部署和监控管道。
- 分类引擎重新验证。如果已解决，工单自动关闭。
两个路径使用相同的管道。一个系统。一个标准。
结果
在 14 天内，我们平均每天有 3 到 8 次生产部署。在我们的旧模式下，整个两周周期甚至无法产生一次发布到生产环境。
坏功能在发布的同一天被下线。新功能在构思的当天上线。A/B 测试实时验证影响。
人们假设我们在用质量换取速度。用户参与度上升。支付转化率上升。我们比以前产生更好的结果，因为反馈循环更紧密。当你每天发布时，你学到的比每月发布时更多。
新工程组织
将存在两种类型的工程师。
架构师
一两个人。他们设计标准操作程序，教 AI 如何工作。他们构建测试基础设施、集成系统、分类系统。他们决定架构和系统边界。他们为代理定义"好"的样子。
这个角色需要深度的批判性思维。你批评 AI。你不跟随它。当代理提出计划时，架构师找到漏洞。它遗漏了什么失败模式？它跨越了什么安全边界？它在积累什么技术债务？
我有物理学博士学位。我的博士学位教给我最有用的东西是如何质疑假设、压力测试论点、寻找遗漏的东西。批评 AI 的能力将比产生代码的能力更有价值。
这也是最难填补的角色。
操作员
其他所有人。工作很重要。结构不同。
AI 分配任务给人类。分类系统找到 bug，创建工单，呈现诊断，并分配给正确的人。人调查、验证、批准修复。AI 制作 PR。人类审查是否有风险。
任务是 bug 调查、UI 优化、CSS 改进、PR 审查、验证。它们需要技能和注意力。它们不需要旧模型所要求的架构推理。
谁适应得最快
我注意到了一个我没有预料到的模式。初级工程师比高级工程师适应得更快。
传统实践较少的初级工程师感到被赋能。他们有了放大影响力的工具。他们没有十年的习惯需要放弃。
传统实践很强的高级工程师最难适应。两个月的工作可以被 AI 在一小时内完成。在多年建立稀有技能集之后，这是一个很难接受的事实。
我不是在做判断。我在描述我观察到的。在这个转变中，适应性比积累的技能更重要。
人的一面
管理 collapsed（崩溃/瓦解）
两个月前，我 60% 的时间花在管理人上。对齐优先级。开会。给反馈。指导工程师。
今天：低于 10%。
传统的 CTO 模式说要赋能团队做架构工作，培训他们，委派。但如果系统只需要一两个架构师，我需要自己先去做。我从管理转向构建。我大多数日子从早上 9 点编码到凌晨 3 点。我设计系统的 SOP 和架构。我维护 harness。
压力更大。但我在享受构建，而不是对齐。
更少的争论，更好的关系
我与联合创始人及工程师的关系比以前更好。
在转变之前，我与团队的大部分互动是对齐会议。讨论权衡。争论优先级。对技术决策有分歧。这些对话在传统模型中是必要的。它们也是令人疲惫的。
现在我仍然与团队交谈。我们谈论其他事情。非工作话题。随意对话。外出旅行。我们相处得更好，因为我们停止了对可以由系统轻松完成的工作的争论。
不确定性是真实的
我不会假装每个人都开心。
当我停止每天与每个人交谈时，一些团队成员感到不确定。CTO 不跟我交谈意味着什么？我在这个新世界的价值是什么？合理的担忧。
有些人花更多时间争论 AI 是否能做他们的工作，而不是做工作。转变期产生焦虑。我没有干净的答案。
我确实有一个原则：我们不会因为工程师引入生产 bug 而解雇他们。我们改进审查流程。我们加强测试。我们添加护栏。同样的原则适用于 AI。如果 AI 犯错，我们构建更好的验证、更清晰的约束、更强的可观察性。
超越工程
我看到其他公司采用 AI 优先工程，但让其他一切保持手动。
如果工程在小时内发布功能，但营销需要一周来宣布，营销是瓶颈。如果产品团队仍然运行月度规划周期，规划是瓶颈。
在 CREAO，我们把 AI 原生操作推入每个职能：
- 产品发布说明：AI 从变更日志和功能描述生成。
- 功能介绍视频：AI 生成的动态图形。
- 社交媒体日常帖子：AI 编排和自动发布。
- 健康报告和分析摘要：AI 从 CloudWatch 和生产数据库生成。
工程、产品、营销和增长在一个 AI 原生工作流中运行。如果一个职能以代理速度运行，另一个以人类速度运行，人类速度的职能约束一切。
这意味着什么
对工程师
你的价值正在从代码输出转向决策质量。快速编写代码的能力每月都在贬值。评估、批评和指导 AI 的能力每月都在升值。
产品感觉或品味很重要。你能在用户告诉你之前看出生成的 UI 是错的吗？你能在代理遗漏之前看出架构提案的失败模式吗？
我告诉我们的 19 岁实习生：训练批判性思维。学习评估论点、找到差距、质疑假设。学习好的设计是什么样子。这些技能会复合。
对 CTO 和创始人
如果你的 PM 流程比构建时间长，从那里开始。
在扩展代理之前构建测试 harness。没有快速验证的快速 AI 是快速移动的技术债务。
从一个架构师开始。一个构建系统并证明它有效的人。在系统运行后，让其他人以操作员角色加入。
把 AI 原生推入每个职能。
预期阻力。有些人会反对。
对行业
OpenAI、Anthropic 和多个独立团队都汇聚在相同的原则上：结构化上下文、专门代理、持久记忆、执行循环。Harness 工程正在成为标准。
模型能力是驱动这一转变的时钟。我把 CREAO 的整个转变归因于过去两个月。Opus 4.5 做不到 Opus 4.6 能做的事。下一代模型将进一步加速。
我相信一人公司将成为常态。如果一个架构师带代理能做 100 人的工作，许多公司不需要第二个员工。
我们还处于早期
我交谈的大多数创始人和工程师仍然以传统方式运作。有些在考虑转变。很少有人已经做到了。
一位记者朋友告诉我，她采访了大约五个人关于这个话题。她说我们比任何人都走得更远：“我不认为有人像你那样完全重建了整个工作流。”
工具存在，任何团队都可以这样做。我们的技术栈中没有什么是专有的。
竞争优势是围绕这些工具重新设计一切的决策，以及吸收成本的意愿。成本是真实的：员工中的不确定性、CTO 工作 18 小时的日子、高级工程师质疑他们的价值、旧系统已去新系统未被证明的两周期。我们吸收了那个成本。两个月后，数字说话。
我们构建一个代理平台。我们用代理构建了它。