用 AI 寫自動化腳本的安全指南：Shell、Python、Node.js

一句話說明

AI 寫自動化腳本很快，但常常在指令注入、路徑檢查、金鑰管理這幾個地方留下漏洞，跑之前一定要自己看過每一行。

AI 擅長自動化的工作

檔案整理。批次重新命名、依日期或類型分類、找出重複檔案，這類規則明確、輸入輸出格式固定的工作，AI 寫起來又快又準。

日誌解析。從幾萬行的 log 裡篩出錯誤訊息、統計某個錯誤碼出現的頻率、把不同格式的 log 轉成統一的結構，這是 AI 的強項，因為規則可以用正規表達式清楚定義，而且結果容易驗證。

資料格式轉換。CSV 轉 JSON、Excel 轉資料庫、把多個檔案合併成一份報表，這類任務結構清楚，AI 寫的轉換腳本出錯機率低，就算出錯也容易從輸出格式看出來。

API 呼叫整合。串接多個服務的 API、定期抓取資料、把不同系統的資料同步在一起，AI 對常見 API（Slack、Google Sheets、Notion 等）的呼叫方式很熟悉，寫起來效率很高。

排程任務。用 cron 或排程器定期執行備份、清理暫存檔、寄送報表，這類任務邏輯單純、失敗了重跑一次通常沒有副作用。

報表產出。把資料庫查詢結果整理成固定格式的報表，定期寄給主管或存到共用資料夾，這是很多內部工具最常見的自動化需求之一。

AI 不該用來自動化的工作

任何直接碰觸正式環境資料庫的操作。UPDATE、DELETE、批次修改正式資料這類指令，一旦 AI 寫的邏輯有誤（例如 WHERE 條件寫錯），後果可能是不可逆的資料損毀。這類腳本可以讓 AI 協助草擬，但執行前必須有資深工程師逐行審核，並且先在測試環境跑過。

金流或財務交易相關的自動化。轉帳、退款、發票產出這類牽涉到金錢的流程，任何邏輯錯誤都直接變成財務損失或法遵問題，不適合讓 AI 寫的腳本沒有人工複核就直接上線。

需要精確錯誤復原機制的場景。例如分散式系統裡的交易補償、需要保證「要嘛全部成功、要嘛全部回滾」的流程，這類邏輯需要對系統狀態有深入理解，AI 生成的錯誤處理常常只是把例外包起來印出訊息，沒有真正處理復原邏輯。

AI 生成腳本常見的安全風險

一、Shell Injection（指令注入）

AI 很習慣用字串拼接的方式組出要執行的指令，而不是用陣列參數傳遞，這是指令注入最常見的來源。

不好的寫法：

import os
filename = input("請輸入檔名：")
os.system(f"cat {filename}")

如果使用者輸入 report.txt; rm -rf ~，這段指令會變成先印出 report.txt 的內容，再刪除使用者的家目錄。

比較安全的寫法：

import subprocess
filename = input("請輸入檔名：")
subprocess.run(["cat", filename], check=True)

用陣列傳參數而不是拼字串，shell 就不會把輸入內容當成指令的一部分解析。如果一定要用到 shell 特性（例如管線），至少要對輸入做嚴格的白名單驗證。

二、Path Traversal（路徑遍歷）

AI 寫的檔案處理腳本，很少主動驗證使用者輸入的路徑是不是在預期的資料夾範圍內。

不好的寫法：

def read_user_file(filename):
    with open(f"/data/uploads/{filename}") as f:
        return f.read()

如果 filename 是 ../../etc/passwd，這段程式碼就會讀到系統檔案，超出原本 /data/uploads/ 這個範圍。

比較安全的寫法：

from pathlib import Path

def read_user_file(filename):
    base = Path("/data/uploads").resolve()
    target = (base / filename).resolve()
    if not target.is_relative_to(base):
        raise ValueError("非法路徑")
    return target.read_text()

關鍵是把路徑解析成絕對路徑之後，確認它真的還在允許的目錄底下，而不是只檢查檔名字串裡有沒有 ..。

三、硬編碼金鑰

AI 為了讓範例程式碼能夠直接跑，很習慣把 API 金鑰直接寫在程式碼裡示範。

不好的寫法：

API_KEY = "sk-live-abc123xyz789"
response = call_api(API_KEY)

這種寫法一旦程式碼被 commit 進 Git，金鑰就永久留在版本歷史裡，就算之後刪掉也還查得到。

比較安全的寫法：

import os
API_KEY = os.environ.get("API_KEY")
if not API_KEY:
    raise EnvironmentError("請設定 API_KEY 環境變數")
response = call_api(API_KEY)

金鑰放在環境變數或密鑰管理服務（例如 AWS Secrets Manager、HashiCorp Vault）裡，程式碼本身完全不出現金鑰內容，並且記得把 .env 這類檔案加進 .gitignore。

四、過度授權

AI 遇到權限錯誤時，最快的解法常常是把權限開到最大，而不是找出真正需要的最小權限。

不好的寫法：

chmod 777 /var/www/uploads

這讓任何使用者都能讀寫執行這個目錄下的檔案，等於把伺服器的門完全打開。

比較安全的寫法：

chmod 750 /var/www/uploads
chown www-data:www-data /var/www/uploads

只給實際需要的使用者和群組權限，並且區分讀、寫、執行分別要不要開放。同樣的問題也常出現在「腳本要不要用 sudo 執行」，能不用 root 權限跑的腳本就不要用。

五、缺乏錯誤處理

AI 生成的腳本常常沒有考慮失敗情境，要嘛整個崩潰不留紀錄，要嘛遇到錯誤還繼續往下跑，留下不完整的結果卻沒有任何警訊。

不好的寫法：

for file in files:
    process(file)
    upload(file)

如果某個檔案處理到一半失敗，迴圈可能直接中斷，也可能靜默略過，你完全不知道哪些檔案真正處理完成。

比較安全的寫法：

import logging

failed = []
for file in files:
    try:
        process(file)
        upload(file)
    except Exception as e:
        logging.error(f"處理 {file} 失敗：{e}")
        failed.append(file)

if failed:
    logging.warning(f"共有 {len(failed)} 個檔案處理失敗：{failed}")

每一步都記錄下來，失敗的項目集中列出，讓你事後能明確知道哪些需要重跑，而不是猜。

執行 AI 生成腳本前的檢查清單

一、逐行讀過整個腳本，特別留意 rm、curl、chmod、sudo、os.system、eval、exec 這幾個關鍵字出現的地方，弄清楚每一行實際會做什麼，不要因為腳本看起來很短就跳過。

二、先在沙盒或測試環境跑一次。可以是一個獨立的 Docker 容器、一台測試機、或至少是一個內容無關緊要的資料夾，絕對不要第一次執行就對著正式環境或重要資料跑。

三、檢查有沒有硬編碼的密鑰或密碼，搜尋腳本裡是否出現 key、password、token、secret 這類字樣後面接著實際的字串值。

四、確認所有牽涉到檔案路徑的操作，特別是有使用者輸入或外部資料來源的路徑，都經過驗證，不會被帶出預期的資料夾範圍。

五、檢查腳本有沒有對外的網路呼叫，確認資料實際上會送到哪裡去，尤其是 AI 建議安裝的第三方套件或呼叫的第三方 API，弄清楚你的資料是不是正在被送往你不知道的地方。

安全生成腳本的 Prompt 範本

與其寫完再檢查，更有效率的做法是一開始下 Prompt 時就把安全要求寫進去。

請幫我寫一個 Python 腳本，功能是〔描述你的需求〕。 要求： 1. 所有外部指令使用 subprocess 的陣列參數呼叫，不要用字串拼接或 shell=True 2. 所有檔案路徑操作要先驗證是否在允許的目錄範圍內 3. 所有密鑰、Token 從環境變數讀取，不要寫死在程式碼裡 4. 每個可能失敗的步驟都要有 try/except，並記錄清楚的錯誤訊息 5. 檔案或系統權限設定使用最小必要權限，不要用 777 或 sudo，除非你先說明為什麼一定需要 請在程式碼之後，列出這個腳本可能有風險的地方讓我確認。

最後一句特別重要，讓 AI 自己列出風險點，往往能幫你抓到一開始沒想到的問題，但這不能取代你自己逐行檢查，AI 列出的風險清單本身也可能不完整。

知識檢測

讀完文章後，測試一下你對這個主題的理解。

FAQ