Gemini 3.5 Flash 在开发日常里的几个实用用法

最近在整理项目文档、排查启动问题、补测试场景时，我用了一段时间 Gemini 3.5 Flash。体验入口可以从库拉进入，ouai.me。整体感觉是，它更适合放在开发过程里做辅助，比如帮忙理清代码逻辑、整理报错信息、生成文档初稿，而不是直接把整个功能交给它完成。

如果你平时会接触后端服务、前端工程、接口文档、部署脚本、测试用例这些内容，可以把 Gemini 3.5 Flash 当成一个顺手的开发工具来用。它比较适合处理“信息比较散，但需要整理清楚”的工作，比如把日志整理成排查步骤，把代码片段解释成流程，把改动摘要整理成 PR 描述。

先说使用感受

我更愿意把 Gemini 3.5 Flash 放在这些环节里：

• 看项目目录；
• 理解旧代码；
• 分析报错信息；
• 整理接口说明；
• 生成测试场景；
• 写 README 初稿；
• 整理版本说明；
• 优化技术提问；
• 梳理 Review 检查项。

这些事情看起来都不大，但在日常开发中经常遇到。
尤其是接手已有项目时，很多时间并不是花在写新代码上，而是花在理解现有逻辑、查配置、看日志、补文档上。

Gemini 3.5 Flash 在这些场景里比较适合做“第一轮整理”。
它可以先把内容变成结构化信息，然后开发者再继续判断、修改和确认。

一、接手项目时，先看清目录结构

很多项目第一次打开时，目录大概是这样：

.
├── app
├── config
├── internal
├── pkg
├── scripts
├── docs
├── test
├── examples
└── README.md

刚接手时，最容易遇到的问题是：

• 服务入口在哪里；
• 配置文件在哪里；
• 公共模块放在哪里；
• 测试怎么运行；
• 脚本分别做什么；
• 文档是否完整。

这时候可以先把目录结构交给 Gemini 3.5 Flash：

下面是一个项目目录结构。
请说明每个目录可能承担的职责，并给出新成员的阅读顺序。
要求偏工程实践，不要写成宣传文案。

如果你要排查某个具体问题，可以继续补充：

我想了解服务启动和配置加载流程，请判断应该优先查看哪些目录和文件。

这样得到的结果一般会按模块说明：

• app 可能是应用入口；
• config 可能存放配置模板；
• internal 可能是业务实现；
• pkg 可能是可复用模块；
• scripts 可能是构建或部署脚本；
• docs 可能是项目说明；
• test 可能是测试用例。

这一步不一定完全准确，但可以帮助你先建立一个项目地图。
后面再结合 README、启动脚本和实际代码确认，会省不少时间。

二、读代码时，先让它解释流程

很多代码不好读，不是因为语法难，而是因为上下文太多。

比如一段服务启动逻辑，可能包含：

• 读取配置；
• 初始化日志；
• 连接数据库；
• 加载缓存；
• 注册路由；
• 启动定时任务；
• 处理退出信号。

如果直接逐行看，很容易被细节打断。

可以这样问：

请解释下面这段服务启动代码。
重点说明：
1. 整体流程分成哪几步；
2. 每一步依赖哪些配置；
3. 哪些地方可能失败；
4. 哪些地方适合补日志或测试。

如果代码比较长，不建议一次贴完整文件。
可以按函数拆开：

先只解释 initConfig 函数。
只说明输入、输出、主要判断和异常情况，不要扩展到其他模块。

这种方式比较稳。
先看流程，再看细节，最后再结合项目里的测试和日志确认。

三、排查报错时，让它给验证步骤

本地启动项目时，经常会遇到一些常见问题：

port already in use
config file not found
connection refused
permission denied
module not found
version mismatch
timeout

这些报错本身不一定复杂，但具体排查时要结合环境、命令、配置和依赖。

比较好用的提问方式是：

我在本地启动服务时遇到问题。

环境：
- Ubuntu 22.04
- JDK 17
- Maven
- 使用本地 MySQL
- 执行命令：mvn spring-boot:run

报错信息：
xxx

请按可能性从高到低列出排查步骤。
每一步说明如何验证，以及验证失败后下一步看哪里。

重点是让它写出“如何验证”。
比如它可能会建议：

• 检查端口是否被占用；
• 确认配置文件是否存在；
• 检查数据库服务是否启动；
• 确认连接参数是否正确；
• 检查依赖是否下载完整；
• 确认 JDK 版本是否符合项目要求；
• 查看启动命令是否读取了正确 profile；
• 检查本地环境变量是否生效。

这样你拿到的不是一句简单结论，而是一条排查路线。
后面可以按步骤逐个验证，效率会高一些。

四、整理技术问题，减少沟通成本

在团队协作或技术社区发问题时，描述越清楚，别人越容易帮你判断。

不太好处理的问题通常是这样：

项目启动失败，帮忙看看。

这句话信息太少，别人很难继续分析。

一个比较完整的问题，至少应该包含：

• 问题现象；
• 复现步骤；
• 期望结果；
• 实际结果；
• 环境信息；
• 报错日志；
• 已尝试方法；
• 最近是否有相关改动。

可以把零散信息交给 Gemini 3.5 Flash 整理：

请把下面的信息整理成技术社区提问内容。
要求包含问题现象、复现步骤、期望结果、实际结果、环境信息、报错日志和已尝试方法。
语气客观、简洁，适合开发者社区阅读。

比如原始记录是：

Ubuntu 22.04
JDK 17
main 分支
启动后提示数据库连接失败
确认过 MySQL 是启动的
昨天合过一个配置相关改动

可以整理成：

### 问题现象

在 Ubuntu 22.04 环境下，从 main 分支启动服务时失败，日志提示数据库连接失败。

### 复现步骤

1. 拉取 main 分支最新代码；
2. 确认本地 MySQL 已启动；
3. 执行项目启动命令。

### 期望结果

服务正常启动，并成功连接本地 MySQL。

### 实际结果

服务启动失败，日志提示数据库连接失败。

### 环境信息

- OS: Ubuntu 22.04
- JDK: 17
- Branch: main
- Database: MySQL

### 已尝试

- 确认 MySQL 服务已启动；
- 重新执行启动命令。

### 补充信息

昨天合入过一个配置相关改动，暂未确认是否有关。

这样的提问更容易被理解，也方便后续定位问题。

五、PR 描述别只写一句 fix

很多项目里的 PR 描述比较简单：

fix bug
update docs

短期看没什么问题，但过一段时间再回头看，很难知道当时到底改了什么。

一份清楚的 PR 描述可以包含：

• 背景；
• 主要改动；
• 测试情况；
• 影响范围；
• 文档是否同步；
• 是否有关联问题。

可以让 Gemini 3.5 Flash 帮你整理初稿：

下面是我的修改摘要，请整理成 PR 描述。

修改内容：
1. 修正配置文件不存在时的提示信息；
2. 增加默认配置示例；
3. 补充配置解析相关单元测试；
4. 更新 README 中的配置说明。

要求：
- 简洁；
- 适合工程团队阅读；
- 不要夸张表达。

整理后可能是：

### 背景

当前项目在配置文件不存在时提示不够明确，新成员或首次使用者不容易定位问题。

### 主要改动

- 修正配置文件不存在时的提示信息；
- 增加默认配置示例；
- 补充配置解析相关单元测试；
- 更新 README 中的配置说明。

### 测试情况

- 本地单元测试通过；
- 手动验证缺少配置文件时的提示内容。

### 影响范围

- 不改变现有配置读取逻辑；
- 不影响已有配置格式。

拿到这版之后，再根据实际改动补充或删减。
它适合帮你把内容排整齐，但最终描述还是要自己确认。

六、Review 前做一次自查

提交代码前，如果能先自查一遍，Review 时会少很多来回沟通。

可以把改动摘要交给 Gemini 3.5 Flash：

下面是我的代码改动摘要。
请从代码 Review 角度帮我检查可能遗漏的地方：

1. 命名是否清楚；
2. 错误处理是否完整；
3. 是否需要补测试；
4. 是否影响已有接口或配置；
5. 文档和示例是否需要同步更新；
6. 是否存在重复逻辑；
7. 是否需要补充日志。

它可能会提醒：

• 新增配置项没有写进 README；
• 修改默认值后没有说明影响范围；
• 异常路径缺少测试；
• 错误提示没有包含具体配置项；
• 示例代码仍然是旧写法；
• 日志不够清楚，不方便排查。

这些提醒不一定全部适用，但可以当成提交前 checklist。
尤其是小改动，很容易漏掉文档、测试或兼容性说明。

七、补测试时，先列场景

写测试用例时，最容易漏的是异常流程和边界条件。

以配置读取为例，除了正常读取，还应该考虑：

• 配置文件不存在；
• 配置文件为空；
• 字段缺失；
• 字段类型错误；
• 默认值是否生效；
• 环境变量是否覆盖配置；
• 不同环境配置是否正确加载；
• 旧配置是否兼容；
• 错误提示是否清楚。

可以这样问：

我修改了一个配置读取函数。

函数行为：
1. 读取配置文件；
2. 支持默认值；
3. 支持环境变量覆盖；
4. 配置错误时返回明确提示；
5. 需要兼容旧配置。

请帮我列出测试场景。
要求按正常流程、异常流程、兼容性、边界条件分类。

如果是 Java 项目，可以继续问：

请按 JUnit 5 的结构整理测试用例名称和断言重点。
不需要生成完整代码。

如果是 Go 项目，可以问：

请整理成 table-driven tests 的用例列表。
只需要用例名称、输入条件、期望结果。

如果是前端项目，可以问：

请按 Vitest 的结构整理测试用例名称和断言重点。

我更建议先让它列测试场景，而不是直接写完整测试代码。
因为测试怎么写，还是要看项目里的实现方式、Mock 策略和断言习惯。

八、文档更新可以先出初稿

很多项目的问题不是代码没改，而是文档没同步。

常见情况包括：

• 新增配置项，但 README 没更新；
• 启动命令改了，但示例还是旧的；
• 接口字段变化，但说明没改；
• 部署步骤调整后没有同步；
• 版本说明过于简单。

Gemini 3.5 Flash 适合先生成文档初稿。

比如新增配置项：

server.port：服务端口，默认 8080
log.level：日志级别，默认 info
cache.enabled：是否开启缓存，默认 false

可以这样问：

请把下面的配置项整理成 README 中的配置说明表格。
字段包括：配置项、说明、默认值、备注。

输出可能是：

| 配置项 | 说明 | 默认值 | 备注 |
| --- | --- | --- | --- |
| `server.port` | 服务监听端口 | `8080` | 可根据部署环境调整 |
| `log.level` | 日志级别 | `info` | 常见值包括 `debug`、`info`、`warn`、`error` |
| `cache.enabled` | 是否开启缓存 | `false` | 开启前需确认缓存服务可用 |

之后再根据实际情况补充示例、限制条件和注意事项。

九、版本说明要让使用者看得懂

版本说明如果只写：

fix bugs
update docs

使用者很难判断这次更新是否和自己有关。

可以把提交摘要整理成版本说明：

下面是本次版本的提交摘要。
请整理成版本说明。

要求包含：
1. 新增；
2. 修复；
3. 文档更新；
4. 影响范围；
5. 升级注意事项。
语气客观，不要营销化表达。

整理后可以是：

## 新增

- 增加配置文件缺失时的提示信息；
- 增加默认配置示例。

## 修复

- 修复部分环境下启动失败时提示不明确的问题。

## 文档更新

- 更新 README 中的配置说明；
- 补充本地启动常见问题。

## 影响范围

- 不改变现有配置格式；
- 不影响已有启动命令。

## 升级注意事项

- 正常升级即可，无需额外调整配置。

这类内容不需要太长，重点是说清楚改了什么、影响哪里、是否需要额外处理。

十、把一次排查沉淀成知识库

团队里有些问题会反复出现：

• 本地启动失败；
• 数据库连接失败；
• 依赖版本不一致；
• 配置文件缺失；
• 构建脚本失败；
• 测试环境和本地环境不一致。

如果每次都靠群里问，成本会越来越高。
解决完一次问题后，可以把排查过程整理成文档：

请把下面的问题排查记录整理成团队知识库文档。

要求包含：
1. 问题现象；
2. 适用场景；
3. 可能原因；
4. 排查步骤；
5. 解决方法；
6. 后续预防建议。

这样下次遇到类似问题时，可以先查文档。
对团队来说，这比一次性回答更有价值。

十一、使用时注意输入内容

在开发场景使用工具时，输入内容要控制好。

不建议直接输入：

• 账号口令；
• 访问凭据；
• 内部接口地址；
• 未公开配置；
• 私有项目完整代码；
• 客户数据或业务数据；
• 不适合公开的日志内容。

如果只是分析报错，可以先做替换：

DB_HOST=xxx
DB_PORT=3306
TOKEN=xxx
INTERNAL_API=xxx

也可以只保留必要上下文：

本地服务连接数据库失败，配置已填写，启动时报错如下：
...

这样既能保留排查所需的信息，也能减少不必要的信息暴露。

最后

Gemini 3.5 Flash 更适合放在开发日常里，处理那些高频、零散、需要整理上下文的工作。

比如：

• 看项目结构；
• 理解代码流程；
• 整理报错排查步骤；
• 组织技术提问；
• 生成 PR 描述初稿；
• 做 Review 前检查；
• 补测试场景；
• 更新 README；
• 整理版本说明；
• 沉淀团队知识库。

它不是用来替代工程判断的，而是帮助开发者把信息先整理清楚。
如果使用方式合适，很多重复性的文字整理、问题梳理和文档初稿工作，都可以处理得更顺一点。

我的建议是：不要一开始就让它完成一个完整功能，先从解释代码、整理日志、列测试场景、写文档初稿这些小场景用起。这样更容易控制质量，也更符合日常开发的真实节奏。