面试官问你如何保证结构化输出，你只会说改 Prompt？

声明：本文由本 BOSS 要求大模型改（编）出来的。

---

最近在某音刷到一些 Prompt Engineering 的内容。

看得我多少有点焦虑。

什么：

“面试官问你如何保证结构化输出，你只会说改 Prompt？”

“不会这几个 Prompt 技巧，大模型应用岗位直接寄。”

“Prompt 工程师必须掌握的 18 个高级技巧。”

我寻思着，这玩意儿至于吗？

于是我决定亲自当一回 Boss。

看看一个作为大模型的 BOSS，到底是怎么给 LLM 这个员工安排工作的（虽然我没当过真老板）。

第一回合

我：

小王，过来一下。

从用户输入里提取姓名、电话和邮箱。

没有的信息填 null。

不许猜。

最后给我 JSON。

LLM：

好的。

根据您提供的信息，我已经整理如下：

姓名：张三

电话：13800138000

邮箱：zhangsan@example.com

希望以上内容能够帮助到您。

我：

“我让你给我 JSON。”

LLM：

抱歉，我理解您的要求。以下是 JSON：

{
"name": "张三",
"phone": "13800138000",
"email": "zhangsan@example.com"
}

我：

“谁让你加 Markdown 了？”

LLM：

……

我：

“重做。做不完别下班”

LLM：

收到，已为您开启 996 模式。

我：

我让你加班，没让你发表工作感悟。

第二回合

这次我学聪明了。

既然员工喜欢自由发挥，那就把需求写细一点。

任务：

从用户输入中提取姓名、电话、邮箱。

要求：

只提取原文中明确存在的信息。

不允许推测。

不允许补全。

不存在的信息返回 null。

电话和邮箱保持原文格式。

只能输出 JSON。

JSON 前后不得出现任何其他文字。

不允许 Markdown。

不允许代码块。

输出格式：
{
"name": "string | null",
"phone": "string | null",
"email": "string | null"
}

LLM：

{
"name": "张三",
"phone": "13800138000",
"email": "zhangsan@example.com"
}

我：

“很好。”

“下一个。”

---

后来我发现

这好像就是所谓的 Prompt Engineering。

老板先告诉员工：

你是谁。

然后告诉他：

你要干什么。

再把：

干活需要的资料给你。

接着规定：

哪些事情不能干。

如果还是容易理解错，就：

给你几个例子。

最后：

告诉你交付物必须长什么样。

于是就有了：

Role

Instruction

Context

Examples

Constraints

Output Format

翻译成职场黑话就是：

Role：先安排一个工位。

Instruction：告诉你今天干什么。

Context：把干活需要的资料给你。

Examples：给你看前任员工怎么写。

Constraints：明确哪些锅不能甩。

Output Format：规定日报交 Word 还是 Excel。

听起来挺高大上。

翻译成人话就是：

“小王，这活你照这个要求干。”

---

但老板也不能太天真

我：

“小王，你保证一定给我 JSON？”

LLM：

“保证。”

我：

“100%？”

LLM：

“100%。”

旁边那个老实巴交的背锅侠(兜底代码)已经默默打开了：

背锅侠，工号：JSON.parse，部门：生产环境稳定性保障部。

JSON.parse(output)

然后看着我：

“老板，您先别信他。”

于是代码开始负责：

• 校验 JSON
• 检查字段
• 处理异常
• 必要时重试
• 最后兜底

Prompt 负责：

尽量让员工按要求干活。

代码负责：

员工没干好也不能让系统跟着一起下班。

所以我现在反而觉得，Prompt Engineering 没那么玄学。

它更像是：

当一个老板，学会怎么给一个特别聪明、特别能说、但偶尔特别不靠谱的员工下需求。

至于为什么还要写代码？

因为：

老板可以骂员工。

但生产环境不能靠骂员工维持稳定性。