#076🐝 黃琪婕｜能被驗證的東西，才會進步：從 AI Coding 到我們自己的判斷力

上一篇文章，我在回答一個這半年很常被問到的問題：「AI 每個禮拜都在變，今天大家在玩這個 Agent，過幾個月又換成另一套框架，我們到底該把時間投資在哪裡？」

我當時給自己的答案是，少追一點工具，多留下那些真正屬於自己的東西。工作流程、做過的決策、踩過的坑、一些你自己才知道的判斷依據，把這些慢慢整理成 AI 也能讀的 Memory。模型會換、框架會換，但這些脈絡可以一直帶著走。

這幾個月我也一直照這個方向在實作，尤其從 OpenClaw 那波開始，Agent 已經慢慢從「陪我聊天的 AI」，變成真的可以接工作的人。以前我會自己查資料、自己整理、自己寫第一版，現在有愈來愈多事情，我已經習慣先丟給 Agent 跑。

但用久之後，我碰到另一個問題，這幾個月最多人問我的不是「AI 做不好」，而是：

「它做出來了，看起來也蠻完整的，可是我不敢直接用，我還是得整份重看一遍。」

時間沒省下來，只是從「自己做」變成「自己檢查」。而且愈是對外的東西，愈需要有人在迴圈裡看著，你就愈不敢放手讓 Agent 自己跑完。一旦不能自動化，它能幫你省下的那點時間，其實也就不剩多少了。

我一開始以為這是 Memory 不夠，所以我又餵了更多背景、寫了更多規則、把脈絡整理得更細，結果沒有太大的改善。最有感的是我做 Manager Agent 那陣子，為了讓它能真的接手事情，我把能寫的都寫了。團隊的分工、專案的脈絡、我們慣用的判斷方式、哪些事情要先問過我。它做出來的東西，光看格式跟結構是挑不出毛病的。但每次要真的拿去用之前，我還是會整份重看。後來我才發現，我在檢查的東西，跟我寫進 context 的東西根本不是同一組。我寫進去的是「該怎麼做」，我檢查的是「這樣到底算不算做好了」。而後面那件事，我很少寫下來過。

剛好微軟今年在 Build 上發表 Agent Memory 相關功能的時候，講了一句剛好可以呼應這個狀況：

有些 agent 知道正確的事實，卻還是把任務做壞了，因為它沒有執行正確的流程。

其實是一樣的道理，我們的 Agent 知道所有的背景知識，卻不知道我們的「驗收標準」。我一直在補的是「它知道什麼」，但卡住的地方其實是「它不知道怎麼驗證結果」。這是個很大的問題，因為如果 Agent 不知道怎麼驗證結果，它就不會知道這次做出來的東西到底算不算及格，自然也沒辦法從回饋中學習。

這讓我突然意識到，以前知道要幫 Agent 建立 Memory，也知道生出來的東西需要自己檢查並更新，但我一直沒把這兩件事連在一起。我以為 Memory 就像個資料庫，把背景資料存進去就好。但如果沒有「驗收標準」，Agent 就不會知道這次做得及不及格，自然也生不出回饋，那 Memory 就永遠只會停在最初的狀態，沒辦法從錯誤中學習。

所以，一個會進步的 Memory 應該要分成兩塊：

• 一塊是它一開始記得什麼
• 另一塊是它之後怎麼繼續長

上一篇主要在講前面那一塊，這一篇則想跟大家聊聊後面這件事。而 Memory 如果要能持續成長，驅動力其實來自源頭那一步： 你得先把腦袋裡的「驗收標準」抽出來，系統才知道這次到底做得對不對。

我花了不少時間思考這個議題，直到最近看李開復的《AI 未來已來》，裡面剛好有一段讓我很有啟發。李開復問了一個問題：「為什麼在這一波 AI 發展裡，AI Coding 這麼早爆發，而且成為現在各家最激烈的競爭戰場？」

為什麼偏偏是程式設計呢？他的答案裡有一個很重要的關鍵：因為 Code 可以被驗證。

這句話乍看很簡單，但我後來愈想愈覺得，它背後講的事情其實遠遠超過了寫程式本身。

1. Code 有一個其他工作很羨慕的東西：Feedback

現在用 Claude Code、Codex 這類 Coding Agent，大家應該都很熟悉它們的工作模式。這整個流程其實就是讓 Agent 先試著寫一段 Code，接著跑 Test 看有沒有過。如果有錯，它就自己去讀 Error log 並修改，然後再重新跑一次，直到完全通過為止。

整個流程可以一直循環：Action → Result → Feedback → Update

而且它的 Feedback 品質非常高，Compiler 不會因為今天心情不好，就跟你說這段 Code「感覺怪怪的」，Test Pass 就是 Pass；Fail 就是 Fail；效能要求 500ms，跑出來 800ms，也不用開會討論大家的感受。所以 Agent 可以瘋狂試。錯十次、二十次都沒關係，因為每一次錯誤之後，它都很快知道自己到底哪裡沒達標。這也是為什麼 RLVR（Reinforcement Learning with Verifiable Rewards）這類方法，在數學跟 Coding 特別有發揮空間。只要系統能給出一個相對可靠的 reward signal，模型就有機會大量探索，再根據結果持續修正。

所以回頭看李開復那句話，它背後真正在講的其實是： Coding 本身就是一個非常會教 AI 的環境。 它提供了密集、快速，而且大部分時候相對客觀的 Feedback，這個條件在其他情境下非常奢侈。

其實，如果你把視角從軟體圈拉遠一點，會發現這種「做錯了立刻被糾正」的機制，剛好可以解釋另一個這幾年大家很愛聊、但常常只看到表面原因的話題。

2. 物理世界本來就自帶一台「檢查機器」

這幾年講到哪些工作不會被 AI 取代，最常聽到的說法是那些需要精細動作的工作，例如水電工、按摩師、外科醫生。理由通常是 AI 沒有手，做不到人類那麼細膩的操作。我覺得這個說法只講對一半，水電工難被取代，還有一個容易被忽略的原因，就是物理世界自帶一台檢查機器。

在實體世界裡，管線接錯了就是會直接漏水；螺絲沒鎖緊，東西就會掉下來；而要是牆面沒抓平，你只要退兩步看就能立刻看得出來。做錯了，這個世界會直接用物理法則告訴你。而且回饋的速度極快，判斷標準也完全沒有模糊空間，畢竟漏水就是漏水，不會有人開會爭論「這到底算不算漏水」。

Compiler 其實是同一種東西的軟體版本。工程師花了三十年，一層一層幫自己蓋出 test、CI、type check 這些東西，本來只是想讓自己晚上睡得著覺，結果它們變成了 AI 很好的訓練場。

現在換到我們大部分人的那一側。一份數字是編出來的市場分析，跟一份數字是真的市場分析，攤在螢幕上長得一模一樣。字體一樣、結構一樣、語氣一樣專業，連自信程度都一樣。你要花上跟寫它差不多的力氣，才能知道它到底對不對。這裡沒有那台檢查機器，錯誤不會自己現形，所有的檢查都得有人花時間去做。所以真正造成差距的原因，可能不在「AI 會不會做」，而是在「錯了看不看得出來」。

3. 這幾年的 XX Engineering，其實都在補同一件事

既然軟體與知識工作沒有物理世界那台「內建的檢查機器」，那我們就得自己想辦法造一台。想到這裡之後，我回頭看這幾年做 AI Engineering 的方式，發現它們的發展軌跡驚人地一致。

最早大家瘋 Prompt Engineering，表面上是在研究一句話怎麼寫，實際上做的是先隨手寫一個版本去跑跑看，發現結果不如預期後再回來微調。人其實一直坐在一個 Feedback Loop 裡面，只是那時候的 Evaluator 是我們自己。後來連這件事也被自動化了，你先定義好 Task 跟評分方式，工具自己去測不同版本，人的位置往外移了一層。

而這一兩年 AI 圈一直冒出新的「XX Engineering」，我把它們排在一起看，發現底下其實是同一條線。

• Prompt Engineering 在問：我要怎麼把意圖說清楚？
• Context Engineering 往前一步：AI 做這件事的時候，到底需要知道什麼？
• Loop Engineering 開始問：它做完之後，怎麼知道要繼續、重做，還是停止？
• Graph Engineering 把問題擴大：當工作變複雜，誰執行、誰檢查、失敗要回哪裡、什麼時候需要找人？

順帶一提，Graph Engineering 冒出來的時候，連 LangChain 自己寫文章都吐槽這大概又是 AI content factory 最新生出來的 buzzword。我覺得這個吐槽滿有道理，但這些詞會一直冒出來這件事本身，就說明了大家碰到的問題確實愈來愈往後面那幾層跑。這些名字雖然一直換，但底層的邏輯愈來愈清楚：我們必須把原本存在人腦裡的「完成」、「正確」、「夠好」，慢慢變成系統可以觀察的東西。

OpenAI 今年分享他們怎麼用 Codex 開發一個幾乎零人工寫 Code 的產品時，講了一個我很喜歡的描述。他們說工程師的工作慢慢變成：設計環境、明確表達 Intent，以及建立 Feedback Loops。 因為寫 Code 已經不是最大的問題了。Agent 執行愈便宜，定義問題的成本反而開始浮上來。 以前需求模糊一點沒關係，工程師做到一半可以走過來問一句「欸，你這邊到底是什麼意思？」現在你丟一句很模糊的要求給 Agent，它可能十分鐘後很認真地幫你做完一整套錯的東西。

4. 企業導入 AI 的痛點：驗得起，才敢放

前面講的都是技術圈的事，但我覺得這件事在公司裡的版本，更值得企業端的朋友想一下。這一兩年企業導入 AI，最先上線的幾乎都是同一批東西，像是會議紀要、內部知識問答、客服第一線、招募的履歷初篩。而定價、風控、供應鏈調度、產品方向，這些真正會動到財報的事情，幾乎沒有人敢碰。一般的解釋是資料還沒整理好、組織有阻力、法遵過不了。我覺得這些都對，但可能都不是最底層的原因。

最底層的原因是，前面那批事情的檢查成本與風險趨近於零，後面那批高到沒有人敢簽字。 像是會議紀要寫錯了，讀的人自己看一眼就會發現；如果是客服答錯，客戶當場就會抱怨。這些場景本身就自帶回饋迴路，你幾乎不用額外花力氣去查。但定價調錯了呢？可能要一整季報表出來，才會發現某條產品線的毛利被吃掉了。而那時候追不追得回來，已經是另一回事。

所以企業並非不想把 AI 放到有價值的地方，而是不敢。MIT 前陣子有份被引用到爛掉的報告，說九成五的企業 AI 專案帶不出可衡量的損益貢獻。這個數字大家都在轉，但我覺得比數字更值得問的是，為什麼會這麼一致？300 家公司，不同產業、不同規模、不同顧問，最後全都停在同一側。因為大家其實用的是同一把尺，只是沒人把它講出來：我驗得起的地方，我才敢放。

這句話我自己蠻常拿來提醒自己，你把 AI 放在哪裡，反映的可能不是 AI 的能力邊界，而是你的驗證能力邊界。 如果你的 AI 到現在都還只在做一些無關痛癢的事，那件事可能跟模型沒什麼關係。

「那等之後模型變更強，我們是不是就不用檢查得這麼辛苦了？」

這大概是大家最常接的下一句，我自己也這樣期待過一陣子。但後來發現這條路走不通，原因有點反直覺，那就是模型越強，除錯成本反而越高。

因為模型愈強，它的錯誤就愈像對的。 弱一點的模型出錯，你一眼就看穿。它會講出明顯不存在的東西，數字離譜到你笑出來。強的模型不會這樣，它給你的東西邏輯自洽、格式工整、引用看起來也都有模有樣，只有某一個環節悄悄地錯了。而那個環節，往往正好是最關鍵的那一個。

前陣子我請 Agent 幫我補一段產業數字，它給的那句話語氣很篤定，還附了機構名稱跟年份。我差點就直接用了。後來隨手查一下，機構是真的，報告也是真的，但那個數字是另一份報告的，年份也差了一年。弱一點的模型會直接編一個不存在的機構，那種大家一眼就會擋掉；但強的模型是把三個真的東西拼成一句假的。

所以隨著模型變強，「產出」的成本一路往下掉，但「檢查」的成本沒有跟著掉。這個缺口是跟著能力一起長大的，等下去只會愈等愈寬。

5. 回到個人：為什麼我們的工作環境不適合學習？

看懂了企業為什麼不敢放手，其實也就看懂了我們自己的瓶頸。這裡才是我看完李開復的書後，最先反思的地方。如果「精確而可驗證的 Feedback」可以讓 AI 這麼快進步，那我們自己的工作呢？老實說，大部分人的工作環境超級不適合學習。你今天做了一個產品決策，如果三個月後數字表現不好，你其實很難分辨到底是因為產品方向錯了、執行沒到位、行銷沒做好，還是單純只是運氣不好。沒有人會跳出一個 Error log 跟你說：「決策錯誤：你高估了使用者的付費意願」。

如果有這種東西，創業應該簡單很多，同理，寫文章也一樣。Code 至少有 Test，但文章沒有。一篇文章資訊全部正確、文法正常、SEO 也做了，最後還是可能很無聊。你只會有一種很模糊的感覺：「嗯……這個不太行。」我後來歸納出三個問題，用來判斷一件事的回饋環境好不好，還蠻好用的。

第一，做錯了多久會被發現？ 幾秒鐘，還是三個月？ 第二，什麼叫做好，誰說了算？ 有沒有一個大家都認的標準，還是十個人看有十種意見？ 第三，這次做得好，是實力還是運氣？ 如果結果跟做法的關聯很鬆，那驗出來的東西參考價值也有限。

你今天叫 AI 寫程式：幾秒鐘、機器說了算、測試過了就是過了，三題全中；但換成「做一個產品決策」：要幾個月、每個人標準都不一樣、運氣至少佔一半，三題全滅。這也就是為什麼有些領域的人可以很快練起來，有些領域練十年還是很吃天分。

6. 很多我們叫做「判斷力」的東西，其實是過去的 Feedback

既然大部分工作環境的回饋都很慢、很模糊，那那些所謂「很敏銳、很有 sense」的資深前輩到底是怎麼練出來的？

以一個做產品做很久的人為例，User 跟他說：「這個功能我超喜歡！你們上線我一定用。」他心裡可能已經默默打折。但第一次創業的人可能真的會開心三天。差別在哪？資深的那個人以前可能已經聽過很多次類似的話。他很清楚 User 嘴上說喜歡，但真的做出來往往卻沒有人要用。每經歷一次這種狀況，他心裡就會默默再驗證一次原本的假設。

慢慢地，他的大腦其實已經把 Decision → Outcome → Feedback 的過程跑過很多輪了。最後那些經驗被壓縮成一種「sense」。所以有時候你問一個很資深的人：「你為什麼覺得這方向不對？」他可能真的答不太出來，只會說：「就……感覺不太對。」我們會把這個叫 intuition、taste、judgment、經驗，但它背後其實可能跑過非常多次 Feedback Loop。

順著這個 Feedback Loop 往下想，這是我最近覺得最有意思的一層：判斷力的差異，其實來自你「選擇記下什麼」。

同樣兩個人，在同一家公司、經歷差不多的事情，最後長出來的判斷可能完全不一樣，因為他們選擇記住的東西不同。一個人每次專門記失敗、記風險、記哪個地方當初被高估了。另一個人專門記那些反常的成功，記誰打破了規則還活得好好的。五年後，一個變得很會踩煞車，一個變得很會找機會。他們的差別不在個性，在記法。

我覺得這件事放到 Agent 上更明顯。你可以給兩隻 Agent 完全一樣的資料，但只要一隻總是在記失敗案例、另一隻總是在記異常成功，半年後它們的判斷方式會完全不同。沒有人幫它們寫不同的個性設定，那個差異是從記法長出來的。 這也是我現在覺得「經驗」很值得重新思考的一個地方。工作十年，不一定代表跑了十年的 Learning Loop。如果每次事情做完都直接往下一件走，從來沒回頭看結果，也沒更新自己原本的假設，那很可能只是把同一年的經驗重複了十遍。

7. 交辦給 Agent，反而逼出了我們腦袋裡的隱性判準

就像這幾個月我自己用 Agent 時，最常出現的對話往往是我單方面打槍它。我會嫌它產出的這版不行、內容寫得太 generic，或者覺得這張圖怪怪的，最後直接叫它重來。以前我自己做事情的時候，這些判斷其實都默默藏在執行過程裡。文章寫到一半覺得語氣怪怪的，我自己順手改掉就好；簡報兩頁邏輯接不起來，我自己拉一下位置排版；Code 的架構開始歪掉，我就直接重構。在這些過程中，根本不需要有人知道我為什麼這樣做。

現在工作慢慢交出去之後，我才發現原來我腦袋裡有一大堆從來沒被說清楚的規則。 Agent 很像一個很煩的新同事，每次你跟它說「這個不對」，它下一次還是照樣犯錯，被逼到最後你只好開始反問自己：「好啦，到底為什麼不對？」但這個過程其實滿有價值的。因為很多原本只是「感覺」的東西，就是在這時候第一次被你說出來。

既然知道有這些隱性規則，為什麼一定要等到「否決」的時候才寫得出來？直接坐下來把規則寫一寫不行嗎？我試過，不太行。因為直接寫的是你以為的判準，被逼著否決的時候寫的才是你實際在用的判準。 你叫一個很資深的人寫下他怎麼判斷，他大概會寫出一套教科書版本。但你丟一份東西給他挑毛病，他挑出來的才是真的。上一篇講的那個默會知識，卡的就是這裡，你知道的永遠比你講得出來的多。所以我現在會把 Agent 看成一個抽取器，它先產出一個東西，你才有東西可以否決，而那個否決的瞬間，才是你腦袋裡那條規則第一次現形。

8. Memory 不能只有決策，還要把 Feedback 接回去

這也接回上一篇講的 Memory。之前我會覺得，把 Decision 留下來很重要。例如：「2026 年 8 月，我最後決定先做 B，不做 A。」現在我會覺得這還少了一大塊。真正有意思的記錄應該長這樣：

當時 A、B 都可以做，我因為 X 選了 B。三個月後 Outcome 是 Y。回頭看，原本對 X 的判斷只有一半成立，真正影響結果的是 Z。

這三段串起來之後，才開始有「經驗」的樣子。Decision → Outcome → Feedback。Memory 如果只存前半段，它比較像歷史紀錄；把 Feedback 接回去，才會開始學習。

但這衍生出另一個常被忽略的盲點：存下來的記憶也是會過期的。 你那份寫了半年的工作筆記，或那個一直在長的 CLAUDE.md，裡面有多少條其實已經不成立了？有些是團隊換了做法，有些是客戶換了窗口，有些單純是你自己後來想法變了。但它們還躺在那裡，而且 AI 每次都很認真地照著做。

這也是為什麼我現在覺得，Memory 不能只有「寫進去」這個動作，它還要能被推翻、能過期、能被新的結果改掉。我自己在做 Agent Memory，也愈來愈在意這件事。怎麼存資料其實沒有想像中難，真正麻煩的是哪些東西值得留下、哪些應該被淘汰，以及事情發生一段時間之後，我們有沒有辦法把結果重新接回當初的判斷。這邊我也還在研究。

9. 那接下來半年，我們可以做什麼？

如果上一篇我給自己的功課是建立 Memory，這篇我會再多加一個：替自己的工作建立好一點的 Feedback Loop。 不用突然把生活變成 OKR Dashboard，也不用每個決策都算一個 Score，我自己現在從三件小事開始。

A. 交工作給 Agent 前，多問一句「怎樣算完成？」

「幫我研究這個市場」很容易講，難的是研究到什麼程度，我才敢拿它來做決策？來源需要哪些？哪些問題沒回答就不能下結論？什麼條件出現時，Agent 應該停止猜測、回來問我？我現在習慣在丟出去之前，先寫三條「這樣就算過」。比如要一份競品分析，就先寫：每個數字都要有出處、要涵蓋這五家、每一家都要提到定價模式。五分鐘的事，但它把驗收從一場辯論，變成一次清點。

還有一個小細節我覺得很好用，判斷盡量用「過 / 不過」，不要用一到五分。 五分制聽起來比較細緻，實際上很難用。你永遠說不清楚三分跟四分差在哪。過或不過就很清楚，不過的話，就會逼你講出到底哪一條沒滿足。

B. 每次否決 AI，不要只留下最後答案

今天 AI 給我三個方向，我選 B。B 本身當然可以記，但 A 為什麼被我丟掉，可能更有價值。因為太 generic？沒有 Evidence？不符合現在公司的階段？還是單純我不想做這種公司？這些東西慢慢累積起來，就是你自己的判斷依據。而且很有趣的是，寫個二三十次之後你回頭看，會發現這些理由不是沒關聯的。它們會自己聚成幾類，來來回回都是那幾種錯，那幾類就是你的驗收標準。

舉個例子，這幾個月我用 Agent 研究許多東西。退回的理由累積下來，回頭發現都是那幾類：太像讀書心得，一直在講別人說了什麼，沒有變成我自己的理解；整段只靠一個來源撐著，沒有第二個獨立的佐證；引用看起來很完整，但出處我根本沒查過。一開始我以為是 Agent 不夠聰明。後來才發現，這三句其實就是我對「一份研究可不可信」的驗收標準，只是我從來沒把它寫下來過，所以每次都得重新用嘴巴講一遍。

現在寫下來之後，它還是會犯錯，但至少我下次丟任務的時候會先講清楚，而不是等它做完了再來吵。

這裡其實也回到前面講的那件事，你選擇記「最後選了什麼」，還是記「為什麼把其他的丟掉」，長期下來會讓你變成不太一樣的判斷者。 前者累積的是結論，後者累積的是判準。

C. 重要決策過一段時間後，真的回來看一次

這個我自己也做得很差。做 Decision Log 很爽，會有一種「我是一個很理性的人」的錯覺。三個月後完全沒回去看，前面那堆其實就只是日記。真正有價值的是：當初相信什麼？結果發生什麼？哪個假設錯？下次碰到類似情況，我會改什麼？Loop 要關起來，才真的有 Feedback。

這三件事其實是同一個環

這三件小事單獨看都很普通，但它們其實是接起來的。你先寫下三條「這樣就算過」，AI 做完之後你拿那三條去對，結果它三條都過了，你卻還是不想用。那就代表你的標準漏了一條。把漏掉的補上去，下次丟任務的時候，你手上就是四條。再過三個月回頭看那份清單，你會發現有幾條已經不需要了。可能是 AI 現在自己就會做，也可能是你們的做法早就變了。那就把它刪掉。

這個環轉一圈，你的標準就準一點，轉一年，它就變成一份別人抄不走的東西。 而這其實就是我前面說的「記憶怎麼繼續長」，落到日常裡的具體樣子。它不會只是一直往上疊。該補的補，該改的改，也要捨得刪，一份只會愈變愈長、從來不會變短的筆記，通常代表那個環根本沒有在轉。

10. 這件事只能你來，沒辦法外包

講到要自己花力氣去轉動這個環，很多人可能會有個偷懶的念頭：現在工具這麼多，我是不是直接去下載別人寫好的 Agent 或 Prompt 來用就好了？連標準都不用自己建。

今年確實有幾家大廠把 Agent 的能力包裝格式標準化了，你現在可以直接下載別人寫好的 Skill 來用，理論上很方便。但有人抽樣了三萬多個公開的 Skill，大約四分之一被驗出有問題。 更麻煩的是，同一份東西換一代模型，行為可能就不一樣。所以就算有人幫你認證過，那個認證的有效期也很短。

我覺得這件事對個人跟企業都是一個提醒。未來很可能會出現「下載別人養好的 Agent」這種事，甚至有人在想這會不會變成一個市場，技術上其實已經快到了。但真正難的不是打包，是你怎麼知道那份東西好不好。 所以驗證這件事，最後大概還是得在自己的環境裡做一次。這聽起來像壞消息，因為代表沒有人能幫你省掉這段。但反過來想也是好消息，你累積的那份標準，別人真的抄不走。 這點對企業來說也是一樣。當大家都能買到一樣的模型、下載到一樣的 Skill 時，企業內部有沒有那些別人無法獲取的真實資料與驗證標準，才是未來真正的護城河。

11. 有些事情就是驗不了，那可能反而是好消息

前面把「驗證標準」講得像是絕對的護城河，寫到這裡，好像整篇文章都在無腦推銷「凡事都要驗證」。所以我得誠實講一下這套東西的邊界。

先講一個比較實際的做法是不要追求完美的驗證，追求「只驗一部分，但驗到的那部分跟品質高度相關」。 你沒辦法驗出一份提案好不好，那牽涉太多主觀判斷。但你可以驗出每個數字有沒有來源、有沒有漏掉那三個一定要提的風險、客戶名字有沒有拼錯。這幾條擋不掉一份平庸的提案，但能擋掉八成會讓你丟臉的狀況。我覺得大部分人卡在這裡，是因為想一步到位，想不出完美的標準，乾脆就不寫了。

不過確實有一些事情，是真的驗不了的。要不要接這個案子、要不要留這個人、這個方向該不該轉。沒有標準答案，沒有快速回饋，樣本數還只有一次，你做完了，然後永遠不會知道另外一條路會怎麼樣。而我也不覺得所有東西都應該被硬塞成 KPI，亂選 Reward 最後只會讓 Agent 很認真地幫你把錯的指標做到滿分。

但這反而讓分工變得相對清楚，把驗得出來的，慢慢交出去；驗不出來的，先留給自己。 問題是現在大部分人的狀況剛好倒過來，驗得出來的自己做，驗不出來的也自己做，因為根本沒分過。

12. 能被驗證的東西，才會進步

把驗得出來的事情交出去，不只是為了省時間，更是為了讓系統跟自己都能繼續往前走。這也讓我重新思考文章開頭提到的那個問題：為什麼 AI Coding 先爆發？因為 Code 天生有很好的 Feedback。這個答案我一開始只把它當成一個 AI 技術觀察，後來愈想愈覺得，它在講的其實是一件更普遍發生的事：能被驗證的東西，才會進步。 Code 是這樣，Agent 是這樣，人也是這樣。反過來說，那些長期沒有人驗、也驗不出來的地方，不管你在裡面待了幾年，都有可能只是在原地跑。

上一篇我在講的是，把你腦袋裡的東西存下來，讓 AI 記得。這一篇想講的是後面那一半，我自己最大的轉變是現在不太把 Memory 當成一個資料庫了，它比較像一個要養的東西。 資料庫存進去就沒事了，養的東西要餵、要修、要淘汰，而且你一段時間不管它，它就會壞掉。至於餵它的是什麼，就是每一次你判斷「這個不對」的那個瞬間。

如果建立 Memory 是第一步，那下一步，我會強烈建議你加上這個小習慣：在丟任務給 AI 之前，先花五分鐘寫下三條「這樣就算過」。第一次寫，你大概會覺得卡卡的、寫不太出來，我一開始也是。但那個卡住的瞬間，其實正是最有價值的時候。因為寫不出「怎樣算完成」，往往代表我們自己也還沒想清楚到底要什麼。以前我們自己動手做，可以一邊做一邊想，很多判斷就這樣含糊地混過去了。但現在，當我們試圖把工作交給 AI 時，那些曾經的含糊，全都會變成一份看起來很完整、但你根本不敢用的產出。

AI 就像一面鏡子，它不只反映了技術的進步，更誠實地照出了我們專業裡的模糊地帶，但正因為它能逼著我們釐清這些盲點，所以放心把工作交給 AI 去跑吧！這是時代給我們的饋贈，但別忘了，那把名為「判斷力」的尺，永遠要握在自己手裡。

ChiChi Huang 為 AILogora 與 Cairn 創辦人及生成式 AI 工程師，近期成功入選錄取率僅 2.4% 的 Anthropic 全球 Hackathon。她專注於 AI Agent 協作與知識管理系統，致力打造 AI Native 公司，其創業產品與觀點曾獲公視及非凡新聞報導。