Appearance
场景1——接到一个模糊需求
场景描述
周五下午，产品经理发来消息：
"小李，有个紧急需求，用户反馈搜索不好用，
你看看怎么优化一下，下周一要上线。"就这么一句话。没有需求文档，没有具体说明。
这是典型的模糊需求场景。
你可能的第一反应是：
- 直接问"具体要做什么？"
- 或者干脆自己猜，做完再说
但两种做法都有问题。
CPERF应用
C - Capture 捕获
第一步：定义问题
"搜索不好用"是什么意思？
可能的理解：
- 搜索结果不准？
- 搜索速度慢？
- 搜索界面不好用？
- 搜索功能不够？你需要把"模糊的抱怨"转化成"清晰的问题"。
怎么问产品：
不好的问法（太开放）：
"具体要做什么？"
→ 对方可能也说不清楚
好的问法（给选项）：
"搜索不好用，我理解可能是几种情况：
1. 搜索结果不准
2. 搜索速度慢
3. 搜索交互不方便
用户反馈主要是哪方面的问题？"产品回复：
"主要是搜索结果不准，用户说搜关键词经常找不到想要的。"好，问题清晰了一点：搜索结果不准确。
但还不够具体。
继续追问：
"有没有具体的案例？比如用户搜什么关键词，期望找到什么，
实际出来的是什么？"产品回复：
"有用户说搜'苹果'，想找水果，结果出来都是手机。
还有用户说搜'运动鞋'，结果里混了很多运动服。"现在问题更清晰了：
问题定义：
搜索结果与用户意图不匹配
具体表现：
1. 关键词歧义问题（苹果→水果or手机）
2. 类目混淆问题（运动鞋→混了运动服）第二步：收集信息
需要了解的信息：
1. 现在的搜索逻辑是什么？
2. 有多少用户反馈这个问题？影响大吗？
3. 后端能不能配合改？
4. 下周一必须上线吗？能有什么范围的改动？问完之后得到：
1. 现在是纯关键词匹配，没有语义理解
2. 每天大概10条投诉，占总搜索量的0.1%，但用户反馈很强烈
3. 后端说可以配合，但大改来不及
4. 周一必须有改进，但不要求完美解决P - Process 处理
问题分类：
这是一个技术方案选择问题。
约束条件：
- 时间：3天（周五下午+周末如果需要+周一上午）
- 后端配合度：能小改，不能大改
- 期望：有改进，不要求完美分析选项：
方案A：前端加类目筛选
- 用户搜"苹果"时，提示选择"水果"还是"电子产品"
- 工作量：前端2天，后端0天
- 效果：能解决歧义问题，解决不了类目混淆
方案B：后端加搜索词纠正
- 搜"运动鞋"自动限定类目为"鞋类"
- 工作量：前端0.5天，后端2天
- 效果：能解决类目混淆，需要后端维护词库
方案C：前端加结果筛选
- 搜索结果旁边加类目筛选按钮
- 工作量：前端1天，后端0天
- 效果：用户可以自己筛，但要多点一下决策：
考虑时间约束和后端说"能小改不能大改"，选择方案A+C组合：
方案：前端类目筛选+结果筛选
理由：
1. 不依赖后端，前端可控
2. 能解决主要问题
3. 工作量可控，周日前能完成E - Express 表达
跟产品确认方案：
"我这边评估了一下，建议这样改：
1. 搜索时增加类目提示
- 当搜索词有歧义时（如'苹果'），提示用户选择类目
2. 搜索结果增加筛选
- 结果页旁边加类目筛选，用户可以进一步过滤
这个方案的优点是前端可以独立完成，周日晚上能提测。
缺点是不能完全自动解决问题，需要用户多点一下。
如果后端后续有时间，可以再做搜索词智能匹配，进一步优化。
你看这个方案行吗？"R - Review 复盘
周一上线后，追踪效果：
追踪指标：
1. 搜索相关投诉数量
2. 类目筛选使用率
3. 用户搜索后的点击率一周后数据：
结果：
- 投诉从每天10条降到3条
- 类目筛选使用率15%
- 搜索点击率提升了5%复盘：
- 方案有效，投诉减少了70%
- 但还有3条投诉，说明问题没有完全解决
- 后续可以做搜索词智能匹配进一步优化F - Form 固化
经验记录：
1. 遇到模糊需求，先拆解可能的问题类型，再和产品确认
2. 技术方案要考虑时间和配合度约束
3. "不完美但能解决主要问题"的方案比"完美但来不及"的方案更好关键要点
要点1：把模糊需求转化成清晰问题
模糊的抱怨 → 具体的问题 → 可执行的方案
"搜索不好用"
→ "搜索结果与用户意图不匹配"
→ "关键词歧义+类目混淆"
→ "前端加类目筛选+结果筛选"要点2：问问题要给选项
❌ "具体要做什么？"（太开放）
✅ "我理解可能是这几种情况，主要是哪个？"（给选项）给选项的好处：
- 对方更容易回答
- 能快速确认方向
- 显示你有思考
要点3：约束条件决定方案
时间约束：3天
资源约束：后端不能大改
期望约束：有改进，不要求完美
这些约束条件直接影响方案选择。
在约束条件内找最优解，而不是找理论上的最优解。要点4：先做能做的，再迭代
第一版：前端筛选，3天上线，解决70%问题
后续版本：后端智能匹配，解决剩余30%问题
不要追求一步到位，先解决主要问题。本场景的CPERF检查清单
markdown
□ Capture
- 把模糊需求拆解成具体问题了吗？
- 有具体案例支撑吗？
- 约束条件（时间、资源、期望）明确了吗？
□ Process
- 列出了可行的方案选项吗？
- 根据约束条件选择了合适的方案吗？
- 方案和对方确认了吗？
□ Express
- 向产品清晰表达了方案和理由吗？
- 说明了方案的优缺点吗？
- 提到了后续迭代的可能吗？
□ Review
- 上线后追踪效果了吗？
- 验证方案是否有效了吗？
- 记录了改进点吗？
□ Form
- 总结了可复用的经验吗？
- 更新了个人的处理模式吗？小结
模糊需求是最常见的场景之一。
核心方法：
- 先把模糊的抱怨转化成清晰的问题
- 收集约束条件（时间、资源、期望）
- 在约束条件内选择最优方案
- 先做能做的，后续再迭代
下一章，我们看另一个常见场景：排查线上Bug。