lingxi/docs/评估/平台电商素材生产平台_整合可行性评估_V0.1.md

平台电商素材生产平台 · 双项目整合可行性评估

文档类型：技术 + 产品可行性评估（评审稿） 版本：V0.1 rev.2　|　状态：待评审　|　日期：2026-10-30 评估对象：参考项目/dewu-material-Downloader/（得物素材助手 v2.7.0）、参考项目/sucaigongfang/（素材工坊 v1.0.0） 依据文档：docs/PRD/平台电商素材生产平台_PRD_V0.1.md 密级：内部　|　注意：本文及两份调研报告引用了得物星光平台的接口路径、签名机制与登录方式，属平台敏感信息，不可外发客户或平台方 配套调研：docs/评估/_调研/dewu-调研报告.md（726 行）、docs/评估/_调研/sucaigongfang-调研报告.md（740 行）

评审输入更新（2026-10-30，rev.2）： ① 项目定位为内部平台（仅内部人员使用），但部署方式为公网可访问 + 登录鉴权； ② 设计资产（PSD 模板 / 展示方式 / 促销模板）由设计师角色提供，M1 前可给 ≥5 个真实模板 + 规范； ③ 客户已授权我们使用其平台账号（待补书面授权文件与范围），平台侧封禁风险由客户承担。 注意：① 只解决"我方平台合规"，不等于平台方允许服务端自动化；③ 降低但不消除平台条款残余风险（见 §5.7 / §10.1 D-09）。

技术栈定稿（2026-10-30）：见 docs/技术架构/技术栈架构_定稿_V1.0.md。相对本评估，ORM 由 Sequelize 改为 Prisma 7.10.1（+812 人日），UI 改为 Semi 2.104 + Tailwind 4；本评估 WBS 已同步为 **391581 人日**、首期闭环 288~426 人日。

---

阅读指引

• 只想看结论：读 第 0 章与第 11 章。
• 要判断做不做、先做什么：读 第 3、4、5、8 章。
• 要判断投多少人力/多少钱：读 第 7 章。
• 要拍板：读 第 10 章（决策项 + 待确认问题）。
• 本文所有数字都有口径；证据等级标注为 【代码】（直接读源码确认）、【文档】（项目文档记载）、【实测】（历史项目真机/抓包验证记录）、【推断】（基于结构的判断，需 POC 确认）。

---

0　执行摘要

0.1 一句话结论

两个项目整合为一个统一 WEB 平台在技术与产品上都成立，且互补性远大于重叠性；但这不是"合并两个仓库"，而是"以新建统一工程为骨架，把两个项目分别作为「生产产线」与「投放作业端」的资产源迁入"，其中图片产线代码级复用约 60%~70%，得物投放作业端约 50%~60% 需服务端重写，视频 AI 产线是 100% 新建。

结论：有条件 Go（建议立项），前置条件是 4 个必需 POC（POC-14）+ 3 个支线 POC（POC-57）+ 1 份客户书面授权文件**（客户已同意我们使用其平台账号，待补文件与授权范围）。安全侧需按"公网可访问"加固。设计资产供给已确认由设计师角色提供（M1 前 ≥5 个真实模板 + 规范）。**

0.2 三个关键判断

#	判断	依据	影响
1	形态成立：统一 WEB 端可行，Electron 桌面端可以停止演进	得物侧「读」链路已在裸 Node 实测可复现（签名 + 只读接口），「写」链路（送审）可服务端化：项目当前选择页面自动化（技术上也可重放写接口，但成本与风控更高，需 POC 择一）；项目负责人已确认「彻底 Web 化」	桌面端专属能力（自动更新/签名/窗口/Cookie 同步等）全部废弃，Electron 主进程约 1.7 万行需重写或废弃（纯逻辑抽包保留）
2	互补成立：两项目拼起来正好是 PRD 主链路的两端，工程层重叠估计约 15%~20%	dewu 覆盖「选品 → 原始物料 → 提审 → 投放链接」；scgf 覆盖「模板 → 批量图片生产 → 命名 → 导出」；重叠集中在登录/权限/配置/队列/通知等工程层	整合的主要工作量在"接缝"（物料库、命名/提审、平台抽象），而不是"去重"
3	差距成立：PRD 是目标态，现状距目标仍有明显缺口	按 PRD 表 1-3 的 27 项功能框架逐条比对：完全满足 1 项、部分满足 12 项、完全空白 14 项（§4.1）；P-02 四层信息、P-03 视频、P-06 多平台、P-07 资产中心是主要缺口	首期不能承诺"PRD 全量 P0"，必须做范围裁剪（§4.4 / §8）

本次评审输入带来的变化（rev.2）：

输入	结论	对方案的影响
内部平台、不对外部用户开放	单租户、内部账号体系；但部署为公网可访问（带登录鉴权）	省去多租户约 23 人日，但新增公网安全加固 48 人日（已单列 §7.2 第 28 项）；平台侧自动化风险仍按 R-01 管理
设计资产由设计师角色提供，M1 前可给 ≥5 个真实模板 + 规范	A-01 成立，设计资产不属于研发交付物	P-02 具备闭环前提；M1 可直接用真实模板做 POC-4 与回归；规范不到位仍会阻塞出图
客户已授权我们使用其平台账号	账号使用权与封禁风险由客户承担（待补书面文件与授权范围）	D-09 从"Go/No-Go 未知"降为"已确认、待文件"；仍需保留半自动降级与一键停用

0.3 推荐方案（评审主选项）

方案 C：新建统一工程 + 双项目资产迁移（与您已确认的技术底座选择一致）

              ┌──────────────────────────────────────────────────────┐
              │  统一 WEB 端（React 19 + Semi Design + Tailwind）      │
              └───────────────┬──────────────────────────────────────┘
                              │ HTTPS / SSE
      ┌───────────────────────┼───────────────────────────┐
      │                       │                           │
┌─────▼─────┐          ┌──────▼──────┐             ┌──────▼──────┐
│  API/BFF  │          │ 图片渲染     │             │ 平台作业     │
│  Express5 │          │ Worker       │             │ Worker       │
│  PG/Redis │          │ (sharp/PSD/  │             │ (Playwright: │
│  BullMQ   │          │  抠图)       │             │  登录/送审/   │
└─────┬─────┘          └──────────────┘             │  审核/投放)   │
      │                                             └──────────────┘
      │                    ┌──────────────┐
      └────────────────────┤ AI Worker     │
                           │ 生图/视频     │
                           └──────────────┘

• 复用 scgf：后端工程地基（认证/权限/客户范围/系统配置/迁移/队列/事件/失败目录/通知/打包）、PSD 解析与合成引擎、抠图、命名引擎、任务与可观测体系（约 80~115 人日迁移改造）。
• 复用 dewu：21 个纯逻辑库（星光签名、命名解析、混剪规则、审核 CSV、DPLink 拼装、远端配置 schema）、只读接口层、商品详情 SSR 直取、送审批次策略、页面交互信息架构（约 60~85 人日迁移改造 + 服务端化）。
• 新建：多平台抽象、平台账号/凭据中心、选品与物料库、图片多资产渲染（Logo/促销/AI 模特/脚模）、提审工作流、投放配置、AI 生图产品化、视频 AI 产线、对象存储、Worker 拆分（约 215330 人日）。三类口径有交叉，不作为严格加总；**合计 391581 人日**（严格以 §7.2 逐项加总为准；含 ±25% 不确定性，不含人力成本）。

0.4 首期范围建议（图片先行）

建议首期（MVP，得物单平台）闭环： 平台切换(仅得物) → SPUID 检索/圈选 → 原始物料（主图/详情图/主视频）入库 → 模板 + 三规格 + 商品图 + Logo/促销四层合成 → 批量预览/导出（按路径/命名） → 提审清单与状态 → DPLink 一键复制

M3 多平台：唯品会适配、平台切换、新增平台机制。 M4 AI 增强：AI 生图产品化、资产中心、投放配置（DP/承接页）扩展、混剪送审。 M5 视频产线：脚本 → 画面 → 组合；数据看板随后。

0.5 关键数字速览

指标	数值	口径
两项目代码总量	约 12.9 万行代码（dewu 65,253 含 MJS/CJS 脚本 / scgf 63,632 含 CSS）	口径见两份调研报告 §7.1 / §6.1
两项目数据模型	dewu 无数据库（本地 JSON/JSONL）；scgf 19 张表 / 11 个迁移	scgf 方案可直接作为统一库起点
两项目接口/通道	dewu 101 条 IPC（87 invoke + 14 event）；scgf 约 113 个 HTTP 接口 / 17 个 Router	统一后全部收敛为 HTTP/SSE
两项目测试	dewu 32 个 verify 脚本、15,411 行（无单测框架）；scgf node:test 175 用例，无 DB/E2E	统一后需补契约测试与渲染回归
功能框架覆盖	PRD 表 1-3 共 27 项：完全 1 / 部分 12 / 空白 14	§4.1 逐条
首期闭环工作量（M0 + MVP-1 + MVP-2）	约 288~426 人日（AI 辅助），传统估算约 411~609 人日	§7.2
全量平台工作量	约 391~581 人日（AI 辅助），传统估算约 559~830 人日	§7.2
建议人力/周期	3 人 + AI：首期闭环约 5.5~8.5 个月、全量约 8~11.5 个月；2 人：8.512.5 / 11.517.5 个月；1 人：1725.5 / 2334.5 个月	§7.3/§8.1

人日为"一名熟悉本仓库的工程师全职投入"的量级估算，非承诺值；AI 辅助系数按 0.65~0.8 折算，M0 结束后必须用真实任务校准（§7.4）。

---

1　评估范围与方法

1.1 评估对象

项目	形态	定位	版本/基线	代码量	成熟度
dewu-material-Downloader	Electron 44 桌面双端（Win 主力 / mac 开发验证）	得物星光平台软广素材的桌面运营工作台：素材下载 + 商品查询 + 素材审核 + 批量/混剪送审 + DPLink	v2.7.0，HEAD fe7646b，228 commits，2026-05→10	65,253 行代码（src 19,120 / electron 17,345 / scripts 27,828 / release 875 + 根目录构建配置 85）	功能闭环，真机覆盖不均；无单测框架，靠 32 个 verify 脚本 + CI 门禁
sucaigongfang	Web 全栈（pnpm workspace，前后端双包）	图片素材自动化生产系统：PSD 模板 → 商品图 → 批量合成 → 命名 → 打包交付	v1.0.0，HEAD d1b01fa，249 commits，2026-03→09	63,632 行 TS/TSX/CSS（后端 30,835 / 前端 32,797）	可部署生产态（容器化 + 反代 + 回滚）；175 个纯函数单测；AI 能力仅验证未产品化

1.2 评估依据与方法

依据	说明
源码通读	两份调研报告基于逐目录、逐模块只读通读；关键结论附 文件:行 证据（合计 105 条）
项目文档	dewu 30 篇 14.6k 行、scgf 33 篇（但 docs/ 被 .gitignore 忽略、0 入库）；文档与代码冲突处以代码为准
git 历史	提交数、tag、活跃度、分支（scgf 的 backup/ai-asset-m1 分支约 10 万行、已声明作废）
历史实测记录	星光接口登录通道实测 9/9；签名自校验 + 抓包 fixture 门禁；送审非混剪真机 1 条端到端；DPLink 4/4 逐字符复现；AI 生图 34/34 成功等
PRD	仅 1.1/1.2 有实质内容，210 章为空模板；本文只按 1.1 问题表（P-01P-07）与 1.2 功能框架（表 1-3）做覆盖度比对
未做	未安装依赖、未运行构建/测试、未做真机验证、未向平台方求证、未取得 AI 供应商报价。所有"可行性"判断为代码级判断，需以 §6 的 POC 结论替代

1.3 术语对齐

统一使用 PRD 术语：平台 / 选品 / 原始物料 / 模板 / 展示方式 / 脚本 / 提审 / DP / 承接页 / 配置信息；"产线"指图片产线、视频产线；"作业端"指平台侧操作（登录、下载、送审、审核、投放链接）。

---

2　两个项目的现状画像

2.1 dewu-material-Downloader（Electron 桌面端）

2.1.1 它实际是什么

名称是"下载器"，但 v2.x 已演进为得物星光平台的桌面运营工作台，五段闭环：

① 登录（接口验证码登录 / 浏览器兜底 / 云端 Cookie 同步）
② 选品（素材下载页按 SPUID 筛选；商品查询页支持 SPUID/链接/App 分享文本）
③ 原始物料（视频：媒体任务ID-视频ID-SPUID-类目-授权期.mp4；商品图/主视频：按商品目录归档）
④ 提审（命名解析 → md5 查重 → 预检 → 批量/混剪送审 → 审核状态查询 → 审计）
⑤ 投放（DPLink：iOS UniversalLink / 安卓 DeepLink 一键复制）

2.1.2 技术架构

层	选型	说明
渲染层	React 19.3 + Semi Design 2.103 + Tailwind 3.4 + react-router 6（HashRouter）	6 个一级页面；无全局状态库，3 个 Context
主进程	Electron 44 + TypeScript strict	101 条 IPC；contextIsolation + preload 白名单
关键能力	Playwright 1.60（声明 ^1.40，已漂移）+ 直连 CDN + safeStorage + basic-ftp	浏览器会话、上传、加密凭据、Cookie 云同步
数据	无数据库：config.json / cookies.json / dplink-*.json / platform-cache/*.json / submit-audit.jsonl / logs/	全部本机 userData，原子写；多处 safeStorage 加密
发布	electron-builder + electron-updater + Ed25519 三把密钥（远端配置 / 更新元数据 / 浏览器 manifest）	Windows NSIS / macOS dmg + 签名公证

2.1.3 与 PRD 的覆盖关系（重要）

PRD 问题	覆盖度	说明
P-01 原始物料	部分（仅得物）	商品图/主视频/视频素材库均可抓取并归档；无"本次选品物料库"概念
P-02 图片制作	0	全仓无 PSD、无模板合成、无三规格产出
P-03 视频制作	0	无脚本、无 AI 视频；只有"下载已有视频"
P-04 命名提审	部分（提审强、命名固定三字段）	提审链路完整（预检 + 批量送审 + md5 幂等 + 审核查询 + 审计）；命名固定为 {媒体任务ID}-{视频ID}-{SPUID} 末三段解析，不支持 PRD 要求的自定义字段组合
P-05 投放配置	部分（仅 DPLink）	只做商品 → 唤端链接拼接与复制；不含 DP 编写、承接页字段批量替换
P-06 多平台	0	全仓检索 唯品会 / vipshop / vip.com 零命中
P-07 资产管理	0	无模板/Logo/脚本资产库

2.1.4 最有价值的可迁移资产

资产	位置	价值
星光请求签名（含 salt）+ 启动自校验	scripts/lib/platform-sign.mjs、electron/platform/sign.ts	服务端直连星光的关键；盐变更可第一时间发现
平台字段映射 / 授权时间解析 / 审核状态映射	scripts/lib/platform-material-mapping.mjs（719 行）	与真实抓包逐字段对齐
送审命名解析 + 预检/载荷/审计形状	scripts/lib/submit-naming.mjs（1,013 行）	直接对应 PRD P-04，含大量真实样本
混剪业务规则	scripts/lib/mix-submit.mjs	混剪配对/授权状态/结构校验唯一实现
DPLink 双层拼装	scripts/lib/dplink-link.mjs	4/4 样本逐字符复现；依赖独立的星光硬广账号（软广账号调 list-landing 会 401）
只读接口层（签名/信封/缓存/授权预检）	electron/platform/*（2,526 行）	改造成服务端 SDK 成本低
商品详情 SSR 直取	electron/shop/detail.ts	无需浏览器，服务端可直接复现
送审批次策略层（串行/中断/回查/幂等/审计）	electron/submit/{batch,plan,verify,idempotency,audit}.ts	写链路业务策略，独立于 Playwright
API 文档（含 106 条接口枚举、选择器、错误码）	docs/星光平台API接口文档.md（807 行）等	服务端复现的唯一权威资料

2.1.5 必须重写 / 废弃的部分

• Electron 外壳：内嵌 <webview> 商品 H5 + 净化模式（Web 端受 X-Frame-Options/CSP 限制，无等价物）、本地文件路径/dialog、系统通知/剪贴板/打开目录、safeStorage、自动更新/代码签名/窗口状态、旧版本清理、HTTP GET 拉取 + FTP 上传的 Cookie 云同步（v2 双分区）。
• IPC 层：101 条通道 → HTTP + SSE/WebSocket；契约可参考，实现重写。
• 本地 JSON 基础设施：config/cookies/cache/账本/审计/下载目录 → 数据库 + 对象存储 + 凭据服务。
• 服务端浏览器：Playwright 会话管理、送审页面自动化（submit/page.ts 1,824 行）必须重写为服务端浏览器池 + 账号分布式锁 + 大文件上传通道。
• UI：Semi 组件与 .semi-* 样式深度绑定，新平台若换 UI 库则组件层需重写（§5.5）。

2.1.6 成熟度与质量

• 优点：TypeScript strict 全开；32 个验证脚本 + 3 个 CI job；真实抓包 fixture；大量"为什么这么写 + 踩过什么坑"的注释；读写分离、超时只回查、幂等账本等业务红线清晰。
• 问题：无 vitest/jest，无 ESLint/Prettier；非混剪送审已真机成功 1 条、混剪「是」写链路未真机；大文件上帝模块（DownloadPage 2,241 行、browser/manager 1,962 行）；electron/config/developer.ts:130,135 仍硬编码 Cookie 同步密钥与 FTP 密码（且在 git 历史中）；本地 MD5 全量同步扫描是性能债。
• 官方自评（docs/项目评估与优化建议-2.1.0.md）健康度 3.0/5（产品完成度 4.5、安全信任链 2.0、测试质量 2.0、性能 3.0）。

2.2 sucaigongfang（Web 全栈）

2.2.1 它实际是什么

面向信息流广告投放（电商唤端 + 券商）的图片素材批量生产线：

① 管理员：建客户 → 建用户并绑定客户/角色 →（可选）客户级命名规则
② 设计师：上传 PSD → ag-psd 解析 → 逐图层绑定「图片替换/文本替换/剪贴蒙版」→ 预览图 → 归客户/分类/标签/规格
③ 优化师：选模板（可多选）→ 上传商品图（≤100）→ 文件名识别商品ID/名称/品牌 → 表格可编辑
          → 生产参数（抠图/尺寸/JPG/缩放/字号）→ 二次确认提交
④ 系统：建批次（N 模板 × M 商品图 交叉）→ 命名快照 + 预渲染文件名 → BullMQ
⑤ Worker：白底判定 → imgly/ONNX 抠图 → MaterialComposer 合成 → materials 落库 → WS 推送
⑥ 收尾：站内信 → ZIP 打包 → 下载；任务列表/详情/时间线/失败目录/CSV

2.2.2 技术架构

层	选型	说明
前端	React 19.2 + Arco Design 2.66 + Tailwind 4 + zustand + axios + router 7 + Vite 8	16 个页面；113 个 API 方法；设计 token 单点 + CI 静态校验
后端	Node 24 + Express 5 + Sequelize 6 + PostgreSQL 18 + Redis/BullMQ + ws	API 与 Worker 同进程；19 表 / 17 Router / 约 113 接口
图像	ag-psd 30 + @napi-rs/canvas + sharp 0.32.6（锁版）+ fontkit + imgly/ONNX	PSD 解析/合成/字体兜底/抠图
导出	archiver（ZIP level 9）+ CSV + 按需 WebP 缩略图	异步打包 + 选集下载
部署	双镜像（Node 24-slim / nginx 1.27）+ 1Panel PG/Redis/OpenResty + 备份/回滚脚本	单机、本地磁盘 uploads

2.2.3 与 PRD 的覆盖关系

PRD 问题	覆盖度	说明
P-01 原始物料	0	无抓取；商品图靠本地手工上传
P-02 图片制作	约一半	有"模板 + 商品图 + 文本层"，缺 AI 模特/脚模、Logo 组合、促销图层、三档规格固定语义；规格是通用 (w,h)
P-03 视频	0	全仓无视频/ffmpeg
P-04 命名提审	命名全覆盖、提审 0	命名引擎成熟；无提审清单/状态机
P-05 投放配置	0	无 DP/承接页/链接
P-06 多平台	0	系统无"平台"维度（"得物"仅出现在通知模板示例文案）
P-07 资产管理	部分	模板/分类/标签/规格/批次模板强；Logo/展示方式/脚本无

2.2.4 最有价值的可迁移资产

资产	位置	价值
工程地基	17 Router / 19 模型 / 11 迁移 / 健康检查 / 进程兜底	统一平台后端约 70% 非业务工作量
认证与账号安全	JWT + pwdv 口令版本、强制改密、三态口令有效期、一次性随机口令、IP+用户名限流、审计	安全设计高于平均水平，直接复用
RBAC + 客户范围	权限 key 目录 + fail-closed 客户范围 + 全链路校验	升级为"平台 × 客户"双层范围即可
系统配置框架	40 项 / 10 模块 / L1-L3 生效级别 / 审计 / 专用控件	最值得整套继承的机制；加 platform/ai/video 模块即可
PSD 合成引擎	utils/materialComposer.ts（1,773 行）：15 种混合模式、剪贴蒙版、三档缩放、字体兜底、JPG 二分质量 / PNG 调色板压缩	全项目最贵资产；但只支持单一商品图入参（§6.1 第 3 项）
抠图	imgly/ONNX + 白底判定 + 降级告警	失败会标 low_quality_warning，不静默交付
任务与可观测	BullMQ 2 队列 + DB 计数 + WS 节流 + 失败口径分轮次 + 事件目录 + 失败目录 + 90 天保留 + 卡死巡检	统一任务中心底座
命名引擎	变量模板 + 客户级 + 批次快照 + 校验 + 商品图识别三层兜底	PRD P-04 的一半
导出/打包	CSV（BOM 防乱码、1 万条上限）+ 选集 ZIP + 整批异步 ZIP	按路径导出可直接改造
通知	5 类可配模板 + 站内信 + WS 触发	需补独立通知中心页与提审/投放事件
前端设计体系	token 单点 + verify-design-tokens.mjs CI 硬卡 + AdminLayout/守卫/共享组件	迁移为统一设计系统

2.2.5 必须重写 / 废弃的部分

• AI 能力全部不算数：main 分支没有任何 AI 产品代码；M0（VLM 反推/图层分离）验证完成、M1 分支 53 commits 约 3.1 万行已被官方声明整体作废、M2-0（Seedream 表单式生图）验证完成但产品代码从零开始（§6.1 第 4 项）。
• 素材制作页（2,625 行）与首页 Dashboard：信息架构按新 PRD 完全变化，需重写；可复用"上传识别 + 字段表格 + 参数 + 二次确认"的逻辑。
• 单进程架构：API 与 Worker 同进程、本地磁盘、内存限流，无法支撑"多产线 + AI"（§6.1 第 7 项）。
• 菜单/路由/权限三处硬编码：加一个模块要改 4 处，新平台应配置驱动。
• 文件存储：纯本地磁盘、无 OSS 适配层。

2.2.6 成熟度与质量

• 优点：容器化 + 备份/回滚 + 6 步 CI 硬卡；175 个纯函数单测；fail-closed 数据范围；系统配置/任务事件/失败目录等治理机制成熟；大量注释记录"踩过的坑"。
• 问题：docs/ 整体 gitignore（110 个文件 0 入库），AI 验证结论与部署手册只在本机；无 DB/HTTP 集成测试、无 E2E、PSD 渲染无回归；渲染引擎与抠图单机内存峰值；API/Worker 同进程；SystemConfigAudit 不脱敏导致 AI Key 不能进配置；字体 方正兰亭中黑简体 商用授权待确认。

2.3 横向对比

维度	dewu-material-Downloader	sucaigongfang	对整合的含义
端形态	Electron 桌面双端	Web 全栈	统一为 Web，桌面能力重写/废弃
业务段	选品 / 物料 / 提审 / 投放	模板 / 生产 / 命名 / 导出	互补，接缝在物料与命名/提审
平台覆盖	得物（星光）单平台	无平台概念（客户维度）	多平台抽象是新建
数据层	无 DB（JSON/JSONL）	PostgreSQL 19 表 + Redis	以 scgf 数据层为起点
任务层	Electron 主进程内串行	BullMQ + DB 计数 + WS	统一任务中心，Worker 拆分
认证/权限	无用户体系（单机单账号 + 平台凭据）	JWT/RBAC/客户范围/审计	以 scgf 为起点，加平台账号维度
UI	Semi Design 2 + Tailwind 3	Arco Design 2 + Tailwind 4	需统一（§5.5）
测试	32 个 verify 脚本（无单测框架）	175 个 node:test（无集成/E2E）	互补：纯逻辑 + 契约测试
文档	30 篇、14.6k 行，已入库	33 篇，未入库	整合第一件事是文档抢救入库
主要风险	平台合规/账号单会话/接口稳定性	单机架构/渲染引擎/字体版权	两类风险叠加，需分别治理

---

3　能力重叠、互补与空白分析

3.1 功能域对照矩阵

图例：✅ 完整　🟡 部分　❌ 无　— 不适用。仅列能力域，不含页面级细节（页面清单见两份调研报告 §2）。

能力域	dewu	scgf	PRD 是否要求	统一平台建议
登录 / 用户 / 角色 / 权限	❌（单机无用户体系，只有平台登录态）	✅ JWT + RBAC + 客户范围 + 口令安全	隐含（多角色：设计/优化/运营/管理）	以 scgf 为起点，补平台账号授权
客户 / 品牌归属	❌	✅ 客户 + 用户绑定 + fail-closed 范围	隐含（多品牌 Logo、唯品会）	升级为"平台 × 客户 × 项目"
平台切换 / 多平台	❌ 仅得物	❌ 无平台概念	✅ P0	新建
选品检索（SPUID / 粗词）	🟡 得物 SPUID / 链接 / 分享文本	❌	✅ P0	迁移 dewu 商品查询并扩粗词
选品圈选 / 历史选品	🟡 多 SPUID 列表，无"选品批次"	❌	✅ P0/P1	新建选品批次/圈选模型
原始物料抓取 / 归档	🟡 抓取完整（得物）、归档仅本地目录	❌ 靠手工上传	✅ P0	迁移并接入物料库 + 对象存储
物料库 / 商品快照	❌ 落本地目录	❌	隐含	新建（统一主数据）
PSD 模板管理 / 图层契约	❌	✅	✅ P0	迁移 scgf，加平台/客户归属
模板渲染合成	❌	✅ 单商品图（1,773 行）	✅ P0	改造为多资产图层（核心工作）
展示方式（AI 模特 / 脚模 / 设计导入）	❌	❌（只有单商品图）	✅ P0	新建资产类型 + 渲染分支
商品位置（固定 / AI 调优）	❌	🟡 固定位置已支持（由替换图层 bbox 决定）；AI 调优 ❌	✅ P0	补 AI 调优，列 P1
Logo 主/副 + 拼接字符	❌	🟡 标签 logo 字段存在但未接入合成	✅ P0	新建组合式 Logo 资产 + 渲染
促销信息（折扣/活动标识）	❌	🟡 文本层可放文案，无促销模板	✅ P0	新建促销图层/模板
三规格（800² / 1280×720 / 1080×1920）	❌	🟡 通用 (w,h) 规格	✅ P0	固定枚举 + 可扩展规格
批量出图 / 预览	❌	✅ N 模板 × M 商品交叉批量	✅ P0/P1	迁移生产页与批量逻辑
命名规则引擎	🟡 送审命名固定三字段（末三段解析）	✅ 变量模板 + 客户级 + 快照	✅ P0	合并为统一命名引擎（两套变量域，补自定义字段组合）
导出 / 打包 / 下载	🟡 按路径落本地	✅ ZIP/CSV/选集下载	✅ P0	对象存储 + 导出中心
提审（内部待审清单/状态）	🟡 只有平台侧审核查询	❌	✅ P0	新建内部提审工作流
批量送审（平台写操作）	🟡 非混剪真机 1 条；混剪「是」未真机	❌	隐含（PRD 提审）	服务端重写 Playwright
审核结果查询 / 驳回原因	✅	❌	隐含	迁移只读接口层
投放配置 / DP / 承接页	🟡 仅 DPLink	❌	✅ P0	迁移 DPLink + 新建 DP/承接页配置
视频脚本（AI/人工）	❌	❌	✅ P0	新建
视频生成（画面/组合）	❌	❌	✅ P0	新建
脚本/动作模板资产	❌	❌	✅ P0	新建
AI 生图	❌	❌ 仅 M2-0 验证资产，无产品代码	间接（替代实拍）	从零产品化
资产中心（模板/Logo/展示/促销/脚本）	❌	🟡 模板/分类/标签/规格	✅ P0	扩建
系统配置中心	🟡 本机配置 + 远端配置	✅ 40 项/L1-L3/审计	隐含	迁移 scgf
任务队列 / 实时进度	🟡 Electron 主进程串行	✅ BullMQ + WS	隐含	迁移并拆 Worker
通知 / 站内信	❌（只有系统通知）	✅ 铃铛下拉 + 模板	隐含	迁移 + 扩展事件
日志 / 审计 / 可观测	🟡 本地日志 + JSONL 审计	✅ 事件目录/失败目录/时间线	隐含	合并为统一可观测
文件存储 / CDN	🟡 本地目录	🟡 本地磁盘	隐含	对象存储适配层（新建）
多租户 / 数据隔离	❌	🟡 客户范围（非多租户）	隐含	首期单部署 + 范围隔离

3.2 重叠项：整合时要防止"重复建设"

两项目在工程层有约 15%~20% 的功能重叠，但实现质量与语义不同，不能简单保留两份：

重叠域	dewu 实现	scgf 实现	统一建议
任务队列 / 进度	Electron 主进程内存队列 + IPC 事件	BullMQ + DB 计数 + WS 推送	采用 scgf 模型，补 dewu 的"串行/中断/超时只回查/幂等账本"语义
命名	送审命名（媒体任务ID-视频ID-SPUID）	生产命名（变量模板/客户级/快照）	合并为一个引擎，两套变量域 + 两套校验规则
配置管理	本机 JSON + 远端签名配置	DB 配置中心 + L1-L3 + 审计	采用 scgf，补"远端配置/运维开关"能力
日志 / 审计	本地日志文件 + JSONL 审计	控制台文本日志 + 事件目录 + 任务日志（结构化日志是新工程要补的）	采用 scgf 事件模型，保留 dewu 的"只追加审计"语义
通知	系统通知（下载完成）	站内信 + 模板	采用 scgf，扩展提审/投放/失败事件
素材/文件管理	本地目录 + 文件名规则	uploads 目录 + 缩略图 + 清理	统一对象存储 + 资产表 + 生命周期策略
登录态	平台 Cookie/token（safeStorage）	系统 JWT	两个不同概念，都要：系统账号 + 平台账号（凭据中心）

重复建设的典型陷阱：如果按"两个项目各自保留"的方式合并，会出现两套任务表、两套命名、两套审计、两套权限，半年后无法维护。新工程必须"一套任务中心 + 一套资产表 + 一套权限"。

3.3 互补项：整合真正的价值在"接缝"

接缝	上游（dewu）	下游（scgf）	统一后的数据流
商品主数据	商品查询：SPUID/链接/分享文本 → 标题/价格/货号/SKU/主图/详情图/主视频	制作页手工上传商品图 + 填字段	选品时落 product_snapshot，生产直接引用
原始物料	商品图/详情图/主视频/视频素材库 → 本地目录	商品图上传 → 生产	raw_asset + 对象存储，选品即归档
命名规则	送审命名（末三段 = 媒体任务ID-视频ID-SPUID）	生产命名（变量模板 + 客户级）	统一引擎：生产命名 + 提审命名两个 profile，共享校验
素材产出 → 提审	送审需要本地成品文件（mp4，140–190MB）	产出图片素材（ZIP/文件）	material 表统一承载，提审单引用 material，文件在对象存储
投放配置	DPLink（商品 → 唤端链接）	无	投放配置中心：SPUID/官网链接 → DP/承接页/唤端链接

结论：整合不是"选一个项目继续做"，而是把 dewu 的"投放作业端"与 scgf 的"生产端"用统一的商品/物料/素材主数据连接起来。接缝的数据模型设计质量，决定整合成败（§5.6）。

3.4 空白项：必须新建的 8 块

#	空白	影响 PRD 条目	难度	备注
1	多平台抽象 + 唯品会适配	平台切换、新增平台、多平台管理	高（唯品会零参考）	唯品会的登录/接口/提审需从 0 摸底
2	选品批次 / 圈选 / 历史选品	选品模块 P0/P1	中	现有只有"多 SPUID 输入"，无批次概念
3	图片多资产渲染	四层信息（展示方式/Logo/促销）	高	现引擎所有替换图层共用一张商品图
4	提审工作流（内部清单 + 状态）	素材提审 P0	中	dewu 只有平台侧审核查询
5	投放配置（DP/承接页）	投放信息 P0	中	PRD 对 DP 的定义本身待确认
6	AI 生图产品化	产品目标 1/2	高	仅 M2-0 验证，无产品代码
7	视频 AI 产线	视频素材 P0	极高	两项目均为 0，模型/成本/质量均未知
8	对象存储 / Worker 拆分 / 分布式锁	非功能（容量/并发/可靠性）	中高	现架构单机同进程，无法水平扩展

---

4　PRD 覆盖度差距分析

4.1 PRD 表 1-3 功能框架逐条覆盖

口径：以 PRD 表 1-3 的 27 项功能点为基线；"现有能力"取两项目代码实证（不是文档声称）。

#	PRD 功能点	优先级	dewu	scgf	现状结论	差距与建议
1	平台切换：得物 / 唯品会	P0	❌ 仅得物	❌ 无平台概念	完全空白	新建平台上下文；唯品会需从 0 摸底（§6.1 第 6 项）
2	新增平台 / 新增项目	P0	❌	❌	完全空白	平台适配器注册机制 + 资源路径规则
3	商品 ID / SPUID 检索	P0	🟡 得物 SPUID/链接/分享文本	❌	部分（单平台）	迁移商品查询，抽象 PlatformAdapter
4	商品名称（粗词）检索	P1	❌	❌	空白	依赖平台搜索接口，需抓包验证
5	添加本次选品	P0	🟡 多 SPUID 输入	❌	部分	新建选品批次/圈选模型
6	下载原始图片	P0	🟡 得物商品图/主视频	❌ 手工上传	部分（单平台）	迁移 + 对象存储 + 物料库
7	历史选品	P1	❌	❌	空白	选品批次查询/复用
8	品类 / 尺寸 / 模板	P0	❌	🟡 模板 + 通用规格	部分	三规格固定枚举 + 品类维度
9	商品类别：鞋子 / 衣服	P0	❌	❌	空白	品类字典 + 展示方式子菜单
10	展示方式：设计导入 / AI 模特 / AI 脚模	P0	❌	❌（单商品图）	空白	新建资产类型 + 渲染分支；AI 模特依赖生成能力
11	商品位置：固定 / AI 调优	P0	❌	🟡 固定位置由图层 bbox 决定；AI 调优缺	部分	补 AI 调优，列 P1
12	Logo：主 Logo + 副 Logo（拼接方式/字符）	P0	❌	🟡 logo 字段未接入合成	空白（半成品）	组合式 Logo 资产模型 + 渲染器
13	促销信息：折扣 / 活动标识	P0	❌	🟡 文本层可放文案	部分	促销模板/图层 + 资产库
14	按路径导出	P0	🟡 本地目录落盘	✅ 命名 + ZIP + 选集下载	部分（两端各有半套）	对象存储 + 导出中心 + 路径规则
15	批量多图制作与预览	P1	❌	✅ 交叉批量 + 悬停预览	已覆盖（scgf）	迁移 + 接入选品物料
16	历史脚本	P0	❌	❌	空白	脚本表 + 模板 + 版本
17	脚本模板管理	P0	❌	❌	空白	新建
18	脚本 AI 分析	P0	❌	❌	空白	新建（LLM 调用 + 结构校验）
19	脚本生成（选品+模板+数量）	P0	❌	❌	空白	新建
20	动作模板：AI 分析视频方向	P0	❌	❌	空白	新建（视频理解/动作提取）
21	视频生成（脚本+模板+数量）	P0	❌	❌	空白	新建（视频模型 + 组合）
22	提审标签页：待审清单与状态	P0	🟡 平台审核查询	❌	部分（语义不同）	新建内部提审状态机，并保留平台审核同步
23	配置管理：加号新增 / 自定义命名	P0	🟡 落地页配置	❌	部分	新建配置项模型（平台/项目级）
24	一键复制单条配置	P0	🟡 仅 DPLink 场景复制	❌	部分（仅 DPLink）	通用复制 + 权限/审计
25	自动配置：拉取配置 / 自动生成链接	P0	🟡 DPLink	❌	部分（仅 DPLink）	扩展 DP/承接页生成规则
26	批量修改固定字段	P1	❌	❌	空白	配置批量替换 + 预览/回滚
27	资产统一管理（模板/Logo/展示/促销/脚本）	P0	❌	🟡 模板/分类/标签/规格	部分	资产中心扩建（Logo/展示/促销/脚本）

统计：完全满足 1 项（批量多图，来自 scgf）；部分满足 12 项；完全空白 14 项。

这个结果不意外：PRD 是"目标态"，dewu 与 scgf 是两条历史产线的局部最优。如果按 PRD 表 1-3 全量 P0 承诺首期交付，周期与风险都不可控（§4.4）。

4.2 P-01~P-07 问题覆盖度汇总

编号	PRD 问题	dewu	scgf	合并覆盖	判断
P-01	原始物料获取	部分（得物）	0	约 40%	需扩多平台 + 物料库
P-02	图片素材制作（三规格 × 四层）	0	约 50%	约 50%	引擎需支持多资产
P-03	视频素材制作	0	0	0%	完全新建
P-04	命名与提审	提审强、命名固定三字段	命名强、提审 0	约 55%	合并命名 + 新建提审流 + 命名支持自定义字段组合
P-05	账户搭建与投放配置	部分（DPLink）	0	约 25%	DP/承接页待定义
P-06	多平台管理	0	0	0%	完全新建（唯品会零参考）
P-07	素材与模板资产管理	0	部分	约 35%	扩建资产中心

4.3 PRD 自身需要补齐/澄清的地方（给产品评审的输入）

PRD V0.1 目前只有 1.1/1.2 有实质内容，2~10 章为空模板。从研发视角，以下 12 项会在开发中直接变成阻塞：

#	问题	为什么阻塞	建议补充到 PRD
1	目标用户与角色未定义（2.1 空白）	决定权限模型、菜单、数据范围	补设计/优化/运营/管理员四类角色与权限矩阵
2	用户故事/场景未填（2.2）	无法做验收标准	与 1.1 的 P-01~P-07 一一对应
3	成功指标无现状值/目标值（表 1-4 全空）	上线后无法判断成功	先补"现状值"（哪怕估算），目标值可分期
4	本期范围/非范围未写（3.1/3.2）	范围蔓延风险最高	明确"唯品会、视频、AI 生图是否首期"
5	功能详情模板未填（4.2）	无验收标准	优先补 15 条 P0 的主流程/异常/规则
6	非功能需求未量化（5.1 全空）	压测/容量/可用性无法验收	给出并发、P95、存储、RTO/RPO 量级
7	DP 的准确口径未定义	投放配置模块无法设计	明确 DP 是什么、字段、生成规则、样例
8	提审是"平台后台提审"还是"系统内审批流"	决定提审状态机复杂度	明确是否需要内部审核角色/多级审批
9	唯品会零参考	无法评估工作量	提供唯品会后台账号/流程/接口样例
10	视频质量与验收标准未定义	AI 视频无法验收	定义时长、分辨率、口播/字幕、过审标准、样片
11	AI 生成内容的合规要求未写	电商广告合规红线	明确商标/肖像/功效宣称/免责声明要求
12	多租户/数据隔离未定义	决定架构分叉（最大）	明确单部署共享 vs 客户硬隔离

4.4 范围裁剪建议

判断：PRD 表 1-3 的 P0 全量（27 项中 23 项 P0、4 项 P1）不适合作为首期承诺。 建议按下表裁剪：

阶段	交付范围	对应 PRD 条目	退出标准
MVP-1 图片生产主线	平台上下文(得物) + 选品/物料 + 模板/三规格 + 商品图/Logo/促销合成 + 批量/预览 + 命名 + 导出	1(得物)、3、5、6、8、12、13、14、15、27(模板部分)	一个真实商品从检索到导出全流程跑通；用 ≥5 个存量真实模板做回归，渲染差异在阈值内（模板供给见 §4.4 假设）
MVP-2 投放闭环	提审清单/状态 + 批量送审 + 审核同步 + DPLink + 配置管理/一键复制	22、24、25、23(基础)	送审真机成功率 ≥ 95%，审核状态可回查
M3 多平台	唯品会适配 + 平台切换 + 新增平台机制	1(唯品会)、2、4	唯品会完成一次选品→出图→提审验证
M4 AI 增强	AI 生图（补充产线）+ AI 模特/脚模 + 商品位置 AI 调优	10、11、13(增强)	抽样 100 张人工评估通过率 ≥ 80%
M5 视频产线	脚本（AI/人工）→ 画面 → 组合，16:9 / 9:16	16~21	每条链路产出 20 条样片，人工评审通过
P1 增强	历史选品、粗词检索、批量配置替换、资产中心完整	4、7、26、27(完整)	按迭代计划

建议把"视频产线"明确为独立里程碑且不设硬上线日期：它的技术不确定性（模型质量/成本/时长）远高于图片产线，任何"首期必须交付"的承诺都会拖垮整体。

关键假设与当前状态：

编号	假设	不成立时的后果	由谁确认
A-01	设计资产由设计师角色持续供给（PSD 模板/展示方式/促销模板），M1 前提供 ≥5 个真实模板 + 规范	已确认（2026-10-30，含时间点）	产品 + 设计负责人（Q-06/Q-07/Q-08）
A-02a	项目为内部平台，仅内部人员使用；部署为公网可访问 + 登录鉴权	已确认（2026-10-30）：单租户、内部账号；需公网安全加固	产品负责人
A-02b	客户授权我们使用其平台账号做服务端托管与自动送审（D-09）	已确认（2026-10-30，客户授权；待补书面文件与范围）：仍需保留半自动降级；平台方条款的残余风险由业务方接受并留档	业务 + 法务 + 客户（Q-01/Q-02）
A-03	唯品会在首期之外，可按同一适配层接入（不阻塞得物主线）	多平台里程碑需重新评估，但图片主线不受影响	运营 + 客户（Q-03）

---

5　整合方案评估

5.1 候选方案对比

维度	方案 A：以 scgf 为基座扩展	方案 B：保留桌面端 + scgf Web 端	方案 C：新建统一工程 + 双项目资产迁移（您已选）
形态	Web	Electron + Web 双端	Web
复用率	高（scgf 全量）	最高（两端都保留）	中高（后端/逻辑/引擎复用，UI 重写）
前期工作量	低	低	中（多 20~35 人日脚手架/迁移）
架构债	继承单进程/本地磁盘/无平台维度三大债	继承两套架构 + 双端同步成本	可一次性清理
平台账号托管	需补	桌面端可本机登录，Web 端仍需补	集中托管（需合规确认）
长期维护	中	高（双端双栈）	低
数据模型	19 表沿用，加列/加表	两套数据	可重新设计主数据
风险	中（改造成本易低估）	高（双端不一致/人力分散）	中（新建工程量大，但路径清晰）
适合团队	1~2 人、求快	不想动桌面端	1~3 人 + AI 辅助、求长期可维护
结论	不推荐	不推荐（您已确认彻底 Web 化）	推荐

5.2 为什么"新建"不等于"重写"

这是本次评估最需要说清的一点："新建统一工程"是重建骨架与边界，不是重写业务逻辑。

资产类别	迁移方式	估算复用率
scgf 后端工程地基（认证/权限/配置/迁移/队列/事件/通知/导出）	代码级迁移；但数据访问层改 Prisma，模型/查询需重写	60%~75%
scgf PSD 解析/合成/抠图/命名	代码级迁移，渲染器改造	60%~70%
scgf 前端设计体系（token/布局/守卫）	设计思想 + 布局/守卫思路迁移；Arco 组件与 token 校验脚本不复用	20%~30%
dewu 纯逻辑库（签名/映射/命名/混剪/DPLink/CSV）	npm 包级迁移，几乎零改动	90%+
dewu 只读接口层/商品 SSR 直取	抽包 + 服务端化	70%
dewu 送审批次策略（串行/幂等/回查/审计）	逻辑迁移，存储改 DB	60%
dewu Electron 外壳/更新/签名/本地文件	废弃	0%
dewu 页面组件	交互信息架构复用；换 UI 库时组件重写 20%~30%，沿用 Semi 时页面壳/交互层 40%~50%（均不含数据接入）	20%~50%（按前提）
scgf 素材制作页/首页	交互逻辑复用，页面重写	30%~40%
AI 生图/视频	代码从零；验证结论/语料/踩坑记录可复用	代码 0%，验证资产可复用

代价：新建工程需要额外投入约 20~35 人日做 monorepo/CI/环境/迁移框架/部署基线，并承担"迁移期双系统并行"的沟通成本。 收益：一次性解决单进程、本地磁盘、无平台维度、权限模型、对象存储、Worker 拆分等结构性问题，避免在 scgf 旧架构上"边跑边换轮子"。

口径提醒（UI 复用）：任何 UI 库选型都省不掉"页面数据接入重接"——dewu 页面从 window.electronAPI（101 条 IPC）改为 HTTP/SSE、鉴权与数据模型重接，约 30~40 人日；scgf 管理类页面（用户/角色/客户/任务/日志，约 8,300 行）也要按新路由/权限重接。UI 库只影响"组件与样式"这一层：基础层约 8~15 人日 的差异，不应被当作页面整体复用收益。

5.3 技术选型建议

层	建议	理由	备选/注意
语言	TypeScript 全栈（strict）	两端均 TS，类型可共享	后端 strict 需补 noUncheckedIndexedAccess
Monorepo	pnpm workspace + Turborepo（可选）	scgf 已用 pnpm workspace	Node 24.15.0 + pnpm 11.4.0
前端框架	React 19 + Vite	两端现状	不引入 Next.js（纯内网后台，SSR 无收益）
UI	Semi Design 2.104 + Tailwind CSS 4.3 + 自建 token 层	§5.5 专章；Tailwind 4 与 Semi 的层叠需 M0 Spike 验证	不选 shadcn/ui（除非补设计师）
前端状态	zustand（会话/配置）+ TanStack Query（服务端状态）	scgf 只有 zustand，复杂列表/轮询需要缓存层	也可先用 axios + 手写 hooks，避免过度设计
表单/校验	react-hook-form + zod（或 Semi Form + zod）	表单密集（模板/配置/投放）	zod schema 与后端共享
后端框架	Express 5（沿用 scgf）	中间件/错误处理/上传/WS 可直接迁移；重写为 Nest/Fastify 收益低于成本	若追求性能可评估 Fastify，但不建议首期换
ORM	Prisma 7.10.1 + @prisma/adapter-pg	类型/迁移一体；19 表模型需重写（+8~12 人日，见技术栈定稿）	稳定线；8.x 仍 RC，不采用
数据库	PostgreSQL 18（18.4）	开发机已有 Docker	JSONB 用于图层契约/配置/快照；PG18 原生 uuidv7()
队列	BullMQ + Redis	现有；按产线拆队列	队列：image-render / platform-task / ai-image / ai-video / export
浏览器自动化	Playwright（服务端 Worker）	客户端单机已验证；服务端 Worker 待 POC-1；送审默认页面自动化（可评估直连备选）	独立 Worker 进程 + 账号级分布式锁 + 并发上限
图像处理	sharp + @napi-rs/canvas + ag-psd + fontkit	现有	sharp 0.32.6 锁版；升级需回归
抠图	imgly/ONNX（独立 Worker）	现有	内存峰值高，必须与 API 隔离
对象存储	S3 兼容（OSS/MinIO）+ StorageAdapter	支持多实例、大文件、签名 URL	本地开发用 MinIO；导出走签名 URL
实时	WebSocket（现有）+ Redis pub/sub	多实例下 WS 需要跨进程广播	长任务进度也可用 SSE，二选一即可
认证	JWT + refresh token + 平台账号凭据独立加密	scgf 已有 JWT/pwdv	平台凭据用 KMS/信封加密，禁止进系统配置
部署	Docker Compose（单机）+ 后续 K8s	现有部署可用	Worker 独立容器；PG/Redis 托管；公网入口前置 WAF/HTTPS/MFA
观测	pino 结构化日志 + 任务事件 + Prometheus 指标	scgf 有事件目录/失败目录	首期至少：任务成功率/时长/失败 TopN/队列积压

5.4 目标架构

┌──────────────────────────────────────────────────────────────────────────────┐
│                          apps/web（React 19 + Semi + Tailwind）                │
│  平台切换 │ 选品 │ 原始物料 │ 图片制作 │ 视频制作 │ 提审 │ 投放配置 │ 资产 │ 系统 │
└───────────────────────────────┬──────────────────────────────────────────────┘
                                │ HTTPS（REST）+ WS/SSE
┌───────────────────────────────▼──────────────────────────────────────────────┐
│                          apps/api（Express 5，无状态，可多副本）               │
│  认证/权限 │ 客户/平台范围 │ 商品/物料 │ 模板/资产 │ 批次/素材 │ 提审/投放 │ 配置 │
│  PostgreSQL（主数据/任务/审计）    Redis（会话/锁/队列/缓存）                    │
└──────┬──────────────────┬──────────────────┬──────────────────┬──────────────┘
       │ BullMQ           │ BullMQ           │ BullMQ           │ BullMQ
┌──────▼──────┐    ┌──────▼──────┐    ┌──────▼──────┐    ┌──────▼──────┐
│image-worker │    │platform-    │    │ai-worker    │    │export-worker│
│PSD/合成/抠图 │    │worker       │    │生图/视频     │    │ZIP/CSV/打包  │
│（CPU/内存密集）│    │Playwright   │    │（外部 API）  │    │（IO 密集）   │
└──────┬──────┘    │登录/送审/审核│    └──────┬──────┘    └──────┬──────┘
       │           │/投放        │           │                  │
       │           └──────┬──────┘           │                  │
       └──────────────────┴──────────────────┴──────────────────┘
                          │
              ┌───────────▼───────────┐
              │ 对象存储（S3/OSS/MinIO）│  ← 原始物料 / 模板 / 成片 / 导出包
              └───────────────────────┘

模块边界（建议的 monorepo 结构）：

lingxi/
├── apps/
│   ├── web/                 # React SPA
│   ├── api/                 # Express 5 BFF
│   ├── worker-image/        # 渲染/抠图/合成
│   ├── worker-platform/     # Playwright：登录/送审/审核/投放
│   ├── worker-ai/           # 生图/视频
│   └── worker-export/       # ZIP/CSV/导出
├── packages/
│   ├── shared/              # DTO、zod schema、枚举、错误码
│   ├── domain-naming/       # 命名引擎（生产 + 提审两套 profile）
│   ├── domain-platform/     # 星光签名/字段映射/送审规则/DPLink
│   ├── ui/                  # 设计 token + 通用组件
│   └── config/              # 配置注册表（L1-L3）
├── infra/
│   ├── docker/  migrations/  scripts/  nginx/
└── docs/

关键架构决策（ADR 摘要）：

决策	选择	放弃的方案	理由
API 与 Worker	拆进程	同进程（scgf 现状）	AI/渲染/Playwright 三类负载差异大，同进程 OOM 会拖垮 API
存储	对象存储 + 适配层	本地磁盘	多实例、大文件（视频 140–190MB）、导出包
平台账号	集中托管 + 账号级串行锁	每用户绑自己账号 / 不托管	客户已授权使用其账号（D-09）；串行锁用于应对"单账号单会话"（若 POC-2 证实；证伪则可放宽）
部署暴露面	公网 + 登录鉴权 + WAF/MFA	纯内网/VPN	用户确认公网可访问；需安全加固 4~8 人日（§7.2 第 28 项）
平台适配	Adapter + 注册表	写死得物	多平台/新增平台是 PRD P0
实时	WS + Redis pub/sub	纯前端轮询	批量任务进度体验；轮询作降级
权限	平台 × 客户双层范围	只按角色	多平台多品牌
AI 调用	统一 AI 网关 + 队列 + 成本核算	页面直接调模型	限流/配额/成本/审计/降级

5.5 UI 选型专章：Semi Design / Arco / shadcn/ui 对比（回答您的问题）

结论：本阶段建议 Semi Design 2（+ Tailwind + 自建 token 主题），但不建议把 UI 选型当成关键决策——Semi 与 Arco 在本项目上近似平手，shadcn/ui 在当前条件下不推荐。

5.5.1 评分矩阵

权重按"后台密集 + 无专职设计师 + AI 辅助开发 + 追求交付速度"的项目特征设定：

维度	权重	Semi Design	Arco Design	shadcn/ui	说明
后台复杂组件覆盖（表格/表单/上传/树/级联/日期）	25%	5	5	2	Semi/Arco 开箱即用；shadcn 需自建 DataTable/Upload/Tree/DatePicker（中文）
中文本地化与暗色主题	10%	5	5	3	两者内置 zh_CN/暗色；shadcn 需接 date-fns locale + 自定义
与现有资产复用度	20%	4	4	1	Semi 贴合 dewu 作业端页面；Arco 贴合 scgf 管理端页面；两者各得一半，shadcn 两边都要重写
设计自由度 / 品牌化	15%	3	3	5	shadcn 代码归你所有、Tailwind 自由；Semi/Arco 需 token 覆盖
无设计师时的落地确定性	15%	5	5	2	两者有默认规范；shadcn 每个决策都要人定，易风格漂移
AI 辅助开发友好度（示例/API 稳定性）	10%	4	4	4	三者 LLM 都熟；shadcn 代码可读性更强，Semi/Arco 中文文档更全
长期维护与升级	5%	3	3	4	组件库升级受库约束；shadcn 代码在你手里但升级要自己跟
加权得分	100%	4.30	4.30	2.65	—

5.5.2 为什么最终仍略偏向 Semi

1. 与 PRD 主链路页面的贴合度：dewu 的选品/商品查询、素材下载、审核、送审预检、混剪配对页面，正好对应 PRD 的"选品 → 原始物料 → 提审 → 投放"；这批页面在 Semi 下的交互与组件经验可直接复用（Select/Table/Drawer/Progress 等），而 scgf 的 Arco 页面中，素材制作页与首页本来就要按新信息架构重写。
2. 作业端页面 > 管理端页面的迁移权重：管理类页面总工作量约 812 人日，两库差异仅 24 人日；而作业端页面涉及大量交互细节与踩坑经验，保留 Semi 经验的收益更高。
3. 中文后台生态与文档：Semi 的组件文档、示例、Table/Form 能力更完整；无专职设计师时，默认视觉规范能减少风格漂移。
4. dewu 已验证 Tailwind 共存方案：@layer tailwind-base, semi, ... 的层叠顺序坑已被踩清（dw/src/styles/index.css），新工程可直接沿用。

反方也要说清：如果团队对 Arco 更熟、或评审认为"素材生产页（scgf 最大页面）权重更高"，选 Arco 完全可接受——两者加权同分，最终差异约 5~12 人日（Arco 略省管理页、Semi 略省作业端）。不要为了 UI 库选型推迟项目。

5.5.3 为什么不推荐 shadcn/ui

• 本产品是"高密度 B 端后台 + 少量作业端"，shadcn/ui 是"组件代码片段"而非完整组件库，DataTable/Upload/Cascader/DatePicker/Tree/Form 都需要自建与长期维护；
• 无专职设计师时，shadcn 的自由度会变成"每个页面一个风格"的风险，AI 生成页面也难以保持一致；
• 预计额外 4~6 人周 搭后台组件层，且与"AI 辅助、求快"的约束冲突；
• 只有在"有设计师 + 强品牌化 + 愿意长期投入设计体系"时才更优。

5.5.4 净影响与折中方案

方案	对 dewu 作业端页面	对 scgf 管理端页面	净影响（相对 Semi 基线）
Semi（推荐）	作业端 UI 基础层省 815 人日；数据接入另计 3040	管理页重写，可省 2~4 人日	基线
Arco	作业端需重写（+8~15 人日）	可复用部分管理页结构（省 5~8 人日）	约 -5~-12 人日
shadcn	重写 + 自建组件层	重写 + 自建组件层	+20~30 人日（4~6 人周）

折中方案（若您坚持"新项目改动大一些"）：用 Semi 作为行为与可访问性底座，通过 ConfigProvider + CSS 变量把视觉 token 全面替换为自有品牌色/圆角/字号/间距；页面壳层与营销页可用 Tailwind 自由布局。这样既保留组件能力，又不会"一看就是默认 Semi"。不建议在同一后台里混用两套组件库（双维护成本 + 样式冲突）。

5.6 数据模型统一建议

以 scgf 19 表为基础，新增/改造为以下核心域（约 33 张表：迁移/改造约 18、新建约 15）：

域	表	关键字段	来源/说明
组织	platform	code, name, base_url, adapter_key, status	新建（得物/唯品会）
组织	project（可选）	platform_id, name, resource_path, status	新建（PRD"新增项目"）
组织	client	name, naming_config, platform_id?, status	由 scgf clients 扩展
组织	user / role / user_client	沿用 scgf（pwdv/强制改密/范围）	迁移
凭据	platform_account	platform_id, account_label, credential_cipher, owner_user_id, status, last_verified_at	新建（信封加密 + 审计）
商品	product_snapshot	platform_id, spu_id, title, brand, article_no, price, payload(JSONB), fetched_at	新建（来自 dewu SSR/接口）
选品	selection_batch / selection_item	batch_id, name, operator, status; spu_id, snapshot_id, raw_asset_status	新建
物料	raw_asset	selection_item_id, type(image/video), source_url, storage_key, md5, width/height, status	新建（对象存储）
模板	template / template_category / template_tag / template_spec	沿用 scgf + platform_id + asset refs	迁移 + 扩展
资产	asset（Logo/展示方式/促销/字体/脚本模板）	type, name, platform_id, client_id, config(JSONB), storage_key, status	新建（统一资产中心）
生产	production_batch / production_task	沿用 scgf（参数/命名快照/状态）	迁移
素材	material	沿用 scgf + selection_item_id + storage_key + md5 + review_status	迁移 + 关联
命名	naming_rule	scope(platform/client), profile(production/submit), template, fields, version	由 scgf clients.naming_config 拆出
提审	review_ticket / review_item	platform_id, account_id, status, submitted_at, result, reason	新建（内部状态机）
提审	submit_ledger	md5, ticket_id, result, payload(JSONB), created_at	由 dewu JSONL 账本升级
投放	delivery_config	platform_id, client_id, name, type(dp/landing/deeplink), fields(JSONB)	新建
投放	delivery_link	config_id, spu_id, url, generated_at, operator	新建（DPLink 结果）
任务	task_event / failure_catalog	沿用 scgf	task_event 迁移；failure_catalog 在 scgf 是代码常量目录，需升为表（新建）
通知	notification / notification_template	沿用 scgf	notification 迁移；notification_template 在 scgf 是 system_configs 的 JSONB，需拆为表（新建）
配置	system_config / system_config_audit	沿用 scgf + secret 类型	迁移（先补 secret）
审计	user_audit / operation_audit	沿用 scgf + 平台操作审计	扩展

数据迁移策略：

• scgf：不迁移 19 表结构，迁移数据。新库按上述模型建表，用一次性脚本把 clients/users/templates/template layer_config/materials/naming_config/notifications 导入；854MB 文件迁对象存储（保持路径映射表）。
• dewu：不迁移本地配置/凭据/账本（safeStorage 跨机不可解）；只导入 submitted-md5.json（防重复送审）与审计 JSONL（历史可查），其余重新登录/重新拉取。
• 迁移脚本必须支持 dry-run + 对账（行数/大小/MD5）+ 可回滚。

5.7 安全与合规设计要点

项	要求
平台凭据	信封加密（KMS 或 PLATFORM_CRED_KEY），按平台账号存储；禁止进系统配置/日志/审计明文
账号串行	同一 platform_account 的写操作（送审/上传）必须分布式锁串行；读操作限并发
权限	平台 × 客户双层范围；提审/投放/AI 需要独立能力点；所有列表接口强制范围校验（scgf 已有 fail-closed 范式）
审计	谁在何时对哪个商品/素材/账号做了什么（送审/投放/配置变更/凭据使用）；审计表不随业务删除
敏感信息	星光签名盐/token/账号/内网地址属内部敏感：调研报告与接口文档入库前必须脱敏（原值存受控知识库），并加 pre-commit secret 扫描；仓库内不得再硬编码任何平台/运维凭据
内容合规	AI 生成图/视频需人工复核闸门 + 合规词库 + 品牌 Logo 贴回校验（scgf 已验证方向）
合规边界	区分两类：①我方平台合规（内部用户 + 公网访问，需登录鉴权/WAF/等保，按内部系统加固）；②对第三方平台后台的自动化访问合规（客户已授权使用其账号，待补书面文件与范围；平台方条款残余风险由业务方接受并留档）。二者不可互相替代（§10.1 D-09）
公网暴露面	虽为内部平台，但公网可达：HTTPS + WAF/限流 + 管理员 MFA + 登录风控 + 依赖与镜像扫描 + 渗透测试 + ICP 备案/等保评估（按公司要求）

---

6　关键技术难点与 POC 清单

这一章是本次评估的"不确定性清单"。下列每一项都可能在 POC 阶段推翻或修正上面的工作量估算，因此建议 M0 用 3~6 周集中验证，再锁定排期。

6.1 八个高不确定项

#	难点	现状证据	为什么难	不通过时的降级方案
1	服务端 Playwright 送审	dewu 非混剪链路真机 1 条成功、混剪「是」未真机；项目选择"不直接调写接口"（dw/electron/submit/page.ts:2-30）	平台上传走页面第一方 SDK + duToken 网关；写接口技术上可重放（需自实现 STS/OSS 分片/media/create/提交），但成本与风控更高；选择器随改版失效；140–190MB 大文件；机房 IP 风控	优先 A：页面自动化（默认）；并行评估 C：服务端直连写接口。两者都不可行时降级为"服务端准备 + 人工浏览器收尾"
2	平台账号集中托管	单账号单会话是【推断】（源文档标注需两次同时登录对照实验）；现有云端同步是 HTTP+FTP 明文共享	若成立：多用户并发会互相顶号；凭据集中存储有安全与合规责任；账号归属/审计需产品化	每用户绑定自己的平台账号（用户级授权），牺牲效率换合规；POC-2 先用实验证实/证伪"单会话"
3	PSD 多资产渲染	1,773 行合成器，但所有图片替换图层共用同一张商品图；无自动化回归	四层信息（模板/展示方式/商品信息/Logo）要求按图层注入不同资产；改错是静默错误（图能出、内容错）	先做"商品图 + 文本 + Logo"三层，AI 模特/脚模延后；保留旧渲染器开关
4	AI 生图产品化	仅 M2-0 验证：34/34 成功、中文逐字正确、透明底成立、flash 19–25s/张；单价未获取、账号级限流真实、文字校验成本近翻倍	质量/成本/限流/一致性四重不确定；"生成图直接当成品"与"模板合成"两条路线未定	定位为"补充产线"（无模板场景），不替代 PSD；人工复核闸门
5	AI 视频产线	两项目均为 0；无模型选型、无样片、无验收标准	模型质量/时长/一致性/口播/字幕/成本全部未知；60s 成片可能需要多模型组合 + 剪辑	先做 5~15s 单镜头样片；不承诺首期上线
6	唯品会适配	两项目零参考	登录方式/接口/提审流程/反爬策略全部未知	首期仅得物；唯品会单独立项摸底
7	单机 → 多实例	scgf API 与 Worker 同进程、本地磁盘、内存限流	影响部署形态与所有文件/进度/锁的实现	首期单机 + Worker 独立容器 + 对象存储；多副本后置
8	PSD 兼容性与字体可用性	ag-psd 只覆盖普通图层/剪贴蒙版/15 种混合模式；智能对象/文字特效/图层样式/PSB 未系统验证；生产镜像无中文字形，内置仅 1 个 方正兰亭中黑简体 且商用授权未知	存量模板一旦不兼容，渲染结果错误且静默；换字体会改变所有模板的排版	POC-4 用 ≥5 个真实模板 + 字体替换做回归；不兼容模板登记清单，必要时设计侧重出

6.2 M0 POC 清单（建议 36 周；7 个 POC，其中 14 为必需）

编号	POC	验证内容	通过标准	估时	不通过的影响
POC-1	服务端送审 1 条真机（A/C 两路线）	A：登录态注入 → Playwright 打开送审抽屉 → 上传 140MB+ 成片 → 提交 → 回查；C：评估服务端直连写接口的可行性/成本	A 端到端成功且选择器可配置；C 给出可行性结论（不一定实施）	3~6 人日	整个"提审自动化"降级为半自动，MVP-2 价值下降
POC-2	账号集中托管 + 串行锁	①两次同时登录对照实验，证实/证伪"单账号单会话"；②两个并发请求使用同一账号，验证锁、互踢检测、重登恢复	"单会话"有明确结论；无互相顶号；失败可恢复；审计可追溯	2~4 人日	需改为用户级授权，账号体系重设计
POC-3	得物选品 + 物料入库	SPUID/链接 → SSR 商品详情 → 主图/详情图/主视频下载 → 对象存储 → 物料表	10 个真实商品 100% 成功；原图非压缩衍生图；MD5 去重	2~3 人日	选品模块需改用浏览器抓取，成本上升
POC-4	PSD 多资产渲染 + 兼容性	≥5 个存量真实模板（含剪贴蒙版/文字特效/智能对象）+ 商品图 + 主/副 Logo + 促销文本/图形 → 三规格输出；再做一次字体替换回归	5 个模板全部可渲染且差异在阈值内；Logo 拼接字符正确；不兼容模板有清单与降级方案	4~6 人日	P-02 四层信息无法达标，需重新设计模板契约
POC-5	AI 生图 30 张	9 要素表单 → 提示词 → 模型出图（pro/flash 各一组）→ 文字逐字校验 → 人工评估	可用率 ≥ 75%；中文文字正确率 ≥ 95%；单张成本/耗时拿到实测值；pro/flash 取舍有结论	2~3 人日	AI 生图延后，不影响图片主线
POC-6	AI 视频 3~5 条样片	脚本 → 画面 → 组合，16:9 与 9:16 各 2 条	业务方认可"可投"；拿到单条成本/时长	3~5 人日	视频产线只做"脚本+素材管理"，不做生成
POC-7	唯品会摸底	账号登录、后台结构、素材/提审流程、是否有可复用接口	形成《唯品会适配可行性说明》	2~5 人日	唯品会推迟到二期之后

M0 退出标准：POC-1/2/3/4 全部通过 → 图片+提审主线可立项；POC-5 通过 → AI 生图可排期（生产验收门槛高于 POC：≥80%）；POC-6 通过 → 视频可排期；POC-7 有结论 → 多平台可排期。

6.3 各难点的技术方案要点

（1）服务端 Playwright

• 独立 platform-worker 容器；每个平台账号一个持久化 browser context（加密 cookie 存储），同一账号串行（Redis 分布式锁 lock:account:{id}）。
• 只读优先：素材/审核/枚举走 HTTP 签名接口（无浏览器）；只有"写"（送审/登录兜底）走 Playwright。
• token 单一持有：拆 api / platform-worker 后，平台 token 只能由凭据服务单写；api 只读同一份，禁止自行重登（否则会出现"接口说未登录、Worker 说已登录"或双写互踢）。401 统一标记失效 + 一次重登，由 platform-worker 执行。
• 上传：浏览器端 → OSS 直传（STS 临时凭证）→ worker 下载到本地临时目录 → setInputFiles；或用户上传到服务端临时区。避免 140MB 文件穿 API 进程。
• 选择器集中配置化（YAML/JSON），带"页面健康检查"（关键元素缺失即告警），平台改版时可热修不发版。
• 失败显式：截图 + DOM 快照 + reasonCode 入库，便于事后排障。

（2）账号集中托管

• platform_account 表：平台、账号标签、账号能力（软广/硬广/审核角色）、加密凭据（信封加密）、归属运营、状态、最近验证时间。同一平台可有多账号（DPLink 依赖独立的星光硬广账号，软广账号调 list-landing 会 401）。
• 登录方式优先接口验证码登录（dewu 接口登录通道实测 9/9），浏览器兜底；token 过期自动重登并告警。
• 权限：谁能使用哪个账号、谁能看哪类操作，全部审计；敏感操作二次确认。
• 合规：客户已授权使用其账号（待补书面文件与范围）；仍需保留半自动降级与一键停用。注意"内部平台"只解决我方合规，平台方条款的残余风险由业务方接受并留档（D-09）。

（3）原始物料

• 得物：商品详情 SSR __remixContext 直取（无需浏览器），短链解析 + 域名白名单；图片取原图 URL（非 webimg 压缩图）；视频 CDN 直连下载。
• 唯品会：待摸底。
• 入库：raw_asset + 对象存储 + MD5 去重 + 尺寸/时长元数据；保留 source_url 与抓取时间，便于追溯。
• 限速：按平台/账号维度限流，避免机房 IP 被风控。

（4）PSD 多资产渲染

• 图层契约扩展：image_replacement_* 支持 assetType（product / model / foot-model / logo / promo）+ assetRef + 缩放/对齐；Logo 支持"主+副+拼接字符"组合器；文本层支持促销模板。
• 渲染顺序保持 PSD 图层 z 序：assetType 只决定该图层取哪类素材，不重排图层（否则会破坏"商品图在装饰框之后""Logo 在蒙版之后"这类真实版式）；仅同层级内按语义排序。
• 资产引用快照：批次创建时把 assetRef → storage_key + md5 + version 固化进批次/子任务；Worker 只读快照，避免同批次前后图版本不一致（沿用 scgf 的命名/参数快照先例）。
• 三规格：同一模板按目标尺寸派生（或设计侧提供三尺寸模板；需 POC-4 确认哪种更稳）。
• 字体：生产镜像内置可用中文字体并明确商用授权；换字体必须跑黄金样本回归（字体会改变排版与换行）。
• 回归：建立"存量模板黄金样本 + 像素级 diff"再动引擎；灰度客户；保留旧渲染器开关。

（5）AI 生图

• 路线：表单（9 要素：品类/主体/场景/文案/风格/尺寸/品牌元素/合规项/数量）→ 提示词合成 → 模型 → 文字校验（VLM 逐字）→ 人工挑图 → 入资产库。
• 模型分层：成品/交付默认 pro（效果优先，符合预算充足的定位）；草稿/预览/大批量初筛用 flash（快 3 倍、成本更低）。单价与日/月上限做成配置，超限降级 flash 或排队。
• 网关：统一 provider 接口（火山方舟/其他），配额/限流/重试/降级；成本按调用记账。
• 合规：商标/肖像/功效宣称词库 + 人工复核闸门 + 品牌 Logo 程序贴回（不信任模型画 Logo）。
• 定位：无模板场景的补充产线，不替代 PSD（POC-5 后确认）。

（6）AI 视频

• 三段解耦：脚本（LLM + 营销理论模板）→ 画面（文生图/图生视频/AI 模特）→ 组合（TTS/字幕/剪辑/拼接）。
• 首期只做 16:9 或 9:16 其中一条；单镜头 5~15s；不做复杂转场。
• 成本与时长必须单列预算（§7.5）。

（7）单机 → 多实例

• Worker 独立进程/容器（image/platform/ai/export 四类）。
• 对象存储 + 签名 URL，替代本地磁盘与 /uploads 直出。
• 限流迁 Redis；WS 用 Redis pub/sub 广播；任务锁用 Redis。
• 首期可以单机多容器（docker compose），不必上 K8s；但代码必须"无本地状态"。

---

7　工作量与成本估算

7.1 估算方法与假设

项	说明
单位	人日 = 1 名熟悉本仓库的工程师全职 1 天（8h）
包含	编码、自测、代码评审、必要重构、与前后端联调
不含	产品/设计/测试专岗、运维部署、项目管理、真机验证等待时间、平台改版返工
AI 辅助	本节数字已按 AI 辅助折算（加权系数约 0.65~0.8，推导见 §7.4）
传统估算	本节数字 ÷ 0.7 ≈ 1.4 倍
不确定性	±25%；POC 失败可能使单项翻倍
口径	逐项加总为唯一底稿；分阶段小计只做归类，不重复计算

内部平台定位省去多租户约 23 人日；但部署为公网可访问，新增安全加固 48 人日（已单列第 28 项）。

7.2 工作分解（AI 辅助后人日）

阶段	#	工作项	低	高	说明
M0	27	7 个 POC + 架构/模型定稿	16	31	见 §6.2；POC 估时按 AI 折算 1326 + 定稿 35
地基	1	monorepo/CI/环境/部署/迁移框架/对象存储适配	12	18	从零搭骨架
地基	2	账号/权限/客户范围/审计（迁移 scgf）	8	12	加平台账号授权
地基	3	系统配置中心（迁移 + platform/ai 模块 + secret 类型）	8	12	AI Key 前置
地基	4	任务中心（队列拆分/实时/事件/失败目录/监控）	12	16	拆 Worker
地基	5	前端壳/设计系统/布局/路由/权限/通用组件	20	28	Semi token 主题
地基	6	测试基础设施（契约测试/渲染黄金样本/E2E 骨架）	10	15	必须，不是可选
平台	7	得物适配层（签名/只读接口/登录态/账号凭据/商品详情/素材库/审核）	25	35	迁移 dewu + 服务端化
选品	8	选品与物料库（检索/圈选/历史/物料归档/去重/下载）	18	26	新建部分
图片	9	模板资产（PSD 上传/解析/图层绑定/预览/分类/标签/规格，含 5 个模板页面）	12	16	迁移 + 平台维度
图片	10	渲染引擎多资产化（Logo/促销/AI 模特/脚模/三规格/质量/回归）	25	35	核心改造；含像素回归
图片	11	图片生产页与批量（筛选/上传识别/字段表/参数/预览/导出）	18	26	重写 + 迁移逻辑
图片	12	命名引擎（生产 + 提审两套 profile + 自定义字段 + 校验）	8	12	合并
提审	13	提审工作流 + 批量送审（状态机/预检/幂等/Playwright/审核/审计/混剪 P1）	28	40	服务端重写
投放	14	投放配置（DPLink + DP/承接页 + 复制 + 批量）	14	20	部分新建
多平台	15	多平台抽象（平台维度/资源路径/新增平台机制）	8	12	—
多平台	16	唯品会适配（摸底后未知）	18	30	零参考，区间大
资产	17	资产中心（模板/Logo/展示/促销/脚本统一管理）	10	15	—
AI	18	AI 生图产品化（网关/队列/表单/提示词/校验/合规/成本/挑图）	20	30	从零
AI	19	视频产线 MVP（脚本/画面/组合/长任务/存储/审核）	45	65	最大不确定
交付	20	联调/真机验证/压测/合规自查	15	22	不能省；安全见第 28 项
交付	21	上线/部署/监控/文档/培训	8	12	—
前端	22	管理类页面迁移（用户/角色/客户/任务/日志/登录，约 8,300 行）	8	12	scgf Arco 页面重接 HTTP/权限
迁移	23	数据迁移执行（19 表 + 854MB 文件 + 命名/图层映射 + 对账/回滚）	5	8	不含迁移框架
文件	24	文件服务迁移（缩略图/鉴权 URL/清理策略，约 1,275 行）	2	4	对象存储化
导出	25	导出 Worker（ZIP/CSV/打包/签名 URL 下载）	4	6	从 scgf 迁 + 拆分
通知	26	通知中心页 + 事件扩展（提审/投放/失败）	2	3	现只有下拉
安全	28	公网安全加固（WAF/限流/MFA/扫描/备案/渗透测试）	4	8	公网可访问的前置
数据	29	Prisma schema/Repository 重写（19 表映射 + 迁移基线 + 数据访问层）	8	12	ORM 由 Sequelize 改 Prisma
		合计	391	581

分期小计（与逐项加总一致，不重复计算）：

阶段	范围	低	高	累计（低/高）	对应 §4.4
M0 验证	27	16	31	16 / 31	7 个 POC
MVP-1 图片生产主线	112 + 2225 + 28~29 + 20/21 一半	219	318	235 / 349	得物选品→物料→出图→命名→导出
MVP-2 投放闭环	13~14 + 20/21 另一半	53	77	288 / 426	提审 + DPLink/配置
M3 多平台	15~16	26	42	314 / 468	唯品会 + 平台扩展
M4 AI 增强	17~18 + 26	32	48	346 / 516	资产中心 + AI 生图 + 通知中心
M5 视频产线	19	45	65	391 / 581	视频 MVP

首期口径（建议）：M0 + MVP-1 + MVP-2 = 288~426 人日（含验证）；若不含 M0，则为 272~395 人日。全量 = 391~581 人日。

7.3 人力与周期（含 AI 辅助，日历周期已含依赖等待）

配置	MVP-1（219~318）	首期闭环累计（288~426）	全量累计（391~581）
1 人 + AI	13~19 个月	17~25.5 个月	23~34.5 个月
2 人 + AI（1 前端 + 1 后端/全栈）	6.5~9.5 个月	8.5~12.5 个月	11.5~17.5 个月
3 人 + AI（前端/后端/平台+AI）	4.5~6.5 个月	5.5~8.5 个月	8~11.5 个月
4 人 + AI	3~4.5 个月	4.5~6.5 个月	6~8.5 个月

折算方式：人日 ÷ 人数 ÷ 21（工作日/月），再乘 1.21.35 的依赖等待与联调系数（多人并行不能线性加速）。首期上线建议 3 人 + AI；2 人也能做，但首期闭环需 8.512.5 个月。不要一开始就承诺唯品会与视频。

7.4 AI 辅助开发的现实预期（重要）

"全程 AI 辅助"确实会显著改变成本结构，但压缩的是"写代码"，不是"确认代码对不对"：

工作类型	占比（估）	AI 提效	折算系数
脚手架/CRUD/表单/表格/迁移脚本	25%	2~2.5 倍	0.40~0.50
样式/组件/页面重构	20%	1.5~2 倍	0.50~0.67
业务逻辑/算法（命名/渲染/签名）	20%	1.2~1.6 倍	0.63~0.83
平台真机联调（Playwright/登录/上传）	15%	1.0~1.2 倍	0.83~1.0
需求澄清/评审/合规/验收	10%	1 倍	1.0
线上排障/平台改版应急	10%	1.0~1.3 倍	0.77~1.0

加权后约 0.65~0.8，这就是 §7.2 采用的系数；也是"AI 提效 2~3 倍"与"整体只省 20%~35%"并不矛盾的原因。

为什么本评估 391581 人日，而两份调研的传统粗估合计只有 280425？ 因为口径不同，不是数字打架：

来源	覆盖范围	粗估
dewu 调研	dewu 模块迁移（含 UI）	115~190 传统人日
scgf 调研	scgf 地基 + 图片产线 + AI + 多平台（不含视频深水区）	165~235 传统人日
两者合计	有重叠、且都未单列下列工作	约 280~425（不可直接相加）
本评估 WBS	新增单列：M0 验证 1631、管理页 812、数据迁移 58、文件服务 24、导出 Worker 46、通知中心 23、平台账号/凭据 812、对象存储/多实例 610、测试基础设施 1015、前端数据重接 3040、公网安全 48、Prisma 重写 812	391~581（AI 辅助）

换句话说：若只看两份粗估覆盖的范围，本评估折算后约 288420 人日，与 280425 基本吻合；多出来约 103~161 人日 是两份调研都没有单列的"新工程必做项"（其中"前端数据重接 3040"已部分包含在两份粗估的 UI 工作内，净新增约 73121 人日）。评审时请按"能力清单"逐项对账，而不是拿两个总数直接比较。

建议：

• 用 AI 并行推进"脚手架 + 测试 + 文档 + 迁移脚本"，但每个 AI 产出都必须有人评审 + 自动化验证；AI 生成的渲染/签名/提审逻辑若没有回归测试，错误会静默上线。
• 单人 + AI 的真实瓶颈是评审与联调，不是编码；若只有 1 人，建议把"提审自动化"与"真机验证"外协或延后。
• M0 结束时用 POC 实际耗时校准系数（把 0.65~0.8 替换成实测值）。

7.5 成本估算（量级参考，非报价）

项	估算	说明
服务器（API/4 类 Worker/PG/Redis）	800~2,500 元/月	4C8G×1 + 2C4G×3 + 托管 PG/Redis；Playwright/渲染吃内存
对象存储 + CDN	100~500 元/月	按 500GB 存量 + 月流量 200~500GB 估算；视频素材占大头
带宽/出网	200~800 元/月	送审大文件上传、素材下载；建议同地域 OSS 直传降低穿行
AI 生图	单价待确认；按 0.2~0.5 元/张 × 月产量做预算上限	M2-0 实测 flash 19~25s/张、16,428 token/张；文字校验使成本近翻倍；必须把单价做成配置项
AI 视频	单价待询价；按 5~15 元/条 × 月产量做上限	1000 条/月即 5,00015,000 元/月；需先做 35 条样片再定
字体商用授权	一次性/年费，需法务确认	方正兰亭中黑简体 商用授权状态未知；换字体会改变渲染结果
域名/证书/监控	100~300 元/月	—
WAF/公网防护	100~500 元/月	公网访问可选云 WAF/高防；也可先用云厂商基础防护
合计（不含 AI 视频放量）	约 1,300~4,600 元/月 + AI 调用费	五项固定成本加总：800+100+200+100+100=1,300；2,500+500+800+300+500=4,600

建议在系统配置中心增加"AI 单价 / 日调用上限 / 月预算 / 告警阈值"，把成本控制做成产品能力（scgf 已有配置框架，加 ai 模块即可）。

7.6 与两项目历史投入的关系

• dewu：2026-05→10 约 5 个月，228 commits，65k 行（桌面端含大量发布/签名/更新链路）。
• scgf：2026-03→09 约 6 个月（9 月集中 131 commits），63k 行（含 19 表/113 接口/PSD 引擎）。
• 新平台不是"第三次重做"：它把两条产线合并，节省的是"两端各自再演进"的长期成本；但短期内（6~12 个月）总投入会高于"只维护现状"，这是整合的必然代价。评审时建议用"3 年总成本"而不是"首期成本"做决策。

7.7 投入产出：与"维持现状"的对比（3 年 TCO 框架）

项	维持现状（两套系统并行）	新统一平台	说明
建设投入	0（但新 PRD 能力无法交付）	391581 人日（≈1.92.8 人年）	按 210 工作日/人年
长期维护	1.0~1.5 人（两套 + 平台改版适配）	0.8~1.2 人（一套 + 平台改版适配）	平台适配约 0.5~1 人不变
基础设施	两套（桌面端无服务器成本，但 Web 端已有）	一套（略增，因对象存储/Worker）	见 §7.5
3 年人力	≈ 3.0~4.5 人年	≈ 建设 1.92.8 + 维护 2.43.6 ≈ 4.3~6.4 人年	不含 AI 调用费
能力	无法满足 PRD 的图片四层/视频/多平台/投放配置	满足 PRD 主链路，可扩展	这是主要收益
结论	短期便宜，长期被"两条产线 + 人工配置"锁死	首期投入大，但只维护一套、能力完整	—

决策建议：不要用"首期能省多少钱"评估整合，而用"3 年 TCO + 能力清单 + 风险"三维评估。如果只打算做图片产线、且能接受人工完成选品/提审/投放，那么"保留 scgf + 手工流程"更省；如果要交付 PRD 描述的完整链路，整合是唯一可控路径。

---

8　整合路线图

8.1 里程碑总览

工作量取自 §7.2 分期小计（逐项加总一致）；日历周期见 §7.3，二者口径不同，不要混用。

阶段	工作量（人日）	目标	核心交付物	退出标准
M0 验证与定稿	16~31	去风险	7 个 POC 结论、客户书面授权文件、模板/资产规范与首批样张、架构与数据模型定稿、调研报告与 scgf 文档脱敏入库	POC-1~4 通过；授权文件到位；模板规范与 ≥5 个真实模板到位
M1 地基 + 图片主线（MVP-1）	219~318	跑通"选品→物料→出图→命名→导出"	新工程骨架、账号/权限/配置、得物平台适配（读）、物料库、模板/渲染/生产页、命名/导出、管理页迁移	≥5 个真实模板回归通过；10 个真实商品端到端出图；权限/范围有测试
M2 提审 + 投放闭环（MVP-2）	53~77	跑通"送审→审核→投放链接"	提审状态机/预检/批量送审 Worker/审核同步、DPLink/配置管理	送审真机成功率 ≥95%；审核可回查；账号串行锁有并发测试
M3 多平台	26~42	扩平台	唯品会适配、平台扩展机制、资源路径规则	唯品会完成一次闭环；新增平台不改核心代码
M4 AI 增强	32~48	AI 补充产线 + 资产中心	AI 生图产品化、资产中心、通知中心	AI 生图可用率 ≥80%；成本/限额/复核闸门生效
M5 视频产线	45~65	视频素材 MVP	脚本（AI/人工）→ 画面 → 组合；16:9/9:16 各一条	20 条样片人工评审通过；单条成本/时长可统计
合计	391~581	—	—	—

8.2 关键路径与并行建议

客户授权文件 ─┐
           ├──▶ POC-1/2（送审+账号）──▶ M2 提审 Worker ──▶ 上线
POC-3/4 ───┘                                  ▲
   │                                          │
   └──▶ M1 图片主线（最长路径）───────────────┘
                     │
                     └──▶ M3 唯品会 / M4 AI 生图 ──▶ M5 视频

• 最长路径是 M1 图片主线（渲染引擎 + 生产页 + 物料库），应优先投入最强的人力。
• POC 与 M1 可并行：POC-4（渲染）本身就是 M1 的第一块。
• 唯品会、AI 生图、视频都不在关键路径上，可以后置；不要为了"PRD 全量"把三条不确定支线塞进首期。
• 提审 Worker 与 M1 的后半段可并行（一个前端/一个平台 Worker）。

8.3 每阶段的"完成定义"（DoD）

阶段	DoD
M0	每个 POC 有书面结论（通过/不通过/降级）；架构图与数据模型评审通过；合规结论留档；两份调研报告 + scgf docs 入库
M1	真实商品全链路可复现；渲染有黄金样本回归；任务失败可观测；权限/范围有测试；部署脚本可用
M2	送审成功率与失败原因可统计；账号串行锁有并发测试；提审/审核状态与平台一致；审计可查
M3	新增一个平台不改核心代码（只加 adapter + 配置）
M4	AI 生图有成本/限额/复核闸门；资产中心可用
M5	视频样片达到业务方"可投"标准；单条成本/时长可统计；失败可重试/降级

8.4 上线、灰度与容灾

项	建议
切换策略	新旧系统并行 2~4 周：旧系统只读，新平台承接新任务；按客户/平台灰度，先 1 个客户 + 1 个平台
停服窗口	仅数据迁移需要，放周末 2~4 小时；提前 3 天公告；桌面端在切换完成后停止分发（D-01）
灰度与回滚	镜像版本化 + 开关（送审/抓取/AI 分别可关）；DB 迁移提供 down 脚本；回滚时限 30 分钟内
备份	每日全量 PG 备份 + WAL 增量；对象存储开版本化/生命周期；保留 ≥30 天
容灾目标	单机阶段：RTO ≤ 4h、RPO ≤ 24h；多副本阶段再收紧
演练	上线前至少 1 次"备份恢复 + 迁移回滚 + 送审开关"全流程演练
上线检查	配置项、账号凭据、队列健康、对象存储权限、监控告警、公网安全（WAF/MFA/依赖与镜像扫描/渗透测试）、客服/运营话术、值班表

---

9　风险登记

概率/影响：高/中/低。每条风险必须有明确的触发信号与应对动作，禁止"持续关注"。

编号	风险	概率	影响	触发信号	应对措施	责任人
R-01	平台合规/封禁：服务端集中托管账号 + 自动化送审被平台判定违规，导致账号限流/封禁	中	高（客户承担）	登录频繁失效、接口 403/风控码、账号被限制	客户已授权使用其账号（待补文件）；只读优先；写操作人工确认；账号级限速；enableSubmitReview 式一键停用；降级为"服务端准备 + 人工浏览器收尾"；平台方条款残余风险由业务方接受并留档	业务负责人 + 法务
R-02	单账号单会话冲突（待 POC-2 验证的推断）：多人共用账号互踢，送审中断	中高	高	频繁"请先登录"、token 被顶	账号级分布式锁串行；登录态健康检查；失败自动重登+告警；按项目分配账号	平台 Worker 负责人
R-03	平台接口/页面改版：签名盐、字段、选择器、权限菜单变化	高	高	签名自校验失败、关键元素缺失、接口 4xx	适配层隔离；选择器配置化 + 页面健康检查；契约测试 + 抓包 fixture；预留维护人力（约 0.5~1 人持续）	平台适配负责人
R-04	视频 AI 不达预期：质量/成本/时长不可控	高	高	POC-6 样片不通过、单条成本超预算	不设硬上线日期；先做 3~5 条样片；只做单镜头；不接受则降级为"脚本+素材管理"	产品 + AI 负责人
R-05	唯品会零参考：适配周期不可控	高	中高	摸底后无可用接口/流程差异大	单独立项；首期不做；合同中明确"平台适配另计"	业务负责人
R-06	渲染引擎改造静默错误：图能出但内容错	中高	高	存量模板产出与设计稿不一致	黄金样本 + 像素 diff 回归；灰度；旧渲染器开关；人工抽检	图片产线负责人
R-07	对象存储/大文件：视频 140–190MB 上传失败/成本超预期	中	中高	上传失败率上升、流量费用异常	客户端/浏览器直传 OSS；分片 + 断点；限速与重试；成本看板	架构 + 运维
R-08	数据迁移丢失/错位：854MB 文件 + 19 表 + 历史命名	中	中高	对账不一致、成片找不到	dry-run + 对账（行数/大小/MD5）+ 备份 + 可回滚；先迁模板与资产，历史批次只读归档	后端负责人
R-09	AI 成本失控/限流：账号级 IPM 限流、单价未知	中	中	429、账单超预算	网关排队 + 配额 + 日/月上限 + 告警；pro/flash 分层；先小流量	AI 负责人
R-10	凭据泄露：历史仓库已硬编码 Cookie 同步密钥/FTP 密码	高（既成事实）	高	仓库/文档/产物中出现凭据	立即轮换；新平台全部走 KMS/环境变量；禁止写入配置/日志/审计；清理历史产物	安全 + 研发负责人
R-11	字体/许可证：方正字体商用授权、sharp/onnx 许可证	中	中高	法务审核不通过	法务确认；替换开源字体并回归渲染；依赖许可证扫描入 CI	法务 + 研发
R-12	单机架构扩展受限：API+Worker 同进程、本地磁盘、内存限流	中	中	OOM、任务堆积、接口超时	首期即拆 Worker + 对象存储 + Redis 限流；单机多容器起步	架构负责人
R-13	AI 生成内容合规：商标/肖像/功效宣称/免责声明	中	高	平台拒审、客户投诉	合规词库 + 人工复核 + 品牌 Logo 程序贴回 + 留痕	合规 + 产品
R-14	文档与知识未入库：scgf docs 110 文件 0 入库	高（既成事实）	中高	人员/机器变动后上下文丢失	M0 第一件事：文档入库 + 关键结论摘要进仓库；建立 ADR	技术负责人
R-15	范围蔓延：PRD 全量 P0 + 视频 + 唯品会同时压入首期	高	高	里程碑持续延期、质量下降	冻结首期范围（§4.4）；变更走评审；视频/唯品会独立里程碑	产品负责人
R-16	公网暴露：虽为内部平台，但公网可达，登录账号/平台凭据/客户素材面临外部攻击面	中	高	异常登录、凭据撞库、接口扫描	WAF + 登录限流 + MFA（至少管理员）+ 最小权限 + 全量审计 + 依赖/镜像扫描 + 渗透测试 + 定期轮换密钥	安全 + 运维

---

10　评审决策清单与待确认问题

10.1 需要您拍板的决策项

编号	决策	推荐	备选	影响
D-01	桌面端下线节奏	彻底 Web 化，桌面端冻结功能、只做安全维护，首期闭环（M2）上线后停止分发	过渡期保留双端	决定是否保留 Electron 维护人力
D-02	技术底座	新建统一工程（pnpm monorepo），技术栈沿用 Express 5 + Sequelize + PG + Redis/BullMQ	以 scgf 为基座 / 前后端分离新建	已选新建；本项确认技术栈
D-03	UI 组件库	Semi Design 2 + Tailwind + 自建 token（与 Arco 近似平手，Semi 略优）	Arco / shadcn/ui（+4~6 人周）	相对 Semi 基线，Arco 约 -3~+3 人日，shadcn 约 +20~30 人日；不影响主工期
D-04	平台账号模式	运营级集中托管 + 账号级串行锁 + 全量审计	用户级授权	已选集中托管；客户已授权使用其账号（D-09 待补文件）
D-05	首期范围	MVP-1 图片主线 + MVP-2 投放闭环（首期闭环）；唯品会/AI 生图/视频后置	仅 MVP-1（不含提审）	决定上线时间与价值闭环；对应 §7.2 的 272~395 人日（不含 M0）
D-06	平台顺序	得物先行；唯品会 M3 且单独立项	双平台并行	唯品会零参考，并行会拖垮主线
D-07	AI 定位	AI 生图为补充产线（无模板场景），不替代 PSD；AI 模特/脚模按"资产图"接入	AI 生图替代 PSD	决定渲染引擎改造方向
D-08	数据迁移	迁用户/客户/模板/图层/命名/通知；不迁历史批次与凭据；dewu 只导入 md5 账本 + 审计	全量迁移	决定迁移工作量与风险
D-09	平台侧合规（客户授权已确认，待补文件）	客户已授权使用其账号做服务端托管 + 自动送审；需补书面文件：账号范围/期限/允许操作/数据使用/封禁风险承担	降级半自动 / 停止自动送审	文件未到位前不得上线自动送审；平台方条款残余风险由业务方接受并留档；仍保留一键停用
D-10	部署形态	单机 Docker Compose（API + 4 Worker + PG + Redis + MinIO/OSS）+ 对象存储	K8s	首期够用；代码保持无本地状态
D-11	人力配置	3 人 + AI（前端/后端/平台+AI），先 MVP-1 + MVP-2	2 人 / 1 人 + AI	决定周期（§7.3）：3 人首期 58 个月，2 人 7.511.5 个月
D-12	设计资产供给（已确认）	已确认由设计师角色提供；本项转为"模板规范 + 首批样张 + 交付节奏"的落地项	系统内做模板编辑器（不必要）	供给方已定；规范/样张不到位仍会阻塞 M1（A-01）

10.2 待确认问题（合并两项目调研，去重后 22 条）

编号	问题	为什么影响整合	建议确认人	期望时间
Q-01	客户已授权使用其账号（待补文件）：授权范围/期限/允许操作/数据使用/封禁风险如何约定？平台方条款残余风险由谁接受？	决定提审自动化能否上线（D-09）	业务负责人 + 法务 + 客户	M0 第 1 周
Q-02	客户授权覆盖哪些账号：软广与硬广（DPLink）两套是否都在授权范围？账号归属、退出语义与封禁责任如何写进文件？	决定账号体系、能力绑定、审计与责任边界	业务负责人	M0 第 1 周
Q-03	唯品会的后台登录方式、素材/提审流程、是否有接口或可复用页面？	决定多平台工作量（18~30 人日起）	运营 + 客户	M0
Q-04	PRD 中的 DP 具体指什么？字段、生成规则、样例？	决定投放配置模块是规则引擎还是固定拼接	业务方	M1 前
Q-05	提审是"平台后台提审"还是"系统内审批流"？需要几级？	决定提审状态机与角色	产品 + 运营	M1 前
Q-06	模板是否只支持 PSD？是否允许非 PSD 图片模板并存？	决定是否复活/重做 Schema 渲染路线	产品 + 设计	M0
Q-07	"AI 模特/脚模"是生成图还是设计提供的素材图？"Logo 拼接字符"具体交互？	决定渲染引擎与资产模型（差异可达 10+ 人日）	设计 + 运营	M0
Q-08	三规格是固定枚举还是可扩展？同一模板如何派生三尺寸？	决定模板/规格模型与设计侧交付方式	产品 + 设计	M0
Q-09	视频的时长/分辨率/口播/字幕/过审标准？样片由谁验收？	视频无法验收的根因	产品 + 运营	M0
Q-10	AI 生图定位与预算上限？是否必须"文字逐字校验 + 人工复核"双闸门？	决定成本（近翻倍）与流程	产品 + 财务 + 合规	M0
Q-11	字体商用授权状态（方正兰亭中黑等）？新增字体如何管理？	合规红线；换字体会改变渲染结果	法务 + 设计	M0
Q-12	存量数据迁移范围：scgf 19 表 + 854MB 文件；dewu md5 账本/审计？	决定迁移方案与回滚	产品 + 运维	M0
Q-13	内部平台已收敛为单租户；仍需确认多品牌/多客户的数据隔离维度（客户范围 vs 物理隔离）	决定权限模型与列表范围，但不再是架构分叉	技术 + 业务负责人	M0
Q-14	权限是否需要"平台 × 客户 × 项目"三层？	决定权限模型与所有列表接口	产品 + 运营	M1 前
Q-15	表 1-4 成功指标的现状值/目标值？	上线后无法判断成功	业务 + 数据	M1 前
Q-16	首期上线时间、验收方式、是否需要灰度/回滚演练？	决定排期与发布策略	产品 + 技术	M0
Q-17	历史选品、粗词检索、批量配置替换等 P1 是否必须在首期？	影响 MVP 范围	产品	M0
Q-18	平台改版后的适配责任人/SLA？是否接受"平台变更可能需要 1~3 天停机修复"？	长期维护成本归属（约 0.5~1 人）	业务 + 技术	M0
Q-19	选品主键与口径：得物用 SPUID，唯品会用什么？是否统一为内部商品主数据？	决定选品/物料/命名/投放的主键设计	运营 + 平台对接人	M0
Q-20	促销信息（折扣/活动标识）的数据来源与更新频率？是模板叠加还是实时数据？	决定促销图层模型与数据对接方式	运营 + 产品	M1 前
Q-21	需要哪些埋点与经营看板指标？口径与数据源？	决定事件模型与统计聚合	产品 + 数据	M1 前
Q-22	混剪送审与 Excel/CSV 批量导入是否在首期？	影响提审范围（6~10 人日）与优先级的判断	业务 + 产品	M1 前

10.3 评审 Go/No-Go 标准

建议评审结论分为三档：

结论	条件	后续动作
Go（推荐）	D-01~D-12 确认（D-09 待补文件、D-12 已确认）；客户书面授权文件到位；启动 M0 的 7 个 POC	立项，3 人 + AI，按 §8 路线图执行
Conditional Go	合规未闭环 / POC 未做 / 设计供给未定	先做 M0（3~6 周）再决策；期间冻结开发投入（只做 POC 与文档）
No-Go（当前形态）	平台明确禁止服务端自动化，且不接受半自动降级	退回"桌面端 + Web 生产端"混合形态（方案 B），或只做图片产线

10.4 组织、协作与合规（评审也需确认）

项	建议/待确认
平台侧合规	客户已授权使用其账号（待补文件与范围）；平台方条款残余风险由业务方接受并留档；文件未到位前不开放自动送审（D-09）
设计师角色	设计资产由设计师提供 → 系统必须支持设计师上传/编辑/预览/版本与资产复用；需明确模板规范与交付节奏（A-01）
人力来源	2~3 人从哪来？是否需要外协（前端/Playwright 适配）？谁做产品决策与验收？
决策机制	范围变更、平台适配优先级、上线窗口由谁拍板？建议设"产品 + 技术"双负责人
素材版权	抓取的商品图/视频用于二次创作与投放，版权/授权依据需客户书面确认；AI 生成图不得侵犯商标/肖像
个人信息	平台账号手机号、运营人员信息属个人信息，需最小化收集、加密存储、审计访问
内容合规	AI 图/视频需人工复核闸门；电商广告禁用词/功效宣称/免责声明按客户行业规则配置
审计与追溯	谁在何时用哪个账号对哪个商品/素材做了什么，必须可查、可导出、不可篡改

---

11　结论与建议

11.1 结论

1. 整合可行，方向正确：两项目是同一业务链路的上下游，合并后能形成"选品 → 原始物料 → 图片/视频生产 → 命名 → 提审 → 投放配置"的完整闭环，避免继续维护两条互不相通的产线。
2. 技术上没有"不可逾越"的障碍，但有 3 个技术约束 + 1 个待验证假设：①送审默认页面自动化（可并行评估直连写接口）；②PSD 渲染需支持多资产；③单机架构必须拆分；④平台账号单会话是推断，需 POC-2 用两次同时登录实验证实/证伪。这四点应在 M0 用 POC 定论。
3. 最大风险不在代码，而在外部依赖：平台侧合规（客户已授权使用其账号、待补文件，平台条款残余风险仍在）、平台接口稳定性、视频 AI 质量/成本、唯品会零参考。这四项任何一项不成立，都会显著改变产品形态或排期。
4. PRD 目前不足以直接开发：2~10 章为空，27 项功能框架中 14 项完全空白；建议先补 §4.3 的 12 项，再冻结首期范围。
5. "新建统一工程"是正确的，但要把"新建"理解为"重建骨架 + 迁移资产"，而不是重写。按人日计约 35%~40% 的工作可由存量资产覆盖（按代码行数约 40%~50%：后端 60%~70%、前端 25%30%），这是 3 人 + AI 能在 5.58.5 个月内做出首期闭环的前提。

11.2 建议的下一步（未来 3~6 周，即 M0）

优先级	动作	产出	负责人
P0	补齐客户书面授权文件（账号范围/期限/操作/数据使用/封禁风险）并留档	授权文件 + 风险接受记录	业务负责人 + 法务
P0	与设计师确认模板/图层/促销规范，锁定 M1 前首批 ≥5 个真实模板	模板规范 + 首批样张 + 排期	产品 + 设计负责人
P0	抢救知识：scgf docs/ 110 个文件 + 两份调研报告脱敏后入库；dewu 关键文档归档	统一文档库 + ADR + secret 扫描	技术负责人
P0	执行 M0 的 7 个 POC（必需 POC-14 + 支线 POC-57）	POC 报告 + 修订后的估算	技术负责人
P1	评审目标架构与数据模型（§5.4/§5.6）	架构评审结论	技术 + 产品
P1	补 PRD §4.3 的 12 项；冻结 MVP-1 范围	PRD V0.2 + 范围基线	产品负责人
P1	UI 选型拍板（Semi / Arco / shadcn）	设计技术选型 ADR	产品 + 前端
P2	POC-5/6/7（AI 生图/视频/唯品会）	三条支线的可行性结论	AI/平台负责人

11.3 明确不建议做的事

#	不建议	原因
1	直接把两个仓库合并/复制进一个目录	两套架构（Electron 本地 JSON vs Web/PG）无法共存，只会得到双份技术债
2	首期同时做"图片 + 视频 + 唯品会 + AI 生图"	4 条不确定支线并行，任何一条失败都会拖垮整体
3	在没有渲染回归前改 materialComposer.ts	静默错误风险最高；先建黄金样本
4	把 AI API Key/平台凭据放进系统配置表	现有审计不脱敏，会长期明文留痕
5	继续保留桌面端并把新功能只做在桌面端	与"统一 Web"目标冲突，双端维护成本高
6	用服务端多用户共享一个平台账号而不做串行锁	若 POC-2 证实"单账号单会话"，则会互踢、送审失败；即使证伪，并发上传同一账号也有风控风险
7	在客户书面授权文件未到位前就上线自动送审	授权范围不清，封禁责任与数据使用无依据
8	在模板规范/首批样张未到位时承诺"四层信息完整产出"	供给方已确认，但规范与样张不到位仍会让引擎改造失去验收基准（A-01）
9	以"与设计稿像素级一致"作为验收标准	字体/渲染引擎差异客观存在；应改为"差异在约定阈值内 + 业务可接受"

---

附录 A　关键证据索引

#	结论	证据
1	dewu 已从下载器演进为五段闭环工作台（v2.7.0，228 commits）	参考项目/dewu-material-Downloader/ git 历史；调研报告 §1、§2
2	dewu 全仓无唯品会代码	全仓检索 唯品会|vipshop|vip.com 零命中（本评估独立复核）
3	星光只读接口可无浏览器复现（签名 + 信封）	dw/scripts/lib/platform-sign.mjs:20-37、dw/docs/接口登录通道-实现说明.md:146-169
4	送审默认页面自动化（写接口技术上可重放，成本/风控更高）	dw/electron/submit/page.ts:2-30,47,68、dw/docs/星光平台API接口文档.md:342-404、dw/docs/星光平台送审与审核查询-可行性评估.md:638,750
5	平台单账号单会话是【推断，待 POC-2 验证】	dw/docs/星光平台送审与审核查询-可行性评估.md:100（源文档标注推断）
6	送审判定/命名/预检为纯逻辑，可复用	dw/scripts/lib/submit-naming.mjs（1,013 行）、dw/docs/送审命名规范与预检规则.md:20-93
7	仓库仍硬编码 Cookie 同步密钥/FTP 密码	dw/electron/config/developer.ts:130,135
8	scgf 为可部署生产态（容器化/迁移/CI）	参考项目/sucaigongfang/deploy/*、backend/src/utils/migrator.ts
9	scgf API 与 Worker 同进程	参考项目/sucaigongfang/backend/src/app.ts:65-66,402
10	scgf 19 表 / 11 迁移 / 113 接口	调研报告 §4.1、§2；backend/src/routes/*、models/*
11	PSD 引擎所有替换图层共用一张商品图	backend/src/utils/materialComposer.ts:222-236,516-620
12	命名引擎成熟（变量/客户级/快照/校验）	backend/src/utils/namingConfig.ts:28-72,240-403、types/naming.ts:19-40,104-119
13	系统配置框架 40 项 / L1-L3 / 审计	backend/src/utils/systemConfigRegistry.ts:33-100,192-760
14	客户范围 fail-closed	backend/src/utils/clientScopeCore.ts:12-22
15	docs/ 110 文件 0 入库	参考项目/sucaigongfang/.gitignore:122、git ls-files docs = 0（本评估独立复核）
16	AI 生图 main 分支零产品代码	调研报告 §5.3；grep -rniE "seedream|volc|aigc" backend/src frontend/src = 0
17	M1 分支整体作废	docs/AI生图相关功能-实现方案.md:6
18	M2-0 验证结论（34/34、flash 19~25s、单价未获取）	docs/AI生图-M2-0验证记录.md:8-11,46-66,120-135
19	AI Key 不能进系统配置	docs/AI素材生成-与现有系统整合方案.md:122-155
20	字体商用授权待确认	调研报告 §9.1；backend/fonts/方正兰亭中黑简体.TTF
21	两项目 LOC 口径	dewu 65,253（本评估复核 git ls-files + wc）；scgf 63,632（调研报告 §6.1 命令）
22	scgf 单机架构（本地磁盘 + 内存限流）	scgf/backend/src/utils/uploadPath.ts:20、middlewares/rateLimit.ts:11-18
23	scgf 通知模板 5 类；failure_catalog/notification_template 非表	scgf/backend/src/utils/notificationTemplates.ts:130-156、utils/failureCatalog.ts:46
24	调研报告敏感值已脱敏（SALT 等不可入库）	docs/评估/_调研/dewu-调研报告.md（SALT 已替换为占位）

完整证据（合计 105 条 文件:行）见两份调研报告的"证据索引"章节。

附录 B　本次评估的局限

局限	说明	影响
未运行代码	未安装依赖、未构建、未跑测试、未真机验证	"能跑通"的判断来自历史实测记录 + 静态阅读，需 POC 复核
未向平台方直接求证	未与得物/唯品会确认工具合规性；目前依据客户授权（待补文件）	R-01 的残余平台条款风险需业务/法务接受并留档
未取得报价	AI 生图/视频、云资源、字体均未询价	§7.5 为量级参考，预算需采购复核
设计资产样张未到位	供给方已确认（设计师角色），但尚未取得真实 PSD/展示方式/促销样张与规范	POC-4 需在样张到位后执行；验收标准随规范确定
未做人力成本测算	只用人日/人年，未乘薪资	预算需财务按实际人力成本换算
估算为量级	±25%，且 POC 结果可能推翻	不建议把 §7.2 直接写进合同或对外承诺
PRD 不完整	2~10 章为空，14 项功能无细节	范围与验收标准需产品补齐
图片/视频 AI 验证样本偏差	scgf 的 AI 验证以券商素材为主，与电商场景不同	AI 结论不能整体平移，需按电商素材重验

附录 C　后续应产出的配套文档

文档	时点	负责人
《平台电商素材生产平台 PRD V0.2》（补 2~10 章）	M0	产品
《平台/客户/项目数据模型设计》	M0	架构
《技术架构设计说明书 + ADR》	M0	技术负责人
《API 契约（OpenAPI）+ DTO 类型》	M1	前后端
《数据迁移方案（含对账/回滚）》	M1	后端
《渲染引擎改造与回归测试方案》	M1	图片产线
《平台适配层（得物/唯品会）接口与选择器说明》	M1/M3	平台 Worker
《AI 生成能力验证与成本预算》	M3	AI 负责人
《视频产线 MVP 方案与验收标准》	M4	产品 + AI
《部署/运维/应急手册（含备份/回滚/RTO-RPO）》	M1	运维
《3 年 TCO 与年度预算表（人力/基础设施/AI 调用/字体）》	M0	产品 + 财务
《设计资产供给方案与模板规范》	M0	设计 + 产品

附录 D　评审确认

角色	姓名	结论（Go / Conditional Go / No-Go）	意见	日期
产品负责人
技术负责人
设计负责人
测试负责人
业务负责人

---

本文基于 2026-10-30 的代码与文档快照，参考项目版本分别为 dewu v2.7.0（fe7646b）与 scgf v1.0.0（d1b01fa）。所有估算随 POC 结论更新，版本号按"小改升次版本、范围/方案重大调整升主版本"维护。