1. 先搞清楚Skill的本质是什么它到底解决了什么问题先说一个我观察到的现象。最近半年Claude Code、Codex、Cursor 这些 AI 编程工具卷得飞起几乎每个工具都在推自己的 Skill 机制。大家对新概念的第一反应都一样这玩意儿是不是就是高配版 Prompt是不是跟 Agent 一个东西我用 Cursor 写代码本来就很顺手非得学一套 Skill 的玩法图什么我自己最初也是这么想的直到在项目里真正吃到了甜头才把这事想明白。拿claude code skill来举例你给它一个任务它本身很聪明但聪明不代表稳定。同一个任务让它写十次可能十次的思考路径都不一样。有时候它会跳过关键步骤有时候它会自己脑补一个你根本不需要的模块。这不是模型能力不够而是缺少一套强制性的“做事规范”。Skill 干的事情就是把这套规范固化下来告诉你手底下的模型遇到这类任务先看什么文件、按什么顺序做、输出什么格式、哪些坑绝对不能踩。所以你可以把 Skill 理解成一个“岗位说明书”。模型是那个能力很强但容易跑偏的新员工Skill 是贴在工位上的那张 SOP标准作业流程。没有 SOP新员工发挥全凭状态有了 SOP哪怕状态一般下限也保得住。这也是为什么全网都在搜“skill怎么编写”、“skill推荐”、“好用的skill”——因为大家已经开始意识到模型本身的差距在缩小真正拉开效率差距的是谁手里沉淀的 SOP 更完整、更贴合自己的业务。那 Skill 和 Agent 的区别在哪这是热搜里出现频率极高的问题。我的理解是Agent 是一个自主行动的实体它负责“感知-决策-执行”的闭环你给它一个目标它在环境里跑起来自己做判断Skill 更像是一张能力卡片它本身不会跑它是给 Agent 或者模型提供的一套方法论和工具箱。你问 Agent“帮我整理会议纪要”Agent 如果装了这个 Skill就知道第一步要提取音频、第二步要分段、第三步要按照模板输出纪要如果没有 Skill它可能直接甩给你一段干巴巴的文字摘要。两者不是一个维度的概念没有可比性——Agent 是司机Skill 是司机手里的导航地图。地图再好得有车模型能力和司机Agent框架来用。还有一个很关键的判断标准什么时候需要引入 Skill我给自己定了一个阈值——同一个任务我手动调教模型超过三次就值得把它写成 Skill。比如我每次让模型写周报都要重新描述一次团队背景、项目进展、汇报风格这个重复成本就是白花花的 token。写成 Skill 之后一句话“按团队周报 Skill 生成本周周报”就搞定了。这套逻辑适用于编程、论文写作、数学建模、PPT 制作等几乎所有场景所以你会看到“论文skill”、“ppt skill”、“数学建模skill”这些词在社区里疯传本质都是同一个诉求把重复劳动固化下来。2. Skill 的主流形态从纯文本到可执行脚本的演进搜过“skill 有哪些形态”的朋友应该发现了网上的说法五花八门有的说是 Markdown 文档有的说是带脚本的文件夹还有的说 Skill 是让 AI 调用本地工具的一种协议。其实都对因为 Skill 本身是一个演化中的概念不同工具对它的定义并不完全统一。我按自己的实践把目前主流的 Skill 形态分成了五类从轻到重排序。2.1 纯文档型SKILL.md 驱动这是最基础、生态最丰富的一类形态。核心就是一个精心编写、带有结构化 Front Matter 的SKILL.md文件。文件里写清楚这个 Skill 叫什么、描述里包含哪些触发关键词、适合处理什么任务正文就是步骤化的指导文档告诉模型先做什么再做什么中间可能附带一些代码示例和输出模板。claude code skill早期大量使用这种形态社区里很多skill仓库也是这种结构。它的特点是零依赖、跨工具、易分享。你在 Claude Code 里能用在 Cursor 里把路径配好也能用。缺点是它本身不包含可执行代码遇到需要精确计算或者调用外部 API 的场景光靠自然语言描述容易出偏差。我写过不少这种文档型 Skill有一个心得Front Matter 里的 description 字段极其重要。模型什么时候加载你的 Skill全靠 description 与用户输入语义匹配。很多人写的 description 又长又空比如“帮助用户处理各种与项目管理相关的事情”模型根本判断不出来什么时候该用它。要精炼、有代表性至少要包含任务类型关键词和核心动作关键词让模型一眼就能判断“哦这单活归它管”。2.2 脚本型LLM 代码的完整闭环第二种形态是目前效率最高的Skill 文件夹里除了SKILL.md还带了可执行脚本比如 Python、Shell、JavaScript。模型按 SKILL.md 的步骤需要精确处理数据时直接调用脚本用代码的确定性来弥补大模型计算的不可靠性。举个最典型的例子论文写作辅助场景。你让模型帮你整理参考文献格式模型靠“心算”去格式化引用条目必然出错。但如果你的 Skill 里有一个 bibtex 格式转换脚本和一个文献去重脚本模型就会调用脚本完成——这时的准确率是 100%而不是 90%。这也是“codex 用的检索文献 skill”、“科研 skill”这类需求突然变多的原因搞科研的人不需要 AI 给他泛泛而谈他需要 AI 能跑脚本去解析 PDF、去 query 学术 API、去生成格式合规的 bib 条目。脚本型 Skill 对写作者的要求也上了一个台阶。你至少要有基本的编程能力同时要考虑脚本的输入输出约定。我自己写这类 Skill 时会在 SKILL.md 里明确规定脚本的 CLI 参数格式、stdin/stdout 的数据格式、错误码含义。模型读文档然后按文档去调用脚本——文档写得越精确脚本调用成功率越高。2.3 配置型把多个外部命令编排成 Agent 能力第三种形态是配置编排型。它不是一个独立脚本而是对一组已有命令行工具的编排方案。比如你想做一个“前端代码审查 Skill”里面不一定要自己写审查逻辑而是配置好调用eslint、typescript --noEmit、npm audit这些命令的规则告诉模型“先跑哪条命令收集错误、再按什么优先级修复、哪些 error 可以忽略、哪些必须处理。”这种形态特别适合工程化场景。codex的很多 skill 就走这个路线模型先把代码库扫一遍根据 Skill 里预设的规则调用对应工具最后按模板输出审查报告。它的核心价值在于沉淀工程规范。团队里已有的代码规范、命令习惯全部可以固化成一个 Skill新成员上手就是“团队级”的代码习惯。写这种 Skill 有一个细节要注意命令的超时设置和输出量控制。模型调用 shell 命令时如果脚本输出几千行日志上下文窗口瞬间就被打爆。我一般会在 SKILL.md 里明确规定只输出 error 级别及以上日志成功时输出简洁的状态信息并且给每条命令加上时间限制和输出截断策略。2.4 混合工作站型把 Skill 体系化当单文件 Skill 无法满足复杂任务时就该上混合工作站型了。这类形态不再是一个 Skill而是一个 Skill 体系里面包含多个文档、多个脚本、互相调用的规则约定甚至自带一套简单的配置文件。以“workbuddy skill”这种在社区流传的结构为例它实际上是被设计成一套完整的工作流先通过一个识别模块判断用户当前在做什么项目再通过不同的子模块调用对应的处理逻辑。整个体系里有负责感知的脚本、有负责执行的主流程、有负责格式化输出的模板。这种 Skill 的价值在于它能跨子任务协作而不是单点响应。这种形态也是我一直觉得最像“数字分身”的东西。你把一个完整业务场景里可能涉及的所有细碎操作拆成模块装进 Skill 体系里模型面对任务时像流水线一样按序执行中间不需要你频繁纠正。代价是编写和维护成本极高适合频率极高、流程极稳定的业务场景。2.5 生态型与社区沉淀Skill 的第三种力量最后一种形态严格来说不算技术形态但必须提生态型。现在各家的 Skill 已经形成了大量社区仓库比如 GitHub 上的 skill 集合仓库、各大模型工具的 plugin 市场。你能找到一个汇总了几百个 Skill 的仓库里面有“vue-best-practices skill”、“会议纪要 Skill”、“PPT 设计 Skill”、“AI 视频 Skill”等等。这些社区资源的共同特征是有人踩过坑、把经验固化成文档、免费分享出来。我一贯建议大家想学 Skill 编写先去扒优秀的开源 Skill尤其是那些 Star 高的。你在 GitHub 上搜awesome-claude-skills或者对应工具社区的 Skill 榜单能刷到很多高质量案例。把它们下载下来拆开看结构、看用词、看脚本组织比自己凭空憋一篇 SKILL.md 要快得多。3. 什么样的 Skill 才算好我从多个真实项目里提炼的六条标准网上搜“什么样的 Skill 叫做好 Skill”能搜到很多高赞回答但大多数都是空对空。我结合自己写过的十几个 Skill 和用过的几十个第三方 Skill总结出六条可以量化的标准拿这几条去卡基本不会走眼。3.1 命名与触发描述偏了Skill 就废了这是最容易被忽视、也是最要命的一点。你的 Skill 写得再好模型在合适的场景调用不出来等于零。很多人的 SKILL.md 里的 description 写得像产品介绍而模型判断 Skill 是否匹配用户意图靠的就是这段描述和用户输入的语义重叠度。好的 Trigger 描述应该像搜索引擎的标题核心关键词前置、动作语义明确、附带典型使用场景。比如一个会议纪要 Skill 的描述我建议写成“整理会议纪要、会议记录、meeting notes支持从音频/视频转写、按模板输出待办事项与决策摘要”而不是“本技能用于帮助用户高效地处理会议相关内容提升办公效率”。你体会一下这两种描述在向量匹配时的差距。核心关键词能不能自然落在描述里直接决定了模型“想不想得起来”用它。3.2 结构完整性一份合格的 SKILL.md 长什么样一个结构完整的 Skill至少要包含四个部分一是名称和描述区也就是 Front Matter 或头部元信息二是“何时使用”区说明这个 Skill 的适用输入条件和不适用的场景边界三是“执行步骤区”按顺序明确列出处理流程四是“输出格式区”定义最终产物结构比如 JSON 格式、模板格式或动作清单。社区里有个经典误区把 SKILL.md 写成一篇文章大段大段描述背景和原理就是不给操作步骤。我说句难听的模型读它读得再懂它也不知道第一步该干嘛。你在写每一个步骤时要想的是如果这个模型的上下文从零开始完全靠这段文字它能不能准确执行能把这个问题回答好你的 SKILL.md 就是合格的。3.3 能力边界的显式声明知道不做什么比知道做什么更重要好 Skill 必须显式说明“我不做什么”。这个理念在 Agent 工程里叫 Scope Limitation用在 Skill 上同样成立。你的会议纪要 Skill要不要负责自动发邮件不需要那就别在文档里提“可以帮你发送”。因为模型看到任何一句相关描述都可能画蛇添足地往那个方向展开。我自己写 Skill 有一条铁律在“使用限制”一节里明确写出三种以上不该用本 Skill 的场景。比如论文 Skill 里写“本 Skill 不负责生成实验数据不负责代写结论不提供学术不端相关的协助”。这不仅仅是为了避免模型乱来也是安全合规的底线要求。边界清晰模型的自由度虽然降低了但产出质量反而老老实实地提高了。3.4 幂等性与容错好 Skill 能经得起重复执行第三个标准是幂等性。什么叫幂等同一个输入你让 Skill 跑一次和跑十次结果应该基本一致而且不会对项目产生破坏性影响。很多人的 Skill 里写着“把代码格式化并保存”听起来没毛病。但如果模型执行了两次格式化而你的脚本没有做幂等保护第二次跑可能会在文件头部追加重复的注释头甚至把已有配置覆盖掉。怎么保证幂等两个手段一是在脚本里做前置检查如果文件已经处理过就直接跳过二是在 SKILL.md 里明确声明“本 Skill 不得重复执行格式化操作除非文件内容被修改过”。很多看起来“玄学”的操作问题其实根源就在幂等性上。3.5 上下文经济性会省 token 的 Skill 才是真高级Skill 本身要占用模型的上下文窗口而且 Skill 被调用时还会产生输出上下文。一个高质量的 Skill必须有极强的上下文经济性。也就是说加载它不会浪费太多窗口它产生的结果也不会把上下文撑爆。这在长文本任务里尤其重要。比如整理一个 10 万字的文档如果 Skill 的脚本把全文都读了再输出摘要窗口可能直接溢出。好做法是脚本先对文本做预处理、分块、关键句抽取只把浓缩后的中间结果交给模型加工。你用 SKILL.md 实际上是在给模型设计一套“上下文预算”哪里该精读、哪里该略读、哪里不读写得清清楚楚。3.6 可维护性Skill 也是代码要有版本意识最后一个标准有点进阶好 Skill 是可以被维护和演化的。Skill 不是写完就完事的静态文档它会随着你业务的变化而变化。如果你的 SKILL.md 是一坨没有分节、没有注释、没有变更记录的文本三个月后你自己都看不懂当初写了什么更别提让同事接手。我现在的习惯是每个 Skill 文件夹里放一个CHANGELOG.md每次修改都记录“改了什么、为什么改”。写脚本的也用统一的风格和注释规范。Skill 和代码没有区别技术债一样会累积。社区里的热门 Skill 仓库为什么经久不衰就是因为维护者有版本意识。评估维度合格线上优秀水平触发描述包含任务关键词关键词前置 明确场景边界结构组织有步骤列表有决策分支 限制边界 输出模板可执行性模型能按文档执行模型能脱离提示自行全流程执行幂等性重复执行不报错重复执行结果一致且无副作用上下文开销无明显浪费主动分块、压缩中间产物可维护性有文档说明有 CHANGELOG 脚本注释完善4. 从零手写一个 Skill 的完整实操以“会议纪要 Skill”为例讲了这么多理论我们来动手写一个。我以最实用、几乎人人都需要的会议纪要 Skill 为例把从设计到挂载到主流工具的全流程走一遍。这个 Skill 的定位是支持线下会议录音转写与线上会议文本输入按照统一模板输出结构化纪要。你将看到 SKILL.md 怎么设计、Python 脚本怎么写、参数怎么约定以及最终怎么装进 Claude Code、Codex、Cursor 这些工具。4.1 目录设计与 SKILL.md 编写先看目录结构。我的建议是把一个 Skill 当成一个独立的微服务文件夹来组织里面至少包含SKILL.md、scripts/、assets/可选、CHANGELOG.md推荐。对于会议纪要这个场景初始结构如下meeting-minutes-skill/ ├── SKILL.md ├── scripts/ │ ├── transcribe.py │ └── format_minutes.py └── CHANGELOG.md最核心的SKILL.md文件我把它写成下面这样你直接参考着改就行--- name: meeting-minutes description: 整理会议纪要、会议记录、meeting notes。支持对会议文本或转写稿进行结构化整理输出待办事项、关键决策、风险点。 --- # Meeting Minutes Skill ## 适用场景 - 用户提供会议文字记录直接粘贴、上传 txt/md 文件 - 用户提供音频/视频文件路径需要先转写再整理 - 用户需要生成周报/项目同步所需的会议纪要附件 ## 不适用场景 - 不要用于代写会议邀请函 - 不要用于生成虚假会议记录 - 不要用于处理超出文本范围的信息 ## 执行步骤 1. 获取会议原始素材。如果输入是音频/视频文件调用 scripts/transcribe.py使用本地 Whisper 模型转写如果无本地模型则提示用户安装。 2. 将原始文本按议程、发言人、时间线分段删除寒暄与无信息量内容。 3. 调用 scripts/format_minutes.py传入分段后的 JSON 数据输出标准模板纪要。 4. 根据用户需要进一步生成待办任务列表格式为 负责人 | 事项 | 截止时间 | 状态。 5. 输出纪要时必须在文末附注“由 AI 辅助整理请核对关键决策与待办”。 ## 输出格式 输出 Markdown必含以下大节会议主题、时间地点、参会人、会议目标、讨论摘要、关键决策、待办事项、风险与遗留问题。你拿这个模板改的时候注意description 要写满关键词和场景执行步骤要具体到“够模型直接执行”的程度不适用场景一定要写这是一道安全阀。我给工作室的同事培训时反复强调SKILL.md 是写给模型的代码不是写给人的散文。每一句话都要让模型读了之后能产生一个明确动作而不是增强它的困惑。4.2 配套脚本转写与格式化光有 SKILL.md 还不够脚本型 Skill 的精髓在于脚本。会议纪要场景下我把工作拆成两个脚本一个负责“把语音变成文本”一个负责“把杂乱的文本变成结构化数据”。转写脚本transcribe.py核心逻辑是调用 faster-whisper 进行本地转写。我用 faster-whisper 而不是 openai-whisper是因为它在 CPU 上的速度要快不少且对显存要求更低。代码骨架如下import sys from faster_whisper import WhisperModel def transcribe(audio_path: str, output_txt_path: str) - None: model WhisperModel(small, devicecpu, compute_typeint8) segments, _ model.transcribe(audio_path, languagezh) with open(output_txt_path, w, encodingutf-8) as f: for seg in segments: start round(seg.start, 2) end round(seg.end, 2) text seg.text.strip() f.write(f[{start:.2f}-{end:.2f}] {text}\n) if __name__ __main__: transcribe(sys.argv[1], sys.argv[2])我实测下来small模型对中文普通话的识别效果够用如果你有 GPU 且追求更高准确率可以换成medium。这里有个小细节我把转写结果带上了时间戳格式是[起始秒-结束秒] 文本。为什么要带时间戳因为后续做分段和发言人分离时时间戳是关键的切割依据。模型拿到带时间戳的文本可以根据停顿间隙推断说话人切换准确率远高于纯文本。格式化脚本format_minutes.py本质上是个模板渲染器把读取到的分段 JSON 渲染成标准 Markdown 纪要。关键点在于脚本只做“渲染”这一件事语义理解交给大模型脚本的确定性保证输出结构不错乱。import json import sys from datetime import datetime TEMPLATE # 会议纪要 - 会议主题{topic} - 时间{time} - 参会人{attendees} ## 会议目标 {goals} ## 讨论摘要 {summary} ## 关键决策 {decisions} ## 待办事项 | 负责人 | 事项 | 截止时间 | 状态 | |--------|------|----------|------| {todos} ## 风险与遗留问题 {risks} def render_minutes(data: dict) - str: data[todos] \n.join( f| {item[owner]} | {item[task]} | {item[deadline]} | {item[status]} | for item in data.get(todos, []) ) data[time] data.get(time) or datetime.now().strftime(%Y-%m-%d %H:%M) return TEMPLATE.format(**data) if __name__ __main__: input_path sys.argv[1] output_path sys.argv[2] with open(input_path, r, encodingutf-8) as f: payload json.load(f) result render_minutes(payload) with open(output_path, w, encodingutf-8) as f: f.write(result)抽身来看这两个脚本其实是把整条流水线里最机械的部分交给代码把最需要语义理解的部分分段、提炼要点、识别决策交给模型在 SKILL.md 指导下完成。这种“代码管精度、模型管理解”的协作模式是我认为当下 Skill 编写最合理的分工方案。4.3 参数校验与多轮对话衔接很多新手写 Skill 时有一个致命失误SKILL.md 里要求模型调用脚本但既不给参数说明也不给异常分支。实际跑起来模型要么传错参数要么脚本报错后不知道怎么办。我建议在 SKILL.md 中单开一节“脚本调用约定”把参数长度、格式、错误处理全部写死。以上面的两个脚本为例我会在这一节中写明transcribe.py接收两个位置参数依次为音频路径和输出文本路径注意音频路径必须是绝对路径且文件需存在否则脚本退出码为 1。format_minutes.py接收两个位置参数依次为输入 JSON 路径和输出 Markdown 路径JSON 必须包含 topic、attendees、summary 等顶层字段。任何脚本执行失败时不要强行忽略错误先检查路径和依赖并向用户反馈失败原因。同时要考虑多轮对话的衔接。用户可能第一轮丢过来一段音频第二轮说“顺便把待办事项发到群里”第三轮说“再帮我整理一版英文摘要”。这要求 SKILL.md 的执行步骤不能是僵化的单次流程还要包含“当前谈话状态”的处理。我在实际项目里的做法是每次执行完把中间产物转写稿、结构化数据保存到工作目录并在 SKILL.md 中写明“如果用户后续要求追加操作优先读取最近一次生成的中间文件而不是重新转写”。这样看起来只是一句话实际上帮模型省掉了大量重复计算也让多轮交互变得流畅。4.4 在不同工具中挂载运行Skill 写好了最后一步是挂载到具体工具里。不同工具对 Skill 的加载方式不太一样我把自己用过的几个主流方案的配置方式列一下。Claude Code 中最简单的方式是把 Skill 文件夹放到项目的.claude/skills/目录下比如你的项目根目录是/data/my-project就把meeting-minutes-skill整个文件夹放到/data/my-project/.claude/skills/。它会在每次会话中自动读取 Skill 索引模型发现用户输入满足 description 的意图时就会主动加载对应目录下的 SKILL.md。Codex 里更灵活一点。codex支持通过codex skill add命令注册外部 Skill注册时指定路径它会把 Skill 目录软链接到全局配置目录。也可以手动编辑配置文件在skills字段里按顺序列出所有需要启用的 Skill 绝对路径地址每个 Skill 用一组 name、path、description 字段描述。Cursor 中打开.cursor/skills/目录把 Skill 文件夹放进去即可。Cursor 的模型在生成回复时会参考这些 Skill 文件。如果你的 Skill 涉及脚本调用记得确认 Cursor 有权限执行本地命令否则脚本永远跑不起来。我在实践中最常用的是 Claude Code 搭配claude code skill体系。原因是它对 SKILL.md 的读取最规范触发机制相对成熟。但你要注意各大工具对“Skill”规范的支持程度在快速迭代今天能用的字段明天可能就变了。所以这里给一个通用建议优先把 SKILL.md 写到“自包含”的程度即使换个工具这个文件本身依然是一份高质量提示文档。工具在变方法论不变。5. 常见问题与避坑实录给 Skill 路上的新手踩坑预警最后一部分我把这两个月里在技术社区被高频询问的 Skill 问题进行汇总每一条都对应一个真实踩坑场景。你可以直接拿这份清单当作排查手册来用。5.1 Skill 安装了但模型从不调用怎么排查这个问题出现的频率极高。排查顺序要按概率排序第一步检查description等头部描述里是否包含用户可能输入的同义关键词如果描述太窄比如用户说“帮我总结一下开会内容”而 description 里只有“会议纪要”可能匹配不上第二步检查 Skill 目录位置是否放在工具指定的默认加载路径下很多人把文件夹放错了层级工具根本没读到第三步看有没有缓存部分工具会缓存 Skill 索引修改 SKILL.md 后需要重启会话或者清缓存才生效。5.2 脚本能跑但模型老是不调用怎么办这通常不是模型笨而是你的“脚本调用约定”写得不够显眼。SKILL.md 的执行步骤里要明确使用命令格式最好把完整的命令行写出来比如“执行python3 scripts/format_minutes.py input.json output.md”。不要只写“调用脚本格式化输出”这种模糊描述模型在模糊指令下的行为方差极大。脚本调用要像 API 文档一样给出明确的 request 格式和 response 格式模型才愿意去碰它。5.3 上下文爆炸Skill 产生大量冗余输出我见过不少 Skill 脚本喜欢打印中间状态、debug 日志模型一旦调用这些脚本几百行输出全灌进上下文等真正需要模型思考的时候窗口已经所剩无几。解决方案只能是脚本层面控制输出量把默认输出设计成“简洁模式”如果需要诊断再通过环境变量打开 verbose 开关。我写脚本时的默认原则成功时零输出失败时输出三行以内的错误摘要和排查建议。让上下文留给语义推理而不是日志灌水。5.4 安全边界Skill 能做危险操作怎么办Skill 一旦可以调用本地脚本就有执行任意命令的能力这必须设置边界。至少做到三点第一SKILL.md 的编写与使用必须遵循内容安全要求绝不用于任何涉及违规或敏感信息的任务第二脚本对外部传入的路径、URL 参数做校验禁止拼接 shell 命令优先使用子进程列表形式调用命令避免注入风险第三如果 Skill 需要联网访问或执行文件系统写操作应该在文档中显式声明并在执行前反馈给用户确认。你在构建自己的 Skill 时把自己当成一位保守的系统管理员默认不支持一切不确定行为这样用着才放心。5.5 怎么判断一个 Skill 质量好不好不用纠结评分直接拿任务测试。用同一个标准任务去测试两个 Skill对比它们的输出质量、耗时、上下文消耗。输出质量看结构是否完整、是否有幻觉信息耗时长且上下文消耗大的 Skill即使结果好看也要警惕长尾维护成本太高。不要被“功能多”迷惑Skill 的功能广度与输出稳定性往往是反比关系。真正好用的 Skill 大多不是“什么都行”的而是“一件事情做到九十分”的。写到这里想最后分享一个我的个人习惯我并不会为了写 Skill 而写 Skill每一次创建之前都会先问自己这个任务我一个月要做几次频率低于三次就先不写直接用对话硬怼模型。Skill 的本质是投资你投入时间写它回报是之后每次调用的稳定性和效率提升。如果任务本身就稀少投资回报率是负的。等到你准备动笔时记住五件事为模型而写、为场景而写、为边界而写、为上下文而写、为维护而写。够你在这条路上少踩一半坑了。
