在订单处理这个岗位上摸爬滚打久了你会发现最磨人的往往不是订单本身而是那些重复了千百遍的问答、核对和跟进。我决定把日常工作里最耗时的几个环节交给AI用一套“订单辅助系统”的提示词把它们串起来。这套提示词的核心不是让AI写代码而是让它变成一个真正懂订单流程的助手——能解析客户发来的乱糟糟的信息、识别关键字段、生成话术草稿还能在我需要复核的时候给出结构化摘要。最关键的是整套提示词经过反复调试后做到了“可复用、可复现”换一个同事、换一批订单数据只要按照约定格式输入输出的质量基本稳定。如果你也在做电商、供应链、客服或者项目管理这类离不开表格和消息往来的工作这篇文章就是为你准备的。我会把整套系统的设计思路、每一个提示词模块的写法、为什么要这样写以及在实际应用中踩过的坑全部摊开来讲。1. 为什么用提示词堆出一个订单辅助系统先说说我最初遇到的问题。每天收到大量来自不同渠道的订单信息有客户直接发来一段文字描述附带几张截图有销售在群里转发聊天记录还有从表单系统导入的原始数据。这些信息格式五花八门提炼关键信息全靠人肉阅读。每天下午光是把这些零散信息整理成标准化的订单表格就要花掉一两个小时。更麻烦的是不同业务员整理出来的字段颗粒度还不一样有人写“客户要求周五前发货”有人只写“加急”等到真正执行的时候根本对不上。1.1 订单处理的实际痛点我当时试过几个现成的订单管理软件要么太贵要么字段固定死了改个自定义属性都要找客服。也想过写脚本去解析数据但订单信息里真正的难点不是格式不统一而是“语义歧义”——同样一句话上下文不同意思完全不同。比如“这台机器要红色的外壳”和“这台机器红色外观的版本已经停产了”前者是需求后者是说明脚本根本分辨不了。于是我把目光转向了大语言模型。它的优势恰好能补上传统规则引擎的短板对自然语言的理解能力强能结合上下文判断意图还能按照指定格式输出。但大模型也不是万能的它最大的问题是“不稳定”——同样的输入换个说法可能就输出不一样了。这就是我决定做“可复用复现提示词”的根本原因我得让这套系统产出稳定到可以交给任何一个同事直接使用。1.2 常规方案和提示词方案的区别传统的思路是画流程图、写判断逻辑、配字段映射表碰到语义歧义就加正则表达式补丁补丁多了系统就变成一个谁都不敢动的“定时炸弹”。提示词方案则是把判断权交给模型我们只负责定义“规则边界”和“输出契约”。拿“客户要求周五前发货”这句话举例。传统方案里我可能要写四五条正则去匹配时间表达还得处理“周五”“下周五”“这周五”的区别。提示词方案里我只要在系统指令里写明“提取订单中的时间要求注意相对时间的转换如果无法确定具体日期就标记为待确认”模型就能按照语义去理解。当然这不意味着提示词方案可以完全替代传统方案。在字段层级的后处理、数据校验、异常检测这些环节传统规则依然有用。真正合理的架构是分工合作提示词负责理解和抽取规则代码负责校验和落库。1.3 这套提示词适合谁这套“订单辅助系统”的提示词并不只适用于电商行业。你在做售后工单分类、客户需求收集、供应链进度跟踪甚至招聘简历初筛的时候底层的逻辑是完全相通的。核心要解决的永远是同一个问题如何让大模型帮我们从一堆非结构化文本里稳定地提取出结构化信息并按照我们需要的格式输出。我建议以下类型的场景直接复用这套思路有固定的业务流程但输入文本不固定的对输出格式有明确要求、后续系统需要解析的需要多人协作维护同一套规则的。如果你们的输入输出已经完全标准化直接走API对接就好了没必要用提示词绕一圈。2. 提示词系统的总体骨架角色、任务、格式三分离在动手写第一版提示词之前我先给自己定了一条铁律提示词必须拆成三个独立的部分角色设定、任务描述、输出格式互不掺杂。这也是后来整个系统能做到可复用、可复现的基石。2.1 角色设定为什么要单独拎出来很多人写提示词喜欢这样开篇“你是一个订单处理助手帮我提取客户消息里的订单信息包括产品名称、数量、价格……”看起来没毛病实际上把角色和任务混在一起后续想复用就麻烦了。我的做法是角色设定单独放在一个system级别的位置不让它出现在每一次具体任务的提示里。角色描述只回答一个问题面对这些文本时你的立场、身份、知识边界是什么。我实际用的角色提示词效果如下你是一名资深的订单处理专员熟悉电商、供应链和售后流程。 你擅长从口语化、碎片化的客户消息中提取结构化信息识别隐含需求。 你的回答必须基于给定的输入文本不允许编造输入中不存在的信息。 遇到模糊信息时你的默认策略是主动标记为待确认而不是猜测。这段角色提示词看起来简单但每一句话都有目的。“不允许编造信息”是为了减少幻觉“默认策略是主动标记待确认”是为了让系统在模糊场景下保持行为一致。这两点直接决定了后续输出质量的稳定性。2.2 任务描述如何写得既具体又通用任务描述是整个提示词里最核心的部分。我见过太多失败的例子就是任务描述写得太窄换个场景就失灵或者写得太宽泛模型不知道你到底想要什么。我的原则是“一段任务描述只描述一种能力”。比如“从客户消息中提取订单结构化信息”是一个能力“生成订单跟进话术”是另一个能力。把它们拆开分别对应不同的prompt入口需要的时候通过调度逻辑拼接起来而不是堆在一次对话里。具体到“信息提取”这个任务我的任务描述是这样设计的请从以下客户消息中提取订单相关信息并按输出格式要求生成结果。 需要提取的字段包括 - 客户名称/联系人优先从签名、开头称呼、结尾落款中识别 - 商品名称包括型号、规格、颜色等描述性信息 - 数量注意“一箱”“一件”“一套”等量词统一折算为标准单位 - 价格及币种如果消息中出现了多个价格按照时间顺序记录全部 - 交期要求包括具体日期、相对时间如“越快越好”、未明确时间 - 特殊说明包装、物流、开票等非标需求 处理规则 1. 如果同一字段在消息中多次出现保留最后一次的描述 2. 如果字段信息缺失对应位置填充“未提及” 3. 如果消息中存在互相矛盾的信息保留全部并在“备注”中提示冲突这段描述最大的好处是它给了模型一套可执行的“处理规则”而不是让它自由发挥。第2条规则“未提及”看似多此一举实际上极为关键——它倒逼模型必须逐字段扫描而不是偷懒漏掉某些信息不填。2.3 输出格式整个系统最容易被忽视的命门输出格式写得好不好决定了后续能不能自动化处理。我第一版的时候在这里摔过一个大跟头当时让模型“用自然语言汇总订单信息”结果十次输出十种格式根本没法做后续的字段解析。后来我强制要求输出为JSON格式情况立刻好转但也没完全解决——因为模型偶尔会在JSON前后加废话偶尔会使用不规范的键名。最终我用了一个“格式契约”的方式直接在提示词里给定一个JSON模板样例并且强调必须严格匹配。这一块我会在讲可复现性的时候展开细说这里先给出一个核心思路输出格式要求 必须输出合法的JSON对象字段取值必须为字符串不要输出JSON以外的任何内容。 { 客户名称: , 联系人: , 商品: , 数量: , 价格: , 币种: , 交期要求: , 特殊需求: , 备注: }这个模板样例同时起到了“约束格式”和“提示字段”的双重作用。模型看到具体样例之后输出崩溃的概率大幅下降。这就叫“给输出一个锚点”。3. 核心模块订单解析提示词的工程化拆解骨架搭好以后我开始填充具体的功能模块。整个订单辅助系统里订单解析是使用频率最高、也最能节省时间的模块。这一节我把它的工程化过程完整拆开。3.1 信息提取的完整流程我设计的订单解析流程分三步先让模型判断消息类型再抽取关键字段最后做冲突检测。这个顺序不能乱因为判断类型会直接影响抽取策略。比如收到一条消息是“请把上次的订单再追加10件”如果模型没有先识别出这是“追加订单”而不是“新建订单”就会把“上次”当作无效信息直接忽略。但如果先明确这是追加订单模型就知道应该去对话历史里找到上次订单的编号并把“追加10件”识别为核心增量信息。我把这个流程写进了提示词的系统路由层。当用户输入一条消息后系统会先进行类型判断得到的结果作为中间变量传给信息提取模块。这个中间变量在最终输出里不需要展示但它在决策链路上至关重要在处理输入消息之前请先分析这条消息属于以下哪种类型 A. 新建订单 B. 订单修改追加、减少、变更 C. 订单查询 D. 售后咨询 E. 其他请在备注中说明内容概要 请先输出类型标记如B再执行信息提取。加上这个前置判断之后系统的准确率提升了非常明显。原因很简单大模型在输出完整答案之前如果先做一步“推理前置”这一步推理本身就会约束后面的输出方向。这比直接让模型跨步骤输出要稳得多。3.2 字段标准化与单位换算订单信息一大痛点就是单位不统一。客户说“来两箱”“拿一件样品”“按公斤报价”各有各的口径。如果原样提取到表格里采购、仓储、财务三个部门看到的数量含义完全不一样后面一定会出问题。我在提示词里专门加入了“统一单位”的规则要求模型在保留原始描述的同时额外输出一个标准化字段。这里需要特别说明的是我尝试过让模型自己判断换算系数但结果不稳定。后来改成在提示词里明确给出换算对照表比如“一箱12件一件1个最小销售单位”让模型只查表不换算准确率立刻提上去了。标准单位换算规则 - 箱 - 件乘以12 - 套 - 件按照套装内数量换算无法确定时写“待确认” - 打 - 件乘以12 - 公斤 - 克乘以1000 - 其他非标准量词保留原文并在备注中标记“计量单位待确认”这条规则的核心逻辑是把模型从数学计算里解放出来。模型的语言理解能力很强但算数并不总是可靠尤其是涉及到“两箱半”这种带小数的场景。给它一张查表出错率就降下来了。表格之外的量词强制标“待确认”比让模型硬猜一个换算系数要靠谱得多。3.3 边界情况信息缺失与矛盾内容的处理做订单解析这段时间我总结出一个经验真正的难点从来不是正常订单而是那些信息残缺、互相矛盾的订单。客户发来一句“老价格不要错过这次优惠”就什么都不写了模型怎么处理消息里前半段说“改地址到朝阳区”后半段又有一个“公司地址海淀区”模型怎么判断我在提示词里给了一套明确的处理策略。对于缺失信息前文已经提到填充“未提及”对于矛盾信息不尝试自己裁决而是原样保留并且高亮冲突。这个策略一直坚持到今天因为它守住了底线辅助系统的职责是把信息整理清楚交给人工决策而不是替人工拍板。矛盾处理规则 如果同一字段在消息中出现了不一致的描述例如地址变更前后不同、数量前后不一致、 价格与总价不匹配等系统不得自动选择其中一个作为最终结果。 正确做法是保留全部描述在“备注”字段中用冲突提示前缀说明矛盾点 并列出所有冲突的原始描述。这条规则曾经引起过一个很有意思的行为差异。没有写这条时模型经常会自作主张把“客户说改到新地址”当成最终地址忽略后半句“暂不修改”。加了这条规则后模型学会在冲突提示里写明两句话的原始位置和上下文人工翻回去看原文的效率反而变高了。因为模型的引用定位能力检索原文的速度比人眼扫聊天记录快得多。4. 可复用性落地变量化模板与多场景适配框架搭好了、模块拆出来了接下来就要解决“换一批数据还能不能继续用”的问题。一开始我的提示词里写死了不少业务名词比如“产品名称”“交期要求”换到售后场景就完全不行。后来我把这些业务词全部抽成了变量提示词本身只剩逻辑骨架。4.1 字段级变量抽离所谓字段级变量就是把业务流程里可能变化的元素全部提取为独立的部分而不是混在句子中间。举个例子一个用于“订单新建解析”的提示词在通用场景下会拿到这样的变量映射变量名通用订单场景售后工单场景实体类型订单工单核心字段客户/商品/数量/价格/交期联系人/设备型号/故障描述/紧急程度输出键名客户名称/商品报修人/设备型号用户身份客户报修人这个映射表在实际使用中至关重要。模型对“字段名”非常敏感如果你想让系统返回“客户名称”提示词里就别写“联系人”哪怕你觉得这两个意思差不多模型的输出也会跟着你给出的字面走。字段名统一了后续的自动化流程才能接得住。4.2 提示词模板的模块化拼接变量抽离之后提示词本身变成几大块的组合。我这里做了一个简单的模板渲染结构可以应付大多数场景def build_order_prompt(sceneorder): role load_file(system_role_base.md) if scene order: task load_file(task_order_extract.md) constraints load_file(rules_order_unit.md) elif scene after_sale: task load_file(task_aftersale_extract.md) constraints load_file(rules_aftersale_unit.md) output_tpl load_file(output_json_template.json) return \n\n.join([role, task, constraints, output_tpl])这个拼接逻辑看起来非常朴素但带来的收益是实打实的。团队里任何一个人需要一个新的辅助能力只需要改一个模块文件不需要动其他部分。知道改哪一行比能写一整段提示词更重要。4.3 同一批提示词跑通多个场景的实践我拿这套系统做过一次极限测试把同样的框架分别用在“订单摘要生成”“售后工单分类”“供应商询价整理”三个场景里只替换了角色设定、任务描述、输出模板三个模块其余的路由逻辑、冲突处理规则、单位换算规则几乎没有改动。结果是三个场景全部跑通。之所以能这么顺是因为底层本质都是“从非结构化文本中抽取结构化字段”玩法是共通的。这也就是为什么我在标题里强调“可复用”而不是“一次性”。这套提示词框架真正的价值是可以沉淀成团队的提示词资产库下次遇到新的信息处理场景改改字段定义就能上线。5. 可复现性落地格式化输出、稳定性控制与版本管理如果说可复用解决的是“换场景还能不能用”那可复现解决的就是“同一场景下结果是否稳定”。这是很多AI辅助系统最终被弃用的核心原因——输出时好时坏没人敢信。这一节我单独拉出来讲因为它才是整个项目的护城河。5.1 强制JSON输出的稳定性手段我在前面已经提过输出契约这里补充一些工程细节。仅仅在提示词里写“请输出JSON”是不够的模型偶尔会在JSON前后加一些说明文字或者把键值对写成不符合要求的格式。我采用的是一套组合策略第一在提示词的末尾单独一段强调“只输出JSON不要输出任何其他文字”把这条命令放在最后靠近输出的位置约束力会更强。第二在解析端做容错处理如果拿到的内容不是合法JSON就尝试提取第一个花括号到最后一个花括号之间的子串再做解析。第三在每次交互的最开头再放一遍“本次输出必须合法JSON”的提示作为全局约束。这套组合打完JSON解析失败率降到了很低。即便如此我建议在代码层面绝对不要赌模型一定遵循格式解析失败的回退逻辑一定要写。5.2 采样参数与定位锚点的搭配大模型输出的随机性有一部分来源于解码参数温度太高会自由发挥过度温度太低又可能导致模板机械化。我在订单辅助系统中把温度设置在较低的水平以保证稳定输出。但光调参还不够更有效的稳定性控制手段是“锚点注入”。我在输出模板里预置了字段排序甚至把一些枚举值的取值范围直接写死。比如紧急程度只能是以下枚举值之一紧急、一般、不紧急。不要输出其他同名或近义词。为什么锚点能显著提升稳定性因为大模型的生成过程是逐词预测的当你把可选范围限定死之后模型在每一步的候选词空间就小了很多出现乱写同义词的概率自然降低。这个方法在很多场景下比调整温度参数还管用推荐你优先尝试。5.3 Few-shot示例的选取与维护除了硬性约束给模型吃几个好示例也是一条有效路径。这里的关键不在于示例多而在于示例精。我实践下来每个场景准备三到五个示例足矣但示例必须覆盖常见的边界情况。比如订单场景里我会放三个示例一个标准完整订单一个信息残缺订单一个包含矛盾信息的订单。每个示例都带上标准的输入输出对模型看到之后就更容易理解“缺失时标未提及”“矛盾时标冲突提示”这些规则到底是什么意思。示例不是一劳永逸的。我每个月都会把实际跑偏的案例回收成新的few-shot示例。这样系统会越用越稳因为历史踩过的坑都被吃进了上下文参考里。这也是“可复现”能够长期维持的关键提示词资产需要维护否则时间久了就会退化。5.4 提示词版本与效果追踪提示词的迭代很像写代码必须有版本记录否则改着改着就不知道当前线上跑的是哪一版。我用了一个最简易但很有效的管理方式每一条提示词文件都加入版本号同时在测试集上记录每次改动的输出差异。具体的做法是准备一组固定的测试输入每次改完提示词先把这组输入全部跑一遍用程序对比新旧输出的差异。如果某个字段的通过率下降就说明改动有问题回滚到上一个版本。这保证了任何一次优化都不是盲目的。测试集本身也要不断扩充把真实业务中遇到的奇葩输入塞进去。后来团队里其他同事接手这个系统时靠的就是这份测试集来理解系统边界而不是靠翻聊天记录问我当时怎么想的。6. 实测表现与常见问题的排查链路讲完设计和原理接下来这节是实打实的现场记录。任何系统上线后一定会遇到意外问题是能不能快速定位原因。我遇到过很多次AI输出异常的情况但几乎每一次都在几分钟内找到了原因靠的就是一套排查链路。6.1 误提取与漏提取的实际案例有一次销售反馈某个订单一直被系统解析成售后工单。我看了一眼输入文本原文是“客户说这批货不要了要退掉之前的订单”。模型把这些词跟“售后”关联起来直接归类为D类型。但实际上客户的意思是“取消订单并重新下单”属于新建订单的变体。这就是典型的“语义偏移”——文本里有退货词汇但意图并不只是售后。定位过程是这样的我先走了一遍排查链路第一条就是检查类型判断环节。我单独把输入文本拿来跑一次“只做类型判断”的prompt发现模型输出的确实是D。然后我用一个最简单的测试输入“删除订单重新下单”跑同一段代码结果输出是A。差异点很快就暴露了原句中的“退掉”误导了模型。修复方案是在任务描述里增加一条规则“当消息中提到取消原订单并重新下单时归类为A-新建订单归类前注意区分‘退货退款’与‘重购’的区别。”加了这条few-shot示例之后误判率明显下降。这类修复并不复杂难的是快速定位到误判是发生在哪个决策环节。6.2 上下文污染与幻觉信息的定位另一个高频问题是幻觉信息。我遇到过系统突然在备注里写“客户希望收到货后立即开发票”但原始消息里根本没有这句话。当时第一反应是模型出了问题但复查后才发现是我自己的问题这条会话在连续多次交互后对话历史里残留了上一个订单的特殊需求模型错误地把上一条消息的内容当成了本轮的上下文。上下文污染在订单场景里非常危险因为订单处理往往是多轮对话用户会连续发好几条消息改地址、加数量、催发货。如果模型把前面几轮的信息揉进最新一轮的解析结果里订单就会多出一些不存在的字段。我的解决办法是在每次调用模型之前对会话历史做一个处理只保留与当前订单强相关的关键信息并手动拼接成“已知背景”避免模型自己从大量历史文本里挖线索。同时在提示词里加了明确指令本输入是独立的订单消息。除非输入中明确引用了之前的对话否则不得根据对话历史补充信息。这句话有效遏制了上下文污染问题。如果你正被模型的“自作聪明”困扰先检查一下是不是对话历史太长导致的。6.3 长文本截断与输出越界还有一个常见问题是当客户消息特别长或者包含多张截图中的OCR识别文本时模型的输出会出现截断或者漏字段。我在排查中发现这不是模型不聪明而是因为提示词里的约束段落太多压缩了回答的空间最终输出被截断了。解决方式是把提示词分成必要和非必要两层。必要的角色设定、任务描述、输出模板常驻在上下文中一些示例放在最后的“参考示例”模块并且只保留一两个最典型的。如果文本实在太长就做分段抽取第一次先抽取前半部分的字段第二次抽取后半部分然后在后处理代码里做结果合并。这些听起来都不复杂但每一条都是被真实业务推着走出来的。排查的过程其实就是把黑盒模型拆成白盒子一层一层验证直到找到那个出问题的环节。7. 从订单辅助到团队协作把提示词变成可维护的资产到这里这套“订单辅助系统”已经不是一段简单的提示词了而是一个由模块化prompt、模板渲染脚本、规则校验逻辑、测试集共同构成的微型辅助引擎。最后我想聊聊怎么让这套资产在团队里真正落地而不是只躺在个人文档里吃灰。7.1 提示词的测试用例库建设我能给的最诚恳的建议是从第一天就建测试集。哪怕只有十条用例也比没有强。测试用例要覆盖四类场景标准输入、缺失字段输入、矛盾信息输入、模糊表达输入。每次修改提示词后跑一遍全量测试用脚本对比输出字段的填充率、合法率、冲突标记数量等指标。只有这样你才敢在业务环境里频繁迭代提示词而不必担心改坏某些隐藏场景。我现在维护的测试集已经有两百多条用例覆盖了日常订单、售后、物流变更、价格异议等多种情况。每次把新坑加入测试集系统的防回归能力就强一分。7.2 提示词如何纳入版本管理这里说的版本管理不只是存一个文件名带日期而是像管理代码一样管理prompt。我的做法是把prompt文件放在git仓库里每次变更都要提交commit信息里写上变更原因和影响范围。这样出了任何问题都可以checkout回上一版对比排查Diff。更重要的是prompt文件和解析代码、模板渲染代码放在一起改动的时候做整体测试保证提示词变了下游解析还能对齐。很多团队做AI应用代码和prompt都放在同一个仓库就是因为这两者的耦合度极高拆开管理只会制造混乱。7.3 从个人效率工具走向团队标准化当这套系统跑通三个月后我开始遇到另一个挑战同事也想用但他们不太理解“为什么会输出这个结果”。于是我把提示词模块化成了一份内部的说明文档把每个变量解释清楚把各个模块的用途写明白还配了五个典型的调试案例。后来团队甚至约定了一套“提示词评审”流程新场景上线前必须提交三类东西prompt文件、测试用例集、输出样例。有了这三样任何人接手都能快速理解系统的边界在哪里。这个流程不是负担反而大幅减少了“这AI怎么又出错了”的沟通成本。7.4 后续扩展从文本解析到流程执行目前这套系统已经稳定运行在订单信息抽取、售后工单分类和询价整理三个场景。下一步我计划把提示词的输出结果直接接到业务系统中让结构化字段自动填充到表单里再由规则引擎来做校验和流转。提示词负责“看懂”代码负责“执行”各司其职系统才能真正从辅助走向半自动。从个人工具到团队标准化的过程并不复杂关键是每一步都为下一步留好了接口。这套提示词框架就是我用最低成本铺好的一条路。