AI 真正的成长,不是换模型,而是把错误蒸馏成 Skill
前两天,同学做了一次分享。
主题是 AI 蒸馏(Distillation)。
以前我一直觉得,所谓蒸馏,就是把一堆 Prompt 整理一下。
后来才发现,真正值得蒸馏的,从来不是 Prompt。
而是 经验(Experience)。
一次博客,让我意识到 AI 一直在犯同一种错误
这周看到一篇博客。
作者吐槽了一件很有意思的事情。
他说:
AI 特别喜欢写防御性代码。
比如:
const url = process.env.API_URL?.trim() || "";
或者
try {
...
} catch {}
再或者
if (!value) return null;
看起来非常严谨。
实际上很多都是没意义的。
博客最后总结得很好:
AI 喜欢这种代码,不是因为它聪明,而是因为它面对的是不完整上下文。
它不知道:
-
哪些错误一定不会发生
-
哪些配置一定存在
-
哪些异常必须暴露
-
哪些值不能默认
所以只能不断地:
-
trim()
-
try/catch
-
默认值
-
null 判断
把所有情况都包起来。
乍一看很安全。
实际上只是把真正的问题藏起来了。
真正的问题,不是 AI 写了这些代码
而是我以前根本不会发现。
以前我的流程一直是:
AI 写代码。
我看看。
功能实现完备。
结束。
直到看到这篇博客,我才意识到:
AI 写出来的每一种"奇怪的习惯",背后其实都有一个原因。
如果只是把这一段代码删掉。
下一次。
AI 还是会写。
因为模型没有成长。
只有我在重复劳动。
后来我才知道,这种东西可以蒸馏成 Skill
翻评论区的时候。
有人说了一句话:
我已经把这个问题蒸馏成 Skill 了。
当时一下子就懂了。
原来 Skill 不是 Prompt。
Skill 更像是一条长期规则。
例如上面这个问题,可以直接沉淀成:
Skill:不要生成无意义的防御性代码
生成代码时:
-
不要因为缺少上下文而滥用 try/catch
-
不要随意添加 trim()
-
Secret、Token、JWT 等必须 Fail Fast
-
配置缺失应该启动失败,而不是运行时返回默认值
-
默认值只能用于真正允许缺省的配置
-
优先在边界统一校验,而不是到处判空
如果需要防御,请说明原因。
否则不要添加。
以后每次写 Node 项目。
AI 都会遵守。
同一个坑,不会掉第二次。
我发现 Skill 真正蒸馏的是"认知"
以前觉得:
Prompt 是资产。
后来觉得:
Workflow 是资产。
现在越来越觉得:
真正值钱的是 Skill。
因为:
Prompt 解决的是一次任务。
Workflow 解决的是一类流程。
Skill 解决的是一种认知。
它会一直影响 AI 后面的所有输出。
这也是为什么很多人用同一个模型。
效果却越来越不一样。
不是模型差距。
而是 Skill 库越来越大。
我准备以后这样使用 AI
以后只要遇到下面几种情况。
我都会考虑是不是值得蒸馏。
第一类:AI 的固定坏习惯
例如:
-
滥用 try/catch
-
到处判空
-
过度抽象
-
提前优化
-
重复封装
-
默认值泛滥
这些其实都可以变成一条 Skill。
第二类:项目规范
例如:
React 项目。
我可以直接蒸馏:
-
不允许 any
-
Props 使用 interface
-
组件必须 PascalCase
-
不修改自动生成目录
-
Zustand 管理状态
-
Less + CSS Module
以后所有代码自动符合规范。
第三类:自己的编码偏好
例如:
我喜欢:
-
Fail Fast
-
小函数
-
注释解释为什么
-
不解释是什么
-
能删掉一层就删掉一层
这些也都可以沉淀。
AI 会越来越像我。
Skill 像是在训练一个长期搭档
以前总觉得:
每一次聊天。
都是重新开始。
现在越来越觉得。
真正高效的方式,不是一次次重新教 AI。
而是把每一次踩坑都留下来。
今天发现一个问题。
明天蒸馏成 Skill。
后天所有项目都受益。
AI 没有真正成长。
成长的是自己的知识库。
而 Skill,就是这个知识库最小、最容易复用的单位。
写在最后
这周最大的收获,不是学会了一个新的 Prompt 技巧。
而是改变了一种使用 AI 的方式。
以后遇到 AI 犯错,我不会第一时间想着修改这一段代码。
我会先问自己三个问题:
它为什么会这样写?
这是一次偶然,还是一种模式?
如果以后还会发生,我能不能把它蒸馏成一条 Skill?
当越来越多的问题被沉淀成 Skill 时,你会发现,AI 并没有变得更聪明。
但你的 AI,会越来越懂你。
更多推荐


所有评论(0)