Prompt工程实战：从旅游推荐到人岗匹配的AI应用开发指南

1. 先搞清楚Prompt工程到底在解决什么问题很多人一听到“Prompt提示词”就觉得是让AI听话的咒语或者是一堆花里胡哨的模板。但真正在项目里用过几次大模型LLM你就会发现Prompt工程的核心其实是在解决一个非常具体的问题如何用最少的沟通成本让模型稳定地输出你想要的、格式正确、逻辑清晰的结果。这和你跟一个能力很强但理解方式有点特别的实习生沟通是一个道理。你不能只说“帮我写个报告”也不能事无巨细地写一本操作手册。你得告诉他背景、目标、格式要求甚至举几个例子。Prompt工程就是这套沟通方法。所以这篇文章不是给你一堆“全网最强Prompt模板”而是拆解从零开始构思、写作、调试到实战落地的完整流程。我会用两个非常典型的场景——旅游景点推理和人岗匹配逻辑推理——作为主线带你走一遍。这两个场景刚好覆盖了信息提取、逻辑判断和结构化输出这几个LLM应用中最常见也最头疼的环节。无论你是刚开始接触AI应用开发还是已经试过一些API但总被不稳定的输出搞得很烦这篇文章里的思路和调试方法都能直接拿来用。最关键的不是记住几个词而是学会“怎么想”和“怎么调”。2. 动笔之前明确你的输入、处理和输出在动手写第一个词之前先停下来在白板或文档里回答三个问题。这是避免后续反复调试最有效的一步。2.1 定义清晰的输出目标你想要模型给你什么是一段流畅的文案一个“是/否”的判断一个JSON对象还是一个步骤列表目标越模糊输出就越随机。反面例子“介绍一下北京。”—— 输出可能是历史、文化、美食、景点的大杂烩长度不定。正面例子“请列出北京最著名的三个旅游景点并为每个景点提供一条适合家庭游玩的特色推荐。请以JSON格式输出包含name、reason、family_tip三个字段。”—— 输出结构清晰可直接被程序解析。对于旅游景点推理我们的目标可能是根据用户模糊的描述如“我想去个有历史感、交通方便的地方”推理出具体的景点并给出理由。 对于人岗匹配目标则是根据简历文本和职位描述JD判断匹配度并提取出匹配的技能点和不匹配的差距。2.2 盘点你的输入信息你手头有什么信息可以喂给模型这些信息是否干净、完整用户输入是简短的一句话还是一段长文本有没有歧义比如“苹果”是指水果还是公司上下文对话历史、用户资料、知识库文档。你需要决定把多少上下文放进Prompt。示例你是否有一两个“输入-输出”的完美范例这是Few-Shot Learning的关键。对于我们的实战场景旅游推理输入是用户的一句话需求。可能还需要一份结构化的景点知识库名称、标签如“历史”“自然”“交通便利”等作为上下文。人岗匹配输入是简历文本和JD文本。这两者通常很长需要处理长文本问题。2.3 设定处理规则与约束模型需要遵守哪些规则这里最容易出问题。格式约束必须输出JSON、XML、Markdown表格还是纯文本长度约束回答不超过100字。风格约束用口语化还是专业术语面向儿童还是专家逻辑约束如果无法判断是输出“不确定”还是必须二选一是否需要进行多步推理Chain-of-Thought安全与拒答约束对于不合适的问题应该如何回应把这些想清楚Prompt的骨架就有了。接下来就是填充血肉。3. Prompt的骨架与血肉从角色设定到示例优化一个健壮的Prompt通常包含以下几个部分你可以把它想象成一个给模型的“任务工单”。3.1 赋予角色与背景System Prompt这是定调子的部分通常在对话API中作为系统消息System Message传入。它定义了模型的“人设”和对话的边界。你是一个资深的旅游规划专家和人力资源分析师。你的回答需要专业、准确、结构清晰。请严格遵守用户的指令特别是关于输出格式的要求。如果用户的问题信息不足请礼貌地要求补充而不是随意猜测。为什么重要这能一定程度上稳定模型的输出风格并提前注入领域知识倾向。对于需要切换身份的复杂任务如先做旅游分析再做人岗匹配清晰的系统提示能减少角色混乱。3.2 给出清晰指令与格式User Prompt核心这是用户每次请求的具体内容。必须清晰、无歧义。一个基础的指令结构如下请根据以下用户需求从提供的景点列表中推荐最匹配的一个景点。 【用户需求】 {用户输入文本} 【景点列表】 {你的景点知识库格式为景点名称 | 标签1标签2... | 简介} 【输出要求】 1. 输出必须为JSON格式。 2. JSON包含字段recommended_spot (推荐景点名), reason (匹配原因需引用用户需求中的关键词和景点标签), suggestion (给游客的具体建议)。 3. 如果没有任何景点匹配recommended_spot 字段值为“暂无匹配推荐”并在reason中说明。关键点使用分隔符用【】、---、“”等清晰分隔不同部分帮助模型理解结构。格式化输入数据把景点列表整理成规整的格式比扔给模型一段杂乱段落解析成功率更高。指令具体化不要说“给出理由”要说“匹配原因需引用用户需求中的关键词和景点标签”。这直接约束了推理过程。3.3 提供少量示例Few-Shot Learning对于复杂逻辑说一千道一万不如给个样子看。提供1-3个高质量的“输入-输出”示例能极大提升模型输出的稳定性和质量。示例1 输入用户需求“带孩子想玩得轻松点有互动项目。” 输出{recommended_spot: 上海迪士尼乐园, reason: 用户需求关键词‘带孩子’、‘轻松’、‘互动项目’与景点标签‘亲子’、‘娱乐’、‘主题公园’高度匹配。, suggestion: 建议提前下载官方APP查看排队时间利用早享卡减少等待。} 示例2 输入用户需求“喜欢安静看看古建筑拍拍照。” 输出{recommended_spot: 苏州博物馆, reason: 用户需求关键词‘安静’、‘古建筑’、‘拍照’与景点标签‘历史’、‘建筑’、‘艺术’匹配。博物馆环境清幽建筑极具设计感。, suggestion: 建议预约工作日参观避开人流高峰光影最佳时段在下午。}注意示例的质量至关重要。它必须完美体现你想要的格式、逻辑和风格。垃圾示例只会把模型带偏。3.4 加入思维链Chain-of-Thought引导对于人岗匹配这类需要多步推理的任务直接让模型输出“匹配”或“不匹配”可能结果很武断。引导模型“一步一步想”能产生更可靠的结果。可以在指令中增加请按照以下步骤进行分析 步骤一从职位描述JD中提取核心技能要求3-5条。 步骤二从简历文本中寻找能证明每条技能要求的证据项目经历、技能描述等。 步骤三基于证据逐条判断技能是否匹配并给出简要理由。 步骤四综合所有判断给出整体匹配度评估例如高/中/低并列出最突出的匹配技能和主要差距。 最终请将上述分析结果整合到以下JSON格式中 { “core_skills_from_jd”: [“技能1” “技能2”, ...], “match_analysis”: [ {“skill”: “技能1” “evidence”: “...” “is_match”: true/false, “reason”: “...”}, ... ], “overall_match”: “高/中/低”, “strengths”: [...], “gaps”: [...] }这种结构化的思维链不仅让输出更可信也让你作为开发者更容易调试——你可以看到模型在哪一步的判断上出了问题。4. 实战演练一旅游景点推理Prompt构建与调试假设我们有一个简单的景点数据库现在要处理用户查询“周末想去个近郊有山有水能当天来回的。”4.1 第一版Prompt初稿你是一个旅游助手。根据用户需求推荐景点。 用户需求周末想去个近郊有山有水能当天来回的。 景点列表颐和园历史园林湖泊、香山公园自然登山红叶、古北水镇古镇夜景度假、十渡风景区自然山水漂流。 请推荐一个。问题分析 这个Prompt太简陋了。模型可能会推荐“古北水镇”有山有水但它忽略了“当天来回”——古北水镇距离市区较远通常需要住宿。输出也可能只是一段话不利于程序处理。4.2 第二版Prompt加入结构化指令和约束你是一个北京本地旅游专家非常熟悉各景点的地理位置和适合的游玩方式。 请根据用户的详细需求从以下景点列表中筛选出最符合条件的一个。 【用户需求详情】 * 核心诉求有山有水 * 时间限制周末游玩希望当天往返市区 * 地理位置偏好近郊 【备选景点信息】 1. 名称颐和园 | 标签历史文化遗产皇家园林湖泊市区 | 交通地铁可达距市中心约20公里 | 游玩时间半天至一天 2. 名称香山公园 | 标签自然风光登山红叶近郊 | 交通公交/地铁可达距市中心约30公里 | 游玩时间半天 3. 名称古北水镇 | 标签仿古古镇夜景温泉度假 | 交通自驾/长途车距市中心约150公里 | 游玩时间建议1-2天 4. 名称十渡风景区 | 标签自然山水峡谷漂流户外 | 交通自驾/火车距市中心约100公里 | 游玩时间一天至两天 【你的任务】 1. 重点评估每个景点是否符合“当天往返”这一硬性约束。 2. 比较各景点与“有山有水”诉求的匹配度。 3. 输出一个JSON对象包含以下字段 - recommendation (字符串)推荐的景点名称。如果没有符合条件的填写“未找到完全匹配的景点”。 - confidence (整数)你的推荐置信度范围0-100。 - reasoning (字符串)简要说明推荐理由特别是如何满足“当天往返”和“有山有水”。 - alternative (字符串)如果首要推荐有轻微不符如山水匹配度稍差提供一个备选方案。 现在请开始分析并输出JSON。改进点角色更具体“北京本地旅游专家”比“旅游助手”更能提供可信建议。需求结构化用列表拆解用户需求避免模型遗漏。信息格式化景点信息用统一格式名称 | 标签 | 交通 | 时间便于模型解析。任务步骤化明确告诉模型分析的重点顺序先卡“当天往返”这个硬条件。输出结构化强制JSON格式并设计了有意义的字段如confidence,alternative方便下游应用使用。4.3 调试与优化即使第二版已经很详细实际运行可能还会出问题。以下是常见的调试方向问题模型忽略了“当天往返”。调试在指令中加重语气。例如“首要且必须考虑的条件是‘当天往返’。任何单程交通时间超过2小时的景点都应排除。”技巧把硬性约束放在任务描述的最前面并使用加粗等标记在API中可以用文字强调。问题输出JSON格式偶尔错误。调试提供Few-Shot示例。给一个完美的输入输出对展示你想要的JSON长什么样。技巧在指令中直接写明JSON Schema甚至可以用json ...包裹一个示例结构。问题推荐理由过于笼统。调试在reasoning字段的要求里更细化。例如“理由中必须包含对‘山’元素和‘水’元素的具体指认如香山公园的‘山’指香山颐和园的‘水’指昆明湖。”技巧要求模型“引用”输入文本中的关键词这能强制它建立更清晰的关联。经过几轮调试你会得到一个针对“近郊山水当日游”这类需求非常稳定的Prompt。这个模式可以复用到其他旅游推理场景。5. 实战演练二人岗匹配逻辑推理Prompt构建这个任务更复杂涉及对长文本的理解、信息提取和逻辑对比。我们的目标是输入一段简历和一段职位描述输出结构化的匹配分析。5.1 挑战与应对策略文本过长简历和JD可能很长超出模型上下文窗口。策略先做预处理。用另一个简短的Prompt让模型或传统方法提取“核心技能摘要”例如“用3-5个关键词概括这份JD的核心要求”。然后将摘要而非全文送入主匹配Prompt。标准主观“沟通能力强”如何衡量策略在Prompt中定义可观测的“证据”。例如“‘沟通能力强’的证明可能包括描述过跨部门协作项目、有客户汇报经验、有文档撰写作品等。”输出不一致有时匹配度高有时低。策略标准化分析流程即思维链CoT和输出格式。强制模型按步骤思考并将每一步思考结果填入固定字段。5.2 构建分阶段Prompt流程对于生产环境我建议拆成两个阶段这比一个巨型Prompt更可靠。阶段一信息提取与标准化你是一个专业的简历分析师。请从以下职位描述JD中提取出最核心的5-8项硬性技能要求和3项软性素质要求。 【职位描述】 {JD全文} 【输出格式】 请严格按照以下JSON格式输出 { “hard_skills”: [“技能1” “技能2” ...], // 例如Python, SQL, AWS “soft_skills”: [“素质1” “素质2” ...] // 例如团队协作解决问题能力沟通能力 } 注意硬性技能应是具体、可验证的技术或工具软性素质应是行为或能力描述。同样对简历也可以做一个类似的提取Prompt获取候选人的“技能清单”。阶段二结构化匹配分析你是一个资深的人力资源顾问正在进行人岗匹配度评估。 【核心技能要求】来自JD分析 硬技能{hard_skills_list} 软素质{soft_skills_list} 【候选人技能证据】来自简历分析 {简历中提取的技能和项目经验摘要} 【你的分析任务】 1. 对于每一项【硬技能】在【候选人技能证据】中寻找直接或间接的证据。给出匹配判断是/否和一句证据引用。 2. 对于每一项【软素质】基于【候选人技能证据】中的项目经历描述评估其具备的可能性高/中/低并说明推理依据。 3. 综合以上分析给出一个初步的匹配度评级强烈推荐/推荐/可考虑/不匹配。 【最终输出】 请输出一个JSON对象包含以下部分 { “hard_skill_match”: [ {“skill”: “Python”, “match”: true, “evidence”: “简历中提到‘使用Python开发了XX系统’...”}, ... ], “soft_skill_assessment”: [ {“skill”: “团队协作”, “level”: “高”, “reasoning”: “简历中描述了三个跨部门项目并担任了协调角色...”}, ... ], “overall_recommendation”: “推荐”, “summary”: “候选人硬技能匹配度较高尤其在Python和数据分析方面有直接经验。软素质方面团队协作表现突出。主要差距在于缺少AWS实战经验。” }5.3 调试与边界处理问题模型对“证据”的认定过于宽松或严格。调试在Few-Shot示例中明确展示什么是“强证据”什么是“弱证据”或“无关信息”。例如对于“Python”技能“精通Python”是弱证据“使用Python Pandas库完成了销售数据清洗与可视化项目”是强证据。问题当技能不完全匹配时如JD要“TensorFlow”简历只有“PyTorch”。调试在系统提示或指令中加入领域知识“在深度学习框架领域TensorFlow和PyTorch经验具有一定的可迁移性。在评估时若候选人具备PyTorch经验可视为部分匹配并在总结中注明。”问题输出字段缺失或混乱。调试这是Few-Shot示例最能发挥作用的地方。提供一个覆盖所有字段、且处理了边缘情况如某项技能完全无证据的完整示例。6. 通用优化技巧与高级策略当你有了一个能工作的基础Prompt后这些技巧可以帮你进一步提升效果和稳定性。6.1 温度Temperature与核采样Top-p这两个参数控制输出的随机性。Temperature温度值越高如0.8-1.0输出越随机、有创意值越低如0-0.3输出越确定、保守。应用对于推理、匹配、信息提取这类需要确定答案的任务建议使用低温度0.1-0.3。对于创意写作、头脑风暴可以使用高温度。Top-p核采样与温度类似但方式不同。它从概率累积超过p的候选词中采样。通常设置0.9-1.0。建议对于生产环境我通常固定temperature0.2 top_p0.95在确定性和少量灵活性之间取得平衡。不要同时大幅调整温度和Top-p先调一个。6.2 后处理与验证不要完全信任模型的原始输出尤其是用于生产流水线时。格式验证用代码解析JSON/XML如果解析失败触发重试或降级处理。关键字段缺失检查检查输出中是否包含所有必需的字段。逻辑一致性检查例如在旅游推荐中如果confidence低于50但recommendation却是一个具体景点这可能不合理需要人工复核或重试。设置重试机制当模型输出明显不符合指令如拒绝回答、格式错误时自动用相同的Prompt重试1-2次。很多临时错误可以通过重试解决。6.3 处理模型的长文本限制当输入上下文很长时模型可能无法处理全部信息即遇到“context overflow”错误。策略1摘要与提炼如前所述先用一个Prompt对长文档进行摘要将摘要送入主Prompt。策略2分块与聚合将长文档分成有重叠的块分别用Prompt处理每个块如提取该块的技能最后再用一个Prompt聚合所有结果。策略3使用支持更长上下文的模型关注模型更新选择上下文窗口更大的型号。6.4 持续迭代与评估Prompt工程不是一劳永逸的。建立测试集收集几十到上百个典型的输入用例以及你期望的“标准输出”。批量测试定期用你的Prompt跑一遍测试集评估输出质量。评估指标不仅仅是“对错”可以包括格式正确率、关键信息提取准确率、推理逻辑合理性等。A/B测试如果你有两个版本的Prompt可以用线上流量的一小部分进行A/B测试看哪个版本的实际效果如推荐点击率、匹配满意度更好。7. 常见“坑”与排查清单最后分享一些我踩过的坑和通用的排查思路。当你的Prompt效果不佳时可以按这个顺序检查。1. 输出完全跑偏答非所问先检查你的指令真的清晰吗有没有歧义让一个没看过需求的同事读一下你的Prompt看他是否能理解要做什么。再检查系统提示System Message是否和用户指令冲突比如系统说“你是个诗人”用户让“分析财务报表”模型就会精神分裂。最后检查输入数据格式对吗有没有不该出现的特殊字符或乱码破坏了结构2. 输出格式不稳定时好时坏先检查是否提供了高质量的Few-Shot示例一个完美的例子胜过千言万语。再检查是否明确要求了格式如“输出JSON”并给出了字段定义试试在指令中直接写一个空的JSON Schema。最后检查Temperature参数是否设得太高了对于格式要求严格的任务把它调低。3. 模型忽略了部分指令先检查指令是否太长、太复杂把最重要的指令如输出格式、硬性约束放在最前面或最后面并用强调。再检查是否使用了清晰的分隔符如##、“”、---来区分指令、输入和示例一团浆糊的文本模型很难解析。技巧把复杂的指令拆分成多个简单的指令通过多轮对话Chain来完成。比如第一轮让模型提取信息第二轮让模型基于提取的信息做分析。4. 处理长文本时效果下降先检查是否超出了模型的上下文窗口计算一下Token数。再检查关键信息是否被埋没在长文本中间模型对开头和结尾的信息更敏感。尝试把最重要的输入如用户问题、核心指令放在上下文的最开始或最末尾。最后手段必须使用长上下文时考虑使用“Map-Reduce”模式分块处理再汇总。5. 感觉模型“变笨了”或效果波动首先确认你的输入Prompt和模型版本是否完全没变云服务的模型版本可能静默更新。其次这可能是大模型固有的随机性。建立评估体系关注平均效果而不是单次输出。最后网络、API临时负载都可能导致响应质量波动。实现重试和降级逻辑是生产系统的必备。写Prompt更像是在做产品设计或交互设计而不是在编程。你需要精确地定义问题清晰地传达意图并设计好容错和验证机制。从“旅游景点推理”和“人岗匹配”这两个实战场景出发掌握“角色-指令-示例-约束”这个核心框架再结合持续的测试和迭代你就能让大模型从“一个聪明的聊天伙伴”变成“一个可靠的生产力工具”。记住最好的Prompt往往是迭代出来的而不是一次写成的。