给 AI 的提号 SOP 长跑优化任务

目标

持续优化 @vocmarket/tihao，直到它能稳定把客户 Brief 转成商务可用的博主名单。优先级是结果质量：更高命中率、更强 Brief 相关性、更有效的参考账号/参考视频风格匹配、更低负样本率。

本轮不以成本为第一约束，但任何 token、sessionToken、模型 key、Authorization header 都不能写入代码、文档、报告、日志或输出文件。

工作目录

E:\workspace\tihao-ai\claude-code-tihao-sourcing

运行前检查

先跑本地发布验收：

npm run acceptance
npm run acceptance:providers:mock
npm run optimization:status

如果要验证真实 live/provider/video，先跑预检：

$env:TIHAO_SESSION_TOKEN="<Parse sessionToken>"
$env:TIHAO_COMPANY="<Company objectId>"
$env:VOC_SOCIAL_TOKEN="<Parse sessionToken>"
$env:VIDEO_ANALYSIS_BASE_URL="https://api.fmode.cn"
$env:VIDEO_ANALYSIS_MODEL="doubao-seed-2-0-pro"
$env:VIDEO_ANALYSIS_TOKEN="<runtime model token>"
npm run live:preflight -- --strict

预检失败时不要启动 live 长跑。

把 live 预检和历史数据审计汇总成可交接的长跑就绪报告：

npm run longrun:readiness -- --mode full-matrix --preflight <live-preflight-summary.json> --history <historical-dataset-audit.json> --output <输出目录> --strict

如果要验证视频 A/B：

npm run longrun:readiness -- --mode video-ab --preflight <live-preflight-summary.json> --strict

如果要验证客户选中率和人工补号减少：

npm run longrun:readiness -- --mode customer-effect --preflight <live-preflight-summary.json> --history <historical-dataset-audit.json> --strict

历史数据准备

如要验证客户选中率，先准备 5-10 个真实历史 Brief，包含客户原始 Brief、参考账号/视频、人工最终名单、客户最终选中/拒绝记录和拒绝原因。

验收：

npm run history:audit -- --input <history-dataset目录> --output <输出目录> --strict

只有 history:audit 显示可用于长期优化长跑，才可以验证客户选中率 30%/50%。没有真实客户选择字段时，只能验证商务复核通过率。

受控 live 子集

正式长跑前先跑小子集。它会消耗真实额度，范围要小。

$env:TIHAO_OVERNIGHT_LIVE="true"
$env:TIHAO_OVERNIGHT_FIXTURES="dha-mom-baby"
$env:TIHAO_OVERNIGHT_VARIANTS="baseline-live,reference-account,homepage-evidence,result-first"
$env:TIHAO_OVERNIGHT_MAX_RUNS="4"
$env:TIHAO_OVERNIGHT_FAIL_ON_GATES="true"
npm run overnight:quality

如果要验证真实 reference/homepage provider，打开严格门槛：

$env:TIHAO_GATE_REQUIRE_REFERENCE_PROVIDER="true"
$env:TIHAO_GATE_REQUIRE_HOMEPAGE_PROVIDER="true"

严格门槛打开后，fallback/sample 失败是正确结果，不要为了通过降低门槛。

完整 live 矩阵

受控子集通过后再跑完整矩阵：

$env:TIHAO_OVERNIGHT_FIXTURES="dha-mom-baby,sensitive-skin-repair,healthy-snack,home-cleaning,618-list-seeding"
$env:TIHAO_OVERNIGHT_VARIANTS="baseline-live,reference-account,homepage-evidence,video-enhanced,result-first,result-first-risk,result-first-broad"
$env:TIHAO_OVERNIGHT_DELAY_MS="1500"
$env:TIHAO_OVERNIGHT_RUN_RETRIES="1"
$env:TIHAO_OVERNIGHT_RESUME="true"
$env:TIHAO_OVERNIGHT_FAIL_ON_GATES="true"
npm run overnight:quality

查看：

outputs/overnight-quality-*/aggregate-summary.json
outputs/overnight-quality-*/aggregate-report.md
outputs/overnight-quality-*/manual-review-sample.csv

参考视频 A/B

有参考视频时，单独验证视频分析是否真的提升提号结果：

npm run acceptance:video-ab

通过标准：

B 组必须拿到真实视频 URL。
B 组必须拿到封面、ASR/字幕、帧图资源中的至少一类。
B 组证据卡不能只是 pending、fallback 或待补证据。
B 组证据卡必须包含 text、ASR、visual、frame 中至少一类可解释信号。
B 组 Top 10 证据命中候选增加。
B 组强推荐数量、Top 10 平均分、参考风格分不得下降。

没有通过这条命令，不要说视频分析已经证明能提升提号率。

人工复核和业务指标

人工复核 manual-review-sample.csv。长跑表已预置 客户选择、归因类型、反馈原因 三列，商务不用手动加列。

在“人工复核标签”列填写：

可直接发客户
商务复核
跑偏
硬性规则违约
调性不符
主页质感不符
参考账号不像
可投但需补证

如果拿到客户最终选择，在 客户选择 列填写：

客户选中
客户拒绝
待客户反馈

所有负样本必须填写 归因类型。负样本包括：

跑偏
硬性规则违约
调性不符
主页质感不符
参考账号不像

归因类型必须落到可优化环节，例如：

需求解析错
隐性规则漏
召回关键词错
主页证据不足
视频证据误判
排序权重错
输出解释错
软件端表重复或排名不连续

统计业务指标：

npm run review:metrics -- --input <已标注CSV> --output <输出目录> --strict

短期目标：

商务可用率 >= 60%。
负样本率 <= 10%。
负样本归因覆盖率 = 100%。
有客户选择字段时，客户选中率 >= 30%。

中长期目标：

有参考账号的 Brief，客户选中率 >= 40%。
客户选中率稳定 >= 50%。
同类需求下人工补号量减少 50%。

失败后怎么优化

不要降低门槛来凑通过。按失败样本归因：

需求解析错。
隐性规则漏。
召回关键词错。
主页证据不足。
视频证据误判。
排序权重错。
输出解释错。
软件端表重复或排名不连续。

每轮只优化一个主要失败原因，重跑同一矩阵并记录提升。

必须沉淀

每轮结束后更新：

docs/tihao-experience-implementation-log.md

记录：

运行命令。
输出目录。
是否 live。
是否打开严格 provider 门槛。
failureCount、gatePass、failedGateCount。
软件端重复键和排名连续性。
provider 状态。
人工复核指标或客户选中率。
明确说明还没有验证的边界。

同时运行：

npm run optimization:status
npm run evidence:index

如果状态里仍有 ready_not_proven 或 blocked_by_external_data，不要宣布长期优化目标完成。evidence:index 会扫描 outputs 下的长跑、状态审计、review metrics、历史数据审计和视频 A/B 产物，区分 real_evidence、smoke_or_local 和 not_business_proof。

不允许做的事

不要硬编码 Parse token、模型 token、npm token 或 Authorization header。
不要在 manifest.liveEnabled=false 时声称已经 live 验证。
不要把 sample 模式通过当成命中率证明。
不要把 fallback/provider 状态存在当成真实 provider 通过。
不要为了通过而降低验收门槛。
没有通过 package acceptance 和目标 live gate 前，不要发布新 npm 版本。

交付物

已更新的实现文件。
已更新的运行手册和验收文档。
最新 live 输出目录。
baseline 与优化策略的指标对比。
人工复核或客户选择后的 review-metrics 报告。
明确说明已验证内容，以及仍需真实 provider、真实客户反馈或人工复核的内容。

ai-overnight-optimization-task.md 7.4 KB Постоянная ссылка История Исходник