编码代理的超级能力方法论

很多编码代理的问题不是“写得不够快”，而是启动得太早。用户说一句“帮我做个上传功能”，代理就直接开始生成路由、写接口、调样式；等你发现需求没对齐、边界没确认、测试也没想清楚，代码已经铺开了。返工成本越高，早期缺少结构化思考的代价就越明显。

这个技能的目标是给编码代理装上一套 Superpowers 方法论：在真正落笔写实现之前，先走一遍更像工程师的工作流程。它不是让代理多说几句话，而是把项目推进拆成几个可执行的前置阶段。

它解决什么问题

• 需求漂移：代理把模糊目标直接当成实现细节，做到一半才发现做的不是用户真正要的东西。
• 规格缺失：没有明确输入、输出、错误处理和验收条件，后续测试只能靠“看起来对”。
• 规划断层：一个改动同时碰数据库、API 和前端时，代理容易跳步，缺少可追踪的计划。
• TDD 缺位：实现先于测试生成，重构时没有安全网，回归问题很难在早期发现。
• 评审滞后：代码写完才暴露架构或一致性问题，修复成本远高于需求确认阶段。

它如何工作

技能在编码代理启动后就开始介入。当代理识别到用户在“构建某样东西”时，不会立刻冲进去写代码，而是先退一步澄清目标。这个动作本身就是一层防误判机制。

核心流程可以归纳为以下环节：

• Discovery 需求发现：确认真实目标、使用者、关键场景和约束，而不是急着拆解文件。
• Spec review 规格评审：把需求整理成明确的规格，检查边界、接口、数据流和验收标准。
• Planning 规划：将实现拆成可执行步骤，标明依赖、风险点和验证方式。
• TDD 测试驱动开发：先写失败测试或可验证条件，再写实现，避免“实现完再补测试”的倒挂。
• Subagents 子代理协作：把探索、实现或验证拆给子代理并行处理，适合信息收集、代码搜索和独立模块验证。
• Review loops 评审循环：在关键节点反复检查规格、计划和实现是否仍然一致，而不是只做一次总结。

这些步骤的价值在于可中断、可纠偏。用户在发现阶段说一句“其实我要的是批量上传”，比写完实现后重构便宜得多。代理在规格评审时提出一个问题，也比上线后修 bug 可控。

适用边界

它更适合需要完整研发链路的编码任务：需求不清、跨模块、涉及数据一致性，或有明显质量要求的项目。如果只是让代理“在 500 行文件里改一个变量名”，引入整套流程会显得过重。

另外，Superpowers 不会自动替用户做业务决策。它能帮助代理问出更专业的问题，但最终的产品方向、优先级和取舍仍需要人来确认。使用时也要保留对代理输出的审查，尤其是规格和测试部分——自动化流程可以减少遗漏，但不该替代工程判断。