怎么把6周一次版本更新提升到1天8次部署？从用 AI 到 AI 优先

技术人生黄勇

发布于 2026-04-17 15:55:01

1760

文章被收录于专栏：技术人生黄勇技术人生黄勇

AI 优先的意思是：围绕「AI 是主要构建者」这个前提，重新设计你的流程、架构和组织。

当我看到一家25人公司分享如何通过AI重构，实现从六周一个版本到一天八次更新，忽然想起前两天一个 AI 产品经理的面试。

"你了解 LangChain 这类框架的具体实现吗？"

"不了解，我现在不写代码，也不学框架了。

因为我发现，现在效率的瓶颈在我的人脑的思考输出，而不是具体学习某一类框架，或者是查看 AI 写的代码。

我一年前还这么想。但是现在不这么做了，而是考虑怎么让 AI 做得更好。"

面试官说："那还面试还有甚么？"

可能没把后面一句话：”那你就是只会用 AI “说出来。

我当时觉得，现在我的日常就是这么做的，是不是错了？

其实没有，因为这个 AI 是个新事物，提供它的人、使用它的人，都在适应它。

现实中，不同的人对 AI 能力的认知出现了非常大的偏差。

这也很正常，AI 在短短 2～3 年迅猛发展。多数人可能还停留在豆包的使用体验。

编程方面，多数还普遍在 AI 辅助的阶段。

今天看到这篇文章，我才发现：

我并没有完全把 AI 优先贯彻到日常工作中，而是比辅助略进一步的阶段。

真正的 AI 优先 什么样？看看这个团队的实践。

他们做到了什么

CREAO 是一个智能体平台，25 名员工，10 名工程师。

他们 99% 的生产代码由 AI 编写。

无独有偶，OpenAI 公司的一个产品开发过程也是这样：全部代码由 AI 生成。

这篇文章有介绍：AI 不是在抢我的工作：Harness 正在重构软件工程｜让 Agent 完成任何复杂任务。

上周二，他们上午 10 点发布了一个新功能，中午开始 A/B 测试，下午 3 点因为数据说"不"就把它下掉了。

下午 5 点，他们发布了一个更好的版本。

三个月前，这样一个完整的迭代周期需要六周。

AI 辅助 vs AI 优先

大多数公司是把 AI 拼接到现有流程上的。

工程师打开 Cursor，PM 用 ChatGPT 起草需求文档，QA 试着用 AI 生成测试用例。工作流没有变。效率提升了 10% 到 20%。

结构上没有任何改变。

这叫 AI 辅助。

AI 优先的意思是：你围绕「AI 是主要构建者」这个前提，重新设计你的流程、架构和组织。

你不再问「AI 怎么帮助我们的工程师？」，而是问「怎样重构一切，让 AI 来负责构建，工程师负责方向和判断？」

两者之间的差距，是乘数级别的。

我看到很多团队声称自己 AI 优先，却还在跑一样的 Sprint 周期，用一样的 Jira 看板，开一样的周会，走一样的 QA 审批流程。

他们把 AI 加进了循环里，却没有重新设计这个循环。

还有一种常见形态，就是人们说的氛围编程（vibe coding）：

打开 Cursor，一直 prompt 到能跑，提交，重复。

这只能造出原型。

生产系统需要稳定、可靠、安全。

你需要一套系统，在 AI 写代码的情况下，仍然能保证生产系统可用。

系统是你手工搭建出来的。

那些 prompt 是一次性的，并不能形成循环，不能离开你自动运转。

他们怎么改的：统一架构

他们做了一个大胆决定：把所有代码统一到一个叫 Monorepo 的单体代码库里。

原因只有一个——让 AI 能看到一切。

这就是 Harness 工程原则在实践中的体现。

你把越多的系统拉入一种智能体能检查、验证和修改的形态，你获得的杠杆就越大。

一个碎片化的代码库，对智能体是不可见的。

一个统一的代码库，才是可读的。

他们花了一周时间设计新系统：规划阶段、实现阶段、测试阶段、集成测试阶段。

然后又花了一周，用智能体完成整个代码库的重构。

他们公司的产品 CREAO 是一个智能体平台。

他们用自己的智能体，重建了运行这些智能体的平台。

如果产品能构建自己，说明它跑通了。

他们怎么改的：自愈循环

这是整个系统的核心。

每天早上 9:00 UTC，一个自动化健康工作流运行。

AI 查询 CloudWatch，分析所有服务的错误模式，生成一份管理层健康摘要，通过 Microsoft Teams 推送给团队。

这都是自动化运行的。

一小时后，分诊引擎运行。

它对 CloudWatch 和 Sentry 中的生产错误进行聚类，按九个严重性维度对每个簇打分，并自动生成排查工单。

每张工单包含日志样本、受影响用户、受影响端点以及建议的排查路径。

系统会自动去重。

如果某个开放工单已覆盖相同的错误模式，它会更新该工单；

如果一个已关闭的问题复现，它会检测到回归并重新打开。

工程师推送修复代码后，同一套流水线继续接管。

三轮 AI 审查评估 PR，CI 验证，六阶段部署流水线在开发和生产环境逐级推进，每个阶段都有测试。

部署完成后，分诊引擎重新检查 CloudWatch。

如果原始错误已消除，工单自动关闭。

每个工具负责一个阶段，没有工具试图包揽一切。

每日循环构成了一个自愈闭环：错误被检测到、分类、修复、验证，人工介入降至最低。

他们怎么改的：工程师角色分化

工程师将分化为两种。

架构师（一到两个人）：他们设计教会 AI 如何工作的 SOP（标准操作规程）。

他们搭建测试基础设施、集成系统、分诊系统。

他们决定架构和系统边界，定义对智能体而言「好」是什么样的。

这个角色需要深度的批判性思维。

你是去批判 AI 的，不是跟着 AI 走的。

当智能体提出一个方案，架构师要找出漏洞：它遗漏了哪些故障模式？它越过了哪些安全边界？它在积累什么样的技术债？

批判 AI 的能力，将比生产代码的能力更有价值。

这也是最难招到人的角色。

执行者（其他所有人）：这些工作很重要，但结构不同了。

AI 给人分配任务。

分诊系统发现 bug，创建工单，浮出诊断结果，并分配给合适的人。

那个人去排查、验证，批准修复方案。

AI 提 PR，人类审查是否存在风险。

这些任务是 bug 排查、UI 精调、CSS 修改、PR 审查、结果验证。

它们需要技能和专注力，但不需要旧模式所要求的架构推理能力。

他们怎么改的：超越工程

我看到其他公司采用了 AI 优先工程，却让其他一切照旧。

如果工程能在几小时内发布功能，但市场营销需要一周才能发出公告，市场营销就是瓶颈。

如果产品团队还在跑月度规划周期，规划就是瓶颈。

在 CREAO，他们把 AI 原生运营推进到了每一个职能：

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

工程、产品、市场营销、增长，运行在一套 AI 原生工作流里。

如果一个职能以智能体速度运行，另一个以人类速度运行，人类速度那个就会卡住一切。

结果

在 14 天里，他们平均每天完成 3 到 8 次生产部署。

按他们以前的模式，整个两周时间，可能连一次生产发布都交付不了。

有问题的功能，当天发出当天就下线。

新功能，从想出来到上线，当天完成。

A/B 测试实时验证影响。

人们以为他们是用质量换速度。

但用户参与度上去了，付款转化率上去了。

他们产出了比以前更好的结果——因为反馈循环更紧了。

每天发布，比每月发布，能学到的东西多得多。

我的差距

对照他们的做法，我看到了自己的差距。

我以为自己是 AI-first，但其实只是 AI 辅助的略进一步。

我还在用旧的思维模式：我来规划 → AI 来执行 → 我来检查。

真正的 AI 优先应该是：

我来定义方向和约束 → AI 来规划和执行 → 系统来自动验证 → 我来处理异常和边界。

我还没有把日常工作流完全围绕 AI 来设计。

我还没有搭建起"让 AI 能看到一切"的上下文基础设施。

我还没有构建自愈循环。

怎么办

从今天开始，围绕"AI 是主要构建者"，重新设计我的日常工作。

日常任务、文章创作、代码开发、知识管理，都可以按着这个思路来改造。

先把目前代码开发项目，按 Harness 原则重新组织：

然后我去阅读它产生的这些文档，进行执行前的修正，然后在这个框架执行后，再查看什么没有按预想的要求进行，进行修正，直至它能自动工作。

AI 优先不是能力问题，是认知问题。

你的工作，是 AI 辅助，还是 AI 优先？欢迎评论区留言

-END-

为什么你的“人工智能优先”战略可能是错误的：https://x.com/intuitiveml/status/2043545596699750791