Files

yangqianqian 6a2632da70 baseline: Clover 独立仓库首次基线提交

将 Clover 从上层产品包旧仓库中独立出来,建立专属版本控制。
当前状态=纵切片端到端已打通(登录→选品→出文出图→审核→下载包),
M1文案质量去套路化已验收。此提交作为后续按核销清单逐条修复的基线。

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

2026-06-16 11:30:22 +08:00

9.7 KiB

Raw Blame History

Clover 修改处理方案 · 第三批（❌ 需新建/重构）+ 修3叠字

这批是新建模块或重构，技术不确定性高、且多数需北哥给业务定义。不像第一二批能直接给 before/after，这里给：现状/改造思路/影响文件/风险/待定义点。

修3 · 瓶身中文小字乱码（叠字兜底）【L·技术最不确定】

根因：gpt-image-2 画中文小字会糊/乱码（记忆 clover-image-gen-mixed-text-rendering 已记）。现状 storyboard 把所有文字(overlay_text)都塞进prompt让模型画（image_gen.py:140附近）。

改造思路（模型出底图 + 代码叠字）：

storyboard 区分"模型画的"vs"代码叠的"：大标题模型画(已清晰)，瓶身小字/品牌词/卖点改代码叠。
新建 image_text_overlay.py：PIL 加载中文字体(思源黑体开源)，按坐标叠字到底图。
image_gen 生图后、后处理前，调叠字。
prompt 负向约束模型"不要在瓶身画文字"。

影响文件：新增 image_text_overlay.py、storyboard.py(标记哪些字代码叠)、image_gen.py(接叠字)、字体资源(assets/fonts/)。 风险（高）：①叠字坐标/字号要按每张构图调，模型出图位置不固定→坐标难定 ②哪些字叠/哪些画的边界要试 ③字体版权(用SIL开源思源) ④可能要调好几轮才自然。 待定义点：这期做不做？我的建议——先验证模型把大标题画清楚(已能)，瓶身小字这种高不确定项放二期，一期先用"少画字、关键字代码叠品牌词"最小版本试。 最小版本(降risk)：只代码叠"品牌词"一处(位置固定在底部),不碰瓶身小字。工作量降到M。

建1 · 生图≥3套【L】

根因：storyboard.py:119 plan_image_set 只产1套storyboard，image_gen.py:156 generate_storyboard_images 只跑1套，返回扁平list。无"套"概念。

现状结构：

plan_image_set → {storyboard: [6张item]}  # 1套
generate_storyboard_images → gather 6张 → [6个结果]  # 扁平
pipeline_io → 存6张 ImageCandidate

改造思路：外层套循环。

for set_idx in range(3):           # 3套
    plan = plan_image_set(..., variant=set_idx)   # 套间差异
    套结果 = gather(...)
返回 [[套1的6张],[套2的6张],[套3的6张]]
ImageCandidate 加 set_no 字段；前端按套分组展示选择

影响文件：storyboard.py(plan加variant参数做差异)、image_gen.py(外层循环)、pipeline_io.py(存set_no)、models/task.py(ImageCandidate加set_no列+迁移)、前端图片选择页(按套展示)。风险：①生图成本×3、apiports限流(记忆:限并发2)→3套18张要控并发别打爆 ②"套间差异"是什么没定 ③前端展示改动较大。 待定义点（必须北哥/你定）：

3套的差异维度？候选：a)不同文案角度各出一套 b)同角度不同视觉风格 c)不同封面方案
套数固定3还是用户可选1/3/5？
是否每套都6张，还是套数×张数用户配？

建2 · 产品图视觉分析 visualIdentity【M】

根因：banana 有(上传产品图→提主色/字体/风格)，Clover 的 build_visual_system(storyboard.py:127)只用了文案锚点，没做产品图视觉提取。

改造思路：产品图上传后(或生图前)调多模态分析→提主色/包装风格→存产品档案→生图prompt注入"保持与参考图一致的主色/风格"。

影响文件：新增 visual_identity.py、products上传接口接入分析、product表加 visual_json 列+迁移、storyboard注入。风险：多模态调用成本+延迟；分析准确度。 待定义点：一期必要还是二期？我建议二期（现已强制带产品参考图给 /images/edits，视觉一致性已有基本保证，视觉提取是锦上添花）。

建3 · 标杆 AI 出8特征【L·需北哥定义】

根因：benchmarks.py 纯CRUD，BenchmarkCreate 只 screenshot_url/highlights/link_url 三字段，零AI分析。

改造思路：录标杆(截图/文本)→AI分析出8个特征维度→存库→生成时可参考。

影响文件：api/v1/benchmarks.py、新增标杆分析service、BenchmarkNote加 features_json 列+迁移、前端标杆展示。风险：与建4(裂变)强耦合——8特征是裂变的输入。 待定义点（必须北哥给）：8特征具体是哪8个？（如：钩子类型/痛点/人设/结构/卖点呈现/情绪/视觉/标题公式？）北哥不给定义，做不了。

建4 · 爆款裂变全套【XL·最大块·需北哥给完整流程】

根因：全栈零代码，整块缺失。

完整流程（待北哥确认）：选标杆→选参考度档位(高/中/低)→选裂变维度→基于标杆8特征生成变体→裂变后评分。

影响文件（大量新增）：后端裂变service+router、裂变记录表+迁移、前端裂变页(选标杆/档位/维度/看结果)。强依赖建3的8特征。风险：这是独立新功能，不是修补。工作量远超其他项。依赖建3。 待定义点（必须北哥给）：

完整裂变流程定义
"参考度档位"高/中/低分别意味着多大改动？
裂变维度有哪些可选？
裂变后评分用现五维还是另立标准？建议：单独立项，与bug修复彻底分开。北哥不给流程定义无法开工。

建5 · 去水印强制3:4比例【S】

根因：image_postprocessor.py process_image 只重编码+重采样，无比例校验/裁切。

现状代码（image_postprocessor.py:41-49）：

img = Image.open(io.BytesIO(image_bytes)).convert("RGB")
original_size = img.size
if resample_strength >= 1:
    w, h = original_size
    small_w, small_h = int(w * 0.98), int(h * 0.98)
    img = img.resize((small_w, small_h), Image.LANCZOS)
    img = img.resize(original_size, Image.LANCZOS)

改后：开头加3:4校验+居中裁切。

img = Image.open(io.BytesIO(image_bytes)).convert("RGB")
# 强制3:4(1080×1440)：偏差超阈值则居中裁切
w, h = img.size
target_ratio = 3 / 4
cur_ratio = w / h
if abs(cur_ratio - target_ratio) > 0.02:
    if cur_ratio > target_ratio:        # 太宽→裁宽
        new_w = int(h * target_ratio)
        left = (w - new_w) // 2
        img = img.crop((left, 0, left + new_w, h))
    else:                                # 太高→裁高
        new_h = int(w / target_ratio)
        top = (h - new_h) // 2
        img = img.crop((0, top, w, top + new_h))
original_size = img.size   # 裁后尺寸

影响文件：backend/app/services/ai_engine/image_postprocessor.py（约12行）。风险：居中裁切可能切到边缘内容；gpt-image-2 本就按1080×1440出图，多数已是3:4，裁切是兜底保险。验收：故意喂非3:4图→输出严格3:4。

建6 · 客户输入物整体导出【M】

根因：只有产出物打包(package_exporter)，无产品/标杆等输入物导出。数据归属红线：客户原始数据可导出。

改造思路：加 GET /products/export、GET /benchmarks/export，导出该workspace全部输入物为zip(含json+上传的图)。 影响文件：新增导出router+service。风险：导出格式(json/csv/zip)、是否含上传的图要定。 待定义点：格式？一期必要还是二期？建议二期（飞轮启动+北哥测试期客户数据导出诉求不急）。

根因：全局无放大逻辑，img直接渲染，看不清细节。 改造思路：图片卡加点击放大遮罩(轻量自写或 yet-another-react-lightbox)。 影响文件：前端图片相关组件(images页/confirm页)+新增Lightbox组件。风险：无。验收：点图弹出大图遮罩。建议：直接做，体验刚需且简单。

建8 · 套版预览（封面+内页拼笔记）【M】

根因：confirm页只网格分开展示图(ConfirmPreviewImages)，没拼成"一条小红书笔记长相"。 改造思路：confirm页加"笔记预览"视图：封面图+内页轮播+文案标题正文，按小红书样式排。 影响文件：前端confirm页+新增笔记预览组件。风险：还原小红书样式要调。 待定义点：一期必要还是二期？建议二期（confirm已能逐个看图+文案，拼版是体验增强非阻断）。

建9 · 任务级并发上限【M】

根因：只有 celery worker_prefetch_multiplier=1（worker层），无用户/任务级并发限制。用户狂点开任务可能堆爆。 改造思路：任务创建时查该用户在跑任务数(DB status查或Redis计数)，超N则拒绝/排队。 影响文件：任务创建router、可能加Redis计数。风险：限制策略要定。 待定义点：每用户允许几个并发任务(建议2-3)？超限拒绝还是排队？

第三批小结

项	性质	建议期次	阻塞点
修3叠字	重构·高不确定	一期最小版(只叠品牌词)/二期完整	技术验证
建1 3套图	重构	看北哥要不要	套间差异定义
建2 视觉分析	新建	二期	—
建3 标杆8特征	新建	看北哥	8特征定义
建4 爆款裂变	新建·XL	单独立项	完整流程定义
建5 强制3:4	改造·小	一期可做	—
建6 输入导出	新建	二期	格式
建7 lightbox	新建·小	一期可做	—
建8 套版预览	新建	二期	—
建9 并发上限	改造	一期可做	并发数

无歧义可直接做：建5(3:4)、建7(lightbox)、建9(并发，定个数即可)。 需北哥给定义才能动：建3(8特征)、建4(裂变流程)。 建议二期：建2、建6、建8。 技术验证后再定：修3叠字。

9.7 KiB Raw Blame History Unescape Escape