我用 vibe coding，搓了一个内部反馈工具

从一个很蠢的早晨开始

我是某回国加速器的产品经理。有一段时间，我每天的第一件事不是看数据、不是排优先级，而是打开工单后台，把昨晚和今早的新反馈逐条复制到 IM 群里 @ 运维。

要看用户标识、平台、地区、用户原话、有没有日志。不难，但荒谬——不产生判断，只消耗人。更麻烦的是，发出去不等于问题被接住：群里常回「在看」，查到哪、转不转研发、结论是什么，往往没有下文。同一用户一周反馈好几次，在列表里是几条散记录，我不记得就被冲掉。

我真正要回答的问题

用户说连不上、加速没效果、影音没解锁、要退款。客服能看到用户怎么骂，运维能看到节点，研发能查日志。但我要答的是另一组问题：

• 这是不是产品体验问题？
• 影响多少人？有没有地区、平台、版本上的集中？
• 该不该进研发优先级？

这些信息散在客服平台、工单后台、业务库埋点、崩溃日志和群里。被问「这周加速怎么样」，我常常只能说「好像节点多一点」「某地区好像集中」。

最烦的就是「好像」。 用户只会说慢、失败、没效果；真正原因可能是节点、线路、DNS、版本，也可能是本地网络。拼不起来，就只能看散点，看不到链路。

为什么先跑起来，而不是先写完整 PRD

按常规应该写 PRD、拉客服/运维/研发对齐、排期上线。流程没错，但这件事不是边界清晰的新功能，而是一条乱的真实业务链路——只有跑起来，才知道哪里最堵。

我的做法很朴素：用 vibe coding 先替换当下最蠢、最重复、最靠人脑补的那一截。不是做 Demo 秀，是把链路往前推一步。

链路一：从「我有没有发」到「有没有被接住」

痛点： 靠人记、靠人催、靠人复制粘贴。

做法： 新反馈自动推到团队群，带上平台、用户标识、地区、原话和详情入口；该 @ 谁由规则决定，不再靠我早上手动搬运。

群适合提醒，不适合追踪。我加了看板：谁在跟、什么状态、有没有超期、要不要转研发，都在一个地方。群负责让人看到，看板负责记录有没有被接住。

链路二：从「连不上」到「找到该看的那段日志」

痛点： 用户一句「连不上」，研发要先在几万行日志里找反馈前后发生了什么。时间多半耗在找，不是判。

做法： 按反馈时间切一小段日志，放在详情页。不替研发下结论，只是把重复搜索提前做掉。

辅助定位： 在切片上生成初稿——可能的故障类型、责任方、建议怎么查。我没有让它自动结案：高置信也会错，必须有人标确认、有争议还是噪声。目的是减少重复劳动，不是卖「智能化」。

链路三：从「一条工单」到「看见趋势」

痛点： 单条工单只能看个案，看不出这周什么问题在涨、哪里集中、有没有重复用户。

做法： 加了洞察页；又单独拉加速失败埋点，看各平台成功率和 Top 错误。至少「用户在骂什么」和「系统在哪里失败」，能放在同一视角里。

还没通的地方： 埋点失败和工单还不能自动绑定；洞察到 backlog 没完全打通；用户不传日志，后台无解；初稿必须人工复核。我不指望一次做完——先把最堵的几截换掉，剩下的慢慢补。

写在最后

这不是能发 Product Hunt 的产品，就是长在业务里的内部工具。它还不完整。

但我终于不用每天第一件事是抄工单到群里。可以把注意力放回用户体验本身——去判断哪些问题真的在伤害加速体验，而不是靠脑子拼散点。