日常运营案例

约 2055 字大约 7 分钟

以下案例使用当前 React 浏览器管理后台的实际菜单和路由，不是创作者使用的 Web 网站端。每个案例都以“先定位、再变更、后验证”为顺序，适合值班、上线和复盘时直接照做。

案例 1：上线一个新的 AI 视频模型

目标：让一个已验证的上游模型能够被用户端选择，生成任务能记录渠道和成本，并且故障时可独立停用。

准备：上游 Base URL、模型代码、能力说明、授权凭证、支持的时长/比例/分辨率、成本规则，以及一个测试账号。凭证只在受控字段中填写。

打开“AI 提供商” /admin/ai-providers，创建或核对提供商。名称使用稳定业务标识，不包含密钥。
打开“AI 模型” /admin/ai-models，新增模型，明确它是图片还是视频模型，填写与上游一致的模型代码和能力范围。
打开“AI 渠道” /admin/ai-channels，绑定提供商和模型，填写受控凭证、权重与可用状态。先校验配置，成功后再启用。
打开“AI 分组” /admin/ai-groups，把新渠道加入正确分组，并保留已验证的备用渠道。
在“价格规则” /admin/ai-prices 和“AI 计费规则” /admin/quota-formula 补齐成本与积分规则。模型参数、用户显示价格和实际扣费必须一致。
在“生成策略中心”确认用户侧所需选项、Skill 或参数资源已发布。
使用测试账号提交一个最小视频任务：固定一个支持的时长、比例和提示词，不在首测同时引入多张参考图或复杂参数。
回到“AI 任务中心” /admin/ai-tasks 搜索任务 ID，确认模型、渠道、状态和完成时间；再到“AI 成本分析” /admin/ai-cost-logs 核对成本记录。

验收结果：用户端可选择该模型；任务能完成或给出可读失败原因；后台可从任务追溯到渠道和成本；停止该渠道后，分组内仍有符合预期的替代路径。

失败时的排查顺序：模型类型与实际能力 -> 渠道凭证/健康 -> 分组绑定 -> 价格/计费启用 -> 用户端参数 -> 上游限流或错误。不要一开始同时修改所有配置。

案例 2：发布并验收一个积分充值商品

目标：用户购买后，订单、支付流水与积分到账保持一致。

在“商户配置” /admin/payment-configs 创建或核对支付商户，确认回调地址是公网 HTTPS，支付平台侧已经配置产品权限与回调白名单。
点击“校验”，只在校验成功后启用商户；确认启用商户中有且仅有预期的默认渠道。
在“商业化中心” /admin/billing 新建或编辑积分商品，核对名称、展示金额、实际金额、到账积分、活动规则和启停状态。
使用测试账号记录购买前积分余额，完成一次真实测试环境下的下单和支付。
在“订单中心” /admin/orders 找到订单，核对用户、商品、金额和订单状态。
在“支付流水” /admin/payment-records 核对支付渠道返回的交易状态和时间。
在“额度流水” /admin/credit-logs 核对入账记录，并比较购买前后余额差值是否等于商品权益。

验收结果：商品价格一致，支付成功后订单完成、支付流水存在、额度流水可回溯，余额变动与权益一致。

异常处理：支付成功但未到账时，保留订单号与支付交易号，先检查回调日志和订单处理状态；不要重复创建订单或手动在数据库加额度。更完整的支付验证细节见支付与权益验收。

案例 3：处理“生成失败但已扣积分”的工单

目标：把用户反馈定位到唯一任务，并以可审计的数据判断是参数、渠道、上游还是结算问题。

向用户收集任务 ID、提交时间、项目/工作空间、选择模型、提示词摘要和截图。不要让用户发送密钥或完整隐私素材。
在“AI 任务中心”按任务 ID 或时间筛选，记录任务状态、错误消息、模型、渠道和重试信息。
到“工作空间”搜索用户的空间，确认任务归属的项目和资产上下文，排除用户误查其他任务。
到“额度流水”核对该任务关联的扣费记录；到“AI 成本分析”核对上游成本和渠道调用是否落库。
根据证据分类：参数不支持、渠道配置问题、上游失败、回调未完成或计费规则异常。
仅在页面提供且业务规则允许的情况下使用重试动作；重试前固定输入参数并记录新旧任务 ID，避免无条件重复扣费。
需要补偿或退款时，走平台已发布的订单/额度处理流程，并在工单中留下关联记录。缺少证据时不要做手工余额修改。

关闭工单前：给出任务 ID、最终状态、问题归类、实际处理动作、额度/订单结论和防止再次发生的配置或监控项。

案例 4：停用异常渠道而不中断生成

目标：在上游故障、余额耗尽或响应不稳定时，切走异常渠道并保留业务连续性。

在“AI 任务中心”和“AI 成本分析”确认异常是否集中在同一渠道、模型或时间段。
在“AI 渠道”打开目标渠道，检查最近状态、关联模型和所在分组。
在“AI 分组”确认该分组至少有一个已经通过测试的替代渠道；若没有，先扩充替代能力，而不是直接停用。
用测试账号提交最小请求，确认替代渠道可用。
降低异常渠道权重或停用渠道，立即用相同测试输入验证路由结果。
持续观察新提交任务、失败率和成本变化；等上游恢复并完成验证后再逐步恢复渠道。

记录内容：故障窗口、渠道 ID、模型、分组、停用前后权重、替代渠道、测试任务 ID、恢复时间和原因。

案例 5：审核用户额度异常

在“用户与额度” /admin/users 搜索用户，核对账号状态、用户组和当前余额。
在“额度流水”用用户 ID 和时间范围筛选，按时间线整理每一次增加与扣减。
若涉及付费，进入订单中心和支付流水核对订单号、金额、商品、支付状态与到账记录。
若涉及生成，进入 AI 任务中心和成本分析核对任务状态、模型和扣费关联。
输出可审计结论：余额为何变化、对应的订单/任务号、是否需要后端修复或按既定流程补偿。

每日值班清单

AI 任务中心：失败率、积压、超时和高频错误是否异常。
AI 渠道：启用渠道是否健康，是否存在单点依赖或异常权重。
AI 成本分析：模型/渠道成本和用户扣费是否有突变。
订单中心与支付流水：待确认、失败和回调延迟订单是否需要跟进。
系统策略：仅在有变更计划时修改，日常巡检以读取和记录为主。
变更记录：所有配置发布、渠道开关、权益处理和高风险操作均保留对象 ID、时间、操作者和验证结果。