当我们要求AI去重构一段代码时，最令人困扰的往往不是它无法完成，而是它在“理解”与“执行”之间产生了偏差。举个例子，你明确要求保留空列表的判空逻辑，它却自作主张将那段代码删除；你强调要在循环之外做边界检查，它却把检查移到了循环内部，硬生生制造出一个索引越界。这并非模型“不够聪明”，而是提示词这个“遥控器”上，关键的按钮没有锁定。

明确告知模型哪些逻辑绝对不可变动

一个核心技巧是：在提示词的开头几行，直接划定“禁止修改区域”。用三行以内的篇幅，把那些必须保留的逻辑判断、分支走向或返回值写清楚。举例来说，可以这样写：

“保留以下逻辑”
• 当 input_list 为空时，直接返回空列表
• 若 any(item is None for item in input_list)，抛出 ValueError
• 每次修改 result 之前必须调用 validate_item(item)

这一步一旦遗漏，模型很可能会认为那些防御性检查是“冗余代码”，顺手就清除了。它并没有上下文记忆去回想你上一轮强调过“这个判空逻辑很重要”。

借助具体输入输出样例锚定行为

仅仅说“保留逻辑”还不够，需要给它一个明确无误的行为锚点。这里有两个非常实用的方法：

方法一：提供最小可证伪的样例

在提示词末尾加上一句：“请确保重构后的函数对以下输入仍产生完全相同的输出”。然后给出几个边界案例：

input: [] → output: []
input: [1, None, 3] → output: ValueError
input: [2, 4] → output: [4, 8]

这样做的目的，就是把你对“正确”的定义，用最简单直接的方式锁定下来。

方法二：附带原始函数中已验证的单元测试断言

直接把 2～3 行pytest断言贴进去，比如 assert transform([]) == [] 和 assert "None" in str(transform([1, None]))。模型会把 assert 当作必须遵守的硬性契约，行为上自然会对齐。

避免使用模糊动词，替换为可验证的动作

提示词里那些“优化”、“清理”、“改进”之类的词汇，能不用就尽量不用。这些词太模糊了，模型很难把握你的具体意图。该如何替换？用带有验收标准的动词：

不要写“优化循环”，要写“将 for 循环改为列表推导式，但保持原有的短路逻辑（遇到 None 立即中断）”。
不要写“清理重复代码”，要写“把重复的 type(item) == int 判断合并到一个前置校验函数，该函数必须在任何元素处理之前执行”。
不要写“改进累加方式”，要写“用 functools.reduce 替代手动累加，初始值设为 0，且不改变浮点数精度处理方式”。

关键在于，模型无法理解“更优雅”或“更 Pythonic”——它只能匹配你给出的具体语法结构和执行顺序。 你给出的指令越精确，它的执行结果就越可控。

强制要求返回 diff 而非完整代码

在提示词的结尾加上一个强约束：“只输出 git-style diff，从原始函数开始，仅显示被修改、新增或删除的行，不要重写整个函数。每处修改后用 # WHY: xxx 注释原因”。

这样操作的好处是显而易见的：你一眼就能看出它是否误删了 if not input_list: return [] 这类“守门逻辑”。如果它返回的是整段新代码，说明提示词没有压住输出格式，需要立刻补上这条约束。