1. 项目概述一个能直接“抄作业”的多智能体提示词设计框架如果你和我一样每天都在和 Cursor、Claude 或者 ChatGPT 打交道试图让它们帮你完成一些复杂的、需要深度思考的任务比如分析数据库性能瓶颈、重构一段糟糕的代码或者设计一个系统架构那你肯定遇到过这样的困境AI 的回答要么流于表面要么逻辑混乱你需要不停地追问、引导甚至自己动手重写。整个过程就像在指挥一个聪明但缺乏条理的新手心累。今天要拆解的这个项目——Multi-Agent-Prompt-Design就精准地命中了这个痛点。它不是一个具体的工具库而是一套方法论和可复用的设计模板。其核心思想是不要指望 AI 一次性给你完美答案而是通过精心设计的“剧本”让 AI 扮演不同的专家角色按照你预设的、符合人类专家思维的工作流一步步推导出高质量、可验证的结果。简单说它把一次复杂的 AI 交互变成了一场分工明确、流程清晰的“专家会诊”。你不再是那个不断纠正 AI 的“监工”而是成为了这场会诊的“会议主持人”和“流程设计师”。这个项目提供的正是一份极其详尽的“会议流程手册”和“专家角色剧本”。我花了大量时间研究并实践这套框架发现它尤其适合解决那些有明确步骤、需要多角度分析、且输出要求结构化的问题。比如开篇提到的数据库索引分析还有代码审查、API 设计评审、系统故障根因分析等。接下来我会结合自己大量的实操经验把这套框架从理念到骨头缝里的细节都给你掰开揉碎讲明白并补充大量原始文档里没有的“实战心得”和“避坑指南”。2. 核心理念拆解为什么“角色扮演任务分解”如此有效在深入具体设计前我们必须先理解其底层逻辑。为什么简单的“角色扮演”Role-Playing和“任务分解”Task Decomposition组合能产生“112”的化学反应这背后是对大语言模型LLM工作方式的深刻洞察。2.1 突破模型的“平均化”思维陷阱大语言模型本质上是基于海量数据训练出的“概率大师”它的回答倾向于给出一个“平均意义上”合理、安全的答案。当你直接问“如何优化这张表”时模型会调用它学到的所有关于“数据库优化”的通用知识给出一个泛泛而谈的列表加索引、避免 SELECT *、优化查询语句……这些都对但缺乏针对性更缺乏深度。“角色扮演”的第一重作用是进行思维聚焦。当你告诉模型“现在你是顶尖的数据库管理员DBA”你其实是在为模型庞大的知识库增加了一个强大的“过滤器”。模型会优先激活与“DBA”、“性能调优”、“生产环境”强相关的知识神经元抑制那些泛泛的、初级的建议。这相当于把模型的“思考带宽”集中到了一个专业频道上。2.2 模拟人类的专家级问题解决路径人类专家解决复杂问题从来不是一蹴而就的。一个资深 DBA 分析表性能会下意识地遵循一个思维框架先看业务场景这表是干嘛的再抓查询模式哪些SQL在用它怎么用的最后权衡利弊出方案加什么索引代价是什么。“任务分解”就是在外部显式地重建这个思维框架。我们把“分析表”这个模糊指令拆解成“场景分类 - 查询分析 - 方案设计”三个明确的阶段。每个阶段我们再通过“角色扮演”细化专家视角架构师 - DBA - 决策者。这相当于为 AI 铺设了一条清晰的“思考轨道”它只需要沿着轨道运行就能输出结构化的、符合专家习惯的中间产物和最终结论。2.3 实现过程的可视化与结果的可验证性这是项目设计中非常高明的一点。传统的 Prompt 输出是一段文本好坏全凭主观判断。而在这个框架下每个阶段都有明确的“交付物”Deliverable格式要求比如步骤一必须是 Markdown 表格步骤二必须是带理由的列表步骤三必须是 SQL 语句加解释。这样做有三大好处强制结构化思考模型为了生成表格必须去提取和归类信息这本身就是一种深度处理。便于人类审阅你可以快速扫描表格和列表检查模型的分析是否覆盖了关键场景和查询逻辑是否自洽。形成分析链路最终方案步骤三必须能追溯到前两步的分析结果“理由基于步骤二识别的高频查询组合”形成了一个完整的、可审计的分析闭环。如果最终方案和前文对不上你立刻就能发现 AI“跑偏了”。实操心得别怕“限制”AI很多人在设计 Prompt 时总想给 AI 最大自由怕限制太多影响发挥。但我的经验恰恰相反对于复杂任务清晰、严格的限制角色、步骤、格式不是枷锁而是“脚手架”。它帮助 AI 把散乱的知识组织成有逻辑的成果最终输出质量远高于一个开放式的指令。这就像让一位建筑大师自由发挥 vs 给他一份详细的施工图纸后者更能保证建成你想要的房子。3. 框架核心组件深度解析与设计指南理解了“为什么”我们来看“怎么做”。项目的核心是一个高度结构化的 Prompt 模板。我们以它示范的“数据库表索引分析”为例逐层拆解每个组件的设计意图和实操要点。3.1 角色系统设计从“全局角色”到“情境角色”角色系统是整套框架的“演员表”设计好坏直接决定演出效果。全局角色 (Global Role)这是对话的“基调设定者”。在示例中一开始就将 AI 设定为“顶尖的数据库管理员DBA与后端性能工程师”。这个角色要足够权威和具体避免使用“助手”、“专家”等泛称。好的全局角色能立刻将对话语境拉入专业领域。设计技巧在角色描述中融入关键职责。例如“你是一名拥有十年以上大型互联网系统运维经验的资深 DBA尤其擅长 InnoDB 存储引擎的性能调优与故障排查对索引原理、执行计划有深刻理解。”情境角色 (Situational Role)这是框架的精华所在。在任务的不同阶段让 AI 切换更具体的专家视角。步骤一场景分类切换为“系统架构师”。视角是宏观的、业务导向的。他关心的是“这个表在整个系统里扮演什么角色哪些业务模块在用它读写比例如何”步骤二查询分析切换为“钻探型 DBA”。视角是微观的、技术细节的。他拿着放大镜审视每一条 SQL“这个 WHERE 条件有没有索引这个 JOIN 是否高效这个 ORDER BY 能不能用索引优化”步骤三方案设计切换为“权衡决策者”。视角是全局的、权衡利弊的。他基于前两步的分析像一名CTO一样做决策“索引A能覆盖80%的查询但会影响写入速度索引B更通用但占用空间大。我们的业务优先级是什么最终拍板哪个方案”设计技巧为每个情境角色配一句“内心独白”式的思考框架下文详述能极大地帮助 AI“入戏”。3.2 任务分解结构打造无懈可击的逻辑链条任务分解不是简单地把大任务切成几个小任务而是要构建一个有逻辑递进关系的“流水线”。步骤一场景分类与负载评估目标定性分析。回答“是什么”的问题。输入代码库上下文codebase。核心动作扫描所有引用目标表的代码文件识别操作类型CRUD、频率、关键字段和业务场景。输出格式Markdown 表格。强制分类能暴露认知盲区。如果AI连5行像样的场景都填不满可能意味着它没读懂代码或者你的表确实设计得太简单。避坑指南模型可能会把一次函数调用中的多个SQL语句混为一谈。需要在思考框架中强调“按独立的业务意图进行归类”。步骤二查询模式深度分析目标定量分析。回答“为什么”的问题。输入基于步骤一识别出的“读操作”场景。核心动作对每个查询模式进行“尸检”找出所有可能成为索引候选的字段并分析其组合方式。输出格式带理由的列表。每一条都应遵循“模式描述 - 候选索引 - 理由”的结构。理由必须具体例如“WHERE statusactive AND dept_id是高频查询组合且dept_id选择性高适合作为复合索引的前导列。”避坑指南警惕AI提出“为每个字段都建单列索引”这种新手建议。要在思考框架中强调“复合索引”、“最左前缀”、“覆盖索引”等高级概念来引导它。步骤三最终索引方案与 SQL目标合成与决策。回答“怎么办”的问题。输入步骤二产生的候选索引列表。核心动作合并、取舍、权衡。利用最左前缀原则合并索引根据读写负载和业务优先级决定最终方案。输出格式可执行的 SQLCREATE INDEX语句 每条索引的设计理由。理由必须引用前两步的分析形成闭环。避坑指南这是最容易出“纸上谈兵”方案的一步。好的 Prompt 应提醒AI考虑“索引维护成本”、“磁盘空间”、“对INSERT/UPDATE性能的影响”等工程现实因素。3.3 灵魂所在“思考框架”的编写艺术“思考框架”Thinking Framework是附着在每个步骤下的“导演脚本”它告诉AI在这个角色下“应该如何思考”。这是区分普通Prompt和高级Prompt的关键。写法精髓使用第二人称或角色内心独白提出一系列引导性问题。差“分析查询模式。”太笼统佳“现在像一名钻探型DBA一样思考1. 这条查询的WHERE子句中哪个字段的选择性最高2. 有没有出现ORDER BY和WHERE使用不同字段的情况3. 如果我把这两个字段组成复合索引顺序应该怎么放才能同时满足筛选和排序”示例解析步骤二的思考框架“我需要像 DBA 一样看待每条查询WHERE 条件中最常出现哪些字段引导定位高频过滤条件ORDER BY / GROUP BY 是否可通过索引优化引导考虑排序分组优化JOIN 的连接字段有哪些引导关注关联查询是否有可以通过复合索引实现覆盖查询的场景引导追求更高阶的优化目标”这一连串的问题就是一个标准的DBA分析索引的Checklist。AI会顺着这个清单逐一检查输出的分析自然就全面、深入了。实操心得如何写出好的“思考框架”角色代入自己先扮演一遍这个专家把脑子里闪过的关键问题记下来。使用疑问句多问“是否”、“能否”、“哪些”少用陈述句。嵌入专业术语像“覆盖索引”、“最左前缀”、“选择性高”这样的术语能有效唤醒模型的领域知识。分层引导从简单事实有哪些字段到复杂判断如何组合优化层层递进。3.4 确保质量的“完成标志”与“富文本输出”这是保障输出可用性的最后两道闸门。完成标志 (Completion Criteria)在Prompt末尾以清单形式列出。它有两个作用给AI的明确终点告诉AI必须完成这些才算任务结束。给用户的验收清单你可以快速核对输出是否完整。示例中的“所有输出内容均可追溯至实际源代码引用”这一条非常关键它杜绝了AI凭空捏造分析依据的可能。富文本输出 (Rich Output Formatting)强制要求使用 Markdown 表格、代码块、列表等格式。这不仅是为了好看。结构化信息表格迫使信息按列对齐便于比较和提取。突出代码SQL 语句放在代码块中一目了然甚至可以一键复制执行。降低审阅疲劳整齐的结构化文档比一大段杂乱文字容易审阅得多。4. 实战演练将一个复杂任务改编为此框架光看数据库例子可能觉得有局限性我们动手将另一个常见任务——“评估一个REST API接口的性能与设计”——改造成多智能体Prompt。假设我们有一个用户查询接口GET /api/users。4.1 第一步定义角色与任务流首先我们规划出分析这个接口需要哪几个专家视角以及流程。全局角色资深后端架构师与API性能优化专家。任务分解阶段一场景与负载分析扮演“产品与运维视角的观察者”。分析这个接口的调用方、频率、数据量。阶段二代码与逻辑剖析扮演“代码侦探”。深入代码分析业务逻辑、数据库查询、缓存使用、序列化等瓶颈点。阶段三优化方案设计扮演“解决方案架构师”。综合前两步提出具体、可落地的优化方案并评估利弊。4.2 第二步编写完整的 Prompt 模板以下是改编后的 Prompt 示例你可以直接用于 Cursor 或 Claude启用规则REST API 接口深度分析与优化 # 规则名称REST API 接口性能与设计评估 **全局角色**你现在是一名拥有超过8年高并发系统开发经验的资深后端架构师尤其擅长分布式系统性能调优与微服务API设计。你对数据库、缓存、消息队列、代码层面的性能瓶颈有敏锐的嗅觉。 接下来你将遵循以下三阶段工作流对接口 {{API_ENDPOINT}}例如GET /api/users进行深度分析。请严格按阶段推进并输出指定格式的内容。 --- ## 步骤一接口场景与负载分析 **情境角色切换**现在请你从**产品经理与运维工程师**的联合视角出发宏观审视这个接口。 ** 目标**厘清该接口的业务价值、调用模式与负载特征。 ** 思考框架** “这个接口服务于哪个前端页面或移动端功能主要的调用方是谁用户端、管理后台、内部服务在典型业务场景下如早晚高峰它的QPS每秒查询率大概在什么范围请求参数有哪些返回的数据量行数、JSON大小通常有多大是否存在明显的热点数据或突发流量场景” ** 输出格式 (Markdown 表格)** | 分析维度 | 具体内容 | | :--- | :--- | | **核心业务场景** | 例如用户中心页面拉取个人资料、后台用户列表筛选 | | **主要调用方** | 例如Web前端、移动端App、内部风控服务 | | **预估QPS范围** | 例如平时 50/s高峰 200/s | | **典型请求参数** | 例如user_id, page, size, status | | **典型响应数据量** | 例如单条记录约2KB列表每页20条约40KB | | **潜在热点/突发** | 例如热门活动时根据activity_id查询的请求激增 | --- ## 步骤二代码逻辑与瓶颈深度剖析 **情境角色切换**现在请你化身**代码侦探**深入 {{API_ENDPOINT}} 相关的控制器、服务、数据访问层代码。 ** 目标**定位代码中可能存在的性能瓶颈与设计缺陷。 ** 思考框架** “1. **数据库**查看了哪些表查询条件是否都有索引是否存在N1查询问题数据量大会不会分页慢 2. **缓存**是否使用了缓存缓存键设计是否合理缓存过期策略是什么有没有缓存穿透/雪崩风险 3. **计算**响应数据是否经过了复杂的计算或转换序列化如JSON化成本高吗 4. **外部依赖**是否调用了其他慢速服务或API有没有做超时和降级处理 5. **代码结构**是否存在重复逻辑参数校验是否完整错误处理是否得当” ** 输出格式 (Markdown 列表每个瓶颈点一条)** * **瓶颈点用户列表查询缺乏高效复合索引** * **位置**UserService.listUsers(filter) * **问题描述**代码中根据 status 和 registration_date 进行筛选和排序但表上仅有 id 的主键索引。 * **影响**当用户量达到百万级时该查询需要进行全表扫描并排序响应时间超过2秒。 * **证据/代码片段** javascript // 示例代码 const users await User.findAll({ where: { status: filter.status }, order: [[registration_date, DESC]], limit: filter.size, offset: (filter.page - 1) * filter.size }); --- ## 步骤三综合优化方案设计 **情境角色切换**现在请你作为**解决方案架构师**基于前两步的分析制定一份可执行的优化方案。 ** 目标**提出具体、可落地、分优先级的优化建议并权衡利弊。 ** 思考框架** “我需要权衡改动成本与收益。哪些是‘低垂的果实’如加索引可以快速见效哪些需要中期重构如引入缓存哪些属于长期架构优化每个方案是否会引入新的复杂度如缓存一致性方案之间是否有依赖或冲突” ** 输出格式** 请为每个优化建议提供以下信息 1. **建议标题**例如为users表添加复合索引 2. **具体方案**可操作的步骤如SQL语句、代码改动 3. **预期收益**量化或定性描述如“预计该查询响应时间从2000ms降至50ms” 4. **实施成本/风险**如“需要短时间锁表”、“增加少量存储空间”、“需维护缓存一致性” 5. **优先级 (P0/P1/P2)**P0为最高应立即实施 **示例输出** - **建议1添加复合索引以优化列表查询** - **方案**在users表上创建索引 idx_status_regdate (status, registration_date DESC)。 - **预期收益**将步骤二中识别的列表查询从全表扫描优化为索引范围扫描预计响应时间提升95%以上。 - **成本/风险**低。仅需一条在线DDL语句取决于MySQL版本对写入性能影响微乎其微。 - **优先级**P0 --- ## ✅ 完成标志 * [ ] 步骤一完整填写接口场景与负载分析表格。 * [ ] 步骤二至少列出2个具体的代码层瓶颈点并附上问题描述与代码位置。 * [ ] 步骤三提出至少2条不同维度的优化建议如数据库、缓存、代码并完整包含方案、收益、成本与优先级评估。通过这个改造你会发现原本模糊的“帮我看看这个接口慢不慢”变成了一个可执行、可验证的深度分析流程。AI 会按部就班地给出远超简单问答的专业报告。5. 高级技巧与常见问题排查在实际使用这套框架时你可能会遇到一些问题。以下是我总结的常见“坑”及其解决方案。5.1 问题一AI 不遵循步骤或者跳步执行现象你发出了多步分析的指令但 AI 直接给出了最终答案或者把几个步骤的分析混在一起输出。原因Prompt 的指令结构不够强硬或者 AI 的上下文理解出现了偏差。解决方案使用强制分隔符在 Prompt 中用---或***等符号清晰分隔每个步骤并在每个步骤开头重申“现在开始执行步骤X”。明确指令在 Prompt 开头就强调“请严格按照以下三个步骤顺序执行完成前一步骤并输出指定格式后再向我请求或自动进入下一步骤。”利用 Claude/Cursor 的“停止”特性在 Claude 或 Cursor 中你可以要求模型在完成一个步骤后暂停等你输入“继续”再开始下一步。这给了你审阅中间结果的机会。事后纠正如果 AI 跳步了直接指出“你没有按照要求先输出步骤一的表格。请重新开始首先完成步骤一接口场景与负载分析。”5.2 问题二分析流于表面缺乏深度现象AI 输出的分析都是常识性建议“可以加索引”、“可以考虑用缓存”没有结合具体的代码和业务场景。原因“思考框架”引导性不足或者提供的上下文codebase不完整。解决方案强化“思考框架”将引导问题设计得更具体、更深入。例如不要只问“有没有瓶颈”要问“在/services/userService.js的第45行这个循环内部的数据库查询是否可以在循环外批量完成”提供更丰富的上下文确保你用codebase或上传文件的方式提供了接口相关的所有关键文件控制器、服务层、数据模型/DAO层、甚至相关的工具类。AI 看不到代码自然只能给泛泛而谈的建议。在角色描述中强调“细节”在“代码侦探”这类角色描述里加入“你以对代码细节的苛刻审查而闻名善于发现隐藏的N1查询、循环内的远程调用等深层问题。”5.3 问题三输出格式混乱不遵守要求现象要求输出表格它却用列表要求 SQL 代码块它却用行内代码。原因模型有时会“偷懒”或误解格式指令。解决方案提供清晰的格式范例在 Prompt 里直接写一个输出样例比如在“输出格式”后面跟一个简单的示例表格或列表。模型有很强的模仿能力。使用明确的标记语言直接说“请以 Markdown 表格形式输出包含以下列业务场景描述、操作类型、关键字段、预估频率、源文件引用”。事后格式化如果输出格式不对可以简单要求“请将上述内容重新整理为符合步骤一要求的 Markdown 表格。”5.4 问题四针对不同 AI 工具的适配微调Claude (Claude-3.5-Sonnet/Opus)Claude 对长上下文和复杂指令的理解能力极强非常适合这套框架。你可以把整个庞大的 Prompt 一次性给它它通常能很好地遵循。它的优势在于推理深度。Cursor (基于 GPT-4)Cursor 的优势在于与代码上下文的深度集成。使用codebase指令极其方便。注意 Cursor 的上下文长度限制如果项目很大可能需要聚焦于特定目录。它的响应更偏向代码实操。ChatGPT (GPT-4o)同样具备强大的能力。如果对话轮次多了它有时会“忘记”最初的复杂指令需要在关键步骤稍作提醒。它的通用性最好。核心技巧把它变成“对话模板”不要在每次需要时都粘贴这段长篇 Prompt。在 Cursor 或 ChatGPT 中可以将这个精心设计好的多步分析 Prompt 保存为一个“自定义指令”或“对话预设”。给它起个名字比如“【深度分析】API性能审查”。下次遇到需要分析的接口只需要输入“启用【深度分析】API性能审查规则目标接口GET /api/orders”整个专家工作流就自动启动了效率倍增。6. 框架的边界与扩展思考没有任何方法论是银弹这套多智能体 Prompt 设计框架也不例外。理解它的边界才能更好地运用它。适用场景有明确步骤和检查点的复杂任务如设计评审、代码分析、故障排查、方案评估。需要多维度专业知识单一角色无法覆盖需要架构、开发、运维等不同视角。输出要求高度结构化需要报告、清单、方案等格式清晰的交付物。不适用场景开放式创意比如“帮我想一个产品名字”或“写一首诗”不需要如此复杂的结构。简单问答“Python里怎么读文件”这类问题直接问就好。高度依赖实时信息或动态交互的任务例如需要实时调试、不断试错的交互式编程这套流程可能显得笨重。扩展性思考迭代与反馈可以将 AI 输出的方案作为下一轮 Prompt 的输入进行复审或模拟实施。例如“假设我是团队资深工程师请从代码可维护性角度评审你刚才提出的第三条优化建议。”知识库集成在思考框架中可以引导 AI 参考特定的项目文档、架构图或历史故障报告通过上传文件实现让分析更贴合项目实际。自动化流水线对于极其标准的检查如每次提交代码前的安全检查理论上可以将此 Prompt 与 CI/CD 工具结合让 AI 自动生成审查报告。但这需要更稳定的模型 API 和输出解析。这套Multi-Agent-Prompt-Design框架的价值在于它提供了一种将人类专家思维“编码”进 AI 交互的范式。它强迫我们这些使用者在向 AI 提问前先把自己的问题想清楚、结构化。这个过程本身就是一次极佳的思维训练。当你习惯了用“角色”、“步骤”、“交付物”来拆解问题后即使不借助 AI你分析解决复杂问题的能力也会悄然提升。最终最好的 Prompt 工程师不仅是会调教 AI 的人更是那个最懂如何思考的人。