wp-playground

wp-playground 技能概览

wp-playground 是用于搭建和操作 WordPress Playground 实例的技能，适合你需要一个可丢弃、可复现的环境，而不是完整的本地 WordPress 技术栈时使用。wp-playground skill 最适合插件和主题开发者、QA 测试人员，以及希望复现问题、测试版本，或在浏览器中、或通过 @wp-playground/cli 共享可运行配置的后端开发者。

最重要的是它解决什么问题：快速把 WordPress 站点跑起来，挂载正确的代码，选择合适的 WP/PHP 版本，并保留足够的控制能力来调试或打包结果。它不是一个泛泛的“帮我写个 WordPress prompt”技能；它更像是一份实用的 wp-playground guide，用于受控环境、blueprint、snapshot 和隔离测试。

适合一次性 WordPress 工作流的最佳场景

当你需要下面这些能力时，用 wp-playground 最合适：

• 快速拉起一个临时 WordPress 站点，验证插件或主题改动，
• 针对特定 WordPress 或 PHP 版本做测试，
• 运行 blueprint 或生成 snapshot 方便共享，
• 在不影响生产环境或本地数据库的情况下，隔离调试行为。

它的区别在哪里

它最强的差异点在于 CLI 工作流、blueprint 支持，以及可预测的短生命周期运行时。wp-playground 很适合你更看重复现性，而不是精致 UI 的时候。另一个关键点是，它的环境基于 SQLite 和 WebAssembly，这会让它在性能和约束上都不同于传统服务器安装。

先要知道的关键限制

只有当你能接受一次性环境时，它才算合适。它不适合生产数据、长期保留的本地状态，也不适合依赖传统 MySQL 型 WordPress 技术栈的工作流。为了获得最好效果，请把它当作受控测试床，而不是主开发环境的替代品。

如何使用 wp-playground 技能

安装并打开源文件

先按你目录工具的标准 wp-playground install 路径开始，然后在让它干活之前先阅读这个技能的源文件。这个仓库里的关键文件是 SKILL.md、references/blueprints.md、references/cli-commands.md 和 references/debugging.md。这些文件会告诉你这个技能期望什么输入，以及哪些 CLI 参数最关键。

把模糊目标改写成可执行的 prompt

一个弱 prompt 会说：“帮我给插件搭建 WordPress Playground。”
一个更强的 prompt 会说：“用 wp-playground 为 packages/my-plugin 里的插件创建一个可丢弃的本地实例，自动挂载项目，针对 WP 6.9 和 PHP 8.3 测试，并告诉我精确的 CLI 命令，以及任何挂载或 blueprint 需要调整的地方。”

在 wp-playground usage 里，最好包含：

• 项目路径，
• 你要用 server、run-blueprint 还是 build-snapshot，
• WordPress 和 PHP 版本，
• 是否需要自动挂载代码，
• 是否需要 Xdebug 或 blueprint 文件。

先选对工作流

当你想要一个交互式实例来做实时测试时，用 server --auto-mount。当你需要脚本化配置，并且流程是启动后立即退出时，用 run-blueprint。当你想要一个可复用的产物，方便交接或以后重跑时，用 build-snapshot。如果目标是后端调试，请明确说明具体故障表现，而不要只问启动命令，这样它才能给出更适合 Xdebug 的步骤。

按这个顺序阅读仓库

一份好的 wp-playground guide 应该先看 SKILL.md，然后看 references/cli-commands.md 了解命令结构；如果需要自动化配置，再看 references/blueprints.md；如果任务涉及断点、挂载或卡住的运行，再看 references/debugging.md。按这个顺序能减少猜测，也能避免漏掉 --mount-before-install 或 --blueprint-may-read-adjacent-files 这类参数。

wp-playground 技能常见问题

wp-playground 只是给前端演示用的吗？

不是。wp-playground skill 对插件、主题和后端开发尤其有用，因为它能提供隔离的 WordPress 行为、可复现的版本和调试会话。它更偏向受控执行，而不是视觉演示。

我需要先有完整的本地 WordPress 环境吗？

通常不需要。wp-playground install 的目的，就是给你一个快速环境，而不是先去配置传统技术栈。如果你已经有本地环境，wp-playground 仍然有用，特别是在你需要一个干净的对照目标，或者需要特定 WP/PHP 组合的时候。

什么情况下不该用它？

不要把它用于生产数据、需要持久化内容的工作，或者依赖 MySQL 特定行为的工作流。如果你的插件依赖外部服务、文件系统持久化，或者长期运行状态，那么 wp-playground 可能不是默认选择，除非你能在 blueprint 里明确建模这些依赖。

它适合新手吗？

适合，前提是任务简单，而且你严格按照 CLI 示例来做。最容易出问题的地方是输入太模糊：如果你没有说明项目路径、版本目标，或者是否需要 blueprint，结果就会不够有用。新手的最佳做法是一次只问一个清晰的工作流。

如何改进 wp-playground 技能

给技能明确的环境变量

提升质量最大的办法，是把项目根目录、期望的 WP/PHP 版本，以及代码是否需要自动挂载或显式挂载说明清楚。比如，“用 wp-playground 在 WP 6.9 和 PHP 8.3 下测试 plugins/contact-form，并启用 --auto-mount” 就比“让它能用”好得多。

说明故障表现，而不只是目标

如果你在调试，请直接说哪里坏了：安装失败、插件 hook 没有触发、REST 返回不对，还是只有在 PHP 8.3 上才出现的版本回归。这样技能才能判断该用 server、run-blueprint 还是 build-snapshot，也会让任何 wp-playground for Backend Development 工作流更有价值。

注意挂载和 blueprint 的常见错误

常见问题包括相对挂载路径、安装前必须存在的文件，以及需要读取本地邻近文件的 blueprints。如果第一次运行失败，就把 prompt 改得更具体：补上绝对路径，确认是否需要 --mount-before-install，并说明 blueprint 会不会读取本地资源。调试时，直接要求提供 Xdebug 配置细节和预期的 IDE 映射方式。

一次只迭代一个变量

如果第一次输出已经接近正确但还不完全对，只改一个变量：WP 版本、PHP 版本、挂载模式，或者 blueprint 来源。这样更容易判断问题到底出在环境选择、命令参数，还是配置方案本身。