feat: expand novel IP and production workflows
This commit is contained in:
www
@@ -0,0 +1,99 @@
|
||||
# Work 同步文档索引
|
||||
|
||||
> 批次：`WORK_SYNC_2026-07-19_V11`
|
||||
> 状态：待上传
|
||||
> 入口：先阅读本文件，再阅读项目状态快照。
|
||||
|
||||
## 1. 当前有效文档
|
||||
|
||||
| 顺序 | 文档 | 版本 | 类型 | 当前状态 | 主要回答 |
|
||||
| ---: | --- | --- | --- | --- | --- |
|
||||
| 1 | `01_项目现状/PROJECT_STATUS_V1.md` | V1 | 不可变快照 | 当前基线 | 代码、数据、测试和运行现实是什么 |
|
||||
| 2 | `S_PLUS_BATCH_AUTOMATED_PRODUCTION_PIPELINE_V2.md` | V2 | 目标流程规范 | 当前目标/待分阶段实现 | 面向批量自动化和 S+ 质量，唯一生产流程应该是什么 |
|
||||
| 3 | `S_PLUS_PRODUCTION_FLOW_AUDIT_V1.md` | V1 | 现状流程审计 | 当前有效 | 当前实现为何不能直接承担无人值守批量生产 |
|
||||
| 4 | `02_架构设计/SYSTEM_ARCHITECTURE_V1.md` | V1 | 当前设计 | 有效 | 系统边界、模块和部署如何组织 |
|
||||
| 5 | `05_AI流水线/AI_PIPELINE_V1.md` | V1 | 当前设计 | 有效 | Provider、Prompt、队列、回退和成本如何工作 |
|
||||
| 6 | `06_数据库/DATABASE_CURRENT_V1.md` | V1 | 当前设计 | 有效 | 数据模型如何分组、怎样迁移和备份 |
|
||||
| 7 | `03_小说引擎/NOVEL_ENGINE_V1.md` | V1 | 当前设计 | 有效 | 小说生成、记忆、质量和版本如何工作 |
|
||||
| 8 | `04_短剧引擎/DRAMA_ENGINE_V1.md` | V1 | 当前设计 | 有效 | 剧本、分镜、视频、声音和合成如何工作 |
|
||||
| 9 | `04_短剧引擎/AI_VIDEO_TEST_LESSONS_V1.md` | V1 | 生产经验 | 有效 | 已验证的视频生产经验和反例有哪些 |
|
||||
| 10 | `07_版本记录/CHANGELOG.md` | 持续 | 追加记录 | 有效 | 每个同步批次改变了什么 |
|
||||
| 11 | `08_维护规范/WORK_SYNC_PROTOCOL.md` | V1 | 维护规范 | 有效 | Work 与代码怎样保持同步 |
|
||||
| 12 | `08_维护规范/DOCUMENT_TEMPLATE.md` | V1 | 模板 | 有效 | 新文档应如何写 |
|
||||
| 13 | `99_历史设计/README.md` | V1 | 历史索引 | 有效 | 旧系统 A/B 文档何时可使用 |
|
||||
| 14 | `SYNC_MANIFEST.md` | V11 | 校验清单 | 有效 | 本批次文件、来源和校验和是什么 |
|
||||
| 15 | `S_PLUS_SHORT_DRAMA_CODEX_OPTIMIZATION_V1_1.md` | V1.1 | 目标架构 | 当前有效 | S+ 内核的合同、质量门和实施路线是什么 |
|
||||
| 16 | `PROMPT_RULE_AUDIT_V1.md` | V1 | 规则审计 | 当前有效 | 历史 Prompt 中哪些规则保留、待验证或废弃 |
|
||||
| 17 | `SPLUS_PHASE_0_1_IMPLEMENTATION_REPORT.md` | V1 | 实施报告 | 已完成 | 保护、去污染、合同和硬门完成了什么 |
|
||||
| 18 | `SPLUS_PHASE_2_IMPLEMENTATION_REPORT.md` | V1 | 实施报告 | 工程完成/内容待验收 | 三阶段结构化写路径如何实现和部署 |
|
||||
| 19 | `KLING_S_PLUS_MODEL_ROUTING_SPEC_V1.0.md` | V1.0 | 模型路由规范 | 当前有效 | Kling S+ 的能力、路由、参数和质量规则是什么 |
|
||||
| 20 | `SPLUS_GENERATION_PLAN_IMPLEMENTATION_REPORT_V1.md` | V1 | 实施报告 | 工程完成/真实小样待验收 | 不可变计划怎样成为关键帧到成本审计的执行事实源 |
|
||||
| 21 | `SPLUS_MODEL_REGISTRY_AND_PLAN_DIFF_IMPLEMENTATION_REPORT_V1.md` | V1 | 实施报告 | 工程完成/真实小样待验收 | 能力、参数、价格如何版本化并与计划修订对比联动 |
|
||||
| 22 | `KLING_V3_OMNI_API_UPDATE_V1.md` | V1 | 官方能力快照 | 当前有效 | Kling V3 Omni 当前接口、限制和价格基线是什么 |
|
||||
| 23 | `LANDSCAPE_CHARACTER_ELEMENT_IMPLEMENTATION_REPORT_V1.md` | V1 | 实施报告 | 工程完成/真实元素待验收 | 16:9统一画幅和 Kling 视频角色元素怎样落地 |
|
||||
| 24 | `SPLUS_CHARACTER_TURNAROUND_ITERATION_REPORT_V1.md` | V1 | 实施与真实验收报告 | 工程保护链完成/单画布路线未达 S+ | 三视图实测、成本、硬门和分面板决策是什么 |
|
||||
| 25 | `SPLUS_CHARACTER_TURNAROUND_PROMPT_V4_AUDIT.md` | V4 | Prompt 与资产输入审计 | 当前有效 | 网页版分析哪些成立、旧 Prompt/经验如何被阻断、四个角色是否可进入生成 |
|
||||
| 26 | `AI_REQUEST_INSPECTOR_IMPLEMENTATION_REPORT_V1.md` | V1 | 实施报告 | 双端已上线/Provider Trace 待增强 | AI 请求参数、执行证据和隐私边界如何在页面展示 |
|
||||
| 27 | `SPLUS_CHARACTER_TURNAROUND_SPLIT_PANEL_IMPLEMENTATION_REPORT_V1.md` | V1 | 实施与真实验收报告 | 工程完成/首轮母版 A+ 88 | 分面板生成、断点续跑、单面板返修、母版合成、真实成本和首轮缺陷是什么 |
|
||||
| 28 | `SPLUS_EXECUTION_BRIDGE_EXTERNAL_ASSET_WORKFLOW_V1.md` | V1 | 实施报告 | 已完成/等待外部资产 | 确认资产计划如何在不伪造素材 ID 的前提下落地为导演分镜草案 |
|
||||
|
||||
### 1.1 不默认上传的本地追溯输入
|
||||
|
||||
- `S_PLUS_SHORT_DRAMA_CODEX_OPTIMIZATION_V1.md`：已由 V1.1 取代，只用于追溯初稿。
|
||||
- `豆包讨论.txt`：原始讨论输入，结论已审阅并吸收到当前规范，不作为代码事实上传。
|
||||
|
||||
## 2. 文档职责边界
|
||||
|
||||
### 项目状态
|
||||
|
||||
只记录某个时间点可验证的事实，包括源码结构、服务状态、测试、数据量和风险。V1 发布后不原地修改事实；下一次审计新建 `PROJECT_STATUS_V2.md`。
|
||||
|
||||
### 架构与领域文档
|
||||
|
||||
记录当前稳定边界、核心流程、约束和差距。结构性变化时升级文件版本，小的措辞修正可在 CHANGELOG 中说明。
|
||||
|
||||
### 功能设计
|
||||
|
||||
尚未实现的功能不要直接写进当前设计文档并标成已完成。应单独创建：
|
||||
|
||||
```text
|
||||
FEATURE_<功能名>_V1.md
|
||||
```
|
||||
|
||||
经过 Work 讨论确认后交给 Codex 实现；上线验证后再合并进当前设计文档。
|
||||
|
||||
### 架构决策
|
||||
|
||||
影响多个领域且存在替代方案的决策，建议使用：
|
||||
|
||||
```text
|
||||
ADR_<编号>_<主题>.md
|
||||
```
|
||||
|
||||
至少记录背景、决策、替代方案、影响和回滚条件。
|
||||
|
||||
## 3. 状态标记
|
||||
|
||||
| 标记 | 含义 |
|
||||
| --- | --- |
|
||||
| 当前有效 | 与当前代码现实一致，可作为讨论基线 |
|
||||
| 待实现 | 已完成设计，代码尚未完成 |
|
||||
| 部分实现 | 有入口或数据结构，但链路不完整 |
|
||||
| 待验证 | 代码存在，但测试/E2E/生产验证不足 |
|
||||
| 已废弃 | 不再作为当前方案，只供追溯 |
|
||||
| 历史参考 | 解释旧设计，不能推断当前实现 |
|
||||
|
||||
## 4. Work 使用提示
|
||||
|
||||
在 Work 中讨论新功能时，先引用最新 `PROJECT_STATUS` 和对应领域文档；不要只引用旧聊天或历史设计。若 Work 的回答与状态快照冲突，应标记为假设并要求代码审计，不直接让 Codex照旧方案开发。
|
||||
|
||||
## 5. 下一批计划
|
||||
|
||||
下一次同步优先包含：
|
||||
|
||||
- V2 流程 P0 安全门实现：候选默认不选中、拒绝清活动指针、合并只接收 `merge_ready`。
|
||||
- 关键帧批准状态和 Execution Plan 冻结时机修正。
|
||||
- 新建 `splus_v2` 项目的十步生产台首版。
|
||||
- 短篇/长篇/现成剧本三条路线和制作拆解合同。
|
||||
- 项目 #22 仅作为回归样本，不继续承担新流程验收。
|
||||
- `PROJECT_STATUS_V2.md`、测试结果、Git/备份基线和受控部署记录。
|
||||
@@ -0,0 +1,879 @@
|
||||
# AI 内容生产平台项目现状 V1
|
||||
|
||||
> 文档类型：项目状态回灌 / 技术审计快照
|
||||
> 审计时间：2026-07-15（Europe/Berlin）
|
||||
> 审计对象：`/www/wwwroot/ai` 当前工作区、当前 MySQL 数据库、当前 systemd 运行服务
|
||||
> 文档用途：作为 Work 的“代码现实”基线，不替代产品设计文档，也不替代 Git 版本记录。
|
||||
|
||||
## 0. 审计口径
|
||||
|
||||
本文件按以下优先级判断项目真实状态：
|
||||
|
||||
1. 当前工作区源码与配置结构。
|
||||
2. Prisma schema、迁移记录和数据库只读统计。
|
||||
3. 当前 systemd、Nginx、MySQL、Redis 运行状态。
|
||||
4. 构建与自动测试结果。
|
||||
5. `README.md`、`CURRENT_ARCHITECTURE.md`、`CODEX_PROGRESS.md` 与 `docs/system_a`、`docs/system_b` 等历史文档。
|
||||
|
||||
状态标记：
|
||||
|
||||
| 标记 | 含义 |
|
||||
| --- | --- |
|
||||
| 已实现且验证 | 代码存在，当前可构建，并有运行数据、测试或实际调用记录佐证 |
|
||||
| 已实现但验证不足 | 主体代码已存在，但自动测试、运行配置或完整 E2E 尚未达到发布基线 |
|
||||
| 部分接入 | 只有部分入口、部分 Provider 或部分流程可用 |
|
||||
| 仅设计/预留 | 有文档、数据结构或界面占位，但未形成完整可用链路 |
|
||||
|
||||
注意：本文中的 V1 是“状态文档版本”，不是 npm 包版本。当前各 workspace 的代码版本仍为 `0.1.0`，不应仅凭功能变多就直接对外宣布产品 V5.0。
|
||||
|
||||
## 1. 执行摘要
|
||||
|
||||
### 1.1 当前项目真实定位
|
||||
|
||||
当前系统已经不再只是“AI 小说系统”或“AI 漫剧系统”，实际代码覆盖：
|
||||
|
||||
- 小说导入、阅读、原创生成、章节质量循环与版本管理。
|
||||
- 故事圣经、世界观、角色、剧情记忆与 IP 资产管理。
|
||||
- 分集、剧本、分镜、关键帧、图生视频和候选片段选择。
|
||||
- 真人/仿真人短剧生产、原生音频视频、字幕、BGM、SFX、转场与 FFmpeg 合成。
|
||||
- AI Provider 目录、模型偏好、成本记录、路由、实验台与回退。
|
||||
- 队列、任务重试、人工介入、额度、审核、运营后台和审计日志。
|
||||
- 面向生产的独立创作工具，当前已开放“人物三视图”。
|
||||
|
||||
因此，面向 Work 的项目名称建议使用：
|
||||
|
||||
```text
|
||||
AI 内容生产平台
|
||||
```
|
||||
|
||||
### 1.2 当前健康度
|
||||
|
||||
| 检查项 | 当前结论 |
|
||||
| --- | --- |
|
||||
| 后端 API | `ai-backend.service` 正在运行，健康检查返回 `ok` |
|
||||
| 队列 Worker | `ai-workers.service` 正在运行，消费 14 个 BullMQ 队列 |
|
||||
| 数据库 | MySQL 正在运行，33 个 Prisma 迁移全部已部署 |
|
||||
| Redis | 正在运行，Worker 与 API 均配置为使用 Redis |
|
||||
| 前台/后台 | Vue 3 + Vite 生产构建通过，Nginx 直接托管静态产物 |
|
||||
| 全仓构建 | 通过：backend、admin、user-app、workers 均成功构建 |
|
||||
| 自动测试 | 未通过：后端 273 条测试中 238 通过、35 失败；Worker 1 条通过；前台和后台无测试文件 |
|
||||
| Git 基线 | 高风险：`main` 仅 1 个提交，当前有 85 个修改项、47 个未跟踪项 |
|
||||
| 运行版本一致性 | 需处理：审计构建产物晚于 backend/worker 进程启动时间，当前进程尚未加载最新构建 |
|
||||
| 存储 | 当前为本机私有存储；MinIO 代码已实现但当前未完整配置 |
|
||||
| AI 默认模式 | 全局 `AI_PROVIDER_MODE=mock`，但数据库中有大量真实 Provider 可被显式选择 |
|
||||
|
||||
### 1.3 结论
|
||||
|
||||
当前项目已经是一个有真实数据、真实调用和真实视频资产的内部生产平台，不是原型空壳；但它还不是可安全标记为“稳定生产版”的发布基线。
|
||||
|
||||
当前最重要的工作顺序应为：
|
||||
|
||||
1. 固化 Git 与数据库备份基线。
|
||||
2. 修复测试和状态枚举漂移。
|
||||
3. 对齐当前构建与运行进程。
|
||||
4. 补齐队列任务执行覆盖。
|
||||
5. 再继续扩展新功能。
|
||||
|
||||
## 2. 当前项目实际架构
|
||||
|
||||
### 2.1 仓库形态
|
||||
|
||||
项目为 npm workspaces 单仓库：
|
||||
|
||||
```text
|
||||
ai/
|
||||
├── backend/ NestJS API、Prisma、业务编排、Provider、FFmpeg 调用
|
||||
├── workers/ BullMQ Worker，消费队列后委托 backend 执行业务
|
||||
├── user-app/ Vue 3 + Vite 用户端 H5
|
||||
├── admin/ Vue 3 + Vite 运营管理后台
|
||||
├── deploy/ 开发依赖与 Nginx 示例，生产脚本尚不完整
|
||||
├── docs/ 原系统 A/B、AI 生产经验、教程和成本资料
|
||||
├── data/ 项目内容、剧本、分镜与生成过程资料
|
||||
├── storage/ 当前本地私有素材存储
|
||||
└── tmp/ 临时处理文件
|
||||
```
|
||||
|
||||
### 2.2 运行拓扑
|
||||
|
||||
```mermaid
|
||||
flowchart TB
|
||||
User[用户端 Vue H5] --> Nginx[Nginx]
|
||||
Admin[管理端 Vue H5] --> Nginx
|
||||
Nginx --> API[NestJS API :3010]
|
||||
API --> MySQL[(MySQL ai_manga)]
|
||||
API --> Redis[(Redis)]
|
||||
API --> Storage[本地私有存储\nMinIO 可选]
|
||||
API --> Providers[AI Providers]
|
||||
API --> FFmpeg[FFmpeg / FFprobe]
|
||||
API --> BullMQ[BullMQ 14 队列]
|
||||
BullMQ --> Worker[独立 Worker\n并发 2]
|
||||
Worker --> InternalAPI[受 WORKER_SECRET 保护的内部接口]
|
||||
InternalAPI --> API
|
||||
```
|
||||
|
||||
### 2.3 后端基础设施
|
||||
|
||||
- 框架：NestJS 10。
|
||||
- ORM：Prisma 6，MySQL。
|
||||
- 队列：BullMQ 5 + Redis。
|
||||
- 文件：本地私有文件为当前主存储，MinIO 为可选实现。
|
||||
- 媒体：FFmpeg、FFprobe。
|
||||
- 文件解析：PDF、DOCX、纯文本。
|
||||
- 鉴权：JWT。
|
||||
- 后台权限：`admin`、`operator`、`finance`、`auditor` 角色与细粒度 permission。
|
||||
- API 前缀：`/api`。
|
||||
- 请求体上限：当前 160 MB。
|
||||
- 中间件：请求 ID、安全响应头、HTTPS/代理判断、应用层加密请求处理。
|
||||
- API 返回：统一 envelope 和统一异常过滤。
|
||||
|
||||
### 2.4 当前部署事实
|
||||
|
||||
- 后端由 `ai-backend.service` 托管。
|
||||
- Worker 由 `ai-workers.service` 托管。
|
||||
- Nginx 分别托管用户端与管理端，并反向代理 `/api/`。
|
||||
- MySQL、Redis 为本机服务。
|
||||
- 当前 `NODE_ENV=production`、`STORAGE_DRIVER=local`、Worker 并发为 2。
|
||||
- 后端没有强制 `HTTPS_REQUIRED`；传输安全依赖 Nginx 与部署配置。
|
||||
- `PUBLIC_ASSET_BASE_URL` 类配置当前未设置，依赖外部 Provider 获取临时素材 URL 的链路需要专项复核。
|
||||
|
||||
## 3. 已实现模块
|
||||
|
||||
### 3.1 后端模块
|
||||
|
||||
当前 `AppModule` 注册的业务模块：
|
||||
|
||||
| 模块 | 主要职责 | 状态 |
|
||||
| --- | --- | --- |
|
||||
| `AuthModule` | 注册、登录、JWT、账号状态 | 已实现且验证 |
|
||||
| `UsersModule` | 用户资料 | 已实现 |
|
||||
| `BillingModule` | 额度、订单、冻结、释放、后台人工调整 | 已实现但支付仅为 mock |
|
||||
| `ProjectsModule` | 项目、作品库、小说库、创意模式、流水线配置 | 已实现 |
|
||||
| `ProviderLabModule` | Provider 参数试跑与状态轮询 | 已实现 |
|
||||
| `AssetsModule` | 上传、下载、预览、Range 流、别名、选择状态 | 已实现且有大量真实素材 |
|
||||
| `NovelsModule` | 导入、解析、阅读、原创小说、Agent 与章节质量流程 | 已实现但测试不足 |
|
||||
| `StoryBiblesModule` | 故事圣经、制作规则、确认锁定 | 已实现 |
|
||||
| `CharactersModule` | 项目角色、全局角色、版本、状态、Prompt 审核与优化经验 | 已实现但复杂度较高 |
|
||||
| `MemoriesModule` | 剧情、角色、伏笔与连续性记忆 | 已实现但测试桩未同步 |
|
||||
| `EpisodesModule` | 分集计划、请求预览、质量闸门 | 已实现但质量测试有漂移 |
|
||||
| `ScriptsModule` | 单集剧本、分镜、动态时长、提示词、转场 | 已实现但测试不足 |
|
||||
| `ImagesModule` | 角色图、锚点图、三视图、关键帧、视觉质检 | 已实现 |
|
||||
| `LiveActionModule` | 真人短剧准备、关键帧、视频、QC、合并、后期 | 已实现但仍处于生产化磨合 |
|
||||
| `MediaModule` | TTS、字幕、传统漫剧合成、音频片段重试 | 已实现 |
|
||||
| `ProvidersModule` | Provider 目录、配置、调用、日志、成本、异步视频轮询 | 已实现且有真实调用 |
|
||||
| `QueuesModule` | RenderTask、BullMQ、重试、取消、恢复、Worker 委托 | 已实现但执行覆盖不完整 |
|
||||
| `ReviewsModule` | 文本/素材审核、返修、案例授权 | 已实现但当前数据库尚无审核记录 |
|
||||
| `AdminModule` | 运营后台聚合 API、审计、配置、Router 审计 | 已实现 |
|
||||
|
||||
`AiRouterModule` 没有作为顶层模块单独注册，但被 `LiveActionModule` 导入并实际用于真人视频路由。当前它不是覆盖全平台所有 AI 请求的统一 Router。
|
||||
|
||||
### 3.2 用户端模块
|
||||
|
||||
用户端实际为 Vue 3 单页应用，不是旧文档描述的 uni-app 多路由实现。
|
||||
|
||||
顶级导航：
|
||||
|
||||
- 创作：新建、提示词直出、API 快测。
|
||||
- 工具：独立创作工具。
|
||||
- 项目：项目列表、制作台、IP 资产中心、进度。
|
||||
- 作品：视频、小说、素材。
|
||||
- 任务：运行任务、审核、额度与成本。
|
||||
- 我的：账号、角色资产、教程。
|
||||
|
||||
制作台主流程：
|
||||
|
||||
```text
|
||||
来源 -> 版权 -> 故事圣经 -> 角色 -> 记忆 -> 分集
|
||||
-> 剧本/分镜 -> 真人视频 -> 合成 -> 审核
|
||||
```
|
||||
|
||||
独立创作工具当前状态：
|
||||
|
||||
| 工具 | 状态 |
|
||||
| --- | --- |
|
||||
| 人物三视图 | 已开放；支持主锚点参考或输入本次唯一角色描述；生成后可下载和视觉质检 |
|
||||
| 影视场景专家 | 待接入 |
|
||||
| 9 宫格分镜 | 待接入 |
|
||||
| 16 宫格分镜 | 待接入 |
|
||||
| 25 宫格分镜 | 待接入 |
|
||||
| 原创剧本 | 待接入 |
|
||||
|
||||
虽然 `user-app/src/pages/` 中保留了多页面文件，但当前 `App.vue` 实际只加载大型 `pages/index/index.vue`，没有 Vue Router。多数业务都集中在一个约 1.35 万行的页面组件中。
|
||||
|
||||
### 3.3 管理端模块
|
||||
|
||||
管理端实际为自研 Vue 3 单页后台，不是完整 GeekerAdmin 集成。
|
||||
|
||||
当前菜单包括：
|
||||
|
||||
- 仪表盘、使用教程。
|
||||
- 项目、小说、全局角色、项目角色、分镜、成品。
|
||||
- 订单额度、内容审核、任务。
|
||||
- Router 审计、爆款诊断、AI 平台入口。
|
||||
- Provider、成本、用户、素材。
|
||||
- 系统配置、版权、审计日志。
|
||||
|
||||
后台同样集中在一个约 1.03 万行的 `App.vue` 中，没有实际 Router、Store 和拆分后的 Views。
|
||||
|
||||
## 4. 已完成功能与完成度
|
||||
|
||||
| 业务域 | 当前能力 | 完成度判断 |
|
||||
| --- | --- | --- |
|
||||
| 账号与安全 | 注册、登录、JWT、账号禁用、密码重置、RBAC、操作审计、应用层加密 | 已实现且验证 |
|
||||
| 项目 | 新建、列表、删除、取消、进度、作品库、提示词直出分镜 | 已实现 |
|
||||
| 小说导入 | 粘贴、文件上传、章节切割、编辑、版权确认 | 已实现 |
|
||||
| 小说阅读 | 目录、分页/翻页、阅读进度、书签、批注 | 已实现 |
|
||||
| 原创小说 | 创作向导、生成计划、章节 Agent、上下文、质检、修复、版本、批次 | 已实现但自动测试未稳定 |
|
||||
| 故事与世界观 | StoryBible、WorldBible、制作文本和锁定 | 已实现 |
|
||||
| 角色资产 | 项目角色、全局演员、外观版本、状态、服装、声音、授权范围 | 已实现 |
|
||||
| 角色提示词闭环 | Prompt 版本、审核、优化经验、下一次生成吸收 | 已实现 |
|
||||
| 人物三视图 | 主锚点模式、纯描述覆盖模式、旗舰模板、下载、视觉评分 | 已实现 |
|
||||
| IP 资产中心 | 场景/道具提取、主资产、版本、Prompt、冲突检查 | 已实现但 UI/测试仍在磨合 |
|
||||
| 长篇记忆 | 剧情记忆、角色记忆、伏笔线程、连续性检查 | 已实现但测试未同步 |
|
||||
| 分集 | 动态数量、质量闸门、请求预览与 Prompt 覆盖 | 已实现但当前一条质量测试失败 |
|
||||
| 剧本 | 剧本生成、人工编辑、确认、请求预览 | 已实现 |
|
||||
| 分镜 | 动态时长、关键帧/视频 Prompt、前后镜衔接、转场字段、视觉板 | 已实现 |
|
||||
| 关键帧 | 角色/场景/道具参考、单镜/批量、视觉审核 | 已实现且有真实图片调用 |
|
||||
| 视频 | 单镜/批量、多候选、首帧/首尾帧/参考图、原生音频 Provider | 已实现且有真实视频调用 |
|
||||
| 视频 QC | 自动评分、同模型重试、Fallback、人工确认、候选选择 | 已实现但测试和策略仍在变化 |
|
||||
| 视频合并 | 硬切/转场、画面归一、源音轨、字幕、BGM、SFX、FFmpeg | 已实现但产品质量仍需持续验收 |
|
||||
| 原创音乐 | 音乐圣经、MusicProvider、BGM 对齐、资产包 | 部分接入，默认关闭 |
|
||||
| 口型 | LipSync Provider 抽象、策略与桥接 | 部分接入；当前真实 LipSync Provider 全部禁用 |
|
||||
| 素材库 | 类型、别名、分镜号/范围、选中/候选/淘汰、Range 播放、下载 | 已实现 |
|
||||
| 队列 | 14 队列、任务幂等、重试、取消、过期恢复、人工介入 | 已实现但部分任务类型无 Worker 执行器 |
|
||||
| 成本 | Provider 成本规则、调用日志、人民币展示、额度冻结/释放 | 已实现；财务口径仍需统一 |
|
||||
| 支付 | 套餐、订单模型与 mock-pay | 仅测试，不是生产支付 |
|
||||
| 内容审核 | 文本、素材、后台复核、案例授权 | API/UI 已实现，但当前 `ContentReview` 为 0 条 |
|
||||
| 爆款诊断 | 样本、片段、创意模式、项目绑定 | 已实现，属于原设计后的扩展 |
|
||||
|
||||
## 5. 数据库结构
|
||||
|
||||
### 5.1 总体规模
|
||||
|
||||
- Prisma Model：61 个。
|
||||
- Prisma Enum：0 个。
|
||||
- 数据库迁移：33 个，当前全部已部署。
|
||||
- 索引、唯一约束和 JSON 字段大量使用。
|
||||
- 业务状态主要使用字符串字段，而不是数据库枚举。
|
||||
|
||||
### 5.2 模型分组
|
||||
|
||||
#### 用户与项目
|
||||
|
||||
- `User`
|
||||
- `UserModelPreference`
|
||||
- `Project`
|
||||
- `ProjectPipelineConfig`
|
||||
- `ProjectCreativePattern`
|
||||
- `CreativePattern`
|
||||
|
||||
#### 小说与 Agent
|
||||
|
||||
- `NovelSource`
|
||||
- `NovelChapter`
|
||||
- `NovelReadingProgress`
|
||||
- `NovelBookmark`
|
||||
- `NovelAnnotation`
|
||||
- `NovelGenerationPlan`
|
||||
- `NovelChapterVersion`
|
||||
- `NovelContextMemory`
|
||||
- `NovelQualityReport`
|
||||
- `NovelVersionSnapshot`
|
||||
- `NovelDerivativeJob`
|
||||
- `AgentPrompt`
|
||||
- `AgentRun`
|
||||
|
||||
#### 故事、版权与世界观
|
||||
|
||||
- `CopyrightRecord`
|
||||
- `StoryBible`
|
||||
- `WorldBible`
|
||||
|
||||
#### 角色与 IP 资产
|
||||
|
||||
- `Character`
|
||||
- `StoryCharacter`
|
||||
- `CharacterExtractionVersion`
|
||||
- `GlobalCharacter`
|
||||
- `GlobalCharacterAsset`
|
||||
- `GlobalCharacterLookVersion`
|
||||
- `CharacterImage`
|
||||
- `CharacterImageQualityReview`
|
||||
- `CharacterMemory`
|
||||
- `CharacterDesignVersion`
|
||||
- `CharacterPromptVersion`
|
||||
- `CharacterPromptReview`
|
||||
- `CharacterPromptOptimizationLesson`
|
||||
- `CharacterState`
|
||||
- `ActorProfile`
|
||||
- `ProjectVisualAsset`
|
||||
|
||||
#### 剧集生产
|
||||
|
||||
- `Episode`
|
||||
- `EpisodeScript`
|
||||
- `StoryboardShot`
|
||||
- `ShotImage`
|
||||
- `VideoClip`
|
||||
- `PlotMemory`
|
||||
- `PlotThread`
|
||||
- `ContinuityCheck`
|
||||
|
||||
#### 素材、任务与 Provider
|
||||
|
||||
- `Asset`
|
||||
- `RenderTask`
|
||||
- `ProviderConfig`
|
||||
- `ProviderLog`
|
||||
|
||||
#### 计费、审核与运营
|
||||
|
||||
- `Order`
|
||||
- `QuotaAccount`
|
||||
- `QuotaLog`
|
||||
- `RevisionRequest`
|
||||
- `ContentReview`
|
||||
- `CaseShowcase`
|
||||
- `HitAnalysisCase`
|
||||
- `HitAnalysisSegment`
|
||||
- `AnalyticsEvent`
|
||||
- `SystemConfig`
|
||||
- `OperationLog`
|
||||
|
||||
### 5.3 当前数据库数据快照
|
||||
|
||||
| 数据 | 数量 |
|
||||
| --- | ---: |
|
||||
| 用户 | 2 |
|
||||
| 项目 | 20 |
|
||||
| 小说源 | 10 |
|
||||
| 小说章节 | 256 |
|
||||
| 故事圣经 | 13 |
|
||||
| 项目角色 | 87 |
|
||||
| 全局角色 | 14 |
|
||||
| 分集 | 87 |
|
||||
| 单集剧本 | 21 |
|
||||
| 分镜 | 114 |
|
||||
| 素材 | 977 |
|
||||
| 任务 | 748 |
|
||||
| Provider 配置 | 112 |
|
||||
| Provider 调用日志 | 1002 |
|
||||
| 内容审核记录 | 0 |
|
||||
| 操作审计记录 | 44 |
|
||||
|
||||
素材构成：
|
||||
|
||||
| 类型 | 数量 |
|
||||
| --- | ---: |
|
||||
| image | 600 |
|
||||
| video_clip | 215 |
|
||||
| video | 74 |
|
||||
| audio | 50 |
|
||||
| subtitle | 33 |
|
||||
| 其他角色图、片段音频、成品类型 | 5 |
|
||||
|
||||
任务状态：
|
||||
|
||||
| 状态 | 数量 |
|
||||
| --- | ---: |
|
||||
| success | 646 |
|
||||
| failed | 77 |
|
||||
| manual_required | 22 |
|
||||
| pending | 2 |
|
||||
| completed | 1 |
|
||||
|
||||
`completed` 不在当前 `TASK_STATUSES` 常量中，属于历史状态漂移，需要迁移或兼容处理。
|
||||
|
||||
## 6. API 接口现状
|
||||
|
||||
### 6.1 总量
|
||||
|
||||
- Controller：25 个。
|
||||
- HTTP 方法装饰器：289 个。
|
||||
- API 全局前缀：`/api`。
|
||||
- 当前没有生成 OpenAPI/Swagger 规范，接口事实依赖 Controller、DTO 与前端 client。
|
||||
|
||||
### 6.2 分组
|
||||
|
||||
| 接口域 | 代表能力 | 路由规模 |
|
||||
| --- | --- | ---: |
|
||||
| Admin | 仪表盘、项目、用户、素材、作品、Provider、成本、审计、Router | 47 |
|
||||
| Characters | 项目角色、全局角色、版本、状态、IP 资产、Prompt、声音 | 47 |
|
||||
| Projects | 项目、库、阅读入口、创意模式、流水线配置 | 28 |
|
||||
| Live Action | 角色档案、关键帧、视频、QC、候选、渲染、音乐 | 21 |
|
||||
| Novel Generation | 生成计划、IP 圣经、章节、批次、暂停恢复 | 17 |
|
||||
| Providers | 目录、配置、执行、日志、成本、偏好 | 16 |
|
||||
| Billing | 套餐、订单、额度、冻结/释放、后台调整 | 13 |
|
||||
| Scripts | 剧本、分镜、请求预览、确认、重生 | 12 |
|
||||
| Memories | 剧情、角色、伏笔、上下文、连续性 | 11 |
|
||||
| Images | 角色图、关键帧、锚点、视觉质检 | 9 |
|
||||
| Queues | 创建、列表、重试、取消、恢复、统计 | 9 |
|
||||
| Reviews | 文本/素材审核、案例授权、后台复核 | 9 |
|
||||
| Novels / Wizard / Original | 导入、解析、原创、创作向导 | 16 |
|
||||
| Assets | 上传、预览、Range 下载、临时 URL | 7 |
|
||||
| Auth / Crypto | 登录注册、用户信息、加密会话 | 7 |
|
||||
| Episodes / StoryBible / Media | 分集、故事圣经、音频字幕视频 | 14 |
|
||||
|
||||
### 6.3 安全边界
|
||||
|
||||
- 业务接口主要使用 JWT Guard。
|
||||
- 管理能力在 Service 层执行 permission 检查。
|
||||
- Worker 内部接口使用 `WORKER_SECRET` 和 timing-safe 比较。
|
||||
- 生产环境缺失 Worker secret 时不会使用本地默认值。
|
||||
- 素材为私有存储，支持鉴权下载、Range 请求和带签名的临时 URL。
|
||||
- API Key 经服务端密钥加密存储，后台不回显明文。
|
||||
|
||||
## 7. 前后端目录结构
|
||||
|
||||
### 7.1 后端
|
||||
|
||||
```text
|
||||
backend/src/
|
||||
├── admin/
|
||||
├── ai-router/
|
||||
├── assets/
|
||||
├── auth/
|
||||
├── billing/
|
||||
├── characters/
|
||||
├── common/
|
||||
├── config/
|
||||
├── episodes/
|
||||
├── images/
|
||||
├── live-action/
|
||||
├── media/
|
||||
├── memories/
|
||||
├── novels/
|
||||
├── prisma/
|
||||
├── projects/
|
||||
├── provider-lab/
|
||||
├── providers/
|
||||
├── queues/
|
||||
├── reviews/
|
||||
├── scripts/
|
||||
├── story-bibles/
|
||||
└── users/
|
||||
```
|
||||
|
||||
当前后端约 9.39 万行 TypeScript。最大文件：
|
||||
|
||||
- `live-action.service.ts`：约 1.42 万行。
|
||||
- `characters.service.ts`：约 7443 行。
|
||||
- `providers.service.ts`：约 6776 行。
|
||||
- `admin.service.ts`：约 6096 行。
|
||||
- `scripts.service.ts`：约 4600 行。
|
||||
|
||||
### 7.2 用户端
|
||||
|
||||
```text
|
||||
user-app/src/
|
||||
├── api/
|
||||
├── components/tools/CreativeTools.vue
|
||||
├── pages/index/index.vue
|
||||
├── pages/auth/
|
||||
├── pages/help/
|
||||
├── pages/projects/
|
||||
├── pages/user/
|
||||
├── App.vue
|
||||
├── workflow.ts
|
||||
└── styles.css
|
||||
```
|
||||
|
||||
当前约 2.37 万行，主要功能集中在 `index.vue`、`api/client.ts` 和全局 CSS。
|
||||
|
||||
### 7.3 管理端
|
||||
|
||||
```text
|
||||
admin/src/
|
||||
├── api/client.ts
|
||||
├── api/crypto.ts
|
||||
├── App.vue
|
||||
├── main.ts
|
||||
└── styles.css
|
||||
```
|
||||
|
||||
`router/`、`stores/`、`views/` 当前只有占位文件。管理端约 1.34 万行。
|
||||
|
||||
### 7.4 Worker
|
||||
|
||||
```text
|
||||
workers/src/main.ts
|
||||
```
|
||||
|
||||
每个队列由 BullMQ Worker 消费，任务本体通过内部 HTTP 接口委托后端执行，Worker 本身不重复实现业务逻辑。
|
||||
|
||||
## 8. 当前 AI 调用流程
|
||||
|
||||
### 8.1 通用 Provider 流程
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
Input[业务输入] --> Preference[用户/项目模型偏好]
|
||||
Preference --> Config[ProviderConfig]
|
||||
Config --> Limit[启停、优先级、成本上限]
|
||||
Limit --> Execute[ProvidersService]
|
||||
Execute --> Sync[同步文本/图片/音频]
|
||||
Execute --> Async[异步视频提交与轮询]
|
||||
Sync --> Log[ProviderLog]
|
||||
Async --> Log
|
||||
Log --> Asset[Asset / VideoClip]
|
||||
Log --> Task[RenderTask 状态与成本]
|
||||
Execute --> Fallback[失败回退或人工介入]
|
||||
```
|
||||
|
||||
### 8.2 Provider 现状
|
||||
|
||||
- Provider 配置共 112 个。
|
||||
- Mock 配置 11 个，其中 10 个启用、1 个 LipSync mock 关闭。
|
||||
- Real 配置 101 个，其中 64 个启用、37 个关闭。
|
||||
- 当前已启用的真实 Provider 覆盖 Text、Novel、Image、Video、Voice、Music、Embedding、Moderation。
|
||||
- 真实 LipSync Provider 当前全部关闭。
|
||||
- 代表性已启用模型族：OpenAI、豆包/火山、DeepSeek、Qwen、Kimi、智谱、MiniMax、Kling、Seedance、Seedream、Sora 等。
|
||||
- 全局默认仍为 mock，显式选择真实 Provider 时可产生真实调用。
|
||||
|
||||
Provider 日志当前共 1002 条：
|
||||
|
||||
| 状态 | 数量 |
|
||||
| --- | ---: |
|
||||
| success | 825 |
|
||||
| failed | 170 |
|
||||
| running | 5 |
|
||||
| cancelled | 2 |
|
||||
|
||||
数据库 `cost_actual` 原始累计值为 354.9416。由于 Provider 成本币种和历史规则可能不同，该值只能用于技术对账，不能直接视为财务账单。
|
||||
|
||||
近期真实使用主要集中在：
|
||||
|
||||
- `openai-image`。
|
||||
- `kling-v3-native-audio-720p-video`。
|
||||
- `openai-responses-text`。
|
||||
- `volcengine_seedance_20_mini`。
|
||||
- `volcengine-seedream-50-image`。
|
||||
- `openai-tts`。
|
||||
|
||||
### 8.3 真人短剧流程
|
||||
|
||||
```text
|
||||
剧本/外部提示词
|
||||
-> 动态分镜与前后镜关系
|
||||
-> 角色/场景/道具资产计划
|
||||
-> Prompt Engine
|
||||
-> 关键帧
|
||||
-> 视频 Provider 预检与成本估算
|
||||
-> 单镜或批量视频、多候选
|
||||
-> 自动 QC / 重试 / Fallback / 人工选择
|
||||
-> Scene Composer 计划
|
||||
-> 字幕 / 源音轨 / TTS / BGM / SFX / 转场
|
||||
-> FFmpeg 合成
|
||||
-> 成品与素材库
|
||||
```
|
||||
|
||||
当前支持的后期参数包括：源音轨、额外音频、字幕、BGM、SFX、环境音、无源音轨回退 SFX、口型、字幕模式和音量控制。原创音乐与 Scene Composer 由项目配置控制，默认并非全部开启。
|
||||
|
||||
### 8.4 小说流程
|
||||
|
||||
```text
|
||||
创作 Brief / 导入小说
|
||||
-> 生成计划
|
||||
-> IP/故事/世界观规则
|
||||
-> Agent Prompt
|
||||
-> 章节草稿
|
||||
-> 质量报告
|
||||
-> 自动修复或重写
|
||||
-> 章节版本与上下文记忆
|
||||
-> 小说快照
|
||||
-> 听书/短剧派生任务
|
||||
```
|
||||
|
||||
小说新引擎代码已形成，但目前自动测试和管理体验还没有达到可无人值守批量生产的程度。
|
||||
|
||||
## 9. 队列任务流程
|
||||
|
||||
### 9.1 队列与任务
|
||||
|
||||
BullMQ 队列共 14 个：
|
||||
|
||||
```text
|
||||
novel_queue
|
||||
parse_queue
|
||||
story_queue
|
||||
character_queue
|
||||
episode_queue
|
||||
script_queue
|
||||
storyboard_queue
|
||||
image_queue
|
||||
audio_queue
|
||||
subtitle_queue
|
||||
video_queue
|
||||
qc_queue
|
||||
review_queue
|
||||
analytics_queue
|
||||
```
|
||||
|
||||
任务类型共 21 个，状态包括：
|
||||
|
||||
```text
|
||||
pending / running / success / failed / retrying
|
||||
cancelled / manual_required / skipped
|
||||
```
|
||||
|
||||
### 9.2 执行链
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
API[API 创建 RenderTask] --> Idempotency[输入哈希 / 幂等键]
|
||||
Idempotency --> Queue[BullMQ 入队]
|
||||
Queue --> Worker[独立 Worker]
|
||||
Worker --> Secret[WORKER_SECRET]
|
||||
Secret --> Delegate[backend internal/worker execute]
|
||||
Delegate --> Provider[通用 Provider 执行]
|
||||
Delegate --> Live[真人视频业务执行]
|
||||
Provider --> Result[日志 / 素材 / 状态]
|
||||
Live --> Result
|
||||
Result --> Retry[按类型自动重试]
|
||||
Retry --> Manual[耗尽后 manual_required]
|
||||
```
|
||||
|
||||
已实现：
|
||||
|
||||
- 幂等键与输入哈希。
|
||||
- 不同任务类型的默认重试次数。
|
||||
- 任务取消与队列 Job 清理。
|
||||
- stale running 任务恢复。
|
||||
- 失败后自动重试与人工介入。
|
||||
- 队列统计。
|
||||
|
||||
### 9.3 当前队列覆盖缺口
|
||||
|
||||
任务目录比 Worker 执行器更宽。以下任务在当前 `providerTypeForTask` 中没有实际 Provider 映射，也不属于真人业务执行器，走通用 Worker 时会被标记为 `skipped`：
|
||||
|
||||
- `long_memory_generate`
|
||||
- `subtitle_generate`
|
||||
- `live_action_keyframe_generate`
|
||||
- `live_action_video_render`
|
||||
- `analytics_event`
|
||||
|
||||
其中部分能力目前由同步 Service 方法直接执行，因此功能本身不一定不可用；但“全部已队列化”的说法不准确。`video_render` 在通用任务映射中指向 `VideoProvider`，与 FFmpeg 合成语义也需要重新核对。
|
||||
|
||||
## 10. 已实现但未完整写入原设计文档的功能
|
||||
|
||||
相较 `docs/system_a`、`docs/system_b` 的早期设计，当前代码额外出现或显著深化了：
|
||||
|
||||
1. 小说创作向导、章节 Agent、上下文构建、质量修复、版本快照与派生任务。
|
||||
2. 小说阅读器、书签、批注、阅读进度。
|
||||
3. 全局角色资产、外观版本、角色状态、角色 Prompt 版本与审核经验闭环。
|
||||
4. 人物三视图独立工具，以及“主锚点参考/本次描述覆盖”两种模式。
|
||||
5. 三视图视觉质量评分、问题提取、优化经验进入下一次生成。
|
||||
6. 项目级场景/道具/IP 资产中心和主资产版本。
|
||||
7. 动态分镜时长、前后镜衔接、转场字段、请求预览与 Prompt 人工覆盖。
|
||||
8. 真人短剧 AI Router、镜头评分、成本预检、候选视频与自动质量闭环。
|
||||
9. Kling 原生音频、Seedance、Seedream、Hailuo、Sora 等多模型目录。
|
||||
10. Scene Composer、字幕/BGM/SFX/环境音开关、源音轨策略和原创音乐包。
|
||||
11. 素材别名、选中/候选/淘汰状态、按分镜号和范围联合筛选。
|
||||
12. Provider Lab、模型偏好、人民币成本标签和 Provider 调用审计。
|
||||
13. 爆款诊断、拉片片段、创意模式和项目模式绑定。
|
||||
14. API 应用层加密、临时素材签名 URL、视频 Range 流式播放。
|
||||
|
||||
## 11. 与原设计文档的主要差异
|
||||
|
||||
| 领域 | 原设计世界 | 当前代码现实 |
|
||||
| --- | --- | --- |
|
||||
| 产品定位 | 系统 A 小说转漫剧 + 系统 B 真人写真 | 已合并演化为小说、短剧、视频、角色/IP 资产、创作工具平台 |
|
||||
| 用户端 | uni-app 多页面 | Vue 3 + Vite H5，核心集中在单一大页面 |
|
||||
| 管理端 | GeekerAdmin | 自研 Vue 单页后台，未引入完整 GeekerAdmin 架构 |
|
||||
| 数据库 | 约 20 个核心表 | 61 个 Model、33 个迁移 |
|
||||
| Provider | 抽象层与少量真实模型 | 112 个配置，覆盖大量国内外文本/图像/视频/声音模型 |
|
||||
| AI Router | 后续路由能力 | 已用于真人视频，但未成为全平台统一入口 |
|
||||
| 小说 | 原创 mock + 导入改编 | 已加入 Agent、质量循环、版本、阅读器和派生任务 |
|
||||
| 分镜 | 固定镜头/宫格倾向 | 动态时长、上下镜关系、首尾帧/多图、转场与声音层 |
|
||||
| 视频 | 图片、TTS、字幕、简单合成 | 真人视频候选、QC、原生音频、Scene Composer、复杂 FFmpeg 后期 |
|
||||
| 队列 | 所有生产任务统一异步 | Worker 已运行，但部分声明任务没有异步执行器，部分流程仍同步 |
|
||||
| 存储 | MinIO 优先设计 | 当前实际使用本地私有存储，MinIO 未完整配置 |
|
||||
| 支付 | 订单支付闭环 | 额度与 mock-pay 可用，真实支付未接入 |
|
||||
| 审核 | 内容审核闭环 | API/UI 已有，但数据库没有实际审核记录 |
|
||||
| 测试 | 文档定义生产验收 | 后端单测有覆盖但当前 35 条失败，前后端无自动测试 |
|
||||
| 版本管理 | 设计文档持续推进 | Git 只有初始提交，大量现实代码尚未形成版本基线 |
|
||||
|
||||
## 12. 当前待优化问题
|
||||
|
||||
### P0：必须先处理
|
||||
|
||||
#### 12.1 Git 无法代表当前系统
|
||||
|
||||
- `main` 只有 1 个提交。
|
||||
- 当前有 85 个修改项、47 个未跟踪项。
|
||||
- 多个数据库迁移、小说新引擎、Provider Lab、人物三视图、数据与文档都未纳入提交。
|
||||
|
||||
风险：服务器故障、误操作或换机后，无法从 Git 恢复当前系统。
|
||||
|
||||
建议：先做数据库与素材备份，再把当前状态拆成可审阅提交；不要把生成素材和临时文件混入源码提交。
|
||||
|
||||
#### 12.2 测试未达到发布基线
|
||||
|
||||
后端结果：
|
||||
|
||||
```text
|
||||
Test Files: 19 passed / 8 failed
|
||||
Tests: 238 passed / 35 failed
|
||||
```
|
||||
|
||||
失败主要分为：
|
||||
|
||||
1. 新增 Prisma 依赖后，旧测试 mock 没有补齐。
|
||||
2. 动态分镜、质量闸门、BGM/SFX 策略改变后，旧期望未更新。
|
||||
3. Provider 成本标签新增人民币后，断言仍使用旧文案。
|
||||
4. Seedance 真人参考图预检策略出现测试与实现不一致。
|
||||
|
||||
应逐条判断“测试旧了”还是“代码回归”，不能简单批量改断言。
|
||||
|
||||
#### 12.3 当前运行进程未加载最新构建
|
||||
|
||||
审计期间全仓构建通过，但 backend 和 worker 进程启动时间早于最新构建产物。需要在备份、测试和变更确认后执行受控重启，并做健康检查与核心链路冒烟测试。
|
||||
|
||||
### P1：高优先级
|
||||
|
||||
#### 12.4 队列执行覆盖不完整
|
||||
|
||||
补齐或明确移出队列：长篇记忆、字幕、真人关键帧、真人合并、分析事件。避免任务显示已入队，Worker 最后却标记 `skipped`。
|
||||
|
||||
#### 12.5 状态字段漂移
|
||||
|
||||
数据库中存在历史 `completed`，当前代码只认 `success`。项目、任务、素材、审核等大量状态均为自由字符串。建议建立状态字典、迁移脚本和兼容测试。
|
||||
|
||||
#### 12.6 本地素材是单机风险点
|
||||
|
||||
当前 977 个素材使用本地私有存储，MinIO 未完整配置，部署目录中也没有可执行备份脚本。至少需要：
|
||||
|
||||
- 数据库定时备份。
|
||||
- `storage/private` 增量备份。
|
||||
- 恢复演练。
|
||||
- 磁盘容量与失败告警。
|
||||
|
||||
#### 12.7 任务和调用失败积压
|
||||
|
||||
- RenderTask：77 failed、22 manual_required、2 pending。
|
||||
- ProviderLog：170 failed、5 running。
|
||||
|
||||
需要区分历史测试垃圾、外部异步任务和真实待处理任务，并提供批量归档/恢复策略。
|
||||
|
||||
#### 12.8 Provider 配置过多且默认策略不清晰
|
||||
|
||||
数据库中有 112 个 Provider 配置，但全局默认仍是 mock。真实 Provider 启停、用户偏好、项目偏好、Router 和显式 provider_code 同时存在，容易出现“页面选了 A，实际走 B”的理解成本。
|
||||
|
||||
建议为每次调用固定记录并展示：请求 Provider、路由原因、实际 Provider、模型、参数、输入参考图、成本和回退链。
|
||||
|
||||
#### 12.9 外部 Provider 素材 URL 配置需复核
|
||||
|
||||
当前公开素材基础 URL 未设置，而部分第三方视频/图片 Provider 需要可访问的临时参考图 URL。应把此项纳入 Provider preflight，而不是运行到提交时才失败。
|
||||
|
||||
#### 12.10 审核闭环尚未实际使用
|
||||
|
||||
`ContentReview` 当前为 0 条。需要确认是入口未触发、审核结果写到了其他字段，还是生产流程绕过了正式审核。
|
||||
|
||||
### P2：结构性优化
|
||||
|
||||
#### 12.11 超大文件与前端单体化
|
||||
|
||||
- `live-action.service.ts` 约 1.42 万行。
|
||||
- 用户端主页面约 1.35 万行。
|
||||
- 管理端主页面约 1.03 万行。
|
||||
|
||||
这会放大回归风险和协作冲突。建议按稳定业务边界逐步拆分，不做一次性大重构。
|
||||
|
||||
#### 12.12 缺少前后端自动测试与正式 E2E
|
||||
|
||||
用户端、管理端目前没有测试文件。后端以单元测试为主，没有覆盖“登录 -> 项目 -> 分镜 -> 真实 Provider -> 素材 -> 合并”的稳定 E2E。
|
||||
|
||||
#### 12.13 API 缺少机器可读契约
|
||||
|
||||
当前 289 个接口依赖 TypeScript DTO 和手写 client，没有 OpenAPI 文档与自动 client 生成。接口数量继续增长后，前后端容易漂移。
|
||||
|
||||
#### 12.14 生产运维不完整
|
||||
|
||||
`deploy/` 只有开发 compose、Nginx 示例和说明，没有落地的发布、回滚、备份、日志轮转、监控和告警脚本。当前主要依靠 systemd 日志与人工检查。
|
||||
|
||||
#### 12.15 真实支付、多租户和财务对账未完成
|
||||
|
||||
- 支付仍为 mock-pay。
|
||||
- 当前是用户级数据隔离，没有组织/租户模型。
|
||||
- `cost_actual` 的币种与财务账单口径需统一。
|
||||
|
||||
## 13. 建议建立的唯一真相机制
|
||||
|
||||
### 13.1 Work 负责
|
||||
|
||||
```text
|
||||
产品定位
|
||||
业务规则
|
||||
架构决策
|
||||
未来路线
|
||||
功能设计文档
|
||||
```
|
||||
|
||||
### 13.2 Git + Codex 负责
|
||||
|
||||
```text
|
||||
当前代码
|
||||
数据库迁移
|
||||
实现细节
|
||||
测试结果
|
||||
部署与运行事实
|
||||
```
|
||||
|
||||
### 13.3 同步规则
|
||||
|
||||
每个重要功能建议使用以下闭环：
|
||||
|
||||
```text
|
||||
Work 讨论
|
||||
-> FEATURE_xxx_V1.md
|
||||
-> Codex 实现
|
||||
-> 测试与部署
|
||||
-> 更新 CHANGELOG.md
|
||||
-> 更新 PROJECT_STATUS_Vn.md
|
||||
-> 回灌 Work
|
||||
```
|
||||
|
||||
状态文档不应每次全量覆盖，而应保留 V1、V2、V3，便于追踪系统如何演化。
|
||||
|
||||
## 14. 建议放入 Work 的首批资料
|
||||
|
||||
```text
|
||||
AI 内容生产平台/
|
||||
├── 01_项目现状/
|
||||
│ └── PROJECT_STATUS_V1.md
|
||||
├── 02_架构设计/
|
||||
│ └── SYSTEM_ARCHITECTURE.md
|
||||
├── 03_小说引擎/
|
||||
│ └── NOVEL_ENGINE.md
|
||||
├── 04_短剧引擎/
|
||||
│ └── DRAMA_ENGINE.md
|
||||
├── 05_AI流水线/
|
||||
│ └── AI_PIPELINE.md
|
||||
├── 06_数据库/
|
||||
│ └── DATABASE.md
|
||||
└── 07_版本记录/
|
||||
└── CHANGELOG.md
|
||||
```
|
||||
|
||||
本次只生成真实状态基线。其余文档应以本文件为依据重新整理，而不是直接复制旧系统 A/B 文档并假定其全部已实现。
|
||||
|
||||
## 15. 本次验证记录
|
||||
|
||||
已执行并确认：
|
||||
|
||||
- 全仓生产构建通过。
|
||||
- Prisma schema 可用。
|
||||
- 33 个迁移与当前数据库一致。
|
||||
- 后端健康检查通过。
|
||||
- backend 与 worker systemd 服务正在运行。
|
||||
- MySQL、Redis、Nginx 正在运行。
|
||||
- 数据库只读数量与 Provider/任务状态统计完成。
|
||||
- 自动测试执行完成，并如实记录 35 条失败。
|
||||
|
||||
未执行：
|
||||
|
||||
- 未重启生产服务。
|
||||
- 未修改数据库数据。
|
||||
- 未触发新的付费 AI 生成。
|
||||
- 未做浏览器端完整 E2E。
|
||||
- 未做数据库或素材恢复演练。
|
||||
|
||||
@@ -0,0 +1,209 @@
|
||||
# AI 内容生产平台架构设计 V1
|
||||
|
||||
> 文档状态：当前有效
|
||||
> 基线日期：2026-07-15
|
||||
> 事实来源：当前源码、Prisma schema、生产配置与 `PROJECT_STATUS_V1.md`
|
||||
> 维护原则：记录稳定边界和已确认事实，不复制完整代码。
|
||||
|
||||
## 1. 架构目标
|
||||
|
||||
平台面向小说、角色/IP 资产、短剧和音视频成品的一体化生产，当前架构要同时满足：
|
||||
|
||||
- 长文本生产中的记忆、版本和质量循环。
|
||||
- 图片、视频、声音等多 Provider 的差异化调用。
|
||||
- 角色、服装、场景和道具在跨镜头生产中的连续性。
|
||||
- 耗时任务的异步执行、重试、人工介入和成本追踪。
|
||||
- 素材私有访问、Range 播放、下载与后期合成。
|
||||
- 用户端生产工作台和管理端运营审计。
|
||||
|
||||
## 2. 系统边界
|
||||
|
||||
```mermaid
|
||||
flowchart TB
|
||||
User[用户端 Vue 3 H5] --> Nginx[Nginx]
|
||||
Admin[管理端 Vue 3 H5] --> Nginx
|
||||
Nginx --> API[NestJS API :3010]
|
||||
API --> MySQL[(MySQL)]
|
||||
API --> Redis[(Redis / BullMQ)]
|
||||
API --> Storage[本地私有存储\nMinIO 可选]
|
||||
API --> AI[外部 AI Providers]
|
||||
API --> Media[FFmpeg / FFprobe]
|
||||
Redis --> Worker[独立 Worker]
|
||||
Worker --> Internal[受密钥保护的内部执行接口]
|
||||
Internal --> API
|
||||
```
|
||||
|
||||
外部依赖包括文本、图片、视频、语音、音乐、Embedding 和审核模型。平台负责业务编排、资产关系、质量控制和成本记录，不把外部模型的临时任务状态当作最终业务状态。
|
||||
|
||||
## 3. 仓库结构
|
||||
|
||||
项目采用 npm workspaces 单仓库：
|
||||
|
||||
| 目录 | 职责 |
|
||||
| --- | --- |
|
||||
| `backend/` | NestJS API、Prisma、业务编排、Provider 与媒体处理 |
|
||||
| `workers/` | BullMQ 消费，委托后端内部接口执行业务 |
|
||||
| `user-app/` | Vue 3 + Vite 用户端 H5 |
|
||||
| `admin/` | Vue 3 + Vite 管理后台 |
|
||||
| `deploy/` | 开发依赖和 Nginx 示例，生产运维脚本尚不完整 |
|
||||
| `docs/` | 当前设计、历史设计、经验和同步包 |
|
||||
| `data/` | 项目内容、剧本、分镜和生产资料 |
|
||||
| `storage/` | 当前本地私有素材存储 |
|
||||
| `tmp/` | 临时媒体处理文件 |
|
||||
|
||||
## 4. 后端分层
|
||||
|
||||
### 4.1 接入层
|
||||
|
||||
- HTTP API 统一使用 `/api` 前缀。
|
||||
- JWT 负责用户身份，管理能力执行角色和 permission 校验。
|
||||
- 统一响应 envelope、异常过滤、请求 ID 和安全响应头。
|
||||
- 请求体上限当前为 160 MB。
|
||||
- 素材接口支持鉴权下载、Range 流和临时签名 URL。
|
||||
|
||||
### 4.2 业务域
|
||||
|
||||
| 业务域 | 核心模块 |
|
||||
| --- | --- |
|
||||
| 身份与计费 | `AuthModule`、`UsersModule`、`BillingModule` |
|
||||
| 项目与素材 | `ProjectsModule`、`AssetsModule` |
|
||||
| 小说与世界观 | `NovelsModule`、`StoryBiblesModule`、`MemoriesModule` |
|
||||
| 角色与 IP | `CharactersModule`、`ImagesModule` |
|
||||
| 分集与剧本 | `EpisodesModule`、`ScriptsModule` |
|
||||
| 真人短剧 | `LiveActionModule`、`MediaModule` |
|
||||
| AI 与任务 | `ProvidersModule`、`ProviderLabModule`、`QueuesModule` |
|
||||
| 审核与运营 | `ReviewsModule`、`AdminModule` |
|
||||
|
||||
`AiRouterModule` 当前服务于真人视频域，尚未成为全平台所有 AI 请求的统一入口。文档和界面不得把它描述成已完成的全局智能路由。
|
||||
|
||||
### 4.3 数据层
|
||||
|
||||
- Prisma 6 + MySQL。
|
||||
- 当前 61 个 Model、33 个已部署迁移。
|
||||
- 业务状态大多为字符串；历史值漂移需要通过状态字典和兼容迁移治理。
|
||||
- JSON 用于保存 Provider 参数、Prompt 快照、质量报告和扩展元数据。
|
||||
|
||||
### 4.4 异步执行层
|
||||
|
||||
- Redis + BullMQ，共 14 个队列。
|
||||
- Worker 并发当前为 2。
|
||||
- Worker 不重复业务实现，通过受 `WORKER_SECRET` 保护的内部接口委托后端。
|
||||
- `RenderTask` 保存幂等键、输入哈希、重试、成本与人工介入状态。
|
||||
|
||||
当前并非所有声明任务都已完整队列化。长篇记忆、字幕、真人关键帧、真人合并和分析事件存在同步执行或 Worker 映射缺口，详见 `AI_PIPELINE_V1.md`。
|
||||
|
||||
### 4.5 媒体层
|
||||
|
||||
- FFmpeg 负责归一、拼接、转场、字幕、BGM、SFX、环境音和混音。
|
||||
- FFprobe 负责媒体元信息探测。
|
||||
- 视频模型可返回原生音轨；后期策略决定保留、压低或补充外部音频。
|
||||
- LipSync 已有抽象和策略字段，但真实 Provider 当前均未启用。
|
||||
|
||||
## 5. 前端架构现实
|
||||
|
||||
### 5.1 用户端
|
||||
|
||||
用户端为 Vue 3 + Vite H5。当前核心功能集中在 `pages/index/index.vue`，没有启用 Vue Router。顶级入口包括创作、工具、项目、作品、任务和我的。
|
||||
|
||||
独立工具目前只有“人物三视图”正式开放；影视场景、9/16/25 宫格和原创剧本仍为待接入状态。
|
||||
|
||||
### 5.2 管理端
|
||||
|
||||
管理端是自研 Vue 3 单页后台，并非完整 GeekerAdmin。主要功能集中在 `App.vue`，`router/`、`stores/`、`views/` 仍是占位结构。
|
||||
|
||||
### 5.3 结构风险
|
||||
|
||||
用户端、管理端和若干后端 Service 已形成超大文件。后续应按稳定业务边界渐进拆分，避免一次性重构影响现有真实生产链路。
|
||||
|
||||
## 6. 核心数据流
|
||||
|
||||
### 6.1 内容生产
|
||||
|
||||
```text
|
||||
来源/创作 Brief
|
||||
-> 版权与项目规则
|
||||
-> 故事/世界观/角色/IP 资产
|
||||
-> 分集与剧本
|
||||
-> 动态分镜
|
||||
-> 关键帧或多图参考
|
||||
-> 视频候选
|
||||
-> 自动 QC / 人工选择
|
||||
-> 字幕、音频、BGM、SFX、转场
|
||||
-> FFmpeg 成品
|
||||
-> 审核与作品库
|
||||
```
|
||||
|
||||
### 6.2 AI 调用
|
||||
|
||||
```text
|
||||
业务请求
|
||||
-> 用户/项目模型偏好
|
||||
-> Provider 配置与预检
|
||||
-> 同步调用或异步提交
|
||||
-> ProviderLog
|
||||
-> Asset / VideoClip / RenderTask
|
||||
-> 质量评估、回退或人工介入
|
||||
```
|
||||
|
||||
## 7. 安全与隐私
|
||||
|
||||
- API Key 由服务端密钥加密保存，后台不回显明文。
|
||||
- Worker 内部接口使用 timing-safe 密钥比较。
|
||||
- 素材默认私有，不依赖可枚举静态 URL。
|
||||
- Nginx 承担公网 TLS；应用当前未强制 `HTTPS_REQUIRED`。
|
||||
- 外部 Provider 使用参考图时，应只提交限时、最小权限 URL。
|
||||
- Work 同步文档禁止包含 `.env`、API Key、JWT、数据库密码、私有素材 URL 和用户个人数据。
|
||||
|
||||
## 8. 部署与运行
|
||||
|
||||
当前生产事实：
|
||||
|
||||
- `ai-backend.service`、`ai-workers.service` 由 systemd 托管。
|
||||
- Nginx 托管两套前端静态产物并代理 API。
|
||||
- MySQL、Redis 为本机服务。
|
||||
- 主存储为本地私有目录，MinIO 仅有代码能力，尚未完整配置。
|
||||
- 全仓生产构建已通过，但运行进程需受控重启后才会加载最新构建。
|
||||
|
||||
当前缺少完整的发布、回滚、备份、日志轮转、监控和恢复演练脚本。这些属于发布基线，不应只保留为历史设计。
|
||||
|
||||
## 9. 架构约束
|
||||
|
||||
1. 数据库 schema 和迁移是数据结构唯一真相。
|
||||
2. Provider 调用必须留下实际 Provider、模型、参数快照、成本和回退记录。
|
||||
3. 角色、场景和道具应通过资产 ID/版本引用，不靠 Prompt 文本隐式继承。
|
||||
4. 外部模型状态、平台任务状态和素材状态必须分层管理。
|
||||
5. 付费生成前必须完成参数和参考图预检。
|
||||
6. 视频质量闭环允许人工确认，不能把模型评分直接等同于发布通过。
|
||||
7. 历史设计只能解释来路，不能覆盖当前代码事实。
|
||||
|
||||
## 10. 当前优先级
|
||||
|
||||
### P0
|
||||
|
||||
- 备份数据库和素材，固化 Git 基线。
|
||||
- 修复 35 条后端失败测试。
|
||||
- 受控重启并验证最新构建。
|
||||
|
||||
### P1
|
||||
|
||||
- 补齐队列执行覆盖和状态字典。
|
||||
- 建立本地素材备份与恢复演练。
|
||||
- 明确 Provider 路由优先级和实际调用展示。
|
||||
- 补齐外部素材 URL preflight。
|
||||
|
||||
### P2
|
||||
|
||||
- 渐进拆分超大 Service 和前端单体组件。
|
||||
- 引入 OpenAPI 契约和关键 E2E。
|
||||
- 完善生产发布、回滚、监控与告警。
|
||||
|
||||
## 11. 更新触发条件
|
||||
|
||||
发生以下任一变化时更新本文并提升版本：
|
||||
|
||||
- 新增或删除顶层业务模块。
|
||||
- 数据库、队列、存储或部署拓扑改变。
|
||||
- AI Router 扩展为平台级入口。
|
||||
- 前端路由或应用边界发生结构性变化。
|
||||
- 安全边界、租户模型或支付模式改变。
|
||||
|
||||
@@ -0,0 +1,147 @@
|
||||
# 小说引擎现状与设计 V1
|
||||
|
||||
> 文档状态：当前有效
|
||||
> 基线日期：2026-07-15
|
||||
> 适用范围：小说导入、阅读、原创生成、质量循环、版本与派生任务。
|
||||
|
||||
## 1. 当前定位
|
||||
|
||||
小说引擎不是单一“生成一章”接口，而是平台的长文本内容底座。它负责把来源、创作约束、世界观、角色、剧情记忆和质量标准组织成可追踪的章节生产流程，并为短剧、听书等下游提供稳定文本资产。
|
||||
|
||||
## 2. 能力边界
|
||||
|
||||
### 已实现
|
||||
|
||||
- 粘贴、TXT、DOCX、PDF 等来源导入和章节切割。
|
||||
- 小说目录、分页阅读、阅读进度、书签和批注。
|
||||
- 原创小说创作向导与生成计划。
|
||||
- StoryBible、WorldBible、角色和项目规则接入。
|
||||
- Agent Prompt、AgentRun 与章节生成编排。
|
||||
- 上下文记忆、章节版本、质量报告、自动修复和重写。
|
||||
- 小说版本快照和听书/短剧派生任务数据结构。
|
||||
|
||||
### 尚未达到稳定基线
|
||||
|
||||
- 无人值守长批次生产。
|
||||
- 全链路自动测试和正式 E2E。
|
||||
- Agent 策略、质量阈值和人工确认的统一运营界面。
|
||||
- 派生任务的完整异步执行覆盖。
|
||||
|
||||
## 3. 核心对象
|
||||
|
||||
| 对象 | 作用 |
|
||||
| --- | --- |
|
||||
| `NovelSource` | 导入或原创小说的主记录 |
|
||||
| `NovelChapter` | 当前可读章节 |
|
||||
| `NovelGenerationPlan` | 原创目标、结构、节奏和批次计划 |
|
||||
| `NovelChapterVersion` | 草稿、修复、重写和确认版本 |
|
||||
| `NovelContextMemory` | 供后续章节消费的压缩上下文 |
|
||||
| `NovelQualityReport` | 章节质量维度、问题与修改建议 |
|
||||
| `NovelVersionSnapshot` | 可追踪的整书状态快照 |
|
||||
| `NovelDerivativeJob` | 听书、短剧等下游派生请求 |
|
||||
| `AgentPrompt` | 可版本化 Agent 指令 |
|
||||
| `AgentRun` | Agent 实际执行与输入输出记录 |
|
||||
| `StoryBible` / `WorldBible` | 故事、世界规则和不可违反约束 |
|
||||
| `CharacterMemory` / `PlotMemory` | 人物和剧情连续性信息 |
|
||||
|
||||
## 4. 生产流程
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
Brief[创作 Brief / 导入文本] --> Plan[生成计划]
|
||||
Plan --> Bible[故事与世界观规则]
|
||||
Bible --> Context[上下文构建]
|
||||
Context --> Prompt[Agent Prompt]
|
||||
Prompt --> Draft[章节草稿]
|
||||
Draft --> Quality[质量报告]
|
||||
Quality --> Pass{达到阈值?}
|
||||
Pass -- 否 --> Repair[定向修复或重写]
|
||||
Repair --> Quality
|
||||
Pass -- 是 --> Confirm[确认章节版本]
|
||||
Confirm --> Memory[更新上下文与伏笔]
|
||||
Memory --> Snapshot[版本快照 / 下游派生]
|
||||
```
|
||||
|
||||
## 5. 上下文构建
|
||||
|
||||
每章生成不应把整本小说无差别塞入模型。上下文按优先级组成：
|
||||
|
||||
1. 当前项目和生成计划的硬约束。
|
||||
2. StoryBible、WorldBible 中与本章相关的规则。
|
||||
3. 当前角色状态、关系、服装/身份等连续性信息。
|
||||
4. 上一章结尾和当前章目标。
|
||||
5. 尚未回收的伏笔与必须推进的剧情线程。
|
||||
6. 长篇压缩记忆和必要的原文片段。
|
||||
7. 文风、篇幅、视角和禁用项。
|
||||
|
||||
所有自动压缩都必须保留来源章节和版本，以便发现错漏后回溯。
|
||||
|
||||
## 6. 质量循环
|
||||
|
||||
质量检查至少覆盖：
|
||||
|
||||
- 章节目标是否完成。
|
||||
- 因果、时间线、人物动机是否成立。
|
||||
- 角色口吻、能力、关系和状态是否连续。
|
||||
- 伏笔是否误删、提前泄露或遗忘。
|
||||
- 节奏、冲突、信息增量和章节钩子。
|
||||
- 文风、重复、空泛解释和模板化表达。
|
||||
- 与版权、合规和项目制作规则的冲突。
|
||||
|
||||
修复策略应优先定向改写问题段落；只有结构性失败时才整章重写。每次修复生成新版本，不覆盖原始版本。
|
||||
|
||||
## 7. 人工确认点
|
||||
|
||||
建议保留以下人工闸门：
|
||||
|
||||
- 生成计划确认。
|
||||
- StoryBible/WorldBible 锁定。
|
||||
- 核心角色和长期伏笔确认。
|
||||
- 首章与关键转折章确认。
|
||||
- 质量循环多次失败后的人工处置。
|
||||
- 下游改编前的版本冻结。
|
||||
|
||||
## 8. Provider 策略
|
||||
|
||||
- NovelProvider 与 TextProvider 均可参与，但必须记录实际模型。
|
||||
- 章节生成、质量审查和定向修复可使用不同模型配置。
|
||||
- 用户偏好、项目偏好、显式 `provider_code` 与系统默认的优先级必须可解释。
|
||||
- 真实调用失败后可回退，但不可静默切换后仍展示原模型名称。
|
||||
- 成本记录需区分估算值和 Provider 返回的实际值。
|
||||
|
||||
## 9. 与短剧引擎的契约
|
||||
|
||||
下游短剧不直接读取“任意最新草稿”，应消费明确的小说快照或已确认章节版本。派生输入至少包含：
|
||||
|
||||
- 来源小说、章节和版本 ID。
|
||||
- 已确认的人物、世界观和不可更改事实。
|
||||
- 可压缩、可改编和禁止删减的内容范围。
|
||||
- 目标时长、集数、媒介风格和受众。
|
||||
|
||||
改编产生的新事实不得反向污染小说正史，除非人工确认并写入新的 StoryBible/版本。
|
||||
|
||||
## 10. 当前风险
|
||||
|
||||
1. 新增 Prisma 依赖后部分单元测试 mock 未同步。
|
||||
2. Agent、上下文和质量逻辑分布在多个服务，缺少稳定 E2E。
|
||||
3. 长篇记忆任务声明存在，但 Worker 执行映射不完整。
|
||||
4. 状态字符串缺少统一字典，历史数据可能出现兼容问题。
|
||||
5. 批量生产的暂停、恢复、幂等和成本上限需要更强验证。
|
||||
|
||||
## 11. 不可破坏的规则
|
||||
|
||||
1. 所有章节修改必须形成版本，不直接覆盖已确认稿。
|
||||
2. 生成请求必须能追溯到 Prompt、上下文和 Provider。
|
||||
3. 故事圣经的硬约束优先于模型自由发挥。
|
||||
4. 长篇记忆是辅助索引，不是原文唯一副本。
|
||||
5. 下游派生必须绑定明确快照。
|
||||
6. 质量评分不能替代人工对关键章节的确认。
|
||||
|
||||
## 12. 下一阶段
|
||||
|
||||
- 修复小说相关测试桩和状态期望。
|
||||
- 增加“计划 -> 3 章批次 -> 质量修复 -> 快照”的 E2E。
|
||||
- 明确章节状态机和迁移规则。
|
||||
- 补齐长篇记忆与派生任务的 Worker 执行器。
|
||||
- 为 AgentRun 增加成本、实际模型和输入摘要展示。
|
||||
|
||||
@@ -0,0 +1,323 @@
|
||||
# AI 真人/漫剧视频流水线测试踩坑记录 V1
|
||||
|
||||
更新时间：2026-06-12
|
||||
|
||||
用途：
|
||||
|
||||
- 记录测试阶段已经遇到的问题、原因判断、系统优化点。
|
||||
- 后续接入 Kling、Seedance、Wan、Vidu、Runway、Veo 等平台时，按同一套准入标准测试，避免重复烧钱。
|
||||
- 本文件是运营/开发测试手册，不替代 `docs/` 里的系统需求文档。
|
||||
|
||||
## 当前阶段定位
|
||||
|
||||
当前仍是测试磨合阶段，不追求一次性自动发布。
|
||||
|
||||
目标顺序：
|
||||
|
||||
1. 跑通自动化流水线。
|
||||
2. 找到各 Provider 的能力边界。
|
||||
3. 把失败原因转成系统规则。
|
||||
4. 形成可恢复、可路由、可统计成本的生产流程。
|
||||
5. 最后再逐步提高自动化比例。
|
||||
|
||||
## 已验证结论
|
||||
|
||||
### Hailuo 适合做什么
|
||||
|
||||
Hailuo / MiniMax Hailuo 2.3 Fast 当前更适合：
|
||||
|
||||
- 都市真人短剧普通镜头。
|
||||
- 中景、远景、走路、转身、递物、沉默、反应镜头。
|
||||
- 咖啡厅、街道、办公室、豪车、酒店、家庭等现实场景。
|
||||
- 旁白 + 字幕 + BGM 推动剧情的短剧。
|
||||
- 成本敏感的批量生产。
|
||||
|
||||
当前实测成本：
|
||||
|
||||
- `minimax_hailuo_23_fast`：约 `$0.317 / 10秒`
|
||||
- `minimax_hailuo_23`：约 `$0.467 / 10秒`
|
||||
|
||||
### Hailuo 不适合硬扛什么
|
||||
|
||||
Hailuo 对以下镜头可控性不足：
|
||||
|
||||
- 凌空翻滚、复杂武打、连续打斗。
|
||||
- 精准手诀、结印、舞蹈式手部动作。
|
||||
- 法相天地、千臂法身、巨型神像复杂动作。
|
||||
- 一镜中塞太多高复杂动作。
|
||||
- 正脸强台词口型同步。
|
||||
|
||||
处理原则：
|
||||
|
||||
- 不要在同一失败动作上无脑重跑 Hailuo。
|
||||
- 如果同类复杂动作 1-2 次失败，优先切换 Provider 或补动作参考/姿势关键帧。
|
||||
- 修仙、法相、打斗、次元壁穿越等镜头默认标记为高价值/高复杂度，不按普通都市镜头处理。
|
||||
|
||||
## 分镜时长经验
|
||||
|
||||
### Hailuo 时长设计规则
|
||||
|
||||
Hailuo 当前按真实可用规格优先设计：
|
||||
|
||||
- 常规可用镜头时长：6 秒 / 10 秒。
|
||||
- 真人短剧主流程优先按 10 秒长镜头设计。
|
||||
- 只有非常简单的过渡镜头、环境镜头、无台词动作镜头，才考虑 6 秒。
|
||||
- 不再设计 7 秒、8 秒这种无法直接匹配 Hailuo 输出规格的镜头。
|
||||
|
||||
系统规则：
|
||||
|
||||
- 导演分镜上限必须允许 10 秒。
|
||||
- 如果原分镜明确是 10 秒，prepare 阶段不得自动压缩成 5 秒或 8 秒。
|
||||
- 负面约束里的“避免嘴部特写”不能导致镜头被误判成 insert 特写。
|
||||
- “手里的道具”不能被误判成“手部特写”，只有手部/手指/手掌/手腕/手势等明确关键词才算 insert。
|
||||
|
||||
### 3 秒碎片问题
|
||||
|
||||
法相天地三段式测试暴露问题：
|
||||
|
||||
- 镜头切太碎，像图片拼接。
|
||||
- Hailuo 实际输出常按 6 秒返回，系统再裁成 3/3/4 秒时，动作容易被截断。
|
||||
- 复杂动作被拆太短，会失去电影感和动作连贯性。
|
||||
|
||||
结论：
|
||||
|
||||
- 普通反应镜头：3-5 秒可以。
|
||||
- 都市剧情镜头：5-6 秒更稳。
|
||||
- 复杂动作/爆点镜头：优先 8-10 秒一镜到底。
|
||||
- 不能把 6 秒 Provider 输出硬裁成 3 秒作为长期策略。
|
||||
|
||||
### 10 秒一镜到底结论
|
||||
|
||||
法相天地 10 秒 Hailuo 测试已验证：
|
||||
|
||||
- Hailuo API 可以返回 10 秒。
|
||||
- 10 秒一镜到底比 3 段裁切更连贯。
|
||||
- 人物、服装、场景稳定性明显提升。
|
||||
- 但复杂动作本身仍受 Provider 能力限制。
|
||||
|
||||
系统规则：
|
||||
|
||||
- `action_score >= 8` 且 `importance >= 8` 的镜头，优先生成 8-10 秒单镜头。
|
||||
- 如果 Provider 不支持目标时长，再由系统拆分，不要随意裁切关键动作。
|
||||
|
||||
## Prompt Engine 经验
|
||||
|
||||
直接把剧情发给视频模型，质量不稳定。
|
||||
|
||||
必须通过 Prompt Engine 组装：
|
||||
|
||||
- 角色。
|
||||
- 场景。
|
||||
- 主动作。
|
||||
- 镜头大小。
|
||||
- 运镜。
|
||||
- 动作时间轴。
|
||||
- 情绪表演。
|
||||
- 灯光。
|
||||
- 特效时机。
|
||||
- 声音卡点。
|
||||
- 负面约束。
|
||||
|
||||
已落地：
|
||||
|
||||
- Motion Director Prompt。
|
||||
- 10 秒仙侠一镜到底时间轴。
|
||||
- Hailuo 长镜头 prompt 上限提升。
|
||||
|
||||
仍需注意：
|
||||
|
||||
- Prompt 只能提高概率，不能保证复杂动作精确执行。
|
||||
- 复杂动作需要动作参考图、姿势关键帧或更强 Provider。
|
||||
- 如果同一个 Prompt 多次失败，继续加形容词意义不大。
|
||||
|
||||
## 角色一致性经验
|
||||
|
||||
当前测试发现：
|
||||
|
||||
- 没有固定角色定妆图/锚点图时，人物容易漂移。
|
||||
- 修仙/奇幻镜头更容易因为特效导致人物脸和服装变化。
|
||||
- 都市短剧也需要固定林凡、陈雪、王伯这类角色锚点。
|
||||
|
||||
系统规则：
|
||||
|
||||
- 真人短剧正式验收前必须先做角色锚点图。
|
||||
- 新剧首轮至少固定主角、女主、关键配角。
|
||||
- Provider 小样要使用同一角色锚点和同一关键帧，避免测试结果不可比。
|
||||
|
||||
## 声音与字幕经验
|
||||
|
||||
没有声音、没有字幕、没有 BGM 的视频判定为失败。
|
||||
|
||||
已经遇到的问题：
|
||||
|
||||
- 屏幕女孩测试：无声音、无字幕，发布感不足。
|
||||
- 口型镜头：语音先到，嘴型后动。
|
||||
- 部分合成音量偏低，视觉还可以但情绪不够。
|
||||
|
||||
系统规则：
|
||||
|
||||
- 每条可发布视频必须包含字幕。
|
||||
- 每条可发布视频必须包含 BGM 或环境底噪。
|
||||
- 情绪镜头必须有 SFX：雨声、脚步、门声、心跳、低频冲击、sting 等。
|
||||
- 合成后必须跑音量检测。
|
||||
- 音量偏低时重新后期合成，不一定重跑视频。
|
||||
|
||||
## 台词与 lip-sync 经验
|
||||
|
||||
没有稳定 lip-sync Provider 前，不要把关键台词做成正脸大嘴型特写。
|
||||
|
||||
当前策略：
|
||||
|
||||
- `lip_sync_required=true` 但没有真实 lip-sync Provider 时：
|
||||
- 改成旁白。
|
||||
- 改成字幕。
|
||||
- 改成中景/侧脸/轻口型。
|
||||
- 避免正脸嘴部特写。
|
||||
|
||||
未来接入 lip-sync Provider 后：
|
||||
|
||||
- 只给关键正脸台词使用。
|
||||
- 不全片 lip-sync，避免成本翻倍。
|
||||
- lip-sync 放在视频片段生成后、FFmpeg 合成前。
|
||||
|
||||
## 成本控制经验
|
||||
|
||||
默认策略：
|
||||
|
||||
- 每个镜头默认只生成 1 条。
|
||||
- 不默认生成 2-3 条候选。
|
||||
- 只有封面级、爆点、最后反转、人工验收阶段才允许候选 2 条。
|
||||
- 任何候选数增加都必须进入成本预估和审计日志。
|
||||
|
||||
当前后台已支持：
|
||||
|
||||
- AI 接入列表展示每 10 秒成本。
|
||||
- Provider `cost_summary`。
|
||||
- 单次成本上限。
|
||||
- 当日成本上限。
|
||||
- `price_per_second=0` 不当成免费，而是提示需账单回填。
|
||||
|
||||
## Provider 路由经验
|
||||
|
||||
推荐基础路由：
|
||||
|
||||
```text
|
||||
普通都市镜头
|
||||
=> Hailuo
|
||||
|
||||
都市高价值镜头
|
||||
=> Hailuo 优先，必要时 Kling / Vidu / Wan 对比
|
||||
|
||||
修仙 / 法相 / 打斗 / 次元壁 / 复杂动作
|
||||
=> Premium Provider 候选
|
||||
|
||||
正脸台词
|
||||
=> 有 lip-sync Provider 才允许正脸特写，否则中景/旁白/字幕
|
||||
|
||||
成本超预算
|
||||
=> Premium -> Hailuo -> Seedance/Mock
|
||||
```
|
||||
|
||||
不要把“平台选择”写死在业务代码里，必须走 Router。
|
||||
|
||||
## Provider 准入测试标准
|
||||
|
||||
每接入一个新视频 Provider，都按固定小样测试：
|
||||
|
||||
1. 同一项目。
|
||||
2. 同一角色锚点图。
|
||||
3. 同一关键帧。
|
||||
4. 同一镜头文本。
|
||||
5. 同一目标时长。
|
||||
6. 同一分辨率/比例。
|
||||
7. 记录真实成本。
|
||||
8. 记录失败原因。
|
||||
9. 记录生成耗时。
|
||||
10. 记录人工观感评分。
|
||||
|
||||
必须记录：
|
||||
|
||||
- `provider_code`
|
||||
- `model_name`
|
||||
- `clip_id`
|
||||
- `asset_id`
|
||||
- `duration`
|
||||
- `cost_actual`
|
||||
- `quality_score`
|
||||
- `human_acceptance`
|
||||
- `failure_reason`
|
||||
- `prompt_version`
|
||||
- `keyframe_asset_id`
|
||||
|
||||
## 人工验收标准
|
||||
|
||||
当前 mock-qc 分数只能说明流程没坏，不能代表可发布。
|
||||
|
||||
真人视频上线前必须人工看：
|
||||
|
||||
- 人物是否稳定。
|
||||
- 动作是否连贯。
|
||||
- 镜头是否像真实拍摄。
|
||||
- 字幕是否准确。
|
||||
- 声音是否完整。
|
||||
- BGM/SFX 是否有情绪。
|
||||
- 口型是否明显穿帮。
|
||||
- 是否有明显 AI 手、脸、身体变形。
|
||||
- 成本是否在预算内。
|
||||
|
||||
## 不要重复踩的坑
|
||||
|
||||
- 不要把 mock-qc 通过当成真实质量通过。
|
||||
- 不要无音频/无字幕就判断视频流程合格。
|
||||
- 不要用 3 秒碎切测试复杂动作。
|
||||
- 不要在 Hailuo 上反复烧复杂修仙动作。
|
||||
- 不要把 `price_per_second=0` 当成免费。
|
||||
- 不要默认生成 2-3 条候选。
|
||||
- 不要让正脸台词在没有 lip-sync 时直出。
|
||||
- 不要只看最终成片，要保留脚本、分镜、prompt、关键帧、音频、视频片段、合成记录。
|
||||
- 不要默认认为 `mock-video` 就是全链路零成本；如果 TTS Provider 已启用真实平台，Mock 视频合成仍可能调用真实 TTS。零成本压测要显式指定 `mock-voice` 或关闭音频。
|
||||
- 真实 Hailuo / Kling / Wan 等图生视频前必须先跑 preflight，确认关键帧是 PNG/JPG/WebP；Mock SVG 只能测流程，不能直接发给真实视频 Provider。
|
||||
- Hailuo Fast 跑都市真人 10 秒镜头可用，5 条 10 秒顺序生成约 9 分钟，总成本记录 `$1.585`；后续应进入队列并在后台显示耗时。
|
||||
- 只用单张临时关键帧会改善画面质感，但不能彻底解决同脸一致性；要上架必须补“角色锚点图 / 定妆图 / 同脸参考图”流程。
|
||||
- 都市短剧 Hailuo 长镜头比 3-6 秒碎切更像真人短剧，但部分镜头仍会像关键帧慢推；Prompt 里要继续强化明确动作、人物走位、视线、反应和镜头结束动作。
|
||||
- 角色锚点图 V1 对关键帧生成有效：同一角色的脸、服装、气质会比临时起图更稳；但 Hailuo Fast 当前按单首帧图生视频跑，不能直接吃多角色参考图，所以运动中仍可能轻微改脸。
|
||||
- 锚点重跑应优先挑第 1 镜、第 3 镜、第 5 镜这类“角色出场 / 冲突 / 反转”镜头；默认候选仍为 1 条，避免成本翻倍。
|
||||
- 真人短剧对白不能一镜一段 TTS 直接读完；只要 `dialogue_text` 里出现 `角色名：台词`，必须拆成多段 TTS，每段记录 `speaker_name` / `character_id` / `voice_id` / `voice_style`。
|
||||
- 角色声线是发布级基础配置：顾辰、林雨薇、周浩、管家这类核心角色必须先在 Character 表绑定声音；否则即使画面像真人，声音也会变成解说感。
|
||||
- 主持人、旁白也要当作独立声线处理；如果没有角色记录，至少要走固定 narration / host voice，不能复用男主或女主声音。
|
||||
- 多声线 TTS 只解决“谁在说话”的问题，不解决“嘴型同步”；正脸台词仍要继续走 lip-sync 或中景轻口型策略。
|
||||
- TTS 声音 ID 不能只看名字想当然：`Chinese (Mandarin)_Gentle_Senior` 在老管家场景听感偏女，不适合作为中老年男管家默认声线；当前老管家默认改为 `Chinese (Mandarin)_Gentleman`，但仍需人工听感确认。
|
||||
- 核心角色上线前要做“角色声线小样验收”：每个角色先生成 1-2 句固定台词试听，确认性别、年龄、气质，再进入整集成片，避免整集重合成。
|
||||
- Hailuo 2.3 标准版 1080P 比 Fast 768P 清晰度和雨夜质感略好，但第 5 镜 A/B 证明它不能单独解决“像图片动”的问题；高价值反转镜头更需要三关键帧/动作参考/更强 Provider，而不是只把 Fast 换成标准版。
|
||||
- Provider A/B 测试必须保护当前成片：生成候选后要恢复 `storyboard_shots.video_clip_asset_id`，避免实验 clip 自动替换正式整集。
|
||||
- 动作节拍链式生成 V1 对高价值反转镜头有效：第 5 镜用 2 段 Fast 生成，第二段用第一段结尾帧作为首帧，比单首帧慢推更能呈现“递卡 -> 看卡震惊”的动作链。
|
||||
- action beat 不能默认全片开启：成本、耗时都会增加，适合反转/封面/爆点/高价值动作镜头；普通对话镜头仍用单条生成。
|
||||
- preflight 必须按 action beat 的真实分段估算成本，否则后台会低估费用；第 5 镜 action beat 从单条 `$0.317` 变为 2 段 `$0.3804`。
|
||||
- action beat 只解决“动作链更连续”，不解决“同一角色像同一个演员”；整集样片必须单独检查人物脸、年龄感、发型、服装是否跨镜稳定。
|
||||
- 真实视频生成不能只传角色名字；必须把本镜出现角色的 ActorProfile 注入 provider prompt，并在 task input 记录 `actor_lock`，否则后台无法审计“这条视频到底有没有走锁脸策略”。
|
||||
- prepare 阶段不要把全项目角色描述混进单镜 prompt；单镜只允许注入本镜出现的人物，否则多人项目会增加串脸概率。
|
||||
- Hailuo 当前配置不是强角色参考模型，`supports_character_reference=false`；它可以做低成本图生视频，但发布级真人短剧要靠“角色锚点图生成首帧 + 强一致性 prompt + 人工抽检”，必要时横测支持角色参考的 Provider。
|
||||
- 如果整集都换脸，不要继续盲目重跑全片；应先重跑第 1 / 3 / 5 镜这种出场、冲突、反转镜头，对比抽帧确认角色锁定是否有效，再决定是否整集重跑。
|
||||
- 多角色音频不能把跨平台 voice_id 混用：`coral` 属于 OpenAI TTS，不能直接发给 MiniMax；Provider 层必须做 voice_id 适配或降级到当前 Provider 默认声线。
|
||||
- MiniMax TTS 返回 JSON 时必须先检查 `base_resp.status_code`；否则账号权限、voice_id、group_id 等真实错误会被误报成 `EMPTY_AUDIO`。
|
||||
- 小说上传走 encrypted JSON/base64 时，实际 HTTP body 会比原文件大约 33%；后端 body limit 必须高于文件限制，否则会先被 `request entity too large` 拦截。
|
||||
|
||||
## 下一步建议
|
||||
|
||||
短期优先：
|
||||
|
||||
1. 继续围绕都市真人短剧做 Hailuo 量产质量优化。
|
||||
2. 做角色锚点图/定妆图 V1。
|
||||
3. 做动作参考/姿势关键帧 V1。
|
||||
4. 用同一固定镜头横测 Kling / Seedance / Wan / Vidu。
|
||||
5. 建 Provider 准入表：质量、成本、失败率、耗时。
|
||||
6. 做 BGM/SFX 发布级音量标准。
|
||||
7. lip-sync 只做关键台词小样，不先全片接入。
|
||||
|
||||
长期原则：
|
||||
|
||||
- Hailuo 做低成本量产。
|
||||
- 高价值镜头交给高质 Provider。
|
||||
- Router 负责自动选模型。
|
||||
- QA + 人工抽检负责质量闭环。
|
||||
- 成本、失败、重试、降级全部进入审计。
|
||||
@@ -0,0 +1,239 @@
|
||||
# 短剧引擎现状与设计 V1
|
||||
|
||||
> 文档状态：当前有效
|
||||
> 基线日期：2026-07-15
|
||||
> 适用范围：分集、剧本、动态分镜、视觉资产、视频候选、质量控制与成片合成。
|
||||
|
||||
## 1. 当前定位
|
||||
|
||||
短剧引擎负责把已确认的故事内容转为可生产镜头，并持续管理人物、场景、表演、声音和后期之间的关系。当前系统同时支持真人/仿真人短剧、原生音频视频和传统“图片 + TTS + 字幕”合成，不应把任何单一模型当成完整导演系统。
|
||||
|
||||
## 2. 核心原则
|
||||
|
||||
1. 剧情完整度优先于固定镜头数量。
|
||||
2. 分镜时长由对白、动作、停顿和转场预算共同决定。
|
||||
3. 角色、服装、场景和关键道具必须引用明确资产版本。
|
||||
4. 首帧、首尾帧、多图参考和纯文本生成按镜头需要选择。
|
||||
5. 视频模型负责画面和可用原生声音，稳定文字 UI、字幕和进度条优先由后期完成。
|
||||
6. 表演、运镜、声音和镜头衔接都属于质量评分，不只检查画面清晰度。
|
||||
7. 每个付费请求必须保留完整提交参数和实际 Provider。
|
||||
|
||||
## 3. 生产对象
|
||||
|
||||
| 对象 | 作用 |
|
||||
| --- | --- |
|
||||
| `Episode` | 分集目标、顺序、状态和质量信息 |
|
||||
| `EpisodeScript` | 已确认的单集剧本与版本 |
|
||||
| `StoryboardShot` | 镜头时长、动作、对白、运镜、声音、Prompt 和衔接 |
|
||||
| `Character` / `GlobalCharacter` | 项目角色与可复用演员资产 |
|
||||
| `CharacterState` | 角色在特定时间点的服装、伤势、情绪等状态 |
|
||||
| `ProjectVisualAsset` | 场景、道具及其主版本 |
|
||||
| `ShotImage` | 首帧、尾帧、关键帧和候选图 |
|
||||
| `VideoClip` | 单镜视频候选、实际模型、QC 和选择状态 |
|
||||
| `Asset` | 图片、视频、音频、字幕和成品的统一素材记录 |
|
||||
| `RenderTask` | 异步任务、重试、成本和人工介入 |
|
||||
|
||||
## 4. 标准流程
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
Source[连续原文快照] --> Analysis[原著分析合同]
|
||||
Analysis --> Bible[改编圣经合同]
|
||||
Bible --> Episode[分集计划合同]
|
||||
Episode --> Continuity[三集连续性检查]
|
||||
Continuity --> Release[人工放行一集]
|
||||
Release --> Script[单集剧本]
|
||||
Script --> Shot[动态分镜]
|
||||
Shot --> AssetPlan[角色/场景/道具资产计划]
|
||||
AssetPlan --> Prompt[镜头 Prompt]
|
||||
Prompt --> Frame[关键帧/参考图]
|
||||
Frame --> Video[视频候选]
|
||||
Video --> QC[自动 QC]
|
||||
QC --> Select[重试/回退/人工选择]
|
||||
Select --> Compose[字幕/声音/BGM/SFX/转场]
|
||||
Compose --> Render[FFmpeg 成片]
|
||||
Render --> Review[审核与作品库]
|
||||
```
|
||||
|
||||
`splus_v1` 新项目使用上述结构化写路径。旧项目的 StoryBible、Episode 和历史 Prompt 保持原样，不自动迁移；旧写接口不能向新项目写入。原著分析、改编圣经和分集计划均追加新版本，并保存来源、质量问题和人工确认记录。
|
||||
|
||||
## 5. 剧本到分镜
|
||||
|
||||
### 5.1 剧本审核
|
||||
|
||||
每集应对照来源文本和上下集，检查：
|
||||
|
||||
- 核心事实、动机和因果是否保留。
|
||||
- 是否为压时长而删掉必要台词或反应。
|
||||
- 对白是否像角色在表演，而不是信息段落拼接。
|
||||
- 心理旁白、悬疑信息和听觉线索是否服务情绪。
|
||||
- 本集钩子、高潮和尾点是否成立。
|
||||
|
||||
### 5.2 动态时长
|
||||
|
||||
时长估算至少包含：
|
||||
|
||||
```text
|
||||
对白朗读时间
|
||||
+ 动作完成时间
|
||||
+ 反应/停顿时间
|
||||
+ 运镜落点时间
|
||||
+ 前后镜衔接余量
|
||||
```
|
||||
|
||||
模型支持的单次最大时长不是目标时长。台词无法完整说完时，优先延长或按完整戏剧节拍拆镜，禁止靠加速到听不清来硬塞。
|
||||
|
||||
### 5.3 分镜字段
|
||||
|
||||
单镜至少应明确：
|
||||
|
||||
- 当前镜头的戏剧目标。
|
||||
- 角色站位、视线、入画和离画方向。
|
||||
- 按时间段划分的动作与表演。
|
||||
- 逐句台词、说话者、语气和开始时机。
|
||||
- 景别、机位、镜头运动和最终落点。
|
||||
- 环境声、对白、系统声、SFX 和 BGM 节奏。
|
||||
- 与上一镜的接入动作、声音桥或视觉桥。
|
||||
- 与下一镜的尾帧、视线、运动方向或声音预埋。
|
||||
- 禁止项和资产版本。
|
||||
|
||||
## 6. 资产一致性
|
||||
|
||||
### 6.1 角色
|
||||
|
||||
- 先确定全局角色和当前项目外观版本。
|
||||
- 服装、发型、年龄、伤势和持有物由 `CharacterState` 固定。
|
||||
- 三视图用于角色母版，不代表每个镜头都应直接上传整张三视图。
|
||||
- 同场多人应明确各自参考图和身份，避免参考关系错配。
|
||||
|
||||
### 6.2 场景
|
||||
|
||||
- 场景主资产应至少覆盖关键方向、空间结构和标志物。
|
||||
- 同一连续场景不得仅靠文字重复描述来维持一致性。
|
||||
- 对联、牌匾、二维码、屏幕等精确文字内容应由后期层处理，模型画面保留合理空间和时长。
|
||||
|
||||
### 6.3 道具
|
||||
|
||||
- 剧情证据、武器、手机、银铃、文件等关键道具应有主资产或明确外观约束。
|
||||
- 道具在人物手中时要描述持握手、方向、前后位置和动作路径。
|
||||
|
||||
## 7. 图像输入模式
|
||||
|
||||
| 模式 | 适用情况 | 主要风险 |
|
||||
| --- | --- | --- |
|
||||
| 纯文本 | 无既有资产、探索性镜头 | 角色和空间漂移最大 |
|
||||
| 单首帧 | 同一空间内连续表演、动作可自由发展 | 尾点不可控 |
|
||||
| 首尾帧 | 明确起止构图、动作落点或转场接力 | 首尾差异过大时中间形变 |
|
||||
| 多图参考 | 同时约束人物、场景、道具，或测试模型参考能力 | 参考权重错配、剧情控制有限 |
|
||||
|
||||
选择原则：使用能满足镜头目标的最少参考图。首尾帧需要处于同一时空、同一服装、可连续运动，不能拿两个独立海报硬桥接。
|
||||
|
||||
## 8. 视频生成
|
||||
|
||||
当前支持：
|
||||
|
||||
- 单镜和批量生成。
|
||||
- 单首帧、首尾帧和多图参考。
|
||||
- 多候选与人工选择。
|
||||
- Kling 原生音频、Seedance 等真实视频 Provider。
|
||||
- Provider preflight、成本估算和异步轮询。
|
||||
|
||||
请求记录应包含：
|
||||
|
||||
- 原始业务 Prompt 和最终提交 Prompt。
|
||||
- 参考图顺序、资产 ID、用途和临时 URL。
|
||||
- 请求时长、比例、分辨率、模型和 Provider 参数。
|
||||
- 是否要求原生音频、实际返回音轨。
|
||||
- Provider 任务 ID、状态、耗时、成本和失败原因。
|
||||
|
||||
特殊对照测试可以按用户要求“原样 Prompt + 指定图片”提交，此时不得自动注入公共润色词；系统应明确标记为 bypass/实验请求，避免污染正式模板结论。
|
||||
|
||||
### 8.1 当前统一画幅
|
||||
|
||||
- 新生产任务统一使用16:9横屏。
|
||||
- 1080P视频固定1920×1080，关键帧固定2560×1440，原生4K固定3840×2160。
|
||||
- 新的 Production Contract、Generation Plan、关键帧 Prompt、视频请求和 FFmpeg 合成都读取同一横屏常量。
|
||||
- 历史素材与已冻结计划不原地改写；旧镜头重新生成时创建新的16:9计划修订。
|
||||
|
||||
### 8.2 Kling 视频角色元素
|
||||
|
||||
视频角色元素负责回答“角色是谁、长什么样、使用什么声线”；分镜 Prompt 只负责场景、动作、表演、台词与运镜。
|
||||
|
||||
生产步骤：
|
||||
|
||||
1. 从已确认角色锚点生成3-8秒身份源视频，默认8秒、1080P、16:9。
|
||||
2. 人物正面起始，依次左转约30度、回正、右转约30度并回正；背景与灯光保持中性。
|
||||
3. 在 Kling 元素库人工创建视频角色元素；当前不宣称存在已验证的公开创建 API。
|
||||
4. 将真实 `element_id`、元素名称、源视频、声线和质检结果导入 `CharacterProviderBinding`。
|
||||
5. 质检分达到90后才能审批为正式主元素。
|
||||
6. Generation Plan 冻结角色到元素的映射；正式 Omni 请求提交真实 `element_list`。
|
||||
7. 新 S+ 镜头缺少任何出场角色的已审批元素时，在付费调用前阻断。
|
||||
|
||||
Prompt 内的 `<<<element_n>>>` 与 API `element_list[n]` 必须一一对应。网页端 `@名称` 只用于手工操作，不能冒充已绑定 API 元素。
|
||||
|
||||
## 9. 声音设计
|
||||
|
||||
声音层包括：
|
||||
|
||||
- 角色对白和心理旁白。
|
||||
- 机械系统音或非人物提示音。
|
||||
- 环境声、拟音和冲击音效。
|
||||
- BGM、高潮音乐和转场声音桥。
|
||||
- 模型原生音轨、后期 TTS 与补充音频。
|
||||
|
||||
系统音必须在 Prompt 中与角色声线分离，说明音色、节奏、响度和播放窗口；仍不稳定时由后期独立音轨替换。字幕仅展示实际说出的台词，不包含角色名、动作说明或生成残留符号。
|
||||
|
||||
## 10. 质量控制
|
||||
|
||||
自动 QC 至少覆盖：
|
||||
|
||||
- 角色身份、脸型、年龄和服装一致性。
|
||||
- 场景空间、道具和文字占位是否正确。
|
||||
- 动作是否按方向完成，是否出现穿模或多余人物。
|
||||
- 台词是否完整、中文是否清楚、声线是否串角色。
|
||||
- 嘴型、说话时机和字幕窗口是否协调。
|
||||
- 运镜是否服务表演，有无硬切、漂移或无意义运动。
|
||||
- 首尾是否能接前后镜。
|
||||
- 画质、闪烁、畸变、音量和可播放性。
|
||||
|
||||
自动评分用于筛选和重试，不直接等于发布通过。关键镜头和最终成片必须允许人工确认。
|
||||
|
||||
## 11. 合成与后期
|
||||
|
||||
当前 FFmpeg 链路支持：
|
||||
|
||||
- 分辨率、帧率、像素格式和音轨归一。
|
||||
- 硬切、淡入淡出、模糊、声音桥等转场。
|
||||
- 原生音轨、附加音频、BGM、SFX 和环境音混合。
|
||||
- ASS/字幕烧录。
|
||||
- UI 提示框、进度条和稳定中文信息层。
|
||||
- 无源音轨时的兜底声音。
|
||||
|
||||
正式合并流程应输出完整成片，而非只做裸拼接。每次合成需保存镜头顺序、裁剪范围、转场、字幕、UI 和混音参数，以便可重复生成。
|
||||
|
||||
## 12. 当前风险
|
||||
|
||||
1. 动态分镜、声音和后期策略变化后，部分测试仍使用旧期望。
|
||||
2. 真人关键帧和真人合并任务并未全部通过 Worker 执行。
|
||||
3. Scene Composer 和原创音乐默认关闭，项目间配置容易产生理解差异。
|
||||
4. LipSync 只有抽象，当前真实 Provider 未启用。
|
||||
5. Provider 临时参考图公网可达性尚未形成统一 preflight。
|
||||
6. 自动字幕、UI 时间点与台词结束边界仍需更多成片回归样本。
|
||||
|
||||
## 13. 不可破坏的规则
|
||||
|
||||
1. 不删改用户已确认的总剧本事实，分镜只能做可追踪改编。
|
||||
2. 不在用户要求原样测试时偷偷注入模板。
|
||||
3. 不用未确认的角色或服装锚点替换主资产。
|
||||
4. 不把模型生成的乱码文字当作正式 UI。
|
||||
5. 不在对白未结束时切镜。
|
||||
6. 不把多个候选误当成同一镜重复提交。
|
||||
7. 不在没有参数快照的情况下宣称某模型效果优劣。
|
||||
|
||||
## 14. 下一阶段
|
||||
|
||||
- 建立剧本/分镜逐镜 98+ 审核量表的机器可读版本。
|
||||
- 补齐视频合成、字幕和真人任务的 Worker 执行器。
|
||||
- 为每次视频调用展示实际路由、参考图和回退链。
|
||||
- 增加完整成片 E2E：镜头生成 -> 选择 -> 字幕/UI -> BGM/SFX -> 合并。
|
||||
- 将高质量人工评审结果沉淀为可版本化 Prompt 经验，而不是无边界自动追加。
|
||||
@@ -0,0 +1,222 @@
|
||||
# AI 流水线与 Provider 设计 V1
|
||||
|
||||
> 文档状态：当前有效
|
||||
> 基线日期：2026-07-15
|
||||
> 目的：说明当前 AI 请求如何选择、执行、记录、回退和进入业务资产。
|
||||
|
||||
## 1. 设计目标
|
||||
|
||||
- 业务不直接绑定单一厂商 SDK。
|
||||
- 每次调用可解释、可审计、可计费、可重试。
|
||||
- 同步和异步 Provider 使用统一日志与业务结果。
|
||||
- 用户指定的模型和参数不被静默替换。
|
||||
- Prompt 模板、实验请求和原样透传有明确边界。
|
||||
- AI 失败不会破坏已经确认的业务资产。
|
||||
|
||||
## 2. Provider 类型
|
||||
|
||||
当前目录覆盖：
|
||||
|
||||
- `TextProvider`
|
||||
- `NovelProvider`
|
||||
- `ImageProvider`
|
||||
- `VideoProvider`
|
||||
- `VoiceProvider`
|
||||
- `MusicProvider`
|
||||
- `EmbeddingProvider`
|
||||
- `ModerationProvider`
|
||||
- `LipSyncProvider`（抽象存在，真实配置当前关闭）
|
||||
|
||||
数据库当前有 112 个 Provider 配置，其中真实配置 101 个、启用 64 个；Mock 配置 11 个、启用 10 个。全局 `AI_PROVIDER_MODE` 当前仍为 `mock`，但业务显式选择真实 Provider 时会产生真实调用。
|
||||
|
||||
## 3. 调用选择
|
||||
|
||||
一次调用可能同时受到以下输入影响：
|
||||
|
||||
1. 用户明确选择的 `provider_code`。
|
||||
2. 项目级模型偏好。
|
||||
3. 用户级模型偏好。
|
||||
4. 业务模块默认 Provider。
|
||||
5. Provider 启停、优先级、能力和成本限制。
|
||||
6. AI Router 的业务评分与回退规则。
|
||||
|
||||
当前 AI Router 主要用于真人视频，不是全平台统一路由。后续必须固定一套明确优先级，并在调用详情展示：请求选择、路由原因、实际 Provider、实际模型和回退链。
|
||||
|
||||
## 4. 请求生命周期
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
Input[业务输入] --> Build[构建请求]
|
||||
Build --> Preflight[参数/能力/素材 URL/成本预检]
|
||||
Preflight --> Config[解析 ProviderConfig]
|
||||
Config --> Submit[同步执行或异步提交]
|
||||
Submit --> Log[ProviderLog]
|
||||
Log --> Poll[异步轮询/回调]
|
||||
Poll --> Normalize[结果归一]
|
||||
Normalize --> Asset[Asset / VideoClip / 文本版本]
|
||||
Normalize --> QC[质量评估]
|
||||
QC --> Pass{通过?}
|
||||
Pass -- 否 --> Retry[同模型重试/回退/人工介入]
|
||||
Pass -- 是 --> Done[业务确认]
|
||||
```
|
||||
|
||||
### 4.1 请求构建
|
||||
|
||||
请求快照至少保存：
|
||||
|
||||
- 业务类型和关联项目/分镜/角色。
|
||||
- 原始输入与最终 Prompt。
|
||||
- 公共模板版本和是否旁路模板。
|
||||
- 模型、比例、时长、分辨率、种子等参数。
|
||||
- 参考素材的资产 ID、顺序和用途。
|
||||
- 预估成本和用户确认条件。
|
||||
|
||||
### 4.2 Preflight
|
||||
|
||||
提交前检查：
|
||||
|
||||
- Provider 是否启用且类型匹配。
|
||||
- 参数是否在模型能力范围。
|
||||
- 参考图数量、格式、大小和顺序。
|
||||
- 外部 Provider 能否访问临时素材 URL。
|
||||
- 账户额度和项目成本上限。
|
||||
- 原生音频、首尾帧、多图参考等能力是否真实支持。
|
||||
- 实验请求是否要求禁止模板注入。
|
||||
- 新生产任务的画幅是否为唯一允许值16:9。
|
||||
- S+ Kling Omni 镜头的每个出场角色是否绑定质检分不低于90的已审批视频角色元素。
|
||||
- Omni 的图片、视频与元素组合是否满足数量和互斥限制；无参考视频时图片与元素合计不超过7。
|
||||
|
||||
### 4.3 结果归一
|
||||
|
||||
不同 Provider 的任务 ID、状态、URL、用量和错误格式必须转换为平台统一结构，再写入业务资产。临时 URL 不是最终资产，需下载到私有存储并保存来源信息。
|
||||
|
||||
## 5. Prompt 管理
|
||||
|
||||
Prompt 分为四层：
|
||||
|
||||
1. 业务事实：剧本、角色、场景、动作和台词。
|
||||
2. 公共质量模板：画质、一致性、可用性和负向约束。
|
||||
3. Provider 适配：模型特有参数与表达。
|
||||
4. 本次覆盖：用户人工修改或严格原样提交。
|
||||
|
||||
优先级为“本次明确覆盖 > 已确认业务事实 > 公共模板 > Provider 默认”。公共模板不得改变台词、人物、镜头时长或参考图集合。
|
||||
|
||||
人物三视图已具备“主锚点参考”和“本次唯一角色描述覆盖”两种模式，并将视觉质检问题沉淀为后续优化经验。经验只能以版本化、可审阅方式进入公共模板，避免单个角色的专用词污染全局。
|
||||
|
||||
Kling 正式镜头不再重复大段描述已锁定角色五官。平台从不可变 Generation Plan 读取 `CharacterProviderBinding` 快照，把真实 `element_id` 写入 `element_list`，再在 Prompt 中使用与数组顺序一致的 `<<<element_n>>>` 标记。角色元素控制身份和绑定声线，镜头 Prompt 控制本次动作、表演、空间、台词与摄影。
|
||||
|
||||
S+ 结构化写路径新增阶段 Prompt Builder。Source Analyst、Adaptation Showrunner、Episode Planner 的公共模板与项目数据分离，运行时只注入不可变来源快照、已确认父合同和上一集状态。Writer 输出完整合同；Reviewer 只输出问题与结构化修复差异，不静默重写正文。用户可以在调用 Provider 前预览最终阶段 Prompt；Phase 2 默认不提供一键付费生成入口。
|
||||
|
||||
## 6. 任务与队列
|
||||
|
||||
### 6.1 队列
|
||||
|
||||
```text
|
||||
novel_queue / parse_queue / story_queue / character_queue
|
||||
episode_queue / script_queue / storyboard_queue / image_queue
|
||||
audio_queue / subtitle_queue / video_queue / qc_queue
|
||||
review_queue / analytics_queue
|
||||
```
|
||||
|
||||
### 6.2 平台任务状态
|
||||
|
||||
```text
|
||||
pending / running / success / failed / retrying
|
||||
cancelled / manual_required / skipped
|
||||
```
|
||||
|
||||
数据库中仍有历史 `completed`，需要迁移或兼容，不应继续产生新值。
|
||||
|
||||
### 6.3 执行模式
|
||||
|
||||
Worker 消费 BullMQ 后，通过受密钥保护的内部 API 委托 backend 执行。这样可复用业务逻辑，但也意味着 backend 必须能承受 Worker 回调并保持幂等。
|
||||
|
||||
### 6.4 已知覆盖缺口
|
||||
|
||||
以下任务在通用 Worker 映射中没有 Provider 执行器，可能被标记为 `skipped`：
|
||||
|
||||
- `long_memory_generate`
|
||||
- `subtitle_generate`
|
||||
- `live_action_keyframe_generate`
|
||||
- `live_action_video_render`
|
||||
- `analytics_event`
|
||||
|
||||
部分能力目前由同步 Service 完成，因此应选择：补齐 Worker 执行器，或从异步任务目录移除并明确同步语义。`video_render` 当前映射到 VideoProvider，与 FFmpeg 成片合成的命名也需要拆分。
|
||||
|
||||
## 7. 重试与回退
|
||||
|
||||
重试策略按错误性质区分：
|
||||
|
||||
| 错误 | 处理 |
|
||||
| --- | --- |
|
||||
| 参数/素材不可用 | 不盲目重试，返回可修复原因 |
|
||||
| 限流/临时网络故障 | 指数退避重试 |
|
||||
| 异步任务超时 | 先核对外部任务，避免重复扣费 |
|
||||
| 质量不达标 | 同模型定向重试，必要时回退其他模型 |
|
||||
| 多次失败 | `manual_required`，保留全部候选和日志 |
|
||||
|
||||
回退不可静默发生。UI 应展示实际使用模型和回退原因。
|
||||
|
||||
## 8. 成本与额度
|
||||
|
||||
- `ProviderConfig` 保存成本规则和能力配置。
|
||||
- `ProviderLog` 保存本次调用的估算/实际成本、耗时和状态。
|
||||
- `QuotaAccount`、`QuotaLog` 支持冻结、释放和扣减。
|
||||
- 数据库历史 `cost_actual` 可能混有不同币种/规则，只能技术对账，不能直接作为财务总额。
|
||||
- 真实支付仍为 mock，不能把订单模型描述成生产支付闭环。
|
||||
|
||||
提交付费任务建议采用：
|
||||
|
||||
```text
|
||||
预估 -> 冻结额度 -> 执行 -> 按实际结算 -> 释放差额
|
||||
```
|
||||
|
||||
异步任务重试必须复用或核验外部任务 ID，避免重复扣费。
|
||||
|
||||
## 9. 日志与审计
|
||||
|
||||
每次 AI 调用应能回答：
|
||||
|
||||
- 谁、在哪个项目、为了哪个业务对象调用？
|
||||
- 用户请求了什么 Provider/模型？
|
||||
- 系统为何选择实际 Provider/模型？
|
||||
- 最终提交了什么参数和参考素材？
|
||||
- 是否注入模板、是否回退、重试了几次？
|
||||
- 外部任务 ID、耗时、状态和错误是什么？
|
||||
- 产生了哪些资产，哪一个被选择？
|
||||
- 估算成本、实际成本和额度变化是什么？
|
||||
|
||||
API Key、JWT、数据库密码和临时签名参数不能进入可下载日志或 Work 文档。
|
||||
|
||||
## 10. 新 Provider 接入清单
|
||||
|
||||
1. 明确能力类型、模型和区域。
|
||||
2. 定义请求 DTO、参数范围和默认值。
|
||||
3. 实现鉴权、提交、轮询/回调、取消和结果归一。
|
||||
4. 处理文本、二进制和临时 URL 输入。
|
||||
5. 定义成本规则和币种。
|
||||
6. 增加 preflight 与错误分类。
|
||||
7. 增加 mock、单元测试和至少一次真实小额冒烟。
|
||||
8. 在 Provider Lab 验证参数透传。
|
||||
9. 验证日志不泄露密钥。
|
||||
10. 更新本文件、CHANGELOG 和项目状态文档。
|
||||
|
||||
## 11. 当前优先级
|
||||
|
||||
### P0
|
||||
|
||||
- 修复 Provider/Seedance 相关测试与真实策略不一致。
|
||||
- 对齐运行进程与最新构建。
|
||||
|
||||
### P1
|
||||
|
||||
- 固化模型选择优先级和路由解释。
|
||||
- 补齐素材 URL preflight。
|
||||
- 清理历史 running/failed 日志和任务积压。
|
||||
- 补齐队列执行映射与任务命名。
|
||||
|
||||
### P2
|
||||
|
||||
- 将 AI Router 扩展为可选的平台统一入口。
|
||||
- 建立 Provider 契约测试和录制回放测试。
|
||||
- 统一成本币种和财务口径。
|
||||
@@ -0,0 +1,260 @@
|
||||
# 数据库现状与维护规范 V1
|
||||
|
||||
> 文档状态：当前有效
|
||||
> 基线日期：2026-07-15
|
||||
> 唯一结构真相：`backend/prisma/schema.prisma` 与 `backend/prisma/migrations/`。
|
||||
|
||||
## 1. 当前事实
|
||||
|
||||
- 数据库：MySQL。
|
||||
- ORM：Prisma 6。
|
||||
- Model：69 个。
|
||||
- Prisma Enum：0 个。
|
||||
- 已部署迁移：40 个。
|
||||
- 迁移状态：审计时全部已部署。
|
||||
- 状态字段主要是字符串，存在历史值漂移风险。
|
||||
|
||||
本文只解释领域结构和维护规则，不复制所有字段。字段、索引、默认值和约束以 Prisma schema 为准。
|
||||
|
||||
## 2. 领域分组
|
||||
|
||||
### 2.1 用户、项目与偏好
|
||||
|
||||
- `User`
|
||||
- `UserModelPreference`
|
||||
- `Project`
|
||||
- `ProjectPipelineConfig`
|
||||
- `ProjectCreativePattern`
|
||||
- `CreativePattern`
|
||||
|
||||
### 2.2 小说与 Agent
|
||||
|
||||
- `NovelSource`
|
||||
- `NovelChapter`
|
||||
- `NovelReadingProgress`
|
||||
- `NovelBookmark`
|
||||
- `NovelAnnotation`
|
||||
- `NovelGenerationPlan`
|
||||
- `NovelChapterVersion`
|
||||
- `NovelContextMemory`
|
||||
- `NovelQualityReport`
|
||||
- `NovelVersionSnapshot`
|
||||
- `NovelDerivativeJob`
|
||||
- `AgentPrompt`
|
||||
- `AgentRun`
|
||||
|
||||
### 2.3 故事、世界观与版权
|
||||
|
||||
- `CopyrightRecord`
|
||||
- `StoryBible`
|
||||
- `WorldBible`
|
||||
|
||||
### 2.4 角色与 IP 资产
|
||||
|
||||
- `Character`
|
||||
- `StoryCharacter`
|
||||
- `CharacterExtractionVersion`
|
||||
- `GlobalCharacter`
|
||||
- `GlobalCharacterAsset`
|
||||
- `CharacterProviderBinding`
|
||||
- `GlobalCharacterLookVersion`
|
||||
- `CharacterImage`
|
||||
- `CharacterImageQualityReview`
|
||||
- `CharacterMemory`
|
||||
- `CharacterDesignVersion`
|
||||
- `CharacterPromptVersion`
|
||||
- `CharacterPromptReview`
|
||||
- `CharacterPromptOptimizationLesson`
|
||||
- `CharacterState`
|
||||
- `ActorProfile`
|
||||
- `ProjectVisualAsset`
|
||||
|
||||
### 2.5 剧集与媒体生产
|
||||
|
||||
- `Episode`
|
||||
- `EpisodeScript`
|
||||
- `StoryboardShot`
|
||||
- `ShotGenerationPlan`
|
||||
- `ShotImage`
|
||||
- `VideoClip`
|
||||
- `PlotMemory`
|
||||
- `PlotThread`
|
||||
- `ContinuityCheck`
|
||||
|
||||
### 2.6 素材、任务与 Provider
|
||||
|
||||
- `Asset`
|
||||
- `RenderTask`
|
||||
- `ProviderConfig`
|
||||
- `ModelCapabilityVersion`
|
||||
- `ModelParameterSchemaVersion`
|
||||
- `ModelPricingVersion`
|
||||
- `ProviderLog`
|
||||
|
||||
### 2.7 计费、审核与运营
|
||||
|
||||
- `Order`
|
||||
- `QuotaAccount`
|
||||
- `QuotaLog`
|
||||
- `RevisionRequest`
|
||||
- `ContentReview`
|
||||
- `CaseShowcase`
|
||||
- `HitAnalysisCase`
|
||||
- `HitAnalysisSegment`
|
||||
- `AnalyticsEvent`
|
||||
- `SystemConfig`
|
||||
- `OperationLog`
|
||||
|
||||
### 2.8 S+ 生产合同
|
||||
|
||||
- `ProductionSourceSnapshot`
|
||||
- `ProductionContract`
|
||||
- `ProductionContractReview`
|
||||
|
||||
`Project.engine_version` 隔离历史写路径与 `splus_v1` 新内核；`Project.production_lifecycle` 记录当前生产阶段。数据库默认值保持 `legacy_v1 / legacy_snapshot`，避免迁移把历史项目误标为新项目；应用层只为普通新项目明确写入 `splus_v1`。
|
||||
|
||||
## 3. 关键关系
|
||||
|
||||
```text
|
||||
User
|
||||
└── Project
|
||||
├── NovelSource -> NovelChapter -> ChapterVersion/Quality/Memory
|
||||
├── StoryBible / WorldBible
|
||||
├── Character / ProjectVisualAsset
|
||||
├── Episode -> EpisodeScript -> StoryboardShot
|
||||
│ ├── ShotGenerationPlan
|
||||
│ ├── ShotImage
|
||||
│ └── VideoClip
|
||||
├── Asset
|
||||
├── RenderTask
|
||||
└── ProductionSourceSnapshot
|
||||
└── ProductionContract -> ProductionContractReview
|
||||
|
||||
ProviderConfig -> ModelCapabilityVersion/ModelParameterSchemaVersion/ModelPricingVersion
|
||||
ShotGenerationPlan -> 三类不可变模型注册表版本 -> ShotImage/VideoClip/RenderTask
|
||||
ProviderConfig -> ProviderLog -> Asset/业务对象
|
||||
GlobalCharacter -> LookVersion/Asset/CharacterProviderBinding -> Project Character/ActorProfile
|
||||
```
|
||||
|
||||
全局角色与项目角色不是同一层：全局角色用于复用演员母版，项目角色承载本项目身份、服装、状态和授权范围。
|
||||
|
||||
生产合同按类型、范围和版本追加写入；已确认版本不原地覆盖。来源快照保存正文与哈希，合同保存父版本、输入哈希、来源引用、质量结果和下游放行状态。
|
||||
|
||||
`ProviderConfig` 是允许运营调整的工作配置，不作为历史执行凭证。每次 S+ 镜头冻结前，系统按规范化内容哈希发布或复用三类不可变注册表版本，并把版本 ID 和内容快照写入 `ShotGenerationPlan`。能力、参数 Schema 或价格发生变化时创建下一修订，不更新旧修订。
|
||||
|
||||
`CharacterProviderBinding` 保存平台角色与供应商长期角色资产之间的真实绑定。当前字段覆盖供应商与元素 ID、元素类型、源视频、外观版本、声线、质检分、审批状态、主版本和绑定修订。正式生成只读取 `approved` 绑定；镜头冻结后，所用元素 ID 会复制进入 `ShotGenerationPlan.element_plan_json`，后续修改角色主元素不会污染旧计划。
|
||||
|
||||
## 4. 数据快照
|
||||
|
||||
审计时主要数据量：
|
||||
|
||||
| 数据 | 数量 |
|
||||
| --- | ---: |
|
||||
| 用户 | 2 |
|
||||
| 项目 | 20 |
|
||||
| 小说源 | 10 |
|
||||
| 小说章节 | 256 |
|
||||
| 故事圣经 | 13 |
|
||||
| 项目角色 | 87 |
|
||||
| 全局角色 | 14 |
|
||||
| 分集 | 87 |
|
||||
| 单集剧本 | 21 |
|
||||
| 分镜 | 114 |
|
||||
| 素材 | 977 |
|
||||
| 任务 | 748 |
|
||||
| Provider 配置 | 114 |
|
||||
| Provider 调用日志 | 1002 |
|
||||
| 模型能力版本 | 156 |
|
||||
| 参数 Schema 版本 | 156 |
|
||||
| 价格版本 | 114 |
|
||||
| 角色供应商绑定 | 0 |
|
||||
| 内容审核记录 | 0 |
|
||||
| 操作审计记录 | 44 |
|
||||
|
||||
该表是 2026-07-15 快照，不应作为实时运营数据使用。实时数量应从数据库只读查询或管理后台获得。
|
||||
|
||||
## 5. 状态治理
|
||||
|
||||
当前 Prisma 没有数据库 Enum，状态由字符串常量和业务代码约束。已发现 `RenderTask` 中存在历史 `completed`，而当前代码使用 `success`。
|
||||
|
||||
后续要求：
|
||||
|
||||
1. 每个业务域建立唯一状态字典。
|
||||
2. API 入参、Service、前端展示和 Worker 共用同一组状态语义。
|
||||
3. 删除状态前先提供兼容读取和数据迁移。
|
||||
4. 未知历史状态必须显示为“需迁移”，不能静默当成功或失败。
|
||||
5. 新状态需更新数据库文档、API 契约和测试。
|
||||
|
||||
## 6. JSON 字段规则
|
||||
|
||||
JSON 适合保存：
|
||||
|
||||
- Provider 原始参数和归一结果。
|
||||
- Prompt、质量报告和调用快照。
|
||||
- 非核心扩展元数据。
|
||||
|
||||
以下信息不应只存在 JSON：
|
||||
|
||||
- 需要频繁筛选、排序或唯一约束的核心字段。
|
||||
- 业务主状态。
|
||||
- 资产、角色、分镜和 Provider 的主外键。
|
||||
- 财务扣减所需的金额和流水关系。
|
||||
|
||||
JSON 结构发生兼容性变化时，应写入 `schema_version` 或提供读时迁移。
|
||||
|
||||
## 7. 迁移流程
|
||||
|
||||
每次 schema 变更必须遵循：
|
||||
|
||||
1. 说明业务目的、影响表和回滚策略。
|
||||
2. 在备份或可恢复环境验证数据量和锁表风险。
|
||||
3. 修改 `schema.prisma` 并生成命名清晰的迁移。
|
||||
4. 审阅 SQL，禁止无意删除列、索引或生产数据。
|
||||
5. 更新受影响的 DTO、Service、测试和前端类型。
|
||||
6. 运行 Prisma 校验、构建和相关测试。
|
||||
7. 先部署兼容代码，再执行破坏性清理。
|
||||
8. 更新 `CHANGELOG.md`、本文件和状态文档。
|
||||
|
||||
禁止手工改生产表后不补迁移。
|
||||
|
||||
## 8. 备份与恢复
|
||||
|
||||
当前数据库和素材都在单机，备份应成对管理：
|
||||
|
||||
- MySQL 逻辑备份或一致性快照。
|
||||
- `storage/private` 增量备份。
|
||||
- schema、迁移和部署版本标识。
|
||||
- 备份校验和、保留期和异地副本。
|
||||
|
||||
恢复演练必须验证：
|
||||
|
||||
1. 数据库可恢复并通过迁移检查。
|
||||
2. `Asset.storage_key` 对应文件存在。
|
||||
3. 视频可 Range 播放，图片和音频可下载。
|
||||
4. RenderTask、ProviderLog 和业务资产关系没有断链。
|
||||
5. 用户权限和密钥配置不从文档包恢复。
|
||||
|
||||
## 9. 隐私与敏感信息
|
||||
|
||||
- Work 只上传模型名称、表名、字段职责和聚合统计。
|
||||
- 不上传用户邮箱、手机号、JWT、API Key、密码哈希或私有素材 URL。
|
||||
- Provider 原始响应进入日志前需屏蔽鉴权头和签名参数。
|
||||
- 删除用户或项目时，必须明确数据库记录、素材对象和外部任务的处理策略。
|
||||
|
||||
## 10. 当前问题
|
||||
|
||||
1. 状态字段自由字符串较多。
|
||||
2. `completed` 等历史状态未迁移。
|
||||
3. 本地素材和数据库缺少已验证的成套恢复流程。
|
||||
4. `ContentReview` 为 0 条，需要确认正式审核是否绕过该模型。
|
||||
5. 成本字段存在历史币种/口径差异。
|
||||
6. 69 个 Model 尚无自动生成的数据字典和关系图。
|
||||
|
||||
## 11. 下一阶段
|
||||
|
||||
- 建立状态字典和历史状态迁移。
|
||||
- 增加数据库与素材每日备份脚本及恢复演练记录。
|
||||
- 增加注册表待发布差异预览、管理员确认和回滚到旧修订的操作审计。
|
||||
- 从 Prisma 自动生成不含敏感值的数据字典。
|
||||
- 为核心关系增加删除策略和孤儿资产检查。
|
||||
- 统一 Provider 成本币种、精度和财务流水口径。
|
||||
@@ -0,0 +1,364 @@
|
||||
# Work 同步变更记录
|
||||
|
||||
本文件只追加已实现、已验证或明确改变状态的事项。未来设想写入 `FEATURE_*.md`，不要混入变更记录。
|
||||
|
||||
## [WORK_SYNC_2026-07-19_V11] - 2026-07-19
|
||||
|
||||
### 新增
|
||||
|
||||
- 新增 `S_PLUS_PRODUCTION_FLOW_AUDIT_V1.md`，按当前代码、数据库和项目 #22 审计从原著到成片的真实流程风险。
|
||||
- 新增 `S_PLUS_BATCH_AUTOMATED_PRODUCTION_PIPELINE_V2.md`，作为新建 S+ 项目的唯一目标生产流程。
|
||||
- 目标流程统一为真人剧组逻辑：开发、前期、生产、后期，对用户呈现十步制作流程。
|
||||
- 明确短篇完整故事、长篇连载小说和现成分集剧本三种入口，不再强迫所有内容走同一编剧顺序。
|
||||
- 明确制作拆解、资产与导演双轨、场景地理、风险分级、G0-G7 质量门、任务 DAG、预算和局部失效策略。
|
||||
|
||||
### 决策
|
||||
|
||||
- 批量生产采用异常驱动人工介入；低风险镜头可自动通过，高风险镜头必须人工批准。
|
||||
- Generation Plan 拆分为可修订 Intent Plan 和关键帧批准后冻结的不可变 Execution Plan。
|
||||
- 视频生成只创建候选；未通过 QC、未批准或被拒绝的素材不得进入活动指针、合并或发布。
|
||||
- 项目 #22 保留为回归样本，不再作为新流程结构的母版。
|
||||
|
||||
### 状态说明
|
||||
|
||||
- 本批次只完成流程审计和目标规范，没有修改数据库、生产服务或付费 Provider 调用。
|
||||
- V2 流程标记为目标规范，代码需按 P0-P5 分阶段实现和验收。
|
||||
|
||||
## [WORK_SYNC_2026-07-16_V2] - 2026-07-16
|
||||
|
||||
### 新增
|
||||
|
||||
- 新增确认资产计划到 `Episode` / `EpisodeScript` / `StoryboardShot` 的 S+ 执行桥接。
|
||||
- 支持在外部生成角色三视图的情况下，先落地导演分镜草案。
|
||||
- 新增外部资产占位状态 `external_assets_pending`。
|
||||
|
||||
### 保护
|
||||
|
||||
- 草案只能引用资产计划内的 `REQ_*` 逻辑编号。
|
||||
- 素材未导入前不编译 Provider Prompt，不冻结 Generation Plan，不触发付费生成。
|
||||
- 已有确认分镜或冻结计划后禁止覆盖。
|
||||
|
||||
### 验证
|
||||
|
||||
- 项目 #22 已落地第1集 9 镜，总时长 60 秒，全部等待外部资产。
|
||||
- Production Kernel 定向测试 24/24 通过。
|
||||
- Backend 与 User App 生产构建通过，后端健康检查通过。
|
||||
- 未调用付费 AI Provider。
|
||||
|
||||
## [WORK_SYNC_2026-07-15_V1] - 2026-07-15
|
||||
|
||||
### 新增
|
||||
|
||||
- 建立 AI 内容生产平台首个 Work 同步包。
|
||||
- 生成项目真实状态快照 `PROJECT_STATUS_V1.md`。
|
||||
- 生成当前架构、小说引擎、短剧引擎、AI 流水线和数据库文档。
|
||||
- 纳入 AI 视频生产经验快照。
|
||||
- 建立同步协议、文档模板、历史设计隔离说明和文件校验清单。
|
||||
|
||||
### 当前确认
|
||||
|
||||
- 全仓生产构建通过。
|
||||
- Prisma 33 个迁移全部已部署。
|
||||
- backend、worker、MySQL、Redis、Nginx 正在运行。
|
||||
- 后端测试 273 条中 238 通过、35 失败。
|
||||
- 当前运行进程尚未加载审计期间的最新构建。
|
||||
- Git 只有初始提交，当前现实代码尚未形成可靠版本基线。
|
||||
|
||||
### 风险
|
||||
|
||||
- 数据库和本地私有素材缺少已验证恢复流程。
|
||||
- 队列任务目录与实际 Worker 执行覆盖不一致。
|
||||
- Provider 路由、状态字符串和成本口径需要统一。
|
||||
- 用户端、管理端和若干 Service 文件过大。
|
||||
|
||||
## [WORK_SYNC_2026-07-15_V2] - 2026-07-15
|
||||
|
||||
### 新增
|
||||
|
||||
- 部署 S+ Phase 2“原著分析 -> 改编圣经 -> 分集计划”结构化写路径。
|
||||
- 新增不可变来源快照、版本化生产合同和 Reviewer 记录。
|
||||
- 新增三个阶段 Prompt、确定性硬门、三集连续性检查和人工单集放行。
|
||||
- 用户端新增 S+ 生产工作台；付费阶段生成入口暂不开放。
|
||||
|
||||
### 变更
|
||||
|
||||
- 普通新项目默认使用 `splus_v1`；原有 20 个项目全部保留为 `legacy_v1`。
|
||||
- 新项目不再使用旧 StoryBible/旧 Episode 写入口；后端同步增加隔离守卫。
|
||||
- 单次原著分析限制为最多 20 个连续章节、180,000 字。
|
||||
|
||||
### 数据库
|
||||
|
||||
- 迁移：`20260715143000_splus_production_contracts_v1`。
|
||||
- Prisma Model 从 61 个增加到 64 个，迁移从 33 个增加到 34 个。
|
||||
- 新表当前为空，没有自动迁移或改写历史内容。
|
||||
|
||||
### 验证
|
||||
|
||||
- Phase 2 定向测试：13/13 通过。
|
||||
- 后端生产构建：通过。
|
||||
- 用户端生产构建：通过。
|
||||
- Prisma schema 校验与迁移：通过。
|
||||
- 后端健康检查：`ok`。
|
||||
- 全量后端测试：254 通过、34 失败；失败数未扩大。
|
||||
|
||||
### 风险/回滚
|
||||
|
||||
- 工程链路已部署，真实新项目连续三集内容验收尚未执行。
|
||||
- 进入 Phase 3 前必须只放行一个通过三集连续性检查的分集计划。
|
||||
- Phase 0 数据库与私有素材备份继续作为本次回滚基线。
|
||||
|
||||
## [WORK_SYNC_2026-07-15_V3] - 2026-07-15
|
||||
|
||||
### 新增
|
||||
|
||||
- 新增镜头级不可变 `ShotGenerationPlan`，以内容哈希和修订号保存 S+ 执行计划。
|
||||
- 新增生成计划冻结、查询、快照与定向规则测试。
|
||||
- 关键帧、参考资产、角色元素、逐角色音色、视频请求、QC、重试、回退和成本审计共同读取同一计划。
|
||||
|
||||
### 变更
|
||||
|
||||
- S+ 视频队列不能被普通请求静默覆盖 Provider；系统修复仅可使用冻结回退链。
|
||||
- 镜头、关键帧、视频片段和渲染任务增加生成计划追踪 ID。
|
||||
- 旧 `legacy_v1` 项目不强制迁移或回填计划。
|
||||
|
||||
### 数据库
|
||||
|
||||
- 迁移：`20260715223000_shot_generation_plan_v1`。
|
||||
- 新增 `shot_generation_plans`；当前 Prisma 迁移共 38 个并已全部部署。
|
||||
|
||||
### 验证
|
||||
|
||||
- Generation Plan 与 AI Router 定向测试：9/9 通过。
|
||||
- Backend、User App、Admin、Workers 生产构建：通过。
|
||||
- 全量后端测试：265 通过、34 失败；本阶段新增测试全部通过。
|
||||
- 未触发真实付费 AI 生成。
|
||||
|
||||
### 风险/后续
|
||||
|
||||
- 前端尚未提供生成计划修订差异界面。
|
||||
- 模型能力、参数 Schema 和价格仍需升级为版本化注册表。
|
||||
- 需要用一个全新 S+ 项目执行单镜头真实验收。
|
||||
|
||||
## [WORK_SYNC_2026-07-15_V4] - 2026-07-15
|
||||
|
||||
### 新增
|
||||
|
||||
- 新增不可变 `ModelCapabilityVersion`、`ModelParameterSchemaVersion` 和 `ModelPricingVersion`。
|
||||
- 当前 114 个 Provider 已初始化三类首版注册表，各 114 条。
|
||||
- 新增模型注册表查询、按当前 Provider 配置发布或复用修订的管理接口。
|
||||
- 新增同一镜头两个 Generation Plan 修订的字段级比较接口。
|
||||
- 用户端真人短剧制作台新增活动计划、历史修订、成本和分类差异视图。
|
||||
|
||||
### 变更
|
||||
|
||||
- `ShotGenerationPlan` 绑定能力、参数 Schema 和价格三个不可变版本 ID，并继续保存完整快照。
|
||||
- S+ 计划冻结前按绑定 Schema 校验最终 Provider 请求；参数冲突会在付费调用前阻断。
|
||||
- `ProviderConfig` 明确为可编辑工作区，不再被当作历史执行凭证。
|
||||
|
||||
### 数据库
|
||||
|
||||
- 迁移：`20260715233000_model_registry_versions_v1`。
|
||||
- Prisma Model 从 64 个增加到 68 个，迁移共 39 个并已全部部署。
|
||||
|
||||
### 验证
|
||||
|
||||
- Backend、User App、Admin、Workers 生产构建：通过。
|
||||
- 模型注册表与计划修订定向测试：6/6 通过。
|
||||
- 全量后端测试：269 通过、34 失败；失败数与上一基线一致。
|
||||
- Backend 与 Worker 受控重启后均为 `active`，后端健康检查返回 `ok`。
|
||||
- 未触发真实付费 AI 生成。
|
||||
|
||||
### 风险/后续
|
||||
|
||||
- 仍需用一个全新 S+ 单镜头核对计划、ProviderLog、QC 和真实账单。
|
||||
- 注册表待发布差异、管理员确认和回滚审计尚未进入后台。
|
||||
- 角色主资产到 Kling `element_id` 的供应商绑定和正式校验仍待完成。
|
||||
|
||||
## [WORK_SYNC_2026-07-15_V5] - 2026-07-15
|
||||
|
||||
### 新增
|
||||
|
||||
- 新增 `CharacterProviderBinding`，保存全局角色到 Kling 视频角色元素、多图元素和绑定声线的真实供应商映射。
|
||||
- 新增8秒、1080P、16:9角色元素源视频入口，以及元素 ID 导入、90分质检审批和主版本管理页面。
|
||||
- Generation Plan 冻结元素绑定；Kling Omni 正式请求同时提交真实 `element_list` 和顺序一致的 `<<<element_n>>>` Prompt 引用。
|
||||
- S+ Kling Omni 镜头新增角色元素硬门，任一出场角色缺少已审批元素即在付费调用前阻断。
|
||||
|
||||
### 变更
|
||||
|
||||
- 新生产画幅统一为16:9；视频1920×1080、关键帧2560×1440、原生4K 3840×2160。
|
||||
- 42个图片/视频 Provider 的 `production_aspect_ratio` 和允许画幅统一为16:9。
|
||||
- Omni 无参考视频时按图片与元素合计最多7个动态分配图片输入，不再固定浪费参考位。
|
||||
- 历史项目、素材和已冻结计划不原地改写；重新生成须冻结新的横屏修订。
|
||||
|
||||
### 数据库
|
||||
|
||||
- 迁移：`20260716003000_landscape_character_elements_v1`。
|
||||
- Prisma Model 由68个增加到69个，迁移由39个增加到40个并已部署。
|
||||
- 模型能力版本与参数 Schema 版本分别由114条增加到156条；价格未变化，仍为114条。
|
||||
|
||||
### 验证
|
||||
|
||||
- Prisma schema 校验与迁移：通过。
|
||||
- Backend、User App 生产构建：通过。
|
||||
- Generation Plan 与 Model Registry 定向测试：6/6通过。
|
||||
- Prompt Builder 定向测试：7/7通过。
|
||||
- 全量 Backend 测试：269通过、34失败，失败数未扩大。
|
||||
- Backend 与 Worker 已受控重启并保持 `active`，后端健康检查返回 `ok`。
|
||||
- 未触发真实付费生成；真实 Kling 元素创建、单镜头和账单对账待验收。
|
||||
|
||||
### 风险/后续
|
||||
|
||||
- Kling 官方公开资料目前只确认网页/App元素库创建流程；平台暂不实现未经验证的自动创建元素 API。
|
||||
- LiveAction 历史测试仍有19条失败，主要是旧 Prisma mock 与既有导演策略断言漂移，需要单独清债。
|
||||
- 当前角色供应商绑定表为0条，需要用首个真实元素完成端到端验收。
|
||||
|
||||
## [WORK_SYNC_2026-07-16_V6] - 2026-07-16
|
||||
|
||||
### 新增
|
||||
|
||||
- 使用全新 S+ 项目“诸葛亮与司马懿斗法”执行首批人物三视图真实 Provider 验收。
|
||||
- 图片生成支持显式 `reference_asset_ids`，任务能够审计本轮实际参考来源。
|
||||
- 新增 `reference_crop_mode=turnaround_face_panel`，可临时提取三视图左侧身份面板，不修改原始素材。
|
||||
- 新增跨视图身份漂移、错误视图几何和现代鞋履的确定性视觉硬门。
|
||||
|
||||
### 变更
|
||||
|
||||
- 公共人物三视图模板升级为 `character_turnaround_public_v3_s_plus`，身份母版默认空手并强化年龄、鞋履和视图一致性。
|
||||
- 三视图不再被错误自动晋升为角色主锚点，只有真实 `anchor` 类型图片可参与自动主锚点选择。
|
||||
- 98分且参考模式一致的可信 Prompt 可复用，避免每轮视觉经验变化都重复执行多轮昂贵审稿。
|
||||
- Prompt 审稿输入不再把独立负面约束作为待审正文，减少错误污染判定。
|
||||
|
||||
### 真实验收
|
||||
|
||||
- 共得到 #978、#979、#980、#981、#982、#983 六张候选；当前最佳为素材 #980，视觉分87。
|
||||
- 所有候选均未达到 S+，没有标记 approved，也没有晋升角色主锚点。
|
||||
- Seedream 5.0 整板递归、GPT Image 2 A/B 和身份面板裁切均未解决跨视图服装与鞋履拓扑漂移。
|
||||
- 停止继续单画布递归，下一阶段采用“身份、正面、严格侧面、背面分别生成与质检，再程序化合成”的路线。
|
||||
|
||||
### 成本
|
||||
|
||||
- ProviderLog #1010-#1038 合计 $3.1663。
|
||||
- TextProvider 审稿与视觉质检 $2.9753，ImageProvider $0.1910；文本相关成本约为图片成本的15.6倍。
|
||||
|
||||
### 验证
|
||||
|
||||
- ImagesService 定向测试：16/16通过。
|
||||
- Backend 生产构建：通过。
|
||||
- User App 生产构建：通过。
|
||||
|
||||
### 风险/后续
|
||||
|
||||
- 当前最高视觉分只有87，不能作为视频角色元素的 S+ 身份母版。
|
||||
- 分面板生成、逐面板状态持久化、跨面板拓扑检查和确定性合成尚未实现。
|
||||
- RenderTask 成功成本当前主要反映图片调用，完整生产成本仍应以 ProviderLog 汇总为准，后续需统一审计口径。
|
||||
|
||||
## [WORK_SYNC_2026-07-16_V7] - 2026-07-16
|
||||
|
||||
### 变更
|
||||
|
||||
- 公共人物三视图模板升级为 `character_turnaround_original_v4_s_plus`，以原创虚构数字角色和最高原生质量替代冲突的真人肖像限制与提示词式 8K 声明。
|
||||
- 三视图负面约束压缩为六组，并新增非人、多头、多臂角色结构分支。
|
||||
- 旧 V3 Prompt 即使已有 98 分也不能直接复用；活动 Prompt 必须同时满足当前版本、旗舰版式、参考模式和零冲突词。
|
||||
- 历史高分经验增加画幅、角色名、专属道具、物种、时代和服装适用性过滤；新 reusable rules 写库前使用同一硬门。
|
||||
- Asset Planner 身份母版示例改为原创虚构角色资产，历史候选不得污染新资产描述。
|
||||
- Project #22 的蜀军将领和九幽鬼将角色描述去除跨角色点名。
|
||||
- 网页复制包的通用角色负面模板移除五条压低脸部清晰度的冲突限制，并过滤旧角色描述的同类回流；明确隐藏脸的 Seedance 安全首帧分支保持隔离。
|
||||
- 人物三视图固定工业版式由泛化“横版”收紧为显式 16:9 横版单一连续画布。
|
||||
- 主锚点、表情锚点、服装锚点、三视图及平台复制文案统一移除提示词式 8K 声明；旧角色 Prompt 提交前自动改写为最高原生质量与后续 4K 放大准备。
|
||||
|
||||
### 验证
|
||||
|
||||
- 三视图、CharactersService、ImagesService、Production Kernel、资产计划 Prompt 与旧行为保护定向测试：60/60 通过。
|
||||
- Backend 生产构建：通过。
|
||||
- 四个橙色角色 V4 Prompt 预检：全部 16:9、当前版本、零冲突、无人名串线。
|
||||
- 未触发真实付费 AI 生成。
|
||||
|
||||
### 风险/后续
|
||||
|
||||
- Prompt 收口不等于单画布三视图已经达到 S+；历史最佳视觉分仍为 87。
|
||||
- 下一阶段继续执行分面板生成、分别质检、程序化合成和 96+ 总质检。
|
||||
|
||||
## [WORK_SYNC_2026-07-16_V8] - 2026-07-16
|
||||
|
||||
### 新增
|
||||
|
||||
- 用户端与管理端新增共享的全局 AI 请求参数检查器，默认收起并通过右侧抽屉查看。
|
||||
- 统一展示路径参数、查询参数、明文请求体、Request ID 和请求状态。
|
||||
- 请求预览/预检完整展示后端响应；正式生成提取 Task、Generation Plan、Provider 路由与成本证据。
|
||||
- 新增敏感字段、Base64 与二进制摘要保护，以及最近 30 条会话历史、复制和清空能力。
|
||||
|
||||
### 验证
|
||||
|
||||
- AI 请求匹配、误捕获保护、参数快照、脱敏和预览证据测试：36/36 通过。
|
||||
- User App 与 Admin 生产构建：通过，Nginx 已提供新构建资源。
|
||||
- Backend 健康检查：`ok`。
|
||||
- 未触发付费 AI 调用。
|
||||
|
||||
### 风险/后续
|
||||
|
||||
- 旧同步接口若不返回 Task、Generation Plan 或请求预览，只能保证展示页面提交事实；最终 Provider 载荷需后端统一 Trace 才能完整覆盖。
|
||||
|
||||
## [WORK_SYNC_2026-07-16_V9] - 2026-07-16
|
||||
|
||||
### 新增
|
||||
|
||||
- 实现人物身份特写、严格正面、严格90度右向侧面、严格180度背面独立生成与独立质检。
|
||||
- 新增 FFmpeg 确定性 4K 四面板母版合成，避免最后一步重新绘制导致换脸。
|
||||
- 新增断点续跑和 `regenerate_image_types` 指定面板返修；用户端提供“只重生此面板”。
|
||||
- 新增诸葛亮真实小样 #984-#988 与实施验收报告。
|
||||
|
||||
### 变更
|
||||
|
||||
- 公共拆分面板模板升级为 `character_turnaround_split_panel_v1_1`，强化时代鞋履、年龄、手部、侧面几何和背面服装拓扑。
|
||||
- 面板视觉质检输出上限由 2600 提高到 5000 tokens。
|
||||
- 执行回执成本拆分为图片、视觉质检、本地合成和总成本，并补充质检 ProviderLog ID。
|
||||
- 视觉质检以落盘尺寸元数据为权威，禁止将 3840x2160 留白资产误判为非 16:9。
|
||||
|
||||
### 修复
|
||||
|
||||
- 修复“严格90度右向侧面”被本地 Prompt 契约错误拦截。
|
||||
- 修复质检 Provider 失败覆盖上一轮有效图片分数与状态的问题。
|
||||
- 修复正面质检 JSON 因 token 上限过低被截断的问题输入配置。
|
||||
|
||||
### 真实验收
|
||||
|
||||
- 身份 #984 为91分，侧面 #986 为88分，背面 #987 为89分，母版 #988 为 A+ 88分。
|
||||
- 严格侧面和严格背面成立；母版因现代白色橡胶鞋底命中一票否决，未晋升 S+ 或主锚点。
|
||||
- 4张4K图片成本 $1.7386，5次成功视觉质检 $0.4652，本地合成 $0，总计 $2.2038。
|
||||
- 补跑旧图质检遇到 OpenAI 429，两次失败调用成本为0，未继续发起付费生成。
|
||||
|
||||
### 验证
|
||||
|
||||
- 相关后端测试：29/29通过。
|
||||
- Backend 与 User App 生产构建：通过。
|
||||
|
||||
### 风险/后续
|
||||
|
||||
- 当前账户配额阻断进一步付费质检与返修。
|
||||
- 配额恢复后只返修未通过全身面板；四个面板和母版均达到96+且无一票否决，才可晋升视频身份母版。
|
||||
|
||||
## 追加模板
|
||||
|
||||
```markdown
|
||||
## [WORK_SYNC_YYYY-MM-DD_Vn] - YYYY-MM-DD
|
||||
|
||||
### 新增
|
||||
- ...
|
||||
|
||||
### 变更
|
||||
- ...
|
||||
|
||||
### 修复
|
||||
- ...
|
||||
|
||||
### 数据库
|
||||
- 迁移：...
|
||||
|
||||
### 验证
|
||||
- 构建：...
|
||||
- 测试：...
|
||||
- 冒烟：...
|
||||
|
||||
### 风险/回滚
|
||||
- ...
|
||||
```
|
||||
@@ -0,0 +1,83 @@
|
||||
# Work 文档模板 V1
|
||||
|
||||
## 1. 当前设计文档模板
|
||||
|
||||
```markdown
|
||||
# <领域/系统名称> V1
|
||||
|
||||
> 文档状态：当前有效 / 待实现 / 部分实现 / 待验证
|
||||
> 基线日期：YYYY-MM-DD
|
||||
> 事实来源：代码路径、迁移、状态快照
|
||||
|
||||
## 1. 目标
|
||||
## 2. 非目标
|
||||
## 3. 当前能力
|
||||
## 4. 核心对象
|
||||
## 5. 主流程
|
||||
## 6. 业务规则
|
||||
## 7. 数据/API/队列影响
|
||||
## 8. 安全与成本
|
||||
## 9. 当前差距
|
||||
## 10. 不可破坏规则
|
||||
## 11. 下一阶段
|
||||
## 12. 更新触发条件
|
||||
```
|
||||
|
||||
## 2. FEATURE 模板
|
||||
|
||||
```markdown
|
||||
# FEATURE_<名称>_V1
|
||||
|
||||
> 状态：讨论中 / 已确认 / 实现中 / 已验证 / 已取消
|
||||
> 关联基线：WORK_SYNC_...
|
||||
> 负责人：
|
||||
|
||||
## 背景与问题
|
||||
## 目标
|
||||
## 非目标
|
||||
## 用户流程
|
||||
## 业务规则
|
||||
## 方案
|
||||
## 替代方案
|
||||
## 数据库影响
|
||||
## API/队列/Provider 影响
|
||||
## UI 状态
|
||||
## 安全、隐私与成本
|
||||
## 兼容与迁移
|
||||
## 验收标准
|
||||
## 发布与回滚
|
||||
## 未决问题
|
||||
```
|
||||
|
||||
## 3. ADR 模板
|
||||
|
||||
```markdown
|
||||
# ADR_0001_<主题>
|
||||
|
||||
> 状态：提议 / 接受 / 废弃 / 被替代
|
||||
> 日期：YYYY-MM-DD
|
||||
|
||||
## 背景
|
||||
## 决策
|
||||
## 替代方案
|
||||
## 正面影响
|
||||
## 负面影响
|
||||
## 迁移与回滚
|
||||
## 验证方式
|
||||
```
|
||||
|
||||
## 4. 状态快照要求
|
||||
|
||||
状态快照必须包含：
|
||||
|
||||
- 审计时间、对象和口径。
|
||||
- 当前架构和真实运行配置。
|
||||
- 已实现、部分实现和仅设计能力。
|
||||
- 数据库、API、队列和 Provider 统计。
|
||||
- 构建、测试和服务验证。
|
||||
- Git、备份、部署和安全风险。
|
||||
- 与上一版状态快照的差异。
|
||||
- 明确列出未执行的验证。
|
||||
|
||||
禁止包含任何凭据或用户明细。
|
||||
|
||||
@@ -0,0 +1,133 @@
|
||||
# Work 与代码同步协议 V1
|
||||
|
||||
> 目标：让 Work 的设计世界持续认识 Git + Codex 的代码现实，同时避免把源码和敏感信息塞进知识库。
|
||||
|
||||
## 1. 权责划分
|
||||
|
||||
### Work 负责
|
||||
|
||||
- 产品定位和业务规则。
|
||||
- 新功能讨论、替代方案和优先级。
|
||||
- 跨模块架构决策。
|
||||
- 用户体验、质量标准和未来路线。
|
||||
- 形成 `FEATURE_*.md`、ADR 和验收口径。
|
||||
|
||||
### Git + Codex 负责
|
||||
|
||||
- 当前源码和数据库迁移。
|
||||
- 实现细节和接口事实。
|
||||
- 自动测试、构建和部署状态。
|
||||
- 当前生产配置与运行验证。
|
||||
- 生成状态快照和同步包。
|
||||
|
||||
## 2. 文档层级
|
||||
|
||||
```text
|
||||
L0 PROJECT_STATUS：不可变事实快照
|
||||
L1 SYSTEM/ENGINE/PIPELINE/DATABASE：当前有效设计
|
||||
L2 FEATURE/ADR：未来设计和决策
|
||||
L3 CHANGELOG：已发生变化
|
||||
L4 历史设计/讨论记录：仅供追溯
|
||||
```
|
||||
|
||||
L2 不能在代码完成前冒充 L1；L4 不能覆盖 L0。
|
||||
|
||||
## 3. 标准闭环
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
Idea[想法] --> Work[Work 讨论]
|
||||
Work --> Feature[FEATURE/ADR]
|
||||
Feature --> Codex[Codex 实现]
|
||||
Codex --> Verify[测试/构建/部署验证]
|
||||
Verify --> Change[更新 CHANGELOG]
|
||||
Change --> Domain[更新领域文档]
|
||||
Domain --> Status[必要时生成新状态快照]
|
||||
Status --> Upload[上传同步包]
|
||||
```
|
||||
|
||||
## 4. 何时更新哪些文档
|
||||
|
||||
| 变化 | 必须更新 |
|
||||
| --- | --- |
|
||||
| 小缺陷修复，不改变契约 | CHANGELOG |
|
||||
| API、状态或领域规则变化 | CHANGELOG + 对应领域文档 |
|
||||
| 新功能设计、尚未实现 | 新建 FEATURE 文档 |
|
||||
| 跨模块技术决策 | 新建 ADR |
|
||||
| Prisma schema 变化 | DATABASE + CHANGELOG + 迁移 |
|
||||
| Provider/队列/Prompt 机制变化 | AI_PIPELINE + CHANGELOG |
|
||||
| 小说生产逻辑变化 | NOVEL_ENGINE + CHANGELOG |
|
||||
| 短剧/视频/合成逻辑变化 | DRAMA_ENGINE + CHANGELOG |
|
||||
| 架构、部署、测试或风险显著变化 | 新建 PROJECT_STATUS_Vn |
|
||||
|
||||
## 5. 版本规则
|
||||
|
||||
- 状态快照：`PROJECT_STATUS_V1.md`、`V2.md`，发布后不可改写事实。
|
||||
- 当前设计：结构性改变升 V2；旧版本移入历史区或保留只读。
|
||||
- FEATURE/ADR：决策变化升版本，不覆盖已评审版本。
|
||||
- CHANGELOG：只追加，不回写历史结论；错误修正新增一条说明。
|
||||
- 同步批次：`WORK_SYNC_YYYY-MM-DD_Vn`。
|
||||
|
||||
## 6. 上传前检查
|
||||
|
||||
1. 文件只包含当前项目必要信息。
|
||||
2. 没有 `.env` 值、API Key、JWT、密码、签名 URL 和个人数据。
|
||||
3. 状态、数量和测试结果标注采集日期。
|
||||
4. “已实现”“部分实现”“待实现”区分清楚。
|
||||
5. 文档中的模型、路由和队列说法与源码一致。
|
||||
6. 所有文件列入 `SYNC_MANIFEST.md` 并生成 SHA-256。
|
||||
7. `CHANGELOG.md` 已追加本批次。
|
||||
8. 上传后在 Work 标记批次号和生效日期。
|
||||
|
||||
## 7. Work 讨论新功能的输入模板
|
||||
|
||||
```markdown
|
||||
当前基线：WORK_SYNC_YYYY-MM-DD_Vn
|
||||
关联现状：PROJECT_STATUS_Vn
|
||||
关联领域：<领域文档>
|
||||
|
||||
目标：
|
||||
非目标：
|
||||
业务规则：
|
||||
现有约束：
|
||||
预期用户流程：
|
||||
数据影响：
|
||||
API/队列/Provider 影响：
|
||||
成本与安全：
|
||||
验收标准：
|
||||
回滚条件：
|
||||
```
|
||||
|
||||
## 8. 交给 Codex 的实现包
|
||||
|
||||
Work 讨论结束后，交付内容应至少包括：
|
||||
|
||||
- 已确认的 FEATURE/ADR 文件。
|
||||
- 关联的当前状态和领域文档版本。
|
||||
- 明确的验收标准。
|
||||
- 不允许改变的现有行为。
|
||||
- 是否允许数据库迁移、付费调用和生产重启。
|
||||
|
||||
不要只复制一段没有上下文的聊天结论。
|
||||
|
||||
## 9. 冲突处理
|
||||
|
||||
### 文档与代码冲突
|
||||
|
||||
先审计源码、迁移和运行状态；确认代码现实后更新状态快照。若代码本身是错误实现，再通过 FEATURE/修复任务改变代码，不能为了让文档“看起来一致”而掩盖差异。
|
||||
|
||||
### Work 与最新设计冲突
|
||||
|
||||
保留两个方案，形成 ADR，记录为什么更改。未经确认的 Work 建议不得直接覆盖当前有效文档。
|
||||
|
||||
### 数据与文档冲突
|
||||
|
||||
实时业务数量以数据库只读查询为准；文档快照必须标注日期。
|
||||
|
||||
## 10. 建议节奏
|
||||
|
||||
- 每个已上线功能：立即追加 CHANGELOG。
|
||||
- 每周或每个开发批次：更新受影响领域文档。
|
||||
- 每次结构性发布：生成新状态快照和同步清单。
|
||||
- 每月至少一次：检查备份、状态漂移、失败任务和敏感信息。
|
||||
|
||||
@@ -0,0 +1,42 @@
|
||||
# 历史设计使用说明
|
||||
|
||||
`docs/system_a/`、`docs/system_b/`、根目录旧架构文档和早期进度记录保留了项目演进过程，但不能直接代表当前实现。
|
||||
|
||||
## 1. 默认不上传全量历史文档
|
||||
|
||||
原因：
|
||||
|
||||
- 旧文档假定用户端是 uni-app，当前实际为 Vue 3 H5。
|
||||
- 旧文档假定管理端采用 GeekerAdmin，当前实际是自研单页后台。
|
||||
- 旧数据库、Provider、队列和视频能力与当前代码差异明显。
|
||||
- 同一能力可能在系统 A/B 中重复定义，容易让 Work 得出相互冲突的结论。
|
||||
|
||||
## 2. 可按需查阅的历史资料
|
||||
|
||||
| 历史资料 | 适合回答 | 使用条件 |
|
||||
| --- | --- | --- |
|
||||
| `docs/system_a/` | 小说、漫剧和早期平台业务设想 | 必须与当前状态文档对照 |
|
||||
| `docs/system_b/` | 真人动态视频的早期需求与合并思路 | 不得推断已全部实现 |
|
||||
| `CURRENT_ARCHITECTURE.md` | 某阶段架构演进 | 先核对日期和源码 |
|
||||
| `NOVEL_IP_SYSTEM_DESIGN.md` | 小说/IP 资产设计来源 | 只采纳未过时的规则 |
|
||||
| `CODEX_PROGRESS.md` | 开发过程和阶段记录 | 不作为验收结果 |
|
||||
| `AI_VIDEO_TEST_LESSONS.md` | 视频生产经验 | 已复制版本化快照到同步包 |
|
||||
|
||||
## 3. 上传历史文档的格式
|
||||
|
||||
如 Work 需要某份旧文档，应在文件顶部增加外部说明或上传备注：
|
||||
|
||||
```text
|
||||
状态：历史参考
|
||||
不代表当前实现
|
||||
当前基线：WORK_SYNC_2026-07-15_V1
|
||||
需要对照：PROJECT_STATUS_V1.md
|
||||
讨论目的：<为什么需要这份旧文档>
|
||||
```
|
||||
|
||||
不要直接修改原历史文件来伪装成当前设计；有价值的结论应提炼到新的 FEATURE、ADR 或当前领域文档。
|
||||
|
||||
## 4. 何时归档当前文档
|
||||
|
||||
当前领域文档升级版本后，旧版移入此区的对应子目录，并在新文档和 CHANGELOG 中说明替代关系。状态快照不移除，持续保留 V1、V2、V3。
|
||||
|
||||
@@ -0,0 +1,69 @@
|
||||
# AI 请求参数检查器实施报告 V1
|
||||
|
||||
> 实施日期：2026-07-16
|
||||
> 状态：用户端与管理端已上线，后端统一 Provider Trace 待后续增强
|
||||
> 目标：让所有 AI 生成、审核、质检、预检与合成入口具备可追溯的页面参数视图。
|
||||
|
||||
## 1. 用户入口
|
||||
|
||||
登录用户端或管理端后，页面右侧固定显示“AI 请求参数”入口。面板默认关闭，点击后从右侧滑出；移动端改为全屏抽屉并保留横向请求历史。两端复用同一个共享组件和同一套路由规则，避免实现漂移。
|
||||
|
||||
抽屉支持：
|
||||
|
||||
- 最近 30 条会话级请求历史。
|
||||
- 请求状态、HTTP 方法、接口路径、时间与 Request ID。
|
||||
- 完整 `path_params`、`query_params` 与明文 `body`。
|
||||
- 请求预览/预检的完整后端响应。
|
||||
- 正式生成返回的 `task.input_json`、Generation Plan、Provider 路由、最终请求与成本证据。
|
||||
- 一键复制与清空历史。
|
||||
|
||||
## 2. 捕获位置
|
||||
|
||||
检查器接入 `UserApiClient.request()` 与管理端 `ApiClient.request()`，在应用层加密之前复制一份仅用于诊断的安全快照，因此可以看到页面实际提交的可读参数，又不会改变原请求。
|
||||
|
||||
当前动作级白名单覆盖：
|
||||
|
||||
- Provider Lab 与提示词直出。
|
||||
- 原著分析、改编圣经、角色/场景/道具提取与 Prompt 优化。
|
||||
- 分集、场景剧本、分镜及其请求预览。
|
||||
- 人物图片、人物三视图、角色元素测试与视觉质检。
|
||||
- 关键帧、语音、单句 TTS 重试、字幕、音乐与视频生成。
|
||||
- 视频预检、成本估算、自动 QC、重试与成片合成。
|
||||
- 管理端 Provider 实测、小说方案/IP圣经/章节任务与爆款案例 AI 分析。
|
||||
|
||||
普通项目保存、人工审核、素材绑定、候选选择和确认操作不进入历史，避免诊断面板被非 AI 写请求污染。
|
||||
|
||||
## 3. 数据安全
|
||||
|
||||
- `password`、Authorization、API Key、Token、Secret 自动隐藏。
|
||||
- Base64 与二进制正文不写入面板，只保留文件名、MIME、字节数或字符数摘要。
|
||||
- 历史仅写入浏览器 `sessionStorage`，最多 30 条，不进入业务数据库。
|
||||
- 检查器故障或浏览器存储已满时，不得阻断真实生成。
|
||||
|
||||
## 4. 两层事实边界
|
||||
|
||||
### 页面提交事实
|
||||
|
||||
始终记录前端实际送入 API 的路径参数、查询参数和请求体。这一层适合检查漏参、错参、Provider 选择与人工覆盖值。
|
||||
|
||||
### 后端执行事实
|
||||
|
||||
后端返回请求预览、Task、Generation Plan、Provider 路由或成本信息时，检查器同步展示。这一层适合检查 Prompt 编译、参考图、模型参数、回退与成本。
|
||||
|
||||
若旧接口没有返回执行证据，面板会明确显示“尚未返回”，不会把前端请求体伪装成最终 Provider 载荷。后续如需覆盖所有同步旧接口，应增加统一的后端 Provider Trace，而不是在前端猜测。
|
||||
|
||||
## 5. 验证
|
||||
|
||||
- `ai-request-inspector.spec.ts`：36/36 通过。
|
||||
- User App 与 Admin TypeScript、Vite 生产构建：通过。
|
||||
- `git diff --check`：通过。
|
||||
- Nginx 已提供本次新构建静态资源。
|
||||
- Backend 健康检查：`ok`。
|
||||
- 本次验证未触发任何付费 AI 调用。
|
||||
|
||||
## 6. 后续
|
||||
|
||||
1. 在后端统一 Provider 执行层增加脱敏 Trace ID 与最终载荷摘要。
|
||||
2. 让同步旧接口也能通过 Request ID 查询 Provider Trace。
|
||||
3. 将请求记录与不可变 Generation Plan、ProviderLog 和成品 QC 建立可点击关联。
|
||||
4. 按真实漏项继续维护动作级白名单，普通保存和人工操作必须保留误捕获测试。
|
||||
File diff suppressed because it is too large
Load Diff
@@ -0,0 +1,59 @@
|
||||
# Kling v3 Omni API 参数基线 V1
|
||||
|
||||
> 同步日期：2026-07-15
|
||||
> 适用模型：`kling-v3-omni`
|
||||
> 代码驱动：`kling_omni_video`
|
||||
|
||||
## 官方基线
|
||||
|
||||
- 创建任务：`POST /v1/videos/omni-video`
|
||||
- 查询任务：`GET /v1/videos/omni-video/{task_id}`
|
||||
- 鉴权：新版 API Key，`Authorization: Bearer <KLING_API_KEY>`
|
||||
- 区域域名：`https://api-singapore.klingai.com`
|
||||
- 清晰度：`std`=720P、`pro`=1080P、`4k`=原生 4K
|
||||
- 时长：3-15 秒
|
||||
- Prompt：最多 2500 字符
|
||||
- 自定义多镜头：最多 6 段，每段 Prompt 最多 512 字符，各段时长总和必须等于任务总时长
|
||||
|
||||
## 输入限制
|
||||
|
||||
- 无参考视频时：`image_list` 图片数与 `element_list` 元素数合计最多 7 个。
|
||||
- 有参考视频时：图片与元素合计最多 4 个。
|
||||
- 参考视频最多 1 个；存在参考视频时 `sound` 必须为 `off`。
|
||||
- 使用首帧/尾帧时，元素最多 3 个。
|
||||
- 图片支持 JPG/JPEG/PNG，单图不超过 10MB，宽高均不低于 300px，宽高比范围 1:2.5 至 2.5:1。
|
||||
- 视频支持 MP4/MOV，3-15.5 秒，最大 200MB，24-60fps。
|
||||
|
||||
## 平台生产画幅
|
||||
|
||||
- 当前平台不再生产竖屏，新冻结的 S+ Generation Plan 固定为 `16:9`。
|
||||
- 1080P视频为1920×1080，原生4K为3840×2160，关键帧基线为2560×1440。
|
||||
- 已冻结的历史计划和既有素材不原地改写；重新生成时必须冻结新的16:9修订。
|
||||
|
||||
## 视频角色元素
|
||||
|
||||
- Kling 元素库的视频角色元素源视频要求单一角色、3-8秒，并建议包含正面与左右轻侧角度。
|
||||
- 平台默认生成8秒、1080P、16:9的中性角色身份视频；该视频只用于建立角色元素，不承载剧情表演。
|
||||
- 当前未确认存在可公开调用的“创建视频角色元素”API，因此平台不伪造自动创建能力：用户在 Kling 元素库完成上传后，将真实 `element_id` 导入平台。
|
||||
- 正式 Omni 请求同时提交 `element_list` 与 `<<<element_n>>>` Prompt 引用；网页端 `@元素名` 仅是人工操作语法，不代替 API 绑定。
|
||||
- 无参考视频时，图片与元素总数不超过7；平台按 `可用图片数 = 7 - 已绑定元素数` 动态收紧图片输入。视频角色元素最多3个。
|
||||
- S+ 镜头中每个出场角色都必须有质检分不低于90的已审批元素，否则在冻结计划前阻断付费生成。
|
||||
|
||||
## 平台映射
|
||||
|
||||
| Provider | `mode` | 官方价格 |
|
||||
| --- | --- | ---: |
|
||||
| `kling-v3-omni-native-audio-720p-video` | `std` | $0.112/s |
|
||||
| `kling-v3-omni-native-audio-1080p-video` | `pro` | $0.14/s |
|
||||
| `kling-v3-omni-native-audio-4k-video` | `4k` | $0.42/s |
|
||||
|
||||
三个 Provider 默认禁用。启用前必须在后台写入新版 `KLING_API_KEY`，并以单镜头小样验证账号权限、4K 可用性和实际账单。
|
||||
|
||||
## 官方资料
|
||||
|
||||
- [Kling v3 Omni API](https://kling.ai/document-api/api/video/3-0-omni/video-omni)
|
||||
- [Authentication](https://kling.ai/document-api/api/get-started/authentication)
|
||||
- [Billing Method](https://kling.ai/document-api/productBilling/billingMethod)
|
||||
- [Kling Video 3 Omni Guide](https://kling.ai/quickstart/klingai-video-3-omni-model-user-guide)
|
||||
- [Kling Element Library Guide](https://kling.ai/quickstart/klingai-element-library-3-user-guide)
|
||||
- [Kling Video 3 Model Guide](https://kling.ai/quickstart/klingai-video-3-model-user-guide)
|
||||
@@ -0,0 +1,148 @@
|
||||
# 16:9 与 Kling 视频角色元素实施报告 V1
|
||||
|
||||
> 实施日期：2026-07-15
|
||||
> 状态：工程完成，真实元素创建与付费镜头待人工验收
|
||||
> 适用范围：新 S+ 图片、关键帧、视频、Generation Plan 与 Kling V3 Omni 正式请求
|
||||
|
||||
## 1. 本阶段目标
|
||||
|
||||
1. 新生产链路停止使用9:16，统一到16:9。
|
||||
2. 建立可复用的视频角色元素资产与审批流程。
|
||||
3. 让角色元素与关键帧、音色、视频参数、QC、成本共同冻结进不可变 Generation Plan。
|
||||
4. 正式 Omni 请求提交真实供应商元素 ID，而不是只依赖角色描述词。
|
||||
|
||||
## 2. 16:9 生产合同
|
||||
|
||||
平台新增单一生产格式常量：
|
||||
|
||||
```text
|
||||
视频：1920×1080 / 16:9 / 默认1080P
|
||||
关键帧：2560×1440 / 16:9
|
||||
原生4K：3840×2160 / 16:9
|
||||
```
|
||||
|
||||
该常量已接入关键帧、真人视频、Prompt Builder、Production Contract、Provider Lab、媒体合成和用户端表单。数据库中42个 ImageProvider/VideoProvider 的 `production_aspect_ratio` 与 `allowed_aspect_ratios` 已统一为16:9。
|
||||
|
||||
历史素材、历史项目与已冻结 Generation Plan 不原地改写。旧镜头如需重生，应创建新的16:9计划修订，保留原执行证据。
|
||||
|
||||
## 3. 角色元素源视频
|
||||
|
||||
平台复用角色锚点视频测试执行器，新增 `video_character_element_source` 目的：
|
||||
|
||||
- 单一人物，3-8秒，默认8秒。
|
||||
- 16:9、1080P、固定机位、浅灰中性背景、均匀正面光。
|
||||
- 腰部以上入镜，正面、左侧约30度、回正、右侧约30度、回正。
|
||||
- 只允许自然呼吸、眨眼与克制头部转动。
|
||||
- 可输入一句中性台词以提取自然声线。
|
||||
- 禁止字幕、文字、BGM、环境噪声、特效、切镜与遮脸。
|
||||
|
||||
生成是显式付费动作，不会因打开页面自动触发。输出保存为普通私有视频素材，并标记下一步为上传 Kling 元素库。
|
||||
|
||||
## 4. 供应商绑定与审批
|
||||
|
||||
新增 `CharacterProviderBinding`：
|
||||
|
||||
```text
|
||||
global_character_id
|
||||
look_version_id
|
||||
source_asset_id
|
||||
provider_code
|
||||
provider_asset_type
|
||||
provider_element_id
|
||||
element_name / element_description
|
||||
source_duration
|
||||
voice_bound / voice_id / voice_description
|
||||
validation_score / validation_report_json
|
||||
binding_version / status / is_primary
|
||||
```
|
||||
|
||||
约束：
|
||||
|
||||
- 视频元素源素材若已提供，必须是视频且时长3-8秒。
|
||||
- 同一供应商元素 ID 不能绑定到两个角色。
|
||||
- 质检分低于90不能标记 `approved` 或主元素。
|
||||
- 正式生成只读取 `approved` 绑定。
|
||||
|
||||
当前公开文档没有提供已验证的“创建视频角色元素”API，因此平台不伪造自动上传能力。用户在 Kling 网页或 App 的元素库创建元素后，把真实 `element_id` 导入平台。后续若官方开放稳定接口，再单独增加自动创建执行器。
|
||||
|
||||
## 5. Generation Plan 与请求执行
|
||||
|
||||
冻结计划时，平台把以下信息写入 `element_plan_json.actor_lock.provider_elements`：
|
||||
|
||||
- 平台绑定 ID。
|
||||
- 项目角色 ID 与全局角色 ID。
|
||||
- 供应商代码、元素 ID、元素名称。
|
||||
- 是否绑定声线与 voice ID。
|
||||
|
||||
执行时只读取这份冻结快照：
|
||||
|
||||
```json
|
||||
{
|
||||
"element_list": [
|
||||
{ "element_id": "供应商真实元素ID" }
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
Prompt 同时按数组顺序写入 `<<<element_1>>>`、`<<<element_2>>>` 等引用，避免角色、台词和声线互换。网页端 `@元素名称` 不是 API 绑定，不能替代 `element_list`。
|
||||
|
||||
对于新 S+ Kling Omni 镜头，只要有出场角色缺少已审批元素，系统即抛出 `SPLUS_CHARACTER_ELEMENT_BINDING_REQUIRED`，在付费提交前停止。
|
||||
|
||||
## 6. 输入数量规则
|
||||
|
||||
- 无参考视频时，Omni 图片与元素合计最多7个。
|
||||
- 视频角色元素最多3个。
|
||||
- 平台运行时按 `最大图片数 = min(模型图片上限, 7 - 元素数量)` 动态裁剪参考图。
|
||||
- 有参考视频时仍按官方更严格的4个合计上限和声音互斥规则执行。
|
||||
|
||||
## 7. 模型注册表
|
||||
|
||||
迁移后重新发布114个 Provider 的注册表：
|
||||
|
||||
| 注册表 | 当前数量 | 变化原因 |
|
||||
| --- | ---: | --- |
|
||||
| 能力版本 | 156 | 42个图片/视频 Provider 新增16:9能力修订 |
|
||||
| 参数 Schema 版本 | 156 | 42个图片/视频 Provider 只允许16:9的新修订 |
|
||||
| 价格版本 | 114 | 本阶段没有改价，继续复用原价格版本 |
|
||||
|
||||
旧注册表修订保留，旧 Generation Plan 仍可审计原参数。
|
||||
|
||||
## 8. 前端入口
|
||||
|
||||
全局角色页新增：
|
||||
|
||||
- 供应商模型族、元素 ID、元素名称。
|
||||
- 可选源视频素材 ID。
|
||||
- 声线绑定与 voice ID。
|
||||
- 候选导入、质检分、审批为主元素。
|
||||
|
||||
项目角色页新增“生成元素源视频”。Generation Plan 详情会展示画幅、冻结元素 ID、角色名和元素名。
|
||||
|
||||
## 9. 验证结果
|
||||
|
||||
- Prisma schema：有效。
|
||||
- 迁移：40/40 已部署。
|
||||
- Backend 生产构建：通过。
|
||||
- User App 生产构建：通过。
|
||||
- Model Registry 与 Generation Plan 定向测试：6/6 通过。
|
||||
- Prompt Builder 定向测试：7/7 通过。
|
||||
- 全量 Backend 测试：269通过、34失败，与上一同步基线一致。
|
||||
- Backend 与 Worker 受控重启后均为 `active`，健康检查返回 `ok`。
|
||||
- 未触发新的付费角色源视频或正式视频生成。
|
||||
|
||||
LiveAction 历史测试仍有19条失败，其中多数来自旧 Prisma mock 与既有导演策略断言漂移，不是本阶段新接口的编译错误；需作为独立测试债处理。
|
||||
|
||||
## 10. 官方依据
|
||||
|
||||
- [Kling Element Library Guide](https://kling.ai/quickstart/klingai-element-library-3-user-guide)
|
||||
- [Kling Video 3 Model Guide](https://kling.ai/quickstart/klingai-video-3-model-user-guide)
|
||||
- [Kling Video 3 Omni Guide](https://kling.ai/quickstart/klingai-video-3-omni-model-user-guide)
|
||||
- [Kling V3 Omni API](https://kling.ai/document-api/api/video/3-0-omni/video-omni)
|
||||
|
||||
## 11. 下一步验收
|
||||
|
||||
1. 选择一名已通过三视图与锚点审核的角色，生成8秒身份源视频。
|
||||
2. 人工检查正侧脸一致性、服装、年龄、口型和声线。
|
||||
3. 在 Kling 元素库创建视频角色元素，导入真实 ID 并完成90分门禁。
|
||||
4. 用一个全新 S+ 单人物镜头冻结计划并生成候选。
|
||||
5. 对照 Generation Plan、ProviderLog、Kling 任务、QC 与真实账单。
|
||||
@@ -0,0 +1,116 @@
|
||||
# Prompt 规则去劣取优审计 V1
|
||||
|
||||
> 审计日期：2026-07-15
|
||||
> 适用内核：`splus_v1`
|
||||
> 审计基线：`S_PLUS_SHORT_DRAMA_CODEX_OPTIMIZATION_V1_1.md`
|
||||
> 代码实现：`backend/src/production-kernel/prompts/prompt-rule-registry.ts`
|
||||
|
||||
## 1. 审计原则
|
||||
|
||||
历史 Prompt 是生产经验来源，不是公共模板真相。处理规则如下：
|
||||
|
||||
1. 历史记录和素材快照不改写、不删除。
|
||||
2. 项目专名、素材编号、临时 URL 和单次返修上下文不得进入公共模板。
|
||||
3. 能跨项目解释、能转换为可执行约束的经验，去除项目事实后进入候选规则。
|
||||
4. 未经 A/B 证明的题材或 Provider 经验只允许处于 `testing`，不能默认激活。
|
||||
5. 规则必须记录阶段、范围、激活条件、预期改善、证据和版本。
|
||||
6. 公共规则之间冲突时，以来源事实、已批准改编、连续性和 Provider 可执行性为先。
|
||||
|
||||
## 2. 已批准保留
|
||||
|
||||
| 规则 ID | 提取出的有效经验 | 适用范围 | 处理结果 |
|
||||
| --- | --- | --- | --- |
|
||||
| `shot.performance_arc` | 表演包含起点、触发、可见反应和余韵 | 全局 / 镜头 | 保留并结构化 |
|
||||
| `shot.dialogue_reaction_timing` | 对白前有准备、句尾有反应与安全余量 | 全局 / 镜头 | 保留并结构化 |
|
||||
| `shot.motivated_camera` | 运镜有起点、动机、速度和落点 | 全局 / 镜头 | 保留并结构化 |
|
||||
| `shot.first_last_frame_continuity` | 首尾帧同空间、光源、轴线和运动方向 | 全局 / 首尾帧 | 保留并结构化 |
|
||||
| `shot.cross_space_boundary` | 跨物理空间分别建立，用可剪切点桥接 | 全局 / 镜头 | 保留并抽象 |
|
||||
| `shot.scene_anchor_lock` | 连续场次锁定空间结构、光源与固定物件 | 全局 / 连续性 | 保留并结构化 |
|
||||
| `shot.character_state_lock` | 身份母版与当前服装/伤势状态分工 | 全局 / 角色资产 | 保留并结构化 |
|
||||
| `shot.asset_visibility_boundary` | 资产检索标签不等于必须入画 | 全局 / 资产 | 保留并结构化 |
|
||||
| `shot.axis_and_screen_direction` | 连续动作记录轴线和画面方向 | 全局 / 连续性 | 保留并结构化 |
|
||||
| `shot.state_handoff` | 前镜结束状态与后镜开始状态接力 | 全局 / 连续性 | 保留并结构化 |
|
||||
| `shot.dialogue_integrity` | 对白保持说话人、语义、顺序和完整性 | 全局 / 对白 | 保留并结构化 |
|
||||
| `shot.sound_is_story_action` | 环境声、拟音、对白和声音桥服务剧情 | 全局 / 声音 | 保留并结构化 |
|
||||
| `shot.transition_responsibility` | 视频模型与后期合并层职责分离 | 全局 / 转场 | 保留并结构化 |
|
||||
| `shot.suspense_sound_pressure` | 悬疑声音绑定证据、动作和心理压力 | 悬疑题材 | 保留为题材规则 |
|
||||
| `shot.suspense_inner_monologue` | 内心独白只用于悬疑关键心理转折 | 悬疑题材 | 保留为题材规则 |
|
||||
| `shot.ui_text_post_composite` | 精确中文 UI、进度条和字幕由后期合成 | 全局 / UI | 保留并结构化 |
|
||||
| `shot.ui_reaction_placeholder` | UI 占位由构图、视线、停顿和反应构成 | 全局 / UI | 保留并结构化 |
|
||||
| `shot.reference_image_responsibility` | 每张参考图分配唯一主职责和优先级 | 全局 / Provider 输入 | 保留并结构化 |
|
||||
| `shot.one_primary_action` | 单片段只承担一个主要动作链或转折 | 全局 / 镜头 | 保留并结构化 |
|
||||
| `shot.no_mechanical_filler` | 不为满足数量补空镜、反应或证据镜 | 全局 / 分镜规划 | 新增硬规则 |
|
||||
| `episode.hook_truth_and_payoff` | 钩子来自当前冲突并在本集兑现 | 全局 / 分集 | 保留并结构化 |
|
||||
| `timeline.subtitle_spoken_content_only` | 字幕只含实际语音并跟随语音时点 | 全局 / 时间线 | 保留并结构化 |
|
||||
|
||||
## 3. 已抽象重写
|
||||
|
||||
| 历史写法 | 问题 | 新写法 |
|
||||
| --- | --- | --- |
|
||||
| 用某酒店、宴会厅和红毯示范所有开场 | 项目场景污染公共模板 | 开场运镜由事件、情绪和空间边界决定 |
|
||||
| 用具体两个人名说明对话轴线 | 角色污染 | 使用当前角色关系轴线和画面运动方向 |
|
||||
| 用具体文件、礼服、胸针作为资产示例 | 道具和服装污染 | 使用当前镜头的角色状态、主场景和关键道具 |
|
||||
| 所有开场都要求俯冲、快速推进 | 风格机械化 | 冲突、悬疑、庄重、悲伤等开场分别选择动势 |
|
||||
| 所有跨空间镜头按“楼外到宴会厅”解释 | 单一案例过拟合 | 任何独立物理空间均分别建立并设计桥接 |
|
||||
| 终局必须出现特定底牌、地点和两个名字 | 某故事终局污染分集评分 | 检查核心冲突结果、主角选择、状态变化和余波 |
|
||||
|
||||
## 4. 已废弃
|
||||
|
||||
| 行为 | 废弃原因 | 代码保护 |
|
||||
| --- | --- | --- |
|
||||
| `导演补拍节奏点` 自动补满镜头数 | 凭空造剧情，产生平庸填充 | `fitScriptStoryboardBeatsToCount` 与 `expandStoryboardSeeds` 不再增删剧情点 |
|
||||
| 按说话人自动拆成多个对白反打镜头 | 把一场表演切成对白素材块 | `normalizeStoryboardDraftsForVideo` 保持已批准戏剧单元 |
|
||||
| 用关键词命中宣称固定 `96+`、`98+` | 分数未经样本校准且可被堆词作弊 | 新内核只认硬门、版本化 Rubric、媒体 QC 和人工校准 |
|
||||
| 公共模板直接出现历史人物、地点和道具 | 污染新项目 | 污染扫描器与静态回归测试阻断 |
|
||||
| 生成失败经验自动追加到公共 Prompt | 单次事故可能是素材或 Provider 原因 | 只进入 `PromptRuleCandidateV1`，审核/A-B 后晋升 |
|
||||
|
||||
## 5. 待验证候选
|
||||
|
||||
以下经验可能有价值，但证据不足，暂不默认激活：
|
||||
|
||||
| 候选 | 需要验证的问题 |
|
||||
| --- | --- |
|
||||
| 近景/特写占比约 80% | 不同题材、动作密度和平台是否同样适用 |
|
||||
| 开场前 5 镜最多 1 个环境镜 | 长镜头、史诗场面和慢悬疑是否需要例外 |
|
||||
| UI 占位统一为 1.2-3 秒 | 字数、屏幕尺寸和观众阅读速度应如何计算 |
|
||||
| 特定时长档位 5/10/15 秒 | 必须由真实 Provider 能力档案决定，不能写死 |
|
||||
| 复杂多角色场景默认多图参考 | 不同模型的图数上限、权重和身份一致性差异 |
|
||||
|
||||
## 6. 本轮代码变更
|
||||
|
||||
- 新增五级生产合同、质量结果、QC Delta 和规则候选合同。
|
||||
- 新增严格验证器，覆盖来源引用、钩子兑现、场景转折、对白时长、资产职责和首尾帧连续性。
|
||||
- 新增版本化规则注册表和按阶段/题材/Provider 激活机制。
|
||||
- 新增 Prompt 污染扫描器，检测历史项目词、数据库 ID、临时 URL 和素材编号写法。
|
||||
- 公共脚本 Prompt 已接入经批准的镜头规则。
|
||||
- 公共脚本和分集服务已清除当前审计到的历史项目事实。
|
||||
- 生产构建通过；中性合同与污染回归测试通过。
|
||||
|
||||
## 7. 剩余隔离区
|
||||
|
||||
以下旧服务仍含历史项目专属分支，当前不得作为 `splus_v1` 的公共 Prompt 来源：
|
||||
|
||||
| 文件 | 当前命中量 | 处置策略 |
|
||||
| --- | ---: | --- |
|
||||
| `characters/characters.service.ts` | 28 | 区分角色资产历史兼容与公共角色生成模板，逐段迁出 |
|
||||
| `images/images.service.ts` | 14 | 把关键帧项目特例改为合同驱动资产选择 |
|
||||
| `live-action/live-action.service.ts` | 10 | 新项目绕过旧项目特例，后续接 Provider Compiler |
|
||||
| `live-action/prompt-builder.service.ts` | 9 | 仅保留通用镜头编译，删除人物/酒店/文件专属分支 |
|
||||
|
||||
命中量是本轮关键词审计结果，不等同全部问题数量。清理时必须逐条判断是历史读取兼容、项目数据还是公共生成逻辑，禁止批量替换。
|
||||
|
||||
## 8. 晋升流程
|
||||
|
||||
```text
|
||||
历史 Prompt / 返修记录 / QC 差异
|
||||
-> PromptRuleCandidateV1
|
||||
-> 去除项目事实与内部 ID
|
||||
-> 明确 stage / scope / activation_condition
|
||||
-> 至少两个不同项目复现
|
||||
-> 低成本 A/B
|
||||
-> 人工审核
|
||||
-> approved 规则版本
|
||||
-> 按条件进入编译请求
|
||||
```
|
||||
|
||||
任何步骤缺失，规则只能停留在 `candidate` 或 `testing`。
|
||||
@@ -0,0 +1,96 @@
|
||||
# AI 内容生产平台 Work 同步包
|
||||
|
||||
> 当前批次：`WORK_SYNC_2026-07-19_V11`
|
||||
> 适用对象：用于 Work 的项目知识库同步
|
||||
> 代码仓库：`/www/wwwroot/ai`
|
||||
|
||||
## 1. 这个目录解决什么问题
|
||||
|
||||
本目录把“当前代码事实”和“产品设计意图”分开维护，避免 Work 继续依据旧系统 A/B 文档推演已经变化的系统。
|
||||
|
||||
- Work 负责产品定位、业务规则、架构决策、功能方案和路线。
|
||||
- Git + Codex 负责当前代码、数据库迁移、测试、部署和运行事实。
|
||||
- 本目录是两者之间的可上传同步包，不是完整源码备份。
|
||||
|
||||
## 2. 首次上传顺序
|
||||
|
||||
1. `00_文档索引.md`
|
||||
2. `01_项目现状/PROJECT_STATUS_V1.md`
|
||||
3. `S_PLUS_BATCH_AUTOMATED_PRODUCTION_PIPELINE_V2.md`
|
||||
4. `S_PLUS_PRODUCTION_FLOW_AUDIT_V1.md`
|
||||
5. `02_架构设计/SYSTEM_ARCHITECTURE_V1.md`
|
||||
6. `05_AI流水线/AI_PIPELINE_V1.md`
|
||||
7. `06_数据库/DATABASE_CURRENT_V1.md`
|
||||
8. `03_小说引擎/NOVEL_ENGINE_V1.md`
|
||||
9. `04_短剧引擎/DRAMA_ENGINE_V1.md`
|
||||
10. `04_短剧引擎/AI_VIDEO_TEST_LESSONS_V1.md`
|
||||
11. `S_PLUS_SHORT_DRAMA_CODEX_OPTIMIZATION_V1_1.md`
|
||||
12. `PROMPT_RULE_AUDIT_V1.md`
|
||||
13. `SPLUS_PHASE_0_1_IMPLEMENTATION_REPORT.md`
|
||||
14. `SPLUS_PHASE_2_IMPLEMENTATION_REPORT.md`
|
||||
15. `KLING_S_PLUS_MODEL_ROUTING_SPEC_V1.0.md`
|
||||
16. `SPLUS_GENERATION_PLAN_IMPLEMENTATION_REPORT_V1.md`
|
||||
17. `SPLUS_MODEL_REGISTRY_AND_PLAN_DIFF_IMPLEMENTATION_REPORT_V1.md`
|
||||
18. `KLING_V3_OMNI_API_UPDATE_V1.md`
|
||||
19. `LANDSCAPE_CHARACTER_ELEMENT_IMPLEMENTATION_REPORT_V1.md`
|
||||
20. `SPLUS_CHARACTER_TURNAROUND_ITERATION_REPORT_V1.md`
|
||||
21. `SPLUS_CHARACTER_TURNAROUND_PROMPT_V4_AUDIT.md`
|
||||
22. `AI_REQUEST_INSPECTOR_IMPLEMENTATION_REPORT_V1.md`
|
||||
23. `SPLUS_CHARACTER_TURNAROUND_SPLIT_PANEL_IMPLEMENTATION_REPORT_V1.md`
|
||||
24. `SPLUS_EXECUTION_BRIDGE_EXTERNAL_ASSET_WORKFLOW_V1.md`
|
||||
25. `07_版本记录/CHANGELOG.md`
|
||||
26. `08_维护规范/WORK_SYNC_PROTOCOL.md`
|
||||
27. `SYNC_MANIFEST.md`
|
||||
|
||||
若 Work 只支持少量资料，优先上传 1-10；实施报告和维护模板可以第二批上传。
|
||||
|
||||
## 3. 不要默认上传的内容
|
||||
|
||||
- `backend/`、`workers/`、`user-app/`、`admin/` 完整源码。
|
||||
- `.env`、API Key、JWT、数据库密码和 Worker Secret。
|
||||
- `storage/`、`tmp/`、用户上传素材和 Provider 临时 URL。
|
||||
- 数据库导出中的用户明细、支付信息和私有内容。
|
||||
- `docs/system_a/`、`docs/system_b/` 全量历史设计。
|
||||
- 未审阅的对话记录、临时 Prompt 和生成日志。
|
||||
|
||||
历史文档需要讨论某项旧决策时，再按 `99_历史设计/README.md` 单独选取，并明确标记“历史参考，不代表当前实现”。
|
||||
|
||||
## 4. 文档类型
|
||||
|
||||
| 类型 | 是否可改 | 用途 |
|
||||
| --- | --- | --- |
|
||||
| 状态快照 | 不改，新增 V2/V3 | 某个时间点的代码、数据和运行事实 |
|
||||
| 当前设计 | 可修订并升版本 | 当前有效的稳定边界和业务规则 |
|
||||
| 变更记录 | 只追加 | 记录从上一同步批次发生的变化 |
|
||||
| 经验总结 | 可修订并升版本 | 经多次生产验证的可复用结论 |
|
||||
| 历史设计 | 不作为当前事实 | 解释旧决策和演进背景 |
|
||||
|
||||
## 5. 日常维护
|
||||
|
||||
小改动只需更新受影响领域文档和 `CHANGELOG.md`。以下变化必须生成新的项目状态快照：
|
||||
|
||||
- 顶层模块、数据库模型或部署拓扑变化。
|
||||
- 生产 Provider、队列或存储策略变化。
|
||||
- 新增完整业务流程或修改关键状态机。
|
||||
- 发布基线、测试结果或重大风险变化。
|
||||
- Work 与代码对同一事实出现分歧。
|
||||
|
||||
详细流程见 `08_维护规范/WORK_SYNC_PROTOCOL.md`。
|
||||
|
||||
## 6. 冲突处理
|
||||
|
||||
当文档互相冲突时，按以下优先级判断事实：
|
||||
|
||||
```text
|
||||
当前源码/迁移/运行验证
|
||||
> 最新 PROJECT_STATUS
|
||||
> 最新当前设计文档
|
||||
> CHANGELOG
|
||||
> 历史设计文档
|
||||
```
|
||||
|
||||
产品未来目标不按上述顺序覆盖，应由 Work 形成独立 `FEATURE_*.md` 或 ADR，再交给 Codex 实现。
|
||||
|
||||
## 7. 当前限制
|
||||
|
||||
`PROJECT_STATUS_V1` 是项目状态基线；各实施报告记录其对应阶段的代码事实。`S_PLUS_BATCH_AUTOMATED_PRODUCTION_PIPELINE_V2.md` 是新项目的目标流程，不代表其 P0-P5 已经全部上线。当前测试、Git 基线、队列覆盖、备份和真实内容验收风险，均以状态快照、现状审计、实施报告和 CHANGELOG 为准。
|
||||
@@ -0,0 +1,141 @@
|
||||
# S+ 人物三视图真实迭代报告 V1
|
||||
|
||||
> 实施与验收日期：2026-07-16
|
||||
> 验收项目：`诸葛亮与司马懿斗法`（Project #22）
|
||||
> 当前状态：工程保护链完成；单画布三视图路线未达到 S+，已停止继续递归
|
||||
> 结论口径：真实 Provider、真实图片、真实视觉质检和真实 ProviderLog，不以 Prompt 分代替成图质量
|
||||
|
||||
## 1. 本轮目标
|
||||
|
||||
本轮使用首个全新 S+ 项目的阻断资产计划，验证人物三视图能否作为后续关键帧、视频角色元素和正式分镜的身份母版。重点不是产出一张“看起来不错”的设定图，而是验证：
|
||||
|
||||
1. 同一角色的脸、年龄、发型和胡须能否跨面板稳定。
|
||||
2. 正面、严格侧面和背面能否保持同一套服装裁片、鞋履与比例。
|
||||
3. 失败图是否会被硬门阻断，避免自动晋升为角色主锚点。
|
||||
4. 参考图、Prompt、模型、成本和视觉结论能否完整审计。
|
||||
5. 迭代经验能否进入公共模板，而不是只修补诸葛亮一个角色。
|
||||
|
||||
## 2. 实测结果
|
||||
|
||||
资产计划合同为 #8，计划分为 20 项。首批只执行诸葛亮母版，司马懿、蜀军将领、九幽鬼将和五丈原场景继续被阻断，避免在路线未验证前扩大成本。
|
||||
|
||||
| 轮次 | 任务 | 模型 | 参考策略 | 素材 | Prompt 分 | 视觉分 | 结论 |
|
||||
| ---: | ---: | --- | --- | ---: | ---: | ---: | --- |
|
||||
| 1 | #749 | Seedream 5.0 | 无参考原创 | #978 | 98 | 77 | 道具、鞋履与跨视图身份漂移 |
|
||||
| 2 | #750 | Seedream 5.0 | 公共 V3 模板原创 | #979 | 98 | 83 | 构图改善，年龄与鞋履仍漂移 |
|
||||
| 预检 | #751 | 未调用图片模型 | 整板 #979 | - | 97 | - | Prompt 硬门阻断，无图片费用 |
|
||||
| 3 | #752 | Seedream 5.0 | 显式参考 #979 | #980 | 98 | **87** | 当前最佳，但未达到 S+ |
|
||||
| 4 | #753 | Seedream 5.0 | 整板递归 #980 | #981 | 98 | 82 | 质量回归，整板参考开始固化缺陷 |
|
||||
| A/B | #754 | GPT Image 2 | 整板参考 #980 | #982 | 98 | 86 | 结构接近，仍复制错误鞋型 |
|
||||
| 分层参考 | #755 | Seedream 5.0 | #980 左侧身份面板裁切 | #983 | 98 | 78 | 身份隔离有效，服装拓扑仍被重新设计 |
|
||||
|
||||
当前最佳是素材 #980、CharacterImage #147、2560x1440、视觉分 87。该图没有被审批，也没有被设置为角色主锚点。
|
||||
|
||||
## 3. 已进入公共底层的能力
|
||||
|
||||
### 3.1 公共三视图模板
|
||||
|
||||
- 本轮真实图片实验时公共模板为 `character_turnaround_public_v3_s_plus`；后续 Prompt 冲突审计已升级为 `character_turnaround_original_v4_s_plus`，详见 `SPLUS_CHARACTER_TURNAROUND_PROMPT_V4_AUDIT.md`。
|
||||
- 身份母版默认空手；剧情武器、法器和动作道具不再混入人物母版。
|
||||
- 增加古代鞋履、浅色服装高光、全身小脸年龄继承和工业级视图几何约束。
|
||||
- 角色输入仍是唯一可变业务描述，公共规则不绑定某个具体人物。
|
||||
|
||||
### 3.2 显式参考与审计
|
||||
|
||||
- 图片任务支持 `reference_asset_ids`，可明确指定本轮参考资产。
|
||||
- 任务记录实际参考资产，不再依赖隐式“最近一张图”。
|
||||
- 三视图只保持三视图身份，不会被错误自动晋升为 `anchor`。
|
||||
|
||||
### 3.3 身份面板裁切
|
||||
|
||||
- 支持 `reference_crop_mode=turnaround_face_panel`。
|
||||
- 系统从原三视图临时裁取左侧身份特写作为 Provider 参考。
|
||||
- 原始素材不修改，不生成伪锚点，裁切模式进入任务审计数据。
|
||||
|
||||
### 3.4 确定性视觉硬门
|
||||
|
||||
以下问题只要被视觉报告识别，即由代码升级为硬失败，不依赖审稿模型是否正确标记 `critical`：
|
||||
|
||||
- 现代鞋、厚底鞋、橡胶运动鞋等时代错误。
|
||||
- 跨视图身份明显漂移。
|
||||
- 侧面不是严格侧面、背面不成立等视图几何错误。
|
||||
|
||||
### 3.5 Prompt 复用与成本控制
|
||||
|
||||
- 已通过 98 分且参考模式一致的活动 Prompt 可直接复用。
|
||||
- 新增视觉经验不会再让同一可信 Prompt 每次重复进行多轮昂贵审稿。
|
||||
- Prompt 审稿输入不再混入单独提交给图片模型的负面约束文本，减少误判污染。
|
||||
|
||||
## 4. 成本结论
|
||||
|
||||
ProviderLog #1010 至 #1038 的实际成本：
|
||||
|
||||
| 类型 | 实际成本 |
|
||||
| --- | ---: |
|
||||
| TextProvider：Prompt 审稿与视觉质检 | $2.9753 |
|
||||
| ImageProvider | $0.1910 |
|
||||
| 合计 | **$3.1663** |
|
||||
|
||||
文本审稿与视觉质检成本约为图片成本的 15.6 倍。这说明成本优化不能只盯图片单价；高分 Prompt 的重复审稿、每轮高规格视觉复核和无效递归同样需要门控。
|
||||
|
||||
本轮已先消除可信 Prompt 重复审稿。视觉 QC 的分层模型和关键资产终审策略仍需后续单独设计，不能为了省钱关闭最终硬门。
|
||||
|
||||
## 5. 失败路线与停止条件
|
||||
|
||||
单画布同时生成“身份大特写 + 正面全身 + 严格侧面 + 背面”的路线已出现稳定瓶颈：
|
||||
|
||||
1. 整板递归会把正确身份和错误鞋履、裁片一起锁定。
|
||||
2. 只提供身份裁切后，模型仍会分别重建三个全身视图的服装和鞋履。
|
||||
3. Prompt 达到 98 分不等于跨视图资产拓扑达到 S+。
|
||||
4. Seedream 5.0 与 GPT Image 2 的 A/B 都没有解决同一类硬失败，继续换模型盲抽不构成有效优化。
|
||||
|
||||
因此停止对 #980、#981、#982、#983 继续整板递归。任何未达到硬门的候选不得以人工偏好绕过审批。
|
||||
|
||||
## 6. 下一阶段架构决策
|
||||
|
||||
下一阶段改为分面板人物母版，当前仅为已确认路线，尚未实现：
|
||||
|
||||
```text
|
||||
身份主特写
|
||||
-> 正面全身
|
||||
-> 严格 90 度侧面全身
|
||||
-> 背面全身
|
||||
-> 四个面板分别做身份、服装、鞋履和视图几何质检
|
||||
-> 程序化合成 16:9 白底设定板
|
||||
-> 合成后执行总质检
|
||||
```
|
||||
|
||||
建议放行规则：
|
||||
|
||||
- 每个子面板通过对应确定性硬门。
|
||||
- 跨面板身份与服装拓扑检查通过。
|
||||
- 合成总分达到 96+。
|
||||
- 人工确认后才允许晋升角色母版，并用于视频角色元素源视频。
|
||||
|
||||
## 7. 验证结果
|
||||
|
||||
- ImagesService 定向测试：16/16 通过。
|
||||
- Backend 生产构建：通过。
|
||||
- User App 生产构建：通过。
|
||||
- 真实付费图片生成：4 次有效成图，另有 1 次在图片调用前被 Prompt 门阻断。
|
||||
- 当前没有任何本轮图片被误标为 S+ 或自动晋升为主锚点。
|
||||
|
||||
## 8. 详细项目记录
|
||||
|
||||
逐图问题、任务号、素材号和原图路径记录在：
|
||||
|
||||
```text
|
||||
data/诸葛亮与司马懿斗法/7.第一批阻断母版生成记录.md
|
||||
```
|
||||
|
||||
Work 应以本报告作为工程结论，以项目记录作为生产追溯证据。下一次同步应新增分面板实现报告和首个 96+ 真实母版验收记录，不覆盖本报告。
|
||||
|
||||
## 9. V4 Prompt 审计补充
|
||||
|
||||
2026-07-16 根据网页端复核意见完成公共 Prompt 二次审计。V4 已消除“要求高清身份脸，同时禁止清晰正脸”的目标冲突，并增加模板版本硬门、历史经验语义过滤、人类/非人双分支和资产计划原创角色约束。
|
||||
|
||||
这次变更只提高下一次生成输入的可控性，不把 #978 至 #983 的历史视觉分改写为高分，也没有触发新的付费生成。四个阻断角色的详细预检结果见：
|
||||
|
||||
```text
|
||||
docs/work-sync/SPLUS_CHARACTER_TURNAROUND_PROMPT_V4_AUDIT.md
|
||||
```
|
||||
@@ -0,0 +1,112 @@
|
||||
# S+ 人物三视图 Prompt V4 审计
|
||||
|
||||
> 审计日期：2026-07-16
|
||||
> 审计对象：公共人物三视图模板、历史高分 Prompt 复用、优化经验注入、资产计划基础提示词，以及 Project #22 的四个阻断角色资产
|
||||
> 外部输入：ChatGPT 网页版对旧生产 Prompt 的 91/100 分析
|
||||
|
||||
## 1. 结论
|
||||
|
||||
网页版分析的核心判断成立：旧提示词中“左侧高清身份脸”与“禁止清晰正脸/真人脸特写”的组合存在直接冲突。问题不在细节不足，而在目标互相抵消、重复负面词稀释注意力，以及用“8K”文字替代真实输出参数。
|
||||
|
||||
但数据库中 Project #22 已实际提交的六次三视图请求并没有包含那五条冲突限制。真正仍存在的工程风险是：
|
||||
|
||||
1. 旧 V3 Prompt 即使已有 98 分，也可能被系统直接复用。
|
||||
2. 历史优化经验中曾同时存在“羽扇必须跨视图固定”和“身份母版必须空手”两套相反规则。
|
||||
3. 公共资产计划示例仍使用“同一真实演员式角色身份”，容易把后续资产描述带回真人肖像语义。
|
||||
4. 人类角色规则可能错误套用到多头、多臂、亡灵等非人角色。
|
||||
5. 网页版复制包的顶层通用 `negative_prompt` 仍可能展示五条冲突限制，即使实际三视图专层请求已经干净，容易造成“复制内容”和“实际提交”口径不一致。
|
||||
|
||||
因此本轮不是照抄网页版的诸葛亮专用长 Prompt，而是把正确结论收敛进公共 V4 模板和执行硬门。
|
||||
|
||||
## 2. 公共模板 V4
|
||||
|
||||
当前模板版本：
|
||||
|
||||
```text
|
||||
character_turnaround_original_v4_s_plus
|
||||
```
|
||||
|
||||
主要变化：
|
||||
|
||||
- 使用“当前模型与 API 参数允许的最高原生质量”，不再用提示词虚构原生 8K。
|
||||
- 固定工业版式显式锁定为 16:9 横版单一连续画布，不再只写语义模糊的“横版”。
|
||||
- 人类角色统一定义为原创虚构电影 VFX 数字演员，不复制现实演员、公众人物或既有影视角色。
|
||||
- 左侧身份特写与右侧三个全身工程视图同时保留，不再使用压低清晰正脸质量的限制。
|
||||
- 负面约束压缩为身份、视图、身体、服装拓扑、摄影材质、多余元素六组。
|
||||
- 身份母版默认空手，剧情道具、武器、羽扇和法器进入独立道具或状态资产。
|
||||
- 新增非人分支，锁定主头部、头部与肢体数量、关节、表面材质、甲胄和标志性损伤。
|
||||
- 非人角色不再被强制套用中年皱纹、法令纹、眼袋、胡须和真人皮肤规则。
|
||||
|
||||
网页复制包的顶层通用负面模板也已同步清理：不再禁止“清晰正脸、可识别脸部特写、高精摄影棚脸”，改为禁止复制现实演员、公众人物或未经授权真人身份，以及禁止生活摄影、商业写真和平台肖像模板。旧角色负面描述如重新注入这五条冲突词，会在编译时被过滤。
|
||||
|
||||
角色资产链中的主锚点、表情锚点、服装锚点、三视图和平台复制文案已统一移除提示词式 `8K` 声明。新请求只描述 Provider 最高原生质量、后续 4K 放大准备和禁止伪细节；历史保存 Prompt 在提交前会把旧 `8K/4K-detail` 营销词正规化为同一可执行口径。
|
||||
|
||||
代码中仍有一类有意保留的例外：只有分镜明确要求肩后、侧后、背影或 Seedance 安全首帧时，关键帧层才允许限制清晰正脸。该规则服务平台预检和指定镜头构图，不属于人物三视图、身份母版或复制总包，禁止跨层复用。
|
||||
|
||||
## 3. 执行硬门
|
||||
|
||||
三视图活动 Prompt 只有同时满足以下条件才可跳过文本复审：
|
||||
|
||||
1. Prompt 分达到当前门槛。
|
||||
2. 使用当前 V4 模板版本。
|
||||
3. 仍是左侧身份特写加右侧正面、严格侧面、背面的旗舰版式。
|
||||
4. 不包含五条脸部质量冲突限制。
|
||||
5. 参考模式与本次请求一致。
|
||||
|
||||
因此，Project #22 当前活动 Prompt Version #102 虽然为 98 分且不含五条冲突词，但仍是 V3 引擎产物，下一次生成不会直接复用，必须按 V4 重新审稿。
|
||||
|
||||
文本审稿模型返回的优化 Prompt 也必须保留 V4 版本和旗舰版式；如果删掉版本、破坏版式或重新引入冲突词，即使模型自报 98 分也不能通过。
|
||||
|
||||
## 4. 历史经验过滤
|
||||
|
||||
数据库当前有 243 条活动三视图优化经验，来源跨越五个 Prompt/QC 引擎版本。经验仍保留用于追溯，但进入新审稿前执行语义过滤：
|
||||
|
||||
- 拒绝 9:16 规则。
|
||||
- 拒绝五条脸部质量冲突限制。
|
||||
- 拒绝把项目角色名写入公共规则。
|
||||
- 拒绝把专属道具、武器、羽扇、手机或法器升级为身份母版必备物。
|
||||
- 拒绝向非人角色注入真人年龄、皱纹、胡须和皮肤规则。
|
||||
- 拒绝向人类角色注入多头、多臂或鬼火结构规则。
|
||||
- 按角色时代、服装颜色和物种过滤古代鞋履、浅色服装等条件规则。
|
||||
- 无角色上下文的纯描述工具只吸收真正跨题材通用的结构经验。
|
||||
|
||||
新审稿产生的 reusable rules 在写入全局经验库前也经过同一过滤，避免污染继续累积。
|
||||
|
||||
## 5. 四个橙色角色卡审计
|
||||
|
||||
| 角色 | 数据状态 | V4 分支 | Prompt 预检 | 资产状态 |
|
||||
| --- | --- | --- | --- | --- |
|
||||
| 诸葛亮 #92 | locked | 人类历史角色 | 16:9、V4、无冲突、无人名串线 | 尚无批准主锚点；旧六图最高 87 分 |
|
||||
| 司马懿 #93 | locked | 人类历史角色 | 16:9、V4、无冲突、无人名串线 | 尚未生成身份母版 |
|
||||
| 蜀军将领 #94 | locked | 人类历史角色 | 16:9、V4、无冲突、无人名串线 | 尚未生成身份母版 |
|
||||
| 九幽鬼将 #95 | locked | 非人多头多臂角色 | 16:9、V4、无冲突、无人名串线 | 尚未生成造型母版 |
|
||||
|
||||
数据净化：
|
||||
|
||||
- #94 的负面描述由点名“复制诸葛亮或司马懿面孔”改为“复制其他主要角色面孔”。
|
||||
- #95 的身份描述由“司马懿鬼道召出”改为“由九幽鬼道召出”，避免另一角色名字进入造型 Prompt。
|
||||
|
||||
四个角色仍是资产计划中的阻断项。Prompt 预检通过不等于图片资产通过；没有生成、视觉硬门和人工审批前，不得进入视频角色元素或正式分镜。
|
||||
|
||||
## 6. 上游基础流程审计
|
||||
|
||||
Project #22 当前七份已确认合同：原著分析、改编圣经、三集计划、第 1 集场景剧本和第 1 集资产计划，未检测到旧项目专属词或 9:16 数据污染。
|
||||
|
||||
资产计划仍保留旧项目素材作为 `manual_review_required` 候选，且 `reuse_decision=create`、`existing_ref=null`。这是可追溯库存，不是自动参考图。新 Asset Planner Prompt 已增加硬规则：候选图的人脸、服装、风格、项目名称和历史 Prompt 不得进入新资产的 `visual_brief`、连续性锁和验收标准。
|
||||
|
||||
基础资产示例已由“同一真实演员式角色身份”改为“同一原创虚构角色资产”，并区分人类数字演员与非人角色结构锁。
|
||||
|
||||
## 7. 验证
|
||||
|
||||
- 三视图模板、CharactersService 复制总包、ImagesService、Production Kernel、资产计划 Prompt 与旧行为保护定向测试：60/60 通过。
|
||||
- ProductionKernelService 资产计划提示词测试新增原创虚构角色断言。
|
||||
- Backend TypeScript 生产构建：通过。
|
||||
- `git diff --check`：通过。
|
||||
- 四个角色 V4 Prompt 本地预检：全部当前版本、16:9、无五条冲突限制、无旧项目人名串线。
|
||||
- 本轮未调用付费图片或视频 Provider。
|
||||
|
||||
## 8. 下一步
|
||||
|
||||
本轮只完成 Prompt 与资产输入层收口，没有改变此前“单画布三视图最高仅 87 分”的真实结论。下一阶段仍应执行分面板路线：身份特写、正面、严格侧面、背面分别生成和质检，再程序化合成 16:9 母版。
|
||||
|
||||
先用诸葛亮做 V4 分面板小样，通过 96+ 总质检后，再依次放行司马懿、蜀军将领和九幽鬼将，避免四个阻断角色同时付费试错。
|
||||
@@ -0,0 +1,118 @@
|
||||
# S+ 人物四面板母版实施与诸葛亮小样报告 V1
|
||||
|
||||
> 实施与验收日期：2026-07-16
|
||||
> 验收项目：`诸葛亮与司马懿斗法`（Project #22 / Character #92）
|
||||
> 当前结论：分面板工程链路成立；首轮真实母版为 A+ 88 分，未达到 S+，不得晋升主锚点
|
||||
|
||||
## 1. 已落地生产路线
|
||||
|
||||
系统不再要求图片模型在一张画布中同时解决四个视图，而是执行：
|
||||
|
||||
```text
|
||||
身份特写 -> 独立视觉质检
|
||||
严格正面 -> 独立视觉质检
|
||||
严格 90 度右向侧面 -> 独立视觉质检
|
||||
严格 180 度背面 -> 独立视觉质检
|
||||
FFmpeg 确定性合成 16:9 母版
|
||||
母版总质检
|
||||
```
|
||||
|
||||
四个面板均使用真实 `gpt-image-2`、`quality=high`、`3840x2160`。最终母版由本地 FFmpeg 合成，不使用生成模型再次绘制，避免在最后一步换脸或改服装。
|
||||
|
||||
## 2. 身份参考链
|
||||
|
||||
本次从旧候选素材 #980 只提取身份线索，随后逐步累积已完成面板：
|
||||
|
||||
| 面板 | CharacterImage | 素材 | 实际参考素材 |
|
||||
| --- | ---: | ---: | --- |
|
||||
| 身份特写 | #151 | #984 | #980 的脸部面板裁切 |
|
||||
| 严格正面 | #152 | #985 | #984、#980 |
|
||||
| 严格侧面 | #153 | #986 | #984、#985、#980 |
|
||||
| 严格背面 | #154 | #987 | #984、#985、#986、#980 |
|
||||
| 程序母版 | #155 | #988 | #984、#985、#986、#987 |
|
||||
|
||||
母版 #988 为真实 3840x2160 PNG，约 10.82 MB；版式宽度为身份特写 1200 px，正面、侧面、背面各 880 px。
|
||||
|
||||
## 3. 真实质量结论
|
||||
|
||||
| 资产 | 视觉分 | 结论 |
|
||||
| --- | ---: | --- |
|
||||
| 身份特写 #984 | 91 | 身份清晰；主体略宽、年龄略老、存在轻微 CG 皮肤感 |
|
||||
| 正面 #985 | 质检 JSON 被旧 2600 token 上限截断；原始返回首项分数为 86 | 图像成立；手部、微材质与现代鞋底是主要问题 |
|
||||
| 侧面 #986 | 88 | 严格右向侧面成立；胸前结构仍略展开，鞋底现代化 |
|
||||
| 背面 #987 | 89 | 严格背面成立；后领被长发遮挡，手部和布料拓扑不足 |
|
||||
| 母版 #988 | **88** | A+；命中现代白色橡胶鞋底一票否决，不可用于 S+ 视频身份锁定 |
|
||||
|
||||
本轮证明“分别生成”明显改善了严格侧面、背面、人物完整裁切和程序版式稳定性，但 S+ 仍取决于跨面板服装拓扑、时代鞋履、手部和年龄一致性，不能只看脸是否相似。
|
||||
|
||||
## 4. 公共模板 V1.1
|
||||
|
||||
公共模板升级为 `character_turnaround_split_panel_v1_1`，吸收本轮通用问题，不写入诸葛亮专属五官或服装：
|
||||
|
||||
- 鞋履必须是角色时代对应的同色软底传统鞋靴。
|
||||
- 禁止白色橡胶中底、运动鞋弧形底、现代休闲鞋头、拉链和工业胶边。
|
||||
- 正、侧、背锁定同一头脚高度、肩宽、腰线、四肢长度和服装层级。
|
||||
- 侧面要求胸腔、腰带和衣襟中线压缩为真实侧面厚度。
|
||||
- 背面要求露出后领中心、背部接缝、后腰带与衣摆拓扑。
|
||||
- 中老年角色在侧背面通过发色、后颈、耳部、手部皮肤与姿态继续保持年龄。
|
||||
- 身份特写安全区由中央约 31% 收紧为 27%，减少母版裁切挤压。
|
||||
- 面板视觉质检 `max_tokens` 从 2600 提高到 5000，避免合法 JSON 被截断。
|
||||
|
||||
## 5. 断点续跑与单面板返修
|
||||
|
||||
接口：
|
||||
|
||||
```text
|
||||
POST /api/characters/:characterId/turnaround-master/generate
|
||||
```
|
||||
|
||||
支持：
|
||||
|
||||
```json
|
||||
{
|
||||
"force": false,
|
||||
"regenerate_image_types": ["turnaround_side_panel"]
|
||||
}
|
||||
```
|
||||
|
||||
系统会复用其余已完成面板，只重新生成指定面板，然后重新合成和质检母版。用户端每个未通过面板提供“只重生此面板”按钮；完整提交参数进入全局 AI 请求检查器。
|
||||
|
||||
## 6. 成本审计
|
||||
|
||||
ProviderLog #1039 至 #1047 的真实成功成本：
|
||||
|
||||
| 类型 | 成本 |
|
||||
| --- | ---: |
|
||||
| 4 张 GPT Image 2 4K 图片 | $1.7386 |
|
||||
| 4 次面板质检 + 1 次母版质检 | $0.4652 |
|
||||
| FFmpeg 程序合成 | $0 |
|
||||
| 合计 | **$2.2038** |
|
||||
|
||||
最初接口回执只汇总 RenderTask 图片成本，低估了视觉质检费用。现已修复为分别返回图片、视觉质检、本地合成和总成本，并附任务 ID 与视觉质检 ProviderLog ID。
|
||||
|
||||
## 7. 额外修复
|
||||
|
||||
- 视觉质检必须信任落盘文件元数据；3840x2160 或 2560x1440 不得因留白误判为非 16:9。
|
||||
- 质检 Provider 失败只新增失败审计，不再把上一轮有效分数和状态覆盖为空。
|
||||
- API 返回上一轮有效质检，同时保留最新失败尝试的状态与错误。
|
||||
- 断点续跑测试确认身份特写、正面不会被重复生成和重复计费。
|
||||
- 指定面板返修测试确认只调用所选面板。
|
||||
|
||||
补跑旧图质检时 OpenAI 返回 429 配额错误，两次失败调用成本均为 0；图片未损坏，原有有效状态已恢复，系统未继续发起付费请求。
|
||||
|
||||
## 8. 验证
|
||||
|
||||
- 相关后端测试：29/29 通过。
|
||||
- Backend 生产构建：通过。
|
||||
- User App 生产构建：通过。
|
||||
- 真实 4K 图片元数据、背面和最终母版已人工查看。
|
||||
- 母版没有被误标为 S+，也没有自动晋升角色主锚点。
|
||||
|
||||
## 9. 下一步放行条件
|
||||
|
||||
待账户配额恢复后，只返修未通过的全身面板，优先处理鞋履、手部和服装拓扑。只有四个子面板和最终母版均达到 96+ 且无一票否决项，才允许：
|
||||
|
||||
```text
|
||||
人工确认 -> 晋升人物母版 -> 生成 6-8 秒角色身份视频 -> 创建 Kling 视频角色元素
|
||||
```
|
||||
|
||||
@@ -0,0 +1,57 @@
|
||||
# S+ 执行桥接与外部资产流程 V1
|
||||
|
||||
## 目标
|
||||
|
||||
允许 S+ 项目在暂不调用图片生成模型的情况下，继续完成“确认场景剧本 -> 确认资产计划 -> 导演镜头执行草案”，然后在外部素材导入后才进入付费生成。
|
||||
|
||||
## 新执行桥
|
||||
|
||||
```text
|
||||
POST /api/production/contracts/:assetPlanContractId/materialize-execution-draft
|
||||
```
|
||||
|
||||
输入：`ShotExecutionSpecV1[]`。
|
||||
|
||||
硬门：
|
||||
|
||||
- 资产计划和场景剧本必须已确认且版本链一致。
|
||||
- 镜号必须连续。
|
||||
- 单镜表演、对白、声音、轴线、验收和负向结果必须通过 `shot_execution_v1` 校验。
|
||||
- 所有逻辑资产引用必须来自已确认资产计划。
|
||||
- 镜头总时长必须严格等于场景剧本时长，每个场次也必须单独对齐。
|
||||
- 已有确认分镜或冻结 Generation Plan 时禁止覆盖。
|
||||
|
||||
## 落地语义
|
||||
|
||||
- 创建或更新 `Episode`。
|
||||
- 保存可审核的 `EpisodeScript` 版本。
|
||||
- 将执行草案物化为 `StoryboardShot`。
|
||||
- `video_status = external_assets_pending`。
|
||||
- `video_prompt = null`。
|
||||
- `active_generation_plan_id = null`。
|
||||
- 不调用 Provider，不产生 AI 费用。
|
||||
|
||||
## 外部资产路线
|
||||
|
||||
```text
|
||||
外部生成角色/场景/道具
|
||||
-> 导入私有素材库
|
||||
-> 人工 QC
|
||||
-> REQ_* 逻辑需求绑定真实 Asset ID
|
||||
-> 镜头资产预检
|
||||
-> 编译 Provider Prompt 和完整请求参数
|
||||
-> 人工对比修订
|
||||
-> 冻结 Generation Plan
|
||||
-> 关键帧/视频生成
|
||||
```
|
||||
|
||||
## 实际验证
|
||||
|
||||
项目 `#22 诸葛亮与司马懿斗法` 已以此流程落地第1集：
|
||||
|
||||
- 9 镜，总时长 60,000ms。
|
||||
- 四场时长严格为 8s / 17s / 16s / 19s。
|
||||
- 所有分镜状态为 `external_assets_pending`。
|
||||
- Generation Plan 为 0，没有伪造已绑定素材。
|
||||
- 生产内核定向测试 24/24 通过，Backend 和 User App 构建通过。
|
||||
|
||||
@@ -0,0 +1,71 @@
|
||||
# S+ 不可变 Generation Plan 实施报告 V1
|
||||
|
||||
> 状态：工程已完成，真实付费小样待验收
|
||||
> 日期：2026-07-15
|
||||
> 适用引擎：`splus_v1`
|
||||
|
||||
## 1. 目标
|
||||
|
||||
每个可生成镜头在关键帧之前冻结唯一执行计划。关键帧、参考资产、角色元素、音色、视频请求、质量门、重试、回退和成本审计共同读取该计划，禁止执行阶段静默换模型或重算资产。
|
||||
|
||||
## 2. 不可变规则
|
||||
|
||||
- 计划使用规范化内容的 SHA-256 作为 `plan_hash`。
|
||||
- 相同输入复用同一修订；输入变化创建下一修订。
|
||||
- 历史修订只读，不执行 `update`。
|
||||
- `StoryboardShot.active_generation_plan_id` 只指向当前活动修订。
|
||||
- `ShotImage`、`VideoClip`、`RenderTask` 保存 `generation_plan_id`，形成结果与成本追踪链。
|
||||
- S+ 正式执行必须存在状态为 `frozen` 的活动计划；旧项目继续走 `legacy_v1`，不强制回填。
|
||||
|
||||
## 3. 冻结内容
|
||||
|
||||
单个计划固定保存：
|
||||
|
||||
- Provider、模型、接口、能力版本、路由理由和回退链。
|
||||
- 推荐分辨率、实际生成分辨率、画幅、时长、原生声音、多镜头和4K候选状态。
|
||||
- 角色/场景/道具参考资产及 Provider 请求装配快照。
|
||||
- 角色元素与逐说话人音色计划。
|
||||
- 关键帧模型、尺寸、质量与参考图上限。
|
||||
- 视频请求、Prompt、质检阈值、重试上限和成本/价格快照。
|
||||
|
||||
## 4. 共同读取链路
|
||||
|
||||
```text
|
||||
镜头分析与路由
|
||||
-> freeze generation_plan
|
||||
-> 关键帧读取资产与关键帧参数
|
||||
-> 视频队列读取 Provider、参数、声音与分辨率
|
||||
-> VideoClip/RenderTask 绑定 plan_id
|
||||
-> QC 读取计划阈值
|
||||
-> 重试读取计划上限与回退链
|
||||
-> TTS/后期读取逐角色音色
|
||||
-> ProviderLog 通过 RenderTask 进入成本审计
|
||||
```
|
||||
|
||||
正常请求不能覆盖冻结 Provider；系统定向修复只能使用计划内已批准的回退链。关键帧缓存也必须与活动计划 ID 一致，避免旧图被新修订误用。
|
||||
|
||||
## 5. 数据与接口
|
||||
|
||||
数据库迁移：`20260715223000_shot_generation_plan_v1`。
|
||||
|
||||
新增接口：
|
||||
|
||||
- `GET /episodes/:episodeId/live-action/generation-plans`
|
||||
- `POST /episodes/:episodeId/live-action/shots/:shotId/generation-plan/freeze`
|
||||
|
||||
镜头、视频片段和任务安全响应均返回对应计划 ID，便于前端和后台展示真实执行来源。
|
||||
|
||||
## 6. 验证
|
||||
|
||||
- Prisma Client 生成、schema 校验和迁移部署通过。
|
||||
- Backend、User App、Admin、Workers 生产构建通过。
|
||||
- Generation Plan 与 AI Router 定向测试 9/9 通过。
|
||||
- 全量后端测试 299 条中 265 通过、34 失败；失败属于既有旧测试桩和历史断言漂移，本阶段新增测试全部通过。
|
||||
- 未触发真实付费生成。
|
||||
|
||||
## 7. 下一步
|
||||
|
||||
1. 活动计划、历史修订与字段级差异查看已完成。
|
||||
2. 版本化模型能力、参数 Schema 和价格注册表已完成并绑定 Generation Plan。
|
||||
3. 下一步把 Kling 元素创建/验证结果纳入供应商绑定，并在计划冻结前硬校验。
|
||||
4. 用一个全新 S+ 项目做单镜头真实验收，核对计划快照、请求日志、QC 与成本是否完全一致。
|
||||
@@ -0,0 +1,95 @@
|
||||
# S+ 模型注册表与 Generation Plan 修订对比实施报告 V1
|
||||
|
||||
> 状态：工程、迁移与本地注册表初始化已完成；真实付费镜头待验收
|
||||
> 日期：2026-07-15
|
||||
> 适用引擎：`splus_v1`
|
||||
|
||||
## 1. 本阶段目标
|
||||
|
||||
把会变化的 Provider 工作配置与正式执行事实分开：Provider 配置仍可编辑，但每次正式冻结计划必须引用发布后不可变的模型能力、参数 Schema 和价格修订。前端能够查看镜头当前生效计划，并比较两个历史修订的真实执行差异。
|
||||
|
||||
## 2. 不可变模型注册表
|
||||
|
||||
新增三类独立版本：
|
||||
|
||||
- `ModelCapabilityVersion`：支持能力、输入上限、时长、分辨率、声音、参考图/视频和官方文档来源。
|
||||
- `ModelParameterSchemaVersion`：字段类型、必填项、枚举、数量上限和参数冲突规则。
|
||||
- `ModelPricingVersion`：币种、计费单位和完整价格规则快照。
|
||||
|
||||
发布规则：
|
||||
|
||||
- 使用规范化内容的 SHA-256 作为 `content_hash`。
|
||||
- 内容相同复用原修订；内容变化创建下一修订。
|
||||
- 三张版本表不提供更新或删除接口。
|
||||
- `ProviderConfig` 是可编辑工作区，不能直接充当历史执行凭证。
|
||||
- 当前 114 个 Provider 已完成首版初始化，三类注册表各 114 条。
|
||||
|
||||
## 3. 参数 Schema 硬门
|
||||
|
||||
计划冻结前会组装最终 `video_request + provider api_payload`，再按当时发布的参数 Schema 校验：
|
||||
|
||||
- 必填参数。
|
||||
- string/number/boolean/array 类型。
|
||||
- 枚举、数值范围、Prompt 长度、数组数量上限。
|
||||
- Kling Omni `video_list` 存在时必须 `sound: off`。
|
||||
- Kling Omni 携带参考视频时，图片数量按更严格上限校验。
|
||||
|
||||
校验失败返回 `MODEL_PARAMETER_SCHEMA_VALIDATION_FAILED`，不会进入视频 Provider 或产生付费调用。
|
||||
|
||||
## 4. Generation Plan 绑定
|
||||
|
||||
`ShotGenerationPlan` 新增：
|
||||
|
||||
- `capability_registry_version_id`
|
||||
- `parameter_schema_version_id`
|
||||
- `pricing_version_id`
|
||||
|
||||
计划同时冻结三个版本键和内容快照。关键帧、视频请求、QC、重试、声音与成本审计继续读取同一计划，Provider 后续修改不会改变历史计划含义。
|
||||
|
||||
## 5. 接口
|
||||
|
||||
新增：
|
||||
|
||||
- `GET /model-registry?provider_code=`：查看已发布版本，需要 `providers:read`。
|
||||
- `POST /admin/model-registry/sync`：按当前 Provider 配置发布或复用版本，需要 `providers:write`。
|
||||
- `GET /episodes/:episodeId/live-action/generation-plans/compare?base_plan_id=&target_plan_id=`：比较同一镜头两个计划修订。
|
||||
|
||||
既有计划列表接口现在返回镜头号、场景名和 `is_active`。
|
||||
|
||||
## 6. 前端
|
||||
|
||||
真人短剧制作台新增“生成计划与修订对比”：
|
||||
|
||||
- 按镜头选择计划历史。
|
||||
- 展示当前生效修订、模型、分辨率、时长、声音、成本与三个注册表版本 ID。
|
||||
- 任选两个修订比较。
|
||||
- 差异按模型路由、能力、参数、价格、素材、声音、关键帧、Prompt、质检和重试分类。
|
||||
|
||||
## 7. 数据库
|
||||
|
||||
迁移：`20260715233000_model_registry_versions_v1`。
|
||||
|
||||
当前：
|
||||
|
||||
- Prisma Model：68 个。
|
||||
- Prisma 迁移：39 个，全部已部署。
|
||||
- 三类注册表各 114 条首版记录。
|
||||
|
||||
## 8. 验证
|
||||
|
||||
- Prisma Client 生成、schema 校验和迁移部署通过。
|
||||
- Backend、User App、Admin 与 Workers 生产构建通过。
|
||||
- 新增注册表与计划修订测试 6/6 通过。
|
||||
- 全量后端测试 303 条中 269 通过、34 失败；失败数与上一基线一致。
|
||||
- 参数冲突、4K合法请求、内容哈希复用和字段级计划差异均有定向测试。
|
||||
- Backend 与 Worker 已受控重启，服务均为 `active`，后端健康检查返回 `ok`。
|
||||
- 未触发真实付费 AI 生成。
|
||||
|
||||
现有 `live-action.service.spec.ts` 仍有 19 条已知旧失败，其余 15 条旧失败分布于旧测试桩和质量策略旧断言；本阶段新增定向测试全部通过。
|
||||
|
||||
## 9. 下一步
|
||||
|
||||
1. 用一个全新 `splus_v1` 镜头做真实单镜验收，核对计划版本、Provider 请求、ProviderLog 和账单。
|
||||
2. 将注册表版本与参数校验结果加入后台 Router 审计。
|
||||
3. 为 Provider 配置保存动作增加“预览待发布差异”，由管理员确认后发布。
|
||||
4. 修复历史 Live Action 测试桩，恢复全量测试基线。
|
||||
@@ -0,0 +1,141 @@
|
||||
# S+ 内核 Phase 0-1 实施报告
|
||||
|
||||
> 日期：2026-07-15
|
||||
> 范围：保护基线、Prompt 去污染、生产合同与硬门
|
||||
> 付费 AI 调用：无
|
||||
> 数据迁移：无
|
||||
> 生产服务重启：无
|
||||
|
||||
## 1. 本轮完成
|
||||
|
||||
### 保护基线
|
||||
|
||||
- 数据库完整逻辑备份：`/www/wwwroot/ai-backups/20260715-splus-phase0/database.sql`
|
||||
- 私有素材归档：`/www/wwwroot/ai-backups/20260715-splus-phase0/storage-private.tar`
|
||||
- 校验文件：`/www/wwwroot/ai-backups/20260715-splus-phase0/SHA256SUMS`
|
||||
- 数据库约 90MB，私有素材约 4.7GB。
|
||||
- 两份备份均通过 SHA-256 回读校验。
|
||||
|
||||
### 生产内核
|
||||
|
||||
新增 `backend/src/production-kernel/`：
|
||||
|
||||
```text
|
||||
contracts/production-contracts.ts
|
||||
validators/production-contract-validators.ts
|
||||
prompts/prompt-rule-registry.ts
|
||||
prompts/prompt-contamination.ts
|
||||
fixtures/neutral-production-fixtures.ts
|
||||
production-kernel.spec.ts
|
||||
legacy-behavior-guard.spec.ts
|
||||
index.ts
|
||||
```
|
||||
|
||||
已定义：
|
||||
|
||||
- `SourceAnalysisSpecV1`
|
||||
- `AdaptationBibleSpecV1`
|
||||
- `EpisodePlanSpecV1`
|
||||
- `SceneScriptSpecV1`
|
||||
- `ShotExecutionSpecV1`
|
||||
- `StageQualityResultV1`
|
||||
- `ShotQcDeltaV1`
|
||||
- `PromptRuleCandidateV1`
|
||||
|
||||
硬门已覆盖：
|
||||
|
||||
- 来源与事实引用；
|
||||
- 改编决策账本；
|
||||
- 开场钩子时间线与本集兑现；
|
||||
- 分集目标、阻力、高潮选择和不可逆变化；
|
||||
- 场景目标、人物策略、阻力、转折和结果；
|
||||
- 中文台词时长预算；
|
||||
- 镜头资产、表演、运镜、声音和验收条件；
|
||||
- 参考图数量与职责；
|
||||
- 首尾帧同空间轴线和运动方向；
|
||||
- 非首镜连续性接力。
|
||||
|
||||
### 去劣取优
|
||||
|
||||
- 建立版本化 Prompt 规则注册表，当前批准 22 条公共/题材规则，另保留 1 条废弃规则作为防回归标记。
|
||||
- 历史规则已按 global、genre、provider、project 分级。
|
||||
- 公共规则可按 stage、genre、provider 条件激活。
|
||||
- 脚本分镜和分集 Prompt 已接入规则注册表。
|
||||
- 新增污染扫描，阻断项目专名、内部数据库 ID、临时 URL 和嵌入素材编号进入公共规则。
|
||||
- 脚本与分集公共链路已清除本轮命中的历史项目人物、地点和终局专名。
|
||||
- 终局质量检查已从特定故事关键词改为通用的冲突结果、主角选择、状态变化和余波。
|
||||
- 镜头目标数量不再增删已确认剧情点。
|
||||
- 删除自动“导演补拍节奏点”。
|
||||
- 删除按说话人自动拆分对白素材的后处理行为。
|
||||
- 无法从已确认剧本提取可追溯动作/台词/反应时，直接阻断，不再生成一套都市会议室兜底剧情。
|
||||
|
||||
详细规则见 `PROMPT_RULE_AUDIT_V1.md`。
|
||||
|
||||
## 2. 验证结果
|
||||
|
||||
| 检查 | 结果 |
|
||||
| --- | --- |
|
||||
| 后端生产构建 | 通过 |
|
||||
| 新内核合同/硬门测试 | 7/7 通过 |
|
||||
| 公共污染与旧行为守卫 | 2/2 通过 |
|
||||
| 保持真实镜头数的脚本回归测试 | 1/1 通过 |
|
||||
| 全仓后端测试 | 248 通过，34 失败，共 282 条 |
|
||||
| 备份 SHA-256 回读 | 通过 |
|
||||
| `git diff --check` | 通过 |
|
||||
|
||||
全仓失败没有在本轮伪装修复。主要仍是：
|
||||
|
||||
- Prisma 新字段/新查询加入后旧 mock 未补齐；
|
||||
- 旧分集样本不满足当前制作蓝图和闭环质量门；
|
||||
- Provider 成本展示文案断言仍是旧格式；
|
||||
- Live Action 的旧参考图预检、BGM/SFX 和导演计划断言漂移。
|
||||
|
||||
审计基线为 238 通过、35 失败；本轮新增测试后为 248 通过、34 失败。
|
||||
|
||||
## 3. Schema 影响
|
||||
|
||||
本轮没有修改 Prisma schema，也没有执行数据库迁移。
|
||||
|
||||
原因：当前工作区已有大量未提交迁移与测试 mock 漂移；先完成可独立验证的合同、验证器和规则清理，避免在同一批次叠加持久化风险。
|
||||
|
||||
Phase 2 前需要评审并落库：
|
||||
|
||||
- 项目 `engine_version` 与生命周期；
|
||||
- 五级合同的版本、状态、输入哈希、来源和质量结果；
|
||||
- Prompt 规则候选、A/B 证据、审核与回滚版本；
|
||||
- Provider 编译请求快照和参考图职责；
|
||||
- 结构化 QC Delta。
|
||||
|
||||
现有 `ProjectPipelineConfig.video_engine_version` 与角色/图片 Prompt 版本字段可复用，但不能替代完整生产合同版本。
|
||||
|
||||
## 4. 尚未清理的隔离区
|
||||
|
||||
以下旧服务仍存在项目专属分支，暂不允许成为 `splus_v1` 公共规则来源：
|
||||
|
||||
- `characters/characters.service.ts`
|
||||
- `images/images.service.ts`
|
||||
- `live-action/live-action.service.ts`
|
||||
- `live-action/prompt-builder.service.ts`
|
||||
|
||||
下一轮必须逐段判断哪些属于历史项目读取兼容、哪些是公共生成逻辑，不能批量替换。
|
||||
|
||||
## 5. 未解决风险
|
||||
|
||||
1. 新合同尚未落库，也尚未成为新项目唯一写路径。
|
||||
2. 公共脚本 Service 仍是大文件，旧 Prompt 文本与新规则并存；本轮只先切断确定有害行为。
|
||||
3. Provider Compiler 和能力档案未实现，模型时长、参考图数量和音频能力仍由旧链路判断。
|
||||
4. 污染扫描已实现并保护公共规则，但还没有覆盖所有 Prompt 生成入口。
|
||||
5. 全仓类型检查仍被旧测试 fixture 类型漂移阻断；生产构建可以通过。
|
||||
6. 没有浏览器 E2E，也没有真实 Provider A/B；本阶段按要求未产生付费调用。
|
||||
|
||||
## 6. Phase 2 建议
|
||||
|
||||
下一阶段只推进“原著分析 -> 改编圣经 -> 分集计划”三段：
|
||||
|
||||
1. 评审生产合同持久化 schema。
|
||||
2. 为新项目建立 `splus_v1` 唯一写入口，旧项目只读。
|
||||
3. 实现 Source Analyst、Adaptation Showrunner、Episode Planner 的阶段请求与 Reviewer Delta。
|
||||
4. 用三个中性样本验证事实引用、改编决策、钩子兑现和跨集状态。
|
||||
5. 只批准其中一集进入 SceneScript，暂不接真实视频生成。
|
||||
|
||||
进入 Phase 2 前，建议先单独处理测试 mock 基线，避免新合同测试与历史失败混在一起。
|
||||
@@ -0,0 +1,152 @@
|
||||
# S+ 内核 Phase 2 实施报告
|
||||
|
||||
> 日期：2026-07-15
|
||||
> 范围：原著分析、改编圣经、分集计划的结构化写路径
|
||||
> 工程状态：已部署，真实新项目内容验收待执行
|
||||
> 付费 AI 调用：无
|
||||
> 数据迁移：`20260715143000_splus_production_contracts_v1`
|
||||
|
||||
## 1. 本轮结论
|
||||
|
||||
Phase 2 的工程链路已经形成，但尚未宣称通过内容生产验收。
|
||||
|
||||
当前系统已经可以安全执行：
|
||||
|
||||
```text
|
||||
连续原文快照
|
||||
-> 原著分析合同
|
||||
-> 改编圣经合同
|
||||
-> 分集计划合同
|
||||
-> 三集连续性检查
|
||||
-> 人工只放行其中一集
|
||||
```
|
||||
|
||||
新链路不会覆盖旧 `StoryBible`、`Episode` 或历史 Prompt。所有结构化结果均版本化保存，审核失败也保留为可诊断草稿。
|
||||
|
||||
## 2. 数据与状态
|
||||
|
||||
### 项目标记
|
||||
|
||||
`Project` 新增：
|
||||
|
||||
- `engine_version`：数据库默认 `legacy_v1`；应用创建的普通新项目写入 `splus_v1`。
|
||||
- `production_lifecycle`：记录来源准备、合同写入、确认、三集检查和单集放行状态。
|
||||
|
||||
直接提示词实验项目继续标记为 `tool_direct_v1`，不伪装成 S+ 正式生产项目。
|
||||
|
||||
迁移后数据库中原有 20 个项目全部为 `legacy_v1`，没有自动迁移、改写或删除历史项目。
|
||||
|
||||
### 新增持久化对象
|
||||
|
||||
- `ProductionSourceSnapshot`：保存不可变原文、章节清单、内容哈希和版本。
|
||||
- `ProductionContract`：保存合同类型、schema 版本、父版本、输入哈希、来源引用、正文、质量结果和下游状态。
|
||||
- `ProductionContractReview`：保存 Reviewer 版本、轮次、问题清单、修复差异和评分。
|
||||
|
||||
当前迁移刚完成，三张新表均为 0 条记录；真实内容只会在用户明确创建新 S+ 项目后写入。
|
||||
|
||||
## 3. 唯一写路径
|
||||
|
||||
### 原著分析
|
||||
|
||||
1. 从项目小说源选择最多 20 个章节。
|
||||
2. 章节号必须连续，单次正文最多 180,000 字。
|
||||
3. 固化不可变来源快照和逐章哈希。
|
||||
4. `SourceAnalysisSpecV1` 必须引用本次快照中的来源。
|
||||
5. 不允许在原著分析阶段提前写改编结论。
|
||||
|
||||
### 改编圣经
|
||||
|
||||
1. 必须绑定一个已确认的原著分析版本。
|
||||
2. 改编决策必须记录操作、来源、原因、影响、连续性风险和批准状态。
|
||||
3. 未批准的改编决策不能被分集计划使用。
|
||||
4. 修改时创建新版本，不覆盖已确认版本。
|
||||
|
||||
### 分集计划
|
||||
|
||||
1. 必须绑定一个已确认的改编圣经版本。
|
||||
2. 第 2 集以后要求上一集已确认。
|
||||
3. 每集必须包含开场钩子、目标、阻力、升级、高潮选择、不可逆变化和集尾钩子。
|
||||
4. 连续三集必须同属一个改编版本、集号连续，并严格继承上一集退出状态。
|
||||
5. 三集通过连续性检查后仍不会自动进入剧本；必须人工选择一集执行 `release`。
|
||||
|
||||
## 4. Reviewer 与修复
|
||||
|
||||
- Writer 负责输出完整结构化合同。
|
||||
- 确定性验证器负责字段、来源、批准状态和跨集状态硬门。
|
||||
- Reviewer 使用版本号记录，只输出问题与 `StageReviewDeltaV1`，不静默重写正文。
|
||||
- 失败结果保存为 `draft + blocked`，通过硬门的结果保存为 `validated`。
|
||||
- 确认时重新执行审核；同一范围旧确认版本会被标记为 `superseded`。
|
||||
|
||||
## 5. Prompt 构建
|
||||
|
||||
新增三个阶段的干净模板：
|
||||
|
||||
- Source Analyst
|
||||
- Adaptation Showrunner
|
||||
- Episode Planner
|
||||
|
||||
公共模板与项目正文分离，运行时才注入来源快照、已确认父合同和上一集状态。请求预览可在付费调用前查看和复制；本轮没有在 UI 暴露一键付费生成入口。
|
||||
|
||||
## 6. API 与界面
|
||||
|
||||
新增 `ProductionKernelModule` 及接口，覆盖：
|
||||
|
||||
- 创建/查询来源快照。
|
||||
- 保存、查询、评审和确认合同。
|
||||
- 预览阶段 Prompt。
|
||||
- 三集连续性检查。
|
||||
- 放行一个分集计划进入下一阶段。
|
||||
- 保留受控的阶段 Provider 调用能力，但本轮未触发。
|
||||
|
||||
用户端新增 `SplusProductionPipeline.vue`：
|
||||
|
||||
- 原著分析、改编圣经、分集计划三个阶段标签。
|
||||
- JSON 导入、确定性校验、版本列表和问题定位。
|
||||
- Prompt 预览与复制。
|
||||
- 评审、确认、三集检查和单集放行。
|
||||
|
||||
`splus_v1` 项目不再显示旧 StoryBible/旧分集写入口；历史项目仍走旧页面读取。旧 `StoryBiblesService` 和 `EpisodesService` 的写方法也增加了后端守卫，不能靠直接调用 API 绕过界面。
|
||||
|
||||
## 7. 部署与验证
|
||||
|
||||
### 部署
|
||||
|
||||
- 数据库和私有素材备份继续使用 Phase 0 已校验备份。
|
||||
- Prisma 迁移从 33 个增加到 34 个，并成功部署。
|
||||
- 后端已受控重启。
|
||||
- `GET /api/health` 返回 `status: ok`。
|
||||
|
||||
### 自动验证
|
||||
|
||||
| 检查 | 结果 |
|
||||
| --- | --- |
|
||||
| Phase 2 合同/Service 定向测试 | 13/13 通过 |
|
||||
| 后端生产构建 | 通过 |
|
||||
| 用户端生产构建 | 通过 |
|
||||
| Prisma schema 校验 | 通过 |
|
||||
| 数据库迁移 | 34/34 已部署 |
|
||||
| 后端全量测试 | 254 通过，34 失败，共 288 条 |
|
||||
|
||||
34 条失败与本轮开始前的既有失败面一致，主要是旧测试 mock 未补齐、旧质量断言和当前实现漂移。本轮没有批量改断言掩盖问题。
|
||||
|
||||
## 8. 尚未完成
|
||||
|
||||
1. 尚未选择一部全新项目和连续故事段实际写入三阶段合同。
|
||||
2. 尚未产出并确认连续三集，也未执行“只放行一集”的真实内容验收。
|
||||
3. 尚未开放前端一键付费阶段生成。
|
||||
4. 尚未进入 `SceneScriptSpecV1` 场景剧本写路径。
|
||||
5. 旧角色、记忆等下游页面仍可见，后续需要按阶段状态进一步收口。
|
||||
6. 全仓 34 条历史测试失败仍需作为独立基线修复。
|
||||
|
||||
## 9. 进入 Phase 3 的条件
|
||||
|
||||
只有完成以下验收，才进入场景剧本：
|
||||
|
||||
1. 新建一个 `splus_v1` 项目。
|
||||
2. 选取一个连续故事段并生成来源快照。
|
||||
3. 原著分析与改编圣经通过审核并确认。
|
||||
4. 连续三集分集计划通过状态继承检查。
|
||||
5. 人工只放行其中一集。
|
||||
6. 保存本次 Prompt、合同版本、Reviewer 问题和人工判断作为首个 Phase 2 样本。
|
||||
|
||||
在此之前不接视频生成，也不以“页面可操作”代替内容质量验收。
|
||||
@@ -0,0 +1,78 @@
|
||||
# Work 同步清单 V11
|
||||
|
||||
> 批次：`WORK_SYNC_2026-07-19_V11`
|
||||
> 生成日期：2026-07-19
|
||||
> 根目录：`docs/work-sync/`
|
||||
> 校验算法：SHA-256
|
||||
|
||||
## 1. 同步目录文件
|
||||
|
||||
| 文件 | 类型 | 来源/维护方式 | SHA-256 |
|
||||
| --- | --- | --- | --- |
|
||||
| `00_文档索引.md` | 索引 | 本批次更新 | `995140fcb1d749a531149ba46ceaf073f3cd2fd37f5af6a001348f807d3190da` |
|
||||
| `01_项目现状/PROJECT_STATUS_V1.md` | 不可变状态快照 | 根目录同名文件原样复制 | `23d9f0669b54a1bb5d56ba930376c1fe8ec4d08326dbfc752cad252cffca1226` |
|
||||
| `02_架构设计/SYSTEM_ARCHITECTURE_V1.md` | 当前设计 | 本批次按代码现实生成 | `f2efe8ba4ccf6e889547e296e0663407d780bf9e0c7c0c60834e9fd1acb6a730` |
|
||||
| `03_小说引擎/NOVEL_ENGINE_V1.md` | 当前设计 | 本批次按代码现实生成 | `1f8ba7e73cced96efaf9dfb609fee17ea15c1b4f5a4fbb38d1f7f120aba68cc1` |
|
||||
| `04_短剧引擎/DRAMA_ENGINE_V1.md` | 当前设计 | 增补16:9与角色元素执行规则 | `81c6fa3a199000e4f2ebe606a69725e824bd8e2845ac6fba9e17b67388fb042f` |
|
||||
| `04_短剧引擎/AI_VIDEO_TEST_LESSONS_V1.md` | 生产经验快照 | 根目录 `AI_VIDEO_TEST_LESSONS.md` 原样复制 | `a697a77dbff0f42bcf9d31e3cc5455289df1f79f0e2f3a68744dc3a25c405a4c` |
|
||||
| `05_AI流水线/AI_PIPELINE_V1.md` | 当前设计 | 增补角色元素 Preflight 与请求绑定 | `06987b334efc26de9209aa7710d871c95039b9ea99d130c1821bd4a85f40961f` |
|
||||
| `06_数据库/DATABASE_CURRENT_V1.md` | 当前设计 | 增补角色供应商绑定与新注册表统计 | `6359ea8f58a1db5cc83667bb09d71a87130f9d77faec486ecb090dd8c907bb07` |
|
||||
| `07_版本记录/CHANGELOG.md` | 追加记录 | 追加 V2 目标流水线和现状流程审计 | `67a708701f630267c24a984433585b1ea16323027ddc70e77947e74c4c684387` |
|
||||
| `08_维护规范/WORK_SYNC_PROTOCOL.md` | 维护规范 | 本批次生成 | `fe70b955f43b350ca78429a0a5cb86c6a19dffee2aecfa978d4463c30973addf` |
|
||||
| `08_维护规范/DOCUMENT_TEMPLATE.md` | 模板 | 本批次生成 | `90dba248b7e06e791d3f3e68729500f1319cf9ff7ea4439e554afb4a03c6676a` |
|
||||
| `99_历史设计/README.md` | 历史隔离说明 | 本批次生成 | `2882ed0f46e136e641830eb1045130b3e14b9faded3f3d2abfb57a833fe8f37e` |
|
||||
| `README.md` | 使用说明 | 本批次更新 | `9c61886a2b973aaf994b59cc8d0c3a75b39bf1531ab902b67e8efbc6359fccfb` |
|
||||
| `S_PLUS_BATCH_AUTOMATED_PRODUCTION_PIPELINE_V2.md` | 目标流程规范 | 批量自动化与 S+ 唯一目标流程 | `4356c36dab9caa389b3b1768888d7ba4b6adccaee60ff7c8b23f1b0572864eac` |
|
||||
| `S_PLUS_PRODUCTION_FLOW_AUDIT_V1.md` | 现状流程审计 | 按当前代码、数据库和项目 #22 生成 | `7b0d1f29cf3a6514321b191c86c4d6a2f5894dedfc3da4432aabf603d561c527` |
|
||||
| `S_PLUS_SHORT_DRAMA_CODEX_OPTIMIZATION_V1_1.md` | 当前目标架构 | 生产画幅收敛为16:9 | `811afabeed20fbad99df20c051409d76f3918599160cbe187f9612a9b51968b7` |
|
||||
| `PROMPT_RULE_AUDIT_V1.md` | Prompt 规则审计 | Phase 0.5 审计结果 | `f655fa6b81c60bafbc1641477c40d3eb4bbce34ed351d24d94028c5745e5365d` |
|
||||
| `SPLUS_PHASE_0_1_IMPLEMENTATION_REPORT.md` | 实施报告 | Phase 0-1 代码与验证记录 | `2b865ccc4c4fdaebdd26be9f19e69bccde418d2792e9ca4cde9cdfdda80b6223` |
|
||||
| `SPLUS_PHASE_2_IMPLEMENTATION_REPORT.md` | 实施报告 | Phase 2 代码、迁移、部署与验证记录 | `bae06ed1d38fab73f88d1a1747a98bfaeacecfe4390090f25933d04f8d76db4b` |
|
||||
| `KLING_S_PLUS_MODEL_ROUTING_SPEC_V1.0.md` | 当前模型路由规范 | 统一16:9参数、尺寸与母版策略 | `e3b5bfa2513e98392b259e16a1d7fd1afea12f41b463c42b2bb15e56b4dd0fe0` |
|
||||
| `KLING_V3_OMNI_API_UPDATE_V1.md` | 官方能力快照 | 增补横屏与视频角色元素规则 | `98357cd2443b100f00d1138363b3d0e3919072e561bb0ab34f7cf4af3dd01ba1` |
|
||||
| `LANDSCAPE_CHARACTER_ELEMENT_IMPLEMENTATION_REPORT_V1.md` | 实施报告 | 本批次代码、迁移、测试与部署事实 | `ac181c79fab41e0344dc25b07105c60798fbba05cd302ac803c2449ef7a66871` |
|
||||
| `SPLUS_GENERATION_PLAN_IMPLEMENTATION_REPORT_V1.md` | 实施报告 | Generation Plan 数据、执行、测试与后续记录 | `b4eb98e9c8d13a9cd753459d3ccf30bd7d68c3a5325a205426146104b7a10360` |
|
||||
| `SPLUS_MODEL_REGISTRY_AND_PLAN_DIFF_IMPLEMENTATION_REPORT_V1.md` | 实施报告 | 注册表、参数硬门、修订对比与部署验证 | `dafa7734315d1bfb61b9a522e55c480b306e892afbb89b1697a9c9f2395b4135` |
|
||||
| `SPLUS_CHARACTER_TURNAROUND_ITERATION_REPORT_V1.md` | 真实验收报告 | 补充 V4 Prompt 审计引用，不改写历史成图分数 | `25a2353e0cb72f08f949430ba9db063af9fb994e7908333a8c0cfad811475ee0` |
|
||||
| `SPLUS_CHARACTER_TURNAROUND_PROMPT_V4_AUDIT.md` | Prompt 与资产输入审计 | 本批次按代码、数据库和四角色实际输入生成 | `6386fbd02ec0317a1b1ca8dd3ff5e6dadb27c5f9bc99dab95dae6ba32cd5e27a` |
|
||||
| `AI_REQUEST_INSPECTOR_IMPLEMENTATION_REPORT_V1.md` | 实施报告 | 用户端与管理端共享 AI 请求参数及执行证据抽屉 | `f495b0569e820edd71f293c57777881772c0e2ee177efd52bb53f70ac4ca4fb5` |
|
||||
| `SPLUS_CHARACTER_TURNAROUND_SPLIT_PANEL_IMPLEMENTATION_REPORT_V1.md` | 实施与真实验收报告 | 四面板独立生成质检、断点续跑、单面板返修、4K母版与诸葛亮小样 | `a5800fd3a789b3a1c9ba32c6194e03b9ee283b61af053f455edf2667f9b62fb1` |
|
||||
| `SPLUS_EXECUTION_BRIDGE_EXTERNAL_ASSET_WORKFLOW_V1.md` | 实施报告 | 确认资产计划到导演分镜草案的外部资产等待桥接 | `12cf606e59c8370b71fedab3ada9844a5d037b60ba9a1cd6f51af1e7620d1ff3` |
|
||||
| `S_PLUS_SHORT_DRAMA_CODEX_OPTIMIZATION_V1.md` | 本地追溯输入 | 已由 V1.1 取代，不默认上传 | `ac40820de9eea05b74e072a930ee77181be5ad15e99346eaff3a8173e5b7c888` |
|
||||
| `豆包讨论.txt` | 本地追溯输入 | 结论已吸收，不默认上传 | `fb180e8e96d454be8b5ac1c7fe49edda64f6cf79ac79826e4914657ab35945a2` |
|
||||
|
||||
`SYNC_MANIFEST.md` 不记录自身校验和，因为写入校验和会改变文件本身。
|
||||
|
||||
## 2. 完整性检查
|
||||
|
||||
在仓库根目录执行：
|
||||
|
||||
```bash
|
||||
find docs/work-sync -type f ! -name SYNC_MANIFEST.md -print0 \
|
||||
| sort -z \
|
||||
| xargs -0 sha256sum
|
||||
```
|
||||
|
||||
校验结果应与上表一致。文档内容变化后，必须更新对应校验和、`CHANGELOG.md` 和批次号。
|
||||
|
||||
## 3. 上传状态
|
||||
|
||||
| 项目 | 状态 |
|
||||
| --- | --- |
|
||||
| 文档生成 | 已完成 |
|
||||
| 敏感信息扫描 | 已完成，未发现凭据或私有连接信息 |
|
||||
| 文件一致性验证 | 已完成，31 个受校验文件全部匹配 |
|
||||
| 默认上传范围 | 29 个；排除两份本地追溯输入 |
|
||||
| 上传 Work | 未执行 |
|
||||
| Work 批次标记 | 未执行 |
|
||||
|
||||
## 4. 上传完成后记录
|
||||
|
||||
```text
|
||||
Work 名称：AI 内容生产平台
|
||||
上传批次：WORK_SYNC_2026-07-19_V11
|
||||
上传时间：
|
||||
上传人：
|
||||
缺失/跳过文件：
|
||||
Work 中的生效说明：
|
||||
```
|
||||
@@ -0,0 +1,858 @@
|
||||
# S+ 批量自动化短剧生产流水线 V2
|
||||
|
||||
> 文档类型：目标流程与实施基线
|
||||
> 状态：当前目标规范；P0 执行门禁与 Scene Geography 导演硬门已落地，完整流水线尚未全部实现
|
||||
> 适用范围：所有新建 `splus_v2` 项目，统一 16:9 横屏
|
||||
> 核心目标：批量生产、自动化闭环、异常驱动人工介入、S+ 质量可追溯
|
||||
> 前置审计：`S_PLUS_PRODUCTION_FLOW_AUDIT_V1.md`
|
||||
> P0 落地记录：`S_PLUS_P0_EXECUTION_GATES_IMPLEMENTATION_V1.md`
|
||||
> 场景地理落地记录：`S_PLUS_SCENE_GEOGRAPHY_BLOCKING_IMPLEMENTATION_V1.md`
|
||||
|
||||
## 0. 最终决策
|
||||
|
||||
新流程不再以“能调用模型并合并视频”为完成标准，而以以下五项同时成立为完成标准：
|
||||
|
||||
1. 一部作品可以按集、场、镜形成可恢复的任务 DAG。
|
||||
2. 正常镜头无需人工改 Prompt，异常镜头只返修差异。
|
||||
3. 任何付费生成都读取已批准资产和可追溯执行计划。
|
||||
4. 任何未通过质量门的素材都不能被选中、合并或发布。
|
||||
5. 用户只看到制作流程，工程合同和 Provider 参数默认收进高级抽屉。
|
||||
|
||||
这是一条“真人剧组生产逻辑 + AI 自动执行”的流水线，不是旧页面步骤的改名。
|
||||
|
||||
## 1. 成功指标
|
||||
|
||||
### 1.1 批量生产
|
||||
|
||||
- 同一项目支持连续多集生产。
|
||||
- 项目、集、场、镜和资产均可独立暂停、恢复、返修和重跑。
|
||||
- 相同角色、场景和道具只生产一次主母版，跨集复用。
|
||||
- 独立镜头可并行执行，同场连续镜头按依赖顺序执行。
|
||||
- 上游局部修改只失效受影响的下游，不全项目重跑。
|
||||
|
||||
### 1.2 自动化
|
||||
|
||||
- 自动生成阶段合同、制作拆解、镜头执行规格和 Provider 请求。
|
||||
- 自动完成确定性校验、风险分级、模型路由、预算预检和任务排队。
|
||||
- 自动完成低风险素材的 QC、定向返修、候选比较和合并准备。
|
||||
- 人工只处理创作决策、高风险镜头、边界分数和最终发布。
|
||||
|
||||
### 1.3 S+ 质量
|
||||
|
||||
- S+ 不由单一总分决定。
|
||||
- 所有硬门必须通过。
|
||||
- 身份、空间、动作、台词、声音和连续性关键维度均有证据。
|
||||
- 自动评分必须经过真实样本和人工盲评校准。
|
||||
- 不宣称外部平台官方等级，S+ 是平台内部生产标准。
|
||||
|
||||
### 1.4 成本与审计
|
||||
|
||||
- 每个付费请求都有输入版本、资产 ID/hash、Prompt、参数、模型、价格版本和实际成本。
|
||||
- 项目、集、镜分别设置预算上限和自动执行额度。
|
||||
- 预算内的已批准批次可自动执行；超预算、模型降级或高风险请求进入人工确认。
|
||||
- 计划请求、选择请求和实际发送请求必须分层展示。
|
||||
|
||||
## 2. 真人剧组映射
|
||||
|
||||
| 真人剧组阶段 | AI 平台阶段 | 主要产物 |
|
||||
| --- | --- | --- |
|
||||
| 项目开发 | 项目与原著 | 原文快照、项目规格、版权状态 |
|
||||
| 编剧开发 | 剧本开发、分集规划、分集剧本 | 改编规则、分集结构、锁定剧本 |
|
||||
| 剧本拆解 | 制作拆解 | 角色、状态、场景、道具、服装、VFX、声音清单 |
|
||||
| 选角、美术、勘景 | 资产制作 | 角色/场景/道具母版、元素和声线 |
|
||||
| 导演、摄影、预演 | 导演分镜 | 空间调度、镜头表、分镜和关键帧 |
|
||||
| 拍摄计划 | 拍摄准备 | 执行计划、参数、成本和任务 DAG |
|
||||
| 正式拍摄 | 分镜拍摄 | 视频候选、现场声音、单镜 QC |
|
||||
| 剪辑、声音、视效 | 剪辑后期 | 粗剪、精剪、字幕、BGM、SFX、UI、调色 |
|
||||
| 审片、交付 | 成片交付 | 技术 QC、叙事 QC、批准版本和导出 |
|
||||
|
||||
## 3. 用户端唯一流程
|
||||
|
||||
用户端只显示以下十步：
|
||||
|
||||
```text
|
||||
0 项目与原著
|
||||
1 剧本开发
|
||||
2 分集规划
|
||||
3 分集剧本
|
||||
4 制作拆解
|
||||
5 前期筹备
|
||||
6 拍摄准备
|
||||
7 分镜拍摄
|
||||
8 剪辑后期
|
||||
9 成片交付
|
||||
```
|
||||
|
||||
内部的 Source Analysis、Adaptation Bible、Generation Plan、Model Registry、Parameter Schema 和 Pricing Version 不作为顶级步骤。
|
||||
|
||||
### 3.1 页面分组
|
||||
|
||||
```text
|
||||
开发：0-3
|
||||
前期：4-6
|
||||
生产：7
|
||||
后期：8-9
|
||||
```
|
||||
|
||||
### 3.2 每步固定展示
|
||||
|
||||
每一步只回答五个问题：
|
||||
|
||||
1. 输入是什么。
|
||||
2. 这一阶段产出什么。
|
||||
3. 当前通过、阻断和待人工数量。
|
||||
4. 用户现在需要做什么。
|
||||
5. 下一步何时自动开始。
|
||||
|
||||
所有 AI 请求、合同 JSON、Provider 路由、成本和差异放进“高级信息 / 完整生成请求”右侧抽屉。
|
||||
|
||||
## 4. 两种剧本路线
|
||||
|
||||
平台不能用一套顺序同时处理短篇完整故事和长篇连载小说。
|
||||
|
||||
### 4.1 短篇完整故事
|
||||
|
||||
适合单个完整故事拆成少量短集：
|
||||
|
||||
```text
|
||||
原文
|
||||
-> 完整改编总剧本
|
||||
-> 项目级资产粗提取
|
||||
-> 分集切分
|
||||
-> 分集剧本锁定
|
||||
-> 分集级精确制作拆解
|
||||
```
|
||||
|
||||
完整总剧本是唯一叙事母版，分集只切分和局部节奏调整，不能静默重写故事。
|
||||
|
||||
### 4.2 长篇连载小说
|
||||
|
||||
适合长小说、季播和持续生产：
|
||||
|
||||
```text
|
||||
原文范围快照
|
||||
-> 原著分析
|
||||
-> 改编圣经/季纲
|
||||
-> 分集规划
|
||||
-> 分集剧本
|
||||
-> 分集级制作拆解
|
||||
-> 项目资产库增量合并
|
||||
```
|
||||
|
||||
长篇项目不得先生成全季逐句对白剧本，以免上下文、成本和连续性失控。
|
||||
|
||||
### 4.3 路线确认
|
||||
|
||||
项目创建时系统可以建议路线，但必须由用户确认：
|
||||
|
||||
```text
|
||||
短篇完整故事
|
||||
长篇连载小说
|
||||
现成分集剧本
|
||||
```
|
||||
|
||||
路线一旦进入正式制作，只能通过版本迁移变更，不能在中途静默切换。
|
||||
|
||||
## 5. 十步生产流程
|
||||
|
||||
### Step 0：项目与原著
|
||||
|
||||
输入：
|
||||
|
||||
- 小说、故事或现成剧本。
|
||||
- 项目类型、目标集长、画幅、题材和预算。
|
||||
- 版权与授权信息。
|
||||
|
||||
系统自动：
|
||||
|
||||
- 创建不可变原文快照和内容 hash。
|
||||
- 建立章节、段落和来源引用索引。
|
||||
- 检查缺页、乱码、重复和明显格式问题。
|
||||
- 建议短篇或长篇路线。
|
||||
|
||||
人工门：确认来源、生产路线和项目规格。
|
||||
|
||||
产物：`SourceSnapshot`、`ProjectProductionProfile`。
|
||||
|
||||
### Step 1：剧本开发
|
||||
|
||||
系统自动：
|
||||
|
||||
- 原著事实分析。
|
||||
- 改编目标、题材承诺、人物弧光和故事主线。
|
||||
- 短篇模式生成完整改编总剧本。
|
||||
- 长篇模式生成改编圣经和季级故事结构。
|
||||
|
||||
必须单独展示的高影响决策：
|
||||
|
||||
- 新增剧情。
|
||||
- 删除剧情。
|
||||
- 调换顺序。
|
||||
- 合并角色。
|
||||
- 改变人物动机或结局。
|
||||
|
||||
人工门：逐项批准高影响改编决策，不能只确认整份 JSON。
|
||||
|
||||
产物：`SourceAnalysisSpec`、`AdaptationBibleSpec`、短篇模式的 `MasterScriptSpec`。
|
||||
|
||||
### Step 2：分集规划
|
||||
|
||||
系统自动：
|
||||
|
||||
- 根据故事转折而不是固定字数拆集。
|
||||
- 计算每集目标、阻力、高潮、不可逆变化和集尾钩子。
|
||||
- 检查连续三集的入口/出口状态。
|
||||
- 避免连续重复相同钩子模式。
|
||||
|
||||
人工门：批量审核集卡，批准进入分集剧本。
|
||||
|
||||
产物：版本化 `EpisodePlanSpec[]`。
|
||||
|
||||
### Step 3：分集剧本
|
||||
|
||||
系统自动：
|
||||
|
||||
- 生成可读、可演、可拍、可听的完整分集剧本。
|
||||
- 计算中文对白时长、动作时长和场景总时长。
|
||||
- 检查人物声音、动机、潜台词和上下集连续性。
|
||||
- 对照原文和已批准改编决策，阻断擅自增删。
|
||||
|
||||
人工门：以完整剧本阅读器审核并锁定每集剧本。
|
||||
|
||||
锁定后修改必须产生新版本，并计算影响范围。
|
||||
|
||||
产物：`SceneScriptSpec`、`ScriptApproval`。
|
||||
|
||||
### Step 4：制作拆解
|
||||
|
||||
这是 AI 版剧组“剧本拆解”，不是生成图片。
|
||||
|
||||
系统自动提取：
|
||||
|
||||
- 角色身份。
|
||||
- 角色状态、年龄阶段、服装、妆发、伤势和情绪。
|
||||
- 场景、时间、天气、光线和空间结构。
|
||||
- 道具、持有人、尺寸、材质和交互方式。
|
||||
- 神兽、怪物、法阵、召唤物和其他 VFX 实体。
|
||||
- 群演、军队、车辆、动物和环境组件。
|
||||
- 对白、声线、环境声、拟音、音乐和 UI/字幕需求。
|
||||
|
||||
系统执行两级去重：
|
||||
|
||||
```text
|
||||
项目级身份资产
|
||||
分集/场景级状态资产
|
||||
```
|
||||
|
||||
自动分类：
|
||||
|
||||
```text
|
||||
必须制作母版
|
||||
可复用已有母版
|
||||
只需 Prompt 描述
|
||||
交给后期制作
|
||||
```
|
||||
|
||||
人工门：只审核冲突、重复和高成本资产，不逐条手工确认普通条目。
|
||||
|
||||
产物：`ProductionBreakdownSpec`、`AssetRequirementManifest`。
|
||||
|
||||
### Step 5：前期筹备
|
||||
|
||||
本步骤采用双轨并行，不强制资产和分镜完全串行。
|
||||
|
||||
#### A. 资产轨
|
||||
|
||||
```text
|
||||
角色身份母版
|
||||
-> 角色造型/状态母版
|
||||
-> 角色元素源视频
|
||||
-> Provider element_id 和声线绑定
|
||||
```
|
||||
|
||||
```text
|
||||
场景概念
|
||||
-> 场景空间母版
|
||||
-> 时间/天气/破坏状态版本
|
||||
```
|
||||
|
||||
```text
|
||||
道具概念
|
||||
-> 正式道具母版
|
||||
-> 尺寸和交互规则
|
||||
```
|
||||
|
||||
每类资产使用不同视觉 QC，不再只检查数据库是否有图片。
|
||||
|
||||
#### B. 导演轨
|
||||
|
||||
```text
|
||||
场景地理与调度
|
||||
-> 粗镜头表
|
||||
-> 表演/摄影/声音设计
|
||||
-> 分镜执行规格
|
||||
```
|
||||
|
||||
场景地理必须明确：
|
||||
|
||||
- 人物和阵营归属。
|
||||
- 固定方位和屏幕方向。
|
||||
- 视线和动作方向。
|
||||
- 攻击起点、路径和落点。
|
||||
- 180 度轴线与允许越轴方式。
|
||||
- 同场可用机位。
|
||||
|
||||
双轨合流条件：
|
||||
|
||||
- 镜头引用的正式资产已批准，或明确使用占位资产且不得进入付费视频。
|
||||
- 分镜空间、动作、时长和声音规格已通过。
|
||||
- 资产状态与镜头要求没有冲突。
|
||||
|
||||
产物：`AssetApproval`、`SceneGeographySpec`、`ShotExecutionSpec[]`。
|
||||
|
||||
### Step 6：拍摄准备
|
||||
|
||||
系统自动：
|
||||
|
||||
- 按镜头风险选择生成策略。
|
||||
- 生成关键帧、首尾帧或多图预演方案。
|
||||
- 编译 Shot Intent Plan。
|
||||
- 对关键帧做身份、空间、动作和构图 QC。
|
||||
- 生成整集关键帧联系表。
|
||||
- 批量展示实际参考资产、模型、参数、元素、音色和成本。
|
||||
|
||||
关键帧状态：
|
||||
|
||||
```text
|
||||
generated_candidate
|
||||
-> qc_passed
|
||||
-> approved
|
||||
-> locked_for_video
|
||||
```
|
||||
|
||||
只有批准后的关键帧才能编译不可变 `GenerationExecutionPlan`。
|
||||
|
||||
人工门：
|
||||
|
||||
- 低风险且 96+ 的关键帧可按批次批准。
|
||||
- 中风险以联系表批审。
|
||||
- 高风险镜头必须逐镜批准。
|
||||
|
||||
产物：`ShotIntentPlan`、`KeyframeApproval`、`GenerationExecutionPlan`。
|
||||
|
||||
### Step 7：分镜拍摄
|
||||
|
||||
系统自动：
|
||||
|
||||
- 按任务 DAG 和 Provider 并发限制提交。
|
||||
- 生成视频候选，不自动选中。
|
||||
- 抽帧、读取视频、转写音频并对照镜头规格做 QC。
|
||||
- 失败时按差异修 Prompt、参考图、时长或路由。
|
||||
- 在预算和重试上限内自动恢复。
|
||||
|
||||
视频候选状态：
|
||||
|
||||
```text
|
||||
generated_candidate
|
||||
-> qc_passed
|
||||
-> approved
|
||||
-> selected
|
||||
-> merge_ready
|
||||
```
|
||||
|
||||
人工门：只处理高风险、边界分数、候选难分和自动返修耗尽的镜头。
|
||||
|
||||
产物：`VideoCandidate`、`ShotQcDelta`、`SelectedClip`。
|
||||
|
||||
### Step 8：剪辑后期
|
||||
|
||||
系统自动：
|
||||
|
||||
- 按镜头入点、出点和声音桥生成粗剪。
|
||||
- 检查漏镜、重复镜、黑帧、卡帧和时长偏差。
|
||||
- 生成转场、字幕、UI、BGM、SFX、环境音和响度时间线。
|
||||
- 对对白优先级、BGM 压限和字幕安全区做确定性检查。
|
||||
- 生成精剪候选。
|
||||
|
||||
声音分工：
|
||||
|
||||
- 视频原生音频负责对白、现场动作和必要环境声。
|
||||
- 后期负责 BGM、补充 SFX、系统提示音、字幕和 UI。
|
||||
- 不让视频模型生成需要精确显示的文字。
|
||||
|
||||
人工门：整集粗剪审核和节奏调整。
|
||||
|
||||
产物：`EditDecisionList`、`PostProductionPlan`、`RenderedCandidate`。
|
||||
|
||||
### Step 9：成片交付
|
||||
|
||||
系统自动：
|
||||
|
||||
- 技术 QC：分辨率、帧率、音轨、响度、黑帧、编码和文件完整性。
|
||||
- 叙事 QC：剧情是否完整、台词是否完整、镜头是否错序。
|
||||
- 连续性 QC：角色、场景、道具、方向和声音是否漂移。
|
||||
- 发布 QC：字幕、敏感内容、版权、封面和交付格式。
|
||||
|
||||
人工门：最终成片批准。
|
||||
|
||||
产物：`FinalQcReport`、`ReleaseApproval`、交付文件。
|
||||
|
||||
## 6. 风险分级与候选策略
|
||||
|
||||
批量生产不能每镜都生成三份，也不能每镜都人工审批。
|
||||
|
||||
### 6.1 低风险镜头 L1
|
||||
|
||||
特征：
|
||||
|
||||
- 单人物或无人物。
|
||||
- 无对白或短句。
|
||||
- 固定场景、轻动作、无复杂 VFX。
|
||||
- 不承担关键身份首次建立。
|
||||
|
||||
策略：
|
||||
|
||||
- 默认 1 个候选。
|
||||
- 自动 QC 96+ 且无硬失败可自动批准。
|
||||
- 失败后最多 1 次定向返修。
|
||||
|
||||
### 6.2 中风险镜头 L2
|
||||
|
||||
特征：
|
||||
|
||||
- 双人对话。
|
||||
- 明确道具交互。
|
||||
- 中等运镜或跨镜连续动作。
|
||||
- 普通法术、环境变化或情绪转折。
|
||||
|
||||
策略：
|
||||
|
||||
- 默认 2 个候选或 1 个候选加 1 次条件重试。
|
||||
- 96+ 可进入批量人工抽检。
|
||||
- 92-95 进入人工比较。
|
||||
- 低于 92 自动定向返修。
|
||||
|
||||
### 6.3 高风险镜头 L3
|
||||
|
||||
特征：
|
||||
|
||||
- 多人物对白或明确台词归属。
|
||||
- 战斗、群体、复杂神兽和大规模 VFX。
|
||||
- 首次建立角色、场景或关键世界观。
|
||||
- 精确文字/UI、复杂口型或高连续性长镜头。
|
||||
- 高成本 4K 或不可替代高潮镜头。
|
||||
|
||||
策略：
|
||||
|
||||
- 关键帧逐镜批准。
|
||||
- 默认 2-3 个候选，按预算动态决定。
|
||||
- 必须人工选择，不能自动进入合并。
|
||||
- 失败优先拆解风险，不盲目重复同一请求。
|
||||
|
||||
## 7. S+ 质量门
|
||||
|
||||
### G0：来源和版本门
|
||||
|
||||
- 输入快照、来源引用和版本链完整。
|
||||
- 上游变更影响范围已计算。
|
||||
|
||||
### G1：剧本门
|
||||
|
||||
- 改编决策已批准。
|
||||
- 人物动机、场景转折、对白时长和上下集状态通过。
|
||||
|
||||
### G2：资产门
|
||||
|
||||
- 资产不是普通 candidate。
|
||||
- 身份、视角、服装、空间或交互专项 QC 通过。
|
||||
- 主母版和状态版本关系明确。
|
||||
|
||||
### G3：导演门
|
||||
|
||||
- 场景空间、阵营归属、视线、动作向量和轴线可验证。
|
||||
- 每个镜头都有存在理由、入点、出点和验收标准。
|
||||
|
||||
### G4：请求门
|
||||
|
||||
- 关键帧已批准。
|
||||
- 实际资产、元素、音色、模型、参数和价格版本已冻结。
|
||||
- 请求满足 Provider 能力和预算上限。
|
||||
|
||||
### G5：媒体门
|
||||
|
||||
- QC 真实读取图片、视频、音频和转写，不使用只看 Prompt 的 mock 结果。
|
||||
- 身份、空间、动作、台词、声音、运镜和连续性均有证据。
|
||||
|
||||
### G6：合并门
|
||||
|
||||
- 只允许 `approved + selected + merge_ready` 片段。
|
||||
- 片段的 Generation Plan 与当前镜头版本一致。
|
||||
- rejected 素材不得保留在任何活动指针中。
|
||||
|
||||
### G7：交付门
|
||||
|
||||
- 技术、叙事、连续性、字幕、声音和版权审核全部通过。
|
||||
|
||||
## 8. 分数与自动决策
|
||||
|
||||
硬失败永远优先于总分。
|
||||
|
||||
```text
|
||||
有 fatal：立即拒绝
|
||||
有 major：阻断并定向返修
|
||||
总分 >= 96 且关键维度 >= 96：自动通过候选
|
||||
总分 92-95：人工复核
|
||||
总分 < 92：自动返修或拒绝
|
||||
```
|
||||
|
||||
高风险 L3 即使达到 96，也必须人工批准。
|
||||
|
||||
每个分数必须保存：
|
||||
|
||||
- rubric 版本。
|
||||
- 观察证据。
|
||||
- 置信度。
|
||||
- 关键维度分。
|
||||
- 扣分原因。
|
||||
- 修复范围。
|
||||
|
||||
本地结构校验分不得显示成“S+ 视觉质量分”。
|
||||
|
||||
## 9. 自动化 DAG
|
||||
|
||||
### 9.1 任务层级
|
||||
|
||||
```text
|
||||
Project
|
||||
-> Episode
|
||||
-> Scene
|
||||
-> Asset / Shot
|
||||
-> Keyframe
|
||||
-> GenerationExecutionPlan
|
||||
-> VideoCandidate
|
||||
-> SelectedClip
|
||||
-> RenderedEpisode
|
||||
-> Release
|
||||
```
|
||||
|
||||
### 9.2 并行规则
|
||||
|
||||
- 不同集的独立资产提取可以并行。
|
||||
- 项目共享身份资产只生成一次。
|
||||
- 同场无连续动作依赖的镜头可以并行。
|
||||
- 需要上一镜尾帧、姿态或声音桥的镜头必须串行。
|
||||
- 合并和最终 QC 必须等待本集所有必需镜头 `merge_ready`。
|
||||
|
||||
### 9.3 幂等与恢复
|
||||
|
||||
任务幂等键至少包含：
|
||||
|
||||
```text
|
||||
stage
|
||||
input_contract_hash
|
||||
asset_version_hashes
|
||||
prompt_rule_version
|
||||
provider_schema_version
|
||||
requested_parameters
|
||||
```
|
||||
|
||||
相同输入不得重复付费生成；失败重试沿用同一业务任务并新增 attempt 记录。
|
||||
|
||||
### 9.4 局部失效
|
||||
|
||||
| 上游变化 | 自动失效范围 |
|
||||
| --- | --- |
|
||||
| 原文或高影响改编变化 | 相关分集及全部下游 |
|
||||
| 分集剧本某场变化 | 该场拆解、分镜、计划和视频 |
|
||||
| 角色身份母版变化 | 所有引用该角色版本的未发布镜头 |
|
||||
| 场景空间母版变化 | 所有引用该场景版本的未发布镜头 |
|
||||
| 单镜执行规格变化 | 该镜关键帧、计划和视频 |
|
||||
| 关键帧变化 | 该镜 Execution Plan 和视频 |
|
||||
| BGM、字幕或 UI 变化 | 只失效后期和成片，不重拍镜头 |
|
||||
|
||||
已发布版本不原地修改，返修产生新发布候选。
|
||||
|
||||
## 10. 人工介入策略
|
||||
|
||||
批量生产采用“异常工作台”，不采用“每一步都让用户点一次”。
|
||||
|
||||
### 10.1 强制人工门
|
||||
|
||||
1. 项目路线和规格确认。
|
||||
2. 高影响改编决策。
|
||||
3. 分集剧本锁定。
|
||||
4. 首次角色/场景主母版批准。
|
||||
5. 高风险 L3 关键帧和视频选择。
|
||||
6. 整集粗剪审核。
|
||||
7. 最终发布批准。
|
||||
|
||||
### 10.2 可批量批准
|
||||
|
||||
- 分集卡。
|
||||
- 资产提取清单。
|
||||
- 同一场景的关键帧联系表。
|
||||
- 中低风险镜头候选。
|
||||
- 字幕、UI 和后期时间线。
|
||||
|
||||
### 10.3 自动执行
|
||||
|
||||
- 结构检查和来源追踪。
|
||||
- 普通资产去重与复用。
|
||||
- 低风险镜头生成、QC 和返修。
|
||||
- 预算内 Provider 路由。
|
||||
- 合并前确定性检查。
|
||||
- 技术 QC 和文件交付检查。
|
||||
|
||||
## 11. 预算、并发和停止条件
|
||||
|
||||
### 11.1 预算层级
|
||||
|
||||
```text
|
||||
project_budget
|
||||
episode_budget
|
||||
shot_budget
|
||||
attempt_budget
|
||||
```
|
||||
|
||||
项目预算确认后，预算内且不改变模型等级的任务可自动执行。以下情况重新请求人工批准：
|
||||
|
||||
- 超过集或项目预算。
|
||||
- 从 1080P 升级到原生 4K。
|
||||
- 候选数量增加。
|
||||
- 切换到更高成本 Provider。
|
||||
- 自动返修达到上限。
|
||||
|
||||
### 11.2 并发控制
|
||||
|
||||
- 按 Provider 配额和限流动态调整并发。
|
||||
- 文本、图片、视频、QC 和本地 FFmpeg 使用独立队列。
|
||||
- 高成本视频队列优先执行已通过全部门禁的任务。
|
||||
- 同一项目保留公平额度，避免单项目占满队列。
|
||||
|
||||
### 11.3 停止条件
|
||||
|
||||
每个阶段必须有：
|
||||
|
||||
```text
|
||||
max_attempts
|
||||
max_candidates
|
||||
max_repair_rounds
|
||||
max_cost
|
||||
timeout
|
||||
fallback_limit
|
||||
```
|
||||
|
||||
耗尽后进入 `manual_required`，不无限重试。
|
||||
|
||||
## 12. 状态机
|
||||
|
||||
### 12.1 合同
|
||||
|
||||
```text
|
||||
draft -> validated -> review_passed -> approved -> locked
|
||||
draft/validated -> rejected
|
||||
approved/locked -> superseded_by_new_version
|
||||
```
|
||||
|
||||
### 12.2 资产
|
||||
|
||||
```text
|
||||
candidate -> qc_passed -> approved -> bound
|
||||
candidate/qc_passed -> rejected
|
||||
approved -> superseded
|
||||
```
|
||||
|
||||
### 12.3 关键帧
|
||||
|
||||
```text
|
||||
generated_candidate -> qc_passed -> approved -> locked_for_video
|
||||
generated_candidate/qc_passed -> rejected
|
||||
```
|
||||
|
||||
### 12.4 视频
|
||||
|
||||
```text
|
||||
generated_candidate -> qc_passed -> approved -> selected -> merge_ready
|
||||
generated_candidate/qc_passed -> rejected
|
||||
```
|
||||
|
||||
### 12.5 成片
|
||||
|
||||
```text
|
||||
rendered_candidate
|
||||
-> technical_qc_passed
|
||||
-> editorial_qc_passed
|
||||
-> release_approved
|
||||
-> published
|
||||
```
|
||||
|
||||
禁止继续使用没有定义的自由状态字符串。
|
||||
|
||||
## 13. 前端信息架构
|
||||
|
||||
### 13.1 项目总览
|
||||
|
||||
展示：
|
||||
|
||||
- 十步生产进度。
|
||||
- 各阶段通过、运行、阻断、人工数量。
|
||||
- 项目和本集预算。
|
||||
- 下一项必须处理的异常。
|
||||
- 批量继续、暂停和取消。
|
||||
|
||||
### 13.2 阶段页面
|
||||
|
||||
每个阶段包含：
|
||||
|
||||
- 主产物预览。
|
||||
- 质量门结果。
|
||||
- 版本与差异。
|
||||
- 批量操作。
|
||||
- 异常列表。
|
||||
- 高级信息抽屉。
|
||||
|
||||
### 13.3 异常工作台
|
||||
|
||||
按原因聚类，而不是按任务流水罗列：
|
||||
|
||||
```text
|
||||
剧本决策待确认
|
||||
资产缺失或冲突
|
||||
空间/方向错误
|
||||
身份漂移
|
||||
台词不完整
|
||||
成本超限
|
||||
Provider 失败
|
||||
候选需要人工选择
|
||||
最终成片问题
|
||||
```
|
||||
|
||||
用户修复一次规则后，可批量应用于同类未执行任务。
|
||||
|
||||
### 13.4 高级信息抽屉
|
||||
|
||||
完整显示：
|
||||
|
||||
```text
|
||||
上游合同版本
|
||||
计划资产
|
||||
选择资产
|
||||
实际发送资产
|
||||
角色元素和声线
|
||||
完整 Prompt
|
||||
负向约束
|
||||
Provider/模型/端点
|
||||
完整参数
|
||||
价格版本和估算
|
||||
实际请求和响应摘要
|
||||
QC 证据
|
||||
重试与回退记录
|
||||
```
|
||||
|
||||
## 14. 新旧能力处理
|
||||
|
||||
### 14.1 保留
|
||||
|
||||
- Source Snapshot 和来源引用。
|
||||
- 版本化生产合同。
|
||||
- Prompt Rule Registry。
|
||||
- Model Capability、Parameter Schema、Pricing Registry。
|
||||
- Provider 路由和请求检查器。
|
||||
- 资产私有存储和 Range 预览。
|
||||
- RenderTask、BullMQ、成本和审计日志。
|
||||
- FFmpeg 合成、字幕、BGM、SFX 和转场能力。
|
||||
|
||||
### 14.2 重构
|
||||
|
||||
- 五级合同扩展为完整制作合同链。
|
||||
- Generation Plan 拆成可修订 Intent Plan 与不可变 Execution Plan。
|
||||
- Asset Plan 升级为制作拆解和资产批准体系。
|
||||
- 分镜增加 Scene Geography 和导演审核。
|
||||
- 视频生成改为候选优先，不再自动选中。
|
||||
- QC 改为读取真实媒体。
|
||||
- 用户端只保留十步制作流程。
|
||||
|
||||
### 14.3 废弃
|
||||
|
||||
- 用 `generated` 表示所有阶段完成。
|
||||
- 用结构完整度 100 分代表 S+。
|
||||
- 视频生成后立即写入正式选中指针。
|
||||
- 人工拒绝后继续保留活动指针。
|
||||
- 只看 Prompt 的视频 QC。
|
||||
- 未批准素材进入付费视频请求。
|
||||
- 工程合同名称占据用户主导航。
|
||||
|
||||
## 15. 实施顺序
|
||||
|
||||
### P0：停止错误素材进入成片
|
||||
|
||||
1. 视频生成只创建候选，默认不选中。
|
||||
2. 拒绝候选时原子清空活动指针。
|
||||
3. 合并只接受 `merge_ready` 且 Plan 匹配的片段。
|
||||
4. 关键帧增加批准状态，未批准禁止视频生成。
|
||||
5. Execution Plan 移到关键帧批准后冻结。
|
||||
|
||||
验收：项目 #22 的 rejected 视频 #1002 无法进入任何新合并任务。
|
||||
|
||||
### P1：建立可理解的新生产台
|
||||
|
||||
1. 新增 `splus_v2`，不改变已存在项目。
|
||||
2. 用户端替换为十步流程和四阶段导航。
|
||||
3. 工程合同移入高级抽屉。
|
||||
4. 项目总览增加异常和批次状态。
|
||||
|
||||
验收：新用户不需要理解 Production Contract 或 Generation Plan，也能从原著走到成片。
|
||||
|
||||
### P2：补齐剧本与制作拆解
|
||||
|
||||
1. 加入短篇/长篇/现成剧本三种路线。
|
||||
2. 增加高影响改编逐项确认。
|
||||
3. 增加 Production Breakdown。
|
||||
4. 增加项目级和分集级资产去重。
|
||||
|
||||
验收：锁定剧本可以稳定生成角色、场景、道具、状态、VFX 和声音清单。
|
||||
|
||||
### P3：补齐前期双轨和导演门
|
||||
|
||||
1. 增加 Scene Geography。已完成合同、校验、前端查看、镜头强绑定和项目 #22 首份确认合同。
|
||||
2. 资产 QC 与导演分镜并行。
|
||||
3. 增加分镜执行规格批审和关键帧联系表。
|
||||
4. 增加局部失效图。
|
||||
|
||||
验收：阵营、视线、动作方向或轴线错误在关键帧前被阻断。
|
||||
|
||||
### P4：真实媒体 QC 和风险路由
|
||||
|
||||
1. 接入视频抽帧、视频理解和音频转写。
|
||||
2. 实现 L1/L2/L3 风险分类。
|
||||
3. 实现动态候选数量和差异返修。
|
||||
4. 自动选择只开放给低风险 96+ 镜头。
|
||||
|
||||
验收：错误说话者、漏词、变脸、方向错误和动作未完成可被自动发现。
|
||||
|
||||
### P5：批量 Orchestrator 与最终交付
|
||||
|
||||
1. 以 DAG 编排项目、集、场、镜和资产。
|
||||
2. 完成预算自动批准、并发、恢复和停止条件。
|
||||
3. 完成粗剪、后期计划和全片 QC。
|
||||
4. 建立批量指标和人工校准数据集。
|
||||
|
||||
验收：连续三集可以在有限人工门下批量完成，异常可局部恢复。
|
||||
|
||||
## 16. 总体验收
|
||||
|
||||
选择一个全新 S+ 项目，连续生产三集，每集 6-12 镜，满足：
|
||||
|
||||
- 不人工改写 Provider Prompt。
|
||||
- 所有付费请求可复现实际输入。
|
||||
- 100% rejected 素材无法进入合并。
|
||||
- 100% 视频使用批准关键帧和批准资产。
|
||||
- 首轮镜头自动通过率达到 70% 以上。
|
||||
- 人工介入镜头比例低于 30%，并随校准逐步下降。
|
||||
- 成本不超过批准预算，预估与实际偏差小于 10%。
|
||||
- 台词完整率、说话者正确率和字幕覆盖率达到 100%。
|
||||
- 阵营、空间、攻击方向和跨镜连续性无致命错误。
|
||||
- 整集无需人工逐镜裁切和重新排列台词。
|
||||
- 最终人工盲评达到内部 S+ 发布标准。
|
||||
|
||||
未满足以上条件前，不宣称自动化 S+ 流水线已经完成。
|
||||
@@ -0,0 +1,135 @@
|
||||
# S+ P0 执行门禁落地记录 V1
|
||||
|
||||
> 日期：2026-07-19
|
||||
> 范围：关键帧批准、不可变执行计划、视频候选审核、选用指针与合并门禁
|
||||
> 目标：先消除“生成即选用、未审即合并、计划与实际素材不一致”的高风险旁路。
|
||||
|
||||
## 1. 本次落地结果
|
||||
|
||||
### 1.1 关键帧不再直接进入视频生成
|
||||
|
||||
当前状态链：
|
||||
|
||||
```text
|
||||
generated_candidate
|
||||
-> approved
|
||||
-> 冻结 ShotGenerationPlan
|
||||
-> 才允许视频预检与提交
|
||||
```
|
||||
|
||||
- 上传或 AI 生成关键帧后，只写入候选状态。
|
||||
- 候选会清空旧的执行计划指针和旧的视频选用指针。
|
||||
- 新增关键帧批准接口：
|
||||
|
||||
```text
|
||||
POST /api/episodes/:episodeId/live-action/shots/:shotId/keyframe/approve
|
||||
```
|
||||
|
||||
- 批准动作完成后才冻结不可变 Generation Plan。
|
||||
- 预检会返回 `LIVE_ACTION_KEYFRAME_APPROVAL_REQUIRED`，阻断未批准候选。
|
||||
|
||||
### 1.2 视频生成结果不再自动选中
|
||||
|
||||
当前状态链：
|
||||
|
||||
```text
|
||||
generated_candidate
|
||||
-> 人工审核 passed
|
||||
-> approved
|
||||
-> 用户设为选用
|
||||
-> merge_ready
|
||||
```
|
||||
|
||||
- 已移除 `autoSelectClip` 业务逻辑。
|
||||
- 队列审计字段固定记录 `auto_select_clip=false`。
|
||||
- 同步生成与异步回收都只创建 `generated_candidate`。
|
||||
- AI Provider 返回后不再写 `storyboard_shots.video_clip_asset_id`。
|
||||
|
||||
### 1.3 选用指针成为受控活动指针
|
||||
|
||||
只有以下条件同时满足，候选才允许设为选用：
|
||||
|
||||
- `VideoClip.status=approved`
|
||||
- `VideoClip.quality_status=passed`
|
||||
- 存在输出素材
|
||||
- 候选的 `generation_plan_id` 与镜头当前计划一致
|
||||
|
||||
选中后：
|
||||
|
||||
- 当前候选变为 `merge_ready`。
|
||||
- 同镜头其它 `merge_ready` 候选降回 `approved`。
|
||||
- 镜头活动指针原子更新到选中素材。
|
||||
|
||||
关键帧重新批准时，旧计划下的 `merge_ready` 片段统一变为 `superseded`。
|
||||
|
||||
### 1.4 驳回会原子清除旧选用
|
||||
|
||||
如果被驳回的候选正是当前选用片段：
|
||||
|
||||
- 候选变为 `rejected`。
|
||||
- `video_clip_asset_id` 同一事务内清空。
|
||||
- 镜头回到不可合并状态。
|
||||
|
||||
重试、进入人工处理或质量失败时也会清理失效的活动指针。
|
||||
|
||||
### 1.5 合并只读取严格可合并片段
|
||||
|
||||
整集合并现在要求每个镜头都满足：
|
||||
|
||||
```text
|
||||
有活动素材指针
|
||||
+ 对应 VideoClip.status=merge_ready
|
||||
+ quality_status=passed
|
||||
+ S+ 项目存在 active_generation_plan_id
|
||||
+ VideoClip.generation_plan_id 与活动计划一致
|
||||
```
|
||||
|
||||
任何镜头不满足都会抛出 `LIVE_ACTION_CLIP_NOT_MERGE_READY`，FFmpeg 不会启动。
|
||||
|
||||
## 2. 用户端变化
|
||||
|
||||
小样页现在明确显示：
|
||||
|
||||
1. 生成或上传关键帧候选。
|
||||
2. 预览候选。
|
||||
3. 点击“批准并冻结计划”。
|
||||
4. 生成视频候选。
|
||||
5. 质检并人工确认可用。
|
||||
6. 点击“设为选用”。
|
||||
7. 所有镜头到达 `merge_ready` 后才开放整集合并。
|
||||
|
||||
候选列表中的“设为选用”按钮会在审核通过前保持禁用，避免页面误导。
|
||||
|
||||
## 3. 数据实现
|
||||
|
||||
本次没有新增数据库字段，也没有执行数据迁移。
|
||||
|
||||
复用现有字段：
|
||||
|
||||
- `ShotImage.status`
|
||||
- `VideoClip.status`
|
||||
- `VideoClip.quality_status`
|
||||
- `StoryboardShot.active_generation_plan_id`
|
||||
- `StoryboardShot.keyframe_asset_id`
|
||||
- `StoryboardShot.video_clip_asset_id`
|
||||
|
||||
这样先建立安全门禁，后续再按生产合同补充独立 Approval、QC Evidence 和活动版本表。
|
||||
|
||||
## 4. 本次没有完成的内容
|
||||
|
||||
以下仍属于后续阶段，不应误认为本次已解决：
|
||||
|
||||
- 场景地理、阵营、屏幕方向、攻击向量和 180 度轴线合同。
|
||||
- 对关键帧真实像素内容的自动视觉 QC。
|
||||
- 对视频逐帧、声音和台词归属的多模态自动 QC。
|
||||
- 项目/集/场/镜完整任务 DAG 与局部失效传播。
|
||||
- 自动批准低风险镜头的校准机制。
|
||||
- 后台批量审核台、审核证据和盲评标定。
|
||||
|
||||
## 5. 验证
|
||||
|
||||
- 后端 TypeScript 构建通过。
|
||||
- 用户端 Vue TypeScript 与生产构建通过。
|
||||
- 新增状态门禁测试覆盖：未批准关键帧阻断、批准后冻结计划、视频候选禁止自动选中、未审核候选禁止选用、驳回后清除活动指针、未到 `merge_ready` 禁止合并。
|
||||
- 本次 6 条定向门禁测试全部通过。
|
||||
- 后端全量测试当前为 343 条中 313 条通过、30 条失败。失败集中在旧测试桩、Prompt V5/导演策略断言、人物三视图旧模板断言和其它历史模块，不应误报为全仓测试已通过。
|
||||
@@ -0,0 +1,626 @@
|
||||
# S+ 短剧完整生产流程审计 V1
|
||||
|
||||
> 审计日期：2026-07-19
|
||||
> 审计对象：当前 S+ 设计文档、前后端实现、数据库状态，以及项目 #22《诸葛亮与司马懿斗法》的第一集实际执行记录
|
||||
> 审计性质：只读流程审计。本次不修改剧本、不修改数据库、不触发付费生成。
|
||||
|
||||
> 2026-07-19 更新：P0-3、P0-4、P0-5 与合并门禁的第一阶段代码整改已落地，详见 `S_PLUS_P0_EXECUTION_GATES_IMPLEMENTATION_V1.md`。场景地理合同、自动视觉 QC 和完整 DAG 仍待后续阶段。
|
||||
|
||||
## 1. 结论
|
||||
|
||||
当前流程的方向是对的，但还没有形成真正闭环的 S+ 生产线。
|
||||
|
||||
目前系统擅长：
|
||||
|
||||
- 保存版本化合同。
|
||||
- 检查 JSON 结构和上下游引用。
|
||||
- 规划资产、模型、参数和成本。
|
||||
- 调用图片、视频 Provider 并保存审计记录。
|
||||
|
||||
目前系统缺失的关键能力：
|
||||
|
||||
- 高影响改编决策的独立人工确认。
|
||||
- 场景地理、阵营归属、视线、攻击方向和镜头轴线的正式合同。
|
||||
- 资产是否真的表达了所需空间关系的视觉质检。
|
||||
- 分镜执行规格和关键帧的 S+ 视觉准入。
|
||||
- 冻结计划与实际提交素材完全一致的不可变执行快照。
|
||||
- 真正观看视频内容的自动质检。
|
||||
- “通过质检后才能选中、通过选中后才能合并”的状态门禁。
|
||||
- 成片画面、声音、字幕和叙事完整性的最终审核。
|
||||
|
||||
因此，第一镜失败不是单个 Prompt 写差，而是多个流程缺口叠加：
|
||||
|
||||
```text
|
||||
原著被改成结果先置
|
||||
-> 没有单独确认这项叙事重排
|
||||
-> 场景母版没有双军站位信息
|
||||
-> 分镜把鬼将写在画面中央而不是魏军上空
|
||||
-> 关键帧生成后没有视觉质检
|
||||
-> 冻结计划仍引用旧关键帧
|
||||
-> 视频生成后先自动选中
|
||||
-> 自动 QC 不读取视频画面
|
||||
-> 人工拒绝后仍保留在分镜选中字段
|
||||
-> 合并门禁仍可能放行
|
||||
```
|
||||
|
||||
## 2. 当前实际流程
|
||||
|
||||
### 2.1 S+ 合同链
|
||||
|
||||
当前 S+ 页面展示：
|
||||
|
||||
```text
|
||||
不可变原文快照
|
||||
-> 原著分析
|
||||
-> 改编圣经
|
||||
-> 分集计划
|
||||
-> 场景剧本
|
||||
-> 资产计划
|
||||
-> 执行联调 Generation Plan
|
||||
```
|
||||
|
||||
前五阶段后端已经提供文本模型自动生成接口，但当前 S+ 页面主要操作仍是：
|
||||
|
||||
```text
|
||||
生成阶段 Prompt
|
||||
-> 复制到外部模型
|
||||
-> 粘贴结构化 JSON
|
||||
-> 校验并保存合同
|
||||
```
|
||||
|
||||
证据：
|
||||
|
||||
- 自动生成接口：`backend/src/production-kernel/production-kernel.service.ts:627`
|
||||
- 当前页面导入方式：`user-app/src/components/production/SplusProductionPipeline.vue:775`
|
||||
|
||||
### 2.2 旧工作流仍并存
|
||||
|
||||
用户端全局工作流仍是：
|
||||
|
||||
```text
|
||||
来源 -> 版权 -> 故事 -> 角色 -> 记忆 -> 分集
|
||||
-> 脚本 -> 分镜 -> 图片 -> 音频字幕 -> 成品
|
||||
```
|
||||
|
||||
证据：`user-app/src/workflow.ts:66`
|
||||
|
||||
这条旧流程没有表达 S+ 的原著分析、改编圣经、资产计划、Generation Plan、关键帧审核和视频 QC。当前系统实际上存在两套流程语义，页面状态容易互相污染。
|
||||
|
||||
## 3. P0 问题
|
||||
|
||||
### P0-1：高影响改编决策没有独立确认
|
||||
|
||||
项目 #22 的原文是顺叙：
|
||||
|
||||
```text
|
||||
两军对峙
|
||||
-> 司马懿挑衅
|
||||
-> 司马懿施法
|
||||
-> 阴兵、乌鸦和九幽鬼将出现
|
||||
```
|
||||
|
||||
改编圣经新增了“结果先置”钩子，分集计划和场景剧本因此改成：
|
||||
|
||||
```text
|
||||
开场直接出现完整鬼将和巨掌
|
||||
-> 再切回两军对峙与司马懿施法
|
||||
```
|
||||
|
||||
这不是压缩，而是叙事顺序重排。当前系统只要求整份合同确认，没有把 `add / remove / reorder` 这类高影响决策单独列出来确认。
|
||||
|
||||
后果：分镜与已确认场景剧本形式上一致，却与用户期望的完整故事不一致。
|
||||
|
||||
整改要求：
|
||||
|
||||
- `keep`、轻量 `compress` 可以批量确认。
|
||||
- `add`、`remove`、`reorder`、角色动机变化必须逐项确认。
|
||||
- 未确认的高影响决策不得进入分集计划。
|
||||
|
||||
### P0-2：缺少“场景地理与调度圣经”
|
||||
|
||||
当前资产计划检查了：
|
||||
|
||||
- 是否存在场景引用。
|
||||
- 是否存在角色身份引用。
|
||||
- 引用是否属于当前项目。
|
||||
|
||||
但没有检查：
|
||||
|
||||
- 蜀军和魏军的固定方位。
|
||||
- 两军是否相向而立。
|
||||
- 司马懿、诸葛亮分别属于哪一侧。
|
||||
- 鬼将必须从魏军上空出现。
|
||||
- 巨掌必须从魏军方向拍向蜀军。
|
||||
- 镜头是否越过 180 度轴线。
|
||||
|
||||
证据：`backend/src/production-kernel/production-kernel.service.ts:1863`
|
||||
|
||||
项目 #22 的场景资产 #989/#990 只是空战场，没有双军、角色、攻击方向和镜头轴线，却被当成正式空间母版使用。
|
||||
|
||||
整改要求：在资产计划与分镜切割之间增加正式合同：
|
||||
|
||||
```text
|
||||
Scene Geography & Blocking Bible
|
||||
```
|
||||
|
||||
至少包含：
|
||||
|
||||
```json
|
||||
{
|
||||
"world_axis": "魏军西侧，蜀军东侧，两军隔原相望",
|
||||
"screen_axis_a": "常规正打保持魏军画面左侧、蜀军画面右侧",
|
||||
"faction_ownership": {
|
||||
"司马懿": "魏军",
|
||||
"九幽鬼将": "魏军召唤物",
|
||||
"诸葛亮": "蜀军"
|
||||
},
|
||||
"attack_vectors": [
|
||||
"九幽鬼将从魏军阵地上空显形",
|
||||
"巨掌由魏军方向压向蜀军诸葛亮所在位置"
|
||||
],
|
||||
"forbidden_results": [
|
||||
"两军背向而立",
|
||||
"鬼将出现在蜀军上空",
|
||||
"巨掌拍向魏军",
|
||||
"无动机越轴"
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
### P0-3：关键帧没有视觉准入门
|
||||
|
||||
当前关键帧生成后会立即写入：
|
||||
|
||||
- `storyboard_shots.keyframe_asset_id`
|
||||
- `shot_images.status=generated`
|
||||
|
||||
但没有：
|
||||
|
||||
- 空间关系视觉检查。
|
||||
- 阵营归属检查。
|
||||
- 攻击方向检查。
|
||||
- 人物身份和服装一致性检查。
|
||||
- 人工“批准为视频首帧”状态。
|
||||
|
||||
证据：`backend/src/live-action/live-action.service.ts:8322`
|
||||
|
||||
项目 #22 第一镜关键帧 #1001：
|
||||
|
||||
- `shot_images.quality_score = null`
|
||||
- `shot_images.status = generated`
|
||||
- 素材却已经是 `selection_status = selected`
|
||||
|
||||
整改要求：
|
||||
|
||||
```text
|
||||
generated_candidate
|
||||
-> visual_qc_passed
|
||||
-> human_approved
|
||||
-> locked_for_video
|
||||
```
|
||||
|
||||
任何关键帧未到 `locked_for_video`，禁止提交视频 Provider。
|
||||
|
||||
### P0-4：Generation Plan 冻结得太早
|
||||
|
||||
S+ 当前在生成关键帧前先冻结 Shot Generation Plan。
|
||||
|
||||
证据：`backend/src/live-action/live-action.service.ts:1388`
|
||||
|
||||
项目 #22 第一镜的 Plan #15：
|
||||
|
||||
- 状态为 `frozen`。
|
||||
- `video_request_json.provider_clip_segments[0].source_keyframe_asset_id = 1000`。
|
||||
- 实际视频任务使用关键帧 #1001。
|
||||
|
||||
这意味着“不可变计划”和“实际执行请求”已经不一致。
|
||||
|
||||
整改要求：拆成两类计划。
|
||||
|
||||
#### Shot Intent Plan
|
||||
|
||||
- 在关键帧前生成。
|
||||
- 包含戏剧目的、空间关系、资产需求、模型建议和成本区间。
|
||||
- 可修订，不叫 frozen。
|
||||
|
||||
#### Generation Execution Plan
|
||||
|
||||
- 关键帧批准后生成。
|
||||
- 包含实际关键帧 ID 与 hash。
|
||||
- 包含实际发送的每张参考图 ID 与 hash。
|
||||
- 包含实际元素 ID、音色 ID、Provider、模型、Schema、参数和价格版本。
|
||||
- 冻结后请求不得替换素材。
|
||||
|
||||
### P0-5：视频先选中，后质检
|
||||
|
||||
当前任务默认：
|
||||
|
||||
```text
|
||||
auto_select_clip = true
|
||||
```
|
||||
|
||||
视频生成成功后，立即写入：
|
||||
|
||||
```text
|
||||
storyboard_shots.video_clip_asset_id
|
||||
```
|
||||
|
||||
此时 `VideoClip.quality_status` 仍为空。
|
||||
|
||||
证据：
|
||||
|
||||
- 默认自动选中：`backend/src/live-action/live-action.service.ts:3332`
|
||||
- 视频落库后立即选中：`backend/src/live-action/live-action.service.ts:3574`
|
||||
|
||||
整改要求：
|
||||
|
||||
```text
|
||||
generated_candidate
|
||||
-> qc_passed
|
||||
-> human_approved
|
||||
-> selected
|
||||
-> merge_ready
|
||||
```
|
||||
|
||||
生成完成只能成为候选，不能自动写入正式选中字段。
|
||||
|
||||
### P0-6：视频自动 QC 不看视频
|
||||
|
||||
当前视频 QC 固定使用 `mock-qc`，输入只有：
|
||||
|
||||
- clip ID。
|
||||
- 时长。
|
||||
- MIME。
|
||||
- 素材状态。
|
||||
- Prompt 文本。
|
||||
|
||||
没有视频文件、抽帧、音轨或转写文本。
|
||||
|
||||
证据：`backend/src/live-action/live-action.service.ts:2766`
|
||||
|
||||
因此它无法检查：
|
||||
|
||||
- 两军是否相向。
|
||||
- 鬼将出现在哪一侧。
|
||||
- 巨掌拍向谁。
|
||||
- 角色是否变脸。
|
||||
- 台词是否漏读、抢词或说错语言。
|
||||
- 音画是否同步。
|
||||
|
||||
整改要求：QC 至少读取：
|
||||
|
||||
```text
|
||||
首帧 + 25%帧 + 50%帧 + 75%帧 + 尾帧
|
||||
音频转写
|
||||
镜头执行规格
|
||||
关键帧和身份母版
|
||||
```
|
||||
|
||||
高风险镜头需要直接上传视频给支持视频理解的模型复核。
|
||||
|
||||
### P0-7：人工拒绝后仍可进入合并
|
||||
|
||||
当前人工拒绝只更新：
|
||||
|
||||
- `video_clips.quality_status`
|
||||
- `storyboard_shots.video_status`
|
||||
|
||||
不会清空：
|
||||
|
||||
```text
|
||||
storyboard_shots.video_clip_asset_id
|
||||
```
|
||||
|
||||
证据：`backend/src/live-action/live-action.service.ts:2384`
|
||||
|
||||
项目 #22 第一镜已被人工拒绝：
|
||||
|
||||
- Clip #287：`quality_status=rejected`
|
||||
- Asset #1002：`selection_status=rejected`
|
||||
- Shot #969：`video_status=sample_rejected`
|
||||
- 但 Shot #969 仍指向 `video_clip_asset_id=1002`
|
||||
|
||||
合并门禁目前只处理“多候选时是否选了其中一个”，不检查所选素材是否通过 QC。
|
||||
|
||||
证据：`backend/src/live-action/live-action.service.ts:4913`
|
||||
|
||||
整改要求：
|
||||
|
||||
- 拒绝视频时，若分镜正指向该素材，必须在同一事务中清空指针。
|
||||
- 合并只接受 `quality_status=passed`、`selection_status=selected`、`approval_status=approved`、`generation_plan_id` 匹配的片段。
|
||||
|
||||
## 4. P1 问题
|
||||
|
||||
### P1-1：结构评分被误解为 S+ 质量评分
|
||||
|
||||
合同本地审核分数从 100 开始，按结构问题扣分：
|
||||
|
||||
```text
|
||||
fatal -30
|
||||
major -15
|
||||
其他 -5
|
||||
```
|
||||
|
||||
证据：`backend/src/production-kernel/production-kernel.service.ts:1999`
|
||||
|
||||
因此“100 分”通常代表：
|
||||
|
||||
```text
|
||||
字段齐全、引用合法、结构连贯
|
||||
```
|
||||
|
||||
不代表：
|
||||
|
||||
```text
|
||||
剧本好看、运镜高级、笑点有效、空间正确、成片达到 S+
|
||||
```
|
||||
|
||||
整改要求：页面分开显示：
|
||||
|
||||
- 结构完整度。
|
||||
- 叙事质量。
|
||||
- 导演可执行性。
|
||||
- 视觉连续性。
|
||||
- S+ 综合评审。
|
||||
|
||||
### P1-2：资产“存在”被当成资产“合格”
|
||||
|
||||
当前资产门禁主要检查引用存在与 `missing_requirements`，没有统一检查：
|
||||
|
||||
- `selection_status`。
|
||||
- 视觉质量分。
|
||||
- 是否人工批准。
|
||||
- 是否真的表达角色、场景和道具语义。
|
||||
|
||||
项目 #22：
|
||||
|
||||
- 场景 #989 是 `candidate`，无视觉质量分，却被当作场景锁定资产。
|
||||
- 九幽鬼将 #995 是非主母版的三视图辅助图，却满足了“正式身份母版”需求。
|
||||
|
||||
整改要求：不同资产类型使用不同 QC 合同。
|
||||
|
||||
```text
|
||||
角色：脸、年龄、服装、体型、视角一致性
|
||||
场景：空间结构、光源、方位、可拍机位、轴线
|
||||
道具：形状、材质、尺寸、持有方式、交互面
|
||||
特效实体：结构、归属、运动方向、尺度、物理交互
|
||||
```
|
||||
|
||||
### P1-3：计划资产与实际 Provider 输入没有清晰区分
|
||||
|
||||
第一镜 Plan 选择的是：
|
||||
|
||||
```text
|
||||
#995 九幽鬼将
|
||||
#989 战场
|
||||
```
|
||||
|
||||
实际视频请求使用：
|
||||
|
||||
```text
|
||||
首帧 #1001
|
||||
附加参考 #995
|
||||
```
|
||||
|
||||
场景 #989 没有作为独立参考图发送。
|
||||
|
||||
系统需要同时展示三层信息：
|
||||
|
||||
```text
|
||||
计划需要什么
|
||||
-> 选择了什么
|
||||
-> 实际 API 发了什么
|
||||
```
|
||||
|
||||
不能只展示计划包，否则无法复盘生成偏差。
|
||||
|
||||
### P1-4：视频角色元素链路尚未真正接通项目 #22
|
||||
|
||||
“元素源视频”不是“可灵视频角色元素”。完整链路应为：
|
||||
|
||||
```text
|
||||
生成 3-8 秒元素源视频
|
||||
-> 上传可灵元素库
|
||||
-> 获得真实 element_id
|
||||
-> 导入 CharacterProviderBinding
|
||||
-> 状态 approved 且评分 >= 90
|
||||
-> 项目角色关联对应 GlobalCharacter
|
||||
-> Generation Plan 写入 element_list
|
||||
```
|
||||
|
||||
项目 #22 当前四个项目角色的 `global_character_id` 全为空，数据库没有可解析的 Provider Element Binding。第一镜 Plan #15 的：
|
||||
|
||||
```text
|
||||
element_list = []
|
||||
provider_elements = []
|
||||
```
|
||||
|
||||
而第一镜走的是普通 `kling-v3-native-audio-video`，不是要求元素门禁的 `kling-v3-omni`。
|
||||
|
||||
结论：此前生成的诸葛亮元素源视频目前只是素材候选，并没有参与正式分镜生成。
|
||||
|
||||
### P1-5：最终“视频审核”仍是内容安全审核，不是成片质量审核
|
||||
|
||||
当前成品视频审核只把素材类型、MIME、文件路径和一段文本交给 Moderation Provider，没有读取成片视频。
|
||||
|
||||
证据：`backend/src/reviews/reviews.service.ts:86`
|
||||
|
||||
它能做的是内容风险审核，不能替代：
|
||||
|
||||
- 漏镜检查。
|
||||
- 画面连续性检查。
|
||||
- 字幕缺失检查。
|
||||
- 音量与对白完整性检查。
|
||||
- BGM 高潮点检查。
|
||||
- 黑帧、卡帧和转场检查。
|
||||
|
||||
### P1-6：状态名称不能反映真实完成度
|
||||
|
||||
项目 #22 当前：
|
||||
|
||||
- Project：`live_action_shots_prepared`
|
||||
- Episode：`storyboard_draft`
|
||||
- 9 个 Shot：全部 `status=generated`
|
||||
- 但只有第 1 镜有关键帧和视频，且视频已拒绝。
|
||||
|
||||
整改要求：项目、集、镜头必须使用可推导状态，不由多个服务随意写自由字符串。
|
||||
|
||||
## 5. P2 问题
|
||||
|
||||
### P2-1：S+ 页面和旧制作台没有统一
|
||||
|
||||
S+ 页面只到“执行联调”，旧制作台负责分镜、关键帧、视频和合并。用户需要跨两个世界理解同一个项目。
|
||||
|
||||
整改要求：S+ 项目使用一条完整的可视化流水线，旧项目保留旧入口，但新项目不再进入旧状态机。
|
||||
|
||||
### P2-2：Prompt 过度承担数据库合同职责
|
||||
|
||||
当前 Prompt 同时承载：
|
||||
|
||||
- 戏剧目的。
|
||||
- 空间关系。
|
||||
- 人物站位。
|
||||
- 运镜。
|
||||
- 声音。
|
||||
- 资产绑定。
|
||||
- 禁止结果。
|
||||
|
||||
文本再长也不能替代结构化字段。应把关键约束存入可校验 JSON，再由 Provider Adapter 编译成模型 Prompt。
|
||||
|
||||
## 6. 建议的完整 S+ 流程
|
||||
|
||||
### 阶段 A：内容合同
|
||||
|
||||
1. 原文不可变快照。
|
||||
2. 原著分析。
|
||||
3. 改编圣经。
|
||||
4. 高影响改编决策逐项确认。
|
||||
5. 连续三集计划与连续性检查。
|
||||
6. 完整场景剧本 S+ 审核。
|
||||
|
||||
### 阶段 B：导演合同
|
||||
|
||||
7. 场景地理与调度圣经。
|
||||
8. 角色、场景、道具、特效实体抽取。
|
||||
9. 资产需求计划。
|
||||
10. 镜头切割与时长预算。
|
||||
11. 分镜执行规格审核。
|
||||
|
||||
### 阶段 C：资产准入
|
||||
|
||||
12. 外部导入或内部生成素材。
|
||||
13. 类型专项视觉 QC。
|
||||
14. 人工批准主母版。
|
||||
15. 视频角色元素创建、导入与绑定。
|
||||
16. Shot Intent Plan 编译。
|
||||
|
||||
### 阶段 D：关键帧准入
|
||||
|
||||
17. 关键帧生成。
|
||||
18. 关键帧自动视觉 QC。
|
||||
19. 关键帧联系表人工审核。
|
||||
20. 关键帧批准并锁定。
|
||||
|
||||
### 阶段 E：不可变执行
|
||||
|
||||
21. 编译 Generation Execution Plan。
|
||||
22. 展示完整实际 API 请求与成本。
|
||||
23. 人工确认付费调用。
|
||||
24. 视频生成，只创建候选。
|
||||
25. 视频画面、声音、台词和连续性 QC。
|
||||
26. 人工选择最佳候选。
|
||||
|
||||
### 阶段 F：合成与发布
|
||||
|
||||
27. 合并准入检查。
|
||||
28. 转场、BGM、SFX、字幕和 UI 后期。
|
||||
29. 全片技术 QC。
|
||||
30. 全片叙事与 S+ 审核。
|
||||
31. 发布或返修。
|
||||
|
||||
## 7. 必须执行的状态机
|
||||
|
||||
### 资产
|
||||
|
||||
```text
|
||||
candidate -> qc_passed -> approved -> bound
|
||||
candidate -> rejected
|
||||
```
|
||||
|
||||
### 关键帧
|
||||
|
||||
```text
|
||||
generated_candidate -> qc_passed -> approved -> locked_for_video
|
||||
generated_candidate -> rejected
|
||||
```
|
||||
|
||||
### 视频片段
|
||||
|
||||
```text
|
||||
generated_candidate -> qc_passed -> approved -> selected -> merge_ready
|
||||
generated_candidate -> rejected
|
||||
```
|
||||
|
||||
### 成片
|
||||
|
||||
```text
|
||||
rendered_candidate -> technical_qc_passed -> editorial_qc_passed -> approved -> published
|
||||
```
|
||||
|
||||
## 8. 项目 #22 的正确恢复点
|
||||
|
||||
项目 #22 不应该从“优化第一镜 Prompt”继续，也不应该直接重新生成。
|
||||
|
||||
正确恢复顺序：
|
||||
|
||||
1. 回到已确认的完整场景剧本，取消未经重新确认的结果先置开场。
|
||||
2. 建立五丈原场景地理与调度圣经。
|
||||
3. 明确两军相望、魏蜀归属、鬼将生成点和巨掌攻击向量。
|
||||
4. 重新切第一集分镜并审核时长、轴线和运镜。
|
||||
5. 生成双军空间关键帧小样。
|
||||
6. 关键帧通过后再编译新的不可变执行计划。
|
||||
7. 只跑第一镜视频样片。
|
||||
8. 通过视频 QC 和人工审核后，再进入其余分镜。
|
||||
|
||||
第一镜旧 Plan #10-#15、关键帧 #1001、视频 #1002 只保留为失败审计样本，不再作为正式链路输入。
|
||||
|
||||
## 9. 实施优先级
|
||||
|
||||
### 第一批：先堵住继续烧钱的漏洞
|
||||
|
||||
1. 禁止视频生成后自动选中。
|
||||
2. 人工拒绝时原子清空 Shot 的视频指针。
|
||||
3. 合并必须检查 QC、批准状态和 Plan 匹配。
|
||||
4. 关键帧增加批准门，未批准不能生成视频。
|
||||
5. 将冻结计划移到关键帧批准之后。
|
||||
|
||||
### 第二批：修正创作流程
|
||||
|
||||
6. 增加高影响改编决策审核。
|
||||
7. 增加场景地理与调度圣经。
|
||||
8. 增加分镜执行规格审核页。
|
||||
9. 资产增加类型专项视觉 QC。
|
||||
|
||||
### 第三批：形成真正 S+ 闭环
|
||||
|
||||
10. 接入可读取视频与音频的真实 QC。
|
||||
11. 增加最终成片技术和叙事审核。
|
||||
12. 统一 S+ 页面、状态机和完整 API 请求审计。
|
||||
|
||||
## 10. 验收标准
|
||||
|
||||
新版流程应能在付费视频调用前自动阻断以下任意情况：
|
||||
|
||||
- 两军不是相望关系。
|
||||
- 阵营左右与空间圣经冲突。
|
||||
- 召唤物没有绑定召唤方。
|
||||
- 攻击向量指向错误阵营。
|
||||
- 场景母版仍为候选或没有视觉审批。
|
||||
- 关键帧未通过视觉 QC 或人工批准。
|
||||
- Execution Plan 的关键帧 ID 与实际请求不一致。
|
||||
- 视频元素源素材没有真实 element_id。
|
||||
- 生成视频尚未通过 QC 就被选中。
|
||||
- 被拒绝视频仍留在 Shot 正式指针中。
|
||||
- 合并输入包含 rejected、未批准或 Plan 不匹配片段。
|
||||
|
||||
只有这些门禁全部成立，流程才算从“会调用模型”升级为“可控的 S+ 流水线”。
|
||||
@@ -0,0 +1,160 @@
|
||||
# S+ 场景地理与人物调度硬门落地记录 V1
|
||||
|
||||
> 落地日期：2026-07-19
|
||||
> 适用范围：新 S+ 生产内核，统一 `16:9`
|
||||
> 状态：第一阶段已实现并验证
|
||||
|
||||
## 1. 本次目标
|
||||
|
||||
在镜头执行和关键帧生成之前增加正式 `Scene Geography` 合同，机器可验证：
|
||||
|
||||
- 阵营方位、人物站位和视线。
|
||||
- 场景空间区和世界坐标。
|
||||
- 180度关系轴与允许/禁止机位。
|
||||
- 攻击、移动和特效汇聚的起点、路径、方向与目标。
|
||||
- 跨镜连续性、空间锚点和致命禁项。
|
||||
|
||||
解决仅靠自然语言 Prompt 导致的两军不相望、阵营交换、鬼将漂移和攻击己方问题。
|
||||
|
||||
## 2. 新合同
|
||||
|
||||
新增合同：
|
||||
|
||||
```text
|
||||
scene_geography_v1
|
||||
```
|
||||
|
||||
合同上游：
|
||||
|
||||
```text
|
||||
confirmed scene_script
|
||||
-> confirmed asset_plan
|
||||
-> confirmed scene_geography
|
||||
-> shot_execution
|
||||
```
|
||||
|
||||
合同包含：
|
||||
|
||||
- `scene_geographies[]`
|
||||
- `coordinate_system`
|
||||
- `zones[]`
|
||||
- `placements[]`
|
||||
- `primary_axis`
|
||||
- `camera_positions[]`
|
||||
- `action_vectors[]`
|
||||
- `blocking_beats[]`
|
||||
- `continuity_locks[]`
|
||||
- `forbidden_outcomes[]`
|
||||
- `required_spatial_anchor_refs[]`
|
||||
- `acceptance_criteria[]`
|
||||
|
||||
## 3. 硬门规则
|
||||
|
||||
确定性校验会阻断：
|
||||
|
||||
1. 非16:9或非米制右手坐标。
|
||||
2. 场景缺少空间区、主体站位或关系轴。
|
||||
3. 活动角色没有世界坐标与朝向。
|
||||
4. 关系轴端点没有对应站位。
|
||||
5. 场景没有安全机位。
|
||||
6. 禁用轴侧机位被标记为允许。
|
||||
7. 攻击向量起止区不存在。
|
||||
8. 攻击回到施法者自身或同一空间区。
|
||||
9. 调度节拍引用不存在的空间区或动作向量。
|
||||
10. 场景地理未覆盖已确认剧本全部场景。
|
||||
11. 空间锚点不属于上游资产计划。
|
||||
12. 镜头未绑定精确地理合同、轴线、批准机位、空间区或动作向量。
|
||||
|
||||
## 4. 执行链变化
|
||||
|
||||
旧链路：
|
||||
|
||||
```text
|
||||
asset_plan -> shot_execution
|
||||
```
|
||||
|
||||
新链路：
|
||||
|
||||
```text
|
||||
asset_plan
|
||||
-> scene_geography
|
||||
-> shot_execution
|
||||
-> approved keyframe
|
||||
-> immutable Generation Plan
|
||||
-> video candidate
|
||||
```
|
||||
|
||||
`materializeExecutionDraft` 现在只接受已确认的 `scene_geography`，不能再使用资产计划绕过导演空间门。
|
||||
|
||||
## 5. Prompt 编译
|
||||
|
||||
新增地理调度专用 Prompt Builder，要求模型只完成 Production Designer 与 Blocking Director 工作：
|
||||
|
||||
- 不切分镜。
|
||||
- 不写视频 Prompt。
|
||||
- 不生成图片。
|
||||
- 不改剧本和对白。
|
||||
- 逐场输出坐标、空间区、站位、轴线、机位、动作向量与验收标准。
|
||||
- 巨型召唤物必须绑定召唤方上方或后方。
|
||||
- 攻击必须有可验证的 source、target、world direction 和 screen direction。
|
||||
- 禁止视觉上攻击自己。
|
||||
|
||||
## 6. 前端
|
||||
|
||||
S+ 生产合同页新增“场景地理”阶段，位于“资产计划”和“镜头执行”之间。
|
||||
|
||||
页面可查看：
|
||||
|
||||
- 世界布局和坐标轴。
|
||||
- 空间区和人物站位。
|
||||
- 主轴、越轴政策和批准机位。
|
||||
- 攻击与特效动作向量。
|
||||
- 禁止结果与验收条件。
|
||||
- 完整 AI 提交参数仍通过高级请求查看器展开。
|
||||
|
||||
## 7. 项目 #22 实证
|
||||
|
||||
`诸葛亮与司马懿斗法` 第一集已建立：
|
||||
|
||||
- 场景剧本：`#15`
|
||||
- 资产计划：`#16`
|
||||
- 场景地理：`#17`
|
||||
- 状态：`confirmed`
|
||||
- 硬门评分：`100/100`
|
||||
- 场景覆盖：4/4
|
||||
|
||||
项目文档：
|
||||
|
||||
- `data/诸葛亮与司马懿斗法/20.第一集场景地理与人物调度圣经V1.md`
|
||||
- `data/诸葛亮与司马懿斗法/21.第一集分镜执行重切V2待确认.md`
|
||||
|
||||
本次未触发任何付费图片或视频生成。
|
||||
|
||||
## 8. 代码范围
|
||||
|
||||
- `backend/src/production-kernel/contracts/production-contracts.ts`
|
||||
- `backend/src/production-kernel/validators/production-contract-validators.ts`
|
||||
- `backend/src/production-kernel/production-stage-prompt-builder.service.ts`
|
||||
- `backend/src/production-kernel/production-kernel.dto.ts`
|
||||
- `backend/src/production-kernel/production-kernel.service.ts`
|
||||
- `backend/src/production-kernel/fixtures/neutral-production-fixtures.ts`
|
||||
- `user-app/src/api/client.ts`
|
||||
- `user-app/src/components/production/SplusProductionPipeline.vue`
|
||||
|
||||
## 9. 验证
|
||||
|
||||
```text
|
||||
production-kernel.spec.ts 14 passed
|
||||
production-kernel.service.spec.ts 12 passed
|
||||
focused production-kernel tests 26 passed
|
||||
backend TypeScript build passed
|
||||
scene geography contract #17 hard gate 100/100
|
||||
```
|
||||
|
||||
## 10. 下一步
|
||||
|
||||
1. 人工确认第一集10镜重切稿。
|
||||
2. 编译10份 `shot_execution_v1`，全部绑定合同 `#17`。
|
||||
3. 先做第1-3镜空间关键帧联系表。
|
||||
4. 对空间关键帧执行阵营、轴线、鬼将归属和攻击方向专项 QC。
|
||||
5. 全部通过后才允许视频候选生成。
|
||||
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
Reference in New Issue
Block a user