pstack 拆解 04 · 探索与杠杆
模型想到的第一个方案往往不是最好的,而设计一旦写进代码就很难反悔。同时,它能不知疲倦地重复劳动,却不会主动把劳动变成工具。
这一篇讲三条:没先例时做两三个竞争方案,把重复劳动做成可重跑的杠杆,以及反复失败时质疑前提而不是再修一次。
exhaust-the-design-space
穷尽设计空间的背后是一个关于反悔的判断:模型给的第一个方案,是"它想到的第一个形状",不是"最好的形状"。 设计一旦写进代码,再改就要付重构的代价,所以设计阶段是唯一便宜的反悔窗口。做两三个结构上不同的方案,换的是"以后还能改"的自由,也就是 option value。这里的关键词是"结构上不同":同一个思路的两种写法不算探索,那只是把第一个方案确认了两遍。
它有一句判据:当正确答案不明显时,做两三个互相竞争的方案,并排比较,再决定。
为什么值得。因为建错的东西,比探索三个方案贵得多。
什么时候用。代码库里没有先例的新交互,有多个可行路线的架构选择,体验取决于手感而不是逻辑的产品决策。
什么时候不用。已经有明确模式的机械实现,目标清楚的修 bug 和重构,约束只留下一个可行方案的时候。
这里最容易犯的错是"假装探索":真正的探索要能让你在结果出来之后改变主意,而结果是你眼睛能看到的原型或草图,不是你脑子里的对比。
仓库里实现这条原则的是 arena。它并行起 N 个候选,交叉评判,选一个做底,再把其他候选里最好的部分嫁接进来。
build-the-lever
造杠杆的背后是一个关于信任的判断:把"信任"建立在"可复算"上,而不是"我的保证"上。 自动化的价值有两层,第二层常被低估。第一层是吞吐:一个脚本一次做对所有单元,还能免费重跑,而且它每次的做法完全一致,不会今天一个样明天一个样。第二层是信任:脚本是一个 reviewer 能读、能重跑的东西,而手工做的东西只能靠重做来复核。也就是说,杠杆把"相信我"换成了"跑这个"。在需要别人相信你的工作时,这一层比省下的时间更值钱。
它有一句判据:工作不平凡时,造那个做这件事的工具,而不是用手上做。
它的细则。
默认造杠杆。 只有任务确实平凡,几处一眼看穿的编辑,才跳过去。
第一个单元先手工做。 用手工做掉第一个,学出配方,再造工具。然后重跑工具,和手工版本 diff,证明它是对的。让这个杠杆可以安全重跑。
按工作挑形式。 编辑用 codemod 或脚本,重复文件用生成器,分析用一条 dump 到 sqlite 的查询,验证用可重跑的检查。
确定性杠杆胜过 fan-out。 如果工具能一遍处理所有单元,就自己跑,不要派一堆 subagent 去做脚本能做的事。这句在原文里很反直觉,值得记住。
派活时,把杠杆写成子 agent 都读的 skill。 配方、验证契约、不要碰的边界,放在一个产物里,并且放在它们的写范围之外,免得它们悄悄改掉契约。
它会产生一个文件。 如果你引用了这条原则,diff 里却没有 codemod、脚本、生成器或委派 skill,那你就是没应用它。这是原文的自我检查,很硬。
活得比会话长的杠杆,提交它。
边界在"平凡"。门槛是平凡,不是重复。一次性的活也可能值得造杠杆,前提是杠杆恰恰是那个让工作可检查的东西。反过来,两行改动不要为它造框架。
attack-the-premise
质疑前提的背后是科学方法里的证伪:反复在同一个前提上失败,是关于那个前提的证据,不是关于那些修复的证据。 当两个或多个修复共享同一个前提、又在同一个关卡上失败时,这些失败合起来指向的是那个前提,但直觉会推着你再修一次,因为"这次可能就成了"。这条原则要做的,是把你从这个循环里拽出来:先把每个失败修复都假设的那一句话写下来,做一次普查,看是哪些 actor 在每个失败里承担了不平衡,然后质疑那个被所有人默认的前提,而不是再写一个假设它的修复。
它有一句判据:当两个或更多共享同一个前提的修复,在同一个关卡上失败时,该怀疑的是前提,不是这些修复。
它的细则。
先把前提写下来。 前提就是每个失败修复都假设的那一句。
下一次修复之前做一次普查。 按 actor 数不平衡。普查显示的是哪些 actor 持有不平衡,不是不平衡有多大。普查要写成可重跑的脚本,这里就用上了上一条 build-the-lever。
读偏斜。 如果每次跑都是同几个 actor 持有大部分不平衡,说明有东西在给他们分配这个角色。找出是什么在分配,那个分配就是下一个要追的"为什么"。
移除不对称,而不是补偿它。 轮换角色、随机化分配、或者把角色挪走,让没有任何 actor 每次都持有它。加一条返回路径、一个共享池、一次批量交接、一个周期性再平衡,这些做法都保留了那个分配,只是每次多做一道工。这里能看到 laziness 的影子:能移除的不对称,不要用补偿去盖。
停止条件也明确。前提没写下、普查没做出来之前,不要开始下一个修复。如果普查显示各 actor 很均匀,那前提就不是原因,去别处找,普查留着当证据。
参考
原文都在 pstack 上游仓库(cursor/plugins):