她站在門口，手裡抱著一台筆電，眼神有點緊張
她沒有工程背景，被分派到一個正在跑的金融 SaaS 專案，不是教學專案，不是 side project，是真的有人在用的系統——審批流程、預算管理、年度預估，每一頁背後都壓著真實的業務邏輯
我是她的 Mentor，我帶過團隊、管過人，但那些都是即戰力——有經驗的工程師，給方向就能跑，這次不一樣，這是我在外部公司，把一個非工程背景的人從零帶到能獨立交付的經歷
而且我不打算教她傳統的寫程式方法
我們的安排是兩週一次課程，我不會手把手盯著她寫 code，而是每次見面時 review 她的進度、給方向、教思維，中間兩週，她自己摸索、自己跟 AI 協作
不教 Coding，教思考
我給她的第一個任務不是寫程式
「把公司要你做的流程，全部寫下來，不要管格式，不要管排版，巨細靡遺地寫，想到什麼就寫什麼，寫完之後用 AI 整理，整理到你自己能看懂為止」
她的表情明顯寫著：我是來寫 code 的，不是來寫作文的，但她沒說出口，開始寫了
這就是我的教學策略——Vibe Coding，不教 for-loop，不教 state management，不教 CSS，教她像產品經理一樣思考：這個系統要解決什麼問題？使用者會怎麼操作？資料從哪裡來、到哪裡去？想清楚之後，用人話把需求說明白，AI 會幫你把它變成程式碼
程式碼是 AI 的工作理解需求、設計流程、判斷邏輯——這才是人的工作
第一次 review，她寫出來的 PRD 邏輯清楚、能問出對的問題，這比會寫 React component 重要一百倍
五個為什麼
第二次見面，她帶來了一個困擾她兩週的 bug
審批列表頁面，應該要顯示待審核項目，但畫面上永遠是零筆，她試了各種方法——跟 AI 說「幫我修這個列表」、「換一個做法試試」、「重新載入資料」，AI 照做了，但畫面還是零
問題不在 AI 寫的程式碼，在於她給 AI 的方向就是錯的，她在第一層打轉
我問了她一個問題：「為什麼畫面顯示零筆？」然後一路往下追——陣列是空的、API 沒回資料、權限過濾太嚴格、部門對應寫錯、原始資料匯入時欄位名稱不一致
五個為什麼，一層一層往下挖，直到碰到岩盤，根因埋在資料匯入的那一瞬間
Vibe Coding 不代表你不需要理解系統 你可以讓 AI 寫程式，但 AI 不會替你問「為什麼」，方向對了，AI 才能幫上忙
她後來養成了一個習慣：遇到問題，先寫五個「為什麼」再跟 AI 說要改什麼
先畫靶，再射箭
同一個 bug，我做了一件讓她困惑的事——修 bug 之前，先寫測試案例
「可是 bug 都還沒修，寫測試有什麼用？」
「你先畫好靶，再射箭，不是射完箭，再把靶畫在箭插的地方」
用 Vibe Coding 的語言來說——你先告訴 AI「做完之後，這幾個情境要能通過」，然後再讓 AI 去寫，如果你不先定義什麼叫正確，AI 寫出來的東西你根本無法判斷對不對
她想了一下：「所以測試就像是我跟 AI 的驗收標準」
對，先把驗收標準寫好，AI 才知道做到什麼程度算完成
白屏
有一次，我自己把 dashboard 搞炸了，Push 之後整頁白屏，什麼都沒有
她在旁邊看著，Mentor 剛教完怎麼抓 bug，結果自己把頁面搞掛
我沒有慌，也沒有找藉口，打開工具，花了四十分鐘找到原因，修掉，補測試
她後來跟我說，那天學到的比前幾次加起來還多，不是技術——是態度搞砸了就修，修完就補防線，不需要演
帶人這件事，你展示的態度永遠比你教的技術影響更深
是我太笨了嗎
大概第三個月的時候，她傳了一則訊息給我
「為什麼我的開發進度一直延遲？是我太笨了嗎？」
我回了她：
「業務邏輯比程式碼難十倍，連 Mentor 都要花時間釐清，不是只有你不懂」
這不是安慰，這是事實
她卡住的地方不是程式語法——AI 已經幫她處理了，卡住她的是金融業務的審批流程、預算分類的層級關係、多角色的權限控制邏輯，AI 可以幫你寫程式，但 AI 不會替你理解業務
Vibe Coding 的瓶頸從來不是程式碼，是你對業務的理解深度 你描述得越精準，AI 產出的品質越高，而精準描述的前提，是你真的懂這件事
那之後，她問問題的方向徹底變了，不再是「這個 component 怎麼用」，而是「這個審批流程在什麼情況下會被退回」
沒人教她的那一步
有一次 code review，我看到一個小改動
她在處理 Google Sheets API 串接時，主動把 service-account-key.json 加進了 .gitignore
沒有人教她這一步，她自己想到的——判斷出一個金鑰檔案不該被 commit，即使是用 Vibe Coding，你還是需要判斷什麼該做、什麼不該做，AI 不會主動替你想安全問題
我在 review 裡還是給了其他回饋——commit message 描述模糊，下次寫清楚改了什麼、為什麼改，進步了不代表可以放鬆標準
一個人完成工程師做的事
三個月的尾聲，她獨立完成了年度預估寫入功能
不是練習題，是一個會被真實使用者操作的功能，影響公司的財務報表，她自己定義需求、設計資料結構、用 AI 實作前後端、處理邊界條件
從需求到交付，她自己來，我只在最後做了 review
她的 title 沒有變，但她做的事完全不一樣了，一個三個月前完全沒有工程背景的人，現在能獨立用 AI 完成工程師做的事——用 Git 管理版本、在 GitHub Issues 上追蹤任務、定義需求、用 AI 實作前後端、交付 production-ready 的功能，公司不再需要外包工程師
成長軌跡：
| 次數 | 關鍵里程碑 |
|---|---|
| 第 1 次 | PRD 撰寫，流程文件化，用 AI 整理需求 |
| 第 2 次 | 學會 5-Why，知道方向對了 AI 才能幫上忙 |
| 第 3 次 | 理解驗收標準概念，分階段規劃能力提升 |
| 第 4 次 | 後端 API 串接（AI 輔助），見證白屏事件 |
| 第 5 次 | 業務邏輯突破，安全意識萌芽 |
| 第 6 次 | 獨立定義需求 → AI 實作 → 完整交付 |
注意看這條路徑——她學的不是「怎麼寫 React」，是怎麼把一個模糊的業務需求變成 AI 能執行的精確指令，這才是 Vibe Coding 的核心能力
教的人學到更多
三個月結束後，我把整段帶人過程寫成了一份文件，一千多行
寫的過程中我才發現——很多東西是我在教她的時候才真正想清楚的，5-Why 我以前只是直覺在用，從來沒整理成方法，先定義驗收標準？我自己也不是每次都做到，白屏事件？如果不是有人在旁邊看著，我大概草草修掉就算了
帶人不是把已知的東西倒給別人，帶人是在傳遞的過程中，重新理解自己到底知道什麼
十條原則，不是事先設計好的，是走過一遍之後回頭看到的路：
- 小步前進 — 每兩週一個明確目標，不貪多
- 擁抱錯誤 — 錯誤是最好的教材，包括 Mentor 自己的錯
- 需求優先 — 先想清楚要做什麼，再讓 AI 做
- 先定驗收標準 — 不知道什麼叫「對」，就不知道什麼時候做完
- 五個為什麼 — AI 不會替你問為什麼，診斷是人的工作
- 具體回饋 — 不說「寫得不錯」，說「這裡為什麼這樣設計」
- 心理安全 — 讓人敢犯錯、敢提問
- 正常化困難 — 難不是因為你笨，是因為業務邏輯本來就難
- 追蹤成長 — 每次回饋，讓進步被看見
- 把過程寫下來 — 教學相長，寫的時候才真正學會
最後
專案結束幾個月後，她傳了一則訊息給我
不是問 bug，不是問技術，她說她決定去上正式的工程師培訓課程，她想把寫程式這件事真正學透
我愣了一下，三個月前站在門口那個緊張的人，現在主動走向這條路，不是因為公司要求，是因為她在這三個月裡發現了一件事——把一個模糊的想法變成一個真的能用的東西，這件事讓她著迷
有些人學了寫程式之後覺得「這是一份工作」，有些人學了之後覺得「這是我想做的事」，差別不在天賦，在於那個最初的體驗夠不夠真實
她的第一個體驗不是 Hello World，是一個真的有人在用的金融系統，她的第一次除錯不是教科書的練習題，是一個影響真實使用者的 production bug，這些經歷帶給她的不只是技能，是一種確定感——「我可以做這件事，而且我喜歡做這件事」
我回了她一句：「加油，你已經知道最重要的事了——先想清楚再動手，剩下的都是細節」
而我，一個本來只打算教別人東西的人，在這之後才真正理解——帶人最大的成就，不是教會了什麼技術，是點燃了一個人想要繼續走下去的動機
技術可以學，但只有動機還在燃燒的時候，學什麼都學得會
作者 Young Tsai，全端 AI 接案開發者，過去當主管帶的是即戰力，這次是在外部公司用 Vibe Coding 的方式，把一個非工程背景的人帶到能獨立用 AI 交付金融功能，不教語法，教思考，點燃動機