Minecraft 红石视频全自动演绎工厂 - Idea 文档 v1.1
项目代号：Redstone Director (红石导演) 文档版本：v1.1 更新日期：2026-08-15 核心原则：先建筑，后演绎；实机录制，拒绝 AI 生成画面；全链路可复现。
本文件为项目最高指导原则，后续所有设计文档、代码实现、流程调整均需遵循本文档定义的方向与约束。
1. 项目愿景
将《我的世界》视频创作从"手工劳作"升级为"AI 导演+演员的实机彩排"。
构建一个 "虚拟剧组" 。AI 负责读懂需求、画出图纸、控制角色（演员）在真实的游戏世界里亲手搭建红石机关并演绎剧本。最终产出 100% 实机录制、带有中英双语的影视级或教学级视频。
核心理念：观众看到的是"角色在 Minecraft 里真实建造/表演"，而非 AI 生成的虚假画面。
2. 核心创新点
| 对比维度 | 传统 AI 视频 | 本项目（Redstone Director） |
|---|---|---|
| 画面来源 | AI 生成（画面崩坏/幻觉） | Minecraft 实机录制（物理引擎真实） |
| 内容逻辑 | 一次性生成，错了重来 | 图纸验证先行，建筑对了再演戏 |
| 创作形式 | 文本生成视频 | 角色演绎（走位/放置/对话）+ 红石科技 |
| 迭代方式 | 人工手动修改 Prompt | 标准化目录 + 版本控制，一键重跑复现 |
3. 核心方法论：两阶段演绎法
建筑是"地基"，演绎是"上层建筑"。
-
建筑图纸阶段：解决"搭什么"和"对不对"。
- 输入需求 → AI 生成图纸（含方块坐标、朝向、红石逻辑）→ 游戏内自动建造 → 验证红石功能（灯亮/门开）→ 入库存档
-
演绎脚本阶段：解决"怎么演"。
- 基于已入库的图纸 → AI 生成分步演绎脚本（角色走位、放置动作、对话台词、镜头运动）→ 模拟玩家亲手搭建过程 → 录制素材 → 配音剪辑
关键约束：必须进入演绎阶段的前提是建筑图纸验证通过。禁止在建筑未经验证时生成演绎脚本。
4. Agent 编排与协同架构
4.1 Agent 清单
项目共包含 10 个 Agent，按职责划分如下：
| Agent | 简称 | 核心职责 |
|---|---|---|
| 策划 Agent | Planner | 理解用户需求，生成分镜脚本和大纲 |
| 建筑 Agent | Builder | 生成建筑图纸（JSON 格式） |
| 指令 Agent | Commander | 将图纸转换为 Minecraft 可执行命令 |
| 演绎 Agent | Director | 将图纸转换为分步演绎脚本（动作+台词+镜头） |
| 执行 Agent | Executor | 控制游戏客户端执行命令或动作序列 |
| 录制 Agent | Recorder | 控制 OBS 自动开始/停止录制 |
| 剪辑 Agent | Editor | 自动拼接素材、添加片头片尾、叠加字幕 |
| 配音 Agent | Voiceover | 生成中英双语配音并对其时间轴 |
| 审核 Agent | Reviewer | 自动质检（技术/内容/合规） |
| 发布 Agent | Publisher | 多平台自动分发与数据追踪 |
4.2 Harness 协同架构
所有 Agent 由 Harness（调度中心） 统一管理。Harness 是项目的"大脑"，负责：
- 按阶段调度 Agent（Phase 0 只用建筑+指令+执行；Phase 1 增加演绎+录制+剪辑+配音）
- 管理各 Agent 之间的数据传递（上一个 Agent 的输出格式 = 下一个 Agent 的输入格式）
- 记录每次运行的完整链路（含输入、输出、耗时、错误），确保可复现
- 当任何 Agent 执行失败时，根据预设策略决定重试/跳过/回滚/通知人工
┌─────────────────────────────────────────────┐
│ Harness (调度中心) │
│ - 阶段管理 (Phase 0/1/2/3) │
│ - 数据传递 (上一个输出 = 下一个输入) │
│ - 链路记录 (完整追踪，确保可复现) │
│ - 容错策略 (重试/回滚/人工介入) │
└─────────────────────┬───────────────────────┘
│
┌─────────────────────┼───────────────────────┐
│ │ │
▼ ▼ ▼
┌───────────────────┐ ┌───────────────────┐ ┌───────────────────┐
│ 策划 Agent │ │ 建筑 Agent │ │ 演绎 Agent │
│ (需求→大纲) │ │ (大纲→图纸) │ │ (图纸→演绎脚本) │
└───────────────────┘ └───────────────────┘ └───────────────────┘
│ │ │
└─────────────────────┼───────────────────────┘
▼
┌─────────────────────────────────────────────┐
│ 执行 Agent │
│ (控制游戏客户端：建造/走位/交互/录制启停) │
└─────────────────────┬───────────────────────┘
│
┌─────────────────────┼───────────────────────┐
│ │ │
▼ ▼ ▼
┌───────────────────┐ ┌───────────────────┐ ┌───────────────────┐
│ 录制 Agent │ │ 剪辑 Agent │ │ 配音 Agent │
│ (OBS控制) │ │ (素材拼接) │ │ (TTS+时间轴) │
└───────────────────┘ └───────────────────┘ └───────────────────┘
│
▼
┌─────────────────────────────────────────────┐
│ 审核 Agent │
│ (自动质检：逻辑/音画/合规) │
└─────────────────────┬───────────────────────┘
│
▼
┌─────────────────────────────────────────────┐
│ 发布 Agent │
│ (多平台分发 + 数据追踪) │
└─────────────────────────────────────────────┘
4.3 Agent 协同约束
| 约束类型 | 说明 |
|---|---|
| 数据契约 | 上游 Agent 的输出必须包含下游 Agent 所需的全部字段。格式在 Plan 阶段定义 |
| 阶段依赖 | 建筑阶段（Phase 0）完成后才能进入演绎阶段（Phase 1）。禁止跨阶段跳跃 |
| 执行顺序 | Harness 保证串行执行，当前 Agent 完成后才触发下一个。不采用并行调度 |
| 错误传播 | 任一 Agent 失败，Harness 记录错误并阻断下游执行，等待人工确认或自动重试 |
| 版本锁定 | 每个项目的每次运行必须记录所有 Agent 的版本号，确保可复现 |
5. 阶段规划
采用渐进式验证，每阶段确认后再进入下一阶段：
| 阶段 | 名称 | 核心目标 | 涉及 Agent | 周期 |
|---|---|---|---|---|
| Phase 0 | 基石期 | 验证自动建造：AI 能在游戏里搭出可用的红石结构 | Builder、Commander、Executor | 约 2 周 |
| Phase 1 | 成片期 | 验证自动演绎：AI 能像真人一样"演"搭建过程并自动出片 | Director、Executor、Recorder、Editor、Voiceover | 约 3-4 周 |
| Phase 2 | 进化期 | 验证自学习与质检：AI 能自动审片并学习人工修改 | Reviewer、反馈学习模块、Publisher | 约 3 周 |
| Phase 3 | 拓展期 | 多角色剧情演绎：支持多人同框、红石机关联动 | 全部 Agent 升级 | 长期迭代 |
阶段推进前提：前一阶段的验证标准全部达成后，方可进入下一阶段。
6. 工程化方向
6.1 可复现目录结构（概念）
建立标准化的项目目录，用于存放图纸、脚本、视频、日志、反馈等全部产物。每个项目独立归档，支持多版本共存。
核心目录包括：
- 需求输入（
01_Requirements/） - 建筑图纸（
02_Building_Blueprints/） - 演绎脚本（
03_Acting_Scripts/） - 游戏执行记录（
04_Game_Execution/） - 原始录制素材（
05_Raw_Videos/） - 最终成品视频（
06_Edited_Videos/） - 发布记录（
07_Published/） - 人工审核反馈（
08_Feedback/） - Agent 代码（
Agents/） - 辅助脚本（
Scripts/）
核心机制：
- 每个项目保留
current软链接指向当前有效版本 - 任何时刻都能根据目录内容复现历史版本的视频
6.2 版本控制思想
- 图纸、脚本、视频均支持多版本迭代（v1.0 → v1.1 → ...）
- 每次修改需求后，一键重新生成新版本，不影响旧版本
- 若新版本验证失败，自动回退到上一个有效版本
7. 数据闭环方向
7.1 数据追踪
视频发布后，系统自动抓取各平台数据：
- 播放量、完播率、互动率（点赞/评论/分享）
- 评论热词分析（了解观众反馈）
7.2 反馈学习
- 人工审核时，你的每次修改（改台词、删片段、换 BGM）都会被系统记录
- 系统学习你的修改偏好，下次生成类似主题时优先采用"你改过的那版"方案
- 数据追踪的结果也会反馈给策划 Agent，辅助选题优化
核心闭环：需求微调 → 一键重跑 → 新视频上线 → 数据追踪 → 反馈学习 → 下一次生成更优。
8. 技术选型方向（建议）
| 能力模块 | 技术方向 | 说明 |
|---|---|---|
| 文本智能 | GPT-4 / Claude | 需求理解、脚本生成、台词创作 |
| 语音合成 | Edge TTS / ElevenLabs | 中英双语配音（免费/高质量） |
| 游戏控制 | Python + PyAutoGUI / .mcfunction 数据包 | 模拟键鼠控制游戏，或直接执行命令 |
| 图像识别 | OpenCV | 检测红石灯亮灭、方块位置是否正确 |
| 视频处理 | MoviePy + FFmpeg | 自动剪辑、拼接、字幕叠加 |
| 录制控制 | OBS-WebSocket | 程序化控制录制的启停 |
| 数据存储 | SQLite / 文件系统 | 反馈日志、版本记录、元数据管理 |
9. 全局约束与原则
9.1 核心原则
| 原则 | 说明 |
|---|---|
| 图纸先行 | 任何演绎脚本必须基于已验证通过的建筑图纸 |
| 实机录制 | 所有画面来自真实游戏录制，严禁使用 AI 生成图像 |
| 版本归档 | 每次运行的输入、输出、日志全部归档，不可覆盖 |
| 可复现 | 给定同样的需求和版本号，系统必须产出同样的结果 |
| 渐进推进 | 按 Phase 0→1→2→3 顺序推进，不得跳跃 |
9.2 Agent 通用约束
- 每个 Agent 必须有明确的输入和输出定义（在 Plan 阶段细化）
- 每个 Agent 执行后必须生成结构化日志（含时间戳、输入摘要、输出位置、错误信息）
- 每个 Agent 的代码独立版本管理，互不影响
- Agent 之间不直接通信，全部通过 Harness 传递数据
9.3 人工介入节点
| 节点 | 触发条件 | 人工操作 |
|---|---|---|
| 需求输入 | 每次启动新项目 | 撰写 brief.md（一句话或一段描述） |
| 终审发布 | Phase 1/2/3 完成后 | 确认视频质量，决定发布/修改/重做 |
| 异常中断 | 任何 Agent 失败且自动重试无效 | 检查日志，决定重新运行或手动修复 |
10. 后续计划
| 阶段 | 输出产物 | 状态 |
|---|---|---|
| 当前 | Idea 文档 v1.1 | ✅ 完成 |
| 下步 | Design 文档 | 待启动（细化各 Agent 的职责边界、输入输出协议、具体约束） |
| 下步 | Plan 文档 | 待启动（定义横切分层与竖切切片，规划各阶段任务粒度与验证门禁） |
| 后续 | 逐 Phase 实现 | 待计划 |