補充 #10 · Provide Specific Context

寫出精準 Prompt

指令越精確、修正越少。官方提供 4 種改寫技巧 + 5 種餵資料方式。

四種改寫技巧 · Before / After

① 劃範圍

指定檔案、情境、測試偏好

❌ 改寫前

幫 foo.py 加測試

✅ 改寫後

幫 foo.py 寫一條測試，涵蓋使用者已登出的邊界情況。不要用 mock。
② 指向來源

直接指明能回答問題的資料源

❌ 改寫前

為什麼 ExecutionFactory 的 API 這麼怪？

✅ 改寫後

查 ExecutionFactory 的 git history，總結它的 API 是怎麼演變來的
③ 引用既有 pattern

點名專案中已存在的範例

❌ 改寫前

加一個 calendar widget

✅ 改寫後

先看 HotDogWidget.php 理解專案的 widget 寫法，再依同樣風格做一個 calendar widget。從零寫起，不要引入新套件。
④ 描述症狀

給症狀 + 可能位置 + 修好的樣子

❌ 改寫前

修一下 login bug

✅ 改寫後

使用者反映 session timeout 後登入失敗。檢查 src/auth/，特別是 token refresh。先寫一條會失敗的測試重現問題，再修掉

餵 Claude 資料的五種方式

不要用「描述」，能直接給的就直接給。

📎 @檔名

直接用 @src/foo.ts 引用檔案，比「描述 code 在哪」可靠。

🖼️ 貼圖片

UI bug、截圖 error 訊息、設計圖直接複製貼上或拖進去。

🔗 給 URL

文件、API 參考直接給網址；常用網域用 /permissions 加入 allowlist。

🚰 pipe data

cat error.log | claude 直接把檔案內容餵進來。

🛠️ 讓 Claude 自己抓

叫它用 Bash / MCP / 讀檔自己去取所需 context — 不用每件事都你貼。

💡 例外：模糊也有用的時候

當你還在 探索階段、可以承受 AI 自由發揮時，模糊 prompt 反而有用。

$ 這個檔案還有哪些地方可以改進？

# 你會看到原本想不到的角度

# 一句話心法

「Claude 能推論意圖，但不能讀你的心」— 精確度直接決定修正次數