AI 把开发加速之后，发布不能还靠人肉兜底
现在很多工程师、产品经理、创业者都已经在重度使用 AI。
写代码、改需求、补测试、查资料、做 review、生成文档，这些环节都已经被 AI 明显加速了。一个人一天能推进的事情，比过去多很多。
但一个新的瓶颈也随之出现：开发被 AI 加速了，发布却还停留在人肉兜底时代。
这很危险。
因为发布不是开发流程的尾巴。发布是产品真正进入用户世界的边界。前面 90% 的开发过程已经变成 AI-native，最后 10% 的发布如果还靠人记上下文、对清单、盯日志、手动验收，就会成为整个系统里最慢、最脆弱、最消耗注意力的部分。
我的发布面，已经不适合人肉盯
很多人理解发布，是把一个 Web 服务部署到线上。
我的发布不是这样。
我的一次发布可能同时覆盖多个仓库、CLI、技能/插件、官网、安装链路、文档、真实用户验收，还要区分开源和闭源部分。
这类系统最麻烦的地方，不是某一步特别难，而是它们之间有太多“应该顺手确认一下”的关系。
代码更新了，CLI 包可能没跟上。
技能/插件变了，官网展示可能没更新。
文档写了新能力，安装链路可能还是旧的。
开源仓库发了，闭源部分的依赖关系可能没同步。
发布命令成功了，但真实用户路径可能没有跑通。
这种发布面下，靠人脑记住全部关系是不现实的。更准确地说：如果一个发布系统还需要我记住这些关系，它就还没有被设计好。
为什么我没有选择“随时发布”
有些团队会采用极高频的随时发布。
一个小改动合并了，就立刻上线。一天发布几十次、几百次都很正常。这个模式本身没有问题，甚至在很多场景下非常先进。
但它成立有一个前提：发布面足够窄，回滚足够容易。
比如一个纯 Web 服务，发布对象主要是线上服务。出了问题，可以快速回滚到上一个版本；用户侧没有太多本地状态，也没有太多已经分发出去、难以收回的内容。这个时候，高频发布的风险是可控的。
但我的发布面不是这样。
尤其是我们运营的开源 skills，一旦发布出去，用户侧可能已经安装、复制、引用、集成。它不像一个 Web 服务那样，服务器回滚一下，所有用户立刻回到旧版本。
有些内容一旦进入用户侧，回滚成本就会明显变高。
所以我没有追求“有一点改动就立刻发布”。对我来说，更合理的节奏是每天进入发布两次。
这个频率足够高，可以让改动不过夜、不堆积；同时又足够收束，可以让 AI 在每次发布前后完整跑完测试、验收和对齐检查。
发布频率不应该是一种信仰。不是越快越高级，也不是越慢越稳。真正应该看的，是三件事：
- 发布面有多宽
- 失败后能不能快速回滚
- 用户侧是否会留下难以撤回的状态
如果只是一个窄 Web 服务，随时发布很合理。
如果发布对象包含 CLI、插件、文档、开源内容、用户本地安装链路，那么发布就不能只看“能不能上线”，还要看“上线之后能不能收回来”。
我现在只看 AI 的测试报告
我现在一般每天进入发布两次。
但我并不会在每次发布里重新检查所有细节。
我的注意力边界已经非常明确：我只看 AI 的测试报告。
AI 会自动整理本次发布涉及哪些变化，覆盖哪些仓库和模块，开源与闭源部分是否对齐，相关测试是否通过，文档和安装链路是否一致，发布前真实端到端请求是否跑通。
如果测试报告通过，我就让 AI 自动继续推进流水线。
发布前测试、发布动作、发布后测试，也都会自动触发 AI 去执行真实端到端验证。不是 mock 一下，也不是在纸面上说“应该可以”，而是尽可能用真实业务请求走真实用户路径。
发布后，我看的仍然不是“命令成功了吗”，而是 AI 给出的验收结论：
线上版本是否正确。
安装链路是否可用。
关键能力是否能从用户视角跑通。
除此之外，我基本不关注。
不关注具体命令怎么跑。
不关注哪一步该先做。
不关注哪个仓库该怎么对齐。
不关注文档和官网该怎么核对。
这些事情如果还要我操心，就说明流水线没有真正接管发布。
在我的工作里，发布相关注意力大概从 20% 被压到了 5%。这不是因为我不重视发布，而是因为我不再让自己参与那些低价值的发布细节。
一键发布不是按钮，而是注意力边界
很多人理解的一键发布，是“点一下按钮，代码上线”。
我理解的一键发布不是这个。
真正的一键发布，是一条清晰的注意力边界：按钮之前，系统已经把该验证的东西验证完；按钮之后，系统继续把该验收的东西验收完。人只需要在少数节点看结论、做决定。
所以一键发布不是减少检查，而是减少人类亲自参与检查。
不是把风险藏起来，而是把风险整理成报告。
不是让发布变得随便，而是让发布不再依赖人的临场认真。
这件事很关键。因为人类的认真是有额度的。
一天发布一次时，你可能还能认真看 checklist。一天发布两次、三次，甚至更多时，人工确认很容易变成机械动作。表面上每一步都有人点头，实际上没有人真的有精力重新理解全局。
这时候，人工流程反而会制造一种虚假的安全感。