pstack 仓库与 Lauren 推文分析

By 陈成 · Published October 22, 2026

This report also has an interactive version.

分析日期 2026 年 10 月 22 日。分析查阅了 backnotprop/pstack（提交 e44668c）、对照了上游 cursor/plugins/pstack，用 bird 逐条阅读了 19 条相关推文，还读了 Lauren 的两篇长文《The Complete Guide to pstack》Pt. 1 和 Pt. 2，以及最近两周她本人和其他用户关于 pstack 的推文。另外看了她 9 月 21 日发在 X 上的 38 分钟演讲视频，原本是给 Cursor Compile London 准备的；转写由 Whisper 自动生成，专有名词可能不准。推文日期按 UTC 记。产能、质量数字都是作者自述。

先说结论

pstack 的核心不是 56 个技能，而是一条顺序：先让代理能自己跑起并操作你的应用（验证技能 + feature map），再用 /poteto-mode 让它按任务类型走固定流程，最后才谈并行和自动合并。没有第一步，后面的多代理流程只会更贵，不会更可信。Lauren 自己在 Pt. 1 里也是这么排的。她在 9 月的演讲里分得更清楚：验证管"对不对"，pstack 管"好不好"（性能、代码质量），两样都有才够。那场演讲标题是 2,500 个 PR，但 pstack 只讲了一小段，她自己说"今天不多讲这个插件"，产能主要归到验证、给代理设计的架构和自动派活的外循环上。

对 Claude Code 用户，有两件需要注意的事。一是默认配置里的 Grok 模型在 Claude Code 里会被映射成"沿用父模型"，/arena、/architect、/interrogate 这些靠"不同模型家族互相评审"的流程会退化成同一家族自评。二是 /poteto-mode 本身约 3,600 个英文词，每个 poteto-agent 子代理都被要求完整读一遍，子代理越多，固定上下文成本线性增加。值得用，但最好挑着用。

来源链：谁在维护什么

Lauren Tan（@poteto）
  └─ cursor/plugins/pstack        原始版本，Cursor 插件，0.15.30
       └─ backnotprop/pstack      Michael Ramos 的镜像，0.15.28
            · upstream 分支：上游原样
            · main 分支：upstream + 通用化改写
            · 安装：npx skills add backnotprop/pstack

Lauren 以前在 React 团队，后来去 Cursor 做 Agents Window 的性能。Cursor 现在并入了 SpaceX AI，她在那边做 Grok Bot。默认配置混用 Claude 和 Grok 就是这个原因：Grok 是她公司自己的模型，这个组合首先反映她的工作环境，不一定适合其他宿主。

镜像的价值是让 Claude Code、Codex、Pi 等宿主能直接装。代价是多一层同步延迟，以及改写本身可能偏离原意。MIRROR.md 写明了同步方法，冲突时"保留 Cursor 的新含义，再套用通用措辞"。Lauren 在推文里说通过 Grok Bot 或 Cursor 安装会自动更新，镜像则要等维护者手动同步。

更新很快。10 月 4 日发 0.15.9，10 月 22 日上游已到 0.15.30，18 天二十来个补丁版本。这对试用是好事，对把它固化进团队流程的人是个提醒：技能文本随时在变，评测结果也会跟着变。

仓库结构

仓库包含56 个技能（其中 24 个 principle-*），poteto-mode 下 23 个 playbook，两个代理定义（poteto-agent、comment-sicko），一套只适用于 Cursor 的 Benny 自动化，docs/guide/ 下 10 章指南，MIT 许可。

各部分的量级大致如下：

部分	规模	什么时候进上下文
`poteto-mode/SKILL.md`	约 3,600 词	每次 `/poteto-mode`；每个 `poteto-agent` 子代理也要读
单个 playbook	300 到 2,700 词（bug-fix 368，orchestrate 2,692）	按任务类型选中后
原则	24 个，合计约 5,100 词	主文件只放索引，要求"应用哪个就完整读哪个"
全部 SKILL.md + playbook	约 49,500 词	不会一次全读

poteto-mode 按任务类型路由到不同的 playbook。几条值得注意的硬规则：要问用户"选哪个方案"之前，先判断这个问题能不能靠跑一下得到答案，能的话就走 Prototype playbook 去试，不要问人；任何代码先说出数据结构；跨函数边界的改动先走 /architect；提交前过 deslop，review 前过 /no-comments；答复里要点名哪个原则改变了哪个决定，并且只能点名本会话里真读过的原则。最后一条是很实用的防糊弄设计。

两篇长文中的方法

Lauren 的两篇长文详细介绍了具体方法，也说明了 pstack 想解决什么。

Pt. 1：验证是一切的前提（8 月 31 日）。 她把验证技能当作"关键基础设施"，甚至建议给它排 oncall。具体做法有三点。

第一，把操作应用做成一个小 CLI，而不是让代理每次临时写脚本去点按钮。这对应原则 Build the Lever。她列了这个 CLI 应有的特征：可组合、有破坏性副作用的命令带 --dry-run、用子命令逐步暴露功能、错误信息告诉代理该怎么做、--help 详细、输出 JSON。

第二，feature map。每个功能写清楚"用户从哪进、怎么用、用 CLI 怎么驱动、有哪些坑"。她称之为"物化的记忆"：代码是团队决策的投影，feature map 是它的压缩版，放在技能里所有人共享。她公开了一个虚构应用 Atlas 的示例。

第三，技术栈会影响代理生产力。Electron 和 Web 有 CDP，iOS 有模拟器；运行时越难调试、越难控制，代理越难用。她甚至说值得为此自建调试工具或换技术栈。这个判断很激进，但逻辑一致。

Pt. 2：用代码做计划（9 月 9 日）。 主题是"监督比你聪明的人"。

先对齐意图。让代理"用自己的话复述问题"（后来做成 /in-your-own-words），既能早发现误解，也避免自己的假设把代理带偏。
补上下文。/teach 调 /how（追运行机制）和 /why（从 git、PR 评论、Linear、Notion、Slack、Sentry 等查动机），/recall 从历史会话捞上下文。
计划靠原型而不是长文档。她明确反对对抽象计划做对抗式评审，理由是代理会臆想风险、为不会发生的边界情况设计防护。替代做法是 Prototype playbook 做两三个可切换的变体，用验证技能截图测量，再由 /architect 让多个模型家族各出一版类型签名级的设计，交叉评判后再实现，设计错了就推倒。
真要计划文档，就用 multi-phase-plan playbook，每一项都以"实际运行验证过"为完成标准，再用 check-plan.mjs 检查格式。大项目的计划临时提交进仓库，做完就删。

这两篇解释了 README 里"没有 planning 技能"的说法：不是不计划，是把计划换成可运行的东西。

在 Claude Code 里实际会发生什么

docs/harness/claude-code.md 是镜像加的映射表。读完后几处影响比较大。

多模型评审会退化。 默认角色配置是代码类任务用 grok-4.7-xhigh-fast，判断和写作用 claude-opus-5-5-xhigh，arena、architect、interrogate 的评审团各放一个 Claude 和一个 Grok。映射表规定非 Claude 模型在 Claude Code 里"省略 model，沿用会话模型"，默认的 Grok 直接写成 inherit-parent。结果是评审团里两个席位跑同一家族。poteto-mode 自己写着"第二意见是同一提示换一个模型，一致才是强信号"，这个前提在纯 Claude 环境里打了折扣。要找回多样性，得让子代理调用外部 CLI（Codex、Gemini 等），pstack 本身不提供。

cloud agent 变成 worktree。 映射表把 environment: "cloud" 换成 isolation: "worktree"。而 Lauren 在 Pt. 1 里专门劝人别用 worktree 做并行，说它吃磁盘和机器资源，本地大概十个就到头。她宣传的"每个代理一台机器、录屏截图、半夜自己合并"依赖 Cursor 云代理，Claude Code 本地跑拿不到这部分。

技能互相调用靠读文件。 因为 55 个技能都禁止模型自动调用，Claude Code 的 Skill 工具会拒绝它们，映射表让代理直接 Read 对应的 SKILL.md。能用，但比原生调用多一步，也多吃上下文。

Cursor 专有步骤会跳过。 Automations、Bugbot、云代理面板都会被替换成一行 "Skipped in Claude Code"。/maintain-verification-skill 作为每日自动任务这件事，在 Claude Code 里要自己用 cron 或别的调度去补。

外循环不在 pstack 里。 演讲里她讲了另一层：Grok Bot 接 Slack、Datadog、Sentry、PlanetScale，用 routines 订阅 Slack 线程和 Sentry 告警，自动触发云代理去复现 bug、开 PR，再配合 Cursor automations 和 SDK 自建的 bot。这一层 pstack 不提供，Claude Code 也没有现成对应物，要自己搭。

成本：已知数字和一个独立样本

成本来源有两层。一层是固定上下文，主会话读 poteto-mode 加若干原则和 playbook，每个 poteto-agent 子代理再读一遍 poteto-mode。另一层是子代理数量。Lauren 说成本主要来自大量子代理，建议跑 /setup-pstack 选预算，并在会话开头告诉代理别开大规模 swarm。预算档位只调推理强度（max / xhigh / high / medium），不减少子代理个数。

我只找到一个第三方的量化对比。用户 @dwkim601 用 claude-sonnet-5-5 跑了 5 个带隐藏测试的小任务，不加 pstack 和加 poteto-mode 都是 15/15 通过，后者花费 3.455 美元，前者 2.435 美元，约 1.4 倍。他自己也说任务太简单，说明不了难题上的效果。这个样本很小，但方向和直觉一致：简单任务上 pstack 主要是额外成本，收益要到需要复现、验证、设计取舍的任务上才可能体现。Lauren 说她对自己的技能做评测，还说过一次精简 10% 且行为无损，但没有公开评测数据。

另外两条用户反馈指向同一个外部风险：Cursor 订阅方案调整后，有用户说用不了 Opus 5.5，也有人问第三方模型受限后 pstack 是否会调整。pstack 的默认配置绑定了具体模型名，宿主的模型政策一变，效果就会变。

推文里的工程判断

Lauren 的推文还涉及以下工程判断。

把反复纠正变成结构。 四级顺序：用架构或数据结构根除 > lint 或测试让 CI 拦截 > 技能或规则 > 人工 review。她把第四级标成"ngmi"。/correct 回看代理反复犯的错，用架构、类型和检查去修。她给过一段可以直接用的提示词，要求代理翻历史提交找常见陷阱，用原型回答自己的开放问题，带着数据回来给人审。

演讲里最具体的例子是 Dune，Grok Bot 的客户端框架。出发点是代理爱走捷径，那就让捷径本身是正确的路；代价是人写起来很难受，好处是上下文很少的代理，或者设计师、PM 驾驶的代理，默认也能写对。三条原则：删掉已有技术债；每件事只留一种写法，用 CI 和 lint 引着代理走；看到坏模式先写 lint 规则止血，之后再让代理清理，让代码库一直处在"代理照抄也没问题"的状态。一个落地例子是用导入依赖图强制隔开 Electron 主进程和渲染进程，因为 Cursor Agents Window 出过慢代码被误引入渲染线程的问题，而渲染线程每帧只有 16ms（60fps）或 8ms（120fps）。她强调重点不在 Dune 本身，而在于把原本散在 code review 评论里的经验写进框架。

删注释。 她主张禁止并删除大部分代码注释，理由是代理爱模仿现有代码，一条解释临时绕过方案的注释会被当成模板扩散。演讲里给了起因：在 Cursor 代码库里，代理会拿周围的注释当理由，不去解决根本问题，贴个临时补丁了事。所以 Dune 直接禁止写注释。/no-comments 会保留解释浏览器怪癖这类必要注释，其余尝试从根上解决。这个立场有争议，她在回复里承认不是非黑即白。

验证是近似。 验证推文说得很克制：验证产物要证明工作正确、符合意图、比读整个 PR 更好审；同时承认不是所有领域都容易验证，验证也会错，"和相信人类真的跑过自己写的代码没什么区别"。

形式化验证还在 beta。 /create-formal-verification-skill 只有 41 行。关键要求是先挑单元测试够不着、出错代价高的性质；事件顺序类问题默认用 TLA+；没有现成验证器的语言要明说，并改用生成输入测真实代码；每个性质都要在一个故意改坏的版本上失败过，证明检查本身有效。上游在 10 月 19 日补了 TLA+ 默认值和无验证器时的回退，又加了 maintain-formal-verification-skill，说明这块还在快速调整。

产能数字一直在涨，而且口径不统一。 8 月 19 日说上个月 1,000 个 PR，8 月 31 日 Pt. 1 说"每月 2,000 个"，9 月 21 日说上个月 2,500 个。她在 Pt. 1 里也说过 PR 数曾是她眼里的虚荣指标。这些数字依赖 Grok Bot 团队的代码库、Cursor 云代理、接着 Slack 和 Sentry 自动派活的外循环，以及她本人的判断力，不能当作安装 pstack 的预期收益。

社区反应

最近两周的讨论以称赞为主，Taylor Otwell 说"pstack is the new solid"，Uncle Bob 说原则里有"非常重要的智慧"。也有人把它移植到 DeepSeek Harness 和 Codex。批评集中在细节，比如有设计师不满 /unslop 要求把弯引号换成直引号。还有用户说 Grok Bot 加 Cursor 云代理的组合多数时候很慢，需要人在环路里时他宁可开 CLI 自己引导，方向明确后再交给云代理和 pstack。这和 Lauren 自己说的"开头给足方向，之后放手"其实是一回事。

怎么用

先不装全套。 Lauren 自己建议从零技能开始观察失败模式。镜像 README 列了 16 个可以单独装的技能，比如 correct、in-your-own-words、arena、unslop。
第一件正事是验证技能。 跑 /create-verification-skill，重点打磨它生成的 CLI，再让 feature map 覆盖核心路径。在 Claude Code 里，每日维护要自己排程。
/poteto-mode 只给难任务。 复现型 bug、跨模块设计、性能问题值得用；改文案、小修小补不值得。开头加一句"不要开大规模子代理"。
在 Claude Code 里补模型多样性。 如果在意 arena、architect、interrogate 的评审质量，考虑让其中一个席位调用外部模型 CLI，否则要接受它们是同一家族的自评。
固定版本。 镜像和上游都改得快。团队使用时记下提交号，升级前用自己的几个代表任务对比一下。

我（AI）的判断

pstack 最能直接带走的是三样东西：验证 CLI 加 feature map 这套做法、"能跑出答案的问题不要问人"这条路由规则、以及把反复纠正沉淀成架构和 lint 的习惯。这三样不依赖 Cursor，也不需要装全套技能。

它的多代理、多模型部分是为 Cursor 云代理加 Claude/Grok 混合模型设计的。离开这个环境，尤其在纯 Claude Code 本地跑时，并行能力和评审多样性都会缩水，成本却不会等比例下降。唯一的公开第三方对比显示简单任务上贵 40% 且没有收益，难任务上的效果目前只有作者自述。

所以我会先花一两天把一个核心功能做成代理能自己跑通、能截图取证的路径，再挑一个反复出现的代理错误用 /correct 试一次。这两步做完，就能看出整套 pstack 在自己的代码库里值不值。

Read this report as Markdown · Cite it (BibTeX)