用途
Systems Analyst 是一个面向复杂分布式系统、陌生代码库和技术工具链的分析专家技能。它的目标不是罗列功能，而是把不熟悉的系统转化为清晰、可导航的知识，帮助使用者理解系统为什么存在、数据如何流动、信息在哪里丢失，以及当前架构能回答和不能回答哪些问题。
核心思路
每次分析都从同一个根问题出发：“如果这个组件不存在，谁会受影响，为什么？”这个问题迫使每个工具和服务先以人的语言被理解，再进入技术语言，避免只列功能而不解释用途。
主要能力
该技能提供一套五层分析框架，按顺序应用：
- 找到痛点：在阅读配置之前，先识别系统或组件解决的人类问题，例如“没有它，团队就得手动做什么”“它一旦坏掉，谁会感到痛苦”。
- 识别数据形态：判断组件产生、消费或转换的数据属于四种形态中的哪一种——随时间变化的数值、事件流、请求树、状态快照。数据形态决定了可能的查询与关联方式，也决定了盲点。
- 追踪数据流并找出断点：从数据产生到查询，映射完整生命周期，识别数据消失、未被采集或无法关联的每个点，并按严重程度分类：关键、高、中、低。
- 区分信封与内容：区分平台生成的基础设施遥测（信封，如请求到达、响应耗时、状态码）与应用生成的遥测（内容，如数据库查询、置信度分数、LLM 消耗的 token）。信封告诉你“有问题”，内容告诉你“为什么有问题”。
- 应用三级侦探测试：验证可观测性栈能否回答三个层次的诊断问题——第一级“系统健康吗”（指标/数值），第二级“哪里不健康”（追踪/树），第三级“为什么不健康”（日志/事件）。当三层连通时，还能获得第四级能力：展示证据链。
使用方式
当被要求分析系统或解释技术领域时，按上述六步流程执行：找到痛点、识别数据形态、追踪数据流、区分信封与内容、应用三级侦探测试、产出结果。产出时根据受众选择格式：工程师学习新系统适合带 ASCII 图和具体示例的学习文档；团队决定下一步建设适合按严重程度排序的缺口表和目标架构图；正在调试的工程师适合特定请求类型的数据流追踪；管理者理解投资适合用平实语言写成的前后能力对比表。
适用场景
该框架不限于可观测性，也适用于 CI/CD 流水线、数据库架构、组织结构等任何复杂系统。例如分析 CI/CD 时，痛点是“构建失败但没人知道原因或哪一步失败”，数据形态是带状态和时长的作业执行事件流，断点可能是测试日志未采集、缺少制品血缘。
限制
资料未提供该技能的具体安装方式、运行环境、依赖条件、收费模式或平台支持信息。该技能本身是一个分析框架，不直接执行代码或修改系统。