AI 时代，开发者要完成的三个转变是什么？
开发者能力的"退化"不是真退化，是工具栈迁移。
- 能力转移：从骑马到开车，AI 让"手写"变成"调度"
- 第一个转变：AI 团队的 leader，懂每个领域的基础判断
- 第二个转变：架构师 + 舵手，给 AI 明确方向让船走对路
- 第三个转变：写代码被替代后，省下的脑力必须投入产品本身
- 职业范围扩张：从个人到团队，到综合性团队，最后到一个人的公司
- 结论：AI 时代不会让开发者消失，只会让"开发者"的定义变宽
能力转移：退化是错觉
"开发者能力在退化"是个伪命题。
100 年前汽车发明之后，有人说"我们的骑马能力在退化"——是的，骑马能力确实退化了，但你获得了"从一个城市移动到另一个城市"的能力。工具换了，能力的含义也换了。
AI 时代开发者丢失的是手写代码的细节能力，拿到的是和 AI 协作的调度能力。这两件事不在一个维度上——前者是"我能写出来"，后者是"我能让人（或 AI）写出来"。
关键差异：会写 ≠ 会调度。会写的人很容易陷入"我自己写更快"的陷阱；会调度的人知道什么时候该放手让 AI 干、什么时候必须亲自上手。
第一个转变：从开发者到 AI 团队的 leader
AI 时代，开发者不再是孤胆英雄，而是 AI 团队的 leader。
"团队成员"全是 AI，没有"请教同事"的选项，但 你也不能装作不懂每个领域。当 AI 给你一段支付集成代码，你不懂支付的清算流程，就没法判断代码对不对。
全局管理能力 ≠ 全栈开发。你不需要成为每个领域的专家，但你必须能判断每个领域输出的好坏。
这就像一支足球队的教练——他不是 11 个位置都踢过，但每个位置的关键动作、常见错误、胜负标准，他都要懂。否则场上换人、调整战术，他下不了判断。
具体到 AI 协作场景：
| 任务 | leader 需要具备的判断力 |
|---|---|
| AI 写 SQL | 能不能判断查询计划是否合理 |
| AI 出 UI | 能不能判断交互流程是否符合用户预期 |
| AI 写测试 | 能不能判断边界条件是否覆盖到位 |
| AI 写架构图 | 能不能判断模块拆分是否遗漏关键依赖 |
判断力的前提是基础认知。每个领域不必精，但要懂判断标准。
第二个转变：从写细节到定方向
AI 在细节上已经完胜人类——正则表达式的边界条件、异步并发陷阱、类型推导的细微差异，这些人类记不住的细节，AI 处理起来毫不费力。
如果你的核心价值是"写对细节"，那你的价值会被 AI 抹平。
反过来，AI 在"宏观判断"上依然弱——它不知道这个项目该往哪个方向走，不知道这个模块该不该独立，不知道这个改动会不会拖累其他团队。这些判断必须人来定。
所以开发者的精力要从"细节执行"转移到"方向把控"：
| 之前 | 现在 |
|---|---|
| 纠结 SQL 写法 | 设计数据模型和访问模式 |
| 调 CSS 到像素级对齐 | 设计视觉系统的设计 token |
| 手写测试覆盖每个分支 | 定义验收标准和测试策略 |
| 调试 bug 到凌晨 | 设计监控和告警体系让 bug 自己暴露 |
船长不需要是最会游泳的人，但船长必须知道港在哪、风向是什么、哪里有礁石。这才是 AI 时代开发者的核心竞争力。
方向错了，AI 越能干越糟糕。给 AI 一个错误的目标，它会以 10 倍速度产出 10 倍的废代码——这比手动写错更可怕，因为发现的时候已经晚了。
第三个转变：从开发者到产品思考者
写代码的能力被 AI 替代，不是威胁，是释放。
真正稀缺的从来不是"怎么实现"，而是"该不该做"——产品思维、前瞻性、知道业务的核心价值是什么。这些是 AI 短期替代不了的。
开发者职业范围的扩张路径非常清晰：
每一跳都是能力的横向扩展，而不是垂直深入：
- 第 1 跳：从代码到人——学习怎么带工程师
- 第 2 跳：从纯技术到综合性团队——理解产品、运营、销售的逻辑
- 第 3 跳：从团队到一个人——把过去的"团队协作"压成"AI + 工具链"
一个人的公司 是 AI 时代最现实的终局之一。一个人 + AI Agent 矩阵 + 自动化工具链，可以做出过去需要 10-20 人团队才能做的产品。
但这个终局的前提是——前两跳已经走完。没有产品思维、没有架构判断力，单干只会做出一堆没用的代码。
三个转变合在一起看
| 转变 | 核心动作 | AI 替代不了的部分 |
|---|---|---|
| AI 团队 leader | 全局管理 + 领域判断 | 跨领域判断力 |
| 架构师 + 舵手 | 定方向 + 把控关键决策 | 战略判断 + 风险识别 |
| 产品思考者 | 从代码转向业务价值 | 产品 sense + 前瞻性 |
共同点都是一样的：把"手"的工作让出去，把"脑"的工作抢回来。
AI 不是替你思考，是逼你 更密集地思考——思考约束、思考核心、思考价值。这件事和上一篇文章讲的「AI 疲劳」三种类型是同一枚硬币的两面。
怎么开始这三条转变
不要等"AI 替代完"再行动。从今天开始：
- 每次让 AI 写代码前，先自己写判断标准：验收条件、对错标准、边界情况——这些先写出来，再看 AI 输出能不能过
- 每周留出半天做"非技术"工作：产品调研、用户访谈、运营复盘——把时间从键盘上挪开
- 每个月强制让自己做一个"架构决策"：哪怕小到日志模块的拆分方式，不要把决策权完全让给 AI
三个月后回头看，你会发现"开发者"这个身份没消失——只是它变成了一个更宽的东西。
延伸阅读：Karpathy 4 条规则是什么？ —— 同样是 AI 时代下对开发者工作方式的反思