提示工程
链式复杂提示以获得更强的性能
在处理复杂任务时，如果你试图在单个提示中处理所有内容，Claude有时可能会出现失误。思维链(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%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个月的费用。 - 风险：对潜在的数据泄露、知识产权盗窃或长期服务故障不足。 - 影响：对可能远超上限的损害赔偿不足，如集体诉讼或监管罚款。 |
提示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）vs分片。 b. 对应用服务器使用预留实例，对非关键工作负载使用竞价实例。 c. 实施主动监控和适当规模调整以避免过度配置。 4. 概念验证（PoC）：在完全实施前，进行高规模模拟的PoC： a. 测试分片数据库vs优化的多租户数据库的成本和性能。 b. 用模拟的企业级流量峰值压力测试应用层。 c. 进行第三方安全审计，重点关注数据隔离和访问控制。 通过这些增强，我们的多租户策略将达到企业级：可扩展、安全且具有成本效益。PoC将验证我们的设计选择并增强我们企业客户的信心。 |
提示3
| 角色 | 内容 |
|---|---|
| User | 就清晰度、可操作性和与企业优先级的一致性对这份策略审查文档评分。 <priorities> {{PRIORITIES}} </priorities> <strategy_doc> {{STRATEGY_DOC}} </strategy_doc> |
| Assistant | 1. 清晰度：A + 清晰的结构，包括执行摘要、详细分析和建议。 + 分析使用评分系统（B+、B-）以快速把握优劣势。 + 技术术语（RBAC、ABAC、TLS）有解释或上下文，帮助非技术领导理解。 + 视觉辅助（项目符号、缩进）增强可读性。 2. 可操作性：A- + 建议具体且技术性（如”使用Kubernetes实现自动扩展”）。 + 具有明确目标的PoC计划提供了路线图。 + 缺失：每项建议的时间线、资源需求或团队分配。 + 考虑：添加”下一步”部分，包含即时行动、角色和高级时间线。 3. 企业一致性：A+ + 直接解决企业优先级： - 可扩展性：讨论处理企业级流量峰值。 - 安全性：关注数据隔离、加密和企业IAM。 - 成本：策略符合企业FinOps（预留实例、适当规模）。 + 带有”高规模模拟”和安全审计的PoC显示对企业级质量的承诺。 + 语言符合企业关注点：“不可接受风险”、“企业级”、“增强信心”。 总的来说，文档在清晰度和企业一致性方面表现出色。可操作性很强，但添加”下一步”部分可提升到A+。技术深度加上清晰的解释使其对技术和非技术领导都非常有效。干得好！ |