AI 能帮你写代码,但架构决定它会不会写成屎山

「在你做项目之前一定要知道架构。」

「架构非常重要。」

「要是你不知道你项目的架构，那你的 AI 写出来的代码就会是屎山代码。」

这几句话，你应该经常听到。

我以前也觉得自己听懂了。

架构嘛。

不就是整个项目的结构吗。

前端、后端、数据库、页面、接口，大概就是这些东西。

但说真的，我后来发现，我只是听懂了这个词，没有真的 get 到别人想表达的那个点。

这个感觉最明显的一次，是我之前做一个宠物 App 的时候。

这个 App 一开始其实不复杂。

就是用户可以选猫狗、选性格、选预算，然后看适合自己的宠物品种。

如果它一直只是一个筛选工具，那确实没有那么多事。

页面、数据表、接口和筛选逻辑都写清楚，基本就够了。

但后来我想把它继续往下做。

做成一个更完整的宠物社区。

它会有图文信息流、视频流和发布。

也会有点赞评论、个人主页、关注私信、登录、云存储和上线部署。

这时候你就会发现，项目已经不是「加几个功能」这么简单了。

每一个功能单独看，AI 都能写。

你跟 Codex 说，帮我加一个发布功能，它能写。

你跟 Claude 说，帮我加一个点赞功能，它也能写。

你说帮我做一个私信限制，未互关前只能发一条，它也能给你一套代码。

问题是，能写，不代表写得对。

更不代表写进你的项目以后，它还是一个健康的项目。

这也是很多人没有真正理解架构的地方。

他们以为架构就是目录。

以为前端一个文件夹，后端一个文件夹，数据库一个文件夹，这就叫架构。

但真正做项目的时候，你会发现，架构不是这个。

架构是你知道一件事应该放在哪里。

比如发布功能。

它不是只在页面上多一个按钮。

页面只是用户看到的地方。

真正要想的是，发布的数据结构是什么，图片视频放在哪里，数据库里到底存什么。

还要想清楚后端接口怎么收，前端 service 怎么请求，权限和审核应该放在哪一层。

这些东西不想清楚，你当然也能把发布功能做出来。

但它可能是这样做出来的：

页面里直接写上传逻辑，上传地址散落在好几个文件。

前端自己判断用户能不能发，后端只是照单全收。

第一次看，功能能跑。

第二次加需求，就开始痛苦。

这就是架构没想清楚之后最常见的结果。

不是代码一开始就烂。

而是每次加一点，项目就多歪一点。

我之前还遇到过一个很典型的问题。

宠物 App 在手机真机上点击「活泼好动」这类标签，会提示筛选失败。

这个问题如果只看现象，很容易误判。

你会以为是筛选算法错了，或者标签字段不一致。

也可能把问题归到后端 breeds 接口和数据库标签上。

这些地方看起来都很相关。

所以如果你直接让 AI 修，它大概率会去改这些地方。

在页面、筛选函数、接口和数据库之间来回改。

每一步看起来都像在解决问题。

但我当时真正要排查的是整条链路。

点击有没有触发，状态有没有更新。

请求是不是通过 service 发到了正确后端。

APK 打包以后，环境变量有没有被正确带进去。

后来真正的问题，不在筛选、算法或者数据库，而是在配置层。

Expo 打 APK 的时候，没有把真实后端地址注入进去。

手机里的 App 没有连到我电脑的后端，而是连到了一个 fallback 的后端地址。

所以它当然筛选失败。

不是筛选错了。

是它根本没连上真正的后端。

这件事对我来说很典型。

因为它说明了一个问题：

你不知道项目的架构，就会一直在错误的地方修。

你以为你在修页面。

其实问题在 service。

你以为你在修接口。

其实请求根本没打到那个接口。

所以架构不是为了显得高级。

架构是为了让你知道问题可能在哪一层。

一个正常的项目，不是所有代码都混在一起。

页面、组件、service、后端 route、数据库 model、配置文件，各自有自己的职责。

你知道这些职责，AI 才是在你的项目里施工。

你不知道这些职责，AI 就是在一个它也不完全理解的项目里到处补代码。

这两件事差别非常大。

比如我的 App 里，用户看到的是页面。

页面里有品种卡片、筛选面板、点赞按钮。

这些可以拆成组件。

页面想拿品种数据，不应该自己去数据库里翻。

它应该通过前端 service 去请求后端。

后端 routes 收到请求以后，再去数据库里查 Breed、Post、User 这些模型。

如果是上传图片视频，文件不应该直接塞进数据库。

文件应该放本地上传目录，或者放云存储。

数据库里只保存 URL、类型、归属关系这些信息。

如果是私信，前端可以提示用户还不能继续发。

但真正的限制必须放在后端。

比如未互关前只能发一条消息，这个规则就不能只靠页面拦。

因为前端是可以绕过的。

后端才是规则真正兜底的地方。

这些东西听起来都不酷。

但它们就是架构。

不是画一张很复杂的图，而是每一件事都有它应该待的位置。

我现在觉得，AI 写代码有一个很大的特点。

它特别擅长解决局部问题。

你给它一个报错，它能修。

你给它一个页面或按钮，它也能补出交互。

但如果你不给它项目全局，它就很容易为了把眼前这个功能做出来，直接在最近的文件里补一段代码。

短期看，很爽。

页面能点，接口有返回，功能看起来完成了。

但后面你会发现，发布、上传、登录判断全挤在页面里。

点赞状态每个组件自己存一份，接口地址到处硬编码，后端也没有兜底校验。

然后你再加功能，就会越来越难受。

所以我现在让 AI 写项目，会尽量先让它读结构。

不要一上来就写。

先让它说，这个功能会影响哪些页面、组件和 service。

也要说清楚后端 route、数据库模型、配置文件，以及哪些地方不能随便动。

我确认方向没问题，再让它写。

这件事看起来慢。

但它比后面到处补坑快太多了。

你如果不懂架构，你给 AI 的指令通常会很像这样：

帮我加一个点赞功能。

帮我修一下筛选失败。

这些指令不是不能用。

但它们太局部了。

更好的方式是先问：

这个功能应该放在哪一层。

前端和后端分别负责什么。

数据库、权限校验和状态管理要不要动。

你能问出这些问题的时候，AI 写代码才不是乱写。

它是在你的架构规则里施工。

我觉得这才是 AI 时代很多人需要补上的能力。

不是背语法。

也不是跟程序员比谁手写代码快。

而是你要知道怎么指挥 AI。

而指挥 AI 的前提，是你自己得知道项目的架构。

很多人现在的问题是，功能一个个做出来了。

但他不知道这个功能为什么放在这里。

也不知道规则到底该前端管还是后端管，bug 该从页面、接口还是配置查。

所以一出问题，就让 AI 到处改。

AI 很努力。

你也很努力。

但项目越来越乱。

这不是 AI 不行。

是你没有给它一个清楚的架构边界。

如果你也想开始练这个能力，我建议你不要一上来就让 AI 写代码。

你可以先让 AI 变成你的「架构学习教练」。

把自己的真实项目交给它，让它围绕你的项目，帮你设计一套学习路线。

下面这段提示词，你可以直接复制过去用：

你现在是我的「AI 编程架构学习教练」。我不是让你直接写代码，也不是让你直接改项目。你的任务是，基于我提供的真实项目，帮我设计一套「围绕这个项目学习编程与架构」的课程。一、我的背景1. 我不是传统程序员，编程基础较弱。2. 我现在主要靠 AI 辅助开发项目，比如 Codex、Claude、Cursor、Gemini 等。3. 我的目标不是马上变成纯手写代码的程序员，而是成为「AI 时代的应用架构负责人」。4. 我希望自己能做到：   - 看懂项目结构   - 拆清功能模块   - 判断功能应该放在哪一层   - 判断 AI 的实现方案是否合理   - 限制 AI 不乱改文件   - 避免 AI 把项目写成屎山代码   - 能让 AI 先出方案，再分模块实现，再自查二、我的项目请你基于下面这个项目来设计课程：【我的项目】项目名称：项目类型：项目目标：项目路径或代码仓库：前端技术：后端技术：数据库：当前已经完成的功能：接下来想做的功能：我目前最困惑的问题：如果你能直接访问项目文件，请先阅读项目结构。如果你不能访问项目文件，请先让我提供目录树、关键文件、页面文件、接口文件、数据库模型文件和配置文件。三、课程目标请把我训练成一个能指挥 AI 做项目的人。不是只会说：「帮我加一个功能。」而是能说清楚：1. 这个功能属于哪个页面？2. 这个功能涉及哪些组件？3. 需要哪些数据模型？4. 需要哪些接口？5. 状态应该放在哪里？6. 哪些逻辑不能写在页面里？7. 哪些文件不能乱改？8. 怎么让 AI 先出方案再写代码？9. 怎么判断 AI 有没有把项目写乱？10. 怎么避免项目越写越像屎山？四、请你设计一套完整课程课程不要泛泛讲 JavaScript、Python 或某个框架。必须围绕我的真实项目讲。请按这 8 个模块设计：模块 1，看懂项目结构让我知道项目里有哪些主要文件夹，每个文件夹负责什么，App 从哪里启动，页面在哪里，组件在哪里，接口在哪里，配置在哪里，数据库模型在哪里。模块 2，最小代码基础只教我为了看懂本项目必须掌握的变量、对象、数组、函数、条件判断、循环、import/export、JSON、async/await、type/interface。模块 3，页面、组件、状态、路由结合我的项目解释什么是 Page、Component、State、Router，功能应该放页面、组件、全局状态还是服务层。模块 4，数据模型与接口教我从功能需求反推数据结构和接口，解释 User、Post、Comment、Like、Favorite、Follow、Message 这类模型在我的项目里应该怎么理解。模块 5，前端、后端、数据库、云存储解释一个完整功能如何从前端页面，经过接口，到后端，再到数据库或文件存储。模块 6，完整项目架构图帮我设计 5 张图的学习任务，用户流程图、页面结构图、数据模型图、接口调用图、文件目录图。模块 7，AI 工程化开发指挥教我形成固定工作流，需求 → AI 阅读项目 → AI 输出方案 → 我确认架构 → AI 分模块实现 → AI 自查 → 我测试 → AI 修复 → 记录项目状态。模块 8，架构判断力教我判断什么是屎山代码，什么是模块边界，什么是低耦合、高内聚，什么是技术债，什么时候该重构，什么时候不该重构。五、每个模块都要拆成具体课程不要只给我阶段目标。请给我真正能上课的课表。每一节课都必须包含：1. 这一课学什么2. 为什么要学3. 用人话怎么理解这个概念4. 结合我的项目看哪些真实文件5. 课堂任务6. 课后作业7. 学到什么程度算过关8. 学完能回答什么问题9. 这一课对应的 AI 指挥提示词六、输出要求请输出一套完整课程方案，格式如下：1. 课程总目标2. 学习周期建议3. 当前项目结构初步判断4. 8 个模块的课程总表5. 每个模块下的具体课时安排6. 每节课的学习任务、作业和过关标准7. 每个模块的最终产出物8. 第一轮结课项目9. 以后我指挥 AI 写代码的标准提示词模板七、特别要求1. 我是零基础，请不要默认我懂专业词。2. 每个专业词都要结合我的项目解释。3. 不要空讲概念，要告诉我这个概念在我的项目里有什么用。4. 不要让我一上来刷算法。5. 不要让我系统学一堆暂时用不上的计算机基础。6. 课程重点是让我能指挥 AI 写出不乱的代码。7. 如果当前项目结构混乱，请先指出问题，再告诉我应该如何学习和整理。8. 不要直接开始讲课，先设计完整课程。9. 不要直接改代码。10. 课程必须基于我的真实项目，而不是凭空假设。

这段提示词的重点，不是让 AI 教你一堆抽象概念。

而是让它围绕你的真实项目，把结构、边界、模块和工作流先讲清楚。

所以我现在对架构的理解很朴素。

它不是为了让你显得专业。

它是为了让你知道，项目里的每一块代码为什么在这里。

它也是为了让你知道，当 AI 写了一段看起来能跑的代码时，你该怎么判断它到底是帮你修好了项目，还是给你埋了一个未来的坑。

架构不是那个画在白板上的大词。

架构是你在每次让 AI 动手之前，先问自己一句：

这段代码，应该放在哪里。

能回答这个问题，你才是在做项目。

回答不了这个问题，你只是在让 AI 往项目里堆代码。

短期看，都挺热闹。

长期看，差别会非常大。

如果你能看到这里，相信你也明白了架构到底是啥？明白架构对于你做长项目，大项目有多么大的帮助。那么不妨一键三连支持一下吧，谢谢大家了。