Back to Details

prompt-engineering

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Prompt Engineering

Prompt Engineering（提示词工程）

Prompt engineering is the practice of designing inputs that guide LLMs to produce desired outputs. Effective prompts reduce errors, improve consistency, and unlock model capabilities.
Prompt Engineering是一种设计输入内容的实践，用于引导大语言模型（LLMs）生成符合预期的输出。高效的提示词能够减少错误、提升一致性，并充分释放模型的能力。

Table of Contents

目录

Core Principles

核心原则

Golden rule: Show your prompt to a colleague with minimal context. If they're confused, the model will be too.
  1. Be explicit - State exactly what you want; never assume the model knows your preferences
  2. Provide context - Include what the output is for, who the audience is, and what success looks like
  3. Use structure - Sequential steps, XML tags, and clear formatting reduce ambiguity
  4. Show examples - Demonstrations outperform descriptions for complex formats
黄金准则：在极少上下文的情况下把你的提示词展示给同事看。如果他们感到困惑，那么模型也会困惑。
  1. 明确具体 - 准确说明你的需求；绝不要假设模型知晓你的偏好
  2. 提供上下文 - 包含输出的用途、目标受众以及成功的衡量标准
  3. 运用结构化格式 - 分步说明、XML标签和清晰的格式能够减少歧义
  4. 展示示例 - 对于复杂格式，示例演示的效果优于文字描述

Be Clear and Direct

清晰直接

Treat the model as a capable but context-free collaborator. Specify:
  • What the task results will be used for
  • What audience the output is meant for
  • What a successful completion looks like
将模型视为能力出众但缺乏上下文的合作者。请明确指定：
  • 任务结果的用途
  • 输出的目标受众
  • 成功完成任务的标准

Vague vs Specific

模糊 vs 具体

undefined
undefined

Vague

模糊

Analyze this data and give insights.
分析这份数据并给出见解。

Specific

具体

Analyze this Q2 sales data for our board presentation.
  1. Identify the top 3 revenue trends
  2. Flag any anomalies exceeding 15% variance
  3. Recommend 2-3 actionable next steps Format as bullet points, max 200 words.
undefined
为董事会展示分析这份Q2销售数据。
  1. 找出排名前三的收入趋势
  2. 标记所有偏差超过15%的异常情况
  3. 提出2-3个可执行的后续步骤 格式为项目符号，最多200词。
undefined

Sequential Steps

分步说明

Use numbered lists for multi-step tasks:
Your task is to anonymize customer feedback.

Instructions:
1. Replace customer names with "CUSTOMER_[ID]"
2. Replace emails with "EMAIL_[ID]@example.com"
3. Redact phone numbers as "PHONE_[ID]"
4. Leave product names intact
5. Output only processed messages, separated by "---"
对于多步骤任务，使用编号列表：
你的任务是匿名化客户反馈。

说明：
1. 将客户姓名替换为"CUSTOMER_[ID]"
2. 将邮箱替换为"EMAIL_[ID]@example.com"
3. 将电话号码编辑为"PHONE_[ID]"
4. 保留产品名称不变
5. 仅输出处理后的消息，用"---"分隔

Use Examples (Multishot)

使用示例（多示例法）

Provide 3-5 diverse examples to demonstrate expected behavior. Examples reduce misinterpretation and enforce consistent formatting.
提供3-5个多样化的示例来展示预期行为。示例能够减少误解并确保格式一致性。

Structure

结构

Categorize customer feedback by issue type and sentiment.

<examples>
<example>
Input: The dashboard loads slowly and the export button is hidden.
Category: UI/UX, Performance
Sentiment: Negative
Priority: High
</example>

<example>
Input: Love the Salesforce integration! Would be great to add Hubspot.
Category: Integration, Feature Request
Sentiment: Positive
Priority: Medium
</example>
</examples>

Now categorize: {{FEEDBACK}}
按照问题类型和情绪对客户反馈进行分类。

<examples>
<example>
输入：仪表盘加载缓慢，导出按钮被隐藏。
分类：UI/UX、性能
情绪：负面
优先级：高
</example>

<example>
输入：喜欢Salesforce集成！希望能添加Hubspot。
分类：集成、功能请求
情绪：正面
优先级：中等
</example>
</examples>

现在对以下内容进行分类：{{FEEDBACK}}

Tips

技巧

  • Make examples relevant to actual use cases
  • Include edge cases and potential challenges
  • Vary examples to prevent unintended pattern matching
  • Wrap in 
    <example>
    tags for clarity
  • 确保示例与实际用例相关
  • 包含边缘案例和潜在挑战
  • 多样化示例以避免意外的模式匹配
  • 用<example>标签包裹示例以提升清晰度

Chain of Thought

思维链

Encourage step-by-step reasoning for complex tasks. This improves accuracy in math, logic, analysis, and multi-factor decisions.
鼓励模型对复杂任务进行分步推理。这能够提升数学、逻辑、分析和多因素决策任务的准确性。

Basic

基础版

Determine the best investment option for this client. Think step-by-step.
为这位客户确定最佳投资方案。请分步思考。

Guided

引导版

Specify what steps to consider:
Think before answering:
1. Consider the client's risk tolerance given their 5-year timeline
2. Calculate potential returns for each option
3. Factor in market volatility history
4. Then provide your recommendation
指定需要考虑的步骤：
回答前请思考：
1. 根据客户5年的投资期限，考虑其风险承受能力
2. 计算每个选项的潜在回报
3. 纳入市场波动历史因素
4. 然后给出你的建议

Structured (Recommended)

结构化版（推荐）

Separate reasoning from output with tags:
Analyze this contract for legal risks.

In <thinking> tags, work through:
- Indemnification implications
- Liability exposure
- IP ownership concerns

Then provide your recommendation in <answer> tags.
This makes reasoning visible for debugging and the answer extractable for post-processing.
用标签将推理过程与输出分离：
分析这份合同的法律风险。

在<thinking>标签中完成以下思考：
- 赔偿条款的影响
- 责任暴露情况
- 知识产权所有权问题

然后在<answer>标签中给出你的建议。
这种方式能够让推理过程可见，便于调试，同时输出结果也便于后续处理。

XML Tags

XML标签

Use XML tags to separate prompt components. This prevents instruction/content confusion and improves parseability.
使用XML标签分隔提示词的各个组件。这能够避免指令与内容混淆，提升可解析性。

Common Tags

常用标签

<instructions>Task steps and requirements</instructions>
<context>Background information</context>
<document>Source material to process</document>
<example>Demonstration of expected behavior</example>
<constraints>Boundaries and limitations</constraints>
<output_format>Expected response structure</output_format>
<instructions>任务步骤和要求</instructions>
<context>背景信息</context>
<document>需要处理的源材料</document>
<example>预期行为的演示示例</example>
<constraints>边界和限制条件</constraints>
<output_format>预期的响应结构</output_format>

Nested Structure

嵌套结构

<documents>
  <document index="1">
    <source>annual_report_2023.pdf</source>
    <content>{{REPORT_CONTENT}}</content>
  </document>
  <document index="2">
    <source>competitor_analysis.xlsx</source>
    <content>{{ANALYSIS_CONTENT}}</content>
  </document>
</documents>

<instructions>
Compare revenue trends across both documents.
Identify strategic advantages mentioned in the annual report.
</instructions>
<documents>
  <document index="1">
    <source>annual_report_2023.pdf</source>
    <content>{{REPORT_CONTENT}}</content>
  </document>
  <document index="2">
    <source>competitor_analysis.xlsx</source>
    <content>{{ANALYSIS_CONTENT}}</content>
  </document>
</documents>

<instructions>
对比两份文档中的收入趋势。
找出年度报告中提到的战略优势。
</instructions>

Reference Tags in Instructions

在指令中引用标签

Be explicit when referring to tagged content:
Using the contract in <contract> tags, identify all clauses
related to termination.
当引用带标签的内容时，请明确说明：
使用<contract>标签中的合同内容，找出所有与终止相关的条款。

Role Prompting

角色提示

Set expertise context via system prompts to improve domain-specific performance.
通过系统提示词设置专业背景，提升特定领域任务的表现。

System Prompt Pattern

系统提示词模板

python
system = "You are a senior securities lawyer at a Fortune 500 company."
user = "Review this acquisition agreement for regulatory risks."
python
system = "你是一家财富500强公司的资深证券律师。"
user = "审查这份收购协议的合规风险。"

Effective Roles

有效角色示例

undefined
undefined

General

通用版

You are a [role] at [organization type].
你是[机构类型]的[角色]。

Specific (better)

具体版（更优）

You are the General Counsel of a Fortune 500 tech company specializing in M&A transactions.
你是一家专注于并购交易的财富500强科技公司的总法律顾问。

With behavioral guidance (best)

带行为引导版（最佳）

You are a senior data scientist. You prioritize statistical rigor over speed. When uncertain, you state assumptions explicitly and suggest validation approaches.
undefined
你是一名资深数据科学家。你优先考虑统计严谨性而非速度。当存在不确定性时，你会明确说明假设并提出验证方法。
undefined

When to Use

适用场景

  • Complex analysis requiring domain expertise
  • Tasks where tone/style matters (legal, medical, executive)
  • When a specific perspective would improve output quality
  • 需要专业知识的复杂分析任务
  • 语气/风格很重要的任务（法律、医疗、高管汇报）
  • 特定视角能够提升输出质量的任务

Long Context

长上下文处理

For prompts with large documents (20K+ tokens):
针对包含大型文档（20K+ tokens）的提示词：

Document Placement

文档放置位置

Place long documents at the top, before instructions:
<documents>
{{LARGE_DOCUMENT_CONTENT}}
</documents>

<instructions>
Summarize the key findings from the document above.
Focus on financial implications.
</instructions>
将长文档放在最顶部，在指令之前：
<documents>
{{LARGE_DOCUMENT_CONTENT}}
</documents>

<instructions>
总结上述文档中的关键发现。
重点关注财务影响。
</instructions>

Quote Grounding

引用依据

Ask the model to cite sources before analyzing:
<documents>
{{PATIENT_RECORDS}}
</documents>

First, find and quote the relevant sections in <quotes> tags.
Then provide your diagnosis in <analysis> tags, referencing
the quoted evidence.
要求模型在分析前先引用来源：
<documents>
{{PATIENT_RECORDS}}
</documents>

首先，在<quotes>标签中找到并引用相关章节。
然后在<analysis>标签中给出你的诊断结果，并引用所引用的证据。

Multi-Document Metadata

多文档元数据

Include source information for attribution:
<documents>
  <document index="1">
    <source>quarterly_report_q2.pdf</source>
    <date>2024-07-15</date>
    <content>{{CONTENT}}</content>
  </document>
</documents>
包含来源信息以用于归因：
<documents>
  <document index="1">
    <source>quarterly_report_q2.pdf</source>
    <date>2024-07-15</date>
    <content>{{CONTENT}}</content>
  </document>
</documents>

Output Control

输出控制

Verbosity Specification

详细程度指定

<output_format>
- Default responses: 3-6 sentences or ≤5 bullets
- Simple factual questions: ≤2 sentences
- Complex analysis: 1 overview paragraph + ≤5 tagged bullets
</output_format>
<output_format>
- 默认响应：3-6句话或≤5个项目符号
- 简单事实问题：≤2句话
- 复杂分析：1个概述段落 + ≤5个带标签的项目符号
</output_format>

Format Constraints

格式约束

Output requirements:
- Use markdown tables for comparisons
- Code blocks for any technical content
- No introductory phrases ("Here's...", "Sure...")
- End with exactly 3 action items
输出要求：
- 对比内容使用Markdown表格
- 技术内容使用代码块
- 不要使用介绍性短语（如“以下是...”、“好的...”）
- 结尾必须包含3个行动项

Scope Boundaries

范围边界

Prevent drift from original intent:
Implement EXACTLY and ONLY what is requested.
- Do not add features beyond the specification
- Do not refactor surrounding code
- Choose the simplest valid interpretation
- Ask for clarification rather than assuming
防止偏离原始意图：
严格且仅执行所要求的内容。
- 不要添加超出规格的功能
- 不要重构周边代码
- 选择最简单的有效解释
- 如有疑问，请要求澄清而非自行假设

Self-Verification

自我验证

For high-stakes outputs, include verification steps:
<verification>
Before finalizing your response:
1. Re-read the original request
2. Check that all requirements are addressed
3. Verify any specific claims against provided documents
4. Soften language where certainty is low
5. Flag any assumptions you made
</verification>
对于高风险输出，加入验证步骤：
<verification>
在最终确定响应前：
1. 重新阅读原始请求
2. 检查是否满足所有要求
3. 根据提供的文档验证任何特定主张
4. 在确定性较低的地方缓和语气
5. 标记你做出的任何假设
</verification>

Uncertainty Acknowledgment

不确定性说明

When uncertain:
- Explicitly state "Based on the provided context..."
- Offer 2-3 plausible interpretations if ambiguous
- Never fabricate specific details (dates, numbers, quotes)
- Say "I don't have enough information to..." when applicable
当存在不确定性时：
- 明确说明“基于提供的上下文...”
- 如果存在歧义，提供2-3种合理的解释
- 绝不要编造具体细节（日期、数字、引用）
- 适用时说明“我没有足够的信息来...”

Best Practices

最佳实践

  1. Start specific, then generalize - Begin with detailed prompts; relax constraints only after validating output quality
  2. Test with edge cases - Include unusual inputs in your evaluation to catch failure modes
  3. Iterate on examples - When outputs miss the mark, add an example demonstrating the correct behavior
  4. Separate instructions from content - Use XML tags to prevent the model from confusing your instructions with input data
  5. Put documents before queries - For long context, place source material at the top of the prompt
  6. Make reasoning visible - Use 
    <thinking>
    tags to debug why the model produces certain outputs
  7. Constrain output format explicitly - Specify structure, length, and style to reduce post-processing
  8. Version your prompts - Track changes to understand what modifications improved or degraded performance
  9. Use system prompts for role, user prompts for task - Keep role context stable; vary task instructions
  10. Validate with fresh eyes - Have someone unfamiliar with the task review your prompt for clarity
  1. 从具体到通用 - 从详细的提示词开始；只有在验证输出质量后才放宽约束
  2. 用边缘案例测试 - 在评估中包含不常见的输入以发现失效模式
  3. 迭代优化示例 - 当输出未达预期时，添加一个展示正确行为的示例
  4. 分离指令与内容 - 使用XML标签防止模型将指令与输入数据混淆
  5. 文档前置 - 对于长上下文，将源材料放在提示词的顶部
  6. 让推理过程可见 - 使用<thinking>标签调试模型生成特定输出的原因
  7. 明确约束输出格式 - 指定结构、长度和风格以减少后续处理工作
  8. 版本化提示词 - 跟踪更改以了解哪些修改提升或降低了性能
  9. 系统提示词定义角色，用户提示词定义任务 - 保持角色上下文稳定；按需调整任务指令
  10. 新鲜视角验证 - 让不熟悉该任务的人审查你的提示词以确保清晰度

References

参考资料