当模型不断吸收过去需要人类教授的方法，人还需要向模型提供什么？

序章：21:21，我们删除了 17,712 行

2026 年 8 月 4 日，21:21。

一条名为“迁移至 2.0.0 无 Hook 八 Skill 架构”的提交进入了我们的仓库。129 个文件发生变化，新增 3,020 行，删除 17,712 行。

被删除的不是一个无人使用的实验分支，而是前一天还在修复、发布和验收的产品核心：Hook、Runtime、状态、门禁，以及一套判断任务应该走什么流程、什么时候可以结束的系统。

五天前，我们才刚刚开始做它。

最初，我们只是想让 AI 写出更容易维护的代码。后来，我们为它准备工程规范、测试要求和完成前验证；再后来，我们开始担心这些规则会被跳过，于是试图用模型之外的系统确保它真的执行。

整个过程看上去都很合理。直到系统越来越认真地执行我们的规则，也越来越频繁地妨碍最简单的任务。

我们最终删除的不是工程标准，而是那套试图替模型理解任务的控制系统。

但这个故事并不始于我们的插件。大约十个月前，另一套“教 AI 怎样写代码”的方法刚刚从一个人的工作流走向整个社区，并最终获得超过 26 万个 Star。

它叫 Superpowers。

第一章：从个人工作流到 26 万 Star

2025 年 10 月 9 日，Jesse Vincent 把 Superpowers 发布到了 GitHub。

不到十个月后，2026 年 8 月 6 日，它已经拥有 267,477 个 Star、23,902 个 Fork 和 1,015 名 Watcher。

这是一个相当夸张的数字。Superpowers 既不是模型，也不是 IDE，更不是一个能够直接生成应用的产品。它的主体是一组写给 Coding Agent 的 Skills，以及由这些 Skills 组成的软件开发方法。

超过 26 万人收藏的，是一套“AI 应该怎样工作”的答案。

先有工作流，后有插件

Superpowers 并不是从一份宏大的产品规划开始的。它首先是 Jesse 自己每天使用 Claude Code 的习惯。

发布前四天，他写了一篇文章，记录自己在 2025 年 9 月使用 Coding Agent 的方式：用 CLAUDE.md 保存规则；为不同任务建立独立 Worktree；写代码前先讨论问题；把设计拆成小段逐步确认；设计通过后再生成足够具体的实施计划；让不同 Claude 会话分别担任架构师和实现者；上下文变得混乱以后，清空会话重新开始。

这些做法并不陌生。真正重要的是，它们第一次被连成了一条可以重复执行的 Agent 工作流：先理解，再计划，最后实现。

当时，Jesse 仍要手动创建 Worktree、复制 Prompt、打开多个终端，并亲自在不同会话之间传递计划和 Review 结论。Superpowers 最初要解决的，就是把这套已经有效、却相当依赖使用者技巧的方法，变成 Agent 可以自己执行的系统。

四天后，Claude Code 发布了插件机制。Jesse 原本准备周末再整理项目，看到新的分发方式后，决定当天就把它公开。首个版本已经形成一条完整流水线：

Brainstorm → Plan → Implement → Review → Finish

Agent 不再收到需求后立即写代码。它会先澄清问题、形成设计，再建立隔离环境、拆分计划、交给独立 Agent 实现和审查，最后在真实验证之后询问用户如何处理分支。

Superpowers 最特别的地方，不是其中哪一条工程原则前所未见，而是它把工程经验变成了一组 Agent 可以发现、加载和组合的 Skills。

一套工作方法成为公共产品

发布第二天，Simon Willison 就推荐了 Superpowers。他称 Jesse 是自己认识的最有创造力的 Coding Agent 用户之一，特别提到了 TDD、分阶段计划和可以持续演化的记忆。

早期用户称赞的也不是“代码生成更快”，而是 Agent 更像一个可以协作的工程师：它会先问问题，会按计划推进，会查根因，会验证结果，也更少需要人在每一步提醒。

Superpowers 在 2025 年 10 月下旬达到约 1,000 Star。2026 年 1 月进入 Anthropic 官方 Claude 插件 Marketplace 后，增长开始明显加速：三天后跨过 1 万，3 月突破 10 万，8 月达到 267,477。

从 1 万到 10 万只用了约两个月。到这个阶段，Superpowers 已经不只是一个受欢迎的 Claude Code 插件，也成了 Agent Skills、Spec-driven Development 和工程 Harness 浪潮中最容易被理解的代表。

它后来又适配 Codex、Cursor、OpenCode、GitHub Copilot CLI、Kimi Code、Pi 等不同环境。模型和工具名称可以变化，但 Brainstorming、Planning、TDD、Debugging、Review 和 Verification 仍然能够以 Markdown Skill 的方式迁移。

在它之前，很多人保存的是一份越来越长的 CLAUDE.md，或者一组需要自己记住、自己粘贴的 Prompt。Superpowers 展示了另一种产品形态：个人的工程经验，可以像代码一样被命名、安装、测试、分享和迭代。

26 万 Star，是社区对这套工作方式最直观的一次投票。

第二章：它为什么是那个时代正确的答案

回到 Superpowers 发布的日期，会看到一个看似矛盾的事实。

十天前，Anthropic 刚刚发布 Claude Sonnet 4.5，并在 Claude Code 2.0 中将它设为默认模型。按照 Anthropic 当时的说法，它已经能在复杂、多步骤任务上持续工作很长时间；Claude Code 也拥有 Checkpoint、Subagent、Hook、后台任务和原生 VS Code 扩展。Sonnet 4.5与Claude Code 2.0描绘的，已经不是一个只会补全函数的 Chatbot。

同一时期，GPT-5-Codex、Claude Opus 4.1 和 Gemini CLI 也都在强调跨文件修改、测试、调试、重构与长任务。Agentic Coding 已经成为行业共同的方向。

既然模型已经这么强，为什么开发者恰恰在这时需要一套严格流程来教它写代码？

模型已经会写，问题是能否稳定完成

Benchmark 和长任务展示的是模型能力的上限。真实软件工程面对的却是另一件事：一个模糊需求能否被正确理解，一次局部修改能否尊重代码库历史，长对话中能否保持目标，几个都能工作的方案应该如何取舍，以及什么证据足以支持“已经完成”。

Jesse 的工作流正好展示了这段距离。

Claude 知道什么是 TDD，也知道 Bug 应该先定位根因。问题不在这些知识是否存在，而在它会不会在正确时间使用，会不会在“先给用户一个答案”的局部压力下跳过，会不会在上下文变长以后仍然坚持。

所以 Jesse 才需要把设计与实现放进不同会话，自己充当中间的项目经理；才需要把计划拆得足够小，定期清空上下文，并用一套强硬的 Bootstrap 提醒 Agent：只要存在相关 Skill，就应该先读取。

2025 年的前沿模型已经足够强，能够执行一整套复杂工程方法；它们又不够稳定，无法在没有外部组织的情况下始终选择并坚持这套方法。

Superpowers 正好存在于两者之间。

工具已经齐全，缺的是默认方法

Claude Code 早期有意保持低层和无固定主张。Anthropic 在最佳实践中建议用户先探索、再计划、再编码，也建议使用 CLAUDE.md、测试、Subagent 和验证；但产品并没有强制所有人采用同一种开发流程。

这是合理的。一个通用 Agent 必须适应不同代码库、团队和任务，不可能预设唯一的软件工程方法。

它也留下了一块空白：工具已经存在，如何编排工具仍然依赖用户。

Superpowers 没有发明 Brainstorming、TDD、Worktree、Debugging 或 Code Review。它真正做的，是把这些分散的方法连成一条有主张的默认路径：什么时候讨论，什么时候动手，谁实现，谁复审，测试顺序是什么，结束前需要什么证据。

Skill 和 Plugin 的出现又让这件事第一次容易传播。Skill 把程序性知识与组织上下文按需放进模型注意力；Plugin 则负责安装、更新和分发。2025 年 10 月 16 日，Anthropic 正式公开 Agent Skills 时，把它形容成给新员工准备的 Onboarding Guide。

Superpowers 把一个高级用户才能手工维持的工作方式，变成更多人可以安装的默认行为。

它是那个时刻相当正确的答案。

但每一套写进 Skill 的流程，也会把它诞生时对模型能力的判断一起封装进去。当模型继续变化，原来承担作用的结构并不会自动知道自己什么时候应该退出。

第三章：我们也做了一次相似的尝试

我们的故事始于一个约 1.5 万行的文件。

它由 AI 在持续修改中逐渐写成。这个数字是我们的项目亲历，不是一项关于模型的统计，也无法归因到某一个具体模型版本。但问题非常真实：文件职责已经失去边界，局部修改牵动整片代码，AI 还可以继续往里添加功能，人却越来越难以理解和维护。

我们想让这种事情更难发生。

2026 年 7 月 30 日，我们建立了一个团队 AI 开发规范仓库。最初的想法很简单：把团队认可的工程标准整理出来，让 Agent 知道一个文件不应该无限膨胀，行为变化需要测试，Bug 修复应该寻找根因，文档应该与代码一起更新，Git Commit、Push 和发布拥有不同的授权边界。

从表达标准，到确保标准被执行

很快，我们遇到了一个熟悉的问题：把规则写下来，不等于模型每次都会使用。

它可能没有完整读取 Skill，可能说自己已经验证，却引用了另一个 Worktree 的结果；文件变化以后，上一轮测试也可能已经过期。

于是问题从“团队想要什么”变成了“怎样确保模型每次都做到”。

我们先加入 Hook，再建立 Runtime、状态和门禁。后来，我们研究了 Superpowers，把其中已经成熟的需求澄清、系统化调试、Worktree 和完成前验证方法吸收进自己的产品。

这套设计有完整的工程逻辑：如果一个约束重要，就应该可以验证；如果证据会过期，就应该绑定当前差异；如果流程可能被跳过，就不应该只相信模型说“我做过了”。

它也确实解决了一些问题。测试和文档更难被悄悄省略，证据必须来自当前代码，Commit 前可以检查最终 Staged Tree，发布包也能够验证来源、版本和摘要。

问题出现在系统开始理解“任务是什么”的时候。

一个只读任务，为什么不能结束

有一次，用户只要求分析 SDK，没有要求修改代码。请求里却包含“修复”“功能”等词，系统把它识别成了工程场景。需求、质量、测试和完成验证开始累积；到了结束阶段，它又要求为这些流程提供通过证据。

早期系统只认识成功，却没有给“只读咨询”“没有实施”“用户取消”“测试失败”或“环境受阻”设计正常出口。

“不能声称成功”，最后被实现成了“不能结束任务”。

而且这个行为一度被测试保护。系统不是偶然坏掉，它只是在认真执行我们当时认为正确的规则。

随后，越来越多精力开始花在任务分类、命令识别、状态同步和宿主协议上。系统要判断一条 Shell 是读取、验证、写入还是几个动作的组合；要识别新的 App Tool、MCP 返回结构和间接执行；还要在用户授权、Agent 判断和自身门禁之间决定谁拥有最终权威。

我们原本想解决代码质量，后来却逐渐构造出了一套负责识别任务、选择流程、验证模型行为并决定任务能否结束的控制系统。

简单任务进入复杂流程，只是这个问题最容易看见的表面。

风险分级为什么没有解决问题

面对这种副作用，最直觉的办法是风险分级：简单任务走短流程，复杂任务进入完整治理。

但系统仍然需要先判断：这是咨询还是实现？一行修改是低风险，还是碰到了关键权限边界？哪些 Skill 必要？任务进行中范围变化以后是否重新分级？

如果由固定规则判断，它只能把丰富语境压缩成有限标签。如果最终仍然需要模型结合对话和代码库判断，那么分级系统就没有消除模型判断，只是在它前面增加了一套信息更少的判断。

我们逐渐意识到，问题不在风险等级分得不够细，而在于谁拥有任务语义的最终判断权。

2026 年 8 月 4 日 14:06，我们第一次在提交里明确写下：“将插件决策权交还 Codex Agent。”

几个小时后，那套控制系统被删除。

保留下来的八个 Skill 仍然要求关注需求、质量、测试、调试、文档、验证和 Git 安全。被删除的是另一层东西：Plugin 不再决定任务属于什么场景，不再要求内部回执，不再根据命令字符串判断证据是否充分，也不再阻止任务结束。

我们删除的是控制，不是标准。

但 Hook 消失以后，问题并没有完全消失。一项很小的修改，仍可能触发多份 Skill；固定在 Skill 里的 must，也可能继续把简单任务扩展成完整工程流程。

于是，问题从“要不要 Hook”继续向前移动：如果模型已经能够理解任务规模、选择工具并检查结果，Skill 还应该规定多少步骤？

哪些规则是在补偿模型，哪些是在表达团队仍然需要主动告诉它的选择？

第四章：当“怎样做”不再稀缺

Prompt 是一次任务里的意图与上下文，Skill 是可以反复调用的局部知识，Plugin 负责安装和分发，Harness 则是模型实际工作的整套环境。它们都会改变模型表现，却都不是智能本身。

时间已经开始给出一些答案。

2026 年，OpenAI 在一篇内部团队使用 Codex 的实践总结中写道，他们曾尝试维护一份巨大的 AGENTS.md，后来发现它挤占上下文、迅速过期，也让所有事情看起来同样重要。最终，他们保留一份短小地图，把知识放进可发现的仓库结构，让基础设施执行不变量，让 Agent 自己探索实现路径。

Anthropic 在长任务 Harness 设计中记录了更直接的变化：同一套系统从 Claude Opus 4.5 升级到 4.6 后，原本用于分解工作的 Sprint 结构开始成为限制。团队删除了这层脚手架，保留仍然有价值的 Planner 和 Evaluator。

模型升级没有让 Harness 消失，却移动了 Harness 中真正承重的位置。

同年，Anthropic 对约 40 万次 Claude Code 会话的研究也观察到一种清晰分工：用户作出约 70% 的规划决策，Claude 作出约 80% 的执行决策。这不是关于所有 Agent 的定律，却像一张正在显影的照片——人越来越多地决定做什么、什么算完成，模型越来越多地决定怎样实现。

什么正在过时

我们写进 Skill 的东西，大致可以分成两类。

第一类是能力补偿：提醒模型先规划、怎样拆分任务、使用什么测试方法、什么时候 Review、完成前依次执行哪些检查。这些原则通常没有错，但是否需要被写成固定步骤，会随着模型和 Agent Harness 改变。

第二类是意图表达：团队为什么反对职责无限膨胀的单文件，怎样权衡抽象与局部可读，什么时候兼容性高于结构整洁，哪些文档必须双语，哪些动作必须分别获得授权。

模型能力增强，会不断减少第一类内容的必要性，却不会自动产生第二类信息。

这并不意味着 Skill 已经失效。现有研究恰好给出了并不整齐的答案。

SkillsBench报告，经过人工整理、准确匹配的 Skill，让其基准平均通过率从 33.9% 提升到 50.5%；聚焦在不超过三个模块的 Skill，通常优于试图覆盖一切的大型 Skill。

但 SWE-Skills-Bench 对公开软件工程 Skill 的测试中，49 个 Skill 有 39 个没有提高通过率，平均提升只有 1.2%；有些任务结果没有改善，Token 开销却最高增加了 451%。另一项 More Skills, Worse Agents? 则报告，Skill 库扩展到 202 个后，错误选择和相互遮蔽让表现最多下降 21%。

这些仍是需要更多复现的研究，不能替所有模型和任务下结论。但它们共同说明：Skill 的有效性不是一个固定属性。它取决于是否提供了模型与环境尚未提供、与当前任务真正匹配的信息。

一旦“如果不提醒，模型就不会这样做”不再成立，能力补偿就会从保障变成重复；如果仍以强制形式存在，重复又可能变成干扰。

模型无法凭空知道什么

起初，我们把答案概括成“品味”。

黑色页面和白色页面都可以很好看，但我就是喜欢白色。我可能说不出完整理由。这不是因为黑色在客观上错误，而是因为在两个都成立的答案之间，我作出了选择。

游戏设计里，这种差别更明显。很多游戏集合了所有已经被证明“好玩”的机制，最后仍然没有意思；另一些作品看似违反传统，甚至破坏已有规则，却因此建立了新的游戏方式。

工程中也是如此。两个实现都能通过测试，一个团队愿意保留少量重复以维持局部可读，另一个团队更看重抽象一致；一个产品接受短期结构债务换取市场窗口，另一个宁愿推迟交付。

通用训练可以让模型理解这些取舍，却不能让它在没有信息时知道，这一次哪种选择属于我们。

不过，“模型永远学不会品味”仍然说得太满。只要品味留下选择、比较和反馈，其中相当一部分就可能被学习。2026 年的预印本 AI Can Learn Scientific Taste 使用 72 万组按领域和时间匹配的论文摘要对，从引用等共同体反馈中训练模型。作者报告，模型能够在他们定义的指标上学习一种共同体的“科学品味”。

这项研究对品味的定义主要落在长期影响和共同体评价上，新想法也没有经过真实实验验证。它不能证明模型已经掌握所有意义上的创造性品味，却足以修正一个过度绝对的判断：品味并不天然处在模型学习能力之外。

真正无法从通用能力中自动产生的，是更具体的东西：

• 这一次究竟要解决什么；
• 私有代码、组织历史与过去失败过什么；
• 这一次更重视速度、兼容、简洁还是创新；
• 多种偏好冲突时，谁拥有决定权；
• 模型是否被授权行动，以及谁承担结果。

模型可以学习品味的模式，却不能在没有任何新信息时，正当地替某个主体决定这一次究竟选择什么。

如果模型能力无限强

把问题推到极端，边界会看得更清楚。

假设模型拥有近乎无限的理解、创造和实现能力。它能写任何软件，生成任何设计，模拟每一种方案的结果，甚至比一个人更准确地预测他最后会选择什么。

那么人与人之间还剩下什么区别？

过去，我们常常通过一个人能做什么认识他。有人会编曲，有人会写程序，有人擅长经营公司。能力既是工具，也是身份。

但当执行能力逐渐成为公共基础设施，人的差异不会消失，只会向上迁移：他看见什么，他想要什么，他拒绝什么，他愿意为哪种结果承担代价，他把什么赋予意义。

“怎样做”越便宜，“为什么做”就越显眼。

无限强的模型也许能准确预测“你会选择白色”。但预测选择不等于拥有选择，更不等于获得授权。即使一个人决定让模型完全代理自己的品味，“让模型替我选择”本身仍然是一次更高层的选择。

无论模型多强，一个具体系统仍然需要知道：它为谁行动，谁的偏好优先，谁授权它采取行动，以及谁承担结果。

未来的 Skill 应该是什么

过去的 Skill 常常围绕动作编写：先问几个问题，必须怎样分解，调用哪个工具，完成前依次执行哪些检查。

未来更有价值的 Skill，可能围绕判断编写：我们为什么在意这件事，什么结果不可接受，几个都正确的方案中我们偏向哪一个，什么证据会改变这种偏好，以及什么时候这份 Skill 不应该被使用。

能够由测试、类型系统、Lint、Schema 和权限证明的边界，交给工具。需要结合任务与代码库判断的实现路径，交给模型。模型无法凭空知道的局部事实、团队选择和授权，仍然由人提供。

静态 SKILL.md 不一定会消失。它透明、可审查、可版本化，也能够跨模型迁移。但它可能逐渐只保留为入口：背后连接可检索的历史决策、正反示例、版本化领域事实、真实工具、权限系统、评估结果和持续更新的记忆。

模型能力越弱，Skill 越接近约束；模型能力越强，Skill 越应该成为引导。

尾声：所以，它过时了吗？

如果“Superpowers 这类插件”指的是，把一代模型尚不稳定的通用工程方法冻结成固定流水线，并默认让每个任务经过相同阶段，那么它从诞生之日起就带着保质期。模型、工具和宿主一旦吸收了其中的方法，重复的脚手架就可能从帮助变成摩擦。

但如果 Plugin 与 Skill 的作用，是把一个组织的局部知识、真实边界、品味、授权和意图交给通用模型，那么它们并没有过时。

恰恰相反，模型越通用，它越需要知道自己这一次正在为谁工作；实现能力越趋同，人与团队的差异越需要被表达。

Superpowers 的 26 万 Star，不是一次关于永恒方法的投票。它记录了一个历史阶段：人们第一次大规模意识到，模型能力之外，还需要一层可以安装和传播的工作方式。

它的成功不会因为其中一些工作方式开始过时而被否定。它完成了那个时代交给它的任务，又把下一道问题留给了我们。

过去的 Skill 主要记录模型不会做什么。未来的 Skill，更应该记录模型不可能凭空知道什么。

当 AI 不再需要我们教它如何写代码，它仍然需要知道：这一次，它为什么写，替谁写，什么样的答案才像我们。

而当模型越来越能够替我们找到答案，它也在迫使我们更认真地回答：

我们究竟想要什么？

资料说明

• 本文写于 2026 年 8 月 6 日。Star、Fork、Watcher 等实时数据来自 GitHub Repository API，查询时间为 2026 年 8 月 6 日 13:39（UTC+8）。1,000 与 10,000 Star 使用 GH Archive 的公开 WatchEvent 复核，历史净值可能因取消收藏等原因存在小幅差异。
• Superpowers 的起源与早期方法主要来自 Jesse Vincent 的同期工作流记录和发布文章。本文没有假定 Jesse 当时使用的具体模型。
• SkillsBench、SWE-Skills-Bench 与 AI Can Learn Scientific Taste 均为 2026 年研究或预印本，任务范围与结论边界不同。本文用它们呈现正在形成的证据，不把它们视为已经解决的科学结论。
• 本文不主张取消安全、合规、权限、不可逆操作或外部协议约束。能够由环境确定验证、违反后果明确的边界，仍应由工具和系统执行；本文质疑的是用外部弱观察替代模型对任务语义的判断。

传递专业知识、拓宽行业人脉——看雪讲师团队等你加入！！