Appearance
写Skill别急着动手：先问自己四个问题，工程思维做AI技能
做Skill需要有工程思维——不是上来就干，而是干之前想清楚：这个需求值得做成Skill吗？是补能力还是固偏好？输入输出边界在哪？将来敢删吗？
四个问题清单
text
1. 这个需求我每周都在做吗？流程够固定吗？
2. 这Skill是补能力还是固偏好？如果是补能力，准备好它有一天会过时吗？
3. 我的验证方案，能不能用数据替掉感觉？
4. 如果有一天它该退役了，我有勇气删掉它吗？最后一个问题最要命——敢承认一个Skill没用了，比敢写一个新Skill更难，也更值钱。
一、需求值得做成Skill吗？
高频复用 + 流程够固定，才值得。
| 条件 | 说明 |
|---|---|
| 高频 | 每周甚至每天都在做 |
| 流程固定 | 每次的步骤、标准、产出格式都差不多 |
Skill的本质：解决你当下需求的流程指导手册。
好例子
| Skill | 为什么好 |
|---|---|
| 文章插图Skill | 每次写完都要配图，把画面风格、尺寸、构图偏好固化成Skill，省的是每一次 |
| 公众号排版Skill | 段落空多少、哪里加粗、引用块怎么用，固化流程，不是某一次的输出 |
| 标题生成Skill | 主体词+修饰词+句式套路+人性(恐惧/欲望)，组合拼接不断积累 |
反面教训
小红书风格优化Skill：把任意文本转成小红书调性，口语化、加emoji、分段短。后来模型升级了，自己做得更好——Skill反而不如裸模型。
二、动手之前，先问三个问题
第一问：补能力，还是固偏好？
| 类型 | 特点 | 盯什么 |
|---|---|---|
| 补能力型 | 模型还不擅长的领域 | 模型升级后是否还必要 |
| 固偏好型 | 你有自己的标准，模型不知道 | 忠实度——还在按你的规矩办事吗 |
小红书Skill就是补能力型的典型下场——模型学会了，Skill从帮手变累赘。标题生成Skill是偏好型——模型自己会起标题，但不知道怎么按你的标准起。
第二问：输入、输出、边界是什么？
这是Skill的契约——没这个契约，连它干没干活都判断不了。
第三问：单Skill，还是主Skill套子Skill？
| 场景 | 方式 |
|---|---|
| 解决问题 | 一个Skill干到极致：插图、排版、标题各管各的 |
| 解决流程 | 主Skill管编排，子Skill管执行 |
三、Skill和Agent到底什么关系？
| 概念 | 角色 | 特点 |
|---|---|---|
| Agent | 决策者 | 看环境、定计划、选动作、看反馈、修正自己，活的推理循环 |
| Skill | 操作手册 | 告诉执行者"按这个步骤做"，不观察、不决策、不反思 |
- Agent：运行时反思
- Skill：设计时迭代
把Skill当Agent设计，会给它不该有的自由度；把Skill当手册设计，才能做测试、对比、保鲜期检查。
四、Skill怎么长出来的？归纳，然后演绎
设计Skill的思维过程，本质是归纳和演绎来回倒。
| 阶段 | 方法 |
|---|---|
| 归纳 | 拆解思维：从普遍到抽象，找共性 |
| 演绎 | 把共性和规律写成约束、规则、边界 |
归纳的具体做法
- 定标准：什么是好结果，必须有标准
- 翻素材：把最好的输出翻出来，一个个拆共同点
- 找共性：提炼套路，做成规则
- 反推约束：什么容易让输出偏离标准，写成反面约束
风格种子与约束声明
| 方法 | 用途 | 示例 |
|---|---|---|
| 风格种子 | 给Agent一个方向，引导它朝某个风格靠 | 口语化、有画面感、金句加粗 |
| 约束声明 | 告诉Agent绝对不能做什么 | 不能自创格式、不能改原文内容 |
五、三种对比：用数据替掉感觉
| 对比类型 | 做什么 | 说明 |
|---|---|---|
| 基准测试 | 有Skill vs 没有Skill | Skill真的比裸模型强吗？ |
| A/B测试 | 旧版本 vs 新版本 | 改了之后效果变好还是变差？ |
| 性能测试 | 旧模型 vs 新模型 | 模型升级后Skill效果有变化吗？ |
关键规则：每次线上出了坏例子，必须沉淀成新的回归用例——同一个坑不能摔两次。
六、一个Skill的一辈子：从出生到退休
开发阶段：8步循环
定义任务 → 写草稿 → 小规模测试 → 看结果
→ 人工复核 → 修改 → 扩大测试集 → 继续迭代这是MVP思维：先用最小劲做出能跑的东西，靠反馈推着改进。
CI/CD流水线
改 → 测 → 审 → 发| 环节 | 说明 |
|---|---|
| 改 | 任何修改用版本管理管住，出问题随时回滚 |
| 测 | 自动跑测试集，回归测试+版本对比同时上 |
| 审 | 人只看报告：整体好于旧版本→发；明显退步→回去改 |
| 发 | 打版本标签，发布 |
保鲜期检查
- 补能力型Skill：模型升级后可能过时，evals告诉你什么时候发生
- 偏好型Skill：你的标准变了，它还在往过时方向拉
七、从造一个Skill，到管一群Skill
Skill不是提示词，是一份交互策划书
一个熟透了的Skill，不是一段长提示词，是你和Agent之间的一份交互策划书：
- 什么情况启动
- 启动后按什么流程走
- 每一步用什么格式说话
- 哪里是变量，哪里是死规矩
- 什么时候停，什么时候叫别的Skill帮忙
给Agent分配两种脑子
| 类型 | 管什么 | 用啥约束 |
|---|---|---|
| 理性脑 | 精确、结构化、可验证 | JSON schema、YAML、、MUST声明 |
| 感性脑 | 模糊、创造性、要审美 | 风格种子、自然语言描偏好 |
判断标准：这个任务的输出，能不能写成"if A then B"的规则？
- 能 → 理性脑，用JSON锁死，改规则时跑回归测试
- 不能 → 感性脑，用风格种子引导，改规则时用Comparator做A/B盲测
四大骨架
| 骨架 | 说明 | 类比 |
|---|---|---|
| 流程骨架 | 先干啥、后干啥、分支条件 | 时间线 |
| 规范骨架 | 每步按什么标准来 | 锚点 |
| 能力骨架 | 谁来干（子Skill/工具/API/裸模型） | 工具箱 |
| 任务骨架 | 这次要解决什么问题 | 起点和终点 |
好的Skill系统，就像搭乐高——面对新需求，不是从零写提示词，而是从四个维度各抽合适模块，拼成新策划书。
搭新系统的三步走
- 先写任务骨架：输入什么、输出什么、怎么算成功
- 再翻能力库：有没有现成Skill能复用？考虑给理性脑还是感性脑
- 最后串流程和规范：画出步骤图，标出硬规矩
大部分时间不是在"创造"，而是在"组合"。组合的速度比创造快十倍。
八、一个小故事
A是提示词高手，库里塞了几十个Skill，每次做新项目第一反应是"新写一个"。
B是系统思维者，Skill不到十个，每次先花十分钟用四大骨架拼一遍。
A的产出很高，但总觉得累。B的产出也高，但他不累——他在用系统，不是用蛮力。
B的秘诀：Skill不是你的武器库，是你把脑子里的隐知识，变成能传给明天自己的工程资产。
总结
| 层次 | 靠什么 | 特点 |
|---|---|---|
| 写提示词 | 灵感 | 一次性的 |
| 设计Skill | 工程 | 可重复、可验证 |
| 驾驭Skill系统 | 全局视角 | 可组合、可迭代 |
Skill不是攒得越多越牛。留下来的每一个，都得是经过验证的、值得维护的工程资产。
关键词：Skill开发, 工程思维, AI技能, Skill测试, Skill生命周期, Skill系统设计, CI/CD
