第 7 章
工作模式與心法
光會叫 Copilot CLI 動手還不夠——這一章教你怎麼「帶」它做事：什麼時候讓它邊做邊問、什麼時候先看計畫書再放行、什麼時候乾脆放手讓它自己跑到完成，還有官方教的那套讓它穩定不出包的心法。
篇導讀（第 3 篇 進階）
適合對象——已經會用自然語言叫 Copilot CLI 讀改跑程式碼（第 4 章）、寫過 copilot-instructions.md 專案記憶（第 5 章）、也懂了核可制與 Git 整合安全機制（第 6 章）的你，準備把「偶爾能用」升級成「穩定好用」。
閱讀方式——找一個你已經在用 Copilot CLI 的專案，邊讀邊按 Shift+Tab 切換三種模式試手感。
本篇做完你會——懂得怎麼「帶」Copilot CLI 做事：三種工作模式怎麼選、核可機制怎麼跟模式搭配、本機沙箱怎麼多一層防護、官方 best practices 心法；接著第 8 章教你把這些偏好變成永久設定，第 9 章教你接上 MCP 外部工具。
想像你請了一位能力很強的工程師助理，第 4 章你已經學會怎麼「開口交辦」、第 5 章學會怎麼寫「守則手冊」（copilot-instructions.md）、第 6 章學會怎麼替它畫出「能碰、不能碰」的安全邊界，也懂了核可制那句「沒有任何事情會自動執行，你會在做決定之前檢視每一件事」的安全感從哪裡來。這一章要教的，是另一個維度的東西：不是「它敢不敢做」，而是你跟它相處的節奏會怎麼變。
7.1 長時間開發是什麼樣子：從盯著螢幕到描述目的地
先問一個問題：什麼樣的工作，值得你換一種「帶」的方式？答案不是「工作量大」這麼籠統，而是有三個具體特徵同時出現的時候。
先講清楚：這裡說的「長時間開發」是什麼樣子
本書接下來會反覆用到「長時間開發」這個說法，這裡先具體講清楚它指的是什麼，不是隨口的形容詞。它有三個一起出現的特徵：
- 跨多個檔案——不是改一行、修一個函式就結束，而是一個改動會牽動好幾個地方：路由設定、UI 元件、資料模型、對應的測試，缺一不可。
- 跨多次 session——不是一次對話從頭做到尾就能收工，可能今天先想清楚資料結構、明天接著做畫面、後天才補測試，中間你關過終端機、開過新的對話，靠第 5 章教的守則手冊（
copilot-instructions.md）接住上次還沒講完的脈絡。 - 需要先規劃再拆解執行——連你自己都還沒完全想清楚要怎麼改、要動哪些地方，得先把整件事想過一輪、拆成一步步的施工順序，才知道第一步該從哪裡下手。
拿一個具體例子來說：「幫這個專案加一個簡單的使用者設定頁」——這句話聽起來只有一句話，做起來卻要碰路由、UI、資料儲存，還要有把新舊行為串起來的測試，往往也不是一個下午就能做完。這跟前面提過的「小事、一句話講得清楚」（例如改一個錯字、修一行邏輯）完全是兩種量級——那種事你自然還是用標準模式邊做邊看；長時間開發要的是另一種相處方式。
Plan 模式：你描述目的地，它規劃路徑
面對一句話講不清楚、需要先規劃的任務，直覺的做法是自己先想清楚步驟，再一步步下指令給它做——但這樣一來，「規劃」這件最花腦力的事，還是全部留在你身上，你只是把「打字」外包出去而已。
Plan 模式要做的，是把「規劃」這一步也交出去。官方對它的說明講得很直白：Copilot 會分析你的需求、反過來問你問題把範圍與需求問清楚，然後才在動手寫任何一行程式碼之前建出一份計畫。也就是說，你不用先自己想好每一步該怎麼走，你只要講清楚目的地在哪裡——「我要一個使用者設定頁」——它會透過提問把模糊的地方問出來，再把路徑規劃出來給你看。你的工作，從「發號一連串指令」變成「審查一份計畫」。
這個轉變之所以重要，是因為它改變了互動的基本單位。標準模式下，一次互動是「一個指令、一個回應」；Plan 模式下，一次互動是「一份需求描述、一份完整計畫」——官方也明講，有具體計畫可以照著走，模型的成功率會更高。碰上跨檔案、跨 session 的長時間開發，這就是「你自己一步步想、一步步喊」跟「你講目的地、它畫路線圖」的根本差別。
Autopilot 模式：你不必逐行盯著，但核可機制仍是兜底
計畫確定之後，另一個問題來了：長時間開發往往意味著執行階段本身也很長——好幾個檔案要改、好幾輪測試要跑。如果每一步都要你停下來看一眼、點一下頭，你等於還是得從頭盯到尾，只是動手的人換成了它。Autopilot 模式解決的正是這件事：你不必逐行盯著它做，它會自己一路做到判定任務完成為止。
但「不必逐行盯著」不等於「完全不設防」。第 6 章教過的核可機制，並沒有因為你進了 Autopilot 就整套失效——它退到背景繼續運作，變成你放手時的兜底：Autopilot 會在任務完成、卡住做不下去、你按 Ctrl+C，或觸及你設定的接續次數上限時停下來；如果你當初選的是「有限權限」而不是全開，遇到需要核可的動作它一樣會自動擋下、不會硬闖。這一章談的是你的注意力怎麼分配——從「每一步都要看」變成「大部分時間可以去做別的事，只在關鍵點回來確認」；核可機制那套「安全感從哪裡來」的完整故事，第 6 章已經講完，這裡只是提醒你：節奏變了，底下的安全網沒有跟著消失。
補充資訊：這一章跟第 6 章，談的是兩件不同的事
第 6 章回答的問題是「安全感從哪裡來」——核可制、信任目錄、沙箱、/undo／/rewind，整套機制確保你放手之後不會出事。這一章回答的是另一個問題：「你跟它相處的節奏怎麼變」——從一步步盯著螢幕下指令，變成描述目的地、審查計畫、只在關鍵點回來看一眼。節奏會變，是因為底下那套安全機制夠可靠，讓你敢把步調交出去；但這一章的重點在節奏本身，不是機制本身，兩者別搞混。
這套心法要真正實作，靠的是三個具體的操作模式跟它們各自的語法；模式之外，還有一層核可機制在背後決定它到底能不能真的動手，以及一個 2026 年中才上線、還在公開預覽階段的「本機沙箱」，替 Autopilot 模式再多包一層防護。接下來幾節把這幾塊拼開來講，最後用官方整理的 best practices 心法收尾。
7.2 三種互動模式：Standard、Plan、Autopilot
在互動畫面裡按 Shift+Tab，Copilot CLI 會在三個狀態之間循環：Standard → Plan → Autopilot → 再按一次回到 Standard。
補充資訊：跟第 4 章接起來
第 4 章你已經按過一次 Shift+Tab，體驗過「從預設模式切到 Plan Mode」，也提過 Plan Mode 跟預設模式是互斥的兩種狀態。這裡把完整拼圖攤開——其實 Shift+Tab 不是兩態切換，是三態循環：預設模式的正式名稱叫 Standard，繼續按下去還有第三態 Autopilot。
Standard 模式：預設的邊做邊問
這是你一開始打開 copilot 就在的狀態——第 4 章教過的整套核可流程（唯讀操作自動放行、會改東西的動作跳出來問你）都是在這個模式下運作的。適合針對性的問題、小範圍重構、看檔案、請它先解釋一個失敗的測試再動手——步調由你掌控，走一步、看一步。
Plan 模式：先把施工圖畫給你看，再讓它動工
按 Shift+Tab 切過去，或直接打 /plan [你的需求]：
/plan 幫這個專案加上一個簡單的使用者設定頁官方對 Plan 模式的說明（逐字）：
Copilot analyzes your request, asks clarifying questions to understand scope and requirements, and builds a plan before writing any code.
（Copilot 會分析你的需求、問你釐清問題以確認範圍與需求，然後在動手寫任何一行程式碼之前，先建出一份計畫。）
也就是說，Plan 模式不是「它自己猜要做什麼」，而是會反過來問你問題，把模糊的地方問清楚，才動手規劃。典型的工作流程官方寫法是：explore（探索）→ plan（規劃）→ code（動手）→ commit（存檔）——複雜任務照這個順序走最穩。
官方還有一句很直白的心法：
Models achieve higher success rates when given a concrete plan to follow.
（有一份具體計畫可以照著走，模型的成功率會更高。）
小技巧：什麼時候該用 Plan 模式
官方明講——該用：多檔案改動、觸點多的重構、新功能實作。不該用：小 bug 修正、單檔案的小改動。任務越大、越模糊，Plan 模式的價值越高；一句話講得清楚的小事，直接用 Standard 模式反而更快。
你 review 過計畫、按下核可之後，Copilot 才會照著計畫真正動手。這一步跟第 6 章教的核可制是同一套邏輯的延伸：Plan 模式讓你在「它真的開始改檔案」之前，多了一整份計畫可以審查，不是只審查一個個零散的動作。
Autopilot 模式：放手讓它自己跑到完成
繼續按 Shift+Tab（或非互動時加 --autopilot 旗標、互動中打 /allow-all／/yolo），會進入 Autopilot 模式——讓 Copilot CLI 不必每一步都停下來等你輸入，自己一路做到它判定任務完成。
它會在下面四種情況之一發生時停下來（官方逐字，只要其中一項成立就停）：
- Agent 自己判定任務已經完成
- 遇到問題，導致無法繼續
- 你按下
Ctrl+C - 達到「最大接續次數上限」（若你有用
--max-autopilot-continues N設定的話）
copilot --autopilot --max-autopilot-continues 20 -p "把這批失敗的測試修到全綠"第一次進 Autopilot 模式、還沒授權過的話，官方會先跳出一個選擇：「Enable all permissions (recommended)」（開啟所有權限）或「Continue with limited permissions」（有限權限繼續）。選有限權限的話，Copilot 會「automatically deny any tool requests that require approval, which may prevent it from completing certain tasks」——白話講就是：油門踩到底但煞車還在，遇到需要核可的動作它會自動拒絕，某些任務因此可能做不完。
重要提醒：官方原句警告，務必記住
「This gives the CLI permission to make any changes it deems necessary to complete the task, including altering and deleting files.」
（這等於授權 CLI 可以做任何它認為完成任務所必要的改動，包含修改與刪除檔案。）
這句話一定要當真。Autopilot 一旦選了「Enable all permissions」，代表你把「這一步該不該做」的判斷權完全交出去了。
官方明講的適用場景：「well-defined tasks like writing tests, refactoring files, or fixing CI failures」（定義清楚的任務，例如寫測試、重構檔案、修 CI 失敗）以及「large tasks that require long-running, multi-step sessions」（需要長時間、多步驟執行的大任務）。
不適用的場景，官方也講得很白（Avoid for，逐字）：「Open-ended exploration, feature development without a clear goal, or tasks where you want to guide the ongoing work.」（開放式的探索、沒有明確目標的功能開發，或是你想全程引導的工作。）
小技巧：Plan → Autopilot 的典型組合技
官方推薦的順序是：先用 Plan 模式跟它一起把計畫討論出來，確認方向沒問題，選「Accept plan and build on autopilot」（接受計畫並用自動駕駛執行），轉成 Autopilot 一口氣做完。等於先把風險最高的『決定方向』這一步做完、看過、點頭了，剩下機械式的執行才放手交給自動駕駛——不是一上來就無腦全開。
非互動模式，這裡先點一句
除了三種互動模式，Copilot CLI 還有一個「不進互動畫面、丟一句話就跑完退出」的用法——第 4 章已經教過 -p／-s 的基本用法，官方對它的定性是「the CLI completes the task and then exits」（跑完任務就退出）。完整的自動化玩法（權限旗標家族、排程、--model 跨供應商切換）留給第 10 章「非互動自動化」整章講，這裡不搶戲。
7.3 核可機制怎麼跟三種模式搭配
第 6 章已經教過核可制的基本盤：唯讀操作自動放行、會改動系統的操作一定要你點頭、--allow-tool／--deny-tool 精細語法、--allow-all／--yolo 的官方紅線警告。這一節不重複那整套，只聚焦在核可機制怎麼跟這一章的三種模式搭配，並且補一個第 6 章沒細講的角落：兩種權限存檔位置到底各自存什麼。
快速複習：核可旗標家族
| 旗標 | 作用 |
|---|---|
--allow-tool='TOOL_TYPE'（例：--allow-tool='shell(git:*)'） | 預先核准特定工具／子指令 |
--deny-tool='TOOL_TYPE'（例：--deny-tool='shell(git push)'） | 封鎖特定工具，deny 永遠贏過 allow |
--allow-all-tools | 所有工具免問 |
--allow-all-urls / --allow-url=DOMAIN / --deny-url=DOMAIN | 網址存取白名單／黑名單 |
--allow-all 或 --yolo | 上面全部一次開，等同「什麼都不問」——就是 Autopilot 一鍵開啟所有權限背後用的那組旗標 |
（料源：official，Allowing tools to run）
官方對「deny 優先」這條規則講得很硬：
Deny rules always take precedence over allow rules, even when
--allow-allis set or a matching approval has been saved.
（拒絕規則永遠贏過允許規則，就算你開了--allow-all、或者之前已經存過核可紀錄，也一樣。）
也就是說，--deny-tool 是你能設的最高防線——不管 Autopilot 開了多大的權限，只要某個動作被 --deny-tool 點名，它就是動不了。
重要提醒：官方逐字警告，別把 --yolo 做成 alias
「It is strongly recommended that you only use these options in an isolated environment. You should never use an alias to apply one of these options every time you start Copilot CLI, as doing so would allow Copilot to use any tool without your explicit permission.」
翻成白話：只該在隔離環境用這些全開權限的選項；絕對不要把 --allow-all 或 --yolo 寫成你每次啟動 Copilot CLI 都會套用的 alias（例如 alias copilot="copilot --yolo"）——這樣等於讓 Copilot 永遠不用問你就能動用任何工具，跟裸奔沒兩樣。
兩種存檔位置，各自管什麼
第 6 章提過核可紀錄有兩個存檔位置，這裡把它們的分工講清楚：
| 存檔位置 | 管什麼 |
|---|---|
~/.copilot/permissions-config.json | 位置限定的工具／路徑核准，依 Git repo root 或工作目錄綁定 |
~/.copilot/settings.json | URL 核准（網域白名單），全域套用到所有 session |
核准本身也分兩種期限：Session 級（互動中選「這一次允許」或「這個 session 剩下時間都允許」，session 結束就失效）跟持久化（存進上面兩個檔案，跨 session 記住）。官方原文：「Some prompt options save your consent so you aren't asked again.」（有些提示選項會存下你的同意，之後就不會再問。）
互動內對應的管理指令：
/allow-all [on|off|show]
/yolo [on|off|show]
/permissions [show|reset]
/reset-allowed-tools/allow-all 跟 /yolo 是同一件事的兩個名字，在 session 內開關全權限；/permissions 查看或清除已存的核准紀錄；/reset-allowed-tools 重置本次已允許的工具清單。
補充資訊：這幾個指令可能被組織政策鎖住
如果你的 Copilot 是透過 Business 或 Enterprise 方案取得的，上面這幾個 slash 指令可能被管理員政策限制或直接停用——你打了沒反應，不一定是你打錯，先確認一下是不是組織政策的關係。
信任目錄：跟第 1／3 章的伏筆接上
只有被信任的目錄（及其子目錄）能被 Copilot CLI 讀、寫、執行操作——這是第 1 章埋下的伏筆、第 3 章、第 4 章你已經實際走過的那個「信任目錄」提示框。永久信任的目錄清單存在你的設定目錄裡。
補充資訊：這裡老實留一點彈性
查證時發現，官方不同文件頁對「信任目錄清單究竟存在哪個檔案的哪個鍵」措辭略有出入（trustedFolders 還是 trusted_folders、存在 config.json 還是 settings.json）。這一章只確認「有這個機制、行為如你在第 1／3 章實際看到的那樣」，確切鍵名與存放檔案，以你實機 /settings show 或官方文件當下版本為準，不武斷咬死是哪一個。
7.4 本機沙箱（Local Sandbox）——公開預覽，行為可能還會變
版本時效提醒：這是本章唯一該標「實驗性」的功能
2026-06-02 官方 changelog 宣布「Cloud and local sandboxes for GitHub Copilot」進入公開預覽（Public Preview），逐字聲明：「Cloud and local sandboxes for GitHub Copilot is in public preview and subject to change.」——還在變動中，別把下面講的介面細節當成永久不變的規格，一切以你實機看到的畫面為準。
第 6 章已經提過本機／雲端 sandbox 這個名詞，這一節把「本機沙箱」攤開講。它做的事情，是在核可機制之外，再替 Copilot 發起的 shell 指令執行，多包一層作業系統層級的限制——好比你請工人來家裡裝修，核可制是「每個動作先問過你」，本機沙箱則是「先把工人限制在指定的房間裡施工，就算他手滑，也波及不到其他房間」。這對 Autopilot 模式尤其重要：你放手讓它自己跑，本機沙箱就是那道「就算它判斷錯了也出不了圈」的物理邊界。
啟用方式：
/sandbox enable
/sandbox disable裸打 /sandbox（不加參數）會打開一個三分頁的互動設定介面：
| 分頁 | 內容 |
|---|---|
| General | 總開關「Sandboxing enabled」；macOS Keychain 存取權限（給 credential helper 用） |
| Filesystem | 預設限制寫入「工作目錄之外」的位置；可按 A 加路徑規則，授予某條路徑唯讀或讀寫 |
| Network | 對外連網、區網存取開關；可嘗試加 host 規則 |
底層技術官方逐字：「Local sandboxing is built on Microsoft MXC technology for a consistent isolation experience across macOS, Linux, and Windows.」（本機沙箱建立在微軟 MXC 技術上，讓 macOS、Linux、Windows 三個平台有一致的隔離體驗。）
重要提醒：兩個實測限制
- Network 分頁的逐 host 過濾不可靠：官方自己註明，跨平台的逐 host 網路過濾規則不該被當成安全保證，只當成輔助防線。
- Windows 需要 Insiders 版：官方逐字「Local sandboxing on Windows requires a Windows Insiders build.」——一般穩定版 Windows 目前用不了本機沙箱，這點在規劃跨平台團隊的安全策略時要特別注意。
（料源：official，Configuring local sandbox settings）
7.5 官方安全使用責任聲明
官方「Responsible use」文件對 Copilot CLI 有兩句值得抄下來貼在螢幕邊的話：
Additional caution is required when asking or allowing Copilot CLI to execute a command, particularly regarding the potential destructiveness of some suggested commands.
（請求或允許 Copilot CLI 執行指令時，需要格外謹慎——尤其是某些建議指令可能具有破壞性這一點。）
You are ultimately responsible for the commands executed by Copilot CLI.
（你，對 Copilot CLI 執行的指令負最終責任。）
第二句尤其重要：不管你用的是 Standard、Plan 還是 Autopilot，它幫你做的每一個動作，責任都在你身上，不是「AI 自己決定的、跟我無關」。
官方另外還有一條「存取範圍」原則，跟第 1 章提過的工作目錄概念直接呼應：「files and folders in, and below, the directory from which it was invoked」——CLI 預設只碰你啟動它時所在的目錄，以及這個目錄之下的子目錄。想讓它涵蓋更多目錄，第 8 章會教你 /add-dir 的用法。
（料源：official，Responsible use of GitHub Copilot CLI）
7.6 心法收尾：官方 Best Practices
前面四節讓你懂了「怎麼選模式、怎麼放權限、怎麼多包一層沙箱」。這一節整理官方 best practices 頁的心法精華，幫你把 Copilot CLI 從「能用」帶到「好用」。
Plan-driven development：複雜任務先 /plan
前面 7.2 節已經完整講過，這裡再濃縮一句：explore → plan → code → commit，是官方對複雜任務建議的標準順序。
Focused sessions：一件事一段對話
官方原句：「focused sessions produce better results」（專注的 session 產出更好的結果）。不相干的任務之間，用 /clear 或 /new 重置 context，別把 Copilot 的一段對話當成什麼事都往裡塞的萬用垃圾桶。
/clear
/new小技巧：這條心法四套 CLI 都在講
「一件事一段對話」不是 Copilot CLI 獨有的心法——本站其他幾套終端機 AI 工具的對應章節，也都在用各自的說法講同一件事：對話（或說 thread、session）裡塞的事情越雜，AI 的注意力就越容易被稀釋、答非所問。換個角度想：這不是哪一家工具的怪癖，是所有這類工具背後共通的機制限制。
無限 session、自動壓縮，跟 /compact
Copilot CLI 的 session 理論上可以無限長，靠「intelligent compaction」（智慧壓縮）自動管理 context window，你什麼都不用做它也會處理。想主動看用量、手動出手，有幾個指令：
/context
/compact 專注在剛才那個檔案的改動/context：看 token 用量的視覺化畫面。/compact [FOCUS-INSTRUCTIONS]：手動觸發摘要壓縮，可以加一句話告訴它「壓縮時重點留意什麼」。
壓縮發生時，系統會建立一個 checkpoint（存檔點），你可以用下面幾個指令回頭查：
/session checkpoints
/session plan
/session files/session checkpoints 列出目前 session 累積過的壓縮存檔點、/session plan 看目前的計畫、/session files 看這段對話產生過的暫存產物。
補充資訊：這個 checkpoint 不是第 6 章的 /undo／/rewind
這裡的 checkpoint 是「context 壓縮時留下的摘要存檔點」，方便你回頭查對話脈絡；第 6 章教的 /undo／/rewind 是「把檔案或對話真的復原到某個時間點」的回滾機制，兩者名字沾親帶故、實際功能完全不同，別搞混。
多 repo 工作：/add-dir、/list-dirs
從父目錄跑 Copilot 可以涵蓋多個 repo；或者用 /add-dir 把額外的目錄加進允許存取清單：
/add-dir ../another-project
/list-dirs/list-dirs 查目前允許存取哪些目錄——這兩個指令的完整設定細節，第 8 章會再展開。
委派：把旁支任務丟去雲端
/delegate 幫我把 README 裡過時的安裝說明更新一下/delegate [PROMPT]：把旁支任務、文件更新、可以非同步跑的工作丟給雲端 agent 處理，本機專注在核心開發、除錯、互動式探索。適合那種「該做、但不急、也不需要你盯著」的工作。
Test-first：先寫會失敗的測試，再叫它做到通過
官方建議的驗證心法：請它先寫測試 → review → 實作到通過 → 再 review 一次實作本身才 commit。這一招在第 6 章談 Git 工作流程時已經示範過一次，這裡是官方 best practices 頁對同一件事的正式定調。
/security-review：開 PR 前先掃一次
/security-review 檢查我剛剛這批改動有沒有安全疑慮在開 PR 之前，先讓 Copilot 掃一次本機改動，找安全問題——高風險發現優先處理。這個指令目前也還在公開預覽階段，用法跟輸出格式可能持續調整。
/review：可以指定用不同模型審查
/review 用 Opus 4.5 和 Codex 5.2 審查我目前分支跟 main 的差異/review [PROMPT] 可以指定用不同模型做 code review——這是第 4 章提過的多供應商架構在這裡的一個實際用法：讓一顆模型寫程式，再換另一顆模型幫你挑錯。
/fleet：多代理平行編排，先知道名字就好
/fleet 把這個大重構拆成幾個獨立子任務平行跑/fleet [PROMPT]：把一個大任務拆成平行子任務，讓多個 agent 同時跑（官方描述：「Enable parallel subagent execution of parts of a task」）。這是 Copilot CLI 自己的「多代理」輕量版本，完整的平行編排、遞迴保險絲設計，留給後面談多代理協作的章節整章展開，這裡你只要知道有這個指令、大概做什麼就夠了。
本章小結
這一章的核心，是你跟 Copilot CLI 相處的節奏怎麼變——從一步步盯著螢幕下指令，變成描述目的地、審查計畫、只在關鍵點回來確認。落到實際操作，你學會了：Standard／Plan／Autopilot 三種模式用 Shift+Tab 循環切換，任務的大小、模糊程度決定你該選哪一種；核可機制（--allow-tool／--deny-tool，deny 永遠贏、--yolo 絕不能做成 alias）是背後那道決定「動作能不能真的執行」的閘門，跟三種模式搭配運作；還在公開預覽的本機沙箱替 Autopilot 多包一層作業系統層級的邊界；官方那句「你對執行的指令負最終責任」提醒你，方便歸方便，責任始終在你身上。最後你認識了一整套 best practices 心法——專注的 session、/delegate 委派雲端、test-first、/security-review，以及點名了 /fleet 這個多代理輕量版本，完整玩法留給後面章節。
動手試試
- 找一個你不怕弄壞的小專案，按
Shift+Tab循環一次三種模式，感受 Standard／Plan／Autopilot 在畫面上的差異。 - 用
/plan丟一個「不只一步」的需求（例如「幫這個專案加一個設定頁」），看它怎麼反問你釐清問題、怎麼把計畫列出來——先別讓它真的動手。 - 在一個你確定安全、可以重來的測試資料夾裡，試著開一次 Autopilot 模式，選「Continue with limited permissions」，觀察它遇到需要核可的動作時怎麼被自動擋下來。
- 打
/sandbox看看本機沙箱的三分頁設定畫面長什麼樣，即使你暫時不打算真的啟用它。 - 打
/context看看目前這段對話的 token 用量視覺化，再試著打一次/compact，體會壓縮前後的差異。
版本時效提醒
本章提到的三種模式操作方式、核可旗標、/sandbox 介面細節，Copilot CLI 改版速度很快（本教學查證當下，repo 近期兩天內連發過四個版號），畫面文字、快捷鍵、旗標名稱都可能已經調整。任何時候，實機打 copilot --help、互動畫面裡打 /help，都比書上寫的更準。
本章官方文件參考
- CLI best practices：https://docs.github.com/en/copilot/how-tos/copilot-cli/cli-best-practices
- Autopilot：https://docs.github.com/en/copilot/concepts/agents/copilot-cli/autopilot
- Allowing tools to run：https://docs.github.com/en/copilot/how-tos/copilot-cli/use-copilot-cli/allowing-tools
- Configuring local sandbox settings：https://docs.github.com/en/copilot/how-tos/cloud-and-local-sandboxes/configuring-local-sandbox-settings
- Cloud and local sandboxes 公開預覽公告：https://github.blog/changelog/2026-06-02-cloud-and-local-sandboxes-for-github-copilot-now-in-public-preview/
- Responsible use of GitHub Copilot CLI：https://docs.github.com/en/enterprise-cloud@latest/copilot/responsible-use/copilot-cli
- Using GitHub Copilot CLI（總覽，含非互動模式）：https://docs.github.com/en/copilot/how-tos/copilot-cli/use-copilot-cli/overview