Prompt Engineering 实际案例：从迭代到质量复核

实际项目里的 prompt 更像一段可维护配置。它需要说明任务边界、输入格式、输出结构、禁止行为和失败时的处理方式。

如果 prompt 只能在作者手里有效，就还不是团队资产。别人接手后能不能理解、能不能调试、能不能判断输出质量，才是更重要的问题。

我会把 prompt 当作工作流的一部分，而不是孤立的模型咒语。

很多 prompt 迭代失败，是因为输出结构不稳定。今天是自然语言列表，明天是 JSON，后天又夹杂解释，后端和前端都很难接。

在 AI 下单助手这类场景里，输出必须先变成明确字段：服务类型、时间、地址、备注、置信度、需要确认的字段。结构稳定后，业务系统才有接入点。

结构化输出不是为了好看，而是为了让后续校验、人工确认和审计记录成为可能。

Prompt 迭代不应该只看成功样本。真正有价值的是失败样本：字段漏填、意图误判、语气过度、输出格式漂移、把不确定内容说得太肯定。

每次失败都应该归类：是上下文不足、指令歧义、示例不够，还是模型本身不适合。不同原因对应不同调整方式。

如果只是不断加一句“请更准确”，prompt 会越来越长，但问题不一定更少。

Prompt 输出是否可用，不能只靠主观感觉。至少要检查格式稳定性、业务字段完整性、边界条件表现和人工修改成本。

对于图像生成工作流，还要看输出是否贴近业务场景、是否符合品牌方向、是否能被后续流程使用，而不是只看第一眼是否惊艳。

当这些标准被写下来，prompt 才能从一次调参变成可交接的工作方式。

不要把所有业务规则都塞进 prompt。能由代码校验的内容，就应该由代码校验；需要模型判断的部分，才交给 prompt。

比如订单时间是否合法、用户是否有权限、服务是否在范围内，这些都不应该只靠模型遵守。模型可以建议，系统必须验证。

好的 prompt engineering 不是让模型负责一切，而是把模型放在它最适合的位置上。