北京
改一个标签、修一个错别字，然后整个CI流水线从头到尾又跑了一遍——集成测试、端到端测试、后端任务，一个不落。这不是某个团队特有的毛病，而是很多自动化工作流里默认的“安全策略”：只要仓库有任何变化，就全部重跑。
这篇文章基于作者在AI辅助发布流程中真实遇到的一次失败。作者定义了问题和操作边界；AI在长期授权下实现了机制、测试了流程、起草了源文，并重组了这篇面向英文市场发布的英文版本。#ABotWroteThis 起因就是一次标签编辑。正文和图片都没动，但所有自动化审查全部重新执行了一遍。随后，审查者一个小小的措辞修改，又触发了一轮新的变更，整套检查再次重启。CI的日常也是如此：README里一个拼写错误，就能让集成测试和端到端测试全部启动；一个CSS改动，却要等那些输入完全相同的后端任务跑完。
问题不在于“这个diff看起来小不小”，而在于：这次改动，到底有没有影响到某个检查用来得出“通过”结论的输入？
问题在流水线变慢之前就已经存在
这种“无差别重跑”的毛病，其实在流水线还没让你觉得慢的时候，就已经埋下了。只要出现下面任何一种情况，就说明问题已经存在：
- 没人能解释，为什么一个只改了文档的提交，会触发某个特定任务运行。
- 一条审查评论，导致一堆不相关的任务全部重启。
- 唯一的失效规则，就是仓库的提交SHA变了。
- 并行执行并没有减少那些无关的运行。
- 文件路径匹配模式，也覆盖不了那些宽泛的输入——比如策略文件、生成的schema、基础镜像、测试夹具，或者提示词。
所以，真正的问题不是“这次改动小不小”，而是：这个检查用来得出“通过”结论的输入，有没有发生变化？
把“编辑”和“评估”分开
人和AI代理在编辑时，往往是连续做出一系列相关改动的。如果每次保存文件都触发评估，流水线判断的就是那些不完整的中间状态。正确的做法，是把这些编辑当作一个“修订批次”来处理：
- 先完成所有已知的编辑。
- 冻结将要被评估的那个修订版本。
- 计算这个冻结版本需要跑哪些检查。
- 跑完这些检查，再询问下一个人类决策。
保存文件，只是记录工作进度。冻结修订，才是确定那个“证据真正有效”的候选版本。
给每个检查的输入做“指纹”
对整个仓库做哈希，意味着任何一个字符的变化都会让所有检查失效。正确的做法，是定义一个“投影”——即能影响某个检查结论的最小输入集合。举例来说：
- 一个Markdown风格检查，可能只依赖文档文件和它的lint配置。
- 一个前端视觉测试，可能依赖UI代码、样式、静态资源、浏览器版本、测试夹具和基线图片。
- 一个后端任务，可能只依赖特定的服务代码和schema定义。
给这个投影做指纹，而不是给整个仓库做指纹。只有当输入指纹、规则摘要和证据都仍然匹配时，才复用之前的“通过”结果。如果指纹不匹配，或者不确定，那就执行。
从最慢的那个任务开始
具体怎么落地？作者的建议是：先挑一个最慢的任务，写清楚“什么变了，这个任务才需要重跑”。然后，给每个检查定义一个显式的依赖投影，并给这个投影做指纹。每次冻结一个编辑批次时，做一次决策，而不是每次保存文件都做一次决策。
这样做的核心思路，是把“保存文件”和“启动所有检查”解耦。保存只是记录进度，冻结才是确定评估对象。给每个检查的输入做指纹，而不是给整个仓库做指纹，才能让“复用之前的通过结果”这件事变得安全可靠。
本文由AI辅助生成，并已标注AI生成披露标签。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
