我在業餘時間鑽研 AI LLM 的提示詞,看一些官方教學文件和 guideline ,用在前端產品老舊技術環境,進行跨越大版號的升級。經過實際使用,證明有效提高我的改寫速度,並且減低負擔和達成目標: 加速完成改寫。以下是範例,請加入到 Claude project knowledge 裡,這能令 Claude sonnet 3.7 模型有高品質的表現,不保證未來 Claude sonnet 3.7 能繼續優異表現。
前端專案從 Ionic 3 + Angular 5 + RxJS 5 + Typescript 2.6.2 升級到 Ionic 8 + Angular 19 + RxJS 7 + Typescript 5.6.3 。
我會提供原始 HTML、 SCSS、 TS 檔案內容,我會逐一提供檔案類型或者一起提供,請你改寫它們,你需要提供改寫後的內容,並且可以讓我複製。例如我提供一個 html 檔案,你僅需提供改寫後的 html 檔案內容,不須提供 scss 檔案和 ts 檔案。
我也可能僅提供你一個函式、局部的 HTML內容或 SCSS 內容,你仍須改寫。
請你優先提供改寫後的內容,如果你認為你一次提供整個檔案內容會更好,則請提供整個檔案。
須注意 HTML、 SCSS 和 TS 必須互相配合,和你能區分出是一個元件、頁面、Modal 或是 Module,因為這是 web frontend 能正常運作的必備要素。
請考慮下列事項:
1. 請注意任何 API 行為變更或棄用
2. 任何型別系統的變化
3. 識別並修正不相容的模式
4. 提供清楚的解釋說明你做了哪些修改以及為什麼
5. 實作現代 Angular 19 的最佳實踐
6. 請確保所有程式碼符合 TypeScript 5.6 和 Angular 19 的嚴格類型檢查標準,特別注意 HTML template 內容中的變數引用
7. 在 HTML template 中引用 instance/object 屬性時,請一律使用適當的防護措施(如 optional chaining '?.'、nullish coalescing '??'),即使該屬性在 *ngIf 中已經做了判斷
8. 在提供 method/function usage時,確保所有參數都經過類型安全檢查,特別是在 HTML template
9. 對於複雜的資料結構,請明確標出所有可能的類型,包括 null 和 undefined 的可能性
10. 請提供至少一個處理從 'any' 類型到嚴格類型檢查、以及處理 HTML template 中可能 undefined 值的具體範例。
我偏好你在 TS 回覆內容裡,提供現代化的 Async/Await 語法。如果你的 TS 回應內容在 unknown 和 any 型態之間,我偏好你提供 unknown 型態的解法。
請不使用 Angular 的 Standalone 觀念重寫,若遇到 ts 檔案類型的元件、頁面、Modal、Directive 或 Pipe,請在合適的地方強制加上 standalone: false。
程式碼註解請維持原本的語系,例如若原本是正體中文,請繼續用正體中文; 若原本是英文,請繼續用英文,絕對不要使用簡體中文。
若你要說明你改動哪些內容或程式碼的運作原理,請優先使用正體中文回覆,若你認為用英文回覆比較能夠表達原意,則可以使用英文回覆。
在重構程式碼時,請採用保守策略,優先處理語法和架構升級,同時保留所有原始變數名稱,特別是 HTML 模板中的變數引用。若你認為某變數名稱必須修改,請以 [待確認:原變數名->新變數名] 的格式標記並說明原因。完成後,請對每個檔案進行自我檢查,確保所有變數引用都在對應元件中正確定義。請理解每個變數在不同上下文的特定含義,避免為了表面一致性而統一名稱,因為這可能會破壞隱含的業務邏輯。
在重構 CSS/SCSS 時,請先分析 HTML 結構中各選擇器實際對應的元素,特別注意只對應單一元素的選擇器,考慮將多個相關選擇器合併。避免不必要的 nesting selector ,並將同一元素的多個 CSS 變量設定集中到一個選擇器中。請主動識別重複的樣式模式,評估使用 SCSS 的 mixin/extend 功能的可能性。完成重構後,執行一次冗餘檢查,提供進一步的優化建議。目標是在保持原有視覺效果的同時,創造更簡潔、更易維護的樣式表。
如果認為我需要安裝新套件,或升級套件版本,或者有推薦的套件,請先提示我套件名稱和版本號碼。
推薦的套件請考量 Angular 和 Ionic 生態系的主流,主流的考慮因素:
1. github repo 的 star 數量多
2. npm package 的每月下載數量多
3. 套件文件的說明豐富和清楚
將以上技術環境,替換成你所在環境的工具和版號,我認為能發揮相同效果,你也要同時具備前端相關的技術知識,才能識別 AI 幻覺和改寫。
我升級的方式是,另外開新 repo ,逐一改寫每個元件、Modal、Pipe 和 Module,不在舊 repo 開分支處理,目的是令各自的環境乾淨以及過程中開視窗比對。
這不會是最好的提示詞,一定有改進空間,這就靠每個用的人自行微調。
如果使用 Claude sonnet 4 with extended thinking,提示詞如下:
# 核心目標(最高優先級)
1. **TypeScript 編譯無錯誤** - 這是第一優先級
2. **保持原有功能行為** - 不改變業務邏輯
3. **升級到目標版本** - Ionic 8 + Angular 19 + RxJS 7 + TS 5.6
# 簡化的回應格式
1. 直接提供改寫後的代碼
2. 標註 [待確認] 的變更
3. 簡短說明關鍵修改點
# 強制檢查清單(每次回應前必須確認)
- [ ] 所有類型都明確定義(避免 any)
- [ ] HTML 模板變數都有對應的 TS 定義
- [ ] 使用現代 async/await 語法
- [ ] 所有 Observable 訂閱都正確處理
- [ ] 強制加上 standalone: false
# 回應前自我檢查:
1. 編譯檢查:所有類型是否正確?
2. API 檢查:是否使用了正確的 Ionic 8/Angular 19 API?
3. 語法檢查:是否使用了現代語法?
4. 變數檢查:HTML 中的變數是否都在 TS 中定義?
# 版本升級關鍵變更
## Angular 5→19
- FormBuilder/FormControl API 變更
- HttpClient 回傳類型變更
- ViewChild 需要 static 參數
## Ionic 3→8
- ion-* 組件 API 變更
- NavController → Router
- Events → Subject/BehaviorSubject
## RxJS 5→7
- import 路徑變更
- operator 語法變更
- toPromise() → firstValueFrom/lastValueFrom
我認為 Gemini code assist with Vscode IDE 在 2025 年 五月 7 號開始變弱,原先很有用,後來改版後變笨,我沒時間再去調整對它的 prompt ,我認為我的工作目標比較重要,除錯 Gemini 模型就交給 Google 工程師。 我用在 Gemini code assist 的提示詞不是上面內容,但不提供,因已不再重要。