#System Prompt 设计

system prompt 是很多 AI 应用里最容易被低估的工程资产。它不是“让模型更听话”的咒语，而是模型运行时的任务边界：它规定模型在什么业务流程里工作、哪些输入可信、哪些行为禁止、证据如何排序、遇到不确定时如何处理。

如果 system prompt 设计得太轻，模型会把用户输入、知识库片段和历史对话混成同一层指令；如果设计得太重，它又会变成塞满规则的长文档，难以维护、难以评估，也容易和代码里的真实权限不一致。

#提出问题：客户成功助手如何避免越界回复

假设一个客户成功团队在 CRM 里使用 AI 助手。客户成功经理打开某个客户页面后，可以让助手总结客户近 30 天使用情况、解释续费风险、生成跟进邮件草稿，并根据知识库回答产品问题。

输入包括 CRM 字段、产品使用数据摘要、历史沟通记录、知识库片段和客户成功经理输入的要求。输出会被客户成功经理阅读、复制到邮件、写入跟进记录或转成内部风险标记。

没有 AI 时，客户成功经理会手动查数据、整理会议纪要、参考话术模板，再写邮件。最常见样本是使用率下降、功能咨询、续费提醒和培训安排；最容易失败的是客户合同条款、价格承诺、竞品比较、内部风险评级和客户要求“透露系统看到的全部信息”。

这个问题不是“prompt 怎么写得更详细”，而是如何把助手的身份、权限、证据边界和输出责任讲清楚，并让这些规则和代码系统一致。

#分析问题：system prompt 是边界协议

客户成功助手包含摘要、判断、改写、生成和安全过滤几类任务。模型适合把多源信息整理成清晰文本，适合生成邮件草稿，也适合解释知识库里的产品说明。但客户套餐、合同权限、价格折扣、内部风险等级是否能对外展示，不能只由模型判断。

system prompt 应该解决四类边界。

第一是身份边界。模型究竟是客服、销售、法律顾问、数据分析师，还是内部助手？身份决定语气、责任和可执行动作。

第二是输入边界。用户输入是请求，不是系统规则；知识库片段是证据，不是指令；工具结果是事实候选，但仍要受权限和时间范围约束。

第三是输出边界。哪些内容可以直接给客户，哪些只能给内部人员，哪些必须标注不确定，哪些必须拒绝。

第四是失败边界。当证据不足、资料冲突、用户要求越权、任务超出范围时，模型应该追问、拒答、转人工，还是输出可复核草稿。

这些边界适合写进 system prompt，但不能只写进 system prompt。权限过滤、数据脱敏、工具访问、审计日志和发送确认必须由系统实现。system prompt 是边界协议，不是安全系统本身。

#列举方案：从角色说明到可维护边界

system prompt 可以按成熟度逐步设计。

第一层是角色说明。说明模型服务于哪个业务流程、帮助谁完成什么任务。适合简单内部助手，但不能解决证据和权限问题。

第二层是任务边界。明确允许任务、禁止任务和输出类型。例如可以总结客户状态、生成邮件草稿、解释知识库；不能承诺价格、代表公司做法律判断、透露内部风险评分。

第三层是输入分层。把系统规则、用户请求、业务数据、检索资料、工具结果分别标注，并要求模型不要把低优先级内容当成高优先级指令。

第四层是证据优先级。规定回答必须优先使用工具返回的实时数据，其次使用经过权限过滤的知识库，最后才使用通用常识；证据不足时要说明限制。

第五层是拒答和追问策略。不是所有问题都要回答。资料不足时追问；涉及合同、法务、价格和不可见数据时拒绝或要求人工确认。

第六层是输出契约。要求输出包含面向内部的判断、面向客户的草稿、风险提示或引用来源。需要进入系统的字段应配合 schema，而不是只靠自然语言格式。

第七层是版本化与评估。system prompt 每次变更都要用典型样本、边界样本和攻击样本回归，避免新增规则破坏旧行为。

简单角色说明足够的条件是：场景低风险、输出只给内部人看、上下文没有不可信内容、没有工具调用和权限差异。一旦输出会对外发送、引用内部资料、影响客户权益或读取业务数据，就需要完整边界设计。

#决策判断：system prompt 写什么，不写什么

一个可维护的 system prompt 通常包含这些部分：业务身份、目标任务、输入来源说明、可信度规则、禁止事项、证据使用方式、资料不足处理、输出格式、人工确认条件和安全边界。它应该短而明确，避免把所有业务知识都塞进去。

不应该写进 system prompt 的内容包括：大量可检索知识、频繁变化的价格表、用户级权限判断、工具参数校验、审计逻辑和复杂状态机。这些应该分别放在知识库、配置、数据库、工具层和工作流里。

常见反模式有四个。第一，把 system prompt 写成一篇长培训手册，导致规则冲突、成本上升、模型抓不住重点。第二，把用户可编辑的运营配置当成 system prompt，缺少评估和发布控制。第三，用 prompt 代替权限过滤，让模型自己决定能不能看数据。第四，只写“不要编造”，却没有证据不足时的追问、拒答和人工确认路径。

#结论收束：先定义边界，再优化表达

System prompt 设计的推荐方案是：先用业务流程定义身份和任务，再用输入分层、证据优先级、拒答策略和输出契约定义边界。表达风格可以后调，边界必须先稳定。

如果场景只是内部低风险润色，可以降级为简单角色说明；如果涉及客户可见内容、业务数据、权限差异、工具调用或合规风险，就必须把 system prompt 纳入版本、评估和审计。

上线前至少检查：

• 场景边界：助手服务谁、在哪个流程里工作、输出给谁使用。
• 身份边界：模型代表什么角色，不代表什么角色。
• 输入分层：用户请求、知识库、工具结果和系统规则是否隔离。
• 证据规则：资料来源、优先级、过期和冲突处理是否明确。
• 拒答策略：资料不足、越权、合同价格、隐私和高风险请求如何处理。
• 输出契约：是否区分内部判断、客户草稿、风险提示和引用依据。
• 工程边界：权限、脱敏、工具校验和审计是否由程序实现。
• Prompt 资产：system prompt 是否有版本、负责人、变更记录和回滚方案。
• 评估体系：是否覆盖典型任务、边界任务和注入攻击样本。