新手上手 pstack：在 Cursor 里让 agent 像靠谱工程师一样干活

37Flow 整理 · 非官方教程

依据： - 官方十章指南：cursor/plugins 仓库 pstack/docs/guide（README 及第 01–10 章） - 官方插件说明：pstack/README.md - 作者 @poteto 的 X 长文《The Complete Guide to pstack》Pt.1（2026-09-01）、Pt.2（2026-09-10） - 中文学习站 learn-pstack（非官方）：官方指南中文版、作者文章索引

查阅日期：2026-10-05。 pstack 更新很快，本文和官方说法不一致时，以官方仓库为准。

0. 写给谁 / 读完能做什么

写给谁：

读完你能做到：

  1. 装好 pstack，配好它用的模型；
  2. 用一句“目标 + 怎么算完成”的提示词，让 /poteto-mode 帮你挑好流程；
  3. 改代码前，先用 /how /why /teach /recall 把代码弄懂；
  4. 大改动前，用 /architect /arena /swarm /interrogate 把设计想清楚；
  5. 让 agent 拿出真实证据证明改动能用，再开 PR、盯 PR；
  6. 写一份“过夜合同”，第二天早上查它的决策记录；
  7. 用 /automate-me 做一个属于你自己的 mode。

建议读法： 第一次按顺序读，每读一节就在真实项目里试一条提示词。官方指南最后一句话说得很对：习惯是用出来的，不是读出来的。

1. pstack 一句话是什么

一句话：pstack 是一套装进 Cursor 的“技能包”（skills 插件），核心入口是 /poteto-mode。

先把几个容易混的地方讲清楚：

作者在 README 里说，pstack 的目标不是让 agent 写更多代码，反而是“写更少、但质量更高的代码”。能信得过一个 agent 写出可验证的代码，你才敢同时开好几个 agent 并行干活。

小结：日常你几乎只需要记住 /poteto-mode。其他 skill 大多由它在需要时替你调用。

2. 从零安装

人话解释： 插件就是一个“技能包下载器”，装一次，所有聊天都能用。

操作步骤：

  1. 打开 Cursor，新建一个聊天。
  2. 输入：
/add-plugin pstack

预期效果： Cursor 提示插件已安装。

也可以去插件市集页面看介绍：https://cursor.com/marketplace/cursor/pstack

装好之后先别急着干活，下一步要配模型。

3. /setup-pstack：给不同角色配模型

3.1 先用人话理解“角色”

pstack 干活时，会把任务分给不同的“角色”。按官方指南，常见的有：

不同模型各有长处，pstack 允许你给每个角色指定不同模型。官方 README 提到，开箱默认是：写代码的活交给 grok，最难的改动、写作和判断交给 opus 5.5，默认评审小组是 opus 5.5 / sol / grok。这些都能在 setup 里改。

3.2 操作步骤

/setup-pstack

预期效果：

  1. 它先检测你账号能用哪些模型；
  2. 问你要多少推理预算（可以理解成“让模型想多久、想多深”，越多越贵越慢）；
  3. 把每个角色列成一张角色表给你看，问你想怎么改；
  4. 你回答完，它写出一个小规则文件：
~/.cursor/rules/pstack-models.mdc

之后每个 pstack skill 都会先读这个文件，看自己该用什么模型。

3.3 必须知道的几件事

3.4 验证 skill 的邀请（先了解，后面细讲）

setup 最后会找一找你的项目里有没有办法“证明应用真的能用”（一个 verify-* skill，或现成的测试工具）。如果都没有，它会问你一次要不要用 /create-verification-skill 生成一个。说“要”或“不要”都行，以后随时能自己跑。第 8 节会讲它为什么重要。

4. 第一次用 /poteto-mode

4.1 核心心法：说目标，不说仪式

官方指南首页有一句“只记住一件事”的话：给 agent 一个目标，再给它一个检查方法，用你自己的话说就行。

你不需要写需求文档，也不需要列出要用哪些 skill。

4.2 第一条提示词

挑一件真实但很小的事，像跟同事说话一样写：

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

（意思：给这个命令加一个 --json 参数；原来的文本输出要一个字节都不变；两种输出都要验证。）

预期效果：

修 bug 的写法也一样，关键词是“先复现”：

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

预期效果： “repro first”（先复现）加上一个能检查的结果，就足够让它匹配到 Bug fix 流程：先把问题复现出来，再找根因修复，最后验证。

4.3 什么是 playbook（流程文件）

人话解释： playbook 是 /poteto-mode 里面的一份份“流程卡片”，比如“修 bug 怎么做”“做新功能怎么做”“开 PR 怎么做”。官方 README 写的是二十三个。

注意两点：

常见路由（按官方指南）：

你说的话像…… 它大概会走
只读的问题（“为什么……”“别改代码”） Investigation 调研
某处坏了 Bug fix 修 bug
要新行为 Feature 新功能
只改结构、行为不变 Refactoring 重构
量出来的慢 Perf issue 性能
工作很大，或者都对不上 figure-it-out

4.4 换任务时说一声 “new task”

一个聊天聊久了，会带着上一个任务的上下文。换话题时这样写：

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

预期效果： “new task” 让它重新挑流程；“don’t change any code yet” 把这次钉在只读调研上。不说这两句，它可能把你的问题当成上一个功能的下一步。

4.5 上下文够了，提示词可以很短

聊天里已经讲清楚时，这些都够用：

/poteto-mode do it

continue

keep going until done

4.6 让 /poteto-mode 一直“粘”着：Custom Mode

人话解释： 普通方式选中 /poteto-mode 按 Enter，它只附在这一条消息上，聊着聊着效果会淡掉。想让它整场聊天都在，就把它变成 Custom Mode。

操作步骤：

  1. 在输入框打 /，在菜单里找到 poteto-mode；
  2. 不要按 Enter，而是按 Option+Enter（Mac） 或 Alt+Enter（Windows）；
  3. 它会变成一个 Custom Mode，每一轮都留在上下文里，直到你退出。

官方说明 Custom Mode 在 Agents Window 和 CLI 里可用。

4.7 新手最常犯的错：自己列 skill 清单

不要这样写：

use /how, then /architect, then /arena...

流程里已经排好了 skill 的顺序。你手写的顺序往往会打乱或漏掉流程本来会保留的步骤。只有想推翻某个具体选择时，才点名某个 skill。 实在不知道用哪个，问 /poteto-help，它会问清你想做什么，再给你指路。

5. 先弄懂代码：/how /why /teach /recall

为什么要这一步？ 改自己不懂的代码，是悄悄引入回归 bug 的主要途径。没弄懂就动手的 agent，常常在第一个“看起来对”的地方修症状，而不是修病根。先 /how 一下，比修第二个 bug 便宜。

5.1 /how：现在是怎么运作的

人话： 像一个资深同事带你熟悉一个模块，讲清楚运行时怎么流转、关键类型是什么、哪里不直观。

/how do we dedupe notifications? is there an n+1 when we look up subscribers?

Pt.2 里作者的例子（中文大意）：

/how 虚拟化是怎么实现的？

预期效果： 小问题它直接读代码解释；大模块会先派 2–4 个只读的探索子 agent 并行去读，再汇总。作者提到，这些探索 agent 可以用又快又省的模型来跑。

5.2 /why：当初为什么这样写

人话： 像侦探查旧案。代码能告诉你发生了什么，却很少告诉你别人为什么这样写。

/why was the retry limit set to five? does the reason still hold?

/why 我们为什么还卡在旧版的 node.js 上？

预期效果： 它先查 git 历史，再并行查你通过 MCP 接入的各种来源（工单、文档、团队聊天、监控、报错等）。报告会注明出处，分开“直接证据”和“推断”，证据少时会说“看起来是”。查不到也会如实报告，因为“没人写下过原因”本身就是答案。

两个可以组合：do why first then how（先查历史再看机制）也是一句好提示词。

5.3 /teach：讲到我真懂

人话： 摘要不够用时，让它把 /how 和 /why 的结果揉成一份一步步搭起来、带图的讲解。

/teach me how this PR changes retries. convince me it fixes the cause and not the symptom.

/teach 给我讲讲，你为什么这样实现，而不是 <另一种做法>。你做了哪些取舍，为什么？

预期效果： 一份从浅到深的解释。官方建议偷学“convince me（说服我）”这个说法：它把讲解变成一个你可以反驳的论证，而不是走马观花的导览。作者在 Pt.2 里还说，让 agent 先把要做什么、为什么讲给你听，最后也帮了 agent 自己，因为它得真去读代码，不能只凭感觉下结论。

5.4 /recall：帮我找回上次的进度

人话： 你隔了一周回到某个话题，脑子一片空白。/recall 去翻你最近的聊天记录和共享记录（工单、以前的修复、还在报的错），给你一份“现在到哪了、接下来干什么”的简报。

/recall catch me up on the export work from last week

/recall 我昨天在虚拟化上做的工作，然后读一下 slack 上这份 bug 报告

注意区分： 想接着某一个具体的旧聊天或别人留下的分支干活，用的是 Session pickup 流程，不是 /recall：

/poteto-mode take over this branch. read the decision log, figure out what's done, and continue from there. don't redo finished work.

5.5 作者的小技巧：让 agent 用自己的话复述

Pt.2 里作者常用一种“间接提示”：先不说自己的猜测，让 agent 用自己的话把问题说一遍。

/poteto-mode 读一下这个 slack 讨论串。用你自己的话、用大白话复述一遍，你觉得根本问题是什么

好处：它得把嘈杂的讨论压缩成清楚的问题陈述；它理解错了你马上能看出来；你也不会用自己可能错误的假设把它带偏。

6. 设计：/architect /arena /swarm /interrogate

为什么要这一步？ 难的设计只试一次，就会被模型想到的第一个形状锁死。作者在 Pt.2 里说，最常见的两个规划错误是：照单全收 agent 给的第一版设计，以及没有实证就在计划上用力过猛。他的做法是“用代码来规划”：做原型、画类型签名，而不是写一份抽象的长计划。

6.1 /architect：先定形状再写实现

人话： 先把“调用方怎么用、类型长什么样、模块怎么分”定下来，再填实现。

/architect design the import pipeline before writing any code. i care most about how callers use it.

预期效果： 它先用 /how（必要时加 /why）摸清相关代码，再用 /arena 生成几份竞争的设计草图，每份都先写调用方的用法，然后是类型、函数签名和模块图。默认它会直接从综合后的设计进入实现。

想先看设计再动手：

/architect with checkpoint. stop and show me before implementing.

Pt.2 里的组合例子（中文大意）：

/poteto-mode 我们需要给外部 webhook 加限流。先 /architect 一下，有悬而未决的问题就用原型来回答。继续之前先让我看一下。

作者还提到：如果实现时发现草图是错的（比如同一种变通写法在不相干的地方反复出现，或者不得不用 any、强制类型转换这类“逃生舱”），agent 应该把草图扔掉重来。

6.2 /arena：同一道题，多人比拼

人话： 像设计比赛。N 个子 agent 做同一道题，各自在自己的目录里交卷；一个只读的裁判（条件允许时用另一个模型家族）按评分标准打分；协调者通读每份答卷，挑一份当底子，再把落选方案里的好点子“嫁接”进来，最后验证。

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

决策很重要时，多要几个候选：

/arena this, 5 candidates. the cache key format is expensive to change later.

想给现有方案找第二意见：

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

6.3 /swarm：把活切片，并行覆盖

人话： 像分组检查。把一件大事切成互相独立的小块，每个工人负责一块、各自检查，最后汇总成一份报告。

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

预期效果： 每个工人报 PASS、ISSUES 或 BLOCKED；父 agent 等所有工人做完，交回一份紧凑的报告，并标出缺口和掉线的工人。

6.4 一定要分清：arena 和 swarm

/arena /swarm
一句话 同题比拼 切片并行
每个人拿到的 同一份设计或代码任务 各自不同的一片（或一条事先声明好的赛道）
最后怎么收 挑底子 + 嫁接最好的部分 + 验证 汇总成一份报告，或按事先定好的规则选胜者
适合 命名、格式、算法、架构等“要选最好答案”的事 覆盖矩阵、逐个包检查、并行跑验证

官方把“用 /arena 做覆盖检查”列为常见坑。

6.5 /interrogate：让别的模型来拆台

人话： 把同一份改动、意图和评分标准，交给几位来自不同模型家族的评审。不同模型盲点不同，两个模型各自独立提出的问题，可信度很高。

/interrogate the whole branch, but skeptically. no nitpicks unless it's an actual bug or regression.

预期效果： 主评审把意见分成 Act on（该改）、Consider（可考虑）、Noted（记下）、Dismissed（驳回，附理由），不会自动改任何东西。驳回的部分也要看，主评审不是神，你可以推翻它。

想严格只读，再加一句 “don’t change anything yet”。

6.6 一个改动值得多少设计？

大部分改动一个都不用。官方给的阶梯：

/poteto-mode 本来就会按这个阶梯走。你直接点名这些 skill，主要是想要比默认更多或更少的审查。

7. 构建与清理：/tdd /unslop /no-comments

7.1 各类构建任务都走 /poteto-mode

心法： 说出你观察到的事实，让流程去要证据。

修 bug，说症状，要求先复现：

/poteto-mode this command emits two records after a retry. repro first, then fix and verify.

做功能，说行为和“什么不能变”：

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

重构，先把行为钉住再动结构：

/poteto-mode move parsing into one module, zero behavior change. record the current output first and prove it's unchanged after.

性能，说测量值而不是感觉：

/poteto-mode startup takes 1.8s on this fixture. trace it, fix the measured cause, show me before and after.

预期效果： 流程会补上你没写的步骤：修之前先复现、实现前先说清数据形状、重构前先钉住行为、优化前先 profile（测量耗时分布）。

7.2 /tdd：先写一个会失败的测试

人话： TDD 是“测试驱动开发”，先写一个能证明 bug 存在的测试（它此刻应该失败），再修，再跑一遍看它通过。

上下文足够时，两个词就够：

/tdd implement

预期效果： 它写一个“因为正确原因而失败”的最小测试，修代码，再跑测试。如果测试需要搭一大堆环境或很脆的 mock（假对象），它会直说，并改用最接近的真实命令检查。别硬塞测试：真实命令往往是更强的证据。

和 bug 流程组合：

/poteto-mode repro the duplicate write first. if there's a cheap test path, /tdd it. then fix and rerun.

7.3 /unslop：清理文字里的“AI 腔”

人话： slop 指粗制滥造、空洞的内容。/unslop 专门清理文字：PR 描述、提交说明、README 等。

/unslop the readme changes, no emdashes

也可以很随意：unslop that, tighten it。

7.4 /no-comments：让“没写这段代码的人”来删注释

人话： 写注释的 agent 会像你护着自己的注释一样护着它们。所以要换一双新眼睛。

/no-comments the diff

预期效果： 它派出一个只读评审（官方叫 Comment Sicko），只保留很少几类注释：许可证头、公开 API 的文档注释、解释代码表达不了的链接、被外部依赖逼出来的行为说明。其余都删。如果注释声称“不要删这个”这种约束，它会建议改成类型、测试或 lint 规则来表达。

7.5 三个清理工具别搞混

改 .ts/.tsx 文件时，可以手动加载 /typescript-best-practices，它不会自动加载。

坑：清理不是可有可无的打磨。满是旁白注释和防御性死代码的 diff，在评审眼里就是没做完。觉得 diff 臃肿，提交之前就说 deslop it。

8. 验证与发 PR

8.1 “能编译”不是证据：Prove It Works

人话： pstack 有一条原则叫 Prove It Works：agent 报告成功之前，必须检查真实产物，而不是用“构建通过了”这种替代品糊弄。你的任务是让“真实产物”变得可检查。

把“完成”的定义写进第一条提示词：

/poteto-mode add json output to this command. text output stays byte-identical, the json parses, both run against the sample project. show me the evidence.

预期效果： 回复里带着确切的命令和输出。检查跑不了时，好的回复会说 “inconclusive”（无法确定）。一个很自信却没有证据的回复，是危险信号。

按改动类型选检查方式：

对一个小改动心里没底，可以用 /blast-radius 找它可能在别处弄坏什么。

8.2 可选但强烈推荐：/create-verification-skill

人话： UI 改动要验证，agent 就得有办法像用户一样“操作”你的应用。验证 skill 就是一份教 agent 怎么启动、操作、取证、收尾的说明书。

/create-verification-skill

预期效果： 它主要“采访”你的代码仓库而不是你，弄清用户会碰什么、应用怎么在本地启动、能用什么驱动它（已有工具优先，否则浏览器/CDP、终端 PTY 或 HTTP）、什么证据能证明行为。它写出 .cursor/skills/verify-<app>/，包含 Launch、Doctor、Drive、Evidence、Cleanup 几部分，以及 features/ 下的 Feature Map（功能地图）。交付前，它会端到端跑通一次；这次证明失败，就别用它的产出。

作者 Pt.1 的重点：验证 skill 是地基。

/maintain-verification-skill

它只会改验证 skill 自己的目录，不碰产品代码；发现产品回归会报告出来，而不是在文档里掩盖。

有了验证 skill（假设生成的叫 /control-app），作者常用这样的提示词（中文大意）：

/poteto-mode 实现 <功能描述>。用 /control-app 验证你的改动，给我看视频和截图当证据

8.3 开 PR

/poteto-mode open the pr. small ordered commits, evidence in the description.

预期效果： Opening a PR 流程在 worktree（git 的独立工作副本）里工作，把改动整理成小而有序的提交，清理 diff 和文字，返回 PR 链接。官方观点：五个窄 PR 胜过一个胖 PR。

8.4 盯 PR：Babysit 流程

人话： PR 一开，麻烦就来了：检查失败、评审留言、主干在动。交给 Babysit 去盯。

/poteto-mode babysit this pr. get it green.

预期效果： 按顺序处理：冲突 → 评审留言 → CI。已知修复合并成一次推送，检查只重跑一次。对评审意见持怀疑态度：真问题就修，噪音就驳回并在帖子里写明理由。它停在“可合并”，从不自己合并，因为合并是另一个决定。

只想问状态：

/poteto-mode check on pr 123. anything outstanding?

8.5 落地一摞 PR：Shipping 流程

“绿”不等于“安全”。

/poteto-mode land the stack.

预期效果： 每个 PR 都由一个新的 agent 独立在线验证（评判改动的 agent 永远不是写它的那个），然后只从最底下开始，合并连续验证通过的那一段，并报告第一个断链的 PR。

9. 过夜自动驾驶

9.1 人话：为什么敢让它过夜跑

一个能验证自己工作的 agent，才敢让它独自干难活。让过夜安全的不是运气，而是三样东西：能检查的完成条件、独立的 worktree、你早上能审计的决策日志。

9.2 完整版“过夜合同”

/poteto-mode im going to bed. migrate every caller to the new parser in a fresh worktree off <base>.
done means zero old callers, all parser fixtures pass, old api deleted.
keep a decision log. don't ask me before committing.
/loop until done. if you're truly stuck after a few hours, stop and write up why.

逐句看它买到了什么：

预期效果： 因为是你事后才看的活，/poteto-mode 会把它交给 /figure-it-out，先设计好阶段再写代码，并接上 /show-me-your-work 的决策日志。每一轮：检查完成条件 → 做最小的合理改动 → 对真实产物验证 → 有进展就提交、没进展就丢弃 → 记一行日志。完成条件不会悄悄放宽来宣布胜利。

9.3 简短版（任务和完成条件已在聊天里时）

im going to bed, keep going autonomously until every fixture passes. do not stop. keep a decision log i can audit in the morning.

9.4 早上审计：决策日志

人话： 决策日志就是一张表，每一行记：时间、阶段、做了什么决定、理由、证据在哪、结果。默认写在 decisions.tsv（多个任务共用目录时在 .audit/<task-slug>.tsv），默认只存在本地。

/show-me-your-work catch me up on what you did last night

预期效果： 交回总结之前，它会派一个另一个模型家族的评审去读日志和记录，回复末尾有一个 Attention 部分，列出值得你细看的地方。先看这部分，再看它指向的日志行。你在审计决策，不是重读一整夜。

9.5 autonomous / orchestrate / autopilot 用人话说

名字 人话 示例提示词
Autonomous run 一个任务、一个完成条件，用 /loop 自己一直跑到完 上面的过夜合同
Autopilot-full 一队互相独立的 PR，每个 PR 有一个负责人 agent 从构建跑到合并；负责人不能凭自己的判断合并，要由新的验证者给出干净结论 /poteto-mode full autopilot on this queue. each item is independent. i want them merged by morning.
Autopilot-stack 同样的负责人循环，但不合并；你早上收到一摞每一环都有验证结论的 PR，自己审、自己落地。改动互相耦合或想亲眼看过再合时选它 /poteto-mode autopilot these five changes but stack them, don't ship. i'll land the stack in the morning.
Orchestrate 跨好几天、很多 PR、一群子 agent 的大项目，由一个常驻协调者聊天来派活、收活，协调者自己不写代码。故意很重；一个 agent 一次能做完的活，它会把你打回过夜合同 /poteto-mode orchestrate the store migration. own it until every package is converted and merged. i'll check in twice a day.

坑：时长不是完成条件。 “work on this for 4 hours” 让 agent 无从检查，你醒来看到的是四小时的忙碌，而不是结果。给 /loop 一个能“过”或“不过”的判断。

10. 用原则名字“方向盘”式纠偏

人话： pstack 带了 24 条原则，每条都是一个 skill。你不用主动调用它们；/poteto-mode 每次做多步任务时会读原则索引，并在回复里说明用了哪条、改变了哪个决定。你可以直接说原则名字来纠偏，一个短语比一段长指令更准。

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

apply prove it works. run the real import flow and show me the written records.

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

跑偏时的一句话纠正：

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.

回复太专业看不懂？就一个词：

/bro

预期效果： /bro 把上一条消息用人对人说话的方式重说一遍，没有术语，更短。

判断它是真用了原则还是在“报菜名”：回复里引用原则却说不出改变了哪个决定，就是只报了名字。

11. /automate-me：做一个属于你自己的 -mode

人话： poteto-mode 是作者一个人的工作风格。底下那套机器（流程、路由、模型角色）换成你的风格一样好用。

/automate-me

预期效果： 你不用描述自己的风格。它会挖你在当前工作区最近的聊天记录，找你反复表现出来的偏好（喜欢怎样的回复、怎么分派、怎么验证、代码和文字风格、流程习惯），再问你哪些真的是你。然后通过 Cursor 自带的 create-skill 流程起草 .cursor/skills/<你的名字>-mode/SKILL.md，用 /unslop 过一遍，最后在 worktree 里开一个 PR 给你审。

习惯变了就更新：

/automate-me update my mode skill with everything since its last edit

相关工具：

/reflect that took way too long. capture what we learned so the next run doesn't repeat it.

/poteto-mode write a skill for verifying database migrations in this repo

/poteto-mode run the eval playbook on this skill change. same task for both variants, candidates stay blind.

坑：skill 在任务中途表现不好，别在任务里顺手改它。单独开 PR 修，让当前任务继续。

12. 常见问题 FAQ

Q1：/poteto-mode 路由选错了流程怎么办？

Q2：token 太贵怎么办？

依据现有资料能说的有这些：

Q3：中文资料、移植版和官方不同步？

learn-pstack 是非官方中文学习站，说明里写明和 poteto 没有隶属关系、不发行中文版插件，译文对照的是 cursor/plugins 仓库的 pstack/ 目录。pstack 版本更新很快（例如 0.15.3 前后默认模型就有变化），所以遇到不一致，以 GitHub 官方仓库为准，并留意查阅日期。本文也一样。

Q4：同时开几个 agent，它们在同一个工作区里打架？

多个 agent 共用一个工作树会互相覆盖文件，diff 变成考古现场。开工时就说清楚要隔离：

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

或者“own worktree per attempt”（每次尝试一个独立 worktree）。worktree 多了占磁盘，可以：

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

它只删证据确认可删的，有未提交改动的会停下来问你。作者在 Pt.1 里还提到，并行规模大时，他更推荐用 Cursor 的 cloud agents 而不是本机 worktree。

Q5：构建是绿的，agent 说成功了，可以信吗？

不能直接信。构建只证明能编译。要它拿出真实命令、真实流程、读回来的存储值或 profile，并在回复里附上证据：

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

同理，PR 检查全绿也不等于安全，落地前走 Shipping 流程做独立验证。

Q6：我在提示词里列了一串 skill，结果反而更乱？

正常。流程已经排好了 skill 顺序，手写清单会打乱或漏步骤。说目标和约束，只在想推翻默认时点名某个 skill。

Q7：我在 /setup-pstack 里把模型写成 auto，是选了一个叫 auto 的模型吗？

不是。auto 和 inherit-parent 都表示“不填模型字段，让子 agent 继承父聊天的模型”，它们不是模型 slug。

Q8：配完模型好像没生效？

规则只对新会话生效，配完请开新聊天。如果规则文件是 0.15.3 之前写的，可能钉死了旧默认模型：删掉对应角色行，或删掉 ~/.cursor/rules/pstack-models.mdc，再跑一次 /setup-pstack。

Q9：完成条件写成“make it better”或“跑 4 小时”行不行？

不行。/loop 需要一个能“过”或“不过”的检查，比如一条命令、一个产物、一组 fixture 全部通过。

Q10：评审意见要全部照改吗？

不用。人和机器人的评审都混着真问题和噪音。/interrogate 会把意见分成该改和驳回两类并附理由，你可以从两个方向推翻它。

附：资料链接

37Flow 整理，非官方。查阅日期 2026-10-05。