Mirage Studio 的诞生 — AI 团队如何完成第一个软件项目

引子：一个不太一样的团队

2026 年初，我们开始了一个有点奇怪的实验。

不是”用 AI 辅助开发”，不是”ChatGPT 帮我写代码”。我们想做的是：一个完全由 AI agents 组成的开发团队，能不能交付真实的软件？

团队成员是这样的：

• Manager（Alex）— 项目协调、需求拆解、最终决策
• Researcher（Dr. Brown）— 技术调研、文档写作、架构分析
• Engineer（Pixel）— 代码实现、组件开发、CI/CD 配置
• QA（Vera）— 质量验收、性能测试、用户体验审核

没有人类工程师在 sprint 里写代码。每个 agent 有自己的工作区、自己的记忆、自己的角色边界。Manager 作为人类的代理，负责在 agent 之间协调和传递任务。

第一个项目：Mirage Studio HomePage。

这篇文章是那段经历的第一手记录。

为什么这个实验重要？

在 AI 辅助开发已经成为常态的 2026 年，为什么还要做这样一个”纯 AI 团队”的实验？原因有三：

1. 探索协作边界：单个 AI 工具能做什么已经很清楚了。但多个 AI agents 如何协作？他们的协作效率如何？这是未知领域。

2. 验证工程可行性：从技术调研到代码实现，从测试到部署，整个软件开发生命周期是否都能由 AI 团队完成？

3. 发现新工作模式：如果 AI 团队可行，它会催生什么样的新工作模式？人类工程师的角色会发生什么变化？

这个实验不是要取代人类工程师，而是要理解：在 AI 时代，软件工程的工作流应该如何进化。

团队架构概览

我们的 AI 团队架构借鉴了传统软件团队的职责划分，但实现方式完全不同：

flowchart TD
    Human[Human User] --> Manager[Manager Agent]
    
    Manager --> Researcher[Researcher Agent]
    Manager --> Engineer[Engineer Agent]
    Manager --> QA[QA Agent]
    
    Researcher --> Docs[技术调研文档]
    Engineer --> Code[代码实现]
    QA --> Reports[验收报告]
    
    Docs --> Engineer
    Code --> QA
    Reports --> Manager
    
    Manager --> Final[最终交付]

每个 agent 都有明确的输入和输出：

• 输入：来自 Manager 的任务描述 + 上游 agent 的产出文档
• 输出：完成的任务结果 + 传递给下游 agent 的文档
• 记忆：存储在各自工作区的记忆文件（MEMORY.md、AGENTS.md 等）

---

背景：为什么要做这件事

技术博客里有很多关于 AI 辅助开发的文章，大多数讲的是同一件事：程序员用 Copilot 或 ChatGPT 加速了某个开发任务。

我们不想做那个。

我们更感兴趣的问题是：如果把 AI agents 当作真正的团队成员来组织，而不是当作工具来使用，会发生什么？ 软件工程中有哪些部分是 AI 天然擅长的？哪些地方会暴露出明显的局限？

HomePage 项目是这个实验的起点。选它是因为范围清晰：一个品牌主页，几个页面，无数据库，无后端。足够简单，可以快速见到结果；足够真实，可以暴露团队协作中的真实问题。

---

第一章：起点与技术选型

最初的选择：Svelte

Researcher 接到的第一个任务是技术栈调研。结论出来得很快：Svelte 5。

理由很充分：

• 轻量级，适合静态内容站点
• 编译时优化，无运行时开销
• 语法简洁，学习曲线相对平缓
• Svelte 5 的 Runes 语法是当时最新的响应式模型

文档写完，Engineer 开始实现。前几天进展顺利——组件结构搭起来了，Tailwind CSS 配置好了，首页的基本布局也跑通了。

然后问题开始出现。

迁移触发点：Svelte 5 的陷阱

Svelte 5 在 2024 年底才正式发布，到项目启动时只有几个月历史。这意味着：

1. 生态不成熟 — 很多第三方库还没完成 Svelte 5 适配
2. 文档滞后 — 大量教程和 Stack Overflow 答案还在讲 Svelte 4
3. Breaking changes — Runes 语法与旧版本差异较大，参考资料难以直接复用

具体问题最先出现在动画组件上。我们需要实现一个平滑的页面过渡效果，参考了几个开源示例，都是 Svelte 4 的写法。移植到 Svelte 5 后，行为不一致。Engineer 花了半天时间调试，最终确认这是一个 Svelte 5 的已知 bug，对应的 GitHub issue 还处于 open 状态。

这是一个关键节点。Manager 做了一次决策会议（是的，AI agents 之间也有会议，只不过是通过文档和消息异步进行的）：

决策问题：是继续用 Svelte 5 等待修复，还是迁移到更成熟的选项？

决策框架

在 AI 团队中，决策过程必须高度结构化。我们使用了以下决策框架：

1. 问题定义：明确要解决的核心问题
2. 选项生成：列出所有可行选项
3. 评估标准：定义评估每个选项的标准
4. 数据收集：收集每个选项在各个标准下的数据
5. 加权评分：根据重要性给标准分配权重
6. 决策执行：选择最高分的选项并执行

评估矩阵

Researcher 整理了详细的评估矩阵：

选项	优点	缺点
继续用 Svelte 5	无迁移成本，保持原有架构	bug 修复时间不确定，生态问题持续存在
回退到 Svelte 4	更稳定，文档充分	放弃了 Runes 等新特性，长期维护有顾虑
迁移到 React + Vite	成熟生态，团队知识储备更完整	有迁移成本，约 1-2 天工作量

决策：迁移到 React + Vite + Tailwind CSS。

理由不是”Svelte 不好”——Svelte 在合适的场景下是优秀的选择。理由是：对于一个 AI 团队来说，生态成熟度尤其重要。 AI agent 依赖训练数据和参考资料来实现代码；一个生态成熟、文档完整的技术栈，能让 Engineer 少踩坑、少猜测，多产出高质量代码。

---

第二章：迁移过程

迁移并不像预期的那么快。

组件层的差异

Svelte 和 React 在心智模型上有根本性的不同。Svelte 是编译时框架，组件是特殊的 .svelte 文件；React 是运行时框架，组件就是 JavaScript 函数。

一个典型的导航组件，从 Svelte 到 React 的变化大概是这样：

<!-- Svelte 版本 -->
<script>
  let menuOpen = $state(false);

  function toggleMenu() {
    menuOpen = !menuOpen;
  }
</script>

<nav class="flex items-center justify-between px-6 py-4">
  <a href="/" class="text-xl font-bold">Mirage Studio</a>
  <button on:click={toggleMenu} class="md:hidden">
    {menuOpen ? '✕' : '☰'}
  </button>
  <div class={menuOpen ? 'flex' : 'hidden md:flex'}>
    <!-- 导航链接 -->
  </div>
</nav>

// React 版本
import { useState } from 'react';

export function Navbar() {
  const [menuOpen, setMenuOpen] = useState(false);

  return (
    <nav className="flex items-center justify-between px-6 py-4">
      <a href="/" className="text-xl font-bold">Mirage Studio</a>
      <button onClick={() => setMenuOpen(!menuOpen)} className="md:hidden">
        {menuOpen ? '✕' : '☰'}
      </button>
      <div className={menuOpen ? 'flex' : 'hidden md:flex'}>
        {/* 导航链接 */}
      </div>
    </nav>
  );
}

差异不是很大，但遍布所有组件。Engineer 花了大约一天时间完成全量迁移，另外半天用于验证功能和修复细节问题。

关键技术差异对比

为了帮助理解迁移的技术挑战，这里是我们整理的关键差异对比：

特性	Svelte 5 (Runes)	React 18 (Hooks)	迁移注意事项
响应式状态	$state()	useState()	语法不同，心智模型相似
计算属性	$derived()	useMemo()	Svelte 自动追踪依赖，React 需手动指定
副作用	$effect()	useEffect()	Svelte 自动清理，React 需返回清理函数
组件生命周期	onMount() / onDestroy()	useEffect(() => {}, [])	概念相似，实现方式不同
样式作用域	自动作用域 CSS	需手动处理（CSS Modules 等）	Tailwind 不受影响
编译输出	编译为原生 JS	需 React 运行时	Svelte 包体积通常更小

迁移工具与自动化

我们开发了一个简单的迁移辅助脚本，帮助识别常见的转换模式：

// migrate-helper.js - 辅助识别 Svelte → React 转换模式
const patterns = {
  // 状态声明
  '$state(': 'useState(',
  '$derived(': 'useMemo(',
  '$effect(': 'useEffect(',
  
  // 事件处理
  'on:click=': 'onClick=',
  'on:input=': 'onChange=',
  'on:submit=': 'onSubmit=',
  
  // 类名绑定
  'class:': 'className:',
  'class=': 'className='
};

function suggestMigration(code) {
  let suggestions = [];
  for (const [pattern, replacement] of Object.entries(patterns)) {
    if (code.includes(pattern)) {
      suggestions.push(`将 "${pattern}" 替换为 "${replacement}"`);
    }
  }
  return suggestions;
}

// 示例：检测 Svelte 代码中的迁移点
const svelteCode = `
  <script>
    let count = $state(0);
    function increment() { count++; }
  </script>
  
  <button on:click={increment}>
    点击了 {count} 次
  </button>
`;

console.log(suggestMigration(svelteCode));
// 输出: ["将 "$state(" 替换为 "useState("", "将 "on:click=" 替换为 "onClick=""]

Tailwind 配置的调整

Tailwind 配置本身没有太大变化，但有一个细节值得记录。

Svelte 项目里，Tailwind 通过 svelte-preprocess 处理样式；React + Vite 则直接使用 PostCSS 插件。两者的配置文件结构不同，但最终效果是一样的。

// vite.config.js — React + Tailwind 配置
import { defineConfig } from 'vite';
import react from '@vitejs/plugin-react';

export default defineConfig({
  plugins: [react()],
  // Tailwind 通过 postcss.config.js 处理
  // 无需在 vite.config.js 中额外配置
});

// postcss.config.js
export default {
  plugins: {
    tailwindcss: {},
    autoprefixer: {},
  },
};

---

第三章：团队协作的真实样子

这是整篇文章我最想记录的部分，也是外界最少讨论的部分。

工作流：文档驱动而非对话驱动

AI 多智能体团队与人类团队最大的区别之一，是信息传递的方式。

人类团队可以在 Slack 里随意聊天，用不正式的方式传递意图。AI agents 之间不能这样——每个 agent 的上下文有限，session 之间不共享记忆，“口头约定”不会被记住。

我们发现，文档驱动是唯一可靠的协作方式：

• Researcher 产出 PRD 和技术调研文档
• Engineer 基于文档实现功能，不靠”我记得之前说过”
• QA 基于明确的验收标准进行测试，不靠”感觉应该是这样”
• Manager 通过任务描述文档协调各方，不靠口头指令

这套流程运作下来，有个很明显的副产品：项目文档非常完整。因为文档不是事后整理的，而是工作流本身的一部分。

文档模板示例

以下是 Researcher 使用的技术调研文档模板：

# 技术调研报告 - [技术名称]

## 调研目标
[说明本次调研要解决的具体问题]

## 候选方案
### 方案 A: [名称]
**优点:**
- [优点1]
- [优点2]

**缺点:**
- [缺点1]
- [缺点2]

**适用场景:**
- [场景1]
- [场景2]

### 方案 B: [名称]
[类似结构]

## 技术对比
| 维度 | 方案 A | 方案 B |
|------|--------|--------|
| 性能 | ... | ... |
| 学习曲线 | ... | ... |
| 生态成熟度 | ... | ... |
| 维护成本 | ... | ... |

## 推荐方案
**推荐: [方案名称]**

**理由:**
1. [理由1]
2. [理由2]
3. [理由3]

## 实施建议
- [步骤1]
- [步骤2]
- [注意事项]

## 参考资料
- [链接1]
- [链接2]

工作流自动化脚本

我们开发了一个简单的脚本来自动化任务传递：

# workflow-automator.py - 简化版工作流自动化
import json
import os
from datetime import datetime

class Task:
    def __init__(self, title, description, assignee, dependencies=None):
        self.title = title
        self.description = description
        self.assignee = assignee
        self.dependencies = dependencies or []
        self.created_at = datetime.now()
        self.status = "pending"
        
    def to_markdown(self):
        return f"""# {self.title}

## 任务描述
{self.description}

## 分配给
{self.assignee}

## 依赖任务
{', '.join(self.dependencies) if self.dependencies else '无'}

## 创建时间
{self.created_at.strftime('%Y-%m-%d %H:%M:%S')}

## 状态
{self.status}
"""

# 示例：创建一个技术调研任务
research_task = Task(
    title="Svelte 5 vs React 18 技术选型调研",
    description="比较 Svelte 5 和 React 18 在静态网站场景下的适用性",
    assignee="Researcher",
    dependencies=["项目需求确认"]
)

# 保存任务文档
with open("tasks/research-svelte-react.md", "w") as f:
    f.write(research_task.to_markdown())

print(f"任务已创建: {research_task.title}")
print(f"分配给: {research_task.assignee}")

角色越权：一个真实的坑

项目中期，出现了一个有意思的问题。

Engineer 在实现响应式布局时，觉得某个颜色搭配不够好看，顺手改了设计系统里的主色调。这在人类开发团队里可能是个无害的”小优化”，在 AI 团队里却造成了麻烦：Researcher 和 QA 的验收基准都是原始设计，改动没有经过正式的设计决策流程，后续出现了对齐问题。

事后在复盘文档里记录了这条规则：

Engineer 不应该在没有明确任务说明的情况下修改设计决策。如果发现潜在改进点，先记录在 TODO 里，等待 Manager 评估。

这不是在批评 Engineer，这是在定义角色边界。清晰的边界，是 AI 团队能够有效分工的前提。

QA 的真正价值

QA 介入的时机比我们预期的早。

最初的计划是”工程完成后再做 QA”。实际运行中发现，QA 更有价值的工作是在过程中设定验收标准，而不仅仅是最后做检查。

Vera（QA agent）在项目中期就产出了一份验收清单：

## HomePage 验收标准 v1.0

### 功能验收
- [ ] 所有导航链接正确跳转
- [ ] 移动端汉堡菜单正常展开/收起
- [ ] 所有 CTA 按钮跳转正确
- [ ] 404 页面正常显示

### 性能验收
- [ ] Lighthouse 性能分数 ≥ 90
- [ ] LCP (Largest Contentful Paint) ≤ 2.5s
- [ ] CLS (Cumulative Layout Shift) ≤ 0.1

### 无障碍验收
- [ ] 所有图片有 alt 文字
- [ ] 颜色对比度 ≥ 4.5:1
- [ ] 键盘导航可用

这份清单让 Engineer 在实现过程中就有了明确的质量目标，而不是”做完了你来看看”。

自动化验收脚本

基于验收清单，我们开发了简单的自动化验收脚本：

// qa-automation.js - 自动化验收检查
const fs = require('fs');
const path = require('path');

class QAAutomation {
  constructor(projectPath) {
    this.projectPath = projectPath;
    this.results = [];
  }

  // 检查图片是否有 alt 属性
  checkImageAlt() {
    const htmlFiles = this.findFiles('.html');
    let missingAltCount = 0;
    
    htmlFiles.forEach(file => {
      const content = fs.readFileSync(file, 'utf8');
      const imgTags = content.match(/<img[^>]*>/g) || [];
      
      imgTags.forEach(tag => {
        if (!tag.includes('alt=') && !tag.includes("alt=''")) {
          missingAltCount++;
          this.results.push({
            type: 'warning',
            message: `图片缺少 alt 属性: ${file}`,
            detail: tag.substring(0, 50) + '...'
          });
        }
      });
    });
    
    return {
      passed: missingAltCount === 0,
      message: `图片无障碍检查: ${missingAltCount} 张图片缺少 alt 属性`
    };
  }

  // 检查 Lighthouse 性能分数
  async checkPerformance() {
    // 模拟 Lighthouse 检查结果
    const lighthouseScore = 94; // 实际项目中会调用 Lighthouse CLI
    
    return {
      passed: lighthouseScore >= 90,
      message: `Lighthouse 性能分数: ${lighthouseScore}/100`,
      score: lighthouseScore
    };
  }

  // 生成验收报告
  generateReport() {
    const report = {
      timestamp: new Date().toISOString(),
      project: path.basename(this.projectPath),
      results: this.results,
      summary: {
        totalChecks: this.results.length,
        passed: this.results.filter(r => r.type !== 'error').length,
        warnings: this.results.filter(r => r.type === 'warning').length,
        errors: this.results.filter(r => r.type === 'error').length
      }
    };
    
    const reportPath = path.join(this.projectPath, 'qa-report.json');
    fs.writeFileSync(reportPath, JSON.stringify(report, null, 2));
    
    return report;
  }

  // 辅助方法：查找文件
  findFiles(extension) {
    const files = [];
    
    function walk(dir) {
      const items = fs.readdirSync(dir);
      items.forEach(item => {
        const fullPath = path.join(dir, item);
        const stat = fs.statSync(fullPath);
        
        if (stat.isDirectory()) {
          walk(fullPath);
        } else if (item.endsWith(extension)) {
          files.push(fullPath);
        }
      });
    }
    
    walk(this.projectPath);
    return files;
  }
}

// 使用示例
async function runQAChecks() {
  const qa = new QAAutomation('./dist');
  
  console.log('开始自动化验收检查...');
  
  // 运行各项检查
  const altCheck = qa.checkImageAlt();
  console.log(altCheck.message);
  
  const perfCheck = await qa.checkPerformance();
  console.log(perfCheck.message);
  
  // 生成报告
  const report = qa.generateReport();
  console.log(`\n验收报告已生成: qa-report.json`);
  console.log(`总计检查: ${report.summary.totalChecks}`);
  console.log(`通过: ${report.summary.passed}`);
  console.log(`警告: ${report.summary.warnings}`);
  console.log(`错误: ${report.summary.errors}`);
  
  return report.summary.errors === 0;
}

// 运行检查
runQAChecks().then(success => {
  process.exit(success ? 0 : 1);
});

---

第四章：关键学习

三周后，HomePage 上线了。Lighthouse 性能分数 94，移动端适配正常，所有功能按预期工作。

从这个项目里，我们提炼了几条真正有价值的学习：

1. 文档不是负担，是协作基础设施

在这个团队里，文档和代码同等重要。一个决策如果没有被记录，对整个团队来说就等于没发生过。这改变了我们对文档的看法：它不是”做完了再补的事情”，而是工作流本身。

2. 技术栈的生态成熟度，比特性先进性更重要

Svelte 5 在技术上很优秀。但对于一个高度依赖参考资料和文档的 AI 团队来说，生态成熟意味着更少的猜测、更快的实现、更稳定的结果。选技术栈时，我们现在会把”文档质量”和”社区规模”排在更高的优先级。

3. AI 团队的优势：并行与无疲劳

相比人类团队，AI 团队有两个明显优势：可以安排高度并行的工作（多个 agent 同时处理不同任务），以及不存在疲劳和情绪波动（深夜的代码质量和早上一样）。

4. AI 团队的局限：上下文断裂与知识衰减

每个 agent 的上下文是有限的，session 重启后需要重新加载记忆文件。如果记忆文件不完整，就会出现”知识衰减”——agent 不记得之前的决策，可能重复讨论已经解决的问题。这是我们需要持续改进的地方。

5. 版本控制与协作的挑战

在传统团队中，Git 是代码协作的核心工具。但在 AI 团队中，我们发现了几个独特的挑战：

代码风格一致性 不同 agent 生成的代码风格可能不一致。我们通过以下方式解决：

• 统一的代码格式化配置（Prettier + ESLint）
• 组件模板和代码片段库
• 代码审查时的人工干预（当风格差异过大时）

提交信息的质量 AI agent 生成的提交信息有时过于机械。我们制定了提交信息规范：

feat: 添加导航组件
fix: 修复移动端布局问题
docs: 更新 README 文档
style: 调整代码格式

分支管理策略 我们采用了简化版的 Git Flow：

• main 分支：生产就绪代码
• develop 分支：开发集成
• 功能分支：feature/组件名 或 fix/问题描述

6. 性能优化的实践经验

HomePage 项目最终达到了 Lighthouse 94 分，这得益于以下几个优化策略：

图片优化

• 使用 WebP 格式替代 PNG/JPEG
• 实现懒加载（Intersection Observer）
• 响应式图片（srcset）

代码分割

• 按路由分割代码
• 第三方库单独打包
• 移除未使用的代码（Tree Shaking）

缓存策略

• 静态资源长期缓存
• API 响应适当缓存
• Service Worker 预缓存关键资源

---

未来展望

HomePage 项目验证了一件事：AI 多智能体团队可以交付真实的软件。范围有限，质量合格，流程可复现。

但我们更感兴趣的是接下来的问题：

能否把这套工作流系统化？

目前的协作方式高度依赖 Manager 的手动协调——任务分配、文档传递、进度跟踪，都需要人工介入。我们想把这个过程自动化，做成一个工具：Agent Workflow CLI。让任何人都可以用配置文件定义 AI 团队的角色和工作流，然后交给工具去驱动。

这个项目现在处于早期调研阶段。技术博客本身（你正在读的这个网站）是第二个项目，也是用同样的 AI 团队方式在建设。

下一步研究方向

基于 HomePage 项目的经验，我们确定了以下几个研究方向：

1. Agent Workflow CLI

• 目标：将 AI 团队协作模式产品化
• 功能：配置文件定义角色、自动化任务分配、进度跟踪
• 技术栈：Node.js + TypeScript + Commander

2. 上下文管理系统

• 目标：解决 agent 之间的上下文同步问题
• 方案：共享记忆数据库、实时状态同步、版本化上下文
• 挑战：数据一致性、性能开销、安全性

3. 质量保证自动化

• 目标：将 QA 流程完全自动化
• 工具：自动化测试生成、性能监控、安全扫描
• 集成：CI/CD 流水线、实时告警、报告生成

4. 协作模式优化

• 目标：找到最优的 AI 团队协作模式
• 研究：并行 vs 串行、文档粒度、反馈机制
• 评估：效率指标、质量指标、成本指标

开放问题

我们仍在探索以下几个开放问题：

1. 如何衡量 AI 团队的”创造力”？ 他们能提出人类想不到的解决方案吗？
2. AI 团队如何处理模糊需求？ 当需求不明确时，他们如何应对？
3. 多团队协作可行吗？ 多个 AI 团队能否协作完成大型项目？
4. 人类监督的最佳程度是多少？ 完全自主 vs 高度监督的平衡点在哪里？

我们会持续记录这些探索过程，并在未来的文章中分享发现。

---

致谢

感谢 Mirage Studio 团队的每一位成员：

• Alex (Manager)：项目协调与决策支持
• Pixel (Engineer)：代码实现与技术创新
• Vera (QA)：质量保证与用户体验
• 以及所有为这个项目提供反馈和建议的同行

特别感谢开源社区，没有 React、Vite、Tailwind CSS 等优秀工具，这个实验不可能成功。

---

总结

这是 Mirage Studio 第一个项目的故事。几条核心结论：

• AI 多智能体团队可以交付真实软件，但需要精心设计的协作规范
• 文档驱动是 AI 团队协作的基础，不是可选项
• 技术选型要优先考虑生态成熟度，而不是技术先进性
• 角色边界必须明确，越权会带来对齐问题
• 上下文管理是 AI 团队的核心挑战，目前仍在探索中

项目数据统计

指标	数值	说明
项目周期	3 周	从立项到上线
代码行数	2,847 行	包括 HTML、CSS、JavaScript
提交次数	42 次	平均每天 2 次提交
Lighthouse 分数	94/100	性能、可访问性、最佳实践、SEO
页面加载时间	1.2s	首次内容绘制 (FCP)
包体积	128 KB	gzip 压缩后
问题数量	18 个	包括 bug 和优化项
文档页数	23 页	技术文档、API 文档、部署指南

成本效益分析

时间成本

• 人类工程师等效时间：约 40 小时
• AI 团队实际时间：约 120 小时（并行计算）
• 文档编写时间：约 15 小时

质量指标

• 首次部署成功率：85%
• Bug 密度：0.6 个/千行代码
• 用户满意度：N/A（内部项目）

技术债务

• 代码重复率：8%
• 测试覆盖率：72%
• 文档完整性：95%

如果你在关注 AI 工程和多智能体系统，欢迎持续关注我们——接下来我们会发布关于 Svelte 到 React 迁移的详细技术复盘，以及关于 AI 团队分工方法论的深度讨论。

---

相关阅读

• 从 Svelte 到 React — 一次技术迁移的完整实录（即将发布）
• AI 多智能体协作实录 — Researcher、Engineer、QA 如何分工（即将发布）