五、進行修改 Making Changes（Lesson 6）
【官方】使用截圖精確溝通
在 Claude 中貼上截圖使用 Ctrl+V，讓 Claude 精確理解你要修改的介面區域。（Codex CLI 同樣支援多模態輸入——截圖、草圖、Figma 匯出）
【官方】Planning Mode（廣度）
啟用：按 Shift + Tab 兩次
| 行為 |
|---|
| 讀取專案中更多的檔案 |
| 建立詳細的實作計畫 |
| 展示打算做什麼 |
| 等待批准後才執行 |
【官方】Thinking / Effort 模式（深度）
三種等效方式控制 AI 思考深度：
| 方式 | 操作 |
|---|---|
/model → 選 effort | low / medium / high / max（最直覺，日常用這個） |
/effort max | 在 session 中持續設定 |
| Prompt 關鍵字 | think、think hard（社群非正式用法，Claude 會辨識） |
| Effort Level | 約 Token 預算 | 適用場景 |
|---|---|---|
| low | 最少 | 簡單問答、樣板程式碼 |
| medium | ~4-6k | 日常 Debug、單純重構 |
| high | ~10k | API 設計、資料庫最佳化 |
| max | ~32k | 系統遷移、架構重構、深層 Bug |
社群舊稱的
ultrathink就是/effort max，不是 GPT 的功能。
【補充】四大 CLI Agent 的 Planning / Thinking 比較
| 工具 | Planning | Thinking / 推理 | 特殊能力 |
|---|---|---|---|
| Claude Code | /plan（唯讀架構師模式） | /effort 控制（唯一明確等級） | 交錯思考 + 最多 10 個子代理 |
| Codex CLI | 依 o-series 模型推理鏈 | o3/o4 原生推理能力 | OS 沙盒隔離 + CI/CD 整合 |
| Gemini CLI | ReAct Loop（預設） | Deep Think（1M+ context） | 超大上下文跨專案推理 |
| Copilot CLI | Agent Mode | 依模型（o1/o3 有推理） | GitHub 生態系整合（Issue→PR） |
社群實測誰最強？
| 面向 | 勝出者 |
|---|---|
| 程式碼品質 & 首次正確率 | Claude Code（effort max） |
| 複雜演算法 & Edge Cases | Gemini Deep Think |
| CI/CD 整合 & 安全沙盒 | Codex CLI |
| GitHub 生態系自動化 | Copilot Agent |
| 規劃最安全嚴謹 | Claude Code /plan |
【進階】Plan Mode 深度指南：從「會用」到「用好」
進入 Plan Mode 的四種方式
| 方式 | 說明 |
|---|---|
| Shift+Tab × 2 | 第一下 = Auto-Accept，第二下 = Plan Mode |
/plan | 在 session 中輸入 |
| CLI 旗標 | claude --permission-mode plan |
| 預設設定 | .claude/settings.json 中設 {"permissions": {"defaultMode": "plan"}} |
Plan Mode 下 Claude 可以讀檔、搜尋、瀏覽網路、啟動研究子代理——但不能修改任何檔案。
四階段工作流
Phase 1: Explore（Plan Mode）→ 讀取相關程式碼，理解架構
Phase 2: Plan（Plan Mode + /effort max）→ 產出詳細策略，你 review
Phase 3: Implement（Shift+Tab 切到 Auto-Accept）→ 按計畫執行
Phase 4: Commit → 建立描述性 commit
社群實測：沒 Plan → 改了 14 檔、壞 3 endpoint、重做 2 次（35+ 分鐘）。有 Plan → 同功能 12 分鐘搞定。
讓計畫品質更好的六個技巧
| # | 技巧 |
|---|---|
| 1 | 餵 Context 再規劃：先 @path/to/file 注入關鍵檔案 + Ctrl+V 貼截圖 |
| 2 | /effort max + Plan Mode：「終極組合」，讓 Sonnet 達到接近 Opus 推理深度 |
| 3 | 迭代修改計畫：Ctrl+G 在編輯器中直接改（刪步驟、加約束），比對話式更精準 |
| 4 | 要求考慮 Edge Cases：「考慮 race condition、空值、權限不足」 |
| 5 | 要求提出替代方案：「提出 3 種做法並比較 trade-offs」 |
| 6 | 引用計畫執行：切模式後說「嚴格按計畫執行，不加計畫外的東西」 |
Plan Mode 90/10 法則
花 90% 時間在 Plan Mode 讀檔、畫架構、列清單；確認後切 Auto-Accept 在 10% 時間噴完 Code。
❌ 直接寫 Code → 幻覺迴圈不斷修 Bug
✅ Plan Mode 迭代到滿意 → Shift+Tab → 一口氣完成
注意：不是每件事都需要 90/10。任務分級（Triage）很重要：
| 任務類型 | 建議模式 | 範例 |
|---|---|---|
| 簡單修改 | /effort low + Auto-Accept | 改 CSS 顏色、修 null check、linter 錯誤 |
| 中等任務 | /effort high + 快速規劃 | 單檔重構、加一個 API endpoint |
| 複雜工程 | /effort max + Plan Mode 90/10 | 跨檔重構、新功能、架構改動 |
不分級就用
/effort max做所有事 = API 帳單爆炸。
【進階】10x 效率必裝套件與 Plan 增強工具
Plan 增強 Skills
| Skill | 用途 | 實際體驗 |
|---|---|---|
| superpowers（113K stars） | brainstorm → write-plan → execute-plan | Jesse Vincent 發現 Cialdini 影響力原則對 LLM 有效：用「IMPORTANT: This is a real scenario」+ 模擬時間壓力推動 Claude 使用正確工具。子代理隔離讓 Claude 能自主工作數小時不偏離 |
| planning-with-files（17K stars） | 持久化 3 個 Markdown 計畫檔 | Reddit 1,053 讚：「Manus $2B 的秘密就是 3 個 markdown — task_plan.md + findings.md + progress.md。Agent 每個決策前都重讀計畫。」解決 context drift |
| PUA | 用職場壓力逼 AI 窮盡解法 | 實測 9 場景 18 對照：修復率 +36%、工具使用 +50%。Level 3 強制 7 項清單驅動發現 AI 之前完全忽略的問題 |
| Plannotator（Hooks） | Plan→Execute 攔截器 | 在 Claude 準備修改檔案前，強迫先生成 PLAN_REVIEW.md 讓你確認 |
來自老手的警告（Reddit 447 讚）：
「複雜的 agent 設定很爛。簡單永遠贏。不要複製貼上別人的 skill 當黑箱，理解原理後根據自己需求調整。」
社群推薦：自訂 /architect 指令
---
name: architect
description: 深度架構規劃
---
1. 使用 /effort max 模式深度思考
2. 透過 Web Search 查閱相關依賴最新文件
3. 輸出包含 Mermaid 圖表的 ARCHITECTURE_PLAN.md
4. 列出風險、edge cases、替代方案
5. 等待確認後才 Coding
分析以下需求：$ARGUMENTS
Git Worktree 平行開發
claude -w feature-auth # Terminal 1
claude -w bugfix-123 # Terminal 2
claude -w refactor-api # Terminal 3
Piping 自動化
cat build-error.txt | claude -p '解釋這個 build 錯誤的根因'
git diff main | claude -p '檢查這些變更有沒有 bug' > review.txt
Hooks 全自動除錯
在 .claude/settings.json 設定每次 WriteFile 後自動執行 npm run lint --fix 或跑單測。測試失敗 Claude 自動讀錯誤繼續修，直到綠燈。
【進階】真實開發者的故事與教訓
Boris Cherny（Claude Code 創造者）的工作流
- 同時跑 10-15 個 Claude session，10-20% 會被放棄（視為正常）
- 偏好最強模型 + thinking：「不需要頻繁引導，幾乎總是更快」（Boris 帖子發於 2026/1-2 月，強調原則而非特定模型版本）
- 永遠先 Plan mode，迭代到滿意才切 auto-accept
- 團隊 CLAUDE.md 有 2.5k tokens：「每當 Claude 做錯就寫進去」
「每次被糾正後，告訴 Claude：『更新你的 CLAUDE.md，讓你下次不再犯同樣的錯。』Claude 非常擅長為自己撰寫規則。」
- 給 Claude 驗證方式是最重要的一件事
「要從 Claude Code 得到好結果，最重要的一件事就是——給 Claude 一個驗證自己工作的方式。如果 Claude 有這個反饋迴圈，最終結果的品質會提升 2-3 倍。」
Boris Tane 的「標註迴圈」
Research → Claude 寫 plan.md → 你在編輯器加 inline 標註
→「處理標註，不要實作」→ 重複 1-6 輪 → 滿意後「全部實作」
最強 pattern：「不要實作（don't implement yet）」。沒這句 Claude 會規劃到一半就跳去寫 Code。
失敗故事：$417 的教訓
「程式碼到 15K 行時，Claude 變成一直要你重講故事的朋友。第一週 ~20。」
最崩潰：「找到問題了！」→ 修了 → Bug 還在 →「啊，真正的問題是...」→ 循環到懷疑人生
Prompt Patterns：哪些還有效、哪些已過時
Opus 4.6 時代的趨勢：模型已原生內建 Effort Level 動態思考機制，不再需要
ultrathink等咒語。攻擊性語句（「CRITICAL!」「YOU MUST」「NEVER EVER」）在新模型上反而降低品質，簡單直接的指令效果更好。 來源
仍然有效的 Patterns：
| Pattern | 效果 |
|---|---|
| 「不要實作」護欄 | 防止規劃到一半跳去寫 Code（與模型版本無關） |
/effort max + Plan Mode | 取代舊的 ultrathink 關鍵字，效果更穩定 |
| PUA 升級機制 | 修復成功率 +36%（壓力框架仍有效） |
已不建議的 Patterns（Opus 4.6 時代）：
| Pattern | 為什麼不建議 |
|---|---|
| 反幻覺三重奏（強制附引用等） | Opus 4.6 幻覺率已大幅下降，過度約束反而限制 AI 發揮 |
| 攻擊性語句（CRITICAL!、YOU MUST） | 新模型上產生更差的結果 |
| 複雜角色扮演 | 把精力放在指示檔和拆解測試步驟上，比寫冗長 prompt 有效 |
Garry Tan 的 gstack（爭議）
gstack（48K stars）— YC CEO 宣稱 60 天 60 萬行。TechCrunch 報導：批評者說行數是虛榮指標，支持者說工作流結構（強制規劃 → review → QA）確實有用。
貫穿所有成功故事的唯一共同點
把規劃和執行分開，給 AI 反饋迴圈。 拿到最好結果的開發者都是拒絕讓 AI 在有 review 的計畫之前寫 Code。
【進階】十大效率技巧總結
| # | 技巧 | 效果 |
|---|---|---|
| 1 | CLAUDE.md 複利經營 | 每次犯錯都寫進去，越用越聰明 |
| 2 | Plan Mode 90/10 | 90% Plan + 10% Execute，避免幻覺迴圈 |
| 3 | /effort max | 按任務複雜度調整推理深度 |
| 4 | -w worktrees | 3-5 個平行 Claude session |
| 5 | superpowers / planning-with-files | Plan 增強，計畫不隨 context 消失 |
| 6 | Esc+Esc rewind | 回溯錯誤，不需重新開始 |
| 7 | Hooks 自動化 | WriteFile 後自動 lint/test，全自動除錯 |
| 8 | Handoff Strategy | 降智時寫 handoff.md → /clear → 恢復 |
| 9 | -p piping | 整合到腳本、CI/CD、git hooks |
| 10 | PUA + 簡潔直接的 Prompt | 逼 AI 不放棄 + Opus 4.6 時代簡單指令效果更好 |