文 / STEM Career 编辑部
FDE 类面试中的模糊问题，往往需要你同时处理需求、工程和交付。先说出几个 Agent 框架名称，还不足以证明能够把客户的问题推进到可用结果。你需要解释先问什么、先做什么，以及用什么事实判断第一版可以交付。
下面是一道原创教学案例，用于双人练习，不是任何公司的招聘真题。它适合准备客户部署型工程岗位，也可以帮助已有技术项目的人补齐方案和沟通表达。
先拿到一份不完整的客户要求
假设一家企业软件公司每天收到两百条工单，目前由协调员手工分到五个支持队列。负责人说：“能不能用 AI 自动处理，让客户等得更少？”你有两周做一次小范围验证。
已知材料包括工单标题、正文、创建时间和当前队列。历史队列可能分错；客户等级保存在另一套系统里；没有人说明 AI 是否可以发回复或执行账户变更。每天的工单数量只是教学假设，不是效果预测。
你的任务是提出一个可验证的初始方案，并解释一次需求变化后如何调整。先保留问题的不完整性，不要立即补出一套完美客户背景。
第一轮问题应该改变方案
可以先问负责人希望改善什么：减少分派时间、缩短首次响应，还是减少最终解决时间？这几个目标依赖不同环节。若问题在队列中等待，先做自动回复可能改善不了实际瓶颈。
再问谁使用结果、谁确认分类、分错有什么代价。普通咨询错分可以人工转派，紧急安全事件或账户权限问题可能需要特殊流程。把不同类别分开，才能决定第一版允许做哪些动作。
最后确认数据与接入：能否使用历史正文，哪些字段需处理，读取客户等级由谁授权，以及测试环境在哪里。问完后把答案复述成短记录，让对方能指出误解。
明确一个可以完成的初始范围
本案例选择“队列建议加人工确认”。系统给出类别、建议队列和简短依据，由协调员确认后写入测试系统。暂不自动发信、不修改账户，也不把未知客户等级猜成普通客户。
| 事项 | 第一版范围 | 待确认或后续范围 |
|---|---|---|
| 输入 | 测试工单标题与正文 | 客户等级接口 |
| 输出 | 队列建议与依据 | 完整处理方案 |
| 执行 | 人工确认后更新测试记录 | 无人值守操作 |
| 特殊情况 | 缺失信息转人工 | 更多类别细分 |
| 验证 | 合成样本与授权测试数据 | 生产使用效果 |
范围不是为了少做事，而是为了能解释怎样验收。当前无法读取客户等级，就把该依赖留在计划里，并说明它对下一版本的影响。
用一条完整路径说明架构
输入层保存工单标识、可用字段与本次处理版本。处理层先做格式和缺失检查，再调用模型产生结构化建议。输出层校验队列是否在允许列表中，向协调员展示依据，并等待确认。
确认动作需要关联原工单与建议版本，防止用户确认的是旧结果。写入发生后，再检查测试系统的实际记录。页面显示“提交成功”与记录确实更新，应作为两个可区分状态。
LangChain 的 Deployed Engineer 职责可作为研究客户部署任务的入口。练习时仍需用自己的架构和假设说明方案，不能把一份 JD 当作固定面试评分表。
评测样本先覆盖错误代价
准备一组普通咨询、紧急问题、信息缺失、互相矛盾和重复提交的工单。标注每条允许的结果、需转人工的条件，以及最终应检查的系统状态。历史队列只作为参考，不能自动当作正确答案。
可以先用二十条教学样本做人工检查，找出分类边界，再建立更完整的验证集。这二十条只能帮助发现问题，不能支持上线可靠性结论。样本数量、代表性和允许错误需要按实际业务另定。
Anthropic 的 Agent 评测说明强调观察执行与结果。用于本题时，至少区分建议是否合理、人工是否确认、更新是否正确，以及失败是否能够被发现。
两周计划怎样安排依赖
第一阶段确认目标、数据和决策人；第二阶段做离线原型与结构化输出；第三阶段接入测试环境并检查失败情境；最后与使用者一起验收，决定继续、修改或停止。
不要仅报出每天要写哪个页面。每个阶段写一个检查结果：目标获得确认、样本可以使用、输出可验证、重复提交不会造成重复更新，以及使用者知道如何接管。
如果接口迟迟不能接入，可以先演示模拟环境，但要在说明里保留差别。一个模拟接口运行成功，不能被描述成已经完成客户系统集成。
加入一次需求变化
同伴现在扮演客户：“既然能分类，下周能否直接自动回复所有工单？”你可以先确认新增目标，再说明需要补什么：回复依据、发送权限、错误代价、人工审批和回滚记录。
不必马上答应或直接拒绝。可以建议先让系统生成回复草稿，人工审核后发送，并选取低风险类型验证。时间和评测范围随之调整，原来的两周结果不再包含全部自动回复。
这次变化检验你能否保护已确认范围，同时提出推进办法。回答中应明确哪项决定需要客户确认，而不只是说“我们会协调资源”。
给自己一张验收表
| 检查情境 | 预期行为 | 观察证据 |
|---|---|---|
| 字段缺失 | 明确请求补充或转人工 | 无未经确认的写入 |
| 队列不存在 | 拒绝执行该建议 | 校验记录 |
| 工具超时 | 保留待处理状态 | 重试与查询结果 |
| 重复确认 | 不重复更新 | 同一操作标识的记录 |
| 结果变更 | 用户看到新版本 | 确认与写入版本一致 |
验收也包括用户是否理解系统。让一名未参与开发的人完成一条任务，观察他在哪一步犹豫。必要时调整说明或确认界面，别把操作困惑全部归因于用户培训不足。
练习时怎样给反馈
安排十分钟澄清、十分钟方案和十分钟追问。观察者分别记录你问到了什么、用了哪些未说明的假设、哪些检查能证明结果，以及需求变化后是否调整了承诺。
反馈应落到可以改的动作。例如“你在画架构前没有确认谁批准写入”，比“沟通不够强”更有用。下一轮只改变一个条件，如数据延迟或规则冲突，再看方案能否保持一致。
还没有明确目标岗位，可先看FDE 适配与相邻方向。需要整理书面提交，可以配合Take-home 任务准备安排材料。
向客户展示一个失败场景
演示可以先走普通工单，再主动展示一条缺失客户标识的输入。说明为什么此时不写入队列、用户会看到什么、谁能继续处理。这样对方能判断边界是否符合工作，而不只是评价界面顺不顺。若现场工具失败，也能用已保存的教学记录解释状态，不把演示中断包装成已经验收。
把案例训练接到你的真实面试
如果你会做功能，但遇到客户追问、范围变化或验收问题容易讲乱，可以加微信说明目标岗位、准备时间和自己最不稳的一环。无需先把这道练习全部做完。
蒸汽教育可以结合项目与面试准备讨论训练重点。用你实际完成的经历作基础，再安排原创场景和模拟追问，更容易把工程能力与交付表达连起来。
常见问题（FAQ）
这篇是企业面试真题吗？
是原创教学场景，用于练习客户澄清、方案与验收。
需要第一版就全自动处理吗？
应根据任务、授权和错误代价选择范围，案例保留人工确认。
需求临时变化怎样回答？
确认新增目标与依赖，说明范围、检查和时间如何调整。
- LangChain 的 Deployed Engineer 职责· LangChain
- Anthropic 的 Agent 评测说明· Anthropic
如果项目能做出来，但一遇到客户追问、范围变化就讲不清，可以加微信说明目标岗位和准备时间，先讨论适合练哪一段交付场景。