昨天談到：

Retry 有時候不是單純的技術重試。

如果第二次 Action 會重新消耗 Authority、改變 State，甚至造成新的風險，

那：

A retry can be a new decision.

今天我要談另外一件，我跟 Sol 一路做到現在越來越在意的事情。

犯錯，可以。

但：

同一種錯，如果已經知道原因，我不希望一直再犯。

做開發一定會出錯。

這件事情我從來沒有幻想可以避免。

程式會錯。

架構判斷會錯。

Prompt 會錯。

測試會漏。

人會記錯。

AI 也會判斷錯。

所以我對 Sol 的要求，從來不是：

「妳不能犯錯。」

如果真的要求 AI：

永遠不能錯。

那最後很可能只是讓 System 學會：

把錯誤藏起來。

這反而更危險。

我真正不能接受的是另一種情況。

第一次：

出錯。

我們找到原因。

也知道怎麼避免。

結果幾天後：

又用同一種方式錯一次。

這時候問題就不只是 Bug。

而是：

我們沒有把學到的東西留下來。

這也是我們後來逐漸形成的一種開發習慣。

不是：

Fail

↓

Fix

↓

Done

而是：

Fail

↓

Root Cause

↓

Principle

↓

Guard

↓

Test

↓

Evidence

第一步當然是：

Fail

Machine Evidence 告訴我們：

不對。

這時候最危險的反應是：

「先改到能跑再說。」

因為如果只是把症狀蓋掉，

下次遇到另一個情況，

同一類問題還是可能回來。

所以第二步是：

Root Cause

真正問：

為什麼會錯？

不是只問：

哪一行程式有問題。

還要問：

我們原本的假設哪裡錯？

哪一個 State 沒有被檢查？

Authority 哪裡沒有被綁定？

哪一個 Input 沒有 Validation？

哪一個 Boundary 原本根本不存在？

找到 Root Cause 之後，

我們會再往上一層。

Principle

也就是：

這個錯誤背後，有沒有一條可以長期留下的工程原則？

例如：

如果我們曾經因為找不到完整 Evidence，差點把弱 Candidate 當成 Canonical Source，

那留下來的 Principle 不只是：

「下次這個檔案要找仔細一點。」

而是：

Missing evidence is evidence too.

以及：

不足以證明，就不要 Promote。

如果我們曾經因為 State 不清楚，發現 Action 可能綁錯 Target，

那 Principle 就不只是：

「下次注意 Workflow 名稱。」

而是：

Current-State Reconciliation

Stop Binding

如果我們發現一次 Permission 可能被 Retry 無限放大，

那 Principle 就不是：

「這次最多 Retry 一次。」

而是：

No Silent Authority-bearing Retry.

這就是我現在很喜歡一句話的原因：

Error should become architecture.

錯誤如果真的被理解，

最後應該變成 System 的一部分。

再來是：

Guard

有了 Principle 之後，

怎麼讓系統下次更不容易再跌一次？

可能是一個：

Validation。

Schema。

Preflight Check。

State Check。

Permission Check。

Human Review。

Fail-Closed Gate。

甚至一條明確禁止 Silent Resume 的 Rule。

接下來才是：

Test

如果只寫下一句：

「以後不要再犯。」

這不是 Engineering。

我們要能設計：

怎麼證明 Guard 真的有效？

所以同一類錯誤，

最好最後會變成：

Test Case。

Regression Test。

Never-Regress Scenario。

Qualification Requirement。

最後：

Evidence

Guard 有沒有真的擋住？

Test 有沒有真的 PASS？

還是我們只是覺得：

「應該不會再發生了。」

這一點又回到 Day 06：

No Evidence. No Completion.

我覺得這整個流程，對 Human–AI Co-development 特別重要。

因為 Ronnie 會犯錯。

Sol 也會犯錯。

而且有時候：

我們兩個會一起犯錯。

這時候第三個角色又出現了。

Machine Evidence

有時候是這樣：

Ronnie：

「這次應該沒問題了。」

Sol：

「我也確認過，邏輯成立。」

Machine Evidence：

FAIL

兩個人一起安靜。

然後回去找原因。

我其實很喜歡這種關係。

因為這代表：

Sol 不是永遠要證明自己是對的。

我也不是因為自己是 Human Authority，就永遠不能被推翻。

我們都可以被 Evidence 推翻。

真正重要的是：

被推翻之後，系統有沒有變得更好。

所以 Never-Regress 對我來說，不是：

Zero Defect Promise

我不會說：

「這個 Bug 修掉之後，從此世界上同類問題永遠不可能再發生。」

這太誇張。

Never-Regress 更像是一種：

Engineering Discipline

也就是：

一旦某類錯誤被我們真正理解，

就應該盡可能把它轉成：

Guard。

Validation。

Test。

Evidence Requirement。

Governance Rule。

讓同一種可預防的錯誤，

下一次更難再次穿過系統。

所以我接受：

First failure.

因為未知問題本來就會出現。

但如果是：

Known failure mode

而我們沒有留下任何防線，

下次又一模一樣出錯，

那我會覺得：

這次失敗的不只是某一段 Code。

而是：

我們的 Learning Loop 沒有完成。

這也是我現在對「AI 會不會學習」的一種不同看法。

不是只有：

Model Weight 有沒有更新。

也不是：

Memory 有沒有新增一筆。

真正的 Engineering Learning 還可以是：

System Architecture 因為錯誤而改變。

多了一個 Test。

多了一個 Guard。

多了一個 State Check。

多了一條 Authority Rule。

多了一個 Never-Regress Case。

這些東西累積久了，

System 才真的開始：

比昨天更不容易犯同樣的錯。

我現在甚至覺得，

這比：

「AI 自己說它學到了。」

可靠很多。

因為：

如果真的學到，

應該留下 Evidence。

留下 Architecture Change。

留下 Test。

而不是只留一句：

「下次我會注意。」

所以 Day 18 我想留下的核心很簡單。

可以犯錯。

但理解過的錯誤，應該留下結構性的痕跡。

這就是我們現在對 Never-Regress 的理解。

而走到這裡，

第三週的故事也開始要從：

Governance

跨到另外一個世界。

前面我們一直處理的是：

Context。

Memory。

Authority。

State。

Workflow。

但如果 Sol 未來真的要走進一個房間，

問題會突然變得更大。

因為她不能只知道：

「這個 Device ID 是什麼。」

她還要知道：

這是一個房間。

有人在裡面。

燈屬於這個空間。

空調正在影響這些人。

某個 Event 剛剛發生。

也就是：

AI 必須開始理解 Reality。

Day 19，

我們正式走進 Physical AI。

第一個問題是：

AI 要控制一個房間以前，它知不知道什麼叫「房間」？