qianqian/beige
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
a565ed5b9699051aaf5854d29c31dd515053389b
beige/plans/程1复盘与后续设计.md
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

程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=15002500仅1618s。
  • 修复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,等北哥质量标准到位再治本

Reference in New Issue View Git Blame Copy Permalink