我用 3000 行 AI 代码做软件,输给了老婆 3 秒生成的表格

事情要从两个月前说起。

老婆的托管班，经常需要录入学生信息、记收支明细、算利润、看趋势。她一直用备忘录和计算器，偶尔用用Excel。有一天她随口说了一句：“要是能有个自动统计的工具就好了。”

这句话在我脑子里种了草。

我是那种典型的“手里有个锤子，看什么都是钉子”的人。那段时间正好在Vibe Coding——用自然语言描述需求，让AI帮你写代码的编程方式。我心想：这不正好吗？我不会写代码，但我会提需求啊。

于是我开始了一场浩浩荡荡的“造轮子”运动。

第一周，我让AI帮我搭了一个本机 Web 框架。Flask + SQLite，左侧导航栏分了几个模块：首页驾驶舱、学生中心、日常支出、工资管理、现金流水、凭证中心。学生中心下面还细分了收费订单、收入入账、退费记录、欠费台账。首页放了一排大大的统计卡片，显示本月收入、退费、净收入、经营利润、现金余额、待收尾款，还有合伙人的均分分红。

第二周，我开始加功能。既然做了，就做好一点嘛。我加了数据可视化——首页支持本月和全年两个视角，全年有 1-12 月月度趋势表，看收入、支出、利润的走势。我还做了登录系统，虽然就她一个人用。甚至加了凭证强制上传——收入、支出、工资、退费、现金，每笔入账必须拖入微信截图或小票，没有凭证不让保存，防止账目说不清。

代码量从最初的几百行膨胀到了三千多行。配置文件、依赖包、构建脚本，加起来小一万行。我每天下班回来就坐在电脑前，跟AI对话、调试、改bug，乐此不疲。

现在回想起来，这整个过程充满了Vibe Coding式的傲慢：我觉得我在解决问题，其实我是在创造问题。

Vibe Coding最危险的地方在于，它让不会写代码的人也能“编程”。但这种“编程”的门槛降低，并不意味着“做软件”的门槛降低了。写代码只是做软件的一小部分，真正难的是理解需求、设计体验、持续维护。

而我，跳过了前面所有步骤，直接跳到了“写代码”。

让我把时间线拉回到“出问题”那天。

那天晚上，老婆在记账。她打开我做的软件，点了三下，没反应。又点了两下，页面白屏了。她给我发微信：“又坏了。”

我一看，没看懂，找AI看了下，是浏览器缓存导致的前端路由出了问题。清一下缓存就好。但问题是，她不知道要清缓存，我也不知道，大家也不应该知道。

我修好了，跟她说“可以用了”。她回了个“嗯”。

第二天，她又说数据对不上。我查了半天，发现是她录入的时候，有一笔支出入账忘了选日期，导致统计口径出了问题。

第三天，她说想看一下上个月某笔活动物料的支出的明细。我做的系统里确实有这个功能，但藏在三层菜单下面。她找不到。

就在我焦头烂额地修bug、加功能、优化体验的时候，她做了一件事。

她打开豆包——说了一句：“

豆包给她生成了一个表格模板，她打开到WPS里，开始录入。

从那以后，她再也没打开过我做的那套系统。

我后来仔细看了看她用的那个表格。说实话，简陋得令人发指。就是一个普通的电子表格，列了七八个字段，下面有个SUM函数做汇总。没有图表，没有看板，没有IP形象，没有自动备份。

但她每天都在用。

那个表格解决的是她真正的需求，而不是我假设的需求。

她需要的不是“一个经营统计软件”，她需要的是“一个能快速记录、方便查看、不出错的工具”。表格完美满足了这三点。而我做的那个软件，一个都没满足——录入太慢、查看太复杂、还老出错。

这件事给我最大的教训是：工具不是越复杂越好，而是越合适越好。

听起来像废话，但做起来真的很难。因为“复杂”本身有一种诱惑力。当你学会了一种新工具、新技能，你总想把它用在所有地方。尤其是Vibe Coding这种东西，它让我觉得“我什么都能做”，于是我什么都做。包括我做了剪贴板、灵感随记、局域网快传等等，最后反响最高的反而是局域网快传,主打一个轻灵快。

大多数问题不需要“解决方案”，只需要“够用的工具”。

我老婆需要的不是软件，是表格。就像大多数人需要的不是“知识管理系统”，而是一个能搜到笔记的备忘录。

这里面有一个很深的认知偏差：我们容易把“工具的复杂度”等同于“问题的严重程度”。觉得问题很大，所以要做一个很复杂的工具来解决。但很多时候，问题很小，用一个简单的工具就够了。

更关键的是，复杂工具带来的隐性成本被严重低估了。

我做那个软件花了两个星期。这两个星期里，我本可以打打篮球、看看书、甚至说刷刷抖音。软件做出来之后，我又花了两周的时间修bug、做优化、教她使用。这些时间加起来，够她用手写账本记一年了。

而她用那个表格，从创建到上手，三秒钟。

“我用三个月写了一个软件，她用三秒钟选了一个工具。”

这就是复杂工具和简单工具之间的真实差距。不是功能上的差距，而是时间成本、学习成本、维护成本上的差距。

这件事之后，我给自己定了一条规矩：先问痛点，再做功能。

01观察。不要急着做东西，先观察对方是怎么工作的。她用什么工具、在什么环节卡住、哪些操作是重复的。

02确认。直接问：“你最大的痛点是什么？”不要问“你想要什么功能”，因为大多数人描述不清楚自己想要什么功能，但他们能清楚地告诉你哪里痛。

03最小化。用最简单的方式解决那个痛点。能用表格解决的不做工具，能做工具的不做系统，能做系统的不做平台。

04验证。做出来之后，看对方用不用。如果对方不用，不要问“你为什么不用”，而要观察“你在用什么”。你观察到的，才是真正的需求。

观察：她用备忘录记账，经常算错。确认：她说“容易记混，算不清”。最小化：帮她做一个带自动求和的表格模板。验证：她用了，问题解决。整个过程不超过半小时，而我实际花了一个月。

1先别急着写代码。遇到需求的时候，先想想有没有现成的工具可以用。飞书表格、Notion、Excel、Google Sheets，这些工具存在了几十年，不是没有道理的。

2从“最小可用”开始。不要一上来就做完整的产品。先做一个最简陋的MVP版本，看对方用不用。用了再加功能，不用就及时止损。

3警惕“创造”的快感。让AI写代码、搭系统、做设计、出成品，这些事本身会带来很大的成就感。但成就感不等于价值，你写的代码没人用，解决不了需求，那就只是无效产出。

4学会“不做”。很多时候，“不做一个软件”才是最好的决定。帮对方找一个现成的工具，教他们用，比做一个半成品软件有用得多。

我做的那个软件现在还躺在我的硬盘里。偶尔打开看看，AI代码写得其实还不错（反正看不懂），架构也合理（外观我喜欢），驾驶舱图表渲染得很漂亮。

但它从来没有被真正使用过。

而老婆的豆包表格，现在还在WPS里，每天更新，干干净净。

有一次我忍不住问她：“你觉得我做的那个软件怎么样？”

她想了想说：“挺好的，就是太麻烦了。”

“太麻烦了。”这三个字，比任何技术评审都准确。