P1

很多人打開 Claude 或 AI 工具，輸入一句需求，等它直接交出完整答案。

結果不夠準，就開始懷疑模型不好用。

問題往往不是 Claude 不夠聰明，而是我們把它當成「自動完成工具」，卻沒有把任務交代清楚。

P1 比較好的方式，是把 Claude 想成一位能力很強、但剛進公司的新同事。

它有判斷力，也能處理複雜工作，但不知道你的背景、目標、習慣和限制。你交代得越清楚，它越能做出接近你想要的結果。

尤其新一代 Claude 5 系列的判斷能力已經提升，過去為舊模型設計的大量防呆規則，不一定還要全部保留。規則太多，有時反而綁住模型，讓回答變得僵硬。

寫 Prompt，先把事情說清楚

P1

最有效的技巧，其實不是什麼神奇關鍵字，而是「清楚、直接」。

不要只說：

幫我整理一下。

可以改成：

請整理成 500 字內的繁體中文文章，語氣自然，適合手機閱讀，保留原始數據，不要自行補充情節。

格式、長度、語氣、限制和使用情境，能說清楚就不要讓 Claude 猜。

當資料比較多時，也可以用 XML 標籤分區：


<instructions>

請整理以下內容，保留重要數據。

</instructions>

<data>

原始資料放在這裡。

</data>

<examples>

提供希望的輸出範例。

</examples>

這樣做的目的不是炫技，而是把指令、資料和範例分開，避免 Claude 把不同內容混在一起。

給角色，但不要只給角色

你可以告訴 Claude：

你是一位資深 TypeScript 工程師。

但只有角色還不夠。

最好接著說明它要處理什麼、最後要交出什麼，以及哪些事情不能做。

例如：

你是一位資深 TypeScript 工程師。請檢查以下程式碼的型別問題，先列出錯誤原因，再提供修改版本，不要更動原本的功能流程。

角色負責設定視角，任務說明才真正決定輸出品質。

複雜問題，不要急著叫它直接做

面對程式開發、資料分析或 Agent 任務，可以改用這個流程：

先探索 → 再規劃 → 接著執行 → 最後驗證

不要一開始就說：

直接幫我把整個系統寫完。

可以先讓 Claude 讀取檔案、確認現況、列出處理步驟，再開始修改。

完成後，也不要只問它「有沒有做好」，而是提供可驗證的方法，例如：

  • 執行哪些測試

  • 檢查哪些輸出

  • 哪些條件代表成功

  • 哪些邊緣情況也要通過

Claude 能自己執行測試、比對結果，會比單純產生一段看起來合理的答案可靠。

範例通常比形容詞更有效

P1

與其寫一長串：

語氣要自然、專業、有溫度、不要太正式，也不要太隨便……

不如直接提供一至三個範例。

可以放一個你喜歡的版本，再放一個你不希望出現的版本，讓 Claude 看出差異。

這就是 Few-shot 的概念。

對模型來說，具體範例通常比抽象描述更容易理解，也比較不會每次產生完全不同的結果。

輸出格式也要先說

需要 JSON，就直接指定 JSON。

需要 Markdown、表格或固定欄位，也要先寫清楚。

有些情況還可以先提供輸出的開頭，讓 Claude 接著完成，也就是 prefill。

例如先放：


{

  "title":

比起只說「請輸出 JSON」，格式通常會更穩定。

不要一次把所有資訊塞進去

P1

資訊多，不代表一定要在第一則 Prompt 全部丟完。

可以先給任務目標，再補充資料、限制和範例。重要資訊分階段提供，Claude 比較容易抓到優先順序。

遇到需要取捨的情況，也不要只下死命令，可以把兩面的條件說清楚。

例如：

優先維持程式相容性，但若會造成明顯效能問題，可以調整架構，並說明原因。

這比堆疊十幾條規則，更能發揮新模型的判斷能力。

Prompt 也需要測試和除錯

一個 Prompt 寫完，不代表就定稿。

可以準備幾組不同資料測試：

  • 一般案例

  • 資料不完整的案例

  • 格式異常的案例

  • 容易誤判的邊緣案例

如果結果不穩定，就檢查是哪一句容易產生歧義，再調整指令。

這個過程很像修 Bug。

不是一直增加更多規則，而是找出問題真正發生的位置。

Claude Code 與 Agent 的使用方式

如果是 Claude Code 或長期專案，可以把固定規則寫進 CLAUDE.md。

例如：

  • 專案架構

  • 命名方式

  • 程式風格

  • 禁止修改的範圍

  • 測試指令

  • 完成條件

這些長期不變的資訊，不需要每次重新貼上。

至於工具使用，也要記得一件事：

Prompt 無法憑空增加模型能力。

需要查檔案，就要提供檔案工具；需要執行程式，就要有執行環境；需要查詢外部資料，就要讓它能使用相對應的工具。

指令寫得再漂亮，也不能取代缺少的工具。

真正的核心，不是背咒語

P1

好的 Prompt，不是塞入越多專業名詞越好。

它更像一份清楚的任務委託：

你要做什麼、資料在哪裡、有哪些限制、最後要交付什麼，以及如何確認完成。

把 Prompt 當成「概念工程」，持續測試、修正和簡化，你會發現，真正拉開差距的不是某一句神奇指令，而是你有沒有把事情說清楚。

原始資料來源

Anthropic 把這些 session 都上傳到 YouTube 官方頻道了：

  • Prompting 101 | Code w/ Claude（最接近貼文內容）
    → https://www.youtube.com/watch?v=ysPbXH0LpIE（約 25 分鐘）
  • Prompting for Agents | Code w/ Claude（Agent 提示工程）
    → https://www.youtube.com/watch?v=XSZP9GhhuAc（約 29 分鐘）
  • The Prompting Playbook（進階 debug prompt，像影片裡的實作示範）
    有好幾個錄影版本，YouTube 搜尋 “The Prompting Playbook Code w/ Claude” 就能找到。