通过实践 FDE 系统设计案例，重点掌握评测、客户约束、故障模式、安全性、上线、成本与采纳等要点。

由 The Forward Deployed 编辑团队撰写并审校

Palantir 的现场面试包含一轮系统设计。可以预期是普通类型。错误在于用普通的方式去准备，因为对 FDE 而言，这一轮真正考察的只有一件事：你能否设计出一个能在真实客户环境中存活的 AI 系统。

有一个值得深思的事实。在 AI 案例中，架构几乎是被迫固定的。一个文档助手就是检索加模型。一个 AI Agent 就是模型、若干工具和一个循环。你循环中的每位候选人都会在五分钟内画出同样的框图，所以框图决定不了什么。这一轮的成败取决于你如何利用剩下的时间。大多数候选人把时间花在分块策略上。你应该花在客户如何知道系统是对的：上线之前，以及之后的每一天，因为语料库会变化，模型会被替换，上个月的准确率数字会悄悄失效。采纳源于信任，而信任建立在客户看得见的评测之上。

通用系统设计基础

有记录的那一轮通常是普通系统设计；Interview Method 有相关资料。所以在任何 AI 操作之前，你需要先掌握其下的普通系统设计。以下内容只是一个底线。如果通用系统设计对你来说是新领域，请搭配一本该领域的正规教材一起学习。

这是一个术语底线。你不需要在白板上设计一个分布式数据库；但你需要不经提示就说出这四个框，并为每个问题所迫的选择进行辩护。

一个通用案例的完整演练

题目：设计一个服务，接收送货卡车的全球定位系统（GPS）信号，并回答“我的货在哪里？”

逐一走过四个框。接入：卡车持续发出信号，所以在写入端前面放一个队列，吸收稳定的数据流以及车队在班次开始时集中上线带来的突发流量。存储：写入是按运单为键的小型追加操作；读取则是查询某个运单的最新已知位置，因此一个按运单标识建立索引并保留最近一次信号的存储，可以低成本地同时满足两者。服务：“我的货在哪里？”是高频重复读取，所以为每个运单缓存最新位置，让缓存吸收查询流量。故障：当卡车的网络重试时，同一条信号可能到达两次。让写入具备幂等性，以运单加信号时间戳为键，这样重复数据会合并为同一条记录，而不会破坏轨迹。

现在请说出起主导作用的约束。这个系统在写入端是重负载(每辆卡车、随时都在写入),在查询端也是重负载(每个客户都在查询),而这两者会导向不同的设计方向。你需要决定优先优化哪条路径,并把两者分开,避免一方拖垮另一方。这里有一个值得明确说出来的权衡:按运单标识符分区,单个运单的历史记录会保留在同一个节点上,这让"我的货到哪了?"这类读取保持快速,但如果某个地区的卡车占主导,就容易产生热点;按地区分区,写入负载可以均衡,但单个运单的历史会分散,读取就要扇出到多个节点。这个服务的核心价值在于按运单的读取。所以按运单标识符分区,并接受随之而来的再平衡工作。

一旦写入、存储、服务和故障处理都站得住脚,再在其上叠加 AI 层:评测、护栏、特定模型的成本与延迟。本页其余部分讲的就是这一层。

案例 1:有据可依的助手

题目:一家财富管理公司想要一个助手,能基于其内部研究库回答投资顾问的问题。请设计它。
在继续往下读之前:这个架构几乎是被迫确定的——对文档做检索,再由模型基于检索结果作答。那么这一轮真正考察的是什么?说出你最先设计的东西——而它不是向量数据库。

差 / 良 / 优——回答的侧重点

差——直接设计 RAG 流水线。你花十五分钟讨论分块策略、嵌入模型和索引选型。这些都很真实、都在预期之内,但没有一项决定这个系统的成败。你把容易的那一半设计得很好,却只字未提信任。

良——架构加上上线前的评测。你覆盖了检索,然后说会在上线前构建测试集并衡量回答准确率。这确实比大多数人强:你提到了评测。但一次性的上线前评测,在语料库或模型一变时就失效了,而且在受监管的场景里,"上线时是准确的"并不能作为辩护。

优——把持续的信任流程放在首位。"架构就是检索加有据可依的模型,这部分是被迫确定的。真正决定成败的是信任。受监管的投资顾问不会把 AI 放到客户面前,只要它哪怕自信满满地错过一次。所以我会先设计信任系统:领域专家对输出打分,评分反馈到提示词和检索的改进中,再配一个每天运行的回归测试套件,让漂移在一天内暴露出来,而不是等到客户会议上才发现。在输出送达客户之前,保留人工审核。检索器只是入场券。"这才是真实部署的形态,而一位真正上线过这类系统的面试官会立刻认出来。

可以预期的追问

面试官:"你怎么知道你的评测确实反映了投资顾问的需求?"
你:"因为评测是由投资顾问和领域专家来编写和打分的,而不只是工程师。对答案负责的人来定义什么算'正确'。同时我也会关注线上信号:纠错率、哪些问题被升级处理、顾问在哪些地方开始不再信任它。"

案例 2：Agent 系统

题目：客户想要一个能够执行操作的 Agent——根据自然语言请求提交工单、发送邮件、更新记录。请设计它。
在继续阅读之前：一个会执行操作的 Agent，其失败方式与只会回答的 Agent 不同。你会首先限制什么？

差 / 良 / 优 —— 失败处理

差 —— 最大化自主性。“Agent 规划并端到端执行整个工作流。”在演示中令人印象深刻，但一旦它给错误的客户发了邮件或删除了错误的记录，就会成为灾难。你只设计了理想路径。

良 —— 增加审批。“高影响操作需要人工确认。”直觉正确：你在限制影响范围。接下来要深入思考哪些操作需要审批，以及如何发现它行为异常。

优 —— 先限制影响范围，再进行监测。“设计问题在于它可以在无人值守的情况下做什么。可逆、低成本的操作自动执行。任何不可逆或高影响范围的操作都要经过人工检查点：给客户发邮件、转账、删除。我会限制它在停止并汇报之前可执行的操作数量，记录每个操作以供审计，并给它一个紧急停止开关。然后进行度量。它多久需要一次纠正，在哪里陷入循环，完成一个任务的成本是多少。随着评测数据证明其可靠性，再逐步提高自主性。”这就是将护栏思维应用于一个会执行操作的系统。

预期会遇到的追问

面试官：“客户想要完全自主——检查点会拖慢他们的员工。”
你：“那我们就用数据来赢得自主性。先在不可逆操作上设置检查点，度量 Agent 本来会出错的频率，一旦数据表明某类操作是安全的，就移除该类操作的检查点。一次错误的无人值守操作，就是足以毁掉整个部署的故事。逐步买回自主性，远比在那之后重新赢回信任便宜。”

案例 3：成本与延迟

题目：试点在五十个用户下运行良好。客户想让它面向五万用户上线。会有什么变化？
在继续阅读之前：“它能扩展”不是一个答案。说出真正会变化的两个数字，以及你分别会怎么应对。

差 / 良 / 优 —— 生产规模

差 —— “加更多服务器。”你把 AI 系统当成了无状态的 Web 应用。这里成本和延迟都来自模型调用，单纯水平扩展只会让账单更糟，而不是更好。

良 —— 把成本和延迟作为约束条件。“每次请求的 token 成本乘以量就是账单，而首次响应时间是用户体验。”框架正确。接下来要说明你分别会怎么应对。

好——那就具体地攻这两个指标。“有两个数字在动：每次请求的成本和 p99 延迟。成本方面，缓存重复问题的响应，把占大多数的简单请求交给更小的模型，把大模型留给困难的尾部，并在检索过度取数时削减提示词长度。延迟方面，用流式输出 token 让用户立刻看到响应开始，并缓存昂贵的共享前缀。而且我会从第一天起就对两者做逐请求的监控，因为到了五万用户规模，任何一个指标的小幅回退都意味着一大笔账单或一条排队的工单。” Cost & Latency 深入运用了每一个杠杆。

需要应对的追问

面试官：“你会先优化哪一个，成本还是延迟？”
你：“哪个更接近让部署崩溃就先优化哪个。如果用户因为启动太慢而流失，那就是延迟。如果试点的单位经济撑不到五万用户，那就是成本。我会先看实际数字再做选择。”

练习题库

上面三个案例会打印自己的评分，所以每个只能用一次。下面的 Rep Kit 收录了二十个同类型的新鲜 AI 案例（一个客户、一个请求、一条暗中起决定作用的约束），外加两个面向基础层的通用设计热身题，网站上没有任何答案。选一个，大声运行框架约十五分钟，然后对照它的五个动作给自己打分。留意你的时间花在了哪里；把大部分时间花在架构上会挂掉这一轮，即使架构本身是对的。相关概念在 Production 章节，完整展开的真实版本是 Morgan Stanley 项目，而当你跑完全部四轮之后，回到 Interview Method。

案例库

  • 一家航空航天供应商想要一个文档助手，且任何内容都不得离开其气隙隔离的工厂网络。
  • 一个应急调度中心想要实时通话摘要，而在通话结束后才生成的摘要毫无价值。
  • 一款儿童教育应用想要一个作业辅导，且每个用户都是未成年人。
  • 一家病理实验室想要报告草稿，且每句话都必须在多年后仍可供监管机构追溯。
  • 一家比价初创公司想要一个购物 Agent，且如果单次会话的成本超过收益，业务就会死掉。
  • 一个法律研究平台服务数百家相互竞争的律所，且任何一家律所的文件都绝不能出现在另一家律所的答案中。
  • 一家电信公司想要一个面向预付费客户的支持助手，而所在地区的网络动辄断连数小时。
  • 一家银行的欺诈团队想要案卷摘要，而案卷中被描述的那些人正 actively 试图污染记录内容。
  • 一个福利机构想要一个资格解释器，而一个错误的答案可能让人失去住房且几乎没有申诉途径。
  • 一家交易公司想要研究摘要，而一个基于昨日申报文件的答案比没有答案更糟。
  • 一家航空公司想要排班解释，而同一决策的两份不一致解释最终会变成一起工会申诉。
  • 一家医院希望用十几种语言起草出院指导，而翻译错误就是临床错误。
  • 一家大型零售商想要一个店内语音助手，而它必须运行在已经安装在每条过道的廉价硬件上。
  • 一家保险公司想要理赔分诊，而监管机构要求每一次拒赔都必须能证明是由某个具名的人做出的。
  • 一个社交平台想要一个审核助手，而它的用户会争相截图它说出可怕的话。
  • 一家制药公司想要文献摘要，而引用一篇不存在的论文属于必须上报的事件。
  • 一家货运运营商想要一个能自主改签货物的 AI Agent，而一个错误的操作会把实体货物运到错误的大洲。
  • 一个学区想要一个评分助手，而任何家长都可以要求对任何分数做出完整解释。
  • 一家报税服务公司想要一个申报助手，而其全年的工作量集中在几个残酷的星期内涌入。
  • 一个海上平台运营商想要一个维护助手，而客户不允许使用云，只提供一条卫星链路。

通用设计热身题

两个非 AI 案例，用于通过同一套协议演练底线。这里没有需要评估的模型，因此 AI 特有的评分要点（评测、爆炸半径）只作宽松参考。“说出主导约束”仍然适用，可理解为读多写少还是写多读少，或一致性还是可用性。

  • 一个票务平台想要一项在结账期间锁定座位、买家放弃时释放座位的服务，而且绝不能让两位买家确认同一个座位。

- 一家车队运营商想要一项服务，从数千辆车中摄取传感器读数并回答“哪些卡车需要保养？”，而读数到达的速度远远快于任何人查询它们的速度。

这些案例不提供答案。大声说出来，限时，对着框架来。

想要更多通用设计练习，可以把 OpenAI system design interview questions 和 Anthropic system design interview questions 中公司报告过的题目，用同一套协议来演练。

下一项：价值观与招聘经理面试演练