Java 后端在 AI 时代怎么提效：不是多会一个工具，是重新分工
Java 后端在 AI 时代怎么提效：不是多会一个工具，是重新分工
TL;DR 「Java 后端在 AI 时代怎么提效」不是盘点 Cursor / Claude 谁更强，而是回答三件事：什么活交给 AI、什么活绝不能交、交之前你得先准备什么。 完整案例见另一篇复盘——两次人工排查无果的线上告警，AI 一晚上挖穿 60G 日志。本文只抽可复用的分工方法，并补上日常写代码时同一套逻辑怎么用。
📌 本文要点
- 提效的本质是分工，不是「让 AI 替你当高级工程师」
- 线上排查：人给上下文与方向，AI 负责读代码、批处理日志、串时间线
- 写业务：AI 可以快，边界、事务、数据一致性、发布影响面必须人把关
- 比 Prompt 更值钱的是可复用的工程底座（模块约定、脚手架、排查习惯）
- 附一份我实际在用的人机清单，可直接抄
为什么不写「工具盘点」
网上这类文章通常长这样：装了什么插件、Prompt 怎么写、谁家模型排行第一。
对 10 年左右的 Java 后端 来说，瓶颈很少是「不会用聊天框」，而是：
- 上下文在人脑子里：跳板机、哪个集群先上线、上次有没有人手工改过 consul——文档里往往没有
- 责任边界在人身上：误删对账、误判缓存语义、漏发告警，背锅的是你不是模型
- 系统是脏的：多服务双写、事件与人工操作混杂、日志按天 8G——这才是日常
所以提效问题可以改写成一句更狠的：
你能不能把问题描述清楚到「AI 能动手」，同时把关口守在「它不能乱拍板」？
最近一次把这件事做透的，是那次连发五天的服务发现残留告警。方法细节、日志和修复代码都在复盘文里，这里只借结论谈分工。
一次对照：同一条告警，两种打法
| 前两次（纯人工） | 这一次（人机） | |
|---|---|---|
| 线索 | 猜 proxy 重启、猜瞬时状态 | 代码 + 告警原文 + 机器与日志路径 |
| 体力 | 自己 grep，范围一大就累 | AI 写 expect、批量 grep、抽临时文件 |
| 结束方式 | 猜想被证伪，告警继续 | 五环 Bug 链钉死 + 点修 + 对账兜底 |
| 人真正做了什么 | 几乎全包，也几乎卡死 | 缩小时间窗、纠偏方向、要求证据、定修复策略 |
不是 AI「比我聪明」，是：翻 60G 日志本来就不该是人的核心竞争力。 人的竞争力是知道「别扫 30 天，从 7 月 2 日开始」「去看 gatewayapi」「每个结论贴日志原文」。
完整时间线、18 秒窗口、DEL 缓存污染、反证法，见：
👉 两次人工排查无果的线上告警，Claude 一晚上挖穿 60G 日志找到根因
线上排查：四条可复制的分工
1. 人负责「没写在文档里的上下文」
AI 缺的不是搜索，是你脑子里的私货：
- 这个问题第一次冒头是哪天
- 之后有没有人工动过（绑网关、手工摘节点）
- 还有哪个服务会写同一张表（proxy vs gatewayapi）
一句话上下文，往往比再开十个 grep 更值钱。
提效第一刀：开局就把背景一次给齐——仓库路径、告警原文、机器、日志目录、登录方式、你记得的时间点。
2. AI 负责「读得动、翻得快、串得起来」
适合整段外包给它的：
- 通读相关服务，标可疑分支（早退、缓存、去重）
- 自动化跳板 / 批量命令（在你授权的环境里）
- 大日志先
grep到小文件再多轮过滤 - 按时间戳拼跨服务时间线
- 起草复盘与点修补丁（合并前必须你审）
3. 强制「每个结论贴证据」
防幻觉最有效的一招不是换模型，是规则：
时间线上的每一个断言，都要能指到带时间戳的日志原文或具体代码行。
编造观点容易，编造「对得上线程名、对得上代码」的日志很难。
你从「执行者」变成「质检员」——质检比从头翻盘快一个数量级。
4. 人拍板修复策略，AI 只出方案草稿
那次最终是：
- 点修：早退清缓存、告警对称
- 兜底：对账自愈 + 熔断阈值
「要不要自动删库」「熔断阈值多少」是生产决策，不是补全建议。
AI 可以写 patch，不能替你承担 blast radius。
写业务代码时：同一套逻辑
排查是极端场景，日常写 CRUD / 活动接口时，分工可以更钝一点：
| 可以大胆让 AI 干 | 建议你亲自把关 |
|---|---|
| 按现有模块补 Entity / Mapper / DTO / 单测草稿 | 事务边界、幂等、并发与锁 |
| 按示例 Controller 扩一个资源 | 权限与数据范围 |
| 补日志、参数校验、简单分支 | Flyway 是否可回滚、是否兼容老数据 |
| 解释一段陌生代码 | 缓存语义：记的是动作还是状态 |
| 写迁移脚本初稿 | 发布顺序、双写/回滚预案 |
| 根据报错猜方向 | 要不要上线、灰度怎么切 |
一句话：
AI 适合在「已有正确范式」里加速；范式错误时，它会帮你把错误规模化。
那次主 Bug 本质就是缓存语义错位——「我做过 DEL」被当成「实体已删除」。
若让 AI 在错误语义上「优化去重」，它多半会写得更巧，坑更深。
先纠正模型（架构语义），再让它填实现。
为什么我还要搞脚手架
有人会问：都有 AI 了，还要 solo-spring-scaffold 干什么？
正因为有 AI，底座更重要。
- Initializr 空壳 + AI = 每人生成一套「貌似能跑」的分层，团队很快分裂
- 重型后台脚手架 + AI = 改不动、也不敢让模型大改
- 固定的多模块边界 + 统一返回体 / 异常 / Flyway / 可选插件，等于给 AI（和人）同一张地图
我的用法很务实：
- 骨架用生成器定死（别每次让 AI 发明包结构）
- 业务在边界内让 AI 填
- 线上问题按「上下文 → 证据 → 人拍板」排查（见上）
副业里管服务器、域名、密钥，则是另一套本地收拢：Solo Workspace。工具是分身，分工原则通用。
一份可直接用的清单
开聊 / 开排查前
- 一句话问题（现象 + 影响面 + 何时开始）
- 相关仓库 / 服务名
- 环境入口（机器、日志路径、是否要跳板）
- 你已排除的方向（避免它从头空转）
- 已知人工操作或近期发布
过程中
- 要求：结论必须带日志或代码锚点
- 大文件先抽取再分析
- 每确认一个事实就写进笔记（顺手变复盘）
- 发现「缓存 / 早退 / 双写」类语义问题，先停手讨论，再改代码
收尾
- 点修解决「为什么再发生」
- 兜底解决「漏了怎么自愈」
- 人审查 diff 与发布风险后再合入
写在最后
Java 后端在 AI 时代的提效，我目前信这三句：
- 把体力活交给模型，把判断力留在自己手里。
- 上下文和证据规则，比神奇 Prompt 管用。
- 先有稳定工程范式，再让 AI 在范式里冲速度。
完整的事故故事、Bug 链和修复代码，请看这篇（建议先读案例再回看本文的清单）：
👉 两次人工排查无果的线上告警，Claude 一晚上挖穿 60G 日志找到根因
如果你也在用 AI 查 Java 线上问题，欢迎交流：你卡在「给不够上下文」，还是「不敢信它的结论」？评论区或邮件都行。