三层架构：让AI写出整洁代码的方法

AI生成混乱的代码，是因为你的项目没有架构，而不是AI不行。三层架构可以解决这个问题。给它三个清晰的层——组件负责UI，服务负责业务逻辑，数据层负责数据库——并且一次只对一层下提示词，同一个AI就能产出整洁、可测试、可扩展的代码。我用这种方法构建了超过300万行代码。

下面是这个模式、它为什么有效，以及确切的提示词顺序。

问题：没有结构的AI会制造混乱

你让AI构建一个功能。它给你代码。你粘贴进去。一周后，你的代码库一团糟：数据库调用散落各处，业务逻辑与UI混在一起，到处是复制粘贴的代码，无法测试，一扩展就崩。

问题不在AI。问题在你的架构。

AI只生成你要求的东西。但没有清晰的架构，它会混淆关注点，制造不一致的模式，也无法维持你的代码库结构——每一条提示词都会带来新的混乱。AI并不了解你的架构。你必须引导它。

解决方案：三层架构

把你的应用想象成三层楼。顶层是组件——只负责UI。中间是服务——业务逻辑。底层是数据层——数据库和API。每一层只与紧邻其下的那一层对话。当AI知道自己在处理哪一层时，就会生成整洁的代码。

• 第1层——组件（只管UI）。属于这里的：显示逻辑、用户交互、路由、布局。不属于这里的：数据库调用、业务逻辑、验证、权限。糟糕的组件会在自己内部从数据库获取用户，顺便按状态过滤。好的组件则向一个hook请求“活跃用户”，等待时显示加载骨架屏，然后渲染列表。这就是它的全部工作。
• 第2层——服务（业务逻辑）。属于这里的：数据获取、验证、权限、业务规则、数据转换。不属于这里的：任何负责渲染的东西，或组件专属的状态。UserService知道规则——必须有组织、应用哪些过滤条件、失败时怎么办——而且这些规则只存在于这一处。
• 第3层——数据（数据库和API）。数据库查询、API调用、外部集成。只能通过服务访问，绝不能从组件直接访问。

如何用这个模式给AI下提示词

错误的做法是一条提示词：“构建一个用户管理功能。”结果是一切都在一个组件里——数据库调用、验证、UI全部混在一起。正确的做法是三条提示词，自下而上，每次一层：

1. 先写服务：“生成一个UserService，包含获取、创建、更新和删除用户的方法。包括验证和错误处理。”
2. 再写hook：“创建一个useUsers hook，用缓存包装UserService。”
3. 最后写组件：“构建一个使用useUsers hook的UserList组件。显示加载状态并处理错误。”

结果：干净、分离的代码，每一层专注于自己的职责。一次性对所有内容下提示词是头号错误——AI会生成各层纠缠在一起的混合代码。一次一层，自下而上构建。

本书The Solopreneur RevolutionLuis Gonçalves 讲述如何在不辞职的情况下用 AI 打造独立创业者事业。获取本书 →

适用于任何技术栈

同样的模式，不同的工具：

代码已经乱了？五步迁移法

1. 找出所有数据库调用。在你的组件中搜索直接的数据库和API调用。
2. 创建服务。把所有数据访问移到服务类中——原本放在组件里的查询，现在放在带错误处理的服务方法里。
3. 创建hooks。用你框架的数据获取层包装每个服务，让组件免费获得缓存和加载状态。
4. 更新组件。用一次hook调用取代在组件内部获取数据的模式。
5. 让AI帮忙。提示词：“重构这个组件以使用hook模式。把数据库逻辑移到服务中。”AI会逐块迁移。

回报立刻体现在测试上：服务无需任何UI就能测试，hooks作为薄包装来测试，组件则在模拟掉hook的情况下测试。层次清晰 = 测试轻松。

为什么这样有效

没有分层，AI会生成庞大的整体式组件，在各文件间重复逻辑，产出难以测试、难以维护、一扩展就崩的代码。有了分层，AI为每一层生成专注的代码，逻辑集中在服务中，每一层独立测试——并且可以扩展到数百万行。

我用这种方式构建了300万行以上的代码。它行之有效。这正是FIKR Space背后的确切架构：300万行以上代码、964张数据库表、5款集成产品，用Claude构建，已在生产环境中运行。要避免的两个错误：跳过服务（“我直接在hooks里用数据库就行”——hooks里的业务逻辑难以测试，也无法复用）和臃肿的组件（“我把验证放在组件里”——没有UI你就无法复用或测试它）。

发布之前，过一遍检查清单：组件中没有数据库导入，所有业务逻辑都在服务中，组件只处理UI，hooks包装服务，服务无需UI即可测试，各层都有错误处理。这个模式是生产级软件五大支柱中的第2根支柱——而一旦分层到位，像PRP方法这样的结构化提示词就会可靠得多，因为每条提示词都有明确的归属。

12 周企业职业生涯从来都不是计划申请加入 Solopreneur Accelerator。立即申请 →

常见问题

使用三层架构需要懂代码吗？

你需要看懂地图，而不是每条街道。知道UI、业务逻辑和数据访问是三个独立的楼层——而且每条提示词只针对其中一层——就足以正确指挥AI。架构是你和AI之间的沟通工具，而指挥是你这一半的工作。

小型MVP用三层是不是小题大做？

不会，因为成本几乎为零，而不这样做的代价会不断累积。第一天用三条提示词而不是一条，只是多花几分钟；到第六个月再从五十个组件里理清数据库调用，则要花几周。这个模式既能缩小到周末项目，也能扩大到数百万行——两端我都用过。

服务和hook分别放什么？

规则放在服务里；管道放在hook里。如果是业务决策——什么算有效、谁被允许、某个值怎么计算——就属于服务。如果是把数据送到屏幕上——缓存、加载标志、重新获取——就属于hook。拿不准时，放进服务：服务更容易测试和复用。

如何让AI自动遵守分层？

把规则写进你的长期项目指令：组件绝不导入数据库客户端，所有数据访问都经过服务，hooks包装服务。然后让每条提示词都点明它的层（“为……创建一个服务方法”）。AI遵循的是真正写下来的架构——而不是你脑子里的那个。