pstack 拆解 17 · 让 agent 能在应用里自证
验证是承重柱,而它最慢的一步是在等一个人。让 agent 能自己驱动真实应用、自己取证,就是把"等人"从关键路径上拿掉。
create-verification-skill
验证是承重柱,而它最慢的一步是在等一个人:agent 改完,把结果交回给你手工检查。让 agent 能自己驱动真实应用、自己留下证据,就是把"等人"从关键路径上拿掉。一次投入,之后每一次运行都受益,所以它是 setup 里回报最高的一件事。
create-verification-skill 生成一个项目本地的 skill,教 agent 像用户那样驱动你的应用,并留下证据。
如果 setup 里只做一件事,做这一件。原因是它改变的不是一件事,是所有事的上限。guide 里点得很清楚:一个能自证的 agent,会一直跑到检查通过;一个不能自证的 agent,把每一个结果都交回给你手工检查。你花一次力气换来的,是之后每一次运行都不再需要你来当验证的瓶颈。
它跑起来是去 interview 仓库,不是 interview 你。它自己回答五个问题。
- Surface:用户到底碰什么?web UI、CLI/TUI、桌面应用、API、移动端,还是一个库?一个仓库可能有好几个,选主要的,其余的记下来。
- Run:本地怎么启动?优先用仓库自己记录的命令(package scripts、Makefile、README 的快速开始),记下端口、环境变量、种子数据、鉴权。
- Drive:agent 怎么程序化地交互?已有的 harness 优先:Playwright 或 Cypress 的用例、expect 脚本、PTY 助手、可以 curl 的端点、一个调试端口。实在没有,才选通用方案:web 和 Electron 用浏览器加 CDP,CLI/TUI 用 tmux 或 PTY,服务用纯 HTTP。
- Observe:能抓到什么证据?截图、终端记录、响应体、日志、退出码、数据库状态。
- Isolate:能不能并排跑两个实例(端口、数据目录、profile)?不能的话,要在生成的 skill 里写清楚:拒绝同时驱动一个共享实例,比弄坏用户的会话好。
它只问你代码答不上来的部分。而且有一个前置条件:如果这个 checkout 现在根本构建不起来或者启动不了,先修那个,再生成。 一个建立在坏地基上的验证 skill,会教出一串错误的步骤。
输出是 <skills>/verify-<app>/,一份面向 agent 的指令,包含精确的五节。
- Launch:启动应用进行验证的确切命令,以及怎么判断它准备好了(一行日志、一个端口回应、一个提示符),还有拆解方式。短命的 CLI 或 TUI 没有要一直活着的服务器,启动就是"构建一次二进制",然后每次驱动开一个自己的 PTY 或 tmux 会话。
- Doctor:一个只读的检查,回答"这个实例值不值得驱动":进程活着、版本或构建对、端口是自己的、鉴权有效。agent 在遇到任何不对劲时,第一件事就是跑它。
- Drive:带着这个仓库真实选择器和命令的 harness 配方,不用示例。优先稳定的句柄(ARIA 标签、data 属性、提示符字符串、路由路径),不用坐标和 tab 顺序。
- Evidence:一次证明要抓什么,放到哪里。它规定了证明的标准:走真实的用户路径,不走内部 setter 或测试专用端点;抓动作和它导致的状态,不只抓最后一屏;在可见结果之外验证副作用(写进去的文件、插入的行、发出的消息);只在生产边界已经隔离了外部系统的地方用 mock。还有一个很实在的提醒:当安全路径是一个 dry-run 或测试模式时,要靠观察(文件、网络、git ref)确认它到底跳过了什么,不要信它的名字,因为有些 dry-run 还是会碰网络或打开浏览器。
- Cleanup:怎么拆掉这次运行创建的实例。绝不按进程名杀,只杀自己启动的。清理移除实例和临时状态,绝不移除证据:证明产物要在拆解之后活下来,放在 skill 指定的位置。
再加一个 features/ 目录下的 feature map,每个功能一个文件,从用户视角回答:这是什么、怎么到达、怎么驱动、什么可观察的终态能证明它工作。起步先做最上面的三到五个,从路由、命令、菜单或文档里找。四个固定的二级标题是 Sub-features、How to get to it (user POV)、Driving it with <harness>、Gotchas。
它有一条纪律不能省。生成器在交给你之前,自己把这个 skill 端到端证明一遍:启动,跑 doctor,驱动一个功能(一个就够,feature map 的意义就是让以后的运行覆盖其余),抓证据,清理。而且清理之后要确认证据还在原处,一个会吃掉证据的 cleanup 这一关就算失败。这一步没过的输出,不要用,它是一个草稿,不是一个交付物。
从此刻起,"在应用里验证它"变成这个仓库里任何 agent 都能执行的一步,不需要一次设置对话。这个 skill 应该提交进仓库,当成基础设施。
参考
原文都在 pstack 上游仓库(cursor/plugins):