自动化边界
说明哪些 AI 能力适合自动读取和生成建议，哪些必须人工确认后执行。
核心原则
很多用户想要的是“AI 帮我少做重复劳动”，不是“AI 随便操作网站”。设计 Ability 时，先把功能分成两类：
- 可以自动读取或生成建议。
- 必须人工确认后再执行。
这个边界决定了站点是否安全，也决定了用户是否信任你的 AI 功能。
适合自动化的能力
这类能力通常只读数据，或只生成建议，不改变站点状态。
| 能力 | 说明 |
|---|---|
| 读取文章上下文 | 读取标题、摘要、正文、分类、标签 |
| 读取商品或资源字段 | 给后续生成说明、FAQ、摘要提供上下文 |
| 生成 SEO 描述 | 返回建议，不直接保存 |
| 生成关键词 | 返回数组，用户确认后再采用 |
| 检查缺失项 | 检查文章是否缺少封面、摘要、alt |
| 生成图片提示词 | 只返回提示词，不自动生成或上传 |
| 生成审核建议 | 输出风险等级和原因，不直接删除内容 |
自动化能力也必须做权限判断。能读取的范围，应当和当前用户在 WordPress 后台能看到的范围一致。
必须人工确认的能力
下面这些能力必须放在用户确认之后：
- 删除文章、订单、用户或评论。
- 修改余额、积分、会员、下载权限、订单状态。
- 直接发布文章或批量修改内容。
- 给用户发送私信、邮件、短信或站内通知。
- 执行退款、发货、封禁、审核通过。
- 批量导入、批量改价、批量改权限。
这些操作一旦出错，影响的不只是内容质量，还可能影响真实业务、用户资产和站点信誉。
推荐拆法
把复杂功能拆成两段：
| 阶段 | 命名 | 行为 |
|---|---|---|
| 生成建议 | generate-*、analyze-* | 读取数据，生成结果，不保存 |
| 确认保存 | save-*、apply-* | 用户确认后保存，重新检查权限和 nonce |
例如 SEO 描述：
zibll-ai-ext/generate-seo-description生成建议。- 后台展示结果，用户可以编辑。
- 用户点击保存。
zibll-ai-ext/save-seo-description保存到 post meta。
用户界面建议
后台按钮不要只写“AI 生成”。更好的界面流程：
- 按钮：生成建议。
- 状态：正在读取文章内容。
- 状态：正在生成 SEO 描述。
- 结果：展示 AI 建议。
- 操作：复制、重新生成、保存。
- 保存前：提示会写入哪个字段。
用户要清楚知道 AI 做了什么，以及点保存后会改哪里。
日志和追踪
生产环境建议记录：
- 谁点击了按钮。
- 哪个 Ability 被执行。
- 输入对象 ID，例如文章 ID。
- provider 和 model。
- 成功或失败。
- 错误码。
- 保存前后的字段名。
不要记录完整 API Key，不要把隐私数据长文本直接写入日志。输入输出预览要裁剪。
安全底线
- API Key 不进前端。
- 模型输出不直接写数据库。
- 写数据库前必须清洗、校验、裁剪。
- 权限回调不能相信模型。
- 保存动作要有 nonce。
- 自动调用只给只读能力。
- 付费、权限、审核、通知相关操作必须人工确认。
- 出错返回
WP_Error，不要echo、wp_die()或暴露服务器路径。
判断题
开发时可以用这组问题自查：
| 问题 | 如果答案是“是” |
|---|---|
| 会不会改数据库？ | 需要人工确认 |
| 会不会影响用户资产？ | 需要人工确认 |
| 会不会发通知？ | 需要人工确认 |
| 会不会发布或删除内容？ | 需要人工确认 |
| 只是读取当前用户可见信息？ | 可以考虑自动化 |
| 只是生成建议不保存？ | 可以考虑自动化 |
自动化不是越多越好。用户能理解、能确认、能回退，才是好用的 AI 功能。
このドキュメントは役に立ちましたか？