高可靠 AI 工作流的 Skill 设计指南:4 大模式 + 4 种防御策略

💡 核心导读：Skill 的本质并非工具插件，而是“知识注入”。一份高质量 Skill 的底层逻辑只有两件事：description 决定加载频率，正文逻辑 决定执行深度。

很多人第一次接触 SKILL.md 时，下意识觉得它是工具插件，用来扩展 AI 的能力边界。

这个理解不能说错，但严重低估了 Skill 的本质。

Skill 真正做的事是 知识注入：把一段结构化的指令文本，塞进大模型的上下文窗口。

一旦理解了这层逻辑，你就会明白：Skill 写得好不好，取决于 指令文本的质量，而不是你给 AI 配了多少工具。

一份高质量的 Skill 文件，标准结构其实很简单：

---name:skill-namedescription:触发场景描述（决定是否被加载）---正文：具体的执行逻辑## 适用场景## 前置条件## 主流程## 降级方案

一、Description 决定命运：让 AI 正确加载你的 Skill

为什么两个功能几乎一样的 Skill ，一个能被 AI 稳定调用，另一个总是被跳过？

答案几乎 100% 出在 description 字段上。

AI 加载 Skill 的逻辑本质是检索匹配：用户发起请求时，AI 会将请求语义与所有 Skill 的 description 做打分，分数最高的被加载执行。

好的 description 写作，建议遵循以下三条核心原则：

• 原则一：列举触发短语不要只写“用于代码审查”，要写出具体的用户指令。例如：“当用户说‘帮我 review 这段代码’、‘检查漏洞’时触发”。
• 原则二：定义时序位置说明该 Skill 在工作流的哪个阶段被调用。例如：“在代码编写完成后、部署之前调用”。
• 原则三：包含产品关键词如果与特定平台强绑定，必须出现平台名称。例如：“用于生成技术团队周报，自动汇总 Git 提交与 Jira 工单”。

二、4 种设计模式：覆盖全部典型场景

Skill 的正文有 4 种最常见的设计模式。记住这个框架，可以应对大多数 AI 工作流的设计需求。

2.1. 模式一：线性流程

适用场景：任务边界清晰、执行路径单一。先验证前置条件，然后按顺序执行，失败后进入降级方案。

2.1.1. 案例：周报自动生成 Skill

假设你需要一个 Skill，每周五自动帮你生成本周工作总结。

---name: weekly-report-generatordescription: |  当用户说生成本周周报写一下周报本周工作总结时触发。  自动拉取 Git 提交、Jira 工单、会议纪要，按三段式结构生成 Markdown 周报。---## 适用场景每周五下午需要生成本周工作总结，面向技术团队管理者或项目经理。## 前置条件- Git 仓库访问权限正常（`git log` 可执行）- Jira API Token 已配置且未过期## 主流程1. 拉取本周 Git 提交记录：`git log --since="last friday" --pretty=format:"%s"`2. 调用 Jira API 获取状态为已完成的工单，提取标题和关键进展3. 扫描 `/docs/meetings/week-*.md`，提取 Action Items（匹配 `- [ ]` 或 `TODO:`）4. 按项目进展 / 技术难点 / 下周计划三段式结构生成周报5. 写入文件 `weekly-report-YYYYMMDD.md`## 降级方案- 会议纪要缺失：基于 Git 和 Jira 数据生成精简版周报

2.1.2. 关键设计要点

2.2. 模式二：决策树 + 按需加载

适用场景：任务存在多个分支，AI 需要根据上下文判断路径。

2.2.1. 案例：会议总结助手 Skill

用户让 AI 总结一场会议，但会议类型不同（周会、项目评审会、客户沟通会），总结模板和关注重点完全不同。

决策树设计：

用户输入：帮我总结今天的会议判断节点 1：这是什么类型的会议？├── 周会（触发关键词：周会 / 例会 / standup）│   └── 加载模板：references/weekly-meeting-template.md│   └── 关注重点：本周完成项、阻塞项、下周计划│   └── 输出格式：三段式表格（Done / Blocked / Next）│├── 项目评审会（触发关键词：评审 / review / 方案讨论）│   └── 加载模板：references/project-review-template.md│   └── 关注重点：决策结论、待确认事项、风险点、责任人│   └── 输出格式：决策清单 + 风险矩阵│└── 无法识别类型    └── 使用通用模板：references/generic-meeting-template.md    └── 输出格式：时间 / 参与人 / 议题 / 结论 / 待办

2.2.2. 关键设计要点：

• 每个分支必须有独立的下一步指引，不能让 AI 站在分支节点上自己判断

❌ 错误的写法：

如果用户选择了海外区域：  （这里没有后续内容，AI 需要自己推理）

✅ 正确的写法：

如果用户选择了海外区域：  1. 检查目标 bucket 是否存在跨境权限  2. 调用 cos upload 接口，上传至海外节点  3. 返回部署成功通知，包含 CDN 刷新指令

• 按需加载外部模板：大段的条件判断不需要全部塞进主文件，可以按需引用外部 reference 文件，避免单个 Skill 文件过大、超过上下文预算。

2.3. 模式三：循环迭代

适用场景：任务需要反复打磨，直到满足退出条件（如文章润色）。

2.3.1. 案例：文章润色助手 Skill

场景：用户写了一篇公众号文章，要求 AI 反复打磨，直到风格达标。

循环设计：

## 主流程（循环迭代）初始化：iteration = 0，max_iterations = 5循环开始：  1. iteration += 1  2. 读取检查清单 `reference/article-checklist.md`  3. 按清单逐项评估当前版本（通过/不通过）  4. 如果全部通过 → 退出循环，输出终稿  5. 否则 → 识别最高优先级未通过项，针对性改写，进入下一轮强制退出：iteration ≥ 5 时，输出当前最佳版本，标注未通过项

2.3.2. 关键设计要点：

2.4. 模式四：接力棒循环

适用场景：跨越多个会话 session 的超长任务，防止 AI 遗忘。

核心逻辑：将状态写入文件。

• 每轮结束将进度写入 state.json。
• 下轮开始先读取该文件，恢复上下文。
• 文件就是“接力棒”，通过读写实现跨 session 连续执行。

2.4.1. 案例：长篇小说创作助手 Skill

场景：用户要求 AI 协助创作一部长篇小说（预计 10 万字），显然无法在一次对话中完成。

接力棒设计：

// state.json 结构{"project": "科幻小说《xxx》","current_phase": "chapter_draft",  // 当前阶段：outline / chapter_draft / polish"completed_chapters": 3,           // 已完成 3 章"total_chapters": 20,              // 共 20 章"current_chapter": 4,              // 正在写第 4 章"next_action": "基于大纲撰写第 4 章初稿，目标字数 5000 字"}

每轮 session 的执行流程：

1. 读取 state.json，恢复上下文2. 读取世界观设定和人物小传（保持设定一致性）3. 执行 next_action 中的任务4. 任务完成后：   - 更新 state.json 中的状态和进度   - 写入新的章节内容到独立文件（如 chapter-04-draft.md）   - 更新 next_action 为下一项任务5. 如果当前 session 即将结束（token 接近上限）：   - 保存 state.json   - 输出进度摘要：已完成第 4 章初稿，下次请从第 5 章大纲开始

2.4.2. 关键设计要点：

三、模式选型决策指南

四种模式并非互斥，复杂 Skill 常结合使用。以下是快速选型建议：

四、防止 AI 偷懒的 4 种防御策略

大模型在执行复杂任务时，有天然的 偷懒倾向：跳过它认为不重要的步骤，用模糊的结论替代精确的验证，合理化自己的简化行为。

Skill 设计者必须正视这个现实，而不是假设 AI 会老老实实按我说的做。

以下是 4 种经过实战验证的防御策略：

策略一：强硬语气

置于正文最显眼位置，使用命令式的、清晰的、不容置疑的语言。

**必须严格执行以下规则，不得违背：** - 禁止使用“已经够好了”、“基本达标”、“用户应该能接受”等理由提前结束循环。 - 每轮必须完整运行完整检查清单，不能跳过任何一项。 - 修改后必须重新跑一遍完整检查清单验证效果。

策略二：验证清单 (Checklist)

要求 LLM 执行完任务后逐项打勾，全量通过才准退出。

* [ ] 标题是否包含具体的利益点？* [ ] 是否去掉了无意义的废话开头？* [ ] 全文是否有至少 3 个案例支撑？

策略三：Good/Bad 对比

用案例锁定标准。AI 对“口语化”这种抽象词理解不稳，但能看懂对比：

策略四：负面指令

明确告诉 AI禁止操作的行为：

- 不要修改未列出的文件。- 不要替用户做决定，只提供事实依据。- 不要为了缩减篇幅而省略细节。

结语

Skill 设计本质上是一门 知识工程。

它不要求你写多么漂亮的代码，而要求你把“什么场景下做什么、怎么做、做错了怎么办”，用 结构化、可验证、不歧义 的方式表达清楚。

把这套“模式+策略”组合起来，你的 AI 工作流离稳定可靠就不远了。