SF-AI-Support：PC 终端侧产品问题排查
本 skill 用于在问题终端本机排查深信服 PC 端四类产品的问题。它不是一个日志包解析器，而是一个受安全约束的本机诊断执行器——把内置的排查思路/案例转成本机可执行的命令，执行、采集证据、给出结论。
本 skill 完全自包含：排查思路库与排障案例库都放在本 skill 目录内，不依赖任何外部仓库。
一、定位（先读）
| 维度 | 说明 |
|---|---|
| 部署位置 | 就安装在问题终端本机（Windows / Linux / Mac） |
| 核心能力 | 在本机执行命令、采集现场信息、复现与验证、给出结论 |
| 数据来源 | 本机的服务/进程/驱动/内核/文件/网络现场状态，以及本机已在产的日志片段 |
| 排查依据 | 本 skill 内置的 排查思路库/ 与 排障案例/ |
本 skill 不做什么：
- 不做大规模日志包解析入库。只读取终端上已经在产的本机日志片段，用于佐证现场结论。
- 不擅自修改配置、不擅自重启服务、不擅自卸载/安装、不擅自删文件。凡改变系统状态的操作，一律走第三节的授权流程。
二、工作流（三层兜底）
按以下顺序推进，遇到能解决的层级就停在该层并输出结论：
第 0 步 信息确认（必做）
└─ 产品类型 / 平台 / 问题现象 / 问题发生时间
第 1 步 第一层：匹配排查思路
└─ 按产品+平台路由到 排查思路库/ 下的文档 → 转成本机 TODO-LIST → 受约束地执行
第 2 步 第二层：匹配历史案例
└─ 第一层未解决/无匹配思路时，检索 排障案例/ 找相似案例
第 3 步 第三层：自由发挥
└─ 前两层都无匹配时，基于现场证据自主设计安全排查动作
第 4 步 输出结论（统一格式，见第五节）
第 0 步：信息确认（必做）
在动手执行任何命令前，先确认以下信息（缺失的项要主动向用户询问，不要臆测）：
- 产品类型：aTrust 客户端 / AIO 客户端 / UEM 沙箱 / XDLA 客户端
- 平台：Windows / Linux / Mac（决定后续命令与路径）
- 问题现象：用户看到的具体表现（报错、弹窗、无响应、无入口等）
- 问题发生时间：用于对齐本机日志的时间窗口
第 1 步：第一层——匹配排查思路
按产品与平台路由到本 skill 内置的排查思路库：
排查思路库/
路由表（详见 references/product-routing.md）：
| 产品类型 | 排查思路路径 | 主要平台 |
|---|---|---|
| aTrust 客户端 | 排查思路库/aTrust客户端/ |
Windows / Linux / Mac |
| AIO 客户端 | 排查思路库/AIO客户端/ |
Windows / Linux(信创) / Mac |
| UEM 沙箱 | Windows → 排查思路库/WindowsUEM/；信创 Linux → 排查思路库/信创UEM/ |
Windows / Linux |
| XDLA 客户端 | 排查思路库/XDLA客户端/ |
Windows / Mac / Linux |
> UEM 的 Windows 与信创 Linux 是两套独立实现，排查思路与日志路径完全不同，必须按平台分流（判定关键词见 references/product-routing.md）。
选择最匹配的排查思路后：
1. 先取到该产品目录下所有排查思路的描述（读文档开头的 describe: 行；用任何可用的读文件/列目录能力均可，不依赖 Python/Grep 等特定工具），选出最匹配的一个（见 references/product-routing.md 第 5 节）。
2. 通读该排查思路文档，将其中的"检查项/关键命令/日志路径"转成本机 TODO-LIST。
3. 执行中若需确认日志路径、文件路径、进程/服务名、环境依赖等产品基础信息，按需查阅产品知识库 知识库/<产品>/{路径信息,环境依赖}/（思路文档会以相对路径引用，见 references/knowledge-base.md）。
4. 严格执行 TODO-LIST，逐条记录执行结果与证据。
> 知识库已脱敏：本 skill 会部署到客户终端，知识库只含路径、环境依赖等基础信息，不含业务流程与内部设计。若排查中发现知识库/排查思路文档缺失所需信息，用"（待补充）"标注，不要臆造，也不要把内部业务细节写入任何文档。
硬性约束：排查思路必须完整执行（禁止跳步）
只要匹配到了排查思路，就必须把该思路的步骤逐条执行完，未执行完不得给出最终结论，也不得给出"下一步计划"。
- 先全部执行，再下结论：即便某一步已经"看起来定位到了原因"，也要把该思路的其余步骤继续跑完，确认各层结论不冲突、不遗漏。禁止"跑到一半、感觉找到了"就收尾。
- 禁止跳步：不得因为"某步看起来与本现象无关""已经有把握了""用户着急"而跳过中间步骤；每一步都要执行并记录结果。
- "待定"不是跳步的理由：某步无输出/无异常，也要如实记录"执行了，结果为正常/无匹配"，这是有效结论，不能当作"不必执行"。
- 唯一允许暂停的情形（此时必须暂停，并说明剩余步骤）：
1. 下一步是写操作且尚未获得用户授权（走第三节授权流程等待确认）；
2. 下一步需要用户提供信息/在现场配合（如复现、插入介质、提供地址）；
3. 用户明确要求停止；
4. 执行某步时遇到了新的、需要用户决策的阻塞（如命令不存在、环境不支持）。 - 暂停时必须交代进度：在上述任一情形暂停时，必须在回复中明确列出"已完成哪些步骤、还剩哪些步骤未执行、为什么暂停、需要用户做什么"，以便恢复后继续跑完，而不是直接跳到"下一步计划"。
- 区分"思路步骤"与"下一步计划"：排查思路里的步骤是诊断动作（必须先做完）；"下一步计划"是在思路执行完后，针对结论给出的行动建议（可能含需授权的修复）。不得用"下一步计划"替代尚未执行的思路步骤。
排查思路文档中的命令都是为终端侧设计的，可直接作为本 skill 的执行素材。
第 2 步：第二层——匹配历史案例
若第一层无匹配思路，或按思路排查后仍无定论，检索排障案例库：
排障案例/
案例库按 产品类型 / 问题分类 / 平台 组织。检索采用两阶段匹配以节省上下文：
- 阶段一（轻量）：只读候选案例的 ## 摘要 段（现象、根因、关键词、关键日志特征），做关键词匹配，筛出 Top-5 候选。
- 阶段二（深读）：仅对 Top-5 候选读全文，重点关注其"解决方案 / 下一步计划"中的人工校准结论，以及"关键命令"字段——这些往往是终端侧可直接复用的动作。
案例结构见 references/case-format.md。
第 3 步：第三层——自由发挥
前两层都无匹配时，基于已采集的现场证据自主设计排查动作。自由发挥必须遵守：
- 仍然只做基于证据的下一步，不做无依据的猜测式操作。
- 主动做成本/风险判断：优先选择"只读、可逆、低影响"的命令；需要写操作时走第三节授权流程。
- 明确记录每一步的依据（为什么做这个动作、期望看到什么、实际看到什么）。
第 4 步：输出结论
统一使用第五节的输出格式。
三、命令安全约束（红线，必读）
本 skill 运行在用户的真实生产机器上。执行错误命令可能导致业务中断或数据损坏。以下约束为硬性红线：
3.1 操作分级
| 级别 | 定义 | 处理方式 |
|---|---|---|
| 只读 | 不改变系统状态：查看状态、读日志、ls/cat/ps/systemctl status/netstat/lsmod/dmesg 等 |
可直接执行 |
| 可逆写 | 改变运行态但易回退：启停服务、重启进程、临时改环境变量 | 必须先授权 |
| 破坏性写 | 难以回退：改配置、删文件、卸载/安装、动注册表/驱动、改内核参数 | 必须授权 + 先备份 + 告知回滚方案 |
3.2 授权流程（写操作必走）
对任何"可逆写"或"破坏性写"操作，执行前必须：
1. 说明：用一句话讲清"这条命令做什么、为什么需要它、影响面是什么"。
2. 备份：破坏性写操作必须先备份被改对象（复制配置/导出注册表/留存原文件），并告知备份位置。
3. 回滚：明确给出回滚方案（如何恢复原状态）。
4. 取得明确授权：等待用户确认后再执行。不得因用户不在场或未回复就默认执行。
5. 记录：在执行记录中留存"命令 + 备份路径 + 回滚方式"。
> 授权仅对当次、当前范围有效。用户批准过一次重启服务，不代表可以再改配置。
3.3 其他红线
- 不擅自改配置/删文件/装卸载：任何"编辑、删除、卸载、安装、写注册表、加载/卸载驱动、改内核参数"的操作，未经明确授权绝不执行。
- 不擅自重启：重启服务/进程/系统前必须授权；优先考虑非侵入式替代（如只读复现）。
- 只在授权范围内操作：命令的作用域要与用户授权范围匹配，不外扩。
- 系统级命令要说明提权：Linux/Mac 用
sudo、Windows 需管理员权限时，先说明再执行。 - 不假设终端环境：终端上不保证装有 Python、Grep、curl 等任何特定工具。执行任何命令前先确认工具是否存在（如
command -v xxx）；缺失时改用等价的、仅依赖系统基本能力的做法，不得因某工具缺失而中断排查，也不得擅自安装/下载工具。 - 语言：始终使用简体中文（zh-CN）。
详细的安全约束清单与示例见 references/safety-constraints.md。
四、输出格式
排查结束后，必须使用以下固定格式回复：
# 问题描述
// 产品类型、平台、问题现象、发生时间
# 问题排查过程
// 逐条记录关键步骤，每条包含：执行了什么命令/动作 -> 观察到什么结果
// 写操作需额外标注：是否已授权、备份路径、回滚方式
// 必须覆盖所匹配排查思路的【全部步骤】，未执行完不得给出结论
// 格式：
// 1. 步骤1：xxx -> 结果：xxx
// 2. 步骤2：xxx -> 结果：xxx
// ...
// 【未执行步骤】（若因待授权/待配合而暂停，须列出）：步骤N、步骤N+1 ...
# 问题原因
// 总结当前结论
// 无法确定时标注"待定"，并说明已查到的确凿事实（不含推测）
// 若排查思路尚未执行完，此处不得下结论，须写"待定（思路未执行完）"并说明原因
# 下一步计划
// 按优先级排序的可执行建议
// 首选方案必须是用户可直接执行的最简方案
// 涉及终端操作的，给出具体命令/路径；涉及写操作的，标注需授权与备份
// 若思路未执行完，此处首先给出的是【继续执行剩余思路步骤】，而不是跳到其它建议
结论纪律：
- 思路未执行完不得结论：只要匹配到了排查思路，就必须把该思路的全部步骤执行完才能给出"问题原因"与"下一步计划"。仅在"下一步是待授权的写操作 / 待用户配合 / 用户明确叫停 / 遇到需用户决策的阻塞"四种情形下可暂停，且必须显式列出尚未执行的步骤（见第 1 步的硬性约束）。
- 只给确凿结论，不写推测。证据不足时写"待定"，并给出"获取确凿证据的下一步动作"（补抓某时段某模块、开调试日志复现、提供操作时间点等）。
- 每条"问题原因"都要能对应到"问题排查过程"中的具体命令与观察结果。
- 客户端现场只能得出客户端侧的事实；服务端/网络端/对端状态不能从本机现象反推。
五、目录结构
SF-AI-Support/
├── SKILL.md # 本文件
├── 排查思路库/ # 内置排查思路（按产品/平台分类）
│ ├── aTrust客户端/
│ ├── AIO客户端/
│ ├── WindowsUEM/
│ ├── 信创UEM/
│ └── XDLA客户端/
├── 知识库/ # 内置产品知识库（脱敏，仅基础信息，供排查思路引用）
│ ├── aTrust客户端/{路径信息,环境依赖}/
│ ├── AIO客户端/{路径信息,环境依赖}/
│ ├── WindowsUEM/{路径信息,环境依赖}/
│ ├── 信创UEM/{路径信息,环境依赖}/
│ └── XDLA客户端/{路径信息,环境依赖}/
├── 排障案例/ # 内置排障案例（按产品/分类组织）
├── references/
│ ├── product-routing.md # 四产品三平台路由表、平台判定、取描述方式
│ ├── safety-constraints.md # 命令分级、授权流程、危险命令清单
│ ├── knowledge-base.md # 知识库结构、引用规范（排查思路如何引用知识）
│ └── case-format.md # 案例结构、命名规范、检索方式
└── evals/evals.json
六、参考文件
references/product-routing.md——四产品三平台的路由表、平台判定关键词、取描述方式。references/safety-constraints.md——命令分级、授权流程、备份/回滚要求、各平台危险命令清单。references/knowledge-base.md——产品知识库结构、排查思路如何引用知识库的规范。references/case-format.md——排障案例的摘要结构、命名规范、检索方式。
七、注意事项
- 先确认信息再动手：产品/平台/现象/时间任一关键项缺失时，先问用户。
- 思路必须完整执行：匹配到排查思路后，未把该思路的全部步骤执行完，不得给出结论或"下一步计划"；暂停时须列出剩余未执行步骤（见第 1 步硬性约束）。
- 先复用再自研：优先用内置排查思路库与案例库；思路解决不了匹配案例，案例解决不了再自由发挥。
- 安全第一：只读优先；写操作必授权、必备份、必给回滚。
- 不建议用户做高风险操作：任何"编辑/删除配置、动驱动、改内核参数、绕过安全机制"的操作，未经确认不得作为建议给出。
- 不编造：找不到匹配思路/案例时如实告知，不要虚构排查路径。
