提示工程
串聯複雜提示以獲得更強大的表現
在處理複雜任務時，如果您試圖在單一提示中處理所有內容，Claude 有時可能會出錯。思維鏈（Chain of thought, CoT）提示很好，但如果您的任務有多個需要深入思考的不同步驟怎麼辦？
這就需要提示串聯：將複雜任務分解成更小、更易管理的子任務。
為什麼要串聯提示？
- 準確性：每個子任務都能得到 Claude 的全部注意力，減少錯誤。
- 清晰度：更簡單的子任務意味著更清晰的指示和輸出。
- 可追蹤性：輕鬆找出並修復提示鏈中的問題。
何時串聯提示
對於研究綜合、文件分析或迭代內容創作等多步驟任務，請使用提示串聯。當任務涉及多個轉換、引用或指示時，串聯可以防止 Claude 遺漏或處理錯誤步驟。
**請記住：**提示鏈中的每個環節都能得到 Claude 的全部注意力！
除錯提示：如果 Claude 遺漏了某個步驟或表現不佳，請將該步驟單獨放在一個提示中。這樣您就可以微調有問題的步驟，而無需重做整個任務。
如何串聯提示
- 識別子任務：將任務分解為不同的、順序性的步驟。
- 使用 XML 結構以清晰交接：使用 XML 標籤在提示之間傳遞輸出。
- 設定單一任務目標：每個子任務應該有一個明確的單一目標。
- 迭代：根據 Claude 的表現改進子任務。
串聯工作流程示例：
- 多步驟分析：請參見下方的法律和商業示例。
- 內容創作流程：研究 → 大綱 → 草稿 → 編輯 → 格式化。
- 數據處理：提取 → 轉換 → 分析 → 視覺化。
- 決策制定：收集信息 → 列出選項 → 分析每個選項 → 提出建議。
- 驗證循環：生成內容 → 審查 → 改進 → 重新審查。
優化提示：對於具有獨立子任務的任務（如分析多個文檔），創建單獨的提示並並行運行以提高速度。
進階：自我糾正鏈
您可以串聯提示讓 Claude 審查自己的工作！這可以捕捉錯誤並改進輸出，特別是對於高風險任務。
提示 1
| 角色 | 內容 |
|---|---|
| User | 總結這篇醫學研究論文。 <paper>{{RESEARCH_PAPER}}</paper> 重點關注方法論、研究發現和臨床意義。 |
| Assistant {{SUMMARY}} | 方法論：500名2型糖尿病患者的雙盲隨機對照試驗。A組（n=250）接受新型 GLP-1/GIP 雙重激動劑；B組（n=250）接受標準 GLP-1 激動劑。24週試驗，主要終點：HbA1c 降低。 研究發現： - A組：平均 HbA1c 降低1.8% - B組：平均 HbA1c 降低1.1% - A組68%與B組52%達到 HbA1c <7% - A組：平均減重5.2kg - B組：平均減重3.1kg 安全性：類似的不良事件概況，無嚴重事件歸因於治療。 臨床意義：與標準療法相比，雙重激動劑顯示出更優的血糖控制和減重效果。可能是一個突破性進展，特別是對肥胖的糖尿病患者。 |
提示 2
| 角色 | 內容 |
|---|---|
| User | 您的任務是對研究論文摘要提供反饋。這是一篇醫學研究論文的摘要： <summary> {{SUMMARY}} </summary> 這是研究論文： <paper> {{RESEARCH_PAPER}} </paper> 請以A-F等級評審此摘要的準確性、清晰度和完整性。 |
| Assistant {{FEEDBACK}} | 1. 準確性：A - 正確報告關鍵統計數據：HbA1c 降低、減重。 - 準確記錄安全性概況和無嚴重不良事件。 - “突破性進展”的說法由顯著更好的結果支持。 2. 清晰度：A- - 簡潔且結構良好，各部分清晰。 - 良好使用比較語言（例如，“較第一季度上升3%“）提供背景。 - 小問題：未定義縮寫”RCT”、“GLP-1”和”GIP”。考慮首次使用時拼寫完整。 3. 完整性：B+ - 涵蓋所有要求的領域：方法論、研究發現、臨床意義。 - 缺失：組別基線特徵（是否匹配良好？）。 - 缺失：任何次要終點（如血壓、血脂）。 - 建議：長期影響或進一步研究的需求。 總的來說，摘要準確且清晰，提供了快速掌握研究的關鍵見解。要達到A+，需定義縮寫、提及組別基線統計、注明任何次要結果，並簡要提及長期研究的需求。 |
提示 3
| 角色 | 內容 |
|---|---|
| User | 您的任務是根據反饋改進論文摘要。這是醫學研究論文的第一稿： <summary> {{SUMMARY}} </summary> 這是研究論文： <paper> {{RESEARCH_PAPER}} </paper> 這是反饋： <feedback> {{FEEDBACK}} </feedback> 根據反饋更新摘要。 |
| Assistant | 方法論：500名2型糖尿病患者的雙盲隨機對照試驗（RCT）。A組（n=250）接受新型胰高血糖素樣肽-1/葡萄糖依賴性促胰島素分泌多肽（GLP-1/GIP）雙重激動劑；B組（n=250）接受標準 GLP-1 激動劑。24週試驗的主要終點是 HbA1c 降低。兩組在年齡、BMI和基線 HbA1c 方面匹配良好。 研究發現： - A組：平均 HbA1c 降低1.8% - B組：平均 HbA1c 降低1.1% - A組68%與B組52%達到 HbA1c <7% - A組：平均減重5.2kg - B組：平均減重3.1kg 次要終點顯示兩組的血壓和血脂指標均有改善，A組表現略優。 安全性：類似的不良事件概況，無嚴重事件歸因於任一治療。 臨床意義：GLP-1/GIP 雙重激動劑相比標準 GLP-1 療法展現出更優的血糖控制和減重效果。這些結果表明它可能是一個重要進展，特別是對肥胖的糖尿病患者。然而，需要更長期的研究來確認持續的療效和安全性，並研究對心血管結果的潛在益處。 |
示例
注意 Claude 在其電子郵件草稿中遺漏了提供建議修改的指示。
| 角色 | 內容 |
|---|---|
| User | 您是我們的首席法務官。請審查這份 SaaS 合同的風險，重點關注數據隱私、SLA 和責任上限。 <contract> {{CONTRACT}} </contract> 然後起草一封電子郵件給供應商，說明您的顧慮和建議修改。 |
| Assistant | 審查 SaaS 合同後，我發現以下幾個問題： 1. 數據隱私（第7節）： - 問題：供應商對客戶數據有廣泛的”服務改進”使用權。 - 風險：可能導致未經授權的數據共享或變現。 2. SLA（第5節）： - 問題：99.5%的運行時間保證低於行業標準。 - 風險：過多的停機時間可能影響我們的運營。 3. 責任（第9節）： - 問題：上限設定為3個月的費用。 - 風險：對潛在的數據洩露或服務故障不足。 電子郵件草稿： 尊敬的{{VENDOR}}， 審查 SaaS 協議後，我們有以下顧慮： 1. 數據隱私：我們要求我們的數據僅用於直接服務提供，而不是廣泛的”服務改進”。請修改第7節。 2. SLA：99.5%的運行時間不足。我們需要99.99%，並有明確定義的處罰。請修改第5節。 3. 責任：目前3個月費用的上限不足。我們建議將上限設為12個月的費用，對於數據洩露或故意不當行為不設上限。 我們重視我們潛在的合作關係，相信這些變更將為我們奠定成功的基礎。請發送修訂後的協議。 此致 {{CLO_NAME}} |
提示 1
| 角色 | 內容 |
|---|---|
| User | 您是我們的首席法務官。請審查這份 SaaS 合同的風險，重點關注數據隱私、SLA 和責任上限。 <contract> {{CONTRACT}} </contract> 請在 <risks> 標籤中輸出您的發現。 |
| Assistant {{CONCERNS}} | 1. 數據隱私（第7節）： - 問題：供應商對客戶數據有廣泛的”服務改進”使用權。 - 風險：可能導致未經授權的客戶數據共享或變現。 - 影響：潛在違反客戶信任，監管罰款（GDPR、CCPA）。 2. SLA（第5節）： - 問題：99.5%的運行時間保證低於行業標準（通常為99.99%）。 - 風險：每年最多43.8小時停機時間，相比99.99%的52.6分鐘。 - 影響：運營中斷、收入損失、客戶不滿。 3. 責任（第9節）： - 問題：責任上限設為3個月的費用。 - 風險：對潛在的數據洩露、知識產權盜竊或長期服務故障不足。 - 影響：對可能遠超上限的損害賠償不足，如集體訴訟或監管罰款。 |
提示 2
| 角色 | 內容 |
|---|---|
| User | 起草一封電子郵件給 SaaS 產品供應商，概述以下顧慮並提出修改建議。以下是顧慮： <concerns> {{CONCERNS}} </concerns> |
| Assistant {{EMAIL}} | 尊敬的{{VENDOR}}， 經過對擬議 SaaS 協議的深入審查，我們的法務團隊已確定了幾個必須解決的高優先級問題： 1. 數據隱私（第7節）： - 現狀：廣泛的客戶數據”服務改進”使用權。 - 顧慮：潛在的未經授權數據共享或變現。 - 建議修改：限制數據使用於直接服務提供。任何用於改進、分析或營銷的使用必須選擇加入、可撤銷且匿名化。 2. SLA（第5節）： - 現狀：99.5%運行時間保證。 - 顧慮：每年最多43.8小時停機時間，存在運營中斷風險。 - 建議修改：99.99%運行時間，分級服務補償。例如，<99.99%補償10%，<99.9%補償25%，<99.5%補償50%。 3. 責任（第9節）： - 現狀：上限為3個月費用。 - 顧慮：對數據洩露、知識產權盜竊或長期停機嚴重不足。 - 建議修改：一般責任為12個月費用。數據洩露、故意不當行為、知識產權侵權無上限。 這些變更對我們來說是不可協商的。它們符合行業標準和我們對數據安全、運營卓越和信託責任的承諾。我們重視潛在的合作關係，解決這些問題將奠定堅實的基礎。 請讓您的法務團隊審查並納入這些變更。我們很樂意進一步討論以確保相互理解和協議。 此致 {{CLO_NAME}} |
提示 3
| 角色 | 內容 |
|---|---|
| User | 您的任務是審查一封電子郵件並提供反饋。這是電子郵件： <email> {{EMAIL}} </email> 就語氣、清晰度和專業性提供反饋。 |
| Assistant | 1. 語氣： - 專業且堅定，但不具對抗性。 - 使用”不可協商”措辭強硬但考慮到問題的重要性是合理的。 - 合作性語言（“我們重視”，“樂意討論”）平衡了堅定性，保持建設性語氣。 2. 清晰度： - 優秀的結構：每個問題都列出現狀、顧慮和建議修改。 - 技術術語（如”EBITDA”，“分級服務補償”）適合B2B SaaS背景。 - 行動項目明確：供應商法務團隊審查並納入變更。 3. 專業性： - 關注互惠和行業標準，而不僅是我們的要求。 - 提及更廣泛的責任（數據安全、運營卓越、信託責任），提升討論層次。 - 提供進一步討論，表明致力於理解和解決問題。 總的來說，電子郵件在堅定性和合作性之間取得了適當的平衡。它清晰地闡述了我們的顧慮，提出具體解決方案，並保持專業、面向合作的語氣。無需修改；可以發送。 |
提示 1
| 角色 | 內容 |
|---|---|
| User | 作為高級解決方案架構師，請審查並分析這個針對我們新企業 SaaS 產品的多租戶策略。 <strategy> {{STRATEGY}} </strategy> 重點關注可擴展性、安全性和成本效益。 |
| Assistant {{ANALYSIS}} | 1. 可擴展性： + 按租戶分片數據庫減少爭用，支持高增長。 + 微服務允許組件獨立擴展。 - 共享應用服務器在極端負載下可能成為瓶頸。 - 未提及應用層的自動擴展或負載均衡。 2. 安全性： + 通過分片實現租戶數據隔離，減輕數據洩露。 + 短期過期的 JWT 和刷新令牌是行業最佳實踐。 - 未提及加密（靜態、傳輸中）或密鑰管理。 - IAM 策略缺乏角色、權限或 RBAC 的細節。 3. 成本效益： + 共享應用服務器減少閒置資源成本。 + 不頻繁任務使用無服務器函數優化成本。 - 每租戶數據庫在規模化時可能比優化的多租戶數據庫成本更高。 - 未討論使用預留實例或競價實例以節省成本。 |
提示 2
| 角色 | 內容 |
|---|---|
| User | 基於這個多租戶策略分析，為工程領導層起草一份策略審查文檔。 <strategy> {{STRATEGY}} </strategy> <analysis> {{ANALYSIS}} </analysis> 包括執行摘要、詳細分析和建議。 |
| Assistant {{STRATEGY_DOC}} | # 多租戶策略審查：SaaS 企業產品 ## 執行摘要 擬議策略在可擴展性和安全性原則方面展示了堅實的基礎，但在實施細節方面存在差距。它在數據隔離和組件級擴展方面表現出色，但缺乏強大的應用層擴展和高級安全措施。成本優化存在但可能在高規模時失效。通過有針對性的增強，這個策略可以有效支持我們的企業 SaaS 願景。 ## 詳細分析 ### 1. 可擴展性：B+ 優勢： - 按租戶分片數據庫非常出色。它最小化查詢延遲，支持高數據增長，並促進無縫的每租戶擴展。 - 微服務架構允許根據需求擴展單個組件，對處理多樣的企業工作負載至關重要。 劣勢： - 共享應用服務器有成為瓶頸的風險。隨著租戶數量和流量增長，這可能降低所有租戶的性能。 - 缺少應用層的自動擴展和負載均衡是一個關鍵疏忽。這些對於處理流量峰值而不過度配置是必要的。 ### 2. 安全性：B- 優勢： - 分片數據庫提供強大的租戶數據隔離，減輕租戶間數據洩露或未授權訪問的風險。 - 短期過期的 JWT 和刷新令牌符合 OWASP 最佳實踐，減少令牌漏洞窗口。 劣勢： - 未提及靜態或傳輸中的數據加密（TLS 1.3）。這對企業數據是不可協商的。 - 缺少密鑰管理策略。如何管理和輪換加密密鑰、JWT 密鑰和數據庫憑證？ - IAM 缺乏深度。我們需要具有明確定義角色的 RBAC、用於細粒度權限的基於屬性的訪問控制（ABAC），以及與企業身份提供者（SAML、OIDC）的集成。 ### 3. 成本效益：B 優勢： - 共享應用服務器減少閒置容量成本，適合穩定狀態流量。 - 不頻繁任務（如報告）使用無服務器很明智；只在使用這些資源時付費。 劣勢： - 每租戶數據庫在規模化時可能不如具有強大數據分區的多租戶數據庫成本效益。 - 未提及成本節省措施，如用於可預測工作負載的預留實例或用於容錯任務的競價實例。 - 缺少應用層自動擴展可能導致過度配置，增加成本。 ## 建議 1. 應用層彈性：使用 Kubernetes 或雲原生服務（EKS、GKE）實施自動擴展。跨可用區部署，使用 CDN 處理靜態資產。 2. 安全強化： a. 加密靜態數據（AES-256）和傳輸中數據（TLS 1.3）。 b. 使用託管 KMS（AWS KMS、GCP KMS）進行密鑰管理。 c. 通過 RBAC、ABAC 和 SAML/OIDC 增強 IAM，實現企業 SSO。 3. 成本優化： a. 評估列式多租戶數據庫（如 Snowflake）與規模化分片的比較。 b. 對應用服務器使用預留實例，對非關鍵工作負載使用競價實例。 c. 實施主動監控和適當規模調整以避免過度配置。 4. 概念驗證（PoC）：在完全實施前，進行高規模模擬的概念驗證： a. 測試分片數據庫與優化多租戶數據庫的成本和性能。 b. 使用模擬的企業級流量峰值壓力測試應用層。 c. 進行第三方安全審計，重點關注數據隔離和訪問控制。 通過這些增強，我們的多租戶策略將達到企業級：可擴展、安全且具有成本效益。概念驗證將驗證我們的設計選擇並增強我們企業客戶的信心。 |
提示 3
| 角色 | 內容 |
|---|---|
| User | 就清晰度、可操作性和與企業優先級的一致性對這份策略審查文檔進行評分。 <priorities> {{PRIORITIES}} </priorities> <strategy_doc> {{STRATEGY_DOC}} </strategy_doc> |
| Assistant | 1. 清晰度：A + 清晰的結構，包括執行摘要、詳細分析和建議。 + 分析使用評分系統（B+、B-）以快速掌握優劣勢。 + 技術術語（RBAC、ABAC、TLS）有解釋或上下文，幫助非技術領導理解。 + 視覺輔助（項目符號、縮進）增強可讀性。 2. 可操作性：A- + 建議具體且技術性（如”使用 Kubernetes 實施自動擴展”）。 + 概念驗證計劃有明確目標提供路線圖。 + 缺失：每項建議的時間表、資源需求或團隊分配。 + 建議：添加”下一步”部分，包含即時行動、角色和高層時間表。 3. 企業一致性：A+ + 直接解決企業優先事項： - 可擴展性：討論處理企業級流量峰值。 - 安全性：關注數據隔離、加密和企業 IAM。 - 成本：策略符合企業 FinOps（預留實例、適當規模）。 + 具有”高規模模擬”和安全審計的概念驗證顯示對企業級質量的承諾。 + 語言與企業關注點產生共鳴：“不可接受風險”、“企業級”、“增強信心”。 總的來說，文檔在清晰度和企業一致性方面表現出色。可操作性很強，但添加”下一步”部分可提升至A+。技術深度加上清晰解釋使其對技術和非技術領導層都非常有效。做得很好！ |
Was this page helpful?