Gemini提示词优化：不改业务逻辑的代码技巧

利用AI优化代码时，最大的风险在于模型自作主张合并看似冗余的if分支。优化后的代码虽能通过编译，但业务语义已被扭曲，隐含的边界条件也可能随之消失。凡是经历过线上维护的开发者，对此都心有余悸。

类似问题同样适用于Gemini。核心原则只有一个：明确划定边界——向模型清晰申明哪些是业务红线，哪些是可优化区域。

锁定业务逻辑不可变

提示词的首句就必须明确约束：所有原生if/else、switch分支、循环终止条件、异常抛出点、外部API调用顺序及参数结构，均属于业务逻辑的刚性约束，严禁任何形式的合并、拆分、提前返回或逻辑等价替换。

因为模型注意力机制会优先处理指令的开头部分。若约束后置，模型很可能先入为主地将一个“看似多余”的判空视为可优化项——而该判空可能暗藏下游权限校验失败的日志埋点，从而导致优化引入隐性缺陷。实践表明，若首句漏写或延后，后续多条补充约束也难以纠正模型行为。

指定可优化的维度

光说不让做什么还不够，还需明确告知哪些维度可以调整。

方法一：性能优化
将String.format替换为StringBuilder链式拼接；把循环内重复计算的表达式外提；使用Collections.singletonList取代new ArrayList<>(Collections.singleton(x))。

方法二：可读性改进
将魔法值替换为具名常量；为复杂布尔表达式提取业务语义变量名（如isEligibleForRefund = order.status == PAID && order.ageDays() <= 30）；用Optional.ofNullable().map().orElse()替代多层null检查。

方法三：安全与健壮性
字符串比较前使用Objects.equals(a, b)；对传入的Collection参数包裹Collections.unmodifiableList；将硬编码的超时毫秒数改为带单位的Duration.ofSeconds(30)。

这三类优化相对安全，模型在此范围内通常不会触及业务语义。但切记，避免笼统地要求“优化一切”，否则模型很可能从业务语义层面进行非预期的改写。

提供最小化上下文样例

仅靠约束语句往往不够稳固。更有效的方法是提供具体的“输入→输出”契约。在附上待优化代码片段时，必须同时包含以下三项：

① 输入：用户提交的JSON，例如{"userId": "U123", "items": [{"sku": "A01", "qty": 2}]}

② 输出：期望的HTTP 200响应，例如{"orderNo": "ORD-20240521-XXXXX", "totalAmount": 199.0}

③ 关键不变量：items为空时必须返回400；任一item.qty ≤ 0时必须抛出IllegalArgumentException；userId必须原样透传至下游日志。

这三项缺一不可。缺少它们，模型可能认为空items分支“没用”而合并到主流程，并兜底返回默认订单号。表面上无报错，但接口契约已被篡改。

实际操作很简单：将接口文档中的“请求体”“响应体”“错误码”三栏直接复制进去即可。省时省力，效果最佳。

来源：互联网