ARTICLE DETAIL

资讯详情

深耕网站视觉设计与运营推广的一线实战洞察。

项目:电商后端 API

项目:电商后端 API 项目电商后端 API【免费下载链接】gemini-cliAn open-source AI agent that brings the power of Gemini directly into your terminal.项目地址: https://gitcode.com/GitHub_Trending/gemi/gemini-cli技术栈TypeScript 5.0 / NestJS / Prisma PostgreSQL规范接口命名以 I 开头如 IUserService公共方法必须写 JSDoc错误处理统一用 Result 模式写一次之后每次提问它都自动加载不用你再开口。 更省心的是它的**三层加载机制**同一份思路、三种粒度 | 层级 | 文件位置 | 管什么 | |------|---------|--------| | 全局 | ~/.gemini/GEMINI.md | 你的个人偏好所有项目生效 | | 项目 | 项目根目录 GEMINI.md | 团队规范跟着代码库进版本控制 | | 模块 | 子目录里的 GEMINI.md | 只在该目录被访问时才按需加载 | 第三层是我个人最喜欢的细节它叫 JIT 上下文。比如 packages/core/ 下单独放一份说明这个包禁止直接 import React平时不占上下文只有 AI 真的碰了这个目录才会读到——**规则跟着代码走而不是全局塞满**。会话底部会显示当前加载了几个上下文文件一眼能确认它读懂了多少背景。 [官方文档中对这部分的完整说明](https://link.gitcode.com/i/cea65ab3a07ac3d3ac3deae8a69b6147)值得一读这里不展开了。 ## 别急着放权Plan Mode 是终端 AI 的刹车片 在终端里跑 AI 最大的顾虑就一句话**它会不会偷偷改我的代码** Gemini CLI 的态度是默认就开着刹车。Plan Mode 是一个只读环境AI 可以翻遍整个项目、给方案、做权衡但一个字节都不许动。两种用法 bash # 启动时直接进入 Plan Mode gemini --approval-modeplan 审查这个鉴权重构重点看向后兼容性交互中也可以随时按ShiftTab在三种审批模式间切换Default → Auto-Edit → Plan。我的习惯很固定陌生代码库先 Plan 后动手。先看它的调研结论认可了再放行比事后 review 一堆 diff 轻松得多。把流程写进技能Skills 才是团队一致性的答案GEMINI.md 解决它知道什么Skills 解决它按什么流程干。一个技能就是一个自包含的目录核心是一份SKILL.md。比如你团队有一套代码审查标准可以写成# .gemini/skills/code-review-expert/SKILL.md # 审查标准 - 优先检查安全漏洞SQL注入、XSS - 检查 API 端点是否都有鉴权 - 错误处理必须完整日志级别要合理它的生命周期分五步会话开始时 CLI 扫描技能目录并注入名称和描述 → AI 判断当前任务匹配时主动调用activate_skill→界面弹确认提示告诉你它要激活什么技能、要访问哪个目录→ 你批准后正文才进上下文 → 按流程执行。几个容易忽略的点按需加载技能库可以很大但只有匹配时才把正文塞进上下文不会挤占窗口技能分级内置技能 扩展技能 用户技能~/.gemini/skills/ 工作区技能.gemini/skills/同名时高优先级覆盖低优先级——所以团队共享的技能放项目里个人私货放家里管理命令会话内/skills list看清单/skills link ./my-skills链接本地技能目录。技能细节可以看 skills 文档配套还有技能编写最佳实践。最后一步让它进 CI无人值守也能跑前三步都是人盯着用。真正拉开差距的是 headless 模式——没有交互界面结构化输出脚本直接消费# 非交互执行一条任务JSON 输出 gemini -p 检查这个 diff 是否有安全问题 --output-format json【免费下载链接】gemini-cliAn open-source AI agent that brings the power of Gemini directly into your terminal.项目地址: https://gitcode.com/GitHub_Trending/gemi/gemini-cli创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
返回列表