从 Claude Code 到 Codex再到 Trae最近一年里 AI 编程工具里最热闹的词大概就是 skill。我见过很多人兴致勃勃打开编辑器新建文件夹写了几段 prompt 就宣布“我做了一个 skill”结果用两次就吃灰。真正好用的 skill不应该是一段临时提示词的复制粘贴而是一套经过抽象、有边界、有输入输出契约、可验证、可维护的方法包。这篇文章想跟你聊的正是怎么把“创建 skill”这件事本身变成一条高效流程顺便把我自己在项目里反复用的 Review 清单完整放出来。1. 先把 Skill 的概念边界划清楚1.1 Skill 的底层形态不是“一个提示词文件”这么简单如果只看表面skill 通常是一个文件夹里面有说明文档、示例、参考资源甚至可执行的脚本。比如 Claude Code 社区里常见的 .claude/skills/ /SKILL.md或者 Codex 生态里和 AGENTS.md 配合的 skill 目录。文件夹里的内容看起来像文档但本质上skill 是给模型使用的一份“能力说明书”。这份说明书和普通提示词最不一样的地方在于它试图把“完成某类任务时需要的知识、步骤、判断标准、常见坑”全部固化下来并且在合适的时候被自动加载。所以它不只是告诉模型“你是个专家”而是明确告诉模型“面对什么输入、按什么步骤、产出什么结果、出现什么情况该做出什么判断”。我见过不少人创建的 skill 关键词是“你是一个资深运维专家请帮我分析日志”这种描述太虚了。模型看完并不知道它该读哪个文件、该按什么顺序找异常、该输出什么格式。真正能反复用的 skill一定会把“怎么判断”“先做什么再做什么”“输出长什么样”写得足够具体让模型照着走就能得到一个稳定质量的结果。1.2 Skill、Agent、Plugin、Workflow到底差在哪很多初学者会把 skill 和 agent、插件、工作流混在一起。我在实际交流中经常被问到“既然 skill 能做这么多事那还要 agent 干什么”这是个好问题边界其实很重要。我习惯用三个词区分它们skill 回答“我会做什么”plugin 回答“我能调用什么外部工具”agent 回答“我该自主决定做什么”。plugin 偏工具集成层面比如连接数据库、调 API、操作浏览器skill 偏知识和方法层面告诉模型完成一个任务的标准方法和判断准则agent 则是在更高层做目标拆解和行动决策它可以调用多个 skill 和 plugin 来完成一个复杂目标。工作流又不一样。工作流更像流水线强调步骤之间的固定编排skill 则更像工具箱里的一个工具什么时候用、怎么用由调用的 agent 或模型决定也可以由用户显式指定。一个很直观的判断标准是如果任务可以拆成一二三四步每一步固定不变那是工作流如果同一个任务在不同输入下需要做不同判断而是更需要模型依据经验灵活处理那更适合做成 skill。1.3 为什么做 Skill 也需要“方法抽象”这是全文最想强调的一点。很多人创建 skill 时是对着某个具体问题写了一段“一次性解决方案”。比如看到一份报错日志让模型帮忙排查试了几次效果不错就把这段 prompt 存成 skill。结果下次换了一个日志格式、换了一个业务背景效果就崩了。原因在于他没有做“方法抽象”。方法抽象的意思是从一个个具体案例里提炼出可复用、可迁移的通用方法再把这些方法固化成 skill。打个比方一个做菜 app 里如果只记录“西红柿炒鸡蛋先炒蛋再放西红柿”换个食材就用不了但如果你抽象出“先处理食材 - 预热锅具 - 控制火候 - 调味收汁”的通用流程再加上“不同食材熟成速度不同”的判断准则它就能适用于更多菜。Skill 也一样。高价值的 skill 不应该绑定某一个具体文件、某一种具体报错、某一套具体话术而应该绑定“完成这类任务时通用的方法与判断逻辑”。具体案例可以作为示例放进去但真正指挥行为的是被抽象出来的那套方法。这也是为什么很多社区里口碑最好的 skill看起来并没有写特别多“业务细节”反而花大篇幅写“步骤”和“判断规则”。2. 高效创建 Skill 的五步流程2.1 第一步从真实问题出发做边界拆解很多人设计 skill 是从“我想做一个 XX skill”这种 idea 出发而不是从一个真实、具体、反复出现的问题出发。这两者的差别非常大。从 idea 出发容易做出一个什么都想管、却什么都管不好的全能型选手从真实问题出发才能把 skill 的边界界定清楚。我建议你先记录最近一周的工作找出“哪个任务你反复做了三遍以上”。比如你每周都要分析一次业务日志、每周都要整理一次周报、每次写英文邮件都要调整语气。这个“反复出现”就是 skill 的价值基础。接下来你要做的是边界拆解这个问题最核心的输入是什么期望的输出是什么哪些情况是它该负责的哪些情况应该直接拒绝举个例子“日志分析”这个需求听起来很宽但如果你拆解一下会发现它至少能分成“错误日志快速定位”“性能瓶颈分析”“安全事件排查”“业务数据统计”这几类。每一类的关注点、判断逻辑、输出格式都不一样。如果你把它们塞进同一个 skill模型会犯迷糊它不知道你现在是想定位崩溃还是想做性能分析。所以第一步一定要把边界划出来宁可一个 skill 只解决一件事也不要试图做一个万能包。2.2 第二步设计输入/输出契约边界确定之后最重要的事情就是设计输入输出契约。我经常说skill 本质上是一个函数函数有参数、有返回值参数不定清楚调用方就不知道怎么用。这里说的输入不是指“用户会输入一句话”而是指模型在执行 skill 时需要哪些信息、以什么形式拿到这些信息。我习惯在 SKILL.md 里写清楚三块内容必需输入、可选输入、禁止依赖的信息。必需输入是任务成立的前提比如日志分析 skill 里日志文件路径是必需的可选输入是能增强效果的补充比如“期望的时间范围”“已知的业务上下文”禁止依赖的信息是为了阻止模型瞎猜比如“如果没有提供服务器架构图不要凭空假设部署方式”。输出也同理。你希望模型最终给你的是一段文字解释还是一份结构化报告是 Markdown 列表还是 JSON 数据方便后续工序直接解析如果输出格式不固定模型每次都会自由发挥最后你必须人工二次加工skill 的价值就会大打折扣。把这个契约写死模型后续的表现才稳定。2.3 第三步按“先骨架后血肉”写指令很多朋友写 skill 最大的问题是“一步到位”。打开文档就从第一行开始写想到哪里写到哪里结果写到后面自己都忘了前面说了什么。我的习惯是先搭骨架再填血肉。骨架只需要四部分目标与边界、输入与输出、执行步骤、判断准则。先把这四部分的标题和一句话要点写出来然后不断问自己如果模型只读这段内容它能顺利完成这个任务吗哪里有歧义哪里会卡住骨架完整了再往每一部分里填充细节、示例和常见坑。关于 SKILL.md 的长度我建议控制在“不超过 3000 字”的可读范围之内。太短往往信息不足太长则会在每次调用时消耗大量 token而且关键规则会被淹没。如果你想放入大量参考资料更好的做法是把它们放在 references/ 文件夹下在 SKILL.md 里只写“什么情况下读哪份文件”。这样模型按需加载比一股脑全塞进上下文要省得多。2.4 第四步用 3~5 个黄金用例做回归验证写完 skill 不是终点验证才是关键。我每次写完一个 skill都会准备 3~5 个“黄金用例”也就是这个任务领域里最典型、最容易被问到的问题。验证时用一个干净的会话不要带任何多余上下文直接调这个 skill 来跑一遍。黄金用例要覆盖三种情况常规输入、边界输入、异常输入。常规输入对应最典型的场景边界输入对应那些“看起来能处理但容易出错”的输入比如空日志、超大日志、完全没有匹配结果的日志异常输入对应那些“本来就不该它管”的问题比如你用日志分析 skill 去问“明天的天气怎么样”这个时候应该被拒绝而不是硬着头皮瞎编。每次验证时记录两个变量输出正确率和输出格式稳定率。我一般要求正确率至少达到 80% 以上格式稳定率达到 100%也就是说所有验证例子的输出结构必须一致。如果某个用例失败了不要急着改 prompt 硬套要找出是哪条规则没覆盖到把那部分判断准则补进 skill 里。2.5 第五步版本化、灰度、迭代Skill 写出来之后它会随着使用慢慢“腐烂”。业务背景会变工具版本会变模型本身也会变。所以我不推荐把 skill 当成一次性的静态文件而是建议像管理代码一样管理它。给 SKILL.md 加一个 frontmatter里面写上 version、date、last_used、compatible_tools每次修改都递增版本号并且在文档末尾维护一段 changelog。别小看这个动作当你一个仓库里有十几个 skill 的时候你就知道版本信息有多重要了。我经历过好几次排查半天最后发现是因为某个 skill 换了个老版本导致的。迭代节奏上我建议不要每次都大改而是先小范围跑通再逐步扩大场景。刚写完的 skill 先在 3 个真实任务里跑观察哪里解释得模棱两可哪里步骤顺序不对再改第 2 版用一两周之后覆盖更多情况再改为第 3 版。这套节奏能避免你因为一两次失败就直接推翻重写也能让 skill 的质量稳步上升。3. 方法抽象让 Skill 从小技巧变成可迁移方法论3.1 案例复制与方法抽象的本质区别我在做方法抽象的时候经常拿“菜谱”和“烹饪方法”来对比这个例子前面提过但它值得再深入说一层。菜谱解决的是“这道菜怎么做”方法解决的是“这一类菜怎么做”。两者不是对立的菜谱是方法的具象示例方法是菜谱背后的规律。Skill 里的示例就是菜谱而真正驱动模型跨场景发挥作用的是藏在示例背后的那套“这一类任务怎么做”的方法。我再举一个实际例子。很多人想做一个“写周报的 skill”如果只是案例复制你可能会在 skill 里写“请参考以下模板输出本周工作、下周计划、风险点三部分。”这样的 skill 在格式固定时有效但一旦遇到“项目中同时有开发任务、管理任务、临时支持任务”这种复杂情况模型就不知道该怎么归类了。如果做方法抽象你会提炼出“区分工作类型 - 按价值排序 - 量化成果 - 关联目标 - 暴露风险”的通用流程还会给出一套判断标准什么信息该放在成果里什么信息适合放在风险里什么样的表述是空话。这就是案例复制和方法抽象的根本差异案例复制只给了模型一个“像什么”方法抽象给了模型“怎么想”。真正被反复调用的 skill靠的必然是后者。3.2 抽象的三个层次任务模板、决策树、质量准则进行方法抽象时我一般从三个层次下手组合起来使用。第一个层次是任务模板也就是把完成任务拆成固定顺序的步骤。比如“先收集信息、再分析现状、然后给出方案、最后列出执行计划”。这一步解决的是“从哪儿开始”的问题防止模型一上来就跳到最后一步。第二个层次是决策树也就是在关键节点上给出分支判断。比如判断日志异常时如果错误码是 4xx优先检查请求参数和权限如果是 5xx优先检查服务端依赖和资源水位如果完全无错误码则进入时间线关联分析。决策树能显著提升模型在复杂场景下的准确率因为它把“有经验的人会怎么判断”显式地写了出来。第三个层次是质量准则也就是“什么才算做得好”。比如日志分析报告不能只列现象必须给出可能性排序周报里的每条成果必须包含量化数字代码 review 意见必须引用具体行号。质量准则决定了输出的下限很多 skill 之所以输出粗糙就是因为缺少这些“验收标准”。3.3 一个范例把“Nginx 日志分析”抽象成“通用日志排查”为了让你更直观理解抽象过程我拆一个具体的例子。假设你一开始想做的 skill 是“Nginx 错误日志分析方法”。如果你不做抽象你的 skill 可能会写“读取 error.log查找 ‘connection refused’输出出现次数最多的 IP。”做方法抽象时你要先问自己Nginx 日志分析和我之后可能遇到的 MySQL 日志、应用日志、系统日志有什么共性它们的共性在于先确定时间范围、再分类错误类型、然后按维度聚合、最后定位根因。这就是“通用日志排查”的方法。于是我把 skill 改造成这样输入是任何日志文件路径和问题描述第一步识别日志格式和字段语义第二步按时间窗口切分建立事件时间线第三步按错误类型或关键字分组聚合第四步关联错误之间的因果链第五步输出“现象 - 可能原因排序 - 证据 - 建议排查方向”的结论。Nginx 日志只是放在 examples 里的一个案例。这样改完之后这个 skill 既能分析 Nginx也能分析 MySQL 慢查询日志甚至能处理某天你临时拿到的一份 Python 应用堆栈日志。同样道理你在做别的 skill 时也应先做这个“横向迁移”的思考这个任务有没有更抽象的上一级如果下次换了一个工具、换了一个品类这套方法还成立吗成立的部分才是你真正要固化的核心。3.4 抽象到什么粒度才合适抽象不是越多越好。我之前吃过一个亏把一个“邮件撰写 skill”抽象得过于宏大在 SKILL.md 里写了一大堆关于“沟通本质”和“用户心理”的内容结果模型每次写出来的邮件都又长又空因为方法层次太高反而丢失了具体执行细节。我的经验是抽象粒度以“任务场景变化时核心步骤仍然稳定”为上限。如果换一个场景步骤就有一半对不上那说明抽象粒度太细了如果换一个场景步骤依然能用但是示例太少模型不知道怎么落地那说明抽象粒度合适但示例需要补全。实际操作里我一般会先做一个“只能覆盖当前场景”的版本然后每遇到一个新场景就回头改一次逐步上移抽象层次。不要在第一次写的时候就追求放之四海而皆准那是做科学研究不是做工具。核心原则是在“够用”的前提下尽量抽象让 skill 有迁移能力但不要抽象到导致指令失去抓手。4. 从零构建一个高质量 Skill完整实操记录4.1 目录结构与元信息设计下面我完整走一遍从零创建 skill 的过程这套流程我在多个项目里反复用过。首先看目录结构。主流工具对 skill 的识别规则略有差异但大同小异我会用一个兼容性比较高的结构my-skill/ ├── SKILL.md # 主说明文档模型优先加载 ├── references/ # 参考资料按需加载 │ └── log-levels.md ├── examples/ # 典型示例及期望输出 │ ├── nginx-case.md │ └── mysql-case.md └── scripts/ # 可选的可执行脚本 └── parse_time.pySKILL.md 是核心。它通常包含一个 YAML frontmatter里面写 name、description、version 这些元信息。description 特别重要因为它是模型判断“什么时候调用这个 skill”的关键依据。我见过太多人把 description 写成“用于日志分析”导致模型在用户问天气时也可能试试这个 skill。正确做法是把 description 写成包含触发条件、使用边界、输入要求的完整句子比如“当用户提供日志文件路径或日志内容并希望定位错误、分析性能或排查故障时使用。不适用于没有日志输入场景的问题。”4.2 我推荐的核心字段与写法模板我建议 SKILL.md 的正文按固定模板组织字段如下目标Goal一句话说明这个 skill 要完成什么任务、达到什么质量标准。边界Scope明确什么情况属于该 skill 负责什么情况应该礼貌拒绝。输入Input列出必需输入、可选输入、禁止依赖的信息。输出Output给出输出结果的结构尽量到小标题级别。执行步骤Steps用编号列出标准执行流程每个步骤写清目标和关键操作。判断规则Rules给出各类分支情况的处理策略。示例Examples放 2~3 个典型例子强调“输入到输出”的映射关系。自我检查Self-Check让模型在输出前对照几项准则做自查。这个模板的好处是结构统一维护方便而且不依赖特定工具。不管你是给 Claude Code、Codex、Trae 还是自己的 agent 框架写 skill都可以直接用。4.3 完整示例一日志排查 Skill下面是一个简化版 SKILL.md我保留了核心逻辑方便你体会结构name: log-troubleshooting description: 当用户提供日志文件路径、日志文本或日志相关故障描述并希望定位错误、分析异常、排查性能问题时使用。没有日志输入时不要使用。 version: 1.3.0目标对给定日志进行系统排查输出有证据支撑的原因排序和下一步建议。边界负责错误定位、异常聚合、时间线分析、性能瓶颈初判。不负责无日志输入时猜测问题不经过分析直接给结论。输入必需日志文件路径或日志文本片段。可选问题发生时间范围、已知变更、服务架构简述。禁止假设不要假设日志来自哪个系统除非用户明确说明。输出格式日志概览来源、时间范围、日志总量、日志级别分布。异常聚类按错误类型和关键字聚合按出现次数排序。时间线还原将关键异常按时间排列找出先后关系。原因排序给出 2~3 个最可能的原因并给出对应证据。建议排查方向每条结论对应一个可执行检查项。执行步骤读取并解析日志格式明确字段含义。按时间窗口切分排除无效噪声。识别日志级别对不同级别分开聚合。对错误信息做聚类去除重复堆栈。关联错误前后的上下文事件。输出上述五段式报告。判断规则出现 timeout 类错误优先检查依赖服务和网络链路。出现 OOM 类错误优先关注内存增长曲线和堆配置。出现权限类错误优先检查凭证有效期和角色策略。无法确认根因时禁止用“可能”堆砌必须给出验证方法。这个示例比较通用。你如果直接拿去看会发现它根本没提“Nginx”“MySQL”这些词但真正遇到这些系统日志时它都能用。4.4 完整示例二去 AI 味写作 Skill热搜词里有一组很有意思比如 humanizer skill、去 AI 味 skill、write skill。这类 skill 的热度说明很多人写出来的文本被一眼识破。我自己也维护过一个“去 AI 味”写作 skill核心方法其实也可以抽象出来。它和日志分析 skill 的结构完全一样只是内容不同。目标是“将书面表达改写得更自然接近真人作者口吻”输入是待改写文本以及可选的“目标读者”“发布平台”执行步骤则包括先消除模板化开头、再用具体细节替代抽象形容词、调整句式长短节奏、删掉非必要的连接词、最后做语气一致性检查。这里同样用到了方法抽象不要只写“请写得更自然一点”而要给出“哪些词需要禁止”“句子长度如何变化”“用什么细节来替代空话”这些可执行规则。比如“通过本文你将学会”这种开头在去 AI 味 skill 里会被标记为禁词所有“深入了解”“显著提升”这类虚词都会被要求替换成具体的数字、案例或对比。这类抽象出来的判断规则才是去 AI 味的关键。4.5 如何与 Claude Code / Codex / Trae / LangGraph 集成不同工具对 skill 的加载方式不太一样但核心逻辑都是“在合适的时机把 SKILL.md 的内容注入上下文”。我在多个工具里验证过下面几点是通用的。Claude Code 类工具通常约定放在项目或用户目录下的 skills 文件夹中模型通过 description 自动决定是否加载。这类工具里SKILL.md 的 description 写得好不好直接决定 skill 是否会被正确触发。Codex 这类工具对 skill 的识别更多要配合 AGENTS.md 体系你需要在 AGENTS.md 里显式说明 skill 的使用边界、加载条件和与其他工具的协作关系。这其实要求你的 skill 描述具备更强的“路由”意识能让 agent 在多个候选技能里选出最合适的一个。Trae 这类 IDE 集成工具也会读取类似约定但我在实践中发现IDE 环境里 skill 往往需要强调“不与用户的即时编辑冲突”所以最好在边界部分写清楚执行类操作前必须确认用户意图。LangGraph 这类 agent 编排框架则不太一样它更依赖显式代码注册。你在框架里要把 skill 封装成一个节点或子图或者作为工具集挂到 agent 的 tools 里。这样做的好处是控制力更强你不会受限于模型是否“愿意”调用技能坏处是你需要开发成本而且 skill 更新后要同步修改代码引用。遇到“怎么给 LangGraph 增加 skill”这种问题时我一般建议先想清楚你需要的是“自动触发的知识型 skill”还是“显式编排的节点逻辑”前者用规则注入后者用代码封装不能混着来。5. 附 Review 清单上线之前对照这 18 项自检一遍5.1 功能与正确性检查这部分检查的是“能不能完成主任务”。[ ] SKILL.md 里的目标和输出格式是否能让一个完全不了解你意图的人看懂[ ] 执行步骤是否按顺序编号且每一步都有明确输入和产出[ ] 是否提供了至少 2 个黄金示例示例里是否包含“输入 - 过程 - 输出”的完整链路[ ] 判断规则是否覆盖了至少 80% 的常见分支场景[ ] 自我检查项是否真的可执行而不是空泛的“请确保答案正确”[ ] 拿 3 个黄金用例实测正确率是否达到 80% 以上5.2 边界与异常检查这部分解决的是“别乱干活、别瞎编”。[ ] 边界部分是否明确列出“拒绝处理”的场景[ ] 遇到缺少必需输入时模型是会继续编还是会主动询问补充信息[ ] 有没有禁止模型“假设”某类信息比如没有提供架构时不得猜测部署方式。[ ] 异常输入测试空输入、错误格式输入、极端体积输入是否都通过了5.3 可移植性与依赖检查这部分解决的是“换个环境还灵不灵”。[ ] SKILL.md 里是否引用了具体机器路径、具体系统提示语、不可迁移的绝对指令[ ] 如果依赖外部脚本脚本入口和运行方式是否写清楚了[ ] 是否避免了“只在某个固定工具版本上可用”的语法[ ] description 是否清晰到能让模型只靠字段内容就做出正确触发决策而不是依赖某个外部路由5.4 命名、说明与可维护性检查这部分解决的是“长期能不能维护”。[ ] skill 名称是否表意清晰避免用 v1、demo、test 这类无意义名字[ ] frontmatter 是否包含 version、date、compatible_tools 等元信息[ ] 是否维护 changelog记录每个版本的变更点[ ] SKILL.md 长度是否控制合理参考资料是否已经拆分到 references/ 目录[ ] 是否定义了一个清晰的所有者或维护人多人在场时这一点尤其重要。上面这些项目建议每次发布 skill 前至少完整过一遍。不要嫌麻烦我统计过自己踩过的坑至少有一半是“发布前花十分钟自检”就能避免的。6. 实操中踩过的坑和排查思路6.1 模型不触发 Skill原因多半在 Description这是我被问得最多的问题“我的 skill 写了但模型一直不用。”排查顺序一般是这样的先看 description 是否明确写了“什么情况下使用”再看是否和其他 skill 的触发条件重叠最后看工具是否真的扫描到了对应目录。Description 写得太宽泛是最常见的问题。你写“用于日志分析”模型可能觉得所有和日志沾边的对话都可以用它反而因为匹配范围太广而降低了触发优先级正确做法是写“当用户提供日志文件或日志文本希望定位错误、分析性能、排查故障时使用”绑定了具体输入形态和用户意图。另外如果同一个场景下有多个 skill 都可以触发模型往往会困惑必要时你需要给 skill 增加优先级字段或者在 description 里用“优先于 XX skill 使用”这类说明。6.2 输入输出太随意模型开始自由发挥很多 skill 第一版失败都是因为输入输出契约没定死。最常见的情况是用户在对话里只说了一句“看一下这个日志”没有给路径于是模型要么假装知道路径要么自己猜一个路径最后给出一堆毫无根据的结论。我后来在 SKILL.md 里加了一条硬性规定缺少必需输入时必须先向用户索要不允许猜测。同时输出部分明确为五段式报告任何不按照格式输出的结果都算失败。加了这个约束之后效果立竿见影。模型执行质量不稳定很多时候不是模型变笨了而是你没把“不确定性”堵住。6.3 环境依赖太强换个机器就废了Skill 里如果写了“用 python 脚本解析日志”就要考虑这台机器上有没有 python有没有相关依赖包。如果你的 skill 依赖大量外部命令和包一定要在文档里写清楚前置条件并且建议提供降级方案。比如日志分析 skill 里的 parse_time.py如果目标环境没有 python我会在 SKILL.md 里同时给出“没有脚本时的手动解析思路”让模型在遇到缺依赖的情况下不至于直接罢工。再比如有些 skill 依赖 curl、jq 这类常见命令我会明确注明“可选依赖缺失时改用纯逻辑处理”。这种细节看似不起眼却决定了 skill 能否在不同环境里被稳定复现。6.4 Token 预算失控Skill 不是“知识库”有一个误区要强调不要把 SKILL.md 当成无限容量的知识库往里塞内容。有些朋友做“行业分析 skill”把行业报告、历史数据、公司列表全塞进 SKILL.md结果每次调用都会消耗巨量 token响应速度变得很慢关键方法反而被淹没在大量背景资料里。正确思路是SKILL.md 里只放“方法论和判断规则”这类高频信息低频查询类的资料全部丢到 references/ 文件夹并注明“什么情况下才去读取”。模型不是一次性读完 references 里所有文件而是按需加载这样既保证信息完整又控制上下文占用。我把这个习惯叫做“方法进正文知识进附件”。6.5 太多 Skill 反而没用建立技能内阁最后想说一个组织层面的坑。随着你建的 skill 越来越多一定会遇到“技能堆积”的问题每个 skill 单独看都还可以但放在一起就会互相打架。我和团队在维护一个超过 30 个 skill 仓库的时候痛感特别深。后来我们做了一个“技能内阁”机制每次新增 skill 前必须先在目录里检查是否已经存在职责相近的 skill如果存在要么合并要么明确边界差异每个 skill 的 description 里都必须写清楚它与相近 skill 的边界。另外每个季度做一次清理把三个月没被调用过的 skill 标记为“deprecated”六个月没调用直接归档。这套机制看起来简单却能让整个技能库保持长期可用。就我个人的经验来说创建 skill 最值钱的部分从来不是 prompt 本身而是对任务领域的理解和对经验的抽象能力。你越是能在不同场景之间找到共性越是能把判断规则写得精确你产出的 skill 就越耐用。每次想更新某个 skill 之前我都会先问自己一句我是在打补丁还是在优化这套方法本身这个习惯帮我做了很多次关键判断也尽量避免把技能仓库变成一堆无法维护的碎片文件。