"Ralph is a Bash loop."
——Geoffrey Huntley, 2025 年

这句话是对 Ralph Wiggum 技术最精确的定义。不是架构图，不是论文，不是 200 页的设计文档。就是一个 while 循环。把同一个 prompt 反复喂给 AI，让它看到自己上一轮的产出，然后改进。再改进。直到成功。

第 3 章定义了 Spec——你和 AI 之间的合约，写清楚"做成什么样才算对"。合约签完了，履约过程仍然充满不确定性。Agent 第一次实现可能偏离规格，第二次修好一个问题却引入另一个，第三次陷入改动 A 破坏 B、修复 B 破坏 A 的死循环。

Ralph Loop 应对的就是这个。如果 Spec 管"做到什么标准"，Ralph Loop 管"做不到就继续做"。它不是一个文档，不是一个 Skill——它是一个自主循环控制结构，把 AI Agent 从一次性助手变成了不知疲倦的初级工程师。

本章三条线索。第一，Ralph Loop 的起源——一个《辛普森一家》的梗如何变成了 AI 工程中的核心模式。第二，Anthropic 官方的 ralph-wiggum 插件——用 Stop Hook 实现会话内自指涉循环，目前最优雅的实现。第三，Ralph 生态中的其他实现。

自指涉（self-referential）：AI 的产出变成自己的输入。不是把上一轮的输出文本喂给下一轮——而是 AI 在文件系统里读到自己刚写的代码，发现 bug，自己修。输入始终是同一个 prompt，但 AI 每次看到的文件系统都不一样，因为它上一轮已经改过一遍了。

阅读全文

"The specification is the source of truth, and code derives from it — not the other way around."
规格是真理的来源，代码派生自规格——而不是反过来。

——Deepak Babu Piskala, 《Spec-Driven Development: From Code to Contract in the Age of AI Coding Assistants》, 2026 年

Skill 是 AI Agent 的能力单元：一个 Markdown 文件定义一种行为，小而可组合，可复用可迭代。但多个 Skill 组合在一起时，它们之间的"合约"是什么？谁来保证 /tdd 写的测试和 /grill-with-docs 对齐的需求是同一件事？

这就是规格驱动开发（Spec-Driven Development，SDD）要解决的问题。如果 Skill 是原子能力，那么 Spec 就是这些能力之间的接口协议。它不定义"怎么做"，而是定义"做成什么样才算对"。

三条线索：SDD 的思想史（根源比 AI 编码工具早得多，但 AI 让它从学院派理想变成了工程必需品）；三个代表性工具的逐层分析（OpenSpec、GitHub Spec-Kit、AWS Kiro）；跨工具的通用原则。

三个线索汇聚到一句：规格不是在浪费时间写文档——规格是你和 AI 之间最有效率的通信协议。

阅读全文

本文深入分析 Matt Pocock 的 Skills 系统——目前社区中设计最精良、哲学最自洽的 AI Agent 能力单元框架之一。它不追求最大最全，但它对「什么是一个好的 Skill」这个问题的思考深度，远超同类项目。从 Prompt-Driven 到 Skill-Driven——Prompt 消失在对话历史里，Skill 留在工具链里。

阅读全文

事情的起点，是 Go 仓库里一个很普通的 issue（golang/go#77273）。

在 Go 这种量级的开源项目里，每天都有人提出各种各样的提案：增加一个语法糖、调整一处行为、复活一个曾经被否决的设计……其中有相当一部分，是在重新提起一个早已被讨论过、并且已经下过结论的话题。

对维护者来说，这是一件很消耗精力的事。如果每个人都可以无限次地把一个已经决定的问题重新拉出来辩论一遍，那么决策永远不会真正「落地」，团队会被无穷无尽的回锅讨论拖垮。

于是，在这条 issue 的讨论里，有人贴出了 Go 官方提案流程（go.dev/s/proposal）中的一段话：

一般来说，对于「重新审议此前已经决定的提案」这件事，我们的做法遵循 John Ousterhout 在他那篇 Open Decision-Making 中给出的建议，尤其是其中「Reconsideration（重新审议）」那一节。

换句话说，连 Go 团队这样的顶级工程组织，在「怎么做决策、决策之后还要不要重新讨论」这件事上，引用的也不是某套高深的管理学理论，而是 John Ousterhout —— 也就是写《软件设计的哲学》那位斯坦福教授 —— 的一篇博客。

那一节的核心其实只有一句话：当有人想推翻一个已经做出的决定时，先问一句 「你掌握了什么新的信息？」（What new information do you have?）。如果没有新信息，那就不必重新讨论；如果有，那随时欢迎修正。

这套关于「决策」的方法论，远不止「要不要重新讨论」这一个点。Ousterhout 在这篇文章里，系统地讲了他在两家创业公司里摸索出来的一整套**开放式决策（Open Decision-Making）**框架。

下面是这篇文章的完整翻译。

---

开放式决策

作者：John Ousterhout，斯坦福大学计算机科学系教授
原文：Open Decision-Making
最后更新：2021 年 6 月 8 日

引子

在创办并领导两家创业公司的过程中，我亲历过形形色色的决策：有些成功，有些惨败。回过头看，那些好与坏的结果背后，其实有一套可以总结的规律。我逐渐形成了一套自己偏爱的决策方法，它处在「集权 — 开放」这条光谱中相当靠近「开放」的那一端：与其依赖少数几个人拍板，不如尽可能去汇聚许多人的集体智慧。

很多管理者对这种做法心存疑虑，担心它低效、担心自己失去掌控。但我的经验恰恰相反：

• 达成共识，往往比你想象的要容易。
• 领导者其实不需要把决策攥得那么紧。
• 尽早把争议摆到台面上，反而能减少后期的冲突。

阅读全文

seq 库的一行代码，从左读到右。写过 lo.Map(lo.Filter(...)) 的人，大概会愣一下。

这个库的开发我昨天晚上在微信上了做了直播，展示我如何使用Loop Engineering 从 0 构建出来。使用的是火山引擎的coding plan, GLM-5.2模型，花了 2 小时，耗费Token 7.23M。你可以查看直播回放：

你也可以访问这个库的项目地址： https://github.com/smallnest/seq， tasks目录中有需求文档和设计文档。

阅读全文

写好一篇设计文档并不是一件容易的事情，本文从 Go 官方 proposal 仓库（golang/proposal/design）中挑选了几个公认优秀、影响深远的设计文档，提炼它们的共性结构与写法，总结成一份可复用的设计文档写作指南，并精炼成一个 to-design skill。

阅读全文

"Same person. Different era. The difference is the tooling."
人未变，时代已改。拉开差距的，全在工具。

——Garry Tan, Y Combinator 总裁 & CEO, 2026 年

卷首语用五个人的故事画出了一幅图景：Karpathy 半年没写代码，Amodei 预言 90% 代码将由 AI 完成，Garry Tan 的产出翻了 810 倍，Boris Cherny 不再写代码只审查代码，antirez 放下了亲手雕琢每一行的执念。这些信号指向同一个结论——软件工程正在经历自 1968 年这门学科诞生以来最深刻的一次范式转换。

本章建立理解这场变革所需的概念坐标。它是怎么一步步走到今天的？新旧范式之间真正的断裂在哪里？全书贯穿的那根主线——"用结构化知识驾驭非结构化 AI 能力"——是怎么来的？

阅读全文

"I don't think I've typed like a line of code probably since December, basically, which is an extremely large change."
从去年十二月起，我基本上一行代码都没写过，这是一个巨大的变化。

——Andrej Karpathy，No Priors 播客，2026 年 3 月

阅读全文

Machine Learning Transformers LLM Neural Networks AI

本文带你走一遍 LLM 的工作原理。现代 LLM 大多是由 transformer 块反复堆叠而成的，因此理解了 transformer 机制，你就掌握了大部分。

我将覆盖现代基于 transformer 的 LLM 内部的核心机制，避开那些复杂的数学。别误会，你应该学数学，但本文可以作为一个入门。

大多数现代 LLM 共享同一套 transformer 家族的骨架。差异来自于各自的训练数据、规模和配置选择，以及在此之上的后训练。读完本文后，你应该能够阅读许多现代 LLM 论文或模型卡，并知道每个部分在讲架构中的哪个组件。

路线如下：

1. Token——一串文本如何变成一组整数序列
2. Embedding——这些整数如何获得含义
3. 位置编码——模型如何知道 token 的顺序
4. Attention——token 之间如何交换信息

阅读全文

Go 在发布新版本时经常会附带实验性特性（experimental features）。

这些实验性特性有不同的形式：有时是标准库中全新的包，有时是编译器或运行时的改动，偶尔也可能是对 Go 行为的破坏性变更。

大多数情况下，实验性特性的目的是在某个功能正式进入 通用可用（general availability） 阶段、成为 Go 的永久组成部分之前，从用户那里获取真实世界的反馈。如果该特性导致性能退化，或收到社区的负面反馈，它可以在最终定稿前被修改——甚至被完全放弃。

阅读全文