AI 辅助开发实践：我如何用 AI 工具构建一个完整的博客系统

这篇文章记录我在开发个人博客系统全程中使用 AI 工具的真实体验——包括它在哪些环节显著提升了效率，在哪些地方需要谨慎，以及如何正确地使用 AI。

整个系统包含 Spring Boot 后端、两个 Next.js 前端、Docker Compose 部署配置，共 4 个独立仓库，全程有 AI 深度介入。

AI 工具在开发中的角色分工

在开始具体讨论之前，先澄清一个认知误区：AI 不是代替你思考，而是帮你把思考结果更快地变成代码。

架构决策、技术选型、模块划分——这些需要技术判断力的事情，AI 给出的建议只能参考，最终拍板的仍然是你。但一旦决定了方向，AI 在实现环节的效率提升是颠覆性的。

二、工程化使用 AI：Rules 和 Workflow

随意地和 AI 对话能解决单个问题，但在一个有一定规模的项目里这远远不够。

没有约束的 AI 很容易生成"看起来能跑"但不符合你项目规范的代码——比如把 Controller 放错了模块，用了 @Autowired 字段注入，或者跨模块直接 JOIN 了数据库表。每次都要人工纠正，效率反而不高。

解决方案是给 AI 建立两类工程化约束：Rules（不变量） 和 Workflow（操作流程）。

Rules：告诉 AI 什么是不可违背的

项目根目录下有 .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 从第一次就做对，而不是靠反复纠正。

Workflow：告诉 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 组合的效果：

MCP Context7：让 AI 实时获取最新官方文档

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 的组合：

• Rules：约束 AI 的行为边界（绝对不做什么）
• Workflow：规范 AI 的操作步骤（怎么一步步做）
• Context7：保证 AI 使用的是最新文档（做的时候用的知识是准的）

三者结合，基本解决了 AI 辅助开发中的主要痛点：行为不可控、步骤不规范、知识过时。

三、具体场景：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 在执行一个已经明确的模式。

2. Docker 和部署配置：减少踩坑

Docker Compose、Caddyfile、GitHub Actions workflow——这些配置文件的语法并不难，但细节很多，比如：

• depends_on 短语法不等待健康检查，要用 condition: service_healthy
• Next.js 的 NEXT_PUBLIC_* 变量在构建时打包，运行时传 -e 无效
• Caddy 反向代理到 Docker 服务要用服务名，不能用 localhost

这些都是"不知道就会反复踩"的坑。AI 在生成配置的同时能解释这些细节，比单纯搜文档效率高很多。

我整个项目的 compose.yml（7 个服务）、4 个 GitHub Actions workflow、Caddyfile，都是以 AI 生成的初稿为基础，再根据实际情况调整。

3. 调试：缩短排查时间

部署过程中遇到一个问题：管理后台 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 分钟内定位并修复。

4. 代码审查角度的建议

完成一段功能实现后，把代码贴给 AI，让它从不同角度提意见：

• 有没有边界条件没覆盖
• 并发场景下是否安全
• 命名是否清晰
• 有没有更简洁的写法

这不是让 AI 替代 Code Review，而是在没有同事的个人项目里，用 AI 作为第一道检查，发现自己看习惯了注意不到的问题。

AI 不擅长什么：必须自己判断的部分

1. 架构决策

"用微服务还是单体？" "模块间怎么划分边界？" "用 JWT 还是 Session？"

AI 会给出很多方案，每个方案都有它的分析，看起来都挺有道理。但它不知道你的团队规模、项目阶段、运维能力、后期演进方向。

架构决策是权衡，不是对错题，必须由你来做。

我选择模块化单体的原因是：单人开发，运维成本要低，但代码需要有清晰边界。这是结合自己情况的判断，AI 给的是备选方案，不是答案。

2. 技术调研的准确性

AI 的知识有截止日期，对新版本特性的掌握可能不准确。

举个例子：问 Next.js App Router 的某个新行为，AI 给的答案可能是基于旧版本的，和现在实际表现不一致。

正确做法：用 AI 快速建立概念，然后去查官方文档确认，特别是涉及版本特性的细节。

3. 理解业务逻辑

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 辅助开发不是捷径，是换了一种工作方式——你的时间从"写代码"转移到了"想清楚要写什么"，而后者对技术成长更有价值。