diff --git a/docs/ai/01_prompt.md b/docs/ai/01_prompt.md
new file mode 100644
index 0000000..d1aeaf9
--- /dev/null
+++ b/docs/ai/01_prompt.md
@@ -0,0 +1,275 @@
+---
+title: Prompt Engineering
+sidebar_label: Prompt Engineering
+keywords: ["Prompt"]
+description: "提示工程 (Prompt Engineering) 如何影響 LLM 理解使用者輸入的問題"
+sidebar_position: 1
+tags: ["Prompt"]
+---
+
+## 提示工程 (Prompt Engineering)
+
+目前的 LLM 本質上還是機率模型,所以要如何透過所謂的提示詞 (Prompt),提供模型我們想要回覆的預期方向,讓模型能夠猜的更準,變成使用AI的第一個要掌握的重點。
+
+當我們將觀念從傳統的 **指令** 改為 **提示詞**,自然也就衍生出常見的 Pattern。
+
+## Pattern
+
+### 角色提示
+
+- 定義:賦予一個專家角色,模型會優先使用與該角色相關的背景知識、語氣、和思考模式。
+- 範例:
+ > 你是一位擁有 20 年經驗的美食作家,擅長將複雜概念的味覺感受轉化成文字描述。
+
+### 上下文提示
+- 定義:完成這個任務/目標,模型需要知道的基本上下文(脈絡)。
+- 範例:
+ > 這份報告的目標讀者是沒有咖啡豆背景知識的潛在投資者,所以請避免使用過多專業術語。報告的重點應放在市場規模、主要參與者和潛在風險上。
+
+### 限制提示
+
+- 定義:避免模型過於發散,明確規定輸出的風格、語氣、篇幅,甚至是格式(ex: markdown, xml...)。
+- 範例:
+ > 正向: 請用一種熱情、活潑、充滿鼓勵的語氣來撰寫這封歡迎新員工的郵件,全文不得超過 100 字。
+ > 反向: 請為我比較 A 和 B 兩款手機的優缺點。請**不要考慮價格**因素,只專注於**硬體規格**和**用戶體驗**。
+
+### 範例提示
+
+- 定義:透過小且精確的範例,讓模型直接當作參考依據。
+- 範例:
+ > 請將最終結果以下方形式呈現:
+ > 品項:xxx咖啡豆
+ > 產地:來自衣索比亞的單一產區。
+ > 特點:豐富的花香和柑橘風味。
+
+### 翻轉提示
+
+- 定義:當你自己也不完全清楚完成任務需要哪些資訊時,可以利用這個模式,讓 AI 扮演專家的角色,來引導您提供必要的資
+- 範例:
+ > 你是一位資深的商業分析師(Business Analyst)。擅長引導客戶進行需求探索。我們的共同目標是透過一系列的對話討論,為一個新的商業提案做出分析報告。
+
+## 系統提示詞 vs 使用者提示詞
+
+### 系統提示詞
+定義 AI 對話的核心,包含角色、個性、行為準則和長期目標,且會在整個任務中持續生效。
+
+:::tip
+你是一位名叫「數學小老師」的 AI 家教。
+你的任務是:
+1. 只回答國小六年級以下的數學問題。
+2. 如果問題超出範圍,要禮貌地拒絕,並說明你的專長是國小數學。
+3. 解釋問題時,要使用生動的比喻,讓小朋友容易理解。
+4. 絕對不能直接給出答案,必須先引導小朋友思考。
+:::
+
+### 使用者提示詞
+使用者想要跟互動的AI(不論是否包含設定好角色),發問的內容。
+
+## 如何開發提示詞
+
+由於模型本身是機率模型,所以開發提示詞的過程中,一定少不了多次的嘗試與持續調整,甚至不同版本的模型,各自對應的提示詞也會有所不同。
+
+只能通過不斷的試驗,逐漸優化提示,觀察輸出結果,才能做出一個讓自己滿意的提示詞。
+
+1. 避免全方位的角色
+ > 越全面的角色,設定的內容越多越複雜,也更容易失焦,反而傾向於攏統描述,不如針對各項專精的項目,謹慎地設定好每個角色分別應該具備的能力與期待完成的目標,才能更有方向的去調教設定,優化產生的品質。
+2. 持續優化、反覆實驗
+ > 相同的提示詞,在同一個模型執行多次也會有不同的結果,不同模型間的效果落差甚至會更明顯,只有針對不同的場景,反覆實驗,直到能夠在主要使用的模型上,取得不錯的結果。
+3. 不必過於追求完美
+ > 提示工程雖然有指引,但並沒有標準答案,有些提示詞也許第一次問答的結果不夠好,但是根據第一次的回答作為 context 的一部分,往後展開,也許就會出現想要的內容。
+4. Deep Domain Knowledge
+ > 只有當領域知識足夠深厚,才能夠提供更深刻的關鍵詞、Context,讓模型更精準找到你需求的內容,甚至基於這些內容,產生更深刻的結論或是推斷,讓你去做更深的思考。
+5. 清晰 != 囉嗦。
+ > 有時候,一個精準的技術術語(關鍵字)比一段冗長的描述更有效。關鍵在於找到「恰到好處」的資訊量,—既能完整傳達意圖,又不會引入不必要的噪音。
+6. 限制
+ > 避免模型過於發散,如同前面說到的,我們做提示的目的,就是希望能夠讓模型**猜得準**,所以透過限制,明確告訴模型不能包含哪些部分,也會是很好的引導。
+
+## Key Concept
+
+### In-Context Learning (ICL)
+
+模型無需更新自身參數(即無需重新訓練),僅透過分析提示中提供的範例,就能學會並執行新任務。
+**表示當模型大到一個程度後,已經展現理解和推理能力。**
+
+
+
+### Zero-shot Prompting
+
+- 定義: 不提供任何任務範例,直接要求模型根據其龐大的預訓練知識完成任務。
+- 運作原理: 模型對自然語言指令的強大理解能力,以及其內部知識庫中已經存在的相關模式。
+- 適用時機:
+ 1. 通用任務: 如翻譯、常識問答等模型在訓練中已大量接觸的任務。
+ 2. 簡單指令: 任務邏輯簡單直接,沒有複雜的格式要求。
+
+:::info
+Input: 東京位於哪一個國家?
+A: 日本
+(因為這個知識已在模型預訓練包含)
+
+---
+Q:
+
+將問題描述的類別名稱設定為「高」、「中」或「低」。僅預測最後一個問題的類別名稱。簡短說明選擇該類別名稱的原因。
+
+Class name: High
+說明:對企業成本影響高、影響眾多使用者或兩者皆是的問題。
+Class name: Medium
+描述:介於高與低之間的問題。
+Class name: Low
+描述:對少數使用者有影響、沒有高昂的商業成本,或兩者皆有的問題。
+
+問題:使用者回報無法上傳檔案。
+
+A:
+
+Class: High
+Description: 此問題被視為高嚴重性,因為它影響了許多使用者且業務成本高昂。無法上傳檔案可能會阻止使用者完成其任務,進而導致延遲和生產力下降。此外,此問題可能會影響多個部門或團隊,進一步增加業務成本。
+(透過模型本身育訓練的理解能力,幫助回答問題)
+(example from: https://www.ibm.com/think/topics/zero-shot-prompting)
+:::
+
+### Few-shot Prompting
+
+- 定義: 提供少數(通常 1-5 個)範例,讓模型透過範例來歸納出你想要的輸出。
+- 運作原理: 模型透過分析您提供的輸入/輸出對,歸納出任務的潛在規則、邏輯、格式或風格,並將其應用到新的輸入上。
+- 適用時機:
+ 1. 特定格式要求:當您需要模型輸出特定結構(如特定風格的程式碼註解)時。
+ 2. 複雜分類任務:當分類標準比較微妙,難以用語言完全描述時(如判斷用戶評論的意圖是「產品諮詢」、「售後投訴」還是「功能建議」)。
+
+:::tip
+好的範例本身應基本遵循以下原則:
+
+- 清晰 + 準確
+- 一致性:所有範例的格式和邏輯應保持高度一致,避免讓模型產生困惑。
+- 覆蓋性:應盡可能涵蓋任務的不同情況。
+ (例如,在做主觀評價分析時,最好包含 **`正面`**、**`負面`** 以及 **`中性`** 評論。)
+- 順序:將最複雜的範例放在最後。
+:::
+
+### Chain-of-Thought (CoT)
+
+CoT 實際上是強迫模型將其隱性的思考過程,轉化為顯性可追蹤的文字步驟。
+這不僅僅是為了讓我們看到它的思考過程,更重要的是,這個「寫下來」的動作本身,就能幫助模型更穩定、更合乎邏輯地進行推理,減少了在複雜問題上「一步錯,步步錯」的情況。
+
+- 定義: **`Let's think step by step.`** (**`請一步一步地思考。`**)
+- 運作原理:
+ > CoT 將一個複雜的大問題,分解成一系列更小的中間步驟。模型在每一步只需要專注於一個子問題,從而降低了出錯的機率。
+ > 生成的每一步推理,都為後續的步驟提供了完整的 Context,確保邏輯鏈的連貫性。
+ > 類似於人類在解決難題時進行演算的過程。將思考過程外化,有助於整理思路和發現潛在的錯誤。
+
+:::tip
+如果覺得 `Let's think step by step.` 效果不如預期,可能是模型自動產生的步驟並不正確。
+可以試著提供手動 CoT 的簡單範例,觀察是否會有所改善。
+:::
+
+### Self-Consistency
+
+Self-Consistency 是 CoT 的一個延伸,簡單說,就是讓模型採樣多個不同的推理路徑,然後從多個產生結果中,選出最一致的答案。
+
+- 運作原理:
+ 1. 多路徑生成:針對同一個問題,多次運行 CoT 提示。由於生成過程帶有隨機性,每次生成的推理路徑都會略有不同。
+ 2. 答案投票:收集所有這些不同推理路徑得出的最終答案。
+ 3. 選擇最優解:選擇在這些答案中出現次數最多的那個,作為最終的可信的答案。
+- 優勢
+ 一個複雜問題可能有多種解法,即使某些解法在中間步驟出現了小錯誤,但只要大部分的推理路徑都能指向同一個答案,那麼這個答案的可信度就非常高。
+ 這種類似「群體智慧」的方法,極大地增強了結果的穩定性。
+
+### Tree of Thoughts (ToT)
+
+CoT 的思考是線性單向的,一旦某個環節出錯,整個後面就可能導致連環錯。
+
+- 運作原理:
+ 1. 分解步驟:像 CoT 一樣,將問題分解成多個思考步驟。
+ 2. 多路徑探索:在**每一個**步驟上,ToT 都會引導模型生成多個可能的「**下一步**」或「**中間解**」。這就像從樹的同一個節點,長出了多個分枝。
+ 3. 評估:ToT 會引導模型對每個分枝的「好壞」或「前景」進行自我評估,判斷有沒有價值。
+ 4. 剪枝與回溯:模型會「剪掉」那些被評估為沒有前途的分枝,並集中資源在更有希望的路徑上繼續探索。如果所有路徑都走不通,它甚至可以「回溯」到上一個節點,嘗試其他可能性。
+- 優勢
+ 當一個任務需要綜合評估多種方案時,使用ToT就能展現出優勢,這也是 Agent 收到使用者任務,制定相關計畫的核心能力。
+
+### Retrieval-Augmented Generation (RAG)
+
+檢索增強生成,是目前將 LLM 應用於企業知識庫最主流、最重要的技術框架。
+
+- 運作原理:
+ 1. 查詢:您的問題首先被發送到一個「檢索器 (Retriever)」。
+ 2. 檢索:檢索器會將問題轉換為向量,然後在公司的「知識庫」(一個預先被處理和向量化的文件資料庫,如 Confluence、Google Drive 裡的文件)中,搜尋語義上最相關的文本片段(Chunks)。
+ 3. 增強 (Augment):檢索器將找到的這些相關文本片段,連同您最初的問題,一起「打包」成一個更豐富、包含更多上下文的提示。
+ 4. 生成 (Generate):這個被「增強」過的提示,最終被發送給 LLM。
+ 5. 回答:LLM 根據您提供的即時、準確的上下文,生成一個有理有據的回答,而不是依賴其可能已經過時的內部知識。
+
+### ReAct (Reason + Act)
+
+LLM 的知識被凍結在它們的訓練數據中,它們無法獲取即時資訊,也無法執行計算之外的動作。**ReAct** 徹底改變了這一點,它讓模型成為了一個能夠使用「工具」的智慧代理 (Agent)。
+
+- 運作原理: ReAct 的核心是一個「思考 -> 行動 -> 觀察」的循環。
+ 1. Reason:模型首先分析任務,並判斷是否需要使用外部工具。
+ 如果需要,它會決定使用哪個工具,以及如何使用(即生成呼叫所需的程式碼或指令)。
+ 3. Act:系統執行模型生成的指令,調用外部工具。
+ 這些工具可以是:
+ - 搜尋引擎 API:用於查詢即時資訊(如今天的天氣、某支股票的最新價格)。
+ - 計算機/程式碼解釋器:用於執行精確的數學計算或程式碼。
+ - 資料庫查詢 API:用於從企業內部資料庫中獲取數據。
+ - 任何其他 API:如訂票、發送郵件等。
+ 4. 觀察:接收 Act 返回的結果。
+ 5. 再次思考:模型將觀察到的新資訊,整合到 Context 中,然後進行下一步的思考,決定是繼續使用工具,還是已經擁有足夠資訊來回答最終問題。
+
+ReAct 框架極大地擴展了 LLM 的能力邊界,使其轉變為一個能夠動手解決現實世界問題的「數位助理」。
+(已見 AI Agents 的雛形)
+
+---
+
+## Timeline
+
+```mermaid
+timeline
+ title LLM
+
+ section 2017
+ Google
Transformer : Attention Is All You Need
+
+ section 2020
+ OpenAI
GPT 3 : Language Models are Few-Shot Learners
+ Meta
RAG : Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks
+```
+```mermaid
+timeline
+ title LLM
+
+ section 2022
+ Google
CoT : Chain-of-Thought Prompting Elicits Reasoning in Large Language Models
+ ReAct : Synergizing Reasoning and Acting in Language Models
+
+ section 2023
+ ToT : Tree of Thoughts - Deliberate Problem Solving with Large Language Models
+```
+
+```mermaid
+timeline
+ title LLM
+
+ section 2024
+ Anthropic: Model Context Protocol
+
+ section 2025
+ Github : Copilot
Agent Mode
+ Google : Gemini Cli
+ OpenAI : Codex
+
+```
+
+## Reference
+[Prompt Engineering Guide](https://www.promptingguide.ai)
+[Learn Prompting](https://learnprompting.org/docs/introduction)
+[openai-cookbook](https://cookbook.openai.com)
+[Gemini Api Prompt Strategy](https://ai.google.dev/gemini-api/docs/prompting-strategies)
+[Digital Ocean Prompt Tutorials](https://www.digitalocean.com/community/tutorials?q=prompt)
+[RAG Best Practices](https://www.kapa.ai/blog/rag-best-practices)
+[zero-shot-prompting](https://www.ibm.com/think/topics/zero-shot-prompting)
+
+## Paper
+[Attention Is All You Need](https://arxiv.org/abs/1706.03762)
+[Language Models are Few-Shot Learners](https://arxiv.org/abs/2005.14165)
+[RAG : Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks](https://arxiv.org/abs/2005.11401)
+[Chain-of-Thought (CoT)](https://arxiv.org/abs/2201.11903)
+[ReAct](https://arxiv.org/abs/2210.03629)
+[Tree of Thoughts (ToT)](https://arxiv.org/abs/2305.10601)
diff --git a/docs/ai/img/2025-11-16-15-21-09.png b/docs/ai/img/2025-11-16-15-21-09.png
new file mode 100644
index 0000000..bf7df54
Binary files /dev/null and b/docs/ai/img/2025-11-16-15-21-09.png differ