我们是如何构建一个将客户反馈转化为已发布修复的智能体的

证据等级：A1 证据类型：官方一手信息 来源：Brex Engineering Blog 官方发布日期：2026-06-22 采集时间：2026-07-16T20:29:56.142Z

大多数产品设计师都了解这一现实。看似“微小”的产品工作，例如令人困惑的空状态、陈旧的工具提示或在模态窗口中无法使用的键盘快捷键，往往会被优先度较高的、更吸引人的项目所取代。随着时间的推移，这些小问题会累积，从而开始影响产品的整体体验。

产品反馈无处不在：NPS 调查、支持对话、客户电话、Slack 讨论线程、调研访谈。这些信号以截然不同的格式出现，分散在彼此不相通的工具中。作为一名设计师，我花了大量时间观察客户反馈中的模式，提交工单，并推动问题修复。你收到的反馈越多，漏掉的就越多——没有任何一个人（或团队）可以同时无处不在。

所以我们建立了一个系统，可以自动完成这一过程，从随意的评论到已发布的修复，仅需几天，完全免手动操作。以下是我们的做法。

我们构建的内容

我们建立了一个工作流程，可以在不削弱保持高质量的人类判断的前提下，减少识别、分类和修复小型产品摩擦的人工成本。

在内部，我们称之为“小而重要的细节”，这是以[我最喜欢的设计Tumblr之一]（https://littlebigdetails.com/）亲切命名的。

“小而重要的细节”系统连接到客户反馈、NPS调查、内部对话和用户研究洞察所在的各种地方。在我们的案例中，这些包括：

• Linear（问题和项目跟踪）
• Slack（内部和客户反馈渠道）
• Granola（通话记录）
• Glean（内部文档和研究，以及连接到各种其他来源的门户）
• 很好的问题（用户研究访谈和调查）
• BuildBetter（用户研究访谈和汇总客户反馈）

它会跨所有数据进行读取，发现隐藏在显而易见处的小改进和生活质量机会，验证它们是否仍然相关，并将其作为一个动态待办事项来管理。当需要修复某些问题时，它会打开一个草稿拉取请求，附上建议的解决方案供人类审核。

如果你的团队使用 Jira、Zendesk、Intercom、Notion、Dovetail 或任何其他有可用 MCP 的工具，同样的方法也适用。MCP 是一个标准接口，因此交换数据源很简单。团队已经用来生成反馈的任何工具都可以成为输入来源。

结果：以前需要数周才能显现、优先处理并采取行动的反馈，现在可以在几天内从一个随意的评论变成发布的修复。在我们运行系统的前两天，它发现了71个真实候选问题，其中33个（还在增长中）已经发布、正在审核或处理中。

它的工作原理：三个智能体，一个流程

工作流程被分为三个智能体，每个智能体都有不同的工作。以这种方式分离关注点可以让每个智能体更高效：任务范围更窄意味着指令更加集中，效果更好，而且当需要调整时更容易调试。

智能体 1：挖掘（从噪声中找到信号）

The Mine 智能体负责发现工作。它会系统地扫描所有连接的来源（Linear 工单、Slack 频道、客户通话记录、内部研究文档等），寻找关于小型前端摩擦的提及。

它不仅仅做关键词搜索。它利用语言模型读取_意图_的能力，将真正的优化机会与错误报告、功能请求或背景噪音区分开来。“按钮很难找到”与“按钮坏了”是不同的，智能体能够区分它们。

每次扫描时，它会执行以下操作：

• 广泛搜索各类来源，使用配置好的关键词模式和与摩擦相关的语言（例如“烦人”，“每次我都必须”，“为什么它不能直接…”）
• 在处理之前去除个人可识别信息，以确保隐私和合规性。
• 将发现的内容规范化为基础摩擦的标准描述，这样跨来源以不同方式描述的同一问题会被识别为一个问题，而不是三个。
• 去重已跟踪的所有内容，这样同一问题不会生成五个工单。

/bootstrap 命令会对六个月的历史进行初始深度扫描，非常适合首次设置系统和建立初始积压任务。

智能体 2：综合（在控制信噪比的同时）

一旦 Mine 识别出一大批潜在候选项，Synthesize 智能体会进行严格验证，以确保只有真正可交付的机会才能通过。如果没有这一步，待办事项堆积很快会充满噪音，整个系统也会失去信任。

该过滤器根据六个严格的标准评估每个候选项：

1. 仅前端：无需后端更改、API 修改或模式更新
2. 低风险：影响范围小，如果出现问题易于回滚
3. 高频或高摩擦：交互要么发生频繁，要么痛点明显，以至于人们会明确抱怨
4. 多来源证据：至少由两个独立来源确认（单个渠道的一个提及是不够的）
5. 两天或更短时间可交付：范围足够紧凑，一个人可以快速完成
6. 仅改变现有行为：改进用户已经在做的事情，从不偷偷添加新功能

智能体还会检查 Linear 以确认问题是否已经被跟踪，并在代码库中验证摩擦点仍然存在（捕捉那些最近版本已经修复或因产品变化而变得无关的事项）。

符合条件的内容会被写入一个专用的 Linear 项目，并附上丰富的元数据：

• 规范化（标准化）的问题描述
• 所有来源证据已关联
• 基于新近性和频率的优先级评分
• 一个独特的指纹，有助于未来的 Mine 运行了解已经看到的内容及其状态（该指纹是去重键；它是系统在多次运行中保持连续性而不创建重复项或丢失不断变化的上下文的方式）
• 修复者的用户体验考虑（例如，值得思考的边缘情况）

每张票据底部都包含一个可机器读取的元数据块，大致如下:

这是智能体在后续运行中阅读的内容，以了解它们已经看到过什么、哪些来源做出了贡献，以及问题首次和最后一次被观察到的时间。对于任何处理待办事项的人来说，这些都是不可见的，但它是保持系统随时间保持一致性的连接组织。

这种选择性是经过设计的。 我们宁愿错过一些候选项，也不愿让队列充斥噪音。严格的筛选会建立信任；宽松的筛选会产生繁琐的工作。

智能体 3: 修复（从工单到拉取请求）

这是提出解决方案的智能体。它从待办事项中读取一个合格的问题，理解问题，找到相关代码，并以建议修复的形式创建一个草稿拉取请求。

它可以以三种模式运行：

• 定时：自动按您选择的间隔挑选一个问题，持续不断地进行改进
• 创建时：当新的问题进入待办事项时立即执行（更快，但噪声更大）
• 手动 (/pick)：由您自己触发，它将选择未处理的最高优先级问题。就像产品优化的“我很幸运”按钮。

这个修复智能体结合了两件让这类工作非常适合大型语言模型的事情：它可以读取反馈背后的_意图_（用户实际希望发生的事情），并且可以编写处理该意图的代码。所以它不仅仅是定位问题，而是提出一个基于用户挫败感和实际代码库的解决方案。

保持质量标准

“所以……实际上只是快速运送有情节暗示的烂片吗？”

不完全是。我们没有做的是：将人类从重要决策中移除。

智能体建议的修复方案本身可能完全可以直接发布（有时确实如此），但我们总是希望由人工审核者来做出这个决定。一个修复方案在技术上可能是正确的，但仍可能缺失关键的业务背景，未达到设计质量标准。

人工审查员会看到所提议的修复，并决定：按原样发布、调整后发布，或关闭它。关于修复应该_感觉_如何、某个交互是有帮助还是令人烦恼、文案是清晰还是居高临下的判断，完全由人类来做出。

在这个工作流程中，我们将人的角色进一步下移在流程中。审查员不是从书面工单开始从零做起，而是查看一个已经构建好的解决方案。在这种情况下，拉取请求本身就是工单。人类仍然负责所有质量判断，但他们跳过了最耗时的阶段：构建和上下文收集阶段。

更广泛的启示

虽然我们具体的例子集中在前端优化上，但如果你以输入和输出的角度来看，它的思路可以应用于许多用例。

把它想象成一条装配线：一个智能体的输出成为下一个智能体的输入。矿工智能体的输出传给合成器，合成器的输出传给修正，再依此类推。每个站点只做一件专注的事情，然后把结果传递下去。原料（零散的反馈）从一端进入；成品（已发布的修正）从另一端出来。就像真正的装配线一样，你可以独立调节或更换任何一个站点，而无需重新设计整个系统。一旦你开始这样思考，就可以用简单、专注的步骤组合出惊人复杂的工作流程。

输入： 您可以使用哪些数据来源？文档、调查、记录、Slack 消息、分析、支持票据，通过 MCP 连接。

输出: 一个LLM智能体能从这些输入中推导出哪些传统的基于规则的自动化无法做到的，或者做得不如它强大？

在我们的案例中，LLM为我们提供了两个显著的优势：

1. 跨上下文的语义理解。 它能够识别出在两个不同工具中用完全不同措辞的投诉其实描述的是同一个摩擦点。不是关键词匹配，而是_意义_匹配。
2. 基于用户意图的代码生成。 它可以根据自然语言描述的痛点，提出具体的代码修复方案，从而解决问题，并参考现有代码库的模式、既定最佳实践和设计系统。

传统的自动化可以搜索关键词，但它无法理解“我总是得向上滚动”和“页面不会记住我停留的位置”是同一个问题。它可以提交一个工单，但它无法编写解决方案。

同样的模式（收集多来源信号、进行规范化、严格过滤、对幸存的信号采取行动）适用于任何有用信息散布在太多地方而单个人无法整合的情况。

构建类似工具的手段比以往任何时候都更容易被更多人获取。你不必在工程团队中。你需要一个值得解决的问题、值得连接的数据源，以及愿意对能够通过的信息进行高度选择的态度。