大家好，我是 AI 超元域。
把任务交给一个有自己电脑的 AI，会得到怎样的结果？这期我用 OpenAI dots 做了几类具体工作：通过语音找 Notion 旧笔记、检索论文并写回笔记；在云端同时推进 Godot 贪吃蛇和 Blender 巨石阵模型；再安装并调用 Grok CLI，做一个简单的登录页 Demo。
我更关心的是任务有没有落到实际软件里，最后能不能拿到文件、自己打开验证。下面按这条线整理体验，区分助手报告的进度、实际交付物，以及我亲自检查过的部分。
本文整理自 2026 年 9 月 30 日发布的视频、公开章节和与案例匹配的校正讲稿。本次没有重新取得 YouTube 字幕导出，也没有重新运行片中的工程。它记录的是当时的产品体验，不是当前每个账号都能复现的功能保证。
如果播放器无法加载，可以前往 YouTube 观看完整视频。
dots 的定位：持续推进目标的个人智能体
OpenAI 的产品介绍将 dots 描述为由 GPT-6 Astra 驱动、可以在对话之间持续推进工作的智能体。它有自己的云端电脑，也能使用用户选择连接的工具。本文于 2026 年 10 月 24 日核对该页面，模型名和产品定位均有官方依据。
这里容易混淆的是“它有一台云端电脑”和“它已经获得我的电脑权限”。二者并不等价。云端开发、连接 Notion 和访问本地文件，是不同的工作路径，所需权限也不同。
本期主要围绕已经连接的应用和它自己的云端环境展开。视频介绍中涉及的机器配置、应用数量和入口位置，不在本文中作为长期固定规格。账号资格、地区和工作区设置，请以当前官方入门文档为准，不要把历史体验直接当成购买订阅后的功能承诺。
从创建助手到 Slack：先让它知道自己要做什么
01:24 的创建环节中，我给助手起名后，让它根据青铜机器人的概念设计形象，再转换为带动态效果的头像。
这个步骤本身并不能证明生产力，但让长期使用的助手有一个容易辨认的入口，确实更方便。随后我问它对我的技术栈有什么了解，再把它接入 Slack，查看能怎样协助内容整理、开发和资料查找。
02:07 的演示体现的是：在当前可用上下文和已连接应用的范围内，它可以带着背景继续工作。不能因此推断它默认能读取所有历史对话、所有工作区，或不经授权访问任意文件。
第一次连接时，我建议先给一个范围小、结果可核对的任务，比如找出指定主题的几条笔记。确认读到的是正确账号和资料后，再增加写入或更复杂的工作。
语音工作流：找旧笔记，再补新资料，最后写回 Notion
02:55 开始的语音测试不是只问一个知识问题。我先让它从 Notion 查找大模型微调相关笔记，接着根据查找结果继续调整任务。
这段流程可以拆成三个环节。
1. 先找已有资料，避免从零开始
我通过通话要求它查找微调笔记。助手返回了方法梳理和实操记录，并提醒其中一些资料来自 2024–2025 年，真正照着运行前要确认依赖版本。
这类提醒的价值在于，找到笔记和判断笔记是否适合今天使用，是两件事。旧文章可能仍有概念价值，但命令、依赖和模型接口不一定还能原样使用。
2. 在对话中收窄“最新”的含义
发现资料偏旧后，我继续让它搜索 QLoRA 相关论文，并进一步明确要求查找当年的论文。
这样做比只说“找最新论文”更清楚：需要区分首次发表时间、修订日期，以及旧方法在新任务上的应用。片中的助手也谈到了实验环境和结论适用范围。
本文重点记录语音任务如何衔接，没有独立复现所提论文的实验，也不将助手口头归纳的性能结论作为本文的技术评测结果。
3. 把研究结果变成可访问的笔记
之后我选定其中一个方向，要求整理成笔记、保存到 Notion 并提供页面链接。助手报告完成后，我在通话中确认看到了笔记，并给出了正面反馈。
这一步使整个流程有了可检查的终点：从口头指令出发，找到已有资料，补充研究，再生成落在工作应用里的文档。语音的价值在于可以连续补充条件，而不是把每条指令重新打成文字。
当然，写入外部应用需要正确连接和相应授权。遇到重要资料，仍应该打开页面检查内容、引用和保存位置，而不只听到“完成”就结束。
桌面同步与文件输出：任务结果要能取出来
06:46 的桌面演示中，我查看了网页与桌面端的对话同步，以及输出区域中的图片和 Blender 文件。
这里我关注的是文件交付：结果有没有明确入口，能不能下载，在自己的环境里能否继续使用。对图片来说，预览通常足以做初步检查；对工程文件来说，最好还要打开源文件，而不是只看截图。
本期后面的贪吃蛇就继续做了本地试玩。截图、源代码和可运行项目对应不同程度的验证，不能混成一句“整个项目都已测试完成”。
定时任务：这期验证的是设置流程
07:20 的定时任务展示了检查项目仓库 Issues，以及定时检查 OpenAI 是否发布新文章的设置方式。
创建后，任务出现在界面中，这是本期能够支持的观察。视频没有记录连续多天执行情况，也没有统计漏报、误报或失败恢复，因此不能把它写成已经验证了长期无人值守稳定性。
如果要把类似任务真正用于日常工作，创建时应说明检查对象、运行时间、发现什么才通知，以及没有新内容时怎么处理。设置完成后，再核对一次实际运行结果，才能知道它是否按预期执行。
Supabase：连接成功之后，还要做一个小检查
08:01 的插件部分展示了安装 Supabase 插件、进入授权流程，然后回到 dots 请求列出已有数据库信息。
本期看到的是它在连接后返回了相关列表。这可以说明应用连接进入了可读的工作环节，但没有覆盖数据库写入、迁移、权限修改或生产环境运维。
这样的顺序很值得保留：连接后先做小范围只读验证，确认账号和对象正确，再考虑更有影响的操作。不要把一次列出资源的结果理解为它已经有权处理所有数据。
并行开发：Godot 贪吃蛇和 Blender 巨石阵
08:37 的云端电脑展示中，我查看了浏览器、终端和开发工具。随后进入这期最直接的交付测试。
先派发一个简单游戏任务
09:05 的开发环节中，我让 dots 使用 Godot 开发最简单的贪吃蛇游戏。
选择简单游戏有一个好处：规则容易理解，结果也容易检查。能否移动、吃到食物、在触碰边界后结束，比复杂游戏里大量无法立即验证的设定更适合作为初次测试。
不等游戏完成，再追加模型任务
游戏开发进行中，我又让它使用 Blender 创建英国巨石阵模型。助手提示模型正在制作，贪吃蛇任务也继续推进。
本期可以确认的是，这两个任务在同一次使用过程中并行推进并分别交付。不能据此推导任意数量任务都不会相互影响，也没有测量并行前后的资源竞争或性能收益。
让项目跑起来，再自己验证
视频讲解记录了它打开 Godot 项目并运行游戏窗口：贪吃蛇走出边界后结束。随后助手报告逻辑测试和窗口检查通过，开始保存工程与截图。
这里需要分清两层证据：测试通过是助手的报告，游戏窗口运行和结束是演示中的可观察行为。它们都比只有代码文本更进一步，但不能代替完整测试报告。
10:27 的试玩部分，我下载源代码后运行游戏，实际控制贪吃蛇吃到食物，并对这个简单游戏的效果给出了正面评价。它至少说明交付物可以进入我自己的验证环节，不只停留在云端的一张截图。
Blender 交付了什么
同一段演示里，我继续要求输出巨石阵文件，拿到了模型效果渲染图和 Blender 文件。
渲染图方便看整体造型，工程文件则便于后续打开、编辑和检查。本文没有进一步声称完成了模型拓扑、尺寸精度、物理真实性或商业生产质量验收。它是一个三维建模任务的初步交付案例。
调用 Grok CLI：把外部工具接到云端任务中
11:06 的最后一个案例中，我让 dots 安装 Grok CLI。登录时，它给出了官方授权页面和设备授权流程，随后我让它调用这个工具开发一个简单登录页 Demo。
讲稿记录了等待后成功得到页面的过程。这个案例说明，在本期授权完成的环境中，dots 能把外部命令行工具接入开发流程。
这里的登录页是界面 Demo，不能据此推断已经实现真实用户认证、密码存储、会话管理或安全部署。视频提到其他命令行工具可以作为后续方向，但本文不把尚未在本期演示的工具逐一算作已经验证成功。
账号授权也应和普通任务区分开：只在对应服务的正规登录流程中操作，不把登录凭据写进提示词或公开文档。
我的结论：交付和验收比功能列表更重要
这次最让我有感受的是三件事：
- 语音指令可以接到应用里的实际工作，Notion 的查找、研究和写回形成了完整流程。
- 云端电脑可以承担具体开发任务，游戏和模型有各自的交付文件。
- 同时推进多个任务，让等待其中一个任务时仍能安排其他工作。
这些观察来自一次有限范围的体验：一个简单游戏、一个模型、一个页面 Demo，以及应用和任务设置流程。它们没有证明 dots 能独立完成所有生产级项目，也没有构成与 Muse 或其他智能体的统一对照评测。
如果你准备尝试，我更建议从一个验收条件清楚的小任务开始。提前说明要拿到什么文件、在哪里运行、怎样判断完成；拿到结果后亲自打开检查。等一个流程稳定了，再把更多任务交给它。
参考资料
- 本期完整视频与章节，2026 年 9 月 30 日发布。
- OpenAI：Introducing dots，产品定位、模型和用户控制说明。
- OpenAI：Getting started with your dot，当前入口、连接与资格条件。
官方资料核对日期：2026 年 10 月 24 日。文中的具体案例、操作顺序和主观体验以拍摄当时为准。