做事方法论

解决什么问题

日常开发里有种很常见的状态：接到需求就开始写代码，遇到 bug 就动手试，改到测试通过就宣布完成。看起来一直在输出，实际上每一步都靠直觉驱动——不知道设计是否合理，不确定修复是否触及根因，声称“应该好了”时手里并没有证据。任务越复杂，这种模式的隐患越明显：测试是事后补的、修复是症状式的、完成是凭感觉的。

这套做事方法论要替换的就是这种“凭直觉忙活”的工作方式。它来自开源的 superpowers 技能体系，已适配 WorkBuddy：调用其他技能用 Skill 工具，需要并行或隔离执行时用 Agent 工具派发子代理。

核心机制

框架的核心理念是：先想清楚 → 用对的流程 → 证据说话 → 不过度设计（YAGNI）→ 小步提交。落到执行层，是四条不可妥协的铁律：

• 技能优先：只要任务有 1% 可能适用某个技能，就先调用它再做任何回应，包括反问、读文件、写码。流程型技能（设计、调试）优先于实现型技能。
• 先红后绿：写功能或修 bug 时，没有先写出失败测试，就不写生产代码；已经先写的代码一律删掉重来。
• 先根因后修：遇到 bug 或测试失败，没有完成根因调查就不提修复方案——症状式修复等同于失败。
• 证据先行：没有在当前消息里跑过验证命令，就不声称“完成/修好/通过”，should、probably、seems 这类表述一律不算数。

按任务类型路由

技能不会用一个固定流程套所有请求，而是按用户意图分流：说“做个 X”“加个功能”“改一下行为”走设计流程，禁止跳过设计直接写码；说“这 bug 修一下”“测试挂了”走调试流程，禁止瞎猜硬改；说“实现计划”“帮我执行”进入执行阶段；当用户在说“搞定了/通过了/修好了”前，会先过验证闸门。

此外还有一套通用红线：出现“这问题很简单，不用走流程”“先试着改 X 看看”“应该好了吧”“就这一次不 TDD/不验证”这类念头时，立即停止并回到流程起点。简单的问题同样有根因、同样有测试价值；一次只改一个变量，验证结果先看输出再说话。

适用边界

这套框架针对的是可拆解、可验证的开发任务，不适用于探索性原型、紧急线上止损等需要快速试错的场合——那时先止血、再复盘是更合理的做法。

阅读方式上建议按需加载：主文档掌握理念和铁律即可，落到设计、执行、调试、代码评审等具体阶段时，再读 references/ 下对应的详细步骤、模板与红线表，不要把全部内容一次性塞进上下文。