用 AI 写代码写到最后项目崩了，真不是模型不行，是你没搞架构

很多人用 Cursor 或者 Claude 写项目的时候，都会经历一个“魔幻时刻”：刚开始描述需求，AI 啪一下甩出一堆代码，运行起来丝滑无比，觉得自己简直是编程天才。但神奇的是，当你试图往里塞第五个、第六个功能时，整个项目就开始原地爆炸。修好一个 Bug，后面跳出两个新的，最后你甚至连该把报错信息贴给 AI 什么样都不知道。

这时候你要意识到一个扎心的事实：AI 抹平了“写代码”的门槛，但它完全没有抹平“设计架构”的门槛。

代码写得快不代表项目能跑得远。现在的现状是：你生成代码的速度，远快于你理解代码结构的速度。你就像是在驾驶一架你根本看不见仪表盘的飞机，只要自动驾驶没坏，你就觉得很爽；一旦需要手动调一下参数，你直接就原地失联了。

如果你也遇到了这种“屎山预警”，我总结了两个最硬核的生存习惯，不需要你有计算机学位，只要在跟 AI 沟通时死磕这两点：

一、 强迫 AI 把“零件”拆开，别搞大杂烩

AI 有个坏习惯：为了省事，它特别喜欢把所有逻辑全塞进一个文件里。界面渲染、业务逻辑、数据库请求，全揉在一起。项目刚起步时没问题，但一旦规模大了，改个按钮颜色可能都会导致数据库连接报错。

你必须在 Prompt 里明确要求它实现“关注点分离”。简单说，就是要把项目拆成三层：

• UI 层（用户看得到的）： 只负责按钮、布局、颜色。
• 逻辑层（App 的大脑）： 负责计算、判断、处理业务规则。
• 数据层（信息的来源）： 只负责跟数据库或 API 打交道。

你可以直接把这段指令喂给 AI：

Keep the interface (UI), the business logic, and the data access in separate files. 
Do not mix them together in a single file.

只要坚持这一条，你的项目崩溃概率起码能降一半。

二、 遵循“一文件一职责”原则

如果你发现一个函数或者一个文件，你得用“它负责干这个，并且还要干那个，顺便还得处理一下那个”来描述时，这个文件离报废就不远了。

一个健康的函数或文件，应该能用一句话说清它的唯一任务。比如 calculate_tax() 就只管算税，不该顺便去更新用户的账户余额。如果 AI 给你的代码函数长得像个“全能战士”，一定要把它拆开。

这种结构化的思维不是为了显得专业，而是为了让你在项目变大时，依然能一眼看穿哪里出了问题，而不是在几千行乱麻里玩“拆弹游戏”。