普通归档装不下这类问题#

项目回看很适合写清楚一件事是怎么做成的。

比如一个发布脚本怎么串起安全扫描、构建、Pagefind、打包和线上校验；一个群聊机器人怎么从 NapCat、OneBot 路由到插件；一个实验仓库怎么把网表、波形和报告材料放到一起。

这些文章的主线是把系统做稳：问题从哪里来，系统怎么拆，最后怎么验证。

但争议内容还要看停手。

它要回答的不只是“还能不能继续做”，还有“做到哪一步就该停”。这种问题如果混在普通项目归档里，读者很容易只看到能力增长，看不到能力旁边的刹车。

这对写作者也不健康。因为一旦叙事默认沿着“更自动、更主动、更完整”往前走，范围就会被写成一句附带说明，而不是文章最后要讨论的东西。

哪些内容应该进入争议边界#

我会把几类内容放进“争议边界”这条线。

第一类是私有记忆公开化。

本地记忆进博客时，我最想记的是“哪些记录永远不该公开”。路径、群聊、账号、日志、真实人名、临时上下文、还没有脱敏的失败现场，都不能因为它们能提供素材，就被直接搬进文章。

第二类是机器人自我迭代。

这里要问的不是“它能不能改文件”，而是它什么时候只能只读，什么时候只能生成建议，什么时候可以打补丁，什么时候必须停在确认门前。越接近真实执行，越要把责任范围写清楚。

第三类是真实动作自动化。

提醒、清单、价格监控、未支付订单、远程控制本机，这些小工具都很有用。不过它们一旦碰到钱、账号、消息发送、公开发布、文件删除，就不能只按“能不能跑通”来判断。它们需要安全门、回包、可取消路径和失败后的清理方式。

第四类是批量创作。

批量生成图片、封面和文章草稿，本身不是问题。问题在于它们很容易绕过人的最后审校，直接把半成品推到公开站点。越是量大，越要先有质量门槛、人工复核和草稿隔离。

这些内容都值得写，但它们不该伪装成普通功能进度。

写争议文章时，少复原现场#

争议文章不适合写成现场还原。

现场往往有太多私有细节：具体群聊、具体账号、具体机器、具体文件、某次临时决策。把这些东西写出来，看似真实，实际会把公开文章带偏。

更好的写法是少复原现场，多留下判断。

我更关心这些问题：

1
默认值为什么要保守？
2
失败时会伤到什么？
3
哪些动作必须人工确认？
4
哪些材料只适合留在本地？
5
公开版本应该删掉什么？
6
这个能力如何降级或关闭？

这样写出来的文章，重点是说明系统在哪里停手，不是炫一个系统多强。

公开文章不需要证明我把每个现场细节都掌握了。它更应该留下可复用的判断：下一次遇到类似能力时，我应该先问哪些问题。

未完成专题继续留在草稿里#

未完成专题也适合按这个原则处理。

有些内容已经有雏形，但还不该进入正式发布流。只要口吻、封面、目录节奏和最后审校没有统一，就不能因为素材已经存在而提前放出；批处理回看虽然是工程经验，也可能把读者带到一个还没整理好的生产线里。

更稳的做法是继续保持 draft: true。

等专题入口、章节节奏、封面规范和质量标准都清楚以后，再作为独立专题发布，而不是混进普通归档。强入口如果还没有打磨好，提前发布只会让首页显得杂。

这不是单纯否定内容，而是给它留一个更完整的出场方式。

专栏要提醒自己别写散#

把争议内容放进单独栏目，不是为了让分类显得齐整。

它的作用是提醒自己：这里讨论的不是普通功能进度，而是一种能力该怎么被限制。

当文章被放进这条线时，它默认要回答几个问题：

• 这件事为什么容易越界。
• 哪些信息不能公开。
• 哪些动作不能自动执行。
• 哪些默认设置必须保守。
• 如何确认它没有从草稿泄漏到生产站点。

这些问题比标题、标签和封面更重要。

博客如果只按项目名堆文章，很快就会变成流水账。更值得长期看的，是那些跨项目反复出现的判断：发布范围、确认门、少打扰、可审计、失败隔离。

这些内容要单独放#

能力越接近真实动作，公开出口越要窄。

能写，不代表现在就发布；能自动化，不代表一路执行；能从私有系统里长出素材，也不代表要把私有现场摊开。

博客要保留这些争议，因为它们是长期判断的来源。不过它们应该被放到单独栏目里讨论，而不是伪装成普通项目进度。

我不想把博客写成一条功能升级流水线。

更好的形态是：项目文章讲做成了什么，实验文章讲结果怎么留，课程文章讲知识怎么拆，争议文章讲能力在哪里停手。这样内容才不会全挤进归档，也不会把最该说明的范围写丢。