提示词核心原则

除了结构之外，有效的提示工程还遵循一些基本原则——这些是适用于所有模型、任务和场景的基础真理。掌握这些原则，你就能应对任何提示挑战。

原则 1：清晰胜于花哨

最好的提示是清晰的，而不是花哨的。AI 模型是字面解释器——它们完全按照你给出的内容工作。

明确表达

把这个弄好一点。

通过以下方式改进这封邮件：
1. 让主题行更引人注目
2. 将段落缩短到最多 2-3 句
3. 在结尾添加明确的行动号召

避免歧义

词语可能有多重含义。选择精确的语言。

给我一个简短的摘要。
（多短？1 句话？1 段？1 页？）

用 3 个要点总结，每个要点不超过 20 个字。

说明显而易见的事情

对你来说显而易见的事情对模型来说并不明显。把假设说清楚。

你正在帮我写一封求职信。

重要背景：
- 我正在申请 Google 的软件工程师职位
- 我有 5 年 Python 和分布式系统经验
- 该职位需要领导经验（我曾带领过 4 人团队）
- 我想强调我的开源贡献

原则 2：具体性带来质量

模糊的输入产生模糊的输出。具体的输入产生具体、有用的输出。

具体性阶梯

每个级别都增加了具体性，并显著提高输出质量。

明确这些要素

原则 3：上下文为王

模型没有记忆，无法访问你的文件，也不了解你的情况。所有相关内容都必须在提示中。

提供充分的上下文

为什么我的函数不工作？

我有一个 Python 函数，应该按特定键值过滤字典列表。它返回空列表，但应该返回 3 个项目。

函数：
def filter_items(items, key, value):
    return [item for item in items if item[key] = value]

调用：filter_items(items, 'status', 'active')
预期：2 个项目，实际：空列表

上下文检查清单

原则 4：引导，而不仅仅是询问

不要只是询问答案——引导模型走向你想要的答案。

使用指导性框架

微服务的优缺点是什么？

列出微服务架构的 5 个优点和 5 个缺点。

对于每一点：
- 用一句话清楚陈述观点
- 提供简短解释（2-3 句话）
- 给出一个具体例子

考虑以下视角：小型创业公司、大型企业、以及从单体架构转型的团队。

提供推理脚手架

对于复杂任务，引导推理过程：

我需要在 PostgreSQL 和 MongoDB 之间为我的电商项目做出选择。

请系统地思考这个问题：
1. 首先，列出电商数据库的典型需求
2. 然后，根据每个需求评估每个数据库
3. 考虑针对我用例的具体权衡
4. 给出带有明确理由的建议

原则 5：迭代和优化

提示工程是一个迭代过程。你的第一个提示很少是最好的。

迭代周期

1. 编写初始提示
2. 查看输出
3. 识别差距或问题
4. 优化提示
5. 重复直到满意

常见优化

保持提示日志

记录有效的内容：

任务：代码审查
版本 1："审查这段代码" → 太笼统
版本 2：添加了具体审查标准 → 更好
版本 3：添加了好的审查示例 → 很好
最终版本：[保存成功的提示作为模板]

原则 6：利用模型的优势

顺应模型的训练方式工作，而不是逆其道而行。

模型想要提供帮助

将请求框定为有帮助的助手自然会做的事情：

我知道你不能做这个，但试着...

帮我理解...
我正在做 X，需要帮助...
你能带我了解一下...

模型擅长模式

如果你需要一致的输出，展示模式：

推荐 3 本科幻小说。按以下格式给出每个推荐：

📚 **[书名]** 作者：[作者]
*[类型] | [出版年份]*
[2 句描述]
你会喜欢它的原因：[1 句吸引人的话]

---

模型可以角色扮演

使用角色来访问不同的响应"模式"：

作为魔鬼代言人，反驳我的提案...
作为支持性的导师，帮我改进...
作为持怀疑态度的投资者，质疑这个商业计划...

原则 7：控制输出结构

结构化输出比自由形式的文本更有用。

请求特定格式

按以下格式返回你的分析：

摘要：[1 句话]

主要发现：
• [发现 1]
• [发现 2]
• [发现 3]

建议：[1-2 句话]

置信度：[低/中/高] 因为 [原因]

使用分隔符

清楚地分隔提示的各个部分：

### 背景 ###
[你的背景信息]

### 任务 ###
[你的任务]

### 格式 ###
[期望的格式]

请求机器可读输出

用于程序化使用：

只返回有效的 JSON，不要解释：
{
  "decision": "approve" | "reject" | "review",
  "confidence": 0.0-1.0,
  "reasons": ["字符串数组"]
}

原则 8：验证和确认

永远不要盲目信任模型输出，尤其是对于重要任务。

要求推理过程

解决这个问题并逐步展示你的工作过程。
解决后，通过[检查方法]验证你的答案。

请求多种视角

给我三种不同的方法来解决这个问题。
对于每种方法，解释其权衡。

内置自检

生成代码后，检查以下内容：
- 语法错误
- 边界情况
- 安全漏洞
列出发现的任何问题。

总结：原则一览

练习：填空

通过完成这个提示模板来测试你对核心原则的理解：

这些原则构成了后续所有内容的基础。在第二部分，我们将把它们应用到显著提升提示效果的具体技术中。