Admin 实施计划

目标与范围

为内部团队提供统一管理入口、平台公共管理与各产品管理空间。以 Studio 现有后台为基座逐项拆分，合并独立 Admin 已接入的客户、目录、价格、订单核对、授权和审计能力。使用同一 Core 身份并独立校验后台授权，供应渠道维护留在网关后台；各产品服务保留自己的业务事实。

本轮改造执行入口

基于当前 Admin 真实代码制定的改造计划明确 B0–B5 顺序；64 项功能清单覆盖完整范围；104 项核对清单逐项关联验收。首批 B1–B3 共 30 项功能（含已有能力回归），重点为公共管理、模型内容、Site 固定栏目与 Console/Site 发布读取；Studio 后续逐模块迁移，供应后台保持独立。

本轮细化沿用原 38 项主任务，AF/CK 为功能与核对编号，不重复计入任务数。设计与契约仍需按 B0 冻结，实际状态见改造基线记录。

需求输入与确认

以完整管理归属、Admin 详细需求和20 项客户商业操作为依据。原商业切片推进 A01–06、08–13、15–19；同步预览 A07 按能力，周期订阅 A14 待定，A20 供应入口首期不实施，供应后台独立使用。新增管理空间和基座迁移归 P09，具体批次与待定项见归属表。零售、FDE 与模型对接客户边界参见定价规则。

设计与原型

使用 shadcn 与 OceanWay 风格，按客户详情→价格预览→订单核对→调用排查组织原型。客户账号、员工身份与企业专属账户不可混为组织成员管理。

补统一管理首页→选择产品空间→产品菜单→带上下文进入公共客户/财务→返回产品的旅程。优先复用 Studio 已有表单和业务流程，不先重写全部组件；验证全局与产品范围的可辨识性。

财务动作展示目标、金额/积分、理由、证据和处理结果；未知结果先查询。使用实际后端的 Admin/Root 权限，未形成细粒度授权前不虚构已隔离的客服/财务角色。

API 与文档交付

逐项沿用 CA-A 接口映射：用户管理、model/pricing、topup、log/task、audit、option/authz。企业价格版本、报价预览、补单理由、调整幂等和结果查询按差异规范补齐。Core 负责写入和授权；Admin 不直连客户数据库或绕过业务 API。交付受控操作清单、字段/错误映射及维护手册。

实施步骤与交付物

保留原有八阶段 32 项客户商业任务，新增 P09 6 项管理空间与迁移任务，共九阶段 38 项，其中 P07.03 保留编号并后置，不作为首期必需任务。新旧任务分别记录覆盖范围，不能用原 20 项商业操作代表全部后台。主计划负责整体组织，原执行证据见两端开工基线。

操作覆盖与接入顺序逐项对应产品操作、参考 API、Core 任务及当前运行边界。条件启用项保留计划，但不虚构已确定的支付商、套餐金额或 Playground 选择。

依赖与接入顺序

P01/P02 可先进行。P03/P04 依赖 Core 客户与价格；P05 依赖订单和账务幂等；P06 依赖实际调用/任务事实；P07 依赖已落实的后台授权。按跨端联调计划逐条交付，不等待全部运营页一起完成。

P09.01 可先完成盘点，P09.02 接实际身份与权限；其余按模块依赖 Core 或产品 API，旧入口退出只等待对应新链路验收，不等待全部产品同时迁移。产品管理接口及内容发布接口在各责任仓设计，Admin 不创建临时事实库。

验收标准

• 同一身份登录不等于获得后台权限；三位维护人员有可区分的操作身份。
• 客户价格预览、Console 本人价格和实际扣费一致；历史消费保留原价格依据。
• 补单、加减积分和费用处理都有服务端授权、持久去重与审计；覆盖余额不能冒充增减。
• 排查页面不承诺不存在的筛选和指标；没有恢复协议的动作不提供一键退款/重跑。
• 首期统一入口不接入供应后台，也不将 Console 客户自助端列为管理员空间；供应后台独立使用。
• Studio 26 项模块均有目标空间与唯一写入方；新旧入口按模块切换，无重复钱包或后台双写；各产品设置和内容发布按目标范围执行。

待定项与后续范围

细粒度员工权限、支付方、充值套餐与周期订阅的启用范围待定；供应成本和毛利没有可核对数据前不纳入承诺指标。

本文定义计划，不累积执行日志。实际版本、完成状态和验证证据见项目进度；任务状态登记到本机工作台，并关联具体 CON-P/ADM-P 子任务；接口字段冻结与运行验收分别记录。