前言

在内容生产里，“一键润色”很容易，但真正难的是可控地落地：既要用 AI 提升表达，又要能逐段校对、可回滚、可审计、避免并发修改导致覆盖。本文总结一个 WordPress 插件的实现：生成润色候选稿 → 左右对比审阅 → 按段采纳 → 应用/回滚，并把关键的安全与冲突处理串成一条闭环。

问题背景

• 核心诉求：为文章正文生成 AI 润色版本，但不能直接覆盖原文，需要编辑/审阅人员逐段确认。
• 典型场景：编辑在后台文章编辑页触发润色；审阅时希望看到原文与候选稿并排对比，并能快速选择“保留/采用”。
• 风险点：文章在生成候选稿后又被别人改过，直接应用会覆盖他人修改；需要权限隔离与留痕。

解决过程

整体思路是把 AI 生成从“写回正文”拆成两个阶段：

1. 生成阶段只做“快照 + 候选稿”，不触碰正文；
2. 审阅阶段把原文/候选按段落映射，提供逐段决策，再合并写回正文。

为保证可追溯与可回滚，把“原文快照、候选稿、段落映射、审计日志”落到独立表里，而不是混在 post meta 中。

最终方案

1）插件骨架与入口

入口文件负责定义常量、加载核心类，并在 plugins_loaded 时启动主插件类。主类在 boot() 中注册后台菜单（设置页、审阅页）、编辑页侧边栏 Meta Box（触发润色按钮与选项）、以及一组 wp_ajax_* 动作（加载审阅数据、应用、回滚）。

2）“快照 + 候选稿”的数据模型

• 快照表：保存某篇文章某次生成时的原文（版本号递增）。
• 候选表：保存润色结果（provider/model/style/status/error），并记录生成时文章的 post_modified_gmt。
• 段落映射表：保存 source/candidate 的段落索引、hash、相似度、置信度与默认决策。

3）生成流程（run_polish）

生成流程串联为：读取正文 → 写入原文快照 → 创建候选记录（processing）→ 调用外部模型生成润色结果 → 成功则 ready 并生成段落映射；失败则标记 failed，并写审计日志。

Provider 侧实现了：Endpoint/API Key/模型配置、超时重试、兼容常见的响应结构，以及返回内容清洗（避免 fenced code block、识别 Markdown 并转 HTML）。本文不包含任何具体域名、密钥或私有接口细节。

4）审阅页与逐段应用

审阅页通过 AJAX 拉取 payload，为每段提供原文/候选预览、相似度与置信度提示；置信度低的段落默认“保留原文”，并提醒人工复核。

应用时做了关键的冲突保护：对比当前文章的 post_modified_gmt 与候选生成时记录；若不一致则拒绝应用，避免覆盖他人修改；一致才会按决策合并并写回正文，同时记录审计日志。

5）安全与权限控制

• Nonce 校验：表单与 AJAX 均有 nonce，避免 CSRF。
• 能力检查：生成要求 edit_post；应用/回滚要求自定义能力 wba_apply_polish（管理员默认拥有，也可授予专用角色）。
• 最小破坏原则：停用插件不删表，保证历史可追溯与回滚安全。

总结

• 把“AI 改写正文”拆成快照与候选 → 可控审阅 → 合并写回，能显著降低线上风险。
• 通过 post_modified_gmt 冲突检测，避免并发编辑导致覆盖。
• “逐段映射 + 置信度提示 + 默认保守策略”降低审阅成本，减少误采纳。
• 审计日志是线上排障与合规的重要基础设施，应当与流程一起设计。

开源地址

WP Beautify Articles