荣耀通用软件开发一面：Tob 中台架构、上传链路与 AI 工程化

《面试题目》

1. Tob 中台项目的架构细问
2. Node 如何抗住高并发？
3. 性能优化怎么做的？
4. 描述一下整体的上传管理链路
5. 平台和携程 App 的关系，是否做了小程序、App？
6. 场景题：如果大批量上传夹杂大体积视频挤爆上传，怎么处理？
7. AI 相关：平时怎么用 AI，spec 工作量是多少？
8. AI 相关的项目主要用什么模型，怎么用的？
9. 怎么避免出现大模型幻觉？
10. 输入材料堆积挤爆了上下文怎么解决？

《参考解析》

Node 抗高并发的关键是把「单线程事件循环」的边界管住。 CPU 密集逻辑（大 JSON 序列化、图片处理、加密、复杂正则）要么移到 worker_threads、要么拆成独立服务，否则会阻塞所有请求；I/O 全部异步化并配连接池（数据库、Redis、下游 HTTP），池大小要跟下游承载能力一起算。多实例部署是标配：Node 天生适合多进程（cluster 或容器多副本）+ 上层负载均衡，单机靠 SO_REUSEPORT 或 cluster 模块分摊；进程崩溃必须能快速拉起（PM2/K8s 探针 + 优雅退出）。再往上就是流控：入口限流（令牌桶按用户/IP）、请求超时与熔断、以及对下游并发做隔离（bulkhead），防止一个慢下游把所有连接占满。缓存要分层：进程内 LRU 挡热点、Redis 做共享缓存，注意缓存击穿时用单飞（singleflight）合并回源。

上传链路要讲清「直传 + 分片 + 异步处理」。 客户端向业务服务申请上传凭证（STS 临时密钥或预签名 URL），然后直传对象存储，业务服务不转发字节；大文件按 1–5MB 分片、并发上传、服务端记录分片清单以支持断点续传和合并；上传完成后由事件/消息触发异步转码（视频转码、封面抽帧、内容审核），业务库里只存对象 key 与处理状态，前端通过轮询或 WebSocket 拿到进度。上传是典型的「写放大」入口，要提前设计好带宽与存储的配额。

「大批量上传夹杂大体积视频挤爆上传」这道场景题，核心是隔离与配额，而不是扩容。 分层去答：① 入口识别：按文件类型和大小分通道（普通文档通道 vs 大文件通道），大文件走独立域名/独立网关，避免把主站带宽吃满；② 并发控制：客户端限制并发分片数，服务端对单用户/单租户设并发上传数与速率上限（令牌桶），超限排队或拒绝并返回明确的重试时间；③ 资源隔离：把转码等重活放到独立队列与独立工作池，按租户加权公平调度，防止一个大客户饿死其他用户；④ 削峰：允许客户端在业务低峰时段（或断点续传恢复后）继续上传，对非紧急任务做调度；⑤ 可观测与止损：对队列深度、带宽水位、失败率设告警与自动降级（暂停非核心任务、限流新上传）。答题时点出「挤爆」通常是共享资源被单一用户占满，所以答案一定包含配额与隔离这两个词。

避免幻觉和上下文管理，是 AI 工程题里最容易被追问的两处。 避免幻觉按三层讲：输入侧保证证据进上下文（检索不到就明确拒答）、生成侧约束（只依据材料作答、要求引用来源、结构化输出便于校验）、输出侧校验（引用核对、规则检查、必要时二次检索验证）；工程上再加一层「人可复核」的交付形态。上下文挤爆的处理：分层记忆（近期保留原文、远期压缩成结构化状态、长期记忆外置到可检索存储按需回灌）、按相关性做检索而非全量拼接、对工具返回值限长、对超长文档先摘要再选段；同时要给「上下文超限」设计明确降级路径（截断策略 + 提示模型当前上下文已截断）。最后可以用一句话收口：这几件事的共性是把模型的输入输出都当成不可信数据来处理。