我剛開始用 ChatGPT 時，覺得自己已經摸透了門道。我是個軟件工程師，寫代碼是本行，寫作是我的熱愛，搞幾個 AI 提示能有多難？我丟進去一個問題或任務，得到一個快速答案，然后拍拍自己肩膀，覺得自己挺聰明。有一陣子，這樣感覺還行。但新鮮感一過，我發現個問題：AI 的回答太平淡了。太“安全”。太“默認”。它們給出的信息是對的，提綱也還行，但就是缺了我想要的那股勁兒。

我一直在想：“為什么 ChatGPT 給不了我真正想要的東西？”我改措辭，加點花哨的詞匯，甚至試過寫超級復雜的指令，想讓自己聽起來“聰明”。劇透一下：這不是解決辦法。實際上，在試了上百個失敗的提示（想想看，1200 多次失誤！）后，我終于明白了：AI 完全按照我說的在做，問題出在我身上。我的提問方式不對。

我一開始并不是什么“提示工程師”。我是個 AI 和 C++ 開發者。我測試 API，調試死鎖，和可空引用類型死磕。

但慢慢地，我發現自己和 AI 工具——ChatGPT、Claude、甚至 Copilot——的溝通方式，能讓我省下好幾個小時，也可能浪費我一天時間。

最初只是隨手一句“幫我寫這個”，后來變成了我工作流程的重要部分。尤其是當我發現自己能更快得到更好的結果、更聰明的代碼時。不是因為模型變聰明了，而是因為我提問的方式更好了。

在這篇文章里，我要分享我跨項目反復使用的10個精準提示模板。有些是挫折中誕生的。有些來自深夜刷 Stack Overflow 的靈感。它們都是真實的。更重要的是：它們真的好用。

讓我們開始吧！

1. 像對新人一樣解釋這段代碼

我會在審查別人代碼或幾個月后重看自己代碼時用這個。有時候，你就是需要一個清楚、像聊天一樣的解釋——就像隊友在白板上給你講明白。

提示：“你是一個資深 C++ 開發者。像指導初級開發者一樣，逐段解釋下面這個方法。用簡單英語，假設對方有基礎 C++ 知識。最后總結這個函數的作用?！?/span>

// 在這里粘貼你的方法

為什么好用：

? 你給 AI 定了個角色：一個資深開發者在解釋東西。

? 你明確了受眾：不是完全小白，但也不是專家。

? 輸出通常很有人味兒，不像機器人——還能直接拿來寫文檔或注釋。我不僅用這個來理解代碼，還用它來教別人代碼在干嘛，不用自己手寫。

2. 生成測試用例（救我一周的那個）

我來告訴你這個提示是怎么來的。

我們當時在準備一個版本發布。我剛寫完一個價格計算模塊，業務邏輯復雜，邊緣情況一大堆。猜猜我還沒寫啥？單元測試。

那是周五，我的腦子已經成漿糊了。

我把主方法丟進 GPT-4，用了這個提示：

提示：“我用 xUnit 測試這個 C++ 方法。生成 5-6 個測試方法，覆蓋正常情況和邊緣情況。測試名稱要清晰有意義。加注釋說明每個測試在驗證什么。”

// 在這里粘貼你的方法

它給了我四個很棒的測試用例，還提醒我漏了個情況：當 customerLoyaltyYears 是負數時會怎樣？

為什么好用：

? 你指明了測試框架，這很重要。

? 你說了要測試啥：正常路徑 + 邊緣情況。

? 你要求加注釋，把測試變成了學習材料。這個提示那天至少幫我省了 90 分鐘?，F在它是我編碼流程的一部分。

3. 清理這段丑代碼

有時候你寫完一個方法，立馬覺得自己寫得有點惡心。

代碼能跑，但就是丑。臃腫。重復?？赡苓€摻雜了太多職責。

這時候我會把 AI 變成我的重構小伙伴：

提示：“重構這個 C++ 方法，讓它更易讀易維護。如有需要，拆成小函數。改進變量名。保持邏輯不變。重構后，解釋改了什么，為什么更好。”

// 在這里粘貼你的丑代碼

為什么好用：

? 你不只是要新代碼，你要的是改進。

? “解釋改了什么”讓你真正學到東西，而不是只復制粘貼。

? 結果幾乎總是更干凈，更貼近 SOLID 原則。我用這個重構過從 API 控制器到批處理器的各種代碼。它不會讓代碼完美，但能幫你搞定 80%。

4. 在我提交前審查這段代碼

不是每次都有團隊幫你 review PR。但這不意味著你就該提交沒審查過的代碼。

當我想得到關于結構、命名、性能的反饋，或者只是想確認下沒問題，我會用：

提示：“扮演一個資深開發者，審查這段代碼。給出關于正確性、效率、命名、可讀性、最佳實踐的 bullet-point 反饋。如果有潛在 bug 或可簡化的地方，指出。”

為什么好用：

? 明確角色：資深開發者在做代碼審查。

? 明確類別：不只是“能跑嗎？”，而是“寫得好嗎？”

? 輸出通常很快、直白、實用。這個提示幫我抓到過：

? 一個可能為空的變量（沒檢查）

? 一個本可以用 LINQ 的循環

? 一個我太累沒注意到的爛方法名每次提交前都用這個。比等隊友快，而且幾乎總是對的。

5. 從代碼注釋寫文檔

我們都寫過這種簡短丑注釋：

// 獲取所有有活躍訂閱的用戶

但當我需要給端點或函數寫正式文檔時，我會用：

提示：“把這個注釋變成完整文檔。包括用途、參數、返回值和一個使用示例。假設受眾是項目新人開發者。”

// 獲取所有有活躍訂閱的用戶
public List<User> GetActiveUsers() { … }

為什么好用：

? 它把你的簡短注釋擴展成可維護的文檔。

? 你會得到 XML 風格的摘要或 markdown 格式的內容。

? 如果你提到“使用示例”，它還會加個代碼示例。我常結合提示 #1，用真實代碼寫文檔，尤其是在交接或新人培訓時。

6. 幫我總結這個文件

大文件看著就累。尤其當你只是想快速改點東西。

與其花 20 分鐘掃代碼，我會用：

提示：“總結這個 C++ 文件的作用。列出每個類和方法，附上簡短用途描述?？刂圃?150 字以內?！?/span>

// 在這里粘貼文件或大段代碼

為什么好用：

? 特別適合新人上手（尤其在老舊代碼庫上）。

? 幫我快速搞清楚“這個文件到底干嘛的？”再去改。

? 簡潔到可以直接拷進 README 或 wiki。你可以對每個服務層文件跑這個，輕松建內部文檔，不用全手寫。

7. 幫我修這個錯誤

你可以去 Google 搜那個錯誤堆棧。或者丟給一個讀過千萬個堆棧的 AI。

提示：“我遇到這個 C++ 錯誤。解釋它是什么意思，常見原因是什么？再建議 1-2 個修復方法。”

錯誤：對象引用未設置為對象的實例
// 在這里粘貼相關代碼

為什么好用：

? 你不只得到修復，還得到原因分析。

? 通常會給多種修復方案：保護性條件、空值傳播、日志建議。

? 我在生產環境緊急修 bug 時用這個，快速清晰。

8. 頭腦風暴一些不爛的博客標題

我寫過夠多 Medium 文章，知道標題有多重要。

如果文章寫好了但標題感覺平淡，我會用：

提示：“我在 Medium 上寫一篇關于 C++ async/await 的文章。建議 5 個好標題——2 個簡潔有力的，1 個搞笑的，1 個列表式的，1 個激發好奇心的。”

為什么好用：

? 強制多樣性：不同類型標題，而不是五個無聊的。

? 激發好奇心的標題常會啟發我自己的想法。

? 搞笑那個？即便不用，也讓編輯過程更有趣。用這個，多測幾個，挑一個你想點的。

9. 幫我規劃這篇文章的結構

有時候，你有個點子——但結構還沒成型。

這個提示幫我從一個話題變成真正的提綱：

提示：“我想寫一篇標題為‘為什么 C++ 開發者該關心依賴注入’的博客。給我一個提綱：引言，3 個主要部分（帶子項），簡短結論。語氣要清晰有幫助，不帶推銷味?！?/span>

為什么好用：

? 你定了話題、標題、語氣和結構。

? 得到的是一個可用的框架，我能直接開始填充。

? 通常還包括過渡和建議的行動號召。這個提示救我于無數次對著空白 Google Docs 發呆的時刻。

10. 讓這段話聽起來更有人味兒

最后但同樣重要——潤色。

有時候，我寫了個不錯的段落。內容清楚，技術上沒問題。但就是……有點僵硬。

我會用這個：

提示：“把這段話改得更自然、有人味兒。用縮寫，變化句式長度。保持專業，但別那么機器人。不增減信息，只改語氣?！?/span>

總之，使用 async 和 await 通過減少阻塞操作來提高代碼效率和可讀性。

為什么好用：

? 增加溫暖、節奏和流暢感。

? 保留你的原意，只是換上更好的表達。

? 特別適合引言、結論或摘要。這通常是我按“發布”前的最后一步。

你不需要做提示工程師也能從 AI 得到更好的答案。你只需要更好的提示。

這十個提示是我日常工作的主力——在真實開發、真實寫作、真實截止日期里。

它們省時間，提升質量。最重要的是，它們讓我思考更快。

從一個開始，調整它，讓它變成你的。

當你發現某個提示給出的結果比你預期還好時？

那是你不再只是用 AI——而是開始和它協作了。