用了Cursor一个月, 除了写代码给我带来的便利之外
我意识到, 他给我这半年以来的 对于Chatbot的交互形式的思考, 提供了答案

在过往使用各类Chatbot的过程中, 我总是觉得对话式的交互,并不总是非常舒服
尤其是 当我在 使用GPT去帮我解决一些复杂问题的时候
单一线程的, 对话式的交互, 让我觉得在不断的对话交互之中, 我会逐渐失去对这次对话的宏观把控

具体而言, 例如:
伴随着 对话轮次 的增多, 冗余的信息在上下文的窗口之中逐渐累积
而为了修剪掉这些冗余, 我可能会需要回到某一轮对话, 删除或者重编辑一些对话轮次
但这样的操作又会让这些被覆盖的对话轮次之中的有价值的信息丢失
再例如:
面对一个新的问题的时候, 语言模型所给出的很多解决方案, 是会超纲的(即超出当前我对这个问题的认知和理解)
[比如说, 对于去年使用gpt写代码的一个编程小白而言, 开始面临的问题就是需要跳出当前写代码的线程, 去提问什么是前后端/服务器/数据库]
对这些基础问题的提问会打乱当前问题解决的这个"单线程",
而这些基础的信息对于当前有待解决的问题几乎毫无增益

所以, 这半年我困惑的一个问题是, 是否存在一种 更加自由的上下文控制方式,
在这种范式之中, 我可以保有一个 主要的线程 去和大模型沟通交流, 以逐渐将问题解决
而在这个主要线程之中, 我可以随时开启 任意多的 子线程, 以去解决当前线程所遇到的问题,
这个子线程 可能对我的理解而言很重要, 但是对于大语言模型可能未必重要
并且, 在此基础上,如果我判断某个子线程的信息 对主线程的信息是有增益的,
我可以将这些子线程的执行结果 合并到这个主线程之中
以保证 主线程 中 所有的信息 都是 对于解决问题 有直接增益的

对于这个问题, 我做过一些调研, 唯一看起来比较接近这个思路的, 是flowith, 但他们只能多开子线程,
而无法做到在多个线程之间 随时切换, 并且 合并信息, 做到自由的上下文管理
在两周的cursor使用之后，我发现, Cursor 的 @ 功能, 可能是对于我的需求的一个非常好的解法

那个主线程就是当前的正在处理的代码文件, 所有的聊天、其他的文件都是为这个线程服务的
而当我在编写代码的时候, 我可能随时需要某个信息, 而那个信息可能是在某个子线程里的,
我会把那个子线程的信息存储到某个文件之中(通过让大模型把一段对话的信息总结为一个markdown文档),
在需要的时候, 我可以随时 @ 某个子线程(md或者其他代码文件), 将那个子线程的信息 合并到当前的线程之中

这种交互方式并不只是对写代码有意义,
对于任意一个复杂问题的解决, 我都可以使用这种方式, 去逐渐把中心的问题思考清楚
比起单纯的让大语言模型拟人去扮演某个assistant或者tutor
这可能是一个更加有效的, 更加原生的, 人机协同的方式

(这段随笔在cursor编辑，它甚至自动补全了其中30%的内容)

参考信息:
[1]: Cursor博客: www.cursor.com
[2]: flowith官网: flowith.io
[3]: 播客 AI炼金术《做AI产品的12条反共识》: www.xiaoyuzhoufm.com（文稿：mp.weixin.qq.com）