从抗拒AI到真香：一个老后端的开发流程自救指南
说实话，半年前如果谁跟我说“用AI写代码能提升效率”，我大概会翻个白眼，默默把键盘敲得更响一点。作为一个在公司混了三年多、VSCode插件装得比头发还多的老后端，我一直坚信：代码这东西，还得自己一行一行敲才有灵魂。
但现实嘛……总是很骨感。
去年双11大促前两周，我们团队临时接到一个需求：要在现有SpringBoot微服务基础上，快速搭一套新的资源管理后端模块，支持动态配置、权限隔离和审计日志——而且产品经理笑眯眯地说：“下周三上线，不难吧？”
不难？我差点把咖啡喷在屏幕上。
那会儿我正处在职业倦怠期，每天加班到十点，K8s集群告警半夜狂响，测试同事在群里@我说“又500了”，运维大哥一边修锅一边叹气：“你们这代码是不是没测过就上生产？”——而我，连简历都还没更新完，想着跳槽换个环境喘口气。
就在那个周五晚上，盯着满屏红叉的CI流水线，我突然想试试之前一直嗤之以鼻的GitHub Copilot。反正死马当活马医，说不定能少写几行样板代码？
结果……真香了。
被逼出来的流程改造
我们的项目是个典型的SpringBoot后端系统，用了MyBatis-Plus、Redis缓存、JWT鉴权，部署在阿里云ACK（K8s）上。以前的开发流程大概是这样的：
- 产品经理甩PRD
- 我们开会对需求（通常理解偏差）
- 手动建表 → 写Entity → 写Mapper → 写Service → 写Controller
- 自己mock数据测试
- 提PR → 等review → 合并 → 触发Jenkins → 等部署 → 测试反馈Bug → 回滚 or 热修
整个过程慢、易错、重复劳动多。尤其是那些CRUD接口，写得人麻木。比如新建一个“资源”模块，光是字段校验、分页查询、新增/编辑/删除/详情这些基础功能，就得写三四百行样板代码。
而这次双11需求里，光是“资源”相关的实体就有三个：Resource、ResourceGroup、ResourcePolicy。每个都要完整的增删改查+权限控制。
我受够了。
于是，我开始思考：能不能把这套流程标准化、自动化，甚至让AI帮我干掉那些机械劳动？
实战：SpringBoot + AI + 标准化脚手架
第一步：统一代码生成规范
我先拉了个小组会议（其实就是拉了两个同病相怜的后端兄弟），定了几条规矩：
- 所有新模块必须基于我们自研的
springboot-starter-template - Entity必须带
@TableLogic软删除、@ApiModelProperty注释 - Controller统一返回
Result<T>包装类 - Service层必须打操作日志（用AOP）
- 所有接口要有Swagger文档
然后，我把这些规范写成了一份《后端开发Checklist》，并配套了一个代码生成器模板（基于MyBatis-Plus Generator）。
// 示例：自动生成的Controller片段
@RestController
@RequestMapping("/api/v1/resource")
@Tag(name = "资源管理")
public class ResourceController {
@Autowired
private ResourceService resourceService;
@PostMapping
@Operation(summary = "创建资源")
public Result<Long> create(@Valid @RequestBody ResourceCreateDTO dto) {
return Result.success(resourceService.create(dto));
}
}
以前手动写这个，至少10分钟。现在跑个脚本，30秒搞定。
第二步：让AI干脏活
接着，我打开了Copilot（后来也试了Cursor），直接给它指令：
“基于SpringBoot 2.7，写一个ResourceService，包含create、updateById、pageQuery方法，使用MyBatis-Plus，参数校验用javax.validation，操作日志用@LogRecord注解。”
它唰唰几秒就生成了骨架代码。虽然有些细节要调整（比如权限校验逻辑没加），但80%的样板代码已经成型。我只需要专注业务逻辑——比如“资源创建时要检查配额是否超限”、“编辑时不能修改owner字段”这类真正需要人脑判断的地方。
更爽的是，Copilot还能根据我的注释自动补全测试用例。以前最烦写单元测试，现在输入：
// test: verify that create throws BusinessException when quota exceeded
它就能生成对应的JUnit测试块，连Mockito的when().thenReturn()都给你写好。
第三步：集成到CI/CD流水线
光本地爽不够，得让整个团队受益。我把代码生成器打包成Docker镜像，配了个简单的Web界面（用Vue3搭的，前端同事帮忙搞的），输入表名和字段，点一下就下载完整模块代码。
同时，在Jenkins Pipeline里加了一步：PR提交时自动运行代码规范检查（用Checkstyle + 自定义规则），不符合模板的一律打回。
我们还搞了个“资源中心”文档站（用Docsify搭的），所有新模块的API文档、数据库设计、权限模型都集中管理。新人来了不用问“这个接口咋调”，直接看文档。
效果对比：时间省了一半，Bug少了一大截
为了说服老板和同事，我做了个小统计（数据来自最近三个迭代）：
| 指标 | 改造前 | 改造后 | 变化 |
|---|---|---|---|
| 单模块开发平均耗时 | 1.5天 | 0.7天 | ↓53% |
| CR返工率 | 38% | 12% | ↓68% |
| 生产P0级Bug | 2次/月 | 0次（连续2月） | ↓100% |
| 新人上手时间 | 1周 | 2天 | ↓71% |
最让我意外的是，代码可读性反而提升了。因为大家都用同一套模板，命名规范、异常处理、日志格式完全一致。Review代码时，一眼就能看出哪里“不对劲”。
上周五，测试妹子居然在群里说：“这次提测一次过，你们后端开挂了？”
我默默回了个狗头表情。
血泪教训与真心建议
当然，这一路也不是一帆风顺。踩过几个大坑，分享出来给大家避雷：
别让AI写核心业务逻辑
AI适合干“标准动作”，但涉及复杂状态机、金融计算、安全策略的代码，一定要人工Review。有一次Copilot自动生成的权限校验漏了角色继承关系，差点线上越权。模板不是万能的，要持续演进
初版生成器没考虑多租户场景，后来加了@TenantId注解才补上。建议每季度回顾一次模板，结合新需求迭代。工具再强，也得团队共识
一开始有个老哥死活不用，觉得“AI写的代码没灵魂”。后来让他负责一个紧急需求，他熬通宵写完，结果被Checkstyle打回来三次。第二天主动找我要生成器链接……别忽视文档和培训
光有工具没人用等于零。我们搞了两次内部分享，还录了5分钟短视频教程（放在Confluence里），新人入职第一件事就是看这个。
写在最后：技术人的自救，从来不是单打独斗
回头看这段经历，其实不是AI拯救了我，而是我终于愿意放下偏见，用工具解放自己。
三年多来，我一直在“写代码”和“救火”之间反复横跳，忘了技术本该是解决问题的手段，而不是枷锁。现在，我每天花更多时间在架构设计、性能调优、和产品聊真实用户场景——这些才是真正体现后端价值的地方。
至于跳槽？简历倒是更新好了。但说实话，现在的团队氛围越来越高效、透明，我反而有点犹豫了。
如果你也在经历类似的困局——重复劳动、线上事故、职业迷茫——不妨试试从标准化 + 自动化 + 适度AI辅助开始。不用一步到位，哪怕只是先搞个代码生成器，也能省下不少头发。
对了，我们整理了一份《SpringBoot后端开发标准化实践手册》和配套脚手架代码，开源在GitHub上了（搜 springboot-backend-boilerplate 就能找到）。里面有详细教程、配置说明、以及我们踩过的所有坑。
欢迎Star，也欢迎来Issue区吐槽——毕竟，程序员的世界，不就是互相救赎嘛。
（完）
评论 0