# 我的自动化全都运作正常，然后它们一起让我吃了一记回马枪 > 发一篇文章，照理三十分钟，实际花了三小时。过程撞出六个系统问题：bot commit 让三镜像永远对不齐、自动翻译盖掉人工翻译、文章上线了首页却不知道、每个 AI 窗口拿到的规范各不相同。最讽刺的是：每一个组件都在正确运作。这是一份一人公司的韧性工程 postmortem：当 AI 与自动化开始介入需求、数据、界面与测试，人真正要管理的已经不是单一任务，而是一整套新的工作秩序，以及自己还握着多少判断权。 - Author: Paul Kuo（郭曜郎） - Date: 2026-06-04 - Pillar: 智能与秩序 / Intelligence & Order - Tags: 韧性工程, 自动化治理, 多代理协作, 判断权, AI 主体性, postmortem, 一人公司 - Canonical: https://paulkuo.tw/zh-cn/articles/automation-bites-back/ - Language: Simplified Chinese (简体中文) - Translation: AI-translated from the zh-Hant (Traditional Chinese) original - Original (zh-Hant): https://paulkuo.tw/articles/automation-bites-back.md - Site index for LLMs: https://paulkuo.tw/llms.txt --- > **TL;DR**：原本只是发一篇文章，却花了三小时，还撞出一连串系统问题：bot commit 让三个镜像对不齐、自动翻译盖掉人工翻译、首页缓存卡住新文章、不同 AI 窗口之间出现规范漂移。最讽刺的是，每个组件都在「正确」运作。真正需要修复的，不是把自动化拆掉，而是给每个自动化一份所有参与者都读得到的契约：触发条件、副作用、opt-out 标记、查证入口，四项缺一不可。而契约背后还有一个更根本的问题：未来的工作风险，不是自动化坏掉，而是自动化全都正常运作，却没有人知道它们彼此正在影响什么。
▶ 听摘要
AI 合成语音・作者本人声线克隆
昨天深夜，我发了一篇文章。 四个语言版本的文件，十分钟就放好了。封面图生成、确认、定稿，顺利。然后我按下 push。接下来的三个小时，我都在跟自己的系统搏斗。 不是跟 bug 搏斗。三个小时里，我没有修到任何一个坏掉的东西。SEO bot 正确地登录了新网址，翻译 bot 正确地翻译了文章，缓存正确地缓存了页面，排程脚本正确地记录了数据。每一个组件，拿出来单独检查，都在做它该做的事。 但合在一起，它们一起让我吃了一记回马枪。 我原本只是想测试一个新的发布流程，最后却发现，自己其实站在一场工作方式变革的门口。 ## 测试的是工具，撞上的是新的工作秩序 过去这段时间，我试着把几个 AI 协作工具接进自己的工作流程。表面上只是测试工具，实际上我碰到的是另一个更深的问题：当需求、数据、界面、测试与修正都开始由 AI 介入时，人真正要管理的，已经不是单一任务，而是一整套新的工作秩序。 一开始，我以为 AI 只是帮我补上几段代码、提交几次 commit，或整理一些重复性的工作。但做着做着，我开始意识到，AI 并不是单纯加速原本的流程，而是在迫使我重新理解「流程本身」。 接下来的六个坑，就是这堂课的学费。其中四个最有代表性，值得逐一解剖；其余两个较偏操作层，最后也归入同一个问题：自动化没有被写成所有参与者都读得到的契约。 ## 为什么 push 完，三个镜像永远对不齐？ 先交代背景。这个网站经历过[一次 GitHub 帐号无预警停权](/zh-cn/articles/resilience-engineering-after-github-suspend/)，那之后我把 repo 铺成三镜像：Codeberg、GitLab、GitHub 对等并存，本地 git 是唯一事实来源。前一天，GitHub 恢复了，三镜像加本地端的部署系统刚接回来。而我是在发文的当下，才真正体会到这个新系统的脾气。 文章 push 上去之后，GitHub 端的自动化开始工作：一个 bot 把四语版网址登录进 SEO 索引清单，追加一个 commit；另一个 bot 产出社群贴文素材，又追加一个 commit；然后是一个自动 merge。结果就是：我每 push 一次，GitHub 就比另外两个镜像多出一两个 commit。 我的第一反应是把它们追平。错了。force-push 把 bot 的 commit 盖掉，下一轮它又重新追加，于是再盖、再追加，标准的打地鼠。打了两轮我才停下来想：bot 不是干扰，它在替我工作，它的 commit 是工作成果。正确的姿势是 `fetch` 加 fast-forward，把它的成果吸收进本地，再把另外两个镜像补齐。 这个坑的本质：**我建立了一个会自己长 commit 的系统，但我的肌肉记忆还停留在「远端只有我会动」的时代。** ## 自动翻译为什么盖掉了人工翻译？ 第二记回马枪，来得更深。 这篇文章的英文、日文、简体版，是事前人工打磨过的：用语、语感、在地化都调过。我把四个文件放好、push。几分钟后，GitHub 端的自动翻译管线醒来，发现翻译记录里没有这个新文章的条目，于是忠实地执行任务：重新翻译三个语言版本，盖掉我放上去的文件。 更有意思的是质量方向。比对之后发现，机器重翻的简体版反而在地化倒退了：人工版写「进化生物学」「集群」，是大陆读者的惯用语；机器版写「演化生物学」「丛集」，那是台湾用语直接转字。自动化不只盖掉了人工成果，还盖出了一个更差的版本。 修复本身不难：恢复文件、在 commit 消息加上 `[skip-translate]` 标记、把翻译记录的哈希值对齐，让管线知道「这篇已经翻好了，别动」。真正的教训在前面：**这条管线有 opt-out 机制，但知道它存在的只有管线自己。** 我（以及替我工作的每个 AI 窗口）的操作手册里，根本没有这一条。 ## 文章上线了，首页为什么不知道？ 第三记，来自缓存。 文章页面四个语言版本全部回 200，标题正确，封面正常。我以为收工了。然后发现首页的「最新思考」区块，还停在上一篇文章。 排查的过程像剥洋葱。先猜 CDN 缓存，用 Cloudflare 的 API 对首页网址做 purge，成功，没效。再看响应标头，`cf-cache-status: DYNAMIC`，根本不是 CDN 层在缓存。最后翻到网站自己的 middleware：它用 [Workers Cache API](https://developers.cloudflare.com/workers/runtime-apis/cache/) 在边缘节点缓存每一页 HTML，存活二十四小时，而且 cache key 带了一个版本号后缀。版本号不变，缓存就不变；因为 key 跟网址长得不一样，连 zone purge 都比对不到它。 设计这个机制的人，也就是几周前的我自己（通过某个 AI 窗口），在代码注释里写得清清楚楚：「内容更新后 bump 版本号来清缓存」。但这句话只活在代码注释里，从来没有进入发文流程的检查清单。于是「部署成功」和「读者看得到」之间，隔了一道谁也想不起来的墙。 ## 为什么每个 AI 窗口拿到的规范都不一样？ 前三个坑修完，我以为结束了。直到我回头检查「为什么这些坑会存在」，才挖到第四层：规范漂移。 我的工作方式是多个 AI 窗口并行：有的负责写作、有的负责工程、有的负责侦察，各自载入同一份写作规范作为开工前提。这套[一个人带四个 AI 窗口的治理架构](/zh-cn/articles/governance-harness-engineering/)，我之前写过。当一个产品开始进入真实运作，问题就不再只是「能不能做出来」，而是不同任务如何被拆解、交付、回收与再判断。某些 AI 负责文件，某些 AI 负责界面，某些 AI 负责测试与反馈；人则退到更高的位置，开始扮演架构设计者与判断者。 问题在于：那份规范有好几个副本。repo 里的正本、文件镜像、还有桌面应用程序载入用的副本。正本升级了，副本不一定跟上；更要命的是，文件里宣称「副本会自动同步」，但实际去翻 git hook，那条自动同步的线，写好了，从来没接上。 也就是说：规范文件本身，犯了它想要防止的错。它描述了一个不存在的自动化，而每个读到它的 AI 窗口，都以为同步会自己发生。 地图与疆域的关系在这里彻底反转。不是地图跟不上疆域，是地图宣称疆域长什么样子，然后所有人照着地图走，走进了疆域里根本没有的桥。 在人类团队里，一份过期文件的杀伤力有限：新人照着做，撞墙，问一句，有人纠正，错误就停在那里。但在 AI 协作的工作流里，文件就是 agent 的行动依据。错误的文件不是静态错误，它会成为下一轮自动化行动的共同来源。每个窗口都照着同一张错的地图行动，没有人会撞墙后回头发问，错误不会被稀释，只会被忠实地同步执行。这已经不是文件管理问题，而是 AI 协作时代的知识治理问题：当 agent 依据过期规范行动时，文件本身就是系统风险。 ## 韧性的第二课：自动化需要契约 第一次写[韧性工程](/zh-cn/articles/resilience-engineering-after-github-suspend/)，是 GitHub 停权教我的：不要让单一平台掌握你的命脉。那是韧性的第一课：冗余。 这次的第二课完全不同。出手的不是平台，是我自己建的东西。六个坑没有一个来自外部依赖，全部来自「我建了自动化，然后忘记告诉所有参与者」。参与者包括未来的我，和替我工作的每一个 AI 窗口。前面没展开的那两个操作层小坑，拆到最后也是同一句话：有人改了系统的行为，却没有人更新所有参与者读到的那份说明。 这时我才真正感受到，AI 带来的不是工具升级，而是「分工逻辑」的重组。过去我们问的是：谁来做？现在我们问的是：哪一段交给 AI？哪一段仍然必须由人判断？哪一段需要保留主权？ 修复清单其实很短。每个自动化补一份契约，写进所有窗口开工都会载入的共享文件，内容四项： **它什么时候动**：push 之后？commit 消息含特定字眼？每十分钟？ **它会动什么**：改哪些文件、追加什么 commit、清哪层缓存。 **怎么让它这次别动**：`[skip-translate]` 这类 opt-out 标记，没有就补。 **事后去哪查证**：log 路径、版本号、manifest，出事时三分钟内能确认它动过没有。 这四项合起来，就是一份最小可用的自动化契约。它不是事故后的个人笔记，而是一套可以直接搬进任何团队的 workflow governance，搭配两条执行纪律：新的自动化上线，契约没写齐就不准接进管线；契约一旦修改，所有参与者（人与 AI）开工加载的文件必须同步更新。团队规模不是门槛。只要系统里有两个以上的参与者会动到同一份状态，这份契约就该存在。 当 Google 这类大型平台开始把 [postmortem 文件](https://sre.google/sre-book/postmortem-culture/)、AI 协作流程与开发系统整合在一起，我们看到的不是单一产品功能，而是一种新的组织形态正在成形。AI 开始不只是协助工程师，而是进入组织的记忆、修复、反馈与决策回路之中。一人公司只是把这个趋势压缩到极限：没有「另一个值班的人」可以咎责，所有的坑都是自己埋的，所有的修复也都直接变成下一个窗口的开工规范。你写下的每一条教训，第二天就会被某个窗口载入、执行、验证。postmortem 的投资报酬率，反而比团队更高。 未来的团队边界，可能不再只由人员编制决定，而是由人、模型、数据、流程与权限共同构成。产品也不再只是被开发出来的对象，而是一个持续学习、修正与演化的系统。 ## 交出去的是任务，还是判断权？ 契约解决的是「看不见」的问题。但这三个小时还留下一个更深的问题，契约解决不了。 当我们把 prompt 丢出去，看似只是发出一个指令，其实是在把一部分判断权交给系统。这里真正值得思考的，不是 AI 能不能完成任务，而是我们是否知道自己交出了什么。 这次实作给我最大的提醒是：AI 不只是替人完成工作，它正在进入人的思考前段。它不只回应需求，也开始影响我们如何描述问题、切分任务、设定优先顺序，以及理解一个产品该如何被完成。 因此，真正的问题或许不是 AI 会不会取代人，而是人会不会在追求效率的过程中，逐步放弃自己的判断位置。当工具变得越来越像器官，我们就必须重新确认：这个器官是服务于我，还是我正在成为某个系统的延伸？ 这里我想给一条具体的判断标准，不只是比喻：当一个系统开始自行触发、自行改写状态，并且影响下一轮决策时，它就不再只是工具，而是进入了治理范围。锤子不会在半夜自己动工，但会自己翻译、自己追加 commit、自己决定首页该长什么样的系统会。前者只需要保养，后者需要契约、权限与问责。这条线划在哪里，决定了你对系统的态度：线的这一边，你是使用者；线的那一边，你是治理者。 这也回到我前一天才写过的问题：[AI 到底只是外部工具，还是正在成为我们工作生命体中的一个器官](/zh-cn/articles/organism-or-organ/)？如果它只是工具，人仍然是主体；但如果它成为器官，我们就必须问清楚，这个生命体到底由谁来支配。 所以，这件事表面上是科技问题，深层其实是治理问题。AI 的关键不只在模型能力，而在于权限、数据、流程、责任与主体性如何被重新安排。 ## 会反作用的，都是活的 三小时的混战结束后，我重新看了一眼这个系统：会自己长 commit 的 repo、会自己翻译的管线、会自己记帐的排程、会在边缘节点记住每一页的缓存。 它确实越来越像个活物。而活物就是这样：它不会等你下指令才动，它有自己的节奏、自己的反射、自己的新陈代谢。你喂养它、扩充它，总有一天它的行为超出你的地图，然后在某个深夜，给你一记反作用，提醒你：该更新地图了。 我会继续往这个方向探索，因为我越来越确定，这不是一场单纯的效率革命，而是一场工作文明的改写。真正重要的，不是我们用了多少 AI 工具，而是我们是否还能在 AI 逐步成为器官的时代，保有人的主体性、判断力与治理能力。 说到底，未来的工作风险，不是自动化坏掉，而是自动化全都正常运作，却没有人知道它们彼此正在影响什么。坏掉的东西会报错、会留下痕迹、会逼你停下来修；正常运作的东西不会，它们只会安静地叠加，直到某个深夜一起现形。 吃了一记回马枪，不是失败，而是系统演化的必然。错误会继续出现，也不可怕；《老子》说「祸兮福之所倚，福兮祸之所伏」是对的。真正重要的，是让每一次错误都留下痕迹、推动修正，让地图更准、契约更清楚，也让下一轮迭代比上一轮更成熟。