聊负载均衡，大多数人张口就是 Nginx。但往流量入口再退一层，还有一个更老、更快、长在 Linux 内核里的方案：LVS（Linux Virtual Server）。
它比 Nginx 老得多——章文嵩博士 1998 年发起，现在已经是内核标准的一部分。它快的原因也简单：工作在内核空间的 INPUT 链上，数据包根本没到用户态就被改写转发了，没有进程、没有 socket、没有用户态开销。 " xgfone/snippet 仓库里这篇《LVS 负载均衡原理及安装配置详解》把原理、四种转发模式、八种调度算法和 Keepalived 高可用实验整理得很完整。这篇拆开讲，重点说清楚一件事：四种模式的区别，本质是"响应走不走调度器"的区别。
推理引擎这几年的主流叙事是通用性：一个 vLLM/llama.cpp 跑所有模型、所有硬件，哪里都能搬。
halogen-flash 反着来。它是 Qwen3.8-Flash-Next 这个模型在 AMD Strix Halo（gfx1151）这块芯片上的专用推理引擎——每个 kernel 只为这一块 GPU 和这一个模型家族手写，没有通用运行时、没有可移植层、没有 fallback 路径。
代价写在脸上：只跑在这一块硅片上，权重格式连 llama.cpp 都打不开。收益也写在脸上：32K 长上下文问答，端到端比这块硬件上最快的公开成绩还快约 4 倍——而且靠的不是把精度压得更狠。
AI 帮你回消息的工具不少，绝大多数的做法是：读对话 → 让大模型编一句回复 → 发出去。听起来顺，用起来心慌——它替你说的每一句话，出了事算谁的？
Jev 聊天助手（jev-chat-jarvis）把顺序和权力都改了：先判断，再写字，绝不发送。一个判断模型先告诉你对方真实意图、危险等级（1-9）、该不该马上回，再让生成模型起草 3 条候选，排序后填进输入框——发送键永远你自己点。开源（MIT），Android 11+，还有 macOS 和 Windows 姊妹版。 " 这个项目值得写的不是"AI 回消息"，而是它对边界的处理：不 hook、不改包、不碰账号、不读数据库、不自动发送。每一条都是刻意的克制。
" 家里有没有这种设备：运营商送的智能插座，厂商的 APP 停服了，插座本身好好的，继电器能吸合能断开，就是没人管它了——一块标准的"云僵尸"硬件。
CMPOWER W1 就是这么个东西，中移铁通的智能插座，基于乐鑫 ESP8266。作者 Slaven 干的事很干脆：官方 APP 没了，那就重写一版固件，把这块硬件救活。固件开源，MQTT 协议控制两个继电器，配任何 MQTT 客户端就能远程控制。
这个项目小，但五脏俱全——配网、协议、状态上报、按键交互一条链路全有，是理解"一个 IoT 设备固件到底由什么组成"的绝佳样本。
" 刷到一条爆款视频，老板说"照这个给我来 50 条"。
以前的流程：拆解脚本 → 找素材 → 剪辑 → 改字 → 再来 49 遍。现在的流程是——把视频丢给你的 Coding Agent：
/hypit Clone this video: /path/to/video.mp4
Hypit 做的事，是给 AI Agent 一套做视频的语言和系统。它克隆的不只是脚本，是完整的工作流：素材、字幕、B-roll、特效，全部可编辑、可复用、可批量出变体。
" 让 LLM 判断"这封邮件是不是钓鱼"、"该转给哪个部门"、"用户是不是要流失"，你得到的是什么？
一段文字。然后你写代码去解析这段文字，祈祷它格式稳定，祈祷它没有幻觉，祈祷置信度那句话是真心话。
Laya 换了一条路：判断不该生成，判断该测量。它是一个不自动回归的"系统 1"决策引擎——输入状态和类型化问题，一次前向传播直接输出结构化决策。单问题 33 毫秒（T4 实测），没有任何文字生成，没有东西可解析，就没有东西可幻觉。
Laya 是一个 33 毫秒出决策的 System 1 引擎——但那个数字是 T4 GPU 的。手头一台幽兰笔记本（格蠹科技 RK3588 方案，ARM64，无独立显卡），能不能跑？跑起来什么性能？怎么把它变成一台离线的工单分流机？ " 这篇是完整的部署方案。结论先说：能跑，单次判断预期亚秒级，把它当"离线决策盒子"完全成立；但预加载策略和性能预期要按笔记本的规矩重新算。
先盘点硬件和模型，方案才不是空中楼阁。
幽兰本这边：
" Sunniwell Z96A，原本是运营商云桌面（VDI）用的廉价云笔电，RK3568B2 方案，4GB 内存 + 32GB eMMC，二手市场上一两百块的东西，典型的"电子废品再就业"选手。
上一期给幽兰本（RK3588，8 核，16GB）做了 Laya 部署方案，这次换成 Z96A，难度完全不是一档：4 个 A55 小核、没有大核、内存只有 4GB——Laya 最小的 checkpoint 是 322M 参数，fp32 权重就占 1.3GB，再算上 PyTorch 运行时，内存账从第一页开始就是紧的。
很多人装了 gh（GitHub CLI），用法停留在两个：gh pr list 和 gh pr create。偶尔回 GitHub 网页点两下，感觉 gh 是个可有可无的补充。
翻一遍 gh 的官方手册，会发现格局完全不对：gh 是把整个 GitHub 平台搬进终端的官方通道——PR、Issue、Actions、Projects、Codespaces、Release、Secret，全在命令行里。而且 2026 年的手册里出现了两个新信号：gh agent-task 和 gh skill——GitHub 官方把 Agent 也接进了这条通道。
扫描版 PDF 是阅读体验的灾难：整页是一张图，不能选中文字，字号放大脑袋得跟着歪，Kindle 上更是没法看。
OCR 能解决，但自己跑 OCR 模型要么吃显卡要么调参到天亮。pdf2epub-paddle 的思路很直接：识别这件事扔给百度飞桨的云端 API，本地只管编排——提交任务、盯进度、切章节、打包 EPUB。
整个项目就一个 Python 脚本，349 stars，MIT 协议。
