非常明确的Prompt+示例可以保证大语言模型输出Json格式。比如你需要生成包含用户信息的Json，那么你可以用这个Prompt：请生成一个包含用户信息的JSON，具体要求如下：- 姓名：字符串类型- 年龄：整数类型- 邮箱：字符串类型
请严格按照以下格式返回结果：
```json{ "name": "示例姓名", "age": 示例年龄, "email": "示例邮箱"}
这里面包含了两部分，第一部分是提示词，要生成Json格式，并且确定了一共有三个数据以及相对应的数据类型。第二部分直接给出示例，其中示例中的数据属性都跟提示词对应，字符串就双引号“”，普通的整数类型不加双引号，以及再次强调了要Json格式。我们可以用这个Prompt来测试一下，分别用ChatGPT3.5， ChatGPT4o，Gemini，通义千问以及Kimi。首先，ChatGPT3.5作为一个老模型，生成的没问题。 再试ChatGPT4o，也没问题，不过它生成的让我觉得更智能一些，因为邮箱那个地方，它用了英文的形式，因为邮箱确实没有中文格式，而名字那里没有变，因为可以是中文。 接下来是Google的Gemini，它的生成就有意思了，一模一样的Prompt，它生成了两部分内容，一部分是正常的Json格式；另一部分它加上了解释，解释每个数据的数据类型，以及它的使用说明，这部分说实话我觉得意义不大，跟Prompt关系不大。
接下来是通义千问的测试结果，生成的也没问题，不过有意思的是，在名字和邮箱那一栏，它用了“张三”，这个很有意思，因为张三李四是很明显的中文语料库里面的高频词，而ChatGPT并没有体现这一点。
最后就是Kimi了，和通义千问类似的，它用的是张伟，也是中文语境下的高频词，非常有趣的发现。 这个例子相对来说比较简单，因为很多情况下Json格式可以储存非常多的信息，比如网站链接、数组、时间格式等等，那么这种情况下，用Prompt + 示例是最好的方法。因为Prompt可以保证整体的输出方向，示例可以让大模型的输出约束到极限。比如说我们要生成下面的这种Json格式，它不仅有字符串，还有网站链接，还有嵌套Json，以及还有数组格式，这种你只用Prompt几乎是不可能做到的，因为你需要描述的东西太多了，且不一定精确。{ "user_info": { "name": "John Doe", "age": 30, "email": "johndoe@example.com", "website": "https://johndoe.com", "social_media": { "twitter": "https://twitter.com/johndoe", "linkedin": "https://linkedin.com/in/johndoe" } }, "address": { "street": "123 Main St", "city": "Wonderland", "zip_code": "56789", "geo_location": { "latitude": 37.7749, "longitude": -122.4194 } }, "orders": [ { "order_id": "ORD123", "date": "2023-01-15", "items": [ { "product_id": "P001", "name": "Product 1", "image_url": "https://example.com/images/p001.jpg", "quantity": 2, "price": 19.99 }, { "product_id": "P002", "name": "Product 2", "image_url": "https://example.com/images/p002.jpg", "quantity": 1, "price": 49.99 } ] }, { "order_id": "ORD124", "date": "2023-02-20", "items": [ { "product_id": "P003", "name": "Product 3", "image_url": "https://example.com/images/p003.jpg", "quantity": 3, "price": 9.99 } ] } ], "total_spent": 109.95, "membership_status": "Gold", "coupons": ["COUPON1", "COUPON2"]}
但是加上示例代码就容易多了，完整版的Prompt+示例如下，其实就跟刚刚的一样，只不过在具体的Json描述上多了很多的新内容。
请生成一个包含详细用户信息的复杂JSON，具体要求如下：- 用户信息（user_info）：对象 - 姓名（name）：字符串类型 - 年龄（age）：整数类型 - 邮箱（email）：字符串类型 - 个人网站（website）：URL字符串类型 - 社交媒体（social_media）：对象 - 推特（twitter）：URL字符串类型 - 领英（linkedin）：URL字符串类型- 地址（address）：对象 - 街道（street）：字符串类型 - 城市（city）：字符串类型 - 邮编（zip_code）：字符串类型 - 地理位置（geo_location）：对象 - 纬度（latitude）：浮点数类型 - 经度（longitude）：浮点数类型- 订单（orders）：数组，对象类型 - 订单ID（order_id）：字符串类型 - 日期（date）：字符串类型 - 商品（items）：数组，对象类型 - 商品ID（product_id）：字符串类型 - 名称（name）：字符串类型 - 图片链接（image_url）：URL字符串类型 - 数量（quantity）：整数类型 - 价格（price）：浮点数类型- 总花费（total_spent）：浮点数类型- 会员状态（membership_status）：字符串类型- 优惠券（coupons）：数组，字符串类型
请严格按照以下格式返回结果：
```json{ "user_info": { "name": "示例姓名", "age": 示例年龄, "email": "示例邮箱", "website": "示例个人网站URL", "social_media": { "twitter": "示例推特URL", "linkedin": "示例领英URL" } }, "address": { "street": "示例街道", "city": "示例城市", "zip_code": "示例邮编", "geo_location": { "latitude": 示例纬度, "longitude": 示例经度 } }, "orders": [ { "order_id": "示例订单ID", "date": "示例日期", "items": [ { "product_id": "示例商品ID", "name": "示例商品名称", "image_url": "示例图片链接", "quantity": 示例数量, "price": 示例价格 }, { "product_id": "示例商品ID", "name": "示例商品名称", "image_url": "示例图片链接", "quantity": 示例数量, "price": 示例价格 } ] }, { "order_id": "示例订单ID", "date": "示例日期", "items": [ { "product_id": "示例商品ID", "name": "示例商品名称", "image_url": "示例图片链接", "quantity": 示例数量, "price": 示例价格 } ] } ], "total_spent": 示例总花费, "membership_status": "示例会员状态", "coupons": ["示例优惠券1", "示例优惠券2"]}
我就用通义千问来测试下这个Prompt，结果完全没问题。 这就是Prompt编写时候的准则，宏观的方向+细致的指导，这样你做出来的Prompt可以大程度上消除歧义。这种思考方式可以引申到很多地方，比如有时候大模型理解不了你让它写Python代码，那你加一段经典的python代码在prompt上就行了，比如 import numpy，这就是给大模型提示一下的神奇效果。
