02｜写好提示词的第一课：把需求说清楚

场景引入：一份”看了等于没看”的需求文档

如果你做过软件开发，一定经历过这种场景：产品经理扔来一句”做一个用户管理模块”，然后消失了。你满脑子问号——管理哪些用户？需要哪些字段？要不要支持批量导入？权限怎么分？审批流程是什么？

你硬着头皮开发了一版，产品经理看了摇头：“不是这样的。”

给AI下指令和写需求文档是一回事。一条模糊的 prompt 就像一份只有标题没有正文的需求文档——AI只能靠猜，猜对了是运气，猜错了才是常态。

本章介绍六个写好提示词的基本原则。这些原则来自实践总结，也与 OpenAI 和 Anthropic 官方发布的 prompt 最佳实践高度一致（参见 OpenAI Prompt Engineering Guide 和 Anthropic Prompt Engineering Guide）。每一条都配有对比示例，让你看到”改一点点，效果差很多”的具体落差。

---

原则一：明确具体（Be Specific）

最常见的 prompt 问题就是太笼统。“说一说""分析一下""帮我看看”这类指令把所有决策权都交给了模型，而模型并不知道你心里想要什么。

对比示例 1：数据分析

模糊的 prompt：

分析一下我们公司的销售数据。

AI 回复（节选）：

销售数据分析是企业经营中非常重要的环节。通常我们可以从以下几个维度来分析：销售额趋势、客户分布、产品结构、季节性波动…

AI 给了一篇”什么是销售数据分析”的科普文——因为它不知道你的数据长什么样，也不知道你想分析什么。

明确的 prompt：

以下是我们 2025 年 Q4 各区域的销售额数据（单位：万元）：
- 华东：3200
- 华南：2800
- 华北：1950
- 西南：1100
- 其他：650

请完成以下分析：
1. 计算各区域占总销售额的百分比
2. 找出同比增长最快和最慢的区域（Q3 数据：华东 2900、华南 2650、华北 2100、西南 980、其他 700）
3. 用一段 50 字以内的结论概括关键发现

AI 回复（节选）：

1. 各区域占比：华东 33.0%、华南 28.9%、华北 20.1%、西南 11.3%、其他 6.7%
2. 同比增长：西南增长最快（+12.2%），华北下降最多（-7.1%）
3. 结论：华东华南仍是主力市场，西南区域增长势头强劲，华北出现下滑需重点关注。

对比示例 2：技术方案

模糊的 prompt：

怎么优化数据库？

明确的 prompt：

我的 PostgreSQL 数据库中有一张 orders 表，数据量约 800 万行。
以下查询在高峰期耗时超过 3 秒：

SELECT order_id, total_amount, created_at
FROM orders
WHERE user_id = 12345 AND status = 'paid'
ORDER BY created_at DESC
LIMIT 20;

目前 user_id 上有单列索引，status 上没有索引。
请给出 3 条具体的优化建议，每条说明原因和预期效果。

核心技巧：把”说一说""分析一下”替换为具体的动作动词——“列出 5 个""对比 A 和 B""计算百分比""给出 3 条建议”。数字是消除模糊性的利器。

---

原则二：提供上下文（Give Context）

模型的知识来自训练数据，但它不知道你的具体处境。同一个”怎么处理”的问题，在不同场景下答案天差地别。

对比示例

缺乏上下文的 prompt：

帮我写一封拒绝邮件。

AI 回复：

尊敬的XXX：感谢您的来信。经过慎重考虑，我们遗憾地通知您…

一封没有温度的模板。

提供上下文的 prompt：

背景：我是一家 30 人创业公司的技术负责人。一位合作了半年的外包供应商
提交了续约报价，但价格比市场均价高出 40%。我们决定不续约，
但希望保持良好关系，因为未来可能还有合作机会。

请帮我写一封邮件，礼貌地婉拒续约，同时表达对过去合作的认可，
并留下未来合作的可能性。语气专业但不生硬，300 字以内。

AI 回复：

张总，您好：

感谢贵团队过去半年在项目中的专业支持，特别是在系统迁移阶段的快速响应，给我们团队留下了很深的印象。

关于续约事宜，经过内部评估，我们当前阶段的技术方向有所调整，短期内将以自建团队为主推进后续开发工作。因此本轮续约暂不推进。

这并不影响我们对贵团队能力的认可。后续如有适合的合作场景，我们会第一时间与您沟通。再次感谢过去的愉快合作，祝业务蒸蒸日上。

上下文让AI理解了人际关系的微妙之处——不是冷冰冰地拒绝，而是”有铺垫、有肯定、留余地”。

上下文应该包含什么

并不是所有信息都需要塞进 prompt。有效的上下文通常包含：

• 你是谁：角色、职位、所在团队
• 面对什么场景：项目阶段、技术栈、业务约束
• 目标受众：输出内容是给谁看的
• 已有的信息：数据、文档片段、之前的结论
• 已知的限制：预算、时间、技术栈约束

---

原则三：指定格式（Specify Format）

如果你不告诉AI要什么格式，它会自作主张——有时给你一篇文章，有时给你一堆无序文字。对格式有要求时，必须明确指定。

对比示例

不指定格式：

列出 Python 中常用的数据结构。

AI 回复：

Python 中常用的数据结构包括列表（list）、元组（tuple）、字典（dict）、集合（set）。列表是有序可变的序列，元组是有序不可变的序列…

一大段文字，信息密度低，不便查阅。

指定格式：

列出 Python 中 4 种常用的内置数据结构，用 Markdown 表格呈现，
列包括：名称、类型关键字、是否可变、是否有序、典型使用场景。

AI 回复：

名称	类型关键字	是否可变	是否有序	典型使用场景
列表	list	可变	有序	存储同类元素的集合，如日志列表
元组	tuple	不可变	有序	函数返回多个值，数据库查询行
字典	dict	可变	有序(3.7+)	键值对映射，如配置项、JSON 数据
集合	set	可变	无序	去重、集合运算（交集、并集）

常用格式类型

根据不同的使用场景，你可以要求以下格式：

• Markdown 表格：适合对比、速查
• 编号列表：适合步骤说明、排序
• JSON：适合程序解析
• 代码块：适合代码生成
• YAML：适合配置文件
• 分节标题 + 正文：适合长文

# 要求 JSON 输出的示例
将以下三条用户反馈分类，输出 JSON 数组，每个元素包含
original（原文）、category（分类：功能建议/体验问题/正面评价）、
priority（优先级：高/中/低）三个字段。

反馈 1：登录页面加载太慢，经常转圈超过 10 秒
反馈 2：希望增加深色模式
反馈 3：这个新功能太好用了，节省了我很多时间

AI 回复：

[
  {
    "original": "登录页面加载太慢，经常转圈超过 10 秒",
    "category": "体验问题",
    "priority": "高"
  },
  {
    "original": "希望增加深色模式",
    "category": "功能建议",
    "priority": "中"
  },
  {
    "original": "这个新功能太好用了，节省了我很多时间",
    "category": "正面评价",
    "priority": "低"
  }
]

---

原则四：设定约束（Set Constraints）

没有约束的指令就像没有边界的画布——模型可能画到天边去。约束帮你框定输出的范围。

常见约束类型

字数约束：

# 模糊
写一段公司简介。

# 明确
写一段公司简介，100-150 字，包含核心业务、成立年份和服务客户数量。

风格约束：

用技术博客的风格解释微服务架构，语气专业但不晦涩，
面向有 1-2 年开发经验的工程师。避免使用"众所周知""不言而喻"等空洞表述。

排除约束：

推荐 5 个适合小团队使用的项目管理工具。
约束：不包含已停止维护的产品，不包含月费超过 50 美元/人的方案。

对比示例

无约束：

帮我写一个产品发布会的开场白。

AI 回复：800 字的长篇演讲稿，充满”在这个日新月异的时代""怀着激动的心情”之类的套话。

有约束：

为一场线上直播的产品发布会写开场白。
约束：
- 120 字以内
- 前两句必须抛出一个与用户痛点相关的问题来吸引注意力
- 不使用"日新月异""翘首以盼"等陈词滥调
- 以"今天，我们带来了一个答案"作为结尾过渡句

AI 回复：

每次切换三个以上的工具才能完成一项简单任务，你有没有算过每天在”找东西”上浪费了多少时间？我们调研了上千位用户，发现这个数字平均是 47 分钟。今天，我们带来了一个答案。

约束越具体，AI的发挥空间越小，但命中你预期的概率越高。

---

原则五：分步指令（Break into Steps）

当任务比较复杂时，一口气把所有要求塞在一段话里，模型容易顾此失彼。更有效的做法是把任务拆解为编号步骤。

对比示例

一股脑的 prompt：

帮我分析这篇技术文章的结构，总结核心观点，找出论证不严谨的地方，
然后改写成一篇面向管理层的 500 字摘要。

模型可能会把分析、总结、找问题、改写混在一起输出，结构混乱。

分步指令的 prompt：

请对以下技术文章执行四步处理：

步骤 1：梳理文章结构
- 列出文章的各级标题和段落主旨

步骤 2：提取核心观点
- 用 3-5 个要点概括文章的关键论述

步骤 3：指出论证薄弱环节
- 找出缺乏数据支撑或逻辑跳跃的地方，引用原文并说明问题

步骤 4：改写为管理层摘要
- 500 字以内
- 去除技术细节，聚焦业务影响和决策建议
- 使用"现状 → 问题 → 建议"的结构

文章原文：
[粘贴文章]

分步指令的优势在于：

• 每一步的目标明确，模型不会遗漏
• 步骤之间有递进关系，后一步建立在前一步的基础上
• 输出结构清晰，便于你逐项审阅

什么时候需要分步

并不是所有 prompt 都需要分步。判断标准很简单：

• 简单任务（翻译一句话、解释一个概念）：直接写即可
• 中等任务（写一封邮件、做一次对比分析）：一段话加几个要点
• 复杂任务（多阶段分析、涉及多种输出格式）：分步指令

---

原则六：说做什么，而非不做什么（Tell What TO Do）

人类的沟通习惯中经常使用否定句——“别太长""不要用专业术语""不要列举太多”。但对模型来说，否定指令的效果往往不如肯定指令。

原因在于模型的工作方式：它通过概率预测下一个 token，而否定句实际上会激活被否定的概念。当你说”不要提到价格”，模型在处理这句话时反而会把”价格”这个概念加载到注意力中。

对比示例

否定表述：

介绍一下容器化技术。不要太长，不要太技术化，不要用英文术语。

肯定表述：

用 150 字向一位非技术背景的项目经理介绍容器化技术。
用日常类比解释核心概念，所有术语使用中文。

否定表述：

写一段代码注释。不要写废话，不要重复代码本身的含义。

肯定表述：

为以下函数写一段注释，说明它的业务用途、参数含义和返回值，
不超过 3 行。重点解释"为什么这样做"而非"做了什么"。

当然，否定指令不是完全不能用。当你发现模型反复犯某个特定错误时，直接说”不要做X”作为补充约束是完全合理的。关键是：以肯定指令为主，否定指令为辅。

---

进阶技巧：用 XML 标签组织复杂提示词

当 prompt 变得又长又复杂时，纯文本容易让不同部分的边界模糊。Anthropic 在官方文档中推荐使用 XML 标签来结构化提示词，这种做法对 Claude 系列模型效果尤为显著，对其他模型也有不错的通用性。

为什么用 XML 标签

XML 标签提供了一种无歧义的方式来划分 prompt 的不同区域。模型能清晰地识别”这是指令""这是待处理的数据""这是输出要求”。

实际示例

<role>
你是一位精通中英双语的技术文档审校专家。
</role>

<task>
审校以下翻译稿，检查术语一致性、语句通顺度和技术准确性。
</task>

<terminology>
- API Gateway → API 网关
- Load Balancer → 负载均衡器
- Circuit Breaker → 熔断器
- Rate Limiting → 限流
</terminology>

<source>
The API Gateway routes incoming requests to downstream services.
When a service is unhealthy, the Circuit Breaker prevents cascading failures
by returning a fallback response.
</source>

<translation>
API 网关将传入的请求路由到下游服务。当某个服务不健康时，
熔断器通过返回回退响应来防止级联故障。
</translation>

<output_format>
1. 逐句对照，指出翻译问题（如有）
2. 给出修改建议
3. 最终输出审校后的完整译文
</output_format>

常用标签

以下是一些实践中常用的标签名，你可以根据自己的习惯命名：

标签	用途
<role>	角色设定
<task> / <instruction>	任务指令
<context>	背景信息
<input> / <data>	待处理的数据
<example>	示例
<constraints>	约束条件
<output_format>	输出格式要求

标签命名没有强制标准，关键是语义清晰、前后一致。

---

六个原则的协同实战

最后，让我们用一个完整的例子把六个原则融会贯通。

需求：你的团队要在技术博客上发布一篇关于 Redis 缓存策略的文章，你想让AI帮忙生成大纲。

初始 prompt（仅满足部分原则）：

帮我写一篇关于 Redis 缓存的文章大纲。

按六个原则优化后的 prompt：

<role>
你是一位有 5 年分布式系统经验的后端工程师，同时在技术社区有丰富的写作经验。
</role>

<task>
为一篇技术博客文章生成结构化大纲，主题是"Redis 缓存策略的选型与实践"。
</task>

<context>
- 目标读者：有 1-3 年经验的后端工程师，了解 Redis 基础但缺乏生产环境缓存设计经验
- 发布平台：公司技术博客，风格务实，强调可落地的实践经验
- 篇幅预期：正文 3000-4000 字
</context>

<constraints>
- 大纲层级不超过三级（章 → 节 → 要点）
- 必须包含至少 2 个真实业务场景的案例分析
- 必须涵盖：Cache Aside、Read/Write Through、Write Behind 三种策略的对比
- 不要写成教科书风格，要有工程判断和踩坑经验
</constraints>

<output_format>
Markdown 格式的大纲，每个章节标注预估字数，关键小节用一句话说明核心内容。
</output_format>

这个 prompt 中：

• 明确具体：不是”写一篇文章”，而是”生成结构化大纲”
• 提供上下文：说明了读者画像、发布平台、篇幅要求
• 指定格式：Markdown 大纲，标注字数
• 设定约束：层级限制、必含内容、风格要求
• 分步隐含：通过 XML 标签将不同层面的要求分区
• 肯定表述：“要有工程判断和踩坑经验”而非”不要写得太理论”

---

本章回顾

原则	核心要点	快速检查
明确具体	用具体动词和数字取代模糊表述	prompt 中有没有”说一说""分析一下”？
提供上下文	告诉AI你是谁、面对什么场景	AI能否仅凭 prompt 理解你的处境？
指定格式	需要什么格式就明确说	你对输出形式有预期吗？说了吗？
设定约束	字数、风格、排除条件	如果AI写了 2000 字你觉得太长，prompt 里有字数要求吗？
分步指令	复杂任务拆解为编号步骤	你的 prompt 包含超过 3 个不同类型的要求吗？
说做什么	肯定指令优先，否定指令为辅	数一数 prompt 里”不要”出现了几次

思考题

1. 找一个你日常工作中经常让AI做的任务（写邮件、翻译、代码审查等），用本章的六个原则重写你的 prompt，对比前后效果。
2. 尝试用 XML 标签重新组织你写过的最长的一条 prompt，看看结构化之后模型的输出是否有变化。
3. 回顾”原则六”中关于否定指令的分析——下次你想在 prompt 里写”不要”的时候，试着先用肯定句重新表达，看看能否达到同样的效果。

下一章，我们将学习一个强大且实用的技巧——少样本提示（Few-shot Prompting）。通过给AI几个示例，你能让它快速学会几乎任何模式化的任务。