卖模型的岗位，考的是你会不会算账

朋友晓辉准备AI方向求职面试，岗位叫「大模型技术解决方案专家」。

他准备了两周，背了一堆概念：RAG 的三种切分策略、Agent 的 ReAct 框架、微调里的 LoRA 和 QLoRA 区别。面完出来跟我说：全问到了，但一个都没答到点上。

面试官问他的第一个问题是：「客户说要用大模型做客服，预算一年 80 万，你怎么接？」

他讲了半天向量数据库选型。

这就是这类岗位最常见的死法：把解决方案岗当成算法岗来准备。

这篇把我理解的准备路径写清楚：这个岗位到底在卖什么、简历怎么写、项目怎么挑、面试怎么答。素材主要来自那份 JD 本身，加上我这两年跟几个做 To B 大模型落地的朋友聊出来的东西。

不保证你一定能过。但至少能让你别把时间花在错的地方。

一、先搞清楚：这个岗位卖的不是模型

JD 第一条写得很清楚：为重点客户提供「从需求澄清、方案设计、PoC 验证到生产上线的全流程支持」，并且「对项目落地与商业化结果负责」。

注意最后半句。不是对「方案交付」负责，是对「商业化结果」负责。

这意味着你的角色更接近售前 + 方案架构 + 半个项目经理的混合体。客户签不签单、签了能不能上线、上线了第二年续不续，都在你的账上。

我见过太多候选人在这一层就歪了。他们以为这个岗位的核心能力是「懂技术」，于是把所有准备时间砸在模型原理上。但真实工作里，你 70% 的时间在做三件事：

第一，把客户模糊的诉求翻译成可验证的技术目标。客户说「我们要提升客服效率」，这句话没法做方案。你得追问到「现在人工客服日均处理 8000 通，平均时长 6 分钟，你想降到多少？哪一类问题占比最高？能接受多少误答率？」

第二，算账。这个方案要花多少钱、多久能上线、能省多少人、ROI 几个月回正。客户老板只关心这四个数。

第三，兜住「不确定性」。大模型的输出是有概率的，客户要的是确定性。你的活儿就是把概率性的能力，包装成一套有边界、有兜底、有度量指标的工程方案。

所以我在标题里说：卖模型的岗位，考的是你会不会算账。

不是比喻。是真的要会算。

二、把 JD 翻译成一张能力地图

JD 三大段职责、六条任职要求，信息量不小。但直接照着准备会失控，因为它是「职责语言」，不是「能力语言」。

我的做法是把它翻译成三列：

翻译完之后你会发现，真正要准备的只有四类素材：一个完整项目、一个失败项目、一套评测方法、一次跨团队推动。

剩下的都是包装。

这一步很重要，因为面试官不会问你「你有没有 PMF 思维」。他会问：「你之前做过的项目里，哪个是你判断可以复制的？为什么？」

你有没有那张地图，决定了你答得像背的还是像自己的。

三、简历：把「负责」两个字删掉

看过有人写简历，最典型的一版是这样写的：

负责某银行智能客服项目，使用大模型技术完成知识库搭建与问答系统开发，对接客户需求，推动项目上线。

这段话的问题不是不好，是没有信息。谁都能这么写。

解决方案岗的简历，面试官只看三件事：你解决过什么量级的问题、你做过什么判断、结果是多少。

同一件事，改写之后：

某股份行信用卡客服知识库项目｜方案负责人

• 客户原始诉求是「准确率 90%」，澄清后锁定真实痛点是「账单分期类问题转人工率 47%」，将该类目单列评测集
• 方案取舍：放弃全量微调（8 周、成本 40 万），改用 RAG + 结构化查询工具调用，3 周上线
• 结果：该类目转人工率降至 19%，日均节省 620 通人工，年化人力成本下降约 210 万；单次会话成本 0.07 元

差别在哪？

第一，有数字。47%、19%、620 通、210 万、0.07 元。数字是解决方案岗的通用语言。

第二，有取舍。「放弃微调改 RAG」这一句，比十句技术描述都有用。因为它证明你会在约束下做判断。

第三，有口径。「年化人力成本下降 210 万」这种话，说明你算过账，不是拍脑袋。

三个提醒：

• 别写工具清单。 「熟悉 LangChain、Dify、Coze、RAGFlow」这种罗列，只能证明你上过网。
• 别把团队成果写成个人成果。 面试官一追问「这个评测集是你设计的吗」，你就露了。
• 留一两个「钩子」。 简历上写「成本压到 0.07 元/次」，他一定会问怎么压的。这就是你要的主场。

四、项目：两个讲得透的，胜过五个讲不清的

很多人简历上写七八个项目，面试一問全露。解决方案岗的面试是深挖型的，面试官会顺着一个项目往里钻三层：

第一层：你做了什么。第二层：你为什么这么做，不那么做。第三层：如果预算砍一半/时间砍一半/客户换一个行业，你怎么办。

能扛住三层深挖的项目，两个就够了。

怎么挑？我的标准是三条：

1. 有真实约束（预算、工期、数据质量、合规），因为方案能力全在约束里体现。
2. 有可量化的结果（效果、成本、周期至少占两样）。
3. 你个人有明确决策点（哪怕只是「我坚持把评测集单独建」这种小事）。

必须准备一个失败项目。

这条我特别坚持。解决方案岗的失败率很高——PoC 过了上线挂了、上线了没人用、用起来了算不过账，都是常态。面试官问「讲一个没做成的项目」，不是想听你认错，是想看你会不会复盘。

好的失败故事长这样：

有个制造业客户的质检问答项目，PoC 阶段准确率 92%，客户很满意。上线三个月，日活不到预期的 15%。
复盘下来三个原因：一是我们把准确率当唯一指标，没测「问题覆盖率」——工人真正问的问题，60% 不在我们预设的类目里；二是上线时没做现场培训，班组长不知道怎么用；三是响应要 3 秒，车间网络环境下经常超时。
这件事之后我改了两个习惯：方案里必须有一节叫「上线后 30 天运营计划」，评测集必须从真实用户提问里采样，不能用我们编的问题。

这个回答里没有一句「我深刻认识到」，但每句都在证明你会干活。

五、硬功夫：RAG、Agent、评测，讲成人话

JD 里点名的技术栈是「模型 API、知识库/RAG、智能体及工具调用」。这三块必须能讲，但讲法有讲究。

别讲原理，讲判断。

比如 RAG，你不要从 embedding 讲起，那是在背书。你要讲的是选择：

一个 300 页的产品手册问答，我先判断它是不是「检索问题」。如果用户问题集中在 20 个高频场景，其实不需要 RAG，写成结构化 FAQ + 意图分类更便宜也更准。RAG 的价值出现在长尾——问题分散、文档频繁更新、答案需要引用原文。

落地时我关注三个指标：召回率（该找到的找到没有）、上下文命中率（找到的内容里有多少是有用的）、端到端答对率。前两个是工程指标，第三个才是客户能感知的。很多项目死在只优化前两个。

这段话里没有一个术语是炫技，但每句都在告诉你「我做过」。

Agent 和工具调用，面试官最常追问的是：「什么时候该上 Agent，什么时候不该？」

我的答法很直接：Agent 的成本是不确定性。每多一步自主决策，延迟、成本、出错率都往上走。所以我的默认策略是「能确定性编排就不上自主 Agent」——固定流程用工作流，只在需要开放式决策的环节放 Agent。客户要的是稳定，不是智能。

评测是最容易被追问、也最容易露怯的一块。准备时至少要能回答：

• 你的评测集从哪来？（真实日志采样，不是自己编）
• 多少条？（分场景，核心场景不少于 100 条才有统计意义）
• 谁来标？（业务专家标，不是算法同学自评）
• 怎么打分？（人工 + 模型评审结合，模型评审要先跟人工对齐一致率）
• 上线后怎么持续监控？（badcase 回流机制）

成本这块，得能当场算：

一次会话大概多少 token？输入输出比例多少？按当前单价，100 万次会话多少钱？如果加 RAG，检索和重排的调用成本是多少？如果换更小的模型，效果掉几个点、成本降多少？缓存能命中多少比例？

算不出来，说明你没真的做过。

六、案例题：用四段式拆，别急着给方案

这类面试几乎一定有一道开放案例，比如：

一家连锁零售企业想做门店导购助手，全国 2000 家店，你怎么设计方案？

大多数人的第一反应是开始讲架构：用什么模型、接什么知识库、怎么做意图识别。

停一下。这套答法的问题在于，你在信息不足的情况下给结论——这恰恰是解决方案岗最忌讳的。

我习惯用四段式，跟 JD 里的流程一一对应：

第一段：澄清（占 30% 时间）不要一次问十个问题，会像审问。我的习惯是先问三个定生死的：

1. 现在这件事谁在做、成本多少？（判断有没有 ROI 空间）
2. 导购最想解决的三个问题是什么？（判断是知识问题还是流程问题）
3. 上线时间和预算的大致范围？（判断方案上限）

然后再补：数据在哪、谁能给、准确率要求多少、出错谁担责。

第二段：拆解与选型（20%）把问题拆成「可以确定性解决的」和「必须靠模型生成的」。导购场景里，查库存、查活动价、查会员权益，这些是查表，不该让模型编；只有「怎么跟客户介绍这款商品」才是生成任务。

这个拆法本身就是加分项，因为它直接决定了成本和稳定性。

第三段：PoC 设计（30%）这是最能区分人的一段。你要给出：验证范围（选 5 家店还是 1 个品类）、周期（建议 2–4 周）、评测口径（导购会用不用、答得对不对、单次成本）、判定标准（什么情况下算成功、什么情况下该叫停）。

叫停标准特别重要。敢说「如果 4 周内端到端准确率不到 75%，这个场景就不适合做」，面试官会觉得你靠谱。

第四段：上线与运营（20%）包括灰度策略、埋点、badcase 回流、SOP 沉淀、客户侧的人怎么培训。

大多数人讲到第三段就没了，第四段空白——而这恰恰是「对商业化结果负责」的体现。

七、取舍：四条腿的凳子，你锯哪条

JD 里有一句话，我认为是整份 JD 的核心：

能在客户价值、技术可行性、交付成本与产品标准化之间做取舍。

这四个词就是四把尺子。任意一个方案，都在这四个方向上有拉扯：

• 客户要定制，产品要标准化 —— 你定制得越深，越难复制，第二个客户就得重做一遍
• 效果要好，成本要低 —— 上更大的模型、加更多检索、加重排，效果上去了，毛利下来了
• 上线要快，质量要稳 —— 两周 PoC 出效果，往往意味着评测做得糙

所以面试官问「你怎么平衡」，其实是在问：你锯哪条腿，为什么。

我的答法是先给一个判断顺序，再给一个具体例子：

我的顺序是：先保客户价值成立（这事确实解决了他的问题），再保可交付（我能承诺上线），然后压成本，最后才谈标准化。因为前两个不成立，后两个没意义。

但标准化我会提前埋。做法是：第一个客户就按「可复制」的方式设计——把行业通用的部分抽成模板（知识库结构、评测集、Prompt 框架），把客户特有的部分做成配置项。这样第二个客户能省 60% 的工作量。

这就是 JD 里说的 PMF 思维：不是做完一个项目再去想能不能复制，而是在做第一个的时候就想好怎么复制。

如果是面火山方舟这类平台方，还有一层要讲：你接触的客户反馈，最终要变成产品需求。你得能说清「这个客户的需求是个例还是共性」——三个客户都提，就该推进产品化；只有一个客户提，且他付得起钱，就做项目定制。

八、反问环节，别浪费

面试最后「你有什么想问我的」，很多人用来问薪资和加班。这两个可以问，但别浪费唯一的机会。

三个我认为有信息量的问题：

1. 「这个岗位现在接的项目，大概是什么量级？是标准产品交付为主，还是行业定制为主？」 —— 你能听出这活儿是销售支持还是真做方案。
2. 「团队现在最缺的能力是什么？」 —— 他会告诉你他心里的痛点，你下一句就能接「我之前的经历刚好在这块」。
3. 「如果我进来，前三个月你希望我做成什么事？」 —— 这个问题能让对话从「考试」变成「共事」。

如果前面聊得好，可以加一句更狠的：「您觉得我今天的回答里，哪部分最不像做过的人？」

大部分人不敢问。但它传递的信息很强：我不怕被指出问题，我要的是真实反馈。

最后说回准备这件事本身。

这类岗位的门槛不在知识量，在判断密度。同样一个项目，有人讲十分钟全是流程，有人三句话就讲清了取舍。面试官要的是后者，因为客户不会给你十分钟。

所以准备的时候，与其多背十个概念，不如把一个项目往下挖三层：我当时为什么选 A 不选 B、如果预算砍一半怎么办、如果客户换一个行业这套方案还成立吗。

能答上来，你就已经比大多数人强了。