生活分享

Claude Code|Plan Mode 與權限模式

在規劃與實作之間控制操作權限。Plan Mode 用來先探索與提出方案,權限模式則決定工具操作如何獲准。本篇會在待辦專案先做一次規劃,再切到可審查的實作模式,並用一條精確測試規則理解 allow、ask、deny。你會知道「我說不要改」與工具層的授權控制有何差別。

閱讀時間約 5 分鐘

Plan Mode 與權限模式:文件、螢幕與完成記號的幾何插圖
圖片:Mokaair (© Mokaair)
本篇目錄
  1. 先用 Plan Mode 探索
  2. 看懂常見權限模式
  3. 從規劃走到實作
  4. 用 /permissions 看規則來源
  5. 建立一條小範圍測試規則
  6. 指引、權限與沙箱的邊界

Plan Mode 用來先探索與提出方案,權限模式則決定工具操作如何獲准。本篇會在待辦專案先做一次規劃,再切到可審查的實作模式,並用一條精確測試規則理解 allow、ask、deny。你會知道「我說不要改」與工具層的授權控制有何差別。

請先準備正常運作的,並讀過。本篇只在專用練習目錄操作,不要求略過所有權限提示。不同介面對模式的顯示名稱可能不同,先看它描述的行為,再對照 CLI 的設定值。

先用 Plan Mode 探索

先用 Plan Mode 探索 → 看懂常見權限模式 → 從規劃走到實作
先用 Plan Mode 探索 → 看懂常見權限模式 → 從規劃走到實作 · 圖片:Mokaair (© Mokaair)
閱讀完整文字說明

Plan Mode 與權限模式,以流程和文件圖形呈現教學重點。

在新啟動時可以使用 --permission-mode plan,已開啟的對話也可用 /plan。進入後檢查目前模式指示,再交代需求。規劃應產出檔案範圍、資料處理方式與驗收步驟,不能只列「分析、開發、測試」三個抽象階段。

專案終端機:直接以規劃模式啟動 · bash
claude --permission-mode plan
Claude Code 對話框:要求具體方案 · text
請先規劃待辦清單的全部、未完成、已完成三種篩選。
說明要修改的檔案、如何保留原始資料、要補哪些測試。
先不實作,不安裝套件,不建立 Git 提交。

Plan Mode 允許探索與分析,不應把它理解成完全不使用工具的普通聊天。它會依支援的規則讀取資訊與進行規劃流程。若你的要求是嚴格只讀某幾個檔案,也要在任務中說清楚範圍,並檢查實際工具紀錄。

看懂常見權限模式

模式或設定值主要行為初學時怎麼使用
Manual/default依工具與規則要求確認審查每次重要操作
Plan/plan探索並提出方案先確認設計與驗收
Accept edits/acceptEdits自動接受多數檔案編輯仍需檢查其他命令授權
Auto/auto由分類機制檢查操作先了解資格與限制
bypassPermissions跳過多數權限確認不作為本篇練習方法

自動接受編輯不等於允許所有 shell 命令,Auto 也不等於完全無限制。模式是整體行為的一部分,具體權限規則與管理政策仍會影響結果。看到一個操作被擋下,先讀原因,不能只認為切到另一個模式就應該全部放行。

從規劃走到實作

閱讀方案,確認篩選只影響顯示、項目仍以 id 處理,測試涵蓋切回全部時資料不丟失。若方案過大,要求縮小;確認後從介面切到適合審查的實作模式,再明確要求實作。不要一邊保留「這輪只規劃」,一邊期待檔案已被修改。

切到實作模式後的 Claude Code 對話框 · text
請依剛才確認的方案實作篩選。
保留新增、勾選、刪除,不能因篩選丟失原始項目。
修改後執行既有與新增測試,提供差異及瀏覽器驗收結果。

遇到權限提示時,查看實際工具、命令與目標位置,再決定一次允許或保存規則。長期允許的影響可能超出這一輪,尤其在儲存庫與 worktree 間有共享設定時。初次練習先使用一次性授權,比立刻建立寬泛規則容易理解。

用 /permissions 看規則來源

開啟 /permissions,查看 Allow、Ask、Deny 與各規則的來源檔。允許規則讓匹配工具免去手動確認,詢問規則要求確認,拒絕規則阻擋匹配操作。官方判斷順序是 deny、ask、allow,較精確的 allow 不會自動突破較廣的 deny。

Claude Code 對話框:查看目前權限規則 · text
/permissions

例如你允許某個精確測試命令,但同時有匹配它的 deny,仍會被拒絕。這不是設定失效,而是規則順序使然。先查匹配來源並理解團隊目的,再修正錯誤規則;不要用反覆添加更多 allow 的方式堆疊矛盾設定。

建立一條小範圍測試規則

以下範例適用於使用 Bash 工具執行 npm test 的環境。先閱讀 package.json,確認 npm test 實際做什麼,再考慮允許。若原生 Windows 工作使用的是 PowerShell 工具,就要依該工具的官方規則格式設定,不能把 Bash 規則當成所有 shell 通用。

合併到 .claude/settings.local.json:Bash 工具範例 · json
{
  "permissions": {
    "allow": ["Bash(npm test)"]
  }
}

保存後用 doctor 確認格式,再用 /permissions 看規則來源,最後要求執行一次 npm test,觀察是否依預期匹配。規則允許的是命令形式,不是保證該腳本永遠沒有副作用;之後 package.json 改變時,也應重新檢查原先批准的命令內容。

練習結束後,從正確來源移除本次加入的 allow,保留其他既有規則。若你是在介面新增,確認它寫入哪個範圍,再從同一處管理。不要為了撤回一條規則刪掉整份設定,因為那可能同時移除其他必要限制。

指引、權限與沙箱的邊界

拒絕一個操作後,可以附上具體原因,例如「這個命令會推送遠端,這輪只做本機驗證」。這能讓 Claude 改用符合範圍的方法。理由應指出真正邊界,不必只寫不准,否則它可能不知道應停止整個任務,還是繼續其他已允許的步驟。

CLAUDE.md 表達希望模型怎麼工作;權限規則由 Claude Code 控制哪些工具操作可執行;則提供另一層檔案或網路隔離。三者用途不同,也有平台限制。寫一條「不要讀金鑰」的 MD 規則,不等於作業系統已封鎖所有讀取方式。

小練習是完成規劃、審查方案、實作小功能,再查看並移除一條精確測試規則。保留每一步的模式與實際結果。完成時應能解釋為什麼某次工具操作被詢問或拒絕,也能區分指引與真正的授權控制。需要事件層的自動檢查時,再接著讀。

回總目錄

  • 生活分享

    Claude Code|建立第一個 mod:在 Claude Code 行程內數工具呼叫

    寫一個三檔案的 mod,用驗證器與測試確認它掛上的事件。文件把 mod 定義成多了入口檔的 plugin:入口檔叫 hooks module,Claude Code 在事件發生時呼叫裡面的函式,函式可以觀察、改寫或接手事件。

  • 生活分享

    Claude Code|Git Worktree 平行工作

    隔離多個任務的檔案與分支。Git Worktree 讓同一儲存庫擁有多個工作目錄,各自使用分支與檔案。本篇會把待辦篩選與文件整理分開,確認兩個 session 不會直接改到彼此的檔案,再把其中一個成果整合回主分支。你也會知道何時可以安全清理工作目錄。

  • 生活分享

    Claude Code|雙 Worktree 實作與衝突整合

    隔離兩項功能,最後完成整合與回歸。兩個 Claude 工作階段同時編輯專案,最容易出現的問題是互相改到同一份檔案,或各自測試通過、整合後卻失敗。本篇用兩個 Worktree 分別處理篩選預設值與介面文字,故意製造一次小衝突,再完成整合、驗證與清理。你不需要先啟用 Agent Teams。

  • 生活分享

    Claude Code|比較流程品質、用量與執行時間

    以同一資料集比較兩種工作方法。比較兩種 Claude 工作方法時,不能只挑成功那一次,也不能只看第一個答案有多快。本篇用固定案例、原始紀錄和一致判準,比較品質、重試、等待與人工整合時間,最後寫出有樣本數與限制的報告,而不是保證某個方法一定省錢。

最新旅遊情報攻略

資料來源

生活分享