1. 从“skills”这个热词说起它到底是什么为什么突然火了如果你最近在开发者社区、技术群或者视频平台上频繁刷到“skills”这个词大概率不是指传统意义上的“技能”泛称而是特指围绕 Claude 生态、尤其是 Claude Code 和 Agent Skills 体系衍生出来的一套能力扩展机制。简单说skills 就是让 AI 助手从“能聊天”变成“能干活”的关键拼图。它不是一个孤立的工具而是一套约定用结构化的文件核心是 SKILL.md告诉模型在特定场景下该调用什么工具、遵循什么流程、输出什么格式。你可以把它理解成给 AI 写的一份“岗位操作手册”只不过这份手册是机器可读、可组合、可复用的。我第一次接触这个概念是在一个前端自动化重构的项目里。当时团队想让 Claude Code 帮忙批量处理组件迁移但直接对话总是“跑偏”——它不知道我们内部的目录规范、命名习惯和构建流程。后来有人丢过来一个 skills 目录里面几个 SKILL.md 文件配置好之后同样的指令输出质量直接上了一个台阶。那一刻我才意识到skills 解决的不是模型能力问题而是“上下文对齐”问题。模型再强不知道你的项目约定也只能靠猜而 skills 就是把你的约定显式地、结构化地喂给它。从热搜词也能看出端倪“Claude”“Agent Skills”“SKILL.md”“Claude Code”“skills开发”“ai skills怎么写”“常用skills”“数学建模skills推荐”“前端开发skills”“superpower skills”……这些词覆盖了从底层机制到具体应用场景的完整链条。有人关心怎么装有人关心怎么写有人关心哪些场景好用还有人关心怎么清理。这说明 skills 已经从一个技术概念快速演变成了一个有实际生产力价值的工具生态。不管你是前端、后端、数据科学、数学建模还是内容创作只要你的工作流里有重复性的、有明确规则的、需要 AI 辅助的任务skills 都值得你花时间研究。这篇文章面向的是所有想搞懂 skills 是什么、怎么用、怎么自己写、怎么避坑的人。我会从设计思路、核心机制、实操步骤、常见问题四个维度展开尽量把每个“为什么”讲清楚把每个“怎么做”落到可复现的程度。你不需要是 AI 专家但最好有一点命令行基础或者至少愿意动手试。如果你完全零基础也没关系我会在关键步骤上补充背景知识确保你能跟上。2. skills 的整体设计与核心思路拆解2.1 为什么是 SKILL.md而不是插件或 API很多人第一次看到 skills 的形态会有点意外不就是一堆 Markdown 文件吗这也能叫“技能”但恰恰是这种“低技术含量”的载体成就了它的高扩展性。SKILL.md 的本质是一份声明式的指令集它不写复杂代码而是用自然语言加少量结构化标记描述“在什么条件下做什么事”。这种设计有几个明显优势。第一门槛极低。你不需要会写 Python 或 JavaScript只要能把流程说清楚就能写一个 skill。我见过一个做电商运营的朋友她用 SKILL.md 写了一个“竞品价格监控报告生成”的 skill里面就是几步读取指定表格、按品类分组、计算价格波动、输出 Markdown 报告。全程没有一行代码但 Claude Code 执行起来非常稳定。第二可组合性强。一个 skill 可以调用另一个 skill就像函数调用一样。比如你有一个“读取数据库”的 skill一个“数据清洗”的 skill一个“生成图表”的 skill它们可以串成一条流水线。这种组合能力让 skills 从“单点工具”变成了“工作流引擎”。第三版本管理和协作友好。Markdown 文件天然适合 Git 管理谁改了哪条规则、什么时候改的、为什么改一目了然。团队里每个人都可以贡献自己的 skill慢慢沉淀成一套组织级的“AI 操作手册”。相比之下插件或 API 虽然能力更强但开发和维护成本高而且往往绑定特定平台。SKILL.md 这种“轻协议”反而更容易跨工具、跨场景迁移。这也是为什么热搜里会出现“opencode skills”“codex nature skills”这样的词——不同工具都在尝试兼容或借鉴这套思路。2.2 Agent Skills 的运行时逻辑模型怎么“读懂”你的意图理解 skills 的关键是搞清楚模型在执行时到底发生了什么。当你给 Claude Code 一个任务并指定使用某个 skill 时系统大致会经历这几个阶段加载阶段读取 SKILL.md 文件解析其中的元数据名称、描述、触发条件和指令内容。匹配阶段根据当前任务和上下文判断哪些 skill 被激活。有些 skill 是显式调用的有些是根据关键词自动触发的。注入阶段把激活的 skill 内容作为额外上下文拼接到模型的提示词中。执行阶段模型按照 skill 中定义的步骤、工具和输出格式生成响应或调用外部工具。反馈阶段如果 skill 中定义了校验规则模型会自我检查输出是否符合要求不符合则重试或报错。这个流程里最容易被忽视的是匹配阶段。很多新手写完 skill 后发现“不生效”往往是因为触发条件写得太模糊或者和其他 skill 冲突了。比如你写了一个“生成周报”的 skill触发词是“报告”但系统里已经有一个“生成测试报告”的 skill 也匹配“报告”模型就不知道该用哪个。解决办法是在 SKILL.md 的 description 里写清楚适用场景和排除条件越具体越好。另一个关键是注入阶段的上下文长度限制。skill 内容不是越多越好如果每个 skill 都写几千字几个叠加起来就会挤占模型的实际任务上下文导致“记住了规则但忘了任务”。所以写 skill 要克制只写必要的规则把详细说明放到外部文档里用链接引用。这也是为什么很多成熟的 skill 看起来都很短但背后有一整套文档体系。2.3 从“对话”到“技能”AI 使用范式的转变Skills 的出现其实标志着我们和 AI 协作的方式正在从“对话式”转向“技能式”。对话式是你一句我一句靠即时反馈调整技能式是你提前把规则和流程固化下来AI 按章办事。这两种模式没有优劣之分但适用场景不同。对话式适合探索性任务比如“帮我想几个产品名字”“这段代码为什么报错”。技能式适合重复性任务比如“每周一自动生成销售报表”“把所有组件的 class 命名从驼峰改成短横线”。技能式的核心价值是把人的经验沉淀成可复用的资产而不是每次都要重新解释一遍。我自己的体会是当一个任务你重复做了三次以上就应该考虑把它写成 skill。比如我经常需要把会议记录整理成结构化纪要以前每次都要给 Claude 发一大段提示词后来写了一个“会议纪要生成”的 skill现在只需要说“用会议纪要 skill 处理这个文件”输出格式稳定省心很多。热搜里“数学建模skills推荐”“华为杯建模比赛好用的codex skills”“ai漫剧常用skills”这些词也印证了这一点不同领域的人都在把自己的专业流程 skill 化。数学建模有固定的论文结构、代码规范、图表要求写成 skill 后AI 就能按照竞赛标准输出AI 漫剧有分镜、角色设定、台词风格写成 skill 后生成的内容一致性会大幅提升。3. 核心细节解析与实操要点3.1 SKILL.md 的文件结构与字段说明一个标准的 SKILL.md 通常包含以下几个部分。我用一个“前端组件重构”的 skill 作为例子来说明。--- name: frontend-component-refactor description: 用于将 React 类组件重构为函数组件并统一使用项目内部的 hooks 规范。适用于 src/components 目录下的 .jsx 文件。 version: 1.0.0 author: your-name tags: [frontend, react, refactor] --- # 前端组件重构 Skill ## 触发条件 当用户要求重构 React 类组件或提到“类组件转函数组件”“hooks 重构”时激活。 ## 前置检查 1. 确认目标文件是 .jsx 或 .tsx 格式。 2. 确认文件内包含 class 组件定义。 3. 检查项目根目录是否有 .eslintrc 和 prettier 配置。 ## 执行步骤 1. 读取目标文件内容。 2. 识别类组件中的 state、生命周期方法和自定义方法。 3. 将 state 转换为 useState生命周期转换为 useEffect。 4. 自定义方法用 useCallback 包裹如果作为 props 传递。 5. 保持原有的 export 方式和文件路径不变。 6. 按照项目 prettier 配置格式化输出。 ## 输出要求 - 输出完整的重构后代码。 - 在代码上方用注释说明主要变更点。 - 如果遇到无法自动转换的逻辑如复杂的 shouldComponentUpdate在代码下方用 TODO 标注并说明原因。 ## 禁止事项 - 不要修改组件的对外接口props 名称和类型。 - 不要删除任何现有的测试文件。 - 不要引入新的第三方依赖。这个结构里frontmatter--- 包裹的部分是元数据用于系统识别和匹配正文是指令内容分为触发条件、前置检查、执行步骤、输出要求、禁止事项几个模块。这种分法不是强制的但实践证明它能让模型更容易理解优先级和边界。有几个字段值得特别说明。description是最重要的它决定了 skill 什么时候被激活。写的时候要包含动作、对象、场景三个要素。比如“用于将 React 类组件重构为函数组件”就比“前端重构”好得多。tags用于分类和搜索方便在 skill 库多了之后管理。version在团队协作时很有用可以追踪变更。3.2 触发条件怎么写才不会“误触发”或“不触发”触发条件是新手最容易踩坑的地方。写得太宽什么任务都往里套输出质量下降写得太窄该用的时候不激活等于白写。我的经验是遵循**“三具体一排除”**原则。三具体是指具体动作、具体对象、具体场景。比如“当用户要求生成周报且输入数据包含本周的 Git 提交记录和 Jira 任务列表时激活”。这里动作是“生成周报”对象是“Git 提交记录和 Jira 任务列表”场景是“本周”。一排除是指明确写出什么情况下不激活。比如“如果用户只是询问周报模板格式不激活此 skill”。另外触发词不要用太通用的词。像“报告”“分析”“生成”这种词几乎每个任务都会出现写了等于没写。更好的做法是用领域特定的组合词比如“竞品价格波动报告”“组件依赖关系分析”“用户留存漏斗生成”。这些词组合起来误触发的概率就低很多。还有一个技巧是用否定条件做隔离。如果你有两个 skill 都涉及“代码审查”一个针对前端一个针对后端可以在前端的 skill 里写“不适用于 .py、.java、.go 文件”在后端的 skill 里写“不适用于 .jsx、.tsx、.vue 文件”。这样模型在匹配时就能根据文件类型做出判断。3.3 执行步骤的粒度控制太粗会跑偏太细会死板执行步骤是 skill 的核心。写得太粗比如“重构代码”模型自由发挥的空间太大结果不可控写得太细比如“第 3 行第 5 列加一个逗号”又失去了 AI 的灵活性而且维护成本极高。合适的粒度是“逻辑步骤”级别每一步对应一个明确的子任务但具体实现留给模型。举个例子一个“数据清洗”的 skill执行步骤可以这样写读取原始数据文件识别列名和数据类型。检查缺失值数值列用中位数填充分类列用众数填充。检查异常值超出 3 倍标准差的值标记为异常但不删除单独输出异常清单。检查重复行完全重复的行去重保留第一条。输出清洗后的数据和清洗报告。这五步每一步都是一个逻辑单元模型知道要做什么但具体怎么识别列名、怎么计算中位数它自己会处理。这样既保证了流程可控又保留了灵活性。如果某个步骤特别关键容易出错可以加校验子步骤。比如“第 2 步完成后检查填充后的缺失值比例是否低于 5%如果高于 5%停止并报告”。这种自检机制能大幅降低错误率。3.4 输出格式的约束让结果可预测、可集成输出格式的约束经常被忽略但它直接决定了 skill 能不能融入自动化流程。如果你只是自己看Markdown 就够了但如果输出要给下游程序消费就必须用结构化格式比如 JSON、YAML 或 CSV。我建议在 skill 里明确写出输出模板。比如## 输出格式 请严格按照以下 JSON 结构输出 { summary: 一句话总结, issues: [ {file: 文件路径, line: 行号, severity: high/medium/low, message: 问题描述} ], stats: {total_files: 数量, total_issues: 数量} }有了这个模板模型每次输出都会对齐字段名和层级下游程序直接解析就行。如果没有模板模型可能这次用issues下次用problems再下次用findings集成成本会很高。另外对于文本类输出可以约定标题层级、列表符号、代码块语言等细节。比如“所有代码块必须标注语言类型”“二级标题用 ##三级标题用 ###”“列表统一用短横线”。这些细节看起来琐碎但能显著提升输出的一致性和可读性。4. 实操过程与核心环节实现4.1 环境准备Claude Code 的安装与基础配置在写 skill 之前你得先有一个能运行 skill 的环境。目前最主流的是 Claude Code它是一个命令行工具可以在终端里直接和 Claude 交互并加载本地的 skill 文件。安装过程不复杂但有几个坑需要注意。首先Claude Code 对操作系统有要求。Windows 用户可能会遇到“claude’s workspace requires the virtual machine platform on windows”这样的提示这是因为它的某些功能依赖虚拟化平台。解决办法是在“启用或关闭 Windows 功能”里勾选“虚拟机平台”和“适用于 Linux 的 Windows 子系统”然后重启。如果你用的是 macOS 或 Linux基本不会有这个问题。安装命令通常是通过 npm 全局安装npm install -g anthropic-ai/claude-code安装完成后在终端输入claude应该能看到欢迎信息。如果提示“无法将‘claude’项识别为 cmdlet、函数、脚本文件或可运行程序的名称”说明 npm 的全局 bin 目录没有加到系统 PATH 里。Windows 下可以用npm config get prefix找到路径然后手动加到环境变量macOS/Linux 下检查~/.bashrc或~/.zshrc里有没有export PATH$PATH:$(npm config get prefix)/bin。接下来是配置 API 访问。Claude Code 需要连接模型服务你需要准备好相应的访问凭证。具体配置方式因版本而异建议参考官方文档的“快速开始”部分。配置完成后可以用一个简单任务测试比如“列出当前目录下的文件”如果能正常响应说明环境就绪。注意如果你所在地区无法直接访问相关服务请遵守当地法律法规和平台规定选择合规的替代方案。本文不涉及任何绕过限制的方法。4.2 创建你的第一个 skill从目录结构到文件编写Claude Code 默认会在几个位置查找 skill 文件最常见的是项目根目录下的.claude/skills/文件夹或者用户主目录下的~/.claude/skills/。项目级的 skill 只对当前项目生效用户级的对所有项目生效。我建议新手先从项目级开始方便测试和修改。目录结构大概是这样your-project/ ├── .claude/ │ └── skills/ │ ├── meeting-notes/ │ │ └── SKILL.md │ └── code-review/ │ └── SKILL.md ├── src/ └── package.json每个 skill 一个文件夹文件夹名就是 skill 的标识符里面放一个 SKILL.md。文件夹名建议用短横线分隔的小写英文比如meeting-notes、code-review避免空格和特殊字符。现在我们来写一个完整的“会议纪要生成”skill。假设你的会议记录是纯文本包含发言人、时间戳和讨论内容你希望输出结构化的纪要包含议题、结论、待办事项。--- name: meeting-notes description: 将原始会议记录整理成结构化纪要包含议题、结论和待办事项。适用于包含发言人、时间戳和讨论内容的文本文件。 version: 1.0.0 tags: [productivity, meeting, notes] --- # 会议纪要生成 Skill ## 触发条件 当用户提供会议记录文本并要求“整理成纪要”“生成会议纪要”“提取待办事项”时激活。 ## 前置检查 1. 确认输入是文本格式不是音频或视频。 2. 确认文本中包含至少两个发言人的标记。 3. 如果文本超过 5000 字分段处理每段不超过 2000 字。 ## 执行步骤 1. 通读全文识别所有议题。议题通常以“讨论”“议题”“主题”等词引出。 2. 对每个议题提取讨论要点按发言人归类。 3. 识别结论性语句通常包含“决定”“同意”“确定”“结论”等词。 4. 提取待办事项通常包含“负责”“跟进”“完成”“截止”等词记录负责人和时间节点。 5. 按照输出格式整理成 Markdown。 ## 输出格式 # 会议纪要 ## 会议信息 - 时间 - 参与人 ## 议题一[议题名称] ### 讨论要点 - 发言人 A... - 发言人 B... ### 结论 - ... ## 待办事项 | 事项 | 负责人 | 截止时间 | |------|--------|----------| | ... | ... | ... | ## 禁止事项 - 不要编造原文中没有的信息。 - 不要遗漏任何待办事项。 - 如果某个议题没有明确结论写“未达成结论”不要强行总结。写完之后在 Claude Code 里输入“用会议纪要 skill 处理 meeting-2024-01-15.txt”如果配置正确它就会按照你的格式输出。第一次可能不完美根据输出结果调整 SKILL.md 里的步骤和格式迭代两三次基本就能稳定。4.3 调试与迭代怎么判断 skill 写得好不好判断一个 skill 好不好我通常看三个指标激活准确率、输出一致性、边界处理能力。激活准确率是指该激活的时候激活不该激活的时候不激活。测试方法是准备一组任务一半应该触发这个 skill一半不应该看模型的判断是否正确。如果误触发多就收紧触发条件如果不触发就放宽或换更具体的触发词。输出一致性是指同样的输入多次运行输出结构是否稳定。你可以把同一个任务跑三遍对比输出的字段名、层级、格式是否一致。如果每次都不一样说明输出格式约束不够明确需要加模板或示例。边界处理能力是指遇到异常输入时的表现。比如输入文件为空、格式完全不对、包含大量乱码skill 应该优雅地报错或提示而不是强行输出一堆垃圾。你可以在 skill 里加“异常处理”章节明确写出各种异常情况的应对方式。我自己的迭代节奏是第一版写完跑五个典型任务记录问题第二版针对问题调整再跑十个任务第三版基本稳定然后放到团队里让大家用收集反馈。一个成熟的 skill 通常需要三到五轮迭代。4.4 组合多个 skill搭建你的工作流流水线单个 skill 解决单点问题多个 skill 组合起来就能搭建完整的工作流。比如一个“周报生成”的流水线可以这样设计数据收集 skill从 Git 仓库提取本周提交记录从 Jira 提取已完成任务。数据清洗 skill去重、分类、按项目分组。周报生成 skill按照公司模板生成周报正文。格式检查 skill检查是否有遗漏项、格式是否符合规范。在 Claude Code 里你可以按顺序调用这些 skill也可以写一个“元 skill”来编排它们。元 skill 的 SKILL.md 里不写具体执行步骤而是写“依次调用 skill A、skill B、skill C如果 A 失败则停止并报告”。组合的时候要注意数据传递格式。上游 skill 的输出必须是下游 skill 能解析的格式。我建议统一用 JSON 作为中间格式因为它的结构最清晰解析最稳定。比如数据收集 skill 输出 JSON数据清洗 skill 读取 JSON 并输出新的 JSON周报生成 skill 读取 JSON 并输出 Markdown。另外组合 skill 的调试比单个 skill 麻烦因为错误可能出现在任何一个环节。我的做法是在每个环节加日志记录输入和输出的摘要。这样出问题时能快速定位是哪个 skill 的锅。5. 常见问题与排查技巧实录5.1 安装与配置类问题速查问题现象可能原因解决方法提示“无法将 claude 项识别为 cmdlet”npm 全局 bin 目录不在 PATH运行npm config get prefix把结果加到系统 PATHWindows 提示需要虚拟机平台缺少虚拟化组件在 Windows 功能里启用“虚拟机平台”和“Linux 子系统”重启安装后运行报权限错误全局安装权限不足macOS/Linux 用sudo npm install -g或配置 npm 使用用户目录连接模型服务失败凭证配置错误或网络问题检查配置文件中的凭证确认网络环境符合平台要求skill 文件不生效目录位置不对或文件名错误确认放在.claude/skills/下文件名必须是SKILL.md大写这里特别说一下文件名大小写的问题。很多新手写成skill.md或Skill.md系统识别不到。必须是全大写的SKILL.md。另外文件夹名不要用中文或空格虽然有些系统支持但容易出兼容性问题。5.2 skill 不触发或误触发的排查思路skill 不触发是最常见的问题。排查顺序建议从外到内检查文件位置确认 SKILL.md 在正确的目录下且 frontmatter 格式正确三个短横线开头和结尾。检查 description看是否包含了任务中的关键词。如果任务说“整理会议记录”你的 description 里只有“生成纪要”可能匹配不上。检查触发条件看是否写得太窄。比如你写了“仅适用于 .txt 文件”但输入是 .md 文件就不会触发。检查冲突看是否有其他 skill 的触发条件更宽泛把任务抢走了。可以临时禁用其他 skill 测试。检查模型版本不同版本的模型对 skill 的匹配逻辑可能有差异确认你的环境支持当前 skill 格式。误触发则相反通常是触发条件太宽。解决办法是加否定条件和优先级标记。比如在 description 里写“不适用于代码审查场景”或者在 frontmatter 里加priority: high让系统优先匹配更具体的 skill。5.3 输出质量不稳定的优化方法输出质量不稳定通常有三个原因指令模糊、上下文不足、模型随机性。指令模糊是最常见的。比如你写“整理数据”模型不知道你要整理成什么格式、按什么规则。改成“按日期升序排列缺失值用 0 填充输出 CSV 格式列顺序为 date, value, category”稳定性会大幅提升。上下文不足是指 skill 里没有提供足够的背景信息。比如你要求模型“按照公司规范写代码”但公司规范是什么模型不知道。解决办法是在 skill 里附上规范摘要或者用链接引用外部文档。模型随机性是指即使指令很明确模型每次输出也可能有细微差异。对于要求高度一致的任务可以在 skill 里加自检步骤让模型输出后自己检查一遍不符合格式就重试。虽然多花一点时间但稳定性会好很多。5.4 团队协作中的 skill 管理经验当团队里多人使用 skill 时管理就成了问题。我踩过的坑包括有人改了 skill 没通知导致其他人输出格式变了skill 文件散落在各个项目里找不到最新版新人不知道有哪些 skill 可用。解决办法是集中管理加版本控制。我们团队的做法是建一个独立的 Git 仓库专门放 skill每个人都可以提交 PR合并前需要至少一人 review。仓库里有一个 README 列出所有 skill 的名称、用途、维护人。每个 skill 文件夹里除了 SKILL.md还可以放一个 CHANGELOG.md 记录变更。另外定期清理不再使用的 skill 也很重要。热搜里“tibo关于清理skills的方法推荐”说明很多人遇到了 skill 堆积的问题。我的建议是每季度 review 一次把三个月内没人调用的 skill 归档或删除。保留太多 skill 不仅占用上下文还会增加误触发的概率。5.5 不同场景下的 skill 设计差异不同领域的 skill 设计重点不一样。数学建模的 skill 要强调论文结构、公式格式、图表规范前端开发的 skill 要强调代码风格、组件规范、构建流程内容创作的 skill 要强调语气、结构、关键词密度。以数学建模为例一个“竞赛论文生成”的 skill 应该包含摘要写法、问题重述格式、模型假设列表、符号说明表格、模型建立与求解步骤、灵敏度分析要求、参考文献格式。这些细节写清楚后AI 生成的论文初稿就能达到可提交的水平人工只需要润色。再以 AI 漫剧为例一个“分镜生成”的 skill 应该包含场景描述格式、角色对话风格、镜头切换规则、情绪标注方式。这些规则固化后生成的分镜一致性会很好不会出现角色性格前后矛盾的情况。6. 进阶技巧与个人实操心得6.1 用“示例驱动”提升 skill 的可靠性纯文字指令有时候不够直观加一两个示例能大幅提升模型的理解准确度。比如在“会议纪要”skill 里除了写步骤还可以加一个“输入示例”和“输出示例”。模型看到具体的样子更容易对齐格式。示例不用太长覆盖典型情况就行。如果任务有多个变体可以每个变体给一个简短示例。比如“如果会议没有明确结论输出示例为结论未达成结论建议下次会议继续讨论”。6.2 给 skill 加“自检清单”在 skill 末尾加一个自检清单让模型输出前逐项检查。比如[ ] 是否包含所有议题[ ] 每个议题是否有结论或“未达成结论”标记[ ] 待办事项是否都有负责人和截止时间[ ] 格式是否符合模板这个清单不需要模型真的“勾选”但它会引导模型在生成时关注这些点减少遗漏。我实测下来加了自检清单后输出完整度提升了大概三成。6.3 处理长文本的分段策略当输入文本很长时一次性处理容易超出上下文限制或者导致模型“忘记”前面的内容。解决办法是分段处理加汇总。在 skill 里写清楚如果输入超过 N 字按章节或每 M 字切分每段单独处理最后合并结果。切分的时候要注意不要切断完整的语义单元。比如按段落切分比按字数切分好按章节切分更好。如果文本有明确的标题层级优先按标题切分。6.4 我个人常用的几个 skill 模板最后分享几个我日常用得最多的 skill 方向你可以根据自己的需求调整。代码审查 skill检查命名规范、注释完整性、异常处理、边界条件、性能隐患。输出按严重程度分级附修复建议。文档生成 skill读取代码或配置文件自动生成 README、API 文档、部署说明。重点是保持和代码同步每次代码变更后重新生成。数据报告 skill读取 CSV 或 Excel做描述性统计生成图表和结论。适合周报、月报场景。翻译校对 skill中英互译保持术语一致检查语法和语气。适合技术文档本地化。这些 skill 都不复杂但坚持用下来能省下大量重复劳动的时间。关键是先写起来再慢慢优化不要一开始就追求完美。我第一个 skill 写得也很粗糙但用着用着就知道哪里需要改进了。提示skill 的价值在于复用不在于数量。与其写二十个半成品不如把三个常用场景的 skill 打磨到稳定可靠。
Claude Agent Skills 实战：从 SKILL.md 到工作流自动化
1. 从“skills”这个热词说起它到底是什么为什么突然火了如果你最近在开发者社区、技术群或者视频平台上频繁刷到“skills”这个词大概率不是指传统意义上的“技能”泛称而是特指围绕 Claude 生态、尤其是 Claude Code 和 Agent Skills 体系衍生出来的一套能力扩展机制。简单说skills 就是让 AI 助手从“能聊天”变成“能干活”的关键拼图。它不是一个孤立的工具而是一套约定用结构化的文件核心是 SKILL.md告诉模型在特定场景下该调用什么工具、遵循什么流程、输出什么格式。你可以把它理解成给 AI 写的一份“岗位操作手册”只不过这份手册是机器可读、可组合、可复用的。我第一次接触这个概念是在一个前端自动化重构的项目里。当时团队想让 Claude Code 帮忙批量处理组件迁移但直接对话总是“跑偏”——它不知道我们内部的目录规范、命名习惯和构建流程。后来有人丢过来一个 skills 目录里面几个 SKILL.md 文件配置好之后同样的指令输出质量直接上了一个台阶。那一刻我才意识到skills 解决的不是模型能力问题而是“上下文对齐”问题。模型再强不知道你的项目约定也只能靠猜而 skills 就是把你的约定显式地、结构化地喂给它。从热搜词也能看出端倪“Claude”“Agent Skills”“SKILL.md”“Claude Code”“skills开发”“ai skills怎么写”“常用skills”“数学建模skills推荐”“前端开发skills”“superpower skills”……这些词覆盖了从底层机制到具体应用场景的完整链条。有人关心怎么装有人关心怎么写有人关心哪些场景好用还有人关心怎么清理。这说明 skills 已经从一个技术概念快速演变成了一个有实际生产力价值的工具生态。不管你是前端、后端、数据科学、数学建模还是内容创作只要你的工作流里有重复性的、有明确规则的、需要 AI 辅助的任务skills 都值得你花时间研究。这篇文章面向的是所有想搞懂 skills 是什么、怎么用、怎么自己写、怎么避坑的人。我会从设计思路、核心机制、实操步骤、常见问题四个维度展开尽量把每个“为什么”讲清楚把每个“怎么做”落到可复现的程度。你不需要是 AI 专家但最好有一点命令行基础或者至少愿意动手试。如果你完全零基础也没关系我会在关键步骤上补充背景知识确保你能跟上。2. skills 的整体设计与核心思路拆解2.1 为什么是 SKILL.md而不是插件或 API很多人第一次看到 skills 的形态会有点意外不就是一堆 Markdown 文件吗这也能叫“技能”但恰恰是这种“低技术含量”的载体成就了它的高扩展性。SKILL.md 的本质是一份声明式的指令集它不写复杂代码而是用自然语言加少量结构化标记描述“在什么条件下做什么事”。这种设计有几个明显优势。第一门槛极低。你不需要会写 Python 或 JavaScript只要能把流程说清楚就能写一个 skill。我见过一个做电商运营的朋友她用 SKILL.md 写了一个“竞品价格监控报告生成”的 skill里面就是几步读取指定表格、按品类分组、计算价格波动、输出 Markdown 报告。全程没有一行代码但 Claude Code 执行起来非常稳定。第二可组合性强。一个 skill 可以调用另一个 skill就像函数调用一样。比如你有一个“读取数据库”的 skill一个“数据清洗”的 skill一个“生成图表”的 skill它们可以串成一条流水线。这种组合能力让 skills 从“单点工具”变成了“工作流引擎”。第三版本管理和协作友好。Markdown 文件天然适合 Git 管理谁改了哪条规则、什么时候改的、为什么改一目了然。团队里每个人都可以贡献自己的 skill慢慢沉淀成一套组织级的“AI 操作手册”。相比之下插件或 API 虽然能力更强但开发和维护成本高而且往往绑定特定平台。SKILL.md 这种“轻协议”反而更容易跨工具、跨场景迁移。这也是为什么热搜里会出现“opencode skills”“codex nature skills”这样的词——不同工具都在尝试兼容或借鉴这套思路。2.2 Agent Skills 的运行时逻辑模型怎么“读懂”你的意图理解 skills 的关键是搞清楚模型在执行时到底发生了什么。当你给 Claude Code 一个任务并指定使用某个 skill 时系统大致会经历这几个阶段加载阶段读取 SKILL.md 文件解析其中的元数据名称、描述、触发条件和指令内容。匹配阶段根据当前任务和上下文判断哪些 skill 被激活。有些 skill 是显式调用的有些是根据关键词自动触发的。注入阶段把激活的 skill 内容作为额外上下文拼接到模型的提示词中。执行阶段模型按照 skill 中定义的步骤、工具和输出格式生成响应或调用外部工具。反馈阶段如果 skill 中定义了校验规则模型会自我检查输出是否符合要求不符合则重试或报错。这个流程里最容易被忽视的是匹配阶段。很多新手写完 skill 后发现“不生效”往往是因为触发条件写得太模糊或者和其他 skill 冲突了。比如你写了一个“生成周报”的 skill触发词是“报告”但系统里已经有一个“生成测试报告”的 skill 也匹配“报告”模型就不知道该用哪个。解决办法是在 SKILL.md 的 description 里写清楚适用场景和排除条件越具体越好。另一个关键是注入阶段的上下文长度限制。skill 内容不是越多越好如果每个 skill 都写几千字几个叠加起来就会挤占模型的实际任务上下文导致“记住了规则但忘了任务”。所以写 skill 要克制只写必要的规则把详细说明放到外部文档里用链接引用。这也是为什么很多成熟的 skill 看起来都很短但背后有一整套文档体系。2.3 从“对话”到“技能”AI 使用范式的转变Skills 的出现其实标志着我们和 AI 协作的方式正在从“对话式”转向“技能式”。对话式是你一句我一句靠即时反馈调整技能式是你提前把规则和流程固化下来AI 按章办事。这两种模式没有优劣之分但适用场景不同。对话式适合探索性任务比如“帮我想几个产品名字”“这段代码为什么报错”。技能式适合重复性任务比如“每周一自动生成销售报表”“把所有组件的 class 命名从驼峰改成短横线”。技能式的核心价值是把人的经验沉淀成可复用的资产而不是每次都要重新解释一遍。我自己的体会是当一个任务你重复做了三次以上就应该考虑把它写成 skill。比如我经常需要把会议记录整理成结构化纪要以前每次都要给 Claude 发一大段提示词后来写了一个“会议纪要生成”的 skill现在只需要说“用会议纪要 skill 处理这个文件”输出格式稳定省心很多。热搜里“数学建模skills推荐”“华为杯建模比赛好用的codex skills”“ai漫剧常用skills”这些词也印证了这一点不同领域的人都在把自己的专业流程 skill 化。数学建模有固定的论文结构、代码规范、图表要求写成 skill 后AI 就能按照竞赛标准输出AI 漫剧有分镜、角色设定、台词风格写成 skill 后生成的内容一致性会大幅提升。3. 核心细节解析与实操要点3.1 SKILL.md 的文件结构与字段说明一个标准的 SKILL.md 通常包含以下几个部分。我用一个“前端组件重构”的 skill 作为例子来说明。--- name: frontend-component-refactor description: 用于将 React 类组件重构为函数组件并统一使用项目内部的 hooks 规范。适用于 src/components 目录下的 .jsx 文件。 version: 1.0.0 author: your-name tags: [frontend, react, refactor] --- # 前端组件重构 Skill ## 触发条件 当用户要求重构 React 类组件或提到“类组件转函数组件”“hooks 重构”时激活。 ## 前置检查 1. 确认目标文件是 .jsx 或 .tsx 格式。 2. 确认文件内包含 class 组件定义。 3. 检查项目根目录是否有 .eslintrc 和 prettier 配置。 ## 执行步骤 1. 读取目标文件内容。 2. 识别类组件中的 state、生命周期方法和自定义方法。 3. 将 state 转换为 useState生命周期转换为 useEffect。 4. 自定义方法用 useCallback 包裹如果作为 props 传递。 5. 保持原有的 export 方式和文件路径不变。 6. 按照项目 prettier 配置格式化输出。 ## 输出要求 - 输出完整的重构后代码。 - 在代码上方用注释说明主要变更点。 - 如果遇到无法自动转换的逻辑如复杂的 shouldComponentUpdate在代码下方用 TODO 标注并说明原因。 ## 禁止事项 - 不要修改组件的对外接口props 名称和类型。 - 不要删除任何现有的测试文件。 - 不要引入新的第三方依赖。这个结构里frontmatter--- 包裹的部分是元数据用于系统识别和匹配正文是指令内容分为触发条件、前置检查、执行步骤、输出要求、禁止事项几个模块。这种分法不是强制的但实践证明它能让模型更容易理解优先级和边界。有几个字段值得特别说明。description是最重要的它决定了 skill 什么时候被激活。写的时候要包含动作、对象、场景三个要素。比如“用于将 React 类组件重构为函数组件”就比“前端重构”好得多。tags用于分类和搜索方便在 skill 库多了之后管理。version在团队协作时很有用可以追踪变更。3.2 触发条件怎么写才不会“误触发”或“不触发”触发条件是新手最容易踩坑的地方。写得太宽什么任务都往里套输出质量下降写得太窄该用的时候不激活等于白写。我的经验是遵循**“三具体一排除”**原则。三具体是指具体动作、具体对象、具体场景。比如“当用户要求生成周报且输入数据包含本周的 Git 提交记录和 Jira 任务列表时激活”。这里动作是“生成周报”对象是“Git 提交记录和 Jira 任务列表”场景是“本周”。一排除是指明确写出什么情况下不激活。比如“如果用户只是询问周报模板格式不激活此 skill”。另外触发词不要用太通用的词。像“报告”“分析”“生成”这种词几乎每个任务都会出现写了等于没写。更好的做法是用领域特定的组合词比如“竞品价格波动报告”“组件依赖关系分析”“用户留存漏斗生成”。这些词组合起来误触发的概率就低很多。还有一个技巧是用否定条件做隔离。如果你有两个 skill 都涉及“代码审查”一个针对前端一个针对后端可以在前端的 skill 里写“不适用于 .py、.java、.go 文件”在后端的 skill 里写“不适用于 .jsx、.tsx、.vue 文件”。这样模型在匹配时就能根据文件类型做出判断。3.3 执行步骤的粒度控制太粗会跑偏太细会死板执行步骤是 skill 的核心。写得太粗比如“重构代码”模型自由发挥的空间太大结果不可控写得太细比如“第 3 行第 5 列加一个逗号”又失去了 AI 的灵活性而且维护成本极高。合适的粒度是“逻辑步骤”级别每一步对应一个明确的子任务但具体实现留给模型。举个例子一个“数据清洗”的 skill执行步骤可以这样写读取原始数据文件识别列名和数据类型。检查缺失值数值列用中位数填充分类列用众数填充。检查异常值超出 3 倍标准差的值标记为异常但不删除单独输出异常清单。检查重复行完全重复的行去重保留第一条。输出清洗后的数据和清洗报告。这五步每一步都是一个逻辑单元模型知道要做什么但具体怎么识别列名、怎么计算中位数它自己会处理。这样既保证了流程可控又保留了灵活性。如果某个步骤特别关键容易出错可以加校验子步骤。比如“第 2 步完成后检查填充后的缺失值比例是否低于 5%如果高于 5%停止并报告”。这种自检机制能大幅降低错误率。3.4 输出格式的约束让结果可预测、可集成输出格式的约束经常被忽略但它直接决定了 skill 能不能融入自动化流程。如果你只是自己看Markdown 就够了但如果输出要给下游程序消费就必须用结构化格式比如 JSON、YAML 或 CSV。我建议在 skill 里明确写出输出模板。比如## 输出格式 请严格按照以下 JSON 结构输出 { summary: 一句话总结, issues: [ {file: 文件路径, line: 行号, severity: high/medium/low, message: 问题描述} ], stats: {total_files: 数量, total_issues: 数量} }有了这个模板模型每次输出都会对齐字段名和层级下游程序直接解析就行。如果没有模板模型可能这次用issues下次用problems再下次用findings集成成本会很高。另外对于文本类输出可以约定标题层级、列表符号、代码块语言等细节。比如“所有代码块必须标注语言类型”“二级标题用 ##三级标题用 ###”“列表统一用短横线”。这些细节看起来琐碎但能显著提升输出的一致性和可读性。4. 实操过程与核心环节实现4.1 环境准备Claude Code 的安装与基础配置在写 skill 之前你得先有一个能运行 skill 的环境。目前最主流的是 Claude Code它是一个命令行工具可以在终端里直接和 Claude 交互并加载本地的 skill 文件。安装过程不复杂但有几个坑需要注意。首先Claude Code 对操作系统有要求。Windows 用户可能会遇到“claude’s workspace requires the virtual machine platform on windows”这样的提示这是因为它的某些功能依赖虚拟化平台。解决办法是在“启用或关闭 Windows 功能”里勾选“虚拟机平台”和“适用于 Linux 的 Windows 子系统”然后重启。如果你用的是 macOS 或 Linux基本不会有这个问题。安装命令通常是通过 npm 全局安装npm install -g anthropic-ai/claude-code安装完成后在终端输入claude应该能看到欢迎信息。如果提示“无法将‘claude’项识别为 cmdlet、函数、脚本文件或可运行程序的名称”说明 npm 的全局 bin 目录没有加到系统 PATH 里。Windows 下可以用npm config get prefix找到路径然后手动加到环境变量macOS/Linux 下检查~/.bashrc或~/.zshrc里有没有export PATH$PATH:$(npm config get prefix)/bin。接下来是配置 API 访问。Claude Code 需要连接模型服务你需要准备好相应的访问凭证。具体配置方式因版本而异建议参考官方文档的“快速开始”部分。配置完成后可以用一个简单任务测试比如“列出当前目录下的文件”如果能正常响应说明环境就绪。注意如果你所在地区无法直接访问相关服务请遵守当地法律法规和平台规定选择合规的替代方案。本文不涉及任何绕过限制的方法。4.2 创建你的第一个 skill从目录结构到文件编写Claude Code 默认会在几个位置查找 skill 文件最常见的是项目根目录下的.claude/skills/文件夹或者用户主目录下的~/.claude/skills/。项目级的 skill 只对当前项目生效用户级的对所有项目生效。我建议新手先从项目级开始方便测试和修改。目录结构大概是这样your-project/ ├── .claude/ │ └── skills/ │ ├── meeting-notes/ │ │ └── SKILL.md │ └── code-review/ │ └── SKILL.md ├── src/ └── package.json每个 skill 一个文件夹文件夹名就是 skill 的标识符里面放一个 SKILL.md。文件夹名建议用短横线分隔的小写英文比如meeting-notes、code-review避免空格和特殊字符。现在我们来写一个完整的“会议纪要生成”skill。假设你的会议记录是纯文本包含发言人、时间戳和讨论内容你希望输出结构化的纪要包含议题、结论、待办事项。--- name: meeting-notes description: 将原始会议记录整理成结构化纪要包含议题、结论和待办事项。适用于包含发言人、时间戳和讨论内容的文本文件。 version: 1.0.0 tags: [productivity, meeting, notes] --- # 会议纪要生成 Skill ## 触发条件 当用户提供会议记录文本并要求“整理成纪要”“生成会议纪要”“提取待办事项”时激活。 ## 前置检查 1. 确认输入是文本格式不是音频或视频。 2. 确认文本中包含至少两个发言人的标记。 3. 如果文本超过 5000 字分段处理每段不超过 2000 字。 ## 执行步骤 1. 通读全文识别所有议题。议题通常以“讨论”“议题”“主题”等词引出。 2. 对每个议题提取讨论要点按发言人归类。 3. 识别结论性语句通常包含“决定”“同意”“确定”“结论”等词。 4. 提取待办事项通常包含“负责”“跟进”“完成”“截止”等词记录负责人和时间节点。 5. 按照输出格式整理成 Markdown。 ## 输出格式 # 会议纪要 ## 会议信息 - 时间 - 参与人 ## 议题一[议题名称] ### 讨论要点 - 发言人 A... - 发言人 B... ### 结论 - ... ## 待办事项 | 事项 | 负责人 | 截止时间 | |------|--------|----------| | ... | ... | ... | ## 禁止事项 - 不要编造原文中没有的信息。 - 不要遗漏任何待办事项。 - 如果某个议题没有明确结论写“未达成结论”不要强行总结。写完之后在 Claude Code 里输入“用会议纪要 skill 处理 meeting-2024-01-15.txt”如果配置正确它就会按照你的格式输出。第一次可能不完美根据输出结果调整 SKILL.md 里的步骤和格式迭代两三次基本就能稳定。4.3 调试与迭代怎么判断 skill 写得好不好判断一个 skill 好不好我通常看三个指标激活准确率、输出一致性、边界处理能力。激活准确率是指该激活的时候激活不该激活的时候不激活。测试方法是准备一组任务一半应该触发这个 skill一半不应该看模型的判断是否正确。如果误触发多就收紧触发条件如果不触发就放宽或换更具体的触发词。输出一致性是指同样的输入多次运行输出结构是否稳定。你可以把同一个任务跑三遍对比输出的字段名、层级、格式是否一致。如果每次都不一样说明输出格式约束不够明确需要加模板或示例。边界处理能力是指遇到异常输入时的表现。比如输入文件为空、格式完全不对、包含大量乱码skill 应该优雅地报错或提示而不是强行输出一堆垃圾。你可以在 skill 里加“异常处理”章节明确写出各种异常情况的应对方式。我自己的迭代节奏是第一版写完跑五个典型任务记录问题第二版针对问题调整再跑十个任务第三版基本稳定然后放到团队里让大家用收集反馈。一个成熟的 skill 通常需要三到五轮迭代。4.4 组合多个 skill搭建你的工作流流水线单个 skill 解决单点问题多个 skill 组合起来就能搭建完整的工作流。比如一个“周报生成”的流水线可以这样设计数据收集 skill从 Git 仓库提取本周提交记录从 Jira 提取已完成任务。数据清洗 skill去重、分类、按项目分组。周报生成 skill按照公司模板生成周报正文。格式检查 skill检查是否有遗漏项、格式是否符合规范。在 Claude Code 里你可以按顺序调用这些 skill也可以写一个“元 skill”来编排它们。元 skill 的 SKILL.md 里不写具体执行步骤而是写“依次调用 skill A、skill B、skill C如果 A 失败则停止并报告”。组合的时候要注意数据传递格式。上游 skill 的输出必须是下游 skill 能解析的格式。我建议统一用 JSON 作为中间格式因为它的结构最清晰解析最稳定。比如数据收集 skill 输出 JSON数据清洗 skill 读取 JSON 并输出新的 JSON周报生成 skill 读取 JSON 并输出 Markdown。另外组合 skill 的调试比单个 skill 麻烦因为错误可能出现在任何一个环节。我的做法是在每个环节加日志记录输入和输出的摘要。这样出问题时能快速定位是哪个 skill 的锅。5. 常见问题与排查技巧实录5.1 安装与配置类问题速查问题现象可能原因解决方法提示“无法将 claude 项识别为 cmdlet”npm 全局 bin 目录不在 PATH运行npm config get prefix把结果加到系统 PATHWindows 提示需要虚拟机平台缺少虚拟化组件在 Windows 功能里启用“虚拟机平台”和“Linux 子系统”重启安装后运行报权限错误全局安装权限不足macOS/Linux 用sudo npm install -g或配置 npm 使用用户目录连接模型服务失败凭证配置错误或网络问题检查配置文件中的凭证确认网络环境符合平台要求skill 文件不生效目录位置不对或文件名错误确认放在.claude/skills/下文件名必须是SKILL.md大写这里特别说一下文件名大小写的问题。很多新手写成skill.md或Skill.md系统识别不到。必须是全大写的SKILL.md。另外文件夹名不要用中文或空格虽然有些系统支持但容易出兼容性问题。5.2 skill 不触发或误触发的排查思路skill 不触发是最常见的问题。排查顺序建议从外到内检查文件位置确认 SKILL.md 在正确的目录下且 frontmatter 格式正确三个短横线开头和结尾。检查 description看是否包含了任务中的关键词。如果任务说“整理会议记录”你的 description 里只有“生成纪要”可能匹配不上。检查触发条件看是否写得太窄。比如你写了“仅适用于 .txt 文件”但输入是 .md 文件就不会触发。检查冲突看是否有其他 skill 的触发条件更宽泛把任务抢走了。可以临时禁用其他 skill 测试。检查模型版本不同版本的模型对 skill 的匹配逻辑可能有差异确认你的环境支持当前 skill 格式。误触发则相反通常是触发条件太宽。解决办法是加否定条件和优先级标记。比如在 description 里写“不适用于代码审查场景”或者在 frontmatter 里加priority: high让系统优先匹配更具体的 skill。5.3 输出质量不稳定的优化方法输出质量不稳定通常有三个原因指令模糊、上下文不足、模型随机性。指令模糊是最常见的。比如你写“整理数据”模型不知道你要整理成什么格式、按什么规则。改成“按日期升序排列缺失值用 0 填充输出 CSV 格式列顺序为 date, value, category”稳定性会大幅提升。上下文不足是指 skill 里没有提供足够的背景信息。比如你要求模型“按照公司规范写代码”但公司规范是什么模型不知道。解决办法是在 skill 里附上规范摘要或者用链接引用外部文档。模型随机性是指即使指令很明确模型每次输出也可能有细微差异。对于要求高度一致的任务可以在 skill 里加自检步骤让模型输出后自己检查一遍不符合格式就重试。虽然多花一点时间但稳定性会好很多。5.4 团队协作中的 skill 管理经验当团队里多人使用 skill 时管理就成了问题。我踩过的坑包括有人改了 skill 没通知导致其他人输出格式变了skill 文件散落在各个项目里找不到最新版新人不知道有哪些 skill 可用。解决办法是集中管理加版本控制。我们团队的做法是建一个独立的 Git 仓库专门放 skill每个人都可以提交 PR合并前需要至少一人 review。仓库里有一个 README 列出所有 skill 的名称、用途、维护人。每个 skill 文件夹里除了 SKILL.md还可以放一个 CHANGELOG.md 记录变更。另外定期清理不再使用的 skill 也很重要。热搜里“tibo关于清理skills的方法推荐”说明很多人遇到了 skill 堆积的问题。我的建议是每季度 review 一次把三个月内没人调用的 skill 归档或删除。保留太多 skill 不仅占用上下文还会增加误触发的概率。5.5 不同场景下的 skill 设计差异不同领域的 skill 设计重点不一样。数学建模的 skill 要强调论文结构、公式格式、图表规范前端开发的 skill 要强调代码风格、组件规范、构建流程内容创作的 skill 要强调语气、结构、关键词密度。以数学建模为例一个“竞赛论文生成”的 skill 应该包含摘要写法、问题重述格式、模型假设列表、符号说明表格、模型建立与求解步骤、灵敏度分析要求、参考文献格式。这些细节写清楚后AI 生成的论文初稿就能达到可提交的水平人工只需要润色。再以 AI 漫剧为例一个“分镜生成”的 skill 应该包含场景描述格式、角色对话风格、镜头切换规则、情绪标注方式。这些规则固化后生成的分镜一致性会很好不会出现角色性格前后矛盾的情况。6. 进阶技巧与个人实操心得6.1 用“示例驱动”提升 skill 的可靠性纯文字指令有时候不够直观加一两个示例能大幅提升模型的理解准确度。比如在“会议纪要”skill 里除了写步骤还可以加一个“输入示例”和“输出示例”。模型看到具体的样子更容易对齐格式。示例不用太长覆盖典型情况就行。如果任务有多个变体可以每个变体给一个简短示例。比如“如果会议没有明确结论输出示例为结论未达成结论建议下次会议继续讨论”。6.2 给 skill 加“自检清单”在 skill 末尾加一个自检清单让模型输出前逐项检查。比如[ ] 是否包含所有议题[ ] 每个议题是否有结论或“未达成结论”标记[ ] 待办事项是否都有负责人和截止时间[ ] 格式是否符合模板这个清单不需要模型真的“勾选”但它会引导模型在生成时关注这些点减少遗漏。我实测下来加了自检清单后输出完整度提升了大概三成。6.3 处理长文本的分段策略当输入文本很长时一次性处理容易超出上下文限制或者导致模型“忘记”前面的内容。解决办法是分段处理加汇总。在 skill 里写清楚如果输入超过 N 字按章节或每 M 字切分每段单独处理最后合并结果。切分的时候要注意不要切断完整的语义单元。比如按段落切分比按字数切分好按章节切分更好。如果文本有明确的标题层级优先按标题切分。6.4 我个人常用的几个 skill 模板最后分享几个我日常用得最多的 skill 方向你可以根据自己的需求调整。代码审查 skill检查命名规范、注释完整性、异常处理、边界条件、性能隐患。输出按严重程度分级附修复建议。文档生成 skill读取代码或配置文件自动生成 README、API 文档、部署说明。重点是保持和代码同步每次代码变更后重新生成。数据报告 skill读取 CSV 或 Excel做描述性统计生成图表和结论。适合周报、月报场景。翻译校对 skill中英互译保持术语一致检查语法和语气。适合技术文档本地化。这些 skill 都不复杂但坚持用下来能省下大量重复劳动的时间。关键是先写起来再慢慢优化不要一开始就追求完美。我第一个 skill 写得也很粗糙但用着用着就知道哪里需要改进了。提示skill 的价值在于复用不在于数量。与其写二十个半成品不如把三个常用场景的 skill 打磨到稳定可靠。