--- title: "pstack" author: "陈成" author_url: "https://research.sorrycc.dev/@sorrycc" url: "https://research.sorrycc.dev/@sorrycc/pstack" emoji: "🧠" published: 2026-10-22T10:34:03Z updated: 2026-10-22T10:34:02Z version: 1 interactive: "https://research.sorrycc.dev/pub/pl3gagh2wsbh/p/index.html" cite: "https://research.sorrycc.dev/@sorrycc/pstack.bib" --- # pstack 仓库与 Lauren 推文分析 By [陈成](https://research.sorrycc.dev/@sorrycc) · Published October 22, 2026 This report also has an [interactive version](https://research.sorrycc.dev/pub/pl3gagh2wsbh/p/index.html). 分析日期 2026 年 10 月 22 日。分析查阅了 [backnotprop/pstack](https://github.com/backnotprop/pstack)（提交 [`e44668c`](https://github.com/backnotprop/pstack/commit/e44668c2aad92eacf4e84df47984121fefb11b82)）、对照了上游 [cursor/plugins/pstack](https://github.com/cursor/plugins/tree/main/pstack)，用 bird 逐条阅读了 19 条相关推文，还读了 Lauren 的两篇长文《The Complete Guide to pstack》[Pt. 1](https://x.com/poteto/status/2094457600259842065) 和 [Pt. 2](https://x.com/poteto/status/2097732320606507506)，以及最近两周她本人和其他用户关于 pstack 的推文。另外看了她 9 月 21 日发在 X 上的 [38 分钟演讲视频](https://x.com/poteto/status/2102050467505430555)，原本是给 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](https://github.com/backnotprop/pstack/blob/main/MIRROR.md) 写明了同步方法，冲突时"保留 Cursor 的新含义，再套用通用措辞"。Lauren 在推文里说通过 Grok Bot 或 Cursor 安装会自动更新，[镜像则要等维护者手动同步](https://x.com/poteto/status/2110047891201114165)。 更新很快。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](https://github.com/backnotprop/pstack/blob/main/skills/principle-build-the-lever/SKILL.md)。她列了这个 CLI 应有的特征：可组合、有破坏性副作用的命令带 `--dry-run`、用子命令逐步暴露功能、错误信息告诉代理该怎么做、`--help` 详细、输出 JSON。 第二，feature map。每个功能写清楚"用户从哪进、怎么用、用 CLI 怎么驱动、有哪些坑"。她称之为"物化的记忆"：代码是团队决策的投影，feature map 是它的压缩版，放在技能里所有人共享。她公开了一个[虚构应用 Atlas 的示例](https://github.com/poteto/verification-skill-example)。 第三，技术栈会影响代理生产力。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`](https://github.com/backnotprop/pstack/blob/main/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 说[成本主要来自大量子代理](https://x.com/poteto/status/2110498629307990461)，建议跑 `/setup-pstack` 选预算，并在会话开头告诉代理别开大规模 swarm。预算档位只调推理强度（max / xhigh / high / medium），不减少子代理个数。 我只找到一个第三方的量化对比。用户 @dwkim601 [用 claude-sonnet-5-5 跑了 5 个带隐藏测试的小任务](https://x.com/dwkim601/status/2113002041991926194)，不加 pstack 和加 `poteto-mode` 都是 15/15 通过，后者花费 3.455 美元，前者 2.435 美元，约 1.4 倍。他自己也说任务太简单，说明不了难题上的效果。这个样本很小，但方向和直觉一致：简单任务上 pstack 主要是额外成本，收益要到需要复现、验证、设计取舍的任务上才可能体现。Lauren 说她[对自己的技能做评测](https://x.com/poteto/status/2109912648116826250)，还说过一次[精简 10% 且行为无损](https://x.com/poteto/status/2109116030761230571)，但没有公开评测数据。 另外两条用户反馈指向同一个外部风险：Cursor 订阅方案调整后，有用户说[用不了 Opus 5.5](https://x.com/antoniolorusso/status/2112973440923693268)，也有人问[第三方模型受限后 pstack 是否会调整](https://x.com/Zeez0321/status/2113065638755541362)。pstack 的默认配置绑定了具体模型名，宿主的模型政策一变，效果就会变。 ## 推文里的工程判断 Lauren 的推文还涉及以下工程判断。 **把反复纠正变成结构。** [四级顺序](https://x.com/poteto/status/2089067865098113024)：用架构或数据结构根除 > lint 或测试让 CI 拦截 > 技能或规则 > 人工 review。她把第四级标成"ngmi"。`/correct` 回看代理反复犯的错，用架构、类型和检查去修。她给过一段[可以直接用的提示词](https://x.com/poteto/status/2106542593656111276)，要求代理翻历史提交找常见陷阱，用原型回答自己的开放问题，带着数据回来给人审。 演讲里最具体的例子是 Dune，Grok Bot 的客户端框架。出发点是代理爱走捷径，那就让捷径本身是正确的路；代价是人写起来很难受，好处是上下文很少的代理，或者设计师、PM 驾驶的代理，默认也能写对。三条原则：删掉已有技术债；每件事只留一种写法，用 CI 和 lint 引着代理走；看到坏模式先写 lint 规则止血，之后再让代理清理，让代码库一直处在"代理照抄也没问题"的状态。一个落地例子是用导入依赖图强制隔开 Electron 主进程和渲染进程，因为 Cursor Agents Window 出过慢代码被误引入渲染线程的问题，而渲染线程每帧只有 16ms（60fps）或 8ms（120fps）。她强调重点不在 Dune 本身，而在于把原本散在 code review 评论里的经验写进框架。 **删注释。** 她主张[禁止并删除大部分代码注释](https://x.com/poteto/status/2110149626133438732)，理由是代理爱模仿现有代码，一条解释临时绕过方案的注释会被当成模板扩散。演讲里给了起因：在 Cursor 代码库里，代理会拿周围的注释当理由，不去解决根本问题，贴个临时补丁了事。所以 Dune 直接禁止写注释。`/no-comments` 会保留解释浏览器怪癖这类必要注释，其余尝试从根上解决。这个立场有争议，她在回复里承认[不是非黑即白](https://x.com/poteto/status/2110165682302447699)。 **验证是近似。** [验证推文](https://x.com/poteto/status/2109436202554372476)说得很克制：验证产物要证明工作正确、符合意图、比读整个 PR 更好审；同时承认不是所有领域都容易验证，验证也会错，"和相信人类真的跑过自己写的代码没什么区别"。 **形式化验证还在 beta。** [`/create-formal-verification-skill`](https://github.com/backnotprop/pstack/blob/main/skills/create-formal-verification-skill/SKILL.md) 只有 41 行。关键要求是先挑单元测试够不着、出错代价高的性质；事件顺序类问题默认用 TLA+；没有现成验证器的语言要明说，并改用生成输入测真实代码；每个性质都要在一个故意改坏的版本上失败过，证明检查本身有效。上游在 10 月 19 日补了 TLA+ 默认值和无验证器时的回退，又加了 `maintain-formal-verification-skill`，说明这块还在快速调整。 **产能数字一直在涨，而且口径不统一。** 8 月 19 日说[上个月 1,000 个 PR](https://x.com/poteto/status/2090141955695198633)，8 月 31 日 Pt. 1 说"每月 2,000 个"，9 月 21 日说[上个月 2,500 个](https://x.com/poteto/status/2102050467505430555)。她在 Pt. 1 里也说过 PR 数曾是她眼里的虚荣指标。这些数字依赖 Grok Bot 团队的代码库、Cursor 云代理、接着 Slack 和 Sentry 自动派活的外循环，以及她本人的判断力，不能当作安装 pstack 的预期收益。 ## 社区反应 最近两周的讨论以称赞为主，Taylor Otwell 说"pstack is the new solid"，Uncle Bob 说原则里有"非常重要的智慧"。也有人把它移植到 [DeepSeek Harness](https://x.com/monkeyin_92/status/2113105674557411541) 和 Codex。批评集中在细节，比如有设计师[不满 `/unslop` 要求把弯引号换成直引号](https://x.com/dvsch/status/2113130048668463260)。还有用户说 Grok Bot 加 Cursor 云代理的组合[多数时候很慢](https://x.com/chrisdrit/status/2113060804018974833)，需要人在环路里时他宁可开 CLI 自己引导，方向明确后再交给云代理和 pstack。这和 Lauren 自己说的"[开头给足方向，之后放手](https://x.com/poteto/status/2107567417316831523)"其实是一回事。 ## 怎么用 1. **先不装全套。** Lauren 自己建议[从零技能开始观察失败模式](https://x.com/poteto/status/2098637947021205856)。镜像 README 列了 16 个可以单独装的技能，比如 `correct`、`in-your-own-words`、`arena`、`unslop`。 2. **第一件正事是验证技能。** 跑 `/create-verification-skill`，重点打磨它生成的 CLI，再让 feature map 覆盖核心路径。在 Claude Code 里，每日维护要自己排程。 3. **`/poteto-mode` 只给难任务。** 复现型 bug、跨模块设计、性能问题值得用；改文案、小修小补不值得。开头加一句"不要开大规模子代理"。 4. **在 Claude Code 里补模型多样性。** 如果在意 arena、architect、interrogate 的评审质量，考虑让其中一个席位调用外部模型 CLI，否则要接受它们是同一家族的自评。 5. **固定版本。** 镜像和上游都改得快。团队使用时记下提交号，升级前用自己的几个代表任务对比一下。 ## 我（AI）的判断 pstack 最能直接带走的是三样东西：验证 CLI 加 feature map 这套做法、"能跑出答案的问题不要问人"这条路由规则、以及把反复纠正沉淀成架构和 lint 的习惯。这三样不依赖 Cursor，也不需要装全套技能。 它的多代理、多模型部分是为 Cursor 云代理加 Claude/Grok 混合模型设计的。离开这个环境，尤其在纯 Claude Code 本地跑时，并行能力和评审多样性都会缩水，成本却不会等比例下降。唯一的公开第三方对比显示简单任务上贵 40% 且没有收益，难任务上的效果目前只有作者自述。 所以我会先花一两天把一个核心功能做成代理能自己跑通、能截图取证的路径，再挑一个反复出现的代理错误用 `/correct` 试一次。这两步做完，就能看出整套 pstack 在自己的代码库里值不值。