这篇文章记录我在开发个人博客系统全程中使用 AI 工具的真实体验——包括它在哪些环节显著提升了效率,在哪些地方需要谨慎,以及如何正确地使用 AI。
整个系统包含 Spring Boot 后端、两个 Next.js 前端、Docker Compose 部署配置,共 4 个独立仓库,全程有 AI 深度介入。
在开始具体讨论之前,先澄清一个认知误区:AI 不是代替你思考,而是帮你把思考结果更快地变成代码。
架构决策、技术选型、模块划分——这些需要技术判断力的事情,AI 给出的建议只能参考,最终拍板的仍然是你。但一旦决定了方向,AI 在实现环节的效率提升是颠覆性的。
随意地和 AI 对话能解决单个问题,但在一个有一定规模的项目里这远远不够。
没有约束的 AI 很容易生成"看起来能跑"但不符合你项目规范的代码——比如把 Controller 放错了模块,用了 @Autowired 字段注入,或者跨模块直接 JOIN 了数据库表。每次都要人工纠正,效率反而不高。
解决方案是给 AI 建立两类工程化约束:Rules(不变量) 和 Workflow(操作流程)。
项目根目录下有 .agent/rules/ 目录,里面的 Markdown 文件是对 AI 的强制约束,每次对话都自动生效。
以后端的 personal-blog-backend.md 为例,它定义了:
技术栈约束(不可更改)
- Language: Java 21
- Framework: Spring Boot 3.5.7
- ORM: MyBatis-Plus 3.5.14
- Database: MySQL 9.4.0
- Security: Spring Security 6 + JWT (JJWT 0.13.0)
AI 永远不会建议你换成 JPA,或者在这个项目里用 PostgreSQL——因为 Rules 明确声明了这是 Immutable(不可变的)。
架构约束(严格禁止项)
✅ Service → API → Common(合法依赖方向)
❌ Service → Service(严格禁止,模块间直接调用)
❌ 跨模块 JOIN 数据库表
❌ Controller 放在 blog-application 模块
有了这些规则,AI 在生成代码时会自动遵守模块边界,不会"偷懒"地跨模块调用,也不会在错误的位置创建文件。
编码规范约束
- 使用 @RequiredArgsConstructor 构造器注入,禁止 @Autowired 字段注入
- Controller 必须返回 Result<T>,不允许直接返回原始对象
- 业务异常用 throw new BusinessException(ErrorCode.XXX),禁止在 Controller 写 try-catch
- 不暴露 Entity,响应必须通过 VO
这些规范如果靠人工 Review 来保证,很容易遗漏。写进 Rules 后,AI 生成的每一段代码都会天然遵守。
前端也有对应的 personal-blog-admin.md,约束了 Next.js App Router 的组件写法、TanStack Query 的使用规范、表单必须用 Zod 验证等。deploy 仓库的 docker-compose.md 约束了 Compose 文件的格式规范(禁用 version 字段、必须有 healthcheck、必须用长语法 depends_on 等)。
Rules 的本质:把你的"老手经验"固化成规则,让 AI 从第一次就做对,而不是靠反复纠正。
.agent/workflows/ 目录下的文件是操作手册,描述特定任务的完整步骤。
以 add-api.md(添加新 REST API 端点)为例:
## 操作步骤
1. 在 *-api 模块创建 DTO/VO
- DTO 必须实现 Identifiable<T>
- VO 字段添加 @Schema 注解
2. 在 *-service 模块创建 Converter(MapStruct)
3. 创建 Service 接口和实现
- 实现继承 BaseServiceImpl<M, E, V, D, C>
4. 创建 Controller
- 返回 Result<T>
- 使用 BusinessException 处理错误
5. 验证编译
→ mvn compile -pl blog-modules/blog-module-xxx
每个步骤都有代码模板。当我说"帮我给文章模块加一个批量删除的 API",AI 会按这个 Workflow 逐步执行,不会遗漏 Converter、不会忘记 @Schema 注解,也不会把 DTO 漏掉实现 Identifiable<T>。
add-module.md 更复杂,描述了新建一个完整业务模块需要修改哪些 pom.xml、创建什么目录结构、更新哪些依赖声明——这是一个涉及 5 个文件的操作,手动做很容易遗漏,Workflow 里列明了完整检查清单。
Workflow 中标注了 // turbo 的步骤,AI 会直接自动执行对应的终端命令(如 mvn compile),无需手动确认。
Rules + Workflow 组合的效果:
| 没有规则 | 有 Rules + Workflow |
|---|---|
| 每次都要提醒"记得继承 BaseServiceImpl" | AI 自动按模板生成 |
| 偶尔生成跨模块调用的代码 | 架构约束在 Rules 里,不会发生 |
| 新加模块忘记更新某个 pom.xml | Workflow 有完整检查清单 |
| 代码风格不一致 | 编码规范在 Rules 里,天然一致 |
Rules 和 Workflow 解决了"AI 不懂我的项目"的问题,但还有另一个问题:AI 的知识有截止日期。
问 Next.js 15 的某个新特性、Tailwind CSS v4 的新语法、Spring Boot 3.5 的配置变更——AI 给出的答案可能是基于旧版本的,和当前实际行为不一致,需要自己再去查官方文档核对。
**MCP(Model Context Protocol)**是一套让 AI 能调用外部工具的协议,Context7 是其中一个工具,专门解决文档实时性问题:
用户问 AI:Next.js 15 的 use cache 指令怎么用?
没有 Context7:AI 基于训练数据(可能是旧版本)回答,可能不准确
有 Context7:AI 先调用 Context7 查询 Next.js 官方文档,基于最新版本回答
使用方式很简单,在提问时加上 use context7:
"帮我配置 Tailwind CSS v4 的
@plugin指令,use context7"
Context7 会实时拉取对应库的官方文档,AI 基于最新文档给出准确答案,而不是凭训练数据"猜"。
Context7 + Rules + Workflow 的组合:
三者结合,基本解决了 AI 辅助开发中的主要痛点:行为不可控、步骤不规范、知识过时。
项目里有 4 个业务模块,每个模块结构相似:Entity、DTO、VO、Mapper、Service、Controller。这类高度重复的样板代码,手写又慢又枯燥,还容易遗漏细节。
一句话描述需求:
"帮我生成 Article 模块的完整 CRUD,Entity 包含 title、content、status、viewCount 字段,使用 MyBatis-Plus,Service 继承 BaseServiceImpl,返回类型用 ArticleVO"
AI 给出的代码覆盖了字段注解、BaseServiceImpl 泛型参数、MapStruct 转换方法等细节,基本可以直接使用,只需要补充业务特有逻辑。
这不是 AI 在"思考架构",而是 AI 在执行一个已经明确的模式。
Docker Compose、Caddyfile、GitHub Actions workflow——这些配置文件的语法并不难,但细节很多,比如:
depends_on 短语法不等待健康检查,要用 condition: service_healthyNEXT_PUBLIC_* 变量在构建时打包,运行时传 -e 无效localhost这些都是"不知道就会反复踩"的坑。AI 在生成配置的同时能解释这些细节,比单纯搜文档效率高很多。
我整个项目的 compose.yml(7 个服务)、4 个 GitHub Actions workflow、Caddyfile,都是以 AI 生成的初稿为基础,再根据实际情况调整。
部署过程中遇到一个问题:管理后台 Docker 环境下无法访问后端 API,但本地开发正常。
错误现象:前端 fetch 请求超时,日志没有任何错误。
把现象、compose.yml、next.config.ts、Dockerfile 一起贴给 AI,AI 指出了问题:
Dockerfile 在构建阶段(builder stage)没有注入
BACKEND_URL,导致 Next.js 的rewrites配置在构建时用了默认值localhost:8080,而容器内localhost指向容器自身,不是 backend 服务。
这个问题涉及 Next.js 构建机制、Docker 网络、多阶段构建三个层面,单独排查可能需要 1-2 小时。有 AI 参与,20 分钟内定位并修复。
完成一段功能实现后,把代码贴给 AI,让它从不同角度提意见:
这不是让 AI 替代 Code Review,而是在没有同事的个人项目里,用 AI 作为第一道检查,发现自己看习惯了注意不到的问题。
"用微服务还是单体?" "模块间怎么划分边界?" "用 JWT 还是 Session?"
AI 会给出很多方案,每个方案都有它的分析,看起来都挺有道理。但它不知道你的团队规模、项目阶段、运维能力、后期演进方向。
架构决策是权衡,不是对错题,必须由你来做。
我选择模块化单体的原因是:单人开发,运维成本要低,但代码需要有清晰边界。这是结合自己情况的判断,AI 给的是备选方案,不是答案。
AI 的知识有截止日期,对新版本特性的掌握可能不准确。
举个例子:问 Next.js App Router 的某个新行为,AI 给的答案可能是基于旧版本的,和现在实际表现不一致。
正确做法:用 AI 快速建立概念,然后去查官方文档确认,特别是涉及版本特性的细节。
AI 不了解你的业务。文章状态机、评论审核流程、权限模型——这些业务规则需要你先想清楚,再描述给 AI 让它实现。
如果自己没想清楚就让 AI 写,得到的代码看起来能跑,但逻辑可能不是你真正需要的。
经过这个项目的实践,我总结出几条有效的使用原则:
提供足够的上下文
不好的提问:「帮我写一个 Service」
好的提问:「帮我写 ArticleServiceImpl,继承 BaseServiceImpl<ArticleMapper, ArticleEntity, ArticleVO, ArticleUpdateDTO, ArticleCreateDTO>,需要实现发布文章时触发 ArticlePublishedEvent 事件,并且发布前要通过 ContentProcessorChain 处理内容」
上下文越丰富,AI 生成的代码越贴合实际需求,需要修改的地方越少。
先看,再用,再改
AI 生成的代码不要直接复制粘贴,要先理解它在做什么,确认逻辑正确,然后再适配到你的项目里,再根据实际情况调整。
把 AI 当 Pair Programmer,不当外包
Pair Programming 的价值在于两个人互相审视,而不是一个人完全依赖另一个人。你需要保持主动思考,AI 负责快速落地,两者结合才能持续产出高质量代码。
使用 AI 辅助开发一段时间后,我发现它改变的不只是开发速度,还有学习的方式和深度。
过去在陌生领域踩坑时,要么反复搜文档,要么等报错堆栈慢慢猜。现在可以把问题、代码、报错一起贴给 AI,快速定位根因,再通过追问理解背后的原理。排查一个问题的时间缩短了,但对原理的理解反而更深了——因为 AI 会在给出解法的同时解释"为什么"。
更重要的变化是:思考时间的重心转移了。以前大量时间花在"怎么写这段代码"上,现在这部分交给 AI,自己则更多地思考"这段代码应不应该存在"、"这个设计有没有更好的方式"。后者才是真正的技术成长。
Rules 和 Workflow 的编写过程本身也是一种成长。为了写出准确的约束规则,必须先把自己的技术认知梳理清楚:哪些是不可变的原则,哪些是可以灵活的细节,哪些操作步骤是固定的,哪些需要根据场景判断。这个梳理过程,比直接写代码学到的东西更系统。
用 AI 搭起来的这整个博客系统,我能解释每一个架构决策背后的原因、每一段关键代码的实现逻辑——这才是真正属于自己的东西。
AI 工具降低了实现成本,但没有降低思考成本。理解这一点,才能把 AI 用出价值。
用 AI 辅助开发不是捷径,是换了一种工作方式——你的时间从"写代码"转移到了"想清楚要写什么",而后者对技术成长更有价值。
在设计个人博客后端时,我面临一个经典抉择:用简单粗暴的单体应用,还是拥抱时髦的微服务?最终我选择了两者之间的 模块化单体架构(Modular Monolith),事实证明这是正确的决定。 为什么不用微服务? 微服务固然优秀,但对于个人项目来说成本太高: - 需要服务注册、配置中心、网关、链路追踪…… - 每个服务独立部署,运维复杂度指数级增长 - 分布式事务难以处理 - 单人开发,维护多个仓库效率...
在做个人博客后端时,我发现每个业务模块都在重复同样的代码:创建实体、校验参数、调用 Mapper、处理异常……于是我设计了 BaseServiceImpl,一个基于 MyBatis-Plus 和 MapStruct 的通用 CRUD 基类。
作为一个人项目,我的博客系统包含 4 个独立仓库:后端(Spring Boot)、前端(Next.js 博客展示)、管理后台(Next.js Admin)、部署配置(Docker Compose)。最初我每次更新代码都要手动构建镜像、推送 Docker Hub、SSH 到 VPS 拉取最新版——这套流程繁琐且容易出错。
博客系统的管理后台需要处理文章的增删改查、评论审核、文件上传、系统监控等功能。这类界面有一个共同特点:大量表单 + 大量数据展示 + 频繁的服务端交互。 本文记录我在管理后台中选用的技术栈,以及每个选型背后的理由。 --- 技术栈总览 | 层级 | 技术 | 版本 | 用途 | |:---|:---|:---|:---| | 框架 | Next.
从数据库到用户界面,这篇文章记录我在个人博客系统中每一层技术选型背后的思考。整个系统包含 4 个独立仓库,涵盖 Java 后端、两个 Next.js 前端、和 Docker 部署配置。 --- 一、整体架构图 ` 用户浏览器 │ ▼ Caddy(反向代理 + 自动 HTTPS) │ ├── chonkybird.com → Next.js 博客前端(SSR) ├── admin.