真理是一個函數嗎？

系列：程式人的哲學思辨 #01/11 | 閱讀時間：25-30分鐘 | 概念：知識論（Epistemology）— 真理的本質與判定

作者：Wina @ Code & Cogito

---

深夜的 True

2024年某個深夜。

我盯著螢幕上的一行程式碼：

if user.age >= 18:
    return True

手指懸在鍵盤上，突然意識到一件事。

這個 True 到底意味著什麼？

不是技術上的意思——我知道它返回布林值。我問的是更深的問題：什麼讓某件事成為「真」？

年齡大於 18 就是成年。在台灣。但在日本是 20 歲。在美國買酒是 21 歲。在某些國家，「成年」這個概念本身就在爭論。

那個簡單的 True，背後藏著人類思考了 2500 年的哲學難題。

而我發現，程式設計師可能是最適合思考這個問題的一群人。

因為我們每天都在做一件事：把模糊的現實，壓縮成明確的布林值。

每一個 if 都是一次判定。每一次判定都隱含一個問題——你的判定標準從哪裡來？它可靠嗎？它在什麼條件下會失效？

這是「程式人的哲學思辨」系列第一篇。我們從最基本的開始：真理。

Let’s debug reality.

---

背景：Boolean 的假象

程式世界裡的乾淨二分法

在程式裡，真假很簡單：

x = 5
y = 3
print(x > y)  # True

毫無疑問。乾淨俐落。True 就是 True。

但當你把這個邏輯推向現實世界，事情就開始崩塌。

def is_adult(age):
    return age >= 18  # 這真的是「真理」嗎？

這個函數返回的 True，和 5 > 3 的 True 是同一種「真」嗎？

不一樣。

5 > 3 是數學真理——在宇宙的任何角落、任何時刻都成立。

但 age >= 18 是社會建構的判定——它在特定法律、特定文化、特定時代下成立。改個參數就失效。

不是所有的 True 都是同一種「真」。

這個洞察，哲學家們花了兩千多年才整理出框架。

為什麼程式人特別適合想這件事

因為你每天都在處理「真」的問題：

• 測試是「真的通過」還是「假的通過」？
• 需求文件說的是「真正的需求」還是「表面的需求」？
• AI 生成的答案「看起來是真的」但「事實上是假的」——你怎麼分辨？

哲學家亞里斯多德在兩千年前就說過：「說存在的東西存在，說不存在的東西不存在，就是真。」聽起來很簡單。但當你嘗試把這句話寫成程式碼，你會發現它有多少隱含的假設。

---

三種真理理論：程式人的直覺翻譯

哲學家把「什麼是真」這個問題，歸納成三大理論。每一個都對應你在工程中熟悉的模式。

一、符應論：語句要對到世界

核心思想：真理就是語句與現實的匹配。

它最像你心中的函數：

def is_true_correspondence(statement, reality):
    return statement.matches(reality)

直觀、舒服、也最危險。

因為你通常拿不到完整的 reality。你拿到的是 API 回傳的部分資料、使用者回報的片面描述、監控系統抓到的不完整 log。

符應論的問題不是邏輯上的，而是實務上的：你永遠無法確定你的 reality 參數是完整的。

亞里斯多德提出符應論。兩千年來它一直是最直覺的真理觀。直到人們開始追問：「那『現實』本身怎麼定義？誰來告訴你現實是什麼？」

二、融貫論：在系統內不矛盾

核心思想：一個語句如果與你的整個信念系統一致，它就是真的。

它像整合測試——一組模組要能一起運作，不能自相矛盾：

def is_true_coherence(statement, belief_system):
    return belief_system.add(statement).no_contradiction()

融貫論的力量在於：你不需要跑去「對照現實」，只需要確保系統內部一致。

但它的陷阱也在這裡：一個漂亮的封閉系統可以完全自洽，卻與現實脫節。

想想那些設計精美、邏輯嚴密、但完全不符合使用者需求的軟體架構——它們在理論上完美一致，在實踐中完全失敗。

黑格爾、布拉德利等哲學家發展了融貫論。他們相信真理是一個巨大的邏輯網絡，每個部分都與其他部分相互支撐。

三、實用論：能用就是真

核心思想：如果一個信念在實踐中產生好的結果，它就是真的。

它像 A/B test 或線上指標：

def is_true_pragmatic(statement, metrics):
    return metrics.after_adopting(statement).improves()

實用論對工程師極有吸引力——我們習慣「不管黑貓白貓，能跑的就是好貓」。

但它會逼你面對一個尷尬的問題：有用的謊言算不算真？

安慰劑效應是真的有效。錯誤的地圖如果碰巧帶你到目的地，它算「正確」嗎？

威廉·詹姆斯和約翰·杜威發展了實用論。他們把哲學從象牙塔拉回現實：不要問「這是真的嗎」，要問「相信這個有什麼後果」。

---

單元測試能證明真理嗎？

這裡有一個程式人特別能理解的悖論。

你的測試全綠了。100% 通過。你能說你的程式是「正確的」嗎？

不能。

測試能做的，不是證明「永遠正確」，而是證明：在你想到的輸入、你設計的案例、你考慮的邊界裡，它沒有被推翻。

def truth_by_tests(claim, test_cases):
    return all(case.verify(claim) for case in test_cases)
    # test_cases 永遠不完備

這和哲學家卡爾·波普的「否證論」驚人地一致。波普說：科學不是透過不斷驗證來建立真理，而是透過不斷嘗試推翻來逼近真理。你永遠無法證明一個理論「是真的」，你只能說「目前還沒被推翻」。

覆蓋率的哲學版本

你的測試覆蓋率是 95%。那另外 5% 呢？

更關鍵的是——你覆蓋的是「你想得到的世界」。世界永遠有你想不到的邊界條件、你沒預見的分佈漂移、你不知道自己不知道的盲區。

所以真理更像「持續監控 + 持續校準」，不是一次性的宣告。

型別系統的保證與局限

強型別系統給你安全感。int 不會突然變 str，None 被顯式處理，某些不可能狀態被排除。

但它不保證：

• 你的需求理解是正確的
• 你的變數命名反映了現實
• 你的目標函數沒有偏差

型別系統像形式邏輯：它保證推論在規則內一致，不保證規則本身是對的。

這正是融貫論的問題——形式上完美，實質上可能脫節。

---

不可證明：為什麼「全域正確」常常不可得

工程上你知道兩個殘酷的現實：

1. 複雜系統的狀態空間太大，不可能窮舉
2. 你不可能枚舉所有使用情境

哲學上也有類似的困境。當你嘗試為一個命題提供證據，你會發現：

• 證據本身也需要驗證
• 驗證又需要另一層證據
• 如此無窮回歸

到最後，你會落到兩個選擇：要嘛接受某些基礎前提不需要證明（公理），要嘛承認確定性永遠有極限。

這和哥德爾不完備定理的精神如出一轍：任何足夠複雜的形式系統，都存在無法在系統內證明的真命題。

工程師的直覺版本：

我們永遠在「風險可接受」的邊界上工作，而不是在「絕對正確」的天堂裡。

---

現代連結：AI 幻覺與真假供應鏈

在生成式 AI 的時代，真理問題變得前所未有地緊迫。

ChatGPT 給你的答案可能：

• 看起來一致（融貫論通過）——句子通順、邏輯連貫、自信滿滿
• 但未必對應現實（符應論失敗）——引用了不存在的論文、編造了虛假的事實
• 短期有用（實用論部分通過）——幫你完成了任務，但埋下了隱患

這就是 AI 幻覺（hallucination）的本質：它通過了融貫論和實用論的測試，卻在符應論上徹底失敗。

作為程式人，你已經有了應對的直覺——它就像一個通過了所有整合測試、但在生產環境炸掉的系統。測試案例沒有覆蓋到那個致命的邊界條件。

真理需要供應鏈管理

在 AI 時代，真理不再是一次性判定，而需要像供應鏈一樣管理：

• 來源追溯（source of truth）——這個資訊從哪裡來？
• 交叉驗證（multi-source validation）——有獨立的第二來源嗎？
• 版本管理（truth versioning）——什麼時候、為什麼改變了？
• 持續監控（post-deploy maintenance）——部署後它還是真的嗎？

你每天在做的 CI/CD pipeline，本質上就是一套真理維護系統。

---

反思與啟示：程式人的真理修養

你想要的是「真」還是「安心」？

很多時候我們追求真理，其實是在追求可控感。「這個 bug 修好了」——你想要的不是宇宙真理，而是「我可以安心上線了」。

但世界常常不可控。優秀的工程師不追求一次性的「正確答案」，而是建立一套能在不確定中持續運作的判定流程。

真理是一條 Pipeline

如果你要把今天的討論濃縮成一個工程模型，它是這樣的：

1. 定義命題——明確 scope，「什麼是你要判定的？」
2. 指定證據——可追溯來源，「你的依據是什麼？」
3. 一致性檢查——避免自相矛盾，「它和你知道的其他事情衝突嗎？」
4. 反例搜尋——主動找會失敗的情境，「什麼條件下它會錯？」
5. 上線監控——注意分佈漂移，「它還是真的嗎？」
6. 版本化修正——承認自己會錯，「需要更新嗎？」

真理不是一個函數的回傳值。它更像一條持續運行的 pipeline——需要輸入、處理、校驗、監控、更新。

四個帶走的心智模型

1. 保持懷疑精神——像寫測試一樣測試你的信念。不是不相信一切，而是對「確定性」保持健康的警覺。

2. 追求多維度驗證——一個信念至少要通過符應論、融貫論、實用論中的兩個才值得信賴。只通過一個的，要小心。

3. 接受不完備性——你的測試覆蓋率永遠不會是 100%，你的信念系統也是。接受它，然後建立容錯機制。

4. 持續重構——定期檢視和更新你的信念系統，就像重構程式碼一樣。不是因為原來的「錯了」，而是因為世界變了。

---

結語

回到開頭的那個深夜。

if user.age >= 18:
    return True

現在你知道了：這個 True 不只是一個布林值。它是一個在特定法律框架（符應論）、社會共識（融貫論）、實用需求（實用論）下成立的判定結果。

改變框架，它就可能變成 False。

而作為程式人，你擁有一個獨特的優勢——你早就習慣在不確定中工作、在複雜中尋找結構、在錯誤中持續修正。

這些，恰好是追尋真理最需要的能力。

下次當你寫下 if something == True: 時，也許會多想一秒：

這個 True，比你想的複雜得多。

---

下一篇預告

知識就是資料嗎？

你的資料庫裡存了 TB 級的資料。但你「知道」了什麼？

• 資料、資訊、知識、理解、智慧——這個金字塔真的成立嗎？
• Schema 設計就是在定義世界觀？
• 為什麼兩個人看同一份數據，會得出完全相反的結論？
• 知識需要「版本控制」嗎？

下一篇，我們把認識論拆成程式人能操作的知識工程。

---

參考資料

• Aristotle. Metaphysics. (符應論的原始文獻)
• Popper, Karl. The Logic of Scientific Discovery. Routledge, 1959. (否證論)
• James, William. Pragmatism. Longmans, Green, and Co., 1907. (實用論)
• Gödel, Kurt. “On Formally Undecidable Propositions.” Monatshefte für Mathematik, 1931. (不完備定理)
• Floridi, Luciano. The Philosophy of Information. Oxford University Press, 2011. (資訊哲學)

---

---