本项目演示了如何通过「多角色协作 + 明确任务分段 + 可验证输出」的 Prompt 设计，实现一个复杂、可复用的多agents工作流。 该 Prompt 可直接用于 Cursor / Claude / ChatGPT (GPT-5) 等具备代码上下文理解的 AI 环境。
这个 Prompt 的高效性来自于 系统化的多角色设计 与 可验证的任务分层结构。 它不仅让 AI"回答问题"，而是让 AI"执行一个完整的专业工作流"。
| 设计要素 | 说明 |
|---|---|
| 角色扮演 (Role-Playing) | 在全局与局部任务中设定不同的专家身份，激活 AI 的领域知识。 |
| 任务分解 (Task Decomposition) | 将任务拆解为多个阶段（Stage）和步骤（Task），层次清晰。 |
| 精确指令 (Precision) | 所有操作均以命令式语言描述，避免歧义与不确定性。 |
| 思考框架 (Thinking Framework) | 通过专家的内心独白，引导 AI 以结构化方式分析问题。 |
| 完成标志 (Completion Criteria) | 明确每个阶段的产出与验证条件，确保任务闭环。 |
| 富文本输出 (Rich Output) | 要求 Markdown 表格、Mermaid 图、SQL 与伪代码等多维表达，提升可理解性与验证性。 |
在对话一开始，就将 AI 设定为 "顶尖的数据库管理员（DBA）与后端性能工程师"，从一开始奠定了专业的基调。
在每个分析步骤中进一步细化角色定位：
- 架构师（步骤一：鸟瞰全局）
- DBA（步骤二：深钻性能）
- 最终决策者（步骤三：权衡利弊）
这种分层式角色扮演极大激活了模型的专业思维，使其推理过程更贴近真实专家。
整个分析被拆分为三个明确的步骤，层次清晰。
分析流程严格遵循专家的解决路径：
| 步骤 | 名称 | 目标 |
|---|---|---|
| Step 1 | 场景分类 | 识别数据库使用场景 |
| Step 2 | 查询分析 | 深入分析性能瓶颈 |
| Step 3 | 方案设计 | 提出最终索引与优化方案 |
结构上实现了从宏观 → 微观，从分析 → 决策的逻辑递进。
这是整个 Prompt 的灵魂部分。它不仅告诉 AI "做什么"，更指导它 "如何思考"。
通过角色扮演的内心独白形式（如："作为一名架构师，我首先需要鸟瞰全局..."），帮助模型进入正确的分析思维路径。
框架中嵌入了具象的问题提示，如：
- "WHERE 条件是关键吗？"
- "能否寻求覆盖索引？"
这就像一份专家级的 Checklist，确保分析系统化、全面化，避免遗漏关键要素。
要求模型智能识别 {{TABLE_NAME}} 的命名风格（帕斯卡命名、驼峰命名等），
适应 ORM 的多样化场景，从而增强 Prompt 的鲁棒性。
每个步骤明确规定：
- 输入内容：如
@codebase或 SQL 段落 - 输出格式：如 Markdown 表格、列表、SQL 代码块
保证结果具备 可预测性 与 可验证性。
每个步骤都必须生成清晰、结构化的输出格式。
最终步骤（Step 3）输出完整的索引设计方案：
- 包含
CREATE INDEXSQL 语句 - 提供 设计理由 与前两步分析结果的逻辑关联
- 形成 闭环式分析链路
要求 AI 使用：
- Markdown 表格
- 格式化 SQL 代码块
| 角色 | 描述 |
|---|---|
| 🧑💻 全局角色 | "软件分析师"——负责协调整体任务流程与结构设计。 |
| 🧠 情境角色 | 在每个阶段切换为更具体的角色，例如"资深 DBA"、"性能工程师"或"架构师"。 |
| 📊 审阅者角色 | 负责根据完成标志检查输出格式与分析完整度。 |
在 Cursor / ChatGPT 的对话框中输入：
启用规则：通用数据库表索引分析
输入指令：
为 tb_user_profile 表运行索引分析规则
AI 将根据当前
@codebase上下文，扫描所有引用该表的代码文件并启动三阶段分析。
| 阶段 | 名称 | 核心目标 | 输出形式 |
|---|---|---|---|
| 步骤一 | 操作场景分类与负载评估 | 明确表的使用场景、操作类型与负载强度 | Markdown 表格 |
| 步骤二 | 查询模式深度分析 | 挖掘查询瓶颈与潜在索引候选字段 | 列表与分析说明 |
| 步骤三 | 最终索引方案与 SQL | 输出可部署的索引方案与理由说明 | SQL + 解释文本 |
🎯 目标：
识别 {{TABLE_NAME}} 的业务使用场景与数据库负载类型（读密集 / 写密集 / 混合负载）。
🧩 思考框架：
"作为一名架构师，我要全局扫描
{{TABLE_NAME}}的使用方式。 我需识别每个操作的业务意图、类型（SELECT / INSERT / UPDATE / DELETE）、调用频率与关键字段。"
📤 输出格式 (Markdown 表格)：
| 业务场景描述 | 操作类型 | 关键字段 | 预估频率 | 源文件引用 |
|---|---|---|---|---|
| 登录用户验证 | Read | user_id, email | 高 | src/services/authService.ts |
| 更新用户资料 | Write | user_id, updated_at | 中 | src/controllers/profileController.js |
🎯 目标：
分析所有与该表相关的 读操作 查询，识别可优化的索引字段组合。
🧩 思考框架：
"我需要像 DBA 一样看待每条查询：
- WHERE 条件中最常出现哪些字段？
- ORDER BY / GROUP BY 是否可通过索引优化？
- JOIN 的连接字段有哪些？
- 是否有可以通过复合索引实现覆盖查询的场景？"
📤 输出格式 (Markdown 列表)：
-
查询模式： 根据用户状态和角色筛选活跃用户
-
索引候选：
(status, role, last_login_time)理由：
status与role是 WHERE 的高频组合，last_login_time用于排序，此索引可显著减少扫描量并形成覆盖索引。
🎯 目标：
平衡读写性能，生成最终可部署的索引创建语句。
🧩 思考框架：
"索引越多，写入越慢。我要以最少的索引覆盖最多的场景。 合并候选索引，利用最左前缀原则，避免冗余。"
📤 输出格式 (SQL + 理由)：
/* 索引 1：优化活跃用户查询 */
CREATE INDEX idx_status_role_login ON {{TABLE_NAME}} (status, role, last_login_time DESC);理由： 支持步骤二中识别的"按状态与角色查询活跃用户"场景。该索引兼顾筛选与排序，覆盖高频读操作。
/* 索引 2：优化用户资料更新冲突检测 */
CREATE INDEX idx_userid_updated ON {{TABLE_NAME}} (user_id, updated_at);理由： 该索引可加速更新前的重复检测逻辑，平衡写入性能与读取效率。
- 生成 Markdown 表格（步骤一）
- 输出索引候选分析列表（步骤二）
- 生成至少 1 个
CREATE INDEX语句并附解释（步骤三） - 所有输出内容均可追溯至实际源代码引用
multi-agent-db-index-analysis/
├── README.md
├── prompts/
│ ├── rule_db_index_analysis.md ← 本文档
│ └── rule_api_latency_analysis.md ← 其他规则示例
└── examples/
├── tb_user_profile_analysis.md
└── tb_order_record_analysis.md
此结构化 Prompt 模板不仅适用于数据库索引分析，也可扩展至：
- 代码架构依赖分析
- 性能瓶颈定位
- 日志模式优化
- 微服务拓扑重建
本项目遵循 MIT License，可自由复用与修改，但请在引用时保留作者与源仓库信息。