很多人已经会用 Claude Code 改代码、跑命令，但只要任务稍微复杂，就会回到同一个状态：每次重新解释规范、重复粘贴检查清单、反复提醒它不要跳过测试。

问题通常不在模型，而在工作方式。一次性 Prompt 适合表达当前意图；可复用的工程流程，更适合沉淀为 Agent Skill；需要访问数据库、浏览器或外部 API 时，再交给 MCP。把这三层拆开，Claude Code 才能从“聪明的命令行助手”变成可复用、可验证的工程执行者。

本文给出一套可以直接落地的 Skills 设计方法，并说明什么时候应该使用 MCP，而不是继续把所有内容塞进一个超长提示词。

一、先分清 Prompt、Skills 和 MCP

可以用三个问题快速判断：

层次	解决的问题	适合内容
Prompt	这次要做什么	当前目标、临时约束、一次性上下文
Skills	应该怎样稳定地做	标准流程、检查清单、模板、脚本、团队规范
MCP	可以访问什么外部能力	数据库、GitHub、浏览器、搜索、工单、实时 API

一个容易记住的比喻是：Skill 是工作手册，MCP 是工具箱，Prompt 是这次的任务单。

例如“生成上线报告”：

1. Prompt 指定本次版本号和发布日期；
2. MCP 读取 GitHub PR、监控指标和工单数据；
3. Skill 规定数据提取顺序、风险分级、报告模板和发布前检查项。

如果只是静态流程，不要为了“看起来高级”专门搭 MCP 服务；如果必须读取实时数据，也不要把数据手工复制进 Skill。

二、一个最小可用 Skill 长什么样

典型目录可以保持很简单：

code-review-workflow/
├── SKILL.md
├── scripts/
│   └── collect-diff.ps1
├── references/
│   └── review-rules.md
└── templates/
    └── review-report.md

SKILL.md 至少包含名称、触发描述和执行流程：

---
name: code-review-workflow
description: Review a code change before merge. Use when the user asks for
  code review, PR review, regression analysis, or release risk assessment.
---

# Code Review Workflow

1. Read the architecture and repository conventions.
2. Inspect the complete diff and affected callers.
3. Rank findings by user impact and regression risk.
4. Verify each finding against code or tests.
5. Report findings first, then residual test gaps.

## Exit conditions

- Every finding has a file and line reference.
- No claim is based only on guessing.
- Unverified risks are labeled as assumptions.

最重要的字段不是 name，而是 description。模型通常先看到 Skill 的元数据，再决定是否加载正文。描述只写“helps with code”几乎无法稳定触发；应当写出用户可能说的词，以及 Skill 在流程中的位置。

三、5 种常用工作流模式

1. 线性流程

适合部署、安装、迁移和发布等有明确顺序的任务。

推荐结构：

Prerequisites -> Quick Start -> Verification -> Fallback -> Troubleshooting

关键不是把步骤写多，而是给出安全默认值、明确命令、超时、验证方法和失败后的降级方案。例如部署类 Skill 默认创建预览环境，只有用户明确确认后才进入生产。

2. 决策树 + 按需加载

适合平台选型、故障诊断或拥有大量子产品的知识域。

主文件只负责导航：

用户需要运行代码？
├─ 边缘函数 -> references/edge-functions.md
├─ 容器任务 -> references/containers.md
└─ 定时任务 -> references/schedules.md

详细材料放入 references/，真正命中分支时再加载。这样既能覆盖大知识域，又不会在每次会话中塞入几万字上下文。

3. 循环迭代

适合 TDD、代码审查、设计评审等“执行、验证、修正、再验证”的任务。

以测试驱动为例：

RED -> 验证失败 -> GREEN -> 验证通过 -> REFACTOR -> 重复

这类 Skill 必须写退出条件。如果只写“修复直到完成”，模型很容易在第一次看到绿色输出时提前结束。应明确最低测试范围、禁止跳过的检查项，以及不确定时何时请求人工判断。

4. 接力棒循环

适合跨多个会话或多个 Agent 的长期任务。

核心做法是把状态写入文件，而不是依赖对话记忆：

读取 current-state.md
-> 执行本轮任务
-> 更新决策与证据
-> 写 next-step.md
-> 下一会话继续

接力棒文件至少记录：已完成内容、当前证据、未解决风险、下一步命令和禁止重复的动作。这样即使会话中断，也不会重新从头扫描或重复提交外部操作。

5. 多阶段 + 检查点

适合需求发现、系统迁移、合规审计等跨天或跨周流程。

每个阶段使用统一模板：

Activities -> Outputs -> Evidence -> Go/No-Go Decision

检查点必须有可验证条件。例如“完成需求调研”不够具体，可以改成“覆盖三类用户、关键问题连续两轮没有出现新主题、所有结论均能追溯到访谈记录”。条件未满足就不能进入下一阶段。

四、让 Skill 真正稳定的 6 个细节

1. 描述要包含触发词

把用户会说的自然语言写进 description，例如 review、regression、release risk，而不是只写抽象能力名。

2. 主文件只保留决策所需内容

长 API 文档、平台清单和示例放到 references/。主文件负责告诉模型“什么时候读哪个文件”。

3. 给出正反例

Good/Bad 对比比单纯解释规则更容易被模型稳定执行。代码审查、文案风格和结构化输出尤其适合这种写法。

4. 设置量化退出条件

“充分测试”“认真检查”都不可验证。改成具体命令、覆盖范围、最少检查项和允许残留的风险类型。

5. 明确禁止项

写清楚不得删除用户文件、不得绕过验证码、不得把未验证假设写成结论、不得在没有确认时执行生产操作。负面边界应该靠近相关步骤，而不是藏在文末。

6. 把机械工作交给脚本

文件扫描、格式校验、统计和模板生成适合放在 scripts/。模型负责判断，脚本负责确定性执行。脚本输出再进入上下文，通常比让模型逐行读取所有原始数据更省 token，也更可靠。

五、最常见的 5 个反模式

1. 一个 Skill 包办所有事情：触发范围过大，加载后仍不知道先做什么；
2. 把整套文档都塞进 SKILL.md：上下文成本高，也失去按需加载的意义；
3. 静态流程也搭 MCP：增加认证、部署和维护成本，却没有实时数据价值；
4. 没有验证和回滚：模型完成了动作，但无法证明结果正确；
5. 没有人工检查点：涉及账号、付款、生产环境和不可逆操作时仍自动推进。

六、推荐的落地顺序

不要一开始就建设庞大的 Skills 平台。可以按下面的顺序迭代：

1. 从每周重复两次以上的流程中选择一个；
2. 先写 50 到 100 行的最小 SKILL.md；
3. 用 5 个真实任务测试触发率和完成率；
4. 将重复读取的大段资料移入 references/；
5. 将确定性操作提取为脚本；
6. 只有出现实时外部数据需求时，再接入 MCP；
7. 为高风险动作增加人工确认和审计记录。

最终目标不是“安装更多 Skill”，而是减少重复解释、降低上下文浪费，并让团队流程能够复用和验证。

延伸阅读

• Agent Skills 原理、三层加载机制与 MCP 对比
• 从 7 个案例拆解 Skill 的 5 种设计模式
• AI Coding 常用 MCP 项目与使用场景
• AI 编程专题与完整学习路径

---

本文基于公开案例与工程实践整理，AI 辅助完成结构和排版；发布前已人工核对方法、示例与风险边界。