AI 对话本身不是文章。
这句话看起来很简单，但真正开始做的时候，我才发现它不是一句写作建议，而是一条工作流原则。因为对话发生在现场，文章面对的是后来的人。现场需要解决问题，文章需要留下经验。两者不是同一种东西。
一次 AI 协作里，往往会混在一起很多内容：临时判断、工具动作、路径信息、失败尝试、用户补充的新要求，还有一些只有当时才有意义的上下文。如果把这些东西原样搬上博客，确实真实，但读者会很累。读者不是来旁听一场施工过程的，他更想知道：这件事为什么值得做，中间最容易错在哪里，最后沉淀出什么方法。
真正要保留的不是工具动作，而是动作背后的判断链。 这也是我这次重写规则时最想强调的一点。以后无论来源是 Codex、Claude、Kimi，还是浏览器 Agent、写作 Agent、研究 Agent，都不应该先问“这是哪个工具的记录”，而应该先问“这里面有什么值得公开复盘的判断”。
先把对话从工具里解放出来
我以前容易把“AI 对话写博客”理解成“把 Codex 会话整理成文章”。后来觉得这还是太窄了。因为工具会换，Agent 会换，记录格式也会换。有的对话在本地日志里，有的是导出的 Markdown，有的是浏览器任务记录，有的是手动粘贴的一段工作复盘。
如果规则只绑定某个工具，后面换 Agent 时又要重来一遍。更稳的方式，是把它看成“协作记录转文章”。协作记录只是材料，文章要处理的是材料里的经验。
这件事让我重新意识到：一个流程成熟的标志，不是它能跑通一次，而是它换了工具以后还能继续成立。 工具只是入口，真正有价值的是提炼方法的能力。
所以第一步不是立刻写，而是先判断来源类型。它是完整会话，还是片段？是技术协作，还是写作协作？里面有没有隐私？有没有需要保留的决策点？这一步做清楚，后面的文章才不会被原始格式牵着走。
文章不是压缩包，而是思考路径
把长对话变短，很容易。删掉重复内容，保留结果，再加几个小标题，看起来就像文章了。
但这种文章往往读得很快，也忘得很快。原因是它只完成了压缩，没有完成解释。它告诉读者发生了什么，却没有讲清楚为什么这样做。
表面上我是在整理一段 AI 对话，其实我是在回答一个更深的问题：一次临场协作怎样变成未来可复用的经验？
如果文章只写“先整理资料，再生成草稿，最后发布上线”，读者不会真的学到什么。因为每一步都像正确废话。真正有用的是这些追问：为什么不能直接发布？为什么要先预览？为什么标题要清理？为什么本地路径和机器名要抽象掉？为什么上传成功还不等于线上成功？
这些“为什么”才让文章有骨架。读者看完以后，知道的不只是我做成了一件事，而是知道自己下次遇到类似场景时该怎么判断。
长度要服务于说清楚
一开始我会关心字数：一篇文章到底写多长合适？后来发现，长度不是目标，清楚才是目标。
如果只是预览草稿，七八百字可以。它的任务是让人快速判断主题、结构和方向。可是正式发布时，尤其是这种工作复盘类文章，太短就会有一种“点到了，但没讲透”的感觉。
我现在更倾向于把正式文章写到两三千字。不是为了显得厚重，而是给每个关键判断留出解释空间。
比如“发布前要本地预览”这句话，如果只停在这里，读者会觉得它是流程要求。继续往下写，才会发现预览真正挡住的是三类风险：标题污染、正文重复标题、隐私信息泄露。再继续往下写，还能讲清楚为什么批量发布时风险会放大。
这就是深写版要做的事：每个重要判断后面，都多写一层原因、后果和迁移方法。深写不是把话说长，而是把判断背后的代价说清楚。
脱敏不是抹掉真实，而是让经验能公开
AI 协作记录里经常有很多具体信息。项目名、路径、机器名、账号、日期、内部文件名，甚至某些临时素材后缀。它们在现场很有用，但放到公开文章里，不一定合适。
这里最容易误判的是，以为脱敏会让文章变空。其实好的脱敏不是删除真实，而是把真实换成可以公开理解的表达。
具体路径可以变成“本地工作目录”，某台机器可以变成“另一台工作机”，具体课程或老师可以变成“课程资料”，某个内部项目可以变成“内容发布系统”。读者仍然知道事情发生在真实工作里，但不会被无关细节困住。
脱敏还有另一个好处：它会逼你区分“事实细节”和“方法细节”。事实细节服务当时，方法细节服务以后。公开文章应该保留后者。
能被替换掉的，多半是现场细节；替换之后仍然成立的，才更接近方法。
配图要解释结构，不要装饰热闹
这次新规则里，我也把图片放进了流程。
但我不想把配图理解成“文章显得丰富一点”。如果图片只是好看，反而会分散注意力。对这种由协作记录改写来的文章，图片最好承担结构功能。
比如一张图可以表达从“协作记录”到“草稿”再到“预览、发布、验证”的流程；一张卡片可以提炼一个关键判断；一张前后对比图可以说明“原始对话”和“可复用方法”的差别。
图片不需要多。默认一张封面概念图，一张流程图就够了。太多图片会让文章像简报，反而削弱文字里的思考。
我更愿意把图片看成路标。文字负责把路走完，图片负责让读者在几个关键转弯处看清方向。
发布流程里要留一个人的停顿
自动化流程很诱人。写完、上传、部署、上线，最好一步完成。
但内容发布有个很微妙的地方：越是能自动，越要在关键点留一个人的停顿。
这个停顿就是本地预览。草稿在对话框里看是一种感觉，进入博客页面又是另一种感觉。段落是否太短，小标题是否太机械，加粗是否太多，图片是否压住正文，标题是否带了内部标记，这些问题都需要在页面里看。
如果只有一篇文章，问题还容易修。如果是十三篇文章一起发布，一个共同缺陷就会被放大十三次。比如所有文章都太像总结，所有段落都点到为止，所有标题都带着工具痕迹。预览不是拖慢流程，而是在自动化之前保留判断。
内容流程最危险的地方，不是它不能自动，而是它在还没有判断清楚时就开始自动。
所以我的发布顺序会固定下来：先写草稿，再本地预览，再按反馈深写，再处理图片和加粗，最后上传、部署、验证线上链接。
下次我会怎么做
下次再把 AI 对话写成博客，我会先做四件事。
第一，不先问工具名，先看协作类型。无论来源是哪种 Agent，先判断这段记录里有没有一个值得公开复盘的问题。
第二，不按对话顺序写，按读者理解顺序写。先讲发生了什么，再讲表面问题和真实问题，再讲判断链、风险、方法。
第三，默认进入深写版。每个重要判断后面补一层“为什么”：为什么重要，不处理会怎样，下次能怎么复用。
第四，给文章配置少量有用图片，并用加粗标出关键判断。图片负责解释结构，加粗负责抓住主线，但不能替代正文讲清楚。
对话会过去，工具也会换。真正应该留下来的，是一次协作里那些经得起迁移的判断。
这才是把 AI 对话写成博客的价值：不是保存聊天记录，而是把一次临场工作里的判断、边界和方法，变成下一次可以继续使用的思想工具。