最近花了两天时间把 GPT-6 Astra 的官方提示词指南从头到尾啃了一遍啃完之后我最大的感受不是我又学了几招新技巧而是我过去引以为傲的那套 prompt 写法可能有一大半都需要推翻重来。这篇文章不打算复述官方文档我想换个角度聊聊读完指南之后我是怎么重新理解提示词、重新设计 prompt 结构、以及在实际调优过程中踩到的一堆坑——包括 invalid prompt 被拦截、token 预算爆炸、上下文压缩失败这类让人血压升高的问题。如果你平时就在用大模型接口开发应用、做 agent 或者搭自动化工作流这篇文章应该能帮你省下不少试错时间。1. 读完官方指南我重新理解了 prompt 的新定位1.1 官方指南反复强调的不是怎么说而是给什么先说结论这一代模型包括我现在主力在用的 GPT-6 Astra在意图理解上已经比我预想的强太多。官方指南里你几乎找不到请使用礼貌用语一定要加角色设定这类话术建议更多是在讲上下文完整性、任务边界和输出约束。这跟我早期学 prompt 时的认知完全反过来了。举个我自己的例子。以前我写 prompt习惯开头先来一段你是一位拥有十年经验的高级数据分析师请以专业、严谨的态度……。这种写法在 GPT-3.5 时代确实有效因为那时候模型需要靠角色词来激活特定领域的知识分布。但现在同样是做数据清洗任务我发现直接把数据格式、目标字段、缺失值处理规则写清楚效果比堆十个角色头衔都好。官方指南其实就点破了这一层模型的理解能力上来了prompt 真正要解决的不是唤起身份而是交代清楚任务。我自己的理解是prompt 的本质正在从魔法咒语变成任务规格书。以前写 prompt 像对着老式收音机调频率你得反复试某个词、某种句式看能不能碰到那个触发点。现在更像是给一个能力很强的实习生布置工作他不需要你反复强调身份他需要的是目标、背景、限制条件和交付标准。这个转变听起来简单但实际操作中我见过太多人还在用旧思维堆砌话术反而把任务描述挤没了。1.2 角色设定的价值还在但优先级要让位给任务定义这不是说角色设定完全没用。在某些场景下给模型一个角色确实能稳定语气和回答风格。比如写营销文案你告诉它你是一个面向年轻消费者的文案策划出来的文案语感会明显更对味。但这种角色设定应该是为任务服务的而不是prompt的主体。我读完指南后重新梳理了自己的写法发现真正决定输出质量的其实是一下几个要素的完整度任务目标你到底要让模型做什么一句话能不能说清。背景信息模型需要知道哪些前置条件才能做出合理判断。约束条件不能做什么、边界在哪里、遇到例外怎么处理。输入数据需要处理的数据放在哪、格式是什么。输出格式返回的结构、字段、示例、长度限制。自检要求输出完后模型自己怎么判断是否符合要求。我把这六点称为prompt 六要素。以前我写 prompt 恨不得把前两点写满后四点全靠模型自己悟现在我是反过来前两点尽量精简后四点写得越细最终效果越稳。这算是读完指南后最大的一个转变。1.3 六要素框架具体长什么样这里我给出一个我最近在项目里实际使用的模板你们可以直接拿去改。这个模板并不是什么官方推荐而是我在大量实测之后沉淀出来的通用结构task 本次任务根据给定用户评论判断其情感倾向并输出结构化结果。 /task context 我们是一个电商平台售后团队评论来自近 30 天订单。投诉类型包含物流、质量、尺寸、服务四类。 /context constraints - 仅使用提供的评论内容进行判断不要推测评论之外的订单信息。 - 若评论同时包含多个情感倾向以最强烈的情绪为准。 - 禁止在输出中给出任何处理建议只做分类和情感判断。 /constraints input [评论内容] /input output_format 返回 JSON格式如下 { sentiment: positive|neutral|negative, category: logistics|quality|size|service|other, confidence: 0.0-1.0 } /output_format check 输出前请自行检查sentiment 是否严格属于枚举值category 是否能由评论内容直接支撑 /check这套模板并不是什么新鲜东西但它把我刚才说的六要素都装进去了。我实测下来同样的任务用这种段落化标签的结构比之前那种一大段描述性文字的错误率降低了至少三成。原因也很简单标签让模型更清晰地区分任务描述背景信息硬性约束和输出要求它不需要从一大段散文里去猜哪些是重点。2. 从零写一个 GPT-6 Astra 可用的 prompt实操拆解2.1 先把输出格式定义清楚再回头写任务描述很多人写 prompt 的习惯是先讲故事再提要求也就是把背景和任务写完之后在最后轻描淡写地来一句请以 JSON 格式输出。我读指南后学到的第一件事就是把这个顺序彻底反过来先定义输出格式再回头写任务描述。原因很简单。模型在生成时它会尽力按照你能想到的最具体的形式去组织回答。如果你只说了请用 JSON 输出模型对JSON的理解可能只是带花括号的对象字段名、嵌套结构、是否包含多余文字它都会自由发挥。但如果你把输出格式定义成一个完整的 JSON Schema并附上一个期望输出示例模型就会严格照着这个骨架去填内容。我举一个我实际遇到的案例。之前做一个信息抽取功能需要从合同文本里抽取出甲乙双方、金额、日期。第一版 prompt 我就是简单写了句请从合同中抽取甲方、乙方、总金额、签订日期以 JSON 返回。结果模型经常返回这样的东西{ 甲方: 北京某某科技有限公司, 乙方: 上海某贸易有限公司, 总金额: 人民币三百二十万元整, 签订日期: 2025年3月18日 }看起来没问题对吧但金额字段是中文大写带人民币日期格式也不统一后面程序解析的时候全得再做一层清洗。后来我改成在 prompt 里直接写明字段类型、格式要求和枚举约束output_format 返回 JSON严格遵循以下规则 - amount: 数字类型单位为元不包含货币符号如 3200000 - sign_date: 字符串格式为 YYYY-MM-DD - party_a, party_b: 字符串使用合同中的完整注册名称 /output_format改完之后输出直接可入库一个解析 bug 都不需要再调。这就是输出格式先行的价值。你花在定义字段上的 100 个字能帮你省掉下游至少一小时的解析代码。2.2 上下文信息要数据库化不要流水账化多轮对话和复杂任务里最让人头疼的就是上下文管理。很多人习惯把历史对话一股脑儿全部塞给模型结果 prompt 越来越长模型越来越糊涂还经常把旧信息和新信息混在一起。官方指南里有一个观点我印象很深上下文不是越多越好而是越结构化越好。什么意思呢就是说你要像设计数据库表一样去组织上下文而不是像写聊天记录一样把信息平铺开。我自己的做法是把上下文分成几类分别打上标签每次更新只跟模型同步增量变化。举个客服机器人的例子。系统提示词里我会维护这样一块区域user_profile 用户ID: 10234 会员等级: gold 近30天订单数: 3 历史投诉: 物流延迟1次已解决 /user_profile order_context 当前咨询订单: OD-20250318-021 订单状态: 已签收 签收日期: 2025-03-20 可能风险: 签收后第3天提出“未收到货” /order_context conversation_state 用户已提供签收照片问题焦点从“未收到货”转为“快递被代收点签收且本人不知情”。 /conversation_state三种信息分得很清楚静态画像、订单数据、当前对话进展。模型每次回复前只需要读取这三个区块就可以快速定位自己的任务状态不需要从头读一遍几十轮聊天记录。这种数据库化的上下文组织方式是我这次读指南后认为最值得推广的一个习惯。2.3 few-shot 示例的取舍少而准别堆量few-shot在 prompt 里给几个输入输出示例是提示词工程的老传统了。但读完指南再结合我自己的实测我现在的看法是示例的数量不是越多越好在 GPT-6 Astra 这一代模型上3 到 5 个高质量示例的效果往往比 20 个混乱示例更好。为什么因为这一代模型已经有了很强的模式识别能力它不需要靠大量重复示例来学会任务反而会从过多的示例中归纳出你可能并不想要的特征比如示例的措辞习惯、示例里偶然出现的字段顺序、甚至示例中隐含的情感倾向。我自己在做一个评论分类任务时亲测过两个版本。版本 A 给了 20 条历史标注数据版本 B 只给了 5 条但都是精心挑选的边界案例比如同时包含好评和差评的评论、表情包评论、超短评论文本。结果版本 B 在测试集上的准确率反而高出两个点而且输出更稳定。另外我强烈建议在示例里加入负面示例就是明确告诉模型不要输出什么。很多人只给正面示例模型很容易出现过拟合。比如examples 输入: 质量太差了穿一次就开线再也不买了 输出: {sentiment: negative, category: quality} 输入: 输出: {sentiment: neutral, category: other} /examples negative_examples 输入: 质量太差了这句批评语气很强但不代表商品一定属于质量类问题可能是物流包装破损导致的误解 错误输出: {sentiment: negative, category: quality} 正确输出: {sentiment: negative, category: logistics}如果评论里明确提到包装破损 /negative_examples负面示例的价值在于它能帮模型画出决策边界让模型知道哪些情况容易被误判这是堆量示例做不到的。2.4 在 prompt 里写自检和兜底逻辑这个习惯是我后来在 agent 场景里被逼出来的。你写一个普通问答 prompt模型输出有偏差顶多就是答案质量差一点但在 agent 场景模型输出一个不符合预期的结构化指令整个工作流可能就直接崩掉。所以现在我写 prompt一定会加两个区块一个是自检要求output check一个是兜底逻辑fallback。自检要求我在前面的六要素模板里已经展示过了就是让模型在最终输出前自己按照你给定的规则把结果重新审视一遍。它不仅让最终答案更稳定而且能大幅减少返回结果里的低级错误。兜底逻辑则更重要。什么意思呢你要在 prompt 里明确告诉模型如果这个任务你无法完成、或者输入数据不满足某些条件你应该输出什么而不是编造一个答案。举个例子fallback - 如果输入评论为空或字数少于2返回 {sentiment: neutral, category: other, confidence: 0.0} - 如果输入内容与任务无关例如纯广告、乱码返回 {error: invalid_input} - 禁止在 confidence 未知或无法判断时猜测数值此时 confidence 置为 0 /fallback有了这个兜底逻辑下游程序遇到模型无法处理的情况时就不会傻傻地拿一个编造结果往里走。我见过太多线上事故根源就是模型在信息不足的时候强行编了一个看起来合理的 JSON把下游系统带进沟里。兜底逻辑是这最后一层防线。3. tokens 预算与上下文管理别再被长 prompt 拖垮3.1 prompt token 和 completion token 到底怎么算聊到长 prompt就绕不开 token。很多刚入门的朋友对 token 的计算一知半解以为 prompt token 就是指提示词的字数。实际上token 是模型处理文本的最小单位。在英文里一个 token 大约对应 0.75 个单词在中文里一个汉字大概对应 1 到 2 个 token具体要看模型的分词器设计。我实测过不少模型中文场景下 1000 个汉字可能会被切成 800 到 1800 个 token 不等差异很大。所以千万不要拿字数去估算 token 消耗。你写一个 5000 字的上下文加上历史对话实际 token 数可能直接破万。而模型的上下文窗口是有限的比如 GPT-6 Astra 这一代虽然窗口已经比以前大了很多但也不是无限的而且只要输入超过一定长度每轮请求的成本和延迟都会肉眼可见地上升。这里有个经常被忽略的概念prompt token 和 completion token 是分开计费的。completion token 就是模型生成回复时消耗的 token。很多人只盯着输入侧的 token忽略了输出侧。如果你的 prompt 要求模型输出非常长的结构化内容比如整篇报告completion token 可能比 prompt token 还贵。所以写 prompt 时除了压缩输入还要控制期望输出的长度该用简短回复约束就写上。3.2 prompt is too long 的典型场景与解决思路最近我看到好几个朋友在社区吐槽一个报错prompt is too long后面还跟着一句 automatic compaction failed。我自己也在类似场景里踩过坑。这类问题的本质就是输入内容超出了模型上下文窗口的上限而自动压缩机制又没能成功把内容压缩到可用范围。我遇到的一个真实案例是拿 Claude Code 调试一个中大型项目。项目源码文件很多我图省事直接把几个核心文件全部塞进对话里结果跑了几轮之后系统开始报 prompt is too long自动压缩也失败了。我当时的第一个反应是把上下文窗口调大但后来发现问题的根源不是窗口不够大而是我把大量不该进入对话的内容塞进去了。解决思路其实就三条减少冗余系统提示词精简去掉重复指令历史对话只保留关键结论不保留中间过程。按需加载不要把整个文件塞进去用代码检索/工具先定位到函数级片段再让模型查看相关区域。手动摘要把之前的对话历史做成结构化总结而不是依赖自动压缩。我最后是靠第二种方式解决的把项目文件从 prompt 里拿掉改用工具调用让模型按需读取代码片段。prompt 长度立刻从几万 token 降到了几千自动压缩也再没触发过。这个经验放在 GPT-6 Astra 上同样适用——它的上下文窗口再大也不该成为你乱堆信息的理由。3.3 上下文压缩失败的教训与手动摘要协议自动压缩失败是个特别容易让人崩溃的情况。我总结下来常见原因有三类一是内容量远超单次压缩阈值机制无法一次处理二是上下文里存在格式损坏比如未闭合的 JSON、markdown 结构断裂压缩工具解析失败三是递归压缩时摘要本身又被拼回上下文导致二次超限。我的建议是不要过度依赖自动压缩而是自己设计一套手动摘要协议。具体来说就是在多轮任务中每隔一段时间比如每完成一个子任务就主动让模型生成一份当前进度的结构化摘要然后在下一次请求时只传摘要不传完整历史。我常用的摘要模板长这样请将当前对话总结为以下格式供下一轮使用 progress_note task_status: 进行中/已完成/阻塞 completed: 已完成的关键步骤列表 current_focus: 当前正在处理的问题 decisions: 已经确定的关键决策 blockers: 遇到的阻碍和待解决事项 next_action: 下一步计划 /progress_note这个摘要的好处是它把历史对话状态化了。后续每一轮模型只需要加载 progress_note就能把上下文接上完全不需要回溯几十轮之前的原始对话。我用这个方案以后几乎再没遇到过 automatic compaction failed。4. 无法忽略的常见报错invalid prompt 与 agent 异常中断4.1 invalid prompt: your prompt was flagged... 排查记录这个报错原文大概是这样的invalid prompt: your prompt was flagged as potentially violating our usage policy. please try again with a different prompt。我身边已经不止一个人遇到过。大部分人第一次看到它第一反应是我是不是说了什么违规内容然后开始逐字检查自己的 prompt结果发现全是正常的技术描述。我的排查经验是这个报错不一定意味着你的意图有问题更多时候是 prompt 里的某些片段恰好命中了内容策略的检测规则。我遇到过的情况包括负面示例写得太生动把攻击性内容原文贴出来了。比如为了教模型识别垃圾评论直接在 negative example 里放了完整的不文明用语。这种写法容易被规则误伤。测试数据里带了特殊字符组合比如连续的 HTML 标签、非常规 unicode、大量转义符。prompt 里包含某些极端事件的描述哪怕只是举例说明不要输出此类内容也会被拦截。解决办法也有套路。首先负面示例一律改写为类型标签描述不要原文照录。比如要教模型识别人身攻击就写包含攻击性言论的评论如辱骂、威胁而不是把辱骂的字句写出来。其次测试数据尽量脱敏去除特殊符号。再有如果报错持续用二分法分段测试把 prompt 拆成上下两段分别发起请求哪段报错就继续拆快速定位到具体片段。4.2 agent 场景agent terminated due to error 排查agent 场景的报错比普通 prompt 更让人头疼。比如我在部署一个自动化测试 agent 的时候经常能看到类似 agent terminated due to error: you can prompt the model to try... 的信息。这类问题表面上看是 agent 执行中断但根子很大程度出在 prompt 上。我遇到过的最常见情况是 prompt 里的指令自相矛盾。比如我既让 agent严格按 JSON 返回结果又在后面加了句如果遇到异常请用自然语言说明。结果模型在某一步确实遇到异常它在严格遵守 JSON和用自然语言说明之间产生了冲突输出了一个格式违规的结果下游工具解析失败agent 直接 terminated。解决办法是在 prompt 里把异常路径也写到结构化逻辑里而不是让模型临场发挥。比如exception_handling - 工具调用失败时返回 {status: error, error_code: tool_failed, details: ...} - 不要用自然语言描述错误除非 status 为 error。 /exception_handling同时给工具的输入和输出都加一层 schema 校验。agent 报错时优先看是不是工具返回的数据长这样——很多时候模型是完全按照 prompt 执行的只是它输出的内容不符合工具方的预期格式。先校验工具入参再怀疑 prompt顺序不要搞反。4.3 常见问题速查表我把这段时间积累的问题排查经验整理成了一张速查表方便你们截图保存。症状可能原因优先排查方向prompt is too long上下文超限历史对话过多压缩历史、按需加载文件、手动摘要automatic compaction failed上下文结构损坏内容量过大检查未闭合标签改用自定义摘要协议invalid prompt flagged措辞命中策略规则负面示例去原文数据脱敏二分定位agent terminated due to error指令矛盾工具返回格式不符检查异常处理逻辑给工具加 schema 校验输出 JSON 解析失败字段约束不够明确输出格式给示例 枚举值 自检要求回答越来越笨上下文过长关键信息被稀释结构化上下文只保留最近结论模型擅自编造信息缺少兜底逻辑增加 fallback禁止猜测字段这张表里的每一条我都在实际项目中至少踩过一次。尤其是擅自编造信息这条很多人以为模型在胡说八道其实是因为 prompt 里没规定不知道时怎么办。你给了兜底逻辑模型就有了合法的回答不了的出口它就不会硬编。4.4 调试 prompt 时的一个小技巧从输出到推改为输入到验最后分享一个我最近一直在用的调试思路。以前我调试 prompt习惯盯着输出看输出不对就去改 prompt 措辞。但现在我换了一种方式——我会先构造一批标准输入保证输入数据覆盖正常情况、边界情况和异常情况然后每次修改 prompt都用这批输入去跑一遍重点看输出能不能稳定满足格式约束。这个方法说起来简单但它能帮你避免一个很大的坑为了修一个边界案例把 prompt 改复杂了结果其他正常案例的输出反而退化了。有了固定测试输入集每一次修改的效果就变成了可对比的回归测试而不是凭感觉。我已经用这个方式把自己的 prompt 迭代了十多个版本每一次改动都心里有数。5. 我的 prompt 调优工作流版本管理、回归测试与模块化5.1 给 prompt 建立版本号与变更日志prompt 是可以迭代的而且在大模型升级之后效果漂移现象特别明显。同一个 prompt上周还好好的这周换了一个模型版本可能就开始输出不稳定内容。所以我现在会给每份线上 prompt 建立版本号和变更记录类似这样prompt_name: comment_classifier version: v12 base_model: gpt-6-astra change_log: - v12: 增加负面示例2条修正空评论兜底逻辑 - v11: 输出格式增加 confidence 字段要求 0-1 之间 - v10: 修复 category 枚举值遗漏 packaging 的问题这个习惯帮我解决过一个很实际的问题有一次线上效果突然下滑我翻变更记录发现前一次模型服务商更新了版本而我的 prompt 里恰好用了旧版本特有的措辞习惯更新之后就失灵了。有了版本记录我能快速回滚到上一条 prompt同时保留下次适配的方向。5.2 用黄金样例集做回归测试提到版本管理就离不开测试集。我在每个 prompt 项目里都会维护一份黄金样例数量不用多20 到 50 条足够但一定要覆盖三类正常样本、边界样本、异常样本。每次修改 prompt我都拿这份样例集跑一遍记录三个核心指标——格式通过率输出能不能被程序直接解析、关键字段覆盖率、兜底逻辑触发率。有一次我优化一个抽取类 prompt改完之后正常样本的格式通过率从 90% 提到了 98%我正高兴结果一看异常样本兜底逻辑触发率掉到 60%——模型开始强行抽取哪怕输入根本没有目标字段。如果没有回归测试这个问题可能到线上才会暴露。所以黄金样例集不是可有可无的它是 prompt 工程质量的生命线。5.3 prompt 模块化拆成四层方便复用prompt 写久了你会发现很多项目的需求是重复的。为了减少重复劳动我现在会把 prompt 拆成四个独立模块按需拼接system 层模型的基础能力设定、通用行为准则。task 层本次任务的目标、输入输出定义。data 层当前需要处理的具体数据。output 层统一的输出格式、自检规则、兜底逻辑。这样做的好处是显而易见的。换一个任务system 层和 output 层基本不用动我只需要替换 task 层和 data 层。甚至在不同项目之间system 层和 output 层也能直接复用。这不仅降低了写 prompt 的时间还让团队内部其他同学更容易理解和维护——毕竟一个小几百行的 prompt 如果要靠人肉逐行审查是非常痛苦的。5.4 别把 prompt 写成一锤子买卖要和代码一起治理最后想多说一句。很多人把 prompt 当成一次性的小技巧写完能用就再也不管了。但实际使用中prompt 是需要持续维护的。模型在更新业务在变化数据在漂移prompt 不可能一劳永逸。我现在的做法是把 prompt 当代码一样管理有版本、有测试、有评审、有上线记录。虽然听起来有点重但等你的场景真正跑起来你会发现这些成本都是值得的。我自己就被一锤子买卖坑过。之前做一个文本摘要服务prompt 写完后大半年没动过结果某天模型方更新了版本摘要风格整体变化下游用户直接投诉。那次以后我就把所有 prompt 全部纳入版本管理并且定了一个规矩每次收到模型服务商发来的更新通知第一时间用黄金样例集做一次全量回归测试而不是等用户来报。个人体会与一个小建议这篇文章写到这里其实已经把我这段时间的实践沉淀得差不多了。如果只能挑一个最有价值的改变我会说是别再追求花哨的提示词魔法把精力放到把任务和价值边界说清楚上。每次写 prompt 之前先问自己三个问题它到底要做什么它能依赖什么上下文它做不了的时候该怎么办。把这三个问题写清楚你的 prompt 大概率已经超过市面上大多数了。最后再分享一个小技巧如果你手上有一个线上正在跑的 prompt今天就可以试一次重构实验。把它按照六要素拆一遍压缩角色设定、补齐输出格式、加上兜底逻辑然后用同一批测试数据跑一遍新旧对比。我敢说你会和我一样在对比结果出来的一瞬间重新理解提示词该怎么写这个问题的答案。