Gemini提示词精华：旧代码整理为文档并自动生成检查清单

接手遗留代码时，多数开发者习惯直接丢给Gemini一句“写注释”。这种做法远不够深入——AI默认不会审查函数是否具备单元测试、参数验证是否完整、异常路径是否全面覆盖。单纯让它生成注释，无异于盲目搜索，关键缺陷极易被遗漏。

关键在于，引导它遵循一套严谨的“缺陷排查清单”逐行扫描。以下是一套经过生产验证的方法论，能让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，就证明这个判断缺乏依据。

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