金融科技AI Coding研發閉環實戰

從程式碼生成走向研發閉環：問題不只在模型

李渭寧目前負責匯豐科技的內部開源與 AI Coding 相關建設，也保有一線開發實務視角。他指出，大型金融科技組織面對的不是單一工具能否寫出程式碼，而是如何讓 AI 在既有的大量系統、複雜技術棧與嚴格品質、安全要求下，真正改善整體交付。這使 AI Coding 的討論必須從開發者個人工具，升級為涵蓋需求、設計、開發、測試、發布與營運的工程系統。

AI 工具與方法變化極快，現場以「各領風騷一個月」概括這種更新速度。這也意味著，企業若把導入建立在單一熱門產品或一次性培訓上，很快就會失去時效；更可靠的做法，是建立能持續試驗、評估、淘汰與擴散的機制。

「各領風騷一個月。」
— 李渭寧

講者特別提醒，AI 更像能力放大器，而不是自動修復器：基礎工程能力、協作規範與研發基建成熟的團隊，較可能把 AI 轉化為更高的交付效果；反之，若團隊原本缺乏約束、知識沉澱或開發基建，AI 也會放大既有混亂。這是典型的「先有軌道，列車才跑得快」問題。

企業導入的五項挑戰：效果、過程、品質、安全與規模化

在大型組織中，AI Coding 必須同時回答五個問題：交付是否真的變好、AI 是否理解企業內部上下文、品質是否下降、安全風險如何控管，以及如何從小團隊試點推進到大規模使用。講者的框架不是把這些問題拆開處理，而是將它們視為同一條研發閉環上的相互制約：只加快生成、不驗證品質與安全，最終只會更快地累積風險。

• 看效果：不能只看個人感受或程式碼產量，應觀察端到端交付結果。
• 看過程：AI 能否連接內部知識、開發規範與既有工程流程，決定了輸出是否可用。
• 看品質：交付更快不等於品質可接受，需保留並強化測試、審查與發布前檢核。
• 看安全：Agent、程式碼與資料流都可能引入新的攻擊面與敏感資訊風險。
• 看推廣：數萬人規模不能只靠少數高手，必須有可複製的工具、實踐與社群機制。

用端到端指標驗證提效，而非只算生成量

講者將「度量標準」置於 AI 導入的起點。重點不是模型一次產生多少行程式碼，而是需求進來後，從首次提交到成功上線需要多久、團隊能以多高頻率交付，以及更快發布後是否仍維持穩定。這種觀點接近 DORA Metrics 的精神：用部署與恢復等交付事實，取代對工具效果的主觀印象。

• 交付前置時間（Lead Time）：觀察需求從進入開發到部署上線的週期，判斷交付是否由月、週進一步縮短。
• 部署頻率：以團隊而非個人為單位觀察持續交付能力，避免把個人產出誤當成組織效能。
• 變更失敗率：發布更快、更多時，仍須檢查是否造成更多失敗、回退或客戶影響。
• 服務恢復時間：一旦發生問題，必須能快速恢復；速度若以穩定性為代價，並非真正的提效。

Lead Time部署頻率變更失敗率服務恢復時間DORA Metrics端到端度量

企業上下文是 AI 可用性的地基

金融科技研發的每一次變更，都要穿越需求、設計、開發、測試與發布等多個環節。對 AI 而言，真正困難的往往不是補全語法，而是能否取得並正確使用企業特有的程式碼、領域術語、文件、規範與歷史決策。講者提到，內部存在大量程式碼與知識文件；若缺少有效檢索、理解與授權機制，模型即使通用能力很強，也難以輸出符合現場約束的結果。

因此，導入重點是把企業知識轉換為 AI 可安全取用的上下文，而不是把所有資料直接餵給模型。可理解為替 AI 準備一張受管制的「工作地圖」：它應知道當前任務可使用哪些程式碼、文件與規範，也必須知道哪些內容不可存取、不可外傳。

品質治理：從覆蓋率走向內容真實性

AI 能協助生成單元測試與測試案例，但也可能產生看似完整、實則無效的測試。講者提到，品質閘門不能僅以傳統行覆蓋率或分支覆蓋率判斷，還要關注路徑覆蓋等更接近實際行為的訊號。更進一步地，AI 時代的檢查要回到內容本身：需求是否真的被覆蓋、測試的預期結果與實際結果是否合理、上線前該做的驗證是否確實完成。

• 保留 Quality Gate：將測試、程式碼審查與發布檢核作為 AI 產出的必要關卡。
• 提升測試判讀深度：不只問覆蓋率數字，也檢查關鍵執行路徑與案例品質。
• 驗證需求—測試—上線的一致性：以實際內容確認驗證工作已完成，而非只確認表單或流程已通過。
• 將 AI 用於檢查而非放棄檢查：AI 可協助比對、提示與產出報告，但人與既有控制點仍要負責最終判斷。

安全治理：讓 Agent 在護欄內工作

講者明確指出，安全不能因為 AI 導入而被「訂閱」或外包掉。尤其當 Agent 可讀取文件、操作工具或協助修改程式碼時，風險不只在模型回答錯誤，也包括資料外洩、提示注入、權限濫用與供應鏈問題。其治理思路是強化分層安全體系，讓 Agent 的工作範圍、身分、網路與憑證都受到控制。

• 工具與測試基準：先用受控工具鏈與測試標準約束 AI 的使用方式。
• 沙箱化 Agent：將 Agent 限制在明確環境與任務邊界中，避免任意取得或操作資源。
• 最小權限與身分控管：Agent 不應以員工完整身分任意執行，而應取得完成任務所需的最小授權。
• 網路與資料流限制：管控可連線範圍與資料傳遞路徑，降低敏感內容外流風險。
• 憑證與密碼保護：避免將長效密碼或高權限憑證直接交給 Agent；以受控方式提供必要權限。
• 供應鏈與開源風險：對引入的套件、元件與程式碼來源維持檢查與可追溯性。

「戴著腳鐐跳芭蕾。」
— 李渭寧

「戴著腳鐐跳芭蕾」形容得精準：在高監管與高安全要求下，開發者確實受到多重限制；但這不是放棄 AI 的理由，而是要求平台把安全護欄工程化，讓開發者能在明確邊界內高效工作。講者也分享，雖然每人每月有超過 500 美元的工具使用額度，但實際高度使用者僅約 1% 至 2%，顯示採用率不能靠預算或採購推動，必須排除流程、環境與能力上的摩擦。

沙箱最小權限身分控管網路隔離憑證管理提示注入供應鏈安全

從少數高手到全員採用：ETC 推廣框架

若要讓 AI Coding 在數萬名技術人員間擴散，講者認為不能只挑出少數高使用量者，也要研究他們為何有效，並把經驗產品化。其推廣框架可概括為 ETC：Effective Harness、Tool、Community；也就是有效駕馭 AI 的方法、可取得且可用的工具，以及可持續交流的社群。

• Effective Harness：持續學習如何與 AI 協作，提升任務拆解、指令設計、驗證與修正能力。
• Tool：提供合乎企業規範、整合既有流程的工具，降低每個團隊自行選型與建置的成本。
• Community：讓成功案例、失敗教訓與可複用實踐在社群中共享，形成共同解題的網路。

這套策略的本質，是把 AI 採用從「個人技巧」變成「組織學習」。高效使用者通常不只是更常開啟工具，而是更願意學習、理解工具特性，並主動參與社群分享。當最佳實踐能以內部平台、社群與標準化素材沉澱，其他團隊才不必每次都從零開始。

四種 AI Coding 場景：依系統階段與任務複雜度選工具

AI Coding 並不存在放諸四海皆準的導入方式。講者以「系統建設階段」與「任務複雜度」構成場景矩陣，提醒團隊依系統特性決定自動化程度。新建、低風險或驗證概念（POC）類工作，通常較適合更積極地採用生成式工具；但對需要長期演進、上下文厚重或高度關鍵的既有系統，則必須選擇較受控的協作方式。

• 新建、低複雜度或 POC 場景：可較積極使用程式碼生成與 Agent，加速探索與實作。
• 需要持續迭代的新系統：應及早建立架構、規範與上下文基礎，避免日後 AI 難以理解系統。
• 複雜既有系統：優先使用 Coding Assistant 進行局部協助，並在原有架構、流程與審查機制下完成變更。
• 高風險關鍵系統：不應因 AI 能力提升而直接放大自動化範圍，需依風險與可驗證性逐步推進。

個人筆記也保留了一項重要提醒：有些看似完整的 AI 工作流「不一定可行」。這不是否定自動化，而是要求每一種流程設計都回到系統風險、上下文完整度與驗證成本來判斷。能展示的流程，不必然能安全地投入生產。

Spec 與 PDCA：把 AI 協作變成可重複的工程流程

講者將規格（spec）視為 AI 協作的重要起點。對人類工程師而言，規格是對齊需求與設計的共同語言；對 AI 而言，它也是縮小任務邊界、提供必要上下文、降低任意生成的重要依據。與其要求 AI「幫我做完」，不如先說清楚目標、限制、輸入輸出、驗收條件與不可觸碰的範圍。

在方法上，講者以 PDCA（Plan-Do-Check-Act）串起 AI 時代的研發閉環：先規劃任務與規格，再進行開發與生成；接著透過測試、審查與度量檢查成效；最後將問題與有效做法回饋到規範、工具和知識庫。AI 讓每一步可以更快，但不能略過「Check」與「Act」；否則只是更快地重複錯誤。

specPDCAPlan-Do-Check-Act需求對齊可複用實踐持續改善

以評測與程式碼審查校正 AI 輸出

要判斷 AI 工具是否有效，不能只依供應商宣稱或開發者好感度。講者提到內部會建立工具評測與評分，並從實際工作場景檢視其通用性、適配程度與使用效果。評測應是持續性的：工具能力、模型版本與團隊任務都會變，因而需要定期重新檢驗。

程式碼審查同樣要因 AI 而升級。審查不只確認功能，也應檢查非功能性需求、依賴套件與安全風險，並產出可追蹤的報告。講者也坦言，初期報告容易出現大量雜訊或不易閱讀的問題；因此關鍵不在「找到越多問題越好」，而是提升訊號品質，協助工程師優先處理最可能、最重要的風險。

• 建立場景化評測：用真實任務檢驗工具，而非只比較通用展示效果。
• 將評測結果公開為選型依據：讓團隊能在受控範圍內選擇適合工具。
• 重視輸入與輸出控制：清楚定義可提供給模型的內容，以及輸出可進入哪一道流程。
• 以人機協作處理風險：AI 可提出問題與方案，人負責判斷優先級、正確性與是否採納。

工程師角色轉變：AI 提案，人負責洞察與判斷

講者在結尾區分「程序員」與「工程師」：AI 可以協助生成程式碼、分析問題、提出方案，但無法自動承擔系統脈絡下的責任。真正的工程工作包含理解問題根因、在多重限制中權衡方案、判讀 AI 結果是否可信，以及在生產環境中對品質與安全作出決策。

「我們不應該再做程序員一樣的事情，我們要做工程師。」
— 李渭寧

換言之，AI 不是把工程師降格為程式碼驗收員，而是要求工程師把注意力移向更高層次的洞察力與判斷力。面對異常或複雜需求，AI 或許能生成候選方案，但是否看懂根因、是否符合領域與架構限制、是否值得部署，仍須由人根據數據與事實做出判斷。

重點回顧：以事實、標準與閉環導入 AI

• AI Coding 的成敗要看端到端交付事實，而不是只看生成速度、程式碼行數或個人使用感受。
• 金融科技的導入前提是品質與安全治理；企業上下文、權限、網路、資料與憑證都必須納入設計。
• 品質閘門要從形式化指標走向內容真實性，檢查需求、測試、程式碼與上線驗證是否一致。
• 大規模推廣需依靠 ETC：有效方法、受控工具與活躍社群，將少數人的經驗轉成可複用能力。
• 依系統階段、任務複雜度與風險選擇 AI 協作模式；不是每個自動化流程都適合直接落地。
• 用 spec 與 PDCA 建立閉環，將 AI 產出持續回饋到規範、工具、知識與流程。
• 工程師的核心價值轉向洞察、判斷與責任承擔；AI 提供方案，人以數據、事實與工程原則決策。