想象你是一家小餐馆的老板，后厨请了一位手脚麻利、热情高涨的 AI 大厨。你只需要用大白话报菜名，他就能飞速出一桌菜——这就是 Vibe Coding，一种靠自然语言提示驱动 AI 写代码的编程方式。问题来了：这位大厨偶尔听岔话，客人（测试用例）突然皱眉：“这菜太咸了！”——bug 出现了。和普通编程不同，你不能直接掀桌子自己炒，因为菜是他炒的、菜谱是他脑补的。你得学会带这位大厨一起返工：先问清楚是哪道菜、咸到什么程度、你期望什么口味；再让他回厨房翻监控（日志）、在关键步骤暂停试吃（断点）；他改完之后，先做一小份试吃（单元测试），再整桌重新尝一遍（回归测试），还要盯着他别为了去咸而狂加水，把整锅汤都毁了。这篇文章，就是一份“如何指挥 AI 大厨精准回锅”的完整攻略：Vibe Coding 调试与修复。
学会这套调试心法，你就能从“被 AI 带着跑”变成“指挥 AI 精准返工”，让 AI 编程真正从刺激变成踏实。
目录
可视化演示
演示AI辅助编程调试的完整闭环：从Bug描述沟通、AI路径分析、日志断点验证到修复回归检测，通过交互式可视化展示Vibe Coding调试工作流。
本节配有交互动效（进入视口后自动加载，约 3KB）。
Bug描述沟通 错误堆栈+错误码描述 复现步骤+输入数据 期望行为vs实际行为 精准描述是AI定位Bug的前提
1. 问题描述：客人怎么说，AI 大厨才听得懂
作为餐厅老板，你最怕遇到客人只丢下一句“菜不行”就走人。你没法把这样的抱怨转告给后厨：是宫保鸡丁太辣，还是番茄炒蛋太酸？是量太少，还是上菜太慢？AI 大厨也一样，你只丢给他一句“代码有 bug，帮我改改”，他就只能站在灶台前发呆，然后随便猜一个方向乱炒。坏的客户反馈会毁掉一道菜，模糊的 bug 描述会毁掉一次调试。
所以 Vibe Coding 调试的第一步，是学会写“客人差评单”——一份结构化的问题描述。它至少要包含四个部分：具体症状（什么功能报错、报错信息是什么）、复现步骤（怎么操作能稳定触发）、期望行为（你希望程序做什么）、实际行为（程序到底做了什么）。如果能再附上环境信息（浏览器、系统、依赖版本），AI 大厨就能少做一大堆无用的猜测。
最值钱的一招，是给出最小复现样例。就像检验盐放多没放多，不需要把一整桌宴席都端出来，一碗只有盐和水的测试汤就够了。你需要把无关的业务逻辑删掉，只保留能稳定触发 bug 的最小代码片段。这样一来，AI 就不用在大堆无关代码里大海捞针。描述得越清楚，信息量越大，AI 一次修对的概率就越高。
把这份“差评单”递进厨房，AI 大厨就不用靠猜来炒菜了。下次再遇到 bug，先花五分钟写清症状、复现、期望和最小样例，你会发现 AI 的回话从“我猜可能是……”变成“我确认是这里有问题”。
- $I_{\text{before}}$ 初始不确定性描述之前，AI 面对几千行代码，可能出错的位置成百上千，信心很低。
- $I_{\text{after}}$ 描述后不确定性你给出症状、复现步骤和最小样例后，可疑范围急剧缩小。
- $\Delta I$ 信息增益两者相减就是这次描述带来的信息增量，增量越大，AI 一次命中的概率越高。
2. 让AI定位：回厨房翻监控，缩小嫌疑范围
大厨拿到“宫保鸡丁太咸”的反馈后，回到厨房还要想一步：问题出在腌鸡肉时盐放多了，还是出锅前又补了一勺盐？如果你能告诉他“客人说吃到第三口才觉得咸”，他就能更快锁定是调味阶段的问题。AI 定位 bug 也是同一套逻辑：不要问“这是怎么回事”，要问“从哪一行开始和预期不符”。
具体操作时，你可以让 AI 沿着代码执行路径走一遍：输入什么数据、进入哪个函数、中间变量变成了什么、在哪一步返回值开始不对。就像看后厨监控录像，一帧一帧回放。日志是最好的“监控录像”——把可疑函数里的输入输出打印出来，再把日志片段喂给 AI，它就能从“盲猜”变成“推理”。报错堆栈（traceback）也是线索，它直接告诉你爆炸现场在哪条街。
真正高效的方法论是二分定位。假设有一段 100 行的可疑代码，你可以让 AI 先看第 50 行前后的输出：如果这里还正常，说明问题在下半段；接着看第 75 行……这样每试一次就能排除一半位置。把“逐个检查”变成“对半砍”，工作量会从 N 次锐减为对数级别。
别忘了先排除干扰因素：本地能跑、服务器挂了，那大概率是环境差异，就像确认是锅的问题还是厨师的问题一样。把环境、依赖、输入数据先固定住，再让 AI 去二分追杀代码里的真凶。问题范围一缩小，AI 大厨翻菜谱的页数就少了，修起来自然快。
- $N$ 可疑位置数比如 100 处可疑代码行，这是要排查的总范围。
- $\log_2 N$ 对半切的次数每检查一次就排除一半，所以需要的次数是 2 的几次方能到 N。
- $\left\lceil \cdot \right\rceil$ 向上取整次数必须是整数，比 6.64 大的最小整数是 7。
3. 修复与验证：只改一处，先试一口
定位到“是出锅前那勺盐多了”之后，靠谱的大厨只会做一件事：调整盐量。他不会顺手把整道菜的配方推翻，更不会把菜单上所有菜都重做一遍。但 AI 大厨有个坏毛病：它太爱表现，修 bug 时常常夹带私货——顺带“优化”了一下变量名、重构了一个函数、多改了几行看似相关实则无关的代码。这就像让厨师去去咸，他却把整本菜谱都改了。
所以修复阶段要亮出两条纪律。第一，最小改动原则：明确告诉 AI“只解决当前这个 bug，不要做任何额外修改”，改完用 git diff 检查，凡是超出问题范围的改动全部退回。第二，快速验证原则：修完先跑一个针对该 bug 的小测试，就像先舀一小勺汤尝咸淡，而不是直接端给客人。小样试吃合格了，再跑一遍相关功能的测试，确认没有把别的菜搞砸。
AI 大概率不会一次就改对，这很正常。你要做的不是发火，而是进入迭代反馈循环：把测试结果、失败原因、新的期望喂回给 AI，让它再改一版。每一轮修复都有一定的成功率，只要不是零，多试几轮总能成功——这背后的道理很朴素。
记住这个节奏：小样试吃通过，才整盘端出；单测通过，才跑集成测试。每一轮修复都把反馈喂回去，AI 大厨会在三五个来回之内把菜调对。千万别跳过“试吃”直接上桌，那样客人就是你唯一的测试用例，代价太大。
- $p$ 单轮修复成功率你描述越清楚，p 就越高，比如从 0.3 提升到 0.6。
- $1-p$ 单轮失败概率这一轮没修好的可能性。
- $(1-p)^n$ 连续失败 n 轮的概率如果每次都失败，且各轮独立，就是它的 n 次方。
- $P_{\text{success}}$ 至少成功一次的概率用 1 减去“全都失败”，就是“多轮里总有一次修对”的把握。
4. 传统调试配合：监控录像和试吃闸门
很多初学者以为 Vibe Coding 就是纯聊天：我把报错丢给 AI，它负责想，我负责等。但真正的老手都知道，厨房里该装的监控、该设的闸门一样都不能少，恰恰是因为有了 AI 大厨，这些传统工具反而变得更重要——它们是给 AI 递证据的通道。
日志就是厨房的监控录像。你在可疑函数里打印输入、输出、中间变量，代码跑一遍，所有操作记录都在。把这些日志片段原封不动喂给 AI，它就能看到数据在哪一步变坏的。断点则像在流水线上设一道“试吃闸门”：程序执行到关键行时暂停下来，你亲眼看看此刻的变量到底是什么，再把观察结果告诉 AI。很多 AI 猜不出来的诡异 bug，看一眼关键断点的实际值就真相大白了。
还有一个被低估的工具：git diff。AI 改完代码后，你对比一下改动前后的差异，就像把旧菜谱和新菜谱并排摊开，看看它到底偷偷加了什么料。有时候 bug 是 AI 上一轮修复时留下的，把“这次提交改了哪些行”告诉 AI，它才能意识到“哦，是我上次改坏的”。日志、断点、diff 这三板斧，能让 AI 从“玄学猜谜”变成“有据可查”。
有了监控和闸门，AI 大厨就不能拍着胸脯说“我觉得没问题了”。你随时可以用日志打脸：“第 27 行打印出来的值明明是 null，你告诉我这正常？” 传统调试技能不是被 AI 淘汰了，而是变成了你管理 AI 大厨的遥控器。
- $n_{\text{total}}$ 全部关键路径数一段代码里所有可能影响结果的执行分支。
- $n_{\text{logged}}$ 已观测到的路径数你通过日志或断点实际看到的那部分。
- $C$ 覆盖率两者相除，值越接近 1，证据越完整，AI 的定位结论越可信。
5. 防止回归：别让修好的菜又坏掉
AI 大厨有个特别让人头疼的操作：为了去咸往汤里猛兑水。咸味确实淡了，但整锅汤的鲜味也没了——客人抱怨从“太咸”变成“太淡”。这就是回归测试要防的事：修好了 A，打坏了 B。在 Vibe Coding 里，AI 只看你给它的那一个报错，它没有能力自动发现自家补丁悄悄踩坏了旁边的边界条件。
防回归的第一招，是跑完整回归测试。修完 bug 后，不要只跑那一个用例，把相关模块、甚至整个项目的测试套件都跑一遍。整套菜都重新尝一遍，才算真正通过。第二招，是单次改动原则：一次只让 AI 修一个问题。如果你同时丢给它三个 bug，它就可能在混战中把锅彻底搞乱。第三招，是留下变更记录。让 AI 在回复里明确列出：“我改了哪些文件、哪些函数、为什么改”，你对照 git diff 逐一审查，发现越界立刻打回。
回归风险是可以量化的直觉：你让 AI 同时改的地方越多，风险就越大。每一处改动都可能引入新问题，而这些风险会叠加。
修好一个 bug 的标准不是“报错消失”，而是“整桌菜仍然原汁原味”。当 AI 自信满满地说“改好了”时，你要冷静地按一遍回归测试，再冷静地看一眼 diff。确认没有多余改动之后，这盘菜才算真正可以上桌。
- $k$ 改动点数量本次修复里 AI 实际修改的代码位置数。
- $r$ 单点风险概率每改动一处，因为疏忽引入新 bug 的可能性。
- $R$ 总回归风险两者相乘，改动越少、单点越稳，总风险就越低。
6. 失败模式识别：提前识破大厨的翻车套路
跟 AI 大厨合作久了，你会发现他的翻车套路其实就那几样。第一种叫“自嗨”：他拍着胸脯说“已修复”，实际上根本没运行过代码，全凭感觉。第二种叫“修复过头”：明明只差一撮盐，他却把整道菜的配比都改了，还美其名曰“顺手优化”。第三种叫“换班失忆”：你换了个新对话窗口想让他继续干活，结果他完全忘了前面所有讨论，又开始按老错误的方法来。第四种叫“添乱式返工”：越修越乱，代码像被反复回锅十八次的剩菜。
识别这些模式，是 Vibe Coding 调试的进阶技能。对付“自嗨”，办法是要求证据：不让 AI 说“我修好了”，要让 AI 说“我运行了哪条测试、输出是什么”。对付“修复过头”，办法是限制边界：明确要求只改指定函数，改完必须给你看 diff。对付“换班失忆”，办法是管理上下文：换新对话前，把之前的结论、修改过的文件、剩余问题压缩成一段“交接说明”粘过去，让 AI 大厨快速回忆今天自己干过什么。
所有这些翻车，本质都指向同一个要害：AI 能利用的上下文是有限的、脆弱的。对话里塞了太多不相干的信息，或者历史太长，它就会“选择性失忆”，忘记最关键的那条约束，就像大厨忘了客人不吃香菜一样。
知道大厨会在哪儿摔倒，你才能在哪儿提前扶住灶台。看到 AI 开始长篇大论自我表扬，就让它贴证据；看到它东改西改，就让它交 diff；看到它答非所问，就赶紧把关键词重新强调一遍。识别翻车套路的速度，决定了你的调试效率。
- $L_{\text{context}}$ 对话总上下文长度当前对话里所有已发生的文字，包括闲聊、报错、废话。
- $L_{\text{used}}$ 有效利用的上下文长度和当前 bug 直接相关的关键信息量。
- $U$ 利用率两者相除，越高说明 AI 在处理正事，越低说明它正在被大量噪声干扰。
7. 工作流沉淀：把一次救火变成一套菜谱
一位真正的大厨，不会每次做菜都靠临场发挥。他会把关键步骤、酱料比例、火候时间写进菜谱，下次照着做就行。Vibe Coding 团队也一样：每次成功的 bug 修复，都应该像一次菜品改良实验，把过程沉淀下来，而不是救完火就抛到脑后。
沉淀的第一步是调试记录。每次 debug 完成，写下：问题是什么、你怎么给 AI 描述的、AI 是分几步定位的、最终改了什么、测试怎么验证的。这些记录放在团队 Wiki 或者仓库的 docs 目录里，下次遇到类似问题，直接搜索，就不用从零开始和 AI 大厨沟通了。第二步是固化 Prompt 模板。把你用过的最有效的问题描述格式变成固定模板：症状 / 复现步骤 / 期望行为 / 实际行为 / 相关日志。团队所有人都用同一个模板喂 AI，AI 的表现会稳定很多，就像后厨每一道菜都有标准菜谱一样。
第三步是定工程规范：AI 改完的代码必须跑测试才能提交；单次改动不得超过某个范围；AI 生成的补丁必须经过人工 review。这些规范看似约束，其实是保护——它们保证每个菜谱被严格执行，大厨的“灵机一动”不会乱入。当一个团队的调试经验开始沉淀，大家会发现：新手遇到 bug，第一反应不是慌，而是翻开菜谱，复制模板，照着流程走一遍。
把一次次惊心动魄的救火，写成一本厚厚的厨房 SOP，是 Vibe Coding 调试的终极形态。到那时，AI 大厨依然会偶尔翻车，但你的后厨不会乱——因为每个人的手边都有一本经过实战检验的菜谱。
- $N_{\text{debug}}$ 总调试次数一段时间内团队处理 bug 的总数。
- $N_{\text{reuse}}$ 经验复用次数其中靠沉淀的记录或模板快速解决的次数。
- $E$ 复用率两者相除，接近 1 说明团队大部分 bug 都能靠“菜谱”快速处理，而不是每次重新踩坑。
AI 应用场景
场景一：联调时接口报错，快速让 AI 修复
阶段：AI 辅助开发中的调试迭代
解决的问题：前后端联调时，AI 生成的接口报 500，传统方式是开发人员翻日志、查代码、问同事，半小时起步。用 Vibe Coding 的“问题描述四要素”，把报错信息、请求参数、期望返回、实际返回整理成一段结构化描述，再附上相关函数代码，AI 能在几十秒内给出可疑点和修复补丁，像把“客人差评单”直接递给大厨。
具体案例：前端调用 /api/order 返回 500，后端日志显示 TypeError: Cannot read properties of null。你把 curl 命令、报错堆栈、期望的 JSON 结构、实际响应发给 AI 编程助手，AI 很快指出是订单详情接口里某个字段在数据库为空时没有判空，并给出最小补丁。运行测试通过，问题闭环。
场景二：老项目偶发崩溃，用日志辅助 AI 定位
阶段：可观测性与故障定位
解决的问题：AI 大厨看不见生产环境，就像厨师没法跑到客人家里看冰箱。传统的日志埋点和断点调试，是给 AI 递“厨房监控录像”。很多偶发 bug 用常规手段很难复现，但通过在可疑链路加日志，把中间变量的变化过程抓下来发给 AI，人类和 AI 配合，定位效率远超单打独斗。
具体案例：一个老服务每隔几小时超时一次，人工看代码毫无头绪。你在 Redis 连接池相关函数里加了耗时日志，跑一晚上抓到了“连接数峰值异常”的记录，把日志片段和连接池配置代码发给 AI，AI 指出默认连接数配置在突发流量下会打满，导致请求排队超时，建议调整参数并加熔断。问题解决。
场景三：CI 回归失败，让 AI 分析自己的改动
阶段：质量保障与回归防护
解决的问题：AI 修好一个 bug，却在 merge request 里弄坏了另一个功能，这是“兑水毁汤”的典型事故。把 CI 的失败用例列表和 git diff 一起交给 AI，让它自查改动影响面，是防回归的实用操作。
具体案例：团队用 AI 修了一个工具函数的排序 bug，提交后批量单测挂了 6 个。你把失败列表和本次提交的 diff 粘贴给 AI，AI 很快承认：“我把默认参数 reverse=False 改成了 True，导致其他调用方行为变了。” 然后它给出兼容性修复，并主动补充了回归测试。人工 review 后合入，CI 全绿。
Python 演示
import re SOURCE = "def calc(x):\n return x * 2\n" def run_tests(src): namespace = {} exec(src, namespace) case1 = namespace["calc"](3) == 7 case2 = namespace["calc"](0) == 0 return {"case1": case1, "case2": case2} class VibeDebugger: def __init__(self, source_map, test_fn): self.source_map = source_map self.test_fn = test_fn self.fix_count = 0 def build_prompt(self, symptom, repro, expected, logs): return ("请修复以下 bug。\n" "症状：" + symptom + "\n" "复现：" + repro + "\n" "期望：" + expected + "\n" "日志：" + logs + "\n" "代码如下：\n" + self.source_map) def apply_fix(self, old, new): if old in self.source_map: self.source_map = self.source_map.replace(old, new, 1) self.fix_count += 1 return True return False def verify(self): return self.test_fn(self.source_map) def main(): debugger = VibeDebugger(SOURCE, run_tests) prompt = debugger.build_prompt( "calc(3) 返回 6，而不是 7", "运行 calc(3)", "calc(3) == 7", "x=3, out=6" ) print("=== 发给 AI 的问题描述 ===") print(prompt) print("\n=== 开始迭代修复 ===") for round_index in range(3): results = debugger.verify() print("第", round_index + 1, "轮测试结果：", results) if all(results.values()): print("全部通过，修复完成，共修改", debugger.fix_count, "处") break if not results["case1"]: debugger.apply_fix("return x * 2", "return x * 2 + 1") else: debugger.apply_fix("return x * 2 + 1", "return x * 2 + (1 if x > 0 else 0)") print("最终代码：") print(debugger.source_map) if __name__ == "__main__": main()
SOURCE = "def calc(x):\n return x * 2\n"这就是 AI 大厨最初端出来的菜：一份有 bug 的源码，漏掉了关键逻辑。def build_prompt(...)把症状、复现、期望、日志缝合成一段结构化描述，相当于递给后厨的“客人差评单”。exec(src, namespace)动态执行补丁后的代码，模拟 AI 大厨改完配方后重新开火。self.source_map.replace(old, new, 1)只替换第一处匹配，恪守“最小改动原则”，不让大厨顺手乱改。all(results.values())所有测试用例都通过才算修复完成，而不是只盯着最初那个报错。if not results["case1"]: ... else: ...根据失败用例选择不同补丁，这就是迭代反馈循环。
常见误区
误区“我已经把报错信息复制给 AI 了呀，它怎么还说信息不够？报错里不是写得很清楚吗？它是不是在偷懒？”
正解报错只是症状，不是病因。就像客人喊了一声“菜咸了”，大厨还需要知道是哪道菜、咸到什么程度、当时点的是什么、期望什么口味。同样，你要把复现步骤、期望行为、实际行为、相关代码一起发给 AI，它才能从“看热闹”变成“查真相”。
为何常见：报错信息看起来非常具体，甚至指出了行号和错误类型，让人误以为这就是全部有效信息，忽略了上下文和意图。
误区“AI 大厨信誓旦旦地说已修复，还列出了修改点，那应该没问题，直接提交吧！”
正解AI 的“已修复”只是它生成了一段文字，并不代表程序真的跑通了。它可能没运行过测试，可能只修了一半，甚至可能修错了。正确流程是：自己跑相关测试、查看 git diff、再跑一遍回归，拿到真实证据才算数。
为何常见：AI 的语气天然自信流畅，人很难在潜意识里把它当成“未经验证的草稿”，于是放松了警惕。
误区“都用自然语言让 AI 写代码了，还打日志、打断点？那也太不酷了，直接让 AI 猜不行吗？”
正解日志和断点不是给人类看的，是给 AI 递证据的。AI 没有“视觉”，看不到程序运行时的真实状态，只有你把中间变量、日志片段、断点观察结果喂给它，它才能从瞎猜变成推理。这些传统工具是 AI 大厨的“监控录像”和“试吃闸门”，缺了它们，AI 就是在盲人摸象。
为何常见：Vibe Coding 强调自然语言交互，让初学者误以为工程手段已经过时，其实 AI 越强大，高质量的输入证据越值钱。
误区“这个窗口聊乱了，重新开一个对话继续问，AI 又能满血复活，多省事！”
正解新对话意味着 AI 彻底失忆。它不知道你之前已经试过什么方案、问题背景是什么、哪些约束不能碰，于是很可能重复犯同样的错误，甚至提出和上次完全相反的建议。正确的做法是在当前对话里粘贴最新日志、总结已试方案、重述目标，把上下文完整续上。
为何常见：人习惯用“重启大法”解决电脑问题，但这个经验套用到 AI 对话上，反而丢掉了最宝贵的上下文资产。
误区“AI 改了代码之后，原来看见的那个报错确实没了，那就大功告成了！”
正解报错消失只代表“这个症状不存在了”，不代表“整道菜是好的”。AI 很可能为了修 A 问题，偷偷改坏了边界条件，就像一个测试用例过了，另外六个用例全红。修完后要跑完整测试、检查 diff、确认改动范围，才能宣布修复完成。
为何常见：人的注意力天然被“原来报错”的消失所满足，产生任务完成的错觉，忽略了副作用和不可见风险。
面试题
Q1. 下面哪个问题描述，AI 大厨听了最容易直接动手修？
- A.代码好像出了点问题，帮我看看
- B.有个 bug，请你快速修复一下
- C.calc(3) 返回 6，期望 7，请看代码← 正确答案
- D.我的程序不太对，帮我优化一下
答案：C。C 包含了具体症状（返回 6）、期望行为（返回 7）和相关代码位置，就像客人明确说出“这道菜咸了、希望淡一点”。A、B、D 都属于模糊抱怨，AI 大厨只能靠猜，无从下手。
Q2. 给 AI 描述 bug 的核心要素中，通常不包括？
- A.具体症状和报错信息
- B.最小化的复现步骤
- C.开发机的 CPU 型号← 正确答案
- D.期望行为与实际行为
答案：C。症状、复现、期望与实际行为是问题描述的核心，相当于客人差评单。CPU 型号属于无关环境噪声，它不会影响绝大部分业务 bug 的定位，除非问题本身与硬件性能强相关。
Q3. AI 大厨拍胸脯说“已修复”后，你应该先做什么？
- A.直接提交代码并部署上线
- B.运行相关测试验证修复效果← 正确答案
- C.让 AI 顺手再写一个新功能
- D.把代码全部推倒重新生成
答案：B。AI 的“已修复”只是它的一段输出，不等于程序真的跑通了。正确做法是先运行测试验证，再查看 diff 和回归结果。直接提交等于让客人当小白鼠；推倒重来和加新需求都是脱离当前目标的跑偏操作。
Q4. 在 Vibe Coding 调试中，日志相当于厨房里的什么？
- A.给菜品拍照发朋友圈
- B.记录每一步操作的监控录像← 正确答案
- C.客人填写意见的反馈卡片
- D.厨师手里拿着的炒菜锅
答案：B。日志的价值在于回放程序运行时的每一步状态，像厨房监控录像能还原“哪一步开始不对劲”。客人反馈卡是问题描述，炒菜锅是工具本身，朋友圈则完全不相关。
Q5. 用二分法排查 200 个可疑代码位置，最多需要试几次？
- A.需要尝试 200 次左右
- B.需要尝试 100 次左右
- C.需要尝试 8 次左右← 正确答案
- D.需要尝试 1 次左右
答案：C。二分定位每次砍掉一半可疑范围，$\lceil \log_2 200 \rceil = 8$，所以最多试 8 次就能锁定问题所在区域。200 次是线性排查，100 次是折半查找的误记，1 次是运气好，不是稳定的方法论。
Q6. 哪些做法能有效防止 AI 修 A 问题时弄坏 B 功能？
- A.跑一遍完整的回归测试← 正确答案
- B.修改后用 git diff 核对改动← 正确答案
- C.让 AI 重写整个项目的全部代码
- D.一次性把所有可疑点都修改掉
答案：AB。回归测试能暴露“修好 A、弄坏 B”的副作用，git diff 能审查改动是否越界，这两者是防回归的基本盘。重写全部代码和一次性改所有可疑点都会让风险爆炸式上升，违背最小改动原则。
Q7. AI 反复“自嗨”式声称修复完成，最有效的应对是？
- A.要求它附上测试通过的真实证据← 正确答案
- B.把模型温度参数调到最大
- C.立刻换一个更大的模型版本
- D.清空当前对话重新开始聊天
答案：A。对付“自嗨”最有效的办法是让 AI 提供真实证据，比如运行某条测试的输出截图或日志。调温度、换模型、清空对话都没有解决“缺乏验证”这个核心问题，甚至会引入新的不确定性或丢失上下文。
Q8. 以下哪些策略能帮助 AI 在调试时不丢失上下文？
- A.每轮修复后立刻新开一个对话
- B.在对话中粘贴最新日志和报错← 正确答案
- C.请 AI 先总结当前结论再继续修复← 正确答案
- D.用简短列表重述问题与改动目标← 正确答案
答案：BCD。粘贴日志、让 AI 总结结论、重述目标都能把关键信息固定在上下文中，延长 AI 的“有效记忆”。新开对话等于换班失忆，AI 会忘掉已试方案和问题背景，是 Vibe Coding 调试的大忌。
Q9. 最小复现样例就像把一道复杂的菜简化成什么？
- A.一道只有盐和水的测试汤← 正确答案
- B.一份加了十种配料的浓汤
- C.一整套豪华包间的菜单
- D.一盘等待上桌的红烧肉
答案：A。最小复现样例的核心是剔除无关因素，只保留触发 bug 的骨架，像用“盐和水”来判断咸淡。配料越复杂、菜单越豪华，干扰越多，反而不容易看清问题本质。
Q10. 人工 review AI 的修复补丁时，应该重点看哪些？
- A.改动是否超出了问题本身的范围← 正确答案
- B.是否破坏了边界条件和数据格式← 正确答案
- C.是否夹带了无关的调试输出或重构← 正确答案
- D.是否使用了最新款的显卡来训练模型
答案：ABC。Review AI 补丁要盯住三件事：改动边界是否越权、边界条件和数据格式是否被破坏、有没有夹带无关重构或调试垃圾。显卡型号与业务代码无关，属于审查噪声，不应出现在补丁检查清单里。