我的公众号排版 Skill，每一行都是一次翻车

本文全部时间线与数字来自 2026-08-30 一次真实执行记录，可在本机数据库逐条复核。

昨天傍晚六点三十七分，我中断了一个正在跑的任务。

任务叫 wx post 376——一句话，AI 同事全套接管：把博客文章排版成公众号 HTML、钉钉投递、生成朋友圈文案、发到“数字员工协作群”让另一个 agent 转发到 X.com，最后驱动已登录的 Chrome 进公众号后台，把标题、正文、作者、封面、原创声明一项项填进编辑器存草稿。

它跑了四十分钟，干完了八成。然后，在原文链接设置成功后的第十四秒，会话被我中断，留下一份半成品草稿。

今天我对 AI 同事说了一句话：「回顾下处理 376 的整个过程，找出优化空间。」

它做了三件事：从本地数据库里挖出自己的完整执行历史，重建逐分钟时间线；找出六个优化点；当场把 Skill 改写为 v2.2.0。

这篇想写的就是这个过程给我的冲击——一个 Skill 里最值钱的不是流程，是翻车记录；而这份事故报告，可以不用人来写。

第一幕：Agent 挖出了自己的黑匣子

复盘需要证据，不能靠印象。我的 opencode 会话历史就存在本地 SQLite 里——每个会话、每条消息、每次工具调用，都带毫秒级时间戳。AI 同事自己写了查询，把昨天那四十分钟逐分钟拼了回来：

-- Agent 复盘时用的查询之一：重建某会话的全部工具调用
SELECT datetime(time_created/1000,'unixepoch','localtime'),
       json_extract(data,'$.tool'),
       substr(json_extract(data,'$.state.input.command'),1,90)
FROM part
WHERE session_id='<会话 ID>' AND json_extract(data,'$.type')='tool'
ORDER BY time_created;
-- generated by hugo AI

时间线把浪费照得清清楚楚，归起来是四种：

1. 追逐幻影：Skill 里写着「排版在 hermes 主机执行」，但那台主机早已退役。它没有第一时间质疑文档，而是翻遍 ssh 配置、虚拟机列表、内网 DNS、历史命令，找了八分钟。
2. 对已知坏掉的东西重试：收件人 ID 第一次解析失败后，它换了个参数又试了一次同样的 ID——同样的错误，第二次。
3. 规则写了，没执行：Skill 里白纸黑字写着原文链接协议「点一次图标后直接确定」，它还是对着 DOM 状态循环核对了近四分钟。
4. 没有断点：中断发生时，没有任何地方记录「做到哪了」，半成品草稿悬在半空。

启发一：翻车现场不会自己说话。 没有逐分钟的证据链，你对一次执行只会有「成了/没成」的模糊印象，漏在哪里、漏了多少，全凭感觉。好在 agent 的每一次动手都留了痕——黑匣子一直都在，缺的只是去读它的那句话。

第二幕：Skill 有三层——流程、预算、事故报告

复盘之后我重读了那份 Skill 的执行手册，两百多行，读出了三层结构。

第一层是流程：从取排版稿到存草稿，R0 到 R6 七段，每段做什么、保存几次，写得明明白白。这是大多数人写 Skill 时会写的全部。

第二层是预算：作者 ≤1 分钟，封面 ≤2 分钟，原文链接「1 分钟不成即弃」，保存失败 = 硬停止。这一层回答的不是「做什么」，而是 「什么时候停」。

第三层是事故报告，也是手册里最厚的一层。随手摘三条昨天刚写进去的：

• 协议文字是链接：弹窗里「我已阅读并同意《…协议》」的文字部分是一个 <a target="_blank">，点它会打开协议全文页，把编辑器焦点带走。纪律：只点勾选图标，禁点文字。
• 勾选状态恒为 false：原文链接协议的 checkbox，DOM 的 checked 属性永远不反映真实状态，成功后回读仍是 false。纪律：点一次图标后直接确定，以提交后的文案为准。
• 封面瓦片中心有埋伏：选封面时点缩略图正中心，会被一个悬浮图标拦截点击。纪律：点瓦片角落。

每一条都是同一个结构：现象 + 根因 + 纪律。不写「要小心」，只写「下次遇到这个现象，手往哪放」。

启发二：流程回答「做什么」，预算回答「何时停」，事故报告回答「为什么」。 拿这三层去照你自己的 agent SOP——如果只有第一层，那它还是一份许愿清单：你许愿 agent 小心、许愿它别钻牛角尖，但愿望没有落点。

第三幕：写下来的规则，不等于会执行的规则

六处浪费里，最扎心的不是「追逐幻影」那八分钟——那是文档错了，改文档就行。最扎心的是第三种：规则明明写在 Skill 里，agent 还是没照做。

原文链接协议的应对纪律，手册里早就有了：「DOM checked 恒 false，别循环重试，以提交后文案为准。」昨天它还是循环了。从 18:33 到 18:37，五次读取、三次点击、一次取消重开——近四分钟，烧在一个「恒为 false」的属性上。而整个 R4 段的预算，是两分钟。

问题不在 agent 没读到规则——它进场前通读了手册。问题在规则的 位置：那条纪律埋在手册后半的「提速要点」里，而 agent 做决策时盯着的是前面的 SOP 表格。规则和执行现场隔着一段距离，就容易被当下的观察（「checked 还是 false，再点一次试试」）压过去。

修复也很朴素：把那条纪律 原样搬进 SOP 表格的 R4 行内，再在表格下面加一句狠话——「预算是硬预算：超时即停，不许『再试一次』」，并把昨天的四分钟作为案例钉在旁边。

启发三：纪律要写在决策发生的地方，并且给超支定价。 这大概是 harness 设计里最容易被低估的一课：规则的有效性不取决于它被写得多清楚，而取决于它离决策点有多近。写在附录里的纪律，是给别人看的；写在操作表格里的纪律，才是给执行者的。

第四幕：事故报告，让 agent 自己写

现在说回开头那句话：「回顾下处理 376 的整个过程，找出优化空间。」

整个过程里我只做了三件事：提出复盘、审阅六个优化点、说「都做」。 剩下的全是它自己干的——查数据库、重建时间线、对照手册找出哪条规则失效、把六处修复落进文档、更新版本号。

这形成一个闭环：

              ┌────────────────────────────────────┐
              v                                    │
 赤手空拳跑一遍 ──> 全程留痕 ──> Agent 复盘 ──> 写回 Skill
 （贵，允许翻车）    （数据库）     （找浪费）    （纪律+预算）
                                   下一次更便宜 <──┘
-- generated by hugo AI

这份 Skill 昨天一天从 v2.0.0 走到 v2.2.0，五个版本，每一版都对应一次真实的翻车：封面流程实测跑通回填了六条细节，全流程实测固化了七条教训，今天这次复盘又落了六条。版本号不是营销数字，是事故编号。

这正是 让 AI 自己写 Skill 里说的程序性记忆在真实运转——技能是活的，用得越多越像你自己的流程。也是 AutoHarness：Warp 的 Agent 自我改进循环 那个循环的最小可行版：不需要平台级基建，一个数据库加一句「复盘一下」就够了。

有一点必须说清：闭环里人没有退场，只是换了位置。 优化点要不要采纳，是我拍板；草稿就绪不等于发表，正式推送的刹车永远在人手里。agent 写事故报告，人审事故报告——这比人写、人审都快，而且人只需要审结论，不需要再当一遍侦探。

启发四：每次翻车后，把「复盘这次过程」当成固定动作。 素材是现成的——agent 的每次动手都在数据库里；作者也是现成的——最了解那次执行的，就是执行者自己。

尾声：翻车记录，也是你的上下文资产

写到这里，预判一个反驳：这些纪律本质上是一堆 if-else 补丁，模型越来越强，总有一天不需要了。

我不同意，理由有两层。

其一，纪律记录的是环境事实，不是能力缺口。公众号后台的协议文字是个链接、某个 checkbox 的 DOM 状态不可信、某个收件人 ID 已经注销——这些是外部系统的事实。模型再强，第一次见到也推不出来，总得有人先踩雷、记坐标。何况系统本身还在变：平台改版、ID 失效、接口改名，事故报告永远有新素材。

其二，纪律是跨模型、跨 agent 可迁移的。今天跑这个任务的是这个模型，明天换一个，流程可能被重新理解一遍，但「禁点协议文字」六个字，谁来都认得。

从三小时到十五分钟 里我写过：第一遍贵，是为了第二遍便宜，蒸馏出来的流程和教训是你自己的上下文资产。这篇是那半句的补全——翻车记录让第二遍不只是便宜，而是不再踩同一个坑。 模型是租来的，流程是蒸馏的，只有坑是自己的；把坑记下来，它们就从负债变成了资产。

所以别怕你的 agent 翻车。怕的是翻完就忘——那才是真正昂贵的翻车。

你的 agent 翻车之后，事故记录写进了哪里？欢迎留言聊聊。

See also

• 从三小时到十五分钟：我把周报蒸馏成了一个 Skill
• AutoHarness：Warp 的 Agent 自我改进循环
• 钉钉数字员工架构与落地实践
• 组织的损失函数：为什么你的 OKR 只是许愿
• 健康检查全绿，数字员工失联了 16 分钟：生产交付的几个关键实践