企业官网建设流程全解析

1. 项目概述：你的虚拟AI开发团队

如果你曾经尝试过用AI助手来写代码，大概率会遇到这样的场景：你描述了一个需求，AI助手给你生成了一堆代码，但当你运行起来，发现不是这里少个依赖，就是那里逻辑不对，或者压根没考虑部署和测试。你就像一个项目经理，在跟一个“全栈但样样不精”的初级程序员单打独斗，沟通成本高，结果还不尽如人意。

Dream Creator 这个项目，就是为了彻底解决这个问题而生的。它不是一个单一的AI助手，而是一个由12个高度专业化的AI智能体组成的“虚拟开发团队”。当你输入/dream-creator这个指令时，你启动的不是一个工具，而是一个完整的、拥有明确分工的协作流程。这就像你瞬间拥有了一支小型创业团队：产品经理负责和你沟通需求，架构师设计技术方案，前后端工程师负责编码，QA工程师写测试用例，DevOps工程师规划部署，甚至还有专门的文档工程师和调试专家待命。

这个项目的核心价值在于，它将软件开发中复杂的协作流程，通过多智能体系统（Multi-Agent System）进行了自动化建模。每个智能体都专注于自己的领域，并且遵循一套预设的通信协议进行交互、提问和任务交接。对于初学者，它像一个手把手教学的导师团；对于有经验的开发者，它则是一个能极大提升效率、减少低级错误的“超级副驾驶”。无论你是想从零开始一个个人项目，还是想快速分析、迭代一个现有代码库，Dream Creator 都试图提供一个更接近真实团队协作的智能体验。

2. 核心设计思路：为什么是12个智能体？

很多AI编码工具的思路是让一个模型“变得更聪明”，试图让它无所不能。但Dream Creator走了一条不同的路：专业化分工与流程协作。这个设计的背后，是对软件开发本质的深刻理解。

2.1 模拟真实团队的职能划分

在真实的软件团队中，角色分工是效率和质量的基础。产品经理定义“做什么”，架构师决定“怎么做”，开发者负责“实现”，QA确保“没问题”，运维关心“跑得稳”。Dream Creator的12个智能体正是对这些角色的映射：

• 产品经理（Product Manager）：这是你和团队的“接口”。它的核心任务不是直接写代码，而是通过2-5轮的对话，像剥洋葱一样把你的模糊想法（“我想做个记账App”）层层细化，转化为清晰、可执行的产品需求文档（PRD）。它会主动提问：“这个记账App需要支持多用户吗？”、“数据需要云端同步吗？”、“预算是多少？”。这个过程至关重要，它避免了后续开发因需求不清而返工。
• 架构师（Architect）：拿到PRD后，架构师智能体开始工作。它不会立刻写代码，而是先做技术选型。是基于React还是Vue？后端用Node.js还是Python Django？数据库选MySQL还是MongoDB？它会根据项目规模、团队技能（假设）、性能要求和你的偏好，给出一个权衡后的技术栈建议，并绘制出简单的系统架构图。这个步骤为整个项目奠定了技术基调。
• 前端/后端开发者（Frontend/Backend Developer）：这两个智能体是执行层。它们根据架构师的设计，分别生成用户界面和服务器逻辑的代码。关键不在于它们各自能写多复杂的代码，而在于它们之间的“接口约定”是清晰的。例如，后端开发者生成一个RESTful API接口GET /api/transactions，前端开发者就知道如何去调用并渲染这个数据。
• QA工程师 & 代码审查员（QA Engineer & Code Reviewer）：这是质量双保险。代码审查员像一位资深同事，检查生成的代码是否符合规范、有无安全漏洞、逻辑是否清晰。QA工程师则负责生成单元测试、集成测试的代码框架，甚至是一些边界测试用例（比如输入负数金额会怎样？）。它们的存在，确保了产出的代码不仅仅是“能跑”，更是“健壮”和“可维护”的。
• DevOps工程师 & 环境配置（DevOps Engineer & Environment Setup）：项目最终要能运行和部署。环境配置智能体会自动检测你的开发环境（比如你用的是Windows的VS Code还是macOS的终端），并生成对应的依赖安装命令（如npm install或pip install -r requirements.txt）。DevOps工程师则负责规划如何将应用部署到服务器，可能会生成Dockerfile、docker-compose.yml或简单的CI/CD流水线配置。
• 调试员、技术写手、FAQ代理、欢迎代理（Debugger, Tech Writer, FAQ Agent, Welcome Agent）：这些是支持性角色。调试员在项目运行出错时介入分析；技术写手自动生成README、API文档；FAQ代理像一个不断学习的知识库，记录常见问题和解法；欢迎代理则是新用户的引导员。

2.2 智能体间的通信协议：协作的基石

让12个“AI”有序协作，而不是各说各话，靠的是一套设计精巧的“通信协议”。这可以说是Dream Creator最核心的“软实力”。协议规定了智能体之间如何传递信息，格式如下：

## Agent Communication **From**: 前端开发者 **To**: 产品经理 **Type**: 请求澄清 **Priority**: 中 --- ### 主题：关于用户登录表单的交互细节确认 ### 详情 根据PRD，用户登录需要邮箱和密码。但我需要确认： 1. 是否需要“记住我”复选框？ 2. 密码输入错误时，是实时提示还是提交后统一提示？ 3. 是否有第三方登录（如微信、谷歌）的需求？ ### 所需行动 请与用户确认以上交互细节，以便我继续实现UI组件。

这套协议有几个关键设计点：

1. 明确的发送方和接收方：避免了信息广播造成的混乱。
2. 类型（Type）定义：分为请求、响应、升级、反馈、通知，明确了信息的意图。
3. 优先级（Priority）系统：分为关键、高、中、低，并规定了响应时间期望。比如，生产环境Bug会被标记为“关键”，要求相关智能体立即响应；而一个文档优化建议可能是“低”优先级。
4. 结构化的内容：“主题-详情-所需行动”的三段式，确保信息精准、无歧义，接收方一看就知道要做什么。

正是这套协议，使得“前端开发者遇到不确定的UI细节时，知道该向产品经理发起一个‘请求澄清’类型的通信，而不是自己瞎猜或者直接去问用户”成为可能。它模拟了真实团队中JIRA ticket、Slack消息或站会沟通的流程。

3. 实战体验：从零创建一个待办事项应用

理论说得再多，不如亲手跑一遍。我们以创建一个“带用户认证的待办事项（Todo List）Web应用”为例，完整走一遍Dream Creator的工作流。假设我们已经在Claude Code中安装了该技能。

3.1 启动与需求澄清阶段

在Claude Code的聊天框中，我输入：

/dream-creator

欢迎代理首先被激活。它发送了一条欢迎信息，并简要介绍了团队。紧接着，它和产品经理智能体完成交接。

产品经理开始与我对话：

PM：你好！我是你的产品经理。很高兴为你启动一个新项目。请描述一下你想构建的应用。我：我想做一个在线的待办事项列表，用户需要先注册登录才能使用。PM：很好的想法！为了确保我们理解一致，我需要问几个问题来细化需求：

1. 用户系统：除了基础的邮箱/密码注册登录，是否需要第三方登录（如GitHub、Google）？
2. 待办事项功能：除了创建、查看、标记完成、删除，还需要优先级（高/中/低）、标签分类、截止日期提醒吗？
3. 数据持久化：用户的数据需要永久保存，并能在不同设备间同步吗？
4. 部署目标：这个应用你希望最终部署到公共网络供他人访问，还是仅在本地运行？
5. 技术偏好：你对前端或后端框架有偏好吗？（比如喜欢React还是Vue？）

经过几轮这样的问答，PM智能体会总结出一份简明的需求摘要，并再次向我确认。这个过程大约会进行2-5轮，直到需求足够清晰。这是整个流程中人与AI交互最密集的部分，也是决定项目方向是否正确的最关键一步。

3.2 架构设计与技术选型

需求确认后，PM将需求摘要通过通信协议发送给架构师。

架构师开始分析：

架构师（内部推理）：这是一个典型的CRUD（增删改查）应用，带有用户认证。需求明确，复杂度中等。考虑到现代Web开发流行度和快速原型能力，我推荐以下技术栈：

• 前端：React + TypeScript + Vite。React生态丰富，TypeScript能提升代码质量，Vite开发体验极快。UI库选用轻量级的Chakra UI或Ant Design。
• 后端：Node.js + Express + TypeScript。与前端技术栈统一，利用JavaScript全栈优势。数据库使用PostgreSQL（关系型，适合此类结构化数据），用Prisma作为ORM（对象关系映射）工具来简化数据库操作。
• 认证：采用JWT（JSON Web Token）无状态认证方案。用户登录后，服务器签发一个Token，前端将其存储在本地（如localStorage），后续请求在Header中携带此Token。
• 部署：整体可容器化。为前后端分别编写Dockerfile，使用docker-compose在本地编排。生产环境可部署到任何支持Docker的平台（如Railway、Fly.io）。

架构师会将这个方案，连同简单的系统组件图（用户 -> 前端React App -> 后端Express API -> PostgreSQL数据库），一并反馈给PM，并由PM呈现给我确认。如果我提出异议（比如“我想用Python Flask做后端”），架构师会重新评估并调整方案。

3.3 项目生成与环境搭建

方案确认后，架构师会牵头，协同环境配置智能体，开始生成项目骨架代码。

1. 创建项目结构：在我的工作区，会生成一个标准的项目文件夹。

   my-todo-app/ ├── frontend/ # React前端项目 │ ├── package.json │ ├── vite.config.ts │ ├── src/ │ └── ... ├── backend/ # Express后端项目 │ ├── package.json │ ├── src/ │ └── ... ├── docker-compose.yml # 本地开发环境编排 └── README.md # 项目总览

2. 编写核心配置文件：环境配置智能体会自动生成前后端的package.json，包含所有必要的依赖（如react,express,jsonwebtoken,prisma等）。同时，它会检测到我当前在VS Code中工作，可能会在项目根目录生成一个.vscode/extensions.json文件，推荐我安装ESLint、Prettier等插件以提升开发体验。

3. 提供一键启动命令：在生成的README中，会清晰地写明：

   # 1. 安装依赖 cd backend && npm install cd ../frontend && npm install # 2. 启动数据库（使用Docker） docker-compose up -d postgres # 3. 运行数据库迁移 cd backend && npx prisma migrate dev # 4. 启动开发服务器（两个终端） # 终端A: cd backend && npm run dev # 终端B: cd frontend && npm run dev

此时，技术写手智能体会介入，为这个新生成的项目编写初步的文档，解释项目结构、技术栈和启动步骤。

3.4 功能迭代与团队协作

项目骨架搭好后，就进入了“功能迭代”的循环。假设我们第一个迭代是实现用户注册登录功能。

1. PM分配任务：PM根据需求，创建一个“迭代任务”，描述为“实现用户注册与登录API及前端页面”。
2. 后端开发者实现API：后端开发者智能体开始工作。它会：
   • 使用Prisma定义User数据模型（字段：id, email, passwordHash, name等）。
   • 生成prisma/schema.prisma文件。
   • 创建/api/auth/register和/api/auth/login的路由、控制器和业务逻辑。
   • 在注册逻辑中，使用bcrypt库对密码进行哈希存储（这是一个重要的安全实践，智能体会自动采用）。
   • 在登录逻辑中，验证密码后，使用jsonwebtoken库生成一个JWT Token返回给前端。
3. 代码审查员介入：后端开发者的代码提交后（在AI的上下文中模拟），代码审查员会立刻对其进行审查。它可能会提出：

   审查意见：在注册接口中，建议增加对邮箱格式的验证（使用正则表达式），并检查邮箱是否已被注册，返回明确的错误信息。密码强度规则目前缺失，建议至少要求8位，包含字母和数字。 后端开发者根据审查意见修改代码。

4. QA工程师编写测试：同时，QA工程师会根据这个功能点，在backend/tests/目录下生成对应的单元测试和集成测试文件，测试注册、登录的成功和失败场景（如重复邮箱、错误密码）。
5. 前端开发者实现界面：后端API就绪后，前端开发者开始构建注册和登录页面。它会创建React组件，使用axios或fetch调用后端API，并处理响应（如登录成功后将Token保存到localStorage，并跳转到主页）。
6. 循环与集成：前端代码同样会经过代码审查员的审查和QA工程师的测试。DevOps工程师可能会检查Docker配置是否需要调整以支持新的环境变量（如JWT密钥）。

在整个过程中，如果任何一个智能体遇到不确定的问题（比如前端开发者不确定登录后跳转的页面URL），它会通过通信协议向PM发起“请求澄清”。PM可能会直接回答，也可能再次向我（用户）提问。这就形成了一个闭环的、有反馈的协作流程。

4. 深度解析：多智能体系统的优势与挑战

使用Dream Creator一段时间后，我对这种多智能体协作模式的优势和当前面临的挑战有了更深的理解。

4.1 显著优势：超越单智能体的体验

1. 需求理解的深度和准确性大幅提升：单一AI助手容易陷入“你说什么我就做什么”的被动模式。而PM智能体主动的、多轮的需求澄清，极大地降低了因初始需求模糊导致的后期返工风险。它像一个真正的产品经理一样，在帮你做“需求挖掘”。
2. 代码质量更有保障：有了专职的代码审查员和QA工程师，生成的代码不再是“一次性产物”。审查员会关注代码风格、潜在漏洞和最佳实践；QA工程师则强制引入了测试思维。这相当于为你的代码上了一道“质量保险”。
3. 技术决策更合理：架构师智能体提供的不是随机的技术选型，而是基于项目需求、社区趋势和最佳实践的权衡建议。对于技术选型有选择困难症的新手来说，这无疑是指路明灯。
4. 项目可维护性增强：环境配置和DevOps智能体生成的标准化项目结构、Docker配置和部署指南，让项目从一开始就具备了良好的可维护性和可移植性。技术写手生成的文档也省去了事后补文档的麻烦。
5. 学习价值高：观察整个团队的协作过程，对于初学者而言，本身就是一次完整的、规范的软件开发流程教学。你能看到从想法到产品，中间需要经历哪些步骤，每个角色关心什么。

4.2 当前挑战与局限性

当然，作为一个前沿的探索项目，Dream Creator在实际使用中也会遇到一些挑战：

1. 上下文长度与成本限制：这是最大的技术瓶颈。12个智能体的完整工作流需要消耗巨大的AI模型上下文（Context）。每次智能体切换和通信，都需要在上下文里记录和传递信息。这可能导致在复杂项目中，上下文很快被耗尽，使得靠后的智能体“忘记”了之前的需求和决策。同时，这也意味着更高的API调用成本。
2. “幻觉”问题的链式传递：如果某个智能体（尤其是架构师）在早期做出了一个错误的技术判断或生成了有问题的代码，这个错误可能会被后续的智能体当作“既定事实”继承下去，导致问题在流程后期才暴露，排查成本高。
3. 通信开销与效率：过于结构化的通信协议虽然清晰，但在处理简单任务时可能显得繁琐。有时你会觉得，直接告诉一个“全能”的AI“给我写个登录页面”反而更快。多智能体系统的优势在复杂、长期的项目中才能完全体现。
4. 对用户引导的依赖：整个系统的运转非常依赖于初期PM与用户的高质量对话。如果用户自己都不清楚要什么，或者无法准确回答PM的问题，那么后续流程的质量就会大打折扣。这要求用户具备一定的“产品思维”。
5. “智能体”的深度和专业度：目前的智能体更多是基于提示词（Prompt）工程定义的“角色”，其专业深度依赖于底层大模型（如Claude）本身的能力。它们还无法像真正的领域专家那样，拥有极其深厚的、细节性的知识（例如，针对特定性能瓶颈的数据库深度调优）。

5. 安装、配置与高级使用技巧

5.1 多种安装方式详解

项目提供了几种安装方式，适应不同用户的使用习惯。

方式一：npm全局安装（最推荐）这是最简洁的方式，前提是你的系统已经安装了Node.js。

npm install -g dream-creator

安装后，你就可以在任何支持Claude Code技能的编辑器里直接使用/dream-creator命令了。它的原理是将技能文件下载到全局的npm包目录下，并被Claude Code自动识别。

注意：如果你遇到权限问题（尤其在macOS/Linux上），可能需要使用sudo npm install -g dream-creator。但更推荐的做法是使用Node版本管理工具（如nvm），它可以在用户目录下管理Node和全局包，避免使用sudo。

方式二：使用npx（免安装体验）如果你只是想快速体验一下，不想污染全局环境，npx是绝佳选择。

npx dream-creator

npx会临时下载并运行dream-creator包，运行完毕后不会留下永久文件。适合“试用”。

方式三：克隆源码手动安装对于开发者，或者想研究、修改技能内部逻辑的用户，推荐这种方式。

git clone https://github.com/Xianyu33666/Dream-Creator.git cd Dream-Creator # Linux/macOS chmod +x install.sh ./install.sh # Windows PowerShell (以管理员身份运行) .\install.ps1

手动安装脚本install.sh或install.ps1做的事情很简单：将agents/和references/等目录下的Markdown文件，复制到你的AI工具（如Claude Code）指定的技能目录中。例如，对于Claude Code个人版，通常是~/.claude/skills/dream-creator/。

5.2 技能目录结构与自定义

理解技能目录结构，是进行高级自定义的关键。以Claude Code为例，安装后的目录类似：

~/.claude/skills/dream-creator/ ├── SKILL.md # 技能主入口文件，定义了触发命令和基础流程 ├── agents/ # 12个智能体的定义文件 │ ├── product-manager.md │ ├── code-architect.md │ └── ... └── references/ # 参考模板和指南 ├── dream-template.md └── framework-guide.md

自定义智能体行为：如果你觉得默认的“产品经理”提问不够深入，或者“架构师”的技术栈偏好不符合你的团队，你可以直接修改对应的.md文件。例如，打开agents/code-architect.md，你可以修改其中关于技术选型的逻辑提示词，让它更倾向于选择你公司内部常用的技术栈（比如把推荐数据库从PostgreSQL改成MySQL）。

添加新的通信场景：你还可以在agents/communication-protocol.md中定义新的智能体协作模式。比如，你觉得缺少一个“安全审计”角色，你可以创建一个security-auditor.md文件，并在协议中增加“开发者 -> 安全审计员 -> 代码审查员”的代码安全审查流程。

重要提示：修改这些文件后，需要重启你的AI工具（如Claude Code），或者重新加载技能，修改才能生效。自定义需要你对提示词工程有一定了解，并且每次项目更新时，需要注意合并冲突。

5.3 与现有项目集成

Dream Creator不仅用于从零创建新项目，也擅长分析和迭代现有项目。用法很简单：在你的现有项目根目录下，打开Claude Code并输入/dream-creator。

欢迎代理和环境配置智能体会首先被激活。它们会扫描当前目录的文件结构、package.json、requirements.txt等，试图理解这是一个什么类型的项目（React项目？Python Django项目？）。

然后，产品经理会介入，但它的问题会变成：“我检测到你正在一个现有的React项目中。你是想为这个项目添加新功能，还是分析现有代码的结构和问题？” 你可以回答：“我想为这个项目添加一个黑暗模式切换功能。” 随后，整个多智能体团队就会基于你现有的代码库上下文，开始协作：架构师评估改动影响，前端开发者修改主题相关的组件和Context，QA工程师为新增的功能编写测试用例。

这个特性使得Dream Creator可以无缝融入你已有的开发工作流，成为一个强大的“项目增强引擎”。

6. 常见问题与排错实录

在实际使用中，你可能会遇到一些问题。以下是我和社区用户遇到的一些典型情况及解决方法。

6.1 安装与启动问题

问题1：输入/dream-creator无反应，或提示“未找到技能”。

• 可能原因A：技能未正确安装到AI工具的技能目录。
• 排查：检查你的AI工具（如Claude Code）的技能目录路径是否正确。可以尝试通过npm list -g dream-creator查看全局安装位置，然后手动核对文件是否被复制到了正确的技能子目录下。
• 解决：重新运行安装脚本，或手动将克隆的仓库文件复制到技能目录。确保目录名是dream-creator，并且里面包含SKILL.md文件。

问题2：安装脚本（install.sh）在macOS/Linux上报权限错误。

• 可能原因：脚本没有执行权限，或目标目录不可写。
• 解决：

  # 确保脚本有执行权限 chmod +x install.sh # 如果目标目录需要sudo权限，可以尝试用sudo运行 sudo ./install.sh # 但更好的做法是检查并修改你的AI工具技能目录的所有权，使其对当前用户可写

6.2 使用过程中的问题

问题3：智能体间的对话陷入循环，或者某个智能体“卡住”了，不断重复相同的问题。

• 可能原因：这通常是底层大模型（Claude）在长上下文下产生的“困惑”现象，或者智能体的提示词指令在某些边界条件下形成了逻辑闭环。
• 解决：
  1. 中断并重启：最直接的方法是停止当前对话，新建一个聊天窗口，重新输入/dream-creator。在对话初期，用更清晰、简洁的语言描述需求。
  2. 手动引导：你可以尝试直接@某个智能体，给出明确指令。例如，当PM在需求澄清上反复时，你可以输入：“@产品经理，关于问题2，我的答案是‘不需要截止日期提醒’。请基于我们已确认的需求，直接进入下一阶段。”
  3. 简化需求：如果项目非常复杂，尝试将其拆分成更小的、独立的子项目，分多次使用Dream Creator来完成。

问题4：生成的代码有错误，无法运行。

• 可能原因：AI生成的代码不可能100%正确，可能存在语法错误、逻辑错误或缺少某些依赖。
• 解决流程：
  1. 首先，不要慌。这是正常现象，也是“调试员”智能体存在的意义。
  2. 复制错误信息：将终端或浏览器控制台报错信息完整复制。
  3. 召唤调试员：在聊天框中输入：“@调试员，项目启动时报错，错误信息如下：[粘贴错误信息]，请分析原因并提供修复方案。”
  4. 调试员会分析错误日志，定位问题（例如，某个npm包版本冲突，或一个API接口路径写错了），并给出修改建议。你可以根据建议修改代码，或直接让对应的开发者智能体重新生成有问题的部分。

问题5：如何让团队使用我们内部的技术规范？

• 解决方案：深度自定义智能体文件。这是将Dream Creator融入企业工作流的关键。
  • 修改agents/code-reviewer.md，在其中加入你们公司的代码规范检查清单（如命名规范、注释要求、特定的安全规则）。
  • 修改references/framework-guide.md，将默认的技术栈推荐替换为你们内部批准的“技术白名单”。
  • 在agents/tech-writer.md中，加入你们公司的文档模板和要求。
  • 将这些自定义后的技能文件，打包分发给团队所有成员，安装到他们的本地环境中。这样，整个“虚拟团队”就都遵循你们内部的开发标准了。

6.3 性能与成本优化技巧

技巧1：控制对话轮次，避免上下文爆炸每次智能体交互都会消耗上下文令牌（Token）。对于复杂项目，可以主动控制流程：

• 在PM需求澄清阶段，尽量一次性给出全面、清晰的描述，减少来回问答的轮次。
• 当进入开发迭代阶段后，如果只是添加一个小功能，可以尝试直接对“前端开发者”或“后端开发者”智能体下达精确指令，而不是重新走一遍完整的PM-架构师流程。

技巧2：分阶段使用对于超大型项目，不要指望一次对话完成所有事情。可以这样规划：

• 第一次对话：只用Dream Creator完成需求梳理和顶层架构设计。拿到技术方案和项目骨架后就暂停。
• 第二次对话：在生成的项目目录里，针对核心模块（如用户系统），再次启动Dream Creator进行详细实现。
• 第三次对话：针对另一个模块（如待办事项CRUD）重复此过程。 这样既能利用多智能体协作的优势，又能将每次对话的上下文长度控制在合理范围内。

技巧3：善用“知识库”（FAQ Agent）FAQ代理会记录之前项目中遇到的问题和解决方案。在遇到类似问题时，可以主动询问：“@FAQ代理，我们之前遇到过JWT Token过期的问题，是怎么解决的？” 这能有效利用历史经验，避免重复踩坑。