一个 GitHub 项目最近把话说得很直：整个代码库，包括 Rust parsers、TypeScript renderers、tests、tooling，都是 Claude 通过迭代提示写出来的。仓库声明没有人工编写的应用代码。
项目叫 office-open-xml-viewer，也以 @silurus/ooxml 包的形式发布。它不是新的 Office，也不是 Google Docs 替代品。它做的事更窄：在浏览器里查看 Office Open XML 文档，支持 DOCX、XLSX、PPTX，把结果画到 HTML Canvas 上。
这事最值得看的一点，不是“AI 又写代码了”。而是 AI 已经能把一个复杂但边界清楚的工程项目，推进到可发布形态。
Office 查看器听起来像小工具，实际很脏。ZIP、XML、样式继承、字体度量、分页、换行、表格、图表、公式，任何一项都能把 demo 拖进泥里。
它是什么：浏览器里的 Office 查看器，不是编辑器
把信息压成一张表，更清楚。
| 维度 | Silurus ooxml 目前做法 |
|---|---|
| 项目定位 | 浏览器端 Office Open XML viewer，不是完整编辑器 |
| 支持格式 | DOCX、XLSX、PPTX |
| 解析路线 | Rust parser 编译成 WebAssembly |
| 线程分工 | Web Worker 负责解析，主线程负责渲染 |
| 渲染方式 | Canvas 2D |
| 产品形态 | npm 包、Storybook demo、VS Code 扩展入口 |
| 开发者接口 | 提供 headless engine，可自定义 UI |
| 代码声明 | Rust parsers、TypeScript renderers、tests、tooling 均由 Claude 实现 |
架构不玄。每种 Office 格式都有 Rust 解析器，编译成 .wasm。浏览器运行时，Worker 把文件解析成 JSON 模型。主线程拿模型，用 Canvas 2D 画出来。
主线程渲染不是随手选的。README 给了一个很具体的解释：Canvas 要共享页面的 FontFaceSet。如果渲染放进 Worker 的 OffscreenCanvas，字体注册表可能不同，浏览器会悄悄 fallback 到系统字体。
字体一换，字宽就变。字宽一变，换行、分页、表格高度都会漂。
这才是 Office 查看器的真难点。不是能不能画出第一页，而是用户打开自己的文件时，标题有没有掉行，表格有没有错位，公式有没有变形。
它还有一些很实际的限制。
| 现实约束 | 对开发者意味着什么 |
|---|---|
| ESM-only | 老项目接入会受构建链限制 |
| 内嵌 WASM | Vite 需要 vite-plugin-wasm，webpack 要开 experiments.asyncWebAssembly |
| 数学公式 opt-in | DOCX/PPTX 的 OMML 公式走 MathJax + STIX Two Math，约 3MB，不默认进包 |
| Canvas 渲染 | 更接近文档查看器路线，不等于可编辑协同文档 |
这些不性感，但有价值。一个项目愿意把打包、字体、公式引擎这些代价摆出来，比只放几张漂亮截图更可信。
对前端工程工具开发者来说，它最直接的意义不是“赶紧替换 Office”。而是多了一个可以评估的组件：内部文档预览、附件查看、VS Code 扩展、知识库文件浏览，都可能拿它做原型。
但如果场景是合同归档、财务报表、投标文件预览，别急着上生产。那类场景对版式错误的容忍度很低。一个换行错位，就可能不是 UI bug，而是业务风险。
反常点：Claude 写到了基础设施层
过去两年，AI 写代码一直被两边拉扯。
一边说它只能补全函数。另一边说程序员快没了。这个项目夹在中间，反而更接近现实。
它至少说明一件事：在有人类持续提示、拆任务、验收结果、推动发布的前提下，Claude 这类模型已经不只是在写脚本。它可以生成多语言、多包结构、带 WASM、Worker、Canvas、测试和工具链的工程项目。
这不是玩具级复杂度。
但也别把 README 当第三方质检报告。仓库的自述只能说明项目的目标、实现路线和作者声明。它不能证明 Silurus ooxml 已经达到 Microsoft Office、Google Docs 或成熟商业 viewer 的兼容水平。
更不能推导出“真实企业文档都能无痛打开”。这一步没有证据，就不能替它吹。
Office Open XML 的麻烦，有点像早期铁路标准。不完全一样，但那种历史债很像：轨距看着统一，桥梁、弯道、调度、车厢接口却全是旧账。
Office 也是。标准文件写在那里，现实文档里却有二十年软件行为的残影。老版本的默认样式、字体替代、图表实现、分页习惯，都可能变成兼容坑。
“积重难返”在这里不是修辞，是工程日常。
所以我更在意的不是 Claude 生成了多少行代码，而是它把 AI 编程的有效边界往外推了一格。
以前 AI 最稳的地方，是边界窄、反馈快的活：组件、脚本、单测、胶水层。现在它开始碰解析器、渲染器、跨格式共享模块、框架示例、打包说明。
边界还是清楚的。但面积变大了。
这会改变很多团队的动作。工具团队以后做内部 viewer、转换器、协议适配层，可能会先让 AI 打出一版，再由人补测试、压兼容、收边界。采购商业组件的节奏也可能被拉慢：先验证开源 AI 生成方案能不能覆盖 70% 场景，再决定要不要买。
这不是省钱神话。更像把第一公里变便宜了。
真正的分水岭：维护、兼容、责任
这类项目接下来要过三道关：维护、兼容、责任。
维护最朴素，也最难躲。代码今天能跑，不代表下个月还能跑。浏览器策略变了，WASM 打包破了，依赖升级冲突了，谁来修？
代码可以由 Claude 写。债主不会找 Claude。
兼容更硬。DOCX 的分页，XLSX 的虚拟滚动，PPTX 的形状和图表，任何一个都能拖出长尾问题。Office viewer 的用户也不会关心 Rust、WASM、Canvas 这些路线。
用户只会问一句：为什么我的文件打开不对？
责任归属更微妙。仓库声明“没有人工编写应用代码”，这是一个醒目的生产方式标签。但项目决策、提示设计、验收标准、发布动作，仍然可能有人类参与。
AI 不是凭空开源。它是在人的目标函数里干活。
对开发者而言，接下来最该看的不是 star，也不是截图，而是这些具体变量：
| 观察点 | 为什么重要 |
|---|---|
| 真实文档兼容样本 | 决定它能不能从 demo 走向业务场景 |
| 回归测试覆盖 | Office viewer 最怕修一个格式、坏三个格式 |
| 字体与分页稳定性 | 直接影响 DOCX/PPTX 是否可信 |
| XLSX 大文件表现 | 决定表格预览是否能用于内部系统 |
| issue 响应与维护节奏 | AI 生成之后，仍要有人长期还债 |
| API 是否稳定 | 决定开发者敢不敢接入 headless engine |
这里的分水岭很清楚：AI 已经能降低“从零到可发布”的成本，但还没有消灭“从可发布到可信赖”的成本。
这对前端团队和工程工具团队尤其现实。以后很多内部工具会更快出现：文档预览、管理台、转换器、插件、协议桥。问题不再只是“AI 能不能写”。
问题变成：你能不能定义边界，设计测试，识别坏味道，并准备接住后续维护。
刀更快了。手不能更懒。
回到开头那个声明：Claude 写了整个应用代码库。它确实够吸睛，也确实代表一种新变化。
但真正该记住的不是“无人写代码”这句标签，而是后面的账本：复杂但边界明确的软件，正在更容易被 AI 生产；复杂且长期演化的软件，仍要人类负责收拾残局。
模型看着更强，产品反而更需要工程判断。发布只是开始，兼容性才是秋后算账。