面向不写 agent 代码、但想给 AI 配一套「能力插件」的普通人。开篇为什么你的 skill 总不好使如果你给 AI 写过 skill大概率撞过这两堵墙第一堵墙是——AI 压根不用它。你明明写了一个代码审查 skill结果让它 review 代码时它该怎么干还怎么干根本没翻你写的那份东西。第二堵墙是——它用了但做得不对。skill 是被加载了可输出跟你想要的差了十万八千里你只好在文档里不停加必须“一定”“禁止”越加越长效果却越来越玄学。这两堵墙背后其实是同一个误解很多人把写 skill当成写一篇说明文档——以为只要把要求写清楚、写全AI 自然会照办。但真相是写 skill 更像是在给一位很聪明、但记性和注意力都有限的新同事设计一份会被翻开、翻开后能照着做的工作手册。文档写得全不等于会被读被读不等于会被执行。讲这件事与其干巴巴讲理论不如找一个现成的好范本来拆。这篇文章选的范本有点特别——它叫skill-creator是一个教 AI 怎么写 skill 的 skill。它特别在哪它把怎样才算一个好 skill的方法论直接写进了自己的实现里。所以我们可以反过来读它它要求别人怎么做往往正是它自己被做好的方式。这篇文章就从它身上倒推出几条普通人也能用的原则。我们先从最基础的两件事讲起skill 到底是什么以及它凭什么能被读得动。第一章先建立直觉——skill 到底是什么它不是程序是手册 工具箱很多人第一次接触 skill会下意识觉得它是某种后台运行的小程序我装上它AI 就多了一个功能模块像手机装 App 一样。这个直觉是错的而且这个错误会让你后面写 skill 时处处别扭。我们先把魔法感拆掉说三个朴素的事实skill没有自己独立的 AI 模型跑你 skill 的还是当前这个 AIskill没有编译器、没有运行时不会有一段代码在那里逐行执行你的流程;skill 的本体就是几个文本文件——核心是一个叫 SKILL.md 的 Markdown 文件外加可选的脚本、文档、模板。那它凭什么能增强AI答案朴素到有点反高潮skill 的全部作用就是在合适的时机把一段预先写好的文字塞进 AI 的上下文里让 AI 照着这段文字去做事。“上下文”context你可以理解成 AI 当前对话的工作记忆——它此刻能看到的所有内容。skill 干的事就是往这块工作记忆里在对的时候塞进对的内容。所以更贴切的类比是现实世界skill 世界公司通讯录里每个岗位的一句话简介description决定要不要找这个人岗位的详细操作手册SOPSKILL.md正文决定具体怎么做手册里提到的专用工具、表格模板scripts/、assets/、references/写 skill本质上就是在写一份给 AI 看的岗位手册——而不是在编程。一个真实的例子skill-creator 被触发的那一刻拿我们的范本举例。当你对 AI 说帮我做一个处理 PDF 的 skill时背后发生的事大致是AI 扫一眼当前所有 skill 的一句话简介发现有个叫 skill-creator 的简介里写着创建新 skill、改进 skill……跟你的需求对上了AI 决定翻开这本手册于是 skill-creator 的 SKILL.md 正文486 行被整段塞进上下文接下来 AI 读到的不是什么 PDF 知识而是一份操作流程先问清楚你想要什么、再写草稿、再帮你验证、再迭代、最后打包。注意这里的关键skill-creator 没有执行任何代码它只是让 AI 读到了一份 SOP然后 AI 按这份 SOP 扮演起skill 作者的角色。这就是 skill 的运作全貌。把这个直觉立住后面所有原则你都会觉得顺理成章——因为它们本质上都在回答同一个问题既然 skill 就是在对的时候塞进对的文字那怎么保证它在对的时候被塞进来、塞进来之后又真的有用这恰好引出最关键的机制它凭什么能被读得动。第二章原理一——三层加载决定 skill读不读得动上下文是稀缺资源不能一次全塞上一章说skill 的作用是往 AI 的工作记忆里塞内容。但这块工作记忆是有限的——它要同时装下你们的对话历史、AI 自己的思考、其他可能用到的 skill、还有你现在的问题。每一段文字都在抢这块有限的空间。这就带来一个矛盾你希望 skill 写得足够详细这样 AI 才知道每个细节怎么处理但如果每个 skill 都把详细的一切一股脑塞进上下文工作记忆很快就爆了AI 反而会看不过来“记不住重点”。skill 体系解决这个矛盾的办法叫渐进式披露Progressive Disclosure——说人话就是分层加载要用到了才展开。三层加载是怎么分的skill-creator 把内容分成三层按被加载的时机区分第一层name description名片——永远在场这是每个 skill 的一句话简介非常短大概几十到一百多字。它始终待在 AI 的工作记忆里作用只有一个让 AI 在每次对话时都能扫到判断这个 skill 现在用不用得上。第二层SKILL.md 正文手册——被选中才加载只有当 AI 根据第一层的名片决定我要用这个 skill时正文才会被整段读进来。这是真正的操作说明理想情况下控制在 500 行以内。第三层scripts / references / assets工具箱——按需取用更细的文档、可执行脚本、模板文件等放在这一层。AI 只在确实需要时才去读其中某一个文件平时它们安安静静躺在文件夹里不占用工作记忆。用一个生活场景串起来就很好懂电梯里贴的部门小纸条第一层「财务找小王报销发票对账都归他」——每个人每天都能扫一眼小王抽屉里的报销操作手册第二层你真要报销了他才把手册翻出来手册里提到的报销系统、专用表格第三层手册写金额计算请用这个 Excel 模板到那一步才打开模板。没人会把整本手册和所有表格都贴在电梯里——那样谁都看不过来。skill 的三层加载就是同一个道理。skill-creator 自己就是这么干的回头看我们的范本它把渐进式披露用得很彻底主流程怎么创建 skill、怎么迭代、怎么打包写在 SKILL.md 正文里打分的详细规则被单独拆到 agents/grader.md只有当 AI 真的要去给测试结果打分时才会被提示去读这个文件各种数据文件的格式约定拆到 references/schemas.md平时根本不加载只有要手写某个 JSON 时才去查。它的目录结构长这样skill-creator/ ├── SKILL.md # 第二层主流程被触发时加载 ├── agents/ │ └── grader.md # 第三层打分细则用到才读 └── references/ └── schemas.md # 第三层格式规范查的时候才读而 SKILL.md 正文里会有这样的指路牌——明确告诉 AI 什么时候该去翻第三层需要给结果打分时去读agents/grader.md要手写某个数据文件时去references/schemas.md查准确格式。这一句指路牌非常关键。渐进式披露能成立前提是上层得讲清楚下层在哪、什么时候去读——否则拆出去的文件就成了没人翻的死文件。可操作建议如果你只想记三条记这三条正文别贪长。SKILL.md 尽量压在 500 行以内。太长不是更全面而是会稀释重点让 AI 在长文档里抓不住主线。把不常用的细节拆出去。冗长的格式说明、边角案例、参考资料统统挪到单独的文件里。正文只留主干。拆出去的同时留好指路牌。在正文里明确写清楚“遇到 X 情况去读 references/Y.md”。拆分不是把内容藏起来而是让 AI按需找得到。一个简单的自检方法写完 SKILL.md问自己一句——如果我是那位聪明但忙碌的新同事扫一遍这份手册能不能在 1 分钟内抓住’我该按几步走、细节去哪查’?如果不能多半是该拆了。第三章原理二——description 是触发开关决定 skill用不用得上第一堵墙的真正成因回到开篇那个最让人崩溃的问题AI 压根不用你的 skill。很多人第一反应是是不是我功能没写好于是回去把正文改了又改。但其实正文写得再好都没用——因为 AI 根本没走到读正文这一步。上一章讲过决定要不要翻开手册的是第一层的那张名片也就是 description。AI 每次面对你的需求时它做的判断非常简单粗暴扫一遍所有 skill 的 description看哪个对得上。对不上正文写得再精彩也不会被加载。所以 description 不是功能简介那么随意的东西它是整个 skill 的触发开关。这一句话写得好不好直接决定你的 skill 是随叫随到还是形同虚设。两种典型的失败触发开关失灵通常是两个方向方向一该用却不用学名叫 undertrigger描述写得太窄、太含蓄。比如你写生成数据看板但用户说的是把这个月的销售数字做成图给我看看——字面上对不上AI 就没触发。skill-creator 对这个问题专门有个提醒很有意思它说现在的 AI有不爱用 skill的倾向所以建议把描述写得稍微主动一点。它给的对比是偏弱的写法「如何搭建一个展示内部数据的看板。」更主动的写法「如何搭建展示内部数据的看板。只要用户提到看板、数据可视化、内部指标或想展示任何公司内部数据——哪怕没明说看板二字——都应使用本 skill。」后者把什么时候该用我摊开讲透了触发率自然高。方向二不该用却乱用false trigger反过来描述写得太宽太泛比如处理各种文档结果用户一提到任何带文档字样的需求都把它勾出来哪怕那需求其实该用别的工具。一个反直觉的事实太简单的任务谁也触发不了这里有个很多人想不到的点skill-creator 特意点明了简单的、一步就能做完的任务比如读一下这个 PDF即使描述完全匹配也可能压根不触发任何 skill。为什么因为 AI 判断要不要翻手册时还有一层隐含逻辑这事我自己直接做是不是更快读个 PDF、看个文件它用最基础的能力就解决了犯不着大费周章去加载一个 skill。只有当任务足够复杂、多步骤、或需要专门知识时AI 才觉得这事值得先查查手册。这个事实对你有个直接影响别拿过于简单的场景去测试你的 skill 是否触发那测不出任何东西。要用真实、有点复杂度的需求去验证。skill-creator 较真到什么程度普通人写到把描述写主动点也就够了。但 skill-creator 作为范本把这件事做到了极致——它不靠手感靠数据它内置了一整套脚本来科学地优化描述。流程大致是先准备一批真实的用户问法标好这个该触发“这个不该触发”用脚本run_eval.py拿当前描述去实测——每条问法跑 3 次算出真实触发率把该触发却没触发不该触发却触发了的失败案例喂给 AI让它改写描述improve_description.py改完再测反复几轮最后选一个表现最好的版本。它甚至给描述定了硬上限1024 个字符。为什么要限制长度因为这张名片是要始终待在工作记忆里的——它越长占用的空间越多挤占的是所有对话的空间。所以它逼你用最精炼的话讲清做什么 何时用而不是写成一长串这种要触发、那种不要触发的清单。可操作建议你不需要那套脚本但可以借走它的思路description 必须同时回答两件事做什么WHAT什么时候用我WHEN。只写功能不写场景是最常见的错误。用用户的真实说法别用内部黑话。用户不会说执行 PDF 文本抽取他会说帮我把这个 PDF 里的表格弄到 Excel 里。描述里多放些用户真会说的词。宁可稍微主动一点。在合理范围内把边缘但相关的场景也写进什么时候用我对抗 AI懒得用 skill的倾向。写完拿 2-3 个真实复杂场景自测直接问 AI看它会不会主动用你的 skill。不触发先改描述而不是改正文。第四章原则一——讲为什么少用必须和禁止把 AI 当聪明同事而不是提线木偶前面解决的是读不读得到、用不用得上。从这一章起我们谈读到之后怎么让它做得对。普通人写 skill 最常见的本能动作是堆命令。「必须用 X」「一定要先 Y」「禁止 Z」「永远不要……」满屏的必须“禁止”恨不得把每一步都焊死。skill-creator 对这种写法的态度非常鲜明几乎是直说的满屏的大写 ALWAYS / NEVER 是一张黄牌。一旦你发现自己在疯狂下硬命令往往说明你没把为什么讲清楚。它的理由是今天的 AI 已经相当聪明有不错的换位思考能力。当你解释清楚一件事为什么重要它往往能举一反三、灵活应对而当你只给它一条死命令它在命令没覆盖到的边角场景就会卡壳或乱来。一个对照例子同样是要求用某个库提取 PDF 文本生硬的写法「必须使用 pdfplumber禁止使用其他库。」讲理的写法「提取文本用 pdfplumber因为它对表格和多栏排版的处理比其他库更稳遇到扫描件纯图片时它会失效这种情况改走 OCR。」后者多说了两句为什么和什么情况下例外AI 拿到的就不只是一条规则而是一套可迁移的判断依据。碰到你没预料到的扫描件它知道该怎么办而前者只会一条道走到黑。例外关键的、易错的节点仍然要下狠手讲理是默认策略但不是说完全不用硬约束。skill-creator 自己也保留了少数全大写的强命令——而且都用在最容易被偷懒跳过、一跳过就出问题的关键节点上。最典型的一处是它反复强调甚至破例用了全大写先把测试结果摆到人面前再动手改 skill。因为它太了解 AI 的坏习惯了——AI 容易自己跑完测试、自己看一眼、自己就把 skill 改了跳过了让人审一下这一步。这一步一旦被跳过整个迭代就失去了人的把关。所以这里它不讲理直接下死命令。这给我们的启发是硬约束要省着用用在刀刃上。默认讲道理让 AI 理解、灵活应对只在一旦做错代价很大、且 AI 有倾向做错的关键路口才下硬命令。可操作建议写完一条规则习惯性追问一句为什么把答案也写进去。数一数你的 SKILL.md 里有多少个必须/禁止/一定/永远。如果一屏好几个回头把大部分改写成因为……所以建议……。留 1-2 个真正关键的硬约束就好多了就贬值了——满纸都是重点等于没有重点。第五章原则二——为用一百万次而写别为眼前的例子打补丁overfit最隐蔽的陷阱这是 skill-creator 反复强调、也最容易被忽视的一条。写 skill 时你手头通常只有两三个具体例子。你拿这几个例子反复调调到它们都完美了就觉得成了。但问题在于skill 是要被复用成千上万次的面对的是无数你现在还想象不到的场景。如果你的 skill 只对手头那几个例子好使换个说法、换份文件就翻车——那它基本没用。这个陷阱有个名字叫overfit过拟合你以为在改进 skill其实只是在往少数样本上贴补丁。它的典型症状是每遇到一个翻车案例你就往 skill 里加一条特例——“如果遇到这种文件就这样处理”“如果用户这么问就那么回答”。规则越加越多skill 越来越长、越来越脆换个没覆盖到的情况照样崩。skill-creator 的解法它的应对原则一句话概括从失败里归纳而不是罗列。具体体现在两个地方其一在改进 skill 时它明确要求从反馈中提炼出更普遍的规律而不是堆砌这个 query 要触发、那个 query 不要触发的清单。遇到顽固问题它甚至建议你换个比喻、换种思路重写而不是再加一条特例。其二前面提过的描述的1024 字符硬上限本质上就是一道防 overfit 的物理护栏——它从空间上就不允许你把描述写成一长串特例清单逼着你提炼通用表达。可操作建议每加一条规则前问自己「这是一条通用原则还是只为了救眼前这一个例子」如果是后者警惕。遇到反复修不好的顽固问题别急着加第十条特例。退一步换一种说法或思路整段重写——往往比打补丁更有效成本也不高。心里始终装着那句话我写的是给未来无数场景用的手册不是给手头三个例子的答案。第六章原则三——确定的事交给脚本别让 AI 每次重造轮子AI 擅长判断不擅长每次都一模一样AI 很适合做需要理解、判断、写作的活但它不适合做那种每次都该严丝合缝、一字不差的机械活——因为它每次发挥都可能有细微差别而有些事差一点就出错。这类事情的正确做法是写成脚本或模板让 AI 去调用而不是每次现场重写。skill-creator 怎么做的它把好几件机械且要求精确的事都固化成了 Python 脚本格式校验quick_validate.py检查 skill 的名片格式合不合规——名字是不是规范、描述有没有超长、有没有非法字符。这种检查规则固定、不容差错交给脚本对就是对、错就是错打包package_skill.py把 skill 文件夹打成一个可安装的 .skill 包并且打包前先自动跑一遍格式校验不通过就不让打包结果聚合aggregate_benchmark.py把多次测试结果按固定格式汇总成统计数据。更值得学的是它的一条自我进化建议如果你发现 AI 在每个测试里都各自独立地写了同一个辅助脚本比如都写了个生成 Word 文档的小程序那就是个强信号——应该把这个脚本写一次固定放进scripts/让 skill 直接用它。这一条特别能体现脚本化的价值与其让 AI 每次重新造一遍轮子还可能每次造得不太一样不如造好一个轮子让它复用——又快、又稳、又一致。可操作建议审视你的流程哪些步骤是每次都该一模一样的格式检查、固定计算、套模板把它们脚本化或模板化。哪些步骤是需要看情况判断的理解需求、组织语言、做取舍这些才留给 AI。你不会写代码也没关系——可以让 AI 帮你把这些机械步骤写成脚本关键是意识到这步不该靠 AI 临场发挥。第七章原则四——闭环验证 人来把关别凭感觉说行了skill 不像代码所以更要测一测、看一看普通程序有个好处同样的输入永远是同样的输出对错很确定。skill 不一样——它依赖 AI 的理解同一份 skill不同场景下的表现会有波动。正因为这种不确定性凭感觉觉得写好了是最危险的。你觉得好不代表换个真实用户、换个真实场景还好。skill-creator 把验证做成了它整个流程的主心骨循环是这样的写几个真实的测试场景用户真会这么说的话让 AI 带着 skill 去跑这些场景把结果摆到人面前看——而不是 AI 自己看自己改根据人的反馈改进 skill重复直到满意。注意第 3 步——前面讲硬约束时提过它甚至用全大写强调先让人审再动手改。这背后是一个朴素但重要的认知AI 不适合当自己作业的唯一判官。它写的 skill、它跑的结果、它自己评判好坏——这个闭环里缺了人就容易自说自话。轻量版闭环skill-creator 那套带打分、带统计的完整流程对普通人来说太重了。但闭环的精神你完全可以低成本照搬准备 3 个你真实会遇到的场景亲手让 AI 用你的 skill 跑一遍自己看结果。就这么简单。这一下就能暴露出描述触发不了“输出格式不对”漏了某一步之类的大部分问题。关键有两点场景要真实。别用帮我处理一下文件这种空泛的测试用你工作里真会发生的、带具体细节的需求。人要亲自看。别让 AI 跑完自己说看起来不错。你才是最终标准。不满意就回去改 skill再跑一遍。改的时候记得用上前面几章的原则——讲为什么、防 overfit、该脚本化的脚本化。第八章反向总结——从 skill-creator 提炼的好 skill 检查清单我们从一个教 AI 写 skill 的 skill身上倒推出了一条完整的脉络。把它压缩成一张你写完每个 skill 都能对照的清单维度自检项对应原理能被用上description 同时写清了做什么 什么时候用我用的是用户真实说法触发开关能被用上描述稍微主动一点覆盖了相关的边缘场景对抗 undertrigger读得动正文精简尽量 500 行细节拆到子文件渐进式披露读得动拆出去的文件正文里留了什么时候去读它的指路牌渐进式披露做得对多解释为什么必须/禁止只留在最关键的 1-2 处讲理 命令做得对写的是通用原则不是为眼前几个例子贴的补丁防 overfit做得稳机械、要求精确的步骤写成了脚本/模板确定性脚本化靠谱用 3 个真实场景亲手跑过、亲眼看过闭环 人把关如果要把这一切再浓缩成一句话那就是写 skill 的本质不是写一篇说明文档而是替未来无数次 AI 对话提前准备好一份——会被翻到、翻开后读得懂、读懂后能照着做、做出来还靠谱的——经验手册。会被翻到靠 description读得懂靠精简和分层照着做靠讲理而非堆命令靠谱靠脚本化和验证闭环。这几件事做到了你的 skill 就不会再卡在开篇那两堵墙前面。彩蛋最好的范本是它自己最后留一个有点意思的观察。skill-creator 教别人怎么写好一个 skill——而它教的每一条恰好都是它自己被写好的方式它讲渐进式披露自己就把打分细则、格式规范拆进了 agents/ 和 references/它讲description 要精准触发自己就内置了一整套优化触发率的脚本它讲确定的事交给脚本自己就用脚本管校验、打包、聚合它讲验证要闭环、要人把关自己整个流程的主心骨就是测—看—改的循环。这种言行一致本身就是判断一个 skill 好不好的最朴素标准——一份好的 skill应该首先说服得了它自己。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】