给 Cursor 报 bug 要带哪些信息：官方文档写明的八项材料与获取方式

2026-08-18

现象：帖子发出去了，然后就没有然后了

一个很典型的场景：Agent 改崩了一个文件，或者某次对话中途报错，你去 forum.cursor.com 发了一帖，写了两句「Agent 表现异常，谁遇到过」，然后石沉大海。过几天你自己都想不起来当时的上下文了。

这类情况里有一部分确实是别人也没辙，但还有相当一部分是对方根本没有可查的东西。Cursor 闭源，能不能被定位完全取决于你交的材料够不够对方在他们的系统里把这次请求捞出来。官方帮助文档专门有一页讲这件事（cursor.com/help/troubleshooting/reporting-bugs），把要附的材料列成了清单。这篇把那份清单逐项摊开，顺带把每项在不同系统上的获取路径对齐一下——文档里有几处口径不一致，第一次照着做很容易卡住。

第一步：怎么确认问题出在「材料不全」

判定动作很直接：把你已经发出去的那条反馈拿出来，对着官方那一页的清单逐项打勾。官方文档写明要包含的是这八项：

材料	官方文档写明的获取方式
Cursor version	菜单栏 Cursor > About Cursor
Operating system	Mac、Windows 或 Linux，附上系统版本
Steps to reproduce	出问题之前你做了什么
Expected behavior	你预期会发生什么
Actual behavior	实际发生了什么
Screenshots or screen recordings	问题是视觉上的就附截图或录屏
Request ID	见下文的取法
Console errors	Help > Toggle Developer Tools 里查看是否有报错

上面这张表整列都照抄自官方那一页，包括菜单路径的写法。八项这个数是回源数出来的，不是约数。

打完勾你大概率会发现两件事：一是 Request ID 压根没给，二是「Steps to reproduce / Expected / Actual」三项被合并成了一句「它坏了」。这两项缺失的杀伤力最大——前者让对方无法在后端定位到你那一次请求，后者让对方无法判断你说的「异常」到底是模型输出不符合预期，还是产品本身报错。

还有一个判定动作是查你自己的隐私设置。官方文档写明 Privacy Mode 是按请求生效的（per-request），改设置不会追溯影响之前的请求，每次请求按提交那一刻生效的隐私模式记录。所以设置状态直接决定了对方能看到什么，这一条下面单独讲。

第二步：文档写明的处置——每一项材料怎么取

版本号：Mac 和 Windows/Linux 的路径在文档里不一样

《Reporting a bug》那一页写的是菜单栏 Cursor > About Cursor。但同站的 Agent 排查页（cursor.com/help/troubleshooting/agent-issues）在讲怎么报一次糟糕的 Agent 回复时，写得更细：系统信息在 macOS 上是 Cursor > About Cursor，在 Windows/Linux 上是 Help > About。

两页的差别在于前一页只给了 Mac 的写法。如果你在 Windows 或 Linux 上，照着第一页去菜单栏找 Cursor 菜单会对不上，按 Agent 排查页写的 Help > About 走即可。这两处都是官方文档白纸黑字写明的路径，我们没有装过这个产品，界面长什么样不做任何描述。

Request ID：文档给了明确的四步

官方文档写明的取法是：

在 Chat 侧栏打开相关的那次对话
打开上下文菜单（”…” 菜单）
选择 Copy Request ID
把这个 ID 发到论坛或邮件里

Agent 排查页写的位置略有不同——它写的是点回复底部的 … 菜单里的 Copy Request ID。两页说的都是同一个动作，按你实际能找到的那个菜单走。

文档对 Request ID 的定义是：每次你向 Cursor 发起请求都会生成的唯一标识，作用是让支持团队在内部系统里定位到你这一次请求。文档还写明这类 ID 只在 Cursor 后端内部有意义，是查询用的键，在他们系统之外没有价值，因此不需要当作机密对待。这句是文档原话的意思，不是我们的安全建议——你自己那边的合规要求怎么定，还是按你所在组织的规矩来。

Console errors：Toggle Developer Tools

官方文档写明走 Help > Toggle Developer Tools 查看是否有报错，文档对这一项只写了这一句，没有说明它适用于哪类问题、也没有给出报错的解读口径。需要点明的只有一条关系：这一项和版本号、系统版本、复现步骤一样，是你自己抄进帖子里的内容；而下面要讲的隐私设置管的是「对方在他们后端能看到什么」。两者是两条独立的路径，别把它们混在一起判断。

一类特殊情况：Agent 初始化失败要交的是导出日志

如果你遇到的是 Agent Execution Timed Out 这个报错，官方 Agent 排查页给的不是上面那套，而是另一套材料。文档写明这个报错的含义是 Cursor 的扩展宿主没能在规定时间内完成启动，导致 Agent 功能无法初始化；同一个根因在网络诊断里会表现为 Timeout waiting for EverythingProvider。文档明确要求先收集日志再动手改任何东西：

按 Cmd/Ctrl+Shift+P，运行 Developer: Export Logs…
选择 Main、Window 和 Extension Host 三项
另外查看 Output → Extension Host（Cmd/Ctrl+Shift+P → “Output”，然后在下拉里选 “Extension Host”）。文档写明如果这个面板是空的，就截图——空面板本身是一个很强的诊断信号
把导出的 zip 和截图连同你的操作系统与 Cursor 版本一起发给支持

Windows/Linux 用户注意第一步的快捷键是 Ctrl 系，Mac 是 Cmd 系，文档用的是 Cmd/Ctrl 合写。这一段还提到在受管控或企业机器上，端点安全软件（杀软、EDR）是可能原因之一，若 IT 确认有安全代理在跑，可以把官方的 Endpoint Security Configuration 页给他们做进程与路径排除。

第三步：Privacy Mode 决定了对方能看见什么

这是整件事里最容易踩的坑，也是「补交材料」经常无效的原因。

官方文档把两种设置下支持团队能看到的内容分别列了出来。Privacy Mode 开启时，团队只能看到：用了哪个模型；是否发生了工具失败（但看不到是哪个工具失败）；以及与你的 prompt、代码、Agent 动作无关的后端故障。Share Data 开启时，团队能看到：你与 Agent 的完整对话；工具调用，包括哪些调用失败的细节；以及提供给 Agent 的上下文（system prompt、rules、git status）。

两侧各三条，都是照抄文档的分项。文档由此给出的结论是：涉及 Agent 行为的问题，在没有 Share Data 的情况下很难还原发生了什么；而连接类问题通常在 Privacy Mode 开启时也能排查，因为这类问题不需要看你的代码和对话内容。

关键在于按请求生效这条语义。文档写明改隐私设置不会追溯影响之前的请求，每次请求按提交时生效的模式记录；如果问题发生时你开着 Privacy Mode，事后切到 Share Data 并不会让团队看到当初那一次请求。所以官方给 Agent 行为异常问题的流程是重现一次，而不是补交：

在隐私设置里临时开启 Share Data
用同样的操作重现问题
用上下文菜单复制新的 Request ID
通过论坛或邮件把 Request ID 发出去
如果需要，再切回 Privacy Mode

隐私设置的位置在官方隐私页（cursor.com/help/security-and-privacy/privacy）里写明：Mac 按 Cmd + Shift + J、Windows/Linux 按 Ctrl + Shift + J 打开 Cursor Settings，侧栏点 General，然后切换 Privacy Mode。同一页还写明团队场景下 Privacy Mode 对所有成员默认开启，管理员可以在 cursor.com/dashboard 全组织强制启用，成员无法自行关闭——如果你在这样的组织里，第 1 步就走不通，只能带着 Privacy Mode 下能看到的那三类信息去报，并在帖子里说明这一点。

顺带一提，官方的 Shared transcripts 可以把对话生成只读链接分享出去，但文档写明它只在 Teams 与 Enterprise 计划上可用，且分享前对已知密钥模式的脱敏是尽力而为、不保证脱干净。拿它当附件之前自己先通读一遍。

第四步：材料交齐了怎么验证

没有回执可以查，只能自查。落到可执行的动作是三条：

把上面那张八项表逐行对回你的帖子，缺哪项补哪项，「不适用」的也写一句「不适用」，比留空好；
确认你贴的 Request ID 是问题发生那一次的，不是后来随手复制的另一次对话——按请求生效的规则下，贴错一次等于没贴；
如果是 Agent 行为类问题，确认你贴的那次请求是在 Share Data 开启状态下提交的，否则对方看到的仍然只有模型名和「有工具失败」这种粒度。

按官方那八项排一个自用模板，发帖时照着填就不会漏（这是我们按官方清单排的自用模板，不是官方提供的模板格式）：

Cursor version:
Operating system (含版本):
Steps to reproduce:
Expected behavior:
Actual behavior:
Screenshots / screen recordings:
Request ID:
Console errors (Help > Toggle Developer Tools):
Privacy setting at the time of the request: Privacy Mode / Share Data

最后一行不在官方八项里，是我们加的：既然隐私模式按请求生效，直接写明当时的状态能省掉一轮来回。

第五步：什么情况说明问题不在材料上

材料齐了仍然没进展，或者一开始就不该走报 bug 这条路，通常是这几种：

它不是 bug，是文件没被拿到。 官方 Agent 排查页给的路径是先查项目根目录的 .cursorignore，列在里面的文件会被挡在 Agent、代码库搜索和 @ 提及之外；再查 .gitignore，那里的模式同样可能让 Agent 发现不了文件；然后在命令面板里搜 “Reindex” 重新索引；也可以在输入框里用 @ 直接附上文件。这条链走完还不行，再考虑报 bug。
它是网络或代理问题。 官方网络页写明可以在 Cursor Settings > Network 点 Run Diagnostics 跑连通性诊断；文档还写明 Cursor 用 HTTP/2 做流式响应，某些企业代理会拦 HTTP/2，可在同一处把 HTTP Compatibility Mode 设为 HTTP/1.1 后重启。这类问题按文档说法在 Privacy Mode 下也能排查，不必为它切 Share Data。
它是卡顿或占用高。 官方性能页给的方向是扩展与设置，命令行可以用 cursor --disable-extensions 起一个不带扩展的实例来对照，再逐个开回来定位；大体积生成目录加进 .cursorignore。这类现象交 Request ID 用处不大。
它是启动就白屏。 官方安装排查页写明先退出重启，Windows 上试试以管理员身份运行，命令面板里跑 Clear Editor History 重置缓存状态。
问题发生时你开着 Privacy Mode，且已经无法重现。 这种情况下没有任何补救动作能把当初那次请求的可见性找回来，只能等下次复发时按 Share Data 流程重来一遍。这不是材料不全，是时间窗过了。

还有一种情况是问题本身与 Agent 的输出质量有关而不是产品报错。这类反馈交 Request ID 依然有意义，但期望值要放低——文档只写了支持团队能据此定位请求并调查出了什么问题，没有写明会得到什么形式的答复。

最后一句限定：这个产品迭代频繁，上面的菜单名、设置项与命令都随版本变动，请以官方文档最新内容为准。

本文依据 Cursor 官方文档（cursor.com/docs 与 cursor.com/help）于 2026-08-18 的公开内容整理。该产品闭源，本文只复述官方文档写明的机制，不推断其内部实现； 我们没有对文中涉及的功能做过实测，因此不涉及界面外观、操作手感与运行速度的任何描述。该产品迭代频繁，文中涉及的设置项与命令随版本变动，请以官方文档最新内容为准。本文不涉及订阅价格、额度与模型清单，相关信息请以官方定价与模型说明页为准。

安全与合规相关做法请结合自身环境评估，本文不构成安全方案建议。