服务端技术术语 & 黑话速查
面向 Web 服务端资深面试的术语手册。每个词条尽量给出：一句话定义 → 通俗解释 → 面试延伸/坑点。 本文持续更新，欢迎按需增删。最后整理：2026-08。
一、高可用与容错（High Availability & Resilience）
这是"熔断、降级、故障转移"所在的核心领域，面试出现频率最高。
| 术语 | 一句话定义 | 通俗解释 | 面试延伸 / 坑点 |
|---|---|---|---|
| 熔断（Circuit Breaker） | 下游持续失败时，主动"跳闸"快速失败，不再发起调用，过一段时间再半开试探 | 像家里的保险丝：电流过大就断开，保护整体不被拖垮 | 三态：Closed→Open→Half-Open；关键参数是失败率阈值、熔断窗口、半开探测量；对比"限流"（限流是限入口流量，熔断是断对下游的调用） |
| 降级（Degradation / Fallback） | 系统压力大或依赖不可用时，牺牲非核心功能，保证核心链路可用 | 双十一时把"猜你喜欢"关掉，保证"下单支付"能用 | 分主动降级（人工开关）/自动降级（触发条件）；降级要返回兜底数据（默认值、缓存、静态页）；和熔断常配合（熔断后走降级逻辑） |
| 限流（Rate Limiting / Throttling） | 限制单位时间内的请求量，超出部分拒绝或排队 | 景区限流，每小时只放 N 个人进去 | 算法：计数器、滑动窗口、漏桶（Leaky Bucket，恒定出速）、令牌桶（Token Bucket，允许突发）；维度：单机 vs 分布式（Redis+Lua、Sentinel） |
| 故障转移（Failover） | 主节点故障时自动切换到备用节点继续提供服务 | 主服务器倒了，备机顶上，用户几乎无感 | 涉及健康检查、选主、VIP 漂移、DNS/负载均衡切换；主备切换要防脑裂；RTO/RPO 是衡量指标 |
| 故障恢复 / 回切（Failback） | 原主节点恢复后，把流量切回去 | 保险丝修好了，重新合闸 | 回切要谨慎，避免"抖动"（反复切来切去），常需人工确认 |
| 超时（Timeout） | 调用在规定时间内没返回就放弃 | 打电话响 30 秒没人接就挂 | 最容易被忽视但最致命；连接超时 vs 读超时要分开设；超时时间要 < 上游超时（否则上游先超时，本次调用白做） |
| 重试（Retry） | 调用失败后再试几次 | 网络抖一下，重发一次往往就好了 | 必须配合幂等，否则重复下单/扣款；要加**退避（Backoff）+ 抖动（Jitter）**避免"重试风暴"；只重试可重试的错误（超时/5xx，不重试 4xx） |
| 幂等（Idempotency） | 同一操作执行一次和执行多次，结果一致 | 电梯按钮按一次和按十次，效果一样 | 实现：唯一键去重、状态机、乐观锁、去重表/Token；面试常问"如何保证接口幂等" |
| 隔离（Isolation / Bulkhead 舱壁隔离） | 把资源分区，一个模块出问题不拖垮全局 | 船体分成多个隔水舱，一个进水不会沉船 | 线程池隔离、连接池隔离、信号量隔离；典型：Hystrix 的线程池隔离 |
| 补偿（Compensation） | 操作失败后执行反向操作把状态修正回去 | 转账扣了款没到账，就把款退回去 | 分布式事务 Saga 模式的核心；对应"正向操作 + 补偿操作" |
| 兜底（Fallback Data） | 拿不到真实数据时返回一个可接受的默认结果 | 推荐系统挂了，就返回一个热门榜单 | 和降级配套；兜底数据要提前准备好（本地缓存、静态资源） |
| 自愈（Self-Healing） | 系统检测到异常后自动恢复，无需人工介入 | 容器挂了，K8s 自动重启拉起 | 健康检查 + 自动重启/重建/扩容；探活失败自动摘除 |
| 优雅停机 / 优雅上线（Graceful Shutdown/Startup） | 停服前先摘流量、处理完存量请求再退出；上线前先预热再接流量 | 下班前把手头活干完再走，别把客户晾着 | 停机：先从注册中心摘除→拒绝新请求→处理完在途请求→关闭；上线：预热（JIT、连接池、缓存）后再放流量 |
面试高频组合题："限流、熔断、降级三者的区别与配合？"
- 限流：控入口流量（我处理不过来，先挡住一部分）
- 熔断：断对下游的调用（下游坏了，我别再打它）
- 降级：保核心功能（资源不够，砍掉非核心，返回兜底）
- 配合链路：入口限流 → 调用下游超时/失败 → 触发熔断 → 熔断后走降级返回兜底。
二、流量治理与发布（Traffic & Release）
| 术语 | 一句话定义 | 通俗解释 |
|---|---|---|
| 削峰填谷 | 用队列/缓存把瞬时高峰的请求缓冲下来，平滑处理 | 洪峰来了先蓄到水库，再慢慢放水 |
| 背压 / 反压（Back Pressure） | 下游处理不过来时，向上游反向施压，让其减速 | 下水道堵了，水就往上游倒逼，让你少放水 |
| 预热（Warm Up） | 服务/缓存正式接流量前先加载数据、建立连接 | 运动前先热身，别一上来就冲刺 |
| 灰度发布 / 金丝雀（Canary） | 新版本先放给一小部分流量/用户，观察无误再全量 | 矿工带金丝雀下井，先探探有没有毒气 |
| 蓝绿部署（Blue-Green） | 准备两套环境，一套旧一套新，切流量一次性切换 | 两个舞台，观众从 A 台一下切到 B 台 |
| 滚动发布（Rolling Update） | 分批替换实例，逐步把旧版本换成新版本 | 一排灯泡一个个换，不用全关灯 |
| A/B 测试 | 同时上线多个版本，按指标对比效果 | 两版页面同时投放，看哪版转化高 |
| 流量镜像 / 影子流量（Shadow Traffic） | 把线上真实流量复制一份打到新系统，但不返回给用户 | 拿真实考题给新员工模拟考试，但不算分 |
| 切流 / 摘流 / 放量 / 上量 | 切流=引流量过去；摘流=把流量摘走；放量/上量=逐步加大流量 | 水阀的开、关、调大 |
| 回滚（Rollback） | 发现问题把版本退回上一个稳定版 | 存档读档，回到没出 bug 的状态 |
三、分布式系统理论（Distributed Systems）
| 术语 | 一句话定义 | 面试延伸 |
|---|---|---|
| CAP 定理 | 一致性(C)、可用性(A)、分区容错(P) 三者最多同时满足两个 | 网络分区必然存在(P 必选)，所以实际是在 C 和 A 之间取舍：CP（如 ZooKeeper/etcd）vs AP（如 Eureka/Cassandra） |
| BASE 理论 | Basically Available（基本可用）、Soft state（软状态）、Eventually consistent（最终一致） | CAP 中 AP 的工程实践延伸，用最终一致换高可用 |
| 强一致性 / 最终一致性 | 强：写完立刻读到最新；最终：过一会儿一定一致 | 强一致性能牺牲性能/可用性；大多数互联网系统用最终一致 |
| 线性一致性（Linearizability） | 所有操作看起来像在某个瞬间原子发生，全局有序 | 最强的一致性模型；etcd/Raft 提供 |
| 脑裂（Split-Brain） | 集群网络分区，出现多个"自认为是主"的节点 | 危害：双写冲突、数据错乱；解决：Quorum 过半、fencing token、仲裁节点 |
| Quorum（法定人数） | 读写都需要过半节点确认才算成功（W + R > N） | Paxos/Raft 的基础；防脑裂的关键 |
| Paxos / Raft | 分布式一致性（共识）算法，保证多副本对同一值达成一致 | Raft 更易懂：Leader 选举 + 日志复制 + 安全性；etcd/Consul 用 Raft |
| 2PC（两阶段提交） | 准备阶段 + 提交阶段，协调者统一决定提交或回滚 | 同步阻塞、协调者单点、有数据不一致窗口 |
| 3PC / TCC / Saga | 分布式事务方案：TCC=Try-Confirm-Cancel；Saga=一串本地事务+补偿 | TCC 侵入强、性能好；Saga 适合长事务、最终一致 |
| 分布式锁 | 跨进程/机器的互斥锁 | 实现：Redis（SET NX + 过期 + Redisson 看门狗续期）、ZooKeeper（临时顺序节点）；坑：锁误删、锁过期业务没执行完 |
| 一致性哈希（Consistent Hashing） | 节点增减时只影响相邻数据，减少大规模迁移 | 加虚拟节点解决数据倾斜；用于缓存分片、负载均衡 |
四、缓存（Cache）
| 术语 | 一句话定义 | 解决方案 |
|---|---|---|
| 缓存穿透 | 查一个根本不存在的数据，绕过缓存每次都打到 DB | 布隆过滤器拦截；缓存空值（带短过期） |
| 缓存击穿 | 某个热点 key 突然过期，瞬间大量请求打到 DB | 互斥锁重建缓存；热点 key 永不过期 / 逻辑过期 |
| 缓存雪崩 | 大量 key 同时过期 或缓存整体宕机，请求全压到 DB | 过期时间加随机抖动；多级缓存；限流降级；集群高可用 |
| 缓存一致性 | 缓存和 DB 数据如何保持一致 | Cache Aside（旁路，最常用：更新 DB 后删缓存）；延迟双删；Canal 订阅 binlog |
| 旁路缓存（Cache Aside） | 读：先读缓存，没有再读 DB 回填；写：更新 DB 后删缓存 | 最主流；先删缓存还是后删？为什么删而不是更新？是经典追问 |
| 热点 Key / 大 Key | 热点=访问集中在单个 key；大 Key=单个 value 过大 | 热点：本地缓存/多副本打散；大 Key：拆分、压缩、避免大集合 |
| 穿透/击穿/雪崩记忆口诀 | 穿透=查不存在；击穿=单点热 key 失效；雪崩=大面积失效 | 面试必背，别搞混 |
五、数据库（Database）
| 术语 | 一句话定义 | 面试延伸 |
|---|---|---|
| 读写分离 | 写走主库，读走从库 | 靠主从复制；坑：主从延迟导致刚写完读不到（读主库/强制走主） |
| 分库分表 | 数据量大时按规则拆到多个库/表 | 垂直拆（按业务）vs 水平拆（按行）；分片键选择、跨库 join/事务/分页难题 |
| 主从复制 | 主库把变更同步给从库 | MySQL 基于 binlog；异步/半同步/组复制；延迟是常见故障源 |
| MVCC（多版本并发控制） | 通过数据多版本实现读不加锁、读写不阻塞 | InnoDB 靠 undo log + ReadView 实现；面试常和隔离级别一起问 |
| 事务隔离级别 | 读未提交/读已提交/可重复读/串行化 | MySQL 默认 RR；对应解决脏读、不可重复读、幻读 |
| 脏读 / 不可重复读 / 幻读 | 脏读=读到未提交；不可重复读=两次读值不同；幻读=两次读行数不同 | RR 用间隙锁基本解决幻读 |
| 间隙锁 / 临键锁（Gap / Next-Key Lock） | 锁住索引记录之间的间隙，防止幻读 | InnoDB RR 级别的关键机制 |
| 回表 / 覆盖索引 / 索引下推 | 回表=二级索引查到主键再查聚簇索引；覆盖索引=索引直接包含所需列免回表；索引下推(ICP)=在存储引擎层先过滤 | 索引优化三件套，性能追问必备 |
| 最左前缀原则 | 联合索引从最左列开始才能命中 | (a,b,c) 索引，查 b、c 用不上 |
| 慢查询 / 执行计划（EXPLAIN） | 慢=超过阈值的查询；EXPLAIN 看优化器怎么执行 | 关注 type、key、rows、Extra（Using filesort/temporary 是坏信号） |
| 乐观锁 / 悲观锁 | 乐观=先改后校验版本(CAS/version)；悲观=先锁再改(for update) | 冲突少用乐观，冲突多用悲观 |
| WAL（预写日志） | 先写日志再写数据，保证持久性和崩溃恢复 | MySQL redo log、PG WAL 都是这个思想 |
六、消息队列（Message Queue）
| 术语 | 一句话定义 | 面试延伸 |
|---|---|---|
| 解耦 / 异步 / 削峰 | MQ 的三大作用：系统解耦、异步处理、流量削峰 | 面试"为什么用 MQ"的标准答案 |
| 消息积压 | 消费速度跟不上生产速度，消息堆积 | 排查生产/消费速率；临时扩容消费者、加分区 |
| 重复消费 | 同一消息被消费多次 | 靠消费端幂等解决（业务去重） |
| 消息丢失 | 生产、存储、消费任一环节丢消息 | 生产端 confirm/ack、存储端持久化+副本、消费端手动 ack |
| 投递语义 | at-most-once（最多一次）/ at-least-once（至少一次）/ exactly-once（恰好一次） | 大多数 MQ 保证至少一次；exactly-once 需幂等或事务配合 |
| 顺序消息 | 保证消息按发送顺序被消费 | 单分区/单队列保证；全局有序牺牲并发 |
| 死信队列（DLQ） | 消费失败/超时/超过重试次数的消息进入的特殊队列 | 用于兜底排查、人工介入 |
| 事务消息 | 保证"本地事务"与"发消息"的原子性 | RocketMQ 半消息 + 回查；解决分布式事务经典场景 |
| Backlog / Lag（消费滞后） | 消费者当前位点落后最新消息的量 | Kafka 用 consumer lag 监控积压 |
七、性能与容量（Performance & Capacity）
| 术语 | 含义 |
|---|---|
| QPS / TPS | 每秒查询数 / 每秒事务数（TPS 通常含多步、更重） |
| RT（Response Time） | 响应时间/耗时 |
| P99 / P95 / P50（分位延迟） | 99%/95%/50% 的请求耗时低于该值；P99 反映"长尾"体验，比平均值更有意义 |
| 长尾延迟（Long Tail） | 少数请求异常慢，拉高 P99 |
| 吞吐量（Throughput） | 单位时间处理的请求/数据量 |
| 并发 / 并行 | 并发=交替处理多任务；并行=同时真正一起跑 |
| 水位（Water Level） | 资源使用率（CPU/内存/连接数）相对容量的位置 |
| 压测 / 基准测试（Benchmark） | 用工具模拟高负载测系统上限 |
| 容量规划（Capacity Planning） | 根据业务量预估并准备资源 |
| C10K / C10M 问题 | 单机支撑 1 万 / 1 千万并发连接的挑战 |
八、高并发连接（C10K 家族）
面试问"单机能扛多少连接""长连接怎么做"时的核心知识点，和第九章"网络与 IO"强相关。
C10K = Concurrent 10,000 connections：单台服务器如何同时处理 1 万个并发连接（1999 年 Dan Kegel 提出）。 核心矛盾：传统"一个连接一个线程/进程"模型下，1 万连接就要 1 万线程，线程栈内存 + 上下文切换开销直接压垮机器。 解法主线：阻塞 IO + 每连接一线程 → IO 多路复用 + 事件驱动（Reactor）。
| 术语 | 含义 | 难点 / 解法 |
|---|---|---|
| C10K | 单机 1 万并发连接 | 抛弃每连接一线程，改用 epoll/事件驱动 |
| C100K / C1M | 十万 / 百万级长连接 | IM、消息推送、直播弹幕的典型场景 |
| C10M | 单机 1 千万并发连接 | 光靠 epoll 不够，需内核旁路（Kernel Bypass）：DPDK、用户态协议栈、多队列网卡、CPU 亲和/绑核、无锁数据结构 |
| select / poll / epoll | IO 多路复用的三代演进 | select/poll 是 O(n) 轮询、有 fd 上限；epoll 回调就绪、O(1)、无上限；BSD 对应 kqueue |
| epoll LT / ET | 水平触发 / 边缘触发 | LT：没读完会一直通知（好写不易漏）；ET：只通知一次，必须一次读干净（性能高、易漏事件） |
| 惊群效应（Thundering Herd） | 一个连接到来唤醒所有阻塞的进程/线程，只有一个能处理，其余空忙 | Nginx 用 accept_mutex、Linux 用 EPOLLEXCLUSIVE / SO_REUSEPORT 解决 |
| 文件描述符（fd）限制 | 每个连接占一个 fd | 调 ulimit -n（进程级）、fs.file-max（系统级） |
| 端口耗尽 | 作为客户端发起大量连接时，本地端口（约 6 万）不够用 | 多 IP、扩端口范围、复用连接 |
| TIME_WAIT 堆积 | 主动关闭方大量连接卡在 TIME_WAIT | SO_REUSEADDR、长连接复用、tcp_tw_reuse |
九、架构模式（Architecture Patterns）
| 术语 | 一句话定义 |
|---|---|
| 微服务（Microservices） | 按业务拆成一堆小而自治、独立部署的服务 |
| 服务网格（Service Mesh） | 用 Sidecar 代理接管服务间通信（流量/安全/observability），业务无侵入。代表：Istio |
| Sidecar（边车） | 与主应用一起部署的辅助进程，处理通用能力（如 Envoy 代理） |
| API 网关（Gateway） | 所有请求的统一入口，做鉴权、限流、路由、聚合 |
| BFF（Backend For Frontend） | 为不同前端（App/Web）定制的后端聚合层 |
| DDD（领域驱动设计） | 以业务领域为核心建模：限界上下文、聚合根、实体、值对象 |
| CQRS | 命令（写）和查询（读）用不同模型/存储分离 |
| 事件溯源（Event Sourcing） | 不存最终状态，而存一连串事件，状态由事件回放得出 |
| 无状态 / 有状态 | 无状态：请求不依赖本机内存，可任意水平扩展；有状态：需固定会话/存储 |
| SOA | 面向服务架构，微服务的"前身"，更重（ESB 总线） |
十、网络与 IO（Network & IO）
| 术语 | 一句话定义 |
|---|---|
| 长连接 / 短连接 | 长：一次连接复用多次请求；短：一次请求一次连接 |
| 心跳（Heartbeat） | 定期发小包探测连接是否存活 |
| 粘包 / 拆包 | TCP 是流，没有消息边界，需自己分包（长度前缀/分隔符） |
| 连接池 | 复用连接，避免频繁建连开销 |
| IO 多路复用 | 一个线程用 select/poll/epoll 管理大量连接 |
| Reactor / Proactor | 事件驱动网络模型；Netty 是 Reactor 的典型实现 |
| 零拷贝（Zero-Copy） | 数据传输避免内核态/用户态多次拷贝（sendfile、mmap） |
| TCP 三次握手 / 四次挥手 | 建连三次、断连四次；面试常问 TIME_WAIT、半连接队列 |
| 粘性会话 / 会话保持（Sticky Session） | 同一用户请求固定路由到同一台机器 |
十一、并发编程（Concurrency）
| 术语 | 一句话定义 |
|---|---|
| CAS（比较并交换） | 无锁原子操作：期望值匹配才更新，是乐观锁基础 |
| ABA 问题 | 值从 A→B→A，CAS 察觉不到中间变化 |
| 自旋锁 | 拿不到锁不睡眠，循环重试 |
| 死锁 / 活锁 / 饥饿 | 死锁=互相等待卡死；活锁=一直重试却无进展；饥饿=某线程长期抢不到资源 |
| 可重入锁 | 同一线程可重复获取同一把锁 |
| 读写锁 | 读读共享、读写/写写互斥 |
| 协程（Coroutine） | 用户态轻量线程，切换成本极低（Go goroutine、Java 虚拟线程） |
| 线程池 | 复用线程，控制并发数（核心/最大线程、队列、拒绝策略） |
| 内存屏障 / 可见性 / 指令重排 | 并发下的可见性与有序性问题（Java volatile、happens-before） |
十二、可观测性与稳定性（Observability & SRE）
| 术语 | 一句话定义 |
|---|---|
| 可观测性三支柱 | Metrics（指标）、Logging（日志）、Tracing（链路追踪） |
| 链路追踪（Distributed Tracing） | 用 TraceID 串起一次请求经过的所有服务 |
| 埋点 / 打点 | 在代码里插入统计/日志上报点 |
| SLA / SLO / SLI | SLA=对外承诺；SLO=内部目标；SLI=实际度量指标（如可用性 99.99%） |
| 错误预算（Error Budget） | 允许的不可用额度（1 - SLO），用完就停止上新功能 |
| 告警（Alerting） | 指标越过阈值时通知；要防"告警风暴"和"狼来了" |
| 混沌工程（Chaos Engineering） | 主动注入故障（杀节点、断网、延迟）验证系统韧性 |
| 健康检查 / 探活 | Liveness（活着吗，不行就重启）、Readiness（能接流量吗） |
| 全链路压测 | 在生产（或影子库）对整条链路施压，找真实瓶颈 |
| 复盘 / 事故复盘（Postmortem） | 事故后回顾原因、影响、改进项，对事不对人 |
以下按主题补充运维 / SRE 高频黑话（值班、故障、容灾、监控里最常听到）。
稳定性指标类
| 术语 | 一句话定义 | 面试延伸 / 坑点 |
|---|---|---|
| QoS（服务质量） | 对不同流量分级保障，优先满足高优先级请求的带宽/时延/丢包 | 常和限流分级、优先级队列、TC 流量整形一起谈；核心是"资源紧张时先保谁" |
| 可用性 N 个 9 | 用几个 9 表达可用性：4 个 9=99.99%（年不可用约 52 分钟）、5 个 9≈5 分钟 | 每多一个 9 成本指数级上升；要会换算年/月停机时长 |
| 毛刺（Spike / Glitch） | 指标曲线上偶发的尖峰突起（延迟/错误率瞬间飙高又回落） | 常由 GC、慢查询、缓存失效、网络抖动引起；拉高 P99，比均值更该关注 |
| 抖动（Jitter） | 延迟忽高忽低、不稳定 | 网络抖动、调度抖动；重试要加 Jitter 打散，避免重试风暴对齐 |
| 长尾（Long Tail） | 少数请求特别慢，拖垮 P99/P999 | 慢节点、冷数据、锁竞争；对冲请求（Hedged Request）可缓解 |
| 基线（Baseline） | 正常状态下的指标参考水平 | 告警阈值、异常检测都基于基线；节假日/大促要动态基线 |
| 水位 / 水位线（Water Level） | 资源使用率相对容量的位置 | 常设"警戒水位"触发扩容/限流；容量规划的核心概念 |
| RTO / RPO | RTO=故障后多久恢复服务；RPO=最多能丢多少数据 | 容灾核心指标；RPO=0 需同步复制，代价高 |
| MTBF / MTTR / MTTF | 平均无故障时间 / 平均修复时间 / 平均失效前时间 | 稳定性 = 少出故障(MTBF↑) + 快速恢复(MTTR↓) |
容灾 / 高可用类
| 术语 | 一句话定义 | 面试延伸 / 坑点 |
|---|---|---|
| 容灾（Disaster Recovery） | 机房/区域级故障时仍能恢复服务的能力 | 对应 RTO/RPO；分冷备、热备、多活等级别 |
| 同城双活 / 异地多活 | 多个机房同时对外提供服务、互为备份 | 异地多活难在跨地域数据一致性与延迟；单元化是主流解法 |
| 冷备 / 温备 / 热备 | 冷=平时不运行需拉起；温=运行但不接流量；热=实时同步随时切 | 越热恢复越快、成本越高 |
| 主备 / 主从切换 | 主故障时切到备/从继续服务 | 切换要防脑裂、防抖动；配合 RTO 衡量 |
| 单点故障（SPOF） | 某个组件挂了整个系统就不可用 | 高可用设计首要消除 SPOF：冗余、集群、无状态 |
| 爆炸半径（Blast Radius） | 一次故障波及的影响范围 | 通过隔离、单元化、限流把爆炸半径控制到最小 |
| 故障演练 / 预案演练 | 主动模拟故障，验证应急预案和恢复流程 | 混沌工程的一种；"平时多流汗，战时少流血" |
| 止损 | 故障发生后先快速把损失止住（如切流、降级、回滚），再定位根因 | 应急第一优先级是止损而非查因 |
监控 / 告警 / 值班类
| 术语 | 一句话定义 | 面试延伸 / 坑点 |
|---|---|---|
| 大盘 / 看板（Dashboard） | 把核心指标汇总成一屏可视化监控页 | 分业务大盘、系统大盘；值班第一眼看的东西 |
| 黑盒 / 白盒监控 | 黑盒=从外部像用户一样探测；白盒=从内部暴露指标 | 拨测属黑盒；Prometheus 埋点属白盒 |
| 拨测 / 探针（Probe / Dial Test） | 主动定时发请求探测服务是否正常 | 多地拨测发现地域性故障；探针≠健康检查 |
| 采样率（Sampling Rate） | 只采集一部分数据以降低开销 | 全量 Trace 成本高，常按比例采样；采样过低会漏关键链路 |
| 告警风暴 / 告警疲劳 | 短时间大量告警刷屏，或告警太多被麻木忽略 | 靠告警收敛、分级、抑制、根因聚合解决 |
| 根因分析（RCA） | 定位故障的根本原因而非表象 | Root Cause Analysis；复盘核心产出，配 5 Why |
| On-Call / 值班 | 轮班待命，负责第一时间响应线上告警 | 关注响应时长 SLA、升级机制（Escalation） |
| 工单 / 升级（Escalation） | 问题按级别流转、逐级上报给更高权限/更资深的人 | 处理不了要及时升级，别自己硬扛耽误止损 |
| 巡检 | 定期检查系统健康状况，提前发现隐患 | 分人工巡检和自动巡检；防患于未然 |
| 冒烟测试（Smoke Test） | 上线后跑一组最基本用例，快速确认核心功能没崩 | 发布后第一道验证；不通过立即回滚 |
十三、安全（Security）
| 术语 | 一句话定义 |
|---|---|
| 认证 vs 鉴权（AuthN vs AuthZ） | 认证=你是谁；鉴权=你能干什么 |
| 越权（水平/垂直） | 水平=访问同级别他人数据；垂直=访问更高权限功能 |
| 防重放（Anti-Replay） | 防止请求被截获后重复发送（nonce + timestamp + 签名） |
| XSS / CSRF / SQL 注入 | 前端脚本注入 / 跨站请求伪造 / SQL 拼接注入，Web 三大经典漏洞 |
| 加密 vs 签名 vs 加签验签 | 加密保机密；签名保完整性和不可否认；对称/非对称 |
| 脱敏（Data Masking） | 敏感数据展示/存储时打码处理（手机号中间四位星号） |
十四、互联网"黑话"口语速查
这些不是严格技术术语，但会议/评审里高频出现，听不懂容易懵。
| 黑话 | 实际意思 |
|---|---|
| 抓手 | 切入点、着力点、能落地推进的方法 |
| 拉齐 / 对齐 | 让大家信息一致、达成共识 |
| 闭环 | 事情有始有终、形成完整循环，别烂尾 |
| 赋能 | 给别人（团队/业务）提供能力支持 |
| 复盘 | 事后回顾总结经验 |
| 链路 / 全链路 | 一次请求/一个业务从头到尾经过的所有环节 |
| 串联 / 打通 | 把分散的系统/流程连起来 |
| 透传 | 参数/数据原样往下传，不做处理 |
| 下钻（Drill Down） | 从汇总数据往下看更细的明细 |
| 水位 | 资源/负载的当前占用程度 |
| 洗数据 / 刷数据 | 批量修正、清理、回填历史数据 |
| 上量 / 放量 | 逐步增大流量或业务规模 |
| 切流 / 摘流 | 把流量切过去 / 摘走 |
| 埋点 | 插入数据采集点 |
| 踩坑 / 埋雷 | 遇到隐蔽问题 / 留下隐患 |
| 兜底 | 出问题时的最后保障方案 |
| 收敛 | 把发散的问题/方案收拢到可控范围 |
| 颗粒度 | 粗细程度（如"监控颗粒度更细"） |
| 心智 | 用户认知 / 也指"心智负担=理解成本" |
| 对齐颗粒度 | 让大家对"做到多细"达成一致 |
以下按主题补充大厂高频职场黑话（战略汇报、周会、OKR、评审里最常听到）。
战略 / 方向类
| 黑话 | 实际意思 |
|---|---|
| 顶层设计 / 顶设 | 先从全局高处把方向、框架定下来，再往下拆 |
| 打法 | 做一件事的整体策略和方式（"换个打法"） |
| 组合拳 | 多种手段配合一起上，不是单点发力 |
| 赛道 | 所处的行业细分领域（"押注这条赛道"） |
| 卡位 / 卡身位 | 提前占据有利位置/资源，抢占先机 |
| 终局 / 终局思维 | 从最终格局倒推现在该怎么做 |
| 第一性原理 | 回到最本质的原理重新推导，而非照搬经验 |
| 护城河 / 壁垒 | 竞争对手难以逾越的优势（技术/规模/生态） |
| 抢占心智 | 在用户认知里占据位置（"提到 X 就想到我们"） |
| 势能 / 动能 | 势能=积累的有利态势；动能=当前推进的力量 |
| 破圈 / 出圈 | 突破原有用户群，被更广人群知道 |
| 长期主义 | 着眼长远价值，不追短期数字 |
落地 / 执行类
| 黑话 | 实际意思 |
|---|---|
| 落地 | 把方案/想法真正实施到位、见到结果（最高频） |
| 拆解 | 把大目标层层分解成可执行的小任务 |
| 对标 | 找一个参照对象来比较（"对标行业标杆"） |
| 打样 / 打样板 | 先做一个成功样板，再复制推广 |
| 跑通 | 整个流程能顺利走完一遍（"先把链路跑通"） |
| 沉淀 | 把经验/能力/数据积累成可复用的资产 |
| 复用 | 已有成果拿来重复使用，不重复造轮子 |
| 收口 | 把发散的方案/问题收拢定下来（同"收敛"） |
| 卡点 / 卡脖子 | 阻碍推进的关键堵点 / 被人掐住的要害 |
| 抓大放小 | 集中精力抓重点，次要的先放一放 |
| 降本增效 / 提效 | 降低成本、提高效率（汇报万能词） |
| 小步快跑 / 快速迭代 | 先上最小可用版本，边跑边改进 |
| 飞轮 / 飞轮效应 | 各环节正向促进、越转越快、自我强化 |
沟通 / 协作类
| 黑话 | 实际意思 |
|---|---|
| 拉通 | 跨团队把信息/目标对齐打通（比"对齐"更强调跨部门） |
| 同频 | 大家节奏/认知在同一频道上 |
| 周知 / 知会 / cc 一下 | 把信息同步给相关人，让其知晓 |
| 背书 / 站台 | 用自己的信誉为某事/某人担保、公开支持 |
| 反哺 | 把产出反过来支持上游/母体 |
| 拍板 / 拍脑袋 | 拍板=最终定夺；拍脑袋=没依据凭感觉决定 |
| 对焦 | 把讨论聚焦到关键问题上 |
| 抓手 | 能撬动全局、可落地推进的切入点（战略+执行都用） |
增长 / 运营类
| 黑话 | 实际意思 |
|---|---|
| 拉新 / 促活 / 留存 / 转化 / 变现 | 用户增长五段（AARRR 的中文说法） |
| 漏斗 | 用户从进入到转化逐层流失的模型 |
| 北极星指标 | 当前阶段最核心的唯一衡量指标 |
| 私域 / 公域 | 私域=自己可反复触达的用户池；公域=平台大流量 |
| 触达 / 触点 | 触达=把信息送到用户；触点=与用户接触的环节 |
| 曝光 / 露出 / 资源位 / 坑位 | 曝光=被看到；资源位/坑位=页面上的展示位置 |
| 用户画像 / 打标签 / 千人千面 | 给用户建标签，按标签做个性化推送 |
| 盘活存量 | 激活已有但沉睡的用户/资源 |
| 人效 / 坪效 / ROI / 投产比 | 单位投入产出的效率衡量 |
效应 / 规律类（汇报里显专业）
| 黑话 | 实际意思 |
|---|---|
| 马太效应 | 强者越强、弱者越弱，头部通吃 |
| 木桶效应 / 短板 | 整体上限取决于最短那块板 |
| 二八法则 | 80% 的结果由 20% 的关键因素决定 |
| 网络效应 | 用的人越多，产品对每个人越有价值 |
| 规模效应 | 规模越大，单位成本越低 |
| 协同效应 / 1+1>2 | 组合起来的价值大于各部分之和 |
| 长尾效应 | 大量小众需求累加起来不可忽视 |
十五、大模型基础（LLM Fundamentals）
做 Agent/RAG 前的地基词汇，面试官常从这里往深处问。
| 术语 | 一句话定义 | 面试延伸 / 坑点 |
|---|---|---|
| Token（词元） | 模型处理文本的最小单位，一段文字先被分词器切成 token | 计费、上下文长度都按 token 算；中文约 1 字 ≈ 1~2 token，英文 1 词 ≈ 1.3 token |
| 上下文窗口（Context Window） | 模型一次能"看到"的最大 token 数（输入+输出） | 超出就要截断/压缩；窗口大 ≠ 有效利用好（见"上下文腐化"） |
| 参数量（Parameters） | 模型权重的数量，如 7B、70B | 越大越强但越贵越慢；面试常问"为什么不无脑上大模型" |
| 温度 / Top-p / Top-k（采样参数） | 控制输出随机性：温度越高越发散；Top-p 核采样按累积概率截断；Top-k 只从前 k 个候选采样 | 确定性任务调低温度（0~0.3），创意任务调高；同时调 T 和 top-p 要小心 |
| 幻觉（Hallucination） | 模型一本正经地编造不存在的事实 | 根因：概率生成 + 知识缺失；缓解：RAG 注入事实、要求引用出处、降低温度、让模型"不知道就说不知道" |
| In-Context Learning（上下文学习） | 不改权重，仅靠 prompt 里给的示例就学会任务 | Zero-shot（不给例）/ Few-shot（给几个例）/ One-shot |
| 思维链（CoT, Chain-of-Thought） | 让模型"一步步想"，显式输出推理过程再给答案 | 显著提升推理题正确率；衍生：Self-Consistency（多次采样投票）、ToT（思维树） |
| 预训练 / 微调（Pretrain / Fine-tune） | 预训练=海量语料学通用能力；微调=在特定数据上再训练适配任务 | SFT（监督微调）、LoRA（低秩适配，只训练小部分参数省显存） |
| RLHF / DPO（对齐训练） | 用人类偏好训练模型，让输出更符合人类期望 | RLHF=奖励模型+强化学习；DPO 更简单直接用偏好数据；解决"对齐（Alignment）"问题 |
| MoE（混合专家） | 模型由多个"专家"子网络组成，每次只激活一部分 | 参数量大但推理只激活少数专家，省算力（如 DeepSeek、Mixtral） |
| 量化 / 蒸馏（Quantization / Distillation） | 量化=用低精度（INT8/INT4）压缩模型；蒸馏=用大模型教小模型 | 都为降本提速、端侧部署；量化会损失一点精度 |
| KV Cache | 推理时缓存已算过的 Key/Value，避免重复计算 | 长文本推理省算力的关键；但吃显存，是长上下文的成本瓶颈 |
| Prefill / Decode（预填充/解码） | Prefill=并行处理输入 prompt；Decode=逐 token 生成输出 | 对应两个延迟指标：TTFT（首 token 延迟，受 prefill 影响）、TPOT（每 token 生成间隔） |
| 困惑度（Perplexity） | 衡量模型对文本预测的"意外程度"，越低越好 | 语言模型评测的经典指标 |
AI 能力与质量属性类
这些词描述的不是"模型有多大"，而是模型在真实服务里是否稳定、可信、可控。面试时要把它们和准确率、延迟、成本等指标一起谈。
| 术语 | 一句话定义 | 通俗解释 | 面试延伸 / 坑点 |
|---|---|---|---|
| 鲁棒性（Robustness） | 输入存在噪声、改写、格式变化或边界情况时，模型仍能保持可接受表现的能力 | 同一个问题换种说法、夹几个错别字，模型也不至于答非所问 | 鲁棒性不等于准确率；要用扰动集、对抗样本、极端输入做专项测试，并配合输入校验、降级和拒答 |
| 泛化能力（Generalization） | 在训练数据之外的未见样本、场景上仍能正确工作的能力 | 没见过这道原题，也能用学到的方法解决同类新题 | 训练集高分不代表泛化好；要区分过拟合，使用跨领域、时间切分和私有测试集验证 |
| 可控性 / 可引导性（Controllability / Steerability） | 模型能否稳定遵循指令、格式和业务约束输出 | 让它输出 JSON，它就按 schema 输出；让它只调用白名单工具，它不会乱来 | 依赖 system prompt、结构化输出、函数参数校验、护栏和微调；提示词本身不是安全边界 |
| 可解释性（Interpretability / Explainability） | 能否说明模型为何给出某个结果，以及依据了哪些信息 | 不只告诉你答案，还能指出引用的文档、关键证据和决策路径 | 模型生成的"解释"不一定是真实原因；生产上优先保留引用、检索片段、工具轨迹和可审计日志 |
| 校准性（Calibration） | 模型给出的置信度与实际正确概率相匹配的程度 | 说"我有 80% 把握"的 10 次里，最好大约有 8 次答对 | 自报 confidence 不等于可靠概率；可用可靠性曲线、ECE/Brier Score 评估，并设置低置信度转人工或检索 |
| 事实性（Factuality） | 输出陈述在客观世界中是否真实、可验证 | 答案里的日期、数字、人物关系不能凭空编 | 与 RAG 的**忠实度（Faithfulness）**不同：事实性看是否真实，忠实度看是否忠于给定材料；需引用、校验或外部工具核实 |
| 一致性（Consistency） | 对相同或语义等价的输入，多次生成结果在结论和格式上保持稳定 | 同一个问题问三遍，不能每次结论都变 | 温度设为 0 也不保证完全确定；可用多次采样、一致性投票、规则校验和固定版本降低波动 |
| 可复现性（Reproducibility） | 在模型版本、提示词、参数、随机种子和运行环境相同的条件下复现结果的能力 | 昨天能跑通的评测，今天用同一套配置还能得到近似结果 | API 模型会更新，服务端可能存在非确定性；应记录 prompt、模型版本、seed、工具结果和评测数据版本 |
| 分布外（OOD, Out-of-Distribution） | 线上输入与训练/评测数据分布明显不同的情况 | 用法律问答模型去回答医学急救，属于没见过的领域 | OOD 下模型可能高置信度胡说；可做领域识别、异常检测、路由到专用模型或直接拒答 |
| 数据漂移（Data Drift） | 线上输入数据的分布随时间变化，导致模型效果衰退 | 用户用词、业务规则或商品类型变了，模型还是按旧世界理解 | 监控输入统计、Embedding 分布、命中率和线上反馈；定期回流样本评测、微调或更新知识库 |
| 对抗样本（Adversarial Example） | 为诱导模型产生错误结果而刻意构造的输入 | 在文本里加入特殊指令或细微扰动，让模型绕过原本的判断 | 关注对抗鲁棒性、提示注入和越狱；防护要做输入隔离、权限最小化、输出校验，不能只靠一句 system prompt |
| 越狱（Jailbreak） | 通过提示技巧绕过模型安全策略，诱导其执行受限行为 | 模型本来不该回答，换个角色扮演或多轮套话后却答了 | 属于安全评测的一部分；用红队样本、策略分类器、工具权限隔离和人工审核构建纵深防御 |
| 拒答 / 弃答（Refusal / Abstention） | 模型在风险过高、信息不足或超出能力边界时主动不作答 | 不确定时说"我不知道"，而不是编一个答案 | 要平衡漏拒答（该拒不拒）和误拒答（正常问题也拒）；结合置信度、检索、人工兜底设定策略 |
十六、上下文工程（Context Engineering）
Agent 面试的核心新战场。模型能力再强，喂进去的上下文烂，结果照样烂。这一章是你提到的"上下文腐化/溢出/噪声"所在。
| 术语 | 一句话定义 | 面试延伸 / 坑点 |
|---|---|---|
| 上下文工程（Context Engineering） | 系统性地决定"往上下文窗口里放什么、怎么放、放多少"，让模型在正确的信息下工作 | 被认为是比"提示工程"更上位的能力；Agent 时代的核心工程学 |
| 上下文腐化（Context Rot） | 随着上下文变长，模型对其中信息的利用质量逐渐下降，即使没超窗口 | 关键认知：上下文越长≠效果越好；有效上下文有限，无关内容会稀释注意力；解法：只放相关信息、及时压缩/裁剪 |
| 上下文溢出（Context Overflow） | 塞入的内容超过上下文窗口上限，超出部分被截断丢弃 | 表现为"前面说的忘了"；解法：滑动窗口、摘要压缩、外部记忆、检索按需注入 |
| 噪声（Noise） | 上下文里与当前任务无关/低质/重复的信息 | 会干扰模型判断、放大幻觉；RAG 召回不精、工具返回大 JSON 都会引入噪声；解法：重排、过滤、精简工具输出 |
| 中间遗失（Lost in the Middle） | 模型对长上下文开头和结尾记得牢，中间的信息容易被忽略 | 经典实验结论；实践：把最重要的信息放在开头或结尾，别埋在中间 |
| 大海捞针（Needle in a Haystack） | 测试模型能否从超长上下文里精确捞出某条关键信息的评测方法 | 衡量长上下文"真实有效长度"的标准测试 |
| 上下文污染（Context Poisoning） | 错误/幻觉信息一旦进入上下文，被后续步骤反复引用、越滚越错 | Agent 多轮里尤其致命；解法：验证中间结果、隔离不可信来源 |
| 上下文冲突 / 干扰（Context Clash / Distraction） | 上下文里出现互相矛盾的信息，或无关信息把模型带偏 | 多来源检索、长对话历史累积时常见 |
| 上下文压缩 / 裁剪（Compression / Pruning） | 通过摘要、去重、筛选把上下文缩短，保留高价值信息 | 手段：对话历史摘要、只保留最近 N 轮、按相关性打分裁剪 |
| 记忆（Memory：短期 / 长期） | 短期=当前会话上下文；长期=跨会话持久化的信息（存向量库/DB 按需取回） | Agent 突破上下文窗口限制的关键；长期记忆本质是"外挂的检索" |
| 提示注入（Prompt Injection） | 恶意输入伪装成指令，劫持模型行为 | Agent 安全头号威胁；分直接注入和间接注入（藏在检索到的网页/文档里）；解法：输入隔离、权限最小化、输出校验 |
十七、Agent 工程（Agent Engineering）
| 术语 | 一句话定义 | 面试延伸 / 坑点 |
|---|---|---|
| Agent（智能体） | 能自主"感知→规划→调用工具→行动→观察→再决策"循环完成任务的系统 | 对比：Workflow 是写死的流程，Agent 是模型自己决定下一步 |
| ReAct | Reasoning + Acting：让模型交替"推理(Thought)→行动(Action)→观察(Observation)"直到完成 | 最经典的 Agent 范式；面试常让你手写这个循环 |
| 工具调用 / Function Calling（Tool Use） | 模型按结构化格式输出要调用的函数名和参数，由外部执行后把结果喂回 | Agent 的手脚；坑：工具描述要清晰、参数要校验、工具返回别太长（引噪声） |
| MCP（Model Context Protocol） | 标准化模型与外部工具/数据源连接的协议 | 让工具/数据接入即插即用，避免每个应用重复造轮子 |
| 规划（Planning） | 把复杂任务拆解成子任务并排序执行 | 方式：一次性规划 vs 边做边规划（ReAct）；Plan-and-Execute 模式 |
| 反思 / 自我批判（Reflection / Self-Critique） | 让模型审视自己的输出并修正 | 提升质量的常用手段；代表：Reflexion；代价是多花 token 和延迟 |
| 多智能体（Multi-Agent） | 多个各司其职的 Agent 协作（如规划者/执行者/审查者） | 编排（Orchestration）方式：主从、辩论、流水线；坑：通信成本高、易发散、难调试 |
| Agentic Workflow | 介于固定 Workflow 和全自主 Agent 之间：用模型增强但流程仍有骨架 | 生产实践更偏这一档，可控性和效果的平衡 |
| 护栏（Guardrails） | 对 Agent 输入输出加约束，防越界、防有害、防跑飞 | 输入校验、输出格式约束、敏感操作人工确认 |
| 人在环路（Human-in-the-Loop, HITL） | 关键步骤（如付款、删除）暂停等人工确认 | 高风险 Agent 的必备安全阀 |
| Harness（智能体框架/骨架） | 包裹模型、管理循环/工具/上下文/记忆的运行时脚手架 | 决定 Agent 上限的往往是 harness 工程，而非模型本身 |
| Token 预算 / 成本失控 | Agent 多轮循环 token 消耗指数级增长 | 面试高频"怎么控制 Agent 成本"：限制轮数、压缩上下文、缓存、小模型分流 |
| 死循环 / 兜圈子（Looping） | Agent 反复调同一工具或在两个状态间打转，不收敛 | 解法：最大步数限制、循环检测、强制反思、超时熔断 |
| 评测（Agent Eval） | 衡量 Agent 端到端任务完成率、工具调用准确率等 | 比传统模型评测难，常需轨迹级(trajectory)评估 + LLM-as-Judge |
十八、RAG（检索增强生成）
Retrieval-Augmented Generation：先检索相关知识，再让模型基于检索结果作答，解决幻觉和知识时效问题。
| 术语 | 一句话定义 | 面试延伸 / 坑点 |
|---|---|---|
| RAG | 检索外部知识拼进 prompt，让模型"开卷考试"再作答 | 对比微调：RAG 改数据不改模型、可溯源、实时更新；标准流程：切块→向量化→检索→重排→组装→生成 |
| Embedding（向量嵌入） | 把文本映射成一串数字向量，语义相近的向量距离也近 | 检索的基础；不同 embedding 模型效果差异大；中文要选对模型 |
| 向量数据库（Vector DB） | 专门存储和检索高维向量的数据库 | Milvus、Qdrant、pgvector；靠 ANN（近似最近邻，如 HNSW）索引加速 |
| 分块（Chunking） | 把长文档切成小片段再向量化 | 核心权衡：块太大引噪声、块太小丢上下文；策略：定长/按语义/按结构，常配重叠(overlap) |
| 召回（Recall / Retrieval） | 从知识库里粗筛出一批候选片段 | 指标：召回率；召回不全 = 后面全白搭 |
| 重排（Rerank） | 对召回结果用更精细的模型重新打分排序，取 Top-K | 召回重"广"、重排重"准"；Cross-Encoder 重排质量高但慢 |
| 混合检索（Hybrid Search） | 语义检索（向量）+ 关键词检索（BM25）结合 | 向量擅长语义、BM25 擅长精确词/专有名词；两者互补，是实践标配 |
| 语义检索 vs 关键词检索（BM25） | 语义=按含义匹配；BM25=按词频精确匹配 | 纯语义会漏专有名词/编号，纯关键词理解不了同义改写 |
| 查询改写 / HyDE | 改写用户问题以提升检索命中；HyDE=先让模型假想一个答案再拿它去检索 | 解决"问题和文档表述不一致"；也有查询扩展、多查询融合 |
| 上下文组装（Context Assembly） | 把重排后的片段按顺序拼进 prompt | 注意"中间遗失"、控制总长防溢出、保留出处 |
| Agentic RAG | 让 Agent 自主决定"要不要检索、检索什么、检索几轮" | 对比标准 RAG 的固定一次检索；能处理多跳问题，但更慢更贵 |
| GraphRAG | 基于知识图谱的 RAG，利用实体关系做多跳推理 | 适合需要跨文档关联、全局理解的问题 |
| RAG 评测 | 衡量检索质量（命中/相关性）和生成质量（忠实度/相关性） | 框架：RAGAS；关键指标 Faithfulness（答案是否忠于检索内容，防幻觉）、Context Precision/Recall |
检索与嵌入进阶
| 术语 | 一句话定义 | 面试延伸 / 坑点 |
|---|---|---|
| 稠密嵌入（Dense Embedding） | 神经网络把文本编码成低维稠密向量（每维都有值），按语义相似度检索 | 双塔模型产出；擅长语义 / 同义改写，弱在精确术语；上文的 Embedding 就是稠密向量 |
| 稀疏嵌入（Sparse Embedding） | 高维稀疏向量（大部分为 0），每维对应一个词，本质是词权重 | BM25 是经典无监督稀疏；学习式稀疏如 SPLADE 能做同义扩展，兼顾精确与语义 |
| BM25（算法细节） | TF（词频）× IDF（逆文档频率）并按文档长度归一化的打分算法 | 稀疏检索代表；擅长专名 / 编号 / 精确词；ES / Lucene 默认打分；可调 k1、b 参数 |
| RRF（倒数排名融合） | 把稠密和稀疏两路结果按名次倒数加权融合成一个榜 | Reciprocal Rank Fusion；只看排名不看原始分、简单鲁棒；混合检索最常用的融合法 |
| ANN / HNSW / IVF（近似最近邻索引） | 用近似算法在海量向量里快速找 Top-K，牺牲一点精度换速度 | HNSW=分层图、快但吃内存；IVF=倒排聚类、省内存；PQ 做向量量化压缩 |
| 双塔 / Bi-Encoder（召回用） | Query 和 Doc 各自独立编码，Doc 向量可离线预存 | 快、可规模化；精度不如 Cross-Encoder；负责"广撒网"召回 |
| Cross-Encoder（重排用） | Query 和 Doc 拼在一起过模型直接算相关性分 | 精度高但每对都要现算、慢；只用于重排 Top-N，不做全库召回 |
| ColBERT / 多向量检索 | 每个 token 一个向量、做后期交互（late interaction）细粒度匹配 | 精度接近 Cross-Encoder、速度快很多；召回与重排的折中 |
| 父子分块 / Small-to-Big | 用小块精准命中检索，喂模型时替换成信息更全的父块 | 兼顾检索精度和生成上下文完整；对应 ParentDocumentRetriever |
| 上下文压缩（Contextual Compression） | 检索后再过滤 / 抽取，只保留与问题相关的句子 | 降噪、省 token、缓解中间遗失；可用小模型或规则实现 |
十九、Vibe Coding 与规格驱动开发（SDD）
2025 年最火的 AI 编程新范式方向。面试官会用这些词判断你是否跟得上 AI 工程化的最新实践。
编码范式类
| 术语 | 一句话定义 | 面试延伸 / 坑点 |
|---|---|---|
| Vibe Coding（氛围编程） | 用自然语言描述需求，让 AI 直接生成代码，人主要负责引导/测试/反馈而非手写 | Karpathy 2025.2 提出；精髓"最热的新编程语言是英语"；坑：不审代码直接用，埋 bug 和安全洞 |
| SDD（规格驱动开发，Spec-Driven Development） | 先写清晰规格(spec)，让规格变成"可执行"的源头，再由 AI 据此生成实现 | 对 Vibe Coding 的纠偏：把"凭感觉"变成"凭规格"；代表工具 GitHub Spec-Kit、AWS Kiro |
| Spec（规格 / 规约） | 结构化描述"要做什么、为什么做、验收标准"的文档，先于代码 | SDD 的核心产物；强调 what/why 而非 how |
| Prompt as Code（提示即代码） | 把 prompt、规则、规格纳入版本管理，像代码一样评审和迭代 | AI 工程化的基础实践 |
| English as Code / 意图即代码 | 用自然语言表达意图，AI 负责翻译成实现 | Vibe Coding 的理念根基 |
| AI Slop / Vibe Slop（AI 垃圾产出） | AI 生成的低质、冗余、看似能跑实则难维护的代码/内容 | 批评 Vibe Coding 的高频词；对应"技术债飙升" |
规格驱动流程类（以 Spec-Kit 为例）
| 术语 | 一句话定义 | 面试延伸 / 坑点 |
|---|---|---|
| Constitution（宪法 / 章程） | 项目级一次性设定的治理原则和约束（编码规范、技术底线） | 贯穿全程的"最高法"，约束 AI 所有产出 |
| Specify（规格化） | 定义要构建什么——需求和用户故事，聚焦 what/why | 不谈技术栈，只谈目标 |
| Plan（方案） | 给出技术栈和架构选择——怎么建 | 从 what 到 how 的桥梁 |
| Tasks（任务拆解） | 从方案生成可执行的任务清单 | 把大目标拆成 AI 可逐个执行的小步 |
| Implement（实现） | 按任务清单逐个执行、生成代码 | 多步精修而非一次性生成 |
| Clarify / Analyze（澄清 / 分析） | Clarify=提前消除模糊点；Analyze=跨产物一致性检查 | 保证 spec/plan/tasks 不打架 |
| EARS（需求语法） | Easy Approach to Requirements Syntax，用固定句式写无歧义需求 | 如"When <触发>, the system shall <行为>"；让需求可测、可验收 |
质量门禁与围栏类
| 术语 | 一句话定义 | 面试延伸 / 坑点 |
|---|---|---|
| 门禁（Gate / Quality Gate） | 代码进入下一阶段前必须通过的强制检查卡点（测试/覆盖率/扫描/lint） | 不达标就卡住不让合并/发布；CI 里的"红绿灯"；SonarQube 质量门禁最典型 |
| 围栏 / 护栏（Guardrails / Fences） | 给 AI 或系统划定的行为边界，防止越界或危险操作 | AI 编码里指限制 AI 能改的文件/能跑的命令/能调的工具；对应"最小权限" |
| 卡点（Checkpoint） | 流程中设置的强制停顿/校验点 | 高风险操作前人工确认，同 HITL |
| Human-in-the-Loop（人在环路） | 关键步骤暂停等人工审核确认 | Vibe Coding 防翻车的安全阀；见第十七章 |
| Steering / Rules（引导规则） | 用规则文件（如 CLAUDE.md、.cursorrules）持续约束 AI 行为 | 把项目规范固化给 AI，避免每次重复交代 |
| Checklist（检查清单） | 对产出做质量校验的清单，被称为"英语的单元测试" | Spec-Kit 概念；用自然语言定义验收项 |
二十、求职招聘与职场 HR 黑话
面试全流程和入职谈薪时会碰到的高频词。看懂这些能避免在 offer、定级、补偿上吃暗亏。
招聘流程类
| 术语 | 一句话定义 | 面试延伸 / 坑点 |
|---|---|---|
| JD（Job Description，职位描述） | 岗位职责 + 任职要求的说明书 | 投递前对照 JD 定制简历；JD 里的"加分项"往往才是真正的筛选线 |
| HC（Head Count，人头 / 编制） | 团队获批的招聘名额 | "有没有 HC"决定能不能发 offer；HC 冻结=停招；跨部门抢 HC 常见 |
| 内推（Referral） | 员工推荐候选人走内部通道 | 简历直达 HR / 用人经理，过筛率高；推荐人有内推奖金 |
| 猎头（Headhunter） | 第三方招聘中介 | 按 offer 年薪 20%~30% 收服务费；多为社招中高端岗；别同一岗位被多个猎头重复推 |
| HRBP（HR Business Partner） | 派驻业务线的 HR | 招聘 / 绩效 / 员工关系一肩挑；裁员谈话常是 TA 出面 |
| 校招 / 社招 | 应届生招聘 / 有经验者招聘 | 校招看潜力和基础，社招看即战力和项目落地 |
| 提前批 | 校招正式批次前的抢人通道 | 竞争相对小、通过可锁 offer；大厂普遍设置 |
| HR 面 | HR 主导的综合面试 | 考察稳定性、动机、薪资预期；别暴露裸辞 / 海投；反问环节要准备 |
| 交叉面 | 非本部门面试官参与的一轮 | 防止用人经理"放水"，考察通用能力和横向评价 |
| 终面 | 最后一轮，多为主管 / 总监 / HRD 拍板 | 常谈薪、定级；到这轮基本稳，别松懈 |
| Offer | 录用通知 | 口头 offer ≠ 书面 offer；一切以书面 / 系统 offer 为准 |
| 背调（Background Check） | 入职前核实履历真实性 | 查在职时间、职级、薪资、离职原因；简历注水是雷区，第三方背调(如 i9)很细 |
| 感谢信 / 泡池子 | 婉拒信 / 简历留档待有 HC 再捞 | "祝前程似锦"=挂了；"纳入人才库"多是客气话，别干等 |
薪酬职级类
| 术语 | 一句话定义 | 面试延伸 / 坑点 |
|---|---|---|
| Base（基本工资） | 每月固定发放的月薪 | package 谈判的核心；base 高抗风险，奖金 / 股票有波动 |
| Package / 年包 | 年度总收入 = base×月数 + 奖金 + 股票 | 谈薪都谈年包；警惕用股票 / 画饼撑高的"纸面年包" |
| 13 薪 / 14 薪 | 年底多发的 1~2 个月工资 | 算年包时要问清几薪；有的和绩效挂钩、不保底 |
| 五险一金 / 六险二金 | 社保 + 公积金（+ 补充医疗 / 企业年金） | 公积金比例和基数是隐形收入；确认是否按全额 base 缴纳 |
| 期权 / 股票（Option / RSU / ESOP） | 公司给的股权激励 | vesting（归属）通常 4 年、1 年 cliff（满 1 年才解锁第一笔）；离职时未归属部分作废 |
| Signing Bonus（签字费） | 入职一次性奖金 | 常用来补偿你放弃的老东家股票 / 年终奖；可能绑服务期，提前离职要退 |
| 定级 / 职级（Leveling） | 入职对应的职级（如 P6/P7、L4/L5） | 决定薪资带宽和话语权；定级偏低后面很难受；跨级跳槽含金量高 |
| 薪资倒挂 | 新人薪资高于老员工 | 市场行情涨、老人不涨导致；是谈薪时的隐形筹码 |
| 谈薪 | 和 HR 协商薪资待遇 | 别先报价、拿竞品 offer 当筹码、谈年包别只盯月薪；期望值给区间不给死数 |
| N+1 / 2N（裁员补偿） | N=工作年限，N+1=协商解除多赔 1 个月，2N=违法解除双倍 | 协商解除通常 N+1；违法辞退可主张 2N；签字前看清是否写"协商一致" |
在职与离职类
| 术语 | 一句话定义 | 面试延伸 / 坑点 |
|---|---|---|
| 试用期（Probation） | 入职初期考察期，通常 3~6 个月 | 不合格可解除但需说明理由和依据；工资不得低于转正后的 80% |
| 竞业（限制 / 协议）（Non-compete） | 离职后一定期限内不得入职竞对 | 有补偿金（月薪 30% 起）才有效；违约要付违约金；范围过宽可争议 |
| PIP（绩效改进计划） | Performance Improvement Plan | 常是变相劝退的前奏；签了指标要留证据；别轻易签"自愿离职" |
| 绩效（361 / 271、KPI / OKR） | 强制分布的绩效考核 | 强制末位（如 10% 待改进）；连续低绩效可能被优化；OKR 重目标、KPI 重指标 |
| 优化 / 毕业 / 向社会输送人才 | 裁员的黑话 | "毕业"=被裁；"组织调整""人才流动"同义；小心被"劝退"变自离，丢掉补偿 |
| 活水（内部转岗） | 公司内部换岗位 / 部门 | 不用离职就换赛道；需现主管放人 + 新团队有 HC |
| 汇报线（Reporting Line） | 向谁汇报工作 | 实线=直属上级（定你绩效），虚线=业务协作；入职前问清，避免多头管理 |
| 大小周 / 996 / 007 | 工作时间黑话 | 大小周=隔周单休；996=9 点到 9 点每周 6 天；工时是入职尽调重点 |
| 三方协议 | 应届生 学校 / 单位 / 学生 的就业协议 | 违约要付违约金（常 5000）；只能签一份；和劳动合同性质不同 |
| gap / 裸辞 | 空窗期 / 没找好下家就辞职 | 面试常被追问 gap 原因；裸辞在 HR 面尽量表述成"主动规划" |
二十一、团队角色与研发协作缩写
一个需求从想法到上线，会串起一整条角色链。搞懂这些缩写，跨团队沟通和面试聊项目协作时不露怯。
岗位角色类
| 术语 | 一句话定义 | 面试延伸 / 坑点 |
|---|---|---|
| PM（Product Manager，产品经理） | 定义做什么、写 PRD、排优先级的人 | 有时也指 Project Manager（项目经理）；互联网语境默认产品经理；和 RD 常"相爱相杀" |
| PMO / PJM（项目管理办公室 / 项目经理） | 管进度、排期、风险、跨团队协调的人 | 不碰功能设计，盯交付节奏；PMO 是公司级项目治理部门 |
| RD（Research & Development，研发工程师） | 泛指写代码的开发（国内常指后端） | 字节 / 百度体系里 RD 就是开发工程师统称；对外也说 SDE |
| FE（Front-End，前端工程师） | 负责浏览器 / H5 页面和交互实现 | 和 UI / UE 对接还原设计稿；React / Vue 技术栈 |
| BE（Back-End，后端工程师） | 负责服务端逻辑、接口、数据库 | 和 FE 联调接口；本速查前 20 章主打 BE 面试 |
| CE / 客户端（Client Engineer） | 负责 iOS / Android / 桌面 App 开发 | 端上开发；常再细分 iOS / 安卓 |
| UE / UX（User Experience，交互设计师） | 设计交互流程、信息架构、原型 | UE=UX；管"怎么用得顺"，不管颜色好不好看 |
| UI（User Interface，视觉设计师） | 设计界面视觉、配色、组件、规范 | 管"长得好不好看"；产出高保真设计稿和 UI 规范 |
| UED（用户体验设计部） | UI + UE + 用研 + 前端 的设计团队统称 | 阿里体系常用；一个部门涵盖体验全链路 |
| 用研（User Research，用户研究） | 通过访谈 / 问卷 / 数据研究用户需求 | 给产品和设计提供决策依据 |
| QA（Quality Assurance，测试工程师） | 保证质量、设计用例、执行测试的人 | 国内 QA ≈ 测试；提测后由 QA 把关，发现 bug 打回 |
| 测开 / SDET / SET（测试开发工程师） | 写测试框架、自动化、工具的开发 | Software Development Engineer in Test；比纯 QA 更偏编码 |
| DBA（Database Administrator，数据库管理员） | 负责数据库运维、优化、容灾 | 大厂稀缺；慢 SQL、分库分表常找 TA |
| OP / SRE / DevOps（运维 / 稳定性工程） | 保障服务上线、监控、稳定性 | SRE 用软件工程做运维；见第十二章 |
| 算法 / MLE（算法工程师） | 做推荐 / 搜索 / 风控 / 大模型的工程师 | 分策略算法和工程算法；和 RD 区分 |
| 数据 / DE（Data Engineer，数据工程师） | 建数仓、跑 ETL、做数据管道 | 和数据分析（DA）、算法区分 |
| DA / 商分（Data Analyst / 商业分析） | 用数据支持业务决策 | 出报表、做归因、看指标 |
| TL（Team Leader / Tech Lead，技术负责人） | 带团队 / 定技术方案的人 | Tech Lead 偏技术拍板，Team Leader 偏管理；面试可能是 TA 终面 |
| Owner / PO（Product Owner，负责人） | 某模块 / 需求的第一责任人 | 敏捷里 PO 定义 backlog；"谁 owner 这块"=谁负责 |
需求与研发协作类
| 术语 | 一句话定义 | 面试延伸 / 坑点 |
|---|---|---|
| PRD（产品需求文档） | 产品经理写的"要做什么"的详细文档 | RD 排期和开发的依据；评审不过不能开工 |
| MRD / BRD（市场 / 商业需求文档） | MRD=市场需求，BRD=商业价值论证 | 优先级 BRD > MRD > PRD；越靠前越偏商业决策 |
| 需求评审 / 技术评审 | 拉齐各方过一遍需求 / 技术方案 | 评审通过才进排期；目的是提前发现坑 |
| 排期 | 确定各角色的开发 / 测试时间计划 | PM 催排期，RD 报工时；delay（延期）是高频词 |
| 联调 | FE 和 BE（或多端）对接接口、跑通流程 | 接口文档不一致最容易翻车；提前约定字段和 mock |
| 提测 | 开发完成后把版本交给 QA 测试 | 提测质量差会被 QA 打回；一般有提测标准 / 冒烟 |
| 冒烟测试（Smoke Test） | 提测后先跑核心主流程的快速验证 | 冒烟不过直接打回，不进入详细测试 |
| 走查 / 验收 | 设计师 / PM 检查还原度和功能是否符合预期 | UI 走查看还原度，PM 验收看功能 |
| 灰度 / 上线 / 回滚 | 小流量放量 / 正式发布 / 出问题退版本 | 见第二章；发布三件套 |
二十二、容灾与多活架构
第十二章有速记版，这里展开讲。金融、大厂高级架构面试的重头戏，从冷备一路问到异地多活、两地三中心，考的是你对可用性、一致性、成本三者取舍的理解。
备份与切换基础类
| 术语 | 一句话定义 | 面试延伸 / 坑点 |
|---|---|---|
| 冷备 / 温备 / 热备 | 冷=备机平时关闭需拉起；温=开机但不接流量；热=实时同步随时可切 | 越热恢复越快、成本越高；冷备 RTO 以小时计，热备以秒计 |
| 主备 / 主从（Active-Standby） | 一主对外服务，一备待命，主故障切备 | 备机平时闲置浪费；切换要防脑裂、防抖动 |
| 双活（Active-Active） | 两个中心同时对外服务、互为备份 | 资源都用上；难点在数据双向同步和写冲突 |
| 多活（Multi-Active） | 多个中心同时服务并各自承载流量 | 容灾终极形态；单元化是主流实现 |
| 同步复制 / 异步复制 / 半同步 | 同步=等从库确认再返回；异步=不等直接返回；半同步=至少一个从库确认 | 同步不丢数据但慢，异步快但可能丢；半同步是折中 |
| RTO / RPO | RTO=故障后多久恢复服务；RPO=最多能丢多少数据 | 容灾两大核心指标；RPO=0 需同步复制，代价高；见第十二章 |
| 灾备等级（6 级容灾国标） | 国标 GB/T 20988 定义的 0~6 级容灾能力 | 6 级=零数据丢失 + 远程集群自动接管；金融机构按等级建设 |
多活部署形态与关键机制类
| 术语 | 一句话定义 | 面试延伸 / 坑点 |
|---|---|---|
| 同城灾备 | 同城市不同机房建备份中心 | 网络延迟低（约 1~2ms）可同步复制、RPO≈0；防机房级故障，防不了城市级灾难 |
| 异地灾备 | 远距离城市建灾备中心 | 防地域级灾难（地震 / 断电）；延迟高只能异步复制，有数据丢失风险 |
| 同城双活 | 同城两机房都对外服务 | 延迟低可做到 RPO≈0；比灾备利用率高；主流做法 |
| 异地多活（异地双活） | 不同城市多个中心同时服务、就近接入 | 阿里 / 蚂蚁标杆；核心=单元化 + 数据同步 + 就近路由；同时解决容灾和扩展性 |
| 两地三中心 | 两个城市、三个数据中心（同城双中心 + 异地一中心） | 银行 / 金融标配；同城双活抗机房故障，异地一中心抗城市级灾难 |
| 三地五中心 | 跨三城五机房的高等级容灾架构 | 蚂蚁代表方案；任意城市故障不丢数据、可自动切换 |
| 单元化（LDC / 单元化架构） | 把用户按维度切成自包含的封闭单元 | 异地多活的基石；单元内流量闭环，减少跨地域调用；LDC=逻辑数据中心 |
| 单元（RZone / GZone / CZone） | 蚂蚁单元化里的逻辑分区 | RZone=可按用户拆分的业务，GZone=全局唯一不可拆，CZone=同城只读缓存 |
| 就近路由 / 流量调度（GSLB） | 按用户位置把请求路由到最近单元 | 依赖 DNS / GSLB / 接入层；是异地多活的入口 |
| 数据同步（DRC / DTS） | 多中心间复制数据保持最终一致 | 难点：写冲突解决、循环复制、同步延迟 |
| 脑裂（Split-Brain） | 网络分区导致多个中心都以为自己是主 | 双活 / 多活最大风险；靠仲裁、quorum、防护栏避免 |
| 切流 / 容灾切换（Failover） | 故障时把流量从故障中心切到健康中心 | 关键指标是切换耗时；追求一键切流、分钟级恢复 |
| 容灾演练 / 混沌工程 | 主动模拟断网 / 断电 / 宕机验证容灾能力 | 阿里"断网断电"演练、Netflix Chaos Monkey；不演练的容灾等于没有 |
| 爆炸半径（Blast Radius） | 一次故障波及的影响范围 | 通过隔离、单元化、限流把爆炸半径压到最小；见第十二章 |
二十三、大模型评测与基准（Benchmark）
聊 AI 模型绕不开"刷分"。看懂这些基准和评测方法，能判断一个模型的能力宣称到底靠不靠谱，也是 Agent / AI 应用面试的高频延伸。
主流基准（Benchmark）类
| 术语 | 一句话定义 | 面试延伸 / 坑点 |
|---|---|---|
| SWE-bench | 用真实 GitHub issue + PR 测模型能否自主改代码修 bug 的基准 | 最贴近真实软件工程；SWE-bench Verified 是人工校验子集；Agent 编码能力标杆 |
| HumanEval / MBPP | OpenAI 函数级编程题 / 入门 Python 题集，测代码生成 | 指标 pass@k；早期代码标准基准，如今已接近饱和 |
| LiveCodeBench | 用最新竞赛题、按时间滚动防数据污染的代码基准 | 抗"背题"；对比 HumanEval 更能反映真实水平 |
| MMLU / MMLU-Pro | 覆盖 57 学科的多选知识问答，测通用知识 | 老牌通用能力基准；MMLU-Pro 更难、选项更多 |
| GPQA | 研究生级、专家都难的科学问答 | "Google-Proof"防搜索答题；测深度推理 |
| GSM8K / MATH / AIME | 小学应用题 / 竞赛数学 / 数学邀请赛，测数学推理 | GSM8K 已饱和，MATH、AIME 是推理模型（o 系列、R1）的秀场 |
| BBH（BIG-Bench Hard） | BIG-Bench 里最难的一批任务 | 测复杂、多步推理 |
| Chatbot Arena（LMArena） | 用户两两盲评投票、按 Elo 排名 | LMSYS 维护；众包盲评最贴近真实体验，难被刷 |
| Agent 类（GAIA / WebArena / τ-bench / AgentBench） | 测用工具、浏览网页、多步任务的能力 | GAIA=通用助理，WebArena=网页操作，τ-bench=工具 + 对话 |
评测方法与指标类
| 术语 | 一句话定义 | 面试延伸 / 坑点 |
|---|---|---|
| pass@k | 生成 k 个候选里至少一个通过测试的概率 | 代码评测标准指标；k 越大越宽松，pass@1 最严 |
| LLM-as-Judge | 用强模型当裁判给答案打分 | 便宜可扩展；坑：位置偏好、啰嗦偏好、自我偏袒，需校准和对照 |
| Elo / Arena 评分 | 像下棋一样让模型两两对战、按胜负算相对分 | Chatbot Arena 用法；反映相对强弱而非绝对值 |
| 数据污染 / 刷榜（Data Contamination） | 测试题混进了训练数据导致分数虚高 | 高分 ≠ 真强；用最新题 / 私有测试集防污染 |
| 过拟合基准（Benchmark Overfitting） | 为刷榜专门优化、真实能力没提升 | Goodhart 定律："指标一旦成为目标，就不再是好指标" |
| 任务完成率 / 轨迹评估 | Agent 端到端完成任务比例 + 逐步动作是否合理 | Agent 评测核心；见第十七章的 trajectory 评估 |
| 忠实度（Faithfulness）/ 幻觉率 | 答案是否忠于给定材料 / 编造比例 | RAG 与事实性评测关键指标；见第十八章 |
| win-rate / 人类偏好对齐 | 人类更偏好哪个回答的胜率 | AlpacaEval、Arena-Hard 等；衡量对齐（RLHF）效果 |
附：面试高频"组合拳"问题清单
- 限流、熔断、降级的区别与协作？（见第一章）
- 缓存穿透 / 击穿 / 雪崩分别是什么，怎么解决？（第四章）
- 如何保证接口幂等？（唯一键、Token、状态机、乐观锁）
- 如何保证消息不丢、不重复、有序？（第六章）
- 分布式事务有哪些方案，怎么选？（2PC / TCC / Saga / 本地消息表 / 事务消息）
- CAP 怎么取舍，你的系统是 CP 还是 AP？（第三章）
- 主从延迟导致读不到刚写的数据怎么办？（读主库 / 强一致读 / 延迟双删）
- P99 高但平均值正常，如何排查长尾？（第七、十一章）
- 如何设计一个高可用的系统？（多活、故障转移、限流降级、隔离、可观测）
- 同城双活、异地多活、两地三中心有什么区别，怎么选？（第二十二章）
- 上下文越长效果越好吗？什么是上下文腐化，怎么应对？（第十六章）
- 如何缓解大模型幻觉？（RAG、引用出处、降温、拒答；第十五、十八章）
- RAG 和微调怎么选？RAG 完整链路有哪些环节？（第十八章）
- 检索召回不准怎么优化？（混合检索、重排、查询改写、分块策略；第十八章）
- 怎么控制 Agent 的成本和防止死循环？（限轮数、压上下文、缓存、循环检测；第十七章）
- Workflow、Agent、Agentic Workflow 有什么区别？（第十七章）
- 怎么评估一个大模型 / Agent 的能力？基准分高就一定强吗？（数据污染、刷榜、LLM-as-Judge；第二十三章）
- 混合检索里稠密和稀疏怎么融合？为什么要 RRF？（第十八章）
维护约定：新增词条时保持"定义 → 通俗 → 延伸"三段式；按主题归入对应章节；口语黑话统一放第十四章；AI/大模型相关放第十五~十九章（含 Vibe Coding 与 SDD）；求职招聘 / 职场 HR 黑话放第二十章；团队角色与研发协作缩写放第二十一章；容灾与多活架构放第二十二章；大模型评测与基准放第二十三章。