🤪 除錯是家常便飯

我請 AI 幫忙一起架設 雲端服務 Nextcloud 的過程中遇到了鬼打牆的事，一開始架設得很順利，最後要優化一些功能時，常常修好了這裡卻壞了那裡，不斷地在除錯 debug，原以為是自己問 AI 的方式不夠精確或有什麼不周延的地方，直到讀了Google工程師 Addy Osmani 這篇 文章 〈The 70% problem: Hard truths about AI-assisted coding〉，我終於釋懷了。原來，幫 AI 收爛攤子 收尾是常見的事，這是我們要做的事，別誤以為 AI 會幫我全部預備好好的，什麼都它一手全包！

😨 鬼打牆

一開始看起來確實很順利，無論是 Nginx 的反向代理、 Docker 的容器設定、寫 PHP 伺服器端程式語言，甚至整合線上編輯 Collabora Online，AI 幾乎都能迅速給出一份看似結構完整、邏輯清楚的答案，我看著程式碼一條一條運作，竟有種飛天的感覺，不過，到優化功能和除錯階段，頓時從天空摔到了地下室，可怕的循環如下：

1. 要修一個小 bug 或優化一項功能，問AI 怎麼做
2. AI 給了一個看起來合理的程式碼
3. 這個程式碼有效，但卻引發了其他問題
4. 叫 AI 修好問題後，結果又冒出別的新問題
5. 回到第1點，無限循環…

更絕望的是，如果看不懂這一堆程式碼，根本拆解不出真正的問題成因，只好回頭叫 AI 檢查自己造成的 bug ，看似很荒謬，怎麼要 AI 收捨自己惹出來的事呢？

📑 AI 工作流

在實際部署的過程中，AI「幾乎」正確，這「幾乎」代表了還差一點點，例如設定寫好了，但服務沒接上對口；路徑看起來沒問題，請求卻卡住；能開啟 Collabora online，但文件載不出來，每一段配置單獨看都合理，但整體卻無法運作，這正是工程師 Addy Osmani 文章所說的現象：AI 很擅長做到「70%」，它可以快速生成正確的指令、合理的架構、看似完整的設定，但剩下的 30%，才是現實世界真正困難的部分，那是除錯 debug、系統環境差異、各項服務之間的互動，以及各種不在文件裡的種種細節。

也就是說，AI 產出的東東，還需要人類最後檢查。

剩下的30%

當理解這一切之後，與 AI 的互動方式會變成讓 AI 做 70%，我們掌握 30%，我們讓 AI 快速產出初步方案，因為那是它最擅長的部分，但不會直接採用，而是叫 AI 解釋指令，好幫忙 逐段理解 、逐步驗證，用小範圍測試來確認結果，而不是一次套用整套設定。如果出現問題，別急著否定或相信，而是回到是否程式適合系統環境，去找真正的原因。

那篇文章提出了一個很精準的比喻「AI 就像一個能力很強，但經驗不足的 junior 工程師」，它寫得快、產出多、回答得很有自信，但它不會替結果負責，也不會主動驗證。這時候，角色就會自然轉變，我不再只是使用工具的人，而開始像一個真正的工程師那樣工作，會去檢查設定是否合理、會去看 log、會用指令測試每一個節點、會一步一步縮小問題範圍，即便用 AI 檢查 AI 也是同樣意思。

我開始多問幾句：「這指令碼在這裡執行，會影響什麼地方？先檢查我的系統環境及各項參數，是否適合？」

😃 練習基本功

走到這裡，我發現一個無法逃避的事實，在寫程式上，如果基本功薄弱，就難以與 AI 有效合作！

AI 可以告訴我反向代理怎麼寫，但如果我不知道請求是經過哪些步驟和東東，就無法判斷問題出在哪一層？AI 可以給我 Docker 指令，但如果不理解容器與主機的關係，就無法面對異常狀況，也就是說：

AI 並沒有降低技術門檻，而是改變了門檻的位置。

從「做不做得出來」變成「看不看得懂為什麼？」

「做多少」不再困難，複制貼上即可；「懂多少」卻要花大把心力去思考，這件事不可交給 AI 啊！當看不懂時，AI 是搗蛋鬼；當看得懂時，AI 才是好幫手。

🤨 從懷疑到相信

相信是建立在理解之上的選擇，會先懷疑，因為知道它可能不完整；會驗證，因為需要確定結果；而當理解之後，才會瀞楚我相信了什麼。走過 Nextcloud 的架設過程，逐漸明白與 AI 共事就像帶新人一樣，讓它照需求提供資料，但由我負責方向與品質，並非全部的工作都交給它。「從懷疑到相信」的真正意義，或許不在於要是否信任 AI，而是我漸漸成為了那個知道何時該相信的人。

上次修改於 2026-04-01