在客服工单自动分类、合同要素抽取、日报格式化这些实际项目里，让文心一言输出固定格式是刚需，但真正跑起来往往发现返回结果里多了一堆“好的，以下是您需要的内容”之类的客套话，或者JSON字段名被人为“优化”成了中文。究其原因，不是模型能力不够，而是提示词没有把真实场景的上下文压进去。下面从三个不同角度拆解如何把输出格式提示词真正落到业务里。
把真实数据样本塞进提示词，让格式“长”在例子上
很多提示词写成“请以JSON格式输出，包含姓名、年龄、地址三个字段”，看似清晰，但模型不知道这三个字段分别对应什么类型的数据。如果原数据里姓名字段叫“客户名称”，年龄字段偶尔出现“30岁”或者“三十”，地址字段有时是完整的省市区有时只有一个小区名，模型就会按照自己猜的规则去填，结果格式虽然对，内容却对不上。
正确的做法是直接从业务数据库或日志里取几条有代表性的原始数据，抹掉敏感信息后作为输入样例放进提示词。例如在抽取合同关键信息时，先给文心一言展示三条真实合同文本片段，再把期望的输出结构列出来，并且明确每个字段的取值来源。比如“合同金额”字段必须从原文“含税总价”或“合同总金额”后面提取数字，不能自己计算；“签署日期”要求转换成YYYY-MM-DD格式，如果原文只写了“2024年5月”，则输出“2024-05-01”并标记为“日期不完整”。这种带噪声的真实样本比一百句描述都管用。
另外要注意示例的摆放位置。文心一言对提示词后段的内容权重较高，建议把输出格式说明放在角色设定之后、真实样本之前，最后再用一小段强调“严格按照以下JSON结构输出，不要添加任何解释性文字”。如果示例里已经包含格式，可以省去大段的字段说明，直接说“输出格式请参照示例部分”。
用“反例约束”消除格式漂移
真实业务里最头疼的不是格式完全不对，而是“格式看起来对，但多了一块少了一块”。比如要求返回一个数组，模型偶尔返回对象；要求字段值为空时输出空字符串，模型输出null或者“无”；要求只输出JSON，模型在前面加了一句“根据您的输入，我整理如下”。这些问题靠正向描述很难完全避免，因为正向描述只能告诉模型应该做什么，不能穷尽所有不应该做的事。
一个有效的补丁是在提示词中加入明确的“禁止事项”和“反例”。举例来说，在做评论情感分类并输出结构化结果时，可以写：禁止输出任何与JSON无关的前缀或后缀；禁止将字段名翻译成中文；如果原文中不存在某个属性，该字段值必须为null而不能省略；下面是一个错误输出示例，请避免类似写法。然后给出一段故意带错的输出，标注“这是错误示范”。文心一言对错误示范的识别能力很强，看到反例后会自动规避同类模式。
另一个常见问题是数值和日期格式。提示词里如果只说“输出日期”，模型可能返回“2024年5月20日”、“2024-05-20”、“05/20/2024”三种不同写法。真实场景中下游系统往往只接受一种格式，所以必须指定：日期一律使用YYYY-MM-DD，时间为HH:MM:SS，金额保留两位小数且不要千分位逗号。把这些规则用短句罗列，放在输出样例之前，效果最好。
结合角色和任务上下文，让格式约束“参与推理”
单纯要求格式，模型容易把格式约束当成附加条件，而不是任务本身的一部分。解决办法是给模型一个明确的业务角色，并把格式要求融入角色的工作职责描述中。例如：“你是一名银行信贷审批辅助机器人，你的输出将直接写入风控系统数据库。请严格按以下JSON模板返回，任何格式错误都会导致系统写入失败。”这种场景化描述会让模型意识到格式不是可选项，而是任务成败的一部分。
更进一步，可以在提示词里模拟一次“写入失败后的人工修正”对话。比如先给一条格式正确的输出，再给一条因为多了换行符而被系统拒绝的输出，然后要求模型以后只输出第一种。这种通过后果来反向强化格式的方式，在实际测试中比单纯强调“必须严格遵守”更稳定。因为模型理解了格式错误的代价，而不是机械记忆规则。
如果业务场景涉及多轮对话，还需要把历史输出格式作为上下文的一部分。例如第一轮要求模型抽取发票信息并输出JSON，第二轮要求模型基于第一轮的JSON做汇总分析，这时必须在第二轮提示词里带上第一轮的实际输出，并说明“这是你上一轮返回的结果，请基于此结构继续处理”。如果不带历史输出，模型很可能重新生成一个结构相似但字段名不同的JSON，导致下游解析失败。
调试提示词的三个实用步骤
第一步，先用最小化提示词测试是否理解任务本身，不加任何格式要求，只问模型“请从以下文本中找出关键信息”。如果这一步就答非所问，说明任务描述不清，需要先补充背景。第二步，加入格式模板和字段说明，观察输出是否100%符合结构，重复测试10次以上，统计格式错误率。第三步，把测试中出现的所有格式错误整理成反例清单，逐条写进“禁止事项”部分，再重新测试。经过两三轮迭代，格式稳定性通常能提升到可接受范围。
测试时要注意输入数据的多样性。真实数据里可能有换行、特殊符号、超长字段、缺失值，这些都要分别构造样本去测试。例如一段包含HTML标签的合同文本，模型能否正确抽取纯文本内容输出？一个字段里带有英文双引号，模型输出的JSON是否会被破坏？这些细节往往决定线上效果。可以使用repr()或json.dumps()把测试输入输出打印出来，逐字符比对。
最后给一个可直接用于文心一言的提示词模板：
你是一个数据抽取助手，专门从给定的业务文本中提取结构化信息。
你的输出将直接写入数据库，任何格式错误都会导致任务失败。
【待处理文本】
{{input_text}}
【输出要求】
1. 只输出一个JSON对象，不要添加任何解释、注释或Markdown代码块标记。
2. 字段固定为：company_name（字符串）、total_amount（数字，保留两位小数）、sign_date（字符串，格式YYYY-MM-DD）。
3. 如果原文中找不到对应信息，company_name和sign_date输出空字符串，total_amount输出0。
4. 日期统一转换成YYYY-MM-DD，如果原始日期只有年月，则补充为当月第一天。
5. 禁止输出类似“好的”、“以下是结果”等任何额外文字。
【错误示范】
{
"company_name": "示例公司",
"total_amount": 100,
"sign_date": "2024年5月"
}
错误原因：total_amount应为两位小数，sign_date格式不对。
【正确示范】
{
"company_name": "示例公司",
"total_amount": 100.00,
"sign_date": "2024-05-01"
}
模板中使用了{{input_text}}作为占位符，实际调用时替换成真实业务文本。把这段提示词放进文心一言的控制台或API调用中，替换掉原来笼统的格式要求，你会看到返回结果的JSON解析成功率明显提升。