云产品诊断架构设计：路由 + 分层加载方案实践

一、为什么云产品诊断越来越难

[1. 产品数量多](#1. 产品数量多)

[2. 故障现象相似，但根因不同](#2. 故障现象相似，但根因不同)

[3. 诊断依赖多种证据](#3. 诊断依赖多种证据)

二、设计目标

[1. 提升诊断准确率](#1. 提升诊断准确率)

[2. 控制上下文成本](#2. 控制上下文成本)

[3. 降低维护难度](#3. 降低维护难度)

[4. 支持持续扩展](#4. 支持持续扩展)

[三、三层诊断 Skill 设计](#三、三层诊断 Skill 设计)

[1. 一级：通用诊断 skill](#1. 一级：通用诊断 skill)

[2. 二级：类目诊断 skill](#2. 二级：类目诊断 skill)

[3. 三级：产品特有规则](#3. 三级：产品特有规则)

[四、路由 + 分层加载的整体流程](#四、路由 + 分层加载的整体流程)

五、为什么不能一次性加载全部规则

[1. 上下文会迅速膨胀](#1. 上下文会迅速膨胀)

[2. 规则之间容易干扰](#2. 规则之间容易干扰)

[3. 维护难度高](#3. 维护难度高)

六、信息不足时怎么办

[七、Skill 的目录结构怎么设计](#七、Skill 的目录结构怎么设计)

八、技能内容建议结构化

九、推荐的落地路径

[第一阶段：先做通用诊断 skill](#第一阶段：先做通用诊断 skill)

[第二阶段：按类目沉淀 skill](#第二阶段：按类目沉淀 skill)

在面向 160 款云产品的诊断场景中，最棘手的问题往往不是模型能力不足，而是诊断知识过多、产品差异太大、上下文无法一次装下。如果把所有产品的规则、错误码、阈值、配置项都一次性塞给模型，短期看似简单，长期却很容易带来三个问题：

上下文膨胀
规则相互干扰
维护成本极高

因此，更合理的做法不是"把所有知识都给模型"，而是让模型在正确的时机加载正确的知识 。本文介绍一种适合大规模云产品诊断的设计方式：路由 + 分层加载。

一、为什么云产品诊断越来越难

云产品诊断之所以复杂，主要来自三个维度。

1. 产品数量多

160 款产品意味着 160 套差异化逻辑。即便它们属于同一技术体系，也会在错误码、接口行为、配置项、容灾机制上存在差异。

2. 故障现象相似，但根因不同

例如"超时""失败""不可用"这类现象，在不同产品上对应的原因可能完全不同。

同样是上传失败，可能是：

权限问题
配额问题
网络问题
服务端异常
配置错误

3. 诊断依赖多种证据

真正有效的诊断，不只看现象，还要结合：

日志
指标
配置
拓扑
调用链
环境状态

如果没有清晰的知识组织方式，模型很容易"知道很多，但判断不稳"。

二、设计目标

一个可落地的大规模云产品诊断体系，至少要满足以下目标：

1. 提升诊断准确率

让模型在正确的知识范围内推理，减少误判。

2. 控制上下文成本

避免一次性加载所有规则，节省 token 和推理开销。

3. 降低维护难度

新增产品或修改规则时，不影响整体体系。

4. 支持持续扩展

随着产品数量增长，体系仍能平滑扩容。

三、三层诊断 Skill 设计

这套方案的核心，是把诊断能力拆成三层。

1. 一级：通用诊断 skill

一级 skill 解决的是"怎么诊断"的问题，而不是"诊断哪个产品"的问题。

它通常包含：

故障现象分类
影响范围判断
信息补全策略
日志/指标/配置的通用检查方法
根因分析框架
标准输出模板

通用诊断 skill 的作用，是把模型拉到统一的方法论上。

2. 二级：类目诊断 skill

二级 skill 解决的是"这类产品通常怎么诊断"的问题。

例如：

存储类
网络类
计算类
数据库类
中间件类

不同类目有不同的共性逻辑。

例如存储类产品通常会关注：

鉴权
容量
副本
一致性
读写路径
可用区
延迟

类目 skill 的价值在于沉淀领域共性，让模型先进入正确的大方向。

3. 三级：产品特有规则

三级 skill 负责解决"这款具体产品有什么特殊规则"的问题。

例如：

特有错误码
特有阈值
特有配置项
特有 API 行为
特有修复步骤

这一层不追求通用，只追求准确。它是类目规则的补充，也是最终定责的重要依据。

四、路由 + 分层加载的整体流程

这套方案最关键的不是"有哪些 skill"，而是什么时候加载哪一层 skill。

推荐流程如下：

复制代码

用户输入
  ↓
问题预处理
  - 提取产品名、类目、版本、现象、错误码、日志线索
  ↓
一级路由：判断是否为诊断请求
  - 是故障排查 / 配置问题 / 使用问题 / 信息不足
  ↓
二级路由：识别产品类目
  - 存储 / 网络 / 计算 / 数据库 / 中间件 ...
  ↓
加载一级 skill
  - 通用诊断方法
  - 通用输出模板
  ↓
加载二级 skill
  - 类目级常见故障模式
  - 类目级检查项
  ↓
三级路由：识别具体产品
  - 产品A / 产品B / 产品C
  ↓
按需加载三级规则
  - 特有错误码
  - 特有阈值
  - 特有配置项
  - 特有处理步骤
  ↓
综合推理
  - 结合现象、日志、指标、配置、拓扑
  ↓
输出结果
  - 结论
  - 依据
  - 下一步验证
  - 修复建议

可以看到，这套架构的核心思想是：
先收敛问题范围，再注入细节知识。

五、为什么不能一次性加载全部规则

很多人第一反应是：既然最终都要用到知识，那能不能一口气全喂给模型？

从工程实践看，这通常不是好办法。

1. 上下文会迅速膨胀

160 款产品的规则量非常大，全部加载会占用大量上下文窗口，导致真正关键的信息被冲掉。

2. 规则之间容易干扰

不同产品可能有相似现象，但对应逻辑不同。

如果模型同时看到太多类似规则，容易混淆。

3. 维护难度高

一旦某个产品更新规则，你可能要重新整理整套大 Prompt。

这会让版本管理和灰度发布变得很困难。

因此，更合理的方式是：按需加载、逐层注入、局部生效。

六、信息不足时怎么办

真实场景里，用户经常只给一句模糊描述，例如：

"上传失败了，帮我看下。"

这时不要急着加载大量产品规则，因为连产品、版本、现象都不完整。

更合理的做法是先追问关键字段：

产品名
版本
错误码
发生时间
是否可复现
日志信息
影响范围

也就是说，路由的第一步不一定是加载知识，也可能是补齐诊断输入。

七、Skill 的目录结构怎么设计

为了便于维护，建议把知识按目录拆分。

复制代码

diagnosis-skills/
  ├── common/
  │   ├── diagnosis-principles.md
  │   ├── output-format.md
  │   └── evidence-collection.md
  ├── category/
  │   ├── storage/
  │   ├── network/
  │   ├── compute/
  │   └── database/
  ├── product/
  │   ├── product-a/
  │   ├── product-b/
  │   └── product-c/
  └── router/
      ├── category-router.yaml
      └── product-router.yaml

这种结构的好处是：

易维护
易扩展
易检索
易版本管理

新增产品时，只需要：

归类到某个类目
补充产品特有规则
更新路由配置

不需要改动全局诊断逻辑。

八、技能内容建议结构化

如果规则只是写成大段自然语言，后续检索和拼装会比较困难。

更好的方式是把规则结构化，例如 YAML 或 JSON。

示例：

复制代码

product: xxx-storage
version: v2
symptoms:
  - upload_failed
  - auth_error
checks:
  - name: auth_check
    condition: error_code == 403
    action:
      - check_ak_sk
      - check_token_expire
      - check_policy
root_causes:
  - permission_denied
  - signature_expired
  - bucket_policy_restricted

结构化表达的优势在于：

更容易检索
更容易拼装
更容易自动化调用
更容易演进为规则引擎

九、推荐的落地路径

如果你要真正落地这套体系，我建议按以下顺序推进。

第一阶段：先做通用诊断 skill

先统一诊断流程、输出格式、信息补全策略。

第二阶段：按类目沉淀 skill

优先覆盖高频类目，例如存储、网络、数据库。

第三阶段：逐步补产品规则

从高频产品开始，逐个补齐产品特有逻辑。

第四阶段：接入检索和工具

让模型可以按需读取知识，并调用日志、监控、配置查询工具。

这一步很重要，因为真正的诊断不只是"会推理"，还要"会取证"。

十、一个简单示例

假设用户输入：

"XX 存储产品上传失败，报错 403。"

系统可以按如下流程工作：

识别为诊断请求
路由到存储类
加载通用诊断 skill
加载存储类 skill
识别具体产品 XX
加载 XX 产品的 403 特有规则
输出排查建议，例如：

- 检查鉴权
- 检查 AK/SK 或 Token
- 检查权限策略
- 检查签名是否过期
- 检查 bucket policy 是否限制访问

这种方式的优点是，模型先看到了"该怎么诊断"，再看到了"该类产品怎么诊断"，最后才看到"这个产品有什么特殊规则"。

十一、总结

对于 160 款云产品的诊断场景，最优解不是一次性加载全部知识，而是通过"路由 + 分层加载"实现按需诊断。

你可以把这套体系理解为：

通用 skill：统一诊断方法
类目 skill：沉淀领域共性
产品规则：补齐产品差异
路由机制：决定加载什么
工具调用：负责取证和验证

这种设计的核心价值在于：

更稳
更省上下文
更易维护
更适合大规模产品体系