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