最近我在给AI编程助手装Skill折腾了小半个月最强烈的感觉是真正决定一个AI Agent靠不靠谱的往往不是底层模型有多聪明而是你塞给它的“工作手册”写得够不够清楚。Skill就是这份工作手册Skill Creator则是那个帮你把手册写对、写全、写稳的“老编辑”。如果你正在用Codex、Claude Code或者OpenClaw这类工具也遇到过“功能明明装了但表现还是飘”的情况那这篇文章就是给你准备的。我会用自己手搓一个“测试用例生成Skill”的过程把Skill Creator怎么用、有哪些坑、怎么绕一次讲清楚。1. Skill到底是什么为什么大家都在聊它1.1 一个Skill的实质给智能体的“岗位说明书”先说结论Skill不是插件不是脚本也不是一段单纯的提示词。它是把“某个任务的完整做法”打包成一套Agent能直接加载的规范文件。通常里面包含三样东西说明文档、示例、以及可选的辅助脚本。说明文档告诉Agent“你面对什么任务时该启用我按照什么步骤做”示例告诉Agent“输出长什么样才算合格”辅助脚本则负责处理Agent不擅长的计算、文件读写、接口调用等活。我习惯把它理解成“岗位说明书”。你让一个实习生写周报光说“写详细点”没用你得给他模板、给他上周的样例、告诉他哪些部分必须包含。Skill干的就是这件事。没有Skill的Agent像一个只有热情、没有流程的新人你问一句它答一句全看当天状态有了Skill之后它至少知道先拆任务、再按步骤走、最后检查输出质量。在Codex、Claude Code、OpenClaw这些工具里Skill通常以目录形式存在里面放一个主描述文件比如SKILL.md再放几个examples目录里的参考样本。Agent启动后会扫描这些目录把匹配的Skill内容注入上下文。你会发现所谓“装了技术”本质上就是给模型多喂了一段高质量、高结构化的“面试答案”。1.2 Skill和Agent到底谁管谁网上经常有人混淆Skill和Agent我直接用一句话区分Agent是坐在工位上的那个人Skill是他手边那本具体操作的SOP手册。人负责判断、决策、调度手册负责告诉你每一步怎么做。两者不是替代关系而是配合关系。举个例子。你有一个“代码审查Agent”它负责检查PR里有没有明显问题。你可以给它配好几个Skill一个负责静态代码扫描一个负责依赖安全检查一个负责数据库索引评估。Agent读懂了每条PR之后判断当前场景更适合调用哪个Skill然后按Skill里的步骤执行。反过来如果只给Agent十个Skill却没有任何决策规则它也会懵不知道先看哪个。所以设计Skill时一定要明确“触发条件”和“适用边界”这比把步骤写得花哨更重要。另外我注意到很多人把Skill理解成“给Agent使用的插件”其实插件更偏底层能力Skill更偏业务经验。比如“读取PDF”是插件能力“从PDF里提取发票信息并整理成Excel”是Skill。插件解决“能不能做”Skill解决“做得好不好、符不符合你的要求”。1.3 为什么Codex、Claude Code、OpenClaw都在抢着支持Skill最近这些工具不约而同地支持Skill本质原因很简单模型越来越聪明但通用模型的“通”反而成了问题。你让它写一首诗它能写你让它按公司规范输出测试报告它可能就自由发挥了。每家公司的规范、每个团队的流程、每个人偏好的输出格式都不一样模型不可能天生知道。Skill就是给模型做“领域定制”的最小单位。我在OpenClaw里试过装十几个社区Skill确实有惊喜。比如“drawio skill”能让Agent直接生成流程图“测试用例skill”能按边界值方法列用例。但这种通用Skill有时也尴尬因为社区作者不是你同事他不懂你们项目的字段含义。这时候你就需要Skill Creator把“别人的Skill”改造成“自己的Skill”。有些人可能会问我直接在对话里跟Agent说清楚要求不就行了吗短任务可以长任务不行。一是每次对话重复描述会占用上下文窗口二是口头的描述不够稳定模型这次听懂了下次可能又忘了。Skill的核心价值就是把隐性经验显性化、版本化。你封装一次后面每次调用都稳定输出这才是效率真正的来源。2. Skill Creator从“装Skill”到“造Skill”的钥匙2.1 Skill Creator不是单一软件而是一套“造Skill的工作流”先说清楚Skill Creator并不是某个固定App的专属名词。在OpenClaw里有类似“Skill Creator”的角色设定在Claude Code里也有人用子Agent来生成Skill在Codex里则可以自己写一个“Skill生成器”的提示词。但不管形式怎么变核心工作流是一致的你描述一个你想要的技能它帮你整理成结构化的Skill文件并生成测试用例验证效果。所以我把Skill Creator理解为“生产Skill的流水线”。它本身不直接干活而是干“教Agent怎么干活”的活。你需要一个测试用例生成能力就直接跟Skill Creator说“帮我做一个根据PRD生成测试用例的Skill”它会自动拆解输入输出、设计步骤、写描述、生成示例最后甚至帮你跑一遍看这个Skill在真实Agent上能不能被触发。我刚开始觉得这玩意儿有点多余后来被一个场景教育了我连着三天写同一个类型的日志分析每次都让Agent按同样格式输出。有天我实在烦了随手建了一个“日志异常分析Skill”之后Agent看到日志文件就直接按模板输出再也不用我啰嗦。那瞬间我才明白Skill Creator真正省下的不是写提示词的那几分钟而是“重复沟通”的巨大成本。2.2 Skill Creator的核心能力拆解一个好用的Skill Creator至少要具备四件事。第一需求解析能力。它能把一句模糊的“我想让Agent做测试”拆成“输入是什么、输出是什么、有哪些约束、需要调用哪些工具”。这决定Skill的边界是否清晰。第二骨架生成能力。它会自动建好目录结构生成SKILL.md、examples、scripts等标准文件不会让你面对一个空白文件夹发愁。第三提示词工程能力。这是最值钱的部分。它会把“角色设定、执行步骤、输出格式、禁止事项”组织成容易被模型遵循的文本结构。第四验证迭代能力。它能在当前环境里拉起Agent做一次真实调用把失败结果反馈回来然后修改Skill文件。没有验证的Skill就是空中楼阁生成完只知道长什么样不知道能不能跑。我在实际操作中最看重的是第二和第四项。目录结构乱后面维护会崩溃不经过真实测试你根本不知道模型的输出是不是符合预期。Skill Creator如果只是“生成一堆Markdown”而不做验证那就退化成普通的文本生成器了。2.3 手动写Skill和用Skill Creator差别在哪手写Skill不是不行我自己早期就手写过好多份。但效率是真的低。你写完描述得想示例想完示例得调格式调完格式发现Agent根本不触发你还得排查是不是description关键词没写对。这一套下来半小时起步。而用Skill Creator五分钟能出第一版虽然不一定完美但至少骨架是完整的。我做个对比你感受一下对比维度手写Skill用Skill Creator目录结构容易漏文件自动生成标准结构提示词质量依赖个人经验自动套用工程模板示例完善度写得少模型理解不足能从需求反推多角度示例验证成本需要手工在Agent里试可自动跑一轮冒烟测试维护难度版本混乱改一处漏一处更倾向按迭代交付当然Skill Creator也不是万能的。它生成的Skill往往是“标准答案”如果你有极强的业务特殊性还是得人工修改。我现在的习惯是让Skill Creator出初稿我当Reviewer去改。毕竟AI帮我省掉的是繁琐的组装工作而不是业务判断。3. 实操用Skill Creator做一个“测试用例生成Skill”3.1 先想清楚输入、输出和边界我准备做的这个Skill专门用来把“需求描述”转化成“测试用例清单”。你可能会说这跟让Agent直接输出有什么区别区别在于我会给它固定边界它只能基于提供的需求文本进行逻辑推导不能臆想需求背景输出必须是测试用例表格包含用例编号、前置条件、操作步骤、预期结果、优先级如果拿到的需求描述模糊它必须列出“需求澄清问题”而不是硬生成。在让Skill Creator生成之前我先把这些边界想清楚。如果你自己都没想清楚边界工具也帮不了你。一个Skill最怕的就是“什么都能干”因为什么都能干意味着模型不知道在什么情况下该收敛。边界不是限制边界是给模型的安全绳。我把需求整理成一句话“当用户给出一段功能需求描述时Skill需要识别核心功能点为每个功能点生成正向、反向、边界三类测试用例。”这句话看起来简单但所有后续提示词和示例都会围绕它展开。3.2 搭骨架目录、描述文件与示例我先用最传统的方式搭了一个目录结构这也是大多数Skill通用的形态test-case-skill/ ├── SKILL.md ├── examples/ │ ├── login_requirement.md │ └── login_test_cases.md └── scripts/ └── format_check.pySKILL.md是主文件Agent会优先读它。examples里放一组“输入需求”和“期望输出”的对照样例scripts里放一个小的Python校验脚本用于检查生成的用例是不是合法表格。别小看scripts这个目录很多Skill之所以输出不稳定就是因为没有外部脚本做兜底校验。接下来我让Skill Creator生成SKILL.md的初稿它给的内容大概长这样我做了一定简化--- name: test-case-generator description: 当用户提供功能需求描述或用户故事时生成结构化的测试用例清单。 version: 1.0.0 --- ## 目标 基于输入需求生成正反向和边界测试用例。 ## 输入 - 需求描述文本 ## 输出格式 | 用例编号 | 前置条件 | 操作步骤 | 预期结果 | 优先级 | ## 执行步骤 1. 提取核心功能点 2. 识别每个功能点的输入参数 3. 为每个参数设计正向、反向、边界值用例 4. 检查是否有遗漏场景 ## 禁止行为 - 不得虚构需求中不存在的功能 - 不得跳过需求澄清这一段看起来简单但“禁止行为”非常关键。模型普遍有补全倾向你不禁止它它就会自动给你加需求。比如你说“用户登录”它可能顺手帮你加了“记住密码”功能而这个词在需求原文里根本没出现。禁止行为就是拉住模型缰绳的那只手。3.3 把提示词打磨到“指哪打哪”目录搭好只是第一步真正决定Skill好不好用的是SKILL.md里的提示词质量。我反复改了三版才发现一个细节模型并不会自动按“步骤1步骤2步骤3”严格走它可能一上来就输出表格。所以我在提示词里加了“先列出功能点清单再生成用例”的强制顺序并且要求它必须先输出“需求澄清问题”再输出用例表。我还把examples目录用得很重。examples/login_requirement.md里写了一段很普通的“用户登录”需求examples/login_test_cases.md里则是配套的完整输出。为什么要把示例放完整因为对模型来说一个实际例子比十句抽象说明都好用。你不用给它解释“边界值”是什么它看到用例表里的真实数据自己就能反推规律。Skill Creator在这里的贡献是帮我生成了这组初始示例然后我手动修正了几个字段。比如我原本没想到“密码错误次数锁定”是它从边界值角度想到了这类场景。这种“交叉补全”是人工写Skill时最容易遗漏的。3.4 安装到Agent并完成一次真实测试文件准备好后就要把Skill装进Agent运行环境里。我在OpenClaw里是把整个test-case-skill目录放进skills文件夹然后在配置里启用。Claude Code的姿势也差不多核心都是“让Agent知道这个Skill存在并且能通过描述匹配到它”。激活之后我直接丢了一段模拟需求过去“用户可以用手机号或邮箱注册注册时需设置6-16位密码密码必须包含字母和数字。”过了一会儿Agent返回的不只是一张用例表还先列了它理解到的功能点手机号注册、邮箱注册、密码规则、重复校验。这个“先列理解”的动作太关键了它能让你在早期就发现Agent有没有误解需求。第一次测试结果并不完美。它生成的“手机号格式不正确”用例写的是“请输入正确的手机号”但预期结果却是“提示格式错误”。这种描述不够精确但大方向已经对了。我把这段失败反馈交给Skill Creator让它修改提示词增加了一条“用例步骤必须描述具体操作值”。改完之后第二轮生成的用例就明显更精确了。3.5 测试结果分析与迭代这个Skill最终稳定下来花了不到半小时。你以为故事就这么结束了并没有。第二天我给它喂了一个新的需求“用户上传图片时图片大小不能超过5MB支持jpg和png格式。”它这次生成的用例覆盖了空文件、超限、格式不支持、正常上传但我看了一下漏掉了“文件名为中文”的场景。不是它不聪明而是我并没有在examples里放任何关于文件名的异常样例它自然就没想到。这给了我一个很重要的启发Skill是需要持续喂养的。你每次发现一个漏测点就把它补进examples这个Skill会越用越准。Skill Creator不是一锤子买卖它更像一个陪你对练的教练你每次暴露问题它帮你优化下一次输出。用这种方式我还做过其他Skills。比如让Agent根据NVIDIA显卡参数生成推理资源估算表只是把输入改成“GPU型号、显存、并发需求”输出改成“推理可并发数、显存占用估算、推荐配置”。流程一模一样只不过换了描述和示例。这也说明掌握了Skill Creator的方法论之后很多重复性分析工作都能被沉淀成可复用的Skill。4. 踩坑实录做Skill时最容易翻车的几个地方4.1 不生效触发条件写得像“没说”很多新手第一步就栽在这——Skill装好了但Agent怎么都不调用。我排查过几次发现90%的原因是SKILL.md里的description写得太模糊。比如你写“处理日志”Agent根本分不清什么时候该用你要是写“当用户提供nginx access日志或应用错误日志时分析状态码分布和异常堆栈”触发率就高很多。所以description就是你给Agent的“关键词索引”。它要足够具体具体到包含明显的触发词。你甚至可以主动在description里加同义词比如“日志”对应“log”“错误日志”“access.log”。但别堆太多堆多了模型又不知道优先级了。我自己的习惯是主描述写清楚“什么输入”再在小节里写“适用和不适用场景”。另外很多Skill不生效是因为名字和description里的关键词不一致。你在目录里叫test-case-generatordescription里却写“测试用例”Agent扫描时可能只匹配description导致永远等不到触发。装好Skill之后一定要在真实对话里大声说出触发词看它会不会响应。这一步能帮你省掉很多盲目调试。4.2 乱说话提示词太短Agent自由发挥Skill文件里的提示词写得越短Agent的自由度就越大这是好事还是坏事取决于你想不想要标准化输出。大部分业务场景我们追求的是稳定所以我宁可把步骤写细一点也不愿意每次都看到不同的输出结构。比如我最初写的测试用例Skill只有一句话“生成测试用例”。结果Agent输出了各种格式一会是表格一会是列表我一怒之下把输出格式、步骤、结构全固化到SKILL.md里世界才清净。我还加了一条“如果输入需求本身有歧义先列出3个澄清问题再继续”这样它就不会擅自脑补了。这里要提醒一个度的问题提示词太长同样有风险。模型不是完全按你的步骤执行它可能只读前面的内容后面细节直接被忽略。我踩过最大的坑是把全文写成两三千字的“论文”结果模型反而抓不住重点。现在我的SKILL.md一般控制在500-800字其他细节放到examples里让模型通过样例自己理解效果反而更稳。4.3 跑不起来脚本路径、权限和依赖Skill里如果带了脚本问题就多了。最常见的坑是相对路径。Agent在不同的工作目录启动时可能找不到脚本文件。我吃过一次亏写了个Skill调用scripts/parse.py结果Agent是在项目根目录里运行的路径解析直接失败。后来我改用绝对路径或者让SKILL.md里写清楚“脚本路径相对于Skill目录计算”才稳定下来。权限问题也很烦。某些运行环境对脚本执行有沙箱限制Agent没法直接运行Python或者没法访问某些文件夹。这时候Skill里的脚本形同虚设。我在OpenClaw里就遇到过Agent能读取文件但没法调用某个CLI工具的情况。解决方案是给Skill配上工具权限声明在配置里把需要的工具显式放行。如果你自己搭环境最好在Skill里附一张“运行环境要求”清单避免别人用你的Skill时跑不起来。还有一个容易忽略的是依赖。脚本用到了第三方库但环境里没装。我的习惯是每个Skill目录下放一个requirements.txt并在SKILL.md里提示“使用前请安装依赖”。虽然听起来麻烦但总比Agent跑到一半报ModuleNotFoundError强。4.4 塞太满Skill太多把上下文挤爆这个坑不是单个Skill的问题是装太多Skill造成的。Agent的上下文窗口是有限的每次对话它都要把所有启用的Skill描述读一遍再加入当前对话内容。当Skill数量超过二三十个即使每个只占几百字也会挤占大量上下文空间导致模型“记不住”你后面说的话。这是我装了四十多个社区Skill后最痛的领悟。建议是分类管理、按需启用。不同项目可以配不同的Skill集合而不是一股脑全开。我的机器里目前有几十个Skill但一次只会启用和当前任务相关的五到八个比如涉及代码库变更就启用“代码审查Skill”涉及日志就启用“日志分析Skill”。这样既保证了能力覆盖又不会把上下文爆掉。另外Skill文件本身也要控制体积。有些社区Script能把整个项目的说明文档塞进去看起来是“丰富”实际上是大半本书。Agent加载之后真正的有效信息可能只占5%。用Skill Creator生成内容时你可以在提示词里明确“压缩示例、只保留关键文本”它能帮你把描述大幅瘦身。4.5 改崩了没有版本管理出现回归问题Skill也是代码也会迭代也会改出bug。我之前改了一个“PDF提取Skill”把描述词扩充得更好用了结果第二周再用发现它提取字段的格式变了跟下游Excel模板对不上。那次我花了快一小时排查才发现是我自己某次微调把“输出格式”段落删了一行。从那以后我给每一个Skill都做了版本管理目录里放CHANGELOG.md每次改动写下改了什么、为什么改。如果你的Skill放在Git仓库里那更简单。每次修改提交一次出问题直接回滚。不要嫌麻烦一个稳定可用的Skill是长期维护出来的不是一次生成完就完事。Skill Creator在生成新版本时可以保留旧版本记录有点像“迭代式生成”。你每次把遇到的问题反馈给它它会产出新版本但你需要保留之前的可用版本作为兜底否则迭代几次之后可能越改越烂。还有一个小技巧给每个Skill写一个“回归测试用例集”。比如测试用例生成Skill你可以预留三个典型输入每次改完SKILL.md就跑一遍这三个输入确认输出没有回归。这在AI工具链里很少见但极其好用。所谓“像软件工程一样管理Skill”就是这个时候最有价值。我在实际使用中还有一个体会不要指望Skill Creator一口气生成完美结果它更像一个加速器帮你把60分的初稿迅速做出来然后通过真实使用场景逐步调到90分。最终让Skill好用的不是工具本身而是你愿不愿意持续反馈、持续修正。这个思路放到所有AI工具上都成立模型负责下限你负责上限。