锅糊了别硬翻,炒完一道菜记得洗锅。

上周聊了《大模型是台老虎机》,今天接着往下说——虽然原理上是老虎机,但这不是纯运气游戏。日常使用大模型更像是做菜,今天给大家分享几个"做菜"的小技巧。

下面这些都是我用各种 vibe coding 工具攒下来的 Tips,对于 Claude Code、Codex、CodeBuddy 这些 Agent 工具都适用。它们大多不是什么高深技巧,更像是炒菜时的手感:火候到了该关火、菜串味了该换锅。核心就一件事——把上下文这口锅,洗干净。

复杂的菜,先看菜谱?

碰上一个相对大的任务,如果你脑子里还没有一个清晰的方案,别急着让模型开干。先进 plan mode。

让它先出一个完整的方案,你过一遍、改一改,确认没问题了,再让它动手实现。讲究一点的,还能在 plan mode 里叠加 /grill-me skill——模型反过来追问你一堆问题,把那些你自己都没想清楚的地方一个个想清楚,这样方案模型才算真的跟你对齐了。

这一步类比做菜,就像你要做一道口味小龙虾之前,先把菜谱翻出来:配料、火候、先放什么后放什么,全搞清楚再下锅。看着慢,其实最省事——它省掉的,是你中途手忙脚乱、整锅推倒重来的时间。

给目标,还是站边上教它颠勺?

这是我越用越深的一个体会:模型是有推理能力的。很多时候,你只要把目标和方向给清楚,不用手把手教它每一步怎么做。管得太细,反而容易把它带偏。

我看到一个挺有意思的研究:管理者去指挥大模型干活,提示词的效率比普通开发者还高出 10%。为什么?因为管理者更擅长说清楚"我到底要什么、有哪些约束",目标感强;而开发者常常一上来就教模型"你应该这么写代码",一头扎进实现细节里,反倒把最重要的目标给丢了。

放到灶台上就是:你要当那个拍板"今晚做道麻辣小龙虾、要够辣够入味"的人,而不是站在锅边盯着厨子喊"火再大点、姜再多放两片"的人。把目标和口味交代清楚,颠勺这事,交给它。

面多了加水,水多了加面?

跟大模型聊着聊着,你会发现它开始往沟里走。这时候第一反应不该是继续陪它绕,而是及时止损。

止损有两个层次。

轻一点的,叫纠偏:你先按住它,补一段更明确的信息,把它拽回正道。

但如果你发现纠偏纠了好几次(这是个危险信号),那就别在这口锅里继续翻了。菜已经糊了,你越翻越糊——这就是大家常说的"上下文腐烂"(context rot)。模型把前面那些错误的、互相打架的对话全读进去,越读越懵。

这特别像炒菜时的一种窘境:咸了加水,水多了再加盐,盐多了又兑水……一路补救下来,最后整锅菜全毁了。跟大模型纠偏纠上头,是一模一样的剧本——每一次"补救"都在往锅里加新的乱七八糟,菜只会越来越糟。

这时候正确的做法是:菜做坏了就做坏了,没关系,把锅洗干净,重做一遍。但别空手重来——先用 hand-off 这样的 skill,把这一锅踩过的坑、好不容易达成的共识记下来,然后另起一个新窗口,拿着这份小抄重新开炒。带着教训重做,就不会再栽进同一个坑。

听起来有点反常识——好不容易聊到这儿,推倒重来不亏吗?不亏。脏锅里炒不出好菜,洗干净再来反而快。

及时止损、及时纠偏、果断开新窗口,这是我管理上下文最有效的一招,没有之一。

自己做的菜,永远好吃!

模型任务做完,我一般不会直接收货,而是让模型再 review 一遍。但这里有个坑。

千万别在当前这个会话里让它 review。

这就像你自己炒的菜,自己总是觉得好吃——模型会爱上自己给出的方案,你让它自己 review 自己,往往 review 不出重点。

正确的姿势是:另起一个干净的会话,让它以一双没被污染的眼睛重新审视。哪怕用的是同一个模型(比如都用 Opus 4.8),换个新窗口,效果就完全不一样。

更进一步,交叉 review:让 GPT-5.5 去 review Opus 写的代码。这就引出另一件事——不同的模型,擅长的菜系不一样。Opus 更擅长架构、更扛得住长任务;GPT 的执行力强、对指令的遵守度更好。所以一个很实用的配合是:让 Opus 当主厨定菜单(架构设计),让 GPT-5.5 掌勺(具体实现),各司其职。

被忽视的技巧:边炒可以边喊停

顺手提一句:Claude 和 Codex 现在都有个叫 steer 的功能。

就是说,你盯着它干活的过程中,可以随时插一句话,直接打断它当前的目标和执行路径,当场纠偏。不用等它把整盘菜炒完了你才发现放错了盐——颠勺颠到一半,你就能喊"停,这步不对"。

新手,我劝你盯着锅看

这条专门给编程经验还不多的朋友。

我强烈建议你盯着大模型干活。看它怎么分析问题、怎么一步步拆解、怎么调工具、怎么自己 debug。是有点累(全程盯锅嘛),但你在旁边看一个老师傅颠勺,学到的东西比自己瞎摸要多得多。

别把它当成一个黑盒,扔进去需求、等着出结果。看它工作的过程,本身就是最便宜的一堂课。

复杂菜品上多 Agent

每个 Agent 有它自己独立的上下文窗口,互不粘锅:

  • 调研与分析:一个负责调研,一个负责需求分析,一个负责架构设计。
  • 对抗校验:设计完,换一个用完全不同模型的 Agent 去 review,专门挑刺、做对抗性验证。
  • 编写与审核:最后让一个模型写代码,写完再让另一个模型来审。

这套流程,跟 Claude Code 最新的 Ultra Code 的 workflow 模式其实有点像。

但我得泼盆冷水:简单任务别上这一套,纯属浪费 token。这就好比煮个泡面,你非要支起八口锅分工协作,图什么呢?

模型有时候会偷懒

你有没有发现,模型有时候会偷懒?这事有点反直觉,但你从它的工作原理看,就通了。

模型的上下文窗口是有限的。它要在有限的窗口里把你的活干完,大概率会抄近道——能省一步是一步。

换个角度看会更清楚。你给它一个任务,在模型眼里发生了什么?它根据当前上下文和任务的理解,在自己庞大的参数空间里找到一个坐标系,定下起点;你给的目标,就是终点。它生成答案的过程,本质上是从起点往终点做插值,中间穿插着工具调用、MCP、skill。

这里有个要命的推论:任务给得越大,起点和终点离得越远,中间这条插值路径上能出岔子的地方就越多,roll 出正确答案的概率就越低。 一锅乱炖十样菜,炒糊的概率自然比单炒一道高。

也正因为模型会偷懒,社区里冒出来一堆"PUA"型的 skill——逼着模型别走捷径,从第一性原理、从根因上去分析问题。我实际用下来,有时候还真挺管用。

说到底,一锅别炒太多菜

把上面这些小动作串起来,你会发现它们指向同一件事:

  • 保持上下文独立:多 Agent 模式之所以好用,就是每个 Agent 的锅是分开的,互不串味。
  • 及时开新窗口:反复纠偏纠不动了,别在脏锅里硬磕,洗锅重来。
  • 别在一个会话里耗到天荒地老:一件事在一个窗口里耗了太久,与其继续陷下去,不如新开一个。既为了上下文干净,也因为这毕竟是台老虎机——每次摇出正确答案,都是有概率的。

所以最后一条,也是我最想说的:

do one thing and do it well

这本来是 Unix 的哲学,放在跟大模型干活上一样成立:把问题拆小,让一次会话只干一件事。 review 架构的时候,就别同时让它 review 具体实现;炒这道菜的时候,就别惦记着另一道。模型每次的注意力越聚焦,起点离终点越近,它给你端上来的东西就越靠谱。

你们还有什么自己攒的小技巧,欢迎评论区聊聊。

Reference

配套阅读:上一篇《大模型是台老虎机:你能控制的只有事前对齐和事后验证》。