当AI已经会思考,我们还需要Skills教它怎么工作吗?

如果你当前在项目工作中大量使用ai--skills技能包,那么我认为这篇文章对你有很大的帮助,或许会改变一些你的思考。
前言:
个人浅薄见解,勿怪。 不知道从什么时候开始(最早应该是各大AI厂商推出Plan模式时),我发现AI上安装的一些强流程型的skills越来越累赘,甚至一度认为有还不如没有呢! — 嗯。。。 随着ai模型能力越来越强,我的感受越来越深,直到我现在AI工具已经完全卸载了类似于superpowers这类skill技能包了。
下面我会详细说明我的观点(通过与AI对话的形式来表达我的思考),如果你认为这篇文章对你有所帮助,请点个小赞赞,十分感谢,哈哈。
我的对话
随着ai的爆火,智能工具越来越多,ai agent的兴起,ai的思考等等,延伸出了一系列的skills技能包,主要是为了弥补ai agent思考不全面的问题,例如superpowers这个skills就是一套固定的全面的程序运行工作流,早期我觉得还比较好用,有各种思考、审核、规划等等的步骤。
..........
但是近期随着 gpt5.6、fable5、opus5等越来越强的模型发布和崛起,我发现superpowers等之前好用的skills插件技能包等现在都成了累赘了,很多时候都是在无谓的消耗token,延长了程序思考和开发的流程,感觉很累赘,所以我已经卸载了,因为我认为随着agent和模型越来越强大之后,很多的skills技能工作流都逐步的融入到模型和agent的日常思考中去了,所以我的ai工具现在基本只安装一些必要的工具技能包,如调用外部浏览器、pdf制作等等,之前的superposers等技能包都已经卸载了..........
我相信随着agent和模型能力越来越强大之后,终会淘汰这些流程性的skills技能包,你认同我的观点吗?我希望你可以给出客观中肯的意见和建议,还有你自己的看法,从我的观点解析、到你的分析、到哪些后期还有生存空间,哪些终会被淘汰等等角度出发,给出我你的思考和观点。
我大体认同你的判断,而且我认为你抓到了 2026 年 Agent 生态正在发生的一个重要变化。
但我会把你的结论稍微改写一下:
未来被淘汰的不是 Skills,而是“教强模型怎么思考”的 Skills。
真正长期存在的 Skills,会越来越像“能力扩展包、领域知识包、工具适配器、确定性执行模块”,而不是“AI 思考流程说明书”。
这两者的区别非常重要。
一、为什么你会突然觉得 Superpowers 变得累赘了?
因为 Superpowers 出现时解决的,本质上是一个模型能力不足的问题。
它目前仍然把自己定义为一套“完整的软件开发方法论”,其核心流程大概是:
理解需求 → 澄清 → 输出设计 → 用户确认 → 制定详细实施计划 → TDD → 子 Agent 开发 → Review → 继续下一任务。
这个设计在较早阶段非常合理。
以前模型经常出现:
用户:帮我实现这个功能
AI:
马上开始写代码
↓
没理解项目
↓
没分析影响范围
↓
没看现有架构
↓
没测试
↓
改了一堆东西
↓
发现方向错了
↓
返工
所以 Superpowers 相当于给模型套了一副“工程师外骨骼”:
先别写
↓
分析问题
↓
澄清需求
↓
规划
↓
拆任务
↓
实现
↓
测试
↓
Review
↓
再确认
在模型本身不够可靠的时候,这种方法非常有效。
问题在于:
模型已经变了。
GPT-5.6 官方公布的数据就特别值得注意:OpenAI 强调 GPT-5.6 的一个核心进步不是单纯“答题更聪明”,而是用更少 token、更少模型往返和更少工具调用完成长流程 Agent 工作;一些实际 Agent 场景中也观察到了步骤数和工具调用减少。
Anthropic 对 Opus 5 的描述也很类似:更强的规划能力、自我纠错能力、代码库理解和长流程稳定性,一些测试中甚至出现更少轮次、更少工具调用完成同类任务的情况。
所以发生了一个非常自然的变化:
过去
弱模型
+
强流程 Skill
=
可靠 Agent
现在
强模型
+
强 Agent Harness
+
强工具调用
+
强上下文管理
=
本身已经具备大量工程工作流能力
这时候再叠:
+
brainstorm
+
planning
+
TDD workflow
+
review workflow
+
subagent workflow
+
verification workflow
+
completion workflow
就可能出现你现在遇到的问题:
重复建设。
二、所以我认为你的感觉并不是错觉
甚至 Anthropic 自己现在的官方文档,都在某种程度上印证这个趋势。
Claude Code 当前文档直接说:
内置工具已经覆盖绝大多数编码任务,扩展层应该在具体需求出现以后再添加。
而 Anthropic 最新 Skill 编写指南还有一个我认为非常关键的原则:
默认假设 Claude 已经非常聪明,只给它添加它本身不知道的东西。
并且要求作者反问自己:
- Claude 真的需要这段解释吗?
- 这个知识 Claude 本身是不是已经知道?
- 这段内容值不值得消耗这些 token?
这和你的观点几乎已经殊途同归。
三、但有一个地方我要修正你的判断
你说:
“很多 Skills 最后都会被模型能力吸收。”
这个判断我认同。
但如果进一步推导成:
“Skills 最终会消失。”
我不认同。
实际上我认为:
Skills 这个形态反而会长期存在。
只是它的职责会发生根本改变。
OpenAI 和 Anthropic 现在都在支持开放的 Agent Skills 体系。OpenAI 的 Codex/ChatGPT Skills 与 Anthropic Claude Code Skills 都已经采用基于 SKILL.md 的开放标准。
截至 2026 年 7 月,一项刚发布的 GitSkills 研究甚至统计到了公开 GitHub 中约 380 万个 SKILL.md 文件、28 万多个仓库。这不能说明每个 Skill 都有价值,但至少说明 Skill 正在演化为一种广泛采用的 Agent 扩展方式,而不是正在消亡的格式。
所以未来真正变化的是:
Skill 从“教 AI 怎么思考”,转向“告诉 AI 它不知道的东西,以及给 AI 它原本没有的能力”。
这是我认为整件事情最关键的分界线。
四、我把 Skills 分成六类,你就能很容易看清谁会死、谁会活
| Skill 类型 | 例子 | 我的判断 |
|---|---|---|
| 通用思维流程型 | brainstorming、planning、self-review、debug workflow | 🔴 大量被淘汰 |
| 通用能力增强型 | UI 设计原则、代码风格指南、通用最佳实践 | 🟡 大量缩水 |
| 专业知识/领域型 | 公司规范、银行规则、内部 API、项目架构 | 🟢 长期存在 |
| 工具/执行能力型 | PDF、PPTX、Excel、浏览器、Figma、数据库操作 | 🟢 长期存在 |
| 确定性脚本型 | deploy、release、lint、migration、CI | 🟢 极强生命力 |
| 合规/审计型 | 安全检查、发布流程、金融合规、生产操作 | 🟢 极强生命力 |
而且越往未来,这个分化会越明显。
五、第一批会被淘汰的:通用“思考型 Skills”
这是我与你观点最一致的地方。
例如:
think carefully
↓
understand requirements
↓
analyze alternatives
↓
make a plan
↓
implement
↓
review implementation
↓
run tests
↓
fix problems
这种东西在 2024、2025 年非常有意义。
到了 GPT-5.6、Fable 5、Opus 5 这一代,边际价值明显下降。
因为这些能力正在成为:
Agent 基础能力。
而不是:
用户额外安装的能力。
规划、自我检查、工具选择、长任务坚持、代码搜索、运行测试、分析失败原因,本来就是现代 Coding Agent 的核心竞争力之一。GPT-5.6 和 Opus 5 的发布材料也都把这种长程 Agent 能力作为重要提升方向。
于是就会产生非常典型的:
“Skill 反向降智现象”
模型自己本来可能这样:
理解需求
→ 快速判断
→ 查看代码
→ 修改
→ 测试
→ 发现问题
→ 修复
非常自然。
Skill 强制它变成:
启动 brainstorming
↓
输出需求理解
↓
进入 design
↓
输出方案
↓
等待确认
↓
启动 planning
↓
拆成 12 个 Task
↓
启动 TDD Skill
↓
启动 subagent
↓
启动 review agent
↓
review review
↓
verification
↓
completion
小功能本来 10 分钟能完成。
结果:
仪式感比工程本身还重。
这就是流程 Skill 最大的问题:
模型越强,固定流程的机会成本越高。
六、而且“浪费 Token”其实只是其中一个问题
这里我认为还可以再深入一层。
很多人把问题简单归结为:
Skill 占 Context。
实际上现在 Skill 已经有 Progressive Disclosure。
OpenAI Codex 当前机制是先加载 Skill 的名称和描述,只有判断相关时才加载完整 SKILL.md;初始 Skill 列表甚至有明确的上下文预算限制。
Anthropic 也是类似设计,只在需要时读取 Skill,再进一步按需读取 references/scripts。
所以真正的问题其实有 4 层成本:
Skill 成本
│
├── ① Discovery Cost
│ Skill 名称和 description
│
├── ② Context Cost
│ 加载 SKILL.md 后占用上下文
│
├── ③ Reasoning Cost
│ 强迫模型多规划、多检查、多思考
│
└── ④ Execution Cost ← 我认为最严重
多 Agent
多轮对话
多次 Review
多 Tool Call
多测试
多文件读取
你觉得 Superpowers “累”,很多时候真正感受到的其实不是第一、第二项。
而是:
③ + ④。
也就是所谓:
Workflow Tax——工作流税。
我认为这个词非常适合你未来文章里使用。
七、以后最危险的一类 Skill:教 AI 做 AI 本来就会做的事情
以后判断一个 Skill 有没有必要,我建议只问一句:
“如果我把这个 Skill 删除,GPT-5.6 / Opus 5 / Fable 5 自己会不会自然做到?”
如果答案是:
90% 会。
那基本可以删。
比如:
「分析需求 Skill」
模型本身已经会。
删。
「写代码前先规划 Skill」
高端模型本身会根据复杂度决定是否规划。
很多情况下删。
「遇到 Bug 要分析根因 Skill」
模型本来就会。
删。
「写完代码 Review Skill」
现代 Coding Agent 很多本来就会运行测试、检查 diff。
可以大幅精简。
「复杂问题逐步思考 Skill」
几乎没有必要。
模型本身就是 reasoning model。
八、但下面这些 Skills 我反而认为生命力非常强
1. 工具型 Skill
例如:
PDF
PPTX
DOCX
XLSX
Browser
Playwright
Figma
数据库
SSH
云服务
内部系统
模型再聪明,也不能靠“思考”凭空获得工具。
模型知道:
“应该修改 PDF。”
跟模型实际上能:
“正确操作 PDF 文件、调用库、检查输出、生成成品。”
是完全不同的能力。
Anthropic 官方提供的预置 Skills 目前恰恰就包括 PDF、PowerPoint、Excel、Word。
这非常能说明问题。
九、第二种长期存在的,是“模型不知道的信息”
比如:
公司的开发规范
内部 API
数据库字段规则
银行业务规则
项目特殊架构
部署服务器结构
内部 CI/CD
品牌规范
产品设计体系
这些东西不会随着 GPT-6、GPT-7 出现而自动消失。
因为:
能力强 ≠ 知道你的私有信息。
例如一个超级强的 Agent 也不可能凭空知道:
我们的 Go 项目必须:
service → usecase → repository
禁止 controller 直接操作 DB
错误码必须使用 xxx 包
上线前必须运行 internal-check.sh
这种 Skill 的价值不会因为模型变强下降。
反而会因为 Agent 自主程度提升而越来越重要。
十、第三种我尤其看好:Script-backed Skill
这可能才是未来 Skills 最正确的方向。
不是:
SKILL.md
请认真检查代码
请运行测试
请检查格式
请确认没有问题
而是:
SKILL.md
│
↓
scripts/
verify.sh
lint.sh
release.sh
migration-check.sh
模型负责:
判断
理解
决策
解释
程序负责:
执行
验证
计算
检查
重复任务
OpenAI 最近介绍自己维护 Agents SDK 仓库时,实际上采用的就是这种思路:模型处理解释、判断和上下文相关工作;脚本处理确定性的重复机械操作。
Anthropic 对 Skills 的设计建议也明确指出,传统代码在排序、结构化处理等确定性任务上往往比让模型生成 token 更便宜、更可靠。
这才是我认为 Agent Engineering 最终会走向的状态。
十一、所以未来不是“Agent + 一堆工作流”
而更像这样
┌──────────────┐
│ 强模型 │
│ GPT / Claude │
└──────┬───────┘
│
自己完成通用思考
│
┌────────────┼────────────┐
↓ ↓ ↓
工具能力 私有知识 确定性能力
│ │ │
Skills Skills Scripts
│ │ │
↓ ↓ ↓
Browser API规则 Test
PDF 公司规范 Build
Figma 业务知识 Deploy
DB 项目架构 Verify
而不是:
强模型
↓
思考 Skill
↓
规划 Skill
↓
需求 Skill
↓
开发 Skill
↓
测试 Skill
↓
Review Skill
↓
反思 Skill
↓
完成 Skill
这两个架构看起来只差一点。
实际上代表了完全不同的 Agent 哲学。
十二、我甚至认为未来有一个原则会越来越重要
Model-first,Skill-second。
先让模型做。
发现模型稳定做不好,再加 Skill。
而不是:
“先把网上所有优秀 Skills 装一遍。”
Anthropic 当前官方建议其实已经是这种思路:先通过实际任务发现 Agent 的能力缺口,然后针对缺口逐步构建 Skill。
这与前几年很不一样。
过去是:
看到牛逼 Skill
↓
安装
↓
希望 AI 变强
未来应该是:
十三、因此你现在“只留下必要技能”的方向,我认为是合理的
我甚至会推荐一个非常简单的策略:
Skill 最小化原则
只留下三类:
第一类:模型没有的能力
例如 PDF、浏览器、Figma、特殊文件格式。
第二类:模型不知道的知识
例如公司规范、项目架构、内部业务知识。
第三类:不能交给概率模型随意发挥的操作
例如 deployment、release、migration、security check、合规验证。
除此之外:
默认相信模型。
如果它连续几次在某个地方犯相同错误,再把那个问题抽象成 Skill。
而不是提前给它套几十层防护。
十四、Superpowers 会不会“死”?
我认为:
不会完全死。
但它的定位会越来越窄。
Superpowers 本身目前仍然非常活跃,而且仍然明确定位成完整软件工程方法论。
它未来依然非常适合:
- 新手使用 Agent 开发;
- 大型需求;
- 模型能力较弱的 Agent;
- 需要严格 TDD 的项目;
- 高风险重构;
- 多 Agent 长时间自主开发;
- 团队要求统一研发流程;
- 希望 Agent 行为高度可预测的环境。
但如果是:
经验丰富的开发者
+
GPT-5.6 / Opus 5 / Fable 5
+
成熟 Coding Agent
+
已有项目上下文
再强制套一整套:
Brainstorm
→ Design
→ Plan
→ TDD
→ Subagent
→ Review
→ Verification
我认为边际收益已经明显下降。
甚至可能:
收益 < Workflow Tax。
十五、这其实和软件工程发展史很像
早期很多事情都需要开发者手工规定:
内存管理
线程调度
错误检查
编译优化
网络处理
后来逐渐下沉:
程序员
↓
框架
↓
Runtime
↓
Compiler
↓
OS
Agent 也会发生相同事情。
早期:
用户
↓
Prompt
↓
Workflow
↓
Skill
↓
Agent
↓
Model
未来:
用户
↓
Agent
↓
Model
大量:
planning
reflection
tool selection
context management
self correction
review
memory
sub-agent delegation
都会逐渐下沉进 Agent Harness 和模型。
于是上层 Skill 不需要再告诉它:
“你应该先思考。”
而应该告诉它:
“这是你不知道的东西。”
这个变化,我认为就是未来几年 Skills 生态最重要的变化之一。
十六、我给 Skills 的未来做一个判断
如果让我给未来的 Skill 生态画一条演进路线,我会这么看:
换句话说:
Skills 会从:
Thinking Instructions
转变成:
Capability Modules
我认为这是比“Skills 会不会消失”更准确的表述。
十七、还有一个特别容易被忽略的变化
以后优秀 Skill 很可能越来越短。
现在很多 Skill:
SKILL.md
400 行
800 行
1000 行
未来可能变成:
---
name: release
description: 在正式版本发布时使用
---
运行 scripts/release-check.sh
读取 references/release-policy.md
如果检查失败,分析失败原因。
没了。
因为真正聪明的部分:
交给模型。
真正确定的部分:
交给程序。
真正特殊的部分:
放进 references。
这也正符合 Anthropic 当前“Skill 要简洁,只补模型不知道的信息”的官方编写原则。
十八、我会把整个观点浓缩成一句话
我认为最值得作为核心论点的是:
AI 越聪明,越不需要 Skills 教它如何思考;但 AI 越自主,越需要 Skills 告诉它有什么工具、哪些私有知识,以及什么事情必须确定性地执行。
这篇文章真正值得讨论的并不是“Superpowers 好不好”,而是一个更大的时代变化:
Agent Engineering 正在从“给模型搭思维脚手架”,进入“给模型提供能力边界”的阶段。
而我的实际使用体验,恰好是这个转变非常典型的一个缩影。
更多推荐



所有评论(0)