流程知識 (Process Knowledge)
AI 時代不可忽略的關鍵
上週，我透過應用 AI 順利地解掉了一個，過去我總是覺得頗困難、傾向直接放棄的 bug 。而這件事讓我重新思考了「與 AI 協作」一事。
公司有一個 Clojure 寫成的 web application 的專案，由於它會被布署到 GCP 上，所以它的建置流程相對複雜，最後的產出物不是單純的 jar 檔，而是 docker image 檔。建置流程通常都由我的同事處理完，也因此這一塊我極度不熟悉。基於某些原因，建置流程壞掉了，所以我開發完新的功能，卻無法布署 (deploy)。
由於上週四就是我在前公司的最後一天，離職前我希望畫下一個完美的句點，我決定挑戰一下建置流程的 bug 。
首先，我把終端機丟出的錯誤訊息給 AI ，請它幫忙。
${情境描述}
${錯誤訊息}
你覺得可能原因為何？下一個線索上哪找？其中，錯誤訊息裡的關鍵成分是：
Execution error (IllegalArgumentException) at juxt.pack.jib/make-builtin-layers$fn (jib.clj:145).
No matching clause: AI 答曰：
問題在 juxt.pack.jib/make-builtin-layers 的第 145 行，在處理某個 layer 時的 case 或 cond 陳述式失敗了。
解決方案：${錯的解法}我認為 AI 對錯誤訊息的解釋合理，但是解法不對，所以我再補了一個 prompt
是否有什麼方法，可以更加精確的定位問題，再來想解法？AI 答曰：
修改 release.clj 的 ${某處}，將 ${變數內容} 印出。然後，我就搞懂了問題，並且自己想出了合理的解法。
對除錯流程的反思
回顧這個過程，我發現一個有趣的分工模式：
AI 提供了大量的內容知識 (content knowledge)：錯誤訊息的可能意涵、Clojure 的語法細節 (哪些語法可以產生特定的錯誤訊息)、建置工具的運作方式。這些都是我不熟悉的領域，如果要自己從頭查資料，可能要花上 1~2 小時，同時，極度消耗我的專注力。
但整個除錯的流程知識 (process knowledge)，卻完全是由我掌控的：我知道該問什麼問題、如何判斷 AI 的答案是否合理、下一步該往哪個方向探索、什麼時候該停止依賴 AI 自己動手。
更重要的是，當 AI 給出「錯的解法」時，我能立刻察覺。不是因為我懂 Clojure 建置流程的細節，而是因為我懂除錯的流程：「在還沒精確定位問題前，不該急著套用解法」。
這讓我反問自己一個問題：「在 AI 時代，什麼樣的知識變得更重要了？」
Process Knowledge vs. Content Knowledge
用語言學習來比喻的話，process knowledge 就像文法，content knowledge 就像單字。
語言專家會說：「文法有限，很快就學完了；單字無邊無際，學不完。」但對還不會的人來講，文法卻非常難學，比單字難學得多。
為什麼？因為文法是抽象的、系統性的、需要理解「為什麼這樣說」的規則。單字是具體的，不懂就查，查了就記得（至少暫時記得）。
但文法一旦掌握了，就可以活用語言。單字再多，沒有文法，也組不出有意義的話。
軟體開發的 process knowledge 也是如此。它往往是關於：如何診斷問題、設計實驗、決策 。這些知識數量有限，但極度抽象，而且高度依賴情境和經驗。更糟的是，它們大多是隱性知識 (tacit knowledge)，連擁有它的專家都很難明確說出「我是怎麼做的」。
反觀 content knowledge：這個錯誤訊息代表什麼、這個 API 怎麼用、這個產業的標準做法是什麼。這些知識無邊無際，但只要連上網際網路，通常都可以查得到。
AI 真的學到 Process 了嗎？
這帶出一個關鍵問題：當我們說 AI「很厲害」時，它到底學到了什麼？
LLM (大型語言模型) 的訓練過程，本質上是從海量文本中學習「在這種情境下，通常接下來會出現什麼」。它建立的是一個龐大的 pattern library，記錄著無數的「情境/回應」配對。
這讓它在提供 content knowledge 上表現驚人。你問它一個技術問題，它能從訓練資料中找到相似的模式，給你看起來很合理的答案。
但它真的掌握了 process knowledge 嗎？
讓我們看一個對比：AlphaGo。
AlphaGo 是透過「在真實的圍棋世界中無限地搜尋 (解決方案) 與學習 (不同解法的後果)」來掌握圍棋的。它下了數百萬盤棋，每一步都得到即時的、明確的回饋（這步棋好或不好）。它不只是記住「在這種棋型下人類通常怎麼下」，它是真正在探索「什麼策略會贏」。
這種訓練法可以訓練出連人類都無法掌握的 process knowledge。
但 LLM 沒有這樣的學習機制。它沒有在真實世界中試錯、沒有得到明確的成功/失敗回饋、沒有機會驗證「這個流程是否真的有效」。
它只是看過很多人在類似情況下怎麼做，然後記住了這些 patterns。
這意味著：
LLM 可以告訴你「下一步這樣做機率」最高，但不能保証「抵達終點的機率」最高
它可以在訓練資料覆蓋的範圍內表現很好，但遇到真正新的情境就可能失效。
回到我的除錯經驗：AI 給我的第一個解法為什麼是錯的？因為它只是從訓練資料中找到「遇到這種錯誤訊息，通常這樣修」，但它不會自動切換帶入除錯流程。
應該帶入除錯流程這個判斷，需要 process knowledge。而這個切換的 knowledge，目前只在我腦中。
人與 AI 的理想分工
基於以上的分析，我認為在 AI 時代，理想的人機協作應該是：
人負責 process，AI 負責 content。
更具體地說：
人類掌控流程：問什麼問題、如何驗證答案、下一步往哪走、何時做決策
AI 提供內容：資料、案例、可能的選項、技術細節
為什麼這樣分工更穩健 (robust)？
因為 process knowledge 是在真實世界的代價中淬煉出來的。一個經驗豐富的工程師，他的除錯流程是經過無數次「試錯-反思-修正」建立起來的。這些經驗雖然隱性、難以言說，但它們是真實有效的。
相對地，LLM 的「process-like behavior」只是統計上的相關性，沒有經過真實世界的驗證。當遇到罕見情況時，有經驗的人更可能有「這裡不太對勁」的直覺，因為這個直覺是用真實的失敗「買」來的。
這不是說 AI 沒有價值。恰恰相反，AI 在提供 content 上的能力是革命性的。過去我需要花數小時查文件，現在 AI 幾秒內就能給我相關的資訊。這讓我可以把更多心力放在「思考」而不是「查資料」上。
對 AI 應用設計的啟示
如果接受「人負責 process，AI 負責 content」這個原則，那麼在設計 AI 應用時，我們應該問的問題就不一樣了。
不是「如何讓 AI 自動化整個流程」，而是：
流程中哪些環節是「查資料、提供選項」（適合 AI）？
哪些環節是「判斷、決策、處理例外」（需要人類）？
如何設計介面，讓人類可以輕鬆地掌控 process，同時高效地利用 AI 的 content？
還有，哪一類的人，他們對 process knowledge 最敏感？