Claude Code 内置了一组"运行并验证"技能——/run、/verify、/run-skill-generator，三者配合能让 Claude 把改动放进真实跑起来的应用里核对效果，而不是只满足于测试通过或类型检查无报错。本文基于官方 Skills 文档详解这套工具链。
三个技能各自的职责
/run → 启动并操作你的应用，看到改动的实际效果
/verify → 构建并运行应用，确认代码改动确实达到
预期效果，不满足于测试或类型检查通过
/run-skill-generator → 教会 /run 和 /verify 如何构建和
启动你的具体项目
这三个技能都要求 Claude Code v2.1.145 及以上版本，可以用 claude --version 或 /status 命令确认当前版本。
/run 和 /verify 默认怎么工作
开箱即用，不需要任何配置——它们会根据你的项目类型（CLI、服务端、TUI、浏览器驱动型应用）以及 README、package.json、Makefile 等文件里的信息，自动推断该如何启动。
但官方也坦承了这个自动推断的局限：
That inference gets unreliable for projects that need anything beyond a standard launch: a database, an env file, a graphical session, a multi-step build.
如果你的项目需要数据库、环境变量文件、图形化会话，或者多步骤构建流程，这种自动推断就容易翻车——这正是第三个技能要解决的问题。
/run-skill-generator：把启动方式记下来，一劳永逸
它的工作方式：
1. 从一个干净的环境把你的应用真正跑起来
2. 记录下过程中用到的安装命令、环境变量、启动脚本
3. 把这套"配方"提交为一个项目专属技能，
存放在 .claude/skills/run-<name>/
运行一次 /run-skill-generator 之后，之后调用 /run、/verify，以及仓库里的其他 Agent，都会遵循这份记录下来的配方，而不需要每次重新摸索一遍怎么启动这个项目。这对团队协作尤其有价值——一个人跑通配置后，整个团队和后续的 Agent 都能直接复用，不用各自重复踩坑。
使用场景对比
场景：项目结构标准（比如一个纯 Node.js CLI 工具）
→ 直接用 /run、/verify，无需额外配置
场景：项目依赖数据库 + 环境变量 + 多步构建
→ 先跑一次 /run-skill-generator 记录启动配方，
之后 /run、/verify 才能可靠工作
场景：验证一次具体的代码改动是否真的解决了问题
→ 用 /verify，它会构建并运行应用来确认，
而不只是依赖测试或类型检查这类间接信号
为什么"跑起来验证"比"测试通过"更可靠
/verify 的设计理念值得单独强调——测试和类型检查能覆盖的只是代码逻辑层面的正确性，但应用在真实运行时的表现（比如渲染是否正常、交互流程是否顺畅、依赖服务是否正确连接）是测试套件未必能完全捕捉的。结合前文提到的"给 Claude 一个验证闭环"这条最佳实践，/run 和 /verify 提供的正是那种"能产出 pass/fail 信号"的具体实现之一——只不过信号来源从测试输出换成了真实运行的应用状态。
实战建议
1. 新项目接入 Claude Code 时，第一件事可以考虑跑一次
/run-skill-generator，把启动方式固化下来
2. 涉及 UI 改动或用户可见行为变化的任务，
优先用 /verify 而非仅依赖单元测试作为完成标准
3. 团队协作场景下，把生成的 .claude/skills/run-<name>/
提交进版本库，让所有协作者和 Agent 共享同一套启动配方
总结
/run、/verify、/run-skill-generator 这套组合，解决的是"Claude 怎么知道自己的改动到底有没有真正生效"这个实际问题——尤其是对于结构复杂、启动流程不标准的项目，提前用 /run-skill-generator 记录配方，能让后续所有验证工作都建立在可靠的基础上。
来源：Extend Claude with skills — Claude Code 官方文档，Anthropic