🫰 欢迎来到楠楠老爹的博客！

翻译：Transwan 校改：Carl Cui MLX、oMLX 和 MTPLX 都是跑在 Apple Silicon 上的本地 LLM 工具，它们都强调速度，并且名字相近，这很容易让人把它们当成三个互相竞争的产品，然后问“谁是最快的”。 实际上，它们其中一个是引擎，另外两个是建立在该引擎之上的服务器：MLX 是底层引擎，oMLX 是面向并发和长上下文的推理服务器，MTPLX 是面向单用户低延迟的推理运行时。 如果你要做底层开发、训练、微调，或者想控制生成循环，用 MLX； 如果你要服务多个用户、长上下文、本地 RAG，或者模型刚好卡在内存边界上，用 oMLX； 如果你是单人使用，主要跑编码代理或交互式助手，希望输出更快，并且模型带有原生 MTP 头，用 MTPLX； 本文围绕上面这个判断展开。 三者分别处于什么位置 可以先用一句话理解这三层： MLX：Apple 的原始计算基座，为 Apple Silicon 打造的底层框架，其他两者都导入了它。 oMLX：为服务多用户而调优的推理服务器，在 MLX 之上做连续批处理、KV Cache 分层和 SSD 缓存，适合多人请求、长上下文场景。 MTPLX：为单用户场景调优的运行时，在 MLX 之上利用模型原生 MTP 头做推测解码，适合追求速度的单用户。 MLX 直接面向 Apple Silicon 的统一内存架构。oMLX 和 MTPLX 都构建在 MLX 之上，它们本身不直接和底层硬件打交道，而是通过 MLX 来利用 Apple Silicon 的 CPU/GPU 共享内存能力。 因此把 MLX 拿去和 oMLX、MTPLX 做横向比较并不合理：MLX 是底座，另外两个是建立在底座上的运行时和服务器。 ...

AI 编程工具让代码生成、重构和修复变得越来越快，但它也放大了另一个问题：改动来得越快，越需要清晰的版本历史来解释这些改动从哪里来、为什么发生、何时进入稳定版本。 作为版本管理工具，Git 在 AI 编程时代扮演着越来越重要的角色，它可以为工程协作提供的时间线、审计记录和回滚机制。越是在 AI 能快速生成大量代码的场景下，越需要理解标准工作流，避免把临时实验、半成品功能和稳定发布混在一起。 Git 命令本身往往不是难点，难点在于搞清何时用它们。 git merge [--no-ff|--squash]、git rebase 都能把改动带到另一个分支，但它们对提交历史的处理完全不同。什么时候应该用 merge，什么时候应该用 rebase？这就是本文要回答的问题。下面以一个虚构项目 world-cup-dashboard 为例，说明这两个命令的用法，最后推荐一种围绕 git 工具的项目开发流程。 1. 分支约定 通常，一个项目会有三类分支： main 稳定发布分支 dev 日常集成分支 feature/* 单个功能分支 下面的命令，会初始化项目，并建立 dev 分支： git init git add . git commit -m "Initial project" git switch -c dev 项目开发流程：main 保持稳定，日常改动先进 dev，较大的任务从 dev 拉 feature/*。 2. 在 feature 分支开发功能 假设要做赛程页面，从 dev 分支上新建一个 feature/schedule-page 分支： git switch dev git switch -c feature/schedule-page 开发过程中可能产生几个有意义的提交： ...

翻译：Transwan 校对：Carl Cui 从 Demo 到生产的“死亡之谷” 如果你做过 AI 功能，大概率有过这样的体验：团队在开发一个让人兴奋的新功能，发布排期已经敲定；模型能给出近乎完美的回答，系统原型看起来就像德芙那样丝滑。会议室里，每个人都开始想象它上线后会变成一个流行的产品，许多次，我曾坐在这样的会议室里，那种气氛确实很棒。 然后，你开始做发布前测试： 移动端延迟飙升到 10 秒；模型在占实际用户查询 15% 的边缘案例上开始产生幻觉。经过一番努力，你从 A/B 测试结果上看不到明显的提升，因为 AI 输出的方差太大，使得传统的假设检验基本上失效。安全团队第一周就标出了 340 个失败案例，而你每天都在调试那些以各种新颖方式失败的非确定性案例。 很多时候，这不是模型能力问题，而是工程规范问题。发布 AI 产品和交付传统软件很不一样，我吃了苦头之后才明白这一点。下面这份 playbook，就是我从这些经验里总结出来的经验教训。 延迟预算 每个 AI 功能都会带来额外的延迟开销。大语言模型推理需要时间，实际可能是 500 毫秒，也可能是 5 秒，甚至 50 秒，这取决于模型大小、输入长度以及基础设施配置。对 ToC 产品来说，用户往往期待低于 200 毫秒的交互响应，所以系统响应延迟不是一个上线后再优化的小问题，而是设计阶段就必须正面处理的硬约束。 我最常见到的错误，是团队只看 p50 延迟。一个 p50 为 800 毫秒的功能听起来还不错，直到你发现它的 p90 是 15 秒。这意味着每 100 个用户里，就有 10 个要坐在那里等 15 秒以上。放到规模化产品里，这就是每天成千上万次糟糕体验。 我的做法是按交互类型定义延迟预算，而不是给所有场景设一个统一标准： 同步交互，也就是用户盯着 loading 状态等待结果的场景，应该在 1 秒内完成 渐进式交互，也就是输出逐个 token 流式返回的场景，首个 token 应该在 500 毫秒内出现，完整响应最好控制在 5 秒内 异步交互，也就是用户可以继续做别的事的场景，可以在有进度提示的情况下放宽到 20 秒左右 冷启动也要单独测量。模型加载到内存后的第一个请求，可能比后续请求慢 10 倍。如果你的流量是突发型的，冷启动会特别惩罚那些在高峰时段进入产品的高活跃用户。 ...

Claude Fable 5 发布了，Claude Fable 5 下线了，这是在 2026 年 6 月初发生在前后脚的事情。 Anthropic 在 2026 年 6 月 9 日发布了 Claude Fable 5。它被称为一个带有安全限制的 Mythos 模型，面向 Pro、Max、Team 和 Enterprise 用户开放，本来这个开放窗口就很短：从 6 月 23 日开始，Fable 5 不再包含在默认订阅计划中，而是要消耗额外额度。 然后没几天，美国政府以国家安全为由，对 Anthropic 的 Fable 5 和 Mythos 5 实施出口管制，限制外国政府、外国公司和非美国人员访问这些模型。由于 Anthropic 难以在现有系统中可靠地区分用户国籍和访问资格，最终选择暂停所有客户对这两个模型的访问。 这个新闻当然炸裂。它牵涉模型能力、安全边界、出口管制、地缘政治等等因素。 但我想谈的是另一个问题：即使 Fable 5 没有下线，我们真的应该默认使用最强模型吗？ Fable 到底是贵，还是便宜？ Fable 5 发布后，围绕它的一个很有意思的讨论是“它到底值不值”。乍一看，像是在讨论价格，其实是跟工程决断有关。 国外 Mitchell Hashimoto 在社交媒体分享过一个的测试，他让 Fable、GPT-5.5 和 GLM-5.1 处理普通的“实现这个功能”类的编码任务，最终三个模型都给出了可接受的结果。不过成本差距非常明显：GLM-5.1 不到 1 美元，GPT-5.5 大约 1.50 美元，而 Fable 跑了 40 分钟，花了 9 美元。 ...

文章开头，我们先考虑这样一个问题：在 Go 里怎么判断一个 IP 是否是私有地址？ 很多人第一反应会这样写： ip.IsPrivate() 如果在普通的业务逻辑中，这么写看起来没什么问题。Golang 标准库中关于 net.IP.IsPrivate 和 net/netip.Addr.IsPrivate 的文档也很直接：它判断一个地址是否属于 RFC 1918 定义的 IPv4 私有地址，或者 RFC 4193 定义的 IPv6 ULA 地址。 但是如果在 SSRF 防护代码里这么写，事情就变得危险了。 最近（2026 年 6 月 10 日），在 Go issue tracker 里安全研究员 Jonathan Leitschuh 就提交了一个关于 IsPrivate 的提案：proposal: net: IP.IsPrivate is widely misused as a security primitive，编号 79925。它讨论的不是一个简单的 API 命名问题，而是一个工程安全问题：当标准库提供了一个看起来“刚好能用”的分类函数，开发者很容易误把它当成安全边界。 SSRF 防护里常见的错误写法 SSRF，全称 Server-Side Request Forgery，中文通常叫服务端请求伪造。 假设一个服务提供了“根据 URL 抓取图片”的功能： https://example.com/fetch?url=https://example.org/avatar.png 服务端会根据用户传入的 URL 发起请求，然后把资源下载回来。问题是，攻击者可以把 URL 换成内网地址： ...

我们在讨论大模型时，经常会听到这样一些说法： “这个模型有 7B 参数。” “把权重下载下来就能本地跑。” “这个模型是开放权重，不是完全开源。” “量化之后权重变小了，但效果可能会下降。” 这些说法里反复出现一个词：权重（model weights）。它听起来很底层，像是机器学习工程师需要关心的东西。但如果你想真正理解大模型是怎么运行的，模型权重其实是最值得先搞清楚的概念之一。 简单说，模型权重就是模型训练之后保存下来的大量数值，它们共同构成了模型“学到的能力”。这句话很短，但背后有不少东西可以展开。 模型不是一段规则，而是一大堆参数 很多人第一次接触 AI 时，会下意识地把模型想象成一套规则系统。 比如： 如果用户问“法国首都是哪里”，就回答“巴黎”。 如果用户问“苹果是什么”，就根据上下文判断是水果还是公司。 如果用户要求写诗，就调用某种写诗模板。 但现代大语言模型不是这样工作的。它不是由工程师手写了亿万条规则，也不是一个巨大的问答数据库。它更像是一个巨大的数学函数。 你输入一段文字，模型把文字切成 token，然后经过一层又一层计算，最后预测下一个 token 最可能是什么。比如你输入： 巴黎是法国的 模型会计算出下一个 token 的概率分布。它可能认为： “首都” 概率很高 “城市” 概率也不低 “总统” 概率很低 “香蕉” 概率几乎没有 这个判断不是来自某一条明确规则，而是来自模型内部海量参数共同参与的计算。 这些参数，就是我们说的模型权重。 权重到底长什么样？ 权重在文件里并不像一本百科全书，也不像一堆可读的句子。它们本质上就是大量数字。 大概可以想象成这样： 0.0182 -0.4417 1.2093 0.0008 -2.1349 ... 当然，真实模型里的权重不是简单排成一列，而是组织成很多矩阵和张量。Transformer 的不同模块里都有各自的权重，比如注意力层（attention layer）的权重、前馈网络（feed-forward network / FFN）的权重、词嵌入矩阵（token embedding matrix）的权重等等。 这些名字听起来很工程化，但本质上仍然是一批批数值。它们只是处在模型的不同计算环节纸中：有的负责建模 token 之间的关系，有的负责非线性变换，有的负责把 token 映射成向量表示。 在直觉上，你可以先把它理解成：模型内部有无数个旋钮，训练就是调整这些旋钮，权重就是每个旋钮最终停在哪个位置。 一个 7B 模型，大约有 70 亿个这样的参数。一个 70B 模型，大约有 700 亿个参数。这也是为什么大模型文件那么大，因为你不是下载一段代码，而是在下载几十亿、几百亿个数值。 ...

翻译：Transwan 改写：Carl Cui 图片来源：TechRadar / Getty Images 2026 年 6 月 1 日，台北 Computex 2026 上，NVIDIA 发布了 RTX Spark。 单纯看参数，RTX Spark 很容易被当作又一颗高性能 PC 芯片：更强的 CPU，更强的 GPU，更大的内存，更适合 AI 的算力。硬件发布会一直就这样，只要参数堆得够高，就能引起关注。 但是对真正构建 AI 应用的人来说，它最重要的地方不是“笔记本终于能跑多大的模型”，而是它把一个被我们默认了三年的架构重新摆在桌面上：AI 推理一定要在云端吗？ 过去几年，大多数 AI 应用的默认答案都是“是”。你在对话框里输入一句话，请求离开本机，进入 OpenAI、Anthropic、Google 或其他云端数据中心。模型在远端 GPU 集群上完成推理，再把结果返回。开发者围绕这个流程实现 agent：选择模型、组织 prompt、接入工具、压缩 token 成本、处理延迟、评估隐私风险，等等。 这套架构下诞生了很多好用的产品。它让小团队也能调用最强模型，让很多产品不必自己拥有昂贵硬件。但它也悄悄建立起一种成规：只要你想使用足够强的 AI，就必须把推理交给远端数据中心。 RTX Spark 的意义，在于它开始松动这个前提。 NVIDIA 对它的定位不是普通 PC 芯片，而是面向本地 AI agents 的 Windows PC 平台。换句话说，它要让一部分过去默认上云的 AI 工作负载，回到用户面前这台机器上。对我来说，这不是硬件新闻，而是一个架构信号。 未来的 AI 系统，不应该再默认“所有推理都走云端”。一个更好的问题是：哪些推理必须在云端，哪些推理应该留在本地？ ...

翻译：Transwan 改写：Carl Cui 最近几条新闻放在一起看，很有意思：Microsoft 开始收缩部分团队对 Claude Code 的使用，把工程师引回自家的 GitHub Copilot CLI；Uber 在 2025 年底向数千名工程师部署 Claude Code，结果四个月烧完了全年 AI 编程预算；Klarna 曾高调用 AI 替代大量客服，后来又重新招聘人工客服。 这 3 个故事很容易被解读成极端的版本：一种可能会说 AI 编程工具失败了，另一种可能会说这些公司只是暂时没做好成本管理。这两种说法都不准确，我觉得问题的本质其实是：AI 确实能加速一部分工作，但是很多企业把 AI 加速的这部分工作当成了全部工作。 Microsoft：好用，不代表可无限放大 Microsoft 是 AI 时代最激进的玩家之一，向 OpenAI 投入巨资，也深度推进自家的 AI 编程工具。但 Microsoft 内部很多工程师仍然偏好 Claude Code。工具好不好用，工程师的选择已经给出了答案。 问题不在于 Claude Code 没价值，而在于它在企业规模下太容易失控。一个工程师偶尔用 AI 写代码，和一个大型部门把 AI Agent 接进日常开发，是两种完全不同的成本结构。后者消耗的不是一个固定订阅费，而是持续增长的 token、上下文、工具调用和自动化尝试。 所以 Microsoft 的动作，与其说是“停止使用 AI”，不如说是企业终于开始重新思考：哪些 AI 工具值得用，在哪些场景里用，谁来付账，成本上限在哪里，数据和工作流又该留在谁的平台里。 这不是 AI 无用，而是 AI 进入企业主流程之后，凸显出预算、治理和平台控制权的重要性。 Uber：使用量不是价值 Uber 的数据看起来更像一场成功推广：工程师采用率很高，AI 参与的代码提交比例很高，Agentic AI 功能使用率也快速上涨。按很多公司的 AI KPI，这几乎可以写进成功案例。 ...

翻译：Transwan 改写：Codex 校对：Carl Cui 关于 AI 如何影响大脑，作者调研了来自国内、外的多项研究，从多个维度探讨了 AI 对于人类认知的影响。作者还在文中附上了参考链接，这些研究的结论并不是一边倒的，有些研究的结论甚至互相冲突，不禁让我联想最近耿同学曝光的学术圈造假丑闻。于是，对于各项研究，我们保持谨慎态度；关于 AI 会对人类产生哪些影响，我们需要进行独立思考。 图片来源：Shutterstock 引言 从 2023 年 ChatGPT 改变公众对 AI 的想象开始，到 2026 年今天，MIT、Wharton、Harvard、Stanford、Microsoft、OpenAI、Oxford、Google DeepMind，以及中国多所高校的研究者，都在研究同一个问题：AI 聊天机器人到底会怎样影响人的认知、学习和心理状态？ 这些研究的类型很杂，也很有价值：有脑部扫描和 EEG 实验，有数千人规模的随机对照试验，有纵向调查、荟萃分析（Meta-analysis），也有发生在真实课堂和工作场所里的实地实验。其中既有预印本，也有已经经过同行评审的论文。 但问题在于，这些研究常常以孤立新闻的形式出现。一篇论文发布，一个耸动标题刷屏一天，然后很快被下一轮话题淹没。结果是，很多人隐约觉得 AI 可能正在改变我们的思考方式，却很少有人真正看到完整图景。 这篇文章试图把这张图拼起来。我汇总了 30 多项研究，逐项看它们到底发现了什么：当我们使用 AI 聊天机器人时，大脑活动、思维方式、学习效果和情感生活会发生哪些变化。更重要的是，我也会指出目前科学界还不知道什么。 最终浮现出来的是一个悖论。这个悖论会影响政策制定、产品设计、个人使用习惯，以及我们整体上如何和这项既令人兴奋又令人不安的新技术相处。 I. 你的大脑活动会下降 目前已经有少量但不断增加的研究，把人放进脑部扫描仪，或在他们使用 ChatGPT 时佩戴 EEG 传感器。相比自我报告和普通行为测试，神经影像学工具更接近直接观察大脑活动，因此这些研究虽然样本量通常不大，却很值得关注。 Your Brain on ChatGPT，Kosmyna 等人（arXiv 预印本，2025，N=54）：MIT Media Lab 用 32 通道 EEG 跟踪三组参与者数月内的写作过程：ChatGPT 用户、Google 搜索用户和无辅助写作者。结果显示，ChatGPT 组的神经连接最弱，比无辅助写作者低最高约 55%。随着实验推进，他们越来越依赖复制粘贴。到了第 4 阶段，当 ChatGPT 组被要求独立写作时，大脑活动仍然处于受抑状态，研究者称之为“认知债务”。相反，原本无辅助写作的人在第 4 阶段首次使用 ChatGPT 时，大脑连接反而增强。Kosmyna 的总结很关键：“时机可能很重要。” Lower engagement of cognitive control, attention, modulation networks and lower creativity in children while using ChatGPT，Horowitz-Kraus 等人（bioRxiv 预印本，2025，N=31）：这是目前少见的使用 fMRI 同时观察儿童和成人与聊天机器人互动时大脑活动的研究。成年人在认知控制网络中表现出更强的网络内连接；儿童则在认知控制、注意力和调节网络上的参与度较低。这暗示儿童大脑可能比成人更容易受到 AI 使用方式的影响。 EEG during creative design with AI tools，Wang 等人（Frontiers in Psychology，2025，N=64）：这项研究给出了相反方向的证据。使用 ChatGPT、Midjourney、Stable Diffusion 等 AI 创意工具的设计专业学生，比使用传统软件的对照组表现出更高的专注度和更好的创意表现。关键区别在于，他们不是被动接收答案，而是在主动指挥 AI 作为创意工具。 Effects of different AI-driven chatbot feedback on learning outcomes and brain activity，Yin 等人（Nature portfolio，2025，N=87）：研究者用 fNIRS 测量学生和聊天机器人互动时的大脑激活情况。不同反馈方式会激活不同区域。元认知反馈，比如“你为什么认为那是答案？”，会增加额极区激活，并与更高的迁移分数相关；中性反馈则更多激活背外侧前额叶皮层。换句话说，聊天机器人怎么和你说话，会改变你的大脑怎么工作。 NeuroChat: A neuroadaptive AI chatbot for customizing learning experiences，Baradari 等人（arXiv 预印本，2025，N=24）：MIT Media Lab 做了一个能实时监测 EEG 的原型系统。当它检测到参与度下降时，会调整回复方式。相比标准聊天机器人，它显著提升了 EEG 测得的参与度和自我报告参与感，但没有改善短期学习结果。这说明“认知脱离”不是不可避免的，产品设计可以介入。 结论：大脑成像证据仍处在早期阶段，样本量小，预印本多，而且结果并不完全一致。但整体模式已经比较清楚：被动使用 AI，也就是让 AI 直接给答案，往往会降低与费力思考相关的大脑参与；主动使用 AI，也就是把它当作需要你指挥和挑战的工具，则可能维持甚至提高参与度。关键变量不是有没有 AI，而是 AI 到底要求你的大脑做什么。当 AI 替你思考时，你的大脑自然会少做一些。 ...

翻译：Transwan 校对：Carl Cui 如果你经常使用 AI Agent，大概率碰到过这种情况：任务刚开始的时候，agent 表现得很好，能理解目标，也能选对工具，前几步推理看起来都在正轨上；但跑到第十几步、二十几步之后，质量开始变得不稳定，它可能忘了最初的要求，开始调用一些没必要的工具，或者输出明显变得粗糙。 很多人的第一反应是模型不够强，但在 Agent 场景里，问题往往不在模型本身，而在它在执行过程中看到了什么、忘掉了什么，以及被哪些无关信息干扰了。 这就是上下文工程要解决的问题，组织模型所看到的内容被称为上下文工程。过去我们谈提示词工程，关注的是如何写好一段初始指令；现在我们构建 Agent，要关心的是如何管理模型在每一步能看到的全部信息。一个可靠的 Agent，不只有一个好 prompt，而是有一套能够持续运转的工作记忆系统。 1. 什么是上下文工程，为什么 Agent 特别需要它 提示词工程解决的是“怎么把任务说清楚”。比如角色怎么设定，目标怎么描述，输出格式怎么约束，示例怎么给。这在普通聊天场景里很有效，因为聊天机器人通常只是在回答一个问题。但 Agent 不一样，它会连续执行动作，会浏览网页、调用 API、读取文件、写代码、运行命令，并根据中间结果继续做下一步决策。每一次工具调用、每一段检索结果、每一次对话历史，都会成为模型下一步推理时可能看到的上下文。 所以，上下文工程不是提示词工程的替代品，而是它在 Agent 时代的扩展。Anthropic 对这个概念的定义很直接：上下文是你从 LLM 中采样时包含进去的 token 集合；上下文工程，就是优化这些 token 的效用，让模型持续得到我们想要的结果。换句话说，关键不是把更多东西塞进窗口，而是在正确的时间、以正确的形式，让模型看到真正有用的信息。 可以把模型想象成 CPU，把上下文窗口想象成 RAM。CPU 再强，如果内存里塞满了无关内容，程序也会变慢、变乱。Agent 也是一样。上下文窗口一旦被大量工具输出、历史对话、过期信息和重复内容占满，模型的推理质量就会下降。这个过程通常不是到了上下文上限才突然发生，而是在窗口还远没有填满时就已经开始退化。 这类现象常被称为 context rot，也就是上下文腐烂。Chroma 的研究测试了多个前沿模型，发现随着输入长度增加，模型表现会变得越来越不稳定。另一个经典问题叫 Lost in the Middle：模型更容易使用上下文开头和结尾的信息，中间的信息反而容易被忽略。对 Agent 来说，这尤其危险，因为最初的任务目标、约束和关键背景，可能在几十步之后被大量工具输出埋到中间。模型虽然“看得到”，但实际上已经不怎么用它了。 一个 Agent 的上下文通常也远不止用户的一句话。它至少可能包含七类内容：系统提示、工具定义、工具调用结果、检索到的知识、对话历史、短期和长期记忆，以及 Agent 当前的状态。系统提示定义 Agent 的身份、边界、任务流程和工具使用原则；工具定义告诉模型每个工具能做什么、参数是什么、什么时候该用；工具调用结果可能是网页全文、文件内容、命令输出或 API 返回值；RAG 系统会把检索到的文档片段塞进来；对话历史记录之前发生过什么；记忆系统加入用户偏好和历史经验；Agent 状态里还有当前计划、待办事项、已完成步骤和草稿笔记。 这些内容都在争夺同一个上下文窗口。如果不加管理，窗口迟早会被填满，而且不一定是被有价值的信息填满。很多长任务 Agent 到后面变得敷衍，并不是它突然变笨了，而是它的工作记忆被污染了。 2. 四个核心策略：写入、选择、压缩、隔离 最有效的方式是把上下文工程拆成四个动作：写入、选择、压缩和隔离。这四个词看起来简单，但基本覆盖了 Agent 上下文管理的大多数问题。 ...