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