产品体验问题排查

这类问题为什么难对齐

产品/体验反馈往往和开发报错混在一起：同事说「按钮没反应」「和设计稿对不上」「PRD 写的是 X 线上是 Y」，大家还没统一现象、预期和影响范围就开始改代码或改文档，最后发现其实是理解偏差或文档缺口。

本技能把对话约束在体验侧 issue triage：先搞清楚再动手，默认不抢着改代码、不写文件。

技能如何工作

触发后按固定五段输出，每段控制在 3～6 行，适合一屏读完：

1. 问题复述：现象、预期、影响范围；缺信息则列「待确认问题」反问，不硬编。
2. 复现路径：从入口到问题的最短点击路径，不全则标 待确认。
3. 问题归类（核心交付）：三选一——设计问题（PRD/稿缺陷或未覆盖）、实现问题（文档对但实现是 Y）、预期问题（文档与实现一致但反馈方期待不同）；必须给出结论与一句依据，信息不足则说明还需什么。
4. 根因假设：最多 3 条，按可能性排序，格式为「假设 → 验证方式」（看哪段代码、哪份文档、如何复现）。
5. 下一步动作：≤3 条，面向产品/反馈方（验证假设、对齐文档、决定改设计还是改实现），不写实现细节。

工作流约定包括：复述保留用户原话关键词；未知标待确认；遇到「为什么会这样」「怎么改」或模糊描述（如「不太对劲」）时，先归类或反问再继续。

适用边界

• 适用：功能表现与预期不符、路径走不通、与稿/PRD 不一致、交互「感觉不对」等体验问题。
• 不适用：纯技术栈报错、堆栈、构建失败等开发调试场景（应走排错类技能）。
• 不要期待：直接给出修哪行代码、系统性体验审计，或在未看文档/代码时断言实现问题（除非用户已明确说明）。