我们如何构建一个软件工厂来处理6倍的产品反馈
用Cosmos构建反馈分诊代理，将工程师从90%的反馈处理时间中解放，降至30%，实现小团队规模化支撑产品增长。
概要
随着我们两位工程师组成的 Cosmos 顾问团队向更多客户交付更多自动化功能，每周的产品反馈迅速增长——达到每周 30 多个反馈线程。调查问题、复现故障、寻找负责人、提交工单以及修复问题，开始消耗我们约 90% 的时间。我们的路线图几乎停滞不前。
我们没有立即扩充团队，而是利用 Cosmos 构建了一个反馈分诊专家（即代理）。它跟踪每条 Slack 报告的完整生命周期：收集证据、执行根本原因分析（RCA）、回答问题、将反馈路由到其他渠道、创建工单，并在修复方案明确时，将问题交给 PR 作者专家（即代理）。人类保留产品判断和优先级决策；代理则负责围绕这些决策进行重复性的调查和执行。
结果是，一个小团队能够保持对客户的快速响应，而不会将路线图变成支持队列。
成功催生了新的瓶颈
由两名工程师组成的 Cosmos Advisor 团队，在代码托管平台、工单追踪器和协作平台上，打造开箱即用的自动化及 Advisor 体验。这涵盖了代码审查、事件响应、反馈分类以及跨 GitHub、GitLab、Slack、Microsoft Teams、Jira 等平台的大型工程项目的工作流程。
随着功能集和客户群的扩大，反馈量激增。成功带来了新的瓶颈：我们发布得越快，花在支持已有功能上的时间就越多。
报告会发送到我们团队专用的 Slack 反馈频道。这些反馈来自：
- 市场推广（GTM）团队转达的外部客户反馈
- 内部团队对新旧功能的内部试用反馈
在最近的两周内，我们处理了 60 条产品反馈线程——平均每周 30 条，而几周前每周仅约 5 条：
| 类型 | 典型示例 | 线程占比 |
|---|---|---|
| 功能请求 | 客户需要新的工作流程或配置选项。 | 8.33% |
| 平台支持 | 工作流程在 GitLab、Azure DevOps、Teams 或 Jira 上表现不同——这些平台我们无法像主要技术栈那样深入试用。 | 8.33% |
| 生产环境缺陷 | 已发布的工作流程在客户环境中失败或出现意外行为。 | 6.67% |
| 发布前反馈 | 内部试用在客户遇到问题之前，发现了新自动化中的缺陷。 | 68.34% |
| 其他产品反馈 | 内部发布后的缺陷、正面反馈或更广泛的产品问题。 | 8.33% |
| 总计 | 100.00% |
在这 60 条线程中，50% 在报告后不久即已修复或已有具体的修复方案在推进中。
问题并不只是Slack消息的数量。每份报告可能都需要阅读整个讨论串、复现行为、搜索代码和文档、检查日志、查找相关工单、确定归属、回答后续问题，有时还要编写修复方案。
在高峰期，我们估计这消耗了团队大约90%的时间。我们保持了响应速度，但长期工作的执行却开始停滞。
招聘是一种选择，但大部分工作量是重复性的上下文重建，而非产品判断。我们希望代理能承担调查和常规执行，而工程师则保留优先级排序和产品决策权。
我们的反馈循环如何运作——从报告到解决
我们团队反馈渠道中的每一条新根消息都会启动一个长期运行的Feedback Triager会话。该会话在其生命周期内拥有该讨论串，因此可以整合回复、更正、编辑和新证据，而无需在每次轮次中重建对话。
1. 接收
Triager阅读报告及周围上下文，进行确认，并确定需要哪些信息。当关键事实缺失时，它最多提出一个聚焦的澄清问题。
2. 调查
对于缺陷、回归和意外行为，它会在代码、配置、测试、文档、日志、指标、部署状态、现有工单和相关Slack讨论串中进行根本原因分析。运行时证据确定发生了什么；静态证据解释为什么。Triager将结论标记为已确认、暂定或仍缺证据，而不是将看似合理的猜测当作事实呈现。
3. 行动
下一步取决于证据：
| 发现情况 | 处理方式 |
|---|---|
| 问题、一次性事件、预期行为或不支持的请求 | 在 Slack 中解答或说明决定；无需创建工单。 |
| 问题属于其他团队 | 将问题连同 RCA 和已有证据转交给相应团队。 |
| 已存在匹配的问题 | 链接或补充到现有工单，而不是创建重复工单。 |
| RCA 和局部修复方案明确 | 立即启动 PR 作者实施修复，然后进入审查和验证流程。 |
| 问题较为开放或 RCA 仍不明确 | 创建 Linear 积压问题，附上目前收集到的证据；结合路线图其余部分进行优先级排序和深入调查。 |
清晰且范围明确的修复不应等待下一个规划周期；模糊的问题和功能请求应归入 Linear 进行优先级排序和深入工作。
如何让反馈分类高效运作
- 背景： 分类员能够访问工程师所使用的代码库、文档、工单历史、Slack 讨论串、日志及指标。缺少这些输入，智能体只能总结报告；有了它们，智能体则能深入调查问题。
- 定制化： 每个团队可自定义分类、路由、工单、证据及沟通规则，使分类员能贴合该团队的实际运作方式。
- 证据纪律： 分类员独立验证报告者的诊断，并在证据指向不同原因、负责人或严重程度时明确说明。
- 人在回路中： 人力投入小而精，集中于最高杠杆的任务：利用根本原因分析（RCA）及支持证据做出决策。一旦人类选定路径，智能体即可处理常规执行，如提交工单或启动拉取请求作者。
- 记忆： 对分类、路由、去重或响应行为的修正，会转化为明确的渠道特定规则，使未来的分类更加一致。
反馈分类需要软件工厂
反馈分类员能比手动队列更快地产出可执行的工作。如果下游工程系统无法消化这些工作，代码审查和验证便成为新的瓶颈。
因此，我们的反馈循环连接了多位专业的 Cosmos 专家：
目标不是优化单一环节，而是缩短从产品反馈到验证结果的完整循环。同一软件工厂也支持 大型工程项目 和 事件响应。
最终状态：反馈规模化，团队无需扩张
我们对当前的运营模式感到满意。如今，我们两人的团队在反馈处理上花费的时间约占30%，远低于此前估计的90%，主要精力重新回归长期规划。
我们不再需要仅仅为了跟上反馈节奏而扩充团队。随着功能不断增多，反馈分类员（Feedback Triager）提升了我们调查和分流反馈的能力，而PR作者、代码审查及验证专家则承接了下游的修复工作。
其他早期经验：
- 最佳的分类结果往往是不创建工单。 问题咨询、已知限制、重复报告及一次性故障不应堆积在待办事项中。
- 模糊性应留待规划阶段，而非体现在试探性代码中。 开放式问题需要优先级排序和更深入的调查。
如何采纳此工作流程
请让 Cosmos Advisor 为您的团队配置一名反馈分类员。借助标准的协作与工单系统——如Slack或Microsoft Teams配合Jira、Linear、GitHub Issues或GitLab Issues——Advisor能够自主配置专家、集成、触发器和分流工作流。
从单一团队和单一反馈渠道开始。Advisor将连接代码库、追踪器和证据来源；配置回答、路由、去重和归档规则；设定人工审批级别；并连接下游的审查与验证环节。先测量基线，待工作流验证可靠后再逐步扩大权限。
目标并非生成更多工单或PR，而是让每一条产品反馈都能以更少重复性人工劳动达成正确结果——这样小团队也能支撑不断壮大的产品，并持续构建未来。
构建你自己的软件工厂，用于产品反馈
Cosmos 为工程团队提供共享上下文、运行时控制、集成以及人工检查点，以便对反馈进行分类、调查根本原因，并将其引导至正确的处理结果。
最初发布于 @augmentcode 博客。作者：@AkshayUtture001。