Michael Nielsen 说 AlphaFold 的突破主要来自蛋白质数据库(PDB)里约 18 万条实验结构,这些结构靠 X 射线衍射、核磁共振和冷冻电镜花了数十年、几十亿美元才拿到。AI 只是最后一步拟合模型,占整个投入的极小部分。正文没披露模型训练具体用了多少数据,但核心观点很清楚:别把功劳全算在 AI 头上,数据采集才是大头。
Karpathy 的 LLM Wiki:让 AI 替你整理收藏夹,比 Auto Research 更有意思
作者说 Karpathy 的 LLM Wiki 比 Auto Research 更有创意,核心思路是让 AI Agent 把散落在各处的收藏(X 点赞、浏览器书签、微信收藏等)自动整理成结构化的个人 Wiki,而不是让人手动打标签、建分类。作者自己也在做类似工具,但 Karpathy 这一步之前没见过。关键转变是信息整理从人主动变成 AI 主动,你只需...
短评:Karpathy 的 LLM Wiki 被作者评为比 Auto Research 更有创意,但正文没披露具体内容,信息缺口明显。
点评:作者认为 Andrej Karpathy 的 LLM Wiki 比 Auto Research 更有创意,理由是 Auto Research 早有理论铺垫,而 LLM Wiki 让他眼前一亮。但全文只有个人观点,没有给出 Wiki 的具体内容、功能或...
锐评
这条信息只给出一个核心主张:LLM Wiki 要把分散收藏自动整理成结构化 Wiki;正文未披露模型、索引机制、更新频率、价格,也没给发布时间。我对这个方向是偏看好的,因为它打的不是“再做一个收藏工具”,而是把知识管理里最没人愿意做、但又最影响复用率的那一步外包给 agent。
我一直觉得,个人知识管理产品死得最多的地方,不是采集,不是搜索,是归档。Notion、Readwise、Mem、各种稍后读和书签服务,这几年都证明了一件事:用户愿意一键存,不愿意持续整理。标签体系最后会烂尾,文件夹层级最后会失真,过几周就没人记得当初为什么存。Karpathy 这个想法有意思,就在于它默认“人不会维护结构”,所以让模型从内容本身反推主题、关系、时间线和引用网络。这比 Auto Research 更像一个长期容器。Auto Research 解决的是一次性探索任务,做完一轮报告就结束;Wiki 这条线如果做对,价值会随时间累积。
但我对“整理成结构化 Wiki”也有明显保留。第一,结构化不等于可靠。模型很会编出看起来合理的分类树,也很会把两篇相邻但无因果关系的材料硬连起来。第二,知识库一旦自动演化,就会出现版本污染:你上周存的一篇旧论文,可能会被新内容重写语境,最后你看到的是 agent 的解释,不是原始资料。第三,个人知识管理最难的不是写页面,而是决定删什么、保留什么、冲突信息怎么并存。正文没有讲冲突处理、来源回链、人工审核阈值,我自己不会轻易把这类系统当成“第二大脑”。
外部参照其实不少。Google NotebookLM 证明了“围绕你自己的材料生成结构和问答”有需求,但它更偏会话和播客式消费,不是持续维护的个人 wiki。Readwise Reader 这些产品已经把高亮、摘要、回顾做得很顺,但还没真正把碎片信息变成能长期演化的知识图谱。我印象里 Mem 早年也讲过自动组织的故事,热度不低,最后没有变成主流工作流,问题就在自动结构经常不够稳,用户也很难建立信任。Karpathy 如果真要把这件事做成,关键不在“能不能生成 Wiki 页面”,而在三件很硬的事:来源引用要细到段落级,更新合并要可回滚,分类变更要让用户看得懂。我还没查到他现在的原型是否做到这些。
所以这条我不会把它当成一个新理论。我把它看成一个产品方向终于碰到了对的切口:不是帮你多看一点,而是帮你少丢一点。这个切口很对,落地却很难。只要回链、去重、冲突管理做不好,LLM Wiki 就会从“个人知识库”滑成“看起来很整齐的幻觉堆栈”。
Telegram 现在允许机器人自主创建和管理其他机器人,全程不需要你手动审批或操作。这意味着你的 Claude Code 或自动化脚本可以直接在 Telegram 里批量生成带复杂功能的子机器人,实现原生多机器人编排。正文没披露 API 调用范围、安全护栏、上线时间或定价,所以实际能玩多大、会不会被滥用,目前还不清楚。
#Agent#Tools#Telegram#Claude Code
精选理由
Telegram 放开机器人管理机器人的权限,钩子新、机制具体,所以 H 和 K 都成立。但 API 范围、权限边界、上线时间和费率正文都没说,R 还弱,没到 featured 级别。真正值得盯的是多机器人编排会不会原生进 Telegram,这点先别太激动。