Technology

Document Picture-in-Picture API与任意元素画中画实现

好消息，之前只有视频元素才能画中画，现在任意元素都能独立成画中画窗口了，小屏摸鱼有了新选择。

张鑫旭-鑫空间-鑫生活 · ZH

Nice！继text-wrap之后，Flex布局也支持balance排版了

balance均衡排版是一种特殊的排版方式，目前只有内联元素应用text-wrap:balance实现，现在好消息，Flex布局也支持balance排版了，我们可以配合flex-line-count进一步实现瀑布流布局。

张鑫旭-鑫空间-鑫生活 · ZH

算了，还是讲下named-feature() @supports规则检测吧

named-feature() @supports规则检测本身没什么好多的，就是CSS规范里显式登记的特殊特征变化检测，但是其支持的特性背后的故事却是值得好好说道说道的。

张鑫旭-鑫空间-鑫生活 · ZH

懒加载图片新支持了sizes=”auto”属性，其作用是？

太不容易了，终于不需要在<img>元素的sizes属性里面写媒体查询了，auto关键字崭新来袭，只要是懒加载图片，浏览器自动判别使用哪一个srcset图片，比以前省心多了。什么，不知道我叽里咕噜说的啥？点进来看看不就知道了。

张鑫旭-鑫空间-鑫生活 · ZH

ai-memory：换个 CLI 接着干的 agent 记忆层

同时用好几个编码 agent 的人都遇到过：Claude Code 干到一半退了，换 Codex 打开同一个目录，上一个知道的事一件都不剩。 ai-memory 是个 Rust 单二进制，用 MCP 加生命周期钩子给这些 CLI 接一层共享的长期记忆，不用手动 write_note ，也不用把总结在会话之间复制粘贴。 读它代码最大的收获不是功能表，是那十五条不变量——每一条后面都挂着一个别人踩过的坑的 issue 号。 要解决的问题 它把记忆沉淀成一棵 git 版本化的 markdown 树，作者管这叫 Karpathy 式的 LLM wiki：页面随时间被增量编译、就地版本化，语义知识累积，情节日志衰减。旁边一个 SQLite 索引负责检索。 关键是这两者的主从关系——下面那张图里，从左到右只有一条主链，而真相始终在最左边落盘的那一份文件里。 真相在磁盘上 作者在设计文档里把这条列为「最大的架构决策」，并列了三个选项：数据库为主、markdown 为主、数据库为主但按需导出。选的是第二个，理由四条： 备份与迁移就是 git clone 或 rsync 一个目录——这是需求里明写的； Karpathy 那套模式本身就是磁盘上的 wiki，用导出步骤伪造会丢掉「能在 Obsidian 里直接翻」这个性质； 数据库可以从文件全量重建，损坏可恢复，反过来不行； 任何能读 ~/.ai-me

阁子 · ZH

munder-difflin 的多 agent 协调实现

刷到这个仓库的时候是被名字骗进去的，munder-difflin，《办公室》里那家最差的纸业公司，主管 Michael 也搬了过来当了这层楼的老板。演示视频里一堆像素小人在办公室里走来走去，互相发消息的时候还有信封在桌子之间飞，看着像个玩具。 后来翻到一份叫 docs/message-queue.md 的文档，一千多字只讲一件很窄的事：一个真实的 CLI 只有一根输入行，而想用它的不止你一个。这篇就记一下里面几处认真想过的地方。 项目概况 munder-difflin 是个 Electron 桌面应用，把你已经在终端里跑的 agent CLI 包起来当 agent 用，README 里列了十种： claude 、 agy 、 codex 、 grok 、 kimi 、 qwen 、 opencode 、 crush 、 pi 、 copilot 。每个会话是一个真进程，同时是办公室地板上的一个小人，走去哪个工位取决于它在用哪个工具。 到今天的 HEAD（ 92461ab ），从 5 月 31 日起 710 次提交， src/ 下 185 个 ts/tsx 文件、53,166 行， index.ts 4,582 行， hive.ts 2,464 行，38 个测试文件跑在 node --test 上。版本 0.4.4，README 自己写的状态是 working prototype，这

阁子 · ZH

OpenViking 的上下文组织与检索

前一篇翻完一个把 agent 摆进办公室的项目，顺手又去看了火山引擎开源的这个，两个都在解决 agent 记不住事，路子完全不一样。 OpenViking 的做法是别让 agent 去查一个黑盒向量库，让它像开发者一样用 ls 、 tree 、 find 翻自己的上下文。记忆、资源、技能统一挂在 viking:// 这个虚拟文件系统下，每个目录带一份摘要和一份概览，检索先定位到目录再往下钻。 这篇记一下它的结构、检索流程，以及一致性那块的取舍。 项目概况 不是薄封装，是三种语言各管一层。到今天的 HEAD（ afa5aae9 ），从 1 月 29 日起 2,033 次提交。Python 那层是服务和业务逻辑， openviking/ 下 619 个文件、148,477 行；Rust 那层是文件系统 RAGFS， crates/ragfs/ 78 个文件、40,673 行；C++ 那层是向量与标量索引引擎， src/ 65 个文件、12,260 行，自带 croaring 位图、leveldb、rapidjson、spdlog 这些依赖，是真的在写索引引擎不是调库。 协议是 AGPLv3， crates/ov_cli 和 examples/ 单独给 Apache 2.0。背后有论文，VikingMem，arXiv:2605.29640，VLDB 2026 收录，README 说开源的

阁子 · ZH

magpie 本地语义搜索

星标过的仓库再没打开过第二次，截图记得长什么样却翻不出来，书签埋在几层文件夹里，一小时前复制的那段东西不知去向，想开的应用埋在三层菜单下面。这些东西的共同点是存的时候顺手，找的时候只能靠运气。 喜鹊爱叼亮闪闪的东西回窝，然后忘了放哪儿，所以叫 magpie。按 Alt+Space 唤出面板，把还记得的那点描述打进去，或者丢一张图进去，回车。 本地跑，不联网，不扫全盘。下面写的是 v0.1.20。 源 Tab 在四个标签之间切：本地、星标、Web、剪贴板，顺序和默认打开哪个都能在设置里改。应用不单独占标签，在本地标签里作为置顶命中出现。每个源有各自的索引方式和排序选项。 本地文件 手动加进来的目录，里面每个文件都能按名字找到，认识的格式连内容一起进全文索引。 78 种纯文本与代码扩展名，整篇读入，默认单文件上限 4 MB，设置里可调到 16、64 或不限 PDF 由 pdf-inspector 抽取文字，上限 64 MB；扫描件与乱码抽不出正文，仍按文件名留在索引里 docx、xlsx、pptx 按 zip 拆开，取出带文字的 XML 部分去掉标记 压缩包、二进制只索引文件名 jpg、jpeg、png、webp、bmp、gif 不走文本，交给视觉模型 mp4、mkv、mov、avi、webm、m4v 抽帧之后也按内容搜，见下一节 Shift+Tab 在「全部 / 文本 / 图片 /

阁子 · ZH

FrontierAgent 的上下文压缩与重复抑制

长程 agent 跑着跑着就废了，这件事大家都见过，但很少有人把它拆成具体的失败模式再拿数据说话。 FrontierAgent 是 Apodex 前两天开源的 agent 运行时，翻代码时发现它把两个失败模式量化过：一个是上下文压缩触发得太晚，子 agent 被端点打死；另一个是压缩把旧结果换成占位符之后，模型开始一遍遍重发同一个搜索。 这两件事还是同一个环的两端。 项目概况 仓库里是一套 agent 运行时加终端产品加评测套件，两种自带工作流：ReAct 是单个有状态的 agent 自己查、读、写、跑命令；Agent Team 是一个协调者维护任务板，把独立的活拆给并行子 agent，收报告再合成。同一套引擎也驱动它们评测自家模型的 benchmark runner。 目录边界划得很清楚， frontier_agent/ 是通用循环、调度、注册表、AgentBus 和观察者， plugins/tools/ 是各类工具实现， workflows/ 是两条流水线的编排与提示词， apodex/ 是终端和 Docker 那一层， benchmarks/ 是评测。 13 万行 Python，79 个测试文件，Apache 2.0。不过提交只有 22 次，首次提交是 2026-08-24，也就是说这是内部仓库整理之后一次性倒出来的，不是在开源状态下长出来的。看的时候心里有数就行，代码质量与

阁子 · ZH

lamarck 按真实调用进化全部 skill

现在优化 skill 的工具都是一次挑一个：你选中某个 skill，给它写一批测试 prompt，跑评委打分，改完再跑一遍。有几十上百个 skill 的时候这条路走不通，瓶颈根本不是优化算法，是你没空逐个去挑、逐个编测试用例。 lamarck 换的是这个前提：装一次，之后所有已装的 skill 全部进入观察，不用挑、不用写用例、不用配置。它在后台看真实调用，攒够同一类证据才对某一个提出一处改动，改完立刻验，变差就退回去。 观察范围 一次挑一个的做法，隐含假设是你知道哪个 skill 有问题。实际上你不知道，你只知道最近某个任务干得不顺，至于是哪条指令没写清楚、还是压根触发错了 skill，事后很难复盘。而那些一直安静工作的 skill 里有多少段落是从来没被用到过的死重，更没人去查。 全量观察把这两件事都变成了副产品。每个 skill 各自积着自己的账，谁反复出同一类问题，看账本就知道；谁的哪一段九十天零引用，也是账本里现成的数字，可以直接变成一条修剪提案。挑选这一步被取消了，不是因为有更聪明的挑法，是因为不需要挑。 前提是它必须常驻，而常驻的东西一旦贵，两天就会被卸掉。所以省这件事在这里不是优化项，是能不能成立的问题，后面好几处设计都是从这一条推出来的。 信号来源 同类工具的信号来自专门造出来的考场，基准分数，或者人编的测试 prompt 加评委打分。lamarck 用的是生产遥

阁子 · ZH

LEANN 的重算式向量索引

向量检索有个不太好看的账：索引往往比原始数据还大。六千万条文本切块，用传统办法建索引要 201 GB，而那堆文本本身没那么大。想在自己笔记本上索引邮件、浏览记录、聊天记录，这道门槛就卡在硬盘上。 LEANN 的选择是索引里干脆不存向量，只存一张剪过的图，搜索时走到哪一跳就现算哪一跳的向量。同样那六千万条，索引降到 6 GB。 论文是 arXiv:2506.08276 ，伯克利那批人写的，作者名单里有 Ion Stoica、Matei Zaharia、Joseph Gonzalez。 存储开销 摘要里的原话是索引「需要存储高维嵌入和大量索引元数据，其总大小可能是原始数据（例如文本块）的数倍」。占地方的是那一堆浮点数，文本本身反倒是小头。 一条 768 维的 float32 向量是 3 KB，六千万条就是 180 GB。存储曲线跟着向量维度和条数走，跟你实际有多少字没多大关系。 LEANN 的做法是把这部分从磁盘上删掉，改成用的时候现算。论文说索引最多能缩小到原来的五十分之一，占原始数据约 5%，而检索精度和延迟保持在可比范围。仓库里给的对比表是这样： 六千万条维基文本：传统 201 GB，LEANN 6 GB，省 97% 两百一十万条 DPR：3.8 GB 对 324 MB，省 91% 七十八万封邮件：2.4 GB 对 79 MB，省 97% 三万八千条浏览记录：130 MB 对 6

阁子 · ZH

keepane，AI 时代的终端多路复用

终端复用器是给坐在键盘前的人写的，分屏、切窗口、断线重连，前提都是有个人在看着。现在 pane 里跑的常常是 agent，人不在跟前，要的东西就变了。 keepane 是按后面这个前提写的。每个 pane 有名字、有收件箱、有工作模式，pane 之间能互发消息，也能让对方直接执行一条命令；同一台机器上如此，配过对的两台电脑之间也一样。人、脚本和 agent 走同一套，agent 那侧还能走内置的 MCP 服务端。 终端断了 pane 里的程序照跑，跑完了手机、桌面或者 webhook 会告诉你；扫个二维码就能在手机上看每个 pane 在干什么、往里打字。agent 用了多少 token、花了多少钱、上下文还剩多少，也都摆在面上。tmux 的键、命令和配置在这里照用。 起因 一开始是想找个现成的用，找了一圈没有合预期的。能用的那些都还是按「有人看着」写的，pane 里跑的是什么它不关心，更不会让两个 pane 说上话。于是自己写，第一个提交的标题是「wmux: tmux-style terminal multiplexer for Windows」，那会儿还叫 wmux。 真用起来才发现分屏解决的只是摆放。几个窗口里各跑一个 agent，想让它们配合起来，眼下就两条路。一条是用各家 agent 自己的协议，一家一套，谁也不认谁，换个工具就得重接一遍。另一条是用 agent 内部那套派

阁子 · ZH

高尿酸血症确诊

我在 2024 年底左脚大拇指根部曾肿痛一周 ，结合多年体检高尿酸结果，怀疑是痛风。但后来没有什么症状，身体也一直很好，就没去医院看。 最近一年多一直通过跑步降低体重 ，减少了 9~10kg 体重。攀岩保持在一周两到三次。自己在家查血尿酸，一直在 500~600 之间，偶尔在 480 左右。虽然戒掉了含糖饮料，也无饮酒，作息规律，精神放松（不用工作了）。但尿酸一直降不下来。...

云风的 BLOG · ZH

对抗系统的桌游

最近比较难找到人一起开桌游，所以我玩了不少人对抗系统规则的游戏。 桌游中人和人对抗的比较常见，设计一套规则、让玩家在这套规则下博弈；但需要找到（足够水平的）人一起玩。虽然很多桌游也会设计 solo 模式，但大多是设计一个自动机来模拟对手。这会损失相当的博弈性，要么变成了可预测的系统行为，要么沦为半随机事件。而游戏规则的原始设计中通常都会有相当部分依赖人之间的博弈才有趣。例如，我最喜欢的桌游《银河竞逐》在第一个扩展包中就加入了自动机，允许 solo ，但我觉得远没有和人玩有趣。 也有设计得不错的自动机。例如之前介绍过的《Star Trek : Captain's Chair》在玩家社区中就公认单人模式非常有趣，我也只一个人玩过。还有我前段超喜欢的《deep future》也是一个多人对抗游戏，但很多玩家包括我也喜欢一个人玩。我甚至还制作了 solo 模式的电子版本 。 如果一开始就围绕玩家对抗系统规则去设计，去掉人和人之间的博弈，那么游戏会有不太一样的体验。关于这种 PvE 游戏，去年我在整理卡牌构筑类桌游规则时提过不少：Legendary 系列、Aeon's End 系列（以及后续的 Astro Knights ）、XenoShyft 、Legacy of Yu、Kingdom Legacy，等等。还有今年我玩过的 voidfall 和 spirit island 。 这类游戏一般

云风的 BLOG · ZH

用地标改进 A star 寻路的启发函数

今天读到 redblobgames 写的关于如何改进寻路算法中启发式函数的文章 ，感觉很棒。我们可以用很简单的方法改进 A star 算法中的传统计算欧氏距离的方式实现启发函数的方法。 这意味着，可以直接利用之前写好的寻路模块 改变一下启发函数，就可以大幅提升性能。...

云风的 BLOG · ZH

银河竞逐的乐趣和策略

银河竞逐是我最喜欢的桌游之一。我曾经为它写过两篇 blog ：银河竞逐的设计 及 如何教人玩银河竞逐 。 最近我教会了小孩玩这个游戏，我自己也在电脑上玩了 200 多盘。主要是在 BGA 上和人对战，以及在官方授权的电子版 中挑战最高难度的 AI 。和过去喜欢多人混战不同，这段时间我主要玩双人规则。虽然在线下，我玩这个游戏的水平超过一般桌游玩家，但在线上，我只有略高于 40% 的胜率。说明这个游戏的策略还有很高的天花板我没能摸到。和最高难度的 AI 相比，我的胜率超过了 50% 。 这是为数不多有着极深的策略，却又超快节奏的桌游。在 BGA 上默认只给两个选手各 3 分钟的总时间，通常在 5~6 分钟就可以完成一局游戏。应了它名字里的 Race ，玩起来颇有竞速的感觉。我在游戏过程中总是觉得思考时间不够，如果纯凭借经验（感觉）打牌，很容易输掉。特别在最后两个回合，往往需要精算自己和对手的各种可能性，找到取胜的可能。胜负比分通常差距非常小，运气成分虽然存在，但总有希望通过计算挽回。而判断上的一个小的失误却会迅速落下对手一大截。 这个游戏核心目标就是：在触碰结束条件的那一刻，比对手拿到更多的 VP 。新手则往往理解成单一的如何更高效的获取 VP 。这两者是有区别的。因为比拼获取 VP 的效率往往会减少 PvP 游戏的对抗性，变成埋头干自己的事情。初玩 RFTG 的时候，我也一度觉得这是

云风的 BLOG · ZH

暑假的英语补习

对云豆来说，这个暑假特别长。 他小学毕业了，6 月中就已放暑假，9 月 1 日方开学进入初中。自然没有学校布置的暑假作业。我不想他整个假期都沉迷在短视频和蛋仔派对中，所以每天给他安排了英语学习。 7 月初，我记录过对孩子之前的英文辅导。先前，我用的《英语在用：剑桥初级英语语法》给他补习基础语法。学习的效果还可以，原本以为可以在暑假过渡到中级本。但读了两天后就发现完全进行不下去。倒不是中级语法难度大了很多，而是他本身的阅读能力跟不上。 阅读不仅仅是 “英文” 语言的问题，换成中文也一样。所以，我换了一套书：《Basic Reading 1200 Key Words》...

云风的 BLOG · ZH

Caves of Qud 初体验

关注 Caves of Qud（卡德洞窟）很久了，之前一直没下决心玩。最近发现它更新了多语言支持分支，在 steam 创意工坊里有了一个初步的中文 mod ，便试了试，果真很有趣。 我玩传统 Roguelike 很久了。最早是在 GBA 上用干电池玩特鲁尼克大冒险（以及后来风来的西林系列）。在 2008 年的时候就试过 NetHack 还尝试过做汉化 。ps. 现在已经有针对最新 5.0 版 NetHack 的中文版本了，在 AI 翻译的加持下，体验很不错。后来沉迷过很长时间（600+ 小时）的 Rogue's Tale，甚至它的官方中文一开始就是我翻译的。还玩过一点 CDDA , Cogmind ，以及关注过 RogueBasin 上很多很多的 Roguelike 。 除了在游戏机上被彻底改造过的不可思议迷宫系列，很少见针对手柄交互改造的特别好的 Roguelike 。这或许是 Roguelike...

云风的 BLOG · ZH

点老救世记的深度体验

我最近重新玩了两百小时的《Dotage 点老救世记》，对这个游戏有了很多新的认识。之前是在今年初玩了一百多小时，对这款一个人花了十年以上时间做的游戏相当佩服。经过近 400 小时的游戏时间，我对这个游戏的理解慢慢发生了变化。有不少游戏设计方面的东西值得研究，但却很难说清楚，需要用文字整理一下。 这是一款关于规划和选择的游戏。它固定了回合数（标准模式下，共 310 回合），所以玩家实际上需要规划整个游戏过程，无法通过控制游戏发展节奏来决定是速通（注：实际上有手段更快结束并赢得游戏）还是慢慢发展。但玩家可以选择怎样规划这个游戏过程：是把发展节奏拉长，平缓延续到游戏结束；还是快速发展到一定阶段，停留在某个规模对抗系统直到终末。这会导致非常不一样的游戏体验，并没有最优通解。 本质上，玩家需要积累健康、希望、温度、自然四个维度的点数，对抗终局的天灾点数：即玩家在终局点积累的对应点数需要和系统设定的点数相当。在整个游戏过程中，还会动态设定若干检查点（事件），在检查点处，玩家积累的点数会重置，根据检查点处点数和系统设定的点数比较，来决定获得增益还是惩罚。...

云风的 BLOG · ZH

QWERTY 键盘布局的发展历史

在我最初学习键盘打字时，曾今为看似随机的键盘字母排列困惑不已。当时为找到一个字母就需要看半天键盘，我觉得键盘按字母表次序排列不好吗？当时流行的解释是：机械键盘在输入时，一些常用的字母组合的连杆，在快速连续击打时容易卡在一起。所以，现在的 QWERTY 排列“旨在降低打字速度”。这个说法至今广为流传，而我最近读了一篇 Koichi Yasuoka 和 Motoko Yasuoka 写的论文《 On the Prehistory of QWERTY 》，更清晰的描述了 QWERTY 键盘的发展脉络，我觉得可信度更高。 论文分两个部分，第一部分阐述了先进流行的 QWERTY 键盘是怎样演变到今天的布局的，第二部分驳斥了“旨在降低打字速度”的说法。后者源于 1980 年东京大学 Hisao Yamada 教授发表的论文《 A Historical Study of Typewriters and Typing Methods 》。论文中有这么一段话： ： Hence the original keyboard arrangement...

云风的 BLOG · ZH

程序员阅读清单：我喜欢的 100 篇技术文章（1-20）

清单 1. 《开发者应学习的 10 件有关“学习”的事》 2. 《开发者如何管理自驱力》 3. 《用 Go 语言分析 10 亿行数据，从 95 秒到 1.96 秒》 4. 《在开发高质量软件上的花费值得吗？》 5. 《错误抽象》 6. 《谷歌技术写作课：编写有帮助的错误信息》 7. 《深入 Python 字典——一份“可探索”的解释》 8. 《愿意让自己显得愚蠢》 9. 《我们为什么坚持使用 Ruby on Rails》 10. 《ChatGPT 是互联网的一张模糊的 JPEG 图》 11. 《重新发明 Python notebook 时学到的教训》 12. 《断点单步跟踪是一种低效的调试方法》 13. 《作为“胶水”》 14. 《拥抱苦差事》 15. 《也许是时候停止推荐〈代码整洁之道了〉》 16. 《我在编辑时考虑的事》 17. 《修复流行 Python 库的内存泄露问题》 18. 《UI 设计原则》 19. 《你的数据库技能不是“锦上添花”》 20. 《预估开发时间很难，但还是得做》 结语 程序员们也许是互联网上最爱分享的群体之一，他们不仅喜欢开源自己写的软件，也爱通过写文章来分享知识。从业以来，我阅读过大量技术文章，其中不乏一些佳作。这些佳作中，有些凭借深刻的技术洞见令我深受启发，也有些以庖丁解牛般的精湛手法解释一项技术，让我读后大呼过瘾。 作为“爱分享”的程序员中的一份子

Python 工匠 · ZH

程序员阅读清单：我喜欢的 100 篇技术文章（21-40）

清单 21. 《人生短暂》 22. 《有“产品意识”的软件工程师》 23. 《Python 的 range 不是迭代器》 24. 《有关 TLS/SSL 证书的一切》 25. 《让困难的事情变容易》 26. 《The Hiring Post》 27. 《13 年后，我如何用 Go 写 HTTP 服务》 28. 《Rust std fs 比 Python 更慢！？》 29. 《选择乏味的技术》 30. 《Python 3.10 中的结构化模式匹配》 31. 《你想要的是模块，不是微服务》 32. 《我不喜欢 Go 语言默认的 HTTP Handlers》 33. 《对人类更友好的“超时”与“取消”》 34. 《20 年软件工程师生涯，学到 20 件事》 35. 《为什么你的 mock 不工作》 36. 《实用的 Go：来自真实世界的编写可维护 Go 程序的建议》 37. 《编写系统软件：代码注释》 38. 《编写易于删除，而不是易于扩展的代码》 39. 《如何提出好问题》 40. 《每天写代码》 结语 程序员们也许是互联网上最爱分享的群体之一，他们不仅喜欢开源自己写的软件，也爱通过写文章来分享知识。从业以来，我阅读过大量技术文章，其中不乏一些佳作。这些佳作中，有些凭借深刻的技术洞见令我深受启发，也有些以庖丁解牛般的精湛手法解释一项技术，让我读后大呼过瘾。 作为“爱分享”的程序员中的一

Python 工匠 · ZH

程序员阅读清单：我喜欢的 100 篇技术文章（41-50）

清单 41. 《抽象泄露法则》 42. 《如何设计一个好的 API 及其重要性》 43. 《我构建软件的原则+实践“让无效状态不可表示”》 44. 《不，不是编译器的问题，从来都不是》 45. 《关于在除夕前一天换了一个洗衣机的故事》 46.《你的函数是什么颜色？》 47. 《健康的文档》 48. 《如何像人类一样做代码评审》 49. 《关于 Python 3.13 你需要了解的一切 - JIT 和 GIL》 50. 《入行 14 年，我还是觉得编程很难》 结语 程序员们也许是互联网上最爱分享的群体之一，他们不仅喜欢开源自己写的软件，也爱通过写文章来分享知识。从业以来，我阅读过大量技术文章，其中不乏一些佳作。这些佳作中，有些凭借深刻的技术洞见令我深受启发，也有些以庖丁解牛般的精湛手法解释一项技术，让我读后大呼过瘾。 作为“爱分享”的程序员中的一份子，我想当一次推荐人，将读过的好文章分享给大家。我给这个系列起名为 《程序员阅读清单：我喜欢的 100 篇技术文章》 。 受限于本人的专业与兴趣所在，清单中的文章对以下几个领域有所偏重： 程序员通识、软件工程、后端开发、技术写作、Python 语言、Go 语言 。 下面是阅读清单的第三部分，包含第 41 到 50 篇文章。 系列索引： 第一部分（1-20）： 链接 第二部分（21-40）： 链接 第三部分（41-50）： 链接 清单 41.

Python 工匠 · ZH

我看见的软件设计：胖瘦客户端

kubectl apply 的故事 客户端侧 apply 客户端侧 apply 的局限性 服务端侧 apply 小结 软件设计建议 1. 善用服务端功能零成本复用、变更实时触达的特点 2. 别让服务端因客户端的定制需求过载 烤肉店故事：如何调味？ 识别服务端复杂度的过载风险 3. 客户端的计算力是独特的优质资源 烤肉店故事：谁来烤肉？ 善用客户端的独特资源 “自助烤肉”的弊端 结语 文末彩蛋 设计软件是一个不断产生疑问、解决疑问的过程。设计者们面对一个需求，会产生许许多多的疑问，在这些疑问中，有一个看似幼稚，却直击灵魂的小问题： “业务逻辑（复杂度）放在哪？” 项目每引入一个新功能，所增加的总复杂度几乎是确定的，但如何把这些复杂度分配到各模块中，其中的方式方法却变化无穷。 比如，一个采用“客户端/服务端”架构的软件，在增加某项业务功能时，工程师们可能会发现：它既可以（主要）放在服务端实现，也可以放在客户端实现。不同决策直接影响后续的分工模式、开发效率以及功能扩展性等方方面面。 此类场景中，一种常见的设计策略是 “瘦客户端，胖服务端” ，“胖/瘦”指的并非身材，而是组件所承担的职责多寡。采用“瘦客户端”设计，代表主要的业务逻辑均由服务端承担，客户端尽量简单。 让我们通过 kubectl apply 命令的故事，看看如何把“瘦客户端”理念应用在现实世界的软件中。 kubectl app

Python 工匠 · ZH