他把 Slack 里的吐槽，变成了会自己上线的功能

一个反直觉的事实正在发生：产品改进，已经不一定需要人盯着。Every 的创作者展示了一套真实在用的流程——Slack 里的反馈，被自动整理、分析、写代码、提 PR，甚至在你睡觉时直接合并上线。这不是 Demo，而是正在跑的生产系统。

最反直觉的一幕：我在睡觉，产品在进化

视频里最“炸”的瞬间不是技术细节，而是结果：作者前一晚启动流程，只留下一句规则——“如果一切看起来不错，CI 是绿的，就直接 merge。”第二天醒来，同事已经在 Slack 里夸设计更顺了。没有 standup，没有评审会，没有人肉逐条修 bug。对很多 AI 从业者来说，这一幕击中了一个长期被忽略的点：AI 的价值，不在写得多快，而在于能否闭环到‘上线’。

真正的核心不是模型，而是“反馈工厂”

作者反复强调，他并不是在炫耀某个模型，而是在搭一个“工厂”。入口是 Slack：内部 alpha 频道里，所有人随手丢反馈、截图、Riffrec 录制文件。随后，一个定时任务会自动跑：读取 Slack、结构化信息、判断是否已解决、下载录屏和视频。关键在于，这些原本零散、情绪化的反馈，被转成了机器可读的 YAML 和 Markdown。很多团队卡在‘收集反馈’这一步，而他已经把这一步做成了可重复、可批量处理的原材料生产线。

Riffrec + Cursor：让“我没看过问题”也能被修掉

Riffrec 是一个很容易被低估的细节：它不是单纯录屏，而是同时记录用户点击、语音、网络请求和错误。作者直言，这种反馈“比视频还好”。接下来才是 Cursor 登场的地方：AI 会在一个 PR 里批量修复 10 多个问题，并生成 walkthrough 视频。一个很微妙但重要的变化是——作者第一次 review 时，甚至不知道所有原始问题是什么。他只需要验证结果是否合理。这意味着，人的角色已经从“逐条理解问题”转向“策略性审查决策”。

为什么批处理比 17 个 PR 更先进

视频里有一句非常工程化的判断：一次性处理一批反馈，比拆成十几个 PR 更‘人性化’。原因不复杂——人类的审查成本是瓶颈。通过批处理，AI 可以在 compound engineering 的机制下不断修正自己的错误，下次不再犯同样的问题。慢（2-4 小时一轮），但稳定、可学习。作者说这让他有了“超能力”，本质上是把不可控的上下文切换，变成了可控的节奏。

总结

这条视频真正值得 AI 从业者反复看的，不是某个工具名，而是一种新默认值：反馈不再是讨论材料，而是自动进入交付流水线的输入。你不一定要复制这套系统，但可以从三个动作开始：第一，让反馈天然机器可读；第二，把“修复”变成批处理而不是即时响应；第三，给 AI 明确的合并规则，而不是无限的‘等等再看看’。如果你还在手动整理 Slack 里的吐槽，也许真正该升级的不是模型，而是你的工作方式。

关键词： Slack反馈自动化， Cursor， AI编程工作流， 产品迭代， Compound Engineering

事实核查备注： 需要核查：1）Fable 是否为作者使用的模型名称；2）Riffrec（Riffrack）开源库的准确拼写与定位；3）Cursor 中 LFG flow 是否来自 Compound Engineering；4）流程运行时间为 2-4 小时的描述是否为原话。