Repo teardown · 2026-10-22

pstack 仓库与
Lauren 推文分析

pstack 的核心不是 56 个技能，而是一条顺序：先让代理自己跑起并操作你的应用，再按任务类型走固定流程，最后才谈并行和自动合并。

backnotprop/pstack @ e44668c 上游 cursor/plugins/pstack 19 条推文 长文 Pt. 1 / Pt. 2 38 分钟演讲
56技能，其中 24 个 principle-*
23poteto-mode 下的 playbook
3,600 词每个子代理都要读一遍的 poteto-mode
~2118 天内的补丁版本（0.15.9 → 0.15.30）
1.4×唯一第三方样本里的成本倍数，通过率相同

分析查阅了镜像仓库与上游，用 bird 逐条阅读了 19 条相关推文，读了《The Complete Guide to pstack》两篇长文和最近两周她本人及其他用户关于 pstack 的推文，还看了她 9 月 21 日发在 X 上的演讲视频（原本是给 Cursor Compile London 准备的；转写由 Whisper 自动生成，专有名词可能不准）。推文日期按 UTC 记。产能、质量数字都是作者自述。

01先说结论

顺序比技能数量重要。没有第一步，后面的多代理流程只会更贵，不会更可信。

1

验证技能 + feature map

让代理能自己跑起并操作你的应用，截图取证。

管"对不对"
2

/poteto-mode

按任务类型路由到固定流程（playbook）。

管"好不好"：性能、代码质量
3

并行与自动合并

多代理、云代理、半夜自己合并。

前两步都有才谈得上

Lauren 在 Pt. 1 里就是这么排的。她在 9 月的演讲里分得更清楚：验证管"对不对"，pstack 管"好不好"，两样都有才够。那场演讲标题是 2,500 个 PR，但 pstack 只讲了一小段，她自己说"今天不多讲这个插件"，产能主要归到验证、给代理设计的架构和自动派活的外循环上。

对 Claude Code 用户，两件事要注意

评审退化

默认配置里的 Grok 在 Claude Code 里会被映射成"沿用父模型"，/arena、/architect、/interrogate 这些靠不同模型家族互评的流程，会变成同一家族自评。

上下文成本

/poteto-mode 本身约 3,600 个英文词，每个 poteto-agent 子代理都要完整读一遍。子代理越多，固定成本线性增加。值得用，但最好挑着用。

02来源链：谁在维护什么

一个原始版本，一个通用化镜像，中间隔着手动同步。

Lauren Tan @poteto · 作者 cursor/plugins/pstack 原始版本 · Cursor 插件 · 0.15.30 手动同步，有延迟 backnotprop/pstack Michael Ramos 的镜像 · 0.15.28 upstream 上游原样 main + 通用化改写 npx skills add … 经 Grok Bot / Cursor 安装 → 自动更新 经镜像安装（Claude Code、 Codex、Pi 等）→ 等维护者同步
为什么默认是 Grok React 团队 Cursor Agents Window 性能 SpaceX AI Grok Bot

Cursor 现在并入了 SpaceX AI。Grok 是她公司自己的模型，所以默认配置里 Claude 和 Grok 混用。这个组合首先反映她的工作环境，不一定适合其他宿主。

更新很快 10/04 · 0.15.9 10/22 · 0.15.30

18 天二十来个补丁版本。对试用是好事；对把它固化进团队流程的人是个提醒：技能文本随时在变，评测结果也会跟着变。镜像的 MIRROR.md 写明冲突时"保留 Cursor 的新含义，再套用通用措辞"，镜像要等维护者手动同步。

03仓库结构

56 个技能、23 个 playbook、两个代理定义（poteto-agent、comment-sicko）、一套只适用于 Cursor 的 Benny 自动化、10 章指南，MIT 许可。

每次进上下文的文本量（英文词） 全部 SKILL.md + playbook 合计约 49,500 词，不会一次全读
poteto-mode 每个子代理都要再读一遍；原则主文件只放索引，要求"应用哪个就完整读哪个"；playbook 按任务类型选中后才读。
固定上下文随子代理数线性增长
只算 poteto-mode 本身：主会话一次，加上每个 poteto-agent 子代理一次，每次约 3,600 词。

poteto-mode 里值得注意的硬规则

先跑后问

要问用户"选哪个方案"之前，先判断能不能靠跑一下得到答案；能的话走 Prototype playbook 去试。

先说数据结构

任何代码先说出数据结构；跨函数边界的改动先走 /architect。

关卡

提交前过 deslop，review 前过 /no-comments。

防糊弄设计：答复里要点名哪个原则改变了哪个决定，而且只能点名本会话里真读过的原则。

04两篇长文中的方法

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

Pt. 1 · 8 月 31 日

验证是一切的前提

她把验证技能当作"关键基础设施"，甚至建议给它排 oncall。

① 小 CLI 而不是临时脚本。对应原则 Build the Lever。应有的特征：

可组合破坏性命令带 --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 从历史会话捞上下文。

原型代替长文档。她反对对抽象计划做对抗式评审：代理会臆想风险、为不会发生的边界情况设防。替代做法：

2–3 个变体 截图测量 /architect多家族出签名 交叉评判→实现

设计错了就推倒。真要计划文档，就用 multi-phase-plan playbook，每项以"实际运行验证过"为完成标准，用 check-plan.mjs 查格式；大项目的计划临时提交进仓库，做完就删。

05在 Claude Code 里实际会发生什么

依据镜像加的映射表 docs/harness/claude-code.md。

能力Cursor（设计目标）Claude Code（映射后）
多模型评审评审团一个 Claude、一个 Grok：代码类 grok-4.7-xhigh-fast，判断和写作 claude-opus-5-5-xhigh→非 Claude 模型"省略 model，沿用会话模型"，Grok 写成 inherit-parent；两个席位同一家族
并行云代理：每个代理一台机器、录屏截图、半夜自己合并→environment: "cloud" 换成 isolation: "worktree"；她本人劝别用，本地大概十个到头
技能互调原生调用→55 个技能禁止模型自动调用，Skill 工具会拒绝；改为直接 Read 对应 SKILL.md，多一步、多吃上下文
Cursor 专有Automations、Bugbot、云代理面板；/maintain-verification-skill 每日自动跑→一行 "Skipped in Claude Code"；每日维护要自己用 cron 等调度补
外循环Grok Bot 接 Slack、Datadog、Sentry、PlanetScale；routines 订阅线程和告警，自动派云代理复现 bug、开 PR→pstack 不提供，Claude Code 也没有现成对应物，要自己搭
评审团席位：同一提示，换一个模型 Cursor Claude Code Claude Grok 两家一致 → 强信号 inherit-parent Claude Claude 同一家族自评，信号打折
poteto-mode 自己写着"第二意见是同一提示换一个模型，一致才是强信号"。要找回多样性，得让子代理调用外部 CLI（Codex、Gemini 等），pstack 本身不提供。

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

两层成本：固定上下文 × 子代理数量。

@dwkim601 的对比
claude-sonnet-5-5 · 5 个带隐藏测试的小任务
两组都是 15/15 通过。他自己也说任务太简单，说明不了难题上的效果。原推
成本来自哪

Lauren 说成本主要来自大量子代理，建议跑 /setup-pstack 选预算，并在会话开头告诉代理别开大规模 swarm。

注意：预算档位只调推理强度（max / xhigh / high / medium），不减少子代理个数。

样本很小，但方向和直觉一致：简单任务上 pstack 主要是额外成本，收益要到需要复现、验证、设计取舍的任务上才可能体现。Lauren 说她对自己的技能做评测，还说过一次精简 10% 且行为无损，但没有公开评测数据。

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

07推文里的工程判断

被纠正时，从最硬的一层修起。

把反复纠正变成结构：四级顺序

1
架构 / 数据结构根除
让错误在类别上不可能发生
2
lint 或测试，CI 拦截
机器强制，不靠记性
3
技能或规则
代理多数时候会遵守，但可能漏读
4
人工 review
她标成 "ngmi"

/correct 回看代理反复犯的错，用架构、类型和检查去修。她给过一段可以直接用的提示词：让代理翻历史提交找常见陷阱，用原型回答自己的开放问题，带着数据回来给人审。

Dune：让捷径就是正确的路

Grok Bot 的客户端框架，演讲里最具体的例子。代价是人写起来很难受；好处是上下文很少的代理，或者设计师、PM 驾驶的代理，默认也能写对。

原则 1

删掉已有技术债。

原则 2

每件事只留一种写法，用 CI 和 lint 引着代理走，不让它猜。

原则 3

看到坏模式先写 lint 止血，之后再让代理清理，代码库始终处在"代理照抄也没问题"的状态。

落地例子：用导入依赖图隔开 Electron 主进程和渲染进程 主进程 main 慢代码 IO / 重计算 渲染进程 renderer 每帧预算 16ms · 60fps 8ms · 120fps 不能有长任务 依赖图检查：禁止跨界导入
Cursor Agents Window 出过慢代码被误引入渲染线程的问题。她强调重点不在 Dune 本身，而在于把原本散在 code review 评论里的经验写进框架。
删注释

她主张禁止并删除大部分代码注释：代理爱模仿现有代码，一条解释临时绕过方案的注释会被当成模板扩散。演讲里给了起因：在 Cursor 代码库里，代理拿周围的注释当理由，不去解决根本问题，贴个补丁了事。所以 Dune 直接禁止写注释。

/no-comments 会保留解释浏览器怪癖这类必要注释。立场有争议，她在回复里承认不是非黑即白。

验证是近似

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

形式化验证 · beta

/create-formal-verification-skill 只有 41 行：先挑单元测试够不着、出错代价高的性质；事件顺序默认 TLA+；没有验证器就明说，改用生成输入测真实代码；每个性质都要在故意改坏的版本上失败过。上游 10 月 19 日补了 TLA+ 默认值和回退，又加了 maintain-formal-verification-skill。

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

08社区反应

最近两周以称赞为主，批评集中在细节。

"pstack is the new solid"
Taylor Otwell
原则里有"非常重要的智慧"
Uncle Bob
移植

有人移植到 DeepSeek Harness 和 Codex。

细节批评

有设计师不满 /unslop 要求把弯引号换成直引号。

速度

有用户说 Grok Bot 加云代理多数时候很慢，需要人在环路里时宁可开 CLI 自己引导。

最后这条和 Lauren 自己说的"开头给足方向，之后放手"其实是一回事。

09怎么用

挑着装，先打地基。

  1. 先不装全套

    Lauren 自己建议从零技能开始观察失败模式。镜像 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. 固定版本

    镜像和上游都改得快。团队使用时记下提交号，升级前用自己的几个代表任务对比一下。

10我的判断

最能直接带走的三样东西，都不依赖 Cursor，也不需要装全套技能。

1

验证 CLI + feature map这套做法。

2

"能跑出答案的问题不要问人"这条路由规则。

3

把反复纠正沉淀成架构和 lint的习惯。

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

下一步

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