TL;DR：原本只是发一篇文章，却花了三小时，还撞出一连串系统问题：bot commit 让三个镜像对不齐、自动翻译盖掉人工翻译、首页缓存卡住新文章、不同 AI 窗口之间出现规范漂移。最讽刺的是，每个元件都在「正确」运作。真正需要修复的，不是把自动化拆掉，而是给每个自动化一份所有参与者都读得到的契约：触发条件、副作用、opt-out 标记、查证入口，四项缺一不可。而契约背后还有一个更根本的问题：未来的工作风险，不是自动化坏掉，而是自动化全都正常运作，却没有人知道它们彼此正在影响什么。

昨天深夜，我发了一篇文章。

四个语言版本的档案，十分钟就放好了。封面图生成、确认、定稿，顺利。然后我按下 push。接下来的三个小时，我都在跟自己的系统搏斗。

不是跟 bug 搏斗。三个小时里，我没有修到任何一个坏掉的东西。SEO bot 正确地登录了新网址，翻译 bot 正确地翻译了文章，缓存正确地缓存了页面，排程脚本正确地记录了数据。每一个元件，拿出来单独检查，都在做它该做的事。

但合在一起，它们一起让我吃了一记回马枪。

我原本只是想测试一个新的发布流程，最后却发现，自己其实站在一场工作方式变革的门口。

测试的是工具，撞上的是新的工作秩序

过去这段时间，我试着把几个 AI 协作工具接进自己的工作流程。表面上只是测试工具，实际上我碰到的是另一个更深的问题：当需求、资料、画面、测试与修正都开始由 AI 介入时，人真正要管理的，已经不是单一任务，而是一整套新的工作秩序。

一开始，我以为 AI 只是帮我补上几段程序、提交几次 commit，或整理一些重复性的工作。但做着做着，我开始意识到，AI 并不是单纯加速原本的流程，而是在迫使我重新理解「流程本身」。

接下来的六个坑，就是这堂课的学费。其中四个最有代表性，值得逐一解剖；其余两个较偏操作层，最后也归入同一个问题：自动化没有被写成所有参与者都读得到的契约。

为什么 push 完，三个镜像永远对不齐？

先交代背景。这个网站经历过一次 GitHub 帐号无预警停权，那之后我把 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 在边缘节点缓存每一页 HTML，存活二十四小时，而且 cache key 带了一个版本号后缀。版本号不变，缓存就不变；因为 key 跟网址长得不一样，连 zone purge 都比对不到它。

设计这个机制的人，也就是几周前的我自己（透过某个 AI 窗口），在程序代码注解里写得清清楚楚：「内容更新后 bump 版本号来清缓存」。但这句话只活在程序代码注解里，从来没有进入发文流程的检查清单。于是「部署成功」和「读者看得到」之间，隔了一道谁也想不起来的墙。

为什么每个 AI 窗口拿到的规范都不一样？

前三个坑修完，我以为结束了。直到我回头检查「为什么这些坑会存在」，才挖到第四层：规范漂移。

我的工作方式是多个 AI 窗口并行：有的负责写作、有的负责工程、有的负责侦察，各自载入同一份写作规范作为开工前提。这套一个人带四个 AI 窗口的治理架构，我之前写过。当一个产品开始进入真实运作，问题就不再只是「能不能做出来」，而是不同任务如何被拆解、交付、回收与再判断。某些 AI 负责文件，某些 AI 负责界面，某些 AI 负责测试与回馈；人则退到更高的位置，开始扮演架构设计者与判断者。

问题在于：那份规范有好几个副本。repo 里的正本、文件镜像、还有桌面应用程序载入用的副本。正本升级了，副本不一定跟上；更要命的是，文件里宣称「副本会自动同步」，但实际去翻 git hook，那条自动同步的线，写好了，从来没接上。

也就是说：规范文件本身，犯了它想要防止的错。它描述了一个不存在的自动化，而每个读到它的 AI 窗口，都以为同步会自己发生。

地图与疆域的关系在这里彻底反转。不是地图跟不上疆域，是地图宣称疆域长什么样子，然后所有人照着地图走，走进了疆域里根本没有的桥。

在人类团队里，一份过期文件的杀伤力有限：新人照着做，撞墙，问一句，有人纠正，错误就停在那里。但在 AI 协作的工作流里，文件就是 agent 的行动依据。错误的文件不是静态错误，它会成为下一轮自动化行动的共同来源。每个窗口都照着同一张错的地图行动，没有人会撞墙后回头发问，错误不会被稀释，只会被忠实地同步执行。这已经不是文件管理问题，而是 AI 协作时代的知识治理问题：当 agent 依据过期规范行动时，文件本身就是系统风险。

韧性的第二课：自动化需要契约

第一次写韧性工程，是 GitHub 停权教我的：不要让单一平台掌握你的命脉。那是韧性的第一课：冗余。

这次的第二课完全不同。出手的不是平台，是我自己建的东西。六个坑没有一个来自外部依赖，全部来自「我建了自动化，然后忘记告诉所有参与者」。参与者包括未来的我，和替我工作的每一个 AI 窗口。前面没展开的那两个操作层小坑，拆到最后也是同一句话：有人改了系统的行为，却没有人更新所有参与者读到的那份说明。

这时我才真正感受到，AI 带来的不是工具升级，而是「分工逻辑」的重组。过去我们问的是：谁来做？现在我们问的是：哪一段交给 AI？哪一段仍然必须由人判断？哪一段需要保留主权？

修复清单其实很短。每个自动化补一份契约，写进所有窗口开工都会载入的共享文件，内容四项：

它什么时候动：push 之后？commit 讯息含特定字眼？每十分钟？ 它会动什么：改哪些档案、追加什么 commit、清哪层缓存。 怎么让它这次别动：[skip-translate] 这类 opt-out 标记，没有就补。 事后去哪查证：log 路径、版本号、manifest，出事时三分钟内能确认它动过没有。

这四项合起来，就是一份最小可用的自动化契约。它不是事故后的个人笔记，而是一套可以直接搬进任何团队的 workflow governance，搭配两条执行纪律：新的自动化上线，契约没写齐就不准接进管线；契约一旦修改，所有参与者（人与 AI）开工加载的文件必须同步更新。团队规模不是门槛。只要系统里有两个以上的参与者会动到同一份状态，这份契约就该存在。

当 Google 这类大型平台开始把 postmortem 文件、AI 协作流程与开发系统整合在一起，我们看到的不是单一产品功能，而是一种新的组织形态正在成形。AI 开始不只是协助工程师，而是进入组织的记忆、修复、回馈与决策回路之中。一人公司只是把这个趋势压缩到极限：没有「另一个值班的人」可以咎责，所有的坑都是自己埋的，所有的修复也都直接变成下一个窗口的开工规范。你写下的每一条教训，第二天就会被某个窗口载入、执行、验证。postmortem 的投资报酬率，反而比团队更高。

未来的团队边界，可能不再只由人员编制决定，而是由人、模型、资料、流程与权限共同构成。产品也不再只是被开发出来的物件，而是一个持续学习、修正与演化的系统。

交出去的是任务，还是判断权？

契约解决的是「看不见」的问题。但这三个小时还留下一个更深的问题，契约解决不了。

当我们把 prompt 丢出去，看似只是发出一个指令，其实是在把一部分判断权交给系统。这里真正值得思考的，不是 AI 能不能完成任务，而是我们是否知道自己交出了什么。

这次实作给我最大的提醒是：AI 不只是替人完成工作，它正在进入人的思考前段。它不只回应需求，也开始影响我们如何描述问题、切分任务、设定优先顺序，以及理解一个产品该如何被完成。

因此，真正的问题或许不是 AI 会不会取代人，而是人会不会在追求效率的过程中，逐步放弃自己的判断位置。当工具变得越来越像器官，我们就必须重新确认：这个器官是服务于我，还是我正在成为某个系统的延伸？

这里我想给一条具体的判断标准，不只是比喻：当一个系统开始自行触发、自行改写状态，并且影响下一轮决策时，它就不再只是工具，而是进入了治理范围。锤子不会在半夜自己动工，但会自己翻译、自己追加 commit、自己决定首页该长什么样的系统会。前者只需要保养，后者需要契约、权限与问责。这条线划在哪里，决定了你对系统的态度：线的这一边，你是使用者；线的那一边，你是治理者。

这也回到我前一天才写过的问题：AI 到底只是外部工具，还是正在成为我们工作生命体中的一个器官？如果它只是工具，人仍然是主体；但如果它成为器官，我们就必须问清楚，这个生命体到底由谁来支配。

所以，这件事表面上是科技问题，深层其实是治理问题。AI 的关键不只在模型能力，而在于权限、资料、流程、责任与主体性如何被重新安排。

会反作用的，都是活的

三小时的混战结束后，我重新看了一眼这个系统：会自己长 commit 的 repo、会自己翻译的管线、会自己记帐的排程、会在边缘节点记住每一页的缓存。

它确实越来越像个活物。而活物就是这样：它不会等你下指令才动，它有自己的节奏、自己的反射、自己的新陈代谢。你喂养它、扩充它，总有一天它的行为超出你的地图，然后在某个深夜，给你一记反作用，提醒你：该更新地图了。

我会继续往这个方向探索，因为我越来越确定，这不是一场单纯的效率革命，而是一场工作文明的改写。真正重要的，不是我们用了多少 AI 工具，而是我们是否还能在 AI 逐步成为器官的时代，保有人的主体性、判断力与治理能力。

说到底，未来的工作风险，不是自动化坏掉，而是自动化全都正常运作，却没有人知道它们彼此正在影响什么。坏掉的东西会报错、会留下痕迹、会逼你停下来修；正常运作的东西不会，它们只会安静地叠加，直到某个深夜一起现形。

吃了一记回马枪，不是失败，而是系统演化的必然。错误会继续出现，也不可怕；《老子》说「祸兮福之所倚，福兮祸之所伏」是对的。真正重要的，是让每一次错误都留下痕迹、推动修正，让地图更准、契约更清楚，也让下一轮迭代比上一轮更成熟。