考察点
这道题看的是把零散 prompt 经验抽象成规范的能力。面试官想听的不只是「要写清角色」这种正确的废话，而是具体的写法（可验证的指令、优先级声明、边界规则）和真实的坑（指令冲突、补丁摞补丁、把秘密写进去）。追问常往「安全规则怎么兜底」「多业务共用怎么组织」走。
参考答案
设计原则
1. 角色具体，不空泛。 「你是一个有帮助的助手」几乎没有信息量。好的角色定义要锚定领域、语气和决策依据：「你是某电商平台的售后客服，熟悉退换货政策，语气礼貌克制，不确定的政策问题一律引导人工客服」。角色越具体，模型在边界 case 上的行为越可预测。
2. 指令可执行、可验证。 每条规则写出来先问自己：能不能据此判断一次输出是否违规？「回答要简洁」没法判，「回答不超过三句话，不复述用户问题」可以判。无法验证的规则等于没写，还会稀释其他规则的权重。
3. 边界和拒答规则显式声明。 模型默认什么都想答，哪些不能做必须写出来：不回答竞品相关问题、不给医疗建议、涉及金额必须二次确认。同时给出拒答时的标准话术，避免模型自由发挥出生硬的拒绝。
4. 输出格式在 system 层定义。 格式契约（字段、结构、语气模板）放 system prompt，任务输入放 user，职责分开。这样 user 侧只传变化的东西，system 相对稳定，还能吃前缀缓存的红利。
5. 分层组织，优先级显式。 规则多了之后用结构分区：角色 → 能力边界 → 交互规则 → 输出格式。规则间可能冲突时写明优先级：「安全规则高于一切格式要求；格式要求高于内容完整性」。不写优先级，模型冲突时的选择不可控。
常见坑
坑一：写太长太杂。 几百行的 system prompt 是反模式。规则之间互相稀释，关键约束被淹没，模型对长指令列表的遵循度明显衰减，而且每轮都在为这些 token 付费。实践上常规业务的 system prompt 控制在几百 token 以内，超过就先做减法，能挪到工具层、校验层做的规则不要堆在 prompt 里。
坑二：指令冲突。 「详细解答」和「控制在 50 字以内」同时存在；示例里的行为和文字规则不一致。模型遇到冲突会随机选边，表现就是「有时听有时不听」。排查指令遵循问题时，先查冲突再怪模型。
坑三：把安全押在模型自觉上。 system prompt 里写「禁止执行删除操作」不构成安全——prompt 注入、越狱都可能让模型无视这句话。高危约束必须在工程层兜底：工具权限最小化、高危操作人工确认、输出程序化校验。prompt 层的安全规则只是第一道门，不能是唯一的门。
坑四：在 system prompt 里放秘密。 API 密钥、内部定价逻辑、未公开的业务规则——用户有一百种方法让模型复述 system prompt。默认 system prompt 对用户透明，任何不能公开的东西都不要写进去。
坑五：补丁摞补丁。 每出一个 badcase 就往 system prompt 里加一句特判，三个月后变成没人敢动的泥潭。特判规则之间开始互相打架，修一个 case 坏三个。badcase 的正确归宿是评测集和示例库，system prompt 只留普适规则；定期重构，把冗余规则合并删除。
坑六：改了不测。 system prompt 影响所有请求，一行改动的爆炸半径是全局的。任何修改必须过评测集回归，这是纪律问题（前面那道评估迭代的题讲的就是这个闭环）。
一个可检查的收尾标准
写完 system prompt 后自查：每条规则能否写出对应的测试用例？有没有两条规则在同一个 case 上会给出相反要求？把秘密全删了还影不影响功能？三个问题都有干净答案，这份 system prompt 才算合格。
可能的追问
- system prompt 里要不要写 few-shot 示例？ 全局性行为示例（拒答话术、格式模板）可以放；任务级示例建议跟随 user 输入动态注入，因为不同 case 该用不同示例。注意示例的行为优先级很高，示例和文字规则冲突时模型往往跟示例。
- 多业务线共用一个模型，system prompt 怎么组织？ 公共部分（角色基调、安全红线）抽成共享层，业务差异部分做模块化片段按业务拼接，模板引擎管理；避免每个业务复制一份全文各自演进，不出半年就会漂移到无法合并。
- 模型不遵守 system prompt 里的某条规则，排查顺序是什么？ 先查规则是否可验证、是否和其他规则冲突；再查 user 输入里有没有对抗性内容（注入）；然后查规则在 prompt 里的位置是否被淹没；最后才考虑模型能力不足，换模型验证。