Claude Code的代码库近日遭到泄露，内部实现细节随之浮出水面。它比网页版聊天界面强的地方，不是模型本身，而是一整套精心设计的上下文管理和工具调用机制。换句话说，同样的模型，装进不同的软件框架，表现会差很远。
最近Claude Code的TypeScript源码在GitHub上短暂出现过，随即引发广泛讨论。在撇开法律问题之后，它揭示了一个值得深想的问题：为什么同一家公司的同一个模型，放在网页端和放在Claude Code里，用起来感觉像两个东西？
答案大概不在模型权重里。
Claude Code启动时会主动拉取当前git分支、最近提交记录、CLAUDE.md等信息，这是它比网页聊天"懂代码库"的起点。更有意思的是它的缓存策略：静态内容和动态内容之间有明确的边界标记，静态部分全局缓存，不用每次重算。这有点像操作系统里的写时复制，脏页才走慢路径，干净的页直接复用。
工具层面也有讲究。它没有直接通过Bash调grep，而是用一个专门的Grep工具，权限处理和结果收集都在自己掌控里。还有独立的Glob工具做文件发现，以及LSP接入，支持调用层级查找、引用跳转这些功能。网页端看代码更像读静态文本，Claude Code看代码更像真的在跑一个Language Server。
有观点认为，这些工具的加入本质上是把IDE的能力注入给了模型，而不是让模型自己去猜文件结构。
上下文膨胀是代码Agent最容易翻船的地方。反复读文件、长日志、来回对话，context很快就满了。Claude Code在这里做了几件事：文件读取去重，检测文件没有变化就不重新处理；工具返回的结果如果太大，写到磁盘，context里只放预览加文件引用；超长context自动触发压缩和摘要。
这些加在一起，本质上是在做一个手动管理的内存层级，告诉模型什么值得放在寄存器里，什么扔到硬盘就好。
还有一个细节：Claude Code维护一个结构化的Markdown会话记录，包含当前状态、任务说明、涉及的文件和函数、错误与修正、工作日志等部分。这个设计很像人类程序员写scratch pad的习惯，只是被系统化地内置进去了。
子Agent和fork机制倒不新鲜，fork出来的Agent复用父级缓存，同时感知可变状态，可以在不污染主循环的情况下跑摘要、提取记忆或做后台分析。
原作者有个判断，大概70%可信：如果把DeepSeek或其他模型塞进这套框架里，稍作适配，编程表现也会大幅提升。模型是硬件，这套软件框架才是系统软件，性能由两者共同决定。
这留下一个没解决的问题：如果框架比模型更关键，那未来coding agent的竞争，会不会最终变成一场上下文管理工程的军备赛？
Karpathy花四小时用LLM打磨论点，觉得无懈可击，然后让它论证反方，被当场说服。LLM不是真理机器，是说服机器，这个差异比大多数人意识到的要重要得多。
Andrej Karpathy最近发了条帖子，简洁到有点喜剧效果：写好一篇博文，用LLM磨了四小时论证，感觉天衣无缝，心情很好。然后随手让它论证反方观点，LLM把自己的论点彻底拆烂，而且他被说服了。
然后他写了个“lol”。
这个“lol”背后其实是个严肃的问题。LLM不在乎你的论点是什么，它在乎你让它说什么。它优化的是局部连贯性和听起来有说服力，不是真相。所以它可以帮你把一个烂论点打磨得光可鉴人，也可以在五分钟内把它拆成碎片，用的是同等水平的PhD腔调。
有网友一针见血：“如果它能流利地论证两面，说明的是它的修辞能力，不是你论证的正确性。被说服只代表你的反驳门槛太低。”
也有观点认为，这个特性反过来可以用。与其把LLM当思想的放大器，不如当压力测试机。在发文前，专门让它找你论点的三个最大漏洞，让它扮演最挑剔的批评者而不是最热情的编辑。还有人在构建multi-agent系统，让不同模型盲评、相互攻击，用隔离上下文的方式对抗天然的讨好倾向。
真正的问题是：我们习惯用“听起来有没有道理”来判断一个论点好不好。LLM恰好极其擅长让任何东西都听起来有道理。我们过去缺的不是正确答案，是足够好的反驳。现在这个障碍消失了，却多了一个新问题：你愿不愿意在发布前主动让它把你的论点砸烂一遍？
AI没有缩小软件开发市场，而是把市场扩大了100倍。真正消失的不是开发者需求，而是"只会写代码"这个岗位。
有个做MVP开发的创业者发帖，说他今年业务量翻倍了，不是因为别人不会建东西了，而是因为现在每个人都在建东西。
这背后是一个古老的经济规律在发威，Jevons悖论：当一种资源变得极度高效，人们不会用得更少，而是找到一千个以前从没考虑过的使用场景。蒸汽机没有减少煤炭消耗，它让煤炭变得如此有用，需求反而爆炸。
两年前，一个没有技术背景的创始人想做SaaS，要么学六个月编程，要么花十几万外包。大部分人选择了第三条路：把想法烂在备忘录里。现在，同一个人周末就能用AI工具搭出原型。你以为这让开发者失业了，实际上发生的是：每个建出"半成品"的人，都立刻需要帮助把它变成能跑在生产环境里、安全且可扩展的真实产品。
入门门槛降到零，市场没有缩小，而是多了几百万个新入口。
有意思的是，反驳声音也很集中。有观点认为，AI迟早能处理产品决策、用户访谈、功能取舍这些"人类判断"的部分。原帖作者的回应很直接：代码从来就不是最难的部分。难的是搞清楚该建什么、为谁建、什么时候该砍掉一个功能。这些问题的输入本身就是混乱的、人性化的，AI解决不了，因为问题还没被清晰地提出来。
有网友提出了更犀利的分层：初级开发者正在被快速挤压，写CRUD接口这类活确实在消失。但能判断"AI在哪里自信地出错了"的高级工程师，成了每个项目的瓶颈。技能溢价从语法转移到了判断力，这个变化比很多人意识到的要快。
还有人提到，CS毕业生找不到工作，是因为公司不再需要"会写for循环的人"，需要的是能把模糊问题变成用户愿意付钱产品的人。这两个需求根本不是同一件事，却长期被同一个职位名称混淆了。
真正值得想的问题是：如果会AI的一个人能顶以前三到五个人，工资天花板会怎么变？软件越来越多，开发者薪资会跟着涨，还是因为"人人会编程"而变成商品？
这个问题没有人答得出来。
用普通笔记本跑大模型，不再是梦 | 帖子
Google的TurboQuant算法被移植进llama.cpp后，MacBook Air（M4， 16GB）终于能在20000 tokens上下文下运行Qwen 3.5-9B，而此前直接崩溃。这不是什么颠覆，但确实把“不可能”变成了“可以接受的慢”。
一台最便宜的MacBook Air，能跑20000 tokens上下文的9B模型，而且不崩溃。
这就是TurboQuant带来的变化。Google这个压缩算法的核心思路不是直接暴力压缩数据，而是改变数据的存储格式，让KV缓存用极坐标（角度）而非直角坐标来表示，顺带去掉了传统量化方案里必须附带的精度校正常数，还加了1bit错误修正。普通的q4量化相当于把一张全彩图片强行降成16色，TurboQuant更接近视觉无损压缩，模型“看起来”还是原来那张图。
有网友测试后指出，同等bit数下TurboQuant比llama.cpp原生的KV cache量化质量更好，尤其在3bit时差距明显。至于有多接近无损，Google官方说90%以上，实测结果众说纷纭，差距基本在噂1%级别。
目前TurboQuant还没合并进llama.cpp主线，不过社区已经有可编译的实现，有网友预测本周内就能进主分支。MLX版本在路线图末端，不过已经有人提前做了PR。
20000 tokens对于真正的AI agent来说其实还很小，Claude Code的系统提示就有12k。本地设备离长上下文代理仍有距离，只是这个距离，今年开始以肉眼可见的速度在缩短。
Google的TurboQuant算法被移植进llama.cpp后，MacBook Air（M4， 16GB）终于能在20000 tokens上下文下运行Qwen 3.5-9B，而此前直接崩溃。这不是什么颠覆，但确实把“不可能”变成了“可以接受的慢”。
一台最便宜的MacBook Air，能跑20000 tokens上下文的9B模型，而且不崩溃。
这就是TurboQuant带来的变化。Google这个压缩算法的核心思路不是直接暴力压缩数据，而是改变数据的存储格式，让KV缓存用极坐标（角度）而非直角坐标来表示，顺带去掉了传统量化方案里必须附带的精度校正常数，还加了1bit错误修正。普通的q4量化相当于把一张全彩图片强行降成16色，TurboQuant更接近视觉无损压缩，模型“看起来”还是原来那张图。
有网友测试后指出，同等bit数下TurboQuant比llama.cpp原生的KV cache量化质量更好，尤其在3bit时差距明显。至于有多接近无损，Google官方说90%以上，实测结果众说纷纭，差距基本在噂1%级别。
目前TurboQuant还没合并进llama.cpp主线，不过社区已经有可编译的实现，有网友预测本周内就能进主分支。MLX版本在路线图末端，不过已经有人提前做了PR。
20000 tokens对于真正的AI agent来说其实还很小，Claude Code的系统提示就有12k。本地设备离长上下文代理仍有距离，只是这个距离，今年开始以肉眼可见的速度在缩短。
