我用 5 个 AI 编程助“手搓”一个企业服务：真实体验报告（含踩坑）

原创于 2025-12-12 14:52:01 发布 · 737 阅读

9 ·

CC 4.0 BY-SA版权

文章标签：

#人工智能 #后端 #python #fastapi #AI编程

人工智能同时被 3 个专栏收录

15 篇文章

订阅专栏

后端

11 篇文章

订阅专栏

设计模式

6 篇文章

订阅专栏

AI工具实战测评 7.4k人浏览 22人参与

在这里插入图片描述

2025 年，写业务代码这件事，已经很难再靠“纯手搓”保持效率了。
这次，我尝试用 5 个 AI 编程助手，在一周内撸完一个「企业级对账报表服务」，顺便做了一次真实体验报告——包括所有爽点和翻车现场。

项目背景：看似平常的内部报表服务

业务场景：
给财务部做一个「对账报表服务」，每天从订单系统 & 支付系统拉数据，做汇总、对账、生成日报/月报，并提供内部 API + 管理后台。
技术栈：
- 后端：Java / Spring Boot + MySQL，使用 Maven 构建
- 前端：Vue 3（配合组件库，例如 Element Plus）
- 基础设施：Docker Compose + Nginx 反代
- 目标：
  尽量用 AI 助手贯穿从 需求澄清 → 架构设计 → 编码 → 测试 → 重构 → 文档 的全过程。

这次主要体验了这 5 个助手：

GitHub Copilot（含 coding agent）
Cursor IDE（多模型 + Bugbot 调试）
Claude Code（终端原生、擅长看大仓库）
JetBrains AI Assistant（IntelliJ 系深度集成）
基于 Qwen3-Coder / DeepSeek-Coder 的自建开源助手（VS Code + Continue 等插件）

下面请跟着我一起“闯关”，我会说清楚每关的任务、好用点、坑点以及可“拿手不谢”的可复用提示。

用 Claude Code 快速摸清旧系统 & 需求边界

场景：
财务姐姐给了一份 Excel 加上一套老系统的 Swagger 文档，还有一句话需求：

“现在对账得在三个系统来回点，你做一个统一服务，报表能导出就行。”

Claude Code 干了什么？

Claude Code 的强项是：理解大仓库 + 跨文件改代码 + 终端集成。

当时的做法：

在项目根目录装好 Claude Code，先来一句：

cc: 这个旧对账服务帮我梳理一下：
1）当前支持哪些对账维度？
2）定时任务在哪配置？
3）有哪些外部依赖系统？

它自动扫项目结构，给出了一份类似「系统导览」：
- 对账逻辑主要在 ReconcileService 下
- 定时任务用的是 @Scheduled + Cron 配置
- 外部依赖包括订单系统、支付网关、汇率服务等
接着追加了一句：

“按业务视角画一张模块图，用 Markdown 格式输出。”

得到一张可以直接贴进文档的系统结构图（文本版），发给产品/财务确认非常方便。

第一次踩坑：上下文太大 + 中文业务名

一开始直接把整个 monorepo 丢给它，Claude 给出的是一坨“看似全面但不够聚焦”的总结。
后面调整为：先用自然语言划范围，效果就好了很多：

“这次只关心 billing-*、reconcile-* 相关模块，其他模块一律忽略。”

另外，中文字段名/业务名（比如「补扣款」「调账单」）被它翻译成英文再理解，少量术语会偏差，比较稳的做法是：

先给一份术语表：

“补扣款：补扣之前漏扣的金额；调账单：人工调整流水。”
让它在后续回答中沿用这些术语。

可拿走不谢：问旧项目的 3 个万能开场白

下面这段 prompt，在接手任何遗留项目时都很好用，可以直接保存下来丢给任意 AI 助手：

我刚接手这个项目，请你用「开发者视角」帮我搞清楚：

1）这个系统的核心业务是什么？主要操作对象（实体）有哪些？
2）按模块列出大致结构，用 Markdown 的树形结构表示。
3）标出：
   - 配置入口（如 application.yml、环境变量）
   - 定时任务入口
   - 与外部系统交互的地方（HTTP/RPC/消息队列），列出 URL 或 Topic。
4）最后，请给我一个「我要改出一个新报表服务」时，最值得注意的 5 个坑点。

用 Cursor 起项目骨架 + 写 CRUD，效率拉满

场景：
新服务单独起了一个 repo。以前的流程是：
创建项目 → 配置依赖 → 写基础 CRUD → 配 DTO/VO → 写第一版接口文档……这套下来半天没了。

这次直接换到 Cursor IDE，主要让它做两件事：

生成 Spring Boot + MySQL + Maven + Dockerfile 的项目骨架；
写完基础的「对账任务」实体 + Repository + Service + Controller。

Cursor 的爽点体验

Cursor 的特点是：多模型 + IDE 深度集成 + 对话式改动。

当时的具体步骤（伪日志）：

在空目录中打开 Cursor，按 Cmd+L（Command 面板）：

“帮我创建一个 Spring Boot 3 + Java 21 + MySQL 的项目，主要做对账报表服务，使用 Maven 构建。”

几十秒后，基础项目结构就有了（含 pom.xml、application.yml、健康检查等）。
在 schema.sql 里先写了一个粗糙的表结构，然后在侧边 AI 对话中说：

“根据这个表结构，生成对应的 JPA 实体、Repository、Service 和 Controller，支持分页查询和导出 CSV。”
Cursor 直接批量修改多个文件，并展示 diff，可以一键接受或局部接受 —— 这点比传统 Copilot 的“单文件补全”舒服很多。
Bugbot（Cursor 的调试助手）还能根据测试/日志自动定位问题，尤其适合检查它自己生成的代码。

第二次踩坑：自动改动过大，review 压力飙升

Cursor 的最大问题，也是它最强的一点：太能改了。

有几次一句话下去，七八个文件被动了，连日志格式和异常处理都被“顺手优化”。
在 code review 时很难区分：哪些是想要的改动，哪些是它“顺手多做的”。

后面的做法是两条：

每次改动前限定 “施工范围”：

“这次只改 ReconcileTaskController，其他文件不要动。”
大改之前先让它生成 变更计划：

“先用列表告诉我你准备改哪些文件、每个文件的改动点，再动手。”

可拿走不谢：用 Cursor 快速起项目的脚本模板

在新仓库里准备一个 PROMPT_PROJECT_BOOTSTRAP.md 很有用，例如：

项目背景：
- 业务：对账报表服务
- 技术栈：Spring Boot 3 + Java 21 + MySQL
- 构建：Maven
- 部署：Docker Compose + Nginx

请你按以下要求生成项目骨架：
1）pom.xml 构建脚本，包含 Web、JPA、MySQL、Validation、Lombok 等依赖。
2）基础目录结构（controller/service/repository/domain/dto）。
3）健康检查接口 /actuator/health。
4）application.yml 模板，包含数据库连接、日志级别的示例配置。
5）一份 README.md，说明本地启动和 Docker 启动方式。

生成前请先用列表方式确认你打算创建的文件结构。

每次新项目直接贴这段，能省去大量重复劳动。

GitHub Copilot & Copilot Agent——从“补全”到“自动提 PR”

场景：
项目开工后，大量时间其实花在中小颗粒度的业务逻辑上：查询、数据聚合、DTO 转换、异常处理。

这部分 GitHub Copilot 依然是日常开发的 MVP，而且现在多了两个关键升级：

智能程度更高的模型（复杂逻辑生成更稳）
新增 Copilot coding agent：可以在 GitHub 上接任务、自动提 PR

搭配使用方式

在本地 IDE 中：用 Copilot 做补全和行级建议。
- 写循环、判空、DTO 映射这类体力活非常省事。
- 按团队编码规范写几个样例后，后面的补全基本都能贴合规范。
在 GitHub 上：给一些简单但重复的任务交给 Copilot Agent，比如：
- “为所有公共 API 增加请求日志和 traceId 注入”
- “给 ReconcileTaskService 生成单元测试，覆盖成功和失败路径”
做法是给 issue 写清楚任务，例如：

“请在不改变业务逻辑的前提下，为所有 @RestController 的接口增加入参日志。”

然后把 issue 分配给 Copilot，它会跑在 GitHub Actions 里生成变更并提 PR。

第三次踩坑：Agent 改过头 & 代码风格不统一

Copilot Agent 的问题和 Cursor 有点像：

PR 里经常“顺手”优化一些没有提到的部分，比如重命名变量、调整 import 顺序
如果项目没有配好 lint / format，合并之后代码风格会非常混乱

比较稳的做法是：

CI 必须配好：
- 代码格式检查（如 Spotless、Checkstyle）
- 单元测试覆盖率门槛
在 issue 里明确写上：

“只做日志注入，禁止重命名方法/类，不要改业务逻辑。”
让 Agent 先生成 设计说明 再真正修改代码：

“先用 Markdown 列出你准备改的文件和修改点，确认无误后再开始动手。”

可拿走不谢：给 Copilot Agent 的 Issue 模板

# 任务：为对账报表服务增加基础单元测试

## 背景

项目：reconcile-report-service  
语言：Java 21 + Spring Boot 3  
测试框架：JUnit 5 + Mockito

## 目标

1. 为以下类各增加至少 3 个单元测试：
   - ReconcileTaskService
   - ReportExportService
2. 覆盖的场景包括：
   - 正常路径
   - 外部系统返回异常/空数据
   - 参数校验失败

## 约束

- 不要修改生产代码的业务逻辑。
- 可以对现有代码做最小重构（如提取私有方法），但请在 PR 描述中说明理由。
- 遵守现有编码规范和格式，接受 CI 的检查。

## 交付物

- 新增的测试类和测试方法列表。
- 覆盖率变化说明。

JetBrains AI Assistant：复杂重构和调试时的“老法师”

场景：
业务迭代几轮之后，ReconcileTaskService 已经开始长成“上帝类”，里面塞满了：

多种对账策略（T+0、T+1、按渠道、按币种……）
一堆 if-else 和 switch
大量重复的日志和异常处理

这个阶段切回 IntelliJ IDEA + JetBrains AI Assistant 很合适：

JetBrains 在 静态分析、重构、调试集成 上的积累非常深，配合 AI 做复杂重构体验非常好。

一个典型的重构过程

在 IDEA 里选中整个 ReconcileTaskService，右键 → 使用 AI Assistant：

“请帮我识别这里面可以拆分的职责，按『策略模式』『模板方法模式』等经典模式给出重构建议。”
AI 结合 JetBrains 原生分析，给出了一份重构提案清单：
- 将不同对账策略提取为 ReconcileStrategy 接口的实现类
- 提取公共的日志和异常处理为模板方法
- 某些常量和魔法数字建议移到配置
接下来不是一次性全交给它改，而是按“一条提案 → 一轮改动”的方式推进，可控性更好。
遇到诡异 bug（比如对账金额偶发不一致）时，在调试状态下直接对它说：

“当前断点的入参与局部变量如上，请帮我分析这次对账金额计算为什么和预期不一致。”

它会把当前上下文里的变量值、调用栈都考虑进去给出推断。

第四次踩坑：对领域知识的误解

JetBrains AI 在代码层面很强，但对业务领域的理解几乎为零，如果不写清楚约束，会出现“技术上很优雅，但业务上不对”的建议，比如：

把“不允许部分成功”的对账逻辑拆成可回滚的小事务（业务上反而更危险）

比较稳的方式是：

在第一次对话就给它一段「领域约束前言」：

“财务要求：对于同一批次对账要么全部成功，要么全部失败，禁止部分成功。任何可能导致部分成功的建议一律不要。”
后续对话多次引用这条约束，反复强调。

自建开源助手，应对隐私 & 内网场景

场景：
服务基本可用后，接下来是 “落地到公司内网”，以及一些“不方便往外发代码”的场景。

这里选的是：

在内网部署一个 Qwen3-Coder / DeepSeek-Coder 模型服务
前端入口使用 VS Code + Continue（或团队正在使用的开源插件）

原因很简单：

Qwen3-Coder 在复杂工具调用 & Agent 场景上表现不错，适合做公司内部“开发 Copilot”
DeepSeek-Coder 在本地相对有限的 GPU 资源下，性能/性价比比较平衡，用来做代码片段生成和重构也够用

使用模式

把公司代码仓库通过 embeddings + RAG 接到模型上，只允许访问内网知识库。
让它专注做这些事情：
- 根据公司内部规范生成通用异常类、中间件
- 写符合公司标准的监控埋点、日志字段
- 帮忙整理旧项目里的“黑话”术语，写成术语表或 FAQ

踩坑：模型版本 & 温度配置

一开始偷懒直接用默认参数，结果：

Qwen3-Coder 输出经常“过度发挥”，解释一大堆不需要的东西
DeepSeek-Coder 在某些场景下给出了过时的接口写法

后来统一了几条配置策略：

temperature 调低（例如 0.2 左右），让输出更稳
为每个项目设定一份「公司规范前言」，包括日志格式、异常处理、监控埋点等
对“危险操作”（比如数据库迁移脚本）统一要求只返回伪代码或思路，实际命令由人来写

5 个助手，各自最适合的用法

1. 实际分工回顾

工具	“岗位”角色
Claude Code	老项目考古、快速摸清代码和依赖结构
Cursor IDE (+ Bugbot)	新项目起盘、写 CRUD、批量改代码
GitHub Copilot + Agent	日常编码补全、小任务自动提 PR
JetBrains AI Assistant	复杂重构、调试、配合静态分析做决策
Qwen3/DeepSeek 自建助手	内网私有 Copilot、公司规范/术语助手

2. To 个人开发者

预算有限 / 个人开发者：
- 核心工具可以在 Cursor 与 GitHub Copilot 中二选一，不必一口气全开。
- 再配一个开源模型（Qwen / DeepSeek）做离线或内网补充。
JetBrains 重度用户：
- JetBrains AI Assistant 直接开箱即用，不需要额外折腾太多插件。
对隐私极度敏感 / 金融、政企场景：
- 至少需要引入一个 自建开源模型，不能所有代码都喂给公网服务。