用AI写代码千万警惕：别让模型给你整出2万行的“屎山”单文件

最近在搞 Vibe Coding（也就是那种跟着 AI 节奏流的开发方式）的时候，发现了一个有点好笑但又很蛋疼的现象：如果不加干预，那些 AI 编程助手特别热衷于把所有东西都塞进一个文件里。

哪怕是一个功能稍微复杂点的项目，它也能给你硬生生堆出一个 2 万行代码的单文件来。看着那个滚动条只有针尖那么大，我是真的会谢。

AI 倾向于生成的巨型单文件代码，滚动条细如针尖

为什么 AI 爱写“巨型单文件”？

这不能全怪 AI，其实是由底层的上下文机制决定的。

巨石文件导致的代码合并冲突像意大利面一样混乱

1. 上下文连贯性：对于 AI 来说，把所有代码放在一个地方，它“看”起来最省力。跨文件引用需要它在脑子里维护复杂的文件树结构，而在一个文件里顺着往下写，它能更轻松地保持变量和函数的上下文关联。
2. 懒惰的补全逻辑：AI 的训练目标是“补全最可能的文本”。在缺少明确的架构约束时，最简单的路径就是把新函数直接加到当前文件的末尾，而不是去思考“这个模块是不是该新建一个文件”。
3. 缺乏全局视角：除非显式地给它整个项目结构，否则它在写这一段代码时，并不知道你已经有个 utils 文件夹了，它只会觉得“啊，这里好像需要个函数，那就直接写这儿吧”。

万行单文件的“毁灭性”后果

你可能觉得，“能跑不就行了吗？” 真正出问题的时候你就知道痛了。

规划良好的项目骨架能让 AI 更听话

• Review 变成阅读理解：几千行代码混在一起，逻辑跳来跳去，人类review的时候眼睛都要瞎了，根本看不出隐藏的逻辑漏洞。
• 合并冲突地狱：如果是多人协作，哪怕是你自己换个机器改代码，这种巨型文件导致的 Git 冲突能让你怀疑人生。
• 复用性极差：所有逻辑耦合在一起，想在 Next 项目里复用一段逻辑？难，你得把那坨“意大利面”拆出来才行。
• IDE 卡顿：别以为编辑器吃得消，超大文件会严重拖慢语言服务器的响应速度，写代码的体验直接降级。

如何驯服 AI，拒绝“屎山”？

既然不能不用 AI，那我们就得学会给它立规矩。在 Vibe Coding 流程中，哪怕多花一分钟做规划，也能省下后面几小时的填坑时间。

1. 先画骨架，后填血肉

不要一上来就让 AI 写具体功能。先让它生成项目结构。

指令示例：

“我要写一个电商后台，请你只输出目录结构，不要写具体代码。把路由、控制器、模型、工具函数分到不同的目录下。”

有了骨架，后面就可以用类似 Cursor 或 Windsurf 这类 IDE 的功能，把 @models 指向对应文件夹，强迫它往指定文件里写。

2. 使用 @References 引用文件

现在的 AI 编程工具大多支持引用上下文。在让它写新功能前，先把已有的文件引用进去。

*指令示例：

“参考 @userService.ts 和 @types.ts 里的定义，在 @validators 文件夹下创建一个新的数据校验文件，不要修改上述两个文件。”

明确告知“文件位置”和“不要动什么”，能有效防止它乱塞代码。

3. 设定明确的代码行数限制

这是一个很实用的技巧。

指令示例：

“这个文件如果超过 300 行，请帮我把功能拆分到子模块中，保持主文件的简洁。”

虽然 AI 数行数未必精准，但这会给它一个强烈的心理暗示：这里应该拆分了。

4. 善用模块化提示词

如果你发现 AI 开始在单文件里疯狂堆砌 class 或者 function，立刻打断它。

指令示例：

“Stop。不要继续在这个文件里写了。把关于‘支付处理’的逻辑提取出来，新建一个 paymentHandler.js，然后用 ES Modules 导入引用。”

5. 定期重构（Refactor）提示

不要一次性让 AI 生成完所有代码就跑路。每完成一个功能模块，专门发一条指令要求它优化结构。

指令示例：

“检查当前生成的代码，看是否存在职责不清的情况，如果有，请提出重构方案，将高内聚低耦合的代码独立成文件。”

总结

Vibe Coding 确实爽，生产力起飞，但千万不能当“甩手掌柜”。AI 就像一个特别能写但特别不懂整理的实习生，如果你不盯着它的文件夹结构，它能把整个工位堆成垃圾场。

核心原则还是一句老话： 哪怕是 AI 写的代码，架构设计也得由人把控。别等到真的要维护那个 2 万行的单文件时，才在深夜里流下悔恨的泪水。