假設你收到一份 agent 交出的修補程式（patch）。它改了檔案，附上一段解釋：原本的錯在哪裡、為什麼要這樣改、改完會不會影響其他功能。解釋讀起來有條理，邏輯也通順，你一邊看一邊覺得「它懂這個需求」。
這份解釋讀起來像一個真的懂這件事的人在說話，也可能讓你想問：它到底懂了多少？這個好奇很合理。
但在把這份程式交到使用者手上之前，還有幾個問題沒人回答：它真的解決了原本要解決的問題嗎？誰驗證過？如果之後出現新的狀況，由誰負責處理？
這幾個問題和「它到底懂不懂」完全是兩回事。能力要驗證，責任要有人承擔——這件事不必等「它有沒有主觀經驗」這道更難的題先有答案。
借小說《盲視》切開推論：任務能力、主觀經驗與交付責任必須分開檢驗
接下來這段會提到 Peter Watts 的小說《盲視》（Blindsight）的核心設定，還沒讀過、不想被劇透的人可以跳到下一節。
小說透過擾頻者（Scramblers），提出智能與自我覺察可以分離的假設。
借這個假設再問：如果一個系統在某項任務上表現正確，卻沒有主觀經驗，我們要怎麼判斷它的能力？
如果把「表現正確」和「背後有個誰在懂」綁在一起，這個問題就可能讓人不安。小說的假設讓我們有機會重新檢查：任務表現能不能回答主觀經驗的問題？
把這個疑問帶回開頭的假設場景：如果我們因為輸出流暢、邏輯自洽，就把「語言表現」當成「理解程度」的證據，再把「理解程度」當成「可以信任」的證據，每一步究竟查過什麼？這正是我們要拆開檢查的推論鏈。如果沿著小說引出的問題，暫時假設某個系統在一項任務上做對了，卻沒有主觀經驗，也還要分別問：這次做對的證據是什麼，足不足以支持下一次採用？「它懂，所以我信任它」這句話，沒有交代採用的範圍與條件。這是最基本的驗證要求：既不能由此斷言語義理解和表現必然無關，也不能把一次成功當成所有情境的保證。
這裡只借小說的思想實驗提問，不據此判定現實中的 LLM 或 agent 有沒有主觀經驗。語義理解與主觀經驗，本來就需要分開討論。
回到開頭那份修補程式。它解決問題了嗎？這是任務能力的問題，要用需求和測試結果驗證。寫出這份解釋的模型有沒有主觀經驗？這是另一個問題，這裡不下判定。誰該驗收這份修補、出錯了由誰處理？這是第三個問題，要團隊自己安排。三個問題各自有自己的檢驗方式，混在一起問，就會漏掉該查的證據——例如還沒核對需求，就已經開始討論能否放心交付。我們要避免的是判斷跳步，而不是去猜團隊通常會漏問哪一題。
評估產出能不能交付：不看文字多流暢或有沒有意識，全憑需求與測試結果驗證
把這份假設的修補程式攤開來看。如果一句「它懂了」同時代表「它懂這個需求」「它值得信任」「它有主觀經驗」，就把任務正確性、可靠性和主觀經驗一次打包，卻沒有分別檢查。
這裡要檢查兩種可能的推論。第一種是「它說得像個懂行的人，所以這份成果可以交付」——語言表現流暢，不代表任務驗證已經完成。在這個假設裡，我們讀到了一份有條理的說明，但還需要把其中的修改理由與程式碼、需求及執行結果逐項比對。我們要補上的是這些具體核對，不從文字表現推斷模型內部如何產生解釋，更不能把解釋寫得好不好當成驗收結果。第二種剛好相反：「如果它沒有主觀經驗，做對了也不算能力，等它有意識再談後果」——即使暫時接受它沒有主觀經驗這個假設，程式改得對不對、會不會造成其他問題，仍然要照樣檢查。如果團隊把責任安排押在「等意識問題解決」這個條件上，眼前這份修補的驗收就仍未有著落。我的判斷很直接：即使暫不判定主觀經驗，也應先說清楚採用條件、驗收者與修正安排；這項安排不依賴意識問題何時能有答案。
程式是否真的符合需求，要靠測試和實際執行結果驗證。換模型或換 agent 之前，也要先確定錯出在哪一層，同一套檢查邏輯，也適用在判斷一份產出能不能用。不管另外有人相信或否認寫出這份解釋的東西有沒有意識，檢查程式碼、跑測試、確認沒有破壞其他功能，這些事都還是要做。
小說也借用了 John Searle 提出的思想實驗「中文房間」（Chinese Room），討論語言表現與理解。這個論證有不同的回應。這裡只借它提出「表現正確」和「理解」能否畫等號的問題，不當成 LLM 架構或意識判定的證據。
主觀經驗本身值得認真關心，這一點不該被立場蓋過去。我沒有主張意識對能力毫無作用，也不拿某次任務表現替代這個深奧問題。承認這一點，是為了提醒自己：這裡要處理的是「交付前要檢查什麼」，而不是回答「意識有沒有用」這個哲學大題。兩者可以分開討論，也應該分開討論。但即便暫時接受某個系統缺乏主觀經驗的假設，任務表現、採用範圍與責任安排，仍然各自需要明確的證據與標準。
交付責任不能推給模型：成果必須由具名的人驗收，出錯時負責說明與修正
評估一份 AI 產出能不能交付，可以從四件事問起：要解決的問題是什麼、可接受的結果長什麼樣子、用什麼方式驗證、驗收之後由誰負責處理後續的狀況。這四件事和「它有沒有主觀經驗」是不同的問題，不能互相代答。順序也很重要：先把問題和可接受的結果界定清楚，驗證方式才有對象可以比對。
我認為，這些安排必須明確落在人身上。驗收要有某個具名的人看過結果、確認符合需求；出錯之後，也要有人負責說明原因、提出修正。把這些要求講清楚，是 builder 對交付要盡的責任。團隊裡誰扮演這個角色可以換，但這個角色不能空著。
回到開頭那份修補程式：驗收的人要能說出他是依據哪個需求、哪些測試結果判斷可以接受，不能只因文字解釋寫得清楚就點頭放行。出錯之後，也要能具體說清楚是哪一步判斷錯了，不能拿「模型本來就會犯錯」當藉口，把責任懸在空中。
理解使用者的處境，也要落在具體行動上：聽取需求、核對對方實際遇到的狀況，並在出錯時修正。這些動作值得持續練習。不管最後是人還是 AI 完成了這份工作，使用者都應該能找到一個會回應、會解釋、會修正的對象。
問題定義、驗證、取捨，以及理解受影響者的處境，是值得持續投入的核心能力。依據這套交付要求，即使團隊決定更換模型，也應重新核對需求、驗證結果並指定具名驗收者。在這個假設場景裡，可以請模型提出修補選項，再由具名的人依標準檢查與取捨。這裡強調的是團隊應持續練習判斷、承擔交付的安排，既不主張這些能力只有人類具備，也不對模型能力的上限妄下結論。
這份成果要交給誰、憑什麼驗收、出錯時由誰處理？這三個問題不會因為「它到底懂不懂」有了答案就自動解決——它們一直都要有人回答。
延伸閱讀
- 想把這份判準帶回工作，可以接著讀〈AI 都能交出像樣的報告了，專業還要學到什麼程度？（2026 完整解析）〉。
參考資料
- Peter Watts. Blindsight. 官方全文（小說原文，僅取思想實驗與中文房間相關段落，不延伸為現實 AI 的科學證據）。
- David Cole. The Chinese Room Argument, Stanford Encyclopedia of Philosophy（哲學概念的定位與爭議，不作為 LLM 架構或意識判定的依據）。
留言0
登入後就能留言。
登入