每个模型都有"能做好"和"做不好"的区间
同一个模型，在有些任务上很好 ✔，在另一些上很糟 ✔。
如果你的产品不区分这两类 ✗，用户就会在"做不好"的场景里被伤到 ✔，
从而对整个产品失去信任 ✔（哪怕其它场景很好 ✔）。
做法：明确画出"可用区间" ✔，区间外主动说不 ✔。
一、怎么画出可用区间
- 列任务类型（分类、抽取、摘要、改写、多跳推理、计算 ✔）；
- 每类用 20~30 条样本测 ✔（见评测那几篇 ✔）；
- 记录三类指标：正确率、该拒答却作答率（编造 ✔）、成本/延迟 ✔；
- 设准入线 ✔（例如正确率 ≥ 85% 且编造率 ≤ 2% 才算"可用" ✔）。
结果通常会呈现清晰的能力梯度 ✔ —— 这就是边界 ✔。
二、区间外要"主动说不"
- 入口提示：明确写出"适合做什么、不适合什么" ✔（见文档那篇 ✔）；
- 运行时识别：识别到超出区间的输入（任务类型 + 复杂度 ✔）→ 提前说明 ✔
（而不是硬答一个看起来像样的答案 ✗）；
- 给替代路径（人工、其它工具、拆分任务 ✔）。
关键：主动说不比"硬答"更能保住信任 ✗→✔ ——
用户能接受"这个我做不到" ✔，不能接受"答错了还理直气壮" ✗。
三、边界的三种类型
| 类型 | 例子 | 处理 |
|---|---|---|
| 能力边界（模型做不到 ✔） | 精确计算、长链推理 ✔ | 拒答 + 替代方案 ✔ |
| 数据边界（没有资料 ✔） | 未收录的文档 ✔ | 明确说"资料里没有" ✔ |
| 合规边界（不该做 ✔） | 越权、敏感建议 ✔ | 拒绝 + 原因 ✔ |
三类的用户提示语要不同 ✔（能力不足 vs 没有资料 vs 不允许 ✔）——
混用会让用户误以为"系统坏了" ✗。
四、边界要随版本更新
- 换模型/改提示词后重测能力梯度 ✔（边界会移动 ✔）；
- 边界收窄要主动通知 ✔（原来能做现在做不了，是重大变更 ✔）；
- 把边界写进验收标准 ✔（见验收那篇 ✔）。
五、该观测什么
- 超区间请求占比（有多少用户在用"做不好"的功能 ✔）；
- 超区间时的行为分布（拒答 / 硬答 / 转人工 ✔ —— 硬答比例是关键 ✔）；
- 超区间后的用户行为（是否继续使用 ✔）。
一条判据
抽 20 个"你不擅长"的任务 ✔，系统是明确说不 ✔ 还是给一个像样的错答案 ✔？
后者占比高，说明可用区间没有被执行 ✗。