5G系统引入了全新的安全架构,最核心的变化之一是在主认证(Primary Authentication)层面同时支持 5G-AKA 和 EAP-AKA' 两种认证方法。这两种方法虽然都基于相同的长期密钥K,但在协议封装、密钥推演路径、认证向量构造和归属网络控制粒度上存在根本性差异。本文基于 3GPP TS 33.501 V18.9.0 Section 6.1及Annex A/C,逐信令消息拆解双轨认证的完整机制。
5G主认证的核心目标是实现UE与网络之间的双向认证,并生成锚点密钥 K~SEAF~(Security Anchor Function Key)。整个认证框架由以下安全功能节点协作完成:
| 功能节点 | 英文全称 | 核心职责 |
|---|---|---|
| SEAF | Security Anchor Function | 与AMF共部署,作为服务网络的认证锚点 |
| AUSF | Authentication Server Function | 归属网络认证服务器,验证UE响应 |
| UDM/ARPF | Unified Data Management / Authentication Credential Repository and Processing Function | 存储长期密钥K,生成认证向量 |
| SIDF | Subscription Identifier De-concealing Function | UDM内嵌功能,从SUCI解密出SUPI |
关键设计原则(TS 33.501 Section 6.1.1.1):
当使用EAP-AKA'时,5G系统对RFC 3748定义的EAP框架角色映射如下:
graph TD
UE["UE<br/>(EAP Peer)"] -->|"EAP-Request/Response<br/>经NAS透传"| SEAF["SEAF/AMF<br/>(Pass-through<br/>Authenticator)"]
SEAF -->|"Nausf_UEAuthentication<br/>SBI服务"| AUSF["AUSF<br/>(Backend<br/>Authentication Server)"]
AUSF -->|"Nudm_UEAuthentication_Get"| UDM["UDM/ARPF<br/>(凭证仓库)"]
style UE fill:#4CAF50,color:white
style SEAF fill:#2196F3,color:white
style AUSF fill:#FF9800,color:white
style UDM fill:#9C27B0,color:white
关键区别:5G-AKA不使用EAP框架,而是直接通过NAS层的Authentication Request/Response消息完成质询-应答;EAP-AKA'则在NAS消息内封装EAP包,SEAF做透传。
SEAF可以在任何建立信令连接的过程中发起认证(如注册、服务请求),核心流程如下:
sequenceDiagram
participant UE
participant SEAF as SEAF/AMF
participant AUSF
participant UDM as UDM/ARPF
UE->>SEAF: Registration Request<br/>(含SUCI或5G-GUTI)
SEAF->>AUSF: Nausf_UEAuthentication_Authenticate Request<br/>(SUCI/SUPI + serving network name)
AUSF->>AUSF: 验证SEAF是否有权使用<br/>该serving network name
AUSF->>UDM: Nudm_UEAuthentication_Get Request<br/>(SUCI/SUPI + SN-Name)
UDM->>UDM: SIDF解密SUCI→SUPI<br/>(如收到SUCI)
UDM->>UDM: ARPF选择认证方法<br/>(5G-AKA或EAP-AKA')
UDM-->>AUSF: Nudm_UEAuthentication_Get Response<br/>(认证向量+方法指示)
方法选择逻辑(Section 6.1.2原文): - 认证方法由归属网络运营商决定,基于SUPI选择 - AUSF需验证SEAF使用的serving network name是否被授权(通过3gpp-Sbi-Originating-Network-Id头校验) - SEAF发送的请求必须包含serving network name
serving network name的构造规则对两种认证方法都至关重要——它直接参与密钥推演:
Serving Network Name = "5G:" + SN Id
其中SN Id标识服务PLMN(定义在TS 24.501),格式示例:5G:mnc070.mcc460.3gppnetwork.org
设计意图:将serving network name纳入KDF输入,实现锚点密钥与服务网络的密码学绑定,防止一个服务网络伪装成另一个(Section 6.1.1.3)。
sequenceDiagram
participant UE as UE (USIM+ME)
participant SEAF as SEAF/AMF
participant AUSF as AUSF
participant UDM as UDM/ARPF
rect rgb(240,248,255)
Note over UE,UDM: 阶段一:认证向量生成
SEAF->>AUSF: ① Nausf_UEAuthentication_Authenticate Request<br/>SUCI/SUPI, SN-Name
AUSF->>UDM: ② Nudm_UEAuthentication_Get Request<br/>SUCI/SUPI, SN-Name
UDM->>UDM: ③ SIDF解密SUCI→SUPI<br/>生成AV(RAND,AUTN,CK,IK,XRES)<br/>AMF separation bit=1<br/>推导K_AUSF(Annex A.2)<br/>计算XRES*(Annex A.4)<br/>构造5G HE AV
UDM-->>AUSF: ④ Nudm_UEAuthentication_Get Response<br/>5G HE AV(RAND,AUTN,XRES*,K_AUSF)<br/>+ SUPI + 方法指示=5G AKA
end
rect rgb(255,248,240)
Note over UE,AUSF: 阶段二:服务网络认证向量处理
AUSF->>AUSF: ⑤ 存储XRES*+SUCI/SUPI<br/>计算HXRES*(Annex A.5)<br/>计算K_SEAF(Annex A.6)<br/>构造5G SE AV
AUSF-->>SEAF: ⑥ Nausf_UEAuthentication_Authenticate Response<br/>5G SE AV(RAND,AUTN,HXRES*)
end
rect rgb(240,255,240)
Note over UE,SEAF: 阶段三:UE质询-应答
SEAF->>UE: ⑦ NAS Authentication Request<br/>RAND, AUTN, ngKSI, ABBA
UE->>UE: ⑧ USIM验证AUTN→计算RES<br/>ME计算RES*(Annex A.4)<br/>计算K_AUSF(A.2)→K_SEAF(A.6)
UE-->>SEAF: ⑨ NAS Authentication Response<br/>RES*
SEAF->>SEAF: ⑩ 计算HRES*(Annex A.5)<br/>比较HRES* vs HXRES*
end
rect rgb(255,240,255)
Note over SEAF,AUSF: 阶段四:归属网络确认
SEAF->>AUSF: ⑪ Nausf_UEAuthentication_Authenticate Request<br/>RES*
AUSF->>AUSF: ⑫ 比较RES* vs XRES*<br/>通知UDM认证结果
AUSF-->>SEAF: ⑬ Nausf_UEAuthentication_Authenticate Response<br/>认证成功/失败 + K_SEAF + SUPI
SEAF->>SEAF: ⑭ 推导K_AMF(Annex A.7)<br/>提供ngKSI+K_AMF给AMF
end
| IE名称 | 说明 | 来源 |
|---|---|---|
| SUCI/SUPI | 首次用SUCI,重认证用SUPI | TS 33.501 Section 6.1.2 |
| Serving Network Name | "5G:" + SN Id | Section 6.1.1.4 |
| Disaster Roaming指示 | 可选 | TS 23.502 Section 4.2.2.2 |
这是5G-AKA最关键的步骤之一。UDM/ARPF的内部处理:
(RAND, AUTN, CK, IK, XRES),AMF separation bit 必须设为1KEY = CK || IK
S = FC(0x6A) || SN-Name || L0 || SQN⊕AK || L1(0x00 0x06)
K_AUSF = KDF(KEY, S)KEY = CK || IK
S = FC(0x6B) || SN-Name || L0 || RAND || L1(0x00 0x10) || XRES || L2
XRES* = KDF最低128位输出(RAND, AUTN, XRES*, K_AUSF)设计意图:XRES* 将原始XRES与RAND和serving network name绑定,防止跨网络重放攻击。
AUSF在此步骤完成双层保护设计:
SHA-256(RAND || XRES*) 的最低128位KDF(K_AUSF, FC(0x6C) || SN-Name || L0)(RAND, AUTN, HXRES*)关键安全设计:服务网络(SEAF)永远无法获得 XRES* 和 K~AUSF~。SEAF只能看到HXRES*(哈希值),无法反推原始响应。这确保了归属网络对认证结果的最终控制权。
| 消息 | 方向 | 关键IE |
|---|---|---|
| NAS Authentication Request | SEAF→UE | RAND, AUTN, ngKSI, ABBA |
| NAS Authentication Response | UE→SEAF | RES* |
UE侧处理(Section 6.1.3.2 Step 7-8): 1. ME将RAND/AUTN转发给USIM 2. USIM验证AUTN新鲜性(检查SQN),计算RES,返回RES/CK/IK给ME 3. ME从CK||IK推导K~AUSF~(与ARPF相同的KDF) 4. ME从RES计算RES*(与ARPF相同的KDF) 5. ME进一步计算K~SEAF~
ABBA参数(Annex A.7.1):当前版本固定为 0x0000,用于未来安全特性的降级保护(anti-bidding-down)。
这是5G-AKA相对EPS-AKA最重要的安全增强:
flowchart TD
A["SEAF收到RES*"] --> B["计算HRES*<br/>SHA-256(RAND||RES*)"]
B --> C{"HRES* == HXRES*?"}
C -->|是| D["服务网络认证通过<br/>(第一层验证)"]
C -->|否| E["服务网络认证失败<br/>可能为伪造UE"]
D --> F["发送RES*给AUSF"]
F --> G{"AUSF: RES* == XRES*?"}
G -->|是| H["归属网络认证通过<br/>(第二层验证)<br/>返回K_SEAF+SUPI"]
G -->|否| I["归属网络认证失败<br/>通知SEAF"]
style D fill:#4CAF50,color:white
style H fill:#2196F3,color:white
style E fill:#f44336,color:white
style I fill:#f44336,color:white
TS 33.501原文(Section 6.1.3.2.0):"5G AKA enhances EPS AKA by providing the home network with proof of successful authentication of the UE from the visited network."
在4G EPS-AKA中,MME既持有XRES又负责验证,归属网络无法确认访问网络是否真的完成了UE认证。5G-AKA通过分离HXRES*(给SEAF)和XRES*(仅AUSF持有) 实现了归属网络对认证结果的独立验证。
sequenceDiagram
participant UE as UE (USIM+ME)
participant SEAF as SEAF/AMF
participant AUSF as AUSF
participant UDM as UDM/ARPF
rect rgb(240,248,255)
Note over UE,UDM: 认证向量生成
AUSF->>UDM: Nudm_UEAuthentication_Get Request<br/>SUCI/SUPI, SN-Name
UDM->>UDM: 生成AV(RAND,AUTN,CK,IK,XRES)<br/>计算CK',IK'(Annex A.3)<br/>构造转换后AV'
UDM-->>AUSF: AV'(RAND,AUTN,XRES,CK',IK')<br/>+ 方法指示=EAP-AKA'
end
rect rgb(255,248,240)
Note over UE,AUSF: EAP质询-应答
AUSF-->>SEAF: EAP-Request/AKA'-Challenge<br/>(封装在Nausf Response中)
SEAF->>UE: NAS Authentication Request<br/>EAP-Request/AKA'-Challenge<br/>+ ngKSI, ABBA
UE->>UE: USIM验证AUTN→RES,CK,IK<br/>ME推导CK',IK'(Annex A.3)
UE-->>SEAF: NAS Authentication Response<br/>EAP-Response/AKA'-Challenge
SEAF->>AUSF: Nausf Request<br/>(透传EAP-Response/AKA'-Challenge)
AUSF->>AUSF: 比较XRES vs RES
end
rect rgb(240,255,240)
Note over UE,AUSF: 密钥推演与确认
AUSF->>AUSF: 从CK',IK'推导EMSK<br/>取EMSK最高256位=K_AUSF<br/>推导K_SEAF(Annex A.6)
AUSF-->>SEAF: EAP-Success<br/>(含K_SEAF, SUPI)
SEAF->>UE: NAS消息<br/>EAP-Success + ngKSI + ABBA
UE->>UE: 推导EMSK→K_AUSF→K_SEAF→K_AMF
end
| 比较维度 | 5G-AKA | EAP-AKA' |
|---|---|---|
| 协议框架 | NAS直接承载(非EAP) | EAP框架封装(RFC 3748) |
| 规范章节 | Section 6.1.3.2 | Section 6.1.3.1 |
| 认证向量 | 5G HE AV (RAND, AUTN, XRES*, K~AUSF~) | 转换后AV' (RAND, AUTN, XRES, CK', IK') |
| K~AUSF~来源 | ARPF从CK||IK推导(Annex A.2) | AUSF/UE从EMSK最高256位取得 |
| 中间密钥 | CK/IK→K~AUSF~→K~SEAF~ | CK/IK→CK'/IK'→EMSK→K~AUSF~→K~SEAF~ |
| 认证确认 | RES* vs XRES*(AUSF验证) | RES vs XRES(AUSF验证) |
| 服务网络预验证 | HXRES* vs HRES*(SEAF验证) | 无(SEAF仅透传EAP消息) |
| 归属网络证明 | 有(RES*确认机制) | 无(与4G EAP-AKA'类似) |
| 成功消息 | 无显式成功(依赖后续NAS SMC) | EAP-Success消息 |
| 适用场景 | 3GPP接入(NR/LTE) | 非可信非3GPP接入(Wi-Fi via N3IWF)、SNPN |
| 消息开销 | 较低(2条NAS消息) | 较高(EAP封装+额外Notification) |
flowchart TD
K["K<br/>(长期密钥, 128/256bit<br/>存储于USIM和ARPF)"]
K -->|"5G-AKA"| CK_IK["CK, IK<br/>(USIM生成)"]
K -->|"EAP-AKA'"| CK_IK2["CK, IK<br/>(USIM生成)"]
CK_IK --> KAUSF_5G["K_AUSF<br/>FC=0x6A<br/>KEY=CK||IK<br/>P0=SN-Name, P1=SQN⊕AK"]
CK_IK2 --> CKP_IKP["CK', IK'<br/>FC=via TS 33.402 A.2<br/>KEY=CK||IK<br/>P0=SN-Name"]
CKP_IKP --> EMSK["EMSK (512bit)<br/>RFC 5448 / Annex F"]
EMSK --> KAUSF_EAP["K_AUSF<br/>EMSK最高256位"]
KAUSF_5G --> KSEAF["K_SEAF<br/>锚点密钥<br/>FC=0x6C<br/>KEY=K_AUSF<br/>P0=SN-Name"]
KAUSF_EAP --> KSEAF
KSEAF --> KAMF["K_AMF<br/>FC=0x6D<br/>KEY=K_SEAF<br/>P0=SUPI, P1=ABBA"]
KAMF --> KNAS["NAS密钥"]
KAMF --> KAS["AS/接入网密钥"]
KAMF --> KN3IWF["非3GPP密钥<br/>K_N3IWF<br/>FC=0x6E"]
KNAS --> KNASint["K_NASint<br/>FC=0x69<br/>NAS完整性"]
KNAS --> KNASenc["K_NASenc<br/>FC=0x69<br/>NAS加密"]
KAS --> KgNB["K_gNB<br/>FC=0x6E<br/>KEY=K_AMF<br/>P0=UL NAS COUNT"]
KgNB --> KRRCint["K_RRCint<br/>FC=0x69"]
KgNB --> KRRCenc["K_RRCenc<br/>FC=0x69"]
KgNB --> KUPenc["K_UPenc<br/>FC=0x69"]
KgNB --> KUPint["K_UPint<br/>FC=0x69"]
KAMF --> NH["NH<br/>FC=0x6F<br/>前向安全链"]
style K fill:#f44336,color:white
style KSEAF fill:#FF9800,color:white
style KAMF fill:#2196F3,color:white
style KgNB fill:#4CAF50,color:white
所有5GC密钥推演使用TS 33.220 Annex B.2.0定义的KDF:
KDF(KEY, S) = HMAC-SHA-256(KEY, S)
其中 S = FC || P0 || L0 || P1 || L1 || ... || Pn || Ln
FC(Function Code)值分配范围:0x69 ~ 0x79, 0x7B ~ 0x7D, 0x83 ~ 0x84
| KDF步骤 | FC值 | 输入KEY | 参数P0 | 参数P1 | 参数P2 | 输出 |
|---|---|---|---|---|---|---|
| K~AUSF~推导(5G-AKA) | 0x6A | CK||IK | SN-Name | SQN⊕AK | - | K~AUSF~ |
| CK'/IK'推导(EAP-AKA') | TS 33.402 | CK||IK | SN-Name | - | - | CK',IK' |
| RES*/XRES*推导 | 0x6B | CK||IK | SN-Name | RAND | RES/XRES | RES*/XRES* |
| HRES*/HXRES*推导 | - | - | RAND | RES*/XRES* | - | SHA-256输出最低128位 |
| K~SEAF~推导 | 0x6C | K~AUSF~ | SN-Name | - | - | K~SEAF~ |
| K~AMF~推导 | 0x6D | K~SEAF~ | SUPI | ABBA | - | K~AMF~ |
| NAS/AS算法密钥 | 0x69 | K~AMF~/K~gNB~ | 算法类型区分符 | 算法ID | - | 具体算法密钥 |
| K~gNB~推导 | 0x6E | K~AMF~ | UL NAS COUNT | 接入类型区分符 | - | K~gNB~ |
| NH推导 | 0x6F | K~AMF~ | SYNC-input | - | - | NH |
SUCI = <SUPI Type> || <MCC> || <MNC> || <Routing Indicator> || <Protection Scheme ID> || <Home Network PK ID> || <Scheme Output>
| 字段 | 说明 |
|---|---|
| SUPI Type | 0=IMSI, 1=NAI, 2=GCI, 3=GLI |
| Protection Scheme ID | 0x0=null-scheme, 0x1=Profile A, 0x2=Profile B |
| Home Network PK ID | 标识使用的公钥对 |
| Scheme Output | 加密后的MSIN/username部分 |
5G为SUPI保护定义了两种ECIES profile,均由ME和SIDF实现:
| 参数 | Profile A | Profile B |
|---|---|---|
| 椭圆曲线 | Curve25519 (RFC 7748) | secp256r1 (SEC 2) |
| DH原语 | X25519 | EC Cofactor DH |
| 点压缩 | 不适用 | 使用 |
| KDF | ANSI-X9.63-KDF | ANSI-X9.63-KDF |
| Hash | SHA-256 | SHA-256 |
| MAC | HMAC-SHA-256, 64bit tag | HMAC-SHA-256, 64bit tag |
| 加密 | AES-128 CTR mode | AES-128 CTR mode |
| Scheme Output大小 | 256bit公钥 + 64bit MAC + 输入大小 | 264bit公钥 + 64bit MAC + 输入大小 |
UE侧加密流程(Annex C.3.2):
flowchart TD
A["SUPI中的MSIN<br/>(明文)"] --> B["生成ECC临时<br/>公私钥对"]
B --> C["ECDH协商<br/>UE临时私钥×HN公钥"]
C --> D["KDF生成密钥材料<br/>EK + ICB + MK"]
D --> E["AES-128-CTR加密<br/>MSIN→密文"]
D --> F["HMAC-SHA-256<br/>计算MAC tag"]
E --> G["Scheme Output =<br/>临时公钥+密文+MAC"]
F --> G
style G fill:#4CAF50,color:white
归属网络侧解密(Annex C.3.3):SIDF使用收到的UE临时公钥和归属网络私钥执行ECDH,恢复共享密钥后解密。
TS 33.501 Section 6.12规定:SUCI的计算可以由USIM或ME完成,由USIM中的SUCI calculation indication决定。如果USIM不支持该指示位,则默认由ME计算。
stateDiagram-v2
[*] --> AuthPending: 收到RAND/AUTN
AuthPending --> VerifyAUTN: USIM验证AUTN
VerifyAUTN --> AuthSuccess: AUTN验证通过
VerifyAUTN --> MACFailure: MAC验证失败
VerifyAUTN --> SyncFailure: SQN不同步
MACFailure --> SendAuthReject: UE发送<br/>Authentication Failure<br/>CAUSE=MAC failure
SyncFailure --> SendSyncFail: UE发送<br/>Authentication Failure<br/>CAUSE=Sync failure<br/>+AUTS参数
SendSyncFail --> ARPFReSync: ARPF验证AUTS<br/>重新生成AV
ARPFReSync --> AuthPending: 新RAND/AUTN
SendAuthReject --> [*]: 网络决定<br/>重试或拒绝
AuthSuccess --> [*]
AUTS参数(TS 33.102):包含UE侧的SQN~MS~和MAC~S~,允许ARPF检测SQN偏移并重新同步。归属网络的同步恢复流程在Section 6.1.3.3.2中定义。
| 步骤 | 协议层 | Wireshark过滤器 | 关键字段 |
|---|---|---|---|
| Registration Request | 5G-NAS | nas-5gs.reg.message_type == 0x41 |
SUCI或5G-GUTI |
| Authentication Request | 5G-NAS | nas-5gs.reg.message_type == 0x53 |
RAND(16B), AUTN(16B), ngKSI |
| Authentication Response | 5G-NAS | nas-5gs.reg.message_type == 0x55 |
RES* |
| Authentication Failure | 5G-NAS | nas-5gs.reg.message_type == 0x5C |
Cause(20=Sync, 26=MAC) |
| Nausf Authenticate Req | HTTP2/JSON | http2.headers.path contains "nausf-auth" |
servingNetworkName |
| Nudm UEAuth Get | HTTP2/JSON | http2.headers.path contains "nudm-ueauth" |
suciOrSupi |
| 故障现象 | 可能原因 | 排查思路 |
|---|---|---|
| Authentication Failure (MAC failure) | USIM与ARPF密钥K不一致、AUTN被篡改 | 检查Ki/K同步、核查传输完整性 |
| Authentication Failure (Sync failure) | USIM的SQN与ARPF的SQN偏差过大 | 检查ARPF SQN管理策略(如SQN max delta) |
| AUSF返回"serving network not authorized" | SN-Name与3gpp-Sbi-Originating-Network-Id不匹配 | 核查SEAF/AUSF配置、SEPP路由 |
| HRES*≠HXRES*(SEAF验证失败) | UE计算错误或中间人攻击 | 对比UE和AUSF的KDF输入参数 |
| SUCI解密失败 | 公私钥对不匹配、Profile配置不一致 | 检查Home Network PK ID和Profile ID |
| ## 常见问题 |
Q1: 5G-AKA和EAP-AKA'能否在同一注册流程中切换使用? A: 不能在同一次认证中切换。方法由UDM/ARPF在收到认证请求时一次性选定,并告知AUSF。但不同次注册可以使用不同方法(如3GPP接入用5G-AKA,非3GPP接入用EAP-AKA')。
Q2: 5G-AKA中SEAF验证(HRES*)失败后会发生什么? A: 根据Section 6.1.3.2.2,SEAF仍会将RES*发送给AUSF进行归属网络验证,但最终会根据AUSF的响应决定是否发送Authentication Reject(如果初始用SUCI)或发起Identification过程获取SUCI重试(如果初始用5G-GUTI)。
Q3: null-scheme下的SUCI是否安全? A: 不安全。null-scheme(Protection Scheme ID=0x0)不提供任何隐私保护,SUCI等同于明文SUPI。仅当USIM未配置Home Network Public Key时才使用。运营商应确保所有USIM预置ECIES公钥。
Q4: K~AUSF~为什么需要存储在AUSF中? A: 用于后续的重认证优化——AUSF可基于存储的K~AUSF~执行后续认证,无需每次都访问ARPF。此外还用于Steering of Roaming(SoR)、UE Parameter Update(UPU)和AKMA等特性。但TS 33.501明确指出,基于存储K~AUSF~的认证安全性略弱于直接涉及ARPF/USIM的认证。
Q5: 5G密钥层级中NH链的作用是什么? A: NH(Next Hop)用于提供前向安全性。每次切换时,NH从K~AMF~或前一个NH推演(FC=0x6F),形成链式结构。即使当前K~gNB~泄露,攻击者也无法推算之前的密钥,因为NH推演是单向的。
本文由「51学通信」技术团队出品。51学通信由通信行业18年老兵爱卫生(微信ID: gprshome201101)维护,聚焦5G/6G核心网、3GPP标准解读、通信前沿技术深度分析。 出版作品有《5G核心网原理与实践》《IMS原理与实践》等4本通信专业书籍。知识星球「51学通信」提供深度技术答疑和行业洞察。
[!tip] 51学通信知识星球 星主:爱卫生(微信:gprshome201101)——公众号「51学通信」创办者,19 年通信行业运维与讲师经验,著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书(各大电商平台有售)。 星球定位:深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域,主打运维岗位与信令分析。 当前规模:5200 篇主题 / 990 个回答,198 元/年。 加入福利:加入星球后请加爱卫生微信,拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题,另有群内分享。 AI 加持:51学通信知识星球已作为 skill 接入 WorkBuddy,使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例,做总结、找文档和 PPT 等场景全覆盖。
