我們用AI做了1門合規課，結果栽了

生成一門課程只需17秒，但讓它"能用"花了我們8個月。

CPDForge團隊最初的想法很直接：把合規培訓材料丟給大語言模型（LLM，一種基于深度學習的文本生成系統），讓AI自動輸出結構化課程。技術上完全可行，演示效果也過得去。但當他們真正坐下來逐字審閱時，問題浮出水面——內容在"解釋"，卻沒有在"教學"。

深度缺失，真實場景空白，邊界案例（edge case，指極端或異常情況）完全沒有覆蓋。部分章節詳細得像教科書，另一些卻像臨時拼湊的占位符。整門課程沒有統一的設計邏輯，只是一堆內容碎片的機械組裝。

在合規培訓領域，"差不多對"等于風險敞口。團隊一度以為瓶頸在于"如何生成更好的內容"，后來才意識到真正的難題是：如何讓生成的內容保持一致、可靠、可安全部署。

從"生成"到"系統"：Pipeline的六次迭代

最初的流程極簡：Prompt（提示詞）→ LLM → 輸出課程。這個版本在內部演示時沒出問題，直到他們開始系統性測試——同樣的輸入，每次輸出都有微妙差異；某些生成結果看似合理，實則與法規條文存在偏差。

團隊負責人后來回憶：「你能生成一門課，但無法依賴它。」

轉折點發生在他們停止將問題定義為"生成質量"，轉而視為"系統工程"。Pipeline（處理流程）逐步演化為六層架構：

輸入層 → 結構化生成 → 驗證層 → 定向重寫 → 富化層（測驗、場景、案例） → 合規檢查 → 輸出

每一層都有存在的必要性。團隊發現，跳過任何一層，后續必定出現失效。驗證層負責攔截事實性錯誤，定向重寫修正風格不一致，富化層將抽象條款轉化為可交互場景，最后的合規檢查則對照實時法規庫進行交叉核驗。

最棘手的部分在于約束模型的"即興發揮"。早期他們嘗試過讓LLM整體重生成問題章節，結果發現這只是在轉移錯誤位置，而非消除錯誤根源。最終方案是引入規則引擎與檢索增強生成（RAG，一種結合外部知識庫約束模型輸出的技術），將模型的創造性嚴格限定在特定框架內。

隱藏成本的冰山

項目中期，團隊統計過一組數據：純生成環節僅占整體工作量的12%，剩余88%消耗在驗證、修正、測試與迭代上。這個比例與行業常見的AI應用困境高度吻合——生成容易，可用極難。

他們被迫開發了一套完整的元數據追蹤系統，記錄每段內容的來源、生成時間、模型版本、人工審核狀態。同時引入對抗性測試（adversarial testing，故意輸入極端或誤導性提示以檢驗系統魯棒性），模擬用戶可能提出的各種刁鉆問題。

另一個隱性成本是領域知識的"翻譯"損耗。合規專家熟悉的是法規條文與判例，工程師理解的是token限制與溫度參數（temperature，控制模型輸出隨機性的超參數），兩者之間存在巨大的認知鴻溝。團隊最終聘請了兼具法律背景與產品經驗的"雙語者"擔任接口角色，才將溝通損耗降至可接受范圍。

「我們一度以為AI能減少人力投入，」團隊成員在復盤時寫道，「實際上它只是將人力從'寫作'轉移到了'質檢'與'系統設計'。」

從Prompt Engineering到System Engineering

技術路線的轉變也體現在人才結構上。早期團隊重金招募提示詞工程師（Prompt Engineer），試圖通過精妙的指令設計榨取模型能力。后期則轉向系統架構師與質量工程師，將AI視為Pipeline中的一個可替換組件，而非核心解決方案。

這種轉變有其深層邏輯。大語言模型的本質是基于概率的文本續寫，而合規培訓要求的是確定性輸出——同一法規條款的解釋，今天和明天必須一致，對張三和李四必須相同。概率系統與確定性需求之間存在結構性張力，無法通過更好的提示詞徹底解決，只能通過系統層面的約束與校驗來管理。

團隊最終交付的產品并非"AI生成的課程"，而是"AI輔助的課程生產系統"。后者包含模板庫、版本控制、人工審核節點、A/B測試框架，以及完整的審計日志。生成只是入口，信任才是出口。

CPDForge將這段經歷公開分享時，特別提到一個反直覺的發現：客戶最初詢問的是"你們用哪個模型"，簽約后最關心的卻是"你們如何確保內容不漂移"。技術選型的重要性，遠不及質量管控制度的可信度。

這個項目沒有產生那門"17秒生成的合規課"，但催生了一套被三家金融機構采購的內容生產基礎設施。團隊現在的說法是：「我們起點錯了，但終點對了。」

如果你正在評估某個"AI一鍵生成X"的產品，你會首先檢查它的驗證層設計，還是直接試用生成效果？