2026-04-30-Claude-Code完整教程

Claude Code 完整教程（Eyad Khrais）

後設資料

• URL：https://x.com/eyad_khrais/status/2010076957938188661
• 作者：Eyad Khrais（@eyad_khrais）
• 發表平台：X（Twitter）長推文
• 發表日：未明示（推測 2025 末 ~ 2026 初；文中提及 Claude-Code 與 Opus 4.5 等版本資訊）
• 語言：英文（使用者提供時附中文翻譯對照）

一句話濃縮

用 Claude-Code 寫程式的真正瓶頸不在模型，而在使用者：先思考再打字、用 CLAUDE.md 框住專案常識、把對話 scope 在 context window 劣化前清乾淨、把工作流從一次性對話升級為可被腳本呼叫的系統。

提取要點

• Think First（先思考再打字）：丟到 Claude-Code 之前先用 plan mode（Shift+Tab 兩次）想清楚架構；模糊指令「build me an auth system」 vs 具體指令「Build email/password auth using existing User model, store sessions in Redis with 24-hour expiry, add middleware that protects /api/protected」差距巨大。「五分鐘規劃，省下數小時除錯」是核心交易。
• 與 LLM 來回對話而非單向發指令：使用 ChatGPT / Gemini / Claude 描述要建什麼，要 LLM 列出系統設計選項，雙方互相提問達成共識——對位 Prompt-Engineering 的「迭代觀」與 AI輔助創意 的「散彈 → 收斂」。
• CLAUDE.md 是槓桿點：Claude Code 啟動時讀取的專案規範檔；模型一次只能可靠跟隨 ~150-200 條指令，Claude Code 系統提示已用掉 ~50 條。原則：(a) 簡短；(b) 專案特定（不要解釋什麼是 components 資料夾，要寫專案的 weird stuff、bash 指令）；(c) 講 why 而不只是 what（「Use TypeScript strict mode because we’ve had production bugs from implicit any types」比「Use TypeScript strict mode」好）；(d) 不斷更新（按 # 鍵讓 Claude 自動加入；每次修正同樣的事兩次以上就該寫進去）。
• 好的 CLAUDE.md vs 壞的：壞的像給新進員工的入職資料；好的像「明天會失憶時留給自己的字條」。
• Context window 在 100% 之前就劣化：Opus 4.5 名義 200k tokens；實測 20-40% 用量品質就開始下降，/compact 後仍差是因為壓縮前已劣化、壓縮無法神奇恢復品質。
• Context 管理四招：(1) scope 對話——一個 conversation 一個 feature/task，不要一邊建 auth 一邊重構 DB；(2) 外部記憶體——複雜任務讓 Claude 寫進 SCRATCHPAD.md / plan.md，跨 session 持續；(3) 複製貼上重置——把 terminal 重要內容複製出來、跑 /compact 取摘要、/clear 後只貼回關鍵內容；(4) 果斷 /clear——對話脫軌時清掉重來，CLAUDE.md 仍會載入，10 次有 9 次比硬撐好。心智模型：Claude 是 stateless，每次對話從零開始，除非你明確給它。
• Bad input == bad output：「模型不夠聰明」九成時候是 prompt 寫得爛。模型差異真實存在（Sonnet 快便宜、適合執行；Opus 慢貴、適合推理規劃），但瓶頸幾乎永遠在人這側：prompt 結構、context 提供、需求表達。
• Sonnet/Opus 工作流：用 Opus 規劃與架構決策 → 切到 Sonnet（Shift+Tab）執行；CLAUDE.md 確保兩個模型在同樣約束下運作，交接乾淨。
• MCP / Hooks / Slash commands：(a) MCP 連外部服務（Slack / GitHub / DB / API），找不到現成的就自己建；(b) Hooks 在 Claude 修改前後自動跑程式（Prettier、type check）即時擋問題、長期清理技術債；(c) Custom slash commands（.claude/commands/ 內放 markdown）把重複用的 prompt 包成指令；(d) 付了 Pro Max ($200/月) 就要全部試，模型每週進步、一個月前不行的現在可能可以。
• Claude 卡住時換方法而非加碼：(1) /clear 重啟；(2) 把任務切更小（如果還在卡，代表 plan mode 不夠）；(3) show instead of tell——自己寫最小範例「output 該長這樣」，Claude 非常擅長照範例做；(4) 重新框問題（「implement as a state machine」vs「handle these transitions」）。Meta-skill：早點識別自己在 loop 裡，解釋三次還沒懂就該換策略，不是繼續解釋。
• Build systems, not one-shots：claude -p 旗標進 headless mode，可被 script 呼叫、與 bash 串、整合到自動化 workflow。企業在做的：自動 PR review、客服工單回覆、log 與文件更新——全可審計、隨用隨改進。飛輪：Claude 犯錯 → 看 log → 改 CLAUDE.md / 工具 → 下次更好。作者目前正在讓 Claude 自己改自己的 CLAUDE.md。
• AI 是加速而非替代：即使在高度專業軟體工程時代也是。Claude 還是會犯錯——能識別錯誤本身就解決了很多問題。
• TLDR 七條：(1) 打字前先思考；(2) CLAUDE.md 是槓桿點，簡短具體說 why、持續更新；(3) Context 在 30% 就劣化、不是 100%；(4) 架構比什麼都重要、不能跳過 plan；(5) 輸出來自輸入、結果差就是 prompt 差；(6) MCP / hooks / slash commands 都試一遍；(7) 卡住時換方法、不要 loop；(8) 建系統、不要一次性。

提取概念

連結到此來源衍生 / 更新的 wiki 頁：

• Claude-Code（新建 — entity / product；Anthropic 的 CLI 編程助理；本來源是 vault 中第一個 Claude Code 實作經驗來源）
• Anthropic（補入 Claude Code 產品線）
• AI輔助開發（補入 Claude Code 作為 IDE-agent / CLI 工具的主案例；補入「先思考再打字 / plan mode / 外部記憶體 / build systems」工作法則）
• Prompt-Engineering（補入「Be specific（具體）/ Tell what NOT to do（負向指令）/ Tell why（給原因）」三原則 + Claude 4.5 過度設計傾向觀察）
• Context-Engineering（補入「Context 在容量上限前已劣化」具體經驗值（20-40% 開始下降）+ 「copy-paste reset / 外部記憶體 / scope 對話」工程化做法）
• Model-Context-Protocol（補入 Claude Code 作為 MCP host 的具體應用案例）
• MOC-LLM-應用設計（實體層補入 Claude-Code；應用層 AI輔助開發 補入 CLI agent 案例累積）

原文（中英對照保留）

X 推文易失效，且本來源是 vault 第一個 Claude-Code 實作經驗來源，故完整保留。

Think First 先思考

Most people assume that with Claude Code and other AI tools, the first thing you need to do is type (or start talking). But that’s probably one of the biggest mistakes that you can make straight off the bat. The first thing that you actually need to do is think.

大多數人認為使用 Claude Code 和其他 AI 工具時首先要做的是輸入文字（或開始說話）。但這可能是你一開始就會犯的最大錯誤之一。你真正需要做的第一件事是思考。

10 out of 10 times, the output I’ve gotten with plan mode did significantly better than when I just started talking and spewing everything into Claude Code. It’s not even close.

十次有十次，使用規劃模式得到的輸出結果都比我直接對著 Claude Code 胡亂輸入要好得多。差距非常明顯。

Now for some of you, this is easier said than done. You might not have years of software engineering experience that would allow you to think about this on your own. To this extent I have two pieces of advice:

1. Start learning. You are handicapping yourself if you never pick up on this, even if just a little bit at a time.
2. Have a deep back and forth with ChatGPT/Gemini/Claude, where you describe exactly what you want to build, you ask the LLM for the various options you can take in terms of system design, and ultimately the two of you settle on a solution. You and the LLM should be asking each other questions, not just a one way street.

對你們中的一些人來說這說起來容易做起來難。你們可能沒有多年的軟體工程經驗無法獨立思考這個問題。對此我有兩點建議：

1. 開始學習。如果你一直不學習，就算每次只學一點點，你都會為自己設限。
2. 與 ChatGPT/Gemini/Claude 進行深入的交流，詳細描述你想要建造的內容，向 LLM 諮詢系統設計方面的各種方案，最終你們雙方共同確定解決方案。你和 LLM 應該互相提問，而不是單向溝通。

This applies to everything. This also includes very small tasks like summarizing emails. Before you ask Claude to build a feature, think about the architecture. Before you ask it to refactor something, think about what the end state should look like. Before you ask it to debug, think about what you actually know about the problem. The more information that you have in plan mode, the better your output is actually going to be because the better the input is going to be.

這適用於所有事情，包括像摘要郵件這樣的小任務。在讓 Claude 建立某個功能之前，先考慮一下架構；在讓它重構某些內容之前，先想想最終狀態應該是什麼樣子；在讓它調試之前，先想想你對問題究竟了解多少。計劃階段掌握的資訊越多，輸出結果就越好，因為輸入資訊也會越好。

The pattern is consistent: thinking first, then typing, produces dramatically better results than typing first and hoping Claude figures it out.

規律是：先思考後打字，比先打字再指望 Claude 能明白好得多。

Architecture, especially in software engineering, is a little bit like giving a person the output and nothing more. This leaves for A LOT of wiggle room in how to get to the output, which is essentially what the problem with AI generated code is. If you say something super broad like “build me an auth system” as opposed to “Build email/password authentication using the existing User model, store sessions in Redis with 24-hour expiry, and add middleware that protects all routes under /api/protected.”, you can see the difference.

架構，尤其是在軟體工程領域，有點像是直接給出最終結果，不多也不少。這就為如何實現最終結果留下了很大的迴旋餘地，而這正是人工智慧生成程式碼的根本問題所在。如果你說的是一個非常寬泛的指令，例如「幫我建立一個身份驗證系統」，而不是「使用現有的用戶模型構建郵箱/密碼身份驗證，將會話存儲在 Redis 中，並設置 24 小時過期時間，然後添加中間件來保護 /api/protected 下的所有路由」，你就能看出其中的區別了。

You click shift + tab twice, and you’re in plan mode. Trust me when I say this, this is going to take 5 minutes of your time, but will save you hours upon hours of debugging later on.

按兩次 Shift + Tab 鍵即可進入規劃模式。相信我這只需要你五分鐘的時間，但能為你節省之後數小時的調試時間。

CLAUDE.md

CLAUDE.md is a markdown file. Markdown is a text format that AI models process extremely well, and Claude in particular handles it better than most other models I’ve tested.

CLAUDE.md 是一個 Markdown 文件。Markdown 是一種文字格式，人工智慧模型能夠很好地處理它，尤其是 Claude，它比我測試過的大多數其他模型處理得更好。

When you start a Claude Code session, the first thing Claude does is read your CLAUDE.md file. Every instruction in that file shapes how Claude approaches your project. It’s essentially onboarding material that Claude reads before every single conversation.

當你啟動 Claude Code 會話時，Claude 首先會讀取你的 CLAUDE.md 文件。該文件中的每一條指令都決定了 Claude 處理這個專案的方式。它本質上是 Claude 在每次對話前都會閱讀的新用戶培訓資料。

Most people either ignore it completely or stuff it with garbage that makes Claude worse instead of better. There is a threshold where too much or too little information means worse model output.

大多數人要不是完全忽略它，就是往裡面塞滿垃圾訊息，結果反而讓 Claude 的情況更糟。資訊過多或過少都會導致模型輸出變差，存在一個臨界點。

Here’s what actually matters:

Keep it short. Claude can only reliably follow around 150 to 200 instructions at a time, and Claude Code’s system prompt already uses about 50 of those. Every instruction you add competes for attention. If your CLAUDE.md is a novel, Claude will start ignoring things randomly and you won’t know which things.

盡量簡潔。 Claude 一次只能可靠地執行大約 150 到 200 條指令，而 Claude Code 的系統提示符已經佔用了大約 50 條。你新增的每條指令都會爭奪 Claude 的注意力。如果你的 CLAUDE.md 是一部小說，Claude 會開始隨機地忽略一些事情，而你不會知道他忽略的是哪些事情。

Make it specific to your project. Don’t explain what a components folder is. Claude knows what components are. Tell it the weird stuff, like the bash commands that actually matter. Everything that is part of your flow should go into it.

讓它與你的項目緊密相關。 不要解釋什麼是元件資料夾，Claude 知道元件是什麼。告訴它一些真正重要的細節，例如那些看似無關緊要的 bash 指令。你工作流程中的所有內容都應該放進去。

Tell it why, not just what. Claude is a little bit like a human in this way. When you give it the reason behind an instruction, Claude implements it better than if you just tell it what to do. “Use TypeScript strict mode” is okay. “Use TypeScript strict mode because we’ve had production bugs from implicit any types” is better. The why gives Claude context for making judgment calls you didn’t anticipate. You’ll be surprised how effective this actually is.

告訴它為什麼而不僅僅是做什麼。 Claude 在這方面有點像人。當你解釋指令背後的原因時，Claude 的執行效果會比你只告訴它做什麼更好。「使用 TypeScript 嚴格模式」是可以的，但「使用 TypeScript 嚴格模式是因為我們遇到過隱式 any 類型導致的生產環境 bug」比較好。解釋原因能讓 Claude 做出你意想不到的判斷。

Update it constantly. Press the # key while you’re working and Claude will add instructions to your CLAUDE.md automatically. Every time you find yourself correcting Claude on the same thing twice, that’s a signal it should be in the file. Over time your CLAUDE.md becomes a living document of how your codebase actually works.

不斷更新。 工作時按 # 鍵，Claude 就會自動加入說明到 CLAUDE.md。每次你發現自己兩次糾正 Claude 同一個錯誤時，就表示應該把這個錯誤記錄到文件中。隨著時間的推移，你的 CLAUDE.md 會成為一份鮮活的文檔，記錄你的程式碼庫實際的運作方式。

Bad CLAUDE.md looks like documentation written for a new hire. Good CLAUDE.md looks like notes you’d leave yourself if you knew you’d have amnesia tomorrow.

壞的 CLAUDE.md 看起來像是為新進員工編寫的入職資料。不錯的 CLAUDE.md 看起來像是你知道自己明天會失去記憶時會留給自己的字條。

The Limitations of Context Windows 上下文視窗的局限性

For example, Opus 4.5 has a 200,000 token context window. But here’s what most people don’t realize: the model starts to deteriorate way before you hit 100%. (this is varying dependent on whether you use through API vs desktop app)

例如 Opus 4.5 的 token 上下文視窗大小為 20 萬。但大多數人沒有意識到的是：在達到 100% 之前模型的表現就開始下降了。（這取決於您是透過 API 使用還是透過桌面應用程式使用）

At around 20-40% context usage is where the quality of the output starts to chip away, even if not significantly. If you’ve ever experienced Claude Code compacting and then still giving you terrible output afterwards, that’s why. The model was already degraded before the compaction happened, and compaction doesn’t magically restore quality. (hit /compact for compacting)

當上下文使用率達到 20-40% 左右時，輸出品質就開始下降，即使下降幅度不大。如果你曾經遇到過 Claude Code 壓縮後輸出仍然很差的情況，原因就在這裡。模型在壓縮之前就已經劣化了，而壓縮並不能神奇地恢復品質。

Every message you send, every file Claude reads, every piece of code it generates, every tool result - all of it accumulates. And once quality starts dropping, more context makes it worse, not better.

你發送的每個訊息、Claude 讀取的每一個檔案、它產生的每一段程式碼、每一個工具的運行結果——所有這些都會累積。一旦品質開始下降，更多的上下文資訊只會讓情況更糟，而不是更好。

Scope your conversations. One conversation per feature or task. Don’t use the same conversation to build your auth system and then also refactor your database layer. The contexts will bleed together and Claude will get confused.

明確對話的範圍。 每個功能或任務只進行一次對話。不要用同一個對話來建構身份驗證系統，然後再重構資料庫層。上下文會混淆，Claude 會感到困惑。

Use external memory. If you’re working on something complex, have Claude write plans and progress to actual files (I use SCRATCHPAD.md or plan.md). These persist across sessions. When you come back tomorrow, Claude can read the file and pick up where you left off instead of starting from zero.

使用外部記憶體。 如果你在處理一些複雜的項目，讓 Claude 把計畫和進度記錄到實際文件中（我用 SCRATCHPAD.md 或 plan.md）。這些資訊會在會話之間保留。明天你回來時，Claude 可以讀取該檔案並從上次中斷的地方繼續。

The copy-paste reset. This is a trick I use constantly. When context gets bloated, I copy everything important from the terminal, run /compact to get a summary, then /clear the context entirely, and paste back in only what matters. Fresh context with the critical information preserved.

複製貼上重置。 這是我常用的技巧。當上下文資訊過多時，我會從終端複製所有重要內容，執行 /compact 命令以取得摘要，然後徹底清除上下文，最後只貼上關鍵資訊。這樣就能得到一個全新的上下文，關鍵訊息也得以保留。

Know when to clear. If a conversation has gone off the rails or accumulated a bunch of irrelevant context, just /clear and start fresh. Claude will still have your CLAUDE.md, so you’re not losing your project context. Nine times out of ten, using clear is actually better than not using it.

要懂得何時清場。 如果對話偏離主題或累積了太多無關訊息，直接使用 /clear 命令清場重新開始。Claude 仍然會記得你的 CLAUDE.md，這樣就不會遺失項目上下文。十有八九使用 clear 實際上比不使用更好。

The mental model that works: Claude is stateless. Every conversation starts from nothing except what you explicitly give it. Plan accordingly.

行之有效的思考模式：Claude 是無狀態的。每一次對話都始於虛無，除非你明確地賦予它某種訊息。據此做好計劃。

Prompts Are Everything 提示至關重要

People spend weeks learning frameworks and tools. They spend zero time learning how to communicate with the thing that’s actually generating their code.

人們花費數週時間學習框架和工具卻從未花時間學習如何與實際產生程式碼的系統進行通訊。

Be specific about what you want. “Build an auth system” gives Claude creative freedom it will use poorly. “Build email/password authentication using this existing User model, store sessions in Redis, and add middleware that protects routes under /api/protected” gives Claude a clear target.

明確你的需求。 「建構一個身分驗證系統」給了 Claude 很大的創作自由，但他可能無法充分利用。具體版本則為 Claude 提供了一個清晰的目標。

Tell it what NOT to do. Claude has tendencies. Claude 4.5 in particular likes to overengineer - extra files, unnecessary abstractions, flexibility you didn’t ask for. If you want something minimal, say “Keep this simple. Don’t add abstractions I didn’t ask for. One file if possible.”

告訴它哪些事情不該做。 Claude 有一些習慣。特別是 Claude 4.5，它喜歡過度設計——產生額外的文件、不必要的抽象層，以及你根本沒要求的靈活性。如果你想要一個極簡的東西，就告訴它：「保持簡單。不要添加我沒要求的抽象層。如果可能的話，最好只用一個文件。」

Always cross-reference what Claude produces because you don’t want to end up having technical debt, especially if you’re building something super simple and it ends up building 12 different files for a task that realistically could have been fixed with a couple of lines of code.

務必交叉檢查 Claude 生成的代碼，因為你肯定不想背負技術債務，尤其是在你構建一個非常簡單的東西時，它卻為了一個實際上只需幾行代碼就能完成的任務生成了 12 個不同的文件。

AI is designed to speed us up and not completely replace us, especially in the era of very professional software engineering. Claude still makes mistakes. Being able to recognize these mistakes will actually solve a lot of your problems.

人工智慧旨在提高我們的工作效率而不是完全取代我們。Claude 仍然會犯錯，能夠識別這些錯誤實際上可以解決你很多問題。

Give it context about why. “We need this to be fast because it runs on every request” changes how Claude approaches the problem. “This is a prototype we’ll throw away” changes what tradeoffs make sense. Claude can’t read your mind about constraints you haven’t mentioned.

解釋原因。 「我們需要它運行速度快，因為它每次請求都會執行」會改變 Claude 解決問題的方式。「這是一個原型，我們會棄用它」會改變哪些權衡取捨是合理的。Claude 無法讀懂你未提及的限制條件。

Output is everything, but it only comes from input. If your output sucks, your input sucked.

輸出至關重要但它源自於輸入。如果你的輸出很差，那就表示你的輸入也很差。

Bad Input == Bad Output

If you’re getting bad output with a good model like Opus 4.5, that means your input and your prompting sucks.

如果你用像 Opus 4.5 這樣優秀的模型都產出差，那就表示你的輸入和提示都很糟糕。

The bottleneck is almost always on the human side: how you structure your prompts, how you provide context, how clearly you communicate what you actually want.

瓶頸幾乎總是出在人身上：你如何建立提示語，如何提供背景訊息，以及如何清晰地傳達你的實際需求。

There are real differences between models:

不同型號之間確實存在差異：

• Sonnet is faster and cheaper. Excellent for execution tasks where the path is clear - writing boilerplate, refactoring based on a specific plan, implementing features where you’ve already made the architectural decisions.
• Opus is slower and more expensive. Better for complex reasoning, planning, and tasks where you need Claude to think deeply about tradeoffs.

• Sonnet 速度更快、成本更低。非常適合執行路徑清晰的任務——例如編寫樣板程式碼、根據特定計劃進行重構、以及在架構決策已經確定的情況下實現功能。
• Opus 速度較慢、價格也較高。更適合複雜的推理、規劃以及需要 Claude 深入思考權衡利弊的任務。

A workflow that works: use Opus to plan and make architectural decisions, then switch to Sonnet (Shift+Tab in Claude Code) for implementation. Your CLAUDE.md ensures both models operate under the same constraints, so the handoff is clean.

一個可行的工作流程是：先用 Opus 進行規劃和架構決策，然後切換到 Sonnet（在 Claude Code 中按 Shift+Tab）進行實作。CLAUDE.md 確保兩個模型在相同的約束條件下運行，從而實現無縫切換。

MCP, Tools, and Configurations MCP、工具和配置

Claude has a ridiculous amount of features. MCP servers. Hooks. Custom slash commands. Settings.json configurations. Skills. Plugins.

Claude 的功能多得驚人。MCP 伺服器、鉤子、自訂斜杠命令、Settings.json 配置、技能、插件。

You don’t need all of them. But you should actually try them and experiment.

你不需要全部都用上。但你應該嘗試一下。

MCP (Model Context Protocol) lets Claude connect to external services. Slack, GitHub, databases, APIs. If you find yourself constantly copying information from one place into Claude, there’s probably an MCP server that can do it automatically. There’s a ton of MCP marketplaces, and if there is not an MCP, it’s just a way of getting structured data, so you can just create your own MCP server for whatever tool that you need added.

MCP（模型上下文協定） 允許 Claude 連接到外部服務，例如 Slack、GitHub、資料庫和 API。如果您發現自己經常需要將資訊從一個地方複製到 Claude，那麼很可能存在一個 MCP 伺服器可以自動完成這項工作。市面上有許多 MCP 服務商，即使沒有現成的 MCP，它也只是獲取結構化資料的一種方式，因此您可以為任何目前尚不存在的工具建立自己的 MCP 伺服器。

Hooks let you run code automatically before or after Claude makes changes. Want Prettier to run on every file Claude touches? Hook. Want type checking after every edit? Hook. This catches problems immediately instead of letting them pile up. This is actually what helps remove technical debt as well.

鉤子 允許你在 Claude 修改程式碼之前或之後自動執行程式碼。想讓 Prettier 在 Claude 修改的每個檔案上都執行一次？用鉤子。想在每次編輯後進行類型檢查？用鉤子。這樣可以立即發現問題，而不是讓問題堆積。這實際上也有助於消除技術債。

Custom slash commands are just prompts you use repeatedly, packaged as commands. Create a .claude/commands folder, add markdown files with your prompts, and now you can run them with /commandname. If you’re running the same kind of task often - debugging, reviewing, deploying - make it a command.

自訂斜杠指令 其實就是將你重複使用的提示打包成指令。建立一個 .claude/commands 資料夾加入包含提示的 Markdown 文件，現在你就可以使用 /commandname 來執行它們了。如果你經常執行同類型的任務——例如調試、程式碼審查或部署——那就把它做成一個命令。

If you have the Pro Max plan ($200/month), why not try everything Claude has to offer? See what works and what doesn’t.

如果你訂購了 Pro Max 套餐（每月支付 200 美元），為什麼不試試 Claude 提供的所有服務呢？看看哪些有效，哪些無效。

Don’t get shut off if something doesn’t work on the first try. These models are improving basically every week. Something that didn’t work a month ago might work now.

如果第一次嘗試失敗，不要灰心喪志。這些模型幾乎每週都在改進。一個月前行不通的方法，現在可能就管用了。

When Claude Gets Stuck Claude 陷入困境

Sometimes Claude just loops. It tries the same thing, fails, tries again, fails, and keeps going. Or it confidently implements something that’s completely wrong and you spend twenty minutes trying to explain why.

有時候 Claude 會陷入循環。它嘗試同樣的事情失敗、再嘗試再次失敗、然後繼續。或者它自信滿滿地執行了一些完全錯誤的東西，而你卻要花二十分鐘試圖解釋原因。

When this happens, the instinct is to keep pushing. But the better move is just to change the approach entirely.

遇到這種情況人們的本能反應是繼續施壓。但實際上更好的做法是徹底改變方法。

• Clear the conversation. /clear gives you a fresh start.
• Simplify the task. Break it into smaller pieces. If Claude is struggling with a complex task, your plan mode is insufficient.
• Show instead of tell. Write a minimal example yourself. “Here’s what the output should look like. Now apply this pattern to the rest.” Claude is extremely good at understanding what success looks like and following good examples.
• Be creative. Try a different angle. Reframing - “implement this as a state machine” vs “handle these transitions” - can unlock progress.

• 清理對話。 /clear 讓你重新開始。
• 簡化任務。 切更小，如果 Claude 還在卡，代表你的 plan mode 不夠。
• 用實例說話而不是空談。 自己寫個簡單例子。「輸出結果應該是這樣的，現在把這個模式應用到其他部分。」Claude 非常擅長理解成功指標的含義並能切實地遵循這些指標。
• 發揮創意。 嘗試不同的角度。重新定義問題——例如從「處理這些狀態轉換」改為「將其實現為狀態機」——或許能帶來突破。

The meta-skill here is recognizing when you’re in a loop early. If you’ve explained the same thing three times and Claude still isn’t getting it, more explaining won’t help. Change something.

這裡的關鍵技巧在於及早意識到自己陷入了循環。如果你已經解釋了三遍 Claude 還是不明白，再解釋也沒用。那就得做出改變。

Build Systems 建構系統

The people who get the most value from Claude aren’t using it for one-off tasks. They’re building systems where Claude is a component. Claude code has a -p flag for headless mode. It runs your prompt and outputs the result without entering the interactive interface. This means you can script it. Pipe output to other tools. Chain it with bash commands. Integrate it into automated workflows.

真正能從 Claude 中獲益的人並非將其用於一次性任務，而是建立以 Claude 為組件的系統。Claude Code 有一個 -p 標誌用於無頭模式。在無頭模式下它會直接運行你的提示符號並輸出結果，而無需進入互動式介面。這意味著你可以編寫腳本、將輸出傳遞給其他工具、將其與 bash 命令連結起來，並將其整合到自動化工作流程中。

Enterprises are using this for automatic PR reviews, automatic support ticket responses, automatic logging and documentation updates. All of it logged, auditable, and improving over time based on what works and what doesn’t.

企業利用這項技術實現自動公關審核、自動支援工單回覆、自動日誌記錄和文件更新。所有操作都會被記錄、可審計，並根據有效和無效的回饋不斷改進。

The flywheel: Claude makes a mistake, you review the logs, you improve the CLAUDE.md or tooling, Claude gets better next time. This compounds. Right now I’m in the process of being able to have Claude already improve its own CLAUDE.md files. After months of iteration, systems built this way are meaningfully better than they were at launch - same models, just better configured.

飛輪效應：Claude 犯了錯誤，你查看日誌，你改進 CLAUDE.md 或工具方面，Claude 下次會做得更好。這種效果會不斷累積。目前我正在努力讓 Claude 能夠改進它自身的 CLAUDE.md 文件方面。經過數月的迭代，以這種方式建構的系統比剛發佈時有了顯著改進——同樣的模型，只是配置更優化。

If you’re only using Claude interactively, you’re leaving value on the table. Think about where in your workflow Claude could run without you watching.

如果你只是以互動方式使用 Claude那就錯失了它的全部價值。想想看在你的工作流程中哪些環節可以讓 Claude 在無需你監督的情況下運作。

TLDR

• Think before you type. Planning produces dramatically better results than just starting to talk.
• CLAUDE.md is your leverage point. Keep it short, specific, tell it why, and update constantly.
• Context degrades at 30%, not 100%. Use external memory, scope conversations, and don’t be afraid to clear and restart with the copy-paste reset trick.
• Architecture matters more than anything. You cannot skip planning.
• Output comes from input. If you’re getting bad results with a good model, your prompting needs work.
• Experiment with tools and configuration. MCP, hooks, slash commands. Stay curious even when things don’t work the first time.
• When stuck, change the approach. Don’t loop. Clear, simplify, show, reframe.
• Build systems, not one-shots. Headless mode, automation, logged improvements over time.

打字前先思考。事先做好計劃比貿然開口有效得多。

CLAUDE.md 是你的槓桿點。務必保持簡潔、具體、說明原因，並不斷更新。

上下文會在 30% 時開始劣化，而不是 100%。使用外部記憶體、限定對話範圍，並且不要害怕使用複製貼上重置技巧來清除並重新開始。

建築設計比什麼都重要。規劃必不可少。

輸出源於輸入。如果使用優秀的模型卻得到糟糕的結果，表示你的引導方式需要改進。

嘗試各種工具和配置。MCP、鉤子、斜線指令等等。即使第一次嘗試失敗，也要保持好奇心。

遇到瓶頸時換個方法。不要陷入循環。理清思路、簡化問題、展示結果、重新建構框架。

建構系統而非一次性項目。採用無頭模式、自動化，並記錄長期改善情況。