09 边缘案例定义产品质量

人类记住的是:
  ✅ 失败经历(印象深刻)
  ❌ 成功经历(理所当然)

例子:
  - AI帮你生成了99篇好文章
  - 第100篇出现严重错误

用户记住的是:
  "这个工具不靠谱,会出错"

而不是:
  "这个工具99%的时候很好用"

好体验: 告诉1-2人
坏体验: 告诉10+人

社交媒体时代:
  - 差评会被放大
  - 好评很少传播

一个用户的边缘案例失败,
会通过社交网络影响几百人。

某AI写作工具:
  - 常规案例: 95%好用
  - 边缘案例: 生成了带有争议性的内容

结果:
  - 一个用户发推特吐槽
  - 被转发5000次
  - 品牌受损

教训:
  边缘案例失败的成本 >> 常规案例成功的收益

新手用户:
  - 按教程使用
  - 遇到问题就放弃

高级用户(付费潜力大):
  - 会测试各种场景
  - 会尝试边缘案例
  - 看产品"边界"在哪里

如果边缘案例处理得好:
  → "这个产品很稳健,值得信赖"
  → 愿意付费

如果边缘案例处理得差:
  → "这个产品不成熟,不敢用于正式工作"
  → 不会付费

用户什么都不输入,直接点"生成"

普通产品:
  - 报错: "请输入内容"
  - 用户体验: 差

优秀产品:
  - 提示: "试试输入'XXX',我帮你生成一个示例"
  - 或: 自动生成一个demo
  - 用户体验: 好,还学到了怎么用

用户输入了10000字(远超预期)

普通产品:
  - 卡死或报错
  - 用户体验: 极差

优秀产品:
  - 提示: "内容较长,我会分段处理,大约需要2分钟"
  - 显示进度条
  - 分段生成结果
  - 用户体验: 好,清晰

用户输入了emoji、特殊符号、代码

普通产品:
  - 解析失败,乱码

优秀产品:
  - 自动识别并处理
  - 或友好提示: "检测到代码,要用代码模式吗?"

用户: 在"法律AI"里问"怎么做红烧肉"

普通产品:
  - 也尝试回答(结果不靠谱)
  - 或: 报错

优秀产品:
  - 识别超出领域
  - 友好提示: "我专注于法律咨询,关于烹饪建议试试XX工具"
  - 可选: 提供跳转链接

用户: 输入中英文混合的内容

普通产品:
  - 只处理一种语言
  - 或者全部乱掉

优秀产品:
  - 自动识别语言
  - 分别处理
  - 保持原有的语言风格

用户: 输入了违规/敏感内容

普通产品:
  - 直接生成(风险)
  - 或: 拒绝,但不说明原因

优秀产品:
  - 智能识别
  - 友好提示: "检测到敏感内容,已自动调整"
  - 或: "这个主题可能违规,换个话题吧?"

用户: 上传的数据缺少关键字段

普通产品:
  - 报错,不说明哪里错了
  - 用户:懵

优秀产品:
  - 具体提示: "缺少'价格'字段,请补充"
  - 提供示例: "应该长这样:..."
  - 用户:知道怎么改

用户: 上传的数据格式混乱

普通产品:
  - 解析失败

优秀产品:
  - 自动识别格式
  - 尝试智能转换
  - 转换不了的部分,具体提示

用户: 上传了100MB的文件(远超预期)

普通产品:
  - 上传失败,超时

优秀产品:
  - 预检: "文件较大,上传可能需要5分钟,继续吗?"
  - 显示上传进度
  - 分块处理

生成过程中,网络断开

普通产品:
  - 直接报错,之前的进度丢失
  - 用户:崩溃

优秀产品:
  - 检测到网络中断
  - 提示: "网络似乎断开了,已保存进度,恢复后自动继续"
  - 恢复网络后,从断点继续
  - 用户:安心

高峰期,服务器响应慢

普通产品:
  - 转圈圈,用户不知道发生了什么

优秀产品:
  - 提示: "当前使用人数较多,排队中,预计等待30秒"
  - 显示队列位置
  - 或: 提供"优先处理"的付费选项

常规测试:
  ✅ 输入正常内容,检查输出质量

边缘案例测试:
  ✅ 输入空白,看会怎样
  ✅ 输入超长内容(10000字)
  ✅ 输入特殊字符(@#$%^&*)
  ✅ 输入其他语言
  ✅ 输入敏感词
  ✅ 多次快速点击"生成"
  ✅ 生成过程中关闭页面
  ✅ 生成过程中断网
  ✅ 同时打开10个标签页
  ✅ 在手机上使用(如果是web)

1. 错误率分析
   - 哪些请求失败了?
   - 失败的原因是什么?
   - 频率如何?

2. 异常输入分析
   - 输入长度分布(找到超长输入)
   - 特殊字符使用(找到异常字符)
   - 语言分布(找到非预期语言)

3. 用户行为分析
   - 重试率(失败后重新生成的比例)
   - 放弃率(失败后直接离开的比例)
   - 修改率(生成后大量修改的比例)

4. 性能异常
   - 响应时间超过10秒的请求
   - 占用内存/CPU过高的请求
   - 触发限流的请求

定期(如每周):
  1. 导出失败/异常案例
  2. 分类整理
  3. 优先级排序
  4. 制定解决方案
  5. 更新产品
  6. 回归测试

形成闭环

1. 并发测试
   - 1000人同时使用
   - 系统会崩吗?
   - 响应时间多少?

2. 持续运行测试
   - 连续运行24小时
   - 会内存泄漏吗?
   - 会越来越慢吗?

3. 资源耗尽测试
   - 磁盘满了怎么办?
   - API配额用完了怎么办?
   - 数据库连接满了怎么办?

4. 恶意使用测试
   - 有人故意刷接口
   - 有人输入攻击代码
   - 有人绕过限制

"Error 500: Internal Server Error"
  - 用户:???什么意思?
  - 用户:是我的问题还是你的问题?
  - 用户:怎么解决?

"抱歉,我们这边出了点小问题😅
 已经记录了,工程师会尽快修复。
 你可以:
  1. 稍后重试
  2. 或者换个描述方式试试
  3. 或者联系客服(我们会优先处理)"

  - 用户:知道发生了什么
  - 用户:知道不是自己的错
  - 用户:知道下一步该怎么做

1. 人性化语言(不要技术术语)
2. 承认是产品问题(不要甩锅)
3. 提供解决方案(告诉用户怎么办)
4. 可选:加点幽默(缓解用户焦虑)

用户上传了一个100页的PDF,
包含:文字、图片、表格、公式

普通产品:
  - 尝试全部处理
  - 结果:卡死或错误百出

优秀产品:
  - 识别各部分
  - 能处理的处理(文字)
  - 不能处理的标注(图片、公式)
  - 提示: "已处理文字部分,
           图片和公式需要手动处理"

结果: 用户得到了部分价值,可以接受

100%不行,给80%
80%不行,给50%
50%不行,至少给个清晰的错误说明

不要"全有全无"

Plan A: AI生成内容

失败时的Plan B:
  - 提供模板
  - 提供示例
  - 提供人工撰写的内容

用户不会"空手而归"

Plan A: 根据用户历史推荐

失败时的Plan B:
  - 推荐热门内容
  - 推荐编辑精选
  - 推荐默认内容

总比什么都不显示好

Plan A: 实时生成

失败时的Plan B:
  - 加入队列,稍后生成
  - 降级到更简单的模型
  - 提供缓存的相似结果

给用户选择,而非直接失败

处理中......(转圈圈)
  - 用户:不知道进度
  - 用户:不知道还要多久
  - 用户:不确定是否卡死
  - 用户:焦虑

处理中(2/5)
  ✅ 数据清洗(已完成)
  ✅ 内容分析(已完成)
  🔄 内容生成(进行中,约30秒)
  ⏳ 质量检查(待处理)
  ⏳ 格式优化(待处理)

[暂停] [取消]

  - 用户:知道进度
  - 用户:知道还要多久
  - 用户:可以暂停/取消
  - 用户:安心

1. 显示进度(不要只转圈)
2. 显示步骤(让用户了解过程)
3. 显示预计时间(管理预期)
4. 提供控制权(可暂停/取消)

            影响用户多 ←→ 影响用户少
     ┌─────────────────────────────┐
高   │   P0         │      P1      │
频   │  立即修复     │   计划修复    │
度   ├─────────────────────────────┤
     │   P1         │      P2      │
低   │  计划修复     │   记录观察    │
频   └─────────────────────────────┘
度

- 高频且影响多
- 导致数据丢失
- 导致安全问题
- 导致系统崩溃

例子:
  - 支付失败
  - 数据泄露
  - 服务宕机

- 中频或影响中等
- 影响用户体验
- 有workaround

例子:
  - 某个功能偶尔失败
  - 特定场景下性能差
  - 某些输入格式不支持

- 低频且影响小
- 极少发生
- 用户可以绕过

例子:
  - 极特殊的输入导致的小问题
  - 只在特定浏览器/设备出现
  - 视觉上的小瑕疵

1. "如果用户输入空白,会怎样?"
2. "如果用户输入10000字,会怎样?"
3. "如果网络中断,会怎样?"
4. "如果用户疯狂点击,会怎样?"
5. "如果用户输入恶意代码,会怎样?"

如果答不上来,
说明没考虑边缘案例,
需要补充测试。

1. 边缘案例描述
2. 发生频率
3. 影响范围
4. 解决方案
5. 代码示例
6. 测试用例

每个新功能,都要:
  - 查阅案例库
  - 避免已知问题
  - 补充新发现的案例