AI 能在短時間內產生大量程式碼、測試、文件與修改建議，待閱讀與判斷的內容也隨之變多。生成速度提高後，壓力會轉向理解變更、確認意圖、辨識風險，以及判斷內容是否適合合併。
閱讀 AI 產出的內容需要高度注意力。這些程式碼多半語法完整、命名合理，也能通過部分測試。審查者要確認 AI 是否正確理解需求、例外情境是否完整，以及變更是否牽動其他模組。這類工作缺少明確的進度感，卻要求開發者長時間保持警覺。
待審查內容超過團隊的處理能力時，認知超載便會出現。前一個變更尚未理解清楚，下一個拉取請求（Pull Request, PR）已經進入佇列。開發者頻繁切換需求、模組與設計背景，也要反覆建立上下文，注意力會被快速消耗。
降低負荷的第一步，是限制單次變更規模，控制在製品（Work in Progress, WIP）數量，並讓測試、靜態分析（Static Analysis）與安全掃描先處理可自動判斷的問題。人工審查的注意力才能留給需求意圖、架構邊界與高風險邏輯。
開發者過去會從完成一段程式、解決技術難題或建立一套設計中獲得成就感。AI 接手部分程式撰寫工作後，個人投入與可見產出之間的關係開始改變。程式碼可能在幾分鐘內生成，後續時間則花在檢查、刪除、調整與驗證。
審查與修正工作不容易被看見。管理者若只觀察功能數量、代碼行數（Lines of Code, LoC）或任務完成量，便會低估開發者投入的判斷與驗證。長期處在「替 AI 收尾」的工作狀態中，開發者也可能看不清自己的貢獻，進而對工作價值產生疑問。
這項變化也會影響專業認同。初階開發者擔心缺少實際撰寫與解決問題的機會，資深開發者則承擔更多程式碼審查（Code Review）、架構判斷與風險控制責任。團隊若沒有重新說明工程角色，成員容易將 AI 的產出速度當成個人工作標準，對自己的能力產生不必要的懷疑。
工程價值應涵蓋問題理解、方案判斷、風險控制與系統演化。這些工作也要進入任務規劃、績效討論與成果回顧，讓開發者看見自己的判斷如何減少返工與事故，並降低後續維護成本。
AI 工具加入開發流程後，工作常在需求文件、聊天介面、整合開發環境（Integrated Development Environment, IDE）、版本控制系統、持續整合（Continuous Integration, CI）管線與監控（Monitoring）平台之間切換。
每個工具都只保存部分資訊，需求背景留在文件中，提示詞（Prompt）留在聊天紀錄，修改結果出現在 IDE，檢查結果則散落在其他系統。
分散的資訊會增加工作摩擦。開發者反覆複製需求、貼上錯誤訊息、補充系統背景，再將 AI 建議帶回程式碼中驗證。同一份上下文經過多次搬運，操作步驟會切碎注意力，也可能造成限制條件遺漏。
工具切換也會造成脈絡斷裂。AI 可能只看得到目前開啟的檔案，無法理解先前的架構決策。審查者只看得到最後的差異（Diff），難以掌握生成過程中的假設與取捨。團隊因此要投入更多時間追查修改來源與決策理由。
完整的開發流程應讓 AI 接近團隊既有的工作入口，並串連需求、規格、架構規則、測試結果與變更紀錄。重要提示詞、假設與決策也要保存在團隊能共同存取的位置，減少重複輸入與上下文流失，讓開發者把注意力放在工程判斷上。
程式碼審查要求開發者在短時間內理解需求背景、修改範圍、資料流向與例外情境，再判斷這次變更是否會破壞既有行為。AI 提高產出速度後，審查者面對的變更數量與閱讀密度也跟著上升，注意力會快速消耗。
疲勞出現時，審查者容易先確認程式能否執行、測試是否通過，以及畫面結果是否符合預期。權限邊界、錯誤處理、資料一致性、效能影響與後續維護成本等風險，較難從執行結果直接看見，也可能在審查中被忽略。
AI 生成的程式多半結構完整、語法流暢，使問題更難被察覺。審查者需要主動檢查程式中的假設，確認每一段處理都有明確的需求依據。精神疲累時，深入判斷容易受到表面完整度影響，讓缺少依據的設計進入系統。
小批次提交、風險分級與自動化檢查，可以保留開發者處理關鍵問題的注意力。高風險變更也需要安排熟悉領域的成員共同審查，分散判斷責任，減少重要問題依賴單一審查者發現。
待審查項目長時間排隊時，拉取請求容易被視為流程中必須快速清除的工作。審查者可能粗略瀏覽程式差異、確認測試結果，再留下「看起來沒問題」或直接核准。審查流程依然存在，實際檢查深度卻受工作量與時間壓力牽動。
形式審查會讓團隊產生錯誤的安全感。變更經過批准後，其他成員容易認為相關風險已經被確認，後續測試與部署也可能降低警覺。審查若只處理格式、命名與測試狀態，需求理解、架構方向與跨模組影響便缺少明確的檢查責任。
程式碼審查的知識分享功能也會受到影響。審查意見只剩零碎修改時，團隊難以看見方案選擇、設計理由與風險判斷。初階開發者無法從回饋中建立完整理解，資深開發者也會反覆處理相似問題。
各類變更應有不同審查深度。低風險修改可以交由自動化檢查並搭配抽樣審查。高風險修改則需要提供設計說明、測試證據與清楚的審查責任。審查時間才能集中在需要人工判斷的問題上。
審查疲勞累積後，拉取請求容易成為團隊衝突的來源。提交者等待過久，會擔心進度受阻。審查者面對大量變更，也會感到工作頻繁被打斷。雙方開始用催促、退件或簡短回覆處理問題，討論品質也會下降。
AI 生成內容若缺少背景說明，審查者還要自行推測修改意圖。當變更過大、測試不足或命名不一致等問題反覆出現，不滿容易被投射到提交者身上。提交者也可能認為審查標準缺乏一致性，進而對回饋產生防衛心態。
協作氣氛變得緊張後，成員會減少提早討論的意願。開發者可能等到程式完成後才送出審查，避免在設計階段受到質疑。審查者也可能只留下必要意見，避免進入長時間討論。資訊因此延後出現，返工範圍也會擴大。
審查負荷應被視為工作系統的一部分，定期觀察等待時間、變更規模與退回原因。審查成為瓶頸時，團隊要降低同時進行的工作量、安排共同設計，並要求 AI 產出附上需求背景、限制條件與驗證結果，減少審查者重新整理上下文的負擔。
開發者體驗（Developer Experience, DevEx）關注開發者完成工作時，能否順利取得資訊、使用工具、執行驗證並獲得回饋。AI 加入開發流程後，開發者要處理更多生成內容，原有的等待、重複操作與人工檢查也會加重工作負擔。
低價值檢查多半具有明確規則，例如格式、命名、相依套件版本、安全弱點、測試是否通過，以及程式碼是否符合既定規範。這些項目若長期依賴人工確認，注意力會被固定且重複的工作消耗，能投入需求理解、架構判斷與風險分析的空間也會縮小。
可重複判斷的規則可以放進持續整合流程，透過靜態分析、自動化測試、授權掃描與架構檢查提早攔截問題。AI 生成內容送交審查前，也應通過相同檢查，避免審查者反覆指出相似錯誤。
自動化結果需要提供可執行的資訊。系統若只顯示失敗狀態，開發者仍要花時間追查原因。完整的檢查結果應說明違反哪一項規則、影響哪個檔案，以及建議從哪個位置開始修正，讓回饋能直接銜接下一步工作。
AI 工具提高了局部產出速度，流程中的等待也會打斷工作節奏。開發者完成一段修改後，仍可能等待環境建立、測試執行、權限申請、審查或部署結果。等待期間若轉去處理其他工作，回頭時便要重新理解原有需求與程式背景。
順暢的開發流程需要縮短修改完成到取得回饋的時間。開發環境應能快速建立，測試資料要能重複產生，常用指令與建置方式也要保持一致。開發者能在本地或短時間內取得驗證結果，就能趁上下文仍清楚時修正問題。
流程狀態也要清楚易懂。變更目前停在哪個環節、由誰處理、哪些檢查失敗，以及進入下一步需要符合哪些條件，都應該能被直接看見。資訊若散落在聊天訊息、持續整合頁面與任務系統中，團隊便要投入更多時間詢問與追蹤。
團隊可以整理開發者完成一項變更需要經過的步驟，找出重複輸入、長時間等待與容易失敗的位置。移除這些流程摩擦後，開發者能保持思考脈絡，也能減少流程中斷造成的額外心理負荷。
現在的 AI 開發工具多半直接運作在儲存庫（Repository）與命令列環境中，例如 Claude Code、Codex CLI。它們可以搜尋整個專案、讀取相關檔案、執行測試、查看 Git 狀態與修改多個檔案，因此開發者體驗的重點會落在 AI 是否能順利接上團隊既有的工程流程。
團隊可以把需求規則、架構限制、測試方式與開發規範放進 AI 能直接讀取的位置。例如透過 AGENTS.md、CLAUDE.md、專案層級的上下文規則檔案（Context Files）、架構決策紀錄（Architecture Decision Records，ADR）與測試規範，讓 AI 在執行任務時能依照專案既有要求工作。這些規則也需要由團隊共同維護，避免不同成員與不同 AI 工具使用不一致的判斷標準。
AI 也可以直接接入 Git、拉取請求與持續整合與持續交付（Continuous Delivery, CD）流程。開發者可以讓 AI 產生修改計畫、執行測試、整理差異（Diff）與建立變更摘要，再由既有的程式碼分析（Lint）、靜態分析、安全掃描與自動化測試確認結果。這樣可以降低額外操作，並讓 AI 產出的修改依照原本的品質門檻進入審查。
開發者體驗還需要處理團隊使用方式的一致性。常用提示詞、專案規則、驗證指令與工作流程若能放進儲存庫共同維護，新成員與不同 AI 工具都能依照相近的方式工作。
團隊也應根據實際使用結果調整規則，減少每位工程師各自建立一套做法所產生的摩擦。
開發者的成就感經常來自解決問題、做出設計判斷，以及看見自己的決定如何改善系統。
AI 若主要用於大量生成程式碼，開發者的工作便容易集中在檢查、修正與批准。長期處理這類工作，可能削弱對成果的參與感與掌控感。
團隊可以讓開發者提早參與需求拆解、方案探索與架構討論。功能要解決的問題、現有限制與優先處理的風險，需要先被理解清楚，接著再判斷哪些部分適合交由 AI 協助。這些判斷會直接影響生成內容的方向，也能讓開發者保有解法的主導權。
對初階開發者來說，這也會成為一種訓練方式。先要求他們把需求整理成精準規格，寫清楚目標行為、業務規則、邊界條件與驗收條件，再讓 AI 依照這些內容完成實作。開發者需要先整理自己對需求的理解，再檢查 AI 產出的結果是否符合原先定義。
完成後，可以安排資深工程師陪同審查（Pair Review）。審查內容除了程式碼品質，也可以回頭檢查初階開發者的需求理解、規格描述、提示詞設計與方案取捨。
資深工程師可以指出哪些條件描述不夠精確、哪些限制有所遺漏，以及這些描述如何影響 AI 的實作方向。這類審查也能幫助初階開發者理解自己的判斷在哪個環節需要補強。
設計取捨也需要留下清楚紀錄。團隊選擇某種資料結構、模組邊界或整合方式時，可以記錄當時的背景、限制與後續影響。日後調整 AI 產出時，開發者便能依照既有決策判斷可直接修改的範圍，以及需要重新討論的部分。
開發者參與問題定義與方案選擇後，AI 便能協助實現已確認的想法。開發工作中的創造感也能從程式撰寫，延伸到需求塑形、系統設計與風險取捨。
AI 可以協助產生初稿、整理程式結構、分析錯誤、補充測試案例與探索替代方案。這些能力能縮短重複工作的時間，讓開發者投入更多心力理解系統、驗證假設與改善設計。
使用方式也會影響開發者對系統的掌控感。直接接受 AI 提供的完整答案，可能讓開發者只看到最後結果，卻不清楚修改範圍、設計理由與驗證依據。開發者可以先定義目標、限制與驗證方式，再讓 AI 在明確範圍內提出候選方案，讓修改過程保持在可理解、可檢查的範圍內。
人在開發過程中仍需要掌握最後的決策權，也就是所謂的「人在迴路（Human-in-the-loop）」。AI 可以參與分析、程式生成、測試與審查輔助，最終仍由人判斷是否採用並承擔責任。開發者不能因為程式碼由 AI 產生，就把錯誤歸因給工具。審查者也不能因為 AI 已經完成檢查，就降低原有的審查標準。
AI 產出的幻覺（Hallucination）、資安漏洞與版權爭議，都需要納入開發與審查責任。開發者需要確認生成內容是否符合需求、架構與安全規範，審查者則要依照風險程度確認修改是否適合進入系統。AI 可以提供建議與分析結果，責任仍要落在實際做出決策的人與團隊流程上。
當 AI 提供多種解法時，團隊仍需要討論各方案的風險、維護成本與適用情境，再由負責人做出選擇。這個過程能保留專業判斷，也能避免 AI 建議未經充分檢查就直接成為系統決策。
AI 的價值可以從是否擴大開發者能力來觀察。它應協助開發者加快資訊取得、驗證想法並減少重複操作。開發者仍要理解系統狀態、掌握修改範圍，並對最終結果負責。
AI 降低部分技術操作的門檻後，開發者的學習方式也會改變。過去需要花費大量時間查找資料或反覆嘗試的內容，現在可以透過 AI 快速取得方向。學習速度提高後，開發者也可能只取得答案，尚未建立足夠理解。
團隊可以將 AI 使用過程整理成共同學習材料。例如在程式碼審查中說明使用了哪些限制、排除了哪些建議，以及哪些錯誤適合整理成檢查規則。這些內容能協助其他成員理解系統，也能將個人探索轉成團隊能力。
分享形式可以保持輕量。一次簡短的方案說明、一份修改前後的比較，或一段針對 AI 建議的風險分析，都能成為有價值的學習活動。分享內容應聚焦於判斷依據、選擇理由與學到的內容，避免只展示生成了多少程式碼。
開發者看見自己的經驗改善團隊規範、測試工具、提示詞模板或開發流程後，成就感也會有新的來源。個人貢獻除了功能提交，也會反映在團隊理解問題的速度、修改系統的安全性，以及後續成員接手工作的難度。
iThome鐵人賽
看影片追技術