提示词不是咒语，而是接口设计

提示词工程最容易被误解成“找到一句神奇的话”。在生产系统里，它更接近接口设计：你定义输入字段、输出格式、异常处理、边界条件和测试样例，然后让模型在这个契约内工作。

明确角色，不如明确任务边界

“你是资深专家”可以帮助模型进入语境，但真正影响稳定性的，是任务边界。例如：只根据给定资料回答、无法判断时返回缺失信息、输出必须包含风险等级和依据。

把上下文拆成字段

一段长提示词很难维护。更好的方式是把输入拆成结构化字段：用户目标、可用资料、业务规则、输出格式、禁止事项、示例。字段化以后，团队才能讨论每一块是否必要。

任务：生成客户问题的答复草稿
资料：{retrieved_context}
限制：不得承诺未确认的交付时间
输出：JSON，包含 summary、answer、risk_level、sources

输出格式是系统契约

如果下游程序要消费模型结果，就不要只要求“简洁清晰”。应该定义可解析格式，并给出缺失字段时的处理规则。JSON、Markdown 表格、固定段落模板都可以，但要根据业务流程选择。

少量示例胜过抽象形容词

“语气专业”很模糊，而一个好答案和一个坏答案的对比更清楚。示例能把语气、颗粒度、引用方式和拒答边界同时传递给模型。

提示词也需要回归测试

每次修改提示词，都可能让某些场景变好、另一些场景变差。建议维护一组固定样例，覆盖高频请求、异常输入、敏感内容和边界条件。上线前跑一遍，记录差异。

把提示词拆成可维护模块

生产系统里的提示词可以拆成系统目标、业务规则、输入说明、输出 schema、示例和安全边界。这样做的好处是修改某一部分时更容易评估影响，也方便产品、研发和业务方分别审阅。

提示词变更要有记录

很多模型问题不是突然发生的，而是某次提示词、模型版本或检索策略调整后逐渐出现。建议为每次变更记录原因、预期收益、影响范围和回归结果。提示词不是文案，它是系统配置。

提示词越像接口，系统越容易迭代；提示词越像灵感，系统越难维护。