Prompt 技巧被高估了
「學會 Prompt 就能駕馭 AI」
這句話誤導了很多人。
Prompt Engineering 確實有用。好的 prompt 能讓 AI 產出更精準、更符合需求的結果。
但這只解決了一半的問題。
Prompt 是讓 AI 產出「更多」「更快」。但你知道產出的東西「對不對」「好不好」嗎？
AI 寫了一段 code，你能判斷它有沒有 bug 嗎？ AI 給了一個架構建議，你能判斷它適不適合你的專案嗎？ AI 說「這樣做最好」，你能判斷它的依據對不對嗎？
如果你不能，那 prompt 寫得再好也沒用。
因為你只是更快地產出「你不確定對不對的東西」。
真正的瓶頸不是 AI 的能力，是你的判斷力。
什麼是判斷力？
「判斷力」聽起來很抽象。讓我把它拆成四個具體的層次。
層次 1：判斷「對不對」
最基本的層次：AI 的輸出正不正確？
- AI 寫的這段 code 有沒有 bug？
- 邏輯正不正確？
- 會不會有 edge case 沒處理？
這聽起來簡單，但很多人做不到。
例子：AI 寫了一個排序函數，你能看出它是 O(n²) 還是 O(n log n) 嗎？如果資料量大，這個差別可能是「能用」和「系統當掉」的差別。
層次 2：判斷「好不好」
正確，但是不是最佳解？
- 有沒有更簡潔的寫法？
- 有沒有更易維護的結構？
- 有沒有更高效的演算法？
例子：AI 用了 5 個 if-else 來處理狀態轉換。技術上正確，但你知道用 map 或 state machine 可以一行解決、而且更好維護嗎？
「正確」和「好」是兩件事。很多人只能判斷前者。
層次 3：判斷「適不適合」
最佳解，但適合這個專案嗎？
- 符合團隊的 coding convention 嗎？
- 跟現有 codebase 的風格一致嗎？
- 團隊其他人能理解嗎？
例子：AI 用了最新的 ES2024 語法，寫法很漂亮。但你的專案要支援 IE11，這段 code 根本不能用。
「最佳解」是相對的。在某個 context 下最佳，換個 context 可能是最差。
層次 4：判斷「值不值得」
適合，但值得花時間做嗎？
- 這個優化的 ROI 是多少？
- 現在做還是以後做？
- 做了對業務有什麼影響？
例子：AI 建議你重構整個模組，讓 code 更乾淨。建議很好，但 deadline 是明天，你要先交付還是先重構？
這個層次需要商業判斷，不只是技術判斷。
為什麼大多數人卡在層次 1-2？
因為層次 3-4 需要「專案 context」和「業務理解」。
AI 沒有這些。它不知道你的團隊規範，不知道你的 deadline，不知道你的客戶在乎什麼。
所以 AI 只能給你「通用的正確答案」。
把這個答案變成「你的專案的正確答案」，是你的工作。
這就是判斷力。
判斷力從哪裡來？
判斷力不是天賦，是累積。
具體來說，有五個來源。
來源 1：踩過的坑（經驗）
你被 production bug 教訓過幾次？
每一次 incident 都是判斷力的養分。因為你會記得：這個錯誤是怎麼發生的、當時漏看了什麼、下次要注意什麼。
但問題是：你有沒有真的學到？還是修完就忘？
很多人踩了坑，修完 bug，就結束了。沒有回顧、沒有記錄、沒有歸納。
這樣踩 100 個坑，判斷力還是不會提升。
來源 2：看過的 code（眼界）
你看過多少「好的 code」？
判斷「好不好」的前提是：你知道什麼是好的。
如果你只看過自己寫的 code，你的標準就是自己。這很危險。
好的 code 在哪裡？開源專案、同事的 PR、技術書籍、公司內部的 best practice 文件。
看得多，標準才會高。標準高，判斷力才會準。
來源 3：解決過的問題（模式識別）
同樣的問題遇過三次，第四次你就會有直覺。
「這個 bug 看起來像是 race condition」 「這個架構聞起來像是會 scale 不了」 「這個需求聽起來像是會 scope creep」
這種直覺就是判斷力的一部分。它來自於模式識別——你的大腦在無意識中比對過去的經驗。
但前提是你要「有意識地歸納」。不然經驗只是經驗，不會變成直覺。
來源 4：被 review 過的 PR（他人視角）
別人指出你沒看到的問題。
「這裡有 null pointer 風險」 「這個命名不夠清楚」 「這個設計以後會很難改」
這些 feedback 是最快建立判斷力的方式。因為你看到了「自己的盲點」。
每個人都有盲點。被 review 的過程，就是讓別人的眼睛補足你看不到的地方。
前提是：你要認真看 review comments，不是只求 approve。
來源 5：獨立思考（最關鍵）
以上四個都是「輸入」。
但沒有思考，輸入不會變成你的。
什麼是獨立思考？問「為什麼」，然後形成「自己的觀點」。
具體來說：
看到一個 best practice，問「為什麼這樣比較好？」
不要只是照做。理解背後的原因。這個 practice 解決什麼問題？在什麼情況下不適用？
被 review 打回來，問「reviewer 看到了什麼我沒看到的？」
不要只是改完交差。理解 reviewer 的思考方式。下次你能不能自己看到這個問題？
AI 給了一個答案，問「如果我是 AI，我會怎麼回答？跟它一樣嗎？」
這個問題很有意思。它強迫你先形成自己的判斷，再跟 AI 比較。差異在哪裡？誰對？為什麼？
這個思考過程很慢。但這是判斷力真正「長在你身上」的方式。
沒有思考的經驗，只是流水帳。 有思考的經驗，才是判斷力。
怎麼培養？
知道來源不夠，還要有方法。
以下是五個具體可做的事。
方法 1：每次用 AI 都多問一句
刻意練習判斷力的方式：每次 AI 給你輸出，問自己四個問題。
- 「這個對嗎？」（層次 1）
- 「有更好的寫法嗎？」（層次 2）
- 「適合我的專案嗎？」（層次 3）
- 「值得現在做嗎？」（層次 4）
剛開始會很慢。你可能要花比 AI 生成更多的時間來判斷。
這很正常。這就是刻意練習。
熟練之後，這四個問題會變成直覺，幾秒鐘就能判斷。
方法 2：建立個人 checklist
把你踩過的坑變成檢查清單。
每次 AI 產出後，跑一遍 checklist。
例子：
有沒有處理 null/undefined？
有沒有考慮併發/race condition？
有沒有處理錯誤/exception？
符合團隊命名規範嗎？
有沒有寫測試？
效能可接受嗎？
你的 checklist 會隨著經驗越來越長。
這個 checklist 就是你判斷力的具體化。別人看你的 checklist，就知道你踩過多少坑。
方法 3：主動做 code review
不只是等別人 review 你。主動去 review 別人的 code。
為什麼這有用？
因為 review 別人的 code 會強迫你「主動使用判斷力」。
你要判斷：這段 code 對不對？好不好？適不適合？
你還要能說清楚：為什麼這裡有問題？應該怎麼改？
這比被動接受 review 更能鍛鍊判斷力。
方法 4：記錄失敗
每次 AI 出錯、每次你漏看問題，記下來。
- AI 錯過什麼？
- 你漏掉什麼？
- 下次怎麼避免？
每週花 10 分鐘回顧這些記錄。
這些記錄會變成你的判斷力資料庫。時間久了，你會發現某些錯誤反覆出現——那就是你的盲點，要特別注意。
方法 5：練習再練習
沒有捷徑。
判斷力是肌肉，要練才會有。
用 AI 100 次，有意識地判斷 100 次，你就會進步。
重點是「有意識」。如果你用 AI 100 次，但每次都直接接受輸出、不判斷，那 100 次跟 1 次沒有差別。
練習 + 意識 = 進步。
常見誤區
誤區 1：技術能力 = 判斷力
你可能很會寫 code，但不會判斷「該不該寫」。
技術能力是「怎麼做」。 判斷力是「做不做」「做什麼」「什麼時候做」。
很多技術很強的工程師，判斷力很差。他們會花三天優化一個沒人用的功能，因為「技術上很有趣」。
技術是工具，判斷力是知道什麼時候用什麼工具。
誤區 2：經驗年資 = 判斷力
10 年經驗但沒有反思 = 1 年經驗重複 10 次。
判斷力來自「有意識的累積」，不是時間。
我見過工作 2 年但判斷力很強的人——因為他每天都在反思、歸納、學習。
也見過工作 10 年但判斷力普通的人——因為他只是重複做一樣的事，沒有成長。
年資不等於能力。有意識的練習才等於能力。
誤區 3：Prompt 寫得好 = 不需要判斷力
Prompt 好 → AI 輸出好。
這是對的。
但「好的輸出」還是需要你判斷。
就像「好的員工」還是需要主管判斷方向。員工執行力再強，方向錯了也是白費。
AI 是你的員工。它執行力很強。但方向對不對，還是要你判斷。
Prompt 是讓員工更會做事。判斷力是知道該做什麼事。
兩個都需要，但判斷力更稀缺。
結論
判斷力是 AI 時代最稀缺的能力。
因為 AI 能做的事越來越多，「執行力」不再稀缺。誰都能讓 AI 寫 code、寫文件、做分析。
稀缺的是：知道該做什麼、怎麼做是對的、什麼時候該做。
這就是判斷力。
它不是天賦，是累積。
踩坑、看 code、解問題、被 review、然後——思考。
沒有捷徑，只有練習再練習。
從今天開始：每次用 AI，多問一句「這真的對嗎？為什麼？」
這個習慣，會讓你在 AI 時代越來越值錢。