Prompt 工程实战：让大模型稳定输出的五条原则

Prompt 是新的接口

和模型协作，Prompt 就是你的 API 调用。写得随意，产出就不稳定；写得结构化，模型的发挥就可控。这篇总结几条经得起实战的原则。

原则一：给角色和目标

模糊的指令得到模糊的回答。明确"你是谁、要做什么、给谁看"：

你是一位资深前端工程师。请为初学者解释什么是闭包，
用一个点击计数器的例子，控制在 200 字内。

原则二：给结构，不给散文

要求结构化输出，既方便解析也提升质量：

请按以下格式输出：
## 结论
（一句话）
## 原因
- 要点1
- 要点2
## 示例代码
（可运行的最小示例）

需要程序消费时，直接要求 JSON 并给出 schema，比事后正则解析可靠得多。

原则三：少样本示例（few-shot）

给 1~3 个输入输出示例，模型会模仿格式与风格：

把下面的句子改写得更专业：
输入：这个 bug 太烦了
输出：该缺陷影响了正常使用，建议优先排查。

输入：代码跑不起来
输出：

原则四：引导思考过程

对推理类任务，让模型"先想再答"：

请先分步分析，再给出最终答案。

这类"思维链"提示能显著提升逻辑题、数学题的正确率。但对简单任务反而是浪费，按需使用。

原则五：约束与兜底

明确边界条件，避免模型自由发挥：

- 只使用我提供的资料，不要编造
- 若信息不足，回答"无法确定"
- 不要输出任何解释，只返回结果

迭代方法

1. 写初版 → 跑几组典型输入。
2. 找出失败案例，针对性加约束或示例。
3. 把稳定的 Prompt 固化成模板，参数化可变部分。

Prompt 工程不是玄学，而是可迭代的工程实践：定义清楚"对"，收集失败案例，逐条收敛。