# 程1复盘 + 后续执行设计（断点续）

> 2026-06-13。程1(wf_d840d358-d3e)跑1.9h后failed。本文件记根因+已落成果+程2/3设计,断点可续。

## 程1根因（已诊断）
workflow 的 stall 检测 = **180s 无工具调用完成就杀 agent**。
Clover 端到端生成本身要 **312s**。任何把"跑完整生成验证"当单步阻塞的 agent → 必超180s被杀 → 6次重试全栽同一坑 → workflow failed。
这是**编排设计问题，不是代码问题**。

## 程1已落成果（没白跑，真进项目）
1. ✅ 环境勘验完成：
   - codeRoot=`Clover/backend`，frontendRoot=`Clover/frontend`(不在docker compose,需npm单独跑)
   - docker-compose.yml 在 `backend/` 子目录(不在项目根)，compose命令要加 `-f` 或 cd backend
   - 后端代码挂载热重载(api带--reload，改.py自动生效)；**worker无热重载，改worker/service代码后须 `docker compose restart worker`**
   - 迁移命令 `docker exec clover_api alembic upgrade head`；api启动也自动跑一次
   - 6容器全Up健康；端到端跑法见环境勘验result(登录admin/Clover2026!→product_id=1→建任务→轮询)
   - ⚠️backend的.py改动不在大repo的git status里(被ignore?)，无法git回滚追踪
2. ✅ 迁移008-011真跑成功落库(alembic 007→011)：
   - 008 products.brand_keyword VARCHAR(64)
   - 009 benchmark_notes.features_json TEXT + analyze_status VARCHAR(20)
   - 010 fission_tasks 表新建
   - 011 generation_tasks.benchmark_ids TEXT + source_fission_id INT
   - 新建 app/models/fission.py FissionTask ORM；models/__init__.py 已导出
3. ◐ M1文案三处改动已写进代码(待端到端验证)：
   - S7模型三处全改对：config.py:27 + gemini_factory.py:166 + .env:20 = claude-opus-4-8
   - S8重试退避：text_variants.py:43-49 503/429指数退避 2^attempt
   - S1合格过滤+needs_replenish：pipeline_io.py:98-138 passed且score>=QUALITY_PASS_SCORE且非hard_block，saved<text_count触发补充
   - 验证中：task42(2026-06-13)端到端真跑确认

## 后续执行设计（倩倩姐拍板：拆细workflow+我跑验证）
铁律：**agent 只改代码不跑312s长验证**；端到端真跑验证由主线程(我)用 Monitor 后台盯，不受stall限。
- workflow里的agent活拆到180s内能完成：读清单+改文件+跑只读/快命令(grep/SELECT/import检查)
- 抓"模型是不是opus-4-8"用 grep 代码+抓单次请求体，不靠跑完整生成
- 端到端一条龙、312s生成 → 我在主线程 Monitor
- 每环仍独立交叉验证(另起agent重核代码层)，但效果层(真出文案/图)我主线程验

## 程2待办(M3审核/M4归档/M5底座) — 多碰pipeline_io/task/tasks/config须串行
## 程3待办(M6标杆/M7裂变 用占位规则)
## M1验证中断点：task42 状态待Monitor回报；通过则M1勾✅，进程2

## M1验证实况（2026-06-13，真跑抓到3个真bug，绝不信自评的价值）
- **bug1 模型没切**：task42 worker日志跑的还是 claude-sonnet-4-5。根因=worker容器env_file固化4天前旧值，restart无效，必须 `docker compose up -d worker` 重建(已记忆 clover-worker-env-reload-trap)。修后 printenv MODEL_TEXT=claude-opus-4-8 ✅
- **bug2 返回值解包炸**：程1把 run_text_generation 改成返回3元组(加needs_replenish)，但 tasks.py:102 只解包2个 → `too many values to unpack (expected 2)`,整个pipeline崩+retry循环。这正是核销表"S1+S3必须同步"风险。已修 tasks.py:102 解包3元组。
- **bug3 后台补充task缺失**：needs_replenish只算出来没人消费(先展示后台补铁律没落地)。已新建 app/workers/replenish_task.py 的 replenish_text_candidates(MAX_REPLENISH_ROUNDS=3),tasks.py:108 needs_replenish时.delay触发,celery_app include+tasks.py re-export注册。
- **确认链路**：task44日志铁证 model=claude-opus-4-8 success=1 latency296s(opus确实慢~300s)。opus单次响应慢,注意网关60s上限风险。
- **task45**：发干净任务验证全部修复后的完整链路(opus+解包+补充),Monitor盯中。
- sonnet旧分数(task42)：3条total 80/81/80全不过90,第4/5分项系统性低(9分/0-5分)——待opus这轮看能否过90,要倩倩姐判质量。

## 程2待办(M3审核/M4归档/M5底座) — 多碰pipeline_io/task/tasks/config须串行

## M1验证收尾（2026-06-13下午，60s网关根因彻底解决+又揪2个真bug）
### ✅ 已铁证跑通（task47完整闭环）
- **60s网关503根因锁定**：不是apiports过载/opus慢，是 `max_tokens=8192写死`——opus会撑满输出空间导致单批>60s撞网关。实测单条max_tokens=1500~2500仅16~18s。
- **修复3处全验证生效**：①`_call_llm`的max_tokens参数化 ②`_generate_one_batch`按批量`min(8192,max(1800,n*1800))`缩放 ③`.env`的TEXT_BATCH_SIZE=1。
- **task47链路全绿**：首轮3条串行112s全成功零503→评分→过滤(只1条≥90)→先展示入库→needs_replenish触发→后台补充任务received。"先展示后台补"两截都跑通。
- **opus文案质量样本(task47 id=227)**：91分(标题23/情绪25/买点25/关键词13/合规5)，真实素人口吻、痛点切入、emoji自然、合规满分。明显优于sonnet旧档(80分)。

### 🐞 又揪2个真bug（绝不信自评的价值）
- **bug4 补充任务计数维度错**：replenish_task.py第76行`added_total += len(raw)`把"原始生成数"当"合格入库数"，task47实测len(raw)=2但saved=0(都没过90)→误判"累计3/3"提前停，库里实际仍缺2条。已修=改用DB真实count(`db.expire_all()`+`db.query(TextCandidate).count()`)做循环条件，return真实`current-existing`。
- **bug5 tasks.py日志措辞误导**：`已合格=%d`实际填的是len(candidates_raw)原始生成数。已修措辞为"本轮生成"+注释说明以库内saved_count为准。

### ⚠️ apiports实时负载波动（非代码问题，需留意）
- task48验证补充修复时撞apiports高负载：同样batch1单条，第1条35s成功，第2条起涨到61s→503，3次退避重试都撞高负载窗口。基线18s→35s→61s说明是中转站负载翻倍不是代码。
- **代码已是最优**(串行单条+动态max_tokens+退避)，apiports抽风时单条也会被拖过60s，重试救不回。这是产品级风险点，要攒给倩倩姐判断容错策略。

### M1状态：代码层✅全绿(3修复+2bug已修验)；效果层◐ task47闭环已证，补充DBcount修复待apiports恢复后真跑确认

## M1最后一跑(task49,2026-06-15)：机制全绿但合格率暴露结构性问题
### ✅ 机制层全部验证通过(哪怕极端0合格case)
- task49跑出9条文案分数：79/83/71/71/87/81/79...**无一自然≥90**。
- 先展示：0条合格也置pending_selection不卡用户 ✅
- 后台补充：3轮全跑，用DB真实count判断(bug4修复生效,没再误报"够了") ✅
- 诚实上报：`replenished=0 rounds=3 final=0 target=3`，达上限停止不无限补 ✅
- 容错(倩倩姐拍板加大重试)：max_attempts=5+退避5/10/20/30s 已生效 ✅
- bug6修复：image_count=0早退守卫(纯文案任务不再空跑生图通道) ✅

### 🔴 暴露的结构性质量问题(需倩倩姐判断,非bug)
- **90分线对素颜霜合格率极低**(task47首轮3条过1条,task49首轮3条+补充6条共9条过0条≈合格率0-25%)。
- **根因=评分权重结构**：满分=标题25+情绪25+买点25+关键词20+合规5。实测每条卡在**关键词覆盖13/20**(必扣5-7分,note总是"建议补品类词/长尾词")。光这项扣7分→要过90必须其余四项几乎全满分,实际把及格线推到"四项满分"。
- task47那条91分=标题23+情绪25+买点25+关键词13+合规5,是"四项接近满"的运气case。
- **opus文案本身质量不差**(真实素人口吻/痛点切入/emoji自然/合规满分),是90线+关键词20分权重太严,不是文案烂。

### 待倩倩姐判断(攒批):①90线降不降/关键词权重调不调 ②还是先让北哥抽检原文再定线 ③合格率低时补充上限3轮够不够

## 根因实锤+错误回滚(task50,2026-06-15晚)
### 🎯 关键词维度卡死的真正底因(已实测坐实)
- 之前说"依赖products.keywords配置"还不够准。**实测products表根本没有keywords字段**(只有name/category/selling_points/style_tone/text_angles/custom_prompt/image_path/brand_keyword)，build_product_dict()也没传keywords。
- 所以score_keyword的`matched=[k for k in keywords...]`里keywords恒为[]→matched恒空→matched≥1(+6)+matched≥2(+5)=11分**永远拿不到**，关键词维度天花板被锁在9-13分(只靠tags≥3+5/有#+4/tags≥5+4凑)。
- 入库3条实测明细坐实：id225=标19情23买25**关9**合5=81；id226=18/23/25/**9**/5=80；id227=23/25/25/**13**/5=**91✅**。关键词全卡9-13。

### ❌ "调权重"是错误方向,已回滚
- 试过keyword20→10、把10分补给title/emotion(30/30)。task50实测84/67/75**反而更低**。
- 失败原因：title/emotion的加分项要文案命中特定硬词表(场景词/情绪词/品类词)才填得满，封顶34/33。文案没变命中的词没变，新增的权重空间填不满→总分不升反降。删了keyword能稳拿的分，没换来title/emotion的新增分。
- **已回滚constants.py到原始权重25/25/25/20/5**，worker重启确认生效。constants.py注释已记录真相+正确解方向。

### ✅ 正确解(等北哥标准到位,二选一或都做)
1. 给products表补keywords字段+前端录入(让matched能真匹配)——治标，让现有硬词表评分跑通。
2. 评分用LLM语义判分替代硬编码词表(score_keyword/title/emotion都改成让模型判)——治本，但要北哥的质量标准/prompt到位。
- 现阶段：维持原始权重占位，真过关靠北哥抽检，不靠机器调权重凑数(机器分高≠过关,CLAUDE.md铁律)。

### M1结论：机制层✅全绿(已勾)；合格率=占位规则的已知局限,不阻断进程2,等北哥质量标准到位再治本