如何寻找和构建属于自己的科研 Skill
从反复出现的真实工作入手，先拆清工作模式、寻找现成方案，再把稳定的输入、步骤、输出和检查固化下来。
在体系中的位置
识别科研 Skill 的五类位置后，把自己的重复工作固化成可复用能力。
AI 工作系统入门 · 第 4 篇
这两天有人问我：如果想给自己搭一个 Skill，应该从哪里开始？
在开始前，我建议大家对 Skill 有一个更直观的认识：它可以理解为一段被固化下来的重复工作流程，和我们过去习惯的提示词有明显区别。
真正难的是前面那一步：你要先知道，自己到底想把哪一种工作固定下来。
很多人把 Skill 想成一段更长的提示词。这个理解会带来一个问题：你会拼命写要求、写语气、写禁忌，最后得到一大段很复杂的指令，但它只能解决一次任务。
下次换一个材料、换一个场景、换一个目标，它又不稳了。
我理解的 Skill 是一套小型工作流。它要回答的是一个更长期的问题：
以后每次遇到这类工作，AI 应该按什么顺序做，读什么材料，产出什么东西，怎么判断做得对不对。
所以，如果一个人问我怎么搭 Skill，我会先让他安装并调用三个 Skill，按三步走：
- 用
brainstorming把自己的工作模式拆清楚。 - 用
find-skills先看有没有现成 Skill。 - 用
skill-creator把自己的稳定流程固化下来。
这三步走完，大部分个人 Skill 需求就能收住。
第一步，先用 brainstorming 把工作说清楚
很多 Skill 做不好，是因为一开始就跳到了“怎么写”。
但一个 Skill 能不能稳定触发，能不能交付你想要的结果，最先取决于工作定义清不清楚。
我会先用 brainstorming 做一件事：把模糊需求拆成可执行的工作设计。
在开始前，你可以先回答这张表：
| 字段 | 要回答的问题 |
|---|---|
| 重复任务 | 我反复让 AI 做的是什么 |
| 触发场景 | 用户说什么时应该启动这套流程 |
| 输入材料 | 需要文件、链接、笔记、数据还是上下文 |
| 固定步骤 | 每次都要按什么顺序做 |
| 输出格式 | 最后应该给我文稿、表格、代码还是检查结果 |
| 检查方式 | 怎么判断这次做得好不好 |
这张表看起来简单，但它能筛掉很多不适合做 Skill 的想法。
比如你只是偶尔想让 AI 改一段话，这不一定需要 Skill。直接写清楚要求就行。
但如果你每周都要做公众号选题，每次都要看 Get 笔记、看历史表现、给三条核心判断、再写任务单，这就很适合做成 Skill。
因为它满足四个条件：
| 条件 | 说明 |
|---|---|
| 会重复出现 | 以后还会经常做 |
| 步骤相对固定 | 每次大致都按同一套顺序 |
| 输出格式稳定 | 最后总是产出同一类东西 |
| 可以检查好坏 | 有明确的质量标准 |
能被 Skill 固化的工作，通常是一套会重复出现、可以被检查的动作。
这个时候你就可以把这件事拿来和 brainstorming 讨论了，可以直接把下面这段话发给 AI：
请按照 brainstorming 的方式和我讨论这个需求：我想要 XXX。先帮我确认重复任务、触发场景、输入材料、固定步骤、输出格式和检查方式。
这一步做完以后，你才知道自己要建的到底是什么。
第二步，用 find-skills 先找现成能力
工作模式拆清楚以后，我不会马上自建。
我会先用 find-skills 查一遍：有没有现成 Skill 已经覆盖了 60% 到 80% 的需求。
原因很现实。
很多需求其实已经有人做过了。比如写测试、做前端性能优化、生成演示文稿、整理文档、代码审查、发布流程检查，这些任务在 Skill 生态里很可能已经有成熟版本。
这一步无需找到一个完全一样的 Skill。
目标是判断三件事：
| 判断 | 说明 |
|---|---|
| 有没有现成 Skill | 能不能直接装来用 |
| 能覆盖多少需求 | 覆盖 60% 以上就值得试 |
| 缺口在哪里 | 是触发场景不同，还是输出格式不同 |
如果现成 Skill 已经能解决大部分问题，那就先用现成的。
如果现成 Skill 只能解决一小部分，也不要急着丢掉。它至少能告诉你一件事：别人是怎么定义这个任务边界的。
这对自建 Skill 很有用。
比如你想做一个“论文结构化精读 Skill”。你可以先找有没有文献阅读、PDF 总结、学术写作类 Skill。看完以后再决定，自己要补的到底是字段表、引用核查、矩阵输出，还是某个学科的特殊判断。
先查现成 Skill，本质上是在查边界和参考答案。
这一步能避免重复造轮子，也能让你少走很多弯路。
第三步，用 skill-creator 把流程固化下来
前两步做完，才轮到 skill-creator。
这一步的重点，不在于把一段提示词塞进文件里。
它要把前面那张工作模式表，变成 Agent 能读懂、能触发、能执行、能检查的说明。
如果这个 Skill 涉及固定脚本、模板、示例文件，还可以继续加 scripts、references、assets。
但一开始不要急着做复杂。
我更建议先做一个能跑通的小版本。
真正重要的是后面的测试。
你要拿真实任务试它，不能只看文件写得好不好。
测试完以后，你会发现很多问题。
有的 Skill 触发太少，明明应该用却没用。有的 Skill 触发太多，普通问题也抢着接。有的 Skill 步骤写得太满，导致每次都做过头。
这些都正常。
Skill 要靠迭代变稳，很少一次写完。
什么时候值得做成 Skill
最后给一个更简单的判断。
如果一件事只做一次，直接让 AI 做就行。
如果一件事会反复做，而且每次你都要重复解释背景、重复提醒格式、重复纠正边界，那它就值得考虑做成 Skill。
我现在判断一项工作要不要 Skill，主要看四句话：
- 我是否经常做这件事？
- 我是否每次都要重复讲一遍规则？
- 这件事有没有相对固定的输入和输出？
- 做完以后能不能检查好坏？
四句里有三句是肯定，就可以先做一个小 Skill。
不要急着做大。
先让它接住一个真实场景。
等它连续几次都能帮你省掉重复解释，再把它扩成更完整的个人工作流。
这才是我理解的 Skill 构建：把你已经摸清楚的工作方式，一点点交给 AI 稳定复用。
