先让 agent 自证，再用代码做计划：pstack

核心内容#

2026 年 8 月 31 日，Lauren Tan（@poteto）发了 Pt.1《Verification is all you need》 ↗。2026 年 9 月 9 日的 Pt.2 ↗ 接着写：验证能用了之后，研究、计划、原型和架构怎么做。

她在 Meta、Netflix、Cursor 做过大规模代码，也在 React 核心团队，参与 React Compiler。pstack 是她自己每天在用的一组 skill。两篇把这套用法拆开。

这篇顺着两篇原帖往下走：

• 她在守一个贡献很快的代码库，agent 快了以后卡在哪
• 验证为什么要做成基础设施：一个小 CLI，加上一份 Feature Map
• 有了验证之后，计划怎样改成复述、研究和能推翻的原型
• 这套为什么能把人从验收瓶颈里拿出来
• 按官方 README 装上，以及第一周可以怎么试

同站那篇讲 slop 的笔记问的是平均靠什么右移。这两篇更早，写的是她用来把验证做进每天的做法。

要点整理#

1. 园丁要跟上每天几百个 PR#

Pt.1 从她自己的工作写起。写那篇的时候，她大约两个月前开始参与 Grok Bot。团队每天往这个库落几百个 PR。她一边做功能，一边当园丁：盯代码、重构、加 lint 和检查。她说 pstack 让她可以每月往生产落大约 2000 个 PR，同时把质量守住。

这个数字以前会被当成虚荣指标。她的转折是：量本身不说明质量，但当你还能守住质量，量就开始有意义。地基如果跟不上贡献的速度，库会在被同时建造和扩展的时候散掉。非工程师也在往里提交。能跟上，是因为改动可以被验证，不是因为她看了每一行。

2. 快了以后，卡在三件事#

她不想要的是只有吞吐量、没有质量。根因她分成三件：

前一件让人变成瓶颈。后两件让它在瓶颈外面也做不对。Pt.2 把后两件收成同一句话：用得好不好，取决于你往上下文里放进了多少高质量的背景。

计划阶段她再点两个常见的错。一是直接收下 agent 的第一版设计。二是计划还是抽象的时候，就把它越磨越长，中间没有一次实测。

3. 最重要的 skill，是让它自己证明做完了#

Pt.1 把 verification skill 当成基础设施，不是多装的一个技巧。agent 能自己检查，就能一直做到检查通过。检查不了，每一步都交回给人。

生成的办法是跑 /create-verification-skill。它给这个项目写一个本地 skill。文中的例子叫 /control-app。里面是两样东西。

一个给 agent 用的小 CLI。 打开会话、点击、截图、录性能 trace、开关 feature flag。输出用机器能读的格式，比如 JSON。可能造成破坏的命令带 --dry-run。报错要写明下一步该怎么改，而不是只说失败了。她把这条原则叫 Build the Lever：与其每次临时写一段脚本去点按钮，不如留一条能反复跑的命令。命令更省 token，也更能复现。

CLI 先做稳，再谈别的。她在意的几条：命令能组合，危险操作可以预演，功能用子命令慢慢展开，帮助文本够用。网页和 Electron 可以借浏览器的调试能力。没有现成调试手段的栈，就得先把工具做出来，否则 agent 很难自己闭环。

一份 Feature Map。 应用里的功能被收成几份 markdown，挂在这个 skill 旁边。每个功能四块就够：

不用手写全库。/create-verification-skill 会让 agent 自己把功能过一遍，生成这些条目。她把 Feature Map 叫物化的记忆：代码库才是真正的记忆，这份地图是它的压缩版，省的是上下文。放在 skill 里，后来的贡献者共用同一份。

所以要维护。她建议至少每天跑一次 /maintain-verification-skill，把地图和 CLI 里漏掉的改动补上。用得越多，agent 有时会顺手改；这条命令负责接住没被顺手改到的部分。

验证能跑通几个 PR 之后，下一项是并行。她不建议用 git worktree 在自己的机器上开很多份。仓库一大，磁盘和机器先吃紧。她用的是 cloud agent：每个 agent 有自己的一台机器，能装依赖、跑应用、截图、录视频。开发环境如果已经能被稳定拉起，这一步就没有那么远。

她自己的分工是：负责对话的那个 bot 去派出 cloud agent，自己留在监督的位置，上下文保持干净。写代码的是被派出去的那一层。pstack 装在那一层。负责分活的不必亲自把这些 skill 跑一遍，派活时写上目标和怎么验收就够了。

Pt.1 里她还推荐 Dr Eggbot，一个会教别的 bot 使用 pstack 的 bot。已经有负责写代码的 agent 时，先让那个 agent 学会用，不必为了这件事再加一个。

4. 验证能用了，再决定做什么#

Pt.2 的问题是：检查已经能做了，怎么知道该做什么。

她先不把解法交给 agent。让它用自己的话把问题说回来。比如读完一条讨论，先说出它认为的根因，再动代码。这一步同时做三件事：把嘈杂的对话压成一句问题；误解在写代码之前就被拦住；你自己的假设也不会先把路堵死。模型已经能写出你没想到的解法时，监督的方式是把目标说清，把做法留开。

心智模型用 /teach 建。它内部会调 /how 和 /why。/how 追一段代码现在怎么跑。子系统跨了多个目录时，它会并行去读。/why 追当初为什么做成这样，去看 git、PR、工单和文档里的动机，而不是只读当前这版代码。让它讲给你听，它就得真的去读，不能只给一个很有把握的说法。

跨对话的上下文用 /recall。上一轮聊过的虚拟化、性能、相似的 bug，不要在新对话里从零再讲一遍。它从过去的对话里把当前状态收成一份简短的说明。

设计不要停在第一稿，也不要在纸上磨。她用原型 playbook 做两三个可切换的变体，丢在应用里或一个临时目录。视觉上的差异用 verification skill 去点、去截图、去量时间和布局。原型是用代码做的计划：开放问题靠跑出来的结果回答，不靠人在抽象方案上继续加条件。

更大的改动用 /architect。她把它拆成几个阶段：先用 /how 和 /why 把现有的归属和约束摸清；再让不同的模型并行出设计草图，草图里有调用方式、核心类型和公开函数；换一个模型按同一套标准做交叉评审；然后按草图实现。实现时如果发现要加意料之外的参数、到处打补丁，或者类型开始出现逃逸口，就把这版设计整个扔掉重来。她把这种反复出现的补丁当成架构错了的证据。

真的要一份计划文档，也放在设计定下来之后。/poteto-mode 里有一个多阶段计划 playbook，把已经选定的设计拆成小 PR。每一步的完成标准都是跑过、验过，不是测试文件存在。计划可以临时留在仓库里，让别的 agent 知道正在发生什么，做完就删。她不把计划长期留在库里。

抽象的计划看起来像进度。一份写得很长的计划，多半只是让人觉得这轮很努力。她的判断是，这种进度是错觉。调查、实测和验证接上之后，agent 工程才从打赌变成可以重复的流程。

5. 人退出瓶颈，靠的是证据#

这五件事是同一套闭环的不同侧面。

检查把人从每一步的验收里拿出来。 agent 能自己跑、自己截图、自己判断过没过，你看的是证据，不是过程。

工具比临时脚本便宜，也更稳。 一条 CLI 可以重跑。每次现写一段去点界面，token 和结果都不稳定。

Feature Map 是共享的压缩记忆。 它不代替代码库。它让后来的 agent 少花上下文去找「这个功能在哪、怎么触发」。

复述同时约束两边。 你不先抛假设，agent 就不会被你的假设带走。它为了讲清楚，得去读代码。

原型代替对抽象计划的对抗式审查。 对着一份还没落地的计划挑刺，agent 会编出用不上的风险。让它写出变体、量一量，开放问题有答案。

6. 它是什么，以及怎么装#

pstack 是一组开源的 Agent Skills，放在 cursor/plugins 仓库的 pstack 目录 ↗。配套的 guide ↗ 按顺序带一遍：安装、把工作交给 /poteto-mode、读代码、设计、实现、验证、过夜跑。

入口是 /poteto-mode。你给目标，以及怎么算做完。它从一组 playbook 里挑一个，把步骤抄进待办，再按步骤去调别的 skill。Pt.2 写的是 23 个 playbook，截至 0.15.0。2026 年 10 月 21 日的 README 还是这个数。不知道该用哪一个，就问 /poteto-help。它只回答，并给你一条可以发出去的 prompt。它不会自己开跑，因为一次 pstack 运行会花掉真实的 token。

安装命令以 README 为准。

Cursor。 在对话里运行：

/add-plugin pstack

Claude Code。 先加 marketplace，再装插件：

/plugin marketplace add cursor/plugins
/plugin install pstack@cursor-plugins

Claude Code 会给插件命令加前缀。/poteto-mode 在那里是 /pstack:poteto-mode，/setup-pstack 是 /pstack:setup-pstack。

然后两步。 运行 /setup-pstack，选推理预算，再给代码、判断、评审这几类角色选模型。它会检测你能用的模型，写成一条规则。没写到的角色用 skill 自己的默认。规则对之后新开的对话生效，所以装完要新开一轮。

setup 结束时，如果项目里还没有办法证明应用的行为，它会问一次要不要跑 /create-verification-skill。代码里有并发、重试或状态机时，还会再问一次形式化验证。刚上手，普通的 verification skill 就够。形式化验证留到测试很少能碰到那个失败点的时候。

开工就是把目标和验收说清楚。 README 里的例子是：

/poteto-mode this pr has a subtle bug where the scroll drifts every 750ms even
when idle. repro first, then fix and verify.

你不需要点名 playbook。先复现、再修、再验证，已经够它选路。换成你自己仓库里的一个小问题，句式保持这三截。

省 token 的办法 guide 写了几条：把推理预算调低，或者让代码角色用更便宜的模型；把某个角色设成跟当前对话同一个模型；缩短评审席位，一个席位就是一个子 agent；小改动不必上 /poteto-mode。/swarm 和 /architect 会并行开多个模型，留给确实值得比一遍的任务。

Pt.1 在 Grok Bot 里的路径是装上这个插件 ↗，然后输入 /poteto-mode。README 没有为它再写一条斜杠命令。

7. 第一周可以照着做#

命令都是上面那些。顺序是先看见它怎么选路，再花钱去生成验证 skill。

1. 第 1 天。 装上插件，跑 /setup-pstack。读 guide 的前两页：安装，以及把工作交给 /poteto-mode。setup 如果问要不要现在生成 verification skill，想先看一个小任务，就先拒绝。
2. 第 2 天。 在一个你熟悉的仓库里挑一个已知的小问题。用 README 那个例子的句式：先复现，再修，再验证。看它选了哪个 playbook，待办是不是按那个 playbook 抄出来的。
3. 第 3 天。 对同一段代码跑 /how 和 /teach。只核对它讲得对不对。这一步不改代码。
4. 第 4 天。 跑 /create-verification-skill。审它生成的 CLI 和 Feature Map：危险操作有没有 --dry-run，报错会不会告诉下一步，地图里的「怎么走到」是不是用户真的会走的那条。
5. 第 5 天。 用刚生成的 skill 做一个小改动。完成的定义写成：跑通，并留下截图或视频。
6. 第 6 天。 试一次原型。让它给同一个交互出两三个变体，用 verification skill 截图，你来选。
7. 第 7 天。 看这一周的 token 和留下的证据。值得的话，再加每天一次的 /maintain-verification-skill。

当前理解 / 结论#

1. 先有验证，并行才不是在放大未检查的改动。 agent 不能自己证明做完了，人就是瓶颈。每月很多 PR 只有在这件事成立时才算数。
2. verification skill 是一个小 CLI 加一份 Feature Map。 CLI 把操作变成可复现的命令。Feature Map 是代码库的压缩记忆，所有贡献者共用。每天维护一次，它才不会过期。
3. 计划用代码做。 先让它用自己的话复述，再用 /teach 和 /recall 把背景补上。两三个原型拿证据来选。设计在实现中被证明是错的，就整份扔掉。抽象计划写得越长，越像进度，也越可能没有实质。
4. 你交给 /poteto-mode 的是目标和怎么算做完。 playbook 由它来选。/poteto-help 只给建议，不替你花掉那一次运行。
5. 第一周只证明一件事：一个小改动能自己跑通，并留下证据。 多模型和多 agent 放在这之后，用在值得比一遍的任务上。