「AI 调试工作流怎么搭建」这种开发任务，AI 很容易显得很能干。它能马上给代码，甚至解释得头头是道。但真正让我放心的，从来不是回答，而是后面的 diff 和测试。
我会让 Cursor、GitHub Copilot、ChatGPT 各站一段：先读现有代码，再补局部实现，再看风险。「调试工作流」不能只靠一段生成结果，项目里的命名、测试和旧约定都要进来。
我会故意让第一版粗一点。「调试工作流」 如果太早变得完整，反而容易把问题藏起来。
别先让它开写
做「AI 调试工作流怎么搭建」之前，我会先找三处相似实现。这个动作有点慢，但能让 AI 少写那种“看起来正确、风格完全不贴项目”的代码。
这里先别谈大方案。先说「调试工作流」明天要被谁打开，打开以后他要做什么决定。这个问题一旦清楚，很多花哨步骤都会自动消失。
相似实现要先找
如果手上只有一句需求，我会先补材料，不会急着补提示词。「调试工作流」需要的是可检查的输入，不是更华丽的问法。
提示词里最该出现的，不是夸张形容词，而是边界。比如「调试工作流」要面向谁、产出什么、不能碰哪些事实、交给谁复核。
有时候我会先写一个很笨的判断函数，提醒自己别让 AI 一路写下去：
type DebugNextStep = "继续缩小范围" | "写最小修复" | "退回人工判断";
function chooseDebugStep(hasRepro: boolean, testsPassed: boolean): DebugNextStep {
if (!hasRepro) return "继续缩小范围";
if (!testsPassed) return "写最小修复";
return "退回人工判断";
}
真正项目里不一定就叫这个名字。重点是把“复现、最小修复、测试结果”摆出来，别只看 AI 那段解释顺不顺。
工具各管一小段
这里最怕工具互相抢活。做「调试工作流」时，我会先把它们放到不同工位上。Cursor 适合项目级阅读和跨文件修改。前提是文件范围、验收条件和测试命令先写清楚。GitHub Copilot 适合贴着编辑器补函数、样板代码和测试片段。它适合小步补，不适合替你定方案。ChatGPT 我会放在拆需求、列验收、解释错误日志的位置。它适合把模糊问题先拆成几条可检查的线。这样看起来慢一点，可交接时会少很多含糊话。
这里不需要把流程画得很豪华。只要能看出「调试工作流」的输入、输出、人工判断和沉淀位置，已经比一段很完整的 AI 回答可靠。
最后只相信 diff
我会故意把「调试工作流」读慢一点。看它有没有把diff、测试、命名、复用和无关文件改动讲清楚。没有的话，就退回去补材料，而不是继续润色。
还有个容易忽略的小坑：别在文章里写死 Cursor、GitHub Copilot、ChatGPT 的实时价格、套餐额度或地区可用性。这些东西变得太快。写清它们在「调试工作流」里的位置，就够了。
可以先拿「调试工作流」里的一个小改动试。限制文件范围，写清验收命令，改完马上跑测试。它如果连小 diff 都解释不清，就别让它继续扩大范围。
我还会在 调试工作流 旁边写一行：别让 AI 帮你省掉读代码的时间。它可以少写样板，可以提醒遗漏，但项目里的旧约定、测试习惯和命名方式，还是要自己看一遍。看过之后再让它动手，结果会稳很多。
跑完以后，我只记三件事：哪里真的省了时间，哪里让人更糊涂，哪里必须早点交给人判断。「调试工作流」能留下这些记录，就已经不是一次性生成了。
