1. 设备巡检的做法，散在三个地方
一家装备制造企业的设备科管着三条产线、两百多台设备。巡检这件事有固定做法：先读设备的温度、振动、电流，对照这台设备自己的巡检标准判断是不是异常，异常了按分级上报，最后填巡检记录。这套做法在设备科跑了七八年，班长带着六个巡检员，谁都知道下一步该干什么。
企业把这套问答接到了单位已有的智能体平台上，巡检员用手机就能问。上线头两周还算顺，因为工程同学把设备科的巡检规则抄了一段进系统提示词。第三周开始，毛病一个接一个冒出来。
第一个是系统提示词越写越长。为了让助手什么都能答，三条产线所有设备的判断标准都塞了进去，写到两千四百多字。这个量每一轮对话都要重新带上，费用和等待时间跟着涨，里面九成内容又跟巡检员当下问的这台设备没关系。
第二个是口径改了它不知道。设备科把异常上报的时限从 30 分钟改成 15 分钟，新标准贴在办公室墙上，系统提示词里没跟着改，助手照旧答 30 分钟。巡检员按它说的做，差一点漏报。
第三个是两组做法混在一起。电气组和机械组对同类设备各有一套判断方法，两套都写在提示词里，助手经常拿电气组的判断方法去答机械的活。
三处毛病往回追，落在同一件事上：这套做法一直没有被单独收起来。它散在系统提示词里，散在办公室墙上，散在两个组的经验里；谁都能改，改完没人知道。
2. 技能包把一套做法单独收起来
2.1 一个技能包里装三样东西
技能（Skill）指把一套已经跑通的做法做成一个独立的包，装在平台上，让智能体在合适的时机自己取用。主流平台的技能包结构大同小异，一个文件夹里放三样东西。
| 位置 | 装什么 | 什么时候起作用 |
|---|---|---|
| 说明文件 | 技能的简介和正文，写清什么时候用、按什么步骤做 | 平台启动时只读简介，判断要用这个技能了才读正文 |
| 附带脚本 | 每次结果都必须一样的操作，比如按固定格式算数、校验字段、生成归档文件 | 用到就运行，运行过程不读进窗口 |
| 参考资料 | 只在特定情况下才用得上的细则、模板、参数表 | 走进那个分支时才读 |
说明文件是包里唯一必需的东西，平台上通常叫 SKILL.md。它的开头一段是简介，写这个技能干什么、什么时候该用它。简介是智能体挑技能的唯一依据，写得准不准，直接决定这个技能会不会在该用的时候被想起来。
2.2 技能和系统提示词，装的不是同一批话
系统提示词（System Prompt）管的是这一次对话里它要守的规矩，技能管的是那套反复要用的做法。两样都是写给模型看的话，差别在三个地方。
范围上，系统提示词里的内容每一轮都在窗口里待着；技能平时不在，被触发才进来。
写法上，系统提示词面对的是眼下这一件事，可以说得比较具体；技能面对的是以后各种人拿各种设备来问，触发条件、边界、例外都得交代清楚。
归属上，系统提示词常常是工程同学临时加上去的，改一改也没人记；技能是一个有名字、有版本、有维护人的文件。
判断一段内容该留在系统提示词还是该搬进技能，看一条：它是不是只有特定情境下才用得上。 只有巡检问到的才用得上，就搬进技能；不管谁问、问什么都得守的规矩，比如「不确定就说不确定」，留在系统提示词里。
设备巡检那个例子里，两千四百多字的判断标准搬进技能之后，系统提示词里只剩一句一百八十字左右的话：遇到设备巡检相关的问题，先加载对应的巡检技能，按技能里的步骤回答，拿不准就问巡检班长。提示词短了，助手每一轮的负担也轻了。
2.3 技能和工具，一个管做法一个管动手
工具（Tool）是让智能体能够去动别的东西的接口，比如查一条设备档案、调一次工单接口、拉一段历史振动曲线。技能是让它知道这件事该怎么办的做法。
还是巡检这台空压机。技能里会写：先把振动、温度、电流三个参数调出来，对照这台设备的标准区间，看是哪一项超了、超了多少，再决定走常规记录还是走异常上报。这些是做法。技能自己不具备读参数的能力，读参数这个动作由工具体现。
这两样分开写，换一家单位的设备标准，技能改一改就行；换一个数据源，工具改一改就行，两边互不牵连。
2.4 技能和 MCP 各什么时候用
MCP（Model Context Protocol，模型上下文协议）是让智能体接外部系统的一套通用接口标准，接口按它写一次，各种支持这套标准的智能体都能接。
这两样装的东西不一样：技能装的是做法，MCP 接的是接口。查一件事卡在哪一头，就知道该动哪个。数据在别的系统里取不回来，卡在「够不着」，走 MCP 那条路；数据能取回来，但它不按你的规矩办事，卡在「不知道怎么干」，写技能。
这两样可以叠在同一条链路上用。设备巡检助手里，MCP 负责把设备管理系统里的运行数据取回来，技能负责判断这批数据是不是异常、按什么口径上报。企业里常见的分层配法就是这个样子。
3. 用到时才展开：渐进式披露
3.1 三层按需加载
技能装得再多，平台也不会把它们的内容一股脑塞进窗口，它按三层往里放。
第一层是简介。平台启动时把装过的每个技能扫一遍，只读每个说明文件开头那段简介，放进窗口。按社区实测，一个技能的简介大约占 100 个词元。装 50 个技能，这一层合计 5000 词元左右。
第二层是正文。哪次对话里判断要用这个技能了，才把说明文件的正文读进来。正文写多长占多少词元，一般在 1000 到 5000 词元之间。
第三层是脚本和参考资料。正文里会指明什么时候去用哪一份。脚本是执行，不读进窗口；参考资料用到那份才读那份。
这套机制叫渐进式披露（Progressive Disclosure）。它省上下文的地方在于读进来的时机，跟技能本身写了多少没关系。 一个写了两万字的技能，平时在窗口里只占一百个词元。
装几十个技能，窗口里占多少
- 装过的技能50 个
- 每个技能的简介约 100 个词元
- 这一层合计约 5000 词元
- 此刻的窗口系统提示词、简介这一层、用户这一句提问
装了多少个技能，就只有简介这一层占位置。
- 触发的那一个技能设备异常判读
- 读进来的正文1000 到 5000 词元，按正文长短算
- 没被触发的另外 49 个还只占简介那一份
谁被触发谁才进场，其余的留在库里。
- 正文里指明的参考资料这台设备的参数标准区间
- 读进来的部分只有这一个型号这一张表
- 脚本归档用的固定脚本，执行但不进窗口
参考资料用到那份读那份，脚本只执行不占窗口。
- 移除最后一个技能的简介这一层从 5000 降到 4900 词元左右
- 已经明确不用那个技能它后面两层也不会再进来
省下来的位置在时机上，跟技能本身写多长没关系。
技能写多长不在窗口里付钱，什么时候读进来才付。
3.2 省下来的量有多大
社区里有一个能对上号的对照。一个数据库类的 MCP 服务器，把所有工具的完整定义一次性加载进来，初始占用约 16000 个词元。改成用一个技能的简介做入口，初始占用降到 500 个词元左右；真的要用的时候才按需加载技能正文，再由正文去调用底层的那些工具。
16000 降到 500，省下的这部分是每一轮对话都要重新付的。一次咨询聊到第五轮，这个差距要乘五。
简介这一层自己也会积。装 50 个技能，5000 个词元常驻在窗口里，跟当前要办的事一点关系没有。技能是按需取用的，装得越全并不代表越好；装了半年没触发过的，该清掉。
3.3 技能包的三层里各放什么
三层各放什么，决定了这套机制能不能省下来。
| 层 | 放什么 | 不放什么 |
|---|---|---|
| 简介 | 这个技能干什么、什么时候该用它 | 操作步骤、参数表、示例 |
| 正文 | 通用流程、判断顺序、容易踩的坑、什么时候去用附带资源 | 只在个别设备或个别部门才成立的标准 |
| 脚本与资料 | 结果必须一致的操作、只在某个分支用得上的细则 | 主流程的说明 |
三种放错最常见。触发条件写进正文，正文是触发之后才读的，等到模型看见它，技能该不该选早就定了。参考资料里的细则原样搬进正文，正文越写越胖，每次触发都要整段带进来。结果必须每次一样的操作，比如把巡检记录生成成一份固定格式的归档文件，写成一段文字说明让模型照着做，它每次给出的格式都会有细微差别。
4. 同一套做法怎么给一个团队用
4.1 从一个人的做法变成团队资产
技能写出来放在自己账号里，只有自己用得上。要让它变成团队的东西，得把三件事定下来：放在哪、发给谁、跟着谁更新。
放在哪，企业里通常有两种做法。一种放进平台的技能库，全平台共享，谁有权限谁就能挂到自己搭的助手上，改一次全体生效。另一种随应用打包，某个业务应用绑定了哪几个技能，跟着这个应用一起上线下线，改动只影响这一个应用。选哪种看这套做法的适用范围：设备巡检标准全公司都要守，放技能库；某个车间自己的一套老设备点检法，跟着这个车间的应用走就行。
发给谁靠权限。技能库里可以按部门、按角色下发，设备科的人能挂巡检技能，财务的人看不到。这一点要提前跟平台方确认：技能库里放的东西，默认所有人可见，还是按权限可见。
跟着谁更新，是三件事里最容易漏的。技能一旦被十几个助手引用，改之前得先知道有多少人在用。平台一般会记引用关系，动手前先看这份清单。
4.2 技能市场和插件市场是什么
公开的技能市场是近两年起来的东西。Anthropic 建了官方的技能仓库，社区往里贡献了成百上千个技能，覆盖前端设计、代码审查、文档处理、数据分析这些方向。用的时候把对应的文件夹拷进自己的技能目录，平台下次启动就能扫到它。
插件市场是另一种形态。它把技能、工具接口、配置打包成一个整体，装一个插件，等于同时把做法和接口一起接上。对产品经理来说，两者的区别在颗粒度：市场上单独一个技能管的是一件事，插件管的是一套完整能力。
4.3 拿来一个现成技能，先过三遍
现成技能省事，但不能拿来就用，技能包里可能带着脚本，脚本是会被执行的东西。
第一遍看它带了什么文件。只有一个说明文件，风险小；带了脚本，就得知道脚本会读写什么、会不会往外发数据。
第二遍看它的触发条件写得宽不宽。简介里写着「处理数据分析」这种大范围描述的，装上去之后很可能把不该它管的活也接走。
第三遍看它跟单位里的规矩冲不冲突。外部的巡检技能用的可能是通用标准，单位里有自己的上报时限和分级，直接装上就会出现两套口径。
5. 写一个技能包的五条规矩
5.1 触发条件写在最外层
触发条件写在说明文件开头那段简介里。它是智能体挑技能的唯一依据，写偏了，技能写得再好也不会在该用的时候被想起来。
判断写得准不准，有个简单办法：把打算写的简介跟同事念一遍，再念几句用户真会说的话，看这句简介能不能把该接的接住、把不该接的挡在外面。
一份简介要回答三个问题：这个技能干什么、什么情况下用、什么情况下不用。第三个问题最容易被省掉，也最要紧。巡检技能如果只写「处理设备巡检相关的事」，「帮我写一份本月设备台账」这种活也会被它接走。
三条简介，拿六句真话术试跑
先自己判一遍，再点开下面的判定
三条简介草稿，六句用户话术
- 简介 A巡检相关处理
- 简介 B按设备科的巡检标准判断设备异常，并按规定分级上报、归档巡检记录
- 简介 C处理异常上报，按设备科的 15 分钟时限上报
- 六句话术「3 号线的空压机声音不太对，帮我看看要不要报修」｜「这条异常最晚什么时候上报」｜「帮我写一份本月设备台账」｜「12 号机振动值 8.6 毫米每秒，算异常吗」｜「帮我订一间会议室」｜「巡检记录按什么格式存」
先自己判哪几句会被哪条简介接走，再看判定。
看判定
- 空压机那一句命中 A 和 B，不命中 C；这句里没有上报动作
- 上报时限那一句三条全命中；C 的理由是这句直接落在上报时限上
- 设备台账那一句只命中 A；跟巡检无关的活也被 A 接走
- 振动值那一句命中 A 和 B，不命中 C
- 订会议室那一句三条全不命中
- 巡检记录格式那一句命中 A 和 B，不命中 C
- 把 A 改成「按设备科标准判断设备异常，并处理异常上报与巡检记录归档」重跑 · 写台账那一句三条全不命中
一份简介要回答三件事，干什么、什么时候用、什么时候不用。
一份简介要回答三个问题，这个技能干什么、什么情况下用、什么情况下不用。
5.2 一个技能只管一件事
一个技能里塞两件事，后果是简介变宽、正文变长、两边都用不上。
设备巡检这件事，至少要拆成三个技能：参数判读管「这台设备现在算不算异常」，异常上报管「异常了走哪一级、多久之内报给谁」，记录归档管「巡检记录按什么格式存下来」。三个技能的简介各自只说自己那一件事，谁触发谁进来，不用的时候待在库里。
拆到什么程度算合适，看两条：这些内容是不是同一批人在同一个时机用的；拆开之后，每份简介是不是还能各用一句短话说清自己管什么。两条都是，就拆。
不同行业的拆法不一样。金融行业的制度问答，一个技能可以覆盖上百条制度，因为问制度的人、问的时机都一样；医疗行业的诊疗路径得按科室拆，同一套流程在门诊和住院部用法差得远。
5.3 能写死的别让模型猜
技能里的活分两种。一种每次的结果必须一样，比如按固定字段生成归档文件、按固定公式算设备剩余寿命、把日期转成统一格式。这种交给脚本，输入进去、结果出来，不带一点发挥。另一种需要按现场情况判断，比如「这个振动值算不算异常」，这种用文字写清判断依据，让模型自己权衡。
判断标准看两个问题：做错了后果有多严重；有多少种做法算对。后果严重、正确答案只有一种的，写死；后果可控、好几种做法都行的，放开让它自己判断。
5.4 用祈使句写，把不做什么写明
技能正文的读者是模型，不是同事。给同事看能写「保持专业、建设性的语气」，模型会把「专业」和「建设性」展开成无穷多种组合，每次出来的东西都不一样。这段话里没有一个能落地的动作。
文字要写成动作。「先读振动、温度、电流三个参数」「对照这台设备的参数标准区间」「有一项超上限就按异常处理」，这样的句子模型能照着做。
还有一条更有效的写法：写清不做什么。「不要替巡检员判断能不能停机」「不要给出超出 15 分钟时限的上报建议」「不要引用没有出现在设备档案里的参数标准」。否定句给的是边界，模型在被划出来的范围内活动，发挥空间小，结果也就稳。
写完可以把正文过一遍，看每一句正面要求能不能翻成一句否定要求。能翻的，通常翻过来更准。
5.5 从做法到技能包的六步
把设备科那套巡检经验变成一个技能包，走这六步。
第一步，先用具体例子把共识对上。问设备科的人：巡检员平时到底会问什么，给三句原话。这一步别急着写，先把例子攒够。
第二步，看这些例子里哪些东西是反复要用的。判断标准反复要用，封成一份参考资料；归档格式每次都得一样，封成一个脚本；剩下的流程写成正文。
第三步，按平台给的格式把目录和说明文件建起来，简介先按 5.1 的办法写一版。
第四步，先把脚本和参考资料写好并跑通，再回头写正文。正文是拿来串这些资源的，资源没定型，正文等于空写。
第五步，拿真实的问题试十句，看该触发的时候触发没有、不该触发的时候挡住没有。这一步过了再交给设备科的人用。
第六步，上线之后按反馈改。第一版一定不完整，改的节奏在下一节。
6. 技能也需要有人管
6.1 业务变了技能怎么跟着改
技能写得再好，业务一改它就旧了。设备科上报时限从 30 分钟改成 15 分钟那天，技能包里的参考资料就该跟着改。晚一天，用它的所有助手都在给错答案。
改动来源一般有四个：制度变了、设备换了、系统接口变了、用的人反馈答得不对。前三个有明确的触发事件，制度发文、设备台账更新、接口调整公告出来的时候，就要过一遍名下所有技能。第四个靠人收集，巡检员在对话里纠正过助手的地方，得有地方记下来。
改动要往小里做。改一句时限，就改那一句，别顺手把整个技能重写一遍。重写过的技能，之前试跑过的那些问题得重新试一遍。
6.2 谁负责，版本记在哪
技能一定要有维护人。没有维护人的技能，改起来没人敢动，旧了也没人管，半年之后就变成库里的噪音。
维护人不一定是产品经理。设备巡检技能的维护人，落设备科最合适，他们最清楚标准怎么变。产品经理管的是技能库整体的规矩，比如谁有发布权限、多久检查一次没人维护的技能。
版本要记三样：改了什么、谁改的、什么时候改的。改动影响面大的技能，比如被十几个助手引用的那种，改之前先看引用清单，改完通知一遍。
停用也要有出口。设备科换了新设备，老设备的点检技能留半年都用不上，就该停掉。技能库里的东西只增不减，用不了多久简介层就会积到几千词元，前面省下来的上下文又被吃回去。
6.3 一套做法值不值得做成技能
用得多不多。半年里只用过两次的做法，留在某个人脑子里就够了，做成技能包反而要多花时间维护。
稳不稳。这套做法还在天天变，今天这么干明天那么干，做出来就得跟着改，先等等。
说不说得清。做法靠老师傅的直觉，写不出具体步骤，先把它写成一段文字给模型看，等能说清了再说做成技能。
三条都过得去，就值得做。
7. 三个技能包各管哪一段
设备科那套巡检做法最后拆成三个技能。
「巡检参数判读」管第一件事。正文里写通用判断顺序：先读振动、温度、电流，再按设备型号去查参考资料里的参数标准区间，有一项超上限就走异常，都在区间内就走常规记录。三类共两百多台设备的参数标准，各自一份参考资料，走到哪台设备才读哪一份。
「巡检异常上报」管第二件事。上报级别、时限、报给谁写在正文里，15 分钟这条放在正文最前面，因为它最容易被忘掉。
「巡检记录归档」管第三件事，整个交给了脚本。巡检记录按固定字段生成归档文件，每次结果一模一样。
一开始也考虑过把三件事合成一个技能包，试跑下来简介写不窄，「帮我看看这台设备怎么样」这类话术会把三个分支全激活，正文一次带进来三千多词元，放弃了。
系统提示词从两千四百多字改成一百八十字。助手每一轮平时只占三百词元的技能简介，巡检员问到异常判读的时候，才把那一份正文和那一台设备的标准读进来。
改动流程也定下来了。设备科出一个技能维护人，制度改了由他在两个工作日内更新对应技能；产品经理每季度过一遍技能库，把半年没触发过的技能交给平台方停用。那次把 30 分钟改成 15 分钟的漏改，因为有了明确的维护人和检查节奏，不再靠谁的记性。
8. 巡检做法封成技能包的前置问题
- 这个技能在什么时候被触发，能不能一句就讲清？
- 这套做法里每次结果必须一样的那几步，是不是都拆成脚本了？
- 需要按现场情况自己判断的地方，是不是都标出来了？
- 技能里有没有只对某几台设备、某个班组才成立的内容，是不是单独放了一层？
- 正文里出现的每个参数和时限，是不是都能追到出处和维护人？
- 这套做法改了以后，有没有指定谁来改、谁来验收？
- 现在是不是已经有第二个岗位在用它？
七个问题都能答「是」，这个技能包可以开始写了。
9. 写坏一个技能包的样子
把系统提示词里的规则另存一份当技能。 系统提示词里那段规则，没有触发条件，没有分层，改起来还是没人管。技能包要单独想清楚三件事：什么情况下用、正文和资料怎么分、脚本接了哪些活。
只写做什么，不写不做什么。 「保持专业语气」「全面审查」这类话写给人看没问题，写给模型看等于没写。把要求写成动作，再补一份不做什么的清单，结果才稳得住。
把一家单位的做法原样写死。 上报时限是 15 分钟还是 30 分钟，是设备科定的，写进另一个部门的技能里就错了。技能里写死的是判断逻辑和格式要求；具体的时限、阈值、分级标准放参考资料，谁用谁挂自己那一份。
10. 技能写完了，动作还得靠外面的接口
技能解决的是「这件事该怎么办」。它会写，会判断，但读参数、开工单、发通知这些动作，技能自己不做，得靠外面的接口。这份材料里提到的工具和 MCP，就是让智能体把手伸出去的那一半。
手上如果已经有一套跑通的做法，可以按第 8 节那七个问题先过一遍，看它够不够格做成技能包。下一份材料讲工具怎么接、权限怎么划、接口挂了怎么办，以及 MCP 为什么能让接口写一次就到处能用。