即刻App年轻人的同好社区
下载
用NotebookLM做了我的第一期小宇宙播客
主题是我最近看的一篇很喜欢的论文传达的观点:
用神经科学研究范式（脑电/局部损坏/连接组学等） 研究一块八十年代的老式芯片 结果没法理解其架构设计 而人脑的复杂程度比芯片高多了
展现出当前的神经科学研究范式的缺陷
说回NotebookLM, 是谷歌做的一个免费应用
可以快速把文本转化成不超过十分钟的多人对话英文播客
目前测试下来:
语言的自然程度, 理解难度, 信息量都大致和托福听力材料相当
能够比较自然, 且接地气 好理解的传达一个研究的主要观点, 研究方法和结论
但是数据和比较详细的研究设计会被略掉
比较适合大家学习一些其他学科的有趣的论文(或者说 科普)的同时 练练英语
不能替代严肃的论文学习过程
还是一个非常有趣的ai应用
主题是我最近看的一篇很喜欢的论文传达的观点:
用神经科学研究范式（脑电/局部损坏/连接组学等） 研究一块八十年代的老式芯片 结果没法理解其架构设计 而人脑的复杂程度比芯片高多了
展现出当前的神经科学研究范式的缺陷
说回NotebookLM, 是谷歌做的一个免费应用
可以快速把文本转化成不超过十分钟的多人对话英文播客
目前测试下来:
语言的自然程度, 理解难度, 信息量都大致和托福听力材料相当
能够比较自然, 且接地气 好理解的传达一个研究的主要观点, 研究方法和结论
但是数据和比较详细的研究设计会被略掉
比较适合大家学习一些其他学科的有趣的论文(或者说 科普)的同时 练练英语
不能替代严肃的论文学习过程
还是一个非常有趣的ai应用
神经科学家能理解一片芯片吗？
His Master's Voice
2 01
用claude辅助写了半天gre作文
看到了@李继刚 和 @一泽Eze 大佬的prompt
就搓了一个gre作文模板卡片提示词
使用方法是
用户输入题目
先生成范文
基于范文提取模板生成卡片
提示词见：hv8gkbrrd6q.feishu.cn
看到了@李继刚 和 @一泽Eze 大佬的prompt
就搓了一个gre作文模板卡片提示词
使用方法是
用户输入题目
先生成范文
基于范文提取模板生成卡片
提示词见：hv8gkbrrd6q.feishu.cn
4 00
类型学是一种非常有价值的范式
纵然有太多人会驳斥这种 分类的问题
（比如我们学心理学的许多课程的开头 常常就是批判星座和MBTI）
但是其最大的价值就在于
它能够初步给出一个问题的全景
就好像一个大陆的地图
纵使它划分的这个大陆上不同国家的国界线非常不准确
乃至于可能就没有不同的国家 只是不同的区域有不同的地理特征
但是它能给你粗糙的展示这个大陆的全貌
也因此，一个类型学发挥它完全的作用的时候
就是人们发现他分的是个狗屁的时候
纵然有太多人会驳斥这种 分类的问题
（比如我们学心理学的许多课程的开头 常常就是批判星座和MBTI）
但是其最大的价值就在于
它能够初步给出一个问题的全景
就好像一个大陆的地图
纵使它划分的这个大陆上不同国家的国界线非常不准确
乃至于可能就没有不同的国家 只是不同的区域有不同的地理特征
但是它能给你粗糙的展示这个大陆的全貌
也因此，一个类型学发挥它完全的作用的时候
就是人们发现他分的是个狗屁的时候
0 10
cursor这个产品和他们的官方博客
让我想明白了好几个
很重要的困惑我很久的
关于llm时代的人机交互问题
感觉一下通透了
很多之前隐隐意识到的东西一下就明白了
后面打算再写两篇文章可以整理一下
让我想明白了好几个
很重要的困惑我很久的
关于llm时代的人机交互问题
感觉一下通透了
很多之前隐隐意识到的东西一下就明白了
后面打算再写两篇文章可以整理一下
3 00
我现在 每次开一个项目 会建一个 cursor_blueprint 文件夹 在里面的一个markdown文档里面把prd写好
后续如果有什么 参考的网页样式 需要调用的api的接口文档 全部放在里面
需要的时候就@ 一下， 省很多事情
后续如果有什么 参考的网页样式 需要调用的api的接口文档 全部放在里面
需要的时候就@ 一下， 省很多事情
Yishan: 在 Cursor 里写需求的细致程度快赶上对接真人同事了，区别是兴致更高点些。
3 10
用了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）
我意识到, 他给我这半年以来的 对于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）
10 64