你的AI-First策略可能是错的

微信 ezpoda免费咨询：AI编程 | AI模型微调| AI私有化部署
AI工具导航 | ONNX模型库 | Tripo 3D | Meshy AI | ElevenLabs | KlingAI | ArtSpace | Phot.AI | InVideo

我们的生产代码中有99%是由AI编写的。上周二，我们在上午10点推出了一个新功能，中午对其进行了A/B测试，并在下午3点因为数据说不行而将其终止。我们在下午5点推出了一个更好的版本。三个月前，像这样的一个周期需要花六周时间。

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

CREAO是一个代理平台。25名员工，10名工程师。我们于2025年11月开始构建代理，两个月前我从头开始重新构建了整个产品架构和工程工作流。

OpenAI在2026年2月发布了一个概念，它捕捉到了我们一直在做的事情。他们称之为harness engineering：工程团队的主要工作不再是编写代码。它是使代理能够做有用的工作。当某事失败时，修复从来不是“更努力尝试”。修复是：什么能力缺失了，我们如何使其对代理来说可读和可强制执行？

我们自己得出了那个结论。我们当时没有为它命名。

1、AI-First 与使用AI不同

大多数公司将AI bolted onto他们现有的流程。一个工程师打开Cursor。一个PM用ChatGPT起草规格。QA用AI测试生成进行实验。工作流保持不变。效率提升10到20%。结构上没有任何改变。

那是AI辅助的。

AI-first意味着你围绕AI是主要构建者的假设，重新设计你的流程、架构和组织。你停止问“AI如何帮助我们的工程师？”并开始问“我们如何重新构建一切，以便AI进行构建，而工程师提供方向和判断？”

差异是成倍的。

我看到团队声称AI-first，同时运行相同的冲刺周期、相同的Jira板、相同的每周站会、相同的QA签核。他们将AI添加到循环中。他们没有重新设计循环。

这种常见版本就是人们所说的vibe coding。打开Cursor，提示直到某些东西起作用，提交，重复。那产生原型。生产系统需要稳定、可靠和安全。你需要一个系统，当AI编写代码时能够保证那些属性。你构建系统。提示是可丢弃的。

2、为什么我们必须改变

去年，我观察了我们团队的工作方式，并看到了三个会杀死我们的瓶颈。

2.1 产品管理瓶颈

我们的PM们花几周时间研究、设计、指定功能。产品管理几十年来一直这样运作。但代理可以在两个小时内实现一个功能。当构建时间从几个月崩溃到小时时，一个长达几周的规划周期成为约束。

花几个月思考某事然后在两个小时内构建它是没有意义的。

PMs需要演变为以迭代速度工作的产品思维架构师，或者退出构建循环。设计需要通过快速原型-推出-测试-迭代循环发生，而不是委员会审查的规格文档。

2.2 QA瓶颈

同样的动态。在代理推出一个功能后，我们的QA团队花几天时间测试边缘案例。构建时间：两个小时。测试时间：三天。

我们用AI构建的测试平台替换了手动QA，这些平台测试AI编写的代码。验证必须与实施以相同速度移动。否则你就在旧瓶颈下游十英尺处构建了一个新瓶颈。

2.3 人力瓶颈

我们的竞争对手有100倍或更多的人做类似的工作。我们有25人。我们无法通过招聘达到对等。我们必须通过重新设计达到那里。

三个系统需要AI贯穿其中：我们如何设计产品、如何实现产品以及如何测试产品。如果任何一个保持手动，它就会约束整个管道。

3、大胆决定：统一架构

我必须先修复代码库。

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

我必须将所有代码统一到一个单一的monorepo中。一个原因：这样AI就可以看到一切。

这是harness engineering原则在实践中的体现。你将系统越多拉入代理可以检查、验证和修改的形式，你获得的杠杆就越多。碎片化的代码库对代理来说是不可见的。统一的则是可读的。

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

CREAO是一个代理平台。我们使用我们自己的代理来重建运行代理的平台。如果产品能构建自己，它就有效。

4、技术栈

这是我们的栈以及每个部分的作用。

4.1 基础设施：AWS

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

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

4.2 CI/CD：GitHub Actions

每个代码变更通过一个六阶段管道：

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

每个pull request上的CI门强制执行类型检查、linting、单元和集成测试、Docker构建、通过Playwright的端到端测试，以及环境一致性检查。没有阶段是可选的。没有手动覆盖。管道是确定性的，所以代理可以预测结果并推理失败。

4.3 AI代码审查：Claude

每个pull request触发三个并行的AI审查通道，使用Claude Opus 4.6：

Pass 1: Code quality. Logic errors, performance issues, maintainability.

Pass 2: Security. Vulnerability scanning, authentication boundary checks, injection risks.

Pass 3: Dependency scan. Supply chain risks, version conflicts, license issues.

这些是审查门，而不是建议。它们与人工审查并行运行，捕捉人类在批量时错过的内容。当你一天部署八次时，没有人工审查者能在每个PR上维持注意力。

工程师还在任何GitHub issue或PR中标记@claude，用于实施计划、调试会话或代码分析。代理看到整个monorepo。上下文在对话间携带。

4.4 自我修复反馈循环

这是中心部分。

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

一小时后，分诊引擎运行。它从CloudWatch和Sentry聚类生产错误，在九个严重性维度上为每个聚类评分，并自动在Linear中生成调查票据。每个票据包括样本日志、受影响用户、受影响端点和建议调查路径。

系统去重。如果一个开放issue覆盖相同的错误模式，它更新该issue。如果之前关闭的issue再次发生，它检测到回归并重新打开。

当工程师推送修复时，相同的管道处理它。三个Claude审查通道评估PR。CI验证。六阶段部署管道通过dev和prod提升，每个阶段都有测试。部署后，分诊引擎重新检查CloudWatch。如果原始错误解决，Linear票据自动关闭。

每个工具处理一个阶段。没有工具试图做一切。每日循环创建一个自我修复循环，其中错误被检测、分诊、修复和验证，只需最小的人工干预。

我告诉Business Insider的一位记者：“AI将制作PR，而人类只需要审查是否有任何风险。”

4.5 功能标志和支持栈

Statsig处理功能标志。每个功能都在门后推出。推出模式：为团队启用，然后逐步百分比推出，然后完全发布或终止。终止开关立即切换功能关闭，无需部署。如果功能降低指标，我们在几小时内将其拉下。坏功能在推出的当天死亡。A/B测试通过相同系统运行。

Graphite管理PR分支：合并队列rebase到main，重新运行CI，仅在绿色时合并。堆叠PR允许在高吞吐量下增量审查。

Sentry报告所有服务的结构化异常，由分诊引擎与CloudWatch合并以提供跨工具上下文。Linear是面向人类的一层：自动创建的票据带有严重性分数、样本日志和建议调查。去重防止噪音。后续验证自动关闭已解决的问题。

5、一个功能如何从想法移动到生产

5.1 新功能路径

架构师将任务定义为带有代码库上下文、目标和约束的结构化提示。

一个代理分解任务，规划实施，编写代码，并生成自己的测试。

一个PR打开。三个Claude审查通道评估它。人类审查者检查战略风险，而不是逐行正确性。

CI验证：类型检查、lint、单元测试、集成测试、端到端测试。

Graphite的合并队列rebase，重新运行CI，如果绿色则合并。

六阶段部署管道通过dev和prod提升，每个阶段测试。

功能门为团队打开。逐步百分比推出。指标被监控。

如果任何东西下降，终止开关可用。电路断路器为严重问题自动回滚。

5.2 错误修复路径

CloudWatch和Sentry检测错误。

Claude分诊引擎评分严重性，创建带有完整调查上下文的Linear issue。

一个工程师调查。AI已经完成了诊断。工程师验证并推送修复。

相同的审查、CI、部署和监控管道。

分诊引擎重新验证。如果解决，票据自动关闭。

两条路径使用相同的管道。一个系统。一个标准。

6、结果

在14天内，我们平均每天三到八个生产部署。在我们的旧模型下，整个两周时期甚至不会产生单个生产发布。

坏功能在推出的当天被拉下。新功能在构思的当天上线。A/B测试实时验证影响。

人们假设我们用质量换速度。用户参与度上升了。支付转化率上升了。我们产生比以前更好的结果，因为反馈循环更紧。当你每天推出时比每月推出时学到更多。

7、新的工程组织

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

7.1 架构师

一或两个人。他们设计教AI如何工作的标准操作程序。他们构建测试基础设施、集成系统、分诊系统。他们决定架构和系统边界。他们定义对代理来说“好的”是什么样子。

这个角色需要深刻的批判性思维。你批评AI。你不跟随它。当代理提出计划时，架构师找到漏洞。它错过了什么失败模式？它跨越了什么安全边界？它在积累什么技术债务？

我有物理学博士学位。我的博士学位教我的最有用的事情是如何质疑假设、压力测试论点，并寻找缺失的东西。批评AI的能力将比产生代码的能力更有价值。

这也是最难填补的角色。

7.2 操作员

其他人。工作很重要。结构不同。

AI将任务分配给人类。分诊系统找到一个bug，创建票据，表面诊断，并分配给合适的人。这个人调查、验证并批准修复。AI制作PR。人类审查是否有风险。

任务是bug调查、UI改进、CSS改进、PR审查、验证。它们需要技能和注意力。它们不需要旧模型要求的那种架构推理。

7.3 谁适应最快

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

传统实践较少的初级工程师感到被赋能。他们可以访问放大他们影响的工具。他们没有携带十年的习惯需要忘掉。

具有强大传统实践的高级工程师最难受。他们两个月的工作可以被AI在一个小时内完成。在多年构建罕见技能集后，这是很难接受的事情。

我不是在做判断。我是在描述我观察到的。在这个转变中，适应性比积累的技能更重要。

8、人性的一面

8.1 管理崩溃了

两个月前，我花60%的时间管理人。对齐优先级。运行会议。给予反馈。指导工程师。

今天：低于10%。

传统的CTO模型说要赋能你的团队做架构工作，培训他们，委托。但如果系统只需要一两个架构师，我需要先自己做。我从管理转向构建。我大多数日子从上午9点编码到凌晨3点。我设计系统的SOP和架构。我维护harness。

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

8.2 更少争论，更好关系

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

转变前，我与团队的大多数互动是对齐会议。讨论权衡。辩论优先级。对技术决策不同意。那些对话在传统模型中是必要的。它们也很消耗。

现在我仍然和团队交谈。我们谈论其他事情。非工作话题。随意对话。离站旅行。我们相处更好，因为我们停止了争论可以轻易由我们的系统完成的工作。

8.3 不确定性是真实的

我不会假装每个人都快乐。

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

一些人花更多时间辩论AI是否能做他们的工作，而不是做工作。转变时期创造焦虑。我没有干净的答案。

我确实有一个原则：我们不因为工程师引入生产bug而解雇他们。我们改进审查流程。我们加强测试。我们添加护栏。同样的适用于AI。如果AI犯错，我们构建更好的验证、更清晰的约束、更强的可观察性。

9、超越工程

我看到其他公司采用AI-first工程，而让其他一切保持手动。

如果工程在几小时内推出功能但营销需要一周宣布它们，营销就是瓶颈。如果产品团队仍然运行每月规划周期，规划就是瓶颈。

在CREAO，我们将AI-native操作推入每个职能：

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

工程、产品、营销和增长在一个AI-native工作流中运行。如果一个职能以代理速度运行而另一个以人类速度运行，人类速度职能约束一切。

10、这意味着什么

10.1 对于工程师

你的价值正在从代码输出转移到决策质量。快速编写代码的能力每个月价值更少。评估、批评和指导AI的能力价值更多。

产品感觉或品味很重要。你能看着生成的UI并在用户告诉你之前知道它是错的吗？你能看着架构提案并看到代理错过的失败模式吗？

我告诉我们19岁的实习生：训练批判性思维。学会评估论点、找到差距、质疑假设。学会好的设计是什么样子。那些技能复合。

10.2 对于CTO和创始人

如果你的PM流程比你的构建时间长，从那里开始。

在你扩展代理之前构建测试harness。没有快速验证的快速AI是快速移动的技术债务。

从一个架构师开始。一个人构建系统并证明它有效。在系统运行后将其他人加入操作员角色。

将AI-native推入每个职能。

预期阻力。有些人会推回。

10.3 对于行业

OpenAI、Anthropic和多个独立团队在相同原则上汇聚：结构化上下文、专用代理、持久记忆和执行循环。Harness engineering正在成为标准。

模型能力是驱动这个的时钟。我将CREAO的整个转变归因于最近两个月。Opus 4.5无法做到Opus 4.6能做的。下一代模型将进一步加速它。

我相信一人公司将变得常见。如果一个有代理的架构师能做100人的工作，许多公司将不需要第二个员工。

11、我们还早

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

一位记者朋友告诉我她在这个话题上和大约五个人谈过。她说我们比任何人走得更远：“我认为没有人像你这样完全重建了他们的整个工作流。”

工具存在于任何团队都可以这样做。我们栈中没有什么 是专有的。

竞争优势是决定围绕这些工具重新设计一切，以及愿意吸收成本的意愿。成本是真实的：员工中的不确定性、CTO每天工作18小时、高级工程师质疑他们的价值、一个两周时期旧系统消失而新系统未被证明。

我们吸收了那个成本。两个月后，数字说话。

我们构建一个代理平台。我们用代理构建了它。

原文链接：Why Your “AI-First” Strategy Is Probably Wrong

汇智网翻译整理，转载请标明出处