发布时间：2026 年 6 月 1 日，星期一 · 26 分钟阅读
Machine Learning Transformers LLM Neural Networks AI
本文带你走一遍 LLM 的工作原理。现代 LLM 大多是由 transformer 块反复堆叠而成的，因此理解了 transformer 机制，你就掌握了大部分。
我将覆盖现代基于 transformer 的 LLM 内部的核心机制，避开那些复杂的数学。别误会，你应该学数学，但本文可以作为一个入门。
大多数现代 LLM 共享同一套 transformer 家族的骨架。差异来自于各自的训练数据、规模和配置选择，以及在此之上的后训练。读完本文后，你应该能够阅读许多现代 LLM 论文或模型卡，并知道每个部分在讲架构中的哪个组件。
路线如下：
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，巴不得你基于它们二次开发。牛顿怎么说的，站在巨人肩膀上不丢人。
你是不是也曾经盯着 pprof 火焰图发呆？
线上服务 P99 延迟从 50ms 飙到 800ms，Grafana 告警刷了满屏。CPU profile 翻来覆去看了三遍，热点函数是 sync.Mutex.Lock —— 锁竞争。但问题出在哪？锁粒度大、false sharing、还是并发模型本身选错了？脑子里闪过一堆可能性，每一条都够排查半小时。
如果有一个 Go语言的并发专家和性能专家在身边多好。
还有，对于有经验的老Go程序员，已经习惯了历史的Go语法和代码，对于新的特性反而没有新手更了解，如何保持与时俱进而不被新人所唾弃？
现在，这个愿望变成了现实：三个skill = 顶级有活力的Go语言专家。
做 Go 开发这些年，我发现 Go 程序员面对的最棘手的问题，几乎都可以归为三类：
第一类：并发。 死锁、数据竞争、goroutine 泄漏、channel 关闭时机不对、WaitGroup 计数配不平、锁重入导致自死锁……你写过 Go，就一定被其中至少一个坑过。
你是否曾经有过这样的经历：
写了一篇 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 协议开源。它的核心思路是把代码审查从"逐文件扫描"升级为"按语义单元审查"。
CLIProxyAPI 是一个轻量级 AI API 代理服务器，核心功能是在 OpenAI Responses API 和 Chat Completions API 之间做双向格式转换。它使得仅支持 Responses API 的客户端（如 OpenAI Codex CLI）能够访问仅提供 Chat Completions API 的模型（DeepSeek、GLM、Kimi 等）。
1 | Codex CLI |
instructions → system message，input → messages）
Matt Pocock 大概是 TypeScript 社区里最广为人知的面孔之一了。他的 Total TypeScript 课程和 YouTube 频道帮无数开发者搞懂了类型系统。但最近他在 GitHub 上火起来的原因不太一样：他把自己日常使用的 AI Coding Agent 的 skills 集合开源了，仓库名叫 mattpocock/skills，短短时间就冲到 89K+ stars、7.8K forks，总安装量 140 万次。这些 skills 不是"帮我写个登录页"那种 prompt 模板，而是直接从他 .claude 目录里拿出来的、每天在用的一套工程化开发流程。
如果你用过 Claude Code、Codex 或 Cursor 这类 AI 编程 Agent，大概率经历过以下场景：你描述了一个需求，Agent 自信满满地生成了几百行代码，结果跑起来要么不是你想要的，要么拆东墙补西墙，修好一个 bug 引出三个新的。Pocock 认为这些失败不是 Agent 笨，而是你缺乏一套可靠的工程流程来驾驭它。他在这套 skills 里把传统软件工程中最硬核的那部分——需求对齐（alignment）、领域建模（domain modeling）、测试驱动开发（TDD）、架构治理——打包成了可复用的指令集，让 Agent 不再是一个只会写代码的工具，而是一个遵循工程纪律的协作者。
上手方式极其简单，体现了这个项目的实用主义哲学：一条命令 npx skills@latest add mattpocock/skills，选择你需要的 skills 和目标 Agent（支持 Claude Code、Codex、Cursor、Copilot、Windsurf 等主流工具），然后跑一次 /setup-matt-pocock-skills 做一次性配置（选 issue 追踪器、标签体系、文档路径），就全部就绪了。所有 skills 完全开源（MIT 协议），Pocock 在 README 里直接鼓励你"hack around with them, make them your own"——这不是一个需要你膜拜的权威框架，而是一套你可以随意拆解、修改、组合的零件箱。
Jesse Vincent（GitHub 上的 obra）是一个在开源社区深耕二十多年的开发者。他写过键盘固件（Keyboardio 的 Kaleidoscope）、做过邮件客户端（K9-Mail 的核心维护者）、如今在 Prime Radiant 专注于 Agent 开发工具。他在 2025 年 10 月发布了 Superpowers——一个面向 AI Coding Agent 的完整软件开发方法论，以 skills 集合的形式提供，短短时间就冲到 196K stars。
如果你看过我之前写的 mattpocock/skills 那篇文章，你大概已经理解了"skill 文件"这个概念——YAML frontmatter + Markdown 指令集，Agent 读取后按指令执行。mattpocock/skills 提供的是离散的工具（盘问、TDD、架构审查），你需要自己决定什么时候用什么。Superpowers 的思路完全不同：它是一套自动触发的完整开发流程，从你打开 Agent 说出需求的那一刻起，到代码合入主分支为止，每个阶段都有对应的 skill 接管，而且 skills 之间会自动串联。
Vincent 管它叫"让你的 Agent 拥有超能力"。读完你会发现这个比喻不算夸张——它本质上是用一套指令模板，把一个散漫的 Agent 变成了一个遵循完整工程纪律的协作者。
Superpowers 的工作流是自动串联的，你几乎不需要手动指定"下一步用什么 skill"。下面是七个阶段的完整链路：
这是整个方法论最反直觉的部分——Agent 在写任何代码之前，必须先输出设计文档并获得你的批准。哪怕你只是让它"加一个简单的 todo list"，它也必须走完完整的头脑风暴流程。
