先说结论

这个博客现在进入了一个新的版本：AI 时代人机协作工作流博客。

听上去有点大，其实核心很朴素：过去这里是我的赛博日记、技术学习笔记、工具代码速记、灵感收纳盒。现在 AI 已经能帮我查资料、写代码、跑命令、改项目，旧式“把技术步骤写成长教程以备下次翻”的价值下降了很多。

所以 V4 以后，博客会分成两条线：

1. 给人看的内容继续保留人的味道：随想、旅行、生活、计划、阶段总结，该怎么写还怎么写。
2. 给 AI 看的技术内容改造成工具：skill、tip、playbook、session 复盘、registry、hook、MCP，让未来的 AI 和我都少绕路。

不是把“李寒的小窝”装修成企业文档站。更像是在小窝里加了一个工具间，里面放着给 AI 用的扳手、标签、清单和一点点家规。

旧博客不动

旧博文全部保留，不迁移、不重写、不批量整理 frontmatter。

这点很重要。旧文章里有前 AI 时代的学习痕迹，也有一些当时看起来笨但很真实的记录。它们不是脏数据，不需要被 AI 打扫得光滑如新。

以后如果我写生活、旅行、随想、计划，还是传统博客文章。AI 可以帮我润色、排版、检查链接，但文章本身仍然是给人读的。

新增的 AI 资产层

V4 新增了一层专门给 AI 协作使用的资产：

1
2
3
4
5
6
7

.agents/skills/      Codex 主用 skills
.claude/skills/      Claude Code 兼容 skills
ai/sessions/         AI 协作脱敏复盘
ai/tips/             短问题、短原因、短修复、短验证
ai/playbooks/        复杂流程和长期工作法
static/ai/registry.json  公开机器索引
content/page/ai/     给人看的 AI 协作入口页

它们的分工大概是：

• tip：一个小坑，一个解法，一个验证命令。
• playbook：有步骤、有判断、有失败分支的工作流。
• skill：未来 AI 必须主动加载并遵守的行为规则。
• session：一次协作结束后的脱敏事实记录，不保存原始 transcript。
• registry：AI 先看的目录，决定要不要加载全文。

换句话说，新技术贴不再默认写成“人类教程”，而是默认写成“AI 可调用资产”。这不是为了让 AI 背更多材料，而是让 AI 更快找到该用的那一小片材料。

AI 怎么使用这个博客

以后 AI 开始处理博客技术任务时，第一步不是打开一堆文件，而是先查 registry：

1
2
3

python scripts/ai/mcp_server.py --search registry
python scripts/ai/mcp_server.py --search blog-style
python scripts/ai/mcp_server.py --search old-posts

如果 registry 里命中了合适资产，再加载对应的 tip、playbook 或 skill。

这个顺序很关键。AI 的上下文不是无限储物柜，能少读就少读。真正有效的协作不是“把所有历史都塞给模型”，而是让模型在需要时准确取用工具。

当前已经有的几条家规

现在仓库里已经固化了几条规则。

第一，旧文章只读。content/post/** 里的历史文章不要被批量迁移、重写、整理。只有当我明确要求写新博文或修改某篇文章时，AI 才能动。

第二，默认脱敏公开。AI 协作复盘只保存公开可读、已经脱敏的摘要，不保存原始对话、不保存密钥、不保存私密路径。

第三，AI 资产要短小。一个 tip 如果能解决，就不要写成长篇 playbook；一个 playbook 能表达，就不要升级成 skill。机器技术贴的目标是减少负担，不是增加阅读作业。

第四，更新完要介绍用法。以后每次功能更新、自动化更新、工作流更新完成后，AI 都必须告诉我：

• 这次新增或改变了什么；
• 我应该怎么使用；
• AI 以后应该怎么调用；
• 有哪些验证命令或失败处理方式。

这个规则会写进项目指令和质量门里，避免以后改完功能只丢一句“完成了”就跑路。

Hook：让流程自己提醒自己

V4 里引入了 hooks。

hook 可以理解成 AI 工具链里的“事件钩子”：在用户提交提示词、AI 调用工具、会话结束等节点，自动跑一段脚本。

当前项目里有几类轻量 hook：

• UserPromptSubmit：检查用户提示里是否不小心带了密钥等敏感内容。
• PreToolUse：在工具执行前检查危险路径，比如误改旧博文。
• Stop：会话结束时只采集轻量事实，生成草稿，不自动写长文。

这层设计得很克制。hook 不是让 AI 每次多背上下文，而是在关键节点提醒它别越界。

MCP：让 AI 查博客资产

这个仓库也准备了一个很轻的 MCP 查询层。

本地可以这样试：

1

python scripts/ai/mcp_server.py --search "protect blog style and old posts"

它支持的方向包括：

• 搜索 AI 资产；
• 读取指定 skill、tip、playbook；
• 根据任务推荐相关资产。

未来如果接入更正式的 MCP 配置，AI 就可以把博客自己的经验当成一个可查询的小型知识库，而不是靠我每次口头重复“记得别动旧文、记得保留风格”。

自动化发布链路

现在还加了一个 GitHub Actions 工作流：

1
2
3
4
5
6
7
8
9

ai_collab_digest_submitted
  -> payload 校验
  -> 脱敏
  -> 生成 tip/playbook/session
  -> 更新 registry
  -> Hugo build
  -> 创建 PR
  -> 自动合并
  -> 触发 Pages 部署

自动化的范围是受限的：它只应该改 AI 资产、registry、AI 页面和相关脚本，不应该碰旧文章。失败时再人工介入。

这套东西的理想状态是：我和 AI 做完一个项目，留下一个脱敏 digest，博客自动把可复用经验沉淀成下一次能查到的工具。

我自己怎么用

如果我是人类李寒，日常大概这样用：

1. 想写生活和随想，继续正常写博客。
2. 做完一次 AI 协作开发，如果有可复用经验，让 AI 生成一个短 digest，不保存原始 transcript。
3. digest 由自动化生成 session/tip/playbook，同步到 GitHub Pages 的 /ai/assets/。
4. 发布前看一下 AI 页面和 registry，不需要手动翻所有历史。
5. 每次功能更新完，要求 AI 讲清楚“怎么用”。

如果我是未来的 AI，工作前应该这样用：

1. 先读 AGENTS.md 或 CLAUDE.md。
2. 在博客仓库里搜索 static/ai/registry.json；在其他项目里搜索 https://lihan3238.github.io/ai/registry.json。
3. 只加载命中的资产 URL，不批量读取全库。
4. 修改前确认旧文保护、脱敏、风格要求。
5. 完成后跑验证，并向李寒介绍用法。

这次改造的意义

我觉得这个版本最大的变化，不是多了几个目录，也不是多了几个自动化脚本。

真正的变化是：博客不再只是“我写给未来的我看”，而是变成了“我和未来的 AI 一起工作的接口”。

过去我把知识写下来，是怕忘。现在我把流程固化下来，是为了让人和 AI 都能进化得更稳一点。

当然，小窝还是小窝。技术层长出了一套机器骨架，门口也还是可以放歌、写随想、贴旅行照片、偶尔吐槽人生。这样就挺好。