FDE 交付 · 高频面试题

答：结论：先把「不可复现」变成「可复现」，再谈修复。① 信息收集：客户账号、出错时间、请求 ID、操作路径、客户端版本、网络与权限，一次问全，别来回追问；② 日志与 trace：拉该时段服务端日志、网关访问日志和全链路 trace，按请求 ID 串起来，定位是哪一跳异常；③ 最小复现环境：用客户同版本镜像加脱敏数据搭一套，复刻配置、网络策略和账号权限，逐项替换变量直到现象出现；④ 版本与配置比对：把客户环境与基线环境的镜像、配置项、依赖版本、数据量做 diff，差异项优先验证；⑤ 闭环：复现步骤写成脚本或用例，双方按同一份步骤回归确认，修复后由客户侧验证并留记录。

易错：只凭客户口述就在自己环境试，试不出来就回复「无法复现」——没有 trace 和版本比对，等于把问题原样退回给客户。

追问：① 客户不给日志怎么办？② 只在生产偶发怎么抓现场？③ 复现后怎么确认是同一个问题？

答：别急着选模型和框架，先把「智能客服」翻译成可验收的问题：服务对象是谁、渠道在哪（网页 / 微信 / 电话）、要解决哪几类问题、人工坐席怎么介入、成功标准是什么（解决率 / 转人工率 / 响应时长）。用「场景 → 意图 → 数据 → 指标」四步拆：列高频场景，每个场景对应意图集合，每个意图要什么知识源，最后用什么指标验收。然后做 MVP：先覆盖 3-5 个高频意图，用真实会话跑基线与评测，再按数据补齐长尾。用原型让客户「看图说话」，比开十次需求会有效。落地时把结论写成「场景清单 + 验收口径」，每个意图配一个测试集和一条通过线；客户改口时走变更单，MVP 之外的需求进二期池子而不是随时插队。

易错：客户说「要智能」，团队直接定模型和框架——需求没收敛到可量化指标，做完了客户也不认。

追问：① 客户给不出指标怎么办？② 没有历史语料怎么冷启动？③ 怎么控制范围蔓延？

答：先把「不安全上线」拆成可协商的三件事：范围、质量、时间——明确告诉客户三者只能取二。给出分阶段方案：两周内交付「最小可用 + 受控灰度」，只覆盖核心链路，限客户内部小范围用户，附已知风险清单与回滚预案；安全加固、压测、容灾放到第二阶段并写进里程碑。同时书面确认责任边界：谁批准上线、谁值班、出问题谁决策回滚。不要口头答应全量上线，用「带条件的承诺」换客户对范围的让步。若客户仍不接受分期，就要求决策人书面确认并接受风险共担条款，同时把验收标准锚定在灰度范围内，别用全量标准卡小范围上线，会议结论同步商务与法务备案。

易错：为了签单口头承诺两周全量，上线后质量问题全算到交付方——没有书面风险清单和回滚预案，责任无法切割。

追问：① 客户坚持全量上线怎么办？② 灰度范围怎么选？③ 回滚预案要写清哪些内容？

答：分三层指标，且上线前就要定基线：① 业务层——解决率、转化率、人工工时节省、投诉率；② 系统层——可用性、P95 延迟、错误率、资源成本；③ 模型层——准确率 / 召回、拒答率、幻觉率、人工改写率。做法是上线前采集 2-4 周基线，上线后同口径对比；埋点要覆盖「用户输入 → 系统输出 → 用户是否采纳」三段，否则只有调用量、没有效果。按周出看板，指标异常时先核数据口径，再看模型。指标要落在客户能感知的场景（如客服看首次响应时长、一次解决率），并每周与客户一起过看板，避免交付方自说自话。每个指标的定义、计算公式与数据来源都要写进交付文档，避免月底对账时才发现口径不同。

易错：只报调用量和 QPS 这类「忙碌指标」，客户问「省了几个人」答不上来——业务指标必须有基线，否则无法证明价值。

追问：① 没有历史基线怎么办？② 采纳率怎么埋点？③ 指标好看但客户不满意，问题出在哪？

答：先分级再定策略：按变更影响面判定——只改文案或配置走冒烟，改核心链路跑回归子集，改数据或权限必须全量回归加回滚演练。紧急不等于跳过测试，而是「缩小范围 + 提高频次」：列出本次变更影响的接口与页面，做精准回归清单；用自动化冒烟守住 30 分钟内能跑完的部分；上线走灰度、留观察窗口、备一键回滚。同时记录「这次跳过了哪些测试」，事后必须补测。变更涉及数据库或权限时，必须准备可回滚的数据脚本并在预发验证；上线后保留 24 小时观察窗口与值班人，异常时先止血再定位。上线前把回滚步骤、观察指标和负责人同步到值班群，确保换班时任何人照着就能执行。

易错：把「紧急」当成免测通行证直接全量发布——能跳过的是回归范围，不能跳过冒烟和回滚验证。

追问：① 没有自动化怎么快速测？② 灰度观察多久合适？③ 补测怎么排期？

答：三条线：隔离、降级、可观测。隔离——依赖调用必须设超时和独立线程池或信号量，避免一个慢依赖拖垮全部线程；关键链路做舱壁模式，非核心依赖失败不影响主流程。降级——缓存兜底、返回默认值、异步补偿，明确每个依赖「挂了之后业务还能给什么」。可观测——每个依赖的调用量、错误率、延迟单独打点，用链路追踪定位谁在放大故障。另外必须控制重试：加重试就要配退避加熔断，否则重试风暴会二次放大故障。再进一步把依赖清单化：每个依赖标注是否关键、超时值、降级方式和负责人，新增依赖前先过一遍清单，避免悄悄引入强依赖。

易错：出问题只会加机器和重启，没区分「是我挂了还是依赖挂了」——没有按依赖维度的监控，故障传播永远定位不到源头。

追问：① 熔断阈值怎么定？② 重试风暴怎么防？③ 舱壁模式怎么落地？

答：先确认是不是真下降：固定一批回归集（含历史 badcase），新旧模型同 prompt、同参数跑对比，看指标差异和具体退化样本，同时排除自家 prompt / 检索 / 版本变更的影响。确认是供应商侧问题后：① 查变更公告与模型版本号，锁版本或回退旧版本；② 把退化样本整理成证据发给供应商；③ 短期用 prompt 补丁加后处理兜底，中期准备可切换的抽象层（多供应商或自建）。核心是模型调用必须有抽象层、版本可锁定，不能把模型名硬编码进业务代码。锁定版本后仍要保留旧版本的调用路径与权重文件，回退要做到小时级完成，而不是重新申请资源再部署一遍。

易错：只凭几个用户反馈就断定模型变差，没有固定回归集——既说服不了供应商，也定位不到退化点。

追问：① 回归集怎么建？② 供应商不认账怎么办？③ 多供应商切换成本怎么控制？

答：按「数据 → 特征 → 模型 → 链路」四层对齐。① 数据：口径是否同一份（时间窗、去重、过滤条件），线上是否有脏数据和空值；② 特征：线上特征是否实时计算，与离线口径是否一致，重点查时间穿越和默认值填充差异；③ 模型：线上是否跑着旧版本、量化或蒸馏版本；④ 链路：预处理、截断、超时降级是否改变了输入。方法是对同一条样本做「线上抓包 → 离线复现」，逐段比对中间结果，差异落在哪层就修哪层。排查时固定同一批样本做对照，记录每层的输入输出摘要；确认差异层后，把该层的一致性校验加进日常回归，防止再次漂移。每次换模型版本或改特征逻辑，都要跑这条单样本对照，别等指标掉了再回头查。

易错：直接怀疑模型效果，实际最常见原因是特征口径和时间窗不一致——先复现单条样本，别先调参。

追问：① 怎么抓单条样本？② 特征不一致怎么长期防？③ 时间穿越怎么检测？

答：算法指标证明「模型好不好」，业务指标证明「项目有没有用」，两者要能对上因果链。做法：① 先定业务目标（降本 / 增效 / 体验），再倒推可观测的业务指标；② 算法指标（准确率、召回、F1、AUC）按业务场景加权，别用平均分掩盖关键场景；③ 做 A/B 或前后对比，控制人群、时间、流量；④ 分析「算法涨 5 个点」为什么业务指标没动——常见是阈值、人工复核、流程没跟着改。结论要写清：指标提升落在哪个环节、折算多少钱。评估周期要覆盖完整业务周期（至少一个月），避免周内波动误判；结论同时给出样本量与置信度，别只报一个点估计。

易错：拿离线测试集的高分当交付成果，客户关心的是工单量降没降——指标之间没有因果链，效果无法归因。

追问：① 无法做 A/B 怎么办？② 阈值怎么调？③ 收益怎么折算成金额？

答：按「能不能通 → 通到哪 → 谁拒绝」顺序排：① 本机 curl 目标 IP 和端口，区分连接超时还是连接被拒；② 超时多为网络或防火墙策略，被拒多为服务没起或端口没监听；③ 用 ss / netstat 确认监听地址是 0.0.0.0 还是 127.0.0.1，只听回环时外部必然不通；④ 查安全组、防火墙、代理、负载均衡的后端端口映射；⑤ 确认域名解析是否指向内网地址、是否被代理改道。分层验证 ping、curl、应用日志三段，逐段缩小范围。若只有部分节点不通，对比同网段其他机器，快速判断是单机策略还是网段问题；排查过程记录每步命令与结果，方便客户网络团队协同。

易错：一上来就重启服务，实际问题在防火墙策略或监听地址——先分清「网络不通」和「服务没起」，重启解决不了策略问题。

追问：① 只有超时没有报错怎么定位？② 容器里端口怎么映射？③ 怎么区分 DNS 问题和网络问题？

答：现场约束先落地：不能重启、不能装新工具、只能远程。① 先用客户已有监控（主机面板、APM、容器指标）确认是整机高还是单进程高、用户态还是内核态，别一上来就要求装工具；② 远程只读手段：看 /proc 下各线程的 stat 与 wchan，确认谁在跑；镜像里若自带 jstack 或 py-spy，就间隔抓两次栈对比；③ 分类根因：死循环或忙等、锁自旋、GC、正则回溯、线程池打满、定时任务叠加，对照变更时间线；④ 不能重启时先用限流、降并发、摘流量、扩副本止血，把重启留到变更窗口；⑤ 全程留证据，事后给客户一份定位报告和整改计划。

易错：现场直接要求重启或装工具，客户生产窗口批不下来——先用已有监控和只读手段定位，止血方案要选不需要重启的。

追问：① 客户没有 APM 怎么看？② 只能看日志怎么判断死循环？③ 扩容止血后还要做什么？

答：默认按全离线私有化设计：① 硬件与模型——本地 GPU 服务器，权重、镜像、依赖包提前打包成离线介质，交付前在同等环境验证；② 推理服务——本地部署推理框架，提供内网 API，按并发估算显存与版本；③ 依赖组件——向量库、数据库、缓存全部内网自建；④ 运维——离线升级包、内网镜像仓库、许可文件离线导入；⑤ 合规——明确数据不出域、日志留存位置。交付前必须做一次「断网演练」，拔掉外网验证全链路可用。离线包要做完整性校验（哈希与清单），并在客户环境做一次全新安装演练，确认不依赖任何外网缓存与历史残留。版本与镜像清单随交付归档，方便后续核对。

易错：只验证模型能跑，忘了依赖下载、许可校验、时间同步这些仍需联网的环节——断网演练要覆盖部署、启动、升级全流程。

追问：① 显存不够怎么选模型？② 离线环境怎么升级版本？③ 授权到期怎么办？

答：数据不出域，就把整条链路搬进客户域内：文档解析、切分、向量化、检索、生成全部本地化；embedding 与 LLM 都用本地部署的开源模型，避免调用外部 API。关键点：① 权限——沿用客户原有文档权限体系，检索时按用户身份过滤，不能「检索到就能看」；② 审计——问答日志、命中片段、访问人留存，可追溯到原文；③ 生命周期——原始文档不落第二份，索引加密存储，项目结束或人员离场时清理。即便客户允许「只出向量不出原文」，也要评估向量可反演风险。另外把模型与索引纳入客户资产清单，明确谁持有密钥、谁能导出、项目终止时如何销毁，责任方写进交付文档。

易错：以为「数据不出域」只是不调外部 API，忽略了日志、监控、埋点也在往外传数据——链路每一环都要过一遍出网检查。

追问：① 本地 embedding 效果差怎么办？② 权限过滤怎么实现？③ 向量库怎么加密？

答：POC 的目标不是「做完」，而是用最小成本证明值不值得投。设计四件事：① 选场景——挑客户最痛、数据最全、边界最清楚的一个场景，别铺开；② 定成功标准——和客户一起写清「达到什么数字算通过」，最好带对比基线；③ 控范围——固定数据量、固定周期（2-4 周）、固定人力，明确不做什么；④ 出证据——用客户真实数据跑，输出可复现的评测报告与 badcase 分析。POC 结束必须有明确结论：通过就转商务，不通过就写清差距和补齐条件。POC 期间每周同步进展与风险，别到最后才给结论；同时留一份可复用的评测脚本在客户侧，便于后续自测。

易错：POC 做成缩小版正式项目，范围越加越大、周期越拖越长，最后既没结论也没法转商机。

追问：① 客户数据给不全怎么办？② 成功标准定太高怎么办？③ POC 和试点怎么区分？

答：文档按「接手人能不能独立运维」为标准写，而不是按「我做了什么」。最小集合：① 部署手册（环境要求、步骤、回滚）；② 运维手册（监控指标、告警阈值、常见故障处置）；③ 配置说明（每个参数含义与推荐值）；④ 接口文档与数据字典；⑤ 验收报告与已知限制。知识转移是动作不是文档：安排 2-3 次实操培训，让客户方在自己环境上亲手做一次部署和一次故障演练；建立答疑窗口期与升级路径。文档随版本更新，交付时签字确认接收。培训后安排一次考核或演练验收，确认客户方真能独立操作；同时留下升级与答疑的联系路径和责任窗口，并约定交接后的过渡支持期。

易错：交付一堆截图式文档，客户接手后连服务怎么重启都找不到——文档验收标准是「新人照着能做一次」，不是「页数够多」。

追问：① 客户没人接手怎么办？② 文档怎么保持更新？③ 培训效果怎么验证？

答：SLA 要可测量才可承诺：① 分级——按严重程度定义 P1-P4，每级写清响应时限、恢复时限、通报频率；② 口径——可用性按月算还是按季算、是否剔除计划维护，响应从「客户报障」还是「我方确认」开始计时；③ 能力——值班表、一线到二线的升级路径、监控告警先于客户发现；④ 兜底——重大故障的应急小组、备用环境、复盘机制。承诺前先算清自身能力与成本，违约条款写赔偿上限，别承诺做不到的分钟级恢复。另外把 SLA 与监控口径对齐：告警触发、工单创建、恢复确认三个时间都要能自动记录，否则事后只能靠回忆争论是否超时。值班交接要有书面记录，谁接手谁签字。

易错：只写「7×24 响应」不写计时起点和恢复定义，出事时双方对「是否超时」各执一词。

追问：① 计划维护时间怎么算？② 夜间值班怎么排？③ 违约怎么赔偿？

答：核心原则：定制配置化，不定制代码。① 分层——产品主干保持单一主线，客户差异收敛到配置、插件、扩展点（开关、策略实现、字段映射）；② 分支策略——每个客户最多一条短期交付分支，禁止长期客户专属主干，改动必须回合主线；③ 差异化目录——客户特有逻辑隔离到独立模块，通过接口挂载，主干不引用客户代码；④ 发布——同一套构建产物加不同配置包。确实无法配置化的需求，先评估是否所有客户都需要，别为一家改坏全线。定期做一次「主线合并演练」，把各客户分支的改动合回主干并跑全量回归，及早暴露分叉成本，而不是等到发版才发现合不动。

易错：为赶交付直接复制一套代码给客户改，半年后升级主线时没人敢合——技术债的利息远高于当时的交付速度。

追问：① 客户坚持要改代码怎么办？② 配置项太多怎么管？③ 老分支怎么回收？

答：分歧通常来自「标准没量化」和「范围没边界」。做法：① 回到合同与需求文档，把模糊表述逐条翻译成可测条目（输入、判定方法、通过阈值、样本量）；② 承认不可测项，改为双方共同评审确认；③ 对超出原范围的要求走变更流程：加钱、加时间或减范围，三选一；④ 先验收已达成部分，未达成部分列整改计划与复验时间，避免整体卡死。沟通上只谈事实与证据，不争「我觉得够好了」。每次验收会都出书面纪要，列明已通过项、待整改项与复验时间；分歧较大的条目单独拉专题会，用数据而不是主观判断收口，纪要同步给双方商务负责人。

易错：为推进验收口头答应「再改改就好」却没有变更记录——范围无限膨胀，最后既延期又难收款。

追问：① 客户拿竞品对比怎么办？② 标准无法量化怎么办？③ 客户迟迟不签字怎么处理？

答：复盘对事不对人，用固定结构：① 时间线——从首个异常信号到恢复，精确到分钟，含谁做了什么决策；② 影响——受影响客户数、时长、数据是否受损、金额；③ 根因——区分直接原因与系统性原因（为什么监控没发现、为什么变更没拦住）；④ 处置——已做的止血动作及其有效性；⑤ 改进项——每条有 owner 和截止时间，能落到监控、流程、代码上。汇报分两层：对客户讲影响、处置、改进承诺；对内讲根因与改进项，不甩锅。复盘会控制在 60 分钟内，先讲事实再讲结论；改进项超过两周未闭环要升级通报，避免复盘变成走过场，复盘结论与改进项要全员可见。

易错：复盘写成「某人操作失误」就结束——个人失误背后往往是流程和监控缺失，只处理人不改机制，同类事故必然复发。

追问：① 客户要赔偿怎么谈？② 改进项怎么跟踪闭环？③ 事故等级怎么定？

答：按「对什么结果负责」划分：售前负责赢单——方案讲解、技术答疑、投标支持，对签单负责；FDE 负责交付落地——需求拆解、环境部署、联调验收、效果达标，对「客户能用起来」负责；售后负责持续服务——日常工单、SLA 响应、续约维护；产品经理负责产品定义——需求取舍、版本规划，对通用能力负责。灰区靠机制：售前承诺的技术可行性由 FDE 会签，交付中发现的通用需求回流产品，上线后运维交接给售后并留过渡期。接口人机制同样关键：客户侧有明确对接人，内部有单一 owner；跨角色争议由项目负责人裁决，避免多头指挥，交接清单由双方签字确认。

易错：把 FDE 当成「什么都管的项目经理」，售前乱承诺、售后乱接需求都压到交付——边界不清，最后所有问题都算交付的锅。

追问：① 售前承诺做不到怎么办？② 需求回流产品怎么排优先级？③ 小团队一人多角色怎么分？