AI 内容审核与 Brief 对齐工作流
我把反复对照 Brief 与达人脚本的人工初审，做成了一条可复核、可批量交付的 AI 内容审核工作流。
AI Script Reviewer 面向达人内容合作团队，统一处理品牌要求、产品事实与创作者脚本，辅助检查卖点遗漏、参数错误、品牌表达和内容风险，并把最终判断留给审核人员。
它不是自动审批系统，也不是一个 Prompt 包装页。产品价值来自围绕模型建立的文件解析、Project Context、方向隔离、失败恢复、结构化结果与人工确认工作流。
- 3 / 3
- Brief 解析成功一次真实验收样本
- 94.4%
- Project Context 字符缩减111,103 → 6,220，仅代表该样本
- 90.8%
- Review Prompt 字符缩减估算旧路径对比，仅代表该样本
- 2 / 2
- 批量审核完成一次真实验收样本，成功 2、失败 0
为什么存在
难点不是读完一份脚本，而是持续做对同一套比较。
达人内容合作进入脚本交付后，运营需要把品牌 Brief、产品资料和创作者脚本放在一起，逐项检查必带卖点、产品参数、品牌表述与风险表达。难点不在读完一份脚本，而在多份内容中反复执行同一套比较，同时维持审核标准和反馈质量。
核心用户
达人 / 内容运营
品牌 Campaign 执行人员
需要汇总多份脚本反馈的项目负责人
最初的产品机会是减少卖点与参数的重复对照；真实文件和批量任务随后暴露出更重要的问题：文档格式不同、一个项目有多种资料角色、内容方向互斥、单批结果需要独立状态，而 AI 输出也会发生格式错误与截断。
原始人工审核流程
从逐份重建上下文，到结构化第一轮审核。
审核人员先阅读 Brief 并提取卖点与参数，再逐行阅读脚本，检查遗漏、冲突和无依据表达，写出具体修改意见，最后由人决定是否可以返回或通过。历史上的具体收件渠道、周转时长和审核量没有可靠记录。
人工逐份重建审核上下文
- 接收品牌 Brief
- 提取卖点与参数
- 逐行阅读达人脚本
- 对照事实与表达风险
- 手写修改意见
- 人工决定是否通过
结构化 AI 初审与人工决策
- 上传 Project Files
- 多格式解析
- 生成 Project Context
- AI First Review
- 结构化 Findings
- Excel 交付
- Human Decision
问题发现
文件、上下文、内容方向与模型输出，都会改变审核质量。
- 01
业务文件天然不统一
Brief 与脚本会以 PDF、DOCX、XLSX、TXT 或 Markdown 出现；分镜 Excel 还包含画面、口播、对白、字幕、时间与备注等列。
- 02
一个项目不只一份 Brief
Campaign Brief、Fact Source、Media Source 与 General Reference 的责任不同，不能把每份文档都变成强制脚本要求。
- 03
互斥内容方向会制造误判
金融、娱乐或社会热点等方向可能共享一个项目；若不隔离范围，系统会把其他方向的要求错误标记为缺失。
- 04
AI 输出本身也需要治理
非标准 JSON、Markdown fence、额外文字和真正截断都可能发生，可靠产品必须暴露、诊断并恢复这些失败。
为什么是工作流
产品价值不只来自模型，而来自模型周围的控制层。
通用对话可以生成一次回答，却不能独立提供可重复的文件处理、文档角色、项目上下文、批量进度、失败隔离、结构化输出、Excel 交付与诊断状态。
- 01接收 Project Files
上传多个 Brief 与单份、多文件或汇总表脚本。
- 02解析并分类
按格式提取内容，并区分 Campaign、事实、媒体与一般参考。
- 03建立 Project Context
把一组 Brief 合并为可复用、可追踪的项目知识。
- 04方向感知初审
选择相关内容方向，检查卖点、事实、品牌表达与风险。
- 05结构化结果与状态
保存结论、证据、建议、解析状态、AI 状态与原始响应。
- 06人工决策与交付
审核人员处理不确定项，并通过 Excel 返回项目结果。
核心产品决策
先定义业务对象、责任与失败路径，再决定如何调用 AI。
我没有把通用聊天界面当作完整产品，也没有让 AI 自动批准脚本。产品先控制文件输入、项目上下文、方向范围、输出结构与失败状态，再让 AI 执行第一轮理解和比较，最终业务判断始终由人完成。
为什么建立 Project Context？
- 背景
- 业务对象是一个项目，而不是一份孤立文档；多个来源需要共同定义要求、事实和可选素材。
- 决策
- 先按角色合并项目资料，再让一组脚本复用同一上下文。
- 取舍
- 需要维护来源、角色和上下文缓存，也必须防止合并过程丢失事实关系。
- 结果
- 项目要求与事实边界更清楚，批量审核无需反复携带全部原文。
为什么每组 Brief 只合并一次？
- 背景
- 为每份脚本重复发送全部原始资料会浪费上下文并增加截断风险。
- 决策
- 正常路径在 cache miss 时每组 Brief 合并一次，每份脚本各进行一次审核；低置信度方向和真实截断才触发额外调用。
- 取舍
- 内存缓存重启后会丢失，且合并质量必须可诊断。
- 结果
- 一次真实样本的 Project Context 从 111,103 字符缩减到 6,220 字符。
为什么区分文档角色？
- 背景
- Campaign Brief 定义要求，Fact Source 验证事实，Media Source 默认提供可选素材；三者不能共享同一强制性。
- 决策
- 为每份文件标注文档角色，并在 Project Context 中保留其业务责任。
- 取舍
- 自动识别不是完美分类，必要时仍需人工检查。
- 结果
- 事实资料不会被错误转成必带卖点，可选素材也不会无条件影响评分。
为什么做 Direction-Aware Review？
- 背景
- 同一项目可能有互斥内容方向，统一对照会制造大量无关缺失项。
- 决策
- 先识别当前脚本方向，只选择相关要求；置信度不足时进入人工确认。
- 取舍
- 审核前多了一层方向判断，也不能宣称分类永远正确。
- 结果
- 审核范围更贴近脚本实际任务，无关方向明确标记为不适用。
为什么坚持 Human-in-the-loop？
- 背景
- 上传材料可能不完整，扫描 PDF 可能损坏参数，模型也会超时或返回异常结构。
- 决策
- AI 提供第一轮比较、风险与建议；系统呈现证据和失败状态；人负责关键事实与最终批准。
- 取舍
- 产品不会实现无人值守自动审批。
- 结果
- 不确定性被显式交给审核者，而不是被伪装成确定结论。
产品演进
每一次升级，都来自上一阶段暴露出的真实工作流问题。
- Stage 1
单脚本初审
- 真实问题
- 运营需要反复把一份达人脚本与一份品牌 Brief 做人工对照。
- 产品决策
- 先把卖点覆盖、参数一致性和修改建议做成独立初审模块，不改动原有达人数据产品。
- 新能力
- 单文件上传、DeepSeek 初审、结构化问题与原始响应诊断。
- 结果
- 最早可验证版本在 2026 年 6 月形成可用的单脚本审核助手。
- Stage 2
内容质量与合规扩展
- 真实问题
- 只检查卖点和参数，无法覆盖品牌术语、文本质量和不受支持的表达。
- 产品决策
- 扩展同一审核契约，而不是增加一套割裂的检查系统。
- 新能力
- 错别字、标点、命名一致性、禁用表达、绝对化与无依据宣称检查。
- 结果
- 审核范围从事实核对扩展为内容质量与风险初审。
- Stage 3
批量审核工作流
- 真实问题
- 真实项目包含多位创作者，单份处理无法支持项目级交付。
- 产品决策
- 建立异步批量任务，并让每份脚本保留独立状态与结果。
- 新能力
- 批量进度、成功失败统计、独立结果与 Excel 导出。
- 结果
- 审核从一次模型调用升级为有进度、有状态、可交付的批量任务。
- Stage 4
真实文件理解
- 真实问题
- 业务文件并不是统一文本，真实脚本常是一人一份的分镜 Excel，Brief 也可能来自多种办公文档。
- 产品决策
- 接受现有文件现实，不要求运营先把资料手工转换成统一模板。
- 新能力
- PDF、DOCX、XLSX、TXT、Markdown 解析，以及分镜表头与顶部元信息识别。
- 结果
- V1.5.2 成为最新已提交稳定版本，并支持多文件脚本与失败隔离。
- Stage 5
Project Context
- 真实问题
- 一个项目可能包含 Campaign Brief、事实资料和媒体素材，重复把全部原文发送给每份脚本既浪费上下文，也会混淆文档责任。
- 产品决策
- 先按角色解析并合并为一次可复用的 Project Context，再进入逐脚本审核。
- 新能力
- 多 Brief、文档角色、Project Context、来源追踪与内存缓存。
- 结果
- 一次真实验收中，3 份文档从 111,103 字符整理为 6,220 字符的项目上下文。
- Stage 6
Direction-Aware Review
- 真实问题
- 同一 Campaign 可能包含互斥内容方向，混用要求会制造错误缺失项。
- 产品决策
- 先识别脚本方向，只选择相关要求；置信度不足时交由人工确认。
- 新能力
- 本地方向识别、低置信度 AI fallback、无关方向 notApplicable 与统一审核核心。
- 结果
- 当前本地 V1.6.1 验收在一个真实样本中以 0.99 置信度识别目标方向。
- Stage 7
可靠性与恢复
- 真实问题
- 模型可能返回 Markdown fence、额外文本、尾逗号、格式错误或真正截断的 JSON。
- 产品决策
- 区分可修复格式与真实截断，保留原始响应，并让失败显式进入人工复核。
- 新能力
- JSON 候选提取、结构完整性检查、truncated_json 识别、一次 compact retry 与诊断状态。
- 结果
- AI 失败不再被包装成正常结论，也不会拖垮其他可用文件。
Project Context System
业务对象是项目，而不是一份孤立文档。
多份资料先按业务角色进入同一个项目上下文，再被多份脚本复用。它既降低重复上下文，也避免把事实资料或可选媒体误当成强制要求。
- 01Multiple Documents
接收同一项目中的 Campaign、事实、媒体与参考文件。
- 02Role Classification
区分哪些内容定义要求、提供事实、补充素材或只作参考。
- 03Project Context
每组 Brief 在 cache miss 时合并一次，保留来源与角色。
- 04Reusable Review Knowledge
多份脚本复用同一项目上下文，避免反复发送全部原文。
- 3 / 3
- Brief 解析成功一次真实验收样本
- 94.4%
- Project Context 字符缩减111,103 → 6,220，仅代表该样本
- 90.8%
- Review Prompt 字符缩减估算旧路径对比，仅代表该样本
证据边界
111,103 → 6,220 字符与 94.4% 缩减来自一次包含 3 份 DOCX 的真实验收，不代表所有项目平均值。
正常路径是每组 Brief 在 cache miss 时合并一次、每份脚本审核一次；低置信度方向或真正截断时才会产生额外 AI 调用。
当前 Project Context cache 仅在内存中保留，服务重启后不会持久化。
Direction-Aware Review
只审核当前脚本真正承担的内容方向。
- 01Project Context
保留项目级要求、事实、素材和互斥内容方向。
- 02Direction Detection
先用本地规则识别，置信度不足时才调用 AI fallback。
- 03Relevant Requirements
只选取当前脚本方向的要求，其他方向标记为不适用。
- 04Direction-Aware Review
使用统一审核核心生成结构化初审结果。
- 05Human Confirmation
方向不确定、事实关键或输出异常时，由审核人员确认。
当前实现不会宣称方向分类永远正确。置信度不足时，系统要求人工确认，而不是用无关方向制造错误结论。
Reliability Engineering
可靠 AI 产品必须处理失败，而不只展示生成结果。
- 01
文件失败隔离
单个 Brief 或脚本解析失败时保留错误状态；只要仍有可用 Brief，其他文件可以继续处理。
- 02
解析与 AI 状态分离
parsed、parse_failed、ai_success、ai_format_error 与 ai_failed 分开记录，避免把模型故障误诊为源文件问题。
- 03
JSON 恢复与截断识别
移除 fence、提取平衡对象并修复尾逗号；真正未闭合的 JSON 标记为 truncated_json，不把残缺内容当完整知识。
- 04
受控重试与诊断
Project Context 真正截断时只进行一次 compact retry；异常时保留原始响应，为人工复核和后续诊断提供依据。
可见状态
parsed / parse_failed
ai_success / ai_format_error / ai_failed
invalid_json / truncated_json
原始响应、失败文件与诊断信息保留给人工复核
架构
技术被放在业务故事之后，但每一层都承担明确责任。
输入与解析
接受业务已经在使用的办公文件，并为分镜 Excel 保留顶部信息与内容列。
PDF / DOCX / XLSX / TXT / Markdown
Storyboard-aware Excel parsing
Per-file parse status
项目上下文
先建立项目级知识，区分要求、事实、媒体与参考，再复用于单份和批量脚本。
Document role classification
DeepSeek merge with local fallback
In-memory context cache
审核核心
单文件与批量任务共用方向感知的审核核心，避免规则、模型参数和结果结构漂移。
Direction detection
DeepSeek structured review
Deterministic checks
Shared output schema
可靠性与交付
把解析失败、模型失败和格式异常变成可见状态，并保留人工接管与业务交付路径。
JSON normalization / compact retry
Batch progress / failure isolation
Diagnostics / ExcelJS export
产品证据与验证结果
界面证据与实现边界分开呈现。
现有 3 张公开截图使用虚构文件，展示最新已提交 V1.5.2 的单文件入口、批量输入与完成状态。V1.6.1 的 Project Context、方向感知与恢复能力依据当前本地代码和保存的真实验收记录说明，不用旧截图伪装为新版本界面。
每份脚本重复携带全部原始 Brief
每组 Brief 建立一次可复用 Project Context
所有文档与内容方向被平铺对照
按文档角色与当前方向选择相关审核依据
模型格式异常容易被当作审核失败或静默丢失
解析、AI 与截断状态分离，并保留原始诊断和人工复核
支持五类 Brief 文件扩展名与五类脚本文件扩展名，并兼容一人一文件和汇总 Excel 两种批量输入。
一次真实验收完成 3/3 Brief 解析、真实 DeepSeek 合并与审核，以及 2/2 批量处理。
一次真实样本将 111,103 字符原始 Brief 整理为 6,220 字符 Project Context；该 94.4% 只代表该样本。
审核结果保留来源、方向、置信度、解析 / AI 状态、问题证据、建议与 Excel 交付字段。
Human-in-the-loop
AI 做初审，系统组织证据，人做最终批准。
系统只知道上传的材料，而 Brief 可能不完整、方向可能含糊、扫描件可能损坏关键参数，模型也可能失败。因此产品暴露不确定性，而不是自动批准或拒绝。
执行第一轮理解与比较
- 整理多文档项目知识
- 辅助识别内容方向
- 比较卖点、参数与事实
- 发现表达风险
- 生成结构化修改建议
约束输入、状态与证据
- 解析文件与分镜表
- 区分文档角色
- 隔离失败文件
- 标准化输出状态
- 汇总结果并导出 Excel
承担最终业务判断
- 提供可读源文件
- 确认模糊方向
- 核验关键参数
- 处理模型异常
- 决定脚本是否可以返回或发布
限制与反思
不把本地验证写成生产发布，也不把未知指标包装成成果。
当前限制
最新已提交 Script Reviewer 版本是 V1.5.2；V1.6.1 是当前本地验证实现，尚未确认正式发布或部署。
扫描件 / 纯图片 PDF 尚未自动 OCR；关键参数仍需要可读源文件和人工核验。
超长文件在进入模型前存在截断上限，DeepSeek 仍可能超时、失败或返回异常结构。
Project Context 缓存与批量任务当前保存在内存中，服务重启后不会持久保留。
目前没有可公开验证的活跃用户、平均审核耗时、准确率、节省工时、成本或收入数据。
最终脚本批准、模糊方向和关键事实判断始终由人负责。