ryos

不要教顶尖模型思考

不要用 skills 教顶尖模型思考。过去 skills 主要用来补模型不会的能力；现在它的核心任务，是把模型权重里没有的本地规则、流程标准、工具用法和验收规则注入进去。

在 GPT-5.5、Claude Fable 5 这类模型面前，很多旧的 prompt stack、固定步骤、思维链模板，确实已经过时了。强模型不需要我们手把手规定“第一步做什么，第二步做什么”。它们已经能自己规划、查证、调用工具、修正错误，在模糊任务里找到推进路径。

但这不等于 skills 没用了。真正变化的是价值定位：skills 的重心从“教模型怎么想”，移到了“告诉模型什么算做对”上。

换句话说：

强模型负责判断、规划和变通；skills 负责告诉它，在这个具体世界里什么算做对。

顶级模型吃掉了旧脚手架

过去我们用模型，经常会写很长的指令：

先分析问题，再列计划，再逐步执行，再自我反思，再输出结论。

这种写法在弱模型时代有用，因为模型本身不稳定，需要外部流程把它扶住。但顶级模型出来以后，这类低层脚手架的边际价值在下降。OpenAI 对 GPT-5.5 的说明里，把 skills 定义成“编码流程和约定”的文件包，不再要求模型机械执行每一步。Anthropic 对 Fable 5 的提示工程建议也强调，旧模型时代过度规定的 instructions 和 scaffolding，可能会压制新模型的默认能力。

这件事对人的使用方式影响很大。

我们不应该再把模型当成一个需要一步步遥控的初级员工。更合适的心智是：它已经是一个能独立推进复杂任务的合作者。你要给它目标、约束、材料、成功标准和停止条件，不必把每个动作都写死。

拿改文章这件事来说，旧心智会写：

第一步总结原文，第二步找出问题，第三步重写标题，第四步改段落，第五步润色语言。

新心智应该写：

目标：把这篇文章改成适合公开分享的博客。

成功标准：
- 观点清楚，第一屏能让读者知道结论；
- 不像研究综述，不堆论文数字；
- 保留关键证据，但只服务于论证；
- 语言要像作者本人在表达，不要像报告。

边界：
- 不新增未经证实的数据；
- 不改核心立场；
- 文章长度控制在可读范围内。

强模型不缺“怎么想”的能力，它缺的是“你到底要什么”和“你所在场景的标准是什么”。

Skills 的价值变成了本地智能

一个好的 skill，应该聚焦在告诉模型：这个领域、这个团队、这个工具链、这个任务类型里，哪些规则必须遵守。通用思考，模型自己会。

可以看几个典型场景：

这些属于本地规则问题。模型再强，也不可能天然知道你的仓库约定、公司流程、私有 API、团队审稿标准、个人写作偏好、内部指标口径。它可以现场理解，但如果这些规则反复出现，每次重新解释就是浪费。把它们沉淀成 skill，才是对强模型的正确使用。

所以我更喜欢这个区分：

模型能力 = general intelligence
skills = local intelligence

研究结果也不支持“skills 必胜”

2026 年初的 SkillsBench 给了一个很有意思的结果：在 86 个任务、11 个领域、7 种模型-框架组合、7308 条轨迹上，人工策划的 curated skills 平均把通过率提升了 16.2 个百分点。

更反直觉的是，最强组合 Claude Code + Opus 4.5 反而拿到了最大的绝对提升，约 +23.3pp。也就是说，顶级模型同样需要 skills。强模型可能更能吃透好 skill。

但同一组结果也说明，skills 的价值高度依赖场景。医疗、制造这类领域收益很大；软件工程和数学收益很小。原因并不神秘：通用编程、数学、常见写作这些领域，顶级模型的预训练覆盖已经很充分，额外塞一堆流程文档，可能只是噪音。

专门看真实软件工程的 SWE-Skills-Bench 更尖锐：49 个 public SWE skills 中，39 个没有带来通过率提升，平均增益只有 +1.2%。有些 skill 还因为版本不匹配、和项目上下文冲突，导致性能下降。

这说明一个现实问题：skills 有边界，多了没用，有了也不一定有用。

最好的收益来自少量、聚焦、由懂业务的人维护的 skill。SkillsBench 里，2-3 个 focused skills 的效果明显好于堆 4 个以上；精简 skill 也比“大而全”的文档更有效。模型自己生成的 skills 平均没有收益，这一点尤其值得警惕。让模型在任务后记录经验是有价值的；让模型凭空生成一套流程，然后立刻当成可靠 skill 用，是另一回事。

人的心智要从写提示词迁移到设计工作环境

如果模型越来越强，人的工作会从写更复杂的提示词，转向设计更好的工作环境。

这个工作环境至少包括四件事。

第一，上下文。模型需要知道背景、目标、历史决策、相关材料和不可碰的边界。上下文越清楚，模型越能自主。

第二，标准。什么叫好，什么叫完成，什么叫不能接受。强模型可以自己走路，但你要定义终点。

第三，工具。模型会用工具，不代表它知道你希望它怎么用工具。工具描述、参数约束、错误处理、验证命令，都应该被清晰编码。

第四，记忆和流程。反复出现的任务，不应该靠人反复口述。能沉淀成模板、checklist、脚本、runbook、skill 的，就应该资产化。

这也是为什么我觉得“会不会写提示词”这个说法越来越浅。更底层的能力是：

这已经从 prompt engineering 进入了 environment engineering。

什么时候靠模型，什么时候靠 skill

上面说了这么多，落到实践上就是一个判断问题：一个任务来了，该让模型自主，还是该上 skill？

先问：这件事需要模型自己判断，还是需要遵守本地规则？

如果主要是判断，就给目标和材料，让模型自主；如果主要是规则，就用 skill 把规则显性化。开放式分析、战略判断、论文理解、复杂 bug 定位、一次性写作、数学推理，通常应该先让模型自主发挥——你提供目标、材料、约束和验收标准，不要写死路径。尤其是通用编程和常见写作，不要因为有 skill 机制，就把一堆“最佳实践”全塞进去。强模型通常知道常见模式，真正需要的是当前代码库的约束和你要达成的行为变化。

反过来，如果一个任务反复出现，而且每次都需要解释同一套规则，就应该考虑 skill。最典型的几类：

再问：这套规则是不是会重复出现？

只出现一次，就写在当前任务上下文里。反复出现，就沉淀成 skill、模板、脚本或 runbook。

最后问：这个 skill 会不会比任务本身更重？

如果一个小任务要加载四五个 skill、几十页文档，那大概率已经过度设计了。skills 的成本是真实的：上下文成本、选择成本、维护成本、过时风险都会反噬收益。

好的 skill 更像契约，不像剧本。

差的 skill：

你必须先列计划，再分析，再执行，再反思，再总结。

好的 skill：

使用场景：当任务是审查 PR 时触发。

关注顺序：
- 行为回归和线上风险；
- 测试是否覆盖关键路径；
- 安全、权限、并发、数据一致性；
- 代码可维护性；
- 最后才是风格问题。

输出要求：
- 先列发现，按严重程度排序；
- 每条必须给出文件和行号；
- 没有发现就明确说明剩余风险和未跑的验证。

停止条件：
- 不直接重写代码，除非用户要求修复；
- 不因为个人风格偏好提出阻塞意见。

这类 skill 把专业标准交给模型，不限制它的发挥。

综合起来，实践上可以这样分：

一个简单判断是：如果这个任务主要依赖通用推理，且结果可以通过测试、搜索、人工审查快速验证，就先不用 skill。让模型自由探索，再用验证信号收敛。

Skills 在把经验资产化，不是退回旧时代

很多人担心：模型都这么强了，还写 skills，是不是在倒退？是不是又回到手写流程、手写规则的旧时代？

我觉得不是。

旧时代的 prompt engineering，是试图用文字补模型的推理缺陷。新时代的 skills，是把人的经验、组织的规则、工具的知识、任务的验收标准，变成模型可以调用的外部资产。

这两者的心智完全不同。

未来真正有价值的，是维护一套高质量的工作资产，不是收藏一堆提示词模板：

顶级模型越强，这套资产越重要。强模型会放大好的外部结构，外部结构本身并不会消失。

最终的问题不在于“要不要 skills”，在于：

Skills 的使命是告诉顶级模型，这个世界里什么算做对。思考的事，模型自己会。

参考

所有文章