ai-optimization-task-software-table.md 9.0 KB
AI 提号优化任务表
本文档是给 AI 长跑任务和软件端任务配置直接引用的表格版说明。所有真实 token、sessionToken、模型 key 只能通过运行时环境变量传入，不得写入任务表、日志或输出文件。
1. 任务总表
| 阶段 | 输入 | AI 动作 | 输出文件 | 验收标准 | 不通过处理 |
|---|---|---|---|---|---|
| 运行前检查 | 本地代码、npm 包、mock provider | 执行 npm run acceptance、npm run acceptance:providers:mock、npm run optimization:status |
outputs/optimization-status-*/optimization-status-report.md |
package、MCP、mock provider、软件端表、视频 A/B smoke 全部通过；泄密和乱码扫描为 0 | 先修自动化失败项，不启动 live 长跑 |
| 真实数据准备 | 5-10 个历史 Brief、参考账号/视频、人工最终名单、客户选择/拒绝记录、人工补号量基线 | 执行 npm run history:audit -- --input <目录> --output <目录> --strict |
historical-dataset-audit-report.md、historical-dataset-audit.json |
每个 Brief 都有人工名单、客户选择或拒绝原因；要证明人工补号减少时必须有历史人工补号基线 | 缺字段时只允许做流程测试，不能宣称客户效果达标 |
| 受控 live 子集 | 真实 Parse sessionToken、company、VOC social token、视频分析运行时 token | 小规模跑 baseline-live、reference-account、homepage-evidence、result-first |
tihao-sourcing-report.md、tihao-sourcing-result.json、tihao-sourcing-client-list.csv |
业务接口可用；输出无 token；软件端表重复键为 0；每个 brief 排名连续 | 记录失败原因，先修鉴权、召回、provider 或输出结构 |
| 完整策略矩阵 | 覆盖多个品类的历史 Brief | 跑 baseline-live、reference-account、homepage-evidence、video-enhanced、result-first、result-first-broad |
aggregate-report.md、aggregate-summary.json、manual-review-sample.csv |
failureCount=0；每个 Brief 至少一个策略通过；每个 Brief 至少产出目标人数 1.5 倍可复核候选 |
每轮只优化一个主要失败原因，重跑同一矩阵对比 |
| 参考视频 A/B | 同一 Brief、同一参考视频、真实视频 URL、豆包视频分析服务 | 执行 npm run acceptance:video-ab，对比无视频证据和有视频证据两组 |
video-hit-rate-report.md、video-hit-rate-summary.json |
B 组拿到真实视频 URL；拿到封面、字幕/ASR、帧图至少一类；证据卡不是占位；强推荐数、Top 10 平均分、参考风格分不下降；证据命中候选增加 | 不能说视频分析已提升命中率；按视频资源、证据解析、排序权重分别修 |
| 人工复核 | 已预置 客户选择、归因类型、反馈原因 列的 manual-review-sample.csv |
商务填写人工复核标签；负样本填写归因类型；有客户反馈时填写客户选择 | 标注后的 CSV、review-metrics-report.md |
商务可用率 >= 60%；负样本率 <= 10%；负样本归因覆盖率 = 100%；有客户选择时客户选中率 >= 30% | 按归因类型进入下一轮优化，不降低门槛 |
| 反馈闭环 | 商务负样本反馈、客户偏好、剔除账号 | 导入偏好记忆并重跑第二轮 | tihao-preference-memory.json、第二轮软件端 CSV |
被拉黑或跑偏账号不再进入商务名单；调性/主页质感反馈写入偏好；同类反馈 3 次以上才建议团队规则 | 检查记忆写入、剔除规则、排序降权是否生效 |
| 状态沉淀 | 本轮命令、输出目录、指标和边界 | 更新实施日志并执行 npm run optimization:status、npm run evidence:index |
实施日志、状态审计报告、证据台账 | passed、ready_not_proven、blocked_by_external_data 状态清楚；未证明项不被标成完成 |
保留边界说明，等待真实 provider 或客户数据 |
2. 软件端博主表固定格式
软件端最终接收的博主名单必须使用以下字段，默认文件名为 tihao-sourcing-client-list.csv。交付表按“全局博主唯一”去重：同一 平台 + 规范化主页链接 不得重复；没有主页链接时，同一 平台 + 规范化博主名称 不得重复。同一博主被多个 brief 或多个策略召回时，只保留证据更完整、综合分更高的一条进入交付表。
| brief编号 | 策略 | 排名 | 平台 | 博主名称 | 综合分 | brief匹配分 | 参考风格分 | 主页证据分 | 视觉质感分 | 调性一致分 | 证据加分 | 证据风险扣分 | 推荐理由 | 风险提示 | 主页链接 | 人工复核标签 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 客户 Brief 编号或品牌名 | baseline-live / reference-account / homepage-evidence / video-enhanced / result-first / result-first-broad | 去重后的连续排名 | 小红书/抖音/B站 | 账号展示名 | 最终排序分 | 硬性条件、人群、预算、关键词匹配分 | 参考账号或参考视频风格相似分 | 主页最近内容证据分 | 封面、画面、排版、场景质感分 | 近期内容调性一致分 | provider 或多模态证据加分 | 竞品、跑偏、内容不符等扣分 | 说明 Brief 命中点、参考风格或主页证据 | 说明报价、档期、竞品、合规或证据缺口 | 博主主页 URL | 商务填写 |
3. 人工复核标签表
| 标签 | 判定口径 | 是否计入负样本 | 后续动作 |
|---|---|---|---|
| 可直接发客户 | 硬性条件、调性、主页证据都通过 | 否 | 可进入客户名单 |
| 商务复核 | 基本可用，但需要确认报价、档期、近期内容或合作状态 | 否 | 补证后决定是否发客户 |
| 可投但需补证 | 候选有潜力，但缺视频、主页近作或人工确认 | 否 | 优先补证，不直接算失败 |
| 跑偏 | 内容方向、账号人设或品类明显偏离 Brief | 是 | 写入失败归因并降权或剔除 |
| 硬性规则违约 | 平台、粉丝、预算、地域、禁投项不符合 | 是 | 进入硬规则拦截 |
| 调性不符 | 数据可用，但风格不像参考账号或不适合品牌 | 是 | 写入调性偏好或负向风格 |
| 主页质感不符 | 封面、画面、排版、场景明显低质或下沉 | 是 | 提高主页证据和视觉质感权重 |
| 参考账号不像 | 参考链路召回但类型/调性相似度不足 | 是 | 调整参考账号拆解和相似度阈值 |
4. 去重和候选池验收
| 检查项 | 通过标准 | 自动化入口 |
|---|---|---|
| 表头固定 | 表头与 docs/software-client-table-format.md 完全一致 |
npm run software:smoke |
| 重复键 | 软件端表重复键数量为 0 | npm run software:smoke、npm run candidate-pool:smoke |
| 排名连续 | 每个 brief 内排名从 1 开始连续 | npm run software:smoke、npm run candidate-pool:smoke |
| 候选池规模 | 每个 Brief 至少输出目标人数 1.5 倍的可复核候选；不足时必须给出补量提示 | npm run candidate-pool:smoke |
| 剔除账号 | 已剔除账号不得进入软件端交付表 | npm run hard-rules:smoke |
| 中文编码 | CSV 使用 UTF-8 BOM，Excel 打开不乱码 | npm run software:smoke |
| 表格版沉淀 | 已去重 CSV 可以转换成同字段 Markdown 表格 | npm run software:markdown -- --input <CSV> --output <MD> |
5. 对 AI 的执行指令
| 项目 | 指令 |
|---|---|
| 目标 | 优化 @vocmarket/tihao 的提号命中率和商务可用率，让上传 Brief 后能稳定输出商务可复核、可解释、可沉淀的博主名单。 |
| 优先级 | 本轮优先结果质量，不优先压成本；但不得泄露任何 token、sessionToken、Authorization 或模型 key。 |
| 策略 | 每个 Brief 跑基础召回、参考账号、主页证据、视频增强、结果优先、扩大召回后重排等策略，并按同一指标比较。 |
| 指标 | 强推荐数量、Top 10 平均综合分、参考风格分、主页证据覆盖率、商务可用率、负样本率、客户选中率、人工补号量。 |
| 强推荐证据 | 每个强推荐必须至少有 2 条 Brief 命中点，并至少有 1 条 referenceStyleHitPoints 或 homepageEvidenceHitPoints。 |
| 参考占位证据 | 需补相似账号证据、待补参考风格证据 只能写入 referenceFallbackHitPoints，不得混入 referenceStyleHitPoints；referenceEvidenceConcrete=false 时不得单独支撑强推荐。 |
| 主页质感门槛 | 命中封面下沉、封面混乱、排版混乱、画面模糊、低质等风险时，不得进入强推荐，并保留 homepageQualityRisks。 |
| 归因 | 每个失败样本必须归到需求解析错、隐性规则漏、召回关键词错、主页证据不足、视频证据误判、排序权重错、输出解释错、软件端表重复或排名不连续之一。 |
| 迭代 | 每轮只优化一个主要失败原因，重跑同一矩阵，记录 baseline 与优化后指标差异。 |
| 禁止 | 不得把 sample 通过当成真实命中率证明；不得把 provider fallback 当成真实 provider 通过；不得为了通过而降低门槛。 |