网站刚才还好好的，改完一个按钮，忽然什么也点不动。你把报错截图发给AI，它猜是缓存；清掉缓存后，又猜是依赖。几轮之后，文件越来越多，你已经不记得第一处修改发生在哪里。
这时候，最值得找回来的往往是一件小事：用同一组操作，能不能再次看到同一个问题。
Reddit一则关于AI代理工作流程的分享把可重复出现的失败作为排错起点。本篇沿着这个问题做一个小练习，帮助刚开始接触代码的人，把“它坏了”变成可以核对的描述。
先把问题说成三句话
写下你做了什么、原本期待什么、实际发生什么。例如：“我点击加载按钮；预期显示文章标题；实际没有显示，控制台出现解析错误。”再补一句，刷新后重做同一操作是否仍然出现。
把最近的改动保留一份副本。接下来需要比较每次修复是否有效，有一个可返回的起点，会让比较更简单。
如果要提供材料，先移除密码、访问令牌和真实用户数据。最小示例通常不需要这些内容，也不需要把整个网站都贴进聊天框。
找到一份足够小、又能保留错误的输入
下面是一段专为演示写的JavaScript练习：
const raw = '{"title":"演示文章",}';
const article = JSON.parse(raw);这里的JSON文本在最后一个成员后多了逗号，解析会失败。把文本改成下面这样，才是本次练习所需的有效输入：
const raw = '{"title":"演示文章"}';
const article = JSON.parse(raw);不同运行环境的错误描述可能不同，本篇不依赖某一句固定报错。需要核对的结果很简单：前一份输入解析失败，后一份得到标题为“演示文章”的对象。
真实项目当然可能复杂得多。你要做的是逐步移除无关部分，看看留下的输入是否还会失败。删掉某一段以后问题消失了，那个变化本身就是线索。
让AI先解释发生了什么
把最小示例与三句话一起交给工具：
先说明哪一行使用了什么输入，为什么会得到当前结果。区分已经能从材料确定的原因与仍需要检查的假设。先给最小修改，不调整无关结构。最后写出怎样用原样例验证。
如果答案直接要求重装很多软件，你可以继续问：“这些操作分别要验证哪个假设？在这两行示例里，有没有更小的检查？”让每个建议都接回材料，有助于避免在互不相关的方向上忙碌。
工具的解释也可能错。对于前面的JSON例子，你可以直接运行或交给独立解析器核对，而不是只根据解释的流畅程度决定相信它。
用原来的失败，检查新的修改
修复后先重做原来的操作。如果报错消失，再看预期结果是否真的出现。只知道“控制台没红字”，还不足以证明文章标题已经正常显示。
然后再检查一个相邻情况：例如有效数据里标题为空、缺少标题，或者输入根本不是JSON。它们属于不同需求，不要为了修复一个尾逗号，就让程序在任何输入下都悄悄返回一个空结果。
明确写下当前要怎样处理这些情况：显示提示、保留空标题，还是拒绝输入。答案取决于产品需求，AI不能替你凭空决定。
结束时，留下能让下次少绕路的记录
只记四项：触发操作、实际原因、采用的修改、验证结果。失败的猜测如果解释了重要取舍，可以简短保留；整段聊天不必原样塞进项目说明。
如果最小示例与真实网站的行为不同，也要如实写出来。它说明你还没有把问题完整搬出来，接下来应继续缩小差异，而不是把一次示例通过当成全站恢复。
AI能够提供排查方向、解释代码和起草修改。你给它的输入越容易重复检查，越有机会把这些帮助变成可确认的进展。下一次出错时，先把那两行留下来，再决定要不要搬出一千行日志。