用法：每个项目先背熟 30 秒 STAR，追问按「答」完整说；被追问到底层细节时，宁可讲「我当时怎么排查验证的」，不要硬编没做过的。配套页面：面试当晚手册 · 题库完整回答。
一、工业互联网数据采集分析平台（分布式招牌项目）
30 秒 STAR： 业务是海量工业终端数据的实时采集与分析（S：设备数据孤岛、分析滞后）。我主导架构（A），设计了「边缘采集 → Kafka → Flink → TDengine」的分层流式流水线，接入层把 MQTT、Modbus、OPC-UA 协议做成插件化，配套注册中心、网关、熔断限流的服务治理。结果（R）：支撑万级设备并发、日处理亿级数据点、端到端秒级延迟，新设备接入从天级降到小时级。
追问：为什么选 TDengine，不用 InfluxDB？
答：当时选型对比了三个维度。第一是建模契合度：TDengine 的超级表加标签的设计天然贴合物联网设备模型——每台设备一张子表，设备属性（型号、厂区、位置）做标签，按标签聚合查询直接走索引，不需要像 InfluxDB 那样精心设计 tag 组合；第二是成本：时间戳加列式的 delta 压缩让压缩率非常高，同样的数据量存储成本大幅低于通用数据库，而且自带降采样和数据保留策略，冷热分层不用自己做；第三是工程生态：集群版开源可用、国内支持响应快，InfluxDB 的开源版基本是单机，集群要企业版付费。加分项是我们也评估过 ClickHouse——分析能力确实强，但它是为分析型负载设计的，写放大和高频小报文写入不匹配，最终定位还是专用时序库。
追问：Kafka 在这个架构里的作用？分区怎么设计的？
答：三个作用：削峰——设备上报有明显的波峰（整点批量上报、产线启停），Kafka 把洪峰排队摊平，下游按稳定速率消费；解耦——采集协议变化、计算逻辑调整、存储更换，各自独立演进互不影响；顺序保障——分区内的消息有序。分区设计核心是「同设备进同分区」：按 deviceId 哈希路由，保证同一台设备的时序数据有序，时序计算才正确。分区数的估算有公式：设备数 × 上报频率 × 平均报文大小 = 峰值写入带宽，除以单分区吞吐能力（压测出来的），再留 30% 到 50% 扩容余量。消费者并行度跟着分区数走，所以分区数也决定了计算层的横向扩展上限。
追问：Flink 怎么保证 exactly-once？
答：分三段讲。Source 层：消费偏移量的提交和 checkpoint 绑定——offset 只在 checkpoint 成功后才提交，恢复时从快照里的 offset 重放。计算层：checkpoint 机制——barrier 随数据流向下游，算子收到所有输入通道的 barrier 后对齐、把状态快照进状态后端，我们用 RocksDB 支持大状态和增量快照；所有算子的快照组成全局一致的检查点。Sink 层是关键：写 TDengine 这种外部系统，要防「恢复重放时重复写入」——我们把计算结果先写回 Kafka 的事务 topic，用两阶段提交：预提交阶段数据写入事务、checkpoint 完成后提交事务，消费端 read_committed——这样端到端是精确一次。再补一句工程兜底：sink 侧也配了按批次的幂等写入（按设备加时间戳去重），双保险。
追问：出现背压怎么处理？
答：先定位再处理。Flink 自带反压检测，WebUI 和 metrics 能看到每个算子的 inQueue/outQueue 表现——阻塞会沿着数据流向上游传导，找到传导链的最底端就是慢算子。处理手段按层次：算子级——提高慢算子并行度；异步化——同步 IO 调用（查维表、调外部接口）改成异步 IO，并行发多个请求；状态调优——RocksDB 的写放大严重时调 block cache 和 write buffer。链路级：Kafka 消费端限流保护下游，防止雪崩；极端情况业务降级——上报频率降采样，比如秒级数据在高压期聚合成 10 秒级再传，扛过峰值再恢复。我们实际遇到的一次是 TDengine 写入变慢导致反压，最终解法是 sink 侧攒微批加并行写，单点写入瓶颈消掉。
追问：Modbus、OPC-UA 是什么？接入层怎么设计的？
答：Modbus 是工业领域最老牌的串口/以太网协议，主从模式、主站轮询从站，数据模型就是寄存器和线圈，简单但没有任何安全机制。OPC-UA 是新一代工业互联标准：信息模型——不只是数据还有语义，设备能力描述成对象和属性；通信上支持订阅推送，不用轮询；有完整的认证加密体系。接入层的设计：我们把「协议差异」和「数据处理」彻底分离——抽象了统一的内部模型，任何协议进来都映射成「点表 → 遥测/遥信」的标准结构，然后每种协议实现一个插件：新增一种协议就加一个插件模块，注册到插件管理器，主流程代码零改动——新设备接入从改代码的天级变成配点表的小时级，就是这次设计的直接收益。
追问：万级设备并发，怎么压测和做容量评估？
答：压测方案：自研边缘模拟器——模拟设备行为造流量，按「设备数 × 上报频率 × 报文大小」三个变量组合施压，从千级设备逐步加到两万级，超过目标容量 20% 验证余量。分链路压：接入层单连接吞吐、Kafka 分区写入带宽、Flink 各算子处理能力、TDengine 写入 TPS，各自独立摸上限，找到最薄弱的环节。核心观测指标：写入 TPS、端到端延迟 P99、Flink checkpoint 时长和成功率、反压指标——checkpoint 时长随压力恶化到阈值就要扩容。容量评估输出是一张容量表：每增加一万台设备需要多少分区、多少 Flink 并行度、多少存储，扩容从救火变成查表。
追问：秒级延迟是怎么测出来的？
答：端到端延迟的定义先说清：设备端产生数据的时刻到数据在 TDengine 可查的时刻。测法：采集端在报文里透传 event time——设备侧打点；落库时对比 TDengine 的落库时间与 event time 的差值，作为延迟指标进入监控，按分位数统计——看 P99 而不是平均值，平均值会被长尾掩盖。测试环境用模拟器精确控制发送时刻，生产环境持续采样统计。答到这里再补一句：秒级是设计目标——链路上每一段都预算了延迟份额（接入毫秒级、Kafka 毫秒级、Flink 计算百毫秒级、写入毫秒级），监控每段的分位延迟，超预算就能定位到段——延迟是设计出来的，不是碰运气测出来的。
二、智慧农场管理系统（微服务招牌项目）
30 秒 STAR： 多农场 SaaS 化管理的业务需求（S）。我主导微服务架构（A）：基于 Spring Cloud Alibaba 拆分设备、灌溉、监测、权限、看板服务，Nacos 做注册配置中心，Sentinel 做熔断限流；设计了 IoT「采集 → 阈值判断 → 自动联动」的执行闭环和多租户数据模型。结果（R）：多农场落地、千级 IoT 设备接入，异常发现从小时级提升到分钟级。
追问：服务怎么拆的？粒度依据是什么？
答：拆分依据三条：业务能力——按领域边界拆出设备、灌溉、监测、权限、看板；变更频率——经常一起发布的需求聚在一起，减少跨服务变更；团队边界——服务归属清晰，一个服务一个责任团队。原则是每个服务能独立发布、数据自治——每个服务独立数据库，别的服务要数据走接口不直连库；严格避免环形依赖，依赖只能是单向的。粒度上我反对「越细越好」：跨服务调用本身是有成本的——网络、序列化、一致性，拆得太细，一次业务操作变成五次远程调用，故障面和排查难度都上来了。经验值：先按业务域粗拆，运行一段时间，真正的疼痛点（发布互相阻塞、数据强耦合）出现了再细拆——演进式拆分优于一次性设计。
追问：多租户隔离怎么做的？
答：先说选型对比：SaaS 多租户三种方案——独立数据库，隔离最好、成本最高，适合对安全极端敏感的大客户；共库共 schema 加行级 tenant_id，成本最低、隔离最弱，适合中小租户；共库独立 schema 折中。我们选了行级隔离，配两道保障：落库层——MyBatis 拦截器自动给所有 SQL 注入 tenant_id 条件，业务代码完全不感知，从机制上杜绝「忘了加条件查出别人数据」；上下文层——登录时权限服务统一鉴权，解析出租户身份放进请求头透传，网关和各服务的过滤器把租户上下文放进 ThreadLocal，整个链路随身携带。补一个演进：如果未来出现大客户，架构支持给他单独库——隔离策略是按租户分级配置的，不是一刀切。
追问：自动联动闭环怎么保证可靠？指令丢了怎么办？
答：这是整个系统最核心的可靠性设计。下行指令链路：联动规则触发后，指令先落库产生记录，再通过 MQ 下发——本地状态机管理生命周期：下发 → 设备确认 → 执行成功，任何状态超时未推进就重发，重试次数用完转人工告警。防丢：MQ 的持久化加消费确认保证「至少一次」到达网关；网关到设备端是 IoT 场景的薄弱环节——设备可能离线，靠重发和超时兜底。防重：每条指令带唯一 msgId，设备侧幂等执行——收到重复指令直接返回上次结果，不会重复开关阀门。解耦和审计：规则引擎只负责「判断要不要动」，执行器负责「怎么动」，中间走 MQ——规则变更不影响执行链路；所有关键动作落库可审计可回放，出了问题能完整还原当时的水位、阈值和决策依据。
追问：Nacos 的原理了解吗？
答：分两个角色讲。注册中心：服务实例启动时注册，客户端和服务器之间维持心跳；2.x 改成了 gRPC 长连接——连接级的心跳加推送，服务列表变更时服务端主动推送给订阅方，比 1.x 的 UDP 推送加客户端定时拉取可靠得多。配置中心：客户端发起长轮询——服务端 hold 住请求 30 秒，配置有变更立即返回，没变更超时返回，客户端再发起下一轮——实时性和连接成本的最佳平衡。一致性模式：临时实例走 AP——心跳失效即剔除，可用性优先，注册中心短暂分区也不影响本地服务列表可用；持久实例走基于 RAFT 的 CP，保证配置数据强一致。选 Nacos 的原因就是「注册加配置二合一」，还能在 AP/CP 间按场景切换。
追问：Sentinel 和 Hystrix 的区别？你们怎么用的？
答：Hystrix 是线程池隔离模型——每个依赖一个线程池，隔离彻底但线程开销大、不支持动态规则，而且已经停止维护。Sentinel 的差异：基于滑动窗口的实时统计——每个资源的 QPS、RT、异常数秒级可见；保护策略更丰富——流量控制（QPS、并发线程数、热点参数限流）、熔断降级（慢调用比例、异常比例、异常数三种策略）、系统自适应保护（按 Load 和 CPU 入口限流）；最实用的是控制台——规则动态下发，改限流阈值不用重启服务。我们的落地：对外接口配 QPS 限流加热点参数限流——按农场 ID 维度防单租户打爆；对下游依赖配慢调用比例熔断——RT 超阈值比例过半就熔断，半开探测恢复；核心接口都配了 fallback 降级——返回缓存快照或友好提示。
追问：服务间调用怎么保证数据一致性？
答：我们的原则是：跨服务一律不强求分布式事务，优先最终一致。方案一：本地消息表——业务操作和「待发送消息」在同一个本地事务落库，后台任务扫表投递到 MQ，消费方幂等消费；消息表本身有重试和状态，失败了能补偿。方案二：直接用 RocketMQ 事务消息——半消息加回查机制，省掉自建消息表。幂等在消费端做：唯一业务键加状态机——比如「设备状态变更」消息，消费时状态已经推进就忽略。确实需要强一致的场景很少——我们只有一处「权限变更实时生效」用了 Seata AT：自动生成 undo log 反向补偿，改造成本低，但要接受全局锁对吞吐的限制。对账是最后兜底：每天跑数据核对任务，把跨服务的数据差异捞出来自动补偿或人工处理。
三、AIHPC 高性能混合计算集群
30 秒 STAR： 训练、推理、科学计算混合负载共存的集群（S）。我参与整体架构（A）：打通 K8s 与 HPC 调度器的作业语义，开发作业提交与状态同步网关；独立设计 AIHPC-Alarm 告警模块——GPU 利用率、作业完成、超时事件的全链路告警与可观测体系。结果（R）：基于 fastx 实现分钟级通知，集群治理提效 20%。
追问：K8s 和 HPC 调度器（如 Slurm）的语义差异？
答：设计哲学完全不同。K8s 面向服务：调度单位是 Pod——长期运行的常驻进程，声明式期望状态，失败自动重建，弹性伸缩强；但对批处理作业的支持弱——没有队列配额体系，抢占是驱逐式的、粗暴。Slurm 面向作业：核心概念是 job——有明确生命周期（提交、排队、运行、完成），有队列、用户配额、优先级，拓扑感知调度——GPU 亲和、IB 网络就近，支持 gang scheduling 作业组调度——分布式训练要的全部东西。我们网关做的事就是语义翻译：把用户统一的「提交训练作业」翻译成两边各自的 API；维护双向状态机——Slurm 的作业状态和 K8s 的 Pod 状态都映射到统一状态模型（排队/运行/完成/失败），事件驱动的增量同步。难点在语义对齐——比如 K8s 的 Pod 重启和 Slurm 的作业重跑，对用户都该表现为「运行中」还是「重试」，需要逐个定义清楚。
追问：GPU 资源池化怎么做的？
答：四个层次。资源上报：K8s 侧用设备插件把 GPU 以扩展资源上报给调度器——nvidia 设备插件加 DCGM exporter；HPC 侧 Slurm 本身就管理 GPU。拓扑标记：节点打上 GPU 型号、卡数、NVLink 有无、网络位置的 Label——调度时能按拓扑亲和。分池配额：训练池、推理池、科学计算池物理或逻辑隔离，各池独立配额——防止推理流量把训练卡抢光，也防止大作业把小任务全挤掉队。调度策略：按卡亲和调度——多卡作业尽量落在同 NVLink 域内；跨机作业感知 IB 网络拓扑。监控：DCGM 采集利用率、显存、温度、ECC 错误进 Prometheus——利用率数据既给告警（空转检测、显存泄漏嫌疑），也给容量治理（哪些池常年 30% 利用率可以回收）。
追问：告警模块怎么设计的？怎么防告警风暴？
答：架构是「采集 → 规则 → 路由 → 通知」四段。采集：DCGM 的 GPU 指标、作业生命周期事件、队列堆积、节点健康检查，统一进消息队列。规则引擎：阈值规则——GPU 温度、显存越界；持续时间规则——利用率连续两小时低于 10% 判空转；同比环比——对比上周同时段判断异常；每条规则产出结构化告警事件。分级路由：按严重程度和影响面分级——影响生产作业的走电话加 fastx 即时通知，资源类走群消息，统计类进日报。防风暴是设计重点，四个机制：告警聚合——同源同因的事件合并成一条，附影响对象列表；静默期——同一告警在收敛窗口内不重复发；分级抑制——节点宕机时，抑制该节点上所有作业的衍生告警，只发根因；自动恢复通知——指标回归后发恢复消息，闭环。上线后告警量从每天上千条压到几十条有效告警，运维才愿意看。
追问：提效 20% 怎么量化的？
答：口径是治理工时对比，不是我拍脑袋。取了三类日常治理动作做基线：故障定位——从告警到定位到具体节点/作业的平均耗时；资源回收——低利用率作业的识别、通知、回收流程工时；作业巡检——每日检查队列堆积、异常作业的人工耗时。模块上线后跑满一个月，同样的动作类目统计工时，前后对比——比如故障定位从平均 40 分钟降到 10 分钟，因为告警直接带上了根因上下文和影响面；巡检基本自动化，只剩异常处理。月度汇总下来人工工时降了 20% 左右。答量化题的关键是把口径说清楚——统计了什么、怎么统计的、周期多长，数字才立得住。
四、开源大模型工程化部署（AI 差异化项目一）
30 秒 STAR： 业务要以低成本用上开源大模型（S）。我负责 GLM、DeepSeek 的端到端部署（A）：vLLM/SGLang 推理框架加 Tensor Parallel 多卡并行，FP8/AWQ 量化压缩，KV Cache 与 Prefix Cache 优化；服务化层做 API 网关、负载均衡、按 QPS 和 token 速率的弹性伸缩，支持流式输出、函数调用和长上下文。结果（R）：显存占用和首 token 延迟显著下降，新模型上线周期从周级压缩到天级。
追问：vLLM 为什么快？
答：两个核心机制。PagedAttention：传统实现给每个请求的 KV Cache 预分配最大长度的连续显存——大量浪费在「预留了没用到」和显存碎片上，实测利用率只有三四成；vLLM 借操作系统的分页思想，把 KV Cache 切成固定大小的 block 按需分配、逻辑块映射物理块——显存利用率提到九成以上，同样的卡能并发的请求序列长了好几倍，吞吐直接上来。Continuous Batching：传统 static batching 要等一批里最长的请求全部生成完才能换下一批，短请求陪跑；continuous batching 做到迭代级调度——每一步 decode 后，完成的请求立刻退出、新请求立刻插进来，GPU 永远满载。一句话总结：显存利用率的革命加调度粒度的革命。
追问：Tensor Parallel 的原理？和 PP、EP 什么区别？
答：三种切分维度。TP 张量并行：把注意力头和 FFN 的权重矩阵按维度切到多张卡，每卡算自己那部分，关键点在计算中间需要 all-reduce 同步——通信量跟计算量成正比，所以依赖高带宽互联，适合单机内 NVLink 场景；单机 8 卡基本是标配方案。PP 流水线并行：按 Transformer 层切——1 到 16 层在机器 A、17 到 32 层在机器 B——跨机只传激活值，通信量小；但一个请求要流过整条流水线，用 micro-batch 切小批灌满流水线来压气泡（bubble）时延；适合超大规模模型跨机扩展。EP 专家并行：MoE 模型专用——把不同的专家分布到不同卡，token 按路由结果找卡。我们的场景是单机 8 卡，所以 TP=8 一步到位；跨机的大模型才需要 TP 加 PP 组合。
追问：FP8 和 AWQ 的区别？怎么选？
答：都是量化但路径不同。FP8：浮点 8 位——权重和激活都压到 8bit，收益是双重的：显存减半，更重要的是计算走 FP8 硬件指令，速度也提上去；要求硬件支持（Hopper 架构之后），数值格式保留指数位，精度损失很小。AWQ：激活感知的权重量化——观察到「少数重要权重」对激活分布敏感，保护这些 salient weight，其余权重量化到 INT4——只压权重，推理时反量化计算，显存省得更多（INT4 对比 FP16 是四分之一），通用性好、不挑卡。选择策略：精度敏感链路（代码生成、数学）用 FP8；成本敏感、吞吐优先用 AWQ。但都要过评测集——上量化前跑业务评测基准对比精度回退，回退超过阈值就升精度档位，这个流程比选哪个方案更重要。
追问：首 token 延迟（TTFT）怎么优化？
答：先讲原理：TTFT 由 prefill 阶段主导——把整个 prompt 一次算完才能出第一个字，prompt 越长 TTFT 越长。优化手段按收益排：Prefix Cache——系统提示词是所有请求共享的前缀，把它的 KV Cache 缓存复用，命中时 prefill 只算用户输入部分，长系统提示场景 TTFT 断崖式下降；量化——降低 prefill 的计算量；控制并发 batch 大小——batch 越大单步越慢，延迟敏感的池子限 batch 上限，用吞吐换延迟；系统提示精简——把废话从 prompt 里删掉，几千 token 的祖传 prompt 精简到几百，直接省掉大半 prefill；长上下文分段处理——超长输入先做检索式截断再进模型。监控上把 TTFT 和 TPOT 分开看——TTFT 反映 prefill，TPOT 反映 decode，两个指标恶化的原因和解法完全不同。
追问：弹性伸缩用什么指标？QPS 有什么坑？
答：直接用 QPS 是踩过坑的。LLM 服务的 QPS 完全不反映真实负载——一个「100 token 短问答」和一个「10 万 token 长文档总结」算一个 QPS，计算量差三个数量级；按 QPS 伸缩，要么扩容不足服务过载，要么盲目扩容浪费卡。我们改用三个指标：并发请求数——正在处理加排队的请求数，最直观的饱和度；token 速率——输入加输出 tokens/s，真实计算负载；队列深度——等待 prefill 的请求数，领先指标，涨了就是要扩。还有一个伸缩特性要单独应对：扩容冷启动特别慢——加载模型权重加预热要几分钟，等指标触发再扩就晚了；所以配了预热池——常备一两个已加载模型的 standby 实例，扩容只是流量切换；缩容方向相反要保守——冷却期拉长，避免流量波动期的抖动伸缩。
追问：上线周期怎么从周压到天的？
答：把重复劳动流程化。原来上模型的步骤散在各处：下载权重、改配置、试运行、调参、压测、改网关路由、配监控——每一步都靠人记，来回试错一周很正常。我做的沉淀是流水线模板化：模型权重管理——统一仓库和版本；一键部署脚本——量化脚本、推理服务参数模板按模型类型预置，新模型只填差异项；基准评测自动化——部署完成自动跑吞吐、TTFT、TPOT 和精度评测集，出对比报告，不达标自动标红；灰度上线——先切 5% 流量观察监控，指标正常再全量；监控接入标准化——Prometheus 指标和告警规则是模板自带的。新模型上线变成「填一份差异配置、跑一条流水线」，正常一天走完全流程——周期的本质不是哪个环节变快了，是把「人肉串联」变成了「流水线自动串联」。
五、coremind Token 中转中心（AI 差异化项目二·架构代表作）
30 秒 STAR： 多家异构大模型 API 协议不一、成本难管控（S）。我主导架构（A）：把 Claude、OpenAI、Gemini、本地模型统一成标准 OpenAI 格式，兼容 MCP；aksk 体系做多租户配额、限流与计费；智能路由按能力、成本、SLA 动态选择 provider 并做故障转移；语义缓存降成本；配套 AI Native 研发流水线——Claude Code 加 Agent 加 MCP 的需求、编码、CR、回归链路。结果（R）：新特性交付从 12 小时压到 15 分钟，AI 代码采纳率 85%，语义缓存显著降低成本。
追问：多协议适配怎么设计的？
答：适配器模式落地。统一内部消息模型先定义好——消息、角色、工具调用、流式分块的标准结构；每个上游 provider 一个 adapter，负责三个方向的转换：请求——内部标准格式转各家 API 格式；响应——各家返回转标准格式，重点是流式：每家的 SSE 分块事件结构不同，adapter 把 delta、工具调用增量、结束原因都归一化成标准事件流；错误——各家错误码转统一错误体系，方便路由层做重试和熔断决策。新增 provider 就写一个新 adapter 挂进来，主干零改动——这是开闭原则的实际收益：我们接新模型从排期一周变成两天，其中一天还是等账号审批。再补一句：统一之后，「能力开关」也标准化了——长上下文、函数调用、多模态这些能力变成 provider 的元数据，路由层的输入就来自这里。
追问：智能路由的策略？
答：路由决策是多个因子的加权规则引擎。任务类型匹配能力：请求带特征——上下文长度、要不要函数调用、要不要多模态——先过滤出满足能力要求的 provider 候选集；成本因子：token 单价乘以历史用量特征——长上下文请求在单价比率不同的模型间成本差很大；SLA 因子：各 provider 的实时时延和可用性统计——滚动窗口内的 P99 延迟和错误率。规则引擎按优先级执行：硬性能力过滤 → 降级到成本权重 → SLA 摘除。故障转移：健康检查持续探测，连续失败把节点摘除，转半开状态放少量探测流量，成功才恢复——这套是熔断器思想在路由层的应用。用户侧还可以配策略偏好——某租户指定「成本优先」或「质量优先」，路由参数化。
追问：语义缓存的原理？命中率和风险？
答：原理：请求的 embedding 向量化，进向量库做 ANN 检索，相似度超过阈值就判定「语义等价」，直接返回缓存的响应——相当于把「完全相同的请求才命中」的传统缓存，扩展成「意思相同的请求也命中」。收益：我们的场景里客服话术、常用翻译、固定文档总结这类请求重复度高，命中率可观，直接省掉上游调用成本。风险必须讲透，这是这道题的价值所在：语义相似不等于意图相同——「怎么退货」和「怎么换货」向量很近但答案不同；时效性内容——「今天天气」「最新版本号」命中旧缓存就是错误答案。风控策略：只缓存无上下文的单轮、事实稳定的请求类型；相似度阈值调高，宁可少命中不能错命中；TTL 控制；缓存命中响应打标记，用户侧可配置「强制回源」开关。诚实说：这是个「收益和风险都要量化」的优化，不是免费午餐。
追问：计费怎么防超卖、保证准确？
答：预扣加实结的两段式。请求前：按请求特征预估 token 量——输入长度加预期输出——从租户配额里原子预扣（Redis 的 decrby 配 Lua 保证原子），预扣失败直接拒绝，防「先服务后记账」的超卖；响应后：按实际用量结算——流式响应边收边累计，结束后用实际值回补差额。配额本身用 Redis 原子操作，多实例并发扣减没有竞态。准确性靠对账兜底：上游账单和本地计量流水日结对账——按 provider、按租户、按天三个维度比对，差异超过阈值告警，人工或自动核差。还有两个细节：流式的用量以 finish 后的 usage 字段为准，不信本地估算；失败重试的请求只计一次——按 msgId 去重计量。这套本质就是「支付系统的记账三件套：预扣、实结、对账」搬到 token 计量上。
追问：限流怎么做的？
答：多维度分层。租户级：aksk 识别租户，配 QPS 上限加 token/min 配额——前者防请求洪峰，后者防「单请求不大但总量薅死你」，token 配额和计费的预扣共享一套原子操作。接口级：网关层滑动窗口判断限流阈值，超限快速失败——快速失败很重要，返回 429 加 Retry-After 头，让客户端知道等多久，而不是挂住请求拖垮网关。系统级：provider 侧的压力反向传导——上游 429 或时延恶化时，路由层自动降速，入口层配合收紧，防止把上游配额打爆后全量雪崩。实现上：单机限流 Guava RateLimiter，分布式限流 Redis 加 Lua；但核心思想是分层——入口限请求数、配额限 token 量、上游反馈调全局限速，三个层次各管各的。
追问：85% 采纳率怎么统计的？口径说清楚。
答：口径先立住：分母是「AI 参与生成的代码变更」，分子是「经人工 code review 后被合入的部分」，按 PR 统计变更行占比，流水线自动采集——不是「AI 写了 85% 的代码」，是「AI 生成参与的变更里 85% 被采纳合入」。这个口径的来源是 CR 环节：AI 生成的 PR 全部走人工终审，审过的合入计入分子，被驳回重写或大改的只计分母。为什么强调口径：这个数字最容易被挑战「AI 代码质量行不行」——有了精确口径，就能继续展开质量保障机制：自动 CR（静态检查加测试门禁）先行过滤、人工终审把关、采纳率的趋势按特性类型分层看——模板类代码采纳率接近 95%，复杂逻辑也在七成以上。数字加上机制，才是完整的答案。
追问：12 小时到 15 分钟，边界在哪？
答：主动划边界反而加分。15 分钟指的是指标型小特性：加接口、增删改查、参数调整、脚本工具——需求明确、模式固定、测试可自动化的部分，流水线从需求描述直达上线。12 小时是原来的基线——同样的特性要过手工编码、自测、提审、等审、部署一整套人肉流程。不在这个口径里的：大型架构变更——涉及跨服务数据模型重构、技术选型、性能权衡的，依然人来主导，AI 是加速器不是决策者；还有安全合规敏感的变更——鉴权、计费核心，人工审查比例反而要加大。所以准确的表述是「交付链路里可标准化的部分被流水线吃掉了，节省的是流程和重复劳动，不是判断力」——把边界说清楚，数字才可信。
六、系统设计题预演：拿自己的项目当答案
面试官出系统设计题时，主动往自己做过的系统上靠。结构统一是：澄清边界 → 估量级 → 画分层 → 数据模型 → 逐层说权衡。
「设计一个大模型 API 网关 / 中台」——这就是 coremind 本身。
答：分层讲：协议适配层——每家 provider 一个 adapter，统一成标准 API，兼容 MCP；网关层——aksk 鉴权、多维限流、灰度路由；计量计费层——预扣实结加对账，成本是第一公民；智能路由层——能力、成本、SLA 三因子，健康检查加故障转移；缓存层——语义缓存，带风控策略；可观测层——token 用量、TTFT/TPOT 分位、成本大盘。亮点落点：把「成本治理」讲成架构的第一公民——多数候选人只讲功能，讲成本模型和计费准确性是代差。
「设计一个 IoT 数据接入平台」——这就是工业平台。
答：分层：边缘采集层——协议插件化，统一点表模型；消息层——Kafka 按 deviceId 分区保序，分区数按吞吐公式预估；计算层——Flink 事件时间加 watermark，状态后端 RocksDB，两阶段提交 sink；存储层——TDengine 超级表建模加保留策略降采样；治理层——背压检测、分级降级、容量表驱动扩容。亮点落点：容量公式现场推导——设备数 × 频率 × 报文大小——用数字推导代替「我们会扩容」这种空话。
「设计一个多租户 SaaS」——这就是农场系统。
答：租户模型三方案对比开场——独立库、共库独立 schema、行级隔离——按客户分层混合使用；租户上下文从登录态解析，请求头透传加 MyBatis 拦截器自动注入，机制性防越权；配额与计费——资源配额表加用量采集；数据导出与隔离合规——按租户的导出加删除（被遗忘权）流程。亮点落点：隔离强度和成本的权衡表，以及「大客户单独库」的分级演进路径。
没做过的题（短链、排行榜、Feed 流）怎么答？
答：现场推演展示思考过程，套路五步：澄清需求边界——读写比、量级、一致性要求；估量级——日活乘次数得 QPS，乘年限得存储；存储选型——按读写模式选型并说理由；缓存与热点策略——什么值得缓存、热 key 怎么打散；扩展路径——单库到分片的触发条件和迁移思路。评分点在「每一步有数字、每个选型有理由」，不在答案本身对不对。
七、AI 工程加分问答（差异化主战场）
Q：TTFT 和 TPOT 是什么？为什么分开看？
答：TTFT 是首 token 延迟——从发请求到第一个字出来，由 prefill 阶段主导，prompt 长度是第一变量；TPOT 是每 token 生成时间——后续每个字的平均间隔，由 decode 阶段主导，受 batch size 和显存带宽影响。分开看的价值是定位：TTFT 恶化——查 prefill：是不是 prompt 变长了、Prefix Cache 失效了、batch 太大；TPOT 恶化——查 decode：batch 是不是太大、GPU 是不是被别的租户挤了、模型是不是换了量化档。两个指标恶化的原因和解法完全不同，合在一起看「平均延迟」就丢掉了全部诊断信息。能把这两个词说清楚并用它们定位过问题，就已经超过多数候选人。
Q：MCP 是什么？解决什么问题？
答：MCP 是模型上下文协议——Anthropic 推出、正在成为行业标准的开放协议。它解决 N×M 碎片化问题：过去 M 个应用 × N 个工具，每个应用要为每个工具做一次集成；MCP 把工具、资源、提示词标准化成「服务」，客户端和服务器解耦——工具方实现一次 MCP server，所有支持 MCP 的客户端（Claude、IDE、Agent 框架）都能用。架构是客户端-服务器模型：MCP client 跑在宿主应用里，MCP server 暴露三类原语——tools（可调用的能力）、resources（可读的数据）、prompts（可复用的提示模板），传输走 stdio 或 HTTP。类比它是「AI 界的 USB-C」：接入标准化之后，生态组合爆炸。我在 coremind 做了 MCP 兼容层，也用 MCP 给研发流水线接了 CR 工具——既是标准的使用者也是实现者。
Q：Agent 编排怎么做？
答：我的框架是「分解、执行、校验」的循环。任务分解：把目标拆成可独立验证的子任务——分解质量决定成败，太粗执行不可控、太细上下文丢失。执行：每个子任务选合适的模式——确定性逻辑直接代码，生成性任务给 LLM 配工具；工具调用要有超时和预算控制。校验循环：执行结果过校验器——测试、静态检查、人工抽检——失败带反馈重试，超过重试上限升级人工，绝不让失败静默通过。成本控制贯穿：每步有 token 预算，中间结果可缓存，重复子任务复用。代码工程场景的落地形态：spec 人写——需求和边界条件是人定义的；AI 生成实现；自动 CR 加测试门禁做第一道校验；人工终审兜底——这就是 85% 采纳率背后的流水线，本质是把 Agent 循环嵌进了工程流程。
Q：私有化部署和调 API 怎么选？
答：三个决策因子。数据合规：金融、医疗、政务类数据不允许出域——直接一票决定私有化，没有权衡空间。成本：给量化框架——峰值吞吐（tokens/s）乘以单价对比 GPU 小时成本：API 按 token 计费，量大到每月账单超过「自建集群折旧加运维人力」的盈亏平衡点，私有化更划算；还要算长上下文的账——有些 provider 的长上下文单价翻倍。性能与可控性：需要微调、需要控制 TTFT、需要私有化的 Prefix Cache 策略、要求故障时自己能排查——都是私有化的理由；反过来模型迭代快、要跟着最新版本走、突发流量弹性大——API 省心。我们实际的答案是混合：核心高频场景私有化 GLM 和 DeepSeek，长尾能力和最新模型走 API——coremind 的路由层就是为这种混合策略而生的。
Q：「Java 工程师怎么和 AI 结合」？
答：我的判断是：AI 工程化的复杂度大头在服务层，而服务层正是 Java 的主场。拆开看：推理层——模型、CUDA、量化，是 Python 生态，但这层正被 vLLM 这类框架快速标准化，变成「部署运维」问题；而围绕模型的商业化基础设施——网关、鉴权计费、路由、限流、编排、可观测——全是分布式系统问题，是 Java 生态锤炼了二十年的领域。所以我的定位是「AI Infra 工程师」而不是「算法工程师」：coremind 的多租户计费是预扣实结加对账——支付系统那套；智能路由是规则引擎加熔断——微服务治理那套；语义缓存是缓存加风控——性能优化那套。AI 不是让 Java 失效，而是把 Java 的经验搬到了新赛道——这就是我这一年转型的路径，也是我应聘这个岗位的底气。