没有神奇的咒语。没有任何隐藏的命令能让大语言模型变成神谕，也没有任何秘密的前缀能让 Claude 突然比你更了解你的业务。提示工程并不是在破解某种代码。它是一种与一位能力极强的同事进行清晰沟通的纪律——这位同事读过互联网上的海量信息，但从未见过你，没去过你的办公室，也没听过你的产品推介。把 Claude 当作入职第一天的聪明新员工来对待。他们渴望提供帮助，但如果你给出的指令模糊不清，得到的结果也会模糊不清。这里适用的规则与任何办公室里的规则一样：垃圾进，垃圾出。
把 Claude 当作新员工对待
想象你正在为一名才华横溢的承包商办理入职。你绝不会在第一天走过去说：“修一下网站”，然后就走开。这种指令是毫无用处的。哪个页面？哪里坏了？受众是谁？成功的标准是什么？然而，人们每天都在输入 AI 版的“修一下网站”，并纳闷为什么输出的结果总是差之毫厘。
首先要假设 Claude 对你的具体情况一无所知。它了解语法、编程模式和历史知识，但除非你明确说明，否则它并不了解你公司的语调、客户的痛点或法律限制。优秀的提示词编写本质上就是优秀的管理。你正在设定约束条件、定义受众并明确交付物。做好这些，模型的现有知识就会突然变得有用起来。
一个扎实提示词的五个组成部分
每个专业的提示词都应包含五个不同的元素。你不需要为每一个元素都写一篇长篇大论，但在按下回车键之前，你应该涵盖所有这些方面。
角色
告诉模型它是谁。这决定了词汇、视角和优先级。“你是一名技术编辑”可以，但“你是一名技术编辑，负责为初涉区块链领域的金融科技开发者简化 API 文档”效果要好得多。人设越具体，输出就越精准。
上下文
解释背景。谁在阅读这些内容？目标是什么？一篇针对医院管理人员的网络安全博客文章，其语气应该与针对青少年玩家的文章截然不同。上下文还包括风险程度。你是在进行头脑风暴，还是在撰写即将发布的最终稿？
任务
使用精确的动词。避免使用“改进”、“增强”或“优化”这类模糊的词。这些词毫无意义。相反，你应该写：“将转录文本总结为三个要点，每个要点不超过 20 个字。”或者：“重构此函数以使用 async/await 并添加针对超时情况的错误处理。”任务是你的指令，所以请发出指令，而不是表达愿望。
格式
在 Claude 开始写作之前定义答案的形式。你想要编号列表、Markdown 表格、有效的 JSON、带有主题行的电子邮件，还是法律简报？如果你需要带有特定列的对比表，请指明列名。如果你希望输出在带有注释的代码块中，请说明。格式指令可以防止你在需要结构化数据时却收到一大堆长篇大论。
约束
列出需要避免的内容。这包括语调、长度、禁用词和禁忌话题。例如：“回复控制在 150 字以内。使用对话式的语调。不要使用‘synergy’这个词。避免建议需要超过 500 美元预算的解决方案。”约束就是护栏。模型可以很好地处理它们，但前提是你必须清晰地表达出来。
获得更好结果的四种技巧
一旦掌握了基础知识，你就可以通过几种高级方法来优化你的方法。这些方法都不需要特殊的培训。它们只是组织思维的方式，以便模型能够遵循。
将复杂工作分解为步骤
不要一次性要求完成所有事情。如果你需要一个营销活动，先从受众分析开始。审查该输出，然后要求编写信息。接着要求选择渠道。这种分阶段的方法让你能够及早发现偏差。它还能防止模型在试图一次性平衡十个相互竞争的要求时把自己搞得晕头转向。对于编程任务，先要求架构设计，然后是实现，最后是测试。每一步都建立在前一步的基础上，让你始终保持掌控。
要求展示推理过程
思维链提示（Chain-of-thought prompting）简单来说就是要求 Claude 在给出最终答案之前展示其思考过程。像“请逐步展示你的推理过程，然后给出结论”这样的短语，在处理逻辑问题、数学题和代码调试时效果显著。当你能看到模型是如何得出答案时，你就能精准发现它是在哪个环节误解了需求，或者从数据集中抓取了错误的值。它能将一个“黑盒”变成一个可以审计的过程。
使用 XML 标签分隔信息
当提示词包含大段文本时，模型可能会混淆源材料和指令。请使用 <context>、<task> 或 <example> 等标签将不同的部分包裹起来。例如：
这种结构就像文档中的标题。它能防止模型误将背景信息当作任务的一部分，同时也让你以后编辑长提示词变得更加容易。
多展示，少说教
少样本提示（Few-shot prompting）意味着提供两到四个你想要的风格或格式的示例。模型是模式匹配引擎。它们从示例中学习的速度通常比从密集的描述中学习更快。如果你想将会议记录转化为行动项，请先粘贴两个原始记录的示例，随后紧跟你期望的精确结构化输出。Claude 会以惊人的准确度匹配新输入的模式。用十句话来描述格式，通常不如展示三个简洁的示例有效。
即插即用的模板
如果你面对着空白的提示框发愁，可以参考这个框架。填满每一个括号，即使答案很短。
Role: [插入具体角色及相关专业知识] Context: [插入背景、受众和目标] Task: [使用强有力的动词插入具体动作] Format: [插入所需的结构：列表、表格、文章、JSON 等] Constraints: [插入语气、长度、禁用词或需要避开的话题]
以下是填写完整的示例：
Role: 你是一家 B2B 薪酬初创公司的产品营销经理。 Context: 我们正在推出一项功能，为中型市场公司自动处理州税申报。受众是那些埋头于合规文书工作的 HR 总监。目标是让他们预约演示。 Task: 写一封 120 字左右的电子邮件，开头描述手动申报的痛苦，结尾委婉地请求安排一次 15 分钟的通话。 Format: 主题行、两个简短的正文段落以及一个行动号召（CTA）按钮标签。 Constraints: 不要使用像“synergy（协同效应）”或“bandwidth（带宽/精力）”之类的术语。语气专业但亲切。不要使用感叹号。
这个提示词给了 Claude 所需的一切。结果不会是完美的，但它会足够接近，让你只需要进行编辑，而不是从头开始重写。
核心要点
你并不需要为每一个请求都构建一个五部分组成的杰作。问“小扁豆怎么做才好吃？”并不需要角色或 XML 标签。但当输出结果至关重要、任务很复杂，或者你已经连续得到了三个糟糕的答案时，请运行一遍这个清单。大多数失败的提示词都是因为人类还在“边想边说”。花三十秒时间决定你真正想要什么、受众是谁以及它应该是什么样子。提前做好这些思考，你就会花更少的时间去清理回复内容。清晰的指令带来清晰的结果。除此之外的一切都只是噪音。