🌏 Read this article in English
前陣子，團隊裡發生了一件事
有個 Junior 用 AI 寫了一個功能。
大概 500 行，花了兩小時。效率很高，他自己也很滿意。
我們的 Senior 花了十分鐘 review，然後皺著眉頭說：「這邊邏輯有問題。」
那個問題如果上線，會影響十萬筆用戶資料。
後來我在想：那十分鐘，到底值多少錢？
我開始覺得，「資深」這件事，好像在變
以前我們說一個人資深，通常是說他代碼寫得好、經驗多、踩過的坑多。
但現在 AI 可以寫很多代碼。
寫得快，有時候還寫得不錯。
那資深的人，價值在哪？
我的觀察是：在判斷。
不是寫得比 AI 多，是「看得出 AI 哪裡寫錯了」。
那個 Senior 之所以值錢，不是因為他能寫 500 行。
是因為他花 10 分鐘，就看出了問題在哪。
AI 寫 500 行，你判斷 10 分鐘。那 10 分鐘，就是你的價值。
我把這個叫做「十分鐘價值」。
Definition: 十分鐘價值（10-Minute Value）是指在 AI 時代，資深工程師的核心競爭力——用極短的時間做出關鍵判斷，避免重大問題的能力。這種判斷力來自經驗累積、基礎知識和對系統全局的理解。
Key Insight: AI 時代「資深」的定義正在改變。價值不在於寫更多代碼，而在於能看出 AI 哪裡寫錯了。
AI 像什麼？
我現在會把 AI 想成一個很勤快但沒經驗的實習生。
它可以幫你做很多事：寫代碼、查資料、產報表、整理文件。
而且它不會累，不會抱怨，24 小時都能工作。
但它需要你檢查、需要你指導、需要你做最終決定。
它不知道這段代碼三個月後會不會變成技術債。
它不知道這個 API 設計會不會讓前端同事想打人。
它不知道這個需求其實老闆下週就會改。
這些，都是你知道的事。
你的價值不是「比實習生做得更多」。是「能判斷實習生做得對不對」。
如果你跟 AI 比產量，你會輸。
如果你跟 AI 比判斷，這是它做不到的事。
Key Insight: AI 就像一個很勤快但沒經驗的實習生。它不知道代碼會不會變技術債、API 設計合不合理、需求會不會改——這些都是你的價值所在。
誠實說，AI 不是完美的
在繼續之前，我想先承認一件事：AI 有它的問題。
有研究顯示，用 Copilot 的開發者，bug 率反而比較高。
Microsoft 的數據說，需要 11 週才能完全發揮 AI 工具的效益。
你的主管如果對 AI 有疑慮，他不是無知。他的擔憂是有根據的。
但我的看法是：問題不是「要不要用 AI」，而是「怎麼用」。
如果你把 AI 當成「幫你寫更多代碼的工具」，你可能會製造更多 bug。
如果你把 AI 當成「幫你省時間，讓你專注判斷的工具」，你會升級。
差別在心態。
那什麼是「判斷」？
很多人聽到「判斷力」，會覺得很抽象。
好像是那種資深架構師才會做的事。
但其實不是。
你每天都在做判斷，只是沒意識到。
- 這個 API 要不要做分頁？判斷。
- 錯誤訊息要回什麼？判斷。
- 這個欄位要不要加索引？判斷。
- 這段邏輯要抽成 function 嗎？判斷。
- 這個需求合理嗎？要不要推回去？判斷。
你不是沒在做判斷。你只是沒意識到。
開始「意識到」，就是成長的開始。
三個我看到的誤區
聊到這裡，我想分享三個常見的誤區。
誤區一：以為用 AI 寫越多代碼越好
有些人覺得，AI 時代就是要「產出更多」。
用 AI 寫 500 行，比自己寫 100 行厲害。
但現實是：你的價值不是產出量，是「能不能判斷產出對不對」。
那個 Junior 用 AI 寫了 500 行。
那個 Senior 只花 10 分鐘 review。
但 Senior 的薪水是 Junior 的兩倍。
為什麼？因為那 10 分鐘，避免了一個可能讓公司損失幾百萬的問題。
不要跟 AI 比產量。你會輸。
誤區二：以為 AI 時代不用學基礎
有些人覺得，反正 AI 會寫，我幹嘛還要學資料結構、演算法、系統設計？
但你想想：你要怎麼判斷 AI 寫得對不對？
AI 寫的 SQL 能跑，但你要懂 index 才知道它會不會慢。
AI 寫的架構看起來合理，但你要有經驗才知道它撐不撐得住。
基礎不是用來寫代碼的，是用來「看懂 AI 寫的對不對」。
學基礎，是在投資你的判斷力。
Key Insight: 基礎知識（資料結構、演算法、系統設計）在 AI 時代不是用來寫代碼的，而是用來判斷 AI 寫得對不對。學基礎就是投資你的判斷力。
誤區三：以為會 prompt 就夠了
很多人在學「怎麼跟 AI 溝通」、「怎麼寫好 prompt」。
這很好，但這只是工具。
真正的價值是：AI 給你三個方案，你選哪個？為什麼？
會問問題的人很多。
會判斷答案對不對的人，比較少。
一個簡單的框架：執行—判斷光譜
我自己在想這件事的時候，畫了一個簡單的圖：
flowchart LR
subgraph 執行區["⚙️ 執行區 — AI 能做"]
direction TB
A1["寫 CRUD"]
A2["切版"]
A3["寫基礎 SQL"]
A4["套模板"]
A5["產報表"]
end
subgraph 判斷區["🎯 判斷區 — 你的價值"]
direction TB
B1["Code Review"]
B2["架構決策"]
B3["技術選型"]
B4["判斷需求合理性"]
B5["決定優先順序"]
end
執行區 -- "升級 = 往右移動" --> 判斷區
style 執行區 fill:#ffe6e6,stroke:#ff9999,stroke-width:2px
style 判斷區 fill:#e6ffe6,stroke:#99cc99,stroke-width:2px你可以想想，過去一週，你的時間花在哪裡？
如果大部分在左邊，你在跟 AI 競爭。
如果有一部分在右邊，你在做 AI 做不了的事。
升級，就是往右邊移動。
不同階段，可以怎麼做
如果你是中階工程師（2-5 年）
你可能在想：我知道要「往上走」，但我每天就是寫 CRUD，哪來的機會？
幾個建議：
1. 下次 Code Review 時，多問一個問題
除了看「對不對」，多問：「這個設計會不會造成未來的問題？」
這就是在練判斷。
2. 用 AI 寫完代碼後，花 5 分鐘問自己
「如果不用 AI，我會怎麼寫？差在哪？AI 的寫法有沒有問題？」
這也是在練判斷。
3. 開始記錄你的決策
每週花 10 分鐘，寫下一個你做的判斷：
日期：2025/12/15
情境：PM 要求新增一個 API
選項：A. 改現有 API B. 新增 API
我的判斷：選 B
理由：現有 API 已經有 10 個地方在用，改了風險太大
結果：（一週後補）順利上線，沒影響其他功能三個月後，你會有 12 個以上的「判斷案例」。
這就是你面試時的故事庫，也是升遷時的證據。
4. 不用等公司給你機會
你想升 Senior，但公司沒給你做架構的機會？
不用等。
- 在 Code Review 時，提出架構層面的建議
- 在技術討論時，主動畫圖說明你的想法
- 寫一份「如果重構這個模組，我會怎麼設計」的文件
Senior 不是「被指派做架構的人」。
是「主動在思考架構的人」。
如果你是資深工程師 / Tech Lead
你可能已經在用 AI 了。那這篇文章能告訴你什麼？
我覺得有一件事值得想想：你的新價值是什麼？
AI 讓 Junior 產出變快了。但 Code Review 的負擔也變重了。
你可能會覺得這是負擔。但換個角度想：
你的判斷力，就是團隊的品質保證。
那些 Review，那些「這邊有問題」的十分鐘，就是你的價值。
幾個你可以做的事：
1. 建立「AI 產出的 Code Review Checklist」
AI 容易犯的錯有模式。把它整理出來，讓團隊共用。
2. 在 1:1 時問組員：「這週你做了什麼判斷？」
這會讓他們開始意識到判斷的重要性。
3. 分享你的判斷過程
不只是說「這邊有問題」，而是說「我是怎麼看出來的」。
讓 Junior 學習「怎麼想」，不只是「怎麼做」。
4. 招人時，可以這樣問
- 「你用 AI 寫過什麼？後來發現什麼問題？你怎麼處理？」
- 「給我一個例子，AI 建議 A，但你選了 B，為什麼？」
這些問題能看出一個人有沒有「判斷力」，而不只是「會不會用 AI」。
如果你的主管對 AI 有疑慮
這是很多人會遇到的情況。
你想用 AI，但主管說：「AI 產出品質不穩定，先不要。」
我的建議是：先別急著說服。
他的擔憂通常不是沒道理的。
Bug 率可能真的會上升。學習曲線確實存在。安全風險也是真的。
所以與其說「AI 很棒你應該讓我用」，不如這樣：
「我想在這個小功能上試試看。如果出問題，我負責。兩週後我給你數據。」
這樣做有幾個好處：
- 降低主管的風險感知（小範圍、有人負責）
- 讓你有機會用數據證明自己
- 就算失敗，也是一個學習
試用後，回報具體數據：
「這個功能我用 AI 省了 X 小時。Bug 數是 Y。比起上次類似功能，品質差不多 / 更好 / 有待改進。」
讓主管看到數據，而不是你的主觀感受。
另外，有一句話可能有幫助：
「AI 寫的每一行，我會當作 Junior 的代碼來 review。如果出問題，責任在我，不在 AI。」
這句話讓主管知道：你不是要偷懶，你是要用更聰明的方式工作。
如果你是主管
也許你正在讀這篇文章，想著：「團隊要不要用 AI？怎麼管？」
我的看法是：完全禁止和完全開放，可能都不是最好的選擇。
你的擔憂是合理的
- Bug 率確實可能上升
- 學習曲線確實存在
- 安全風險確實需要考慮
這些不是無知，是謹慎。
但完全禁止也有風險
- 你的競爭對手可能在用
- 你的團隊成員可能私下在用（然後你不知道）
- 優秀的人可能因此不想加入你的團隊
建議的做法
1. 分場景管理
不是「能不能用」，而是「什麼情況可以用」。
例如：
- 內部工具、原型：可以用
- 核心交易邏輯、敏感資料處理：需要額外審查
2. 建立 Review 規範
AI 產出的代碼，必須經過人工 review。
Review 重點：邏輯正確性、安全性、可維護性。
這不是額外負擔，這是品質保證。
3. 追蹤數據
用 AI 的專案 vs 沒用的專案：
- 開發時間差多少？
- Bug 率差多少？
- 維護成本差多少？
用數據決策，不是用感覺。
4. 培養判斷力，而不是依賴性
讓團隊學會「判斷 AI 對不對」，而不是「無腦接受 AI」。
這才是 AI 時代主管的真正職責：不是管 AI，是培養能駕馭 AI 的人。
問題不是「AI 會不會取代你」
我常聽到有人問：「工程師會不會被 AI 取代？」
我覺得這個問題問錯了。
更好的問題是：「我用 AI 省下的時間，拿去做了什麼？」
如果你用 AI 省下時間，然後寫更多 CRUD —— 你在跟 AI 競爭產量。長期來看，這不是好策略。
如果你用 AI 省下時間，然後花時間想架構、做 Review、學習新東西 —— 你在升級。
AI 不會取代你。但「會用 AI + 有判斷力」的人，會取代「不會用 AI」或「只會用 AI 但沒判斷力」的人。
Key Insight: 問題不是「AI 會不會取代你」，而是「你用 AI 省下的時間拿去做什麼」。用省下的時間寫更多 CRUD 是跟 AI 競爭；用來做架構設計、Code Review、學習，才是真正的升級。
回到那個十分鐘
文章開頭那個故事，後來怎麼樣了？
那個 Junior 後來跟 Senior 聊了一下。
他問：「你怎麼十分鐘就看出問題的？」
Senior 說：「這種邏輯錯誤我踩過。三年前有一次，上線後才發現，修了兩週。」
「所以你是憑經驗？」
「也不完全是。我會特別看幾個地方：邊界條件、空值處理、併發情況。這些是 AI 最容易漏的。」
Junior 說：「我以為我用 AI 寫得很快，是一種進步。」
Senior 說：「寫得快是進步。但知道哪裡會出問題，是另一種進步。」
最後
我不知道五年後的工程師會長什麼樣。
沒有人知道。
但我猜，到時候回頭看，我們會發現：
能留下來的人，不是寫最多代碼的人。
是那些在關鍵時刻，做對判斷的人。
那些判斷，可能每次只花十分鐘。
但那十分鐘，決定了一切。
你今天的十分鐘，花在哪裡？
相關文章
Sources
- Figma 2025 AI Report — AI 對設計與開發工作的影響調查
- GitHub Copilot 生產力研究 — GitHub 官方的 Copilot 效益量化研究
- Uplevel: Copilot 與 Bug 率研究 — 使用 AI 工具後 Bug 率變化的獨立研究
- ISC2 2024 資安人才報告 — 全球資安人才趨勢與技能需求
- Microsoft AI 工具效益研究 — 11 週學習曲線的數據來源