一个"换图片"的功能翻车 6 次：免费 AI 干到一半不行了，K3 救场，而我的周额度只剩 3%

我在用 AI 开发自己的备考学习系统（软考高级·系统分析师）。事情发生在周五晚上：我的 Kimi Code 周额度已经烧到 91%，而页面上一个看起来最简单的功能——把错题里识别错的图片换成正确的——刷新一下就打回原形。

我以为半小时能搞定。结果这个功能前后翻车了 6 次，中间的页面甚至被我"修"到直接卡死。而两条 AI 产品线的表现差异，比 bug 本身更值得写。

半小时的活，从"修错了项目"开始

第一个坑不是技术，是方向。

我的勘误功能（发现资料错误、当场修正）最早写在浏览器插件里，后来重构到了学习页面里。AI 没问清楚，对着插件里的旧代码就是一顿猛改：修复结果写进浏览器本地数据库（IndexedDB，可以简单理解为"浏览器里的小金库"）、页面加载时自动重放——干得漂漂亮亮。

我只说了一句："你修错 bug 了，勘误早就不在插件里了。"

教训一：AI 不会主动确认"活代码在哪"，它凭功能名猜。你不拦着，它能把错的代码修得越来越完美。

真正的 bug：三个叠加，个个隐蔽

转到正确的代码后，问题很快现形，是三个 bug 叠在一起：

1. 状态被覆盖：修复完成写入数据库时，存储函数无条件把状态写成"待处理"，而刷新恢复只捞"已处理"的——等于修了个寂寞；
2. 定位信息存错了时机：先改了页面再记录"出错内容长什么样"，存进去的是新内容。刷新后拿新内容去找旧位置，永远找不到；
3. 看不见的变量：补丁函数引用的变量名只存在于另一个文件的闭包里，跨文件就是 undefined——数据源补丁从写下的那天起就没执行过一次。

第三个最典型：代码看起来逻辑完整，实际上一行都没跑过。

我把页面"修"卡死了

修好持久化后，又出现一个瑕疵：错误的图片会先闪一下，才被换成正确的。原因是恢复逻辑有 300 毫秒延迟。

AI 把延迟去掉，改成"页面一变立即恢复"——然后整个页面直接卡死。

原理：页面变化监听器的回调里去改页面，改动又触发监听器，只要某条修复还能匹配到元素，就是无限循环。治闪屏治成了死机，这是当晚第二翻车现场。

转折点：我说了一句"不要内存，写文件"

到这里我忍不了了，把需求本质摊开说：

"我一直认为要永久性修改。数据库、本地错误的源文件直接替换掉，不要搞什么内存。"

这句话把架构整个掰正了。原来很多人（包括 AI）脑子里有个过时假设："浏览器网页改不了本地文件。"其实 Chrome 早就有了 File System Access API——网页经用户授权后，可以直接读写磁盘上的文件。

新架构一句话：勘误 = 直接改写源文件本身（题库数据 js + OCR 转出的 markdown 源文件），浏览器缓存只留一条轻量历史记录。

那个卡死页面的"回放机制"整段删除——因为根本不需要回放了，刷新后页面从源文件加载，天生就是对的。后来复盘发现，用户那句怀疑是对的："卡死 bug 就是内存临时存储搞出来的。"

最后一翻：换张图片为什么这么难

架构对了，功能还是报错"源文件中未找到匹配内容"。又是两个原因：

• 我修的是上次修过的同一张图。上次临时替换把图片地址换成了内存数据，拿着内存数据去源文件里找，当然不存在；
• 匹配逻辑太娇气：同一张图在三种文件里有三种路径写法，全路径比对稍有差异就失败。改成按图片的唯一哈希文件名匹配，一次通过。

到这里，"换图片"这个功能在翻车 6 次之后，终于真正完工：改动直接落盘、自动备份、刷新永存。

另一个战场：免费的 Kimi Claw 和烧钱的 K3

当晚还有个并行实验。我的 Kimi Code 周额度 91%，于是把一部分活交给了 Kimi Claw（桌面版 AI，走另一条线，不消耗 Kimi Code 额度）。

真实表现：

• Kimi Claw（k2.5）：搭插件框架、写常规功能没问题，零额度消耗，真香；
• 但碰到硬骨头就露馅：勘误这种"跨文件状态一致性 + 本地文件读写"的复杂活，它修出来的东西就是文章开头那个"刷新就丢"的半成品——不是态度问题，是复杂调试能力确实不够；
• 最后还得 K3 上场：定位三个叠加 bug、诊断无限循环卡死、重写文件写入架构，一晚上干完。

代价也很直白：K3 周额度从 91% 干到 97%，离重置还有 2 天。

我的结论：免费额度适合"确定性高的建造"，氪金额度要留给"不确定性高的调试"。 这不是省钱攻略，是算力分配策略——把贵的模型花在它真正拉开差距的地方。

经验总结（可复用方法论）

• AI 报修前先问"活代码在哪"：功能迁移过的项目，AI 默认会修错地方；
• 警惕"内存修补"架构：凡是要"刷新后重新应用一遍"的设计，都是给源数据不够可信打补丁，bug 会以闪烁、卡死、丢失三种形式收利息。能改源头就改源头；
• "网页改不了本地文件"是过时认知：Chrome 的 File System Access API 在 file:// 页面也能用，本地工具类网页可以放心直写文件，记得写前备份；
• 别把用户内容拼进 onclick：题干里的换行和引号能让按钮直接哑火，绑定事件就用 addEventListener；
• 大文件别进 git：600MB 的 PDF 暂存一次，.git 直接 798M；清理后只留文本和代码，7.4M。

结尾

一个"换图片"的功能，翻车 6 次才完工——但每一次翻车都把系统往正确的方向推了一步：从内存到文件，从补丁到源头。

AI 编程的真实成本不在额度数字上，在于你能不能分清：哪些活是"建造"，可以交给便宜的模型；哪些活是"排雷"，必须请最贵的那个。

你最近有没有被"看起来很简单"的功能坑过？评论区聊聊。

备选标题

1. 一个"换图片"的功能翻车 6 次：免费 AI 干到一半不行了，K3 救场，而我的周额度只剩 3%
2. AI 编程实录：修 bug 修到页面卡死，最后发现"浏览器能直接改本地文件"
3. 周额度 97% 的晚上，我搞明白了免费 AI 和付费 AI 各自该干什么活