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

2026 年 8 月 4 日，21:21。

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

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

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

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

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

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

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

它叫 Superpowers。

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 必要？任务进行中范围变化以后是否重新分级？

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

冰与火的战歌：Windows内核攻防实战高级班！从零到实战，融合AI与Windows内核攻防全技术栈，打造具备自动化能力的内核开发高手。