10 分钟把你的 Excel 模型迁入 DeepCell

“我已有的模型能迁移过来吗？”

这是每位分析师都会问的第一个问题，也是问得对的问题。因为在大多数工具里， 诚实的答案是：基本不行。导入那些值——当然可以。但公式过来时已经支离破碎、 布局被压平、命名区域消失无踪，不出一天你就得从头重建。到那个时候，成本收益的 账早就崩了。

所以在谈 DeepCell 怎么做之前，值得先讲清楚一次认真的导入到底要做到什么。它得 读取计算后的值，而不是过时的缓存。它得尝试还原公式，而不只是数字。它得 保留一条回溯到来源的链接，让你能审计每个单元格的出处。而且它得对自己没能 转换的部分诚实以告，而不是写个零就当无事发生。

最后那一点最难。大多数导入工具都是悄无声息地失败。

两条路径，取决于你对自己的模型有多熟#

进入 DeepCell 有两条路。它们最终生成的是同一种 .deepcell 文件。区别在于谁来做布局这件事——是你，还是智能体。

路径 1 —— 确定性导入#

当你了解自己的工作簿时用这一条。这模型是你写的，或者你盯着它看得够久，闭着眼 都能背出行号。你告诉 CLI 每个行项目究竟在哪、哪些列对应哪些期间，剩下的它来办。

deepcell import dcf_model.xlsx \
  --items '[
    {"id":"Revenue","name":"Revenue","level":0,"row":5,"sheet":"P&L"},
    {"id":"COGS","name":"COGS","level":0,"row":6,"sheet":"P&L"},
    {"id":"Gross_Margin","name":"Gross Margin","level":0,"row":7,"sheet":"P&L"}
  ]' \
  --contexts '[
    {"id":"FY2024A","name":"FY2024A","period_type":"annual","column":"B","status":"actual"},
    {"id":"FY2025E","name":"FY2025E","period_type":"annual","column":"C","status":"projected"}
  ]' \
  --name acme_dcf

这条命令依次做的事：打开 xlsx，从每个 (row, column) 交叉点读取计算后的值 ——不是 Excel 存在磁盘上的缓存 blob，而是实时结果——提取底层公式，在能转换的 地方把它们转为 Jingwei 语法，并为每个单元格写入一份 DataSourceDefinition， 这样半年后你仍能把 Revenue × FY2024A 追溯回 P&L!B5。

行项目可以指向不同的工作表（一个用 "sheet":"Drivers"， 另一个用 "sheet":"P&L"）——多标签页工作簿是常态， 而非例外。加上 --aggregations 来声明汇总（SUM、 AVERAGE、MIN、MAX、COUNT），引擎就会从子项重新计算父项， 而不是把它们当作扁平的值导入。

这不是自动检测。CLI 不会去猜你的模型从哪里开始。 你把坐标给它，它给你一份忠实的转换。

路径 2 —— 智能体辅助导入#

当你昨天刚打开这个工作簿、却已经一头雾水时用这一条。同事的模型、一个收购标的、 一份再没人认领的遗留 DCF。你不想手动逐行映射。你想让结构被推断出来。

这就是 excel-extractor 子智能体——DeepCell 编排器会委派的五位专家之一。你不 直接调用它。你把文件交给 Claude，然后描述你想要什么：

You: Here's our latest DCF. Pull it into DeepCell and tell me what
     assumptions you found.

Claude: [uses excel-extractor]
        Imported P&L tab (rows 4-23 as items, columns B-K as periods
        FY2020A–FY2029E). Drivers tab linked as upstream. 4 formulas
        required review:
          - Gross_Margin (P&L!B7) — circular ref through Drivers!C18,
            stored with warning
          - WACC (Drivers!B12) — INDIRECT() conversion incomplete
          - Terminal_Value (DCF!F28) — references external workbook,
            value imported, formula dropped
          - Tax_Rate (Drivers!B19) — converted as IF chain, please verify
        Everything else converted cleanly. Want me to walk through the
        four flagged cells?

智能体路径更慢。但它也更能容忍杂乱的工作簿——那些段落之间夹着三行空行、有一个 没人更新的“Summary”标签页、用颜色编码来代替状态的工作簿。编排器和提取器来回 对话，直到结构说得通，然后调用与确定性路径相同的那个底层导入端点。关于这种 分工，更多内容见 分析师与 Claude，在同一个模型上协作。

关于公式转换——说句实话#

大多数 Excel 公式都能干净地转换过来。SUM、AVERAGE、IF、SUMIF、 NPV、IRR、MIN、MAX、ROUND、COUNT、LOOKUP——这些都有 直接的 Jingwei 对应项，往返转换毫无波折。

有些则不行。INDIRECT 是惯犯——它在运行时拼出一个引用 字符串，而这是静态依赖图无法跟踪的。深度 嵌套的数组公式、跨工作表的三维引用、 外部工作簿链接（[other_model.xlsx]Sheet1!B5）——所有这些 要么优雅降级（保留值、标记公式），要么 高调失败，并在单元格上附一条警告。

单元格仍然会被导入。它只是带着一个标记导入，写着这一个 需要人来处理。你会在检查器里看到这些标记，然后决定怎么做。 一条明确的警告，胜过一个悄无声息的错算——后者会在六个 依赖单元格上层层叠加。

还有几件该先知道的事：命名区域不会带过来 ——你给的是行/列坐标，而不是名称。合并单元格只 读取左上角（一个我们继承自 openpyxl 的怪癖）。外部工作簿 链接不会被拉入；如果你的模型依赖于另一个单独的文件，你就 单独导入那一个。单个 xlsx 的体积上限是 10 MB。

转换完成后，你得到什么#

导入一完成就会提交到 git。这件事的分量比听起来更重。当你的同事下周更新同一个 xlsx 并发给你时，在新版本上重新运行 deepcell import 会产生一份语义化的差异 ——不是 blob 层面的“这个文件变了”，而是 “COGS 在 FY2026E 新增，Gross_Margin 公式从 Revenue - COGS 改为 Revenue - COGS - Other_Cost，实际列里有 14 个值被更新”。运行 deepcell diff，你看到的正是这些。

当文件格式就是唯一可信源时，给一个模型做版本管理，就是这个样子。

共存，而非取代#

这次导入是非破坏性的。你的 dcf_model.xlsx 在磁盘上原封不动。那份 .deepcell 文件与它并存、引用它，还可以通过 deepcell to-excel 重新 导出回 xlsx，给你团队里仍然偏爱网格的人用（更多内容见 与 Excel 的往返转换）。

如果迁移没成——如果你判定 DeepCell 并不是这个特定模型该有的归宿——你也 只是花了运行一条 CLI 命令的成本，而你的原始工作簿依然还在。

就是这么个交易。拿一个模型试试。最坏的情况，你也学到了你的模型被拆开、 检视之后是什么样子。最好的情况，你刚刚第一次把它好好地做了版本管理。

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