AI 活动草稿怎么交接：材料齐全，不等于审批通过

AI 营销草稿的结构化审核交接，需要交出什么？

营销负责人收到 AI 写好的促销文案，需要知道它用了哪版需求简报、每项促销主张有什么依据，以及哪些问题还没有确认。把这些信息和指定版本的草稿一起交出，才能检查内容。字段填齐，并不说明优惠写对了。

Google 的结构化输出文档介绍了如何让 Gemini 模型的回复遵循指定的 JSON Schema，也就是描述数据结构的规格。所供页面标注 Gemini Generate Content API (Legacy)。这里用它解释格式与内容的区别，不把它作为已核实的现行 API 实现教程。

文档指出，JSON 语法正确并不保证字段值在语义上正确，应用程序应验证最终输出。它还提醒，符合结构规格的输出，也可能不满足业务要求。折扣可以写在正确的字段里，数值却仍然写错。

下面建议把格式检查、主张核实、业务要求核对和有权限审阅者的决定分开记录。这是一种建议做法，不是 MIA 已有的集成。

在 AI 营销工作流里，把 D3 与 B7 放在一起检查

用一个虚构情境说明：两人营销团队中，文案同事起草，获授权的营销负责人审核。需求简报 B7 批准的是 11 月 1 至 7 日，优惠 10%，AI 草稿 D3 却写成 “全月优惠 20%。” 这不是实际客户事件。

最小材料包可以包含以下字段和值。这是数据示例，不是 Gemini schema 或 API 请求。

字段	示例值
draft_version	D3
brief_version	B7
copy	全月优惠 20%。
claim_register.claim_id	C1
claim_register.quoted_claim	全月优惠 20%。
claim_register.proposed_source_reference	B7 — 促销条款
business_requirements	优惠比例和日期必须与 B7 一致
unresolved_questions	20% 有什么依据？哪份材料授权了全月优惠？

建议引用 B7，不代表 B7 已经支持这句话。B7 和 D3 只是指向材料的编号，审阅者必须打开准确版本，读到实际条款和文案。真正交接时，要附上可打开的文件位置及相关原文，不能用编号代替证据访问。

假设应用程序检查必填字段及数据类型，在这个虚构例子中记录 shape_check: pass。另一笔对照检查则记录 business_fact_check: mismatch：优惠比例和活动期间都与 B7 冲突。格式通过不能覆盖这项差异，更不能变成“已批准”。

用主张与来源对应表交接修订

“请核对优惠”没有告诉文案同事具体改哪里。下面的小型检查表把主张、来源、差异和下一步负责人连起来。

检查项	主张与来源	差异	下一步责任动作
优惠比例	D3 C1：20%；B7：10%	无依据地提高优惠	文案同事按 B7 修正比例
活动日期	D3 C1：全月；B7：11 月 1 至 7 日	无依据地延长期间	文案同事改为批准的日期
证据可访问性	准确版本的 D3 和 B7	任一文件打不开，核实仍待确认	营销负责人取得正确文件后再决定

事实核实与业务要求核对应分别可辨，即使它们用到同一次比对。读 B7 是确认促销条款；检查业务要求，则是判断 D3 是否遵守本次活动指示。在其他活动中，一句话可能有来源支持，但并不在本次批准使用的范围内。

负责人将两项差异附在 D3 上，退回修改，记录审阅者与版本。这笔退回决定属于 D3。

D4 要重新检查，不能继承旧决定

文案同事把 D4 改为 “11 月 1 至 7 日，优惠 10%。” 审阅者打开 D4 与 B7，检查修正内容，再为 D4 记录新决定。D3 的决定不能复制给 D4。修正后的句子是重新审核的对象，不是已经批准的证明。

团队讨论人工检查点放在哪里时，可以参考 MIA 的 Cowork 工作流设计：页面描述了可查的输入、产出和交接，以及等待人审阅、修改或批准的关卡。它说明的是设计；具体访问权限、保留期和部署控制仍要逐项确认。这不代表已有 Gemini 集成，也不证明已经实现本文的材料包。

先拿一项活动主张试用：附上准确版本的需求简报和草稿，分别记录每项检查确认了什么，再把修改交给明确的负责人。材料包应让人能依据原文作决定，而不是把填齐字段变成发布许可。