最近看到一篇文章討論：「AI 不是工具，而是自動化。」
身為在軟體產業打滾多年的工程師，我其實不太認同這個結論。
原因很簡單——如果今天我們把 AI 排除在「工具」之外，那麼許多工程師每天依賴的現代開發系統，恐怕也都不能算工具了。而這顯然不符合現實。
一、我們其實一直都在使用「會自動工作的工具」
剛入行時，我寫的第一套系統是 PHP。那個年代沒有 GitHub Copilot，也沒有 ChatGPT，但很多工具其實早就默默在幫我們「自動」完成工作了：
- Compiler / Interpreter
- IDE (自動補全、重構)
- Database Optimizer
- ORM
- CI/CD Pipeline
- Container Platform
當我在 Terminal 輸入：
Bash
php artisan test
我並沒有親自執行每一個 Test Case，是 Framework 幫我跑完的。
當我執行：
SQL
SELECT * FROM users WHERE id = 42;
我也沒有親自去硬碟掃描資料檔案，是資料庫引擎幫我處理的。
當我 Push Code 後觸發部署：
YAML
deploy:
- build
- test
- release
我更沒有親自登入主機一步步手動部署，是 CI/CD 幫我完成了。
這些系統全都具備：自動執行、自動判斷、自動產生結果。但過去從來沒有人會說：「因為它會自動工作，所以它不是工具。」
二、關鍵不在「自動化程度」，而是「決策權在誰手上」
真正決定一個東西是不是工具的，是：使用者是否仍然掌握最終的決策權。
以資料庫為例，如果 SQL 寫得很爛：
SQL
SELECT * FROM orders WHERE YEAR(created_at) = 2026;
即使底層的資料庫再強大、優化器再聰明，仍然會造成 Full Table Scan。工具永遠無法代替使用者的工程判斷。
AI 也是完全相同的道理。
很多人會說：「AI 已經能幫你寫程式了！」但實際上並不是。AI 只能「生成程式碼」，而真正決定這段程式能否在 Production 存活的關鍵：
- 架構設計 (Architecture Design)
- 領域模型 (Domain Modeling)
- 異常處理 (Exception Handling)
- 資安與權限 (Security & Auth)
- 測試策略 (Testing Strategy)
- 系統可擴充性 (Scalability)
這些核心決策，永遠屬於工程師。
三、為什麼同一個 AI，會產生截然不同的結果？
這是我近兩年觀察到最有趣的現象。給定完全相同的模型：
初級工程師會問：「幫我修這個 Bug。」資深工程師則會問：「請從 DDD、SOLID 原則、測試覆蓋率、維護成本與記憶體使用量，分析這段程式的瓶頸，並列出：1. Immediate Fix 2. Technical Debt 3. Long Term Refactor Plan。」
得到的結果完全不在同一個維度。
很多人以為是「AI 的能力決定輸出品質」，但現實往往是：使用者的能力，決定了 AI 的輸出上限。
四、AI 不是工具人，而是「能力放大器」
我認為對 AI 最貼切的比喻，既不是工具人，也不是自動化機器，而是：能力放大器 (Capability Amplifier)。
當優秀的工程師善用 AI：
- 學習新技術的速度更快
- 概念驗證 (PoC) 的速度更快
- 程式碼重構與優化的速度更快
- 技術文件的撰寫速度更快
他的專業能力被大幅放大。
反過來說，如果一個人原本就沒有驗證習慣——不看官方文件、不寫測試、不理解系統架構、不做 Code Review——那麼 AI 也只是幫他以極高的效率產生更多的技術債與錯誤。
Garbage In, Garbage Out 這句老話從未過時，只是演變成了現代公式：Bad Prompt + Bad Judgment + No Verification = Bad Result
AI 沒有改變這個公式，它只是把運算速度提高了數十倍。
五、資深工程師與 AI 的真實互動方式
非工程師想像中的 AI 開發流程：
$$\text{需求} \longrightarrow \text{AI} \longrightarrow \text{完成品}$$
(這通常只存在於簡報或 Demo 影片裡)
現實世界中的工程師日常：
$$\text{需求} \longrightarrow \text{AI 產生方案} \longrightarrow \text{工程師驗證} \longrightarrow \text{發現盲點} \longrightarrow \text{修正 Prompt 方向} \longrightarrow \text{重新驗證} \longrightarrow \text{實際測試} \longrightarrow \text{部署上線}$$
這是一個持續循環的 Feedback Loop。
最近面試時常被問到：「AI 這麼強，以後工程師是不是不用寫程式了？」
我的回答通常是：「AI 減少的是打字量，不是思考量。」
事實上，越大型、越複雜的系統，越需要經驗來判斷：
- 哪裡該抽象化？哪裡該保持簡單？
- 哪裡該加快取 (Cache)？哪裡該拆分資料庫？
- 哪裡該走微服務？哪裡維持 Monolith 反而更好？
這些 Trade-off 的決策，目前仍然高度仰賴人的工程經驗。
結論：AI 最危險的用法，不是使用，而是放棄思考
我真正擔心的從來不是 AI 多強，而是使用者把 AI 的輸出當成真理，從而放棄了思考：
- 不再閱讀文件，因為「AI 說是這樣」
- 不再驗證結果，因為「AI 看起來很有自信」
- 不再撰寫測試，because「AI 說測試 pass 了」
當開發者放棄了驗證，能力確實會退化。但問題從來不在工具本身，而是在於使用方式。
身為長期維護大型系統的工程師，我認為：AI 當然是工具。
它和鎚子、IDE、Compiler 一樣，不是拿起來就能自動發揮價值。工具本身不會創造專業，工具只會放大專業。
到了 2026 年，會使用 AI 已經不是核心競爭力；能夠駕馭 AI、洞察風險並掌握最終品質的人，才是。
沒有留言:
張貼留言