最好的 ChatGPT 和 Claude 開發者 prompts 會提供給模型三樣東西：實際程式碼、一項明確工作，以及定義好的輸出格式。這就是實用的程式設計 GPT 或 AI 軟體工程師工作階段背後的全部訣竅。「審查我的程式碼」只會得到客氣的摘要。「審查這份差異中的錯誤和安全性問題，依嚴重性列出發現並附上行號，不要重寫檔案」則會得到你能夠採取行動的結果。以下是提供給開發者的 30 個 prompts，分成六組：程式碼審查與品質、測試、重構與效能、文件與 PR 描述、前端，以及後端與 DevOps。這些 prompts 不依賴特定語言，使用 [language] 佔位符；在具體細節重要時，另提供幾個 Python 和 TypeScript 版本。
一次設定程式碼審查
Yuri - 程式碼審查 AI Skill
Yuri 會載入你的審查標準、嚴重性分級和技術堆疊一次，讓每次審查都遵循相同規則，而不是每次都重新撰寫 prompt。
$29
取得 Skill →
如何使用這些 prompts
複製一個 prompt，替換 [brackets]，然後緊接著貼上程式碼或差異。兩個習慣會帶來很大的不同。首先，務必貼上實際產物：函式、堆疊追蹤、差異、結構描述。對程式碼的描述並不是程式碼本身。其次，說明你希望取得的結果：差異、表格、編號清單或檔案。模型預設會提供散文式文字；但你很少真正需要散文式文字。
如果你使用 Claude Code，這些 prompts 仍可直接使用，但其中許多更適合儲存為斜線命令或 Skill，這樣就不用反覆重新輸入。下方有一個簡短章節，另外我們的Claude Code skills指南中也有較長的說明。
程式碼審查與品質（prompts 1 至 5）
Prompt 在差異上執行的效果最好，而不是完整檔案。要求依嚴重性分組列出發現，這樣時間不足時可以略過風格方面的備註。
Prompt 1：依嚴重性進行資深審查
以資深工程師的角度審查這份 [language] 差異。將發現分為：錯誤、安全性、效能、可維護性、程式碼風格。針對每項發現，提供行號參照、用一句話說明問題，以及修正方式。不要重寫整個檔案。如果某個分類沒有發現，請註明。差異：[paste diff]
Prompt 2：僅進行安全性檢查
僅檢查這段 [language] 程式碼的安全性問題：注入、不安全的反序列化、缺少輸入驗證、程式碼中包含密密、未安全的預設設定，以及相依性風險。針對每項發現，用一行說明風險、可能的利用方式，以及更安全的版本。程式碼：[paste code]
Prompt 3：向審查者解釋變更
我是這份差異的作者。撰寫我應附上的審查說明，讓審查者能快速理解：變更了什麼、為什麼變更、應先查看什麼、哪些內容刻意不在範圍內，以及我如何測試。限制在 150 字以內。差異：[貼上差異]
Prompt 4：找出潛在錯誤
這段 [language] 程式碼在正常路徑下可運作，但我懷疑邊界案例中存在錯誤。使用以下輸入逐一檢視：空輸入、null 或 None、非常大的輸入、並行呼叫，以及失敗的相依項。針對每一項，說明會發生什麼，以及這是否正確。程式碼：[貼上程式碼]
Prompt 5：Python 型別與 lint 檢視
檢視這個 Python 模組的型別標註與正確性。新增或修正型別提示，標示嚴格模式下的 mypy 會拒絕的項目，指出可變的預設引數、空白 except，以及未關閉的資源。回傳修正後的模組和變更內容的條列清單。程式碼：[貼上程式碼]
測試（prompts 6 至 10）
要求模型在撰寫測試前先列出案例。從五行的清單中找出遺漏的案例，比從 200 行測試程式碼中找出容易得多。
Prompt 6：先列出案例的單元測試
使用 [測試框架] 為這個 [language] 函式撰寫單元測試。在程式碼之前，列出你將涵蓋的每個案例：正常路徑、邊界、錯誤路徑和無效輸入。然後撰寫測試。使用讀起來像句子的描述性測試名稱。函式：[貼上程式碼]
Prompt 7：根據錯誤撰寫迴歸測試
這裡有一份錯誤報告和修正內容。使用 [測試框架] 撰寫迴歸測試，要求舊版程式碼會失敗，而新版程式碼會通過。以錯誤命名測試。錯誤：[描述錯誤]。修正差異：[貼上差異]
Prompt 8：高風險變更前的測試
我準備在 [你要變更的內容] 中的 [檔案或模組] 進行變更。在著手前，列出我應該準備好的測試，並依照每項測試可能捕捉到錯誤的機率排序。根據這個測試檔案標示哪些測試已存在：[貼上測試檔案]
Prompt 9：TypeScript 整合測試
使用 TypeScript 和 [Vitest 或 Jest] 為這個 API 處理常式撰寫整合測試。只模擬外部邊界（[資料庫、HTTP 用戶端、佇列]），不要模擬內部模組。涵蓋成功呼叫、驗證失敗和上游逾時。處理常式：[貼上程式碼]
Prompt 10：測試檢視
檢視這些測試。告訴我哪些斷言較弱（斷言真值、只使用快照，或測試模擬物件而非程式碼），哪些案例遺漏，以及哪些測試重複。建議三個最有價值的新增測試。測試：[貼上測試]
重構與效能（prompts 11 至 15）
重構 prompts 需要一項硬性限制：行為不得改變。請明確說明這點，並要求將變更列成清單，讓你可以一次審查一項。
提示詞 11：維持行為的重構
在不改變行為的情況下，重構這段 [language] 程式碼以提升可讀性。維持公開介面完全相同。提供程式碼前，先以一行列出每項變更及其原因。標記任何看起來像錯誤的地方，但不要默默修正，請另外註明。程式碼：[paste code]
提示詞 12：拆分過長的函式
這個函式太長了。將它拆分成較小且名稱清楚的函式，每個函式只做一件事。先以大綱形式展示新的結構（函式名稱和一行用途說明），然後提供程式碼。除非新的抽象化至少會被使用兩次，否則不要引入。程式碼：[paste code]
提示詞 13：找出效能問題
這段 [language] 程式碼在 [size of input] 下執行緩慢。找出可能的瓶頸、估算其複雜度，並提出修正方案。說明修正方案的取捨（記憶體、可讀性、正確性風險）。不要進行微最佳化；找出最關鍵的問題。程式碼：[paste code]。若有設定檔分析輸出：[paste]
提示詞 14：Python 效能重寫
為提升效能，重寫這個 Python 函式。優先使用內建功能、推導式、生成器和標準函式庫，而不是手寫迴圈。維持相同的簽名和回傳型別。展示修改前後的版本，並說明如何使用 timeit 進行基準測試。程式碼：[paste code]
提示詞 15：移除重複
以下有兩段或更多看起來相似的程式碼。告訴我它們是否應共用一個實作，或維持分開（並說明原因）。如果應共用，請撰寫該實作，並展示各個呼叫端需要如何變更。程式碼 A：[paste]。程式碼 B：[paste]
文件與提取要求描述（prompts 16 至 20）
文件工作最常被跳過。這些 prompts 只需十秒，就能產生新團隊成員實際可以使用的內容。
提示詞 16：提取要求描述
為這個差異撰寫提取要求描述。區段：摘要（兩句話）、變更內容（條列）、原因、測試方式（步驟）、風險與回復。使用簡單語言，不要採用行銷語氣。不要捏造我未提供的背景。差異：[paste diff]。工單：[ticket link or summary]
提示詞 17：文件字串與註解
在這個 [language] 檔案中，依照 [Google、NumPy、JSDoc 或你的標準] 風格，為每個公開函式和類別新增文件字串。請記錄參數、回傳值、引發的錯誤，並各提供一個範例。不要新增只是重述程式碼的註解。檔案：[paste code]
提示詞 18：模組的 README
請為這個模組撰寫 README 章節：功能、使用時機、最小可運作範例、以表格呈現的設定選項，以及常見錯誤。請控制在 300 字以內。程式碼：[paste code or public API]
Prompt 19：API endpoint 文件
請為這個 endpoint 產生參考文件：方法、路徑、驗證需求、具有型別且標明是否為必要的請求參數、請求範例、成功回應範例，以及每個錯誤回應與其原因。來源：[paste route or controller]
Prompt 20：架構決策紀錄
請針對這項決策撰寫 ADR。章節包括：背景、決策、考量過的替代方案（以及拒絕各方案的原因）、後果。最多一頁。決策：[describe]。替代方案：[list]。限制：[list]
前端（prompts 21 到 25）
Frontend prompts 應說明 framework 和渲染模型。只寫「React」並不足夠，因為在 client component 與 server component 之間，答案可能有所不同。
Prompt 21：元件檢視
請檢視這個 [React, Vue, Svelte] 元件，確認是否有：不必要的重新渲染、應由衍生值取代的狀態、遺漏的 keys、應改為事件處理常式的 effects，以及洩漏實作細節的 props。針對每項問題提供修正方式。元件：[paste code]
Prompt 22：無障礙檢查
請稽核這段標記和元件程式碼的無障礙性：語意元素、標籤、焦點順序、鍵盤操作、色彩對比 token，以及 ARIA 誤用。列出每個問題未符合的 WCAG 準則，並提供修正後的程式碼。程式碼：[paste code]
Prompt 23：API 回應的 TypeScript 型別
以下是來自 [endpoint] 的 JSON 回應範例。請為它撰寫 TypeScript 型別。當某個欄位會切換資料形狀時，請使用可辨識聯集，正確標示選填欄位，並使用 [Zod or your library] 新增與型別相符的執行階段驗證器。JSON：[paste sample]
Prompt 24：CSS 版面配置除錯
這個版面在 [viewport or condition] 時會跑版。以下是 HTML 和 CSS。請用淺白的方式說明造成問題的原因，然後提供修正問題所需的最小 CSS 變更。優先使用現代版面配置（grid、flex、container queries），不要使用權宜技巧。程式碼：[paste code]
Prompt 25：狀態管理決策
我需要在一個 [size] 的 [framework] 應用程式中管理 [describe state]。比較將其保留在本地、提升至 context，以及使用 [store library] 的做法。針對此案例說明理由並推薦其中一種，然後展示推薦做法的基本架構。
後端與 DevOps（prompts 26 到 30）
後端和基礎架構 prompts 若明確說明環境，效果會更好：資料庫、執行環境版本、雲端供應商，以及哪些服務絕不能中斷。
Prompt 26：API 設計審查
審查這個 API 設計的一致性與正確性：資源命名、HTTP 方法與狀態碼、分頁、錯誤格式、寫入的冪等性，以及版本控制。以表格回傳問題、重要性和修正方法。規格或路由：[paste]
Prompt 27：資料庫查詢與結構描述審查
審查這個 [database] 結構描述和這些查詢。標記缺少的索引、N+1 模式、不應為可為 null 的欄位，以及超過 [rows] 後無法擴展的查詢。針對每項結構描述變更提出遷移方案。結構描述：[paste]。查詢：[paste]
Prompt 28：Dockerfile 強化
審查這個 Dockerfile。縮減映像檔大小、固定版本、使用非 root 使用者、分離建置與執行階段，並有效利用層快取。回傳改進後的 Dockerfile，並在每一行變更處加上註解。Dockerfile：[paste]
Prompt 29：CI 管線除錯
這個 [GitHub Actions, GitLab CI, other] 管線間歇性失敗。以下是設定和失敗記錄。找出最可能的原因，告訴我如何確認，並提供修正方法。如果是易 flaky 的測試而不是管線問題，請明確指出。設定：[paste]。記錄：[paste]
Prompt 30：事件事後檢討
根據以下筆記撰寫一份無責任歸咎的事後檢討。章節：摘要、影響、時間軸、根本原因、做得好的地方、做得不好的地方、附負責人的行動項目。保持客觀，只陳述筆記支持的內容，不要過度推測。筆記：[paste incident notes]
這些內容在 Claude Code 中的存放位置
如果你使用 Claude Code，每次審查都重新輸入 Prompt 1 是浪費時間。Claude Code 提供三個儲存指令的位置，而每個位置都適合不同類型的 prompt。
-
CLAUDE.md 用於套用到儲存庫每個工作階段的規則：使用的語言、測試框架、風格指南、「絕不提交密鑰」。內容應簡短、始終啟用，且不接受參數。
-
斜線指令（位於
.claude/commands/ 的檔案）用於你按需觸發的可重複任務：/review、/pr-description、/tests。Prompt 1、6 和 16 很適合作為斜線指令。
-
Skills 用於完整的角色行為：程式碼審查者如何思考、使用哪種嚴重性分級，以及 QA 工程師如何組織測試計畫。Skill 是一個包含工作流程、標準和範例的 .md 檔案，模型會在任務符合時載入它。請參閱 Claude Code skills collection 和我們的 Claude skill examples，了解優質 Skill 的樣子。
經驗法則是：如果只有一行，就放進 CLAUDE.md。如果是你經常執行的一個 prompt，就建立成斜線指令。如果是一個需要判斷力的角色，就建立成 Skill。
將任務轉換成 prompt，再轉換成 Skill
如果你想要以套組形式取得 prompts
以上內容都可以免費複製。如果你想要一套更大型、經過整理，並且針對不同語言和角色提供變體的內容，有兩個選項：
Tech & Dev Prompt Library（$21）：結構化的開發者 prompts 資料庫，涵蓋審查、測試、除錯、文件和架構，依任務分類，讓你能在幾秒內找到適合的 prompt。屬於更完整的 ChatGPT prompts 目錄的一部分。
Coding Agent Bundle - 全部 5 個 AI Coding Agents（$99）：一次購買五種 coding agent Skill，涵蓋審查、建置、測試、後端和基礎架構，適合希望將完整工作流程設定好，而非只配置單一角色的團隊。
所有 Skills 都是一次性購買，會以附有 README 的 .md Skill 檔案形式交付，並可在 Claude（包括 Claude Code）、作為自訂 GPT 的 ChatGPT、作為 Gem 的 Gemini，以及 Copilot 中使用。我們提供 30 天退款保證，無需說明理由。
常見問題
這些 prompts 在 ChatGPT 和 Claude 中的運作方式相同嗎？
可以。這裡的每個 prompt 都是純文字，不含任何特定模型的語法。Claude 通常很適合處理長篇貼上的檔案和多步驟重構，ChatGPT 則擅長快速處理獨立函式和小型測試。文字內容不會改變；改變的是您一次能貼上的內容量。
我應該貼上整個檔案，還是只貼上函式？
貼上包含完整問題的最小單位。遇到錯誤時，應貼上函式、呼叫位置和堆疊追蹤；進行審查時，應貼上差異內容；進行重構時，則應貼上模組。若未附上問題就貼上整個儲存庫，只會得到泛泛的回饋。
prompt 和 Skill 有什麼差別？
prompt 是您每次輸入的一次性指令。Skill 是一個 .md 檔案，其中包含您的角色、標準和工作流程，模型會載入一次，因此每個回答都會遵循您的慣例。KissMySkills 的 Skills 可在 Claude 和 Claude Code 中使用，也可作為 ChatGPT 自訂 GPT、Gemini Gem 或 Copilot 使用，並提供 30 天退款保證。
這些只有 Python prompts 嗎？
不行。每個 prompt 都使用 [language] 佔位符。部分範例以 Python 或 TypeScript 為例，因為這些是最常見的需求，但您可以替換成 Go、Rust、Java、C# 或任何其他語言，結構仍然適用。
我可以直接在 Claude Code 中放入這些 prompts 嗎？
是。簡短且始終啟用的規則適合放在 CLAUDE.md 中，可重複執行的任務適合放在 .claude/commands 下的斜線指令中，而完整的角色行為則適合放在 Skills 中。上方關於 prompts 在 Claude Code 中應放置位置的章節，會說明三者的差異。
重點
對開發人員來說，好的 prompts 很無聊：真實輸入、單一任務，以及明確說明的輸出。上面的 30 個 prompts 涵蓋日常的審查、測試、重構、文件、前端、後端和 DevOps 工作，而且在 ChatGPT 和 Claude 中的運作方式相同。您可以直接輸入使用，也可以把每天執行的 prompts 移到斜線指令或 Skills 中，這樣就不用反覆重新輸入。
完整工作流程，一次購買
程式碼撰寫 Agent 組合包 - 全部 5 個 AI 程式碼撰寫 Agents
可載入一次您的標準，並在 Claude Code、ChatGPT、Gemini 或 Copilot 的每項任務中套用的程式碼審查、建置、測試、後端和 DevOps Agents。
$99
立即取得 →
瀏覽 KissMySkills 上所有的 Claude Code Skills。
