AI Cloud Atlas：给人和 AI 一张共同的地图
我想让人与 AI 一起工作时，少花一些力气在反复拼上下文上，把注意力留给真正需要想清楚的事。
读过的 paper、讨论过的设计、后来改掉的决定，材料会越来越多。真正要做判断之前，我们常常还得先把分散的记录，重新凑成自己能理解的样子。即使一直用同一个 Agent，这个负担也会存在。
我们正在 ArcBlock 内部尝试一件事，叫 Atlas。它要把原始材料，以及材料之间的关系和演变，组织成人和 AI 共同可以理解的地图。人可以看清事情的来龙去脉，Agent 也有结构可循，帮助整理、分析和推进。减少恢复上下文的认知负担，是我们想探索的核心。今天的实验从软件开发开始，怎样延伸到一个人的工作与生活，还在探索中。
说到 Atlas，我会想到我很喜欢的电影《云图》。2012 年的这部电影由 Lana Wachowski、Tom Tykwer 和 Lilly Wachowski 执导，改编自 David Mitchell 的小说。它把不同时代的故事交错剪在一起，前面的片段，会在后面的故事里获得另一层意思。[1]
我喜欢那种宿命感和未来感。做软件当然没有这么浪漫，不过有一点很像：当时看不出用途的片段，过一段时间再看，可能正是另一件事的起点。
现在：这篇文章是从聊天里长出来的
写这篇文章之前，我正在和 AI 讨论 Atlas。
最初聊的是软件开发。我们把 Arc 项目里的 Intent、计划、会议记录，以及 GitHub 上的 Issue 和 PR 纳进来，希望看清一个 Feature 是怎么做出来的。代码变多之后，单看代码很难回答这个问题。一个设计为什么这样选，中间改过几次，最初的要求有没有丢，答案常常散在别处。
聊着聊着，范围就变了。我说，灵感不只来自工作。看到一款有趣的软件，拍了一张风景照片，读到一篇还没看懂的 paper，都可能值得先留下。它今天没有任务，甚至没有结论，也没关系。
然后我又补了一句：同样这些材料，还可以拿来写一篇文章。不一定非得变成执行计划。
于是有了你现在读到的这一篇。原始讨论保留在内部 Atlas，文章在另一个内容仓库里完成。我们正在试着让 AI 从已有材料出发，做出一个不同形态的结果，同时留下这份结果从哪里来的线索。
先把几块拼图摆清楚
读到这里，可能会觉得：ArcBlock 怎么又来了一个名字？其实 Atlas 接着的是我们已经在做的几块拼图。
ArcSpace 是共同的数据基础。在我们的架构里，网站、应用和 Atlas 围绕它保存和使用数据。内容可以在仓库里编辑、留下版本，发布和使用时有自己的数据空间。Arc（Agentic Realm Computer）提供计算环境，让应用运行，让交代给 AI 的工作有地方执行。一个放数据，一个把工作跑起来。
收集这一端，我们已经有一个小工具，叫 Aside。在手机上读到一篇文章，或者碰到一个想研究的 App，可以把链接通过系统分享存进 Aside，顺便写一句为什么想留下它。Aside 的基础也是 ArcSpace：它让日常遇到的内容更容易成为空间里的原始素材。这篇实际使用介绍展示了怎样保存网页，并把自己的收藏理由留在旁边。
Atlas 要做的，是把这些素材，以及后来形成的想法、设计和执行结果组织起来。它想回答的是：这份材料和什么有关？我们后来怎样理解它，又根据它做了什么？比如先在 Aside 留下一篇文章，过一阵子和 Agent 讨论它，再形成产品想法或写作材料。收集时不用先决定它最后会长成什么。
所以我们在做的这几块，各有自己的工作：Aside 让随手收集变容易，ArcSpace 保存材料，Arc 提供计算与执行，Atlas 把材料和它们的演变组织成地图。Aside 已经可以用；Atlas 仍是我们内部正在尝试的那一块。
稍后：有些想法，先别急着安排工作
我一直受 GTD 的影响。脑子里有东西，先 dump 下来，再整理。否则为了决定应该放进哪个文件夹，可能连那点灵感都忘了。
Atlas 让我们想继续往前走一点：先记录，不急着要求每个片段都证明自己的价值。
下面几幕是我想象中的未来用法。
比如在展览里看到一个有趣的装置，拍张照片，对自己的 Agent 说：“这个先留着。我还没想清楚为什么喜欢它。”它能把照片和这句话一起保留下来，就已经帮上忙了。过几天，你在琢磨一个界面，也许会想起那张照片。到那时，再讨论它们有没有关系。
也可能一直没有关系。留下一张喜欢的照片，本身就可以是全部结果。
《Cloud Atlas》官方宣传剧照，© 2012 Warner Bros.[1]
电影可以在不同年代之间切换，一个人的生活也很少按“工作”“研究”“娱乐”分好章节再发生。收集时允许它们混在一起，回看时再按眼前的问题整理，比较符合我的习惯。
过了一阵子：那篇看不懂的 paper
再想一幕。读到一篇 paper，感觉不明觉厉，但确实还没看懂。先收下来，请 Agent 帮忙分析，也可以请另一个人看看。
当时的疑问要留下，后来的解释也要留下。如果几个月以后，它启发了一个产品想法，我希望能看见这段过程：原来我不是一开始就想明白了。
这也是 Atlas 这个“地图”比喻吸引我的地方。它可以帮我们回到一个想法发生的地方，也可以从今天的问题出发，找回以前留下的材料。AI 能提出新的关联，人再判断有没有道理。
有些关联只是 AI 的猜测。把猜测和人的决定分开存，日后才不会把一句“也许可以试试”看成“当时已经决定要做”。
需要组织的，还有一份材料被怎样理解、某个判断依赖哪些证据，以及它后来影响了什么。我希望每次回到一个问题时，地图都能把这些脉络摆出来，AI 也可以帮忙检查有没有遗漏。人就能少花力气恢复背景，不必一直在脑子里维持所有连接，再去判断哪些关联有意义、下一步值得做什么。
回到工作：先看见要做成什么样
在软件开发里，这个区别尤其重要。
我们希望先把需求说清楚，让 Agent 做设计，再推导出“假定已经完成，产品文档会怎样写”。人可以看界面、读文档，判断这是不是自己想要的东西。确认之后，再交给我们所说的软件工厂，也就是负责安排和推进编码、检查等工作的自动化流程，去实施。
这条流程正在探索中，但它来自一个很实际的判断：我能判断一个界面好不好，也能判断一个功能描述对不对；我很难靠逐行阅读越来越多的 AI 代码，完成同样的判断。
而且，Feature 的历史不该随注意力一起消失。我们曾经集中做这套工厂流程，后来转去做别的；某个能力的名字也会改变。等再回头，它仍然应该能连回早先的讨论、设计和实现。只看最近几篇文档，通常看不见这些。
目前这个实验把内容放在有版本记录的仓库里，以丰富的文档为主体，再补人物、项目、术语和来源关系。它已经让我们能开始整理原有材料。跨材料的关联是否准确、怎样让人更容易浏览，还需要继续验证。
未来：沿着同一张地图一起工作
如果把视野拉长，我希望自己可以用最顺手的 Agent。写程序时用 code agent，平时用 personal agent。不同工具能沿着同一份结构继续，是这张地图带来的一个结果；更重要的是，人和 AI 可以围绕眼前的问题，看清已有材料和仍待解决的部分。
沿着这套共同的数据基础，我们希望人可以在网站里阅读这张地图，Agent 可以通过 AFS（Agentic File System）按路径读取和操作其中的材料。收集入口、阅读界面和执行工具可以不同，同一份想法仍然能被认出来。
在这个目标体验里，一个人可以先和自己的 Agent 讲话，再逐渐决定哪些材料归个人，哪些应该投到公司的项目里。共享或订阅之后，还需要认出同一个对象的来源和版本；具体给谁看、谁能改，也要有明确的边界。这些都属于我们要继续做的设计，不能靠给文件贴个标签就算完成。
《Cloud Atlas》官方宣传剧照，© 2012 Warner Bros.[1]
我想要的那个伙伴，能帮忙整理，能执行交代过的事情，也能把以前的想法拿回来一起讨论。至于什么值得做、一个设计是不是自己想要的，仍然要由人来想、来决定。
它可以一直陪着你，但没有必要把你的每一个念头都排成任务。
今天就能尝试的部分
Atlas 现在是内部实验，还没有作为产品对外发布。不过，这个工作方法不需要等产品完成。
找一个自己能持续保存的地方，保留原始笔记。请 AI 整理时，让它把整理稿与原话分开，标明来源、时间和版本。准备让它动手之前，再明确说清哪些结论已经确认。得到结果后，把结果连回产生它的材料。
材料少的时候，普通笔记就够用。一次性的查询、订票，也未必需要专门建一张地图。我们想尝试的是那些会不断回头看、还会继续变化的事情：一个长期项目，或一个人持续几年的兴趣。
眼前这次实验很小：一段聊天，先成了两份意图记录，又成了写文章的指令，最后成为这篇 blog。它们有联系，却不需要长成同一种东西。
回到《云图》那个让我喜欢的感觉：后来的故事，让前面的片段有了新的意义。Atlas 想留下的，也包括这些联系怎样形成、怎样改变，以及哪些判断仍然没有答案。
如果它们能在一张人和 AI 都能理解的地图上呈现出来，下次回来，我们就可以从眼前的问题继续往前想。我希望把精力用来判断接下来要做什么，不必每次先把整个背景重新装回脑子里。
参考
[1] 《Cloud Atlas》官方电影页；Warner Bros. 官方宣传图库。电影改编自 David Mitchell 的同名小说。文中剧照用于讨论电影的交错时间叙事，版权归相关权利人所有。