【AI Coding實戰】AI開始寫程式後，工程師下一步是什麼？LINE臺灣：不只寫規格，更要懂得帶AI做事

新聞

比如，有人寫了一個小工具，請AI幫忙操作公司販賣機；也有人用AI自動搜尋會議室空檔、幫忙搶會議室；還有人把一些重複性的內部流程，自動化成小程式，省去每天手動處理的麻煩。

這些原本只是工程師之間的自發性小專案，卻讓LINE臺灣企業解決方案事業部技術總監林建辰慢慢發現一件事：團隊裡幾乎每個人，都開始用AI解決工作問題。他笑說：「既然大家都在用，不如我們就找一些公司裡的小型專案來試試，看有沒有辦法用AI幫我們做出產品。」

第一步：Mini Home有7成程式碼來自AI

林建辰所帶領的LINE臺灣企業解決方案事業部技術團隊，成立於去年4月，源自LINE內部的一次組織重整。這支新團隊的工程師來自LINE內部不同技術單位，主要負責企業客戶相關的產品與解決方案。

林建辰觀察，去年5、6月，AI輔助開發和AI Agent開始在產業界快速發酵，團隊也明顯感受到，相較前年，大型語言模型（LLM）的表現和可靠度進步很多。

於是，他們決定從一個真正的小型產品開始試水溫。

這個產品，就是LINE Mini App生態系中的入口頁面「Mini Home」。Mini Home整合在LINE錢包頁面中，扮演各種Mini App的服務入口，使用者不必額外下載獨立App，就能直接在LINE應用程式內完成品牌會員、點餐、訂位等操作，甚至還能把常用服務釘選到手機桌面，就像使用原生App一樣快速存取。

這個產品去年10月正式上線，團隊從7、8月開始規畫，採用時下最直覺的Vibe Coding模式，來輔助開發。所謂Vibe Coding，是指工程師直接透過指令（Prompt）描述需求，再由AI產生程式碼，邊寫邊修正。

林建辰透露，Mini Home約70%的程式碼由AI生成，剩下30%由工程師負責調整、補強和後續測試，整體開發時間約2到3周。「如果用傳統方式做，我估計至少還要多一個月。」

這次成功讓團隊建立信心，但也很快暴露出另一個問題：Vibe Coding雖然快，卻不夠可控。

第二步：改用Spec Kit，工程師白天寫規格，晚上讓AI寫程式

林建辰形容，Vibe Coding最大的問題，就像你請一位工匠幫你做椅子，他可能第一次做出木椅；第二次你告訴他要一張人體工學椅，請他重做，結果他只在木椅加上輪子；第三次又換成別的版本。

「AI不是不會做，而是如果規格不夠明確，它很容易已讀亂回。」林建辰表示，為解決這個問題，團隊後來導入GitHub開源的Spec Kit框架，正式從Vibe Coding轉向規格驅動開發。

進一步來說，Spec Kit的核心，把開發流程拆解成4個明確的階段，先定義完整規格，再讓AI根據這些規格工作。例如，在最前面的Constitution階段，團隊會先定義技術堆疊、命名規則、程式撰寫風格，以及依賴策略；接著在Specify階段，團隊要定義功能範圍、使用流程與驗收條件；再來是Plan階段，要決定資料庫設計、API結構與系統元件；最後是Tasks階段，將規格拆成可執行任務，交由AI逐步實作與測試。

換句話說，工程師不再花大量時間告訴AI「怎麼寫」，轉而先定義「要做什麼」、「不能做什麼」、「做到什麼程度才算完成」。「以前我們白天寫code，現在變成白天寫spec，下班後讓AI寫code。」林建辰說：「因為AI不用休息，隔天白天我們就可以審查AI寫好的程式碼，加速完成專案。」

這套方法第一次大規模實戰，是應用在LINE官方帳號生態系產品OA Plus幫手市集中的一個功能元件。雖然OA Plus本身是經營多年的大型產品，不可能整個重寫，但團隊選擇其中一個中小型元件，作為Spec Kit試點專案。

（OA Plus幫手市集示意圖）

結果，一個比Mini Home規模更大的元件，只花3天就完成了。「第一天、第二天讓AI跑，第三天我們收尾、確認沒問題，專案就完成了。」林建辰說。

擁抱SDD不能一路複製，專案規模變大就得要切分規格

不過，規格驅動開發模式，並不是導入後就能一路複製。

林建辰坦言，在他的團隊裡，SDD目前仍用於中小型元件或功能模組，還沒有直接套用到真正的大型核心系統。

最大的原因，在於當專案規模越來越大，如何切分規格本身，就是一門新學問。「規格切得太大，AI一次吃不下；切得太碎，規格之間的相依性又會很難管理。」尤其當系統牽涉多個服務、資料庫與外部API串接時，團隊不只要定義單一功能的規格，還要進一步思考系統邊界、模組依賴關係，以及不同規格之間如何協作。

林建辰表示，這已經不是單純的指令工程，而更接近架構治理。「以前我們寫程式，現在更像是設計AI怎麼工作。」

這也是團隊目前還不敢直接把Spec Kit套用在超大型專案的原因，而先從元件、模組開始驗證，再逐步往更大的系統擴展。

第一次送資安審查就被打槍，LINE開始用AI監督AI

AI加速開發後，新問題也隨之浮現。

林建辰透露，團隊第一次把Spec Kit那套方法產出的程式，送交內部資安團隊審查時，原本大家都很興奮，沒想到結果卻是「不審查還好，一查一堆問題」，資安團隊甚至開出好幾張修正單。

這讓他們意識到，AI輔助開發要真正落地，資安要更早結合到開發流程中。

於是，他們先把公司內部的資安規範，直接寫進規格裡。例如，如果產品涉及個人資料，規格就必須明確定義資料加密；如果系統需要引入第三方函式庫，也必須符合公司內部審核規範，而不是讓AI自行決定。

這還不夠，LINE後來更進一步，在CI/CD pipeline中導入AI Agent，專門監督AI產出的程式碼。

林建辰透露，這個AI agent除了掃描常見漏洞外，還會透過MCP連接公司內部Wiki系統，來即時抓取最新版本的安全指引，再比對這次PR是否符合最新規範。

「因為公司的安全指引一直在更新，十幾頁、甚至更多，不可能每次都人工從頭看完。」林建辰說：「但AI可以。」這讓資安從過去的最後一道關卡，逐漸往前移到規格撰寫和CI階段。

「現在不只用AI幫忙寫程式，我們還用另一個AI，監督AI寫出來的程式碼。」但他也強調，最後負責的人，仍然是工程師。

AI輔助開發，也進入軟體開發的生命周期

從程式碼審查、系統設計，到規格驅動與資安治理，林建辰觀察到，AI真正開始改變的，不只是單一的開發環節，而是整個軟體開發生命周期。

以林建辰團隊這一年導入AI的經驗來看，軟體開發大致可拆成需求釐清、定規格、實作、測試上線，以及後續維護等5個階段，而AI幾乎每一段都開始介入。

比如，在需求階段，工程師可先用AI協助搜尋類似案例、整理市場資訊，甚至提出不同技術解法，協助團隊更快釐清問題本身。

進入定規格階段後，AI則扮演「資訊整理者」的角色。過去，產品需求可能散落在會議紀錄、郵件、即時通訊，甚至不同國家的團隊文件中，但現在，AI可以協助把不同來源的資訊整合成較完整的規格初稿，甚至主動點出邏輯不一致或驗收條件不夠明確的地方。

到了真正寫程式的階段，變化就更明顯了。

林建辰表示，過去工程師拿到需求後，不只要熟技術，也得懂產品，才能一步一步把需求變成程式，人力門檻和學習成本都不低。但現在，AI已經能先協助產出第一版程式，甚至補上一些重複性高的基礎內容，讓工程師不用再從零開始。

工程師真正花時間的地方，也從「怎麼把程式寫出來」，慢慢轉向「這樣寫對不對」、有沒有符合產品需求，以及整體架構是否合理。「現在，工程師更像審核者。」林建辰說。

至於測試階段，LINE團隊現在也開始讓AI協助生成測試案例、自動化測試腳本，甚至由QA工程師透過AI快速建立瀏覽器自動化測試流程。

而在系統上線後的維運階段，AI也開始協助整理變更日誌（Change Log）、追蹤系統異動，甚至產生架構決策記錄（ADR），記錄每次重大技術變更背後的原因，好傳承背景知識。

「以前AI只是加速寫程式，但現在，它開始深入整個開發生命周期。」林建辰強調。

從寫程式到設計AI，LINE要重新定義工程師的角色

AI不只改變開發流程，也開始重新定義工程師在團隊裡的角色。

林建辰表示，目前團隊人數並沒有因AI導入而縮減，但角色邊界開始變得模糊。比如，原本負責手動測試的QA工程師，現在開始用AI生成自動化測試腳本，甚至透過Playwright建立瀏覽器自動化測試。這讓原本需要2周才能完成的大型迴歸測試，縮短到2、3天。

前端與後端工程師的界線，也不像過去那麼明確。林建辰坦言，以前做這種自發性小專案時，工程師可能還需要找其他同事協助補前端或後端；現在，在AI的輔助下，每個人都越來越像全端工程師。

在他看來，未來工程師不會消失，但角色一定會升級。「以前工程師比較像工匠，專注把自己那一塊做好；未來更像工頭，帶著一群AI Agent一起做事。」他甚至認為，未來每位工程師，都會像一位小型產品經理，底下帶著不同功能的AI Agent，分別負責前端、後端、測試與外部系統串接。

工程師真正的價值，不在是撰寫多少程式碼，而是能不能定義問題、寫出好的規格，並對AI產出的結果負責。

寫好規格只是開始，下一步要學的是怎麼帶AI做事

對LINE團隊來說，導入Spec Kit並不是終點，而更像下一階段的起點。

林建辰透露，團隊接下來除了持續深化SDD，把更多專案從需求階段就開始規格化，也希望進一步培養自主開發AI Agent的能力。

但他坦言，真正困難的地方，從來不是把大型語言模型串接起來，而是如何讓AI Agent在企業環境中，變成一套可管理、可監控，也值得信任的系統。

舉例來說，當使用者對AI Agent下指令時，系統要不要先快取這些指令？如果要，是要做語法（Syntax）層級的快取，還是進一步理解使用者真正的意圖，做更深層的語意（Semantic）快取？這本身就是一門技術。

除此之外，當使用者與AI Agent互動時，系統是否要保留完整的稽核紀錄（Audit Log）；當後端的大型語言模型異常時，是否具備自動切換能力；甚至，如何即時監控Token用量，避免成本失控，也都是團隊接下來必須面對的新課題。

「我剛講的每一件事，其實都是一門學問。」林建辰說：「這些能力都很重要，只是過去大家都沒有真的實作，整個業界也都還在摸索。」

也因此，目前像系統部署、環境升級等高風險操作，團隊仍堅持由工程師人工把關。

「誰寫程式碼不重要，最後負責的，還是工程師。」這也是LINE團隊過去一年最大的體悟：當AI開始自己寫程式，工程師真正被放大的，不是開發能力，而是規格思維、架構視野，以及治理AI的能力。