AI编程工具的真实体验：代码飘了，技术债堆了

TL;DR： 我用了三个月Copilot、Cursor和Claude Code，写了上万行AI生成的代码。结论是：AI确实让我写得更快了，但欠下的债够我还到下辈子。本文不聊幻觉和胡编，就聊那些没人愿意正面回答的问题——技术债到底是怎么来的，谁负责，谁买单。

---

"这个函数怎么写？"

"让AI看看。"

三行代码，Enter，Tab，代码出现。我没看懂，但我点击了采纳。

这就是过去一年我写代码的日常。听起来很爽对吧？但问题来了：三个月后，我面对一个Bug，完全不记得这段代码是我写的还是AI写的，更不知道它为什么这样工作。

今天不聊那些"AI编程是未来"的车轱辘话。我们聊聊，当你真的把AI塞进开发流程之后，技术债是怎么悄悄积累的，以及为什么这个问题比"AI会取代程序员"更值得焦虑。

一、速度的幻觉

先说个反直觉的数据。

我统计了三个月内的代码产出：单枪匹马写一个新功能，平均4小时。加上AI辅助，平均2.5小时。听起来效率提升了37.5%。

但我没算另一笔账：这些代码的Debug时间、Code Review时间和后期维护时间。

AI生成的代码，上帝知道它在想什么。很多时候它能跑，但它为什么这样写——抱歉，Prompt里没写，我也没问。

结果是：AI帮我加速了"写代码"这个动作，但"理解代码"和"维护代码"的时间反而增加了。这笔账，没人替你算。

二、技术债是怎么欠下的

技术债这个词大家都在说，但AI时代它有了新的含义。

第一类债：看不懂的债。

你让AI写一个排序函数，它给你写了个带泛型和函数式编程风格的版本，你点击采纳，代码入库。半年后有个实习生问你这段逻辑，你站在白板前憋了半天，最后说"这个我也不太确定，你先别动"。

这种债最要命——债务人是你，但债主是未来的你，而且利息按复利算。

第二类债：风格不统一的债。

我的项目里同时存在AI写的代码、我手写的代码、我让AI按照我的风格重写的代码、以及我让AI按照项目现有风格改过的代码。结果是什么？代码风格手册写了等于没写，因为每个人——包括AI——都在按自己的方式理解"一致"。

第三类债：过度设计的债。

你问AI："帮我写一个读取配置的函数。"

AI哗哗给你搞了个配置管理类，支持多种格式、热更新、插件机制。你说："用得上吗？"

AI说："万一用得上呢。"

结果这个"万能配置器"成了项目里最复杂的模块，而你们团队只有三个人。真正的配置需求就是读一个JSON文件。

三、谁该负责？

这是最让我困惑的问题。

我请教了身边几个Tech Lead，他们的回答分两类：

一派说："AI是工具，工具产生的问题当然工具使用者负责。"

另一派说："代码入库过了Review，Reviewer没发现问题，那Reviewer负责。"

听起来都有道理。但仔细想想，AI辅助编程的场景下，Reviewer真的看懂了代码吗？还是只是确认了"这段代码能跑，逻辑看起来没问题"？

我见过最离谱的案例是：一个AI生成的文件上传模块，用了某种特殊的编码方式绕过了安全扫描，因为AI"认为"这样可以避免文件名冲突。原代码经过了三轮Review，没人发现问题，直到某天用户上传的文件名触发了某个边界条件。

代码是AI写的，但锅是你背的。这个逻辑目前无解。

四、那些没人告诉你的坑

坑一：上下文窗口不是无限的。

很多人觉得上下文窗口越大越好，上下文越多AI越懂你。但实际情况是，当上下文超过一定规模，AI开始"遗忘"早期的内容，或者在不同段落之间产生矛盾。我现在的做法是把代码拆成小块，分别让AI理解，但这样又带来了整体一致性丢失的问题。