Gemini CLI 自定义命令教程：从创建到实战全流程

今天想聊一个我最近特别上头的东西——Gemini CLI 的自定义命令。你知道吗，我之前一直觉得在终端里跟 AI 对话已经够酷了，直到我发现你可以把一整套开发流程封装成一条斜杠命令，输入一下就自动跑完。 对，这个功能其实是 Gemini CLI 可扩展性的核心体现。你可以这么理解——它本质上就是一段预定义的提示词，但这段提示词可以非常复杂，包含多个步骤、条件判断，甚至让模型去执行 shell 命令。你把它写好放在那儿，以后每次用的时候就跟调用一个内置命令一样简单。 嗯，我觉得这个思路特别好。就像我们写代码会把重复逻辑抽成函数一样，自定义命令就是把你的最佳实践抽成了一个可复用的 AI 工作流。那具体怎么创建呢？ 其实特别简单。你在项目根目录下找到 .gemini 文件夹，没有就自己建一个，然后在里面创建一个 commands 子文件夹。接下来关键来了——你在 commands 里面放一个 .toml 文件，文件名就是你的命令名。比如你创建了一个 component.toml，那在 CLI 里输入 /component 就能触发它。 文件名即命令名，这个设计挺直觉的。那 toml 文件里面写什么呢？ 两个核心字段。一个是 description，就是命令的简短描述，输入命令时 CLI 会显示出来。另一个是 prompt，这才是重头戏——你要发送给模型的完整提示词都写在这里。而且有个很重要的语法，prompt 里可以用双花括号包裹 args，就是 {{args}}，它会自动捕获用户在命令名后面输入的所有内容。 哦，就像模板变量一样？比如我输入 /component 一个圆形头像组件，那'一个圆形头像组件'这段话就会填到 {{args}} 的位置？ 没错，就是这个意思。这样同一个命令模板就能适应不同的具体需求，一次编写多次复用。 好，那我们来看点实际的。你之前做了一个 UI 组件生成的命令对吧？这个挺有代表性的，能展开讲讲吗？ 好，这个命令我设计了 7 个步骤，其实编排这些步骤本身就是一种提示词工程的实践。第一步是 Git 安全检查，这个我觉得特别重要。提示词要求模型先跑一个 git status，看看当前有没有未提交、未暂存的更改。一旦检测到，立刻中止，不往下走了。 这一步确实关键。因为后面要切新分支嘛，如果当前有没处理的更改，切分支可能就把东西搞丢了。 对，这就是防御性编程的思路——永远假设执行环境可能处于非预期状态。然后第二步第三步是自动创建分支，模型会根据你描述的组件名推导出一个分支名，格式是 component/ 加上 kebab-case 的组件名，比如 component/circular-avatar，然后用 git switch -c 切过去。 用 switch 而不是传统的 checkout -b？ 嗯，Git 2.23 之后推荐用 switch，语义更清晰。checkout 那个命令身兼数职，又切分支又恢复文件，容易混淆。switch 就专门干切分支这一件事。 好，分支建好了，接下来呢？ 接下来第四到第六步是我最得意的部分——TDD 流程。先写测试，再写组件，最后跑测试验证。你看，模型会先在测试目录里创建测试文件，写好几个有意义的测试用例，但先不运行。然后再去 components 目录创建组件代码。最后运行测试，如果有失败的就修复，直到全部通过。 这个思路很妙啊。让 AI 先写测试等于是先定义了什么叫'正确'，然后生成的代码必须通过这些测试才算完成。比单纯让 AI 生成代码然后你自己去检查靠谱多了。 你说到点子上了。这其实是当前 AI 编程工具提升可靠性的核心策略——生成、验证、修复的闭环。AI 生成的代码有时候看着挺像那么回事，但实际跑起来可能有问题。有了测试用例作为自动化验证，就不用完全依赖模型的'自信'了。 最后一步呢？ 第七步是把组件渲染到预览页面，方便你在浏览器里直接看效果，然后模型会给你一个简短的工作总结。整个流程从安全检查到预览展示，一条命令全搞定。 我好奇实际跑起来效果怎么样？比如你让它生成一个圆形头像组件？ 效果挺不错的。我测试的时候故意先在项目里改了个文件不提交，然后跑命令，Gemini 果然检测到了未提交的更改，直接中止并提醒我。提交之后再跑，它就顺畅地走完了全部七步。生成的测试文件包含四个用例，覆盖了正常渲染、背景色应用、默认值、颜色校验这些场景。组件代码也很规范，用了 computed 做背景色的 class 生成，还对颜色值做了校验。 听起来质量确实不错。那基于这个实战经验，你觉得写好一个自定义命令有什么诀窍？ 我总结了几条。第一，一定要加安全防护，在破坏性操作前检查环境状态。第二，步骤要用编号列表组织，清晰明确，模型处理结构化指令的遵从度比模糊描述高很多。第三，善用 {{args}} 让命令保持灵活。第四，重要的约束条件要反复强调，特别是长提示词里，重复关键约束能显著降低模型忽略它的概率。第五，一定要包含验证环节，让模型自己检查输出质量。第六，要求模型完成后给个总结，方便你确认结果。 这六条其实不光适用于 Gemini CLI，写任何复杂提示词都用得上。 确实是这样。你看，自定义命令本质上就是把领域知识封装成了可执行的提示词。团队可以慢慢积累这些高质量的命令模板，逐步建起自己的 AI 自动化知识库。这其实代表了 AI 工具从通用助手向领域专家演进的趋势。 嗯，从一个 toml 文件开始，把你的开发经验编码化，每次执行都能保证一致的流程和质量标准。不管是组件生成、代码审查还是部署流程，都可以用这种方式自动化。我觉得这个功能值得每个用 Gemini CLI 的开发者都去试试，成本很低，但收益可能会超出你的预期。