pstack 蓝皮书

37Flow 整理 · 非官方 · 2026-10-05

本文是一份综述文档。内容以官方仓库（cursor/plugins 下的 pstack/）、官方指南十章、作者 poteto（Lauren Tan）的长文为第一手依据，再参考中文镜像站、日文深读与社区实践帖。凡是来自社区、尚未被官方确认的说法，正文都会标注「社区报告」或「社区说法」。

文中时间默认使用北京时间（UTC+8）。引用 GitHub 提交时间时，原始值为 UTC，已换算。

我们在 2026-10-05 当天直接读取过官方仓库 main 分支的 README、指南十章目录、plugin.json、skills/ 与 agents/ 目录；其余来源以引用日期为准。

阅读指引

1. 执行摘要

一句话： pstack 是 Cursor 工程师、React Core 团队成员 poteto（Lauren Tan）发布在 Cursor 官方插件仓库中的一套 skills 栈。它的目标不是让 AI 写更多代码，而是让 AI 少写、写好、并且能证明写对了，从而让你敢于同时开多个 agent 并行干活。

核心要点：

1. 定位。 pstack 是 Cursor 插件（marketplace plugin，内含 skills 与 subagent 定义），不是 VS Code 扩展，也不是 npm / pip 包。官方安装方式只有在 Cursor 对话里运行 /add-plugin pstack。来源：官方 README、Cursor Marketplace 页面。
2. 入口只有一个：/poteto-mode。 你只需要说清「目标」和「怎么算完成」，它会从 23 个 playbook 里挑一个，把步骤原样抄进 todo 列表，再按步骤调用其他 skill。官方明确反对你在提示词里手动列出一串 skill。
3. 两步上手。 先 /setup-pstack 选推理预算和各角色模型（写入 ~/.cursor/rules/pstack-models.mdc），再在任何需要严谨的任务前加 /poteto-mode。不知道用什么时，问 /poteto-help。
4. 规模。 截至 2026-10-05 官方 main 分支：23 个 playbook；27 个面向用户的 skill（含 poteto-mode、poteto-help）；24 条原则（principle，每条是一个独立 skill）；2 个 subagent 定义（poteto-agent、Comment Sicko）。
5. 版本。 官方 plugin.json 当前为 0.15.10（新增 /poteto-help，提交 4e5b1cf，2026-10-05 14:36 UTC+8）。中文镜像站 learn-pstack（pstack.ganhai.cloud）在 2026-10-04 的整理覆盖到 0.15.9。0.15.6 到 0.15.9 集中在 2026-10-03 至 10-04 发布：Explain the Number 原则与 /benchmark-checklist、/correct、/architect 加强、性能「七句口诀」。
6. 默认模型分工。 官方 README（2026-10-05 读取）：代码类委派（feature、refactoring、bug fix、perf、hillclimb）交给 Grok，最难的改动、文字和判断交给 Opus 5.5。默认评审面板是 Opus 5.5 / Sol / Grok。都可以用 /setup-pstack 改。
7. 生态。 社区已经把 pstack 移植到 Claude Code、Codex、OpenCode、Gemini、Pi 等环境。最大的移植仓库是 michael-denyer/pstack-claude（约 1300★，社区数据）。移植版普遍会落后上游，且非官方维护。
8. 主要争议。 社区反馈集中在三点：token 消耗大、Cursor 外环境安装麻烦、移植版跟不上上游更新速度。

给 37Flow 的建议： 如果主力环境是 Cursor，直接用官方版，读完官方十章指南，从小而真实的任务开始。如果主力是 Claude Code 或 Codex，可以试用社区移植版，但要钉住 tag 或 commit SHA，并定期对照上游。

2. pstack 是什么与设计哲学

2.1 作者与来历

pstack 的作者是 poteto（Lauren Tan）。她在官方 README 中自述：在 Meta、Netflix、Cursor 接触过数百万行代码，也是 React Core 团队成员，参与构建和维护 React Compiler。pstack 被描述为「我每天在 Cursor 用来交付高质量代码的同一批 skills」。

代码位于 Cursor 官方插件仓库 cursor/plugins 的 pstack/ 目录，许可证为 MIT，作者鼓励 fork、改进和提交 PR（来源：官方 README，2026-10-05 读取）。

2.2 要解决的问题：「AI slop」

README 开篇点明动机：越来越多人觉得 AI 写了太多「slop」（敷衍、冗余、未经验证的代码）。作者同意这一点，并表示不想「像二十个 slop 艺术家组成的团队那样交付」。她的立场是：

没有质量的吞吐量，不是值得追求的目标。如果你想走得快，先走得深。（意译自 README：”if you want to go fast, go deep first.”）

这句话也写进了 plugin.json 的描述字段，可以视为 pstack 的总纲。

2.3 三根支柱

官方 README 把 pstack 的价值归纳为三点，我们用中文重述：

1. 少写，但写得更好。 目标不是最大化代码行数，反而相反。原则里排在最前面的「Laziness Protocol（懒惰协议）」就要求优先删除、优先最小改动。
2. 无畏的并行（fearless parallelism）。 只有当你能信任一个 agent 写出高质量、可验证的代码时，才敢同时开很多个。pstack 的严谨性是并行的前提，不是并行的代价。
3. 多模型各取所长。 Cursor 可以接入多家前沿模型，pstack 的许多 skill 故意用多模型工作流：例如 /interrogate 让几个不同模型分别尝试攻破同一个 diff，/arena 让多个模型对同一题目各给一个方案再合并。

2.4 架构分层：mode → playbook → skill → principle

理解 pstack，最重要的是看清它的四层结构：

另外还有 subagent（子代理） 定义：poteto-agent 是 poteto-mode 派出子任务时的标准执行者；Comment Sicko 是 /no-comments 召唤的「注释清道夫」。详见第 5 章。

2.5 设计哲学的几个关键词

• 证据优先。 官方指南第 10 章把「凭一个绿色的 build 就报告成功」列为典型错误：build 只证明能编译。pstack 要求展示真实命令输出、真实流程、真实写入的数据或性能 profile。2026-09-10（UTC+8）的提交 f8abedd 标题就是「every claim carries its evidence or its label」（每个结论都要带证据或标签）。
• 可审计。 跳过的步骤不会消失，而是留在 todo 列表里，标注 skip: <原因>。长任务有 /show-me-your-work 决策日志（TSV，可提交进仓库）。
• 结构优于说教。 原则「Encode Lessons in Structure」与 0.15.7 新增的 /correct 都主张：同类错误反复出现时，优先用架构、类型、lint、CI、测试来防止，文档放最后。
• 不阻塞人。 原则「Never Block on the Human」要求 agent 对可逆的决定直接推进，而不是停下来等你确认。这是能「睡前布置、早上验收」的基础。
• 用名字导航。 24 条原则各有一个短名，你可以在对话中用一句「apply prove it works」精确纠偏，比写一段长说明更有效（官方指南第 8 章）。

2.6 它不是什么

• 不是代码生成器或模板库。
• 不是独立 CLI 工具，离开 Cursor（或社区移植的宿主）就无法运行。
• 不是「装上就变聪明」的开关。它依赖你给出可检查的完成条件，否则 /loop 和 autonomous run 没有可以判断的终点。

3. 安装与环境配置

本章依据官方指南第 1 章 01-setup 和中文镜像 learn-pstack 01-setup 中文版。

3.1 第一步：安装插件 /add-plugin

在 Cursor 的对话框里输入：

/add-plugin pstack

Cursor 会提示插件已安装。也可以在 Cursor Marketplace 的 pstack 页面 查看介绍和版本。

版本提示：2026-10-05 读取到的官方 plugin.json 版本为 0.15.10。部分用户的 Marketplace 页面可能已显示 0.15.10 并带有 /poteto-help，也有人仍停留在 0.15.9。版本号以你本地插件信息为准，不确定时可以直接输入 /poteto-help 看看是否存在。

3.2 第二步：选择模型 /setup-pstack

/setup-pstack

它会依次做这些事：

1. 检测你账号可用的模型；
2. 询问推理预算（reasoning budget）；
3. 逐个展示角色：代码委派（code delegates）、判断（judgment）、各类评审面板（review panels）、swarm workers；
4. 按你的回答写入配置文件。

3.3 配置文件 ~/.cursor/rules/pstack-models.mdc

/setup-pstack 会写入 ~/.cursor/rules/pstack-models.mdc，这是一个所有 pstack skill 都会读取的小规则文件。几条规则需要记住：

• 只覆盖你在意的。 文件里没有写某个角色，就用该 skill 的默认值。
• 恢复默认： 删除该角色那一行即可。
• 重跑 /setup-pstack： 会保留那些已经被你改成非默认模型的角色。
• 旧版本遗留： 0.15.3 之前写出的规则会把旧的默认模型钉死。要么删掉这些角色行，要么删掉整个文件，再重新运行 /setup-pstack。
• 生效时机： 配置完成后要新开一个对话，模型规则只对新会话生效。

3.4 auto 与 inherit-parent

如果你习惯用 Cursor 的 Auto 模型，可以把某个角色设为 inherit-parent 或 auto。官方说明：

• 两个值含义完全相同；
• 两者都不是模型名（slug）；
• 效果是 pstack 在派生子代理时省略 model 字段，让子代理继承父对话的模型。

对于「面板类」角色（例如评审面板），值是一个列表，每一项启动一个子代理，列表长度就是面板人数。官方指南第 10 章把「把 auto 当作模型 slug」列为常见误区。

示例（示意，具体字段以 /setup-pstack 实际生成为准）：

code delegates: inherit-parent
review panel: [opus-5.5, sol, grok]
swarm workers: auto

3.5 让 poteto-mode「常驻」：Custom Mode（sticky）

普通方式是在消息开头写 /poteto-mode，按 Enter 发送，这只会把 skill 附加到这一条消息上，后续对话中会逐渐淡出。

要让它整场对话常驻：在 / 菜单里选中 poteto-mode 时，按 Option+Enter（Mac） 或 Alt+Enter（Windows）。这会把它变成 Cursor 的 Custom Mode：

• 每一轮都留在上下文里；
• 遇到匹配的 playbook 或需要严谨的任务时自动套用，其他时候不打扰；
• Custom Mode 在 Agents Window 和 CLI 中可用；
• 想临时不用，直接说明即可；想关闭，退出该模式。

3.6 验证能力的「要约」：verify skill

/setup-pstack 收尾时会检查项目里是否有办法证明应用行为：要么已有 verify-* skill，要么已有测试或驱动框架。如果都没有，它会只提议一次用 /create-verification-skill 生成一个。

• 同意： 会写入 .cursor/skills/verify-<app>/，这是一个项目本地 skill，教 agent 像真实用户一样驱动你的应用。交付前它会先实际跑通一次。
• 拒绝： setup 继续，之后你随时可以手动运行 /create-verification-skill。

作者在《完整指南 Pt.1》中把「验证」放在最核心的位置（详见第 8 章）。我们的建议：对于有 UI 或有端到端流程的项目，第一次就接受这个要约。

3.7 跑第一个任务

官方推荐用一个「真实但小」的任务试水，像对同事一样描述：

/poteto-mode add a --json flag to this command. text output stays byte-identical. verify both.

中文环境也可以直接用中文写：

/poteto-mode 给这个命令加一个 --json 参数。原有文本输出要逐字节保持不变。两种输出都要验证。

观察 todo 列表：前几项就是 Feature playbook 的步骤，被原样抄进来。被跳过的步骤显示 skip: <原因>。

3.8 安装检查清单

• [ ] /add-plugin pstack 成功
• [ ] /setup-pstack 完成，~/.cursor/rules/pstack-models.mdc 已存在
• [ ] 如有 0.15.3 之前的旧规则，已清理
• [ ] 已决定是否接受 verify skill 要约
• [ ] 已新开对话
• [ ] 已学会用 Option/Alt+Enter 开启 Custom Mode
• [ ] /poteto-help 可用（0.15.10 及以上）

4. poteto-mode 核心用法

本章依据官方指南第 2 章 02-poteto-mode 与第 10 章 10-recipes-and-pitfalls。

4.1 poteto-mode 被调用时做了什么

1. 读取原则索引（Principles section）；
2. 把你的任务匹配到一个 playbook，打开 todo 列表，前几项是该 playbook 的步骤（原样复制）；
3. 按步骤触发其他 skill；
4. 用去除 AI 腔（unslopped）的方式回复，兼顾「使用者」与「维护者」两种读者。

官方给出的路由示意：只读问题 → Investigation；缺陷 → Bug fix；新行为 → Feature；只改结构 → Refactoring；可测量的慢 → Perf issue；大任务或没有匹配 → /figure-it-out。所有分支最后都汇到「验证并报告」。

4.2 黄金法则：目标 + 可检查的完成条件

官方指南首页说，如果只记一件事，就记这个：

用你自己的话，给 agent 一个目标，以及一个检查它的方法。

/poteto-mode the export writes duplicate rows when a retry lands mid-run. repro first, then fix and verify.

你不需要说出 playbook 名，也不需要列 skill。「repro first（先复现）」加上一个可以检查的结果，就足够 poteto-mode 路由到 Bug fix。

什么是「可检查」？ 一个能通过或失败的命令、产物或观察：

4.3 禁止手动列出 skills

官方在第 2 章和第 10 章两次强调：

陷阱： 不要在提示词里枚举 skill（比如「先用 /how，再 /architect，再 /arena……」）。playbook 已经排好了顺序，手写的顺序通常会打乱或丢掉 playbook 本来会保留的步骤。只有在你想覆盖某个具体选择时，才点名一个 skill。

反例与正例：

❌ /poteto-mode 先用 /how 看一下，然后 /why，然后 /architect，然后 /arena 出三个方案，然后 /tdd，最后 /interrogate。
✅ /poteto-mode 导出任务在重试时会写重复行。先复现，再修复并验证。
✅ /poteto-mode 导出任务在重试时会写重复行。先复现；如果有便宜的测试路径就 /tdd。

最后一条之所以可以点名 /tdd，是因为你在表达一个覆盖性偏好，并且附带了条件（「如果有便宜的测试路径」）。官方指出这个条件很重要：靠脆弱的 mock 硬写测试，证明力不如直接跑真实命令。

4.4 Playbook 与 Skill 的区别

可以这样理解：playbook 是菜谱，skill 是厨具，principle 是厨房守则。 你只需要点菜，厨师会按菜谱拿厨具。

4.5 Sticky：Custom Mode 下的极简提示

当上下文已经齐全，并且 poteto-mode 以 Custom Mode 常驻时，提示词可以短到几个字：

/poteto-mode do it

continue

keep going until done

能这么短，是因为 playbook 承载了结构，Custom Mode 让 poteto-mode 每轮都在。你的话负责意图，skill 负责严谨。

4.6 换任务时说「new task」

长对话会积累上一个任务的上下文。换主题时要明说：

/poteto-mode new task. figure out why the cache entry survives logout. don't change any code yet.

• 「new task」让 poteto-mode 重新匹配 playbook，而不是继续上一个；
• 「don’t change any code yet」把它钉在只读的 Investigation。

不说这两句，一个正在做 Feature 的 mode 很可能把你的问题当成下一步功能。

4.7 并行工作：每个任务一个 worktree

多个 agent 同时操作一个仓库会互相覆盖文件。提前要求隔离：

/poteto-mode new task. branch off <base> in a fresh worktree, then port the parser change there.

Opening a PR playbook 本身就会为代码改动使用 worktree，所以通常只有在你对 base 或位置有特殊要求时才需要说。worktree 多了占磁盘，可以：

/poteto-mode what's eating my disk? prune the worktrees that are safe to prune.

Worktree cleanup playbook 会按合并状态、未提交改动、哪些对话仍在使用来分类，只删证据允许删的；有未提交改动的会停下来等你决定。

社区报告：@zbeyens 认为去掉 worktree 能省下约一半 token（见第 8 章）。这和官方建议存在张力：worktree 带来隔离，但也带来额外开销。单 agent 场景可以考虑不用，多 agent 并行时官方建议保留。

4.8 离开时让它继续跑

/poteto-mode im stepping away. keep going until the migration check reports zero old callers. log your decisions.

需要你事后审阅的工作会被路由到 /figure-it-out，它会设计执行阶段，并用 /show-me-your-work 记录决策日志。完整的「过夜契约」见官方指南第 7 章 07-overnight。poteto-mode 和 Cursor 的 /loop 命令配合效果很好，可以让 Cursor 连续工作数小时而不牺牲严谨性（官方 README）。

4.9 中途纠偏：一句话就够

i said the goal is to repro. i did not ask for a fix yet.

apply prove it works. show me the real output, not the build log.

use subtract before you add. delete the obsolete adapters first, then design what's left.

separate before serializing shared state. give each attempt its own worktree, no locks.

/unslop that, no emdashes

/bro

4.10 提示词示例库（中英对照）

（英文原文见官方 README 的 examples 区。中文写法同样可用，skill 读的是意图。）

5. 全部 playbook 与 skills 详解

数据来源：官方 README 与 skills/ 目录，2026-10-05 读取。中文说明为本文意译。

5.1 23 个 playbook 总表

怎么选不用你操心。 但了解这张表能帮你写出更好的触发语：说「repro」偏向 Bug fix，说「trace」偏向 Perf / Trace forensics，说「两个原型对比」偏向 Prototype，说「我去睡了」偏向 Autonomous run。

关于 Fable：在 2026-09-01 的版本里，Fable 5.1 被设为默认（中文镜像记录为 PR 301）。之后 2026-09-23 的提交 70b2dc8 把默认改为 Opus 5.5 和 Grok 4.7。社区有人（@zbeyens）建议关掉 Fable。详见第 6、8 章。

5.2 主要 skill 详解

下面按官方指南的章节逻辑分组：理解 → 设计 → 构建与清理 → 验证 → 自我定制 → 沟通与写作。

5.2.1 理解代码：/how、/why、/teach、/recall

/how：讲清楚一个子系统怎么工作。

/how do we cancel runs? do we have an n+1 when we look up every run to cancel?

适合进入陌生代码前使用。报告会说明它搜索了哪些来源，你能判断结论的依据。

/why：为什么这样设计。 运行时会发现当前可用的 MCP，并行查询各类证据：源码管理、issue 跟踪、长文档、实时聊天、基础设施监控、错误追踪、分析数据仓库。

/why is this feature flag not on yet?

官方配方：先机制，后历史。

use /how first to understand how this initialization works. then use /why to figure out why it broke recently.

/teach：真正理解，而不只是摘要。 同时运行 how 和 why，把结果编织成一份通俗讲解，一张图一张图地搭建起来。适合新人入职或评审复杂改动。

/recall：重建你的近期上下文。 开始或恢复工作时，从你自己的聊天记录和共享记录里，重建某个主题的近况，交回一份精炼的现状简报。

5.2.2 设计变更：/architect、/arena、/swarm、/interrogate

/architect：先定形状再写代码。 当代码要跨越函数边界时，先确定调用方用法、类型和模块形状。0.15.8（提交 a586282）加强了它，让设计「能抵抗 agent 常犯的错误」。

design this instrumentation to be high signal with no false positives. /architect this first.

/arena：同一题目，N 份答卷，取其精华。 把同一份设计或代码简报交给多个并行尝试，然后选一个作为基底，把其他方案的优点嫁接进来。

/arena take my prompt to the arena verbatim. i want to compare their proposals with yours.

ask /arena for a second opinion on this thread and our approach

你当前的设计会成为候选之一，最终综合会告诉你：面板是否找到更好的方案，还是确认了你的方案。官方称之为「昂贵承诺前的便宜保险」。

/swarm：分片并行，汇总一份报告。 N 个 worker 各负责一个切片（或一个声明好的竞速分支），父代理等所有切片完成，返回一份 PASS / ISSUES / BLOCKED 报告，而不是一堆原始输出。

/swarm check every package under packages/ against its check.sh. one worker per package. one report.

易混点： /arena 是为了比较（同一题多解），/swarm 是为了覆盖（不同切片）。官方指南把「用 /arena 做覆盖」列为陷阱。

/interrogate：让几个不同模型尝试攻破你的 diff。 包含一个严格的代码质量视角。发现会被分为「Act on（需处理）」和「dismissed（已驳回，附理由）」，你可以推翻任一判断。

/interrogate the whole branch, but skeptically. don't change anything yet. no nitpicks unless it's an actual bug or regression in behavior.

限定语有实际作用：「don’t change anything yet」保持只读，「no nitpicks」预先过滤噪音。

/blast-radius：小改动的影响面。 一个看起来很小的改动可能牵连什么？它会用运行代码来证明「这个改动安全，因为某个事实」，而不是口头断言。

5.2.3 构建与清理：/tdd、/unslop、/no-comments、/typescript-best-practices

/tdd： 修 bug 且有便宜的本地测试路径时，先写失败测试，再修。

/unslop： 清理文字中的 AI 腔。也会被 poteto-mode 用于自己的回复。

can we unslop and tighten the new changes?

/no-comments： 评审前去掉注释。它会召唤 Comment Sicko 子代理，修复被接受的发现，并对注释里声称的约束提供「编码化」方案（用类型、命名、结构表达，而不是靠注释）。

/typescript-best-practices： 读写 TypeScript 时使用，把 Type System Discipline 原则落到具体语法。

5.2.4 验证：/create-verification-skill、/maintain-verification-skill、/benchmark-checklist

/create-verification-skill： 项目没有脚本化的方式证明应用行为时使用。生成一个项目本地的 verify skill，附带 Feature Map（功能地图），支持任何语言或平台。作者在 Pt.1 中重点讲了这一点。

/maintain-verification-skill： verify skill 的功能地图和应用实际情况有偏差时使用。先扫一遍源码，再做一次真实运行，最多提交一个 PR 的已证实修正。

/benchmark-checklist（0.15.6 新增）： 跑完基准、测出加速或退化后使用。在你报告或据此行动前，检查这个数字：瓶颈是什么、调优是否到位、有无错误、是否重复运行、与端到端是否相关。它是原则 Explain the Number 的配套工具。

5.2.5 让它适应你：/setup-pstack、/automate-me、/reflect、/correct、/figure-it-out、/show-me-your-work

/setup-pstack： 见第 3 章。

/automate-me： 根据你实际的工作方式，起草一个属于你自己的 -mode skill。官方指南第 9 章 09-make-it-yours 详述。

/reflect： 一个长任务落地后，把这次的「配方」沉淀成 skill 的修改。

/correct（0.15.7 新增，提交 9511e60）： 当你反复为同类错误纠正 agent 时使用。它挖掘历史记录，归纳错误类别，然后在能起作用的最高层级修复：先架构，再类型、lint 和 CI，再测试，文档最后。它还维护一张表，把每条规则和执行它的机制配对。

/figure-it-out： 没有现成 playbook 匹配时，为该任务设计一个严谨、可审计的 playbook。

/show-me-your-work： 需要可审阅的决策轨迹时使用。把决策记录到一个 TSV 文件，可以提交进仓库。

5.2.6 帮助、沟通与写作：/poteto-help、/bro、/technical-writing、/make-bot-ui

/poteto-help（0.15.10 新增，提交 4e5b1cf，2026-10-05）： 新手入口。先弄清你想做什么，回答那部分问题，再给你一段可以直接输入的提示词。当你问「pstack 怎么用」时也会自动加载。

/poteto-help 我想让 agent 帮我查一个只在生产环境出现的内存泄漏，该用哪个？

/bro： 把上一条回复用大白话重说一遍，没有术语，更短。整条提示就是 /bro。

/technical-writing： 分层文档标准（Diátaxis + Google 开发者文档风格 + STE 简化技术英语 + Global English），用于文档、RFC、README、PR 描述、commit message。

/make-bot-ui： 做一个页面或仪表盘，上面的按钮通过 webhook 唤醒 bot，包括 sender-key 交接和 Tailscale 配置。属于较小众的场景。

5.3 Skill 速查表

5.4 24 条原则概览

官方指南第 8 章 08-principles：每条原则是一个独立 skill（目录名 principle-*）。poteto-mode 在每个多步任务开头读取索引，套用被触发的原则，并在回复里写出应用了哪条原则，以及它改变了哪个决定。只引用原则名、说不出改变了什么，就是「名字空投（name-drop）」的信号。

核心原则（做多少、何时重想设计）：

架构原则（状态、校验、兼容性放在哪）： Model the Domain（建模领域）、Boundary Discipline（边界纪律：在边界校验，内部信任类型）、Type System Discipline（让非法状态无法表示）、Make Operations Idempotent（操作幂等）、Migrate Callers Then Delete Legacy APIs（迁移调用方后一次性删除旧 API）、Separate Before Serializing Shared State（先拆开共享，再考虑加协调）。

验证原则（什么算证据）： Prove It Works（验证真实产物而非代理指标）、Fix Root Causes（先复现、追到根因再改）、Sequence Work into Verifiable Units（每个小单元以检查结束）、Test Behavior, Not Implementation（像用户一样调用，断言字面期望值；如果所有导入函数都返回 undefined 测试还能通过，就删掉它）、Explain the Number（0.15.6 新增：在信任或报告一个测量数字之前，说出限制它的因素，并排除它测的其实是别的东西）。

委派原则（让并行保持理智）： Guard the Context Window（大量阅读交给子代理，主对话只保留结论）、Never Block on the Human（可逆决定直接推进）、Encode Lessons in Structure（把教训写进结构）等。

完整清单以仓库 skills/principle-* 目录为准，2026-10-05 读取到 24 个。

5.5 Subagent：poteto-agent 与 Comment Sicko

仓库 pstack/agents/ 下有两个子代理定义：

poteto-agent

• poteto-mode 和「任何想要 poteto 风格的请求」的路由目标；
• 每个新任务派一个全新的 poteto-agent，只在 poteto-mode 的 Subagents 部分列明的严格条件下才复用旧的（0.15.6 提交信息中提到「fresh subagents」）；
• 开工前必须完整读取 poteto-mode 的 SKILL.md，包括内嵌的原则索引；
• 官方明确提示：用通用子代理（generalPurpose）替代它会跳过这次读取，导致行为漂移。

Comment Sicko

• 自我设定是「一个疯狂憎恨注释、享受删除、谴责 workaround 代码的家伙」，被召唤时第一句固定是「Yes… Ha ha ha… Yes!」；
• 只放过这几类：法律/许可证头；由无法改变的外部依赖、平台、供应商或协议导致的非显然行为；// prettier-ignore；定义公共 API 契约的文档注释；解释代码无法表达之约束的 issue / RFC 链接；
• 对我们自己代码里的「意外」不留情：删注释，并把对应符号标为 MUST KILL，要求通过改名、抽取、类型或重新架构让行为不言自明；
• 对 eslint-disable、@ts-ignore 等抑制：先查规则，如果规则能抓真实 bug 或保护正确性，就删掉抑制；
• 「IMPORTANT」「do not remove」「too risky」「fine for now」这类词只是线索，不是定论。

这种拟人化的设计很有 poteto 的风格：用强烈的角色设定，让模型在一个窄任务上更彻底。

6. 版本演进 0.15.6–0.15.9（及前后节点）

说明： 以下内容以官方仓库 pstack/.cursor-plugin/plugin.json 的提交历史（2026-10-05 读取，时间已从 UTC 换算为 UTC+8）为主，并对照中文镜像 learn-pstack 0.15.9 发布页。learn-pstack 在 2026-10-04 的整理覆盖到 0.15.9。0.15.10 目前只有提交记录，我们只陈述提交标题，不推测未公开的更新日志。

6.1 时间线总览

用户口径中常说「0.15.6–0.15.9 于 2026-10-04 发布」。按提交时间，0.15.6 实际在 10-03（UTC+8）合入，0.15.7–0.15.9 在 10-04 凌晨到早上合入。中文镜像在 10-04 统一整理。两种说法并不矛盾。

6.2 0.15.6：Explain the Number 与 /benchmark-checklist

核心变化： 新增第 24 条原则 Explain the Number，并配套 /benchmark-checklist skill。

解决的问题： agent 很容易报告「快了 40%」，但这个数字可能来自缓存预热、测量了错误的路径、只跑了一次、或者瓶颈根本不在被优化的地方。

原则要求： 在信任或报告一个测量数字之前，说出限制它的因素（limiter），并排除它测的是别的东西的可能。

/benchmark-checklist 检查项： 瓶颈（limiter）、调优（tuning）、错误（errors）、重复运行（repeat runs）、端到端相关性（end-to-end relevance）。

同版本其他变化（据提交标题）：子代理每次新建（fresh subagents）、autopilot 每小时状态 tick、PR 标题规范、schema-first cast（先定 schema 再做类型转换）。

使用示例：

/benchmark-checklist 我刚测出新序列化器比旧的快 3 倍，先帮我审一下这个数字能不能报。

6.3 0.15.7：/correct

核心变化： 新增 /correct skill。

设计思路： 如果你总是在为同一类错误纠正 agent，说明问题不该靠「下次记得」解决。/correct 会：

1. 从历史中挖掘错误类别；
2. 对每一类在「能起作用的最高层级」修复，优先级为：架构 → 类型、lint、CI → 测试 → 文档；
3. 维护一张「规则 ↔ 执行机制」对照表。

这是原则 Encode Lessons in Structure 的工具化。

6.4 0.15.8：/architect 加强

核心变化： 提交标题为「make /architect designs resist agent mistakes」。

理解： /architect 原本负责在跨函数边界前定好调用方用法、类型和模块形状。0.15.8 的方向是让这些设计本身就能防住 agent 后续实现时常犯的错误，例如用类型让错误用法无法编译，而不是靠实现者小心。具体条目请以仓库中 skills/architect/SKILL.md 当前内容为准。

6.5 0.15.9：性能「七句口诀」（e43c7ee）

核心变化： 提交 e43c7ee「use bare performance mantras in perf-issue step 2」，在 Perf playbook 第 2 步改用简短的性能口诀。中文镜像把它整理为「性能七句口诀」。

意义： 与其给 agent 一大段性能优化指南，不如给几句短而硬的口诀，模型更容易在每一步真正对照执行。口诀原文请看 learn-pstack 0.15.9 发布页 或仓库 skills/poteto-mode/playbooks/perf-issue.md。本文不转述具体七句，以免与原文出现偏差。

6.6 0.15.10：/poteto-help（仅据提交）

2026-10-05 14:36（UTC+8）合入的 4e5b1cf 新增 /poteto-help，plugin.json 版本为 0.15.10，官方 README 与指南首页都已经引用它。部分安装环境的 Marketplace 已显示 0.15.10。截至本文写作时，learn-pstack 尚未发布 0.15.10 的整理页，本文也不补写未公开的更新日志。

6.7 演进趋势解读（37Flow 观点）

1. 从「多给指令」到「少给指令」。 9 月下旬删掉 19 条 Opus 5.5 不需要的指令，0.15.9 改用口诀。随着模型能力提升，作者在主动瘦身 prompt。
2. 从「做事」到「审数字、审错误」。 Explain the Number、/benchmark-checklist、/correct 都在补「验证与反思」这一环。
3. 降低上手门槛。 /poteto-help 说明官方意识到 27 个 skill 加 23 个 playbook 对新手太多。
4. 迭代非常快。 3 天 5 个版本，这对移植维护者是压力（见第 9 章）。

7. 社区移植全景

总提醒： 以下全部为社区项目，不是 Cursor 或 poteto 官方维护。star 数、支持的 agent 列表都来自各项目自述或社区观察（约 2026-09 至 10 月），我们没有逐一验证每个宿主的可用性。使用前请阅读各仓库 README，并钉住 tag 或 commit SHA。

7.1 总览表

7.2 各宿主的典型用法（社区说法）

• Claude Code： 通过 pstack-claude 安装后，可以用 SessionStart hook 自动路由，或手动 /pstack:poteto-mode。@uehaj 报告每天在 Claude Code 中使用 pstack-claude（X 帖）。
• Codex： 开启 multi_agent；可以把常驻指令放进 ~/.codex/AGENTS.md。
• OpenCode： 把 skills 目录拷进配置目录后按名调用（oh-my-pstack 说明）。
• Gemini / Antigravity： @cpedia_1 在 2026-09-28/29 分享了 Antigravity + Gemini + pstack 的组合（社区报告）。
• Pi、Prime： 见 pstack-claude README。

7.3 移植版的固有局限

1. 多模型工作流会打折。 pstack 很多 skill（/interrogate、/arena、评审面板）依赖 Cursor 方便调用多家模型。单一厂商宿主中，「多模型互相攻击」可能退化成「同一个模型多次运行」。
2. subagent 语义不同。 poteto-agent 的 is_background、全新派生等行为依赖 Cursor 的子代理机制，其他宿主的实现各不相同。
3. Custom Mode 不一定存在。 sticky 行为在其他宿主中需要用 hook 或 AGENTS.md 模拟。
4. 版本滞后。 上游 3 天 5 个版本，移植版很难当天跟上。0.15.6 之后的 /benchmark-checklist、/correct、/poteto-help 在移植版中是否存在，需要逐个确认。
5. 营销与实际不符的风险。 声称支持十几个宿主的项目，需要你自己测试关键路径。

7.4 选型建议

8. 最佳实践

8.1 来自作者：《完整指南》上下篇

Pt.1（约 2026-09-01）：验证、Feature Map、cloud agents（中文：完整指南 Pt.1 中文版）

我们从中提炼的经验：

1. 验证是一切的地基。 没有「可以由 agent 自己跑的验证」，就谈不上放心并行，也谈不上过夜运行。所以 /setup-pstack 会主动提议生成 verify skill。
2. Feature Map（功能地图）。 verify skill 不只是一堆测试脚本，而是一张「这个应用有哪些功能、各怎么驱动、怎么判断正确」的地图。agent 改完代码后，可以对照地图去真实操作应用。
3. 地图会漂移。 应用在变，地图要跟着变，这就是 /maintain-verification-skill 的用途。
4. cloud agents。 有了可靠的验证，才适合把任务交给云端 agent 长时间运行。人只看证据，不看过程。

Pt.2（约 2026-09-10）：research、architect、prototype（中文：完整指南 Pt.2 中文版）

1. 先研究再动手。 /how、/why、/teach 是低成本的理解手段，比边改边猜便宜。
2. 先定形状。 /architect 在写代码前确定调用方视角的接口，代码一旦落地，形状就很难改。
3. 原型是用来扔的。 Prototype playbook 和 Exhaust the Design Space 原则鼓励做两三个竞争原型，用观察结果而不是争论来做决定。

How I Use Cursor（约 2026-08-23）（索引：from-poteto）介绍了作者的日常工作方式，是理解 pstack 动机的背景材料。

以上 Pt.1 / Pt.2 的要点为 37Flow 根据中文镜像的整理和归纳。细节和原话请以原文为准。

8.2 来自官方指南的十条习惯

1. 说目标，不说流程。
2. 完成条件必须可以通过或失败。
3. 不手列 skill，只在覆盖时点名。
4. 换任务说「new task」，只读时说「don’t change any code yet」。
5. 并行时每个尝试一个 worktree。
6. 不要接受所有评审意见，让 /interrogate 分类。
7. 不要把绿色 build 当作成功。
8. 不要手写 SKILL.md，走 Authoring a skill playbook。
9. 用原则名纠偏。
10. 读不懂回复就 /bro。

8.3 社区实践（均为社区报告）

@zbeyens：省 token 三件套（X 帖）

• 去掉 worktree， 自称约节省 50% token；
• 关闭 Fable（指当时的默认模型配置）；
• 用 /reflect 打磨， 把每次长任务的经验沉淀回 skill。

37Flow 注：去 worktree 和官方的并行隔离建议相冲突。单 agent 串行时可以考虑；多 agent 并行时不建议。

@uehaj：Claude Code 日常使用（X 帖）

• 每天在 Claude Code 中通过 pstack-claude 使用 pstack，说明移植版在 Claude Code 上可以用于日常工作。

@cpedia_1：Antigravity + Gemini + pstack（2026-09-28/29，X 帖）

• 展示 pstack 思路在 Google 系工具链中的可迁移性，但多模型面板等特性可能受限。

Zenn 日文深读：（jnst，2026-08-28）

• 适合当作「skill 百科」查表。注意：写于 0.15 之前，部分 skill 数量和名称已经过时。

Reddit r/AIAgentsInAction： 有若干 poteto-mode 讲解帖，适合入门理解；准确性参差不齐，以官方文档为准。

8.4 37Flow 的落地建议

第一周：

• 只用 /poteto-mode、/how、/bro 三个；
• 每个任务都写一个可检查的完成条件；
• 观察 todo 列表里的 skip: 条目，理解 playbook 的取舍。

第二周：

• 接受 verify skill 要约，或手动 /create-verification-skill；
• 开始用 Custom Mode；
• 尝试一次 /interrogate 审 PR。

第三周以后：

• 尝试过夜任务（带决策日志）；
• 对重复错误用 /correct；
• 用 /automate-me 起草团队自己的 mode。

成本控制：

• 用 /setup-pstack 把非关键角色设为较便宜的模型，或用 inherit-parent；
• 减小评审面板人数（列表长度即人数）；
• 小任务不要开 Custom Mode，避免每轮都带上全部上下文；
• 每周查看一次 Cursor 用量面板。

8.5 团队协作模板

PR 前自检提示词：

/interrogate 当前分支，持怀疑态度。先别改任何东西。除非是真实 bug 或行为回退，否则不要挑小毛病。

交接提示词：

/poteto-mode 我要下班了，安全暂停当前工作，写清楚现场，方便明天另一个 agent 接手。

接手提示词：

/poteto-mode 接手昨天那个 agent 的进行中工作，先 /recall 一下这个主题的现状。

（这里点名 /recall 属于覆盖性偏好。Session pickup playbook 本身也会处理上下文重建。）

9. 已知问题与争议

9.1 Token 消耗大

• @SergiuWitt（2026-09-22，社区报告）： 一天就用掉了约 15% 的 Cursor 月度额度。
• @leishenghao（2026-09-30，社区报告）： 认为 pstack 在「token 不限量」时效果最好。

原因分析（37Flow 观点）：

• 多模型评审面板：一次 /interrogate 等于多个模型分别读一遍 diff；
• /arena、/swarm 天然是 N 倍并行；
• 原则索引与 playbook 每个多步任务都要读；
• Custom Mode 让 poteto-mode 每轮都在上下文中；
• worktree 与子代理带来额外的上下文初始化。

缓解办法： 见 8.4 的成本控制；对确实简单的任务不用 poteto-mode；把 /arena 留给真正昂贵的决策。

9.2 安装体验的落差

• @spolen23（社区报告）： Cursor 的插件需要手动安装，对比 Claude Code / Codex 原生的插件或 skills 机制，体验上有摩擦。
• 官方方式其实只有一行 /add-plugin pstack。摩擦主要来自：需要额外运行 /setup-pstack、需要新开对话、Custom Mode 的快捷键不够直观、旧规则需要手动清理。

9.3 移植版滞后与维护成本

• @cu30rry_（社区报告）： 上游迭代太快，移植维护成本高。
• 事实佐证：2026-10-03 至 10-05 三天内上游发布 0.15.6 到 0.15.10 共五个版本。

9.4 其他值得注意的问题

• 默认模型多次变化： 9 月 1 日 Fable 5.1 设为默认，9 月 23 日改为 Opus 5.5 / Grok 4.7，0.15.3 之前的规则会钉住旧模型。升级后请检查 pstack-models.mdc。
• worktree 积累占磁盘： 用 Worktree cleanup playbook。
• 「名字空投」： agent 可能只是提到原则名而没有真正应用。检查回复里是否写明「改变了哪个决定」。
• verify skill 漂移： 定期运行 /maintain-verification-skill。

9.5 FAQ

Q1：我必须用英文写提示词吗？ 不必。skill 读的是意图，中文目标加中文完成条件同样有效。专有名词（如 playbook 名、原则名）用英文原名更精确。

/poteto-mode 订单导出在重试时会重复写入。先复现，再修复，用真实导出文件证明没有重复行。

Q2：/poteto-mode 和直接用 /tdd 有什么区别？ /poteto-mode 会先匹配 Bug fix playbook，再在合适的步骤调用 /tdd，并且在没有便宜测试路径时允许改用真实命令验证。直接用 /tdd 会跳过复现、根因等步骤。

Q3：Custom Mode 和普通 /poteto-mode 怎么选？ 连续多轮的严肃工作用 Custom Mode（Option/Alt+Enter）；一次性问题用普通 Enter。

Q4：auto 能填什么模型？ auto 不是模型，它等于 inherit-parent，意思是子代理继承父对话的模型。

Q5：怎么让它过夜工作又不乱来？ 写清完成条件、要求决策日志、指定 worktree：

/poteto-mode 我去睡了。一直做到所有 fixture 通过为止，不要停。保留一份我早上可以审计的决策日志。

Q6：不知道用哪个 skill？

/poteto-help 我想在改动前搞清楚这个模块为什么设计成这样，该怎么问？

Q7：回复太长看不懂？

/bro

Q8：Claude Code 能用官方版吗？ 官方版只面向 Cursor。Claude Code 请用社区移植（第 7 章），并接受滞后与差异。

Q9：怎么确认我是 0.15.9 还是 0.15.10？ 查看 Cursor 插件信息中的版本号，或输入 /poteto-help，能触发说明已是 0.15.10 及以上。

Q10：评审意见太多太杂？

/interrogate 这个 PR。把发现分成需处理和驳回两类，驳回的写理由。

10. 精通路线图

阶段一：官方十章指南（1–2 周）

按顺序读一遍 官方指南，每章配一个真实小任务：

中文读者可以对照 learn-pstack 中文官方指南。

阶段二：作者上下篇（3–5 天）

1. How I Use Cursor（约 2026-08-23）：理解动机；
2. 完整指南 Pt.1（约 2026-09-01）：验证、Feature Map、cloud agents；
3. 完整指南 Pt.2（约 2026-09-10）：research、architect、prototype。

读完后回头重读官方第 6、7 章，体会会不同。

阶段三：Zenn 查表 + 源码（按需）

• 把 Zenn 深读 当作 skill 百科，但计数以仓库为准；
• 直接阅读 skills/poteto-mode/SKILL.md 和你最常用的几个 playbook 原文；
• 关注 cursor/plugins 中 pstack/ 的提交历史，了解每个版本改了什么。

阶段四：实操与沉淀（持续）

1. 连续两周所有严肃任务都走 poteto-mode；
2. 每周一次 /reflect 或 /correct；
3. 第一个月末用 /automate-me 起草团队 mode，走 Eval playbook 盲测效果；
4. 为团队写一页内部速查卡（可以基于本文第 4、5 章）。

自测清单：你是否已经「精通」

• [ ] 能不看文档说出 5 个以上 playbook 的触发场景
• [ ] 能说清 /arena 与 /swarm 的区别
• [ ] 知道 auto 不是模型 slug
• [ ] 能写出一个可以通过或失败的完成条件
• [ ] 能用原则名一句话纠偏
• [ ] 跑过一次带决策日志的过夜任务
• [ ] 项目里有一个能用的 verify skill
• [ ] 用 /correct 消灭过一类重复错误

11. 参考链接

访问日期均为 2026-10-05，除非另有说明。社区链接内容随时可能变化。

11.1 官方

11.2 关键提交（时间为 UTC+8）

11.3 作者文章（中文镜像）

11.4 中文镜像 learn-pstack

11.5 社区移植

11.6 社区讨论与评论

本文由 37Flow 整理，非官方文档，仅供学习交流。pstack 版权与许可以 cursor/plugins 仓库的 MIT LICENSE 为准。如发现与官方不一致之处，以官方仓库为准。