FDE 的工作与责任

学完这一课，你可以

• 说明 FDE 怎样把一个含糊的要求变成可以检查的工作改进。
• 分清项目组与客户各自负责的决定，找到需要参与的人。
• 建立事实、假设、决定、结果记录，写出一个有负责人、有期限的下一步。

开始之前

• 先读北辰案例介绍：48 名现场工程师、6 名远程专家和初期助手的使用限制。所有人物和数据都是为练习编写的。
• 准备一份空白笔记，写下客户原话、你的第一反应，以及三个还不知道答案的问题。

查看北辰案例与入门数据

从一项工作开始理解 FDE

FDE 是 Forward Deployed Engineer 的缩写，通常译作前线部署工程师。你会贴近客户，了解问题、设计和构建系统，并帮助它进入日常工作。不同公司的岗位范围不同。例如，OpenAI 的官方岗位说明同时涉及需求研究、技术范围、系统构建、上线和采用；这是一家公司的招聘要求，不是所有 FDE 的统一标准。

学习时先问：谁在什么情况下，需要完成哪件事？北辰想要故障处置助手，但现场工程师真正要完成的是判断下一步该检查什么、找到适用于当前设备的依据，并在需要时联系有权处理的人。能生成一段流畅回答，只证明系统会输出文字；还要检查回答能否帮助完成这些工作。

初期助手只允许给建议、准备备件申请草稿，不得自动停机、提交申请或向客户发布事故结论。这些限制贯穿后面的课程。你可以建议缩小或改变范围，但任何放宽都需要重新确认授权和证据，不能因为演示效果好就自行增加动作。

同时检查系统和工作条件

把项目拆成两方面看，会更容易找到遗漏。系统方面包括资料版本、访问权限、检索结果、模型输出和外部接口；工作方面包括谁做判断、谁安排时间、谁复核，以及出现问题时谁接手。两方面会相互影响。例如，即使助手能找到正确手册，如果工程师无权打开，任务仍然无法继续。

不要假定技术故障一定会报警，或人员遇到的问题一定没有记录。没有监控的错误可能长期存在，工作中的困难也可能出现在支持工单里。你要主动安排检查：对一次任务查看系统记录，再请执行者说明当时怎样处理、还用了哪些线下渠道。两种材料放在一起，才能分清缺少能力、缺少权限和缺少人手。

按责任分工，不按称呼猜权限

本课程用 Echo 指业务与用户研究的责任，用 Delta 指工程交付的责任，借用的是 Palantir 的团队名称。你不需要先选一个身份才能学习。小项目里，一个人可能同时研究工作和写代码；重要的是把每项责任写清，并检查有没有无人负责的部分。

客户也不是一个统一的决定者。业务负责人确定优先级和投入，数据负责人确认资料用途和访问范围，运行负责人安排支持并决定运行与停止。领域专家帮助判断专业后果，实际使用者说明工作是否可行。具体授权以客户组织的规则为准；职位高、愿意支持项目，都不等于能替其他人批准。

把交接写成对方可以行动的说明

交接时，只说“用户想要查资料”或“技术上有风险”，对方很难知道下一步。先说明发生了什么、来源是什么、会影响哪个选择，再列出仍需确认的事。业务研究人员不能把一次抱怨变成整个团队的需求，工程师也不能把技术可行直接说成可以上线。

下面是一段假设演示：客户要求“下个月全员使用”。你先记录这是时间期待，不是已经批准的范围；随后分别整理需要了解的工作和技术问题；最后给出共同建议，而不是两个互不相干的答复。让接收者用自己的话说明建议和限制，可以发现“只做建议”是否被听成了“可以自动操作”。

• 第一步，确认目标：希望减少哪一种等待？全员使用是手段，还是客户真正需要的结果？
• 第二步，列出未知：哪些设备任务适合建议？资料能否访问？谁有时间检查和接手？
• 第三步，建议一个可确认的下一步：先研究华东白班的故障任务，由业务、数据和运行负责人确认研究范围。
• 第四步，约定更新时间和负责人。承诺在约定时间提交发现与选择，不承诺尚未验证的效果。

用四类记录保留判断过程

从现在起，给笔记分成事实、假设、决定、结果四类。事实是材料或观察能支持的事，写明来源和适用范围；假设是你对原因或效果的暂时解释，还需要验证；决定是有权的人选择了什么；结果是行动后实际观察到什么。一个文档或表格就够，不必另建复杂系统。

例如，北辰有 48 名工程师是案例事实；“他们的等待主要来自查资料”是假设；“先分析一批获准使用的记录”可以是待确认的建议，获得授权后才记为决定；分析得到的分布才是这一步的结果。给记录编号，并把它们连接起来。另记相关人员的意见和下一次沟通安排，避免只留下数字。

按问题推进，允许回头检查

后面的课程按合作、研究、定义问题、设计、验证、试点和交接逐步展开。每一步会使用前一步的记录：先确认能看什么，再研究实际工作；先确定值得解决的问题，再设计人和系统怎样合作。这样安排是为了减少无依据的投入，不是要求所有项目都严格按同一时间表。

试点是把改变限制在指定用户、任务和时间里的小范围试用，并安排观察、支持和停止方式。它不只是提前把系统发给几个人。如果试点显示主要等待来自审批，你可以回头改问题；如果权限减少，你可以重新谈研究范围。GOV.UK 的发现阶段指南也强调先了解问题、限制和是否值得继续；它的政府服务流程不应原样套作企业项目制度。

分清演示、使用和工作改进

演示说明某条路径在展示条件下能完成；上线说明系统可被访问；登录说明有人打开过。它们都有用途，但都不能单独证明故障等待减少。读一份项目报告时，问清任务用了什么资料、谁有权限、是否有复核，以及任务最后怎样结束。不要因为系统指标漂亮，就跳过实际工作结果。

也不要把所有未使用都归为“需要培训”。如果工程师已经会用，却没有权限、没有合适资料或担心责任不清，增加培训不会直接消除这些条件。先找一次具体任务核对原因。你现在不需要证明全部收益，只需要知道下一步怎样取得信息，并让真正受影响的人有机会纠正你的理解。

遇到“你们决定就好”，怎样回应

客户把判断交给你，可能是在寻求专业建议。先区分工程实现选择和客户的授权决定：代码怎样组织通常属于团队职责，是否允许处理新的数据、谁承担夜班风险、是否改变服务承诺，则要确认客户决定权。责任不清时，不要把沉默或一句客套话当成批准，也不必只回答“我们不能决定”。

给客户一份简短选择说明：推荐什么、依据是什么、还有什么不知道、每个选项有什么代价、需要谁确认。措辞可以是：“我们建议先做受限研究，因为等待原因还没确认。数据用途请由数据负责人批准，后续试点的支持安排请运行负责人确认。”这既提供帮助，也保留了客户对自己工作和风险的决定权。

动手练习

检查你的理解

先写下自己的回答，再展开解析，看看还需要补充什么。

本课记录与下一步

一份分工说明、一张交付步骤图，以及一个写明负责人和再次检查条件的下一步决定。

保留分工说明、事实与假设记录和下一步计划。第 2 课会把“需要谁参与、能访问什么”变成具体的合作和访问安排。