要安全地用 AI 调试代码，先从一个能复现的故障入手，给模型证据而不是理论，每次只检验一个假设。目标不是让报错消失，而是找出原因、证明修复有效，并保留一个在 bug 复发时会失败的回归测试。

通用的 AI 实用工作流依然适用，但调试需要更严格的证据循环。一个看似合理的解释，在受控观察把它与其他可能区分开之前，都只是假设。

关键要点

要求修复之前，先冻结一个可复现的故障。

把观察、假设、实验和结论分开。

分享之前，对日志脱敏并把故障输入缩到最小。

每次实验只改变一个相关变量。

修复后，把故障用例保留为回归测试。

应该怎样用 AI 调试代码？

把 AI 当作调查助手：让它整理证据、给出排序后的可能原因、解释不熟悉的控制流，并提出下一项能区分原因的检查。执行和验收仍由人掌控。GitHub 提醒，生成的回答和代码可能不准确或不安全，因此复核和验证的责任仍在用户身上。［1］

这种方法适用于确定性故障、意外输出、有明确范围的性能退化，或已记录时序证据的不稳定测试。如果唯一的反馈是“生产环境感觉很慢”、无法确定运行环境，或你无权查看受影响的数据，它就不太管用。

建立证据账本

开始对话前，先建四个栏目：

栏目	含义	示例
观察	直接测量或复现的事实	输入 `a,,b` 时测试失败，报 `expected 2, got 3`
假设	可能的解释	空字段被当成值计数
实验	能区分原因的检查	在过滤前打印解析出的 token
结论	实验真正支持的判断	空 token 进入了计数分支

不要因为模型语气自信，就把一句话从“假设”挪到“结论”。只有当实验或代码追踪支持它时，才能挪过去。

步骤一：复现并冻结故障

记录确切的命令、输入、环境和输出。操作是确定性的，就运行两次。如果故障是间歇性的，就记录时序、随机种子、执行顺序、资源压力和尝试次数，而不是假装它很稳定。

在不改变行为的前提下缩小用例。去掉无关的记录、路由、插件和服务，直到故障仍然出现在你能解释的最小 fixture 中。这对隐私和推理都有好处：十行的 fixture 暴露的数据更少，也让模型少掺进无关的路径。

分享日志之前，删除令牌、Cookie、签名 URL、用户标识、内部主机名、私有路径和生产数据载荷。证据含有个人或机密数据时，遵循 AI 隐私风险指南。

保存正常对照

修改代码之前，先保存故障的输入和输出。如果已有测试能体现这个 bug，不要为了让测试套件变绿而削弱或删除它。如果还没有测试，先写出最小的复现，哪怕一开始只是个本地脚本。

基线应回答：什么失败了、失败得有多稳定、附近哪些情况目前是正常的？例如，同时保存故障用例 a,,b 和有效的对照 a,b。没有对照，一个补丁可能通过拒绝所有输入来“修好”这个 bug。

步骤二：提供证据，而不是预设诊断

分享最小 fixture、故障命令、确切的错误、相关函数、调用方，以及最近一次已知正常的行为。然后要求模型先复述证据，再提出原因。

可以使用这样的提示词：

根据失败的测试和解析器代码，按与证据的吻合程度列出最多四个假设。对每个假设，指出一条能支持它的观察和一条能排除它的观察。暂时不要提出补丁。说明还缺少哪些信息。

这种结构能抵抗过早下结论。如果你告诉模型“缓存过期了”，即使追踪结果指向别处，它也可能围绕缓存编出一套解释。从发生了什么说起，而不是从你希望的原因说起。

一般的代码生成设置，请看单独的 AI 编程入门工作流。只有当你手里有一个具体的不符之处要调查时，调试才真正开始。

步骤三：选择一项能区分假设的检查

按与证据的吻合程度、测试的难易和实验风险给原因排序。只读的追踪或聚焦的单元测试，通常应排在依赖升级、数据库迁移或生产配置变更之前。

问一问：拟议的检查能否区分至少两个假设？“到处多加日志”只会制造噪音。“在计数之前立即捕获 token 列表，并与预期的三个位置比较”则能直接检验多出的值是在解析还是计数中产生的。

此为受控的本地截图，使用合成的解析器和测试输出；不含生产日志、账户数据或秘密，也不代表已完成的 AI 修复。

优先使用可回退的观测手段

使用现有的调试器、追踪开关、临时断言、聚焦的日志语句或仅用于测试的探针。观测手段保持在本地、可以移除。除非系统负责人另行批准该设计，否则不要为了调查一个小故障而引入永久的遥测依赖。

命令可能写文件、调用服务或修改数据库时，执行前先复核。OpenAI 把沙箱边界、审批、网络策略和审计日志描述为编码 Agent 的不同控制措施。［2］调试提示词本身无法强制实施这些控制。

步骤四：一次只运行一个实验

只改变一个有意义的变量。运行同一条复现命令并记录结果，包括出乎意料的结果。如果同时改了输入、超时、依赖和代码，你就无法判断是哪一项起了作用。

使用三种结果：

支持： 观察符合该假设的预测。
削弱： 预期的信号没有出现，或另一个原因更吻合。
无定论： 实验无法区分这些原因。

“无定论”也有用。它提示你设计更好的实验，而不是去要一个更自信的解释。

如果模型每次失败后都提出新假设，就要求它让新想法与证据账本相互印证。与已保存观察相矛盾的原因，没有新证据就不应再回来。

步骤五：修复有证据支持的原因

只有在某个原因得到支持后，才要求补丁。说明根因、要求的行为、兼容性边界和回归测试。要求针对原因的最小改动，而不是压制症状。

复核补丁是否：

只改变了批准的行为；
保留了附近有效的情况；
引入了新的依赖、权限、重试或外部 I/O；
把明确的失败变成了悄无声息的回退；
改变了公开的错误或返回类型；
留下了临时的观测代码。

执行拟议补丁之前，尤其是涉及认证、路径、查询、子进程或存储时，使用 AI 生成代码审查清单。

步骤六：证明修复并防止复发

先运行原来的故障用例，再运行有效对照、边界情况、格式错误的输入和最近的现有测试组。回归测试通过是必要的，但如果补丁破坏了调用方或改变了错误契约，这还不够。

按行为而不是实现给回归测试命名。rejects_empty_token_when_counting_fields 比 calls_filter_before_len 更经得起重构。这个测试应当在旧行为下失败，并因验收标准中描述的原因而通过。

NIST 的 SSDF 把复核、分析、测试和漏洞响应视为相互关联的安全开发活动。［3］采用这种更宽的视角：调试会话负责找证据，代码审查负责检查变更，测试覆盖预期行为，运行环境的验证则另行进行。

写一份简短的根因记录

记录：

用户可见的故障；
最小的复现；
得到支持的原因及其证据；
修改的代码和测试；
已运行和未运行的检查；
仍待完成的生产或平台验证。

这份记录能防止下一位维护者重复同样的调查，也能暴露出所谓的“根因”其实仍只是一个听起来合理的故事。

应避免哪些调试错误？

不要粘贴未脱敏的生产日志，不要在复现故障之前就接受补丁，不要同时尝试几个推测性的修复，也不要删除失败的测试。避免让模型“随便试，直到能跑”；这种指令追求的是症状消失，而不是理解系统。

也不要把本地运行成功当作生产环境的证明。配置、权限、流量、操作系统行为和外部服务都可能不同。记录这些缺口，把验证交给正确的负责人和环境。

模型引用某个框架行为或语言规则时，使用 AI 答案事实核查方法。在它成为诊断的一部分之前，先在官方文档中或用最小的可执行示例核实。

总结

冻结一个可复现的故障和一个附近的有效对照。
分享前先把证据缩到最小并脱敏。
把观察、假设、实验和结论分开。
每次只运行一个可回退、能区分原因的实验。
修复得到支持的原因，而不是最显眼的症状。
保留一个行为层面的回归测试，并记录仍存在的环境缺口。

常见问题

AI 能找到 bug 的根因吗？

它可以提出并整理可能的原因，但“根因”的说法需要来自追踪、实验、测试或代码路径的证据。没有依据的解释只能当作假设。

应该给 AI 哪些调试信息？

提供最小 fixture、确切命令、错误输出、相关代码、调用方、预期行为，以及影响故障的环境细节。删除秘密、个人数据和无关的生产背景。

应该立即让 AI 修复吗？

不应该。先让模型复述证据、给假设排序，并提出一项能区分原因的检查。复现之前写出的补丁，可能解决的是另一个问题。

怎样用 AI 调试间歇故障？

记录频率、时序、随机种子、执行顺序、资源状态和尝试次数。要求 AI 调试间歇故障时给出能预测这些规律的假设，再改变一个变量或加入聚焦的观测。

AI 总是提出不同修复怎么办？

回到证据账本。否决与已记录观察相矛盾的假设；如果新的迭代不再带来能区分原因的证据，就停下来。

可以分享生产日志吗？

只有在组织允许使用该服务和该数据时才可以。把日志缩到最小，删除凭证和标识，并尽可能改用合成的复现。

回归测试通过就结束了吗？

它证明的是该环境中被覆盖的那个用例。还要运行附近的测试、复核 diff，并记录仍属于其他阶段的平台、集成或生产检查。

免责声明：本文仅提供一般技术信息。真实系统应遵守组织的事故、隐私、安全和变更控制流程。

来源:

GitHub Docs — Responsible use of GitHub Copilot Chat in GitHub — https://docs.github.com/copilot/responsible-use/chat-in-github
OpenAI — Running Codex safely at OpenAI — https://openai.com/index/running-codex-safely/
NIST — Secure Software Development Framework — https://csrc.nist.gov/projects/ssdf

Sources checked 2026 年 8 月 24 日。

延伸阅读：

如何用 AI 调试代码：先复现故障，再用单一实验逐个验证假设