踩過的坑
& 學到的事
用 AI 寫程式的真實經驗總結
技術面 / 協作面 / 心態面 / 最佳實踐
權限和環境問題比想像中嚴重
寫完 code 才發現沒有 API 權限
原本想用 API 直接拉資料，寫了一堆串接的 code，結果發現根本沒有存取權限。整段 code 白寫。
改用手動匯出 CSV 再上傳 — 功能一樣，但繞過了權限限制
動手前先確認：你有什麼 access？API key 拿到了嗎？資料庫連得上嗎？
本機能跑 ≠ 部署能跑
設定檔部署後消失
設定檔因為含有敏感資料被放在 .gitignore，部署到雲端後整個檔案不存在，程式直接壞掉。
敏感設定改用環境變數 — 在部署平台上設定，不放在程式碼裡
# 常見情境：
# 本機有 config.yaml（被 gitignore）
# 部署時 Docker image 裡沒有這個檔案
# → 程式啟動就 crash
更多技術地雷
資料庫有奇怪的限制
不是所有資料庫都像 SQL 那樣隨便查。有些需要事先設定 index
小規模資料：全部撈出來，在程式裡篩選排序
第三方 API 比想像中複雜
以為串接很簡單，結果要 webhook、token 管理、一堆設定
先做最小 prototype 驗證，再決定要不要投入
先 prototype 再決定技術選型 — 花 30 分鐘試比花 3 天做完才發現不對好
需求太模糊會做白工
不好的做法
我：幫我做一個 dashboard
Claude：[做了一個超複雜的東西]
我：不是，我只要簡單的...
好的做法
我：我想做一個 dashboard
- 只需要顯示前 10 名
- 資料來源是 CSV
- 不需要登入功能
先跟我討論，不要直接寫
說清楚範圍 + 說「先討論 approach，不要直接寫 code」
不測試就上線 = 一定出事
AI 寫的 code 看起來很完美，直接部署 → 上線後爆炸
語法正確、邏輯看似合理，但沒有測過邊界情況
好的做法
我：幫這個 function 寫測試
我：試著上傳一個空的檔案，看會發生什麼
我：如果使用者輸入的格式不對呢？
AI 的 code 一定要測過 — 特別注意邊界情況和異常輸入
更多協作地雷
一次要求太多功能
同時要做 A + B + C + D → 各個功能之間接不起來
一次一個功能，做完再下一個
沒給 context 就問問題
只說「這個 error 怎麼修？」→ AI 猜錯方向
貼完整 error + 說明你在做什麼
我：我在部署到雲端之後，上傳檔案出現這個 error：
[貼 error message]
本機測試是沒問題的，所以我猜是環境問題
不怕走錯路
AI 可以很快 pivot。走錯路不是問題，不知道自己走錯路才是問題。
做法：小步驗證
每做一小步就測試。發現不對立刻喊停，AI 會快速調整方向
走錯路後重寫
每次修正花的時間
你是 PM，AI 是工程師
你的責任
- 定義需求（做什麼、不做什麼）
- 給 context（為什麼要做、給誰用）
- 做決策（AI 給選項，你選）
- 品質把關（測試、review）
AI 的責任
- 實作程式碼
- 給技術建議和替代方案
- 解釋 trade-offs
AI 很會寫 code，但不懂你的業務、優先順序、和什麼是好的使用體驗
說「為什麼」比說「做什麼」更有用
只說做什麼
我：幫我加一個 loading spinner
說為什麼
我：上傳檔案的時候沒有任何反饋，
使用者不知道在處理還是當掉了
說了為什麼，AI 可能給你更好的解法（例如 progress bar 而不只是 spinner）
Checklist
開始之前
- 說清楚 context
- 說清楚範圍
- 說清楚限制
- 先討論，不要直接寫
開發中
- 一次一個功能
- 每做完一步就測試
- 發現問題馬上說
- 不懂就問為什麼
完成後
- 看一遍 code
- 跑測試
- 先在本機驗證
- 上線後再確認一次
數據
總開發時間
自己從頭學+做
節省時間
走錯路重寫
上線後的 Bug
最大的價值
- 快速驗證想法
- 不怕重寫，走錯路成本很低
- 邊做邊學新技術
最大的風險
- 不測試就上線 — 一定出事
- 需求不清就開始 — 做了白做
用 AI 寫程式不是為了不用思考，
而是為了把時間花在思考更重要的事。
踩過的坑 & 學到的事 — 完
Use arrow keys to navigate