代码驱动的多媒体生成
为什么多媒体创作适合转成代码生成问题？
- 本质: 复杂文档的创作是结构化数据的组织与呈现——HTML 描述结构、CSS 控制样式、JavaScript 实现交互;
- GUI 困境: 所见即所得编辑对 Agent 既不直观也不高效，需要视觉理解与精确坐标定位;
- 代码方案: 每个元素的位置、样式、内容都被明确定义，可用程序化方式修改与优化;
- 适用范围: 演示文稿、技术报告、视频、3D 零件等;
提议者-审核者机制为什么在内容生成中必要？
- 前提: 仅能生成代码还不够——Agent 写完代码并不知道实际渲染效果，内容是否太挤、文字是否溢出、图片尺寸是否合适，只有渲染出来才能发现;
- 机制: 把代码编写与质量评审解耦为两个独立 Agent;
| 角色 | 输入 | 输出 |
|---|---|---|
| Proposer | 内容逻辑结构 | 框架代码（如 Slidev / Blender Python） |
| Reviewer | 渲染出的图片 | 结构化改进建议（页码、问题类型、严重程度） |
- 反馈质量: Reviewer 用 Vision LLM 从内容密度、可读性、布局合理性、视觉美感等维度分析，产出的是可执行指导（“第 3 页内容过多，建议拆分”“第 7 页代码块字体过小，建议增大到 14pt”），而不是模糊的“不好看”;
- 循环: Proposer 理解反馈并修改代码，新版本再次提交审查，迭代到质量达标或达到最大迭代次数（如 5 轮）;
- 终止条件: “质量达标”与“最大轮数”正是 Loop 工程要求的两类显式终止条件——前者由审核者判定目标达成，后者用预算上限防止循环失控;
- 模式归属: 与 提议者—审核者 同源；第四章将其用于不可逆操作的事前审批（审核者对单次操作给出批准或否决），此处用于内容质量的迭代改进——多轮循环，且审核者接触到提议者看不到的新信息（渲染结果）;
提议者-审核者为什么优于单 Agent 循环？
- 核心优势: 上下文管理;
- Reviewer 侧: 每次只处理最新版本的渲染图片，不受历史版本干扰;
- Proposer 侧: 仅累积结构化文本反馈，token 消耗少且更易于推理;
- 单 Agent 的代价: 需在同一上下文中累积数十页渲染图片的多轮迭代，上下文迅速超限;
- 复用性: 该机制在视频编辑、日志可视化等场景重复使用;
视频编辑为什么走 API 而不是 GUI？
- GUI 挑战: 视频剪辑软件界面极其复杂，包含大量时间轴、图层、效果面板，精确输出坐标非常困难;
- 代码路线: Blender 支持 Python 脚本控制，FFmpeg 提供命令行能力，核心功能以结构化、可组合的方式暴露;
- 优势: 把自然语言需求转化为 API 调用，远比理解 GUI 并模拟鼠标点击容易;
- 两步定位策略: 先用每 10 秒截图做粗粒度定位（“冲浪在第 40–110 秒”），再以每秒一张的密度精确到边界时间点;
- 子 Agent 封装: 把视频分析封装为子 Agent，避免大量截图占用主 Agent 上下文;
- 质量闭环: Proposer 生成 Blender 脚本，Reviewer 执行快速预览、检查关键帧并反馈，迭代达标后完整渲染;
- 精度要求: 起始与结束点误差不超过 3 秒；特效要求（慢动作、转场、字幕）须正确应用;
什么时候用代码生成、什么时候用 3D 生成模型？
| 判据 | 倾向代码生成 | 倾向 3D 生成模型 |
|---|---|---|
| 有无紧凑精确描述 | 工业零件：五六个参数即完整定义，代码是无损表达 | 绿植、太湖石、人脸：细节数不清，内在复杂度近乎无限 |
| 精度与可验证性 | 每个尺寸是硬约束，可载入网格程序化量测比对 | 无法直接与规格核对 |
| 表示形式与可编辑性 | B-rep 参数化实体（STEP 含特征树与尺寸参数），可直接驱动 CNC | 三角面片网格，曲面靠碎面逼近 |
| 变更成本 | 改一个数字重跑，其余尺寸分毫不差 | 只能整体重新生成，其他尺寸是否跑偏全凭运气 |
- 定位: 走哪条路本身就是 Agent 要做的一次决策——掂量产物的内在复杂度与精度要求;
- 混合: 实际系统可两条路混着走——几何体用代码参数化生成，表面纹理交给生成模型;
- 实验观察: 同一法兰盘零件在代码路线下尺寸精确、可参数化修改，生成模型路线在尺寸精度与变更可控性上明显吃亏；换成绿植等产物后两者优劣正好反转;
- 定位: 这是元能力作用在“内容呈现”这一层，见 代码作为元能力;