初級工程師如何 AI 賦能的翻寫一個跟自己年紀差不多大的框架

會議重點

網站開發工程師、Claude Taiwan 社群管理員 Maple Kuo，分享以AI協作推動 legacy 系統現代化的實務。核心不是加快產生程式碼，而是先釐清使用者意圖、建立行為驗證，再透過分工工作流與控制機制維持品質；過去常被犧牲的測試與重構，在AI時代反而更應重視。

• 翻寫分為行為一致與重新設計兩階段；第一階段不動資料庫，以舊系統作為行為對照。
• 以規格、邏輯、結果三層驗證，結合AI審查與腳本比對，避免只憑測試通過判定翻寫正確。
• 由需求與架構文件串接實作、測試審查、程式審查及QA，讓AI協作涵蓋完整SDLC。
• 透過逐題確認、Skill、Subagent與Hook管理上下文及規範；人仍須提供使用情境、團隊慣例與驗收依據。

討論摘錄

舊系統現代化的背景與邊界

這項舊系統現代化專案，目標是將Java EE系統翻寫為Angular加上.NET的前後端分離架構。專案起因是甲方更換廠商，但系統歷史悠久，部分原始碼已遺失；團隊承接的不只是技術轉換，也包括還原既有商業行為的挑戰。

參與翻寫的Maple Kuo當時23歲，畢業於政大英文系，於4月開始第一份網站開發工作。他表示，大部分技術都是透過AI學習；入職前，主管便提出這項棘手任務，希望觀察他與其他工程師協作時，能運用AI做到什麼程度。

系統的複雜度不只來自老舊框架，也來自跨系統串接、資料庫內的處理邏輯，以及深厚的domain know-how。其中一項feature就需要解析200多條商業流程，且僅有部分原始碼可供參照。

• 前台接收外部系統透過AS2傳遞的資料。
• 前台與後台透過remote EJB溝通，後台另有自己的操作介面。
• 部分邏輯位於資料庫內，包括Stored Procedure與幾百條Trigger。

團隊將工作拆成兩個階段，先保留行為，再進行重新設計。第一階段把黑盒子系統轉為可掌握的原始碼，並在翻寫過程中逐步理解系統；第二階段才進行畫面與架構重新設計，以及功能擴充。

第一階段的邊界十分明確：不動資料庫，且新系統的行為必須與舊系統一致。這讓翻寫與重新設計分開處理，避免在還原既有行為的同時改變系統規則。

以三層驗證還原黑盒子行為

驗證翻寫是否保留舊系統行為，第一步是建立舊系統的測試環境。在缺少原始碼與既有測試的情況下，先把舊系統當作黑盒子操作，觀察輸入、輸出與資料庫狀態，再對新系統執行相同操作。Maple Kuo將驗證分為「對規格、對邏輯、對結果」三個層級，分別確認新系統能否運作、實作邏輯是否一致，以及實際結果是否相符。

• 對規格：先為新系統建立單元測試與整合測試，確認翻寫後的系統本身可以正常運作，再與舊系統進行比較。這一層驗證的是新系統的基本可用性，不能單獨作為新舊行為一致的證明。

• 對邏輯：由Claude Code與Codex檢視新舊系統的實作並進行對照。舊系統有留存原始碼的部分，直接比較程式碼；缺少原始碼的部分，則依log、CZC資料與文件進行推理，檢查翻寫後的邏輯是否與舊系統相符。

• 對結果：將相同request送入新舊系統，確認取得相同response；同時檢查操作過程中寫入資料庫的表、欄位與內容是否一致，避免只比對外部回應而忽略資料狀態的差異。

資料庫狀態的比對採用腳本直接執行機械性檢查，而非交由AI判讀。AI協助理解與對照實作邏輯，實際資料表狀態是否一致，則以可重複執行的比對結果確認。

重新設計面臨的技術債與資料疑點

第二階段的功能擴充與重新設計仍在進行，面臨的障礙不只是新需求，也包括第一階段留下的技術債。為保留既有行為而採用的Workaround與Code Smell，已成為後續開發的程式碼基礎；這些Legacy Code也會影響AI在第二階段的產出品質。

資料本身同樣存在不確定性。部分欄位從畫面規則看來應為必填，實際查詢資料時卻發現缺值或null，使重新設計無法單純沿用畫面呈現的假設。

• 系統歷經多次轉手，缺值可能源於過去廠商交接時的資料遺失。
• 欄位也可能已無人寫入，卻仍保留在系統中。
• 另有可能是其他功能寫入資料，形成與目前畫面規則不同的結果。

上述原因目前尚未確認，不能直接將缺值判定為單一問題。重新設計必須同時面對既有程式碼與資料來源的不確定性，不能僅憑畫面上的必填規則，就推定實際資料必然完整，或據此認定系統的商業行為。

文件驅動的AI分工工作流

這套AI分工工作流以PM文件與Arch架構文件串接需求、實作、審查與驗收。主agent負責協調流程，各角色依共用文件執行任務，讓需求意圖與工程規範能延續到後續檢查，而不只停留在最初的提示。

• pm skill：釐清功能背後的為什麼、使用者要解決的痛點、User Journey與狀態變化，並定義怎樣才算完成。產出的PM文件是架構設計與後續審查共同參照的依據。
• ArchSkill：依PM文件探索當前Codebase，盤點既有coding style、開發慣例與可重用內容，避免重複造輪子；同時規劃測試寫法與內容，產出Arch架構文件。
• Implementer：依架構文件實作，透過帶有開發哲學的system prompt，要求遵循既有風格、清楚命名並減少不必要程式碼。命名應讓讀者不必進入方法內部，也能推知其用途。

「欸你要先讓改動變容易 然後再做一個容易的改動」
— Maple Kuo

實作完成後，先由AI執行第一輪審查，再由講者介入檢視。審查拆成實作與測試兩個角色，分別確認工程品質與測試的有效性，避免僅以程式碼能執行或測試通過作為完成標準。

• Reviewer：檢查過度嵌套、沒有實質作用的多層轉發、race condition與N加1問題，也確認程式碼是否遵循專案風格、維持應有封裝，以及是否繞過既有invariant。
• Test-reviewer：確認測試是否反映使用者意圖、提供修改所需的confidence，並能捕捉回歸；不只追求coverage數字，也要防止AI為了讓測試通過而偷改測試、掩蓋bug。

主agent可安排一輪或多輪review，待講者確認滿意後，再交由QA以fork context啟動服務，進行API testing。驗收未通過便退回修正，直到pass，形成從文件、實作、審查到驗收的反覆檢查流程。

拆分關注點讓需求確認真正落地

AI開發流程會產生大量文件，但文件齊備不代表需求已被充分確認。當文字量超出實際閱讀與理解的負荷，審閱就容易淪為過場。Maple Kuo的做法是讓AI拆分關注點，改以分段、逐題提問的方式，讓人一次只處理一件需要確認的事。

• 逐步提出問題：要求AI不要一次交付所有待確認事項，而是逐題詢問，讓注意力聚焦在單一問題上。
• 運用AskUserQuestion：透過coding agent提供的工具進行確認，每輪最多四次，必要時可進行多輪，不必一次處理完所有疑問。
• 以具體使用者情境提問：問題應落在使用者實際會遇到的情境，確認預期如何操作、系統應如何回應，並將確認結果記錄下來，作為後續實作與驗證的依據。

這種方式將文件審閱轉為有明確焦點的需求確認：由AI提出不清楚的地方，人逐項釐清預期行為。重點不在增加文件數量，而是讓每個需要判斷的問題都獲得實質確認，降低流程流於形式的風險。

Skill與Fork AgentSkill的用途分界

Skill與Fork AgentSkill的用途分界，在於任務是否需要沿用主Session的脈絡，以及是否適合獨立執行。Skill不只有Name與Description，也可設定觸發方式、限制模型自動觸發、定義hook、指定執行的Agent，以及設定context是否採用fork機制。

Fork AgentSkill會建立全新的對話上下文，不繼承主Session的對話紀錄。因此，不能假設它知道主Session先前討論的內容；設計獨立任務時，必須注意可取得的資訊邊界。

一般Skill適合在既有對話中提供快捷操作、擴充能力或補充知識。講者將其用途區分為三類：

• 常用prompt的快捷鍵：把反覆使用的指令整理成Skill，避免每次重新輸入。
• 能力擴充：例如執行資料與環境隔離、安裝套件；reddit-search則透過背後的腳本，依輸入關鍵字到Reddit搜尋。
• 按需載入的背景知識：在任務需要時補充相關資訊。

若多個Skill與操作持續累積在主Session，任務相關內容可能與其他上下文混雜，造成干擾。Fork AgentSkill以乾淨的Session執行，可減少這類影響，但也失去主Session既有的對話脈絡；兩者應依任務需求選用，而非將所有工作集中在主Session。

Fork AgentSkill較適合通用、重複且重視結果的任務，例如Code review。這類工作可跨專案重複使用，使用者主要關心程式碼有哪些問題，而不一定需要掌握Agent逐一查看哪些檔案的過程。

以Hook自動落實開發規範

Hook可在條件成立時自動執行指定行為，將開發規範轉為明確的控制機制，而非只以自然語言要求AI遵守。Maple Kuo指出，其概念與既有軟體工程中的Hook相近，常見用途包括限制AI讀取.env，以及在修改程式碼後執行lint。

相較之下，Skill能否在適當時機被載入，取決於Description是否清楚、模型是否注意到描述，以及是否將描述與當下情境連結。若改由使用者每次手動觸發，又會增加操作負擔。因此，對於有明確觸發條件、需要反覆遵循的規範，講者選擇透過Hook自動注入提醒。

• 觸發條件：AI修改測試相關檔案時，自動提供測試撰寫規範。
• 提醒內容：測試採用BDD命名，並適度參數化。
• 使用目的：不必每次手動觸發Skill，也不只依賴Claude Code自行判斷是否需要載入相關規範。

Hook的用途不只限於禁止特定操作，也能在關鍵時機補入所需規範。講者建議善用Hook、Skill、MCP與Harness控制AI輸出，避免將規範的落實完全交給模型自行記住與判斷。

把AI省下的時間投入測試與重構

AI縮短程式碼產出的時間後，工程師應將省下的時間投入測試驗證、架構維護與品質管理，而不只是加快交付。傳統SDLC在實際執行時，測試與重構經常被犧牲，最後留下Todo、Workaround與缺少的測試；產出速度提高，更需要建立可靠的驗證機制。

測試不僅用來確認軟體行為、可靠性與穩定性，也讓工程師有信心修改程式碼。在測試保護既有行為的基礎上，再針對每次碰到的範圍進行小幅重構，逐步消除Code Smell、建立一致的開發規則。周圍程式碼也是AI的上下文：品質不佳的程式碼會影響後續產出，持續維護良好的程式碼則能提供更好的參照。

確認AI寫出的測試是否有效，不能只靠人工反覆審閱。關鍵是回到需求本身，記錄使用者的意圖、預期操作與行為，讓測試有明確依據，而非僅增加測試數量。人工檢查仍是直接的方法，但應搭配可重複使用的測試設計方法，降低反覆修改與審閱的負擔。

• 整理條件與代表值：先列出影響行為的條件，為各條件選取代表值，作為測試案例的基礎。
• 建立決策表：在寫測試前釐清哪些條件會互相影響，以及哪些組合會改變結果，再依這些組合設計測試。
• 適度縮減組合：當組合數過多時，可依條件交互作用縮減案例。講者以多數BUG由一至兩個條件互相觸發的經驗法則，說明如何減少測試組數並涵蓋多數情境。

原本由團隊分工執行的SDLC，也可以縮小到個人RD與AI協作的流程。將需求釐清、實作、測試驗證與重構納入日常開發，讓AI帶來的效率不只體現在程式碼產量，也反映在產出的可用性與品質。

人提供情境，AI探索實作方法

AI協作的關鍵，是區分技術知識與實際情境。Maple Kuo以「AI什麼都知道，也什麼都不知道」概括這項原則：AI熟悉程式碼、Design Pattern與測試方法，卻不一定知道何時、如何將這些方法用在眼前的系統。人需要提供的不是重教技術，而是讓技術選擇有依據的需求與限制。

• 使用者行為：說明使用者預期如何操作系統，讓測試能真正模擬使用情境，而不只是驗證程式本身。
• 服務規模與設計條件：提供服務規模及系統設計所需的背景，作為架構選擇的依據。
• 團隊風格：明確交代團隊慣例與coding style，不能假設AI會自行掌握。

在交付任務時，應優先描述目標與意圖，避免過早指定實作方法而成為「AI限制器」。講者引用前輩的經驗：原本要求AI採用特定方法，改成只描述意圖後，AI提出了對方未曾想到的解法。這種協作方式保留方法探索的空間，也讓工程師有機會從產出中學到新的做法。

保留探索空間不代表放棄控制。講者指出，AI產出具有非確定性，但程式碼執行結果可以驗證；因此應運用Hook、Skills、MCP等機制控制輸出，並以實際執行結果確認是否符合預期。可靠性應建立在明確情境、控制機制與可驗證結果之上，而非只因AI知道某項技術，就相信它能正確應用。

這套實務的重點，是把AI協作視為可驗證的工程流程，而非單次程式碼生成。先建立測試環境與需求依據，再透過分工審查、確定性比對及持續重構，才能在翻寫與擴充之間維持行為可信度和程式品質。

SDLCUser Journeypm skillArchSkillImplementerTest-reviewerFork AgentSkillAskUserQuestionHookHarness