上个月参加了一场晋升答辩，候选人是个工作四年的前端工程师。他的 PPT 做得很好：主导了三个项目，代码质量评价 A，还带过一个实习生。放在两年前，这个材料过 L5 问题不大。
但他没过。
问题出在一个细节上。评委问他："你提到这个项目里你用 Agent 写了大部分代码，那你自己具体做了什么？"
他说："我写了 spec，然后 review 了 Agent 的产出，确保代码质量。"
评委继续问："你怎么判断 Agent 的代码质量够不够？"
"就是……看它有没有 bug，逻辑对不对。"
"那你怎么判断它的架构设计是否合理？三个月后需求变了，这个设计还能不能撑得住？"
他沉默了。
我后来一直在想这个场景。表面上看，是候选人没把自己的贡献讲清楚。再往下看，会发现旧的职级标准有一个隐含前提：代码是人写的，所以我们可以从代码质量里反推出人的能力。现在代码可能是 Agent 写的，PRD、spec、测试、文档也都可能是 Agent 起草的。那我们到底在评估一个工程师的什么？
这里有一个我越来越确定的判断：AI 没有取消职级，只是把人更早推到了审定者的位置上。
很多过去只在高职级里明确要求的能力，开始下放到更低职级。审方案、判断边界、评估长期风险、跨栈理解、沉淀系统规则——这些以前像是 L5/L6 才需要稳定展现的东西，现在 L3/L4 也会更早碰到。新人没有突然变成熟。只是执行被 Agent 承担以后，他更早被推到了 review、审定和判断的位置上。
这件事有点别扭。
因为它听起来像在说：现在的初级工程师要像过去的架构师一样工作。某种程度上，确实如此。过去架构师和 leader 往往不亲手写每一行代码，他们审方案、看设计、review 关键实现、判断风险、要求别人补充边界条件。现在一个 L3/L4 工程师让 Agent 写代码，自己审 spec、审 PR、判断边界，本质上也在做类似的事。
当然，新人不该被当成立刻可用的架构师。工作形态和考察方式相似，要求程度要降下来。L3 只需要在清晰边界里判断单模块产物是否正确；L5 才需要在模糊需求和跨服务边界里做可靠判断；L6/L7 才需要判断组织级方向。过去高阶工程师的部分工作方式在下沉，但判断力的作用范围、复杂度和可靠性要求，仍然应该按职级递进。
代码不再是最好的证据
传统职级标准里有很多维度：代码质量、系统设计、项目管理、mentor 能力、技术影响力。它们当然还重要。但在 AI 时代，这些维度都会逐渐绕回同一个东西：判断力。
代码质量？Agent 可以写出看起来不错的代码，但你要判断它是不是真的对。系统设计？Agent 可以给出三套方案，但你要判断哪一套能活过下一轮需求变化。项目拆解？Agent 可以列任务，但你要判断这个拆分会不会制造错误的 handoff。mentor 能力？你不只 mentor 人，还要把经验沉淀成 Agent 下次不再犯错的 rule、skill 或 harness。
判断力不是新东西。好的工程师一直有判断力。区别在于，以前判断力藏在执行里。你看到一个人写出好代码，大概就能推断他有判断力。现在执行被外包给 Agent，判断力必须被单独看见。
但判断力又不能直接举证。你不能在晋升答辩里说"我做了很多正确判断"，这跟说"我很聪明"一样空泛。评委能看的，还是那些可观察的东西：你处理的任务有多复杂，影响范围有多大，你有没有留下系统性改进。
一个人说自己 review 了 50 个 Agent PR，不说明太多。另一个人说，他把一个只有一句话的模糊需求拆成了三个可验证场景，驱动 Agent 生成 PRD 和 spec，然后发现 Agent 在某类场景里反复写出用户看不懂的错误提示，最后把问题定位到 AGENTS.md 缺少文案风格规则，并且这条 rule 后来被两个项目复用。后者才是证据。
不是证明自己判断力好，而是证明自己完成了需要好判断力才能完成的事。
全栈也变了
还有一个相关的变化是"全栈"。
过去真正的全栈工程师很少，因为全栈意味着你要能在多个技术栈里亲手写出成熟代码。通常是一个主技术栈，加上若干个也足够成熟的辅技术栈。这个积累很慢，因为每个栈都要经过大量实现、踩坑、维护和返工。
现在门槛下降了。跨域判断力并没有变便宜，变化发生在"全栈"这个词本身。
过去的全栈，是能写全栈。
现在的全栈，更接近能看懂、能 review、能判断全栈。
能看懂和能写出来，难度差别很大。一个前端工程师未必能高质量手写复杂的后端事务逻辑，但他可以在 Agent 生成后端代码时，判断错误处理是否完整、接口契约是否合理、事务边界是否危险、日志和监控是否足够。遇到拿不准的地方，他知道该找谁，知道风险在哪里，知道不能假装自己懂。
这会改变组织对工程师领域画像的期待。过去我们常说 T 型人才：主领域深，相邻领域有理解。AI 时代可能更像是凸型人才：主领域仍然要深，但相邻领域不能只是"听得懂"，而是要凸起来一截，达到可以审查 Agent 产物、发现明显风险、参与跨栈交付的程度。
这里也发生了要求下放。过去我们对高级工程师才会说："你不能只懂自己那一层，你要能判断上下游。"现在这个要求会更早落到初级工程师身上。只是程度要放宽。L3 不需要独立设计全栈架构，但应该开始读懂相邻领域的 Agent 产物；L5 才需要在主领域深度之外，对相邻领域做可靠判断；L6 才需要在多个领域之间设计系统边界。
职级框架只是脚手架
如果一定要把它落到职级标准上，框架反而可以很简单。
L3 仍然处理清晰需求，范围大多是单模块或单组件。变化在于，他不能只会让 Agent 写完，还要能判断主领域内的 Agent 产物是否正确，并且开始读懂相邻领域的简单改动。
L4 开始拆 feature，处理多模块协作。他要能发现相邻领域里的明显风险，知道什么时候自己可以判断，什么时候必须升级给更熟的人。
L5 处理模糊需求、跨服务协调和团队规范。他的判断力不只在主领域里深，还要能覆盖相邻领域的关键风险，并且把反复出现的问题沉淀成 rule、skill 或 review checklist。
L6/L7 再往上，重点就不是某个 PR 对不对，而是系统边界、组织工作流、技术方向和业务方向之间的取舍。
这套递进逻辑其实没那么新。传统职级也一直在问：你的判断力能可靠作用到多大的范围？只是以前这个判断力往往通过亲手写出来的代码间接呈现。现在执行工具变了，低职级更早被推到需要判断的位置，原来的递进逻辑就被压缩了。
所以我不太想把这篇写成一份完整的职级标准。标准可以慢慢打磨，但那个更底层的问题已经摆在眼前：新人不是小号架构师，却开始被放进类似架构师的工作形态里。组织如果只调整晋升标准，不调整训练机制，问题会被遮住。
最难的是判断力从哪里来
真正让我有点不安的是这里。
如果 L3 的标准变成"能判断 Agent 产出是否正确"，但 L3 又不再大量亲手实现，那他的判断力从哪里来？
过去的成长路径虽然慢，但它是闭环的。写代码，遇到 bug，debug，返工，上线，背锅，复盘。一个工程师就是在这些具体的摩擦里，逐渐形成"这样写会坏""这个边界很危险""这个抽象三个月后会撑不住"的判断力。
AI 时代，这条路径被打断了。新人可能更早交付更大的功能，但他没有经历足够多的实现细节；他可能 review 了很多 Agent PR，但没有亲手追过那些错误为什么发生；他可能很快学会驱动 Agent，却没有形成判断 Agent 的底层触感。
这个困惑也不只属于初级工程师。对我们这些从旧时代成长起来的人来说，它其实提供了一个很好的反问：如果把我们当年积累判断力的那条路拿掉，我们还知道怎么培养自己吗？我们知道怎么解释自己的判断力从哪里来吗？
很多 senior 习以为常的"经验"，是在古典工作模式里被训练出来的。现在新人不再自然经过那条路，我们就不能假装判断力会自动出现。
答案也不是让所有人回到古典工作模式。为了训练判断力而故意不用 AI，就像为了学习地图而拒绝导航一样，代价太高，也不符合真实生产环境。
问题是：在不回退到旧工作方式的前提下，怎么重新设计判断力训练？
我现在能想到的方向还比较朴素。L3 仍然需要受控地亲手实现一部分核心路径，尤其是边界条件、错误处理、性能敏感路径和测试。目的不是比 Agent 写得快，而是建立判断 Agent 对错的底层触感。同一个任务，也可以先让新人给出自己的设计草案，再看 Agent 方案，最后比较差异。训练重点不是谁写得好，而是为什么这个差异重要。
更重要的是错误复盘。每次 Agent 出错，都要归因：需求没说清、spec 边界错、上下文缺失、rule 缺失、模型能力不足，还是 reviewer 没看出来。L3 的成长材料不应该只是 PR 数量，而应该是错误归因能力的提升。
Review 也要重新设计。让 L3 review Agent PR 没问题，但必须有 checklist、参考答案和 senior 复盘。没有复盘的 review 只是浏览，有复盘的 review 才是训练。
这可能会变成 AI 时代工程组织最重要的 apprenticeship 设计。保留 L3，也不让 L3 回去手写所有代码；先承认旧的经验积累路径已经断了，然后重新造一条。
否则组织会得到一个很糟糕的结果：短期看起来交付效率很高，长期没有 senior 供给。
答辩材料要怎么讲
回到一开始那个没过答辩的同学。他如果理解了这个框架，材料不应该写成：
我通过 Agent 完成了 X 项目，review 了 47 个 Agent PR。
他应该讲的是另一种故事：
X 项目的原始需求只有一句话："用户觉得操作太复杂。"我花了三天跟产品和用研对齐，把这句话拆成了三个可验证场景。我驱动 Agent 生成 PRD 和 spec，然后逐条审定：什么算"简单"，什么不能变，怎么验证。在 review Agent 产出时，我发现它在 Y 场景里反复把错误提示写得太技术化，普通用户看不懂。我查了原因，发现 AGENTS.md 里没有定义本项目的文案风格。我补充了这条 rule，之后 Agent 在同类场景再没犯过这个错误。现在这条 rule 被另外两个项目复用了。
这个故事里，判断力不是被声明出来的，而是被推断出来的。任务复杂度、执行过程、问题定位、遗留改进，都可以被验证。评委不需要相信他说"我判断力强"，只需要看他是不是完成了一件需要判断力的事。
这可能也是 AI 时代晋升答辩最大的变化。你不能再把产物直接当成人的能力证明。你要讲清楚自己在产物形成过程中做了哪些判断，留下了哪些约束，以及这些约束有没有让下一次交付更可靠。
我现在还没搞明白的一些事
我还没完全想清楚的是，判断力训练到底能被压缩到什么程度。AI 确实能让新人更快暴露在更多 case 里，但"看过很多 case"和"亲手追过一个 case 的因果链"不是一回事。也许训练速度可以提升，但不可能无限提升。这里应该有一个下限，只是现在还没人知道它在哪里。
另一个问题是，组织会不会低估这个断层。AI 带来的交付提升太显眼了，判断力供给不足是几年后才显现的问题。等到发现没有足够多的人能做复杂判断时，补课可能已经很慢了。
还有一个更尴尬的问题：很多 senior 能不能把自己的判断力显性化？如果他们只能说"这个我一看就知道不对"，那新人没有办法学，Agent 也没有办法学。AI 时代对 senior 的要求可能也提前了——他们不只要会判断，还要能把判断过程拆出来，变成训练材料、review checklist、rule 和 eval。
一句话：AI 没有让职级消失，只是把很多高职级要求提前了；真正需要重建的，是新人形成判断力的那条路。
参考文献
- @edinsoncode 转述 Uber CTO 数据：99% 的工程师日常使用 AI 工具，70% 以上的 PR 涉及 Agent。本文只把它作为行业迁移速度的观察信号，而不是严格统计结论。https://x.com/edinsoncode/status/2075532390101852294