pstack 拆解 23 · 可审计与定制流程
无人值守的信任,不能来自事后的自述,要来自一份运行中一行行写下的轨迹;而任务形状装不进现成流程时,要为它定制一个。
show-me-your-work
show-me-your-work 让长任务和无人值守的工作可审计。你不在场的时候,信任从哪里来?它不能来自事后的自述,因为自述和事实之间没有核对;它来自一份在运行过程中一行行写下的决策轨迹,加上一次跨模型的复审。这就是"先要证据"用在无人值守上的形态。
它维护一份决策日志,一个 TSV,一行一个决定。列是固定的。
- ts:ISO8601 时间戳。
- phase:阶段或工作流。
- decision:选了什么或做了什么,一行。
- why:用大白话写的理由。如果一个原则驱动了它,就平实地写出来,不要写成一个术语标签。
- evidence:一个证明它的链接或路径:commit SHA、PR 号、
file:line,或者一个产物、trace、截图路径。永远不是一段话。 - result:结果或谓词状态,像
tests green、reverted、pixel-diff 0、INCONCLUSIVE、open。
它有一条关于"写入方式"的细节:它提供一个小助手 scripts/log.sh 来写行,这个助手会盖时间戳、首次使用时写表头、剥掉多余的 tab 和换行,并且给任何以 =、+、-、@ 开头的单元格前缀一个单引号。最后一条是在防注入,因为一个 TSV 单元格以 = 开头,在表格软件里会被当成公式。
它记录的是决策点,不是每个动作:一个选定的分叉、一个完成并验证过的单元、一次带触发原因的转向或回退、一个浮出来的阻塞、一个修好的关卡。循环运行时,一次迭代一行。
它有几条硬规矩。日志只能追加。一个错误的决定用一行新记录去取代它,永远不编辑或删除历史。而且它偏好由提交过的脚本产出的证据,而不是手工做的一次性产物。
它默认是工作产物,不入库,放在工作目录的 decisions.tsv,或者多个任务并行时放在 .audit/<task-slug>.tsv。只有当工作足够大、reviewer 需要这份轨迹才敢信任结果时,才提交它。
它在结尾还有两个动作。
一个是对着 transcript 审计日志。交回给你之前,它读这次运行的 transcript,把每一行和真实发生的事对一遍:每一行是否对应一个真实的决定或动作;每行的证据是否能解析、是否显示了它声称的东西;一个影响了工作却没被记下来的分叉、转向或放弃的思路,是一个缺口,要补上。它纠正日志,不纠正故事:审计从不编辑或删除一行,哪怕是一行编造的。当一行既不对应真实决定、也不对应真实动作,或者它的说法或证据是错的,就加一行取代它。("你不该把发现向上取整成一句确定的话"在这里也适用。)
另一个是跨模型复审。它起一个不同模型族的 subagent,读这份日志和 transcript,标出你该注意的地方:证据薄弱的决定,声称验证过但 transcript 里没有证明的步骤,事后看有风险的取舍,以及你随便一瞥会漏掉的缺口。回复以一段 Attention 收尾,第一行是复审用的模型名,然后是每一条指向具体行或时刻的标记。"没有标记"也是一个有效值,但模型名不能空。那一段就是你要读的第一段。
figure-it-out
figure-it-out 是当一个任务匹配不上任何更窄的 playbook 时,给你定制一个 playbook 的 skill。任务的形状决定流程;没有现成流程能装下它,就为这个任务设计一个,而不是硬塞进一个近似的模板。它的交付物在代码之前:先是一套可审计的工作流,然后才执行。
它的交付物,在任何代码之前,就是那套工作流本身。它分五个阶段。
Phase A:Frame。 先 grounding,再承诺。它要求你能说出三件事:把 done 定义成一个可证伪的谓词;量化范围(大概多少单元、多少工时、有哪些阻塞);以及严谨程度(偏向高,单向门和高影响面的工作要更多,可逆的低风险步骤要少)。它会在跳进一个长跑之前把框定和权衡present 给你看。可逆的工作直接做,但一个多小时的运行值得一个检查点。
Phase B:设计工作流。 把工作拆成原子、可独立落地的单元,先做风险最高的未知。脚手架和验证排在功能之前:先在改动前的状态上捕获基线,这样检查读起来是"旧值对新值"。单向门的设计决定跑 architect(它内部跑 arena),机械的、形状已定的工作跳过它。决定哪些能 fan out,只在接缝处并行,给每个 worker 自己的 worktree 或分支。然后把这个设计好的阶段列表写下来,那份列表就是给人审的东西。
Phase C:跑循环。 每个单元是一个实验。写下假设,做最小改动,对着谓词在真实产物上测量,前进了就留下,没前进就回退。用 sequence-verifiable-units 的纪律,每个单元验证过再开始下一个,而不是把检查攒到最后。验证靠检查产物,绝不靠自述;当某件事过得太容易,先怀疑观察方法,再怀疑系统。委派的活配一个 judge。如果一个 worker 在钻关卡的空子,重置并收紧契约;如果关卡本身错了,在它自己的改动里修关卡,不要绕过它。判决只有三种:VERIFIED、NOT VERIFIED、INCONCLUSIVE,而且 inconclusive 不是 pass,不许藏一个负面的结果。
Phase D:留审计轨迹。 用 show-me-your-work 记日志。figure-it-out 的工作通常足够大,值得把轨迹提交上去,让 reviewer 能在 PR 里读它。轨迹加 diff,就是让人回来时敢信任这份工作的东西。
Phase E:验证并交回。 对着 Phase A 的谓词在真实产品上检查整体,而不只是在 harness 上。把任何反复出现的纠正编码成一个关卡、一条 lint、一个检查或一个脚本。
它和 orchestrate 的分工值得说清:figure-it-out 设计一次定制的运行,是那个跑完就结束的东西;orchestrate 运转一个程序,跨多天、很多堆叠的 PR、一支 subagent 舰队,由一个常驻的协调者带着。
参考
原文都在 pstack 上游仓库(cursor/plugins):