CCCD 框架：不讓 AI 產品失控的持續校準方法

本文整理自 Lenny’s Podcast 2026 年 1 月播出的單集，為系列第三篇。

來賓背景

這集的兩位來賓是夫妻，也是 AI 產品領域最有實戰經驗的組合之一：

• Kiriti Badam：OpenAI Codex 產品負責人，曾在 Google 打造 AI/ML 基礎設施十年
• Aishwarya Reganti：前 Alexa、Microsoft AI 研究員，現為企業 AI 轉型顧問

兩人合計參與 50+ AI 產品部署。這個 CCCD 框架，就是他們從無數失敗和成功案例中提煉出來的方法論。

為什麼需要 CCCD 框架？

Aishwarya 分享了開發這個框架的背景。

她曾經為客戶打造一個全自動客服 agent。結果上線後，各種意料之外的問題不斷冒出來，團隊只能瘋狂 hotfix。問題修不完，最後只能關掉產品。

Air Canada 也發生過類似事件：他們的客服 agent 幻覺出一個不存在的退款政策，客戶照著做了，公司被迫承認這個政策——因為法律站在客戶那邊。

這些案例讓他們思考：如何在不失去使用者信任、不讓 AI 做出危險決策的前提下，逐步提升 AI 的自主性？

答案就是 CCCD 框架。

CCCD 框架是什麼？

CCCD 全名是 Continuous Calibration Continuous Development（持續校準、持續開發），名稱致敬軟體工程的 CI/CD。

框架分為兩個循環：

右半圈：持續開發（Continuous Development）

1. 界定能力範圍並整理資料：建立一個資料集，定義預期的輸入和輸出應該長什麼樣子。這是很好的練習，因為你常會發現團隊成員對「產品該怎麼運作」根本沒有共識。

2. 建立應用程式：開始實作。

3. 設計評估指標：注意，Aishwarya 刻意用「evaluation metrics」而非「evals」，因為評估是一個過程，指標是過程中關注的維度。

4. 部署並執行評估。

左半圈：持續校準（Continuous Calibration）

1. 分析行為：觀察系統在真實環境中的表現，尤其是那些你一開始沒預料到的使用模式。

2. 辨識錯誤模式：有些錯誤只是偶發，修掉就好（例如工具定義寫錯）。有些則是系統性問題，需要建立新的評估指標來追蹤。

3. 應用修正：修 bug、調整 prompt、改工具配置。

4. 設計新的評估指標：針對新發現的問題類型。

實例：客服 Agent 的三階段演進

Aishwarya 用客服 agent 舉例：

V1：路由（Routing）

目標：讓 agent 能正確分類工單，送到對應部門。

這看起來簡單，但在企業環境往往很複雜。Aishwarya 遇過零售公司的分類系統極度混亂——同一層級同時有「鞋子」「女鞋」「男鞋」，另一個地方又有「for women」「for men」。人類知道哪些是過時的死節點，但 AI 沒有這個脈絡。

這個階段的好處：即使 agent 判斷錯誤，人類可以輕易介入修正。 同時，你也在過程中清理資料問題。

V2：副駕駛（Co-pilot）

目標：agent 根據 SOP 產生回覆草稿，由人類審核後送出。

這個階段你會記錄人類的行為：草稿被採用了多少？哪些被改掉了？哪些被刪掉了？這些資料就是免費的錯誤分析，可以回饋到下一輪迭代。

V3：端到端解決（End-to-End Resolution）

目標：agent 可以直接解決工單，包括退款、提交功能需求等。

只有當 V2 的草稿大多數時候都被原封不動採用時，才應該進到這個階段。

什麼時候該進入下一階段？

主持人 Lenny 問了這個關鍵問題。

Aishwarya 的回答：沒有固定規則，但核心原則是「最小化驚訝」。

如果你每一兩天校準一次，發現使用者行為很一致、沒有新的資料分布模式出現，那代表你從這個階段能學到的東西已經很少了——可以考慮進入下一階段。

但她也提醒：有些事件會徹底打亂你的校準。例如：

• 模型更換：GPT-4o 要被棄用了，你必須換成 GPT-5，而新模型的特性可能完全不同
• 使用者行為演變：使用者發現你的系統能做某件事後，會開始嘗試更複雜的需求

她舉了一個銀行核保系統的例子。前三四個月，系統表現很好，核保員回報省下大量時間。但之後，核保員開始丟出更複雜的問題：「對於這種類型的案例，以前的核保員怎麼處理的？」——這完全是系統設計之外的需求。

Evals 的迷思

這集也深入討論了「evals」這個熱門話題。

Kiriti 觀察到，「evals」這個詞已經被過度使用，不同人講的根本是不同的東西：

• 資料標註公司說的 evals：專家在做錯誤分析
• PM 說的 evals：產品規格的新形式
• 工程師說的 evals：LLM judge 或自動化測試

Aishwarya 則指出一個常見的錯誤二分法：「evals 能解決一切」vs「生產監控能解決一切」。

事實是兩者都需要：

• Evals 能捕捉你已經知道會出問題的情境
• 生產監控 能捕捉你沒預料到的新模式

Kiriti 也分享了 Codex 團隊的做法：他們有核心功能的 evals，確保改動不會破壞基本功能。但對於 coding agent 這種高度客製化的產品，不可能為所有使用情境建立評估資料集，所以他們也非常仰賴客戶回饋、社群討論、A/B 測試。

Claude Code 的負責人 Boris 曾說他們「不做 evals，靠 vibes」。Kiriti 的看法是：沒有人能說「我有一組 evals 可以賭上身家，其他都不用管」。

小結

CCCD 框架的核心理念：

1. 行為校準是關鍵：你無法預測 AI 系統在真實環境會怎麼運作，必須持續觀察和調整
2. 從低代理開始：限制 AI 的決策範圍，確保人類可以輕易介入
3. 逐步增加自主性：隨著信任建立，逐步給予更多自主權
4. Evals 和生產監控都需要：兩者互補，缺一不可

這個框架不是萬靈丹，但它提供了一個降低風險的結構化方法。

本系列共四篇。下一篇將探討「痛苦是新護城河」——為什麼 AI 時代的競爭優勢來自實作經驗。