上一篇的核心结论是：Prompt 不是聊天技巧，而是结构化输入设计。这个视角解决了“怎样把任务说清楚”的问题，但当模型真正接入系统之后，还会遇到第二个问题：任务已经说明清楚，输出为什么仍然不稳定？
很多 Prompt 不是完全不可用，而是只能“偶尔答对”。对于 AI 应用工程来说，这种状态距离可上线仍然很远。真正需要的不是某一次回答足够惊艳，而是同类输入下，模型能够持续给出同类结果。
Table of contents
Open Table of contents
“能用”不等于“可接入系统”
在工程场景里，Prompt 最大的问题往往不是模型完全不会，而是它每次都差一点：
- 这次字段全了，下次漏一个
- 这次语气正常，下次风格跑偏
- 这次是 JSON，下次多加一段解释
- 这次分类合理，下次边界样本判断漂移
这种“不完全错，但总不完全一样”的状态，才是最难处理的。因为下游系统最怕的不是单次错误，而是没有稳定预期。
所以这部分内容的核心，不是再学几个 Prompt 技巧，而是学会一件更工程化的事：
如何逐步收窄模型的输出空间，让结果更稳定、更可验收。
Zero-shot 应该是默认起点
更合理的做法，是把 zero-shot 当成默认起点，而不是把 few-shot 当成“高级模式”。
原因很简单：如果一个任务在 zero-shot 下就能稳定完成，说明你的任务描述本身已经足够清楚。这个时候继续堆示例，收益未必高，维护成本反而会增加。
换句话说，zero-shot 最适合拿来做两件事：
- 验证任务边界是否清晰
- 建立最小可用版本的 Prompt
例如我们想从用户反馈中提取问题信息，一个很自然的 zero-shot 写法可能是：
请分析下面这条用户反馈，并提取关键信息。
反馈：
App 打开很慢，而且首页改版后我找不到会员入口了。这时候模型很可能能答出一些内容，但输出通常不稳定：
- 这次提到“性能问题”和“导航问题”
- 下次可能改成“用户体验差”和“功能入口不清晰”
- 有时会总结，有时会解释，有时还会扩展建议
所以 zero-shot 的意义不是“够不够高级”，而是帮助你看到：现在的任务描述到底有多大自由度。
Few-shot 不是装饰，而是约束
few-shot 容易被理解成“给几个例子，让模型学一学”。更准确的理解是：
当任务已经描述清楚，但输出空间仍然太大时，用示例去收窄模型的可接受行为。
这时候示例的作用就不再是“举例说明”，而更像是在定义：
- 应该用什么字段
- 哪些判断边界算合理
- 输出风格应该落在哪个范围
- 什么样的答案才叫“符合预期”
还是上面的用户反馈场景，如果改成 few-shot，可能会更像这样：
你是一名用户反馈分析助手。
请根据输入反馈，输出以下字段：
- issue_type
- severity
- summary
示例1：
反馈：支付完成后页面一直转圈，没有成功提示。
输出：
{
"issue_type": "支付流程异常",
"severity": "high",
"summary": "支付结果反馈缺失，用户无法确认是否成功"
}
示例2：
反馈：字体有点小，但还能用。
输出：
{
"issue_type": "界面可读性",
"severity": "low",
"summary": "字体偏小，影响部分用户阅读体验"
}
现在请分析：
反馈：App 打开很慢，而且首页改版后我找不到会员入口了。加了 few-shot 之后，模型会更倾向于：
- 使用同一套字段
- 使用接近的抽象粒度
- 给出一致的 severity 风格
- 用更稳定的 summary 句式
所以 few-shot 解决的不是“模型知不知道”，而是“模型会不会稳定地按你希望的方式知道”。
示例最重要的不是数量，而是边界
对 few-shot 来说，一个很重要的判断是：示例不是越多越好，关键在于边界样本选得好不好。
如果你给的全是“理想样本”，模型学到的往往只是表面形式；但在真实场景里，真正麻烦的是边界输入：
- 情绪强烈但信息不完整
- 同时包含两个问题类型
- 描述模糊，严重程度不好判断
- 反馈很短，几乎没上下文
这些时候，few-shot 的价值才真正体现出来。
因为示例不只是告诉模型“正确答案长什么样”，更是在告诉它：
当事情不那么标准时，你也应该怎么做。
结构化输出不是格式美化，而是系统边界
这里还有一个非常重要的问题，即“格式控制”。
这种做法容易被理解成：
- 用 JSON 比较整齐
- 用列表比较清楚
- 用表格比较好看
但如果站在工程角度看，结构化输出的意义根本不是排版，而是：
让输出结果能够被程序稳定消费、比较、校验和接入后续流程。
比如同样是分析用户反馈：
不加格式约束
请分析下面这条反馈，并告诉我有什么问题。模型可能返回：
这个反馈主要涉及两个方面。第一，应用启动较慢，属于性能体验问题；第二，首页改版后会员入口难找，属于信息架构和导航问题。整体来看，这会影响用户留存。这段话人可以读懂，但程序很难稳定解析。
加结构化输出约束
请分析下面这条反馈，并严格输出 JSON：
{
"issue_types": [""],
"severity": "",
"summary": ""
}这时候你得到的结果，不只是更规整，而是：
- 更容易做自动处理
- 更容易做批量评估
- 更容易比对不同 Prompt 版本
- 更容易接到下游系统里
也就是说，structured output 不是“更漂亮”，而是“更可依赖”。
一个更实用的判断标准：先 zero-shot，必要时再 few-shot
这里最值得坚持的一条方法论是：
先用 zero-shot 验证任务是否清晰，只有当输出空间仍然过大时，再用 few-shot 去收窄行为。
这个顺序很重要，因为它更符合工程上的成本意识。
如果一开始就堆示例，很容易掩盖真正的问题：
- 是任务没定义清楚？
- 还是边界没说清？
- 还是输出协议不明确？
- 还是模型本来就需要行为样本来校准？
zero-shot 更像是基线方案，few-shot 更像是校准手段。
在这种理解下，few-shot 就不应再被看成“更高级的 Prompt”，而应被看成：
在必要时才引入的控制成本。
一个 Prompt 是否更稳定，可以怎样验收
如果把这部分内容真正落到工程实践里，“Prompt 好不好”的判断标准也应该随之变化。
验收重点不应只放在单次结果是否足够聪明、是否足够漂亮，而应更多关注下面这些问题：
- 同类输入下，输出结构是否一致？
- 关键信息会不会时有时无？
- 边界样本会不会漂移？
- 下游程序能不能稳定消费结果？
- 如果换一个人继续使用这个 Prompt，结果还能不能维持可用？
如果这些问题答不上来，那这个 Prompt 可能只是“看起来能用”，还远远谈不上稳定。
本篇结论
第一篇更关注“怎么把 Prompt 写清楚”，第二篇更关注“怎么让 Prompt 少发挥一点”。
对 AI 应用工程师来说，写 Prompt 的关键，不是让模型尽情发挥，而是让输出尽量收敛。zero-shot 帮你验证任务定义是否清楚，few-shot 帮你校准行为边界，格式约束帮你把结果变成可以接进系统的输出。
如果说第一篇是在建立输入接口，那么这一篇更像是在收紧接口契约：让模型不只是能回答，而是能稳定地按预期方式回答。
下一篇将进入“从角色提示到结构化接口”，重点讨论 system prompt、消息分层、Function Calling 和结构化返回协议。