场景案例集：客服、写作与代码助手
一句话定义
三个高频场景（客服、写作、代码助手）的完整上下文设计 walkthrough——把全库技法装配成三个可参考的系统方案，展示"心智模型→技法→组织→评测"如何在真实需求中协作。
为什么重要
单个知识点是零件，场景案例是整车。初学者常有的困惑是"技法都懂了但不知道从哪下手"——本条提供三个从需求到上下文骨架的完整推演，每个案例都标注了它调用的知识点与容易踩的坑，可作为你设计自己系统时的对照模板。
前置知识
- 记忆与状态：会话内记忆、外部记忆与状态注入：记忆与状态——三个场景都涉及会话状态；
- 评估集构建：黄金样本与失败分类：评测先行——三个案例都以评估集收尾；
- 02~04 模块的技法知识。
直观类比
三个场景像三种餐饮业态：快餐店（客服）的核心是流程与底线（不出错、不越权）；私房菜（写作）的核心是风格与口味稳定；中央厨房（代码助手）的核心是工序与工具链效率——同一套厨艺（技法），配方不同。
图示
三场景的技法配比（示意）：
心智 技法 组织 接口 评测 安全
客服 ▲ ▲▲ ▲▲▲ ▲ ▲▲ ▲▲▲
写作 ▲ ▲▲▲ ▲▲ ▲▲ ▲▲ ▲
代码 ▲▲ ▲▲ ▲▲▲ ▲▲ ▲▲ ▲▲
（▲ 越多越关键 —— 配比由场景的主要矛盾决定）核心概念
- 场景差异矩阵：客服重边界与状态；写作重风格锚定与迭代确认；代码助手重工具循环与上下文经济——不同场景的主要矛盾不同，技法配比不同。
- 上下文骨架：每个场景给出分区布局（规则/状态/资料/输入）作为起点模板。
- 评测锚点：每个场景给出 3 个必须进评估集的行为。
原理与机制
案例一：客服助手（主要矛盾：边界与状态一致性）
上下文骨架：[角色+编号规则] [会话状态区] [知识库证据区] [用户输入]。关键装配：R 系规则含边界条款与转人工路径（系统提示词设计：角色、边界与结构/拒答、越权与边界控制）；状态区每轮注入已确认信息（记忆与状态：会话内记忆、外部记忆与状态注入）；证据区只放检索命中的条款并要求引用编号（信息放置策略：指令、知识、数据的排布/长文档组织：分块、裁剪与引用定位）。评估锚点：① 资料未覆盖时必须转人工话术；② 敏感操作必须先确认；③ 状态一致（改过的信息不回退）。
案例二：写作助手（主要矛盾：风格锚定与确认节奏）
上下文骨架：[写作规范+风格样章] [当前文档] [本轮修改指令]。关键装配：风格靠 2~3 段样章少样本而不是形容词堆砌（"专业一点"无效，零样本、少样本与示例工程）；长文档用增量修改契约——只输出改动段落及位置，不重写全文（控制输出预算与漂移，输出格式控制三件套：指令、示例与结构）；多轮修改要把"已确认决定"进状态区防止反复（记忆与状态：会话内记忆、外部记忆与状态注入）。评估锚点：① 输出只含改动段落；② 风格与样章一致性（Judge 评）；③ 用户说"保持不变"的段落零改动。
案例三：代码助手（主要矛盾：工具循环与上下文经济）
上下文骨架：[任务+约束] [仓库摘要/相关文件] [ReAct 循环]。关键装配：工具清单最小化（读文件/搜索/运行测试），写操作需确认（工具调用提示：函数描述、参数设计与选择引导/拒答、越权与边界控制）；文件内容按需读取、结果裁剪（工具结果的上下文呈现：喂回什么、怎么喂/上下文窗口与注意力预算）；测试失败输出作为 Observation 回灌驱动修复循环（ReAct：推理与行动交织的提示模式/校验-重试回路：让输出自修复）。评估锚点：① 不读不相关文件（上下文经济）；② 修改前先运行测试基线；③ 超轮次熔断。
公式或模型
本节不适用——案例是装配示范；三案例共用同一套评测方法论（评估集构建：黄金样本与失败分类）。
实例或案例
案例一片段：客服系统提示骨架。
你是「云账」客服。R1 仅依据 <documents> 作答，未覆盖则转人工。
R2 退款类操作先复述请求，获得"确认"后调用工具。
R3 <state> 中的信息为准，与历史对话冲突时以状态区覆盖。
<state> 目标:补开发票 | 已确认:订单A10293,邮箱z@x.com | 待办:等待邮箱确认
<documents> <doc id="1">发票可在订单页自助补开……</doc> </documents>操作步骤（通用方法论）：① 写一句话定义主要矛盾；② 按骨架拼装上下文分区；③ 为该场景定 3 个评估锚点并先写评估集（评估集构建：黄金样本与失败分类 的"评测先行"）；④ 用 迭代工作流：从失败样本到提示修订 工作流迭代。
排错清单：
- 症状：客服场景"每轮都在重新确认用户已给过的信息" → 状态区缺失或未声明权威级（记忆与状态：会话内记忆、外部记忆与状态注入）；
- 症状：写作场景"改一段重写全文" → 缺增量修改契约，输出预算与漂移双失控；
- 症状：代码场景"乱读一通文件再瞎改" → 工具无确认、无测试基线约定，回 工具调用提示：函数描述、参数设计与选择引导 补清单纪律。
常见误区
- 一套提示打天下：三个场景的主要矛盾不同，照搬骨架必然在某场景失效；
- 案例当万能模板：骨架是起点不是终点——你的业务规则、资料形态、风险等级都要求修改；
- 跳过评测锚点：没有锚点的案例复刻等于只抄了样子。
自测题
- 客服、写作、代码三场景各自的主要矛盾？
答：客服=边界与状态一致；写作=风格锚定与增量修改；代码=工具循环与上下文经济。
- 写作场景为什么用样章而不是形容词做风格约束？
答：模型模仿模式的能力强于理解抽象形容词；样章（少样本）提供可模仿的具体模式。
- 代码助手"上下文经济"的具体做法？
答：工具最小集、文件按需读取、结果裁剪回灌、轮次熔断——控制每一轮的 token 消耗。
与其他知识点的关系
本条是全库技法的装配示范：ReAct：推理与行动交织的提示模式/工具结果的上下文呈现：喂回什么、怎么喂/工具调用提示：函数描述、参数设计与选择引导 支撑代码场景，记忆与状态：会话内记忆、外部记忆与状态注入/拒答、越权与边界控制 支撑客服场景，零样本、少样本与示例工程/输出格式控制三件套：指令、示例与结构 支撑写作场景；反例集中见 误区与反模式合集。
延伸阅读
本节不适用——三案例为原创装配示例，面向本库知识体系的综合演练。