While these tips apply broadly to all Claude models, you can find prompting tips specific to extended thinking models here.
为什么要链式提示？
- 准确性：每个子任务都能获得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- - 简洁且结构良好，有清晰的章节。 - 良好使用比较语言（如”比Q1增长3%“）提供背景。 - 小问题：缩写如”RCT”、“GLP-1”和”GIP”未定义。考虑首次使用时拼写完整。 3. 完整性：B+ - 涵盖所有要求的领域：方法论、发现、临床意义。 - 缺失：组的基线特征（它们是否匹配良好？）。 - 缺失：任何次要终点（如血压、血脂）。 - 考虑：长期意义或进一步研究的需要。 总体而言，摘要准确清晰，为快速掌握研究提供了关键见解。要提升到A+，需要定义缩写，提及组基线统计，记录任何次要结果，并简要涉及长期研究的需要。 |
提示 3
| 角色 | 内容 |
|---|---|
| 用户 | 你的任务是根据反馈改进论文摘要。这是医学研究论文的第一稿： <summary> {{SUMMARY}} </summary> 这是研究论文： <paper> {{RESEARCH_PAPER}} </paper> 这是反馈： <feedback> {{FEEDBACK}} </feedback> 根据反馈更新摘要。 |
| 助手 | 方法论：双盲随机对照试验（RCT），包含500名2型糖尿病患者。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和企业SSO的SAML/OIDC增强IAM。 3. 成本优化： a. 评估规模化时列式多租户数据库（如Snowflake）与分片的对比。 b. 为应用服务器使用预留实例，为非关键工作负载使用现货实例。 c. 实施主动监控和合理调整以避免过度配置。 4. 概念验证（PoC）：在全面实施之前，进行高规模模拟的PoC： a. 测试分片数据库与优化多租户数据库的成本和性能。 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+。技术深度与清晰解释相结合，使其对技术和非技术领导层都非常有效。做得很好！ |