Gemini CLI 的“技能”机制我第一眼看到的时候还以为是给命令行工具加了一堆宏命令后来深入玩了一段时间才反应过来这东西的关键不在“技能”这个词本身而在于它把智能体从“你问我答”的对话工具往“按章办事”的模块化执行系统推了一大步。我拿到这个题目想聊的就是这个进化背后的设计思路、落地方式以及它对开发者写代码、搭工具这件事到底意味着什么。不管你是天天跟命令行打交道的老手还是刚接触 AI 编程助手的探索者看完这篇应该能对“技能”这个新范式有个完整的判断。1. 为什么说“技能”是模块化智能体的分水岭1.1 从“万能对话”到“专事专办”的必然转变市面上主流的 AI 编码助手绝大多数还是那个经典的“对话式”形态你描述需求模型理解意图然后在你面前“表演”生成代码。这种方式对付零散的小任务很爽比如“写一个快速排序”、“帮我重构这个函数”但一旦场景变复杂问题就暴露了——对话上下文越来越长模型记不清你最初强调的约束每次都要重复交代项目规范、代码风格、目录结构而且不同的任务之间完全无法复用换个项目又是从零开始。我举个例子你就明白了。假设你维护一个微服务项目每次给新模块写接口文档时团队都要求包含接口概述、认证方式、错误码表、调用示例四个部分且格式要跟历史文档保持严格一致。你让对话式助手来做你得把规范复述一遍再把历史文档粘一段当参考好不容易生成出来格式还经常跑偏。一次两次你忍了十次八次你就会想为什么这个“智能体”不能内置一套操作规范每次直接按章执行这就是技能机制要解决的问题——把可重复、有明确逻辑、有稳定过程的任务固化成一套可加载、可复用、可版本管理的“技能包”。1.2 技能机制与传统命令行脚本的本质区别很多人第一反应是这不就是 Shell 脚本或者 Makefile 吗还真不是。传统脚本是“硬编码”的——输入输出、执行步骤、异常分支写得死死的严格但僵化。技能机制的核心区别在于它融合了模型的推理能力技能定义的是“按什么逻辑做什么事”但具体怎么做、用到什么参数、临时涌现什么分支由模型根据当前情境动态决策。用大白话讲传统脚本是乐高说明书每一块拼哪里画得清清楚楚技能定义是教你怎么造乐高零件再告诉模型“你可以用这些零件搭一艘船”船怎么搭模型自己发挥。这个差别带来一个很实际的好处技能的编写成本和维护成本远低于完整的自动化脚本。你不用把每一步都写死只要把关键约束、判断标准和常见路径描述清楚剩下的推理交给模型。换句话说技能是一种介于“纯自然语言提示词”和“严格工程代码”之间的中间形态既有前者的灵活性又有后者的可复用性。它真正把“大模型当脑子、处理逻辑当方法”这件事在工程上落地了。2. 技能包的骨架一块 Skill 拆开长什么样2.1 目录结构与核心信息单元在 Gemini CLI 的体系里一个技能本质上是一个目录通常叫.agent/skills放在项目根目录或者一个专门的技能仓库下。这个目录里每一个子目录就是一个独立技能技能内部必须包含一个SKILL.md文件这是技能的“信息入口”。我建议你用“最小可行技能”的标准来组织信息一个技能聚焦一件具体的事别指望一个技能包打天下。一个典型的技能包结构大致是.skills/ docs-writer/ SKILL.md scripts/ render_checker.py references/ template.md code-reviewer/ SKILL.md rules/ security_checklist.mdSKILL.md是绝对的核心。它的头部需要一个简短的前言用两三句话讲清楚这个技能“什么时候该被触发”比如“当用户要求编写接口文档时使用本技能”。接下来是使用步骤建议用有序列表写清楚“先做什么、再做什么、遇到什么情况判断什么”这是模型执行的主逻辑。最后是“关键约束”比如“输出的文档必须包含四个固定章节”“错误码表必须以表格形式呈现”约束写得越具体模型跑偏的概率越低。我第一次自主构建洋葱的时候没经验把技能包当 README 写长篇大论加各种背景介绍结果模型加载后半天抓不住重点。后来我调整策略前言只留 3 句话以内步骤部分用“当……则……”的条件句框架写约束只列不可突破的底线。这样改完之后触发准确率和执行稳定性都明显上了一个台阶。2.2 脚本与资源给技能装上手和脚SKILL.md 管“思路”但落到实操时很多环节比如检查文件格式、跑测试、扫依赖漏洞纯靠自然语言描述让模型去推理容易出乱子。所以技能包还支持挂载可执行脚本和参考资源文件。脚本部分的用法很有意思。你可以把一个用 Python 写的格式校验工具放到scripts/下然后在 SKILL.md 的某个步骤里写一句“运行 scripts/ 下的格式校验脚本并根据输出来修正文档结构”。模型在执行这个步骤时会自行去调用脚本把脚本输出作为下一步决策的输入。这等于给技能加了“手”能真正操作环境里的工具而不仅仅是嘴上说方法。资源文件这块我的建议是放“参考模板”和“检查表”。还是拿接口文档技能举例你可以放一份团队成员都认可的已发布的文档作为模板并注明“按照该模板的章节层级和措辞风格输出”对于代码审查技能可以放一份安全漏洞检查清单让模型在审查时逐项比对。Gemini CLI 在加载技能包时会把 SKILL.md 连同资源文件路径一起放入上下文模型可以随时按需读取。这里有个容易踩的坑资源文件不能太大。技能的核心作用是“精准指引”不是“倾囊相授”你硬塞一个几 MB 的代码库进去只会让模型在加载时浪费大量上下文窗口影响后续指令执行的连贯性。我个人的经验是单个资源文件控制在 20KB 左右宁可精简拆成多个小文件也不要堆一个大文件。2.3 编写一份好 SKILL.md 的三个推荐原则第一用步骤说话少描述背景。技能文件不是给人看的文档是给模型吃的操作指引背景和动机尽量不写或极简直接上步骤和判断逻辑。第二关键信息要“显式化”。比如“接口文档需要覆盖认证方式”这种描述不够“认证方式需要明确 token 的位置、有效期、refresh 机制”才是合格的约束。模型对含糊描述的发挥空间太大你不想在审查结果时反复返工就在这一步多花几分钟。第三持续迭代版本。技能包不是一次成型的东西我在真实项目中前三个版本基本每周都在改不是逻辑不对而是模型在处理边界情况时会暴露出你约束盲区。养成“技能包随项目演进”的心态别指望一份技能文件维护上半年。3. 执行链路拆解技能是如何被找到和调用的3.1 检索—注入—执行技能机制的三段式运转技能的调用过程可以用三个阶段概括检索、注入、执行。这三个阶段是模型运行时的内部逻辑理解它对你的技能包设计至关重要。检索阶段模型会根据用户指令在加载的技能包列表中筛选可能相关的条目。这一般靠语义匹配。所以 SKILL.md 开头的前言描述质量就很关键了——你得让模型在“一句话意图”的粒度上就能判断“这个技能该不该出场”。我见过不少技能包正文很完善但前言写得跟学术摘要似的模型等于看串了一样找不到触发点技能就变成摆设了。注入阶段被选中的技能内容会作为额外上下文加载进模型的处理窗口。这里要提醒一个现实问题注入的技能内容会占用上下文窗口的空间。如果你同时加载三四个大体量技能留给当前具体任务的容量就变小了输出的细致度就可能下降。所以实际落地时我给团队的建议是技能包本身要轻单技能控制在 100 行以内描述脚本和资源按需读取这样注入负担最小执行质量最稳。执行阶段模型会按照 SKILL.md 里的步骤逐条执行遇到底层工具调用就实际操作遇到判断分支就根据当前信息决策直到步骤跑完输出最终结果。要不要给模型加一个“执行计划的确认环节”我的做法是高风险的写操作任务比如批量修改文件宁可多一次确认只读分析类任务则直接全速执行。这个权衡按你自身场景来。3.2 技能机制与上下文工程的关系深入用过 Gemini CLI 之后我的体会是技能机制本质上是把“上下文工程”从对话层面下沉到了“工程化配置”层面。没有技能的时候你要靠每次对话的提示词去塑造模型的临时行为有了技能你就可以把高频场景的行为模式固化下来届时执行时自动装配。这对团队的帮助非常明显。我们团队在不同阶段用同一套 Gemini CLI 做两种需求一种是快速的原型验证——这需要模型天马行空放任它自由发挥另一种是规范约束下的生产级代码——这要求它遵守大量规则。以前这两件事在同一个项目里是互相打架的。现在我们把“原型探索”和“生产级实现”分别写成两个技能包让模型在不同情境下自动切换行为模式。这种“按技能切换人设”的用法特别契合复杂项目。别小看这个改变。它在提示词工程和微调之外给团队提供了一条全新的、成本更低的“模型调教”路径——不动参数只换技能包就能在不同行为模式之间切换。对一个要同时应对多种开发场景的团队来说这能省下大量的沟通与配置成本。3.3 技能与 MCP、外部工具的分工协作这轮 AI 工具链里还有另一个难以回避的名词叫 MCPModel Context Protocol模型上下文协议。很多人搞不清技能机制和 MCP 的区别总觉得它们干的是同一件事。我现在的理解是技能管“策略”定义“这件事应该怎么做”MCP 管“工具”解决“做这件事需要的工具和数据从哪来”。认知到它们在分工而不是重叠之后技能的价值反而更清晰了。技能告诉模型先搜集仓库里的测试结果再分析代码变更范围最后调用代码审查服务MCP 则是那个“代码审查服务”的通信管道。两者联动才能构成一套完整的自动化智能体工作流。实际落地时建议这样搭配技能包负责编排流程和判断逻辑MCP 服务负责对接外部系统比如提交审查请求、读取缺陷跟踪系统的工单、更新文档平台。技能是大脑的动作计划MCP 是执行动作的四肢理想状态是各司其职不出范围。理解了这一层你在设计技能包时就不会贪心地想把所有外部调用逻辑都写进 SKILL.md技能文件会干净太多。4. 让技能机制真正落地的三个实践场景4.1 场景一把项目规范固化成交付模板交付类项目最常见的问题就是“这次格式和上次不一样”——接口文档章节不全、测试报告缺运行环境信息、上线说明漏了回滚方案。这些活交给技能包再合适不过。以“项目验收交付”为例我用技能包固化下来的一份工作流程是这样的开场先要求模型检查项目根目录的文件结构识别产品类型然后读 README 与增量改动记录最后按“功能清单、接口说明、部署步骤、验证记录、未知风险”五个固定板块生成验收文档。这五个板块不是拍脑袋想的是一次交付被甲方打回来三次之后总结出来的底线要求。这套技能包最省心的地方是不同的工程师执行输出的交付文档结构都一致差异只体现在文字详略和具体内容上。对团队负责人来说这解决了“交付质量全凭个人经验”的不确定性对新人来说技能包就是一本“活的执行手册”照着走很难犯低级错误。4.2 场景二让代码评审也有统一的“评审视角”代码评审的难点在于审查者的经验和关注点差别太大。有人死盯命名规范有人关心边界条件有人一门心思找性能隐患。用技能包把评审视角统一起来能把“人治”变成“制治”。我实现过一个“后端接口安全评审”技能包里面写清楚了这个场景下的必查项入参是否做白名单校验、鉴权逻辑是否可以在中间件层统一处理、是否存在明显的水平越权嫌疑、SQL 拼接是否走了参数化等等。模型拿到这个技能后在常规代码审查之外会专门针对安全维度出一份补充意见。这个技能的自动化价值显而易见以往经验不足的审查者容易漏掉风险技能兜底把底线风险抓住了。4.3 场景三自动化多步任务的数据流转再进阶一点的玩法是用技能编排一个跨步骤的数据处理链路而不再是一条提示词就能概括的简单任务。比如“从日志文件里分析错误分布并生成周报摘要”这至少涉及读日志、按错误类型聚合统计、过滤已知噪音消息、按固定格式生成摘要报告等四个步骤。我用技能包把这个流程写下来之后模型的执行路径稳定了不会再出现这周报告带原始堆栈信息、下周报告只剩统计数字的混乱情况。并且如果某一步出错比如日志文件路径变动导致读取失败模型会依据技能里的异常处理分支调整策略给出明确报错或改用备用路径这在对话式助手时代基本是做不到的。5. 你可能踩到的坑与我的排查心得5.1 技能不被触发八成是前言没写清楚技能包建好了但运行的时候模型压根不调用这是我遇到最多的反馈。排查方向其实很单一——SKILL.md 开头的前言没有描述清楚触发条件。模型做技能匹配时靠的是语义相关性你的前言如果写得过于宽泛比如“此技能用于辅助开发”它就无法跟当前具体任务建立强关联。解法也简单把前言改成“当用户需要生成接口文档时使用本技能”并在步骤里再加一句“如用户未明确说明格式默认采用技能内置模板”。改完一般立竿见影。5.2 技能执行结果不稳定约束写得太抽象“生成高质量的代码”这种描述等于没说。模型对“高质量”的理解跟你可能天差地别。要把约束具体为可校验的条目“函数不得超出二十行”“关键异常路径必须有日志输出”“禁止硬编码环境相关配置”。注意这些约束必须是模型可以自行检查的结果我们尽量不写主观色彩浓重的模糊要求技能执行质量才会稳定。5.3 技能包版本泛滥缺少收敛机制技能包写多了以后你会发现同一个用途存在多个相似版本a 项目的接口文档技能、b 项目的接口文档技能看似一致细节又互相矛盾。定期收敛很重要我一般一个季度整理一次把同类型技能合并成一个通用包再用“变量区”存放项目差异配置。这样真正维护起来成本会低很多。5.4 常见问题速查表现象常见原因处置方式技能完全不触发前言意图描述不清精简描述用“当……时使用”句式技能触发后执行跑偏步骤缺少明确分支判断对关键分支补充“若……则……”逻辑输出风格不稳定约束过于抽象把约束改为可校验的具体规则技能包占用上下文过多资源文件过大压缩资源按需读取多个技能互相冲突职责边界没划清收敛技能清单明确唯一职责6. 开发者新范式从“调 API”到“训练下属”模块化智能体的出现在我用 Gemini CLI 的这段经历里感受最强烈的是我的工作方式被拆成了两层。第一层是做具体的事写代码、查问题第二层是定义“做事的方法”把它变成技能包。以前专注在第一层现在越来越多的时间投到第二层。一个做前端的朋友说了一句让我印象特别深的話“给智能体写技能感觉不是在写代码像是在给新同事写入职培训手册。”这个类比很贴切。传统开发范式是“人想清楚逻辑然后编码让机器机械执行”新范式的关键在于“人描述清楚目标和原则机器在技能约束下自主推理完成路径”。开发者不再只是代码的生产者开始变成“行为范式的定义者”。这种转变对团队协作模式的影响也值得说两句。当团队的规范和套路被显式固化为技能包它其实变成了一种“团队记忆”——不再依赖“老员工口口相传”而是沉淀为仓库里可被加载的资产。新成员上手一个项目不再需要花几周时间观察摸索直接让智能体加载对应技能包就能按团队沉淀下来的方式处理任务。这在项目协作层面是一个效率杠杆。这种“调教”能力的门槛并不高反而是熟练使用提示词、懂得拆解流程、能清晰描述约束的这些软技能变得更加关键。未来开发者竞争力的一部分可能正体现在“能不能把自己的经验有效迁移给智能体”这件事上。我在实际使用中最深的体会是技能机制的真正威力不在某一个技能包写得多完美而在于你有没有建立起“经验可沉淀、过程可复用”的思维方式。第一批把业务逻辑、流程规范、判断标准写成技能包的团队相当于给自己的项目装了一套自动化的经验传导装置这种先发优势会随技能库的积累越拉越大。所以我的建议是别等工具彻底成熟现在就拿一个最烦人的重复性任务练手写出你的第一个技能包。这个实践成本很低但它带来的思考方式转变可能比工具本身更值钱。
