多能力体系 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. 给出修复建议与复验标准
   • 明确可执行步骤与“修复完成判定条件”。

---

输出模板（必须）#

markdown

## 问题摘要
[一句话说明问题现象与影响]

## 关键证据
- 日志证据：[时间、服务、关键行、频次统计]
- 数据库证据：[表、条件、查询结果]
- 代码证据：[触发路径与分支条件]
- 平台证据：[接口或配置核验结果]

## 根因判断
[最终根因 + 归类：数据/代码/配置/环境]

## 置信度
[高/中/低] + [原因]

## 修复建议
1. [可执行步骤]
2. [可执行步骤]

## 复验标准
- [指标1：例如某错误归零]
- [指标2：例如对象映射恢复]

---

约束#

• 不得伪造证据，不得跳过数据库或日志取证直接定论。
• 如某能力不可用，必须先声明证据链缺口并请求补齐。
• 涉及敏感凭据时，优先使用环境变量/密钥管理，不在输出中扩散明文。