04 · 怎麼和 AI 說話

翔宇一開始也在網上搜最佳提示詞模板，照著抄，有時有效有時沒效。後來想明白了——模板不是重點，你給 AI 的資訊才是。一旦把注意力從怎麼措辭轉到給什麼資訊，一切都清楚了。——翔宇

1. 一個 40 秒和一個 5 秒

你對 Claude Code 說：幫我最佳化這段程式碼。

它改了。你一看——變數名全換了，加了一堆你不需要的註釋，還把一個函式拆成了三個。方向完全不是你想要的。你重新解釋，它再改，又錯。來回 40 秒沒辦法繼續幹活。

現在換一種說法：這段程式碼有記憶體洩漏問題，請找出洩漏點，重點關注資料庫連線和檔案控制代碼，給出修復方案，不要重新命名變數也不要拆分函式。

同一個 AI，同一段程式碼，這次的輸出精準得像換了一個人。5 秒鐘你就能繼續往下幹。

發生了什麼？AI 沒變，程式碼沒變。唯一變了的是你輸入的資訊。第一次你給了一個模糊方向（最佳化），第二次你給了精確目標（找洩漏）+ 範圍（資料庫 / 檔案控制代碼）+ 期望產出（修復方案）+ 邊界（不重新命名、不拆分）。

2. 模型不讀心

如果只能記住一句話，記這一句：模型不讀心。

它沒辦法猜你腦子裡那個具體場景。它只看到你輸入的那些字。你腦子裡清楚但沒說的部分——它當成自由發揮的空間。

flowchart LR
    Brain["🧠 你腦子裡<br/>真實想要的"]
    Words["⌨️ 你打出來的字<br/>只是一部分"]
    AI["🤖 模型基於字推斷<br/>缺失部分用最可能的填"]
    Output["📦 輸出<br/>跟你想要的差距 = 缺失部分"]

    Brain -.資訊丟失.-> Words
    Words --> AI
    AI --> Output

    Brain -.->|對照差距| Output

    style Brain fill:#dcfce7,stroke:#22c55e
    style Words fill:#fef3c7,stroke:#f59e0b
    style AI fill:#dbeafe,stroke:#3b82f6
    style Output fill:#fee2e2,stroke:#ef4444

這就是為什麼資訊越精確，輸出越精準。不是提示詞模板的功勞，是資訊量的功勞。

3. 資訊四件套

要讓模型有能力做你想要的事，每條指令本質上要給 4 類資訊。這 4 類構成一套可調的工程語言：

把開頭那兩個例子拆成四件套對比：

差別不在措辭——在資訊量。

4. 把模糊變具體的 3 個槓桿

知道了四件套，怎麼讓每件都變具體？三個槓桿：

槓桿 1 · 把抽象動詞換成可驗證動詞

判斷標準：動詞要能驗證——做完了能不能客觀判斷完沒完？模糊動詞做不完，具體動詞做完了能跑測試。

槓桿 2 · 給顯式範圍（路徑 / 表 / 時間 / 數量）

顯式範圍讓模型不需要猜——它直接照著做。

槓桿 3 · 顯式說出隱含約束

每個專案都有人人都知道但沒人寫下來的約定。模型沒法靠常識猜出來。

• 我們這個專案所有 API 必須返回 { data, error } 結構 → 寫進 CLAUDE.md（03 篇）或臨時說明
• 測試不要 mock 資料庫 → 寫進 CLAUDE.md，否則每次都要提醒
• 這個函式雖然看起來簡單但有 3 個隱藏呼叫方 → 臨時上下文必須寫
• 這段程式碼 2 周後要重構，臨時方案別太完美 → 邊界

每次糾正 Claude，都是在補這一類隱含約束。補一次寫進 CLAUDE.md，比補十次省心。

5. 何時用結構化提示

正常對話——四件套用自然中文寫下來，夠了。

但長指令、複雜任務、多步驟——結構化能讓模型更穩定。

<task>修复支付回调幂等性 bug</task>

<context>
- 文件：controllers/webhook.ts、queue/retry.ts
- 现象：webhook 重试时 transaction 创建多次
- 已知线索：retry.ts 第 34 行没读 idempotency_key
</context>

<constraints>
- 不改 controllers/webhook.ts 的对外接口
- transaction 表 schema 不动
- 修复 diff < 100 行
</constraints>

<acceptance>
- 跑 tests/payment/retry.test.ts 全过
- 手动跑 scripts/replay-webhook.sh 重放 3 次只创建 1 个 transaction
- 不引入新依赖
</acceptance>

XML 標籤是事實標準（Claude 系列對它訓練得最熟）。4 個標籤對應 4 件套——目標、上下文、邊界、驗收。

為什麼 Claude 系列對 XML 標籤特別敏感：Anthropic 在訓練 Claude 時大量用了 XML 結構化的 prompt 資料，官方的 prompt engineering 文件也把 XML 標籤作為推薦寫法。這意味著模型在解析 <task> <context> <constraints> <acceptance> 時會把它們當作強語義邊界——比純散文段落更容易識別"這一段是目標，那一段是約束"。換成 Markdown 標題（## 目標）也能用，但 Claude 對 XML 的訓練訊號更強。這是模型偏好，不是協議要求——其它模型（GPT / Gemini）用 Markdown 反而更好。

什麼時候不用 XML：日常 1-2 句的對話不要用 XML 包裹（噪音大於訊號）。指令長度超過 200 字、或要求 ≥ 3 個獨立約束時，結構化才有收益。

6. 跟人說話 vs 跟 Claude 說話

很多人覺得跟 Claude 說話像跟實習生說話。這個比喻 80% 對——但有 20% 關鍵差異：

結論：跟 Claude 說話前置成本更高——你得提前說清楚，因為它不會問你。但你說一次，寫進 CLAUDE.md，以後不用再說。這是值得的交易。

7. 一個反覆有效的工作流

把上面所有內容串成一個可重複的工作流：

flowchart TD
    Start["📝 寫一條指令"]
    Check{"4 件套<br/>都給了嗎？"}
    Run["▶️ 跑一遍 Claude"]
    OK{"輸出方向<br/>對嗎？"}
    Done["✅ 收工"]
    Diag["🔍 診斷<br/>哪一件套缺了？"]
    Fix["✍️ 補缺失的"]
    Save{"是不是<br/>專案級規則？"}
    CLAUDE["📜 寫進 CLAUDE.md"]

    Start --> Check
    Check -->|是| Run
    Check -->|否| Fix
    Run --> OK
    OK -->|對| Done
    OK -->|不對| Diag
    Diag --> Fix
    Fix --> Save
    Save -->|是| CLAUDE
    Save -->|否| Run
    CLAUDE --> Run

    style Done fill:#dcfce7,stroke:#22c55e
    style CLAUDE fill:#dbeafe,stroke:#3b82f6
    style Diag fill:#fef3c7,stroke:#f59e0b

第一次問 → 檢查 4 件套齊不齊 → 跑 → 不對就診斷哪件套缺了 → 補 → 如果是專案級規則就寫進 CLAUDE.md → 再跑。

跑通幾個週期後，CLAUDE.md 越寫越完整，你給 Claude 的指令會越來越短——因為公共上下文都已經在檔案裡了，每次只需要補這次任務特有的目標 + 範圍 + 邊界。

8. 檢驗你真懂了嗎

試著用自己的話回答：

1. 有人說提示詞技巧的本質是措辭，你能反駁嗎？真正決定輸出質量的是什麼？對應 §2 + §3。
2. 4 件套裡最容易被忽略的是哪一件？為什麼忽略它最容易翻車？舉一個例子。對應 §3。
3. 動手題 ⭐：拿出你昨天給 Claude Code 發過的最模糊的一條指令（比如"最佳化這段程式碼"、"改改這個函式"）。按 4 件套（目標 / 上下文 / 邊界 / 驗收）改寫一遍，每一件至少補一句具體的。改寫完對比原版，估算新版會減少多少輪"它沒聽懂我再解釋" 的來回——這就是 4 件套省下的真實成本。 對應 §3 + §4。

官方資料

• Best practices
• Common workflows
• Quickstart

接下來去哪

不用按順序全讀。挑你最好奇的那條線走就行。