"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 留在工具链里。

阅读全文

"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 之间如何交换信息

阅读全文

2026年5月28日 · Mike Piccolo, iii 创始人兼 CEO

---

大多数 agent 团队不构建运行时。他们采用一个。LangChain、LangGraph、OpenAI Agents SDK、Anthropic SDK、CrewAI、AutoGen——循环、工具、记忆、编排，都是作为一个单一决策从货架上挑选的。运行时是一个你 import 的框架。如果里面的什么东西不合适，你就 fork 它、跟它斗争、或者绕过它。

阅读全文

你有没有过这样的经历：接手一个"跑了三年没人敢动"的项目，打开代码仓库一看——

src/ 下面 200 多个文件平铺在一个目录里，没有分层，没有模块边界。一个叫 UserService 的类 1800 行，发邮件、对接支付、状态管理全塞在里面，还挂着三个 TODO 标着"后面要重构"。业务逻辑全堆在 Service 层，Model 类只剩 getter 和 setter，贫血得像张纸。数据库查询藏在 for 循环里，每循环一次发一条 SQL。你问老员工这模块谁负责，得到一句："这个……已经没人记得了。"

Martin Fowler 把这类问题叫做"代码坏味道"（Code Smell）。Brian Foote 和 Joseph Yoder 在 1997 年的论文里给了一个更直白的名字：Big Ball of Mud（大泥球）。

阅读全文

去年我还在折腾 langchain/langgraph 开发智能体，弄了个 langgraphgo 项目，把 langgraph 往 Go 生态圈里搬。那会儿网上做智能体的，十个有八个用 langchain/Crew AI。

一个阶段有一个阶段的玩法。

现在我看到了另一种路子：大家直接用 Claude Code、Codex、OpenCode、Pi 这些 coding agent "套壳"来实现智能体。

先说两个很多人搞混的点。

别觉得这些工具只能写代码。Claude Code、Codex 的架构走的是通用智能体模式，早就不止 coding 了。

也别把"套壳"当贬义词。Manus 刚火那阵，就有同事撇嘴说"这不就是 Claude 的套壳"。但你看，Claude、Codex、Antigravity 一个个都在推 SDK，巴不得你基于它们二次开发。牛顿怎么说的，站在巨人肩膀上不丢人。

阅读全文

---

title: "从需求到上线，让 AI 管理你的整个研发流程"
author: "smallnest"
publish_date: "2026-05-17"
summary: "介绍 goal-workflow：AI 驱动的端到端研发工作流，覆盖 PRD 生成、需求拆解、代码审查、自动提交等全流程自动化"

你是否曾经有过这样的经历：

• 写了一篇 PRD，结果开发实现的时候完全跑偏

• 实现完代码后，发现还有一堆体力活要做：代码审查、写 commit、创建 PR、等待 CI 检查...

• 团队成员对同一个需求理解不一致，导致返工

• 多次开会同步需求进度，但最终代码还是和预期不一样

• Issue 拆得太细或太粗，开发时常卡住不知道下一步该做什么

• 每次提交都要重新敲一遍规范的 commit message，累死了

阅读全文

Peter Steinberger（GitHub 上的 steipete）是一个在 AI 开发工具领域绕不开的名字。他曾白手起家将 PSPDFKit 做到百万美元 ARR 并成功退出，如今在 OpenAI 负责 Agent 相关研发。他创建的 OpenClaw 项目收获了 37 万+ stars，而 Clawpatch 和 codex-review skill 是他 AI 编程工具链中专注于代码审查这一环的两个代表作。

传统代码审查有个结构性矛盾：审查者往往不熟悉被审查代码的完整上下文，所以要么流于表面（看看命名、格式），要么只能依赖作者写的 PR 描述来理解意图。AI 时代的解法很直接——让一个能读懂整个代码库的 Agent 来做审查。但不是随便把代码丢给 LLM 让它"看看有没有问题"就行，真正的挑战在于：如何划定审查边界、如何确保证据可追溯、以及发现问题后如何安全地修复。

Clawpatch 和 codex-review skill 分别从"工具链自动化"和"工作流规范化"两个角度回答了这些问题。

Clawpatch（clawpatch.ai，GitHub：openclaw/clawpatch）是一个命令行代码审查工具，MIT 协议开源。它的核心思路是把代码审查从"逐文件扫描"升级为"按语义单元审查"。

阅读全文