Xiaomi MiMo Desktop 开放邀测，值得关注的并不只是它能生成完整 PPT 或制作 3D 游戏，而是产品定位发生了变化：AI 不再只返回一段答案，而是接收多格式素材、理解目标、拆解任务、调用工具，并交付可以继续编辑、演示或运行的成果。
这更接近真实工作的形态。用户手里通常不是一条精心编写的提示词，而是一堆文档、截图、表格、参考链接和模糊要求。桌面 AI 的价值，就在于能否把这些杂乱输入变成结构明确、质量可检查的最终文件。
真正的分水岭是成果，而不是回答长度
聊天机器人完成任务的常见方式，是解释应该怎么做；桌面智能体则需要把解释落实为文件、目录、页面、素材和运行结果。
以完整 PPT 为例，仅仅输出十页大纲并不等于完成交付。一个可用的演示文稿通常还要满足：
- 信息来自用户提供的材料，而不是凭空补齐关键数据；
- 页面结构与汇报对象匹配，例如管理层更关心结论、风险和决策项；
- 图表、标题、注释和数据口径保持一致；
- 文件能够继续编辑，而不只是生成若干张图片；
- 素材缺失或结论不确定时，明确标记待确认项。
3D 游戏的验收标准更加工程化。除了视觉效果，还要检查它能否启动、交互是否完整、资源路径是否正确，以及生成结果中是否包含可维护的项目结构。换句话说，令人惊讶的截图只是演示，能够复现和修改的工程才是交付。
多格式输入为什么比超长提示词更重要
真实项目的上下文往往分散在不同载体中：需求写在文档里，数字放在表格里，视觉参考来自截图，限制条件则藏在聊天记录中。让用户把所有信息重新整理成一个提示词，本身就是一项费时工作。
MiMo Desktop 所强调的多格式素材输入和任务拆解，指向了一种更自然的工作流：用户提供原始材料与目标，AI 负责识别材料之间的关系，再决定需要执行哪些步骤。
这类流程可以抽象为：
- 读取并分类输入文件；
- 提取事实、约束和待确认信息；
- 生成任务计划与交付物清单；
- 调用适合的工具制作内容；
- 检查文件完整性与内容一致性；
- 输出最终成果，同时保留问题清单。
其中最难的并不是生成，而是跨步骤保持约束。例如，源表格中的营收单位是万元，图表和结论页就不能擅自改成元；产品主色被指定后，封面、图表和组件也应使用同一套视觉规则。
可以这样准备一个可验收的任务包
邀测阶段最有效的测试方式，不是输入一句“帮我做个高级 PPT”，而是准备一个规模可控、验收条件明确的任务包。
下面的示例会创建一个用于季度产品复盘的目录和任务说明。它不是 MiMo Desktop 的官方配置格式，而是一种可以直接改造的通用实践：创建后，把真实材料放进 inputs，再将目录和 task.yaml 中的要求交给桌面客户端。
mkdir -p mimo-eval/{inputs,output,review}
cat > mimo-eval/task.yaml <<'YAML'
project: quarterly-product-review
objective: 根据输入材料制作一份面向管理层的季度产品复盘演示文稿
inputs:
- path: inputs/metrics.xlsx
purpose: 核心业务指标
- path: inputs/roadmap.md
purpose: 产品进展与延期说明
- path: inputs/style-reference.png
purpose: 视觉风格参考
constraints:
language: zh-CN
audience: management
max_slides: 12
editable_output: true
do_not_invent_missing_metrics: true
required_sections:
- 执行摘要
- 核心指标及环比变化
- 已完成事项
- 延期事项与原因
- 风险和资源需求
- 下一季度计划
acceptance_criteria:
- 每个关键数字都能追溯到输入材料
- 图表单位与源表格一致
- 不确定信息使用待确认标记
- 输出包含可编辑的 PPTX 文件
- 另附一份问题与假设清单
deliverables:
- output/product-review.pptx
- review/questions.md
- review/source-map.md
YAML
cat > mimo-eval/README.md <<'MD'
# 测试步骤
1. 将真实表格、路线图和风格截图放入 inputs。
2. 把 task.yaml 作为任务要求提交给桌面 AI。
3. 要求 AI 在生成前先列出缺失信息。
4. 将生成文件放入 output，将问题清单放入 review。
5. 按 task.yaml 中的 acceptance_criteria 逐项验收。
MD
find mimo-eval -maxdepth 2 -type f -print
运行前需要把 metrics.xlsx、roadmap.md 和 style-reference.png 替换成自己的文件。若客户端不能直接读取 YAML，也可以打开 task.yaml，将内容复制到任务描述中。
同样的方法可以用于测试 3D 游戏生成，只需要把交付要求换成更工程化的标准，例如：
objective: 根据角色草图制作一个可运行的 3D 收集类小游戏
constraints:
target: desktop-browser
offline_assets_only: true
keyboard_controls:
move: WASD
restart: R
acceptance_criteria:
- 提供明确的启动说明
- 首次加载后可以进入游戏
- 玩家能够移动并收集目标物
- 完成目标后显示结束状态
- 刷新或重新启动不会出现资源路径错误
- 源文件与运行产物分目录保存
deliverables:
- game-source/
- game-build/
- RUNBOOK.md
- KNOWN-ISSUES.md
这里的重点不是 YAML 本身，而是把“做一个游戏”转换成可验证的任务。否则，AI 即使生成了漂亮画面，也很难判断任务究竟完成了多少。
邀测阶段应重点观察什么
面对能够调用工具并操作本地素材的桌面 AI，评估维度不能只看生成速度。
一是事实可靠性。 给表格中的部分单元格设置明显的测试数据，再检查 PPT 图表和结论是否准确引用。对于缺失数据，理想行为是询问或标记，而不是自动编造。
二是过程可恢复性。 故意提供一个损坏文件，观察任务是否整体失败，还是能够指出问题并继续处理其他材料。长任务还应关注中断后能否继续，而不是每次从头生成。
三是成果可编辑性。 检查 PPT 元素是否可修改、游戏工程是否保留源文件、目录命名是否清晰。不可编辑的成品会把后续修改成本重新推给用户。
四是权限与隐私。 不要在邀测工具中直接投入客户机密、个人信息、未公开财务数据或生产环境凭据，除非组织已经确认其数据处理和权限边界。工具调用能力越强，越需要限制可访问目录、外部上传和命令执行范围。
采用建议：先从边界清楚的交付物开始
MiMo Desktop 所代表的方向很明确：桌面 AI 正从对话助手走向成果型智能体。不过，在邀测阶段，更适合把它当作需要验收的新协作者，而不是无需复核的自动化流水线。
可以从 10 页以内的内部汇报、一次性数据整理或小型游戏原型开始，并保留人工审核。每个任务都写清输入、约束、交付物和验收标准，再记录完成时间、返工次数和事实错误。只有当结果能够稳定复现，才适合逐步扩大素材规模和工具权限。
判断这类产品是否真正有用，不应只问“它会不会做 PPT 或 3D 游戏”，而应问三个更具体的问题：成果能否直接使用、过程能否被验证、出错后能否低成本修正。这三项，才是 AI 从回答问题走向交付工作的关键。