面经 | Forward Deployed / AI | 🔥🔥 | Palantir
2026(9月底–10月初) Forward Deployed AI Engineer @ Palantir | New York · Virtual · 1 轮 | 😐 Neutral | Medium
Forward Deployed AI Engineer 的一轮 virtual decomposition。
Decomposition
题目：一家区域制造商每天收几百封供应商邮件说延期，planner 手动看、手动改表格。他们想要「用 AI 弄点什么」，别再漏掉关键零件的延期。没有 schema，没有成功指标，也没说他们现在跑的是什么系统。
先理用户。planner 日常看 alert 干活；buyer 管供应商关系，关心日期又改了；ops lead 要的是哪几个厂有风险的周视图，不是每封邮件。现在中间就靠那张表格，大家也不怎么信，因为日期被覆盖了没有痕迹。
MVP：每封邮件分类延期/非延期，按固定 schema 抽 part number、PO、新日期，和 open PO 对上，只把关键零件的延期推进 planner 队列，附原邮件链接。关键零件用 BOM 上的简单 flag，不上模型。模型抽不干净的——没 PO、日期在 PDF 附件里、输出不是合法 JSON——进人工复核，不去猜。非延期邮件不进队列，避免把 planner 淹了。
他们问抽取这一步长什么样。我说一次带 JSON schema 的 structured call（part、PO、new_date、自由文本原因），先校验字段，再拿 PO 去对 open order。PO 缺失或对不上，整行带着原邮件进复核，不编一个 PO。又追问分类和抽取要一个模型还是两个。我拆开了，免得抽取挂了还得重跑分类，但重试路径没画。
中途面试官改条件：有的供应商同一个延期发三遍，日期还略有不同。我说按 (supplier, PO, part) 做 key，保留最新日期，历史给 planner 看，能看见供应商把日期往后再推了。后面那封把延期缩短的邮件要不要把已关掉的 alert 重新打开，只口头说了会 reopen，状态机没写完。
最后问一个月后怎么知道这东西真的有用而不只是 demo。我说了漏报延期数（已经撞上生产却没出 alert）和每条 alert 的 planner 处理时间。不让 planner 全量标注的话 ground truth 怎么拿，没讲完——只说抽一周邮件对照进队列的结果。