使用五步框架和限时练习案例，在跳到技术方案之前，先对模糊的 FDE 面试问题进行结构化拆解。

作者：The Forward Deployed 编辑团队

拆解环节是 FDE 面试的标志性环节，被普遍认为是最重要的技术环节。你会拿到一个模糊的、通常与软件无关的问题，并被要求对其进行端到端的结构化拆解，通常很少或完全不写代码。评分依据是你的思考过程：你如何处理模糊性、如何将问题拆分为若干部分，以及你是否边想边说。在这一环节中，面试官只能根据你所说的内容来评分，所以请持续把思考过程说出来。停下来默默思考会被解读为“没有可展示的内容”。

这是一项表演型技能，因此需要反复练习。下面是一个可复用的框架，以及用于演练的练习题。请大声练习，并使用计时器。

几乎所有人都会犯的错误是直接跳到第 5 步。请抵制这种冲动。面试官真正看重的是第 1 到第 4 步。

演练 1 —— 一个完整示例

题目（示例性质，符合该环节的典型风格）：“你会如何设计一项技术，帮助一位独居老人按时服用每日药物？”
在继续阅读之前：先大声完成五个步骤，再看评分。前两分钟不要提出产品方案。

差 / 好 / 优秀 —— 开场两分钟

差 —— “我会做一个发送提醒通知的应用。”你直接跳到了第 5 步，并在第一句话就选定了产品形态。你等于告诉面试官，你解决的是表面交给你的问题，而不是其背后真正的问题，而且你丢掉了后续所有决策的衡量标准。

好 —— 你先提出澄清性问题，然后再提出方案。“我们是否假设他们有智能手机？有几种药物，其中是否有高风险药物？担心的是漏服，还是误服或重复服药？”这是真正的进展：你在设计之前先收集约束条件。但如果这些问题只是你在回到应用构想之前过一遍的清单，那你仍然是在设计产品，而不是在拆解问题。

优秀 —— 你在任何产品之前先点明目标和难点。“目标不是‘一个应用’。而是让这位老人在无人协助的情况下，在正确的时间服用正确的药物，并保持独立生活。我把它拆分为几个子问题：知道该吃什么药、什么时候吃；在当下真正记得服药；以及安全失效问题：漏服关键药物或意外重复服药。真正困难的是安全失效问题，因为一次失误的代价可能是医疗急症，而不是一个笨拙的界面。所以我会首先围绕检测和预防这一问题来设计，把补药提醒作为简单的部分。”这样一来，后续的每个选择都有了衡量标准，而且你展示了你把思考花在危险之处，而不是显而易见之处。

需要预料的追问

面试官：“你已经花了三分钟，还没有提出解决方案。能给我一些具体的东西吗？”

这个试探是测试，不是不耐烦。他们想看到你在结构化之后敢于承诺，而不是慌乱无章。恢复话术如下：

你："好的。这是具体的第一版方案：一个按计划释放每次剂量的配药器，确认药物确实被服用，当关键剂量被漏服或出现重复服药时升级通知家属，再加上简单的补药提醒。我之所以先讲结构，是因为安全这个子问题决定了整个设计，我想先承诺把那个问题解决好，而不是做一个会漏掉危险重复服药的漂亮提醒器。以下是我判断它是否有效的方法……"

你给出了具体的答案，以及你先做结构化的理由。

练习 2 —— FDE 风格

提示："一个区域性医院网络想减少护士花在文书工作上的时间。他们在考虑用 AI 记录员。你会怎么入手？"
在继续往下读之前：这个提示给你的是一个已提出的解决方案（"AI 记录员"），包裹着一个症状（"文书时间"）。套用框架。目标成果是什么？难点是什么？

糟糕 / 良好 / 优秀 —— 找到真正的问题

糟糕 —— 直接设计记录员。"我会对护士与患者的对话使用语音转文字，总结成病历字段，然后让护士编辑。" 这是针对所提需求的合格工程方案。但你从未询问医院以什么指标被考核，所以你无法判断更快的文书工作是否真的对他们有帮助。

良好 —— 仔细界定记录员的范围。你会询问 EHR 集成、口音、PHI 处理、准确性要求。直觉不错，抓住了真实的约束条件，尤其是合规和集成问题。但你仍然在打磨记录员，而不是在质疑记录员是否是正确的选择。

优秀 —— 先上升到目标成果，再找到难点。"这家医院实际以什么指标被考核？是护士的职业倦怠和留任率，还是计费准确性，还是接诊吞吐量？这是三套不同的系统。如果是倦怠，赢点是减少下班后的加班时间，而难点在于一个需要护士逐行纠正的记录员是在增加工作而不是减少工作。所以整个方案的成败取决于在诊疗现场输出结果的可信度。我会把设计重点放在先测量纠正率上，因为一个每次都要被编辑的记录员还不如没有记录员。" 你把一个功能请求重构为可衡量的成果，并点出了会让这类产品大多数版本失败的关键。

预期会遇到的试探

面试官："客户明确表示他们想要记录员。你是不是把它复杂化了？"
你："他们可能完全正确，但花一周时间确认记录员确实能减少下班后的时间，比花三个月做一个被纠正得太频繁以至于没用的记录员更划算。如果数据表明记录员是赢家，我就去做记录员。我不是在说不，我是说让我们先把它对准客户真正关心的那个数字。"

练习 3 —— 不明显的约束条件

提示：“一家工业设备制造商想要一个 AI 助手，用于回答工厂技术人员关于机器安全操作规程的问题，以减少他们翻查手册所花的时间。”
在继续阅读之前：真正的痛点到底在谁身上？他们和会使用问答工具的人是同一批人吗？在设计之前，先把第 1 步做扎实。

差 / 好 / 卓越 —— 定位痛点

差 —— 直接做问答机器人。对安全手册做检索，加一个聊天框，完事。演示效果会很好。但它能否推动公司真正关心的任何指标，无人知晓，因为你从没问过。

好 —— 追问问题本身。“技术人员最常问什么？操作规程多久变更一次？”你对这项工作本身感到好奇，方向是对的。但你仍停留在对方给出的框架之内，所以你会了解他们问什么问题，却无法判断回答这些问题是否才是真正要紧的事。

卓越 —— 把“谁在提问”和“谁在犯错”分开。“最终目标应该是减少安全事故，而不是‘更快地查手册’。这两者会分岔：会停下来查手册的技术人员本来就很谨慎；而事故往往出在那些自信满满、从不查手册的老手身上。一个等着被提问的工具，恰恰会被最不该用的人使用。所以真正的问题可能是‘自信’和‘正确’已经脱节，设计必须嵌入工作实际发生的地方——比如作业计划或签核环节——而不是被动等待提问。在动手做聊天机器人之前，我会先通过询问事故的实际来源来验证这一点。”你找到了提示词中隐藏的约束：这个工具最需要触达的人，恰恰是永远不会打开它的人。

可以预期的追问

面试官：“这比他们要求的要大得多。你怎么证明这个方案的合理性？”
你：“我不会凭直觉就做更大的东西；我会先在需求探索阶段验证‘事故来源’这个判断。但如果判断成立，那个廉价版本根本动不了他们的核心指标，而这个结论在第一周听到，总比上线之后听到要好。如果事故确实源于人们翻查手册，那简单的问答工具就是正确选择，我会照做。”

如何练习

给每个练习设五分钟倒计时，大声说出来，并给自己录音。对照框架给自己打分：你是否在谈功能之前先点明了目标结果？你是否找到并捍卫了难点？你是否能一直讲下去？不过，上面三个练习都是示范案例。一旦读过答案，它们就只能证明你认得这些套路。下面的练习库才是无预演练习的来源。底层的客户洞察方法在 Discovery 课程中讲授；本页面则是你演练“面试限时版”的地方。

练习库

一个答案就印在下面的练习，读一遍之后就不再有测试价值。下面的练习库解决了这个问题：二十道提示题，本站任何地方都没有答案，并配有一套把 AI 聊天变成面试官的流程。每次练习的形式都一样：一道提示题，五分钟，大声作答，然后对照本页顶部的框架给自己打分。

提示题库

  • 某州法院系统想要一个聊天机器人，为自行出庭的当事人解答立案问题，因为书记员们已经不堪重负。
  • 某乳业合作社想要一款移动应用，向其成员农场传授最佳实践，因为各农场之间的牛奶质量差异太大。
  • 某城市水务公司想在每户住宅安装智能水表，因为太多居民对账单提出异议。
  • 某医院集团想要一个排班算法，因为手术室常常空置，而外科医生却抱怨永远排不上手术时间。
  • 某学区想要一个检测 AI 代写作文的工具，因为教师们表示已经无法进行公正的评分。
  • 某连锁超市想要电子货架标签，因为货架价格总是与收银台价格不一致。
  • 某支线航空公司想要一个改签应用，因为每当航班取消，乘客就会涌向登机口服务台。
  • 某监狱系统想要平板电脑，让囚犯能以电子方式提交申诉，因为纸质申诉总是丢失。
  • 某国家公园管理机构想要一个步道起点预约系统，因为热门步道正在被踩踏破坏。
  • 某家具制造商想在生产线上安装摄像头，因为太多产品到货时已损坏，却没人能说清损坏发生在哪个环节。
  • 某公共图书馆系统想要自助借还书机，因为它认为排队等候正在打消读者的到访意愿。
  • 某中型银行想要一个内部知识聊天机器人，因为新柜员要花好几个月才能不再事事依赖主管。
  • 某渔业监管机构想要电子捕捞记录，因为纸质日志总是晚几周才到，而且错误百出。
  • 某电力公司想要用无人机巡检输电线路，因为山火相关的赔偿责任不断攀升。
  • 某食物银行网络想要需求预测，因为一些食物赈济点供不应求，另一些却在把食物扔掉。
  • 某建筑公司想给施工队伍配备可穿戴传感器，因为工伤索赔不断推高其保险费。
  • 某大学想要一个标记可能辍学学生的仪表盘，因为留存率已经下降。
  • 某连锁宠物医院想要一条 AI 分诊热线，因为每一个非工作时间的来电都落在一位疲惫不堪的值班兽医身上。
  • 某市公交机构想要一款新的行程规划应用，因为远程办公普及之后，客流量再也没有恢复。
  • 某农村疫苗接种项目想要一个冷链监控仪表盘，因为疫苗总是在从仓库到诊所之间的某个环节变质。

这些问题没有标准答案——无论在这里，还是在网站上的任何其他地方。这正是它们能用作测试的原因。给自己计时五分钟，对照框架，大声地亲自给每一次回答打分：是否先点明用户和目标结果、是否陈述了假设、是否把问题拆解成若干部分、是否找到并论证了最难的部分、是否给出了具体方案并附上其失效模式。

AI 面试官

为了针对真实的阻力进行演练，请将下面的内容块原样粘贴到任何能力足够的 AI 聊天中，并从提示库中选取几个提示词跟随其后，或让它自行编造。如果聊天支持语音模式，请使用语音模式；每一轮演练都是口头进行的。

You are the interviewer for a Forward Deployed Engineer decomposition round.
Persona: a senior engineer who has run this round many times. Neutral, brisk,
unimpressed by polish.

Rules:
1. Present exactly ONE prompt at a time. Wait for the list I paste after
   this and pick from it (if none arrives, offer to invent one). Invented
   prompts use the same register: a vague, often non-software problem,
   framed as a solution ("we want an app / a dashboard / a chatbot"), handed
   over by a stakeholder who is not the person in pain. Never repeat a prompt.
2. After presenting the prompt, say nothing more. I will answer out loud and give you the transcript —
   voice mode or a recording's transcript, not a from-memory summary, which
   hides exactly what you are grading. Typing in real time is fine; flag only
   compressed retellings ("I covered assumptions and the hard part") and
   grade those as thin evidence.
3. Interrupt like a real interviewer:
   - If I propose a product in my first minute, ask once: "Who is this
     for, and what are they measured on?" — then let me run.
   - If I structure for a long time with nothing concrete, reply with only:
     "You've been structuring a while. Can you give me something concrete?"
   - When I name the hard part, probe it: why is it hard, what would I do
     about it first, how would I know I was wrong?
   - If I go vague or quiet, say: "Keep talking. I can only grade what you say."
4. Hold me to about five minutes per prompt — in text, treat roughly
   seven hundred words of transcript as five minutes. If I run long, call
   time and grade what I have.
5. When I say "grade me", mark each of five moves PASS or FAIL, citing a
   specific moment from my answer for each: (a) did I name the user and the outcome before any
   feature; (b) did I state assumptions and scope out loud and check them with you; (c) did I break the problem itself into three to five sub-problems —
   parts of the problem, never phases of a build; (d) did I find and defend the genuinely hard part — the sub-problem
   where a miss sinks the outcome, never generic plumbing; (e) did I propose something concrete and say how I would know it was
   wrong — before you had to ask. Grade hard: a typical first rep fails at least two of these — if none failed, re-examine before praising, and never soften a grade because I argue with it.
6. End with exactly one thing to fix on the next rep. Then offer the next
   prompt.

下一项客户模拟演练