快速摘要
工程團隊使用 AI 輔助開發已成常態，但程式碼是公司最核心的智慧財產。本文從程式碼洩漏、授權風險、安全漏洞三個面向，提供工程團隊安全使用 AI 的完整策略。
工程團隊的三大 AI 風險
1. 程式碼洩漏
當工程師把公司程式碼貼進 AI 工具時，這些程式碼可能被用於訓練模型，或被儲存在第三方伺服器上。即使 AI 服務聲稱不會使用輸入來訓練，儲存本身就是風險。
2. 授權污染
AI 模型是用大量開源程式碼訓練的，生成的程式碼可能包含受 GPL、AGPL 等 copyleft 授權保護的片段。如果未經檢查就使用，可能違反開源授權條款。
3. 安全漏洞
AI 生成的程式碼經常包含安全漏洞——缺少輸入驗證、使用不安全的函式、硬編碼密鑰等。根據研究，AI 生成的程式碼中安全漏洞的比例高於人類撰寫的程式碼。
開發工具安全比較
| 工具 | 程式碼上傳 | 本機執行 | 企業版 | 授權過濾 |
|---|---|---|---|---|
| GitHub Copilot | 片段上傳 | 否 | 有（Business/Enterprise） | 有（可選） |
| Cursor | 檔案上傳 | 否 | 有（Business） | 無 |
| Claude Code | 可讀全專案 | 可執行指令 | 透過 API | 無 |
| Cody (Sourcegraph) | 可設定範圍 | 否 | 有 | 無 |
| 本地模型 (Ollama) | 不上傳 | 是 | N/A | N/A |
飛飛建議：如果處理高機密程式碼（金融、國防、醫療），考慮使用本地部署的模型。如果是一般商業軟體，使用企業版的雲端工具加上適當的存取控制即可。
程式碼 AI 使用政策
建議工程團隊制定以下政策：
- 核准工具清單：明確列出允許使用的 AI 開發工具
- 程式碼分級：區分哪些程式碼可以給 AI、哪些不行（如核心演算法、加密模組）
- 強制 Review：所有 AI 生成的程式碼必須經過人工 Code Review
- 安全掃描：AI 生成的程式碼必須通過自動化安全掃描才能合併
- 授權檢查：啟用 Copilot 的授權過濾功能，或使用工具檢查生成程式碼的來源
- 秘密管理：.env、API Key、私鑰等檔案必須加入 .gitignore 和 AI 工具的排除清單
安全開發工作流
- 開分支：所有 AI 輔助的開發都在獨立分支進行
- 設定排除：在 AI 工具中排除敏感目錄（secrets/、config/、.env）
- 生成程式碼：使用 AI 輔助撰寫程式碼
- 人工審查：逐行檢查 AI 生成的程式碼，特別注意安全相關的部分
- 安全掃描：執行 SAST 工具（如 Semgrep、CodeQL）檢查漏洞
- 授權掃描：使用工具（如 FOSSA、Snyk）檢查授權合規
- 測試：確保有完整的測試覆蓋率，特別是邊界條件
- Code Review：由另一位工程師審查，明確標記哪些是 AI 生成的
- 合併：通過所有檢查後才合併到主分支
智財保護策略
保護公司程式碼智慧財產的具體措施：
- 不要把核心演算法給 AI：公司的核心競爭力相關程式碼不應出現在任何 AI 工具的輸入中
- 使用企業版：企業版的 AI 工具通常有明確的 IP 條款，聲明不會使用客戶輸入訓練模型
- 合約保護：在 AI 工具的採購合約中，加入智財保護和保密條款
- 員工協議：更新員工的保密協議，納入 AI 工具使用的規範
- 離職程序：員工離職時，撤銷所有 AI 工具的存取權限
常見問題
工程師可以用免費版 Copilot 寫公司程式碼嗎？
強烈不建議。免費版的 Copilot 可能會使用你的程式碼片段來改善模型，這代表公司程式碼可能出現在其他人的建議中。請使用 Copilot Business 或 Enterprise。
AI 生成的程式碼屬於誰？
根據目前多數 AI 工具的使用條款，AI 生成的程式碼歸使用者所有。但如果生成的程式碼與開源專案高度相似，可能面臨授權問題。
如何標記哪些程式碼是 AI 生成的？
建議在 commit message 中標注 AI 輔助的部分，或使用 git hook 自動添加標記。這有助於後續的程式碼審查和授權追蹤。
本地模型（如 Ollama）的程式碼品質夠用嗎？
2026 年的開源模型品質已大幅提升，對於一般的 CRUD 和 boilerplate 程式碼足夠使用。但複雜的架構設計和安全相關程式碼，仍建議使用最先進的閉源模型搭配人工審查。