ChatGPT 与 OpenClaw 指南完成重大更新：模型之外，基础设施才是变量
原文：Our ChatGPT and OpenClaw Guides Just Got an Overhaul
作者：Katie Parrott｜发布时间：2026-08-27
我们谈论 AI 进展时，常常把它当成一场模型之间的竞赛——那是带有版本号的部分，也是你在晚餐桌上争论的内容。但模型只是其中一环。它之所以能进入你的工作，取决于你打开的应用程序、你允许它访问的文件和工具、你上次保存下来的指令，以及那个让这一切不至于过时的人。其中任何一项，都可能像新模型一样改变你的结果——有时甚至影响更大。
本周我们重写了两份指南。模型没有变；改变的是模型周围那些决定其行为和能力的基础设施。这些指南既是写给人的，也是写给智能体（agent）的，所以不妨把它分享给你的 agent，然后问它：“我们能从中学到什么，并调整到自己的工作中？”
知识工作在 ChatGPT 中终于有了自己的“家”
最初撰写《Codex for Knowledge Work》指南时，“用编码智能体接口处理编码以外的工作”这个想法还太新，连 OpenAI 自己都没有为它打造一个专门入口。现在有了。快速问题留在 Chat，更长的任务移到 Work，软件类工作交给 Codex。对不接触代码的知识工作者来说，绝大多数任务都可以交给 Work 处理。
我们把这份指南更名为 ChatGPT for Knowledge Work，并围绕新设置重写了内容。指南保留了原有的 16 个工作流程，但把其中大部分重新定位到 Work 上。更新还覆盖了初版写作时还不存在的多项功能：
Goals（目标）： 输入 /goal，把一个目标转化为带有“完成定义”（definition of done）的持续目标。
Projects（项目）： 在 ChatGPT 项目（把云端对话、文件和指令放在一起）和本地项目（把 Work 或 Codex 连接到电脑上的某个文件夹）之间做出选择。
Scheduled work（计划任务）： 在 Work 中使用 Scheduled Tasks 处理周期性任务；在 Codex 中使用线程自动化（thread automations）处理更长的循环。
Browser access（浏览器访问）： 应用内置浏览器有自己的登录态配置。当任务需要你现有的会话、标签页或扩展程序时，选择 Chrome。
👉 阅读：ChatGPT for Knowledge Work
我们对 OpenClaw 的推荐变了
我们的第一份 OpenClaw 指南 聚焦于个人智能体的吸引力。一个 Claw 会常驻在你的即时通讯应用里，连接你授权的工具，不需要每次重新提示就能持续处理重复性工作。对愿意维护它的人来说，这种设置仍然可以异常有用。
这次更新补充了我们自己运行 Claw 后学到的经验。更强的模型依然无法在凭证过期时替你登录；它不会注意到上周某个集成坏了，也不会发现你几个月前设置的某个任务其实早该关掉。把智能体放到服务器上可以让它持续运行——但依然需要有人保持它的工具连接、更新权限、并防止它的记忆被过时指令塞满。就目前而言，那个“有人”是一种负担。
随着公司增加人手，这种维护负担只会越来越重。所以我们尝试了另一种方式：Every Agent。它生活在 Slack 里，整个公司共享同一个智能体——但每个员工通过自己的连接和上下文来工作。
如果你有只属于你自己的重复性工作、希望控制工具和指令、不需要公司上下文、并且愿意维护它，那么个人 Claw 仍然可能合理。更新后的指南会帮你判断这种权衡是否值得，然后解释 Claw 通常在哪些地方会出问题，以及如何限制它的权限。
👉 阅读：更新后的 OpenClaw 指南
核心启示：模型的进步只是 AI 工作效果的一个变量；真正决定结果差异的，是应用入口、工具连接、指令维护和人的持续运营——这也是这次两份指南改版想传达的核心信息。
Our ChatGPT and OpenClaw Guides Just Got an Overhaul 的发芽报告
材料核心
这篇文章宣布 Every 重写了两份 AI 指南——ChatGPT for Knowledge Work 和 OpenClaw——但真正的论点藏在开头两段：AI 进步不只是一场模型赛跑，模型周围的"基础设施"（应用、文件、工具、已保存的指令、以及维护这一切的人）同样决定结果，有时更甚。
发芽 01：模型定潜力上限，基础设施定实际产出
种子
Parrott 说："We talk about AI progress like it's a race between models." 版本号是晚餐话题，但真正改变工作结果的是那个清单："the app you open it in, the files and tools you let it touch, the instructions you've saved from last time, and the person keeping all of that from going stale." 这暗示一个反直觉的判断：模型能力设的是潜力上限，而基础设施决定那个上限有多少变成你的实际产出。
故事
经济学家 Robert Solow 在 1987 年说过一句后来被反复引用的话："You can see the computer age everywhere but in the productivity statistics."（计算机时代无处不在，唯独生产力统计里看不到。）这句话成了著名的"生产力悖论"，困扰经济学界近十年：计算机性能每年翻倍，但宏观生产力数据无动于衷。后来的企业层面追踪研究（Erik Brynjolfsson 等人的工作）发现，关键变量不是计算机本身，而是企业有没有同步投资于"互补性资产"——新流程、新岗位设计、员工培训。只有硬件和软件、没有组织改写，IT 就只是昂贵的打字机。
更早的蒸汽机走了同一条路。经济史学家 Nicholas Crafts 的研究显示，蒸汽机在 1830 年之前对英国生产力增长的拉动甚微。真正释放蒸汽机价值的不是换了一台更好的发动机，而是工厂物理形态的重建：从围绕中央水轮布置的多层垂直厂房，改成让每台机器独立由蒸汽驱动的单层开放式厂房。"发动机"升级了，整个工厂也得重画。
现在 ChatGPT 从 Chat 移到 Work、Codex 从编码工具变成知识工作入口，正是一次类比的"工厂重画"：模型没变，工作环境变了，结果就会变。
Aha 瞬间
"版本号是模型的潜力，基础设施是模型的表现——你日常感受到的 AI 进步，大部分其实是水管工换好了管道。"
发芽 02：每一个自动化的系统，都会在别处长出新的维护工作
种子
OpenClaw 指南更新的核心转折是语气变化：从"个人智能体的魅力"变成"维护负担"。文章说："A stronger model still can't log in when a credential expires. It can't notice that an integration broke last week... For now, that somebody is a burden." 我们以为买了一个智能体就买到了劳动力，结果还附带了一份永久性的兼职：当它的保姆。
故事
这个现象在自动化系统领域早有预言。1983 年，认知工程师 Lisanne Bainbridge 发表了后来成为经典的论文《The Ironies of Automation》（自动化的反讽）。她指出一个反直觉的规律：系统越自动化，留在人手里的残余任务反而越关键、越难。常规工作被机器接管后，人剩下的岗位是"监控 + 异常干预"——盯着一台基本正常的系统，等待偶发故障。而人类恰恰最不擅长这种持续性警戒。自动化没有消灭操作员，它把操作员变成了"待命者"。
智能体把这个结构复制到了个人办公场景：你不再每天写 prompt，但你要检查 credential 有没有过期、integration 有没有断、memory 里是不是塞满了过期指令。工作从"做任务"变成了"检查任务"。Andrew Russell 和 Lee Vinsel 在《The Innovation Delusion》（2020）中给这个现象提供了一个文化侧写：我们崇拜创新，鄙视维护，偏偏维护才是价值产出的主战场。
Every Agent 的做法——把全公司的维护负担集中到一个共享智能体上，而不是每人养一只 Claw——是对这份"维护税"的组织化回应。
Aha 瞬间
"自动化不会消灭工作，它只把工作搬到更没人愿意做的位置：监控和维护。Agent 的瓶颈不是它不会做什么，而是谁来负责养它。"
发芽 03：上下文的产权问题——个人 agent 还是共享 agent？
种子
文章里 Every Agent 的设计值得停下来读："It lives in Slack, so the whole company shares one agent—but each person works through their own connections and own context." 维护是共享的，上下文是私有的。这是一个组织设计决策，穿了一件产品的外衣。它真正问的是：上下文（你的指令、连接、记忆）算个人财产还是公司资产？
故事
这像是个人电脑史上一个争论的重演。1970 年代，大型机是"共享但受控"的：一台机器、一个 IT 部门、大家排队提交作业。PC 的兴起是个人自治的革命——Xerox Alto、Apple II、IBM PC，把计算能力放到了个体桌上，绕过了 IT 看门人。但 1990 年代之后，网络和云又把一部分能力抽回了共享设施。每一次来回，争论的核心都是同一件事：算力和数据应该住在个人身边，还是住在公共设施里？
智能体把这场争论推进到了新层面：现在"上下文"本身成了类似算力的资源。你的指令集、你的连接授权、你积累的工作状态——是应该跟人走（个人 Claw），还是沉淀到公司设施里（共享 Slack agent）？Every Agent 的答案是妥协式的：维护共享化，上下文个人化。这比 PC 时代更精妙——它把"用谁的工具"和"用谁的记忆"拆成了两个问题，分别回答。
Aha 瞬间
"以前我们争论计算能力该属于个人还是组织；现在同样的争论发生在了上下文身上。谁拥有智能体的记忆，谁就定义了智能体为谁工作。"
你的思考空间
- 如果"基础设施决定结果"成立，我们为什么仍然用模型版本号作为 AI 进步的核心度量？一份"系统级基准"应该测试什么？
- 当维护工作成为瓶颈时，我们会选择自己维护、训练另一个智能体来维护，还是干脆放弃智能体？哪一种路径更接近现实？
- "共享维护 + 私人上下文"的组合在组织里会催生什么新协调问题？当个人的上下文和公司的共享上下文冲突时，听谁的？
- Parrott 说这份指南"写得像给智能体也看"——如果文档、指令、甚至写作都要同时给人和 agent 读，我们的写作方式应如何改变？
- 如果模型性能不再是主要瓶颈，"AI 产品"的竞争重心会不会转向基础设施维护能力（工具接驳、上下文管理、记忆卫生）？这会让谁受益，又让谁失业？