AI编程助手抢救烂尾项目的幻觉与现实

最近AI编程助手火得一塌糊涂。Cursor估值60亿美元，GitHub Copilot月活超百万，但一个关键问题被有意无意忽略了：当你用AI来"抢救"一个半吊子项目时，实际上是在堆砌风险。

这不是危言耸听。数据不说谎。

第一组数字：SWE-bench的迷雾

SWE-bench Verified榜单上，顶级AI模型得分已经从年初的32%冲到65%。漂亮吧？但这个榜单测的是什么？是模型能不能在已知bug修复记录的项目上"重现"修复方案。这不是真实世界的项目管理。

真实项目什么状态？一个半年前某人写的粗糙原型、技术债堆成山的遗留代码、没有人敢动的祖传模块。这些不在榜单上。

Anthropic自己做的Agent Marketplace实验揭示了一个尴尬现实：AI代理的质量差距比模型能力差距大得多。即便是同一个模型，不同代理实现可以写出天差地别的代码。有的代理能正确处理边界条件，有的连基本错误都不报。

更关键的发现是："愿望实现类"项目（快速实现已有想法）的成功率远高于"学习成长类"项目（通过项目学习新技术）。 这说明什么？AI擅长在它见过的模式上重复，但对陌生领域的判断力急剧下降。

一个典型场景：你在一个失控的项目里引入AI编程助手。短期产出确实变多了。但六个月后的维护成本呢？

代码reviewer现在要同时review人的代码和AI的代码。AI生成的代码有一个隐藏成本：理解成本。人写的代码，哪怕烂，好歹知道是按人的逻辑写的。AI写的代码，你得先搞懂AI是怎么"理解"这个问题的——这个理解过程往往比写代码还累。

AI编程助手是放大镜，不是奇迹制造器。

如果你有一个架构清晰、测试完备、边界明确的项目，AI可以帮你写得更快。但如果你想靠AI来抢救一个架构腐烂、文档缺失、边界模糊的项目——

你在借高利贷。现在还得高兴，以后得还本付息。

真正有用的做法：先把项目整理到AI能理解的状态，再用AI。 这句话烂大街，但做到的人没几个。