大数跨境
首页
>
写Skill哪几条不许商量？
>

写Skill哪几条不许商量？

写Skill哪几条不许商量？ AI驱动数字化转型
2026-10-24
5
导读：一份 skill 最容易写多的地方，不是步骤，是那些"最好注意一下"的话。模型的注意力是按密度分的：给十条它按十条读，给一百条它按一百条读。放进去越多，每条分到的越少。写得全不等于写得好，只等于每条都
写 skill 最容易犯的错，是把它当成备忘录。
生怕漏了什么，于是想到的全写进去：注意事项、历史教训、例外情况、几个例子。文件越写越长，写的时候挺顺手，用的时候越来越不好用。
翻一批实际在用的 skill，问题反复落在同一件事上：把"写下来了"当成"管住了"。


01
先分清骨架和参数

一个 skill 里有两类东西混在一起。
一类换任何任务都成立：先读什么、什么时候必须停下来问、做完查哪几项、结果写到哪里。这些是骨架。
另一类是某一个人、某一个项目、某一个领域才有的：文件路径、项目名、术语表、特定偏好。这些是参数。
最常见的错是把两者焊在一起。一焊死，这个 skill 就只能给一个人用。
有一份七百多行的写作 skill，里面使用者名字出现了九十次，平均每八行一次。换个人装上去，从头到尾都得改。这不是个别写法，是骨架和参数混在一起的必然结果。
判断方法很简单，把每条拿出来问一句：换一个人、换一个项目，这条还成立吗？成立就留在骨架里，不成立就变成参数，让人自己填。
分开之后还有一个问题：一个 skill 该管多大范围。


02
按事情的性质切

做 PPT 常常要两个 skill 才够：一个管成套，一个管单页。看着重复，其实不是。做一页要的是版式结构，做一套要的是叙事顺序和页面之间的承接。两件不同性质的事合在一起，哪头都做不精。
反过来，同一性质的任务不该拆开。几个功能重叠的 skill 同时装着，每次触发前模型要先花一轮判断该调哪个，这一轮白费。
切分的依据是任务性质，不是领域名。"法务版""技术版""英语版"这种切法看着整齐，切完每个都薄，还互相打架。
切得再准，里面写的话也可能一句都不算数。


03
每句话都要能被检查

翻几份 skill，"注意""尽量""应该""确保""保持"这类词能数出三十多次。随手挑一条：某份里写着"引语尽量转述"。
"尽量"是多少？改到几成算合格？一条都没改算不算违背？没有标准。模型读完只能假装遵守，输出还是照原来的习惯走。写的人觉得交代过了，实际什么都没约束住。
换成能判定的写法：不写"引语尽量转述"，写"直接引语超过两句就改成转述，保留原话的那一句必须带出处"。
差别在于后半句可以被检查。判据一旦能被机检，就不用指望模型自觉。有的写作 skill 配了脚本，把禁用词和硬指标写成规则，跑一遍直接列出第几行违反了哪条。能被查出来的错，不用等到交付那天才发现。
写判据的麻烦在于，得先把自己的判断说清楚。多数人写不出判据，不是不会写 skill，是方法本来就模糊，说得清"我觉得这样好"，说不出好在哪。写 skill 会把这层模糊逼出来，这是它额外的用处。
能写清的判据，还得有人真的去跑。

04
验收写进流程

凡是不做也不会立刻出事的步骤，最后一定会被跳过。
这不是自律问题，是流程设计问题。讲解跳过了，你知道自己没听懂；笔记跳过了，下次找不着；验收跳过了，当下什么感觉都没有，直到真正要用的时候才发现不会。
所以这类步骤不能写成建议，要写成必经节点，而且交给外部检查：脚本必须跑过、结果文件必须存在、报告里必须带上某个字段。留给自觉的检查，等于没有检查。
"机检必改为零才算完稿"这种话才有约束力。一篇稿子里十几处破折号和禁用词，肉眼扫两遍发现不了，脚本一跑全列出来。
流程要能接着跑，得让下一次知道上一次做到哪儿了。


05
状态写进文件

对话有寿命，文件没有。
判断方法：换一个全新对话，只给这一个文件夹，它能不能接着干？接不上，说明状态还锁在对话里。
要写清楚的是三件事：写进哪个文件、什么格式、下次从哪读。缺一样，下次就得靠人重新交代一遍。
还有一层更容易漏的：读的顺序也要写进去。笔记攒多了以后，每次全读一遍会占满上下文。可行的做法是分层，当前任务的记录放最外层，历史归档放子目录，明确写"先读哪个，需要时再翻哪个"。归档不是删文件，是把它挪出默认读取范围。
该分的分了，该查的也查了，文件还是会慢慢变胖。


06
skill 会自己变胖

两个 skill 摆在一起看最说明问题：五十行那个装好之后只改过一次，七百多行那个几乎每周都在动。
打开长的那个，前四十五行里有三十七行是版本变更记录。改了什么、因为哪句话被批、又补了哪一类扫描。每条都写得挺详细，当时确实有用。
问题是这些记录对执行当下的任务没有价值，但每次加载都要占位置。skill 一被触发，开头这些内容跟着进上下文，跟真正要用的规则抢注意力。
它胖起来没有痛感：每次改都往最前面追加一段，追加永远比整理省事。改十次就多出十段，每次只多一点点，谁也不觉得有问题。
难处在于好处和代价不在同一个时候：加一条内容，当下就拿到好处，代价要等每次执行时才付。人只感受得到眼前那个。
除了往上追加，还有两种写法会让它变大。
一种是教程体。开头写"场景"，中间"步骤一、步骤二"，配上"示例"，整整齐齐像一篇博客。这种结构是写给人看的，人可以跳读，扫两眼就知道大概。skill 是逐行发给模型执行的，跳读这件事不存在。教程里那些冗余，到这里全是实打实的开销。
另一种是重复声明。同一条规矩在三个地方各说一遍，怕模型漏看。实际效果是三个版本互相打架，模型挑一个执行，你也不知道它挑了哪个。
胖了怎么办？不是硬砍，是挪。那份写作 skill 主文件七百多行，真正每次都要用的不到一半，剩下的挪进旁边的参考文件，主文件只留"什么时候做什么"，细节等真需要时再翻。主文件短了，模型才看得清哪条是规矩。
砍的时候只问一个问题：这一行，是执行这个任务时需要的，还是当初修改它时需要的？修改历史属于后者，真要留就放另一个文件里，别放在会被加载的那个文件里。


07
什么该留，什么该删

一份 skill 最容易写多的地方，不是步骤，是那些"最好注意一下"的话。
模型的注意力是按密度分的：给十条它按十条读，给一百条它按一百条读。放进去越多，每条分到的越少。写得全不等于写得好，只等于每条都变轻。
该留哪条？问一句就够：违反了这条，会出什么事？答得上来，留着。答不上来，删掉。
答不上来还留着的那些，当时多半也觉得有道理，只是一次都没派上用场。把它们删掉，剩下的自然就短了。短是删出来的，不是省出来的。

【声明】内容源于网络
0
0
AI驱动数字化转型
专注AI，促进智造行业数据衍生，服务智能制造企业的数字化、智能化，聚焦大模型私域部署、大模型微调、数据清洗、AI模型训练、私域知识库及agent技术延展等。行业智能，落地为先。
内容 1109
粉丝 1
AI驱动数字化转型 专注AI，促进智造行业数据衍生，服务智能制造企业的数字化、智能化，聚焦大模型私域部署、大模型微调、数据清洗、AI模型训练、私域知识库及agent技术延展等。行业智能，落地为先。
总阅读14.0k
粉丝1
内容1.1k