普通视图

发现新文章,点击刷新页面。
昨天以前罗磊的独立博客

开启我的「人生 AI」计划

2026年3月10日 08: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

🐦 在 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年3月3日 08: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 多篇文章。

除了博客,还有 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年3月1日 08: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+,未来也可能接入更多网关类型。

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年2月4日 08: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 自由。🚀

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

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

2025年5月25日 08:00

🤖 AI 摘要

作者距离上次装机已有7年,此前主机基于i7-8700K和GTX1080,如今在3A大作压力增大、电商促销与新品发布的契机下,决定以有限预算升级一台偏娱乐向工作站。整体思路是沿用已有SSD、选择MATX小机箱、使用风冷而非水冷,并不追求极致性价比,而是稳定兼顾游戏与剪辑、直播需求。最终配置为AMD Ryzen 7 9700X搭配技嘉B850M AORUS ELITE WIFI7主板、宏碁48GB DDR5 6000 C28内存、沿用P44 Pro PCIe4.0与C2000 Pro PCIe3.0固态,显卡为铭瑄RTX 5070,配九州风神PQ850P电源与AK500S风冷,装入乔思伯Z20白色MATX机箱,并搭配6把利民TL-S12 ARGB风扇构成统一灯效。装机部分重点展示主板M.2快拆设计、CPU与内存安装、风冷替换风扇、以及在小机箱内的走线与理线技巧。性能测试中,在开启EXPO与TDP 105W、PBO负压调整后,Cinebench R23多核达到22624分;3DMark Time Spy约20476分,Time Spy Extreme约9940分。双烤15分钟时CPU触及95℃温度墙,GPU核心约72-74℃,作者认为在使用低风压风扇追求颜值的前提下属可接受范围。游戏实测中,《黑神话:悟空》在4K超高画质+DLSS下平均约90帧,2K超高画质+DLSS约116帧,基本符合预期。

距离我上一次装 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 处理器。

最终配置

组件品牌型号购买渠道备注
CPUAMDAMD 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海力士 SolidigmP44 Pro 2TB NVMe已有PCIe 4.0 ,Mac Mini 外接闲置
固态硬盘2海康威视C2000 Pro 1TB已有PCIe 3.0 ,购于2019年,东芝颗粒
显卡铭瑄 MaxsunGeForce 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年5月14日 08:00

🤖 AI 摘要

作者作为长期高强度用眼的程序员,原配戴600度左右近视眼镜多年,此次决定重新验光并配镜。出于对眼镜店以成交为导向、验光流程可能简化及验光资质难以确认的担忧,他没有选择眼镜店;同时认为验光本身技术门槛不高且热门专科医院排队严重,最终选择人少且硬件新的深圳大学总医院。文章详细描述了通过小程序预约挂号、在眼科门诊分诊台说明“验光”、医生开验光单后缴费并进入专业验光室的流程。首日验光中,仪器与医生多次检查近视和散光,发现与既有600度眼镜相比,首轮结果明显偏低,医生建议散瞳后复验;散瞳历时40分钟,多次滴药后重新验光,度数降至约500度。因变化过大,医生要求次日复查。第二天在散瞳结果基础上试戴500度和550度镜片,结合清晰度和主观舒适度,医生建议先配550度、后续再降到500度。医生解释长年佩戴600度眼镜虽无明显不适,但眼部调节负担较重,长期有害。文章最后列出两日挂号、门诊、散瞳药及停车等费用明细,并提醒散瞳当天不宜开车,对近距离视物和阳光会短暂不适。整体体验验证了医院严谨验光的重要性,也暴露出作者过去度数偏高的问题。

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

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

  • 职业背景:我是一个程序员,过去几年,大多情况下每天是高强度用眼。
  • 眼睛现状: 左右两眼均是 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元以内。

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

科普网站:航班在 3D 地球的飞行真实轨迹

2025年4月19日 08:00

🤖 AI 摘要

文章介绍作者用两天时间以 Next.js 练手开发的一个科普网站,其核心是在 3D 地球上展示航班的真实 GPS 轨迹,并与平面地图上的墨卡托投影航线进行直观对比,帮助用户理解长途航班飞行路线与地图投影之间的误差,对中学科学和地理教学具有潜在价值。灵感源自阮一峰周刊中展示 EK215 航班跨越北极的航线图,作者认为 3D 可视化更直观,于是采用 three.js 进行三维渲染,并调用 Flightradar24 的付费 API 获取真实航班数据。实践中发现 Flightradar24 按 Credit 计费,实际可用请求次数远低于预期,成本过高,只好临时下线真实数据,改用模拟数据展示。作者在项目过程中接触到航旅领域的数据与标准化体系,如全球统一的航班代码、机场代码以及多种开源地理与机场数据仓库,并对航空行业数据服务价格和行业标准化程度有新的感受,最后列出了所用到的相关技术与数据资源链接。

上周花了两天时间,用 Next.js 练手做项目,顺便做了一个科普网站。

经常坐飞机的朋友,尤其是坐过长距离国际航班的朋友,一定留意过飞机在地图上的轨迹。但是由于墨卡托投影的原因,航班在平面地图上的轨迹往往与我们心理上的感知不一致。

这个网站的核心功能是展示航班在 3D 地球上的真实 GPS 轨迹,并与平面地图上的轨迹进行直观对比。这对于理解地图投影的影响特别有帮助,相信初中和高中的科学及地理老师会发现它的教学价值。

同时也收集了几条「最长」的航线,当作展示案例。

灵感来源

在阮一峰周刊 第342期 看到那张 EK215 航班跨越北极的航线图,感觉做一个 3D 效果的可能更加直观,于是做了这个科普性质的网站。

使用了 threejs 和收费的 Flightradar24 API 制作了这个查询真实航班的小工具。后来发现 API 费用太贵,只好先屏蔽真实数据,改用模拟数据,但效果仍然很直观。

在做这个小项目的这几天,我稍微了解了航旅的数据领域,感叹航空行业的标准化真令人佩服:全球统一的航班代码、机场代码和各种开放数据。同时,我也对航空数据服务的价格感到震惊。

一开始我天真地以为 Flightradar24 每月 $9 美元能查 30,000 次挺划算(毕竟能缓存历史航班),结果才发现 Credit 并不是次数,实际请求 500 次不到就用完了,FlightAware 是按请求数计费。

有关航旅这个部分,有一个推友留言,供参考:

Nexa @nexa_li · 2025年4月11日

@luoleiorg 之前打算做相关产品,用OpenAI Deep research做了非常详细的产品调研,想要功能齐全费用不低的 https://t.co/psdvQlYGNx

Tweet image

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

相关资料

京都马拉松: 第一次去日本跑马

2025年2月28日 08:00

🤖 AI 摘要

作者第4次赴日旅行,此行主因是参加2025年京都马拉松,也是自己第10场全马。原本东京马拉松落选后转报京都,海外报名费约3万日元并额外付费定制号码簿和纪念品,但出发前一周突发感冒发烧,只好调整期望为“完赛即可”。2月14日从深圳乘深圳航空飞大阪关西机场,再搭Haruka特快前往京都,入住距离起终点较近且性价比不错的酒店,并通过Klook、小红书等完成交通和行程信息获取。赛前一天在平安神宫附近的京都市劝业馆领取参赛包,体验海外选手专窗和中文服务,参观路线图、补给展示和历届奖牌,随后乘公交在平安神宫、圆山公园、鸭川、四条商业区等地闲逛,用餐和购物,算是淡季错峰轻松游。比赛日清晨,作者在轻微低烧和睡眠不佳的情况下从G区出发,途中经历狭窄但秩序良好的赛道、天气由阴转晴、寺庙和尚与市民的热情应援以及多段河滨小路景观。由于身体恢复不完全,从10公里起即出现撞墙和饥饿感,半程成绩明显落后,只能提前补能量胶并在后程采取走跑结合。一路感受到规范细致的补给布置(水量标识、食物后紧跟饮水台)和精确的关门提示,尤其是30公里后草莓补给和沿途“干巴爹”加油令人印象深刻,在这种氛围下坚持完成全程。

第 4 次去日本,这次是去参加 2025 京都马拉松,也是我的第 10 场全马。

去年报名了东京马拉松,不出意外,依旧没有中签。刚好看到京都马拉松也在报名,就直接报了名,海外报名费用是 30,000 日元,约 $200 美元,我还额外定制了号码簿和几个纪念品,加上税费,光报名就花了将近 ¥1700 人民币。

这次京都马拉松在 2 月 16 日举行,老婆刚好放完春节假期,开年比较忙,这次日本之行就是我一个人去了。

去之前出了点幺蛾子,出发前一周,突然感冒发烧,老婆和我妈都让我别去了,心里实在是有点不想浪费,在家休息了一个星期,每天水果、喝水、吃药,出发前总算没咳嗽了。但是这个也注定我这次京都马拉松与成绩无缘了。最终我也就是抱着「完赛就好」的心态就行。

今天这波博客,依旧跟之前类似,流水记录下这次京都马拉松的行程和感受。

DAY1 深圳・大阪・京都

2 月 14 情人节,这次乘坐的航班是深圳航空,深圳往返大阪,这也是我第二次去大阪。早上 11 点的航班,全程约 4 个小时,一路倒也看了不少不知名的山川。

即将落地大阪关西国际机场。

去年 5 月同老婆去过一次东京,疫情之后,国际差旅终于慢慢恢复了。

关西空港,落地之后直接从这里坐特快到京都。

提前在 klook 上买了关西机场到京都的 haruka 特快车票,¥2,200 日元,约 100 人民币。

在京都站的交通和换乘指引还是很清晰,小红书上也有很多攻略,现在出行,基本已经不怎么使用传统的马蜂窝、穷游之类的旅游网站了,小红书、抖音上的资讯更加实时和丰富。

没想到我一个中年男人,还能坐到这么萌萌哒的列车。

从关西到京都约1个半小时,在列车上见到了大阪的落日。

晚上 7 点,到达京都。这也是我第一次来京都。

出站之后,见到京都塔,应该也算个地标?由于这次我是一个人来,也没啥旅行的计划,坐公交直奔酒店。

京都是个不大的城市,这次住的酒店离京都站只有 3 公里,距离马拉松起跑的体育馆只有 1.5 公里,只要约 500 人民币一晚,对比起东京的酒店,我推开门之后看到这个大小不由得有点惊讶,没想到居然这么大。

这是白天拍的酒店,中间那栋黑色的小楼。

酒店对面有一家 LIFE超市,属于日本的中档超市,挺多当地人在这买东西的,之前几次来日本,最多就是去便利店买买吃喝的东西,对物价感知不明显,今天去酒店对面的超市逛了逛,怎么感觉日本人民群众买这些东西价格,跟我平时买的价格都差不多甚至更便宜。

京都最近温度在0摄氏度到10摄氏度区间,早早就睡了,看了下酒店配的电视是国产的 TCL,遥控器真长。

DAY2 马拉松展会・闲逛

第二天睡到自然醒,今天是去马拉松展会领物资,在公交车站看到了京都马拉松的招牌,也有对交通影响的告示,京都马拉松这段时间,全城各处都有标志,很有氛围。

京都马拉松展会在平安神宫附近的京都市劝业馆。10点半开始检录,我10点就到了,还没什么人。

10 点 30 后,进到展馆内,海外选手有个单独的窗口,有中文服务,听口音应该是一个台湾人。京都向来是台湾的热门旅游目的地。

领到了这次的赛事包,我的号码牌上面印有「罗罗磊磊」的简体字,报名的时候额外花了点年定制的,以后留着纪念。旁边的红色袋子里也是额外花钱的纪念品。除了号码簿,里面大多都是广告,比起 $200 美元的报名费,送的这些物资还是比较寒酸的。

展馆二楼还有一层,有相关的马拉松资讯和赞助商的展位。

有一堵印有所有参赛选手姓名的墙,不少人在这签字留念,可惜我没找到自己的名字。

京都马拉松的线路图。

这次马拉松沿途供给的饮食,也有展示,京都马拉松一路吃的还是挺多的。

京都马拉松历届的奖牌,还是比较精致的,算是我拿过的奖牌中比较好看的了,当然,现在国内马拉松的奖牌设计也越来越精致了。 展会中还有主持节目,对于我一个「日语」一窍不通的人来说,只能看看了。

领完的物资,接下来我就在附近逛了逛,这块也是京都热门旅游打卡地。

在京都的这几天,基本都是公交出行,京都这巴士看着年代感十足,但是车内设施还是挺新的。

附近的平安神宫,看介绍是纪念京都建都1100周年,于1895年建造的,也是在这一年,大清与日本明治政府签下了《马关条约》。

这次京都之行只有我一个人,没有计划,也没有压力,只带了一台相机,随便逛逛,拍拍照。

一支乌鸦停在屋檐的千木上,今天气温虽然不高,但是有太阳,还是挺舒服的。

路过一个圆山公园,现在还没到樱花季,等再过一个月过来应该就很漂亮了。

现在是京都旅游的淡季,游客不多,虽然我在京都的热门区域,但是人也不太多,也这算错峰之行的另类体验吧。

看到一个神奇的店,原来这个冈本和服已经有 180 年历史的老店了。

快到中午了,约了朋友吃饭,往市区走的路上,路过一个八坂神社,碰到有新人在这举行婚礼。

上次去东京也见到新人婚礼,这种传统婚礼应该还是挺成熟的,控制时间,有专人控场,也不太会影响到周围的游客。

这条纵穿京都的小河,就是著名的鸭川,也是京都的一个地标,这次京都马拉松有很长的一段赛道也是沿着鸭川。

来到京都四条,这里是京都的繁华商业区,也是京都的中心地带。

看到了 Apple Store,去年日元汇率很好,加上日版 iPhone 不锁 AI,在国补之前,日版 iPhone 去年属于一个挺香的选择。

给老婆在大丸百货的 LV 买了一个小包,比起国内便宜不少,退税也很方便。

继续在四条附近逛逛,京都没有多少高楼,街道纵横。

路过中京郵便局,没想到也有百年历史了。

朋友推荐,来吃了一家号称日本最好的抹茶冰激凌,听说这家店还挺有名的。

路过京都文化博物馆,这个就是建于 1988 年的新建筑了。

晚餐吃了碗拉面,每次跑马之前,我都会吃得比较清淡。

吃完饭,坐公交回酒店路上,见到了 Shake Shack,之前在纽约倒也见到过,但是我第一次吃这个是在上海,后来在深圳万象也吃过,反正国内这玩意很贵又一般。

虽然现在是旅游淡季,但是京都本地生活还是挺热闹的。 时间也不早了,明天就要跑马了,今天居然在京都走了 10公里,比赛前的一天,这个量有点大了。

DAY3 比赛日

第二天,早上 9 点起跑,8 点 15 停止检录,我 6 点半起床,运气比较差,可能昨天在外走得太多,加上有点吹风,晚上又咳嗽起来,还有点低烧,一夜是没怎么睡好。今天的比赛,目标就是「完赛了」。步行来到起跑点。

早上的天气阴沉沉的,天气预报说今天有雨,加上身体状态不是很好,我特别担心下雨。更不巧的是,我忘记带雨衣了。来到体育馆内,脱掉外套,换上了运动装备后,来到存包的地方。

体育馆不大,人很多。

这一次我是 G 区起跑,位置比较靠后,但是还是在体育馆内,趁着现在人还不太多,让路人给我拍了一张照片,还是之前的那身装备,习惯了舒服。

起跑仪式没有太多花哨的表演,8点55分,首先是轮椅运动员起跑,9点整准时起跑。

京都马拉松全程赛道都不宽,加上参赛人数众多,一路周围人都不少。

跑着跑着,太阳出来了,如果不是身体状态不好,这个天气还是挺适合跑马的,加上气温也不高,其实挺容易刷成绩。

路过一个寺庙,里面的和尚也出来给大家加油,翻译一下是「心怀希望,一路向前」。

路过一个朱红色的鸟居,鸟居是日本神道教神社的传统入口标志,象征着从世俗空间进入神圣空间的过渡。

来到了鸭川河边,过了桥之后,看到后面还有很多很多跑者。

这一段也算是京都马拉松的精髓路段了。

从 15 公里之后,每间隔5km,补给点就开始供给食物了,从饼干、面包到水果,种类还行。京都马拉松每个补给点十分规范,水杯里也会提示这杯水有多少量,提示 「1/3」 , 「3/5」 之类的水量,方便跑者补水,而且有个小细节,在食物的补给台之后,肯定还会再有一个饮用水补给台,方便跑者吃完东西后再进行补水

终于到达半程中间点位置了,这个时候我的时间,已经到达2小时17分,比我过往 2小时出头的成绩慢了将近 15 分钟。

这次京都马拉松,我在 10 公里的时候,身体就已经撞墙,前一周身体状态不佳的影响提前出现了,表现就是 10 公里开始就感受到「很饿」,两腿发软,让我不得不提前吃能量胶。

路过一个路人的食物点。这次京都马拉松,让我印象最深的是京都的观赛民众,日本的长跑文化十分发达,民间也有很多跑步爱好者,这次京都马拉松,从小孩到老人,一路都能看到很多人在路边为跑者加油。我这一路都是听着「干巴爹」,参赛的氛围还是十分棒的。

这是第 14 届京都马拉松,不知道日本的其他马拉松的组织水平,京都马拉松每一段路的交通管制都做得十分精细,在半程之后,会在一些检查点提示这个点的关门时间。

跑步进到京都的一个植物园,这里还有艺妓的表演。

从植物园出来之后,开始进入鸭川的河滨小路,这里的道路就变得比较窄了,并排只能 2 人。

路边的一个加油的团队,我与他们他互相招手了。

到达一个有草莓的供给点,不得不说,跑到 30 多公里,能吃上一口酸甜的京都草莓,还是很爽的。

最后 10 公里,我基本也就是走走停停,最后的 5 公里也是一个折返路段。到达最后 1 公里的时候,自拍留念。

终于要到终点了,两边还是有很多加油的民众。 踏过最终的终点线。

老习惯,终点前自拍一张。

京都马拉松有 1 万 6 千的参赛人数,由于我是在 G 区起跑,属于5小时左右的速度,一路周围看到各个年龄段的都有。

完赛之后,有一个纪念的围脖。

除了奖牌、围脖,还有一些补给品发放。

我的第 10 块马拉松奖牌,也是我的第 2 块海外马拉松奖牌(第 1 块是 2018 年的泰国普吉岛马拉松)

在终点更衣和休息区,还有专门的给手机充电的地方,这一点细节也是值得学习的地方。

早上 9 点起跑,下午 2 点多完赛,更衣准备完之后,依旧接近下午 3 点,又累又饿,步行去京都四条附近看了看找餐厅,结果不是饭点,没找到合适的开门的餐厅,就先回酒店睡觉了。

DAY4 京都・深圳

最后一天的行程,下午 4 点的航班返回深圳,倒也不急,早上 10 点退房之后,来到京都车站,准备在这里吃完饭再坐巴士去大阪的关西国际机场。

京都车站有寄存柜,十分方便,直接刷 Apple Wallet 的西瓜卡就能解锁,也不太贵。

小红书上搜了搜,也懒得再去其他地方逛了,去京都车站10楼的「拉面小路」,准备吃碗拉面。

花了 3,500 日元,约 ¥180 人民币,点了一碗加满牛肉的拉面(我点的最贵的那个)和葱花煎饺,味道还不错。

吃完饭,又上顶楼的观景台,与老婆来了个 FaceTime,感觉下次还可以再带老婆来京都好好玩玩。

时候也不早了,这次不打算坐列车,定了巴士,京都到关西机场,约 ¥100 人民币,一路不堵车,差不多 1 个半小时到。

在巴士上见到任天堂的大楼,搜了搜,才发现原来任天堂的总部就在这里。

顺利登机,离开大阪。

成绩

上次长沙马拉松 4 小时 56 分的成绩,这次 5 小时 07 分的成绩,在身体状态不佳的情况下,也算是「完赛」达成目标了。

随想

京都,作为世界热门旅游城市和日本的文化古都,在这次马拉松之行中,我并未有足够时间深度游览。除了鸭川,其他知名景点基本上没去过。尽管周六那天我离伏见稻荷大社只有1公里远,但因为其他事务而无法步行前往。

这次也没怎么拍照,全程基本就是 iPhone 14 Pro 出片,感觉还是有必要:再安排一次京都的观光行程,好好体验一下京都的文化。

番外

在 YouTube 上想搜搜 Kyoto Marathon 的视频,分别发现了两个在 4.3km 和 13km处的长视频,记录了所有跑过的跑者。

通过分析配速和分段成绩,找到了自己在两个视频中出现的准确时间点,还是挺有趣的,国内马拉松好像还没见过类似的记录者,感觉有机会下次可以试一试。

Cloudflare 创业扶持计划申请经验

2025年1月12日 08:00

🤖 AI 摘要

文章记录作者申请并通过 Cloudflare 创业扶持计划、获得 5000 美元额度的完整经验。首先交代计划背景:Cloudflare 自 2023 年 9 月上线为创业者提供最高 25 万美元云资源支持,额度自审批通过起一年内有效。随后列出官方申请条件,包括公司成立不超过 5 年、处于软件产品/服务开发阶段、获得一定额度融资、拥有 LinkedIn 账号及有效官网与邮箱,并说明属于加速器项目和邮箱与域名匹配可加分,实际审核并不要求额外营业执照等证明。作者重点分享实操经验:建议准备可访问的产品官网、已有 Cloudflare 使用记录(如 R2、Images、Workers)、补充 GitHub 和社交媒体资料以增强可信度;在申请表的 Comments 部分详细介绍产品定位、团队及未来规划,最好使用公司域名邮箱。审核约两周,获批后额度一年内可用。文中还整理了额度使用规则:Workers、Argo 流量、R2、Stream 等按量计费产品从额度中扣减;Pro/Business、Argo/Workers 月费等订阅类产品直接记为 0 美元但不消耗额度;域名注册费用完全不覆盖,R2 与 Cache 额度封顶 5000 美元。目前控制台不能直接查看余额,只能通过账单左上角查看剩余额度。最后建议面向海外市场并在使用 Cloudflare 的创业者积极申请,但需善意合规使用,以免影响后续申请者。

最近申请了 Cloudflare 的创业扶持计划并获得了通过,拿到了 $5000 的额度。

这个计划是 CF 家去年 9 月上线的,由于中文社区暂时没看到相关的分享案例,特此整理申请经验,希望能帮助到有类似需求的开发者。

提醒:这是 Cloudflare 为创业者提供的正式支持计划,希望大家珍惜资源,善意申请和使用。滥用可能会影响后续申请者的审核难度。

项目概况

申请条件

满足以下任一条件即可申请(最终需通过人工审核):

基本条件:

  • 正在开发基于软件的产品或服务
  • 公司成立不超过 5 年
  • 获得了 5 万到 500 万美元的融资
  • 拥有 LinkedIn 账号
  • 拥有有效的网站和邮箱地址

加分项:

  • 属于认可的创业加速器
  • 账号邮箱与域名匹配

上面是官方的要求,实际并不是特别严,填写的内容也不要额外提供营业执照或者公司注册文件之类的,实际上我唯一提供的就是产品的官网。

申请经验分享

产品准备

  • 建议有实际的产品和可访问的官网(我有一个面向海外的商业 SaaS 应用,官网都齐全)
  • 最好已经在使用 Cloudflare 的产品(我的业务有付费使用 R2 、Images 、Worker )
  • 可以附上自己的开源项目、Github 、Twitter 等社交媒体资料,这些可能会有加分

材料准备

  • Comments 部分一定要认真填写,这是审核的重要参考,可以说说自己的产品是做什么的,自己的团队未来可能会开发什么产品。
  • 建议使用公司域名邮箱 -尽可能完整描述你的产品和团队情况

审核时间

我填完申请表格后,大约两个星期之后,收到了确认邮件。

下面是邮件的原文部分:

Congratulations! We’ve successfully applied the Cloudflare credits to your account for up to $5,000 US
What does this mean?
You now have up to 1 year to use up to $5,000 USD in credits. The credits will expire after one year or when they are fully used, whichever happens first.
Please note that you won’t see the credits directly in your Cloudflare dashboard, because this is a new program and that functionality doesn't exist yet. You will be able to see your remaining credit balance on your invoices for usage-based products.
For usage-based billing products (such as Workers usage, Argo traffic, R2 Object Storage, Stream, etc.), your invoices will draw down from the $5k credit. You’ll see a $0 owing at the bottom of your invoice, and the remaining credit balance will be shown at the top left.
For recurring billing products (such as Pro or Business plans, or the $5 monthly fees for Argo and Workers), the invoices will simply be marked as $0 without drawing down from the credits. So don't worry that these invoices look a little different.
Please read all terms and conditions that apply to the Startup Program here and here; including but not limited to: all Registrar purchases are excluded from the credits and must be paid for in full using the payment method associated with your account, and there is a limit of up to $5,000 USD for any R2 or Cache services.
Upgrading to Enterprise Plan
If you’re ready to upgrade your domain to an Enterprise plan, follow these steps:
Log into your Cloudflare Dashboard.
Under "Websites," click on the website you'd like to upgrade.
On the "Overview" tab, scroll down to "Active Subscription," and click "Change" next to your current plan type.
On the next page, select "Enterprise" and click "Confirm" to upgrade your zone.
This process ensures you can fully leverage the benefits of your Enterprise-level credits.

额度使用说明

下面这部分是审核确认邮件中的额外说明:

按量付费产品

以下产品费用会从额度中扣除:

  • Workers 使用费用
  • Argo 流量费用
  • R2 对象存储
  • Stream 服务等

固定订阅产品

以下费用会直接显示为 $0:

  • Pro/Business 订阅费用 -Argo 月费($5 ) Workers 月费等

使用限制

域名注册相关费用不包含在内 R2 或 Cache 服务使用额度上限为 $5000

注意事项

  • 目前仪表盘无法直接显示剩余额度
  • 可通过月度账单左上角查看额度使用情况
  • 额度有效期为一年,用完或到期即止

总结建议

Cloudflare 被成为赛博菩萨,我自己也使用了 Cloudflare 的许多产品和服务,如果你正在开发面向海外市场的产品,尤其是如果你已经在使用 Cloudflare 的产品了,建议可以申请这个扶持计划。

广东电信 IPTV 组播转单播极限测试

2024年12月27日 08:00

🤖 AI 摘要

文章以“娱乐测试”为前提,记录作者在东莞电信 1000M 宽带环境下对 IPTV 组播转单播的极限压力测试过程及结果。作者使用光猫 iTV 口桥接至软路由,在 OpenWrt 中先用 UDPXY、后改用 msd_lite 将运营商 IPTV 组播流转为 HTTP 单播,供内网多终端(PC、M2 Max/M2 Mini Mac、AppleTV、手机等)通过 GridPlayer 等播放器同时观看。硬件方面,光猫为中兴 7015tv3(2.5G WAN + 1G ITV,后将 iTV 口绑到 2.5G),软路由为 N5105,内网设备普遍为 2.5G 接入。UDPXY 阶段因“最大客户端 50”配置限制,最大播放约 55 路,ITV 口带宽约 500Mbps,CPU 占用较高且成为潜在瓶颈。更换 msd_lite 后,CPU 占用明显下降,测试中通过多机+AppleTV 同播,最多达到约 147 路正常输出、200 路画面全部出现但电脑播放变为“幻灯片”,OpenWrt 监测 iTV 口带宽最高在 1.4–1.47Gbps 左右,推测为 IPTV 线路带宽上限。同时作者重点测试 IPTV 带宽占用对家宽的影响:当 IPTV 带宽在约 1.0Gbps 附近时家宽测速可满速;升至约 1.2Gbps 后,电信官网测速下行降至 100Mbps 内;但在 200 路、约 1.4Gbps 时又曾出现测速恢复到 1000M 的情况,表现出一定策略或行为上的不稳定。最终结论是在作者特定网络与硬件条件下,东莞电信赠送 IPTV 在 2.5G XGPON 光猫上可以跑到约 1.5Gbps,理论可支撑 140+ 路 1080P 直播,当 IPTV 占用低于约 1.2Gbps 时基本不影响家庭宽带,高于该值则有概率触发限速。

这两天给家里弄好了 IPTV 的组播转单播,心血来潮,想看看极限能跑多少路 IPTV 直播

有关这次折腾 IPTV 的记录和讨论,我也发到了推特和 V2EX 上。

这篇博客不是教程,由于全国各地不同运营商对于 IPTV 有不同的网络策略,还是建议各位自行以「IPTV + OpenWrt + 组播」等关键字搜索符合当地运营商的教程。

由于这次测试「娱乐性质大于技术研究」,加上本人并不是网络相关专业,并且本人家庭设备诸多限制,注定有诸多不严谨的地方,这篇文章只是记录下下结果,不探讨相关运营商、网络、组网等技术细节。

简单来说,图一乐就好。

组播转单播

  • IPTV 原始信号是以组播(Multicast)方式传输的
  • 通过 udpxy 将组播流转换成 HTTP 单播流(Unicast)
  • 这样转换后,内网中的设备就可以通过普通的 HTTP 协议访问这些视频流

这种转换的主要优点是:

  • 让不支持组播的设备(如手机、平板、智能电视等)也能观看 IPTV
  • 突破了原本 IPTV 信号只能在特定接口或设备上观看的限制
  • 实现了全屋任意设备都能收看 IPTV 的效果

如果家里还有人要看电视,还是推荐可以搞个这个方案,在 AppleTV 、手机、平台上就能直接看直播了,而且没有机顶盒那么多广告。

有点可惜现在才弄这套方案,前段时间奥运会期间,和老婆在家看比赛直播还是挺多的。

参考资料

🌐 网络条件

  • 东莞电信 1000M 下/50M 上(有公网 IPv4/IPv6)
  • 光猫 2.5G 网口 1 桥接,软路由拨号
  • 光猫 iTV 口 桥接: 封装类型 PPPoE 网线连软路由, OpenWrt 配置网口 UDPXY 转发组播(后改为 msd_lite)

🔧 硬件配置

  • 光猫: 中兴 7015tv3 (2.5G WAN + 1G ITV)
  • 软路由: N5105 4 口 2.5G
  • MacBook Pro: M2 Max/96GB + 2.5G 网卡
  • 台式机 PC: i7-8700K/1080 + 万兆网卡
  • Mac Mini: M2 Mini/16GB + 2.5G 网卡

所有设备在内网并没有网络瓶颈。测试用的电脑均为 2.5G 内网。除了上述设备,也使用到了 AppleTV、手机等设备进行测试。

📡 转发组播

我也是昨天看到 /t/102603 这个帖子下的留言,发现可以通过「电脑插光猫 ITV 口直接播放」来验证是否能进行组播转发。

经过测试,我家东莞电信、深圳联通两地的 IPTV ,都可以满足。

我之前被其他帖子误导了,以为要鉴权抓包太麻烦就没搞了。没想到居然这么简单(刚好我的网络条件满足)。

🎮 测试播放器

GridPlayer,基于 VLC 开发的多路播放器,支持硬解。

用 IINA 也试过,最多只能播放 15 个且很卡顿,后来搜到 GridPlayer 发现可以满足需求。

广电电信的组播除了表情,也提供 1080P 的直播源,还有少数 4K,我订阅的电视源使用的都是 HD 1080P 25帧的资源,码率 7Mbps - 10Mbps 波动,大多时候是 8Mbps。

某些 4K 直播源码率码率则在 30Mbps 左右,但是数量较少,这次我过滤留下了 145 个电视台,144 个是 1080P 25帧。

❗ 重要提醒

一开始我使用 UDPXY 作为直播流代理。由于一开始配置的时候填写了最大客户端50的限制,后面测试的时候发现最大播放数量被限制在 55 路,误导我一直以为 IPTV 的最大播放数量被限制了。

但是使用 UDPXY 这一步测试结果依旧保留,仅供参考。

📊 UDPXY 测试结果

下面以 UDPXY 转发测试过程的一些截图:

Mac 最多只能播放 25 路。

Mac 那边继续直播 25路,PC 额外播放 30 路,CPU 压力很大。

OpenWrt 监测 ITV 口带宽平均下来 500Mbps。

V 站有网友评论说 UDPXY CPU 占用率可能导致瓶颈,一开始我的确忽略了这个因素,于是重新又测试了下。

当 55 个通道同时播放时,CPU使用率在 50% 到 70% 之间波动,每个 UDPXY 进程占用 1%到2% 的CPU。但是可以推测,如果继续使用 UDPXY 进行转发,播放到 100 路的时候,CPU 占有率的确有可能达到 100%。

📺 UDPXY 占用网络带宽

总路数PC 播放路数Mac 播放路数IPTV 总带宽占用家宽测速结果IPTV状态
30300300Mbps1300Mbps正常播放
503020450-460Mbps1300Mbps正常播放
553025490-500Mbps1300Mbps无法新增直播流,新增会导致原有直播随机断开一路
  • Mac 跑到 25 路就到顶了(CPU 高负载+风扇难得跑了起来),系统不卡顿,但是播放器卡顿。
  • PC 能撑到 30 路(Mac 那边 25 路还在运行),可添加无限源但超过会卡顿,已达 CPU 和显卡瓶颈,系统卡顿,播放器可能崩溃。
  • 每路都是不同的电视台源,上面 55 路同时播放流畅不卡顿。跑满时,家庭局域网其他设备(AppleTV/手机) IPTV 客户端无法再播放,OpenWrt 监测 iTV 网口带宽平均速率 500Mbps。

⚡ msd_lite 测试结果

27 号晚上,看到有人提到了 msd_lite,相比 UDPXY,msd_lite CPU 和内存占用更低 ,于是我又重新用 msd_lite 测试了下。

也是在这个时候,我才发现 UDPXY 配置里面有个最大客户端数 50 的限制,于是干脆重新测试,也因此得出了新的数据和结论,由于上面 UDPXY 测试时就已经达到了 1000M ,msd_lite 直接跳过,直接以 1000Mbps 向上的压力测试。

同时为了突破网口的物理限制,我将光猫上的 iTV 口绑定到了 2.5G 口上,原本的网络则改到了 1G 网口上。

这一轮测试,出动了 M2 Max MacBook / PC / M2 Mac Mini 共三台设备测试,同时客厅的 AppleTV 也在 4 路同屏一直播放(三台电脑同时播放时,硬件性能瓶颈太大都会卡顿,AppleTV 4 路直播不会因为硬件问题瓶颈,作为一个标定参考组)。

M2 Max MacBook 一直播放 62 路不停止,画面都能出来,但是播放不流畅,CPU 占用率 60-80% 之间波动。

旁边的 M2 Mini 则固定播放 25 路。

📺 msd_lite 占用网络带宽

总路数PC 播放路数Mac 播放路数Mini 播放路数AppleTV 播放路数IPTV 总带宽占用家宽测速结果IPTV状态
91062254900-1000Mbps1000Mbps除了电脑卡顿,其他端流畅播放,AppleTV 播放流畅
10842622541200-1300Mbps10~100Mbps除了电脑端卡顿,其余端流畅播放,开始影响网速
14756622541400~1500Mbps10~~100 Mbps播放卡顿感明显,少数源出现马赛克,ATV 正常播放但是加载偶尔出现进度条,家宽网速限速到 100M 以内
200721002541500+Mbps1000 Mbps❓极限重复 200 路测试,虽说 IPTV 达到 1.2G 之后大概率限速,但是实测依旧偶尔能够跑满 1000M 网络宽带

PC 在播放 56 路时,CPU 压力依旧很大。

在 147 路播放时,OpenWrt 监测 ITV 口带宽平均速率达到了 1.42 Gbps,约 1454 Mbps。后续尝试再增加无法突破。

改成 msd_lite 后,CPU 使用率明显下降,147 路播放时,CPU 在 50%-80% 之间波动。

上述播放,每个设备都是播放不同的电视源,最终是 145 路电视台同时播放。

接下来又分别将 M2 Max MacBook 和 PC 分别增加到 100 路和 72 路,重复播放 50 路。Mac 上这 10x10 的布局画面都展示出来了,但是无法流畅播放,幻灯片一样。

在 200 路播放的时候,iTV 的网口的流量达到了 1.4-1.45Gps ,对应约 1500Mbps 的带宽,与 147 路播放时一样,说明有可能是达到了 IPTV 线路的带宽上限。

🐎 IPTV 网速影响测试

在上面 UDPXY 测试的时候,由于我的 IPTV 最高带宽也才 1000Mbps,网络带宽在 2.5Gps 网口下均能跑到 1300M,在 1G 网口下也能跑到 1000M。因此当时我得出结论是:IPTV 带宽不会影响家宽带宽

但是随着后面转向 msd_lite,将 IPTV 的带宽进一步提升到 1.2Gps ,乃至最高的 1.47Gps 时,我发现了有趣的现象.

当播放 147 路,OpenWrt 监测 ITV 口带宽平均速率达到了 1.42Gps,约 1500Mbps。这个时候访问电信官网测速,下行下降到了两位数,在20-100Mbps 之间波动。

随后我关闭 PC 上的直播,总路数下降到91,网速恢复正常。后续我又尝试恢复 PC 上的直播,当PC的播放数量为7*6 = 42路时,iTV 带宽 1.2G 左右,若继续增加播放数量,在上升到 1.25G左右,网速则受影响下载到 100 Mbps 以内。

原本我以为运营商应该是对家宽和 IPTV 的限速做了某种策略,这个 IPTV 达到 1.2Gps 之后,可能会触发家宽线路的限速。但是随后又发生了一件奇怪的事情。

当我将播放数量增加到 200 路时,这时 iTV 的带宽又达到了 1.4-1.47Gbps 波动,这个时候我测速结果发现网速又回到了 1000M。这个时候我就不知道如何解释了。

📈 总结

如同我在最开头所说的这次测试「娱乐性质大于技术研究」

这次折腾 IPTV,更多是「好玩」性质,没有哪个正常的家庭会有这种同时播放这么多路电视的需求。

最终的结论可能并不严谨,它仅代表了在我家网络和硬件条件下对东莞电信IPTV的测试结果。

  • 东莞电信 1000M 套餐附送的 IPTV,在 2.5G XGPON 光猫下,IPTV 能跑到 1.5 Gbps 的带宽。理论可支持 140+路 1080P 的直播。
  • 当 IPTV 带宽低于 1.2Gbps 占用时,不影响原有的家庭网络带宽。
  • 当 IPTV 带宽高于 1.2Gbps 时,有一定的几率,会触发家庭网络的限速。

(注:1.2 Gps ≈ 1,229 Mbps,1.5 Gps ≈ 1,536 Mbps)

最小巧的 5G 随身 Wi-Fi: 中兴 F50

2025年12月4日 03:07

前段时间,买了个目前市面上最小巧的一线品牌 5G CPE 随身 Wi-Fi:中兴 F50

目前售价 ¥369,我京东券后实际支付 ¥337,用下来感觉还是挺满意的,在这里分享给大家。

选购思路

我手机卡很多(四个运营商,10 多个号码),平时出门包里三台手机(两 iPhone 一安卓),之所以想买一个单独的随身 WiFi,一是发挥多多余 SIM 卡的价值,二是想买个玩。

这段时间偶尔会出门工作,去图书馆呆一天什么的,个人偏好原因,不喜欢公共 Wi-Fi(很多公共 Wi-Fi 不支持 IPv6:我又有需要通过 IPv6 调试跨境网络的需求),倾向自己开热点,加上对网络速率要求比较高,所以决定弄一个 5G 随身WiFi。

不需要内置电源(随身有充电宝),开车有 USB,去图书馆时也会带个快充头,所以供电无所谓。

综合上面个人需求,在各个渠道大概搜索了下关键字,最终下单中兴 F50,插自己的卡使用。

开箱

中兴也算是通信领域的老牌厂家了,这也是我之所以选择他的原因。F50 的包装很小。

盒内物件,除了简单的说明书,还附送了个卡针和短 Type-C 数据线。

设备的颜值不错,左上角的 5G 红标有设计感。

右上角有两个指示灯灯,分别表示基站网络和 Wi-Fi 状态

与身份证大小对比,的确很小巧。

SIM 卡槽和卡托,还能放一个 TF 卡,对于我来说读卡器是个鸡肋功能,相机用的都是 SD 卡,没有什么其他设备用到 TF 卡。

管理后台

连接上 Wi-Fi 或者网络之后,就可以通过浏览器访问管理后台。后台可以查看当前的网络状态,也能查看短信。

5G/4G 网络配置,Wi-Fi 配置,跟常见的家用路由器没有太多差别。

高级配置里可以配置更多的信息,报错指定频段、USB 协议等等。

对于一个随身路由器来说,这些配置也足够了。

使用体验

由于不同的运营商在不同的地区的信号不一样,所以我只说下自己的体验。使用这个随身路由器也有几个星期了。我在家、在车上、在图书馆都使用过。整体还是挺满意的,使用广电卡,Wi-Fi 连接模式下,跑到了 400+Mbps 的下行速率,对于日常场景完全够用了。

优点

  • 体积小巧,50g 不到重量,随身携带很方便
  • 支持 2.4G/5G Wi-Fi,但不能同时开启。
  • 频段覆盖还行,四大运营商 5G 都能用。
  • Type-C 接口支持充电和数据传输,支持 TF 卡扩展,新固件可以直连 MacBook(有线上网)。
  • 速度不错,我用广电惠民卡(移动共享频段),iPhone 通过 Wi-Fi 连接,5G 下行跑到 400+Mbps。

缺点

  • 发热问题有点玄,听说长时间负载会降速,我才开一会,就能感觉设备的外壳温度上来了,但是我没有高负载的场景,不会持续满速率下载,在图书馆用一天感觉还好。这台机器有很多 DIY 散热解决方案,某个角度也反应了大家对这台设备「瑕不掩瑜」的认可吧。
  • 没有电池: 中兴也有一个内置电池的版本,但是我觉得这个不算缺点,直接插一个电源或者充电宝就行了。尤其是有几天,我直接把他放到车的扶手箱,车启动的时候就自动开机了,很方便,没有电池,也不用担心电池自燃的隐患。

参考资料

这篇文章只是个人的体验分享,对于更详细的性能、参数等,建议可以看看张大妈的分享文章,由于 F50 是一款很热门的机器,在 B 站和小红书也有很多分享:

总结

总结一下这个设备的适合人群:

  • 有多余手机卡或者大流量卡,想发挥流量价值。
  • 对随身设备便携性要求高,但是又希望能够有 5G 网络且性能满足日常使用。

长沙马拉松:回到 5 小时内

2025年12月4日 03:07

我从 2013 年开始跑步训练,在 2014 年跑了第一个马拉松。2014 年到 2018 年那几年,我每年都跑马拉松,累计已经跑了 7 场全程马拉松。

2019 到 2022 这三年,由于疫情和工作的原因,中断了三年,去年我开始恢复自己的「人生马拉松」计划,跑了第 8 场全马。

今年的第 9 场,我选择了长沙马拉松。虽然我是一个湖南人,但是我却没有去过长沙。我的表弟定居长沙,8 月乔迁新居,刚好趁着这次机会在他家住了几天,也顺便在长沙玩了五天。

行程

现在回湖南高铁很方便,不管是从东莞还是深圳,坐高铁只需要 3 个小时左右到达长沙南站。在高铁上还遇到后座两位大叔也来跑马拉松,下车的时候还聊了一下,约伴一起去领取参赛包。

检录

马拉松在周日举行,我周五提前到,从长沙南站坐地铁一站到国际会展中心。

由于是周五,很多参赛者还没来(大多会在周六报道),人不太多,我领取物资的过程十分顺利,但是周六那天,听说由于人太多,很多人排队两三个小时,被很多跑友吐槽组织得不行。

领取物资的地方。

这次领取到的参赛包。

我的号码牌,这次我长沙马拉松报名错过了报名时间,是通过赞助商渠道弄到的名额,分配我到了 F 区,属于比较后的区。

今年是长沙马拉松第 10 年,参赛包里的物资展开(也有一些我在博览会打卡领取的物资),感觉一般般,广告和廉价的食物比较多。

赛前闲逛

我表弟的房子在梅溪湖,属于长沙的新区,新楼盘很多,环境不错,晚上吃完饭去梅溪湖边逛了逛,湖边的夜景很美,有不少散步的人。比起一线城市的房价,长沙的房价相对要健康很多。

周六闲着没事,直奔国金中心,一出地铁,人潮涌动,真热闹。

长沙市中心五一广场逛了逛,人真多,街边很多餐饮店,长沙不愧是网红城市。

长沙最高楼国金中心,楼下有 Apple Store,楼上也是一个网红打卡地。

坡子街这个派出所也是一个网红打卡点,很多人慕名而来,之前是不允许拍照,后来警察可能觉得拦也拦不住,把牌子改成了「请文明拍照打卡」,但是依旧顶不住游客顶风作案。挺好玩的一个地方。

街头执勤的交警在给一个大妈指路。

我去年减肥之后,已经戒糖很久了。但是都来长沙了,一杯茶颜悦色还是必须的,完成打卡任务。

在五一广场逛了逛,走到了江边,又来到了文和友,也算是长沙的一个餐饮网红,前几年也开到了广州和深圳,最近看新闻听说要倒闭了。

逛得差不多了,穿过坡子街,走回五一广场地铁站,坐车回家休息。

晚上冲完凉,把第二天的装备收纳了一番,放到床头。这次装备跟上次差不多,除了凡士林忘带了,其他东西都齐全。

比赛日

早上 5 点半就起床了,吃了两个面包,换好衣服,坐地铁前往起跑点,今天马拉松参赛者乘坐长沙地铁免费,地铁为了方便跑友,还提前到 5:30 发车。

到达五一广场换乘去贺龙体育中心,密密麻麻基本都是跑马的人。

马拉松 7点30 起跑,我到达才 6点45,还有半个多小时。此时人已经很多了。

由于我在 F 区,发枪时间是 8:00,在这里等的时候让跑友给我拍了张照片,腰上鼓鼓的里面装满了补给用的能量胶。

前面 A 区已经发枪了,我们 EF 两区也慢慢开始往前挪动。

7点 55,慢慢到了起跑线,大家在等等起跑。

发枪咯,从我的位置到通过计时毯,只用了 1 分钟,这也是分区发枪(间隔15、30分钟)的好处。

今天长沙的天气属于多云,虽然不是阳光明媚,但这种温度还挺适合跑步的。

起跑没多久,上桥进入橘子洲。

到达 5Km,第一个补给点。橘子洲里的道路比较窄。

到达毛泽东头像,来都来了,自拍打个卡,不少跑友还专门停下来留影。

跑了没多久,我追上了第三枪 445 的兔子。他们比我们先 15 分钟发枪,我跑马前半程的速度还是比较稳,基本都能保持 10公里/h 的速度。

跑了两个多小时,终于到达半程,对于半马的人来说他们今天的比赛已经结束了,而我们全马的比赛才刚刚开始。

去年跑完珠海马拉松之后,2024 整个一年,我都没有跑过超过 10km,一般就在健身房跑 5km,过了 25 公里之后,我就能感觉到自己的体能下降了,后面开始慢慢走走跑跑结合。

到达 30 公里,除了跑不动,身体倒没有其他什么不适,用时 3 小时 17分钟,这 10 公里比前面慢了 15 分钟,虽然我平时跑步少,但是一直坚持健身,今年的身体素质还是明显强了很多。

终于到达40公里,30 公里到 40 公里这一段,我一直在看自己的配速,计算如果我这次要跑进 5 小时,需要保持多少的速度。一开始 30 到 35 公里还比较紧张,越到后面,发现自己好像能稳定,倒轻松不少。

最后 400 米,终点就在前面,长沙马拉松最后两公里是一个长上坡,很折磨人。

终点就在前面,最后这几百米,加快了速度又跑了起来。

成功达到终点,十分开心,完成了今年的「人生马拉松」。

看了下自己的手表计时 4 小时 56 分,也达成了我的目标(进入 5 小时以内)。

领完奖牌和纪念品,开心再记录几张。

过了一会,比赛确认的成绩发送到了我的手机。跟我手表记录的时间差不多。

长沙马拉松的关门时间是 6 小时 15 分钟,离开之前,还能看到不少跑友在继续努力。

赛后闲逛:湖南博物院

跑完之后就回家了,吃完饭后,洗完澡就睡了一觉,醒来后腿十分酸痛,起立转身都感觉困难。

第二天周一,腿脚好了点,但是也懒得出去,睡到中午起床,在家休息了一天。周二,跟我堂弟去湖南博物院看了看。

湖南博物院是一个很多人推荐的地方,预约参观,人很多。

博物馆展示湖南地区历年来的不少文物。

一个萌萌的鼎。 看到 Yale 的文凭,这个也是现在「雅礼中学」的前身。

湖南博物院最具特色的「长沙马王堆汉墓」相关展览。

马王堆辛追夫人生前用过的木杖(难以想象这是 2000 多年前的文物)。

逛完博物馆,感觉湖南博物馆可以放到我去过的博物馆的前几名,马王堆汉墓这些十分令人惊叹,值得一逛。

逛完博物馆,时间尚早,又去五一广场附近逛了逛,这个黄金楼也是一个网红点。

吃了黑色经典臭豆腐,味道不错。

看到一个辣条博物馆,给老婆拍了张照,感觉下次可以带老婆再来玩一玩。

还看到一个俄罗斯国家馆。

成绩

这次一个人去长沙跑马,还是挺爽的,湖南菜好吃,长沙也好玩。最后再看看成绩,这次全马的成绩终于回到了 5 小时以内,感觉加大跑量的话,明年回到 4 小时 30 分钟还是挺有希望的。

2024 桌面升级: BenQ RD280U - 为程序员打造的显示器

2025年12月4日 03:07

对于程序员这个群体来说,使用最多的设备,除了键盘,就是显示器了;前者是用来输出和创作,后者则是每天长时间的观看和阅读。

不管是在 V2EX 还是 B 站,在程序员这个群体的外设话题中,问得最多的话题就是「用什么键盘」或者「用什么显示器」。

我是一个程序员,回想我拥有的数码和外设产品,除了一把 2017 年老婆送的 HHKB 键盘,基本没有什么产品号称「为程序员打造」的外设。

对于键盘,经过这几年国内外各种品牌和配件厂商极其夸张的内卷和竞争,从成品到客制化键盘,不管是阵列、轴体还是键帽,每个程序员都可以找到合适自己的键盘。我自己目前主力使用的键盘分别是一把经过 YDKB 无线套件改装的 HHKB Pro 2,另外一把是同样 HHKB 配列 60键的客制化键盘 Qwerty 60

这两把键盘,陪我走过了职场的大多时光,写下了无数代码,也敲下了许多文字。

对于显示器,我现在家中有三台显示器,构成了我的办公桌和工作台。上面这张图,也是过去这几年我的办公桌的变迁。两台 LG,一台 Dell,都是 27英寸 4K 显示器。

对于互联网行业用户来说,如果你的职位是设计师,还有专门的「设计显示器」,强调色域和色准,之前在公司曾经负责过给设计师采购显示器,也稍微了解了一下这个领域。

但是对于程序员来说,可做的选择基本只是在 1920x10802560x14403840x2160 这三个分辨率中,选择一款合适价格的型号罢了。

直到上个月,我第一次知道这台号称「专门为程序员打造的显示器」,截至今天,也已经使用了将近一个月的时间。

开箱

这还是我第一次使用 BenQ 的显示器,纸盒收纳,外观上印着 Ultimate Coding Productivity 「终极编码效率」的字样。

正面的设计,一台笔记本,一个横向正屏,一个竖向副屏,恰好也是我现在自己桌面的组合。

从纸盒下方卡扣打开包装,显示器的支架和底座放在外层。纸盒内部也印有如何打开包装和指引。

见到显示器的第一眼,这是一台28英寸的显示器,加上走的专业路线,非轻薄向,看着分量不轻。

随机附送了一根电源线,一根 HDMI 线,一根 DP 线,一根 USB Type-C线,还有一根 USB-B 线。

底座十分宽大,常见的银灰色的配色,支架支持上下移动和旋转。

支架背后有一个皮质的线材收纳扣,可以将电源和数据线材穿过去。

外观

在放到办公桌之前,先来张背影照片。背后采用纹理凹凸设计,看着比较有质感,但是有预期的是,后续需要注意灰尘和清洁。

BenQ RD280U 背后有一个亮点,圆环其实是一圈可调节的背光灯,被称作Moonhalo

背面的接口,有一个 DP 接口,一个 HDMI 接口,两个全功能 Type-C,一个 USB-B。其中 Type-C 支持 90W 充电,大多情况下满足我的 MBP 的充电需求,我的 MBP 是 M2 Max,但是从来没触发过极限功率,之前 LG 和 Dell 的显示器也都是 90W 充电。

显示器背后的防盗锁孔,又称肯辛顿 Kensington 锁孔,在办公向的笔记本电脑中也常见(这个我也是查 ChatGPT 才知道的知识)。看得出 RD280U 也是有着商务办公的定位。

尺寸

搬到电视柜上,与我家 75 英寸和 16 英寸的 MacBook Pro 放到一起,比比大小。 BenQ RD280U 的3:2的显示比例还是一眼就能看出差异。

搬来我的 Dell U2720QM,我特意把屏幕的实际显示部分从底部对齐,可以看出两者物理上的差距。

设备 尺寸 分辨率 显示比例
BenQ RD280U 28.2 英寸 3840 × 2560 3:2
Dell U2720QM 27 英寸 3840 x 2160 16:9

通过计算可得出,理论上 RD280U 3840 × 2560 = 9,830,400 比传统的 27英寸 4K 显示器3840 x 2160 =8,294,400 会多显示 18.5% 的内容

BenQ RD280U 表明采用了雾面屏。在客厅拍摄这张时候,正是正午,阳台的阳光很强,拍这张照片的时候,发现两个显示器对于反光的处理十分明显。

如果你的办公室的工位敲好靠近窗户,一定能感受到这种抗反光的好处。会想到之前在公司上班的时候,由于我的工位靠近窗户,每天早上到工位的第一件事情就是拉下窗帘,要不白天压根看不清屏幕。

使用和编程体验

接下来把 RD280U 搬到办公桌,又费了不少功夫,为了整理桌面的线材,还专门买了几个小配件改装办公桌。

下面再分享一下使用过程中的一些记录。

BenQ RD280U 支持 VESA 支架,但是我暂时还是先使用自带的支架。

支架除了支持上下110mm的纵向调节,也支持前后正5度到负20度的调节,我的桌子不是电动升降桌,对于我来说垂直就可以了。

还是第一次用上3840x2560这个分辨率, macOS 上我缩放到2560x1707,与我之前使用 27 英寸显示器对应2560x1440的分辨率统一。

如果使用 Type-C 或者 DP 线连接,可以达到 4K 60帧的刷新率,但是如果使用 HDMI 线,则只有 4K 50帧,询问客服说是 HDMI 标准的限制。

使用 Type-C 连接 Macbook Pro,提示是通过 USB3.2 连接,我的 MBP 有三个雷电,分别接上两个显示器刚好。

作为一个编程显示器,除了规格上的特殊,软件上也做了许多的特殊适配,打开 OSD 调节面板,我第一次见到这么多选项的显示器。

显示器正面的 Logo 下方,是一块触摸键,支持自定义触摸切换到指定的模式。

RD280U 这台显示器对于编程场景时有做场景优化,尤其是对于暗夜模式亮色字体时这种反差较大的场景,会通过增加背景对代码的对比度,增强代码的显示效果,我在白天室内拍了一张照片,正面和侧边的视角都有,可以看出不同的显示器,同样 VSCode 显示的内容,RD280U 的更黑点,字体反差效果也更明显。

夜间效果

不同的程序员有自己不同的配色偏好,有些人喜欢亮色主题,有些人喜欢暗夜主题,使用 IDE 终端,人眼在白天和晚上,对于亮色和暗色模式的显示感知差异很大。RD280U 允许切换不同的主题模式。

同时 RD280U 有一个 EyeCare 猫头鹰模式,通过固件调整亮度,提供调整到极低的亮度与色彩平衡方案。

开启猫头鹰模式,显示器面板上会亮起一盏小小的猫头鹰灯。

接下来也是 RD280U 的亮点 MoonHalo,支持 270° 和 360° 的照明,也支持 7 档亮度和色温调节,从暗到亮,从暖到冷。

照片就是我的书房,关掉了所有的灯,使用固定的光圈和 ISO 拍摄的照片。 之前我的另外一台显示器使用的是屏幕挂灯的解决方案,相比一下 MoonHalo 这种在背后的补光方案,更加适合程序员这种不需要太多光线的工作环境。

深夜时分,如果还想敲代码,开启 Moonhalo,只让自己的工作台有一点点的灯光,就可以通过增加环境光,缓和屏幕直射光对眼睛的刺激,在营造沉浸的工作氛围的同时,缓解眼睛的疲劳。

桌面控制

除了支持通过物理或者触摸按键调节显示器。BenQ RD280U 还可以通过 BenQ 的 Display Pilot 2 软件控制显示器。

OSD 上所有的功能开关,模式,均可以通过软件控制,也可以通过软件自定义配置文件,一键切换。

对于开发者来说就十分方便了,可以直接通过 UI 切换模式、调整屏幕亮度、调节灯光等等。

更多

最后为了更直观展示 RD280U 的特殊,我又把办公桌重新布置了一下,与 Dell 组了个双屏。一个28寸、一个27寸的屏幕并排放到桌面上,一下子觉得眼睛看不下来。一般而言会组成有弧度的排列,这里我并排展示,是为了更好展示两者的差异,非最佳的工作角度。

两台显示器采用左右布局,分辨率分别缩放到 2560x17072560x1440 的分辨率,这样让两台显示器在视觉上保持一致。

两个屏幕同时打卡哔哩哔哩首页,可以看到 RD280U 展现的内容多了整整一行。

两个屏幕同时左右分屏,打开 V2EX 和 Chiphell,也可以看到 RD280U 展现的内容更多,3:2在这种日常资讯浏览的情况下,确实有优势。

再来到一个程序员常见的开发常见,一遍开着浏览器预览开发页面,另外一边开着 VSCode,也可以看到 RD280U 展现的内容更多。

但是屏幕大是有大的好处,也会有一个尴尬,如果你用 RD280U 想看看视频,尤其实在白天全屏看视频,你就会发现上下的黑边就特别明显了。

还有一点就是 Xbox 和 AppleTV 均无法使用正确比例的分辨率,如果你外接 Xbox 或者 ATV,会尴尬发现显示的内容都变形了,看来对于这种特殊比例的显示器,还是要看看设备的支持情况。

总结

这款显示器是一款定位十分明确的产品,专门为程序员打造,而程序员的需求相对就简单多了: 看得多而清楚,看得久而不累

市面上之前并没有这么专属职业属性消费级显示器产品,相比传统的 LG 和 Dell 同级别显示器,也并没有贵多少。

最近半年,我开始居家办公,每天绝大多数时间都是在自己的书房 Coding,不出意外的话,我会继续使用 BenQ RD280U,作为我的主力显示器。

显示器太多,眼睛有点不够用了。现在倒考虑重新部署下办公桌,考虑 DIY 一张超长的光轴木桌,再重新布置下工作台。

大家如果对于这块有什么建议,也可以给点建议聊聊。

日本旅行 2024: 东京晨跑・镰仓

2025年12月4日 03:07

五月的时候,同老婆又去了一趟日本,过去这几个月,诸多事务,也是在今天这个时间,终于有时间写完这篇游记。

距离上一次去日本,已经过去 7 年,2016年,我和老婆第一次去日本,逛了逛东京和仙台;2017年的元旦,与老婆在大阪又跨了一个年。从中扣除那如同时间按下了暂停键般的疫情 3 年,我的心理时钟似乎也只感受到了 4 年的流逝。

自从 2021 年我重新上班之后,我和老婆已经很久没出远门旅行了。这次去日本,目的地很明确,行程上也没有什么其他安排,纯粹就是给自己和老婆,安排一场放松的旅途。

与我们以往那些充满了奔波劳顿的出行不同,这次我们只安排了五天四晚的东京行程,五天只去了东京和镰仓两地。

行程

日期 行程
DAY1 深圳・东京成田机场
DAY2 皇宫晨跑・上野公园・东京国立博物馆・国立西洋美术馆・浅草寺
DAY3 东京车站・镰仓高校前・江之岛
DAY4 东京大学晨跑・明治神宫・代代木公园・涩谷
DAY5 东京铁塔・麻布台之丘・深圳

在日本的四晚,我们都选了东京的同一家酒店,也是 2016 年我们在东京住过的酒店,也算是重温一下当年的回忆。

DAY1: 深圳・东京成田机场

很久没来深圳机场了,这次从深圳直飞东京,深圳航空,票价倒尚好,两人来回 4K 多。

这次我们的行李很少,只带了两个登机箱,一个背包。航班出发时间是中午,时间不赶。

这次的航程图,到了后程靠着日本海岸线飞行,倒也可以在空中看到不少沿岸风景。

到底东京接近下午 5 点,又一次看到东京的海岸线。

在飞机上看到一座小铁塔。

伴随这落日,落地东京成田机场。

廊桥前往海关的路上,见到看似熟悉的欢迎标识。这一次入关很快,全程电子登记,也不用排队,在机场看到不少东南亚裔工作人员,看来这些年日本的外劳政策效果还是挺明显的。

过了海关,坐快线前往市区,从成田到市区有很多交通方式,指引也很清晰。

换乘之后,终于到达预定的酒店,这也是我们第二次入住,酒店名叫「东京庭之酒店」,位于水道桥站站附近,离东京巨蛋和东京大学很近。房间不大,但是设施齐全,酒店内的环境也不错。

DAY2: 皇宫晨跑

第二天我很早就起床了,开启这次东京之行的独享时光。这次来东京,我专门带了跑鞋和运动衣物,就是打算在东京跑跑步。5月早上的温度很合适,不热不冷,今天的天气也很好。

今天准备去皇宫跑一圈,从酒店慢跑过去,只有几公里,路上穿过早上的居民区。

到达皇居外围的竹桥。从这里开始一路,就可以沿着皇居绕圈了,这也是许多跑步爱好者的经典线路。

皇居外围有护城河,也有专门的步道,一路遇到不少跑者。

一路慢慢悠悠,三公里不到,即将进去皇居。

到达皇居外苑,铺满细沙这里行人比较多,道路窄,如果要进去就禁止跑步了。

人很少,加上天气不错,这次过来跑步,也是很舒服。

环绕皇居只需 5 公里左右,对于我这种跑马拉松的人来说,连热身都不算,所以后面我就慢慢走了。皇居有不少门,有警察把守。

早8点,轻轻松松跑完一圈,完成一环,解锁村上春树同款跑步线路。

接下来慢慢悠悠走回酒店,路上上班的人也变多起来。

DAY2: 国立博物馆・西洋美术馆

在东京的第二天,第一个白天的行程,只安排了博物馆。先来上野公园,先去东京国立博物馆,公园有好几个博物馆。 路过国立科学博物馆。

国立科学博物馆看着也有些年头,门口有一个好大的蓝鲸雕塑。

穿过公园,来到北面的国立博物馆。

门口的小亭子买票,成人 1000日元/人,约合人民币 50 元。

国立博物馆有几栋建筑,首先去本馆参观。

本馆建立于 1938 年,属于西洋风格,进入本馆后有楼梯直通二楼。今天也有不少学生在这里参观。

同大多数博物馆一样,基本也是按照时间线,分不同小区展示,中日文化一脉相承,日本的古代文化基本就是中国文化的传承和演绎,在国内我东西南北也看了不少国家级博物馆,对于日本博物馆的藏品,倒也没有什么感觉特别惊艳的地方。但是既然来了,还是慢慢悠悠逛了两个小时。

即将离开本馆,在墙上看到一排海报,之前有段时间,有学习和了解过一些设计和排版相关的知识,日本的设计美学排版,可以说也是影响了不少人。实事求是的说,虽说这些年国内的设计水平逐步上升,但是在美学和设计上,中日的差距还是显而易见的,尤其是日常生活的一些诸如字体、招牌、标语、海报的设计。

审美这玩意,尤其是我们普通民众对审美的认知,如同「素质」一样,非一日之功,都是需要几代人的基本教育和传承,才能养成的。

逛完本馆,又去了东洋馆,东洋馆主要展示亚洲各国的文物,当然其中重头部分也是我们中国的流失文物。一入馆,首先看到的就是我们的佛像。

菩萨立像・ 北齐时代・天保3年(552)・山西长子县

观音菩萨立像・隋代・开皇5年(585)・河北省崇光寺

除了中国的展品,也有来自印度、伊朗、东南亚等国的文物,最近黑神话悟空大火,里面不少场景取景中国传统佛道场景,当时我在博物馆东亚馆里看到这些佛像的时候,心中除了「遗憾」,也感受到了这种人类文明和文化共通的魅力。

幽暗的展厅,配合打光,这些佛像的面貌,承载着历史,也传递着人类文明中对于信仰、精神和美的追求。经历千年战火,依旧给站前面前的参观者,带来一种安静和庄严。

中午时分,参观完两个馆,也准备出去吃饭了。5 月虽然已经过了樱花季,但是天气还是舒服。馆外的座椅上,有游客在晒着太阳休息。

国立博物馆北侧有一个庭园,有日式传统的建筑,不大,推荐也可以绕着走一圈即可。

庭园植被茂密,现在即将入夏,一片翠绿,如果是秋冬过来,应该会是另外一番景象。生活在南方久了,尤其是广东基本没有四季之分,有时候跟老婆倒想去北方体验一下四季变化。

逛完国立博物馆,已经是中午时分,准备出去吃饭。

上野公园东侧有一条商业街,有不少餐馆,可能已经过了饭点,街上人并不是太多。

走到台东的一条步行街,里面很多商铺。我们在里面吃了一家拉面,味道还不错,服务的阿姨也很热情,看到我们是外国人,还特意用翻译软件跟我们确认拉面的配料。这也是在日本大多时候体验很舒服的地方,来日本三次,也去了几个城市,整体的感受都很舒服。

吃完饭,继续下午的行程,上野站附近多旅游景点,人还挺多的。

继续参观国立西洋美术馆,美术馆也是位于上野公园内,在上野动物园对面,勒·柯布西耶设计,建于 1959 年,专门收藏西洋美术作品。

美术馆不大,收藏了不少名家作品,对于我们一般民众而言,可能也就看看莫纳之类的名家作品。如果对艺术不太感兴趣,可能会觉得有点乏味,我和老婆独自在馆内各逛各的,倒也逛了一个多小时。

毕加索的作品「男人和女人」。

2019 跨年去了一趟纽约,在 MOMA 现代艺术博物馆和大都会博物馆,也看到了许多名家作品。

这次在东京,再次见到这些名家作品,也是感受下艺术跨越国界的魅力。

逛完美术馆,时间尚早,准备再去浅草寺逛逛。

东京轨道系统世界文明,在地铁站内看到一条之前的铁轨。

浅草寺应该属于那种名片性质的旅游景点,商业化成熟,对于我来说,就是一个打卡的性质。人很多,国际游客应该都会来这逛逛。

对于拥有北京、西安一众古城的中国游客来说,应该对这个寺庙不会有太多感觉。 民俗项目观音签,老婆也去抽了一张,是个吉签。

在浅草寺呆了一小会,看时间也不早了,今天走了一天也挺累,准备回酒店休息了。

在路中央看到一个贴满贴纸的路牌。

DAY3: 镰仓

东京的第三天,今天去镰仓。去镰仓要在东京站转车,上次来东京的时候,也是在这个地方,给老婆拍了一张照片。2016 和 2024 年,同一个地方,8 年时光。

今天也是一个好天气,老婆也很开心。

坐了近一个小时的JR,到达镰仓,出了镰仓站,接下来就是换乘电车,去海边。

买了一张一日通票,有这张票就可以在一天的时间内任意次数乘坐电车,肯定划算。

出现在无数人游记中的电车,这也是来镰仓必须体验的交通工具。

来到海边,我和老婆决定开始漫步一段。今天天气真棒,风也很大。

海边的小屋,有点欧式风格。看着十分干净。

走了没几步,我和老婆都不由惊喜,远远地就望到了海那边的富士山,这也是我两第一次见到富士山。

这次旅行,轻装上阵,只带了索尼 A7 搭配腾龙2870的变焦头,远远拍一张富士山,镰仓海边多云雾,我们也算是运气好,能看到这么清晰的富士山。

唯一有点遗憾的是,今天风太大了,吹得老婆的头发乱漂,不好拍照。

过马路的游客,就像漫画一样。

海边的路牌。

海滩上也有不少的游客,海浪挺大。

第一次见到马自达这个车。

除了自驾,海边也有不少人骑摩托和自行车,说到这还是挺羡慕的,国内禁摩的地方太多了。

来到著名的镰仓高校前车站,也是很多游客必去的地方。

等到电车靠近,给老婆抓拍一张。

海边的7-11,应该也是一个著名的打卡点。

见到 MX-5,在这种天气、这种地方开,真爽。

路过一个路口,刚好看到骑行的人和路人同框,抓拍一张。

临近中午,肚子也饿了,找了一家路边的餐厅,吃饭。

我和老婆点了两份主食、薯条、炸鸡,配上两杯饮料,算下来224人民币,价格还算 OK。 吃完饭出来,接下来步行前往江之岛。

马路对面的一家餐厅和排队的人,店门面的配色看起来很舒服。

江之岛一个靠近镰仓的一个近岸离岛,也是一个著名的旅游景点,有不少游客。

从堤坝去往江之岛的路上,见到另一头钓鱼的人,下午了,远处也起云雾,富士山开始变得模糊,回想今早能看到那么清晰的富士山,还是觉幸运。

来到江之岛上,密密麻麻的人潮攒动。

岛上有山,可以步梯登山,岛上有寺庙。

来到山顶,有一片小花园,看到一颗掉了叶子的树。

江之岛不大,绕一圈,见到海边的礁石,上面还有人在那摄影。

山腰上的饭店。

在江之岛逛了一圈,又步行回来镰仓海边,和老婆坐电车一趟往返,刚好休息。

从车站下车,又来到海边,海边的一座桥。

风很大,海浪波涛汹涌。和老婆在海边的堤岸上又坐了一阵,温度不错,风吹起来也并不冷。

海边的售卖机,阳光从缝隙中穿过。

即将落日,海边也被暖色的夕阳笼罩。今天的镰仓之行,十分轻松,好久没有这么惬意了。

DAY4 东大晨跑・明治神宫

第四天,开始我在东京的第二次晨跑,今天的路线是东京大学和上野公园。依旧早起,向北跑向东京大学。

上一次来东京时,曾经和老婆在夜晚来过东京大学,但是由于晚上关门,并没有进去参观,这次晨跑也算是补上上次的遗憾。这个红色的大门就是「赤门」,建于 1827 年。

来到上次止步的东京大学正门,这次开放了,无人看守,我也就直接跑了进去。

进门的林荫道,郁郁葱葱。

林荫道尽头,是东京大学安田讲堂,也是东大的地标之一。

东京大学是日本的最高学府,成立于 1877 年,地位等同于中国的清华北大。东大现在全球大学 QS 排名 30多,已经落后北大和清华。

跑步穿过东大,没多远就又到了上野公园,早晨的上野公园,空空荡荡。

上野恩赐南部公园中的「不忍池」。

继续往北跑,来到博物馆门口的广场。见到不少晨练的人。

从上野公园出来,又往秋叶原跑了一转,算是结束了这次晨跑。

今天的行程是明治神宫,其实我对这个地方也没啥兴趣,但是这次旅行,本身也就是没啥目的的放松之行,所以倒也没什么所谓。今天的游客很多。明治神宫位于涩谷区,建于1915年至1920年,二战时被焚,1958年按原样重建,靠近新宿和原宿,绿树成荫。

这里的明治,也是我们熟知的「明治维新」那个「明治天皇」。中日近代都经历过类似的社会变革,可惜两国后面一个世纪的命运,走向却是截然不同的。

看到一个通行禁止的牌子。

来到一处牌匾处,我对日本近代文化不是特别感兴趣,所以也仅仅是抱着参观的态度。

来到明治神宫正殿,左右两侧各有一颗圆形的神木,被称作「夫妇楠」,象征着明治天皇和昭宪皇后的深厚感情。

刚好碰到在明治神宫举办日本传统婚礼的新人,普通人也可以申请,看数据说每年有 1300 多人在这里举办婚礼。

院内的树木,不愧被称作「都会中的森林」。

参观完正殿,我和老婆就步行前往下一个目的地代代木公园,中途路过一个挂满灯笼的墙,看了下好像都是酒的品牌。

走到神宫北面的一处草地。如果居住在周围,在这里散步的确是一种享受。

从明治神宫步行,绕了半个多小时,来到南面紧邻的「代代木公园」,这里也是东京市民热门的公园之一。其中的狗狗公园也算一个特色。

公园中写生的老人。

虽然已经过了花季,公园中的花朵依旧茂盛。

恰好碰到举办「泰国节」 Thai Festival,有很多东南亚国家的美食,也看到很多东南亚裔的人,这些年日本逐步放开移民,吸引了不少东南亚外劳。

由于泰国节人太多了,我和老婆并没有停留太久,步行前往涩谷。在代代木公园另一个大门口的广场,见到不少跳舞的人。

干净的街道,这也是我喜欢东京的原因之一。

涩谷号称现代日本的文化中心,年轻人的聚集地。果然人多。

在一条巷子里,见到了蜜雪冰城,看到时笑了,前几天王思聪逛街,也在这里被人拍到。

从涩谷逛完,我和老婆去秋叶原吃鳗鱼饭,正在吃饭的时候,突然收到郭宇发来的信息,问我还在不在东京。

本来这次东京行有约他,但是之前安排的行程,我来东京的时间,他刚好在意大利了,所以没能见上一面。没想到后来我的机票改签,延后了几天,他也刚好在今天回到东京,所以就约了晚上聚一聚。

郭宇是我的学长,也是改变了我人生轨迹的一个人,有关他,和我和他的经历,之前曾经写过一篇文章:

去年在深圳有聚过一次,我和老婆与她的相聚,则是 6 年前的大阪。如今在他东京的豪宅再相聚,天南地北聊了不少。就是这次太赶了,没能蹭上他一顿饭。

也不早了,想着他刚回国,也不打扰他休息,郭宇很热情开车送我们回了酒店,也是第一次体验首都高逮虾户。

DAY5:东京铁塔

在东京的最后一天,晚上的航班回国,今天的安排也很轻松,就是去东京铁塔打个卡。

在酒店收拾完行李寄存,坐地铁来到东京铁塔。可惜今天天公不作美,下起了雨,但是想一想前几天都是好天气,最后一天下下雨,也算是给我们体验一下不一样的东京。

七年前来到东京,在晚上看到一次东京铁塔,这次雨天再来看看。给老婆拍个打卡照。

东京铁塔建于 1958 年,高332.9米,比巴黎艾菲尔铁塔还高 8 米,是日本第二高的结构物,仅次于东京晴空塔。是日本的象征之一,也是东京的地标之一。

距离东京铁塔,有一个「麻布台之丘」的新建观景台,2023年11月开幕,顶楼有一处室内观景台和咖啡厅,能直接看到东京铁塔,目测会是以后又一网红打卡地。

也在这里,给老婆拍了一张照片,也算是这次东京之行的结束。

归程

雨中拖着行李,坐 JR 到了成田机场,时间尚早,在机场星巴克买了杯咖啡,等待登机。

花了两天时间,终于还是写完了这篇游记。

上一次去日本,还是青年,这次再来,已是中年。过去这几年,世界,家庭,包括自己,都发生了诸多变化。成家了,创过业,又回去工作几年,可谓也是踉踉跄跄。

时光匆匆,有时候还挺幸运自己过去一直「记录」和「分享」的习惯,回看过去旅行的点点滴滴,时不时也能找回一些过往的幸福和温馨。

补上这篇游记,也是对未来自己的一种交代,希望再过 5 年,再过 10 年,再过 20 年,再回看这些文字和照片,依旧能感受到生命中的点滴美好。

抗癌笔记:评论信息汇总

2024年3月26日 00:17

谢谢你 ​

在上一篇博客《我的老婆确诊肺癌,希望能得到你的帮助》中,我公开求助,寻求与肺癌相关的资讯、经验,首先向提供帮助的各位朋友说声谢谢你

除了博客,我也在推特、 V2EX 和微信公众号发布了同篇内容,V 站和推特都有大量评论,大家也可以去下面的链接查看。

短短几天的时间里,许多朋友转发、留言、私信,给我们提供了众多有关肺癌治疗、康复的参考资料,对我们后续就医,指明了大概的方向。更重要的是其中基于案例、科研的数据,增强了我们的的信心

如同我在前一篇博客中所写的「帮助可能也遇到这类病状的家庭和朋友,能够给你们带来参考,实现利他的价值」。

今天这篇博客,初步收集、整理上千条评论中,有一定实用价值的内容,汇集到此篇博客中。

说明:不少人的留言不一定严谨,甚至有错误;毕竟除了少数专业领域的人士,或者有实际经历的病人或者家属,大多人对癌症了解是不够的。但是,我和老婆依旧会感谢这些善意的留言,如果大家发现有人提供的信息有所错误,也请就事论事,指出纠正即可。由于本人学识和专业领域所限,也希望大家可以帮忙甄别这些内容。

我将留言内容大概分为下面几块:

  • 肿瘤医院推荐:相对在肺癌治疗方面更专业的医院,为后续再去哪家医院就诊提供对比和参考。
  • 基因检测相关:从目前我老婆的癌症分期来看,包括几位医生朋友的建议,大概率需要基因检测,除此之外,也有朋友提到 MDR(微小残留病灶)检测。
  • 病友经验:癌症病友和亲属提供的经验和参考。
  • 科研资料参考:与肺癌相关的医学和科研资料。

肿瘤医院推荐 ​

  • 我去年也做了左右肺两次的手术,但都是微浸润,达到浸润程度还是要做基因检测啊,对后期靶向治疗有帮助。磨玻璃结节比较讨厌,很多都是多发性的,定期复检,早期问题不大,祝好。单位公司如果有给你办过重疾险,微浸润以上就符合理赔标准了,可以看一下。广州医科大学附属第一医院胸外科很好,可以去看一下,不过最好也是要有基因检测报告。
  • 磊哥好!广州中山肿瘤医院是广东省比较权威的,医疗水平比深圳强,可以了解关注一下。早日康复,愿幸运女神特别眷顾你们!
  • 磊哥,保重,祝太太早日康复。记得去广州肿瘤医院复诊检查,医学方面广州更可靠。
  • 我父是去年十一月被确诊,现在在抗癌之路。看了你家的分期,你们不用过度担心!我家现在是在中国医学科学院肿瘤医院治疗。我在网上查到的是这家是中国建国以来第一家专科肿瘤医院,相对来说会比较权威。不过总院是在北京。
  • 可以尝试咨询北京朝阳医院(呼吸科全国前列)获得更多意见;涉及肿瘤,建议多方咨询全国排名靠前的肿瘤专科医院,例如中国医学科学院肿瘤医院北京大学肿瘤医院中山大学肿瘤防治中心等,如有必要可以重做病理检查,以防止小概率误诊。
  • 术后尊医嘱,深圳医疗资源有限,如果不是很严重,可以在当地就治疗,靶向药现在部分也进医保了。如果之后还是不太好,可以去上海北京看看。北京可以直接来协和。挂号应该还好 另外查下夫人的保单,医疗险。有没有重疾绿通,或者国际部权益,以及保障范围的用药名录和报销要求。遇到理赔问题可以私我。

基因检测相关 ​

  • 定期做MRD检测,可以从分子学层面上监测体内是否还有癌细胞残留,提前能检测到是否复发。术后一个月以内做第一次MRD,评估手术切的是否干净以及体内是否还有癌细胞残留。后面每隔3到6个月做一次即可。
  • 活检做基因检测了么?东亚不吸烟的 adenocarcinoma 很有可能是 EGFR 突变,如果是的话,有很多针对这个突变的靶向药,而且临床试验的结果都不错。也可以参考 NCCN treatment guideline,看看美国这边通用的治疗方案是什么。总之,作为肿瘤治疗的从业者,你夫人的癌症应该是有不错的预后的,配合积极治疗,定时随访,stay optimistic
  • 术后大病理报告会告诉你更多有用的信息。目前而言,专心恢复身体,补充好足够的营养尤其是蛋白质,有助于积液的吸收。记得做呼吸训练,慢慢可以恢复运动,记得别提重物,尤其是手术侧。既然经济能力不错,建议基因检测、ctDNA、MRD都做,有些人会说1A1做这些都是智商税,但是从我个人的角度出发还是做,都是以防万一。后面就要开始进入复查随访阶段一开始三个月,后面是半年、一年。务必记得保存好你每次检查项目的数据(不管手术前手术后的全部都要),尤其是ct原始档案(大多是dicom格式)方便以后多方面寻求意见作对比之用。最后是想写给你的,照顾好家属的同时也记得照顾好自己,记得按时吃饭足量饮水~1A2患者家属留
  • 基因检测是非常建议做,组织样本(白片)不要随便用掉非常宝贵。中山肿瘤是南方最好的肿瘤医院,要做基因检测直接到中肿问就行。燃石算是业内最贵,但是质控是最好,也能提供MRD检测方案(反正找小公司都是不便宜)。-说几个事情吧!医学相关!目前看分期还是很早的,不幸中的万幸。1.基因检测一定要做,不知道目前深圳基因检测是否入院,还是要在院外第三方检测机构做(可能有回扣)选一个好一点的公司,做一个大一点的组,拿手术组织做不要抽血。(推测一下夫人大概率是 egfr 突变)2.如果 egfr 突变但是你的分期是 IA1 那奥西替尼报销不了。当然你可以修改疾病诊断证明书(这个我不知道🤷)3.理论上来说 IA1 术后是可以不做术后辅助治疗的(靶向和化疗)。但是最新的医学这方面好想小样本数据有推荐(我要去查一下)。我会关注后续的。希望挺过5年。后面一路平平安安
  • 广东省人民医院 吴一龙 是国内这方面的专家,你可以查一下他的资料和团队,以后有帮助,早期手术效果会很好,不用太担心,基因检测有必要,测试靶点,不过随着放疗化疗的作用,靶点会变化,用药也会变化,目前有一代二代三代针对非小细胞肺癌的靶向药,第四代药物还在临床实验,用药次序需要根据医嘱,不过这都是在出现进展的情况下才去考虑,目前术后就是回复身体和定期复查看是否有需要化疗。非小细胞肺癌在亚洲女性特别是没有吸烟和饮酒史的女性身上发病率极高。心态平和,坦然处之,你老婆是幸运的,一定会好起来的。还补充几点吧!1.理论上来说IA1术后是可以不做术后辅助治疗的(靶向和化疗)但是,但是,但是就怕CT有些地方没有照到,还有你这边没有做PET-CT,也不知道是否有寡病灶或者运气很差的。2.可以去做一个MDT会诊可能价格有点喜人,但是听一下肿瘤内科的建议还是好很多的,外科医生还是有局限性的.
  • 有较高危的微乳头因素,微乳头和实体型比其它的更容易早期转移已经复发。经济允许的话,取病理切片去知名基因检测机构做比较完整的基因检查。年轻女性通常都有可以用的靶向,也可以顺便做 PDL1 表达 22C3 之类的。做基因检测不是说就要用药,而是之后复发,比如过了两三年或更长,一个是组织做就效果没现在好或者没效果,二个是复发可能还不好取病理。另外没看到肿瘤指标 如果术前就比较高的话,会倾向推荐之后辅助资治疗

病友经验 ​

  • 再来普及一下,对于IAI期非小细胞肺腺癌而言,病理亚型决定了5年生存率,亚型有贴壁型,腺泡型,乳头型,微乳头型,实体性;其中以贴壁型为主的亚型,生存率在浸润型腺癌中5年生存率最高,而如果在亚型中即使存在较少比例的微乳头、实体型成分,也一定要小心注意,经济条件允许上MRD是更好的选择;浸润性腺癌预后而言,前1-2年是复发高危期,前2年,超过5年无复发,临床上可视为痊愈。一般医院会要求每三个月一次增强CT检查,6个月一次全身骨扫描、脑部、腹部增强CT检查。预后对生活的影响:一般浸润性腺癌都是做肺叶切除,相当于你少了五分之一的肺,要说没影响是不可能的,恢复期在1年,前3个月会有明显的咳嗽,3个月后逐渐好转,但在稍剧烈运动、搬重物时仍存在气紧、胸闷等情况。
  • 鄙人去年八月刚做完手术,IAI期的生存率评估,更多是要看病理最终结果显示的亚型,即是高分化、中分化还是低分化,以贴壁为主的预后是非常高的,此外,经济条件允许,建议做MRD监测,可以即把基因突变确定了,同时对于IAI期,每半年抽次血做个MRD,有一定的几率可以提前发现是否出现微转移,好及时做后续应对。
  • 建议加入熊猫与朋友病友互助群,应该是国内最大的病友互助群了。
  • 早期发现是好事,定期复查,基因检测不着急做。现在肺癌治疗手段很多,不影响生活就不用太在意,保持好心态。做为家属,可以多学习相关知识。推荐与癌共舞和肺癌康复圈两个公众号,后者有对应的 App 叫觅健,可以在里面学到很多。
  • 我去年也做了左右肺两次的手术,但都是微浸润,达到浸润程度还是要做基因检测啊,对后期靶向治疗有帮助。磨玻璃结节比较讨厌,很多都是多发性的,定期复检,早期问题不大,祝好。

科研资料相关 ​

我的老婆确诊肺癌,希望能得到你的帮助

2024年12月8日 14:19

为什么要写这篇文章? ​

今天是 2024 年 3 月 19 日,对于我来说,这是一篇严肃的博客。这篇文章,不是募捐,也不会以此话题来贩卖悲情、吸引流量

如同我在标题中所写到的:我的老婆确诊肺癌了

在写这篇文章之前,我也与老婆认真讨论了「是否有必要把家庭和个人的隐私公之于众?」,在经过她的同意后,我还是决定把这件事认真、严谨地记录下来。

我是一个程序员,理性与逻辑,是我向来行为做事追求的准则。写下这篇文章,我有两个目的:

  • 一方面,是收集资讯、经验,用以帮助我的老婆在后续治疗、康复的过程中,尽量少走弯路,避坑的利己诉求;
  • 另一方面,也是希望我的这篇抗癌笔记,能够帮助可能也遇到这类病状的家庭和朋友,能够给你们带来参考,实现利他的价值。

在此,真诚地向所有看到这篇文章的各位朋友求助,如果你有任何有关肺癌的资讯、经验、或者是治疗和康复方案,都希望你能够留下相关的信息。非常感激你的帮助。

这篇文章我也分享到了推特,截至 3 月 21 日下午,已经有 100 多万的浏览量,超过 1 千条评论,在留言中也收获了许多有价值的信息:

更新 Changelog ​

本文会随时间陆续更新,在此栏记录本文的重大更新时间和内容:

  • 2024.04.19:补充中山大学肿瘤防治中心就医时间线,基因检查结果确认。
  • 2024.03.20:补充深圳人民医院「术后病理活体组织检验报告书」。
  • 2024.03.19:文章发布,介绍了老婆的病情背景和治疗关键时间节点。

关键时间节点 ​

时间 时间周期 机构 事项 备注
2023.12.23 D+0 深圳美年体检 肺部 CT 发现肺结节
2024.01.22 D+30 华中科技大学协和深圳医院 肺部 CT 第一个医生:CT 发现肺部 13mmx8mm 磨玻璃,提示有可能是癌前病变,医生建议入院手术
2024.01.24 D+32 香港大学深圳医院 胸外科门诊 第二个医生:医生建议手术
2024.02.29 D+68 深圳市人民医院 胸外科专家门诊 第三个医生:深圳市最好的胸外科医生之一,医生建议入院手术
2024.03.13 D+81 深圳市人民医院 入院 术前系列检查
2024.03.15 D+83 深圳市人民医院 手术 全麻,切除部分肺组织
2024.03.17 D+85 深圳市人民医院 术中病理报告 主治医生术后第一次交流,初步确诊肺微浸润性腺癌
2024.03.18 D+86 深圳市人民医院 癌症分期 右上肺微浸润性腺癌(T1a(mi)N0M0, IA1
2024.03.20 D+88 深圳市人民医院 病理活体组织检验报告书 大病理结果:肺浸润性腺癌中分化,腺泡+乳头状(约50%),可见微乳头结构(约10%),肿瘤大小 1cmX1cmX0.8cm .可见脉管累犯: 胸膜及吻合钉切缘未见癌
2024.03.28 D+96 深圳市人民医院 术后复查 主治医生第二次交流,解释术后其他方案的可行性和必要性(建议不要过度治疗)
2024.04.09 D+108 中山大学肿瘤防治中心(广州) 专家门诊 综合网友建议和评估,全国肿瘤医院排名第三,广州最好的专科医院,专家赵洪云门诊,医生重新安排增强CT、MR、血液、基因检查等项目
2024.04.10 D+109 中山大学肿瘤防治中心 门诊检查 血液相关检查、心电图检查、全身骨显像CT
2024.04.12 D+111 中山大学肿瘤防治中心 门诊检查 病理会诊,提交深圳人民医院病理组织切片等供基因检查
2024.04.13 D+112 中山大学肿瘤防治中心 门诊检查 上腹、胸部增强CT,颅脑磁共振MR查
2024.04.19 D+118 中山大学肿瘤防治中心 分子诊断检查报告 确定变异基因 EGFR: p.E746_S752delinsV

就诊经历简介 ​

我的老婆在 2023 年底体检时,通过 CT 发现肺部有「肺结节」,后续体检机构的工作人员多次电话联系,提醒我的老婆务必去医院复查。

老婆在隔年的 1 月,去南山医院(华中科技大学协和深圳医院)做了进一步检查,也做了 CT,第一个医生,提示我老婆肺结节有可能癌前病变,医生建议入院手术切除。

为了保险起见,我们又预约了香港大学深圳医院的门诊,港大医院的医生也建议入院手术。

经过两家医院的问诊后,我和老婆确定了手术治疗的计划,由于春节假期,中间间隔了一个月,节后我们就立马预约了深圳市人民医院杨林医生的专家门诊,杨医生也是直接给出了手术的建议,并给出了入院通知书。随后,我们在 3 月中旬入院,并在 3 月 15 日顺利进行了手术。

从发现症状,到最后的手术,只用了 80+ 天的时间。虽然时间很快,但是从始至终,我和老婆对于这个病的心理预期,都停留在「肺结节」这个病症的范畴,压根没有想到进一步的癌症

在手术完了后的第三天,在与主治医生交谈时,当我们看到《术中冰冻病理诊断报告单》上写着的「至少肺微浸润性腺癌」这个结果时,以及后续大病理《病理活体组织检验报告书》的最终诊断「肺浸润性腺癌」,我和老婆都非常震惊。

术后医生解释:术中病理报告 ​

在手术后的第一次主治医生交流,由于病理报告上的信息不多,更多的是医生向我们解释内容,从对话之中,我们了解的信息如下:

  • 确诊肺微浸润性腺癌,是肺癌的一种,现在是早期癌症,具体的分期需要等后续的检查报告出来。
  • 微浸润性,说明有可能开始转移(后续升级为浸润性)
  • 这是一个恶性肿瘤
  • 进行手术切除,是早期癌症最好的处理方案。
  • 解释了下为啥切除这么大的原因(手术过程中会把切除下来的组织给家属目视确认)
  • 需要定期复查,半年,一年,五年内都需要定期复查,以观察是否有复发。
  • 如果再次复发,那就一定是晚期(说明已经扩散)
  • 介绍后续治疗方法主要有:靶向药、化疗
  • 说明深圳医保覆盖了大部分靶向药的报销,如果后续需要靶向药,每个月自费几百块即可。
  • 解释基因检测对于癌症治疗的作用,提到医院内有基本基因检测,也可以联系外面基因检测公司做全基因检测,费用从几千到上万不等,但是需要自费,可助于后期筛选靶向药。
  • 如果后面有生育计划,由于需要定期 CT,不建议近两年怀孕。

在交流过程中,我有向医生提问「基于我老婆当前这个年龄和癌症早期的病情,后续康复或者复发,在统计学上的概率大概是多少?」,但是比较疑惑的是,医生并没有回答我的这个问题。

术后第一次与主治医生交谈,得出的病情基本结论是「确诊肺癌,早期,无法保证不复发,后续定期检查即可」,我自己根据医生的解释,大概感觉是虽然这是一个癌症,但是感觉好像不太严重。但医生并没有给出「没啥大问题」之类的主观描述话语,不知道是不是出于医疗严谨用语的需要。

癌症 TNM 分期 ​

手术之后的第三天,由于我老婆的恢复较好,我们就被安排出院了,在出院前拿到的出院疾病证明中,说明了癌症的分期为T1a(mi)N0M0, IA1。TNM 是一种国际通用的癌症分期标准。

具体到我老婆的癌症分期级别的解释,我用 ChatGPT 查了下,解释如下:

  • T1a(mi):T代表肿瘤的大小和局部扩散的情况。在这个分类中,T1a表示肿瘤的最大直径小于或等于1cm,(mi)是微浸润的缩写,意味着肿瘤的侵袭性较低,局部非常有限。T 代表原发肿瘤(Tumor)
  • N0:N代表肿瘤是否有淋巴结转移。N0表示在检查时没有发现淋巴结转移,即肿瘤尚未影响到淋巴系统。"N"代表淋巴结状态(Lymph Nodes)
  • M0:M代表远处转移的情况。M0意味着没有远处转移,即肿瘤没有扩散到身体的其他部位。"M"代表远处转移(Metastasis)
  • IA1:这是根据TNM分期得出的总体分期结果。IA1是非小细胞肺癌(NSCLC)的最早期阶段之一,表示这是一个非常早期的癌症,局限于原发部位,且大小极小,没有淋巴结转移和远处转移。

综上所述,"右上肺微浸润性腺癌(T1a(mi)N0M0, IA1)"的诊断意味着患者的肺癌处于非常早期的阶段,肿瘤小,局限于肺部一个很小的区域,没有发现淋巴结转移和远处转移。这种早期的发现通常预后良好,治疗方法可能包括手术切除肿瘤、可能的放疗和/或化疗,具体治疗方案需要根据患者的整体健康状况和具体情况来定。

病理活体组织检验报告书 ​

3 月 20 日中午,接到主治医生的电话,收到了《病理活体组织检验报告书》,俗称大病理。医生表示比术中病理结果要严重一点。由微浸润改为浸润中分化微乳头,并且有脉管累犯,上面加粗部分,都是恶化和消极因素,但是癌症的分期不变,更新的结果表明,复发的可能性更高

术后院外专家咨询 ​

拿到诊断报告和癌症分期后,我也分别电话咨询了内地某省会城市的医生朋友、深圳某医院的医生同学。其中一人有胸外科 10+ 年的经验,另外一人也有肿瘤相关的研究经验。

在我提供病历、诊断报表、病理诊断报告单之后,两人都给出了类似的意见:

内地医生朋友 ​

  • 情况比较好,属于早期癌症,不太太过担心。
  • 近年来周围也有认识的人得了肺结节和早期肺癌,预后都不错。
  • 现在这个阶段做基因检测没啥太大用,一般都是在筛选靶向药的时候用。

深圳医生同学 ​

  • 从分期结果看,早期五年生存率有 90%
  • 腺癌是肺癌的几种亚型里面相对较好的。
  • 依照医嘱,务必远离烟酒,保持良好的生活习惯。
  • 尤其强调了保持良好心态对预后治疗和康复的重要性,并给出了研究数据解释。

接下来我该做什么? ​

在过去这三个月的问诊、治疗的过程中,我和老婆基本都保持理性、尊重专业知识和专家指导。但是过去这一周,当我面临着「老婆确诊肺癌」这个事实时,对这个领域和相关知识的匮乏,依旧让我觉得无力。因此,如同写这篇文章的目的,我需要尽量地收集、了解更多信息,供我们后续的决策和计划使用。

也许从我上面表述的情况来看,好像能得出我的老婆虽然得了癌症,但是好像还可以,没啥大问题的乐观结论。

但是临床的数据,尤其是 TNM 分期结果对应的 早期五年生存率90%到95% 的数字,依旧是一把悬在我心头的达摩克利斯之剑。

数字放到群体中,只是一个概率,但是这个概率落在个人身上,就是 0 或 1。我不想让老婆承担这 5%到10% 的风险,对于我的内心来说,是难以接受的。

虽然我知道从医学的角度,按照医嘱:定期复查,大概率已经是不错的后续策略。但是我依旧想在这未来的这段时间,尽量提高老婆治愈的百分比。

接下来,我想到的大概确定能做的事情有:

  • 等老婆度过手术恢复期,再去广州肿瘤和胸外科领域更权威的医院,再做一次门诊。
  • 基因检测:虽然几个医生朋友说现在做基因检测没啥大用,但是这个价格尚在接受范围,也欢迎有经验的朋友推荐相关渠道。

除此之外,我并没有太多其他的计划,在此,就希望有经验的朋友,能够给出一些建议和点拨,我发散地想了想:

  • 后续治疗和康复过程中可能会遇到的骗子、骗局?
  • 治疗和康复过程中,可能存在的过度治疗?
  • 从营养学的角度,是否有什么饮食相关的建议?
  • 是否有什么靠谱的网站、论坛、App 推荐?
  • 有哪些可能是我自己无法主动感知的问题?

给大家的建议 ​

花了几个小时,斟酌文字,写完这篇文章。年过 30,对于我和老婆来说,这是人生的一个大事,也是一个挑战。

在这里,我想给各位朋友一些建议:

  • 定期体检:尤其是 30 岁以上的朋友,尽量每年做一次全面体检,现在很多体检不包含 CT ,建议可以加上。
  • 保险:不管是医保、重疾险还是其他商业保险,梳理你已有的保险,如果有不足的地方,尽量补齐。在遇到这种情况的时候,能极大的减轻经济负担,也能给自己更多的选择。
  • 保持健康生活习惯:远离烟酒、运动,健康饮食,这个也算是老生常谈了。

在开始着笔写这篇文章的时候,我一开始想的文章标题是《理性乐观:我的老婆确诊癌症,希望能得到你的帮助 》,相信保持理性和乐观,一定会给老婆带来好的结果。

最后,再次感谢你的阅读,如果你有任何有关肺癌的资讯、经验、或者是治疗和康复方案,都希望你能够留下相关的信息。谢谢。🤝

我的智能家居监控方案:打造自主、安全、可控的摄像头

2024年12月8日 14:19

最近买了一个摄像头,放在家里看宠物,稍微折腾了下,目前算是比较满意了。

如果你对家庭监控的安全性和隐私性要求比较高,可以参考下我的方案。如果不想折腾,建议直接用原厂的 App 和云服务。

自建方案简介 ​

买了个支持ONVIF协议的 IP 摄像头,通过ONVIF协议接入和群晖的监控Surveillance Station,摄像头进行24H监控,视频存储在群晖外挂的 USB 硬盘上,配合Home AssistantNode-RED,实现了一些动静通知、回家离家自动开关等自动化的功能。摄像头断开外网访问,只能在家里内网或者 VPN 访问,保证了视频的安全性。

为什么要自建监控? ​

几个月我写了一篇文章《脱钩: 我的个人网络安全策略》,分享我与中国互联网服务和产品脱钩的一些经验。

在那篇文章中,我介绍了我已经把大多数据资产都转移到了境外服务或者下云,主要目的就是为了保护自己的隐私和数据安全。

对「智能家居」来说,脱钩或者下云是不实际的,我是小米生态的重度用户,门锁和门禁摄像头,都是小米生的产品,这些产品基本都强依赖于小米的云服务。入住新家两年以来,这种基于云的服务,的确也带来了很多便利。

摄像头不同于其他智能设备,这是一个极其敏感的,打破了「网络」与「现实」边界的设备,他可以直接看到、听到镜头里的一切。

好几年前,我通过一个业内的渠道,得知某摄像头的云存储服务,曾经将用户的监控视频未加密处理,就直接存在某公有云的 bucket 里。从那之后,我就再也没在家里开启过摄像头。

前几年,众多在各种乱七八糟网站上泄漏出来的视频,想必大家也都有所耳闻。基于上面种种考量,我决定自建监控方案。首先说下我的这套监控方案的优缺点。

自建对比原厂优缺点 ​

项目 自建方案 原厂
操作性 ❌ 需要折腾,挺麻烦 ✅ 上手即用
安全性 ✅ 本地存储,内网访问,理论可与外网完全隔离 ❌ 云服务、云存储,存在隐私泄露的可能
经济性 ✅ 无额外费用 ❌ 云存储一般都要额外收费
存储空间 ✅ 无空间限制,理论可无限拓展存储 ❌ 云存储空间有限,时长有限
共享性 ❌ 不方便共享给家人 ✅ 便捷分享控制
外网访问 ❌ VPN 访问(可开启公网权限:但不建议) ✅ 直接公网即可访问
HomeKit 支持 ✅ 支持 ❌ 大多不支持

设备清单 ​

设备 品牌 型号 价格
摄像头 TP-Link 800万全彩云台无线网络摄像机 TL-IPC48AW 全彩 ¥279
NAS 群晖 DS216+ ¥0 (旧设备)
外接硬盘盒 淘宝工厂店 2.5寸 USB3.1 Type-C 硬盘盒 ¥21
外接监控存储SSD 饥饿鲨OCZ Arc100 240G固态硬盘 ¥0 (旧设备)

这次除了摄像头是新购的,其他都是原有的老设备。这里的花销大头是群晖的 NAS,理论上如果你有其他 NAS,或者开源的软路由什么的,也能实现类似的功能。无非就是需要花费更多时间折腾罢了。

系统架构 ​

名称 说明 配置难度
SurveillanceStation 群晖自带监控中心套件
Home Assistant 开源智能家庭家庭解决方案,与米家和 HomeKit 等联动
Node-RED 开源的流程编排工具,配合 HA 实现各种事件处理自动化

上面就是我的这套监控系统的核心架构,除了SurveillanceStation属于傻瓜级上手可用,后面的Home AssistantNode-Red都需要花费一定的时间和学习。由于我之前就有一些 HA 和 Node-RED 的使用经验,这次只是集成下 SurveillanceStation,所以整体花费的时间还是比较少的。

配套 App ​

名称 说明 安卓 iOS Web 实时监控 回放 推送信息
Home Assistant HA 的客户端
DS CAM 群晖监控套件的配套 App
Bark 自建的 iOS 的消息推送服务
Telegram 极其方便和自由的社交 App

摄像头选购 ​

搭建自己的监控体系,基本的要求就是摄像头需要支持ONVIF协议或者rtsp协议,这是安防设备的通用协议,方便用户自己集成到各种系统中。

购买摄像头之前,需要务必确认摄像头支持ONVIF协议,小米的许多摄像头就不支持。

这次我购买的摄像头是TP-LinkTL-IPC48AW,属于比较经典的系列。

  • 支持ONVIF协议
  • 支持 4K 15帧录制。
  • WIFI 2.4G
  • 红外夜视(方便夜晚和弱光环境监控)
  • 支持 Micro SD 卡存储
  • 1个RJ45口,支持网线直连

硬伤是 WIFI 不支持 5G。除了基础的硬件功能,还有各种云服务支持,AI 检测什么的,但是由于我也没打算用自带的 App(美区 App Store 居然还没 TP-Link App) ,所以也无所谓了。

关闭摄像头外网访问 ​

防止摄像头能访问外网,首先就是关闭摄像头的外网访问权限,仅限内网用户访问。

按照以下步骤设置即可:

  • 给摄像头设置固定 IP
  • 在路由器层禁止该 IP 访问外网
  • 如果使用 OpenWrt 等网关,在防火墙层设置屏蔽规则
shell
#TP-Link 摄像头 防火墙规则
iptables -I FORWARD  -m mac --mac-source E4:DD:66:82:DE:F4 -j DROP
iptables -I FORWARD -s 10.0.0.12 -d 10.0.0.0/16 -j ACCEPT
iptables -I FORWARD -s 10.0.0.0/16 -d 10.0.0.12 -j ACCEPT
iptables -I FORWARD -s 10.0.0.12 -j REJECT

我家使用的是小米路由器,网关使用的是 OpenWrt,除了在小米的控制台关闭外网权限,同时在防火墙设置里,通过添加过滤摄像头IP和MAC地址的规则,禁止摄像头访问外网。

设置完毕后,可以看到这个时候再访问TP-Link自带的App,提示是设备离线状态。但是如果你是在局域网通过内网 IP 访问,依旧可以正常访问。

如何配置外网访问 ​

将家庭内网暴露到外网,或者内网穿透,是一个与「监控」系统本身不太相关的问题。

从安全的角度考量,我不希望摄像头直接暴露在外网,所以我只是在有需要的时候,通过zerotier来访问家里的监控系统。实际上还有一些其他方案,比如WireGuard等,这里就不做讨论了。

接入群晖 SurveillanceStation ​

群晖的SurveillanceStation是一个非常成熟的监控套件,这个也是我们的监控系统的核心。之所以选择群晖,是因为我家里有一台群晖。其他厂商也有类似的监控套件,也有第三方的开源解决方案,建议大家就自行研究了。

这部分的内容,以ONVIF 群晖 NAS等关键词组合搜索,网上有很多教程,我在这里就不赘述了。

将监控视频存储到外接 USB 硬盘 ​

我的群晖DS216+是双盘位,使用两块机械硬盘做了RAID1

由于监控的过程中一直会写入硬盘,会对硬盘寿命造成严重影响。强烈建议非专业需求,不要将监控视频与其他数据混存。

为了解决这个问题,我使用了一块没用的240GSSD,通过USB3.0接口外接到群晖上,作为监控的存储盘。上图就是我目前实际挂载的样子,这样有个好处:

  • 不影响主硬盘的寿命
  • USB3.0 搭配 SSD 硬盘,读写速度更快,回放时更流畅

虽然这样做,不如直接将视频存储在 NAS 的主硬盘上保险,但是我的目的主要就是看看最近的视频,监控录制的视频也不需要长期存储,所以这样做对于我来说倒是一个更经济合理的选择。

由于群晖默认不允许外接硬盘作为存储盘,这里需要一定的小技巧,外接硬盘挂载成正常的文件路径,需要通过SSH登录到群晖,配合ln -s软链的方式挂载外接硬盘。

首先登录群晖的SurveillanceStation,在网络摄像机>编辑摄像机>录制 里添加新的存储器,这里默认是只能在群晖主硬盘空间上存储,这里我命名camera_storage

接下来需要通过SSH登录到群晖,进入跟路径,找到当前挂载的盘符,这个时候可以看到外接的硬盘已经被挂载到了/volumeUSB1/目录下。

shell
# 通过 SSH 登录群晖,通过软链将外挂硬盘挂载到共享文件夹,突破群晖的限制
ssh  luolei@10.0.0.5
ln -s /volumeUSB1/usbshare/ /volume2/camera_storage
#DSM 7.0 后,上述挂载的方法需要做一些调整,具体方法见下

接下来再去编辑摄像机>录制里,把录制存储器选择为刚刚创建的camera_storage,这样后续监控视频都会默认直接保存在外接硬盘上了。

重要更新 ​

DSM 7.0 后,上述挂载的方法需要做一些调整,不能再通过软链接ln -s的方式映射盘符。简要说明新的步骤

  • 依旧同上添加新的存储器
  • 控制面板 > 任务计划 > 新增触发的任务
  • 创建任务:用户选择root (必须使用root),事件选择:开机
  • 任务设置 > 用户定义的脚本 : mount -o bind /volumeUSB1/usbshare /volume2/camera_storage
  • 重启之后,再去 SurveillanceStation 里设置即可

接入 HomeKit ​

如果想在 iPhone 的 Home App 里看到监控视频,需要通过Home Assistant将摄像头接入到 HomeKit。这一部分也有比较多的教程和文章,我找了几篇比较详细的,供大家参考。

在这里分享一个小优化点,HA 自带的ONVIF协议添加摄像头看到的实时画面延迟较大(我自己观察约5秒),如果使用WebRTC Camera取流可以大大降低延迟。具体的步骤可参考:

监控效果 ​

截止到一步,家庭监控的接入录制存储实时监控回放等功能都已经实现了。目前我主要就是通过群晖的DS Cam来进行实时监控和回放。

DS Cam有网页版和 App 版,使用起来还是很方便的,在监控画面有动静的时候,在时间轴上也有标记,方便快速定位。

出门在外时,一般我就使用 App 查看监控,TP-Link 这个摄像头本身支持语音通话,但是通过ONVIF接入群晖这么一圈后,就没有了,暂时还没找到解决方案,没法远程逗狗了,算是一个小小的不方便。

同样的,通过 iOS 自动的Home也能看到监控画面,但是 HomeKit 的实时监控画面延迟也是比较大的,大概是每10秒刷新一次。通过Home Assistant,则是可以实现更低延迟的监控画面。

进阶:动静通知和自动化管理 ​

接下来就是一些进阶的功能了,主要是为了解决监控动静提醒,以及离家在家模式的自动化管理。

首先思考下面几个问题?

  • 我家的摄像头是否需要24小时监控?
  • 不同位置的摄像头是否需要不同的监控策略?
  • 如果有人在特定时间出现在监控中,是否需要提醒?

现在不少人家里都有摄像头,有些摄像头是用来对着门口,有些摄像头对着客餐厅,有些摄像头对着儿童房的婴儿床。不同的位置,对于监控的需求是不一样的。

我家目前就装了一台摄像头,对着客厅和大门玄关入口。实际上,我并不太需要这个摄像头一直录制。毕竟有时候,我在家还是比较洒脱和坦荡,我不希望自己的一举一动都被摄像头记录下来。

这个时候,就可以通过SurveillanceStationHome AssistantNode-RED来实现一些自动化的功能了。

一句话来介绍这个的原理: 通过自定义规则,触发webhook,来切换摄像头的开关和触发通知。

群晖 SurveillanceStation 支持自定义操作规则,在这里我设置了三个规则:

  • 在家模式: 人员在家时,关闭摄像头
  • 离家模式: 人员离家时,开启摄像头
  • 动静通知: 监控画面出现动静时,发送通知

这个的原理也十分简单,以在家模式举例,通过设置事件源WebHook/外部设备,群晖暴露了一个WebHook接口,通过普通的网络请求触发这个接口,就可以关闭摄像头。

动静通知模式,则是反过来的操作,当监控画面出现动静时,群晖会主动向我的第三方Node-Red定义的接口触发请求,Node-Red会执行抓取当前画面、推送画面到TelegramBark等通知渠道的动作。

HA自动化:离家自动开启摄像头 ​

如果想做到更加智能和自动化,比如离开家时自动开启摄像头,这个时候就需要通过Home Assistant来实现了。

Home Assistant里的设置>自动化与场景支持自己创建自动化。可以通过设置不同的if then 逻辑来控制不同的设备和流程。

以我的需求为例,当我的手机离开家时(地理围栏),就会自动发送一条通知到我的手机,并请求我的群晖的WebHook API开启摄像头。

yaml
rest_command:
  bark_push:
    url: https://push.bark.demo/notification
    method: POST
    payload: '{"body": "{{ body }}","title": "{{ title }}","icon":"https://static.is26.com/share/icon-vm.png"}'
    content_type: "application/json; charset=utf-8"
    verify_ssl: true

  camera_on:
    url: http://10.0.0.5:5000/webapi/SurveillanceStation/Webhook/Incoming/v1?token=iQRJyuOYPIZODrWMRfT
    method: GET

  camera_off:
    url: http://10.0.0.5:5000/webapi/SurveillanceStation/Webhook/Incoming/v1?token=iVufyERsmJZEM1UJ7M
    method: GET

这只是我的一个简单的示例,同理,当你回到家时,希望什么时候关闭摄像头,也可以根据你的实际需求,实现更复杂的自动化功能。上面我使用到了 HA 自带的RESTful Command功能。有关Home Assistant的自动化RESTful Command配置,可以参考下面的文章。

有关「离家」和「在家」模式,可以参考下下面的讨论:

Node-Red自动化:推送Telegram ​

弄完上面的流程后,监控的大多需求都已经满足了,最后我们再来补全出现动静>截取摄像头画面>推送图像这个环节。

群晖本身自带的动静通知功能,也能通过DS Cam接受通知,这里我没有使用自动的方案,而是通过Node-Red来实现。

首先放流程图,整个的流程逻辑是这样的:

  • Node-Red 暴露一个http接口/api/camera/capture,用于被动接受群晖的WebHook请求
  • Node-Red 通过网络请求,调用群晖Surveillance API接口,获得当前所有摄像头信息
  • 继续通过网络请求,调用群晖Surveillance API接口,截图指定摄像头的实时画面
  • 最终将获得的截图发送到 Telegram

同理,最终的通知截图也可以使用钉钉企业微信等其他渠道,我选择 Telegram 是因为之前已经集成了,加上 Telegram 对内容几乎完全没有审核,相对而言我更放心点。

复制下面的 JSON ,导入到 Node-Red,修正对应的账号、密码、IP、端口和 Telegram bot ChatId 即可

展开查看 Node-Red 流程配置文件
json
[
  {
    "id": "a07703f3752fc82a",
    "type": "tab",
    "label": "抓取群晖摄像头推送到Telegram",
    "disabled": false,
    "info": ""
  },
  {
    "id": "3902801a557a738e",
    "type": "www-request",
    "z": "a07703f3752fc82a",
    "name": "获取sid",
    "method": "GET",
    "ret": "obj",
    "url": "",
    "follow-redirects": true,
    "persistent-http": true,
    "tls": "",
    "x": 880,
    "y": 300,
    "wires": [["cabd07b9c918bd13"]],
    "inputLabels": ["输入"],
    "outputLabels": ["输出"]
  },
  {
    "id": "6e7a90e85b1d736b",
    "type": "change",
    "z": "a07703f3752fc82a",
    "name": "设置群辉用户名、密码、摄像头ID",
    "rules": [
      {
        "t": "set",
        "p": "dsm_account",
        "pt": "msg",
        "to": "username",
        "tot": "str"
      },
      {
        "t": "set",
        "p": "dsm_passwd",
        "pt": "msg",
        "to": "password",
        "tot": "str"
      },
      {
        "t": "set",
        "p": "dsm_camera_id",
        "pt": "msg",
        "to": "1",
        "tot": "str"
      },
      {
        "t": "set",
        "p": "dsm_domain",
        "pt": "msg",
        "to": "10.0.0.5",
        "tot": "str"
      },
      {
        "t": "set",
        "p": "dsm_port",
        "pt": "msg",
        "to": "5000",
        "tot": "str"
      }
    ],
    "action": "",
    "property": "",
    "from": "",
    "to": "",
    "reg": false,
    "x": 420,
    "y": 240,
    "wires": [["c18d4fe0633037a4"]]
  },
  {
    "id": "833f9be33b550d84",
    "type": "www-request",
    "z": "a07703f3752fc82a",
    "name": "GetSnapshot",
    "method": "GET",
    "ret": "bin",
    "url": "",
    "follow-redirects": true,
    "persistent-http": true,
    "tls": "",
    "x": 890,
    "y": 500,
    "wires": [["45ea4313512d68a6", "1957d8308081700b"]]
  },
  {
    "id": "c18d4fe0633037a4",
    "type": "function",
    "z": "a07703f3752fc82a",
    "name": "url_sid",
    "func": "msg.url = `http://${msg.dsm_domain}:${msg.dsm_port}/webapi/auth.cgi?api=SYNO.API.Auth&method=login&version=3&account=${msg.dsm_account}&passwd=${msg.dsm_passwd}&session=SurveillanceStation&&format=cookie`;\nconsole.log(msg)\nreturn msg;",
    "outputs": 1,
    "noerr": 0,
    "initialize": "",
    "finalize": "",
    "libs": [],
    "x": 690,
    "y": 240,
    "wires": [["3902801a557a738e"]]
  },
  {
    "id": "f3df28b20f02dd3e",
    "type": "function",
    "z": "a07703f3752fc82a",
    "name": "url_snapshot",
    "func": "var sid;\nsid = msg.payload.data.sid;\nmsg.url = `http://${msg.dsm_domain}:${msg.dsm_port}/webapi/entry.cgi?version=9&id=${msg.dsm_camera_id}&api=\"SYNO.SurveillanceStation.Camera\"&method=\"GetSnapshot\"&profileType=0&_sid=${sid}`;\nreturn msg;",
    "outputs": 1,
    "noerr": 0,
    "initialize": "",
    "finalize": "",
    "libs": [],
    "x": 690,
    "y": 500,
    "wires": [["833f9be33b550d84"]]
  },
  {
    "id": "cabd07b9c918bd13",
    "type": "switch",
    "z": "a07703f3752fc82a",
    "name": "",
    "property": "payload.error.code",
    "propertyType": "msg",
    "rules": [
      {
        "t": "nnull"
      },
      {
        "t": "else"
      }
    ],
    "checkall": "true",
    "repair": false,
    "outputs": 2,
    "x": 570,
    "y": 400,
    "wires": [["3902801a557a738e"], ["f3df28b20f02dd3e"]],
    "inputLabels": ["输入"]
  },
  {
    "id": "dcb9b48e6b3c1fee",
    "type": "inject",
    "z": "a07703f3752fc82a",
    "name": "手动触发",
    "props": [
      {
        "p": "payload"
      },
      {
        "p": "topic",
        "vt": "str"
      }
    ],
    "repeat": "",
    "crontab": "",
    "once": false,
    "onceDelay": 0.1,
    "topic": "",
    "payload": "",
    "payloadType": "date",
    "x": 140,
    "y": 220,
    "wires": [["6e7a90e85b1d736b"]]
  },
  {
    "id": "45ea4313512d68a6",
    "type": "image",
    "z": "a07703f3752fc82a",
    "name": "",
    "width": "360",
    "data": "payload",
    "dataType": "msg",
    "thumbnail": false,
    "active": true,
    "pass": false,
    "outputs": 0,
    "x": 1120,
    "y": 500,
    "wires": []
  },
  {
    "id": "c8427c30a83ac775",
    "type": "telegram sender",
    "z": "a07703f3752fc82a",
    "name": "",
    "bot": "ff58d9095b6d2cda",
    "haserroroutput": true,
    "outputs": 2,
    "x": 1420,
    "y": 780,
    "wires": [[], []]
  },
  {
    "id": "1957d8308081700b",
    "type": "function",
    "z": "a07703f3752fc82a",
    "name": "图像转TG格式",
    "func": "msg.payload = {\n    chatId: 10000, \n    type: \"photo\",\n    content: msg.payload,\n    caption: \"家里有动静,监控提醒\"\n};\nreturn msg;\n",
    "outputs": 1,
    "noerr": 0,
    "initialize": "",
    "finalize": "",
    "libs": [],
    "x": 880,
    "y": 740,
    "wires": [["c8427c30a83ac775"]]
  },
  {
    "id": "02fe4781ca3fbb7b",
    "type": "http in",
    "z": "a07703f3752fc82a",
    "name": "/api/camera/capture",
    "url": "/api/camera/capture",
    "method": "get",
    "upload": false,
    "swaggerDoc": "",
    "x": 90,
    "y": 280,
    "wires": [["6e7a90e85b1d736b", "fb5663502a675986"]]
  },
  {
    "id": "fb5663502a675986",
    "type": "http response",
    "z": "a07703f3752fc82a",
    "name": "",
    "statusCode": "200",
    "headers": {
      "code": "0"
    },
    "x": 600,
    "y": 680,
    "wires": []
  },
  {
    "id": "ff58d9095b6d2cda",
    "type": "telegram bot",
    "botname": "拉布管家",
    "usernames": "",
    "chatids": "10000",
    "baseapiurl": "",
    "updatemode": "polling",
    "pollinterval": "300",
    "usesocks": false,
    "sockshost": "",
    "socksprotocol": "socks5",
    "socksport": "6667",
    "socksusername": "anonymous",
    "sockspassword": "",
    "bothost": "",
    "botpath": "",
    "localbotport": "8443",
    "publicbotport": "8443",
    "privatekey": "",
    "certificate": "",
    "useselfsignedcertificate": false,
    "sslterminated": false,
    "verboselogging": false
  }
]

有关这部分的参考文章:

配置好了之后,建议在群晖摄像头的事件检测那里再精确配置下动作检测区域和灵敏度,避免误报。

总结 ​

从购买摄像头到最终的监控系统搭建,整个过程大概花了我一个下午的时间。基本上所有的步骤,都能在网上找到详细的教程和资料。

除了上面所说的功能,理论上,只要想法够多,还能实现更多的功能,比如:

  • 想要云端存储,配置个同步任务,把监控视频同步到云盘即可(哪怕家里被人放火烧了,也能看到过去的视频)
  • 想要人脸或者宠物识别: 接入图像识别 API,实现人脸识别(实现更精确的动静通知)

小小的捣鼓一番,获得一个功能基本完善,但是更安全和经济的自主监控方案,还是一次挺有趣的折腾过程。

2023 Mac mini 外挂硬盘升级方案: 打造 2TB 苹果电脑

2024年9月17日 19:05

今年 618,给老婆升级了一套办公电脑。打造了一台拥有 2TB 硬盘的 Mac。

为什么要升级电脑? ​

我家目前有几台 Mac 电脑

  • MacBook Pro 14 英寸(2020 年) M1 16GB + 512GB: 我公司配的工作电脑,也是我的主力机
  • MacBook Pro 15 英寸(2014 年中)  i7 + 16GB + 500GB: 老婆的主力工作电脑,用了这么多年还挺给力的
  • MacBook Air 13 英寸(2018 年) i3 + 8GB + 256GB: 我老婆的便携笔记本

老婆是半个视频创作者,主要工作需要用到 Adobe 和视频剪辑 Final Cut Pro ,尽管在 macOS 上的 Final Cut Pro 已经针对影像处理进行了许多优化,但这台将近 10 年的老机器在系统升级后终于开始显露疲态,开始承受过大的负担。

为什么选择 Mac mini? ​

在购买这台 Mac mini 之前,我也有考虑过 MacBook Pro M1 Pro 和 2023 年新款 MacBook Air 15 英寸 的方案,我老婆个人则想要买 iMac。

  • MacBook: 老婆已有 MacBook,加上确实没有移动办公需求,有点浪费。Apple 笔记本产品线 16G + 512GB 规格组合起售价到 10K 价位以上,不太划算。
  • iMac 24 英寸: iMac 实际上也是个不错的选择,但是现在的 iMac 依旧只有 M1 芯片,加上只有 24 英寸的小屏幕。放弃。

考虑到家里其他外设,4K 显示器、键盘鼠标也都齐全了,评估了下当前的需求和设备。最终发现了 Mac Mini 配合雷电硬盘盒外接大容量固态硬盘组合。

说来我对这个组合并不陌生。我在 2017 年就曾经写过文章,分享 iMac 通过 USB3.0 外接硬盘提速的方案。

这么多年过去了,苹果的内存和硬盘依旧金贵,最终我还是采用 Mac mini 加外挂硬盘的方案,规格和价格如下,全部购自京东渠道。

硬件清单 ​

  • 💻 Mac mini: M2 + 16G 内存 + 256G 硬盘 💰 ¥ 4718
  • 💾 固态硬盘: 海力士 P44 Pro 2TB 💰 ¥ 877
  • 📼 硬盘盒: WERO 雷电 3/伪 USB4 双协议💰 ¥ 662
  • 💵 价格总计 ¥ 6257

除了 Mac mini 是通过北京消费券优惠满 6000-600,再叠加店铺满 6000-200  稍微麻烦的方案,其他硬件都是 618 优惠价格。

开箱 ​

这就是今天的配件主角,WERO 的雷电硬盘盒和海力士 Solidigm P44 Pro 。现在 SSD 价格极其优惠,虽然甚至不到 600 就能买到国产的高速固态硬盘,但是由于我是打算给 Mac mini 用作系统盘,所以比较看着稳定性和质量,海力士这块 P44 Pro 算是第一梯队的高档产品,也不便宜。

这个就是 WERO 硬盘盒,采用雷电 3 和外挂 USB4 协议的双芯片方案,最高支持 40Gbps 传输速率,我也有看过阿卡西斯 acasis 的 TB405 硬盘盒,但是两个品牌优惠后价格并没有差太多,最终选择了 WERO。如果预算有限,并且只给 Mac 使用,也可以选择单雷电 3 芯片的盒子,价格会便宜不少。

很久没有关注硬件市场了,一开始看到 SOLIDIGM 这个牌子我还纳闷这是啥,后来查了下资料发现原来是海力士收购英特尔固态硬盘业务后成立的品牌,也算是第一梯队。我是在京东自营店购买的这款硬盘,其包装盒上标明其制造工厂位于美国特拉华州。

盒子插入 WERO 硬盘盒,WERO 盒子有附赠螺丝刀和散热贴。M2 硬盘发热量大,WERO 这种盒子铝合金散热还是有必要的。

安装好后,将盒子连接到 Mac mini 背面靠近 HDMI 的雷雳 4 接口,就可以跑满速度了。WERO 这个盒子我看评价说颜值在线,实际观感还可以,我买的雾面银色。

安装系统到外接硬盘的步骤也比较简单:

  • 格式化硬盘 AFPS 格式 + GUID 分区
  • 在 App Store 下载最新 macOS
  • 安装 macOS 到外接硬盘即可

安装完成后,重启电脑并设定全新的系统环境。此时,系统已经运行在外接硬盘上,测速读写速度可达 2700MB/s。

再放一张 mini 内置自带 256GB 和外接 2TB 硬盘的读写速度对比。

总结 ​

M2 + 16GB 内存 + 2T 硬盘组合,总价 6.3K,对于我来说,还算是一个性价比不错的方案。😄

优点 ​

  • M2 芯片 + 16GB 的内存,性能足够应付大多数的工作场景。
  • 2TB 的固态硬盘: 速度足够快,基本不用再担心空间不够。

缺点 ​

  • 外挂一个硬盘,占了一个雷雳接口,另外一个雷雳接口我目前接了一个雷电拓展坞。
  • 肯定没有内置硬盘稳定: 虽然我之前 iMac 外挂 USB 硬盘用了几年也没出过啥问题。

如果你没有现成显示器键盘,个人建议还是买 MacBook Pro M1 16GB + 512GB 的版本。但是如果你的其他条件满足,Mac mini + 外挂硬盘不乏性价比不错的选择。

❌
❌