用户不会问，只会"随便写一句"
同一个功能，好提问与坏提问的结果差距巨大 ✔：
"帮我写个方案" ✗ vs "为一家 20 人的 SaaS 公司写一份新客户上手方案，面向技术负责人，800 字以内" ✔。
建一个"输入示例库" ✔：把"好的提问长什么样"直接摆给用户看 ✔。
一、示例库要有什么
① 每条示例：完整输入（用户可直接点用）
② 一句话说明：为什么这样问效果更好
③ 场景标签：适合谁、什么时候用
④ 反面示例（可选但很有用）：这样问会差在哪
第 ② 项最关键 ✗→✔：只给示例不解释 ✔，用户会照抄但学不会 ✔；
解释了"为什么" ✔ → 用户能迁移到自己的场景 ✔。
二、示例从哪来（别自己编 ✗）
- 真实日志里的高频好案例 ✔（用户问过且结果好的 ✔ —— 见查询日志那篇 ✔）；
- 人工审核里的"标杆修改" ✔（审核员改得最好的那几条 ✔ —— 见审核队列 ✔）；
- 客服记录里的成功解决 ✔。
要点：示例必须真实出现过 ✔（编的示例往往"太完美"，不具代表性 ✗）。
三、怎么呈现（三个位置）
- 空状态（第一次进来就看到 ✔ —— 见空状态那篇 ✔）；
- 输入框上方（可横向滚动的示例卡片 ✔）；
- 失败提示里（"试试这样问：…" ✔ —— 见用户教育那篇 ✔）。
要点：示例要可点击直接使用 ✔，而不是只能看 ✔。
四、示例库要维护
- 每月更新（能力变了，示例要变 ✔）；
- 淘汰不再有效的（模型换代后老示例可能不再好用 ✔）；
- 标注"最近更新"（用户会信任更新的示例 ✔）；
- 统计点击率（哪些示例被用得最多 ✔ → 说明这类需求高频 ✔）。
五、三个反模式
- 示例写得像广告 ✗（"输入任何内容都能得到完美答案" ✔）；
- 只给一个示例 ✗（用户以为只能这么问 ✔）；
- 示例与实际能力不符 ✗（点了发现做不了 ✔ —— 最伤信任 ✔）。
六、一条判据
新用户第一次进来 ✔，能否点一个示例就得到满意结果 ✔？
不能，说明示例库要么没有、要么不真实 ✗。