版本：v1.0（2026-08） 关联章节：第 16 章《平台运营之最佳实践指南》、第 7 章《AI 系统层》 本文档定义如何在 Audlis 现有系统上构建"AI 运营大脑"：自动巡检、异常分级、处置建议与审批门。
1. 目标与范围
1.1 为什么需要 AI 运营
第 16 章建立了运营体系：27 个工作区、七类 cron 任务、日/周/月节奏、事故手册。但这些体系的运转完全依赖"人每天主动去看"。当平台订单量增长、创作者与内容变多后，一个运营团队会出现三种真实困境：
- 巡检疲劳：每天重复检查 6 个工作区，漏检概率随量增长而上升
- 处置延迟：异常发现到处理之间隔着"人注意到"这一步，MTTR 被拉长
- 知识断层：事故手册写在第 16 章，但换人后执行标准漂移
AI 运营的目标不是替代人，而是把"发现-分级-建议"从人转移到系统，把"处置"留给审批门与人工。
1.2 边界声明（本方案不做什么）
- 不做自动退款、自动打款、自动改价等资金类自动执行（一律走审批门）
- 不做自动删除用户数据（隐私类操作仅生成建议）
- 不把用户原始数据发送给外部 LLM（聚合、脱敏后才进入分析）
- 不替换现有 cron worker 的状态机（AI 运营是它之上的"运营大脑"，不是它的替代品）
1.3 成功标准
- 运营巡检覆盖率 100%（不再依赖人每天手动过工作区）
- 异常检出到人工介入的 MTTR 降低 ≥ 60%
- 误报率 ≤ 20%（否则运营会开始忽略告警）
- 自动处置（低风险类）占全部处置的 ≥ 40%，资金类自动处置恒为 0
2. 总体架构
AI 运营系统分为五层，全部复用现有 Cloudflare 底座：
┌─────────────────────────────────────────────────────┐
│ 感知层 Ops Scanner（cron worker 扩展） │
│ 每分钟/每小时对关键表做快照：orders、shipping_exceptions、│
│ return_requests、product_reviews、design_reports、 │
│ marketing_lifecycle_triggers、ap_delivery_queue、 │
│ royalty_ledger、creator_payouts │
└──────────────────────┬──────────────────────────────┘
▼
┌─────────────────────────────────────────────────────┐
│ 分析层 Ops Brain（LLM 分类分级） │
│ 输入：快照 diff + 规则引擎输出 + RAG 检索的处置预案 │
│ 输出：结构化 incident 对象（severity/category/建议动作） │
└──────────────────────┬──────────────────────────────┘
▼
┌─────────────────────────────────────────────────────┐
│ 决策层 分级路由 │
│ P0 自动+立即通知 → P1 自动处置+通知 → │
│ P2 建议+人工确认 → P3 仅记录 │
└──────────────────────┬──────────────────────────────┘
▼
┌─────────────────────────────────────────────────────┐
│ 执行层 Ops Action Executor（最小权限 token） │
│ 调用现有管理 API：标记异常、发安抚邮件、驳回评价、 │
│ 更新状态字段；资金/隐私/内容下架类动作转发审批门 │
└──────────────────────┬──────────────────────────────┘
▼
┌─────────────────────────────────────────────────────┐
│ 反馈层 审计 + 知识沉淀 │
│ ops_audit 全量留痕；处置结果回写 ops_knowledge_docs │
│ 形成 RAG 知识库的持续更新 │
└─────────────────────────────────────────────────────┘2.1 与现有 cron worker 的关系
cron worker 继续推进既有状态机（邮件触发、版税转正、投递、Mockup 流水线）。AI 运营新增两类任务：
| 任务 | 频率 | 职责 |
|---|---|---|
opsScan | 每分钟 | 快照关键表，计算 diff，写 ops_scans |
opsAnalyze | 每分钟（在 opsScan 后） | 对 diff 运行规则引擎 + LLM 分级，生成 ops_incidents |
cron worker 的既有任务不感知 AI 运营的存在；AI 运营只读取事实层，通过管理 API 动作，不修改 cron 内部状态机。
2.2 技术选型
| 组件 | 选型 | 理由 |
|---|---|---|
| 快照存储 | D1 新表（ops_scans）+ R2（大快照） | 复用现有 D1/R2，无新基础设施 |
| LLM | 复用第 7 章 Provider 抽象层（Workers AI / 云上模型） | 不新增 AI 接入代码 |
| 结构化输出 | JSON Schema 约束 + 白名单动作枚举 | 降低幻觉导致的非法动作 |
| 规则引擎 | Cloudflare 原生（D1 SQL + 阈值常量，后续配置化） | 确定性规则优先于 LLM 判断 |
| 前端 | 后台新增 "Ops AI" 工作区（Astro + Preact） | 复用 Admin Workspace 模式 |
3. 数据模型
新增四张 D1 表（Drizzle schema）：
ts
// ops_scans — 每次巡检快照
export const opsScans = sqliteTable('ops_scans', {
id: integer('id').primaryKey({ autoIncrement: true }),
scannedAt: integer('scanned_at').notNull(), // unix ms
scanType: text('scan_type').notNull(), // daily | hourly | minutely
summaryJson: text('summary_json').notNull(), // 各队列/表的关键计数快照
diffJson: text('diff_json'), // 与上次快照的 diff
});
// ops_incidents — 异常事件（AI/规则产生的"发现"）
export const opsIncidents = sqliteTable('ops_incidents', {
id: integer('id').primaryKey({ autoIncrement: true }),
scanId: integer('scan_id').references(() => opsScans.id),
severity: text('severity').notNull(), // P0|P1|P2|P3
category: text('category').notNull(), // fulfillment|logistics|support|content|payout|federation|ai_mockup|other
entityType: text('entity_type').notNull(), // order|design|payout|queue|...
entityId: text('entity_id').notNull(),
summary: text('summary').notNull(), // 一句话描述（LLM 生成）
suggestedActionJson: text('suggested_action_json'), // 建议动作（白名单枚举+参数）
status: text('status').notNull().default('open'), // open|approved|executed|rejected|resolved|dismissed
assignedTo: text('assigned_to'), // ai | operator:<id>
createdAt: integer('created_at').notNull(),
resolvedAt: integer('resolved_at'),
});
// ops_actions — 建议/已执行动作（审批门载体）
export const opsActions = sqliteTable('ops_actions', {
id: integer('id').primaryKey({ autoIncrement: true }),
incidentId: integer('incident_id').references(() => opsIncidents.id),
actionType: text('action_type').notNull(), // notify|mark_exception|reject_review|send_email|refund_suggest|payout_fix_suggest|...
paramsJson: text('params_json').notNull(),
approvalState: text('approval_state').notNull().default('not_required'), // not_required|pending|approved|rejected
approvedBy: text('approved_by'),
executed: integer('executed').notNull().default(0),
executedAt: integer('executed_at'),
resultJson: text('result_json'),
});
// ops_knowledge_docs — RAG 知识库（第 16 章 runbook 的结构化沉淀）
export const opsKnowledgeDocs = sqliteTable('ops_knowledge_docs', {
id: integer('id').primaryKey({ autoIncrement: true }),
title: text('title').notNull(),
category: text('category').notNull(),
content: text('content').notNull(), // markdown（来自第 16 章 runbook + 历史处置复盘）
source: text('source').notNull().default('runbook'), // runbook|incident_review|manual
active: integer('active').notNull().default(1),
});4. 巡检项设计（对应第 16 章运营节奏）
| 巡检项 | 频率 | 数据源 | 判定规则（确定性优先） |
|---|---|---|---|
| 履约失败 | 分钟 | orders.fulfillment_status='failed' | 出现即 P1（已有自动退款，通知确认） |
| 物流停滞 | 分钟 | shipping_exceptions.status='in_transit_stalled' | 超阈值即 P1（自动发安抚邮件 + 标记） |
| 售后待审 | 分钟 | return_requests.status='pending_review' 数量 | 数量 > 5 或首个等待 > 24h → P2 |
| 评价待审 | 分钟 | product_reviews.status='pending' | 含违规词 → P1（自动驳回）；否则排队 → P3 |
| 举报队列 | 分钟 | design_reports 未处理 | 出现 P0 类（版权/露骨）→ P1；其余 → P2 |
| 转人工会话 | 分钟 | support 会话 handoff | 含"退款/投诉/改价"关键词 → P2；其余 → P3 |
| 版税转正 | 小时 | royalty_ledger pending 数 | 停滞 > 24h → P2 |
| 打款状态 | 日 | creator_payouts failed | 出现 failed → P0 通知人工（资金类不自动） |
| 投递队列 | 分钟 | ap_delivery_queue failed 数 | failed > 50 → P2；持续失败 → P3 |
| Mockup 卡住 | 小时 | ai_mockup_series run stage 停留 | 同 stage > 6h → P2（建议重试） |
| 存储 GC | 日 | System 工作区 GC 日志 | 连续失败 → P3 |
| 邮件队列 | 分钟 | marketing_lifecycle_triggers 堆积 | 堆积 > 200 → P2 |
设计原则：确定性规则（SQL + 阈值）先判定，LLM 只做规则覆盖不到的语义判断（如异常描述总结、下一步建议、邮件文案）。这保证 80% 的巡检不依赖 LLM，成本可控、行为可预测。
5. 分级与处置策略
5.1 四级处置模型
| 级别 | 定义 | 处置 | 示例 |
|---|---|---|---|
| P0 | 资金/法律/数据安全风险，或影响全站 | 自动通知 + 必须人工 | 打款失败、支付 webhook 异常、隐私请求逾期 |
| P1 | 明确规则可处置、低风险 | 自动处置 + 通知 + 留痕 | 履约失败确认、物流停滞安抚邮件、违规评价自动驳回 |
| P2 | 需要判断，建议 + 人工确认 | 生成建议，等待审批 | 售后审批建议、Mockup 重试建议、创作者打款修复步骤 |
| P3 | 仅观察 | 记录，进入日报 | 队列波动、增长指标变化 |
5.2 审批门规则（硬编码，不可被 LLM 覆盖）
| 操作类别 | 审批要求 |
|---|---|
| 退款、打款、改价、折扣码发放 | 必须人工（拒绝自动） |
| 内容下架、设计屏蔽、实例屏蔽 | 自动处置但强制留痕 + 当日复核 |
| 隐私请求执行（导出/删除） | 必须人工 |
| 邮件发送（模板内） | 自动允许 |
| 状态标记、队列重试 | 自动允许 |
审批门用动作白名单枚举实现（opsActions.actionType 只允许预定义值），LLM 只能从白名单中选择，不能自由生成动作参数。这是防止 AI 越权的第一道闸。
6. 安全边界与审计
- 最小权限执行：AI 执行器使用
ops角色的短期 token，仅授权管理 API 中列出的端点（标记状态、发模板邮件、驳回评价、重试 Mockup）；无订单删除、无用户数据写、无 Stripe 操作权限。 - 全量审计：每次 AI 动作写
ops_actions+ 追加admin_actions（第 16 章建议的统一审计日志），支持按操作者=ai:<model>检索。 - 回滚机制：状态标记类动作记录前值，支持一键回滚；邮件类动作不可回滚（发送前在审批门日志留草稿）。
- 数据隐私：发送给 LLM 的巡检数据剥离 PII（用户邮箱 → 哈希、姓名 → 聚合、内容 → 截断摘要），
prompt_safety_events继续作用于 AI 运营的 prompt 输入输出。 - 模型与输出约束：LLM 输出经 JSON Schema 校验；动作参数与白名单匹配；不匹配即丢弃并记录
ops_audit异常。
7. 实施路径（四阶段）
阶段一：巡检 + 日报（只读，第 1–2 周）
- 实现
opsScan+opsAnalyze（规则引擎部分） - 后台新增 "Ops AI" 工作区：展示当日巡检摘要、异常列表
- 产出：每日运营报告（邮件 + 工作区），无任何自动动作
阶段二：P1 自动处置（第 3–4 周）
- 打开 P1 白名单动作（状态标记、模板邮件、驳回违规评价）
- 审批门上线（P2 建议面板 + 一键确认/拒绝）
- 指标：记录 MTTR 与误报率基线
阶段三：审批门工作流（第 5–6 周）
- Ops AI 工作区升级为完整审批中心：P0/P2 待办、批量确认、动作历史
- 把第 16 章 runbook 灌入
ops_knowledge_docs，启用 RAG - 每次人工处置的最终选择回写知识库（教训沉淀）
阶段四：闭环优化（第 7 周起）
- 从处置结果评估分级准确率，自动调优阈值（配置化，
app_config） - 引入"处置复盘"：每周 AI 生成运营周报（趋势 + 建议）
- 指标看板：检出率、误报率、自动处置率、MTTR、审批通过率
8. 关键指标
| 指标 | 定义 | 目标 |
|---|---|---|
| 巡检覆盖率 | 关键表被快照的比例 | 100% |
| 异常检出率 | 真实异常被生成 incident 的比例 | ≥ 95% |
| 误报率 | P0/P1 中非真实异常的比例 | ≤ 20% |
| 自动处置率 | P1 类自动完成比例 | ≥ 40% |
| 资金自动处置 | 资金类自动执行数 | 恒为 0 |
| MTTR（检出→解决） | 相对纯人工基线 | 降低 ≥ 60% |
| 审批通过率 | 人工确认 P2 建议的比例 | ≥ 70%（过高说明建议过于保守） |
| 知识库命中率 | 处置时检索到有效预案的比例 | ≥ 80% |
9. 风险与缓解
| 风险 | 缓解 |
|---|---|
| LLM 幻觉产生错误建议 | 白名单动作 + JSON Schema + 规则优先 |
| 自动处置误伤（如误驳回评价） | P1 仅限可逆动作；状态标记可回滚；强制留痕 |
| 运营对 AI 告警麻木 | 控制误报率；P0/P1 才通知，P3 只进日报 |
| 数据隐私泄露 | 发送前剥离 PII；聚合/截断；safety 层复用 |
| 依赖外部 LLM 不稳定 | 规则引擎兜底；LLM 失败时降级为纯规则模式 |
| 知识库过时 | 阶段三起每次处置回写，人工可编辑 |
10. 结论
AI 自动运营是第 16 章运营体系的下一个自然演进：把人从"发现"中解放出来，让人专注于"决策"。 本方案的关键不是"让 AI 管平台"，而是建立一条纪律严明的流水线——确定性规则负责发现，LLM 负责理解与建议，审批门负责守住资金、隐私与内容的底线，审计日志负责让每一步都可追溯。
它复用了 Audlis 已有的全部基础设施：cron worker 的调度、D1 的事实存储、Provider 抽象的模型接入、Admin Workspace 的交互模式。增量成本只有四张表、两个 cron 任务和一个工作区——这正是前十六章反复强调的：系统长得越大，新增能力越应该长在已有的骨架上。