跟很多刚开始接触大模型开发的程序员一样我一开始也觉得“提示词”不就是把话说清楚吗直到自己上手做项目才被现实狠狠教育了一通同一个问题换个说法结果可能天壤之别明明看着逻辑没毛病模型偏偏输出一堆格式乱七八糟的东西更头疼的是多聊几轮之后它把最开始的要求全忘了。后来我慢慢意识到想在这个领域真正入门不是会“聊天”就行而是要把三件事分开看提示词、提示词工程、上下文工程。它们不是一个概念的三种叫法而是三个不同层次的问题。这篇内容就是给刚踏上大模型开发这条路的程序员准备的我会把这三个概念拆开揉碎讲清楚它们各自解决什么问题、怎么上手、有哪些坑最后附上一个从零到一的完整案例和排查经验希望能帮你少走点弯路。1. 先搞清楚这三兄弟到底在解决什么问题很多教程一上来就教“万能模板”“十大技巧”但很少有人先讲清楚提示词、提示词工程、上下文工程这三件事的边界到底在哪。不把这个问题想明白你学再多技巧也只会套壳遇到新的场景照样两眼一抹黑。1.1 提示词你和大模型之间的对话协议先说最基础的东西。提示词就是你发给模型的那一段输入它可以是一句话、一段描述、一整个结构化文本。它本质上是你和大模型之间的一份“对话协议”——你想让模型干什么以什么身份干按什么格式输出全写在里面。我用一个生活类比来帮你建立直观认识假设你找一名外包写手帮你写产品文案。第一种问法“帮我写个文案。”对方大概率会给你一段泛泛而谈的漂亮话但不一定符合你的产品调性、投放渠道和用户群体。第二种问法“你是资深消费电子文案策划请帮我为一款入门级降噪耳机写一篇小红书种草笔记目标用户是通勤上班族要求突出佩戴舒适和降噪效果语气轻松口语化结尾带一个行动引导全文150字以内。”后者写出了你想要的概率就高得多。原因不是“问得长”就好而是你提供了足够的约束条件把对方的工作范围框住了。大模型也是一样它对着海量文本训练出来你要从它身上稳定拿到想要的结果就必须把需求描述得足够具体、边界足够清晰。这就是提示词最基础的价值。对于小白程序员来说第一步要养成的习惯是永远不要用“帮我写一个函数”这类模糊指令去调用模型。把角色、任务、输入、输出格式、约束条件都写清楚输出质量立刻上一个台阶。1.2 提示词工程从“能说”到“会说”的修炼提示词人人都会写可为什么有人能让模型稳定输出有人却三天两头翻车区别就在于后者把提示词当成“一次性提问”前者把提示词当成“可迭代的工程产物”。提示词工程简单说就是一套系统化的方法用来构造、优化和评估提示词让模型输出更稳定、更可控。它关心的问题包括角色设定怎么写才有效指令放在哪个位置示例给几个最合适格式约束怎么表达温度参数怎么配合等等。注意这里的用词工程。这意味着它不再是碰运气的语言游戏而是有套路、有评估、有迭代的方法体系。比如我给你同一个任务让模型从一段客服对话中提取用户诉求写法A“提取用户诉求。”输出很随意格式看心情写法B“你是客服质检系统的信息抽取模块。请从对话中找出用户的核心诉求并输出为JSON包含request诉求描述不超过20字和emotion用户情绪平和/不满/愤怒两个字段。只输出JSON对象不要解释。示例对话‘你们这个App怎么一直闪退啊重启也没用’ 输出{“request”: “App频繁闪退”, “emotion”: “不满”}”两种写法在相同参数下输出的可用度差距巨大。为什么因为写法B给了模型一个明确的“锚”身份背景、任务边界、输出结构、参考样例。提示词工程就是把这种“锚”变成一套可复用的方法论而不是每次都在运气边缘试探。1.3 上下文工程不止于提问更是“记忆管理”如果说提示词是单次对话的“问法”那上下文工程管的就是“模型眼前能看到的所有信息”。大多数新人最容易忽略的就是这一点。大模型本身没有任何记忆。你每次调用它它都是“全新”地面对你。之所以很多聊天产品看起来有记忆是因为程序端把之前的对话记录重新拼进了请求里一起发给了模型。所以模型能看到多少“历史”完全取决于你怎么管理这个上下文窗口。上下文工程就是系统性地设计、管理和优化送入模型的上下文内容该放哪些历史消息、哪些外部资料、哪些用户状态以及如何截断、摘要、检索才能在有限的token预算内让模型获得最充分、最相关的信息。我举个容易理解的类比想象你请了一位顶级专家来解决问题但他面前只有一张小桌子桌上一次只能摆几份资料。你当然希望把最关键的几页塞到他手边而不是把整面墙的文件全堆上去。上下文工程就是研究“桌面怎么整理”的学问。很多“程序员的第一个AI项目”一开始都很简单单轮调用就完了。但一旦做成对话机器人、智能客服、分析助手这类多轮产品上下文管理就成了决定体验上限的核心环节。可以说提示词工程解决的是“每个问题怎么问”上下文工程解决的是“在更大的时间跨度和信息范围内怎么让模型始终掌握必要的背景”。1.4 三者的关系与边界聊到这里三者的边界其实已经比较清晰了我用表格帮你做个快速对照概念关注粒度核心问题典型手段提示词单条消息让模型理解这一次的要求角色设定、任务描述、输入数据、格式约束提示词工程单轮或单任务让输出更稳定、更可控结构化模板、少样本示例、思维链、采样参数调节上下文工程多轮对话、多文档、跨任务在token预算内组织最相关的信息环境历史截断、语义摘要、外部知识检索、动态组装三者的关系可以这样理解提示词是地基提示词工程是地基上的建筑规范而上下文工程是在更大的园区里做整体规划。你不先把提示词写明白后面两层无从谈起但如果你只会雕琢单条提示词不理解上下文怎么组织做一个真实产品照样会焦头烂额。2. 提示词的核心细节与实操要点我见过不少新人一上来就追求“高级模板”结果连一个提示词的基本结构都说不清。这一节我们先把提示词本身解剖开看看一个可靠、稳定的提示词内部到底由什么组成每一部分该怎么写。2.1 一个提示词的内部结构拆解一个成熟的提示词通常不是一段话而是由多个功能块组成的结构化文本。我自己在项目里常用的模板骨架是下面这样的你是一名{角色}。 任务{一句话说清楚要做什么}。 输入内容 {这里放用户输入或待处理数据} 输出要求 1. {格式要求比如“只输出JSON对象”} 2. {字段定义比如“包含xxx和xxx字段”} 3. {长度或语气约束} 参考示例 输入{示例输入} 输出{与格式要求完全一致的示例输出} 额外说明 {兜底规则、边界情况的处理方式}这个模板的核心思路是“把话分块说”而不是揉成一团。你可以把它想象成给模型画了一张表格你是谁、做什么、输入什么、输出什么样、有没有样例、边界情况怎么办。每一块信息各司其职模型更容易“按图索骥”。在实际项目里我会把这种模板写成一个模板字符串用变量填充动态内容而不是每次手敲。这样既方便维护也方便做版本管理。2.2 角色、指令、示例、格式约束怎么写才有效先说角色设定。给模型一个身份本质上是在告诉它“请从某个知识分布里取用合适的行为模式”。你写“你是资深客服”模型输出的语气和内容组织方式就会自动向“专业客服回答”靠拢。对于小白我建议每个角色设定都尽量具体不要只写“你是助手”最好写“你是XX系统的智能客服擅长处理订单咨询和售后问题”。再说任务指令。指令要用动词开头不要用“我想”“能不能”这类含糊表述。正确例子“请从以下文本中提取日期、金额、订单号。”错误例子“能不能帮我看看这里面有什么重要信息。”动词开头的好处是强制任务边界清晰模型不会猜“你到底想要什么”。然后是示例。这是很多人偷懒省略的部分但它的重要性不亚于角色设定本身。大模型是跟着模式学习的你给一个示例它就能自动模仿这种输入到输出的映射关系。我给几条实操经验示例数量控制在2到3个太少了不足以保证格式稳定太多了浪费token示例的输入要覆盖正常情况和边界情况最关键的一条示例输出的格式必须跟你要求输出的格式保持完全一致否则模型会照着你的错误样例学坏。最后是格式约束。如果你需要结构化输出就必须明确指定格式。常见做法是要求“只输出JSON对象不要任何解释”或者“输出为Markdown表格”。还有一个容易踩的坑模型有时候会好心地在JSON外面套一个代码块你必须在提示词里补一句“不要使用代码块包裹”否则解析阶段还得专门清理。2.3 小白最容易忽略的提示词“隐性规则”这几条隐性规则是我在日常排查别人提示词问题时发现的高频盲区。第一模型不是人。它不是一个“懂你”的对话者而是一个按概率预测下一个词的机器。你给的信息越含糊它的回答就越“平均”什么场景都能套但什么场景都不精准。所以每次写提示词前先问自己如果这句话发给一个新同事他能只看这句话就把活干对吗第二指令位置有讲究。模型对一段文本开头的注意力通常强于中间所以最重要的任务指令尽量放在开头一些兜底提醒或关键约束可以放在最后再强调一次。比如“最后请再次检查你的输出是否包含三个字段”这种收尾式提醒对格式稳定性有实际帮助。第三尽量用肯定句少用“不要”。如果你写“不要解释原因”模型很可能反而给出大段解释因为“解释”这个概念被激活了。更稳的写法是正面引导“只输出JSON对象不包含任何其他文本。”实在要表达否定语义就把它转化成对输出形态的正面约束。第四不要滥用“请一步步思考”。思维链确实能提升复杂任务准确率但对于“提取某个字段”这种简单任务强制拆步骤只会增加延迟和token消耗还可能引入额外错误。先判断任务难度再决定是否启用。3. 提示词工程常用套路与参数选择搞清楚了提示词怎么写接下来这层更进阶怎么让不同任务都稳定跑通。这一节分享几个我用下来性价比最高的套路以及采样参数到底怎么配合。3.1 少样本示例的价值远超你想象少样本Few-shot是提示词工程里投入产出比最高的技巧之一。它指的不是给模型喂大量训练数据而是在提示词里直接附上几个完整的“输入→输出”示例让模型现场模仿。为什么有效因为大模型在训练时已经看过无数“范例模式”你给的示例相当于帮它定位到正确的模式分支。比如做分类任务你可以这样写请将用户反馈分类为功能问题、性能问题、体验问题、其他。 只输出类别名称不要解释。 反馈App首页总是加载不出来 分类性能问题 反馈我想把订单地址改成公司地址找不到修改入口 分类功能问题 反馈你们这个界面配色真好看 分类体验问题 反馈{这里放线上真实输入} 分类注意最后一行我留了一个空待填位置这样模型只需要顺着模式补全。在实际调用中你把“{这里放线上真实输入}”替换成真实内容即可。这个套路的优势是零训练成本改起来也容易适合快速验证某个任务的可行性。少样本示例给几个合适我的经验是2到3个。给一个太少模型可能抓不住特征给五六个以上边际收益急剧下降而token占用却线性上涨不划算。示例的选择要有代表性最好覆盖不同子类别或边界情况这样模型才能准确理解分类边界。3.2 思维链复杂推理任务的稳定器如果你遇到的任务涉及多步推理比如数学计算、逻辑判断、规划拆解单纯让模型“直接答”很容易出错。这时候可以使用思维链Chain-of-Thought套路核心思路是引导模型先把推理过程铺开再给结论。一个最简单的写法请回答以下问题先逐步推导再给出最终答案。 问题小明有5个苹果吃了2个又买了4个现在一共有几个 推导过程让模型先输出“初始5个吃掉2个后剩3个再买4个变成7个”通常比直接让它答“7”更稳定。原因在于模型生成答案时是逐词预测的如果中间推理步骤被显式生成它就多了“自我校准”的机会如果直接跳到结论容易在长链条推理中丢失信息。进阶一点的用法是思维树让模型先列出几种解题方案或分支再选最优路径执行。它比思维链更稳但也更贵。对小白的建议是先用思维链输出格式控制好等遇到“单一方向推导也救不回来”的复杂任务再考虑更复杂的方案。这里必须提醒一句思维链不是免费的。它会让输出token明显变多延迟和成本都会上升。所以请只在任务确实需要多步推理时使用简单的关键词提取、分类任务没必要杀鸡用牛刀。3.3 温度、Top-p这些参数到底怎么调除了提示词内容本身采样参数对输出质量的影响也非常直接。很多新人从头到尾用默认参数结果同一个提示词有时输出A有时输出B完全摸不着头脑。理解几个关键参数你就能把“随机性”控制在自己手里。任务类型温度建议Top-p建议原因分类、抽取、格式化输出0.0 - 0.30.8 - 0.9需要高确定性低随机性避免字段漂移代码生成0.2 - 0.50.8 - 0.95需要一定灵活性但语法和逻辑要稳文案创作、头脑风暴0.7 - 1.00.9 - 1.0需要更多样性但太高容易跑题翻译、改写0.3 - 0.60.9既要忠实原意又要自然流畅温度temperature控制的是下一个词的概率分布平滑度温度越低越倾向于选最高概率的词输出越保守温度越高概率分布越平坦越容易选出“不那么常见”的词输出越发散。Top-p是另一种采样方式它从累积概率达到p的最小词集合里采样p越小可选词越少输出越稳。我的习惯是优先调温度Top-p保持默认或只在温度调不动时再动。需要特别注意的是模型接口不同两者的有效范围可能有差异需要先看文档确认。还有一个小经验如果你希望输出可以复现可以尝试固定随机种子某些接口支持但这不是通用能力最终还是要靠“低温度强约束”的组合来保障稳定性。3.4 提示词模板管理与版本迭代当你的项目有几十个场景每个场景都有专属提示词时把它们散落在代码字符串里绝对是一场灾难。我强烈建议像管理代码一样管理提示词。一个简单的做法是抽一个模板管理类from string import Template class PromptTemplate: def __init__(self, name, template_str, version1.0): self.name name self.template Template(template_str) self.version version def render(self, **kwargs): return self.template.substitute(kwargs) # 用法示例 tpl PromptTemplate( namesupport_ticket_classify, template_str 你是客服工单分类专家。 任务将用户反馈分为功能问题/性能问题/体验问题/其他。 用户反馈${user_feedback} 只输出类别名称。 , version2.1 ) prompt tpl.render(user_feedbackApp闪退无法打开)这样做的直接好处有三点第一所有提示词有唯一名字和版本号日志里可以带上版本出了问题能快速定位是“哪一版提示词导致”第二修改提示词不用动业务代码改模板和版本号即可第三方便做回归测试后面会详细讲。很多团队早期没有这个习惯临时改一个小需求就复制粘贴一段提示词等线上出问题连排查都不知道从哪儿下手。把提示词当作一等代码资产来管理看似麻烦长期回报非常可观。4. 上下文工程真正的实战进阶如果说前两章还能靠“小心写提示词”混过去那一旦产品有了多轮对话、动态知识接入你就不得不面对上下文工程。4.1 上下文窗口与Token预算先算清楚账大模型有一个上下文窗口意思是它一次最多能“看到”多少token。Token可以粗略理解为“词元”一个中文汉字大约占1到2个token一个英文单词大约占1到2个token标点和空格也会占。不同模型的窗口大小不同有8K、32K、128K甚至更大的但窗口大不等于你可以敞开来用。原因有三个第一输入的每个token都要花钱越长越贵第二处理越长输入延迟越高第三研究表明模型对长上下文中间部分的注意力会衰减塞太多无关信息反而降低回答质量。所以我建议你养成做预算的习惯。一个简单公式安全Token预算 上下文窗口 × 0.7 可用Token 安全预算 - 系统指令 - 固定示例 - 当前输入剩下的空间一部分留给历史消息一部分留给你期望模型输出的token数。举个例子你用的是8K窗口的模型系统指令占500固定示例占800当前用户输入占1000那么安全预算是5600剩下的可用空间就是3300左右。如果这时候你一股脑塞入7000字的聊天记录先不说会不会超出窗口即使不超模型也未必能抓住重点。在设计请求时先把“必须存在”的信息列出来再把“可有可无”的信息砍掉。记忆不是越多越好而是越精越好。4.2 上下文构建三大策略截断、摘要、检索真实产品里对话历史和新内容往往远超上下文窗口这时候就需要用策略来管理。我每天都在用三个基础策略。第一是截断。最简单粗暴保留最近N轮对话更早的直接丢弃。好处是稳定、省token坏处是如果用户早前提过一个关键要求比如“所有回答控制在50字内”截断之后模型就把这个要求忘了。所以截断只适合短会话或对历史信息不敏感的场景。第二是摘要。把较早的对话定期用模型总结成一段要点再把摘要塞回上下文。比如聊了20轮你可以每5轮总结一次“用户已经确认了收货地址正在纠结配送时间语气由不满转为平缓。”这样关键信息用少量token保留比存20轮原始对话划算得多。代价是摘要本身会引入一次额外的模型调用而且摘要质量不好时信息会失真。第三是检索。这也是目前最热门的方向之一核心思路是不把所有知识塞进上下文而是根据当前问题从外部知识库中找出最相关的内容片段拼到提示词里再问模型。比如一个售后知识库有几万字但你只把与“退换货政策”相关的几百个字检索出来喂给模型既省钱又精准。这三种策略不是互斥的实际项目里经常组合使用先对旧历史做摘要再对最近几轮做截断保留最后把检索到的文档片段注入当前请求。骨架代码大概长这样messages [ {system: 系统指令 用户长期偏好}, {assistant/user: 最近N轮对话}, {system: 早期对话摘要}, {user: 当前问题 检索到的相关文档片段} ]顺序有讲究系统指令在最前帮助模型建立全局基调最近对话紧跟其后因为这是最直接的上下文历史摘要放在中间作为背景补充当前问题放最后让模型以最新的输入作为响应依据。这个组装顺序不是唯一标准但它来自我多次调试后的经验。4.3 对话状态管理与多轮交互设计多轮对话最容易出问题的地方是模型“记不住”用户在某一轮里确认过的重要信息。你可以把关键业务状态抽出来单独管理而不是指望模型从庞杂历史里自己找。我举一个实际的例子。假设你在做一个订餐助手用户可能中途改地址、换菜品、问配送时间。你可以在程序端维护一个状态字典state { user_intent: place_order, address: 未确认, cart: [牛肉面, 酸梅汤], delivery_time_preference: 尽快, confirmed: False }每次组装请求时把当前状态的核心字段拼进系统消息或对话前部让模型每轮都能看到“最新事实”而不必从头翻聊天记录。状态更新也由程序端控制比如用户改地址你自己更新字典而不是靠模型去理解。这么做的优势是显而易见的模型不需要从2000字历史里推理“今天的地址到底改成什么了”你直接把“当前地址xx路xx号”喂给它它出错的概率自然大幅下降。对话状态管理本质上是把模型从“记忆负担”里解放出来让它专注于语言理解和生成。4.4 上下文工程落地的代码视角聊了这么多理论给一个最小可实现的代码视角帮助你把“检索组装上下文”跑通。假设你已经有一个知识库里面存放了一堆产品文档每条都被切成了片段并且已经做过文本向量化也就是把每段文字变成一组数字坐标。def retrieve(query, knowledge_base, top_k3): # 把query也做同样方式的向量化 query_vec embed_text(query) scored [] for item in knowledge_base: score cosine_similarity(query_vec, item[embedding]) scored.append((score, item[text])) scored.sort(reverseTrue) return [item for _, item in scored[:top_k]] def build_context(user_query, history, knowledge_base): # 1. 检索最相关的文档片段 retrieved retrieve(user_query, knowledge_base) # 2. 组装系统指令 历史摘要 检索片段 当前问题 system 你是产品助手基于提供资料回答问题不要编造未知信息。 history_text summarize_history(history) # 伪代码 context f{system}\n\n历史要点{history_text}\n\n相关资料\n for doc in retrieved: context f- {doc}\n context f\n用户问题{user_query} return context # 最终调用 prompt build_context(user_query, history, knowledge_base) reply call_llm(prompt)这里的embed_text、call_llm都是抽象接口你可以用自己手上任意模型的能力去实现。关键在于体会这种分步流程检索不是“用关键词匹配”而是用语义相似度组装不是“机械拼接”而是有层次的布局。很多“放大模型能力”的酷炫功能底层其实就是这种朴素的上下文工程逻辑相关信息检索出来、重要信息放进去、无关信息挡在外面。先把这个闭环跑通你就能进入大模型应用开发的实战轨道了。5. 从入门到实战一个完整的可复现案例前面的内容偏原理和方法这一节我用一个具体案例把流程串起来。假设你是一个刚转到大模型方向的开发同学领导丢给你一个任务写一个客服工单分类助手输入用户反馈输出三个字段——分类、紧急程度、建议回复。整个过程可以分三个版本迭代。5.1 场景定义与需求拆解客服工单分类助手的需求通常包含这么几块输入一段用户反馈文本比如“我昨天下的订单到现在还没发货在线客服也不回我”。输出分类物流投诉/质量投诉/功能问题/其他、紧急程度高/中/低、建议回复一段话。附加要求输出必须是结构化的方便程序直接解析并写入工单系统。第一眼看去无非就是“写个提示词然后调用模型”。但真正动手会发现问题出在“结构化输出不总是结构化”“分类边界不清晰”“建议回复有时太长或语气不对”这三点上。我们分版本来攻克。5.2 第一版提示词能跑通再说第一版我通常先求“能跑通”不追求完美。一个最简单的写法你是一个客服助手。请对下面的用户反馈进行分类、判断紧急程度并给出建议回复。 用户反馈{user_feedback}结果你也猜到了模型能回答但形式完全是“自由的”。它可能输出一大段话把“分类”和“建议回复”混在一起甚至自己加一些温馨提示。程序端要解析出固定字段还得写一堆正则去碰运气。第一版的价值是验证了“模型确实能理解这个任务”但距离可用差得很远。5.3 第二版优化结构化与示例注入第二版把我们在第2节和第3节学到的套路全用上加角色、加输出约束、加少样本示例。你是客服工单分类专家负责处理用户反馈的分类、紧急度判断与回复建议。 用户反馈{user_feedback} 输出要求 1. 只输出一个JSON对象不要其他文字不要代码块。 2. JSON字段 - category: 物流投诉 | 质量投诉 | 功能问题 | 其他 - priority: 高 | 中 | 低 - reply: 给用户的回复不超过50字语气耐心专业 示例 用户反馈我收到的手机屏幕有划痕想换一台。 输出{category: 质量投诉, priority: 中, reply: 您好非常抱歉商品给您带来了不好的体验我们会尽快为您安排换货请保持联系方式畅通。} 用户反馈App更新之后一直闪退重装也没用。 输出{category: 功能问题, priority: 高, reply: 您好该问题我们技术团队正在紧急处理中建议您先尝试清理缓存我们稍后给您反馈修复进展。}这一版的格式通过率会明显提升大部分请求都能输出合法JSON字段值也基本符合预期。示例的作用在这里体现得淋漓尽致尤其是“reply要专业耐心”这个抽象要求光用文字说模型有时候把握不好尺度给一个示例它立刻知道“大约是这个风格”。5.4 第三版进阶引入上下文检索第二版解决了“格式”和“风格”但会出现另一个问题当用户反馈涉及某条具体售后政策时模型可能按自己理解瞎编。比如用户问“七天无理由退货运费谁承担”模型没有你公司的政策只能给一个“可能合理其实不一定”的答案。第三版的思路是把公司政策文档做成知识库在每次请求前先检索相关片段再拼进上下文。示意流程如下user_feedback 你们宣传说免费退换现在又让我自己出运费什么情况 # 1. 检索相关知识片段 policy_retrieved retrieve(user_feedback, policy_kb) # 2. 组装提示词 prompt f 你是客服工单分类专家请基于以下“退换货政策”回答用户。 政策内容 {policy_retrieved} 用户反馈{user_feedback} 请输出JSON包含category、priority、reply字段。 reply必须依据政策内容不能编造。 这里的关键点是模型不再依赖自己的“常识”回答而是看到了你公司的真实政策片段。于是“免费退换”和“实际运费规则”之间的矛盾它就能给出有理有据的回复而不是含糊其辞。从实现角度看第三版比第二版多做两步把政策文档做成可检索的片段库在请求前动态检索相关片段。这个模式就是大家常说的检索增强生成RAG的极简形态。它并不神秘核心思想就是“给模型配一个可以随时查阅的资料库”。5.5 效果对比与经验总结为了直观展示迭代效果我整理了一张模拟对比表版本格式通过率分类准确率回复政策依据平均输出长度第一版无约束自由输出约40%约65%无靠模型常识150字以上第二版角色约束示例约95%约85%无靠模型常识60字左右第三版加入政策检索约95%约90%有可追溯70字左右第一版自由输出导致大量格式解析问题第二版通过“角色约束示例”大幅提升了格式稳定性还顺带压缩了输出长度第三版靠上下文检索提升了回答依据的准确性尤其是涉及公司政策的问题编造率大幅下降。这个案例的价值在于它把前面所有的知识点串成了一条真实链路先确认需求再写能跑通的版本接着用提示词工程加固格式最后用上下文工程补齐知识短板。每一步的动机都很清晰你可以直接套用到自己的第一个项目上。6. 常见问题与排查技巧实录最后这部分我把自己日常调试中最常遇到的问题和排查思路整理出来。这些内容在教科书上很难看到但确实是实战中最耗时间的环节。6.1 问题速查表现象可能原因排查方向解决思路JSON格式不稳定偶尔带多余文字格式约束不够强没有示例检查提示词是否指定“只输出JSON”并给了示例加输出约束、加示例、解析时做兜底清理模型开始正常越到后面越跑题上下文过长注意力分散统计每次请求总token数截断旧历史、做摘要、精简无关内容同样的输入输出每次都不一样温度/Top-p偏高或未固定seed检查采样参数降低温度到0.2以下必要时固定seed模型总是忽略末尾要求指令位置不合理被大量文本淹没观察提示词结构把关键约束放在开头或结尾再强调一次输出虽符合格式但内容质量低角色或任务描述不够具体检查角色与指令的明确度将角色写具体任务用动词开头必要时补示例多轮对话中模型忘记早期要求截断策略过于简单丢掉了关键历史检查context组装方式引入摘要或状态管理把关键事实放在上下文中部这张表可以作为你日常开发的“体温计”模型一旦表现异常先对照表格定位可能原因再逐项验证比漫无目的地改提示词高效得多。6.2 调试提示词的通用方法论很多新人调试提示词是全靠感觉这次加一句下次删一句看到结果好了就收手结果换个数据集又翻车。更靠谱的方式是建立一套“提示词调试流水线”。第一步准备一组固定的回归用例。选20到30条有代表性的输入覆盖常见情况和边界情况放在一个列表或文件里。任何提示词的改动都要用这组用例全部跑一遍对比输出是否符合预期。这一步看起来麻烦但能帮你建立最基础的“效果感知”。第二步每次请求都记录日志。至少记录提示词版本、采样参数、模型版本、请求时间、完整输出。出问题时先翻日志看“什么时候开始变差的”再用版本对比工具找出是提示词变了还是参数变了。第三步用二分法定位。如果你改了5个地方不要一次全上先把改动拆成两组A组上、B组不上看哪组导致问题再继续缩小范围。定位到具体是某一句还是某个示例在起作用后你的下一次修改才会是有效的而不是又一次盲改。我见过很多同事花了几个小时调提示词最后的结论往往是“刚才那版其实差不多”。如果你也遇到这种情况大概率是缺了第二步的日志和第三步的二分法。调试提示词和调试代码方法论上是一模一样的。6.3 关于成本与性能的实用建议最后聊聊钱的问题这在小项目中容易被忽视等量大了就肉疼。第一输入token和输出token的价格往往不对等通常输入更便宜、输出更贵。但如果你塞入大量历史记录和知识片段输入token总量快速增长成本大头反而来自输入。上下文工程做得好不好直接影响你的账单。每加一段检索内容都先问自己这段内容真的有用吗第二长上下文不是免费的也不是越快越好。把相同的8K内容重复发送给模型既浪费钱又拖慢响应时间。可以考虑对历史对话做缓存或复用摘要而不是每次全量重发。第三模型版本升级后行为可能悄悄变化。同一套提示词在旧版和新版上的表现可能差异明显这是大模型应用开发的常态。所以你的回归用例集不仅要跑还要在版本升级前后各跑一遍。我团队里有一个固定流程任何上游模型版本变更先跑一遍全量回归用例再决定是否上线。把这三条做进习惯预算和稳定性都会好很多。大模型开发从来不只是“把提示词写好”而是在写好的基础上把成本、速度、稳定性一起管住。我个人在实际操作中的体会是提示词、提示词工程、上下文工程这三个概念看似简单却是大模型应用从“demo”走向“产品”的三级台阶。你可以在小脚本里只写一个提示词玩得很开心但一旦做真实产品每一级台阶都要踩实。尤其是上下文工程我见过太多项目死在“模型记不住”“响应太慢”“账单爆炸”这三件事上而这三件事的解法都不在提示词里在更宏观的信息组织方式里。最后再分享一个我自己的小习惯我把所有提示词都放进git仓库管理每个版本都配好对应的回归用例集。有一次某个分类功能白天还好好的晚上突然大面积抽风查来查去最后发现问题出在有人把示例里一个全角标点改成了半角。如果没有git历史这个排查会变成噩梦。希望这些经验能让你在大模型学习入门的路上走得比我当初顺一些。