工程團隊 AI 導入指南：程式碼安全與智財保護

一句話摘要

工程師是 AI 工具的重度使用者，也是程式碼外洩風險最高的群體。導入 AI 的同時必須管理程式碼安全、智財保護和依賴套件風險。

工程團隊用 AI 的三個主要風險

程式碼外洩。當工程師把程式碼貼進 AI 工具時，這段程式碼就離開了公司的控制範圍。即使是企業版的 AI 工具（宣稱不會用資料訓練模型），程式碼仍然會經過第三方的伺服器處理。如果這段程式碼包含商業邏輯、演算法、或競爭優勢，外洩的損失可能很大。

實際案例：2023 年 Samsung 的工程師把晶片設計資料和會議紀錄貼進 ChatGPT，造成營業秘密外洩。Samsung 隨後全面禁止員工使用生成式 AI，後來才轉為提供內部版的 AI 工具。這個案例說明了「先禁止再開放」的代價——禁止期間員工仍在私下使用（Shadow AI），只是公司看不到了。

智財權模糊。AI 生成的程式碼可能來自訓練資料中的開源專案。如果生成的程式碼和某個 GPL 授權的專案高度相似，把它用在商業產品中可能觸發授權問題。GitHub Copilot 有提供 code referencing 功能（顯示生成的程式碼是否和訓練資料中的公開程式碼相似），建議開啟這個功能。

AI 生成程式碼的安全漏洞。AI 傾向生成「能跑」的程式碼，但不一定是「安全」的程式碼。常見問題：缺少輸入驗證、硬編碼的認證資訊、不安全的 API 呼叫方式、使用已知有漏洞的舊版函式庫。史丹佛大學 2023 年的研究發現，使用 AI 輔助寫程式的開發者產出的程式碼，在安全性上明顯低於不使用 AI 的對照組，而且使用 AI 的開發者對自己程式碼的安全性更有信心——這是最危險的組合。

工具設定：限制 AI 存取的範圍

GitHub Copilot 的 .copilotignore 設定

在專案根目錄建立 .copilotignore 檔案，語法和 .gitignore 相同。Copilot 不會讀取被排除的檔案來產生建議。

建議排除的項目：

# 環境設定和密鑰
.env*
**/secrets/
**/credentials/
*.pem
*.key
*.p12
*.pfx

# 核心商業邏輯
src/core/pricing/
src/core/algorithms/
src/core/billing/
src/core/recommendation/

# 資料庫 schema 和 migration
db/migrations/
prisma/schema.prisma
**/database/seeds/

# 內部設定
.internal/
config/production/
config/staging/
deploy/

# 安全相關模組
src/auth/
src/crypto/
src/security/

# 合規和法務
legal/
compliance/

# 基礎設施
terraform/
*.tfvars
docker-compose.prod.yml
k8s/production/

常見的錯誤：只排除 .env 但忘了 .env.local、.env.production 等變體。用 .env* 通配符可以一次涵蓋所有變體。

另一個常見錯誤：排除了 src/core/ 但忘了 tests/core/。測試程式碼通常會引用核心模組的類別名稱、函式簽章和業務規則，也應該排除。

Cursor 的 .cursorignore 和 Privacy Mode

Cursor 的設定分兩層：

.cursorignore 檔案：語法類似 .copilotignore，放在專案根目錄，指定不要被索引的檔案。

Privacy Mode：在 Cursor 的 Settings → Privacy 中開啟。啟用後的效果：

• 你的程式碼不會被送到 Cursor 的伺服器做遙測或改善服務
• 程式碼補全和聊天的請求只會送到你選擇的 AI 模型供應商（如 OpenAI 或 Anthropic），不會經過 Cursor 的中間層
• 無法使用 Cursor 自有的部分功能（例如 Cursor Tab 自動補全可能不可用）

建議的設定步驟：

1. 在 Settings → Privacy 中開啟 Privacy Mode
2. 在專案根目錄建立 .cursorignore
3. 確認 .cursorignore 的排除範圍至少和 .copilotignore 一致
4. 在 Settings → Models 中選擇符合公司政策的模型供應商

如果公司對程式碼外洩的風險容忍度很低，應該在入職設定的 SOP 中加入「確認 Cursor Privacy Mode 已開啟」這個步驟。

Claude Code 的 CLAUDE.md 設定

在專案根目錄的 CLAUDE.md 中可以設定 Claude Code 的行為準則。和 .copilotignore 不同的是，CLAUDE.md 是用自然語言撰寫的指令。

範例內容：

# 安全規範
- 不要讀取或修改 .env、secrets/、credentials/ 目錄下的檔案
- 產生程式碼時，永遠使用參數化查詢，不要用字串拼接 SQL
- 不要在程式碼中硬編碼 API Key、密碼或任何認證資訊
- 如果需要存取外部 API，使用環境變數
- 不要建議使用 eval() 或動態執行未經驗證的字串
- 不要修改 src/auth/ 和 src/crypto/ 目錄下的檔案

# 程式碼風格
- 使用 TypeScript strict mode
- 錯誤處理使用自訂的 AppError 類別
- API 回傳格式遵循 src/types/api.ts 的定義

Claude Code 也支援 .claude/settings.json 做更精細的權限控制，例如限制可執行的 shell 命令和可存取的檔案路徑。

程式碼分類與使用邊界

根據程式碼的敏感程度，設定不同的 AI 使用權限：

實務上的灰色地帶：很多工程師會問「那我可以把錯誤訊息貼進 AI 嗎？」答案取決於錯誤訊息的內容。Stack trace 如果只包含函式名稱和行號，通常沒問題。但如果錯誤訊息中包含資料庫連線字串、API endpoint URL、使用者資料，就需要先移除敏感部分。

另一個常見問題是「寫 Unit Test 算一般內部程式碼吧？」不一定。如果測試程式碼中包含了商業邏輯的預期行為（例如「當折扣碼 VIP20 配合滿三千元時，應該打八折」），這就洩露了定價規則。測試程式碼的分類應該和被測試的程式碼一致。

Vibe Coding：趨勢與風險

Vibe Coding 是近期流行的開發方式：開發者透過自然語言描述需求，讓 AI 工具（如 Claude Code、Cursor、Windsurf）產生大部分的程式碼，開發者的角色從「寫程式碼」轉變為「描述需求和驗證結果」。

Vibe Coding 適合的場景：

• 快速原型（Prototype）和概念驗證（PoC），在幾小時內建出可展示的版本
• 內部工具和管理後台，生命週期短、使用者少、安全要求相對低
• 學習新的框架或語言，用 AI 加速上手
• 一次性的腳本和資料處理工具

Vibe Coding 不適合的場景：

• 會直接面對終端使用者的產品功能，特別是涉及付款、個資或認證的模組
• 需要長期維護的核心系統，AI 產生的程式碼在可維護性上通常不如手寫
• 安全性要求高的模組，AI 容易遺漏邊界條件和安全檢查
• 效能敏感的模組，AI 傾向產生正確但效率不高的實作

Vibe Coding 的安全注意事項：

在描述需求的 Prompt 中，容易不小心透露敏感資訊。例如：「幫我寫一個 API，連接 production 的資料庫 postgres://admin:P@[email protected]:5432/production」——這段 Prompt 包含了真實的資料庫連線字串。正確做法是用佔位符：「幫我寫一個 API，連接 PostgreSQL 資料庫，連線字串從環境變數 DATABASE_URL 讀取」。

Vibe Coding 產生大量程式碼後，工程師容易跳過逐行審查。飛飛的建議是：用 AI 產生程式碼後，至少要做三件事——跑測試確認功能正確、用 linter 和 SAST 工具掃描安全漏洞、人工看過所有的外部 API 呼叫和資料庫查詢。

AI 生成程式碼的常見安全漏洞

以下是 AI 程式碼生成中最常見的安全問題，按照 OWASP Top 10 分類：

注入攻擊（Injection）。AI 經常生成字串拼接的 SQL 查詢，而不是使用參數化查詢。

有問題的寫法：

# AI 常生成這樣的程式碼
query = f"SELECT * FROM users WHERE email = '{email}'"
cursor.execute(query)

安全的寫法：

# 應該使用參數化查詢
query = "SELECT * FROM users WHERE email = %s"
cursor.execute(query, (email,))

跨站腳本攻擊（XSS）。AI 在生成前端程式碼時，經常直接將使用者輸入插入 HTML，沒有做跳脫處理。

// AI 可能產出
element.innerHTML = userInput;

// 安全做法
element.textContent = userInput;
// 或使用框架的自動跳脫機制（React 的 JSX 預設會跳脫）

硬編碼的認證資訊。AI 在產生範例程式碼時，喜歡直接寫死 API Key 和密碼。

// AI 常生成
const apiKey = "sk-abc123def456";
const client = new OpenAI({ apiKey });

// 安全做法
const apiKey = process.env.OPENAI_API_KEY;
if (!apiKey) throw new Error("OPENAI_API_KEY not set");
const client = new OpenAI({ apiKey });

不安全的隨機數生成。AI 在需要產生 token 或 session ID 時，有時會用 Math.random() 而非密碼學安全的隨機數生成器。

// 不安全
const token = Math.random().toString(36).substring(2);

// 安全做法
const crypto = require('crypto');
const token = crypto.randomBytes(32).toString('hex');

缺少輸入驗證。AI 生成的 API endpoint 經常直接信任前端傳來的參數，沒有做型別、長度和範圍的驗證。

過於寬鬆的 CORS 設定。AI 很喜歡在 CORS 設定中用 *，允許所有來源存取。

// AI 常生成
app.use(cors({ origin: '*' }));

// 安全做法：指定允許的來源
app.use(cors({ origin: ['https://app.example.com'] }));

使用已棄用的加密演算法。AI 的訓練資料包含舊的程式碼，可能建議使用 MD5 或 SHA1 做密碼雜湊，而不是 bcrypt 或 argon2。

Code Review 工作流整合

把 AI 審查作為人工審查的前置步驟：

步驟一：開發者提交 PR。

步驟二：自動化工具先跑一輪。靜態分析工具（ESLint security rules、Semgrep、Bandit）檢查已知的漏洞模式。AI Code Review（Copilot PR review 或 Claude Code）做更廣泛的審查。

步驟三：人工 reviewer 收到 AI 的審查報告，重點看 AI 標記的問題、商業邏輯正確性、架構設計。人工 reviewer 不需要花時間在 AI 已經抓到的語法和格式問題上，可以專注在更高層次的判斷。

步驟四：所有 PR 必須有至少一位人工 reviewer 的 approve 才能 merge。AI 的審查結果可以當參考，但不能取代人工 approve。

AI 生成程式碼的 Code Review 檢查清單：

安全性檢查： - 所有的使用者輸入是否有驗證和消毒（sanitization）？ - SQL 查詢是否使用參數化查詢？ - 是否有硬編碼的密鑰、密碼或連線字串？ - 錯誤處理是否會洩露系統內部資訊（完整的 stack trace 回傳給前端）？ - API endpoint 是否有適當的認證和授權檢查？ - 是否使用了已知有漏洞的套件版本？

邏輯性檢查： - 邊界條件（空值、零、極大值、負數）的處理是否正確？ - 並發情境（race condition）是否處理？ - 錯誤路徑（error path）是否有正確的清理（cleanup）和回滾（rollback）？

品質檢查： - 程式碼是否符合專案的命名規範和架構模式？ - 是否有不必要的複雜度（AI 有時會過度工程化）？ - 是否有重複的程式碼可以抽取成共用模組？ - 測試覆蓋率是否足夠？

AI 輔助測試

AI 在測試領域的三個用途：

產生 Unit Test。這是 AI 目前做得最好的測試類別。給 AI 一個函式，它通常能產出涵蓋正常路徑（happy path）的測試。但要注意以下問題：

• AI 產生的測試傾向測試「函式目前的行為」而非「函式應有的行為」。如果函式本身有 bug，AI 的測試會把 bug 當成正確行為來驗證
• AI 經常遺漏邊界條件的測試：空字串、null/undefined、極端數值、特殊字元
• AI 產生的 mock 可能過於寬鬆，真正的整合環境中會失敗

使用 AI 生成 Unit Test 的正確流程：

1. 先寫清楚函式的規格（輸入、輸出、邊界條件、預期錯誤）
2. 讓 AI 根據規格產生測試
3. 人工檢查：邊界條件是否涵蓋、mock 的行為是否合理、assertion 是否檢查了正確的東西
4. 手動補充 AI 遺漏的測試案例

產生 Integration Test。AI 在這裡的表現比 Unit Test 差很多。Integration Test 需要理解系統的架構、服務之間的互動、資料庫的狀態管理。AI 通常能產出看起來像 Integration Test 但實際上只是在測試 mock 的程式碼。

建議：Integration Test 的框架和設定（資料庫連線、測試資料準備、清理）由人工撰寫。個別的測試案例可以用 AI 輔助，但要確認它真的在測整合而不只是 mock。

產生測試資料。AI 很適合用來產生大量的測試資料：不同格式的 Email、各種長度和字元組合的字串、邊界值的數字。Prompt 範例：「產生 20 組測試用的台灣手機號碼，包含正確格式、缺少國碼、長度錯誤、包含字母等各種情況」。

AI Pair Programming 的實務做法

AI Pair Programming 指的是開發者和 AI 工具即時協作開發的模式。和傳統的兩人 Pair Programming 類似，但 AI 扮演 navigator（導航者）或 driver（駕駛者）的角色。

有效的使用方式：

讓 AI 當 driver，你當 navigator。你描述邏輯和架構，AI 負責寫出程式碼。你的工作是審查 AI 寫出的每一段程式碼，確認邏輯正確、安全、符合專案風格。這個模式適合 boilerplate code 和 CRUD 操作。

讓 AI 當 navigator，你當 driver。你自己寫程式碼，但遇到問題時問 AI：「這段程式碼有什麼安全問題？」「有沒有更有效率的寫法？」「這個函式庫的用法對嗎？」這個模式適合複雜邏輯和安全敏感的模組。

讓 AI 做 Rubber Duck Debugging。把你的程式碼和問題描述給 AI，讓它幫你分析可能的 bug 原因。這比傳統的對著橡皮鴨講話有效得多，因為 AI 真的會分析程式碼。

不好的使用方式：

讓 AI 生成一大段程式碼然後直接用，不看就 commit——這不是 Pair Programming，這是讓 AI 替你工作而你不審查。

讓 AI 決定架構。AI 可以建議架構選項，但架構決策需要考慮團隊的技術能力、維護成本、業務需求等 AI 看不到的因素。

完全依賴 AI 解決問題而不自己思考。長期下來你的問題解決能力會退化。用 AI 加速，但不要讓 AI 代替你學習。

本機部署 AI 工具：Ollama 設定指南

對於敏感程式碼，本機部署的 AI 工具是唯一不需要將程式碼送到外部伺服器的選項。以下是使用 Ollama 搭配 IDE 擴充功能的設定步驟。

安裝 Ollama：

# macOS / Linux
curl -fsSL https://ollama.com/install.sh | sh

# Windows
# 從 ollama.com 下載安裝程式

下載適合程式碼輔助的模型：

# CodeLlama 7B - 輕量版，適合 16GB RAM 的機器
ollama pull codellama:7b

# CodeLlama 13B - 品質更好，建議 32GB RAM
ollama pull codellama:13b

# DeepSeek Coder V2 - 目前開源中程式碼能力較強的模型
ollama pull deepseek-coder-v2:16b

# Qwen 2.5 Coder - 對中文的支援較好
ollama pull qwen2.5-coder:7b

硬體需求參考：

沒有 GPU 也可以跑，但速度會慢很多（用 CPU 推論）。Apple Silicon Mac（M1 Pro 以上）用 Metal 加速可以達到不錯的速度。

搭配 VS Code 使用（Continue.dev 擴充功能）：

1. 在 VS Code 中安裝 Continue 擴充功能
2. 打開 Continue 的設定檔（通常在 ~/.continue/config.json）
3. 設定使用本機的 Ollama：

{
  "models": [
    {
      "title": "Ollama CodeLlama",
      "provider": "ollama",
      "model": "codellama:13b",
      "apiBase": "http://localhost:11434"
    }
  ],
  "tabAutocompleteModel": {
    "title": "Ollama Autocomplete",
    "provider": "ollama",
    "model": "qwen2.5-coder:7b"
  }
}

1. 重新載入 VS Code
2. 在編輯器中用 Cmd/Ctrl + I 呼叫 AI 聊天，或等待自動補全建議

本機部署的限制：模型的能力比雲端的 GPT-4 或 Claude Opus 差一個等級。複雜的邏輯推理、跨多個檔案的上下文理解、和長文理解都比較弱。但對於程式碼補全、簡單的函式生成、和語法查詢已經堪用。

依賴套件安全掃描

AI 建議的套件不一定安全。飛飛在做程式碼安全審查時，曾多次發現 AI 建議使用的 npm 套件在 npm registry 上已經被標記為 deprecated 或有已知漏洞。

常見的風險：

Typosquatting（名稱相似的惡意套件）。AI 的訓練資料中包含大量的套件名稱，有時會推薦名稱拼寫稍有不同的惡意套件。例如推薦 crossenv 而非正確的 cross-env。每個 AI 建議的套件都要在 npmjs.com 或 pypi.org 上確認。

已棄用的套件。AI 的訓練資料有時間差，可能推薦兩年前流行但現在已經不再維護的套件。檢查套件的最近一次發布時間和 GitHub 的維護狀態。

已知漏洞的版本。AI 可能建議安裝特定版本的套件（例如 [email protected]），但那個版本有已知的 Prototype Pollution 漏洞。

建議的掃描工具和流程：

npm audit：Node.js 內建，每次 npm install 後自動執行。可以在 CI/CD pipeline 中加入 npm audit --audit-level=high，有高風險漏洞時中斷建置。

Snyk：商用的漏洞掃描工具，有免費方案（每月 200 次測試）。可以整合到 GitHub PR 中自動掃描。能偵測直接和間接依賴的漏洞。

# 安裝 Snyk CLI
npm install -g snyk

# 掃描專案的依賴
snyk test

# 持續監控（Snyk 會在發現新漏洞時通知）
snyk monitor

Socket.dev：專門偵測供應鏈攻擊的工具。分析套件的行為（是否存取網路、是否讀取環境變數、是否執行 post-install script），找出可疑的套件。

pip-audit（Python）：

pip install pip-audit
pip-audit

建議的 CI/CD 整合：在每次 PR 和每日建置中執行依賴掃描。設定阻斷規則：高風險（High）和嚴重（Critical）漏洞必須修復才能合併。中風險（Medium）的漏洞記錄追蹤，在下一個 sprint 處理。

衡量 AI 對工程生產力的影響

導入 AI 工具後，管理層通常會問「效果如何？」以下是可以衡量的指標和方法。

可量化的指標：

PR 合併時間：從 PR 建立到合併的平均時間。導入 AI Code Review 後，這個指標通常會改善（因為初步審查更快）。

程式碼品質指標：用 SonarQube 或 CodeClimate 追蹤程式碼的 bug 密度、技術債比例、測試覆蓋率。理想情況下，導入 AI 後這些指標至少維持不變。

開發者自評：每季做匿名調查，問工程師覺得 AI 工具對自己的工作效率有多少幫助（1-10 分）、在哪些任務上最有幫助、什麼地方反而增加了工作量。

安全掃描結果：追蹤每個月掃出的安全漏洞數量和嚴重程度。如果 AI 導入後漏洞數量明顯上升，需要加強 Code Review。

不建議量化的指標：

程式碼行數。AI 可以輕鬆產生大量的程式碼行數，但行數和價值沒有正比關係。用行數衡量 AI 的效果會鼓勵工程師讓 AI 產生冗長的程式碼。

PR 數量。同理，AI 可以加速 PR 的產出，但如果 PR 的品質下降（更多 bug、更多返工），數量的增加沒有意義。

衡量的注意事項：導入 AI 工具後的前 1-2 個月是學習期，生產力可能暫時下降（學習工具、調整流程）。至少觀察 3-6 個月再做結論。不要把 AI 工具的效果和個別工程師的績效掛鉤——這會導致工程師過度依賴 AI 或不願使用 AI（取決於績效標準）。

安全考量

API Key 和 Token 的管理。工程師在使用 AI 工具的 API 時，要用環境變數管理 API Key，不要硬編碼在程式碼中。特別注意：.env 檔案不要被 commit 到 git。建議在 .gitignore 中永遠包含 .env*。如果不小心 commit 了 API Key，要立即到該 AI 服務的後台撤銷該 Key 並重新產生。Git 的歷史紀錄中仍然保有舊的 Key，需要用 git filter-branch 或 BFG Repo-Cleaner 來清除歷史紀錄中的 Key。

AI 生成程式碼的依賴套件風險（詳見前面的「依賴套件安全掃描」段落）。

AI 產生的 Dockerfile 和 CI/CD 設定。AI 生成的 Dockerfile 可能使用不安全的基礎映像檔（使用 latest tag 而非固定版本）、跑在 root 權限（沒有建立非特權使用者）、或暴露不必要的端口。CI/CD pipeline 設定（GitHub Actions、GitLab CI）如果有安全問題，影響範圍是整個部署流程。例如 AI 可能建議使用 actions/checkout@v3 但沒有 pin SHA，如果 action 被入侵，你的 CI 環境也會受影響。這些設定檔建議人工撰寫或至少由資深工程師審核。

AI 工具本身的帳號安全。開啟 AI 工具帳號的雙因素認證（2FA）。不要共用 AI 工具的帳號——共用帳號的問題是無法追蹤誰上傳了什麼。離職員工的帳號要及時停用。

常見問題

# 在 PR 觸發的 workflow 中
- name: Run Semgrep
  uses: returntocorp/semgrep-action@v1
  with:
    config: p/security-audit

- name: Run npm audit
  run: npm audit --audit-level=high

- name: Run Snyk
  uses: snyk/actions/node@master
  env:
    SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}