ChatGPT vs Claude：如何针对两者编写提示词

ChatGPT vs Claude：如何针对两者编写提示词

稳定可靠的 AI 工作始于一份明确的约定：规定产出什么以及如何评判其质量。本文提供的是一套实操框架，而非产品排行榜，也并非预言某种提示词技巧就能解决所有任务。当具体能力依赖于特定的模型、账户或集成环境时，请务必在你的实际使用环境中进行验证。

核心要点

• 在选择语法或工具之前，先明确预期的成果。
• 将指令、支撑依据以及参考示例拆分开来。
• 让约束条件具备可测试性，并为关键决策指定负责人。
• 评估具有代表性的多次输出，而非轻信某一次令人惊艳的回答。
• 在执行前，使用 Brief Prompting（简报提示法）收集缺失的上下文背景。

从相同的任务定义开始

对比往往容易聚焦在模型“性格”上，但造成差异的最大根源其实是不完整的需求简报。两个系统都需要明确预期成果、受众群体以及依据边界。在调整语法之前，请先确立这些要素。否则，当第二次尝试仅仅是补充了第一次遗漏的信息时，你可能会误将其归功于模型本身的优劣。

实用落地示例

从一个有人能够进行复核的真实任务入手。识别模型必须接收的信息、允许其做出的决策，以及必须由人工承担责任的节点。在生成交付成果前，将这些边界写入需求简报。即使底层模型发生变化，这也能确保工作流清晰易懂。

目标：起草一封新手引导邮件。受众：新系统管理员。预期结果：完成配置。依据来源：所提供的配置指南。约束条件：不得捏造指南中未列出的功能或承诺指南中没有的协助。

根据原始需求来评估结果，而不是看它听起来有多完美。检查所需信息是否齐全、是否出现了缺乏依据的假设，以及目标读者是否能够据此采取行动。如果不符合某项要求，请明确指出该缺陷，而不是提出含糊的改进要求。

一次有价值的对比必须保持预期交付成果不变。如果你让一个系统写高管摘要，而让另一个系统做详细分析，这种输出就无法为评估模型适用性提供有意义的判断。请先将任务标准化，然后再审视各自的回答在哪里需要修正。

将 Markdown 作为 ChatGPT 的默认格式

Markdown 标题便于人工检查和修改指令。请将任务、背景、要求和输出格式分开，避免混在一个段落中。这是一种实用的约定，并不代表 ChatGPT 无法理解 XML 或常规白话。清晰的层级标签远比装饰性的排版重要得多。

实用落地示例

从一个有人能够进行复核的真实任务入手。识别模型必须接收的信息、允许其做出的决策，以及必须由人工承担责任的节点。在生成交付成果前，将这些边界写入需求简报。即使底层模型发生变化，这也能确保工作流清晰易懂。

# Goal
向非技术背景的客户解释系统迁移流程。
# Sources
仅使用所提供的指南。
# Output
列出 5 个编号步骤，随后列出尚未解决的问题。

根据原始需求来评估结果，而不是看它听起来有多完美。检查所需信息是否齐全、是否出现了缺乏依据的假设，以及目标读者是否能够据此采取行动。如果不符合某项要求，请明确指出该缺陷，而不是提出含糊的改进要求。

不要把排版惯例演变成某种教条。如果简单的标题结构在两个系统中都能很好地运作，那它可能就是最简便的通用标准。只在需要更清晰边界时才添加标签，而不是每个任务都硬套一套复杂的标记语言。

将 XML 作为 Claude 的默认格式

类 XML 标签非常适合将指令与参考资料隔离开来，尤其是在简报包含多份文档或示例时。请选用描述性的标签名称，并保持嵌套结构简单明了。标签的作用是划定边界；它们不能验证内容的真实性，也无法完全杜绝未遵循指令的错误。Claude 同样能够处理 Markdown 和纯文本语言。

实用落地示例

从一个有人能够进行复核的真实任务入手。识别模型必须接收的信息、允许其做出的决策，以及必须由人工承担责任的节点。在生成交付成果前，将这些边界写入需求简报。即使底层模型发生变化，这也能确保工作流清晰易懂。

<goal>向非技术背景的客户解释系统迁移流程。</goal>
<sources>在此处插入经审核通过的迁移指南。</sources>
<output>列出 5 个编号步骤，随后列出尚未解决的问题。</output>

根据原始需求来评估结果，而不是看它听起来有多完美。检查所需信息是否齐全、是否出现了缺乏依据的假设，以及目标读者是否能够据此采取行动。如果不符合某项要求，请明确指出该缺陷，而不是提出含糊的改进要求。

参考示例绝不应在暗中扩大使用敏感信息的权限。在将材料粘贴到任一系统之前，请检查该材料是否已被批准用于该环境。去除与本次任务处理无关的个人隐私信息和机密内容。

迁移核心意图，而非仅仅套用标点符号

跨模型转换成功的关键在于保留优先级和资料来源边界。不要盲目地把杂乱无章的提示词套上标签，就以为它得到了优化。首先消除相互矛盾的指示，明确强制性要求，并将示例与客观事实区分开来。随后，使用团队最易维护的结构重新表达这份相同的需求简报。

实用落地示例

从一个有人能够进行复核的真实任务入手。识别模型必须接收的信息、允许其做出的决策，以及必须由人工承担责任的节点。在生成交付成果前，将这些边界写入需求简报。即使底层模型发生变化，这也能确保工作流清晰易懂。

保留目标、受众、事实约束和验收标准。将标题转换为描述性标签，切勿添加新要求或削弱现有约束。

根据原始需求来评估结果，而不是看它听起来有多完美。检查所需信息是否齐全、是否出现了缺乏依据的假设，以及目标读者是否能够据此采取行动。如果不符合某项要求，请明确指出该缺陷，而不是提出含糊的改进要求。

一次有价值的对比必须保持预期交付成果不变。如果你让一个系统写高管摘要，而让另一个系统做详细分析，这种输出就无法为评估模型适用性提供有意义的判断。请先将任务标准化，然后再审视各自的回答在哪里需要修正。

赋予示例明确的分工

示例可以展示语气、颗粒度或排版布局，但模型需要知道该模仿哪一种特性。参考文章可能具有合适的行文节奏，但其事实论断可能是错的。请明确打上对应标签。真实发布的参考资料在其相关性经过检查时非常有用，但切勿默认其具备权威性，也不要将其直接照抄进最终答复中。

实用落地示例

从一个有人能够进行复核的真实任务入手。识别模型必须接收的信息、允许其做出的决策，以及必须由人工承担责任的节点。在生成交付成果前，将这些边界写入需求简报。即使底层模型发生变化，这也能确保工作流清晰易懂。

仅将参考资料用于段落长度和表达直白度的参考。切勿复用其中的措辞、统计数据、公司名称或事实论断。内容本身请使用经审核通过的事实清单。

根据原始需求来评估结果，而不是看它听起来有多完美。检查所需信息是否齐全、是否出现了缺乏依据的假设，以及目标读者是否能够据此采取行动。如果不符合某项要求，请明确指出该缺陷，而不是提出含糊的改进要求。

不要把排版惯例演变成某种教条。如果简单的标题结构在两个系统中都能很好地运作，那它可能就是最简便的通用标准。只在需要更清晰边界时才添加标签，而不是每个任务都硬套一套复杂的标记语言。

明确来源处理规则

无论自信的语气还是优雅的引用，都不能证明答案是有据可循的。当准确性取决于特定文档时，请直接提供来源，并要求对这些来源进行可追溯的引用标注。如果可以使用联网浏览，请明确检索范围并要求核验。工具可用性因产品、账户和配置而异；不要假定每次会话都具备搜索能力。

实用落地示例

从一个有人能够进行复核的真实任务入手。识别模型必须接收的信息、允许其做出的决策，以及必须由人工承担责任的节点。在生成交付成果前，将这些边界写入需求简报。即使底层模型发生变化，这也能确保工作流清晰易懂。

对于每个实质性的事实主张，指明所依据的来源章节。如果来源无法证实该主张，请予以省略或标注为未解决。切勿捏造 URL 或引文。

根据原始需求来评估结果，而不是看它听起来有多完美。检查所需信息是否齐全、是否出现了缺乏依据的假设，以及目标读者是否能够据此采取行动。如果不符合某项要求，请明确指出该缺陷，而不是提出含糊的改进要求。

参考示例绝不应在暗中扩大使用敏感信息的权限。在将材料粘贴到任一系统之前，请检查该材料是否已被批准用于该环境。去除与本次任务处理无关的个人隐私信息和机密内容。

规定推理产出，而非隐藏的思考流水账

对于分析类任务，应要求提供简明扼要的解释、相关假设以及读者可验证的检查点。要求模型展示所有内部思考过程是没有必要的，甚至可能不被支持。重点应放在可观测的工作成果上：计算过程、论据、替代方案和局限性。所要求的解释深度应当与读者需要做出的决策相匹配。

实用落地示例

从一个有人能够进行复核的真实任务入手。识别模型必须接收的信息、允许其做出的决策，以及必须由人工承担责任的节点。在生成交付成果前，将这些边界写入需求简报。即使底层模型发生变化，这也能确保工作流清晰易懂。

推荐一个方案。提供决定性证据、核心假设、主要权衡考量，以及一项可能推翻该推荐的核查项。保持解释简明且具备可审计性。

根据原始需求来评估结果，而不是看它听起来有多完美。检查所需信息是否齐全、是否出现了缺乏依据的假设，以及目标读者是否能够据此采取行动。如果不符合某项要求，请明确指出该缺陷，而不是提出含糊的改进要求。

一次有价值的对比必须保持预期交付成果不变。如果你让一个系统写高管摘要，而让另一个系统做详细分析，这种输出就无法为评估模型适用性提供有意义的判断。请先将任务标准化，然后再审视各自的回答在哪里需要修正。

将结构化数据作为独立需求对待

Markdown 表格和用 XML 分隔的指令，并不等同于经过校验的机器可读输出。如果该输出供下游软件读取，请定义具体的输出 Schema。尽量使用模型原生的结构化输出功能，并在模型外部对结果进行校验。数据类型正确并不代表业务含义正确，因此必须单独执行业务规则校验。

实用落地示例

从一个有人能够进行复核的真实任务入手。识别模型必须接收的信息、允许其做出的决策，以及必须由人工承担责任的节点。在生成交付成果前，将这些边界写入需求简报。即使底层模型发生变化，这也能确保工作流清晰易懂。

返回包含 status、summary 和 source_ids 的 JSON 对象。如果缺乏依据，将 status 设为 needs_review，并将 source_ids 设为空数组。不要包含任何外围的解释说明。

根据原始需求来评估结果，而不是看它听起来有多完美。检查所需信息是否齐全、是否出现了缺乏依据的假设，以及目标读者是否能够据此采取行动。如果不符合某项要求，请明确指出该缺陷，而不是提出含糊的改进要求。

不要把排版惯例演变成某种教条。如果简单的标题结构在两个系统中都能很好地运作，那它可能就是最简便的通用标准。只在需要更清晰边界时才添加标签，而不是每个任务都硬套一套复杂的标记语言。

通过对照实验对比模型

使用相同的需求简报和资料来源在两个系统上运行，然后根据明确的评审标准进行对比。在输出波动较大的情况下，应包含多次重复测试。记录下确切的模型版本和相关设置，而不要把 ChatGPT 或 Claude 视为一种单一且一成不变的能力。产品名称背后对应的是持续变动的模型、工具和账户级特性。

实用落地示例

从一个有人能够进行复核的真实任务入手。识别模型必须接收的信息、允许其做出的决策，以及必须由人工承担责任的节点。在生成交付成果前，将这些边界写入需求简报。即使底层模型发生变化，这也能确保工作流清晰易懂。

从来源保真度、任务完成度、受众契合度和格式合规性四个方面为两组输出打分。引用具体段落作为依据。切勿仅仅因为某篇回答更为冗长就给予偏好。

根据原始需求来评估结果，而不是看它听起来有多完美。检查所需信息是否齐全、是否出现了缺乏依据的假设，以及目标读者是否能够据此采取行动。如果不符合某项要求，请明确指出该缺陷，而不是提出含糊的改进要求。

参考示例绝不应在暗中扩大使用敏感信息的权限。在将材料粘贴到任一系统之前，请检查该材料是否已被批准用于该环境。去除与本次任务处理无关的个人隐私信息和机密内容。

基于针对性反馈进行迭代

当草稿达不到预期时，请准确指出其不足之处。只要求“改好一点”无法给模型提供明确方向，还可能破坏原本表现不错的部分。保留已被认可的章节，并明确指定需要做出的最小改动。如果问题在于缺少论据，请补充论据，而不是要求模型更自信地重写一遍。

实用落地示例

从一个有人能够进行复核的真实任务入手。识别模型必须接收的信息、允许其做出的决策，以及必须由人工承担责任的节点。在生成交付成果前，将这些边界写入需求简报。即使底层模型发生变化，这也能确保工作流清晰易懂。

保留当前结构与已核实的事实。仅针对抱有怀疑态度的技术受众重写引言部分。删除未经证实的优势宣传，并将所有缺失的依据单独列出。

根据原始需求来评估结果，而不是看它听起来有多完美。检查所需信息是否齐全、是否出现了缺乏依据的假设，以及目标读者是否能够据此采取行动。如果不符合某项要求，请明确指出该缺陷，而不是提出含糊的改进要求。

一次有价值的对比必须保持预期交付成果不变。如果你让一个系统写高管摘要，而让另一个系统做详细分析，这种输出就无法为评估模型适用性提供有意义的判断。请先将任务标准化，然后再审视各自的回答在哪里需要修正。

可复用的操作清单

阶段	必需的决策	完成依据
需求简报	关注什么预期成果与受众？	书面写明目标和验收标准
输入材料	以哪些资料来源为准？	标注清晰、现行有效的源材料
执行过程	允许模型执行什么操作？	明确的工具使用与输出边界
审查复核	由谁来核验结果？	指定的审查人员与记录在案的修改意见
维护更新	何时应当调整指令？	版本负责人与评估说明记录

将此清单作为沟通协作的工具，而不是形式化的合规流程。如果某一行无法给出有实质意义的答案，说明该任务很可能定义不清。请补全缺失的决策，或主动缩小交付成果的范围。一份边界清晰的临时草稿，往往比建立在隐含假设之上的“表面完整”答案有用得多。

将简报付诸实践

PromptDeck 通过单张问题卡片逐步访谈的方式，将粗略的想法转化为一段可直接粘贴的提示词。快速模式（Quick）大约包含 8 个问题，标准模式（Standard）约 15 个问题，深度模式（Deep）约 25 个问题。请根据复杂度和后果影响来选择深度，而不是盲目认为访谈越长越好。

该方法涵盖目标、受众、背景、约束、语气、格式、示例、规避事项以及成功标准。PromptDeck 会为 ChatGPT 编写 Markdown 标题，为 Claude 编写 XML 标签。它还能在网络上检索真实发布的参考示例，并提供 ChatGPT/Claude 连接器。在依赖参考材料中的事实或将其作为风格参考之前，请先对其进行仔细审查。

平台提供一次免费提示词生成机会。专业版（Pro）价格为每月 9 欧元（包含 100 额度），或每年 79 欧元。免费试用 PromptDeck，选一个你已经足够了解且能够评估的任务来尝试。将生成结果与你平常的操作流程进行对比，记录哪些方面有所改善、哪些仍需修改，以及缺少哪项回答本可以避免后续的修改。

若想了解底层方法论，请阅读 Brief Prompting 指南 并学习 Brief Prompting。可以在提示词库中探索具体的起步参考，或回顾常见提示词错误。我们的目的不是收集更多模板，而是让每一个关键需求都变得更易明确定义和校验。

常见问题解答

更好的提示词能确保输出完全准确吗？

不能。清晰的指令改善了产出有用结果的前提条件，但模型仍可能误读来源或产生缺乏依据的主张。在做出重大决策或公开发布之前，请务必核实关键事实，并引入适当的人工复核。

提示词越长效果就一定越好吗？

不是。相关的上下文与清晰的优先级远比篇幅长短更重要。请剔除冗余内容并解决自相矛盾之处。只有在任务复杂度确实需要时才使用更长的简报，切勿用拉长篇幅来代替对核心要点的取舍决断。

同一份需求简报可以同时用于 ChatGPT 和 Claude 吗？

可以。保留目标、来源、约束和验收标准，然后在需要时微调呈现格式即可。Markdown 标题和 XML 标签只是便于整理的封装选择，既非强制要求，也不能单凭格式保证输出质量。

团队应该在何时使用访谈式引导，而非直接套用模板？

当需求提出者只有粗略想法，尚未理清受众、边界或成功标准时，请使用访谈式引导。当这些决策已经明确，且工作流使用可预测的输入反复运行时，请使用固化模板。

当缺乏依据材料时，我们该怎么做？

要求补充缺失的来源、缩小任务范围，或将结论标注为“未解决”。切勿鼓励模型自信满满地填补证据缺口。清晰指出局限所在，远比提供一个毫无事实支撑的答案更有价值。