GEMINI.md配置指南：三级作用域定制你的AI编码助手

最近在用Gemini CLI写代码的时候，我发现一个特别有意思的现象——很多人装好工具就直接开干了，结果AI生成的代码风格跟自己的项目格格不入。其实中间漏了一个关键步骤，就是配置GEMINI.md文件。今天咱们就来好好聊聊这个东西。 对，这个文件其实特别重要，但确实容易被忽略。你可以把它理解成给AI下达的一份「项目说明书」。它是一个Markdown格式的指令文件，每次你跟Gemini CLI对话的时候，这个文件的内容会自动注入到上下文里。所以AI就知道你的项目用了什么框架、什么技术栈，甚至你个人的编码习惯是什么样的。 嗯，说到这个，我注意到不只是Gemini在用这种方式。Cursor有.cursorrules，GitHub Copilot有copilot-instructions.md，Claude Code有CLAUDE.md。这算是一种行业趋势了吧？ 没错，这其实是「以文档驱动AI行为」的模式，正在成为行业标准。你想啊，以前我们每次跟AI对话，都得反复说「我用的是Vue、不要给我加分号、CSS别用Tailwind类名」，特别烦。现在把这些固化成一个版本可控的项目文件，本质上就是System Prompt的工程化延伸。而且Markdown这个格式选得很巧妙——人能读懂，大语言模型也能高效解析成结构化指令。 那具体怎么创建这个文件呢？总不能从零开始手写吧，尤其是已有代码的项目。 这就是Gemini CLI做得比较贴心的地方了。你在聊天窗口里输入一个斜杠命令 /init，它就会自动扫描你的整个代码库，识别出框架、CSS库、目录结构、数据流这些信息，然后帮你生成GEMINI.md。 等一下，这个扫描过程靠谱吗？毕竟AI有时候会「幻觉」嘛。 这个问题问得好。其实 /init 这种斜杠命令跟你平时跟AI聊天不一样，它触发的是CLI内部预定义的工作流，是确定性的程序行为，不是模型的概率性输出。所以扫描结果的可靠性是有保障的。而且还有一层安全机制——它分析完之后不会直接写入文件，而是先给你展示一个diff，就是差异对比，红绿色标注哪些是新增的内容，让你审查确认之后才会真正写入。 这个「先展示再确认」的设计我觉得挺关键的，有点像Git里看diff的感觉。 对，这就是所谓的Human-in-the-Loop，人在回路中。AI可以提建议、生成方案，但最终执行权在人手里。你想，如果AI不受控地随便改文件，万一破坏了现有代码或者引入安全漏洞，那就麻烦了。确认的时候你有三个选项：允许一次、当前会话始终允许、或者拒绝并提修改意见。 好，那自动生成的内容大概长什么样？能举个例子吗？ 比如说一个Nuxt 3的项目，Gemini会自动识别出这是一个Web应用，用的Nuxt 3框架，测试用的VTest，组件放在app/components目录下，页面在pages目录，样式方案是单一CSS文件。如果项目比较简单，生成的内容也会比较精简。但这只是起点，你完全可以手动补充。 手动补充的部分一般写什么呢？ 主要是个人编码偏好。比如你不喜欢JavaScript里加分号，或者虽然项目用了Tailwind但你不想在模板里堆一大堆类名，又或者你希望组件保持小而模块化、用相对导入路径、尽量少引入第三方依赖——这些都可以写进去。关键是把你的习惯明确告诉AI，这样它生成的代码风格才能跟你保持一致。 不过这里有个问题我比较好奇——这个文件的内容是要占用上下文窗口的吧？写太多会不会有问题？ 你看，这就是很多人容易踩的坑。虽然Gemini 2.5 Pro有100万token的上下文窗口，空间是很充裕的，但文件内容还是应该保持精炼、高信息密度。冗余的描述不光浪费token预算，更关键的是会稀释关键指令的权重。打个比方，你给新同事写了一份十页的开发规范，他大概率记不住重点；但如果是一页纸的要点清单，执行效果反而更好。所以你会发现自动生成的内容都是结构化的列表，而不是长篇大论。 嗯，这个类比很形象。那我还想聊一个我觉得特别实用的设计——三级作用域。 对，这个设计确实很灵活。第一级是项目级，就是放在项目根目录的GEMINI.md，对整个项目生效，最常用。第二级是目录级，你可以在子目录里再创建GEMINI.md，比如在tests目录下专门定义测试的编写规范和断言风格，在pages目录下定义页面组件的生成规范。第三级是全局级，放在用户主目录的.gemini隐藏文件夹里，对你所有的项目都生效。 这个有点像.gitignore或者.eslintrc的多级配置机制对吧？子目录的配置可以覆盖或补充上层的。 完全正确，就是经典的配置继承模式。多个层级的GEMINI.md同时存在时，内容会被合并注入上下文。这在Monorepo架构里特别有价值——根目录定义通用的TypeScript规范和Git提交约定，前端子包声明自己用React，后端子包声明用Express，各管各的，互不干扰。 那全局级的一般放什么内容比较合适？ 跨项目通用的东西。比如你所有项目都不用分号，或者你希望AI回复的时候用中文注释，这种放全局就很合适。另外那个.gemini文件夹里还能管理MCP服务器配置、扩展和聊天会话这些东西。MCP就是模型上下文协议，通过它Gemini CLI可以连接数据库、API测试工具这些外部能力，把AI的能力从代码生成扩展到整个开发工作流。 最后还有一个容易被忽略的点——编辑完GEMINI.md之后，是不是还得做点什么？ 对，这个很关键。保存之后要在CLI里执行 /memory refresh，让它重新扫描所有GEMINI.md文件，把最新的指令加载到当前会话。否则你改了半天，AI还在用旧的配置。而且这个文件不是创建完就丢在那里不管了，随着项目演进——换了技术栈、调整了架构——都应该同步更新，不然AI就会基于过时的信息生成代码。 所以总结一下，GEMINI.md本质上就是你跟AI之间的一份「编码契约」。用 /init 自动生成基础配置，手动补充个人偏好，利用三级作用域做精细化管理，再配合 /memory refresh 保持同步。把这套流程跑通了，AI生成代码的质量和一致性确实能上一个台阶。 嗯，说白了就是你在前期花十分钟把这个文件配好，后面能省掉大量反复纠正AI的时间。这笔账怎么算都划算。