Vibe Coding 的“恶果”来了最近在升级 JClaude发现 Tokens 消耗特猛然后分析了代码发现其中有一个代码文件已经快 10000 行了。大概算了下光这一个文件上下文就有十几万 Token 了虽然程序运行完全正常但是技术债越来越重了所以必须重构一下。最近刚好在测试 Kimi K3我就把这个任务交给它了这个测试应该比做一个动画效果来得更有实际意义吧。下面就来看一下它的重构过程以及重构后的结果。1、项目简介先简单介绍一下这个项目的情况这是我之前做的 Claude Code 中文界面版完全克隆了 Claude 桌面版的界面然后调用 Claude Code 终端自动接入第三方模型。也就是说第三方模型可以直接用 Anthropic 家最强编程智能体不受账号限制。当然如果你接入了 Opus 4.8那这个软件的能力基本上约等于 Anthropic 官方的 Claude 桌面版。因为最近加入了这个角色和技能相关的功能就发现这个项目文件已经膨胀到让人无法接受的程度了。这个项目开始于一个简单的界面克隆测试所以当时并没有在意代码结构的问题。然后在修改的过程中也没有强制提出重构的需求所以 AI 就一直在堆“屎山”我估计很多很多的 Vibe Coding 项目都会面临这样的问题。刚开始呢是试着玩玩的玩得爽了就越改越大。2、基础情况这个项目是TauriRust开发的安装包和很小内存开销也很低可以制作多平台的发行包。界面部分主要是JSCSSHTML等前端代码界面效果可以做的很好后端是Rust可以高效的和系统进行交互。开发支持热更新效率很高。这是基础情况。要重构代码的话先得了解一下具体的代码的情况所以我们的对话是这么开始的当前代码中有哪些文件代码行数特别多有没有做一下优化的必要性然后得到了这样一个结果从这里可以看到main.js已经 9338 行了真的是快接近万行了里面有 400 个函数接下来就是具体看一下里面有什么了main.js 内部结构它本身是纯 script无 import/模块化靠 30 个 // 注释分段。最大的几段• Claude Code CLI bridge—— 约 2160 行最大的单一块 • Experts Skills 管理—— 约 800 行 • i18n—— 约 620 行基本是翻译数据 • Code workspace panels / Projects / Settings / Providers—— 各 500-600 行其实模块还是很清晰的但是文件确实太大了有没有优化必要大概情况知道了接下来就是判断一下有没有必要优化了。K3 的结论是有但要看你们接下来的开发节奏且不建议一次性大改。支持拆分的理由• 单文件 9k 行已超过可维护性的常见阈值多人协作时合并冲突几乎不可避免 ​ • 部分段落是天然的拆分候选成本低收益高 ​ • i18n 是纯数据抽成 i18n/zh.json、i18n/en.json 之类零风险 • CLI bridge 2000 行自成一体抽成独立模块后主文件立刻瘦 1/4 • Tauri 支持原生 ES modules拆 script typemodule 不一定需要引入打包工具它这里提到了很关键的一点就是多人协作冲突是一个大问题。对我而言还好我就是多 AI 合作一把梭。需要权衡的点• 目前测试覆盖很薄大重构没有安全网回归风险高 • 大文件本身不是病——如果这段代码已经稳定、很少改动靠分段注释导航也能用建议的优先级如果近期要持续加功能尤其是 CLI bridge、Skills 相关就按 i18n → CLI bridge → 各 workspace 面板 的顺序增量抽取每抽一块跑一遍现有测试如果只是维护期、改动少可以先不动只把 i18n 数据分离出去。3、多维度分析目前的情况看来除了大之外没有特别大的问题。其实我比较担忧的是大文件情况下 AI 读写和 Token 消耗的问题。所以我第二轮的需求是下面我们从代码设计、AI 读写以及 Token 消耗的角度来判断一下优化的必要性。下面是 K3 的分析结果。1、代码设计角度• main.js 的问题不只是长而是无模块化的长约 400 个函数全部是全局作用域通过 一个全局 state 对象和 DOM id 隐式耦合。你没法只改设置而不碰对话因为它们共 享同一片命名空间。 ​ • 这直接导致可测试性差——测试薄只有 3 个针对性测试很大程度上是这个结构的果不 是因。函数无法单独 import就没法单测。 ​ • lib.rs 同样 4148 行单文件但 Rust 有模块系统和编译器兜底拆分安全且容易风险 远低于 main.js。 ​ • styles.css 4836 行在 CSS 里不算异常危害最低可放最后。单看代码设计有必要拆但属于慢性病不致命。2、AI 读写角度这是大文件代价最直观的地方• 读不完整主流 AI 工具单次读文件上限约 1000 行9338 行的文件 AI 永远只能看局部 。改一个功能时它读到目标段落却看不到 3000 行外那个依赖同一全局状态的函数—— 改坏联动的概率显著上升。 ​ • 编辑易误伤AI 编辑靠精确字符串匹配。9k 行文件里相似代码片段多比如那 14 个并 排且结构几乎一样的 persistXxx() 函数匹配唯一性差误替换风险高。 ​ • 定位成本高目前靠 // 分段标记 grep 还能工作但跨段依赖全局 state、跨 段调用对 AI 不可见每次都要重新摸索。拆成模块后每个文件能被 AI 一次整读心智模型完整改动质量明显上升。3、Token 消耗角度按中英文混合代码约 3.5 字节/token 粗估• main.js 全量读入 ≈ 13 万 tokens一次就吃掉大半个上下文窗口。 ​ • 实际工作模式是 grep 分页读若干段但每次任务往往要读 state 定义段 目标功能段 相关 persist/i18n 段累计轻松到 3-5 万 tokens而且每次会话都重复消耗。 ​ • 拆成模块后一个任务通常只需整读 1-2 个相关文件几千 tokens单次任务省 80% 且是持续性收益——每次让 AI 改代码都在省钱。 ​ • i18n 那 620 行是纯数据最冤经常被卷入上下文却几乎不需要全部内容。这确实是个大问题太浪费了。修改后能节省 80%这个诱惑还是很大的。4、综合判断单看代码设计拆分是应该做但不紧急叠加 AI 读写和 token 成本后必要性明显升级——因为我主要就是用 AI 辅助开发大文件的税是每次任务都在交的。结论不变增量拆分顺序 i18n → CLI bridge → 各面板。4、深入分析其实我心中早就有数了因为我已经让 Opus 4.8 拆分过一次了。这次很明显也是让它按拆分的方向去的。为了谨慎起见或者说为了更好地引导 K3 完成任务我再问它第三个问题那我们就先把 main.js 这个文件拆分一下吧。那你觉得如何来拆分这个文件比较合适拆分到什么样的颗粒度比较合适拆分过程中应该注意什么如何保障成功完成这个重构任务1、怎么对齐现有分段分层 自下而上。加载方式从script src./main.js改为script typemodulesrc./main.js。然后按现有// 分段抽取分层依赖• 第 0 层纯数据零依赖i18n、DEFAULTS、MODEL_BLURB/system prompt、action chip prompts ​ • 第 1 层基础state全局 state KEYS 14 个 persistXxx、storage、Tauri API 封装 ​ • 第 2 层UI 基建theme、sidebar、tooltip、菜单 ​ • 第 3 层功能域chat、projects、settings、providers、experts/skills、code panels、CLI bridge、browser、code stats、mentions ​ • main.js 最终只剩入口import init/boot 顺序2、颗粒度一个分段一个模块200–800 行/单文件• 目标每个文件能被人或 AI 一次整读1000 行预计拆出 15–20 个文件收进 src/js/ 之类的子目录。 ​ • 不要再细拆成 50 个 100 行的小文件会让 import 清单本身变成维护负担跨文件跳转反 而更累。 ​ • 也别贪全chat/projects/settings 核心段耦合最重如果拆到那里发现代价陡增留一个 较大的 app.js2000 行以内也完全可以接受——80% 的收益来自前 20% 的抽取。3、注意事项按翻车概率排序1. 测试 eval 耦合如上所述搬 DEFAULT_EXPERTS 等被测代码块时必须同步改测试的 SRC 路径标记字符串原样保留。 ​ 2. 循环依赖功能模块间必然互相调用chat ↔ workspace ↔ projects。ESM 循环导入在 仅运行期调用、无顶层副作用下是安全的——所以搬移时保持 function foo() {} 声明形式 有提升禁止在模块顶层执行跨模块调用init 统一由 main.js 触发。 ​ 3. 共享 state 唯一性state 对象main.js:474必须从 state.js 导出同一个引用所有 模块 import 它绝不能复制。 ​ 4. 只搬不改每次提交只做机械搬移 补 import/export不顺手优化逻辑。重构成败的关键 就是 diff 可审查。 ​ 5. import 清单遗漏400 个函数分散后漏一个 import 就是运行期 ReferenceError静态 检查抓不住项目无 lint。对策见下。 ​ 6. init 顺序boot splash、applyWorkspace 等有 DOM 时机依赖index.html 注释专门提过 入口处的初始化顺序原样保留。 ​虽然只是拆一个文件其实难度还是有的。因为不同模块之间是有耦合的我之前让 Opus 分析过有些模块间的耦合度有几十个。一个拆完之后文件行数和文件数量都会变化所以模型必须重新学习新的结构再进行后续的解耦。4、如何保障成功这一点很关键• 试点先行第一步只做 i18n state 两段跑通搬移 → 改测试 → 验证全流程确认模式 可行再批量搬。 ​ • 每步三道闸npm test 全绿3 个 node 测试 cargo test→ npm run dev 启动冒烟主 界面、聊天、设置、Code workspace 各点一遍看控制台报错→ 独立 commit。出问题单步 回退即可。 ​ • 明确的完成标准main.js 只剩入口300 行、测试全绿、冒烟清单通过、每个被搬分段 都能在新文件里被 grep 到。 ​ • 顺序i18n → 纯数据 → state/storage → UI 基建 → CLI bridge最大但自成一体瘦 1/4 就靠它→ experts/skills、code panels、browser → 核心段视情况收尾。从它的回答看应该是理解得比较透彻了。我已经经过 3 轮引导它应该已经掌握了关键信息。所以最后一句话就是开干5、重构过程下图是它自己做的 todo 任务列表改完之后还问了我两个问题第一个是用 git 管理版本方便回退。第二个是冒烟测试怎么做。这个还是很稳的但是我对它的测试选项不是太满意怎么可以把手动启动 dev 放在推荐呢必须你来启动我来看啊另外说一点细节可以作为对比参考。Opus 4.8 改的时候虽然改得很细但是很自信地告诉我它会自己做 dev 测试我就做了个甩手掌柜。由于第一轮独立性比较强整体修改非常快。我测试了一下没有这么大问题。唯一的问题是无法调用 Claude Code我不确定它为什么把内置CC给我跳过了正常没有理由弹这个的。我把情况给它说了一下它就成功解决这个问题了。那就没啥大问题了继续推进随着修改的深入逐渐变得复杂起来了改到中间环节的时候验证点逐渐变多了修改的时间也越来越久了。6、重构结果整个重构过程大概消耗了小半天时间。最后把这个main.js从 9938 行压缩到了 263 行减少 97%。全部改成模块化设计拆成了 24 个模块每个 33-2177 行。总共提交了 13 个 commit每步可单独回退。基础语法检查和其他校验它已经做好了然后我人工检查了各项功能全部是正常运转的。这次重构非常成功而且毫无波澜重构是要点脑子的而且是一个非常严谨的问题容不得一点错误。K3 能改完没有错误这一点还是略微出乎我的意料。2.8T 的参数了果然是稳了很多这一次测试结果还比较理想的下一篇将要让它修改桌面软件的疑难 Bug 了敬请期待