1. 「誒，他好方便喔」

先講一個我踩過很多次、後來發現很多人也在踩的坑。

我要開一個新專案，或者只是想試一個新想法。我把需求跟 Claude 講完 —— 就講完而已，還沒叫它「開始做」 —— 它就已經動手了。

幾分鐘後我回頭看，根目錄冒出一堆新資料夾。整個架構都搭好了，檔案分門別類，看起來很專業。

我當下的反應是:「誒，他好方便喔，這樣就做出來了。」

然後我打開來看。

以前端來說:按鈕點了沒反應，一半的功能根本沒接起來，畫面上的資料是寫死的。做 RAG 那次更明顯 —— 對話框裡那幾輪問答看起來好好的，結果是硬寫在程式裡的假資料，它根本沒接後端。

它很快。但快出來的是一個空殼。

後來我發現這不只是我會遇到。社群上常有人分享用 AI 做出來的工具和作品，畫面都很完整；但如果你剛接觸開發，很容易漏掉那些畫面上看不到的地方 —— 功能有沒有真的接起來、資料是不是真的、API 金鑰有沒有被直接寫進程式裡。

這也不全是使用者的錯。整個過程它沒報錯，最後還跟你說「完成了」，你當然會以為該處理的它都處理了。史丹佛 2023 年有一篇研究就發現:有 AI 助手幫忙的人，寫出來的程式比較不安全，卻更相信自己寫得很安全。

問題在於，它很容易停在「看起來做完」 —— 交出一個像是完成的東西，而不是真的完成。很多人把這叫 AI 在「偷懶」。這不是我一個人的感覺，Claude Code 的官方文件裡就直接寫著:

Claude stops when the work looks done.

Claude 會在「看起來做完了」的時候停下來。
—— Claude Code 官方文件〈Best practices for Claude Code〉

它不是故意的。沒有人先跟它講清楚「做完」長什麼樣子的時候，「看起來做完」就是它唯一的判斷標準。

而且最貴的不是那些檔案 —— 檔案刪掉就好。最貴的是我以為它做完了的那段時間，以及我照著那個殼往下想的方向。

我的處理方式一直都一樣:全部不要，重開一個對話，先跟它約束好，再重新開始。

這篇要講的，就是怎麼不用靠重開對話來做這件事。

2. 我本來是用嘴巴做這件事

被坑過幾次之後，我的工作方式變成這樣:

專案最初期，我不會讓它直接開始寫 code、也不讓它定架構。我會先叫它去做調研、去讀現有的東西、去把可行的做法列出來。然後我跟它來回討論，改到我確定「對，就是這個方向」，才讓它進入開發階段。

有點像我跟人共事的方式 —— 你不會在我還在講需求的時候就開始動手。

這個習慣是對的。但它有一個漏洞:

你講的「先別動手」，只是一句話。

它記在對話裡，而對話會變長、會被壓縮(G2、G5 都講過那塊白板)。當那句話從白板上被擦掉，它就不記得你們約過什麼了 —— 於是又開始改。

Claude Code 裡有一個機制，就是專門做這件事的。 你不用靠嘴巴約，也不用靠自己記得約。

這就是 G7 講 opusplan 時，我刻意沒解釋的那個詞:規劃階段。

3. 先搞清楚你現在在哪

在講 Plan Mode 之前，得先講一件更基本的事，因為它 8、9 月才剛改。

Claude Code 有好幾種「模式」，決定它動手前要問你多少。 而你現在正在其中一種裡面，即使你從來沒設定過。

怎麼看？看畫面下方那一行小字。 它會寫:

• ⏵⏵ auto mode on
• ⏸ manual mode on
• ⏵⏵ accept edits on
• ⏸ plan mode on

⚠️ 這裡有一個 8、9 月的重要變化。 從 2026 年 8 月 14 日起，auto mode 成為 Pro、Max、Team 新對話的預設模式(需要 macOS / Linux / WSL v2.1.228 以上，原生 Windows 要 v2.1.233 以上)。9 月 25 日的 v2.1.283 又往前一步:只要是在終端機或 VS Code 裡開的對話，不管哪種方案，都從 auto mode 開始。

意思是:你什麼都沒設定，它預設就不是「每件事都問你」的那個模式。 例外只有三種:版本太舊、公司管理員把 auto mode 關掉，或是你用 claude -p 這種不開對話、跑一次就結束的方式。

切換的方式是按 Shift+Tab，它會在幾個模式之間輪流。

💡 一個容易被寫錯的細節: 從 auto 按第一下，是跳回 Manual，不是往下一個。之後才是 Manual → 自動接受編輯 → Plan Mode → 回 Manual 這樣循環。所以如果你按一下發現「怎麼變得比較囉嗦了」，那是正常的。

還有一個名字要認:Manual 就是以前的「default」。 2026 年 7 月改了顯示名稱，東西是同一個 —— 只是設定檔裡還是寫 default。看到有人講 default 模式、有人講 Manual，別以為是兩種。

4. 四種模式是一條光譜

把它們排成一條線就很好記 —— 軸是「它動手前要問你多少」:

⚠️ 「自動接受編輯」不只會改檔案。 這個名字有點騙人 —— 它同時也放行工作目錄裡的 mkdir、mv、cp，以及 rm。它不只是「幫你按存檔」，是「幫你按存檔和刪除」。選它的時候要知道這件事。

另外還有兩個模式，預設不會出現在 Shift+Tab 的循環裡。dontAsk 其實是最嚴格的 —— 沒有事先允許的動作一律拒絕，是給自動化腳本用的。bypassPermissions 剛好相反，什麼都不問。兩個你現在都用不到，第 10 節會講為什麼後者最好別碰。

5. Plan Mode:光譜上最保守的那一格

進去的方式有三種，挑順手的:

Shift+Tab                       ← 按到狀態列出現 plan mode on
/plan 幫我規劃這個新專案的架構    ← 用指令進,還能順便把題目講給它
claude --permission-mode plan   ← 啟動的時候就進

💡 我最常用第二種。 /plan 後面可以直接接你要它想的東西 —— 這剛好就是我第 2 節那個習慣的機制版:一句話同時做到「進入規劃」和「給它題目」。

進去之後它能做什麼？

• ✅ 可以讀 —— 你的檔案、專案結構，它要看什麼都行
• ✅ 可以查 —— 跑那些「看一下情況」的指令去搞清楚現狀
• ✅ 會產出一份計畫 —— 而且是寫成一個檔案，不是講講就算
• ❌ 不會改你的原始碼 —— 這是重點，核准之前它動不了你的東西

換句話說:你要它做的調研、探索、比較，它全都做得到;它唯一被綁住的就是「動手」。 這正是專案最初期最需要的那條線。

💡 它跑指令的時候會不會一直問你？ 不太會。ls、cat 這類只是看一看的指令，本來就不用問你。其他指令，只要你的 auto mode 可用，預設也會交給 auto mode 的自動審核，不會每一條都跳出來 —— 所以 Plan Mode 不等於「一直被打斷」。

⚠️ 不要以為它完全不碰硬碟。 它會把計畫寫成檔案。所以精準的說法是「不動你的原始碼」，而不是「什麼都不寫」。

實際跑一次最有感。我在一個空資料夾下了 /plan 幫我規劃一個個人作品集網站，它沒有馬上丟計畫給我。它先看了一眼資料夾(空的)，然後反過來問我四個問題:視覺風格、內容從哪來、用什麼語言、作品要怎麼呈現。

這就是我第 2 節那個「先討論、再動手」的習慣。方向還沒定的時候，Plan Mode 會自己先問 —— 不用再靠我用嘴巴約。等我回答完，它才把計畫攤出來:

6. 計畫出來以後，你有三個選擇

它想完會把計畫攤在你面前，然後問你要怎麼辦。三個選項:

⚠️ 第一個選項的文字會變。 依你的環境和設定，它可能顯示成「切到 auto mode」或「自動接受編輯」，甚至是別的。看到的字跟這篇不完全一樣是正常的，重點是第一個是「核准後比較放手」、第二個是「核准後還是盯著」。

計畫寫得不夠好，可以直接改。 在計畫畫面按 Ctrl+G，它會用你系統預設的編輯器把計畫打開，你改完存檔就是改過的版本。不用回頭跟它文字來回。

核准之後會發生兩件事:它離開 Plan Mode、切到你選的那個模式;另外會用計畫的內容自動替這個對話取名字，之後你用 /resume 要找回來會好找很多(G5 那篇提過)。

回答 G7 欠的那個問題

G7 推薦過一個叫 opusplan 的選項，當時我說「規劃階段用 Opus、動手時自動換 Sonnet」，但沒解釋「規劃階段」是什麼。

答案就是這一節:它判斷的就是你在不在 Plan Mode。

在 Plan Mode 裡想計畫 → 用 Opus，那顆想得最周全的腦袋。核准之後開始一個檔案一個檔案改 → 自動換成 Sonnet，又快又省。

所以 opusplan + Plan Mode 是一組的。 兩個都設好，你會在最需要的地方用到最好的模型，在不需要的地方省下來 —— 而且完全不用手動切。

7.〔別搞混〕Plan Mode、/rewind、交接檔

這三個很容易混成一件事，它們管的是不同的時間點:

一句話記:Plan Mode 是預防，/rewind 是急救，交接檔是交班。

8. 模式是臨時的，規則才是永久的

到這裡你可能會想:「那我每次都先進 Plan Mode 就好啦？」

會有一個問題。模式是臨時的 —— 它會隨著你切換、隨著核准計畫而改變。而有些東西，你不是希望「這次不要動」，你是希望它永遠不要動。

比如說，你絕對不想讓它自己 push 到遠端;你絕對不想讓它讀你的 .env。

這種事，不要用嘴巴講。 官方文件裡有一段話講得很直白，大意是:

你在對話裡講的界線，不會被存成規則。它每次檢查都重新去讀對話 —— 所以當 context 被壓縮、那句話不見了，界線就跟著不見了。要硬保證，就寫一條 deny 規則。

這句話直接打中第 2 節那個漏洞。我用嘴巴約法三章，約定就活在對話裡;對話一長就可能被擦掉。規則不會。

三種規則，記住 deny 最大

規則分三種:allow(放行)、ask(問我)、deny(擋死)。

判斷順序是 deny → ask → allow，先中的贏。所以只要有一條 deny 中了，後面寫幾條 allow 都救不回來 —— 這是刻意設計的，讓你的底線不會被自己不小心放行。

實際長這樣(寫在設定檔的 permissions 裡):

允許:"Bash(npm run *)"       ← 跑 npm 腳本不用問我
允許:"Bash(git commit *)"    ← 讓它 commit
擋掉:"Bash(git push *)"      ← 但絕對不准 push
擋掉:"Read(./.env)"          ← 不准讀這個檔

⚠️ 萬用字元的位置很要命。 * 要放在子指令後面。官方特別點名一種寫法:Bash(git * main) 看起來像是「只允許跟 main 有關的 git 指令」，實際上會連 git push origin main 一起放行。要擋 push 就明確寫 Bash(git push *)。

⚠️ deny 是底線，不是保險箱。 這點要老實講:擋掉讀某個檔，不代表繞道的寫法也一定擋得住 —— 例如你擋了 git push，還是有其他寫法能達到類似效果。deny 的價值是把你最在意的那幾件事釘住，不是「設了就不用看了」。

9. 規則寫在哪一層

同樣一條規則，寫在不同地方，影響範圍不一樣:

優先順序是:命令列參數 > local > 專案 > 個人。但別忘了上一節那條 —— 任何一層的 deny 都擋死，不管它在哪一層。

⚠️ 一個 9 月才變、你可能會踩到的坑: 有些網路上的教學會叫你在專案的設定檔裡把預設模式設成最放行的那種(bypassPermissions)。從 2026 年 9 月 1 日起，寫在專案層會被直接忽略 —— 你以為設了，其實對話起來還是 Manual。這種設定只能寫在個人層(~/.claude/settings.json)，或用啟動參數。

順便說:auto 這個值一直都不能寫在專案層。

另外，你可能會看到一些「鎖住整個組織」的設定(managed settings、關掉 auto mode 之類的)。那些是給公司 IT 管理員用的，個人方案用不到，看到可以直接跳過。

10. 「我懶得一直按 y」的正解

這是新手最常問的一題。網路上常見的答案是那個很長、名字裡就有「危險」兩個字的參數 —— --dangerously-skip-permissions。

它確實還在，而且確實會讓它什麼都不問你。但官方自己在警告框裡寫的替代方案不是它，而是:

用 auto mode。

理由很清楚:全部跳過等於完全沒有防線，而 auto mode 是「它自己判斷大部分的事，遇到有風險的才問你」。你要的是「少按 y」，不是「把煞車拆掉」。

⚠️ 還有一個很少人知道的副作用: 用這個參數開的對話，連 Plan Mode 都擋不住它改檔。它還是會被告知「先規劃、別動手」，但它真的去改的時候，不會被攔下來。換句話說，這篇前半段教的那條線，在這個參數底下是虛的。

💡 兩個順帶的好消息: 第一，auto mode 現在本來就是預設，你什麼都不用設。第二，auto mode 那些自動判斷的過程，在 Pro / Max / Team 不算你的用量 —— 這點跟 G2、G7 講的省用量不衝突。

所以整件事收攏起來是這樣:

日常留在 auto mode(它本來就是預設)→ 專案最初期進 Plan Mode 想清楚 → 真正不能碰的東西寫成 deny 規則。

不用把煞車拆掉，也不用一直按 y。

11. 本課單字:讓它先想再動手

這篇收三個 —— 一個指令、一個快捷鍵、一個規則:

/plan

進入規劃模式，後面可以直接接你要它想的題目:/plan 幫我規劃這個專案的架構。它會去讀、去查、去把計畫攤出來，但不會動你的原始碼。計畫不滿意就選「告訴它哪裡要改」，想自己改就在計畫畫面按 Ctrl+G。

Shift+Tab

切換模式。先學會看狀態列那一行小字，知道自己現在在哪個模式，比記住循環順序重要。記一個細節就好:從 auto 按第一下是跳回 Manual。

deny 規則

唯一的「硬保證」。在對話裡交代的界線會被壓縮弄丟，寫成 deny 不會。 把你最不能接受的那兩三件事寫進去 —— 例如 Bash(git push *)、Read(./.env) —— 其他的交給 auto mode 判斷。

12. 給新手的三個提醒

a. 先看你現在在哪個模式

這篇如果只帶走一件事，就是認得狀態列那一行小字。8 月之後預設已經變成 auto mode，很多人不知道自己在一個「比較放手」的模式裡。知道自己在哪，才知道該不該換。

b. 專案最初期才最需要 Plan Mode

不是「難的任務才用」，而是**「方向還沒定的時候用」**。這兩件事不一樣 —— 一個很簡單的新專案，方向沒想清楚一樣會做出空殼。等方向定了、開始一個檔案一個檔案改，就不需要它了。

c. 不能碰的東西，寫成規則，不要只講一次

我自己吃過這個教訓:對話裡講過的約定，會隨著對話變長而消失。你講過，不等於它記得。 真正不能碰的，寫成 deny;剩下的，讓 auto mode 去判斷。

結語

回頭看第 1 節那個坑 —— 我以為問題出在「它太急」。

寫這篇的時候我才想清楚:問題出在我把一個規矩，用最容易消失的方式交代出去。 我用嘴巴講，所以它只存在於對話裡;對話一被壓縮，約定就不見了。

Plan Mode 和 deny 規則做的是同一件事:把「你講過的話」變成「系統守得住的界線」。 一個管當下這一段，一個管永久。

而且這件事跟 G3 的 CLAUDE.md 是同一個道理 —— 重要的東西不要靠記得，要放在會自動生效的地方。

下一篇我們換個方向。前面八篇都在處理「怎麼跟它把事情做對」，但東西做完之後呢？G6 教過用 HTML 讓它把產出畫給你看 —— 那些檔案現在都躺在你自己的電腦裡，要給別人看只能傳檔案，而且傳出去的那一份不會再更新。

有一個方式可以讓它變成一個網址:會跟著更新，能傳給別人，別人打開就是最新的。下一篇就講這個。

📌 關於本篇的細節: 模式的名字、狀態列的字樣、核准時看到的選項文字、版本門檻 —— 這些都是依 2026 年 9 月的官方文件整理的，而這塊改得特別快(光是今年，default 就改名成 Manual、預設模式也換了)。如果你是在很久以後讀到這篇，觀念和指令都還適用，但畫面上的字請以你眼前看到的為準 —— 按 Shift+Tab 看它列出什麼，就是最即時的答案。

下一篇 G9 — Artifacts:把產出變成一個會更新的網址。G6 教你讓 Claude 用 HTML 把東西畫給你看，這篇讓那份東西變成別人也打得開、而且會自己更新的網頁。

系列文章

• G1 Claude Code 從零開始 — Portfolio v2 重做
• G2 用量與計費 — 搞懂怎麼收費，再決定要不要省
• G3 CLAUDE.md — 讓 Claude 跨對話記得你的專案
• G4 Memory 系統 — 讓 Claude 不只記得專案，還記得你
• G5 換 section 不斷線 — 把當下進度交接給下一個對話
• G6 用 HTML 跟 Claude 溝通 — 讓你一眼看懂它給你的東西
• G7 控制 Claude 怎麼想 — 選模型與思考深度
• G8(本篇) 先想清楚再動手 — Plan Mode 與權限模式
• G9 Artifacts — 把產出變成一個會更新的網址(規劃中)

完整 20 篇地圖會放在系列首頁。本系列同步發佈於 Medium。

關於我

Tim Wei / Technology Consulting Consultant @ EY Taiwan，專注於 Responsible AI、金融業 ML 落地。

歡迎在留言區跟我討論，或在 LinkedIn 上找我。