为什么你的“AI优先”战略很可能是错的

我们99%的生产代码都是由AI编写的。上周二，我们在上午10点发布了一个新功能，中午前完成了A/B测试，下午3点就将其下线了，因为数据表明它不行。下午5点，我们发布了一个更好的版本。三个月前，这样的一个周期需要六周。

我们不是通过在IDE中添加Copilot达到这一步的。我们拆解了我们的工程流程，并围绕AI重建了它。我们改变了规划、构建、测试、部署的方式，也改变了团队的组织方式。我们改变了公司里每个人的角色。

CREAO是一个智能体平台。我们有25名员工，其中10名工程师。我们从2025年11月开始构建智能体，两个月前，我彻底重构了整个产品架构和工程工作流。

OpenAI在2026年2月发布了一个概念，恰好概括了我们一直在做的事情。他们称之为“驾驭工程”：工程团队的主要工作不再是编写代码，而是让智能体能够完成有用的工作。当出现故障时，解决方法从来不是“更努力地尝试”，而是：缺少了什么能力？我们如何让智能体能够理解并执行这个能力？

这是我们自己得出的结论。当时我们还没有给它命名。

AI优先不等于使用AI#

大多数公司只是将AI生硬地嫁接到现有流程上。工程师打开Cursor。产品经理用ChatGPT起草规格说明。质量保证人员尝试用AI生成测试。工作流保持不变。效率提高了10%到20%。结构上没有任何改变。

这是AI辅助。

AI优先意味着你围绕“AI是主要构建者”这一假设，重新设计你的流程、架构和组织。你不再问“AI如何帮助我们的工程师？”，而是开始问“我们如何重组一切，让AI负责构建，而工程师提供方向和判断？”

两者的区别是指数级的。

我看到一些团队声称AI优先，却仍在运行相同的冲刺周期、相同的Jira看板、相同的每日站会、相同的QA签核流程。他们只是在循环中加入了AI。他们没有重新设计这个循环。

一个常见的版本是人们所说的“氛围编码”。打开Cursor，不断提示直到某个东西能运行，提交，重复。这能产出原型。一个生产系统需要稳定、可靠、安全。你需要一个在AI编写代码时也能保证这些属性的系统。你构建的是系统。提示词是消耗品。

我们为什么必须改变#

去年，我观察了我们团队的工作方式，发现了三个会拖垮我们的瓶颈。

产品管理瓶颈

我们的产品经理花费数周时间研究、设计、制定功能规格。几十年来，产品管理一直是这样运作的。但智能体可以在两小时内实现一个功能。当构建时间从几个月缩短到几小时，长达数周的规划周期就成了制约因素。

花几个月时间思考一件事，然后用两小时构建它，这没有意义。

产品经理需要进化为具有产品思维的架构师，以迭代的速度工作，否则就需要退出构建周期。设计需要通过快速的原型-发布-测试-迭代循环来完成，而不是通过委员会评审的规格文档。

质量保证瓶颈

同样的动态。在智能体发布一个功能后，我们的QA团队花费数天测试边界情况。构建时间：两小时。测试时间：三天。

我们用AI构建的测试平台取代了手动QA，这些平台测试AI编写的代码。验证必须与实现保持相同的速度。否则，你只是在旧瓶颈下游十英尺处建立了一个新瓶颈。

人员规模瓶颈

我们的竞争对手有100倍甚至更多的人在做类似的工作。我们只有25人。我们无法通过招聘来达到同等水平。我们必须通过重新设计来达到目标。

有三个系统需要AI贯穿其中：我们如何设计产品、如何实现产品、如何测试产品。如果其中任何一个环节保持手动，它就会制约整个流程。

大胆的决定：统一架构#

我必须先修复代码库。

我们旧的架构分散在多个独立的系统中。一个简单的更改可能需要触及三到四个代码仓库。从人类工程师的角度来看，这是可以管理的。但从AI智能体的角度来看，这是不透明的。智能体无法看到全貌。它无法推理跨服务的影响。它无法在本地运行集成测试。

我必须将所有代码统一到一个单一的单体代码仓库中。一个原因就是：让AI能看到一切。

这是驾驭工程原则的实践。你将系统中越多的部分纳入智能体可以检查、验证和修改的形式，你获得的杠杆作用就越大。一个碎片化的代码库对智能体是不可见的。一个统一的代码库是可读的。

我花了一周时间设计新系统：规划阶段、实现阶段、测试阶段、集成测试阶段。然后又花了一周时间，使用智能体重新架构了整个代码库。

CREAO是一个智能体平台。我们使用我们自己的智能体来重建运行智能体的平台。如果产品能构建自身，那它就成功了。

技术栈#

以下是我们使用的技术栈及其各部分的作用。

基础设施：AWS

我们在 AWS 上运行，使用自动伸缩的容器服务和断路器回滚机制。如果部署后指标下降，系统会自动回滚。

CloudWatch 是中枢神经系统。所有服务都采用结构化日志记录，设有超过 25 个警报，自动化工作流每天查询自定义指标。每一块基础设施都暴露结构化、可查询的信号。如果 AI 无法读取日志，它就无法诊断问题。

CI/CD：GitHub Actions

每个代码变更都需要通过一个六阶段流水线：

验证 CI → 构建并部署到开发环境 → 测试开发环境 → 部署到生产环境 → 测试生产环境 → 发布

每个拉取请求上的 CI 关卡强制执行类型检查、代码检查、单元和集成测试、Docker 构建、通过 Playwright 进行的端到端测试以及环境一致性检查。没有阶段是可选的。没有手动覆盖。流水线是确定性的，因此代理可以预测结果并推理故障原因。

AI 代码审查：Claude

每个拉取请求都会触发使用 Claude Opus 4.6 进行的三个并行 AI 审查流程：

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

这些是审查关卡，而非建议。它们与人工审查并行运行，能够大规模地发现人工遗漏的问题。当你每天部署八次时，没有人工审查员能够持续关注每一个 PR。

工程师还可以在任何 GitHub Issue 或 PR 中标记 @claude，以获取实施计划、调试会话或代码分析。代理可以看到整个单体仓库。上下文在对话间保持连贯。

自愈反馈循环

这是核心部分。

每天 UTC 时间上午 9:00，一个自动化健康工作流会运行。Claude Sonnet 4.6 查询 CloudWatch，分析所有服务中的错误模式，并生成一份执行健康摘要，通过 Microsoft Teams 发送给团队。无需任何人请求。

一小时后，分类引擎运行。它从 CloudWatch 和 Sentry 中聚类生产错误，根据九个严重性维度对每个聚类进行评分，并在 Linear 中自动生成调查工单。每个工单都包含示例日志、受影响的用户、受影响的端点以及建议的调查路径。

系统会进行去重。如果已有一个开放的问题涵盖了相同的错误模式，它会更新该问题。如果之前已关闭的问题再次出现，它会检测到回归并重新打开。

当工程师推送修复时，同一流水线会处理它。三个 Claude 审查流程评估该 PR。CI 进行验证。六阶段部署流水线通过开发和生产环境进行升级，并在每个阶段进行测试。部署后，分类引擎重新检查 CloudWatch。如果原始错误已解决，Linear 工单会自动关闭。

每个工具处理一个阶段。没有工具试图做所有事情。每日循环创建了一个自愈循环，错误被检测、分类、修复和验证，而人工干预最少。

我曾告诉一位来自 Business Insider 的记者：“AI 将负责 PR，而人类只需要审查是否存在任何风险。”

功能开关与支持性技术栈

Statsig 处理功能开关。每个功能都在一个开关后发布。发布模式是：为团队启用，然后逐步进行百分比发布，最后完全发布或终止。终止开关可以立即关闭一个功能，无需重新部署。如果一个功能导致指标下降，我们会在几小时内撤回它。有问题的功能在发布的同一天就会被终止。A/B 测试通过同一系统运行。

Graphite 管理 PR 分支：合并队列会变基到主分支，重新运行 CI，仅在通过时合并。堆叠式 PR 允许在高吞吐量下进行增量审查。

Sentry 报告所有服务中的结构化异常，分类引擎将其与 CloudWatch 合并，以实现跨工具的上下文关联。Linear 是面向人类的层面：自动创建的工单带有严重性评分、示例日志和建议的调查路径。去重机制防止了噪音。后续验证会自动关闭已解决的问题。

一个功能如何从想法走向生产#

新功能路径

架构师将任务定义为包含代码库上下文、目标和约束的结构化提示。
一个代理分解任务，规划实现，编写代码，并生成自己的测试。
打开一个 PR。三个 Claude 审查流程对其进行评估。人工审查员检查战略风险，而非逐行正确性。
CI 验证：类型检查、代码检查、单元测试、集成测试、端到端测试。
Graphite 的合并队列进行变基，重新运行 CI，如果通过则合并。
六阶段部署流水线通过开发和生产环境进行升级，并在每个阶段进行测试。
功能开关为团队开启。逐步进行百分比发布。监控指标。
如果出现任何问题，可使用终止开关。对于严重问题，断路器会自动回滚。

Bug 修复路径

CloudWatch 和 Sentry 检测到错误。
Claude 分类引擎评估严重性，创建一个包含完整调查上下文的 Linear 工单。
工程师进行调查。AI 已经完成了诊断。工程师验证并推送修复。
相同的审查、CI、部署和监控流水线。
分类引擎重新验证。如果问题已解决，工单自动关闭。

两条路径使用相同的流水线。一个系统。一个标准。

成果#

在 14 天的时间里，我们平均每天进行 3 到 8 次生产部署。在我们旧的模式下，那整整两周的时间甚至无法完成一次生产发布。

有问题的功能在发布的同一天就会被撤回。新功能在构思的当天就能上线。A/B 测试实时验证影响。

人们以为我们是在用质量换取速度。但用户参与度上升了。支付转化率上升了。我们产出的结果比以前更好，因为反馈循环更紧密了。当你每天发布时，你学到的东西比每月发布时更多。

新的工程组织架构#

将存在两种类型的工程师。

架构师

一到两个人。他们设计标准操作程序，用以教导AI如何工作。他们构建测试基础设施、集成系统、问题分类系统。他们决定架构和系统边界。他们定义对于智能体而言，什么是“好”的。

这个角色需要深刻的批判性思维。你批判AI。你不盲从它。当智能体提出一个计划时，架构师要找出其中的漏洞。它遗漏了哪些故障模式？它越过了哪些安全边界？它在积累哪些技术债务？

我拥有物理学博士学位。我的博士经历教会我最有用的一件事就是如何质疑假设、压力测试论点，并寻找缺失的部分。批判AI的能力将比产出代码的能力更有价值。

这也是最难填补的角色。

操作员

其他所有人。工作内容很重要。但结构不同。

AI向人类分配任务。问题分类系统发现一个Bug，创建工单，呈现诊断结果，并将其分配给合适的人。这个人进行调查、验证并批准修复方案。AI创建PR。人类审查其中是否存在风险。

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

谁适应得最快

我注意到一个出乎意料的模式。初级工程师比高级工程师适应得更快。

传统实践较少的初级工程师感到被赋能。他们获得了能放大其影响力的工具。他们没有需要忘却的、积累了十年的习惯。

拥有深厚传统实践的高级工程师适应起来最困难。他们两个月的工作量，AI可能在一小时内就能完成。在花费数年时间构建了一套稀缺技能之后，这是很难接受的事情。

我不是在做出评判。我只是在描述我的观察。在这场转型中，适应能力比积累的技能更重要。

人性化的一面#

管理职能的瓦解

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

今天：低于10%。

传统的CTO模式要求赋能团队进行架构工作、培训他们、委派任务。但如果系统只需要一两个架构师，我需要首先自己来做。我从管理转向了构建。我大多数日子从早上9点编码到凌晨3点。我设计系统的SOP和架构。我维护着这个“缰绳”。

压力更大了。但我享受构建的过程，而不是对齐的过程。

更少的争论，更好的关系

我与联合创始人和工程师的关系比以前更好了。

在转型之前，我与团队的大部分互动都是对齐会议。讨论权衡、辩论优先级、就技术决策产生分歧。这些对话在传统模式中是必要的。但它们也令人疲惫。

现在我仍然与团队交流。我们谈论其他事情。非工作话题、随意的交谈、外出活动。我们相处得更好，因为我们不再为那些可以由我们的系统轻松完成的工作而争论。

不确定性是真实存在的

我不会假装每个人都很开心。

当我停止每天与人们交谈时，一些团队成员感到了不确定性。CTO不和我说话意味着什么？在这个新世界里，我的价值是什么？这些都是合理的担忧。

有些人花更多时间争论AI是否能做他们的工作，而不是实际去做工作。转型期会带来焦虑。对此我没有一个完美的答案。

但我有一个原则：我们不会因为工程师引入了一个生产环境Bug而解雇他。我们会改进审查流程、加强测试、增加防护栏。这同样适用于AI。如果AI犯了错误，我们就构建更好的验证机制、更清晰的约束、更强的可观测性。

超越工程领域#

我看到其他公司采用AI优先的工程模式，却让其他所有环节保持手动。

如果工程部门能在几小时内交付功能，但市场营销部门需要一周时间来宣布它们，那么市场营销就成了瓶颈。如果产品团队仍然运行月度规划周期，那么规划就成了瓶颈。

在CREAO，我们将AI原生运营推向了每个职能：

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

工程、产品、市场营销和增长在一个AI原生工作流中运行。如果一个职能以智能体速度运行，而另一个以人类速度运行，那么以人类速度运行的职能就会制约一切。

这意味着什么#

对于工程师

你的价值正从代码产出转向决策质量。快速编写代码的能力每个月都在贬值。评估、批判和指导AI的能力则越来越有价值。

产品感或品味很重要。你能看着一个生成的UI，在用户告诉你之前就知道它是错的吗？你能看着一个架构提案，发现智能体遗漏的故障模式吗？

我告诉我们19岁的实习生：训练批判性思维。学习评估论点、发现漏洞、质疑假设。学习什么是好的设计。这些技能会产生复利效应。

对于CTO和创始人

如果你的产品管理流程耗时比构建时间长，就从那里开始。

在扩展智能体之前，先构建测试框架。没有快速验证的快速AI，就是快速积累的技术债务。

从一位架构师开始。由一个人构建系统并证明其可行。在系统运行后，再将其他人纳入操作员角色。

将AI原生理念推向每个职能。

预计会遇到阻力。有些人会反对。

对于行业

OpenAI、Anthropic以及多个独立团队都趋同于相同的原则：结构化上下文、专业化智能体、持久化记忆和执行循环。框架工程正在成为一种标准。

模型能力是驱动这一切的时钟。我将CREAO的整个转变归因于过去两个月。Opus 4.5做不到Opus 4.6能做的事。下一代模型将进一步加速这一进程。

我相信单人公司将变得普遍。如果一个架构师加上智能体可以做100个人的工作，许多公司将不再需要第二名员工。

我们尚在早期#

我交谈过的大多数创始人和工程师仍然以传统方式运作。有些人考虑进行转变。很少有人已经做到了。

一位记者朋友告诉我，她采访过大约五个人关于这个话题。她说我们比任何人都走得更远：“我认为没有人像你们这样彻底重建了整个工作流程。”

任何团队都可以使用现有的工具做到这一点。我们的技术栈中没有任何东西是专有的。

竞争优势在于围绕这些工具重新设计一切的决策，以及承担相应成本的意愿。成本是真实存在的：员工的不确定性、CTO每天工作18小时、高级工程师质疑自身价值、旧系统已去而新系统尚未被证实的为期两周的过渡期。

我们承担了这些成本。两个月后，数据说明了一切。

我们构建了一个智能体平台。我们是用智能体来构建它的。