做了 3 年后端开发后，我最大的变化不是“写代码更快了”，而是编码从“个人体力劳动”变成了“需求翻译 + 质量控制”。具体来说：我把一半编码工作交给 Claude 来完成，从接口骨架、DTO/VO、基础校验到部分业务分支的实现都让它先跑起来。这样我能把更多时间留给：架构选择、边界条件设计、性能与并发思考、以及最终的代码质量把关。

（v g.8 7 7 a i .c n）

但把 AI 当“代写”用，确实会踩坑。我的做法是：建立一个可重复的后端工程化工作流，让 Claude 输出的不只是“能跑”，而是“可审、可测、可合并”。

---

1. 先定义：哪些任务适合交给 Claude？

我把任务分成三类，分别处理：

A类：高重复、规则明确（交给 Claude）

• Controller/Router、DTO/VO 映射
• 参数校验（Bean Validation / 自定义校验）
• 基础 Service 方法骨架、简单 CRUD
• 标准化返回结构（Result/ErrorCode）
• 低风险的工具类（时间处理、分页封装、通用校验器）

B类：需要业务理解（半交半审）

• 涉及复杂规则的业务分支
• 多表联动与事务边界
• 权限/幂等策略
• 性能敏感路径（大分页、聚合查询、缓存一致性）

C类：强架构、强约束（我自己做，或极少量让 Claude 辅助）

• 核心领域建模与重构方案
• 数据模型迁移策略（尤其是生产环境）
• 复杂并发与一致性设计（锁/队列/事务隔离级别）

经验：AI 不擅长“替你承担决策责任”。它能写出代码，但你仍要决定“为什么这样做”。

---

2. 工作流：把“提需求”拆成 Claude 可执行指令

我把一次编码任务拆成 6 步，每步都尽量可校验。

步骤1：给输入上下文

• 技术栈：Spring Boot / MyBatis / JPA / ORM 选择、Java 版本
• 现有代码约束：包结构、命名风格、异常体系
• 关键对象定义：实体字段含义、枚举值、表结构摘要

步骤2：明确输出格式（强约束）

• 只输出哪些文件（例如：Controller、DTO、Service、Mapper、单测）
• 返回结构必须符合项目规范
• 需要包含注释/日志点吗（按团队规范）

步骤3：列出边界条件清单（让它“先想后写”）
例如：

• 参数是否允许为空
• 最大长度、最小值、枚举校验
• 幂等/去重规则
• 事务提交时机与回滚条件

步骤4：给“验收方式”而不是“写得漂亮”
我会要求：

• 必须有单测（覆盖正常/异常/边界）
• 必须通过静态检查（Checkstyle/PMD/SpotBugs）
• 性能：关键查询要写清楚索引要求或避免 N+1

步骤5：先产出骨架，再让它补全
我会让 Claude 先生成接口签名与关键分支的伪实现（或 TODO），我确认后再让它补全细节。
这样能显著减少返工成本。

步骤6：最后让我审“质量指标”
AI 输出不是终点，终点是：

• 可读性（命名/结构）
• 正确性（边界/异常）
• 可测性（单测与覆盖点）
• 可维护性（依赖与耦合）

---

3. 关键踩坑1：边界条件“看似对，实际上漏掉”

最常见问题是：Claude 会把主流程写得很完整，但对边界条件的理解不够“苛刻”，例如：

• “空字符串” vs “null” 的差异
• 分页参数：pageSize 上限、pageIndex 下限
• 枚举值的非法处理：返回码/错误信息一致性
• 事务：某些异常是否需要回滚、是否需要补偿

解决策略：用“清单式验收”约束它
我会在提示词里用表格或条目列出边界条件，并让它在代码中显式处理。例如要求：

• 在校验层统一处理（避免散落在业务层）
• 所有分支必须抛出项目既有异常类型/错误码
• 单测至少覆盖每条边界清单

---

4. 关键踩坑2：生成代码的“风格与依赖”不一致

另一个坑是：AI 可能会引入与你项目不一致的写法：

• 不符合你们的命名习惯（例如 DTO/VO 命名、字段命名）
• 异常处理方式与现有体系不一致
• 依赖注入方式不同（构造器/字段注入）
• 使用了项目里没有的工具类或第三方库

解决策略：建立“代码约束模板”
我会准备一个“团队规范速查卡”，固定放在每次任务的开头，例如：

• Controller 返回类型统一是 ApiResponse<T>
• 错误码映射使用 ErrorCodeEnum
• 记录日志必须在关键路径写 logger.info 或 logger.warn
• Repository/Mapper 层禁止在业务里直接写 SQL

这样 Claude 输出的代码会更贴近你的工程语境。

---

5. 让 Claude 不只是“写代码”，而是“写可合并的 PR”

我对它的要求从“生成实现”升级到“生成可合并变更”。具体做法：

1. 要求单测先行
   我通常让它先写测试用例（正常/异常/边界），并给出预期结果。
   我确认测试覆盖点足够后，再让它补实现。

2. 要求覆盖“异常路径”
   后端系统真正的价值往往在异常与边界处理。
   如果单测只测了 happy path，合入后风险会变大。

3. 要求代码可审查
   我会让它给出“变更点说明”，例如：

• 新增了哪些参数校验
• 修改了哪些错误码
• 影响的接口与返回结构是什么

1. 我只审“关键风险”
   比如：并发场景、事务边界、性能查询、数据一致性。
   其余样板代码我会少花时间反复推。

---

6. 一个小示例：接口参数校验的“可控输出”

下面示例是我在提示词里常要求 Claude 的输出风格：统一校验与异常处理。你可以把它当作“验收模板”的参考（示例为思路，非你项目的强绑定）。

java

// 示例：统一参数校验 + 明确错误码public ApiResponse<UserProfileDto> getUserProfile(String userId) {    if (userId == null || userId.isBlank()) {        throw new ApiException(ErrorCodeEnum.PARAM_INVALID, "userId不能为空");    }    // TODO: 查询逻辑（Claude先给骨架，我确认边界与异常路径后再补全）    return ApiResponse.ok(profileDto);}

我更关注两点：

• 校验条件是否覆盖 null/空/非法值
• 抛出的异常类型与错误码是否符合现有体系

---

7. 结果验证：效率提升来自“减少返工”，不是“减少思考”

我把体感拆成三块：

• 编码时长下降：接口与样板代码提速明显
• 返工减少：因为边界清单与验收方式变得标准化
• 思考时间上升：把精力从“敲代码”转到“设计质量”

如果你现在也在用 AI 辅助开发，建议你先做一个小实验：
选择一个你最讨厌返工的功能（比如参数校验 + 错误码 + 单测），让 Claude 负责 50%，然后记录返工原因。你会很快知道：效率提升的关键不是“更会写”，而是“更会验证”。

---

总结：Claude 最适合后端开发的三件事

1. 规则清晰的样板编码：DTO/Controller/校验/基础 CRUD
2. 用验收清单约束它：边界条件、异常路径、单测覆盖
3. 把输出变成可合并 PR：符合工程规范、依赖一致、风险集中审查

当你把它当“初稿生成器 + 质量控制对象”，而不是“最终作者”，后端开发的效率就会真正上去。