深度使用 Superpowers 一段时间后，我的一些感受

刚开始用 Superpowers 的时候，我其实是把它当流程看的。

先 brainstorming，再写 spec，再写 plan，最后实现、验证。听起来很工程，也很正确。但老实说，刚开始我并没有特别强的体感。因为很多时候我只是想让 AI 快点帮我改完，尤其是那种看起来很小的需求：补个字段、改个状态、加个按钮、修一个接口返回。

真正用多了以后，我才感觉到，它改变的不是某一个步骤，而是我对 AI 写代码这件事的耐心。

以前我会更关心一句话：它能不能写出来？

现在我会先问另一个问题：它是不是已经看清楚要写的东西了？

这两个问题差别挺大。

AI 现在当然能写代码。很多场景下，它写得还很快，局部代码也挺像那么回事。麻烦的是，局部像对的，不代表放回系统里就是对的。

有些代码单独看没问题，编译也能过，甚至 review 时也能解释得通。但只要放回真实链路里，就会发现它绕开了某个旧逻辑，误解了某个状态，或者把一个只用于展示的字段当成了真正的执行状态。

这种问题最容易让人放松警惕，因为它不是一眼就错。

它是那种“每一块都能讲通，但整体方向偏了”的错。

我现在会先让它停一下

以前拿到需求，我经常直接让 AI 开始搜代码、改文件。

后来我发现，越是看起来小的需求，越容易在这里出问题。

比如只是改一个任务状态。你以为就是枚举和页面文案，结果后面还有定时任务在扫这个状态，有 SSE 在推这个状态，有 Redis 缓存了一份，还有前端根据它决定按钮能不能点。

这种时候，如果一开始就让 AI 写，它通常也能写。但它写的是它理解里的那个需求，不一定是真实系统里的那个需求。

所以我现在经常先丢一句：

先不要写代码，先把这条链路看清楚。
入口在哪，状态在哪落库，谁会读，有没有缓存、任务调度、回调或者前端依赖。

这句话表面上是在管 AI，其实也是在管我自己。

因为我也会急。看到需求的时候，我脑子里也会马上出现一个实现方案。AI 的速度会放大这种冲动。它一旦开始改文件，你就会觉得事情在推进。

但很多返工就是这么来的。

我不再假设自己已经讲清楚了

用VIbe Coding久了，我越来越不相信“我已经说清楚了”这件事。

不是说表达能力的问题，而是很多需求本来就不是一开始能说完整的。

有些东西我很确定。比如我要改哪个接口，页面上要多展示一个字段，失败时要返回错误原因。

有些东西我知道自己还没想清楚。比如失败后要不要重试，部分成功算不算成功，历史数据要不要补偿。

还有一些更麻烦。我没写出来，但看到方案时会立刻知道不对。比如 AI 给我设计了一个很完整的任务中心，我才意识到这个需求其实只需要一个同步接口；它给我抽了一个通用能力，我才意识到我真正想要的是沿用现有 service，不要扩大影响范围。

最危险的是最后一种：我根本没意识到的问题。

它通常藏在老代码里。一个字段为什么这么命名，一个状态为什么不能合并，一个 service 为什么不能直接复用，可能都有历史原因。你不读到那一层，就不会知道它存在。

所以我现在会主动让 AI 问我问题，而且不是泛泛地问“还有什么需求吗”。

我会这样说：

只问会改变实现方式的问题，一个一个问。不要问文案、命名这种后面能改的小问题。

这个提示很有用。

它问出来的通常不是细枝末节，而是会直接改变代码落点的问题：

这个字段是实际状态，还是页面展示状态？
这个开关是策略，还是当前事实？
失败后是重试，还是进入人工处理？
手动触发和自动调度要不要共用一条链路？
取消任务只是改数据库状态，还是必须通知 runtime 停止？

这些问题如果在实现前问出来，只是讨论几分钟。

如果在实现后才发现答错了，就是返工。

说不清楚的时候，我现在直接给源码

还有一类情况，我以前会写很长的 prompt。

比如我想说：“这个重试策略要和之前那个上传任务一样。”
或者：“这个状态流转不要重新设计，参考归档恢复那边的做法。”
再或者：“这个按钮的交互和另一个页面保持一致。”

这种话看起来清楚，其实很容易被误解。

“一样”到底是哪种一样？是接口风格一样，异常处理一样，状态语义一样，还是用户体验一样？

后来我就不太硬解释了。能给参考就给参考，尤其是源码。

我会直接让 AI 去读：

先看这个模块，重点看它怎么做状态流转、失败处理和日志记录。
这次不要照搬文件结构，但语义要和它保持一致。

这比我自己描述半天有效。

源码里有很多文字说不清的东西。命名习惯、异常边界、老系统的妥协、哪些地方看起来奇怪但其实不能动，AI 读到了才有机会理解。

我现在觉得，给 AI 参考源码，其实是在降低双方猜测的空间。

需求复杂的时候，继续堆文字不一定有用。找一个最接近的实现，让它先读，反而更快。

方案摊开以后，我才知道自己想要什么

我以前以为自己对需求判断挺明确。

后来发现不是。

很多判断，是看到方案后才出现的。

比如一个列表要展示归档状态。AI 给了两个方案：一个是在原列表接口上补字段，一个是新增归档详情接口。

单看设计，新接口好像也没错，职责更清楚。但我看到之后马上觉得不对。这个页面要的是扫一眼状态，不应该为了每一行再发请求。对这个需求来说，在原接口补字段反而更合适。

再比如任务取消。AI 可能会给我一个完整状态机，看起来很稳。但我看完会意识到，当前真正要解决的不是状态机不够完整，而是“用户发起取消”和“runtime 真的停了”这两个语义必须拆开。

这些判断，我一开始未必能直接写进 prompt。

所以现在我会让 AI 先给两三个方案，但我会加一句：

优先给最小改动方案，不要为了完整而新增抽象。

这句话对我很重要。

AI 很容易把事情做得“更完整”。但老系统里，完整有时候就是风险。多一个抽象，多一张表，多一个配置项，后面都要有人维护。

这个东西是不是当前需求必须要的？，不是的话，就先不要做。

plan 不是为了好看，是为了别改飞

我以前对 plan 没那么敏感。

现在我会认真看。

不是看它写得漂不漂亮，而是看它有没有越界。

如果只是补一个状态字段，计划里出现了“重构状态体系”，我会让它收回去。

如果只是当前入口有问题，计划里开始改公共 service，我会让它说明为什么非改不可。

如果一个功能暂时没有规模化诉求，计划里却设计了任务表、进度表、清理策略和配置开关，我通常会直接砍掉。

AI 写代码有个习惯：顺手。

顺手补一个工具类，顺手改相邻代码，顺手抽一个通用方法，顺手加一个“以后可能会用”的扩展点。

它不是故意乱来。它只是觉得这样更完整。

但工程里很多麻烦，恰恰就是“顺手”带来的。

plan 不是仪式。它是用来控制改动半径的。

计划写清楚以后，我就能判断：这次到底改哪里，不改哪里；哪些是必须做的，哪些只是 AI 觉得可以顺手做的。

实现中改方向可以，但原因要留下

再好的计划，写到真实代码里也会变。

这个我现在已经不纠结了。

• 有时候计划里说复用某个 service，读进去才发现它会顺手发通知。
• 有时候看起来只是改状态，结果还有 Redis、SSE、定时任务一起读。
• 有时候某个字段看起来能表达事实，历史数据里却早就被当成策略开关用了。

这些不是异常情况。老系统开发经常就是这样。

不怕计划变，怕的是 AI 悄悄变。

我会要求它在实现中把偏离写出来：

如果原计划不适用，先说明为什么，再选最保守的做法。

这件事看起来很小，但对 review 很有帮助。

最后看 diff 的时候，我不只是看到“它改了什么”，还能看到“为什么这里没有按原计划做”。这能省掉很多猜测。

AI 最让我不放心的地方，不是它犯错，而是它替我做了关键决定，却没告诉我。

implementation notes 对我来说就是干这个用的：把那些关键决定摊出来。

“完成”这两个字，我现在会看证据

我现在不太喜欢 AI 直接说“已完成”。

不是说它一定错，而是这句话经常太轻了。

我更想看到的是：

跑了什么？
结果是什么？
覆盖了哪条路径？
哪些路径没有覆盖？
有没有既有失败？

这也是 verification-before-completion 对我影响最大的地方。

没有新鲜验证，就不要说完成。

这句话很朴素，但很有用。AI 的语气经常很确定，确定到你会忘记它其实只是在推断。

比如“这个改动不会影响其他逻辑”“现在应该可以正常工作”“问题已经修复”。如果后面没有命令、日志、接口返回或者数据库状态，那它就只能算判断，不能算结论。

当然，我也不是每次都要求完整测试。

小改动跑编译和定向检查就够。状态流、任务调度、文件处理、外部 runtime 这种东西，就要把关键链路走一遍。哪怕本地条件不完整，也要说清楚哪些验证了，哪些没验证。

我更愿意看到这种收尾：

Maven 编译通过。
手动走了提交和取消两条路径。
runtime 超时分支本地没有服务，没覆盖。

这比“已完成”更让我放心。

因为它告诉我边界在哪里。

最后我会让它问我几个问题

这个习惯是后来才有的。

功能做完后，我会让 AI 反过来问我几个问题。

刚开始我觉得没必要。代码是我让它改的，plan 我看过，验证也跑了，还问什么？

后来发现还是有必要。

看 diff 只能知道文件怎么变了，不代表我真的理解行为怎么变了。尤其是任务状态、文件归档、runtime 回调、补偿任务这类链路，真正的行为往往是新代码和旧逻辑叠在一起产生的。

我会让它问：

基于这次改动问我 5 个问题，重点覆盖状态流转、失败分支、外部依赖、验证边界和可能的误解。

比如：

任务已经 RUNNING 后收到取消请求，数据库状态怎么变？
runtime 没有响应时，前端看到的是取消中还是失败？
文件已经清理后，再触发恢复会走哪条分支？
这次验证覆盖了哪条路径，哪条只是代码层面确认？

如果我答不上来，就说明我只是接受了 AI 的结果，还没有真正吃透这次改动。

代码最后进仓库，责任还是在我这里。

AI 可以帮我写，但不能替我背锅。

更看过程，而不是只看结果

以前我判断 AI 靠不靠谱，主要看结果。

代码写得快不快，能不能编译，测试能不能过。

现在我更看过程。

它有没有先看真实链路？有没有问到关键问题？有没有给出方案取舍？有没有控制改动范围？偏离计划时有没有说明？最后有没有验证证据？

这些东西比一次代码生成质量更重要。

因为我不需要 AI 每次都像天才一样给出最优解。我更需要它像一个稳定的协作者：知道什么时候该问，什么时候该停，什么时候该少做，什么时候必须验证。

用了一段时间 Superpowers 后，我最大的感受不是它让 AI 更强，而是它让 AI 更克制。

• 克制地进入实现。
• 克制地扩大范围。
• 克制地做抽象。
• 克制地宣布完成。

这种克制，在 AI Coding 里其实挺稀缺。

One more thing...

总结

先看真实链路，再谈方案。
说不清楚，就给源码参考。
方案先摊开，再决定走哪条。
plan 用来控制范围，不是写给人看的装饰。
实现偏离可以，但原因要留下。
没有验证，不说完成。
最后让它问我，确认我真的懂了。

这些东西听起来不新鲜。

甚至可以说，它们本来就是正常工程流程。

只是 AI 太擅长响应，也太擅长生成。你不给它约束，它就会把“快”放在“稳”前面。

但在它写之前，自己得先确认两边在解决同一个问题。