达人脚本审核
解决痛点：大量脚本人工审核漏细节，视频产出后难改。原则：机械核对交给脚本（零遗漏），理解判断交给 AI（语境、主旨、业务契合），拿不准的一律 ❓ 交用户拍板，绝不编造。
规则库为全平台统一库：references/rules.md（人读）+ references/rules.keywords.txt（机扫）。通用条款默认全平台适用；仅个别平台适用的条款收在 rules.md「第四节 平台差异条款」，用户说明投放平台时叠加执行。
审核流程（按序执行）
0. 处理模式选择（token 权衡）
（SKILL_DIR = /Users/hanz/.workbuddy/skills/script-review）
本 skill 的省 token 设计：机扫词表 rules.keywords.txt 由 scan.py 本地读取，永不进 LLM 上下文；脚本原文是否进主上下文，由以下模式决定——批量时主 agent 完全不读脚本原文，把约 13k token 挡在主上下文外。
- 脚本 ≤ 4 篇 且 单篇 ≤ 3000 字：主 agent 直接处理（Read 脚本 + 规则，按模板出报告）。不 subagent——避免子 agent 重复读规则增加总 API token。
- 脚本 ≥ 5 篇 或 单篇 > 3000 字：走 subagent 隔离，主 agent 不 Read 任何脚本原文。
- 主 agent 职责：① 拆 brief→需求卡；② 对每篇 spawn 子 agent；③ 把各子 agent 返回的精简报告片段拼成总报告；④ 加系列级备注。主 agent 上下文只收子 agent 的精简返回，不收脚本全文。
- 子 agent 负责单篇全量审核：读该篇脚本 + 规则 + 需求卡 + 调 scan.py，输出该篇标准报告。
- 子 agent prompt 模板（每个 subagent 处理 1 篇；超长脚本可 1 个处理 2-3 篇）：
> 你是脚本审核执行者。严格按下列文件与步骤，产出【单篇脚本】的审核报告，不要读其他脚本。
> 必读：<SKILL_DIR>/references/rules.md、<SKILL_DIR>/references/product-names.md（核心必读，除非脚本出现表外产品名否则勿读全系表）、本篇脚本<脚本文件路径>、需求卡<需求卡路径>（若无跳过业务层、主旨判「待确认」）。
> 机扫：运行python3 <SKILL_DIR>/scripts/scan.py --file <脚本文件路径>（脚本自行读词表，不要把 rules.keywords.txt 读入你的上下文）。
> 输出：严格按 SKILL.md 第 5 步模板，只输出本篇报告（主旨贴合 + 审核发现，每条含【段落】+原句+问题+替换建议），不输出多余解释。
⚠️ 权衡：subagent 模式让子 agent 重复读规则层，总 API token 略增（≈ 子 agent 数 × 规则层 ~7k）；其价值是主上下文瘦身——多篇原文不进主上下文，避免长对话截断、提升主 agent 拼装质量。少篇场景勿用。
1. 获取脚本全文
- 腾讯文档链接：
docs.qq.com走 tencent-docs 技能；saas.docs.qq.com走 tencent-saas-docs 技能的manage.get_content（file_id 从链接或用户消息中取）。用户原文档只读，严禁回写。 - 粘贴文本/本地文件：直接读取。
- 多篇脚本：逐篇独立审核、独立出报告（批量时见第 0 步选模式）。
- 用户说明了投放平台的记下，用于平台差异条款叠加；未说明则按通用层审核，不强制询问。
2. 获取项目需求卡
> 📌 优先原则：只要有 brief，先拆需求卡再审核。 无论用户先给脚本还是先给 brief，只要对话中存在项目 brief（链接/文本/文件），都优先将其拆解为需求卡后再进入审核，绝不在缺需求卡状态下直接出业务层报告。无 brief 且无已填需求卡时，才走"业务层全标 ❓"兜底。
按以下优先级：
1. 用户已填需求卡 → 直接使用；
2. 用户提供项目 brief（链接/文本/文件）→ 智能预填：brief 明确写到的直接填；推断的填入并标【推断】；brief 没有的留"待补充"，绝不编造（尤其功能点事实清单）。预填稿发用户确认后才用于审核。模板与规则见 assets/project-brief.md；
3. 两者都无 → 固定层照常审核，业务层（主旨/场景/种草次数位置/功能事实）全部标 ❓ 并说明"需求卡缺失"。
3. 机械扫描（兜底）
python3 scripts/scan.py --text "<脚本全文>"
# 或脚本存为临时文件后 --file 传入
- 产品名错误命中 → 原则上 🔴 必改；
- 违禁词命中 → 逐条语境复核：区分产品宣称（🔴/🟡）与剧情梗/过渡语/人物描述（🟡低风险或放过），不一刀切；分类带平台前缀（如"抖音-直播口播"）的条款仅该平台适用，其余平台命中降级或不报；
- 扫描未命中 ≠ 通过，继续第 4 步。
4. AI 逐层审核
> 批量/subagent 模式下，本步固定层与业务层由 subagent 在单篇内执行，主 agent 不读脚本原文、只汇总子 agent 返回。少篇直接处理模式下本步由主 agent 执行。
固定层：
1. 按 references/rules.md 的 Checklist 逐项过（品类红线 → 导流 → 极限词 → 功效宣称 → 权威背书 → 拉踩 → 情绪内容 → 平台差异 → 全文范围：标题/封面大字/正文/口播字幕/评论区预埋/发布文案）；
2. 变体词补查：谐音、拼音、符号拆分（机扫无法识别）；
3. 产品名核对：对照 references/product-names.md（核心必读）；若脚本出现本表之外的腾讯产品名，再按需读 references/product-names-full.md（全系 50+ 产品，默认不加载）。大小写敏感，含"同一脚本内产品名写法不一致"；
4. 拼写/语病/逻辑：错别字、语句杂糅、标点错误、前后称谓不一、时间线矛盾。
业务层（需需求卡）：
5. 主旨/场景/调性契合度；
6. 必带表述是否原样出现、禁用表述是否出现；
7. 种草结构：产品名口播提及次数与位置（画面露出不计入）、植入点、发布文案话题；
8. 功能点事实：脚本所有功能描述逐条对照需求卡「功能点事实清单」——清单外的功能写了即 🔴；口径不一致 🟡 并给出官方口径。
5. 输出审核报告
从简结构，每篇只保留两层（不再出结论总览）：
# 审核报告｜<脚本名>
- 审核时间 / 依据（规则库版本 + 需求卡有无 + 平台差异条款是否叠加）
## 1. 是否贴合传播主旨
一句话结论（贴合 / 部分偏题 / 偏题 / 待确认）+ 依据（引用脚本对应段落，说明是否围绕主旨、场景与调性是否对味）。无需求卡时统一判「待确认（需求卡缺失）」，不凭空编造主旨。
## 2. 审核发现
🔴 必改（不改不能发）
- [位置] 原文「xxx」→ 问题（规则依据）→ 替换建议「xxx」
🟡 建议（有概率被限流或影响专业性）
- [位置] 原文「xxx」→ 风险点 → 建议「xxx」/ 删除
❓ 存疑（AI 拿不准，用户拍板）
- [位置] 原文「xxx」→ 存疑原因 → 需确认方向（不要只写"待确认"）
> 某级别无问题则写"无"。
- 每条发现四要素：原文引用 + 问题定性 + 规则依据 + 替换建议（产品名错误给正确写法、违禁词给可用替代、功能事实给官方口径、缺需求卡给补卡方向），不给空话。
- 经验性规则命中注明【经验】；数据/事实无法核实写"待核实"，不写 0、不臆造。
- 长脚本/多脚本批量审核时，报告写入工作区
outputs/审核报告-<脚本名>-<日期>.md并用 present_files 交付；单篇短脚本可直接在对话输出。
6. 迭代（每次审核后执行）
- 发现表外产品名错误写法 → 补入 references/product-names.md（核心表）；若属全系其他 BG 产品，同步补入 references/product-names-full.md（附日期）；
- 规则误判/漏判 → 修订 rules.md 与 rules.keywords.txt（两者同步改），在 rules.md 更新记录中注明；
- 用户确认的产品官方名称/功能口径 → 立即回写对照表或需求卡；
- 实战中积累的某平台独有规则 → 补入 rules.md 第四节平台差异条款 + 词表加平台前缀分类。
边界
- 用户原始脚本/表格只读，产出报告一律为新文件；
- 涉对外口径的结论拿不准就标 ❓，不替用户下判断；
- 规则库分【官方】与【经验】两层，报告中须区分，经验性规则可被用户实战反馈修订。
