2026-01-27 23:23:51
看了下 DeepSeek OCR 2 的论文，以我二把刀的知识分析一下。
这次是一个视觉模型编码器架构上的创新，主流的视觉模型编码器的方式是把图片分成一个个小块，变成一个个 token，然后按照从左上到右下逐行扫描的顺序一个个输入给模型。这其实和现在的 LLM 工作原理很像，只不过 LLM 是一串文本的 token，这里是一个个图片块的 token。然后还是 attention 那套两两比较，计算出每个 token 之间的关联关系，这样就可以通过不同 token 之间 attention 的权重关系得出不同图像块之间的关联，模型也就理解了整个图片。
看上去这个思路很好，统一了图片和文本的处理方式，但是图片和文本有个显著的区别，文本可以看做是一个一维的表现形式，你从左到右按顺序读，文本的逻辑大概率也是按照这个方向展开的。但是图片是个二维的表现形式，图片的逻辑并不是按照从左上到右下，图片里可能有斜线有曲线甚至有螺旋线，还是按照从左上到右下拆成的一维顺序是不是最有效的？至少人类看图片是不遵循这个顺序的。
虽然通过位置编码的方式可以把位置信息也加入到 attention 的计算，但是主流的位置编码也是基于文本一维顺序做的，是不是能很好的对图片这种二维表现形式进行位置编码呢？
DeepSeek OCR 2 的架构创新就在这里，他们在编码器里附加了一个小型的 LLM 可以推理出图片之间各个块的因果关系，然后按照关联关系对 token 进行重排序。可以认为模型是按照逻辑顺序去看图片而不是无脑的从左上到右下，这个逻辑顺序也会更接近人看图片的顺序。
性能提升，开销下降这属于 DeepSeek 的常规操作这里就不提了。我在想有没有可能视觉模型才是能力更强的模型的方向？
论文里提到这个模型主要作用还是读文档来生成语料，给 V 系列的语言模型用，但有没有可能把 OCR 系列和 V 系列直接融合。一方面图片里其实包含了文本里无法体现的内容信息，另一方面图片还比文本更节约 token。
按照 DeepSeek 一贯喜欢融合模型的作风，我觉得可以期待一下 V4 是个有初步视觉能力的模型了。
2026-01-12 02:49:00
最近迷上了补看电视剧，又看了《人民的名义》和《亮剑》，但是由于先看的《潜伏》难免会做一些对比。看了后两部更显的《潜伏》的节奏紧凑，台词没有废话，所有的演员都处在很高的水平，编剧也是自始至终的优秀。
《人民的名义》的节奏就有点拖，一个事情好几集都绕着转，换成《潜伏》一集可能三四个重要事情都过去了。里面老演员的演技还是不错的，年轻演员感觉都在用力过猛，两边一旦同场景搭戏就让人看着很尴尬。
看《亮剑》里的平安县争夺战拍出了看三大战役的感觉，还是很过瘾的，不过后面的剧情就急转直下，给人一种烂尾的既视感。
另外这两部剧很多时候都是靠喊台词来表现人物特点，《潜伏》在这方面就很收敛，更多是通过表情和动作来塑造人物。
引体向上现在站在台阶上不用跳可以拉上去了，不过全程还是拉不上去。
最近做动作膝盖和肩关节的弹响越来越明显了，看了些视频一方面要加强后侧肌肉的训练，还要专门练习一下肩胛骨的活动度。
睡眠对力量训练的影响还是很大的，稍微一熬夜大重量拉起来就很费劲了。研究一下说是力量除了和肌肉相关也和神经募集能力相关，如果睡眠不足会导致神经无法募集足够的肌肉来发力，从这个角度看健身可能比写代码更费脑子。
Kubernetes 的 managedFileds 在 Informer 缓存的时候可以删掉来节省 client 端的内存占用。我之前一直以为这时候再根据缓存做对象的 Update 操作会出问题，经同事指点其实 APIServer 会在 Update 和 Patch 时忽略没有 managedFileds 的情况，具体可以参考 Server Side Apply: clearing managedFields
之前为了标记生成的 Go 二进制对应的是代码的哪个 commit 会在 build 的时候把这个参数传进去，但是 Go 在 1.18 之后的 runtime 里其实默认就带了 VCS 的相关信息，只需要使用 go version -m xxx 就可以从二进制文件里直接获取构建信息了，更多参考 Go 1.18 debug/buildinfo features
发现了两个适合让 codex 来做的任务：
最近在做数字骨灰盒时发现其实大部分厂商都提供了视频理解的 LLM，但是 GLM 和 Qwen 只支持 public_url 方式传入视频，对非公开视频不是很友好。而 Gemini 是支持上传文件后再引用文件 ID 的，国内貌似只有 DouBao 支持类似的功能。
2025-12-29 16:25:00
居家办公三周后莫名其妙的得了痔疮，前几天都只能躺着了。查了下资料说现代人可能是因为长时间坐马桶导致的，可是我并没有。稍微好一些之后发现只要坐平时办工坐的椅子就会疼，仔细观察发现这个椅子由于长时间胶皮老化中间凹下去了，所以做起来就类似一个马桶两边高中间低，换成个平板椅子就好多了。
对着上周看的 Performance Hints 里的一条unnecessarily-nested-maps，拿着锤子找钉子，去 Prometheus 里看看有没有什么蹭 PR 的机会。最终发现这个优化方法还是有很多细节要考虑的，并不是完全没有副作用，尤其在 Prometheus 的场景里有时候完全不适用还会导致性能严重下降，之后可能会单写一个博客来说明。不过好在 Prometheus 里还有一处是完美适合这个优化的，提交了一个 PR perf(promql): update matchedSigs to a flat map reduce memory by 97% for GROUP_LEFT，能优化一个常见场景 13% 的 CPU 和 97% 的内存分配。
看了How uv got so fast，和第一直觉认为的 Rust 比 Python 快，所以 uv 才能这么快不同，uv 的快主要还是来自实现架构层面的选择。一方面是 Python 的包管理出了更高效的标准，另一方面 uv 选择放弃了大量的历史兼容性，专注于标准路径的优化。此外还有很多语言无关的优化，比如并行下载，硬链接等等其实是其他语言的依赖管理都有的功能，只是 pip 的历史包袱太大了，一直都没有这方面的优化。
在逛 Prometheus Issues 是发现一个 WIP: tsdb: persist series metadata to Parquet files 需要找时间看一下 Parquet 是个什么存储。
周末和孩子去了城市农场，一开始以为是个什么网红景点，去了后发现是个正经的科研机构，中国奶牛的育种就是从这里开始的。里面都是些看上去六七十年代的老房子，有科研人员专门负责讲解，体验还是很不错的。另一方面想到自己小时候没有盒装奶还都是牧场每天早上和报纸一块送的鲜牛奶要拿回家去煮。
里面有从刚出生到三四岁的奶牛，可以自己去喂，小孩抱着草料来回跑喂了快一个小时。
2025-12-22 04:43:00
最近社区的 PR 越来越多，由于 AI 的增强，每个 PR 膨胀的也很厉害，Review 的难度也越来越大。一直以来我对 PR 的合并手都比较松，现在合并一个新功能不强制有 proposal，不强制有测试，文档有时候甚至都是我后来再写的。如果从教条的开源社区规范来看，这个项目的治理，社区，文档都是乱哄哄的。代码债也到处都是，我最近初步梳理了几个文件就费了好大的劲。如果不是借助 AI 好多重构的活会更难。
不过从我的价值倾向来看，相比规范性，我更注重的还是一个项目是不是真的有用。尽管不规范会带来长期的隐患，但是保持这个项目一直有用就有机会等到后人有智慧来解决。
最近在反思之前用 AI 的一些方法，在习惯了自己不动手一把梭后，感觉自己阅读代码和复杂内容的耐心也下降了。或许以后确实 AI 可以做所有脑力劳动了，那么脑力劳动可能就变成现在的健身房了，未来人类需要和现在刻意锻炼肌肉一样才能保证脑力不流失。
happy 一个能在手机上控制开发机上 codex 和 claude code 的工具，这样不在电脑前也能抽 AI 干活了。
10kg 哑铃片到货，视觉上还是有些吓人。
全程的引体向上还是做不了，不过肩胛骨旋转的感觉找到一些了，离心可以做全程了。
连续三周上重量后，这周五的时候明显感觉硬拉拉不动了，下周打算做个减载周。
OpenShift Roadmap OpenShift 更新了未来一年的 RoadMap，公司里如果还有上了年纪的人可能会关心。
A new hash table 是 Valkey 的一个 hash table 实现变种，主要目的是为了节省内存体积和内存访问次数。这种把数组和链表组合的思路能够兼顾顺序访问的效率和链表无限扩容还是挺有意思。不过后来又看了下其他的 hash table 实现，发现这好像就是 Golang 在使用 Swiss Table 之前的实现。
kubevirtbmc 一个对接 KubeVirt 和传统物理机 BMC 协议的工具，能把 IPMI 和 Redfish API 的调用转换成 KubeVirt 的 API。这样用就能复用之前管理物理机的工具和流程来管理 KubeVirt 的虚拟机了。
Performance Hints Jeff Dean 和另一个 Google 初创时的工程师 Sanjay Ghemawat 写的性能优化手册。和大部分性能优化都是先 profile 找到热点再优化不同，这个手册介绍的主要是火焰图上看不到热点的时候如何怎么榨取性能。 因此里面介绍的全都是微操，针对 common case 做 fast path 已经算是最大块的优化方法了。里面有不少在 search 和 tensorflow 上做微操的例子，看上去还是很过瘾的。
海底捞的海螺片和鞭炮笋很好吃，推荐尝试，新出的猪肉卷就不要试了。另一个感叹是海底捞现在已经变成了个家庭聚餐的地方，满屋子都是过生日的，而在几年前我一直以为这是个工作或者同学聚餐的地方。
中午逛公园走了条平时没走的小路，上了段城墙，然后发现了传说中的“蓟门烟树”，我一直以为是什么古树，原来是个石碑，看介绍是乾隆题的字。
去了平西府地铁站新开的小站公园，公园用的一个人物形象名字是“下腰女孩（Tireless Girl）”。虽然我能勉强搞明白下腰和 Tireless 的关系，但这个翻译实在是太奇怪了。
2025-12-15 15:46:00
这是第二周远程办公，专注度相比上一周出现了很大起伏。上一周基本上能从早上起来一直拉满到晚上，这周注意力有所下降。
想了一下上周社区的问题比较多，基本是问题驱动的，自己不需要去考虑要做什么。这周问题少了空下来很多时候就没想法了。还是需要开启 Plan 模式，多做一些规划，给自己分配一些明确的任务。
这周花了些时间把卓叔增重和凯圣王Kaizen_Wang 的动作视频看了一遍。随着力量增加，一些之前看不懂的动作细节和找不到的发力感，现在渐渐能体会到了。再仔细看一遍争取每次动作都有进步。
这周做深蹲和硬拉已经能把单只 18kg 的哑铃片加满了，然后发现个问题就是这个重量做深蹲已经不太能靠手臂的力量把哑铃撑到肩上了，危险系数陡增。深蹲还能考虑换单腿，硬拉还是要加重量了。趁着双十二 pdd 了四个 10kg 哑铃片，估计能再撑几个月了。
我一直有个想法是把看到的所有东西都记录下来，然后借助 AI 的能力能不断检索一个人，甚至重建一个人。之前我的想法是感觉这个事情只能放在眼睛上来做，但是最近想法有变化，发现其实只要在我们日常接触的主要屏幕，比如电脑和手机上做记录也可以达到接近的效果。于是开始仔细的去看几个开源项目：DayFlow, ScreenPipe 和 OpenRecall。
这个过程中发现了很多我之前的知识盲区。一个是这里面有的项目是通过截图去记录屏幕信息，但是会通过视频的形式进行存储，原因是视频的压缩率会更高一些。我尝试了一下 5s 的频率截取了 120 张图片，用 zip 普通压缩一下还是有将近 400M，而用 FFmpeg 转成 1FPS 的视频后只需要 3.4M。
第二个是我才注意到 Gemini 是有视频模态的，这应该是目前主流 AI 厂商里少有的具有视频理解能力的。
这周内部同事分享了 ZCF 的六阶段工作流，我比较感兴趣它的实现方式。一般用 coding agent 使用 agent.md 其实不太好控制工作流，因为有的时候是写功能，有的时候是排查故障，有的时候是重构，不同的目标使用的工作流其实是不一样的。而 agent.md 里即使根据各种情况写了工作流，也还需要 AI 工具能自动分析出是哪种情况，并且多轮对话的时候很容易出现不一致的情况。ZCF 是通过 command 来实现，需要用户显式去说明用哪个工作流，感觉上不是太智能，但其实实际中用起来一致性应该会更好。
这周还发现 OVS+OVN Con 2025 的视频和 Slide 已经上传了，下周找时间过一下。粗看一个感兴趣的议题 Deprecating Code 看样子 OVS 要移除对 Windows 的支持了，原因是没人知道该怎么维护，甚至没人知道是不是还能正常工作，当然从我们团队同事之前的经验看在最新的 Windows 上已经不太正常了，这样我也可以顺带着清理一波代码了。
这周看了《疯狂动物城 2》，还是标准的迪士尼套路，没有啥太多的惊喜。和年初的《哪吒之魔童闹海》比，还是能看出明显的文化区别。动物城目标群体是全球用户，所以选了没啥文化背景理解需求的动物做主角，而哪吒明显是个中国文化故事，甚至能看到对《哪吒闹海》和《十万个冷笑话》的致敬。动物城是个中规中矩的工业品，而哪吒是有着很鲜明作者特色和作者表达的作品。我对动物城票房数字唯一的理解就是这一年除了哪吒就再也没有一个水平线上的电影作品了。
最近迷上了看《潜伏》的解读，主要看了 B 站 Up 弥先生碎碎念的《细讲潜伏》系列。之前只是觉得台词好，演技好，解读后才发现编剧是多么的厉害，历史背景有多么复杂。
2025-11-30 17:45:00
NetworkPolicy 作为 Kubernetes 早期的 API 看似美好，实际使用过程中就会发现它功能有限，不易扩展，不易理解且不易使用。因此 Kubernetes 成立了 Network Policy API Working Group 来制订下一代的 API 规范，而 ClusterNetworkPolicy 就是目前探讨出来的最新成果，未来可能会成为新的规范。
NetworkPolicy 是 Namespace 级资源，本质上是“应用视角”的策略。它通过 podSelector、namespaceSelector 来选中一批 Pod，然后对这些 Pod 的 Ingress、Egress 做限制。这带来了几个实际的问题：
由于策略的作用域是 Namespace，集群管理员无法定义集群级别的默认网络策略，只能在每个 Namespace 里都创建相同的网络策略。这样一方面每次更新策略需要对所有 Namespace 下的资源进行更新，另一方面，很容易和开发者创建的网络策略产生冲突。管理员设置的策略，应用侧很容易就可以通过新的策略绕过去。
本质上在于 NetworkPolicy 这种应用视角的策略和管理员集群视角的策略存在冲突，当用户的安全模型并不是应用视角的时候 NetworkPolicy 就会变得难以应用。而集群管理员管控集群整体的安全策略是个现实中很常见的场景。
NetworkPolicy 的语义有几个“坑”，新手和运维人员都容易踩：
隐式隔离。
一旦有任何 NetworkPolicy 选中了某个 Pod，那么“未被允许”的流量就会被默认拒绝。这种隐式的行为需要靠心算来推导，很难一眼看懂。
只有允许，没有显式拒绝。
标准 NetworkPolicy 只能写 allow 类型的规则，想要“拒绝某个来源”，通常要通过补充其他 allow 规则间接实现，或者依赖某些 CNI 厂商特有的扩展。
没有优先级。
多个 NetworkPolicy 选择同一批 Pod 时，规则是加法而不是覆盖关系。最终行为往往需要把所有策略合在一起看，排查问题时非常困难。
这些特点叠加在一起，就会导致 NetworkPolicy 理解起来困难，调试起来更困难。
为了解决 NetworkPolicy 固有的问题，Network Policy API 工作组提出了一个新的 API —— ClusterNetworkPolicy (CNP)，它的目标是在不破坏现有 NetworkPolicy 用法的前提下，给集群管理员提供一个更清晰、更强大的网络控制能力。
其最核心的思路是引入策略分层，在现有的 NetworkPolicy 之前和之后分别引入独立的策略层，将集群管理员的策略和应用的策略分开，提供了更丰富的视角和更灵活的使用。
一个示例如下：
1 |
apiVersion: policy.networking.k8s.io/v1alpha2 |
新引入的 ClusterNetworkPolicy 是集群级别资源，管理员可以直接选中多个 Namespace 下的 Pod 进行策略控制。同时 Admin Tier 的策略可以先于 NetworkPolicy 生效，这样集群管理员只需要少量的 Admin Tier 策略就可以控制住整个集群的红线行为。
而 Baseline Tier 的策略在所有 NetworkPolicy 都不匹配后执行，相当于提供了一个兜底策略。
简单来说：
tier: Admin 的策略用来定义绝对不能做的事情。tier: Baseline 的策略用来定义默认不建议做的事情，用户可以通过 NetworkPolicy 来放行。ClusterNetworkPolicy 中新增了 priority 字段，这样在同一个 Tier 中多个规则的范围出现重叠时，可以通过优先级清晰的界定哪个规则该生效，不会再出现 NetworkPolicy 里那种隐式覆盖，需要互相猜测的情况。
和 NetworkPolicy 只有“允许”语义不同，ClusterNetworkPolicy 的每条规则都有一个显式的 action 字段，可以取值：
Accept：允许这条规则选中的流量，并停止后续策略评估Deny：拒绝这条规则选中的流量，并停止后续策略评估Pass：在当前 tier 里跳过后续 ClusterNetworkPolicy，交给下一层继续评估同时，文档中特别强调：
结合优先级的配置，规则的理解就不再会产生模糊的情况，理解上也变得不那么困难。
ClusterNetworkPolicy 一定程度上回归了传统的分层网络策略的架构，在解决了 NetworkPolicy 问题的情况下没有带来破坏性的变化，可以说是一个很不错的设计，希望能尽快看到这个规范的成熟和落地。
