春节期间，我花了四个小时，从零开始 Vibe Coding 了一个网络流量分析面板 
项目最初叫 Clash Master，用了一周后改名为 Neko Master。原因很简单：不想跟 Clash 这个名字绑定太死，后来支持了 Surge v5+，未来也可能接入更多网关类型。
Neko Master 是什么？
一个开源、自部署的网络流量分析面板。
- 多维流量统计（域名 / 节点 / 规则 / 地区等）
- 趋势分析
- 多后端支持（OpenClash / Mihomo / Surge）
- Docker 一键部署
- 移动端适配 + PWA
如果你家里也在用 OpenClash / Mihomo / Surge，欢迎体验。MIT 开源，欢迎 Star 和提 Issue。
- GitHub:
- 在线演示:
neko-master.is26.com（
密码: neko2026）
从最初的「玩具」到现在拥有复杂架构的项目，这篇文章算是对整个开发过程的一个回顾和总结，分享一些 Vibe Coding 的实战体感。 如果只看第一版，它其实不复杂；真正的复杂度，是上线后被真实流量和用户场景一点点逼出来的。
为什么会有这个项目
我是一个 Homelab 用户，家里跑了一堆服务，分流策略比较复杂，日常开发也会频繁切换 IP。
其实早在 2024 年初，我就折腾过一次流量监控方案：用 Grafana 和 Loki 配合 Clash Premium 的 Tracing API，弄了一个监控面板。当时发了条推，说「能看看自己的线路流量什么的，其实也没啥用」。
但用了一段时间后，发现 Grafana 这套东西虽然功能强大，但对于家庭用户来说门槛还是太高了。配置繁琐，界面也不够直观，更关键的是长得不好看。原生的 Clash 面板更多是「运行状态」展示，但我一直缺少一个更直观的视角去看：
流量到底在干什么？
- 哪些域名在吃带宽？
- 哪个节点负载更高？
- 深夜学习 AI 时到底哪个网站最耗流量？
- 当前的规则策略是否合理？
市面上除了 UniFi 之外，其他统计工具的界面确实有些一言难尽。与其在不同工具之间拼凑数据，不如自己做一个更好看、更好用的「流量感知」的面板。
一小时打造 MVP
2 月 5 日下午，我打开 
没有画原型图，没有写技术方案，就是在脑子里先搭了个大概框架，然后直接跟 AI 对话。一小时不到，MVP 就跑起来了：部署在内网，监听 OpenClash 流量，能看到域名统计、节点流量，数据还能持久化。
当天晚上又花了三个小时打磨了一下，凌晨四点半，第一版 Clash Master 就上线了。
这个项目发布不到 24 小时，就收获了 GitHub 400+ Star，Docker Hub 1000+ 次拉取。这就是 AI 时代的开发速度。
让 AI 审美在线
这次开发 Neko Master，听到最多的评价就是「好看」，甚至有人在 V2EX 专门发帖，问 Logo 是怎么做出来的。
Neko Master 整体的 UI 属于现代 SaaS 风格，我自己也挺满意的。后面我还专门发了一条推，聊「如何让 AI 审美在线」。
图一是当晚 Vibe 出来的第一版，图二是几天后的完全体。前者 AI 味浓浓，后者审美基本达到了 2026 年现代 App 的水准。
很多人吐槽 AI 生成的界面「千篇一律」，说实话第一版确实如此。分享一个我实践下来觉得很有效的技巧：
不要只用文字描述「给我写个好看的面板」。要给视觉锚点。
具体做法：去 Dribbble / Figma Community 搜「Dashboard」，挑一张看着舒服的截图直接喂给 AI，告诉它「复刻这个设计感」。配色、卡片阴影、数据可视化风格，都可以用截图来锚定。
有了参考系，AI 的审美直接从「程序员风」进化到「SaaS 级」。
一个我越来越确信的感受是：在 AI 时代，代码的门槛在下降，但审美判断依然是决定成品质量的关键因素。 AI 可以帮你写代码、做布局、调样式，但「好不好看」这件事，最终还是得靠人来判断。
AI 工具复盘
这个项目开发过程中，我把市面上主流的几个 AI 编码工具都用了个遍。直接说结论：
| 工具 | 角色 | 体感 |
|---|---|---|
| Kimi K2.5 | 早期主力 | 量大管饱，中文理解好，MVP 阶段 100% 主力，甚至没见过任何限额提示 |
| Claude Code (Opus 4.6) | 硬骨头 | 贵公子。一个复杂任务下去 4 小时限额 15 分钟直接见底，但遇到架构和性能深水区，只有它能啃 |
| CodeX (GPT 5.2/5.3) | 日常输出 | 5 小时循环用量非常扎实，开发过程基本碰不到小时限制的瓶颈，但周限量两天就用完了 |
| Gemini 3 Pro | 辅助 | 主要用来 Review 和写 Commit Message，质量偶尔掉线 |
一个真实体感：国产模型在初始化阶段已经足够高效，Kimi K2.5 是 Clash Master 诞生阶段的绝对主力。但当项目复杂度提升，面对数据库性能调优、架构重构这些深水区问题时，还是得靠 Claude Opus 4.6 和 CodeX 5.3 交叉 Debug。
一个额外体感是：模型不是越贵越好，关键看任务匹配。原型、重构、排障用的模型可以完全不一样。
Vibe Coding 的节奏：快速迭代与用户反馈
上线之后的两周，基本就是一个循环：发版 → 收反馈 → 修 Bug → 加功能 → 发版。 从 v1.0.2 到 v1.3.2，迭代了大约 20 个版本。
这个节奏下，AI 的角色不再是「帮我从零写一个功能」，而是变成了「帮我快速响应用户反馈」。 V2EX 上有人说磁盘 I/O 炸了，我把日志贴给 Claude，十五分钟定位到是 SQLite 单条写入没做批处理，连夜修了三个版本，I/O 从一天 200GB 降到了 1.6GB。Docker 镜像太大被吐槽，让 AI 帮我做多阶段构建，从 800MB 瘦到 300MB。
这个阶段的一个核心体感是：Vibe Coding 不只是「让 AI 写代码」，更是「让 AI 帮你加速整个反馈循环」。 用户提了个需求，你不需要花半天去查文档、写方案，直接跟 AI 说清楚上下文，几分钟就能拿到一个可用的 patch。这种响应速度，在开源项目的早期阶段是非常关键的——用户看到你迭代快，信任感就上来了。
技术细节
改名的同时做了一次比较大的架构升级，包括 Agent 分布式部署模式、ClickHouse 大规模分析后端等。 真正难的不是把面板做出来，而是让它在 NAS / 软路由这类资源受限环境里稳定跑起来。这里补几个最能体现复杂度的深水区问题。
1) 硬盘 I/O：从“硬盘灯常亮”到可持续运行
这个坑是最痛的一次。早期版本把每条流量记录都直接单条写入 SQLite，功能是对的，但在真实家庭网络里会触发严重写放大。用户反馈磁盘写入量吓人，我一看容器和主机监控，日写入量确实离谱。
核心问题不是 SQLite 本身，而是写入策略太“在线”了：高频事件 + 单条落盘 + 没有缓冲，I/O 自然爆炸。在 demo 阶段不明显，一上真实流量就暴露。后面连续几个版本做了三件事：
- 内存缓冲队列 + 批量落盘（30 秒 flush，达到阈值提前 flush）
- 先聚合再写入（热点统计先在内存合并，减少无意义小写入）
- 写入限流和背压（高峰期优先保系统稳定，不让磁盘被打穿）
结果非常直观：
v1.0.2 -> v1.0.7 -> v1.0.9
200GB -> 20GB -> 1.6GB / day
这次之后我基本确定了一件事：AI 能快速把“能跑”的代码给出来，但 I/O 模型、缓存策略、背压机制这些基本功，必须由人把关。
2) ClickHouse：不是“接上就快”，而是“建模正确才快”
单网关场景 SQLite 足够，但多 Agent、多网关以后，域名/IP 维度的数据量会迅速上涨，查询复杂度也跟着上来。尤其是 TopN、时间趋势、规则命中这类查询叠在一起时，读写压力会互相放大。ClickHouse 引入后，第一版也踩了典型坑：小批次高频写入导致 parts 激增，merge 压力上来后，查询延迟会抖动。
后面重点做了几层优化：
- 写入侧：统一批量写入窗口，避免 tiny insert 把 MergeTree 打碎
- 存储侧：按时间分区 + 按常用筛选维度排序，热点列做低基数字典化和压缩
- 查询侧：把仪表盘高频指标（Top 域名、节点趋势、规则命中）前置到预聚合层，接口优先读聚合结果
- 迁移侧：保留 SQLite + ClickHouse 双写，先灰度再切换，避免一次性迁移风险
这套优化做完后，收益不只是“更快”，而是“更稳”：高峰时段的查询波动明显下降，面板体验从偶发卡顿变成可预期的稳定响应。这也是项目从“能跑”走向“可维护”的分水岭。
3) AI 在深水区的正确使用姿势
深水区里，AI 最有效的用法不是“一次性生成”，而是进入工程化闭环：日志与指标 -> 假设 -> patch -> 压测/对比 -> 继续迭代。 我在这个项目里基本就是让 Kimi 快速铺功能，用 Claude/CodeX 啃性能和架构细节，然后自己做最终取舍。AI 把迭代速度拉高了，但稳定性边界和技术债优先级，还是得人来拍板。
如果你对完整架构感兴趣，GitHub 仓库里有完整的
写在最后
Vibe Coding 确实改变了我的开发方式，过去需要一两周的原型，现在几小时就能跑起来。但有一个东西 AI 替代不了：从「能跑」到「好用」的那段距离。
200GB 的写入 bug 是 AI 写的，但发现问题、定位瓶颈、设计缓存策略是人做的。界面从「AI 味」到「SaaS 级」，靠的不是更好的 prompt，而是你自己对美的判断。Agent 模式的架构设计，来自对真实部署场景的理解，不是 AI 能凭空想出来的。
Vibe Coding 降低了「从 0 到 1」的门槛，但「从 1 到 100」的路，依然需要经验、审美和对用户需求的理解。