# 5G N4接口PFCP会话建立与PDR/FAR/QER/URR报文处理规则全链拆解 > 聚焦 3GPP TS 29.244，从 N4 会话建立信令到 UPF 数据面报文流水线，逐级解析 SMF 如何用四类规则把"一张白纸"的 UPF 编程为一台能检测、转发、限速、计费的智能转发引擎。 --- ## 一、N4接口在5G系统中的定位 5G 核心网最深刻的架构变革之一，就是**控制面与用户面的彻底解耦**：SMF（会话管理功能）只负责信令与策略决策，UPF（用户面功能）只负责高速数据转发。二者之间唯一的耦合点，就是 **N4 接口**。N4 上运行的协议是 **PFCP（Packet Forwarding Control Protocol，报文转发控制协议）**，由 TS 29.244 定义。 PFCP 的核心思想可以一句话概括：**SMF 不直接转发数据包，而是向 UPF 下发一组"规则（Rules）"，UPF 按规则自主处理每一个数据包。** 这种"规则下发 + 数据面自治"的设计，使 UPF 可以用硬件/DPU/SmartNIC/可编程交换芯片实现线速处理，而 SMF 完全不必关心每一帧报文。 理解 N4，必须先把它放回 PDU 会话建立的大流程里。根据 **TS 23.502 Section 4.3.2.2.1（UE-initiated PDU Session Establishment）**，N4 信令发生在 SMF 选定 UPF 之后、PDU Session Establishment Accept 下发之前。 ```mermaid sequenceDiagram autonumber participant UE participant RAN as (R)AN/gNB participant AMF participant SMF participant UPF participant PCF UE->>AMF: NAS PDU Session Establishment Request
(DNN, S-NSSAI, Request Type) AMF->>SMF: Nsmf_PDUSession_CreateSMContext
(SUPI, PDU Session ID, DNN) SMF->>PCF: Npcf_SMPolicyControl_Create
(获取PCC规则、QoS、计费) Note over SMF: 选定UPF(基于DNN/S-NSSAI/UL-CL) SMF->>UPF: PFCP Session Establishment Request
(Create PDR/FAR/QER/URR) UPF->>SMF: PFCP Session Establishment Response
(UPF分配的N3 F-TEID, Cause) SMF->>AMF: Nsmf_PDUSession_CreateSMContext Response
(含N2 SM信息:PDU Session Resource Setup List) AMF->>RAN: N2 PDU Session Resource Setup Request
(含QoS Flow、N3 TEID) RAN->>UE: RRC Reconfiguration + NAS
PDU Session Establishment Accept UE->>RAN: 上行数据(GTP-U, N3 TEID) RAN->>UPF: GTP-U上行报文(N3) Note over UPF: PDR匹配 → FAR转发 → QER限速 → URR计费 ``` 可以看到，**第 6 步的 PFCP Session Establishment Request 是整个会话能跑通数据的"点睛之笔"**——在这条消息之前，UPF 不知道该为谁服务、不知道收到的包该怎么处理；在这条消息之后，UPF 立即具备了对该 PDU 会话所有上下行报文的完整处理能力。 --- ## 二、PFCP消息结构与N4会话建立流程 ### 2.1 PFCP消息头（TS 29.244 Clause 6.1） 所有 PFCP 消息都遵循 **"固定头 + 可变 IE（Information Element）"** 结构。会话相关消息的头部包含一个关键的 **SEID（Session Endpoint Identifier，64位）**，它全局唯一标识一个 N4 会话——UPF 与 SMF 各持一端。 | 字段 | 长度 | 说明 | |------|------|------| | Version | 3 bit | 协议版本，当前为 `001` | | Flags（S/E/MP/V） | 4 bit | S=含SEID，E=含重建TEID，MP=含消息优先级 | | Message Type | 8 bit | 见下表 | | Length | 16 bit | 消息长度 | | SEID | 64 bit（条件存在） | N4会话端点标识，会话级消息必带 | | Sequence Number | 24 bit | 请求/响应配对 | | Message Priority | 4 bit | MP标志置位时存在 | ### 2.2 PFCP消息类型码（TS 29.244 Clause 7.1） 抓包识别 N4 流程时，**Message Type 字节是第一判据**。下表是 N4 会话生命周期中最常用的类型码： | 消息类型码 | 消息名称 | 用途 | |-----------|---------|------| | 50 | PFCP Session Establishment Request | SMF→UPF 创建 N4 会话 | | 51 | PFCP Session Establishment Response | UPF→SMF 应答（回带分配的 F-TEID） | | 52 | PFCP Session Modification Request | 会话修改（如切换、加 UL-CL） | | 53 | PFCP Session Modification Response | 修改应答 | | 54 | PFCP Session Deletion Request | 会话删除（PDU 会话释放） | | 55 | PFCP Session Deletion Response | 删除应答 | | 56 | PFCP Session Report Request | UPF→SMF 上报用量/事件（计费/通知） | | 57 | PFCP Session Report Response | 上报应答 | ### 2.3 N4会话建立时序与关键IE组 在 **TS 29.244 Clause 5.8.2（PFCP Session Establishment Procedure）** 中定义的流程，本质就是 SMF 把一个 PDU 会话"翻译"成一组规则，原子化地下发给 UPF： ```mermaid sequenceDiagram autonumber participant SMF participant UPF Note over SMF: 1.为UE分配UE IP地址
2.生成SEID(本地端+对端)
3.按PCC规则翻译为PDR/FAR/QER/URR SMF->>UPF: PFCP Session Establishment Request Note right of UPF: 消息体含IE组:
· Create PDR (一组)
· Create FAR (一组)
· Create QER (一组)
· Create URR (可选)
· Create BAR (可选)
+ UE IP Address / PDN Type / Node ID Note over UPF: 校验能力位、分配N3/N9 F-TEID、
安装规则到数据面、建立转发表项 UPF->>SMF: PFCP Session Establishment Response Note left of SMF: 含:
· Cause(成功/失败原因)
· UP F-TEID(UPF分配的TEID与IP)
· Created PDR(回带每个PDR的F-TEID)
· Usage Report(若已有用量) Note over SMF,UPF: N4会话激活,UPF可处理上下行报文 ``` 这里有一个常被忽略的设计要点：**F-TEID 由谁来分配？** 在 5G 中，N3 接口（RAN↔UPF）的 GTP-U TEID 通常由 **UPF 分配**并在 Establishment Response 中回带给 SMF，SMF 再通过 N2 消息（TS 38.413 的 PDU Session Resource Setup）传给 gNB。这意味着 SMF 在建立 N4 会话时，Create PDR 里的 F-TEID 字段会带上 `TEID-CHID/V4/V6` 标志，请求 UPF 分配——这就是为什么 `Created PDR` IE 必须出现在 Response 中。 --- ## 三、五大报文处理规则深度拆解 UPF 数据面的一切行为，都由五类规则驱动。它们之间通过 **Rule ID** 相互引用，形成一个 DAG（有向无环图）： ```mermaid flowchart TD PKT[上行/下行数据报文] --> PDR{PDR匹配
按Precedence} PDR -->|命中第一条| DET[检测成功
提取UE IP/TEID/SDF] DET --> FAR[FAR: Apply Action
转发/丢弃/缓存/复制] DET --> QER[QER: QoS执行
门控/限速/打QFI] DET --> URR[URR: 用量测量
统计流量/时长] FAR -->|FORW| OHCR[Outer Header
Creation
封装GTP-U] FAR -->|BUFF| BAR[BAR: 缓存控制
下行通知] QER --> MARK[打QFI/Reflective QoS] URR --> RPT[触发Session Report] OHCR --> OUT[送出N3/N9/N6] MARK --> OUT ``` ### 3.1 PDR——Packet Detection Rule（报文检测规则，Clause 5.2.1A） **PDR 是整个体系的"入口"。** UPF 收到任意一个报文，第一件事就是拿它去匹配一组 PDR，**以 Precedence 值最小（优先级最高）的那条命中规则为准**（Precedence IE 见 Clause 8.2.11）。 PDR 的灵魂是它内含的 **PDI（Packet Detection Information，报文检测信息）**，PDI 定义了"什么样的包属于我"： - **Source Interface**（Clause 8.2.2）：标识报文来自接入侧（Access/N3）、核心侧（Core/N9）、还是 N6。这是最粗粒度的分流。 - **F-TEID**：用于 GTP-U 隧道接入的检测——如果 UPF 是按 N3 隧道接入上行报文，PDI 就用 `(本地IP, 本地TEID)` 来匹配。 - **UE IP Address**：用于非 GTP 接入（如 N6 上行/以太网 PDU 会话）按内层 IP 检测。 - **SDF Filter（业务数据流过滤器）**：5/7 元组（协议、IP五元组）包过滤器，可实现应用级精细检测，引用 TS 23.501 的 QoS/计费规则。 - **Application ID**：基于 DPI 识别的应用。 除 PDI 外，PDR 还携带： - **Precedence**：决定匹配优先级，**值越小优先级越高**。这是 PDR 体系区别于传统 ACL 的关键——它是一个全局有序的匹配表。 - **Outer Header Removal**：告诉 UPF 在检测后剥掉哪些外层头（GTP-U/UDP/IP 或 VLAN），露出内层 payload 供后续 QER/URR 处理。 - **关联引用**：`FAR ID list`、`QER ID list`、`URR ID list`、`BAR ID`——PDR 是"枢纽"，通过这些 ID 把检测到的包路由到对应的执行规则。 ### 3.2 FAR——Forwarding Action Rule（转发行为规则，Clause 5.2.3） **FAR 回答"检测到的包要做什么"。** 核心字段是 **Apply Action**，取值见下表（第二张表）： - **FORW（Forward）**：转发。此时 FAR 必须携带 **Forwarding Parameters**，其中最关键的是 **Outer Header Creation**——它告诉 UPF 用什么外层头封装（N3/N9 用 GTP-U，需要写入对端 TEID、对端 IP、源 IP、QFI），以及 **Destination Interface**（Access/Core/SGi-LAN/N6 LAN）和 **Network Instance**（DNN）。 - **DROP**：直接丢弃（如策略拒绝、过载丢弃）。 - **BUFF（Buffer）**：缓存，配合 BAR 使用，典型场景是寻呼未完成时缓存下行数据。 - **NOCP（Notify CP）**：通知控制面——触发 UPF 向 SMF 发 PFCP Session Report（如检测到首个下行包需寻呼 UE）。 - **DUPL（Duplicate）**：复制，配合 **Duplicating Parameters**，用于合法拦截（LI）、双发选收（冗余传输）等场景。 ### 3.3 QER——QoS Enforcement Rule（QoS执行规则，Clause 5.4 / 5.2.4） **QER 负责质量保障：限速、门控、打 QFI。** 它实现了 TS 23.501 QoS 模型在用户面的最终落地点。关键字段： - **QFI（QoS Flow Identifier）**：在转发时封装到 GTP-U 扩展头或反射给 UE。 - **Gate Status（UL/DL）**：Open 允许通过，Closed 直接丢弃——这是计费策略中"流量暂停/恢复"的用户面抓手。 - **MBR（Maximum Bit Rate，上/下行）**：令牌桶限速，超出 MBR 的报文被丢弃（对 Non-GBR）或标记。 - **RQI（Reflective QoS Indication）**：指示 UE 反射派生 QoS 规则。 - **PPI（Paging Policy Indicator）**：影响寻呼优先级，与切片/业务优先级联动。 ### 3.4 URR——Usage Reporting Rule（用量报告规则，Clause 5.2.2） **URR 是计费与策略计费（PCC）的数据来源。** 它定义"测量什么、何时上报"。关键字段： - **Measurement Method**：VOLUME（字节数）、DURATION（时长）、EVENT（基于事件，如应用检测）。 - **Reporting Triggers**：触发上报的条件——`PERIO`（周期）、`VOLTH`（流量阈值）、`TIMTH`（时长阈值）、`VOL_QU/TIME_QU`（配额耗尽）、`LIUSA`（链路使用率）、`IPMJL`（立即上报）等。 - **Volume/Time Quota**：SMF 下发的配额；耗尽时 UPF 通过 PFCP Session Report（消息类型 56）向 SMF 上报并请求新配额。 - **Linked URR ID**：URR 之间可嵌套，实现分层统计（如子规则统计、父规则汇总）。 ### 3.5 BAR——Buffering Action Rule（缓存行为规则，Clause 5.2.5） **BAR 是 BUFF 动作的细节控制器。** 当 FAR 的 Apply Action 设为 BUFF 时，BAR 提供： - **Downlink Data Notification Delay**：下行数据通知的延迟参数。 - **Suggested Buffering Packets Count**：建议缓存的最大报文数（超出的丢弃）。 BAR 在寻呼场景中至关重要：当 UE 处于 CM-IDLE 状态且有下行数据到达，UPF 通过 NOCP + BAR 机制通知 SMF，SMF 触发寻呼，期间下行包缓存在 UPF。 --- ## 四、IE参数说明表（表1） 下表汇总四类核心规则的 IE 字段，便于协议开发与抓包对照： | 规则 | 关键 IE | 取值/含义 | 对应章节 | |------|---------|----------|----------| | **PDR** | PDR ID | 规则唯一标识（会话内唯一） | 8.2.6 | | | Precedence | 匹配优先级，**值越小越优先** | 8.2.11 | | | Source Interface | Access/Core/SGi-LAN | 8.2.2 | | | F-TEID | GTP-U隧道检测：本地IP+TEID | 8.2.4 | | | UE IP Address | 非GTP接入按内层IP检测 | 8.2.10 | | | SDF Filter | 五/七元组包过滤器 | 8.2.5 | | | Outer Header Removal | 剥离GTP/VLAN/UDP-IP | 8.2.30 | | **FAR** | FAR ID | 规则唯一标识 | 8.3.x | | | Apply Action | FORW/DROP/BUFF/NOCP/DUPL | 8.2.26 | | | Outer Header Creation | 转发封装：对端TEID/IP/QFI | 8.2.31 | | | Destination Interface | 出向接口 | 8.2.24 | | **QER** | QER ID | 规则唯一标识 | 8.4.x | | | QFI | QoS Flow标识 | 8.2.33 | | | Gate Status | Open/Closed（上下行） | 8.2.50 | | | MBR | 上/下行最大比特率 | 8.2.49 | | | RQI | 反射QoS指示 | 8.2.48 | | **URR** | URR ID | 规则唯一标识 | 8.5.x | | | Measurement Method | VOLUME/DURATION/EVENT | 8.2.43 | | | Reporting Triggers | PERIO/VOLTH/TIMTH/VOL_QU等 | 8.2.41 | | | Volume/Time Quota | 计费配额 | 8.2.44 | --- ## 五、FAR Apply Action取值与触发场景（表2） | Apply Action | 含义 | 典型触发场景 | 关联IE | |--------------|------|-------------|--------| | **FORW** | 转发报文 | 正常会话数据上下行 | Forwarding Parameters、Outer Header Creation | | **DROP** | 丢弃报文 | 策略拒绝、非法UE、过载 | （可选）Drop原因 | | **BUFF** | 缓存报文 | UE CM-IDLE、寻呼未完成 | BAR（缓存参数） | | **NOCP** | 通知控制面 | 首个下行包需寻呼、需策略决策 | 触发Session Report（type 56） | | **DUPL** | 复制报文 | 合法拦截（LI）、冗余传输 | Duplicating Parameters | > 设计意图：**FORW/DROP/BUFF 是互斥的"主动作"，NOCP/DUPL 可叠加。** 这种位图式编码使一条 FAR 可同时表达"转发 + 复制到LI接口"。 --- ## 六、报文处理流水线的设计哲学 理解了五类规则，再回头看 PFCP 的设计，会发现三个精妙的工程取舍： **第一，"枢纽-执行"解耦。** PDR 只管"检测和分流"，不关心"怎么处理"；FAR/QER/URR 只管"执行"，不关心"包从哪来"。PDR 通过 ID 列表把检测命中的包"扇出"到多个执行规则。这意味着同一条 QER（如限速 10Mbps）可被多个 PDR 引用，避免规则膨胀。 **第二，Precedence 全局有序匹配。** 与传统 ACL 的"first-match"不同，PFCP 用显式 Precedence 值排序。这解决了 UL-CL（上行分类器）分流场景的歧义：当上行包同时匹配"主会话 PDR"和"UL-CL PDR"时，Precedence 小的胜出，结果确定且可复现——这对运营商编排分流策略至关重要。 **第三，控制面无状态化与数据面有状态化。** SMF 永远不下发任何数据包，只在状态变化时下发/修改规则（增删改 IE 组用 `Create/Update/Remove` 前缀区分）。而 UPF 在数据面维护每条规则的有状态计数器（URR 的字节数/时长）。这种分工使 SMF 可以水平扩展到海量会话，UPF 可以下沉到边缘。 --- ## 七、N4会话状态机（状态转换图） ```mermaid stateDiagram-v2 [*] --> ESTABLISHED: Establishment Request成功
(Cause=Accept) ESTABLISHED --> MODIFIED: Modification Request
(加UL-CL/切换/QoS变更) MODIFIED --> ESTABLISHED: Modification Response成功 ESTABLISHED --> REPORTING: Session Report
(用量上报/事件) REPORTING --> ESTABLISHED: Report Response
(SMF下发新配额) ESTABLISHED --> DELETED: Deletion Request
(PDU会话释放) MODIFIED --> DELETED: Deletion Request DELETED --> [*]: 释放所有规则与TEID ESTABLISHED --> [*]: UPF故障/心跳超时
(隐式释放) ``` 状态机的核心是 **ESTABLISHED**——这是唯一能让数据正常转发的稳态。所有规则都挂在该会话下；一旦进入 DELETED，UPF 删除该 SEID 关联的全部 PDR/FAR/QER/URR，并释放 F-TEID。 --- ## 八、实战连接：抓包识别与故障排错 ### 8.1 抓包识别 N4 流程（TShark） N4 走 PFCP，**UDP，端口 8805**（多播发现用 224.0.0.250 / IPv6 ff02::a:b:c:d）。常用过滤器： ```bash # 1. 仅看PFCP tshark -i eth0 -Y "pfcp" -V # 2. 仅看某次会话建立(SMF→UPF的Establishment Request) tshark -i eth0 -Y "pfcp.msg_type==50" # 3. 追踪某个SEID的完整生命周期 tshark -i eth0 -Y "pfcp.seid==0x0000000000001234" # 4. 解析所有Create PDR/FAR并导出规则 tshark -r n4.pcap -Y "pfcp.msg_type==50 || pfcp.msg_type==51" \ -T fields -e pfcp.seid -e pfcp.msg_type -e pfcp.pdr_id \ -e pfcp.precedence -e pfcp.far_id -e pfcp.qer_id ``` `pfcp.msg_type==50` 是排查"会话是否真正建立"的最快手段。若只有 50 没有 51，说明 UPF 未应答（多半是规则校验失败或 UPF 资源不足）。 ### 8.2 常见故障点 | 现象 | 根因 | 排查思路 | |------|------|---------| | UE拿到IP但无法上网 | UPF 未收到/拒绝 N4 Establishment | 抓包看是否有 msg_type=51；Response 中 Cause 是否为 Accept | | 上行通、下行不通 | 下行 PDR 的 Outer Header Creation 中**对端N3 TEID/IP错** | 检查 Create FAR 的 Outer Header Creation 是否用了 gNB 给的 TEID | | 双向都不通 | PDR Precedence 配置冲突，命中错误 PDR | 导出 PDR 列表，按 Precedence 排序核对 Source Interface / F-TEID | | 限速不生效 | QER 未关联到 PDR（QER ID list 缺失），或 MBR 单位错误 | 确认 Create PDR 中 QER ID list 包含目标 QER | | 计费用量缺失 | URR 未配 Measurement Method 或 Triggers 永不满足 | 检查 Reporting Triggers 与 Quota 是否下发 | | 寻呼风暴 | BUFF+NOCP 配置错误，频繁触发 Session Report | 核对 BAR 的 Notification Delay 与缓存包数 | ## 常见问题 **Q1：PFCP 和 4G EPC 的 Sx 接口是什么关系？** A：PFCP 就是 CUPS（控制面用户面分离，TS 29.244 R14）引入的协议，4G 中 SGW-U/PGW-U 与 S/P-GW-C 之间也用 Sx/PFCP。5G 的 N4 直接沿用并扩展了 PFCP（增加 5G 特有 IE，如 QFI、S-NSSAI、UE IP 多归属）。因此 N4 与 4G Sx 在协议格式上高度兼容，差异主要在语义字段。 **Q2：为什么是 PDR 引用 FAR/QER/URR，而不是反过来？** A：因为数据面处理顺序是固定的：**先检测（PDR），再执行（FAR/QER/URR）**。PDR 作为入口枢纽，把"一个检测命中"扇出到"多个执行动作"，符合流水线方向。反向引用会破坏匹配的唯一性——一个 QER 可被多个 PDR 共用（限速规则复用），这是性能关键。 **Q3：Precedence 值到底怎么分配才合理？** A：原则是"越具体的规则优先级越高（值越小）"。例如 UL-CL 分流 PDR 的 Precedence 应小于主会话 PDR；每个应用级 SDF PDR 又小于 UL-CL PDR。运营商通常按 PCC 规则的优先级 + 业务类型分层映射，避免冲突时命中错误 PDR 导致数据走到错误隧道。 **Q4：URR 的配额耗尽后流量会断吗？** A：不会立即断。UPF 在配额耗尽时通过 PFCP Session Report 上报 SMF，SMF 向 CHF（计费功能）申请新配额。若申请成功，SMF 用 Session Modification 下发新 Quota，UPF 继续放行；若申请失败或信用耗尽，SMF 才通过 Modification 把 FAR 改为 DROP。这个"先报后断"机制保证了计费准确性。 **Q5：N4 会话修改和重新建立的区别？** A：Modification（msg_type=52/53）是**增量操作**，用 `Update/Remove` IE 组对现有规则做增删改，保留 SEID 与未变更的规则，开销小、速度快——切换、加 UL-CL、QoS 变更都用它。Establishment 是**全量创建**，用于会话首次建立。大量频繁变更若误用 Establishment，会导致 UPF 重建全部表项，严重浪费数据面资源。 --- ## 参考来源 1. [3GPP TS 29.244 — Interface between the Control Plane and the User Plane nodes](https://www.3gpp.org/dynareport/29244.htm) — N4/Sx接口PFCP协议主规范（Clause 5.2.1A PDR、5.2.3 FAR、5.2.4 QER、5.2.2 URR、5.8.2 会话建立流程、8.2.11 Precedence） 2. [3GPP TS 23.502 — System procedures](https://www.3gpp.org/dynareport/23502.htm) — Section 4.3.2.2.1 UE-initiated PDU Session Establishment（N4步骤定位） 3. [ETSI TS 129 244 V17.5.0 PDF](https://www.etsi.org/deliver/etsi_ts/129200_129299/129244/17.05.00_60/ts_129244v170500p.pdf) — 规范全文PDF，含完整IE编码图 4. [华为云社区：5GS协议栈 PFCP PDR/FAR 报文检测与转发规则](https://bbs.huaweicloud.com/blogs/detail/291466) — PDR/FAR 字段中文详解（对应 Clause 5.2.1A / 5.2.3） 5. [free5GC PFCP Software Architecture within UPF](https://free5gc.org/doc/Upf_PFCP/design/) 与 [PFCP Session Lifecycle](https://free5gc.org/blog/20260204/20260204/) — 开源UPF实现视角的规则安装与报文处理流水线 6. [DeepWiki: Packet Forwarding Rules (PDR/FAR/QER/URR/BAR) — open5gs](https://deepwiki.com/open5gs/open5gs/5.1.2-packet-forwarding-rules-(pdrfarqerurrbar)) — open5gs 数据面规则应用实现 --- > 本文由「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 等场景全覆盖。