這一課會完成什麼
- 用價值、可行性、風險、可觀察性與流程負責人承諾，選出一條 30 天導入範圍。
- 把 discovery、sandbox、shadow、canary、production 與 handoff 排成有進退條件的計畫。
- 交付可維運的系統、eval、runbook、責任、完整成本與下一步投資建議。
開始前先準備
- • 完成一份工作流程 charter，以及至少一組可重跑 fixture、評估基準與人工接管程序。
- • 取得業務 sponsor、流程 owner、實際使用者、IT／資料／資安窗口的可排程時間。
先把定義說清楚
FDM 導入專案
Forward Deployed Marketing 是把產品、資料、AI 與行銷營運能力帶進一條真實工作流程，由技術與業務角色在現場共同完成診斷、適配、測試、部署與交接。這類角色有明確結束與交接條件，也會先找用途再決定平台。30 天專案從窄而可驗證的範圍開始，使用真實但受控的資料與事件，先跑 shadow，再小量 canary；每一階段都有品質、風險、採用、成本與停止條件。結束時內部 owner 能照 runbook 操作、暫停、復原與更新評估，才算完成導入。
許多 AI 試點在 demo 當天很亮眼，幾週後沒人使用。原因往往不在模型，而是沒有接進既有身分、資料、審核、例外、值班與衡量。FDM 把現場工作視為產品的一部分：工程師或系統負責人直接觀察使用者如何補資料、退件、繞路與接管，再把這些行為寫回 workflow 與 eval。
導入速度不能靠跳過治理換來。若第 1 週就讓系統對正式名單寄信，團隊還沒看過資料延遲、權限與失敗分布，事故成本會遠高於試行收益。分階段把 sandbox、shadow、canary 與 production 接起來，可以提早發現錯誤，也讓 sponsor 在每個門檻重新決定是否投入。
交接本身就是驗收，最後一場簡報取代不了操作。流程若只能由外部顧問修 prompt、清 dead-letter 或判讀 scorecard，客戶並未真正取得能力。專案一開始就要指定內部 owner 與 backup，讓他們共同建立資料字典、測試、runbook、成本表和變更程序；最後用反向操作證明能獨立維運。
現場情境
Orchid 30 天 FDM 導入
教學用合成案例。企業、流程、工時、比率、成本與導入結果皆為教材設定，不代表 Tenten 客戶成果或保證。
- 負責人
- FDM Lead，與 Orchid 的 Marketing Ops、內容、法務、IT 與資料團隊共同導入 B2B 內容 brief 工作流程。
- 要做的決策
- 把專案分成 5 天 discovery、5 天 sandbox、5 天 shadow、5 天 canary 與 10 天穩定／交接。先處理 4 份已完成內容的去識別 fixture，再 shadow 4 份真實 brief，通過門檻後才讓最多 4 份進 CMS 草稿區；公開發布仍由原流程處理。
- 目前狀態
- Orchid 每月完成 16 份技術內容 brief，中位週期 8.5 個工作天，約 38% 至少退件一次。研究、產品與法務各有自己的文件；一次錯誤發布曾花 6 小時回查來源。公司已做過兩次生成式 AI demo，但沒有流程 owner、基準、eval、服務帳號或正式停止程序。
- 預期成果
- 第 30 天交付已驗證的工作流程、版本化 eval、dashboard、事故與回復 runbook、RACI、完整成本、owner 反向操作紀錄，以及擴大、修正或停止的投資備忘錄。沒有達門檻時，交付診斷與可回復資料，避免硬推上線。
限制條件
- • 30 天只處理 evidence-approved 到 CMS draft，不包含公開發布、廣告預算或 CRM 發送。
- • 第 1 週前不得讓模型讀取受限資料；資料清單與保留規則須由 IT／資安核准。
- • 品質門檻不得低於人工基準，未支持主張、個資外洩與重複草稿屬零容忍。
- • Orchid 必須指派 1 位 owner 與 1 位 backup，每週至少參與一次操作與一次決策檢查。
實作範例
把兩次 demo 改成有退出條件的 30 天部署
證據類型: 具名模擬情境Orchid 原本的成功定義是「30 天內自動產生所有 brief」，沒有品質基準，也沒算編輯審核與 IT 維運。訪談後發現 8.5 天週期裡，模型可能改善的草稿撰寫只占約 7 小時；最大的等待是產品來源未核准與法務不清楚主張出處。如果直接優化生成速度，38% 退件率可能更高。
團隊將範圍前移到 evidence-approved 門檻：來源未核准時不生成，brief 每個 claim 帶 source ID，編輯退件選 reason code。基準包含週期、source support、退件、人工分鐘、完整成本與接管時間。go 條件要求 24 題 eval 的 hard gates 全過、shadow 的 source support 不低於人工基準、沒有重複草稿，owner 能在 20 分鐘內暫停與手動接續。no-go 則保留原流程並輸出根因。
教材結果中，4 份 shadow 有 1 份因來源日期缺失被正確阻擋；其餘 3 份進入人工比較。canary 的 4 份裡，3 份一次核准，1 份因產品說法退回；沒有公開發布或重複草稿。中位週期的方向改善，但樣本不足以證明 8.5 天已穩定下降。owner 完成暫停、查詢 run、手動建稿與恢復演練，投資建議為再觀察一個月，不擴大到 CRM。
主張限制
16 份、8.5 天、38%、6 小時、24 題與各階段天數都是合成資料。30 天可能不足以觀察低頻錯誤、季節性與最終商業結果。FDM 成效取決於資料、流程、權限與內部參與，不能由此例推算 ROI。實際部署需要依產業、法域、供應商合約、資安程序與變更凍結期調整。
做法
照著做，每一步都有檢查點
現場情境
把專案分成 5 天 discovery、5 天 sandbox、5 天 shadow、5 天 canary 與 10 天穩定／交接。先處理 4 份已完成內容的去識別 fixture，再 shadow 4 份真實 brief，通過門檻後才讓最多 4 份進 CMS 草稿區；公開發布仍由原流程處理。
- 01用現場事件完成 discovery
- 02在 sandbox 建資料與失敗證據
- 03用 shadow 比較人工基準
驗收條件
完成品是一份能被 IT、行銷、資安、財務與實際操作者共同核對的部署紀錄。它說清楚為什麼選這條流程、每階段看什麼證據、何時停止、誰能接管、花費怎麼算，以及外部團隊離開後誰負責更新。
- 01
用現場事件完成 discovery
跟著一筆正常與一筆退件流程走，不只訪談主管。記錄資料、等待、例外、個人帳號、人工判斷、外部副作用與完整成本；確認 owner、受影響者及禁止範圍。
檢查點 · 第 5 天 review 能看到現況事件、基準、RACI、資料清單與單一介入範圍；最大瓶頸若不在 AI 可處理處，允許 no-go。
- 02
在 sandbox 建資料與失敗證據
使用去識別 fixture 建 workflow、schema、權限、eval、冪等、成本上限與 dead-letter。測正常、拒答、注入、timeout、重複、資料缺失及核准逾期。
檢查點 · 第 10 天前 hard gates 全過，服務身分無正式副作用權限，owner 能找到任一 run 與失敗原因。
- 03
用 shadow 比較人工基準
在真實工作旁運行，但不寫入正式系統。相同輸入比較事實支持、完整性、退件預測、人工修改、延遲與成本；記錄使用者沒有採用的理由。
檢查點 · 第 15 天 review 有至少一輪真實 shadow、人工差異與未達門檻項目；品質不夠就回 sandbox，不用趕 canary。
- 04
小量 canary 並保留原流程
只開放已核准的最小寫入，穩定分流並設每日上限。每筆仍由人核准，監測品質、重複、等待、成本與接管；觸發門檻立即暫停並沿原流程完成。
檢查點 · 第 20 天前所有 canary 有 run、核准、外部確認與回復紀錄；值班者能在 20 分鐘內停止新執行並列出待處理項目。
- 05
讓 owner 反向操作並做投資決定
由內部 owner 不看提示完成啟動、監測、退件、暫停、手動接管、更新 fixture 與回復；backup 再做一次。以品質、採用、成本、風險與維運負荷決定擴大、修改或停止。
檢查點 · 第 30 天交接有 owner 與 backup 操作紀錄、開放風險、文件位置、權限清單、下一次 review 與具證據的投資備忘錄。
動手實作
完成一份可簽核的 30 天 FDM deployment pack
以 Orchid 的窄範圍為骨架，替自己的流程安排 discovery 到 handoff；若缺少 sponsor 或資料權限，就把 no-go 寫進計畫。
準備項目
- • 確認 sponsor、流程 owner、使用者、IT／資料／資安、法務與財務窗口，沒有負責人就先不排 production。
- • 帶齊 charter、資料清單、至少 24 題 eval、現況基準、服務身分方案與手動流程。
- • 預約第 5、10、15、20、30 天的 go／no-go review，讓決策者預留時間。
本課產出
一份已由 sponsor 與 owner 核對的部署 charter、階段門檻、資料與權限設計、eval 報告、dashboard、runbook、交接證據與投資建議。
起始模板: 30 天 FDM 部署包
Markdown# Deployment charter
Workflow:
Sponsor:
Owner / backup:
Users:
In scope:
Out of scope:
Baseline:
Quality hard gates:
Adoption signal:
Full-cost cap:
Stop authority:
## Phase gates
| Day | Phase | Inputs | Proof required | Go | No-go / recovery | Decision owner |
| --- | --- | --- | --- | --- | --- | --- |
| 1–5 | Discovery | | | | | |
| 6–10 | Sandbox | | | | | |
| 11–15 | Shadow | | | | | |
| 16–20 | Canary | | | | | |
| 21–30 | Stabilize + handoff | | | | | |
## Production boundary
Data classes:
Service identities:
Allowed reads:
Allowed writes:
Human approvals:
Denied actions:
Retention / deletion:
Vendor terms:
## Evidence pack
Workflow version:
Eval version:
Dashboard:
Runbook:
Incident log:
Cost model:
Owner reverse-operation:
Open risks:
Recommendation: expand / modify / stop
Next review:預期結果
完成品是一份能被 IT、行銷、資安、財務與實際操作者共同核對的部署紀錄。它說清楚為什麼選這條流程、每階段看什麼證據、何時停止、誰能接管、花費怎麼算，以及外部團隊離開後誰負責更新。
留給下一課
將 deployment pack 作為正式變更與下一輪投資的基線。擴大新流程、資料、locale 或權限前，複製同一套門檻並重跑受影響 eval。
驗收條件
- 0130 天計畫具有 discovery、sandbox、shadow、canary、stabilize／handoff，每階段都有 go、no-go、復原與決策人。
- 02品質、採用、流程健康、完整成本與風險皆有人工基準、資料來源及硬門檻。
- 03正式權限遵守最小範圍，公開發布、CRM 發送與預算不在本專案；服務身分、保留、撤銷可查。
- 04owner 與 backup 都完成暫停、查 run、人工接管、回復與 eval 更新的反向操作。
- 05最終投資建議允許 expand、modify 或 stop，並列出證據強度、限制、維運負荷及下一次 review。
常見故障
故障診間
F1專案第 2 週已經接正式資料，卻沒有 owner、基準或停止權限。
- 先檢查
- 查看 charter 簽核、RACI、資料核准、服務身分、階段 decision log 與值班表。
- 可能原因
- 把交付日期當成 go 條件，discovery 與 sandbox 只做口頭確認。
- 修復方式
- 暫停正式 run、撤銷多餘權限，回到 sandbox 補基準、owner 與停止演練。
- 下次怎麼避免
- 每個階段只有證據齊全且決策人簽核才能升級；日期到不代表自動前進。
F2cycle time 看似下降，但編輯、IT 與法務投入時數大增。
- 先檢查
- 重算模型、工具、人工審核、重工、事故、維運與供應商費用，對照原流程。
- 可能原因
- 只算生成時間或 API 費用，交接與例外工作被移到其他團隊。
- 修復方式
- 降低流量、修正瓶頸或縮小範圍；把隱藏工時加入單次成功成本再決策。
- 下次怎麼避免
- 從 discovery 就記完整成本，階段 review 同時看週期、品質、採用與維運負荷。
F3外部團隊離場後沒人會處理 dead-letter、更新 eval 或撤銷憑證。
- 先檢查
- 檢查 owner／backup 操作紀錄、runbook 權限、文件位置、值班與變更責任。
- 可能原因
- 交接只做簡報，沒有由內部人員實際反向操作。
- 修復方式
- 暫緩擴大，安排 owner 與 backup 在 sandbox 和 canary 各完成一次操作並補權限。
- 下次怎麼避免
- 把反向操作、事故演練、eval 更新與權限撤銷列為專案驗收，不完成就不結案。
展示版之後
正式上線前的邊界
- 01charter 鎖定單一流程、介入起訖、out-of-scope、sponsor、owner、backup、使用者與受影響團隊。
- 02每階段有輸入、證據、go／no-go、停止、回復、決策人與簽核時間；排程不會自動越級。
- 03資料有分類、用途、lineage、保留、刪除與供應商條款；服務身分採最小權限且可快速撤銷。
- 04workflow、prompt、schema、模型、工具、eval、dashboard、runbook 與 policy 全部版本化。
- 05sandbox、shadow 與 canary 涵蓋正常、邊界、注入、拒答、timeout、重複、部分失敗及人工逾期。
- 06監測品質、週期、採用、人工接管、傷害、資料漂移、完整成本與成功單位成本。
- 07原手動流程在 canary 期間可用，owner 能暫停、排空、接管、回復並對未完成項目負責。
- 08owner 與 backup 通過反向操作，文件與權限歸內部所有；外部存取在交接後依清單撤銷。
- 09最終投資備忘錄揭露樣本、限制、開放風險與維運負荷，不把 30 天方向性結果包裝成保證 ROI。
證據類型
資料來源與主張限制
資料來源只支撐本課標示的主張，不代表換一個系統也會得到相同結果。
- [1]OpenAI Academy Courses: Champion Deployment Guide組織導入的受眾、贊助者、節奏、office hours 與採用衡量
OpenAI Academy · 官方文件 · 2026-08-20
- [2]Improving support with every interaction at OpenAI第一線標註、trace、eval 與知識更新如何形成營運迴圈
OpenAI · 官方文件 · 2026-08-20
- [3]Cyera case study方法、執行、衡量與服務交付的公開案例
Powered by Search · 公開案例 · 2026-08-20
- [4]Forward Deployed MarketingTenten 的 FDM 服務邊界與導入方法
Tenten AI · Tenten 實務方法 · 2026-08-20
- [5]FDM Enterprise Playbook工作流程適配、ROI、技術堆疊、組織與交接方法
Tenten AI · Tenten 實務方法 · 2026-08-20
延伸的 Tenten 資源