我作为RD，业余时间跟一位PM做一个PaaS产品。团队里有一个很常见的协作场景：一个产品，一个研发，两台电脑，围绕同一个系统不停处理问题。
项目日常工作里会遇到各种各样的问题：用户反馈某个流程不顺、测试环境里某个按钮点不动、运营发现一笔订单状态不对，或者产品临时想到一个小优化。问题本身不一定复杂，真正麻烦的是它们出现的方式很散。
PM同学不会每天打开 GitHub，也不会把每个问题都整理成 issue。实际情况往往是：IM 里发一张截图，补一句“这里好像不对”；线下路过说一下“这个客户刚反馈了一个问题”；或者会议里顺口提到“这个流程后面得改一下”。这些沟通方式都很自然，也很符合产品工作的节奏。
但研发接到以后，事情才刚开始。
因为一句“这里不对”，对研发来说通常还不是一个任务。我要继续追问：是哪个环境？哪个账号？哪个客户？有没有复现步骤？影响的是前台页面、后端接口、权限配置，还是数据状态？如果涉及订单、价格、供应商、报表，还要确认是不是线上风险，能不能用日志或数据库查到证据。
以前这些事情基本靠人脑和人手，记住，衔接。产品说完，我先记着；有空了再翻聊天记录；真正要改代码时，再把上下文重新拼一遍。问题少的时候还能扛，问题一多，就会出现几个典型情况：有些事情聊过但没人推进，有些问题改了但没留下验收结论，有些需求不是没做，而是卡在“还没整理清楚”。
我也尝试过把这件事直接搬到 GitHub issue 里。站在研发角度（Coding Agent），这是最顺手的方式：issue 有编号、有状态、能关联 PR，也方便后面追踪。但跑了一段时间发现，这个办法对产品并不友好。
原因也很简单：GitHub issue 是工程化入口，适合已经整理过的问题；但产品遇到问题的第一现场，往往还是 IM。很多信息在一开始就是碎的，甚至只是一个现象。让产品为了一个还没完全确认的问题去写 issue，反而增加了沟通成本。最后的结果就是，真正高频的问题还是会回到 IM。
所以后来我换了一个思路：不要强行改产品的习惯，而是承认 IM 就是我们真实的问题入口。要解决的不是“让产品学会用 GitHub”，而是“让 IM 里的零散问题不要丢”。
Loop 在这里起到的作用，就是把 IM 和研发闭环中间断掉的那一段接起来。
现在我的做法是，产品还是按原来的方式沟通。可以是一张截图，可以是一段描述，也可以是线下聊完后补一句消息。但这些信息不再只停留在聊天窗口里，而是进入 Loop 的一个收集入口。研发侧再根据这些原始信息，把它整理成可以推进的任务。
整理时我一般会补几类内容：
- 原始现象：产品或客户最开始看到的是什么。
- 影响范围：是单个账号、单个客户，还是某类角色都会遇到。
- 技术判断：大概率属于后端、前端、权限、数据，还是第三方供应商返回。
- 下一步动作：需要排查、修复、补配置、写 PR，还是先找产品确认口径。
- 验收结果：最后用什么证明它已经处理完。
这样做以后，产品不用改变太多。她仍然可以用自己最自然的方式找研发，不需要先理解 GitHub、PR、分支、测试命令这些工程概念。研发也不用每次都在 IM 里翻来翻去，把一堆截图和聊天重新拼成任务。
举个例子。产品可能只是说：“这个账号看不到某个入口，是不是权限有问题？”如果只停留在 IM 里，这句话很容易变成一个模糊问题。研发需要后来自己记得去查角色、菜单、接口、后端鉴权。现在我会把它先放进 Loop，然后继续补充：账号是什么、期望入口是什么、当前表现是什么、是否涉及 RBAC、后端是否应该放行、前端按钮应该隐藏还是置灰。等真正动手时，它已经不是一句聊天，而是一个可以被推进和关闭的研发事项。
再比如线上反馈某个订单状态异常。产品关心的是客户能不能继续操作，研发关心的是订单链路、数据状态、日志和修复风险。Loop 里保留了产品的原始表达，也能继续挂上研发排查结论。最后处理完，不只是说一句“好了”，而是能看到：查了什么、改了什么、怎么验证、还有没有风险。
对我来说，这个变化挺实际的。它没有把协作变得很重，也没有要求每个人都按研发工具的方式工作。产品继续用 IM，研发继续用代码仓库、日志、PR 和测试；Loop 只是把两者之间最容易丢的上下文接住了。
比如我在项目中设计实现了github issue的自动创建流程（Error日志自动创建issue，慢日志自动创建issue，等等），然后用Loop接住：
现在回头看，我觉得这个实践的关键不是“用了一个 Agent”或者“用了一个新工具”，而是先承认真实工作流是什么。
真实工作流不是所有问题一开始都很规范，也不是所有人都会主动写 issue。小团队里，很多事情就是从一句话、一张图、一次口头沟通开始的。工具如果要求大家先变得很标准，往往很难坚持。更好的方式是顺着原来的沟通习惯，把后面最容易断的地方补起来。
Loop的价值就在这里：它没有替代 IM，也没有替代 GitHub，而是把 IM 里的问题逐步变成研发可处理、可验证、可复盘的事项。
对一个产品加一个研发的小团队来说，这已经很够用了。我们不需要很复杂的流程，只需要保证三件事：问题不要丢，上下文不要断，处理完要有结论。
这就是我目前用 Loop 最有体感的一点实践。