夜雨聆风可选副标题：问题不是经验失效，而是经验必须换一种方式证明自己。
周一上午的评审会上，一个刚入职不久的工程师拿出三版方案：界面能点，接口跑通，测试也生成了一批。旁边的资深工程师看了十分钟，说：“先别急着合。”
尴尬从这里开始。
产品经理问：“哪里不对？” 他说：“不是不对，是这里的上下文太多，后面会很难维护。” 会议室安静了两秒。因为这句话在过去听起来像专业判断，今天却很容易被理解成：你慢，你保守，你跟不上 AI。
这就是 AI 带来的新冲突。它不是简单把新人变强，也不是直接把资深的人淘汰。它先改变了一个更微妙的东西：经验被看见、被衡量、被信任的方式。
尴尬不在于不会用 AI，而在于旧经验突然不好证明了
过去，一个人“资深”，往往可以通过很多可见动作证明：写得快、记得多、知道坑、熟悉框架、能在白板上推演架构。AI 进入工作流后，这些动作的一部分被抹平了。
新人可以用 AI 生成第一版代码，学生可以用 AI 完成作业初稿，产品经理可以让工具写需求，设计师也可能直接提交一个小修复。可见产出变快了，第一版结果变便宜了。
但资深经验里最值钱的部分，恰恰经常是“没有发生的事”：没有引入一个难以维护的抽象，没有为了验证一个假设就新建一套系统，没有让合规、安全、性能和客户体验在三个月后一起爆雷。
问题在于，AI 让“做出来”变得醒目，而“没埋雷”仍然很难被统计。
大学已经演示过一次：会交作业不再等于真的学会
这条线索先在大学里出现。
据《硅谷101》2026 年 5 月 14 日发布的 E236 节目页，嘉宾 Jack 在节目中谈到“99% 作业由 AI 参与”，并说已经很难想到完全没有 AI 参与的作业。这里要注意来源层级：这是一期访谈节目中的个人经验表达，不是覆盖所有大学生的统计调查。
但它仍然有信号价值。因为它说明，在 AI 原住民那里，“完成任务”和“掌握能力”正在分离。
如果一份作业可以由 AI 参与完成，老师就必须重新判断：学生到底是在调用工具，还是在理解问题？如果一篇论文能被快速生成，学校就必须重新判断：教育的价值到底是记住知识、完成格式，还是训练判断、讨论、批判性思维和选择能力？
同样的问题会迁移到职场。过去，初级岗位承担了大量“练手型任务”：写初稿、查资料、修小 bug、补测试、做页面。AI 接走一部分之后，新人的起步会更快，但学徒期也可能变薄。资深的人不只是被挑战，他们还失去了一个熟悉的培养路径。
最刺耳的数字不是 99%，而是 19%
更刺耳的是另一个数字。
METR 在 2025 年一项针对资深开源开发者的随机对照研究中，观察了 16 名开发者在熟悉项目里的 246 个真实任务。论文摘要显示，这些开发者平均对相关项目有 5 年经验；任务被随机分配为允许或不允许使用早期 2025 年 AI 工具。研究结果是：开发者原本预计 AI 会让完成时间减少 24%，研究结束后仍认为 AI 让自己快了 20%，但实际测量中，允许使用 AI 的任务完成时间增加了 19%。
这个结论不能被粗暴改写成“AI 让所有资深工程师变慢”。METR 自己在 2026 年 2 月更新中也提醒，后续工具和使用习惯变化很快，新的实验存在参与者选择偏差，早期 2025 年的结果未必能直接代表 2026 年所有场景。
但这个研究解释了为什么“资深悖论”会出现：在成熟系统里，资深工程师的优势不是敲代码，而是掌握大量隐性上下文。AI 如果不知道这些上下文，就会制造额外的审查、修正和解释成本。
所以，最资深的人看起来变慢，不一定是因为他们落后。很多时候，是因为他们知道得太多，知道哪些“能跑”的东西以后会变贵。
公司要重写的不是岗位名称，而是责任边界
社区语言也在变化。Ibrahim Diallo 个人博客归档显示，他在 2026 年 5 月 18 日发布了一篇题为“Don’t call yourself a Software Engineer, you are an AI Enabled Engineer”的文章。把它当成一个社区情绪看，意思很清楚：人们正在寻找新名称，来描述 AI 进入软件生产之后的工程师身份。
但改名是最容易的部分。
据宝玉 2026 年 5 月 12 日文章转述 Anthropic 会议演讲，Fiona Fung 谈到 AI 时代工程团队管理时，核心变化不是“代码更多”，而是瓶颈转移：验证、评审、跨职能协作和安全变得更关键。该文还转述称，Claude Code 团队会看新人上手时间、PR 生命周期、Claude 辅助提交比例等指标，同时提醒不要死盯“多少代码由 AI 写成”，因为那只是虚荣指标，关键仍是产品质量和可靠性。
这比“AI Enabled Engineer”这个称呼更重要。
如果它只是表示“会用 AI 写代码”，那很快会变成廉价标签。真正的新能力应该包括：能为 AI 提供上下文，能拆解任务边界，能设计验证机制，能判断什么时候该用 AI，什么时候必须停下来让人负责。
AI 时代的工程师，不是从“写代码的人”变成“提示词操作员”。更准确地说，是从直接生产更多代码，转向组织代码、约束代码、验证代码，并为代码后果承担责任的人。
经验没有贬值，它从答案迁移到了判断
宝玉同日翻译的另一篇文章《为什么资深开发者讲不清自己的专业能力》提供了一个很好的解释框架：业务侧关心的是不确定性，资深开发者关心的是复杂性。业务希望更快试错，资深开发者担心系统变得不可维护。两边都对，但讲的不是同一种语言。
AI 会放大这个冲突。因为当业务侧看到 AI 能快速生成方案时，它会更难忍受“等等再说”。而资深开发者如果还只是说“这会增加复杂性”，就很容易被听成阻碍速度。
资深经验的表达方式必须改变：不要只说“这不行”，要能说清楚“有没有一个更快、风险更低的验证办法”。不要只维护抽象的工程原则，要把复杂性翻译成业务能理解的风险：上线会不会更慢，故障会不会更难查，客户承诺会不会更难兑现。
据宝玉 5 月 17 日翻译的 Jacob Harris 文章，作者反对“凭感觉编程”的一个重要理由是：摩擦本身是信号。写得困难，可能说明抽象错了；评审、测试、合规、沟通这些看似拖慢速度的环节，很多时候是在阻止坏主意进入生产环境。
这也是资深经验在 AI 时代的真实位置。它不是和 AI 比谁更快写第一版，而是判断哪些摩擦应该被消除，哪些摩擦必须保留。
以后衡量 AI，不要只看它写了多少
企业接下来最容易犯的错，是把 AI 使用变成新的指标游戏。
代码量、AI 生成比例、调用次数、token 消耗，都很容易统计，也很容易被包装成进步。但这些指标不能自动说明组织变强了。一个团队可能 AI 生成代码比例很高，但线上事故也变多；也可能 PR 更快了，但审查负担转移给少数资深工程师。
更有用的观察框架至少有四个问题。
第一，AI 缩短的是哪一段流程？是写代码，还是需求澄清、测试、评审、上线、排障？如果只缩短了编码，却拉长了验证，总效率未必提升。
第二，任务属于哪一类？从零做原型、写一次性脚本、生成样板代码，和修改成熟系统、处理安全敏感模块、维护金融或医疗业务，风险完全不同。
第三，谁负责最后判断？AI 可以参与生成，但出了问题不能由 AI 背锅。责任边界如果没有重画，所谓效率提升会变成组织风险。
第四，新人还怎么成长？如果所有低阶任务都被 AI 接走，企业需要重新设计学徒路径，让新人不仅会调用工具，也能理解系统、承受反馈、形成判断。
最后回到那个评审会。
资深工程师真正要回答的，不再是“你为什么不让它合进去”，而是“我们能不能用更小的代价验证同一个假设，并且不把未来三个月的维护成本押上去”。
AI 让最资深的人尴尬，是因为它把经验从台前推到了幕后。过去经验看起来像答案，现在经验更像边界、取舍和责任。
这不是经验的死亡，而是经验的重新定价。
你所在的工作里，最先被 AI 改变的，是哪一件原本用来证明“资深”的事？
