我用强模型写规则、让便宜模型照着跑，这套干了大半年的活这周有了名字

哈喽，我是飞飞。

这周刷到一篇 VC 写的短文，标题叫《Skill Distillation》。作者是 Tomer Tunguz，发在 2026 年 5 月 29 号。

我点进去看了两遍。看完有点恍惚。

因为他认认真真命名、当成一个新趋势讲的那件事，我自己已经埋头干了大半年。只是我一直没给它起过名字，也没觉得它值得起个名字。

他管这叫「技能提炼」。说人话就是：让最贵最聪明的模型负责写流程文件，让便宜的小模型照着流程一步步执行。

我那套天天在用的写作流水线，骨子里就是这个。

「技能提炼」到底是什么：老师写流程，学生照着做

Tunguz 自己用一个开源框架 Pi 当个人助理。他形容这东西不像聊天机器人，更像一个小型操作系统，帮他管收件箱、管项目、发博客、查资料。Pi 的目录里攒了大概 80 个流程文件，每天晚上还会自动复盘当天的日志，生成新的流程。

这些流程文件就是核心。它们用一种叫 SKILL.md 的格式写成。

关键在于谁来写、谁来跑。

写流程的，是 Opus、GPT、Gemini 这一档前沿模型。它们最懂怎么把一件复杂的事拆成清楚的步骤。跑流程的，可以是本地的 Qwen、Gemma 这种小模型。它们不需要多聪明，只要照着步骤走就行。

Tunguz 有一句话我特别认同：小模型不需要懂怎么去评估一家公司，它只要会照着步骤走。

老师把「怎么做」写进 markdown，学生照着做。这就是技能提炼。

它跟蒸馏、微调、RAG 差在哪：前三个都在动模型，它只动文本

你可能觉得，让小模型变聪明，方法早就有了，何必再造个词。

但它跟那三个老办法，划的界线很清楚。

知识蒸馏，是把大模型输出的概率分布压进小模型的权重里。本质是在改小模型的脑子。

指令微调，是用一堆「问题加回答」的样本去训练，把某种行为烤进权重。本质也是在改脑子。

RAG，是在模型回答之前先去知识库里捞相关的事实塞给它。它喂的是「事实」。

技能提炼一个都不沾。说白了，它不改权重，也不喂事实，喂的是「流程」。

而且这个流程是一份纯文本。我能打开看，能动手改，能用 git 管版本，能 diff 出昨天和今天差在哪。前三个办法做完，知识藏在权重里，你看不见也摸不着。

这个区别看着小，用起来天差地别。正因为流程是明文，我才敢把它交出去跑。

我的写作流水线，就是一套跑了大半年的技能提炼

我写公众号有一整套流水线，全是 SKILL.md 文件。content-researcher 负责查资料，content-writer 负责写初稿，content-polisher 负责去 AI 味，content-distributor 负责生成各平台版本。上面还有个 content-director 把它们串起来。

这些文件，是我拿 Opus 一点点磨出来的。具体就是把「飞飞写东西的判断」翻译成模型能照着执行的步骤。

举个例子。我知道自己讨厌中文破折号，讨厌「不是 X 是 Y」那种工整对仗的金句，讨厌「第一第二第三」的编号腔。但模型不知道。

我不能只写一句「写得自然点」，那等于没说。

我得把它拆成模型能执行的硬规则：正文里禁止出现破折号，写完跑一遍检索；对仗金句全篇不超过一处，超了就删；编号词换成具体的引导。每一条都配一个能用 grep 抓出来的模式。

这套规则攒到现在，是一个四十多条经验的文件。新写的每一篇,模型先读它，再动笔。

这就是技能提炼。我把脑子里那点写作品味，提炼成了一份模型照着就能跑的说明书。

哪些活我敢交给便宜模型，哪些判断我绝不敢给

这半年我最大的体会，不是「什么都能交出去」，而是摸清了那条边界在哪。

能交出去的，是照着步骤走的活。套模板、按句号拆段、统计字数、做 AI 味的初筛、把一篇文章改写成小红书版本。这些事步骤是死的，规则写清楚，便宜模型完全接得住。我甚至不需要它用最强的脑子。

不敢交出去的，是需要判断的活。

选题就是一个。我那套流程里，选题这一步必须停下来等我拍板，模型只能推荐,不能替我定。

事实核查是另一个。一个数字、一个出处对不对，错了就是硬伤，这事我不敢赌小模型。

最要命的是立场。我在润色规则里专门写了一条死命令：只许改语言，不许改观点。如果原文说某个东西「半年回本」，润色之后绝不能变成「不划算」。模型润色时手一滑很容易把立场改飘，所以这条我盯得最死。

这条边界，业界其实也认。

我去查了一圈，本地跑 SKILL.md 早就不是空想。GitHub 上有个项目叫 open-skills，标语就是「用任何模型在本地跑 Claude 的技能」。Ollama 现在直接提供了 Anthropic 兼容的接口，本地挂个 Qwen 或者 Gemma，配个 LiteLLM 代理，十来分钟就能跑起来。

但那些做过实测的人也老实承认：本地小模型照着流程走没问题，一碰到复杂的多文件改动、藏得深的 bug、需要架构推理的活，就明显不如前沿模型。

你看，这跟我的体会对上了。流程能下放，判断不能下放。

SKILL.md 写到什么份上，模型才接得住

技能提炼听着简单，真上手会发现，难的全在流程文件本身怎么写。

我踩过两个大坑。

一个是规则写虚了，模型立刻跑偏。「写得通顺一点」「注意逻辑」这种话，模型读完跟没读一样。它需要的是可执行、可检验的硬约束。中文字数卡在两千到两千五，破折号零容忍，对仗句最多留一处。越具体，它跑得越稳。

另一个坑更隐蔽：流程缺一步，整条链就崩。

我之前有个交付项叫「写作立意」，是 content-writer 这一步产出的。但到了 content-director 汇总的时候，它走的是自己另一套总结模板，这一项就在两个环节的接缝处悄悄漏掉了，连着几篇都没透传出来。

我后来才定位到问题，在流程里专门加了一句：这一项必须原样透传，不许省略。加上之后才接住。

这件事给我提了个醒。技能提炼里，模型不会自己补全你漏掉的步骤。你的流程写到哪，它就跑到哪。说明书的颗粒度，直接决定了执行的质量。

这套方法真正帮我省下的，是什么

折腾这么久，要说技能提炼帮我省了什么，最开始我以为是省时间。

后来发现不是。

它真正帮我省下的，是「我不用每次重新跟模型交代一遍我的写作品味」。

我的判断只需要沉淀一次，写进文件。之后无论换哪个模型来跑，它都照着我这套标准来。Tunguz 那篇文章里有句话我印象很深：执行的那个学生模型，就是这一季最便宜的那个。流程不动，底层模型谁便宜换谁。

这才是明文流程最大的价值。我的品味是资产，它躺在 git 里，不绑死在任何一家模型的权重上。

接下来我想真去试一件事：把流水线里最不吃判断的那几步，比如句号拆段和字数统计，换成本地的小模型跑，看看在我这台机器上，质量到底掉不掉。

你手上有没有那种重复交代了无数遍、其实早该写成流程文件的活？是写代码的规范，还是处理数据的套路？评论区聊聊，我想看看大家都把哪些判断提炼出来了。

---

参考资料

• [[skill-distillation-tomtunguz]]
• [[agent-skills-open-standard]]

相关洞察

• [[skill-distillation]]