第1897篇：AGI来临前的准备——工程师如何在过渡期保持价值
第1897篇：AGI来临前的准备——工程师如何在过渡期保持价值
"AGI"这个词，我现在有点怕提，因为一提就容易陷进两种无聊的讨论：一种是末日论，说AGI来了程序员都完蛋；另一种是盲目乐观，说AGI还远着呢，不用担心。
这两种我都不想讲。今天想讲的是：不管AGI什么时候来，在到来之前的这段时间——也就是我们正在经历的过渡期——工程师应该怎么做，才能让自己持续有价值？
一、"过渡期"是什么意思
先定义一下我说的"过渡期"。
当前我们处在"强AI工具"阶段：大模型能够完成大量任务，但还需要人来定义问题、验证输出、处理异常、做系统集成。这个阶段，人和AI是协作关系，各自有分工。
AGI（通用人工智能）如果实现，意味着AI能够完全自主地完成任何认知性任务，不需要人的介入。这个阶段，"程序员"这个职业的形态会发生根本性变化——但这还需要相当长的时间。
过渡期的特征是：AI能力在快速提升，但提升是有方向性的——某些类型的工作AI越来越擅长，某些类型的工作AI进步很慢甚至看不到进步。
理解这个方向性，是制定个人职业策略的关键。
二、过渡期AI能力提升最快的方向
这是我综合了多方观察得出的判断：
快速提升的方向（3-5年内会有质变）：
- 代码生成和理解（特别是有上下文的代码补全）
- 测试用例生成和自动化测试
- 文档生成和技术写作
- 代码审查的初步分析
- 标准化的系统集成代码
提升较慢的方向（可能需要10年+）：
- 理解复杂业务场景和组织政治
- 处理模糊的、矛盾的需求
- 跨团队的技术协调
- 架构决策中的业务判断
- 技术团队的管理和培养
三、过渡期的个人策略
策略一：主动把自己迁移到AI缓慢提升的区域
这不是说完全不做AI能做的事，而是说：你工作的重心和价值锚点，要逐渐向AI难以替代的方向迁移。
举个具体的例子。同样是一个Java后端工程师，A的日常工作是写CRUD接口、改bug、写单元测试。B的日常工作是参与需求评审、设计系统架构、Code Review、指导初级工程师。
在AI快速提升的过渡期，A面临的压力会比B大得多。不是说A现在就要被替代，而是A的每一项工作，都有被AI分摊的趋势。
策略二：成为AI能力的放大器，而不是竞争者
这句话我说过很多次，但值得再说一遍。
过渡期最稀缺的人才，不是"最厉害的程序员"，而是"能把AI能力用到最大价值的程序员"——就是那种能把AI当成得力工具，产出远超过去的人。
这需要一个认知转变：从"我会做什么"转向"我能指挥什么"。你设计任务、分解问题、验证结果、把关质量——AI执行大部分的技术劳动。
策略三：积累对AI系统的深度理解
有一类知识，在过渡期会越来越值钱：对AI系统行为的深度理解。
能回答这些问题的工程师，稀缺而且价格不低：
- 这个场景下用RAG还是直接用大模型？为什么？
- Prompt为什么这么写，而不是那样写？
- 模型出现幻觉的根本原因是什么？怎么系统性地降低？
- Agent系统在什么情况下会失控？怎么设计故障保护？
- 向量检索的召回率低是什么原因，怎么排查？
这些问题的答案，需要对大模型原理、工程实践都有理解，不是靠背文档能得到的。
四、从"写代码"到"设计系统"的迁移路径
这是一个很多人想做但不知道怎么开始的转变。
过渡期的一个重要机会是：AI工具让你可以用更少的时间做"写代码"的工作，你可以用省出来的时间投入到"设计系统"的学习和实践中。
具体来说，我建议这样做：
第一步：把AI辅助编程的效率提到极致
不要半心半意地用AI工具。Cursor、Copilot、Claude——选一个主力工具，把它的能力压榨到极限。不是让AI帮你写点代码，而是让AI帮你完成整个功能模块的初版，你只做方向指导和把关。
效率提升之后，你每天会省出2-3小时。这是关键资源。
第二步：用省出来的时间学系统设计
系统设计的学习路径：
- 深读几本经典书（《设计数据密集型应用》《微服务架构设计模式》）
- 研究真实的开源项目架构
- 主动请缨参与团队里的架构讨论
- 整理自己参与的项目的架构决策，写架构设计文档
第三步：建立技术影响力
从方案评审开始，逐步建立起"在技术判断上有发言权"的位置。这不是靠资历，是靠持续输出有质量的技术判断。
五、"AI不可替代"的能力如何刻意练习
聊到"技术领导力"、"架构决策"，很多人会说：这些不是靠学的，是靠年限积累出来的。
这个说法有道理，但不完全对。这些能力是有方法可以加速的。
刻意练习一：架构复盘
每个参与过的项目，做一次架构复盘：当初的设计决策是什么？回头看哪些是对的，哪些走弯路了？如果重来一次会怎么设计？
坚持写架构复盘文档，三年下来你的判断力会远超同龄人。
刻意练习二：阅读和理解技术决策
行业里有大量公开的技术决策文档：Netflix技术博客、阿里技术、美团技术团队的文章——这些文章里讲的不只是"怎么做"，而是"为什么这么做"。学习这个"为什么"的思维方式。
刻意练习三：主动提出方案，接受评审
在团队里，主动提需求方案。被质疑、被反驳——这是最快的成长。脸皮厚一点，多经历几次，你对技术方案的判断力会快速提升。
刻意练习四：负责技术全局
争取负责一个完整功能的技术全局——从需求理解到架构设计到实现到上线。不是做局部模块，而是对整体负责。这种全局责任感，会逼迫你思考你平时不会主动考虑的问题。
六、一个具体的AI辅助架构设计实践
说点实际的。我现在做架构设计的时候，会把AI当成"第一轮审视者"：
// 用AI辅助架构审查的工作流
public class ArchitectureReviewWorkflow {
/*
* 实际使用时，我会这样用AI：
*
* 1. 描述系统设计：
* "我要设计一个支持百万并发的消息推送系统，
* 主要约束：消息需要保序、允许短暂延迟不超过1秒、
* 消息大小在1-10KB之间"
*
* 2. 让AI列举可能的方案和权衡：
* "列举3-5种主要架构方案，分析每种方案的
* 优劣势、适用场景、主要技术挑战"
*
* 3. 让AI挑战我选定的方案：
* "我倾向于用Kafka+消费者组方案，帮我找出
* 这个方案在上述约束下可能遇到的最严重的三个问题"
*
* 4. 最终判断还是自己做
*
* 这个工作流下，AI是思维的外部化工具，
* 帮我更快地发现思维盲点，
* 但最终的判断和决策责任是自己的。
*/
// 真实项目中的架构决策文档模板
@Data
public static class ArchitectureDecisionRecord {
private String title; // "选择消息中间件方案"
private String context; // 背景和约束条件
private List<String> options; // 考虑过的方案
private String decision; // 最终决策
private String rationale; // 决策理由
private List<String> tradeoffs; // 接受的权衡
private List<String> risks; // 识别的风险
private LocalDate decisionDate;
private String decider;
}
}这不是展示什么高超技术，而是说：把AI融进工作流里，要融进去的是那些能帮你更快思考更全面的地方，而不是把思考都外包出去。
七、对AGI来临的心态准备
最后说说心态。
过渡期最大的心理挑战是不确定性——不知道AI进化到什么程度，不知道哪些工作会消失，不知道自己积累的经验还值多少钱。
应对不确定性，我的心态是：持续做那些在任何版本的未来里都有价值的事情。
学习能力本身，是所有未来里都有价值的。深度的业务理解，是所有未来里都有价值的。优秀的沟通和协作能力，是所有未来里都有价值的。对技术判断的把关能力，是所有未来里都有价值的。
AGI如果来，这些能力怎么用可能会变，但它们的重要性不会消失。
结语
过渡期不是等待期，是准备期。
你现在做的选择——学什么、做什么项目、在哪个方向上积累——都在为未来做铺垫。趁AI还没有强大到不需要人的时候，把那些AI难以替代的能力做厚实，这是最务实的判断。
恐慌没用，躺平也没用，把眼前能做的做扎实，才是真的。