当接手遗留代码时，许多开发者习惯直接让 Gemini 生成注释或说明。然而，这种做法远远不够——AI 默认不会主动检查函数是否具备单元测试、参数校验是否完整、异常路径是否全面覆盖等关键隐患。单纯依赖其生成注释，犹如大海捞针，真正的缺陷很容易被遗漏。

关键在于，需要让 Gemini 遵循一套严谨的“侦查清单”进行逐行扫描。以下是一套经过实战验证的方法论，能够帮助 Gemini 自动识别旧代码中的潜在问题、逻辑断层和维护风险，从而提升代码质量审查效率。

让Gemini高效识别代码中的潜在检查点

第一步：在提示词开头明确限定检查维度，避免模型自由发散。使用编号列表强制输出结构化内容：

① 请逐行扫描以下代码，仅针对以下6类问题进行标记：
　　- 缺少输入校验（如未判空、未校验长度、未做类型转换）
　　- 异常处理缺陷（try块覆盖不全、catch后吞异常、finally中可能抛新异常）
　　- 硬编码值（含路径、URL、状态码、超时毫秒数等不可配置项）
　　- 资源泄漏风险（文件流/数据库连接/线程未显式关闭或未进try-with-resources）
　　- 并发安全隐患（共享变量无同步、静态集合非线程安全、时间戳用new Date()）
　　- 业务逻辑断点（if分支无else兜底、switch缺default、边界条件未覆盖）

第二步：要求每项检查必须包含三个信息点：代码位置（行号及缩进层级）、具体问题描述、修复建议。注意，修复建议不能仅笼统地说“应加校验”，必须具体到代码级别，例如“建议在第12行前插入 if (input == null) throw new IllegalArgumentException("input cannot be null");”。

第三步：禁止输出任何解释性文字、背景说明或总结段落。仅输出纯检查项表格，包含以下字段：【问题类型】【行号】【代码片段】【风险等级（高/中/低）】【修复建议】。此处必须增加强调：【风险等级必须依据实际影响判定，高风险项指可能直接引发服务崩溃、数据错乱或权限越界】。

通过对比法触发深度代码校验

方法一：提供同一功能的新旧两版本代码，指令为：“请对比A版（旧版本）与B版（新版本），列出A版中B版已修复而A版仍存在的所有检查项，格式同上表。重点标记B版通过增加防御性判断、拆分长函数、提取常量等方式规避的问题。”

方法二：提供接口定义文档（如OpenAPI/YAML）以及对应实现代码，指令为：“请将以下代码与接口文档逐字段比对，检查是否满足：所有请求体字段均被正确解析、所有响应体字段均被赋值、HTTP状态码返回与文档一致、错误码枚举值无硬编码拼写。仅输出不一致项。”

方法三：上传代码的同时，附上该模块最近3个月的线上错误日志关键词（例如“NullPointerException”“TimeoutException”“DuplicateKeyException”），指令为：“请定位代码中可能导致上述错误日志的实际路径，并标注对应的检查项。若某异常未在代码中被捕获或记录，则视为高风险项。”

强制模型输出判断依据以验证准确性

当Gemini输出检查项后，立即追加追问：“请对第3条检查项（硬编码URL）说明判断依据：该URL是否在项目其他配置文件中存在对应配置项？是否被测试用例覆盖？若存在，请指出配置项key名；若不存在，请说明该URL在生产环境变更时会导致什么后果。”

这一步能有效筛选出模型凭空猜测的假阳性结果。许多AI会将合法常量误判为硬编码，但只要它无法指出配置中心中对应的key，就说明该判断缺乏依据。

完成上述任一方法三的追问验证后立即结束。