低成本、靠判斷、細節很在地的任務，常常自己寫比較快。
你昨天用 coding-AI 寫的東西，今天才發現結果不對
你只是想把「送出」改成「確認預約」，順手調一下按鈕狀態。結果你叫 coding-AI 工具改，它先翻了三個檔案，順便重構命名，再幫你加一段你沒要的防呆。你開始檢查程式碼差異，刪掉多餘改動，補充背景資料，最後花了 25 分鐘。這時候才想起來：原本自己改，可能 5 分鐘。
真正的問題不是 AI 不會寫
結論先講：AI 省的是「打字時間」，不一定省「決策時間」。很多人剛開始用 coding-AI 工具，會把它當成全自動同事，什麼都丟過去。看起來很先進，實際上常常把小任務變成溝通任務。
寫程式不只是在產生文字。你還要知道這個按鈕為什麼叫這個名字、這段判斷背後是哪個商業規則、這個例外到底要不要擋。這些不是模型看幾個檔案就容易猜準的東西。它可以給你一版「看起來合理」的做法，但你還是要檢查(review)、修正、補背景資料。
Simon Willison 提過一個很派的觀察：AI 的胡編錯誤(hallucination)有時反而沒那麼危險，因為假套件、假函式一跑就炸；麻煩的是「跑得起來但邏輯不對」。成本就是從這裡冒出來的：不是它寫不出來，是你要花腦力確認它有沒有寫歪。
值得自己手動寫的 4 種情境
**第一種：5 到 10 分鐘內能改完的小修。** 例如改文案、補一個欄位名稱、調整一個條件判斷。這類改動你腦中已經有答案，叫 AI 反而要描述位置、描述意圖、再檢查它有沒有順手多改。當提示詞比程式碼還長，差不多就該自己動手了。
**第二種：靠領域知識判斷的商業邏輯。** 例如「試用戶能不能套用折扣」、「退款後積分要不要回補」、「這個狀態要不要顯示給客服」。AI 可以幫你寫語法，但它不知道公司昨天開會到底拍了什麼板。這種地方錯一行，不是錯誤訊息，是客訴。
**第三種：很吃專案習慣的細節。** 有些程式碼庫(codebase)有自己的怪癖：命名規則、資料夾擺法、錯誤處理風格、誰呼叫誰。Ryz Labs 做過 6 個月測試，超過 1 萬行的程式碼庫，coding-AI 準確率會掉到 50%。不是不能用，而是越在地的規矩，越需要人盯。
**第四種：你已經知道解法，只是不想打字。** 這種最常見，也最浪費。你明明知道要加哪三行，卻開一個新對話請 AI 寫。它回你 60 行，你再刪成 3 行。這不叫自動化，這叫繞路健身。
今天就能改的 4 個分流動作
**先做 30 秒估價。** 動手前問自己三件事：我知道要改哪裡嗎？改動會不會少於 10 行？我能不能 10 分鐘內寫完？如果三題多數是「可以」，先手寫。AI 留給你不確定、範圍大、需要探索的任務。
**把 AI 改成「問路用」，不是「代駕用」。** 小任務可以問：「這個狀態在哪裡被用到？」、「這段判斷可能影響哪些畫面？」讓 AI 幫你找路、列風險、做粗檢(sanity check)。真正落筆的那幾行，自己寫，速度常常比較漂亮。
**商業邏輯先用中文寫一句規則。** 例如：「退款後，只有未使用的點數要回補。」如果你寫不出這句，先別叫 AI 寫程式；如果你寫得出，很多時候你也差不多能自己改。AI 可以幫你補測試案例，但規則本人最好不要外包給它猜。
**設一個停損點：修兩輪還不對，就接手。** 如果 AI 第一版不對、第二版還在誤解，你繼續補背景資料，成本通常會膨脹。這時候不要跟它拚耐心，直接自己改，然後再叫它檢查有沒有漏掉極端情境(edge case)。角色一換，效率就回來了。
拿走的一句話
coding-AI 的高手不是什麼都丟給 AI，而是看得出哪件事手寫比較便宜。
