技术

我把小米电视交给 AI 改造：一次远程桌面替换的 18 项验收 我家那台 Redmi X65，桌面首页常年堆着剧集推荐和会员角标，关不掉。2026 年 11 月 1 日，我把这活儿整个交给了电脑上的 AI：它读文档、下安装包、连电视、装 App、授权、最后逐条验收，我只负责在电视上按几个遥控器键，以及决定哪些事不能做。【关键词：#Aerial #ADB #小米电视】 01｜我的活儿只有一句话，剩下的是它的 我给 AI 的任务很短：把开源桌面 Aerial 装到我家电视上，让它接管开机和主页键，别动我原来的任何系统应用。 之所以交给 AI，而不是自己照着文档敲，是因为这类活儿有一个特点：步骤都不难，难的是不出错。查系统版本、选对应的包、给权限、确认守护服务真的挂上了、跑完 18 条验收还要逐条比对输出——人做会累，做漏一条也不知道漏在哪。AI 做这件事刚好合适，它不会因为「第 9 条看着没问题」就跳过去。 选 Aerial 的理由也很实在：它参照 tvOS 做了 Android TV 桌面，没有广告和推荐流，只有 App、壁纸和 Apple TV 的 114 段航拍屏保；Kotlin 写的，MIT 许可证；仓库 2026 年 10 月 20 日建仓，到 11 月 1 日已经 8377 星、697 个 fork，1.75、1.76 一天内各发一版。官网是 aerial.qust.me。 ...

VS Code 这次没重做 UI：它把 Agents 窗口那套设计系统搬回了编辑器 原文：Modernizing the VS Code UI 作者：Lee Murray（VS Code 团队；具体职位未在博客中注明） 来源：Visual Studio Code Blog，发布于 2026 年 10 月 15 日 我读 Lee Murray 在 2026 年 10 月 15 日发布的《Modernizing the VS Code UI》，先找的是改版目的。官方给出的方向很明确：理清十余年累积的界面层级、减少干扰，用同一套设计基础承接手动编辑和 AI 智能体（agent）会话，同时保留信息密度、定制能力和熟悉的操作习惯。【关键词：#VSCode #现代UI #Agents】 顺着这个目的，我更关心的是：这套设计为什么先在 Agents 窗口落地，搬回编辑器后，又为老用户改了什么。下文依据博客发布时的预览状态解读，设置建议未经本地实测。 01｜我先分清：这次改的是哪一层 我先看了博客里的时间线：2015 年首发预览，2016 年加入编辑器标签页，2019 年更新树状控件，2023 年推出 Dark Modern / Light Modern 主题。今天看着理所当然的界面，其实是一块块加上来的。 原文把这种演进叫作逐个组件推进。工作台（workbench，也就是包围代码区的导航、面板、标签等界面）里的各个部分，未必遵循同一套间距、字号和控件规则。我把它理解成一间不断添家具的书房：每件家具单看都能用，放在一起，尺寸和动线却未必协调。 我理解这次改版的边界是：保留文件编辑方式，改造工作台外壳。 密集的文件导航、多编辑器分组和已有操作习惯，都要继续照顾。沿着原文，我把推进过程串成三步： 颜色先动：以 Dark 2026 / Light 2026 两个新主题为起点，一起考虑工作台配色和代码语法高亮。 共享设计系统在 Agents 窗口里跑通：这个窗口在 2026 年早些时候进入 Stable（稳定版），当时仍是 Preview（预览功能）。它围绕发起智能体会话、跟踪进度、检查结果组织界面，为统一间距、字号、界面底色和控件规则提供了落地场景。 把同一套规则铺到编辑器外壳：活动栏（Activity Bar）、侧边栏、编辑器组、面板、标签、状态栏，成为应用共享规则的区域。 读到这里，我才把 Agents 窗口和这次改版连起来：直接编辑文件时，重点是快速找文件、切分组；委托智能体做事时，重点是看会话状态、下一步动作和修改结果。两种工作流需要不同布局，但字体、间距、颜色和控件可以共用一套规则。Agents 窗口是实验室，编辑器外壳是推广地，并不意味着要把编辑器也摆成一个聊天窗口。 ...

我把家庭影音库搬上了 Jellyfin，在威联通 NAS 上跑影院 周末中秋，我顺手在小米电视上点开 Jellyfin，全家一起在小米电视上看蓝光电影，配合外接的音响，深度沉浸式体验。【关键词：#Jellyfin #威联通NAS #豆瓣刮削】 01｜为什么我决定把家庭影音库"上云"到自己家 Jellyfin + 威联通 NAS + 豆瓣刮削，是当前最稳的组合。 第一套是硬盘 + USB 直接插电视：小米电视对 NTFS、exFAT 支持不稳定，字幕经常错位、外挂音轨识别不出来。老婆为了追剧投屏到平板，看着看着突然音画不同步，最后只能回电视重新加载。 第二套是某品牌 NAS 自带的媒体中心：海报墙难看得像 Windows 资源管理器，4K 原盘直接卡死，更别提硬解。 Jellyfin 是 Plex 当年的开源分支，GPLv2 协议，功能覆盖 Plex 90% 但完全免费、移动端不限并发、不限画质，已经不是"爱好者玩具"了。 02｜Jellyfin 是什么，为什么我选它而不是 Plex/Emby Jellyfin 是一个用 C# 写的开源媒体服务器，主项目托管在 GitHub 上。核心逻辑很简单：你把电影、电视剧、动漫按"影片/季/集"的目录结构放在硬盘上，Jellyfin 扫描这些目录、帮你拉元数据（封面、简介、演员表、评分）、生成海报墙，然后在你家里的电视、手机、平板、电脑上提供播放服务。它不替你存数据，只替你整理数据和播放——这是和 Plex、Emby 最大的共同点。 为什么我最后选 Jellyfin 而不是 Emby： Emby 在 2018 年把服务端核心从开源转成了"个人免费 + 商业付费"的双轨制，移动端解锁、硬件转码都已经收进 Emby Premiere 订阅，¥448 永久。我不是付不起，是不想为一个本来开源的东西再付一次订阅费。 Jellyfin 是当年 Emby 开源部分 fork 出来的，主要开发者是从 Emich（Emby 创始人）出走的团队，协议是 GPLv2，社区、客户端、插件生态全都独立维护。它不是"想白嫖 Emby 的项目"，是有完整产品节奏的独立项目。 客户端生态基本一致：Android TV、Apple TV、iOS、Android、Web 全平台都有原生客户端，体验上 90% 的功能我用不到差异。 03｜威联通 NAS Docker Compose 部署：把硬解、目录、权限一次说透 ...

公司抠到不发笔记本只给瘦终端 + Ubuntu，我反而把开发体验拉满了 中秋放假前大家都基本上半开工状态，我就好好吐槽下现在的办公环境 和 使用Ubuntu的优劣势吧。 没有笔记本、没有 MacBook、没有 ThinkPad——："公司全部走云桌面，瘦终端连过去就是工作机，系统只有 Ubuntu 和 Windows 两个选项" 不是被冒犯，是真的想笑——一家号称做技术驱动的云公司，自己员工用的机器居然是公司虚拟化的超卖主机。真的在 Ubuntu 云桌面上干高频容器化开发、跑 K8s、写 AI Coding Agent ，有些时候也挺感谢这种漂移， 缺点是分辨率和画质损失。 我在家开发和剪视频 使用macos系统，在公司使用瘦终端+云电脑Ubuntu 【关键词：#Ubuntu #瘦终端 #Linux 开发】 01｜公司抠到这种程度，我也是服了 先说吐槽部分。这家公司是真的抠： 不发笔记本——MacBook Pro 不可能、ThinkPad X1 不可能、外星人也不可能。能摸到的只有一台 国产的瘦终端（瘦客户端：本身不运算、只负责接显示器和传键鼠信号，所有计算在云端跑），长得跟网吧机差不多，桌面还贴着公司的资产编号。 外设自带——键盘鼠标自己买，显示器公司只给一台 27寸的AOC的2K显示器。 网络隔离——公司网络完全隔离公网，大多数均无法正常访问和查询资料。 02｜Ubuntu 上的开发体验，比想象中香太多 我选 Ubuntu 不选 Windows 的判断，不是因为 Linux 性能更好（这个说法不够精确），而是因为在虚机资源受限的环境里，Ubuntu 把更多资源还给了真正的工作。这件事在瘦终端云桌面场景下，被包过的具体数字放大到了"体感级别"。 第一，资源开销是真的少。同一台 4 vCPU + 8 GB 内存的云桌面： Windows 11 桌面空载内存 2.5–4 GB，后台 Defender、OneDrive、Teams、各种 UWP 进程持续吃 CPU/IO； Ubuntu 22.04 桌面（GNOME）空载内存 800 MB–1.2 GB，关掉 snap（Ubuntu 自家的封闭包管理）相关服务后能压到 600 MB。 这台云桌面我要跑 Docker Desktop、K8s 集群（kind）、VS Code + 远程开发模式、tmux、Zellij、AI Coding Agent——剩下的 6 GB 内存，Ubuntu 几乎全给我；Windows 那边一开机就被吃了 3 GB。 ...

Cloudflare Python Workers 终于 GA：把 Python 塞进 WebAssembly 扔到全球边缘，我看到的甜点与坑 【关键词：#Cloudflare Workers #Python Serverless #边缘计算】 2026 年 9 月 21 日，Cloudflare 把 Python Workers 从 preview 拉到 GA——两年的预览期正式结束。我盯这个特性看了很久，它的实质是把 **Pyodide（CPython 编译到 WebAssembly 的运行时）**直接跑进 Cloudflare 边缘网络（300+ 城市）。不是"Cloudflare 也支持 Python 了"那么简单。甜点、坑、适用人群，下面分开讲。 01｜为什么我盯了两年 边缘计算这两年最大的痛点：Lambda 只能在某区域跑，冷启动还要几秒。Cloudflare Workers 一直靠 V8 isolate（Chrome V8 引擎里的轻量沙箱，每个请求一个独立执行环境）把冷启动压到 50ms，但只支持 JS/TS。Python 程序员想在边缘跑代码，要么忍受 Lambda 的延迟，要么把 Python 编成 WASM 自己部署——两条路都不甜。 Cloudflare 在 2024 年开始 preview Python Workers，走的路线是 Pyodide + WebAssembly：让 CPython 直接跑在 V8 isolate 里，不走容器。这样三件事成立： ...

云主机推荐，一年不到 200 元搞定 VPS，我把博客和服务都搬出了亚马逊云 今天想聊一个老被问到的问题：VPS 是什么、和 AWS 有什么不一样、为什么国外有这么多便宜的小厂云？ 这也是我自己这两年手上有几台 VPS 跑在 nube、racknerd 这类小厂上之后，慢慢讲明白的事。这篇文章就把答案一次性说清楚，再把我为什么选 nube 和 racknerd 的判断也写下来。【关键词：#VPS #小厂云 #性价比部署】 01｜什么是 VPS，先把概念说清楚 VPS 全称是 Virtual Private Server，虚拟专用服务器。你可以把它理解为：一台物理服务器被切成几台、几十台，每一台都给你开一个独立的"操作系统房间"，门牌号、CPU、内存、硬盘都是给你的。 你拿到 root 账号之后，想装什么装什么、想重启重启，跟一台物理机唯一的差别是 CPU、内存、硬盘、网络带宽是和别的小物理机共享的，邻居会跟你抢。 这是和"虚拟主机"（shared hosting）最关键的区别：虚拟主机你拿到的是"账号"，服务器上跑什么你看不到、改不了；VPS 你拿到的是"一台机器"，完全是你的。 这也是和"云主机"（cloud server）有区别的地方。云主机本质也是 VPS，但更"云"：可以临时扩容、按秒计费、自带负载均衡、跨可用区复制、自动备份。AWS EC2、阿里云 ECS、DigitalOcean Droplet 严格说都是云主机——它们是 VPS 的"企业升级版"。 VPS 的虚拟化技术主要是两种： KVM：每台 VPS 有自己独立的内核，性能隔离更彻底，绝大多数小厂商和大厂云默认都用 KVM。 OpenVZ / Virtuozzo：共享内核，单台机器更便宜但跑不了 Docker、跑不了需要内核模块的东西，正在被逐步淘汰。 所以当你看到一家"年付 10 美元"的小鸡，基本可以默认是 KVM 虚拟化 + NVMe SSD + 1Gbps 共享带宽。你拿到一台 VPS 之后能干的事，比你想象的多——博客、家庭相册 Immich、轻量爬虫、CI runner、个人邮箱、密码管理器、Notion 替代品、学习项目，只要不爆内存都跑得动。 02｜国外为什么冒出这么多小云厂商 ...

我把家里的相册搬出了 Google Photos，让 Codex 在 NAS 上替我搭了一套 Immich 去年我家里加起来有将近 6 万张照片和短视频，散落在三台手机、一台旧笔记本和一个云盘备份里。Google Photos 我用了 4 年，体验上确实是消费级做得最好的产品之一，但 2021 年 6 月 Google 关闭免费无限原图画质、引入"省空间副本"和"原画质"两条产品线之后，我就一直在找替代品——真正让我下定决心的不是订阅费，是 Takeout 导出后目录结构混乱、EXIF 大面积丢失、人脸聚类完全没带出来这件事。我不想再依赖一个我无法控制、也无法完整带走的相册服务。【关键词：#Immich #自建相册 #AI 部署】 我想回到"照片在我家硬盘上、AI 帮我整理、随时能下载原图"的状态。折腾了两小时、让 Codex 把一台 NAS 上的 Immich 完整搭起来之后，我得出了一个有点反直觉的结论：自建相册的最大成本不是设备，是人；现在人这部分可以交给 AI。这篇文章就是把这套部署和日常使用讲清楚——如果你也在云相册和自建相册之间犹豫，希望它能帮你省一次选择。 01｜为什么我决定从远离云上存储，并跑路 Google Photos和iCloud 我用了 ，体验上确实是消费级做得最好的产品之一：识别准、分享方便、跨设备同步丝滑、动回忆像会讲故事。但当它把"原画质"和"省空间副本"分成两条产品线、对免费用户悄悄走压缩路径时，问题就从"功能"变成了"信任"——我不能接受一个替我保管家庭照片的产品，由它自己决定哪些照片可以、哪些不可以保留原始画质。 隐私边界：家里人的生活照会被持续上传到一个我不掌控的服务器；公司项目截图、家庭证件、孩子学校活动照片夹杂在一起，外人看不到，但平台看得到。 导出不自由：Google Takeout 我用过几次，导出的目录结构混乱、EXIF 大量丢失、人脸聚类结果完全没有。换平台等于重新整理一次。 价格曲线：Google One 2TB 在美国是 $9.99/月、在中国是 ¥68/月。照片涨到 2TB 之后，每个月固定花这笔钱就只为"看照片"这件事，性价比急速下降。 这三条任何一条单看都不致命，三条叠加在一起就是"我要把这件事握在自己手里"。 02｜Immich 到底是什么，为什么我选它而不是 Nextcloud 或者 PhotoPrism 自建相册的开源选项里，2026 年 9 月这个时间点能打的不多。Immich 是其中唯一一个把 Google Photos 当作"对标对象"做产品的项目，不是把它当作 NAS 的附加功能。功能矩阵看下来基本覆盖 Google Photos 的 90%： ...

💻 【技术日报】| 2026-08-27 📰 NVIDIA Groq 3 LPX 进入全面量产，为 Agentic AI 提供极速推理 NVIDIA 宣布其 Groq 3 LPX 推理加速卡正式进入全面量产阶段。该卡隶属 Vera Rubin 平台，专门针对 Agentic AI 工作负载优化。在 Artificial Analysis 基准测试中，Groq 3 LPX 运行开源 Agentic 模型 Gemma 4 31B（100,000 token 上下文）时创下 3,400 output tokens/s 的纪录。Nebius 成为首个采用该加速卡的 AI 云服务商。相比当前最优替代方案，Groq 3 LPX 可为 Agent 和延迟敏感型工作负载带来 4 倍响应速度提升。 来源：NVIDIA Newsroom | 时间：2026-08-26 📰 OpenAI GPT-5.6 全系登陆 AWS Kiro，推理成本降低 82% OpenAI 与 AWS 联合宣布，GPT-5.6 模型家族（Sol、Terra、Luna）已全部集成至 AWS Kiro——亚马逊面向规格驱动开发（spec-driven development）的 AI 编程环境。GPT-5.6 Terra 在 Kiro 环境中运行 Terminal-Bench 2.1 基准测试时，任务完成成本降低约 82%。Kiro 将产品需求转化为结构化实施计划后，再交由模型执行多步编码任务，全程提供上下文支撑，减少迭代次数和 token 浪费。 ...

💻 技术日报 | 2026-06-29 HackerRank 开源 ATS 引发评分随机化争议 来源： danunparsed | 时间：2026-06-29 HackerRank 开源了其招聘 ATS 系统 hiring-agent，在 LinkedIn 和 Reddit 获得数千点赞。但实测发现：同一份简历、同一个命令，ATS 给出的分数在 66-99 分之间大幅波动。若公司录用线设为 85 分，候选人将有 65% 的概率"随机"落选。 技术分析： 该系统工作流程为：PDF 解析 → LLM 6 次调用提取结构化信息（工作经历、教育、技能等）→ 汇总后统一评分。默认模型为 gemma3:4b，temperature 设为 0.1。问题在于评分维度的"软判断"（如项目复杂度、工作经历质量）本质上依赖 LLM 的主观输出，即使极低 temperature 也无法消除随机性。 关键数据： 同一简历跑 100 次，分数范围 66-99 技术技能评分稳定（8/10 出现 98 次），因为是硬 checklist 项目评分波动剧烈，取决于 LLM 当下"心情" 工作经历评分：实习生和资深工程师均得 25/25——因为 prompt 缺乏评判标准 换用 Gemini 后分数集中在 48-64，但仍存在 28% 的"随机失败率" 深层问题： LLM 的非确定性不是 bug，无法通过调参修复。这是用主观判断替代客观标准的根本性设计缺陷。开源 ATS 降低了使用门槛，却也放大了这一缺陷的危害面。 ...

💻 技术日报 | 2026-06-27 Linux 7.2 显著提升匿名管道写入性能 来源： Phoronix | 时间：2026-06-27 Linux 7.2 在匿名/无名管道性能上实现大幅提升，特别是针对 shell 管道场景的写操作性能优化。这是近年来针对管道子系统的首次重大改进，对频繁使用管道的高性能场景有直接影响。 技术细节： 优化了内核中管道缓冲区的管理逻辑，减少了锁竞争 对 write() 系统调用的路径进行了简化，降低了上下文切换开销 基准测试显示部分管道密集型工作负载提升超过 30% 意义： 管道是 Unix/Linux 最基础的 IPC 机制之一，这一优化将惠及所有使用 shell 管道、进程池、流水线架构的场景，尤其对 CI/CD、数据处理管道等场景有直接价值。 🔗 Linux 7.2 Improves Anonymous/Unnamed Pipe Performance For Shell Pipelines Go 语言空指针检查争议：过度防御还是必要保障？ 来源： Konrad Reiche Blog | 时间：2026-06 一篇关于 Go 语言中「过度空指针检查」现象的技术文章引发开发者社区热议。作者指出，很多 Go 代码中存在对 nil 指针的过度防御性检查，这些检查不仅降低了代码可读性，还可能掩盖真正的逻辑错误。 核心观点： Go 的 nil 和其他语言（Java、C#）的 null 语义不同，不应照搬防御模式 过度检查会让 panic 变成错误返回值，失去了 Go 的「快速失败」设计哲学 正确的做法是在边界的「信任边界」处检查，而非在内部逻辑中处处设防 讨论延伸： 这与 Go 社区近年倡导的「let it crash」理念相呼应，引发了关于错误处理最佳实践的重新思考。 ...