提示詞工程絕不是「一次性的隨手聊天」，而是一個需要不斷調整、比較與優化的科學實驗過程。就像化學家做實驗必須寫「實驗日誌」一樣，每次你改動了一個關鍵字、換了一個模型，或是調高了 Temperature，都應該把「用了什麼 Prompt、設定了什麼參數、產出什麼結果、成效好不好（OK / NOT OK）」詳細記錄在一張標準表格（例如 Google Sheet）中。

當你隔了幾天要回頭重看、或是模型版本升級、亦或是要把 Prompt 交給軟體工程師寫進系統時，才不會忘記當初為什麼這樣寫，也能一目瞭然地挑選出歷史表現最佳的版本。

🎯 核心重點

1. 提示詞工程的迭代本質（Iterative process）：
   • 提示詞在最終進入正式程式碼庫（Codebase）之前，通常會經歷多次修改與嘗試。若沒有系統化地追蹤，人類很容易在短短幾天後忘記不同版本之間的細微差異。
2. 提示詞文件紀錄的範本（Documentation Template）：
   • 教材強烈建議使用表格（如 Google Sheets）建立紀錄文件，核心欄位應包含：
     • Name & Version：提示詞名稱與版本號（如1_1_movie_classification_v2）。
     • Goal：該次實驗嘗試的核心目標。
     • Model：採用的模型名稱與版本（如gemini-pro）。
     • Configurations：Temperature、Token Limit、Top-K、Top-P參數設定。
     • Prompt：完整的提示詞文本。
     • Output：模型的實際輸出結果。
     • Evaluation & Feedback：成果評估標籤（如OK/NOT OK/SOMETIMES OK）與文字反饋。
     • Link：在 Vertex AI Studio 中儲存的提示詞超連結（方便一鍵重新執行驗證）。
3. RAG 系統的額外紀錄需求：
   • 若應用於檢索增強生成（RAG）系統，還需額外捕捉影響提示詞內容的特定資訊，例如用戶查詢（Query）、Chunk 切塊設定與檢索到的內容片段。
4. 程式碼庫（Codebase）維護最佳實踐：
   • 當 Prompt 調優至滿意狀態後，導入系統時應將 Prompt 儲存在獨立的文件中（與程式碼分離），以利維護。
   • 正式操作時，應建立自動化測試與評估流程（Automated tests & evaluation procedures），以掌握 Prompt 在實際任務中的一般化表現。

💡 實際例子（提示詞實驗記錄表）

以下為教材推薦使用的標準文件範本的例子：

❌ 常見錯誤

1. 憑感覺測試，缺乏參數與版本的記錄：試了十幾次之後，忘了當初輸出最完美的那個版本究竟設定了多少 Temperature 或使用了什麼具體字眼。
2. 將 Prompt 直接硬編碼（Hardcoding）在主程式碼深處：沒有將 Prompt 抽離成獨立的模板檔案，導致後續 Prompt 工程師要微調時，必須改動軟體核心程式碼。
3. 模型升級後沒有重新測試與紀錄：當基底模型升級或更新時，舊的 Prompt 表現可能會發生變化，必須重新評估並更新紀錄。

📖 來源依據

內容依據《Prompt Engineering》教材：

• 提示詞迭代特性與記錄重要性：第 6 頁、第 14 頁、第 64–65 頁
• 標準文件化記錄模板（Table 21）與欄位細節：第 65–66 頁
• RAG 額外記錄欄位與 Codebase 檔案分離：第 65 頁
• 模型更新與適應性測試：第 60 頁

📝 3 題理解測驗

第 1 題（單選題） 關於「提示詞文件化紀錄（Document Prompt Attempts）」的最佳實踐，下列何者描述最為正確？ (A) 只要 Prompt 測試成功就可以直接忘掉過程，不需要記錄中間失敗的嘗試。 (B) 建議使用表格詳細紀錄 Prompt 名稱、目標、模型版本、 Temperature 等配置參數以及輸出成果（OK/NOT OK），以便未來除錯與版本比對。 (C) 提示詞記錄只需要存下文字本身，模型配置參數（如 Temperature, Top-P）並不影響結果，所以不需要記錄。 (D) Prompt 記錄表格建立後就不能修改，否則會破壞模型的預測。

第 2 題（單選題） 當我們經過多次實驗，終於調優出一套非常優秀的 Prompt，準備將其正式整合進軟體系統的程式碼庫（Codebase）時，教材推薦的最佳架構做法是什麼？ (A) 將 Prompt 直接以硬編碼（Hardcode）方式長段寫在核心程式碼的 Function 內部。 (B) 將 Prompt 儲存於與程式碼分離的獨立檔案中，以利未來獨立維護與自動化測試。 (C) 把 Prompt 貼在 Slack 聊天室，不需要儲存進 Codebase。 (D) 將 Temperature 刪除以縮短程式碼長度。

第 3 題（應用簡答題） 請列出在一份標準的「提示詞實驗紀錄表格」中，除了「Prompt 完整文字」與「Output 輸出結果」以外，至少 3 個 必須記錄的關鍵參數或欄位名稱。

測驗答案：（參考）
第1題：B。 建議使用表格詳細紀錄 Prompt 名稱、目標、模型版本、 Temperature 等配置參數以及輸出成果（OK/NOT OK），以便未來除錯與版本比對。
第2題：B 。將 Prompt 儲存於與程式碼分離的獨立檔案中，以利未來獨立維護與自動化測試。 。
第3題：
欄位名稱：應記錄的訊息。

Name & Version：提示詞名稱與版本號（如 1_1_movie_classification_v2）。
Goal：該次實驗嘗試的核心目標。
Model：採用的模型名稱與版本（如 gemini-pro）。
Configurations：Temperature、Token Limit、Top-K、Top-P 參數設定。
Prompt：完整的提示詞文本。
Output：模型的實際輸出結果。
Evaluation & Feedback：成果評估標籤（如 OK / NOT OK / SOMETIMES OK）與文字反饋。
Link：在 Vertex AI Studio 中儲存的提示詞超連結（方便一鍵重新執行驗證）。

謝謝您與我一起完成了從底層原理、參數配置、基礎與進階提示技術、代理（Agent）邏輯到工程化最佳實踐與記錄文件的完整學習歷程！

學習里程碑總覽：

1. 單元 1：LLM 運作原理（Token 預測引擎）與 Prompt 工程定義
2. 單元 2：輸出配置參數（Temperature, Top-K, Top-P, Output Length）
3. 單元 3：基礎提示技術（Zero-shot, One-shot, Few-shot）
4. 單元 4：結構化提示（System, Role, Contextual Prompting）
5. 單元 5：邏輯推理提示（Step-back Prompting, Chain of Thought - CoT）
6. 單元 6：多路探索與代理技術（Self-consistency, Tree of Thoughts - ToT, ReAct）
7. 單元 7：提示詞設計最佳實踐（正向指令, 簡潔設計, 變數使用）
8. 單元 8：結構化資料處理（JSON 輸出/輸入 Schema, JSON Repair）
9. 單元 9：自動化與程式提示（APE 自動化生成, Code Prompting）
10. 單元 10：提示詞實驗操作與文件紀錄範本

最後，恭喜您已經具備了專業 Prompt 工程師的核心知識與實務思維！

註1：
這「學習系列」的文章，是記錄自己與AI一起探索知識的過程，也是我將AI做為私人家教的一項實驗。對於如何藉由Ai輔助自我學習，請參考這篇：
https://blog.udn.com/tku_89056/192561353
https://goldenbird-willy.blogspot.com/2026/09/gemini-notebook-ai.html

註2：
學習教材：《Prompt Engineering》
本書探討了提示工程的核心概念、多種進階技巧、以及最佳實務（use cases）。內容涵蓋如何設定大型語言模型的輸出長度與取樣參數，並且介紹零樣本、少樣本、角色扮演、思維鏈、以及如何結合外部工具的推理與行動等實用策略。此外，本書也示範了如何利用人工智慧來編寫、解釋、翻譯和除錯程式碼。最後，本書提供了多項專業的建議，例如簡化提示設計、優先使用正面指令、利用如JSON的結構化格式、以及落實詳盡的版本記錄與迭代。
本書作者Lee Boonstra是一名人工智慧軟體工程師、技術主管和系統架構師，在谷歌全球首席技術官辦公室（OCTO）、應用創新工廠等擁有10年以上的資歷。
免費下載：https://www.kaggle.com/whitepaper-prompt-engineering