agentic coding 里最反直觉、回报也最高的一条纪律是:先别让 AI 写代码。 把一个任务拆成探索(读懂相关代码与约束)→ 计划(产出可 review 的方案)→ 编码(按计划落地)→ 提交(小步可回滚)四个阶段,在「计划」处花十分钟拦一道,胜过在「编码」之后花两小时救火。
道理三句话讲完。难的是怎么每次都做到——这篇先讲清这四阶段各自拦住了什么,再讲怎么用工具(主角是 Superpowers)把这条纪律焊成你绕不过去的流程,最后给四条真用下来才长记性的踩坑经验,以及什么时候可以跳过。
为什么不能一上来就写
AI 默认急于动手——你说一句,它立刻开写。问题在于:它对你的代码库、命名约定、既有抽象往往一无所知。没有探索就计划,等于在错误的地基上盖楼;盖得越快,拆得越久。最常见的翻车是:它重新发明了一个你早有的工具函数,或用了一个你项目里明令禁用的库——代码「能跑」,却和整个工程格格不入。
探索:先让它读,别让它写
第一阶段唯一的目标,是让 AI 建立正确的上下文:读相关文件、搞清数据流、找到类似的既有实现。明确告诉它「现在只探索,先别改代码」。这一步还可以派只读的子代理去并行摸清几个方向(后面 EP5 展开),把结论汇总回来,而不占用你主会话的上下文。
计划:产出一份你能 review 的方案
让 AI 把打算怎么做写成一份计划:改哪些文件、加什么、有哪些取舍、怎么验证。这是你介入成本最低、收益最高的一道关卡——读一份计划只要几分钟,而读一版写错的实现要几十分钟。计划阶段你拦下的每一个错误方向,都省掉了后面一整轮的返工。
编码:按计划落地
计划批准后才进入编码。有了清晰的计划,AI 的实现会稳得多,因为它不再边写边猜你到底要什么。你的角色也从「逐行写」变成「盯着它按计划走,偏了就拉回来」。
提交:小步、可回滚
让它小步提交:一个逻辑改动一个 commit,信息写清。出问题时能精确回滚到上一个好状态,而不是在一大坨改动里大海捞针。频繁提交与检查点(checkpoint),是你在 agentic 编程里的安全绳——它越敢放手跑,你越需要随时能退回来。
怎么驾驭这条流水线:让工具替你立规矩
道理都懂,难的是执行。靠自觉每次都「先探索、再计划」,顶多坚持三天。真正可靠的做法是:把这条纪律交给工具去强制执行。
第一层是各家 agent 自带的 plan mode。 Claude Code、Cursor、Codex 都有「先出方案、你批准了才动手」的模式。它把「编码」这道闸门焊死,够用,但也仅此而已——它管的是「动手前先停一下」,不管你的方案到底够不够细、上下文喂得够不够。
真正把整条流水线管起来的,是 Superpowers——Jesse Vincent(obra)开源的一套「AI 编程开发方法论」:一组可组合的 skill,把上面这套纪律变成 agent 必走的流程。它不绑死某一家——Claude Code、Codex、Copilot CLI、Gemini CLI 等主流 agent 都能用,各端自动适配自己的工具命名。以 Claude Code 为例,装它就两行命令:
/plugin marketplace add obra/superpowers-marketplace
/plugin install superpowers@superpowers-marketplace
(也可以直接从官方市场装:/plugin install superpowers@claude-plugins-official。)
它的价值不在装得快,而在它把几个关键前置过程做成了你绕不过去的强制步骤——真正动手写代码之前,先逼你依次走完:
- 脑暴(brainstorming):先不出方案,反过来「采访」你,把你脑子里的意图、约束、边界一点点问清楚,落成一份结构化的输入。
- 写计划(writing-plans):据脑暴产出一份正式计划,并拆成一个个小任务。这一步是 Superpowers 最香的地方——它给的 Plan 基本都是可落地的方案:改哪些文件、按什么顺序、每步怎么验证,照着做就能跑,而不是一份泛泛的 TODO。
- 子任务执行(subagent-driven development):不再一个会话从头干到尾,而是把计划里的每个小任务派给独立的子代理去做,主会话只管调度与审查——上下文更干净,跑偏一个也不污染全局(子代理与并行的细节见 EP5)。
这三步走完,才轮到编码与提交。一句话:plan mode 是「踩一脚刹车」,Superpowers 是「装一整套驾驶规程」。
用好 Superpowers:四条踩过坑才懂的经验
工具给你规程,开好车还得靠手感。下面四条,都是真用下来才长记性的:
1. 上下文喂不够,AI 就替你瞎猜。 脑暴决定计划质量,garbage in, garbage out。别只甩一句「帮我加个 X」——把背景、现有约束、你已经知道的坑、相关文件一次性喂够。你省下的每一句上下文,AI 都会用一个想当然的假设补上,而它的假设往往不是你要的。
2. 别一路回车点「推荐答案」。 脑暴时它一次只问你一个澄清问题(Claude Code 会把选项连同「推荐项」摆出来,还能用 "chat with this" 就地展开聊)。但它问的未必全,推荐的也未必贴你的场景——碰到自己也拿不准、或明显答歪的地方,别顺手回车,把这一处聊透再继续。 计划阶段每一个含糊带过的决定,都会在执行阶段被放大成返工。
3. 聊歪了,别硬掰——重开。 即便 Superpowers 有时也是开盲盒:一次会话聊着聊着就偏了。真正难纠的不是「跑偏」本身,而是上下文里正确的理解和错误的理解混在了一起——你越想掰,新的纠正越和旧的噪声纠缠,整体越掰越乱。我曾经聊了十几轮、几十分钟,越走越偏;后来换了个做法:让 AI 基于当前会话先沉淀出一份「正确理解」的 markdown,再开一个干净的新会话带着它从头聊,很快就摆正了。(这条不是 Superpowers 的流程,是通用的上下文卫生,但在脑暴/计划阶段尤其救命。)
4. 审查别逐行啃 markdown,让它画给你看。 AI 产出的计划、改动说明往往是一大坨 markdown,逐行读又累又容易漏——关键的坑常常藏在第 40 行。换个方式:让 AI 把要点和数据流总结成 HTML,尤其让它画几张 SVG 图,结构、取舍一眼就看出哪里不对,比啃文字高效得多。(Superpowers 的脑暴自带一个浏览器「可视化伴侣」做输入侧的图示;审查产出侧这个手法你得自己开口要。你正在看的这篇里的动图,就是这么来的。)
什么时候可以跳过计划
不是每件事都要走完整流程。改一行文案、修一个拼写、加一个语义明确的小函数——任务足够小且明确时,直接让它写更高效。判断标准很简单:如果你能一句话说清「改什么、在哪、预期结果」,且影响面只在一两个文件内,就跳过计划;一旦涉及多文件、有设计取舍、或你自己都还没想清,就退回探索→计划。
进阶:把计划写成 spec(规范驱动开发)
对较大的需求,可以把「计划」升级成一份正式的 spec:它不只是一次性方案,而是可版本化、可让 AI 反复对照的「需求事实源」(Superpowers 的 writing-plans 产出本身就已经很接近这种 spec)。规范驱动开发(SDD)的核心是——先把要什么写清楚到能被验证,再让 AI 去实现;实现一旦跑偏,就拿 spec 当裁判把它拉回来。这恰好引出了下一道关:计划再好,也拦不住实现阶段混进来的、看起来对的 bug。