Recalc：当电子表格单元格变成AI终端

一个反常的 Show HN 项目

Hacker News 的 Show HN 板块每天都会冒出各种实验性工具，但 Recalc 的定位足够让人停下来看一眼：它是一个电子表格，而每个单元格里跑的不是公式，是 Claude Code 或 Codex 的终端会话。

这个项目在 HN 上发布时热度并不高，Points 仅为 4，也没有产生评论。这个数字本身说明了它处于非常早期的阶段——它更像一个概念验证，而不是成熟产品。但正是这种"把两个不相关的东西硬拼在一起"的思路，往往藏着值得拆解的产品逻辑。

Recalc 到底在做什么

传统电子表格的核心抽象是：单元格存放值或公式，公式依赖其他单元格，整个表格构成一张有向无环的依赖图，任何输入变化都会触发重算。Recalc 保留了这个外壳，但把单元格的执行单元换成了 AI 编程代理的终端。

这意味着你不再写 =SUM(A1:A10)，而是可以让某个单元格启动一个 Claude Code 或 Codex 会话，把任务丢给它，然后像等待公式结果一样等待它的输出。对熟悉命令行代理的人来说，这是一种把"对话式编程"塞进网格结构的尝试。

从命名看，"Recalc"（重算）直接借用了电子表格的术语，暗示项目的野心在于复用表格的重算语义：单元格之间可能存在依赖关系，上游代理的输出会作为下游代理的输入，形成一条链式的 AI 工作流。

有向无环图（DAG）与重算语义

传统电子表格的依赖模型本质上是一张有向无环图：每个单元格是一个节点，公式对其它单元格的引用构成有向边，而“无环”保证重算可以按拓扑顺序进行，不会陷入循环依赖。当某个输入变化时，表格引擎只需从该节点出发，沿依赖边向下游传播，重新计算受影响的子图，而非全表重算。这一机制在 Excel、Google Sheets 等产品中已高度成熟。

Recalc 声称借用“重算”语义，意味着它若要兑现承诺，就必须实现类似的依赖声明与传播机制——只不过节点执行的是耗时、非确定性、可能失败的 AI 代理会话，而非纯函数公式。AI 输出的不确定性会让“缓存失效”和“重算触发”的判定比传统表格复杂得多：同样的输入未必得到同样的输出，这使得依赖图上的增量重算需要额外的版本或快照概念。

Claude Code 与 Codex 的终端形态

Claude Code 是 Anthropic 推出的命令行编程代理，Codex 则是 OpenAI 的代码模型及其 CLI 形态。两者都以“在终端中接受自然语言任务、自主读写文件、执行命令并返回结果”为工作方式，属于交互式、多轮、有状态的会话型工具，而非一次性的 API 调用。

这一点对 Recalc 的实现至关重要：把这类终端嵌入单元格，不只是调用一个函数，而是要管理一个持续运行的伪终端（PTY）会话，包括启动、输入注入、输出流捕获、中断与销毁。相比调用无状态 API，终端会话的生命周期更长、输出是流式的、状态更难序列化，这决定了 Recalc 在并发与资源管理上面临的工程挑战远超普通公式引擎。

为什么这个组合不是纯粹的噱头

把 AI 终端放进表格，表面上是个古怪的组合，但它回应了一个真实痛点：多个 AI 代理之间的编排目前主要靠脚本、编排框架或手工复制粘贴，缺乏一个直观的可视化载体。

电子表格恰好是人类已经用了数十年、理解成本极低的"并行任务面板"。行列结构天然适合放置多个独立任务，单元格引用天然适合表达任务之间的数据流。如果 Recalc 能把依赖追踪和重算触发做扎实，它实际上提供了一种比 YAML 编排文件更亲民的代理协作界面。

另一个角度是审计性。终端会话的输出被固定在单元格里，比滚动的聊天记录更容易回溯和比对。对于需要反复迭代同一批任务的场景，表格的行列定位比对话历史更利于人工检查。

需要冷静看待的部分

必须指出，原始信息极其有限。除了标题和"单元格可以是 Claude Code 或 Codex 终端"这一句描述，没有更多关于实现方式、依赖机制、并发模型或错误处理的细节。Points 为 4、零评论的数据也不支持任何关于用户认可度的推断。

几个关键问题在现有素材中无法回答：单元格之间的依赖是如何声明的？多个终端会话是并行还是串行执行？代理执行失败时表格如何处理？重算的触发条件是手动还是自动？这些恰恰是决定 Recalc 是"有趣的 demo"还是"可用的工具"的分水岭。

从工程难度看，把交互式终端嵌入表格单元格本身就涉及 PTY 管理、会话生命周期和 UI 渲染的复杂权衡，而加入依赖图和重算逻辑会进一步放大复杂度。这个方向的技术风险不低。

PTY 与终端嵌入的工程约束

PTY（伪终端，Pseudo-Terminal）是让程序以为自己连接着真实终端的操作系统抽象，ssh、tmux、终端模拟器都依赖它。把交互式终端嵌入 UI 组件，通常需要为每个会话分配一个 PTY 主从对，由后端进程读写从端，前端通过 WebSocket 等通道转发字节流，并用 xterm.js 之类的终端模拟器渲染。

难点在于：每个会话都占用独立的进程与 PTY 资源，几十上百个单元格并行就意味着大量常驻进程；输出是 ANSI 转义序列混杂的字节流，需要正确解析；会话崩溃、挂起或等待输入时，表格需要感知并作出反应。这些约束使得“每个单元格一个代理终端”在规模化时成本陡增，也是判断该项目能否产品化的关键工程门槛。

这类实验的价值

即便 Recalc 最终没有成长为产品，它提出的问题值得关注：AI 代理的编排界面应该长什么样？当前的答案集中在聊天窗口和代码编辑器两侧，而 Recalc 提示了第三种可能——把代理当成表格里的计算单元，用数据流而非对话流来组织工作。

对于关注 AI 编程工具形态演化的开发者来说，这是一个值得放进观察列表的小项目。它的价值不在于当下有多可用，而在于它试探了一个尚未被充分探索的交互范式。

常见问题

Recalc 支持哪些 AI 代理？ 根据项目标题，目前涉及 Claude Code 和 Codex 两种终端。

它和普通电子表格有什么区别？ 普通表格的单元格存放值或公式，Recalc 的单元格可以承载 AI 代理的终端会话。

现在可以使用吗？ 项目以 Show HN 形式发布，处于早期阶段，公开信息非常有限。