夜雨聆风- 让它"改一下登录页的样式"，它顺便重构了整个路由模块
- 要求"帮我看一下部署脚本"，它直接执行了生产部署
- 告诉它"写个单元测试"，它输出"测试通过"但根本就没跑
- 让它修一个Bug，它抄了近道、绕过了类型检查、在master分支上直接提交
这些问题的根源不是AI能力不够，而是缺了一本操作手册。你口头说的"小心点"、"先测试再提交"、"不要在master上直接改"，在Agent的上下文里随着对话推进被稀释、被覆盖、被遗忘。
解决方案是用 Skill（技能）——一个放在项目目录下的 Markdown 文件，每次 Agent 启动或匹配到相关话题时自动加载，形成持久的、可复用的行为约束。
Skill是什么？它不是Prompt，也不是Plugin
Skill 是 DeepSeek TUI（以及其他主流 AI 编程工具）的指令封装单元。它本质上是一个带元数据的 Markdown 文件，放在约定目录下，Agent 根据当前对话内容自动匹配加载。
和 Rule、Workflow、MCP 的区别
| Rule | |||
| Skill | |||
| Workflow | |||
| MCP |
Rule 管底线，Skill 管规范，Workflow 管流程，MCP 管能力。四者互不替代。
和传统"写Prompt"的区别
很多人试图在对话开头写一大段"你是一个高级工程师，请遵循以下规则……"。这种做法的问题是：每一轮新对话都要重新写，而且随着上下文增长，前面的规则会被后续内容挤占甚至遗忘。
Skill 的持久性来自文件系统——只要 SKILL.md 还在目录里，Agent 每次启动都会读取它（当然如果你不放心，最好是在Prompt时主动指定）。不依赖你记住、不依赖对话长度、不依赖模型窗口。
Skill的完整生命周期
第一步：创建
一个 Skill 就是一个文件夹加一个 SKILL.md 文件。目录结构如下：
my-skill/
└── SKILL.md
anthropics/skills 仓库中的 template/SKILL.md 提供了标准模板：
---
name: my-skill-name
description: 技能描述和触发条件
---
# My Skill Name
[在此写指令内容]
## Examples
- 用法示例1
- 用法示例2
## Guidelines
- 指南1
- 指南2
根据 Agent Skills 规范（agentskills.io），frontmatter 中只需要两个必填字段：
- name：技能唯一名称，小写连字符格式，必须和文件夹名一致
- description：技能描述和触发条件。这是最重要的字段——Agent 启动时扫描所有 SKILL.md 的 description，当用户输入和某个 description 语义匹配时，对应 Skill 被激活
DeepSeek TUI 内置的 skill-creator 技能提供了完整的验证清单：SKILL.md 以 --- 开头、name 与目录名一致、description 应描述何时使用该技能而不仅仅是"是什么"、内容只引用存在的工具和路径、任何脚本或外部服务步骤需说明凭据和信任处理。
第二步：安装
DeepSeek TUI 的 Skill 发现路径（按优先级）：
1. <项目根>/.agents/skills/
2. <项目根>/skills/
3. <项目根>/.opencode/skills/
4. <项目根>/.claude/skills/
5. <项目根>/.cursor/skills/
6. ~/.agents/skills/
7. ~/.claude/skills/
8. ~/.deepseek/skills/
项目级（前5个路径）：只在该项目下生效，适合项目专属规范。用户级（后3个路径）：全局生效，适合个人开发习惯。
DeepSeek TUI 内置了 skill-installer 技能用于从 GitHub 安装社区 Skill，也支持手动将 SKILL.md 复制到上述路径。
第三步：触发
Skill 的触发不需要用户手动指定。Agent 会：扫描所有已安装 Skill 的 description → 发现匹配当前请求的 Skill → 加载该 Skill 的 SKILL.md 内容到上下文 → 按照 Skill 中定义的规则和输出格式执行。你不必显式指定技能名，Agent 自动完成匹配。
第四步：验证
Skill 是否生效，观察 Agent 的行为输出即可验证。如果没生效，检查：文件路径是否正确、description 是否准确描述了触发场景、SKILL.md 的 YAML frontmatter 格式是否正确。
Anthropics/skills：Anthropic 官方的 Skill 开源仓库
在深入 Skill 的创建和使用之前，有必要了解一个重要的资源：github.com/anthropics/skills 是 Anthropic（Claude 的开发公司）在 GitHub 上公开维护的 Skill 示例仓库。
这个仓库的价值对 Skill 使用者来说，anthropics/skills 不是直接拿来就能用的工具箱，而是一个AI规范库。通过阅读这些官方示例的 SKILL.md 文件，你可以理解什么样的 Skill 结构是有效的、学习 skill-creator 的定义规范、参考文档类 Skill 的复杂度体会大型 Skill 的组织方式。
需要注意的是，部分 Skill 引用了 Claude 专有工具或 API 端点，在 DeepSeek TUI 中可能不可用。但 SKILL.md 的结构、描述方式、指令组织模式是跨工具通用的——这正是 Agent Skills 标准的意义所在。
Anthropics/skills 中值得关注的 Skills
以下是来自 anthropics/skills 仓库的六个真实 Skill，覆盖了从元技能到具体工具链的多个层次。阅读它们的 SKILL.md 源码，是理解"什么样的 Skill 是有效的"最佳途径。
1. skill-creator —— 用Skill造Skill
这是仓库中最特殊的 Skill：它不解决业务问题，而是教你如何创建和迭代 Skill 本身。
它的工作流是：理解用户意图 → 访谈和调研 → 撰写 SKILL.md → 创建测试用例 → 运行评估 → 根据反馈迭代。这个 Skill 本身就是一个渐进式学习素材——读它的 SKILL.md 源码，你看到的是一个 Skill 应该如何组织自身指令。
2. webapp-testing —— 网页应用自动化测试
这是一个基于 Playwright 的 Web 应用测试 Skill。它的 SKILL.md 中包含一个决策树，指导 Agent 根据"是否为静态 HTML"和"服务器是否已运行"选择不同的测试策略。
它带有辅助脚本（scripts/with_server.py），用"黑盒调用"模式——Agent 不需要把大段脚本读到上下文里，直接 python scripts/with_server.py --help 即可。
这就是 Skill 组合资源的典范——用 scripts/ 子目录存放独立脚本，用 examples/ 子目录存放典型用例。你的项目专属 Skill 也可以用这个模式。
3. web-artifacts-builder —— 复杂前端构件构建器
一个用于构建多组件前端 artifacts 的 Skill，技术栈是 React 18 + TypeScript + Vite + Tailwind CSS + shadcn/ui。它的 description 明确划定了使用边界，这避免了 Agent 在简单场景下错误触发复杂 Skill。description 不只是说"这是什么"，还要说"这不是什么"——明确排除不适用场景，防止误触发。
4. brand-guidelines —— 品牌规范应用
一个典型的"企业规范"类 Skill，将 Anthropic 官方的品牌颜色和排版规范编码为 Agent 可执行的指令：
SKILL.md 中明确定义了主色值、字体选择（Poppins / Lora）、以及不同场景下的应用规则。
任何团队都可以写一个类似的 Skill，把公司的代码规范、命名约定、API 设计风格编码进去。Agent 会自动遵循这些规范，不需要每次口头提醒。
5. 资源组织模式 —— scripts/, references/, assets/
综合上述五个 Skill，可以总结出仓库中 Skill 的三种资源子目录模式：
- scripts/ —— 独立可执行脚本。Agent 通过 --help 获取用法而不加载源码，避免污染上下文
- references/ —— 按需加载的参考资料。主流程写在 SKILL.md，细节放参考资料中
- assets/ —— 模板、图标、字体等输出用文件
这三个目录模式让你的 Skill 从"长了点的 prompt"进化为有架构的指令包。
除此之外还有spec-driven-development、test-driven-development等等都是值得开发人员关注的规范，能够让你的AI工具开发应用变得更加规范起来。
项目专属Skill：把踩过的坑变成Agent的肌肉记忆
anthropics/skills 仓库中的示例 Skill 覆盖了通用场景，但每个项目都有自己独特的"坑"。这些坑值得写到项目专属 Skill 里。
什么时候该写项目 Skill
每次 Agent 犯错，问自己：这个错是它不知道某个项目的特殊约定导致的吗？
如果是，记下来，写进 <项目>/.agents/skills/<技能名>/SKILL.md。
Skill组合
多个 Skill 可以组合使用。一套完整的"开发安全包"可以覆盖从需求到部署的全链路。Agent 的行为从"拿到需求立刻写代码"变成标准的多步流程。你可以根据自己的技术栈和项目规模，从 anthropics/skills 仓库中挑选合适的 Skill 作为模板，再补充项目专属的约束规则。
积累方法
在项目目录建一个 Skill 文件夹，每次踩坑后：记录"出了什么问题" → 记录"正确做法是什么" → 写入 SKILL.md。随着文件不断增厚，Agent 在同类场景上的出错率持续下降。Skill 是团队的经验数据库，每个人踩过的坑都变成 Agent 的肌肉记忆。
真实的例子：Windows PowerShell 编码的坑
Windows 下 PowerShell 默认编码不是 UTF-8。如果在 .ps1 部署脚本中写了中文注释，花括号会被吞掉，脚本执行崩溃。写入 Skill 后：生成的 .ps1 脚本中不允许出现中文字符（包括注释），如果需要中文日志输出，使用 Write-Host 的英文消息外加单独的日志文件。
写入后，Agent 生成的所有 PowerShell 脚本不再包含中文字符，这条事故再没出现过。
常见误区
误区1：Skill 写得太长。Agent 读取 SKILL.md 占用 context 空间。控制在 50-80 行以内，超过这个量请拆分成多个 Skill。把大段背景知识移到 references/ 子目录，在 SKILL.md 中写出明确的加载指引。
误区2：description 写得太模糊。description 是 Agent 判断是否加载 Skill 的唯一信号。写得太泛，Agent 可能在不合适的场景下加载它；写得太窄，Agent 在需要的时候又不会触发。好的范例：description: 当需要对代码进行安全性、健壮性和性能审查时使用。同时参考 skill-creator 的提醒——把 description 写得"pushy"一点，明确列出触发上下文。
误区3：只有社区示例就够了。anthropics/skills 提供了很好的参考和学习材料，但每个项目有自己的约定。项目专属 Skill 才是价值最大化的部分——那些踩过的坑、特有的技术栈约束、团队约定俗成的规范，任何社区仓库不可能替你写。
误区4：一次性期望过高。刚装 Skill 的头几天，Agent 的行为不会立刻完美。需要一个适应期——你会发现自己写的 Skill 需要迭代：某条规则写得不够具体导致 Agent 钻空子，或者某条约束太严格导致 Agent 拒绝做合理操作。Skill 是活的文档，需要持续维护。skill-creator 对此有完整的方法论：写草案 → 创建测试用例 → 运行评估 → 根据反馈迭代 → 重复直到满意。
写在最后
这篇文章覆盖了 Skill 的基础用法和进阶策略，核心结论是：
口头要求对 Agent 无效。只有写入 Markdown 文件、放到约定的目录下，才能形成持久的、可复用的行为约束。
Skill 遵循 Agent Skills 标准（agentskills.io），同一份 SKILL.md 文件可以在 DeepSeek TUI、Claude Code、Cursor、CodeX 等多个支持该标准的工具间复用。学一次，到处用。
如果你刚接触 Skill，今天就可以开始做三件事：
1. 在 github.com找到anthropics/skills仓库
2. 从仓库中挑一个与你工作相关的 Skill（如 spec-driven-development、test-driven-development），找到它的使用方法
3. 把上一个项目中 Agent 犯过的错，用 skill-creator 写成你的第一个项目专属 Skill
一个月后回头看，你会发现 Agent 的"不听话"频率会降低一个数量级。
