Skip to main contentSkip to footer
Search
LY Corporation Tech Blog

支持 LY Corporation 和 LY Corporation Group (LINE Plus, LINE Taiwan and LINE Vietnam) 服務，宣傳技術和開發文化。

This post is also available in the following languages. Japanese, English, Korean

從舊有系統 ( Legacy System ) 到 AI 驅動：AX (AI Transformation) 轉型路線圖

你是否曾經想過「AI 工具可以提升生產力，但我們團隊應該從哪裡開始？」把既有的舊有專案 ( Legacy Project ) 轉換為 AI 轉型 (AX (AI Transformation)) 是許多團隊面臨的挑戰。

舉例來說，如果過去從規格到測試的一個開發週期需要 2–3 天，透過自動化的 AI 流程能在 2–3 小時內完成呢？如果一天內能完成多個週期，這個改變將為團隊帶來長期且顯著的競爭優勢。

下表彙總了 AX (AI Transformation)  之後的預期變化（這代表完成本文所述四步 AX (AI Transformation) 路線圖之團隊可能達到的目標等級；實際結果視團隊規模、領域複雜度與採用速度而異）

項目轉為 AI 驅動專案後
Pull request (PR) 週期平均 2–4 小時
測試覆蓋率80% 或更高（自動維護）
程式碼審查自動化
每日合併量團隊範圍內每天 20–40 次

然而，僅僅採用 AI 工具而沒有明確方向，通常很難達到上述的生產力提升。許多團隊在 AI 採用過程中會遇到阻礙，沒有清楚的目標就難以克服這些問題。

  • 技能不均衡：團隊成員對 AI 工具的熟練度不同，降低協作效率
  • 缺乏背景脈絡：不良的文件讓 AI 無法取得適當的專案背景知識
  • 可靠性問題：測試覆蓋率不足導致 AI 產生的程式碼部署不穩定

我們組織也在以組織層級推動 AX (AI Transformation)，同時思考如何克服這些障礙。我們從分類資訊等級與遷移到安全基礎設施等基本步驟開始，然後標準化 AI 指導原則並整合到 CI/CD 中，並在實作中持續迭代。

本文是一份以「如何讓團隊層級的 AI 使用避免碎片化，成為團隊系統與文化中的穩定一部分以提升生產力？」為出發問題所整理的 AX (AI Transformation) 執行路線圖。它逐步說明了將舊有專案 ( Legacy Project )轉為 AI 驅動專案的四步 AX (AI Transformation) 路線圖，並檢視各階段的具體任務與效益。

什麼是 AI 驅動專案？

AI 驅動專案不只是用 AI 做簡單協助，而是把 AI 深度整合到整個開發週期。使用像 Claude Code 或 Codex CLI 這類的 AI 程式碼代理（coding agents），可以讓 AI 主動處理從規格撰寫到程式碼生成、測試、審查與合併的步驟，人類則專注於判斷與方向。與單純使用 AI 工具不同的是，整個團隊工作流程是以 AI 為核心設計的。

AI 驅動專案的核心方法：規格驅動開發 (SDD)

這個方法的核心是規格驅動開發（Spec-driven development，SDD）。SDD 是 AI 程式碼環境中最值得注意的方法之一。不同於先寫程式碼或測試驅動開發（TDD）的做法，SDD 先以清楚的結構定義需求與規格，然後由 AI 根據這些規格生成並驗證程式碼。藉由明確的規格，AI 能夠生成、審查並測試程式碼以完成開發。AI 模型擅長模式補完，但在完全捕捉抽象意圖上有限，SDD 補足這些限制，能產出適合 AI 工作流程的系統化結果。

AX (AI Transformation)  四步路線圖

各 AX (AI Transformation)  階段的核心目標與效果如下。

階段名稱核心目標效果
Stage 1: AI-ready消除安全風險，建立可安全使用 AI 的環境建立讓團隊能安心使用 AI 的基礎
Stage 2: AI-assist標準化使用指引並導入與 CI/CD 結合的助理流程團隊整體程式碼品質與速度可見的改善
Stage 3: AI-development基於 SDD 自動化功能實作與測試產生擺脫重複性工作，達到指數級的生產力提升
Stage 4: AI-review完成自動化，讓 AI 代理領導審查與合併實現真正的 AI 驅動開發文化，僅需最少的人為介入

每個階段都有獨立價值，並非必須完成全部四個階段才能獲得顯著效益。請依照團隊情況、風險容忍度與領域複雜度來設定目標階段，達成所選階段的核心目標即可帶來相對應的生產力提升。

Stage 1: AI-ready — 建立安全與合規基礎

採用 AI 的第一步是消除資料外洩風險並建立可靠的指導方針。雖然許多企業 AI 服務聲稱不會用客戶資料去再訓練模型，但資料外洩仍可能造成災難性後果。請依據合規標準定義允許的 AI 使用範圍，並設置流程以防止 AI 在一開始就能接觸到敏感資料。

第一階段的關鍵任務

1. 強化敏感資訊管理

除了從程式碼中移除密鑰之外，還要建立系統以防止敏感資訊在開發生命週期中曝光。

  • 消除硬編碼：移除程式碼中像是 API 金鑰、資料庫密碼與內部 IP 等硬編碼值
  • 採用動態注入：使用 secrets manager 服務，遷移到在應用執行時動態注入值的環境

2. 保護個人資料與隱私

除了機密資訊之外，務必防止可識別個人身分的資訊（PII）被送到 AI 模型。

  • 資料去識別化：在送往 AI 前對姓名、電子郵件、電話等 PII 進行遮蔽或 token 化，以避免隱私外洩

3. 保護營運關鍵資產

保護決定競爭優勢的智慧財產，例如專有演算法與複雜架構。

  • 存取控制：將 AI 可能分析或模仿的核心邏輯放在獨立的私有儲存庫，或限制 AI 對這些區域的存取，使其能以策略性的孤立方式運作

快速採用 Stage 1 的策略建議

為了建立一個能安全使用 AI 的環境，請檢視上面的檢查清單並遷移到安全環境。由於遷移通常需要時間，短期內可能難以從 AI 中看到生產力提升，導致士氣下降。因此建議採取分階段的採用策略。

  • 先定義必要需求：先選出並立即套用最關鍵的合規需求，例如對敏感資訊加密
  • 使用隔離技術：透過像系統 prompt 設定或網路隔離等 sandbox 功能限制 AI 的活動，避免敏感資料暴露
    • 使用平行驗證流程：在使用隔離技術時，同時執行能阻斷檔案系統與網路存取的驗證流程，以確保敏感資料未被曝露

Stage 1 的預期效益

  • 降低安全風險：建立一個能安心提供程式碼脈絡給 AI 的工作環境
  • 個人工作效率提升：在安全前提下使用 AI 程式碼代理能加速除錯、撰寫文件與重複性程式碼的產出速度
  • 團隊能力內部化：隨著成員逐步累積安全使用 AI 的經驗，能形成前進到 Stage 2（AI-assist）的動能

Stage 2: AI-assist — 標準化專案使用

此階段適用於團隊成員已有使用 AI，但使用方式與技能水準各異，導致輸出不一致且尚未轉化為團隊層級的生產力提升。

在此階段，將個人化的 AI 使用納入團隊工作流程。為專案建立並維護一份專案層級的 AI 指南文件、建立並管理共通技能集，並導入與 CI/CD 結合的自動化流程，使像是程式碼審查等重複性工作在團隊內得到一致性的處理。這能防止 AI 使用碎片化並將其標準化。

注意此階段 AI 並不直接撰寫程式碼。AI 主要輔助審查並支援人類所寫的程式碼。

Stage 2 的關鍵任務

1. 管理 AI 指導文件

在儲存庫根目錄建立專門的規則文件，讓 AI 能理解專案脈絡。以 AI 可讀格式撰寫專案概述、程式碼慣例、架構原則與領域術語表。

2. 採用標準技能或相關工具

建立共通的 AI 技能集，讓整個團隊能達到一致的輸出品質。

  • 採用標準 prompts 與技能：建立或採用團隊的共通技能，用於程式碼審查、頭腦風暴與規劃
    • 例如，superpowers 是一個開源的技能插件，可與 Claude Code 等 AI 程式碼代理搭配使用。它提供針對開發週期各階段的頭腦風暴、撰寫計畫與子代理驅動開發等技能

3. 建立與 CI/CD 整合的 AI 協助流程

自動化重複的審查工作，讓人可以專注於業務邏輯。

  • 基於 AI 的自動程式碼審查：當 PR 被開啟時，AI 進行第一輪審查，檢查程式碼風格、標示潛在的 bug 或安全弱點，並給予即時回饋
  • 優化審查者的工作：人類專注於 AI 無法處理的複雜業務設計與政策決策，以最大化審查效率

Stage 2 的預期效益

採用 Stage 2 時可期待的效益包括：

  • 提升基線 AI 能力：把分散的 AI 使用模式整合為團隊標準流程，提升組織整體技能水準
  • 簡化程式碼審查與協作：AI 處理重複性的審查工作，減少審查者的認知負擔，讓人能專注於更高價值的判斷
  • 維持一致的輸出品質：標準化專案規則與技能，確保程式碼品質不受作者影響

衡量 Stage 2 採用的範例 KPI

可用以下 KPI 來衡量 Stage 2 的成效：

  • 人為審查意見的變化：分析開發者留下的意見數量變化。減少代表 AI 有效取代重複性回饋，並降低審查者的認知負擔。
  • 測試覆蓋率與穩定性：追蹤程式碼庫的測試覆蓋率趨勢。覆蓋率提高代表 AI 協助撰寫測試的活躍度上升，有助於釋出可靠性與系統穩定性。

Stage 3: AI-development — 開發自動化

Stage 3 的目標是建立一個從規格直接產生可執行程式碼的自動化流程。AI 在理解既有程式碼庫的領域知識與架構脈絡後，會根據人類定義的規格生成可運作的程式碼。

Stage 3 的流程概覽

這個流程包含三個由人類掌控是否繼續並設定方向的閘門：規格審查、實作計畫審查（包含測試計畫）、以及程式碼審查。每個閘門都是 AI 在執行下一步之前必須通過的核准點。從規格輸入到建立 PR 的流程包含下面這些步驟。

Stage 3 pipeline

我們會逐步檢視這個流程。

1. 規格定義

根據既有領域知識定義初始規格。清楚列出需求、實作範圍、邊界情境與驗證標準。如果在 Stage 2 採用了 superpowers，可以使用其頭腦風暴技能把想法發展成明確規格。

在定義完規格後，由人類進行審查與批准（Human Gate 1）。此時可以調整實作範圍或增刪需求。

2. 規劃

AI 會根據規格自動產生具體的實作計畫與測試計畫。如果採用 superpowers，可使用 writing-plans 技能讓 AI 輸出實作與測試計畫。

規劃完成後，由人類審查並批准實作與測試計畫（Human Gate 2），接著才開始程式碼實作。

3. 程式碼實作

AI 在執行計畫下實作程式碼。獨立的 AI 子代理會根據計畫依序處理每個任務。如果在 Stage 2 採用了 superpowers，可使用 subagent-driven-development 技能從規格與計畫走到實作。

當人類進行最後審查並批准後，程式碼會被合併（Human Gate 3）。

Stage 3 的關鍵任務

1. 內部化領域知識並注入脈絡

為了讓 AI 撰寫出符合專案環境的程式碼，AI 需要比單純掃描程式碼更多的背景資訊。請執行以下工作：

  • 文件化知識：建立結構化文件，讓架構原則、業務邏輯特性與系統圖能被 AI 參考。把既有的規格文件轉成共通格式，以便 AI 使用。
  • 提供脈絡：在 AI 工具中建立專案專用目錄或自訂技能，或使用檢索增強生成（RAG）系統，讓 AI 在需要時查詢必要知識。

2. 流程自動化

將從規格檔建立到 PR 生成的流程自動化，包含：

  • 事件觸發：設定觸發器，讓 CI 偵測新增到特定目錄（例如 /specs）的檔案，並依序執行各階段任務（先規劃再實作）。
  • CI 設定：使用 AI 工具定義每個 CI 階段的任務。
  • 明確的核准步驟：在 CI 流程中放入 Approval Step，讓 AI 任務在未經人類批准前不會繼續。

Stage 3 的採用建議

一開始就把核心邏輯託付給 AI 可能會產生品質不佳且未針對專案最佳化的輸出，這會侵蝕對 AI 流程的信任。我們建議依下列順序逐步擴大交付給 AI 的範圍：

  1. 測試程式碼：自動產生既有邏輯的 unit 與 integration 測試
  2. 樣板程式碼：重複性的 CRUD 邏輯與 API 規格實作
  3. 業務邏輯：涉及複雜領域政策的核心功能

Stage 3 的預期效益

採用 Stage 3 時可期待的效益包括：

  • 指數級生產力提升：在 code-as-spec 的環境中，能從明確規格生成可執行程式碼
  • 擺脫重複性工作：交付具模式性的任務給 AI，讓人類專注於架構與業務決策

衡量 Stage 3 採用的範例 KPI

可用以下 KPI 來衡量 Stage 3 的成效：

  • 規格到 PR 的時間：衡量從需求定義到 PR 建立的時間。時間縮短代表自動化工作流運作正常，想法能更快轉為程式碼
  • 每日合併數：從 Git 歷史統計團隊每日合併次數。增加代表從規格到程式碼的自動化流程正在提升團隊產能

Stage 4: AI-review — 審查自動化

Stage 4 是完整自動化，AI 不再只是程式碼助理而是主導品質保證與合併決策。開發者只需專注於要建構什麼，從實作到驗證的技術工作則透過 AI 代理之間的互動完成。

盡可能用 AI 自動化，這是轉換為 AI 驅動專案的核心。在 Stage 3 的三項審查（規格審查、實作與驗證計畫審查、程式碼審查）中，程式碼審查耗費最多心力，因為它需要深度的領域與架構理解。自動化這個階段才能帶來劇烈的生產力提升。當 AI 完全負責程式碼審查時，從規格到部署的整個流程就能自動化，AI 驅動專案得以實現。

因為程式碼審查自動化意味著無需人為介入就釋出程式碼，因此優化 AI 的可信度並給予足夠時間是必要的。人們可能對於在沒有最終人類批准的情況下自動合併程式碼感到不安，但錯誤風險對人類與 AI 都存在。這最終是風險管理的問題。為了降低 AI 審查的風險，請在規劃階段徹底檢視驗證方法。經過完整檢視後，建立能涵蓋所有驗證情境的自動化流程，才能安全地用 AI 取代人類審查。

Stage 4 的流程概覽

從規格定義到程式碼合併的最終流程如下。其實 Stage 3 的流程上加了「4. AI 程式碼審查」與「5. Gatekeeper（閘門）」。

stage 4 pipeline

下文說明新增的步驟。

4. AI 程式碼審查

AI 會基於在 Stage 1–3 中累積的領域脈絡與架構知識來執行程式碼審查。使用像 superpowers 的 requesting-code-review 之類的外部插件技能可以產生具體且詳細的審查回饋。

AI 會以嚴重度等級分類問題，以指出修復優先順序：

  • Critical：發布前必須修復的致命項目，例如 bug、安全漏洞或資料完整性缺陷
  • Important：強烈建議修復的重大項目，例如效能回退、架構違規或可維護性問題
  • Minor：改善品質的選項，例如程式碼風格、命名與文件

5. Gatekeeper（閘門）

Gatekeeper 會彙整 AI 的程式碼審查結果並決定是否接受變更並合併程式碼。不要盲目地接受 AI 的審查意見，而是要依據既有的領域脈絡驗證其技術合理性再做最終判斷。使用像 superpowers 的 receiving-code-review 之類的外部插件技能可以優化回饋接受流程。

若嚴重度超過門檻（例如達到 Important 或更高），則回到實作階段進行修正，只有在所有問題解決後才批准最終合併。

Stage 4 的關鍵任務

1. 強化驗證流程

建立完整的自動化驗證流程以保證最終輸出品質。

  • 維持驗證計畫一致性：根據 Stage 3 規劃階段核准的驗證方法對最終輸出進行測試。所有新功能必須通過這些測試才可合併
  • 強化回歸測試：為主要功能建立端到端測試套件，以防新功能影響既有系統
  • 以文件為基礎的測試設計：使用整合的規格與領域知識精煉測試情境，將實作與驗證之間的落差降到最低

2. 自動化程式碼審查與合併流程

完全以 AI 取代人類程式碼審查以最大化營運效率。

  • AI 審查代理：專責的 AI，基於專案領域脈絡與架構進行訓練來執行審查。每則審查意見都帶有嚴重度等級（critical、important、minor）以明確優先順序
  • Gatekeeper（閘門）：Gatekeeper 對審查結果的有效性做最終判斷。需要採取行動的項目會回到開發階段
  • 漸進式品質改進：自動化「修正-再審查-測試」迴圈，只有在所有缺陷被解決後才批准最終合併
流程強化

即使在完整自動化情況下，仍可能發生意外的程式碼變更或持續的驗證失敗等例外情形。遇到此類情況時，人類必須介入來持續進行程式碼修正、審查與合併循環；然而介入不應僅停留在簡單修正上。分析為何流程失敗並找出 AI 遺漏的脈絡或驗證邏輯。應著重強化 AI 的審查規則與驗證流程，避免類似問題重複發生，而不是僅用人工修補目前的瓶頸。

漸進式上線策略

由於某些專案對可靠性要求非常高，可能會抵觸讓 AI 自動合併。在這種情況下，可先依據變更的重要性採用部分自動化，而非對整個程式碼庫一律適用，逐步縮小需人工審查的範圍。

例如，先讓人類審查核心業務邏輯的變更，同時允許 AI 對其他變更進行審查並自動合併。隨著 AI 審查資料與信任度累積，逐步減少人類審查的範圍。

最終工作流程

完成四階段路線圖後的最終工作流程如下：

  1. [Human] 規格定義：就需求、商業目標、介面做出關鍵決策
  2. [AI] 規劃：分析規格並建立實作與驗證計畫
  3. [Human] 計畫批准：審查並批准 AI 提出的計畫
  4. [AI] 程式碼實作：根據批准的計畫撰寫程式碼、執行單元測試並建立 PR
  5. [AI] 程式碼審查：依據領域脈絡審查程式碼並分配嚴重度等級
  6. [AI] 決策是否回饋修正：根據審查意見決定是否要求修正或批准
  7. [AI] 程式碼合併：自動將驗證通過的程式碼合併到程式碼庫

Stage 4 的預期效益

採用 Stage 4 時可期待的效益包括：

  • 消除開發瓶頸：自動化人為限制的審查流程以移除週期延遲
  • 完成 AI-driven 專案轉型：建立一個從規格到生成、審查與部署全部自動化的模型
  • 團隊聚焦真實問題：解放工程師不再被例行的程式碼審查綁住，能把資源投入於複雜的業務邏輯與架構改進

衡量 Stage 4 採用的範例 KPI

可用以下 KPI 來衡量 Stage 4 的成效：

  • AI 自動合併率：由 AI 在沒有人工審查介入下合併的 PR 比例。增加代表組織對 AI 審查的信任，以及程式碼整合流程朝自主運作邁進
  • 回歸 bug 比率：追蹤由 AI 合併程式碼導致的部署後回歸 bug。此 KPI 用以判斷 AI 設計的測試情境與驗證邏輯是否完整覆蓋實作結果。數量低代表 AI 建立的安全網有效取代了人類直覺
  • 審查週期效率：衡量 PR 建立到合併的總時間中，有多少比例耗在審查等待時間。相較於 Stage 3 的下降代表已移除人為審查瓶頸，開發生產力達到最大化

結論

由於 AI 進展快速，新模型可能會在一夜之間讓過去的工作變得過時。因此，AX (AI Transformation)  應聚焦於可持續的設計，預期技術進步，而不是單純追逐熱門工具。需要判斷哪些能夠持續存在、哪些會逐漸消退，並據此在組織中做出取捨。

這裡提出的四步路線圖聚焦於不變的要點。無論工具如何演變，軟體開發的初始輸入永遠是需求，最終輸出永遠是軟體。這也是為何路線圖以 SDD 為核心原則。人類在定義與驗證需求的流程仍然不可或缺，穩固這個結構的團隊可以透過替換核心步驟來適應新的 AI 模型或代理，而不需全面重構整個系統。

希望這份路線圖能幫助團隊超越僅僅使用 AI，透過積極利用快速變化的技術來引導可持續的生產力提升。感謝閱讀。