FDE 跟岗访谈怎么做：用真实操作记录替代需求猜测

不要从“你想让 AI 做什么”开始。请操作者打开一件已处理的任务，从收到请求走到最终结果。选择允许查看、能脱敏并且有处理记录的样本；如果录屏或保存资料不被允许，只记录经过确认的字段和操作步骤。

样本不必只挑顺利的。一次缺少订单号的售后、一次转交主管的例外，常常比标准流程更能解释为什么业务耗时。不同岗位分别观察，别让负责人代替一线员工回答所有问题。

Palantir 的 FDE 工作介绍把与客户沟通、配置业务流程以及维护生产系统列入工程师工作。下面的访谈表是本站对这类现场工作的具体设计，并非原文模板。

表中“查看签收日”是观察事实，“所有客服都这样处理”是未经验证的推断。记录时另加证据位置，例如工单编号的脱敏代号、规则版本和访谈对象岗位。后面别人复核，才知道这条判断从哪里来。

等待时间与操作时间也要分开。等待主管回复半小时，并不表示 AI 能节省半小时；如果授权流程不能改变，系统至多能帮助整理材料和提醒处理。

跟岗表另记开始与结束时间、实际操作耗时、等待对象、证据位置和未知项负责人。阶段名称帮助还原顺序，时间字段帮助判断负担；资料查找、系统响应和等待他人分别记录，不把全部间隔都算成可由 AI 节省的人工时间。

提问时少用“是不是可以自动化”。这种问法容易让对方顺着方案回答。改问“上一次发生例外时怎么处理”，通常能得到更接近现场的证据。访谈结束前把自己的记录读给对方听，请他纠正遗漏和误解。

这些改进可能只需要调整表单或规则。FDE 的判断依据是任务能否更可靠地完成，而不是必须引入 Agent。真正适合模型的部分，通常是非结构化信息提取、归类或基于资料生成候选说明。执行和授权仍要落在系统规则中。

访谈完成后交付四样东西：一张带例外路径的流程图，一份字段及权威来源表，一组经过脱敏的任务样本，以及一页待确认事项。每个拟做的功能都指向其中的证据，避免出现只有口号的需求条目。

例如“自动处理售后”可以缩成“读取订单与申请材料，生成售后分流建议；缺失关键字段时询问补充；所有退款由既有业务系统完成”。对应的验收案例包括完整材料、缺订单号、规则冲突、无权限查看订单。

暂时没有证据的改进可以列为假设，但要写明如何验证。下一次访谈应补哪个岗位、需要观察哪类任务、谁负责确认规则，这些比再写一页功能愿景更有用。

观察中发现客服打开了三份文件，不要立刻认定需要更强的搜索。请他分别说明为什么打开：第一份确认期限，第二份核对渠道例外，第三份其实是在找去年处理相同情况的记录。问题可能是规则分散和历史经验没有整理，而非搜索框不够好。

下一步可以先把期限与渠道例外放到同一份经负责人确认的规则页，拿另一件脱敏任务试用。比较找到依据所需的操作、是否还需要问同事，以及最终结果是否一致。如果流程已明显简化，先保留这个改进，再评估 AI 的额外价值。

每条访谈结论附上“下一步验证”。例如“聊天文本可提取订单号”要用不同写法、错号和缺号样本验证；“可以自动分流”要覆盖规则冲突和授权例外。访谈记录由此成为项目证据，而不是一次讨论的纪要。

首次访谈不代表全部业务。遇到不同班次、不同渠道、不同客户类型，流程可能改变。试点中出现新的高频例外，或实际采用率明显低于预期时，回到现场观察，而不是只修改提示词。

这套方法适合正在界定试点的业务负责人和 FDE。已有明确、稳定接口且规则简单的任务，可以用现成操作记录代替完整跟岗；涉及高度敏感资料时，应在授权环境中做观察，并让资料保留方式服从企业制度。