能力地图：从会做任务到能承担结果

Baseten 的 FDE 负责人 Vlad Shulman 回顾过一次招聘判断的变化：团队起初过于执着于寻找已经掌握机器学习的专家，后来把扎实的软件工程基础放回中心，同时看重客户意识、沟通和接受指导的能力。这是一个团队对自己招聘实践的反思，不能读成“机器学习不重要”，也不证明任何工程师都能迅速胜任所有 FDE 工作。¹

它提醒我们，能力地图应帮助人判断下一段工作能否交出去。仅把编程、产品、沟通、业务各画一条长短不同的线，仍然不知道：这个人可以自己做什么，什么地方需要搭档，遇到哪种情况必须停下来。

本篇面向准备进入 FDE 的实践者，也面向要培养他们的技术和业务负责人。问题不是怎样最快获得一个新头衔，而是怎样逐渐获得这样的信任：把一个尚不清楚的问题交给这个人，他能够查清、建设、验证，也能说清自己暂时不能负责的部分。

先区分自己站在哪个起点

后面会读到的两位转入 FDE 的当事人，此前已经做过技术工作。刚进入一家企业、刚接触某个行业，与刚开始学习编程，是不同的起点。不能把他们适应新岗位的几周，读成从零形成全部能力所需的时间。对尚无工程基础的人，先在有指导的条件下完成小型程序、理解数据和排查故障，比直接模仿独立负责客户项目更合适。

对已经写过多年服务端程序的人，新的练习可能是先听懂客户怎样工作，再决定修改哪里。对习惯技术演示的人，新的练习可能是让方案在演示者离开后继续运行。对某个行业很熟悉的人，新的练习则可能是补足编程、数据与调试基础，亲自检验自己提出的流程能否被系统准确执行。

因此，学习路线应从一个诚实的盘点开始：哪些事情自己已经能独立完成，哪些事情需要指导，哪些判断目前只是听过。把三者区分开，比把简历上的技能词再增加一行更有用。一个熟悉仓储的人完全可以比模型专家更早发现“已出库”的歧义；但发现了歧义，还需要有人把修正落实到系统，并证明它没有破坏其他流程。

不同起点应使用不同的准备路线：先找仍缺的证据，再决定由谁指导、怎样检查。

把形容词换成可以观察的动作

可以选一份目标岗位，把每项职责改写成一个别人能够观察的动作。例如，“善于沟通”可以改成：听完两种冲突的要求后，能否准确复述分歧，并提出一个可检查的下一步？“系统思考”可以改成：修改某一步之后，能否指出谁的等待时间、错误率或工作量可能增加？“主人翁意识”可以改成：发现交付依赖一个自己无权改变的系统时，能否及时找到负责者，而不是默默许下保证？

下面这张表是本书用于学习和分配任务的建议，既不是行业资格认证，也不是招聘打分表。选择自己最近一项作品或工作，为每一行寻找一份别人能够检查的材料。

一份材料可以支撑不止一行。例如，一次有清楚输入、修复理由和复核记录的故障处理，既能显示工程能力，也能显示验证能力。但同一份材料不能被算成多次独立成功，更不能覆盖它没有经历的环境。

Dropbox 在 2021 年公开介绍工程职业框架时，强调影响与行为，同时明确框架不是晋升清单，也不能替代员工与管理者的持续沟通。这里借鉴的是这一限制：表格帮助讨论具体表现，不能替讨论者作决定。Dropbox 的职级体系也不是 FDE 的通用标准。²

“会”后面还需要写条件

对每个动作，可以使用四种描述：只了解概念；在指导下完成过；在明确边界内独立完成过；能帮助他人在变化的条件下完成。没有材料时写“尚无证据”。这些描述表示当前观察到的范围，不给人贴永久等级。

例如，“我能处理重复消息”过于宽泛。较可靠的描述是：“在预约合成练习的一次串行运行中，我能说明为什么同号同内容不再改变业务状态；重启后如何保存记录尚未实现，需要指导。”后半句没有削弱前半句，反而使任务分配更准确。

“独立”也不意味着不用文档、工具或同伴。它意味着自己能组织判断：知道要问什么，能检查拿到的回答，能解释决定，遇到超出权限或知识的部分会升级处理。把 AI 生成的代码直接交出去，却说不清输入和失败条件，不能因为没有向人提问就算独立完成。

如果评阅者提出一个新条件，先看原证据还是否适用。能修好单条错误记录的人，不一定已经能处理数据结构整体改变；能向技术同事解释的人，不一定已经能帮助一线人员作决定。能力扩展应通过新的行为被看见。

一次可以立即开始的差距诊断

以下为教学诊断，不是雇主测试。设想你收到一份作品交接说明，只有四项材料：

• 演示能从请求中提取活动名称，但没有含糊请求的结果。
• 程序的十条固定样本全部通过，尚未记录别人运行的过程。
• 需求写着“自动通知”，组织者只同意生成待确认草稿。
• 作者能解释代码；发送通知需要一个尚未获准使用的账户。

先不要评价“这个人是不是好 FDE”。请写一份分配建议：现在可以交给他哪段工作，哪个承诺尚不能成立，下一份最有价值的证据是什么，需要谁提供什么支持。

一种站得住的判断是：可以让他在合成环境中继续完善提取与草稿流程；十条样本只证明已检查范围；自动通知既缺少授权，也没有被组织者接受。下一步可能是核对“草稿”这一范围并补含糊输入，而不是先增加一个模型。若你的选择不同，应说明它如何处理这四项材料，而不能把缺口默认为已经解决。

评价这份诊断有三个具体依据。第一，是否把“没做过”与“做错了”分开；没有真人运行记录，不代表必然无法交接。第二，是否把能力缺口、授权缺口和需求冲突分开；多学编程无法替代账户批准。第三，建议是否能落实到一段工作，而不是笼统要求“全面提高”。

再把同样的方法用于自己的作品。只选一个最影响下一项任务的缺口，写清已有材料、需要补的观察、愿意提供反馈的人及停止条件。如果连基本请求路径都解释不清，应先回到小程序；如果技术已可靠但需求冲突未解决，应把练习转向业务判断。不要因为能力表有六行，就同时开六项没有完成条件的学习任务。

向别人争取一段合适的责任

与导师或负责人谈成长时，可以带来这样的请求：“我已经能复现这类故障，尚未独立决定生产变更。我想先负责调查和备选方案，由你审核风险；完成两种不同输入的检查后，再讨论是否扩大范围。”其中的检查数量应由实际风险决定，不是本书设置的晋级门槛。

这比“给我更大的项目”更容易形成可执行的培养安排。负责人同样应说明哪些部分暂时不交出，以及怎样的实际表现会改变安排。若始终没有复核人、必要信息或授权，问题应登记为工作条件缺失，不能反过来归结为新人不够主动。

本篇后面的章节分别训练这张地图上的判断。可以从最阻碍自己下一步的地方读起，再用学习与作品的同一个项目连接起来。读完多少章节只是投入记录；自己能解释、能修改、能让别人继续的成果，才是能力证据。