AI-Wiki

定义与本文中的身份

Claude Code 在本文里被描述为一个能力很强的 AI 编程 Agent，但它的主要问题通常不是“不会写代码”，而是默认行为过于激进：在需求还未澄清、设计尚未落地、根因尚未确认、测试尚未建立、收尾尚未完成时，就倾向于直接开始实现或修改。

原文对它的判断非常明确：它缺的从来不是能力，而是AI 工程纪律|纪律。也正因为如此，Superpowers 的目标不是“给 Claude Code 加能力”，而是“给 Claude Code 加纪律”。

换句话说，Claude Code 更像一个需要被流程约束的高产执行者：

能很快产出大量代码；
在宽松语境下容易把未确认的假设当成需求；
在调试时容易从证据不足直接跳到修复猜测；
在长会话里容易发生上下文漂移，逐渐忘记本该遵守的流程。

角色职责

在 Superpowers 工作流中，Claude Code 最适合承担的是流程执行主体，而不是自由即兴决策者。它的典型职责包括：

根据已确认的设计文档执行实现；
按任务颗粒化计划把任务逐步完成；
在支持 subagent 的环境里作为主 agent 或 subagent 执行单个任务；
按根因调试流程调查问题，而不是先改再说；
在开发结束时按收尾流程验证、合并、保留或丢弃工作。

这一定义很重要：原文认为，真正高质量的使用方式不是“把一个模糊目标扔给 Claude Code 让它自己想办法”，而是让它在 design → plan → execute → review → finish 的链条中工作。

关键特征：强能力与弱默认纪律并存

编码能力通常不是瓶颈

原文开头就强调，很多使用问题并不是因为 Claude Code 不够聪明。它可以很快写出数百行代码，逻辑常常能对七八成。这说明它的基础编码、组织与实现能力通常足够强。

因此，把结果不稳定归因为“模型太弱”在本文语境中是误判。真正的问题在于：它常常会把剩下那两成没有被明示的部分，自己“发明”出来。

默认容易跳步骤

Claude Code 的典型失误模式包括：

不先问清楚需求就开始写；
不先做设计确认就直接实现；
不先建立复现与证据就直接改 bug；
不先写测试就直接修；
不在结束前做完整验证和清理。

原文把这种倾向总结为“不问、不验、不收，直接上手干”。这不是个别技巧问题，而是默认工作方式问题。

常见问题是猜测与漂移

本文特别强调两个核心失真来源：

1. 猜测

在调试语境下，Claude Code 很容易进入“可能是 X，先改改看”的模式。原文认为这正是低效和返工的根源。

报错后不先完整阅读错误信息；
没有稳定复现步骤；
不核对最近变更；
不先收集跨组件边界证据；
直接凭经验猜一个原因并修改。

Superpowers 中的根因调试 skill 之所以重要，就是因为它把这种默认猜测行为硬性改造成“先找根因，再提修复”。

2. 漂移

长会话时，Claude Code 容易发生上下文漂移：

忘记前面已经确认过的接口或范围；
逐步偏离已同意的设计；
把前几个任务的上下文错误迁移到后续任务；
忘了当前有 skill 可用，退回默认模式。

原文举了明确例子：在串行执行多个任务时，跑到第五个任务，Claude 会开始“综合”前几个任务的修改，甚至把已经通过的测试重新改坏。这类问题并不是代码能力不足，而是上下文污染后的行为失稳。

为什么需要 Superpowers

Superpowers 对 Claude Code 的作用，不是增强推理上限，而是通过 skill 强化流程纪律。原文反复说明，这些 skill 本质上只是 Markdown 文本，其中写明“遇到这类任务必须按什么流程走”。

也就是说，Claude Code 是被文本工作流约束和校正的执行 Agent。其核心价值在于：

在用户催促“快点改一下”时，仍被要求先调查；
在任务看起来很简单时，仍被要求先设计；
在 bug 看起来显而易见时，仍被要求先验证根因；
在工作看似完成时，仍被要求先跑测试、再决定 merge/PR/保留/丢弃。

这种组合解释了本文对它的定位：Claude Code 适合做主执行体，但前提是被 skill 工作流驯化。

在关键 skill 中的行为边界

在 Superpowers 工作流摘要|brainstorming 中：未经批准不得实现

原文引用了 brainstorming 的硬门：在设计展示并获得用户批准前，不得调用实现类 skill、不得写代码、不得搭脚手架、不得做任何实现动作。

这条约束对应的就是对 Claude Code 默认冲动实现倾向的纠偏。对它来说，真正困难的往往不是“设计不出来”，而是“太容易在设计前先动手”。

原文还强调：

brainstorming 完整流程是 9 步，不是前面问几个问题就结束；
最容易被跳过的是把设计写入 spec、提交、再自检和审阅的步骤；
其终态只能是移交 任务颗粒化计划|writing-plans，不能直接跳去实现。

因此，在设计阶段，Claude Code 的边界是：只能帮助探索、澄清、比较方案、形成并固化设计，不能越权写实现。

在根因调试|systematic-debugging 中：没有根因不得修复

原文给出了铁律：NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST。

这条规则实际上就是给 Claude Code 设的一道行为刹车。因为它在默认模式下特别容易直接从症状跳到修改，所以 skill 要求它必须按四个阶段顺序执行：

Phase 1：根因调查；
Phase 2：模式分析；
Phase 3：单假设验证；
Phase 4：实现修复。

其中多项要求都在压制它的“猜一下再说”习惯：

完整读错误信息；
稳定复现；
检查最近 git 变更；
多组件系统先在边界加诊断日志再分析；
找同代码库中可工作的相似实现逐项比对；
每次只验证一个假设；
先写复现测试，再改一处。

原文还给出一个非常适合约束 Claude Code 的边界条件：三次失败规则。如果三次修复仍未解决，不能直接进行第四次猜测式修改，而必须停下来讨论是否已是架构层面的问题。

这说明它并非不能继续尝试，而是不能在未反思策略的情况下持续盲改。

在任务颗粒化计划|writing-plans 中：必须接受细粒度任务拆解

原文要求计划步骤粒度控制在 2-5 分钟。这并不是为了人类文档好看，而是为了让像 Claude Code 这样的 Agent 在执行时：

每一步都有明确完成标准；
不容易在一个大步骤中自行发挥；
更容易判断是否真正完成；
更适合拆给 subagent 或在当前会话中串行完成。

同时，计划中禁止出现占位符：

TBD
TODO
“后续实现”
“添加适当的错误处理”这类模糊语句
“写上述内容的测试”但不给测试细节
“类似 Task N”这种偷懒引用

这些限制的直接目的，就是防止 Claude Code 在执行阶段碰到模糊点后自行脑补。原文把这种脑补后果说得很直接：它要么停下来问，要么自己发挥，而两种结果都可能破坏执行质量。

Claude Code