跳轉到主要內容

Documentation Index

Fetch the complete documentation index at: https://docs.claude.com/llms.txt

Use this file to discover all available pages before exploring further.

While these tips apply broadly to all Claude models, you can find prompting tips specific to extended thinking models here.
在處理複雜任務時，如果你試圖在單一提示中處理所有事情，Claude 有時可能會出錯。思維鏈（Chain of thought, CoT）提示很好，但如果你的任務有多個需要深入思考的不同步驟呢？ 這就需要提示串接：將複雜任務分解成更小、更易管理的子任務。

​
為什麼要串接提示？

  1. 準確性：每個子任務都能獲得 Claude 的全部注意力，減少錯誤。
  2. 清晰度：更簡單的子任務意味著更清晰的指令和輸出。
  3. 可追蹤性：輕鬆找出並修復提示串接中的問題。

​
何時串接提示

在進行研究綜合、文件分析或迭代內容創作等多步驟任務時使用提示串接。當任務涉及多個轉換、引用或指令時，串接可以防止 Claude 遺漏或處理錯誤步驟。 **記住：**串接中的每個環節都能獲得 Claude 的全部注意力！
除錯提示：如果 Claude 遺漏了某個步驟或表現不佳，將該步驟單獨放在一個提示中。這樣你就可以微調有問題的步驟，而無需重做整個任務。

​
如何串接提示

  1. 識別子任務：將任務分解為不同的、順序性的步驟。
  2. 使用 XML 結構化以清晰交接：使用 XML 標籤在提示之間傳遞輸出。
  3. 設定單一任務目標：每個子任務應該有一個明確的單一目標。
  4. 迭代：根據 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%vs 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-
- 簡潔且結構良好，章節清晰。
- 良好使用比較性語言（如”較Q1上升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%vs 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小時停機時間vs 99.99%時的52.6分鐘。
- 影響：運營中斷、收入損失、客戶不滿。

3. 責任（第9節）：
- 問題：責任上限設為3個月的費用。
- 風險：對潛在的數據洩露、IP盜竊或長期服務故障不足。
- 影響：對可能遠超上限的損害賠償不足，如集體訴訟或監管罰款。

​
提示 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個月費用。
- 顧慮：對數據洩露、IP盜竊或長期停機嚴重不足。
- 建議修改：一般責任為12個月費用。數據洩露、故意不當行為、IP侵權無上限。

這些修改對我們來說是不可協商的。它們符合行業標準和我們對數據安全、運營卓越和信託責任的承諾。我們重視潛在的合作關係，解決這些問題將奠定堅實的基礎。

請讓您的法務團隊審查並納入這些修改。我們很樂意進一步討論以確保相互理解和協議。

順祝安好，
{{CLO_NAME}}

​
提示 3

角色內容
User你的任務是審查一封電子郵件並提供反饋。這是電子郵件：
<email>
{{EMAIL}}
</email>

就語氣、清晰度和專業性給出反饋。
Assistant1. 語氣：
- 專業且堅定而不對抗。
- 使用”不可協商”措辭強硬但鑑於問題的嚴重性是合理的。
- 合作性語言（“我們重視”、“樂意討論”）平衡了堅定性，保持建設性語氣。

2. 清晰度：
- 優秀的結構：每個問題都列出現狀、顧慮和建議修改。
- 技術術語（如”EBITDA”、“分級服務補償”）適合B2B SaaS背景。
- 行動項目明確：供應商法務團隊審查並納入修改。

3. 專業性：
- 關注互惠和行業標準，而不僅是我們的要求。
- 提及更廣泛的責任（數據安全、運營卓越、信託責任），提升討論層次。
- 提出進一步討論，表明致力於理解和解決問題。

總體而言，電子郵件在堅定性和合作性之間取得了適當平衡。它清晰地闡述了我們的顧慮，提出具體解決方案，並保持專業、面向合作的語氣。無需修改；可以發送。

​
提示 1

角色內容
User作為高級解決方案架構師，審查並分析這個針對我們新企業 SaaS 產品的多租戶策略。

<strategy>
{{STRATEGY}}
</strategy>

重點關注可擴展性、安全性和成本效益。
Assistant
{{ANALYSIS}}		1. 可擴展性：
+ 按租戶分片數據庫減少爭用，支持高增長。
+ 微服務允許組件獨立擴展。
- 共享應用服務器在極端負載下可能成為瓶頸。
- 未提及應用層的自動擴展或負載均衡。

2. 安全性：
+ 通過分片實現租戶數據隔離降低數據洩露風險。
+ 短期過期的JWT和刷新令牌是行業最佳實踐。
- 未提及加密（靜態、傳輸中）或密鑰管理。
- IAM策略缺乏角色、權限或RBAC細節。

3. 成本效益：
+ 共享應用服務器減少閒置資源成本。
+ 不頻繁任務使用無服務器函數優化成本。
- 每租戶DB在規模化時可能比優化的多租戶DB成本更高。
- 未討論使用預留實例或競價實例以節省成本。

​
提示 2

角色內容
User基於這個多租戶策略分析，為工程領導層起草一份策略審查文檔。

<strategy>
{{STRATEGY}}
</strategy>

<analysis>
{{ANALYSIS}}
</analysis>

包括執行摘要、詳細分析和建議。
Assistant
{{STRATEGY_DOC}}		# 多租戶策略審查：SaaS 企業產品

## 執行摘要
提議的策略在可擴展性和安全性原則上展示了堅實的基礎，但在實施細節上存在差距。它在數據隔離和組件級擴展方面表現出色，但缺乏健全的應用層擴展和高級安全措施。成本優化雖然存在但可能在高規模時失效。通過有針對性的增強，這個策略可以有效支持我們的企業 SaaS 願景。

## 詳細分析

### 1. 可擴展性：B+

優勢：
- 按租戶分片數據庫非常出色。它最小化查詢延遲，支持高數據增長，並促進無縫的每租戶擴展。
- 微服務架構允許基於需求擴展單個組件，這對處理多樣的企業工作負載至關重要。

劣勢：
- 共享應用服務器有成為瓶頸的風險。隨著租戶數量和流量增長，這可能降低所有租戶的性能。
- 缺少應用層的自動擴展和負載均衡是一個關鍵疏忽。這些對於處理流量峰值而不過度配置是必要的。

### 2. 安全性：B-

優勢：
- 分片數據庫提供強大的租戶數據隔離，降低租戶間數據洩露或未授權訪問的風險。
- 短期過期的JWT和刷新令牌符合OWASP最佳實踐，減少令牌漏洞窗口。

劣勢：
- 未提及靜態或傳輸中的數據加密（TLS 1.3）。這對企業數據是不可協商的。
- 缺少密鑰管理策略。如何管理和輪換加密密鑰、JWT密鑰和DB憑證？
- 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. 評估列式多租戶DB（如Snowflake）vs規模化分片。
b. 對應用服務器使用預留實例，對非關鍵工作負載使用競價實例。
c. 實施主動監控和適當規模調整以避免過度配置。

4. 概念驗證（PoC）：在完全實施前，進行高規模模擬的概念驗證：
a. 測試分片DB vs優化多租戶DB的成本和性能。
b. 使用模擬的企業級流量峰值壓力測試應用層。
c. 進行第三方安全審計，重點關注數據隔離和訪問控制。

通過這些增強，我們的多租戶策略將達到企業級水平：可擴展、安全且具有成本效益。概念驗證將驗證我們的設計選擇並增強我們企業客戶的信心。

​
提示 3

角色內容
User就清晰度、可操作性和與企業優先級的一致性對這份策略審查文檔評分。

<priorities>
{{PRIORITIES}}
</priorities>

<strategy_doc>
{{STRATEGY_DOC}}
</strategy_doc>
Assistant1. 清晰度：A
+ 清晰的結構，包括執行摘要、詳細分析和建議。
+ 分析使用評分系統（B+、B-）以快速掌握優劣勢。
+ 技術術語（RBAC、ABAC、TLS）有解釋或上下文，幫助非技術領導理解。
+ 視覺輔助（項目符號、縮進）增強可讀性。

2. 可操作性：A-
+ 建議具體且技術性（如”使用Kubernetes實施自動擴展”）。
+ 概念驗證計劃有明確目標提供路線圖。
+ 缺失：每項建議的時間表、資源需求或團隊分配。
+ 建議：添加”下一步”部分，包含即時行動、角色和高層時間表。

3. 企業一致性：A+
+ 直接解決企業優先事項：
- 可擴展性：討論處理企業級流量峰值。
- 安全性：關注數據隔離、加密和企業IAM。
- 成本：策略符合企業FinOps（預留實例、適當規模）。
+ 具有”高規模模擬”和安全審計的概念驗證顯示對企業級質量的承諾。
+ 語言與企業關注點產生共鳴：“不可接受風險”、“企業級”、“增強信心”。

總體而言，文檔在清晰度和企業一致性方面表現出色。可操作性很強，但添加”下一步”部分可提升至A+。技術深度加上清晰的解釋使其對技術和非技術領導層都非常有效。做得很好！

提示庫

從精選的各種任務和用例提示中獲得靈感。

GitHub 提示教程

一個包含我們文檔中提示工程概念的示例豐富教程。

Google Sheets 提示教程

通過互動式電子表格提供的我們提示工程教程的輕量級版本。