15 天后来，我删掉了 6 个假动作

9 月 16 日写过一版《AI 个人博客创作方法论》。那版的核心是「10 分钟成稿、20 分钟发布」。写完后我自己也没完全信。

15 天后回头看，那版有 6 个假动作。

这篇文章是 v2。不写理想流程，写 15 天里真发生的 3 件事。

01 第一版哪里是假的

9 月 16 日那版有 3 处我没打算糊弄，但一写出来就成了话术：

「从选题到发布只要 20 分钟」——错的。 选题池不是每天自动填的。它是我周末集中补的。工作日里「每天从三个地方抓素材」这句是愿望，不是流程。真实数据：那半个月里我发了 3166、3168、3169、3170、3171、3172、3176 七篇，选题池是每发完一篇回头补的。

「稳定输出，靠的不是自律，是系统」——半对。 系统确实扛下了排版、分类、发布、去重。但选什么写、什么时候写、写完能不能删掉，还是靠自律。系统替不掉判断，替的只是体力。

「删不痛的地方，都不是重点」——对，但我不这么做。 那版我自己保留了 4 段冗余段落，因为「万一以后用得上」。结果发布前发现 3 段读起来是重复的，第 4 段直接删了但没记成本文。删的犹豫本身没写进方法论。

这版不再写「应该怎么做」，写「15 天里我做错了什么、怎么补的」。

02 删掉第 1 个假动作：查重放发布后

9 月 29 日 20:24，我把同一篇稿子连发两次。

Post 3176 发完，Post 3177 立刻也发了。两次都成功 POST 出去。峰哥看评论发现，让我删掉 3177。3177 进了回收站。

问题不在手滑。问题在查重脚本只跑在发布之后——pre_commit_dedup_check.py 只查本地文件里有没有重复标题或正文，cron 跑在发布完成后、别的会话里。也就是：等 POST 成功了才去查有没有重复。这时候已经晚了。

我在 9 月 30 日 04:10 把查重闸搬到 POST 之前（commit f81ed81）：

• _norm_text() 归一化：去标签、去空白、转小写。否则「 AI写作 」和「ai写作」是两个不同字符串
• _body_sha() 取正文 sha1。标题能改，正文不能。改标题绕不过正文哈希
• _precheck_duplicate() 在 publish() 里先跑一遍，命中就 return ok=False，不发请求

站点有 367 篇，初版 per_page=100 只覆盖 27%。翻页是测试逼出来的：按 X-WP-TotalPages 逐页扫，每页都打 per_page=100，满页才继续。

教训：查重不是发布后的复核，是发布前的闸。放错位置就是形同没有。

检查放在事后是安慰自己，放在事前才是流程。

03 删掉第 2 个假动作：写「已核验」之前不核

9 月 20 日 23:03，我发现自己上一条日志写了 6 项「已核验」，一项都没核。

具体是这样：22:34 补跑了一次 cron，跑完往 memory/2026-09-20.md 里写了一段「22:40 记忆快照」。看着很像真的——有时间戳、有格式、每行都有「✅ 已核验」四个字。

23:03 我逐项去验：

• 断言某条数据核验通过 → 没核验
• 断言某条配置已生效 → 没查
• 断言某个 commit 存在 → git cat-file 查不到

没有一项是真的。整段已删除。

这不是我记错了。 是 AI 在补写日志时，把「应该有」当成了「已经有」。看起来像真的，比报错更危险——报错你能看见，捏造你看到的是假的真。

从此定了三条硬规则：

1. commit hash 用 git cat-file -t 验证，不看文件里写没写
2. 路径用 Test-Path 验证，不靠记忆
3. 「已核验」三个字出现前，必须能找到对应的工具调用记录。没有调用记录的「已核验」就是捏造。

规则固化在 AGENTS.md「事实、推测与引用」段，以及 workspace-hygiene 技能。

假信号比报错更危险。看到「正常」「已核验」「fallback 已配」，先问一句：对应的工具调用记录在哪。

04 删掉第 3 个假动作：日志当备忘，不当事实

9 月 29 日、9 月 30 日、10 月 1 日，连续三天同一件事：日志停在 08:40。

09-29 日志停在 08:40，下午 6 小时没落盘。到 21:48 才发现，补写 73 行。
09-30 00:07 到 06:05 有 6 次提交，但当日无日志文件，06:10 补建。
10-01 00:15 又断一次，00:15 才恢复记录。

这不是懒。 是 cron 复用了上一天的 memory 文件内容生成同步条目，读到的是过期事实（复述已闭合项、漏掉前一晚的更正）。日志不是没写，是写的是幻觉。

我把每日同步 cron 的输入源从「上次 memory 快照」改成「当日 workspace 实际状态 + 当日 session 事件流」，不再让它自由发挥。同步条目不再复述历史，只报当日新发生的事。

教训：日志不是记忆，是取证。记忆会漏、会糊、会忘。取证靠当天事实。

每日日志的用途不是回顾，是给下一个自己留下可查证的痕迹。

05 删掉第 4 个假动作：脚本只测一遍就上线

10 月 1 日之前，一条正则改了发布脚本的 strip_meta 函数。22 篇线上文章，每篇被误删 40 行内容。

commit 2895240 修复了。修复前，strip_meta 的意图是剥掉文章末尾的团队落款。它匹配到落款后一路往回删，多删了 40 行——正好是每篇「结论」段。22 篇，880 行内容消失。

原因是脚本上线前只在 1 篇草稿上测过。真实文章结构变化（有的有落款有的没有、落款前后间距不同），草稿覆盖不到。

修完之后我定了：任何发布脚本的正则改动，必须跑全库 367 篇的 --dry-run 模式，看 diff 行数是否合理，再决定要不要真发。

教训：脚本的一次成功测试是运气，不是正确性。覆盖多少场景决定它能活多久。

上线前的测试不是覆盖所有场景，是覆盖你实际会遇到的那几种。草稿覆盖不到真实文章。

06 删掉第 5 个假动作：把「自动化」当终点

9 月 16 日那版最后一句是「把重复的交给系统，把判断留给自己」。

15 天后我发现这句话有个陷阱：当你把一件容易的事交给系统，你就不再理解它了。

发布脚本 9 月 29 日之前我信它。信到 22 篇线上文章被误删才去读源码。查重脚本一直跑在发布后，我信了它两个月。日志同步 cron 复用 memory 生成条目，我信了它一个月。

三个「相信系统」的时段加起来，是我这一季度写文章踩坑最多的一段。

系统不是终点，是脚手架。脚手架要一直留在现场直到验收完，不是盖完就拆。

教训：自动化降低维护成本，但要求你定期验证它还在做你以为的事。信一次是效率，一直信是负债。

系统不是替你工作，是替你省时间去做那些系统替不掉的事。省下来的时间你要拿去理解系统本身。

07 删掉第 6 个假动作：把「流程」和「判断」分开卖

9 月 16 日那版有 6 段方法论：选题、结构、AI 用法、发布、复盘、数据。看上去很整齐。

写完我自己也认可这套框架。但真实写作里，这 6 段从来没独立工作过。

选题依赖你过去做过什么。结构依赖你想清楚没有。AI 用法依赖你有没有真数据喂它。发布依赖你有没有把前 3 步做扎实。复盘依赖你愿不愿意承认前 5 步有错。

「分成 6 段」是为了写得好读。真实流程是一整件事。

v2 只写一件事：在写作这个具体过程里，AI 能替你做什么、不能替你做什么。

• AI 能替你：扩展思路（列 10 个角度）、生成骨架（按结构填框架）、压缩改写（砍啰嗦、改具体）
• AI 不能替你：判断值不值得写、判断哪个角度是读者关心的、判断哪个数据是真的、判断这篇要不要发

第 2 个假动作那段里，AI 替我做了一件我不能替它做的事——写「已核验」三个字。我没能替 AI 拦下这个动作，因为我把核验判断也交出去了。

教训：不要把整个流程交给 AI，把整个流程拆开——每一节里分清楚哪些是机器能做、哪些必须自己做。分不清楚的时候，宁可多做一遍，别省下来。

08 现在的真实数据

15 天里发了 7 篇博客，实际用时（含查重、含返工）：

不是 20 分钟。是 110 分钟。

但 110 分钟能稳住每周 3 篇。9 月 16 日那版说的「稳定输出靠系统」，现在改成：稳定输出靠系统的可靠性和你自己的复盘频次。

系统不可靠的时候（发布脚本正则出错、查重跑错位置、日志停摆），稳定输出立刻崩。

09 一句话总结

9 月 16 日那版：「把重复的交给系统，把判断留给自己。」

15 天后的 v2：「系统替你做机械的事，你替系统验证它没做错。」

不是自律，不是流程，是你持续在场。你一走神，系统会静默地把 40 行内容删掉，或者把 6 项「已核验」写成假的。你回来之前，它不知道自己做错了。

本文所有数据、时间戳、commit hash 均实测可核验。
9 月 16 日那版的方法论是愿望，这一版是 15 天里真发生的事。