11 篇博文 含有标签「engineering-management」

你开启了一个“评测工程师 (eval engineer)”的招聘需求。一周后，你的招聘人员问了一个显而易见的问题：这个岗位的职级是什么，一份优秀的简历长什么样？你给不出答案。两年前，这个头衔还不存在。没有职级评定标准，没有标准的面试流程，LinkedIn 上也没有现成的“评测工程师”人才库。你在为一个行业尚未达成共识是否存在的职位进行招聘。

这是交付 AI 系统过程中一个隐形的瓶颈。模型是现成的，基础设施是可租用的。你无法从市面上直接买到的是这样一种人：他们的实际工作是确保基于 Prompt 的系统保持“诚实”——而你那套为拥有数十年先例的岗位而构建的招聘机制，并没有给他们留位置。

直觉是等待。等待头衔标准化，等待培训班批量产出候选人，等待别人写出你可以照搬的职级指南。这种直觉是错误的。无论头衔是否存在，工作就摆在那里，而现在就开始组建团队的人，会在竞争对手还没开启招聘需求之前，就摸索出什么是真正的“优秀”。

两个小时的课后作业和 45 分钟的算法面试从来都不是重点。它们只是代标（proxies）。课后作业代表的是“这个人能否交付功能”，而白板面试代表的是“这个人能否在压力下分解问题”。二十年来，这些代标运作得相当不错，以至于大多数团队都停止了对它们的质疑。它们的管理成本低、易于评分，并且与你真正关心的能力大致正相关。

编程 Agent 破坏了这种相关性，但没有破坏形式。面试照常进行。它仍然会产生一个分数。这个分数看起来仍然像是有意义的信号。但面试所衡量的东西与工作所需的能力之间的差距已经拉大到如此地步，以至于一个合格（green）的结果几乎证明不了任何东西——而大多数招聘流程还没有意识到这一点，因为表面上没有任何失败的迹象。

这是一种悄无声息的失效。不是过程崩盘了，而是一个过程在它的假设前提不再成立后仍在继续运行。

编程面试的设计初衷是为了隔离单一变量。把一个人关在房间里，给他们一个问题，拿走他们的参考资料，观察他们是否能独立将问题转化为可运行的代码。这种形式的一切——白板、空白编辑器、禁止查阅资料——都是为了剥离协作者和工具，从而衡量一种被隔离的技能：这个人能否在压力下独自编写出正确的代码。

这项技能已不再是工作中需要锻炼的技能了。2026 年的日常工程工作是工程师与智能体（Agent）之间的协作。工程师决定构建什么，智能体起草大部分代码，而工程师真正的任务是审查、纠正，并判断智能体何时在“自信地犯错”。面试衡量的是独立产出代码的能力。而工作奖励的是指导一个不知疲倦、快速、偶尔产生幻觉的协作者。代理指标与目标已经脱节，而大多数招聘流程尚未察觉到这一点。

这并不是在抱怨作弊，尽管作弊是每个人都关注的症状。这是一个测量问题。当你无法再观察到测试旨在隔离的变量时，测试就不再产生信号——而一个在所有人仍然信任它的同时却不产生信号的测试，比根本没有测试更糟糕。

当一个智能体（agent）加入你的团队时，每个工程经理脑海中最接近的类比就是新员工。因此，应对策略显而易见：给它一个沙盒和只读日志，将最初的任务范围缩小，与其结对编程，预留一段磨合期，并随着信任的累积让它承担更重的工作。这听起来很负责任。这感觉就像是你把上一个初级工程师培养成高级工程师时那种耐心的管理方式。

这也是一个范畴错误（category error）——它不只是一个略显不完美的类比，而是一个错误的类比。初级工程师是一个还不太了解你系统的人。而智能体是一个无状态的函数，无论接触系统多少次，它永远都不会真正“了解”你的系统。这是两种完全不同的事物，适用于前者的管理直觉会在无形中让你错配注意力。

这之所以重要，是因为这个隐喻不仅会产生误导，还会让你把精力投在错误的地方。“培养智能体”并不是一种策略。智能体是固定的，你真正能改变的一切都存在于它之外。

每一家在生产环境中上线 AI 功能的公司，都有那么一两个无法承受其离职损失的工程师，而大多数公司直到收到辞职邮件时，才意识到这些工程师是谁。

那个关键人物很少是办公室里嗓门最大的。他们是那个记得在第二季度的问题升级后，通过三行系统提示词（system-prompt）修改修好了客服摘要语气的人；是那个在模型供应商悄悄更改默认采样（sampling）的那周，在评估套件（eval suite）中添加了六个案例的人；也是那个在上次有人“清理”评分细则（rubric）时，发现评判标准校准（judge calibration）发生偏移的人。这些内容都没有被记录在继任者能找到的地方。它只存在于一个人的脑子里，而这个人的脑子大约每两周就会收到一次猎头发来的加薪 25% 的消息。

这是一个尴尬的事实，大多数 AI 团队在发现时往往已经晚了半年：一个精心设计的评估（eval）用例所耗费的工程精力通常比它要测试的功能本身还要多。修改一次提示词（prompt）只需要一个下午。而让你确信这次修改没有破坏原有功能的评估用例，则需要领域专家进行为期两天的标注，一个与裁判提示词（judge prompt）的校准循环，以及一场关于“正确”在当前用户界面下究竟意味着什么的讨论。功能可以在一个 Sprint 内交付，而让你能够安全交付后续十个功能的评估体系则需要一个季度才能成熟。

这种不对称性并非缺陷。它是评估工作的结构性形态。标注、边缘情况的策划、裁判校准和评分标准设计都是前置的固定成本，它们不随你交付功能的多少而扩展，而是随你想要验证的不同行为（behaviors）数量而扩展。与此同时，功能开发端不断产生看似廉价的边际输出：“又一次提示词迭代”、“为智能体增加了一个工具”、“更换模型”。每一个改动看起来都很微小。但每一个改动都在无声无息地增加评估集必须覆盖的范围。

我今年雇佣的三位最优秀的 AI 工程师，如果让他们互相面试，可能都会被刷掉。那个能写出在模型升级后依然稳健的提示词（prompt）的人，这辈子没写过一个有用的评估（eval）用例。那个能设计出捕捉到关键故障的评估集的人，写的提示词其他工程师根本不想去维护或扩展。那个能设计出既能“故障闭合”（fail closed）又不阻塞正常路径的护栏（guardrail）的人，对另外两个人的看法我在这里不便多说。

职级体系将他们三人都称为“AI 工程师”。定级委员会在对比他们的晋升材料时，仿佛他们做的是同样的工作。其实不然。

信号消失了。在最近对 19,368 场技术面试的审计中，38.5% 的候选人被标记为存在 AI 辅助作弊行为，其中技术岗位的作弊比例高达 48%，初级候选人的作弊率几乎是资深候选人的两倍。更令人堪忧的是：61% 被检测到的作弊者分数超过了及格线。如果没有检测层，他们本可以晋级。面试作为一种评估工具，已经不再能衡量它最初设计要衡量的东西了。

这并不是针对当今年轻人的道德恐慌，而是评估工具的机械性失效。技术面试曾被校准为一个特定的世界：候选人在时间压力下，在陌生的环境中，必须凭记忆和第一性原理编写出正确的代码。这种约束——即让信号清晰可辨的关键——已被在第二台设备上运行的免费聊天窗口瓦解了。每一家仍在进行 LeetCode 式筛选的公司，现在都在花钱对一场考生可以轻易外包的考试进行排名。

一家中型创业公司的高级工程师最近得到了一份平庸的绩效评估。他们的效率不稳定——有些周发了大量代码，其他几周几乎什么都没有。他们的经理受过传统 SWE 框架培训，因产出波动给他们打了低分。六周后，那位工程师跳槽去了竞争团队。经理没有理解的是：工程师"缓慢"的几周是在构建评估基础设施，防止三类无声故障的发生。没有这些基础设施，产品本会以没人能在数月内察觉的方式悄然出问题。

这种情况正在各个工程团队中上演。那些为确定性软件系统设计职级体系的团队，正将同样的框架套用于 AI 工程师——并系统性地误判了他们最优秀的人才。

你的模型在留存测试集上达到了 91% 的准确率。p95 延迟低于 200ms。与之前的规则系统相比，错误率降低了 40%。从每一个技术指标来看，这个项目都是成功的。六个月后，领导层取消了它。

这不是假设。80% 的 AI 项目未能实现预期的商业价值，而这些失败的大多数并不是由于模型性能不足。它们源于工程师所衡量的内容与决策者所能理解的内容之间的鸿沟。技术团队使用的语言，高管无从评估——在缺乏可理解信号的情况下，领导层默认持怀疑态度。

指标翻译问题并非沟通软技能，而是一门工程纪律，而大多数团队把它当作可选项，直到融资审查前夕才想起来。

你团队中的一名初级工程师刚刚在一周内交付了三个功能。而你的资深工程师只完成了半个。仪表板显示初级工程师的效率是资深工程师的 6 倍。仪表板在撒谎。

这就是 AI 技能反转 —— 一种度量错觉。AI 编程助手让初级工程师在表面指标上看起来生产力惊人，却掩盖了更深层次的问题。功能交付得更快了，但架构却在退化。PR 成倍增加，但系统的连贯性却在瓦解。那些比起判断力更相信仪表板的组织，正在助长错误的行为，并流失掉正确的人才。