在 GitHub Copilot 代码补全率突破 40% 的今天，当绝大多数开源项目忙着在 Issue 区部署 AI 机器人和自动翻译插件时，Zig 语言项目组却干了一件极度“反潮流”的事：他们颁布了史上最严厉的 LLM 禁令。禁令范围不仅覆盖代码提交，甚至延伸到了 Issue 提问、PR 评论，连用 AI 做英译中都在封杀之列。这并非保守主义者的最后挣扎，而是一场针对开源社区“信息熵增”的激进实验。深挖 Zig 的技术决策逻辑，你会发现这并非单纯的文化排外，而是对 LLM 特性的精准狙击。目前的 LLM 本质上是概率模型，擅长生成“看起来正确”的文本，但在系统级编程领域，代码的正确性要求是 100%，任何微小的幻觉都可能导致内存泄漏或段错误。Zig 作为一个致力于取代 C 语言、强调编译期计算和内存安全的底层语言，其维护成本极高。维护者需要处理的是复杂的指针运算和对齐问题，而不是分辨一段流利的英语背后究竟是真实的人类意图，还是 GPT-4 的胡编乱造。禁止 AI 翻译更是神来之笔——在技术沟通中，蹩脚但精准的“中式英语”往往比 AI 润色后丢失了上下文语境的“完美英语”更有价值。这直接切断了“低信息密度内容”通过 AI 包装成“高信息密度”的伪装链条。这一政策对行业的影响堪称核弹级。过去两年，开源社区正遭受“AI 垃圾”的围剿，大量由 LLM 生成的低质量 PR、没有任何调试信息的 Issue 报告充斥着维护者的信箱，极大地推高了开源项目的维护成本。Zig 的禁令实际上是在划定一条红线：开源的核心资产是核心开发者的“注意力”，而非代码的数量。当其他项目还在为 AI 带来的贡献数量暴涨而沾沾自喜时，Zig 选择通过提高准入门槛来过滤噪音。这可能会引发开源模式的范式转移——从“开放式协作”转向“精英式协作”。如果这一模式被验证有效，我们可能会看到更多核心基础设施项目（如 Linux Kernel、LLVM）跟进，将 AI 辅助贡献标记为不受欢迎的行为，甚至开发出专门检测 AI 生成内容的反机器人系统。对于普通开发者和 AI 从业者而言，这记耳光打得非常响亮。它意味着“提示词工程”在严肃的系统编程领域正在失效。如果你无法脱离 AI 独立完成 Bug 复现和逻辑构建，你在 Zig 社区将被视为“无效贡献者”。这对那些过度依赖 Cursor 和 Copilot 的新手工程师敲响了警钟：工具可以提升效率，但不能替代你对底层原理的理解。在 AI 时代，最稀缺的资源不再是代码生成能力，而是代码审查能力和对系统架构的深度认知。Zig 正在倒逼贡献者回归“硬核”状态——要么读懂源码，要么闭嘴。这实际上是在进行一场大规模的图灵测试：只有真正理解代码逻辑的人，才配拥有提交权限。当然，这种强硬姿态能维持多久是个未知数。当 GPT-5 或 Claude 4 能够通过图灵测试，完美模拟人类工程师的语气和逻辑时，Zig 的禁令是否会沦为一纸空文？或者，这会成为人类程序员在 AI 浪潮中保留的最后一块“纯血飞地”？在这个 AI 无处不在的时代，我们是否应该重新审视：开源精神的本质，究竟是“人人为我”的协作，还是“人机共生”的狂欢？
* * *
02 / 08
推理算力暴动：Scaling Law 的下半场在测试时
2026-04-30T09:42:51+08:00
Noam Brown（OpenAI o1 核心贡献者）最近抛出了一个反共识观点：“Inference compute is a strategic resource.” 这句话看似平淡，实则是对当前 AI 范式转移的最冷峻注脚。过去两年，行业疯狂迷信预训练算力的暴力美学，认为只要 H100 够多、数据够大，AGI 就会自然涌现。但现实给了这种线性思维一记耳光：Scaling Law 并没有死，它只是换了个战场——从训练时计算转移到了测试时计算。这背后的技术逻辑并不复杂，但极具颠覆性。传统的 LLM 推理是“快系统”模式，一次前向传播生成一个 token，算力消耗是恒定的。而以 o1 为代表的新范式，引入了“慢系统”思维，通过 CoT（思维链）和搜索算法（类似 AlphaGo 的 MCTS），让模型在输出最终结果前，在潜在空间中进行大量的自我博弈和纠错。这意味着，模型在推理阶段的算力消耗不再是常量，而是变量，甚至是一个指数级增长的变量。我们不再仅仅是在“训练”一个模型，而是在每次“使用”时都在进行微调级别的计算。这种计算范式的转移，直接导致推理算力需求呈指数级爆发，瞬间填满了现有的算力储备。这对产业链的冲击是结构性的。Latent Space 近期关注的 CPU compute/sandbox 赛道，正是这一趋势的注脚。当模型开始具备 Agent 能力，代码执行、工具调用成为常态，这些任务并不总是需要 GPU 的张量核心，反而对 CPU 的逻辑处理能力和沙盒环境的安全性提出了极高要求。GPU 厂商的垄断地位开始出现裂痕，高性价比的推理芯片和 CPU 算力正在重获新生。云厂商的商业模式也将被迫重构：过去卖的是“存储”和“训练时长”，未来卖的是“思考时间”和“搜索步数”。谁能提供更低成本的推理算力，谁就能在 Agent 时代掌握定价权。对于 AI 从业者，这不仅是技术迭代，更是生存逻辑的重写。如果你的产品还在依赖简单的单次 Prompt 调用，你的护城河将荡然无存。未来的应用开发，必须在“响应延迟”和“推理深度”之间做极致的权衡。你需要设计机制来控制模型的“思考预算”，防止 API 费用在一次复杂查询中失控。同时，Inference Engineering 将取代 Prompt Engineering 成为显学，如何优化 KV Cache、如何设计并行搜索策略、如何构建高效的 CPU Sandbox，这些硬核工程能力将成为区分高级工程师和调包侠的分水岭。训练算力决定了模型能走多远，而推理算力决定了模型能跑多快。当我们在为模型智力飞跃欢呼时，必须意识到，每一次“顿悟”背后都是真金白银的算力燃烧。留给开发者的问题是：当智能成为一种昂贵的计算资源，你的产品利润率还能撑得起这份“聪明”吗？
* * *
03 / 08
App Store已死？RSS才是AI时代的流量入口
2026-05-01T02:38:48+08:00
Matt Webb 最近抛出了一个看似复古的观点：我们需要 RSS 来分发“氛围编码”（Vibe Coding）的应用。这听起来像个 Web 1.0 时代的冷笑话，但如果你看懂了 LLM 对软件生产关系的重构，就会意识到这是对现有 App Store 模式最犀利的降维打击。当写代码的成本无限趋近于零，软件分发的瓶颈不再是生产，而是渠道。所谓“氛围编码”，本质上是将自然语言意图直接映射为可执行逻辑。Andrej Karpathy 曾断言，未来的编程就是对着 LLM 说话。这导致的结果是，软件不再是稀缺的重资产，而是变成了像博客文章一样的一次性消费品。你为了解决一个极其细分的痛点——比如“把上周的 Notion 日志转换成特定格式的 Excel”——随手 Prompt 一个小工具，用完即弃。这种高频、碎片化、极度个性化的应用形态，与 App Store 繁琐的审核机制、高昂的维护成本完全背道而驰。Webb 提议的 RSS 方案，核心在于“Feed Item 即应用”。技术实现上，这要求 RSS 的 Item 不再仅承载文本摘要，而是封装了代码逻辑的标准化容器。那个“Install”按钮，实际上是在调用某种轻量级运行时环境。这里的技术难点在于“安装到何处”。目前的操作系统生态被 iOS 和 Android 的沙盒机制严密把持，跨应用的互操作性极差。但这并非无解，WebAssembly 和 PWA（渐进式 Web 应用）正在蚕食原生应用的领地。如果未来的 OS 能提供更底层的 Web 容器支持，RSS 订阅源就变成了应用商店，浏览器或阅读器就成了新的 OS 入口。这对行业的冲击是结构性的。首先，中心化的流量分发逻辑失效。App Store 的排名机制建立在“重应用”逻辑上，而 Vibe Coding 时代，应用是原子化的。长尾需求不再需要被妥协进通用软件，而是拥有独立的生存空间。其次，SaaS 行业的护城河将被解构。当一个 RSS Feed 能推送成千上万个针对特定场景优化的微工具，用户为何还要为臃肿的 SaaS 套餐付费？软件行业将从“产品交付”彻底转向“能力交付”。对于开发者和从业者，这意味着必须放弃构建“大而全”平台的执念。未来的核心竞争力，在于能否通过 Prompt Engineering 快速生成高质量、可复用的微服务模块，并将其标准化封装。你需要关注的不再是 DAU 和留存率，而是你的 Feed 订阅数和工具的调用成功率。对于企业 IT 部门，与其采购昂贵的商业软件，不如搭建内部的 RSS 工具流，让员工用自然语言生成自己的生产力工具。当软件像自来水一样通过 RSS 管道流进你的设备，且不论操作系统是否允许，人类真的准备好管理数以万计的个性化微应用了吗？
Note from Andrey: I know there haven’t been posts on Substack in the past couple of weeks… Starting this week they’ll resume at a regular cadence, as usual I apologize for the inconsistency. Our 242nd episode with a summary and discussion of last week’s big AI news! Recorded…
* * *
08 / 08
AI写的代码，其实根本藏不住
2026-05-01T05:24:55+08:00
Andrew Kelley（Zig 语言作者）最近抛出了一个反共识观点：认为无法区分 LLM 代码和人类代码，纯属误解。过去几个月，虽然没能 100% 拦截 AI 辅助的 PR，但区别显而易见——人类犯错的方式和 LLM 的幻觉，在底层逻辑上有着根本性的物种差异。 从技术底层看，这种差异源于生成机制的本质不同。LLM 基于 Transformer 架构，本质是概率模型，追求的是 Token 预测的“合理性”和上下文的“连贯性”。模型产生的幻觉，往往是构建了一个语法完美、甚至符合惯用模式的代码块，却在 API 调用或逻辑链条上凭空捏造。这种错误带有强烈的“平滑感”——它看起来太正确了，以至于不像人写的。反观人类错误，更多是拼写失误、逻辑断层、或是忘记处理边界条件。人类的错误是“离散的”、“粗糙的”，而 AI 的错误是“连续的”、“平滑的”。这种底层特征的区别，使得经验丰富的开发者只需一眼就能识别出那股“AI 味”。 这直接击碎了“AI 能完美混入代码库”的幻想，对开源社区造成了深远影响。维护者们正在面临一场“劣币驱逐良币”的危机，大量由 LLM 批量生成的 PR 淹没了 Issue 区。这些代码往往能通过 CI，甚至能跑通 Happy Path，但在 Edge Case 面前一触即溃。行业里充斥着 AI 提升效率的论调，却忽略了 Code Review 的核心成本从“查找语法错误”变成了“鉴别逻辑陷阱”。这种隐性成本正在急剧拉低开源项目的维护效率。所谓的“无法区分”，很多时候不过是审查者对细节的妥协，而非技术上的不可行。当项目维护者需要花费数倍精力去甄别哪些是真诚的贡献，哪些是概率模型的“胡言乱语”，开源协作的信任基石便开始松动。 对于开发者而言，这释放了一个极其危险的信号：试图用 LLM 生成的代码冒充人工提交，正在消耗你在技术社区的信用资产。审查者的直觉比想象中敏锐，一旦被打上“AI 投毒者”的标签，后续的每一次贡献都会被置于显微镜下。更重要的是，这倒逼我们重新思考 AI 辅助编程的边界——AI 擅长生成样板代码，但在逻辑构建上，它目前仍无法模拟人类思维的“不完美性”。如果你想让代码通过审查，不仅要修正 Bug，还要学会给代码注入“人味”，即那些无法被概率模型预测的独特逻辑路径。盲目依赖生成式 AI，不仅无法提升竞争力，反而会让你在资深工程师的审视下无所遁形。 既然 LLM 的代码痕迹如此明显，为什么行业内依然充斥着“AI 无处不在”的恐慌？或许问题不在于模型太强，而在于我们对于“代码质量”的定义，正在被这种廉价的高产出生成物逐渐稀释。
夜雨聆风
