用 Codex 开发一个 WordPress 小插件：从需求到源码完整教程

想用 AI 辅助开发 WordPress 插件，关键不是让工具一次性生成所有代码，而是把需求、文件结构、验收标准和测试路径说清楚。本文用“文章发布辅助小插件”作为示例，完整演示如何使用 Codex 把一个想法推进到可运行源码。

如果你还在梳理 AI 工具选型，可以先查看站内 AI 工具最新动态；如果你更关注实战落地，也可以延伸阅读 实战工作流 栏目。

先把插件需求写成 Codex 能执行的任务

WordPress 插件开发最容易出问题的地方，是一开始只写一句“帮我做个插件”。Codex 能处理复杂工程，但它需要明确边界：插件解决什么问题、作用于前台还是后台、是否需要数据库表、是否调用外部 API、是否要兼容古腾堡编辑器、是否要给管理员配置页面。

示例需求

本文示例插件的目标是：在 WordPress 后台新增一个“发布助手”页面，管理员可以填写文章标题、摘要、标签建议和 SEO 关键词，然后把这些字段整理成可复制的发布清单。这个需求足够小，但覆盖了插件头信息、菜单注册、权限判断、表单渲染、数据清洗和后台样式。

推荐的需求提示词结构

给 Codex 的第一条需求可以这样组织：插件名称、功能目标、后台入口、用户角色、输入字段、输出结果、文件结构、不得修改主题文件、不得写死密钥、默认不直接发布。这样生成的代码更接近 WordPress 规范，也更容易检查。

设计插件目录和核心文件

一个小插件不需要复杂架构，但目录要清楚。推荐从单一主文件开始，后续再拆分 includes、assets 和 templates。对于教学或轻量工具，保持简单比过早抽象更重要。

基础目录示例

wp-content/plugins/codex-publish-helper/
  codex-publish-helper.php
  assets/admin.css
  includes/class-admin-page.php

主文件负责插件声明、常量定义和加载类文件；后台类负责注册菜单、渲染页面和处理表单；CSS 文件只放后台页面所需的少量样式。这个结构便于 Codex 分步修改，也便于人工审查。

让 Codex 生成第一版源码

生成源码时，不建议一次要求“做完整插件并上线”。更稳妥的做法是先让 Codex 创建最小可运行版本：插件能在后台启用，菜单能显示，页面能打开，表单提交后能看到经过清洗的输出。

主插件文件示例

<?php
/**
 * Plugin Name: Codex Publish Helper
 * Description: A small admin helper for preparing WordPress post publishing notes.
 * Version: 1.0.0
 * Author: Your Name
 */

if (!defined('ABSPATH')) {
    exit;
}

define('CPH_PLUGIN_FILE', __FILE__);
define('CPH_PLUGIN_DIR', plugin_dir_path(__FILE__));

require_once CPH_PLUGIN_DIR . 'includes/class-admin-page.php';

add_action('plugins_loaded', function () {
    if (is_admin()) {
        new CPH_Admin_Page();
    }
});

这段代码只做三件事：声明插件、阻止直接访问、在后台加载管理页面类。它没有改主题文件，也没有碰管理员密码，符合 WordPress 插件开发的基本安全边界。

后台页面类示例

<?php
if (!defined('ABSPATH')) {
    exit;
}

class CPH_Admin_Page {
    public function __construct() {
        add_action('admin_menu', [$this, 'register_menu']);
    }

    public function register_menu() {
        add_menu_page(
            'Codex 发布助手',
            '发布助手',
            'edit_posts',
            'codex-publish-helper',
            [$this, 'render_page'],
            'dashicons-edit-page',
            58
        );
    }

    public function render_page() {
        if (!current_user_can('edit_posts')) {
            wp_die('Permission denied.');
        }

        $title = isset($_POST['cph_title']) ? sanitize_text_field(wp_unslash($_POST['cph_title'])) : '';
        $summary = isset($_POST['cph_summary']) ? sanitize_textarea_field(wp_unslash($_POST['cph_summary'])) : '';
        ?>
        <div class="wrap">
            <h1>Codex 发布助手</h1>
            <form method="post">
                <table class="form-table" role="presentation">
                    <tr>
                        <th><label for="cph_title">文章标题</label></th>
                        <td><input name="cph_title" id="cph_title" class="regular-text" value="<?php echo esc_attr($title); ?>"></td>
                    </tr>
                    <tr>
                        <th><label for="cph_summary">摘要</label></th>
                        <td><textarea name="cph_summary" id="cph_summary" class="large-text" rows="5"><?php echo esc_textarea($summary); ?></textarea></td>
                    </tr>
                </table>
                <?php submit_button('生成发布清单'); ?>
            </form>
        </div>
        <?php
    }
}

真正开发时，还应该加入 nonce 校验、错误提示、字段长度限制和更清晰的输出区域。第一版先跑通，再让 Codex 按清单逐步增强。

用 Codex 做代码审查和安全加固

AI 生成代码后，必须继续做审查。WordPress 插件至少要关注四类问题：权限检查、输入清洗、输出转义、请求校验。后台表单要使用 current_user_can()、sanitize_text_field()、sanitize_textarea_field()、esc_attr()、esc_html() 和 nonce。

可以让 Codex 检查什么

你可以要求 Codex 逐项检查：是否存在未转义输出，是否有未验证的 POST 请求，是否错误使用管理员权限，是否把密钥写入源码，是否修改主题核心文件，是否有直接发布或删除线上文章的动作。检查标准越具体，输出越可靠。

本地测试和安装验证

把插件目录放进 wp-content/plugins/ 后，先在测试站点启用。打开后台菜单，提交空表单、长文本、特殊字符和中文内容，确认页面不报错，输出不会破坏 HTML，也不会出现权限绕过。

测试清单

• 插件能正常启用和停用。
• 后台菜单只对有权限的用户可见。
• 表单提交包含 nonce 校验。
• 所有输入字段都做清洗。
• 所有输出位置都做转义。
• 没有写死密钥、没有修改主题文件、没有直接发布线上文章。

把 Codex 变成可重复的开发流程

一次成功不代表流程可靠。更推荐把提示词、插件目录规范、测试清单和发布规则沉淀成项目说明。以后开发新插件时，只要替换需求和字段，就能复用同一套工作流。

实战建议

让 Codex 每次只处理一个明确阶段：先生成结构，再补业务逻辑，再做安全审查，最后跑测试。对于 WordPress 项目尤其要坚持“插件解决插件的问题，主题解决主题的问题”，不要让自动化脚本越权修改主题核心文件或线上文章。

常见问题

Codex 可以直接开发完整 WordPress 插件吗？

可以，但建议分阶段完成。先做最小可运行版本，再逐步增加后台设置、短代码、REST API、样式和测试，质量会更稳定。

用 Codex 写插件会不会不安全？

风险取决于你的需求描述和审查流程。只要明确权限检查、输入清洗、输出转义、nonce 校验和密钥管理，并在测试站验证，风险可以明显降低。

插件代码可以直接放到主题 functions.php 吗？

不建议。插件功能应该放在独立插件目录中，避免修改主题核心文件，也方便启用、停用和后续维护。

文章发布辅助插件需要连接外部 AI API 吗？

不一定。本文示例只做后台字段整理，不需要外部 API。如果要接入 AI API，密钥必须放在环境变量或安全配置中，不能写入源码。