AI 活動草稿怎樣交接：資料齊全，不代表已獲批核

AI 行銷草稿的結構化審閱交接，需要交出甚麼？

行銷負責人收到 AI 寫好的優惠文案，要看的不只是那幾句文字。這份稿件用了哪一版 brief？優惠聲明有甚麼依據？哪些問題還未確認？把這些資料連同指定版本的草稿一起交出，才有材料作判斷。欄位填齊，不代表優惠寫對。

Google 的結構化輸出文件說明，可設定 Gemini 模型的回應依照指定的 JSON Schema，也就是規定資料結構的規格。所供頁面標示 Gemini Generate Content API (Legacy)。這裡借用它對格式與內容的區分，不把它當作已核實的現行 API 實作教學。

文件指出，JSON 語法正確不保證欄位值在語意上正確，應由應用程式驗證最終輸出。它亦提醒，即使輸出符合結構規格，也可能不符合業務要求。換成活動文案，就是「折扣」欄位裡有一個數字，不代表那是獲准使用的折扣。

以下建議把格式檢查、聲明核實、業務要求核對，以及獲授權審閱者的決定分開記錄。這不是 MIA 已有的整合功能。

在 AI 行銷工作流程中，把 D3 對照 B7

以下是虛構教學情境，不是客戶個案：兩人行銷團隊中，文案同事起草，獲授權的行銷負責人審閱。Brief 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、D3 都只是識別碼；審閱者仍要打開指定版本，讀取實際條款與文案。真正交接時，應附上可開啟的檔案位置與相關原文，不能只交一串 ID。

假設應用程式檢查必填欄位及資料型別，在這個虛構例子裡記錄 shape_check: pass。對照 B7 的另一筆紀錄則是 business_fact_check: mismatch：折扣與期間都不符。格式通過不能蓋過差異，更不能改寫成「已批核」。

把聲明、來源、差異與負責人放在一起

「請再確認優惠」沒有說清楚要改哪裡。以下小型對照表可用來交接修訂。

檢查項目	聲明與來源	差異	下一步由誰處理
折扣	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 整合，或已實作本文的資料包。

先選一項活動聲明試用：附上指定版本的 brief 和草稿，分別記下各項檢查確認了甚麼，再把修訂交給明確負責的人。資料包應讓人能依據原文作決定，而不是把填齊欄位變成發佈許可。