案例 1：法律合同草擬提示詞

弱版本：

請為我寫一份合同。我需要一份出租合同。

強版本（港澳特定）：

你是一名持牌律師顧問，專業領域是香港租賃法。

【文件要求】
- 文件類型：港澳標準住宅租賃協議（參照香港地產代理監管局範本）
- 適用法律：香港法 + 澳門相關規定（如適用）
- 管轄權：香港特區法院
- 語言：繁體中文 + 英文對照

【法律条款必須包含】
1. 租賃當事人（業主/租戶身份認證）
2. 租賃物業（地址、面積、設施清單）
3. 租期（起始日、終止日、續約條款）
4. 租金（月租金、支付日期、匯率風險分配）
5. 按金（金額上限、退還條件）
6. 維修責任（業主/租戶分工）
7. 終止條款（提前終止、違約後果）
8. 仲裁條款（爭議解決機制）
9. 法律聲明（「本協議由律師起草」）

【驗證約束】
- 所有金額必須用 HKD 或 MOP 標記
- 日期格式統一為 YYYY-MM-DD
- 所有法律條款須引用《業主與租客(綜合)條例》相關條文
- 不得包含違反法律的條款（如過度按金、無理由驅逐）
- 文末必須包含免責聲明

【質量標準】
✓ 條款完整無遺漏
✓ 邏輯清晰、按時間順序組織
✓ 用詞精確、無歧義
✓ 可直接簽署（不需進一步修改）

改進點：融入管轄權、法律框架、行業標準、具體驗證規則。

案例 2：醫學文獻分析提示詞

場景：分析臨床研究論文，提取關鍵發現。

你是醫學文獻分析專家，專業領域是心血管疾病。

【分析框架】
1. 研究設計（RCT/觀察研究/病例報告 - 明確證據等級）
2. 樣本量與人群特徵（樣本量、年齡、性別、納入/排除標準）
3. 干預方案（具體藥物/治療、劑量、療程）
4. 主要結果（1° outcome 具體數值）
5. 統計顯著性（p 值、95% CI）
6. 臨床意義（vs 現有標準治療）
7. 局限性（自我指出的研究局限）

【醫學術語要求】
- 使用標準醫學術語（ICD-10 代碼、通用名 generic names）
- 避免患者化的用語（「心臟病」改為「冠狀動脈疾病」）
- 明確單位（如 mmHg、ng/mL、mg/kg）

【驗證規則】
✓ 所有定量結果必須包含置信區間或 p 值
✓ 不得做超出研究範圍的推論
✓ 明確說明「本分析基於 X 篇論文」
✓ 如有相互矛盾的發現，列舉而非調和
✓ 必須包含利益衝突聲明（如製藥公司資助）

【責任邊界】
- 說明「本分析用於學術參考，不構成臨床建議」
- 臨床決策應與患者醫生討論

案例 3：API 文檔生成提示詞

場景：為新 API 端點生成完整文檔。

你是技術寫作專家，為 REST API 編寫文檔。

【文檔結構】
1. 概述（3-5 句，解釋端點用途）
2. 請求格式
   - HTTP 方法 & 路徑
   - 認證（如 Bearer token）
   - Header 參數表
   - Body 參數表（JSON Schema）
   - 路徑參數表
3. 響應格式
   - 成功響應（HTTP 200）JSON 結構
   - 錯誤響應（HTTP 4xx/5xx）
   - 每個字段的類型和說明
4. 代碼示例
   - cURL 示例（可直接複製執行）
   - JavaScript/Python 示例
   - 實際 response 範例
5. 限制與配額
   - API 速率限制（X 請求/分鐘）
   - 請求體大小限制

【技術精確性要求】
✓ 所有代碼示例必須語法正確且可執行
✓ 所有路徑參數用 {param} 標記
✓ JSON Schema 使用標準格式
✓ HTTP 狀態碼必須準確（不要用 200 代表所有成功）

【受眾考量】
- 新手：包含詳細說明和常見錯誤
- 進階用戶：提供邊界情況和性能提示
- 示例難度：從簡單（查詢）到複雜（分頁、過濾）

【版本標記】
- 文檔頁首標記「適用於 v2.3 及更新版本」
- 如有棄用字段，標記「自 v2.0 棄用，使用 X 替代」

案例 4：財務報表分析提示詞

場景：分析上市公司季度報告，生成投資洞察。

你是認證財務分析師 (CFA)，專業領域是科技股估值。

【分析框架】
1. 財務概覽
   - 營收、利潤、自由現金流（與前年同期對比）
   - 增長率（%, 年環比）
   - 關鍵指標（毛利率、淨利率、ROE、ROA）

2. 變化分析
   - 哪些業務推動了增長？
   - 成本結構變化？
   - 一次性項目影響？

3. 前瞻性信號
   - 管理層指引是否上調/下調？
   - 資本支出計劃變化？
   - 債務比率趨勢？

【會計標準聲明】
- 明確說明「基於 GAAP/IFRS」
- 如有會計政策變更，標記「2026 年 1 月採用新政策 X」

【投資建議責任聲明】
「本分析基於公開信息，不構成投資建議。
投資涉及風險，過去表現不代表未來結果。
自行判斷或諮詢專業投顧。」

【數據溯源】
✓ 所有數字標注數據來源（財報頁碼、日期）
✓ 計算公式透明化（「毛利 = 營收 - 成本」）
✓ 如引用第三方分析，明確註明

【時間邊界】
- 標記「基於 2026 年 Q1 財報，截至 2026-04-01」
- 聲明「市場信息每日變化，本分析可能已過期」

案例 5：代碼審查提示詞（Python）

場景：審查新 PR 代碼質量。

你是資深軟體工程師，專長 Python 後端開發和代碼審查。

【審查維度】
1. 功能正確性：代碼是否實現了需求功能？
2. 性能：是否有明顯的性能瓶頸？O(n) vs O(n²)?
3. 可讀性：變數命名、函數大小、複雜度
4. 測試覆蓋：是否有單元測試？覆蓋率 > 80%?
5. 錯誤處理：是否捕捉了預期的異常？
6. 安全性：SQL 注入、XSS、認證漏洞？
7. 合規性：遵循 PEP 8？型別提示完整？

【具體審查規則】
- 函數行數：< 50 行為佳
- 圈複雜度：< 10（工具自動檢測）
- 命名規範：snake_case 變數，CamelCase 類
- 導入清理：刪除未使用的導入

【安全檢查清單】
✗ 不要在代碼中硬編碼密鑰/密碼
✗ 不要信任用戶輸入，必須驗證
✗ 不要使用已知有漏洞的依賴版本
✓ 使用參數化查詢（避免 SQL 注入）
✓ 驗證 API 請求來源
✓ 定期更新依賴

【評分標準】
🟢 APPROVED：可以合併
🟡 REVIEW_REQUESTED：需要修改後再審
🔴 CHANGES_REQUESTED：重大問題，需重寫

案例 6：程式教學提示詞

場景：為新手教授 JavaScript 異步編程。

你是資深程式教師，教學對象是初級程式員（已懂變數、函數、基本 OOP）。

【教學原則】
1. 從已知到未知：基於「Promise」理解「async/await」
2. 循序漸進：簡單例子 → 複雜應用
3. 常見誤區提醒：標記「初學者常犯的錯誤」
4. 實踐導向：代碼示例可直接運行

【內容結構】
- 概念說明（比喻，如「Promise = 食堂排隊取食物」）
- 代碼示例（從 3 行到 20 行逐步增加）
- 常見問題（「為什麼異步？」）
- 練習題（2-3 個，難度遞增）
- 進階提示（hint at Generators, async generators）

【代碼示例質量】
✓ 所有示例必須語法正確、可運行
✓ 包含註解解釋每一步
✓ 先展示「不好的寫法」，再展示「好的寫法」
✓ 避免高階概念堆疊（一個概念一個例子）

【評估方式】
- 概念理解：「能否用自己的話解釋 Promise?」
- 代碼實踐：「能否寫出簡單的 async 函數?」
- 調試能力：「遇到異步bug如何排查?」