为什么需要一种新的文件格式

我们被问得最多的，也是最合情合理的一个问题是：为什么 .deepcell 这种东西非要存在不可？难道不能在 Excel 之上套一个更聪明的智能体，然后就此收工吗？

我们试过。差不多有一年，这就是我们的计划。

但这个计划一遇到两个智能体处理同一个模型，就崩溃了。

约束在于文件本身，而不是它上面那层模型#

人们常把电子表格描述成两个文件硬拼在一起——一个公式图和一份值的快照。这说法没错，但低估了问题的严重性。工作簿里还有第三样东西，没人会提起，因为它根本就不在文件里：作者的工作记忆。为什么用这个折现率。为什么增长曲线在 2027 年拐弯。分析师最先试过、又被弃用的是哪个情景。这个数字的来源是什么。这个数字又意味着什么。

当一个人从头到尾掌控整个模型时，工作记忆就装在他脑子里，这没问题。他打开工作簿，值被计算出来，而为什么则从它唯一被存放过的地方被重新唤起。

可一旦有第二个读者碰了这个文件，工作记忆就没了。值还在。公式还在。但推理已经蒸发殆尽。

在单作者的世界里，这还能忍。但在这样一个世界里就不行了：分析师把一个模型交给智能体，智能体扩展它、再交回来，下周又有另一个智能体接手去做敏感性分析。每一次交接都是一次记忆清零。

智能体能产出一份干净的 xlsx，却读不懂彼此的成果#

这部分让我们颇感意外。从零开始生成一个工作簿是个已经被解决的问题——给一个有能力的模型一段提示词，它就能写出一份说得过去的 xlsx 三表模型。它看上去没毛病。它能勾稽得上。

把这同一份 xlsx 交给第二个智能体，让它加一个 LBO 情景。

第二个智能体看到的，是一张由字符串组成的网格。单元格是字符串。公式是字符串。第 14 行有一个合并区域，意思是"表头"，可在现金流量表里，同样的视觉样式却表示"小计"。有一个叫 Revenue 的命名区域，在模型标签页里指向某一列，在可比公司标签页里又指向另一列。第一个智能体所用的那些约定——间距、配色、假设放在哪里、输出又放在哪里——对第二个智能体来说是不可见的，因为它们从未被写下来。它们只是风格。

每一个 Excel 模型都会堆积起临时拼凑的约定，而这些约定撑不过一次交接。人与人之间撑不过，智能体之间撑不过，人与智能体之间尤其撑不过。

约束并不在于 AI 的质量，而在于文件。

我们需要文件承载什么#

一旦接受了这一点，问题就不再是*"我们怎么让智能体更擅长 Excel？"，而变成了"如果一个文件是为两个读者、而非一个读者设计的，它会是什么样子？"*

答案原来是一小组明确的基本要素。剖析篇 对它们做了详细讲解；简短版本是，.deepcell 把工作簿混为一谈的四样东西分了开来：

• ItemDefs——行项目，带有层级和类型约束。
• ContextDefs——每个值所处的维度：条目 × 时间 × 情景 × 状态。
• CalcDefs——带有显式依赖的公式，作为有向无环图（DAG）求值。NPV、IRR、SUMIF、IF 以及另外 30 多个函数，并自带循环依赖处理，无需在"选项"里勾选某个复选框。
• Reasoning——一个由 Claims、Assumptions、Evidence 和 Arguments 构成的带类型的图。这就是被写下来的工作记忆，写在文件里，让下一个读者能找到它。

值不再是单元格里的一个字符串。它是一个事实，被钉在模型所定义的四维空间中的某个坐标上。公式也不再是字符串——它是依赖图中的一个节点，引擎可以向前追溯（什么依赖于它？）或向后追溯（它又依赖于什么？），而无需解析文本。

最后这一点，正是让多智能体协作成为可能的关键。第二个智能体不必去逆向破解第一个智能体的约定。约定就是 schema 本身。

一个具体的对比#

两位分析师处理同一个模型，Excel 的做法：

analyst_a/Q3_model_v7.xlsx
analyst_b/Q3_model_v7_LBO_scenario.xlsx
→ merge: rebuild from scratch, hope nothing dropped

你知道这会怎样收场。有人发来一条 Slack 消息，附三张截图。另一个人把两个文件并排打开，把数字从一个文件里敲进另一个文件。这次合并是一场手工重建，而审计追踪就是那条 Slack 消息串。

两位分析师处理同一个模型，DeepCell 的做法：

deepcell variant create lbo-scenario
# ... edits happen on the variant ...
deepcell diff lbo-scenario main
deepcell merge lbo-scenario --into main

变体是模型的一个一等分支。差异是语义层面的——它会告诉你哪些 CalcDefs 变了，哪些值在哪个情景中被覆盖，哪些 Assumptions 被新增或修订。合并是依赖感知的：如果 LBO 情景改了债务成本假设，而 main 改了最终依赖于它的收入公式，引擎就会重新计算，并逐单元格、而非逐工作簿地呈现冲突。

让一个智能体能把模型交给另一个智能体的那套基本要素，也正是让两个人能真正协作于其上的那套要素。版本管理是原生 git——log、diff、restore、commit、merge、variant——因为"两个人改了同一样东西"这个问题比电子表格还要古老，而且二十年来一直有一个不错的答案。

共存，而非取代#

以上种种，都不是反对 Excel 的论据。Excel 是有史以来为"一个人做快速分析、并把结果发给一个永远不会安装任何软件的人"而打造的最好的工具。这种使用场景不会消失，我们也不希望它消失。

我们想要的，是一种面向那些存活超过 24 小时的模型的格式——那些被传来传去、被扩展、被审计、被修订，并在六个月后的一份备忘录里被引用的模型。为此，文件就必须承载比一张网格更多的东西。

我们能与 xlsx 之间干净地往返转换——往返转换篇讲解了其中的机制——因为邮件另一端的利益相关方仍然想要一个工作簿。.deepcell 是唯一可信源；xlsx 只是它的一个视图。智能体读写的是源，而人读的则是最有用的那个视图。

这就是这笔交易。一种新格式，因为旧的那种是为单一读者设计的，而这个世界已不再是单一读者的世界了。

亲自来看看吧——在在线演练场中打开一个示例 .deepcell。编辑一个值，看着它的依赖项重新计算，检视任何一个数字背后的推理。