一个人+Claude干碎微软Office?全网沸腾后,工程师扒开源码:全是空壳!

几天前，全球开源社区迎来了一场意料之外的震动。

就在大家还在争论“AI到底能不能取代程序员”的时候，GitHub上突然杀出一位狠人。

前脚，他刚刚用系统级语言Rust，把Photoshop、Premiere、Illustrator等Adobe全家桶一口气克隆了个遍；后脚，仅仅隔了不到48小时，他又把枪口对准了微软的命根子，Office三件套！

Word被重写成了WordCraft，Excel变成了GridCraft，PowerPoint变成了DeckCraft。

▲ 科技媒体It's FOSS爆料：那位用AI克隆Adobe的开发者，正式向微软Office宣战

翻开这批项目的代码提交记录，全世界的程序员都倒吸了一口凉气：每一行核心代码的提交签名上，赫然写着Co-authored-by: Claude Opus 5.5。

一个人，一台电脑，外加一个顶尖大模型。

两天之内，全平台安装包直接推送到官网上。Windows、Mac、Linux，甚至连浏览器网页版都能直接点开运行。

社交网络瞬间彻底失控有人高呼“微软年年收租的Office 365终于要完蛋了”，有人直呼“一人抵得上一万个微软工程师”。

然而，当兴奋的开发者们实际下载软件、扒开代码的那一刻，这场看似神迹的技术狂欢，却在几小时内演变成了一场全网大翻车。

012天干出三件套？看起来像真的，用起来像假的

事情的起点，是一家名为ArtCraft的独立开发团队（在GitHub上的组织名为storytold）。

核心开发者叫Brandon Thomas，整个团队据说“可能只有他一个人”。

▲ 中文开发者圈迅速转发：WordCraft、GridCraft、DeckCraft全面对标微软三件套

这位老哥的打法极其凶狠：纯Rust编写、绝不使用臃肿的Electron、纯洁净室重写（Clean-room Reimplementation）。

普通读者可能对这几个词没概念简单打个比方：

很多跨平台软件为了省事，本质上是把一个完整的谷歌浏览器套在里面跑，容易卡顿且占用内存；而纯Rust编写的应用直接贴合系统底层运行，启动只需几毫秒，响应极其迅捷。

所谓的“洁净室”，更是法律上的奇策：我不看你微软一行源代码，全靠看你公开的文档规范，自己从零写一套一模一样的逻辑。不侵权，不花钱，主打一个纯粹的开源替代。

第一眼看过去，WordCraft确实惊艳到了极点。

熟悉的深色功能区、顶部的排版菜单、左侧的目录导航、中间的文档画布……只要你用过Word，闭着眼睛都能上手。

国内有技术博主第一时间下载了安装包，把一份日常中文周报放进去测试，软件秒级打开，并顺利导出了带超链接的PDF。同时它集成了MCP（模型上下文协议），AI可以直接在后台发送指令操控软件、修改文档。

可当大家试图用它干点正事时，诡异的事情接二连三地发生了。

有人发现，文档里的中文字体忽粗忽细，像得了重感冒；有人顺手插入了一个表格，整个排版瞬间飞到了九霄云外；而当你想要插入公式、SmartArt或者统计图表时，软件直接冷冰冰地告诉你：这功能压根没做。

然而，翻看仓库底部的路线图（Roadmap），作者自己写明了现状：

官方说明显示，功能区命令看着覆盖了87%，但如果算上深度和保真度，实际完成度只有62%。

至于“真实世界DOCX文档兼容性压力测试”，进度条上明确写着：未开始（Not started）。

02“前90%只占10%时间”：老程序员为什么集体愤怒？

消息传开，欧美技术社区的舆论风向一夜之间彻底逆转。

在Hacker News和社交平台上，无数资深工程师不仅没有献上膝盖，反而掀起了一场毫不留情的口诛笔伐。

一位老牌游戏开发者直言不讳地嘲讽道：

“Photoshop克隆版缺了一大堆核心算法，After Effects克隆版几乎只是个空壳，现在又掉头去碰Office？所谓奇迹不过是一场壮观的半成品尾流！”

▲ 评论区尖锐质疑：旧项目的坑还没填完，又跑去新领域画大饼

更有老程序员搬出了软件工程界最著名的铁律，贝尔实验室计算机科学家Tom Cargill提出的“90-90定律”：

“前90%的代码，消耗了前90%的开发时间；而剩下的10%代码，还要消耗另外90%的时间。”

这句话听起来像一句自嘲的废话，合计居然达到了180%，但它道破了软件工业的残酷现实：“表面成型”与“实际可用”之间，存在巨大的鸿沟。

在过去，开发一款办公软件，画界面、搭骨架、写几个文本框，可能需要一个小团队啃上几个月；而在大模型时代，大语言模型吞噬了全网海量的开源代码，让AI吐出成千上万行UI骨架、菜单按钮和基础逻辑，只要几个小时。

AI凭借惊人的生成速度，把软件最容易的前90%快速推到了面前。

但这往往容易让人产生误判

决定一款软件能否进入实际生产环境的关键，全在剩下的10%深水区：

• 那些极度肮脏的非标损坏文件如何容错？
• 几十万字长篇公文中如何防止哪怕1像素的排版抖动？
• 底层复杂的线程死锁和诡异的内存泄漏怎么排查？

正如一位网友对重写Excel的犀利评价：“现在的Excel里，藏着连微软现任员工都不知道是谁写出来的远古奇葩函数。想要百分之百兼容它，已经超出了纯技术范畴，堪称一门考古学难题。”

03Alpha-Creep：一场被大模型加速的“注意力逃避”

在这场风波中，社区工程师们提炼出了一个极具穿透力的新词：Alpha-Creep（Alpha版本蔓延症）。

它揭示了一种在AI编程时代悄然蔓延的心理陷阱与商业泡沫。

任何严肃编写过生产级工程代码的开发者都体会过这种瓶颈：项目骨架搭好后，着手攻关底层性能极限与跨平台兼容死角时，开发往往会陷入漫长而枯燥的攻坚期。

在这个阶段，大语言模型能提供的帮助断崖式下跌。因为那些棘手的边缘Bug，根本没有标准提示词可以直接生成答案，全靠人类开发者对着汇编代码和日志抓狂断点调试。

于是，人性中最原始的逃避机制被AI放大了：

当深入填坑变得无比痛苦时，开发者干脆扔下旧摊子，调转枪头去开辟一个新战场。

从修图工具逃跑到视频剪辑，再从视频剪辑逃跑到文字处理、电子表格。每一次开启新项目，AI都能以极高的效率吐出漂亮的界面，迅速在社交网络上引发一波又一波的尖叫，收割成千上万颗GitHub Star。

但热闹散去后，退潮的沙滩上只留下了一具具外表光鲜却无法独立支撑的数字骨架。

更可怕的隐患，藏在代码库的深处

有资深架构师指出，ArtCraft这种模式制造了一种极其危险的技术债务，“无人认领的代码库（Unowned Codebase）”。

在传统开发中，哪怕是一个很小的团队，每一行代码都经过人类大脑的严密推敲，工程师脑海里有一张完整的系统地图。

但在这种高强度由AI共同署名的项目里，数十万行代码如水银泻地般生成，人类在其中往往退化成了“下发提示词与粗粒度验收的打钩人”，团队中没有人能在脑海里完整掌握系统的全部运转细节。

平时跑标准Demo时风平浪静，一旦某天在复杂文档中触发了底层的排版死锁，缺乏深层心智模型的单兵开发者，根本无法凭空靠几句自然语言提示词让大模型“隔空修仙”。这时候，整个项目就会瞬间撞上一堵无形的高墙。

04狂欢退潮后：是闹剧，还是未来的微光？

我们该把这次轰轰烈烈的“Office挑战赛”全盘定性为一场骗取流量的闹剧吗？

答案恐怕也没有那么简单

脱离情绪化的嘲弄，从纯粹的技术演进视角来看，ArtCraft与WordCraft依然是一场极具前沿价值的极端压力测试。

它至少向全人类展示了一件事：在今天，一个普通程序员配合顶尖AI，在搭建超大型桌面软件原型的生产力上限，已经被推到了怎样恐怖的维度。过去需要跨国巨头投入数千万元、组建几十人正规军才能立项的工业软件骨架，现在一个人几天就能拉扯成型。

与此同时，它也切中了一个清晰的技术演进方向：让AI智能体直接接管办公软件。

传统办公软件是为人眼和鼠标设计的，操作复杂，层层菜单深不见底；而WordCraft一开始就把每一个编辑动作抽象成了389个可调用的命令。它除了提供面向人类用户的图形界面，底层本质上是一个随时准备接入外部AI Agent的“文档驱动引擎”。

搭建出一个视觉可观的Alpha雏形并不困难，但要将其打磨至工业级水准，依然需要经历漫长的沉淀。

AI赐予了我们用几天时间平地建起一座恢弘城堡骨架的神力；但最终决定这栋城堡能不能挡住风暴、让千家万户安心入住的，依然是人类工程师深入到每一根钢筋水泥里，那份枯燥、严谨、无法被任何大模型跳过的恒心与汗水。

这场大戏才刚刚拉开序幕无需将其奉为神话或贬为骗局，它所折射的，正是软件工程在AI时代必经的一场严峻成人礼。