Twitter AI 深度长文精选｜5 月 9 日

本期精选 7 条近期 Twitter 上传播最广、技术密度最高的 AI 深度长文和 Thread，覆盖范式转变、工程方法论、架构演进与产业格局。按热度与深度综合排序。

1. Something Big Is Happening

@mattshumer_（Matt Shumer） · AI 创业者 / 投资人

"I think we're in the 'this seems overblown' phase of something much, much bigger than Covid."
——「我认为我们正处于某件事的『感觉是夸大其词』阶段，而这件事比新冠疫情要大得多。」1

互动数据：转发 28,181 · 点赞 119,009 · 回复 6,605 · 引用 13,370 · 浏览 86,606,316

Shumer 这条 Thread 大概是近几个月 Twitter AI 圈转发量最大的单篇。核心论点是：当前 AI 能力跃迁的速度在被系统性低估，就像 2020 年 1 月多数人看新冠消息时的心理状态。

他罗列了几个具体数据作为佐证：GPT-5.3 Codex 与 Claude Opus 4.6 在 2026 年 2 月 5 日同日发布1，OpenAI 在公告中声称 GPT-5.3 Codex 「instrumental in creating itself」（在自身创建过程中发挥了关键作用）；Dario Amodei 在同期的公开表态中预测，比几乎所有人类都更聪明的 AI 可能出现在 2026-2027 年1。METR 的独立测量数据则显示，AI 独立完成专家级任务的时间窗口每约 7 个月翻倍1。

这条 Thread 的另一个作用是锚定了讨论语境——此后两个月里 Twitter AI 圈大量 Thread 都在延伸或反驳他的时间线预测。

2. 编程在过去两个月发生了不可逆转的质变

@karpathy（Andrej Karpathy） · 前 Tesla AI 总监 / OpenAI 创始团队 / Stanford PhD

"It is hard to communicate how much programming has changed due to AI in the last 2 months... specifically this last December."
——「很难描述过去两个月里 AI 对编程的改变有多大……尤其是去年 12 月。」2

互动数据：转发 4,765 · 点赞 37,277 · 回复 1,601 · 引用 1,091 · 浏览 5,120,965

Karpathy 在这条 Thread 里明确划出了一个时间节点：2025 年 12 月。他认为 AI coding agents 在这个时间前后越过了质变阈值，从辅助工具变成了可以独立完成任务的协作者。

他给出了一个具体案例：某个周末他给 agent 下达了一个全栈开发任务，agent 自主运行约 30 分钟后完成2。他由此提出了「agentic engineering」的概念——开发者的工作变成：启动 AI agent、用英语下达任务、并行管理和审查多个 agent 的输出。

有一点他说得很直接：「从计算机发明以来，在编辑器里手动输入代码的那个时代，正在结束。」这个判断的边界和时间线至今仍有争议，但作为一个推动讨论的锚点，这条 Thread 是近期工程社区被引用最多的单篇之一。

3. 用 LLM 构建个人知识库：完整工作流方法论

@karpathy（Andrej Karpathy）

"a large fraction of my recent token throughput is going less into manipulating code, and more into manipulating knowledge (stored as markdown and images)"
——「我最近的大部分 token 吞吐量，正在从操纵代码转向操纵知识（以 Markdown 和图像形式存储）。」3

互动数据：转发 7,037 · 点赞 58,374 · 回复 2,849 · 引用 2,069 · 浏览 20,903,118 · 书签 105,212

这是 Karpathy 本轮发布密度最高的 Thread，单条书签数超过 10 万，说明很多人把它当作操作手册在收藏。

核心内容是一套六阶段工作流：

数据摄取：抓取 PDF、网页、截图进入 Obsidian
IDE：用 Obsidian 作为知识 Wiki 主体
Q&A：用 LLM 对整个 Wiki 做检索和问答
输出：LLM 生成新文章、笔记、分析
Linting：自动检查 Wiki 内部一致性、修复冗余
扩展工具：他自己 vibe coded 了一个针对 Wiki 的轻量搜索引擎3

他的 Wiki 大约有 100 篇文章、40 万词，由 LLM agent 负责编写和维护。这套方案刻意绕开了传统 RAG（LLM 通过维护索引文件和文档摘要实现检索，而不是依赖向量数据库）。

他同时提出了这套方案的四项设计原则：Explicit（记忆是显式可导航的 Wiki）、Yours（数据在本地，不在云端）、File-over-app（用 Markdown 等通用格式，而不是 Notion 或 Obsidian 专有格式的深度绑定）、BYOAI（可以接入任意 AI 提供商）4。

"So this approach to personalization puts you in full control."4

4. LLM 能力「锯齿化」：为什么模型在某些任务上飞速、在另一些上举步维艰

@karpathy（Andrej Karpathy） · 来自 Sequoia Ascent 2026 炉边谈话

"You're either in the data distribution (on the rails of the RL circuits) and flying or you're off-roading in the jungle with a machete, in relative terms."
——「你要么在数据分布之内（在 RL 电路的轨道上）飞驰，要么就是在丛林里拿着砍刀开路，两者之间的差距是相对意义上的。」5

互动数据：转发 730 · 点赞 5,550 · 回复 284 · 引用 121 · 浏览 794,534 · 书签 6,013

这条 Thread 是对 Sequoia Ascent 2026 炉边谈话内容的总结，算是 Karpathy 近期最系统的一次理论表达，密度高于一般推文5。

他把 LLM 能力看起来「锯齿化」的根源归结为两个相互交织的因素：

领域可验证性：代码可以运行、数学可以验证、法律条文可以对照原文——这类任务的 RL 信号清晰，模型接受了大量有效反馈，能力边界相对平滑。而那些不可验证的任务（如开放性判断、创意写作、跨领域综合推理），RL 几乎没法施力5。

经济学：收入和 TAM 决定了 RL 训练数据的分配。代码生成和数学推理背后是巨大的付费需求，有足够的经济激励推动持续训练；其他领域的 RL 数据稀缺且难以获取5。

他还顺带提出了 agent-native economy 的概念：产品和服务被分解为传感器（sensors）、执行器（actuators）和逻辑（logic），跨 Software 1.0/2.0/3.0 三层运行——这部分在 Thread 里展开较少，算是留给下一轮讨论的铺垫。

Andrej Karpathy @karpathy·1w

You're either in the data distribution (on the rails of the RL circuits) and flying or you're off-roading in the jungle with a machete, in relative terms.

View on X

Loading content card…

5. Claude Code 发布 Code Review：多 Agent 团队审查每个 PR

@bcherny（Boris Cherny） · Claude Code @AnthropicAI

"New in Claude Code: Code Review. A team of agents runs a deep review on every PR."6

互动数据：转发 497 · 点赞 7,398 · 回复 462 · 引用 125 · 浏览 1,201,485 · 书签 3,314

Boris Cherny 负责 Claude Code 工程，这条 Thread 是功能发布公告，但包含了比 changelog 更多的实现细节。

关键数据：Anthropic 工程师的代码产出在过去一段时间同比增长 200%，而代码审查成了实际的速度瓶颈6。新的 Code Review 功能用一个 agent 团队（而非单个模型）对每个 PR 运行深度审查，目的是把审查的吞吐量提高到与代码生成速度匹配。

这里有一个值得关注的架构细节：agent 团队审查与单模型审查的差异，主要体现在并行探索不同潜在 bug 路径的能力上——单模型是顺序扫描，团队可以同时从多个角度切入同一份 PR。

这条 Thread 和 Tai D. Salles 同期分析的「无需人工审查」讨论形成了对照：Claude Code 的方向是「用 AI 团队替代人工审查」，而不是跳过审查环节6。

6. SaaSpocalypse 的真正含义：AI 杀不死 SaaS，但会把它分裂成两层

@aleximm（Alex Immerman） · a16z Growth 基金合伙人

"The truth is that AI simply isn't going to kill software companies... AI is the best thing that ever happened to the software industry."7

互动数据：转发 71 · 点赞 555 · 回复 44 · 引用 40 · 浏览 365,785 · 书签 1,129

这条 Thread 写于 2026 年初 SaaS 股票大跌之后——Salesforce、Adobe 等传统 SaaS 标杆在同期下跌 25-30%，SaaS ETF 整体下跌约 30%7。Immerman 是为数不多给出结构化反驳的声音之一。

他用 Hamilton Helmer 的「Seven Powers」框架逐一分析 AI 对每种 SaaS 护城河的影响。结论分两层：

第一层：AI 本身不会让软件消失，因为业务逻辑、数据护城河、合规要求和集成成本这几个维度，AI 在 2026 年仍然无法轻易复制一家运行了十年的企业级 SaaS。

第二层：AI 会加速淘汰那些靠「摩擦力」维持地位的 SaaS——即用切换成本而非实际价值锁定客户的产品。这类产品的护城河在 AI 降低切换门槛的环境下正在快速蒸发7。

他的核心论点是：「SaaSpocalypse 不是软件的死亡，而是一个更大事物的开始。」这个判断的时间跨度没有明确给出，但文章结构上是乐观的——把当前的市值修正解读为从「流量变现」到「价值创造」的重定价，而非行业终结。

7. Transformer 时代正在结束：Memory 是真正的原因

@rohit4verse（Rohit） · 全栈 + Applied AI 工程师

"The math does not negotiate."8

互动数据：转发 48 · 点赞 312 · 回复 31 · 引用 5 · 浏览 54,975 · 书签 368

这条 Thread 的浏览量在本期 7 条里最低，但技术密度最高，适合对架构演进感兴趣的读者。

核心论点：Transformer 的 KV cache 在长上下文场景下有一个物理上限——128K context 下，一个 7B 参数的模型 cache 需要消耗 30-40GB VRAM8。这是 O(L²) 的代价，不是工程优化能解决的，是数学问题。

SSM（State Space Models）用固定大小的隐藏状态替代 KV cache：在 57K tokens 的场景下，速度快 4 倍、内存减少 64%8。代价是部分精确记忆能力的损失（RNN 的「顺行性遗忘」问题在 SSM 里程度不同但依然存在）。

Rohit 给出的落地案例：NVIDIA Nemotron-H、IBM Bamba-9B、Microsoft Phi-4-mini-flash-reasoning 都是已经在生产环境使用的 SSM 或混合架构8。更值得关注的是他引用的劳动力市场信号：Meta 据报道已开出九位数薪资挖角 SSM 领域的核心研究者8。

对于从事 LLM 应用开发的团队，这条 Thread 的实际价值在于：如果当前推理成本是你部署长上下文 agent 的主要瓶颈，SSM/混合架构路线是值得纳入中期规划的方向。

本期小结

本期 7 条内容里，Karpathy 贡献了三条，这和他在当前周期的信源地位是一致的——他在 2025 年底到 2026 年初进入了密集发布期，每条 Thread 都在尝试给正在发生的变化提供认知框架，而不只是记录现象。

值得并排看的两条是第 5 条（Claude Code Review）和第 7 条（SSM 架构）——前者是应用层对 AI agent 协作的具体落地，后者是基础层对当前架构局限的诊断。两者都在指向同一个方向：现有的基础设施在 agent-heavy 工作流下存在系统性瓶颈，且这些瓶颈是架构性的，不是参数调优能解决的。