工程化使用AI开发项目

工程化使用 AI 开发项目，并保证线上稳定

写给工作 1 - 2 年的你：一套从「入职懵逼」到「独立交付」的完整逻辑闭环。

示例架构：微服务项目 ｜ AI 工具：豆包 · WorkBuddy · Cursor ｜ 薪资参考：南昌 9 - 12k

写在前面：手写代码，真的跟不上了

先说一个扎心的现实：靠一行一行手写代码，已经跟不上项目需求了。

我见过太多外包公司，一个项目丢过来，开发周期就给 二十天。二十天是什么概念？你要熟悉业务、设计表结构、写接口、联调、测试、上线，全部塞进去。你要还是一个字符一个字符地敲，别说二十天，光 CRUD 就能把你敲到怀疑人生。

所以现在这一代开发者，拼的不是「谁打字快」，而是 谁能工程化地驾驭 AI。注意我的用词——是「工程化地使用」，不是「让 AI 随便写」。AI 随便写的代码，上线就是事故；工程化流程管出来的代码，才能保证线上稳定。

这篇博客的目标读者是 工作 1 - 2 年的新人。我会以 微服务项目架构 为例，把「新人进一家中等规模公司，从入职到独立开发」的完整流程讲成一个逻辑闭环。日常我常用的 AI 工具就三个：

  • 豆包：查资料、梳理思路、讨论业务逻辑；
  • WorkBuddy：任务编排、画逻辑图、文档与流程整理；
  • Cursor：真正的代码主战场，读写项目代码。

这三个工具不是用来「替你写代码」的，是用来 放大你的工程化能力 的。

一、先看全景：新人工程化开发的完整闭环

整个流程可以拆成四个阶段，看这张图，后面的内容全在图里：

新人入职到独立开发的完整逻辑闭环

  • 阶段一 · 入职融入：熟悉领导和业务 → 拉代码 → 配环境；
  • 阶段二 · 熟悉项目：习惯 Docker → 摸清项目结构 → 啃文档 → 领一个 CRUD 走通；
  • 阶段三 · 设计先行：理解需求 → 定义状态机 → 给 AI 立规矩（ai-rule.md）；
  • 阶段四 · AI 开发交付：SQL 先行 → AI 写代码 → 断点 + Review → 提交构建。

闭环最后一环是 复盘学习：下班补 Java 基础、JVM、底层原理，能力上去了，闭环转得更快。

二、认识战场：微服务项目架构

先把你要面对的架构搞清楚。现在中型公司的业务项目，基本长这样：

微服务项目架构（Docker 容器化）

一句话概括这条链路：

前端请求先打到 网关（Gateway），网关做路由、鉴权、限流，再分发到各个 微服务（用户、订单、库存、支付、消息……）。每个服务启动时把自己注册到 Nacos（注册中心 + 配置中心），服务之间通过 Feign 互相调用，数据落在 MySQL，热点数据进 Redis，异步消息走 MQ。而这一切，全部跑在 Docker 里。

看不懂没关系，接下来每一步都会带你把这些概念一个个踩实。

三、入职第一周：先融入，再上手

第零步：先熟悉你的领导和公司的业务流程

很多新人第一天就埋头配环境，这是错的。第一件事是熟悉你的直属领导——他决定你的绩效、你拿什么任务、你犯错时有没有人捞你。主动问一句：「哥，咱们组现在做的业务是哪块？有没有业务流程文档我先看看？」

然后花半天搞清楚 公司的业务流程：这家公司是做 MES、ERP、SaaS 还是 CRM？钱从哪来、订单怎么流、谁审核谁。技术是为业务服务的，业务都不懂，AI 帮你写出来的代码也是空中楼阁。

接着：拉取公司 Git，配置环境，跑起来

  1. 找组长要 Git 仓库权限，把前后端代码都拉下来；
  2. 配置环境。这里划重点：标准的业务开发，一定要用 Docker 来解决 Nacos、数据库、Redis 这些配置；
  3. 环境起来之后，把前端跑起来看一眼效果。看到页面能点、接口能通，你才算真正「入场」了。

四、阶段二：熟悉项目的四个步骤

第一步：习惯用 Docker，养成工程化思维

新人最容易在配置环境上耗掉三天，其实 Docker 一条命令的事。Nacos、MySQL、Redis 全部容器化，一份 docker-compose.yml 一键拉起：

Docker 本地开发环境搭建

用 Docker 有三个好处：

  1. 解决配置问题：不再纠结「我本机装的是 MySQL5.7 还是 8.0」，容器版本就是标准版本；
  2. 环境一致：你本地、同事本地、测试服务器，跑的是同一套东西；
  3. 养成工程化思维：万物皆可编排，这就是工程化的第一步。

顺手把两件事养成习惯：画逻辑图（用 WorkBuddy 画流程图、架构图，把脑子里的东西落到纸面）和 API 工具（Apifox / Postman，接口随手测）。这两个习惯会让你后面的开发速度翻倍。

第二步：熟悉项目本身

打开代码仓库，重点看这几样：

  • 数据字典：公司里所有状态、类型字段都定义在这里，这是业务的「母语」；
  • 配置文件：application-dev.yml、application-local.yml 各管什么；
  • 网关：请求从哪进来，路由规则怎么写；
  • 服务发现：Nacos 里挂着哪些服务；
  • Feign 服务调用：服务之间怎么互相调用。

然后配置你的 本地环境，这里有一条铁律：

一律不允许修改 dev 配置环境！ 你只能启动 local 服务，加载本地配置去连接你自己 Docker 里的容器。dev 是大家共用的开发环境，你改一行，全组人陪你加班。

第三步：熟悉业务开发文档、接口文档、原型 UI

业务开发文档、接口文档、原型 UI，这三样东西 第一天看不懂是正常的，坚持看就会慢慢理解。

我的经验是：把文档当成「地图」而不是「课本」，开发到哪个模块就翻哪一块。不懂的地方要多问（问组长、问老员工，脸皮厚一点没坏处），问完要记下来（建一个自己的笔记库）。同样的问题问第二次，观感就差了；同样的坑摔第三次，就是态度问题了。

第四步：领一个 CRUD，走通项目全流程

等你对项目有感觉了，主动找组长：「给我分一个 CRUD 吧」。

别嫌 CRUD 简单，它的价值是 走通整个项目的结构：建表 → 生成实体 → Mapper → Service + Impl → Controller → 联调前端。这一条路走通了，你就是「能干活的人」了。

这段熟悉期差不多 一个星期；如果你上手快，五天 就可以开始参与正式开发。

五、阶段三：设计先行——写代码之前的三件事

第五步：理解业务需求

拿到一个需求，先别碰键盘，把这几个问题回答清楚：

  • 我要 实现什么功能、解决什么问题？
  • 需要 校验哪些参数？（必填、格式、长度、业务规则）
  • 需要 查哪些表？数据从哪来、存到哪去？
  • 这个功能的实现 不能影响别人的接口和方法——这是红线；
  • 输入是什么 VO，输出是什么？参数从哪进、结果给谁看。

把上面五个问题写下来，需求就理解了 80%。

第六步：先定义状态机，再动手写代码（关键节点）

这一步是 整个流程里最关键的节点。只要你的功能涉及 订单流转状态，一定要先用 数据字典把状态机定义好：

订单流转状态机（数据字典先行定义）

  • 先定义 正向流程：待支付(1) → 已支付(2) → 已发货(3) → 已完成(4)；
  • 再定义一个 基础的反向流程：取消、退款该走哪条线；
  • 状态值 一定要递进（1、2、3、4），一眼就能看出先后顺序，将来排查问题、写 SQL 都省心。

一定不要上手直接写代码。 状态机定义好了、思路清楚了，再开始写——先想清楚再动手，永远比先动手再返工便宜。

第七步：给 AI 立规矩：ai-rule.md

既然要让 AI 写代码，就得先给它立规矩。在项目根目录放一份 ai-rule.md，每次让 AI 写代码前先把规则喂给它（Cursor 里直接放进 Rules，WorkBuddy / 豆包里贴在对话开头）：

# AI 开发规则（ai-rule.md）

## 环境红线
1. 不允许修改 dev 配置环境，本地一律使用 local profile 启动；
2. 不允许修改别人的接口定义（Controller / Feign / 对外 API）。

## 架构规范
3. 遵守 MVC 架构：Controller → Service + ServiceImpl → Mapper；
4. VO 只做参数接收；DTO 做层间 / 服务间数据传输；
   Req 用于返回数据给前端；
5. 调用别人的方法必须走 Feign，绝对不允许修改别人的代码和方法。

## 代码风格
6. 每个方法必须附带业务注释，复杂逻辑必须附带逻辑注释；
7. 逻辑必须简单易懂，不炫技，不使用实际开发用不到的
   高级算法或组件。

规矩立在前头，AI 生成的代码才有 90 分的底子。

六、阶段四：AI 开发一个功能的完整流程

第八步：把需求讲清楚，先 SQL 后代码

现在可以正式开发一个功能了。告诉 AI 时要讲清楚四件事：项目类型、需求、数据库、业务边界。

我们平时做的项目，类型大概就是这些：MES、ERP、SaaS、RBAC、IoT、HIS、Fintech、CRM，或者对接地图、微信支付、第三方系统。你要清楚你的项目是什么类型，AI 才会用对的行业语义帮你建模。

给 AI 的提示词可以照这个模板写：

项目类型：MES（制造执行系统）
需求：新增「工单报工」功能，工人在工位上报完工数量与不良品数量。
要解决的问题：目前报工靠纸质单据，数据滞后且对不上账。
使用的数据库：MySQL，涉及表 gongdan（工单）、baogong_record（报工记录）。
业务边界：只负责报工数据的记录与工单状态流转，质检模块不归本功能管。
约束：严格遵守 ai-rule.md。
第一步：先给我生成建表 SQL 和状态字典 SQL，我在数据库里测试确认后，你再写代码。

注意顺序：先让 AI 生成 SQL，你在数据库里跑一遍、测一遍，确认表结构和状态定义没问题了，再让 AI 写代码。 数据库是地基，地基不对，代码写得再漂亮都是返工。

第九步：AI 写的代码，你更要负责（重点）

这是全文 最重要的一步。现在虽然是用 AI 写代码，但签字画押的人是你，线上炸了背锅的也是你。所以：

AI 辅助开发一个功能的完整流程

1. 注释必须带上。 一定要让代码附带业务注释和逻辑注释，逻辑要简单看得懂。记住：实际开发根本用不到高级的算法或组件，谁用谁被同事问候。

2. 必须打断点测试一遍。 AI 写的代码「看起来对」和「跑起来对」是两回事，断点跟一遍，比什么都踏实。

3. 必须 Review，并记录输入输出。 把这次功能 接收的 VO、返回的 Req 记录下来，将来联调、写文档、查问题都靠它。

4. 提交前必须过一遍这张自查清单：

为什么这么严？因为中型公司都是有代码审核的，你的代码不符合规范是会被打回的。 打回一次，你在组长心里的印象分就掉一格。

5. 提交之后，一定要执行 mvn clean install。 别人拉你的代码能不能跑，就看这一步。编译不过就当场修，别留到别人拉代码报错。

七、最后的建议：基础薄弱，下班就补

流程讲完了，说点掏心窝的。

AI 能帮你写代码，但 帮你看不懂报错、帮你不理解 JVM 内存模型、帮不了你判断它写的东西对不对。你能不能驾驭 AI，上限就是你的基础。所以如果你的基础比较薄弱，下班了一定要记得学习：

  • Java 基础：集合、多线程、IO，这是吃饭的家伙；
  • JVM：内存模型、垃圾回收，线上出问题你得看得懂；
  • 底层原理：Spring 原理、MySQL 索引、Redis 数据结构，懂原理才能「保证线上稳定」。

每天一小时，三个月后你会回来谢现在的自己。

写在最后

在南昌，能把这套「工程化 + AI」流程完整跑起来的人，薪资标准就是 9 - 12k；只会手写 CRUD 的，天花板就在那里。

回顾一下整个闭环：

融入团队 → Docker 配环境 → 熟悉项目与文档 → CRUD 走通 → 理解需求 → 定义状态机 → 立好 ai-rule → 先 SQL 后代码 → 断点 Review 再提交。

AI 是杠杆，工程化是支点。支点稳了，杠杆才撬得动二十天的工期。

共勉，下期见。

本文为自包含文档：5 张逻辑配图已内嵌在文档中，无需依赖 images/ 目录，整个文件夹随便拷到哪都能正常显示。

posted @ 2026-09-20 01:42  白鹿为溪  阅读(5)  评论(0)    收藏  举报