改一个词就翻车，提示词工程到底在调什么

提示词工程常被说成写咒语。实际用起来，更像反复试。Reddit的r/PromptEngineering上，有网友Cloudy_Day912发了个帖子：一个提示词刚好给出想要的答案，措辞稍微一改，结果就散了。他问，大家到底花更多时间改提示词本身，还是靠示例、结构化输出和测试来把事情做稳。

这个描述很具体。单次命中不难，难的是下一次还命中。提示词里换一个同义词、调一下句子顺序、加一句礼貌用语，输出都可能漂移。做demo时觉得模型挺聪明，上线后才发现它在不同输入上各有各的想法。

帖子提到的几个词值得拆开看。示例，是给模型几组输入输出样例，让它照着模式走。结构化输出，是要求模型按固定格式返回，比如JSON，方便程序接住。测试，是拿一批固定输入反复跑，看改动有没有把旧能力弄坏。三件事都不性感，但都比继续琢磨形容词有用。

一个判断：只调措辞，很容易把提示词过拟合到少数几个案例上。今天这个问法好用，明天换个用户说法就失效。把示例当规格、把结构化输出当约束、把测试当回归，提示词才从手感变成可维护的东西。

普通用户也能感受到这点。你让模型总结邮件，偶尔一次很顺，不说明什么。换十封不同语气、不同长度的邮件再试，才知道提示词有没有边界。开发背景的读者更熟悉这套逻辑，接口要契约，改动要回归，提示词也一样。

帖子最后把问题抛给社区：你更关注提示词本身，还是示例、结构化输出和测试。这个问题本身暴露了一个尴尬：很多人还在用改文案的方式，处理一个系统稳定性问题。

下次改提示词时，可以留意一下，你是在换措辞，还是在补用例。