Dream Creator：12个AI智能体协作的虚拟开发团队实战指南

1. 项目概述：一个由12个AI智能体组成的虚拟开发团队

如果你曾经尝试过用AI助手来写代码，大概率会遇到这样的场景：你描述了一个功能，AI助手生成了一堆代码，但当你问它“这个架构怎么设计更合理”或者“这里有个bug怎么修”时，它要么答非所问，要么给出的方案过于单一。这感觉就像你一个人在和一台只会执行命令的机器对话，而不是在和一个有分工、有协作的团队一起工作。

Dream Creator 这个项目，就是为了彻底改变这种体验而生的。它不是一个单一的AI助手，而是一个由12个不同角色、各司其职的AI智能体组成的“虚拟开发团队”。当你输入/dream-creator这个指令时，你启动的不是一个工具，而是一个完整的项目孵化流程。从产品经理和你聊需求，到架构师设计技术方案，再到前后端开发、测试、部署，整个过程都由这些智能体相互协作、接力完成。它的核心关键词是“多智能体协作”和“虚拟团队”，目标是把AI从“代码生成器”升级为“项目合伙人”。

这个项目非常适合几类人：编程新手，可以把它当作一个全程指导的导师，从零开始构建应用；独立开发者或小团队，可以用它来快速验证想法、搭建MVP（最小可行产品），相当于凭空多了一个经验丰富的技术团队；产品经理或项目经理，可以用更结构化的方式向AI传达复杂需求；甚至对于有经验的开发者，它也能在架构设计、代码审查、环境配置等环节提供专业的“第二意见”，帮你查漏补缺。

简单来说，Dream Creator 试图解决的是当前AI编程工具“单打独斗”、“缺乏上下文协作”的痛点。它不是让AI变得更聪明，而是让多个AI变得更“专业”和“有序”，模拟出一个真实软件开发团队的完整工作流。

1.1 核心设计思路：从“工具”到“团队”的范式转移

传统的AI编码助手，无论功能多强大，其本质都是一个“黑盒”。你输入指令，它输出结果。中间的逻辑、决策过程、备选方案，用户往往是看不见的。这种模式在处理简单、明确的任务时效率很高，但一旦遇到复杂项目，问题就暴露了：需求理解可能偏差、技术选型缺乏论证、生成的代码缺乏整体架构考量、出了问题只能回溯到最初的提示词重新生成。

Dream Creator 的设计哲学是“分而治之，协同作战”。它将软件开发这个复杂过程，拆解成产品、架构、开发、测试、运维、文档等专业领域，并为每个领域训练（或定义）一个专门的智能体。每个智能体都拥有该领域的“专业知识”和“职责范围”。例如，产品经理智能体擅长需求挖掘和沟通，架构师智能体精通各种技术栈的优劣对比。

这种设计带来了几个根本性的优势：

1. 职责清晰，专业度高：每个智能体只需要专注于自己的领域，因此其输出的建议和方案会更专业、更深入。你不会让一个测试工程师去设计数据库架构，同样，在Dream Creator里，架构问题会自动路由给架构师智能体。
2. 工作流可视化：整个开发过程从“黑盒”变成了“白盒”。你可以清晰地看到需求是如何从产品经理传递到架构师，再拆解给前后端开发的。这大大增强了过程的可控性和可理解性，尤其对新手友好。
3. 知识沉淀与复用：项目内置了一个FAQ智能体，它的职责就是记录开发过程中遇到的问题和解决方案。这意味着，团队（或者说，你）在项目A中踩过的坑，在项目B中可能就能直接避免。这模拟了真实团队中“经验积累”的过程。
4. 质量内建：代码生成后，会自动进入“代码审查”和“QA测试”环节，由专门的智能体负责。这相当于在开发流程中内置了质量关卡，而不是事后再人工检查。

这种从“单一工具”到“协同团队”的范式转移，是Dream Creator最核心的创新点。它不再追求一个“全能”的AI，而是通过组织多个“专才”AI，来达到甚至超越“全才”的效果。

2. 虚拟团队角色全解析：12个智能体如何各司其职

理解Dream Creator，关键在于理解它的12个“员工”。下面我们来逐一拆解每个智能体的角色定位、核心职责，以及它们在实际工作流中是如何互动的。这能帮你明白，当你发出一个指令时，背后究竟发生了什么。

2.1 核心管理角色：产品经理与架构师

👤 产品经理 (Product Manager)

• 角色定位：团队对外的唯一接口，你的“专属客户经理”。所有与“需求”相关的对话，都由它发起和主导。
• 核心职责：
  1. 需求采集与澄清：它会主动与你进行2-5轮对话，深入挖掘你的真实需求。比如，你说“做一个博客系统”，它会追问：“需要用户注册登录吗？”“支持Markdown编辑吗？”“评论功能需要审核吗？”。
  2. 项目协调与同步：它是团队内部的“总调度”。将清晰的需求转化为任务，分发给架构师和开发人员，并跟踪进度。
  3. 沟通桥梁：当开发人员对需求有疑问时，不是直接来问你，而是先反馈给产品经理，由产品经理整理后统一与你确认。这保证了信息传递的效率和准确性。
• 实操心得：与产品经理智能体沟通时，尽量用业务语言描述，而不是技术语言。说“我希望用户能上传图片并自动生成缩略图”，比说“我需要一个支持multer和sharp的接口”更好。前者能让它更好地理解业务场景，从而设计出更合理的功能点。

🏗️ 架构师 (Architect)

• 角色定位：技术方案的“总设计师”，决定项目的“骨架”。
• 核心职责：
  1. 技术选型：根据产品经理提供的需求，推荐前后端框架、数据库、第三方服务等。例如，针对一个高并发的实时应用，它可能会推荐Node.js + Socket.io + Redis；对于一个内容管理后台，则可能推荐React + NestJS + PostgreSQL。
  2. 架构设计：设计系统的高层结构，包括模块划分、数据流、接口设计等。它会输出类似“系统架构图”和“模块职责说明”的文档。
  3. 方案评审：对开发人员提出的具体实现方案进行审核，确保其符合整体架构原则和性能、安全要求。
• 注意事项：架构师的建议通常是“推荐性”而非“强制性”。你可以基于自己的经验或偏好提出异议。一个好的实践是，让架构师给出2-3个备选方案并分析其优劣（如开发效率、性能、可维护性、社区生态），然后由你或产品经理最终拍板。

2.2 开发与实施角色：前后端开发与环境配置

💻 前端开发者 (Frontend Developer) & ⚙️ 后端开发者 (Backend Developer)

• 角色定位：方案的“执行者”，负责将设计转化为代码。
• 核心职责：
  • 前端：负责用户界面(UI)组件开发、页面路由、状态管理、与后端API交互等。它熟悉React、Vue、Svelte等主流框架及配套生态。
  • 后端：负责服务器逻辑、API接口设计、数据库操作、身份认证、业务逻辑等。它熟悉Node.js/Express、Python/Django、Go/Gin等后端技术栈。
• 协作模式：它们之间会通过定义的“通信协议”进行接口联调。例如，后端开发者定义好API的路径、方法、请求/响应格式后，会正式通知前端开发者：“用户登录接口已就绪，文档如下...”。这模拟了真实开发中的前后端约定过程。

🔧 环境设置智能体 (Environment Setup)

• 角色定位：项目的“后勤保障”，确保代码能在正确的环境中运行。
• 核心职责：
  1. 环境探测：自动检测你当前的工作环境（操作系统、Node.js/Python版本、包管理器等）。
  2. 依赖安装：根据项目类型（如识别到package.json或requirements.txt），自动运行npm install或pip install -r requirements.txt等命令。
  3. 配置生成：创建必要的环境配置文件，如.env.example。
• 实操技巧：这个智能体大大降低了项目上手的门槛。对于新手，避免了“克隆了代码却跑不起来”的窘境。对于老手，也省去了手动敲安装命令的重复劳动。它是项目启动后第一个投入工作的“幕后英雄”。

2.3 质量保障角色：QA工程师与代码审查员

🧪 QA工程师 (QA Engineer)

• 角色定位：质量的“守门员”，专注于发现缺陷。
• 核心职责：
  1. 测试用例设计：根据需求文档，设计单元测试、集成测试的用例。例如，针对一个登录功能，它会设计“正确密码登录成功”、“错误密码登录失败”、“空密码提交提示错误”等多个用例。
  2. 测试执行与报告：在代码提交后，自动或提示运行测试套件，并生成清晰的测试报告，标明通过/失败的情况。
  3. Bug提交：发现缺陷后，它会按照规范格式创建“Bug报告”，详细描述复现步骤、预期结果和实际结果，然后提交给开发人员智能体。
• 经验之谈：QA智能体的存在，强制引入了“测试驱动开发”或至少是“质量左移”的思想。它提醒开发者，功能完成不是终点，通过测试才是。这能有效减少“看起来能用，一测就崩”的代码被提交。

🔍 代码审查员 (Code Reviewer)

• 角色定位：代码风格的“教练”和安全漏洞的“扫描仪”。
• 核心职责：
  1. 代码规范检查：检查代码是否符合预定的风格指南（如命名规范、缩进、注释等）。
  2. 潜在问题识别：检查常见的代码坏味道，如重复代码、过长的函数、复杂的条件判断等。
  3. 安全与性能审查：提示可能的安全风险（如SQL注入、XSS攻击）和性能瓶颈（如循环内重复查询数据库）。
• 注意事项：代码审查员的反馈有时可能显得“吹毛求疵”。你需要理解它的目的是提升代码的长期可维护性，而非否定你的工作。对于它提出的建议，合理的可以采纳，如果认为在特定上下文中不适用，也可以给出解释并驳回。这本身也是一个学习过程。

2.4 运维与支持角色：DevOps、调试与文档

🚀 DevOps工程师 (DevOps Engineer)

• 角色定位：负责从代码到服务的“最后一公里”。
• 核心职责：
  1. 部署配置：提供不同环境的部署指南或脚本，如本地开发、测试环境、生产环境。
  2. CI/CD流水线建议：推荐并生成GitHub Actions、GitLab CI等持续集成/持续部署的配置文件。
  3. 基础设施即代码：对于云服务，可能提供Dockerfile、docker-compose.yml或Terraform脚本的示例。
• 场景延伸：当项目需要上线时，这个智能体的价值就凸显出来了。它会告诉你需要购买什么样的服务器、如何配置域名和SSL证书、如何设置监控和日志，让项目从“本地可运行”变成“线上可访问”。

🐛 调试器 (Debugger)

• 角色定位：专治各种“疑难杂症”的“技术专家”。
• 核心职责：当程序运行出现错误（报错、崩溃、行为异常）时，调试器智能体会被激活。它会分析错误日志、堆栈跟踪，尝试定位问题的根本原因，并提供具体的修复建议。它就像是团队里那个最擅长解决线上故障的资深工程师。

📝 技术文档工程师 (Tech Writer)

• 角色定位：知识的“整理者”，让项目易于理解和维护。
• 核心职责：自动生成或更新项目文档，包括API文档、安装指南、用户手册、架构说明等。确保任何接手项目的人（包括未来的你）都能快速上手。

2.5 辅助与引导角色：FAQ库与欢迎代理

📚 FAQ代理 (FAQ Agent)

• 角色定位：团队的“集体记忆”和“知识库”。
• 核心职责：
  1. 知识沉淀：在项目开发过程中，将解决过的问题、做出的重要技术决策记录下来，并分类归档。
  2. 智能问答：当类似问题再次出现时，FAQ代理可以快速提供历史解决方案，避免重复劳动。
  3. 新人引导：新成员（或你隔了很久再看项目）可以通过查询FAQ快速了解项目背景和关键决策点。
• 核心价值：这是Dream Creator最具长期价值的特性之一。它让AI协作的过程不再是“一次性的”，而是产生了可沉淀、可复用的知识资产。

👋 欢迎代理 (Welcome Agent)

• 角色定位：用户的“第一印象”和“导航员”。
• 核心职责：
  1. 首次引导：新用户启动时，介绍Dream Creator的能力和工作流程。
  2. 项目检测：如果是在一个已有项目中启动，它会快速扫描项目结构，理解当前进度，并将上下文同步给产品经理，实现“无缝续接”。
  3. 流程导航：在整个使用过程中，当用户不确定下一步该做什么时，可以提供指引。

这12个智能体共同构成了一个功能完整、角色清晰的虚拟团队。它们之间通过一套标准的“通信协议”进行交互，确保了协作的有序和高效。

3. 实战演练：从零构建一个任务管理应用

理论说得再多，不如亲手实践一遍。让我们跟随Dream Creator的虚拟团队，完整地走一遍构建一个简单“任务管理Web应用”的流程。你会清晰地看到每个智能体在何时介入、做了什么、以及它们之间如何对话。

3.1 阶段零：项目启动与欢迎

你在Claude Code的聊天窗口中输入了/dream-creator。

👋 欢迎代理首先被激活：

“你好！我是Dream Creator的欢迎代理。检测到您正在启动一个新的Dream项目。我将为您引导整个过程。首先，让我为您介绍我们的虚拟团队...（简要介绍12个角色）。接下来，我们的产品经理将与你对接，详细沟通您的项目想法。请稍候。”

👤 产品经理随即登场，与你开始第一轮对话：

“您好，我是您的专属产品经理。很高兴为您服务！为了能为您组建最合适的团队并制定计划，我需要了解您想构建一个什么样的应用。请用您自己的话描述一下您的想法，越详细越好。”

你回答：“我想做一个在线的任务管理工具，像Trello或者Todoist那样，可以创建任务列表和卡片，能拖拽排序，最好还能设置截止日期。”

3.2 阶段一：需求深度挖掘与澄清

产品经理不会就此开始工作，它会启动2-5轮的“需求澄清对话”。这是Dream Creator区别于普通AI的关键。

👤 产品经理：

“很好的想法！为了确保我们理解一致，我需要问几个问题来细化需求：

1. 用户系统：这个应用需要用户注册和登录吗？还是先做一个单机版，所有数据存在本地浏览器？
2. 任务属性：除了标题、截止日期，任务还需要其他信息吗？比如描述、优先级（高/中/低）、标签分类？
3. 协作功能：任务需要支持多人共享和协作编辑吗？还是仅限于个人使用？
4. 数据持久化：您希望任务数据保存在哪里？如果单机版，用浏览器LocalStorage就够了吗？还是需要连接一个后端数据库？
5. 视觉风格：对UI有什么偏好吗？简洁现代，还是需要特定的主题色？”

你逐一回答：

1. 先做个人版，不需要登录，数据存本地就行。
2. 任务需要有标题、描述、截止日期、优先级（高/中/低）和状态（待办/进行中/已完成）。
3. 第一期先不做协作，个人使用。
4. 数据用浏览器本地存储（LocalStorage），这样简单。
5. UI希望简洁清晰，类似Notion那种风格，支持暗色/亮色主题切换。

👤 产品经理：

“感谢您的详细说明！我已经清晰记录了需求。总结一下，我们将构建一个个人单机版任务管理Web应用，核心功能包括：任务增删改查、拖拽排序、按属性（优先级、状态）筛选、数据本地存储、以及暗色/亮色主题切换。需求已确认，我将立即召集架构师和开发团队启动项目。”

至此，需求采集阶段完成。产品经理将一份结构化的《产品需求文档》通过内部协议，发送给了架构师。

3.3 阶段二：技术架构设计与选型

🏗️ 架构师收到需求后开始工作。它不会直接写代码，而是先输出一份《技术方案设计书》。

🏗️ 架构师(在团队内部频道发布)：

From: 架构师To: 产品经理、前端开发、后端开发Type: 方案设计Priority: HighSubject: 个人任务管理应用技术方案

技术栈推荐：

1. 前端：鉴于需求明确、追求开发效率和现代体验，推荐使用React + TypeScript。React组件化非常适合此类UI交互复杂的应用；TypeScript能提升代码可靠性。
2. 状态管理：由于是单页应用且状态不复杂，初期可使用React Context API或Zustand。后者更轻量，推荐Zustand。
3. UI组件库：为快速实现Notion风格和主题切换，推荐使用shadcn/ui或Tailwind CSS自行构建。shadcn/ui是基于Tailwind的现成高质量组件，风格接近需求。
4. 拖拽库：为实现看板拖拽，推荐@dnd-kit库，它是目前React生态下最强大灵活的拖拽解决方案。
5. 数据持久化：前端本地存储使用浏览器IndexedDB，配合idb或Dexie.js库。这比LocalStorage容量更大、性能更好，且支持异步操作。
6. 构建工具：使用Vite作为构建工具，启动和热更新速度极快。

架构概要：

• 采用经典的单页应用(SPA)架构。
• 状态流：用户操作 -> 更新Zustand Store -> 触发UI重渲染 -> 异步同步到IndexedDB。
• 组件规划：应用根组件、侧边栏（筛选）、主看板区域、任务卡片组件、任务编辑模态框。

请前端开发评估此方案，后端开发本期暂不参与。

💻 前端开发者收到方案后回复：

From: 前端开发To: 架构师Type: 反馈Priority: MediumSubject: 技术方案评估

方案评估通过。补充建议：

1. 同意使用React + TS + Vite + Zustand + shadcn/ui + @dnd-kit + Dexie.js这个技术栈组合。
2. 建议初始化项目使用npm create vite@latest并选择React+TS模板。
3. 关于主题切换，shadcn/ui本身支持，我们需按照其文档配置CSS变量。
4. 请求环境设置智能体先行准备基础开发环境。

🔧 环境设置智能体被触发，它检测到当前目录为空，于是开始行动：

检测到新项目初始化。正在执行以下命令：

npm create vite@latest my-task-app -- --template react-ts cd my-task-app npm install

正在安装额外依赖：

npm install zustand dexie @dnd-kit/core @dnd-kit/sortable @dnd-kit/utilities npm install -D tailwindcss postcss autoprefixer npx tailwindcss init -p

正在配置shadcn/ui... 项目基础环境已就绪，可以开始开发。

至此，技术设计阶段完成，项目骨架已搭建。

3.4 阶段三：核心功能迭代开发

接下来进入具体的功能开发循环，即“DREAM迭代”。每个功能迭代都遵循类似的流程：产品经理拆解任务 -> 开发编码 -> 代码审查 -> QA测试 -> 文档更新。

迭代1：实现任务数据模型与存储

1. 👤 产品经理：创建任务“创建、读取、更新、删除”的详细用户故事。
2. 💻 前端开发：使用Dexie.js定义IndexedDB数据库模式和操作类（TaskDB），创建Zustand Store来管理任务状态。
3. 🔍 代码审查员：审查代码，提示“数据库版本升级逻辑需要更健壮”、“Store中的异步操作需要错误处理”。
4. 💻 前端开发：根据审查意见修复代码。
5. 🧪 QA工程师：编写单元测试，验证Store和DB的CRUD操作，并执行测试。
6. 📝 技术文档：生成TaskDB和Store的API使用说明。
7. 📚 FAQ代理：记录“如何在React + TS项目中集成Dexie.js”的步骤和常见陷阱。

迭代2：实现任务看板UI与拖拽

1. 💻 前端开发：基于shadcn/ui的Card组件开发任务卡片，使用@dnd-kit实现列表和卡片的拖拽排序。
2. 🔍 代码审查员：提示“拖拽时的视觉反馈可以优化”、“移动端触摸事件需要测试”。
3. 💻 前端开发：优化拖拽占位符样式，添加触摸事件支持。
4. 🧪 QA工程师：进行跨浏览器（Chrome, Firefox, Safari）和跨设备（桌面、手机模拟器）的拖拽功能测试。

迭代3：实现任务编辑与主题切换...（流程类似）

在整个过程中，👤 产品经理始终作为你的接口。每个迭代完成后，它会向你演示成果，并询问“这是否符合您的预期？”或“接下来您想优先开发哪个功能？”。你可以随时提出调整意见。

3.5 阶段四：问题排查与知识沉淀

假设在开发过程中，你发现拖拽后任务状态有时没保存。

1. 你向产品经理反馈：“拖拽排序后，刷新页面顺序又回去了。”
2. 👤 产品经理将问题转给🐛 调试器。
3. 🐛 调试器分析后得出结论：“问题在于拖拽结束事件中，更新Zustand Store和保存到IndexedDB的操作是同步的，但IndexedDB是异步操作，可能存在Store状态已更新但DB保存失败或延迟的情况。建议将保存操作封装为Promise，并在Store更新后await其完成。”
4. 🐛 调试器将解决方案同时发送给💻 前端开发（去修复代码）和📚 FAQ代理（记录此问题）。
5. 💻 前端开发修复Bug。
6. 🧪 QA工程师重新测试拖拽持久化功能，确认问题解决。
7. 📚 FAQ代理将“拖拽状态持久化异步问题”记录到知识库。下次任何智能体或用户遇到类似问题，都能快速检索到解决方案。

通过这个完整的实战流程，你可以看到Dream Creator如何将一个模糊的想法，通过多智能体有条不紊的协作，一步步变成可运行、可测试、有文档的软件。这不仅仅是生成代码，更是模拟了一个规范的、可持续的软件开发过程。

4. 安装、配置与高级使用指南

了解了核心概念和工作流，接下来我们看看如何将它用起来。Dream Creator的设计目标是尽可能降低使用门槛，提供了多种安装方式。

4.1 安装方式详解与选择建议

方式一：npm全局安装（推荐给频繁使用者）这是最标准、最方便的方式，尤其适合开发者。

npm install -g dream-creator

安装后，你就可以在任何支持Claude Code技能的编辑器或工具中，通过输入/dream-creator来调用它。

• 优点：一次安装，随处使用；便于通过npm update -g进行升级。
• 缺点：需要Node.js环境，并且需要全局安装权限。

方式二：npx直接运行（推荐给尝鲜或低频使用者）如果你不想污染全局环境，或者只是想临时试用，npx是最佳选择。

npx dream-creator

npx会自动下载并运行最新版本的dream-creator，无需预先安装。

• 优点：无需安装，永远使用最新版；环境干净。
• 缺点：每次运行都需要下载（有缓存会快些），首次启动稍慢。

方式三：克隆仓库手动安装（推荐给深度定制或贡献者）如果你想研究其内部机制，或者打算修改智能体的行为定义，这是唯一的选择。

git clone https://github.com/Xianyu33666/Dream-Creator.git cd Dream-Creator # Linux/macOS ./install.sh # Windows PowerShell .\install.ps1

手动安装脚本会将技能文件复制到你的AI工具（如Claude Code、Cursor）指定的技能目录中。

• Claude Code (个人版)：~/.claude/skills/dream-creator/
• Cursor：~/.cursor/skills/dream-creator/
• 其他兼容工具：请查看对应工具的技能目录文档。
• 优点：完全可控，可以查看和修改所有智能体定义文件（在/agents目录下）。
• 缺点：步骤稍多，升级需要手动拉取新代码并重新运行脚本。

个人建议：对于大多数用户，直接从npx开始是最佳选择。确定它对你的工作流有帮助后，再考虑npm全局安装以获得更好的体验。

4.2 在不同AI工具中的集成与调用

Dream Creator 本质上是一个遵循了特定格式的“技能”或“插件”。它主要兼容那些基于Claude模型并支持技能系统的工具。

• 在 Claude Code 中：这是它的“原生”环境。安装后，直接在聊天输入框键入/dream-creator并回车，即可唤醒。
• 在 Cursor 中：Cursor 内置了类似Claude Code的技能机制。安装后，同样通过/dream-creator调用。由于Cursor深度集成IDE，它在代码生成和上下文理解上可能有额外优势。
• 在 OpenCode 或其他兼容工具中：原理相同，确保技能文件被放置在正确的技能目录下即可调用。

注意：技能的生效依赖于底层AI模型对多轮对话和长上下文的理解能力。因此，使用最新、能力最强的Claude模型（如Claude 3.5 Sonnet）通常会获得最佳协作体验。

4.3 智能体通信协议深度解读

智能体之间能有效协作，全靠一套定义清晰的“通信协议”。这不是真正的网络协议，而是约束AI对话格式的一套模板。理解它，你就能看懂团队内部的“聊天记录”，甚至能进行高级定制。

协议的基本格式如下，在每个智能体发言时都会遵循：

## Agent Communication **From**: [发送方角色，如 Product Manager] **To**: [接收方角色，如 Architect] **Type**: [消息类型：Request(请求)/Response(响应)/Escalation(升级)/Feedback(反馈)/Notification(通知)] **Priority**: [优先级：Critical(紧急)/High(高)/Medium(中)/Low(低)] --- ### Subject: [消息主题，一句话概括] ### Details [详细内容，描述问题、需求或方案] ### Required Action [希望接收方执行的具体操作]

优先级策略是保证效率的关键：

• Critical (紧急)：用于生产环境崩溃、安全漏洞等需要立即停止手头一切工作来处理的事件。响应要求：立即。
• High (高)：用于阻塞开发流程的关键问题，如核心接口定义错误、重大逻辑缺陷。响应要求：1小时内。
• Medium (中)：常规的技术咨询、方案评审、需求澄清。响应要求：4小时内。大部分日常协作属于此级别。
• Low (低)：知识分享、非关键信息同步、文档更新等。响应要求：24小时内。

消息类型决定了交互模式：

• Request/Response：最常见的类型，用于任务分发和答复。
• Escalation：当某个智能体无法解决问题时，向上级或更专业的角色“升级”问题。例如，前端开发遇到一个复杂的性能优化问题，可以升级给架构师。
• Feedback：用于代码审查、设计评审等场景，提供修改意见。
• Notification：用于广播信息，如“项目第一阶段已完成”、“数据库已更新，请同步模型”。

实操技巧：当你作为“用户”旁观时，可以要求产品经理“展示一下团队内部最近关于XX功能的讨论记录”。它会以这种协议格式呈现对话，让你清晰了解决策过程，这对于学习或审计非常有帮助。

4.4 自定义与扩展你的虚拟团队

Dream Creator 的12个智能体是开箱即用的默认配置。但你的项目可能不需要这么多角色，或者需要一些特殊角色（比如“数据科学家”、“AI模型调优师”）。

如何调整团队构成？智能体的定义文件位于项目/agents目录下（如果你用克隆方式安装）。每个[role-name]-agent.md文件都定义了该角色的“人设”、职责和响应模板。

• 禁用某个角色：你可以简单地注释掉或删除该角色的定义文件引用（在SKILL.md主文件中）。例如，如果你的项目纯粹是前端，可以暂时禁用后端开发和DevOps。
• 修改角色行为：你可以编辑这些Markdown文件，修改角色的“性格”、专精领域或响应风格。比如，你可以让QA工程师更“严格”，或者让产品经理更“注重商业价值”。

如何增加自定义角色？

1. 在/agents目录下复制一个现有角色的文件，例如复制frontend-developer.md为>问题现象可能原因解决方案输入/dream-creator无反应1. 技能未正确安装。
   2. 当前AI工具不支持技能系统。1. 检查安装路径是否正确。尝试用npx dream-creator直接运行。
   2. 确认你使用的是Claude Code、Cursor等支持技能的工具。智能体陷入循环提问需求描述过于模糊或存在矛盾，AI无法理解。对产品经理说“停止当前问题，我们重新梳理”。然后，用更结构化、更具体的方式描述需求。可以尝试先自己写一个简单的用户故事或功能列表。生成的代码有错误或无法运行1. AI的“幻觉”（生成不存在的API）。
   2. 依赖版本冲突。
   3. 环境配置缺失。1.将错误信息直接粘贴给调试器(🐛 Debugger)智能体，它通常能给出修复方案。
   2. 检查package.json中的依赖版本，尝试安装更稳定的大版本。
   3. 确保环境设置智能体已运行，或手动运行npm install/pip install。团队协作流程显得“慢”或“啰嗦”对于非常简单的任务，多轮交互可能显得冗余。对于微型任务（如写一个工具函数），直接使用普通的AI对话可能更快。Dream Creator的优势在于管理复杂、多模块的项目。你可以告诉产品经理“这是一个简单功能，请直接让前端开发实现，跳过详细设计和评审”。如何接续一个已有的项目？在已有项目目录中启动/dream-creator。欢迎代理和产品经理会尝试分析现有代码结构，理解项目上下文。主动提供信息是关键，告诉产品经理“这是一个XX项目，基于XX技术栈，目前已经完成了A、B功能，现在需要开发C功能”。智能体给出了我不喜欢的技术方案架构师的推荐基于通用最佳实践，未必适合所有场景。直接提出你的偏好。例如：“架构师，我了解你推荐React，但我这个项目必须使用Vue，请基于Vue3 + Composition API重新设计架构。” 智能体会尊重你的最终决策。

   5.2 当前版本的局限性

   认识到局限性，才能更好地利用它。

   1. 对超大型、遗留系统的理解有限：虽然能分析已有项目，但对于代码量巨大、架构复杂的遗留系统，其理解深度和上下文窗口可能不足，给出的重构建议可能比较表面。
   2. “虚拟”团队的资源是无限的，但“真实”的AI算力是有限的：多轮对话和多个智能体响应会消耗大量Tokens（AI对话的长度单位）。在复杂项目中，可能会很快达到单次对话的长度限制，导致需要开启新对话，丢失部分上下文。
   3. 决策依赖你的输入质量：“垃圾进，垃圾出”原则依然适用。如果你无法清晰表达需求，产品经理也无法问出正确的问题，最终产出的方向就可能跑偏。
   4. 无法真正执行命令或访问网络：它只能生成代码、命令和建议，不能替你执行npm install或git push。环境设置智能体也只是生成命令提示，需要你手动（或授权）执行。
   5. 知识截止日期：其知识基于训练数据的截止日期（例如Claude 3.5是2024年7月）。对于此后出现的最新技术或框架，它可能不了解或了解不深。

   5.3 最大化Dream Creator价值的实战心得

   基于上述局限，这里有一些从我实际使用中总结出的“最佳实践”：

   心得一：把你当成“CTO”或“技术负责人”，而不是“实习生”不要指望把问题丢给它就能得到完美答案。你的角色更像是这个虚拟团队的“技术领导”。你需要：

   • 设定清晰的目标：用业务语言描述“要解决什么问题”，而不是技术语言描述“要怎么实现”。
   • 做出关键决策：当架构师给出多个选项时，你需要基于项目预算、团队技能、时间线来拍板。
   • 进行阶段评审：在每个迭代结束时，认真检查产出，提供明确的“通过”或“修改”反馈。你的反馈是团队学习优化的关键。

   心得二：善用“阶段性对话”，管理Token消耗对于大项目，不要试图在一个对话中完成所有事情。

   1. 对话A：需求与架构。只进行到产出技术方案和项目初始化。然后保存对话。
   2. 对话B：核心模块开发。载入对话A的结论，专注于开发用户管理模块。完成后再保存。
   3. 对话C：另一个模块开发。以此类推。
   4. 对话Z：集成与部署。最后，在一个新对话中，汇总各模块成果，进行集成测试和部署配置。
      • 技巧：在每个新对话开始时，让产品经理“回顾我们之前达成的共识”，并粘贴上一阶段的关键结论（如技术栈、数据库设计图），帮助AI快速恢复上下文。

   心得三：主动引导，而非被动等待如果感觉智能体在某个问题上绕圈子，直接打断并给出明确指令。

   • 反面例子：“怎么实现登录？”（可能引发一系列关于OAuth、JWT、Session的复杂讨论）。
   • 正面例子：“产品经理，我们第一期只需要一个最简单的模拟登录。请让前端开发实现一个表单，输入任意用户名即可进入系统，状态用React Context存着就行。后端和数据库登录二期再做。” 清晰的边界和约束，能极大提升效率。

   心得四：将FAQ库作为你的“第二大脑”养成主动查阅和丰富FAQ的习惯。在项目开始时，可以手动向FAQ代理添加一些项目特定的约束（如“本项目必须使用公司内部的UI组件库XXX”）。在开发过程中，遇到任何解决了的小问题，都问一句“FAQ代理，请把刚才解决的YYY问题记录到知识库”。久而久之，这个项目就拥有了一个高度定制化的、可传承的知识库，价值远超代码本身。

   Dream Creator 代表了一种新的AI协作范式。它可能不是执行某个单一编码任务最快的工具，但在管理一个软件项目从构思到上线的完整生命周期上，它提供了前所未有的结构化和可管理性。对于独立开发者、创业团队或教育场景，它就像一个永不疲倦、涵盖各领域专家的“影子团队”，极大地降低了高质量软件开发的认知负荷和启动成本。最关键的是，通过观察这个虚拟团队的协作，你本身也在学习一个规范的软件开发流程，这对于提升个人或团队的工程能力，有着潜移默化的巨大价值。