我花在调试AI代码上的时间是写代码的10倍——这是改变我做法的方法

---

上周我花了三个小时调试一个只有20行的函数，而这玩意儿是AI在30秒内写出来的。听起来很荒谬对吧？但这事儿真的发生了，而且它不是个例。

大家都在吹AI写代码有多快，但没人告诉你调试AI生成的代码有多痛苦。这不是什么生产力提升，这是生产力的置换——你把打字的时间换成了调试的时间，而且大多数时候这笔交易亏大了。

我用AI辅助编程大概一年了，主要用Claude和GPT-4。时间长了，我发现一个规律：任何稍微复杂点的代码，AI给的第一个版本里一定藏着至少一个微妙的错误。不是说语法错误——那种东西好修。我说的是逻辑上的差一错误、漏掉的边界情况、或者完全瞎编的API调用方式。

最坑的是啥？AI写代码的时候自信满满，让你下意识就觉得它是对的。你跑一下，崩了，然后花十分钟琢磨“是不是我用错了”，最后才带着怀疑的眼光去看生成的代码。

来，我给你看个具体的例子。

---

一个活生生的翻车现场

当时我在写一个Node.js小服务，要从一个分页REST API里拉数据然后合并结果。我让AI写一个用while循环+offset参数处理分页的函数。

它给了我这个：

async function fetchAllPages(baseUrl, limit = 100) {
  let offset = 0;
  let allData = [];
  let hasMore = true;

  while (hasMore) {
    const response = await fetch(`${baseUrl}?limit=${limit}&offset=${offset}`);
    const data = await response.json();
    allData = allData.concat(data.results);
    hasMore = data.results.length === limit;
    offset += limit;
  }

  return allData;
}

看着挺干净对吧？我直接粘进去，跑测试，结果死循环了。

服务器在几次请求之后返回了400错误，但这个函数完全没停，因为它从来没检查过 response.ok。AI默认每次调用都会成功。

我花了45分钟调试这个——不是因为这个bug难找，而是因为我信任了它的输出。

后来我加了try/catch和状态检查，然后发现了真正的问题：这个API最后一页的 results 数组可能是空的，但AI的逻辑是 data.results.length === limit。如果最后一页返回的数据少于 limit 条，它会正确停止。但如果某次网络抖动导致数据重复，而恰好那一页返回了正好 limit 条数据，循环就会永远挂在那。

最后我把整个分页逻辑重写了。就这一个函数，我花了大概两个小时调试——生成它只花了30秒，10倍的时间。把这个比例乘以项目里的每一个文件，AI就不是在帮你省时间了，它在给你加税。

---

为什么AI代码总会出这种问题？

我琢磨了一段时间，觉得有几个核心原因。

1. LLM学的是“平均代码”，而平均代码很糙

大语言模型训练用的数据是互联网上公开的代码，这些代码里充斥着各种“能用就行”的写法。模型学会了最常见的模式，而不是最健壮的模式。它不会主动去考虑网络超时、重试机制、限流、空指针——这些在训练数据里出现的频率远低于那些“正常路径”的代码。

2. 模型不知道你的具体环境

你的API有什么诡异的行为？你的错误处理规范是什么？你的测试框架怎么用断言？AI一概不知。它生成的代码在某个地方能跑通，但不一定能在你的环境里跑通。比如上面那个例子，它假设所有fetch调用都会返回200，这在很多demo项目里确实成立，但在生产环境中就是个炸弹。

3. 代码写得自信，但毫无谦逊

AI不会在代码里写注释说“如果网络断了这里可能会崩”或者“你应该加个限流”。它输出的代码语法完美，语气笃定，但全是错的。这种自信让你在调试的时候先怀疑自己，而不是怀疑代码——这是最浪费时间的部分。

4. 调试AI代码比调试自己的代码更痛苦

因为你没有写这些代码，你没有心智模型——你不知道每一行为什么在那里。你只能反过来逆向工程AI的“思考过程”，而这个过程经常是毫无逻辑的。我见过AI生成的代码，导入了一个库，用了一次，用法和文档对不上，然后后面再也没用过。就像在读一本每段都由不同作者写的小说，而且这些作者都没看过前面的段落。

---

我后来是怎么改的？

踩了足够多的坑之后，我终于意识到：不能把AI的输出当成品，只能当第一版草稿——一个写得非常快的第一版草稿。

现在我有一套严格的工作流，分享给你。

第一步：先写测试，再开AI聊天

在打开AI聊天窗口之前，我先在测试文件里写好期望的输入和输出。我用的是Jest，但其实什么框架都行。然后我让AI生成能通过这个测试的代码。

如果第一次没过，我就把测试错误信息直接喂回prompt里。这样做能把调试时间砍掉大概60%，因为AI有了一个具体的靶子。

举个例子，如果我要写上面那个分页函数，我会先写这样的测试：

describe('fetchAllPages', () => {
  it('should fetch all pages and merge results', async () => {
    // mock一个返回3页数据的API
    const result = await fetchAllPages('https://api.example.com/items');
    expect(result).toHaveLength(300); // 假设每页100条，共3页
    expect(result[0]).toHaveProperty('id');
  });

  it('should handle empty result set', async () => {
    const result = await fetchAllPages('https://api.example.com/empty');
    expect(result).toEqual([]);
  });

  it('should handle API errors gracefully', async () => {
    // mock一个返回500的API
    await expect(fetchAllPages('https://api.example.com/error')).rejects.toThrow();
  });
});

这样AI在写代码的时候就必须考虑这些边界情况，而不是只写那个“快乐路径”的版本。

第二步：问最小功能，然后迭代

不要说“写一个分页函数”，而是说“写一个函数，给定offset和limit，获取一页数据”。先测试这个，确认没问题了，再说“现在写一个循环，把上面这个函数跑多次直到取完所有数据”。

这样能防止AI发明出你没要求的复杂逻辑。AI特别喜欢自作主张——你让它写个排序函数，它能给你整出个完整的命令行工具。拆分prompt能让你控制每一步的质量。

第三步：手动验证外部依赖

AI特别喜欢瞎编库的API。我现在养成了一个习惯：浏览器里永远开着一个文档标签页。如果AI写了 client.query("SELECT * FROM users")，我一定去查一下这个库到底有没有 query 方法。上周AI给我建议了 fs.readFileSync 带回调——这明显是错的，readFileSync 是同步的，哪来的回调？

这不是说AI不可靠，而是说它的知识是有时效性的。训练数据可能是一两年前的，库的API可能已经变了。而且对于不那么流行的库，训练数据里可能根本就没多少样本，模型只能靠猜。

第四步：用稳定的模型端点

这是我之前踩的最大的暗坑。当我用免费套餐或者轮换API key的时候，模型的行为每天都在变。今天生成的是干净的async/await，明天就变成了 .then() 链式调用还缺错误处理。我需要一个稳定的后端，不会限流我，也不会在对话中途偷偷换模型版本。

后来我开始用一个按量付费的代理服务，能让我稳定地访问同一个模型版本。比如 tai.shadie-oneapi.com 提供的API和OpenAI的格式兼容，没有配额限制，没有意外。我按请求付费，模型的输出足够可复现，这样我就能基于一个已知的基线去调试。

这不是什么银弹，但它从调试循环里移除了“为什么模型变卦了？”这个烦人的变量。

---

效果怎么样？

用了这些方法之后，我的有效调试时间从10倍降到了大概2到3倍。我花在修AI代码上的时间还是比我自己从头写要多——但总时间更少了，因为生成的速度太快了。

关键洞察是：AI加速的是“写”的部分，而这对于有经验的开发者来说从来不是瓶颈。真正的瓶颈是理解问题和验证解决方案。除非你围绕验证来组织你的工作流，否则AI帮不上忙。

我现在每天还在用AI。我只是不再信任它了。讽刺的是，正是这种怀疑态度让我更快了。因为现在当AI给我一个函数的时候，我手边已经有了测试套件、打开了文档、用着稳定的API端点。代码还是有bug，但我几分钟就能找到，而不是几个小时。

如果你也在经历同样的痛苦——花在调试AI代码上的时间比写代码还多——试试调换一下顺序：先写测试，prompt拆小，锁死模型端点。你可能会发现，AI终于变成了大家吹的那种生产力工具，而不是那个偷偷吃掉你时间的黑洞。