写找代码bug的AI提示词有啥技巧？

找代码 bug 的 AI 提示词，核心就一句话：别把 AI 当搜索引擎，要把它当成一个刚入职、能力很强但完全不了解你项目的实习生。 你给的信息越像“项目交接文档”，它返回的答案就越像“资深架构师的 code review”。技巧不在于咒语，而在于你如何组织上下文和定义“正确”的标准。

一、为什么你写的提示词 AI 总是“答非所问”？

大多数人的提示词是“帮我看看这段代码哪里错了”，然后贴 500 行代码。这相当于你给医生发了一张全身 X 光片，但没说“我头疼”。AI 只能基于概率给你“最常见的几种错误”，而不是“你这个特定场景下的 bug”。

真正的技巧是：把“模糊的求助”变成“精确的故障报告”。你需要告诉 AI 三件事：预期行为是什么、实际行为是什么、以及你怀疑的边界条件。没有这三要素，AI 只能瞎猜，你只能得到一篇看似专业但毫无用处的“废话文学”。

二、核心技巧：用“角色 + 任务 + 约束 + 输出格式”四段式结构

我测试过几十种写法，最高效的模板是下面这个四段式框架。它不是魔法，但它强制你提供 AI 做“根因分析”所需的全部信息。

• 角色设定（给他一个“岗位”）：不要只说“你是程序员”，要说“你是一个有 10 年经验的 Python 后端工程师，擅长调试异步并发问题”。这能激活 AI 模型里对应的知识子网络。
• 任务描述（说清“做完”的标准）：不要只说“找 bug”，要说“找出导致 list index out of range 在特定数据集下偶发出现的根因，并给出可复现的修复方案”。
• 上下文输入（这是最关键的一步）：必须包含错误堆栈（哪怕只有一行）、输入数据的样例（脱敏）、预期输出 vs 实际输出。如果代码超过 100 行，请先自己精简出最小复现单元（MRE），这本身就是一种调试能力。
• 输出格式约束（控制答案的“形状”）：要求它“先给出根因假设，再列出验证步骤，最后给出修改后的完整代码块”。这能防止它直接甩给你一段重写的代码，而你根本不知道改了什么。

一个反面教材和正面教材的对比

看出区别了吗？正面写法里包含了“预期行为”和“约束条件”。AI 不再是猜，而是做“差异分析”。

三、进阶技巧：让 AI “自己生成测试用例”来反推 bug

当你完全没头绪时，试试这一招：不要让它找 bug，让它“生成能暴露 bug 的测试用例”。这利用了 AI 的模式识别能力——它见过太多“边界值、空值、超大值”导致的崩溃。

1. 提示词示例：“这是函数 calculate_discount(price, user_level) 的代码，请列出 10 个最可能让这段代码逻辑出错的输入组合，并说明每个组合期望的输出是什么。不要修改代码，只生成测试用例。”
2. 原理：当你把“找 bug”变成“找反例”，AI 的搜索空间会从“所有可能的错误”缩小到“输入空间中的奇异点”，命中率会大幅提升。很多时候，AI 列出的测试用例里，你自己就能看出问题在哪。

四、针对不同 AI 工具的差异化提示词策略

不是所有 AI 都吃同一套提示词。你需要根据工具的特性调整“喂食”方式。

如果你用的是我目前最常用的 ChatGPT 或 Claude，建议开启“联网搜索”或“代码解释器”功能，它们能获取最新依赖包的文档，避免因版本差异导致的误报。

五、高阶心法：把“找 bug”变成“解释逻辑”

这是我最想分享的一个反直觉技巧：当 bug 极难找时，不要问“哪里错了”，而是问“这段代码每一步在做什么，特别是第 X 行到第 Y 行”。

AI 在“逐行解释”时，会被迫进行逻辑推演，而这个推演过程往往会暴露它“理解”和你“意图”之间的偏差。很多次，我让 AI 解释一段递归函数的执行流程，它解释到第三层时突然说：“等等，这里有个问题，当 n=1 时，这个分支会访问 list[-1]，这可能是 bug。”——它自己就发现了。

这个技巧的本质是：利用 AI 的“自回归生成”特性，让它在生成解释的过程中重新审视逻辑链。你不需要自己盯代码，你只需要盯 AI 的解释是否通顺。

六、实操模板（可直接复制修改）

最后给你一个我常用的“万能模板”，它综合了上面所有技巧。把【】里的内容替换成你的实际信息即可。

【角色】你是一个精通【语言】的资深调试专家，尤其擅长【领域，如：网络编程/算法优化】。
【任务】请帮我定位以下代码中导致【具体现象，如：内存泄漏/偶发崩溃】的根因。我预期这段代码应该【描述预期行为】，但实际它【描述实际行为】。
【上下文】
– 错误堆栈（如有）：【粘贴关键几行】
– 输入数据样例（脱敏）：【粘贴一个能触发问题的样例】
– 相关代码（精简到 50 行以内）：
“`[代码块]“`
【约束】请先列出 2-3 个最可能的根因假设，并说明你为什么优先考虑第一个。然后针对第一个假设，给出具体的验证步骤（比如加日志的位置）。最后，如果确认是 bug，请给出修复后的完整函数，并解释修改的原理。

七、避坑指南：这些做法会让 AI 变“蠢”

• 不要贴超长代码：超过 200 行，AI 的注意力会分散，且容易产生“幻觉”。务必精简到最小复现。
• 不要用“肯定”句式问“是不是 xxx bug”：这会导致 AI 迎合你的预设。要用“有哪些可能的原因”这种开放式提问。
• 不要忽略“环境信息”：Python 版本、第三方库版本、操作系统，这些在提示词里一句话带过，能避免 AI 给出基于过时 API 的建议。
• 不要忘记“轮询确认”：AI 给出答案后，追问一句“这个修复方案在极端情况下（比如输入为 None 或超大整数）是否仍然安全？”这能帮你发现它的盲区。

八、总结：提示词是死的，思维是活的

最后说句掏心窝的话：AI 调试工具再好，也替代不了你对自己代码的理解。提示词技巧的本质是“逼你把自己脑子里的隐性知识显性化”。当你写不出清晰的“预期行为”时，往往意味着你还没想清楚这个函数到底该干嘛——这时候 AI 帮不了你，你得回去看需求文档。

把 AI 当成一个可以随时打断、不怕丢脸、且知识库比你大的结对编程伙伴。你给它越具体的“症状描述”，它回给你的“诊断书”就越精确。下次遇到 bug，别急着贴代码，先花 30 秒写清楚“它应该做什么”和“它实际做了什么”——这 30 秒能帮你省下 30 分钟。

相关问题

• 如何让 AI 解释一段复杂算法的时间复杂度？
  提示词里加上“请用大 O 表示法，并指出最坏情况下的触发条件”，它能帮你分析循环嵌套和递归深度。
• AI 给出的修复方案引入了新 bug 怎么办？
  把新旧代码都贴给它，要求“对比差异，并分析为什么新方案可能破坏原有功能”，让它做回归测试。
• 怎么用 AI 做代码重构而不是单纯找 bug？
  明确说“保持外部行为不变，只优化可读性和性能”，并指定“不允许改变函数签名和返回值类型”。
• AI 在找 bug 时“说谎”怎么办？
  它可能编造一个不存在的错误。对策是要求“给出验证该假设的具体日志输出样例”，如果它写不出来，大概率是幻觉。
• 有没有专门针对前端 bug 的提示词技巧？
  有。前端 bug 常与状态管理和渲染时机有关，提示词里加上“请关注 useEffect 的依赖数组和闭包陷阱”，命中率会高很多。