如果你已经把 AI 用到了真实后端项目大概率很快会遇到一个问题# AI 写后端如何让 AI 守住 Controller、Service、Mapper 的边界摘要本文基于 Sourcelin Blog 项目实践分享如何让 AI 在参与后端开发时保持清晰的分层边界。核心观点是AI 写后端的关键不是写得多快而是分层不乱。文章通过真实 Controller 代码示例展示了如何通过明确的约束提示词让 AI 遵守 Controller 只收参调 Service、Service 处理业务规则、Mapper 负责 SQL、DTO/VO 按输入输出分开的分层原则。同时提供了可直接复用的提示词模板帮助开发者在实际项目中有效引导 AI 产出符合规范的后端代码。它不是写不出来而是特别容易把 Controller、Service、Mapper、DTO/VO 的边界做乱。Sourcelin Blog 这套博客服务我后面越整理越清楚AI 参与后端开发时最重要的不是“帮我快点写”而是“别把分层打散”。如果你拿一个后端服务直接扔给 AI让它“帮我加个接口”它通常不是做不出来而是很容易把分层做乱。项目入口在线演示http://sourcelin.cnGiteehttps://gitee.com/my_lyq/sourcelin-cloud-blogGitHubhttps://github.com/SourceLin/sourcelin-cloud-blogSourcelin Blog 这个项目里后端最重要的边界其实已经写得很清楚Controller 只收参、校验、权限注解、调 ServiceService 负责业务规则、事务、状态流转Mapper 负责 SQLDTO/VO 按输入输出分开这件事如果不先说清楚AI 很容易在 Controller 里塞太多东西。先看这个项目里一段真实的 Controller博客后台文章管理就在sourcelin-modules/sourcelin-blog/src/main/java/com/sourcelin/blog/controller/admin/ArticleController.java里面的列表接口其实很典型GetMapping(/list)publicPageResultArticleVOlist(Articlearticle){PageDomainpageDomainTableSupport.buildPageRequest();PageHelper.startPage(pageDomain.getPage(),pageDomain.getPageSize());ListArticleVOlistarticleService.selectArticleVoList(article);PageInfoArticleVOpageInfonewPageInfo(list);returnBlogPageResults.of(list,pageInfo);}这段代码最值得学的不是语法而是边界Controller 没有直接写 SQLController 没有自己拼返回结构分页最终收口到PageResultArticleVO这类任务我一般怎么交给 AI我会先把边界说死而不是让它“自由发挥”请在 sourcelin-blog 模块中实现一个后端能力。 要求 1. Controller 只做参数接收、权限和 Service 调用 2. Service 处理业务规则和 BusinessException 3. Mapper XML 继续放在 resources/mapper 4. 对外接口返回 PageResult、业务对象或 Void 5. 不允许返回 AjaxResult、TableDataInfo、Map有了这层约束AI 写后端会稳很多。前台文章接口也是一个很好的参考前台文章详情控制器在sourcelin-modules/sourcelin-blog/src/main/java/com/sourcelin/blog/controller/front/FrontArticleController.java比如详情接口就体现了“先查、再校验、再拼展示态”的过程GetMapping(/{id})publicFrontArticleDetailVOdetail(PathVariable(id)Longid){ArticlearticlearticleService.selectArticleById(id);if(articlenull||isDeleted(article)){thrownewBusinessException(ResultCode.NOT_FOUND,文章不存在);}// ...returndetail;}这里有两个点我觉得很适合交给 AI 学业务失败统一抛BusinessException对外返回的是明确的VO不是随手拼的Map我自己现在更喜欢怎么拆后端任务第一步先定输入和输出这一轮新增的是新建接口列表接口详情接口审核或状态流转接口不同接口DTO/VO 的边界不一样。第二步再定放在哪个模块这个项目里最常见的边界是公共能力放sourcelin-common/*业务逻辑放sourcelin-modules/*Feign 和跨服务 DTO 放sourcelin-api/*第三步最后才让 AI 写代码这一步很多人会反过来做。但后端一旦模块位置放错后面再收就麻烦很多。可以直接复用的提示词请基于 Sourcelin Blog 的后端规则完成一个博客模块需求。 先阅读 AGENTS.md、rules/backend.md、rules/api-contract.md。 要求 1. 明确这个能力属于 common、api 还是 modules 2. Controller 不直接写业务编排 3. 业务失败抛 BusinessException 4. 对外接口统一遵守 ApiResponse/PageResult 契约 5. 最后给出受影响模块的 Maven 验证命令展示这类任务里 AI 最容易跑偏的点把业务逻辑塞进 Controller返回旧协议字段直接在公共模块里写业务规则只给出代码不给验证命令我现在对 AI 写后端最看重的已经不是“快”而是能不能长期保持分层稳定。后端只要边界稳后面很多功能都能接着做文章也更有机会写成一套长期可复用的方法论。
