在智能体（Agent）系统从实验走向生产的进程中，一个核心挑战始终悬而未决：智能体如何稳定、可预测地执行工程实践？当模型的随机性遇上软件工程的确定性需求时，社区逐渐形成了一个共识 —— 需要一种机制将工程经验编码为可执行的技能规格。superpowers 框架（188k stars）与 mattpocock/skills 正是这一方向的代表性实践，它们分别从方法论完整性与工程实用性两个维度给出了答案。
技能框架的核心设计哲学
传统的智能体 prompt 工程面临三重困境。其一是对齐失效：模型对需求的理解与人类意图之间存在语义鸿沟，典型表现是 “做了但不是我要的”。其二是反馈迟滞：模型在缺乏即时反馈的情况下会持续沿错误方向迭代，造成 token 浪费与时间损耗。其三是熵增失控：随着对话轮次增加，代码库的复杂度以远超人工开发的速度增长，最终沦为无人敢动的技术债务。
superpowers 框架的回应是建立一套强制执行的工程纪律。该框架将软件开发流程拆解为七个强制触发阶段：brainstorming（头脑风暴）、using-git-worktrees（工作树隔离）、writing-plans（计划编写）、executing-plans/subagent-driven-development（计划执行或子智能体驱动开发）、test-driven-development（测试驱动开发）、requesting-code-review（代码评审请求）、finishing-a-development-branch（开发分支收尾）。关键在于，这七个阶段不是建议性的工作流提示，而是智能体在任何任务开始前必须检查并触发的技能。当智能体检测到相关上下文时，相应技能会自动激活，形成一种 “文档即代码、流程即执行” 的闭环。
mattpocock/skills 则采取了更为原子化的设计思路。该框架不追求完整的方法论覆盖，而是将工程实践分解为可独立使用、可自由组合的微技能。diagnose 技能封装了四阶段调试循环（复现→最小化→假设→验证），tdd 技能强制执行红 - 绿 - 重构循环，grill-with-docs 技能则通过苏格拉底式追问来对齐需求理解。每个技能都是自包含的，用户可以选择性地启用其中任何一个，无需接受完整的框架哲学。
可执行技能规格的内部结构
两个框架的技能文件均采用 Markdown 格式存储，后缀为 SKILL.md。这种选择并非偶然 ——Markdown 是人类可读的自然语言格式，也是大语言模型最熟悉的文档格式。当模型读取一个技能文件时，它实际上是在接收一组结构化的指令，这些指令明确指定了何时激活、在什么上下文中触发、执行哪些具体步骤、以及如何验证执行结果。
以 superpowers 的 test-driven-development 技能为例，其核心约束包括：必须先写失败的测试用例；必须验证测试确实失败；必须编写最小代码使测试通过；必须确认测试通过后才能提交；禁止在测试通过前编写任何功能代码。这些约束被编码为自然语言指令，但配合框架的执行机制，它们实际上成为了不可绕过的门控条件。模型在每个步骤后都需要显式声明验证结果，而非仅凭 “感觉” 继续推进。
mattpocock/skills 的 tdd 技能同样强调垂直切片（vertical slice）原则。每次迭代只实现一个功能路径的端到端测试与实现，而非横向铺开多个功能点。这种设计背后的工程逻辑是：小步验证可以获得更快的反馈循环，更快的反馈循环意味着更早发现问题，更早发现问题则大幅降低了修复成本。当智能体被约束为每次只推进一个切片时，过程的透明性与可回溯性也随之提升。
子智能体编排与并行执行机制
superpowers 框架中最具技术深度的设计是 subagent-driven-development（子智能体驱动开发）。在该模式下，主智能体在完成计划编写后，会将任务分发给多个独立的子智能体并行执行。每个子智能体获得精确的任务描述（包括具体文件路径、完整代码模板、验证步骤），在隔离的工作环境中完成任务后，主智能体负责审查其输出。
审查采用两阶段机制。第一阶段验证规格遵从性：子智能体的产出是否符合计划中定义的功能边界与技术约束。第二阶段评估代码质量：即使功能正确，代码是否存在命名不当、抽象缺失、重复逻辑等问题。只有通过第一阶段验证的产出才会进入第二阶段，而第二阶段发现的问题会阻断合并，主智能体需要指派同一子智能体或新智能体进行修复。
这种设计的工程价值在于它将 “智能体自主性” 与 “人工监督粒度” 进行了显式解耦。using-git-worktrees 技能为每个并行任务创建隔离的 Git 工作树，确保子智能体之间不会产生代码冲突，同时也为失败回滚提供了原子化边界。finishing-a-development-branch 技能则在任务完成后提供清晰的决策路径：合并到主分支、创建 Pull Request、保持分支待审、或直接丢弃，用户可以根据任务性质与质量评估结果选择后续动作。
共享语境与术语一致性
mattpocock/skills 中的 grill-with-docs 技能揭示了一个常被忽视的问题：智能体与人类之间存在隐式的词汇鸿沟。同一业务概念在不同对话中被不同表述（如 “课程章节下的课时变为已上线状态” vs “materialization cascade”），这种不一致会显著增加 token 消耗并降低输出质量。
该技能通过建立一个名为 CONTEXT.md 的共享语言文档来解决此问题。在需求澄清会话中，grill-with-docs 技能会引导用户与智能体共同提炼项目专属术语，并将其固化到文档中。此后，所有代码生成、文件命名、issue 描述都将引用同一套术语体系，智能体不再需要每次从对话历史中推断术语含义，用户也不再需要反复解释同一概念。
这种实践实际上借鉴了领域驱动设计（Domain-Driven Design）中的 “有界上下文” 与 “通用语言” 概念。当智能体被显式告知项目的领域词汇时，它能够在更少的 token 内表达更精确的含义，同时生成更高一致性的代码结构。值得注意的是，CONTEXT.md 的维护本身也是一个持续过程，grill-with-docs 技能会随着对话深入主动建议更新文档，确保共享语境与项目演进保持同步。
约束检查与工程纪律强制
两大框架的共同原则是 “系统性优于即兴”。这不仅是一句口号，而是通过具体的约束机制落地为可验证的行为模式。
在 superpowers 框架中，requesting-code-review 技能定义了一套预审清单。智能体在请求人工评审前必须自行完成清单检查，包括：是否所有计划任务均已实现、是否有未解决的编译错误、测试覆盖率是否符合预期、代码是否遵循项目编码规范。critical 级别的问题会阻断评审流程，智能体必须先自行修复这些问题，而非将问题推给人工评审。
mattpocock/skills 的 diagnose 技能则封装了系统性调试的方法论。面对一个 bug，智能体被要求首先尝试在本地环境中复现问题，然后通过二分查找或因果追踪最小化问题范围，接着基于最小化后的场景提出假设，最后通过针对性验证来确认假设并实施修复。这种结构化的调试流程能够有效避免 “盲目修改 - 运气验证 - 引入新 bug” 的恶性循环。
框架选型与工程场景适配
选择 superpowers 还是 mattpocock/skills，取决于团队对方法论完整性的需求程度。superpowers 提供了从需求澄清到分支收尾的端到端流程，适合希望建立标准化智能体开发规范的中大型团队。其子智能体编排机制对于需要并行处理多个独立任务的场景尤为有价值。但其代价是学习曲线较陡，团队需要接受并遵循其预设的工程哲学。
mattpocock/skills 则更适合追求灵活组合的开发者或小型团队。用户可以根据项目需求选择性采纳某些技能，而不必全盘接受某一方法论。其 caveman 技能（通过压缩沟通将 token 消耗降低约 75%）和 handoff 技能（将对话上下文压缩为可交接文档）对于成本敏感或多人协作场景具有实际价值。
两种框架的共同技术前提是：智能体需要足够的上下文边界来执行精确操作。当任务被分解为技能触发的条件、技能的内部执行步骤、以及步骤完成后的验证门控时，智能体的输出稳定性会显著提升。这种 “规格化约束” 而非 “自由发挥” 的设计理念，恰好是当前大语言模型在工程任务中最迫切需要的引导机制。
资料来源
- obra/superpowers: An agentic skills framework & software development methodology
- mattpocock/skills: Skills for Real Engineers
内容声明：本文无广告投放、无付费植入。
如有事实性问题，欢迎发送勘误至 i@hotdrydog.com。