pstack 完整指南 Pt.1：验证就是一切
作者：poteto（@poteto，Grok Bot 的维护者）
这个系列里，我会展示我怎么使用 pstack——我自己的一套 skill，用来做严谨的工程工作。它让我每个月能带着高信心把 2,000 个 PR 推到生产环境。
我个人从不太在意写多少行代码、落多少 PR。在 agent 之前没人在意，这是对的：纯粹的产出量并不等于质量，也不等于用户能看见的结果，它就是个虚荣指标。
但在构建 pstack 的过程中我发现，量确实重要——尤其是当你用 agent 能保持甚至提高产品质量的时候。比如我大约两个月前开始做 Grok Bot，那时它还在早期，代码库很新但开始长大。现在团队每天往 Grok Bot 推几百个 PR，而 pstack 让我能持续监控代码、重构、加新的 lint 和检查，同时还做功能，为所有人把代码质量维持在高位。
做 Grok Bot 的园丁兼维护者这件事，只有靠 pstack 我才能做到。原型做出来之后我们的势头非常高，很多人加入团队。我抓住了一个关键的时间窗口：在代码库还在被构建和扩展、且没有任何停机的情况下，把整个代码库重构成有强基础的东西——一个不管多少工程师（最重要的还有非工程师）往里贡献都能撑得住的高质量代码库。做这些的前提是，基础能跟得上贡献的数量。
证据就在 Grok Bot 本身。接下来几周，我会把用 pstack 构建和维护一个高质量应用所需要知道的东西全部讲完。
Part 1：验证就是一切
你的工具箱里最关键的一个 skill，是高质量的验证 skill。它重要到我把它当成关键基础设施来维护，而不是「一个 skill」。一个好的验证 skill 会放大整个团队的产出，包括非工程师——做得好，你会把整个团队的产出放大 100 到 1000 倍。
如果你不熟悉这个词：验证的意思是 agent 能验证自己的工作。它可以一直做下去，直到任务成功，因为现在闭环不需要你在中间当瓶颈了。
一起做一个验证 skill
先装 pstack，然后跑 /create-verification-skill。我还建议把我的 Dr Eggbot 加进你的 bot 名单——它专门帮你造高质量的 bot，随 pstack 一起发布。它会教编程 bot 怎么用 pstack，也能用同样的严谨度做非编程 bot。
你可以让 Dr Eggbot 给你造一个工程师 bot，然后让它跑 /create-verification-skill，并设一个每日例程跑 /maintain-verification-skill。
这个 skill 是元 skill：我把它给 Grok Bot 和 Cursor 用的所有验证 skill 蒸馏成了一个，它教你的 agent 为你的应用造一个高质量的验证 skill。
这里技术栈的选择变得重要。如果你做的是 Electron 或 Web 应用，你可以用 JS 生态里丰富的调试工具——比如 Chrome DevTools Protocol（CDP），等于把浏览器开发者工具里的同一套工具交给 agent。如果你做 iOS 应用，就用模拟器。
理想情况下，你要能和应用交互、调试它、取性能 trace，以及任何你自己手写时本来会用的调试和开发工具。如果你没有丰富的运行时可用，可能需要让 agent 给你造工具（比如用 lldb，或者一个在开发环境里作为 sidecar 跑的自定义包），或者先把手头有的用起来。
我个人认为 agentic 验证重要到了我会认真建议你：为了获得不公平的优势和极致的生产力，去建自己的调试工具，甚至换一个技术栈。就像前面说的，让 agent 能验证自己的工作，会解锁组织里每个人去贡献、并验证自己的改动真的能用。你的技术栈越难调试和控制，用 agent 做出高产出的难度就越大。
让它可复现
pstack 里有一条原则叫 Build the Lever（造杠杆）。用在创建 skill 上，它的意思是：我们更愿意给 agent 工具，而不是只给 markdown。对验证 skill 来说，这意味着造一个小 CLI，把应用的交互和调试脚本化，做成一个 agent 友好的小工具。这样 agent 做事消耗的 token 更少（跑一条 CLI 命令，而不是写一个一次性脚本来点某个东西），也让验证 skill 更可复现、更可测试。
一个假想的、给 Electron 应用用的 CLI：
node .cursor/skills/verify-atlas/control-atlas.mjs doctor
node .cursor/skills/verify-atlas/control-atlas.mjs new-session
node .cursor/skills/verify-atlas/control-atlas.mjs send "list open tasks in this project"
node .cursor/skills/verify-atlas/control-atlas.mjs press "Meta+KeyN"
node .cursor/skills/verify-atlas/control-atlas.mjs snapshot
node .cursor/skills/verify-atlas/control-atlas.mjs screenshot /tmp/atlas-proof.png
node .cursor/skills/verify-atlas/control-atlas.mjs wait-settle
node .cursor/skills/verify-atlas/control-atlas.mjs feature-flag rooms\_v2 on
现在所有 agent 都能用这个 CLI 快速导航和调试你的应用。你还要开始考虑应用的开发体验：
开发数据库的 seed；认证、测试用户、对 test/staging 环境的 API 调用怎么处理；如何一致地安装并启动开发环境。
这些是你自己写代码时本来就要想的事。把它当成 agent 在你的应用上做开发工作的主力工具，好好维护、好好测试。
其他值得考虑的命令类型：
检查类：info、snapshot、screenshot、components
导航类：home、new-session、select-project、select-runtime、scroll
交互类：send、click、click-xy、aria-click、type、press、eval、upload-image、add-context、feature-flag
性能类：trace、profile、record、perf-metrics、wait-settle
流式排查：console、network-log、network-summary
健康与清理：doctor、cleanup、watch --restart
有了这套基础，你应该已经能看到 agent 的明显改善：它们能轻松地在你应用里导航和调试。
我建议在做更进阶的事之前，先花时间把这个 CLI 做得好、做到没有 bug。你还要考虑（或者让 agent 考虑）怎么设计一个 agent 友好的 CLI。网上有很多资源可以丢给 agent 参考，我自己最看重的属性是：
API 易于组合——想想 John Ousterhout 的「深模块」哲学
任何可能有破坏性副作用的命令都要有 --dry-run
用子命令逐步披露功能，而不是一次性全给
错误信息要非常有描述性，直接告诉 agent 应该做什么
丰富的 --help 文本
输出用机器可读的形式（比如 JSON）
用 Cloud Agents 代替 worktree 来并行
当你用验证 skill 成功落了几个 PR 之后，你可能会想要并行更多。比如：如果 agent 现在能接过你的 prompt 并把它推进到基本可合并的状态，那是不是就能同时跑更多 agent 了？
你的第一反应会是加 worktree 支持——让 agent 用 git 建一份仓库的带跟踪副本，在其中隔离地改东西，理论上这样多个 agent 就不会互相覆盖。
我建议不要这么做。第一，它在你机器上吃掉大量存储和资源；根据仓库大小和机器性能，用 worktree 大概能跑到 10 个并行 agent。但有更好的办法。
Cursor 的 cloud agents 跑在云端、跑在 Cursor 的基础设施上。这些 agent 能访问一台真实的计算机：可以安装依赖、运行你的应用、录视频和截图、像真实用户那样与应用交互。如果你在前一步把开发体验做得足够好，接上 cloud agent 不会是很大的工程。第一次建立云环境时我们会派一个 agent 帮你把它跑通；第一次构建之后我们会拍一个快照，所以后续每次 cloud agent 启动都很快。
我非常建议花时间把 cloud agents 配起来，它会在并行上解锁巨大的生产力提升。后面的文章里我会展示我怎么在云上并行跑几百个 subagent。现在先把你的环境调到一个你能放心把 agent 都放到云上跑的状态。
用 Feature Map 让 agent 保持聪明
应用变复杂以后，agent 需要更多指引才能找到功能并与之交互。为此我做了一个东西叫 Feature Map。顾名思义，它是一张可搜索的地图，列出你应用里所有可用的功能、它做什么、以及从用户视角怎么走到它。
我给一个虚构应用 Atlas 准备了一份示例 Feature Map，它只是几个 markdown 文件，在验证 skill 的 SKILL.md 里被引用。
这个文件放在哪都行，但在 /create-verification-skill 里我们会自动创建一个 references/features 目录和一个 README.md。这个 readme 就是地图本身：所有主要功能的高层概览，加上指向具体细节的链接。一个功能条目大概长这样：
Preferences：全屏偏好设置浮层和它的标签页集合。
子功能：settings-overlay（从齿轮或 Cmd/Ctrl+, 打开）、settings-nav（左侧标签导航）、settings-search（浮层内搜索，Cmd/Ctrl+K）、theme-picker（外观页的快速主题控制）。
从用户视角怎么到达：点头像旁的齿轮，或按 Cmd/Ctrl+,。从左导航选标签，在搜索框里输入以跳转，按 Escape 或关闭控件退出。
用 control-atlas 驱动：press "Meta+Comma" → snapshot → press "Escape"。
注意：浮层根节点在无障碍树里是名为 Preferences 的 dialog/region；标签按可见名字点击；某些账号状态下 Plan & Usage 可能不存在；设置打开时 Cmd/Ctrl+K 是偏好搜索而不是全局面板。
坑：在套件中途关闭设置可能让焦点落在没用的地方，new-session 或 home 可以恢复；有些标签有权限门槛，用明确的账号理由跳过。
别担心要自己写这些。你跑 /create-verification-skill 的时候，你的 agent 会自动走一遍你的应用，把所有功能编目并生成这些引用。
Feature Map 配上 CLI，是 pstack 的验证 skill 这么好用的主要原因之一：agent 现在拥有每一个功能的上下文和到达方式，省下宝贵的上下文 token，并告诉它这个东西是干什么的、怎么走到。
你可以把 Feature Map 看成一种「物化记忆」。如果你用 agent 有一段时间了，你对记忆这个概念应该不陌生——通常是 markdown 文件（比如一个 Obsidian 库），或者更复杂的向量数据库。而我认为，你的代码库是记忆的终极形态。代码是你和团队所做决策的投影，是「发生了什么、事情实际上怎么运作」的真相来源。Feature Map 只是它更紧凑的一种形式，为了省 token 而设计。而且因为它只是 skill 里的 markdown，所有往你的代码库贡献的人都能共享这份记忆。
这意味着维护验证 skill 非常重要。我建议每天至少跑一次 /maintain-verification-skill，确保 agent 手上始终是关于「怎么控制你的应用」的最新细节。你用得越多，可能也会发现 agent 会在干活时自动更新它；/maintain-verification-skill 负责捞起漏掉的部分。
怎么用你的验证 skill
参考：为虚构应用做的示例验证 skill 在 github.com/poteto/verification-skill-example。再次提醒，跑 /create-verification-skill 生成一个，里面包含基础 CLI 和 Feature Map。
我通常这样配合 pstack 使用。
首先，prompt 用 /poteto-mode 开头。如果你通过 Cursor 用 pstack，在自动补全 /poteto-mode 时按 Opt + Enter（而不是只按 Enter）——这会把 skill 作为 Custom Mode 钉住，agent 在每个新回合都会收到「用这个 skill」的提醒。在 Grok Bot 里，装上 plugin，然后输入 /poteto-mode。
例子：构建新功能。我一般把验证 skill 和 /poteto-mode 一起用，让 agent 验证自己的改动：
/poteto-mode build \<功能描述，以及任何有用的上下文\>。用 /control-app 验证你的改动，并用视频和截图给我看证据。
其中 /control-app 就是 /create-verification-skill 的产物。在 Grok Bot 里我会这样写：
spawn a cloud agent to use /poteto-mode to build \<功能描述\>。用 /control-app 验证你的改动，并用视频和截图给我看证据。
细微差别是：在 Grok Bot 里你让 bot 去 spawn 一个 cloud agent，而不是自己干。我偏好这样做，主要是因为它解放了你的 bot 去做别的事，也让它的上下文保持干净。从这个意义上说，我把 bot 更多看成管理并监督 cloud agent 的协调者。cloud agent 也让你能用上 Cursor 里可用的全部模型，而它们有各自独立的机器，你的 bot 那台电脑就空出来干别的。
例子：性能工作。
spawn a cloud agent to use /poteto-mode 来改善我们应用的首次加载时间。先用 /control-app 给现状打一份 trace，找出优化机会；然后做针对性修复，并用 /control-app 加一次 /swarm 来确认收益。
/swarm 是和验证 skill 搭配最好的 skill 之一：它把任意数量的 cloud agent 扇出去跑你的验证 skill，于是你可以用足够大的样本量确认一次性能收益，或者对你的应用做 fuzz，确保没有破坏或回归。
例子：自动复现用户报告。当你对验证 skill 满意之后，可以把它放进 Grok Bot 的 routine，或者 Cursor Automations。routine 和 automation 让你按计划跑，或者在任何事件发生时触发。
比如：如果你把用户反馈接进了 Slack，或者有自己的内部反馈渠道，你可以让 bot 监听每一条报告，并自动用 cloud agent 尝试复现。如果你的验证 skill 和 Feature Map 足够好，你甚至可以决定自动修掉这些问题。
我前面说验证是你工具箱里最重要的 skill 之一，是有原因的：它给你一个基础，让你在上面构建新的 skill 和例程，而最重要的是，你团队里的每个人都因此受益。
投资你的验证 skill
验证 skill 创建好之后，用 /maintain-verification-skill 让它保持锋利。持续改进那个 CLI，像对待关键基础设施一样投资这个 skill。你甚至可以为它设一个 oncall 轮值——它重要到这种程度，因为它为你的团队解锁 100 到 1000 倍的生产力。
这个 skill 是 pstack 指南里后面很多 skill 的基础，而且和它们组合得很好。
pstack：x.ai/bot/plugin/9717366（GitHub：github.com/cursor/plugins/tree/main/pstack）
Dr Eggbot：x.ai/bot/93gOz3op1UQdBdbekQFLK
原文：https://x.com/poteto/status/2094457600259842065
#Agent #Skill #验证 #pstack
