即刻App年轻人的同好社区
下载
置顶
OpenAI的浏览器真的敢放心用吗？浏览器几乎是每一个上网用户的必备工具，一旦普及，它的算力能支持这么大众的产品吗？一旦算力不够，在浏览器里揪出你是国内的用户可能更方便，直接成片封号，梯子节点挂科，我可以停一下ChatGPT，但我不能停用浏览器…
3 00
最近几天，DeepSeek发布的DeepSeek-OCR论文在外网上被大量讨论，DeepSeek-OCR大胆探索视觉-文本压缩边界。通过少量视觉token解码出10倍以上的文本信息，这款端到端VLM架构不仅在OmniDocBench基准上碾压GOT-OCR2.0，还为LLM的长上下文问题提供高效解决方案。
前特斯拉AI总监、OpenAI创始团队成员Karpathy在讨论这篇论文时提出了一个更深层次的AI架构问题：像素（图像）是否比文本作为LLM的输入更好？他质疑当前LLM的输入范式（文本token），并倡导一种“图像优先”的方法。这反应了Karpathy的计算机视觉背景（他自称“本质上是计算机视觉专家，暂时伪装成自然语言处理专家”）。
当前LLM（比如GPT系列）主要使用文本token作为输入，这些token是通过tokenizer（如BPE或SentencePiece）将文本分解成的离散单元。但token化过程会丢失信息（如格式、颜色），且依赖Unicode等历史遗留系统。
DeepSeek-OCR展示了视觉压缩可以减少token数量（论文中提到<10x压缩下保持97%准确率），这能缩短LLM的上下文长度，降低计算成本。图像可以捕捉文本的视觉属性（如字体、颜色、布局），甚至嵌入图片，这比纯文本更丰富。
当前LLM多用自回归注意力（autoregressive，逐token生成，只能“向前看”）。图像输入允许双向注意力（bidirectional，能同时看前后），如在Transformer编码器中，这更高效和强大。
Karpathy强烈讨厌tokenizer，认为它是“丑陋的、非端到端的阶段”。它引入Unicode的复杂性（历史包袱、安全风险）、字节编码问题。相同外观的字符可能被视为不同token，表情符号被抽象化，而非真实像素（丢失转移学习潜力）。
虽然这种 “图像优先” 的方式是创新性的，但是图像输入可能增加计算机开销（处理像素比token更耗资源），且当前硬件优化针对token，不过，从论文和讨论看，它确实有实质依据。
前特斯拉AI总监、OpenAI创始团队成员Karpathy在讨论这篇论文时提出了一个更深层次的AI架构问题：像素（图像）是否比文本作为LLM的输入更好？他质疑当前LLM的输入范式（文本token），并倡导一种“图像优先”的方法。这反应了Karpathy的计算机视觉背景（他自称“本质上是计算机视觉专家，暂时伪装成自然语言处理专家”）。
当前LLM（比如GPT系列）主要使用文本token作为输入，这些token是通过tokenizer（如BPE或SentencePiece）将文本分解成的离散单元。但token化过程会丢失信息（如格式、颜色），且依赖Unicode等历史遗留系统。
DeepSeek-OCR展示了视觉压缩可以减少token数量（论文中提到<10x压缩下保持97%准确率），这能缩短LLM的上下文长度，降低计算成本。图像可以捕捉文本的视觉属性（如字体、颜色、布局），甚至嵌入图片，这比纯文本更丰富。
当前LLM多用自回归注意力（autoregressive，逐token生成，只能“向前看”）。图像输入允许双向注意力（bidirectional，能同时看前后），如在Transformer编码器中，这更高效和强大。
Karpathy强烈讨厌tokenizer，认为它是“丑陋的、非端到端的阶段”。它引入Unicode的复杂性（历史包袱、安全风险）、字节编码问题。相同外观的字符可能被视为不同token，表情符号被抽象化，而非真实像素（丢失转移学习潜力）。
虽然这种 “图像优先” 的方式是创新性的，但是图像输入可能增加计算机开销（处理像素比token更耗资源），且当前硬件优化针对token，不过，从论文和讨论看，它确实有实质依据。
1 00
发现企业内想推AI Coding是很难的，一个团队内，每个人对AI的认知、使用的工具、使用的模型都是不同的，他们对接的设计、产品的输出也各不相同，业务本身也很难能让AI完全理解，这些问题在一人项目里基本都是不存在的。
企业内部一个运转了十年的项目想要通过vibe coding去让AI做牛马干活很难，你搭建的文件系统来帮助AI更好的了解项目也基本不可能，因为10个人的团队，每个月代码变动量极大，你的文档更新是跟不上的，如果不能整个团队一起维护这套文档系统，那靠一个人是维护不过来的。
所以这个时代的AI Coding红利，就是更倾向于个人或者小团队的快速发展，在企业内推vibe coding还得再等几年，或者永远也等不到。
企业内部一个运转了十年的项目想要通过vibe coding去让AI做牛马干活很难，你搭建的文件系统来帮助AI更好的了解项目也基本不可能，因为10个人的团队，每个月代码变动量极大，你的文档更新是跟不上的，如果不能整个团队一起维护这套文档系统，那靠一个人是维护不过来的。
所以这个时代的AI Coding红利，就是更倾向于个人或者小团队的快速发展，在企业内推vibe coding还得再等几年，或者永远也等不到。
5 71
#独立开发的日常 在去济南的动车上监督AI干活🫤
5 40
Claude今天更新了的新功能——Agent Skills，又是一个上下文工程的技巧，可以在API和Claude Code中使用。来看看它解决的问题和解题思路。
首先看解决的问题，我们拿Claude Code中的例子来看，我的claude code中集成了大量工具，包括MCP，这些工具都要告诉LLM它们是做什么的、什么时候调用、有哪些能力、如何使用等等，当这些工具越来越多的时候，他们会在claude code启动时就被加载到上下文中，但其实很多工具，可能在一次任务中根本不会被使用，白白浪费了这部分上下文。Agent Skills就可以解决这个问题，本质上就是一种“上下文卸载”。
解题思路就是在.claude/skills/目录下创建你的skill，比如pdf，在目录下放一个SKILL.md，在这个文档里描述这个skill的用户和什么时候调用，例如告诉LLM这是个pdf相关工具，应该当用户提到pdf时候调用它。然后在目录里将工作流程、最佳实践和指导之类的内容指向同目录下的相关.md文档，比如读取pdf工具怎么用，使用示例等等。这样在claude code启动后，只会加载相关的工具名称和简单的说明，并不用了解大量的工具具体的使用情况，而是在工作中，需要使用工具时，才去读取具体怎么使用工具。这样就可以大大减少工具描述占用的上下文长度。
首先看解决的问题，我们拿Claude Code中的例子来看，我的claude code中集成了大量工具，包括MCP，这些工具都要告诉LLM它们是做什么的、什么时候调用、有哪些能力、如何使用等等，当这些工具越来越多的时候，他们会在claude code启动时就被加载到上下文中，但其实很多工具，可能在一次任务中根本不会被使用，白白浪费了这部分上下文。Agent Skills就可以解决这个问题，本质上就是一种“上下文卸载”。
解题思路就是在.claude/skills/目录下创建你的skill，比如pdf，在目录下放一个SKILL.md，在这个文档里描述这个skill的用户和什么时候调用，例如告诉LLM这是个pdf相关工具，应该当用户提到pdf时候调用它。然后在目录里将工作流程、最佳实践和指导之类的内容指向同目录下的相关.md文档，比如读取pdf工具怎么用，使用示例等等。这样在claude code启动后，只会加载相关的工具名称和简单的说明，并不用了解大量的工具具体的使用情况，而是在工作中，需要使用工具时，才去读取具体怎么使用工具。这样就可以大大减少工具描述占用的上下文长度。
5 00