"The decisive result came not from the model alone, but from the harness around it."
决定成败的不仅是模型本身，更是其配套的外围系统。

——Anthropic Harness Engineering Team

第 2 章讲了 Skills 系统——Matt Pocock 的工程哲学：一个 Markdown 文件定义一种行为，小而可组合。第 6 章讲了 superpowers——社区级 Skills 库，十四个 Skill 覆盖十四个场景。

Anthropic 自己为 Claude Code 开发了 13 个官方插件。截至 2026 年 5 月，全部放在 Claude Code 仓库的 plugins/ 目录下。和社区 Skills 不同，这些插件是 Anthropic 工程师为 Claude Code 构建的第一方工具——通过 /plugin 安装，深度集成到 hooks、agents、skills 三层基础设施中。

安装。 所有 13 个插件通过同一命令安装：

1

/plugin install code-review

/plugin install <name> 从 Anthropic 官方源拉取插件，注册斜杠命令、hooks 和 Agent。/plugin marketplace add 可添加第三方源。安装后插件在 ~/.claude/plugins/ 下，可手动编辑配置。

阅读全文

"Process over prose — workflows over reference."
流程重于文字，工作流重于参考。

——addyosmani/agent-skills README

第 15 章讲 Compound Engineering 让每一轮工作沉淀知识，下一轮起点更高。第 14 章讲 improve 让强模型做审计、弱模型做执行。两章都在回答"怎么让 Agent 做正确的事"。

本章要回答一个更前置的问题：Agent 知道什么是正确的事吗？

回答这个问题的人叫 Addy Osmani。

如果你写过前端，大概率读过他的书。他在 Google Chrome 领导开发者体验工程团队近 14 年，主导了 Chrome DevTools、Lighthouse、PageSpeed Insights、Core Web Vitals 等工具和标准的建设。2026 年转任 Google Cloud AI 总监，负责 Gemini、Vertex AI 和 Agent Development Kit。著有《Learning JavaScript Design Patterns》《Leading Effective Engineering Teams》，博客名篇《The Cost of JavaScript》从 2017 年到 2023 年持续更新了七年，几乎定义了 web 性能优化的讨论框架。他在前端工程和 web 性能领域的影响力，塑造了一整代前端开发者的工程实践。

2026 年初，他的注意力从"人怎么写更好的代码"转向了"AI 怎么写更好的代码"。2 月 15 日，他开源了 agent-skills，定位一句话："Production-grade engineering skills for AI coding agents"——把资深工程师的工作流、质量门禁和最佳实践，编码为 Agent 不可绕过的结构化约束。 到 6 月，近 60K star。

但这不只是又一个爆款开源项目。Osmani 在这个项目里做的事，和他过去十年做的事一模一样：把隐性的工程知识显式化。《Learning JavaScript Design Patterns》是把资深工程师脑子里的设计模式写成可学习的目录。Chrome DevTools 的文档是把调试技巧写成可操作的步骤。agent-skills 是把工程纪律写成 Agent 无法自我说服跳过的约束。

用 AI 写代码的人都会碰到一种熟悉的挫败感。Agent 接到任务，跳过规格直接敲代码。你说"先写测试"，它说"好的"，然后继续敲代码。你说"这里需要安全检查"，它说"明白"，然后加了一行 // TODO: add auth。你说"代码能简化一下吗"，它说"当然"，然后把三个函数合并成一个更长的函数。

Agent 不是不听话。它是真的不知道什么叫"先写测试""安全检查""简化代码"。这些是资深工程师花了好多年才内化的纪律，而 Agent 的默认行为是用最短路径把代码写出来，能跑就行。其他的都不在它的输出分布里。

agent-skills 要反转的就是这件事。它所有的设计决策，从七阶段生命周期到反合理化表到验证门禁，都指向同一个目标：让 Agent 像资深工程师一样工作。不是写代码更快，是不跳过那些让代码值得写的东西。

阅读全文

"Each unit of engineering work should make subsequent units easier — not harder."
每一个工程工作单元都应该让后续单元更容易，而不是更难。

——everyinc/compound-engineering-plugin README

第 14 章讲 improve 把计划当作产品，让强模型做判断、弱模型做执行。省了 token。但还有一个问题没回答：省下来的 token 和时间，有没有让你的下一次工作起点更高？

大部分 AI 编程工具解决的是"这一次"。帮你写代码，跑测试，合 PR。会话结束，上下文消失。下次开新会话，Agent 从零开始重新理解这个项目。构建命令是什么来着？那个奇怪的约定是因为什么历史事故？上次修那个 bug 踩了什么坑？全忘了。Agent 学到的东西，在你关掉终端的那一刻归零。

Compound Engineering 要反转的就是这件事。核心主张不是"让 Agent 这次做得更好"，是"让 Agent 下次起点更高"。每一轮工作结束时，把学到的东西沉淀回知识库，变成下一轮 Agent 启动时自动读到的上下文。用复利的方式做工程。

这个想法来自 Every 公司（Every.to），由 @kieranklaassen 和 @tmchow 维护。他们把这套方法论打包成 compound-engineering-plugin，MIT 开源，GitHub 18.3K+ star，随插件提供 37 个 skills 和 51 个 agents。支持的编码工具覆盖 Claude Code、Cursor、Codex、GitHub Copilot、Factory Droid、Qwen Code、OpenCode、Pi、Gemini、Kiro，几乎你能叫出名字的都在。

阅读全文

"The plan is the product."
计划才是产品。

——shadcn/improve README

shadcn 是谁，不用多介绍。他创建的 shadcn/ui 是 GitHub 上 Star 数最高的 React 组件库之一，11 万+，几乎凭一己之力改变了前端组件库的交付范式——不是"装一个 npm 包"，是"把源码拷进你的项目，你拥有它，你改它，你对它负责"。这种对控制权和所有权的执念，是他所有作品的设计 DNA。

2026 年 6 月，他在这个 DNA 上又加了一层——开源了一个叫 improve 的 Agent Skill。一周之内，5000+ star。

improve 做的事情，说穿了就是一句话：用最贵的模型读代码库、找问题、写执行计划，用最便宜的模型照着计划敲代码。它自己不碰源码，产出只有一种东西——计划。

这个分工背后是一笔所有用 AI 写代码的人都在付、但很少认真算过的账。用 Opus 读代码库、找 bug、排优先级，值。用 Opus 敲每一行代码、跑每一个测试、写每一句 commit message，不值。但现在的 AI 编程工具不管这些——你给它们什么模型，它们就全程用什么模型。预算好的团队手动切模型——研究阶段用 Opus，实现了切 Sonnet，跑测试了再切 Haiku。切来切去，时间都花在模型下拉菜单上了。

improve 把这个手动切换内建成了自动分工：强模型只负责判断。执行扔给最便宜的、够用的模型。

阅读全文

"Claude Code is powerful. GSD Core makes it reliable."
Claude Code 很强大。GSD Core 让它变得可靠。

——open-gsd/gsd-core README

第 12 章给了 Loop Engineering 一个很大的愿景：你不再提示 Agent，而是设计提示 Agent 的循环。但那一章停在原理层，讲的是五个原语加一个状态记忆。把这些原语落成一套能直接安装、有明确文件结构、带 67 个命令的工程系统，是另一回事。

GSD Core 就是这样一套系统。它不发明新的 Agent，也不取代 Claude Code，而是套在你已有的运行时上面，把讨论、规划、执行、验证、交付这五步，固化成每个里程碑都要重复一遍的流水线。它想回答的不是"Agent 能不能写代码"，这个早就不是问题了，而是一个更隐蔽的问题：为什么 Agent 在小任务上表现惊艳，一接手大项目就开始胡言乱语？

这个问题有名字，叫上下文腐化（Context Rot）。本章讲 GSD Core 怎么把对抗上下文腐化当成第一性原则，用阶段循环、子智能体、持久化工件这三样东西，把一个容易漂移的编码 Agent 变成靠得住的工程伙伴。

阅读全文

"You shouldn't be prompting coding agents anymore. You should be designing loops that prompt your agents."
你不应该再提示编码 Agent 了。你应该设计循环来提示你的 Agent。

——Peter Steinberger, 2026 年 6 月 7 日

第 10 章搭了 Agent 的运行环境——hooks、权限、沙箱、配置继承。第 11 章用 Kanban 管多个 Agent 的并行编排。但有一个更根本的问题还没回答：每次都是你在提示 Agent。你打字，它回话，你再打字。你不在，它就不动。

2026 年 6 月，两条推文把这个矛盾推到了台前。Peter Steinberger（OpenClaw 作者）的那句话在 48 小时内获得 220 万次浏览。几天后，Boris Cherny（Anthropic Claude Code 负责人）在 WorkOS 的 Acquired Unplugged 活动上说了几乎同样的话："I don't prompt Claude anymore. I have loops running that prompt Claude and figuring out what to do. My job is to write loops."

全网炸了。但没人说得清"loop"到底是什么。有人说是 Ralph Loop 的翻版，有人说是"戴了顶帽子的 cron job"，有人说"prompt engineering 已死"。一周之内，Reddit、Hacker News、X 上的讨论翻了几十页，最诚实的回答是 Matthew Berman 那句："Nobody knows but him and Boris."

Addy Osmani 随即发表了长文"Loop Engineering"，给了这个概念第一个完整的拆解。本章基于 Osmani 的框架，结合 Boris Cherny 的实践、Geoffrey Huntley 的 Ralph Loop 思想、以及 AlphaSignal 的四条件测试，回答三个问题：Loop Engineering 是什么？它和前十一章的方法论什么关系？你真的需要它吗？

阅读全文

"You don't write the code anymore. You move the cards."
你不写代码了。你移动卡片。

——leodavinci1, kanbots 作者

Skills 封装能力。Spec 写合约。Ralph Loop 循环到对。gstack 角色覆盖。Goal Workflow 流水线串联。autoresearch 全自动闭环。这些方法论解决的都是"一个 Agent 怎么做事"。

真实场景从来不是一个 Agent。是多个 Agent 同时跑在不同的 worktree 里，多张卡片分布在多块板子上，你不盯就没人在盯。

Kanban 管的就是这个局面。管 Agent。

阅读全文

"The decisive result came not from the model alone, but from the harness around it."
决定成败的不仅是模型本身，更是其配套的外围系统。

——Anthropic Harness Engineering Team

Skill 封装能力。Spec 写规格。Ralph Loop 自己跑到对。gstack 用角色覆盖质量。Goal Workflow 串成七步流水线。autoresearch 全自动从 Issue 到合入。

这些方法论都在 Claude Code 之上运行。但 Claude Code 自己怎么造出来的？它调工具、读文件、写代码、执行 Bash——每一步都可能出错、可能越权、可能陷入死循环。谁在管这些？

Harness Engineering 回答的就是这个问题。不是"怎么用 Agent"，是"怎么造 Agent"。本章拆开 Claude Code 的引擎盖，看它的 hooks、settings.json、权限模型、沙箱、可观测性怎么拼在一起，把一个大语言模型变成可安全交付的产品。

阅读全文

"小孩子才做选择题，成年人当然全都要"

——网络梗

前八章覆盖了七条路线。

Pocock Skills 拆能力。OpenSpec 写规格。Ralph Loop 自己循环到对。gstack 用角色覆盖质量。superpowers 让 Agent 替你选工具。autoresearch 一口气自动到合入。Goal Workflow 串成七步，每步等你说过。

每条路都能走通。真实项目从来不只走一条。Ralph Loop 做实现，谁来审查？gstack 走流程，需求从哪来？autoresearch 全自动跑，Issue 谁拆的？

贪吃蛇案例已经验证了这一点。第 5 章 gstack 走了七个 Sprint 阶段，手工推着走，约两小时。第 6 章 superpowers 后台监听关键词，你答了五个设计问题，约五分钟。第 7 章 autoresearch 你写了一个 Issue，约三分钟，然后等结果。第 8 章 Goal Workflow 每步确认一下，从 PRD 到上线，约八分钟。

同一个贪吃蛇，同一个产出，四种交互模式。

本章把七条路摊开，看它们怎么拼。

阅读全文

"你只需描述功能想法，剩下的交给工作流。"

——smallnest, Goal Workflow 作者, 2026 年 5月

三条路。gstack 覆盖从需求到交付，但你得手动驱动每个阶段。superpowers 覆盖从设计到代码，但止步于开发分支。autoresearch 覆盖从 Issue 到合入，但它假设 Issue 已经存在。每条路都只解了一段。

实际项目不是这样的。实际项目从一句"我想做一个东西"开始。然后你要搞清楚它是什么、设计它怎么做、拆成小块、逐块实现、审查代码、记录决策、最后合入上线。七个动作，缺一个就是断点。每个断点都是你手动接续的地方。

Goal Workflow 做的事就是把这些断点接上。不是做一个更强的 /goal 命令。是做一条流水线——七个斜杠命令，首尾相连，从 PRD 到上线。

阅读全文