企業唔敢用 AI Coding 嘅真正原因：OpenFlow 同 Quality Gates 點解決 governance 問題
2025 年到 2026 年，AI Coding 工具嘅 adoption 喺香港企業度遇到一個好有趣嘅現象：開發者個人層面嘅使用率極高，幾乎每一個有好奇心嘅 engineer 都用緊 Cursor、Copilot 或者 Codeium，但係去到 team 層面嘅 rollout，management 就會閘住。唔係因為唔知 AI Coding 有用，而係因為佢哋見到一個好現實嘅問題——點樣確保 AI 生成嘅程式碼符合公司嘅標準？點樣防止「喪 code」湧入 production？呢個唔係技術問題，而係 governance 問題。
傳統 software development 嘅 governance 靠嘅係 code review、style guide、architecture decision record（ADR）呢類人肉流程。但 AI Coding 嘅速度係人類嘅五到十倍，人肉 review 根本追唔切。結果就係：或者你接受風險，讓 AI 自由發揮然後承受 technical debt 嘅後果；或者你保持原有流程，放棄 AI 帶嚟嘅速度優勢。呢個取捨，正正係香港企業喺 AI Coding 面前停滯不前嘅真正原因。
Quality Gates：將 governance 從「人治」變「程式化」
Quality Gates 嘅核心概念好簡單：喺 code 由開發者寫好到 merge 入 main branch 之間嘅每一個關口，都設有一組可自動執行嘅檢查。傳統 CI/CD 嘅 linting 同 testing 就係最 basic 嘅 quality gates，但對於 AI Coding 嚟講，呢啲遠遠唔夠。
AI 生成嘅程式碼最大問題唔係 syntax error——LLM 寫 syntax 通常好準——而係 semantic 層面嘅問題：用錯 library 版本、忽略 error handling、產生 security vulnerability、或者寫咗同現有 codebase 風格完全唔一致嘅 code。呢啲問題傳統嘅 linter 同 compiler 捉唔到，因為佢哋喺語法層面係正確嘅。
真正有效嘅 quality gates 需要理解 project 嘅 context。例如：一個 gate 可以檢查所有新寫嘅 API endpoint 係咪都有對應嘅 rate limiting，另一個 gate 可以確保所有 database query 都用咗 prepared statement 而唔係 string concatenation。呢啲規則唔係通用嘅，而係每個 team、每個 project 自己定義嘅——而呢個定義過程，就係將 institutional knowledge 變成可執行檢查嘅過程。
OpenFlow：Documentation-as-Constraint-System
呢度就帶出 OpenFlow 嘅核心哲學——將 documentation 由被動嘅參考資料，變成主動嘅 constraint system。傳統嘅開發文檔（README、ADR、style guide）係俾人睇嘅，人會漏睇、忘記、或者解讀錯。但如果同一份知識可以變成自動執行嘅 quality gates 呢？
OpenFlow 嘅 workflow 定義唔單止係 pipeline 嘅步驟，而係每個步驟嘅「入口條件」同「出口條件」。例如一個「Add Payment API」嘅 flow，可以定義以下 constraints：必須有對應嘅 unit test（>80% coverage）、必須通過 security scan（無 high severity finding）、必須更新 OpenAPI spec、必須有 migration script 嘅 review。呢啲 constraints 唔係寫喺 wiki 度等人記得睇，而係直接嵌喺開發流程入面——如果 build 通過唔到某個 gate，根本唔會進入下一步。
呢個做法對 management 嚟講係 game-changer。因為佢哋唔再需要依賴個別 developer 嘅自律或者 senior engineer 嘅 code review 密度嚟保證質量，而係有一套可量度、可 audit、可持續改進嘅系統。Quality metrics 變成咗 real-time dashboard，而唔係季度 retrospective 嘅回顧。
香港企業點樣落地：由一個 Pilot 開始
講到呢度，你可能會問：「聽落好理想，但我哋公司連 unit test coverage 都搞唔掂，點樣跳去 quality gates？」
現實嘅落地策略係由細做起。唔需要一開始就 set 晒所有 gates，而係揀一個最痛嘅問題入手。香港企業最常見嘅 scenario 係：某個 legacy system 嘅 codebase 極度混亂，冇人敢改，但 business 又需要新功能。呢個時候，AI Coding 其實係最好嘅切入點——因為你可以用 AI 寫新嘅 module，然後喺新 module 上建立 quality gates，再逐步將舊 code 重構成符合新標準。
一個實戰嘅 pilot 流程建議係：揀一個非 critical 但有一定複雜度嘅 internal tool 或者 microservice，設定三個基本 quality gates——type safety（TypeScript strict mode）、security scan（Snyk 或者 Semgrep）、以及 architecture rule（例如：唔准直接 access database，一定要經 service layer）。然後容許 team 自由使用任何 AI Coding tool（Cursor、Copilot、Aider），但所有 code 必需要通過呢三個 gates 先可以 merge。
結果通常係點？開發速度提升 2-3 倍、bug rate 下降、而 management 見到有個 dashboard 可以 monitor，信心自然返嚟。然後先再逐步加入更多 specific 嘅 gates——performance benchmark、accessibility check、甚至係 business logic 層面嘅 invariant enforcement。
關鍵成敗因素：Developer Experience 唔可以犧牲
最後一個好重要嘅觀察：quality gates 如果設定得太煩瑣或者太慢，開發者會直接繞過佢哋——喺本地 disable 檢查、或者用各種方法 circumvention。呢個係人性，唔係紀律問題。
所以成功嘅 quality gates 系統有幾個設計原則：第一，gate 嘅檢查速度一定要快，最好喺 30 秒內完成，等 developer 可以保持 flow state。第二，gate 嘅失敗訊息要 actionable——唔係「coding standard violation」，而係「第 47 行嘅 error handling 未 cover network timeout case，建議用 withTimeout wrapper」。第三，俾 developer 有 bypass 機制，但 bypass 係 logged 同埋需要事後補飛，而唔係永遠跳過。
OpenFlow 嘅 constraint system 設計正正考慮咗呢點——每個 constraint 都有 severity level：blocker（一定要過先 merge）、warning（提醒但唔阻擋）、同埋 info（純建議）。呢個 graduated approach 令 team 可以逐步收緊標準，而唔會一下子令開發者反感。
對於香港企業嚟講，AI Coding 嘅 adoption 從來唔係技術能力問題，而係 governance 框架問題。當你有一套可以自動執行、持續改進、而且唔依賴個別英雄嘅 quality system，你就可以放心俾 AI 發揮佢嘅真正價值——唔係取代開發者，而係將開發者嘅精力從重複勞動解放出嚟，去專注喺真正需要人類判斷嘅地方：產品策略、系統架構、以及用戶體驗。