pstack 完整指南（上）

这组文章里，我会讲我怎么用 pstack。它是我自己那套做严谨工程活的 skills。靠它，我能每月把大约 2,000 个 PR 送进生产，而且信心很高。

一张桌子：终端、浏览器、编辑器，旁边还有一个 cloud agent

就我个人而言，我从来不太在意自己落了多少行代码、多少个 PR。在 agent 出现之前，也没人在意。这说得通。原始吞吐并不总等于质量，也不总等于用户看得见的结果。它常常只是虚荣指标。

但在做 pstack 的过程中我发现，量其实重要。尤其是当你能用 agent 把产品质量维持住、甚至抬高的时候。举例。大约两个月前我开始做 Grok @Bot，那时它还早，代码库新鲜，但已经在长大。团队后来变大了，现在每天往 Grok @Bot 代码库里落几百个 PR。即便如此，pstack 仍让我能把代码质量给所有人托住。我会持续盯代码、重构、加 lint 与检查，同时也做功能。

https://x.com/i/status/2090546476464451907

能当上 Grok @Bot 的园丁和维护者，靠的就是 pstack。原型跑通后早期冲劲很猛，很多人在加入。我抓住了一个关键窗口。在它被持续建造和扩展、还不该停机的时候，把整个代码库重构成有硬地基的样子。一个高质量、可扩展的代码库。不管有多少工程师（更重要的是，多少非工程师）往里贡献，它都能撑住。这类工作要求我一边盖楼一边修地基。只有地基跟得上贡献量，你才做得到。

Grok Bot 是市面上最高效、性能最好的 AI 桌面应用之一

Grok Bot 是市面上最高效、性能最好的 AI 桌面应用之一

证据就在 Grok @Bot 本身。接下来几周，我会把用 pstack 建造和维护高质量应用所需的东西，尽量讲清楚。

第 1 部分。验证就是你所需要的全部

工具箱里最关键的 skill，是一份高质量的验证 skill。它重要到我会把它当成关键基础设施，而不是「只是」一个 skill。做好了，它会放大整个团队的产出，包括非工程师。做得好，整队产出可以到 100 到 1000 倍。

如果你还不熟这个说法，验证的意思是。agent 能验证自己的工作。它可以一直做到任务成功，因为闭环不再需要你当瓶颈。想知道我怎么给 Cursor 写出第一份验证 skill，见上一篇 Loops You Can Trust（英文 / X）。

一起做一份验证 skill

先装 pstack，然后跑 /create-verification-skill。我也建议把 Dr Eggbot 加进你的名单。它是我用来帮你做高质量 bot 的 bot，随 pstack 一起提供。它会教写代码的 bot 怎么用这套东西，也能用同样的严谨度做非编码 bot。

你可以让 Dr Eggbot 先给你做一个工程师 bot，再让它跑 /create-verification-skill，并设一个每日例行跑 /maintain-verification-skill。

喜欢 Dr Eggbot

喜欢 Dr Eggbot

它在跑的时候，我们先走一遍这个 skill 做什么，以及它如何替你做出高质量验证 skill。

我把我们用来建 Grok @Bot 和 Cursor 的那些验证 skill，蒸馏成了这份 meta-skill。它教你的 agent 如何为你自己的应用做出一份高质量版本。

这里技术栈选择很重要。如果你做的是 Electron 或 Web 应用，就能用上 JS 生态里丰富的调试工具。例如 Chrome DevTools Protocol (CDP) 让你用上和浏览器开发者工具同一套能力。如果是 iOS 应用，就用模拟器。

理想状态是。agent 能和你的应用交互、调试、采 perf trace，以及你亲手开发时常用的其他调试与开发工具。如果没有丰富的运行时可用，你可能要让 agent 帮你造工具（例如用 lldb，或在开发环境当 sidecar 跑的自定义包），或者就用现有的东西。

我个人觉得 agentic 验证重要到可以认真建议。为了不对称优势和极端生产力，你甚至该自己做一套丰富的调试工具，或者换一个更好调试的技术栈。前面说过。让 agent 能验证自己的工作，等于解锁组织里每个人都能贡献，并证明改动真的有效。技术栈越难调试、越难控制，agent 就越难用出生产力。

让它可复现

pstack 里有一条原则叫 “Build the Lever”。落到写 skill 上，意思是。我们更愿意给 agent 工具，而不是只给 markdown。对验证 skill 来说，就是做一个小 CLI，把与应用交互和调试脚本化，做成对 agent 友好的小工具。这样 agent 做同一件事会少烧很多 token（跑一条 CLI，而不是写个一次性脚本去点什么），验证 skill 也更可复现、可测试。

下面是一个假设例子。agent 可能为 Electron 应用做出这样的 CLI：

# health
node .cursor/skills/verify-atlas/control-atlas.mjs doctor

# open a blank thread and send
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"

# keyboard path
node .cursor/skills/verify-atlas/control-atlas.mjs press "Meta+KeyN"

# accessibility snapshot of the live UI
node .cursor/skills/verify-atlas/control-atlas.mjs snapshot

# screenshot for evidence
node .cursor/skills/verify-atlas/control-atlas.mjs screenshot /tmp/atlas-proof.png

# wait for streaming / layout to settle
node .cursor/skills/verify-atlas/control-atlas.mjs wait-settle

# flip a feature flag for the session
node .cursor/skills/verify-atlas/control-atlas.mjs feature-flag rooms_v2 on

现在所有 agent 都能用这个 CLI 快速导航和调试你的应用。你也该开始认真想应用的开发体验：

如何 seed 开发数据库
如何处理 auth、测试用户、对测试或预发环境的 API 调用
如何用一致方式安装并拉起开发环境

这些本来就是你亲手写代码时也要想的事。把它当成 agent 在你应用上做开发的主工具。维护好，测好。

你可能还想考虑这些命令类别：

- **Inspection:** `info`, `snapshot`, `screenshot`, `components`
- **Navigation:** `home`, `new-session`, `select-project`, `select-runtime`, `scroll`
- **Interaction:** `send`, `click`, `click-xy`, `aria-click`, `type`, `press`, `eval`, `upload-image`, `add-context`, `feature-flag`
- **Performance:** `trace`, `profile`, `record`, `perf-metrics`, `wait-settle`
- **Streaming:** `console`, `network-log`, `network-summary`
- **Health & cleanup:** `doctor`, `cleanup`, `watch --restart`

有了这套基本盘，你应该已经能看到 agent 明显变强。它们该能轻松在应用里导航和调试。

我建议先把这段时间花在把 CLI 做稳、少报错上，再去做更高级的事。你也该想清楚（或让 agent 想清楚）怎样设计对 agent 友好的 CLI。网上有很多资料可以丢给 agent。我喜欢的关键性质是：

API 容易组合。想想 John Ousterhout 的 deep modules
任何可能有破坏性副作用的命令都该有 --dry-run
用子命令逐步披露功能，而不是一次摊开全部
错误信息要非常具体，并告诉 agent 下一步该做什么
丰富的 --help
输出用机器可读形式返回（例如 JSON）

用 Cloud Agents 并行，而不是 worktree

当你已经用验证 skill 成功合进几个 PR，可能会想。能不能更并行？例如，如果 agent 已经能把你的提示大致推到可合并状态，那不就腾出手来跑更多 agent 了吗？

第一反应通常是加 worktree。让 agent 用 git 再建一份受跟踪的仓库副本，在与主 checkout 隔离的地方改。理论上，这样就能同时跑多个 agent，而不会互相覆盖。

我不建议这么做。一来它很吃本机存储和资源。按仓库大小和机器性能，worktree 并行也许能撑到大约 10 个 agent。但有远更好的办法。

Cursor 的 cloud agents 跑在 Cursor 的云基础设施上。它们有一台真电脑。可以装依赖、跑应用、拍视频和截图，像真人用户一样和你的应用交互。如果你已经在前一步把开发体验做扎实，接 cloud agents 通常不会是大工程。第一次配置云环境时，我们会派一个 agent 帮你装好并跑通。第一次构建之后会打 snapshot，之后的 cloud agent 启动会很快。

我强烈建议花时间把 cloud agents 配好。它会解锁并行上的巨大生产力提升。后面某篇我会讲我怎么在云上并行跑上百个子 agent。现在先把环境配到你敢把 agent 都放到云上跑。

用 Feature Map 让 agent 保持聪明

应用变复杂后，agent 需要更多指引，才能找到功能并与之交互。为此我想出了 Feature Map。顾名思义，它是一份易检索的地图。覆盖应用里有哪些功能、各自做什么、从用户视角怎么走到那里。

这是我为虚构应用 Atlas 准备的 Feature Map 例子。就是验证 skill 的 SKILL.md 里提到的几份 markdown。

文件可以放哪都行。但在 /create-verification-skill 里，我们会自动建 references/features 目录，并带一个 README.md。readme 本身就是地图。高层概览主要功能，并链到细节。一个功能条目大概长这样：

# Preferences

Full-screen preferences overlay and its tab set.

## Sub-features

- settings-overlay: full-screen overlay opened from the gear or Cmd/Ctrl+,
- settings-nav: left nav of tabs (General, Appearance, Models, Plan & Usage, ...).
- settings-search: in-overlay search (Cmd/Ctrl+K while settings is open).
- theme-picker: quick theme control on Appearance.

## How to get to it (user POV)

Click the gear next to the account avatar, or press Cmd/Ctrl+,. Pick a tab from the left nav. Type in the preferences search box to jump. Escape or the close control dismisses.

## Driving it with control-atlas

bash
node .cursor/skills/verify-atlas/control-atlas.mjs press "Meta+Comma"
node .cursor/skills/verify-atlas/control-atlas.mjs snapshot
node .cursor/skills/verify-atlas/control-atlas.mjs press "Escape"

- Overlay root: look for a dialog/region named Preferences in the a11y tree.
- Tabs: click by visible name. Plan & Usage may be absent for some account states.
- While settings is open, Cmd/Ctrl+K is preferences search, not the global palette (see `multi-surface-journeys.md`).

## Gotchas

- Closing settings mid-suite can leave focus nowhere useful. `new-session` or `home` recovers.
- Some tabs are entitlement-gated. Skip with an explicit account reason.

不用自己手写这些。跑 /create-verification-skill 时，agent 会自动把应用逛一遍、建目录、写出这些 references。

Feature Map 加上 CLI，是 pstack 验证 skill 这么强的主因之一。agent 现在对每个功能及其到达路径有上下文。既省 context window 里的宝贵 token，也教会它这功能是干什么的、怎么去。

你可以把 Feature Map 看成一种「物化记忆」。用过 agent 一阵子的人，大概都熟 memory 这个概念。常见是简单 markdown（例如 Obsidian vault），也可能是向量库之类更复杂的东西。我个人觉得，代码库才是终极记忆。代码是你和团队决策的投影，是「发生过什么、实际怎么工作」的真相源。Feature Map 只是它的更紧凑形态，目标是省 token。又因为它就是 skill 里的 markdown，每个给代码库做贡献的人都能共享这份记忆。

所以维护验证 skill 真的很重要。我建议至少每天跑一次 /maintain-verification-skill，确保 agent 始终拿得到控制应用的最新细节。用得越深，你也可能发现 agent 会在干活时自动更新它们。/maintain-verification-skill 负责补漏。

怎么用你的验证 skill

参考这份为虚构应用做的例子验证 skill：https://github.com/poteto/verification-skill-example。提醒一次。跑 /create-verification-skill 就能做出一份，里面含基础 CLI 和 Feature Map。

我通常这样和 pstack 一起用。

首先，当然是用 /poteto-mode 开头。如果在 Cursor 里用 pstack，自动补全 /poteto-mode 时可以按 Opt + Enter，而不是只按 Enter。这会把 skill 加成 Custom Mode，从而钉住 skill，让 agent 每一轮都收到「要用它」的提醒。

输入 /poteto-mode，再按 Opt + Enter，把它钉成 Custom Mode

输入 /poteto-mode，再按 Opt + Enter，把它钉成 Custom Mode

在 Grok @Bot 里，装好插件，然后输入 /poteto-mode。

在 Grok Bot 里也能用 pstack！

在 Grok Bot 里也能用 pstack！

例子。做新功能

做新功能时，我通常把验证 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 做别的事，并保持它的 context window 干净。从这个意义上，我把 bot 更多当成协调者。它们管理和监督 cloud agents。Cloud agents 也能用上 Cursor 里整套模型，而且各自有机器，所以你的 bot 本机还能干别的。

例子。性能活

spawn a cloud agent to use /poteto-mode to improve the initial loading time of our app. first use /control-app to take a trace of the status quo, and identify opportunities for improvement. then do a targeted fix and use /control-app + a /swarm to confirm the win

/swarm 是最适合和验证 skill 组合的 skill 之一。它扇出任意数量的 cloud agents 去跑你的验证 skill。于是你可以在足够样本量下确认性能胜利，或 fuzz 应用以确保没破坏、没回退。

例子。自动复现用户报告

验证 skill 满意之后，你可以把它放进 Grok @Bot routines，或 Cursor Automations。Routines 和 automations 能按计划跑，也能在事件发生时触发。

例如，如果用户反馈进 Slack，或你有内部反馈频道，可以让 bot 监听每条报告，并自动用 cloud agent 尝试复现。如果验证 skill 和 Feature Map 够好，你甚至可能下一步直接自动修。

前面我说验证是工具箱里最重要的 skill 之一，是有原因的。它给你一个地基，去叠新的 skill 和 routine。最重要的是，团队里每个人都受益。

投资你的验证 skill

做出验证 skill 之后，用 /maintain-verification-skill 保持锋利。持续改进 CLI，像对待关键基础设施一样投入。你甚至可能想给它排 oncall。它有多重要，就看它能为团队解锁多少 100 到 1000 倍产出。

这份 skill 是 pstack 指南里许多其他 skill 的地基，也和它们组合得很漂亮。

pstack: https://x.ai/bot/plugin/9717366（github link）
Dr Eggbot: https://x.ai/bot/93gOz3op1UQdBdbekQFLK

我建议把 Dr Eggbot 加进名单。它随 pstack 提供，会教写代码的 bot 怎么用，也能用同样严谨度做非编码 bot。

你可以让它先做一个工程师 bot，再让那个 bot 跑 /create-verification-skill，并设每日例行跑 /maintain-verification-skill。

感谢阅读。下篇见。