Gemini 编程工作流

配置成功后，真正有用的结果是可审查的代码与验证记录。下面以现有仓库为例，用 Gemini 完成一次小改动；编辑器路线见 VS Code 配置，已有 CLI 用户见 Gemini CLI 配置。

#1. 检查仓库状态

在目标项目的终端运行：

git status --short
git diff --stat

记录已有修改。告诉模型保留这些改动，并给出明确目标，比如“修复日期格式化在空字符串输入时的错误”，而不是“优化整个项目”。

#2. 先让它读，再让它写

在 Cline 新任务或 Gemini CLI 中输入：

只读检查当前仓库，先不要修改文件。
找出项目的包管理器、启动命令、相关测试，以及日期格式化的实现和调用位置。
已有未提交改动请保留。
根据实际文件说明原因，再给出最小修改计划。

审查它引用的文件和命令是否真实存在。不要接受模型根据常见项目结构猜出来的路径。Cline 可先在 Plan 模式讨论，确认后切换 Act，并核对两个模式都使用 Passion8 配置。

#3. 提供稳定的项目说明

在 Cline 中把构建命令、语言、验收约束写入项目规则，具体方法见 Cline 文档。Gemini CLI 则可在仓库根目录使用 GEMINI.md：

# Project instructions

- Read existing code and tests before editing.
- Preserve unrelated working tree changes.
- Use the package manager specified by the lockfile.
- Reuse existing helpers and avoid unrelated refactors.
- Run relevant existing checks after the change.
- Report the exact commands, results and any unverified behavior.

CLI 执行 /memory show 确认已加载；改完规则执行 /memory refresh。不要假设 Cline 会自动读取 GEMINI.md，不同客户端的规则入口不同。

#4. 限定修改和测试范围

确认计划后输入：

按已确认计划修复这个边界条件。
只修改相关实现和必要的现有测试，不升级依赖，不改其他模块。
先展示修改差异，再执行该项目实际存在的相关检查。

逐次批准文件写入和命令执行。遇到数据库迁移、部署或与任务无关的依赖安装，应先回到计划说明必要性。

#5. 自己验收

git diff --check
git diff --stat
git diff

确认实现、测试、文件范围与目标一致。检查测试输出是否真的执行成功，以及是否有跳过项。没有现成测试的项目应说明采用了什么人工验证，不要把“完成了”当作测试通过。

#上下文与费用

让模型先用文件名和局部搜索定位，再读取相关文件，避免每次发送整仓库。切换目标后新开会话；长会话的文件内容与工具结果也会占用 token。调用记录与费用看 Passion8 控制台，客户端估算仅用于辅助。

如果工具失败，先区分配置问题和模型能力：普通文本请求不能成功时回到 API 接入；只有工具失败时检查 Cline 格式、账号渠道和具体错误。Google 搜索或托管 Grounding 并不是文件读取的必需条件。

#核对来源

核对日期：2026-10-11。

• Gemini CLI configuration and contextual memory
• Gemini CLI IDE integration