FDE 作品集怎麼做：一個能進 Production 的 AI 導入案例

一個聊天視窗、幾段漂亮回答，能證明你會串模型 API；它無法證明你能做 FDE。FDE = Forward Deployed Engineer，前線部署工程師，作品集要回答的是：這套系統接到企業資料後，誰能看什麼、錯了怎麼辦、品質如何回歸、使用者為何願意採用？

以下案例選「企業客服工單 copilot」，因為它同時需要 CRM 資料、產品知識、權限、人工判斷與可衡量 workflow。OpenAI 的部署指南也以取得 CRM context 的客服流程說明 production 導入；但本文的架構與 90 天建議是編輯整理，不代表官方唯一做法。

先寫一頁問題定義

不要從模型開始。先假設一家 B2B SaaS 公司每天收到產品操作、帳務、權限與故障工單。客服要在知識庫、CRM、狀態頁與歷史回覆間切換，copilot 的目標是整理上下文並產生可編輯草稿，不是自動對客戶承諾退款或修改帳號。

定義三個使用者：客服專員、主管、系統管理員。第一版成功條件可以是降低查找步驟、提高引用完整性、減少重複編寫；不要捏造節省比例。作品完成後用測試參與者的任務時間、修改原因與拒用原因留下原始資料。

Workflow：保留人的決策權

收到工單後，系統讀取分類、客戶與授權產品。
依客服專員權限取得 CRM 摘要與知識庫片段。
模型產生問題摘要、建議分類、來源與回覆草稿。
規則引擎標示退款、安全、法律或低信心案例。
客服編輯並送出；高風險案例必須主管核准。
保存採用、修改、拒絕、引用與版本資料，供 eval 回歸。

人工審核不是臨時補丁，而是產品的一部分。NIST 的生成式 AI 風險管理文件建議持續監測 human–AI configuration 的結果；你要說清楚人在哪裡能否決、系統如何記錄決策。

權限與資料：先證明不會拿錯

最小資料模型包含 tenant、user、role、ticket、customer、document、draft、approval 與 audit event。每次 retrieval 必須帶 tenant 與產品授權條件；模型不能直接持有資料庫管理權限，工具只能暴露完成任務所需的窄接口。

用四個測試證明邊界：跨租戶文件不能被取回、一般客服看不到財務欄位、被撤銷文件不再引用、模型要求「忽略權限」時工具仍拒絕。OWASP 將 prompt injection 與敏感資訊揭露列為 LLM 應用的核心風險，防線不能只靠 system prompt。

Eval：建立一份會成長的失敗資料庫

先準備 40 筆合成工單，涵蓋一般操作、缺資料、過期文件、退款、資安、跨租戶攻擊與 prompt injection。每筆至少標記：

必須引用的來源與禁止使用的來源
建議分類與是否應升級人工
草稿必須包含／不可包含的資訊
工具呼叫與權限預期
可接受的語氣與不確定性表達

自動評分適合檢查 JSON schema、引用、工具、敏感字串與分類；語意品質再由人工 rubric 抽查。每次修改 prompt、模型、retrieval 或資料清洗後，都跑同一份回歸集並保存版本。不要只公布總分，要列出失敗類型與你接受的風險。

部署：讓每個版本可追蹤、可回復

建立 dev、staging、production-like 三個環境；secret 不進 repository。CI 執行單元測試、權限測試、eval smoke test 與資料 migration 檢查。部署時以 feature flag 先開給少數測試帳號，模型、prompt、retriever 與知識庫都要有版本。

準備兩種 rollback：應用版本回退，以及只關閉自動草稿、保留手動查詢。若模型供應商超時，工單仍要存在並能回到人工流程。

監控：沿一張工單看完整因果鏈

OpenTelemetry 的 traces、metrics、logs 能建立 vendor-neutral 的觀測基礎。每筆請求至少串起：使用者、工單、retrieval、模型、工具、approval 與送出事件；敏感內容只記必要 metadata，不把完整客戶文字倒進 log。

建議觀察：端到端延遲、錯誤率、單張工單成本、無來源回答、人工修改類型、主管退回、拒用與升級人工。品質指標與系統指標要放在一起；只看 token 或 uptime，不知道 workflow 是否改善。

成效：不要自己發明 ROI

找 3–5 位測試者，各自完成相同的基準任務與 copilot 任務，記錄耗時、查詢次數、草稿修改、錯誤與主觀信任。樣本太小時只報告觀察結果，不宣稱統計顯著或企業 ROI。

最有價值的作品段落通常是「原假設被推翻」。例如使用者不在乎自動分類，卻很在乎每句建議能否點回來源；你因此縮小功能、加強引用與人工覆核。這就是從客戶訊號調整產品，而不是照規格做完。

Repository 與 demo 的交付清單

README：問題、使用者、非目標、資料為合成、架構與取捨
threat model：資產、信任邊界、濫用情境與剩餘風險
eval：dataset、rubric、執行指令、版本比較與失敗樣本
operations：環境、部署、觀測、成本預算、rollback 與 runbook
demo：正常案例、權限拒絕、prompt injection、人工核准、供應商故障
impact memo：測試方法、原始觀察、限制與下一步

你可以先用能力地圖找缺口，再依三種工程背景的 90 天路線調整實作順序。完成後，拿這套證據準備 FDE 面試與工作現實，會比背名詞更有效。

常見問題

作品集一定要接付費模型 API 嗎？

不一定。可用有免費額度的 API、可替換 provider 或本地模型；重要的是保存模型與 prompt 版本、成本與失敗資料，並讓 eval 能比較不同選擇。

沒有企業資料可以做客服案例嗎？

可以使用自行設計的合成工單、產品文件與客戶層級，清楚標註資料為模擬。不要抓取或上傳未授權的真實客服內容。

作品集需要真的部署到 production 嗎？

不必服務真實企業，但應部署到可重現的 production-like 環境，具備身份、權限、secret、監控、版本、rollback 與 runbook，而不只是本機 demo。