最近身边好几个人都在讨论一个叫“小龙虾”的东西，一开始我以为是夜宵档口的新品，结果点进去一看，说的是一个开源AI助手技能包项目。社区里给它起的外号挺形象——项目代号里带“LOBSTER”，再加上那一排小龙虾相关的能力列表，干脆就叫小龙虾了。我实际用了一周，最大的感受是：如果说以前往AI助手的系统提示词里堆规则像“口述需求”，那这批skills就像是给了它一整套规范化的工作流。这篇文章就把我踩过的坑、验证过的方法、以及真正值得装的部分整理出来。
先说清楚：下面所有演示都运行在一个带终端权限、能读写本地目录的AI助手里，你用的是哪一款不影响理解。核心要掌握的是skill这套机制，以及怎么让技能包真正干活。
1. “小龙虾”到底是啥：先说清skill机制再谈安装
1.1 一个昵称背后的真实项目
小龙虾并不是一个全新的独立软件，它是依附在主流AI助手之上的一套“技能包合集”。所谓skill，你可以理解成一份结构化的“岗位说明书+作业手册”：它告诉大模型某个任务的标准处理流程、输入输出格式、要调用哪些命令、遇到什么情况该怎么处理。和普通提示词的区别在于，skill是有独立文件结构、有元数据描述、可以被动态加载和卸载的能力单元。
这个项目把这几年社区里那些散落各处的“秘籍”收拢了起来，用统一的格式重新组织。项目里每个技能都自带一个SKILL.md，里面写明触发条件、执行步骤、示例和禁忌。装好之后，你只要在对话里提到某个任务关键词，助手就会自动加载对应技能，而不是每次都要你在提示词里长篇大论地描述“我希望你怎么做”。
我实测后的体会：这套设计的核心价值不是“多了几个指令模板”，而是把“经验”沉淀进了可复用的文件里。以前我在提示词里写“遇到异常先查看日志再分析”，不同项目里要重复粘贴；现在直接把这类长期主义的工作方法做成一个skill，所有会话默认都能用上。
1.2 为什么说“skill”而不是“写个提示词就行”
要理解“必须装”，得先理解一个反直觉的事实：大模型对“临时输入”的遵从严不严格，取决于上下文窗口里提示词的位置和格式。系统提示词排在所有内容之前，模型通常会把靠前的指令当作“高优先级背景设定”；而用户在对话中段写的一段临时要求，很可能被后续长上下文稀释。
skill恰恰解决的是这个“位置”问题。当助手确认某个技能被触发时，它会把整个SKILL.md置为当前的执行上下文，相当于给你的对话临时“加了一个前置设定”。这一点和传统插件的差异也很明显：插件是程序逻辑的扩展，能做系统调用、能发请求；skill只是文本+命令的组合，它不改代码，只改变大模型思考的方式和节奏。
还有一个容易忽略的细节：skill文件本身是Markdown纯文本，这也意味着你可以放到任意目录、用版本管理工具跟踪修改历史。我在试用期间把整个skills目录初始化成了一个独立的仓库，每次改动都能回滚，这个习惯帮我避免了好几次改坏配置的麻烦。
2. 这批“必装”技能包拆解：每个能干点啥
2.1 技能包全家桶里，真正高频的六个
我完整浏览了一遍小龙虾项目提供的skills清单，大部分能力的覆盖面都很广。挑六个我实际用过的，按“解决什么痛点”整理成一张速查表，方便你判断要不要全装。
| 技能名 | 解决的核心痛点 | 典型触发场景 |
|---|---|---|
| 上下文整理 | 对话长到一半，助手忘了早期需求 | 需求汇总、阶段性复盘 |
| 代码审查 | 只盯着代码逻辑，忽略命名和安全性 | PR合并前的自检 |
| 架构决策记录 | 技术选型理由过了两周就说不清 | 引入新依赖、模块拆分 |
| 数据库脚本生成 | 临时起意写SQL，经常漏索引和事务 | 给新表建结构、写迁移脚本 |
| 周报整理 | 每天的工作散落在多个文档里 | 周五下午汇总一周产出 |
| 文档脱水 | 会议记录又长又乱，找不到结论 | 会议纪要、访谈整理 |
每个技能都做到了“点击即用”，但它们侧重点完全不同。比如代码审查这个skill，它关注的不是语法对错，而是会引导大模型按“安全性、性能、可维护性”三个维度逐一过，并要求在每条意见后面给出修改示例。这比我直接在提示词里说“帮我检查代码”出来的结果扎实得多。
2.2 我在实际项目中最常用的触发方式
技能再丰富，如果触发词不好记，装了就等于没装。小龙虾的触发逻辑设计得比较实用：只要你提到和技能名高度相关的动作词，它就会自动加载。比如我说“帮我把这三个文件过一遍”，助手会先判断是不是需要触发代码审查技能，再决定加载哪个SKILL.md。
举个真实例子。我负责的一个模拟项目里，每次要加一张业务表，以前都是自己手写建表语句，然后被同事提醒“加上更新时间索引”。装好数据库技能后，我只需要说“给订单明细表加一个支付状态字段，按我们的规范生成迁移脚本”，它就会自动加载技能包，按照里面定义的字段命名规则、索引策略、回滚方案把脚本生成好。
这里有个小提示：技能内部定义了一组“硬性要求”，比如数据库脚本必须包含DROP语句的备注、必须写明执行顺序。这些几乎不会在普通对话里被主动遵守，但写成技能后，助手每次触发都会先读一遍要求，执行稳定性高很多。
3. 安装前先想清楚目录规划：别让技能包变成垃圾堆
3.1 推荐的项目目录结构
很多人在安装时第一件事就是往默认目录里塞文件，我认为这是最大的隐患。技能包一旦多了，没准哪天加载错一个，最后排查半天。小龙虾项目建议每个技能独立一个子目录，一个技能对应一个文件夹，文件夹内有且只有一个SKILL.md（外加可选脚本和资源文件）。
我自己的目录长这样：
~/.ai-assistant/ ├── skills/ │ ├── code-review/ │ │ ├── SKILL.md │ │ └── scripts/ │ │ └── analyze.sh │ ├── db-migration/ │ │ └── SKILL.md │ ├── weekly-report/ │ │ └── SKILL.md │ └── context-sweep/ │ └── SKILL.md └── config.toml为什么推荐这种装法？第一，单个技能目录便于用Git做版本管理；第二，AI助手在加载技能时通常用目录名作为命名空间，如果两个技能的目录名重叠，容易产生冲突；第三，未来想给某个技能加脚本、加示例，都能在同一个目录内完成闭环，不需要到处翻文件。所以哪怕你现在只打算装一个技能，也建议先建好这个骨架。
3.2 接入AI助手的完整步骤
接入过程本身不难，难的是找到各款助手对应的“自定义指令入口”。大多数支持本地技能加载的助手，都提供一份全局配置文件，里面可以声明“从哪些目录载入自定义技能”。安装步骤拆开就是三步：
- 把整个skills目录克隆到本地固定路径（我放在用户目录下的.ai-assistant里）。
- 在助手的配置入口（通常是CLI侧的config文件或图形界面里的“自定义指令”栏）追加一行搜索路径，指向该目录。
- 重启会话，让助手重新读取配置。
我建议第二步不要直接指向根目录，而是指向skills子目录本身。因为有些助手会递归扫描整个目录树，你把根目录指进去，它可能把未整理好的旧文件也当作技能加载，白白浪费上下文窗口。
安装完成后，你可以做一些“冒烟测试”：直接问助手“你现在有哪些可用的技能，用表格回答我”，它如果能在几秒内列出技能名和一句功能描述，说明加载链路已经通了。如果它答不上来或者只列了一个，不要急着怀疑助手，先检查第三步的路径拼接，多半是这里出了问题。
3.3 安装完必须验证的一件事
路径对了、助手也认了，并不代表技能内容一定生效。这里我要强调一个极易踩的坑：很多AI助手都有“技能缓存”机制，第一次扫描后会把技能目录的索引缓存进本地，之后你更新了一个SKILL.md，它读到的可能还是老版本。
验证方法很简单：在对话里故意用技能里的某个专属术语提问，看它能不能复述出这个词对应的概念。比如数据库迁移技能里有一个术语叫“双写阶段”，如果我在对话中随口提到“这次变更要不要走双写阶段”，助手能立刻接上这个话题，并且说出该技能对双写阶段的处理建议，说明它确实加载到了新版本；如果它一脸茫然，大概率是缓存没刷新。
碰到这种情况，我的做法是优先清理助手自身的缓存目录，或者重启一个新的会话，而不是去改技能文件。改文件反而容易让问题更隐蔽——你以为更新了，实际助手读的还是旧版，后面出现问题会甩锅给新配置。
4. 只有验证还不够：常见失灵问题的完整排查链路
4.1 一个“假加载”案例的完整追踪
有一次我改了代码审查技能的“禁止事项”，要求助手在提意见时不得使用“建议优化”这类空话。结果下次会话里，它照样给出了一条“建议优化一下性能”的意见。我当时第一反应是技能没生效，于是开始排查。
我第一个动作是让助手“把当前已加载的SKILL.md原文读给我听”，结果它复述出来的确实是新版内容。这就奇怪了，文件已经加载，但行为没有按新规则执行。接着我让它“严格回顾代码审查技能的第四条禁止事项，然后重新审查这段代码”，它才说出了“性能问题需要给出具体热点定位和重构方案”。
也就是说，问题出在“技能虽然被加载，但因为代码审查请求里的表述比较模糊，助手没有把技能视作必须遵循的约束，而是当成了背景知识”。这解释了为什么临时性提示词不顶用：即便是技能内容，在没有被当作“应当遵守的规则”时，也可能被模型降权处理。
追踪到这一层，我的解决方案是：直接在项目级系统提示词里加上一句“当触发代码审查技能时，禁止事项视为绝对约束”。加了这句话之后，行为就稳定多了。这个案例给我的启发是：技能文件负责“知识”，但“约束优先级”最好在系统提示词里再明确一道，双重确认更稳妥。
4.2 四类高频失效原因汇总
在社区里逛了一圈，加上自己的实际使用，我总结出四个最常见的技能失灵原因。对照排查比反复改提示词更高效。
| 现象 | 大概率原因 | 处理方式 |
|---|---|---|
| 提到触发词但助手毫无反应 | 技能名与触发词不匹配 | 在SKILL.md里补写清晰的“trigger”段落 |
| 技能能列出内容但执行时不遵守 | 技能描述太长，优先级被稀释 | 把核心约束挪到技能文件前几行 |
| 更新文件后行为没变化 | 助手或服务的技能缓存未刷新 | 清缓存、重启会话，必要时等缓冲 |
| 多个技能同时触发导致行为混乱 | 技能职责边界重叠 | 收紧每个技能的触发词，避免覆盖通用词 |
这里特别说一下多技能冲突。我最初装了“上下文整理”和“文档脱水”，它们都会在“总结”类动作上被触发，结果有段时间每次说“帮我总结一下”，它会把两套流程都执行一遍，输出变得极度冗余。后面我把“上下文整理”的触发词限定为“会话梳理、需求追溯”，把“文档脱水”的触发词限定为“会议纪要、要点提炼”，两者才算井水不犯河水。
5. 自己动手写一个skill：以“周报整理”为例
5.1 最小skill的标准结构
装别人的技能，永远不如自己写一个来得透彻。我建议你的第一个自定义技能从“周报整理”起手，因为数据都是自己的，规则也是自己定的，改起来不会有心理负担。一个最小可用的skill结构很简单，就一个SKILL.md：
--- name: weekly-report description: 把分散的工作日志整理成周报，按项目、产出、问题三类输出。 triggers: - 周报 - 本周总结 - weekly report --- # 周报整理技能 ## 目标 从工作日志中提取关键信息，输出结构化周报。 ## 步骤 1. 先列出用户提供的所有工作日志来源。 2. 按日期排序，去重。 3. 将内容归入三类：项目进展、确定成果、遗留问题。 4. 输出三段式周报，每段用5条以内的要点。 ## 禁止事项 - 不得编造未出现的工作内容。 - 不得用“推进”“优化”这类空泛词，必须写明具体动作。 ## 示例输入 今天修了登录接口超时，加了缓存，另外整理了测试报告。 ## 示例输出 - 登录接口：修复超时问题，引入缓存策略。 - 测试报告：完成本轮测试结果整理。这个文件写好后放进skills目录，重复第3章的接入流程即可生效。我特别想强调头部三项字段（name、description、triggers）的重要性：name决定了它在技能列表里的显示名，description是助手判断是否加载它的依据，triggers则是对话时触发加载的开关。三者使用英文名是为了避免中文切词歧义，这个我在第6章会专门展开。
5.2 进阶：带自包含脚本和记忆状态的skill
当你不满足于“纯文本规则引导”，可以试着给技能加一个脚本。以周报技能为例，我在技能目录下放了一个generate_report.py，它会扫描指定的日志目录，产出临时的周报草稿文件。SKILL.md里则写清楚“当用户说‘生成周报草稿’，先运行该脚本，然后读取输出文件并润色”。
这一步的核心意义是让skill从“约束思维”变成“自动化流水线”。理论上，任何能在终端执行的命令都可以被写进SKILL.md。不过要提醒两点：第一，脚本路径应写成相对于技能目录的写法，否则你在别的机器上克隆项目后路径全失效；第二，脚本执行完必须明确告知助手“输出文件在哪，下一步该读什么”，否则大模型很容易在脚本执行完就停下来，等你手动读取文件。
我还尝试过给技能加“记忆状态”——在技能目录下放一个state.json，记录上次处理到哪一天。周报这种周期性任务非常需要这个状态，不然每次都是重新扫描整个目录，效率很低。SKILL.md里规定“先读取state.json，然后只处理增量日志，结束后更新state.json”，这样技能就从一个无状态指令变成了带进度的业务工具。
6. 用久了你就会知道：几个反直觉的实操心得
6.1 系统提示词里写明技能边界，反而能放大技能效果
刚上手时我一直觉得“技能已经写清楚了，系统提示词里就不用重复”。但实际用下来，这句话只说对了一半。技能文件里的内容是“知识性规则”，而助手在回应具体请求时，首先遵循的是系统提示词里关于“行为约束”的部分。
后来我在项目级系统提示词里加了一行：“本项目启用了自定义技能目录，当加载技能后，以技能文件为准处理相关任务。遇到技能未覆盖的情况，回退到通用逻辑。”就这么一句话，明显提升了技能的执行率。原因是它给大模型划清了“技能优先”的权限边界，比技能文件自己声明一百句“必须遵守”都管用。
6.2 过长的SKILL.md会导致“读是读了，就是不照做”
这个坑我最初完全没想到。某次我试图把数据库迁移技能写得面面俱到，一共两千多字，覆盖了索引设计、外键策略、事务隔离级别、命名约定、灰度发布步骤。结果在实际使用时，助手虽然能完整复述这些内容，但执行时经常只挑后半部分规则，前几页的规则几乎形同虚设。
后来我意识到，token太长时，模型的注意力会集中在最新读到的那部分，旧内容天然被淡化。解决办法就是“瘦身”：把技能的开头压缩成半页以内的摘要，里面放最关键的“必须做”和“禁止做”，其余细节折叠到“参考资料”区块。这样助手一加载，先看到的就是核心约束，执行效果立刻好很多。我现在给自己定的红线是：单个SKILL.md不超过800字，超过就拆分。
6.3 命名与触发词，尽量避开中文切词歧义
最后一个心得来自一个很实际的问题：为什么有些技能的触发词里包含“总结”两个字，却经常和别的技能打架？因为中文没有天然空格，很多助手做触发判断时用的是整句切词匹配，中文的切词结果五花八门，“总结工作”和“工作总结”可能被识别成完全不同的短语。
我在小龙虾群里看到有人建议：触发词尽可能用英文，或者中英混搭。比如周报技能，我在triggers里同时写了“周报”“weekly report”，但最终让它稳定触发的其实是“weekly report”。原因是英文词匹配几乎不会受切词影响。如果非要用中文触发词，建议选两个以上汉字组成的动词短语，比如“做周报”“写周报”，而不是单字“报”。这一点上我踩过几次坑，改完触发词之后，技能“静默失败”的情况少了很多。
我现在的习惯是：每新增一个技能，先写一句话测一下触发，然后故意用一个相似但语义不同的句子测试“不触发”，确保触发边界清晰。这套方法虽然听起来很基础，但确实能让技能包长期保持健康，不至于装到后来自己都不知道有哪些能力。如果你和我一样经常在多个项目目录间切换，建议把skills目录也纳入版本管理，换新环境十分钟就能恢复整套工作流。
