企业官网建设流程全解析

让 Cursor Agent 自主完成长任务：pstack Autonomous Run Playbook 实战指南

【免费下载链接】pluginsCursor plugin specification and official plugins项目地址: https://gitcode.com/GitHub_Trending/plugins125/plugins

Autonomous Run Playbook（pstack/skills/poteto-mode/playbooks/autonomous-run.md）是 pstack 插件中面向"无人值守长任务"的核心运行规范：它以**可检查的退出条件（predicate）**为唯一驱动力，让 Agent 自主循环迭代、自我处置中途发现的问题，直至条件满足才停止。本文围绕该 Playbook 的六步工作流展开，结合 pstack 的 mode 技能、principle 技能与配套 Playbook（show-me-your-work、sequence-verifiable-units、opening-a-pr等）的源码级细节，说明如何配置唤醒机制、如何判定迭代去留、如何检查点留痕，以及何时应当"停下来问人"——最终交付一份可复盘、可追溯、绝不虚报胜利的自主运行方案。

一、什么是 Autonomous Run：适用场景与定位

在 pstack 的 Playbook 体系中，autonomous-run.md服务于这样一类任务："run until done"、"/loop until X"、"我要去睡觉了，明天早上之前把它做完"。它的定位在 pstack 主技能文档 中被明确描述为：

Autonomous run.A long task to drive to completion without stopping.

它与同族 Playbook 的边界需要区分清楚：

• Autonomous run：驱动一个任务直到满足某个谓词（predicate）为止；
• Orchestrate：一个持续多日、由单一协调者 chat 掌管、横跨多个堆叠 PR 与数十上百个子 Agent 的常驻项目；
• Autopilot-full / Autopilot-stack：针对"一批互相独立的 PR"或"一条线性堆叠分支"的批量自动处理。

正如 pstack 主技能 所指出的，能在单个会话预算内由一个 Agent 完成的工作应路由到 Autonomous run，哪怕它的措辞听起来像"项目"；反之，跨多日、多 PR 的常驻程序才路由到 Orchestrate。先确认任务形态，再选 Playbook，这是使用本指南的第一步。

二、核心心法：你拥有退出条件

Playbook 的开篇只有一句话：

You own the exit condition. Define done, then drive to it without stopping.

（你拥有退出条件。先定义"完成"，然后不停歇地驱动它。）

这一心法可以拆解为两个可操作的语义：

1. "完成"不是感觉，而是可检查的谓词（checkable predicate）。它必须能被机械地判定真假，例如：测试全绿、复现问题已修复、N 个 PR 全部合并、像素级对比为零差异。
2. 在第一次迭代之前就要把它写出来，而不是边做边定义。这保证了整个运行过程始终有一个客观的"南北极"。

这一设计并非孤例，而是 pstack 整个验证哲学的自然延伸：principle-prove-it-works要求"对真实产物验证，而不是对代理品或'它能编译'来验证"，而 Autonomous run 把这条原则从"单个任务结束时的检查"升级为"整条运行主线的锚点"。

谓词的写作规范

Playbook 给出了四个可复制的谓词示例：

写作要领：谓词必须落在可以被命令、脚本或查询判定的事实上，禁止使用"看起来差不多了""我觉得可以了"这类无法验证的主观表述。

三、选择唤醒机制：/loop命令与 watcher 子代理

自主运行的第二个关键决策是：谁在什么时候叫醒你。Playbook 第 2 步明确：

Pick the wake mechanism using Cursor's/loopcommand (a built-in, not a pstack skill).

也就是说，/loop是 Cursor 的内建命令，pstack 并不重新实现它，而是与它协作——这一点在 pstack README 中也有呼应："/poteto-modeworks extremely well with cursor's/loopcommand. you can make cursor work for many hours without sacrificing rigor."（/poteto-mode与 Cursor 的/loop配合得极好，你可以让 Cursor 连续工作数小时而不牺牲严谨性。）

唤醒机制的选型遵循一张简单的决策表：

对应到 pstack 的源码实现，/loop与 watcher 机制在 poteto-mode 的脚本目录 中有可复现的支撑：bootstrap.ts负责初始化运行环境，watch-pr/子目录承载 PR 状态监听逻辑，check-plan.mjs用于校验计划状态，worktree-audit.sh用于审计 worktree。这些脚本共同说明："唤醒"不是靠 Agent 凭空自醒，而是有实际可执行的监听与检查载体（详见pstack/skills/poteto-mode/scripts/）。

一个务实的选型建议：有事件就监听事件，没事件就按周期复查。监听事件比固定轮询更省算力、响应更快；而心跳间隔的长度应该以"这个结果多久值得再看一次"为准，而不是越短越好。

四、迭代纪律：最小变更 + 证据验证 + 去留判定

第 3 步定义了每一轮迭代的"单位操作"，这也是整个 Playbook 中操作性最强的部分：

Each iteration makes the smallest change the evidence justifies, verifies it against the predicate, commits if it advanced, discards changes that didn't help. Belt-and-suspenders that "might help" gets reverted, not left to ride.

逐句拆解其工程含义：

1. 做证据允许的最小变更。这与核心原则技能principle-laziness-protocol（"偏向删除与解决该问题的最小变更"）和principle-subtract-before-you-add（"先移除死重，再在更简单的基础上构建"）一脉相承。
2. 用谓词验证它。每轮变更都对着退出条件跑一次检查，而不是攒到最后统一验证。
3. 推进了就提交；没帮助的就丢弃。这是关键的去留判定："可能有帮助"的保险性改动（belt-and-suspenders）一律回滚，绝不让它搭车留在代码里。理由是：未被证据支持的改动会污染 diff、增加评审负担，而且与principle-test-behavior-not-implementation的"只保留被行为验证的代码"精神一致。

用 sequence-verifiable-units 给工作排序

Playbook 第 3 步末尾要求：用principle-sequence-verifiable-units技能来编排工作顺序。该原则技能给出了"红到绿逐单位推进"的范式：

• 选择最小的、以检查收尾的单位：一次编辑加它的测试，或一个能独立成立的 commit；
• 推进前先验证：每个单位红到绿，绝不推迟到最后一批再检查；
• 按顺序交付：让序列本身成为论据——对执行者而言逐步建立信心，对评审者而言可重放"先红后绿"。

其原理文档（pstack/skills/principle-sequence-verifiable-units/SKILL.md#L11）给出了为什么这样做：在引发问题的那个单位就抓住它，定位成本最低；等到成批检查时才暴露，错误已经被埋进更深的构建里。在 Autonomous run 的语境下，这条纪律意味着：自主运行不是"闷头改完再验证"，而是"每改一小步就对着谓词验证一步"。

五、中途发现：你来处置，不抛回给人类

第 4 步定义了自主运行最重要的边界：运行过程中发现的任何问题都属于你。Playbook 明确列出了一个"发现清单"：

• broken skills（技能文件坏了）
• related bugs（相关问题）
• flaky verifiers（不稳定的验证器）
• review noise（评审噪音）
• tooling failures（工具链故障）
• orphaned follow-ups（无主的后续事项）
• fixable drift（可修复的漂移）

处置规则：

1. 通过 poteto-mode 自行处理。这呼应了 pstack 主技能 中"Broken skill mid-task → fix it in its own PR. Don't block. Don't silently work around it."（任务中途技能坏了 → 放进自己的 PR 修复，不要阻塞，不要默默绕过）的触发规则。
2. 带外修复（out-of-band fixes）放进自己的 PR。主任务与旁路修复分 PR 提交，互不污染。
3. 可逆工作绝不搁置等人，也绝不使用AskQuestion。这正是principle-never-block-on-the-human的落地：代码变更可逆、可评审，错误决策的代价通常低于阻塞的成本，所以"先做，再呈现结果"。
4. 只在三种情况下才向人类浮出：
   • 不可逆动作（force-push 到共享分支、部署、删数据、给客户发消息——参见 pstack 主技能 的 Autonomy 章节）；
   • 真正的产品决策或偏好取舍，任何实验都无法裁决；
   • 真正的死胡同（real dead end）。
5. 谓词始终是主驱动。每次旁路修复之后都要回到谓词继续推进，不能让中途发现把主线带偏。

这一节的要点可以浓缩为一句话：可逆的事自己做掉并记录，不可逆的事才停下来问；旁路修复单开 PR，主线永远回到谓词。

六、检查点留痕：show-me-your-work

第 5 步要求每一轮迭代都通过show-me-your-work技能做检查点：

Checkpoint every iteration via theshow-me-your-workskill, a row for what changed and whether the predicate moved.

（通过 show-me-your-work 技能为每次迭代做检查点：一行记录"改了什么"以及"谓词是否推进了"。）

该技能规定了一个标准化的审计格式：单个 TSV 文件，每个决策一行，列结构为ts / phase / decision / why / evidence / result（pstack/skills/show-me-your-work/SKILL.md#L15-L22）：

技能的几条硬性规则（pstack/skills/show-me-your-work/SKILL.md#L48-L54）在自主运行中尤其重要：

• 一行 = 一个决策或检查点；对于循环运行，每轮迭代一行；
• 只追加（append-only）：错误的决定用新行覆盖，绝不编辑或删除历史；
• 本地优先：默认放在工作目录的decisions.tsv（或多个并行任务时放.audit/<task-slug>.tsv），仅在任务重要到评审者需要审计轨迹时才提交入库；
• 推荐使用辅助脚本scripts/log.sh <logfile> <phase> <decision> <why> <evidence> <result>写入（它会自动盖时间戳、首次使用时写表头、剔除制表符与换行、并为以=、+、-、@开头的单元格加单引号前缀，防止电子表格公式注入）。

运行结束时还有两道收尾工序：对照 transcript 审计日志（每行都能对应到真实动作、证据可解析、遗漏的分叉与放弃方案要补上、删掉填充性条目），以及跨模型复核（用与执行者不同模型族的子代理扫描审计轨迹，找出弱证据决策、跳过验证的环节、事后看来有风险的取舍，并以 "Attention" 章节 +reviewed by <model>行收尾）。对无人值守的长任务来说，这份 TSV 就是让"我信任你做完的事"变得可验证的关键载体。

七、何时停止：谓词满足即止，平台期不是终点

第 6 步定义了终止语义，也是全篇最容易被人性弱点击穿的地方：

Stop when the predicate is met. A plateau is not a stop, so keep going and pivot your approach to push past it. Surface a genuine dead end rather than spinning, and never relax the predicate to declare victory.

三层规则：

1. 谓词满足即停止。这是唯一的合法终止点。
2. 平台期（plateau）不是停止。当迭代不再推进谓词时，正确的动作是换一种方法（pivot）继续推进，而不是停在原地。这对应 pstack 中"攻击前提"（principle-attack-the-premise：连续两次修复共享同一前提且都失败，就该质疑前提本身）与"穷尽设计空间"（principle-exhaust-the-design-space：无先例的决策，先构建 2-3 个竞争性原型再取舍）的原则。
3. 真正的死胡同要浮出，而不是空转。如果证据表明此路不通，就把死胡同如实呈现（这是第 4 步允许向人类浮出的三种情况之一）。
4. 绝不为宣布胜利而放松谓词。"把标准降低到能宣称完成"是自主运行最危险的反模式——它同时背叛了退出条件的客观性（第 1 步）和 prove-it-works 的真实产物验证原则。

八、收尾交付与 PR 规范

Playbook 最后规定了一次运行结束后的回复格式：

Reply:the exit condition, iterations run, what landed, what was discarded, final predicate state.

（回复应包含：退出条件、运行的迭代次数、落地了什么、丢弃了什么、谓词的最终状态。）

这份回复清单本身就是一个结构化的运行报告模板，五要素齐全：目标（退出条件）、过程（迭代数）、成果（落地内容）、反悔（丢弃内容）、结果（谓词终态）。

由于 Autonomous run 属于 pstack 全 Playbook 体系的一员，其产物在落库时还要遵守 opening-a-pr 规范：

• worktree：从 main 开 git worktree 工作，子代理继承；脏分支先 patch 出来、开全新 worktree、再 apply；
• 提交：liberally 提交，rebase 成小的、有序的、每个都能单独成为未来 PR 的 commit；
• PR 写作：提交前跑cursor-team-kit的/deslop，评审前跑/no-comments，标题用 Conventional Commits（type(scope): subject，如fix(pstack): retarget opening-a-pr babysit trigger），正文按## Why / ## Scope / ## Tradeoffs / ## Blast Radius / ## Verification顺序组织；
• 尺寸：偏好 5 个窄 PR 而不是 1 个大 PR；堆叠（stack）时子分支 rebase 到父分支精确 tip，PR 以父分支为 base；
• ready 即开：绝不 draft 开 PR（gh省略--draft，Origin 传--status open）；
• 不开 PR 不 babysit：开 PR 之后继续构建，不逐 PR 停下游说评审。

把这些规则叠加到 Autonomous run 上，得到的最终形态是：一个自主驱动到谓词满足的长任务，其全部产物都以干净、有序、可独立合入的 PR 形态落地，并附带一份可审计的决策轨迹。

九、完整流程速览与实践清单

把六步串成一张可复制的运行卡片：

1. 定义谓词：在第一次迭代前写出可检查的退出条件（tests green / repro fixed / all N PRs merged / pixel-diff zero）。
2. 选唤醒机制：用 Cursor/loop；有事件就配 watcher 子代理 + 长心跳兜底，无事件就固定间隔心跳。
3. 迭代最小变更：每轮做证据允许的最小改动 → 对谓词验证 → 推进则提交、没帮助则丢弃 → 用 sequence-verifiable-units 排序，逐单位红到绿。
4. 自行处置中途发现：坏技能、相关 bug、不稳定验证器、评审噪音、工具故障、无主后续、可修复漂移都自己处理，带外修复单开 PR；仅不可逆动作 / 实验无法裁决的产品取舍 / 真死胡同才问人；处理完回到谓词。
5. 每轮检查点：用 show-me-your-work 写一行 TSV（改了什么、谓词是否移动）；运行结束做 transcript 审计 + 跨模型复核。
6. 谓词满足即停：平台期就 pivot 换方法；真死胡同如实浮出；绝不放松谓词宣布胜利。
7. 收尾回复：退出条件 / 迭代次数 / 落地内容 / 丢弃内容 / 谓词终态；产物按 opening-a-pr 规范以有序 PR 落地。

实践红线（对应各原则技能）：

• 可逆工作不阻塞等人（never-block-on-the-human）；
• 每个检查对真实产物验证，而非"能编译"（prove-it-works）；
• 未被证据支持的改动一律回滚，不让"可能有用"搭车（laziness-protocol / test-behavior-not-implementation）；
• 审计日志只追加、证据可解析、跨模型复核（show-me-your-work）。

延伸阅读：想进一步理解本 Playbook 的运行环境，可继续阅读 pstack 主技能文档（含 Autonomy 边界与全部原则索引）、sequence-verifiable-units 原则、show-me-your-work 技能、opening-a-pr 规范，以及 pstack 项目 README。Autonomous run 与 orchestrate.md、autopilot-full.md 等相邻 Playbook 的边界划分，也建议一并对照阅读。

【免费下载链接】pluginsCursor plugin specification and official plugins项目地址: https://gitcode.com/GitHub_Trending/plugins125/plugins