MoreRSS

site iconLuoLei | 罗磊修改

Front-End Developer @ YueWen , Weekend Photographer, YouTuber
请复制 RSS 到你的阅读器,或快速订阅到 :

Inoreader Feedly Follow Feedbin Local Reader

LuoLei | 罗磊的 RSS 预览

开启我的「人生 AI」计划

2026-03-10 08:00:00

🤖 AI 摘要

作者在完成第10场人生马拉松之际,开启新的长期计划「人生 AI」。该项目源于博客从VitePress迁移到Cloudflare Vinext框架过程中的两个实验:一是创建「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

🐦 在 X (Twitter) 上查看原文 →

从「人生马拉松」到「人生 AI」

过去 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 年,我把自己做成了一个 AI

2026-03-03 08:00:00

🤖 AI 摘要

本文记录作者罗磊将个人十年互联网痕迹转化为AI数字分身的完整实践。核心包含两部分:一是让6个主流大模型(GPT-5.2、Gemini 3等)基于11万字结构化数据生成第三方视角作者画像;二是搭建支持实时对话的RAG聊天系统,采用Vinext框架、自研搜索核心与Vercel AI SDK,实现追问检测、并行搜索、意图重排、分层Prompt及反幻觉协议等技术细节。作者反思了公开数据训练的AI分身与真实自我的偏差,并讨论了API依赖、数据安全等长期风险,最终提出"主动构建知识结构优于被动等待AI理解"的核心观点。

起因

我在互联网上留下痕迹,比写代码还早。

大学时代就开始折腾博客、刷微博、玩人人网,那时候还没入行做程序员,纯粹就是一个爱在网上表达的人。后面这十几年,从最开始的切图仔,到后来资深前端开发,再到现在的 AI 驱动的全栈开发,有了技术加持,输出变得更加系统化。到今天,luolei.org 上已经有 300 多篇文章。

除了博客,还有 YouTubeB 站 的 ZUOLUOTV 视频频道、X/Twitter 上的 @luoleiorg、十几年前的微博和人人网、Unsplash 上累计超过 1500 万浏览的摄影作品、GitHub 上的开源项目。

这些内容散落在互联网的各个角落,涵盖了技术、摄影、旅行、跑步、数码产品、生活方式等话题。如果有人想快速了解「罗磊是谁」,他需要翻好几个平台、读上几十篇文章,才能拼凑出一个大概的印象。

2024 年至今,我全身心投入独立开发,拥抱 AI-first 的 Vibe Coding 工作流。在这个过程中,一个想法越来越清晰:

在生成式 AI 时代,你的内容一定会被 AI 读取。但 AI 是否能完整地理解你,取决于你是否主动构建自己的知识结构。

被动被爬虫抓取,和主动建立语义索引,是两回事。让 AI 理解你,本质是在拿回对自己内容的解释权。

于是我决定在博客上做两件事:让多个 AI 模型以第三方视角写出「AI 眼中的罗磊」,以及基于我多年的多平台内容构建 RAG 知识库,做一个可以直接聊天的「AI 罗磊」。

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 分身主要围绕三类数据进行分析:

  • 博客文章:300+ 篇 Markdown 文件,每篇都经过 AI 预处理生成结构化摘要(含一句话摘要、详细摘要、3-6 条关键要点、SEO 关键词)
  • X/Twitter 动态:通过官方 API 抓取,按互动量排序取最有代表性的内容
  • GitHub 履历:项目信息、工作经历、技术栈

说实话,这只是我在网上留下的数据的一小部分。我在 YouTube 和 B 站上有大量视频内容,十几年前的微博和人人网上也有不少早期的文字记录。但这些平台的数据抓取非常麻烦——视频需要先转文字再分析,国内社交平台的 API 要么不开放、要么限制很多,和 Twitter 的官方 API 体验完全不在一个级别。

即使是 Twitter API,成本也不低。所以我做了本地缓存策略,抓取一次后存到 JSON 文件里,避免重复调用。

11 万字的上下文挑战

这三类数据汇总后,光是 Context JSON 就有大概 11 万字。把这么大的数据量一次性丢给 AI 分析,直接暴露了当前大模型的能力边界。

实测下来,6 个模型中只有 Qwen 和 Gemini 3 能稳定处理这个量级的上下文。其他几家要么超时、要么输出质量严重下降,甚至直接报错。最后我做了一轮 AI 预处理——先用模型对每篇文章生成摘要和关键要点,再把压缩后的结构化数据丢给各个模型生成画像,才解决了这个问题。

这是当前 AI 能力的一个现实限制。但可以想象的是,随着大模型的上下文窗口持续扩大,未来普通用户也能轻松处理几十万字的长文分析。到那时候,做这种个人知识系统的门槛会低很多。

多模型生成

6 个模型使用统一的 System Prompt,要求以第三方视角生成结构化 JSON 报告,包括身份标签、能力维度、做事风格、代表作品等。Prompt 中有严格约束:语气客观克制,结论必须有数据支撑,不能编造,不能夸大。

前端支持在不同模型视角之间切换,每个画像底部标注了生成模型、时间和数据来源,保持透明。

为什么让多个 AI 来写?一个 AI 的输出可能有偏差,但当多个不同架构、不同训练数据的模型都指向类似的结论时,可信度就高了不少。同时不同模型的表达差异,本身就挺有意思——有的模型更关注技术能力,有的更关注内容创作,有的会注意到生活方式这条线。

AI 视角画像生成流程

在博客里和 AI 版的我聊天

/about 页面解决的是「快速了解我」的问题。但如果读者想深入聊一个具体话题——比如「你用什么设备拍照」「你跑过哪些马拉松」「推荐几篇关于 Homelab 的文章」——一个静态画像页面就不够了。

于是我做了第二个功能:直接在博客和 AI 版本的我聊天。

技术栈

  • 框架: Vinext(基于 Vite 的 Next.js 重实现,部署在 Cloudflare Workers)
  • AI SDK: Vercel 的 AI SDKai + @ai-sdk/react + @ai-sdk/openai-compatible
  • LLM: 通过 OpenAI Compatible API 接入,支持切换任意模型(通义千问、DeepSeek、Gemini、OpenAI 等)
  • 搜索/RAG: 自建的 @luoleiorg/search-core 包,基于关键词匹配 + 权重评分 + 意图重排
  • 安全: IP 级速率限制(防止滥用)
  • 监控: Telegram Bot 实时通知,完整追踪 Token 用量和阶段耗时

工作流程

当读者在聊天框输入一条消息,系统的处理链路如下:

1. 搜索上下文复用判断

系统会缓存每轮对话的搜索上下文(10 分钟有效期)。如果是追问(比如先问「你跑过马拉松吗」,再问「成绩怎么样」),会通过以下步骤判断是否复用:

  • 追问检测:基于消息长度(≤48 字符)、标点符号、词数等启发式规则,快速识别可能的追问
  • 意图判定:调用轻量级 AI(1.5 秒超时,8 token 输出上限)判断新问题与上轮是否属于同一检索意图
  • 缓存复用:如果判定为同一意图,直接复用上次的检索结果,避免重复搜索

2. 并行搜索与关键词提取

如果不复用缓存,系统会同时启动两个并行任务:

本地搜索(即时):基于 @luoleiorg/search-core 倒排索引,使用 Intl.Segmenter 进行中文分词,并做 CJK 字符拼接修复(比如把「马拉」+「松」识别为「马拉松」)。搜索算法使用加权评分:

  • 标题匹配 +6 分
  • 摘要匹配 +4 分
  • 关键要点匹配 +3 分
  • 正文匹配 +2 分
  • 一年内文章 +1 分

深度内容提取:对于匹配度最高的文章(分数 ≥8 且显著领先第二名),会额外提取前 1500 字符的完整内容,让 AI 能回答更细节的问题。

AI 关键词提取(异步并行):如果是多轮对话且本地关键词不足 3 个,会调用 AI 从对话上下文中提取更精准的搜索关键词(3.5 秒超时,48 token 输出上限)。提取后会过滤 70+ 个中文停用词。如果 AI 提取的关键词与本地分词结果不同,会用新关键词再次搜索。

最终返回 6 篇最相关的博客文章 + 6 条最相关的 X 动态。

3. 意图重排

系统定义了 5 类意图分类:

  • AI/RAG:ai、rag、embedding、agent、llm、prompt、数字分身、向量、大模型
  • DevOps/Homelab:docker、k8s、nginx、cloudflare、openwrt、homelab、路由
  • 前端/全栈:nextjs、react、typescript、seo、vinext、前端、全栈
  • 摄影/旅行:摄影、旅行、东京、香港、京都、unsplash、马拉松
  • 生活方式:生活、消费、眼镜、医院、体验、投资、健康

根据用户查询内容识别意图后,对检索到的文章进行重排,按意图相关度评分:

  • 标题命中 +3 分
  • 分类命中 +2 分
  • 摘要命中 +2 分
  • 关键要点命中 +1 分
  • 一年内文章 +1 分

这样可以优先展示最相关领域的内容。

4. 分层 Prompt 构建

System Prompt 分为三层:

  • 核心身份:AI 人设定义、语言风格、交互原则
  • 核心规则(反幻觉协议):来源限制、数字协议、履历协议、链接协议
  • 运行时上下文:作者简介 + 相关文章/动态列表 + 用户查询

这种分层设计让提示词维护更清晰,也方便调整规则而不影响其他部分。

5. 流式生成与修复

AI 以 Streaming 方式逐字输出(temperature=0.3,max_tokens=2000)。如果检测到响应截断(以悬停标点结尾、Markdown 不平衡、句子不完整等),会触发一次轻量级修复调用(2.5 秒超时,80 token 上限),只补全最后一句,然后无缝拼接。

6. 全链路追踪

每轮对话结束后,Telegram Bot 会发送详细通知,包括:

  • Token 用量细分:输入 token、输出 token、推理 token、缓存 token(分阶段统计:关键词提取、主对话、响应修复)
  • 各阶段耗时:总耗时、关键词提取耗时、检索耗时(标注是否命中缓存复用)、Prompt 构建耗时、响应修复耗时
  • 引用内容:文章标题列表、推文标题列表

AI 数字分身对话流程

反幻觉:系统工程

做 AI 数字分身最大的挑战不是「让它说话」,而是「让它不乱说」。

大语言模型天生倾向于「编出一个看起来合理的答案」。如果有人问「你有没有去过冰岛」,一个没有约束的模型可能会非常自信地说「有啊,我 2022 年去过」,哪怕我压根没去过。

所以在系统提示词中,我设置了最高优先级的反幻觉规则:

  1. 来源限制协议——只能使用本次 Prompt 中的可见信息
  2. 数字协议——任何具体数字(金额、日期、成绩)必须在文本中出现,否则简洁承认没有记录,且同一轮对话中不得重复相同的表述
  3. 履历协议——工作经历只以「关于你」为准,没有记录时使用模板「这个细节我没在博客里记录」
  4. 链接协议——只允许引用提供的完整 URL,必须使用 Markdown 格式 [文字](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 读取的是投影,重建的也是投影。它理解的是那个「在线的罗磊」,而不是完整的罗磊。

养成系的 AI 分身

做这个东西有点像养成游戏。

目前它的知识库还只覆盖了博客、推文和 GitHub。接下来我打算把 YouTube 和 B 站上的所有视频都处理一遍——先转成文字,再做分析和索引,然后继续「投喂」给这个系统。数据越多,它对我的理解就越完整。

不过说实话,我也有一些隐忧。

目前整个系统的 AI 能力依赖于大厂的 API 服务——通义千问、OpenAI、Gemini,数据传输到他们的服务器上处理。因为我喂给它的都是公开数据,所以隐私问题暂时不太担心。但如果未来想把更私密的内容也纳入进来,就需要认真考虑数据安全了。

另一个风险是依赖性。当你把自己的知识体系建立在第三方服务之上,一旦 API 涨价、服务下线、或者政策变化,整个系统就可能受到影响。这也是为什么我选择了 OpenAI Compatible 的接口标准——至少在模型层可以随时切换,不被单一供应商锁定。

最后

回到最开始的那个观点:在这个时代,主动构建自己的知识结构,远比被动等待 AI 来理解你更重要。

我的博客、推文、视频、代码,如果只是散落在互联网各处,它们就只是搜索引擎里的一条条索引。但当我主动把它们结构化、建立语义关联之后,它们变成了一个可以对话的知识体。

可以想象的是,随着 AI 大模型能力的持续增强,以后的上下文窗口会越来越大,多模态处理会越来越成熟。到那时候,做一个自己的 AI 分身,可能就像今天搭建一个博客一样简单。

这也许就是个人内容创作者在 AI 时代的一种可能性:不只是生产内容,而是构建自己的知识系统。让 AI 成为你的延伸,而不只是替代。


相关链接

Neko Master: 从 0 到 1K+ Star 的 Vibe Coding 实践

2026-03-01 08:00:00

🤖 AI 摘要

Neko Master是一款开源自部署的网络流量分析面板,支持OpenClash/Mihomo/Surge多后端,提供多维流量统计与趋势分析。作者作为Homelab用户,因Grafana门槛过高且界面不直观,于2025年2月使用Kimi K2.5进行Vibe Coding,一小时内完成MVP,当日上线。项目快速迭代20余个版本,解决SQLite单条写入导致日200GB磁盘I/O爆炸、ClickHouse小批次高频写入引发查询抖动等深水区问题,最终通过内存缓冲队列、批量落盘、预聚合层等优化将日写入降至1.6GB。技术栈涉及Docker一键部署、Agent分布式架构、双写迁移策略。作者复盘Kimi/Claude/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+,未来也可能接入更多网关类型。

Neko Master 是什么?

一个开源、自部署的网络流量分析面板。

  • 多维流量统计(域名 / 节点 / 规则 / 地区等)
  • 趋势分析
  • 多后端支持(OpenClash / Mihomo / Surge)
  • Docker 一键部署
  • 移动端适配 + PWA

如果你家里也在用 OpenClash / Mihomo / Surge,欢迎体验。MIT 开源,欢迎 Star 和提 Issue。

从最初的「玩具」到现在拥有复杂架构的项目,这篇文章算是对整个开发过程的一个回顾和总结,分享一些 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

Tweet image

🐦 在 X (Twitter) 上查看原文 →

但用了一段时间后,发现 Grafana 这套东西虽然功能强大,但对于家庭用户来说门槛还是太高了。配置繁琐,界面也不够直观,更关键的是长得不好看。原生的 Clash 面板更多是「运行状态」展示,但我一直缺少一个更直观的视角去看:

流量到底在干什么?

  • 哪些域名在吃带宽?
  • 哪个节点负载更高?
  • 深夜学习 AI 时到底哪个网站最耗流量?
  • 当前的规则策略是否合理?

市面上除了 UniFi 之外,其他统计工具的界面确实有些一言难尽。与其在不同工具之间拼凑数据,不如自己做一个更好看、更好用的「流量感知」的面板。

一小时打造 MVP

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

Tweet imageTweet imageTweet image

🐦 在 X (Twitter) 上查看原文 →

当天晚上又花了三个小时打磨了一下,凌晨四点半,第一版 Clash Master 就上线了。

这个项目发布不到 24 小时,就收获了 GitHub 400+ Star,Docker Hub 1000+ 次拉取。这就是 AI 时代的开发速度。

让 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

Tweet imageTweet imageTweet imageTweet image

🐦 在 X (Twitter) 上查看原文 →

图一是当晚 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」的路,依然需要经验、审美和对用户需求的理解。

实现 AI 自由:我为未来准备的 4 个数字通行证

2026-02-04 08:00:00

🤖 AI 摘要

文章指出尽管国产大模型已居世界前沿,但探索全球优秀AI产品时仍存在访问门槛。作者基于自身通过Vibe Coding开发商业应用的经验,强调数字基建是AI时代的生产力基础。核心内容围绕4个数字通行证展开:1)海外实体SIM卡(如英国Giffgaff)用于接收验证码;2)Gmail/Outlook等国际邮箱避免风控拦截;3)Wise/Dupay等虚拟信用卡解决支付壁垒;4)护照等身份文件完成KYC认证。这些工具组合可系统性解决注册、支付、合规三环节的地域限制问题。

视频

过去的两年, AI 日新月异,很幸运我们很多国产大模型和产品都已经站在了世界前沿 🚀。但不可否认,在探索全球优秀 AI 产品和服务时,依旧有很多朋友被挡在了门外。 作为一名资深开发者,去年我靠 Vibe Coding 上架了一个商业应用。

深感在 AI 时代,数字基建就是我们的生产力。今天分享 4 个我的数字通行证,希望大家都能实现 AI 自由。

luolei @luoleiorg · 2026年2月4日

https://t.co/Ik3xItwco9
过去这两年, AI 日新月异,但现实是,依旧有很多朋友,由于信息差、单向或者双向的门槛,被挡在世界上最先进的 AI 门外。拍了一个视频,分享 4 个让我无障碍使用全球 AI 的数字通行证,希望大家都能在 2026 年实现 AI 自由。🚀

🐦 在 X (Twitter) 上查看原文 →

我的新电脑: 2025 年 MATX 小主机

2025-05-25 08:00:00

🤖 AI 摘要

本文记录了一位程序员在2025年中电商促销期间组装MATX小主机的完整过程。作者此前使用2018年配置的i7-8700K+GTX 1080平台已逾7年,因应对新3A大作吃力而决定升级。新机核心配置为AMD Ryzen 7 9700X处理器、技嘉B850M雕妹主板、48GB DDR5-6000内存、铭瑄RTX 5070显卡,选用乔思伯Z20白色MATX机箱与九州风神AK500S风冷散热,整机预算控制在3200元(利用旧硬盘)。装机思路强调利用现有配件、避免水冷故障风险、不追求极致性能或纯白外观。性能测试显示:开启105W TDP后Cinebench R23多核达22624分,Time Spy Extreme 9940分;双烤时CPU触及95°C温度墙,系风冷风扇替换所致。《黑神话:悟空》4K超高画质DLSS下平均90帧。

距离我上一次装 PC 主机已经过去 7 年。我们中年男人真的是太难了,存了三个月的零花钱,在拼京淘东拼西凑,这里扣扣,那里省省,花费¥3200 巨资,终于把家里用了 7 年的老电脑做了个小小升级了。消费降级,没用 Intel 的高端 CPU,改用了小牌子 AMD,显卡也从之前的 80 系列降级到 70 系。🥹

距离我上一次装 PC 主机已经过去 7 年。2018 年装了一台 ATX 主机,这台老电脑配置如下:

  • CPU: i8700k
  • 主板: 技嘉 Z370 AORUS Gaming 3
  • 内存: 芝奇幻光戟 DDR3 3000 8GB *4
  • 硬盘: 三星 960EVO 500G
  • 显卡: EVGA GeForce GTX 1080
  • 电源: 海盗船 RM650x
  • 散热: 恩杰 NZXT Kraken X62
  • 机箱: NZXT S340 Elite

当初这套配置还是比较顶,所以直到 2025 年的今天,日常用起来还是没什么问题,但是应对近几年的各种 3A 大作就颇有压力了。

临近年中各大电商促销,加上AMD、英伟达等厂商今年推出的产品算是回到了一个合理乃至甜点的区间,今年就动了重新装一台 PC 主机的念头。

装机思路

我是一个程序员,长期以来,我的主力设备都是 Mac,现在用的 MacBook Pro 16 英寸是 M2 Max / 96BG / 4TB 的配置,性能还是十分强大的,所以这次装 PC 主机,主要有几个想法:利用已有的配件(固态硬盘)、MATX小机箱,不用水冷,不追求极致性能或极致性价比,力求在合理价格区间组装一台适合自己的主机,能够应对当前主流的3A大作以及可能的视频剪辑和直播需求,作为一个稳定的偏娱乐工作站。

一开始也有考虑 Ultra 265K 的 Intel CPU + N 卡的组合,但是考虑到英特尔去年的缩缸,Ultra 这一代的支持时间,乃至目前岌岌可危的股价,最终决定还是转向市场上更成熟的 AMD 处理器。

最终配置

组件 品牌 型号 购买渠道 备注
CPU AMD AMD Ryzen 7 9700X(盒装) 京东 板U套装优惠
主板 技嘉 B850M AORUS ELITE WIFI7 ICE - P(雕妹) 京东 2025年5月15日上市,冰雕换皮
内存 宏碁 掠夺者 PREDATOR 48G(24G×2) 套装 DDR5 6000频率 Hermes冰刃 京东 6000/C28 新M-die 颗粒
固态硬盘1 海力士 Solidigm P44 Pro 2TB NVMe 已有 PCIe 4.0 ,Mac Mini 外接闲置
固态硬盘2 海康威视 C2000 Pro 1TB 已有 PCIe 3.0 ,购于2019年,东芝颗粒
显卡 铭瑄 Maxsun GeForce RTX 5070 iCraft OC12G T0 天猫
电源 九州风神 PQ850P 京东 白金全模组电源,850W
散热 九州风神 冰立 AK500S 数显版 京东 5热管,带数显屏
机箱 乔思伯 Z20 MATX 白色 京东 经典 MATX 小机箱,约20L
机箱风扇 利民 TL-S12-W/RW 120MM ARGB 12cm机箱风扇 * 6 京东 正向4把,反向2把

等各个配件送到家,再集体拍张合照的的感觉还是很不错的。

整机展示

这次装机主色调是「白色」,但是我并没有追求「纯白」,最后出来的整机效果基本达到了我的预期。

乔思伯 Z20 是很经典的 MATX 小机箱,在装机领域口碑很不错,体积也不大,刚好在我的心水范围内。

Z20 一侧是钢化玻璃,其余三名是带孔的金属网格,内部有防尘罩,整体看起来简洁大气。

机箱正面的电源开关、 Type-C 接口和 USB 3.0 ,还有一个音频接口,孔比较少,对于我来说有点不够用。

机箱背部还附送了一个小的带有磁铁的防尘罩,可以贴到机箱背部。

机箱内部主要配件和布局,使用的都是各个配件自带的线材。九州风神这个电源附送了压纹线和理线夹,稍微把显卡、主板供电线理了一下。

这次使用了宏碁的冰刃 24GB*2 的套条,频率 6000MHz,时序 C28,使用的是海力士 3GB 新 M-die 颗粒,相比 32GB 的只贵了¥100不到,果断就选择了这个,毕竟我 7 年前的老电脑都 32GB 了,如果再装一台 32GB 的,感觉有点不够意思。

CPU 风冷散热外接线,用白色电工胶布包了一下,稍微美观了一点。

这次之所以不用水冷,主要是图省事,之前那台老机器的恩杰水冷坏过一次,虽然免费换新了,但是从原理的角度水冷相比风冷的故障率还是高一些,现在风冷水冷对于这种级别的机器散热效率差别不太大,这次就选择风冷了。九州风神 AK500S 这个风冷价格不贵,颜值还行,我用利民的 S-12 换了风冷自带的风扇,统一机箱内的风扇风格。

显卡是铭瑄的 RTX 5070 iCraft OC12G 瑷珈,之所以选择铭瑄的显卡,一是之前买了一张铭瑄的 Intel B580 感觉还行,再就是这次铭瑄的铭瑄 5070 价格很香,要不从颜值的角度,肯定还是诸如技嘉雪鹰 5070 更好看,但是架不住铭瑄这个便宜不少。

铭瑄这个虽然也是白色系显卡,但是顶部是二次元元素,仔细看的话底部有点泛黄的设计,不是纯白,但是塞进机箱后看得就不明显了。

来到晚上灯光展示,我不是一个 RGB 爱好者,但是可以不用,但是不能没有,这次我还是给内存、以及风扇都选择了 RGB 效果,机箱内部采用了上2出、后1出、下2进的风道布局,机箱上的 6 把风扇都接到了 ARGB 集线器,可以通过额外的遥控器控制,也可以通过主板同步。

内存、显卡、风扇的灯光都可以同步,可以根据自己的心情和喜好调整灯光动效、颜色、明暗。

九州风神这个风冷有一个小的 LED 屏幕,安装了软件之后,可以显示 CPU 温度、CPU 占有率灯信息,但是比较遗憾的是这个风冷只有淡绿色的灯,不能与其他 ARGB 灯光同步。

我的 ARGB 集线器上也有一个小的 LED 灯,也能同步,透过背部露出来隐隐约约的效果还行。

装机过程

接下来再分享一下一些装机过程中的配件细节。

这次我本来是想购买技嘉 B850M 冰雕的,但是没想到刚好看到技嘉 B850M 雕妹上市,规格就是冰雕换皮,但是升级了 Wi-Fi 7 的芯片,价格甚至还便宜了几十块钱,果断入手。

雕妹这个主板整体大部分是白色的,但是在一些散热马甲上有技嘉的橙黑元素,不像冰雕整体纯白那么干净。但是因为我本身不追求纯白,加上有预期装机完成之后大部分都会被挡住,就没有太在意。

支持安装两个 M2 固态硬盘,上面有一个支持快拆的 M2 固态硬盘散热片,下面的 M2 固态硬盘也支持快拆,不用再用螺丝固定。

这次我用的两个固态硬盘都是已有的老硬盘,其中海力士 Solidigm P44 Pro 2TB 之前是 Mac Mini 的外接硬盘,算是 PCIe 4.0 的顶级固态了,放到现在依旧是高端水准,海康威视那个 C2000 Pro 1TB 是 2019 年买的,虽然是 PCIe 3.0 的,但是也足够日常使用了,我之前就是放在老电脑上专门放游戏。

B850M 雕妹支持 4 根 DDR5 内存条,这部分也是白色卡槽。

板U套装的 9700X。

想起上次装机的时候安装 CPU 手抖了,把主板的针脚搞弯了,这次特别小心,好在现在优化了设计,直接傻瓜放进去扣上就好了。

宏碁的内存条,48GB,应该能满足我的大部分需求了。 上板之后的效果。

散热器这部分没什么好说了的,安装好 AMD 专用的支架之后,涂规制,直接安到了主板上。

九州风神的 pq850p 电源,850W 白金全模组电源,本来我这个规格 750W 也够了,但是想到也没差多少钱,就又换了 850W 的。PQ850P 这个风扇口碑还行,颜值我比较喜欢。

理线效果

这次是我第一次装 MATX 小机箱,走线和理线成了一个大问题。这次我依旧是自己亲自动手装机,也是投入了心血,还是想着能够尽量美观。

上面就是最终的走线效果,由于机箱内有6个 ARGB 风扇,加上有一个 ARGB 集线器需要 SATA 单独供电,整体线材比较多,CPU供电线、主板供电线围绕机箱外部走了一圈,风扇之类的小线、机箱前置的延伸线之类的,大多就是分类扎起来,尽量藏在了电源下部的空间。

这次用到的主要理线工具,白色扎带、网线钳刀、白色电工胶布。当然还有电源送的理线架。

性能跑分

由于我装机之后,立马就装了不少软件、游戏,并不是纯净系统的状态,所以跑分结果可能有些偏差,实际看下来与专门的评测有 3% 到 7% 左右的差距。

整体就是主板和系统的默认配置,开启 EXPO,CPU 功耗限制开启 105W。

图吧硬件和系统信息如上。

CPU 和 GPU 的信息,看了下 CPU 核心电压 1.0-到1.1 左右波动,看着体质还行的样子?

CPU-Z 压力测试

用 CPU-Z 简单进行基准跑分测试,左边是默认 TDP 65W 模式下的跑分,右边是开启 TDP 105W 模式的跑分,解锁功耗之后提升约 10% 左右,最大看到功率跑到 140W 的样子。

Cinebench R23

同样跑一个 Cinebench R23 的多核和单核测试:

  • TDP 65W 模式: 单核 2179,多核 19055
  • TDP 105W 模式 PBO 开启35负压: 单核 2180,多核 22624

一开始我的主板只开启了 TPD 105W 功耗墙,这里的跑分与其他人 R23 单核 2200+,多核 23000 + 还是有不小差距。后来手动调整了一下 PBO 的负压到30,再跑一次方多核就上升到了 22624。

3DMark CPU Profile

3DMark CPU Profile 最大线程 9978,1线程 1256

3DMark Time Spy Extreme

Time Spy Extreme 分数 9940。

3DMark Time Spy

Time Spy 分数 20476。

双烤:TDP 105W

在开启 TDP 105W 和 PBO Auto ( BIOS 默认) 的情况下,使用 AIDA 64 FPU + Furmark 4K 双烤,15 分钟。CPU达到 95° 温度墙,GPU 核心在72-74摄氏度, GPU显存 64-6 摄氏度。

这个温度确实有点高,除了 CPU 本身的原因,另一个原因可能是 AK500S 风冷的风扇。我替换的利民 TL-S12 风扇最高转速只有 1500 rpm,风压为 1.31,而原本九州风神自带的风冷风扇最高转速为 1850 rpm,风压为 2.19,这显然是为了颜值牺牲了散热效率。

不过,这个温度仍在预期范围内,当然在大多数情况下,不可能长期在这种工况下运行。

有关 9700x 使用 AK500s 烤鸡的测试,可以参考 B 站的这个视频:

这个视频的指定评论有 UP 主详细的各个条件的温度表现,这么看来我这个温度应该也是正常。

黑神话悟空

4K 分辨率,超高画质、开启 DLSS、关闭光线追踪,平均帧率90帧。

2K 分辨率,超高画质,开启 DLSS,关闭光线追踪,平均帧率 116 帧。

其他游戏

现在的硬件在规格差不多的情况下,游戏性能的差距都不大,加上我本身玩的游戏不多,这几天新装电脑之后,也只是玩了玩网游永劫无间、无畏契约、三角洲行动、DOOM 毁灭战士、使命召唤黑色行动6、33号远征队。

我的显示器只是 4K 60帧,加上我对高帧无感。实测下来。

三角洲行动: 2K,超高画质,DLSS,能够达到 250- 300帧。

永劫无间: 2K,中低画质,DLSS开启2x,能够达到 200到 300 帧

最新出的毁灭战士:黑暗时代,4K + DLSS 基本也能达到 170帧的水平。

总结

这次装机前,我准备了不少资料,断断续续在抖音、B站和小红书上查看了许多装机方案。简单来说,CPU、主板和内存的组合基本上只有几种,而显卡的选择则因个人预算差异较大。其他配件如电源、机箱、风扇和散热器则主要看个人喜好(这也是水分较多的地方)。

整体配置看下来,基本符合我的预期,除了显卡,其他配件都没有使用低配,算是比较均衡。最终的跑分虽然与评测有差距,但我觉得主要是我的设置问题。

由于我并不追求极致的跑分和性能,在目前的硬件水平下,我新装的这台 MATX 基本可以流畅运行 2K 游戏,算是达成了我的心愿。

眼科近视验光体验:深圳大学总医院

2025-05-14 08:00:00

🤖 AI 摘要

本文记录了一位程序员在深圳大学总医院的近视验光完整经历。作者因原有600°眼镜磨损决定重新配镜,选择医院而非眼镜店或专科医院验光,原因是避免商业导向的简化流程和热门医院排队问题。验光流程包括小程序挂号(25元)、初检、医生开单、验光室检查,因度数差异大进行散瞳(40分钟滴药4次),散瞳后度数降至500°,次日复查试戴确认550°为过渡方案。关键发现是原眼镜过矫100°长期加重眼肌负担,总花费156元加停车20元,提示散瞳后需避光、勿开车。

距离上一次配眼镜已经过去五年,之前的眼镜一直戴到今天。蔡司的镜片依旧完好,而凯米镜片的那副眼镜因平时运动和不太爱惜,已经磨损得不成样子。是时候重新配眼镜了。

从医学角度来看,成年后眼睛的近视一般不会加深。在过去十年里,我的眼镜度数基本没有变化。不过,我想既然要重新配眼镜,不如趁这个机会重新验光,了解一下自己眼睛的真实情况。

  • 职业背景:我是一个程序员,过去几年,大多情况下每天是高强度用眼。
  • 眼睛现状: 左右两眼均是 600°,并且都有轻微散光

这次我没有选择常见的眼镜店验光,而是选择了去深圳大学总医院。

为什么不选择眼镜店验光

由于线下商业的特点,眼镜里店的验光只是销售眼服务中的一个环节。尽管一些眼镜店配备专业验光人员和先进设备,但由于线下销售的性质以快速达成交易为目的,从理性角度来看,眼镜店的验光存在潜在问题。

眼镜店可能仅进行简单的仪器验光,验光过程可能由普通店员完成。

虽然验光师的资格考试不难,但在这种线下场景中,普通消费者通常不太会去确认验光师的资质。

为什么不去专业的眼科医院验光

看到不少人推荐深圳眼科医院或者热门的眼科医院,我恰恰选择避开这些「热门」的医院。验光只是很基础的服务,对于医院和医生眼科方便的水平要求其实并不高,所以没必要选择那种专科医院。

热门的眼科医院,倒容易存在人多排队的情况。人多和服务好很多情况下是互斥的。

这次我选择了「深圳大学总医院」,一个是在西丽离得不远,而是新医院,硬件设施肯定没问题,加上新医院人不多,不用排队就诊、验光都很方便。

流程

下面简单说一下这次在医院的验光流程。

  • 在「深圳大学总医院智慧医院」的小程序预约挂号。随便选「眼科门诊」的主治医师或者医师即可,挂号费25元。
  • 拿到挂号单之后,去到医院3楼的眼科门诊,把挂号单给到分诊台的护士,直接说「验光」,护士会先行使用仪器给你做当前戴着眼镜的验光。
  • 接下来等号去到医生的办公室,直接跟医生说「验光」即可,医生会先再次检查一下,然后开「验光单」去专门的验光室验光。
  • 直接门口的缴费机器缴纳「验光」费用,拿验光单回到分诊台,等叫号去验光室。
  • 接下来就是专业的验光流程,验光师也是专门的大夫,会先检测你当前的眼镜都市,然后再一次检查左右眼的都市和散光,尤其是散光会多次验证偏差角度。由于我眼镜都市600多,而今天的第一轮验光都市只有 550°,医生建议我需要再做一次散瞳,以便正确验光。接下来拿着「散瞳药」的单据缴费,再去楼下取散瞳的药。
  • 散瞳需要持续40分钟,每 10 分钟滴第一次,第4次滴完之后再等10分钟,再次去验光室。散瞳之后的验光,我的度数进一步下降到左右两眼 500°,与我当前眼镜 600° 的度数相差了 100°。

鉴于我散瞳之后的验光度数下降过大,医生让我需要改天重新再次验光,以精准检查出适合的眼睛度数。

我第二天又来医院,需要重新挂号,拿出昨天的检查单据给医生,直接说「过来复查验光」即可,医生会再开一个「验光单」,这次再去到验光室。

  • 与昨天一样,首先还是常规的左右眼近视度数、散光的检查。
  • 然后医生分别给我按照散瞳的度数 500°,给我调整试戴眼睛,我感觉 500° 看得有点不清楚,医生又调整到 550°,我就感觉清晰很多了。医生让我戴着出去走 10 分钟,看看远近,看手机,看看有没有什么不适的。

我戴着550°的眼镜,发现与我600°的眼镜相比,清晰度差异不大。在标准验光距离,我能清晰看到验光表上5.0的小字,外出时也没有感到不适。

医生的建议是:我当前眼睛的实际度数为500°,但由于一次性下降太多,近期可以先配550°的眼镜,待适应半年到一两年后,再慢慢降到500°。

我询问医生和验光师,为什么之前几年600°时没有感到不适。医生表示这种情况很常见,许多人在验光时不够严谨,甚至在用眼一天后再去验光,结果可能相差300多度。

我这五六年适应600°是因为眼睛本身有调节功能,但这个度数对我的眼睛肌肉压力过过大,长期来看还是有害的。

花费

  • DAY1: 挂号¥25 / 门诊 ¥65 / 散瞳药 ¥17
  • DAY2: 挂号¥25 / 门诊 ¥24
  • 总花费; ¥156
  • 额外花费: 停车¥10*2 = ¥20

停车费用可以通过输入当日的门诊编号进行优惠减免,要不原价要 ¥30 多。

注意

如果要做散瞳的话,建议就别开车了,另外可以戴一副墨镜,做完散瞳之后,2-4小时之内,都无法看清楚近处的东西,另外对阳光敏感。

如果不做散瞳的话,一天就能搞定,花费能控制在¥100元以内。

这次验光,整体还是满足了我的预期。纠正了我之前眼镜度数不准的大雷,只可惜了我之前花费巨资配的蔡司眼镜。