Cursor写了一周的代码，我验收时差点砸了电脑

300万行AI代码写了个浏览器，结果连编译都通不过

一、事情的起因

上个月接了个活，重构一个老旧的管理后台。

项目不大，但业务逻辑绕得很——权限分级、审批流、多租户数据隔离，每块都跟其他模块有耦合。按理说这种活不该交给AI，但当时赶工期，我想着“Cursor吹得那么神，让它先搭个架子，我再改”。

于是把项目喂给Cursor，开启Composer模式，让它自己跑。

一周后，我打开IDE验收。

第一个感觉是：代码量真大。一周时间，AI生成了小两万行代码，覆盖了登录、权限、用户管理、审批流、数据看板等七八个模块。

第二个感觉是：这玩意根本跑不起来。

启动报错38个，TypeScript类型错误横跨十几个文件，路由配置里引用了不存在的组件，接口调用写死了测试环境的域名，还有一个审批流的核心逻辑——逻辑完全是反的。

我花了整整两天把项目修到能跑。然后又花了一周把AI写的代码几乎全部重写了一遍。

这不是我第一次被AI代码坑，但这是坑得最惨的一次。

二、Cursor到底出了什么问题？

问题一：宣传和现实的差距

今年1月，Cursor官方发了一篇博文，说他们让AI智能体自主运行了近一周，在1000个文件中编写了超过100万行代码，从零构建了一个网络浏览器。

消息一出，全网沸腾。

但技术社区很快就打了假。有开发者clone了那个仓库，执行cargo build，结果直接报错——34个编译错误，94个警告。GitHub Actions的多次运行也全部失败。

说白了，那300万行代码就是个无法编译的“AI泔水”。

Cursor的问题不是技术不行，是太急了。急着证明AI能取代人，急着用营销冲淡产品缺陷。

问题二：代码质量雪崩

有用户在Cursor官方论坛吐槽，说AI经常用100行垃圾代码替代一行正则。还有人发现，让AI别硬编码年份，它反手又写了一个死数字。

我遇到的情况更典型：

场景一：风格完全不匹配

项目用的是Vue 3 Composition API + <script setup>，AI给我生成了Options API的代码，命名全是camelCase但项目规范要求PascalCase，还自作主张引了lodash——项目里根本没装。

场景二：上下文丢失

让AI改一个模块的接口调用方式，它改了，但顺手把另外三个不相关的模块也改了，改完还编译不过。

场景三：自信地制造Bug

有一段审批流代码，AI把“通过”和“驳回”的逻辑写反了。更离谱的是，代码注释写的是“处理审批通过逻辑”，代码里执行的却是驳回。

CodeRabbit的《2025年度AI与人类代码生成现状报告》给出了数据支撑：AI生成的代码，逻辑错误率比人类高出75%，整体缺陷率是人类的1.7倍。AI参与的PR平均每100个包含10.83个问题，而人类手写的只有6.45个。

问题三：上下文理解是硬伤

Cursor最大的卖点是“整个代码库级别的上下文理解”。但实际用下来，这个能力在复杂项目里基本是摆设。

原因很简单：AI没有真正的“理解” 。它能扫描你的代码库，能索引符号表，但它不理解你的业务逻辑，不理解你们公司的代码规范，不理解你们用了什么基础框架。

有开发者做过实测：在处理包含多层嵌套逻辑的业务系统时，AI生成的代码经常出现业务逻辑断层——税费计算没和折扣联动、重复计算小计、忽略边界条件。

我那个项目里，AI甚至把多租户数据隔离的逻辑给忽略了——这相当于给所有用户开放了全部数据。

问题四：“氛围编程”的效率错觉

METR研究所做了一项对照实验，追踪了16名高级开发者在真实项目中完成246个任务。结果发现：使用AI工具的开发者，完成任务的时间平均增加了19%。

更讽刺的是，这些开发者自己觉得“省了20%的时间”。

为什么会有这种错觉？

因为AI把开发者的工作方式打碎了。以前是“思考→编码→调试”的线性流程，现在是“写提示→等响应→读代码→改提示→再等响应→审查产出→人工修正”的碎片化流程。你一直在动，但前进的距离并没有变远。

三、我是怎么把AI用明白的

踩了这么多坑，我总结了一套“AI编程不翻车”的方法论。

1. 别让它自由发挥，给它画好框

不要把AI当独立开发者用。它就是一个特别能写但特别没脑子的实习生。

正确的做法是把上下文喂饱：

帮我开发一个用户管理组件，要求如下：

技术栈：
- Vue 3 + Composition API（<script setup>语法）
- TypeScript
- Element Plus（已安装，直接用）
- 不要引入项目之外的额外依赖

代码规范：
- 组件名PascalCase，变量/函数camelCase
- 接口类型统一用interface定义
- 注释用中文

业务规则：
- 用户列表分页，每页20条
- 搜索支持姓名、手机号、邮箱
- 禁用操作需要二次确认
- 不要硬编码任何URL或密钥

把“你们项目不用的东西”明确排除掉，比只说“要用什么”效果更好。

2. 报错修复，把完整上下文给它

很多人的习惯是把报错截图丢给AI，然后问“怎么办”。这样AI只能泛泛分析，给一堆“可能的原因”。

正确的做法是：报错信息完整粘贴（含堆栈）+ 出问题的完整组件代码 + 项目背景。这样AI一次就能定位问题，不用来回拉扯。

3. 模型选对，别用Auto

Cursor的Auto模式会随机选择模型，有时候给你用个很差的模型，生成的代码几乎不可用。

我的做法：复杂业务用Claude 3.5 Sonnet，简单补全用本地模型（Ollama + deepseek-coder）。GPT-5在Cursor上目前体验不稳定，上下文窗口太大反而导致“注意力涣散”。

4. 控制上下文窗口

Cursor默认把整个代码库喂给模型，导致上下文过大、模型“注意力涣散”。

在cursor.settings.json里把max_context_tokens从默认砍到8000左右，响应速度和代码质量都会有明显提升。

5. 验收标准不能降

AI写的代码，每一行都要Review。这不是不信任，这是基本工程素养。

我现在的流程是：AI生成 → 我Review → 跑测试 → 有问题让AI修 → 再Review → 合并。

虽然听起来麻烦，但比“AI生成完直接上线然后出大事故”省事多了。

四、说点实在的

AI编程工具是个好东西，但它不是银弹。

它擅长的是：写模板代码、补全重复逻辑、生成单元测试、解释陌生代码。

它不擅长的是：理解复杂业务逻辑、做架构决策、处理多模块耦合、遵循项目规范。

Cursor写了一周的代码让我差点砸了电脑，问题不在Cursor，在我。

是我误把AI当成了能独立交付的工程师，是我没给它足够的上下文和约束，是我验收时放松了警惕。

AI写代码这事，快是它的，质量得自己兜着。

别让“氛围编程”的幻觉，毁了你代码库的健康。