從混亂到可控：我最受益的 10 個 AI 編程技巧（含提示詞）
整理版優先睇
AI 編程嘅核心唔係令模型更聰明，而係學識將模糊諗法拆做可執行步驟，並將經驗沉澱做可重用知識。
作者熊貓Jay過去一年做咗3個產品（熊貓論文、熊貓工坊、PostMaker），累積約60萬行代碼。佢發現AI寫得快，但方向好易錯，導致反覆返工、Bug連連。呢篇文章係佢從混亂到可控嘅實戰總結，分享10個技巧，核心係：AI編程嘅難點唔係工具，而係我哋嘅思維方式——要學會精確描述、分步推進、建立標準。
文章將技巧分為幾大類：修Bug嘅5個核心方法（最小閉環信息、上下文大法、環境適應、全局驗收標準、Debug模式）；需求同設計層面嘅Plan模式同需求拆解；系統化沉澱經驗（知識卡片、上下文文檔）；同埋UI優化流程同心態調整。每個技巧都附有具體提示詞模板，可直接複用。
最終結論：透過呢啲技巧，可以將混沌變成秩序，將想法落成系統。AI編程教會我哋嘅唔止寫代碼，而係點樣喺不確定性中建立確定性標準。
- 修復Bug嘅關鍵係提供「最小閉環信息」，並用「上下文大法」俾AI理解全局，避免盲目修補。
- 用Plan模式逼AI先設計再編碼，將需求拆解清楚，大幅減少後續返工。
- 將短期定製需求通用化，並將每次費力修復過程沉澱做知識卡片，形成可複用資產。
- 為AI生成結果設定Plan B（如JSON校驗、字數限制補償），應對模型嘅不穩定輸出。
- UI優化從建立設計規範開始，透過「單點擊破」逐步鋪開，並持續沉澱樣板卡片，避免靠感覺改動。
Bug修復：上下文大法模板
用於頑固Bug，提供問題描述、情況、提示信息、已嘗試操作，要求AI分析原因並俾解決辦法。
全局觀：測試用例驅動修復模板
要求AI基於驗收標準/測試用例從全局正確性修復Bug，避免引入新問題，並輸出回歸用例清單。
需求拆解模板（資深產品經理）
將一句需求轉為結構化規格：功能描述、用戶故事、驗收標準、備註，形成開發-測試閉環。
Cursor Rule 模板（Python）
包含角色溝通、文檔即上下文、工作流程（需求理解→實現→測試→接口→數據庫→收尾）、參考規範。可直接修改複用。
從修 Bug 到控 Bug：5 個核心技巧
對非技術背景嘅朋友嚟講，改Bug係AI編程最高頻亦最頭痛嘅事。作者發現，修Bug嘅關鍵唔係俾好多提示詞，而係講清楚最小閉環信息：邊個角色、喺邊度、做咗咩動作、出現咩異常、有咩錯誤信息。呢6點足以覆蓋八成場景。
快速提問法：將Bug嘅「最小閉環信息」講完整，避免一句廢話
遇到頑固Bug時，要用上下文大法，一次過俾曬相關線索：需求變動時間、配置參數、之前嘅嘗試同結果。作者提供咗一個詳細嘅上下文模板，要求AI按格式分析。
請基於以下信息，幫我分析並解決問題。
## 問題描述
- 我做了什麼，實際發生了什麼：xxx
- 正常情況下應該發生什麼：xxx
## 問題情況
- 是否每次都會發生：xxx
- 什麼時候開始出現的：xxx
- 出問題前是否有過改動：xxx
## 提示信息（如果沒有，則不提供）
- 頁面提示 / 報錯日誌內容：xxx
## 已嘗試
- 我已經嘗試過的操作：
- 是否有變化：
## 分析要求
- 用通俗的話說明可能原因
- 給出下一步可以直接嘗試的解決辦法
- 如信息不足，請告訴我需要補充什麼另外，AI都需要適應環境。直接將Bug症狀掟俾新context，成功率高極有限。應該先讓AI理解呢個功能嘅代碼結構、核心流程、設計意圖，等佢「搞清楚呢度做緊咩」，再俾具體異常。作者建議用流程圖或時序圖輔助理解。
修覆復雜Bug時，最易犯嘅錯係拆東牆補西牆。作者建議用全局觀：將完整驗收標準或測試用例俾AI，要求佢從全局正確性修復，同時輸出需要回歸嘅用例清單。
- 1 先複述功能嘅正確行為（根據驗收/用例）
- 2 指出當前Bug違反邊幾條用例（列3-5條）
- 3 俾出最小改動嘅修復方案（改邊啲文件/函數）
- 4 俾出需要回歸嘅用例清單
最後係Debug模式，好似Cursor嘅Debug模式，將排查過程變成一條可控鏈路：復現步驟→記錄日誌→自動分析→改完驗證。記得改完後點「問題已修復」，否則AI會留低多餘日誌。
需求與設計：慢落嚟，先會快
作者發現，直接叫AI寫code好易出錯，所以佢養成一個習慣：先Plan後Coding。用Cursor嘅Plan模式或Claude Code，AI唔會即刻寫code，而係先找問題：邊度有歧義？邊啞假設未講？然後一來一回將模糊諗法變成邊界清楚嘅方案。呢個做法只係將傳統軟件開發嘅「先設計再實現」搬到AI協作，但效果好顯著。
需求拆解係成個流程嘅重中之重，作者話呢件事起碼食咗佢30%精力。佢用提示詞幫自己拆需求，將一句需求轉為結構化規格：功能描述、用戶故事、驗收標準、備註。當中備註/待確認部分特別有價值，AI會列出好多「替你多想一步」嘅提醒，幫你提前避開潛在嘅坑。
## 模塊：[功能模塊名稱]
### 功能描述
- 用項目符號簡明列出核心功能點（以「支持…」、「允許…」等動詞開頭）
### 用戶故事
作為[角色]，我希望[行為]，從而[目的]。
### 驗收標準
- ✅ 正向驗證：成功操作後應出現嘅正確結果
- ❌ 負向驗證：錯誤或異常場景下嘅提示或限制
### 備註 / 待確認
- 列出不確定、需確認或可能變更嘅要點對於複雜方案，作者強烈建議方案推演：真正動手前，叫AI模擬程序執行過程，說明每一步做咩、關鍵參數點影響結果、邊啲步驟可以簡化合併。佢試過幫API切換方案做推演，即時暴露咗幾個中高風險問題，避免咗大量Bug。
系統化沉澱：令每次經驗都可複用
作者喺做「熊貓論文」項目時，發現自己只係被AI流程推住走，冇留下任何可複用嘅嘢。於是佢開始將每次費力修復嘅過程提煉成知識卡片或技術教程，沉澱喺代碼項目同飛書知識庫。下次開新任務時，先叫AI檢索項目中有冇類似問題，只要命中一次就賺咗。
將長期用的上下文沉澱成通用文檔（Cursor Rule、Claude.md）
另外，將長期使用嘅上下文沉澱成通用文檔，例如需求文檔、樣式規範、Cursor Rule等，並喺開發過程中持續更新。作者提供咗一個真實商業項目嘅Cursor Rule模板，包含角色溝通、文檔即上下文、強制工作流程（需求理解→實現→測試→接口→數據庫→收尾）。
# Cursor Rule
## 角色與溝通
你係 Python 工程師，幫助初中生完成項目開發。
- 用通俗語言解釋關鍵概念
- 每次輸出俾多啲：要做咩 + 點解 + 下一步點用
## 文檔即上下文
處理需求前先睇 README.md、docs/development_guide.md、docs/requirements.md 等，並持續更新。
## 工作流程
1) 需求理解：一句話複述 + 列出澄清點
2) 實現：PEP8 + Type Hints + 模塊化
3) 測試：pytest，覆蓋100%
4) 接口與鑑權
5) 數據庫變更（alembic）
6) 收尾：更新文檔 + 影響範圍UI優化方面，作者建議先建立設計規範，用參考圖+提示詞生成初版規範，然後圍繞一個頁面做單點擊破打磨出樣板間，等規範穩定後再鋪開。過程中多用「截圖+局部圈選+期望效果」溝通，讓AI生成多方案對比做選擇題，並將每次得意嘅改動沉澱成樣板卡片。
總結：從混沌到秩序
一年前作者以為AI編程嘅難點係模型唔夠聰明，而家佢明白真正嘅難點係我哋自己：習慣模糊表達、習慣一次到位、習慣憑感覺判斷。呢10個技巧表面上係教「點用AI」，本質上係重新訓練思維方式：將模糊諗法拆做可執行步驟，將一次性經驗沉澱做可複用知識，喺不確定性中建立確定性標準。
舊年呢個時候，一個5千蚊嘅定製項目，我整整搞咗一個幾月。
效率極低，搞到我都想放棄。
過去一年，我做咗 3 個產品：熊貓論文、熊貓工坊，仲有一個喺度內測緊嘅出海項目 PostMaker 。
粗略計一計，代碼量大約 60 萬行。
呢一年我發現：
AI 寫得太快，有時快到你都未反應過嚟，個方向已經錯咗。
於是你就會遇到呢啲崩潰嘅畫面：
• 寫得越快，返工越多 • 修完一個bug，又走出下一個 • 頁面睇落好似用得，但成日覺得係臨時砌出嚟 • ...
呢篇文章，我會將呢一年踩過嘅坑同摸索出嚟嘅打法，逐步分享出嚟。
如果你正在學AI編程，希望你呢 10 個技巧，可以令你少走啲彎路。
一、AI 唔怕複雜 Bug，最怕一句廢話
對於非技術背景嘅朋友，改 bug 可能係 AI 編程過程中最常見又最頭痛嘅事。
如果你修復 bug 嘅提示詞係：
點擊“確認”按鈕報錯了又或者係
頁面卡住了，始終空白咁我建議你一定要好好睇嚇呢一章。
1、快速提問法：
想令 AI 快速幫到手，關鍵就係一件事：將 Bug 嘅「最小閉環信息」講清楚。
XXX角色的用戶在XXX地方操作了XXX幾個動作，出現了XXX異常現象，
導致在XXX位置（代碼控制枱 or 瀏覽器控制枱）產生了XXX錯誤信息。只要將呢 6 點交代清楚，通常可以 cover 到 80% 嘅情況。
所以請對 Bug 保持起碼嘅尊重，唔好偷懶，唔好抱住僥倖心態。
2、上下文大法：
遇到頑固 Bug，淨係靠第一種「最基本信息」通常係唔夠嘅。
因為呢類問題通常牽涉到更複雜嘅執行鏈路，局部現象好難直接推到根因。
呢個時候就要用「上下文大法」：將你諗到嘅線索盡量一次過俾曬。
例如最近需求變動嘅時間點同具體改動、
有冇調整過配置參數、
為咗修呢個 Bug 你之前做過啲咩嘗試、
每次嘗試嘅結果係點。
請基於以下信息，幫我分析並解決問題。
## 問題描述
- 我做了什麼，實際發生了什麼：xxx
- 正常情況下應該發生什麼：xxx
## 問題情況
- 是否每次都會發生：xxx
- 什麼時候開始出現的：xxx
- 出問題前是否有過改動：xxx
## 提示信息（如果沒有，則不提供）
- 頁面提示 / 報錯日誌內容：
xxx
## 已嘗試
- 我已經嘗試過的操作：
- 是否有變化：
## 分析要求
- 用通俗的話說明可能原因
- 給出下一步可以直接嘗試的解決辦法
- 如信息不足，請告訴我需要補充什麼3、AI 都需要適應環境：
上面兩步都搞唔掂，點算？
呢個時候，其實好可能唔係你唔得，而係 AI 仲未進入你嘅世界。
我哋成日做嘅一件事：
就咁將一個 Bug 症狀掉俾 AI，
而且仲有可能喺一個完全唔相關嘅上下文度。
就好似你半夜叫醒啱啱瞓着嘅同事：「呢個功能點解爆咗？你即刻俾答案我。」
成功率，會高至奇？
更穩陣嘅做法係：先等 AI 熟悉環境，再叫佢動手修 Bug。
就算你而家冇完整嘅需求文檔，
都可以先叫 AI 幫你 理解呢個功能嘅代碼結構、核心流程、設計意圖，
等佢「搞清楚呢度做緊咩」，
再將具體嘅異常現象、錯誤信息掉入去。
咁樣，當你同 AI 同時擁有記憶嘅時候，效果會完全唔同。
PS：梳理代碼邏輯時，建議叫 AI 將流程用流程圖、時序圖等你熟嘅可視化方式展示出嚟。
請先幫我理解這個功能在“正常情況下”是怎麼工作的：
- 主要代碼結構
- 核心流程（可以用步驟描述）
- 關鍵狀態或判斷點
請配合使用流程圖或時序圖的方式，加上通俗的語言幫我梳理代碼的完整邏輯。4、全局觀：將完整驗收標準 / 測試用例交俾 AI
修複雜 Bug 時，最常見嘅坑係：呢邊啱啱修好，嗰邊又走出新問題，
甚至愈修愈亂，嚟回打補丁好似陷入死循環。
如果你已經改咗幾輪都係唔穩定，我建議唔好再死盯住某一行報錯嚟搞。
去將呢個功能嘅「完整驗收標準」或「測試用例」揾出嚟，
再補上佢同其他功能嘅關聯邊界，一齊掉俾 AI。
有咗呢啲「全局標準」，AI 先至可以喺修復嘅同時兼顧整體行為，唔會拆東牆補西牆。
喺企業入面呢個做法更容易落實：因為正規嘅研發流程通常都會為需求配套測試用例。
我哋將呢啲用例作為上下文俾 AI，
自測嘅時候唔單止更有方向，仲可以順便叫 AI 幫你生成 回歸腳本，
將修復同驗證做成閉環。
請基於我提供的測試用例、驗收標準、相關需求等信息，從“全局正確性”出發修復 Bug，避免修一個bug，再次引入新的 Bug。
請按這個順序輸出：
1) 先簡潔複述：這個功能的“正確行為”（根據驗收/用例）
2) 指出當前 Bug 違反了哪幾條用例/驗收點（列 3-5 條）
3) 給出最小改動的修復方案（改哪些文件/函數/關鍵邏輯）
4) 給出需要回歸的用例清單（基於我提供的用例/驗收點）
只基於我提供的信息，不要腦補；信息不夠就問我最多 3 個關鍵問題。最終目標是把 Bug 修好並通過這些用例。5、終極大法：Debug 模式
呢個係傳統做法入面，解決 Bug 最高效嘅一條路：用「可重現 + 可觀測」嘅方式，將問題還原出嚟。
但對非技術同學嚟講確實唔友好——你好難知道要捉邊啲信息、點樣睇日誌、點樣將現象還原成線索。
好彩而家唔少 AI 編程工具已經將呢件事「產品化」咗。
例如 Cursor 有 Debug 模式，Claude Code 都支援通過 debug 指令嚟輔助排查。
佢哋嘅價值唔單止係「多輸出啲日誌」，
而是 而係將排查過程變成一條更可控嘅鏈路：
更清楚噉睇到工具嘅運行步驟、關鍵調用、同埋失敗發生喺邊一環。
以 Cursor 為例。
我之前喺優化工具「長文轉小紅書」嘅時候，遇到運行時間過長嘅問題，就直接開 Debug 模式嚟定位。
我先將必要信息補齊，然後跟住佢俾嘅重現步驟手動執行一次，等日誌完整記錄低。
接着佢會自動分析日誌，亦會更容易睇出瓶頸點喺邊度。
嗰次佢俾我嘅建議好明確：有啲步驟其實可以合併，減少重複計算同中間結果嘅來回傳遞。
我採用建議之後，叫 AI 按計劃改完，再行一次同樣嘅重現步驟做驗證。
確認問題解決之後，記得㩒「問題已修復」掣。
咁樣 AI 會自動剷走多餘嘅日誌，保持代碼整潔，否則放到線上可能會出現 路徑揾唔到 嘅問題。
二、用 Plan 模式令 AI 慢落嚟
呢一年嚟，我一直同 AI 一齊寫代碼，亦慢慢形成咗一個固定習慣。
喺將任務交俾 AI 之前，先叫佢進入 Plan 模式。
無論係用 Cursor，定係 Claude Code，呢個模式嘅作用，其實唔單止係「多睇一眼需求」。
佢真正做嘅一件事，係逼住需求先被拆開、被質疑、被補全。
就攞 Cursor 嚟講。
喺 Plan 模式下，佢唔會即刻寫代碼，而係先揾問題。
邊度有歧義？
邊啲前提冇講清楚？
有冇潛藏嘅假設？
佢會直接將呢啲點拋出嚟，等你補充說明。
喺一來一回嘅過程中，原本模糊嘅想法，會慢慢變成一個邊界清楚、可以動手執行嘅方案。
Plan 模式，其實只係將軟件開發入面一個好舊、但一直好用嘅做法，搬咗去 AI 協作度。
先設計，再寫代碼。
花多幾分鐘將計劃講清楚，將執行路徑對齊好，通常可以慳返後面幾個鐘嘅反覆修改。
有時，慢落嚟，反而會快啲～
三、需求拆唔清，之後就會係返工
無論係主業定副業，我一直都係直接面對需求的人。
以前，我要將需求翻譯成技術睇得明嘅嘢。
而家唔同咗。
接到定製商單，或者產品要做新功能，我同樣要先做一件事：拆需求。
講真一句：
呢件事，至少食咗我 30% 嘅精力。
由舊年開始，我慢慢習慣用提示詞嚟幫自己拆需求。
更多是逼自己將問題想清楚。
如果拆解唔到位，後果通常得兩個：
一係反覆返工，
一係為咗趕進度，團隊只能死頂。
下面呢個，係我平時用嚟拆需求嘅提示詞。
講真，一啲簡單嘅產品需求，直接就用佢就夠。
但係如果係全新嘅功能模塊，就唔好照搬，更好嘅做法係：
• 先結合自己嘅經驗 • 將需求拆成幾個具體、獨立嘅使用場景 • 再用提示詞繼續往下拆
咁樣用，價值會更大。
需求唔係一開始就完整嘅，其實係逐漸拆出嚟嘅。
你現在是一個資深產品經理兼需求分析師，請將我提供的需求描述，整理成適合開發人員快速理解和交付的結構化需求說明。
## 輸出格式
嚴格遵循以下模板：
"""
## 模塊：[功能模塊名稱]
### 功能描述
- 用項目符號簡明列出該模塊需要實現的核心功能點（以“支持…”、“允許…”、“點擊…”等動詞開頭）。
- 避免描述背景或實現方式，只關注“系統需要實現的行為”。
### 用戶故事
作為[角色]，我希望[行為]，從而[目的]。
（僅一句話，保持簡短、聚焦價值。）
### 驗收標準
- ✅ 正向驗證：描述成功操作後應出現的正確結果。
- ❌ 負向驗證：描述錯誤或異常場景下應出現的提示或限制。
- 每條標準前加符號（✅/❌），確保測試可讀性。
- 語言保持簡潔明確，避免歧義，用“→”描述操作到結果的邏輯。
### 備註 / 待確認
- 列出尚不確定、需進一步確認或可能變更的要點。
- 可包含設計、接口、性能或交互類問題。
"""
## 內部注意點
"""xxx內部的規範要求或者經常容易遺漏的注意點，減少研發返工xxx"""
## 輸出要求：
1. 嚴格使用 Markdown 格式。
2. 每個模塊形成一個“開發-測試閉環”卡片（功能描述 + 用戶故事 + 驗收標準 + 備註）。
3. 不寫多餘的背景或敍述。
4. 若輸入包含多個模塊，請分模塊分別輸出。
## 需求
"""xxx需求說明，可以是一句話，也可以是詳細的說明xxx"""例如最近，主業入面嘅研發平台要支援 合併列頭 呢類平台級配置。
跟住提示詞模版，我喺 ChatGPT 度俾嘅嘢其實好少。
只得兩句口述嘅需求，再加一啲注意點，
同埋我當時諗到嘅影響範圍。
除此之外，我順手將內部嘅一啲規範要求都一齊掉咗入去。
好似呢類相對唔複雜嘅需求，
AI 生成嘅結果，稍微改嚇就可以直接用。
但真正有價值嘅，其實係：備註 / 待確認。
基於我俾嘅內部注意點，再加埋佢自己嘅理解，
AI 會列出唔少提醒同補充項。
呢啲內容，好多唔係「答案」，而係 幫你諗多一步。
幫你提早見到可能嘅坑，將返工嘅機率降低。
有趣嘅係，
呢種方式，反而會迫我哋自己諗清楚問題。
四、複雜方案，先推演，後落地
唔知你有冇遇過呢種情況。
發現一個嚴重 bug，或者需求突然改動好大，
將問題掉俾 Cursor 之後，佢一下子俾你好幾種方案。
有最推薦嘅，有差啲嘅，
有啲追求見效快，有啲偏向長期維護。
問題係，呢啲方案入面，成日會踩到我哋嘅知識盲區，
或者涉及唔熟嘅領域。
呢個時候就好糾結：到底改唔改？簡邊個？
改嘅話，好容易食好多時間同成本，最後仲未必行得通，甚至要推倒重來。
唔改，問題就一路喺度。
後來我意識到一件事。想提高複雜方案真正落地嘅成功率，
唔可以淨係睇「方案本身」，仲要提早睇佢會點行。
於是我開始叫 AI 幫我做一件事：方案推演。
喺真正動手之前，先確認幾件事：
• 呢個方案，可唔可以解決當前問題 • 落地之後，會唔會影響已有功能 • 邊啲地方最容易出風險
呢啲問題，其實都可以喺 方案推演階段 被提早睇清楚。
請基於上述方案，幫我模擬程序在完成後的整體執行過程。
請你重點說明：
- 程序在正常使用情況下，會按照什麼順序一步步運行
- 每一步主要在做什麼事情，想解決什麼問題
- 關鍵參數在流程中起到什麼作用，會對結果產生哪些影響
在說明過程中，請特別留意：
- 哪些步驟是必不可少的，哪些可能只是為了“看起來完整”
- 如果某些輸入不符合預期，流程可能會受到什麼影響
- 有沒有邏輯可以簡化、合併，或者其實可以不要
輸出要求：
- 使用通俗、直白的語言描述，不要堆技術術語
- 可以用簡單的流程圖或步驟列表，幫助我快速理解整體邏輯
- 在結尾用幾句話總結：這個程序邏輯是否清晰、是否有調整空間之前遇到過一個好具體嘅案例。
為咗令 API 嘅調用過程更加穩定，我加咗一層能力：喺唔同 API 供應商之間做智能切換。
但問題好快就出現咗。
現有系統入面，唔單止有唔同嘅模型類型，仲覆蓋咗多種業務場景。
• 語言模型 • 文生圖 • 視覺模型 • 文生視頻模型
但當我將呢套方案用喺文生圖場景嘅時候，我先按之前嘅提示詞行咗一次測試。
結果好直接，佢瞬間幫我暴露咗唔少 中高風險問題。
呢啲點，如果當時我自己冇諗清楚，就直接叫 AI 去實現，
之後幾乎一定會出現一堆 Bug。
五、任何用 AI 生成嘅結果，都應該考慮 Plan B
有一件事，我想先潑啲冷水。AI 生成嘅結果，本質上就係唔穩定嘅。
如果你心裏冇 Plan B，咁 Bug 只係早嚟同遲嚟嘅分別。
我自己最常踩坑、亦最易被忽略嘅，其實得兩類場景：
第一類：結果要俾「機器繼續用」嘅場景
例如 JSON 結構化，用嚟做特徵提取、參數對接、前端渲染。
第二類：結果有「硬約束」嘅場景
例如小紅書標題，最多 20 個字，多一個都唔得。
先講最常見嘅：JSON 結構化。
假設我哋而家要拆解一篇長文，提取佢嘅核心觀點、金句、爆點、鈎子。
如果只係：用嚟展示，或者作為下一個 AI 節點嘅上下文。
講真，根本唔需要結構化，直接塞就搞掂。
但一旦你想做兩件事，麻煩就嚟：
• 前端要「靚噉顯示」 • 某幾個字段，要作為下一個函數嘅輸入參數
呢個時候，穩定性就唔係「加分項」，而係生死線。
大多數人會點做？
• 拼命優化提示詞 • 強調「必須輸出 JSON」 • 跟官方文檔寫 JSON Schema
呢啲方法啱唔啱？啱，而且可以解決 95% 嘅問題。
但我想提醒一句好現實嘅話：
程式，只要有 1% 嘅機會出錯，喺規模化運行嘅時候，佢一定會暴露出嚟。
所以真正穩陣嘅做法，其實好簡單：加多一道校驗。
• 先檢查結果係咪合法 JSON • 如果唔係，就將個結果直接掉返俾 AI，再行一次
以下文本可能有格式錯誤，請提取並修復其中的JSON內容。
期望返回格式：xxx原文本：xxx直接返回修復後的JSON，不要解釋。再說字數限制呢個問題。
玩過小紅書嘅人都知，標題最多 20 個字。
現實係，AI 好難穩定咁卡喺呢個範圍入面。
偶然就會寫成 22 個字、25 個字。無論你點樣調提示詞，呢個問題都會出現。
呢個係模型本身嘅特性。
截取就更加唔現實，咁樣會破壞標題嘅完整性。我嘅做法係：
• 先檢測字數 • 超過限制，就將個結果再掉返俾 AI • 明確話佢知：要壓縮到 20 字以內，甚至可以留多少少緩衝
你是一名小紅書運營專家，請將下面的標題精簡。
要求：字數≤18（必須滿足），保留核心信息和吸引點，不使用emoji，僅輸出精簡後的標題，不做任何說明。
原標題：xxx超長標題xxx無論係上面呢兩個場景需要兜底，
大模型嘅 API 供應商都係噉，Plan B 永遠令你更有底氣。
六、盡可能將你遇到嘅定製化需求通用化
我用一個真實發生過嘅需求，嚟講呢個技巧。
由舊年 10 月開始，我接到唔少自媒體嘅定製化需求。
其中有一個好典型嘅場景：將視頻文案，自動改寫成多種語言版本。
第一個版本好快就做完，功能都用得。
結果客戶好快提出一個優化意見：
「而家生成嘅泰文我完全睇唔明，可唔可以俾個中文對照我？」
如果企喺「純定製」嘅角度，呢個需求其實好好改：
• 目標語言：泰語 • 輸出格式：泰文 + 中文對照 • 提示詞打出嚟，搞掂
但我當時停咗一停。
我問自己一個問題：
• 咁如果下一個用戶係英文呢？ • 再下一個係日文、越南文呢？ • 係咪每嚟一種語言，我就要重寫一套邏輯？
呢個時候你會發現一件事：
需求本身唔複雜，複雜嘅係佢未來嘅變化。
講真，呢種通用性嘅設計，靠自己去諗，都幾靠經驗。
但我哋可以交俾 AI：
請基於我提供的最新需求和已有的功能設計，幫我重新整理這個需求。
需求：
xxx需求描述xxx
目標是：
在不改變核心價值的前提下，將一次性的、具體的需求提煉為一個更通用、可複用的功能。
請你重點思考並說明：
- 這個需求真正想解決的“核心問題”是什麼
- 當前方案中，哪些設計是強綁定當前場景的
- 如果未來出現更多相似但不完全一樣的使用場景，哪些地方可能會受限
請給出一個更通用的需求表達方式，並簡要說明：
- 這個通用版本可以覆蓋哪些類型的場景
- 相比原需求，複雜度是否明顯增加
可以見到，用戶真正需要嘅，
是一種 係能夠協助理解非母語文案嘅能力 ，並唔侷限於泰語呢一種語言。
呢個就係呢個定製化需求背後隱藏嘅關鍵點，
一旦捉住呢一點，往往可以事半功倍。
AI 將可能會出現嘅場景，幾乎都列成一張矩陣。
連對應嘅 UI 交互草圖，都一併俾埋出嚟。
基於呢套交互設計，現階段可以 cover 到嘅大部分情況，基本上都兜得住。
最終優化嘅效果如下：
七、每一次花心機修復嘅過程，都應該變成你嘅知識寶藏
真正意識到要將經驗總結成知識卡片，係喺做「熊貓論文」呢個項目嘅時候。
嗰段時間，我不斷做 Vibe Coding。
睇住功能一個個俾 AI 砌出嚟，
我負責測試，再將結果掉返去，繼續改錯，繼續改。
當時仲係用 Claude 3.7。
能力同而家嘅 Claude 4.5 Opus 比，差距好明顯。
一個稍微複雜嘅問題，成日要嚟回搞一兩個鐘。
連續咁樣行咗一兩星期之後，我突然覺得唔太妥。
我發現自己唔係喺度驅動 AI，反而似一個俾流程推住走嘅執行者。
我冇留下任何可以重用嘅嘢。淨係得啲勉強行到嘅功能。
如果下次再遇到類似問題，我仲係要由頭嚟過。
由嗰時開始，我轉咗做法。
只要遇到複雜問題，或者 花咗好耐先修完嘅 bug，
我都會叫 AI 幫我將過程提煉成筆記，或者整理成一張張知識卡片。
筆記卡片（適合複雜嘅 bug 修復）：
請回顧這次對話，提煉其中最關鍵的 xx 個問題，
並分別整理為 FAQ 形式的筆記卡片。
每張卡片請包含：
- 問題現象：當時具體遇到了什麼情況
- 根因說明：問題產生的核心原因
- 解決方式：最終採用的解決方案或判斷路徑
- 適用提示：在什麼場景下可能再次遇到，如何提前避免
要求：
- 使用 Markdown，結構清晰，便於快速掃讀
- 表達簡潔，偏總結而非過程複述
- 不引入對話中未出現的新結論技術教程（適合相對完整嘅技術教程、方案）:
請將上面的內容整理成一份「可讀性強的 Markdown 筆記」。
整理時請遵循以下原則：
- 以“希望把事情真正講清楚”為目標，而不是堆信息
- 重點說明“發生了什麼”和“為什麼這樣做”，再說明“怎麼做”
- 避免術語堆砌，必要時用直觀解釋或簡單類比輔助理解
筆記結構建議如下（可根據內容靈活調整）：
1. 背景與問題：事情從什麼情況開始，核心困擾是什麼
2. 現有做法：之前的處理方式，以及由此帶來的限制或風險
3. 新的思路：新的解決方向或方案，以及形成這一判斷的原因
4. 關鍵過程：按步驟梳理重要變化，必要時用流程圖或時序圖幫助理解
5. 總結與要點：本次經驗中值得記住的結論，以及可複用的判斷原則
輸出要求：
- 使用 Markdown，結構清晰、層次分明
- 語言自然、可順讀，適合作為教程或學習筆記
- 不引入未出現的新背景，不做過度推演或延展呢啲筆記同知識卡片，我都會沉澱喺代碼項目入面，
同時再歸檔一份去自己嘅飛書知識庫。
放喺代碼嘅目的，
係為咗喺修復問題或者開發新任務時，我都會提醒AI，喺首句加上：
請從項目中檢索是否遇到同樣的問題，xxxx只要命中一次，我就賺咗。
八、將長期使用嘅上下文沉澱成通用文檔
無論係需求文檔、樣式規範、組件庫、技術棧、接口說明、FAQ 等等，
定係用嚟約束 AI 行為嘅 Cursor Rule、Claude.md，
佢哋都會喺項目嘅某個階段，被當作上下文反覆交俾 AI。
我嘅睇法係：呢啲嘢應該盡早準備，並且喺開發過程中持續引用、持續優化。
咁樣做，自然會形成正循環。
當你已經沉澱出一套相對穩定嘅通用文檔，
再將佢哋引入到 Cursor Rule、Claude.md 入面，代碼質量往往會明顯提升，返工亦會大幅減少。
下面嘅提示詞，就係我喺一個真實商業項目中使用嘅 Cursor Rule。
如果你有需要，完全可以喺呢個基礎上做修改同重用。
# Cursor Rule
## 角色與溝通
你是 Python 工程師，幫助技術基礎較弱的初中生完成項目開發。
- 用通俗語言解釋關鍵概念（不堆術語）
- 每次輸出儘量給出：要做什麼 + 為什麼 + 下一步怎麼用
- 遇到不確定點：先列出澄清問題或假設，再寫代碼（不要瞎補需求）
## 文檔即上下文（默認必須引用）
處理任何需求前，先閲讀並遵循這些文件（如不存在則創建）：
- README.md：項目目標、使用方式、參數/返回值示例
- docs/development_guide.md：技術棧、目錄結構、開發規範
- docs/requirements.md（如有）：需求與邊界
- docs/api.md（如有）：接口約定、鑑權、錯誤碼
- docs/faq.md（可選）：常見問題與約定
> 開發過程中持續更新上述文檔：新增功能/約定/坑點，必須同步補齊。
## 工作流程（強制順序）
1) 需求理解
- 用一句話複述需求目標
- 列出 1~3 個關鍵澄清點/假設（儘量少但必須）
- 選擇最簡單可行方案，避免過度設計
2) 實現
- 遵循 PEP8 + Type Hints + 清晰 docstring
- 模塊化、可維護；必要時加日誌與錯誤處理
- 嚴格貼合現有項目目錄與代碼風格（先讀代碼再擴展）
3) 測試（必須）
- 在 tests/ 下按類型放置 pytest 用例（只寫接口測試）
- 覆蓋率目標：100%（以關鍵分支為準，必要時補邊界與異常用例）
4) 接口與鑑權
- 若實現的是接口：根據功能判斷是否需要 JWT
- 接口行為以 docs/api.md 為準；若缺失則補充約定（含示例請求/響應）
5) 數據庫變更（如涉及）
- 在 alembic/versions/ 生成遷移文件
- 補充初始化數據（如需要）並確保遷移可執行
- 變更說明同步寫入 docs/development_guide.md
6) 收尾與覆盤（必須）
- 更新 README.md：新增功能的用法、配置、示例
- 更新 docs/development_guide.md：目錄/依賴/規範變化
- 簡要列出：本次改動影響範圍 + 後續可優化點（不長篇）
## 參考
默認以 Python 官方文檔為準：https://docs.python.org/喺實際使用中，AI 有時並唔會完全嚴格咁跟住我哋設定嘅全局規則嚟執行。
所以我哋都要留意本地文檔嘅變更情況：
當新增咗組件、調整咗需求之後，
如果相關文檔仲未得切更新，就可以主動提醒 AI，將呢啲文檔補齊同修正。
呢度要強調一件事：需求文檔一定要及時更新。
喺一個持續演進嘅項目入面，需求文檔係除咗代碼本身之外，
每個功能模塊最重要嘅上下文。
佢可以幫助 AI：
• 喺修復局部 bug 時，分清邊啲邏輯係刻意保留落嚟，避免唔小心傷到整體設計 • 喺新增功能時，理解模塊真正嘅職責，令功能自然生喺應該生嘅位置 • 喺重構過程中，始終保持對用戶行為同業務約束嘅整體認知，而唔係淨係追求代碼層面嘅優雅
提示詞：
這部分功能 / 需求做了如上調整，可能是重構、改邏輯，或者加了點新能力。
請你幫我同步更新需求文檔，但注意一件事：
只寫“真的變了什麼”，不要擴寫。
在整理時，請重點關注：
- 新增了什麼能力（一句話能說清就別多說）
- 哪些原有需求已經不適用了，需要改或刪
- 這次變化有沒有影響到使用方式或邊界
請遵循這些原則：
- 只描述“對用戶或系統行為有影響的變化”
- 不補背景、不做長解釋、不寫實現細節
- 能刪就刪，能合併就合併
- 儘量不要補充細節代碼
目標：
讓這份文檔保持最小、最新、好讀，
看一眼就知道現在系統“到底是怎麼工作的”。九、極致嘅專注可以擊穿代碼
回頭睇呢一年用 AI 編程，我發現一個成日被忽略嘅點： 我哋點樣對待「等結果」嘅時間。
後來我意識到，呢啲時間唔係碎片，而係一段緩衝區。
我哋都見到唔少人推薦，喺呢段時間利用 Coding Agent 並行推進多個任務。
我都認真試過一段時間，但最終都係好剋制咁用佢。
因為我發現，咁樣對我嚟講，容易搞亂思緒，效率反而下降。
相反，無論係靜靜咁睇住屏幕、或者冥想一陣，放空自己，又或者用嚟補充文檔，諗下一步點做。
只要唔過度攝入太多幹擾信息，我嘅效率反而會更加高。
咁樣一來，等待唔再係中斷，而變咗為下一步提早蓄力嘅過程。
呢個方法唔一定適合所有人，大家見仁見智啦。
十、從用得順眼到手：我嘅 UI 優化心得
呢個係「熊貓論文」主界面嘅 UI 演變過程。
由一開始慘不忍睹，到而家俾好多人讚更加順眼。
講真，可能唔係因為而家呢版有幾靚。
更多係因為 第一版太樣衰，一路用開嘅用戶，突然覺得對眼得到解放。
好多人問我：UI 係點慢慢改過嚟？
第一步，最重要嘅，你一定要先有一份設計規範。
因為你唔係喺度做一個頁面。
登入頁、Landing Page、主頁、充值頁、後台管理頁，
如果每一塊都生得唔同，佢就唔似一個完整嘅系統。
好多人一開始會糾結：
「我唔識設計點算？」
「我都講唔清咩叫好睇，點算？」
做法其實好簡單。
輸入提示詞，再加幾張自己覺得：
符合產品氣質、符合用戶審美 嘅參考圖，直接掉俾 AI。
叫 AI 生成一份 初版設計規範。
你是一名大廠資深 UI 設計負責人。請基於我提供的多張參考圖，提煉其共性風格，
並輸出一份“可落地的 UI 設計規範（Style Guide）”，用於項目初期統一風格或重構對齊。
請不要逐張描述圖片，而是抽象出可執行的規則與設計 tokens。
如有不確定項，請給出“推薦默認值 + 可選範圍 + 使用場景”。
請按以下結構輸出（Markdown）：
## 0. 風格摘要（1屏讀完）
- 一句話風格定位（氣質關鍵詞）
- 3條最重要的設計原則（例如：剋制、對比明確、留白優先等）
- 適用場景與不適用場景
## 1. 設計變量（Design Tokens）
### 1.1 顏色系統
- 主色 / 輔助色 / 強調色
- 中性色階（背景/文字/邊框/分割線/禁用態）
- 狀態色（成功/警告/錯誤/信息）
- 漸變系統（如適用：方向、用途、禁用場景）
- 對比度與可訪問性建議（簡單規則即可）
### 1.2 字體與排版
- 字體取向與替代方案
- 字號體系（標題/正文/註釋/數據展示）
- 字重、行高、段落間距
- 文案語氣：按鈕/提示/錯誤信息的風格傾向（簡短/剋制/友好等）
### 1.3 間距與柵格（佈局基礎）
- 8px 或 4px 間距體系（建議選一種並說明理由）
- 柵格與容器：頁面最大寬度、左右邊距、分欄規則
- 圓角體系（xs/s/m/l 對應場景）
- 陰影與層級（Elevation：0/1/2/3 的含義與使用邊界）
- 分割線/描邊粗細規則
## 2. 佈局規範（頁面層）
- 信息層級：標題區/操作區/內容區/輔助信息區的組織方式
- 列表頁、詳情頁、表單頁的通用佈局骨架
- 留白策略：何處必須留白、何處可緊湊
- 空狀態/加載/錯誤態的版式原則
## 3. 組件規範（關鍵控件）
請至少覆蓋以下組件，並給出：默認樣式、狀態（default/hover/active/disabled/loading）、使用原則、避免事項。
- Button（主/次/文字/危險/圖標按鈕）
- Input / Textarea / Select / Search
- Form（必填標識、錯誤提示、校驗觸發時機）
- Tabs / Segmented / Breadcrumb（導航層級）
- Navbar / Sidebar / Menu（主導航：展開/摺疊、選中態）
- Card / Modal / Drawer（容器與彈層）
- Table（表頭、行高、密度檔位、空態）
- Tag / Badge / Tooltip / Popover
- Toast / Notification（反饋強度與出現位置）
## 4. 響應式與自適應
- 斷點建議（移動/平板/桌面/大屏）
- 字體與間距在不同斷點如何縮放
- 導航在不同屏幕下的變化策略（側邊欄/底部欄/抽屜）
- 表格、圖表、長文本在小屏的處理策略
## 5. 動效規範（Motion）
- 動效的總體原則（剋制/順滑/有目的）
- 過渡時長與節奏（快/中/慢的建議區間）
- 常見動效模式：頁面切換、彈層出現、列表加載、按鈕反饋
- 禁用動效的場景（性能/無障礙/減少干擾）
## 6. 落地建議（給開發/AI）
- 如何把規範轉為組件庫/樣式變量（tokens → theme → components）
- 最小落地路線：先統一哪些組件與頁面，收益最大
- 常見偏離點清單（最容易被做亂的3-5處）
輸出要求：
- Markdown 結構清晰，儘量“一屏一塊”，可直接複製進項目文檔
- 優先給“可執行規則”，少用抽象形容詞
- 不編造圖片中不存在的品牌元素；如果圖片不足以確定，明確標註“建議默認值/可選範圍”PS：上面提示詞微調後，同樣適用於將老項目嘅 UI 風格提煉成規範文檔，作為後續開發時 AI 嘅上下文。
第二步，驗證輸出效果。
呢一步主要係為咗先睇嚇整體嘅輸出效果。
無論係直接用 Figma 生成初版框架，
定係直接上 Coding Agent，
喺生成之後，我哋都可以不斷將結果反饋俾 AI，持續迭代整體嘅設計規範。
呢度其實有個小技巧：
先圍繞一個頁面做單點突破，打磨出一個自己真正滿意嘅「樣板間」，
一邊用佢嚟校準同迭代樣式規範。
等呢套規範相對穩定咗，再慢慢鋪開到全局。
第三步，將樣式規範寫入 Cursor Rule / Claude.md。
之前嘅步驟都有提過。
為咗保證未來多個頁面嘅風格統一，
我哋可以將樣式規範寫入全局規則，避免每次都要提醒 AI。
最後再分享一啲過程中嘅小技巧。
1、「截圖 + 局部圈選 + 期望效果」比純文字強一倍
一圖勝千文。
如果我哋本身唔係設計專業，好多 UI 問題其實好難用語言準確講清楚。
呢個時候直接截圖，將問題位置簡單標出嚟，再配一段說明，又快，又唔易理解錯。
2、叫 AI 生成「多方案對比」，你只做選擇題
唔好叫 AI 直接俾「最終方案」，而係叫佢俾 3 套風格變體，
每套講明差異點（更剋制/更活潑/更商務），你只揀一個方向再深化。
呢招特別適合「有審美，但唔想自己由零畫」嘅路徑。
你是資深UI/UX設計師。我要做一個【XXX頁面類型】頁面，目標是【XXX目標】。
請先做兩件事：
1) 如果我沒提供方案：請你直接給出 3 套不同佈局方案（A/B/C），用幾句話描述每套的結構。
2) 然後對 A/B/C 做對比並給推薦。
對比維度固定為：
- 信息層級是否清晰
- 轉化效率/視覺焦點
- 響應式適配難度（桌面/平板/手機）
- 後續擴展性（運營位/活動/說明）
最後輸出：
- 推薦順序（例如 A > C > B）+ 一句話原因
- 推薦方案的 3 條可直接落地的微調建議3、UI 迭代唔好靠感覺：要及時總結同沉澱
好多時，我哋如果唔係設計專業出身，可能對 UI 冇咁敏感。
頁面用得、睇落順眼，就容易「是但啦」，然後放埋一邊。
但我後來發現，UI 最有價值嘅唔係某一版改得靚，
而係可唔可以將優秀設計沉澱落嚟，變成下次直接重用嘅標準。
唔好忽略呢啲細微改動。
每次遇到唔錯嘅設計，我都會習慣順手叫 AI 做一段總結：
我會提供一張“做對的頁面”截圖（可選：再提供一張優化前對比圖）。
請你幫我把這次 UI 優化沉澱成“樣板卡片”，用於以後直接照搬。
請輸出 4 部分（Markdown）：
1. 一句話規則（最重要）
- 用一句話說明：為什麼它更好看/更好用（要具體、可執行，避免空泛形容詞）
2. 關鍵改變點（3條以內）
- 這次最關鍵的 1~3 個變化是什麼（例如：信息層級、留白節奏、按鈕主次、對比度等）
3. 照搬要點（5條以內）
- 以後做新頁面時，哪些點必須照這個樣板做（寫成清單，能直接抄）
4. 易踩坑提醒（2條）
- 最容易被做回去/做亂的地方是什麼，以及一句話提醒怎麼避免
要求：
- 簡短，適合和截圖一起存進“UI 樣板庫”
- 不逐圖描述細節，不做長篇解釋十一、總結
一年前嘅我，成日以為，
AI 編程嘅難點在於「模型唔夠聰明」。
但而家我明白咗，真正嘅難點從來唔係工具，而係我哋自己：
• 我哋習慣咗模糊嘅表達，但係要學識精確嘅描述 • 我哋習慣咗一步到位，但係要學識分步推進 • 我哋習慣咗憑感覺判斷，但係要學識建立標準同規範
呢啲技巧，表面係教你「點樣用AI」，但本質上係重新訓練我哋嘅思維方式：
點樣將腦入面模糊嘅想法，拆解成可行嘅步驟；
點樣將一次性嘅經驗，沉澱成可以重用嘅知識；
點樣喺不確定性中，建立確定性嘅標準。
呢啲能力，喺任何場景下都可以發揮作用。
所以，AI編程教我哋嘅，唔止係寫代碼，而係將混沌變成秩序，將想法落實成系統。
最後，祝你 2026 喺 AI 編程路上，少踩坑，多收穫。
我係 🐼熊貓Jay，我哋下次再見。
如果覺得唔錯，順手點個讚、睇嚇、轉發三連啦。
如果想第一時間收到推送，都可以俾我個星標 ⭐
多謝你睇我嘅文章 ~
去年這個時候，一個5千塊的定製化項目，我整整改了一個多月。
效率極低，一度讓我想放棄。
過去一年，我做了 3 個產品：熊貓論文、熊貓工坊，還有一個正在內測的出海項目 PostMaker 。
粗略算下來，代碼量大概 60 萬行。
這一年我發現：
AI 寫得太快了，有時候快到你還沒反應過來，方向就已經錯了。
於是你就會遇見這些崩潰的畫面：
• 寫得越快，返工越多 • 修完一個bug，又冒出下一個 • 頁面看起來能用，但總像臨時拼起來的 • ...
這篇文章，我會把這一年踩過的坑和摸索出來的打法，按步驟分享出來。
如果你正在學AI編程，希望這 10 個技巧，能讓你少走一些彎路。
一、AI 不怕複雜 Bug，只怕一句廢話
對於非技術背景的朋友，改 bug 可能是 AI 編程過程中頻率最高，也是最頭疼的事情了。
如果你修復 bug 的提示詞是：
點擊“確認”按鈕報錯了又或者是
頁面卡住了，始終空白那我建議你一定要好好看一看這一章。
1、快速提問法：
想讓 AI 快速幫上忙，關鍵就一件事：把 Bug 的“最小閉環信息”說完整。
XXX角色的用戶在XXX地方操作了XXX幾個動作，出現了XXX異常現象，
導致在XXX位置（代碼控制枱 or 瀏覽器控制枱）產生了XXX錯誤信息。只要把這 6 點交代清楚，通常就能覆蓋 80% 的場景。
所以請保持對 Bug 起碼的尊重，別偷懶，別抱有僥倖心理。
2、上下文大法：
遇到頑固 Bug，只靠第一種“最基本信息”往往是不夠的。
因為這種問題通常牽扯到更復雜的執行鏈路，局部現象很難直接推到根因。
這時候就得上“上下文大法”：把你能想到的線索儘量一次性給全。
比如最近需求變動的時間點和具體改動、
有沒有調整過配置參數、
為修這個 Bug 你之前做過哪些嘗試、
每次嘗試的結果是什麼。
請基於以下信息，幫我分析並解決問題。
## 問題描述
- 我做了什麼，實際發生了什麼：xxx
- 正常情況下應該發生什麼：xxx
## 問題情況
- 是否每次都會發生：xxx
- 什麼時候開始出現的：xxx
- 出問題前是否有過改動：xxx
## 提示信息（如果沒有，則不提供）
- 頁面提示 / 報錯日誌內容：
xxx
## 已嘗試
- 我已經嘗試過的操作：
- 是否有變化：
## 分析要求
- 用通俗的話說明可能原因
- 給出下一步可以直接嘗試的解決辦法
- 如信息不足，請告訴我需要補充什麼3、AI 也需要適應環境：
上面兩步還搞不定，怎麼辦？
這時候，其實很可能不是你不行，而是 AI 還沒進入你的世界。
我們經常幹一件事：
直接把一個 Bug 症狀，丟給 AI，
而且還有可能在一個完全不相干的上下文裏。
這有點像你半夜把一個剛睡醒的同事拽過來：“這個功能為啥炸了？你馬上給我答案。”
成功率，能高才怪。
更穩的做法是：先讓 AI 熟悉環境，再讓它動手修 Bug。
哪怕你現在沒有完整的需求文檔，
也可以先讓 AI 幫你 理解這個功能的代碼結構、核心流程、設計意圖，
等它“搞清楚這是在幹嘛”，
再把具體的異常現象、報錯信息丟進去。
這樣，當你和 AI 同時擁有記憶時，效果會完全不一樣。
PS：梳理代碼邏輯時，建議讓 AI 將流程通過流程圖、時序圖等等你熟悉的可視化方式來呈現。
請先幫我理解這個功能在“正常情況下”是怎麼工作的：
- 主要代碼結構
- 核心流程（可以用步驟描述）
- 關鍵狀態或判斷點
請配合使用流程圖或時序圖的方式，加上通俗的語言幫我梳理代碼的完整邏輯。4、全局觀：把完整驗收標準 / 測試用例交給 AI
修復雜 Bug 時，最常見的坑是：這邊剛修好，那邊又冒出新問題，
甚至越修越亂，來回打補丁像陷入死循環。
如果你已經改了幾輪還是不穩定，我建議別再盯着某一行報錯死磕了。
去把這個功能的「完整驗收標準」或「測試用例」找出來，
再補上它和其他功能的關聯邊界，一起丟給 AI。
有了這些“全局標準”，AI 才能在修復時兼顧整體行為，不至於拆東牆補西牆。
在企業裏這個做法更容易落地：因為正規的研發流程通常都會為需求配套測試用例。
我們把這些用例作為上下文給 AI，
自測時不僅更有方向，還能順便讓 AI 幫你生成 迴歸腳本，
把修復和驗證做成閉環。
請基於我提供的測試用例、驗收標準、相關需求等信息，從“全局正確性”出發修復 Bug，避免修一個bug，再次引入新的 Bug。
請按這個順序輸出：
1) 先簡潔複述：這個功能的“正確行為”（根據驗收/用例）
2) 指出當前 Bug 違反了哪幾條用例/驗收點（列 3-5 條）
3) 給出最小改動的修復方案（改哪些文件/函數/關鍵邏輯）
4) 給出需要回歸的用例清單（基於我提供的用例/驗收點）
只基於我提供的信息，不要腦補；信息不夠就問我最多 3 個關鍵問題。最終目標是把 Bug 修好並通過這些用例。5、終極大法：Debug 模式
這是傳統做法裏，解決 Bug 最高效的一條路：用“可復現 + 可觀測”的方式，把問題還原出來。
但對非技術同學確實不友好——你很難知道該抓哪些信息、怎麼看日誌、怎麼把現象還原成線索。
好在現在不少 AI 編程工具已經把這件事“產品化”了。
比如 Cursor 有 Debug 模式，Claude Code 也支持通過 debug 指令來輔助排查。
它們的價值不只是“多輸出點日誌”，
而是 把排查過程變成一條更可控的鏈路：
更清楚地看到工具的運行步驟、關鍵調用、以及失敗發生在哪一環。
以 Cursor 為例。
我之前在優化工具「長文轉小紅書」時，遇到運行時間過長的問題，就直接用 Debug 模式來做定位。
我先把必要信息補齊，然後按它給出的復現步驟手動執行一遍，讓日誌完整記錄下來。
接着它將自動分析日誌，也會更容易看出瓶頸點在哪裏。
那次它給我的建議很明確：有些步驟其實可以合併，減少重複計算和中間結果的來回傳遞。
我採納建議後，讓 AI 按計劃改完，再跑一遍同樣的復現步驟做驗證。
確認問題解決後，記得點“問題已修復”按鈕。
這樣 AI 會自動去掉多餘的日誌，保持代碼整潔，否則放到線上可能會出現 路徑找不到 的問題。
二、用 Plan 模式讓 AI 慢下來
這一年裏，我一直和 AI 一起寫代碼，也慢慢形成了一個固定習慣。
在把任務交給 AI 之前，先讓它進入 Plan 模式。
不管用的是 Cursor，還是 Claude Code，這個模式的作用，其實不只是“多看一眼需求”。
它真正做的一件事，是逼着需求先被拆開、被質疑、被補全。
就拿 Cursor 舉例。
在 Plan 模式下，它不會馬上寫代碼，而是先找問題。
哪裏有歧義？
哪些前提沒說清？
有沒有隱含的假設？
它會直接把這些點拋出來，讓你補充說明。
在一來一回的過程中，原本模糊的想法，會慢慢變成一個邊界清楚、能動手執行的方案。
Plan 模式，其實只是把軟件開發裏一個很老、但一直好用的做法，搬到了 AI 協作裏。
先設計，再寫代碼。
多花幾分鐘把計劃說清楚，把執行路徑對齊好，往往能省下後面幾個小時的反覆修改。
有時候，慢下來，會更快～
三、需求拆不清，後面將都是返工
不管是主業還是副業，我一直是直接面對需求的人。
以前，我要把需求翻譯成技術能看懂的話。
現在不一樣了。
接到定製商單，或者產品要做新功能，我同樣要先做一件事：拆需求。
說句實話：
這件事，至少吃掉了我 30% 的精力。
從去年開始，我逐漸習慣用提示詞來幫自己拆需求。
更多是逼自己把問題想清楚。
如果拆解不到位，後果通常只有兩個：
要麼反覆返工，
要麼為了趕進度，團隊只能硬扛。
下面這個，是我平時用來拆需求的提示詞。
說實話，一些簡單的產品需求，直接用它就夠了。
但如果是全新的功能模塊，就不要照搬，更好的做法是：
• 先結合自己的經驗 • 把需求拆成幾個具體、獨立的使用場景 • 再用提示詞繼續往下拆
這樣用，價值會更大。
需求不是一開始就完整的，其實是逐漸拆出來的。
你現在是一個資深產品經理兼需求分析師，請將我提供的需求描述，整理成適合開發人員快速理解和交付的結構化需求說明。
## 輸出格式
嚴格遵循以下模板：
"""
## 模塊：[功能模塊名稱]
### 功能描述
- 用項目符號簡明列出該模塊需要實現的核心功能點（以“支持…”、“允許…”、“點擊…”等動詞開頭）。
- 避免描述背景或實現方式，只關注“系統需要實現的行為”。
### 用戶故事
作為[角色]，我希望[行為]，從而[目的]。
（僅一句話，保持簡短、聚焦價值。）
### 驗收標準
- ✅ 正向驗證：描述成功操作後應出現的正確結果。
- ❌ 負向驗證：描述錯誤或異常場景下應出現的提示或限制。
- 每條標準前加符號（✅/❌），確保測試可讀性。
- 語言保持簡潔明確，避免歧義，用“→”描述操作到結果的邏輯。
### 備註 / 待確認
- 列出尚不確定、需進一步確認或可能變更的要點。
- 可包含設計、接口、性能或交互類問題。
"""
## 內部注意點
"""xxx內部的規範要求或者經常容易遺漏的注意點，減少研發返工xxx"""
## 輸出要求：
1. 嚴格使用 Markdown 格式。
2. 每個模塊形成一個“開發-測試閉環”卡片（功能描述 + 用戶故事 + 驗收標準 + 備註）。
3. 不寫多餘的背景或敍述。
4. 若輸入包含多個模塊，請分模塊分別輸出。
## 需求
"""xxx需求說明，可以是一句話，也可以是詳細的說明xxx"""比如最近，主業裏的研發平台要支持 合併列頭 這種平台級配置。
按照提示詞模版，我在 ChatGPT 裏給的東西其實很少。
只有兩句話的口述需求，再加上一些注意點，
以及我當時能想到的影響範圍。
除此之外，我順手把內部的一些規範要求也一起丟了進去。
像這種相對不復雜的需求，
AI 生成的結果，稍微改一下就能直接用。
但真正有價值的，其實是：備註 / 待確認。
基於我給的內部注意點，再加上它自己的理解，
AI 會列出不少提醒和補充項。
這些內容，很多並不是“答案”，而是 替你多想一步。
幫你提前看到可能的坑，把返工的概率降低。
有意思的是，
這種方式，反而會倒逼我們自己去想清楚問題。
四、複雜方案，先推演，後落地
不知道你有沒有遇到過這種情況。
發現一個嚴重 bug，或者需求突然改動很大，
把問題丟給 Cursor 之後，它一下子給你列出好幾種方案。
有最推薦的，有次一點的，
有的追求見效快，有的偏向長期維護。
問題是，這些方案裏，常常會踩到我們的知識盲區，
或者涉及並不熟的領域。
這時候就很糾結了：到底改不改？選哪個？
改的話，很容易吃掉大量時間和成本，最後還不一定走得通，甚至要推倒重來。
不改，問題就一直在那裏。
後來我意識到一件事。想提高複雜方案真正落地的成功率，
不能只看“方案本身”，還要提前看它會怎麼跑。
於是我開始讓 AI 幫我做一件事：方案推演。
在真正動手前，先確認幾件事：
• 這個方案，能不能解決當前的問題 • 落地之後，會不會影響已有功能 • 哪些地方最容易出風險
這些問題，其實都可以在 方案推演階段 被提前看清楚。
請基於上述方案，幫我模擬程序在完成後的整體執行過程。
請你重點說明：
- 程序在正常使用情況下，會按照什麼順序一步步運行
- 每一步主要在做什麼事情，想解決什麼問題
- 關鍵參數在流程中起到什麼作用，會對結果產生哪些影響
在說明過程中，請特別留意：
- 哪些步驟是必不可少的，哪些可能只是為了“看起來完整”
- 如果某些輸入不符合預期，流程可能會受到什麼影響
- 有沒有邏輯可以簡化、合併，或者其實可以不要
輸出要求：
- 使用通俗、直白的語言描述，不要堆技術術語
- 可以用簡單的流程圖或步驟列表，幫助我快速理解整體邏輯
- 在結尾用幾句話總結：這個程序邏輯是否清晰、是否有調整空間之前碰到過一個很具體的案例。
為了讓 API 的調用過程更穩定，我加了一層能力：在不同 API 供應商之間做智能切換。
但問題很快就出現了。
現有系統裏，不僅有不同的模型類型，還覆蓋了多種業務場景。
• 語言模型 • 文生圖 • 視覺模型 • 文生視頻模型
但當我把這套方案用到文生圖場景時，我先按之前的提示詞跑了一次測試。
結果很直接，它瞬間幫我暴露出了不少 中高風險問題。
這些點，如果當時我自己沒有想清楚，就直接讓 AI 去實現，
後面幾乎一定會出現一堆 Bug。
五、任何用 AI 生成的結果，都該考慮 Plan B
有一件事，我想先潑點冷水。AI 生成的結果，本質上就是不穩定的。
如果你心裏沒有 Plan B，那 Bug 只是早來和晚來的區別。
我自己最常踩坑、也最容易被忽略的，其實就兩類場景：
第一類：結果要被“機器繼續用”的場景
比如 JSON 結構化，用來做特徵提取、參數對接、前端渲染。
第二類：結果有“硬約束”的場景
比如小紅書標題，最多 20 個字，多一個都不行。
先說最常見的：JSON 結構化。
假設我們現在要拆解一篇長文，提取它的核心觀點、金句、爆點、鈎子。
如果只是：拿來展示，或者作為下一個 AI 節點的上下文。
說實話，根本不需要結構化，直接塞就完事了。
但一旦你想做兩件事，麻煩就來了：
• 前端要“好看地渲染” • 某幾個字段，要作為下一個函數的輸入參數
這時候，穩定性就不是“加分項”，而是生死線。
大多數人會怎麼做？
• 拼命優化提示詞 • 強調「必須輸出 JSON」 • 按官方文檔寫 JSON Schema
這些方法對嗎？對，而且能解決 95% 的問題。
但我想提醒一句很現實的話：
程序，只要有 1% 的概率出錯，在規模化運行時，它就一定會暴露出來。
所以真正穩的做法，其實很簡單：多加一道校驗。
• 先檢查結果是不是合法 JSON • 如果不是，直接把結果丟回給 AI，再跑一次
以下文本可能有格式錯誤，請提取並修復其中的JSON內容。
期望返回格式：xxx原文本：xxx直接返回修復後的JSON，不要解釋。再說字數限制這個問題。
玩過小紅書的人都知道，標題最多 20 個字。
現實情況是，AI 很難穩定卡在這個範圍內。
偶爾就會寫成 22 個字、25 個字。不管你怎麼調提示詞，這個問題都會出現。
這是模型本身的特點。
截取就更不現實，這樣破壞的標題的完整性。我的做法是：
• 先檢測字數 • 超過限制，就把結果再丟回給 AI • 明確告訴它：需要壓縮到 20 字以內，甚至可以多留點緩衝餘地
你是一名小紅書運營專家，請將下面的標題精簡。
要求：字數≤18（必須滿足），保留核心信息和吸引點，不使用emoji，僅輸出精簡後的標題，不做任何說明。
原標題：xxx超長標題xxx不管是上面這兩個場景需要兜底，
大模型的 API 供應商也是如此，Plan B 始終讓你擁有更多的底氣。
六、儘可能將你遇到的定製化需求通用化
我用一個真實發生過的需求，來講這個技巧。
從去年 10 月開始，我接到了不少自媒體的定製化需求。
其中有一個很典型的場景：把視頻文案，自動改寫成多種語言版本。
第一個版本很快就做完了，功能也能用。
結果客戶很快提了一個優化意見：
“現在生成的泰文我完全看不懂，能不能給我一箇中文對照？”
如果站在“純定製”的角度，這個需求其實很好改：
• 目標語言：泰語 • 輸出格式：泰文 + 中文對照 • 提示詞敲出來，事情結束
但我當時停了一下。
我問自己一個問題：
• 那如果下一個用戶是英文呢？ • 再下一個是日文、越南文呢？ • 是不是每來一種語言，我就要重寫一套邏輯？
這時候你會發現一件事：
需求本身不復雜，複雜的是它未來的變化。
說實話，這種通用性的設計，靠自己去想，挺吃經驗的。
但是我們可以交給 AI：
請基於我提供的最新需求和已有的功能設計，幫我重新整理這個需求。
需求：
xxx需求描述xxx
目標是：
在不改變核心價值的前提下，將一次性的、具體的需求提煉為一個更通用、可複用的功能。
請你重點思考並說明：
- 這個需求真正想解決的“核心問題”是什麼
- 當前方案中，哪些設計是強綁定當前場景的
- 如果未來出現更多相似但不完全一樣的使用場景，哪些地方可能會受限
請給出一個更通用的需求表達方式，並簡要說明：
- 這個通用版本可以覆蓋哪些類型的場景
- 相比原需求，複雜度是否明顯增加
可以看到，用戶真正需要的，
是一種 能夠幫助理解非母語文案的能力 ，並不侷限於泰語這一種語言。
這正是這個定製化需求背後隱藏的關鍵點，
一旦抓住這一點，往往就能事半功倍。
AI 把可能出現的場景，幾乎都列成了一張矩陣。
連對應的 UI 交互草圖，也一併給了出來。
基於這套交互設計，現階段能覆蓋的大部分情況，基本都被兜住了。
最終優化的效果如下：
七、每一次費力修復的過程，都該變成你的知識寶藏
真正意識到要把經驗總結成知識卡片，是在做「熊貓論文」這個項目的時候。
那段時間，我反覆在做 Vibe Coding。
看着功能一個個被 AI 被拼出來，
我負責測試，再把結果丟回去，繼續糾錯，繼續改。
當時用的還是 Claude 3.7。
能力和現在的 Claude 4.5 Opus 比，差距很明顯。
一個稍微複雜的問題，經常要來回調一兩個小時。
連續這樣跑了一兩週之後，我突然覺得不太對。
我發現自己並不是在驅動 AI，更像是一個被流程推着走的執行者。
我沒有留下任何可複用的東西。只有一些勉強能跑的功能。
如果下次再遇到類似問題，我還是得從頭再來。
從那之後，我開始換做法。
只要遇到複雜問題，或者 花了很長時間才修完的 bug，
我都會讓 AI 幫我把過程提煉成筆記，或者整理成一張張知識卡片。
筆記卡片（適合複雜的 bug 修復）：
請回顧這次對話，提煉其中最關鍵的 xx 個問題，
並分別整理為 FAQ 形式的筆記卡片。
每張卡片請包含：
- 問題現象：當時具體遇到了什麼情況
- 根因說明：問題產生的核心原因
- 解決方式：最終採用的解決方案或判斷路徑
- 適用提示：在什麼場景下可能再次遇到，如何提前避免
要求：
- 使用 Markdown，結構清晰，便於快速掃讀
- 表達簡潔，偏總結而非過程複述
- 不引入對話中未出現的新結論技術教程（適合相對完整的技術教程、方案）:
請將上面的內容整理成一份「可讀性強的 Markdown 筆記」。
整理時請遵循以下原則：
- 以“希望把事情真正講清楚”為目標，而不是堆信息
- 重點說明“發生了什麼”和“為什麼這樣做”，再說明“怎麼做”
- 避免術語堆砌，必要時用直觀解釋或簡單類比輔助理解
筆記結構建議如下（可根據內容靈活調整）：
1. 背景與問題：事情從什麼情況開始，核心困擾是什麼
2. 現有做法：之前的處理方式，以及由此帶來的限制或風險
3. 新的思路：新的解決方向或方案，以及形成這一判斷的原因
4. 關鍵過程：按步驟梳理重要變化，必要時用流程圖或時序圖幫助理解
5. 總結與要點：本次經驗中值得記住的結論，以及可複用的判斷原則
輸出要求：
- 使用 Markdown，結構清晰、層次分明
- 語言自然、可順讀，適合作為教程或學習筆記
- 不引入未出現的新背景，不做過度推演或延展這些筆記和知識卡片，我都會沉澱在代碼項目裏，
同時再歸檔一份到自己的飛書知識庫。
放在代碼裏的目的，
是為了在修復問題或者開發新任務時，我都會提醒AI，在首句中加上：
請從項目中檢索是否遇到同樣的問題，xxxx只要命中一次，我就賺了。
八、把長期使用的上下文沉澱成通用文檔
不管是需求文檔、樣式規範、組件庫、技術棧、接口說明、FAQ 等等，
還是用來約束 AI 行為的 Cursor Rule、Claude.md，
它們都會在項目的某個階段，被當作上下文反覆交給 AI。
我的看法是：這些東西應該儘早準備，並且在開發過程中持續引用、持續優化。
這樣做，自然會形成正循環。
當你已經沉澱出一套相對穩定的通用文檔，
再把它們引入到 Cursor Rule、Claude.md 中，代碼質量往往會明顯提升，返工也會大幅減少。
下面的提示詞，就是我在一個真實商業項目中使用的 Cursor Rule。
如果你有需要，完全可以在此基礎上做修改和複用。
# Cursor Rule
## 角色與溝通
你是 Python 工程師，幫助技術基礎較弱的初中生完成項目開發。
- 用通俗語言解釋關鍵概念（不堆術語）
- 每次輸出儘量給出：要做什麼 + 為什麼 + 下一步怎麼用
- 遇到不確定點：先列出澄清問題或假設，再寫代碼（不要瞎補需求）
## 文檔即上下文（默認必須引用）
處理任何需求前，先閲讀並遵循這些文件（如不存在則創建）：
- README.md：項目目標、使用方式、參數/返回值示例
- docs/development_guide.md：技術棧、目錄結構、開發規範
- docs/requirements.md（如有）：需求與邊界
- docs/api.md（如有）：接口約定、鑑權、錯誤碼
- docs/faq.md（可選）：常見問題與約定
> 開發過程中持續更新上述文檔：新增功能/約定/坑點，必須同步補齊。
## 工作流程（強制順序）
1) 需求理解
- 用一句話複述需求目標
- 列出 1~3 個關鍵澄清點/假設（儘量少但必須）
- 選擇最簡單可行方案，避免過度設計
2) 實現
- 遵循 PEP8 + Type Hints + 清晰 docstring
- 模塊化、可維護；必要時加日誌與錯誤處理
- 嚴格貼合現有項目目錄與代碼風格（先讀代碼再擴展）
3) 測試（必須）
- 在 tests/ 下按類型放置 pytest 用例（只寫接口測試）
- 覆蓋率目標：100%（以關鍵分支為準，必要時補邊界與異常用例）
4) 接口與鑑權
- 若實現的是接口：根據功能判斷是否需要 JWT
- 接口行為以 docs/api.md 為準；若缺失則補充約定（含示例請求/響應）
5) 數據庫變更（如涉及）
- 在 alembic/versions/ 生成遷移文件
- 補充初始化數據（如需要）並確保遷移可執行
- 變更說明同步寫入 docs/development_guide.md
6) 收尾與覆盤（必須）
- 更新 README.md：新增功能的用法、配置、示例
- 更新 docs/development_guide.md：目錄/依賴/規範變化
- 簡要列出：本次改動影響範圍 + 後續可優化點（不長篇）
## 參考
默認以 Python 官方文檔為準：https://docs.python.org/在實際使用中，AI 有時候並不會完全嚴格地按照我們設定的全局規則來執行。
所以我們也要留意本地文檔的變更情況：
當新增了組件、調整了需求之後，
如果相關文檔還沒來得及更新，就可以主動提醒 AI，把這些文檔補齊和修正好。
這裏要強調一件事：需求文檔一定要及時更新。
在一個持續演進的項目裏， 需求文檔是除了代碼本身之外，
每個功能模塊最重要的上下文。
它能幫助 AI：
• 在修復局部 bug 時，分清哪些邏輯是刻意保留下來的，避免一不小心傷到整體設計 • 在新增功能時，理解模塊真正的職責，讓功能自然生長在該生長的位置上 • 在重構過程中，始終保有對用戶行為和業務約束的整體認知，而不是隻追求代碼層面的優雅
提示詞：
這部分功能 / 需求做了如上調整，可能是重構、改邏輯，或者加了點新能力。
請你幫我同步更新需求文檔，但注意一件事：
只寫“真的變了什麼”，不要擴寫。
在整理時，請重點關注：
- 新增了什麼能力（一句話能說清就別多說）
- 哪些原有需求已經不適用了，需要改或刪
- 這次變化有沒有影響到使用方式或邊界
請遵循這些原則：
- 只描述“對用戶或系統行為有影響的變化”
- 不補背景、不做長解釋、不寫實現細節
- 能刪就刪，能合併就合併
- 儘量不要補充細節代碼
目標：
讓這份文檔保持最小、最新、好讀，
看一眼就知道現在系統“到底是怎麼工作的”。九、極致的專注可以擊穿代碼
回頭看這一年用 AI 編程，我發現一個常被忽略的點： 我們怎麼對待“等結果”的時間。
後來我意識到，這些時間不是碎片，而是一段緩衝區。
我們也看到不少人推薦，在這段時間利用 Coding Agent 並行推進多個任務。
我也認真嘗試過一段時間，但最終還是很剋制地在使用它。
因為我發現，這樣對我來說，容易把思緒攪亂，效率反而下降。
相反，無論只是靜靜地看着屏幕、或者冥想一會，放空自己，又或者用來補充文檔，思考下一步怎麼做。
只要不過度攝入太多幹擾信息，我的效率反而就會更高。
這樣一來，等待不再是中斷，而變成了為下一步提前蓄力的過程。
這個方法不一定適用所有人，大家見仁見智吧。
十、從能用到順眼：我的 UI 優化心得
這是「熊貓論文」主界面的 UI 演變過程。
從一開始的慘不忍睹，到現在被不少人誇更加順眼了。
說實話，可能不是因為現在這版有多好看。
更多是因為 第一版太醜，一路用過來的用戶，突然覺得眼睛得到了解放。
很多人問我：UI 是怎麼慢慢改過來的？
第一步，最重要的，你必須要得先有一份設計規範。
因為你不是在做一個頁面。
登錄頁、落地頁、主頁面、充值頁、後台管理頁，
如果每一塊都長得不一樣，它就不像一個完整的系統。
很多人一開始會糾結：
“我不會設計怎麼辦？”
“我也說不清楚什麼叫好看，怎麼辦？”
做法其實很簡單。
輸入提示詞，再加上幾張自己覺得：
符合產品氣質、符合用戶審美 的參考圖，直接丟給 AI。
讓 AI 生成一份 初版設計規範。
你是一名大廠資深 UI 設計負責人。請基於我提供的多張參考圖，提煉其共性風格，
並輸出一份“可落地的 UI 設計規範（Style Guide）”，用於項目初期統一風格或重構對齊。
請不要逐張描述圖片，而是抽象出可執行的規則與設計 tokens。
如有不確定項，請給出“推薦默認值 + 可選範圍 + 使用場景”。
請按以下結構輸出（Markdown）：
## 0. 風格摘要（1屏讀完）
- 一句話風格定位（氣質關鍵詞）
- 3條最重要的設計原則（例如：剋制、對比明確、留白優先等）
- 適用場景與不適用場景
## 1. 設計變量（Design Tokens）
### 1.1 顏色系統
- 主色 / 輔助色 / 強調色
- 中性色階（背景/文字/邊框/分割線/禁用態）
- 狀態色（成功/警告/錯誤/信息）
- 漸變系統（如適用：方向、用途、禁用場景）
- 對比度與可訪問性建議（簡單規則即可）
### 1.2 字體與排版
- 字體取向與替代方案
- 字號體系（標題/正文/註釋/數據展示）
- 字重、行高、段落間距
- 文案語氣：按鈕/提示/錯誤信息的風格傾向（簡短/剋制/友好等）
### 1.3 間距與柵格（佈局基礎）
- 8px 或 4px 間距體系（建議選一種並說明理由）
- 柵格與容器：頁面最大寬度、左右邊距、分欄規則
- 圓角體系（xs/s/m/l 對應場景）
- 陰影與層級（Elevation：0/1/2/3 的含義與使用邊界）
- 分割線/描邊粗細規則
## 2. 佈局規範（頁面層）
- 信息層級：標題區/操作區/內容區/輔助信息區的組織方式
- 列表頁、詳情頁、表單頁的通用佈局骨架
- 留白策略：何處必須留白、何處可緊湊
- 空狀態/加載/錯誤態的版式原則
## 3. 組件規範（關鍵控件）
請至少覆蓋以下組件，並給出：默認樣式、狀態（default/hover/active/disabled/loading）、使用原則、避免事項。
- Button（主/次/文字/危險/圖標按鈕）
- Input / Textarea / Select / Search
- Form（必填標識、錯誤提示、校驗觸發時機）
- Tabs / Segmented / Breadcrumb（導航層級）
- Navbar / Sidebar / Menu（主導航：展開/摺疊、選中態）
- Card / Modal / Drawer（容器與彈層）
- Table（表頭、行高、密度檔位、空態）
- Tag / Badge / Tooltip / Popover
- Toast / Notification（反饋強度與出現位置）
## 4. 響應式與自適應
- 斷點建議（移動/平板/桌面/大屏）
- 字體與間距在不同斷點如何縮放
- 導航在不同屏幕下的變化策略（側邊欄/底部欄/抽屜）
- 表格、圖表、長文本在小屏的處理策略
## 5. 動效規範（Motion）
- 動效的總體原則（剋制/順滑/有目的）
- 過渡時長與節奏（快/中/慢的建議區間）
- 常見動效模式：頁面切換、彈層出現、列表加載、按鈕反饋
- 禁用動效的場景（性能/無障礙/減少干擾）
## 6. 落地建議（給開發/AI）
- 如何把規範轉為組件庫/樣式變量（tokens → theme → components）
- 最小落地路線：先統一哪些組件與頁面，收益最大
- 常見偏離點清單（最容易被做亂的3-5處）
輸出要求：
- Markdown 結構清晰，儘量“一屏一塊”，可直接複製進項目文檔
- 優先給“可執行規則”，少用抽象形容詞
- 不編造圖片中不存在的品牌元素；如果圖片不足以確定，明確標註“建議默認值/可選範圍”PS：如上提示詞微調後，同樣適用於將老項目的 UI 風格提煉成規範文檔，作為後續開發時 AI 的上下文。
第二步，驗證輸出效果。
這一步主要是為了先看看整體的輸出效果。
不管是直接用 Figma 生成初版框架，
還是直接上 Coding Agent，
在生成之後，我們都可以不斷把結果反饋給 AI，持續迭代整體的設計規範。
這裏其實有個小技巧：
先圍繞一個頁面做單點擊破，打磨出一個自己真正滿意的“樣板間”，
一邊用它來校準和迭代樣式規範。
等這套規範相對穩定了，再慢慢鋪開到全局。
第三步，把樣式規範寫進 Cursor Rule / Claude.md。
前面一些步驟也提到過。
為了保證未來多個頁面的風格統一，
我們可以把樣式規範寫進全局規則中，避免每次都需要提醒 AI。
最後再分享一些過程中的小技巧。
1、“截圖 + 局部圈選 + 期望效果”比純文字強一倍
一圖勝千文。
如果我們本身不是設計專業，很多 UI 問題其實很難用語言準確說明。
這時候直接截圖，把問題位置簡單標出來，再配上一小段說明，又快，也不容易被理解跑偏。
2、讓 AI 生成“多方案對比”，你只做選擇題
別讓 AI 直接給“最終方案”，而是讓它給 3 套風格變體，
每套明確差異點（更剋制/更活潑/更商務），你只選一個方向再深化。
這招特別適合“有審美，但不想自己從零畫”的路徑。
你是資深UI/UX設計師。我要做一個【XXX頁面類型】頁面，目標是【XXX目標】。
請先做兩件事：
1) 如果我沒提供方案：請你直接給出 3 套不同佈局方案（A/B/C），用幾句話描述每套的結構。
2) 然後對 A/B/C 做對比並給推薦。
對比維度固定為：
- 信息層級是否清晰
- 轉化效率/視覺焦點
- 響應式適配難度（桌面/平板/手機）
- 後續擴展性（運營位/活動/說明）
最後輸出：
- 推薦順序（例如 A > C > B）+ 一句話原因
- 推薦方案的 3 條可直接落地的微調建議3、UI 迭代別靠感覺：要及時總結和沉澱
很多時候，我們如果不是設計專業出身，可能對 UI 沒那麼敏感。
頁面能用、看着順眼了，就容易“先這樣吧”，然後放一邊不管。
但我後來發現，UI 最有價值的不是某一版改得好看，
而是能不能把優秀設計沉澱下來，變成下次直接複用的標準。
別忽略這些細微的改動。
每次遇到不錯的設計，我都會習慣順手讓 AI 做一段總結：
我會提供一張“做對的頁面”截圖（可選：再提供一張優化前對比圖）。
請你幫我把這次 UI 優化沉澱成“樣板卡片”，用於以後直接照搬。
請輸出 4 部分（Markdown）：
1. 一句話規則（最重要）
- 用一句話說明：為什麼它更好看/更好用（要具體、可執行，避免空泛形容詞）
2. 關鍵改變點（3條以內）
- 這次最關鍵的 1~3 個變化是什麼（例如：信息層級、留白節奏、按鈕主次、對比度等）
3. 照搬要點（5條以內）
- 以後做新頁面時，哪些點必須照這個樣板做（寫成清單，能直接抄）
4. 易踩坑提醒（2條）
- 最容易被做回去/做亂的地方是什麼，以及一句話提醒怎麼避免
要求：
- 簡短，適合和截圖一起存進“UI 樣板庫”
- 不逐圖描述細節，不做長篇解釋十一、總結
一年前的我，始終以為，
AI 編程的難點在於"模型不夠聰明"。
但現在我明白了，真正的難點從來不是工具，而是我們自己：
• 我們習慣了模糊的表達，卻要學會精確的描述 • 我們習慣了一次到位，卻要學會分步推進 • 我們習慣了憑感覺判斷，卻要學會建立標準和規範
這些技巧，表面上是在教你"怎麼用AI"，但本質上是在重新訓練我們的思維方式：
如何把腦子裏模糊的想法，拆解成可執行的步驟；
如何把一次性的經驗，沉澱成可複用的知識；
如何在不確定性中，建立確定性的標準。
這些能力，在任何場景下都能發揮作用。
所以，AI編程教會我們的，不只是寫代碼，而是把混沌變成秩序，把想法落成系統。
最後，祝你 2026 在 AI 編程的路上，少踩坑，多收穫。
我是 🐼熊貓Jay，我們下次再見。
如果覺得不錯，隨手點個贊、在看、轉發三連吧。
如果想第一時間收到推送，也可以給我個星標 ⭐
謝謝你看我的文章 ~