#人工智能
一篇分析Claude Code 源码的论文：《Dive into Claude Code: The Design Space of Today's and Future AI Agent Systems》

原来没有创新的想法，只是源码分析，也可以写论文吗？

#人工智能

在 hacker news 的kimi2.6模型发布新闻下，Redis之父antirez留下了这一段评论，多少能代表现在中美以外的人的一些看法（他是意大利人）：

After Trump the US looks like a very unstable partner from which to relay in an exclusive way for a decisive technology, and given that Europe is slow to put the money in this technology to have frontier things at home, China is a huge and shiny plan B for us.（特朗普之后，美国似乎是一个非常不稳定的合作伙伴，无法在关键技术领域完全依赖它。鉴于欧洲在投资这项技术方面进展缓慢，难以在国内拥有前沿成果，中国对我们来说就是一个巨大而光明的备选方案。）

#人工智能

《DeepSeek-V4 预览版：迈入百万上下文普惠时代》

”不诱于誉，不恐于诽，率道而行，端然正己。“

#分布式
《Designing Data-intensive Applications with Martin Kleppmann》，DDIA作者最新接受的视频播客采访。

这个视频是对《设计数据密集型应用》（*Designing Data-Intensive Applications*, 简称 DDIA）一书作者 Martin Kleppmann 的深度访谈。视频中，Martin 详细回顾了他早期的创业经历、在 LinkedIn 处理大规模分布式系统的工作经验，并分享了本书第二版的重大更新、云计算抽象下的工程哲学，以及他对 AI、软件伦理和前沿学术研究的深入见解。

以下是Gemini对该视频核心观点的详细总结：

### 1. 《设计数据密集型应用》第二版的演进
* **写作初衷与背景**：Martin 提到他在早期创业时遇到数据库性能瓶颈，当时大家因为缺乏基础理论，只能在黑暗中摸索。后来在 LinkedIn 工作期间，他深入接触了大规模数据系统（如参与 Kafka/Samza 的相关工作），开始理解系统运作的本质。为了让后来的工程师少走弯路，他决定撰写这本注重实操与概念的“神书” [[16:31](https://www.youtube.com/watch?v=SVOrURyOu_U&t=991)]。
* **拥抱云原生架构体系**：第一版成书时，行业默认的架构是“在一台机器上运行数据库并写入本地磁盘”。然而，现代云服务（如建立在对象存储 S3 之上的数据库）彻底颠覆了这一点。在第二版中，他全面融入了云原生架构的理念，讨论了复制和存储如何在云端下放到对象存储层的问题 [[28:59](https://www.youtube.com/watch?v=SVOrURyOu_U&t=1739)]。
* **技术的更新换代**：随着业界的发展，曾在第一版中占据大量篇幅的 MapReduce 已经被精简并作为学习工具保留，因为现实中大家已经全面转向 Spark 和 Flink。此外，为了支持 AI 浪潮下的基础设施需求，第二版增加了对 **向量索引 (Vector Indexes)** 和 **数据帧 (DataFrames)** 存储等当代数据模型的深入解析 [[47:14](https://www.youtube.com/watch?v=SVOrURyOu_U&t=2834)]。

### 2. 云时代的工程师与“底层超能力”
* **高级抽象并不意味着可以无知**：云计算提供了大量开箱即用的托管服务（Serverless/Managed Services），替开发者屏蔽了存储扩容、内存分配等问题。但 Martin 强调，了解存储引擎（如 B-Trees 或 LSM Trees）的底层原理仍然是开发者的“超能力”。如果完全不懂底层机制，当系统面临诡异的延迟或性能骤降时，你将失去诊断和修复问题的直觉 [[34:09](https://www.youtube.com/watch?v=SVOrURyOu_U&t=2049)]。
* **架构的本质是权衡 (Trade-offs)**：设计系统没有唯一的正确答案，核心在于计算开销、人力成本与高可用性之间的妥协。比如，多区域（Multi-region）甚至多云部署能有效抵御地缘政治风险或云服务商宕机，但这会极大地增加一致性成本和维护难度，工程师必须为业务需求定制最合适的风险平衡方案 [[36:16](https://www.youtube.com/watch?v=SVOrURyOu_U&t=2176)]。

### 3. 工程师不可推卸的道德责任
* **新增伦理章节的原因**：Martin 在第一版的末尾引入了“做正确的事”章节，在第二版中这一部分被进一步强化。他指出，早年科技界的文化往往只关心“打造受用户欢迎的系统”，却无视了技术带来的负面后果（如为了广告变现而过度监控、收割用户隐私）。他呼吁工程师在开发技术的同时，必须将产品的社会伦理影响考虑在内 [[49:02](https://www.youtube.com/watch?v=SVOrURyOu_U&t=2942)]。
* **将伦理风险纳入架构考量**：工程师不能把道德问题全推给合规部门，我们有责任识别系统滥用、数据安全以及可能对社会造成的负面结果，并把这些“社会性风险”像技术风险一样纳入系统的架构评估与商业汇报中 [[51:21](https://www.youtube.com/watch?v=SVOrURyOu_U&t=3081)]。

### 4. AI 时代的软件危机与形式化验证 (Formal Verification)
* **AI 促成代码泛滥**：未来 LLM 将生成难以估量的海量代码。依靠人类工程师去逐行做 Code Review 来排查隐藏极深的并发或安全 Bug 将变得不再可行，我们需要更强大的自动化正确性验证手段 [[58:50](https://www.youtube.com/watch?v=SVOrURyOu_U&t=3530)]。
* **形式化验证是最终答案**：传统的单元测试只能覆盖有限的输入边界，而形式化验证利用严格的数学证明，可以证明代码在“无限的状态空间”和绝对所有的场景下都是安全的。过去这种技术因学习门槛过高而难以普及，但 Martin 乐观地预测，AI 将会极大地辅助撰写这类复杂的数学证明，从而让形式化方法在工业界（尤其是高可用与安全领域）变得经济适用 [[54:27](https://www.youtube.com/watch?v=SVOrURyOu_U&t=3267)]。

### 5. 回归学术界：挑战商业逻辑的尖端研究
Martin 离开工业界回到剑桥大学任教，因为学术界允许他做那些不符合短期商业利益、却对人类长远有利的研究：
* **本地优先软件 (Local-First Software)**：SaaS 公司往往通过将用户数据“锁”在云端来确保订阅费的持续收取。Martin 正在致力于打破这种极度依赖中心化服务器的现状，研发让用户完全掌控自己数据、支持离线协同且自动同步的去中心化软件。这带来了极高难度的分布式工程挑战（例如，在没有中央服务器进行共识投票的情况下，解决同一时间并发修改与权限撤销的冲突） [[01:02:06](https://www.youtube.com/watch?v=SVOrURyOu_U&t=3726)]。
* **保护隐私的供应链密码学**：他正在探索如何利用高级密码学，证明现实世界中的物理事件（比如某批咖啡豆的碳排放合规、或没有涉及砍伐热带雨林），同时不需要企业对外公开其高度机密的供应商名单或生产配方 [[01:19:20](https://www.youtube.com/watch?v=SVOrURyOu_U&t=4760)]。

### 6. 学术界与工业界的互相启迪
* 工业界由于巨大的发版压力，往往缺乏对事物第一性原理的严谨思考，甚至只是听了一个讲座就草率决定技术选型；而学术界往往过于理论化。Martin 认为，最优秀的工程师应该在这两者之间流转——把工业界的“真实问题与痛点”带进学术界，同时将学术界的“批判性思维、长线视角与严谨性”注入工业实践中，从而互相补足 [[01:17:32](https://www.youtube.com/watch?v=SVOrURyOu_U&t=4652)]。

#数学
《All elementary functions from a single binary operator》，这是一篇很有意思的论文，它提出一个二元运算符，配合常数就能生成所有的初等函数。

我们知道数字电路中最基本的元件是与非门，通过与非门能构建出其它所有电子元件。这篇论文就是给连续数学找到了它们的“与非门”。

#开源项目
#Rust

warp terminal 开源了，这是一个rust项目。

#Rust
#开源项目

numa，作者从0使用Rust打造的便携式DNS服务，将本地开发反向代理、自动 HTTPS 证书签发、广告拦截与加密隐私保护融为一体，适合开发者和网络极客的本地网络。

#开源项目
webpage-summary：总结网页内容的浏览器插件，可以配置多种常见的模型。

#投资
#世界观

李录，曾用名李路，不过似乎用哪个lu都不重要了，因为发音都叫"lu li"。

1966年出生于唐山，早年就读于南京大学，参与了89年那场风波，也因为此，位列21名被通缉的骨干之一。

89事件之后逃离中国，辗转法国最后来到美国，就读于哥伦比亚大学。在哥大期间，仅用几年读完了三个本科学位，哥大历史第一人。也因为在哥大，听了校友巴菲特关于价值投资的演讲（网传是因为把巴菲特的英文名“Buffett”听成了自助餐“buffet”），开始了自己在学生时代就起步的投资生涯。

都知道巴菲特由于投资了比亚迪获得巨额回报，但是实际上，背后提出购买比亚迪建议的，正是李录。2010年，李录帮助翻译出版了《穷查理宝典》中文版，并撰写了序言；2020年，李录的文集《文明、现代化、价值投资与中国》在中国出版。2010年，李录随巴菲特访问中国，是六四事件后首位被通缉后可以在中国大陆公开活动的学运领袖。

曾经一度传言李录有可能接替巴菲特接手伯克希尔哈萨维，但是随着巴菲特退休，确认了另外的接班人，李录最终还是继续管理自己创办的喜马拉雅资本（Himalaya Capital）。

李录的人生轨迹足够传奇：出生、成长于国家的混沌年代，青年时参与政治运动，逃亡到异国他乡重新开始后，又在顶尖学府取得相当成绩，阴差阳错进入投资圈子后取得巨大的成绩。最重要的，他在投资生涯中取得的很多成绩，标的都是中国资产，不知道对比他年轻时参与政治运动时，会如何评论现在的中国。

B站上李录在北大的演讲完整视频。

#人工智能
#开源项目
ds4：Redis之父antirez自己手撸的适配 DeepSeek 4 Flash 模型的本地C语言推理引擎，感觉也可以做为推理引擎的学习项目。

#人工智能
#播客

听晚点聊采访群核科技创始人的播客《160: 群核IPO后与黄晓煌聊这15年》，里面听到一句话：

CPU 是用的人越多、边际成本越低；而 GPU 的成本会随用量增长，这是两种芯片的硬件架构决定的

由于之前没有做过GPU编程，所以提问AI解释这段话，Gemini的回答如下。我的理解：CPU可以分片使用，但是GPU的瓶颈在显存，显存无法像CPU内存那样使用虚拟内存来调度存储资源。

这句话的内核在云计算、SaaS（软件即服务）和多租户（Multi-tenancy）基础设施的语境下是完全正确的，但前提必须澄清：这里讨论的“成本”不是芯片制造的规模经济（制造层面两者产量越大，单片边际成本都会降低），而是算力在服务端的部署与分发成本。

这种成本差异确实是由 CPU 和 GPU 截然不同的硬件架构决定的。以下是具体的逐步解析。

一、 CPU 的架构本质：为“控制”与“多任务”而生
CPU（中央处理器）的架构设计目标是低延迟（Low Latency）和复杂的逻辑控制。

强大的上下文切换（Context Switching）能力：CPU 内部拥有巨大的缓存（L1/L2/L3 Cache）、复杂的指令分支预测单元（Branch Predictor）以及专门的硬件虚拟化支持（如 Intel VT-x 或 AMD-V）。这使得 CPU 可以在极短的时间（微秒级）内保存当前任务的状态，切换到下一个任务。
超售（Overprovisioning）的基础：由于这种极速的切换能力，在云服务器上，1个物理 CPU 核心可以被虚拟出多个 vCPU，同时租给数十个不同的用户处理网页请求、数据库查询等相对碎片化的任务。
边际成本递减的逻辑：因为 CPU 极度擅长时间分片（Time-slicing），多加一个轻量级用户，系统只需要多分配一小段时间片，无需增加物理硬件。只要总负载不超过峰值，增加用户的物理边际成本几乎为零，服务器的固定成本被更多用户分摊，单客成本随之断崖式下降。
二、 GPU 的架构本质：为“吞吐”与“并行计算”而生
GPU（图形处理器）的架构设计目标是高吞吐量（High Throughput）和大规模并行处理。

极弱的上下文切换能力：GPU 的芯片面积大部分被数以千计的简单算术逻辑单元（ALU）占据，控制逻辑极其简化，缓存（Cache）非常小。它采用 SIMT（单指令多线程）模型，一旦开始计算，就需要数据如同瀑布一样源源不断地输入。如果要让 GPU 在不同用户/不同任务之间频繁切换，保存和恢复庞大的显存状态会导致极高的延迟和性能损耗，这在工程上是灾难性的。
显存（VRAM）的绝对物理瓶颈：GPU 计算（尤其是 AI 训练和推理）重度依赖显存容量和内存带宽。模型参数和上下文必须驻留在物理显存中。如果一个模型需要 20GB 显存，10个并发用户（假设各自有独立状态或微调模型）理论上就需要占用更多的显存。显存无法像 CPU 内存那样高效地使用虚拟内存（Swap）进行分页调度，一旦显存爆满，GPU 直接 OOM（Out of Memory）宕机。
边际成本随用量增长的逻辑：由于 GPU 无法像 CPU 那样高效地通过时间分片实现大规模“超售”，它只能做“空间隔离”（例如 NVIDIA 的 MIG 技术，将一张大显卡硬切分成几个独立的物理分区）。当用户量或请求量增长时，你无法通过压榨现有 GPU 的碎片时间来消化需求，你唯一的选择是购买新的 GPU 物理硬件。因此，每增加一定量的用户或算力需求，就需要成比例地增加高昂的 CapEx（硬件采购成本）和 OpEx（电力与散热成本）。
三、 总结：时间分片 vs 空间独占
CPU 是“时间共享”架构：像一辆公交车。乘客（任务）上上下下，车辆只要在跑，多载一个人几乎不增加额外油耗。乘客越多，单客成本越低。
GPU 是“空间独占”架构：像高铁的专属货运车厢。每个任务都需要实打实地占据一块物理空间（显存和流处理器阵列）。车厢塞满了，就必须花重金挂载新的车厢，甚至购买新的列车。用户的用量越大，所需的硬件规模呈线性甚至超线性增长。
因此，这句话准确地揭示了现代算力基础设施的商业现实：基于 CPU 的传统互联网应用具有极强的规模效应；而基于 GPU 的 AI 应用（如大模型推理），其算力成本目前仍表现为沉重的线性增长，极具商业挑战性。