上一篇我們聊了三個常見的執行誤區。但誤區背後有一個更根本的問題：我們還在用開發傳統程式的方式，去思考 AI。
我遇過一個很典型的場景。
需求會議開始，BU 的同仁打開一系列的 Word 和 Excel 文件，開始唸規則：「如果欄位 A 填的是 X，就判斷為類別一；如果同時出現 Y 和 Z，要先走例外流程……」大概列了三十幾條，越列越複雜，中間還衍生出好幾個子規則。
會議快結束的時候，我問了一個問題：「你們現在人工處理這個任務，準確率大概是多少？」
對方想了一下，說：「嗯……不一定，有時候不同的人判斷結果也不太一樣。」
這就是問題所在。一個連人都無法標準化執行的任務，列再多規則也沒有用，因為這些規則根本不完整。而當我們把這份不完整的規則文件交給 AI，卻期待它能 100% 正確，失敗幾乎是必然的。
這不是 AI 的問題。是我們用錯了方式去定義 AI 的工作。
Software 1.0 和 2.0，差在哪裡？
傳統程式開發（Software 1.0）的邏輯是：工程師定義所有規則，程式執行規則。輸入 A 一定得到 B，不允許例外，零誤差是基本要求。這套邏輯在金融業行之有年，因為法規、精算、核保等等這些業務的底層本來就是硬規則的世界。
但 AI 開發（Software 2.0）的邏輯完全不同。你不再窮舉規則，而是定義目標，提供數據，讓模型自己從樣本中歸納規律。輸出結果不是確定性的，而是帶有信心分數的機率分佈。
把這個差異整理成三個維度來看：
- 邏輯來源：傳統開發靠工程師寫規則；AI 開發靠模型從數據中學。你的工作從「把所有情境想清楚、寫進程式」，變成「提供足夠有代表性的樣本，讓模型自己找規律」。
- 輸出結果： 傳統程式是確定性的，給定相同輸入，永遠得到相同輸出。AI 的輸出是機率性的，每個結果都附帶一個信心分數，代表模型對這個答案有多確定。這不是缺陷，是本質。
- 開發思維： 傳統開發關注流程中的每一個步驟是否被正確執行；AI 開發關注的是整體輸出的準確率分佈，是否落在可以接受的範圍內。
同一個需求會議，兩種思維的差異
抽象的概念說完了，我想用一個具體的對比來說明這個思維轉換在實務上長什麼樣子。
