這一課會完成什麼
- 分清楚單一 AI 任務、固定自動化與完整營運流程的差別。
- 找出流程裡真正造成等待、重工、風險或資訊遺失的節點。
- 選出一個能在 30 天內觀察成果，又保留人工控制的第一個介入範圍。
開始前先準備
- • 一條可以從觸發到結果完整觀察的行銷流程。
- • 至少一次近期執行紀錄，包含等待、退件與例外。
先把定義說清楚
AI 原生行銷基礎
AI 原生行銷是一種營運設計：研究、決策、製作、發布與衡量共用同一組結構化脈絡，系統記得每次輸出、審核與退件原因，人則在品牌、預算、個資與對外承諾等高風險位置保留決定權。判斷標準不在採用多少模型或工具，而在團隊能否看見狀態、追查決策、手動接管並用真實回饋改善流程。
多數團隊最先自動化的是生成文字，因為畫面上立刻看得到結果。實際吞掉時間的部分往往在前後兩端：需求不完整、素材找不到、審核標準沒有寫下來、發布權限散在個人帳號，或成效資料沒有回到下一次 brief。只把草稿變快，可能讓審核佇列塞得更嚴重。
工作流程地圖迫使團隊回答誰負責、系統記什麼、哪個事件代表完成、遇到例外怎麼走。這些答案一旦缺席，模型表現再好也只能靠某個人盯著。這類系統無法擴張，新工具仍被舊習慣牽著走。
第一個介入範圍應該小到可以回復，也要大到能改變一個營運指標。例如縮短研究 brief 從提出到核准的週期，比『讓大家多用 AI』更容易驗證。指標同時要記品質、採用、成本與退件，否則輸出變多會被誤當成流程變好。
現場情境
Northstar Cloud 每週內容 brief 流程
教學用合成案例。品牌、角色、數字與事件均為練習資料，不代表 Tenten 客戶或公開公司實績。
- 負責人
- 行銷營運主管，負責讓研究、內容、法務與發布團隊共用同一個 brief 狀態。
- 要做的決策
- 把第一階段限定在『核准研究資料後，自動建立結構化 brief 並送交編輯』；研究來源核准、法務檢查與發布仍由人負責。
- 目前狀態
- Northstar Cloud 每週要核准 4 份內容 brief。需求從 Slack 提出，研究員把來源貼進 Google Docs，編輯在文件留言，法務只在發布前收到連結。最近一次執行花了 9 個工作天，其中 4 天是等待補資料；兩份 brief 因來源日期不明被退回。
- 預期成果
- 試行結束時，團隊能比較介入前後的核准週期、補件次數、退件原因、人工分鐘數與每份 brief 的執行成本，並能在任何一步切回原本的手動流程。
限制條件
- • 30 天試行期內不得讓系統自行發布、改預算或對外寄信。
- • 現有 Google Drive 與 Slack 必須保留，團隊沒有資源同時更換系統。
- • 客戶訪談逐字稿含個資，只能存放在既有受控資料夾。
- • 每份 brief 必須留下來源、審核者、退件原因與最終核准時間。
實作範例
把 9 天流程縮成可觀察的 6 個狀態
證據類型: 具名模擬情境團隊暫時不談模型，先把最近一份 brief 的事件依時間排開：需求提出、資料待補、來源已核准、brief 產生、編輯退件、法務核准、排程發布。圖上很快出現兩個問題。第一，『研究中』同時代表還沒找到資料、等待需求者回答，以及正在核對來源，三種狀況沒有共同時限。第二，編輯只看到完成稿，看不到模型用了哪些來源，也看不到哪些欄位是推論。
Northstar Cloud 將狀態改成 intake、evidence-needed、evidence-approved、brief-review、legal-review、scheduled，並為每個轉換指定負責人與最低證據。模型只能讀取 evidence-approved 的資料，輸出固定欄位；缺少 target audience、primary claim 或 source date 時直接回到 evidence-needed。編輯退件必須選一個原因碼並可補文字，法務核准前不會建立發布任務。
練習資料的完成版 charter 暫不承諾週期一定縮短，先建立可比較的基準。第 1 週記錄 4 份既有流程，第 2–4 週跑受限版本。每週檢查中位核准時間、資料補件率、退件分布、人工審核分鐘數與失敗後手動接管時間。只有品質門檻不下降，週期與人工時間也改善，才討論擴大自動化。
主張限制
此例是合成流程，9 天、4 份 brief 與各狀態都是教材設定，不能拿來預估其他團隊的效益。它也沒有處理跨國法規、媒體採購或多品牌權限。實作時必須用自己的事件紀錄重畫地圖；若拿不到現況資料，先把觀察期拉長，不要填一個看起來合理的基準。
做法
照著做，每一步都有檢查點
現場情境
把第一階段限定在『核准研究資料後，自動建立結構化 brief 並送交編輯』；研究來源核准、法務檢查與發布仍由人負責。
- 01從一筆真實紀錄重建現況
- 02把結果改寫成可觀察指標
- 03框出第一個可逆介入
驗收條件
完成品應讓沒參加會議的人看懂流程如何開始、在哪裡等待、誰能做決定、系統會寫入什麼、什麼情況必須停，以及 30 天後用哪些資料判斷是否繼續。它不需要漂亮，但不能靠口頭補充才能運作。
- 01
從一筆真實紀錄重建現況
按時間列出每個事件，不要只寫標準作業程序。把等待、補件、退件、重複輸入與個人帳號操作標出來；每個節點都寫下輸入、輸出、負責人及使用系統。
檢查點 · 執行者能在圖上找到最近一次例外，而且流程總時間等於工作時間加等待時間。
- 02
把結果改寫成可觀察指標
選一個品質指標、一個週期指標與完整成本。成本要包含模型、工具、人工審核、重工與復原，不只算 token；品質指標必須有不准下降的門檻。
檢查點 · 每個指標都有資料來源、計算方式、基準期間與負責人，沒有『提升效率』這類無法驗證的字眼。
- 03
框出第一個可逆介入
把每一步標成固定規則、需要判讀、人工決定或外部副作用。固定規則留給程式；需要判讀的受限步驟才考慮模型。對外發布、預算、個資或難以復原的寫入保留人工核准。
檢查點 · 介入範圍有清楚起訖，禁止動作與人工核准點都能在流程圖上找到。
- 04
寫出停止與手動接管
指定誰可以暫停、什麼證據會觸發暫停、已完成的工作如何辨識，以及團隊怎麼沿用原流程完成當次任務。用一次假想 API 中斷或錯誤退件演練接管。
檢查點 · 未參與設計的人能照步驟在 15 分鐘內說明目前狀態、停止新的執行並找到待處理項目。
- 05
排出 30 天比較計畫
先收基準，再用小批量試行。每週比較品質、週期、採用、人工時間、成本與錯誤嚴重度；預先寫下繼續、修改、停止三種決策需要的證據。
檢查點 · 計畫包含基準週、試行量、每週檢查人、資料來源，以及一個不因輸出量增加就自動判定成功的規則。
動手實作
完成一頁式工作流程 charter
用 Northstar Cloud 範例理解欄位，再替自己的重複行銷流程填一份 charter。
準備項目
- • 準備最近一次完整執行紀錄，包含開始、交接、等待、退件、例外與結束時間。
- • 邀請至少一位實際執行者核對流程；主管記得的流程通常比現場乾淨。
- • 先複製 starter kit，保留空白欄位，不要用理想流程覆蓋現況。
本課產出
一份現況流程圖、一頁式 charter、RACI、基準表、第一個介入範圍、停止條件與 30 天測試計畫。
起始模板: AI 行銷工作流程 charter 範本
Markdown# Workflow charter
流程名稱：
觸發事件：
流程負責人：
使用者與受影響對象：
目前結果：
基準期間：
品質指標：
週期指標：
完整成本：
## Current states
| State | Entry evidence | Owner | Exit rule | Wait/exception |
| --- | --- | --- | --- | --- |
## First intervention
介入起點：
介入終點：
模型可做：
系統可寫入：
必須人工核准：
禁止動作：
## Stop and recovery
暫停條件：
暫停負責人：
手動接管步驟：
回復資料來源：
## 30-day test
基準：
目標：
品質門檻：
採用門檻：
成本上限：
每週檢查時間：預期結果
完成品應讓沒參加會議的人看懂流程如何開始、在哪裡等待、誰能做決定、系統會寫入什麼、什麼情況必須停，以及 30 天後用哪些資料判斷是否繼續。它不需要漂亮，但不能靠口頭補充才能運作。
留給下一課
保留 charter 與狀態名稱。第 2、6、7、8 堂會沿用同一流程，分別加入內容狀態、自動化、人工核准與評估資料。
驗收條件
- 01現況圖至少包含一個真實等待、一個退件或例外，以及其負責人。
- 02介入範圍只有一個明確起點與終點，並列出允許、核准與禁止動作。
- 03品質、週期、採用與完整成本都有基準、資料來源及計算方式。
- 04停止條件、暫停負責人、手動接管與資料回復步驟能由另一位同事照表演練。
常見故障
故障診間
F1流程圖很整齊，但執行者說實際工作不是這樣走。
- 先檢查
- 抽一筆最近完成與一筆退件紀錄，逐一對照時間戳、留言、檔案與系統寫入。
- 可能原因
- 地圖是照 SOP 或主管印象畫的，等待與例外被省略。
- 修復方式
- 以事件紀錄重畫，將例外路徑留在主圖旁，未確認的節點標為待查。
- 下次怎麼避免
- 每季抽樣一筆正常與一筆異常執行，讓實際執行者簽核流程圖。
F2試行輸出變多，核准時間卻更長。
- 先檢查
- 比較各狀態的等待時間、退件原因與審核者每日待辦量。
- 可能原因
- 只加速生成，沒有改善輸入品質、審核標準或發布容量。
- 修復方式
- 降低試行量，補齊 evidence-ready 門檻與退件原因碼，再處理最大的等待節點。
- 下次怎麼避免
- 把審核佇列、退件率與人工分鐘數列為擴大量能前的必要門檻。
F3系統失敗時，沒有人敢暫停，也不知道哪些項目已經處理。
- 先檢查
- 查看是否有流程負責人、執行 ID、狀態紀錄、停止權限與手動清單。
- 可能原因
- charter 只寫正常路徑，沒有分配事故責任與回復來源。
- 修復方式
- 補上暫停責任、執行狀態、人工接管與重播規則，並做一次桌上演練。
- 下次怎麼避免
- 每次擴大權限或新增工具前，先重跑停止與接管演練。
展示版之後
正式上線前的邊界
- 01每次執行都有唯一 ID、輸入版本、模型或規則版本、狀態、審核者與最終結果。
- 02服務帳號只拿到介入範圍需要的權限；發布、預算與個資存取另設人工或系統控制。
- 03提示、資料 schema、路由、審核規則與停止條件都納入版本管理。
- 04監測品質、等待、退件、人工接管、重試、完整成本與採用，不用輸出量代替成效。
- 05保留原本手動流程與必要表單，試行期間能在單次任務中途切回人工。
- 06訂出資料保留與刪除規則；客戶逐字稿、個資與未公開素材不得流入未核准的模型或 log。
- 07每週由流程負責人檢查一次錯誤分布，重大錯誤轉成後續評估案例。
證據類型
資料來源與主張限制
資料來源只支撐本課標示的主張，不代表換一個系統也會得到相同結果。
- [1]NIST AI Risk Management FrameworkAI 風險治理、衡量與持續管理框架
NIST · 官方文件 · 2026-08-20
- [2]Improving support with every interaction at OpenAI第一線標註、trace、eval 與知識更新如何形成營運迴圈
OpenAI · 官方文件 · 2026-08-20
- [3]Building effective agents固定工作流程與代理系統的選擇、成本及控制邊界
Anthropic · 已發表研究 · 2026-08-20
- [4]Forward Deployed MarketingTenten 的 FDM 服務邊界與導入方法
Tenten AI · Tenten 實務方法 · 2026-08-20
延伸的 Tenten 資源