前端学 LLM

Prompt Engineering 进阶专题总览

很多团队第一次接入大模型时，会把 prompt 当成一段“写给模型看的说明”。只要 demo 能跑通，prompt 就被复制到代码、配置、运营后台或数据库里。上线一段时间后，问题才开始出现：模型换了，输出风格变了；业务规则改了，旧 prompt 还在生效；用户输入里混入攻击指令，系统边界被绕开；质量下降时没人说得清是哪次改动造成的。

进阶 Prompt Engineering 的核心不是“写出更聪明的一句话”，而是把 prompt 当成工程资产管理。它需要边界、版本、变更流程、评估样本、安全防护和可观测日志。只有这样，prompt 才能进入生产系统，而不是停留在个人经验和临时试错里。

提出问题：客服回复助手为什么不能只靠一段 prompt

假设一个 B2B SaaS 团队正在做客服回复助手。客服每天在工单后台输入用户问题，系统读取当前工单、用户套餐、产品文档片段和历史沟通记录，然后生成一版回复草稿。客服会人工编辑后发送给客户。

这个能力的输入来自多个来源：用户原始工单、CRM 用户状态、知识库检索结果、公司政策和客服补充说明。期望输出不是普通聊天回答，而是一段可发送给客户的回复草稿，要求语气稳妥、事实来自资料、不能承诺未确认事项、不能泄露内部流程和客户隐私。

没有 AI 时，客服会搜索知识库、查历史工单、复制话术模板并手动改写。常见样本是功能咨询、账单问题、集成失败和操作指引；最容易失败的是套餐差异、版本差异、合同条款、客户情绪激烈和资料不足的场景。使用频率可能从每天几十次增长到几千次，并且每次失败都会留下对外沟通记录。

要素具体情况工程含义
使用者客服、客户成功、实施顾问输出需要可编辑、可追溯
输入工单、用户状态、知识库片段、历史沟通需要区分可信来源和用户指令
输出客户可见回复草稿需要事实边界、语气边界和风险提示
频率高频、多人协作、持续迭代prompt 需要版本化和回归测试
失败代价错答、越权、错误承诺、隐私泄露需要评估、安全和人工确认

这个场景看起来只是“写一段更好的 prompt”，但真正的问题是：系统如何保证 prompt 在业务变化、模型变化、上下文变化和恶意输入下仍然可控。

分析问题：prompt 是任务边界而不是技巧集合

客服回复助手至少包含分类、检索、判断、生成和安全控制几类任务。模型适合做语言理解、摘要、改写和基于证据生成回复；规则和程序更适合做套餐权限判断、敏感字段脱敏、工具参数校验、日志记录和审计；高风险承诺、退款、合同解释和对外口径仍然需要人工确认。

分析项具体判断工程含义
问题类型改写、生成、判断、检索后回答、安全拒答prompt 要定义任务、证据使用方式和拒答边界
收益来源减少客服查资料和起草时间，降低新人遗漏值得引入 AI，但不能完全自动发送
失败代价引用错误、越权泄露、错误承诺、被注入绕过需要边界隔离、评估集、日志和人工复核
人工位置编辑客户回复、批准高风险内容、标注失败样本产品流程要保留确认和反馈入口

prompt 在这里承担的是任务契约：告诉模型系统角色、输入来源、输出标准、禁止行为、证据优先级和不确定时的处理方式。它不是单独存在的文案，而是连接业务规则、上下文工程、结构化输出、工具调用和人工流程的接口。

这也意味着 prompt 不能替代工程边界。用户输入不应该和 system prompt 混在一起；知识库片段不应该拥有改变系统规则的权力；模型输出不应该直接执行高风险动作；质量判断不应该依赖“我试了几个问题感觉还行”。prompt 只能定义模型要如何思考和表达，不能独自承担权限、事实、审计和回滚。

列举方案：从临时 prompt 到工程资产

Prompt Engineering 可以按工程成熟度逐级升级，而不是一开始就引入复杂平台。

第一层是简单 prompt。适合内部低风险改写、固定输入、人工一定会复核的场景。它的成本低，但边界和质量主要靠人兜底。

第二层是 prompt 模板。把变量、输入区块、输出格式和示例固定下来，避免每个调用点手写不同版本。它增加了复用性，但仍需要约束变量来源和空值策略。

第三层是 system prompt 设计。把任务边界、角色、禁止事项、证据优先级、拒答策略和安全边界放在稳定层，而不是散落在用户输入或业务文案里。它能减少越界和风格漂移，但需要和产品权限、上下文装配配合。

第四层是 prompt 版本与评估。每次修改 prompt 都要有版本、变更原因、样本集、回归结果和上线记录。它能控制质量回退，但需要维护评估数据和自动化测试。

第五层是 prompt + schema。输出要入库、驱动 UI、触发工作流或进入统计时，必须让 prompt 和结构化输出契约绑定，并由程序校验。

第六层是 prompt + RAG / Tool / Workflow。需要私有知识、业务数据或执行动作时，prompt 只负责解释任务和使用证据，权限过滤、工具调用、状态流转和审计应该由系统承担。

第七层是 prompt 安全防护。只要接收外部用户输入、网页内容、文档、邮件或第三方数据，就要处理 prompt injection、数据泄露、越权工具调用和上下文污染。

简单 prompt 足够的条件是：输入稳定、失败低风险、输出只给人看、人工会复核、没有外部不可信内容进入上下文。一旦 prompt 影响下游系统、对外沟通、业务权限、客户权益或高频生产流程，就需要升级到可版本化、可评估、可观测和可防护的工程方案。

决策判断：按风险选择 prompt 工程复杂度

场景条件推荐方案不推荐方案判断理由额外成本
内部低风险改写，人工必看简单 prompt + 少量示例重型评估平台输出不直接进入系统决策prompt 维护
多处业务复用同一任务Prompt 模板 + 变量契约在代码里复制多份 prompt需要统一输入、输出和变更入口模板管理、空值处理
对外回复或专业建议System prompt + 证据边界 + 人工复核只靠用户消息约束模型需要稳定角色、拒答和事实边界审核流程、日志
高频生产链路版本管理 + 离线评估 + 线上监控凭主观感觉改 prompt需要防止质量回退样本集、回归门禁
输出进入数据库或工具Prompt + Schema + 程序校验自由文本解析下游需要稳定契约schema、校验、重试
输入含不可信内容指令分层 + 注入防护 + 权限隔离把网页、文档直接拼进 prompt外部内容可能试图改写系统规则内容隔离、审计、拒答

几个判断原则需要先固定下来。

第一，prompt 的边界不能高于系统权限。模型不能因为 prompt 写得“专业”就获得访问更多数据或执行更多动作的能力。

第二，prompt 变更要像代码变更一样可追踪。凡是影响用户可见输出、业务判断或工具调用的 prompt，都应该有版本、评估和回滚。

第三，prompt 质量不能只看平均效果。最重要的是失败样本：资料不足、用户诱导、边界模糊、冲突证据和高风险业务。

第四，prompt 安全不是一句“不要泄露系统提示词”。真正的安全来自输入隔离、权限控制、工具确认、输出过滤、日志审计和异常处理。

常见反模式也很明确：把 prompt 写得越来越长来掩盖上下文质量问题；把业务规则写在 prompt 里却没有程序校验；没有评估集就直接上线；模型换版后不回归；把外部网页和用户输入当成可信指令；把 prompt 当成个人手艺而不是团队资产。

结论收束：把 prompt 纳入设计评审

Prompt Engineering 进阶的推荐方案是：低风险场景从模板化开始，高频和对外场景必须引入 system prompt 边界、版本管理、评估样本、安全防护和可观测日志。这个方案成立的前提是团队承认 prompt 是工程资产，而不是一次性文案。

如果输出只给内部人员参考，可以降级为简单 prompt 和人工复核；如果输出要进入工具、工作流、数据库、客户沟通或权限判断，就必须升级工程复杂度。

上线前至少检查：

  • 场景边界：目标用户、业务流程、输入来源、输出消费者是否明确。
  • Prompt 资产：模板、变量、system prompt、版本、变更记录是否可管理。
  • 输入分层：系统指令、开发者规则、用户输入、知识库、工具结果是否分区。
  • 质量标准：什么是好结果、可接受结果和必须拦截的坏结果。
  • 评估体系：是否有覆盖常见样本、边界样本和攻击样本的回归集。
  • 安全控制：是否处理 prompt injection、越权请求、敏感信息和日志脱敏。
  • 人工确认：高风险回复、承诺、执行动作是否有确认入口。
  • 可观测性：是否记录 prompt 版本、模型、参数、上下文摘要、错误和人工反馈。
  • 回滚恢复：prompt 或模型变更导致退化时能否快速定位和回滚。

本专题后续文章会分别展开：