AI Code With
开发教程Developer Workflow

AI 写的代码怎么验收？审 diff 之外，用 verification skill 驱动真应用（Cursor pstack）

验收 AI 改动不要停在「编译过了」或只审 diff。本文分清开 PR 前的 AI 代码审查与 verification skill（驱动真应用留证据），并对照 Cursor pstack 的 /create-verification-skill：安装链、Launch/Doctor/Drive/Evidence/Cleanup、feature map 与 Prove。无未复现的耗时数字。

4 分钟阅读
AI 写的代码怎么验收？审 diff 之外，用 verification skill 驱动真应用（Cursor pstack）

Coding Agent 越来越敢改仓库，验收却还常停在两件事：编译过了，或开 PR 前让另一个模型读一遍 diff。前者只说明能构建；后者擅长找逻辑坑、漏测和风格问题，但都不等于在真应用里按用户路径跑通。评测一个 agent、验收一段 AI 写的功能，至少要分清这两层。

开 PR 前的 AI 代码审查（读 diff、找问题）可以走站内场景 AI code review。本文讲另一层：怎么给仓库装上「驱动真应用并留下证据」的 verification skill——Cursor 官方插件 pstack 的 /create-verification-skill 就是干这个的。

流程与章节名对照 create-verification-skill/SKILL.md raw、安装指南 与 Verify and ship。这次没有在真实业务仓完整跑生成器并计时，故不写未复现的秒数或截图张数。

先说结论：

  • 评测 / 验收 AI 改动：审 diff（找代码问题） 与 verification skill（驱动真 App 做端到端证明） 是两套工具，别互相替代。
  • 要第二套时，Cursor 安装链：/add-plugin pstack → /setup-pstack → /create-verification-skill。
  • 生成物：.cursor/skills/verify-<app>/；正文含 Launch / Doctor / Drive / Evidence / Cleanup（+ Helpers）与 features/ 地图。
  • 生成器须自己 Prove 一遍；Cleanup 后证据还在才算交付。disable-model-invocation: true，须显式调用。

创建 API Key →

两层验收：审 diff vs 驱动真应用

层在干什么证明什么典型入口
开 PR 前 AI 审 diff读变更代码，找缺陷、漏测、风险「这段改动在代码层面说得通 / 有问题」AI code review 场景
Verification skill启动真应用，按用户路径点/敲/调，抓证据「功能在运行中的 App 里可观测地成立」/create-verification-skill → /verify-<app>

审 diff 不会替你点按钮、看页面、查副作用是否落库；verification skill 也不会替代静态审查里的设计讨论。完整验收通常两层都要：先（或并行）用代码审查挡低级错误，再用 verify skill 证明用户路径。只做一层，都容易误判 Coding Agent「看起来很能干」。

若你主要缺的是 PR 上的自动/半自动 diff 审查，先看 https://aicodewith.ai/en/use-cases/ai-code-review；下面专讲怎么把「真应用证明」装进仓库。

Verification skill 解决什么

官方开篇大意：每个认真项目都要有一套按用户方式驱动真 App 的脚本化证明——启动、操作、抓证据。没有的话，Agent 只能口头汇报，人又变回瓶颈。

生成出来的是仓库基础设施：提交进 git，人和 Agent 共用。任务里点名 /verify-<app>（名字随生成结果），例如官方指南：

text
/poteto-mode build the bulk-archive action. use /verify-<app> to verify your changes and show me a video and screenshots as proof.

安装：/add-plugin pstack → /setup-pstack → /create-verification-skill

按 01-setup.md：

1. 装插件

text
/add-plugin pstack

2. 配模型与预算

text
/setup-pstack

写入 ~/.cursor/rules/pstack-models.mdc；规则对新会话生效，setup 后建议新开 chat。

3. 生成验证 skill

setup 若发现没有 verify-* 或现成 harness，会提议一次跑 /create-verification-skill。也可稍后手动：

text
/create-verification-skill

Claude Code：官方路径是 /plugin marketplace add cursor/plugins，再 /plugin install pstack@cursor-plugins；命令带 pstack: 前缀（如 /pstack:setup-pstack），规则写到 ~/.claude/rules/pstack-models.md。

为什么必须显式调用

create-verification-skill 的 YAML 头（raw）含：

yaml
disable-model-invocation: true

模型不会因「好像该验收了」自动跑生成器。/maintain-verification-skill 同样带此开关。自己写 Skill 的触发规则见 怎么写 SKILL.md；通用安装见 Agent Skills 怎么用。

生成器五步（对齐官方 SKILL.md）

1. Interview the repo

从代码推断，问不清再问人：

轴要搞清楚什么
Surface用户碰什么：Web / CLI·TUI / 桌面 / API / 移动 / 库
Run本地怎么起：优先仓库自带 dev 命令；端口、环境、种子、登录
Drive先用现成 Playwright/Cypress/expect/PTY/curl；再退到 CDP / tmux·PTY / HTTP
Observe截图、终端记录、响应体、日志、退出码、DB
Isolate能否并排两份实例；不能则写明宁可不双开

仓库起不来先修。为启动临时补的无关资产须标成 verification scaffolding，Cleanup 删除。

2. Generate skill

写出 .cursor/skills/verify-<app>/SKILL.md：name: verify-<app> + 点名表面的 description（无 frontmatter 不注册）。正文必须落地访谈结果：

  • Launch：启动命令 + ready 判据；空数据目录到可用态；含 teardown。短命 CLI：先构建，再在隔离 PTY/tmux 里 drive。
  • Doctor：只读「这实例还值得开吗」。
  • Drive：本仓库真实选择器/命令，优先稳定句柄。
  • Evidence：抓什么、放哪；真用户路径；动作+结果态；副作用；dry-run 靠观察确认。
  • Cleanup：只杀自己起的；证据必须留下并写明路径。
  • Helpers：脚本可执行，调用写在正文。

3. Seed feature map

创建 features/README.md + 每功能一文件（先 3–5 个）。形状见官方 feature-map-example。我们核对过示例里四个 H2：

  • Sub-features
  • How to get to it (user POV)
  • Driving it with <harness>（示例为 Driving it with control-notes）
  • Gotchas

缺前置条件应失败并写入 Gotchas，不许为绿削弱旅程。

4. Prove

text
launch → doctor → drive 一个已映射 feature → evidence → cleanup

Cleanup 后确认证据仍在——删证明的 cleanup 算失败。从未执行过的生成物只是草稿。替身环境须列出多做了、真目标不会做的步骤。

5. Offer maintenance

指向 /maintain-verification-skill：结局 clean / changed（最多一 PR，只改 verify 目录）/ blocked。不改产品代码；产品回归只报告。

和审 diff 怎么配合（实操）

  • 功能开发中：主循环改代码；需要静态意见时走 AI code review 那一类「读 diff」流程。
  • 声称「做完了」：用 /verify-<app> 按 feature map 驱动真应用，要视频/截图/副作用证据。
  • 只绿了审查、verify 失败：优先信运行证据，再回头改代码或更新地图（地图漂移用 maintain，别用改文档盖产品 bug）。

把子 Agent 收进主循环 Skill 的讨论见 别急着堆子 Agent——那是编排形态；verification skill 是验收基础设施，两者不互相替代。

生成之后

  • 提交 .cursor/skills/verify-<app>/
  • 提示里写 use /verify-<app> to verify…
  • 地图稳定后可用 /swarm 按 feature 拆验收
  • 老写一次性点击脚本时，按指南做小 control CLI（--dry-run、机器可读输出）供 skill 调用

常见踩坑

  • 把「审过 diff」当成「功能在 App 里成立」。
  • 把进程起来当成 ready。
  • Cleanup 按进程名杀、或删掉证据目录。
  • 地图列多项却只测一个顺手入口。
  • 指望模型自动跑生成器（有 disable-model-invocation）。

常见问题

审 diff 和 verification skill 哪个先做？

没有唯一顺序。常见是开发中随时审 diff，交付声称前必须有一次真应用证明。缺审查入口时看 AI code review；缺驱动能力时跑 /create-verification-skill。

生成物放哪？

.cursor/skills/verify-<app>/，含 SKILL.md 与 features/。

本文有没有你们的端到端计时？

没有。只核对了公开 raw 与 feature-map-example 标题结构。你在自己仓库 Prove 后以你的命令与证据为准。

创建 API Key →

相关文章