收到朋友转发来的一个开源项目链接时我正在对着空白的周报文档发呆。链接标题很直接——“GenOffice一个人、一周、1万美元Token用AI编码助手从零做出来的AI Office套件”。这个标题有当年“AI一小时做出的游戏”那种营销号的味但作为常年折腾开源软件的人好奇心还是被勾起来了Office这种体量的软件正常团队按年算工期一个人一周能搞出什么名堂哪怕最后做出来的是坨屎能拉成AI Office的形状也值得看看过程。于是我花了一个周末把它clone下来从搭建到实测中间踩了五个不大不小的坑下面是完整的实测记录。1. 先看它打算做什么GenOffice的定位与选型逻辑1.1 README说的和代码里写的clone下来之后我第一件事是看README30秒得出了基本信息这是一个“由AI编码助手辅助生成的智能办公套件”支持文档、表格、演示文稿三类文件的新建、编辑和AI辅助生成。打开页面像极了轻量级的印象笔记加腾讯文档的杂交体左边文件树、中间编辑区、右上角挂着几个功能图标整体布局不算惊艳但面对“一周做出来”的标签第一眼确实让我有点意外。再看技术栈真是AI编码项目的教科书式选择前端React Vite后端ExpressNode.js数据存储直接落JSON文件AI能力通过HTTP接口转发到模型服务端。这个组合在package.json里一眼就能扫出来——没有数据库没有Redis没有消息队列一切从简。这种堆叠方式决定了它的部署成本极低也决定了它离生产环境还很远。为什么AI编码一周能做出来我后来想明白了这正好踩在AI编码助手的舒适区上。React写界面、Express写CRUD接口、JSON文件做存储——这三件套是训练语料里出现频率最高的组合AI生成这类代码基本是肌肉记忆。换成分量级的原生办公应用用C直接怼Office的文件解析和排版引擎别说一周给AI俩月它也未必能交出一版能启动的东西。所以选这个技术栈不是偶然是当前的AI能力上限决定的。1.2 三类选型的深层判断啃完代码后我把这些选型分成三档聪明的、危险的、摆烂的。聪明的选型有几个明显特征。文档编辑器直接用了浏览器自带的ContentEditable没自己去写文档排版引擎——不是不想是AI写不了那种东西与其让AI搞出一堆Bug不如让浏览器兜底。文件导出统一走HTML转Pandoc的工具链没有自己写docx解析器这步棋走得很稳AI最擅长的就是把一种格式的文本转换成另一种Pandoc把“转换”这个脏活接了省掉一大半容易翻车的代码。这两个选择让项目在“最小可行性”上站住了脚。危险的选型同样明显。最典型的是登录模块前端随便填个邮箱密码就能进去后端也不校验token直接是写死的字符串。JSON文件当数据库用了三天没啥感觉的概率很大但多用户同时操作起来文件写坏、数据丢失是迟早的事。API Key也存在前端环境变量里构建产物一解包就能看到这类问题是把原型推到生产环境的罪魁祸首。摆烂的选型倒不多但有几个设计从一开始就决定了上限比如页面路由用了BrowserRouter生产环境一刷新就白屏这种问题AI不会主动帮你规避需要人干预。后面我会专门用一整章讲这些坑的具体表现。2. 从clone到跑通搭建环境中的五个坑2.1 环境准备和启动步骤说干就干我的实测环境是MacBook ProM1芯片、Node 20.11、npm 10.2。标准流程走下来git clone项目到本地根目录npm install前端依赖装完进入backend/目录再npm install复制.env.example为.env填好大模型API Keynpm run dev同时起前后端流程看着简单真正跑起来我在这套流程里卡了快三个小时原因下面一个个说。2.2 五个坑逐一拆解坑一Node版本过老。项目刚clone下来我按习惯先看根目录package.json发现vite的版本要求Node 20以上的新语法。我本机Node 18直接启动报错报错信息是一个看不懂的ESM import报错。排查方式很简单nvm ls看到本机已经装了20.11nvm use 20切过去重新install一次问题消失。这里提醒一句凡是这类新项目先看一眼README要求的Node版本比我这样瞎试省时间。坑二npm install反复超时。切到Node 20之后前端的依赖安装还是卡几次都是装到一半报ERR_SOCKET_TIMEOUT。国内网络环境下的老熟人了处理方式不用多说换个registry源两分钟装完。遇到这种情况不要反复重试直接改源。坑三环境变量名对不上。这是最坑的一个。README里的配置说明写的是OPENAI_API_KEY但clone下来以后打开backend/.env.example发现变量名是ANTHROPIC_API_KEY。按README填好OPENAI_API_KEY启动后AI功能全部404——后端根本没读到这个变量初始化模型客户端的时候直接拿到了undefined。我最终是全局搜索代码里的process.env才发现变量名不一致。这个算是AI生成项目典型的文档与实现脱节我甚至怀疑作者写README的时候自己也记不清用了哪个变量名。坑四跨域和端口不匹配。前后端都起来了登录成功进入主界面但所有文件操作全部失败。打开浏览器F12看Network发现前端请求发到3000端口而后端服务跑在5001接口一个都打不通。查了一下前端代码里的API_BASE_URL写死的是http://localhost:3000/api难怪全挂。把后端端口改成3000或者改前端配置都能解决。我图省事直接把后端端口改成3000了。坑五生产构建后刷新就白屏。npm run build之后用静态服务打开路径一刷新页面就404。这个在1.2里提过BrowserRouter在纯静态部署下没有服务端路由回退白屏很正常。开发模式没事一旦部署就暴露。我的处理方式是临时把路由改成HashRouter几分钟搞定——虽然丑但能用毕竟今天的主要任务是实测功能不是给作者改代码。到这里GenOffice总算在我的电脑上跑起来了。界面的第一印象确实很“AI味儿”左边一个文件树中间一块编辑区右上角挂四个小图标整体设计是典型的通用模板风不丑但也没有记忆点。3. 逐模块实测哪些能用哪些纯摆设3.1 文档模块基础能用细节全崩先把文档模块试了个遍。新建一个文本文档在里面打字、回车、加粗、加标题、插入无序列表——这些基础操作都没问题光标移动和快捷键响应正常作为日常记录工具是合格的。但从第二个层级开始就露馅了。插图片只有URL方式本地图片上传的按钮在界面上有点了没反应——我翻代码才发现这个按钮压根没绑事件。更麻烦的是导出。我把一篇带标题、二级标题、正文、一个表格、一段引用的文档导出为docx用WPS打开之后表格外边框没了引用的缩进变成了一坨分页符全乱。再用Microsoft Office打开情况稍好一点但多级标题的样式自己分叉了字体从等线变成了宋体。为什么会崩根子在ContentEditable。这个技术方案在原型阶段确实省事但它产出的HTML结构非常随意标签嵌套层级五花八门转换器拿到这种脏HTML能正常导出才是怪事。我拿一篇纯纯的纯文本文档导出倒是没毛病只要带上结构、样式兼容性就直线下降。所以文档模块的定位很清晰记录点文字、写写草稿可以拿来做正经排版文件趁早放弃。3.2 表格模块全项目最拉胯的一环表格模块是重灾区。新建表格后单元格单击、双击编辑、回车换行这些基本交互是通的但也就到这里了。公式支持的数量少得可怜就SUM、AVERAGE、IF三个更离谱的是SUM的实现有bug——我选中一列10行数据它只对前5行求和。我特意去翻了一下后端代码函数体里写死了遍历前5个单元格见此我差点笑出声。图表功能只有一种柱状图填充颜色写死在代码里用户想改个颜色得改代码。单元格合并根本没做你右键单元格看到的合并选项点了以后只是改了CSS样式打印导出时原形毕露。数据导入导出只支持CSV且完全不校验格式日期列导入时全部被当成字符串。结论很直接这个表格模块连做一个“数据录入表单”的资格都比较勉强。日常加减乘带公式的计算、稍微复杂点的数据透视全都不沾边。如果你日常工作离不开Excel或WPS表格的及格水平这个模块可以直接跳过。3.3 演示文稿模块AI生成反而是最大亮点表格最拉胯但演示文稿模块给了个小惊喜。它的核心入口不是手动编辑而是AI生成。我输入“帮我生成一份2025年AI Agent发展趋势的PPT6页左右”两三分钟后返回一个结构化大纲封面页、引言页、四个趋势点、总结页结构像那么回事每页还配了几句要点式的文案。选了一个“商务蓝”模板生成PPTX用LibreOffice打开整体布局基本在线文字没有溢出只是字体被替换成了本土字体页脚对齐有轻微偏移。再用WPS和Microsoft PowerPoint分别打开PowerPoint显示正常WPS里有两页装饰形状跑位。考虑到这是AI纯生成这个表现其实是能用的——导出之后花十分钟手动修一下就好。token消耗也让我第一次有了直观感受。日志显示这次生成大约消耗输入token 1.8万、输出token 0.4万按当前主流模型API的中端定价粗算成本约0.1美元。从成本角度看PPT生成这个功能是最划算的因为同样一段需求丢给人工做半小时是要的。3.4 AI功能本身好用和难用的边界GenOffice的AI能力分布在文档、表格、PPT三个模块里一律是“输入提示词→调模型→输出内容”的简单模式。文档模块里它可以写一篇命题作文给足了提示词之后效果还行但上下文是断的——你让它写开头再让它顺着写结尾它完全不记得开头内容因为每次请求都是独立对话没有任何记忆归一。生成长文档还有一个硬伤没有流式输出和取消机制。我实测让它生成一篇3000字的项目报告等了约40秒进度条走到一半报了个超时错误结果什么都没留下token倒是实实在在扣了。这种体验在重token消耗的场景下非常劝退因为没有断点续跑也没有草稿缓存烧了钱还得重新来一遍。实测下来AI功能适合的场景是“短内容快速生成”一段摘要、一份简单的方案大纲、一篇带固定结构的通知。不适合的是“长文、多轮迭代、对上下文有依赖”的复杂任务。3.5 实测综合评分模块基础可用性亮点致命伤文档合格基础编辑流畅、Pandoc导出链路清晰复杂排版导出全崩、图片上传无效表格不合格单元格编辑基本可用SUM公式bug、无图表、无合并单元格演示文稿可用AI生成PPT质量超预期、成本低模板库只有3套、导出有偏移AI助手可用短内容生成效果不错无上下文记忆、无流式输出、token不可见4. 代码翻修AI生成项目最典型的“看起来能跑”4.1 代码画像规整的表象和重复的里子功能测完我进入了一个技术宅最爱的环节——翻源码。整个项目前端加后端大概60个文件代码量约7500行这个规模确实是一个人在一周内能写出来的量。第一感受是代码风格一致得不像话。函数命名全是清晰的动宾短语组件结构层次分明注释虽然不多但关键处都有中文说明。这就是AI生成代码的好处没有个人风格全是模板风格读起来像是教科书。翻得深了就发现问题了。工具函数大量重复格式化的函数在前端至少有四处各自实现了一份只是参数顺序不同。数据流全靠props层层透传没有任何状态管理库页面稍微复杂一点组件的props能传十层。这种代码作为原型没有大问题但可维护性很差——想修改一处逻辑得先确认改的是不是被复用最多的那一份。4.2 三个典型的“AI坏味道”坏味道一假登录。登录接口不查数据库不校验密码拿一个写死的伪token糊弄前端伪token的签名部分就是字符串“fake_token”。这意味着任何人抓包看一眼都能伪造身份文件权限体系形同虚设。这是我见过AI生成项目里最普遍的一个坑——AI喜欢“模拟”一个接口的返回格式却不关心实现过程。坏味道二接口返回假数据。有的接口看起来逻辑完整实际返回的是测试占位内容。比如统计模块的图表数据后端直接返回一个硬编码的数组上面标注着“TODO”。这类问题在AI生成代码里很常见因为AI倾向于把功能“补全”到一个能跑的状态哪怕数据是假的。对AI来说能跑和能正确工作是两个概念但在它“理解”里没有优先级之分。坏味道三错误处理偷懒。几乎所有异步接口的失败分支都是往控制台打印一行错误日志然后返回null。前端拿到null之后往往不做任何提示用户看到的体验就是“点了没反应”。这个坏味道比前两个更隐蔽因为它让Bug变成悬案——日志单机版能查真上了生产环境就两眼一抹黑。更麻烦的是代码里到处是这种吞错误的写法根因分析的难度翻倍。4.3 我实测中遇到的最诡异bug保存文档后刷新就消失这个bug值得单独写一节因为它的排查链路非常典型几乎能代表这类AI生成项目里“看起来正常但逻辑自相矛盾”的毛病。现象是这样新建一个文档点保存后端返回200一切正常。但是刷新页面后文件列表是空的刚才保存的文档像没存在过一样。排查第一步看网络请求。保存接口POST /api/files返回200和一个success字段读取接口GET /api/files返回了一个空数组。问题不在请求失败而在读取阶段。排查第二步对比接口日志。我翻后端日志发现保存文件的目录是/data/user_coder而读取文件列表时传的用户参数是admin目录对不上自然读了个寂寞。排查第三步定位根因。前端的保存逻辑里用户ID是从token解析的而读取列表时用的用户ID存的是localStorage里的userId。这两个地方第一次登录后值确实一样但在某些页面刷新后token是新的但localStorage没更新两个ID就分叉了。修复方案不复杂统一从token里解析用户ID把localStorage的冗余字段删掉。但我之所以说这个bug“典型”是因为它暴露的是一个设计层面的问题——假token、假的用户状态、多套用户信息来源交叉在一起。这种问题不是改一行代码能根治的得从数据流上重新设计。5. 把1万美元的账算明白5.1 Token到底烧在哪了1万美元这个数字7000行代码这是整个项目最引人注目的核心。我先根据项目里的代码量、功能点以及AI编程的典型消耗模式做了一张粗略的估算表项目估算值开发周期7天平均每天AI会话轮次40-60轮平均每轮上下文长度5-10万token估算日输入token200-500万估算日输出token10-20万7天输入token总和1400-3500万7天输出token总和70-140万按主流中端模型API价格粗算总费用约8000-12000美元为什么AI编码这么烧Token核心原因是每一轮对话都会把项目上下文重新发一遍。AI编码助手为了理解你正在改哪个文件、当前代码是什么状态不得不把相关文件内容拼进上下文里一次几万token是常事。一个上午跑50轮调试对话那输入token的量就是百万级起步。更烧的是“调试循环”。功能写完编译报错把报错信息贴给AIAI改再报错再改。一个看似简单的导出功能在几次长上下文的调试轮次里可能就烧掉几美元。这种试错成本是AI编码这种工作模式的必然开销——它会把AI的能力边界清清楚楚地换算成钱。5.2 这个账到底值不值拿人力成本对比一下。一个稍微像样的Office MVP正经团队就算3人产品前端后端干一个月按人力成本算每个人月2-3万人民币不过分合计也是1万美元甚至更多。GenOffice用一周时间、一个人的算力做出了一个能跑通全流程的“文档表格PPTAI”的Demo单从验证想法的角度看这笔钱花得相当值。但从“软件可用性”角度看1万美元换来的是一个“能用但只能浅用”的壳子。基础文档编辑OK表格逻辑有BugPPT模板少得可怜多用户协作完全缺失。如果用生产级Office软件的标准来考核这1万美元还远远不够后面至少还得烧几万美元才能把细节磨平。我觉得比较公允的判断是作为个人开发者验证“AI能不能低成本做Office套件”这个命题1万美元交出的这张答卷是及格的作为一款想被真实用户日常使用的软件它还处于“半成品Demo”阶段。它证明了路是通的但路还很长。6. 实测结论它到底能不能用谁能用6.1 分场景回答“能用吗”回到题目本身GenOffice能用吗我把它拆成三个场景分别回答。场景一日常记录点文字、写写简单的文档。能用。基础编辑流畅导出纯文本或简单结构的docx没有大问题AI辅助写些命题短文也够用。场景二做正经的表格数据处理。不能用。公式支持不全还有Bug图表只有柱状图多工作表、数据校验通通没有。这个模块目前只能当个带网格线的笔记本。场景三快速生成一份PPT拿去改改就能用。可用而且是亮点。AI生成大纲的质量超出预期导出后在PowerPoint里做点微调就完事时间成本远比从零做起低。一句话总结GenOffice不是Office的替代品它是一个“AI文档生成器极简编辑器”的复合体。它最擅长的事是通过AI生成内容而不是像Office那套桌面软件一样在排版和计算上较真。6.2 如果要继续维护我会先动这四个地方虽然问题一堆但GenOffice的底子是干净利落的要做生产化改造优先级也很清楚。首先是登录和权限。假token必须换成真正的JWT签发和校验用户数据落库而不是睡在localStorage里。其次是存储层JSON文件换SQLite加个迁移机制避免数据结构一改就全丢。然后是编辑器选型。文档编辑这块把ContentEditable换成TipTap或ProseMirror这类成熟方案能解决绝大多数导出崩溃和排版错乱的问题代价是编辑器面积会大不少但值得。最后是AI层的成本控制。加一个token用量面板让用户知道每次AI操作花多少钱给长内容生成加流式输出和取消按钮同一主题的多轮对话带上一个session_id实现基础的记忆功能。这三件事做完GenOffice的AI体验会从“能跑”变成“好用”。最后说点个人体会。测完这个项目我最深的感觉是对AI编程的认知被扳正了一些。它确实已经能撑起一个Mini级别产品的原型开发但前提是你得清楚它的边界在哪里并且在所有AI不擅长的地方果断找人做技术兜底。GenOffice那1万美元烧出来的不是软件功能是“一个人能否独立完成一个复杂软件原型验证”这个问题的答案——而这个答案是值这个价的。如果你也想试试AI编码的边界最快的办法就是拉一个类似的项目下来自己跑一遍别光看别人的评测因为上手踩坑的过程本身就是最大的收获。