做开发这些年我发现自己花在 AI 助手上的时间一大半不是干活而是在“交代背景”。每天早晨打开智能助手准备写站会同步我得把项目背景、技术栈、依赖服务、进度模板重新输一遍代码改完想让它帮忙 review 时又得反复叮嘱“只看问题、不要夸、标出严重级别、用中文回答”轮到整理接口文档我甚至要把以前的示例格式整段贴过去。这些动作单看没几分钟但架不住天天做、处处做。直到有一天我粗略统计了一下发现那些重复出现的提示设定加起来已经快有一份完整需求文档那么长了——那一刻我才意识到问题不是 AI 不够聪明而是我一直在用最笨的方式指挥它。后来我认真研究了各平台陆续推出的 Skills技能功能一下子就想通了与其每次都费劲组织语言现场发挥不如把一整套行为规范沉淀下来遇到同样的事情直接调用。这篇文章我就从自己的真实使用体验出发聊清楚 Skills 到底是什么、它怎么解决重复提示的痛点、怎么设计才不翻车、实际用起来能省多少事。如果你也是高频使用 AI 辅助开发的人被重复提示耗得没脾气这篇内容应该能给你不少可以直接落地的思路。1. 为什么我们总在反复“教”AI做事1.1 每次新对话AI 都是“第一次进组”我们在 AI 助手面前反复粘贴同样的背景说明根源在于它默认没有长期记忆。至少我们目前大多数人能用的模型和产品形态每次新开对话之前的设定就全部清零了。你上周告诉它“代码风格用规范A”“数据库用的是某一种具体数据库”“注释要写中文”这周重新打开窗口它统统不知道。你可能会觉得“这不是很明显的事吗为什么每次都要我重新说”——对问题就在这AI 没有你自己的项目账本它每次都是第一天来上班的实习生你对它来说就是陌生人。这里有个很容易被忽视的点我们自己在写提示词时其实是在做一次“上下文重建”。你要把项目背景、任务目标、输出要求、约束条件一次性组织好信息密度越高AI 发挥越稳定。但这恰恰是最耗神的环节——写提示词比复核 AI 的输出还累。我认识不少同行他们宁愿自己写十行代码也不愿意写一段两百字的提示词就是因为觉得“说不清楚”“懒得组织”。1.2 复制提示词和真正拥有技能是两回事早期大家对付重复提示的办法是建一个“提示词收藏夹”用的时候复制粘贴。这个方法确实有效我到现在也还留着一些经典的零散提示词。但收藏夹有天然瓶颈提示词是静态文本塞不了参数。今天这个任务范围大一点、明天小一点你就要在粘贴完之后手写补充说明这个月要求的输出格式是表格下个月换成了三段式总结你就要重新修改一大段话再复制。本质上收藏夹解决的只是“找得到”并没有解决“用得好”。Skills 和收藏夹的区别在于它不是一个文本片段而是一个带输入参数、带规则约束、带输出模板的小程序。你可以把它理解成一次调用函数——传入不同的参数产出不同形态的结果但骨架是稳定的。类比一下收藏提示词相当于把菜谱拍成照片存在手机相册每次做饭翻出来照着做Skills 相当于找到一位熟悉你口味的厨师你说一句“老规矩”他就知道该放多少盐、几成火候。这个“老规矩”才是技能真正的价值。1.3 既然有效为什么大家还是懒得封装我观察下来大家不用 Skills 主要是三个原因。第一觉得前期投入时间不划算。一个像样的技能可能要写几百字指令感觉比直接复制粘贴还麻烦。第二怕封装完太死板万一需求变了改技能比重新写提示词还费事。第三是不知道从哪里下手没有一个清晰的模板和步骤感觉“这个功能是给高端用户准备的”。我的实测情况是把每天都要用的“周报生成”封装成技能第一版大概花了不到半小时。之后每次使用能省两三分钟而且不用动脑想格式。一天用一次一个月就省下一个多小时更重要的是心里不累。这个“注意力成本”很多人没算进去。另外我还有个感受封装技能的过程本身就是一次对工作流的梳理。你会逼着自己想清楚“我到底希望 AI 怎么帮我干活”“哪些步骤是可以固定的”“哪些环节必须人工介入”。这种思考比省下来的几分钟更有价值。2. Skills拆开看五个要素和一个设计原则2.1 一个合格的 Skills拆开就是五个部分网上讲 Skills 的文章很多但大多在讲“怎么填界面”很少讲“背后在填什么”。我自己拆解下来一个合格的技能通常由五部分组成组成要素作用举例触发条件决定什么时候激活这个技能输入“/review”或“帮我审查代码”输入参数用户需要提供的信息语言Java范围git diff严格模式开行为指令明确 AI 要执行的动作和步骤按规范审查先输出问题列表再给建议约束规则告诉 AI 不能做什么、边界在哪不空泛表扬、不猜测意图、不越出指定范围输出格式规定结果长什么样Markdown 表格行号 / 级别 / 描述 / 建议这五个要素里新手最容易忽略的是“约束规则”和“输出格式”。很多人写技能时只写“请帮我审查一下这段代码”这就是把提示词换了个地方存放而已并没有形成真正的技能。我拿“代码审查”这个技能举例。触发条件定好后行为指令是“按语言最佳实践审查指定范围的代码”约束规则是“不要为了凑数挑毛病”“不要用空泛表扬”输出格式是“问题分严重、一般、提示三级按表格输出”。这样一套组合下来AI 的表现会稳定非常多——不管你是丢给它 20 行函数还是 2000 行的大改动它的输出结构都是可靠的。2.2 设计 Skills 的第一原则一次只干一件事我在初学设计技能时犯过一个典型错误想做一个“万能技能”既能写周报又能分析项目风险还能顺手翻译英文技术文档。结果调用时它经常“精神分裂”——输出里一会儿是周报格式一会儿是风险预警中间还夹杂着中英文混杂的术语解释。后来我给自己定了一条铁律一个技能 一个可预测的产出。相当于工具箱里的一把螺丝刀它就是用来拧螺丝的你别指望它兼任锤子和扳手。为什么多任务技能容易翻车因为指令里的优先级太多AI 不知道哪些约束更重要它只能靠猜。比如“写周报”和“预测风险”这两个任务在上下文不完整时它会用自己想象中的逻辑去拼凑结果就是四不像。判断一个技能是不是“多任务混杂”有个简单方法如果你需要在调用时额外解释超过两句话这个技能就还没设计好。真正的技能应该让使用者不需要动脑——触发词一输入参数一填结果就按预期出来了。2.3 怎么判断“值不值得封装”不是所有任务都值得封装成 Skills。我总结了自己的决策逻辑主要看三个维度判断维度高低使用频率每天或每周多次偶尔一次任务复杂度需要多段上下文、多种约束一句话就能说清流程稳定性需求基本不变每次要求差异很大我的经验是一个星期内用不到两次的任务先别急着封装普通提示词凑合就行。因为设计技能和调试技能的时间成本要折算进去频率不够高收益就回收不了。但有个例外——如果某个任务的使用频率不高可流程完全固定、每次做都一样它也值得封装。原因很简单技能最大的价值不仅仅是省时间更是保证一致性。人工手动写提示词今天心情好写详细一点明天偷懒写草率一点AI 的输出质量就会跟着波动。技能把流程固化下来以后每一次的结果都是同一个标准这一点在团队协作场景特别重要。3. 手把手做出第一个 Skills完整实操流程3.1 起名字、定触发词、列参数不管你在哪个 AI 平台使用技能功能新建流程都大同小异创建一个新技能给它一个名称然后设置触发条件和参数列表。我自己建第一个技能时选了“代码审查”因为这是日常最高频且流程最稳定的任务。技能名称代码审查触发方式/review一开始我列的参数非常多语言、代码语言版本、审查范围、严格模式、是否输出修改后的代码、是否解释每个问题……结果实际使用的时候每次都要花一大段话去解释参数含义反而比直接写提示词更麻烦。后来我把参数精简成三个参数一language代码语言用于识别审查语言和对应最佳实践参数二scope可选审查范围不填就默认全部参数三strict可选严格模式默认关闭这里有个重要经验能用枚举的地方绝不让 AI 自由发挥。例如参数严格模式我只允许“严格/正常/宽松”三选一而不是让使用者描述“帮我查仔细一点”。这样做的好处是技能内部行为可预期AI 不用猜测使用者的含糊表达。3.2 把行为指令写成“操作手册”设计技能最核心的部分是把行为指令写清楚。我自己的技能指令现在通常长这样你是一个认真的代码审查员。 1. 请根据参数{language}识别代码语言按该语言的最佳实践审查。 2. 只基于{scope}指定范围内的代码输出结论不要越界。 3. 输出格式必须为 Markdown 表格行号 | 问题级别 | 问题描述 | 修改建议。 4. 问题级别分为严重、一般、提示。 5. 不要为了凑数量而挑毛病如果代码没有问题直接说未发现问题。 6. 严重问题指可能造成线上事故、数据错误或安全风险的情况其他一律不算严重。 7. 不要使用空泛表扬不要猜测代码作者的意图。逐条说下为什么这样写。第一句给 AI 一个身份这是最基础的“角色设定”。第二句是边界控制很多 AI 喜欢自由发挥你让它查某个函数它能顺带把整个项目都点评一遍必须事先划清范围。第三句是输出格式这是保证结果稳定的关键AI 一旦明确了表格结构就不会天马行空。四五两句是质量约束防止它“瞎找茬”。第六句特别重要——它定义了什么是“严重”否则 AI 会把所有问题都标成严重那这个分级就失去意义了。第七句是行为规范AI 默认话多你不说它就会在末尾加一句“总体来看代码质量不错值得肯定”这句话对这种工具型任务毫无价值。你会发现整个指令的结构很像写代码定义输入、明确处理逻辑、指定输出、处理边界条件。只不过这个“代码”是用自然语言写的AI 就是那个解释执行的运行时。3.3 测试与迭代没有一次写出来的技能第一次调用这个技能时它确实输出了一个表格但把两个“提示”级别的小问题标成了“严重”比如“变量名可以更清晰”这种建议它也归为严重。我紧接着在约束规则里补充了“严重问题指可能造成线上事故、数据错误或安全风险”第二次调用就准确多了。第二次的问题是输出太长修了一堆小问题但使用者根本看不过来。我又加了一条“只输出影响最大的 10 个问题其余合并为一句提示”。第三次调用稳定了。经过几次迭代我沉淀了一个技能调试清单触发是否成功触发词是否被正确识别参数是否被吸收不传可选参数时行为是否仍符合预期输出格式是否一致多次调用结构是否完全一致约束是否被遵守有没有出现禁止的行为比如空泛表扬、越界输出是否有幻觉AI 有无生成文件中不存在的内容如果这五步都通过这个技能才算真正能用了。4. 三个我每天都在用的 Skills 实例4.1 站会同步技能一句话说清今天干了什么写站会同步是很多开发者的日常痛点。每天要向 AI 重复说明项目背景和更新模板我用技能解决这件事之后成了一句话触发。触发词/sync输入参数done今天完成的事todo明天计划risk遇到的阻碍可选输出示例【今日完成】 - 完成用户模块登录接口联调修复了超时导致的会话中断问题 - 迁移旧版的订单查询逻辑到新服务单元测试全部通过 【明日计划】 - 继续处理订单超时补偿任务排查消息堆积情况 - 评审同事提交的分页查询改动 【风险】 - 测试环境的依赖服务版本不一致可能导致联调结果偏差设计这个技能时我把所有的模板格式都写死在输出格式里还在约束规则里加了“不要补充任何其他内容不要写空话套话”。这样每次开会之前直接触发AI 按固定结构输出我复制到群里稍微改两个细节就发出去整个流程不到一分钟。4.2 接口文档生成技能从半小时到十分钟写接口文档最烦的不是打字而是回忆团队约定的格式请求路径怎么写、参数名是否要加前缀、分页参数叫什么、错误码怎么列。我原来每写一次都得翻之前的文档样例后来干脆把这个规范封装成了技能。触发词/apidoc输入一个函数签名或一段接口定义代码约束规则里写着“参数必填项用 required 标注”“返回示例必须包含正常和异常两种情况”“文档中不出现实现细节”。输出示例接口名称创建订单 请求路径POST /api/orders 请求参数 | 参数名 | 类型 | 必填 | 说明 | | --- | --- | --- | --- | | product_id | string | required | 商品 ID | | count | int | required | 购买数量不能超过库存 | | coupon_id | string | optional | 优惠券 ID | 返回示例成功 {code:0,data:{order_id:xxxx}} 返回示例失败 {code:1001,message:库存不足}这个技能的收益非常明显。以前贪图方便经常随手写文档写出来的格式五花八门团队其他人还得来回改。现在所有接口文档都走同一个技能格式统一维护成本直线下降。当然AI 生成的文档也不是完全可信的参数名和约束是否与实际代码一致还是得人工过一遍。但至少省掉了“回忆格式”和“敲表格”的时间。4.3 SQL 问题定位技能让它学会说“我不知道”这个技能是我觉得最有“以退为进”智慧的一个。AI 有个毛病你让它分析一条 SQL它哪怕没有表结构和数据量也会一本正经给出“建议加索引”之类的结论。这种结论通常没用甚至会误导人。所以我在这个技能里加了一条铁律“如果没有提供表结构和数据量不允许给出具体的索引收益判断只能提示可能存在的全表扫描风险并告知缺少哪些信息。”触发词/sqlhealth输入SQL 语句、表结构 DDL可选、是否慢查询输出示例【风险分析】 - 该查询使用 LIKE %关键词% 模式无法走普通 B 树索引在数据量大时会发生全表扫描。 - WHERE 条件中函数运算导致索引失效。 【需要补充的信息】 - 当前表数据量 - 该字段的区分度情况 - 慢查询日志中的执行时间与扫描行数 【建议】 - 若数据量超过百万行考虑改为前缀匹配或引入全文检索方案。 - 尽量避免在索引字段上做函数运算。这样的输出反而更有用因为它不会给出那种看似专业实则猜测的结论。我见过不少人在网上吐槽“AI 给的 SQL 优化建议根本不可用”根源就在技能指令里没有写好“不知道就说不知道”这条约束。5. 你可能也会踩的坑与排查思路5.1 技能不触发先查这四件事技能用多了以后最常遇到的情况是“我明明输入了触发词它怎么没反应”。我踩过几次坑后总结出四种最常见原因。第一触发词和其他技能冲突了。比如你先建了一个“查询”技能触发词是“查一下”后来又建了一个“数据库查询”技能触发词也是“查一下”平台可能随机挑一个生效或者干脆两个都不生效。解决办法很简单触发词尽量取冷门、唯一的组合比如在动词后面带上对象像“/code-review”和“/db-query”。第二参数格式没按要求写。有些平台要求参数用固定语法比如“languagePython scopeall”少写一个等号或空格技能就可能跳过参数使用默认值。第三大小写或空格问题。AI 对指令的理解是模糊的但触发机制往往是精确匹配至少我用的平台是这样。输入“/Review”和“/review”可能触发不同的行为输入“/review ”多了个空格也可能失效。第四平台自身的“技能命中日志”。第一反应不要瞎猜去平台后台看一眼这个技能是否被命中。我遇到过一种诡异情况技能被命中了也执行了但因为输出格式有问题被模型的通用回答覆盖了。这时候你会发现日志显示“技能已调用”但聊天界面看不出变化。5.2 同一次调用输出却飘忽不定技能稳定一段时间后某天突然发现输出结构变了这个问题很让人头疼。原因通常是三个。一是指令里有自相矛盾的约束。举个例子如果你的技能里同时写了“输出必须是表格”和“根据内容灵活决定输出形式”那 AI 就可能随机选择一个因为两条约束互斥了。矛盾约束会让 AI 输出飘忽不定每次它都在猜优先级。二是上下文太长导致“注意力漂移”。你前几轮对话里聊了一大堆别的内容技能触发时AI 被这些无关信息干扰对技能本身的指令响应就弱了。解决方式是让技能名称和触发词更显眼或者尽量在新会话中直接触发。三是最关键的没有写死输出模板。只要技能指令里没有“输出格式必须为……”这句话AI 就很容易自由发挥今天给你表格明天给你列表。我调试所有技能时都会问一句把上次的输出和这次对比结构是否完全一致。不一致就说明指令里的输出格式不够强硬。5.3 技能越来越多彼此开始打架这个阶段我给自己设了一个规矩每新增一个技能先列出已有的触发词表避免语义过于接近。具体踩过的一个例子是我建了一个“每日计划”技能又建了一个“任务拆分”技能两个触发词都包含“安排一下今天”。结果有时输出计划清单有时输出任务树甚至有一次两个技能同时被触发输出完全是混的。解决方式分两层。第一层是触发词精确化把“安排一下今天”改成“帮我安排今日优先级”另一个改成“帮我拆分这个任务为子任务”语义区分清楚。第二层是利用平台支持的功能部分平台允许调整技能优先级冲突时优先执行高优先级技能。但我不太推荐依赖优先级因为调试优先级比改触发词更麻烦有时还会出现“高优先级技能强制覆盖低优先级”的莫名效果。5.4 技能的维护把技能库当代码库管技能攒到十几个以后维护就成了问题很多技能建完就忘再想起来时已经不知道它够不够用。我的做法是把技能当成代码来管。给每个技能加版本号比如“代码审查 v2”用的时候如果发现某个输出不符合预期就新建一个技能而不是直接在原技能上改来改去。同时每隔一个月左右整体检查一次把两个星期内没有用到的技能归档到一份文本文件而不是直接删除——万一以后要用还能找回来。维护动作频率目的检查技能命中率每月一次找出从没被调用的技能审核输出样例每季度一次确认指令仍符合当前需求清理失效技能每月一次降低触发冲突概率更新版本说明每次修改时保留演进记录不断整理技能库的过程特别像重构老代码短期看是额外工作长期看是降低整个工作流的熵值。我现在十几个技能用下来很少再出现“找不到该用哪个技能”的情况因为每月清理时已经把不用的都归档了。6. 进阶从单个技能到一套工作流体系6.1 把上下文注入技能减少来回追问技能用熟练以后你会开始在意“交互成本”这个词。因为技能虽然封装了指令但每次调用前你还是得把“我在哪个项目”“涉及哪个模块”这些背景信息告诉它。说一次不麻烦但如果你一天调用十几次技能这十几段背景就变成了新的重复劳动。解决方式是使用平台支持的模板变量或上下文注入功能。有的平台支持在技能指令中引用全局上下文比如“项目名称”“当前分支”“当前目录”。我自己的做法是在技能的参数列表里预留这些字段然后在指令中写死项目名称{project_name} 当前模块{module_name} 请基于以上项目背景按照本技能规范执行任务。实际调用时只需填两个参数AI 不用再问“这是什么项目”。如果你用的平台不支持系统级注入也可以在技能内部配置默认值手动切换项目的时候改一次默认配置就行比每次输入省事很多。6.2 用技能串联搭一条“流水线”当你有了一套单点技能后可以做进阶玩法把多个技能串成一条流水线。我之前做过一个“需求评审辅助”场景就是串联三个技能先用“需求分析技能”把一段零散的需求描述整理成结构化的需求说明再让“接口设计技能”基于这份说明生成接口草案最后用“代码审查技能”审查当前已有代码判断改动影响范围串联时的关键技巧是让每个技能的输出带有明确的“结束标记”比如在技能指令里规定“输出结束时另起一行打印字符串 END”。这个标记的作用是让下一步技能的输入有一个清晰的锚点。AI 在处理串联任务时容易把上一步的结果和下一步的指令混在一起明确的边界标记能显著降低这种混乱。你可能会觉得三个技能串在一段对话里调用太复杂但实际操作起来只要在调用完第一个技能后把它输出的整段内容复制到第二个技能对应的输入框即可。这个“复制粘贴”动作比重新描述一遍需求省力得多而且每一步的输出都是结构化的后半段几乎不用改。6.3 个人技能如何沉淀成团队资产最后说说团队层面。我把自己常用的几个技能同步给同事后发现一个有趣的现象同样的技能不同人用得效果不一样因为每个人的调用习惯和补充说明不同。但这反而是好事——至少说明技能提供了一个不错的基线大家可以在上面做微调。为了减少大家的摸索成本我会为每个共享技能写一份简单说明内容包括这个技能解决什么问题触发词和参数怎么填输出长什么样实际使用中有哪些已知限制这份说明不一定要多长关键在于把“设计意图”沉淀下来。技能本身只是一堆指令后来的人如果只看指令往往理解不了为什么约束条件要这么写配合说明文档整个技能才算完整。还有一点要提醒在共享个人技能时注意不要把公司内部敏感的业务逻辑、未公开的架构信息写进去。我自己通常会用通用的示例数据来做演示把那些业务特有的内容从指令里剥离出来这样既不影响团队使用也守住了安全底线。最后说点个人的体会。与其指望 AI 某天突然拥有完美的长期记忆不如主动帮它建一个“外置记忆”。Skills 本质上是把我们每个人的工作习惯、表达偏好、评判标准一点一点翻译成 AI 能稳定执行的行为模板。剥开技术外壳这件事和工程领域里的“规范化”“自动化”没有本质区别——把重复的事制度化把制度化的东西沉淀下来。不要试图一口气把所有技能都配齐。我建议你从自己最高频的一个场景开始哪怕是从一个小小的日报模板起步先走通封装、调用、迭代的闭环用上一周你大概率就回不去了。技能库不是一次建成的它更像你的代码仓库是需要一直维护、随需求演化的资产。每次我重写技能里的指令时都会对“高效开发”这四个字多一层理解真正的效率不是做某件事时手快而是做某件事时不需要重新思考。