3 分钟 AI 学院 | 为什么你的 AI 助手总是「听不懂人话」?聊聊 SKILL 系统

同样是让 AI 写代码，有人效率提升 100 倍，有人觉得「这玩意儿也就聊聊天」。

差距不在模型，在 SKILL。

先说个场景

你让 AI 帮你修个 bug。

第一版：「帮我修一下登录页面的报错」

AI：「好的，请问具体是什么错误？」

你：「用户说点击登录按钮没反应」

AI：「好的，我来看看……」（5 分钟后）「我找到了一段可能相关的代码，你要不要看看？」

第二版（有 SKILL 系统）：「/debug-login 用户反馈：点击登录按钮无响应，浏览器 console 无报错，网络面板显示 API 请求超时」

AI：「收到。已加载登录模块的上下文，正在执行三步诊断：1) 检查按钮事件绑定 2) 检查 API endpoint 配置 3) 检查超时处理逻辑。3 分钟后给你初步结论。」

差距在哪？ 第二版背后有一套 SKILL 系统在撑。

SKILL 到底是什么

一句话：SKILL 是用 Markdown 写成的「可复用程序」，它告诉 AI 遇到某类任务时该怎么思考、怎么行动。

关键洞察：这不是 prompt engineering，是 software design——只不过用 Markdown 当编程语言。

一个 Skill 文件的真实样子

# Skill: 深度调研## 触发词/research, /调研，/深度分析## 参数- 主题：[必填]- 时间范围：[可选，默认最近 3 个月]- 输出格式：[报告/摘要/对比表]## 执行流程1. 先加载行业术语表 (terms.md)2. 并行搜索 5 个信息源3. 交叉验证关键数据4. 输出结构化报告5. 附上原始链接

效果：同一个 /research skill，传入「AI Agent 趋势」变成行业分析能力，传入「竞品动态」变成市场监控能力。

用 Garry Tan 的话说：「Every skill you write is a permanent upgrade to your system.」

为什么需要 SKILL 系统

1. 解决「模型失忆」问题

没有 SKILL：每次对话从零开始，你教过它的东西下次还得重新教。

有 SKILL：能力写在文件里，会话结束了能力还在。

案例：有团队用 AI 写代码，前两周效率提升不明显。第三周开始把「代码审查 checklist」「API 设计规范」「测试用例模板」写成 skill 文件。第四周，AI 第一次提交的代码就能通过审查。

2. 解决「上下文爆炸」问题

把 20000 行的 CLAUDE.md 塞给模型，它反而会迷失重点。

有个开源项目用了三级缓存策略：

• L1：每次加载 200 行核心指针

• L2：按需查 Skills 索引 + 公理索引

• L3：匹配后才加载具体 skill 文件

效果是模型只加载当前任务需要的上下文，注意力不被稀释。

3. 解决「结果不可控」问题

模型天生倾向于输出「看似合理、可能错误」的答案。

SKILL 系统的解法：把验收标准写成可执行的检查脚本。

比如一个调研 skill 的验收标准可以是：

• 输出格式符合 JSON Schema

• 中文内容无英文术语泄漏

• 所有数据附有来源链接

• 关键结论有交叉验证

模型自己跑检查、自己修正，循环到达标为止。

Thin Harness, Fat Skills：架构之争

核心主张：harness（运行模型的那层程序）要薄，skill（能力定义）要厚。

Harness 只做四件事：循环调用模型、读写文件、管理上下文、执行安全策略。

有个项目的反面教材：40 多个工具定义占掉半个上下文窗口，每个 MCP 调用耗时 2-5 秒，相比直接调用 CLI，性能差距 75 倍。

设计原则：把智能向上推到 skills，把执行向下推到确定性工具，中间保持最薄。

两种路线对比很清晰：Fat Harness 每加一个工具就占上下文，工具逻辑嵌在代码里，项目专属；Thin Harness + Fat Skills 则是 skill 文件按需加载，skill 是 Markdown 可读可改，跨项目复用，会写 Markdown 就行。

实战：怎么设计你的第一个 Skill

从高频重复任务开始

别一上来就搞「全能助手」。从你每天都要做的事开始：代码审查、写测试用例、整理会议纪要、生成周报。

有开发者发现每天都要写 PR 描述，于是写了第一个 skill：读取 git diff，识别改动类型（feat/fix/chore/docs），按模板生成描述，附上测试建议。效果是从 15 分钟/次压缩到 30 秒/次。

把隐性知识显性化

你脑子里的「判断标准」是 skill 最该捕捉的东西。

比如资深工程师看代码时会自动检查的那几件事：SQL 注入风险、错误处理是否完整、日志是否结构化、有没有性能陷阱（N+1 查询等）、有没有安全漏洞（硬编码凭证等）。

让 Skill 可组合

好的 skill 像乐高积木，可以拼出复杂工作流。

比如一个「新功能开发工作流」可以依次调用：先调研（/research）、再设计（/design）、然后实现（/implement）、最后测试（/test），每步输出 checkpoint。

几个常见误区

把 skill 写成 SOP：错误写法是「第一步做什么，第二步做什么……」，正确写法是「判断标准是什么，验收条件是什么」。模型不需要步骤，它需要的是判断框架。

追求大而全：一个 skill 文件 2000 行，模型读到后面忘了前面。建议是一个 skill 只做一件事，超过 500 行就拆分。

忽视安全边界：高危操作（删文件、调支付 API、访问数据库）必须有确认环节。比如删除操作需用户二次确认，写操作限制在工作目录内，网络访问需白名单授权。

生态现状

开源项目各有打法：OpenClaw 用 Markdown 文件本地存储，已接入 50+ 消息平台；Claude Code 用 Hooks 配置安全策略；Context Infrastructure 有 40+ skill 文件，带完整的索引和依赖声明。

ClawHub 的经验教训值得注意：OpenClaw 的 ClawHub 几周内从 3000 个 skill 爆发到 17000+，但也暴露了问题——有恶意 skill 混入、凭证存储不安全、质量参差不齐。生态增长快是好事，但安全治理要跟上。

组织影响

有个团队的反馈挺有意思：初级工程师反而适应更快，因为没有传统思维定式，工具使用没有老习惯需要破除。

资深工程师的价值在转移——从「自己写代码」变成「定义什么是好代码」：设计标准作业程序、构建测试支架、在 AI 眼里定义「好」的标准。

未来需要的是π型人才：既懂业务、又懂 AI、还能跨领域行动。核心能力是愿望力——改变世界/自己/公司/团队的主观能动性。AI 无限扩展能力时，主观能动性是无可替代的。

未来会往哪走

几个趋势已经能看到：

Skill 市场：就像 npm 包一样，skill 也会成为可复用的资产。会出现 skill 的「质量认证」机制，类似 npm 的 verified publisher。

Skill 组合语言：现在是用 Markdown 写流程，未来可能有专门的组合语言来做条件加载和序列执行。

Skill 评估体系：怎么判断一个 skill 好不好？任务完成率、平均迭代次数、用户满意度——行业还缺少统一的评估基准。

结语

工具会过气，对工具本质的理解不会。

SKILL 系统的本质不是「让 AI 更听话」，而是把人类的判断框架沉淀下来，让 AI 能够继承和复用。

今天你写的第一个 skill，可能是明天你的团队的标准作业程序。

从你每天都在做的那件重复事开始，把它写成 skill。

参考资料

[1] Garry Tan, “Thin Harness, Fat Skills”, X (Twitter), 2026-04-11.

[2] grapeot, “Garry Tan 的 Thin Harness Fat Skills 五个概念拆解以及怎么落地”, 2026-04-14. https://yage.ai/share/thin-harness-fat-skills-20260414.html

[3] AIOS: https://github.com/agiresearch/AIOS

[4] AgenticOS Workshop: https://os-for-agent.github.io

[5] OpenClaw GitHub: https://github.com/openclaw/openclaw

[6] Context Infrastructure: https://github.com/grapeot/context-infrastructure

注：本文核心观点源自内部业务分享和会议交流，部分参考资料来自公开来源。