【AI】提示词技巧：让大模型“检查”自身输出错误的提示方法

提示词技巧：让大模型 “检查” 自身输出错误的提示方法

**

1. 前言

在使用大模型（如 ChatGPT、豆包、文心一言等）生成内容时，我们经常会遇到输出错误的情况。这些错误可能导致生成的内容无法使用，比如写代码时出现语法错误、写文案时出现逻辑矛盾、整理数据时出现格式混乱等。

如果每次都靠人工检查大模型的输出，不仅会花费大量时间，还可能因为疏忽漏掉一些隐藏的错误。而通过合适的提示词，让大模型自己检查自身输出的错误，能有效提高工作效率，减少人工成本。下面，就详细讲解让大模型 “检查” 自身输出错误的提示方法，包括错误类型分析、提示词设计原则、具体提示方法、实战案例等内容。

2. 大模型常见的输出错误类型

在设计提示词让大模型检查错误前，我们需要先了解大模型常见的输出错误类型。只有明确了错误类型，才能在提示词中针对性地提出检查要求，让大模型更精准地发现问题。

2.1 内容逻辑类错误

这类错误主要是指大模型生成的内容在逻辑上存在矛盾、漏洞或不符合常识的情况。

1. 逻辑矛盾：比如在介绍 “如何节约用水” 时，既说 “每次洗手后要及时关闭水龙头”，又说 “洗手时要让水龙头一直流水以保持清洁”，两个观点相互冲突。

1. 逻辑漏洞：比如在写 “用户注册流程” 时，只提到 “用户输入手机号和密码”，却漏掉了 “手机号验证”“密码确认” 等关键步骤，导致流程不完整。

1. 不符合常识：比如在回答 “地球围绕什么天体转” 时，错误地回答 “地球围绕月球转”，违背了基本的科学常识。

2.2 格式规范类错误

这类错误主要是指大模型生成的内容在格式上不符合预设要求，比如排版混乱、符号错误、格式不统一等。

1. 排版混乱：比如在生成 Markdown 格式的文档时，标题没有使用正确的 #符号（如用 “##” 表示一级标题，用 “###” 表示二级标题），列表没有使用正确的序号或符号（如混用 “1.” 和 “-” 表示列表项）。

1. 符号错误：比如在写代码时，括号不匹配（如左括号 “{” 多一个，右括号 “}” 少一个）、引号使用错误（如混用英文引号 “""” 和中文引号 ““””）、逗号和分号混淆（如在 Python 代码中用分号 “;” 结尾，却在不需要的地方多加分号）。

1. 格式不统一：比如在整理表格数据时，有的行用逗号分隔字段，有的行用空格分隔字段；有的日期格式是 “2025-09-24”，有的是 “2025.09.24”，格式混乱不统一。

2.3 信息准确类错误

这类错误主要是指大模型生成的内容中包含错误的信息，比如数据错误、概念错误、事实错误等。

1. 数据错误：比如在回答 “中国人口数量” 时，错误地给出 “10 亿”（实际最新数据接近 14 亿）；在计算 “2024 年全年天数” 时，错误地回答 “366 天”（2024 年是闰年，实际为 366 天，若错误回答 “365 天” 则属于数据错误）。

1. 概念错误：比如在解释 “HTTP 协议” 时，错误地将其定义为 “一种用于传输文件的协议”（实际 HTTP 协议是用于客户端和服务器之间通信的应用层协议，不仅限于传输文件）。

1. 事实错误：比如在介绍 “李白的代表作” 时，错误地列出 “《蜀道难》《春江花月夜》”（《春江花月夜》的作者是张若虚，并非李白）。

2.4 语言表达类错误

这类错误主要是指大模型生成的内容在语言表达上存在问题，比如语法错误、用词不当、语句不通顺等。

1. 语法错误：比如在写中文句子时，出现 “我昨天吃了一个苹果，很好吃，然后。” 这样的病句（结尾多了逗号，句子不完整）；在写英文句子时，出现 “He go to school every day”（动词 “go” 没有根据主语 “He” 变为第三人称单数 “goes”）。

1. 用词不当：比如在描述 “天气很冷” 时，错误地使用 “热烈” 一词，写成 “今天天气热烈，出门要穿厚衣服”；在介绍 “电脑配件” 时，将 “显卡” 错误地称为 “显示卡”（虽然部分场景可通用，但在专业文档中需使用标准术语 “显卡”）。

1. 语句不通顺：比如在写 “如何学习编程” 时，写出 “编程学习要多练习，因为练习能提高，所以每天都要做一些题目”，句子成分残缺，读起来不通顺。

3. 让大模型检查自身输出错误的提示词设计原则

要让大模型有效检查自身输出的错误，提示词的设计非常关键。设计提示词时需遵循以下原则，确保提示词清晰、明确、有针对性。

3.1 明确检查目标

在提示词中，要清晰地告诉大模型需要检查的具体目标，即让它检查哪类错误（如逻辑类错误、格式类错误、信息准确类错误等）。不能只笼统地说 “检查你的输出是否有错误”，这样大模型不知道该从哪些方面入手，检查效果会很差。

比如，正确的提示方式是：“请检查你刚才生成的‘用户注册流程’内容，重点检查是否存在逻辑漏洞（如漏掉关键步骤）和逻辑矛盾（如步骤之间相互冲突）的问题。”

3.2 给出检查标准

除了明确检查目标，还要给大模型提供具体的检查标准，让它知道 “什么样的情况属于错误”。检查标准越详细，大模型检查的准确性就越高。

比如，在让大模型检查 Markdown 格式错误时，可以给出这样的检查标准：“1. 一级标题必须使用‘# ’（# 后加空格）开头，二级标题必须使用‘## ’开头，不能混用；2. 无序列表必须使用‘- ’（- 后加空格）开头，有序列表必须使用‘1. ’（1. 后加空格）开头，不能混用；3. 表格必须使用 Markdown 标准语法（如用‘|’分隔列，用‘-’分隔表头和内容行），不能出现表格线缺失的情况。”

3.3 规定输出形式

在提示词中，要规定大模型检查完成后的输出形式，比如让它先列出发现的错误，再给出修改建议。这样能让大模型的检查结果更清晰，方便我们后续查看和处理。

比如，可以这样规定输出形式：“请按照以下格式输出检查结果：1. 错误类型：[说明错误属于哪类（如逻辑漏洞、格式错误等）]；2. 错误位置：[说明错误在原文中的具体位置，如‘第 3 段第 2 句’‘表格第 2 行第 3 列’]；3. 错误描述：[详细说明错误内容]；4. 修改建议：[给出具体的修改方案]。如果没有发现错误，请回复‘未发现错误’。”

3.4 结合上下文信息

在提示词中，要包含大模型之前生成的内容（或内容的关键片段），让大模型能结合上下文进行检查。如果只让大模型 “检查错误”，却不提供它之前生成的内容，大模型会因为没有上下文参考而无法进行有效检查。

比如，可以这样在提示词中包含上下文：“你刚才生成的‘Python 读取 Excel 文件的代码’如下：[此处粘贴大模型之前生成的代码]。请检查这段代码是否存在格式规范类错误（如括号不匹配、引号错误）和信息准确类错误（如函数名错误、参数错误），并按照规定格式输出检查结果。”

4. 针对不同错误类型的具体提示方法

根据前面提到的 4 类常见错误，下面分别给出针对性的提示方法，包括提示词模板和使用说明，方便大家直接参考使用。

4.1 针对内容逻辑类错误的提示方法

4.1.1 提示词模板

“请检查你之前生成的关于【主题名称，如‘如何煮米饭’】的内容，重点检查是否存在以下内容逻辑类错误：

1. 逻辑矛盾：内容中是否有相互冲突的观点或描述；

1. 逻辑漏洞：内容是否存在关键步骤、条件或信息缺失，导致流程不完整或逻辑不连贯；

1. 不符合常识：内容是否存在违背科学常识、生活常识或行业常识的描述。

检查标准：

1. 逻辑矛盾：若两个观点同时成立会导致结果冲突，则判定为逻辑矛盾；

1. 逻辑漏洞：若缺少某个步骤或信息会导致用户无法按照内容完成操作或理解核心观点，则判定为逻辑漏洞；

1. 不符合常识：若描述与公认的科学原理、生活经验或行业规则不符，则判定为不符合常识。

请按照以下格式输出检查结果：

1. 错误类型：[逻辑矛盾 / 逻辑漏洞 / 不符合常识]

1. 错误位置：[如‘第 2 段第 3 句’‘第 4 点步骤描述’]

1. 错误描述：[详细说明错误内容，如‘第 2 段第 3 句说 “煮米饭时水要没过米 2 厘米”，第 4 段第 1 句说 “煮米饭时水要刚好没过米”，两个描述相互矛盾’]

1. 修改建议：[如‘统一描述为 “煮米饭时水要没过米 1-2 厘米”，确保逻辑一致’]

如果没有发现上述错误，请回复‘未发现内容逻辑类错误’。”

4.1.2 使用说明

1. 替换【主题名称】：将模板中的 “【主题名称，如‘如何煮米饭’】” 替换为大模型之前生成内容的实际主题，比如 “用户登录接口测试用例”“Python 数据分析步骤” 等。

1. 补充上下文（可选）：如果大模型可能忘记之前生成的内容，可以在提示词中补充关键片段，比如 “你之前生成的内容关键片段如下：[粘贴关键片段]”，帮助大模型回忆上下文。

1. 调整检查标准（可选）：如果是特定行业的内容（如医疗、金融），可以根据行业常识调整 “不符合常识” 的检查标准，比如在医疗领域，可补充 “是否符合医学诊疗规范” 作为检查标准。

4.2 针对格式规范类错误的提示方法

4.2.1 提示词模板

“请检查你之前生成的【内容类型，如‘Markdown 格式的接口文档’‘Python 代码’‘CSV 格式的数据表’】，重点检查是否存在以下格式规范类错误：

1. 排版错误：是否存在标题层级错误、列表格式错误、段落缩进错误等；

1. 符号错误：是否存在括号不匹配、引号错误（中英文混用）、分隔符错误（如逗号和分号混淆）等；

1. 格式不统一：是否存在字段分隔符不统一、日期格式不统一、单位格式不统一（如有的用‘kg’，有的用‘千克’）等。

检查标准（根据内容类型补充）：

1. 若内容类型是 Markdown 文档：一级标题用‘# ’开头，二级标题用‘## ’开头，三级标题用‘### ’开头；无序列表用‘- ’开头，有序列表用‘1. ’开头；表格用‘|’分隔列，用‘-’分隔表头和内容行，且表头与内容列数一致。

1. 若内容类型是代码（以 Python 为例）：括号（()、{}、[]）必须成对出现；字符串用英文引号（'' 或 ""），不能用中文引号；语句结尾一般不加分号（特殊情况除外）；缩进用 4 个空格，不能用 Tab 键。

1. 若内容类型是数据表（以 CSV 为例）：所有行的字段数量一致；字段分隔符统一用逗号‘,’；日期格式统一为‘YYYY-MM-DD’；数值类型字段不包含非数值字符（如字母、符号）。

请按照以下格式输出检查结果：

1. 错误类型：[排版错误 / 符号错误 / 格式不统一]

1. 错误位置：[如‘Markdown 文档的第 5 行标题’‘Python 代码的第 12 行括号’‘CSV 数据表的第 8 行日期字段’]

1. 错误描述：[详细说明错误内容，如‘Python 代码第 12 行的左括号 “{” 没有对应的右括号 “}”，括号不匹配’]

1. 修改建议：[如‘在 Python 代码第 12 行的语句末尾添加右括号 “}”，确保括号成对’]

如果没有发现上述错误，请回复‘未发现格式规范类错误’。”

4.2.2 使用说明

1. 选择对应内容类型的检查标准：模板中针对 Markdown 文档、Python 代码、CSV 数据表提供了不同的检查标准，使用时需根据实际内容类型选择对应的标准，删除不相关的标准（如检查 Python 代码时，删除 Markdown 文档和 CSV 数据表的检查标准）。

1. 补充自定义格式要求（可选）：如果有项目自定义的格式要求（如公司规定代码缩进用 2 个空格，而非 4 个），可以在检查标准中补充，比如 “代码缩进统一用 2 个空格，不能用 4 个空格或 Tab 键”。

1. 提供格式示例（可选）：如果大模型对格式要求不熟悉，可以在提示词中添加正确的格式示例，比如 “正确的 Python 代码括号使用示例：def add (a, b): return a + b（括号成对出现，且缩进正确）”，帮助大模型理解检查标准。

4.3 针对信息准确类错误的提示方法

4.3.1 提示词模板

“请检查你之前生成的关于【主题名称，如‘2024 年中国 GDP 数据’‘JavaScript 核心概念’‘李白生平’】的内容，重点检查是否存在以下信息准确类错误：

1. 数据错误：是否存在数据数值错误、单位错误、计算错误等；

1. 概念错误：是否存在对专业概念的定义错误、解释错误、混淆概念等；

1. 事实错误：是否存在对历史事件、人物信息、客观事实的描述错误等。

检查标准：

1. 数据错误：若数据与权威来源（如政府官网、行业报告、权威书籍）不符，则判定为数据错误；若单位使用错误（如将‘米’写成‘千米’）或计算结果错误（如‘2+3=6’），也判定为数据错误。

1. 概念错误：若对概念的定义与专业教材、行业标准、权威文档不符，则判定为概念错误；若将两个不同概念混淆（如将‘HTTP’和‘HTTPS’的概念混为一谈），也判定为概念错误。

1. 事实错误：若对历史事件的时间、地点、人物，或对客观事实（如天体运行、地理名称）的描述与公认事实不符，则判定为事实错误。

请按照以下格式输出检查结果：

1. 错误类型：[数据错误 / 概念错误 / 事实错误]

1. 错误位置：[如‘第 3 段第 1 句数据描述’‘第 2 点概念解释’‘第 5 行人物生平描述’]

1. 错误描述：[详细说明错误内容，如‘第 3 段第 1 句说 “2024 年中国 GDP 为 100 万亿元”，但根据国家统计局发布的权威数据，2024 年中国 GDP 约为 126 万亿元，数据数值错误’]

1. 修改建议：[如‘将数据修改为 “2024 年中国 GDP 约为 126 万亿元”，并注明数据来源为国家统计局’]

如果没有发现上述错误，请回复‘未发现信息准确类错误’。”

4.3.2 使用说明

1. 明确权威来源（可选）：如果知道具体的权威来源，可以在提示词中补充，比如 “数据需以国家统计局官网（http://www.stats.gov.cn/）发布的 2024 年数据为准”“概念解释需以《JavaScript 高级程序设计》（第 4 版）中的定义为准”，让大模型有更明确的检查依据。

1. 补充关键信息（可选）：如果大模型生成的内容中包含大量数据或概念，可以在提示词中列出需要重点检查的关键数据或概念，比如 “重点检查以下数据：2024 年中国人口数量、2024 年全球 GDP 总量；重点检查以下概念：‘异步编程’‘Promise 对象’”，提高检查效率。

1. 区分时效性信息（可选）：对于时效性较强的信息（如最新政策、实时数据），可以在提示词中强调 “需检查信息是否为最新，是否符合当前时间（2025 年）的实际情况”，避免大模型使用过时信息。

4.4 针对语言表达类错误的提示方法

4.4.1 提示词模板

“请检查你之前生成的【内容类型，如‘中文技术文档’‘英文邮件’‘中文宣传文案’】，重点检查是否存在以下语言表达类错误：

1. 语法错误：是否存在句子成分残缺、搭配不当、语序错误等（中文）；是否存在动词时态错误、主谓不一致、冠词使用错误等（英文）；
2. 用词不当：是否存在近义词混淆（如 “必须” 和 “必需”）、术语使用错误（如将 “接口” 错写为 “端口”）、词性错误（如将名词 “决定” 错用为动词 “决定”，但语境不符，如 “我决定了一个计划” 应为 “我制定了一个计划”）；
3. 语句不通顺：是否存在句子冗长导致逻辑混乱、分句之间缺乏合理连接（如不用 “因为... 所以...”“虽然... 但是...” 等关联词）、读起来生硬不自然等情况。

4. 检查标准：

5. 语法错误（中文）：句子需包含完整的主语和谓语，不存在成分残缺（如 “在公园散步，很开心” 缺少主语，应改为 “我在公园散步，很开心”）；词语搭配需符合中文表达习惯（如 “提高水平” 不能写成 “提升水平” 虽可通用，但 “提高” 更常用，若特定场景要求 “提升” 则需统一，此处以通用搭配为准，如 “改善生活” 不能写成 “改进生活”）；语序需符合中文表达逻辑（如 “我昨天买了一本书” 不能写成 “昨天我买了一本书” 虽语序可调整，但常规表达以 “主语 + 时间状语 + 谓语 + 宾语” 为主，特殊强调除外）。
6. 语法错误（英文）：动词时态需与语境一致（如描述过去发生的事用一般过去时，“He went to school yesterday” 不能写成 “He go to school yesterday”）；主谓需保持一致（如主语为单数第三人称，谓语动词需加 “s” 或 “es”，“She likes reading” 不能写成 “She like reading”）；冠词使用需符合规则（如可数名词单数前需加 “a”“an” 或 “the”，“I have a book” 不能写成 “I have book”）。
7. 用词不当：需使用符合语境的近义词（如 “必须” 表示事理上和情理上必要，“必需” 表示一定要有、不可缺少，“我们必须努力学习” 不能写成 “我们必需努力学习”）；专业术语需使用行业标准表述（如在编程领域，“API 接口” 不能写成 “API 端口”）；词性使用需正确（如 “美丽” 是形容词，可修饰名词 “花朵”，“美丽的花朵” 不能写成 “美丽地花朵”，“地” 用于副词修饰动词）。
8. 语句不通顺：句子长度需适中，避免超过 20 字后仍无标点分隔（如 “我今天早上起床后先刷牙洗脸然后吃早餐接着去上班路上遇到了朋友” 应改为 “我今天早上起床后，先刷牙洗脸，然后吃早餐，接着去上班，路上遇到了朋友”）；分句之间需根据逻辑关系使用关联词（如 “天气很冷，我还是出门了” 应改为 “虽然天气很冷，但是我还是出门了”）；语句读起来需自然流畅，符合日常表达习惯（如 “我对这个问题进行了思考” 可简化为 “我思考了这个问题”，更简洁自然）。

9. 请按照以下格式输出检查结果：

10. 错误类型：[语法错误（中文 / 英文） / 用词不当 / 语句不通顺]
11. 错误位置：[如‘中文技术文档的第 4 段第 2 句’‘英文邮件的开头第 1 句’‘宣传文案的第 3 行’]
12. 错误描述：[详细说明错误内容，如‘中文技术文档第 4 段第 2 句 “在系统中添加新用户，需要填写信息” 缺少主语，应为 “用户在系统中添加新用户时，需要填写信息”’]
13. 修改建议：[如‘在 “需要填写信息” 前补充主语 “用户”，修改为 “在系统中添加新用户时，用户需要填写信息”’]

14. 如果没有发现上述错误，请回复‘未发现语言表达类错误’。”

    4.4.2 使用说明

15. 区分语言类型：若检查的是中文内容，删除英文语法错误相关的检查标准和描述；若检查的是英文内容，删除中文语法错误相关的检查标准和描述，确保提示词针对性更强。
16. 补充行业术语表（可选）：若检查的是专业领域内容（如医疗、法律、编程），可在提示词中补充该领域的常用术语表，比如 “编程领域常用术语：API 接口（应用程序编程接口）、变量（存储数据的容器）、函数（实现特定功能的代码块）”，让大模型更准确地判断用词是否恰当。
17. 提供语言风格要求（可选）：若内容有特定的语言风格要求（如技术文档需简洁严谨、宣传文案需生动形象），可在提示词中补充，比如 “中文技术文档需使用简洁严谨的语言，避免口语化表达（如‘搞定’‘弄好’等）”，让大模型在检查时兼顾语言风格。

18. 5. 多错误类型综合检查的提示方法

    在实际使用中，大模型生成的内容可能同时存在多种类型的错误（如既存在格式错误，又存在信息准确错误）。此时，需要设计综合检查的提示词，让大模型一次性检查多种错误类型，提高效率。

    5.1 综合检查提示词模板

    “请检查你之前生成的【内容类型及主题，如‘Markdown 格式的 2024 年中国经济数据报告’‘Python 代码实现用户登录功能’】，重点检查是否存在以下 4 类错误：

19. 内容逻辑类错误：逻辑矛盾、逻辑漏洞、不符合常识；
20. 格式规范类错误：排版错误、符号错误、格式不统一；
21. 信息准确类错误：数据错误、概念错误、事实错误；
22. 语言表达类错误：语法错误（中文 / 英文）、用词不当、语句不通顺。

23. 检查标准：

    5.1.1 内容逻辑类错误检查标准

24. 逻辑矛盾：两个观点同时成立会导致结果冲突；
25. 逻辑漏洞：缺少关键步骤、条件或信息，导致用户无法完成操作或理解核心观点；
26. 不符合常识：描述与科学常识、生活常识或行业常识不符。

27. 5.1.2 格式规范类错误检查标准（根据内容类型补充）

    以 “Markdown 格式的 2024 年中国经济数据报告” 为例：

28. 排版错误：一级标题用‘# ’开头，二级标题用‘## ’开头，三级标题用‘### ’开头；无序列表用‘- ’开头，有序列表用‘1. ’开头；
29. 符号错误：英文引号用‘""’，不能用中文引号‘“”’；数据中的逗号用英文逗号‘,’，不能用中文逗号‘，’；
30. 格式不统一：日期格式统一为‘YYYY-MM-DD’；数据单位统一（如‘万亿元’不能有时用‘万亿’，有时用‘万亿元’）；表格用 Markdown 标准语法，表头与内容列数一致。

31. 5.1.3 信息准确类错误检查标准

32. 数据错误：数据与权威来源（如国家统计局官网、行业权威报告）不符；单位错误或计算错误；
33. 概念错误：概念定义与专业教材、行业标准不符；混淆不同概念；
34. 事实错误：历史事件、人物信息、客观事实的描述与公认事实不符。

35. 5.1.4 语言表达类错误检查标准

36. 语法错误（中文）：句子成分完整，词语搭配符合中文习惯，语序合理；
37. 用词不当：近义词使用正确，专业术语规范，词性使用准确；
38. 语句不通顺：句子长度适中，分句之间有合理连接，表达自然流畅。

39. 请按照以下格式输出检查结果，每种错误类型单独列出：

    【错误类型，如内容逻辑类错误】

40. 错误位置：[如‘报告第 2 章第 3 节’‘表格第 5 行第 2 列’]
41. 错误描述：[详细说明错误内容]
42. 修改建议：[给出具体修改方案]

43. 若某类错误未发现，可标注‘该类未发现错误’。”

    5.2 综合检查提示词使用说明

44. 明确内容类型和主题：在模板中 “【内容类型及主题】” 处，清晰说明内容的类型（如 Markdown 文档、代码、文案）和具体主题（如经济数据报告、用户登录代码、产品宣传文案），让大模型明确检查对象。
45. 调整格式规范检查标准：根据实际内容类型，修改 “格式规范类错误检查标准”，删除不相关的内容，补充该类型特有的格式要求（如检查 Python 代码时，格式规范标准改为代码缩进、括号配对、引号使用等要求）。
46. 控制检查范围（可选）：若内容篇幅较长，可在提示词中限定检查范围，比如 “重点检查报告的第 1-3 章内容”“重点检查 Python 代码中的登录验证函数部分”，避免大模型检查过于宽泛，影响检查精度。
47. 分步检查（可选）：若综合检查后发现错误较多，可分步骤让大模型逐一检查不同错误类型。比如先检查格式规范类错误，修改完成后，再检查信息准确类错误，确保每种错误类型都能被充分检查。

48. 6. 实战案例：用提示词让大模型检查输出错误

    通过具体的实战案例，能更直观地了解如何使用提示词让大模型检查自身输出错误。下面以 “大模型生成 Python 代码实现用户登录功能，存在多种错误” 为例，展示完整的检查流程。

    6.1 案例背景

    大模型生成的 Python 代码目标：实现用户登录功能，要求用户输入用户名和密码，与预设的正确用户名（“admin”）和密码（“Admin123!”）对比，登录成功提示 “登录成功！”，登录失败提示 “用户名或密码错误！”。

    大模型生成的初始代码如下：

    def login():

    username = input("请输入用户名：")

    password = input("请输入密码：")

    if username == "admin" and password == "Admin123"

    print("登录成功！")

    else

    print("用户名或密码错误！")

    login()

    6.2 设计提示词进行错误检查

    根据代码内容，需检查格式规范类错误（代码语法）、信息准确类错误（密码是否与需求一致）、内容逻辑类错误（逻辑是否完整），设计提示词如下：

    “你之前生成的 Python 代码用于实现用户登录功能，代码如下：

    def login():

    username = input("请输入用户名：")

    password = input("请输入密码：")

    if username == "admin" and password == "Admin123"

    print("登录成功！")

    else

    print("用户名或密码错误！")

    login()

    请检查这段代码是否存在以下错误：

49. 格式规范类错误（Python 代码）：括号是否配对、语句结尾是否有分号错误、缩进是否正确；
50. 信息准确类错误：代码中的正确密码是否与需求（正确密码为 “Admin123!”）一致；
51. 内容逻辑类错误：登录逻辑是否完整（如是否有输入为空的判断）、是否存在逻辑矛盾。

52. 检查标准：

53. 格式规范类错误：Python 代码中，if 和 else 语句后需加冒号 “:”；语句结尾一般不加分号；函数内代码缩进用 4 个空格。
54. 信息准确类错误：代码中的正确密码需与需求 “Admin123!” 完全一致，不能缺少特殊字符 “!”。
55. 内容逻辑类错误：需判断用户名或密码是否为空，若为空应提示 “用户名或密码不能为空！”；登录逻辑需无矛盾，即只有用户名和密码都正确时才提示登录成功。

56. 请按照以下格式输出检查结果：

    【错误类型】

57. 错误位置：[代码行数]
58. 错误描述：[详细说明错误内容]
59. 修改建议：[给出具体修改代码]

60. 若某类错误未发现，标注‘该类未发现错误’。”

    6.3 大模型输出的检查结果

    ### 【格式规范类错误】

    1. 错误位置：代码第4行、第6行

    2. 错误描述：第4行if语句后缺少冒号“:”，不符合Python语法要求；第6行else语句后缺少冒号“:”，不符合Python语法要求。

    3. 修改建议：在第4行if语句末尾添加冒号“:”，修改为“if username == "admin" and password == "Admin123":”；在第6行else语句末尾添加冒号“:”，修改为“else:”。

    ### 【信息准确类错误】

    1. 错误位置：代码第4行

    2. 错误描述：代码中正确密码写为“Admin123”，缺少需求中要求的特殊字符“!”，与预设正确密码“Admin123!”不一致，会导致用户输入正确密码时仍提示登录失败。

    3. 修改建议：将第4行密码对比部分修改为“password == "Admin123!"”，即“if username == "admin" and password == "Admin123!":”。

    ### 【内容逻辑类错误】

    1. 错误位置：代码第2-3行后

    2. 错误描述：代码中未判断用户名或密码是否为空，若用户直接输入回车（用户名或密码为空），会直接进入与正确信息对比的逻辑，不符合常规登录逻辑，也未给出对应的提示。

    3. 修改建议：在获取用户名和密码后，添加判断空值的逻辑，代码如下：

    def login():

    username = input("请输入用户名：")

    password = input("请输入密码：")

    # 新增判断用户名或密码为空的逻辑

    if not username or not password:

    print("用户名或密码不能为空！")

    return

    if username == "admin" and password == "Admin123!":

    print("登录成功！")

    else:

    print("用户名或密码错误！")

    login()

    6.4 案例总结

61. 提示词需包含完整上下文：在提示词中直接粘贴大模型生成的代码，让大模型明确检查对象，避免因上下文缺失导致检查不精准。
62. 检查标准需具体：针对 Python 代码的语法要求、需求中的密码信息、登录逻辑的常规要求，给出具体的检查标准，让大模型有明确的判断依据。
63. 输出格式需清晰：规定每种错误类型单独列出，包含错误位置、描述和修改建议，方便后续直接根据检查结果修改代码。

64. 7. 提升大模型检查效果的进阶技巧

    除了基础的提示方法，还有一些进阶技巧能进一步提升大模型检查自身输出错误的效果，让检查更精准、更高效。

    7.1 分角色提示法

    给大模型设定特定的角色，让它以该角色的身份进行错误检查。比如检查代码时，设定 “你是一名资深 Python 开发工程师，擅长发现代码中的语法错误、逻辑漏洞和安全问题”；检查医疗文档时，设定 “你是一名经验丰富的医生，熟悉医疗行业常识和诊疗规范，能发现医疗文档中的常识错误和术语错误”。

    角色设定能让大模型更贴合具体场景的专业要求，提高检查的专业性和精准度。示例提示词片段：“现在请你以资深 Python 开发工程师的身份，检查以下 Python 代码，重点关注代码的语法正确性、逻辑完整性和安全性（如是否存在密码明文存储问题）...”

    7.2 多次迭代检查法

    第一次检查后，根据大模型输出的检查结果修改内容，然后再次生成提示词，让大模型检查修改后的内容是否仍存在错误。多次迭代能逐步减少错误，确保内容质量。

    比如第一次检查 Python 代码，发现语法错误和逻辑漏洞，修改后，再次提示：“我已根据你的检查结果修改了 Python 代码，修改后的代码如下：[粘贴修改后的代码]。请再次检查代码是否仍存在格式规范类错误、信息准确类错误和内容逻辑类错误，确保代码能正常运行且符合需求。”

    7.3 对比式提示法

    若有正确的参考内容（如需求文档、标准模板、正确案例），可在提示词中让大模型将自身生成的内容与参考内容对比，找出差异，进而判断是否存在错误。

    示例提示词：“以下是用户登录功能的需求文档（参考内容）：1. 正确用户名为 “admin”，正确密码为 “Admin123!”；2. 需判断用户名和密码是否为空，为空提示 “用户名或密码不能为空！”；3. 登录成功提示 “登录成功！”，失败提示 “用户名或密码错误！”。你之前生成的 Python 代码如下：[粘贴代码]。请对比代码与需求文档，找出代码中与需求不符的地方（即错误），并给出修改建议。”

    7.4 限制输出长度法

    若大模型检查结果过于冗长，可在提示词中限制输出长度，要求只保留关键信息（错误位置、核心错误描述、简洁修改建议），避免无关内容干扰。

    示例提示词：“请检查以下 Python 代码是否存在格式规范类错误，检查结果需控制在 300 字以内，仅包含错误位置、核心错误描述和简洁修改建议，无需多余解释。代码如下：[粘贴 Python 代码]”

    使用限制输出长度法时，需注意根据错误的复杂程度合理设定长度。若错误较简单（如单一语法错误），可将长度限制在 100-200 字；若错误较复杂（如多个逻辑漏洞），可适当放宽长度至 300-500 字，确保能完整说明错误信息。

    7.5 错误优先级标注法

    在提示词中要求大模型对发现的错误标注优先级（如高、中、低），优先级根据错误对内容使用的影响程度划分。高优先级错误是指严重影响内容使用的错误（如代码语法错误导致无法运行、关键数据错误导致结论偏差）；中优先级错误是指影响内容体验但不致命的错误（如格式不统一导致阅读困难、用词不当导致理解偏差）；低优先级错误是指对内容使用影响极小的错误（如语句不够简洁、标点符号使用不规范但不影响理解）。

    示例提示词：“请检查以下 Markdown 格式的产品说明书，除了常规的错误描述和修改建议外，需为每个错误标注优先级（高 / 中 / 低）。优先级划分标准：1. 高优先级：错误导致说明书关键信息错误或无法正常阅读；2. 中优先级：错误影响阅读体验但不影响关键信息理解；3. 低优先级：错误对阅读和理解影响极小。产品说明书内容如下：[粘贴说明书内容]”

    错误优先级标注能帮助我们快速聚焦关键错误，优先处理高优先级错误，提高错误修改效率。比如在项目上线前，可优先修改代码中的高优先级错误（如导致程序崩溃的语法错误），中低优先级错误（如代码注释格式不统一）可在后续迭代中优化。

    7.6 场景模拟提示法

    在提示词中模拟内容的实际使用场景，让大模型从场景使用者的角度检查错误。比如检查用户登录代码时，模拟 “普通用户使用登录功能” 的场景；检查产品宣传文案时，模拟 “消费者阅读文案后决定是否购买” 的场景。场景模拟能让大模型更精准地发现与实际使用相关的错误（如用户操作流程中的逻辑漏洞、文案中影响消费者决策的误导性描述）。

    示例提示词：“请模拟普通用户使用登录功能的场景，检查以下 Python 登录代码是否存在问题。普通用户可能会出现的操作：1. 输入正确用户名和密码；2. 输入空用户名或空密码；3. 输入错误用户名；4. 输入错误密码。请从这些操作场景出发，检查代码是否能正确响应，是否存在影响用户使用的错误。代码如下：[粘贴 Python 登录代码]”

    使用场景模拟提示法时，需尽可能列出实际使用中的典型场景，场景越全面，大模型发现的潜在错误就越丰富。

    8. 大模型检查自身输出错误的注意事项

    虽然用提示词让大模型检查自身输出错误能提高效率，但在实际使用中仍有一些注意事项，避免因过度依赖大模型导致错误遗漏或误判。

    8.1 不盲目依赖大模型检查结果

    大模型并非万能，可能存在漏检或误判错误的情况。比如对于非常专业的领域知识（如医疗行业的专业术语、金融行业的复杂计算），大模型可能因知识储备不足而漏检错误；对于逻辑极其复杂的内容（如多条件嵌套的代码逻辑），大模型可能误判错误。

    因此，在大模型检查完成后，需结合人工检查进行二次确认。尤其是关键内容（如项目核心代码、重要报告数据），必须经过人工逐一核对，确保所有错误都被发现和修改。

    8.2 明确大模型的知识边界

    大模型的知识有一定的时间范围和领域范围限制。比如 2023 年训练的大模型无法获取 2024 年后的最新数据，可能导致对 2024 年后的时效性信息（如最新政策、最新行业数据）检查不准确；专注于编程领域的大模型，在检查医疗文档时可能因领域知识不足而效果不佳。

    在使用大模型检查错误前，需明确其知识边界。若内容涉及最新信息或专业领域，需在提示词中补充相关最新知识或专业信息，或选择更贴合该领域的大模型进行检查。比如检查 2024 年的经济数据报告时，在提示词中补充 “2024 年中国 GDP 总量约为 126 万亿元（来源：国家统计局）” 等最新数据；检查医疗文档时，选择医疗领域专用大模型。

    8.3 避免提示词过于复杂

    提示词过于复杂（如包含过多检查标准、过长的上下文描述）可能导致大模型理解混乱，反而降低检查效果。比如在一份提示词中同时包含 10 类检查标准、500 字以上的上下文描述，大模型可能遗漏部分检查标准或误解上下文信息。

    设计提示词时，需保持简洁明了。若检查内容涉及多个方面，可分多次使用简单提示词进行检查，而非一次性使用复杂提示词。比如先使用提示词检查内容的逻辑错误，再使用另一份提示词检查内容的格式错误，逐步完成所有检查任务。

    8.4 记录并复用有效提示词

    在实际使用中，会发现部分提示词检查效果较好（如能精准发现某类错误）。可将这些有效提示词记录下来，按错误类型（如逻辑类错误、格式类错误）或内容类型（如代码、文档、文案）分类存储，形成提示词模板库。

    后续遇到类似的检查需求时，可直接复用模板库中的提示词，只需根据具体内容稍作修改，减少重复设计提示词的时间。同时，可定期对模板库中的提示词进行优化，根据新的使用经验调整检查标准或输出格式，不断提升提示词的检查效果。

    9. 不同场景下的提示词示例汇总

    为了方便大家在不同场景下快速使用提示词让大模型检查自身输出错误，下面汇总了常见场景的提示词示例，涵盖代码、文档、文案三大类内容。

    9.1 代码类内容检查提示词示例

    9.1.1 Python 代码语法错误检查

    “请检查以下 Python 代码是否存在语法错误（如括号不匹配、冒号缺失、缩进错误），检查结果需包含错误位置、错误描述和修改建议。代码如下：

    def calculate_sum(a, b)

    sum_result = a + b

    print("两数之和为：", sum_result)

    calculate_sum(5, 3)

    ”

    9.1.2 Java 代码逻辑错误检查

    “请以资深 Java 开发工程师的身份，检查以下 Java 代码的登录逻辑是否存在错误（如条件判断错误、流程缺失）。代码目标：实现用户登录，当用户名是 “user123” 且密码是 “Pass123!” 时登录成功，否则登录失败。代码如下：

    public class Login {

    public static void main(String[] args) {

    String username = "user123";

    String password = "Pass123!";

    if (username == "user123" || password == "Pass123!") {

    System.out.println("登录成功！");

    } else {

    System.out.println("登录失败！");

    }

    }

    }

    请输出错误位置、错误描述和修改建议。”

    9.2 文档类内容检查提示词示例

    9.2.1 Markdown 格式报告格式错误检查

    “请检查以下 Markdown 格式的项目报告是否存在格式错误，检查标准：1. 一级标题用‘# ’开头，二级标题用‘## ’开头；2. 无序列表用‘- ’开头；3. 表格用 Markdown 标准语法（‘|’分隔列，‘-’分隔表头和内容）。报告内容如下：

    项目进度报告

    1. 项目概况

65. 项目名称：电商平台开发
66. 项目周期：2025.01-2025.06

67. 2. 进度统计

    | 任务名称 | 计划完成时间 | 实际完成时间

    | 需求分析 | 2025-01-31 | 2025-01-28

    | 系统设计 | 2025-03-31 | 2025-04-05

    ”

    请输出错误位置、错误描述和修改建议。”

    9.2.2 Excel 数据表格信息准确检查

    “请检查以下 Excel 数据表格中的信息是否准确，数据需符合 2024 年某电商平台的销售数据常识（如月度销售额一般不会出现负数、销量与销售额的计算逻辑为销售额 = 销量 × 单价）。表格内容如下：

    | 月份 | 商品名称 | 销量（件） | 单价（元） | 销售额（元） |

    | 1 月 | 手机 | 500 | 3000 | 1500000 |

    | 2 月 | 电脑 | -100 | 5000 | -500000 |

    | 3 月 | 平板 | 300 | 2000 | 500000 |

    ”

    请输出错误位置、错误描述和修改建议，并标注错误优先级（高 / 中 / 低）。”

    9.3 文案类内容检查提示词示例

    9.3.1 产品宣传文案语言表达检查

    “请检查以下产品宣传文案是否存在语言表达类错误（如语法错误、用词不当、语句不通顺），文案需符合简洁、生动的宣传风格，避免口语化表达。文案内容如下：

    “本品牌的新款手机，它的拍照功能非常好，像素很高，拍出来的照片很清晰。而且，手机的电池也很耐用，充一次电可以用很久，使用起来很方便，大家快来买啊！”

    ”

    请输出错误位置、错误描述和修改建议。”

    9.3.2 英文邮件内容准确与格式检查

    “请检查以下英文邮件是否存在信息准确类错误（如收件人名称错误、时间错误）和格式规范类错误（如邮件主题格式、落款格式）。邮件内容如下：

    Subject: Meeting Arrangement for Project X

    Dear Mr. Smith,

    This is to inform you that the meeting for Project X will be held on 2025-09-30 at 10:00 AM in Conference Room A. Please bring the project report with you.

    Best regards,

    Li Ming

    Date: 2025-09-25

    P.S. The meeting was originally scheduled for 2025-09-28, but it has been rescheduled.

    ”

    已知信息：1. 收件人正确名称是 “Mr. Jones”；2. 会议重新安排后的时间是 “2025-09-29”。请结合已知信息输出错误位置、错误描述和修改建议。”

    10. 大模型检查自身输出错误的常见问题与解决办法

    在使用提示词让大模型检查自身输出错误的过程中，可能会遇到一些反复出现的问题，下面针对这些常见问题给出具体的解决办法。

    10.1 问题 1：大模型漏检部分错误

    10.1.1 问题表现

    大模型检查后，仍有明显错误未被发现。比如检查 Python 代码时，大模型漏检了 “函数参数缺失” 的错误；检查报告时，漏检了 “关键数据单位错误” 的问题。

    10.1.2 解决办法

68. 细化检查标准：在提示词中更详细地列出需要检查的错误类型和具体场景。比如检查 Python 代码时，补充 “需检查函数定义是否包含所有必要参数，调用函数时是否传入正确数量的参数”；检查报告时，补充 “需检查所有数据的单位是否统一，是否与数据类型匹配（如‘人数’单位应为‘人’，‘金额’单位应为‘元’）”。
69. 分多次专项检查：将原本一次检查的内容拆分为多次专项检查，每次只聚焦一种错误类型。比如第一次专门检查代码的语法错误，第二次专门检查代码的参数错误，第三次专门检查代码的逻辑错误，通过专项检查减少漏检概率。
70. 提供错误示例：在提示词中给出 1-2 个同类错误的示例，让大模型更清楚地了解需要检查的错误类型。比如检查报告数据错误时，示例 “错误示例：‘2024 年 1 月销售额 500 元’应为‘2024 年 1 月销售额 50000 元’，数据数值错误”，帮助大模型明确检查方向。

71. 10.2 问题 2：大模型误判错误（将正确内容判定为错误）

    10.2.1 问题表现

    大模型将原本正确的内容判定为错误，给出错误的修改建议。比如将正确的 Python 代码缩进（4 个空格）判定为缩进错误，建议改为 2 个空格；将正确的 “2024 年中国人口约 14 亿” 判定为数据错误，建议修改为 13 亿。

    10.2.2 解决办法

72. 明确正确标准：在提示词中清晰说明正确的标准，避免大模型因标准模糊而误判。比如检查 Python 代码缩进时，明确 “Python 代码缩进标准为 4 个空格，符合该标准的缩进为正确，无需修改”；检查中国人口数据时，明确 “2024 年中国人口数据以国家统计局发布的约 14 亿为准，符合该数据的描述为正确”。
73. 提供正确示例：在提示词中给出正确内容的示例，让大模型对比示例判断内容是否正确。比如检查 Markdown 标题格式时，示例 “正确一级标题格式：# 项目介绍；正确二级标题格式：## 项目目标”，大模型可根据示例判断其他标题格式是否正确。
74. 补充背景信息：若内容涉及特定领域或特殊情况，在提示词中补充相关背景信息。比如某项目因特殊要求，Python 代码缩进使用 2 个空格，需在提示词中说明 “本项目 Python 代码缩进标准为 2 个空格，按该标准检查缩进是否正确”，避免大模型按通用标准误判。

75. 10.3 问题 3：大模型检查结果格式混乱

    10.3.1 问题表现

    大模型未按照提示词中规定的格式输出检查结果，比如未区分错误类型、错误位置描述模糊、缺少修改建议，导致检查结果难以阅读和使用。

    10.3.2 解决办法

76. 给出格式示例：在提示词中不仅规定输出格式，还给出完整的格式示例，让大模型参考示例输出。比如规定格式后，示例 “格式示例：

77. 【格式规范类错误】

78. 错误位置：Markdown 报告第 2 行二级标题
79. 错误描述：二级标题使用‘### ’开头，不符合‘## ’的标准格式
80. 修改建议：将‘### 1. 项目概况’改为‘## 1. 项目概况’”
81. 强调格式要求：在提示词中使用加粗、大写等方式强调格式要求，引起大模型重视。比如 “请严格按照以下格式输出检查结果，不得更改格式结构！ 格式要求：1. 错误类型：[类型名称]；2. 错误位置：[具体位置]；3. 错误描述：[详细描述]；4. 修改建议：[具体建议]”
82. 简化格式要求：若大模型难以理解复杂格式，可简化输出格式，减少格式要求的复杂度。比如将原本包含 5 项内容的格式简化为 3 项：“1. 错误位置；2. 错误描述；3. 修改建议”，降低大模型的理解难度。
83. 缩小检查范围：在提示词中限定检查的具体范围，避免大模型检查无关内容。比如检查 1000 字的报告时，明确 “仅检查报告的第 1-3 段内容，无需检查其他段落”，减少大模型的处理量。
84. 简化检查目标：一次只让大模型检查一种错误类型，而非多种错误类型同时检查。比如原本让大模型同时检查语法错误、格式错误和信息错误，改为 “本次仅检查语法错误，其他错误后续再检查”，降低大模型的任务复杂度。
85. 拆分内容：若内容篇幅较长（如超过 2000 字的文档、超过 100 行的代码），将内容拆分为多个片段，让大模型分片段检查。比如将 200 行的 Python 代码拆分为 4 个 50 行的片段，逐一让大模型检查，避免因内容过长导致处理耗时增加。

86. 10.4 问题 4：大模型检查耗时过长

    10.4.1 问题表现

    大模型检查内容时，花费过长时间（如检查 500 字的文档耗时超过 5 分钟），影响工作效率。

    10.4.2 解决办法

87. 缩小检查范围：在提示词中限定检查的具体范围，避免大模型检查无关内容。比如检查 1000 字的报告时，明确 “仅检查报告的第 1-3 段内容，无需检查其他段落”，减少大模型的处理量。​
88. 简化检查目标：一次只让大模型检查一种错误类型，而非多种错误类型同时检查。比如原本让大模型同时检查语法错误、格式错误和信息错误，改为 “本次仅检查语法错误，其他错误后续再检查”，降低大模型的任务复杂度。​
89. 拆分内容：若内容篇幅较长（如超过 2000 字的文档、超过 100 行的代码），将内容拆分为多个片段，让大模型分片段检查。比如将 200 行的 Python 代码拆分为 4 个 50 行的片段，逐一让大模型检查，避免因内容过长导致处理耗时增加。​