research

详细介绍

研究

针对用户指定的产品，开展新一轮 UX 研究扫描。

聚焦当前有证据支持的用户问题。优先关注已登录的产品体验、自助流程、入门引导、文档/帮助、开发者体验、支持服务中的阻碍以及产品工作流。

关键覆盖规则

继续之前，请先参阅插件路由器 $index。
遵循 $critical-overrides。

用户上下文

开始之前，加载 $user-context，并在本地 shell 可用时运行其预检脚本。

在相关情况下，使用已保存的产品 URL、Figma 文件、截图、参考图片、代码库路径、Storybook、设计令牌、设计系统、品牌素材、组件参考、浏览器偏好和共享目标作为背景材料。

不要检查所有已保存的参考资料。只检查当前任务所需的内容。

约定

开始扫描之前，重述产品、受众、时间范围和研究范围。
默认使用公开来源。如果连接器可用且用户请求允许，则使用内部来源。
尽可能引用来源。
区分观察到的证据与推断。
不要根据个别案例夸大结论。
不要只罗列投诉。讲清楚产品故事。
明确说明来源缺失或薄弱之处。

工作流程

重述研究范围。
搜索公开来源：

Reddit
X/Twitter
Hacker News
Stack Overflow
GitHub issues/discussions
相关论坛、博客、评论、YouTube 评论和开发者社区

在可用时搜索内部来源：

Slack
Gong
Notion
Google Drive/docs
Linear/Jira/GitHub
可用的支持或 CRM 笔记

将证据归类为信号最强的 UX 问题。
区分：

产品 UI/工作流阻碍
文档/帮助阻碍
入门引导阻碍
账户、计费、权限或设置阻碍
开发者/API/SDK 阻碍
可靠性/性能问题
功能请求

按严重程度、频率、置信度和产品杠杆效应对问题排序。
讲清楚产品故事。

输出

默认在聊天中提供研究简报，除非用户要求其他格式。

包含：

执行摘要：用 5-7 句话概述核心故事。
排序后的 UX 问题：每个问题均包含问题、用户目标、涉及界面、故障点、证据、严重程度、频率信号、置信度和推荐的产品举措。
来源概览：搜索了哪些来源、各来源提供了什么，以及哪些地方的信号较弱。
机会概览：将建议分为本周修复、本季度修复和需要深入研究。

规则

尽可能引用来源。
不要根据个别案例夸大结论。
区分引人注目的投诉与频繁发生的问题。
区分 UX 阻碍与功能缺失。
区分可靠性/性能问题与 UX 工作流问题。
将仅限内部的证据与公开证据分开标注。
保持简报精炼、具体、易于阅读。