即刻App年轻人的同好社区
下载
我把Karpathy的这篇文章丢给自己的agent之后，它可以直接帮我建立知识管理系统，这个知识管理和更新过程感觉远远超过Instapaper + Readwise这种传统知识管理书签的方式，一切都变得“自然”了起来。
机器总结翻译如下：
Andrej Karpathy 的 LLM 驱动知识管理模式可以概括为"LLM 作为知识库管理员"的范式——将原始数据摄取、知识整理、问答交互和持续维护的全过程交由 LLM 自动化处理，人类主要扮演提问者和策展人的角色。
以下是该模式的核心要点：
1. 架构理念：从「写代码」转向「操作知识」
Karpathy 指出，他的 Token 消耗正从代码编辑转向知识操作。核心是将分散的原始资料（论文、文章、代码库、数据集、图像等）通过 LLM「编译」成结构化的 Markdown 知识库（Wiki），而非手动整理笔记。
2. 工作流程闭环
数据摄取（Data Ingest）
• 使用 Obsidian Web Clipper 将网络文章转为 Markdown 存入 raw/ 目录
• 通过快捷键批量下载关联图像到本地，确保 LLM 可直接引用
• LLM 自动将原始数据「编译」为 Wiki：生成摘要、建立反向链接、按概念分类、撰写专题文章
IDE 与可视化
• Obsidian 作为前端 IDE，用于查看原始数据、编译后的 Wiki 及衍生可视化
• 关键原则：LLM 负责所有 Wiki 内容的写入和维护，人类极少直接编辑
• 使用 Marp 插件渲染幻灯片，matplotlib 生成数据图表
智能问答（Q&A）
• 当 Wiki 达到一定规模（如 100 篇文章、40 万字），可直接向 LLM 代理提出复杂问题
• 无需传统 RAG：LLM 自动维护索引文件和文档摘要，在「小规模」（~400K 词）下可直接读取所有相关上下文
• LLM 会主动研究答案，而非简单检索
输出生成与回填（Output）
• 答案不局限于文本终端，而是生成结构化 Markdown、幻灯片或可视化图像
• 关键机制：将输出结果「归档」回 Wiki，使探索过程和查询结果不断累积，形成复利效应
质量维护（Linting）
• 定期运行 LLM「健康检查」：发现数据不一致、通过网页搜索填补缺失信息、识别潜在关联以生成新文章候选
• LLM 主动建议进一步探索的问题方向
3. 工具扩展
• 自研搜索引擎：用「vibe coding」快速开发简易搜索工具，既可直接使用（Web UI），更常作为 CLI 工具供 LLM 调用，增强大规模查询能力
4. 未来演进
• 合成数据 + 微调：考虑通过生成合成数据对模型进行微调，使 LLM 将知识「内化」到权重中，而非仅依赖上下文窗口
5. 产品化洞察
Karpathy 认为当前方案仍是脚本拼凑的临时方案（hacky collection of scripts），但这一模式预示着一个潜力巨大的新产品方向：全自动化的个人知识操作系统。
----
一句话总结：这是一个以 LLM 为引擎、Obsidian 为界面、Markdown 为介质的自动化知识管理系统，实现了从信息收集→结构化整理→深度问答→持续自优化的完整闭环，人类只需提问和审阅，无需手动维护笔记。
机器总结翻译如下：
Andrej Karpathy 的 LLM 驱动知识管理模式可以概括为"LLM 作为知识库管理员"的范式——将原始数据摄取、知识整理、问答交互和持续维护的全过程交由 LLM 自动化处理，人类主要扮演提问者和策展人的角色。
以下是该模式的核心要点：
1. 架构理念：从「写代码」转向「操作知识」
Karpathy 指出，他的 Token 消耗正从代码编辑转向知识操作。核心是将分散的原始资料（论文、文章、代码库、数据集、图像等）通过 LLM「编译」成结构化的 Markdown 知识库（Wiki），而非手动整理笔记。
2. 工作流程闭环
数据摄取（Data Ingest）
• 使用 Obsidian Web Clipper 将网络文章转为 Markdown 存入 raw/ 目录
• 通过快捷键批量下载关联图像到本地，确保 LLM 可直接引用
• LLM 自动将原始数据「编译」为 Wiki：生成摘要、建立反向链接、按概念分类、撰写专题文章
IDE 与可视化
• Obsidian 作为前端 IDE，用于查看原始数据、编译后的 Wiki 及衍生可视化
• 关键原则：LLM 负责所有 Wiki 内容的写入和维护，人类极少直接编辑
• 使用 Marp 插件渲染幻灯片，matplotlib 生成数据图表
智能问答（Q&A）
• 当 Wiki 达到一定规模（如 100 篇文章、40 万字），可直接向 LLM 代理提出复杂问题
• 无需传统 RAG：LLM 自动维护索引文件和文档摘要，在「小规模」（~400K 词）下可直接读取所有相关上下文
• LLM 会主动研究答案，而非简单检索
输出生成与回填（Output）
• 答案不局限于文本终端，而是生成结构化 Markdown、幻灯片或可视化图像
• 关键机制：将输出结果「归档」回 Wiki，使探索过程和查询结果不断累积，形成复利效应
质量维护（Linting）
• 定期运行 LLM「健康检查」：发现数据不一致、通过网页搜索填补缺失信息、识别潜在关联以生成新文章候选
• LLM 主动建议进一步探索的问题方向
3. 工具扩展
• 自研搜索引擎：用「vibe coding」快速开发简易搜索工具，既可直接使用（Web UI），更常作为 CLI 工具供 LLM 调用，增强大规模查询能力
4. 未来演进
• 合成数据 + 微调：考虑通过生成合成数据对模型进行微调，使 LLM 将知识「内化」到权重中，而非仅依赖上下文窗口
5. 产品化洞察
Karpathy 认为当前方案仍是脚本拼凑的临时方案（hacky collection of scripts），但这一模式预示着一个潜力巨大的新产品方向：全自动化的个人知识操作系统。
----
一句话总结：这是一个以 LLM 为引擎、Obsidian 为界面、Markdown 为介质的自动化知识管理系统，实现了从信息收集→结构化整理→深度问答→持续自优化的完整闭环，人类只需提问和审阅，无需手动维护笔记。
https://x.com/karpathy/status/2039805659525644595?s=46&t=LV1Df8WcYu0EFrHechE78A
2 00
个人筛选讲座和分享会嘉宾的标准：
1. 一线做事的人 （“把手弄脏”的人）
2. 有第一手知识且愿意分享第一手知识的人
如果嘉宾是下面几类人，没必要去：
1. 单纯复读机市场叙事的人
2. 号称是专家但是从来没有自己一线做过或者从来没有自己产品的人
3. 转述公开信息的人
1. 一线做事的人 （“把手弄脏”的人）
2. 有第一手知识且愿意分享第一手知识的人
如果嘉宾是下面几类人，没必要去：
1. 单纯复读机市场叙事的人
2. 号称是专家但是从来没有自己一线做过或者从来没有自己产品的人
3. 转述公开信息的人
5 00
之前让Claude做模型横评，结果它横评完还专门“强调”DeepSeek是中国模型所以有数据泄漏风险...
C坍缩中: ？？？ Anthropic这公司搞歧视到底了这是 气炸 国产模型什么时候能追平 立马换
2 00
飞回香港这个科技洼地之前，感受了下北京的龙虾活动，也是全年龄参与，挤在一起听傅盛远程连线讲养龙虾。我感觉和不同于十年前的互联网浪潮（当时中美的互联网在做不同的事情），也不同于几年前的币圈牛市（国内不能做），这一次是好不容易中国科技爱好者们可以和全世界其他地方的人探索着同一件事情。
6 01
可能深圳就是中国里的美国（千禧年版）
小晚: “来了就是深圳人”真是个好的slogan
1 01
复制粘贴PDF文字的时候经常会遇到文字断行的情况，为了不再花时间手动删除换行符，我做了一个开源小工具去自动识别合并文字段落，方便从PDF里粘贴文字。
使用链接：case-thread.github.io
也可以把这个HTML文件从GitHub下载下来，存在本地使用。
使用链接：case-thread.github.io
也可以把这个HTML文件从GitHub下载下来，存在本地使用。
00:49
6 01
AI领域著名研究人员Jason Wei早前写了篇短文，讨论一个简单的概念：有些任务做起来难但验证容易（比如数独、编程），有些任务做起来容易但验证难（比如写一篇文章比逐句核查文章里的每个陈述要省力得多）
Jason Wei把这叫做"验证的不对称性"。这解释了为什么AI在下棋或编程方面表现出色，但在律师的很多工作上却力不从心
他的"验证者法则"是这样说的："训练AI解决某个任务的难易程度，取决于这个任务有多容易被验证。所有可以解决且容易验证的任务，最终都会被AI解决。"
这对法律工作意味着什么?
我认为大多数法律任务都属于"难以完成，更难验证"这一边。这里"验证"的定义本身就很模糊——法律更像是艺术而非科学。下棋的胜负是黑白分明的，但法律工作的优劣是主观的、取决于具体情境的，而且往往要几个月甚至几年后才知道做得对不对。
有些任务是"低垂的果实"，更容易借助AI完成，例如冲突检索、销售合同模板的生成、公司廉洁政策。但其他任务，比如起草“高质量”的书面陈词或交叉盘问问题，验证起来极其困难，因为：(1)没有统一的高质量起草标准；(2)诉讼程序漫长，要很久才能看出效果。
从这个角度来看，问题的关键不在于AI够不够聪明，而在于我们能不能教会它。毕竟我们没法教一个无法被衡量的东西。
Jason Wei把这叫做"验证的不对称性"。这解释了为什么AI在下棋或编程方面表现出色，但在律师的很多工作上却力不从心
他的"验证者法则"是这样说的："训练AI解决某个任务的难易程度，取决于这个任务有多容易被验证。所有可以解决且容易验证的任务，最终都会被AI解决。"
这对法律工作意味着什么?
我认为大多数法律任务都属于"难以完成，更难验证"这一边。这里"验证"的定义本身就很模糊——法律更像是艺术而非科学。下棋的胜负是黑白分明的，但法律工作的优劣是主观的、取决于具体情境的，而且往往要几个月甚至几年后才知道做得对不对。
有些任务是"低垂的果实"，更容易借助AI完成，例如冲突检索、销售合同模板的生成、公司廉洁政策。但其他任务，比如起草“高质量”的书面陈词或交叉盘问问题，验证起来极其困难，因为：(1)没有统一的高质量起草标准；(2)诉讼程序漫长，要很久才能看出效果。
从这个角度来看，问题的关键不在于AI够不够聪明，而在于我们能不能教会它。毕竟我们没法教一个无法被衡量的东西。
4 01