Fyxer AI 行政助理：回饋迴路帶來的產品啟示

快速解答

OpenAI 在 2026 年 9 月 14 日發布 Fyxer 客戶案例，介紹這款 AI 行政助理如何結合 OpenAI 模型、超過 50 萬小時的行政助理工作流程、記憶、任務型評估，以及使用者真實修改。OpenAI 表示，Fyxer 並不是用單一模型一次解決整個收件匣問題，而是把電子郵件流程拆成約 30–50 個專門模型處理不同工作。

TowCue 認為最值得借鑑的不是「每家公司都應該做幾十個模型」，而是可靠的 AI 工作流產品愈來愈像一個系統，而不是一條 Prompt：先判斷任務、找出正確上下文、生成結果、觀察使用者如何修改、評估修改，再把這些訊號帶回產品迭代。

延伸閱讀可參考 TowCue 的如何為工作選擇 AI 工具、AI Agent 最佳實務，以及 Claude 的 Microsoft 365 寫入工具。

Fyxer 實際上怎麼做

Fyxer 直接在 Gmail 與 Outlook 中整理收件匣、找出需要注意的郵件，並以使用者的語氣產生回覆草稿。Fyxer 官方產品頁明確說明，使用者會先檢視草稿，再自行送出，而不是讓 Fyxer 自動代為寄信。

OpenAI 的案例進一步說明背後架構。Fyxer 不把「幫我回信」視為一次文字生成，而是拆成多個決策。模型先判斷郵件需要回覆、排程動作，還是只需要讓使用者看到；其他模型分析意圖與可能結果；檢索模型選出相關記憶與過往互動，再由生成模型建立草稿。

這種拆分很重要，因為一封好郵件需要的不只是文法正確，還必須理解關係、先前承諾、語氣與下一步行動。

最值得注意的是「修改後再學習」

Fyxer 最有移植價值的設計，其實發生在 AI 產生草稿之後。

當使用者修改 AI 草稿再寄出時，Fyxer 可以比較原始版本與最終版本。OpenAI 表示，Fyxer 會把這類比較轉成偏好訓練資料，使用 Direct Preference Optimization，並透過 A/B test 驗證新的草稿系統，確認有統計上顯著改善後才全面推出。

這代表平常的使用行為本身就能成為品質訊號。

一般 AI 助理往往從 Prompt 開始，回答完就結束；工作流產品則可以形成一個迴路：

預測使用者現在需要什麼；
產生建議動作或成果；
觀察使用者的修改；
把修改轉成結構化回饋；
測試新版系統是否真的改善這項工作。

這已經更接近產品工程，而不只是 Prompt engineering。

53% 草稿直接採用率很有意思，但不是通用標準

OpenAI 報告指出，Fyxer 有 53% 的 AI 草稿會被使用者原樣採用，並稱超過 90% 的使用者在 90 天後仍持續付費。這些是 OpenAI 客戶案例中披露的 Fyxer 特定數據，不是獨立產業基準。

TowCue 不建議把 53% 當成所有 AI 郵件助理的目標。不同使用者、郵件類型與審核標準都會大幅影響數字。

更好的問題是：系統是否正在量測最適合自己工作的修正訊號？

對郵件助理來說，可以追蹤草稿採用率、修改幅度、寄出所需時間，以及預測的下一步是否正確。對 coding agent，對應訊號可能是測試失敗、人類修改與 rollback；對研究 agent，則可能是引用修正與無來源主張比例。

專門模型是一種架構選擇，不是一條規則

OpenAI 表示 Fyxer 在電子郵件工作流中使用約 30–50 個專門模型。這是一個值得注意的資料點，但團隊不應照抄這個數量。

當不同子任務有不同準確率、延遲與成本要求時，專門化才真正有意義。Fyxer 表示，它會用自己的驗證集評估模型，並同時衡量準確率、回應時間與成本，因為不同工作最適合的模型可能不同。

因此更實際的原則是：

依任務經濟性路由，而不是依模型名氣路由。

輕量分類器未必需要和細膩的關係型回信使用同一模型；檢索排序也可能需要完全不同的評估標準。

對小團隊而言，一個能力足夠的模型搭配清楚工具往往更簡單、更便宜。只有當量測證明拆分確實改善品質、延遲或成本時，再增加專門化。

記憶應該是選擇性的，而不是愈多愈好

Fyxer 的工作流也凸顯個人化 AI 常見的誤解：更多記憶並不一定更好。

OpenAI 表示，系統必須判斷哪些資訊值得跨對話保留，哪些應該在一次互動後消失；之後再由檢索模型找出與目前人物和郵件串最相關的記憶。

這比把整段歷史全部塞進每一個 Prompt 更合理。

實用記憶至少需要三種控制：

**選擇：**什麼值得保存；
**檢索：**現在真正需要什麼；
**到期或修正：**哪些資訊不該再影響未來工作。

缺少這些控制時，個人化很容易從有用上下文變成過期上下文。

團隊可以從 Fyxer 複製什麼

1. 先拆工作，再選模型

先畫出工作流程中的決策。郵件可能是分類 → 找上下文 → 判斷意圖 → 產生草稿 → 審核；其他工作會有不同階段。

2. 把使用者修改當成資料

如果使用者持續修改 AI 輸出，不要只把它當成摩擦。這些修改正是在告訴你系統哪裡判斷錯誤。

3. 用真實任務做評估

Fyxer 評估的是草稿、分類與優先順序，而不是只看通用模型 benchmark。團隊也應針對自己的失敗模式建立 validation set。

4. 在有後果的邊界保留人工確認

Fyxer 官方頁面表示，它會先產生草稿，由使用者檢視後寄出。對可能影響關係與承諾的對外溝通，這是一個合理的權限邊界。

5. 同時量測品質與經濟性

最準確的模型不一定是最佳 production 選擇。除了任務成功率，也應同時追蹤延遲與成本。

誰最值得關注

這種模式特別適合正在打造重複性、強上下文助理的團隊，例如電子郵件、客戶成功、招募、銷售營運、客服、研究與企業內部知識工作流。

當工作有大量重複，而且會自然產生使用者修正訊號時，價值最高。

如果任務很少發生、定義模糊或根本無法評估，建立複雜的回饋架構反而可能得不償失。

TowCue 判斷：真正的產品護城河是學習迴路

Frontier models 持續進步，單純的生成品質會愈來愈容易被競爭者取得。

更耐久的優勢可能來自模型周圍的整個迴路：專有任務資料、上下文選擇、使用者修改、評估集、路由邏輯，以及可量測的持續迭代。

Fyxer 是一個很好的例子，因為表面輸出只是一封回信草稿，但背後系統刻意不是「一個 Prompt 解決全部」。

對正在打造 AI 工作流產品的團隊來說，問題正在從：

「哪一條 Prompt 能寫出最好的答案？」

轉變成：

「什麼系統能在每次使用者修正它之後，變得可量測地更好？」

這才是值得複製的工作流啟示。

來源

OpenAI — How Fyxer built an AI executive assistant people trust，發布於 2026 年 9 月 14 日。
Fyxer — 官方產品頁，說明收件匣整理、草稿、會議上下文與行政助理工作流資料。
Fyxer — AI Email Organizer，說明 AI 回覆採取「產生草稿 → 使用者檢視 → 使用者送出」的工作方式。

Fyxer 的 AI 行政助理：為什麼回饋迴路比一個完美 Prompt 更重要