支持排查本质上是研究问题，因此在响应客户挑战的过程中，最慢的一步一直都是收集合适的上下文信息。通过将代码、日志、团队知识以及历史对话整合到单个 Cursor 会话中，我们在大部分工作中都消除了这一瓶颈。

现在，超过 75% 的 Cursor 技术支持沟通都是直接在 Cursor 中完成的，使支持工程师的处理效率提升了 5–10 倍。这让支持工程师在短短一年内实现了能力上的跨越式提升。

#从代码库入手

在排查问题时，我们通常从 Ask Mode 开始。我们把问题症状告诉它，让它沿着相关的产品行为往回追踪。因为完整代码库在本地可用，Cursor 可以在同一会话中对产品代码、文档和内部工具建立索引并进行语义搜索。

这正是多根工作区发挥威力的地方。产品相关的上下文几乎总是跨越多个代码仓库。要回答用户“为什么这个按钮被禁用？”这样的问题，可能需要前端逻辑、后端策略检查，以及描述预期行为的文档。我们会把相关代码仓库放在同一个工作区中，这样的问题就能在单个对话线程中被完整回答。

#使用 MCP 集成支持来源

我们使用 MCP 服务器来获取上下文信息，并将其引入问题排查流程。支持工程师不再需要在多个工具之间来回查找相关信息，因为这些上下文已经集中在 Cursor 中。

通过 MCP 服务器，我们可以集成：

• 含有客户信息的数据库，例如订阅等级、团队设置和隐私设置
• 包含所用服务详情、遥测错误和网络问题的流式事件日志
• 像 Slack 这样的通信平台，其中的线程和对话帮助我们更全面地了解客户如何与产品交互
• 包含可能多达数十个、且各自运作方式不同团队的工程工单平台
• 包含运行手册和故障排查指南的内部文档服务
• 包含关键客户信息的账户管理服务，这些信息可能会影响你与客户沟通时的语气和方式

借助 Cursor 和 MCP 服务器，我们的支持工程师可以快速将所需信息直接引入他们的代码库排查工作中。

#确定故障发生的位置

当客户报告错误时，我们需要弄清楚：他们遇到的问题是可复现的还是偶发的，以及 Cursor 究竟是在哪一层出错的（客户端、API 边界层、下游依赖、身份验证）。Datadog MCP 允许我们将相关日志和跟踪信息直接引入到调查对话中，从而开始缩小可能的故障范围。

#查找相似案例

当有新的支持工单进来时，这个问题很可能已经被其他客户或我们团队中的某个人遇到过。一个同时与您的支持平台和 Slack 集成的 MCP，可以让我们直接在这些上下文中搜索，并将最相关的讨论线程用于当前排查。我们会优先搜索明确的标识符（错误字符串、请求 ID），在需要时再放宽范围，并寻找包含当前状态、临时解决方案以及负责人信息的最新线程。

#判断是否真的是一个 bug

很多排查最终都会回到一个问题：“是 bug 还是预期行为？”Notion MCP 让我们可以把相关的运行手册拉进对话，将其与当前情况进行对照，从而要么确认这是预期行为，要么在此基础上升级并提交一份更加清晰的 bug 报告。

#提交错误报告

当我们在 Cursor 中完成一次排查时，如果发现需要修复的问题，我们已经收集好了向工程团队提交工单所需的全部材料。Linear MCP 允许我们直接在同一条对话线程中，把所有这些上下文转换成一条已格式化的升级工单。

#文档更新

当有多个客户遇到相同的问题时，这通常表明我们需要改进文档。技术支持团队最适合直接推动此类改进。我们只需在 Slack 里提及 @Cursor 并说明需要更新的内容，云端 Agent 就会针对我们的文档仓库发起一个 PR。

#流程自动化

#常见步骤的命令

我们使用斜杠命令来处理流程中最常重复的步骤：

#针对重复模式的 Rules 和 Skills

我们使用 Rules 和 Skills 来自动化处理支持调查中的常见流程。

#子代理以并行方式执行步骤

子代理让我们在技术支持流程中并行而不是串行地运行常见步骤。

• LogInvestigator 在 Datadog 中搜索故障点及相关证据。
• KnownIssueMiner 在 Slack 和 Notion 中扫描历史讨论和已有变通方案。
• TicketWriter 将证据整理成完整的升级工单。
• CustomerReplyDrafter 撰写给客户的回复，并剔除内部细节。

这些结果会合并为一个输出，供我们审核和发送。

#原生 AI 技术支持

通过将这些工具组合使用，我们把代码级调研直接融入技术支持流程。我们估计，相比需要在不同工具和团队之间频繁切换的传统方式，这可以让我们团队的生产力最高提升一个数量级。这一效率提升让我们规模不大（但在持续扩张）的技术支持工程师团队，依然能够高效支撑快速扩张的用户群。

如果你有兴趣进一步了解如何将 Cursor 融入你的客户体验（CX）工作流，请与我们联系。