先讲个真事：我第一次让 AI 改一个多模块的 Maven 项目，它三十秒给出了补丁，编译通过，测试全绿。我兴冲冲点了合并，上线两周后才发现它把一处幂等校验悄悄删了——因为那行代码挡住了它要跑通的那条路径。
从那以后我对 AI 的定位就变了：它不是更快的键盘，是一个不知疲倦、手速极快、偶尔一本正经编造函数名的实习生。带实习生你得会派活、会验收、会兜底。这三件事，恰恰是后端干了几年以后最擅长、却最容易忘记自己擅长的。
这篇是「AI 技术专栏」的开篇，写给和我一样从后端过来的人：讲清楚哪些老本能直接吃、哪三门课必须补、三个月怎么排、以及五个几乎人人都会踩的坑。
一、先说结论：贬值的不是程序员，是「翻译」这个动作
过去一个后端工程师的价值链条是这样的：听懂需求 → 设计结构 → 写代码 → 调通 → 上线。其中「写代码」和「调通」这两环，在 2026 年被压缩得非常厉害——一个终端里的 agent 可以自己读仓库、改五个文件、跑测试、看报错、再改一轮。
真正没被压缩、反而变贵的是这三件事：
- 决定要建什么。「做个鉴权」不是需求。用 JWT 还是 session？刷新 token 怎么续？token 被盗了怎么吊销？这些问题的答案不在模型里，在你的业务里。
- 判断产出能不能要。生成代码越来越便宜，判断「这段代码该不该存在」越来越贵。
- 为结果负责。线上炸了，没人会去问那个 agent。
所以转型的方向不是「学怎么用 AI 写代码」，而是从执行者变成验收者。抽象层级往上抬一层：以前你管函数和行，现在你管任务和产出。
二、你身上的哪些能力可以直接迁移
这是后端转 AI 最大的优势，也是很多人没意识到的。你以为自己要从零开始，其实你已经练了好几年：
| 你已经会的 | 在 AI 工作流里的对应位置 |
|---|---|
| 看日志、看堆栈定位问题 | agent 报错时，你能一眼看出它卡在哪一步，而不是把整段报错再丢回去 |
| 读别人的代码、理调用链 | 判断它改得对不对，最快的方式是顺着调用链看一圈，而不是通读 patch |
| 写边界条件和异常分支的习惯 | AI 最缺的就是这个。它写 happy path 极快，边界永远要你补 |
| 系统设计：耦合、幂等、事务边界 | 这些是它给不出好答案的地方，也正是你的价值锚点 |
| 命令行与脚本 | 主流编码 agent 都是终端优先，你的 shell 肌肉记忆直接可用 |
| 排查线上问题的直觉 | 「这个改动上线会不会炸」的直觉，短期内没有替代品 |
反过来说，如果你这些年主要在做「把需求翻译成 CRUD」，那确实要紧张一下——因为这一层正是被压缩得最狠的。
三、必须补的三门课
第一课：把需求写成任务书
AI 不是读不懂人话，是读不懂你没说出口的上下文。对比一下这两句：
弱：给这个接口加个鉴权。
强：给 /order 下的接口加鉴权。
- 复用现有的 PostgreSQL 连接和 users 表，不要新建表
- 用项目里已有的 JWT 工具类，不要引入新依赖
- 只做服务端校验，前端不动
- 需要覆盖三种情况：token 缺失、token 过期、token 的用户已被禁用
- 先读仓库、给我方案，我确认后再动手，不要直接改数据库结构强版本多了七样东西：目标、现有架构、约束、安全要求、范围边界、验收标准、审批点。这不是什么「提示词魔法」，这就是一份合格的工程任务单——你写给同事也会这么写，只是平时偷懒了。
第二课：验收，而不是通读
新手最常见的浪费，是逐行读 AI 生成的代码。三千行 patch 你读不完，也不该读。要检查的是这几个点：
- 它动了哪些不该动的文件？先看改动清单，范围不对直接打回。
- 它有没有为了跑通而删东西？搜
git diff里被删掉的校验、被注释掉的分支、被放宽的异常捕获。这是最容易埋雷的地方。 - 新增的依赖是真的吗？模型编造包名和函数名的概率不低，编译不过还算走运，怕的是恰好有个同名包。
- 边界条件有没有？空值、超时、并发、重复请求——它默认不写。
- 测试是不是自己给自己批改卷？让 AI 写测试再自己跑通，等于让学生自己出题自己判分。测试用例要你定。
第三课：成本意识
AI 的费用结构和你熟悉的云资源不一样：它是按上下文和轮次烧的，不是按调用次数。一个 agent 在一个大仓库里反复读文件，一小时能烧掉一个聊天用户一周的用量。
要建立的习惯有三条：小任务先清上下文；能一次说清就别来回十轮；日常杂活路由给便宜模型，只在硬骨头上用贵的。这些在后面的订阅篇里会算具体的账。
四、三个月的路径安排
| 阶段 | 目标 | 具体做什么 | 过关标准 |
|---|---|---|---|
| 第 1-2 周 上手 | 把工具跑通 | 装一个终端 agent 和一个 IDE 插件；用它做真实的小任务：写脚本、补测试、解释陌生模块 | 能在不看文档的情况下完成一次「改三个文件 + 跑测试」 |
| 第 3-6 周 工作流 | 把它嵌进日常 | 给每个仓库写一份项目说明文件；练任务书写法；练验收清单；刻意让它做重构类任务 | 一次跨文件重构，你只做评审不做补全 |
| 第 7-10 周 工程化 | 从「我用」到「系统用」 | 把项目说明固化成团队规范；算清成本账；试并行任务与云端任务 | 能说出你每个月的钱花在哪、哪个环节最费 |
| 第 11-12 周 落地 | 接到业务里 | 做一个真实的 AI 功能：检索增强、或者一个能调内部接口的 agent；把安全红线落到规范里 | 有一个能对外讲的东西，且你能说清它的失败模式 |
节奏上有个提醒：别一上来就做检索增强（RAG）。那是把「模型不会答」和「你的数据怎么组织」两个难题捆在一起解。先把手上的编码工作流跑顺，收益最直接，坑最少。
五、五个几乎人人都会踩的坑
坑一：把它当搜索引擎用
问「Spring 的事务什么时候失效」然后照抄答案，是最浪费的用法。它对这类问题的回答经常是正确的废话加一两个过时的细节。正确用法是把问题放回你的仓库：「读一下这个项目的 @Transactional 用法，找出会失效的地方，给出行号」。
坑二：一次给一个巨大的任务
「把这个项目从 Spring Boot 2 迁到 3」，一句话丢过去，它会给你一个看起来很完整、实际上埋了三十处坑的方案。要拆：先让它只做调研、出方案和风险评估，你确认之后再分批改，每批改完跑一遍全量测试。
坑三：不看它删了什么
开篇那个真事就是这个坑。git diff 里最危险的不是加号行，是减号行——为了让测试通过而删掉校验，是 agent 的经典动作。养成习惯：评审时先过滤删除行。
坑四：把密钥和真实数据喂进去
API Key、数据库密码、生产环境的数据结构、客户的真实报表逻辑——这些进对话之前必须脱敏。团队协作里最好定一条硬规矩：工具可以各用各的，但敏感内容进 AI 之前必须过一道人肉脱敏。这条后面有专门的篇幅讲。
坑五：要么全信，要么全不用
两种极端都很常见：一种是它说什么都点头，上线才发现埋雷；另一种是试了一次发现它在胡说，从此认定「AI 不行」。真实状态是中间地带：它在有大量既有代码可参考的场景下很强，在需要判断和承担后果的场景下很弱。把强的地方交给它，弱的地方你守着。
六、这个专栏怎么读
接下来的几篇按「先能上手，再算清楚账，最后守得住」的顺序排：
- 工具怎么选：不给你一张三个月就过期的排行榜，给你一套自己比的判断方法。
- 订阅与上手：额度机制、配置、日常工作流，以及钱到底花在哪。
- 不翻车的三条纪律：任务书写法、代码评审清单、安全红线。
再往后会有模型行情、图像与视频、以及把 AI 接进现有系统做交付的内容。如果你只想拿走一句，那就是：AI 让你的手变快了，但也让你的判断力变得更值钱——别把时间省下来，然后花在读它写的三千行代码上。
备忘
- 转型方向不是「学用 AI 写代码」，是从执行者变成验收者：管任务，不管行。
- 可直接迁移的老本：看日志定位、读调用链、边界条件习惯、系统设计直觉、命令行。
- 必补三门课：写任务书（目标/现状/约束/安全/范围/验收/审批点）、验收产出、算成本。
- 任务书七要素：目标、现有架构、约束、安全要求、范围边界、验收标准、审批点。
- 评审优先看减号行：被删的校验、被注释的分支、被放宽的异常捕获。
- 让 AI 自己写测试再自己跑，等于自己出题自己判分——测试用例必须由你定。
- 成本按上下文和轮次烧，不是按调用次数：小任务清上下文、一次说清、杂活路由便宜模型。
- 三个月节奏：上手（2 周）→ 工作流（4 周）→ 工程化（4 周）→ 落地（2 周）。
- 五个坑：当搜索引擎用、一次给巨任务、不看删了什么、喂真实密钥与数据、全信或全不用。
- 别一上来就做 RAG，先把手上的编码工作流跑顺。
一起聊聊