6.0
关注
AI SCORE
观点评论2026-04-13 08:00
"AI 优先"战略的工程现实：不能只有战术
宝玉 AI#AI战略#工程实践
Editor brief · 编辑速览
宝玉观点文章指出 AI 战略需要扎实的工程基础支撑。对团队决策和技术选型有启发，但缺少具体实践指引。
宝玉观点文章指出 AI 战略需要扎实的工程基础支撑。对团队决策和技术选型有启发，但缺少具体实践指引。
今天刷到《Why Your “AI-First” Strategy Is Probably Wrong》这篇文章（原文翻译放在下方）好几次，说点不一样的。与其说 AI First，不如说软件工程 First。
这篇文章表面上在讲 AI，底下讲的全是软件工程。
抛开后面关于组织和人的部分，原文前半段的重点可以简单总结如下：
AI 时代，人成了瓶颈。PM 花几周做需求，AI 两小时就能实现，PM 成了瓶颈；QA 测三天，AI 写代码只要两小时，QA 成了瓶颈；团队只有 25 个人，对手却有几百人，人力也是瓶颈。
怎么办？把人从链条里拿掉。AI 写代码、AI 审查代码、AI 跑测试、AI 部署上线、AI 监控线上状态，出了问题自动回滚。每天定时扫描日志，自动发现问题、分配任务、跟踪修复。整条流水线跑起来后，人只需要在关键节点做判断。
至于文中提到的统一代码库，只是锦上添花，和 AI First 关系不大。有当然更好，没有也有很多替代方案。
整套方案听下来逻辑自洽，效果也很漂亮：一天部署好几次，功能当天上线、当天撤掉，一切由数据说了算。
但先别急着照搬，先对照自己的情况想几件事。
第一，自动化测试。AI 改完代码，你得有办法确认它没有搞崩其他功能。测试覆盖不够的话，每次 AI 提交代码，你都得人工回归一遍，那速度根本快不起来。
第二，CI/CD 流程。从提交代码到部署上线，中间的测试、审查、发布和回滚，是不是已经全自动跑通了？这条流水线不通，AI 写得再快，代码也只能堆在那里，等人手动处理。
第三，A/B 测试和线上监控。新功能上线之后效果好不好，得有数据说话；效果不好，还得能随时关掉。没有这套机制，AI 一天产出五个功能，你都不知道哪个该留、哪个该砍。
第四，任务管理。任务得拆到合适的粒度，生命周期也得能跟踪。一个又大又模糊的任务直接丢给 AI，以现在的能力还啃不动。多个 Agent 同时工作时，谁做哪个、哪个优先、做到什么程度，这些都得有地方管理。
第五，系统架构。架构太乱，或者压根没有架构的代码，AI 维护起来和人一样头疼。上下文塞满了，还是搞不清边界在哪里，改一处崩三处。
这几条里如果有做不到的，就得靠人去补。补不上，AI First 就只是一句口号。
但假设你全都做到了，就能 AI First 了吗？
适合的场景，是以后端逻辑为主、界面不复杂的产品，比如 API 服务、数据处理平台和内部工具。功能好不好，跑一下数据就知道，不需要人去盯着每一个像素。原文里的产品就是一个 Agent 平台，本质上是后端驱动的产品，因此可以采用这套打法。
再比如早期产品快速试错。功能上线后不行就撤，用户预期原本也没那么高，AI 的速度优势可以得到充分发挥。
UI 密集的产品就不一样。自媒体天天喊前端已死，但你让 AI 做一个复杂界面试试：各种易用性问题、交互细节和视觉还原，它都搞不定。否则，马斯克靠 AI 早就不知道把 X 改版多少次了。
功能质量敏感的产品也不适合。Anthropic 和 OpenAI 不知道 AI First 吗？他们敢在 Claude Code 和 Codex 上这么搞吗？让 AI 全自动迭代自家的核心产品，用户不骂死才怪。
安全性要求高的场景同样如此。银行系统、在线交易平台，AI 写的代码一旦出错，那可不是回滚就能解决的。
AI First 的方向没有错，它代表的是一种意识转变：每做一个决策时，都想一想这件事能不能让 AI 来做；如果不能，还缺什么条件，又该怎样把条件补上。
但这种意识要真正落地，靠的不只是购买几个 AI 工具的订阅，还需要先把基础搭好。测试、CI/CD、监控、架构、任务管理，这些做扎实了，AI 的能力自然能够释放出来。做不好，加再多 AI，也只是在沙子上盖楼。
从这个角度看，AI First 的终点未必是让 AI 干所有的活，而是借着这股力量，把那些你一直想做、却没有动力去做的工程改进真正推动起来。
作者：Peter Pang
原文：Why Your “AI-First” Strategy Is Probably Wrong
我们 99% 的生产环境代码都是由 AI 编写的。上周二上午 10 点，我们上线了一项新功能，中午进行了 A/B 测试，结果下午 3 点就把它砍掉了，因为数据表现不佳。下午 5 点，我们又发布了一个优化后的版本。如果放在三个月前，这样一个完整的迭代周期至少需要六个星期。
我们能做到这一步，绝不是因为在代码编辑器里装了一个 Copilot 插件那么简单。我们彻底打破了原有的工程研发流程，并围绕 AI 进行了全面重构。我们改变了做计划、写代码、测试、部署以及团队组织的方式，甚至重塑了公司里每个人的角色。
CREAO 是一个 AI Agent 平台。公司有 25 名员工，其中 10 名是工程师。我们在 2025 年 11 月开始研发 Agent。就在两个月前，我从零开始，彻底重组了整个产品架构和工程工作流。
OpenAI 在 2026 年 2 月发布了一个新概念，完美总结了我们一直在做的事情。他们称之为脚手架工程（Harness Engineering。Harness 原意为马具或安全带，在软件工程中通常指测试支架或脚手架，这里指为 AI 提供工作环境和约束条件的系统工程）：工程团队的核心工作不再是写代码，而是赋能 Agent，让它们去完成有价值的工作。当系统出错时，解决办法绝不是“再试一次”或“再努力一点”。真正的解决思路是去问：AI 缺失了什么能力？我们该如何让这个能力对 Agent 变得清晰可见，并强制它们执行？
我们自己摸索出了这个结论，只是当时还没有一个现成的名词来定义它。
大多数公司只是把 AI 强行塞进现有的工作流里。工程师打开 Cursor 辅助写代码，产品经理用 ChatGPT 帮忙写需求文档，测试团队（QA）尝试用 AI 生成测试用例。整个工作流程还是老样子。效率确实提升了 10% 到 20%，但本质上的结构没有任何改变。
这顶多叫“AI 辅助”（AI-assisted）。
真正的“AI 优先”（AI-first），意味着你要基于“AI 是主力构建者”这一核心假设，彻底重新设计你的流程、架构和组织。你要停止问“AI 能怎样帮助我们的工程师？”，转而去问：“我们该如何重构一切，让 AI 负责构建，而工程师只负责指引方向和判断好坏？”
我看到很多团队自称“AI 优先”，却依然在运行原来的敏捷冲刺周期，用着同样的 Jira 任务看板，开着同样的每周站会，还要经过同样的 QA 验收签字流程。他们只是把 AI 强行加入了现有循环，而没有重新设计这个循环。
这种现象的一个典型表现，就是现在常说的凭感觉编程（Vibe Coding）。打开 Cursor，不断调整 prompt，直到代码能跑通，提交代码，然后不断重复。这种方式只能用来做原型验证。一个真正用于生产环境的系统，必须稳定、可靠且安全。当 AI 负责写代码时，你需要建立一个能够兜底、确保这些特性的系统。你需要构建的是系统，而那些 prompt 是用完即弃的。
去年，我仔细观察了团队的工作方式，发现了三个差点要了我们命的瓶颈。
我们的产品经理过去要花好几周时间调研、设计和详细规划产品功能。几十年来，产品管理一直都是这么运作的。但是，AI Agent 实现一个功能只需要两个小时。当开发时间从几个月被极度压缩到几个小时，长达数周的规划周期就成了最大的拖油瓶。
花几个月构思一个想法，然后只用两个小时把它做出来，这太不合逻辑了。
产品经理必须进化成具备产品思维的架构师，以快速迭代的节奏工作，否则就得退出开发环节。产品设计必须通过“快速原型—发布—测试—迭代”的循环来完成，而不是靠委员会开会评审长篇大论的需求文档。
QA 的情况如出一辙。AI Agent 花两个小时上线一个功能后，我们的 QA 团队要花好几天测试各种边缘和极端情况。开发两小时，测试三天。
于是，我们用 AI 构建的自动化测试平台取代了人工 QA，用 AI 测试 AI 写的代码。验证的速度必须赶上开发的速度。否则，你只是在距离旧瓶颈十英尺的地方，又建了一个新瓶颈而已。
我们的竞争对手有 100 倍甚至更多的人在做同样的工作，而我们只有 25 人。我们不可能靠疯狂招人来赶超他们，只能靠“重新设计”杀出一条血路。
我们需要让 AI 深度贯穿三个系统：如何设计产品、如何实现产品，以及如何测试产品。如果其中任何一个环节依然依赖纯人工，它就会拖垮整条流水线。
过去，我们的架构散落在多个独立系统中。修改一个功能，可能需要同时改动三四个代码仓库。从人类工程师的角度来看，这勉强还能应付。但从 AI Agent 的视角来看，这就像一个黑盒。Agent 看不到全貌，无法推理跨服务的连锁反应，也不能在本地运行集成测试。
我不得不把所有代码整合到一个大型代码库（Monorepo）中。原因只有一个：让 AI 能够纵览全局。
这就是脚手架工程理念在实践中的运用。你把越多部分的系统转化为 AI 可以检查、验证和修改的形态，获得的杠杆效应就越大。碎片化的代码库对 AI 是隐形的，而统一的代码库对它们来说则清晰易读。
我花了一周时间设计新系统：规划阶段、实施阶段、测试阶段和集成测试阶段。接着，我又用了一周时间，利用 Agent 帮忙重构了整个代码库。
CREAO 本身就是一个 Agent 平台。我们用自己的 Agent，重建了运行 Agent 的平台。如果一个产品能够自己构建自己，那就说明这条路走得通。
我们运行在 AWS 上，使用了自动扩缩容的容器服务和熔断回滚机制。如果部署后监控指标恶化，系统会自动回滚到上一个安全版本。
CloudWatch 是整个系统的中枢神经。所有服务都有结构化日志，设定了超过 25 个自动警报，自动化工作流每天都会查询自定义指标。每一个基础设施部件都会暴露出结构化、可查询的信号。结构化日志指按统一格式记录的日志，便于机器读取；可查询信号则是 AI 能够直接检索的关键运行数据。如果 AI 读不懂日志，它就无法诊断问题。
每一次代码修改都要经过一个死磕到底的六阶段流水线：
验证 CI → 构建并部署到开发环境 → 测试开发环境 → 部署到生产环境 → 测试生产环境 → 正式发布
每个 Pull Request（简称 PR，即提交代码变更的请求）上的把关机制，都会强制执行类型检查、代码规范检查、单元和集成测试、Docker 构建、利用 Playwright 进行的端到端测试，以及环境一致性检查。没有任何一个阶段可以跳过，也不允许人工强行开绿灯。整个流水线是绝对确定性的，这样 AI 才能预测结果，并推理出失败的原因。
每一个 PR 都会触发 Claude Opus 4.6，进行三轮并行的 AI 审查：
这些是必须通过的拦截关卡，而不只是提供建议。它们与人工审查并行运行，批量拦截人类容易遗漏的错误。当你一天要部署 8 次时，没有哪个肉眼凡胎的工程师能够对每个 PR 都保持高度专注。
工程师还可以在任何 GitHub Issue 或 PR 中 @claude，让它提供实施方案、开启调试会话或进行代码分析。AI Agent 能够看到整个 Monorepo，所有上下文在不同对话中无缝贯通。
每天早上 UTC 时间 9:00，自动化健康检查工作流准时启动。Claude Sonnet 4.6 会查询 CloudWatch，分析所有服务的错误模式，并生成一份系统健康执行摘要，发送到团队聊天群里。整个过程不需要任何人主动吩咐。
一小时后，分诊引擎启动。它会对生产环境里的错误信息进行分类和聚类，从 9 个维度评估每个问题的严重程度，并在任务管理系统中自动生成调查工单。每个工单都会附带日志样本、受影响的用户、受影响的接口以及建议的排查方向。
系统还会自动去重。如果现有工单已经涵盖了同类错误，它就会更新那个工单。如果以前解决过的问题再次出现，它会敏锐地检测到 Regression，并重新打开工单。
当工程师提交修复代码时，同一套流水线会接管一切。Claude 会进行三轮审查，CI 会进行验证。六阶段部署流水线将代码推送到各个环境并进行测试。部署完成后，分诊引擎会再次检查监控数据。如果原先的错误已经解决，工单就会自动关闭。
每个工具只负责一个阶段，没有哪个工具试图包揽一切。这个日常循环创造了一个“自愈闭环”：以最少的人工干预，完成错误的检测、分诊、修复和验证。
我曾对《商业内幕》的记者说：“AI 会负责写代码并提交，人类只需要审核其中有没有战略风险。”
我们用 Statsig 管理 Feature Flags。Feature Flags 是一种在代码中控制功能是否启用的技术，允许在不重新部署代码的情况下随时开关功能。每个新功能上线前都隐藏在开关后面。发布模式非常稳健：先对团队内部开放，然后按百分比灰度发布，最后全面开放或直接砍掉。所谓的“一键关闭”能够瞬间停用功能，根本不需要重新部署。如果一个功能导致数据指标变差，我们几个小时内就会把它撤下来。糟糕的功能会在上线当天“死掉”。A/B 测试也运行在同一套系统上。
Graphite 负责管理代码分支：合并队列会重新运行一遍验证，只有一路绿灯，代码才会被合并到主干。这让我们可以一边高频提交代码，一边有条不紊地进行审查。
Sentry 报告所有服务的结构化异常，再由分诊引擎将其与监控数据结合。Linear 则是面向人类的界面：系统会自动创建带有严重程度评分和调查建议的工单，并在后续验证通过后自动关闭。
架构师以结构化 prompt 的形式定义任务，其中包含代码库上下文、目标和约束条件。
Agent 拆解任务、规划实施方案、编写代码，并自动生成配套测试。
创建 PR。Claude 进行三轮审查。人类审查员只检查高维度风险，而不再逐行死磕代码。
流水线进行验证：类型检查、代码规范、单元测试、集成测试和端到端测试。
六阶段部署流水线将代码推送到不同环境，每个阶段都伴随着测试。
通过 Feature Flags 面向团队内部开启功能，然后逐步灰度发布，并紧盯数据指标。
一旦数据恶化，随时一键关闭。遇到严重问题时，自动触发熔断回滚。
Claude 分诊引擎评估严重程度，自动创建一个包含完整排查上下文的工单。
工程师介入调查。此时，AI 其实已经完成了诊断工作。工程师只需验证结论，并提交修复代码。
修复代码会经过同一套严格的代码审查、验证、部署和监控流水线。
分诊引擎重新进行验证。如果确认问题已经解决，工单就会自动关闭。
这两条路径使用的是完全相同的流水线。同一个系统，同一个标准。
在过去 14 天里，我们平均每天进行 3 到 8 次生产环境部署。在旧模式下，整整两周时间里，我们连一次发布都做不出来。
糟糕的功能会在上线当天被砍掉。新功能在构思出来的当天就能上线。A/B 测试能够实时验证业务效果。
很多人以为我们是在牺牲质量换取速度。恰恰相反，用户参与度上升了，付费转化率也上升了。我们做出了比以前更好的产品，因为反馈闭环变得极短。每天发布一次所能学到的东西，绝对比每个月发布一次多得多。
架构师只需要一两个人。他们设计标准作业程序，教 AI 如何工作。他们构建测试支架、集成系统和分诊网络，拍板系统架构和边界，并定义在 Agent 眼里什么才叫“好”。
这个角色需要极其深厚的批判性思维。你要做的是挑 AI 的刺，而不是盲从它。当 Agent 提出一个方案时，架构师必须能够敏锐地找到漏洞：它遗漏了哪些失效模式？越过了哪些安全边界？积累了什么技术债？
我拥有物理学博士学位。读博期间，我学到的最有用的东西，就是如何质疑假设、对论点进行压力测试，以及寻找逻辑漏洞。在未来，批评 AI 的能力将比写代码的能力更有价值。
现在是 AI 给人类分配任务。分诊系统发现一个 Bug，创建工单，给出诊断结果，然后把它分配给合适的人。人类负责调查、验证，并批准修复方案。AI 负责提交代码，人类负责审核其中有没有风险。
这些工作依然需要极高的技能和专注力，但它们不再需要旧模式下那种从头构建系统架构的推理能力。
我观察到了一个出乎意料的现象：初级工程师比资深工程师适应得更快。
没有形成传统思维定式的初级工程师感到如虎添翼。他们掌握了能够无限放大自身影响力的工具，而且没有十几年的老习惯需要破除。
而拥有丰富传统经验的资深工程师，则经历了最痛苦的挣扎。他们过去需要辛辛苦苦干两个月的工作，现在 AI 一个小时就完成了。对于那些花了好几年时间才练就一身稀缺技能的人来说，这实在是一个难以接受的暴击。
我不是在评判对错，只是在陈述我看到的现实。在这场变革中，适应能力远比过去积累的技能更重要。
两个月前，我要花 60% 的时间进行人员管理：对齐优先级、开会、提供反馈、辅导工程师。
传统的 CTO 模型告诉你，要赋能团队进行架构设计，培训他们，并把工作交接出去。但如果这个系统只需要一两个架构师，那么我就必须先亲自动手把它建起来。我从“管理者”变回了“建造者”。现在，我每天大概从早上 9 点写代码到凌晨 3 点。我设计系统的底层逻辑和架构，维护整个基础设施的脚手架。
压力更大了，但我很享受这种纯粹“建造”的快乐，而不是每天去和人“对齐”。
我和联合创始人及工程师们的关系，反而比以前更好了。
转型前，我与团队的大部分互动都发生在会议里：讨论技术取舍、争论优先级，为技术决策争得面红耳赤。在传统模式下，这些对话是必要的，但也极其耗费心神。
现在，我依然会和团队交流。我们聊工作之外的话题，轻松闲聊，或者组织团建放松。我们相处得更加融洽，因为不再为了那些现在完全可以交给系统代劳的工作而争吵。
当我不再每天找大家沟通工作时，一些团队成员感到了不安。CTO 不找我说话意味着什么？在这个新世界里，我的价值究竟在哪里？这些担忧都非常合理。
有些人在群里争论“AI 到底能不能取代我的工作”，花费的时间甚至比实际工作的时间还长。转型期不可避免地会带来焦虑，对此我也没有什么完美的安抚话语。
但我有一个原则：我们不会因为一名工程师在线上写了一个 Bug 就开除他。我们会改进审查流程、加强测试、增加护栏。对待 AI 也是一样。如果 AI 犯了错，我们就构建更好的验证机制、更清晰的约束条件，以及更强的系统可观测性。
我看到一些公司在工程研发上采用了“AI 优先”，但其他部门依然完全依赖手工作业。
如果工程师几个小时就能发布一个功能，而市场部要花一周时间发布公告，那么市场部就是新的瓶颈。如果产品团队还在以“月”为单位进行规划，那么产品规划就是瓶颈。
在 CREAO，我们把 AI 原生的运作方式推行到了所有职能部门：
工程、产品、市场和用户增长，都在同一个“AI 原生”工作流里运转。如果一个部门以 Agent 的光速运转，而另一个部门还以人类的龟速爬行，那么人类的速度就会拖慢整个公司的脚步。
你的核心价值正在从“写代码的产量”转移到“做决策的质量”。快速敲代码的能力每个月都在贬值，而评估、批判和指导 AI 的能力正在快速升值。
对产品的敏锐度和品味至关重要。你能不能扫一眼 AI 生成的 UI 界面，在用户抱怨之前，就凭直觉发现它不对劲？你能不能看一眼架构提案，就洞察 AI 遗漏的系统性风险？
我总是告诉我们 19 岁的实习生：去刻意练习批判性思维。学习评估论点、寻找逻辑漏洞、质疑那些想当然的假设。去学习什么是好的设计。这些技能自带复利效应。
如果你们规划产品功能所花的时间，比编写代码实现它所花的时间还长，就赶紧从那里开始动刀。
在大规模引入 AI Agent 之前，先建好测试脚手架。没有极速验证作为后盾的极速 AI，只会带来快速累积的技术灾难。
从一名架构师开始。找一个能够把这套系统建起来，并证明它行之有效的人。等系统跑通后，再安排其他人进入“操作员”的角色。
OpenAI、Anthropic 以及许多独立团队，都在向着相同的原则靠拢：结构化的上下文、专业化的 Agent、持久化的记忆，以及执行闭环。脚手架工程正在成为行业标配。
驱动这一切的引擎，是模型能力的进化。我把 CREAO 最近发生的所有质变，都归功于过去这两个月。Claude Opus 4.5 做不到的事情，Opus 4.6 已经能够做到。下一代模型只会让这种变革来得更加猛烈。
我相信，“一人公司”将变得非常普遍。如果一名架构师带着一群 Agent 就能完成 100 个人的工作，那么很多公司根本不需要雇用第二名员工。
我接触过的大多数创始人和工程师，依然在沿用传统模式。一部分人开始考虑转型，但真正迈出这一步的寥寥无几。
一位记者朋友告诉我，她围绕这个话题采访了大约五个人。她说我们走得比任何人都远：“我觉得没有任何人像你们一样，完完全全重构了整个工作流。”
任何团队都可以利用现有工具做到这一点。我们的技术栈中，没有任何东西是独家机密。
真正的竞争优势，在于你下定决心围绕这些工具彻底重塑一切，并愿意承受随之而来的巨大代价。这种代价是真金白银且痛彻心扉的：员工的迷茫与焦虑、CTO 每天工作 18 个小时的煎熬、资深工程师对自身价值的自我怀疑，以及旧系统已经拆毁、新系统却尚未跑通的那段令人窒息的两周真空期。
我们扛下了这些代价。两个月后，数据说明了一切。
我们构建了一个 Agent 平台，而这个平台，正是我们用 Agent 建起来的。