022、大语言模型（LLM）API调用与提示工程入门

一、从一次深夜调试说起上周三凌晨两点我在调试一个智能客服的对话接口。原本预期模型能返回结构化的JSON结果它给我吐回来一大段散文式的回答里面还夹着几句“我觉得用户可能想问的是……”。当时我就对着屏幕苦笑——这模型太“热心”了热心得让我解析代码直接崩溃。问题就出在提示词上。我写了“请分析用户意图”却没告诉它“用JSON格式输出”。这个教训让我意识到调用大模型API和调用传统API完全是两码事。传统API是精确的机械指令而大模型更像是一个需要明确引导的聪明实习生。二、API调用别把它当普通HTTP请求很多人第一次用LLM API时容易犯一个错误把提示词随便一塞然后抱怨结果不稳定。下面这个例子是我早期踩过的坑# 错误示范过于随意的调用responseopenai.ChatCompletion.create(modelgpt-3.5-turbo,messages[{role:user,content:介绍一下杭州}])# 结果可能是一段导游词、一篇历史文章或者突然开始写诗——完全看模型当天心情问题在于缺乏上下文和约束。大模型需要明确的“对话背景”和“身份设定”。改进后的版本# 正确姿势给模型明确的角色和格式要求messages[{role:system,content:你是一个专注于技术城市的百科助手回答简洁不超过100字。},{role:user,content:请用三个关键词概括杭州的科技产业特点}]# 现在输出稳定多了而且不会突然开始背古诗关键点system消息是你的指挥棒。它决定了模型的回答风格、专业领域和输出边界。我习惯把system消息写成项目需求文档的风格越具体越好。三、提示工程不是魔法是工程规范提示工程听起来高大上其实核心就一条用人类能懂的方式告诉模型你想要什么。下面分享几个实战中总结的模板。1. 结构化输出模板template 请分析以下用户问题并严格按照JSON格式输出 用户问题{question} 输出要求 - category: 问题分类技术/产品/售后 - keywords: 提取3个核心关键词 - response: 生成简短回答50字内 JSON格式 # 注意在提示词里明确写“JSON格式”四个字有奇效模型会主动约束输出结构2. 分步思考模板Chain-of-Thoughttemplate 请按步骤思考 用户查询“如何快速学习Python” 第一步识别用户身份新手/转行/学生 第二步分析真实需求找工作/做项目/考试 第三步给出针对性建议 请用“【步骤】”开头回答 # 这个技巧能让模型把思考过程外化特别适合需要推理的场景3. 少样本学习Few-Shot模板template 请根据示例格式回答问题 示例1 问苹果的营养价值 答{fruit: 苹果, vitamins: [C, K], calories: 52} 示例2 问香蕉的产地 答{fruit: 香蕉, origin: [热带地区], calories: 89} 现在请回答 问橙子的主要功效 答 # 给一两个例子模型就能迅速get到你想要的格式和深度比写长篇大论的要求管用四、温度参数别小看这个滑块temperature参数可能是最被低估的设置。早期我总用默认值0.7直到有一次生成产品描述时同一提示词跑出“优雅奢华”“性价比之王”“小众精品”三种完全不同的人设。# 产品描述场景high_temp0.9# 创意营销文案每次都有新花样mid_temp0.3# 技术文档稳定但略有变化low_temp0.1# 法律条款几乎一字不差# 经验法则# - 创意类0.7~0.9# - 分析类0.3~0.5# - 标准化输出0.1~0.2# 重要生产环境一定要测试不同温度下的输出稳定性五、错误处理模型会“说谎”这是我用血泪换来的经验永远不要假设模型的输出是正确的。特别是涉及数字、日期、专业术语时。# 危险代码answerresponse.choices[0].message.content db.execute(fINSERT INTO table VALUES ({answer}))# 如果模型突然在回答里夹带引号或分号SQL注入就来了# 安全做法importjsonimportredefsafe_parse(response_text):# 先尝试提取JSONjson_matchre.search(r\{.*\},response_text,re.DOTALL)ifjson_match:try:returnjson.loads(json_match.group())except:pass# 非结构化文本的清洗cleanedresponse_text.strip().replace(,)# 关键设置默认值和长度限制return{content:cleaned[:500]}# 硬性截断防止数据库字段溢出模型可能会生成看似合理但完全错误的信息业内叫“幻觉”。重要数据一定要有二次校验或者让模型提供引用来源。六、个人经验包提示词要迭代开发别指望一次写对。我习惯建个prompt_version.txt文件记录每次调整和效果像写实验日志一样。系统消息放最后调先搞定用户消息的格式和内容等主体逻辑跑通了再回头精修system消息。反过来做很容易浪费时间。给模型“思考时间”复杂任务在提示词里加上“请逐步思考”“让我们一步步分析”效果立竿见影。这相当于给了模型更多的计算步骤。长度限制写在明处在提示词里明确写“不超过50字”“用一句话回答”比在代码里截断更自然。模型会自己组织语言适应长度。生产环境加降级方案当API返回异常或内容不符合预期时要有fallback逻辑。我常用的方案是缓存几个高质量模板答案关键时刻直接替换。成本意识每次调用前估算token数。长文档处理时先做摘要再提问比直接扔全文进去便宜得多。记住输入token通常比输出token便宜但两者都计费。最后说点实在的大模型API调用上手容易精通难。最大的门槛不是技术而是思维转换——从“指令式编程”切换到“引导式沟通”。刚开始你会觉得模型不听话慢慢你会发现问题往往出在自己没表达清楚。最好的学习方法是建个测试脚本固定一个任务比如商品描述生成用不同的提示词、温度参数、格式要求反复跑。跑上几十次你自然就能摸到模型的脾气。我电脑里现在还留着三个月前的对比测试记录翻看时能清晰看到自己提示工程的进化轨迹。记住模型不是魔法黑盒它是个有固定模式的聪明学生。你的提示词就是给这个学生的考卷题目。题目出得清晰答案才能漂亮。