起點課堂會員權益
職業(yè)體系課特權
線下行業(yè)大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業(yè)技能直播
會員專屬社群
榮耀標識來自OpenAI及谷歌等50+項目復盤：為什么AI Demo很驚艷，最后卻失敗了？
一個完美的 Demo 和熱烈的早期反響，為何最終卻可能導致 AI 產(chǎn)品上線后問題頻發(fā)、信任流失 ？傳統(tǒng)軟件開發(fā)的最佳實踐在 AI 時代可能已經(jīng)不再適用。
基于在 OpenAI、Google 等公司主導 50 多個 AI 項目的經(jīng)驗，Aishwarya Reganti 和 Kiriti Badam 提出了一套全新的開發(fā)框架：持續(xù)校準/持續(xù)開發(fā) (CC/CD)。
本文將深入剖析 AI 產(chǎn)品開發(fā)的兩個根本性挑戰(zhàn)：其內(nèi)在的“非確定性”，以及“代理權”與“控制權”之間不可避免的權衡。同時詳細解讀 CC/CD 框架如何幫助團隊應對這些獨特挑戰(zhàn)，從而構建出更穩(wěn)定、更值得信賴的 AI 產(chǎn)品。希望能為大家?guī)韼椭?，Enjoy！
一、什么是持續(xù)校準/持續(xù)開發(fā) (CC/CD) 框架
公司要啟動一個 AI 項目，想法聽起來前景不錯。團隊做出的 Demo 堪稱完美，早期評價很好，利益相關者也滿心歡喜。于是，團隊上下一心，使勁把項目推向了生產(chǎn)環(huán)境。
然而，問題開始浮現(xiàn)了。當團隊深入細節(jié)試圖找出癥結時，卻發(fā)現(xiàn)這些問題個個錯綜復雜，難以追蹤，也找不到單一的解決辦法。突然之間，整個產(chǎn)品的方向都變得搖擺不定。
這種情況并不少見。在過去幾年里，本文作者 Aishwarya 和 Kiriti 幫助超過 50 家公司設計、發(fā)布并擴展了 AI 自主系統(tǒng)，服務了成千上萬的客戶?；谶@些經(jīng)驗，他們發(fā)現(xiàn)了一個常見的陷阱：人們忽視了一點，AI 系統(tǒng)的底層邏輯，已經(jīng)從根本上顛覆了傳統(tǒng)軟件的那些基本假設。
AI 產(chǎn)品的打造方式之所以如此不同，主要有兩個原因：
- AI 產(chǎn)品本質(zhì)上是非確定性的。
- 每個 AI 產(chǎn)品都必須在代理權 (Agency) 和控制權 (Control) 之間做出權衡。
如果公司認識不到這些差異，AI 產(chǎn)品就可能出現(xiàn)一連串意想不到的故障和糟糕決策。太多團隊都經(jīng)歷過這個痛苦的過程：Demo 看著很驚艷，但系統(tǒng)一上線就無法擴展，或者根本跑不起來。而就在這個過程中，用戶對產(chǎn)品的信任也一點點流失了。
在多次目睹這種模式后，他們基于成功部署的經(jīng)驗，設計出了一個專為 AI 產(chǎn)品開發(fā)生命周期服務的新框架。這個框架旨在幫助團隊正視 AI 系統(tǒng)的獨特性，從而構建出目標更明確、運行更穩(wěn)定、也更值得信賴的產(chǎn)品。
1. AI 產(chǎn)品本質(zhì)上是非確定性的
傳統(tǒng)軟件的行為，大體上可以預測。因為用戶的交互方式是已知的：比如點擊按鈕、提交表單，或是觸發(fā) API 調(diào)用。開發(fā)者會編寫邏輯，讓這些輸入對應到確定的輸出上。就算出了問題，通常也是代碼 Bug，并且也能追溯到源頭。
AI 系統(tǒng)的行為方式則有所不同。它在輸入和輸出兩端，都帶來了非確定性。換句話說，無論是用戶的交互方式，還是系統(tǒng)的響應，都存在不可預測性。
首先，用戶交互界面就遠不如傳統(tǒng)產(chǎn)品那么確定。用戶不是通過點擊按鈕這類結構化的方式來觸發(fā)，而是通過開放式的 Prompt、語音命令或其他自然語言來輸入。這些輸入不僅更難驗證、更容易被誤解，而且用戶表達意圖的方式也千差萬別。
其次，系統(tǒng)行為本身也是非確定性的。AI 模型接受訓練，是為了根據(jù)模式生成合理的響應，而不是去遵循固定的規(guī)則。同一個請求，可能因為措辭、上下文、甚至模型的不同，而產(chǎn)生不同的結果。
這從根本上改變了產(chǎn)品的構建和發(fā)布方式。產(chǎn)品設計不再是只針對可預測的用戶流程，而是必須考慮各種可能的行為——這些行為既來自用戶，也來自產(chǎn)品本身。因此，開發(fā)流程必須從一開始就把這種不確定性考慮進來，并持續(xù)地去校準預期與現(xiàn)實之間的差距。
2. 每個 AI 產(chǎn)品都權衡代理權和控制權
AI 系統(tǒng)還有一個獨特性，就是它的代理權 (Agency)。這是傳統(tǒng)軟件產(chǎn)品很少需要考慮的因素。
這里說的代理權，是指 AI 系統(tǒng)能代表用戶采取行動、做出決策或執(zhí)行任務（“AI agent” 這個術語也是這么來的）。比如：預訂機票、執(zhí)行代碼、從頭到尾處理一張支持工單等等。
和傳統(tǒng)工具不一樣，AI 系統(tǒng)在執(zhí)行任務時，通常帶有不同程度的自主性。但這里有一個常常被忽視的關鍵點：
每當你給 AI 系統(tǒng)更多代理權，就意味著你放棄了一些控制權。
因此，代理權和控制權之間總是需要權衡。這種權衡至關重要。打個比方，如果系統(tǒng)只是建議一個回復，用戶依舊可以否決它；但如果系統(tǒng)會自動發(fā)出回復，那最好得保證它萬無一失。
大多數(shù)團隊常犯的一個錯誤是，在系統(tǒng)出錯的后果還沒充分測試過之前，就直接給了它完全的代理權。如果一個系統(tǒng)在高度受控環(huán)境下的表現(xiàn)都還沒有得到驗證，那它就沒有準備好去獲得高度的代理權。
在系統(tǒng)尚未“贏得”高代理權之前就過早交出權限，不僅會搞不清楚系統(tǒng)到底在做什么，還會失去用戶的信任。
更嚴重的是，團隊最終會陷進去，不得不去調(diào)試一個龐大又復雜的系統(tǒng)。這個系統(tǒng)已經(jīng)采取了無法追蹤的行動，連背后的原因也無從查起，以至于開發(fā)者甚至都不知道該從哪里著手修改。
這就引出了為應對這些問題而開發(fā)的核心框架。
這個名稱借鑒了 CI/CD：持續(xù)集成 (Continuous Integration) / 持續(xù)部署 (Continuous Deployment)，但又和它不同。CC/CD：持續(xù)校準 (Continuous Calibration) / 持續(xù)開發(fā) (Continuous Development) 是專為那些行為非確定性、需要逐步贏得代理權的系統(tǒng)而設計的。
二、持續(xù)校準/持續(xù)開發(fā) (CC/CD) 的具體操作
和傳統(tǒng)軟件一樣，AI 產(chǎn)品也是一步步迭代，最終實現(xiàn)目標的。但打造 AI 產(chǎn)品，必須考慮前面提到的兩大核心要素：非確定性，以及代理權與控制權的權衡。
CC/CD 框架的設計，就是為了應對這兩個現(xiàn)實情況 ：
- 通過精心設計或密切監(jiān)控，來減少系統(tǒng)的非確定性。
- 確保代理權是逐步“贏得”的，而不是一次性給全。因為每加一個新功能，就等于把一部分控制權從人手里交了出去。
在這個框架里，產(chǎn)品開發(fā)者是在一個持續(xù)開發(fā) (CD) 和持續(xù)校準 (CC) 的循環(huán)中工作的：
在開發(fā)階段，團隊要先界定問題范圍、設計好架構，并建立評估體系，以此來控制非確定性。要從代理權低、控制權高的功能開始做起，等系統(tǒng)逐步證明自己能處理更多場景了，再向上迭代。
接著是部署，但部署并不是結束，只是一個過渡階段。
部署完成后，就進入了校準循環(huán)。這時就要觀察系統(tǒng)在真實環(huán)境下的行為，找出故障點，然后針對性地改進。每循環(huán)一次，系統(tǒng)都會贏得更多代理權。時間久了，這個循環(huán)會形成一個飛輪效應，通過緊密的反饋建立起信任，讓產(chǎn)品在每個版本迭代中都變得更強。
后文將具體看看 CC/CD 循環(huán)的每一個步驟，了解它們的內(nèi)容、重要性，以及執(zhí)行方法。
前三個步驟，組成了持續(xù)開發(fā) (CD) 這一側的循環(huán)，包括：確定功能范圍、設置應用程序和設計評估。
CD 1. 確定功能范圍并整理數(shù)據(jù)
假設有一個宏大的產(chǎn)品想法，并且已經(jīng)完成了初步研究，明確 AI 是正確的實現(xiàn)路徑。在傳統(tǒng)軟件開發(fā)中，通常會根據(jù)功能深度或用戶需求來規(guī)劃 v1、v2、v3 版本。
在 AI 系統(tǒng)中，這種版本控制的邏輯依然適用，但視角發(fā)生了轉變。
在這里，定義一個版本的標準，是看系統(tǒng)擁有多少代理權，以及團隊愿意放棄多少控制權。所以，思考方式也必須轉變：不再是考慮“功能集”，而是要“界定功能范圍”。
首先，要確定一組高控制、低代理權的功能（如圖中的第 1 版）。這些功能應該小巧、可測試，并且易于觀察。然后，再思考這些功能如何隨著時間的推移，一步步增加代理權來演進。目標就是把那個宏大的最終愿景，拆解成一系列可評估、可迭代、也能逐步構建的早期行為。
舉個例子，如果最終目標是自動化公司的客戶支持流程，那么 v1 版本就可以先從一個高度可控的起點開始，比如把范圍限定在“只將工單路由到正確的部門”。到了 v2 版本，系統(tǒng)可以開始建議可能的解決方案。直到 v3 版本，才允許它自動解決問題——但前提是必須帶有人工回滾機制。
請記住，這只是一種方法。實際情況會因產(chǎn)品而異，但這個過程往往是一致的：先從那些容易驗證、也容易被人工干預的簡單決策開始。然后，隨著 CC/CD 循環(huán)的推進，在每個版本中逐步增加自主性。
在每個版本中要停留多久，取決于觀察到的行為信號。優(yōu)化的目標，就是為了深入理解 AI 在充滿噪聲和變化的真實世界中，到底表現(xiàn)如何。
來看一些具體例子：
營銷助手
- v1：根據(jù) Prompt 起草電子郵件、廣告或社交媒體文案。
- v2：構建多步驟的 Campaign 并執(zhí)行。
- v3：跨渠道啟動、進行 A/B 測試并自動優(yōu)化 Campaign。
編碼助手
- v1：建議內(nèi)聯(lián)代碼補全和樣板代碼片段。
- v2：為需要人工審核的更大代碼塊（如測試或重構）生成代碼。
- v3：自主應用限定范圍內(nèi)的更改并創(chuàng)建 Pull Request。
如果你熟悉 GitHub Copilot 或 Cursor 的發(fā)展歷程，就會發(fā)現(xiàn)，它們走的正是這條路。
大多數(shù)用戶只看到當前版本，但它們的底層系統(tǒng)，就是這樣一步步迭代上來的。 從代碼補全開始，到代碼塊生成，再到創(chuàng)建 PR，每一步都是靠著用戶的使用、反饋和迭代才“贏得”的。
好了，既然用戶行為具有非確定性，我們就需要建立一個基準，用來理解哪些是預期行為，以及 AI 系統(tǒng)應該如何響應。 這正是數(shù)據(jù)發(fā)揮作用的地方。 數(shù)據(jù)能幫我們解決冷啟動的問題，并提供評估時能用到的具體依據(jù)。 這個基準，就稱為“參考數(shù)據(jù)集”。
拿客戶支持自動化的例子來說，對于路由版本 (v1)，參考數(shù)據(jù)集里可能包括：
- 用戶查詢
- 應路由到的部門
- 用于決策的元數(shù)據(jù)，如產(chǎn)品類型、用戶層級或來源渠道
這些數(shù)據(jù)可以從歷史日志里提取，也可以根據(jù)產(chǎn)品應該如何工作，來手動構造一批樣本。 這個數(shù)據(jù)集不僅能幫我們評估系統(tǒng)性能，還能幫我們看清楚，這個助手到底需要哪些上下文信息，才能跑得更可靠。 大多數(shù)產(chǎn)品都是從零開始的，所以目標是先收集至少 20 到 100 個樣本。
在接下來的 CC/CD 循環(huán)步驟中，會繼續(xù)使用客戶支持這個例子：
假設我們正在為一家公司構建一個完全自主的支持系統(tǒng)。 下面是我們將要用的版本劃分，以及它們對應的代理權和控制權級別。 接下來都用 v1、v2 和 v3 來指代這些版本。
CD 2. 設置應用程序
很多團隊會跳過第一步，過早地進入設置階段。結果就是一頭扎進各種實現(xiàn)細節(jié)里，過度糾結于需要哪些組件。但如果你在第一步正確界定了功能范圍，看過了足夠的樣本，也整理好了可靠的參考數(shù)據(jù)集，那么設置應用程序這一步就會非常直接。
這時候，你已經(jīng)清楚系統(tǒng)要做什么，對用戶可能提的問題有了初步了解，也明白了什么樣的響應才算好?，F(xiàn)在，只需要先把最精簡的版本搭起來，用來獲取有用的信號就行了。
軟件行業(yè)有句名言：“過早優(yōu)化是萬惡之源”，這句話在這里同樣適用。
不要過度設計，也不要過度優(yōu)化，至少在現(xiàn)階段不要這么做。只構建當前版本需要的功能就好。需要設置好日志，用來捕獲用戶輸入、系統(tǒng)返回以及用戶的交互方式等信息，這樣才能讓系統(tǒng)變得可測量、可迭代。
這會為將來的實時交互數(shù)據(jù)集打下基礎，也能幫助系統(tǒng)在日后不斷改進。這里不會深入探討實現(xiàn)細節(jié)，但有一點，如果產(chǎn)品要開放給最終用戶，請一定確保“護欄”和“合規(guī)性”這些基礎措施都已到位。
還有一個要點：在設置應用程序時，要確?？刂茩嘣谛枰獣r，能無縫地交還給人類。這些機制，就稱為“控制移交” (control handoffs)。舉個例子，在客戶支持 v1 中，如果一個工單被錯誤地路由了，那么接到這個工單的專員應該能很輕松地把它重新路由到別處。這個更正行為會被記錄下來，這樣不僅能幫系統(tǒng)在日后改進，也能維護良好的用戶體驗。
從一開始就考慮好控制移交，是建立信任和保持系統(tǒng)可恢復性的關鍵。
CD 3. 設計評估
這一步通常需要深思熟慮。
在發(fā)布任何功能前，都得先定義好：如何衡量系統(tǒng)是否達到了預期效果？它是否已準備好進入下一階段？這就要用到評估指標 (Evals)。
那么，什么是 Evals？
Evals 是一種評分機制，用來評估 AI 系統(tǒng)是否正常工作，在哪些方面有不足，以及需要改進什么?？梢园阉鼈兛醋鱾鹘y(tǒng)軟件里的“測試”。但它和單元或集成測試不同，那些測試的輸入輸出是固定的，正確性非黑即白，而 AI evals 處理的是模糊性。
Evals 完全是“應用特定”的，和第一步確定的任務緊密相關。它評估的重點，不只是系統(tǒng)“是否在運行”，更是它在執(zhí)行那些本質(zhì)上非確定性的任務（比如總結文檔或回答問題）時，表現(xiàn)得如何。這就是為什么 evals 沒有統(tǒng)一的標準。它們就像信號一樣，引導著迭代循環(huán)，幫助團隊隨時間調(diào)整和優(yōu)化系統(tǒng)行為。
舉個例子，在客戶支持系統(tǒng)的路由 v1 中，一個簡單卻很強大的 Eval 就是“路由準確性” —— 也就是看系統(tǒng)將工單正確路由到相應部門的頻率。單單這一個指標，就能反映出模型是否在學習正確的區(qū)分方式，以及系統(tǒng)設置是否穩(wěn)固。
到了客戶支持系統(tǒng)的 v2 階段，系統(tǒng)開始檢索內(nèi)部 SOP 或歷史解決方案來輔助人工客服。
這時，Evals 的重心就轉到了檢索質(zhì)量上。我們需要看：系統(tǒng)建議的內(nèi)容是否和工單相關？這些建議是人工客服會參考的嗎？
在這個階段，一個好的做法是，先在參考數(shù)據(jù)集上運行 Evals。這能幫我們評估性能，驗證 Evals 的設計是不是合理，還能對第二步的產(chǎn)品設置做些早期調(diào)整。有些團隊會等到部署后，再靠真實的用戶交互數(shù)據(jù)來優(yōu)化。這種方法行不行，要看系統(tǒng)的風險水平，以及能提前收集到多少參考數(shù)據(jù)。
不用在參考數(shù)據(jù)集上過度優(yōu)化 Evals。我們的目標是廣泛覆蓋關鍵的 Use Case，而不是追求完美。生產(chǎn)環(huán)境里的行為總會不一樣的，但一個強大的 Eval 設置能提供一個可靠的起點。
一旦系統(tǒng)實現(xiàn)了，也驗證了范圍界定正確、監(jiān)測手段完善，就可以部署了。部署，就是持續(xù)開發(fā)和持續(xù)校準這兩個循環(huán)之間的一個過渡階段。
過渡階段：部署
部署是個令人興奮的環(huán)節(jié)。但部署可不能憑感覺，更不能指望一切順利。
經(jīng)過 CD 1 到 CD 3，一個用于學習和改進的管道已經(jīng)建立起來了：交互會被記錄，人工接管的機制已經(jīng)就位，評估指標也已設好用來標記問題?，F(xiàn)在，終于有機會在真實環(huán)境中觀察系統(tǒng)的運行情況了。
一旦系統(tǒng)面向一小部分用戶部署，它就正式開始運行。
從這里開始，就進入了持續(xù)校準 (CC) 階段。真實世界的行為開始顯露出來，團隊也開始弄明白：哪些功能有效、哪些存在問題，以及下一步需要修復什么。
CC 4. 運行評估
在 CD 循環(huán)中，Eval 指標已經(jīng)設計好了。部署后，有了用戶行為日志，就可以評估系統(tǒng)的實際表現(xiàn)了。一旦收集到足夠多的實時交互數(shù)據(jù)，就可以開始運行評估。根據(jù)成本和計算資源的限制，評估可以在數(shù)據(jù)子集或整個數(shù)據(jù)集上運行。
如果需要在子集上評估，可以利用系統(tǒng)的獨有屬性，來決定采樣哪些數(shù)據(jù)點。例如，在客戶支持系統(tǒng) v1 中，日志會顯示人工客服是否將查詢重新路由到了不同部門。這個記錄就可以拿來，作為衡量路由準確性的一個代理指標。在更復雜的系統(tǒng)中，可以關注對話輪次、用戶是否給出了正面或負面反饋，或是其他會話中的信號。
“控制移交”的日志也能提供有價值的 Eval 信號，特別是當這些日志記錄下了人類是如何干預或調(diào)整系統(tǒng)結果的時候。
客戶支持系統(tǒng) v1 評估示例
此處的路由準確性為 ? (60%)。根據(jù)具體的 Use Case，選擇最具代表性的實時用戶交互樣本來運行 Eval 指標。如果交互數(shù)據(jù)量較?。?,000 到 3,000 條日志），可以直接在整個數(shù)據(jù)集上運行。
CC 5. 分析行為并識別錯誤模式
查看 Evals 的結果時，可能看起來不錯，也可能不盡人意。如果持續(xù)開發(fā)的前三個步驟做得扎實，指標得分通常會處在中間水平，這意味著還有優(yōu)化的空間。
接下來，就需要手動審查數(shù)據(jù)了。在構建 AI 系統(tǒng)的過程中，這是個至關重要、卻又常常被低估的環(huán)節(jié)。一個簡單的策略，就是從 Eval 指標表現(xiàn)最差的地方入手，那里通常藏著最有價值的信號。
例如，在客戶支持系統(tǒng)路由 v1 中，可以：
- 為每個部門找出 20 到 50 個準確性低的工單。
- 重點關注那些得分落后的部門（比如退款部門表現(xiàn)不佳，而賬單部門表現(xiàn)尚可）。
- 查看用戶說了什么、系統(tǒng)做了什么，以及最終結果是什么。根據(jù)應用的不同，這可能是一次交互，也可能是多輪會話。Eval 指標應該能幫你識別出問題所在，并定位到故障點。
一旦手動看過了足夠多的樣本，就會開始注意到一些重復出現(xiàn)的錯誤模式。這時要把它們記錄下來。一個簡單的表格格式在這個階段就非常有效：
這些模式能揭示出系統(tǒng)邏輯、Prompt 或輸入中需要調(diào)整的地方，同時也能幫你更有針對性地規(guī)劃下一個版本的范圍。
CC 6. 應用修復
一旦識別出可以著手解決的錯誤模式，就可以開始規(guī)劃修復方案了?？赡苁呛唵蔚?Prompt 微調(diào)，也可能是更換更好的模型、改進檢索質(zhì)量，或是添加新組件來分解任務。具體要改什么，完全取決于問題出在哪里。
前面提到“不要過度設計”，是因為這一步才是真正該投入工程精力的地方。要在數(shù)據(jù)的支持下，有意識地去演進系統(tǒng)架構，而不是憑空猜測。
這一步本身也常常需要迭代。可能應用一個修復，再跑一遍 Eval 指標，然后要么繼續(xù)完善當前版本，要么就回到第 2 步到第 5 步再走一遍，直到系統(tǒng)表現(xiàn)足夠好。而且，因為已經(jīng)有了數(shù)據(jù)，你不需要每次都重新部署。
同樣，Eval 的設計本身也可能存在不足。Evals 畢竟通常是基于參考數(shù)據(jù)集設計的，而參考數(shù)據(jù)集反映的是預期的用戶行為。然而，真實用戶的行為可能大相徑庭。
這種非確定性也可能讓 Evals 失效?；剡^頭去看第 4 和第 5 步時，可能會發(fā)現(xiàn) Evals 漏掉了一些問題，或者給有缺陷的輸出打了高分。因此，第 6 步也可能包括回頭去重新審視和重建 Evals，這完全正常。隨著產(chǎn)品不斷迭代，可能會經(jīng)歷好幾輪評估。這都是過程的一部分。
第一次完成第 6 步時，可能已經(jīng)逐漸適應了這個節(jié)奏。團隊會多次經(jīng)歷這個循環(huán)，一步步減少控制，允許系統(tǒng)變得更加自主，并讓產(chǎn)品功能來引導設計上的選擇。請記住，部署只是整個藍圖的一部分，大部分的工作都在于精心的設計。
這就引出了一個常見的誤區(qū)：很多人幾乎只關注“實現(xiàn)”，忙著追逐最新的工具和框架，最終卻犯了代價高昂的錯誤。要從一個宏大的目標開始，把它分解開，只有當那些更復雜的解決方案能真正解決實際問題時，才去用它們。
永遠不要以技術為起點。要讓問題、Evals 和數(shù)據(jù)來指導你下一步該做什么。 這就是用 AI 產(chǎn)品來駕馭非確定性的方式。
三、客戶支持的 CC/CD 循環(huán)
下面的表格，展示了一種把問題分解為多個版本的方法，每個版本的代理權會隨時間推移而增加。表格也概述了在每個階段可以構建的飛輪。還是繼續(xù)用客戶支持這個例子來說明。每一次迭代，都是在為下一次迭代鋪路。這只是一種可行的處理方式而不是唯一方式。
可以把它當作一個啟發(fā)，來思考如何分解自己的產(chǎn)品，從而有目的地去構建和擴展。
如果直接發(fā)布一個完全自主的支持系統(tǒng) (v3)，很多事情可能很快就會出錯。
舉一個簡單的例子：一個退款請求，被錯誤地標記成了賬單問題。系統(tǒng)因此拉取了錯誤的 SOP，并生成了一個看似合理但不正確的解決方案。最終，用戶會感到困惑，并對產(chǎn)品失去信任。
雖然可能有 Evals 來標記問題，但這時已經(jīng)陷入了困境，不得不去解開這一連串的故障。這個錯誤，最終表現(xiàn)為生成了錯誤內(nèi)容。但它的根源其實始于路由問題，又因為缺少上下文而加劇，最終導致了糟糕的結果。這只是一個簡單的例子，但已足以說明情況會變得多么復雜。
CC/CD 方法有助于避免這種惡性循環(huán)。
在客戶支持 v1 中，系統(tǒng)只處理工單路由。這能提供一些信號，讓你了解用戶是如何表述問題的、哪些部門常常被搞混，以及哪些元數(shù)據(jù)至關重要。然后，你就可以利用這些信息來改進路由邏輯、優(yōu)化 Prompt，再進入下一階段。
在 v2 中，系統(tǒng)基于 SOP 起草響應，但人類仍然會進行審查。這有助于理解，檢索到底在哪些地方失敗了，以及哪些文檔需要更新。
到了 v3，系統(tǒng)就準備好通過解決特定范圍內(nèi)的工單，來承擔更多代理權了。但到了此時，你已經(jīng)很清楚：哪些查詢可以安全地自動化，以及在哪些地方需要設置回滾機制。
四、CC/CD 的核心：回歸判斷力
AI 系統(tǒng)的潛力巨大，能以強大的代理權運行。但要實現(xiàn)這個目標，很少是靠堆砌復雜的工具或用蠻力來擴展。這也不是編寫一個完美的 Prompt 就能解決的。
想創(chuàng)建一個能通過有效自動化來節(jié)省時間、金錢和精力的 AI 系統(tǒng)，關鍵在于要理解它的細微差別，并且一步一個腳印地去解決實際問題。
可以把使用 AI 想象成團隊里來了一位新成員。這位成員也許非常聰明，但他還不知道團隊的工作方式。你不會在第一天就把風險最高的項目交給他。你會讓他從小事做起，觀察他的表現(xiàn)，和他建立信任。當他證明了自己能勝任時，再逐步擴大他的職責范圍。
AI 系統(tǒng)也需要走過同樣的路。這正是 CC/CD 框架想要支持的路徑。
CC/CD 的核心就是判斷力。
這種判斷力，能幫你決定該發(fā)布什么、在出錯時如何保護用戶、什么時候該把控制權交還，以及如何定義“足夠好”。
每個版本該包含多少功能？收集數(shù)據(jù)后多久才能推進？范圍要界定得多窄？對于這些問題，并沒有放之四海而皆準的答案。這取決于你的產(chǎn)品、用戶和時間表。有些產(chǎn)品需要花數(shù)周時間來迭代，而其他產(chǎn)品則可以推進得更快。這，正是判斷力的價值所在。
這種寶貴的產(chǎn)品思維，大部分早已存在于成功的產(chǎn)品領導者心中。CC/CD 只是為這種思維提供了一個結構。這個框架提供了一個循環(huán)、一個節(jié)奏和一種共通的語言，好讓團隊能把那些優(yōu)秀的產(chǎn)品本能，應用到 AI 系統(tǒng)上。
來源|隨機小分隊
本文由人人都是產(chǎn)品經(jīng)理作者【產(chǎn)業(yè)家】，微信公眾號：【產(chǎn)業(yè)家】，原創(chuàng)/授權 發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)許可，禁止轉載。
題圖來自Unsplash，基于 CC0 協(xié)議。
- 目前還沒評論，等你發(fā)揮！
