在实际使用 AI 产品的过程中很多人会遇到一个明显反差有人用大模型写代码、做分析、写文案又快又稳有人却觉得 AI“答非所问”“编造内容”“输出质量不稳定”。问题往往不在模型本身而在提问方式。本文围绕“从搜索关键词到写好 Prompt”这条主线解释大模型如何处理你的输入拆解高效 Prompt 的核心要素讲清楚温度、Top-p、最大 Token 这些参数怎么和 Prompt 配合并给出针对“invalid prompt”“prompt is too long”“AI 幻觉”等高频问题的排查思路。学完之后你可以把一套可复用的提示词方法论直接用到工作流中。1. 先看清大模型的工作方式才能理解 Prompt 为什么重要1.1 语言模型不是搜索引擎而是“概率化文本补全器”很多人第一次使用 AI 时会不自觉地把它当成“更聪明的百度”。搜索关键词“Java 内存溢出 排查”搜索引擎返回的是网页链接、博客标题、摘要而大模型收到同样的词返回的是它根据语法模式“续写”出来的一整段回答。这种差异决定了沟通方式必须不同。搜索引擎的核心是倒排索引它在乎的是“哪些页面包含这些词”所以关键词越精确越好。大语言模型的核心是学习过的文本规律它在给定上文的情况下逐个预测下一个最合理的 Token。也就是说你给它什么上下文它就在这个上下文基础上继续生成内容。理解这一点后一个重要的判断就出现了Prompt 不是“命令”而是“下文生成条件”。模型没有真的“听懂”指令它是在你的约束下做概率采样。同一个问题如果上下文含糊模型就会从一个很宽的概率分布里随便选一种回答如果上下文清晰模型生成的内容就会被收窄到更符合预期的范围。所以写 Prompt 的核心目标不是“让 AI 明白”而是“把候选输出空间压缩到最小可行范围”。这也是为什么同样的模型有人能稳定输出可用结果有人却反复得到泛泛而谈的内容。1.2 从“关键词罗列”到“意图描述”表达方式的转变搜索时代的习惯是“堆关键词”例如“Python 读取大文件 内存优化”。这些词作为搜索词够用但直接发给大模型效果往往一般。试想两个写法输入一“Python 读取大文件 内存优化”输入二“我正在用 Python 处理一个 5GB 的 CSV 文件希望逐行读取避免一次性加载到内存。请给出两种方案并说明每个方案的适用场景和内存占用特点。”第二个写法信息量更多明确任务处理 CSV、明确约束逐行读取避免加载全量、明确输出要求两种方案、适用场景、内存特点。大模型生成时能依据这些细节选择更合适的措辞、库和解释角度。从关键词到意图描述的转变核心是回答六个问题我是谁或我希望模型扮演什么角色。我的任务是什么要处理的对象是什么。背景信息有哪些输入数据是什么样的。有哪些硬性约束例如“不能用 X 库”“必须兼容 Python 3.8”。期望的输出格式是什么。希望避免什么或对结果有什么质量要求。并不是每次都要全写但如果生成结果不满意先检查这六项里缺了哪一项。通常情况下一个 500 字但结构化清晰的 Prompt远胜于一句 20 字的模糊指令。1.3 Token 不只有长度意义它决定模型如何理解你的请求大模型处理文本时会把输入输出拆成 Token。Token 不是字也不是词而是模型分词器切分出来的“语义碎片”。中文里一个字可能是一个 Token也可能一个字对应多个 Token一行代码可能被拆成好几个 Token。Token 数量的意义有两个层面第一它是计费和上下文的单位。输入和输出 Token 都会消耗额度模型能接受的最大上下文窗口也是按 Token 计算的。所谓“prompt is too long”这类报错本质是输入 Token、输出预期 Token 和历史对话 Token 的总和逼近或超过了模型上限。第二它影响生成质量。上下文窗口是有限的当你的 Prompt 塞满无关内容时模型真正能用来推理的空间就被挤占了。很多长对话出错不是因为模型变笨了而是因为历史记录太长早期的重要信息被截断或稀释。因此写 Prompt 时要注意“信息密度”。不要把关键词堆成没有结构的长文本而是要有层次地组织信息角色、背景、任务、输出格式各占一段。这样做不仅让模型更容易跟随也方便你自己在出错时定位是哪一段导致的问题。2. 写 Prompt 的底层框架角色、背景、任务、约束、示例、输出格式2.1 六个核心要素缺什么补什么一个可复现的高质量 Prompt可以拆成六个要素。这里把它整理成速查表要素作用缺失时的表现角色限定模型从哪个专业视角输出回答风格平淡不够专业或偏科普背景提供上下文、数据来源、前置条件模型自己假设场景常答非所问任务明确要完成什么动作输出泛泛而谈没有重点约束规定边界如技术栈、数据源、禁止项使用了你不想要的库或方案示例给出输入输出样例格式自由发散很难对齐输出格式要求 JSON、表格、代码块或 Markdown结果是长篇散文难以复用把这六项理解成“填空题”会比“自由发挥”更稳定。比如翻译类任务只写“翻译成英文”模型可能自由发挥如果加上“这是产品说明文档请保持术语一致数字和型号保留原样输出为表格左边中文右边英文”结果就会完全不同。设计原则是不是写得越长越好而是每一段都要能回答模型的一个潜在疑问。模型在生成前会隐式判断“用户到底想要什么”。如果 Prompt 没有给出明确答案它就会大概率选择一个“通用的、看起来最安全的答案”而这个答案往往不适合你的具体场景。2.2 从“一句指令”改造成“结构化 Prompt”的完整示例用一个最常见的需求说明改造过程请 AI 写一封英文邮件。第一版帮我把以下内容翻译成英文邮件项目延期两周因为第三方API返回数据不稳定。这个 Prompt 能出结果但容易得到一封结构简单、缺少礼貌用语和解释语气的邮件。第二版加入背景和格式请扮演一位有十年经验的海外项目交付经理帮我把下面的中文内容改写成一封发给客户的英文邮件。 背景 - 客户是德国合作方重视时间节点和问题原因。 - 延期原因第三方身份验证 API 在连续 48 小时内出现间歇性 5xx 错误影响联调。 - 新时间节点比原计划晚两周下周一开始回归测试。 要求 1. 语气专业、克制不回避延期事实但不要过度道歉。 2. 说明原因时给出技术判断不使用“可能也许”这类模糊词。 3. 邮件结构主题行 称呼 现状说明 原因解释 新计划 下一步行动。 4. 输出 Markdown 格式主题行单独一行。第二版为什么更稳因为角色、背景、约束、输出格式全部明确模型不需要猜测客户是谁、延期原因是什么、邮件该是什么语气。它只需要在约束范围内组织语言。对比可见改造 Prompt 的过程不是“写更长的话”而是“让每一个必要的决策都有一个明确依据”。判断 Prompt 是否合格可以先问自己如果我是执行者只凭这些信息能不能一次做对如果不行就继续补信息。2.3 常用生成参数的温度、Top-p、max_tokens 如何与 Prompt 配合Prompt 文本只是影响输出的一个因素还有一个经常被忽略的因素是生成参数。在 OpenAI 兼容的 API 或本地模型的接口里常见参数如下参数含义常见值调小效果调大效果temperature控制采样随机性0.2 到 0.8更稳定、更重复更有创造性、更发散top_p控制候选 Token 的累积概率范围0.9 左右输出更保守可能给出更冷门词max_tokens限制生成的最大长度按任务类型定可能被截断占用长上下文时间presence_penalty鼓励讨论新话题0 到 1容易重复更愿意换主题frequency_penalty降低重复用词0 到 1容易啰嗦减少重复表达调 Prompt 时通常建议先把 temperature 调低到 0.2 左右用来测 Prompt 本身是否稳定。如果低温度下输出仍然不稳定说明是 Prompt 信息不足而不是参数问题。如果是在做文案灵感、头脑风暴才把 temperature 调到 0.7 以上。一个常见误区max_tokens 设得越大越好。实际上max_tokens 是“输出上限”设太大意味着模型可以在得不到明确约束时继续往下写结果往往是车轱辘话越来越多。更好的方式是先估算任务需要的长度例如写摘要给 300写代码给 800写长文给 2000。同时在 Prompt 里声明“控制在 300 字以内”让模型从语义上知道边界。这里给一个使用 Python 调用这类接口的最小示例用于观察不同参数对结果的影响from openai import OpenAI client OpenAI( api_keyyour-api-key, base_urlhttps://your-api-endpoint ) response client.chat.completions.create( modelgpt-4o-mini, messages[ { role: system, content: 你是一名严谨的技术文档工程师回答要简洁、直接。 }, { role: user, content: 用三句话解释什么是 prompt engineering。 } ], temperature0.3, top_p0.9, max_tokens200 ) print(response.choices[0].message.content)实际项目中并不需要每次调用都手工写一遍参数可以把参数封装成一个配置对象根据任务类型选择“稳定模式”和“创意模式”。下面是一个结构化配置示例from dataclasses import dataclass dataclass class GenerationConfig: temperature: float top_p: float max_tokens: int frequency_penalty: float 0.0 presence_penalty: float 0.0 STABLE GenerationConfig(temperature0.2, top_p0.9, max_tokens1024) CREATIVE GenerationConfig(temperature0.8, top_p0.95, max_tokens2048)注意不同的模型对同一套参数的理解可能不同。模型能力越强通常对较宽松的 Prompt 容错能力也越强模型能力偏弱时就需要更严格的结构化 Prompt。在切换模型后不要默认参数和 Prompt 还能保持同等效果先跑一组最小用例做对比。3. 提升 Prompt 质量的三个进阶手段Few-shot、思维链和迭代优化3.1 少样本示例比直接描述更稳当任务格式比较复杂时语言描述容易产生歧义而给模型看几个“输入-输出”示例效果会好很多。这种方法叫 Few-shot即少样本学习。本质是把抽象规则具象化为可模仿的样例。例如要把用户反馈归类为“功能问题、体验问题、性能问题、其他”四类。只用文字描述模型可能对边界理解不一致。给它几个示例示例1 用户输入保存按钮点了没反应。 输出{category: 功能问题, reason: 按钮交互未生效} 示例2 用户输入页面加载了快10秒我差点关掉。 输出{category: 性能问题, reason: 加载时间过长} 示例3 用户输入界面配色不太好看个人不太喜欢。 输出{category: 体验问题, reason: 主观视觉偏好} 现在对下面这条输入做同样分类只输出 JSON 用户输入登录状态没过一会儿就自动掉了害得我重新填表单。典型规律少样本示例里“覆盖边界情况”比“数量多”更重要。三个示例如果有明显差异模型很快学会格式和判断逻辑。如果所有示例都是同一类情况模型会倾向于把所有输入都归类到那一类。少样本示例同时还能解决一个问题让模型输出稳定格式。比如要求输出 JSON、Markdown 表格或特定命名给一个格式范例几乎不会跑偏。反过来说如果模型生成的内容“形似但细节不对”先检查示例是否够明确是否覆盖了输入中的异常情况。3.2 思维链让复杂推理不摔跤普通 Prompt 让模型直接给答案时模型可能会跳过中间推理直接给出一个“看起来合理但实际错误”的结论。思维链Chain of Thought的作用是要求模型先把推理过程写出来再给出最终结论。典型写法是请逐步思考先列出已知条件再说明解题步骤最后给出结论。计算前不要直接给出最终数字。一个常见的工程问题是“如何把用户输入的日期范围转换成时间戳查询条件”。让模型直接写代码它可能忽略时区和边界。使用思维链后模型会先解释它考虑到的时区来源、日期格式、闭开区间再输出代码。在实现 Agent 场景时思维链的意义更明显。有些 Agent 框架会在循环中调用工具如果 Prompt 里没有要求“先判断需要哪些信息再决定调用哪个工具”Agent 可能会反复调用不合适的工具最后报出“agent terminated due to error”。这类问题往往不是模型坏了而是推理路径没有被约束。需要区分的是思维链并不是所有任务都需要。对“把这段中文翻译成英文”这种线性任务要求模型写一堆推理过程反而浪费 Token。只有在任务包含多个判断步骤、计算、方案选择时才值得显式要求分步思考。对简短任务加一句“直接给出答案不要解释过程”更合适。3.3 迭代调优而不是一版定稿很多人会把 Prompt 当作一次性的输入写完不满意就在结果上手动改。更高效的方式是把调 Prompt 当成一个迭代过程每次只改一个变量。实际操作可以这样先记录当前版本的完整 Prompt 和模型输出。判断最不满意的是哪个方面是格式不对信息缺漏还是语气偏差。只针对这个问题修改一项比如增加一个约束条件或补充一个示例。重新运行对比新输出与旧输出。如果有改进保留这次修改如果没有改进回滚到上一版。这个流程和修 Bug 类似。如果一次改好几个地方输出变化了也无法确定是哪一处产生的效果。日常开发中可以把 Prompt 版本存到项目目录下例如prompts/文件夹按功能命名并记录当前结果示例。下面是一个常见的 Prompt 迭代记录表版本变更内容测试输入问题效果v1初始版产品需求文档输出太泛不合格v2增加角色和输出格式同一份文档结构清晰但缺少方案对比部分合格v3增加方案对比要求和评估维度同一份文档输出完整但过长合格用表格管理 Prompt 的好处是方便追溯避免每次都从零开始。团队协作时也能让其他人理解为什么某个 Prompt 要写成现在这样。不要只在聊天工具里复制粘贴 Prompt那样版本最终会不可控。4. 常见 Prompt 报错与 AI 幻觉的排查链路4.1 把报错当线索invalid prompt、prompt is too long、agent terminated使用 API 或专业产品时经常遇到三类提示。第一类invalid prompt: your prompt was flagged as potentially violating our usage policy. please try again with a different prompt。这个提示出现通常意味着 Prompt 被内容安全策略拦截。常见触发原因有暴力、违法、欺骗性内容某些敏感场景下的自动检测误判或者同一批内容触发了平台规则里的敏感分类。排查路径是先检查 Prompt 里是否有明显违规词汇或高风险指令再尝试把问题改写为更中立的表达。如果内容确实合规但被误判可以分多次请求发送避免把多个高风险话题堆在同一个 Prompt 里。不要通过绕规则的方式来规避检测而应该调整表达方式和使用场景。第二类prompt is too long或自动压缩失败例如automatic compaction failed。它表示输入 Token 超过模型最大上下文或转换器在处理超长上下文时出错。解决思路不是无限扩大窗口而是压缩输入。可以把历史对话摘要化用 10 行以内总结之前的关键信息也可以把参考文档拆分分段让模型处理后再合并结果。还有一种做法是切换支持更大上下文窗口的模型但同样要以“信息是否需要完整保留”为前提长上下文不等于更好的理解能力。第三类agent terminated due to error. you can prompt the model to try again or start。这更像 Agent 运行异常的提示不是 Prompt 语法错误本身而是 Agent 在执行过程中某一步抛错例如工具参数格式不对、外部接口超时、解析模型输出失败。排查顺序是先看日志中具体报错发生在哪一步再检查 Agent 调用的工具 schema 与模型生成格式是否一致最后检查 Prompt 中给工具的描述是否清晰。给模型看的工具说明越明确工具选择错误的概率越低。把这些现象整理成一张排查表报错现象最常见原因检查方式处理方向invalid prompt flagged触发内容安全策略检查 Prompt 用词、场景中立改写、拆分请求prompt is too long输入超出上下文窗口估算 Token、检查历史消息压缩摘要、拆分输入automatic compaction failed超长上下文转换异常查看服务端日志降低输入长度分块处理agent terminated due to errorAgent 调用工具或解析失败看异常栈、工具返回校准工具描述和返回结构输出被截断max_tokens 设太小查看 finish_reason适当调大 max_tokens 或缩短 Prompt这类报错本质上都是“模型上下文管理”和“工具链路管理”的问题而不是模型变笨了。遇到时先按表逐项检查不要反复随机修改 Prompt。4.2 AI 幻觉现象、原因、检查方法和预防AI 幻觉是指模型生成了看起来合理但实际错误或虚构的内容。在写论文、查法规、引用数据等场景中幻觉危害最大。常见的表现是给出根本不存在的论文标题、伪造的数据来源、编写的 API 参数、“看似专业但无法运行”的代码。幻觉的产生原因可以概括为几点模型本身是基于概率生成没有真实数据库做校验模型不知道何时该承认“不知道”当 Prompt 暗示“你什么都知道”时模型更倾向编造一个答案。还有一个现实原因是训练数据本身有错误或过时模型只是把这部分错误复述出来了。排查幻觉的推荐步骤要求模型给出信息出处。虽然不一定准确但能降低编造概率。把“是否确定”这一点写进 Prompt例如“如果信息不确定请明确说明‘我无法确认’”。对引用的数据、版本号、API 名用外部工具或官方文档二次验证。对代码类回答直接执行看报错。对需要保证正确性的任务让模型先生成再让它以批判者身份检查一遍。下面是在 Prompt 中降低幻觉风险的例子请回答关于 Spring Boot 3 中 ConfigurationProperties 的用法。 要求 1. 只基于你确定的知识回答不要编造属性名。 2. 如果你不确定某个配置项是否存在明确写“不确定请查阅官方文档”。 3. 最后列出你需要核对官方文档才能确认的事项。这个 Prompt 的价值在于它把“不确定怎么办”这个规则提前给了模型。模型在生成过程中会倾向于回答“需要确认”而不是硬编。当然这不能替代人工验证。生产环境中的数据统计、金额计算、时间计算都必须通过代码逻辑或数据库严格校验不能直接把模型输出当成最终事实。4.3 通过“最小复现 拆分变量 回归验证”定位 Prompt 问题当 Prompt 表现不稳定时最好的排查方法是像修 Bug 一样做最小复现。先把问题缩小到最小范围。比如你发现“解释代码”这个 Prompt 偶尔输出错误那就不要用真实的大段项目代码来测先造一个 5 行代码的示例观察模型是否稳定。如果最小示例稳定说明问题可能出在真实代码太长、信息量过大或包含某些特殊符号干扰模型解析。拆分变量的思路是Promise 里通常有角色、背景、任务、示例等多个部分。一次只移除或修改一部分观察结果变化。例如原始 Prompt你是后端工程师帮我分析这段代码的并发问题并要求用中文回答输出要点列表。 拆分测试 - 去掉“你是后端工程师” - 去掉“输出要点列表” - 改成“用英文回答”如果发现去掉角色后输出显著变差说明角色设定确实在起作用。如果发现改成英文后输出结构化更强说明中文的输出格式约束还不够严格。回归验证是指当某次修改提升了当前用例的表现后再用之前的旧用例回归一遍确保没有引入新问题。对于同一批 Prompt 任务可以维护一个固定测试集10 个输入、若干期望输出特征。每次调整 Prompt 后跑一遍测试集记录通过率。这个做法和测试驱动开发很像只是被测对象是 Prompt 和模型输出。固定测试集不需要很大关键是覆盖正常输入、边缘输入和错误输入。例如做客服分类任务测试集里应该包含“明确诉求”“包含多个诉求”“错别字很多”“语句不完整”这四类输入。这样测得出的结果才真正有指导意义。5. 搜索关键词和 Prompt 不是对立关系选型对照表5.1 什么时候用搜索什么时候直接用 Prompt搜索引擎和大语言模型各有所长。把两者结合使用比争论“谁的答案更准”更实用。选型时可以按这个逻辑判断需求特征推荐工具原因查最新资讯、实时价格、官方发布搜索引擎模型训练数据可能滞后查规定、法律条文、新闻原文搜索引擎 官方链接模型可能复述错误或省略条件生成初稿、改写文案、脑暴方案Prompt模型擅长生成和重组代码报错、错误日志、配置问题先搜索再 Prompt先找到普遍原因再让模型按场景改写需要权威出处和引用搜索引擎Prompt 不易确认出处真实性需要分析报告、结构化输出Prompt模型擅长整理和归纳很多人误以为“会用 AI 就不要搜索了”。实际工作中搜索负责获取实时和权威信息Prompt 负责把信息转化成可用的产出。一次典型工作流可以是先在搜索引擎里看“Spring Security 6 自定义过滤器”的官方文档把关键段落整理进 Prompt再让模型结合官方文档和你的项目背景生成代码。5.2 搜索关键词也可以借 Prompt 生成形成信息获取闭环搜索引擎和 Prompt 不是竞争的而是可以互相辅助的。一个实用的技巧当你不知道怎样搜索时可以先把目标告诉模型让模型生成几组候选搜索关键词。例如你想找“JVM 内存泄漏排查工具”的资料但不知道业内常用术语。可以这样问我正在排查 Java 服务内存缓慢增长的问题。请帮我生成 10 组搜索关键词用于在搜索引擎查找相关教程。 要求每组关键词包含核心工具名或现象描述例如“jmap dump 堆转储分析”“MAT 泄漏疑点定位”这种格式。模型生成的关键词往往覆盖了jstack、jmap、MAT、Arthas、GC 日志等主题。然后你再把这几组关键词丢回搜索引擎得到的是经过筛选的官方文档和社区讨论。拿到搜索结果后再整理成 Prompt 上下文让模型给你写一份定制化的排查步骤。这个循环过程是目标 - 生成关键词 - 搜索 - 收集权威资料 - 构建 Prompt - 生成答案。它能弥补大模型时效性短板也能弥补搜索结果噪音大的问题。5.3 把高频任务沉淀成可复用的 Prompt 模板与 Skill当某个 Prompt 调通后可以把它整理成模板。模板是固定结构加可变参数适合在团队内部复用。例如role: 后端架构师 task: 评审这段代码的性能隐患 context: | 项目语言Java 17 框架Spring Boot 3.x 场景订单创建接口日均调用量约 50 万 input: {代码片段} output: | - 风险等级 - 问题描述 - 影响分析 - 修复建议这样的模板比“帮我看看这段代码有没有问题”稳定得多。实际使用时把{代码片段}替换成真实代码即可。更进一步可以把模板封装成函数在后端系统里调用def build_code_review_prompt(code: str) - str: return f 你是一名后端架构师请从性能、并发安全、代码可维护性三个维度评审以下代码。 输出格式 1. 风险清单表格风险等级 / 问题 / 位置 / 修复建议 2. 必须修改项 3. 可选优化项 代码 java {code} “Skill”可以理解成“结构化、可复用、面向特定任务的 Prompt 集合”。它比单条 Prompt 更完善通常会包含角色定义、任务流程、输出规范、示例和交互逻辑。如果你经常处理某一类任务比如写 PRD、做数据清洗、写测试用例都可以沉淀成一个 Skill 模板。这样既保证输出一致性又让后来者能够快速接手。6. 可复用的提示词检查清单和最佳实践6.1 发布或使用前的 10 项自查清单无论你是个人使用还是团队接入大模型接口提交一个 Prompt 前都可以用下面的清单做检查。检查项越早发现返工成本越低。序号检查项检查标准1角色是否明确模型知道要以什么身份回答2任务是否单义不会同时让模型做两件冲突的事情3背景是否充分关键假设、数据来源、语言都有说明4约束是否清晰技术栈、禁用词、长度限制已写清楚5示例是否覆盖边界包含正常、异常、边缘输入6输出格式是否指定JSON、表格、代码块等有明确要求7是否明确“不知道怎么处理”模型遇到不确定信息时知道如何表达8是否控制 Token 成本背景资料没有冗余堆砌9是否做过最小复现测试至少跑一次查看输出是否符合预期10是否保存了版本记录能回溯到上一版可用 Prompt检查时最容易忽略的两项是第 7 和第 9。第 7 项影响的是可靠性第 9 项影响的是可复现性。很多人把 Prompt 写好后直接上线结果线上出现幻觉或格式错误才发现没有本地验证过。6.2 学习环境、项目环境和生产环境的不同使用要求Prompt 的使用场景不同严谨程度也要不同。学习环境里重点是理解模型行为可以多用开放式 Prompt通过调整参数观察输出变化目的不是拿到完美答案而是建立手感。此时不需要严格遵守模板但建议每次修改都单独记录方便对比。项目环境里代码和 Prompt 是产品的一部分。需要关注包名、路径、依赖版本是否匹配Prompt 里的示例是否与需求文档一致是否有持久化存储和异常处理。像生成代码的 Prompt输出后要进入代码评审不能直接合并。生产环境的要求更高Prompt 需要外置化至少放在配置文件或模板中心不能硬编码在业务逻辑里。调用接口必须有超时、重试、降级方案。模型的输出要做完整性校验比如检查 JSON 是否能解析、必填字段是否存在。对涉及用户隐私或规范要求的内容模型输出前要经过后置过滤不能直接展示。日志里要保留请求和响应的摘要方便排查问题。一个可以落地的生产调用示例是加入 JSON 解析保护和超时控制import json import time from openai import OpenAI client OpenAI(api_keyyour-api-key) def generate_json(prompt: str, max_retries: int 2) - dict | None: for attempt in range(max_retries): try: resp client.chat.completions.create( modelgpt-4o-mini, messages[ {role: system, content: 只能输出 JSON不要输出任何解释。}, {role: user, content: prompt} ], temperature0.2, max_tokens800, timeout20 ) content resp.choices[0].message.content return json.loads(content) except json.JSONDecodeError: continue except Exception: time.sleep(2 ** attempt) return None真实项目中还需要把模型返回的None或解析失败分支处理成用户可感知的提示而不是直接崩溃。6.3 实操建议先跑通最小闭环再追求复杂效果很多人在学习 Prompt 时容易一开始就冲“复杂的 Agent 系统”或“自动化工作流”结果模型输出混乱也不知道是 Prompt 的问题、参数的问题还是工具链的问题。更好的路径是先跑通一个“最小闭环”找一个非常具体的任务用最简单的 Prompt 结构完成确认输出能稳定复用。然后再逐步加入角色设定、示例、输出格式和外部工具调用。每次增加一个变量都重新回归验证。最小闭环的标准是这样的输入是可重复的比如一条固定测试文本。输出是可判定的比如固定格式的 JSON或一段能成功执行的代码。结果可对比能明确说“这次比上次好在哪里”。运行成本在可控范围内不会因为反复调试消耗大量 Token。当你把几个最小闭环跑熟之后再去尝试多步骤 Agent、多模型组合、提示词模板库等进阶方向会顺利很多。学习 Prompt 的最终目标不是记住几个“万能模板”而是建立一套判断力知道模型为什么会这样输出知道该往哪个方向改知道什么时候该求助文档、什么时候该相信模型。这套判断力才是和 AI 高效沟通的真正核心。