企业官网建设流程全解析

Vibe Coding 的“恶果”来了！！

最近在升级 JClaude，发现 Tokens 消耗特猛，然后分析了代码，发现其中有一个代码文件已经快 10000 行了。

大概算了下，光这一个文件上下文就有十几万 Token 了！

虽然程序运行完全正常，但是技术债越来越重了，所以必须重构一下。

最近刚好在测试 Kimi K3，我就把这个任务交给它了！

这个测试应该比做一个动画效果来得更有实际意义吧。

下面就来看一下，它的重构过程，以及重构后的结果。

1、项目简介

先简单介绍一下这个项目的情况：

这是我之前做的 Claude Code 中文界面版，完全克隆了 Claude 桌面版的界面，然后调用 Claude Code 终端，自动接入第三方模型。也就是说第三方模型可以直接用 Anthropic 家最强编程智能体，不受账号限制。

当然，如果你接入了 Opus 4.8，那这个软件的能力基本上约等于 Anthropic 官方的 Claude 桌面版。

因为最近加入了这个角色和技能相关的功能，就发现这个项目文件已经膨胀到让人无法接受的程度了。

这个项目开始于一个简单的界面克隆测试，所以当时并没有在意代码结构的问题。然后在修改的过程中，也没有强制提出重构的需求，所以 AI 就一直在堆“屎山”！

我估计很多很多的 Vibe Coding 项目都会面临这样的问题。刚开始呢是试着玩玩的，玩得爽了，就越改越大。

2、基础情况

这个项目是Tauri+Rust开发的，安装包和很小，内存开销也很低，可以制作多平台的发行包。界面部分主要是JS+CSS+HTML等前端代码，界面效果可以做的很好，后端是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 type="module"> 不一定需要引入打包工具

它这里提到了很关键的一点，就是多人协作冲突是一个大问题。对我而言还好，我就是多 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 type="module"src="./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.js（2000 行以内）也完全可以接受——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 了，敬请期待！