今天中午，手机弹了个 GitHub 通知。

PR #17798，merged。

愣了两秒。然后跟小虾说：”你的代码被合了。”

小虾是我的 AI 助手。这个 PR 从第一行到最后一行，都是她写的。我干了什么呢——描述需求，看了眼代码，跑了下测试，点了提交。

有一瞬间觉得心虚。但也就一瞬间。

我遇到了什么问题

我在飞书上跑了好几个 AI 助手，都是通过 OpenClaw 接入的。私聊没啥问题，群聊就炸了。

所有人的消息都往一个 session 里塞。张三问技术问题，李四问天气，AI 一脸懵逼，还以为李四在追问张三的 Java 报错。

之前有个按话题隔离的选项，叫 topicSessionMode，但话题这个概念在飞书群聊里太松了。我要的是按人隔离——每个人有自己的上下文，别串。

翻了半天源码没找到现成方案。行吧，自己加。

改了什么

加了一个配置项 groupSessionScope，三种模式：

  • group——默认，整群共享，就是现在这个乱的状态
  • group_sender——按人隔离，群里每个人跟 AI 独立对话
  • group_topic_sender——按人+话题双重隔离，最细

配置长这样：

{
  "channels": {
    "feishu": {
      "groups": {
        "oc-xxxxxx": {
          "groupSessionScope": "group_sender"
        }
      }
    }
  }
}

旧的 topicSessionMode 也兼容了，不会把老用户搞挂。

实际过程

我跟小虾说了一句话：”群聊上下文串了，加个按发送者隔离的功能。”

然后她去读源码，找到 session routing 那块逻辑，改了路由规则，加了配置项解析，写了四个测试用例——按人路由、按人+话题路由、旧配置兼容、边界情况。

我 review 的时候主要看了两个东西：路由 key 的拼接逻辑对不对，兼容性会不会 break 现有配置。看完觉得没问题，pnpm test 跑过，提了 PR。

总共一个小时左右。

如果我自己写，光理解 OpenClaw 的 session routing 架构就得半天。不是写不了，是性价比太低。

想明白一件事

第一次用这种方式提 PR 的时候，我纠结过”这算我的贡献吗”。

现在觉得这个问题本身就问错了。

我之所以知道群聊 session 要按人隔离，是因为我每天在用这个东西，踩到了坑。这个 bug 不在 issue 列表里，不在 roadmap 上，是一个只有实际用户才会遇到的痛点。

能判断小虾的代码改得对不对，是因为我理解 session routing 应该怎么工作。key 怎么拼，兼容性怎么做，这些判断她提供选项，我来拍板。

发现问题、定义需求、判断方案——这三件事 AI 干不了。把方案变成 TypeScript 代码然后写好测试——这件事她干得比我快十倍。

分工明确，各取所长。PR 署名 yfge，Co-authored-by 里有 Tak Hoffman 帮忙做的验证。没什么好心虚的。

一个细节

PR 合并后几分钟，就被四五个 fork 同步了。

看到那几条 commit 引用的时候挺爽的——这需求确实有人要。不是我在自嗨，确实有人需要这个功能。

有时候对开源最有价值的贡献，就是一个真实用户把自己的痒处翻译成了代码。