2026-01-19 00:27:00
Computer Science jokes are old, but they’re still true
“There are only two hard things in computer science: cache invalidation and naming things.” — Phil Karlton (and eventually, off-by-one errors).
We’ve laughed at this trope for decades, but we’ve spent far too little time dissecting the second one: Naming. On the surface, naming is about semantics—choosing user_id over id_1. But at its core, naming is an act of exorcism. In ancient Tibetan folklore, as well as in Western occultism (think the Goetia or Ursula K. Le Guin’s Earthsea), to know the "True Name" of a demon or a dragon is to have absolute power over it. To name a bug is to strip it of its mystery. To name a design pattern is to make it reproducible.
In the era of AI coding assistants, this is more important than ever. Low-hanging fruit—the repetitive boilerplate, the tasks with clear patterns—will soon be “harvested” by AI. Everything it can solve, it will. But the problems that haven’t been documented, defined, or named remain out of reach. AI simply doesn’t know what it doesn’t know.
Recently, I’ve been experimenting with AI coding assistants almost every day. The results are impressive—sometimes even exhilarating. Years of hobby projects suddenly feel “done.” But there’s also a hollow feeling: the AI takes over the thinking, the tinkering, the trial-and-error process that once taught me more than the final product ever did.
Here’s a key insight: sometimes the byproducts are often more valuable than the intended product.
The real danger of AI isn't that it's "wrong"—it's that it's too helpful. AI is a "direct-to-result" machine. But in the history of human progress, the Product is often the least interesting part. The Byproduct is where the revolution happens.
When you struggle to build a library, you might fail to ship the app on time, but you end up naming a new state-management pattern or a faster JSON parser. That "byproduct" becomes your tool for the next ten years. AI doesn't do "side quests." It follows the shortest path of least resistance to satisfy your prompt.
In the history of software, our most vital concepts weren’t created by committee; they were "named" after the lessons we learned while failing to do something else.
These names don't describe the goal; they describe the scar tissue of the process. By focusing only on the "clean result" provided by AI, we risk losing the ability to recognize these scars—and without the scars, we have nothing to name.
If we move to a world where we only write "Specs" and let Agents handle the "Implementation," we are becoming high-level managers of a Soviet tank factory of "fitting".
I happened to read a fascinating engineering story on zhihu from Soviet-era manufacturing—what they called “Fitting” (пригонка).
In Western manufacturing, the gold standard is "Interchangeable Parts." You build a part to a 0.01mm tolerance so it fits any machine on the line. But in Soviet tank factories, tolerances were loose. Instead of perfecting the part, they perfected the "fit."
AI coding today is turning us all into "fitters." We are no longer architects designing perfect, interchangeable modules; we are engineers in a tank factory, taking AI-generated blocks that almost work and "fitting" them together with shims and workarounds. The AI can accelerate production, but it lacks the "eyes" to see why a part doesn't fit—it just produces more parts.
If we outsource the struggle, we outsource the learning. The "fitting" process is where the real knowledge hides. When you manually debug a race condition for three days, you aren't just fixing a line of code; you are learning the "True Name" of concurrency.
AI can give you the solution, but it cannot give you the "Aha!" moment. It can provide the syntax, but it cannot provide the Naming. As we move deeper into this automated era, the role of the developer is shifting from "Writer" to "Editor," and from "Builder" to "Exorcist." Our value will no longer lie in the volume of code we produce—AI has made the marginal cost of code zero. Our value will lie in our ability to look at a chaotic "fitting" of AI logic and give it a name.
Because in the end, the AI is just a mirror of what has already been said. It can rearrange the words, but it cannot speak a new True Name into existence. If you let the AI do all the "shaving," don't be surprised when you find yourself standing in the cold, having forgotten why you wanted to wash the car in the first place.
Master the tools, use them to "fit" your dreams into reality, but never stop looking for the "detour" in the relay. That's where the next great idea is hiding, waiting for someone to finally give it a name.
Author's note:
This original article was organically, hand-written by me https://blog.est.im/2026/stderr-03
I also drafted this English version, and ultimately "fitted" together by Gemini 3.
2026-01-18 23:17:00
计科里有两件极难的事儿，cache invalidation，给东西起名字，和 off-by-1 errors.
今天想说说这个，给东西起名儿。HN今日讨论，软能力会成为程序员最实用的技能，这里的 软技能 就是指交流——特别是和 coding agent 交流。
我觉得吧，coding agent 这波福利迟早会被吃干抹净。低垂的果实，虽然很多，很大，也会被摘完。
AI能把它能解决的一切，全部拉到同一个水平，然后进入贤者模式。哪些从来没有文档说明，也就是没有语料拿来训练的东西，哪些尚没被定义，没被分析，没被起名字的问题，那些就算讨论都要先叠甲 lemma 的问题，AI就无能为力了。
近几天几乎每天都能vibe出来一些成果，我很喜欢，但是突然又很空洞。欣喜的是多年以来的hobby得到了完成，解脱了；空洞一方面是没有下一步目标，索然无味了，还有更深层次的原因是：我失去了一个自己思考和实操的过程
我这几天琢磨出一个味儿了。很多事情，product 不是全部。对没错，产品算个鸟。产品啥都不是。 byproduct 说不定才是真正无价之宝。我回顾了下很多idea都是在撸一个需求走了弯路，走了错路，无意中发明的额外的轮子，结果反而更值钱。就像人们常说的那样，淘金热里可能卖铲子更赚。还有那句怎么说的来着，结果不重要，过程才是经历。
Vibe 爽是爽过了，但是总感觉隔了一层，AI在碰钉子复盘的时候，你在摸鱼，你就错过了一次 level up 的提升机会。AI 在调用别的工具和别的语言做交叉比对验证的时候，如果是人，会学习到新的知识，但是人现在只是个监工了。
只看结果，只看绩效，是对事物的本质和变化缺乏观察的。比如写一篇漂亮的 spec 让AI完美执行，但是可能你就错过了AI 用clever trick 掩盖你一些内在的，本质的设计矛盾。
恰好最近又看到这个 为什么苏联武器在很长的一段时间里被黑成粗制滥造的劣等货？
国产装备制造业机械厂里有个工艺技能，叫“照配”。意思就是配件加工时加工错了不要紧，一切都可以配。
举例说。这个部件上按照图纸应该加工十对直径20的销孔，上下半分开加工。上半十个加工没有问题，下半因为马虎大意上了直径25的绞刀，干错了一个销孔。问题不大，把上半对应的那个销孔扩大到直径25，另外照配一个直径25的销子。装配时这个25的销子和另外9个20的销子一起装，装上就行。
这就叫照配。又比如一根双头螺栓，两头螺纹长度要求是200长，结果发现手头这跟金属材料有点短，一头干了200，另一头长度只剩下160了。但是这根料弃之不用又可惜。那咋办?按照设计两头各有一个40厚的垫片，然后加上螺母。那么把其中一个垫片的厚度削减到5吧。然后误差还剩下5。嗯，算一下螺纹有效长度，剩下的5的误差不耽误和螺母把紧，就这么用吧。
这也叫照配。又比如，这个零部件的金属材质设计要求是15cr2mo1，但是你现在没有现成材质，仓库里倒是有15cr1mo1v的材料，虽然和图纸要求不一样，但是无所谓，一样能代替，就这么用了吧。
这也是一种照配。照配这个技能你在机械专业任何一本教科书上都找不到，是一个非常牛逼的技能，简直百分之八十（甚至可能更多）尺寸错误应该报废的零部件你都可以用这招把问题解决。尽管机械专业课堂上公差配合课程第一课就在强调“标准化”“互换性”，但，那又有什么关系?老板喜欢就行呗，省时省力又省钱啊。
《那年那兔那些事》漫画里面有个段子说美国工程师帮中国改造两架型号一样的战斗机，发现明明同一型号的部件上的零件拆下来后居然往另一台飞机的部件上装不上，因此困惑不已。这事历史上真有假有不知道，但是这种故事发生并不奇怪。
那么照配这个技能是和谁学的呢?答：苏联老师。
据说苏联老师这技能就来自于战争期间的军工生产。二战时期前线非常吃紧，后方的拖拉机厂拼命生产坦克和汽车供应前线。但是生产谁还没有失误的时候?这零部件造错了?配就完事了，一切以及时供应上前线为核心，武器能装配上就行，赶紧开到前线去，反正也不指望这玩意能回来了……然后发现，这虽然违背了机械制造的标准化原则，但是省时省力又省钱啊。能用就行呗，管啥设计要求和质量?
至于“粗制滥造”的指控?乐，军工产品在战场不就是消耗品吗，谁还指望这玩意能活多久似的，那还要那么长的设计寿命干啥?
所以苏联老师就能设计出诸如米格29这种前线战斗机之类的产品，设计思想就是这类东西定位就是前线消耗品，只要空中格斗机动性能好就行，别的啥的人机工程和使用寿命之类的……在乎那些干啥?主打一个能装上，能用，能动，能省钱省时省精力就行了（乐）
于是伴随着着156计划，苏联老师的这种思想以及照配之类的技术也就传授给了中国徒弟，然后丫的一直传承到了现在。
如果你把这种制造思想指导下生产出的产品评价为粗制滥造，我觉得问题不算大。
反正能交差就行。我觉得AI编程，可能就需要长时间去「照配」一切了。而工业化，组织化，体系化，标准化的威力，我想不必多说。
有了AI，人们做啥事都可以一键直达了，不需要去思考，不需要去为了中间步骤搭桥，可能以后人们慢慢的不会再发明 library和一些 design pattern 了。毕竟AI 啥都懂，能识别很多人类察觉不到的 pattern。
AI is one framework to rule all frameworks. 王者之戒，统御9戒
我赶紧向AI问，人类历史有哪些著名的 byproduct 比原来的 product 更重要？它给我胡吹了一堆，最著名的，本来是研究葡萄球菌的，然后搞出来盘尼西林。我觉得这是西医摆脱巫医的质变；当然还有 ARPANET，本来是拿来扛核打击的，结果变成互联网；塑料，本来是拿来代替一种虫胶清漆，结果引发材料学革命；
我大概知道一个冷门的，EUV光刻机。本来是NIF玩激光点火测试核聚变申请着玩没用的专利，交给 Intel 套现的。Intel 拿着也没用就卖给了 ASML台积电。而 NIF 其实就是个幌子项目，说是研究核聚变，实际上是拿来测试激光武器的。所谓我能对准原子核，也能对准你在外太空的导弹。
试想一下，如果交给 AI 来做这些事，可能就完成了平庸的任务了事。压根不会多想。
而且现在AI训练本身就有问题，它不太会拒绝你，它的神经网络是靠「迎合」来打分的。它不会说不知道，它只会问你 would you like to know more 来诱导消费更多的token，而不是回头看这个过程有什么有价值的东西。
有价值？有价值的前提是你有个baseline，你知道什么东西你不知道。但是AI又是全能全知的，它不知道自己不知道，它也不知道你不知道。
人类把折腾规律这一使命交给AI，人类也就失去了重大能力——命名权。
命名权有多重要呢？“苍颉作书，而天雨粟，鬼夜哭”。这一点在藏区作为传统被保留了下来。藏区的鬼神都拥有所谓的命根子。命根子有几种呢？一般分为：名字，种子字等。
也就是说，正确喊出鬼神的名字，你就抓住了鬼神的命根子。翻译一下这句话，你把试题的出题类型正确识别了，题目也就解决了一大半。
人类在蛮荒时代，面对社会、大自然的无知，天生对不确定性和后果有恐惧。起名字是一件神圣，专业和高深的艺术，在汉地其实一直由祭祀阶层以「诗书传家」的方式保留到宋代，也就是造纸术发明打破了这一切。西方也一样。对人性和行为规范的定义权，被教会牢牢控制，一直到 古腾堡 Gutenberg 才打破。说起来也搞笑，东方是拿来印佛经，打破了文化阶级桎梏，西方是拿来印赎罪券，造成进天堂通货膨胀 🤣 这似乎也算重大 by-product了。
说远了。现在是 00:00，我想我应该总结下，AI 承包过程，必将架空人类最宝贵的过程经验。对下面发生了什么事，不仅不能察觉，连命名、定义的能力都会失去。人们以前很喜欢说 paradigm shift，我想这次，恐怕是 no paradigm left to shift。硅基的 token embeddings 人们看不懂啊。
所以啊，趁着还可以，多看 reasoning model 的 thought process，多思考。
2026-01-17 13:45:00
For a decade, we have lived in the Age of the Vapor. We post into the void, chasing a heartbeat of attention that vanishes by morning. Our thoughts are rented to servers we don't own, managed by algorithms that don't care, and deleted as easily as they were typed.
We have traded Legacy for Latency.
Seal is the end of the "Post." We do not "post"; we Inscribe.
When you write here, you are not just making noise; you are adding a verse to your own personal canon. Every word is written to your local disk first. Every thought is signed with your own key.
Once it is Sealed, it is yours. It is a piece of history that no corporation can "un-write."
If a thought isn't worth keeping for a century, is it worth saying today?
By treating microblogging like Scripture, we return gravity to the conversation. We replace the "Infinite Scroll" with the Permanent Record. We don't build feeds; we build Codexes.
Your data lives with you. Our service is merely the Courier—the mailer that carries your sealed verses into the atmosphere of the world. We cannot change what you have said. We cannot hide your history. We are the pipe; you are the source.
We believe in a social web where:
Stop scrolling. Start Inscribing.
Seal your legacy.
2012年，在懵逼之中写下了《我的信息危机》，当年激发了些许讨论。
也正是那一年，Hinton 带着大弟子 Alex，Ilya，去 ILSVRC 踢馆拔得头筹，这场年度比赛背后是ImageNet，李飞飞趴了几千万张Flickr照片+tag，找三哥在 Mechanical Turk 挨个标成题库去考验各种古法编程手搓的分类器。
AlexNet靠两张NVIDIA GTX 580 3GB显卡，用224×224分辨率打败有史以来所有选手，在比赛中大幅度领先，一举成名。这场对全世界，全人类，全历史造成的震荡一直持续到今天。
当年我写到，输入越来越多，输出越来越少；过多信息时效化；碎片化；信噪比极低，这些问题似乎在AI时代……居然引刃而解了？
我渴望一个SNS，隔绝与hivemind的各种hype，又能自洽，这一点可能还需努力，于是就有了这篇 manifesto。
2026-01-16 00:10:00
首先，我讨厌编译，我喜欢二进制，直到昨天我惊讶的发现macOS上一个 yes 命令都是接近100KB的大小。homebrew 一大坨东西还不一定每次都成功。
说起编译，这几天读到一些关于软件法律方面的风险。zhihu说如果你的工具的不针对“特定用途”，那么就可以用一定免责的说辞，但是如果你提供下载只能拿来恰好做某一件特别具体的事，那么工具的提供者就有连带责任。我想这也是为啥大部分开源软件都是提供源码吧。我这代码又不能直接用，开源是为了研究技术。你自己编译之后拿来敲不对劲的命令那是用户自己的选择了。
那么回到主题， mtr 作为居家旅行必备网络工具，它只提供源码分发。9年前研究过，用python写了demo，但是终究不是太成熟，现在有 AI ，几句话就完成了
使用方法是 sudo python3 cli.py jd.com 这样。 -6 可以强制使用 IPv6，-c1 可以每一跳只probe一次并退出。
过程中反复折腾的，居然是最后一个 hop 重复显示，和丢失的问题。没想到AI也犯糊涂。
不过需要sudo还是很蛋痛。有一些折衷的办法比如去读 traceroute -d， mtr 或者 iproute2 的debug输出，有空再折腾。
期间遇到n次无法编辑文件的情况，估计AI输出乱了。还有不知道为什么，Google Antigravity每次写完代码就打 Aurora 几个字到末尾。
现在基本框架有了，下一步支持点什么插件好呢。
2026-01-14 22:48:00
一个奇怪的需求：如何在浏览器判断一个字体是否支持某个字符？
（原始需求是：遇到一些字符渲染错位问题，看起来是字体不支持，fallback 到别的去了。）
想到的方法是：用canvas渲染看宽度。但因为这个 fallback机制，所以更好的办法是拿一个已知的特殊字体去比对，如果fallback了说明不支持。
那么问题来了，这个 fallback font 你不可能下载一个包含所有字符的，那样体积会很大，所以最好是按需生成一个，只包含一个字符，用来比对。那么这个问题就转换成了：如何在浏览器js里动态生成一个 .ttf 格式的字体文件，只包含一个字符？
这里不考虑 woff woff2，因为前者已经过时了后者比 ttf 更复杂。
一开始以为很easy，让 ChatGPT搓，打开浏览器就懵逼
OTS parsing error: bad table directory searchRange
bad table directory entrySelector
bad table directory rangeShift
Invalid table tag: 0x66000000
f\x00\x00\x00: invalid table offset
感觉事情没那么简单。让Antigravity搓，它把我免费额度烧光了也没搓出个所以然
其中一个小插曲是，css里允许对单独一个字符设置 font-family，但是因为这个 .ttf 是动态生成的，所以需要动态生成这个CSS的声明，所以在生成 .ttf 之后需要类似这样的代码：
document.head.insertAdjacentHTML("beforeend", `
<style>
@font-face {
font-family: GhostRaw;
src: url(${url});
unicode-range: U+2603;
}
body { font-family: GhostRaw, system-ui; }
</style>
`);
注意这个是在 html 里的 js 里的 template string 里的 css。antigravity改这一块出现了好多次 error，我猜是AI输出格式嵌套格式本来就容易出错，这里引用和转义太复杂以至于 agent 直接看不懂output了。哈哈
因为没额度了，所以换国产免费的 Trae。Trae 比antigravity更笨，但是也努力。js搓不动，就开始换写 .py 去验证。搞到最后搞出来一堆测试文件
check_maxp.py
check_validation.py
generate_minimal_ttf.py
generate_proper_ttf.py
generate_simple_zero_width_font.py
generate_ttf.js
generate_zero_width_font.py
generated_font.ttf
generated_font.ttx
get_base64.js
minimal_font_generator.py
modify_existing_font.py
simple_font_generator.py
validate_ttf.py
validate.js
working_font_generator.py
zero_width_font.ttf
zero-width.ttf
这样几回合下来，直接搓超出上下文了，最后直接罢工，出现
Output is too long, please enter 'Continue' to get more.
而且你点了 continue 它思索半天还是出现这句话。上下文是彻底爆了。
正向构造一个 .ttf 很难，AI还很聪明的想到了：
我将使用一个更简单的方法，直接使用一个现有的基础字体文件，然后修改它的字符映射。让我检查一下是否有任何基础 TTF 文件可用。我将使用 Google Fonts 中的一个非常简单的字体作为基础。
最后还是失败了。于是我就去搜索引擎找到了这个：
https://pomax.github.io/Minimal-font-generator/
dynamically generated bespoke font that encodes that character as a zero-width glyph
in the PDF.js project, where a PDF file may have fonts embedded for rendering text with, but no way to tell whether an extracted font has actually finished loading.
和我想到一块去了。还是人类老哥牛逼，2012-01-14号就把这个方案搓出来了，距今刚好整整14年。
AI就像一个培训班出身的，对背题能过的任务能很快完成，对于这种考验细节的冷门任务，还是难。
2026-01-13 22:30:00
2022年买的VPS一直没怎么管，今天想跑点东西发现大户 warp-cli 真是吃资源啊。果断删掉
公司的服务器都是SA管理，自己的一般很少去折腾，这次也是闲的，好奇系统里杂七杂八都是啥玩意儿，挨个找AI审问一遍
systemctl list-units --type=service --state=running
blk-availability udisks2 插拔优盘的fwupd 固件更新ModemManager multipathd open-iscsi iscsid 存储用的packagekit GUI包管理器polkit GUI 策略kitsnapd snapd.apparmor snapd.autoimport GUI里的 App storelvm2-monitorupower thermald 电源和温度传感器cloud-init* cloud-config* 云配置器apport* Crash reporting这些都没用！直接 sudo systemctl disable --now XXX 禁用
其中 snapd 直接 sudo apt purge snapd 斩草除根！
最后看一下 free -h used=110Mi 感觉好多了。
顺便把文件也清理下 sudo journalctl --vacuum-size=500M，发现比较大，编辑 vi /etc/systemd/journald.conf
[Journal]
SystemMaxUse=500M
然后 sudo systemctl restart systemd-journald
为什么要整理VPS？因为大善人Cloudflare 和 Vercel 都有 request buffering 导致一个 hobby project 做不下去了
