https://t.co/RBJVbKTj3b
TL;DR · AI 摘要
通过构建自动化代理处理产品反馈,团队效率提升6倍,节省90%重复工作时间。
核心要点
- 使用Cosmos平台构建的Feedback Triager代理可处理90%的重复性反馈工作
- 60个反馈线程中50%在报告后立即启动修复方案
- 自动化流程使团队无需扩大规模即可处理30+周反馈量
结构提纲
按章节快速跳转。
思维导图
用一张图看清主题之间的关系。
查看大纲文本(无障碍 / 无 JS 友好)
- 自动化反馈处理
- 问题背景
- 反馈量激增至30+/周
- 解决方案
- Feedback Triager代理
- 根因分析
- 工单创建
- 修复执行
- 实施效果
- 效率提升6倍
金句 / Highlights
值得收藏与分享的关键句。
60个反馈线程处理中50%在报告后立即启动修复方案
自动化流程使团队处理能力提升6倍,节省90%重复工作时间
Feedback Triager代理系统可自动路由反馈、创建工单并执行修复
Augment Code on X: "https://t.co/RBJVbKTj3b" / X
@augmentcode
$
我们如何构建软件工厂来处理6倍增长的产品反馈
TL;DR
随着我们由两名工程师组成的Cosmos顾问团队向更多客户交付更多自动化功能,每周的产品反馈量迅速增长,达到每周30多个反馈线程。调查问题、复现缺陷、查找负责人、提交工单以及部署修复方案开始消耗我们约90%的时间。我们的产品路线图几乎陷入停滞。
我们没有立即扩大团队规模,而是通过Cosmos构建了一个反馈分类专家(即智能体)。该系统会跟踪每个Slack报告的完整生命周期:收集证据、执行根本原因分析(RCA)、回答问题、将反馈路由到其他渠道、创建工单,并在修复方案明确时将问题转交给PR作者专家(即智能体)。人类保留产品判断和优先级决策;智能体负责围绕这些决策的重复性调查和执行。
结果是一个规模较小的团队,可以在不将产品路线图变成支持队列的情况下保持对客户的响应能力。
成功带来了新的瓶颈
由两名工程师组成的Cosmos顾问团队负责在代码托管平台、工单跟踪系统和协作平台中构建开箱即用的自动化功能和顾问体验。这包括GitHub、GitLab、Slack、Microsoft Teams、Jira等平台上的代码审查、事件响应、反馈分类和大型工程项目的相关工作流程。
随着功能集和客户群的扩展,反馈量激增。成功带来了新的瓶颈:我们交付得越快,就越需要花费时间维护已构建的功能。
报告通过专属于我们团队的Slack反馈频道送达。它们来自:
- 市场推广(GTM)团队传递的外部客户反馈
- 内部团队对新旧功能的内部使用测试
在最近的两周内,我们处理了60个产品反馈线程,平均每周30个,相比仅几周前的每周约5个:
- 这60个线程中,50%在报告后不久就已修复或有明确的修复方案在进行中。
问题不仅仅是Slack消息的数量。每个报告可能需要阅读线程、复现行为、搜索代码和文档、检查日志、查找相关工单、决定负责人、回答后续问题,有时还需要编写修复方案。
在高峰期,我们估计这些工作消耗了团队约90%的时间。我们保持了响应能力,但长期工作的执行开始停滞。
招聘是其中一个选项,但大部分工作负载是重复的上下文重建,而非产品判断。我们希望智能体承担调查和常规执行工作,而工程师保留优先级决策和产品判断。
我们的反馈循环是如何运作的——从报告到解决
我们团队反馈频道中的每个新根消息都会启动一个长期运行的反馈分类会话。该会话在其生命周期内拥有该线程,因此可以在每次交互时整合回复、更正、编辑和新证据,而无需每次重建对话。
- 接收
分类器阅读报告和相关上下文,确认接收,并确定需要的信息。当缺少关键事实时,最多提出一个有针对性的澄清问题。
- 调查
- 行动
下一步行动取决于证据:
清晰且范围明确的修复不应等待下一个规划周期;模糊的问题和功能请求应提交至 Linear 进行优先级排序和深入处理。
如何使反馈分类有效
背景:Triager 可访问工程师使用的仓库、文档、工单历史、Slack 线程、日志和指标。没有这些输入时,代理可以总结报告;拥有这些输入时,它可以进行调查。
定制化:每个团队可自定义分类、路由、工单、证据和沟通规则,使 Triager 能反映团队的实际运作方式。
证据规范:Triager 独立验证报告者的诊断,并在证据指向不同原因、负责人或严重程度时明确说明。
人工参与:人工工作量小且聚焦于高价值任务:基于 RCA 和支持证据做出决策。一旦人工选择路径,代理即可处理常规执行任务,例如创建工单或启动 PR 作者。
记忆:对分类、路由、去重或响应行为的修正会转化为明确的渠道特定规则,使未来的分类更加一致。
反馈分类需要软件工厂
反馈分类器可以比人工队列更快生成可操作的工作。如果下游工程系统无法吸收这些工作,代码审查和验证将成为新的瓶颈。
因此,我们的反馈循环连接了多个 Cosmos 专家:
反馈分类器调查报告并选择下一步行动。
PR 作者实施明确且已批准的修复。
代码审查专家检查变更并推动 PR 合并流程直至解决。
验证者端到端地验证行为。
人类负责产品决策、优先级排序和生产风险决策。
目标不是优化单个步骤,而是缩短从产品反馈到验证结果的完整循环。相同的软件工厂还支持大型工程项目和事件响应。
最终状态:反馈规模扩大而无需扩大团队
我们目前对运营模式感到满意。目前两人团队约30%的时间用于反馈处理(此前估计为90%),我们的主要关注点已重新回到长期路线图。
我们不再需要仅为了跟上反馈而扩大团队。随着我们创建更多功能,反馈分类器将扩展我们的能力以调查和路由产生的反馈,而 PR 作者、代码审查和验证专家则吸收下游的修复工作。
其他早期经验:
最佳的分类结果通常是不创建工单。问题、已知限制、重复项和偶发故障不应增加待办事项。
模糊性应属于规划范畴,而非推测性代码。开放性问题需要优先级排序和深入调查。
如何采用此工作流程
请让 Cosmos Advisor 为您的团队配置反馈分类员。通过标准的协作和工单系统——Slack 或 Microsoft Teams 配合 Jira、Linear、GitHub Issues 或 GitLab Issues,Advisor 可以自主配置专家角色、集成方案、触发条件和路由流程。
从一个团队和一个反馈渠道开始。Advisor 将连接代码库、追踪系统和证据来源;配置回答规则、路由规则、去重规则和归档规则;选择人工审批级别;并连接下游的审核和验证流程。首先测量基准线,随后随着流程被验证为可靠,逐步扩大权限范围。
目标不是创建更多工单或 PR。而是让每条产品反馈线都能以更少的重复人工操作达到正确的结果——使小团队能够支持不断增长的产品,并持续构建下一步的内容。
为产品反馈构建您自己的软件工厂
Cosmos 为工程团队提供了共享上下文、运行时控制、集成方案和人工检查点,用于分类反馈、调查根本原因,并将其路由到正确的结果。
尝试 Cosmos
最初发布于 @augmentcode 博客。作者:@AkshayUtture001.
/$
9:37 PM · Sep 1, 2026
424
浏览量
1
7
10