快速摘要
讓 AI 修改你已經在運作的專案，比從零開始更需要小心。一個錯誤的修改可能影響線上服務。本文提供一套安全的工作流程，讓你放心讓 Claude Code 幫忙修改現有專案。
修改現有專案的特殊風險
和從零開始不同，修改現有專案有以下額外風險：
- 破壞現有功能：AI 可能在修改一個功能時意外影響另一個
- 暴露現有的敏感資訊：專案中可能有 .env、API Key、資料庫連線字串
- 覆蓋人工修改：AI 可能覆蓋你或團隊成員正在進行的修改
- 引入不相容的依賴：AI 可能建議升級或添加和現有套件衝突的依賴
開始前的準備工作
- 備份：確保所有變更都已 commit 並 push 到遠端
- 建立 .claudeignore：排除 .env、credentials 等敏感檔案
- 了解專案結構：自己先搞清楚要改什麼、影響範圍多大
- 準備測試環境：如果可能，在 staging 環境而非 production 進行修改
安全工作流程 7 步驟
- 建立功能分支：
git checkout -b feat/ai-修改名稱 - 設定 Claude Code 為 Ask 模式：確保每個操作都需要你確認
- 明確告訴 AI 修改範圍：「只修改 src/components/Header.jsx，不要動其他檔案」
- 一次只改一個功能：不要要求 AI 同時改多個功能
- 每次修改後檢查 diff：
git diff查看具體變更 - 跑測試：確保修改沒有破壞現有功能
- Code review 後才合併：自己或團隊成員審查後再 merge
如何有效檢查 AI 的修改
檢查 AI 修改的程式碼時，重點注意：
- 有沒有改到不該改的檔案：只修改了你要求修改的檔案嗎？
- 有沒有新增的 import 或依賴：AI 是否引入了新套件？
- 有沒有移除的功能：AI 是否在「簡化」的時候刪掉了重要邏輯？
- 有沒有硬編碼的值：AI 是否把 URL、Key 等寫死在程式碼中？
- 有沒有安全問題：新程式碼是否有輸入驗證？是否有 XSS 風險？
出問題怎麼辦：回復策略
因為你在功能分支上工作，回復很簡單：
# 放棄所有 AI 的修改，回到修改前的狀態
git checkout main
git branch -D feat/ai-修改名稱
# 或者只回復特定的 commit
git revert <commit-hash>黃金法則
永遠不要讓 Claude Code 直接在 main 分支上工作。永遠使用功能分支。這樣即使 AI 做了任何破壞性的修改，你都可以安全地回復。
常見問題
可以讓 Claude Code 直接修改正在線上運作的專案嗎？
強烈不建議。應該在本地開發環境或 staging 環境進行修改，經過完整測試後才部署到線上。
AI 修改的程式碼需要 code review 嗎？
需要。AI 生成的程式碼應該接受和人類寫的程式碼一樣嚴格的 review。甚至更嚴格，因為 AI 可能產生看起來正確但實際有問題的程式碼。
多人團隊中使用 Claude Code 要注意什麼？
確保每個人都在自己的分支上工作，避免 AI 修改和人類修改衝突。統一團隊的 .claudeignore 設定。建議有一份書面的 AI 工具使用規範。