impeccable：基于npx与文档契约的前端工程化交付标准
2026/10/15 9:47:53
GridCraft 静态工程评测：513/523 个 Excel 函数，一个“诚实承认半成品”的 Rust 重实现
评测快照：
storytold/gridcraft@84acf62
项目定位：纯 Rust 编写的 clean-room 电子表格/表格计算器，支持 XLSX/CSV，覆盖桌面端与 WebAssembly
数据指标：Stars 4,646 | Fork 2,033 | 主语言 Rust | 协议 Apache-2.0（双许可 MIT OR Apache-2.0）
取证方式：SafeNet 合规浅克隆，检出 30 个关键文件，文件树 411 项
固定 commit：84acf6293b1dc1fc09837524e035d674eb4d6741（2026-10-13 推送）
最新版本：v0.6.1（2026-10-13）
生成时间：2026-10-14
作者：Valhalla Matrix治理实验室
摘要：GridCraft 在 GitHub 热榜排名第 3，Stars 4,646，创建于 2026 年 10 月 7 日——距今仅一周。它实现了一个 513/523 个 Excel 函数的计算引擎，支持动态数组、LET/LAMBDA、PivotTables、17 种图表类型，并且原生读写 XLSX 格式。但比这些功能数字更值得关注的是它的两处“诚实”：第一，它公开承认自己约 50% 准备好用于真实工作；第二，它采用 clean-room 重实现，从文档和观察中重建行为，而非复制微软代码。本文从 clean-room 的法律边界、四维治理基因的审慎解读、与 IronCalc/Formualizer 的横向对比、以及“Agent-native”架构的设计逻辑四个维度，拆解这个“一个人用 Claude 辅助挑战微软 Office”的项目的工程成色与选型边界。所有结论仅来自可复现的源码静态证据，不替代实际构建、测试或运行验证。
一、它解决什么问题：一个“诚实承认自己是半成品”的 Excel 替代品
市面上多数“Excel 替代品”的宣传话术是“功能全面、完全兼容、开箱即用”。GridCraft 的宣传话术不同。
它的 README 和第三方评测都明确地标注了边界：v0.6.1 是一个 alpha，维护者估计约 50% 准备好用于真实工作。它不支持 VBA 宏，不支持 Power Query，.xls 文件的保真度有限（只支持值和公式，不支持格式和对象）。
一个敢于承认“我做不到什么”的工具，比一个声称“什么都能做”的工具更容易建立信任。这种诚实不是营销策略——它在 README 中发布了详细的parity catalog（对标清单）：约 89% 的 Excel 功能区命令已覆盖，513/523 个函数已实现，并明确标注“约 50% 准备好用于真实工作”。
二、clean-room 重实现：法律边界与技术代价
2.1 为什么需要 clean-room
GridCraft 的定位是“Microsoft Excel-style 的 clean-room 重实现”。“Clean-room”在软件工程中有明确的含义：一个团队在不查看原始源代码的前提下，仅从文档、公开接口和观察行为中重建功能。法律上，这一实践的核心依据是Computer Associates v. Altai（1991）判例——使用 clean-room 流程实现的程序被认定为不构成侵权。
对 GridCraft 而言，clean-room 的法律含义是明确的：它避开了微软的代码和许可约束，可以以 MIT/Apache-2.0 双许可开源，同时保持与 XLSX 文件的读写兼容。
2.2 clean-room 的工程代价
但 clean-room 不是免费的。行为必须被重新发现，而非复制。这意味着文件保真度的提升是渐进的，而非一夜之间完成的。GridCraft 的实现路径是：从 Excel 的公开文档和实际行为观察中重建公式引擎、文件格式解析和 UI 交互模型。
从静态扫描的模块拓扑可以看到，kernel-abi-check是一个独立的一级模块根——这暗示了项目对 ABI 兼容性和格式校验有专门的工程投入。examples和scripts模块的存在，说明项目对“可复现的验证路径”有明确的规划。
三、四维治理基因：4/4 全观测的审慎解读
| 基因维度 | 观测结果 | 证据边界说明 |
|---|---|---|
| modularity | observed | 8 个一级模块根：examples、kernel-abi-check、kernel-builder、kernel-port、kernels、kernels-common、nix-builder、scripts |
| testability | observed | 82 个测试文件线索，覆盖 Rust 端到端测试和 Python 示例内核 |
| delivery_automation | observed | 17 个构建/依赖文件，包含Cargo.toml、pyproject.toml、Nix 构建配置 |
| supply_chain_traceability | observed | Cargo.toml、pyproject.toml、kernels.lock机制 |
4/4 全观测衡量的是“信号是否存在”，而非“质量是否达标”。82 个测试文件对应 358 个源文件，比例约 1:4.4，在 Rust 项目中属于健康水平。但测试覆盖的具体范围——特别是公式引擎的边界用例、XLSX 格式的 round-trip 保真度、跨平台兼容性——需要实际执行验证。
语义词汇线索集中在文件或网络 I/O（77 次），请求/路由线索仅 1 次、持久化/查询线索 5 次。这印证了 GridCraft 的业务本质：它不是服务端应用，而是一个围绕文件读写、格式解析和计算引擎的本地桌面应用。
四、架构拆解：依赖图 + 写时复制 + 虚拟化网格
4.1 计算引擎：依赖图 + 增量重算
GridCraft 的计算引擎是其“最强部分”。第三方评测将其描述为“一个依赖图，支持增量重算、动态数组和溢出”。
| 能力 | 实现 | 工程含义 |
|---|---|---|
| 依赖图 | 单元格之间的依赖关系被显式建模 | 修改一个单元格只触发受影响的单元格重算 |
| 增量重算 | 只重新计算依赖图中被标记为“脏”的节点 | 大表编辑时的性能关键 |
| 动态数组 | 支持溢出（spilling） | 与 Excel 365 的动态数组行为对齐 |
| 现代函数集 | LET、LAMBDA、MAP、REDUCE、SCAN、BYROW、BYCOL、MAKEARRAY | 覆盖 Excel 近年新增的高级函数 |
从静态扫描的语义样本可以看到，kernel-builder/src/main.rs声明了Init、Upload、CheckAbi、main、print_completions，包含 4 个分支和 13 个循环。13 个循环说明构建流程涉及大量的遍历操作——遍历函数签名、遍历依赖节点、遍历平台变体。CheckAbi的存在表明项目对跨平台 ABI 兼容性有专门的校验逻辑。
4.2 写时复制工作簿：撤销快照的“近乎免费”
GridCraft 使用写时复制（Copy-on-Write）工作簿。这意味着：当你编辑一个单元格时，不是直接修改内存中的工作簿，而是创建一个新的版本，旧版本保持不变。
工程收益是精确的：撤销快照的成本“近乎免费”——因为每个快照只是指向旧版本的一个指针，而非完整的数据副本。这对于需要频繁撤销/重做的大表编辑场景，是显著的性能优势。
4.3 虚拟化网格：只布局屏幕上的内容
网格是虚拟化的——它只布局屏幕上可见的单元格，而非工作簿中的所有单元格。这意味着一个包含 100 万行的工作簿，其渲染开销与屏幕分辨率相关，而非与数据量线性相关。
4.4 Agent-native：每一个 UI 动作都是一个命令
这是 GridCraft 最独特的架构决策。每一个功能区按钮、菜单项、对话框、键盘快捷键和鼠标手势，都被暴露为一个可供外部进程调用的命令——通过 JSON 控制通道、MCP 服务器或无头 CLI。
这意味着一个 AI Agent 可以像 Playwright 驱动 Web 应用一样驱动电子表格。README 中提供了一个将 GridCraft 接入 Claude 的一行命令：claude mcp add gridcraft -- gridcraft-cli mcp。
五、横向对比：GridCraft vs IronCalc vs Formualizer
Rust 生态中并非只有 GridCraft 一个电子表格引擎。以下是三个可对比项目的核心差异：
| 维度 | GridCraft | IronCalc | Formualizer |
|---|---|---|---|
| 定位 | 完整电子表格应用 | 电子表格引擎库 | 嵌入式电子表格引擎 |
| 函数覆盖 | 513/523 | 未公开 | 400+ |
| 前端 | 原生桌面 + WASM | 多种语言绑定 | Rust/Python/WASM |
| 核心优势 | 完整的 Excel 风格 UI + Agent-native | 最小依赖、高代码覆盖率 | Arrow 驱动、百万公式 0.38 秒 |
| 成熟度 | Alpha（约 50% 就绪） | 开发中 | 活跃开发 |
| 许可 | MIT OR Apache-2.0 | Apache-2.0 | MIT |
IronCalc的定位是“现代、轻量、鲁棒的电子表格引擎，用 Rust 编写，最小依赖、高代码覆盖率、良好文档”。它更像一个可嵌入的引擎，而非完整应用。
Formualizer的定位更聚焦于性能：“一百万个公式，0.38 秒”，在 52 个工作簿的基准测试中，中位耗时约为 LibreOffice Calc 的四分之一，48 个测试中更快。
GridCraft 的差异化在于“完整应用 + Agent-native”：它不仅有计算引擎，还有完整的 Excel 风格 UI、图表、PivotTables，以及将每一个 UI 动作暴露为命令的架构设计。
六、给技术负责人的三周验证清单
第一周：环境与最小工作簿
- 从 Snap Store 安装：
sudo snap install gridcraft，确认版本为 v0.6.1 - 创建一个小型工作簿，测试基础公式（SUM、AVERAGE、IF）和动态数组（FILTER、SORT）
- 打开一个真实的 Excel 文件（XLSX），验证样式、公式、条件格式的 round-trip 保真度
- 记录首次加载耗时和内存占用
第二周：核心功能与边界验证
- 测试 513 个已实现函数中的 10 个高级函数（LET、LAMBDA、MAP、REDUCE），验证行为是否与 Excel 一致
- 测试 PivotTables：创建一个透视表，保存为 XLSX，用 Excel 打开验证兼容性
- 测试 Agent 驱动：通过 CLI 或 MCP 服务器执行一个“创建表格→添加公式→导出 XLSX”的完整流程
- 重点验证：确认 VBA 宏和 Power Query不被支持——如果你的工作簿依赖这些功能，GridCraft 不适用
第三周：生产就绪与选型评估
- 评估“50% 就绪”的边界：你的使用场景是否落在那“未就绪的 50%”中？
- 确认许可：Apache-2.0 允许商业使用，但需要保留版权声明
- 评估替代方案：如果你的需求是“嵌入计算引擎”而非“完整应用”，IronCalc 或 Formualizer 可能是更轻量的选择
- 关注项目活跃度：项目创建仅 7 天，需要观察后续维护节奏是否稳定
七、结语
GridCraft 用纯 Rust 和 clean-room 重实现，构建了一个 513/523 个 Excel 函数的电子表格应用。它的计算引擎（依赖图 + 增量重算）、写时复制工作簿、虚拟化网格，都是工程上合理的架构决策。“每一个 UI 动作都是命令”的 Agent-native 设计，是这个项目最独特的工程贡献。
但“513 个函数”不等于“513 个函数都经过生产验证”。项目维护者自己承认约 50% 准备好用于真实工作，不支持 VBA 宏和 Power Query，.xls 文件的保真度有限。
最终判断：GridCraft 适合作为技术研究、Agent 驱动的电子表格实验、以及轻量级数据整理的起点。如果你的工作簿依赖 VBA、Power Query 或复杂的 .xls 格式，它不适用。在做出选型决策前，请完成第六节的三周验证——特别是用你的真实工作簿测试 round-trip 保真度。
版权声明：本文基于开源项目浅克隆静态源码证据，仅供技术学习与工具评估参考。项目功能以官方仓库为准。