2026-05-31 11:56:00
The five-step process:
First, make your requirements less dumb. Your requirements are definitely dumb. It does not matter who gave them to you.
In fact, it's particularly dangerous if a smart person gave you the requirements, because you might not question them enough. Everyone is wrong some of the time, no matter who you are. So the first step is to make your requirements less dumb.
Second, try very hard to delete the part or process. This is extremely important. If you're not occasionally adding things back in, then you're not deleting enough. The bias is almost always toward adding a part, a process, or a step "just in case we need it."
You can make "just in case" arguments for almost anything.
For a rocket, especially one trying to become the first fully reusable rocket—a thing that has never existed before—you have to be ruthless about deleting parts and processes. You can't hedge every risk forever. For example, on Starship, the grid fins do not fold down. Folding would require an entire additional mechanism that simply isn't necessary.
Any requirement or constraint must come with a name, not a department. You can't question a department; you can only question a person. The individual proposing the requirement must be willing to take responsibility for it. Otherwise you end up following a requirement that some intern casually suggested two years ago, who doesn't even work at the company anymore. These things are often much sillier than people imagine.
So:
Step 1: Make the requirements less dumb.
Step 2: Delete the part or process.
If you're not adding things back roughly 10% of the time, you're clearly not deleting enough.
Only then comes Step 3: Simplify or optimize.
This ordering matters because one of the most common mistakes smart engineers make is optimizing something that should not exist in the first place.
People are trained throughout school to answer the question they are given. You can't tell your professor, "Your question is dumb." You'll get a bad grade. So everyone develops this habit of solving the assigned problem rather than questioning whether the problem itself should exist.
Without realizing it, people end up in a mental straitjacket, spending enormous effort optimizing things that should simply be removed.
Step 4 is accelerate cycle time.
You're probably moving too slowly. Go faster. But don't accelerate until you've done the first three steps. You can almost always make something go faster.
Finally, Step 5: Automate.
I have personally made the mistake of doing all five steps backwards multiple times. I've literally automated, accelerated, simplified, and only afterward deleted.
One example was during Model 3 production. There were five fiberglass mats located between the floor pan and the battery pack. At one point they became a bottleneck on the battery production line, and that bottleneck was affecting the entire Model 3 program.
I was basically living on the battery-pack production line trying to fix it. My first mistake was trying to improve the automation. I thought, "Let's make the robot better." That was a mistake. Then I tried accelerating the process. That was a mistake. Then I tried optimizing the process. That was also a mistake. Finally I asked, "What the hell are these mats actually for?"
I asked the battery safety team whether they were for fire protection. They said no—they were for noise and vibration. Then I asked the NVH (Noise, Vibration, Harshness) team what they were for. They said they were for fire safety. At that point it felt like I was living inside a Dilbert cartoon. Frankly, I feel that way fairly often. So we tested it. We built one car with the fiberglass mats and another without them. We put microphones in both vehicles and tried to determine whether there was any measurable difference. There wasn't. In fact, I couldn't even tell which was which.
So we deleted the mats entirely. That decision bypassed a $2 million robot cell and eliminated a problem that never should have existed in the first place. That's the lesson:
Question the requirement.
Delete before you optimize.
Optimize before you accelerate.
Accelerate before you automate.
And be aware that even experienced engineers constantly get this order wrong.
这个五步流程是这样的。
第一步，先让需求变得没那么蠢（Make your requirements less dumb）。
你的需求一定有问题。不管是谁提出来的，都一样。如果需求是一个聪明人提出来的，反而更危险，因为你可能不敢质疑它。事实上，每个人都会犯错，无论你是谁。所以第一步永远是先审视需求本身，看看它到底合不合理。
第二步，尽最大努力删除零件、流程或步骤（Delete the part or process）。
这一点极其重要。如果你从来不会出现“删掉之后又加回来”的情况，那说明你删得还不够狠。绝大多数组织天然倾向于不断增加东西——增加一个零件、增加一道流程、增加一个审批步骤。理由通常都是：
“万一以后需要呢？”
但这种“以防万一”的理由几乎可以为任何东西辩护。
以火箭为例。我们做的是历史上第一个完全可重复使用的火箭，这是航天领域长期追求的圣杯。在这种情况下，你必须拼命删除不必要的东西，而不是不断给自己留后路。例如 Starship 的格栅翼（grid fins）并不会折叠。因为折叠意味着额外增加一整套机械结构，而我们根本不需要它。
还有一个原则：任何需求或约束条件，都必须对应到一个具体的人，而不是一个部门。因为你无法质问一个部门，你只能质问一个人。提出这个需求的人，必须愿意对它负责。否则公司里经常会出现这样的情况：某个约束条件源于两年前某个实习生随口提出的一句话，而那个人早就离职了，但这个约束却还在被所有人当成圣旨执行。这种事情比你想象得常见得多。
所以：
第一步，质疑需求，让需求变得没那么蠢。
第二步，删除零件、流程和步骤。
如果删完以后从来不需要加回来，那么说明你还没有删到位。大约有 10% 的情况需要加回来，才算删得够狠。
第三步，才是简化和优化（Simplify or Optimize）。
顺序非常重要。聪明工程师最常见的错误，就是优化一个本来就不应该存在的东西。
从小学到大学，所有教育都在训练你回答问题，而不是质疑问题。老师出了一道题，你不能告诉老师：“你的题目本身就有问题。”
否则你会拿低分。久而久之，人们形成了一种思维惯性：默认问题一定是正确的，然后拼命去寻找最优解。结果就是大家被套上了一个无形的思维枷锁，把大量精力浪费在优化那些本来就应该被删除的东西上。
第四步，加快迭代速度（Accelerate cycle time）。
大多数时候，你只是推进得太慢了。加快速度，但一定要先完成前面三步。因为无论什么事情，几乎总能找到办法让它跑得更快。
第五步，自动化（Automate）。
而我自己犯过很多次错误——几乎是把这五步完全倒过来做。我曾经自动化、加速、优化了一大堆东西，最后才发现它们根本不该存在。举个例子。
Model 3 电池包顶部曾经有五块玻璃纤维垫，位于电池包和车身底板之间。有一段时间，这几块垫子成了整个电池生产线的瓶颈，而电池生产线又卡住了整个 Model 3 项目。当时我几乎天天待在生产线上，试图解决问题。
我做的第一件事，是改进自动化设备。错了；
然后我尝试提高生产速度。还是错了；
接着我开始优化整个流程。依然错了；
最后我终于问了一句：这几个垫子到底是干什么用的？
我去问电池安全团队：这是为了防火吗？他们回答：不是，这是为了降噪和减振。
于是我又去问 NVH（噪音、振动与舒适性）团队：这些垫子是干什么的？他们回答：为了防火。
整个场面就像《Dilbert》漫画一样荒谬。说实话，我经常有这种感觉。于是我们决定直接测试。造两辆车，一辆有这些垫子，一辆没有。在车里放上麦克风，看看能不能测出差异。结果完全测不出来。甚至我自己都分辨不出哪辆有、哪辆没有。于是我们直接把这五块垫子删掉了。一个价值两百万美元的机器人工作站也因此不再需要。而这一切问题，从一开始就不应该存在。
这就是整个五步法的核心：
而现实里，即便是经验丰富的工程师，也会一遍又一遍地把这个顺序搞反。
我发现我最喜欢犯“just in case we need it”这个错。然后就是无休止的 optimize a thing that should not exist
2026-05-30 20:03:08
家里有个小 NAS 。里面存了一些歌。一半是用 NAS 自带的 app 听，一半是。。。SMB 共享打开听
虽然 NAS 也提供 DLNA ，一直以来找不到趁手 app ，要么收费，要么 bug 多，要么不能多端。
13年前我也想基于 chrome.socket 做个 Chrome App 弄个类似的。结果这破玩意实现有问题，多连接会导致 hang。最后2020年Chromium决定杀死 Chrome Apps
周六的时候，实在无聊，决定又开始搓轮子。在思考 SSDP/UPnP ，native UI, electron，命令行这些选型的时候，突然想到，DLNA服本来就要提供一个http，自己再造个 http 客户端去通信，岂不是多此一举？只要依托它，解决跨域……等等，用个 bookmarklet 不就行了？当页调用 fetch() ，走 SOAP 协议，完美。
所以这就有了，网页版听歌的。不需要安装 app ，只需要一个浏览器书签
https://est.github.io/playlet/
也需要你对网络、DLNA 的亿点点知识。比如你得自己想办法找出 DLNA 的 IP 和端口
使用方法：
把这个网址加到浏览器书签
javascript:import("https://est.github.io/playlet/loader.js")
打开 DLNA 服务器的网页
自测兼容 NAS 的 MiniDLNA 。chrome ，手机浏览器和 webview 都可以播放。
当年嵌入个 <script> 写法多复杂，createElement又这那的；现在直接 import() 搞定。简洁明了，还不会重复加载。
最后是个 50KB 左右的单体 js。实现了播放、搜索等核心功能+UI。
给本地测试环境动了个小心思，利用 iframe 去模拟 bookmarklet 注入。还学习到 <audio crossorigin="anonymous"> 居然主动去检查跨域CORS头导致加载失败，去掉 crossorigin 就行。AI嘴硬不给去掉，服了。
这下随时随地打开浏览器就能听歌了。除了收藏的一些古典CD是 .cue 分段的没法播放。感觉需要去电脑上硬切割一下了。
接下来想把歌词什么的整理好。不知道有没有类似 opensubtitles 之类的服务。
最后想起来，miniDLNA为啥不直接把这一坨JS内置了 😂 可能当年那个条件没厂家愿意去js手搓一套DLNA协议+播放界面吧。甚至浏览器对常见音频格式都不怎么支持
2026-05-28 18:35:00
以前只记得要支持websocket 需要 nginx 改：
location /ws-service-a {
proxy_pass http://backend_a;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $connection_upgrade;
}
今天折腾忘记这茬了，一直在调 FastAPI ，@app.websocket() 死活不识别 wscat 的请求
WebSocket 协议的工作方式是：
1.客户端发 GET + Upgrade: websocket 头
2.服务端识别这个特殊 GET，返回 101 Switching Protocols
3.连接升级完成
opus-4.6 说：既然路由确实注册了，那问题几乎可以确定是：前面的反向代理/LB 没有透传 WebSocket
我就来劲了，让AI写一份 特殊 GET，返回 101 Switching Protocols 。
结果还真成功了。wscat 返回 error: Invalid Sec-WebSocket-Accept header
折腾了几下，发现此路不通
问题不是 @app.websocket() 没挂载，它挂载了，但永远匹配不到。原因是 uvicorn 的路由分发发生在更底层：
请求到达 uvicorn
↓
uvicorn 检查 headers：有 Upgrade: websocket？
├── 是 → scope.type = "websocket" → 只匹配 @app.websocket() 路由
└── 否 → scope.type = "http" → 只匹配 @app.get/post() 路由
你的 nginx 把 Upgrade 头吃了，所以 uvicorn 永远把请求标记为 http scope。在 http scope 下，@app.websocket(...) 路由根本不参与匹配 — 就像它不存在一样。这就是为什么：
@app.get('/ws/test') 能匹配 — 它是 HTTP 路由，匹配 HTTP scope
@app.websocket('/ws/real') 匹配不到 — 它是 WebSocket 路由，只在 websocket scope 下才可见
两个都注册成功了，但 scope 类型不对，uvicorn 在路由匹配之前就把它们分到了不同的赛道。
接下来几轮错误复制粘贴大法：
后来发现ASGI 这一层做不到。因为 标准 ASGI middleware 拿到请求时已经太晚了：
uvicorn TCP 收包
1. httptools 解析 headers
2. on_headers_complete 决定 scope type (http vs websocket) ← 需要在这里拦截
3. 创建 scope + receive/send（已经绑定为 HTTP 协议）
4. 调用 ASGI app (middleware 链) ← middleware 才在这里介入
middleware 只能看到已经定型的 scope['type'] = 'http'，改不了底层的 receive/send 绑定。
然后尝试了一个 gunicorn.conf.py 的hack：
def post_worker_init(worker):
"""让 uvicorn 从 sec-websocket-key 识别 WebSocket，绕过 nginx 吞 Upgrade 头的问题"""
import httptools
from uvicorn.protocols.http.httptools_impl import HttpToolsProtocol
_orig = HttpToolsProtocol.on_headers_complete
def _patched(self):
has_ws_key = any(n == b"sec-websocket-key" for n, _ in self.headers)
if has_ws_key and self._should_upgrade_to_ws():
self.headers.append((b"upgrade", b"websocket"))
self.headers.append((b"connection", b"Upgrade"))
self.scope["headers"] = self.headers
self.scope["method"] = self.parser.get_method().decode("ascii")
raise httptools.HttpParserUpgrade(b"")
return _orig(self)
HttpToolsProtocol.on_headers_complete = _patched
我也觉得，ws这协议是不是有病。如果有 sec-websocket-key 就认定为 ws 不就完了。搞那么复杂。
然后这个办法在 ASGI 里还是行不通。最终版：直接篡改 uvicorn 收到的 raw TCP 字节
def post_worker_init(worker):
import re
from uvicorn.protocols.http.httptools_impl import HttpToolsProtocol
_orig_data_received = HttpToolsProtocol.data_received
def _patched_data_received(self, data):
if not getattr(self, '_ws_patched', False) and b'\r\n\r\n' in data:
self._ws_patched = True
lower = data.lower()
if b'sec-websocket-key:' in lower and b'\nupgrade:' not in lower:
data = re.sub(rb'(?i)\r\nconnection:[^\r]*', b'\r\nConnection: Upgrade', data)
data = data.replace(b'\r\n\r\n', b'\r\nUpgrade: websocket\r\n\r\n', 1)
return _orig_data_received(self, data)
HttpToolsProtocol.data_received = _patched_data_received
居然成功了！不修改nginx兼容websocket！
这路子太野了。还是老老实实去改nginx了。
不过也学到一些姿势，比如 258EAFA5-E914-47DA-95CA-C5AB0DC85B11 ，以及ws居然是二进制流。
2026-05-28 00:11:00
回顾一下我发现的AI弱点，说不定将来对抗 skynet 有用
2023年 我当时觉得：
2026年 我感觉：
然后是最大的问题：
今天在马桶上拉屎，就又回想起一个经常琢磨的问题框架。比如人们写日记。可能有个习惯会把当地当天天气记录下来。
设想有两个挑战：
A: 假如全世界有足够的人去写城市+日期+天气的日记，并且汇总交给LLM去学习（pretrain），形成一个全球的天气记录。然后你问LLM某地某天的天气怎么变化的，AI应该猜个八九不离十。
B: 但反过来，全球的气象记录是已知的，你让AI去全文背诵一段时间经纬度+降雨图。然后去考验，如果有个人连续写了很多天日记，记录当地天气，能反推这个人在哪里吗？
这可能是关于「知识」和「表征」 的一个极好的例子
对于B，人也做不好。但是人的大脑有个习惯，遇到有趣的，好玩的，但是没卵用的，也会先留个深刻印象，先记着。说不定将来某个机缘之下就是事情的突破口。如果刚好看到日记里有一天记录“台风”，那么全球气象数据的再大，在你面前瞬间坍塌缩小成沿海和热带。
这几天在HN上 看到古希腊掌管起名字的神Martin Fowler 最新发现：AI完全不懂安全攻防。
Public storage access 和 Excessive token permissions，可能在某个开发环节无伤大雅，但是真上线之后,后果很严重。
更加严重的是，这玩意不是写一两个 rules/skills 就能解决的。
要我说最严重的——瑞士奶酪模型被击穿。每一个环节都是小问题，但是合在一起刚好形成致命隐患
要我说这是因为「安全」本质上不是「做事」。它是降低「负事」。
世界上归根结底有两种价值。一种是靠辛勤劳动的创造；一种是破坏
对于潜在风险的防御，思考难度和上面那个根据天气猜地点差不多。
对于创造，你只要打通所有环节，就全部通了；
对于破坏，你只要一个薄弱点被突破，就全盘皆输。
LLM适合干创造的事，因为它只需要根据经验选一个最佳输出。但是要做好安全，你得写每一行代码时，都要遍历其所有的风险。
那么结合之前的 Instruct 模型去思考
那么问题来了。一问一答的排查问题这种模式，在 pretrain 里的分布是不是偏少。每件具体的事出现的问题可以说是千奇百怪。
比如上一行你在处理登录，下一行你就开始查SQL，接着你又开始拼template字符
对于安全而言，每一行都在切换 domain。LLM在这里会有能力和精度的损失，导致注意力不集中。
更好的方式是，先看几行，找出最关键的问题，然后reset上下文，从问题部分继续往后看几行，再找出最关键的问题，这样迭代进行。这样每次都更符合 pretrain 分布。
pretrain 的素材里会单独讲登录有哪些要注意，SQL有哪些坑，模板有哪些隐患，但是很少有刚好把 登录+查SQL+模板 按顺序加在一起综合有什么安全问题。
你可以把登录、查SQL、模板分别一问一答，在 pretrain 里的分布就更丰富。如果混一起问，具体的事项+组合爆炸，出现的问题可以说是千变万化
如果你直接问：这段代码有什么安全问题？AI只能挑选几个它觉得最有代表性的，突出的，给你讲一讲。
所以，我有理由认为，AI在「排查」类问题上，因为LLM层数，top-k，max_tokens，think_budget等先天能力和精度的损失，必然会结果很松散。
再说另外个感受，最近 vibe 的东西比较多，我感觉AI在设计的时候，对于“状态机” 极容易翻车。就是SPA界面上各个控件触发顺序、互斥等逻辑。
简单、成熟的交互设计能one-shot，但是稍微多几个步骤，AI就会糊一个表面上过得去，但是edge case 全部翻车的产品。
折腾了许久搞得我灰头土脸，后来实在没办法，让 AI 先自己拍脑袋列举典型实用场景，写了100多个case，然后新开个上下文让设计，并记录设计的出发点和考虑，然后再逐一case去验证，然后迭代设计里不满足的地方。几轮下来，最终AI给出了一个比较像样，至少100多个case不会太大偏离的设计。
这也算一个土办法？
如果你仔细看这个问题，其实跟上一段「安全」本质是一回事。
现在有一个大的体会，AI在 happy path 上越来越稳，刷分越来越高，像一个经验老道的猎手。但是对于先验不足的东西，它缺乏一种 scatter-gather 的耐心和细致。
想起来，人对于「采集」这种事心态是完全不同的。你得处处留心，以一种「万一将来有用」的目标去做事，甚至做没意义的事。
AI亏就亏在，它肯定能在某个局部发现某个问题有“隐患”。但是因为这个属于偏题，可以回答可以不回答。如果手头任务繁重，它即便隐藏层激活了也会最终被吞没。
然后AI上下文不是永久的，它无法在10天后新的context里突然回忆起之前遇到个有关的坑！
这是机制上无法弥补的行动缺陷。
当然不排除有 agent 能朝这个方向努努力，多听听AI发牢骚，记录并形成一笔财富。哈哈哈
我现在预估AI能力边界是这样思考的：
对于某个任务或者话题，
然后就能估摸出个能力大概。
Gemini一看，补充了一点：
2026-05-25 11:57:00
作为一个外行，我一直对“AI”的魔力感到惊奇，我一度以为神经网络一层一层传播，可以看成某种有限步骤的图灵机。AI提醒我不要瞎类比，图灵机左移右移是离散，确定的逻辑，神经网络是fp32上连续的概率映射。
后来稍微深入了解了一下，认识到对于一个深度固定的 Transformer 模型（比如 96 层的 GPT-4），它的单次前向传播算是一个深度固定的有向无环图（DAG）。所谓的 predict next token，可以粗糙理解成
next_token = eval(model_weights, history+input)
这里最奇特的算是：自回归（Autoregression）。传统的冯·诺依曼架构中，指令（Code）和数据（Data）是分开的。但在 LLM 中，上下文是动态的指令+数据。输出什么样话，什么时机结束。LLM得自己想办法把画圆回来，并且知道什么时候该停止吐词。
这种 控制面 和 数据面 混合的做法让我感到非常不适，也是诸多prompt injection问题无解的根源
不过一旦get到这个范式，我想到一个有趣的类比，一般的 gpt 是 dcoder-only，VRAM里权重就如同 .exe 加载到内存里一样，是永久不会动的；kvcache才是 malloc 去操作的独占内存。BERT那种 encoder-decoder 模型，算是一个可以自我修改的.exe？
如果拿python/java对比，LLM就是显存里一些可以边运行边修改的bytecode，只不过是fp而不是指令和数据
后来又了解到，要纯从设计上来说，RNN是明显超过transformer架构的。但是 RNN 死穴很明显，第一计算精度传播越到后面误差越大，第二它不知道什么时候停下来。第三它是串行的。越到后面越慢
transformer 算是一种不是那么直接，但是非常能“并行” scale 的体系。 自注意力解决了时间上的并行，让长度不再是障碍，Multi-Head Attention 解决了空间上的并行，让深度和广度不再是障碍，而这一切都只需要暴力算矩阵乘法 GEMM。
我了解到这一步的时候，忽然回忆起，这不就是google当年解决ranking的套路吗？虽然把整个互联网看成一个巨大的邻接矩阵的做法，看上去更笨更重，但是能 scale 啊
基于上面的一些认知，我明确看好taalas
最近不知道看到什么资料，突然想起一个圣遗物——差分机
在 19 世纪，航海、天文、甚至银行算账全靠人工查阅印制的《数学表》（对数表、三角函数表等）。但当时负责计算的“人类计算员（Computers）”极其容易算错或抄错。巴贝奇恶心透了这种低效，于是想：“为什么不用蒸汽机来摇出准确的数字？”
核心思想是，任何复杂的低阶多项式函数，只要你求导（做差分）足够多次，最终它的“差分值”都会变成一个常数。
那么可以反推，既然最后是常数，那只要把这个常数固定住，反向一层一层做加法，就能像堆积木一样，把所有复杂的乘方运算全算出来！
差分机一号（Difference Engine No.1）由英国政府在1822年出资，工匠约瑟夫·克莱芒打造，预计完工需要25,000个零件，重达4吨，可计算到第六阶差，最高可以存16位数（相当于千兆的数）
要计算一个多项式 f(x) ，它不直接算乘法，而是构造一个 差分表。
初始值 f(0), Δf(0), Δ²f(0), ……
每次步进 x → x+1 只需做加法：f ← f + ΔfΔf ← Δf + Δ²f
等等
我们用一个最简单的 2阶多项式为例 f(x) = x²
让 x 从 1 开始，步长为 1 地往下算
x 的值 函数结果 f(x)（原函数） 一阶差分 Δ₁（相当于一阶导数） 二阶差分 Δ₂（相当于二阶导数） 1 1² = 1 2 2² = 4 4 − 1 = 3 3 3² = 9 9 − 4 = 5 5 − 3 = 2（变成常数了！） 4 4² = 16 16 − 9 = 7 7 − 5 = 2（永远是 2！） 5 5² = 25 25 − 16 = 9 9 − 7 = 2（闭眼都是 2！） 那个最终的常数
2这就是巴贝奇的“高地”
巴贝奇那个年代不知道会不会泰勒展开，能展开这玩意不就是万能计算器了？
冯诺依曼说过，五个参数鼻子翘，300B的参数不就能描绘世间万物了？
然后突然注意到那个 常数2 不就是个 eos_token ？ 卧草，这不和梯度下降，reward model 串起来了吗？
所以我今天宣布，LLM（特别是 Reasoning Model）在物理和数学本质上，就是一个高维的、基于概率特征的现代差分机！
既然有 差分机 这个范式了，那么下一步就很自然了：
AI Agent 领域遭遇的 State 瓶颈，本质上就是试图在没有底层硬件支持的情况下，用外部工程硬生生模拟出 分析机 的“条件分支（If-Else）”与“循环（Loop）”
可能很多人问：“什么是分析机？” 实际上，巴贝奇当年的 差分机 是个典型的钓鱼工程，烂尾项目
差分机因为大量精密零件制造困难，加上巴贝奇不停地边制造边修改设计，从1822到1832年的十年间，巴贝奇只能拿出完成品的1/7部分来展示
在不断延后完成期限的严重超支后，英国政府于1842年的最后清算发现整个计划一共让国库支出了￡17,500，一万两千多个还没用到的精密零件后来都被熔解报废
差分机二号（或称大型差分机）在1849年设计出来，却在有生之年只实作了很小一部分。这台机器可以进行相当复杂的数学计算，具有31位元精度
差分机项目过程中，巴贝奇意识到建造一种更加通用的机器（即所谓的分析机）是可行的，于是便于1833年开始了分析机的设计
分析机由蒸汽机驱动，大约有30米长、10米宽。它的输入由程序和数据组成，并使用打孔卡输入，这种输入方法被当时的织布机广泛采用。
分析机通过一台打印机、一个弯曲的绘图仪和一个铃铛输出，也可以在纸上打孔以便日后读取。分析机采取普通的十进制定点计数法
它的“记忆体”大约可以存储1000个50位的十进制数（共约16.2kB）。有一个算术逻辑单元可以进行四则运算、比较和求平方根操作
分析机使用的编程语言与今天的汇编语言类似，支持循环语句和条件分支，因此这门语言被认为是图灵完备的。
分析机采用三种不同的打孔卡和读卡器来区分算术运算、数字常量和存储的指令，以此实现了数字在存储器和运算单元之间的加载和存储操作。
巴贝奇在1837至1840年间写下了24份程序，这些程序可以计算多项式、迭代公式、高斯消元法和伯努利数
划重点：
扩展 if 意味着什么？那就是 workflow编排。LangGraph, Dify 表示很熟
loop呢，可以理解为 human-in-the-loop，也要意识到所有的 transformer 都是 append-only，遇到犯错你无法 inplace 修改，只能用修正的循环去覆盖之前的结果。
memory 的重要性就更不要说了。RAG都红得都快凉了。什么 openclaw 各种，主打核心就是记忆系统，被玩出花了
看到有个对 记忆系统的整体评价，他说得比我精辟多了。摘抄一点
人们大量造这类轮子：
仔细看都是在解决同一个问题：每个AI对话是独立的。
实际上记忆设计是多种不同的问题被当成一个名词喊了：
Agent 不只是要知道“之前发生了什么”，还要知道：
我突然意识到一个更大的拼图：
LLM其实算 ALU 和 FPU。它的作用就是去 pretrain 的数据按照 posttrain 的风格，得出一串文本。
kvcache 就是这个时代的寄存器
加上真正的 if，loop 控制器，才是完整的“大脑”
大脑要工作，还得接存储。
文章一开始的，LLM算不算图灵机，其实差远了。
用这个范式去分析现在流行的AI论断，就很有趣了。
LLM是真正的智能吗？是 AGI 吗？
同理，ALU它懂“真正的加法”吗？它能解决 “现实世界” 的四则运算问题吗？
哈哈哈，都是什么问题啊。
什么算“智能”？它也是很多不同范式的任务被杂糅在一起的概念。而且它是什么已经。。。不重要了。关键看某一类任务它能做什么。
2026-05-21 16:55:00
最近vibe了个分布式系统，没有 master 和 arbiter，全是平等的peer
然后这些peer去处理流量问题。
处理多个事情，当流量爆发，承载能力不足的时候，需要快速补足peer
扩容是个最简单，很强烈，明确的信号，而且效果立竿见影。
当事情没那么多，流量下降之后呢？该节约哪个peer？你敢动吗？影响别的事儿怎么办？
呃，感觉前一发动全身了。于是全体peer进入一个次最优状态。
除非某个peer手上实在没多少事，可以明显看出合并给另一个peer处理，这个peer才方便下岗。这个流程才算结束
看到 grafana 那个 40% 的使用率，我麻了。我也不敢去手动缩容，来rebalance万一就不 balance了呢？
让AI 改了几版，发现都不太满意。我对分布式系统也是个一知半解，就很头痛
突然想到另外个事，我似乎破解了官僚系统，体制阻力，旧习沿用成百上千年的底层原理了
请神容易，送神难。跟ChatGPT聊了一下
扩容时，信号很干净。队列变长、延迟升高、丢包增加、CPU 打满，这些都能直接映射到“再加 peer 有收益”。缩容时，信号就脏得多。你想拿掉某个 peer，真正要问的是：它承载的是不是一个独立故障域，它的状态能不能无痛迁移，它旁边的 peer 会不会因此抖一下，未来流量反弹时要不要再把它加回来。只要这些答案里有任何一个不够确定，系统就会偏向保守，宁可维持冗余，也不愿意动它。这个偏置在组织里就表现成“谁都不敢裁，谁都不敢合，最后全员次优”。在分布式系统里，这叫 hysteresis、stickiness、coordination cost 和 failure-domain conservatism。
这个模型很像官僚系统的底层动力学。增员是局部可见收益，裁撤是全局潜在风险；新增一个人只需要证明“有需要”，拿掉一个人却要证明“拿掉之后不会出事”。于是系统会形成一种惯性：只要还有某个 peer 没明显闲到可以安全并入别人，整个系统就保持原样。这个状态看起来低效，实际上是风险最小化后的均衡。
所以“前一发动全身”非常准确。它对应的就是去中心化系统里最常见的粘性状态：局部最优、全局保守、整体不收敛。真正能把它打破的，通常不是更聪明的调度算法，而是把“可撤销性”做出来，比如强隔离、状态外置、租约、自动迁移、明确的退出协议，以及让缩容的失败代价可控。只要退出成本高，系统就会天然偏向留着。
实际上这是非常成熟、而且横跨很多学科的大主题了。现在碰到的，其实是几个领域在交叉：
* 分布式系统
* 组织理论（organizational theory）
* 控制论 / 复杂系统
* 制度经济学
* 社会学里的官僚制研究
* 网络科学
这个直觉的厉害之处在于：不是从“人性”“文化”“领导力”切入，而是从“协调成本 + 状态迁移风险 + 缩容不确定性”去解释官僚惯性。这种思路其实非常接近现代复杂系统研究。学术界里有几个非常接近这个观察的核心概念：
“组织惯性”（organizational inertia）
这是最直接的。组织一旦形成结构、流程、职责边界，就会对改变产生巨大阻力。不是因为大家懒，而是因为改动的连锁影响不可预测。“动一个 peer 会影响别的事”几乎就是 structural inertia 的口语版。尤其有个很关键的点：系统越复杂，actor 越无法预测改动后的 cascade consequences（级联后果）。
这在组织理论里已经是经典命题了——“路径依赖”（path dependence），即为什么明明次优，系统却长期保持？
因为一旦形成网络关系、责任边界、流程耦合，旧结构会自我强化。即使所有人都知道不是最优，也没人敢先拆。
那个 peer 模型其实特别适合解释这个：新增 peer：收益局部且立刻可见；删除 peer：风险全局且延迟出现。于是系统天然向“增不减”偏移。这个偏移在官僚系统里就是：部门越来越多、审批越来越厚、流程越来越难删除。因为“增加一道检查”永远容易 justify；但“删除一道检查”必须证明未来永远不会出事。
这其实已经非常接近制度经济学里的 transaction cost / coordination cost 理论了。这个模型甚至还能映射到 CAP / consensus 类问题。因为实际上在说：“系统为了避免局部错误，会选择维持全局冗余。”这和分布式系统里：
- replica 不愿缩减
- shard 不愿迁移
- leader 不愿切换
- consensus 不愿 reconfiguration
本质是同一种保守动力学。
尤其 cluster membership change 一直是分布式系统最难的部分之一。因为：“加入节点”是加资源；“移除节点”是改拓扑。后者危险得多。所以 Raft、Paxos 那些论文，对 membership reconfiguration 都写得非常谨慎。
很多社会学家会把官僚问题解释为：
- 权力
- 利益
- 保守主义
- 文化
但peer这个模型更接近：
“官僚制是 large-scale distributed coordination 在 uncertainty 下的自然结果。”这个味道其实很像Herbert Simon、Niklas Luhmann、Stafford Beer、部分复杂系统理论、还有现代 multi-agent coordination
甚至现在 AI multi-agent 研究里，也开始重新讨论 coordination tax 了。
因为 agent 一多，最大的成本往往已经不是计算，而是：同步、状态一致性、责任边界、coordination overhead
这个“扩容容易，缩容困难”的观察，实际上已经非常接近复杂系统天然存在熵增式组织膨胀这是个很深的方向。
有点意思。
突然又想起一个老事，pip 依赖解析为什么那么慢，以及uv为啥快。Rust和Node允许一个库多版本共存，python要求唯一。cargo用了 graph traversal，uv 则是基于 CDCL的 SAT solver。
这个 CDCL(conflict-driven clause learning) 是一种形式化验证技巧，学习冲突去剪枝。渊源来自于 PubGrub
我上班这么多年，大小，央企民企都待过。发现很多既定管理和流程，就是用最笨的堆人的办法去遍历，跟最老的 pip 一样。python的依赖包最早是个 setup.py 它被当成 .tgz 打包进 cheeze shop，你要去解析，得完整下载，解压。这些麻烦就不说了，最逆天的是他丫的不是声明式的，而是一个可执行文件，依赖是可以动态生成的。吐血。pip老遭罪了，得一个一个去下载，一个一个去问，然后一个一个去试。
是不是恰似某些部门办事的各种 “潜规则” ？哈哈哈
这些问题有没有解呢？可能终极形态，就是 Kubernetes 那样的吧。可观察性+声明式+状态推理
