一个 .deepcell 的剖析

一个谨慎的人面对一种新文件格式时，问出的第一个问题往往是对的那一个：里面有什么，我又能不能脱身？

黑箱式的格式对厂商而言是护城河，对用户而言是陷阱。你无法审计自己读不懂的东西，也无法导出自己解析不了的东西。而「相信我们，它是结构化的」这句话，从任何靠留住用户维生的厂商口中说出，都不值得当真。

所以 .deepcell 恰恰相反。在任意文本编辑器中打开一个，你就能读懂它。它是纯文本，而不是专有的二进制黑箱——结构清晰、标注明确、人能读懂。用普通工具就能比对两个版本，看出改了什么。没有任何东西被藏起来。它有八个部分，每个部分各司其职，你可以从头到尾像读散文一样读完。

铺陈你正在阅读的这篇文章的那张矩阵，本身就是一个 .deepcell。十六篇博客文章作为项目（Items），六种财务角色加三个客户细分作为上下文（Contexts），受众契合度作为单元格的值。没有公式，没有推理批注——结构极简，因为这个示例只需要这么多。我们会一个部分一个部分地走一遍。

八个部分#

Header → StatusDefs → ContextDefs → ItemDefs →
CalcDefs → PresentationDefs → Values → Reasoning

CalcDefs 和 Reasoning 都是可选的。矩阵文件省略了它们。一个三表模型则会用到每一个部分。

1. Header#

谁、什么、何时。自由文本，标注清晰——整个部分读起来就是一份简单的清单：

如果别的什么都不记得，请记住这一点：标题和描述就是放在一个普通标签下的纯文本。没有专有编码，没有厂商的黑魔法。

2. StatusDefs#

每个值都带有一个状态。在财务模型里，这就是 actual（已披露的实际数）、projected（你手上正在用的预测）、forecast（一条备选的前瞻路径）以及你的团队需要的任何自定义标签之间的区别。计算引擎用状态来决定哪些值对哪个情景可见——实际值会覆盖预测值，依此类推。

矩阵文件只需要一个：一个标注为「Audience fit」（受众契合度）的状态。

一条意义的轴线。这份文档要做的就只有这些。

3. ContextDefs#

时间与情景的轴线。在一个现金流折现（DCF）模型里，Q1_2027、Q2_2027、base_case、bear_case 就活在这里。而在矩阵中，「上下文」这条轴线不是时间——而是受众。下面的标签你不必细读——重点只是每一类受众都被清晰地标注了出来：

<ContextDefinitions>
  <Context contextId="SS" level="0" statusRef="fit">
    <Label>Sell-side analyst</Label>
  </Context>
  <Context contextId="BS" level="0" statusRef="fit">
    <Label>Buy-side analyst (public markets)</Label>
  </Context>
  <Context contextId="PV" level="0" statusRef="fit">
    <Label>PE / VC analyst</Label>
  </Context>
  <!-- FPA, CF, IB, Individual, Team, Enterprise ... -->
</ContextDefinitions>

财务模型把它的各个时间段铺在这同一条轴线上。形态是一样的，变的只是标签。

4. ItemDefs#

行的轴线。行项目。在模型里它们是 Revenue、COGS、Gross_Margin——也就是各个行项目，按层级组织（最多四层），这样系统就知道哪些行汇总进哪些小计。在矩阵里，它们是博客文章。下面的标签你不必细读——重点只是每一个字段都被清晰地标注了出来：

<Item itemId="post_03" order="30" level="0">
  <Label>[T1] Anatomy of a .deepcell</Label>
  <Description>What's inside the file? Am I locked in?</Description>
  <DataType>category</DataType>
</Item>

level="0" 表示顶层。一张合并损益表会把 Revenue 放在 level 0，把 Product_Revenue 和 Service_Revenue 放在 level 1，再把 SKU 级别的明细行放在它们之下。这套层级由引擎强制校验——如果一个父级下面还有子级在干活，你就不能把值直接记到这个父级上。

5. CalcDefs#

矩阵一个都没有。它是一张实打实的表格，每个单元格都是直接写入的。所以 <CalculationDefinitions/> 空在那里：

<CalculationDefinitions/>

而在一个三表模型里，正是这个部分让这份文档名副其实。下面的标签你不必细读——重点只是每一条计算都清晰地写明了它产出的那一行以及背后的公式（仅作示意——你的模型会有成百上千条）：

<Calculation itemRef="Gross_Margin"
             formula="Revenue - COGS"
             scenarioRef="base_case"/>

引擎自带 NPV、IRR、SUMIF、IF 以及大约另外三十个函数，会算清楚哪个单元格给哪个供数，检测循环引用，并在编辑时重新计算。重点不在于函数库——Excel 的更多。重点在于公式活在它们自己的部分里，与它们产出的值可以分开寻址。这正是它们可审计的原因。

6. PresentationDefs#

数据在屏幕上如何布局。本例中是一个工作表、一个区块——一张名为「Audience fit by post」的表格，文章沿行向下排列，九类受众横向排列，从序号 10 一直到 160。

正是它告诉界面显示——Web 网格、Excel 插件、导出器，三者都取自同一份底层蓝图——项目向下排列，上下文横向排列，区块从序号 10 一直跑到 160。呈现与数据是分开的。重新透视是一次呈现编辑，而不是一次模型编辑。

7. Values#

单元格本身。按项目和状态分组。下面的标签你不必细读——每一行不过是一类受众和它的评级：

<ItemGroup itemRef="post_01" statusRef="fit">
  <Value contextRef="SS">primary</Value>
  <Value contextRef="BS">primary</Value>
  <Value contextRef="PV">primary</Value>
  <Value contextRef="FPA">secondary</Value>
  <Value contextRef="CF">primary</Value>
  <Value contextRef="IB">secondary</Value>
  <Value contextRef="Individual">primary</Value>
  <Value contextRef="Team">primary</Value>
  <Value contextRef="Enterprise">primary</Value>
</ItemGroup>

把这个区块大声读出来，你就得到了矩阵中一行的规格。「第 1 篇文章对卖方、买方、PE/VC、财务总监、个人、团队和企业而言是主要目标；对财务规划与分析（FP&A）和交易分析师而言是次要目标。」文件准确地告诉你的就是这些，而且就是这个顺序。

一个 .deepcell 里的每一个事实，都是这些 <Value> 元素之一，由项目 × 时间 × 情景 × 状态寻址。四个维度。没有隐藏状态。

8. Reasoning#

矩阵不携带任何推理。一个真正的模型则会——用结构化的条目表示主张（Claims）、假设（Assumptions）、证据（Evidence）和论证（Arguments），也就是数字背后的推理，把每一个数字与它背后的信念连接起来。折现率背后的缘由。增长曲线的来源。那张说着这个催化剂支撑那个论点，而这里就是它所引用的申报文件的、把推理连成一张网的关联图。

这是一个足够大的题目，值得拥有它自己的文章。展示你的推演过程讲的就是它。

我会被锁死吗？#

不会。你随时都能把它导出成 Excel——想要公式就保留公式，不想要就只导出值。推理批注和编辑历史没法存进一张普通的电子表格，所以它们会留在原处，但模型本身能干干净净地导出来。你想走，随时可以走。

这就是文件格式和平台之间的区别。我们是有意选了文件格式。完整的论证在为什么要一种新的文件格式里。

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