1. 不是 Doc，是 Dot，而且更像“负责人”而不是聊天窗口
名字很容易听错。不是 Doc，而是 Dot。
普通 ChatGPT 往往是：你提问，它思考，它回答，然后这一轮结束。Dot 不太一样。OpenAI 将 Dots 描述为由 GPT-6 Astra 驱动的 always-on agents，拥有自己的云端电脑和浏览器，可以使用已连接的应用，并持续朝长期目标推进。
所以它更像“负责这个项目的人”，而不仅仅是“回答问题的AI”。
AI终于从聊天框调岗到了责任人名单。
2. “24小时运行”不是无限死循环，而是责任不会随着对话结束而消失
这里最容易误解。24小时可用不等于免费VPS，也不等于CPU每秒都在不停运行。
真正重要的是连续性。Dot可以在对话结束后继续保有任务责任，进行后台研究、定期检查、读取已连接的信息源，并执行你安排的周期性工作。OpenAI把这种后台主动查找有用信息的行为称为 proactive research。
旧模式是：人先想起这件事，再打开AI，再恢复上下文，再重新发指令。Dot的模式是：负责人还在，项目没有因为聊天窗口关闭而失忆。
人类在“上次做到哪了？”这件事上浪费的时间，往往比想象中多。
3. 首次创建以桌面端为主，创建后可以带到手机上
第一个 Dot 需要在 ChatGPT 桌面应用或电脑浏览器里创建。你给它命名，告诉它目标，连接需要的应用，并规定哪些操作可以自行执行。
设置完成后，就可以在手机 App 里继续与它交流。可以理解为：出生登记在电脑上办理，之后把它装进口袋里。
Dot的个人页可以查看进行中、已计划和已完成的工作，也可以管理周期任务的执行频率和通知。访问你的本地电脑是可选项；默认情况下，Dot本身已经有一台独立的云端电脑。
因此并不需要为了让Dot常驻而把家里的电脑整夜开着。
4. 使用量政策很香，但官方并没有说“永久、完全、无限”
发布初期，第一个 Dot 对符合条件的 Pro 和 Business Premium 用户不额外收费。Enterprise 系列则是由管理员开启的 Beta。
OpenAI表示，与Dot的对话不计入普通ChatGPT使用限制。方案还包含一定的 deeper work 配额，而且上线后的第一个月限额会扩大。发布说明进一步写明，首月内，符合条件用户的 Dots 使用不会计入其方案的常规使用额度。
早期用户也分享过一些案例，例如让创作类重任务跑一整晚，而常规使用量几乎没有变化。这和上线期政策并不矛盾，但不能据此推导出“永久免费无限算力农场”。
另外，如果Dot创建或管理Codex、ChatGPT Work任务，这些任务仍会正常消耗相应产品的额度。
不是无限自助餐，但前菜确实豪华得有点可疑。
5. 最有价值的用法，可能是“周期任务的常驻补助员”
Scheduled Tasks很擅长按时开始工作。但现实自动化里，真正困难的通常不是开始，而是收尾。
API偶发失败。权限不足。某一个步骤超时。只有一个子任务失败。日志写好了，blocker分类了，next action也记下了。
然后，没有人去执行next action。
自动化经典剧情。
把Dot放在这里，分工就很清楚。
Scheduled Task负责“到点开工”。Dot负责“没有真正结束就不算结束”。
当某次运行变成PARTIAL、BLOCKED、HOLD或FAILED时，Dot重新读取当前状态，从最后确认的检查点继续。独立且安全的工作继续推进。若根因是代码，就修复；需要复杂开发时再交给专门的编码代理，并在它完成后继续收结果、复检和推进。
系统从“失败提醒器”变成了“失败后仍然有人负责”。
6. Dot、Scheduled Task、Codex可以理解成现场主管、时钟和维修队
用三层模型最容易理解。
Scheduled Task是时钟：在正确的时间或条件下启动工作。
Dot是现场主管：跨多次运行保持状态，发现未完成项，安排下一步，避免无脑重试，推动根因修复，并持续追踪到真正的终态。
Codex是维修队：只有在需要实际代码修改、测试、重构或复杂实现时才叫它上场。
最重要的一条是：“创建了Codex任务”不等于完成。
Codex启动 → 产生修改 → 检查diff → 测试 → 应用 → 重新运行流程 → 检查真实结果。
闭环到这里才算结束。
维修工接到电话，不代表厂长可以下班。
7. 故障处理应该是闭环，而不是报告生成器
给常驻补助员写指令时，最重要的是“什么时候才允许停止”。
弱指令是：“发现失败就告诉我。”这会得到一台很贵的监控摄像头。
强指令是：“发现失败后读取当前状态，定位原因，执行最小且安全的修复，重新验证；只要还有可执行的未完成工作就继续。若需要代码修改，交给编码代理，收回结果后再次验证。若本轮无法结束，则保存精确检查点和下一步，让下一轮从那里继续。”
如果同类问题反复发生，还要回头检查原Scheduled Task的提示词、停止条件、引用信息、假设和完成判定。
“根因已经分类”在现场就像说：“我们知道这是什么类型的火了。”
很好。现在灭火。
8. 但不需要把整个王国的最高权限交给Dot
Dots支持权限管理和Custom Rules。你可以规定哪些动作可自动执行，哪些需要预批准，哪些必须每次确认，哪些必须交还给人类。
proactive research本身也被刻意限制。它可以读取允许的连接来源并保存私人笔记，但研究工具不能直接给别人发消息、修改插件里的内容，也不能控制浏览器或电脑。真正的修改操作会回到正常的权限、审批和安全检查流程。
这不是单纯的缺点。一个24小时工作的操作员，并不需要同时拥有24小时摧毁生产环境的权力。
合理的原则是：观察范围可以宽，重大操作权限要窄。
9. 真正用起来后，“懂事”的含义是：还没问，答案已经放在那里了
开始实际使用Dot之后，会发现除了给Scheduled Tasks当补助员，它还特别适合接手那些过去必须由人记住并反复询问的检查工作。
例如，它可以持续观察访问量，把开始增长的文章走势画成图。然后再往前一步，不只回答“哪些文章涨了”，而是整理“增长文章有哪些共同特征”。主题、入口、语言、发布后的变化、站内流动等可观察信号，都可以从一次性提问变成持续分析。
运维也是一样。如果Cloudflare或GitHub某处卡住，Dot可以先看当前状态，缩小原因范围，在权限允许且安全的情况下修复，并继续追踪到真正完成。这样就不必每次都问“现在卡在哪里？”“访问量怎么样？”“哪些文章开始涨了？”。打开Dot时，调查、图表或修复工作可能已经推进。
这可能才是最实用的“聪明”。
而且实际使用时，它并不只是看数据。它还会推进Cloudflare构建、观察GitHub当前状态，并在需要时执行修复。也就是说，它不只是“发现异常然后报告”的监控层，而是在权限允许时直接下场干活。
到这里，“懂事”就不再只是一个可爱的形容词，而是很具体的工作体验：看、修、验证、继续推进，不需要每一步都重新等人下微指令。它开始从“好用的工具”变成“真正接手任务的负责人”。
不是每次都去AI那里取答案，而是去看一个专属负责人的桌面：图表、原因分析和修复结果已经摆好了。
“很懂事的AI”听起来很抽象，但在工作里很具体：它会提前捡起那些过去必须由你自己记住、再一遍遍询问的问题。
真正节省时间的地方，也许不是回答更快，而是人不再需要一直记着“这个还得去确认”。
而且实际使用时，它不只做观察。它可以跟进Cloudflare的构建状态，查看GitHub里的实际情况，并在权限和安全规则允许时直接推进必要修复。行为开始从“发现问题了”变成“发现后已经处理了”。
到这里，“感觉挺懂事”就会变成“确实挺懂事”。人不再需要每次自己巡回Dashboard、仓库、Build状态和卡住的任务。
慢慢地，这不再像是“给AI派活”，而更像是去查看一个本来就在盯系统的负责人已经做了什么。
10. 结论：真正的魔法不是“永远在线”，而是“持续负责”
Dots最重要的变化，并不是多了一个更聪明的聊天界面。
而是当人离开后，任务仍有上下文、有责任人，可以跨周期任务和连接应用继续推进，并从上一次失败的位置继续，而不是每次重新讲故事。
所以，与其把它当普通聊天对象，不如把它放在那些经常半途失败的周期流程上：盯运行、捡未完成、必要时叫专家修代码，然后一直追到真正完成。
这是AI版的鞋匠小精灵。
不过第二天早上，不要只看鞋做出来没有。还要试试合不合脚。
目标不是报告，而是完工。
