multi-capability-bug-closure

---

name: multi-capability-bug-closure description: >- 统一调用源码、数据库、服务器日志、软件平台查询等多能力体系进行 BUG 定位与闭环论证。用于用户要求“必须基于真实数据给出结论与证据链”，而非仅代码静态分析的场景。

---

多能力体系 BUG 定位闭环技能

适用场景

当用户要求：

主动调用现有能力体系完成定位

提供数据库与服务器日志等真实证据

输出可复核的结论与根因

形成“定位 -> 论证 -> 结论 -> 建议”的闭环

本技能必须优先使用真实运行数据，不得仅基于代码阅读直接定论。

强制指导提示词（原文保留）

> 我的意思是你积极主动调用目前的能力体系，你自己完成问题定位和证据论证（最好有实际的数据库与服务器数据支撑），再给出结论与原因，而不是仅查看代码就完成定论。你不是已经可以查看数据库、服务器日志、软件平台实际查询操作了吗？请自我完成定位闭环，我只在乎你最终提供的问题定位结论和证据支撑。

---

执行前置：四能力体系可用性检查（必须）

每次执行前，必须验证以下四项是否同时具备且可读：

1. 源码文件能力（便于 AI 理解与定位） 2. 数据库读取能力（便于真实数据验证） 3. 服务器日志下载与分析能力（便于时序与行为证据） 4. 软件平台操作查询能力（便于业务侧联动验证）

检查标准

源码文件能力：可在当前工作区读取相关代码文件（至少 1 个核心路由/服务文件）。

数据库读取能力：可成功执行 1 条只读 SQL（如 select 1）。

服务器日志能力：可读取日志技能配置并成功访问目标日志目录或样本日志。

软件平台查询能力：对应平台 Skill 可读，且其文档/接口说明可读取。

缺失能力时的提示与推荐（必须提示用户）

若任一能力缺失，先提示“能力不完整，无法保证证据闭环”，并给出补充建议：

源码文件：请直接提供项目源码上下文或关键目录

数据库读取能力：补充对应服务的 MCP（Postgres/SQLite/Redis 等）

服务器日志下载并分析能力：安装或补充 server-log-analysis

软件平台操作查询能力：补充对应业务平台的查询 Skill 或 MCP 工具

能力未补齐前，不给“最终根因定论”，仅给“当前证据不足清单”。

---

标准工作流（必须执行）

1. 问题结构化 - 抽取时间窗口、服务名、错误关键词、对象标识（SN/ID/traceId）。 2. 日志侧取证（服务器） - 在目标时间窗口拉取原始日志。 - 统计异常频次、对象分组、连续性（是否持续复现）。 3. 数据库侧取证 - 查询对象在关键表中的存在性、关联关系、状态、时间戳。 - 必要时跨库交叉验证（access/cloud/data）。 4. 代码侧定位 - 定位异常枚举、抛出路径、路由与分支条件。 - 只用于解释机制，不替代真实数据结论。 5. 平台侧验证 - 用平台 Skill 验证接口/对象状态、业务配置是否匹配。 6. 证据链合并 - 按“日志证据 -> 数据库证据 -> 代码机制 -> 平台验证”串联。 7. 输出结论 - 区分：数据问题 / 代码问题 / 配置问题 / 环境问题。 8. 给出修复建议与复验标准 - 明确可执行步骤与“修复完成判定条件”。

---

输出模板（必须）

## 问题摘要
[一句话说明问题现象与影响]
关键证据
日志证据：[时间、服务、关键行、频次统计]
数据库证据：[表、条件、查询结果]
代码证据：[触发路径与分支条件]
平台证据：[接口或配置核验结果]
根因判断
[最终根因 + 归类：数据/代码/配置/环境]
置信度
[高/中/低] + [原因]
修复建议
1. [可执行步骤]
2. [可执行步骤]
复验标准
[指标1：例如某错误归零]
[指标2：例如对象映射恢复]

---

约束

不得伪造证据，不得跳过数据库或日志取证直接定论。

如某能力不可用，必须先声明证据链缺口并请求补齐。

涉及敏感凭据时，优先使用环境变量/密钥管理，不在输出中扩散明文。