用技能包固化 AI 日志排障流程

把报错堆栈贴给 AI，往往很快就能得到一套解释。麻烦在于，它可能猜错技术栈、忽略版本，还把不完整的线索说成确定结论。作者开源的 ia-tools 尝试把日志分析变成固定流程：先识别技术，再补齐上下文，最后按统一结构交付诊断。

这套方案最值得借鉴的不是某条提示词，而是如何组织诊断知识、控制上下文，以及明确处理敏感数据的边界。它能让第一轮排查更规整，但原文没有提供准确率或耗时的对照实验。

先补齐环境信息，再让 AI 解释报错

作者列出的几个问题，程序员很容易遇到：助手默认某种技术和版本；同一个错误每次得到不同格式的回答；日志里混入 token 或个人信息却没人提醒；生产与开发环境的差异被直接跳过。

这些问题并不都来自模型能力不足。有时是输入缺了关键条件，助手却继续往下推理。

ia-tools 把分析拆成四步：根据日志模式识别技术，询问无法推断的环境、版本和服务器角色，加载对应技术的参考材料，再生成固定结构的报告。

固定流程的价值，是让缺失的信息先暴露出来。

例如，同一条连接失败日志，出现在开发机、生产应用节点或数据库服务器上，排查路径可能不同。作者要求助手主动询问这些信息，而不是靠日志里的几个词补出完整故事。

统一报告格式也有实际用途：不同事故的分析更容易比较，交给工单、运维或支持人员时，也少一轮重新整理。不过，原文没有展示报告模板，无法判断它具体要求保留哪些证据、怎样表达置信程度。

为什么要拆成入口 skill 和技术参考

按原文的组织方式，一项 skill 是一个包含 SKILL.md 的目录。助手在对话匹配其 description 时加载指令，也可以通过 /nombre 手动调用；较长的参考材料放在 references/，需要时再读取。

主入口 log-analyzer 负责识别技术、补问上下文和组织报告。具体知识则按技术家族拆分，覆盖 Azure、AWS、GCP，PostgreSQL、Oracle、SQL Server，以及 Docker、.NET、Kafka、Kubernetes、OpenShift、Laravel、PHP、Spring Boot、Quarkus、Web 服务器、Windows Event Log、MinIO、IBM API Connect 和 SRE 告警。

这相当于先确定该翻哪本手册，再打开相关章节。作者不希望把二十种技术的规则一次性塞进上下文，因为无关材料会占空间，也可能干扰当前指令。

这是一项合理的设计选择，但原文没有测量拆分前后的上下文消耗，也没有验证误判技术之后会怎样纠正。因此，「拆开更精准」目前仍是设计判断。

仓库还附带四个面向 Claude Code 的独立 agent，分别负责企业沟通、会议纪要、提取决策与任务风险，以及翻译校对和语气调整。它们是面向西班牙语团队的通用模板，不属于日志诊断的必经环节。

安装简单，数据边界需要自己守住

Claude Code 可以通过插件安装：

/plugin install ia-tools --marketplace ifirestone/ia-tools

要注意 --marketplace ifirestone/ia-tools，这是原文指定的插件市场来源。

Codex 和其他兼容环境则使用仓库脚本，把各项 skill 链接到本地 skills 目录：

./scripts/link-skills.sh

这行命令执行前要检查脚本：作者明确提醒，它会替换同名的已有 skill 文件夹。链接采用符号链接，因此之后执行 git pull 就能同步仓库内容。使用方便，也要求团队关注更新后的指令变化。

原文还给出了 ChatGPT 的替代用法：将 SKILL.md 内容放进 Project 或自定义 GPT 的指令，把参考材料作为知识文件上传。这是作者描述的接入方式，不能据此认为各环境的加载行为完全一致。

更有争议的是敏感信息策略：这些 skills 不会自动遮盖凭据、token 或个人信息，而是在报告中标红。作者的理由是，发现泄露后需要轮换凭据，静默隐藏可能让人忽略问题。

标出秘密的位置，并不会降低报告本身的敏感程度。

作者承认报告仍可能包含敏感数据，需要在分享前检查；生产日志也不应在没有组织授权时提交给外部工具。这里要区分两个目标：提醒发生泄露，以及避免秘密继续传播。原文的方案重点处理了前一个。

我的判断

这套方法最有说服力的地方，是把工程师已有的诊断步骤写成可共享的规则。相较于每次临时组织提示词，它更容易维持输入要求和输出格式；相较于一份巨大的提示词，按技术加载材料也更方便维护。

但「可重复」首先指流程和报告形式，不代表每次都能得到相同、正确的根因。作者没有提供对照数据，「先询问能避免大多数虚假自信回答」应当视为经验之谈。

敏感信息策略也不宜直接照搬。告警可以保留泄露类型和定位信息，待分享的报告则可以脱敏，两者能够同时成立。具体保留什么，需要服从团队的数据处理要求。

此外，参考材料会随版本和错误消息变化而过时，缺少根因附近日志的片段也很难支撑可靠结论。即便仓库以 MIT 开源，维护和验证的工作仍然需要团队承担。

能拿来做什么

• 给日常 AI 排障写一份固定入口指令，先确认运行环境、技术版本和服务角色，再要求助手提出诊断假设，并列出支持判断的日志证据。
• 从自己实际使用的技术开始拆参考资料，例如数据库、Docker 或 Kubernetes；为每份材料记录适用版本，避免一次引入整套技术目录。
• 将报告用于工单前，检查是否包含凭据、token 和个人信息；发现秘密泄露时，安排轮换，同时处理报告中的副本。
• 用历史事故检验这套流程，观察它是否会补问关键信息、是否漏掉根因线索，以及建议能否被验证，再决定是否纳入团队日常排查。