企业官网建设流程全解析

1. 项目概述：一个能直接“抄作业”的多智能体提示词设计框架

如果你和我一样，每天都在和 Cursor、Claude 或者 ChatGPT 打交道，试图让它们帮你完成一些复杂的、需要深度思考的任务，比如分析数据库性能瓶颈、重构一段糟糕的代码，或者设计一个系统架构，那你肯定遇到过这样的困境：AI 的回答要么流于表面，要么逻辑混乱，你需要不停地追问、引导，甚至自己动手重写。整个过程就像在指挥一个聪明但缺乏条理的新手，心累。

今天要拆解的这个项目——Multi-Agent-Prompt-Design，就精准地命中了这个痛点。它不是一个具体的工具库，而是一套方法论和可复用的设计模板。其核心思想是：不要指望 AI 一次性给你完美答案，而是通过精心设计的“剧本”，让 AI 扮演不同的专家角色，按照你预设的、符合人类专家思维的工作流，一步步推导出高质量、可验证的结果。

简单说，它把一次复杂的 AI 交互，变成了一场分工明确、流程清晰的“专家会诊”。你不再是那个不断纠正 AI 的“监工”，而是成为了这场会诊的“会议主持人”和“流程设计师”。这个项目提供的，正是一份极其详尽的“会议流程手册”和“专家角色剧本”。

我花了大量时间研究并实践这套框架，发现它尤其适合解决那些有明确步骤、需要多角度分析、且输出要求结构化的问题。比如开篇提到的数据库索引分析，还有代码审查、API 设计评审、系统故障根因分析等。接下来，我会结合自己大量的实操经验，把这套框架从理念到骨头缝里的细节都给你掰开揉碎讲明白，并补充大量原始文档里没有的“实战心得”和“避坑指南”。

2. 核心理念拆解：为什么“角色扮演+任务分解”如此有效？

在深入具体设计前，我们必须先理解其底层逻辑。为什么简单的“角色扮演”（Role-Playing）和“任务分解”（Task Decomposition）组合，能产生“1+1>2”的化学反应？这背后是对大语言模型（LLM）工作方式的深刻洞察。

2.1 突破模型的“平均化”思维陷阱

大语言模型本质上是基于海量数据训练出的“概率大师”，它的回答倾向于给出一个“平均意义上”合理、安全的答案。当你直接问“如何优化这张表？”时，模型会调用它学到的所有关于“数据库优化”的通用知识，给出一个泛泛而谈的列表：加索引、避免 SELECT *、优化查询语句……这些都对，但缺乏针对性，更缺乏深度。

“角色扮演”的第一重作用，是进行思维聚焦。当你告诉模型：“现在你是顶尖的数据库管理员（DBA）”，你其实是在为模型庞大的知识库增加了一个强大的“过滤器”。模型会优先激活与“DBA”、“性能调优”、“生产环境”强相关的知识神经元，抑制那些泛泛的、初级的建议。这相当于把模型的“思考带宽”集中到了一个专业频道上。

2.2 模拟人类的专家级问题解决路径

人类专家解决复杂问题，从来不是一蹴而就的。一个资深 DBA 分析表性能，会下意识地遵循一个思维框架：先看业务场景（这表是干嘛的？），再抓查询模式（哪些SQL在用它？怎么用的？），最后权衡利弊出方案（加什么索引？代价是什么？）。

“任务分解”就是在外部显式地重建这个思维框架。我们把“分析表”这个模糊指令，拆解成“场景分类 -> 查询分析 -> 方案设计”三个明确的阶段。每个阶段，我们再通过“角色扮演”细化专家视角（架构师 -> DBA -> 决策者）。这相当于为 AI 铺设了一条清晰的“思考轨道”，它只需要沿着轨道运行，就能输出结构化的、符合专家习惯的中间产物和最终结论。

2.3 实现过程的可视化与结果的可验证性

这是项目设计中非常高明的一点。传统的 Prompt 输出是一段文本，好坏全凭主观判断。而在这个框架下，每个阶段都有明确的“交付物”（Deliverable）格式要求，比如步骤一必须是 Markdown 表格，步骤二必须是带理由的列表，步骤三必须是 SQL 语句加解释。

这样做有三大好处：

1. 强制结构化思考：模型为了生成表格，必须去提取和归类信息，这本身就是一种深度处理。
2. 便于人类审阅：你可以快速扫描表格和列表，检查模型的分析是否覆盖了关键场景和查询，逻辑是否自洽。
3. 形成分析链路：最终方案（步骤三）必须能追溯到前两步的分析结果（“理由：基于步骤二识别的高频查询组合”），形成了一个完整的、可审计的分析闭环。如果最终方案和前文对不上，你立刻就能发现 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 任务分解结构：打造无懈可击的逻辑链条

任务分解不是简单地把大任务切成几个小任务，而是要构建一个有逻辑递进关系的“流水线”。

1. 步骤一：场景分类与负载评估

   • 目标：定性分析。回答“是什么”的问题。
   • 输入：代码库上下文（@codebase）。
   • 核心动作：扫描所有引用目标表的代码文件，识别操作类型（CRUD）、频率、关键字段和业务场景。
   • 输出格式：Markdown 表格。强制分类能暴露认知盲区。如果AI连5行像样的场景都填不满，可能意味着它没读懂代码，或者你的表确实设计得太简单。
   • 避坑指南：模型可能会把一次函数调用中的多个SQL语句混为一谈。需要在思考框架中强调“按独立的业务意图进行归类”。

2. 步骤二：查询模式深度分析

   • 目标：定量分析。回答“为什么”的问题。
   • 输入：基于步骤一识别出的“读操作”场景。
   • 核心动作：对每个查询模式进行“尸检”，找出所有可能成为索引候选的字段，并分析其组合方式。
   • 输出格式：带理由的列表。每一条都应遵循“模式描述 -> 候选索引 -> 理由”的结构。理由必须具体，例如：“WHERE status='active' AND dept_id=？是高频查询组合，且dept_id选择性高，适合作为复合索引的前导列。”
   • 避坑指南：警惕AI提出“为每个字段都建单列索引”这种新手建议。要在思考框架中强调“复合索引”、“最左前缀”、“覆盖索引”等高级概念来引导它。

3. 步骤三：最终索引方案与 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会顺着这个清单逐一检查，输出的分析自然就全面、深入了。

实操心得：如何写出好的“思考框架”？

1. 角色代入：自己先扮演一遍这个专家，把脑子里闪过的关键问题记下来。
2. 使用疑问句：多问“是否”、“能否”、“哪些”，少用陈述句。
3. 嵌入专业术语：像“覆盖索引”、“最左前缀”、“选择性高”这样的术语，能有效唤醒模型的领域知识。
4. 分层引导：从简单事实（有哪些字段）到复杂判断（如何组合优化），层层递进。

3.4 确保质量的“完成标志”与“富文本输出”

这是保障输出可用性的最后两道闸门。

• 完成标志 (Completion Criteria)：在Prompt末尾以清单形式列出。它有两个作用：
  1. 给AI的明确终点：告诉AI必须完成这些才算任务结束。
  2. 给用户的验收清单：你可以快速核对输出是否完整。示例中的“所有输出内容均可追溯至实际源代码引用”这一条非常关键，它杜绝了AI凭空捏造分析依据的可能。
• 富文本输出 (Rich Output Formatting)：强制要求使用 Markdown 表格、代码块、列表等格式。这不仅是为了好看。
  1. 结构化信息：表格迫使信息按列对齐，便于比较和提取。
  2. 突出代码：SQL 语句放在代码块中，一目了然，甚至可以一键复制执行。
  3. 降低审阅疲劳：整齐的结构化文档，比一大段杂乱文字容易审阅得多。

4. 实战演练：将一个复杂任务改编为此框架

光看数据库例子可能觉得有局限性，我们动手将另一个常见任务——“评估一个REST API接口的性能与设计”——改造成多智能体Prompt。假设我们有一个用户查询接口GET /api/users。

4.1 第一步：定义角色与任务流

首先，我们规划出分析这个接口需要哪几个专家视角，以及流程。

1. 全局角色：资深后端架构师与API性能优化专家。
2. 任务分解：
   • 阶段一（场景与负载分析）：扮演“产品与运维视角的观察者”。分析这个接口的调用方、频率、数据量。
   • 阶段二（代码与逻辑剖析）：扮演“代码侦探”。深入代码，分析业务逻辑、数据库查询、缓存使用、序列化等瓶颈点。
   • 阶段三（优化方案设计）：扮演“解决方案架构师”。综合前两步，提出具体、可落地的优化方案，并评估利弊。

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. **数据库**：查看了哪些表？查询条件是否都有索引？是否存在`N+1`查询问题？数据量大会不会分页慢？ 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 的上下文理解出现了偏差。
• 解决方案：
  1. 使用强制分隔符：在 Prompt 中用---或***等符号清晰分隔每个步骤，并在每个步骤开头重申“现在开始执行步骤X”。
  2. 明确指令：在 Prompt 开头就强调“请严格按照以下三个步骤顺序执行，完成前一步骤并输出指定格式后，再向我请求或自动进入下一步骤。”
  3. 利用 Claude/Cursor 的“停止”特性：在 Claude 或 Cursor 中，你可以要求模型在完成一个步骤后暂停，等你输入“继续”再开始下一步。这给了你审阅中间结果的机会。
  4. 事后纠正：如果 AI 跳步了，直接指出：“你没有按照要求先输出步骤一的表格。请重新开始，首先完成步骤一：接口场景与负载分析。”

5.2 问题二：分析流于表面，缺乏深度

• 现象：AI 输出的分析都是常识性建议（“可以加索引”、“可以考虑用缓存”），没有结合具体的代码和业务场景。
• 原因：“思考框架”引导性不足，或者提供的上下文（@codebase）不完整。
• 解决方案：
  1. 强化“思考框架”：将引导问题设计得更具体、更深入。例如，不要只问“有没有瓶颈”，要问“在/services/userService.js的第45行，这个循环内部的数据库查询，是否可以在循环外批量完成？”
  2. 提供更丰富的上下文：确保你用@codebase或上传文件的方式，提供了接口相关的所有关键文件：控制器、服务层、数据模型/DAO层、甚至相关的工具类。AI 看不到代码，自然只能给泛泛而谈的建议。
  3. 在角色描述中强调“细节”：在“代码侦探”这类角色描述里，加入“你以对代码细节的苛刻审查而闻名，善于发现隐藏的N+1查询、循环内的远程调用等深层问题。”

5.3 问题三：输出格式混乱，不遵守要求

• 现象：要求输出表格，它却用列表；要求 SQL 代码块，它却用行内代码。
• 原因：模型有时会“偷懒”或误解格式指令。
• 解决方案：
  1. 提供清晰的格式范例：在 Prompt 里直接写一个输出样例，比如在“输出格式”后面跟一个简单的示例表格或列表。模型有很强的模仿能力。
  2. 使用明确的标记语言：直接说“请以 Markdown 表格形式输出，包含以下列：业务场景描述、操作类型、关键字段、预估频率、源文件引用”。
  3. 事后格式化：如果输出格式不对，可以简单要求：“请将上述内容重新整理为符合步骤一要求的 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里怎么读文件？”这类问题，直接问就好。
  • 高度依赖实时信息或动态交互的任务：例如需要实时调试、不断试错的交互式编程，这套流程可能显得笨重。

• 扩展性思考：

  1. 迭代与反馈：可以将 AI 输出的方案，作为下一轮 Prompt 的输入，进行复审或模拟实施。例如，“假设我是团队资深工程师，请从代码可维护性角度，评审你刚才提出的第三条优化建议。”
  2. 知识库集成：在思考框架中，可以引导 AI 参考特定的项目文档、架构图或历史故障报告（通过上传文件实现），让分析更贴合项目实际。
  3. 自动化流水线：对于极其标准的检查（如每次提交代码前的安全检查），理论上可以将此 Prompt 与 CI/CD 工具结合，让 AI 自动生成审查报告。但这需要更稳定的模型 API 和输出解析。

这套Multi-Agent-Prompt-Design框架的价值，在于它提供了一种将人类专家思维“编码”进 AI 交互的范式。它强迫我们这些使用者，在向 AI 提问前，先把自己的问题想清楚、结构化。这个过程本身，就是一次极佳的思维训练。当你习惯了用“角色”、“步骤”、“交付物”来拆解问题后，即使不借助 AI，你分析解决复杂问题的能力也会悄然提升。最终，最好的 Prompt 工程师，不仅是会调教 AI 的人，更是那个最懂如何思考的人。