---
title: 你的 AI 報價助手為什麼越用越歪？關鍵在反饋
lang: en
source: https://mindsprt.dev/en/knowledge/effective-feedback-compute-agent-deliberate-practice/
---

# 你的 AI 報價助手為什麼越用越歪？關鍵在反饋

*產業洞察 · 7 min read · 2026-06-05*

> 很多印刷廠把 AI 客服、自動報價接上去就放著跑，半年後發現它沒變聰明，只是更會犯同樣的錯。一篇談 Effective Feedback Compute 的論文點破了原因，也給了印刷現場一條把 AI 越養越準的路

**Quick answer:** 很多印刷廠把 AI 客服、自動報價接上去就放著跑，半年後發現它沒變聰明，只是更會犯同樣的錯。一篇談 Effective Feedback Compute 的論文點破了原因，也給了印刷現場一條把 AI 越養越準的路

## 為什麼 AI 工具接上去半年，效果反而停滯？

我這一兩個月跑客戶，遇到好幾家中小印刷廠的老闆問同一件事：去年導入的 AI 報價助手、自動回 LINE 的客服機器人，當初試用很驚艷，怎麼用到現在感覺沒進步，有時還越錯越離譜

這個現象，最近一篇叫《Scaling Laws for Agent Harnesses via Effective Feedback Compute》的論文講得很透徹，作者群是 Xuanliang Zhang 等人，原文我看的是 Wisely Chen 的中文整理

它直接量化一件反直覺的事：你以為「多給算力、多掛工具、多跑幾次」AI 就會變強，其實沒有

論文用 raw tokens 跟 tool calls 去解釋任務成功率，相關係數 R² 只有：

・0.33 到

・0.42

翻成印刷現場的白話：你把 AI 客服的對話紀錄開到最詳細、把報價重算次數從一次加到三次、再多串兩個資料庫進去，這些「我做了很多」的動作，大概只能解釋三四成的成果，剩下六成跟你燒多少資源無關

我把這個對照到帶學徒。一個師傅讓學徒一天印兩百張練習稿，但印完從不挑毛病、不講哪裡套色歪了，這學徒印一萬張也還是那個水準。他不是更厲害了，他只是更累了

## EFC 到底是什麼？跟「帶師傅」有什麼關係？

論文的核心概念叫 Effective Feedback Compute，簡稱 EFC。意思是：不是所有的互動都算數，只有「有效的反饋」才能讓 AI 真的進步

它定義有效反饋要同時滿足四個條件，我用印刷的場景一條條對：

・Informative（要有料）：反饋帶來新訊息。客戶嫌報價貴，但沒講是貴在紙還是後加工，這種就是廢話反饋

・Valid（要正確）：反饋可信，不是雜訊或瞎猜。業務隨口記「這客人不在乎價格」結果根本記反了，這種錯誤反饋餵進去比不餵更糟

・Non-redundant（不重複）：別把已經知道的再講一遍。系統記了一百次「客戶要 100 磅銅版」其實沒有新資訊

・Retained（要被用上）：這條最狠。反饋真的進到下一次決策了嗎？業務在群組講了正確判斷，但沒人整理進報價邏輯，那等於沒講

最關鍵的數字在這裡：論文做了一個對照實驗，在算力預算完全不變的前提下，只去提升反饋的品質，任務成功率從 27% 拉到 90%

成本一毛沒多花，只是把反饋變有效，成功率跳了三倍多。重新換算後，解釋力 R² 從：

・0.33 一口氣衝到

・0.94 至

・0.99

這套說法，其實就是學習科學講了幾十年的「刻意練習」（deliberate practice）：反饋要具體、要正確、要進到下一次練習。練了不檢討、檢討了不改，等於沒練。AI 跟人一樣吃這套

## 印刷廠的 AI 報價、追單、客服，反饋閉環怎麼設計？

知道原理之後，問題變成：在印務流程裡，怎麼把這個閉環真的接起來。我給幾個可以這週就動手的做法

第一，先建一份「標準答案」對照表。找出過去半年最常報的二三十種品項，騎馬釘型錄、無線膠裝書、貼紙、紙盒，把正確的料號、紙、後加工、合理報價區間整理成一份 ground truth。AI 報的價跟這份對不上，你才有「對錯信號」可以校正，否則它報得歪你也不知道

第二，每次 AI 出錯都留紀錄，而且要記到根因。不是記「報錯了」，是記「它把 250 磅卡紙算成 200 磅」「忘了算上光的費用」。這對應的就是 Informative 那條，要具體到能行動

第三，把失敗案例定期回灌。每個月花一小時，拿這個月 AI 報歪、客服答錯的案例，去修它的提示詞或規則。這一步才是 Retained，反饋有沒有「閉合」就看這裡。飄過去的對話紀錄不算數，被整理、被改進規則，它才算數

第四，每加一個功能，先過 EFC 第四條。想多串一個工具、多開一個自動回覆，先問自己：它會不會真的改變 AI 下一次的判斷？如果不會，加了就是純燒錢、純增加維護負擔

對設計端也一樣。如果你用 AI 輔助出圖、改稿、寫提案，客戶每次的修改意見就是你的反饋訊號。把「客戶為什麼退這版」具體記下來，下次提案直接避開，你的命中率才會升；只把退稿檔丟著、不歸納原因，改一百版也還在原地

## 想導入 AI 記憶功能，要先裝一道閘門

有些廠商會推「AI 會記住你公司的習慣」這類記憶功能，聽起來很美。但論文這裡有個我很認同的提醒

記憶架構解決的是四條件裡最難的第四條「retain」，但它「只」解決記得住，不會幫你過濾前三條對不對、重不重複

換句話說，如果你把錯誤的、重複的、雜訊般的反饋也一股腦存進去，這些錯誤記憶會被反覆叫出來用，毒性比沒記憶還大。等於把「越錯越離譜」從單次，放大成永久

所以導入任何記憶功能，一定要配一道「寫入閘門」：這條資訊夠有料、夠可信、不重複嗎？過了再存。對印刷廠來說，就是別讓業務隨手記的、沒查證的客戶偏好，自動變成系統的「事實」

也要誠實講，這篇論文不是萬靈丹。那個：

・0.94 到

・0.99 的上限，用的是事後才知道答案的理想資訊（論文叫 Oracle-EFC)，真實系統做不到，所以那是理論天花板，不是你明天就拿得到的數字。而「反饋有沒有真的改變決策」這條，本身就難判斷。但即使打了這些折扣，核心方向我很買單

未來 AI 工具的競爭，不會是誰掛的功能多、誰的對話框長，而是誰能讓每一次反饋都真的被用上。好的 AI 助手，不是讓它多幹活，而是像個好師傅，讓它每幹一步都真的學到東西

## 重點整理

・多給 AI 算力跟工具，只能解釋三四成成果（R²：

・0.33

・0

・42)，剩下六成靠的是反饋品質

・算力不變、只把反饋變有效，成功率能從 27% 跳到 90%，差別在「練對」不在「練多」

・有效反饋要同時做到：有料、正確、不重複、被用上，缺第四條等於白練

・AI 記憶功能只解決「記得住」，不會幫你濾錯；沒裝寫入閘門，錯誤記憶比沒記憶更毒

・把 AI 報價、改稿的失敗案例每月回灌一次，才是讓它越跑越準的關鍵動作

## 延伸思考

對印刷廠跟設計工作室，真正的啟發不是「該不該導入 AI」，而是「導入後有沒有設計檢討機制」。多數人卡在第一步就停了，把工具接上去當成終點。建議從一件小事開始：選一個高頻場景，例如型錄報價或貼紙打樣詢問，先建一份三十項的標準答案表，再排一個每月一小時的回灌時段，專門拿 AI 答錯的案例去修規則。這個閉環跑順了，再考慮上記憶功能或擴大範圍。對做整合服務的廠商而言，這也是一個和客戶長期綁定的切口：你幫客戶把反饋閉環設計好，系統就會越用越貼合他的需求，而不是用半年就被嫌不準丟掉

## 延伸閱讀

・[Agent 也需要「及時反饋」：Effective Feedback Compute 與 Agent 的 deliberate practice](https://ai-coding.wiselychen.com/agent-harness-effective-feedback-compute/)

## FAQ

### AI 報價系統用久了反而越來越不準，是什麼原因？

通常不是模型能力問題，而是缺少反饋閉環。AI 每次報價後若沒有明確的對錯信號回饋，也沒人定期拿錯誤案例去修正規則，它就會把同樣的錯誤判斷一直重複，甚至放大

### 什麼是 Effective Feedback Compute(EFC)?

EFC 是一個衡量 AI 反饋品質的概念，指只有同時做到「有料、正確、不重複、被真正用上」四個條件的反饋才算有效。論文證明，算力不變的情況下只提升反饋品質，任務成功率能從 27% 提升到 90%

### 中小印刷廠想讓 AI 工具越用越準，第一步該做什麼？

先建一份標準答案對照表，把最常報的二三十種品項的正確料號、用紙、後加工、合理報價整理出來。有了這份 ground truth,AI 報歪時你才能發現並校正，這是建立反饋閉環的起點

### AI 的「記憶」功能值得導入嗎？

值得，但必須配一道寫入閘門。記憶功能只能解決「記得住」，不會幫你過濾錯誤或重複的資訊。若把雜訊跟錯誤判斷也存進去，這些錯誤記憶會被反覆使用，反而比沒有記憶更糟

### 設計師用 AI 輔助改稿，怎麼讓它越來越懂客戶？

把客戶每次退稿的具體原因記下來並歸納，下次提案直接避開，命中率才會提升。只把退稿檔案丟著不分析原因，改再多版也是在原地空轉，這就是反饋有沒有閉合的差別


---

> HTML version: https://mindsprt.dev/en/knowledge/effective-feedback-compute-agent-deliberate-practice/
> MINDS — 麥思印刷整合有限公司 · https://mindsprt.dev
