Michael AI Agent Lab
Michael AI Agent Lab：AI Agent 培訓 既有專案 AI 改 程式碼 安全流程
培訓資料庫

工程工作流程

先看懂，
再動手。

舊專案不是空地。讓 AI 進來改 程式碼 前，先定位畫面、追清楚資料流、寫出不能踩的邊界，再用小步 審核 與回歸驗證把風險壓住。

既有專案 專案 AI 程式開發防護規則 回歸檢查

先判斷場地

AI 很擅長從零開始，但公司常見的是已經有人使用、已經有規則、已經有共用邏輯的系統。兩種場景不能用同一種交辦方式。

全新開發：從零開始

適合快速建立雛形。規則少、相依少，AI 可以主導架構和檔案安排。風險在於初期太快，後面若沒有治理，很快就會變成難維護的 既有專案。

既有專案：接手既有系統

適合用探索式流程處理。重點不是讓 AI 立刻寫，而是先讓它看懂既有元件、資料來源、共用 hook、錯誤處理與測試方式。

兩種操作模式

依照你對 codebase、工具和 AI 的熟悉度選路徑。兩條路的共同規則是：探索階段只分析，不修改。

AI 輔助開發
你手動找檔案，AI 幫你讀得更快。 適合網頁版 AI、初次接觸 codebase、或還不放心讓 代理 自己改檔案的情境。你負責打開 DevTools、全域搜尋、貼相關檔案，AI 負責整理結構與風險。
指揮式 代理
代理 讀整個專案，先回報地圖。 適合 Claude Code、Cursor、Codex 這類可讀 儲存庫 的工具。先要求它定位、追 資料流、列共用相依，再把探勘結果輸出成架構導覽圖。

Michael AI Agent Lab 操作 SOP

這份流程可以直接套到既有團隊工具、教材網站、儀表板、或任何已經有人使用的系統維護任務。

01

定位畫面：找出要改的那一塊在哪裡

先用畫面文字、class、測試標籤或 DOM 線索回到原始檔。要求 AI 列出父元件、子元件、共用元件、頁面專屬元件。這一步的輸出應該是一張「畫面到檔案」的地圖。

02

追資料流：知道資料從哪裡來、往哪裡去

檢查 package.json、hooks、store、API client、mutate/dispatch/setState、logger。特別要求 AI 標出被共用的 hook 或型別，因為這些通常是改 A 壞 B 的來源。

03

寫 安全護欄：需求不是一句話，而是一組施工規則

需求要寫清楚既有 pattern、可重用元件、禁動檔案、權限/routing/共用 hook 的邊界、測試要求。既有專案 裡的 clean 程式碼 不是炫技，而是跟既有專案一致。

04

小步 審核：先規劃，再一塊一塊改

先看元件結構和資料流規劃，再改 hook，再改 UI，再補互動。每一步 審核 的重點是：有沒有偏離原本寫法、有沒有偷偷動共用檔、有沒有重做既有元件、有沒有漏 載入與錯誤狀態。

05

回歸驗證：證明沒有弄壞別人的功能

改前跑一次既有測試，改後每完成一小塊再跑一次。沒有測試時，先補最關鍵的路徑。對被共用的 hook 或資料型別，要列出所有使用處並逐一確認輸入、輸出、預設值沒有被破壞。

決策檢查表

每次把既有專案交給 AI 前，先用這四個問題決定能不能進入實作。

它知道在哪裡改嗎？ 沒有畫面到檔案地圖，就只能猜。
它知道誰共用嗎？ 共用 hook、元件、型別要先列出。
它知道不能動哪裡嗎？ 禁動區要寫進 提示詞，不要靠默契。
它有辦法驗證嗎？ 測試、建置、截圖、紀錄 都是可讀證據。

可複製 提示詞

把下面幾段當成 既有專案 任務的起手式。重點是先限制 AI 的動作，再要求它產出可檢查的證據。

1. 探索畫面，不改 程式碼

請先找出「[畫面區塊/功能名稱]」是由哪些檔案渲染的。
請列出父元件、子元件、共用元件，以及可能影響其他頁面的元件。
這個階段只做分析，不要修改任何 code。

2. 梳理 資料流

請梳理這個功能的 data flow：
1. 資料從哪個 API 或資料源進來
2. 使用哪套狀態管理或 fetching pattern
3. 使用者操作後資料如何回到 server
4. 哪些 hook / 型別 / 元件被其他頁面共用
請用白話文加上 function 順序說明。

3. 帶規則的需求

請在既有功能上新增 [需求]。
動手前先讀相關 hook、共用元件、型別定義與測試。
要求：
- 沿用專案既有 pattern
- 重用現有元件，不要重做
- 不要改 routing、權限、全域設定
- 不要改動被其他頁面共用的 hook 行為
- 每一步完成後回報 diff 與驗證結果

4. 審核 與回歸檢查

請用資深工程師角度 review 這次改動：
1. 有沒有偏離專案既有命名、資料夾結構或 fetching pattern
2. 有沒有偷偷改到共用檔案
3. 有沒有漏 loading / error / empty 狀態
4. 哪些既有測試應該重跑
5. 哪些使用同一個 hook 的頁面需要回歸檢查

風險控制

這些是舊專案最常出事的位置。教材、內部 儀表板、工具網站都適用。

共用 Hook

改資料格式、預設值或參數名稱前，必須列出所有使用者。若不能保證相容，就新增 adapter 或局部 wrapper。

重複造輪子

新增 UI 前先搜尋 Table、Modal、Select、Toast、Form pattern。舊專案的乾淨寫法通常是「跟大家一樣」。

錯誤紀錄

不要隨手寫 console。先查專案 logger 的格式、error code、metadata 欄位與送出位置，讓新功能說同一套語言。

來源與審稿依據