我的 Prompt 踩坑日记：100 条错误用法与正确姿势
作者：实战 LLM 开发工程师 | 踩坑时长：18 个月 | 项目：10+ 个 AI 落地项目
本文收录真实踩坑案例，附优化前后效果对比，全文约 8000 字，建议收藏慢慢看。
前言
做 AI 应用落地这一年多，我踩过的 Prompt 坑，比很多人写过的 Prompt 还多。
每次翻看早期项目的代码，看到那些"精心设计"的 Prompt，我都想给当时的自己一巴掌。不是因为用错了------而是用的太"想当然"了。
这篇文章是我的踩坑日记，按问题类型分类，收录了 100 个真实场景的错误 vs 正确对比。不废话，直接上案例。
一、指令表达：说不清楚是万坑之源
❌ 坑 01：用模糊词代替具体要求
❌ 写一篇好文章介绍 Python
✅ 写一篇 800 字的 Python 入门文章，面向没有编程基础的大学生，
包含：1) 什么是 Python，2) 第一个 Hello World 程序，3) 三个适合初学者的学习资源链接踩坑现象：模型写了篇 200 字的"文章介绍"，没有代码，没有例子。
❌ 坑 02：指令和内容混在一起
❌ 把以下文本翻译成英文，注意保持专业语气，文本是：人工智能正在改变世界
✅ 请将以下文本翻译成英文，保持专业语气：
<text>
人工智能正在改变世界
</text>踩坑现象：模型把"注意保持专业语气"也翻译进去了。
❌ 坑 03：双重否定让模型懵逼
❌ 不要不使用正式语气
✅ 使用正式语气踩坑现象：模型对双重否定理解不一致，有时候使用正式语气，有时候又不使用。
❌ 坑 04：没有说"不要做什么"
❌ 帮我总结这篇文章
✅ 帮我总结这篇文章。要求：
- 不要超过 200 字
- 不要引用原文原句
- 不要包含作者的主观判断踩坑现象：总结比原文还长，还复制粘贴了大段原文。
❌ 坑 05：用"尽量"代替硬性限制
❌ 尽量简短地回答
✅ 用一句话回答，不超过 30 个字踩坑现象：模型把"尽量简短"解读为"我已经很简短了"，依然输出长段落。
❌ 坑 06：要求太多，模型顾此失彼
❌ 写一篇文章，要有吸引力、有深度、有趣味、简单易懂、有数据支撑、有个人观点、
不要太长、要专业、口语化、同时要......
✅ 写一篇 600 字的科技新闻报道，目标读者：IT 从业者，
核心要求：准确（引用至少 2 个真实数据）+ 简洁（每段不超过 3 句）踩坑现象：指令超过 5 个，模型开始随机忽略部分要求。
❌ 坑 07：没说输出格式
❌ 列出 5 个 Python 学习资源
✅ 列出 5 个 Python 学习资源，用 Markdown 表格格式，包含列：名称、类型（书籍/视频/网站）、适合人群、链接踩坑现象：输出了一段流水账文字，没法直接用。
❌ 坑 08：用"帮我看看"代替具体任务
❌ 帮我看看这段代码
✅ 检查这段 Python 代码的以下问题：
1. 语法错误
2. 潜在的运行时异常
3. 可能的内存泄漏
如有问题，指出代码行号并给出修复建议❌ 坑 09：忘记说"如果找不到/不确定怎么办"
❌ 从以下文本中提取电话号码
✅ 从以下文本中提取所有电话号码，以 JSON 数组格式输出。
如果没有找到电话号码，输出：{"phones": []}
不要猜测或伪造数据踩坑现象：文本里没有电话号码，模型编造了一个。
❌ 坑 10：把约束条件放在末尾
❌ 写一首诗，主题是秋天，要押韵，四行，每行不超过10个字
✅ 写一首诗：
- 格式：四行，每行不超过10个字
- 押韵：偶数行押韵（2、4行）
- 主题：秋天踩坑现象：模型读到约束时已经"想好"了结构，修改成本高。把约束放前面效果更好。
二、角色设定：别只写"你是一个专家"
❌ 坑 11：角色设定太空洞
❌ 你是一个专家，帮我回答问题
✅ 你是一位有 10 年经验的 Python 后端工程师，专注于高并发系统设计。
你的回答风格：直接、简洁、给出具体代码示例，不废话。❌ 坑 12：角色和任务不匹配
❌ 你是一位诗人，帮我写一份商业计划书
✅ 你是一位创业公司的联合创始人，有过 2 次成功融资经验，
帮我撰写一份 Pre-A 轮融资的商业计划书执行摘要❌ 坑 13：角色设定里有矛盾指令
❌ 你是一位严格的老师，要用温柔友善的方式批评学生的作业
✅ 你是一位导师，回顾学生作业时：
- 先肯定3个优点
- 再指出最重要的2个改进点（直接、具体）
- 语气：鼓励型，不说"你错了"，改用"如果这样会更好"❌ 坑 14：没有设定受众
❌ 解释一下什么是 Transformer 架构
✅ 向一位有 3 年 Web 开发经验但没有 AI 背景的工程师解释 Transformer 架构，
类比：可以用"注意力机制像 Google 搜索排序"这类比喻❌ 坑 15：忘记设定语言/地区风格
❌ 写一个产品描述
✅ 为中国市场写一个产品描述（简体中文，符合国内用户习惯，
强调性价比和实用性，避免直接翻译英文营销话术）三、上下文管理：你以为模型记得，其实它不记得
❌ 坑 16：在长对话中假设模型记得早期内容
踩坑现象：第1轮说"我们的产品是 XX"，第20轮问"这个功能适合我们的产品吗？"------模型已经不记得了。
正确做法：在关键问题前，重新注入关键上下文：
[背景重申：我们的产品是面向中小企业的 SaaS HR 系统，主要功能是考勤+薪酬管理，
用户是 HR 专员，技术背景较弱]
请问以下这个新功能适合我们的产品吗？......❌ 坑 17：把所有历史记录都塞进 context
踩坑现象：Token 超限，或者噪声太多导致模型回答跑偏。
正确做法：总结压缩历史，只保留关键决策和约束：
python
# 不好的做法
messages = full_history # 可能有 50 条消息
# 好的做法
messages = [
{"role": "system", "content": "项目背景摘要 + 当前任务约束"},
*recent_messages[-5:] # 只保留最近 5 条
]❌ 坑 18：没有利用好 System Prompt
❌ 每次用户消息都把角色设定放在 user 消息里
✅ System Prompt 设定：角色、格式、输出约束、不变的规则
User 消息：只包含变化的内容（具体问题、当前数据）❌ 坑 19：在多轮对话中改变任务目标
踩坑现象：第一轮说"帮我写一份技术文档"，第三轮突然说"不对，改成营销文案"------模型会混乱。
正确做法：明确重置任务：
[任务重置：忽略之前的写作内容，重新开始]
新任务：为上述产品功能写一份营销文案，目标读者是非技术决策者......❌ 坑 20：忘记告诉模型"你现在知道什么"
❌ 基于我们之前讨论的，继续写
✅ 基于以下已确定的内容，继续写第三章：
[粘贴前两章的核心结论和已确定的内容]四、输出控制：你以为清楚，模型理解不同
❌ 坑 21：要求 JSON 但没有给 Schema
❌ 以 JSON 格式输出用户信息
✅ 以 JSON 格式输出，严格遵循以下 Schema：
{
"name": "string",
"age": "number",
"email": "string | null"
}
不要添加任何额外字段，不要输出 JSON 以外的文字❌ 坑 22：没有处理模型"前言后语"的问题
踩坑现象：要求输出 JSON，模型输出：
当然！这是您要求的 JSON 格式数据：
```json
{...}希望这对您有帮助！
**正确做法**：只输出 JSON，不要任何解释文字，不要 Markdown 代码块标记
---
### ❌ 坑 23：要求"举例说明"但没限制数量❌ 举一些例子
✅ 举 3 个具体例子，每个例子包含：
-
场景描述（1句话）
-
代码示例（5行以内）
-
预期输出
❌ 坑 24：表格要求没有指定对齐和精度
❌ 用表格比较各模型的性能
✅ 用 Markdown 表格比较，列：模型名称 | 参数量 | MMLU得分(%) | 推理速度(token/s) | 显存需求(GB)
数值保留1位小数，如不知道填"N/A"
---
### ❌ 坑 25：要求"详细"但没说详细到什么程度❌ 详细解释这个算法
✅ 解释这个算法，包含：
-
核心思路（2-3句话）
-
时间复杂度分析
-
空间复杂度分析
-
Python 伪代码实现
-
一个具体的数值示例（输入→步骤→输出）
五、代码生成：这块坑最深
❌ 坑 26：没说编程语言和版本
❌ 写一个读取文件的函数
✅ 用 Python 3.11 写一个异步读取大文件的函数，使用 aiofiles 库，
处理文件不存在的异常，返回 str 类型
---
### ❌ 坑 27：没说已有代码的上下文❌ 帮我加一个登录功能
✅ 我的 FastAPI 项目使用 SQLAlchemy ORM + PostgreSQL + JWT 认证。
请在以下路由文件中添加 /login 接口：
粘贴现有代码
要求：使用项目现有的 db session 和 User 模型，密码用 bcrypt 验证
---
### ❌ 坑 28：要求"最优"代码但没说优化目标❌ 优化这段代码
✅ 优化这段代码，目标：降低内存占用（当前处理 100w 条数据时 OOM），
允许牺牲部分可读性，不需要并发加速
---
### ❌ 坑 29：生成代码后没要求写测试
**踩坑现象**：直接用模型生成的代码，上线后出 bug。
**正确做法**：生成代码后，同时生成：
-
单元测试（使用 pytest，覆盖正常/边界/异常三种情况）
-
使用示例（可直接运行）
❌ 坑 30：让模型"修改一下"但没指定修改范围
❌ 这段代码有点问题，帮我修改一下
✅ 这段代码在输入为空列表时会报 IndexError，
请只修改第 15-20 行的边界检查逻辑，不要改其他部分
---
## 六、Chain of Thought：让模型"想清楚再说"
### ❌ 坑 31：复杂问题不用 CoT❌ 这个业务场景应该用微服务还是单体架构？
✅ 这个业务场景应该用微服务还是单体架构？
请先分析以下维度，然后再给出建议：
-
团队规模（当前和预期）
-
业务复杂度和拆分自然边界
-
运维能力
-
性能瓶颈位置
最后：综合以上，给出带理由的推荐
❌ 坑 32：让模型"先想后说"但没给它空间
踩坑现象：要求 CoT，但输出格式限制太死（如 50 字内），模型没法展开思考。
正确做法：复杂推理题，给模型充足的思考空间，不限字数限制推理过程。
❌ 坑 33：数学/逻辑题不强制分步
❌ 小明有 3 个苹果，给了小红 2 个，又买了 5 个，还剩多少？（直接告诉我答案）
✅ 请一步一步计算：
步骤1：初始苹果数
步骤2：给出后剩余
步骤3：购买后总计
最终答案：X 个
**实测发现**：不加步骤的情况下，GPT-3.5 级模型有约 20% 概率算错简单数学。
---
### ❌ 坑 34：让模型同时做推理和格式化❌ 分析这 10 个选项的优劣，输出成 JSON
✅ 分两步：
Step 1：用自然语言分析 10 个选项的优劣（不限格式）
Step 2：基于以上分析，整理成 JSON 格式
---
### ❌ 坑 35：忽略"让模型自我检查"在最后加一行：
最后，检查你的答案是否符合以下标准：
\] 字数是否在要求范围内 \[ \] 是否包含所有必要字段 \[ \] 是否有明显的事实错误 如有不符，请修正后再输出。 --- ## 七、Few-Shot：示例的质量决定输出的质量 ### ❌ 坑 36：示例太少或没有示例 **场景**：让模型按特定格式分类用户反馈 ❌ 将以下反馈分类为：功能需求/bug报告/使用咨询 ✅ 将以下反馈分类，示例： 输入："登录按钮点击没反应" → 分类：bug报告 输入："能不能支持微信登录" → 分类：功能需求 输入："怎么修改密码" → 分类：使用咨询 现在分类："{用户反馈}" --- ### ❌ 坑 37：示例质量差（有歧义或错误） **踩坑现象**：给了 3 个示例，有一个是错的，模型学了坏样本。 **正确做法**：宁少勿滥，确保每个示例都是高质量的典型案例。 --- ### ❌ 坑 38：示例分布不均匀 **踩坑现象**：3 个正面示例，0 个负面示例，模型倾向于总是输出正面结果。 **正确做法**：确保各类别示例数量均衡。 --- ### ❌ 坑 39：示例格式和要求格式不一致 **踩坑现象**：要求输出 JSON，但示例用的是文字格式------模型会跟着示例走，忽略格式要求。 --- ### ❌ 坑 40：示例过于简单，没有覆盖边界情况 **正确做法**：至少包含一个边界案例（如：空输入、极端值、多义词等）的处理示例。 --- ## 八、RAG 场景：检索增强的特殊坑 ### ❌ 坑 41：没有明确让模型区分"知识库内容"和"模型自身知识" ❌ 基于以下文档回答问题 ✅ 严格基于以下文档内容回答，不要使用你的预训练知识补充。 如果文档中没有答案，回答"根据提供的文档，无法找到相关信息"。 文档内容：\[...
---
### ❌ 坑 42：检索结果直接塞给模型，没有说明来源❌ [检索结果1][检索结果2][检索结果3] + 问题
✅ 以下是从知识库检索到的相关片段：
文档A，第3章\]：{内容}
\[文档B，2024-01-15更新\]：{内容}
请基于以上内容回答：{问题}
引用时注明来源（如：根据文档A...）
---
### ❌ 坑 43：没有处理检索结果冲突
✅ 如果多个文档内容有冲突，指出冲突所在，并说明你优先采用哪个来源及理由。
---
### ❌ 坑 44：Prompt 模板里的占位符格式和检索内容格式冲突
**踩坑现象**：用 `{context}` 作占位符，检索内容里也包含 `{...}` → Python format 字符串报错。
**正确做法**：用不易冲突的占位符，如 `<<