提示工程代码审查避坑指南：10个容易犯的低级错误
引言：为什么提示工程需要“代码审查”？
在AI时代，提示词（Prompt）是人类与大语言模型（LLM）沟通的“桥梁”。就像程序员写代码需要评审一样，提示词的设计也需要“审查”——因为一个看似微小的错误，可能导致LLM生成完全不符合预期的结果：
- 比如你让LLM“写一个Python排序函数”，它可能返回递归实现的快速排序（效率低），而你其实需要迭代版的归并排序；
- 比如你问LLM“如何解决数据库连接超时”，它可能给出MySQL的解决方案，而你用的是PostgreSQL；
- 甚至更严重的，模糊的提示可能导致LLM生成有安全隐患的代码（比如没有过滤用户输入的SQL语句）。
这些问题的根源，往往不是LLM能力不足，而是提示词的设计存在“低级错误”。本文总结了提示工程中最常见的10个低级错误，结合真实案例、反例/正例对比，帮你快速避坑。
准备工作：谁需要读这篇文章？
本文的目标读者是有一定提示工程经验的实践者：
- 开发者：用LLM生成代码、文档、测试用例的程序员；
- 数据科学家：用LLM做数据分析、报告生成的研究者；
- 产品经理/运营：用LLM写文案、做用户调研的从业者。
前置知识：
- 了解LLM基本概念（比如GPT-4、Claude 3、文心一言等）；
- 有过编写提示词的经验（哪怕是简单的提问）。
1. 错误1：任务目标不明确——模糊的提示等于没说
错误表现
提示中没有明确**“做什么”“给谁用”“要什么结果”**，导致LLM生成的内容偏离预期。
反例（模糊的提示）：
“写一篇关于AI的文章。”
问题分析：
这个提示没有回答三个关键问题：
- 目标受众：是初中生？还是AI从业者？
- 核心内容：是讲AI历史？还是AI伦理？
- 输出要求：是1000字的科普文？还是3000字的技术论文？
LLM可能会生成一篇泛泛而谈的“AI overview”，但完全不符合你的实际需求。
正例（明确的提示）：
“写一篇面向初中生的AI科普文章（800-1000字），重点介绍机器学习的基本概念（用‘推荐算法’‘语音助手’‘图像识别’3个日常生活例子），语言要通俗易懂（避免‘神经网络’‘梯度下降’等专业术语），结构分为‘什么是机器学习？’‘机器学习在生活中的应用’‘未来的AI会怎样？’三个部分。”
为什么有效？
明确的目标让LLM有了“执行框架”：它知道要写给谁、讲什么、怎么讲，生成的内容会更聚焦、更符合预期。
避坑技巧：
用“5W1H”框架定义任务目标：
- Who（目标受众）：初中生？程序员？
- What（核心任务）：写文章？生成代码？做数据分析？
- Why（目的）：科普？解决问题？提供建议？
- When（时间/场景）：日常使用？紧急故障？
- Where（应用场景）：学校？企业？个人项目？
- How（输出要求）：字数？格式？语言风格？
2. 错误2：上下文断裂——多轮对话变成“失忆症”
错误表现
在多轮对话中，前面提到的关键信息没有被后续提示引用，导致LLM“忘记”之前的约定，生成矛盾的结果。
真实案例：
我同事小A做了一个多轮提示：
第一轮：“我需要处理用户的订单数据，CSV文件有‘订单ID’‘用户ID’‘金额’‘时间’四列。”
第二轮：“帮我写一个Python脚本，计算每个用户的总消费。”
结果LLM生成的脚本没有跳过CSV的表头（比如把“用户ID”当成了数据行），导致计算错误。
问题分析：
第二轮提示没有“继承”第一轮的上下文（CSV有表头），LLM默认处理无表头的文件，导致错误。
正例（连贯的上下文）：
第一轮：“我需要处理用户的订单数据，CSV文件有‘订单ID’‘用户ID’‘金额’‘时间’四列（有表头）。”
第二轮：“基于之前的CSV结构，帮我写一个Python脚本，跳过表头，计算每个用户的总消费金额（按‘用户ID’分组求和）。”
为什么有效？
用“基于之前的XX”“如前所述”等关键词，提醒LLM保留上下文信息，避免“失忆”。
避坑技巧：
- 多轮对话中，每次提示都要引用前面的关键信息（比如文件结构、变量名、需求变更）；
- 用工具（比如LangChain的Memory模块）保存对话历史，让LLM自动关联上下文；
- 如果对话过长，定期“总结上下文”（比如“截至目前，我们讨论了XX需求，接下来需要解决XX问题”）。
3. 错误3：信息过载/缺失——提示不是“越多越好”
错误表现
- 信息过载：提示中包含无关内容，导致LLM抓不住重点；
- 信息缺失：提示中缺少关键信息，导致LLM无法生成正确结果。
反例1（信息过载）：
“写一个Python函数，实现快速排序，要求时间复杂度O(nlogn)，空间复杂度O(1)，处理重复元素，添加注释，另外我之前学过Java，所以语法要符合Python习惯，还有我喜欢用驼峰命名法。”
问题分析：
无关信息（“学过Java”“喜欢驼峰命名法”）会干扰LLM的判断，它可能会花精力处理这些无关要求，而忽略核心任务（快速排序的实现）。
反例2（信息缺失）：
“写一个Python脚本，从数据库中读取数据。”
问题分析：
缺少关键信息（数据库类型？表名？字段？连接方式？），LLM无法生成可执行的脚本。
正例（信息适中）：
“写一个Python函数，实现快速排序算法（处理包含重复元素的整数列表），要求：1. 时间复杂度O(nlogn)；2. 空间复杂度O(1)（原地排序）；3. 添加关键步骤的注释（比如分区过程）。”
为什么有效？
只保留核心要求（排序算法、复杂度、注释），去掉无关信息，让LLM聚焦于关键任务。
避坑技巧：
- 信息筛选：问自己“这个信息对完成任务有帮助吗？”，如果没有，就删掉；
- 关键信息清单：对于代码生成类提示，必须包含：
- 输入/输出格式；
- 数据结构（比如列表、字典）；
- 核心逻辑（比如排序、过滤、聚合）；
- 特殊要求（比如处理空值、重复元素）。
4. 错误4：输出格式不明确——LLM不是“读心术大师”
错误表现
没有指定输出格式，导致LLM生成的内容不符合你的使用需求（比如需要JSON却得到文本，需要代码却得到解释）。
真实案例：
我之前让LLM“列出5个常用的Python数据处理库及其用途”，结果它生成了一段文本：
“1. Pandas：用于数据清洗和分析；2. NumPy：用于数值计算；3. …”
但我需要把这些信息导入Excel，所以需要JSON格式，结果不得不手动转换，浪费了时间。
正例（明确输出格式）：
“列出5个常用的Python数据处理库及其用途，输出格式为JSON数组，每个元素包含‘library’（库名）和‘use_case’（用途）两个字段，例如：[{“library”: “Pandas”, “use_case”: “数据清洗和分析”}]。”
结果：
LLM生成了符合要求的JSON：
[{“library”: “Pandas”, “use_case”: “数据清洗、分析和可视化”}, {“library”: “NumPy”, “use_case”: “数值计算和数组操作”}, …]
为什么有效？
明确的输出格式让LLM知道“要生成什么样子的内容”，减少后续处理的成本。
避坑技巧：
- 对于结构化输出（JSON、CSV、XML），直接给出示例（比如“输出格式如下：[{‘key’: ‘value’}]”）；
- 对于代码生成，指定代码语言（比如“用Python实现”）和框架（比如“用Django的ORM”）；
- 对于文本生成，指定结构（比如“分三点说明”“用 bullet point 列出”）。
5. 错误5：忽略模型局限性——LLM不是“万能工具”
错误表现
让LLM做它不擅长的事情，导致生成错误或无用的结果。
反例1（数学计算）：
“计算123456789 × 987654321的结果。”
问题分析：
LLM的数学计算能力有限（尤其是大数运算），直接让它计算会得到错误结果（比如GPT-4可能会算错）。
反例2（实时信息）：
“2024年最新的Python库有哪些？”
问题分析：
LLM的训练数据有截止日期（比如GPT-4截止到2023年10月），无法提供实时信息。
反例3（专业领域深度问题）：
“写一篇关于量子计算的SCI论文。”
问题分析：
LLM缺乏专业领域的深度知识（比如量子计算的最新研究成果），无法生成符合SCI要求的论文。
正例（规避局限性）：
- 对于数学计算：“用Python的math库计算123456789 × 987654321的结果，并输出代码和结果。”（让LLM调用工具，而不是自己计算）；
- 对于实时信息：“根据2023年10月之前的资料，列出5个常用的Python数据处理库，并说明其特点。”（明确数据截止日期）；
- 对于专业问题：“写一篇关于量子计算的科普文章（面向非专业人士），重点介绍量子比特的基本概念，用‘硬币翻转’的例子说明叠加态。”（将专业问题转化为科普，符合LLM的能力范围）。
避坑技巧：
- 了解LLM的能力边界：它擅长生成文本、解释概念、辅助编程，但不擅长精确计算、实时信息查询、专业领域深度研究；
- 如果需要处理LLM不擅长的任务，借助工具（比如用Python的math库做计算、用搜索引擎查实时信息）；
- 将专业问题**“降维”**：比如把“写量子计算论文”转化为“写量子计算科普文章”，让LLM在能力范围内发挥作用。
6. 错误6：没有迭代优化——“一次提示”不等于“最终结果”
错误表现
认为“一次提示就能得到完美结果”，没有根据输出结果调整提示，导致错过更好的解决方案。
真实案例：
我之前写了一个提示“写一个Python脚本，爬取知乎某话题下的回答”，结果生成的脚本没有处理反爬机制（比如User-Agent、Cookie），导致爬取失败。我没有调整提示，而是自己修改了脚本，浪费了时间。后来我重新写了提示：“写一个Python脚本，爬取知乎某话题下的回答（处理反爬机制：设置User-Agent、使用Cookie），要求：1. 输入话题URL；2. 输出回答内容（作者、标题、正文）到CSV文件。” 结果生成的脚本完美解决了反爬问题。
问题分析：
第一次提示没有考虑到反爬机制，导致结果不符合预期。如果当时迭代优化提示，就能节省时间。
正例（迭代优化）：
- 第一轮提示：“写一个Python脚本，爬取知乎某话题下的回答。”（结果：没有处理反爬）；
- 第二轮提示：“修改之前的脚本，添加反爬机制（设置User-Agent为Chrome浏览器，使用Cookie）。”（结果：解决了反爬问题，但没有输出到CSV）；
- 第三轮提示：“再修改脚本，将回答内容（作者、标题、正文）输出到CSV文件。”（结果：得到完美脚本）。
为什么有效？
通过迭代优化，逐步完善提示，让LLM生成的结果越来越符合预期。
避坑技巧：
- 采用**“最小可行提示”**策略：先写一个简单的提示，得到初始结果，再根据结果调整；
- 每次调整提示时，明确修改点（比如“添加反爬机制”“输出到CSV文件”）；
- 记录每次提示的输出结果，对比不同提示的效果，找到最优解。
7. 错误7：滥用抽象术语——LLM不是“你的同事”
错误表现
在提示中使用抽象术语（比如“agent”“prompt engineering”“few-shot learning”），没有解释，导致LLM无法理解你的需求（尤其是当LLM的训练数据中没有这些术语时）。
反例：
“用agent优化我的prompt，提高LLM的生成效果。”
问题分析：
“agent”是一个抽象术语，不同的人对它的理解可能不同（比如智能代理、工具调用、对话系统），LLM无法确定你指的是哪种“agent”。
正例：
“用智能代理（agent，一种能自动执行任务的程序）优化我的prompt，具体要求：1. 分析我之前的prompt（‘写一篇关于AI的文章’）；2. 指出其中的问题（比如目标不明确）；3. 生成优化后的prompt。”
为什么有效？
解释了“agent”的含义，让LLM明白你的需求。
避坑技巧：
- 对于专业术语，一定要解释清楚（比如“few-shot learning”是指用少量示例训练模型）；
- 用通俗语言代替抽象术语（比如用“智能代理”代替“agent”，用“提示优化”代替“prompt engineering”）；
- 如果不确定LLM是否理解某个术语，测试一下（比如问“你知道‘agent’是什么意思吗？”）。
8. 错误8：忽略输出长度——“长篇大论”不等于“高质量”
错误表现
没有指定输出长度，导致LLM生成的内容过长（比如写1000字的文章，结果写了2000字）或过短（比如写1000字的文章，结果写了500字）。
反例：
“写一篇关于AI的文章。”
结果：
LLM生成了一篇2000字的文章，包含很多无关内容（比如AI的历史、未来趋势），不符合你的需求。
正例：
“写一篇1000字左右的关于AI的文章，结构分为‘引言’‘AI的应用领域’‘AI的挑战’‘结论’四个部分，每个部分250字左右，语言要通俗易懂，避免专业术语。”
为什么有效？
指定了输出长度和结构，让LLM生成的内容更紧凑、更符合预期。
避坑技巧：
- 对于文本生成类提示，指定字数范围（比如“1000字左右”）和结构（比如“分四个部分”）；
- 对于代码生成类提示，指定代码长度（比如“不超过50行”）和复杂度（比如“用简单的逻辑实现”）；
- 如果LLM生成的内容过长，要求精简（比如“把这篇文章精简到1000字，保留核心内容”）；
- 如果LLM生成的内容过短，要求扩展（比如“把这篇文章扩展到1000字，添加‘AI在医疗领域的应用’的例子”）。
9. 错误9：没有验证准确性——“LLM说的”不等于“正确的”
错误表现
相信LLM生成的所有内容，没有验证其准确性，导致传播错误信息（比如生成的代码有bug、文档有错误）。
真实案例：
我之前看到一篇文章，作者用LLM生成了一段“Python实现的冒泡排序”代码，结果代码中有一个bug（循环条件错误），作者没有验证，就把代码发布了，导致很多读者留言指出错误。
反例：
LLM生成的冒泡排序代码：
def bubble_sort(arr):
n = len(arr)
for i in range(n):
for j in range(n - i): # 错误：循环条件应该是n - i - 1
if arr[j] > arr[j + 1]:
arr[j], arr[j + 1] = arr[j + 1], arr[j]
return arr
问题分析：
循环条件错误（j的范围应该是n - i - 1），导致最后一个元素会被比较两次，影响效率。
正例（验证准确性）：
- 第一步：运行LLM生成的代码，测试输入（比如[3,2,1]），结果输出[1,2,3]，看似正确；
- 第二步：检查循环条件，发现j的范围是n - i，导致j+1可能超过数组长度（比如当j = n - i时，j+1 = n - i + 1，而数组的长度是n，所以当i=0时，j的范围是0到n-1，j+1是n，超过数组长度）；
- 第三步：修改循环条件为n - i - 1，重新运行代码，测试输入[3,2,1]，结果输出[1,2,3]，正确。
避坑技巧：
- 对于代码生成类提示，一定要运行代码（测试输入、输出）；
- 对于文本生成类提示，一定要检查事实错误（比如日期、数据、引用）；
- 对于专业内容，一定要请教专家（比如让程序员检查代码、让医生检查医疗建议）。
10. 错误10：忘记“用户视角”——提示不是“写给自己看的”
错误表现
从“自己的视角”写提示，没有考虑LLM的“理解视角”，导致LLM无法正确解读你的需求。
反例：
“写一个脚本，处理那个数据。”
问题分析：
“那个数据”是你自己知道的，但LLM不知道（它没有上下文），所以无法生成正确的脚本。
正例：
“写一个Python脚本，处理我昨天发给你的CSV文件（文件路径：/data/orders.csv，列名为‘用户ID’‘消费金额’），计算每个用户的总消费金额。”
为什么有效？
从LLM的视角出发，提供了它需要的所有信息（文件路径、列名），让它能正确解读你的需求。
避坑技巧：
- 把自己当成**“LLM的用户”**：问自己“如果我是LLM，看到这个提示，能明白要做什么吗？”；
- 用具体的、可量化的信息代替模糊的表述（比如用“/data/orders.csv”代替“那个数据”，用“‘用户ID’‘消费金额’”代替“那些列”）；
- 避免使用代词（比如“它”“那个”），除非前面已经明确指代。
总结：提示工程的“避坑口诀”
- 目标明确：用“5W1H”定义任务，模糊的提示等于没说；
- 上下文连贯：多轮对话要引用前面的信息，避免“失忆”；
- 信息适中：去掉无关信息，保留核心要求；
- 格式明确：指定输出格式，LLM不是“读心术大师”；
- 规避局限：了解LLM的能力边界，借助工具处理不擅长的任务；
- 迭代优化：一次提示不等于最终结果，根据输出调整提示；
- 术语解释：对于专业术语，一定要解释清楚；
- 长度控制：指定输出长度，避免长篇大论或过短；
- 验证准确：运行代码、检查事实，避免错误；
- 用户视角：从LLM的角度出发，提供具体信息。
最后的话：提示工程是“对话艺术”
提示工程不是“写代码”，而是“与LLM对话”——你需要用LLM能理解的语言，清晰地表达你的需求。就像和人对话一样，你说得越清楚，对方的回应就越符合你的预期。
希望这篇文章能帮你避开提示工程中的低级错误，让LLM成为你工作中的“得力助手”。如果你有其他避坑技巧，欢迎在评论区分享！
延伸阅读：
- 《Prompt Engineering Guide》（官方指南，涵盖所有提示工程技巧）；
- 《LangChain Documentation》（用LangChain管理上下文和工具调用）；
- 《OpenAI Cookbook》（OpenAI官方提供的提示示例和最佳实践）。
