AI 把开发加速之后，发布不能还靠人肉兜底

AI 正在把开发速度这件事推向一个新量级。

写代码、改需求、补测试、查资料、做 review，很多环节的单点效率都上来了。以前一个人一天推进一两件事，现在能把好几个环节一起往前推。

但多数人的发布流程，还停留在手工时代。开发快了，发布慢了，这个矛盾在我自己的工作流里正变得越来越尖锐。

我逐渐意识到，当开发过程已经 AI-native，发布如果还靠人记上下文、对清单、盯日志、手动确认，它就会变成整个系统里最脆弱的瓶口。

发布是产品进入用户世界的边界。AI 带来的速度越快，这个靠人的临场认真守住的边界，风险就放大得越快。

我的发布面，已经不适合人肉盯

对我来说，一次“发布”早就不再是把一个网站部署上线那么简单。

它可能同时牵扯到多个代码仓库、一个 CLI 工具、一簇可以独立安装的技能插件、一份官网文档，以及一套必须跑通的真实用户验收流程。并且，这其中还要严格区分哪些是开源部分，哪些是闭源部分。

这种发布面，最耗人的从来不是哪一步特别难，而是那些“本该顺手确认一下”的连带关系：代码更新了，CLI 包的版本号跟上了吗？插件改了，官网的介绍还是旧的吗？文档写了新功能，安装和调用链路同步了吗？

想靠人脑在发布前记全这些关系，确保万无一失，几乎不现实。

更准确地说，如果一个发布系统还需要我在临场靠“想起来”去覆盖这些检查点，那它就还没有真正接管发布。它只是一个脆弱的脚本执行器。

为什么我没有选择“随时发布”

这自然会引出一个问题：为什么不干脆拥抱随时发布（Continuous Deployment）？一个小改动合并就立刻上线，一天发布几十上百次，用高频覆盖来降低单次风险。

这个模式在很多场景下非常先进，但它依赖一个前提：发布面足够窄，且回滚足够容易。

比如一个纯 Web 服务，发布对象主要是服务器。出了问题，快速回滚到上一个版本，所有用户几乎立刻就能回到旧版，风险是可控的。

但我的发布面不是这样。CLI 工具、开源的技能插件，一旦发布出去，用户可能已经下载、安装、复制、引用、在自己的系统里建立依赖。它不像 Web 服务，服务器回滚一下就能把变更收回来。这些已经分发到用户侧的资产，回滚成本要高得多。

所以我没有追求“有一点改动就立刻发”。对我来说，更合理的节奏是每天收束到两三次固定的发布窗口。

这个频率足够高，可以让改动不过夜、不堆积；同时又足够收束，能让 AI 在每次发布前后，都有时间完整跑完所有测试、验收和跨仓库的对齐检查。

我现在判断发布频率，主要看三件事：发布面有多宽；失败后能不能快速、无损地回滚；用户侧是否会留下难以撤回的状态。想不清楚这三点就盲目追求高频，很可能只是在用速度掩盖风险。

我现在只看 AI 的测试报告

在我的发布窗口，我并不会亲自重新检查所有细节。我给自己立了个规矩：只看 AI 生成的测试报告。

这份报告会告诉我，本次发布涉及哪些变化，覆盖哪些仓库和模块，开源与闭源部分是否对齐，相关测试是否通过，文档和安装链路是否一致，以及最重要的——发布前真实端到端业务请求是否跑通。

如果报告显示全部通过，我就授权流水线继续。如果报告里有任何一项失败，整个发布就停下。

发布之后，我盯的也不是命令本身的输出，而是 AI 跑出的线上验收结论：新版本部署好了吗？从用户的角度看，安装链路通不通？核心功能能不能真的跑起来？

人的注意力像一盏手电筒，光束很窄，一次只能照亮一小块地方。而 AI 的测试报告，则像是把整个发布现场浓缩成一张地图，让我一眼就能看到全局。除了这张图，其他地方我尽量不看。因为如果这些细节还需要我去看，就说明流水线还没能真正让人放心。

一键发布的价值在按钮之外

很多人把一键发布理解成“点一下按钮，代码就上线了”。

我以前也这么想。现在我觉得，真正的一键发布，价值不在那个按钮，而在你敢于只按那个按钮的底气。

这份底气来自按钮前后发生的一切：按钮之前，系统有没有把该验证的东西自己验证完？按钮之后，它有没有继续做线上验收？失败时，它能不能把风险整理成我能读懂的报告，而不是把一堆日志丢给我？

发布流程要减少的不是检查，而是人类亲自参与低价值检查的次数。

这件事很关键，因为人的“认真”是有额度的。一天发布一次，你可能还能认真过一遍 checklist。一天发布三五次，人工确认很容易变成机械动作。表面上每一步都有人点头，实际上没人真的有精力重新理解全局。

这时候，依赖人来把关的流程，反而会制造一种虚假的安全感。

AI-native 发布系统，应该默认由 AI 运营

在 AI-native 的工作流里，发布系统不该只是 CI/CD 的简单升级。它更像一个由 AI 参与运营的系统。

它需要知道上一个版本的真实状态，知道这次变化来自哪里，知道哪些是开源哪些是闭源，也知道官网、文档、安装链路之间如何对应。它能在发布前后主动执行检查，而不是等人想起来。

更重要的是，它要敢于失败。

仓库没对齐，就失败。安装链路没跑通，也失败。文档和实际能力不一致，照样失败。

一个好的发布系统，不追求每次都成功，而是追求每一次失败都清晰、可溯源、并且发生在造成实质破坏之前。

从人盯流程，到 AI 托管流程

过去的发布，是一个人盯人的流程。人开会，人对清单，人跑命令，人看日志，人判断有没有遗漏。

我现在想要并正在搭建的，是一个 AI 托管的流程。

AI 负责推进、检查、验证、归档、汇报。人只在系统检查全部通过后，在最终那个“是否发布”的关口介入，承担产品和风险的判断。

这对 AI 重度用户来说，不是锦上添花，而是必需品。一旦 AI 把开发速度提高了，发布如果还靠人肉兜底，就会变成整个系统里最慢、最脆弱、最消耗注意力的那个环节。

我搭建这条流水线，不是为了让发布看起来更自动化，而是为了让自己可以不再惦记发布。

让系统去记住细节，让 AI 去执行检查，让流水线去暴露失败。我的注意力只留给结论、风险和决策。这或许就是 AI native 时代，人和机器最合理的分工。