让 AI 不再"凭感觉做事"——Claude Code Skills 的实践与思考

让 AI 不再"凭感觉做事"------Claude Code Skills 的实践与思考

从一个真实的项目目录出发，聊聊 Skills 是什么、怎么用、以及它为什么是 AI 编程中最被低估的能力。

---

引言：当 AI 有了"肌肉记忆"

我们和 AI 协作时，最常遇到两种挫败感：

1. 每次都要从头教------明明上周刚处理过一模一样的会议纪要，这次它又忘了格式。
2. 它懂了，但做出来的东西差点意思------摘要写了、HTML 也生成了，但排版乱、标签不统一、信息过载。

Skills 就是为解决这两类问题而生的。它让 AI 的行为变得可复现、可验证、可迭代。

这篇文章从一个真实项目的 .claude/skills/ 目录出发，拆解 Skills 的设计哲学。

---

一、Skills 到底是什么？

我的 .claude/skills/ 目录下有两个 Skill：

skills/
├── meeting-minutes/           # 会议纪要生成
│   └── SKILL.md
└── tian-ai-daily/             # 甜甜每日AI新闻概览
    ├── SKILL.md
    └── templates/
        └── daily-template.html

每个 Skill 本质上是一个 Markdown 文档------一份写给 AI 看的"标准作业程序"。

这份文档之所以"有用"，关键在于它的设计方式。

---

二、解剖一个 Skill：以 meeting-minutes 为例

打开 meeting-minutes/SKILL.md，它的结构是这样的：

2.1 头部：精准的触发条件

---
name: meeting-minutes
description: >
  根据会议文字稿/录音转写文本生成结构化的会议纪要。
  当用户提供会议录音转写、会议文字记录、会议笔记、
  或要求"生成会议纪要"、"整理会议记录"、"meeting minutes"时触发。
---

关键设计：description 的内容全部聚焦于触发条件。

这是经过验证的最佳实践------如果 description 里写了"这个技能会先清理文本、再提取关键信息、最后按模板输出"，AI 可能会直接照 description 的摘要干活，而跳过正文里的详细指令。描述越像"索引"，AI 越会认真读完正文。

2.2 正文：像食谱一样的步骤

第一步：通读全文，清理无关内容
第二步：识别关键信息
第三步：按模板输出

每一步都是可操作的动词：识别→提取→输出。不写"你应该理解会议内容"这种模糊话，而是写"不确定的内容一律留空，宁可留空也不要编造"。

2.3 底线：宁缺毋滥原则

Skill 里最核心的一句话是：

不确定的内容一律留空，宁可留空也不要编造。编造的信息比缺失的信息危害更大。

这是给 AI 划的安全边界。没有这条规则，AI 在信息不足时会倾向于"合理推测"------而会议纪要里的推测就是事故。

---

三、再看一个更复杂的 Skill：ai-daily

ai-daily/SKILL.md 展示了 Skills 进阶用法：工作流编排 + 模板分离。

3.1 五步工作流

步骤	内容	工具
Step 1	并行搜索多个新闻源	WebSearch × 5
Step 2	智能过滤（保留/丢弃标准）	规则引擎
Step 3	生成中文摘要（50-100字）	AI 摘要
Step 4	套用 HTML 模板生成页面	读模板→替换占位
Step 5	输出确认	文件路径 + 统计

每一步都有具体的标准表。比如 Step 2 的过滤标准：

保留（满足任一）：
- 头部 AI 公司重大发布或更新
- 开源社区重要模型/工具发布
- AI 政策监管的重大变化
- 过亿美元级别的融资/并购

丢弃：
- 纯观点/评论文章
- 小修小补的版本更新
- 超过 48 小时的旧闻

每一步都是可执行、可验证的条件判断。

3.2 模板分离

SKILL.md 只有 124 行，但引用了 templates/daily-template.html（374 行）。为什么不把 HTML 写在正文里？

因为 HTML 是重参考内容------它不需要 AI 每次重新理解，只需要读取-替换。分离后：

• SKILL.md 保持精干，AI 快速扫描流程
• 模板文件独立维护，改了模板不用动流程

这正是 Skill 设计的核心原则：正文讲流程和判断，附件放"拿来就用"的素材。

3.3 实战产物

ai-daily-2026-07-17.html 是这个 Skill 一次实际运行的输出------一个紫色的渐变头部、12 张新闻卡片、每条都有标签和原文链接的精美 HTML 页面。这就是 Skill 存在的意义：让每次输出都达到同一水准。

---

四、Skills 设计的三个核心原则

从这两个 Skill 的实践中，提炼出三条原则：

原则一：Trigger > Workflow（触发条件 > 工作流程）

Skill 的 description 字段只写"什么时候用它"，不写"它会怎么做"。

• ✅ 好的描述：当用户提供会议录音转写、会议文字记录时触发
• ❌ 差的描述：该技能先清理文本、再提取关键信息、最后按模板生成会议纪要

原因很反直觉：AI 看到差的描述后，会直接照着描述干活，跳过技能正文。描述越是像"目录"，AI 越会认真读完整篇技能。

原则二：Standards > Judgment（标准 > 判断）

AI 的判断力不可靠，尤其是在信息不完全时。好的 Skill 用明确的规则替代 AI 的判断：

场景	模糊指令	明确标准
过滤新闻	"选重要的"	"满足任一保留条件则保留"
摘要长度	"写短一点"	"50-100 中文字符"
不确定信息	"合理推测"	"一律留空，绝不编造"

原则三：Template > Generation（模板 > 即兴生成）

每次让 AI 从零"创造"输出格式，结果必然不一致。好的 Skill 提供模板或示例：

• meeting-minutes 提供了完整的输出模板（表格结构、字段顺序、占位符规则）
• tian-ai-daily 提供了可复用的 HTML 模板（374 行完整样式 + 占位符标记）

模板让 AI 的角色从"设计师"变成"填充者"------后者出错概率远低于前者。

---

五、什么时候值得写一个 Skill？

不是所有重复性工作都值得做成 Skill。我的判断标准是：

值得写 Skill	不值得写 Skill
同一模式使用 3 次以上	一次性任务
输出格式有严格要求	格式灵活，怎么做都对
需要过滤/筛选/判断标准	只需执行固定命令
团队其他人也会用到	只有你一个人用的个人偏好
操作步骤容易遗漏或走样	步骤简单，不可能出错

以 meeting-minutes 为例：每次会议的纪要格式要求一致，但不同会议的输入格式千差万别（录音转写、手写笔记、口述概要）。这就构成了"高重复 + 多变输入 + 严格输出"的典型场景------Skill 的完美适用条件。

---

六、Skills 的局限与未来

当前 Skills 的局限性同样值得关注：

1. 静态文档------Skill 不会自动进化。每次流程变化需要手动更新 SKILL.md。
2. 无状态------Skill 无法"记住"上一次使用的偏好或用户反馈。
3. 发现机制依赖关键词匹配------如果 description 写得不精准，AI 可能永远不会主动加载它。
4. 无验证闭环------Skill 是否被正确执行，没有自动检查机制。

但这些局限也正是 Skills 优雅的地方：它足够简单，所以零门槛。一个 Markdown 文件 + 一个目录，就能让 AI 的行为从"随机应变"变成"精准执行"。

---

七、结语

回到最开始的问题：Skills 是什么？

它是一个 Markdown 文件------这是它的形式。

但它真正的作用是：把你对"AI 应该怎么干活"的期待，转化为 AI 可执行的、不会走样的指令。

当你发现自己在反复纠正 AI 的同一个错误，或者在每次对话开头说"跟上次一样，但是......"的时候------那就是你需要写一个 Skill 的时刻。