Prompt Library：52 組官方逐字提示詞

1. 快速掌握整體架構

接手任何不熟悉的程式碼庫時的第一步——不必自己一層層點開資料夾瞎找，直接讓 Claude 掃過整個專案，回你一份「架構＋關鍵目錄＋模組怎麼串起來」的地圖，後面要深入哪一塊再自己挑。官方 Start Here 起手式第 1 條，也是站方建議的入門提示詞。

give me an overview of this codebase: architecture, key directories, and how the pieces connect

2. 解釋特定檔案怎麼運作

鎖定單一檔案要求逐步解釋資料怎麼流動，並直接指定輸出格式（HTML 加圖表）。比起純文字回答，圖解更容易一眼看懂複雜的資料流向；花括號段落可以換成任何你看得懂的輸出形式，不一定要是網頁。

explain what {src/scheduler/queue.ts} does and how data flows through it. write it up as {an HTML page with a diagram, then open it in my browser}

3. 找特定功能寫在哪裡

知道某個行為存在、但不知道它寫在哪個檔案哪個函式時，直接用一句話描述「這個行為」讓 Claude 幫忙定位，比自己憑關鍵字做全域搜尋準——尤其當變數或函式命名跟你腦中的行為描述對不上的時候。官方 Start Here 起手式第 2 條。

where do we {validate uploaded file types}?

4. 刪東西前先確認會不會炸

動手刪除或重構前，先把「這東西被誰引用、刪了會不會連帶壞掉」丟給 Claude 追蹤依賴關係，把原本得憑印象猜的風險，變成一個可以先問清楚再動手的問題。

what would break if I deleted {the retryWithBackoff helper}?

5. 追蹤一段程式碼是怎麼演變成現在這樣

面對「這段程式碼為什麼長這樣、當初是不是有什麼考量」的疑問，讓 Claude 翻 commit history 幫你整理出演變脈絡與背後原因，省下自己一條條翻 git log 的時間，適合接手祖傳程式碼時用。

look through the commit history of {internal/auth/session.go} and summarize how it evolved and why

6. 估算一個功能要動到哪些檔案

不用先寫程式碼，就能先問「這個功能如果要做，要動到哪些檔案」，讓 Claude 掃過程式碼庫抓出實際的異動範圍，取代開會口頭猜工作量。對 PM、設計來說，這是規劃新功能時可以自己動手問程式碼庫的方式，不必先卡到工程師的時間才能拿到一個大概的範圍評估——問完再帶著具體的檔案清單去跟工程師對焦，討論會更有效率。

which files would I need to touch to {add a dark mode toggle to settings}?

7. 直接向程式碼庫問產品問題

非工程背景的人想搞懂「使用者按下這個按鈕之後，系統實際做了什麼」，先把自己的身份告訴 Claude，它會用適合的說明深度，從畫面操作一路講到後端處理結果，不必自己先學會讀程式碼才能問出有意義的問題。花括號段落可以換成任何非工程角色（設計、行銷等），Claude 會依此調整解釋的技術深度——這是這 7 則裡最直接證明「程式碼庫不是只有工程師能問」的一則。

I am a {PM}. walk me through what happens when a user {clicks Export to PDF}, from the UI down to the result

提示詞 1：規劃多檔案改動，先看不動手

大範圍改動先讓 Claude 列出「會動到哪些檔案、改動順序」，你看過清單再放行，不會等到程式碼已經動了一半，才發現方向理解錯了。工程師為主；但 PM、設計師要評估一項改動的範圍大小、有沒有踩到其他模組時，同樣能拿來問。這招在 Claude Code 裡有正式功能對應：按兩下 Shift+Tab 進入的 計畫模式（Plan Mode），同樣是先給計畫、你點頭才動手。

plan how to refactor the {payment module} to {support multiple currencies}. list the files you would change, but don't edit anything yet

提示詞 2：讓 Claude 反過來面試你，把規格榨乾

你只給一個模糊的功能構想，讓 Claude 主動追問實作細節、使用者體驗、邊界情況與取捨，問到雙方都有共識才落成 SPEC.md——適合還沒想清楚細節、想靠被追問逼自己想清楚的起手式。這句官方原文站內也有對應章節：claude 第 14 章 §14.9 Specs-Before-Code，講的正是同一招——先寫 spec，讓 Claude 訪談你。

I want to build {per-workspace rate limits}. interview me about implementation, UX, edge cases, and tradeoffs until we have covered everything, then write the spec to SPEC.md

這句解決的是「需求訪談＋寫規格」，還不是完整開發框架。若任務會接著拆 tickets、走 TDD、獨立 review 或跨 session，請看GSD、Spec Kit、Superpowers、OpenSpec 與其他主流工作流比較。

提示詞 3：把會議記錄變成工作項目

貼會議紀錄檔案路徑，讓 Claude 自己抓出「誰要做什麼」的行動項目，再逐一開成工單並附驗收條件，省下開完會自己整理待辦、手動開票的步驟。站內有 PM 達人實測案例可對照：PRD 一鍵拆成工單，同樣是接 Linear MCP、批次生成含驗收條件的工單，Spiral GM 幾分鐘生出約 100 張 GitHub Issues。

需要：先把你的 issue tracker（如 Linear、Jira）加為 claude.ai 的 connector 或 MCP server，才能直接建立工單。

read {@meeting-notes.md} and write up the action items, then create a {Linear} ticket for each with acceptance criteria

提示詞 4：開工前先把邊界狀態列清楚

在畫線框圖或寫規格之前，先問 Claude 這個流程有哪些錯誤狀態、空狀態、極端情況要設計顧到，避免這些狀態被留到開發階段才臨時想。站內網頁設計達人案例開篇就點名這個坑：邊界情境為什麼常常等到開發階段才被發現——Figma 稿一旦定案，設計端已經來不及改。

list the error states, empty states, and edge cases for {the file upload flow} that the design needs to cover

提示詞 5：設計稿貼上去，直接生出可以點的原型

直接把設計稿丟給 Claude，依照畫面上的版面與狀態生成一個可以實際點擊操作的原型，不用先請工程師排期，就能先看到動態效果。站內有具體實測數字：設計稿一鍵變成網站，Figma MCP 讀元件與 auto layout，Felix Lee 實測 15 分鐘內完成。

先把設計稿圖片貼上、拖曳進來，或用 @ 提及檔案之後，再送出下面這句提示詞。

here is a mockup. build a working prototype I can click through, matching the layout and states shown

提示詞 6：做完自己截圖比對，揪出跟設計稿的落差

實作完不要只憑自己判斷「應該做完了」，叫 Claude 自己截圖、跟原始設計稿比對、揪出落差再自己修，把「看起來對」換成「真的截圖比對過」。這句官方範例站內有完整實作步驟：叫它自己看畫面改版面，裝 Playwright MCP 讓 Claude 自己截圖比對、自主修正。

需要：讓 Claude 能夠渲染畫面並截圖（Desktop App 內建；終端機環境需另外安裝 Chrome 擴充功能或 Playwright MCP server），並先把設計圖貼上、拖曳進來或用 @ 提及檔案，再送出下面這句提示詞。

implement this design, then take a screenshot of the result, compare it to the original, and fix any differences

1. 參考現有模式寫新功能

先讓 Claude 讀懂一個你已經有的實作模式，再照同樣的結構做一個新的——省去重講一次架構規範的力氣，新功能自然跟現有寫法一致。

look at how {the GitHub webhook handler} is implemented to understand the pattern, then build {a Stripe webhook handler} the same way

2. 幫沒有文件的函式補 JSDoc

批次補文件註解，同時要求比照檔案裡既有的寫法，不會生出一套自己的格式跟原本的並存。

find {the public functions in src/auth/} without {JSDoc} comments and add them, matching the style already used in the file

3. 加一個小型 endpoint

最基本的「講清楚你要什麼」示範——路徑、回傳內容都寫死，不留模糊空間讓 Claude 自己猜規格。

add a {/health} endpoint that returns {the app version and uptime}

4. 做一個小型內部工具（非工程師適用）

不需要專案脈絡、單檔案就能跑的小工具，並指定「開啟瀏覽器」讓你當場看到成果。不是工程師，也能直接用這句話換一個可用的畫面。

create a {drag-and-drop Kanban board with three columns} using HTML, CSS, and vanilla JavaScript, then open it in my browser

5. 直接從 issue 編號工作

讀 issue、動手修、跑測試三件事一次做完，你只需要給編號。

需要：gh CLI 完成登入驗證，或是把 GitHub 加為 claude.ai 的 connector。

read issue #{312}, implement the fix, and run the tests

6. 找出所有相同文案並統一修改

全庫文案統一改字，特別示範怎麼「劃邊界」——明講哪些檔案不要動（測試、changelog），避免改過頭波及不相關的地方。

find every place we say "{Sign up free}" or a close variant, show me each one in context, then update them all to "{Start free trial}". leave tests and the changelog alone

7. 參考既有範本寫新文件

跟第 1 則邏輯相同，但用在寫作類產出——先讀懂既有文件的結構跟語氣，再寫一份新的，維持全庫文件風格一致。

read the {privacy impact assessments} in {legal/pia/} to learn the structure and voice, then draft a new one for {the new analytics integration}

8. 寫測試、跑測試、修失敗

寫測試不是終點。這句話把「跑起來」跟「失敗就修」都寫進同一個指令，Claude 才會自己迴圈到綠燈為止，不是丟一份測試檔案就交差。（此則亦為官方列出的 5 組建議起手式之一。）

write tests for {app/parsers/feed.py}, run them, and fix any failures

9. 測試先行開發

反過來，先讓測試定義「完成」長什麼樣，再要求實作寫到通過為止——驗收標準寫在最前面，而不是寫完才補測試。

write tests for {the password reset flow} first, then implement it until they pass

10. 從覆蓋率報告補缺口

不是憑感覺補測試，而是讀真實的覆蓋率資料找出最弱的檔案，設一個可量測的目標（80%）當停止線。

read {coverage/coverage-summary.json} and add tests for the lowest-covered files until each is above {80}%

11. 在整個程式碼庫遷移某個模式

大範圍替換前先要求「列出所有要改的地方」再動手，把偵查跟執行拆成兩步，避免漏改或範圍誤判。

migrate everything from {the old logging API} to {the structured logger}: identify every place that needs to change, then make the changes

12. 跨語言移植

換語言重寫最怕行為跑掉，這句話明講「保留一致的地方」是什麼（公開 API 跟測試行為），縮小 Claude 自由發揮的空間。

port {this Python module} to {Rust}, keeping the same {public API and test behavior}

13. 針對可量測指標最佳化

效能最佳化給一個具體數字目標，而不是「讓它變快」——有明確終點，Claude 才知道最佳化到什麼程度可以停手。

optimize {the search query} to bring {p95 latency} from {2s} down to under {500ms}

14. 修正精確的視覺 bug

視覺 bug 描述到「差幾 px、在哪個裝置」的精確度，比丟一張截圖說「這裡怪怪的」更容易一次修對。

the {login button} extends {20px} beyond the {card border} on {mobile}. fix it.

15. 提交前自我審查

提交前的最後一道關卡，讓 Claude 用第二雙眼睛看一次自己剛寫的東西，抓明顯的風險點。（此則亦為官方列出的 5 組建議起手式之一。）

review my uncommitted changes and flag anything that looks risky before I commit

16. 審查 PR

跳過手動翻 PR 頁面的流程，直接讓 Claude 讀取整個 PR、摘要異動再列出疑慮。

需要：gh CLI 完成登入驗證，或是把 GitHub 加為 claude.ai 的 connector。

review PR #{247} and summarize what changed, then list any concerns

17. 審查 Terraform 計畫輸出

基礎設施異動最怕看不懂 plan 輸出就直接 apply，這句話讓 Claude 先幫你翻譯這次變更會做什麼、有沒有風險。

先把 terraform plan 的輸出貼進提示詞，再送出這句話。

here is my Terraform plan output. what is this going to do, and is anything here going to cause problems?

18. 安全性審查

明確指名用 subagent 執行——審查過程在它自己獨立的 context window 裡跑，不會把一堆掃描細節塞進你正在用的主對話，回報時只交結果給你。這是「審查工作交給獨立分身處理、不佔用主對話」的具體示範。

use a subagent to review {src/api/} for security issues and report what it finds

19. 上線前內容審查

內容審查一樣可以精確列出檢查項目（沒根據的宣稱、漏標來源、品牌規範），不是丟一句「幫我看看」。

review {launch-post.md} for {unsupported claims, missing attributions, and brand-guideline issues} and list anything I should fix before it goes to {legal}

20. 糾正方向錯誤

Claude 做錯方向時，直接講清楚錯在哪、限制是什麼，再要求換一個做法——比單純說「不對」更快拉回正軌。

that is not right: {the function signature needs to stay backward-compatible}. try a different approach

21. 縮減過大的改動範圍

改動範圍跑超過預期時，明確劃出要保留的部分，其餘要求撤銷，避免一次 review 要面對一堆不相關的異動。

that is too much. keep only the changes to {the validation logic in src/forms/} and undo your other edits

22. 把糾正行為寫進 CLAUDE.md

同樣的錯誤講第二次就該寫進 CLAUDE.md，讓修正變成往後每個 session 都自動生效的規則，不必每次重新提醒一次。

you keep {using default exports when this project uses named exports}. add a rule to CLAUDE.md so this stops happening

Ship-1　解決合併衝突

兩個分支剛好改到同一行、Git 停下來等你決定要留誰的版本時，直接把這句丟給它——不用自己一個個 hunk 比對，它還會順便講清楚「這裡留了哪邊的版本、為什麼」，收尾後方便回頭查。站內對應教學：claude 第 6 章 §6.4 處理合併衝突，一步步教怎麼跟 Claude 說「幫我解決這些合併衝突」。

resolve the merge conflicts in this branch and explain what you kept from each side

Ship-2　commit 訊息自動生成

做完一段告一段落的工作，不想自己想措辭，就用這句請它先讀懂這次的改動再動筆。訊息品質跟你這次改動的範圍夠不夠聚焦有關——範圍太雜、把好幾件不相干的事混進同一次改動，寫出來的說明也會跟著空泛。不熟 Git 指令也不用怕：claude 第 6 章 §6.2 讓 Claude 幫你 commit教完整流程。

commit these changes with a message that summarizes what I did

Ship-3　從 issue／ticket 直接開 PR

先讓它讀 issue tracker 裡的票，整理需求與影響範圍；第一輪不要直接開分支、改檔或開 PR。確認計畫、權限與測試方式後，再依 Claude 第 6 章 §6.3 的安全流程進入實作。

需要：先確認 issue tracker（例如 Linear、Jira）的來源、可讀資料範圍與權限。花括號 {…} 都要換成自己的內容，不能原樣送出。

Read the {Linear} ticket about {the login timeout} and related code. Output a requirement summary, affected files, implementation plan, test approach, and a PR draft. Do not create a branch, modify files, or open a PR until I approve.

Ship-4　從版本歷史生成 release notes

給它兩個版本號，它去讀這兩個版本之間差了什麼，按功能、修正、破壞性變更分類寫成一份說明。這則特別值得注意：操作對象是版本紀錄本身，不是程式碼，所以不只工程師能用——PM 可以直接拿去寫產品公告，行銷可以改寫成使用者看得懂的更新文案，文件維護者可以拿去更新 changelog 頁面，同一句提示詞，三種角色接下去的用途各自不同。

compare {v2.3.0} to {v2.4.0} and draft release notes grouped by feature, fix, and breaking change

Ship-5　寫 CI 工作流

先請它草擬自動化管線，列出觸發條件、最小權限、需要的 secret、部署前檢查與回復方式；不要把「每次推送就部署」當成第一次練習的預設行為。確認草稿與環境邊界後，再寫入 YAML 或部署。

Draft a GitHub Actions workflow that runs tests and deploys to staging on every push to {main}. List the least privileges, required secret names, pre-deploy checks, and rollback steps. Output only a draft; do not write a workflow file, deploy, or change an environment.

1. 揪出測試失敗的真正原因

測試亮紅燈時不要自己先猜哪裡壞，把測試名稱直接丟給它，讓 Claude Code 自己跑測試、讀錯誤訊息、回頭查程式碼定位問題，再動手修——一次講完「找原因」加「修好」兩件事。同時是官方「五個開始提示」建議的第 3 個起手式。

the {UserAuth} test is failing, find out why and fix it

2. 調查使用者回報的錯誤

從使用者看到的症狀出發，不是從程式碼出發——把「誰在哪裡看到什麼」原封不動丟進去，讓它自己往回查是哪一層出了問題，而不是你先預設答案再去驗證。

users are seeing {500 errors} on {/api/settings}. investigate and tell me what is going on

3. 修 build 錯誤到根因

重點在「root cause」跟「verify」兩個字——不只是讓錯誤訊息消失，還要求它自己重新跑一次 build 確認真的過了，不是頭痛醫頭、表面上不報錯就收工。

先把錯誤輸出貼進提示詞，再送出這句。

here is a build error. fix the root cause and verify the build succeeds

4. 正式環境事件調查

把「查 log、查最近部署、查設定變更」三件事一次交代清楚，等於把事件排查的標準順序寫進提示詞，讓它照著查而不是東翻西找亂猜，最後只給你一個最可能的原因而不是一堆疑點清單。

{the checkout endpoint started returning 500s an hour ago}. check the logs, recent deploys, and config changes, then tell me the most likely cause

5. 從主控台截圖診斷問題

不用先把畫面內容轉述成文字描述——直接把儀表板截圖交給它讀；第一輪先做唯讀診斷，說明會查看哪些資料與每個建議命令的影響，再由你逐項核准可能改變正式環境的操作。

貼上、拖曳或用 @ 提及你的截圖，然後送出這句。

Here is a screenshot of {the GCP Kubernetes dashboard}. Diagnose why {this pod} may be failing. First explain which data you would inspect and what each proposed command could affect. Do not restart, delete, scale, deploy, change configuration, or install anything until I approve each step.

6. 用自然語言查詢 log

不用自己先寫查詢語法——用白話描述你想看什麼，讓它自己組查詢、執行、再回頭幫你挑出異常，把「寫查詢」跟「解讀結果」都交出去。

需要：你的資料倉儲或 log 儲存已加入 claude.ai connector 或 MCP server。

show me all {failed logins} for {the auth service} over {the past 24 hours}. write the query, run it, and tell me what stands out

7. 分析資料檔案

這則示範「指定回答格式」的威力——不是要一段文字摘要，而是直接生成一個帶圖表、能在瀏覽器打開的 HTML 頁面，讀資料的結果直接變成看得懂的成品。

把檔案拖進提示詞，或用 @ 提及取代下面路徑。

read {@reports/q1-signups.csv}, summarize the key patterns, and write the results to {an HTML page with charts, then open it in my browser}

8. 從廣告成效資料生成新版本

先讓它從資料裡自己判斷「哪些表現差」，再依可量測的字數上限批次生成替代方案——不是憑感覺想文案，是先看數字再動筆。

把檔案拖進提示詞，或用 @ 提及取代下面路徑。

read {@ads-performance.csv}, find the underperforming {headlines}, and generate {20} new variations that stay under {90} characters

9. 把重複任務變成 skill

把一連串你每次都手動做的步驟固定下來，變成一個團隊裡任何人都能打 /指令 重複執行的 skill，不用每次重新描述一遍流程。

create a {/ship} skill for this project that {runs the linter and tests, then drafts a commit message}

10. 設定自動觸發的 hook

把「每次改完檔案就該做的事」交給 hook 自動觸發，不用靠自己或團隊成員記得手動跑一次。

write a hook that {runs prettier} after every {edit to a .ts or .tsx file}

11. 接上 MCP 工具

外部服務能提供即時資料，但先確認 MCP 的來源、版本、讀取資料範圍、所需權限與設定檔位置。未經核准，不要安裝、登入、讀取錯誤資料或輸出任何憑證。

List the source, version, data scope, required permissions, and configuration location for the {Sentry} MCP server. Do not install it, sign in, read error reports, or expose credentials until I approve.

12. 把這次工作階段學到的記下來

這是 Operate 階段收尾的關鍵動作——把除錯、處理事件、分析資料當下摸出來的專案慣例，寫進 CLAUDE.md，讓下一次對話從這個基礎開始，不必每次重新讓 Claude Code 重新摸索一遍。少了這一步，這階段每次查出來的教訓都只留在當次對話裡，下次同樣的坑還是會再踩一次。

summarize what we did this session and suggest what to add to CLAUDE.md