分享我從手刻程式走向 AI 協作的親身經驗 —
以及一路上對工程師角色的重新思考。
回頭看過去的開發日常，最消耗生產力的從來不是「寫不出程式」，而是以下這三件事。
在需求、文件、程式碼、API 規格之間反覆跳轉，每次切換都重建心智模型，專注力碎片化。
修改 A 連帶影響 B，但依賴關係並未顯式呈現。直到整合時才暴露，規劃被迫重來。
Pull Request 送出前的自我審查耗費大量認知資源，容易因疲勞而漏檢真正的問題。
導入 Claude Code 最在意的不是炫技，而是這三個可量化的面向是否真的有提升。
把規劃、實作、審查合併到同一條產線，從需求定義到 Pull Request 的時間對半砍。
透過 AI 快速掃描 Codebase，把隱性依賴顯式化，在動手前就看見影響範圍。
將 Code Review 範本化、非同步化，讓品質檢查不再依賴個人狀態，而是穩定輸出。
先回顧過去的開發習慣：線性作業、重依賴個人經驗、容易被中途變動拖住 —
拆開這段流程看，才發現時間花在哪裡。
根據 User Story 和驗收條件，手動拆解出需要新增或修改的 API 規格，寫下後端能驗證的 Acceptance Criteria。
在腦中推演系統架構衝擊、決定資料流向、評估是否需要新 Model 或 Service — 全憑過往經驗與直覺。
逐檔查看既有實作、追蹤呼叫鏈、找到可重用的元件 — 資訊密度高、但人類記憶體容量有限。
動手寫 code，不斷遇到「沒想到這邊會牽連到」的意外耦合，在過程中被迫修正原本的規劃。
修改 A 連帶影響 B、B 又回頭影響 A — 成本從線性膨脹成網狀，每一次重新規劃都在消耗時間預算。
發 PR 前的自我審查：命名、格式、測試覆蓋、邊界條件 — 全靠疲憊的大腦逐行掃描。
後來把角色重新劃分：
AI 負責執行、由人負責決策與審查。
每一步產出都留下可驗證的軌跡，方便事後回推。
仍由人負責把 User Story 轉為明確的技術 AC — 「問題定義」這個環節不該讓給 AI。
>_ Claude Code 在數分鐘內掃描整個 Codebase，產出修改大綱，顯式列出所有受影響的檔案、函式與測試。
>_ Claude Code 將修改大綱轉為可追蹤的 Task List，每個任務都有明確的 Input / Output 合約。
>_ Claude Code 依任務序執行，減少手動輸入錯誤 — 工程師也從「打字員」變成「審閱者」。
由 Claude Code 進行 Code Review，但使用與規劃、實作完全獨立的 Session —
透過 Context 隔離，讓審查結果可追溯、可決策、可回滾。
>_ Claude Code 在獨立 Session 執行 Code Review，與規劃、實作的 Context 完全隔離 — 避免審查觀點被開發過程的記憶污染。
>_ Claude Code 將發現的問題、建議寫入可版控的檔案，作為後續人工決策依據 — 決策軌跡可被稽核。
由人檢視 AI 的修正建議，判斷哪些採納、哪些忽略 — 這是整個流程中最需要專業判斷力的一步。
>_ Claude Code 根據工程師的決策自動執行修復，修復完成後 重新進入 Phase 5 審查 — 形成 Review → Decision → Fix 的 closed loop，直至達成高品質狀態。
實作一段時間後，歸納出影響協作品質最深的兩件事 —
Token 預測、上下文理解。
基於機率的 Token 預測
每個輸出都是機率分佈下的選擇 — 不是檢索，也不是複製貼上。
透過上下文理解意圖
上下文的品質決定輸出品質 — Context is everything.
為什麼後來堅持把任務拆成小塊？
讓 AI 產出變得可預期的關鍵，在「反覆迴圈 + 明確契約」。
走過這段歷程，最大的體會是：工程師的核心價值不再是「敲鍵盤的速度」，而是以下三個更高階的能力 — 也是需要持續校準的工作重心。
把商業需求翻譯成可執行的技術 AC — 這是 AI 無法代勞的判斷力。
看見系統的整體結構、預判長期演進 — 規劃層級的能力被放大。
從「寫得對」進化為「審得準」— 審查判斷成為核心交付物。