2026-09-29 08:00:00
🤖 AI 摘要
文章围绕作者为满足 Netflix、TikTok、AI 工具和服务器互联等需求搭建的网络方案展开。作者认为测速截图不能代表真实可用性，因此将家庭网关、国内入口、深港专线、香港落地和不同地区出口拆分设计，通过分流规则让不同服务自动走合适线路。方案包含联通、电信两个家庭网络，CCN、CNIX、IEPL 三条深港线路，美国 CN2 GIA 直达，以及 Tailscale 内网管理。实测家到香港约 19ms，跨境单连接可达数百 Mbps，视频、AI 工具和服务器传输体验更稳定。文章还列出月均约 450 元的服务器与线路成本，并指出维护成本较高，IEPL 到期后计划不再续费。
经常有朋友问我，平时的网络是怎么搭的，怎么才能稳定、顺畅地用上各种 AI 工具。
我对网络一直比较挑剔。大学时期就开始折腾服务器，这些年各家云服务基本玩了个遍，目前手上还好多台服务器。
以前选机器，主要看价格和测速截图；现在更在意延迟、带宽和稳定性。家里怎么连云端，服务器之间怎么连，钱该花在哪一段，都得放在一整套网络里看。
昨晚把家里的网络、专线和全球节点梳理了一遍，连同这些年的一些思考，做成了一个网站：
拓扑图、实测数据、踩过的坑和费用明细都在里面。建议先看图，心里有个大概，下面再聊具体怎么用。
先说结论：这套方案不适合大多数普通用户，搭建和维护都挺费精力。
但如果你和我一样，既要「低延迟、高带宽、高稳定」，又不想每个月花太多钱，里面的一些思路应该能参考。跟之前写的装修网络、家庭弱电一样，这只是基于我自己需求的分享，大家按需取用。
我平时看 Netflix、刷 TikTok，每天还要大量用 AI 工具。看起来都是「上网」，要求其实各不一样：
所以测速截图好看，不代表好用。下载快但出口不对、能打开但用久了掉线，这两种线路都不少见。
我的做法是把这些差异交给网关的分流规则：不同服务走不同的线路和出口，打开就能用，不用手动切节点。再加上家里访问云服务器、服务器之间传文件，就慢慢攒出了下面这套配置。预算有限，能复用的机器和线路尽量复用。
我有两个家，一个联通，一个电信。两家的跨境表现差别很大，2024 年那篇套餐文章里我也吐槽过：同一台服务器，联通连着快，电信就未必，反过来也一样。所以没法靠一台服务器把两个家都搞定，只能分开配。
我在广东，最要紧的是家到香港这一段。国内访问本来就够用，香港往外也有不少选择，偏偏中间这段要是不稳，后面机器买得再好也白搭。
主要路径是：家里网关 → 国内入口 → 深港专线 → 香港落地 → 不同地区的出口。
深港这段目前有 CCN、CNIX、IEPL 三条线，主要汇到同一台香港机器，再按需求分到不同出口；美国另外留了一条 CN2 GIA 直达。每台机器怎么连、负责什么，看网站的拓扑图更直观。
拆成几段的好处是改起来方便：家到香港有问题，就只动这一段；哪个地区的出口不行，就换那个出口，其他部分不用跟着改。
出门在外也沿用这一套：手机先连回家，按家里的规则走；回家的路不好走，还有云端入口兜底。服务器之间用 Tailscale 组内网，管理面板只在内网里访问。
每台机器的分工，写在后面的费用表里。
一句话：快，而且省心。
先看数字。网站里 9 月 29 日中午的记录：家到香港延迟约 19ms；电信走 CCN 单连接能跑到 400 Mbps 左右，联通大概 300–370 Mbps。对家宽跨境来说，这个成绩我挺满意。
看视频感受最明显。YouTube、Netflix 高清基本不缓冲，TikTok、Netflix 的地区限制也有对应的出口处理。想看什么直接打开，不用先想这次该切哪个节点。
AI 工具也一样。我现在每天大量时间花在 AI 上，聊天、写代码、跑任务，打开就能干活，少了断线、来回切节点、思路被打断的麻烦。天天要用的东西，这点钱花得值。
还有几台云服务器。除了从家里访问，服务器之间也经常互传文件，这部分同样按目的地分了路径，能少绕的路尽量少绕。
各条线路的测速和调整过程都留在了网站上，以后换机器、换线路可以拿来对比。
年付、季付和多年付统一折成月费，人民币和美元分开算：
| 服务器 / 线路 | 计费方式 | 人民币 / 月 | 美元 / 月 |
|---|---|---|---|
| 阿里云广州（国内分流、ESA 前置） | 月付 ¥45 | ¥45 | — |
| 腾讯云 Lighthouse 广州（CNIX 入口、CCN 前置） | 月付 ¥45 | ¥45 | — |
| YT · CNIX 深港 IPLC 专线 | 月付 ¥61 | ¥61 | — |
| po0 广州 BGP · CCN（入口及专线段） | 年付 ¥1,953 | ¥162.75 | — |
| RFC 香港（CCN 中继、热备落地） | 年付 ¥270 | ¥22.50 | — |
| BAGE 香港（三条专线统一落地） | 季付 $9 | — | $3 |
| 阿里云 CDT 香港（2000M 直连） | 抢占式，约 $2 / 月 | — | $2 |
| DMIT 洛杉矶（CN2 GIA 前置） | 月付 $10.90 | — | $10.90 |
| tzulo 圣何塞 / Green（中继、DERP、备份） | 3 年 $45 | — | $1.25 |
| OwO 圣何塞 / SJC（主应用机） | 免费 | — | $0 |
| 合计 | ¥336.25 | $17.15 |
算下来，服务器和线路每个月大概 450 元（美元按 6.7 折算）。有几台是从朋友那儿或者其他渠道拿到的，不花钱，能省则省。
注意：这里只算了表里这 10 项，不含家庭宽带、硬件和 AI 订阅；东京、新加坡的出口没单独列价，快到期的 IEPL 也没算进去。
值不值，看用得多不多。像我这种每天靠它干活、自己又爱折腾的，愿意花；如果只是偶尔用下 AI，真没必要上来就搞这么一套。
钱之外还有时间成本：线路调整、服务器续费、检查备用链路，都得自己盯着。
所以我也在做减法。CCN 现在已经能顶上 IEPL 的主要用途，IEPL 2026 年 10 月 29 日到期后就不续了。这部分还在收尾，后面有变化会更新到网站。
这篇更多是给自己留个记录。这套网络是按手上现有的资源和日常需求一点点调出来的，具体哪台机器、哪条线路没必要照搬，每一段为什么这么选，可能更有参考价值。
这次调整，服务器的运维、安全加固和网络优化，基本都是我配合 Claude Code 和 Codex 一起做的：我把现有的机器、线路和遇到的问题讲清楚，它们负责分析、出方案、执行配置，我来看结果、做取舍。以前要查半天资料、手敲一堆命令的事，现在快了很多。
网站我会继续更新，方便自己回头查，也给同样爱折腾的朋友留个参考。
2026-09-28 08:00:00
我在2015、2017、2020，2023 年别写了 4 篇有关「云账单」的文章，记录我在各种云服务、订阅上所花的钱。
2026 年的今天，我的云账单，相比前些年，变化颇大。一方便随着 AI 的落地， Tokens 成为大头，另外也有大量的应用由于 AI 的落地而被替代。
很久没有手写博客了，今天这篇文章，使用键盘重新梳理一下这两年的云账单，也算是一个总结和回顾。
2026-03-10 08:00:00
🤖 AI 摘要
文章源于作者将博客从 VitePress 迁移到 Cloudflare 刚发布的 Vinext 框架，在技术迁站过程中顺势做了两件事：一是让 AI 以第三者视角撰写「AI 视角下的罗磊」页面，二是构建可对话的 AI 分身，回答关于「我是谁」的问题。通过把十多年分散在文章、动态、视频、开源项目中的内容喂给 AI，作者第一次感到这些碎片被重新组织成一个更完整的自我画像，同时也意识到 AI 抓到的是「愿意公开表达的那部分自己」。文章刻意不再展开技术细节，而是提出「人生 AI」作为继「人生马拉松」之后的新长期计划：不再只关注持续产出新内容，而是利用 AI 将既有创作沉淀为有结构、可成长、可迭代的数字分身。作者指出当前存在准确性不足、人格相似却不完全契合等问题，并延伸到隐私、边界与心理接受度的开放讨论，期待在未来几年持续优化分身、丰富数据，并观察这一项目对个人创作与表达的长期影响。
前几天我做了一件挺有意思的事。
Cloudflare 刚发布了 Vinext 这个框架，我也在第一时间把自己的博客，从原本的 VitePress 迁移到了新的架构上。迁站本来只是个工程活，结果做着做着，我顺手把自己也「迁」进了 AI 里。
上一篇文章 《2026 年，我把自己做成了一个 AI》 已经把这个 AI 分身的原理、架构和技术细节写得比较完整了。这篇不再重复讲怎么做，主要补一下这次视频背后的想法：为什么我想开启一个新的长期项目，叫「人生 AI」。
luolei @luoleiorg · 2026年3月10日
过去 10 年，我给自己设了个「人生马拉松」计划：每年至少一场全马 🏃♂️，今年刚好 10 场。
现在准备开启另一个长期项目「人生 AI」：持续迭代我的 AI 分身 🤖，也顺手记录这波 AI 浪潮的技术演进。
拍了个视频，记录这次有趣的尝试👇
https://t.co/T71sbDwvKZ
过去 10 年，我给自己设了一个「人生马拉松」计划：每年至少跑一场全程马拉松。今年刚好第 10 场。
这个计划对我来说，不只是跑步本身。它更像一个提醒：如果把时间拉长，坚持做一件事，很多变化都会慢慢显现出来。
现在我想再给自己开启另一个长期项目，叫「人生 AI」。
它不是一个为了追热点做出来的一次性 Demo，也不是拍完这个视频就结束了。恰恰相反，我希望它变成一个会持续很多年的东西：一边迭代我的 AI 分身，一边记录这波 AI 浪潮对内容创作、个人表达和独立开发的影响。
迁移博客的过程中，我顺手做了两个小实验。
一个是做了 「AI 视角下的罗磊」 这个页面，让 AI 用第三方视角重新看我一次。
另一个，是做了一个可以直接聊天的 AI 罗磊，让它去回答别人关于「我是谁」的问题。
这两件事表面上是在折腾 AI，实际上更像是在重新整理过去十多年的自己。
平时写文章、发动态、拍视频、开源项目，这些内容都是一篇篇、一条条地散落在各个平台上。它们当然都属于「我」，但大多数时候，它们彼此之间并没有真正被串起来。
这次我第一次比较强烈地感觉到，AI 有机会把这些长期积累下来的碎片，重新组织成一个更完整的东西。
看 AI 怎么「理解」自己，其实还挺微妙的。有些地方会觉得它说得挺准，有些地方又会觉得「这也太像一个整理过后的我了」。它抓到的是我这些年愿意公开表达的那一部分，而不是全部的我。
但也正因为这样，它才让我意识到，长期创作这件事，在 AI 时代可能会多出一层新的意义。
你写过的东西、说过的话、公开留下来的痕迹，不再只是过去完成过的一次表达，它们还可能在未来继续被整理、被关联、被重新理解。
关于这个 AI 数字分身背后的原理和架构，我已经专门写了一篇技术向的文章，源码也公开在了自己的 GitHub 上。感兴趣的话，可以去读一读。
这篇我更想记下的是另一个感受：对于一个持续写作、拍视频、发动态很多年的人来说，AI 的意义可能不只是「帮你生成内容」，而是帮你重新整理自己。
以前我会觉得，内容创作者最重要的事情，就是持续生产新的内容。
现在我会觉得，未来可能还要多做一件事情：把自己过去积累的内容，慢慢整理成一个有结构的东西。
这也是我想做「人生 AI」的原因。
我想看看，一个长期创作者在 AI 时代，能不能不只是持续输出内容，还能慢慢把自己的内容沉淀成一个会成长、会迭代的长期项目。
不过这个项目现在也远远谈不上成熟。
第一个问题是，它现在还不够准。
有些时候它回答得还不错，有些时候又会显得有点「像我，但又没那么像我」。内容越多，想让它理解得更稳定、更准确，反而越不是一件简单的事情。
这也是我接下来最想继续打磨的一块。如果你对这种方向有一些想法，也欢迎和我交流。
第二个问题则更开放一些。
像我这种在网上公开输出很多年的人，对把自己的公开资料交给 AI 分析，整体上是比较开放的。因为这些内容本来就已经公开存在了，AI 只是换一种方式把它们重新组织起来。
但这不代表所有人都会接受这件事。
如果是你，你会愿意让 AI 系统地分析自己吗？愿意把自己的文章、动态、照片、视频，逐步整理成一个可以被提问的数字分身吗？
这背后既有技术问题，也有边界、隐私和心理感受的问题，我觉得都挺值得讨论。
对我来说，这次视频不是一个结论，更像是一个开始。
「人生马拉松」我已经跑到第 10 场了，而「人生 AI」才刚刚起跑。后面我会继续往里面加更多数据，继续优化这个 AI 分身，也继续记录这个过程本身。
看看几年之后回头再看，这会不会成为我这十年里，另一个有意思的长期项目。
2026-03-03 08:00:00
🤖 AI 摘要
文章以作者长期在博客、社交媒体、GitHub 等平台留下的大量内容为背景，提出在生成式 AI 时代主动构建个人知识结构的重要性。作者首先在 /about 页让 6 个不同大模型基于 11 万字上下文与结构化摘要，生成第三方视角的作者画像，并通过多模型对比提升可信度。随后，他构建了可在博客内直接聊天的「AI 罗磊」，技术栈包括基于 Cloudflare Workers 的 Vinext、Vercel AI SDK、OpenAI Compatible API 接入多家模型、自研搜索/RAG 核心、IP 级限流和 Telegram Bot 监控。系统流程涵盖追问检测与意图判定、缓存复用、本地倒排索引搜索与分数加权、AI 关键词提取与停用词过滤、意图重排、多层 System Prompt 设计、流式生成与截断修复，以及全链路 Token 与耗时追踪。为抑制幻觉，作者设计了来源限制、数字协议、履历协议和链接协议等严格规则，确保回答有据可依。文末作者反思 AI 分身与真实自我的偏差，并展望接入视频内容、降低对单一 API 依赖，强调个人应主动把分散内容结构化为可对话的知识系统，让 AI 成为自我延伸。
我在互联网上留下痕迹，比写代码还早。
大学时代就开始折腾博客、刷微博、玩人人网，那时候还没入行做程序员，纯粹就是一个爱在网上表达的人。后面这十几年，从最开始的切图仔，到后来资深前端开发，再到现在的 AI 驱动的全栈开发，有了技术加持，输出变得更加系统化。到今天，luolei.org 上已经有 300 多篇文章。
除了博客，还有 YouTube 和 B 站 的 ZUOLUOTV 视频频道、X/Twitter 上的 @luoleiorg、十几年前的微博和人人网、Unsplash 上累计超过 1500 万浏览的摄影作品、GitHub 上的开源项目。
这些内容散落在互联网的各个角落，涵盖了技术、摄影、旅行、跑步、数码产品、生活方式等话题。如果有人想快速了解「罗磊是谁」，他需要翻好几个平台、读上几十篇文章，才能拼凑出一个大概的印象。
2024 年至今，我全身心投入独立开发，拥抱 AI-first 的 Vibe Coding 工作流。在这个过程中，一个想法越来越清晰：
在生成式 AI 时代，你的内容一定会被 AI 读取。但 AI 是否能完整地理解你，取决于你是否主动构建自己的知识结构。
被动被爬虫抓取，和主动建立语义索引，是两回事。让 AI 理解你，本质是在拿回对自己内容的解释权。
于是我决定在博客上做两件事：让多个 AI 模型以第三方视角写出「AI 眼中的罗磊」，以及基于我多年的多平台内容构建 RAG 知识库，做一个可以直接聊天的「AI 罗磊」。
打开 luolei.org/about，你会看到一个和传统「关于我」页面完全不同的东西。
这个页面不是我自己写的自我介绍，而是由 6 个不同的 AI 模型（GPT-5.2、Gemini 3、Qwen 3.5 Plus、Kimi K2.5、豆包 Seed 2.0、GLM 5.0）分别阅读我的博客文章、X 动态和 GitHub 履历后，各自生成的第三方视角作者画像。
同一份数据，不同模型，像 6 个旁观者各自写出对同一个人的理解。
这次 AI 分身主要围绕三类数据进行分析：
说实话，这只是我在网上留下的数据的一小部分。我在 YouTube 和 B 站上有大量视频内容，十几年前的微博和人人网上也有不少早期的文字记录。但这些平台的数据抓取非常麻烦——视频需要先转文字再分析，国内社交平台的 API 要么不开放、要么限制很多，和 Twitter 的官方 API 体验完全不在一个级别。
即使是 Twitter API，成本也不低。所以我做了本地缓存策略，抓取一次后存到 JSON 文件里，避免重复调用。
这三类数据汇总后，光是 Context JSON 就有大概 11 万字。把这么大的数据量一次性丢给 AI 分析，直接暴露了当前大模型的能力边界。
实测下来，6 个模型中只有 Qwen 和 Gemini 3 能稳定处理这个量级的上下文。其他几家要么超时、要么输出质量严重下降，甚至直接报错。最后我做了一轮 AI 预处理——先用模型对每篇文章生成摘要和关键要点，再把压缩后的结构化数据丢给各个模型生成画像，才解决了这个问题。
这是当前 AI 能力的一个现实限制。但可以想象的是，随着大模型的上下文窗口持续扩大，未来普通用户也能轻松处理几十万字的长文分析。到那时候，做这种个人知识系统的门槛会低很多。
6 个模型使用统一的 System Prompt，要求以第三方视角生成结构化 JSON 报告，包括身份标签、能力维度、做事风格、代表作品等。Prompt 中有严格约束：语气客观克制，结论必须有数据支撑，不能编造，不能夸大。
前端支持在不同模型视角之间切换，每个画像底部标注了生成模型、时间和数据来源，保持透明。
为什么让多个 AI 来写？一个 AI 的输出可能有偏差，但当多个不同架构、不同训练数据的模型都指向类似的结论时，可信度就高了不少。同时不同模型的表达差异，本身就挺有意思——有的模型更关注技术能力，有的更关注内容创作，有的会注意到生活方式这条线。
/about 页面解决的是「快速了解我」的问题。但如果读者想深入聊一个具体话题——比如「你用什么设备拍照」「你跑过哪些马拉松」「推荐几篇关于 Homelab 的文章」——一个静态画像页面就不够了。
于是我做了第二个功能：直接在博客和 AI 版本的我聊天。
ai + @ai-sdk/react + @ai-sdk/openai-compatible）@luoleiorg/search-core 包，基于关键词匹配 + 权重评分 + 意图重排当读者在聊天框输入一条消息，系统的处理链路如下：
1. 搜索上下文复用判断
系统会缓存每轮对话的搜索上下文（10 分钟有效期）。如果是追问（比如先问「你跑过马拉松吗」，再问「成绩怎么样」），会通过以下步骤判断是否复用：
2. 并行搜索与关键词提取
如果不复用缓存，系统会同时启动两个并行任务：
本地搜索（即时）：基于 @luoleiorg/search-core 倒排索引，使用 Intl.Segmenter 进行中文分词，并做 CJK 字符拼接修复（比如把「马拉」+「松」识别为「马拉松」）。搜索算法使用加权评分：
深度内容提取：对于匹配度最高的文章（分数 ≥8 且显著领先第二名），会额外提取前 1500 字符的完整内容，让 AI 能回答更细节的问题。
AI 关键词提取（异步并行）：如果是多轮对话且本地关键词不足 3 个，会调用 AI 从对话上下文中提取更精准的搜索关键词（3.5 秒超时，48 token 输出上限）。提取后会过滤 70+ 个中文停用词。如果 AI 提取的关键词与本地分词结果不同，会用新关键词再次搜索。
最终返回 6 篇最相关的博客文章 + 6 条最相关的 X 动态。
3. 意图重排
系统定义了 5 类意图分类：
根据用户查询内容识别意图后，对检索到的文章进行重排，按意图相关度评分：
这样可以优先展示最相关领域的内容。
4. 分层 Prompt 构建
System Prompt 分为三层：
这种分层设计让提示词维护更清晰，也方便调整规则而不影响其他部分。
5. 流式生成与修复
AI 以 Streaming 方式逐字输出（temperature=0.3，max_tokens=2000）。如果检测到响应截断（以悬停标点结尾、Markdown 不平衡、句子不完整等），会触发一次轻量级修复调用（2.5 秒超时，80 token 上限），只补全最后一句，然后无缝拼接。
6. 全链路追踪
每轮对话结束后，Telegram Bot 会发送详细通知，包括：
做 AI 数字分身最大的挑战不是「让它说话」，而是「让它不乱说」。
大语言模型天生倾向于「编出一个看起来合理的答案」。如果有人问「你有没有去过冰岛」，一个没有约束的模型可能会非常自信地说「有啊，我 2022 年去过」，哪怕我压根没去过。
所以在系统提示词中，我设置了最高优先级的反幻觉规则：
[文字](URL)，严禁裸输出 URL这些规则配合 RAG 检索，让 AI 的回答始终有据可查。搜不到就坦诚说没有，比编一个像模像样的假答案好一百倍。
聊天界面的一些设计：移动端全屏、桌面端居中弹窗；键盘 Enter 全局唤起；消息气泡区分用户和 AI，AI 头像带「AI」标识；3 秒发送冷却防误触；预设引导语轮播帮助用户开启话题。
当 AI 回复中引用 X/Twitter 动态时，前端会自动渲染成带有作者头像、互动数据的卡片，点击可展开查看完整推文。
每一次对话都会通过 Telegram Bot 通知到我手机，我能实时看到有多少人在和「AI 罗磊」聊天，聊了什么话题，引用了哪些文章，以及系统在各阶段花了多少时间、消耗了多少 Token。
和自己的 AI 分身聊天，感觉挺奇妙的。
它知道我 2014 年跑了上海马拉松，知道我用 Cloudflare Workers 部署项目，知道我在 2016 年写过一篇关于信息自由的文章。它能推荐我写过的文章，能聊我的技术栈，能说出我用什么相机。
但它不是我。
这个 AI 版的罗磊，是基于我公开发布的内容训练出来的。公开内容天然有筛选和表达倾向——我在博客里写的是我愿意分享的部分，X 上发的是我想表达的观点，GitHub 上展示的是我选择开源的项目。那些没写出来的犹豫、没发出去的想法、生活中琐碎但真实的部分，AI 一无所知。
所以这个数字分身呈现出来的形象，一定和我真人的性格有差异。它可能显得比我更自信、更系统化、更「有条理」，因为发布出来的内容本身就经过了思考和整理。真实的我，可能比它犹豫得多，也随意得多。
这种偏差其实挺值得思考的。我们每个人在互联网上呈现的形象，本来就是真实自我的一个投影。AI 读取的是投影，重建的也是投影。它理解的是那个「在线的罗磊」，而不是完整的罗磊。
做这个东西有点像养成游戏。
目前它的知识库还只覆盖了博客、推文和 GitHub。接下来我打算把 YouTube 和 B 站上的所有视频都处理一遍——先转成文字，再做分析和索引，然后继续「投喂」给这个系统。数据越多，它对我的理解就越完整。
不过说实话，我也有一些隐忧。
目前整个系统的 AI 能力依赖于大厂的 API 服务——通义千问、OpenAI、Gemini，数据传输到他们的服务器上处理。因为我喂给它的都是公开数据，所以隐私问题暂时不太担心。但如果未来想把更私密的内容也纳入进来，就需要认真考虑数据安全了。
另一个风险是依赖性。当你把自己的知识体系建立在第三方服务之上，一旦 API 涨价、服务下线、或者政策变化，整个系统就可能受到影响。这也是为什么我选择了 OpenAI Compatible 的接口标准——至少在模型层可以随时切换，不被单一供应商锁定。
回到最开始的那个观点：在这个时代，主动构建自己的知识结构，远比被动等待 AI 来理解你更重要。
我的博客、推文、视频、代码，如果只是散落在互联网各处，它们就只是搜索引擎里的一条条索引。但当我主动把它们结构化、建立语义关联之后，它们变成了一个可以对话的知识体。
可以想象的是，随着 AI 大模型能力的持续增强，以后的上下文窗口会越来越大，多模态处理会越来越成熟。到那时候，做一个自己的 AI 分身，可能就像今天搭建一个博客一样简单。
这也许就是个人内容创作者在 AI 时代的一种可能性：不只是生产内容，而是构建自己的知识系统。让 AI 成为你的延伸，而不只是替代。
2026-03-01 08:00:00
🤖 AI 摘要
文章围绕开源自部署网络流量分析面板 Neko Master 的诞生与演进展开。作者作为 Homelab 用户，希望获得比 Clash 面板和 Grafana+Loki 更直观、美观的“流量感知”视角，于是在春节期间通过 Kimi K2.5 等模型进行 Vibe Coding，一小时内完成接入 OpenClash 的 MVP，并在四小时内上线首版，迅速获得 GitHub 与 Docker 的关注。后续项目从玩具版走向复杂架构，重点解决家庭 NAS/软路由环境下的稳定性与性能问题，包括：通过内存缓冲队列、批量写入、先聚合再写和写入限流，将 SQLite 导致的日写入量从 200GB 降到 1.6GB；在多 Agent、多网关场景下引入 ClickHouse，通过批量写入窗口、按时间分区与排序键建模、预聚合高频指标等手段，提升查询稳定性与响应时间。文章系统复盘了 Kimi、Claude Opus、CodeX、Gemini 在原型搭建、性能调优、架构重构中的分工，并强调“给 AI 视觉锚点”来提升 UI 审美效果。作者总结，Vibe Coding 极大压缩了从 0 到 1 的时间，但从 1 到 100 仍依赖人类对性能、架构、审美和用户需求的判断。
春节期间，我花了四个小时，从零开始 Vibe Coding 了一个网络流量分析面板 Neko Master，当天就上线了第一版。项目上线一周，GitHub 收获了 1000+ Star，Docker Pull 破了 10K。
项目最初叫 Clash Master，用了一周后改名为 Neko Master。原因很简单：不想跟 Clash 这个名字绑定太死，后来支持了 Surge v5+，未来也可能接入更多网关类型。
一个开源、自部署的网络流量分析面板。
如果你家里也在用 OpenClash / Mihomo / Surge，欢迎体验。MIT 开源，欢迎 Star 和提 Issue。
密码: neko2026）从最初的「玩具」到现在拥有复杂架构的项目，这篇文章算是对整个开发过程的一个回顾和总结，分享一些 Vibe Coding 的实战体感。 如果只看第一版，它其实不复杂；真正的复杂度，是上线后被真实流量和用户场景一点点逼出来的。
我是一个 Homelab 用户，家里跑了一堆服务，分流策略比较复杂，日常开发也会频繁切换 IP。
其实早在 2024 年初，我就折腾过一次流量监控方案：用 Grafana 和 Loki 配合 Clash Premium 的 Tracing API，弄了一个监控面板。当时发了条推，说「能看看自己的线路流量什么的，其实也没啥用」。
luolei @luoleiorg · 2024年1月7日
用 Grafana 和 Loki，配合 Clash Premium 的 Tracing API，弄了一个 Clash 监控面板，能看看自己的线路流量什么的，其实也没啥用。 https://t.co/YhrjvpspIe https://t.co/3huqYdmg4r
但用了一段时间后，发现 Grafana 这套东西虽然功能强大，但对于家庭用户来说门槛还是太高了。配置繁琐，界面也不够直观，更关键的是长得不好看。原生的 Clash 面板更多是「运行状态」展示，但我一直缺少一个更直观的视角去看：
流量到底在干什么？
市面上除了 UniFi 之外，其他统计工具的界面确实有些一言难尽。与其在不同工具之间拼凑数据，不如自己做一个更好看、更好用的「流量感知」的面板。
2 月 5 日下午，我打开 Kimi Code，使用最新的 K2.5 模型，开始 Vibe Coding。
没有画原型图，没有写技术方案，就是在脑子里先搭了个大概框架，然后直接跟 AI 对话。一小时不到，MVP 就跑起来了：部署在内网，监听 OpenClash 流量，能看到域名统计、节点流量，数据还能持久化。
luolei @luoleiorg · 2026年2月5日
我又来吹 Kimi K2.5 了。刚花一小时 Vibe 了一个 Clash 流量分析工具，完成度极高。部署在内网，监听 OpenClash 流量，实现域名、节点流量统计及 IP 归属地查询，数据持久化。我家的网络分流策略比较复杂，一直想找个工具感知流量状况，毕竟市面上除了 UniFi，其他统计工具的界面确实有些一言难尽。 https://t.co/RoLJbkaP53
当天晚上又花了三个小时打磨了一下，凌晨四点半，第一版 Clash Master 就上线了。
这个项目发布不到 24 小时，就收获了 GitHub 400+ Star，Docker Hub 1000+ 次拉取。这就是 AI 时代的开发速度。
这次开发 Neko Master，听到最多的评价就是「好看」，甚至有人在 V2EX 专门发帖，问 Logo 是怎么做出来的。问与答:《想问一下这种 logo 是怎么做的》
Neko Master 整体的 UI 属于现代 SaaS 风格，我自己也挺满意的。后面我还专门发了一条推，聊「如何让 AI 审美在线」。
luolei @luoleiorg · 2026年2月6日
昨晚随手 Vibe 的一个项目 Clash Master，不到 24 小时，收获 GitHub 400+ Star，Docker Hub 1000+ 次拉取。
图 1 是昨晚 Vibe Coding 的第一版，图 2 是现在的完全体。 前者 AI 味浓浓，后者审美基本达到 2026 年现代 App 的水准了。这就是 AI 时代的开发速度。⚡️
💡 分享一个 Vibe Coding https://t.co/9E1GM32EDZ
图一是当晚 Vibe 出来的第一版，图二是几天后的完全体。前者 AI 味浓浓，后者审美基本达到了 2026 年现代 App 的水准。
很多人吐槽 AI 生成的界面「千篇一律」，说实话第一版确实如此。分享一个我实践下来觉得很有效的技巧：
不要只用文字描述「给我写个好看的面板」。要给视觉锚点。
具体做法：去 Dribbble / Figma Community 搜「Dashboard」，挑一张看着舒服的截图直接喂给 AI，告诉它「复刻这个设计感」。配色、卡片阴影、数据可视化风格，都可以用截图来锚定。
有了参考系，AI 的审美直接从「程序员风」进化到「SaaS 级」。
一个我越来越确信的感受是：在 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。
一个额外体感是：模型不是越贵越好，关键看任务匹配。原型、重构、排障用的模型可以完全不一样。
上线之后的两周，基本就是一个循环：发版 → 收反馈 → 修 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 / 软路由这类资源受限环境里稳定跑起来。这里补几个最能体现复杂度的深水区问题。
这个坑是最痛的一次。早期版本把每条流量记录都直接单条写入 SQLite，功能是对的，但在真实家庭网络里会触发严重写放大。用户反馈磁盘写入量吓人，我一看容器和主机监控，日写入量确实离谱。
核心问题不是 SQLite 本身，而是写入策略太“在线”了：高频事件 + 单条落盘 + 没有缓冲，I/O 自然爆炸。在 demo 阶段不明显，一上真实流量就暴露。后面连续几个版本做了三件事：
结果非常直观：
v1.0.2 -> v1.0.7 -> v1.0.9
200GB -> 20GB -> 1.6GB / day
这次之后我基本确定了一件事：AI 能快速把“能跑”的代码给出来，但 I/O 模型、缓存策略、背压机制这些基本功，必须由人把关。
单网关场景 SQLite 足够，但多 Agent、多网关以后，域名/IP 维度的数据量会迅速上涨，查询复杂度也跟着上来。尤其是 TopN、时间趋势、规则命中这类查询叠在一起时，读写压力会互相放大。ClickHouse 引入后，第一版也踩了典型坑：小批次高频写入导致 parts 激增，merge 压力上来后，查询延迟会抖动。
后面重点做了几层优化：
这套优化做完后，收益不只是“更快”，而是“更稳”：高峰时段的查询波动明显下降，面板体验从偶发卡顿变成可预期的稳定响应。这也是项目从“能跑”走向“可维护”的分水岭。
深水区里，AI 最有效的用法不是“一次性生成”，而是进入工程化闭环：日志与指标 -> 假设 -> patch -> 压测/对比 -> 继续迭代。 我在这个项目里基本就是让 Kimi 快速铺功能，用 Claude/CodeX 啃性能和架构细节，然后自己做最终取舍。AI 把迭代速度拉高了，但稳定性边界和技术债优先级，还是得人来拍板。
如果你对完整架构感兴趣，GitHub 仓库里有完整的架构文档和部署说明。
Vibe Coding 确实改变了我的开发方式，过去需要一两周的原型，现在几小时就能跑起来。但有一个东西 AI 替代不了：从「能跑」到「好用」的那段距离。
200GB 的写入 bug 是 AI 写的，但发现问题、定位瓶颈、设计缓存策略是人做的。界面从「AI 味」到「SaaS 级」，靠的不是更好的 prompt，而是你自己对美的判断。Agent 模式的架构设计，来自对真实部署场景的理解，不是 AI 能凭空想出来的。
Vibe Coding 降低了「从 0 到 1」的门槛，但「从 1 到 100」的路，依然需要经验、审美和对用户需求的理解。
2026-02-04 08:00:00
🤖 AI 摘要
文章开头指出近两年 AI 技术和产品高速发展，中国本土大模型已处于世界前列，但在实际使用全球优秀 AI 服务时，许多用户仍面临各种门槛与限制。作者以资深开发者身份，自述曾通过 Vibe Coding 上架商业应用，亲身感受到“数字基建”在 AI 时代已经成为新的生产力基础。基于这一体会，作者提出将分享自己为未来准备的 4 个“数字通行证”，意在从基础设施或账号、工具层面，为读者提供更完善的数字环境配置思路，以便更顺畅地接入海外与本土的 AI 产品和服务，从而提升个人在 AI 时代的学习、创作与工作效率，逐步实现所谓的“AI 自由”。文末通过外链视频与推文卡片扩展内容，方便读者进一步了解细节与实践路径。
过去的两年， AI 日新月异，很幸运我们很多国产大模型和产品都已经站在了世界前沿 🚀。但不可否认，在探索全球优秀 AI 产品和服务时，依旧有很多朋友被挡在了门外。 作为一名资深开发者，去年我靠 Vibe Coding 上架了一个商业应用。
深感在 AI 时代，数字基建就是我们的生产力。今天分享 4 个我的数字通行证，希望大家都能实现 AI 自由。
luolei @luoleiorg · 2026年2月4日
https://t.co/Ik3xItwco9
过去这两年， AI 日新月异，但现实是，依旧有很多朋友，由于信息差、单向或者双向的门槛，被挡在世界上最先进的 AI 门外。拍了一个视频，分享 4 个让我无障碍使用全球 AI 的数字通行证，希望大家都能在 2026 年实现 AI 自由。🚀
