关于OpenClaw的skill怎么写前两讲聊了环境搭建和基础调用。今天这篇我打算把写skill的整个思考过程拆开给你看。核心就一句话skill不是写出来的是想出来的。场景想明白了5分钟写一个文本处理类skill完全做得到。网上那些讲skill的文章很多都在教模板长什么样却很少讲为什么是这个结构、换个场景怎么办。这第三讲我把通用思路和7个可复制的步骤一次讲清适合刚接触skill的新手也适合已经写过一两个、想系统梳理方法的老手。先说明一下“思路通用”四个字的分量。OpenClaw里的skill本质上是给AI代理agent准备的一份“岗位说明书”告诉它在什么情况下出手、拿到什么信息、按什么流程处理、最终交什么结果。理解到这个层面你就会发现写skill这件事跟具体平台关系不大跟具体业务场景关系很大。所以这一讲讲的方法换到AI备课、小说辅助、GIS空间分析、论文拆解这些不同方向上一样能用差别只在细节。1. skill的思路别急着写格式先想清楚三件事1.1 skill到底是什么我更喜欢用一个比喻OpenClaw本身像一个什么都会一点的通用助理而skill就是给这个助理写的一页“操作备忘卡”。助理本来就会用浏览器、能跑命令行、能看文件内容但你要是不告诉它“碰到什么事情、按什么顺序做、结果给谁”它就只能泛泛地回答做不到稳定产出。一份合格的skill至少要包含三块信息触发条件、处理流程、输出格式。触发条件决定AI代理什么时候想起这张卡片处理流程决定中间怎么做是直接回答还是跑脚本、查文件、调接口输出格式决定最终交付的样子是Markdown清单、CSV表格、一段代码还是一个文件。我见过不少朋友写skill上来就写“帮我分析数据”这种模糊描述。这就是没想清楚第一件事的结果。你把“分析数据”四个字丢给AI代理它也确实会分析但八成不是你心里想要的那个分析。你写skill本质上就是把“你心里想要的那个分析”变成AI代理能读懂的执行指令。1.2 “思路通用”到底在讲什么第三讲为什么专门聊“思路通用”因为我见过太多人学skill卡在一个怪圈里照着别人的示例把skill文件格式抄了个八九不离十换一个场景就不会写了。原因很简单你只学会了“skill长什么样”没学会“skill怎么设计”。通用思路的核心是抛开平台和具体业务抽出写skill的固定套路。这个套路一旦形成你看到任何新需求脑子里会自动浮现一个骨架输入是什么输出是什么中间执行逻辑分几步哪些地方需要给示例。这就是从“写一个skill”进化到“随时能写任意skill”的分水岭。所以这篇讲的不只是7个步骤更重要的是讲清楚每一步背后“为什么这么做”。你理解了原因遇到没见过的场景也能自己推导出做法而不是翻着模板硬凑。1.3 什么skill适合5分钟写完必须说实话不是所有skill都能5分钟写完。能做复杂数据管道、要调外部API、要联动多个工具的skill别说5分钟一晚上都可能搞不定。我说“5分钟写出一个skill”指的是最常见的文本处理型skill把用户丢过来的一段内容按你定义的规则整理、归类、输出来。这类skill占日常需求的一大半也是入门最好的练手对象。它不需要写代码核心逻辑用自然语言就能描述清楚AI代理能直接理解。等你用7个步骤把这类skill跑顺了再逐步接触带Python脚本、带外部工具调用的复杂skill思路是同一套只是执行层增加了工程量。2. 5分钟写出一个skill的7个标准步骤2.1 7个步骤总览先把全景摆出来后面一步步拆步骤动作耗时一句话说明第1步定场景30秒明确AI代理在哪个时机替用户做什么第2步抓输入30秒列出用户可能给的信息和说法第3步定输出30秒明确最终交付形式第4步写执行逻辑2分钟用自然语言按顺序描述处理步骤第5步加示例40秒给一组输入输出对让AI代理对照理解第6步注册加载30秒把skill文件放进skills目录并生效第7步测试验收40秒用一句真实触发词跑一遍看结果这7步加起来正好在5分钟上下。注意这说的是“写出初版”的时间不是“最终完美版”的时间。初版跑通再根据测试结果迭代那属于后续优化不在5分钟之内。2.2 前3步定场景、抓输入、定输出第1步定场景是全部工作中最值钱的一步。你要回答的问题不是“我想让AI代理做什么”而是“用户包括你自己在什么情境下会需要这个skill”。我习惯写成一个触发句式“当用户说XX时AI代理应该做YY”。比如“当用户说‘整理周报’时AI代理应该把最近的工作记录分类归档成周报”。这个句式写出来skill的价值就已经确定了一半。第2步抓输入很多人会漏掉。因为站在你自己角度你很清楚“用户会给我什么”但AI代理不知道。你必须在skill里显式告诉它输入可能是一大段聊天记录可能是一条条零散笔记可能是一句话“帮我弄一下”也可能是带附件的文件。把可能性列全AI代理才不会在遇到非典型输入时不知所措。第3步定输出决定交付标准。输出不写清楚AI代理就会自由发挥。我建议在这个环节就明确三点格式Markdown还是纯文本、结构分几块每块叫什么、长度颗粒度要点式的几句还是完整段落。输出定义越具体越不需要你在测试阶段反复纠正。2.3 后4步写逻辑、加示例、注册、测试第4步写执行逻辑是7个步骤里唯一可能超过2分钟的一步但也不会太久。做法是把处理过程拆成3到6个顺序步骤每个步骤用一句话描述让AI代理能顺着执行。注意这里的关键是“按顺序”不是一次性给一大段说教。分步写的好处是某个步骤出问题时你能快速定位是哪一步的逻辑有问题。第5步加示例是让skill效果稳定的临门一脚。AI代理理解自然语言指令的能力再强也难免遇到抽象指令的多重解读。给出一组完整的“用户说—代理输出”对照等于给了它一个锚点。示例有一组就行不用多关键是让它覆盖典型场景。第6步注册加载不同版本的OpenClaw细节可能不一样但大原则是把skill文件放到OpenClaw指定的skills目录让会话重新扫描或重启后生效。我自己遇到最多的问题反而是这个环节后面第5章会专门讲。第7步测试验收别用理想情况测要用真实口吻测。直接打开OpenClaw的对话框用最随意、最口语化的话触发这个skill看它能不能认出来、能不能按你的逻辑跑完。在测试这一步发现的问题比事后翻文档解决任何问题都值。3. 实操演示5分钟写一个“周报自动整理”skill3.1 需求与预期效果理论讲完了走一遍实操。我选一个最日常的场景整理周报。背景是你平时在聊天工具、记事本里随手记了一堆工作碎片到了周五要写周报时面对几十条零散记录头大。这个skill的作用就是让OpenClaw把这些碎片分类整理成周报底稿。预期效果用户丢进来一大段流水账包含做了什么、遇到什么问题、下周打算skill把它整理成“本周重点工作、日常事务、问题与风险、下周计划”四块。格式要清爽能直接复制进周报模板。这个场景选它有代表性第一输入天然是零散文本第二它需要按规则归类而不是简单摘要第三输出格式明确。这三条凑齐就是典型的“5分钟skill”。3.2 编写SKILL.md文件在OpenClaw的skills目录下新建一个文件夹命名为weekly_report_builder里面建SKILL.md文件内容如下--- name: weekly_report_builder description: 当用户需要将零散工作记录整理成周报时使用。触发词包括整理周报、生成周报、汇总本周、把流水整理成周报。 version: 1.0.0 --- # 周报自动整理 ## 用途 把用户提供的零散工作记录按“本周重点工作 / 日常事务 / 问题与风险 / 下周计划”四类整理成周报底稿。 ## 输入 用户可能直接粘贴聊天记录、备注、事项清单也可能只说“把这周的流水整理成周报”需要AI代理从上下文获取原始记录。 ## 输出 - 按四类区块组织的Markdown列表 - 每件事包含做了什么、结果或进展如有、遗留问题如有 - 同类别下按时间顺序或重要程度排序 ## 步骤 1. 通读用户提供的原始记录把长段落拆成独立事项。 2. 逐条判断事项归属类别含“完成、上线、交付”等归入重点工作重复性事务归入日常事务含“卡住、风险、待解决”等归入问题与风险含“计划、安排、打算”等归入下周计划。 3. 同一类别下压缩重复表达把口语说法改成书面表述。 4. 按模板组装输出检查是否有遗漏事项。 ## 示例 **用户**周一联调登录接口终于通了。周二写测试用例下午还帮新人看了一个数据库慢查询问题。周三评审需求周四准备上线文档。周五发现灰度环境有个配置不对下周要安排人修一下。 **代理输出** #### 本周重点工作 - 完成登录接口联调。 - 完成测试用例编写。 - 完成需求评审及上线文档准备。 #### 日常事务 - 协助新人排查数据库慢查询问题。 #### 问题与风险 - 灰度环境存在配置错误需要安排修复。 #### 下周计划 - 修复灰度环境配置问题。文件写好之后保存编码务必选UTF-8无BOM后面第5章会讲为什么强调这一点。3.3 注册加载并验证把SKILL.md放入skills目录后我一般会重启OpenClaw会话让它重新扫描技能。有些版本支持热加载命令但重启会话永远是最不挑版本的验证方式。加载成功后直接在对话框里输入一句触发试试“我这几天的记录比较乱你帮我整理成周报周一处理了三个工单周二改了首页样式还有周三开会客户反馈登录太慢下周要优化一下。”正常情况OpenClaw应该识别出这是weekly_report_builder的活并按四个分类输出。如果它没触发问题大概率出在description里的触发词没覆盖到你的测试说法回去把触发词补上就行。3.4 我的时间分配参考按上面的流程我实测一次的时间大约是4分40秒左右。去掉“想”的时间纯打字填内容不到3分钟。其中第1到第3步花了大约1分钟因为我在写SKILL.md之前就把输入输出的边界想清楚了第4步写执行逻辑花了2分钟因为步骤拆得细第5步示例花了40秒第6步第7步加起来不到2分钟。整个过程里最耗时的不是打字是“想”。想不清楚分类规则AI代理就会在归类时摇摆。这一步想透后面全是体力活。4. 从一次实践到一套方法思路怎么“通用”4.1 把示例抽成通用模板再回头看那个周报skill剥掉“周报”这个业务外壳剩下的骨架是什么其实是四件事拆解原始材料、按规则分类、压缩整理、格式化输出。这套骨架放到别的场景一样成立比如AI备课skill输入一段教材原文输出教案结构本质就是拆解知识点、按教学环节分类、补充教学建议、格式化输出。小说辅助skill输入一个剧情想法输出分章大纲本质就是拆解情节要素、按起承转合分类、丰富细节、格式化输出。GIS空间分析skill输入一段地理分析需求输出分析步骤建议本质就是拆解需求、按分析流程分类、匹配工具方法、格式化输出。论文拆解skill输入一篇PDF摘要或全文输出研究问题、方法、结论三块本质还是拆解、分类、提炼、格式化。这个发现很重要多数日常skill并不需要让AI代理干什么惊天动地的特殊事它只需要做好“理解、拆解、归类、重组”这四步。你的业务场景提供的是分类维度处理逻辑是通用的。4.2 不同场景怎么套用差异点在哪场景变了真正要调整的只有三个地方触发描述、分类维度、格式化模板。触发描述要贴合场景术语。比如“备课”场景里触发词得包含“备课”、“写教案”、“设计课堂环节”而不是“整理”这种泛词。分类维度是从业务需求里长出来的。周报要“按工作性质分类”备课时要“按课堂环节分类”小说大纲要“按故事节拍分类”。这一步没法抄模板必须回到业务本身去思考什么类别对用户最有价值。格式化模板要跟着输出用途走。周报输出要能复制进公司模板备课输出要能直接给老师上课用小说输出要能让你顺着大纲往下写。格式的颗粒度和风格由最终消费这个输出的人决定。每次写新skill前我都建议先做一次“换壳练习”把旧skill的执行逻辑列出来看看新需求能不能套用同样的骨架。能套直接替换触发描述、分类维度、格式模板不能套说明新需求可能要做脚本级联动不是一个简单文本skill能覆盖的。4.3 思路通用的边界哪些skill不建议自己硬写把通用性说得很神但我也得把边界讲清楚免得你踩坑。有几类skill不适合用这套“5分钟思路”硬写第一类是强依赖外部工具的skill。比如要控制SolidWorks、要操作ROS2、要调浏览器自动化。这类skill需要先把工具接入OpenClaw还要写脚本属于系统工程5分钟搞不定。第二类是涉及多轮交互的skill。如果skill需要AI代理中途反问用户确认信息流程设计就会复杂很多。文本型skill大多是一次性输入输出多轮交互要额外设计状态管理不能用简单的“步骤列表”糊弄。第三类是要求高确定性、零出错的skill。比如金融对账、医疗问诊辅助。自然语言驱动的skill天然带一定随机性这类场景需要的是严格校验甚至要专门写验证脚本而不是靠步骤描述来保证质量。遇到这三类我的建议是先别急着写skill而是把问题拆开看看哪些环节能由skill负责、哪些环节还得靠外部脚本和人工兜底。通用思路的价值在于帮你快速发现边界而不是让你什么都往里硬套。5. 高频问题与排查实录5.1 编码类问题skill编码193和247Windows环境下写skill最容易踩的坑就是编码。我在第3章特意提了“保存为UTF-8无BOM”就是因为吃过亏。如果你用记事本或某些默认编码的编辑器保存SKILL.md文件可能是GBK编码结果是OpenClaw加载skill时报错或者skill内容里凡是中文的地方都乱成一团。热搜词里那两个“skill编码193”、“skill编码247”我判断就是这类编码相关的报错。193和247如果出现在控制台里一般对应着脚本解释器或文件读取阶段遇到非预期的字节流。排查思路很简单用VS Code或Notepad打开SKILL.md看右下角编码格式是不是UTF-8如果不是另存为UTF-8无BOM。改完编码再重启会话九成问题就消失了。为什么强调“无BOM”因为带BOM的UTF-8文件在某些解析场景下文件开头会多一个隐藏字符个别版本解析YAML头部时会把隐藏字符带进name字段导致skill识别异常但错误信息又不直观。所以保存时直接选中“UTF-8 without BOM”比UTF-8更稳。5.2 加载与部署问题WSL状态异常、卸载重装Windows上跑OpenClaw很多功能依赖WSL2环境。有朋友反馈“OpenClaw无法安全验证WSL2环境”之类的提示还说系统让在PowerShell里运行wsl --status。这个我不展开讲Windows本身的问题只说排查套路先运行wsl --status确认WSL是否正常再看默认发行版是否设置好。WSL状态不对OpenClaw后续所有依赖Linux子系统的操作都会别扭。另一个常被问的是“怎么卸载OpenClaw”。我的建议是三层清理第一删除OpenClaw程序安装目录第二删除用户目录下的数据目录也就是.openclaw这一类的隐藏文件夹skill和配置全在里面第三检查环境变量里有没有OpenClaw相关的PATH配置顺手清掉。这三层干净了再重装基本不会遇到旧配置干扰。5.3 效果不符合预期时的调试思路skill能加载但输出效果不对这是新手最容易反复陷入的泥潭。我建议按这个顺序排查第一先确认触发是否成功。对话框回复内容里如果完全看不出skill流程的痕迹那就是没触发回去补description里的触发词。第二再看分类是否合理。如果触发成功但归类混乱说明第4步执行逻辑里分类规则写得不够显式。比如“遇到问题要归到问题与风险”这句话里的“遇到”就太模糊改成“包含‘卡住、风险、待解决、Bug、异常’等词的记录”就明确得多。第三最后看输出格式。如果分类对了但排版不对那把第3步输出定义写得再细一点甚至把目标格式整段贴进示例里。我见过很多效果不佳的skill最终都定位到同一个根源执行步骤里用了模糊的动词。AI代理对“合理整理”、“适当归纳”这类词没有共识标准你要么给明确规则要么给示例让它模仿。这个坑踩一次记住了后面写skill会顺手很多。6. 我的实操体会以及下一步还能怎么玩写到现在说点更私人的体会。我在实际使用中发现把7个步骤固化成一个自检清单特别管用。写新skill的时候我甚至不会刻意想“我在按第几步操作”而是写完直接对照清单检查输入写清了吗输出定死了吗逻辑是分步的吗有示例吗这套条件反射一旦建立写skill的效率提升不是一点半点更重要的是写出来每个skill的稳定度高很多。还有个心得想分享skill初版一定要小宁可只覆盖一个场景也不要贪大。很多人一上来就想写一个全能的“我的全能助理”skill结果处理逻辑塞了几十条AI代理在执行时反而不知道优先听谁的。我后来的做法是把全能拆成十几个小skill每个只管一类事。触发精确逻辑简单效果反而好。最后分享一个顺手小技巧写skill的时候把你在编辑过程中的“思路过程”也留一句在文件末尾的注释里。比如“为什么这么分类因为周报读者是Leader只关心重点和风险”。这句话AI代理能用你下次回头维护自己也能用。这个小习惯帮我避免过很多次“这个skill当初是怎么想的来着我怎么忘了”的尴尬。这套7步方法后续还能再往深走一步给skill加上脚本支持让它在整理完之后自动生成文件、调用外部工具甚至联动其他skill做一条流水线。但无论怎么扩展设计思路都还是这一讲里那套东西想清场景、抓住输入、定死输出、分步执行、给足示例。把这五根桩打牢后面加什么功能都稳。