不是所有需求都该做成 Skill：一套封装判断框架
Skill 有开发和维护成本，不能拿来包装每一次模型调用。本文从任务的重复性、专业上下文、流程边界和验证方式出发，给出一张可以直接用于筛选需求的候选卡。
不是所有需求都该做成 Skill：一套封装判断框架
假设现在有几件事摆在面前：
- 把一段接口文档翻成英文；
- 按固定格式把 CSV 转成 JSON；
- 每周检查一次项目依赖，结合团队规则给出升级建议；
- 帮用户管理从注册到续费的完整业务流程。
它们都可以让 Agent 参与，也都能写出一段像样的 Prompt。但要不要做成 Skill，答案并不一样。
翻译一次文档，直接对话最快。CSV 转 JSON，几行代码更稳。依赖检查开始有 Skill 的味道：它会重复发生，需要读取项目文件，还得结合团队规则做判断。排在末尾的需求已经超出单项能力，它有用户、权限、长期状态和多个业务环节，更接近一个完整应用。
上一文章把 Skill 放在 Prompt、工具和 Agent 应用之间。这一篇继续往前走一步：拿到具体需求时，怎么判断它配不配占一个 Skill 的位置。
一、先承认封装有成本
把需求做成 Skill，新建目录只是开始。
职责要有人解释，规则要有人维护，脚本和工具会产生依赖，模型或外部接口变了还要重新验证。只要准备交给别人使用，就得处理输入不完整、执行失败和危险操作。写得越“通用”，测试组合往往越多。
所以别把 Skill 当成收藏 Prompt 的文件夹。它更像项目里的一个模块：存在的理由应该是长期价值，不能只因为这次演示能跑。
有些需求天然不值得承担这笔成本。
临时 Prompt 就能解决
一次性的总结、改写、翻译和头脑风暴，目标会随着对话变化，也没有稳定流程。封装一圈，往往只得到一段带名字的 Prompt。
普通代码会更可靠
格式转换、字段映射、固定规则校验这类任务，输入输出明确，几乎不需要语义判断。硬把模型加进来，只会增加延迟、费用和不确定性。
一个工具已经够用
“读取 Git diff”“查询天气”“创建 Issue”描述的是动作，还算不上完整能力。工具负责把动作做掉，至于为什么调用、如何判断结果，应该由调用它的任务或 Skill 决定。
需求已经大到接近应用
当需求包含用户系统、权限、多个长期状态、复杂界面和一组相对独立的能力时，继续往一个 Skill 里塞只会做出巨型模块。它需要的是应用边界，以及若干可以被应用调用的 Skill。
这几类先排除，剩下的候选才值得继续看。
二、一个需求开始有 Skill 的样子
Skill 的价值不取决于 Prompt 有多长。短指令也可能调用复杂能力，长 Prompt 也可能只服务一次对话。
判断时，我更关心下面几个现象。
它会反复发生，而且每次都在解决同一类问题
“帮我看一下这段代码”太宽了。换一次输入，目标和判断标准都可能跟着变。
“按仓库规范审查当前分支的代码变更”就稳定得多。代码每次不同，任务目标、输入范围和交付方式基本不变。重复带来的收益也很直接：规则只维护一处，失败案例可以留下来，团队不必每次从头解释。
重复与定时执行无关。哪怕一个月只做一次发布检查，只要每次都要遵循同一套严格规则，也可能值得封装。
它依赖一组不能每次临时粘贴的专业上下文
有些任务离开项目资料就无法正确判断，例如：
- 代码审查依赖仓库规范和架构约束；
- 内容发布依赖渠道格式、用词边界和审核规则；
- 数据分析依赖指标口径和字段定义。
这些上下文需要持续更新，还可能被脚本、模板和工具共同使用。继续把它们复制进聊天框，迟早会出现版本不一致。
它有相对稳定的流程，也允许局部判断
完全开放的问题很难封装，完全确定的问题没必要交给模型。适合 Skill 的任务通常夹在中间。
比如依赖升级检查，大体顺序可以固定：读取依赖、识别变化、结合兼容性规则判断风险、生成建议。每一步做什么比较稳定，具体升级哪个版本、风险是否可接受，则需要结合上下文判断。
这种“流程可描述，判断不机械”的任务，正好能让代码、工具和模型各做擅长的部分。
它能说清边界，也能检查结果
至少要能回答：
- 输入从哪里来，缺少什么就不能继续；
- 这项能力负责到哪里，哪些事明确不做；
- 哪些操作只给建议，哪些操作可以执行；
- 什么结果算完成；
- 修改之后，用哪些案例检查行为有没有退化。
这些问题长期答不上来，就先别急着建 Skill。需求本身可能还没收敛。
三、三种常见的伪 Skill
判断条件不能拿来给需求贴金。很多设计失败，恰恰是因为开发者太想把手里的东西叫作 Skill。
换了文件名的 Prompt
里面只有角色设定、任务描述和输出格式，没有外部资料、稳定流程或验证方式。它可以继续作为 Prompt 使用，没有必要为了显得工程化再包一层目录。
什么都能做的大 Skill
“软件开发助手”“内容运营专家”“个人知识管家”听起来很完整，实际很难划清输入输出。一个需求进来以后，它可能分析、搜索、写作、修改文件、发布，还顺手维护状态。
这种 Skill 的任何改动都可能影响无关场景。测试范围不断扩大，失败时也不知道责任落在哪里。名称越像一个岗位，越要警惕它有没有吞掉太多能力。
只能服务一条样例的 Skill
有些 Skill 对演示输入调得很好，换个相邻场景就失效。常见原因是把样例中的偶然细节写成了规则，或者根本没有说明输入边界。
判断它是否可复用，不用准备几十条测试。先换一份输入、删掉一个可选条件、制造一次工具失败。流程立刻散架，说明现在拥有的仍是一段演示脚本。
四、用一张候选卡把需求说清楚
遇到疑似 Skill 的需求，可以先填下面这张卡。这张卡不做评分，每一项也不用写得很长。写不出来的地方，就是当前最需要澄清的地方。
1# Skill 候选需求卡
2
3需求名称：
4
5重复场景：
6- 谁会在什么情况下再次使用它？
7- 每次不变的目标是什么？
8
9专业上下文：
10- 需要长期维护哪些规则、资料或模板？
11- 这些内容现在存放在哪里？
12
13执行流程：
14- 哪些步骤顺序相对稳定？
15- 哪些判断需要模型参与？
16- 哪些动作更适合代码或工具？
17
18能力边界：
19- 必须具备哪些输入？
20- 明确不负责什么？
21- 哪些操作需要用户确认？
22
23验证方式：
24- 什么结果算完成？
25- 可以保留哪些成功、边界和失败样例？
26
27替代方案：
28- 临时 Prompt、普通代码或单一工具为什么不够？
29- 这个需求是否已经大到应该做成应用？填完之后，不必算分。直接看证据。
需求会重复出现，依赖稳定的专业上下文，流程能够描述，边界可以收紧，结果也有办法验证——这些证据齐了，就值得进入下一步拆解。
最有力的理由若只是“Prompt 已经很长”或者“以后也许会复用”，先保持简单。等真实重复出现、失败案例积累起来，再做 Skill 也不迟。
软件工程里有一种很朴素的克制：别急着抽象。Skill Engineering 也一样。