1. 从“会聊天”到“会干活”中间差的是什么大模型能跟你聊哲学、写诗、编故事这都不稀奇。但你让它帮你把一份杂乱的会议纪要整理成结构化待办清单或者把一段报错日志翻译成人话并给出修复命令它经常就开始胡言乱语了。问题出在哪儿不是模型不够聪明而是它缺少一套可复用的工作流约束。我最初接触 Claude 的时候也是把它当搜索引擎用问一句答一句。后来发现真正让 AI 从“玩具”变成“工具”的转折点是给它一套明确的技能定义——告诉它遇到什么场景该调用什么流程、输出什么格式、遵循什么规则。这就像你招了一个很聪明的实习生但他不知道你们公司的报销流程、代码规范、文档模板你得先给他一本员工手册。这次要聊的这个开源项目做的事情就是给 AI 写“员工手册”。它把 29 个中文场景下的实用技能打包成了一套可加载的技能合集覆盖了从文档处理、代码辅助、数据分析到日常办公的多个维度。每个技能本质上是一段结构化的提示词模板加上执行逻辑AI 在需要的时候自动调用对应的技能而不是每次都靠用户从零开始描述需求。这个项目适合谁如果你已经在用 Claude、ChatGPT 或者其他支持技能/插件机制的 LLM 工具但总觉得“差点意思”那这套东西能帮你把使用效率拉高一个档次。如果你还没开始用 AI 辅助工作那正好从这套技能合集入手能少走很多弯路。关键词里提到的 Claude、LLM、命令行、AI Agent基本就是这套东西的技术底座和应用场景。我花了大概两周时间把这 29 个技能逐个跑了一遍有些确实好用有些需要根据自己的业务做二次调整。下面把我踩过的坑、验证过的配置、以及实际效果还不错的使用方式完整地梳理一遍。2. 这 29 个技能到底覆盖了哪些场景2.1 技能分类与核心能力矩阵先把这个合集里的技能按功能域拆开看。我按照自己的使用频率和理解把它们分成了五大类类别典型技能解决的核心问题文档处理会议纪要整理、合同条款提取、长文摘要非结构化文本转结构化输出代码辅助代码审查、报错诊断、单元测试生成降低调试和重构的时间成本数据分析CSV 解析、趋势描述、异常值标注让非数据岗也能快速看懂数据内容创作标题生成、文案润色、多平台适配改写批量产出可用的内容初稿日常办公邮件起草、日程规划、信息提取重复性文字工作的自动化这个分类不是官方给的是我自己用下来觉得最顺手的归类方式。官方仓库里可能按字母序或者提交时间排列但实际用的时候你根本不会关心它是第几个提交的你只关心“我现在要干这件事有没有对应的技能”。2.2 技能文件的内部结构长什么样每个技能本质上是一个 Markdown 文件里面包含了几个关键部分。我拿一个“会议纪要整理”的技能举例拆开给你看--- name: meeting-notes description: 将会议记录整理为结构化纪要 trigger: 当用户提供会议记录或录音转写文本时 --- ## 指令 你是一个专业的会议纪要整理助手。请按照以下步骤处理用户提供的会议记录 1. 提取参会人员、会议时间、会议主题 2. 按议题分段每个议题下列出讨论要点 3. 标注每个议题的结论和待办事项 4. 待办事项需包含负责人和时间节点如原文有提及 ## 输出格式 - 会议基本信息表格 - 议题讨论分段落 - 待办事项清单表格事项/负责人/截止时间这个结构里trigger字段特别关键。它决定了 AI 在什么情况下会自动调用这个技能。如果你写的 trigger 太宽泛比如“当用户需要帮助时”那 AI 会在任何对话里都尝试调用它反而干扰正常交流。我建议 trigger 写得尽量具体最好包含明确的场景关键词。2.3 哪些技能是“开箱即用”哪些需要调根据我的实测29 个技能里大概有 10 个左右是基本不需要改就能直接用的比如会议纪要整理、邮件起草、文本摘要这类通用性强的。另外有 12 个左右需要根据你的行业做小幅调整比如合同条款提取不同行业的合同关注点完全不同你得把“重点关注条款”那一部分改成你实际在意的内容。剩下 7 个左右属于“框架可用但细节需要大改”的比如代码审查技能它默认的审查规则是基于通用最佳实践的但你们团队可能有自己的代码规范那就得把规则部分替换掉。提示不要试图一次性把所有技能都配置好。我的做法是先挑 3 个跟你当前工作最相关的技能跑通、调好、用顺再逐步扩展。一次性全上光调试就能把你耐心耗光。3. 把技能加载到 Claude 里的完整操作链路3.1 环境准备命令行工具的选择与配置这套技能合集最初是为 Claude 的命令行工具设计的但它的核心逻辑是通用的你完全可以在其他支持系统提示词或技能加载的平台上复现。我主要用两种方式一是 Claude 的桌面端配合项目知识库功能二是通过命令行工具直接加载。命令行方式更适合批量处理和自动化场景。你需要先确保本地有 Node.js 环境版本建议 18 以上。然后通过 npm 安装对应的 CLI 工具。安装完成后在项目根目录下创建一个skills文件夹把技能文件按分类放进去。# 检查 Node 版本 node -v # 初始化项目如果还没有 package.json npm init -y # 安装 CLI 工具具体包名以官方仓库为准 npm install -g anthropic-ai/claude-cli配置文件的路径通常在~/.claude/config.json或者项目根目录的.claude文件夹下。你需要把技能目录的路径写进配置里这样 CLI 启动时才能扫描到。{ skillsDir: ./skills, autoLoad: true, defaultLanguage: zh-CN }这里有个坑autoLoad设为true的时候CLI 会在每次对话开始时扫描所有技能文件。如果你技能文件很多启动会变慢。我的做法是保持autoLoad: false然后在需要的时候通过命令手动加载特定技能。3.2 技能文件的命名规范与目录组织目录结构直接影响你后续维护的效率。我试过几种组织方式最后觉得按“功能域/具体技能”两级目录最顺手skills/ ├── document/ │ ├── meeting-notes.md │ ├── contract-extract.md │ └── long-text-summary.md ├── coding/ │ ├── code-review.md │ ├── error-diagnosis.md │ └── test-generator.md ├── data/ │ ├── csv-parser.md │ └── trend-analysis.md └── office/ ├── email-draft.md └── schedule-planner.md文件名用英文小写加连字符不要用中文或空格。虽然系统可能支持但后续在命令行里引用的时候中文文件名会让你多敲很多引号而且容易出错。3.3 验证技能是否加载成功加载完成后你需要验证技能是否真的生效了。最直接的方法是在对话里触发一个明确的场景看 AI 是否按照技能定义的格式输出。比如你加载了“会议纪要整理”技能就输入一段模拟的会议记录观察输出是否包含表格、是否按议题分段、是否提取了待办事项。如果输出格式跟技能文件里定义的不一致说明技能没被正确加载。我遇到过一次情况技能文件写好了配置也改了但 AI 就是不走技能流程。排查了半天发现是文件编码问题——我用 Windows 记事本保存的 Markdown 文件带了 BOM 头导致解析失败。后来统一用 VS Code 保存为 UTF-8 无 BOM 格式问题就解决了。注意技能文件的 frontmatter就是---包裹的那部分对格式非常敏感。冒号后面必须有空格缩进必须用空格不能用 Tab这些细节不注意就会导致解析失败。4. 实测中暴露的问题与修复方案4.1 技能冲突当两个技能抢同一个触发场景这是我最开始遇到的最头疼的问题。比如“文本摘要”和“会议纪要整理”这两个技能它们的触发条件都包含“用户提供一段文本”这个场景。结果就是 AI 有时候该整理纪要的时候给你做了摘要该摘要的时候又给你按会议格式输出了。根因在于 trigger 字段的优先级没有定义。解决方案有两个一是在技能文件里加一个priority字段数值越小优先级越高二是把 trigger 写得更精确避免重叠。我最后采用的是组合方案给每个技能加了priority同时把 trigger 从模糊描述改成了关键词匹配。比如会议纪要的 trigger 改成“当用户输入包含‘会议记录’、‘参会人员’、‘议题’等关键词时”摘要的 trigger 改成“当用户明确要求‘摘要’、‘总结’、‘提炼要点’时”。这样冲突就基本消除了。4.2 输出格式漂移为什么 AI 不按我定义的格式来技能文件里明明定义了输出要包含表格但 AI 有时候就是给你一段纯文本。这个问题困扰了我好几天后来发现原因出在技能文件的指令部分写得太“软”了。比如我原来写的是“请尽量以表格形式输出”AI 就会觉得“尽量”意味着“可以不用”。改成“必须以下列表格格式输出不得使用其他格式”之后遵守率明显提升。另一个原因是对话历史太长。如果在一个对话里已经进行了很多轮交流AI 的注意力会被前面的内容分散对当前技能的指令遵循度下降。我的做法是每个独立任务开一个新的对话窗口不要让一个对话承载太多不相关的任务。4.3 中文场景下的特殊处理这套技能合集是中文的但底层模型对中文的理解和输出有时候会带“翻译腔”。比如你让它整理会议纪要它可能会输出“本次会议就以下议题进行了深入讨论”这种典型的翻译体。解决这个问题需要在技能文件里加一条风格约束“输出使用简洁的中文书面语避免翻译腔避免‘进行了’、‘对于’等冗余表达。”我加了这条之后输出质量明显更接地气了。还有一个中文特有的问题是标点符号。模型有时候会用英文标点有时候用中文标点混在一起很别扭。在技能文件里明确要求“全部使用中文标点符号”可以解决大部分情况。4.4 排查链路一次完整的技能失效定位过程有一次我加载了一个“代码审查”技能但 AI 完全没有按照技能定义的审查清单来输出。我的排查过程是这样的先确认技能文件是否存在且路径正确——检查了配置文件里的skillsDir路径没问题手动打开技能文件确认 frontmatter 格式正确——发现trigger字段的值里有一个中文冒号应该是英文冒号修正冒号后重新加载问题依旧——继续排查查看 CLI 的日志输出发现技能文件被跳过了提示“invalid YAML frontmatter”仔细检查 YAML 部分发现description字段的值里包含了未转义的引号导致 YAML 解析失败把引号改成单引号或者去掉引号重新加载技能终于生效这个问题的根因是 YAML 格式对特殊字符的处理规则。在 YAML 里如果值里面包含冒号、引号、井号这些字符要么用引号包裹整个值要么进行转义。我后来养成了一个习惯所有 frontmatter 里的字符串值都用单引号包裹省得出问题。5. 让技能真正“干活”的进阶配置思路5.1 技能链把多个技能串起来完成复杂任务单个技能能解决的问题有限真正体现价值的是把多个技能串联起来。比如“会议录音转写 → 会议纪要整理 → 待办事项提取 → 邮件通知起草”这一条链路涉及四个技能。实现方式有两种一种是在对话里手动按顺序调用每完成一步把输出作为下一步的输入另一种是写一个“编排技能”在技能文件里定义好步骤顺序和每步的输入输出映射。我目前用的是手动串联因为灵活性更高中间可以随时调整。编排技能适合那些流程非常固定的场景比如每周的周报生成步骤基本不变就可以固化成一个编排技能。5.2 给技能加上“记忆”利用上下文保持一致性默认情况下每次新对话都是白纸一张。但有些场景需要 AI 记住之前的偏好或决策。比如你之前告诉过它“我们公司的合同金额都用万元为单位”下次处理合同时它应该还记得。实现这个的方式是在技能文件里加一个context字段指向一个持久化的上下文文件。CLI 工具在加载技能时会同时读取这个上下文文件的内容注入到对话里。--- name: contract-extract context: ./context/company-preferences.md ---这个上下文文件里可以写各种偏好设置、术语表、格式要求。我建议定期更新这个文件把你在使用过程中反复纠正 AI 的那些点都记进去。5.3 性能优化减少不必要的技能加载当你技能多了之后每次对话都加载全部技能会拖慢响应速度。我的优化策略是把技能按使用频率分成“高频”和“低频”两组高频技能常驻加载低频技能按需手动加载定期清理不再使用的技能文件另外技能文件本身的大小也影响加载速度。如果一个技能文件超过 5000 字考虑把它拆成多个更小的技能或者把一些参考性的内容移到外部文件里用引用链接的方式引入。5.4 版本管理与团队协作如果你是在团队里推广这套东西版本管理就很重要了。我的做法是把技能文件放在 Git 仓库里每个人可以提交自己的修改通过 Pull Request 来审核变更。但要注意技能文件的变更会直接影响 AI 的输出行为所以每次修改都需要经过测试。我建议在仓库里建一个tests文件夹每个技能配一个测试用例文件包含输入样例和期望输出格式。修改技能后跑一遍测试确认没有破坏原有功能。提示团队协作时建议指定一个人作为“技能维护者”负责审核所有技能文件的变更。否则每个人都按自己的习惯改最后技能文件会变得混乱不堪。6. 几个我反复用到的技能实战拆解6.1 会议纪要整理从流水账到结构化输出这个技能是我使用频率最高的。原来开会的时候我一边听一边记会后整理要花将近一个小时。现在我把录音转写的文本直接丢给 AI两分钟就能出一份结构化的纪要。但有个细节需要注意录音转写的文本通常包含大量口语化的重复和语气词如果直接让 AI 整理它可能会把一些废话也当成正式内容。我在技能文件里加了一条预处理指令“先过滤掉口语化的重复表达和语气词只保留实质性内容再进行结构化整理。”另外待办事项的提取准确率取决于原文的质量。如果原文里没有明确说“谁负责什么”AI 也提取不出来。我的做法是在技能文件里加一条“如果原文未明确负责人标注为‘待定’并在备注中说明需要确认。”6.2 代码报错诊断从报错信息到修复方案这个技能对后端开发特别实用。你把一段报错日志贴进去它会输出错误类型、可能的原因列表、每个原因的排查方法、推荐的修复方案。实测下来对于常见的空指针、类型转换错误、依赖冲突这些问题诊断准确率很高。但对于业务逻辑层面的 bug它只能给出方向性的建议具体还得你自己看代码。我在这类技能里加了一条约束“如果错误信息不足以定位根因明确告知用户需要补充哪些信息不要强行给出不确定的修复方案。”这条约束很重要否则 AI 会为了“显得有用”而编造一些不靠谱的修复建议。6.3 长文摘要不只是缩短更是重组普通的摘要工具就是把长文按比例缩短但这个技能做的是“信息重组”。它会先识别文章的核心论点、支撑论据、结论然后按这个逻辑重新组织一段摘要而不是简单地截取原文的句子。我拿一篇 8000 字的技术文章测试过输出的摘要在 500 字左右核心信息保留完整逻辑比原文还清晰。这对于快速筛选信息非常有用。但要注意摘要的质量高度依赖原文的结构。如果原文本身就是一团乱麻摘要也好不到哪去。我在技能文件里加了一条“如果原文逻辑混乱先输出一个‘原文结构分析’指出逻辑问题再给出摘要。”6.4 多平台内容适配一次创作多处分发这个技能解决的是内容创作者的一个痛点同一篇内容要发到不同平台每个平台的风格和格式要求都不一样。技能会读取你提供的基础内容然后按照预设的平台规则进行改写。比如同一篇技术教程发到知乎要偏深度分析发到小红书要偏短平快发到公众号要偏故事性。技能文件里可以定义每个平台的改写规则AI 会自动适配。我目前配置了四个平台的规则实测下来改写质量可以打 80 分剩下的 20 分需要人工微调。但即使这样也比我原来手动改四遍要快得多。7. 关于这套技能合集的一些个人体会用了大概两个月最大的感受是AI 的能力上限取决于你给它的约束质量。同样一个模型你随便问它问题它就是个聊天机器人你给它一套精心设计的技能定义它就能变成一个靠谱的工作助手。这 29 个技能里我真正高频使用的其实只有 8 个左右。但这 8 个技能帮我节省的时间已经远远超过了我配置和维护它们所花的时间。剩下的那些技能有些是备用的有些是给团队其他人用的有些我还在摸索怎么跟自己的业务结合。如果你打算开始用这套东西我的建议是从你最痛的那个场景开始。不要贪多先解决一个具体问题把技能调好、用顺然后再扩展。技能配置这件事跟写代码一样迭代比一次性设计更重要。另外不要迷信“开箱即用”。任何技能都需要你根据自己的实际情况做调整。我见过有人直接把技能文件丢进去用然后抱怨“效果不好”。效果不好是正常的因为技能文件里没有你的业务上下文。花点时间把技能文件改成贴合你实际需求的版本这个投入是值得的。最后说一个我踩过的坑不要在一个技能文件里塞太多功能。我一开始把“会议纪要整理”和“待办事项提取”写在一个技能里结果 AI 经常把两个任务的输出混在一起。后来拆成两个独立技能各自职责清晰效果就好多了。一个技能只做一件事这个原则在技能设计里同样适用。