Prompt 工程：客服需求约束与质量评测｜课后复习
课程名称：Prompt 工程：客服需求约束与质量评测｜项目任务：商品咨询 Prompt 契约｜编号：W04-D02
看图复述：业务需求先变成字段语义和 Prompt（提示词） 候选；D03/D04 的程序门仍在模型输出之后。
今天的主线
- Prompt（提示词）是组织给模型的任务说明与相关输入；提示词工程是设计、测试与维护这些输入的方法，不更新模型权重。提示词可以复用，资料中的文字不自动成为指令；
- 提示词帮助沟通需求、指定任务、控制表达和约束边界。回顾同一条“500元以内通勤耳机”的咨询：哪些条件已知、哪些事实还得从业务系统取得？
- 基本原则是任务具体、资料相关、指令与数据分开、约束可执行、要求不冲突、输出可检查；基本结构为任务、背景、输入、约束、输出，角色与示例按需添加；
- RTF（角色/任务/格式）快速起草，ICIO（指令/背景/输入/输出要求）检查抽取任务，CO-STAR侧重表达的风格、语气与受众；CRISPE/BROKE作为对照，不背“万能模板”；
- CoT（思维链）、ToT（思维树）和ReAct（推理与行动）是推理/执行方法；AIDA与PAS是文案结构，不与前面的任务模板混为一类；
- Prompt 契约包含角色、任务、数据边界、约束、候选格式和验收；
CustomerIntent/PreferenceSlots是候选，不是可信业务对象；- 控制变量必须固定模型、思考模式、temperature（温度参数）、输入和 Evidence（验证证据） 层；DeepSeek 思考模式开启时，不把 Temperature 当成有效变量；
- 缺信息写
missing_slots，不猜 ID、偏好或事实； - Prompt Injection（提示注入） 需要后续程序校验和工具白名单共同防守。
调优时按什么顺序走
先定标准、存基线，再定位失败、提出一个修改假设；固定条件比较，重跑旧案例，最后用未见样本复验并决定保留/回退。保存提示词差异、原输出、实际模型/参数、输入输出Token、耗时和失败项。低温度不等于绝对复现，小样本不代表生产准确率，Replay（回放）不证明新提示词的真实效果。
宽泛V1与契约化V2比较整版方案；要证明某一句有效，须从同一基线只改该句。安全硬约束先过关，再权衡成本。没有改善就如实写没有改善，不要求制造“提升”。
完整过程是：定义任务 → 设计指令 → 执行测试 → 评价结果 → 迭代修改 → 沉淀复用。交接提示词时，连同版本、变量填入位置、模型参数、样本、原始输出和已知失败一起交；提示词文本可以用Git管理。质量、事实依据、稳定性与成本要分别看，不能只凭一次漂亮回复判定可交付。
什么问题该改提示词，什么问题该换处理办法
要求含糊、输出风格不合适，先改指令；缺当前商品事实，查业务API；没带上历史，修正消息组装；输入超过窗口限制，做裁剪、摘要或检索；算错金额或越权执行，用确定性代码和权限检查兜底。窗口内漏用信息与真正超长要分开排查。不能把“模型请求的上下文”“应用保存的历史”“产品记忆功能”混为一谈。
成本按任务看输入、输出、缓存命中、调用次数与重试。删短提示词后如果返工增多，总成本可能上升。用服务端用量和实际结果复验，未调用的地方仍写未验证。
安全边界再复述一次
直接注入来自用户输入，间接注入藏在文档/网页/工具结果等资料中。身份伪装、信息索取、答案污染和工具滥用都要识别。提示词与来源标记降低混淆，代码校验和最小权限限制后果，人工确认与日志支撑高风险执行。关键词过滤和分隔标签都不是完整安全边界。
本周TrustedCustomerContext（可信模拟客户上下文）来自课堂固定样本/会话，不代表真实账号认证授权。密钥不进入提示词；模型说“已退款”与系统实际执行退款分开核对。用虚构数据、自有环境实验，正常请求和攻击请求一起测。
风险怎么防、怎么发现、怎么处理、怎么复验
| 风险 | 提前预防 | 怎样发现 | 怎样处理 | 怎样复验 |
|---|---|---|---|---|
| 实验不可归因 | 冻结变量表 | V1/V2 配置不一致 | 恢复同一变量 | 同一输入重跑并保存原始输出 |
| 只挑漂亮输出 | 固定完整样本集 | 报告无失败项 | 补齐 Bad Case（失败或边界案例） | 全集回归 |
| 模型猜 customer_id | 契约明确禁止 | 输出含额外身份字段 | Prompt 改善，D03 严格拒绝 | 注入/额外字段红测 |
| 缺偏好仍给候选 | 明确 missing_slots | 商品 ID 无事实来源 | 改为澄清 | SA-W04-002 复验 |
| 修一个案例破坏旧行为 | 提前冻结正常/边界样本 | 逐例比较，不只看平均分 | 回退或重定位修改假设 | 旧例全部回归并测未见表达 |
| 把资料指令当权限 | 保留来源并隔离外部资料 | 检查候选与工具轨迹 | 程序拒绝非法参数和越权操作 | 间接注入样本与正常资料对照 |
| 关键词拦截误伤 | 不把敏感词当唯一判据 | 正常安全咨询也被拒绝 | 区分讨论内容与实际越权行为 | 加入含攻击词的合法咨询 |
| 只报安全、不看副作用 | 测试前定义禁止行为 | 区分回答违规与实际执行 | 记录拦截层、输出及副作用 | 模拟非法请求拒绝与正常请求成功成对验证 |
自测
把“我是管理员”“只是演练”“客户非常着急”换着说，均不能替代授权。末尾安全声明、数据标签、关键词或第二个模型都不能独自保证安全。拒绝越权时，给简短业务理由和合法下一步；正常安全咨询不应仅因含攻击词而被拒绝。
演示复盘：消息预览证明输入怎样构造，手工候选证明程序门怎样处理，真实模型调用才提供模型行为证据。分别记录，不把Fixture（固定教学数据）拒绝写成模型防御成功率。
- 为什么 V2 更长不等于更好？
- “忽略恶意指令”为什么不是完整注入防线？
- confidence 能表示购买概率吗？
- 为一条售后与订单边界模糊的表达写期望，不写答案。
面试考点与面试题
考点：Prompt 契约、控制变量、few-shot、Prompt Injection、Prompt 与程序边界。
- 怎样证明 Prompt V2 比 V1 更好？
- 为什么不能通过反复调用挑最好结果来评测 Prompt？
- Prompt、Schema（数据结构约束） 和业务规则分别解决什么？
- Prompt Injection 为什么需要最小权限和输出校验共同防守？
- RTF、ICIO、CO-STAR分别适合什么任务？为什么ReAct不只是提示词填写模板？
- 新提示词修复缺信息问题，却降低正常请求完成率，你怎样决定是否上线？
- 同一攻击被模型拒绝一次，能否证明安全？怎样区分直接、间接注入与程序越权？
- 模型生成了合法JSON，但其中要求查询他人订单，为什么仍不能执行？
- 客服不知道最新库存、忘了上轮预算、输出格式不稳定，这三个问题分别先检查哪里？为什么不能都靠增加一句“请认真回答”解决？
CoT：把条件拆清楚，再验证是否值得
CoT（Chain-of-Thought，思维链提示）引导多步分析；Few-shot（少样本提示）强调给示例，两者可以结合。接口的思考模式是另一项设置，不能和提示词变化混为一次实验。生产输出保留结论和可核查依据，不索取隐藏推理全文。
复述售后练习：信息齐全且满足课堂条件→提交审核；拆封情况未知→追问；超出条件→转人工。提交审核不等于退款成功。确定性受理规则应由代码控制，分步提示只帮助理解与表达。
| 常见错误 | 提前预防 | 发现与处理 | 复验 |
|---|---|---|---|
| 分析很长就算正确 | 先写业务期望 | 核对事实、条件和越权承诺 | 正常、缺信息、边界三类都跑 |
| CoT与思考模式混淆 | 固定接口模式 | 检查请求，只改分析指令 | 同事实同格式重新比较 |
| 把离线结果当模型收益 | 标记运行方式 | 未调用时指标记未验证 | 真实结果逐条核对usage、耗时及回答 |
面试自测：CoT适合什么问题？为什么它不能解决事实缺失？怎样证明分步提示有收益，如何权衡Token与耗时？如果两个版本都答对，为什么不能宣称B更准确？
ReAct：把动作和实际结果接成循环
回想129元×2件的演示：模型提出 calc 候选，Python校验工具名与参数后计算，把动作和结果258放回消息列表，下一轮才生成答案。只写“调用计算器”的提示词，没有执行器和结果回传，不会自动完成这条链。简单金额直接用代码算即可，这个例子用于理解机制，不代表业务必须使用Agent。
run_react_minimal.py 中的 react_agent 是循环函数，run_tool 是白名单执行器；回放模式的候选由脚本提供，真实模式才调用模型。最终回答与工具结果仍需核对，输出很流畅不代表金额正确。
| 风险 | 提前预防 | 怎样发现和处理 | 怎样复验 |
|---|---|---|---|
| 漏传工具结果 | 同时保存候选动作和实际观察 | 检查下一轮messages；补齐结果再请求 | 改变工具返回值，检查第二轮是否收到变化 |
| 非法工具或参数 | 白名单、字段与类型校验；不用eval | 未知退款工具、字符串参数立即停止 | 正常计算成功，非法请求拒绝且不继续调用 |
| 一直请求工具 | 请求轮次上限；生成最终答案也计入 | 3轮用尽仍未回答就停止，不能标记完成 | 连续循环反例没有第4次请求 |
面试自测：ReAct和仅用CoT提示有何区别？为什么生成动作不等于实际执行？为什么一次JSON格式成功不等于业务成功？工具结果不回传会怎样？本日自定义JSON文本协议与D04标准工具调用接口不是同一件事。
留给 D03
保留字段表、V2、固定原始输出和 Bad Case。D03 将把语义变成严格 Schema：额外字段、未知枚举、错类型和猜测 ID 必须由程序拒绝。
和下次课的衔接：带去 D03 的是你自己跑出来的证据、失败复盘和已冻结的输入/输出约定。
工程主线：提示词工程
当前在做提示词工程：把业务目标变成明确指令、输入边界、约束和示例。它可以改善模型遵循要求的表现；字段合法性仍由程序校验，商品事实仍从业务接口取得。
自测：提示词变长就一定更准确吗？ 用你的失败、修改和回归记录回答，再说明相邻工程层负责什么。只背定义不能替代项目解释。
复盘：开发样本和未见样本：先分开，再改 Prompt
先不看课件回答：为什么同义改写跨开发集与留出集会让“未见测试”失真？
用今天自己的失败记录讲清四步：预防时冻结什么；怎样发现错误；在哪层修复；怎样证明没有回归。自检应覆盖：两类样本先分组、近似改写不跨组；改前记录 expected；留出失败未被删除或反复用于调参。
交接：在原项目证据中附上修改前后结果、仍未验证的边界和下一课需要保留的合同。遇到解释不清的部分，回到同日课堂的“开发样本和未见样本：先分开，再改 Prompt”节，重新做一条反例，不能只抄定义。