当开发者将 Claude Code、OpenAI Codex 等编码 Agent 引入日常工作流时，最常见的困境并非 Agent 能力不足，而是人与 Agent 之间的协作模式始终难以建立。Matt Pocock 与 Jesse Vincent 分别从不同维度提出了解决方案：前者通过模块化技能模板实现工程实践的复用，后者通过完整方法论确保开发流程的系统性。两种思路的交汇处，正是当前 AI Agent 工程化的核心挑战与机遇。
意图对齐：从沟通断层到深度 “拷问”
人与 Agent 之间最根本的摩擦在于需求理解的错位。开发者常常发现，当自己描述完一个功能需求后，Agent 实现的成果与预期大相径庭。这种 “Agent 没有做我想做的事” 的失败模式，根源在于双方缺乏足够的需求澄清过程。mattpocock/skills 提供了两种针对性技能来解决这一问题：grill-me 用于非代码场景的需求挖掘，grill-with-docs 则在代码场景中增加了更多工程文档相关的辅助功能。这两项技能的核心理念是将需求澄清从一次性的对话环节，转变为结构化的 “拷问” 流程。Agent 会在动手之前反复追问细节，直到决策树上的每一个分支都被充分理解。这种方法直接呼应了《 Pragmatic Programmer》中的经典观点：“没人知道自己真正想要什么”，与其后期返工，不如在起点投入足够的设计精力。
grill-with-docs 的另一个关键特性是它会自动维护一份 CONTEXT.md 共享语言文档。Matt Pocock 在其个人项目 course-video-manager 中展示了一个典型案例：原本冗长的描述 “当课程章节内的某个课时被标记为正式发布（即在文件系统中获得位置）时存在问题” 被精炼为 “materialization cascade” 这个单一术语。这种共享语言的建立不仅减少了每次沟通的 token 消耗，更重要的是让 Agent 能够持续理解项目特有的领域概念，避免重复解释同一概念。obra/superpowers 则将这一理念进一步强化，其 brainstorming 技能会在 Agent 开始写代码之前，主动进入 Socratic 设计 refinement 阶段，通过提问探索替代方案，并以人类可消化的块状形式呈现设计文档供确认。
代码质量保障：TDD 与系统化调试的强制执行
即使需求已经对齐，Agent 产出的代码仍然可能存在质量问题。Matt Pocock 将此归因于反馈环路的缺失：Agent 缺乏对代码实际运行效果的持续感知，导致在不确定中盲目尝试。mattpocock/skills 中的 tdd 技能将测试驱动开发的 red-green-refactor 循环嵌入 Agent 的工作流程。Agent 首先编写一个失败的测试，观察其失败，然后编写最小化代码使其通过，最后进行重构。这种强制性的节奏确保了每一次代码变更都有明确的验证标准。类似地，diagnose 技能为复杂 Bug 和性能回归提供了一个结构化的诊断循环：复现问题、最小化问题场景、形成假设、添加调试 instrumentation、修复缺陷、回归测试。
obra/superpowers 在这方面的要求更为严格。其 test-driven-development 技能明确要求 Agent 在编写任何功能代码之前先写测试，并且会拒绝任何在测试之前编写的代码。这种强制性的 TDD 实践确保了代码从一开始就是可验证的。systematic-debugging 技能则提供了四阶段的根本原因分析流程，包括根因追踪、防御性编程和基于条件的等待技术。verification-before-completion 技能确保问题真正被修复，而不是被暂时掩盖。这些技能的共同特点是它们不是可选的建议，而是强制性的工作流程 ——Agent 在执行任何任务之前都会检查是否有相关的技能可以应用。
架构熵增对抗：从代码生成到持续设计
Agent 带来的另一个隐性风险是软件熵增的加速。由于 Agent 能够极大提升编码速度，代码库复杂度的增长速度也随之加快，开发者很快就会发现自己面对的是一个难以维护的 “泥球” 架构。mattpocock/skills 通过 improve-codebase-architecture 技能来解决这一挑战，该技能会分析代码库中模块深化的机会，并结合 CONTEXT.md 中的领域语言和 docs/adr/ 中的架构决策记录提供优化建议。zoom-out 技能则强制 Agent 在解释代码时提供系统级别的上下文，而非孤立的片段。to-prd 技能在创建产品需求文档之前，会先询问开发者将要修改哪些模块，确保设计决策与整体架构保持一致。
obra/superpowers 的工作流设计本身就体现了对架构的持续关注。其 writing-plans 技能要求 Agent 将工作分解为 2 到 5 分钟大小的可执行任务，每个任务都包含精确的文件路径、完整代码和验证步骤。这种程度的任务分解确保了实现过程始终在可控范围内进行。subagent-driven-development 技能则允许 Agent 派遣子 Agent 执行各个任务，并通过两阶段审查（规范合规性检查，然后代码质量检查）确保每个子任务的输出符合整体设计意图。finishing-a-development-branch 技能在任务完成后提供验证、合并 / PR / 保留 / 丢弃等选项，并自动清理工作树，确保开发分支不会成为遗留代码的温床。
工程化落地的关键参数与监控要点
将技能框架真正融入团队工作流需要关注几个关键的工程化参数。首先是技能触发机制的可靠性：mattpocock/skills 通过 npx skills@latest add mattpocock/skills 安装后，需要在 Agent 中运行 /setup-matt-pocock-skills 进行仓库级别的初始化配置，包括选择问题追踪器（GitHub、Linear 或本地文件）、定义 triage 标签词汇表、确定文档保存路径。建议每个仓库首次使用前都完成此初始化流程，避免后续技能因缺少配置而失效。其次是跨 Agent 兼容性：obra/superpowers 明确支持 Claude Code、OpenAI Codex、Cursor、OpenCode、GitHub Copilot CLI 和 Gemini CLI，但不同 Agent 的技能触发机制可能存在差异。部署时应验证目标 Agent 的技能自动触发是否正常工作，必要时可通过手动调用确保工作流执行。
监控层面建议关注三个核心指标：需求澄清轮次（grill-me/grill-with-docs 调用后的问题数量，过少说明 Agent 未充分挖掘需求）、TDD 循环完成率（tdd 技能执行时 red-green-refactor 三个阶段的完整度）、架构优化建议采纳率（improve-codebase-architecture 输出的建议中有多少被实际采纳）。这些指标可以帮助团队评估 Agent 工作流是否真正提升了代码质量，而非仅仅增加了流程复杂度。当指标显示 Agent 持续跳过某些技能或绕过强制性流程时，应检查技能配置或考虑升级到更严格的框架如 superpowers。
资料来源：本文主要参考 mattpocock/skills（https://github.com/mattpocock/skills）与 obra/superpowers（https://github.com/obra/superpowers）两个开源项目的官方文档。