多能力体系 BUG 定位闭环技能
适用场景
当用户要求：
- 主动调用现有能力体系完成定位
- 提供数据库与服务器日志等真实证据
- 输出可复核的结论与根因
- 形成“定位 -> 论证 -> 结论 -> 建议”的闭环
本技能必须优先使用真实运行数据，不得仅基于代码阅读直接定论。
强制指导提示词（原文保留）
我的意思是你积极主动调用目前的能力体系，你自己完成问题定位和证据论证（最好有实际的数据库与服务器数据支撑），再给出结论与原因，而不是仅查看代码就完成定论。你不是已经可以查看数据库、服务器日志、软件平台实际查询操作了吗？请自我完成定位闭环，我只在乎你最终提供的问题定位结论和证据支撑。
执行前置：四能力体系可用性检查（必须）
每次执行前，必须验证以下四项是否同时具备且可读：
- 源码文件能力（便于 AI 理解与定位）
- 数据库读取能力（便于真实数据验证）
- 服务器日志下载与分析能力（便于时序与行为证据）
- 软件平台操作查询能力（便于业务侧联动验证）
检查标准
- 源码文件能力：可在当前工作区读取相关代码文件（至少 1 个核心路由/服务文件）。
- 数据库读取能力：可成功执行 1 条只读 SQL（如
select 1）。 - 服务器日志能力：可读取日志技能配置并成功访问目标日志目录或样本日志。
- 软件平台查询能力：对应平台 Skill 可读，且其文档/接口说明可读取。
缺失能力时的提示与推荐（必须提示用户）
若任一能力缺失，先提示“能力不完整，无法保证证据闭环”，并给出补充建议：
- 源码文件：请直接提供项目源码上下文或关键目录
- 数据库读取能力：补充对应服务的 MCP（Postgres/SQLite/Redis 等）
- 服务器日志下载并分析能力：安装或补充 server-log-analysis
- 软件平台操作查询能力：补充对应业务平台的查询 Skill 或 MCP 工具
能力未补齐前，不给“最终根因定论”，仅给“当前证据不足清单”。
标准工作流（必须执行）
- 问题结构化
- 抽取时间窗口、服务名、错误关键词、对象标识（SN/ID/traceId）。
- 日志侧取证（服务器）
- 在目标时间窗口拉取原始日志。
- 统计异常频次、对象分组、连续性（是否持续复现）。
- 数据库侧取证
- 查询对象在关键表中的存在性、关联关系、状态、时间戳。
- 必要时跨库交叉验证（access/cloud/data）。
- 代码侧定位
- 定位异常枚举、抛出路径、路由与分支条件。
- 只用于解释机制，不替代真实数据结论。
- 平台侧验证
- 用平台 Skill 验证接口/对象状态、业务配置是否匹配。
- 证据链合并
- 按“日志证据 -> 数据库证据 -> 代码机制 -> 平台验证”串联。
- 输出结论
- 区分：数据问题 / 代码问题 / 配置问题 / 环境问题。
- 给出修复建议与复验标准
- 明确可执行步骤与“修复完成判定条件”。
输出模板（必须）
## 问题摘要
[一句话说明问题现象与影响]
## 关键证据
- 日志证据：[时间、服务、关键行、频次统计]
- 数据库证据：[表、条件、查询结果]
- 代码证据：[触发路径与分支条件]
- 平台证据：[接口或配置核验结果]
## 根因判断
[最终根因 + 归类：数据/代码/配置/环境]
## 置信度
[高/中/低] + [原因]
## 修复建议
1. [可执行步骤]
2. [可执行步骤]
## 复验标准
- [指标1：例如某错误归零]
- [指标2：例如对象映射恢复]
约束
- 不得伪造证据，不得跳过数据库或日志取证直接定论。
- 如某能力不可用，必须先声明证据链缺口并请求补齐。
- 涉及敏感凭据时，优先使用环境变量/密钥管理，不在输出中扩散明文。