用好 Coding Agent 的关键不在写代码，在你按回车前那几分钟
哈喽，我是飞飞。
上周我干了件蠢事。手头一个功能，给一个列表页加批量导出，我懒得多想，一句「给这个列表加个导出 Excel 的功能」丢给 Claude Code 就让它开跑。四十分钟后回来，它确实把活干完了，代码也能跑。可方案整个拧了，它做成了同步阻塞式的，数据量一大整个接口直接卡死，而我要的是后台异步生成再下载。前后它按自己的理解改了七八个文件，跟我真正想要的差了十万八千里。
那一刻我没法只改一两行收场。它太勤快了，错误的方案被它高效地铺满了半个 codebase，我盯着 diff 看了半天，最后干脆 git reset 全推倒重来。四十分钟白费不说，我还得再花二十分钟把它生成的一堆错文件清干净。
那天晚上我想明白一件事：用 coding agent 这一年多，我踩过的大坑，几乎都不在它写代码的过程里，而在我按下回车之前那几分钟。
「一开始走偏，后面怎么改都改不好」，这句话戳了我很久
前几天刷到宝玉一条分享，大意是用好 coding agent 重点在两头，尤其是开头，一开始走偏了，后面怎么改都改不好。
我盯着这句话看了好一会儿。它把我那次推倒重来的根本原因点破了。
agent 的产出上限，在你按回车那一刻就定了大半。需求里没讲清的地方，它会拿自己的理解去补，补出来的方向大概率不是你要的。等它哗哗写完几百行你才发现不对，这时候沟通成本比一开始讲清楚高十倍。
说白了，我们这些人用 AI 写代码，省掉的是敲键盘的时间，省不掉的是想清楚要什么的时间。后者你不在开头花，就得在返工时加倍还。
模型越强，开头没规划好的代价反而越大
这事还有个反直觉的地方。很多人默认模型越强越聪明，我就能越偷懒，含糊说两句它也能猜对。实际恰恰反过来。
模型越强，它执行你那个错误方案的效率就越高。弱模型可能写两个文件就卡住，你还有机会喊停。强模型像 Opus 4.7、GPT-5.5 这种，你一句话它能一口气改十几个文件，等它停下来，错误已经渗透进整个项目了。
说真的，模型能力每涨一截，开头规划的权重就再重一分。它越能干，你越要在它动手前把方向卡准，不然它就是台开足马力往错误方向狂奔的推土机。
行业里其实早有共识。有个做 spec-first 开发的统计说，先规划再动手能减掉七成左右的无效返工。GitHub 的 Spec Kit 干脆把流程拆成 specify、plan、tasks、implement，先定规格再写代码。有句话我特别认同：快不是瓶颈，对才是。AI 把写代码变得这么快之后，瓶颈早从「写得快不快」挪到了「方向对不对」。
三家的 Plan 模式我都用过，手感差挺多
好在三家主流工具都把「先规划」做成了正经功能，不用自己硬憋。
Claude Code 的 Plan Mode 我用得最多。Shift+Tab 切进去就是只读，它读完相关文件、推理一遍，给我一份编号的执行计划，在我点头之前一个字都不会改。这个只读是工具层面强制的，不是嘴上说说。我可以对着计划挑刺、让它改，确认了再放它执行。四月还出了个 Ultraplan，规划时挖的上下文更深、计划更细。我拿它跑过一次大重构，它先把要动的十几个文件列出来、标好每个改什么，我当场就发现它准备动一个我不想让它碰的核心模块，提前拦了下来。要是直接让它写，这种事得等它改完才暴露。
Cursor 这边规划藏在 Composer 里，偏可视化，多文件改动它会一步步让我确认，适合我想边看边批的时候。
Codex 更自主，给它方案它自己往下闯的劲头更足，我反而要把缰绳收紧点用。
我现在养成的习惯是，稍微复杂点的需求，先让两家各出一版方案，对着看哪个想得更周全，取长补短再动手。一个需求出两版规划成本很低，却能帮我提前照见自己没想到的边界情况。
我现在固定下来的 plan-first 工作流长什么样
踩了足够多坑之后，我把开头这段固化成了一套动作。
动手前我会先把需求自己写一遍。与其说写给 agent 看，不如说逼自己先想清楚。哪怕就三五句话，把要做什么、不碰什么、边界在哪列出来，光这一步就能筛掉一半的跑偏。还是上面那个导出功能，我现在会先写明白：异步生成、走消息队列、不许阻塞主接口、复用已有的文件存储模块、先只支持 Excel 一种格式。就这么几行，agent 能跑偏的空间一下小了很多。
然后我一定先进 Plan 模式让它出方案，绝不让它直接写。它出的计划我当草稿审，重点不看它写得对不对，看它有没有理解我没明说的那部分。它要是把我心里默认的前提漏了，说明我需求没讲清，回去补。
方案我认可了，才放它执行。执行中它撞到计划没覆盖的岔路，好的 agent 会停下来问。这时候我宁可它多问一句，也不要它自作主张往下冲。
这套流程听起来慢，实际比「上来就让它写、写完再返工」快得多。我现在很少再有那种推倒重来的下午了。
实话讲，规划救不了所有事，这几个坑我也踩过
plan-first 不是银弹，丑话得讲在前头。
一个是上下文窗口变大不等于它真会照做。我写过特别详尽的计划，结果 agent 执行到一半还是漏了其中几条。窗口塞得下不代表它会逐条遵守，关键的约束我现在会在执行中再单独强调一遍。
另一个是规划过度反而绑手。我有阵子矫枉过正，把每个实现细节都在计划里写死，结果 agent 被框得死死的，丧失了它本来能帮我优化的空间。有次我连变量命名、函数怎么拆都写进了计划，它老老实实照做，反倒没提醒我有个现成的工具函数可以复用，最后还是我自己 review 时才发现。后来我学乖了，规划只定方向和边界。
分寸大概是这样：方向和边界你来定，实现细节交给它。讲清楚要去哪、哪些地方不能碰，至于路怎么走，强模型往往比你想得周全。
你按回车之前，会停下来几分钟吗
其实这套方法都很朴素，难的是改掉「上来就让 AI 写」的肌肉记忆。
我到现在还在跟自己较劲的一件事，是怎么判断一个需求到底值不值得先规划。太小的活进 Plan 模式反而啰嗦，太大的活不规划必翻车，中间那条线我还在凭手感摸。
你用 coding agent 的时候，是直接开干的多，还是会先停下来让它出个方案？有没有哪次没规划好、被 agent 反向坑惨的经历？评论区聊聊，我挺好奇大家都是怎么跟自己那股「想直接开写」的冲动相处的。