我每天都在用的十個專家級Prompt,提升開發(fā)與寫作效率
我剛開始用 ChatGPT 時,覺得自己已經(jīng)摸透了門道。我是個軟件工程師,寫代碼是本行,寫作是我的熱愛,搞幾個 AI 提示能有多難?我丟進去一個問題或任務,得到一個快速答案,然后拍拍自己肩膀,覺得自己挺聰明。有一陣子,這樣感覺還行。但新鮮感一過,我發(fā)現(xiàn)個問題:AI 的回答太平淡了。太“安全”。太“默認”。它們給出的信息是對的,提綱也還行,但就是缺了我想要的那股勁兒。
我一直在想:“為什么 ChatGPT 給不了我真正想要的東西?”我改措辭,加點花哨的詞匯,甚至試過寫超級復雜的指令,想讓自己聽起來“聰明”。劇透一下:這不是解決辦法。實際上,在試了上百個失敗的提示(想想看,1200 多次失誤?。┖螅医K于明白了:AI 完全按照我說的在做,問題出在我身上。我的提問方式不對。
我一開始并不是什么“提示工程師”。我是個 AI 和 C++ 開發(fā)者。我測試 API,調(diào)試死鎖,和可空引用類型死磕。
但慢慢地,我發(fā)現(xiàn)自己和 AI 工具——ChatGPT、Claude、甚至 Copilot——的溝通方式,能讓我省下好幾個小時,也可能浪費我一天時間。
最初只是隨手一句“幫我寫這個”,后來變成了我工作流程的重要部分。尤其是當我發(fā)現(xiàn)自己能更快得到更好的結(jié)果、更聰明的代碼時。不是因為模型變聰明了,而是因為我提問的方式更好了。
在這篇文章里,我要分享我跨項目反復使用的10個精準提示模板。有些是挫折中誕生的。有些來自深夜刷 Stack Overflow 的靈感。它們都是真實的。更重要的是:它們真的好用。
讓我們開始吧!
1. 像對新人一樣解釋這段代碼
我會在審查別人代碼或幾個月后重看自己代碼時用這個。有時候,你就是需要一個清楚、像聊天一樣的解釋——就像隊友在白板上給你講明白。
提示:“你是一個資深 C++ 開發(fā)者。像指導初級開發(fā)者一樣,逐段解釋下面這個方法。用簡單英語,假設對方有基礎 C++ 知識。最后總結(jié)這個函數(shù)的作用?!?/span>
// 在這里粘貼你的方法為什么好用:
? 你給 AI 定了個角色:一個資深開發(fā)者在解釋東西。
? 你明確了受眾:不是完全小白,但也不是專家。
? 輸出通常很有人味兒,不像機器人——還能直接拿來寫文檔或注釋。我不僅用這個來理解代碼,還用它來教別人代碼在干嘛,不用自己手寫。
2. 生成測試用例(救我一周的那個)
我來告訴你這個提示是怎么來的。
我們當時在準備一個版本發(fā)布。我剛寫完一個價格計算模塊,業(yè)務邏輯復雜,邊緣情況一大堆。猜猜我還沒寫啥?單元測試。
那是周五,我的腦子已經(jīng)成漿糊了。
我把主方法丟進 GPT-4,用了這個提示:
提示:“我用 xUnit 測試這個 C++ 方法。生成 5-6 個測試方法,覆蓋正常情況和邊緣情況。測試名稱要清晰有意義。加注釋說明每個測試在驗證什么?!?/span>
// 在這里粘貼你的方法它給了我四個很棒的測試用例,還提醒我漏了個情況:當 customerLoyaltyYears 是負數(shù)時會怎樣?
為什么好用:
? 你指明了測試框架,這很重要。
? 你說了要測試啥:正常路徑 + 邊緣情況。
? 你要求加注釋,把測試變成了學習材料。這個提示那天至少幫我省了 90 分鐘?,F(xiàn)在它是我編碼流程的一部分。
3. 清理這段丑代碼
有時候你寫完一個方法,立馬覺得自己寫得有點惡心。
代碼能跑,但就是丑。臃腫。重復??赡苓€摻雜了太多職責。
這時候我會把 AI 變成我的重構(gòu)小伙伴:
提示:“重構(gòu)這個 C++ 方法,讓它更易讀易維護。如有需要,拆成小函數(shù)。改進變量名。保持邏輯不變。重構(gòu)后,解釋改了什么,為什么更好。”
// 在這里粘貼你的丑代碼為什么好用:
? 你不只是要新代碼,你要的是改進。
? “解釋改了什么”讓你真正學到東西,而不是只復制粘貼。
? 結(jié)果幾乎總是更干凈,更貼近 SOLID 原則。我用這個重構(gòu)過從 API 控制器到批處理器的各種代碼。它不會讓代碼完美,但能幫你搞定 80%。
4. 在我提交前審查這段代碼
不是每次都有團隊幫你 review PR。但這不意味著你就該提交沒審查過的代碼。
當我想得到關(guān)于結(jié)構(gòu)、命名、性能的反饋,或者只是想確認下沒問題,我會用:
提示:“扮演一個資深開發(fā)者,審查這段代碼。給出關(guān)于正確性、效率、命名、可讀性、最佳實踐的 bullet-point 反饋。如果有潛在 bug 或可簡化的地方,指出?!?/span>
為什么好用:
? 明確角色:資深開發(fā)者在做代碼審查。
? 明確類別:不只是“能跑嗎?”,而是“寫得好嗎?”
? 輸出通常很快、直白、實用。這個提示幫我抓到過:
? 一個可能為空的變量(沒檢查)
? 一個本可以用 LINQ 的循環(huán)
? 一個我太累沒注意到的爛方法名每次提交前都用這個。比等隊友快,而且?guī)缀蹩偸菍Φ摹?/span>
5. 從代碼注釋寫文檔
我們都寫過這種簡短丑注釋:
// 獲取所有有活躍訂閱的用戶但當我需要給端點或函數(shù)寫正式文檔時,我會用:
提示:“把這個注釋變成完整文檔。包括用途、參數(shù)、返回值和一個使用示例。假設受眾是項目新人開發(fā)者。”
// 獲取所有有活躍訂閱的用戶
public List<User> GetActiveUsers() { … }為什么好用:
? 它把你的簡短注釋擴展成可維護的文檔。
? 你會得到 XML 風格的摘要或 markdown 格式的內(nèi)容。
? 如果你提到“使用示例”,它還會加個代碼示例。我常結(jié)合提示 #1,用真實代碼寫文檔,尤其是在交接或新人培訓時。
6. 幫我總結(jié)這個文件
大文件看著就累。尤其當你只是想快速改點東西。
與其花 20 分鐘掃代碼,我會用:
提示:“總結(jié)這個 C++ 文件的作用。列出每個類和方法,附上簡短用途描述。控制在 150 字以內(nèi)。”
// 在這里粘貼文件或大段代碼為什么好用:
? 特別適合新人上手(尤其在老舊代碼庫上)。
? 幫我快速搞清楚“這個文件到底干嘛的?”再去改。
? 簡潔到可以直接拷進 README 或 wiki。你可以對每個服務層文件跑這個,輕松建內(nèi)部文檔,不用全手寫。
7. 幫我修這個錯誤
你可以去 Google 搜那個錯誤堆棧?;蛘邅G給一個讀過千萬個堆棧的 AI。
提示:“我遇到這個 C++ 錯誤。解釋它是什么意思,常見原因是什么?再建議 1-2 個修復方法?!?/span>
錯誤:對象引用未設置為對象的實例
// 在這里粘貼相關(guān)代碼為什么好用:
? 你不只得到修復,還得到原因分析。
? 通常會給多種修復方案:保護性條件、空值傳播、日志建議。
? 我在生產(chǎn)環(huán)境緊急修 bug 時用這個,快速清晰。
8. 頭腦風暴一些不爛的博客標題
我寫過夠多 Medium 文章,知道標題有多重要。
如果文章寫好了但標題感覺平淡,我會用:
提示:“我在 Medium 上寫一篇關(guān)于 C++ async/await 的文章。建議 5 個好標題——2 個簡潔有力的,1 個搞笑的,1 個列表式的,1 個激發(fā)好奇心的?!?/span>
為什么好用:
? 強制多樣性:不同類型標題,而不是五個無聊的。
? 激發(fā)好奇心的標題常會啟發(fā)我自己的想法。
? 搞笑那個?即便不用,也讓編輯過程更有趣。用這個,多測幾個,挑一個你想點的。
9. 幫我規(guī)劃這篇文章的結(jié)構(gòu)
有時候,你有個點子——但結(jié)構(gòu)還沒成型。
這個提示幫我從一個話題變成真正的提綱:
提示:“我想寫一篇標題為‘為什么 C++ 開發(fā)者該關(guān)心依賴注入’的博客。給我一個提綱:引言,3 個主要部分(帶子項),簡短結(jié)論。語氣要清晰有幫助,不帶推銷味?!?/span>
為什么好用:
? 你定了話題、標題、語氣和結(jié)構(gòu)。
? 得到的是一個可用的框架,我能直接開始填充。
? 通常還包括過渡和建議的行動號召。這個提示救我于無數(shù)次對著空白 Google Docs 發(fā)呆的時刻。
10. 讓這段話聽起來更有人味兒
最后但同樣重要——潤色。
有時候,我寫了個不錯的段落。內(nèi)容清楚,技術(shù)上沒問題。但就是……有點僵硬。
我會用這個:
提示:“把這段話改得更自然、有人味兒。用縮寫,變化句式長度。保持專業(yè),但別那么機器人。不增減信息,只改語氣?!?/span>
總之,使用 async 和 await 通過減少阻塞操作來提高代碼效率和可讀性。為什么好用:
? 增加溫暖、節(jié)奏和流暢感。
? 保留你的原意,只是換上更好的表達。
? 特別適合引言、結(jié)論或摘要。這通常是我按“發(fā)布”前的最后一步。
你不需要做提示工程師也能從 AI 得到更好的答案。你只需要更好的提示。

這十個提示是我日常工作的主力——在真實開發(fā)、真實寫作、真實截止日期里。
它們省時間,提升質(zhì)量。最重要的是,它們讓我思考更快。
從一個開始,調(diào)整它,讓它變成你的。
當你發(fā)現(xiàn)某個提示給出的結(jié)果比你預期還好時?
那是你不再只是用 AI——而是開始和它協(xié)作了。



































