今天介紹 Langfuse 時，我們談到一件很重要的事：
不要只看月底 AI 總帳單。
要知道每一次工作到底花多少錢。
但光做到這一步，還是不夠。
因為一個 AI 回答只花 0.02 美元，看起來非常便宜。
如果員工最後花十分鐘重寫，它其實一點都不便宜。
所以今天只學一個動作：
每次 AI 工作結束後，把結果標成「可直接用、需人工修改、失敗」三類。
第一類：可直接用
「可直接用」不是：
AI 有回答。
也不是：
看起來寫得不錯。
而是這份成果已經達到原本的工作標準。
例如客服 AI：
- 回答符合公司政策。
- 沒有弄錯客戶資料。
- 沒有漏掉重要條件。
- 不需要員工重新改寫。
這時才標成：
可直接用。
第二類：需人工修改
這一類最容易被忽略。
例如 AI 已經整理出一封客服回覆。
大方向沒有錯。
但員工還需要：
- 修正一個日期。
- 補上一項退貨條件。
- 改掉錯誤稱呼。
- 重新整理一段說明。
這份成果不能算完全失敗。
但也不能和「直接拿來用」放在一起。
所以標成：
需人工修改。
這一類非常重要。
因為很多 AI 看起來成功率很高，真正隱藏的成本就藏在這裡。
第三類：失敗
什麼叫失敗？
最簡單的判斷方式是：
這份 AI 成果已經沒有修改價值，需要重新做。
例如：
- 找錯客戶。
- 回答錯誤政策。
- 漏掉關鍵資料。
- 捏造不存在的資訊。
- 格式完全不符合工作要求。
- 最後仍要員工重新從頭完成。
這時不要因為 AI「有產生文字」，就把它算成完成。
應該直接標成：
失敗。
為什麼一定要分這三類？
假設你正在比較兩個模型。
模型 A 比較貴。
模型 B 便宜很多。
如果只看 API 帳單，很容易直接選 B。
但實際跑一百件工作後可能發現：
模型 A：
- 大部分成果可以直接使用。
- 少部分需要修改。
- 真正失敗很少。
模型 B：
- API 成本比較低。
- 但大量成果需要員工重新修改。
- 失敗案件也比較多。
這時真正的問題就不是：
「哪個模型一百萬 Token 比較便宜？」
而是：
「哪個模型產生一份真正可用成果的成本比較低？」
Langfuse 裡可以怎麼記？
Langfuse 可以替 Trace 加上 Score。
Score 不一定只能是一個 1 到 10 的分數。
也可以使用分類型結果。
所以最簡單的做法，就是替每次完整工作建立一個固定的結果欄位。
例如名稱叫：
work_result
然後只允許三種結果：
- 可直接用。
- 需人工修改。
- 失敗。
名稱可以依公司習慣調整。
真正重要的是：
所有人使用同一套定義。
不要讓每個人自己理解「可用」
如果客服 A 覺得：
「只改兩句也算可用。」
客服 B 卻覺得：
「只要動過一個字就叫需修改。」
最後資料就無法比較。
所以導入前先寫清楚標準。
可直接用：
不需要修改重要內容，可以直接進入下一步。
需人工修改：
核心成果仍可保留，但必須由人修正後才能使用。
失敗：
無法安全使用，或必須重新完成主要工作。
不要把「語氣微調」和「事實錯誤」混在一起
例如 AI 寫出的回覆：
內容完全正確，只是員工把一句比較正式的文字改得親切一點。
這種輕微風格調整，可以依公司規則仍算「可直接用」。
但如果修改的是：
- 價格。
- 日期。
- 退款條件。
- 商品規格。
- 客戶身份。
就不應該假裝只是文字潤飾。
因為真正被修正的是工作內容。
最容易犯的錯：只標「成功」和「失敗」
很多系統只有兩種結果：
Success。
Failure。
但 AI 工作最麻煩的地方，往往正好位在中間。
系統成功執行。
模型也成功回答。
沒有發生程式錯誤。
可是員工還是花了五分鐘修改。
技術上它是 Success。
商業上卻不是完全可用。
所以「需人工修改」這個中間層非常重要。
先別急著加入十種分類
剛開始不要分成：
- 非常好。
- 很好。
- 普通。
- 稍微修改。
- 大量修改。
- 事實錯誤。
- 格式錯誤。
- 語氣錯誤。
- 完全失敗。
分類愈多，員工愈不想填。
第一週只留三個就夠：
可直接用、需人工修改、失敗。
真的發現某種錯誤大量出現，再增加更細的原因分類。
記錄完之後，第一個要看什麼？
不要先看 AI 一共跑幾千次。
先看三個比例：
- 可直接用比例。
- 需人工修改比例。
- 失敗比例。
然後再把它們和成本放在一起。
你可能會發現：
某個模型總帳單最低。
但「需人工修改」比例最高。
另一個模型價格稍高。
卻幾乎可以直接使用。
這時才有資料可以真正討論：
哪一個比較省。
再把模型版本一起留下來
Langfuse 可以用 Trace、Tag、版本與其他屬性區分不同工作與版本。
所以如果你今天修改 Prompt，最好不要把新舊結果混在一起。
例如：
- 客服 Prompt V1。
- 客服 Prompt V2。
各跑一段時間。
再比較：
- 成本有沒有下降。
- 直接可用比例有沒有增加。
- 失敗有沒有增加。
這比只問員工：
「你覺得新版有沒有比較好？」
可靠得多。
使用者按讚，也可以是一種 Score
Langfuse 也支援把使用者回饋連回 Trace。
例如：
- 讚。
- 倒讚。
- 星級。
- 其他產品內的回饋訊號。
但要注意：
使用者沒有按倒讚，不代表答案一定正確。
有些使用者根本不會留下回饋。
所以客服、財務、法律或其他重要工作，仍然可以保留公司自己的人工結果標記。
「可直接用」也不等於一定正確
這個分類衡量的是：
這次成果在你的工作流程中，有沒有被接受。
它不是事實查證證書。
如果員工自己也沒有發現錯誤，一份錯誤答案仍可能被標成可用。
所以高風險工作還是需要另外的：
- 資料查證。
- 規則檢查。
- 專業審核。
- 自動 Evaluation。
不要用一個 Score 解決所有問題。
這一步特別適合哪些工作？
- AI 客服。
- 商品文案。
- Email 草稿。
- 文件摘要。
- 資料分類。
- 報價草稿。
- 研究摘要。
- 程式輔助。
只要最後有人會決定：
「這份 AI 結果能不能用？」
就適合留下這個標記。
如果沒有 Langfuse，也能先做嗎？
可以。
今天教的真正方法不是一定要先安裝 Langfuse。
如果團隊還很小，可以先在：
- 試算表。
- 資料庫。
- 客服後台。
- 內部工具。
多加一個欄位。
固定記：
可直接用。
需人工修改。
失敗。
等 AI 工作量變大，再把這項結果正式接進 Langfuse。
可以直接交給工程師或 AI 的設定 Prompt
我要替目前的 AI 工作流程增加一個最簡單的成果品質標記。 請不要先建立複雜評分制度。 每一個完整 AI 工作結束後，只記錄一個 work_result。 只允許三種分類： 可直接用： 核心內容與重要事實不需要修改，可以直接進入下一個正式工作步驟。 需人工修改： 主要成果仍然可以保留，但必須由人修正重要內容後才能使用。 失敗： 成果不能安全使用，主要工作必須重新完成，或存在足以影響決策的錯誤。 如果目前系統已使用 Langfuse，請把這個結果設計成可以附加到完整 Trace 的 categorical Score。 另外保留： Trace 名稱、 模型版本、 Prompt 版本、 模型成本、 執行時間。 第一階段不要增加更多品質分類。 等累積至少一段真實使用資料後，再分析最常出現的修改與失敗原因。 最後請確認： 技術執行成功不能自動等於「可直接用」。 必須依照最後工作成果判斷。
一週後可以問哪三個問題？
第一：
哪種 AI 工作「需人工修改」比例最高？
這可能代表 Prompt、資料或模型需要改善。
第二：
哪個模型單次成本最低，但真正可直接使用的成果最少？
這可以避免只看 API 價格。
第三：
哪種工作已經幾乎都能直接使用？
這些才可能是最值得繼續擴大自動化的工作。
今天最容易犯的錯
很多團隊會建立非常完整的 AI 成本 Dashboard。
知道：
- 每天用了多少 Token。
- 哪個模型最貴。
- 哪個 Agent 跑最久。
卻漏掉最重要的一個欄位：
結果到底能不能用？
如果沒有這個資料，成本只是一半的答案。
你知道花多少。
卻不知道買回來的是什麼。
今天只需要記住一句話
每次 AI 工作結束後，不要只有：
「執行成功。」
再多記一個結果：
可直接用、需人工修改，還是失敗？
把這個結果和 Langfuse 記錄的成本放在一起。
你才開始看得到：
便宜模型是不是真的便宜。
昂貴模型是不是真的更值得。
哪一項 AI 工作真正開始成熟。
AI ROI 的第一步，不一定是先算一個很複雜的財務公式。
而是先知道：
每一筆 AI 成本，最後到底買回一份可以用的成果，還是一份等著人重新修改的工作。
今天，和 AI 一起進步一點。
每天學會一個 AI 技巧。
每天節省一點時間。
每天提升一點能力。
SasaDaily，陪你一起成長。
