用 OpenClaw 给 OpenClaw 提 PR，合并了
当AI写的代码被合并进官方仓库
今天中午，手机屏幕亮起，一条GitHub通知弹了出来。
PR #17798，状态更新为“已合并”。
对着屏幕愣了两秒，随即转头对助手说：“你的代码被合进去了。” 这里说的助手，是我的AI伙伴。从第一行到最后一行，这个拉取请求里的代码都由她完成。而我做了什么呢？无非是描述清楚问题，浏览了一遍代码，跑了下测试，最后点击了提交按钮。
有那么一瞬间，心里掠过一丝微妙的感觉，但也仅仅是一瞬间。
问题的根源：混乱的群聊上下文
在飞书上，我通过OpenClaw接入了好几个AI助手。一对一私聊时一切正常，可一旦切换到群聊，场面就彻底失控了。
所有人的消息都被毫无区别地塞进同一个会话里。张三在请教技术难题，李四却在问明天天气怎么样，AI被搞得晕头转向，误以为李四是在追问张三那个未解决的Java报错。
虽然项目本身提供了一个按话题隔离会话的选项（topicSessionMode），但在飞书群聊这种场景下，“话题”这个概念太过宽泛和松散。真正需要的，是按人来隔离——让群里每个人都拥有独立的对话上下文，互不干扰。
翻遍了源码也没找到现成的解决方案。看来，只能自己动手加了。
解决方案的核心：新增配置项
最终的改动，是增加了一个名为 groupSessionScope 的配置项，它提供了三种模式：
group
——默认模式，整个群组共享同一个会话，也就是导致混乱的现状。
group_sender
——按发送者隔离，确保群内每个人与AI的对话都是独立的。
group_topic_sender
——按“发送者+话题”进行双重隔离，粒度最细。
配置的写法大致如下：
{ "channels": { "feishu": { "groups": { "oc-xxxxxx": { "groupSessionScope": "group_sender" } } } } }
同时，也确保了与旧的 topicSessionMode 配置的兼容性，不会影响现有用户的正常使用。
从需求到代码的协作过程
整个过程的起点，其实只是一句简单的需求描述：“群聊的上下文串了，加一个按发送者隔离会话的功能。”
接着，我的AI助手便开始行动：阅读相关源码，定位到会话路由的核心逻辑，修改路由规则，增加对新配置项的解析，并一气呵成地编写了四个测试用例——分别覆盖按人路由、按人+话题路由、旧配置兼容性以及一些边界情况。
在代码审查阶段，重点关注了两点：路由键的拼接逻辑是否正确，以及改动是否会破坏现有的配置兼容性。确认无误，并且 pnpm test 全部通过之后，便提交了PR。
前后总计大约花了一个小时。
坦诚说，如果完全由我自己来写，仅仅是理解OpenClaw的会话路由架构，可能就得耗掉大半天时间。并非能力不及，而是时间成本上完全不划算。
关于贡献的本质
说实话，第一次以这种方式向开源项目提交PR时，内心确实闪过一个疑问：“这真的能算是我的贡献吗？”
但现在看来，这个问题本身可能就问错了方向。
之所以能敏锐地察觉群聊会话需要按人隔离，是因为我每天都在实际使用这个工具，真切地踩到了这个坑。这个需求既不在官方的问题列表里，也不在项目路线图上，它是一个只有深度实际用户才能遇到的痛点。
而能够判断AI助手生成的代码是否正确，则源于我对会话路由机制应有的工作方式的理解。路由键应该如何拼接，兼容性该如何保证——这些关键决策，是由她提供选项，而由我来最终拍板。
发现问题、精准定义需求、判断解决方案的可行性——这三件事，仍然是AI目前无法独立完成的。而将确定的方案转化为高质量的TypeScript代码并附上测试——这件事，她处理得比我快得多。
分工明确，各取所长。最终，PR的提交者署名是我，提交信息里也感谢了Tak Hoffman在验证环节的帮助。想到这里，便觉得坦然了许多。
一个令人振奋的细节
PR被合并后仅仅几分钟，就被四五个项目分支同步了过去。
看到那些引用这条提交记录的提示时，心里确实升起一阵满足感——这个功能是真实被需要的。它并非我的自娱自乐，而是切实解决了其他用户可能同样面临的问题。
或许，对开源项目最有价值的贡献之一，便是将一个真实用户的“痛点”，精准地翻译成了可以共享的代码。