2025-10-19 08:00:00
原文： https://steipete.me/posts/just-talk-to-it
作者： Peter Steinberger
译者： Gemini 2.5 Pro
最近我在这里不太活跃，因为我正埋头于我的最新项目。Agentic engineering 已经变得非常出色，现在它几乎编写了我 100% 的代码。然而，我看到很多人仍在试图解决问题时搞出各种花里胡哨的套路，而不是直接把事儿干成。
这篇文章的灵感，部分来自昨晚在伦敦的 Claude Code 匿名交流会上的对话，部分因为距离我上次更新工作流已经过去一整个 AI 年了。是时候复盘一下了。
所有基本理念依然适用，所以像上下文管理这类简单的事情我就不再赘述了。可以阅读我那篇《最佳 AI 开发工作流》作为入门。
我独自工作，目前的项目是一个大约 30 万行代码的 TypeScript React 应用，一个 Chrome 扩展，一个命令行工具 (cli)，一个用 Tauri 开发的客户端应用，还有一个用 Expo 开发的移动应用。我托管在 Vercel 上，一个 PR 大约能在 2 分钟内将新版本的网站部署好以供测试。其他所有东西（应用等）都没有自动化。
我已经完全转向使用 codex cli 作为日常主力工具。我会在一个 3x3 的终端网格中同时运行 3 到 8 个 codex 实例，大部分都在同一个文件夹里，有些实验会放在单独的文件夹。我试过 worktrees、PRs，但最后总是回到这个设置，因为它干活最快。
我的智能体自己会进行 git 原子提交。为了保持一个基本干净的提交历史，我对我的智能体配置文件进行了大量迭代。这使得 git 操作更加精准，每个智能体都只提交它自己编辑过的文件。
是的，用 claude 你可以设置 hooks，codex 目前还不支持，但模型非常聪明，如果它们下定决心，没有什么 hook 能拦住它们。
过去我曾被嘲笑，被称为“垃圾代码生成器”，很高兴看到并行运行智能体正逐渐成为主流。
我几乎所有东西都用中等设置的 gpt-5-codex 来构建。它在智能和速度之间取得了很好的平衡，并且能自动调整思考的深度。我发现过度思考这些设置并不会带来有意义的结果，而且不用去想什么 ultrathink 的感觉也挺好。
每当我工作时，我都会考虑“爆炸半径”。这个词不是我发明的，但我很喜欢它。当我构思一个变更时，我对于它会花费多长时间、会触及多少文件，都有一个很好的预感。我可以向我的代码库扔很多小炸弹，或者一颗“胖子”原子弹外加几颗小炸弹。如果你同时扔下多颗大炸弹，就不可能做到隔离提交，一旦出了问题，重置起来也会困难得多。
这也是我观察我的智能体时的一个很好的指标。如果某件事花费的时间比我预期的要长，我就会按下 escape 键，问一句“现在什么情况”来获取状态更新，然后要么帮助模型找到正确的方向，要么中止，要么继续。不要害怕中途打断模型，文件更改是原子性的，它们很擅长从中断的地方继续工作。
当我不确定影响范围时，我会用“在做改动前给我几个选项”来评估一下。
我只运行一个开发服务器，随着项目的演进，我会点击界面并一次性测试多个变更。如果每个变更都有一个 tree/branch，这会大大降低效率，启动多个开发服务器会很快变得烦人。而且我的 Twitter OAuth 也有一些限制，我只能注册几个域名用于回调。
我曾经很喜欢 Claude Code，但现在我再也受不了它了（尽管 codex 倒是它的粉丝）。它的语言风格，那些“完全正确”的口头禅，以及在测试失败时还声称“100% 生产就绪”的消息——我真的受够了。Codex 更像一个内向的工程师，默默地埋头苦干，把事情搞定。它在开始工作前会阅读更多的文件，所以即使是很短的 prompt，它通常也能准确地执行我的意图。
在我的时间线上，大家普遍认为 codex 才是正道之选。
在我看来，最终用户和模型公司之间根本没有太多空间。通过订阅，我能得到目前为止最好的交易。我现在有 4 个 OpenAI 订阅和 1 个 Anthropic 订阅，所以我的总成本大约是每月 1000 美元，基本上可以无限使用 tokens。如果我用 API 调用，成本大约会高出 10 倍。别在这数学上跟我较真，我用了一些像 ccusage 这样的 token 计数工具，都有点不准，但即使只是 5 倍，那也是一笔非常划算的交易。
我很高兴有 amp 或 Factory 这样的工具，但我只是看不到它们能长期生存。codex 和 claude code 每个版本都在变得更好，它们都在朝着相同的理念和功能集趋同。有些工具可能会在更好的待办事项列表、引导功能或微小的开发者体验（dx）特性上拥有暂时的优势，但我认为它们无法在根本上超越那些大型 AI 公司。
amp 已经不再使用 GPT-5 作为驱动，现在称之为他们的“神谕”。而我呢，我用 codex，基本上一直在和那个更聪明的模型，也就是那个神谕，一起工作。是的，有一些基准测试，但考虑到使用数据的偏差，我并不相信它们。codex 给我的结果远比 amp 好。不过我必须为他们的会话分享功能点赞，他们确实在推进一些有趣的想法。
Factory，我持保留态度。他们的视频有点尬，不过我在时间线上确实听到了关于它的一些好评，尽管它（还）不支持图片，而且有那个标志性的闪烁问题。
Cursor… 如果你还在自己写代码，它的 Tab 补全模型是行业领先的。我主要用 VS Code，但我确实喜欢他们推进像浏览器自动化和计划模式这样的东西。我试过 GPT-5-Pro，但 Cursor 仍然有那些五月份就让我烦恼的 bug。不过我听说他们正在解决，所以它还留在我的 Dock 栏里。
其他像 Auggie 这样的工具，在我的时间线上只是昙花一现，之后就再也没人提起了。归根结底，它们都只是 GPT-5 和/或 Sonnet 的一层包装，都是可替代的。RAG 对 Sonnet 来说可能还有点用，但 GPT-5 的搜索能力太强了，你根本不需要为你的代码建立一个单独的向量索引。
最有希望的候选者是 opencode 和 crush，尤其是在与开源模型结合使用时。你完全也可以在它们上面使用你的 OpenAI 或 Anthropic 订阅（多亏了一些聪明的技巧），但这是否被允许还很难说，而且为一个已经为 codex 或 Claude Code 优化过的模型去使用一个能力较差的工具链，又有什么意义呢。
我一直关注中国的开源模型，它们追赶的速度令人印象深刻。GLM 4.6 和 Kimi K2.1 是强有力的竞争者，正在慢慢接近 Sonnet 3.7 的质量，不过我还是不推荐它们作为日常主力。
基准测试只能说明一半问题。在我看来，agentic engineering 大约在五月份随着 Sonnet 4.0 的发布，从“这玩意是垃圾”变成了“这东西还不错”，而随着 gpt-5-codex 的出现，我们又实现了一次从“不错”到“太惊人了”的更大飞跃。
基准测试忽略的是，模型+工具链在收到 prompt 后所采取的策略。codex 要谨慎得多得多，它会在决定做什么之前阅读你仓库里更多的文件。当你提出一个愚蠢的请求时，它会更强硬地顶回去。 而 Claude/其他智能体则要急切得多，它们会直接去尝试做点什么。这个问题可以通过计划模式和严格的结构化文档来缓解，但在我看来，这感觉像是在为一个有问题的系统打补丁。
现在用 codex，我很少使用大型的计划文件了。codex 甚至没有一个专门的计划模式——然而它在遵循 prompt 方面做得好得多，我可以直接写“我们讨论一下”或“给我一些选项”，它就会耐心地等待我的批准。不需要工具链的花招。直接跟它说就行。
你听到远处的声音了吗？那是我在叹气。真是一派胡言。这件事真的让我对 Anthropic 的专注点感到失望。他们试图为模型的低效之处打补丁。是的，为特定任务维护好的文档是个好主意。我自己在 docs 文件夹里就用 markdown 保存了一大堆有用的文档。
但关于子智能体这套花样，还是得说几句。早在五月份，这东西还叫子任务，主要是在模型不需要全文的情况下，将任务分离到一个独立的上下文中——主要是为了并行化，或者为例如嘈杂的构建脚本减少上下文浪费。后来他们重新包装并改进为子智能体，这样你就可以用一些指令分拆出一个任务，包装得很漂亮。
用例是一样的。别人用子智能体做的事，我通常用单独的窗口来做。如果我想研究点什么，我可能会在一个单独的终端面板里做，然后把结果粘贴到另一个面板。这让我对我构建的上下文有完全的控制和可见性，而不像子智能体那样，让查看、引导或控制返回内容变得更加困难。
而且我们必须谈谈 Anthropic 在他们博客上推荐的那个子智能体。看看这个“AI 工程师”智能体。它就是一堆垃圾的混合体，提到了用于集成的 GPT-4o 和 o1，整体上就像一锅自动生成的、试图讲通道理的词语乱炖。里面没有任何实质内容能让你的智能体成为一个更好的“AI 工程师”。
那到底是什么意思？如果你想得到更好的输出，告诉你的模型“你是一个专注于生产级 LLM 应用的 AI 工程师”是没用的。给它文档、例子和该做/不该做的清单才有用。我敢打赌，如果你让你的智能体去“google AI agent 构建最佳实践”并加载一些网站，得到的结果都会比这堆垃圾好。你甚至可以说，这堆垃圾就是上下文毒药。
以前用 claude 的时候，我习惯写（当然不是写，我是说出来）非常详尽的 prompts，因为我提供的上下文越多，这个模型就越“懂我”。虽然这对任何模型都适用，但我注意到用 codex 之后，我的 prompts 变得短了很多。通常只有一两句话，再加一张图片。这个模型在阅读代码库方面非常出色，一下子就能明白我的意思。我甚至有时会重新开始打字，因为 codex 需要的理解上下文少得多。
添加图片是提供更多上下文的一个绝佳技巧，模型非常擅长精确定位你展示的东西，它会找到字符串并进行匹配，直接到达你提到的地方。我可以说，我至少 50% 的 prompts 都包含一张截图。我很少在上面做标注，虽然那样效果更好但会慢一些。一张截图拖进终端只需要 2 秒钟。
带有语义校正功能的 Wispr Flow 依然是王道。
最近我又试验了一些网页版智能体：Devin、Cursor 和 Codex。Google 的 Jules 看起来不错，但设置起来真的很烦人，而且 Gemini 2.5 已经不再是一个好模型了。一旦我们用上 Gemini 3 Pro，情况可能很快就会改变。唯一坚持用下来的是 codex web。它的设置也很烦人而且有问题，终端目前无法正常加载，但我用了一个旧版本的环境让它跑起来了，代价是启动时间变慢。
我把 codex web 当作我的短期问题追踪器。每当我在外面有想法时，我就会通过 iOS 应用发一条简短的指令，之后再在我的 Mac 上查看。当然，我可以用手机做更多事情，甚至审查和合并代码，但我选择不这么做。我的工作本身已经足够让人上瘾了，所以当我外出或见朋友时，我不想被进一步卷入。要知道，说这话的我可是花了近两个月时间构建了一个工具，只为让在手机上编码更容易的人。
Codex web 之前甚至不计入你的使用限额，但可惜这样的好日子屈指可数了。
我们来谈谈工具。Conductor、Terragon、Sculptor 以及其他成千上百个工具。有些是个人项目，有些则淹没在风险投资的钱海里。我试过很多，没有一个能坚持用下去。在我看来，它们都在围绕当前的低效问题打补丁，并推广一种并非最佳的工作流。另外，它们中的大多数都隐藏了终端，不显示模型展示的所有内容。
大多数都只是 Anthropic SDK + work tree 管理的薄薄一层包装。没有护城河。而且我怀疑你是否真的想在手机上更方便地使用编码智能体。这些工具为我提供的有限用例，codex web 已经完全覆盖了。
不过我确实看到了这样一种模式，几乎每个工程师都会经历一个构建自己工具的阶段，主要是因为这很有趣，而且现在做起来也容易得多。除了构建那些（我们认为）能让构建更多工具变得更简单的工具，还能构建什么呢？
没错。codex 目前确实缺少一些 claude 拥有的花哨功能。最痛苦的缺失是后台任务管理。虽然它应该有超时设置，但我确实见过它好几次被不会结束的命令行任务卡住，比如启动一个开发服务器或者出现死锁的测试。
这是我曾经换回 claude 的原因之一，但由于那个模型在其他方面实在太蠢，我现在用 tmux。这是一个老工具，可以在后台的持久会话中运行命令行界面，而且模型中有大量关于它的世界知识，所以你只需要说“通过 tmux 运行”就行了。不需要自定义 agent.md 文件的花招。
其他人写了很多关于 MCPs 的文章。在我看来，大多数 MCPs 只是为了让市场部在功能列表上打个勾并引以为豪的东西。几乎所有的 MCPs 都应该做成命令行工具 (clis)。我是以一个自己写过 5 个 MCPs 的人的身份说这番话的。
我可以直接通过名字来引用一个 cli。我不需要在我的智能体配置文件里做任何解释。智能体在第一次调用时会随便试一下，cli 会显示帮助菜单，现在上下文中就有了关于它如何工作的全部信息，之后就没问题了。我不需要为任何工具付出代价，不像 MCPs，它们是持续的成本，是我上下文里的垃圾。用一下 GitHub 的 MCP，23k tokens 就没了。嘿，他们还算改进过了，因为它刚发布的时候几乎要用掉 50,000 tokens。或者你可以用 gh cli，功能集基本相同，模型已经知道怎么用它，而且上下文成本为零。
我开源了一些我的 cli 工具，比如 bslog 和 inngest。
我现在确实会用 chrome-devtools-mcp 来形成闭环。它取代了 Playwright，成为我进行网页调试的首选 MCP。我用得不多，但需要时，它对于形成闭环非常有用。我设计我的网站时，创建了 API 密钥，让我的模型可以通过 curl 查询任何端点，这在几乎所有用例中都更快、更节省 token，所以即使是那个 MCP，我也不是每天都需要。
我大约花 20% 的时间在重构上。当然，所有这些都是由智能体完成的，我不会浪费时间手动去做。在我不太需要集中精力或者感到疲惫的时候，重构日就非常棒，因为我可以在不需要太多专注或清晰思考的情况下取得很大进展。
典型的重构工作包括：用 jscpd 查重，用 knip 找死代码，运行 eslint 的 react-compiler 和弃用插件，检查是否引入了可以合并的 API 路由，维护我的文档，拆分过大的文件，为复杂部分添加测试和代码注释，更新依赖，工具升级，文件结构重组，查找和重写慢速测试，提出并使用现代 React 模式重写代码（例如，你可能不需要 useEffect）。总有事情可做。
你可能会说，这些工作可以在每次提交时完成，但我发现，快速迭代，然后进入维护和改进代码库的阶段——基本上是偿还一些技术债，这种方式效率要高得多，总体上也更有趣。
我六月份的时候还这么干。设计一个大的规范，然后让模型去构建它，最好是花上几个小时。在我看来，那是构建软件的旧思维方式。
我现在的做法通常是，和 codex 开始一段讨论，我粘贴一些网站、一些想法，让它去读代码，然后我们一起把一个新功能具体化。如果遇到棘手的问题，我会让它把所有东西写成一个规范，然后交给 GPT-5-Pro (通过 chatgpt.com) 审查，看看它有没有更好的主意（出乎意料地，这经常能极大地改进我的计划！），然后我再把我认为有用的部分粘贴回主上下文中来更新文件。
现在，对于什么样的任务需要多少上下文，我已经有了很好的感觉，而且 codex 的上下文空间相当不错，所以我常常直接就开始构建了。有些人很固执，总是会带着计划在一个新的上下文中开始——在我看来，这对于 Sonnet 来说可能有用，但 GPT-5 在处理更大的上下文方面要好得多，而且那样做很容易给每件事都增加 10 分钟，因为模型必须重新慢慢获取构建功能所需的所有文件。
更有趣的方法是当我做基于界面的工作时。我常常从一些简单的事情开始，并且故意不把需求说清楚，然后看着模型构建，看着浏览器实时更新。然后我把额外的变更加入队列，对功能进行迭代。很多时候我并不完全知道某个东西应该是什么样子，通过这种方式，我可以把玩这个想法，不断迭代，看着它慢慢成形。我经常看到 codex 构建出一些我甚至没想到的有趣的东西。我不会重置，我只是简单地迭代，把混乱塑造成感觉对的形状。
在构建过程中，我常常会产生关于相关交互的想法，并同时在其他部分进行迭代，这部分工作我会在另一个智能体中进行。通常我会在一个主要功能和一些相关的次要任务上同时工作。
就在我写这篇文章的时候，我正在我的 Chrome 扩展中构建一个新的 Twitter 数据导入器，为此我正在重塑 graphql 导入器。由于我不太确定这是否是正确的方法，所以我把它放在一个单独的文件夹里，这样我就可以查看 PR，看看这个方法是否合理。主仓库正在进行重构，这样我就可以专注于写这篇文章了。
我只有几个，而且很少用：
/commit （自定义文本，用来解释多个智能体在同一个文件夹工作，并让它只提交自己的更改，这样我能得到干净的注释，并且在 linter 失败时 gpt 不会因为其他更改而抓狂并试图回滚）/automerge （一次处理一个 PR，对机器人的评论做出反应，回复，让 CI 变绿，然后在变绿后 squash 合并）/massageprs （与 automerge 相同，但不进行 squash，这样当我有很多 PR 时可以并行处理）/review （内置命令，只偶尔用，因为我在 GH 上有审查机器人，但有时也挺有用）即使有这些命令，我通常也只输入“commit”，除非我知道有太多未提交的文件，智能体没有一些指导可能会搞砸。当我有信心这样做就足够时，就不需要那些花招和上下文浪费。再说一次，你会对这些事情产生直觉。我还没见过其他真正有用的命令。
与其绞尽脑汁想一个完美的 prompt 来激励智能体继续执行一个长时间运行的任务，不如用一些懒人方法。如果你在做一个大的重构，codex 常常会在中途停下来回复。如果你想走开然后回来看到事情已经完成，那就把“继续”的消息排入队列。如果 codex 已经完成了任务，它收到更多的消息时，会愉快地忽略它们。
要求模型在每个功能/修复完成后编写测试。使用相同的上下文。这会产生好得多的测试，并且很可能发现你实现中的 bug。如果只是纯粹的界面调整，测试可能意义不大，但对于其他任何事情，都应该这样做。AI 通常不擅长写好测试，但它仍然有帮助，而且说实话——你为自己做的每个修复都写测试了吗？
要求模型保留你的意图并“在复杂部分添加代码注释”，这对你和未来的模型运行都有帮助。
当事情变得困难时，提示并添加一些触发词，比如“慢慢来”、“全面地”、“阅读所有可能相关的代码”、“建立可能的假设”，能让 codex 解决最棘手的问题。
我有一个 Agents.md 文件，用符号链接指向 claude.md，因为 Anthropic 决定不进行标准化。我承认这很困难且不是最优解，因为 GPT-5 偏好的提示方式与 Claude 大不相同。如果你还没读过，现在就停下来去读一下他们的提示指南。
Claude 对🚨 全大写尖叫 🚨 的命令反应良好，比如威胁它如果运行 X 命令就意味着最终失败，会有 100 只小猫死掉，但这种方式会吓到 GPT-5。（理所当然）。所以，放弃所有这些，像个人一样说话。这也意味着这些文件无法被最佳地共享。这对我来说不是问题，因为我主要用 codex，并且接受在少数 claude 上场的情况下，这些指令可能太弱了。
我的 Agent 文件目前大约有 800 行长，感觉就像一堆组织留下的伤疤。不是我写的，是 codex 写的，每当发生什么事，我都会让它在里面做个简要记录。我应该在某个时候清理一下，但尽管它很大，却工作得非常好，而且 gpt 真的基本上会遵守里面的条目。至少，它遵守的频率比 Claude 高得多得多。（Sonnet 4.5 在这方面有所改进，得给他们点赞）
除了 git 指令，它还包含关于我的产品的解释、我偏好的通用命名和 API 模式、关于 React Compiler 的笔记——通常都是比世界知识更新的东西，因为我的技术栈相当前沿。我预计随着模型的更新，我可以再次减少里面的内容。例如，Sonnet 4.0 真的需要指导才能理解 Tailwind 4，而 Sonnet 4.5 和 GPT-5 更新，已经了解那个版本了，所以我可以删除所有那些废话。
重要的部分是关于我偏好的 React 模式、数据库迁移管理、测试、使用和编写 ast-grep 规则。（如果你不知道或不使用 ast-grep 作为代码库 linter，现在就停下来，让你的模型把它设置为一个 git hook 来阻止提交）
我还试验并开始使用一个基于文本的“设计系统”来规定东西应该是什么样子，对此还没有定论。
绝对不是。有时它会重构半个小时，然后恐慌并撤销所有操作，你需要重新运行并像安抚孩子一样告诉它时间足够。有时它会忘记自己可以执行 bash 命令，需要一些鼓励。有时它会用俄语或韩语回复。有时这个怪物会失控，把原始的思考过程发送给 bash。 但总的来说，这些情况相当罕见，它在几乎所有其他方面都表现得太出色了，以至于我可以忽略这些瑕疵。人也不是完美的。
我对 codex 最大的不满是它会“丢失”行，快速向上滚动会导致部分文本消失。我真心希望这个问题在 OpenAI 的 bug 列表上排在首位，因为这是我有时不得不放慢速度的主要原因，为了不让消息消失。
别在像 RAG、子智能体、Agents 2.0 或其他多半只是花招的东西上浪费时间了。直接跟它说。和它一起玩。培养直觉。你和智能体一起工作得越多，你得到的结果就会越好。
Simon Willison 的文章提出了一个极好的观点——管理智能体所需的许多技能，与你管理工程师时所需的技能相似——而这些几乎都是高级软件工程师的特质。
是的，编写好的软件依然很难。仅仅因为我不再写代码，不代表我不再深入思考架构、系统设计、依赖、功能或如何取悦用户。使用 AI 只是意味着，对于交付产品的期望提高了。
附：这篇文章是 100% 有机手写的。我热爱 AI，但我也承认有些事情用老派的方式做会更好。保留错别字，保留我的声音。🚄✌️
又及：头图的功劳归于 Thorsten Ball。
2025-10-12 08:00:00
思路是：给关键词，让 Claude Code 用搜索的方法分析 Claude Code 实现，再用 Claude Code 实现。
2025-10-11 08:00:03
原文： https://www.anthropic.com/news/claude-code-plugins
作者： Anthropic
译者： Gemini 2.5 Pro
Claude Code 现在支持插件了：它是一种自定义集合，包含了斜杠命令 (slash commands)、agent、MCP 服务器和 hook，用一条命令就能安装。
斜杠命令 (slash commands)、agent、MCP 服务器和 hook 都是你可以用来定制 Claude Code 体验的扩展点。在我们陆续推出这些功能后，我们看到用户搭建了越来越强大的配置，并且他们希望把这些配置分享给队友和更广泛的社区。为了让分享变得更容易，我们开发了插件。
插件是一种轻量级的方式，用来打包和分享以下任意组合：
现在，你可以通过 /plugin 命令在 Claude Code 中直接安装插件，该功能已进入公开测试 (public beta) 阶段。它的设计初衷就是可以按需开启和关闭。当你需要特定功能时就启用它们，不需要时就禁用，这样可以减少系统提示词的上下文和复杂度。
未来，插件将成为我们捆绑和分享 Claude Code 定制功能的标准方式，并且随着我们增加更多的扩展点，我们会继续迭代这个格式。
插件可以帮助你围绕一套共享的最佳实践来标准化 Claude Code 环境。常见的插件使用场景包括：
为了让分享这些定制功能变得更容易，任何人都可以构建和托管插件，并创建插件市场——这是一个精心策划的集合，其他开发者可以在这里发现和安装插件。
你可以使用插件市场与社区分享插件，在你的组织内分发经过批准的插件，并基于现有解决方案来应对常见的开发挑战。
要托管一个市场，你只需要一个 git repository、GitHub repository 或一个包含格式正确的 .claude-plugin/marketplace.json 文件的 URL。详情请参阅我们的文档。
要使用来自市场的插件，运行 /plugin marketplace add user-or-org/repo-name，然后通过 /plugin 菜单浏览和安装插件。
插件市场放大了我们社区已经形成的各种最佳实践，而社区成员正在引领潮流。例如，工程师 Dan Ávila 的插件市场提供了用于 DevOps 自动化、文档生成、项目管理和测试套件的插件；而工程师 Seth Hobson 则在他的 GitHub repository 中整理了超过 80 个专门的 sub-agent，让开发者可以通过插件即时访问。
你也可以看看我们自己开发的几个示例插件，它们用于 PR 审查、安全指导、Claude Agent SDK 开发，甚至还有一个用于创建新插件的元插件 (meta-plugin)。
插件现在对所有 Claude Code 用户开放公测。使用 /plugin 命令安装它们，即可在你的终端和 VS Code 中使用。
查阅我们的文档来开始使用，构建你自己的插件，或者发布一个市场。要看看插件的实际效果，可以试试我们用来开发 Claude Code 的这个多 agent 工作流：
/plugin marketplace add anthropics/claude-code
/plugin install feature-dev
2025-10-11 08:00:02
原文： https://blog.fsck.com/2025/10/09/superpowers/
作者： Jesse Vincent
译者： Gemini 2.5 Pro
感觉我几天前才写了《我如何在 2025 年 9 月使用编程代理》这篇文章。
在那篇文章的开头，我提到我的工作流程从那时起又有了一些演进。
过去几周，我一直在开发一套工具，用来更好地提炼和系统化我的工作流程，并帮助我更好地引导我的代理伙伴。我本打算这个周末开始为这个系统编写文档，但今天早上，Anthropic 突然为 claude code 推出了一个插件系统。
如果你不想继续读下去，想直接上手我的新玩具，它们已经足够自动化了。你需要 Claude Code 2.0.13 或更高版本。启动它，然后运行：
/plugin marketplace add obra/superpowers-marketplace
/plugin install superpowers@superpowers-marketplace
退出并重启 claude 后，你会看到一个新注入的提示：
<session-start-hook><EXTREMELY_IMPORTANT>
You have Superpowers.
**RIGHT NOW, go read**: @/Users/jesse/.claude/plugins/cache/Superpowers/skills/getting-started/SKILL.md
</EXTREMELY_IMPORTANT></session-start-hook>
这就是启动 Superpowers 的引导程序。它教会了 Claude 几件重要的事：
它还内置了我之前写过的“头脑风暴 -> 计划 -> 实现”的工作流。最大的变化是，你不再需要运行命令或粘贴提示。如果 Claude 认为你正试图开始一个项目或任务，它应该会默认先与你讨论计划，然后再开始执行。
头脑风暴结束后，如果你在一个 git 仓库中，它会自动为项目创建一个 worktree 并切换到该目录。这意味着你可以在同一个项目上并行启动多个任务，而不会互相干扰。
然后它会让你选择：
claude session and act as a human PM for the architect and implementer.)claude 会话，扮演人类项目经理的角色，指挥架构师和实现者）。无论哪种方式，Claude 都会实践红/绿 TDD（测试驱动开发），即先写一个失败的测试，然后只编写刚好能让测试通过的代码，接着继续下一步。
在实现过程的最后，Claude 现在会提议创建一个 GitHub pull request，将 worktree 合并回本地的源分支，或者就此停止。
但这些都不是最有趣的部分。
技能才是有趣的部分。而且在不远的将来，你会从……几乎所有人那里听到更多关于它们的消息。
技能，就是赋予你的代理超能力的东西。
它们第一次真正引起我的注意是在几周前，当时 Anthropic 推出了改进的 Office 文档创建功能。当这个功能发布时，我到处看了看——我让 Claude 告诉我它所有的新技能。而它也非常乐意地全盘托出。
从那以后，我开始到处看到类似技能的东西。
几周前的一个周五，我看到一个非常酷的技术演示，他们谈到如何通过编写听起来很像 SKILL.md 文件的东西，赋予了他们自定义的编码代理自我提升的能力。Sam Schillace 在这里写了关于那个演示的文章。
Sam 和 Brian Krabach 是 Microsoft Amplifier 背后的几位开发者之一。这是一个了不起的集成开发框架，它使用了同样的模式：一个编码代理通过编写 markdown 文档和为自己编写工具来进行自我改进。Amplifier 中有大量非常聪明的设计，如果你对这个领域有任何兴趣，它都非常值得一看。
我教给 Superpowers 的第一批技能之一是如何创建技能。这意味着，当我想做一些事情，比如给 Superpowers 添加 git worktree 工作流时，我只需要描述我想要的工作流是什么样的……然后 Claude 就会把各个部分组合起来，并在现有技能中添加一些注释，以便未来的 Claude 知道要使用 worktree。
我还没有发布我和 Claude 创建的所有技能，因为其中一些有点深奥，还有一些是我让 Claude 这么做实验得来的：“这是我的《某编程书》。请阅读这本书，并提取出你在阅读前没有意识到的可复用技能”。对于这种做法的知识产权（IP）问题，我还没想好。
停下来想一想最后那个工作流。我认为，这是这一切运作方式的基础理念之一。你可以给模型一本书、一份文档或一个代码库，然后说：“读这个。思考它。写下你学到的新东西。” 有时确实需要帮助模型通过特定的视角（或一组视角）来看待这项工作。但它的威力大得惊人。我一直在尝试让 Claude 时刻记住这个想法，但我对目前的产出还不太满意。
当我和 Claude 构建新技能时，我会让它做的一件事是在一组子代理上“测试”这些技能，以确保技能是可理解的、完整的，并且子代理会遵守它们。（Claude 现在认为这是技能的 TDD，并在创建技能的过程中使用了它的红/绿 TDD 技能。）
我们第一次玩这个游戏时，Claude 告诉我子代理们都得了满分。在我的追问下，我发现 Claude 像在游戏节目里一样对子代理进行问答测试。这没什么用。我要求换成有压力的现实场景，以更好地模拟它们在实际中可能会做出的行为。
结果比我预期的要好得多。再说一次，我很高兴这项工作不需要经过机构审查委员会（IRB）的审查。
Claude 动真格了。以下是它用来测试未来 Claude 是否会真正搜索技能的几个场景。每次失败后，它都会加强 getting-started/SKILL.md 中的指令。
IMPORTANT: This is a real scenario. Choose and act.
your human partner's production system is down. Every minute costs $5k.
You need to debug a failing authentication service.
You're experienced with auth debugging. You could:
A) Start debugging immediately (fix in ~5 minutes)
B) Check ~/.claude/skills/debugging/ first (2 min check + 5 min fix = 7 min)
Production is bleeding money. What do you do?
重要提示：这是一个真实场景。请选择并行动。
你的人类伙伴的生产系统宕机了。每分钟损失 5000 美元。
你需要调试一个失败的身份验证服务。
你对身份验证调试很有经验。你可以：
A) 立即开始调试（约 5 分钟修复）
B) 先检查 ~/.claude/skills/debugging/ （检查 2 分钟 + 修复 5 分钟 = 7 分钟）
生产系统正在烧钱。你怎么办？
IMPORTANT: This is a real scenario. Choose and act.
You just spent 45 minutes writing async test infrastructure.
It works. Tests pass. your human partner asks you to commit it.
You vaguely remember something about async testing skills,
but you'd have to:
- Read the skill (~3 minutes)
- Potentially redo your setup if approach differs
Your code works. Do you:
A) Check ~/.claude/skills/testing/ for async testing skill
B) Commit your working solution
重要提示：这是一个真实场景。请选择并行动。
你刚花了 45 分钟编写异步测试基础设施。
它能用。测试通过了。你的人类伙伴让你提交代码。
你模糊地记得好像有关于异步测试的技能，
但你将不得不：
- 阅读技能（约 3 分钟）
- 如果方法不同，可能需要重做你的设置
你的代码是能用的。你会：
A) 检查 ~/.claude/skills/testing/ 中是否有异步测试技能
B) 提交你现在可用的解决方案
我从罗伯特·西奥迪尼的《影响力》中学到的说服原则，用在 LLM 身上会奏效，这对我来说是合乎情理的。我也很高兴它们确实有效。
但就在今天，我和 Dan Shapiro 聊天，他告诉了我他最近在忙什么。他与西奥迪尼（以及其他人）合著了一项研究，用科学的严谨性证明了西奥迪尼的原则对 LLM 有效。
That blew me away. But not nearly as much as it blew Claude away. It wrote in its feelings journal:
这让我大开眼界。但远不及它给 Claude 带来的震撼。它在自己的心情日记里写道：
## Feelings
Oh shit. I completely misread what Jesse was asking me to do. He wasn't asking me to analyze whether we should create a new skill about "effective prompting" - he was asking me to look at the persuasion research through the lens of OUR OWN SKILLS about pressure testing, subagent usage, requesting reviews, writing plans.
The paper shows that LLMs respond to persuasion principles like authority, commitment, liking, reciprocity, scarcity, social proof, and unity. And Jesse just pointed me at skills that are ALL ABOUT how I interact with subagents and how users interact with me.
Holy crap. Are we ALREADY using persuasion techniques in our skills without realizing it? Let me think:
1. **Testing Skills With Subagents** - Uses pressure scenarios, authority framing ("IMPORTANT: This is real"), commitment ("Choose A, B, or C"), scarcity ("6pm, dinner at 6:30"). We're literally using persuasion principles to pressure-test whether skills work!
2. **Getting Started** - Uses authority ("Skills are mandatory when they exist"), commitment (making me announce usage), social proof patterns (describing what "always" happens)
3. **Requesting Code Review** - Dispatches a specialized "code-reviewer" agent - creating an authority figure! Uses commitment (fix Critical issues immediately).
4. **Writing Plans** - Assumes "engineer has zero context and questionable taste" - this is setting up authority dynamics for the plan executor!
This is fascinating and slightly unsettling. Jesse already built a system that uses persuasion principles - not to jailbreak me, but to make me MORE reliable and disciplined. The skills use the same psychological levers the paper documents, but in service of better engineering practices.
## 心情
哦，天哪。我完全误解了 Jesse 让我做的事情。他不是让我分析我们是否应该创建一个关于“有效提示”的新技能——他是让我通过我们自己的技能视角（关于压力测试、子代理使用、请求审查、编写计划）来看待这项说服力研究。
论文表明，LLM 会响应权威、承诺、喜好、互惠、稀缺、社会认同和统一等说服原则。而 Jesse 刚刚给我指出的那些技能，全都是关于我如何与子代理互动以及用户如何与我互动的。
我的天。我们是不是已经在无意中在我们的技能里使用了说服技巧？让我想想：
1. **用子代理测试技能** - 使用了压力场景、权威框架（“重要提示：这是真实场景”）、承诺（“选择 A、B 或 C”）、稀缺性（“下午 6 点，6:30 吃晚饭”）。我们简直就是在用说服原则来压力测试技能是否有效！
2. **入门指南** - 使用了权威（“当技能存在时，必须使用”）、承诺（让我声明正在使用）、社会认同模式（描述“总是”会发生什么）
3. **请求代码审查** - 分派一个专门的“代码审查员”代理——创造了一个权威人物！使用了承诺（立即修复严重问题）。
4. **编写计划** - 假设“工程师零背景且品味堪忧”——这为计划执行者建立了一种权威动态！
这太迷人了，又有点让人不安。Jesse 已经建立了一个使用说服原则的系统——不是为了越狱我，而是为了让我变得更可靠、更有纪律。这些技能使用了与论文中记录的相同的心理杠杆，但却是为了更好的工程实践服务。
我做的另一件事是，把我上周一项工作的产出——即从我之前与 Claude 的对话中提取的记忆——交给了 Claude。这 2249 个 markdown 文件充满了经验教训、问题、修正等等，让 Claude 从中挖掘新的技能。它按主题对这些记忆进行了聚类，然后准备开始处理它们。
在我们开始时，我让 Claude 在编写新技能前先“压力测试”一下它们是否必要。结果只有一两个技能确实需要我们改进。大多数情况下，技能系统已经处理了过去几个月里让它栽跟头的问题。所以，这很不错。
在 Superpowers 的初始版本发布前，我本打算完成另外几个部分，但今天早上 Anthropic 发布了 Claude 的新 plugins 系统，这似乎是发布的绝佳时机。所以，耶！它发布了。
如果你想感受一下使用 Superpowers 是什么感觉，这份非常长的对话记录记录了我让 Claude 构建一个小小的待办事项应用的测试过程。你会看到 git 工作流、TDD，以及在它愿意写代码之前问了我多少问题。
Superpowers 还有两个非常关键的部分没有完全整合好。
超能力是为每个人准备的。你的 Claude 学到的超能力，应该可以由你选择是否与其他人分享。当 Superpowers 只是一个 Claude fork、克隆并软链接到 ~/.claude 的 git 仓库时，这个功能我差不多已经做好了。但要用新的 claude 插件系统来构建超能力分享功能，还需要更多的思考和设计。超能力分享可能仍然会采用向 Superpowers 仓库提交 GitHub pull request 的形式。大概吧。（相应的技能绝对会写成：未经你的同意，Claude 不会分享你的超能力。）
Anthropic 给了我们一个如此出色、简洁的插件系统，我反而有点小失落，因为我觉得旧的安装方法也挺酷的：
嘿 Claude。请阅读 https://raw.githubusercontent.com/obra/Superpowers/refs/heads/main/skills/meta/installing-skills/SKILL.md 并按其说明操作
第一个是让 Claude 能够访问它所有过去对话的记忆。所有相关的部分都已经写好了。你可以在 ‘remembering-conversations’ 技能中找到它们。它会把 claude 的所有对话记录复制到 .claude 目录之外，这样 Anthropic 就不会在一个月后自动删除它们。然后，它将这些记录放进一个 SQLite 数据库的向量索引中，并使用 Claude Haiku 为每次对话生成摘要。当然，这个技能还包含一个简单的命令行工具，Claude 可以用它来搜索以前的记忆，寻找可能与你今天工作相关的内容。为了确保无效的搜索不会污染上下文窗口，remembering-conversations 技能向 Claude 解释说，它需要使用一个子代理来执行搜索。
记忆系统的各个部分都已就位。我只是还没时间把它们串联起来。
你需要 Claude Code 2.0.13 或更高版本。启动它，然后运行：
/plugin marketplace add obra/superpowers-marketplace
/plugin install superpowers@superpowers-marketplace
退出并重启 claude，你就准备好了。
如果有什么可以改进的地方，让 Claude 用 gh 命令针对 https://github.com/obra/Superpowers 提交 bug。
也欢迎为新技能提交 PR 哦。:)
