提示词工程被包装得很玄，实操层面其实就是一件事：消除模型猜测的空间。下面六个方法按见效速度排序，每个都配改前改后的对比。
方法一：给约束，而不是给愿望
改前："写一篇关于远程办公的文章。" 改后：
写一篇 800 字的文章，目标读者是第一次带远程团队的主管。
必须包含：3 个常见误区、每个误区对应的具体做法。
不要出现"赋能""闭环"这类词。语气：像朋友喝咖啡时给建议。
约束越具体，输出的方差越小。
方法二：少样本示例（Few-shot）是最强的格式控制
想让模型输出固定格式，贴两个例子胜过两百字描述：
把用户反馈分类。示例：
输入："App 一打开就闪退" → 输出：{"type": "bug", "priority": "high"}
输入："希望增加深色模式" → 输出：{"type": "feature", "priority": "low"}
现在分类这条："导出的表格格式全乱了"
模型对模式的模仿能力远强于对抽象规则的理解能力。
方法三：要求结构化输出
自由文本适合人读，结构化数据适合程序用。需要程序处理结果时，直接指定 JSON Schema，并加一句"只输出 JSON，不要任何解释"。配合 API 的 JSON mode，解析失败率能降到接近零。
方法四：把大任务拆成步骤
"帮我分析这份财报"的输出通常平庸。拆成三步：
- 先提取这份财报里的关键数字（收入、利润、负债率）
- 与上一季度对比，列出变化超过 10% 的项
- 基于以上变化，给出三个可能的原因
每一步的输出作为下一步的输入。单步任务模型很难跑偏，串起来就完成了复杂任务。
方法五：让模型自己挑错
生成之后追加一轮反向校验：
检查你上面的回答：
1. 有没有没有依据的数字？
2. 有没有和开头约束矛盾的地方？
有的话直接修正并说明改了哪里。
这不能替代人工核查，但能拦住约一半的明显错误，成本只是多一次调用。
方法六：把调试好的提示词存成模板
调好的提示词不要躺在聊天记录里。建一个自己的模板库，用变量占位：
角色：资深 {{领域}} 编辑
任务：把 {{原始素材}} 改写成 {{目标格式}}
约束：{{禁区清单}}
示例：{{两个样本}}
提示词是资产，模板化才能复用和迭代。
一句话总结
模型猜对一次是运气，稳定猜对是工程。消除猜测空间的手段就这么多：约束、示例、结构、分步、校验、模板——练熟这六招，够覆盖九成日常场景。