与AI结对调试程序的防坑指南

文章主旨：在利用AI（如扣子/Coze）进行编程调试时，必须主动建立“先验证根因、限定范围、全链路留痕、分步确认”的纠偏机制，打破AI“看到现象直接给最常见解”的默认行为，才能避免陷入无数修补陷阱。

关键要点：

1. 根因验证：调试前先复现、排除其他原因、设计验证方案，而非直接修改代码。
2. 警惕过度补偿与权宜之计：优先设计可扩展方案，避免打补丁使代码混乱。
3. 防止目标迷失：一次只修一个核心Bug，设置时间盒，每步回顾原始目标。
4. 全链路可观测性：记录每次LLM调用的输入输出、解析结果、边界情况。
5. 修改后全域自查与回归：检查所有调用点，运行类型/代码规范检查，给出完整自测用例。

内容结构：

核心洞察

AI的默认行为是“看到现象→给出最熟悉的解”，而非定位根因。人类需主动建立纠偏机制。

第1条：根因验证——先验根因，再谈修改

现象：AI直接给出“合理”原因并修改，问题未解决甚至更糟。
典型错误路径：发现LLM输出不全→判断为格式错误→改提示词限定markdown→问题依旧。
应对原则：先观察后假设，要求证据；复现优先于修复；不能稳定复现则治标不治本。
具体措施：每次改代码前要求AI梳理复现步骤、输出精确条件、列出已排除原因、给出验证方案（如加日志），追问“证据在哪”。
案例：浪费2小时因未查原始输出就改提示词。

第2条：权宜之计 vs 一劳永逸

现象：AI打局部补丁导致代码混乱。
应对原则：评估修改范围，问“复杂场景是否失效”；设计优于补丁，补丁比重构复杂则重构。
具体措施：强制AI回答方案在复杂场景的可靠性；保持风格兼容；拆分长函数；减少嵌套try-catch；修改前读整体结构。
案例：输出不全→AI限字段字数→丢失细节，根因实为上下文窗口或max_tokens。

第3条：Bug迷途与初心迷失

现象：修A遇B，修B遇C，最终忘记初衷。
应对原则：识别“修复陷阱”（1修引发3+新问题则暂停）；30分钟无进展回退；小步提交，区分阻塞与次要问题；一次只修一个核心问题。
具体措施：调试前写下最终目标；设置15分钟时间盒；每解决一个问题问“离目标更近了吗？”；复杂联调拆小步并重申目标+约束。
案例：修TS1472语法错误→括号问题→缩进→整个函数重写→忘记要修normalize功能。

第4条：可观测性——LLM调用全链路留痕

现象：无日志无法判断问题出在提示词、模型还是解析。
应对原则：输入输出必记录，中间状态可见；日志可搜索、可分级；优先固定JSON输出+Schema约束。
具体措施：每次调用记录提示词、原始输出、解析结果；记录关键变量值；日志含稳定关键词、时间戳、请求ID；单独记录边界情况；禁止字符串分割/硬截字符。
案例：加日志发现LLM输出完整，是解析函数截断导致问题。

第5条：修改后全域自查

现象：改一处忘记检查类似位置，或引入新的类型/语法错误。
应对原则：影响范围扫描，必跑类型检查与代码规范检查；自己像Reviewer一样读一遍；改完要求AI给出自测用例。
具体措施：grep相关函数/变量检查其他调用点；运行类型检查、代码规范检查；回归主流程；要求正向、边界、异常用例验证修复并防回归。
案例：修改A函数，未发现B函数也调用同一工具函数，导致B函数悄悄损坏。

第6条：成本意识

现象：AI方案不关心token成本，如循环重复调用、超长提示词。
应对原则：主动要求评估成本，要求给出低成本备选方案。
具体措施：要求AI估算调用次数、输入输出token量、耗时；询问是否可缓存；给出两套方案（低token略复杂 vs 高token简单）。
案例：循环内逐条调用LLM→批量调用，token成本降为1/10。

第7条：格式转换陷阱

现象：AI写的JSON→CSV等转换代码遇到空值、特殊字符时崩溃。
应对原则：显式列出每个字段的转换规则，强制做格式校验。
具体措施：每次转换后要求明确每个字段的源→目标映射（缺省值/类型转换/异常处理）；空值、多余字段处理；嵌套结构展开规则；字符转义/分隔符风险；转换后做最小格式校验。
案例：CSV字段含逗号和换行符，AI未加引号转义，导致解析错位。

第8条：过度修改与越界重构

现象：仅需改3行，AI却重构大片，引入隐性Bug。
应对原则：提前锁定修改范围，禁止扩范围重构。
具体措施：修改前明确指定只改特定函数/行；要求AI先给出修改计划（改动点列表），确认后再执行；一次只改一个核心Bug，闭环后再启下一个。
案例：要求修复字段映射错误，AI却重写整个函数，导致老项目依赖全断。

第9条：协作节奏

现象：AI在不确定时假装确定，或用户未确认就开始写代码；AI给出技术正确但业务错误的方案。
应对原则：先说后写，分步确认，主动暴露不确定性；先给AI业务规则、边界约束再改代码；每个修改视为实验。
具体措施：方案先口头/文字确认再动手；重要结论需多方证据；实验思维（假设→验证→结论）；预留验证时间；落地前自己走一遍逻辑推演和边界用例。
案例：先加一行日志确认根因，比直接改代码快得多。

附：调试流程（7步）

1. 锁定单一核心Bug，临时Bug先记录不插队
2. 稳定复现，与AI对齐根因，出具根因逻辑
3. 限定修改范围，禁止无边界重构
4. 全链路留痕：提示词+原始输出落地日志
5. 修改后AI自查同类代码、批量漏改点
6. 给出自测用例（正向/边界/异常），验证通过再收尾
7. 长对话拆小步，每步重申目标，防止AI健忘跑偏

一页速查表（调试前/中/后）

文章总结：本文是一份详实的AI编程调试实战指南，强调通过结构化流程（根因验证、范围锁定、全链路观测、分步确认）来对抗AI的“假性确定”行为，从而节省时间、避免代码熵增。