如何蒸馏我自己的写作风格

最近在折腾一件事：把自己的博客写作风格蒸馏成一个 Skill。

目的也很简单。后面我肯定还会让 AI 帮我改文章、整理语音笔记、续写一些草稿。但我不希望它一接手，就把东西写成那种很熟悉的 AI 文章：

• 在当今 AI 快速发展的时代
• 本文将从多个维度深入分析
• 核心价值
• 技术架构深度解析
• 未来展望

这些词单独看不一定有问题，但它们凑在一起，基本就不是我的博客了。

一开始我以为这件事很简单：把过去写的 Markdown 全部丢给 AI，让它总结一下我的写作风格，然后生成一个 AUTHOR_VOICE.md。

后来才发现，真正麻烦的不是总结，而是样本。

我的博客里并不全是我自己自然写出来的内容。里面有 AI 生成的文章，有 AI 根据源码整理出来的技术拆解，有周报里的链接和摘抄，也有我收藏的别人的观点。

如果这些东西不先剔掉，最后蒸馏出来的就不是我的风格，而是：

我的原始表达 + AI 公文味 + 资料摘抄 + 公众号味

这肯定不行。

先处理样本

我这次一共扫了 1310 篇 Markdown。

如果只看数量，这个样本肯定够。但写作风格这件事不是样本越多越好，样本脏了，后面总结得越认真，污染越严重。

所以第一步不是提炼，而是排除。

我先做了一轮机器筛选，大概看几类信号：

1. 正文里是否明确写了 AI 生成、Claude 生成、AI 扩写。
2. 链接、引用、摘抄是不是占比太高。
3. 有没有明显的报告味，比如“核心价值”“性能优化策略”“未来展望”。
4. 有没有真实问题、项目场景、排查过程和经验教训。

最后筛出来的数据是：

• 明确 AI 生成或 AI 扩写的文章：16 篇
• 综合判定为 AI 味或报告味较重的文章：38 篇
• 摘抄、链接、引用占比过高的文章：341 篇
• 剩下可作为风格候选的文章：664 篇

这里的重点不是判断文章好坏。

有些 AI 整理的文章内容很完整，甚至比我自己写得更规整。但它不能用来提取我的写作风格。因为我想保留的是我真实写东西时的判断路径，而不是保留一篇文章看起来有多完整。

这个区别很重要。

找真正像自己的文章

排掉明显污染样本后，还要继续找高可信样本。

我比较信任的文章，一般都有几个东西：

• 真实项目背景
• 明确的问题现象
• 一开始的错误判断
• 后来的排查过程
• 最后落到经验教训或 checklist

比如：

• 没搞清楚问题现象的教训.md
• 排查动态柱状图的动画问题.md
• 如何保证提测质量.md
• 如何编写方案设计文档.md
• 如何给可视化组件编写单元测试.md
• 如何做好CodeReview.md
• 如何用D3-js画一个可交互的关系图.md
• 优秀的简历是什么样的.md
• 苏州行.md
• 基于AI进行项目重构的工作流.md

这些文章不一定写得最漂亮，但它们更像我。

比如动态柱状图那篇，重点不是介绍 ECharts 动画机制，而是记录一个真实问题怎么被排查出来：业务方预期是什么，线上效果哪里不对，程序流程怎么走，错误路径是什么，最后改了哪里。

这类文章里有弯路。

而我现在越来越觉得，弯路才是风格的一部分。如果一篇文章从头到尾都很正确、很完整、很顺，它反而会不像我。因为真实工作里大部分经验都是从判断错、排查错、沟通错里面来的。

不要只学口头禅

做风格蒸馏时，很容易走到一个浅层方向：提炼常用句式。

比如我经常写：

• 这里做个记录
• 一开始我以为
• 后来才发现
• 这个问题暴露出
• 后续应该

这些当然有用，但只学这些是不够的。

如果 AI 只是学会了“这里做个记录”，但文章还是从宏大背景开始，还是把一个具体问题写成行业趋势分析，那就只是表面像我。

真正要提炼的是结构：

真实问题 -> 错误假设 -> 排查过程 -> 根因判断 -> 经验教训

所以 AUTHOR_VOICE.md 里最重要的部分，不是让模型多用哪些词，而是限制它不要乱来：

• 不要用宏大背景开头。
• 不要把技术复盘写成百科报告。
• 不要为了完整而完整。
• 不要强行三段论。
• 不要用抽象词替代具体问题。
• 不要编造我没有经历过的项目和教训。

我现在更愿意把这个 Skill 看成一个刹车，而不是油门。

它不是为了让 AI 写得更漂亮，而是为了在 AI 想往公众号、报告、总结文滑过去的时候，把它拉回来。

Skill 本身也要能搬走

最后产出了两个核心东西。

一个是风格画像：

~/.agents/skills/leozhou-blog-writer/references/AUTHOR_VOICE.md

另一个是真正可触发的 Skill：

~/.agents/skills/leozhou-blog-writer/SKILL.md

这里我一开始也犯了一个小错误。

我最早把 AUTHOR_VOICE.md 放在博客项目的 docs/writing-style 目录下。这样在当前博客仓库里看确实方便，但对 Skill 来说不是一个好设计。

因为 Skill 一旦迁移到别的 Agent 环境，或者博客项目路径变了，它就会找不到引用文件。

所以后面改成了自包含结构：

leozhou-blog-writer/
├── SKILL.md
├── agents/
│   └── openai.yaml
└── references/
    ├── AUTHOR_VOICE.md
    └── style-extraction-report.md

这样后面无论是给 Codex、Claude Code、OpenCode，还是其他支持 Agent Skills 的工具使用，只要复制整个 leozhou-blog-writer 目录即可。

这个调整也提醒我：Skill 不是一段 prompt，它更像一个小工具包。只要它依赖了外部文件，就应该尽量把依赖也放进自己目录里。

这次暴露出的一个问题

写完第一版后，我又回头看了一眼这篇文章，发现它其实还有一点 AI 味。

不是那种明显的“赋能闭环”味，而是另一种更隐蔽的问题：太规整了。

第一版文章有很多“第一步、第二步、第三步”，也有很多列表。信息没错，但读起来像一份方法说明文，不太像我平时从一个真实问题里复盘出来的记录。

这也是这次 Skill 暴露出来的第一个问题：

它已经能防住明显的 AI 公文味，但还不太会防“过度完整”。

所以我又往 Skill 里补了一条规则：如果文章读起来太顺、标题太多、列表太多，就要删掉一部分结构，把真实的误判、调整和现场过程写回来。

这个规则可能比禁用某些词更重要。

因为 AI 现在很会躲开禁用词。你不让它写“多维度”，它可以不写。但它还是会下意识把文章写得非常完整、非常平衡、非常像一份最后交付物。

而我的很多博客，本质上不是交付物，是工作记录。

工作记录里应该允许有一点不那么顺的地方。比如一开始放错了文件位置，后来才发现不方便迁移；比如第一版 Skill 生成的文章太规整，于是又补了反规整规则。

这些东西不漂亮，但它们是真的。

后续

这个 Skill 现在只能算第一版。

后面我会按真实使用继续改，不打算一次性把它写成一个万能规则库。规则太多也不好，模型会变成照着 checklist 写文章，最后还是不自然。

比较靠谱的做法应该是：

1. 每次 AI 写完文章，我先判断哪里不像我。
2. 如果只是偶然问题，先不写进规则。
3. 如果同类问题出现 2-3 次，再沉淀到 AUTHOR_VOICE.md。
4. 技术复盘、管理反思、周总结分开维护，不要混成一个万能风格。
5. AI 生成的文章继续明确标记，避免以后再次污染样本。

这次最大的经验其实很简单：

写作风格不是从所有历史文本里平均出来的，而是从高可信样本里提炼出来的。

样本不干净，后面再怎么蒸馏都没用。

另外，风格也不只是语气。真正决定像不像的，是文章背后的思考路径。

如果这个路径提炼不出来，只学几个口头禅，就很容易变成“表面像我，骨子里还是 AI”。