2025-11-20 前端卡顿常源于产品逻辑缺陷，而非技术优化不足。

1. ClickHouse为C++代码库维护了基于CMake的巨型CI系统，日均70个PR、145次提交，执行数千万次独立测试来捕捉内存损坏、段错误和竞态条件。 2. 渐进式迁移路线：先集成Rust到构建系统（通过Corrosion与CMake集成），从BLAKE3哈希函数开始，逐步扩展到clickhouse-client CLI和Delta Lake格式库。 3. Delta Lake案例证明了Rust生态优势：Databricks官方Rust库Delta-kernel-rs远优于C++实现速度，ClickHouse认为自研C++版本"毫无意义"。 4. Rust与C++混用的核心痛点：可重现构建需重新设计隔离策略、跨语言内存分配决策困难、sanitizer和交叉编译的兼容性问题。 5. Rust库的panic滥用问题突出：ClickHouse团队发现大量Rust库在不恰当场景触发panic，对实时服务器不可接受，需逐一排查修复。

⚠️

值得注意

1. 依赖爆炸：ClickHouse原有156个依赖，引入Rust后新增672个传递性依赖。虽然CTO调侃"仍不像NPM"，但对数据库系统而言，依赖链的膨胀直接放大了供应链攻击面。 2. Rust的panic文化是系统性风险。CTO明确指出"Rust代码不应该如此频繁地引发panic"，这说明Rust社区自身对panic边界的共识尚未成熟，数据库这种高可用场景需要额外的人工审查成本。 3. 混合构建系统的维护成本被低估。Corrosion只是胶水层，真正的复杂度在于两套构建系统的sanitizer配置、交叉编译工具链、代码可组合性的对齐——这些隐性成本在技术选型时往往被忽略。 4. 全量重写被明确否定。ClickHouse的结论是"不用Rust重写整个数据库系统"，这意味着C++的历史包袱将长期存在，混合架构的技术债务只会增加不会减少。

原文

◆

LLM 没意思，小扎决策太拉垮，图灵奖大佬 LeCun 离职做 AMI

InfoQ - AI＆大模型•发布于 11月20日

新闻事件型•AI行业动态•评分: 7/10

Yann LeCunMetaAMI世界模型LLM泡沫

🔬

技术洞察

1. LeCun离职消息导致Meta市值单日蒸发约450亿美元，市场将其解读为基础研究能力流失的信号。 2. 离职根本原因：Meta战略重心向GenAI产品化倾斜，FAIR的研究自由被压缩，LeCun需向28岁的亚历山大·王汇报，且其世界模型路线在内部失去资源支持。 3. LeCun认为LLM已进入"优化尾声阶段"，真正的AGI需要四种能力：理解物理世界、持久记忆、真正推理、行动规划——LLM在这四项上全部失败。 4. AMI的技术路线：世界模型+自监督学习+物理理解，目标是构建能理解、推理、规划并与现实世界深度交互的系统。 5. Hugging Face联创Delangue提出"LLM泡沫"而非"AI泡沫"的论断，预测未来几年将出现小模型生态替代巨无霸模型。

原文

◆

WebAssembly 3.0 发布，64 位内存、垃圾回收全都有，先别激动，组件模型还没做完！

InfoQ 话题 - 大前端•发布于 11月20日

知识洞察型•WebAssembly 生态•评分: 7/10

Wasm 3.064位内存垃圾回收组件模型WASI

原文

◆

Agent规模化落地前夜，AI Infra的难题全都暴露了

InfoQ - 云计算•发布于 11月20日

知识洞察型•AI基础设施•评分: 7/10

AI InfraAgent规模化异构算力调度上下文工程分级模型路由

原文

◆

Vercel 防火墙全新改版：安全分析体验大幅提升

Vercel News•发布于 11月20日

知识洞察型•云安全•评分: 7/10

WAF防火墙UI流量分析DDoS防御

原文

必知要闻

Cloudflare酿六年最惨宕机：一行Rust代码，全球一半流量瘫痪！ChatGPT、Claude集体失联

InfoQ - AI＆大模型•发布于 11月20日

新闻事件型•CDN服务故障•评分: 8/10

Cloudflare宕机Rust unwrapBot管理ClickHouse配置变更

原文

常规更新

理解规范驱动开发：Kiro、spec-kit和Tessl

InfoQ - AI＆大模型•发布于 11月20日

知识洞察型•AI编程工程化•评分: 8/10

规范驱动开发SDDAI编程AgentKirospec-kitTessl

🔬

技术洞察

1. SDD存在三个递进层次：规范优先→规范锚定→规范即源，但目前所有工具仅停留在规范优先层面，规范随时间演进的维护策略普遍模糊。 2. Kiro工作流最轻量（需求→设计→任务三文档），但面对小规模Bug修复时会产生16个验收标准的过度工程开销。 3. spec-kit通过CLI为多种编程助手创建工作区，引入"宪法"概念作为不可变高层原则，但每个规范分支的生命周期设计暗示其本质仍是变更请求级别而非功能级别的锚定。 4. Tessl是唯一明确追求规范即源的工具，规范与代码1:1映射，代码顶部标注//从规范生成-请勿编辑，但非确定性问题在低抽象层依然存在。 5. 作者指出SDD与MDD（模型驱动开发）的历史类比：LLM带走了MDD的DSL解析开销，却引入了新的非确定性代价，可能同时继承两者的缺陷。

⚠️

值得注意

1. 致命伤：三款工具均无法灵活适配不同规模的任务。Kiro修个小Bug生成4个用户故事，spec-kit为此创建了交错冗余的Markdown文件群，审查这些文档比直接审查代码更耗时。 2. Agent不遵循指令的问题被系统性忽视。spec-kit的研究步骤中Agent忽略了现有类的描述直接生成重复代码，说明上下文窗口扩大不等于理解力提升。 3. 功能规范与技术规范的边界定义模糊。spec-kit文档自身对"纯粹功能"的解释不一致，这恰恰复现了传统用户故事中需求与实现混淆的老问题。 4. 目标用户错位。工具演示大量使用"用户故事"等产品术语，暗示开发者承担需求分析职责，但SDD显然不适用于仍模糊的大型功能，这需要专业产品经理介入。 5. 规范锚定的维护成本被严重低估。当规范成为"活文档"后，谁来保证规范本身的正确性？谁来审查规范的变更？这本质上是把代码审查的问题平移到了文档层。

原文

◆