baseline: Clover 独立仓库首次基线提交
将 Clover 从上层产品包旧仓库中独立出来,建立专属版本控制。 当前状态=纵切片端到端已打通(登录→选品→出文出图→审核→下载包), M1文案质量去套路化已验收。此提交作为后续按核销清单逐条修复的基线。 Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This commit is contained in:
yangqianqian
196
plans/修改处理方案-第三批.md
Normal file
196
plans/修改处理方案-第三批.md
Normal file
@@ -0,0 +1,196 @@
|
||||
# Clover 修改处理方案 · 第三批（❌ 需新建/重构）+ 修3叠字
|
||||
|
||||
> 这批是新建模块或重构，技术不确定性高、且多数需北哥给业务定义。
|
||||
> 不像第一二批能直接给 before/after，这里给：现状/改造思路/影响文件/风险/待定义点。
|
||||
|
||||
---
|
||||
|
||||
## 修3 · 瓶身中文小字乱码（叠字兜底）【L·技术最不确定】
|
||||
|
||||
**根因**：gpt-image-2 画中文小字会糊/乱码（记忆 clover-image-gen-mixed-text-rendering 已记）。
|
||||
现状 storyboard 把所有文字(overlay_text)都塞进prompt让模型画（image_gen.py:140附近）。
|
||||
|
||||
**改造思路**（模型出底图 + 代码叠字）：
|
||||
1. storyboard 区分"模型画的"vs"代码叠的"：大标题模型画(已清晰)，瓶身小字/品牌词/卖点改代码叠。
|
||||
2. 新建 `image_text_overlay.py`：PIL 加载中文字体(思源黑体开源)，按坐标叠字到底图。
|
||||
3. image_gen 生图后、后处理前，调叠字。
|
||||
4. 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）：
|
||||
```python
|
||||
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校验+居中裁切。
|
||||
```python
|
||||
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)、是否含上传的图要定。
|
||||
**待定义点**：格式？一期必要还是二期？建议二期（飞轮启动+北哥测试期客户数据导出诉求不急）。
|
||||
|
||||
---
|
||||
|
||||
## 建7 · 图片 lightbox 放大【S】
|
||||
|
||||
**根因**：全局无放大逻辑，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叠字。
|
||||
Reference in New Issue
Block a user