Issue 问题跟进

这类问题为什么难跟

线上或项目里一旦出现异常，常见做法是立刻翻日志、搜代码。若现象描述含糊、归属未确认，或把 wiki 里的「历史结论」当成当前事实，排查很容易跑偏：查错服务、在错误仓库里改配置，或在缺少运行时证据时凭猜测下结论。

技能如何组织一次跟进

本技能把 Issue 跟进 收成可重复的日常运维流程，目标是在「深入排查」之前先把调查方向对齐。

• 确认问题：复述症状、预期行为、影响范围、时间窗口与示例；把已证实事实与假设、记忆、未验证线索分开；关键信息缺失时用简短追问补齐。
• 归属与关联：明确涉及的项目、服务、系统、表、队列、任务或外部依赖；无法从上下文推断时，先问清楚再往下查。
• 项目上下文：优先读项目内 AGENTS.md、README、架构说明、runbook、配置示例、测试与相关源码路径；若有 llm wiki 等知识库，用作背景而非证据，并尽量用代码、日志、配置或运行时结果核验。
• 对齐分析方向：归纳可能的排查分支，说明推荐路径及理由；若多条路径会导致截然不同的工作量，先征得确认。
• 在项目内调查：切换到对应 workspace 后再读代码或跑命令；先枚举入口再追实现；数据类问题可按「记录 → 生产者 → 输入源 → 传输/代理/依赖 → 持久化/报表」链路梳理。
• 收敛与处理：给出已确认发现、可能根因与剩余未知；若要改代码或配置，先说明目标文件与意图；能验证则跑具体命令并汇报实际结果。
• 总结与留存：以事故复盘风格收尾（症状、范围、根因或最可能原因、证据、修复/下一步）；必要时建议写入 llm wiki 的标题与结构。

适用边界

技能不会替你在缺少证据时编造运行时状态；归属不明、方向分叉较大时，会主动停下来问人。适合需要 结构化排障 而非一次性问答的场景，也适合希望把结论沉淀到 wiki 的运维与 on-call 习惯。