事情是这样的。年初我接了个活——帮一个外贸公司做 12 个 WordPress 小插件，每个功能都不复杂（联系表单增强、图片懒加载、自定义短代码、数据库清理等），但每个都要独立开发、测试、打包。传统做法，一个插件至少 1-2 天，12 个做完至少半个月。
我用 Codex 的替代 API（DeepSeek/GLM）批量生成，每个插件的核心代码控制在 3-5 小时完成（含测试），12 个插件一共用了 12 天——但其中有 8 天是并行处理的。
（实测）这篇文章不是教你怎么写 PHP——是教你怎么用 AI 在 30 分钟内从一个需求描述变成一份可上架的 WordPress 插件包。
这篇是 OpenAI Codex 停用后免费平替 API 指南 的实战篇。如果你还没找到替代 Codex 的 API，先看那篇。
WordPress 插件的结构是固定套路——主文件头注释、激活/停用钩子、管理页面、短代码或小工具。不需要每次重复写，让 AI 一次性给你。
你是一个 WordPress 插件开发专家。请帮我生成一个 WordPress 插件 [功能描述]，包含以下文件结构：
- 主文件：plugin-name/plugin-name.php（插件头、激活/停用钩子、核心逻辑）
- 如果涉及数据库，建表代码放在激活钩子里
- 如果涉及管理设置页，用 add_options_page
具体要求：
- [功能具体需求]
- [额外的安全要求]
- [UI 风格要求]
代码标准：
- 使用 WordPress 编码规范
- 所有功能用类封装，不要裸函数
- SQL 要用 $wpdb->prepare，不要拼接字符串
- 输出用 esc_html / esc_attr 转义
- 设置页面用 settings_api 或手写简单设置页
输出结构：
- 只输出代码，每段用文件名标注
不需要安装说明
你是一个 WordPress 插件开发专家。请帮我生成一个 WordPress 插件「联系表单增强器」，功能：
- 在现有 Contact Form 7 表单提交后，增加一个验证码字段
- 验证码用简单的数学题（如 3+5=?），不需要第三方服务
- 验证失败返回错误信息，不发送邮件
- 后台加一个设置页，可以开启/关闭验证码功能
代码标准同上。
输出时标注每个文件名。
（实测）第一次跑这个 prompt，DeepSeek 给了我 3 个文件：主文件、验证码类、设置页。总共约 400 行。我花了 30 分钟调整样式和翻译英文提示文字为中文——因为 WordPress 插件面向国内用户。
单个文件不够，需要完整的插件目录。告诉 AI 一次性给：
├── contact-form-enhancer/
│ ├── contact-form-enhancer.php # 主文件
│ ├── includes/
│ │ ├── class-captcha.php # 验证码生成和验证
│ │ └── class-settings.php # 设置页面
│ ├── assets/
│ │ └── style.css # 前端样式
│ └── readme.txt # 插件描述（WordPress 仓库格式）
# 在命令行生成完整目录
mkdir -p contact-form-enhancer/{includes,assets}
（实测）目录结构不要手动创建。你可以在 prompt 里指定目录结构，AI 会按你的要求输出，然后你直接把代码逐文件保存就行。
#!/bin/bash
# 批量生成 3 个 WordPress 插件的基础代码
PLUGINS=("image-lazy-loader" "db-cleaner" "custom-shortcodes")
for plugin in "${PLUGINS[@]}"; do
mkdir -p "${plugin}/includes"
<span class="hljs-comment"># 每个插件的 prompt 发送给 API</span>
<span class="hljs-built_in">cat</span> > <span class="hljs-string">"<span class="hljs-variable">${plugin}</span>/<span class="hljs-variable">${plugin}</span>.php"</span> << <span class="hljs-string">'EOF'</span>
<?php
/**
- Plugin Name: (插件名)
- Description: (插件描述)
- Version: 1.0.0
- Requires PHP: 7.4
*/
// 安全防护
defined('ABSPATH') or die('No direct access');
// 插件主类
class Plugin_Main {
public function __construct() {
// 初始化钩子
}
}
new Plugin_Main();
EOF
<span class="hljs-built_in">echo</span> <span class="hljs-string">"已生成 <span class="hljs-variable">$plugin</span> 基础结构"</span>
done
AI 生成的代码永远有 bug——不是它能力不行，是它不知道你的 WordPress 环境版本和已安装的插件。所以必须批量测试。
# 前提：你有一个本地 WordPress 测试环境（用 LocalWP 或 Docker）
# 批量安装插件
for plugin_dir in ./plugins/*/; do
plugin_name=$(basename "$plugin_dir")
echo "测试插件: $plugin_name"
<span class="hljs-comment"># 复制到 WordPress 插件目录</span>
<span class="hljs-built_in">cp</span> -r <span class="hljs-string">"<span class="hljs-variable">$plugin_dir</span>"</span> /var/www/html/wp-content/plugins/
<span class="hljs-comment"># 激活</span>
wp plugin activate <span class="hljs-string">"<span class="hljs-variable">$plugin_name</span>"</span>
<span class="hljs-comment"># 检查激活是否报错</span>
<span class="hljs-keyword">if</span> [ $? -eq 0 ]; <span class="hljs-keyword">then</span>
<span class="hljs-built_in">echo</span> <span class="hljs-string">"✅ <span class="hljs-variable">$plugin_name</span> 激活成功"</span>
<span class="hljs-keyword">else</span>
<span class="hljs-built_in">echo</span> <span class="hljs-string">"❌ <span class="hljs-variable">$plugin_name</span> 激活失败"</span>
wp plugin deactivate <span class="hljs-string">"<span class="hljs-variable">$plugin_name</span>"</span>
<span class="hljs-keyword">fi</span>
done
每个插件至少跑这 4 个测试：
| 测试项 | 测试方法 | 预期结果 |
|---|---|---|
| 安装激活 | wp plugin activate xxx |
无 PHP 报错 |
| 前端页面加载 | 打开页面检查 | 无 JS/CSS 错误 |
| 后台设置页 | 访问设置页 | 页面不报错 |
| 核心功能 | 手动测试插件的核心功能 | 功能正常 |
（实测）12 个插件中，有 4 个在激活时报错——3 个是 PHP 版本不兼容（AI 用了 PHP 8 语法，但我测试环境是 7.4），1 个是函数命名冲突（和另一个已安装插件的函数重名）。这些问题都在批量测试中被发现了。
// 报错 1：函数重名
// ❌ AI 生成的代码
function my_custom_function() { ... }
// ✅ 修复：用类封装或 function_exists 检查
if (!function_exists('my_custom_function')) {
function my_custom_function() { ... }
}
// 报错 2：直接输出 vs return
// ❌ 插件设置页直接 echo，破坏页面布局
echo '<div class="wrap">';
// ✅ 正确做法：用 ob_start / ob_get_clean 捕获输出
function render_settings_page() {
ob_start(); ?>
<div class="wrap">
<h1>设置</h1>
</div>
<?php
return ob_get_clean();
}
测试完成后，批量打包成 .zip 文件。
#!/bin/bash
# 批量打包 WordPress 插件
PLUGIN_DIR="./plugins"
OUTPUT_DIR="./dist"
mkdir -p "$OUTPUT_DIR"
for plugin_dir in "$PLUGIN_DIR"/*/; do
plugin_name=$(basename "$plugin_dir")
zip_path="${OUTPUT_DIR}/${plugin_name}.zip"
<span class="hljs-built_in">cd</span> <span class="hljs-string">"<span class="hljs-variable">$PLUGIN_DIR</span>"</span>
zip -r <span class="hljs-string">"../<span class="hljs-variable">${zip_path}</span>"</span> <span class="hljs-string">"<span class="hljs-variable">$plugin_name</span>"</span> -x <span class="hljs-string">"*/\.*"</span> <span class="hljs-string">"*/node_modules/*"</span>
<span class="hljs-built_in">cd</span> ..
<span class="hljs-built_in">echo</span> <span class="hljs-string">"✅ 已打包: <span class="hljs-variable">${zip_path}</span>"</span>
done
echo "共打包 $(ls "$OUTPUT_DIR"/*.zip | wc -l) 个插件"
（实测）不要直接把 AI 给的代码发给客户。打包前做三件事：
WordPress 插件面临的安全问题比普通 Web 应用多——因为它在 WordPress 生态里运行，会和其他插件交互。
（实测）AI 生成的代码对 SQL 注入的防护比较好（因为它被训练了大量 WordPress 安全最佳实践），但对 CSRF（跨站请求伪造）和权限检查（current_user_can）经常遗漏。每个插件的管理页面操作，我都手动加了一行：
// AI 漏了这行
if (!current_user_can('manage_options')) {
wp_die('你没有权限执行此操作');
}
AI 对 WordPress 的 $wpdb->prefix 处理有时会出错——它可能直接把表名写成 wp_ 开头。
// ❌ AI 可能写死的表名
$table_name = 'wp_my_data';
// ✅ 必须加前缀
global $wpdb;
$table_name = $wpdb->prefix . 'my_data';
// ❌ AI 把提示文本写死在代码里
echo '验证码错误';
// ✅ 用 WordPress 国际化函数，方便后续翻译
_e('验证码错误', 'my-plugin');
// 或
echo __('验证码错误', 'my-plugin');
观点收尾：
AI 写 WordPress 插件，不是替代开发者，而是把开发者的时间从"写代码"变成"审代码"。
| 工作 | AI 做的时间 | 我做的时间 | 节省比例 |
|---|---|---|---|
| 写基础代码框架 | 5 分钟 | 1-2 小时 | 90%+ |
| 调试兼容性问题 | 0（不会） | 2-3 小时 | -100%（自己来） |
| 安全审查 | 50%（提醒了） | 1 小时 | 50% |
| 测试 + 修复 | 0（不会） | 3-4 小时 | -100%（自己来） |
| 打包发布 | 1 分钟 | 30 分钟 | 90% |
真实情况：一个插件从需求到上架，AI 帮我省了约 40% 的时间。没有 AI 我 100% 自己写，有 AI 我 40% 审 + 改 + 测。省下来的时间花在安全审查和测试上，最终产品比我自己手写还稳。
想了解怎么找到这些 AI API 的免费额度，看 OpenAI Codex 停用后 5 个免费平替 API 实测对比。如果你更关心本地部署方案，看 本地部署大模型实战。
本文基于博主用 DeepSeek/GLM API 批量生成 WordPress 插件的实操经历写成。WP-CLI 命令参考自 WordPress.org 官方文档。