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 时，系统大致会经历这几个阶段：

1. 加载阶段：读取 SKILL.md 文件，解析其中的元数据（名称、描述、触发条件）和指令内容。
2. 匹配阶段：根据当前任务和上下文，判断哪些 skill 被激活。有些 skill 是显式调用的，有些是根据关键词自动触发的。
3. 注入阶段：把激活的 skill 内容作为额外上下文，拼接到模型的提示词中。
4. 执行阶段：模型按照 skill 中定义的步骤、工具和输出格式，生成响应或调用外部工具。
5. 反馈阶段：如果 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，执行步骤可以这样写：

1. 读取原始数据文件，识别列名和数据类型。
2. 检查缺失值：数值列用中位数填充，分类列用众数填充。
3. 检查异常值：超出 3 倍标准差的值标记为异常，但不删除，单独输出异常清单。
4. 检查重复行：完全重复的行去重，保留第一条。
5. 输出清洗后的数据和清洗报告。

这五步每一步都是一个逻辑单元，模型知道要做什么，但具体怎么识别列名、怎么计算中位数，它自己会处理。这样既保证了流程可控，又保留了灵活性。

如果某个步骤特别关键，容易出错，可以加校验子步骤。比如“第 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 组合起来就能搭建完整的工作流。比如一个“周报生成”的流水线可以这样设计：

1. 数据收集 skill：从 Git 仓库提取本周提交记录，从 Jira 提取已完成任务。
2. 数据清洗 skill：去重、分类、按项目分组。
3. 周报生成 skill：按照公司模板生成周报正文。
4. 格式检查 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 安装与配置类问题速查

这里特别说一下文件名大小写的问题。很多新手写成skill.md或Skill.md，系统识别不到。必须是全大写的SKILL.md。另外，文件夹名不要用中文或空格，虽然有些系统支持，但容易出兼容性问题。

5.2 skill 不触发或误触发的排查思路

skill 不触发是最常见的问题。排查顺序建议从外到内：

1. 检查文件位置：确认 SKILL.md 在正确的目录下，且 frontmatter 格式正确（三个短横线开头和结尾）。
2. 检查 description：看是否包含了任务中的关键词。如果任务说“整理会议记录”，你的 description 里只有“生成纪要”，可能匹配不上。
3. 检查触发条件：看是否写得太窄。比如你写了“仅适用于 .txt 文件”，但输入是 .md 文件，就不会触发。
4. 检查冲突：看是否有其他 skill 的触发条件更宽泛，把任务抢走了。可以临时禁用其他 skill 测试。
5. 检查模型版本：不同版本的模型对 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 打磨到稳定可靠。