写Skill别急着动手，先问自己这四个问题
写Skill别急着动手，先问自己这四个问题
来源类型： 微信公众号文章
日期： 2026-06-02
标签： AI, 办公效率, 网络安全, 编程, 大模型
原文链接： https://mp.weixin.qq.com/s/Vx2o_hHedi37hwV9yLesNw
摘要
你是如何写skill的？ 有个想法直接就写？我之前就是这样的。 不过后来我明白了，做Skill的人，需要有工程思维。不是上来就干，而是干之前要想清楚。 什么叫工程思维？不靠一次性的感觉做决定，靠可重复的验证做判断。 比如说一个Skill"效果好"，跟什么比？好了多少？换个模型还稳吗？以前这些问题只能拍脑袋。 改了指令，跑两个例子瞅一眼，觉得行就可以。后来出问题，你连当初怎么改的都忘了。 有一个思路给了我很大启发：把软件工程里成熟的测试和迭代方法，搬到skill创作里来，并且尽量降低技术门槛，让不懂代码的领域专家也能用起来。 很多写Skill的人不是工程师，他们懂业务，但没工具去验...
核心内容
你是如何写skill的？
有个想法直接就写？我之前就是这样的。
不过后来我明白了，做Skill的人，需要有工程思维。不是上来就干，而是干之前要想清楚。
什么叫工程思维？不靠一次性的感觉做决定，靠可重复的验证做判断。
比如说一个Skill"效果好"，跟什么比？好了多少？换个模型还稳吗？以前这些问题只能拍脑袋。
改了指令，跑两个例子瞅一眼，觉得行就可以。后来出问题，你连当初怎么改的都忘了。
有一个思路给了我很大启发：把软件工程里成熟的测试和迭代方法，搬到skill创作里来，并且尽量降低技术门槛，让不懂代码的领域专家也能用起来。
很多写Skill的人不是工程师，他们懂业务，但没工具去验证两件要命的事：模型升级之后，Skill还跑得动吗？我改了指令，效果真的变好了吗？以前只能靠感觉，靠手工一遍遍试。
Evals、基准测试、版本对比、保鲜期检查。我们后面聊的这些方法，都来自这个思路的延伸。看不懂这些词不会怕，它其实就是评估-对比-测试。
01 问自己：需求值得做成Skill吗？
并不是所有需求，都最适合被固化成Skill。
高频复用，而且流程够固定，才值得制作成skill。
什么叫高频？你每周都在做，甚至每天都在做。
什么叫流程固定？每次做的步骤、标准、产出格式，都差不多。
skill的本质，就是解决你当下需求的流程指导手册。
最近我在想一个问题，我现在用的最多的技能是哪些？哪些已经从没打开过了？
文章插图Skill
每次写完文章都要配图。以前每次都手写图生文提示词，次次重来。后来把常用的画面风格、尺寸、构图偏好全固化成Skill。现在要配图，直接用。
省的不是一次的事，是每一次。
公众号排版Skill
我发文有一套固定习惯：段落空多少、哪里加粗、引用块怎么用、小标题什么格式。以前每次手动调，或者把同样的排版指令重新发给模型。做成Skill之后，一口输入原文，一口输出成品。
固化的是流程，不是某一次的输出。
标题生成Skill
如何起标题以前对于我来说是一个头疼的事情，后来我学到一个非常好的思考思路，主体词+修饰词+句式套路组合+人性(恐惧，欲望)，那基于它的思路，我就可以封装成一个技能，后来可以反复使用这个skill解决问题。
后面就是不断完善标题的技巧的拼图，比如说看到一个文章说某某的标题比较不错，那就直接在句式套路组合中添加。
随着不断积累，当我需要标题的时候，大模型可以在我的skill的组合中选择合适的，给我起标题。
我一般习惯于让AI多给我提供不同方向的标题，给我做选择。
同样的道理，如果要写爆款文章的skill，也是同样的思路，组合拼接，不同爆款文章的架构组合拼接，就是新的"爆款"文章。比如说开头套路+中间转折方式+结尾套路。
N的开头N转折N结尾，就是N^3的套路组合，可以高效地支撑批量内容创作。当然，真正的内容价值仍然依赖于洞察和素材质量，结构只是提效工具，不是万能公式。就是因果理论+方法沉淀+组合拼接。
不同人对于爆款的理解不同，文字习惯不同，虽然它所设计的底层逻辑相似，但还是带有不同人的特色。
前面这些Skill共同点是什么？**
**
固化的是我的流程偏好，不是补模型的能力短板。
反面教材我也踩过。
之前做过一个小红书风格优化Skill。逻辑特简单：把任意文本转成小红书调性，口语化、加emoji、分段短、带感叹词。
当时模型自己还不太会拿捏这种风格，或者说是风格不符合我的习惯，Skill确实有用。但后来模型升级了，自己加的emoji更自然，分寸感更好，而我的Skill还在按旧脚本套固定模板。Skill的输出，反而不如裸模型。后面我就没怎么用了，直接让大模型帮我改了。
这件事教会我一个道理：不是所有需求都值得做成Skill，也不是做出来的Skill都值得一直留着。
02 动手之前，先问三个问题
需求值得做，也别急着打开编辑器。先回答三个问题。
第一问：你是补能力，还是固偏好？
能力补充型，教模型做它原本搞不定的事。比如处理特殊格式的PDF、生成特定结构的文档。模型自己有短板，Skill把技巧编进去。
偏好编码型，模型本来也能做，但你要它按你的规矩来。比如按公司法务标准逐条审合同，每周从多个数据源汇总数据写周报。
两种Skill盯的东西不一样。
补能力的，盯保鲜期，模型升级之后，这Skill还用的上吗？
固偏好的，盯忠实度，它还在按你的规矩办事吗？
小红书Skill就是补能力型的典型下场。模型学会了，Skill从帮手变累赘。
标题生成Skill是偏好型，模型自己会起标题，但不知道怎么按我的标准起。
第二问：输入、输出、边界是什么？
这是Skill的契约。输入什么格式？输出长什么样？绝对不能碰什么？没这个契约，你连它干没干活都判断不了。
第三问：单Skill，还是主Skill套子Skill？
解决问题，一个Skill干到极致。插图、排版、标题，各管各的。
解决流程，主Skill管编排，子Skill管执行。
将来我要是做"文章发布全流程"Skill，会挨个调用排版Skill、插图Skill、标题Skill。
但子Skill各自跑得好，不等于串起来就好。上游的输出格式，可能刚好是下游不喜欢的输入。多Skill组合，必须做集成测试。
目前我还没制作过流程技能，基本都聚焦在解决单一问题上。
三个问题答完，再动手写第一行。
03 Skill和Agent，到底什么关系？
聊到这儿，得澄清一个很多人搞混的概念。
有人说Skill就是轻量版Agent。这个说法听着顺耳，但不准。
Agent是决策者。它看环境、定计划、选动作、看反馈、修正自己。它有运行时的反思能力，是一个活的推理循环。
Skill是一本写好的操作手册。它告诉执行者"遇到这种情况，按这个步骤做"。不观察，不决策，不反思。改进不发生在跑的时候，而发生在你设计它的时候，你改它、测它、迭代它。
拿公众号排版Skill来说就清楚了。它没有自己的想法，只是忠实地执行我预设好的段落间距、加粗规则、小标题格式。哪天我觉得段落间距要改，我不会让它自己拿主意，我会在设计阶段改规则，然后跑测试验证。
把Skill当Agent设计，你会给它不该有的自由度，它开始乱发挥，你又没评估机制管它。当然，有些Skill在设计时也可以在参数范围内定义一些灵活判断的空间，让它在约束下自己选择，但它的边界是预定义好的，不是开放式的自主决策。
把Skill当手册设计，你会盯着操作步骤、输入输出契约、可验证的结果。你可以对它做测试、做对比、做保鲜期检查。
所以，Agent做决策，Skill做执行。Agent在跑的时候反思，Skill在设计的时候迭代。
这个区别不是咬文嚼字，是整个工程化体系的根。
04 Skill怎么长出来的？归纳，然后演绎
搞明白Skill是什么了，下一步是怎么设计。
设计Skill的思维过程，本质就是归纳和演绎来回倒。
归纳的过程中，要学会拆解思维。从普遍到抽象的过程。
拿标题生成Skill举例子。
我把看到的好标题翻出来，几十个，一个个拆
...(内容截断，完整内容请查看原文)
本页由自动化脚本生成，待人工审核补充