AI 工程师职级体系：为什么你的 SWE 晋升框架在骗你
一家中型创业公司的高级工程师最近得到了一份平庸的绩效评估。他们的效率不稳定——有些周发了大量代码，其他几周几乎什么都没有。他们的经理受过传统 SWE 框架培训，因产出波动给他们打了低分。六周后，那位工程师跳槽去了竞争团队。经理没有理解的是：工程师"缓慢"的几周是在构建评估基础设施，防止三类无声故障的发生。没有这些基础设施，产品本会以没人能在数月内察觉的方式悄然出问题。
这种情况正在各个工程团队中上演。那些为确定性软件系统设计职级体系的团队，正将同样的框架套用于 AI 工程师——并系统性地误判了他们最优秀的人才。
核心问题：概率性系统需要不同的资历信号
传统软件工程的职级评估 是为这样一个世界构建的：产出是代码，质量信号相对清晰可辨。你可以读代码，可以跑测试，可以数 bug。高级工程师写出更优雅的代码，解决更难的问题，并指导他人如何做到同样的事。
AI 工程打破了这三个假设。
当你在构建 LLM 驱动的功能时，"代码"往往简单得出奇——一个 API 调用、一个提示词模板、一个检索查询。真正困难的部分在标准审查中是不可见的：模型在真实输入分布中是否表现正确，你的评估框架是否在衡量真正重要的事情，你的检索管道在推理时是否真的能找到正确的上下文。
Anthropic 和 OpenAI 的工程师已经公开表示，在某些工作流中 AI 现在几乎写了 100% 的代码。如果代码生成几乎已经商品化，那么资历信号就不可能是"写出更好的代码"，必须是完全不同的东西。
每个级别实际发生了什么变化
AI 工程职业路径表面上与传统软件工程大致相同——初级、中级、高级、Staff。但每个级别的工作却完全不同。
初级 AI 工程师本质上是集成者。他们调用 API、实现模型训练管道、接入现有组件、处理数据预处理。他们遵循提示词设计的指导。他们实现别人设计好的功能。独立判断的上限被刻意设得较低——不是因为他们不会思考，而是因为他们还没有积累出对概率系统以"看起来成功"的方式失败的直觉。
中级 AI 工程师开始设计系统，而不仅仅是实现系统。他们构建完整的 RAG 管道，而不只是检索 层。他们在模型选择、上下文策略和评估方法上做出一阶决策。关键在于，他们能在模糊中工作——能将含糊的产品需求转化为具体的技术方案，而不需要蓝图。晋升的标准不是"他们能否写出更难的代码"，而是"他们能否将定义不清的问题拆解为定义清晰的问题"。
高级 AI 工程师在做一件根本不同的事：建立基准事实。他们定义系统"良好行为"是什么样的。他们设计评估框架，所有其他人的工作都以此为标准来衡量。他们做出架构决策，约束在此之上构建的每个功能。当生产中出现没人预料到的问题时，他们能从故障模式向前追溯到根本原因，再从根本原因向后延伸到系统性修复。
Staff 及以上在组织层面运作。他们不只是构建 AI 能力——他们在构建判断的基础设施：提示词如何被版本化和审计的治理框架；模型升级何时发布的评估标准；组织决定 AI 可以和不可以被信任自主执行哪些事情的准则。
真正与资历挂钩的技能
在传统框架无法捕捉的 AI 工程资历信号中，有几项技能已经浮现为可靠指标：
评估设计是最清晰的一个。为概率性输出构建评估系统是真正困难的事。它要求理解哪些失败模式是重要的，设计能暴露这些失败模式的测试用例，并区分"模型出错了"和"评估出错了"。SWE-bench Verified 上约 59% 的基准问题在测试设计上存在实质性问题。如果连学术基准都会系统性地犯这个错误，那么为生产系统编写好的评估就 是一项需要深度经验才能做好的技能。能够构建可靠行为评估框架的工程师，正在做一件不平凡的事。
检索质量工程被低估了。大多数 RAG 系统失败不是因为模型不好，而是因为检索不好。让检索做对涉及理解数据粒度、分块策略、元数据设计、嵌入选择、相似度指标和后检索重排序——加上能区分其中哪个环节出了问题的评估框架。中级工程师可以实现一个 RAG 系统。高级工程师在它出错之前就知道它会在哪里出错。
上下文工程正在成为一门独立的专业。它不是提示词工程——而是对模型上下文窗口中放入什么、何时放入的战略管理。这涉及理解注意力机制、"lost-in-the-middle"问题（模型会低估位于长上下文中间的信息），以及 U 形注意力曲线。目标是筛选出最小的高信噪比 token 集合，给模型它所需要的内容。做好这件事的工程师让系统既更便宜又更可靠。
Agent 架构要求在脑中保持非线性扩展的复杂性。单 Agent 系统的失败模式是可处理的。多 Agent 系统的失败模式会复合叠加。设计编排模式、跨 Agent 移交管理状态、确保工具使用引入不确定性时的行为一致性——这些需要的系统思维很难伪装，也很难快速培养。
为什么标准职级框架会搞错
一个失准框架的典型症状是一致的：
以速度作为产出的代理指标。 AI 工程的生产力不是线性移动的。工程师可能花两周构建没有任何可见产品影响的评估基础设施，但能无限 期地防止一类故障。同一位工程师接下来两周可能发布五个功能。按冲刺速度评估的经理会将此读作不一致。而事实是，评估基础设施才是杠杆率更高的工作。
以代码复杂度作为技能的代理指标。 在传统软件工程中，编写复杂系统是资历信号。在 AI 工程中，编写一个可靠运行的简单系统往往比编写一个令人印象深刻的复杂系统更难。将无关复杂性抽象掉的工程师展示的是判断力，而不是懒惰。
以基准分数作为生产质量的代理指标。 这种模式从团队如何评估模型蔓延到如何评估工程师。一位发布评估通过率 95% 的功能的 AI 工程师，可能做的工作比发布评估通过率 85% 但边缘用例覆盖更好的简单功能的工程师更差。分母与分子同样重要。
误读 AI 工具采用的学习曲线。 当工程团队刚开始集成 AI 工具时，绩效往往会先变差再变好。团队正在重建心智模型、重新设计评审流程、培养新的质量直觉。期望立即看到产出提升的经理会完全误读这个完全正常的模式，将其视为最深思熟虑的工程师表现不佳——而这些工程师往往正是刻意放慢脚步、思考正确的新做法的人。
差距在扩大，而非缩小
一种常见直觉认为 AI 工具拉平了竞争环境——初级工程师获得生产力提升，缩小了与高级工程师的差距。数据不支持这一点。
高级 AI 工程师将 AI 工具用作乘数。他们具备判断力，知道模型在哪里出错，该问什么问题，以及如何验证输出。他们能大幅提速，因为他们不需要再 做工作中那些显而易见的部分。
初级工程师往往会被 AI 工具困住。输出看起来合理，但他们缺乏评估它的深度。感觉高效的系统——生成了大量代码——结果难以调试、维护或扩展。讽刺的是，AI 工具可能让缺乏经验的工程师感觉更有生产力，同时让他们构建的系统变得更差。
市场已经认识到这一点。AI 工程师的薪资溢价在入门级几乎为零（比同等非 AI 岗位高约 6%），在顶尖公司的高级职级则超过 70%。约 78% 的 AI 工程职位要求五年以上经验。集中在中高级的情况并非任意——它反映了团队实际上学到的关于困难问题在哪里的经验。
好的职级体系实际上是什么样的
更新了框架的工程经理们在 AI 工程师的核心问题上趋于一致：
中级：他们能为自己正在构建的系统定义评估标准吗？他们能在测试之前解释为什么他们的检索策略会或不会奏效吗？他们能做出合理的 RAG 与微调权衡并为之辩护吗？
高级：他们能定义"正确行为"对于一个正确性本身就是概率性的系统意味着什么吗？他们能设计团队可以维护和扩展的评估框架吗？他们能通过模型、检索和上下文层追溯生产故障到根本原因吗？
Staff：他们能为组织管理提示词、评估和模型升级的方式建立治理实践吗？他们能定义 AI 组件赢得或失去自主权的标准吗？他们是在构建判断基础设施，而不仅仅是功能基础设施吗？
底层模式是一致的：在更 高级别，工作从构建系统转向建立治理系统构建和评估方式的标准和基础设施。
留人成本的不对称
搞错这件事的后果是不对称的。将软件工程职级框架应用于 AI 工程师，往往会低估做杠杆率最高工作的工程师——评估基础设施、上下文工程、那些看起来慢却会随时间复利的架构决策——同时高估做高产量、显而易见但实际质量较低工作的工程师。
离职的工程师不成比例地是在构建基础的人。留下来的工程师不成比例地是那些已经学会指标奖励产出数量的人。两组人都在对给定的激励机制做出理性响应。
解决方案并不复杂，但需要刻意改变。职级标准需要明确包含评估质量、系统随时间的可靠性，以及架构决策的组织影响。冲刺速度需要在工程师在做什么的背景下解读，而不仅仅是他们发布了多少。"模型做编码"需要被理解为判断问题的开始，而不是结束。
那些想明白这件事的组织，将积累真正能产生影响的 AI 工程人才。那些没想明白的，将继续纳闷为什么他们最好的人一直在跳槽到那些真正理解这份工作的地方。
