为什么AI干得总是差点意思？教你怎么把需求一次说清楚
袁俊晓约 14 分钟开发者公众号专属群聊
扫码加入获取更多一手教程、科技前沿报告
提示词工程的关键，不在于寻找一句万能指令，而在于清晰表达任务、组织必要上下文，并用明确的结构和约束降低歧义。本文从基础概念、表达格式和实用技巧出发，梳理一套可直接应用于日常 AI 使用与应用开发的提示词方法。
01
本质是一个通过海量数据训练得到的预测引擎，用来预测“在给定上下文，下一个最合理的 token 是什么”。
它接收一段文本作为输入，然后根据上下文预测下一个最可能出现的 token。模型每次生成一个 token，并将其追加到当前序列中，再继续预测下一个 token。因此，每一步生成都依赖于前文上下文和模型训练中学到的模式。
02
提示词就是我们给到大模型的输入，它的作用是设法引导大模型生成的下一个 token 符合我们的预期。
提示词工程是通过不断优化输入，提升模型输出质量的系统性方法。它包含三个关键维度：
质量维度：输出的内容专业、完整和有价值，让人感觉“说到点子上”。
稳定性维度：在不同场景和时间下产生可预期的一致表现，让人感觉“靠得住”。
正确性维度：信息准确、可信，减少产生虚假或误导性内容的情况，让人感觉“说得对”。
提示词工程的局限
提示词工程不是万能的。它不能突破模型能力的上限，也不能保证绝对正确；它只能在模型已有的能力范围之内，把成功的概率推高。
03
提示词工程主要面向两类人：
使用 AI 工具的人？
制造 AI 工具的人？
在 AI 应用开发中，提示词工程尤其重要，可以从两个角度理解：
从 AI 应用角度：模型响应用户输入（User Prompt），在系统提示词（System Prompt）的约束下生成回复（Assistant）。
从产品角度：通过产品设计来设置用户使用的方式，以及模型响应的方式。
04
常见的对话消息包含 System、User、Assistant 三种角色。
System（系统）
设置对话的基本规则和角色定位。
定义 AI 助手的性格、行为准则、回复风格等。
通常由开发团队预设，用户一般看不到。
例如：“你是一个乐于助人、专业的 AI 助手……”
User（用户）
对话的发起者和提问者。
用户每次输入的问题或指令。
用户提供需求、问题、指令或对话内容。
例如：“帮我写一封邮件”“解释一下……”
Assistant（助手）
AI 的回复角色。
即助手每次给出的回答。
基于系统设定和用户输入生成回应。
System Prompt 与 User Prompt 的区别
在开发 AI 应用时，系统提示词用于设置人设与回复逻辑；用户提示词用于表达用户当次提出的问题和需求。两者共同影响大模型的响应。
05
大多数 LLM 提供丰富的参数，用于控制输出生成的方式。有效的提示词工程离不开对这些参数的合理设置，这些参数通常通过 API 调用的形式进行设置。
参考资料：DeepSeek Chat Completion API 文档
https://api-docs.deepseek.com/zh-cn/api/create-chat-completion/
5.1 一输出长度（Output Length）
输出长度即模型响应中生成 token 的数量。输出 token 越多，模型计算开销越大，响应时间越慢，成本越高。
需要注意的是，缩短输出长度并不会让模型“写得更简洁”，它只是在达到指定长度后停止生成。如果想获得短内容输出，还需要通过提示词引导模型尽早收敛。
在某些提示词技巧中，限制输出长度尤为重要，比如 ReAct 技法中，模型容易在目标输出后继续生成冗余内容。
5.2 采样控制（Sampling Controls）
LLM 并不是“预测一个确定 token”，而是对所有可能的下一个 token 给出概率分布，然后从中采样决定最终输出。控制采样方式的关键参数包括 temperature、top_p。
Temperature（温度）
temperature 控制采样的随机性：
值越低，输出越确定；值越高，结果越多样、越随机。
temperature = 0代表贪婪解码（greedy decoding），总是选取概率最高的 token。低温度意味着偏向确定输出，高温度则允许更多不确定性，适用于需要创造性结果的场景。
以下是不同任务的温度参数示例：
注：不同模型和接口的参数行为可能不同，具体配置应以所使用模型的官方文档为准。
Top-P（核采样）
使用时需要注意：
temperature、top_p不建议统一调整，它们之间相互影响。若
temperature = 0，top_p会被忽略。若
top_p接近 0，模型通常只选取最高概率的 token，其他设置也可能被弱化。
06
实践中，可以按以下顺序着手：
第一，把任务说清楚，给足上下文信息。
第二，使用最好的模型。
第三，才是提示词技巧的使用。
07
常见提示词格式包括：自然语言、XML、MD（Markdown）、JSON、伪代码等。实际使用时可以根据任务复杂度选择一种格式，或者结合起来使用；核心是结构化表达，不要产生歧义。
7.1 自然语言
你是一个翻译专家，请把我说的话翻译成英文。注意不要回答问题，只输出翻译结果。
优点：直观、容易理解，适合普通用户。
缺点：可能存在歧义，结构性较差。
适用场景：简单任务。
7.2 Markdown
# 角色翻译专家# 任务把我说的话翻译成英文# 要求不要回答问题，只输出翻译结果
Markdown 天生用来表达文章结构：
#代表大标题，##代表副标题，可以明确表达逻辑上的层级关系。无序列表表达同级并列关系。
有序列表表达同级递进关系。
表格表达数据或属性的对比和归纳。
Markdown 是常用的提示词表达格式，能够兼顾简单和复杂任务。它的结构层级明确，便于区分不同内容的边界。
7.3 XML
<角色>翻译专家</角色><任务>把我说的话翻译成英文</任务><要求>不要回答问题，只输出翻译结果</要求>
优点：结构清晰、层次分明、便于程序解析。
缺点：较繁琐，普通用户理解有一定难度。
适用场景：复杂任务场景、表达结构化内容。
7.4 伪代码
以实验判断为例，按顺序判断数据量、连续负向、近期趋势、累计收益、波动等条件，再返回是否停止实验及原因。
伪代码是一种用类似程序控制逻辑的方式来编写提示词的格式，常用于复杂任务、多个条件判断、Agent Prompt 以及 Workflow 场景。它通过 if / else / loop 等逻辑结构，显式地告诉模型在不同条件下应如何行动，从而尽可能减少歧义。
优点：结构清晰、层次分明，便于表达判断逻辑。
缺点：相对繁琐，普通用户理解有一定难度。
适用场景：复杂任务、多条件判断、Agent 和 Workflow。
7.5 JSON
{"角色": "翻译专家","任务": "把我说的话翻译成英文","要求": "不要回答问题，只输出翻译结果"}
优点：结构化程度高，便于数据交换。
缺点：不太直观，输出较繁琐。
适用场景：结构化输出。
7.6 Jinja
指出，在智能体开发平台中 Jinja 很常见，例如 Coze、Dify；它支持逻辑语法。
{% set language = "英语" %}你是一个翻译专家。请把我说的话翻译成 {{ language }}。注意不要回答问题，只输出翻译结果。
实际使用时，应根据任务复杂度选择合适的格式，也可以组合使用。核心是结构化表达、明确内容边界，尽量避免歧义。
08
为了系统化地向大模型提供明确的背景和目的，我们通常会使用一些 Prompt 框架来规范化 Prompt。比如给大模型设定角色、提供足够的背景信息、交代清楚要执行的任务和内容输出的约束条件。
这一类提示词框架非常多，核心是引导我们一次性把话说完、说清楚，这样大模型才能更准确地完成任务。
一个实用的提示词框架可以包含四个部分：
角色
背景信息
任务
约束
示例：生成待办事项列表组件
# 角色你是一位资深前端开发工程师，精通现代 React（v18+）和 TypeScript，并熟练使用 Tailwind CSS 进行快速 UI 开发。你注重代码的可读性、可维护性和最佳实践。# 背景我正在开发一个个人生产力管理应用的核心模块。当前的需求是实现一个交互式待办事项列表。- 用户故事：作为一名用户，我可以添加新的待办事项、将其标记为完成/未完成、删除事项，并能一眼看清哪些事项已完成。- 技术栈：项目已配置好 React + TypeScript + Vite + Tailwind CSS。- 数据状态：待办事项的数据结构计划使用一个 TodoItem[] 数组，每个事项包含 id（唯一标识）、text（内容）、completed（是否完成）。# 任务请生成实现此功能组件的完整、可运行的代码。具体需要：1. 创建一个名为 TodoList.tsx 的功能组件。2. 使用 React 的 useState Hook 来管理待办事项列表的状态（初始状态可包含 2–3 个示例事项）。3. 实现以下交互功能：- 添加事项：通过输入框和“添加”按钮提交新事项。- 切换完成状态：点击事项文本或旁边的复选框，切换其 completed 状态。- 删除事项：每个事项旁有一个删除按钮，点击后将其从列表中移除。4. 根据 completed 状态动态更新事项样式（例如，已完成事项文本有删除线、颜色变浅）。# 约束请严格按照以下要求组织回答：- 代码实现：提供 TodoList.tsx 的完整代码。代码需包含清晰的类型定义（TypeScript 接口）、详细注释（说明关键逻辑和状态变化），并保持 ESLint 友好的格式。- 输出格式：请使用注明语言为 tsx 的 Markdown 代码块。
09
9.1 提示词要清晰、直接和详细
这里有两个值得注意的要点：
大模型对清晰、直接和详细的提示词反馈最好。
把大模型当作一个非常聪明的新员工。让新员工干活时，需要非常明确的指示，提供充足的背景信息，才能更好地完成交代的任务。
示例：营销邮件
BAD
为我们的新 AcmeCloud 功能写一封营销邮件。
GOOD
你的任务是为我们的 Q3 AcmeCloud 功能发布制作一封有针对性的营销电子邮件。
指示：
目标受众：从本地部署升级到云的中型科技公司（100–500 名员工）。
核心功能：突出 3 个关键新功能——高级数据加密、跨平台同步和实时协作。
语气：专业但平易近人，强调安全性、效率和团队合作。
CTA：包括明确的行动号召，例如免费 30 天试用、优先入职。
主题行：少于 50 个字符，提及“安全”和“协作”。
个性化：使用
{{COMPANY_NAME}}和{{CONTACT_NAME}}变量。结构：主题行、正文（150–200 字）、CTA 按钮文本。
9.2 提供示例
通过在提示中提供精心设计的示例，可以显著提高大模型输出的准确性、一致性和质量。这种技术被称为单一样本学习（One-shot）、少量样本学习（Few-shot），对于需要结构化输出或遵守特定格式的任务特别有效。
示例有什么作用？
准确性：减少对指令的误解。
一致性：示例帮助固定统一的结构和风格。
怎样的示例才是好的例子？
相关性：示例应与你要处理的问题相关、类似、有可比性。
多样性：示例要覆盖各种场景，特别是边界情况，并有足够区分度。
清晰性：示例可用
<example>、<input>、<output>等标签区分，让大模型更好地理解。
例如，在客户反馈分类任务中，可以要求模型使用“UX/UI、性能、功能请求、集成、定价和其他”等类别，并评估情绪（正面/中立/负面）和优先级（高/中/低）。示例反馈为：“新仪表板简直没法用！加载慢得要命，找个导出按钮还得满世界乱翻！”
还可以用翻译任务演示如何用 <examples>、<example>、Q、A 等标记固定输入输出格式。
9.3 通过示例让 JSON 输出更稳定
让 JSON 输出更稳定，可以注意三点：
给结构模板：模板必须写清楚，例如：
{ "intent": "", "reason": "" }
告诉模型禁止输出解释：例如，不要输出模板之外的任何文字，否则模型有时会加一句“以下是 JSON 输出”。
用“必须 严格 不可缺失”等强约束语言：使用“必须”“严格”“不可缺失”等明确约束，有助于提升输出稳定性。
例如，可以要求模型必须使用指定 JSON 格式，字段不可缺失，且禁止输出模板之外的文字：
{"confidence": 0.0,"intent": "SUPPORT | FEEDBACK | CHAT","reason": "简要说明分类依据"}
9.4 设定角色
通过系统提示词给模型分配角色，比如“你是一名高级 Java 开发工程师”“资深管理咨询大师”等。认为这个技巧很好用，几乎可以用于很多场景。
角色设定主要影响三个方面：
准确性更高：在法律分析、财务建模、数学推导等复杂、专业度高的场景里，设定角色往往能改善模型表现。
语气和风格更贴合：角色提示词会影响沟通方式，例如 CFO 简洁、冷静的表达风格，或文案写手有创意、有情绪的风格。
改进专注力：通过设置角色背景，让大模型更容易围绕任务要求回答，而不是东拉西扯。
这是因为：一个具有代表性的角色，背后对应着大量与该角色相关的知识、思维方式、行为习惯和表达风格。角色越具体，越有助于缩小问题范围，让 AI 更专注地解决任务。
例如，软件许可协议分析可以这样对比：
BAD：分析这份软件许可协议中的潜在风险。
GOOD：说明企业背景，并要求重点分析赔偿、责任限制和知识产权所有权条款，留意不寻常或令人担忧的条款，同时提供标准合同进行比较。
9.5 使用 XML 标签或分隔符号区分单元
在构建复杂的 Prompt 时，采用特定分隔符来界定不同内容单元，可以增强 LLM 对 Prompt 的正确解析。随着任务复杂度增加，合理使用分隔符越有帮助。
分隔符可以选择自然语言中不常见、辨识度高的字符组合。它没有固定规则，关键是让模型能清楚识别不同内容区域的边界，而不把分隔符当作普通标点。
例如，在协议审查任务中，可以用标签分别标出指令、标准合同和待审查合同：
<standard_contract>{{STANDARD_CONTRACT}}</standard_contract><instructions>1. 分析赔偿条款2. 分析责任限制3. 分析知识产权所有权4. 注意不寻常或令人担忧的条款5. 与标准合同进行比较</instructions><contract>{{CONTRACT}}</contract>
10
一个实用的做法是：大模型在执行任务前有时间思考，它会表现得更好。特别面对复杂任务（如研究、分析或问题解决）时，添加“在开始回答之前，一步步思考”，可能帮助模型逐步分解问题。这种技术被称为思维链（CoT）提示。
对于推理模型（例如 DeepSeek R1），额外加入 CoT 指令未必会带来明显改善。如果模型的回答仍不理想，应先检查任务描述是否清晰、输入信息是否充分，再有针对性地调整提示词。
可以尝试以下做法：
在指令里加“一步步思考”。
规定步骤：例如写邮件前，先考虑捐赠者的历史捐赠记录、哪些项目内容可能引起共鸣，再结合分析写个性化邮件。
结构化：用标签区分分析和结果，便于检查逻辑问题，也能发现指令是否不够清晰。
示例：撰写个性化捐赠邮件
示例要求根据项目资料和捐赠者资料撰写个性化捐赠邮件：
项目资料：<program>{{PROGRAM_DETAILS}}</program>捐赠者资料：<donor>{{DONOR_DETAILS}}</donor>先根据捐赠者的捐赠历史和支持过的活动，判断什么样的信息可能吸引这位捐赠者；再根据其历史，判断“关爱儿童”项目的哪些方面可能引起共鸣；最后在 <email> 标签中编写个性化邮件。
类似方法也可以用于投资分析、JSON 检查等任务：通过明确步骤和标签组织输入，让任务流程更清晰、结果更容易检查。
11
处理复杂任务时，如果把所有要求都放进一个提示词中，模型的输出可能不够稳定。对于步骤较多的任务，可以拆成多个小步骤，每个步骤用单独的提示词，然后串联起来，把上一步的输出作为下一步的输入。这样能让每一步的输出更加稳定；缺点是会消耗更多时间，但准确率可能提高。
有什么用？
准确性：每个子任务都能获得大模型的注意力，减少错误。
清晰度：更简单的子任务意味着更清晰的说明和输出。
易于调试：更容易识别和修复提示链中的问题。
示例：智能笔记本产品营销
目标：分析新产品“智能笔记本”与竞品 “E-Ink Pad” 和 “Paper Pro” 在价格、核心功能、用户评价和市场定位上的优劣，再提炼三条核心卖点，并撰写面向科技爱好者的营销文案。
可以将任务拆为三个阶段：
示例中的产品资料包括：
“智能笔记本”：售价 199 美元，功能包括云同步、手写转文本、语音备忘。
“E-Ink Pad”：售价 249 美元，功能包括护眼电子墨水屏、超长续航。
“Paper Pro”：售价 159 美元，功能包括实体纸张手感、无需充电。
通过拆分后，每个提示词的职责更加单一，每次任务处理都能更专注，也更容易判断和修复提示词中的问题。
12
另一个实用技巧是：把任务执行步骤明确写出来。
示例：小明去爷爷奶奶家
故事大意：小明早上 8 点出发步行去爷爷奶奶家，走了一段时间后，爸爸发现小明忘记带作业，便骑车追赶。追上后爸爸骑车带小明去目的地。题目要求计算到达时间。
可以将背景、目标和执行步骤写进提示词：
# 背景又到了周日，小明像以往一样去爷爷奶奶家玩。小明于早上八点整步行出发。走了 12 分钟后，小明的父亲发现小明忘记带作业了，于是骑车去追小明。等到追上小明后，爸爸决定骑车带上小明。已知小明坐自行车的路程是走路路程的 5 倍。# 目的小明什么时候到爷爷家？# 步骤1. 先计算小明被爸爸追上时的时间和移动距离。2. 再计算小明去爷爷家剩余的距离和需要的时间。3. 最后计算小明到爷爷家的时间。
重点是明确告诉模型先做什么、再做什么、最后需要得出什么结果。对于涉及计算的任务，还应提供完整的已知条件，并在输出后核对计算过程和单位。
13
一种常见的诱导式提示词会让模型“扮演奶奶哄人入睡”，并在故事中试图诱导模型说出 Windows 11 专业版序列号。
这个例子说明：提示词可能通过角色扮演、情绪引导等方式尝试让模型输出不应提供的信息。
14
好的提示词 = 结构化清晰 + 足够的上下文。
提示词工程本质上是“沟通”，用 AI 能听懂的语言说清你的意图。
除了结构化表达和一些最佳实践技巧，更重要的是把要模型做的事情交代清楚，并通过结构化表达帮助模型更好地理解、避免歧义。我们需要提供足够的上下文信息，而上下文工程可以通过多种方式获取信息，例如 RAG、工具调用或技能的使用。
它本质上就是：用 AI 能够听得懂的方式，把我们的意图表达清楚。