★ FEATURED ARTICLE 大概很多人跟我一样在技术社区刷到那个标题时先觉得有点离谱有人要用 Rust 从头重写 Word还声明采用“纯净室”方法路线图上的每个任务居然不是按人天、不是按周迭代而是按“Claude 工时”记账。离谱归离谱这个组合拳其实信息量很大——它同时踩中了兼容工程的护城河、Rust 生态的硬实力以及“AI 充当主力编码劳动力”的项目怎么管钱、管进度这三个话题。这篇文章我想以一个常年跟办公文档、格式转换和编辑器打交道的工程师视角把这个项目里里外外拆一遍哪些是合理的哪些是罗曼蒂克以及如果你想复刻这种模式最该先准备什么。先说结论用 Rust 纯净室重写 Word在技术上是“能启动、极难完成”的巨型工程但把路线图按 Claude 工时记账这件事反而可能是整个项目最有价值的部分。它把软件工程里最玄学的“还要做多久”变成了一个可计量、可回溯、可回归的数字。这篇文章会按“项目本质 → 功能拆解 → AI 协作模式 → 风险边界 → 可复制的经验”这个顺序展开尽量不聊虚的。1. 这个项目到底在做什么纯净室、Rust 与 Word 三者为何凑到一起1.1 “纯净室”不是装清高而是一套风险控制方案很多读者第一次看到“纯净室”Cleanroom会以为它只是个“从零手写”的漂亮说法其实它在软件工程里有严格的含义实现者不接触原产品的源代码只依据公开的规范文档以及通过黑盒观察到的外部行为独立写出一个功能兼容的实现。这个方法论最早来自硬件逆向后来被软件界拿去应对版权和商业秘密风险。具体到这个项目里纯净室意味着几件事Word 背后的官方规范文档比如 Open XML 格式的公开规范是可以作为合法输入的Word 导出的 docx 文件、用户能看见的各种行为是可以作为黑盒测试输入的但 Word 的二进制、反编译结果、内部算法细节一概不能看。这不是洁癖而是为了保护项目未来能合法分发。历史上那些成功的兼容实现或多或少都走过类似路线只不过今天这位作者把它公开写在了路线图里。但纯净室在 AI 时代多了一层新的麻烦你没法保证 AI 没看过不该看的东西。大模型的训练语料里很可能包含了各种第三方解析库的源代码甚至可能包含 GPL/LGPL 协议的代码。如果 Claude 照着记忆里的某个开源实现“顺手”生成了一段几乎一样的代码你的纯净室就破了。所以真正严肃的纯净室 AI 项目必须在发布流里加一道许可证扫描和记忆审查人得负责问“这段代码你从哪学的”——这一点后面展开讲。1.2 Rust 的选择不是情怀是几条硬理由用 Rust 重写字处理器很多人第一反应是“又是 Rust 重构一切”。但如果把这个选择拆开看它其实相当理性内存安全是刚需。文档解析器面对的是用户发来的、不可信的 docx 文件。历史上 C/C 写的文档处理组件爆出过大量缓冲区溢出、释放后使用漏洞。Rust 的所有权系统在编译期就把整类漏洞按死了这对一个要打开陌生人文档的工具来说不是加分项是保命项。排版和编辑是状态密集的活。文档对象树、命令模式下的撤销栈、选择模型、视图同步这些模块在 C 里最容易出悬垂引用和数据竞争Rust 的借用检查让人把肉眼 review 的精力省下来用在这些模块的逻辑而非内存错误上。性能没有 GC 停顿。表格重排、大文档滚动、字形 shaping 都是 CPU 密集型Rust 没有垃圾回收性能曲线稳定这对排版引擎很重要。生态可复用。zlib/zip 解包、XML 解析、字形 shaping 这些底层组件Rust 生态里都有成熟实现AI 也不容易在这些地基上犯错。代价是Rust 的编译期约束会让某些快速原型写起来比 C/Python 慢。但既然主力编码是 Claude这个开发速度劣势就被大幅摊薄了——你付给 AI 的 token 钱和付给人力的加班费不是一个量级。1.3 为什么偏偏选 Word 而不是别的选 Word 不是因为它简单恰恰因为它是最复杂的民用软件之一挑战足够大社区关注度足够高。更深层的原因在于兼容 Word 的真实需求在全世界依然海量存在——政企文档交换、论文模板、历史档案整个社会的信息流转被半个世纪积累下来的“Word 生态共识”绑得死死的。一个能打开、编辑、保存现代办公室文档且不破坏格式的跨平台工具价值是实打实的。目标越大越值得用“新的生产工具”去试一次。2. 路线图的第一性拆解Word 的核心功能域与“Claude 工时”的含义2.1 先给 Word 画一张功能地图说“重写 Word”之前得先回答一个问题Word 的哪个子集完整 Word 有几千个功能开关没人能一口气重写。理性的做法是先给功能域分层再按“坏一个格式就丢一个用户”的优先级排序。我按自己的经验画了一张功能地图功能域代表性子模块复杂度评级文档模型段落、Run、节、样式、编号、主题S 级是一切的地基持久化格式docx 读、写、round-trip 保真H 级兼容性大头排版引擎断行、分页、表格算法、浮动对象、字形 shapingS 级最被低估编辑交互光标、选择、多级撤销、剪贴板、IMEH 级碎且难测用户界面文档画布、对话框、工具栏、快捷键H 级工程量巨大导出管线PDF、RTF、旧 .doc、HTMLL 级起步兼容成本高批注与修订批注、修订跟踪、审阅视图M 级数据结构繁琐宏与自动化VBA、OLE、COM 自动化建议第一阶段直接砍掉这张表的意思是路线图的第一刀应该切在“文档模型 docx 读 基本渲染”这一条纵向切片上而不是横着把某一层做完再搞下一层。做兼容软件最怕的就是“样式和主题引擎做了三个月结果连一个带表格的 docx 还打不开”。纵向切片能让项目从第 4 周开始就有可演示、可验收的产出。2.2 Claude 工时到底怎么折算为什么它能当计量单位传统项目用“人天”估工时本质上是在赌一个工程师每天的有效产出。这个估算在 AI 介入后变得不适用了——AI 写代码的“体力活”速度是人类的几十倍但人类的验收、拆任务、喂样本的时间反而成了瓶颈。于是这个项目提出了一个新单位Claude 工时。我的理解是1 个 Claude 工时 ≈ 与 Claude 持续协作 1 小时内完成的“可验收实现任务量”人类在这段时间里只做任务拆解和结果验收。单位内部的计价可以拆成三块模型侧成本一次会话的输入输出 token 数 × API 单价。复杂重构任务上下文长单位成本高。人的侧成本写需求卡、跑测试、修边界 case 的时间。这部分通常被严重低估。验证成本CI 跑一遍冒烟测试、渲染对比、round-trip 对比的机器时间。用 AI 工时记账最妙的一点是可审计性。人天是拍脑袋AI 工时可以通过会话日志、token 消耗、提交记录自动生成。项目每周结束时能精确地说出“这周花了 12 个 Claude 工时产出 3 个可运行模块修复 41 个兼容差异”这对长期维护的项目价值巨大。2.3 一份合理的示例路线图长什么样虽然我没法看到原始项目内部的具体排期但按同类兼容工程的经验合理的路线图大概可以排成下面这样每一行都是一条可独立验收的纵向切片Phase 0脚手架 docx 解包 文档树加载任意合法 docx 不崩溃、能显示纯文本内容。预估 15 Claude 工时。Phase 1段落与字体的基础渲染 滚动 缩放能打开“纯文本型”文档。预估 20。Phase 2编辑命令与多级撤销、剪贴板纯文本粘贴。预估 25。Phase 3样式、主题、页边距与页面设置能打开“带排版”的日常文档。预估 30。Phase 4表格、图片、浮动对象。预估 40这里最容易拖。Phase 5页眉页脚、分节、页码、目录域。预估 35。Phase 6批注、修订导出兼容PDF 导出。预估 30。Phase 7永久任务兼容矩阵扩充 模糊测试 回归基线库。用 Claude 工时标完路线图之后项目会暴露一个残酷事实真正“完成”的标准不是列表跑完而是“完成后还能维持”。兼容软件是逆水行舟Word 新版本随时会导出你从没见过的写法。所以路线图最后那一行必须是“常年运行”而不是某一天画句号。3. 三座大山兼容、排版、编辑交互的实际复杂度3.1 兼容层docx 不是“一种格式”而是一套行为协议很多新手以为 docx 是 ZIP XML解析就好。实际上 Open XML 规范足有数千页且充满了“可以这样写也可以那样写”的灰色地带。更糟的是同一个语义在 Word 自己的输出里都存在好几种等价写法有的用样式继承有的直接在 run 上拍平编号可能来自 numbering.xml也可能直接写在段落属性里。兼容实现的目标不是“解析成功”而是round-trip 保真——你用你的实现打开一个 docx不做任何修改直接保存结果文档在你的实现里重新打开必须和原始文档视觉一致、语义一致、最好字节级一致。这是整个项目最硬的一块骨头。我见过太多团队在“能打开”的成就感里待了三个月然后被“重新保存后同事用 Word 打开出现格式错乱”的现实击穿。对策只有两条一是建立庞大的真实样本库二是把 round-trip 测试做成 CI 里永远最先跑的那一项。AI 在这些转换逻辑上很擅长但它天生不擅长定义“等价”——人类必须把“等价判定”写成快照对比工具否则 AI 会说谎说“看起来一样”。3.2 排版引擎最容易低估的部分没有之一排版引擎听起来像“把文本画出来”做起来却是一整套计算几何问题中西文混合断行时的禁则处理、标点挤压、行距计算分页时的孤行寡行控制、表格跨页、脚注往下一页流动表格自动布局有自己的算法比浏览器的 table 布局严格得多浮动对象要和正文绕排还要处理锚定关系更别说字体 fallback、竖排、Ruby 注音这些东亚排版需求。如果项目组没有专门研究过排版算法这块的工期至少要在直觉预估上乘 3 倍。我的实操建议是第一阶段不要自己做完整排版引擎先用成熟的字形 shaping 和断行库把 90% 的日常文档搞定把“怪文档”集中到第二阶段再处理。不要一开始就追求 Word 的字节级视觉还原——那个目标的复杂度等同于重写一个现代浏览器内核。3.3 编辑交互从 caret 到 IME 的碎碎硬细节编辑器的复杂度不在“能打字”而在“打字时所有周边系统都保持正确”光标闪烁与选区绘制的时机IM 输入法组合态下候选窗口里的文字不能进文档树但拼音串的样式和位置又必须显示正确撤销栈要记录的是“文档状态增量”而不是整棵树的快照剪贴板要处理 HTML、RTF、纯文本三种格式之间的降级与升级双击选词、三击选段、拖拽选择、Shift方向键扩展选区……每一项都是老编辑器的肌肉记忆却每一项都要在 Rust 里重新实现一遍。我特别想提醒的是 IME 这块。AI 生成的编辑器代码通常会把焦点、文档内容、组合态全搅在一起短时间能跑但中文输入一抖就露馅。这块必须由人类亲自定义状态机把它和文档模型彻底分离否则后期每加一个功能都要回修一次输入法问题。4. AI 协作下的开发节奏把 Claude 当成主力程序员的工程模式4.1 分工翻转人类写需求卡AI 写实现测试当裁判当 Claude 工时成为路线图的计量单位开发模式必然从“人写代码、AI 补全”翻转为“人定规格、AI 写实现、测试验收”。每个任务都变成一张需求卡卡上写清楚五件事输入是什么、输出是什么、边界条件有哪些、必须通过的测试有哪些、禁止触碰的模块有哪些。然后 Claude 负责生成实现和测试人类负责跑测试和看提交。这个模式我在自己的小项目里实测过纯样板代码、格式转换逻辑、状态推导AI 干得又快又干净但一旦任务描述里出现“稍微复杂一点”这种模糊词AI 就会用最自信的语气写出最危险的错误代码。所以需求卡必须把“稍微复杂”翻译成“如果段落跨页表格的第一行要重复表头”这种可验证的句子测试才能兜住。4.2 防止“AI 糊墙”效应碎片化提交与定期重构让 AI 连续写两周代码之后项目会得一种病每个文件都能编译模块之间的数据模型却彼此对不上——有的函数返回字符串有的返回结构体有的直接改全局状态。这就是“AI 糊墙效应”它擅长快速补窟窿不擅长维持长期一致性。对策是从第一天就立规矩每次提交不超过一个原子任务方便回滚和 code review。接口定义和数据结构文档先由人写死AI 只允许填充实现不允许改接口。每攒 50 个 Claude 工时就安排一次“重构冲刺”专门清理不一致、删死代码、统一错误处理。别把重构当成“额外成本”从路线图里去掉。对 AI 驱动的项目重构不是债而是必然的维护循环否则到第 300 个 Claude 工时你会发现自己手里是一栋没法加固的纸牌屋。4.3 质量基建不建立Claude 工时全是虚数一个没有自动化测试、快照对比和模糊测试的 AI 协作项目是无法用 AI 工时记账的——因为账目失去了“验收”这一列。这里必须上三样东西Golden Master黄金样板收集几十份覆盖不同功能的真实 docx每次改动后自动渲染成图片或转成语义树跑一次 diff。这是兼容回归的第一道防线。属性测试对于 round-trip 逻辑让 AI 生成大量随机的、合法的 docx 变体断言“打开-保存-打开”的语义守恒。AI 很擅长写这种生成器收益极高。模糊测试随机损坏文件不能让解析器 panic。Rust 的强类型已经兜掉一半另一半靠模糊测试和错误恢复路径。我自己一贯的做法是把 20% 的 Claude 工时固定拨给质量基建。这不是浪费是唯一能让“进度数字”有意义的投资。没有这套东西所谓“X 个 Claude 工时完成 Y 功能”只是听起来精确实际上不可验证。5. 可行性与工程风险哪些坑真的会拦住这个项目5.1 边界失控从“重写 Word”滑向“永无止境的泥潭”这类项目的头号死因不是技术不够而是功能边界失控。Word 里有几千年历史一样多的边角功能——文本框连线、交叉引用、域代码、宏按钮、邮件合并、轮廓视图、保护文档模式……如果路线图把这些全算进去Claude 工时就会像黑洞一样增长。理性的北极星指标只有一句话“用户用日常方式写出来的办公室文档打开、编辑、保存后不毁坏。”宏、VBA、OLE 嵌入这些高难度低频功能第一阶段必须理直气壮地砍掉。把“完成”重新定义为“通过自家兼容矩阵”也很关键。你不需要和 Word 等价你需要和“你承诺支持的那部分文档集合”等价。把这个定义写进 README 第一段能救团队的命。5.2 钱和时间账Claude 工时不等于免费Claude 工时的诱惑在于它廉价但算总账时不能只算 token 钱。一个 800 Claude 工时的项目需要加的料包括API 调用费数额取决于上下文长度、人类审代码和写需求卡的时间这部分通常占人工时 50% 以上、CI 跑测试的机器费、以及最贵的部分——返工。AI 写出来的“看起来对但实际错的”代码如果测试没拦住混进主分支后查错的成本远远高于它最初节省的时间。所以如果你真的在策划类似项目预算表里至少要有四行模型 token、人工验收、CI/基础设施、兼容样本库建设。前两项是动态的后两项几乎是固定成本别省。5.3 干净室之外的法律与许可证风险纯净室解决了“不看源码”的问题但没解决所有合规问题不能用“官方 Word 兼容”这种可能造成误导的说法来做宣传不能使用对方产品的图标和商标更关键的是AI 记忆泄漏。如果 Claude 在生成代码时借鉴了某个开源库的实现而那个库是 GPL 协议的你的“从零实现”就可能在发布时背上传染性许可证义务。务实的做法是三条CI 里跑许可证扫描对每个文件的来源做人工抽检在项目文档里维护一份“纯净室证明”——谁在什么时间看过什么资料AI 被限定使用哪些信息源一旦发现可疑的“高度相似的代码片段”立即重写而不是侥幸放行。这些都属于工程内容不该被当成法律部门的事。5.4 依赖风险AI 进度曲线的“断崖”用 AI 工时记账还有个潜在陷阱进度不是线性增长的。前 100 个工时可能势如破竹因为都在做“框架 常见格式”的任务到了第 300 个工时你会开始撞上“word 生成的畸形 XML”“字体厂商特有的 cmap 表”“表格嵌套到六层的布局爆炸”这类 AI 训练语料里也很少见的问题。届时单任务的 Claude 工时可能从 1 涨到 10而且 AI 会给出越来越多的“看似合理、实则需要回退”的补丁。正确的心理预期是把路线图的前 60% 当作甜蜜期后 40% 当作磨盘期。把磨盘期的任务拆得更小、验收写得更严比盼着 AI 突然变聪明靠谱得多。6. 如果你想开一个类似的“纯净室 AI 工时”项目我会这么建议6.1 先选一个老但小的目标不要一上来就重写 Word那种复杂度适合拿来当长期理想不适合当第一个项目。我更推荐先做一个“窄而深”的纵向切片比如“把 Markdown 转成带基本样式的 docx 并保真回读”或者“一个能打开、编辑、保存写字板级别文档的最小编辑器”。跑通一条完整的兼容闭环之后你对 docx 的地形、对 AI 协作的边界、对工时记账的误差都会有一次真切的认识。有了这个认识再放大目标也不迟。6.2 把工时记账从“口号”变成“基础设施”既然引入了 Claude 工时就不要只在路线图里写要在工具链里实现每次和 Claude 的会话自动记录 token 消耗和时长每个完成的 issue 关联对应的会话日志每周自动生成“AI 工时 vs 人工验收工时”的对比表。你会发现这个账本会说话——它会在第三周就告诉你哪些任务 AI 是“真节省”哪些任务是“你以为省了其实人修 bug 的时间比手写还长”。6.3 人的角色会变成“验收官 架构师 样本投喂员”别幻想一个开发者 Claude 就能低成本搞定整个项目。健康的配置是一个人负责架构和数据模型设计一个人负责测试基线和兼容样本库一个人负责把需求翻译成机器可验收的“需求卡”。三个人都不直接写实现代码但每个人都必须能读懂实现代码。这种能力模型很反直觉但我越来越确信未来这类“AI 忙前忙后人类负责定义‘什么是对的’”的团队结构会变成常态。6.4 最后分享一个实操中特别有用的小技巧在所有让 Claude 干活的需求卡里我后来发现**“生成反例测试集”的性价比远高于“生成功能代码”**。与其让 Claude 写一个“解析表格的模块”不如先让它生成 100 个“符合规范但与常见写法不一样的表格 XML 样本”再拿这批样本去测试你的解析器。AI 在制造“刁钻输入”这件事上有天然优势而这类输入恰恰是兼容工程里最珍贵的资产。喂给它一份真实损坏的文档让它分析哪里坏了、应该怎么容错比直接让它写 bug 修补代码更能提升整个项目的稳健度。再补充一条个人体会按 Claude 工时记账这件事短期看是一种项目管理噱头长期看其实是把软件工程从“人的手艺”推向“可审计的工程过程”的一次尝试。它逼着你把每个功能都拆到能写验收标准的颗粒度逼着你把测试基建放在功能之前逼着你承认 AI 的产出一律要过人类的“等价判定”。走过这一遭你得到的也许不是一个能和 Word 掰手腕的产物但你会得到一个极其宝贵的、AI 时代的工程方法论。这个方法论能让你以后手里任何复杂项目都从“感觉快要完成了”变成“我知道还剩多少 Claude 工时也知道什么时候才算完”。
阅读完成 · 觉得有帮助？
