我們一直以為工程的核心是「寫對」。

寫對的程式
正確的模型
精準的預測

但當系統越來越大，你會開始發現一件很不舒服的事——

多數問題，不是因為「寫錯」，而是因為「決策錯了」。

而且更殘酷的是：

這些錯誤，通常在半年後才爆炸。

Harmless Engineering 是什麼？

它不是一個框架，也不是一個工具。

它比較像一種冷靜的自覺：

我們無法避免做錯決策，但可以讓錯誤不要變成災難。

這句話如果翻得更白一點：

不是追求「正確」，而是設計「可承受的錯誤」。

為什麼你一定會做錯決策

你做軟體開發，你一定懂這種感覺：

• 需求不完整
• 規格還在變
• 使用者情境不穩定
• 技術一直在變化

你其實是在這種狀態下決策：

資訊不完整 + 時間有限 + 壓力很大

所以問題從來不是：

「怎麼做出正確決策」

而是：

「當決策錯了，系統會不會死」

真正的轉折：從 Correctness → Damage Control

大部分工程文化都在強調：

• best practice
• correctness
• optimal solution

但 Harmless Engineering 在想的是另一件事：

如果這個決策是錯的，它會傷到哪裡？

一個很現實的例子

你選擇：

• 技術框架採用 Java 還是 C#
• 本地部署還是 cloud
• UDP 還是 TCP

這些都不是「對或錯」。

真正的問題是：

ADR：讓錯誤變成可以回頭的路

這時候，ADR（Architecture Decision Record）就出現了。

不是為了紀錄「我們做了什麼」，
而是為了留下：

我們當初為什麼這樣做。

一個沒有 ADR 的世界

半年後你會聽到：

「這段 code 為什麼這樣寫？」
「不知道，之前的人留的」

有 ADR 的世界

「HE-003，有寫。當時是因為 latency + edge deployment。」

這差異，不是文件，而是：

是否能理解過去的自己

Harmless Engineering + ADR：真正的組合技

這兩個東西分開看都不完整。

• Harmless Engineering：降低錯誤傷害
• ADR：讓錯誤可被理解與修正

合在一起，才是：

一個可以犯錯，但不會崩潰的工程系統

一個你可以直接用的結構

docs/
├── harmless-engineering.md   # 原則（不常變）
└── decisions/
    ├── HE-001-xxx.md
    ├── HE-002-xxx.md
    └── ...

關鍵不是「寫文件」，而是這句話：

每一個決策，都要能被未來推翻。

最後

當你開始做軟體開發的系統時——

你其實已經不在寫 code 了。

你在做的是：

一個會隨時間演化的決策系統

而這種系統，不可能永遠正確。

所以真正的工程能力，不是避免錯誤，而是：

讓錯誤發生時，世界不會崩塌。