2026年2月

image
谷歌插件商店 ｜ GitHub

功能

给任意网站（可指定域名）添加自定义的 css 层叠样式表

用法示例

叠甲：此行为不鼓励，只供学习探讨

  1. xx 网站去水印
    在逛某个设备参数网的时候发现有个全局的水印，看着很不舒服
    打开控制台，选中元素，发现是一张、<img>标签引入的图片，直接用选择器选中该图片display: none
    （别学，可能有点刑？我只为了看得舒服，不截取转发数据）
  2. 试着给 2Libra 移除“今日热议”列表的头像框
    心血来潮想让“今日热议”列表更简约一点，用 css 把头像去掉
    由于没有标志性的类名，只能这样定位
    复制
    div[data-right-sidebar="true"] > div:nth-child(2) {
    /*普通头像*/
    div:has(> img) {
        display: none
    }
    /*svg 头像*/
    div:has(> svg) {
        display: none
    }
    /*动图的头像，被加了一层 canvas*/
    div:has(> div > canvas) {
        display: none
    }
}

    大致效果：
    image
    3. 临时修复一些网站的样式问题
    image
    4. 其他用法你可以发挥想像力，比如改变边框线条粗细，改变左右布局、固定用户信息卡片，简单屏蔽一些低级广告等等
    （Jimmy 会不会揍我，精心设计的排版被我改得面目全非）

话说，这个应该选前端节点还是浏览器扩展节点，好难受，都想要

整理 ｜华卫

 

“简历基本上就是 AI 的时间线”，这是许多人对 Gemini 背后的核心推动者、谷歌首席人工智能科学家 Jeff Dean 的评价。从 2000 年代初重写谷歌搜索全栈到重启万亿参数稀疏模型，再到将 TPU 与前沿机器学习研究协同设计，Jeff Dean 以一种低调的方式，几乎塑造了现代 AI 技术栈的每一层。他亲历了多轮规模革命：从 CPU、分片索引，到能跨文本、视频、代码进行推理的多模态模型。

 

近日，他在一场深度对话中的犀利言论备受热议。不少业内人士直呼，“信息量超大”。在这场访谈中，Dean 抛出了诸多独家观点与极具前瞻性的判断。

 

“大一统模型的时代真的来了。关键在于，模型正在变得越来越强，不再需要领域专家。”他表示，未来是专用模型加模块化模型的组合，可以同时拥有并在不同场景下调用 200 种语言、超强机器人模块、超强医疗模块。“模型知识是可安装的，像下载软件包一样。”

 

作为“计算机历史上最高产的工程师之一”，Dean 还大方分享了自己现在用 AI 写代码的方式，并表示，“未来很可能每个人都能拥有 50 个虚拟实习生，让他们组成小组，只需要对接 5 个小组，让他们各自干活。”

 

而且，Dean 详细透露了谷歌内部“冲前沿”的模式和推动团队架构改进和模型能力升级的思考。除此之外，他还提出并拆解了多个有趣的问题，包括：为什么蒸馏是每一次 Flash 模型突破的核心驱动力、为何能耗而非算力正成为真正瓶颈、如何提前 2–6 年 进行硬件与模型的协同设计、为什么下一次跃迁不只来自更大的上下文窗口而是来自能“仿佛在处理万亿 token” 的系统等。

 

以下是详细对话内容，我们在不改变原意的基础上进行了翻译和删减，以飨读者。

下一代模型，哪些旧思路值得捡起来？

Shawn Wang：今天我们请到了谷歌首席 AI 科学家 Jeff Dean，欢迎您。能邀请到您真的太荣幸了，我看过您无数场演讲，您的职业生涯堪称传奇。首先必须要说，恭喜你们拿下了"帕累托前沿"（Pareto Frontier）。

 

Jeff Dean：谢谢。帕累托前沿确实很棒，能站在这个位置很不错。

 

Shawn Wang：对，我觉得是两者兼备。你既要占据帕累托前沿，要有顶尖能力，也要兼顾效率，然后提供大家愿意用的一系列模型。这其中一部分源于你们的硬件工作，一部分来自模型工作，肯定还有很多日积月累的独门秘诀。能看到这一切如此丝滑地整合在一起，真的非常震撼。

 

Jeff Dean：是的没错。就像你说的，这不是单一因素，而是技术栈从上到下一整套东西的结合。所有这些加在一起，才让谷歌能够做出能力极强的大模型，同时也通过软件技术，把大模型的能力迁移到更小、更轻量的模型里，这些小模型成本更低、延迟更低，但在自身规模下依然能力很强。

 

Alessio Fanelli：那在守住帕累托前沿下限这方面，你们有多大压力？我感觉很多新实验室都在拼命冲性能上限，因为要融资之类的。而你们有数十亿用户。我记得你们早年做 CPU 的时候就讨论过：如果每个谷歌用户每天用三分钟语音模型，你们就得把 CPU 数量翻倍。现在谷歌内部是怎么讨论的？怎么权衡“冲前沿”和“必须落地部署”这两件事？

 

Jeff Dean：我们一直希望拥有前沿、甚至推动前沿的模型，因为只有这样才能看到去年、半年前不存在的新能力。但同时我们也知道，这些顶尖模型虽然有用，但对很多更广泛的场景来说，速度偏慢、成本偏高。所以我们的思路是：同时做两条线，一条是高能力、低成本的模型，支持低延迟场景，让大家能更轻松地用在智能体编程等任务上；另一条是高端前沿模型，用于深度推理、解决复杂数学问题这类场景。两者不是二选一，而是都有用。而且通过蒸馏这一关键技术，你必须先有前沿模型，才能把能力蒸馏到小模型里。所以这不是非此即彼，而是相辅相成。

 

Alessio Fanelli：你和 Jeffrey 在 2014 年就提出了相关方案。

 

Jeff Dean：别忘了还有 L’Oreal Vinyls 那篇工作。

 

Alessio Fanelli：都是很早以前了。我很好奇，你怎么看待这些思路的迭代周期？比如稀疏模型这类想法，你们会怎么重新评估？下一代模型里，哪些旧思路值得重新捡起来？你参与过很多后来影响巨大的想法，但在当时未必能看出来。

 

Jeff Dean：蒸馏最早的出发点是，我们当时有一个很大的图像数据集，3 亿张图。我们发现，如果为不同图像类别训练专用模型，比如这个专攻哺乳动物，那个专攻室内场景，先在更宽泛的图像上预训练，再对聚类后的类别用增强数据微调，效果会好很多。但如果把这 50 个模型当成一个大集成模型，实际部署并不现实。于是蒸馏的思路就来了：把这些独立的专家模型“压缩”成一个可以实际部署的形态。这和我们今天做的事本质差不多，只是现在我们不再用 50 个模型的集成，而是先训练一个超大模型，再把它蒸馏成小得多的模型。

 

Shawn Wang：我还在想，蒸馏是不是和强化学习的革新也有关系？我试着表达一下，强化学习会让模型在分布的某一部分突飞猛进，但可能在其他区域有损失，是一种不太均衡的技术。但或许可以通过蒸馏把它“收回来”。大家的普遍期望是：提升能力的同时不在其他地方退步。这种无损能力融合，我感觉一部分应该可以通过蒸馏实现，但我还没太理清，相关论文也不多。

 

Jeff Dean：我觉得蒸馏的一个核心优势就是：你可以用很小的模型，配合超大数据集，通过多次遍历数据，从超大模型那里拿到逻辑概率输出，引导小模型学到只用硬标签学不到的行为。我们观察到，蒸馏可以让小模型接近大模型的效果。这对很多人来说都是最佳平衡点。现在 Gemini 已经好几代了，我们都能让新一代的 Flash 版本达到甚至大幅超越上一代 Pro 版本的效果。我们会继续这么做，因为这是一个很健康的方向。

 

Shawn Wang：达拉之前问过：最早的路线图是 Flash、Pro、Ultra。你们是不是一直拿着 Ultra 当“母模型”，从它里面蒸馏？Ultra 就是那个终极源头吗？

 

Jeff Dean：我们有很多种模型，有些是内部模型，不对外发布或部署；有些是 Pro 级别模型，我们也可以从它蒸馏出 Flash 级别模型。这套能力很重要，推理时的动态扩展也能提升模型效果。

 

Shawn Wang：明白。而且显然 Flash 的成本优势带来了绝对统治力。最新数据好像是 50 万亿 token，我记不清了，反正每天都在变。

 

Jeff Dean：对，希望市场份额也在往上走。

 

Shawn Wang：我是说从成本上看，Flash 太经济了，几乎什么场景都能用。现在 Gmail 里有，YouTube 里有，到处都有。

 

Jeff Dean：我们也在越来越多的搜索产品里用上它，包括各种 AI 模式。

 

Shawn Wang：我的天，Flash 都进 AI 搜索模式了？我都没想到。

 

Jeff Dean：Flash 模型的一大优点不只是成本更低，还有延迟更低。延迟其实非常关键，因为未来我们会让模型做更复杂的事，生成更多令牌。比如你不再只让它写个循环，而是让它写一整套软件包。能低延迟完成这些就特别重要。Flash 是一条路径，我们的硬件平台也支撑了很多服务能力，比如 TPU，芯片间的互联性能极高，非常适合长上下文注意力、稀疏专家模型这类技术。这些对规模化部署至关重要。

 

Alessio Fanelli：那从 Pro 到 Flash 的蒸馏，会不会存在一个临界点，差不多滞后一代？我有种感觉：很多任务今天 Pro 已经饱和了，到下一代，同样任务在 Flash 的价位上就能饱和。再过两代，Flash 几乎能做所有人需要的一切。那当大部分用户都满足于 Flash 时，你们怎么说服内部继续投入去推 Pro 的前沿？我很好奇你怎么看。

 

Jeff Dean：如果用户的需求分布是静止不变的，那确实会这样。但现实往往是：模型越强，人们对它的期待就越高。我自己就有体会：一年前我用模型写代码，简单任务还行，复杂的就不行；现在我们在复杂代码上进步巨大，我就会让它做更难的事。不止编程，现在你会让它分析全球可再生能源部署、写一份太阳能报告，这些都是一年前没人会让模型做的复杂任务。所以你依然需要更强的模型去拓展边界，同时也能帮我们找到瓶颈：哪里还不行，该怎么改进，让下一代更强。

“把整个互联网纳入上下文”，让模型处理万亿 token

Alessio Fanelli：你们内部会用一些专属基准或测试集吗？因为每次公开的都是那几个基准，从 97% 涨到 99%，你们内部怎么推动团队：我们真正要做的目标是什么？

 

Jeff Dean：公开基准有它的价值，但生命周期有限。刚出来时很难，模型只有 10%–30% 正确率，你可以一路优化到 80%–90%。但一旦到 95% 左右，边际收益就极低了，要么是能力已经达标，要么是训练数据里出现了泄露或相似内容。所以我们有一批不公开的内部基准，确保训练数据里完全没有，代表模型目前还不具备、但我们希望它拥有的能力。然后我们去评估：是需要更专业的数据？还是架构改进？或是模型能力升级？怎样才能做得更好。

 

Shawn Wang：能不能举个例子：某个基准直接启发了架构改进？我正好顺着你刚才的话问。

 

Jeff Dean：我觉得 Gemini 模型尤其是 1.5 首次推出的长上下文能力，就是这么来的。我们当时的目标就是。

 

Shawn Wang：当时所有人一拥而上，全是一片飘绿的图表，我就在想：怎么大家同一时间都突破了？

 

Jeff Dean：Stack Benchmark 这种基准，在 1k、2k、8k 上下文长度上早就饱和了。我们真正在推的是 100 万、200 万上下文的前沿，因为这才有真实价值：你可以把上千页文本、几小时视频放进上下文里真正使用。单针查找已经饱和，我们需要更复杂的“多针查找”，或是更真实的长上下文理解与生成任务，才能衡量用户真正需要的能力，而不只是“你能不能找到这个商品编号”。

 

Shawn Wang：本质是检索，是机器学习里的检索。我想站在更底层一点说：你看到一个基准，发现需要改某个架构才能解决，但你真的应该改吗？有时候这只是一种归纳偏置。就像曾在谷歌工作的 Jason Wei 说的：你可能短期赢了，但长期不一定能扩展，甚至以后还要推翻重做。

 

Jeff Dean：我不太会纠结具体要用什么方案，而是先想清楚：我们到底需要什么能力？我们非常确定，长上下文是有用的，但现在的长度还远远不够。你真正想要的，其实是回答问题的时候能把整个互联网都纳入上下文，对吧？但这靠单纯扩容现有方案是做不到的，现在的算法复杂度是平方级的。一百万 tokens 已经是现有方案的极限了，你不可能做到十亿、更别说万亿 tokens。但如果你能营造出一种“模型可以关注万亿 tokens”的效果，那就太厉害了，应用场景会多到爆炸。

 

这相当于能把整个互联网当成上下文，能处理 YouTube 视频的所有像素，以及我们能提取到的深层表征；不只是单个视频，而是海量视频。在个人版 Gemini 层面，只要你授权，模型还能关联你所有的个人状态：你的邮件、照片、文档、机票信息等等。我觉得这会非常非常有用。问题在于，如何通过算法改进和系统级优化，让模型真正有意义地处理万亿 tokens。

 

Shawn Wang：对了，我之前算过一笔账：一个人每天不停说 8 小时话，一天最多也就生成 10 万 tokens 左右，这个量现在完全装得下。

 

Jeff Dean：没错。但如果你想理解所有人上传的视频内容，那就完全不是一个量级了。

 

Shawn Wang：而且还有个经典例子：一旦跳出文本，进入蛋白质这类信息密度极高的领域，数据量就爆炸了。

 

Jeff Dean：Gemini 从一开始就坚持做多模态。对很多人来说，多模态就是文本、图片、视频、音频这些人类熟悉的模态。但我认为，让 Gemini 理解非人类模态也非常重要。比如 Waymo 自动驾驶汽车的激光雷达数据、机器人传感器数据，还有各类医疗模态：X 光、核磁共振、医学影像、基因组信息等等。世界上可能有几百种数据模态，我们至少要让模型知道：这是一种有意义、有价值的模态。哪怕你没有在预训练里把所有激光雷达、MRI 数据都训进去，至少加一小部分进去也是很有用的，能让模型对这类信息有基本概念。

 

Shawn Wang：正好趁这个机会，我想问一个一直想问你的问题：有没有“王者模态”，也就是能统摄其他所有模态的模态？举个简单例子：视觉在像素级别就能编码文本，Deepseek 那篇 OCR 论文就证明了这点。而且视觉也能处理音频，因为可以转成语谱图，本质也是视觉任务。这么说的话，视觉是不是就是王者模态？

 

Jeff Dean：视觉和动态时序非常重要。这里说的动态，是视频，而不是静态图片。进化让眼睛独立演化了 23 次，是有原因的，感知周围世界的能力太关键了，而这正是我们希望这些模型具备的能力。模型要能解读我们看到、关注到的事物，并帮我们利用这些信息去做事。

 

Shawn Wang：说到动态理解，我必须夸一句：Gemini 目前依然是市面上唯一原生支持视频理解的模型，我经常用它看 YouTube。

 

Jeff Dean：其实很多人还没真正意识到 Gemini 模型的能力。我在演讲里举过一个例子：给模型一段过去 20 年里 18 个经典体育瞬间的 YouTube 集锦，里面有乔丹总决赛绝杀、足球进球等等。你直接把视频丢给它，说：“帮我做一个表格，列出所有事件、发生时间和简短描述。”

它真的能直接从视频里抽出信息，生成一张 18 行的表格。大多数人根本想不到，模型可以直接把视频转成结构化表格。

 

Alessio Fanelli：你刚才提到“把整个互联网纳入上下文”，谷歌本身就是因为人类处理不了全网信息，才需要做搜索排序。这对大模型来说逻辑完全不一样：人类看搜索结果可能只看前五六条，但对大模型来说，是不是要给它 20 条高度相关的内容？谷歌内部是怎么思考的：如何打造一种比传统人类搜索更宽泛、覆盖更广的 AI 模式？

 

Jeff Dean：即使在大模型出现之前，我们的排序系统也是这么做的：索引里有海量网页，大部分都不相关，先用轻量方法筛出一批相关的，比如缩到 3 万个文档，再一步步用更复杂的算法、更精细的信号去精排，最终只展示给用户 10 条左右结果。大模型系统的思路不会差太多。你看似要处理万亿 tokens，但实际流程是：先筛出大约 3 万个文档、大概 3000 万有用 tokens；再从中精挑细选出 117 个真正值得关注的文档，用来完成用户任务。

 

你可以想象这套系统：先用轻量模型、高并发处理，筛出初始 3 万候选；再用更强一点的模型把 3 万缩到 117；最后用最强的模型去深度理解这 117 个内容。只有这样的系统，才能营造出“模型能处理万亿 tokens”的效果，就像谷歌搜索确实在搜全网，但最终只给你最相关的一小部分。

 

Shawn Wang：我经常跟不了解谷歌搜索历史的人说，Bert 刚出来就直接用进了搜索，效果提升非常明显。这对谷歌来说肯定是最核心的数据。

 

Jeff Dean：大模型带来的文本表示方式，让我们跳出了“关键词必须精确匹配网页”的硬限制，真正做到主题和语义相关，而不是字面对应。

 

Shawn Wang：我觉得很多人根本没意识到，大模型已经接管了谷歌、YouTube 这种超高流量系统。YouTube 有个语义标识机制，每个 token 对应一个视频，用码本预测视频，以 YouTube 的规模来说，这太夸张了。

 

Jeff Dean：最近 Grok 也用在了可解释 AI 上。其实在大模型大规模用于搜索之前，我们就一直在弱化“用户输入什么就必须匹配什么”的思路。

 

Shawn Wang：你有没有梳理过这一路的演进历程？

 

Jeff Dean：我 2009 年在一个网络搜索与数据挖掘会议上做过一次演讲，讲了 1999 到 2004、2005 年左右，谷歌搜索和检索系统的五六代架构演进，那部分内容我们没有正式发过论文。2001 年发生了一件关键的事：我们在多个维度扩容系统。一是把索引做大，覆盖更多网页，质量自然会提升，索引里没有的页面，你永远搜不出来。二是扩容服务能力，因为流量暴涨。我们用的是分片架构，索引变大就加分片，比如从 30 片变成 60 片，以此控制延迟。流量变大就增加副本。

 

后来我们算了一笔账：一个数据中心有 60 个分片，每个分片 20 个副本，一共 1200 台带硬盘的机器。这些机器的内存加起来，刚好能把整个索引全放进内存。于是 2001 年，我们直接把全量索引塞进内存，效果直接起飞。在此之前，你必须非常谨慎，因为每个查询词都要在 60 个分片上触发一次磁盘寻道，索引越大效率越低。但全量内存索引后，哪怕用户只输入三四个词，你扩展成 50 个相关词都没问题，可以加同义词，比如 restaurant、restaurants、cafe、bistro 全都一起搜。我们终于能开始理解词义，而不是死磕用户输入的字面形式。

 

那是 2001 年，远在大模型之前，但思路已经是：放宽严格字面匹配，靠近语义理解。

“写大量代码前，先在脑子里推演一遍设计空间”

Alessio Fanelli：你设计系统的原则是什么？尤其是在 2001 年，互联网规模每年翻几倍、涨三倍，现在大模型也是每年规模和能力跳一大截。你有什么一贯的设计原则？

 

Jeff Dean：首先，设计系统时，必须先抓住最关键的设计参数：每秒要扛多少查询？互联网有多大？索引要做多大？每个文档存多少信息？怎么检索？流量再涨两三倍还能不能扛？我一个很重要的设计原则是：把系统设计成能扩容 5～10 倍，但不用更多。因为一旦变成 100 倍规模，整个设计空间会完全不一样，原来合理的方案会直接作废。比如从磁盘索引到内存索引，就是流量和机器足够多之后才变得可行的，一下子打开了全新架构。

 

我很喜欢在写大量代码之前，先在脑子里把设计空间推演一遍。回到谷歌早期，我们不仅在疯狂扩大索引，索引更新频率才是变化最夸张的指标。以前是一个月更新一次，后来我们做到了单页面一分钟内更新。

 

Shawn Wang：这就是核心竞争力对吧？

 

Jeff Dean：没错。新闻类查询，如果你的索引还是上个月的，那就完全没用。

 

Shawn Wang：新闻是个特殊场景，你们当时就不能把它拆成独立系统吗？

 

Jeff Dean：我们确实推出了谷歌新闻，但用户在主搜索里输新闻相关关键词，也必须拿到最新结果。

 

Shawn Wang：所以你们还要分类页面，判断哪些页面该高频更新、频率是多少。

 

Jeff Dean：背后有一整套系统，用来决定页面的更新频率和重要度。有些页面虽然变化概率低，但只要更新价值极高，依然会非常频繁地重新抓取。

 

Shawn Wang：说到延迟和存储，我必须提你的一篇经典之作：《每个程序员都该知道的延迟数字》。背后有什么故事吗？就是随手整理的？

 

Jeff Dean：里面大概列了八九种、十来项指标：缓存失效开销、分支预测失败开销、内存访问开销、从美国发数据包到荷兰的时间等等。

 

Shawn Wang：顺便问一下，为什么是荷兰？是因为 Chrome 的关系吗？

 

Jeff Dean：我们当时在荷兰有个数据中心。其实这就回到了快速估算这件事上。这些都是最基础的指标，你可以拿它们来做判断：比如我要做图片搜索、生成缩略图，我是提前算好缩略图，还是实时从大图里生成？需要多少带宽？会产生多少次磁盘寻道？你只要手里有这些基础数值，几十秒就能在脑子里做一遍推演。等你用更高级的库写软件时，也要培养出同样的直觉：比如在某种结构里查一次数据大概要多久。

 

Shawn Wang：这就是简单的字节换算，没什么特别的。我在想，如果你要更新那篇文章的话……

 

Jeff Dean：我觉得很有必要去算一下模型里的计算量，不管是训练还是推理。

 

Jeff Dean：一个很好的视角是：你需要从内存里搬运多少状态，片上 SRAM、加速器的 HBM、DRAM，还是网络传输？然后对比一下，数据搬运的成本，和矩阵乘法单元里一次实际乘法运算的成本差多少。其实计算成本非常非常低，根据精度不同，大概不到 1 pJ。

 

Shawn Wang：哦，懂了，你是用能耗来衡量的。

 

Jeff Dean：对，核心就是能耗，以及如何做出能效最高的系统。在同一块芯片上，只是从一边的 SRAM 传到另一边，能耗就可能达到 1000 pJ。这就是为什么加速器一定要用批处理（batching）。如果你把一个模型参数从片上 SRAM 搬到乘法单元，要花 1000 pJ，那你最好把这个参数重复用好多次。这就是 batch 维度的意义。batch 设成 256 就还好，但如果是 1，那就非常不划算。

 

Shawn Wang：对，没错。

 

Jeff Dean：因为你花了 1000 pJ，就为了做一次 1 pJ 的乘法。

 

Shawn Wang：我从来没听过从能耗角度去解释批处理。

 

Jeff Dean：这就是大家用 batch 的根本原因。理论上，batch=1 延迟最完美，但能耗和计算效率的浪费实在太大了。

 

Shawn Wang：延迟是最好的。

 

Jeff Dean：对，但代价太高。

TPU 的神级决策：反过来调整模型架构

Shawn Wang：那有没有类似当年“把索引全放进内存”这种神级技巧？比如 NVIDIA 这次押注 SRAM 搞 Grok，引起很大轰动。我在想，你们做 TPU 的时候是不是早就看到这一点了？毕竟要支撑你们的规模，肯定提前预判到了。从这些现象里，你们总结出了哪些硬件创新或洞察？

 

Jeff Dean：TPU 有很规整的结构，2D 或 3D 网格，很多芯片连在一起，每块都挂着 HBM。

在部署某些模型时，从 HBM 拿数据比从片上 SRAM 拿数据，成本和延迟都高得多。所以如果模型够小，你可以用模型并行，把它分散到很多芯片上，吞吐量和延迟都会明显提升。把一个中小模型打散到 16、64 块芯片上，如果全都能放进 SRAM，提升会非常巨大。这不算意外，但确实是个好技巧。

 

Alessio Fanelli：那 TPU 的设计呢？你们怎么决定改进方向？举个例子，有没有办法把 1000 pJ 降到 50？值得为了这个专门设计一颗新芯片吗？最极端的就是有人说，直接把模型烧进 ASIC。领域变化这么快，多少事值得用硬件来解决？内部是怎么讨论的？

 

Jeff Dean：我们 TPU 芯片设计架构团队和高层建模专家之间有大量协作。因为你需要协同设计：根据机器学习研究的未来方向，去定义下一代 TPU 应该长什么样。做 ML 硬件的人都知道，今天开始设计一颗芯片，可能两年后才进数据中心，还要用三四年。你必须预测未来 2～6 年，人们会想跑什么机器学习计算。所以，要有一批人去研究：哪些思路在那段时间里会起效、会更重要。这样我们才能把有用的硬件特性，加到未来几代的 TPU 里。

 

Shawn Wang：芯片迭代周期是两代之后？

 

Jeff Dean：差不多。小改动可以塞进下一代，大改动必须提前更早启动设计。只要条件允许，我们都会这么做。有时会加一些试探性的功能，占芯片面积不大，但如果成了，能直接快 10 倍；就算不成，也就浪费一点点面积，问题不大。但如果是特别大的改动，我们就会非常谨慎，做大量实验来确认方向是对的。

 

Alessio Fanelli：那有没有反过来的情况：因为芯片设计已经定了，所以模型架构不能那么走，因为不匹配？

 

Jeff Dean：肯定有。你会反过来调整模型架构，让它在那一代芯片上训练和推理更高效。两边是互相影响的。比如未来一代芯片支持更低精度，你甚至可以提前用那个精度训练，哪怕当前一代还不完全支持。

 

Shawn Wang：那精度到底能压到多低？

 

Jeff Dean：很多人在说三值精度。我个人非常支持极低精度，因为能省巨大量的能耗。能耗是按每比特传输算的，减少比特数是最直接的方式。业界已经在极低比特精度上取得了很多效果，再配上一组权重的缩放因子，效果就很稳。

 

Shawn Wang：有意思，低精度，但带缩放权重。我以前没想过这点。

 

Shawn Wang：说到这，我觉得精度这个概念本身在采样场景里就很奇怪。我们堆了这么多算力超强的芯片，最后前面还要挂一个随机数生成器。现在业界有往能量基模型、能量导向处理器发展的趋势，你显然也思考过，能说说你的看法吗？

 

Jeff Dean：确实有几个有意思的方向。能量基模型是一个，不按顺序逐 token 解码的扩散模型是另一个。还有 speculative decoding（推测解码），相当于一个很小的草稿 batch，先预测 8 个 token，有效 batch size 就扩大 8 倍，最后接受其中 5～6 个。这样分摊下来，把权重搬到乘法单元里的成本就被摊薄了，能带来几倍的提升。这些都是非常好的技巧。而且一定要从真实能耗、延迟、吞吐量这几个角度去看，你才会找到正确的方向：要么能服务更大模型，要么同等模型成本更低、延迟更低。

 

Shawn Wang：这个思路在理论上很吸引人，只是还没真正成为主流。但某种意义上还挺有美感的，如果从硬件底层就设计好，我们就不用搞那么多取巧的办法。

 

Jeff Dean：还有一些更前沿的方向，比如模拟计算基底，而不是数字电路。理论上能效可能极高，但问题是你要跟数字系统对接，数模、模数转换那部分会吃掉大部分能效优势。但即便只看数字方向，靠更专用、更高效的硬件，能效上我们还有巨大的提升空间。

大一统模型时代到来，不需要专家了？

Alessio Fanelli：你还看到哪些有意思的研究方向？或者有什么在谷歌暂时没法做，但希望其他研究者去尝试的方向？

 

Jeff Dean：我们的研究布局已经很广了。有很多开放问题：怎么让模型更可靠，能做更长、更复杂、包含大量子任务的事情？怎么实现模型调用其他模型当工具，组合起来完成远比单模型更有意义的工作？这部分非常有意思。还有，怎么让强化学习在不可验证的领域也能生效？这是个很棒的开放问题。如果能把数学、代码上的进步，复制到其他没那么容易验证的领域，模型能力会再上一个大台阶。

 

Alessio Fanelli：之前 Noam Brown 来节目里说，他们已经用深度推理证明了这点。某种意义上，你们的 AI 模式也是不可验证的。我在想这里面有没有共通的线索？比如都在做信息检索、返回 JSON。是不是检索就是那个可以打分、可以验证的部分？你怎么理解这个问题？

 

Jeff Dean：可以用其他模型来评估第一个模型的结果，甚至做检索。比如让另一个模型判断：检索回来的内容相关吗？2000 条里最相关的 50 条是哪些？这类方法其实非常有效。甚至可以就是同一个模型，只是换个提示词，从“检索系统”变成“评判器”。

 

Shawn Wang：我总觉得有一道很明显的坎：好像简单的事都做完了，剩下的都特别难。其实每年大家都这么觉得。尤其是 RLVR 这块，所有人都在问：不可验证问题的下一阶段到底怎么做？然后大家都说：不知道，等着评判。

 

Jeff Dean：这个领域好就好在，有无数聪明人在给这些难题想创造性的解法。大家都看得很清楚：模型在某些事上很强，但在边缘场景就会拉胯。提出技巧、验证效果、推动进步，就是这个领域研究的核心。你想想两年前，我们连 GSM8K 这种小学数学题都费劲。现在呢？模型已经能纯靠语言解国际奥数、埃尔德什级别的问题。一年半里能力的跃迁是惊人的，其他领域我们暂时还没完全看清楚路径，但有一些已经看到曙光，我们会全力把这种飞跃复制过去。

 

Shawn Wang：没错。

 

Alessio Fanelli：比如 YouTube 缩略图生成，这个功能会非常实用，我们太需要了。这简直就是 AGI 级别的需求。

 

Shawn Wang：对内容创作者来说绝对是。

 

Jeff Dean：我不是 YouTube 创作者，所以对这个问题没那么敏感，但我知道很多人很在意。

 

Shawn Wang：确实大家很看重。毕竟大家真的会“以封面论视频”。回到奥数那个话题，我到现在还觉得很不可思议：一年前我们还在搞 AlphaProof、AlphaGeometry 这些专门的系统，今年直接一句“算了，全都塞进 Gemini 就行”。你怎么看这件事？过去大家普遍认为，符号系统和大模型必须结合，但后来大家直接选择：全都用大模型解决。

 

Jeff Dean：我觉得这很合理。人类确实会操作符号，但我们脑子里大概率没有一个明确的符号系统，而是某种分布式表征，本质上接近神经网络。大量神经元在特定情况下产生激活模式，让我们能推理、规划、做思维链，发现一条路走不通就换一条。在很多方面，基于神经网络的模型，其实是在模拟我们直觉中大脑里发生的事情。所以对我来说，把完全离散、独立的符号系统，和另一套完全不同的思考机制分开，从来就不太合理。

 

Shawn Wang：有意思。对你来说可能理所当然，但一年前我可不是这么想的。

 

Jeff Dean：你看奥数任务也是一样，最开始要翻译成 Lean 语言、用专门工具，第二年还要专用几何模型，到今年直接换成一个统一模型，就是线上正式版模型，只是多给了一点推理资源。

这其实很好，说明通用模型的能力大幅提升，不再需要专用模型。这和 2013 到 2016 年那波机器学习的发展非常像：以前每个任务都要单独训模型，识别路标训一个，语音识别训一个。现在，大一统模型的时代真的来了。关键在于，这些模型在从未见过的新任务上泛化能力如何，而它们正在变得越来越强。

 

Shawn Wang：而且不再需要领域专家。我之前采访过相关团队的人，他说：我完全不懂奥数，不知道比赛在哪举行、规则是什么，我只管训模型。挺有意思的，现在只要有机器学习这种通用技能，给数据、给算力，就能搞定几乎任何任务。这大概就是所谓的“苦涩教训”吧。

 

Jeff Dean：我认为，通用模型在绝大多数情况下都会胜过专用模型。

未来模型知识直接“装”，“像下载软件包一样”

Shawn Wang：这点我想再追问一下。我觉得这里有个漏洞：模型的容量是抽象的，它能装下的知识只有参数量对应的比特数。谁都知道 Gemini Pro 有几万亿参数，但具体没人知道。但像 Gemma 这类模型，很多人想要开源、本地跑的小模型，它们必然装不下所有知识。大模型有条件什么都知道，但小模型在蒸馏、压缩的过程中，其实会记住很多没用的东西。所以我们能不能把知识和推理剥离开？

 

Jeff Dean：你确实希望模型把推理做到最强，同时具备检索能力。让宝贵的参数空间去记那些可以查到的冷僻知识，其实不是最优使用方式。你更希望参数用在更通用、更多场景都有用的能力上。但同时，你也不想让模型完全脱离世界知识。比如知道金门大桥大概有多长，对“桥有多长”有个基本概念，这类常识是有用的。它不需要知道世界上某个偏僻小桥的长度，但具备相当规模的世界知识是有帮助的，模型越大，能装的就越多。但我确实认为，把检索和推理结合起来，让模型擅长多轮检索，会是关键方向。

 

Shawn Wang：并且基于中间检索结果做推理，会让模型看起来比实际强得多。比如个人版 Gemini。

 

Jeff Dean：我们不太可能把我的邮件拿去训 Gemini。更合理的方式是：用一个统一模型，把检索我的邮件、我的照片当成工具，让模型基于这些信息去推理、交互，分多轮完成任务。这样才合理。

 

Alessio Fanelli：你觉得垂直领域模型有意义吗？比如很多人说“我们要做最好的医疗大模型、最好的法律大模型”。这些只是短期过渡方案吗？

 

Jeff Dean：不，我觉得垂直模型是有价值的。你可以从一个很强的基座模型出发，然后在医疗、机器人这类垂直领域富集数据分布。我们不太可能把所有机器人数据都塞进 Gemini 训练，因为要保持能力均衡。我们会给它看一部分机器人数据，但如果你想做一个极致优秀的机器人模型，就要在通用模型基础上，再用更多机器人数据去训练。它可能会因此损失一点翻译能力，但机器人能力会大幅提升。

 

我们训练基座 Gemini 时，一直在做这类数据配比权衡。我们很想加入 200 多种语言的数据，但这会挤占其他能力：可能 Pearl 编程就没那么强了，Python 还能保住，但其他小众语言或多模态能力可能会受影响。所以我认为，未来是专用模型加模块化模型的组合。你可以同时拥有 200 种语言、超强机器人模块、超强医疗模块，在不同场景下调用。比如处理医疗问题时，就把医疗模块和基座模型一起用上，效果会更好。

 

Shawn Wang：可安装的知识。

 

Jeff Dean：没错。

 

Shawn Wang：像下载软件包一样。

 

Jeff Dean：一部分可安装知识可以来自检索，另一部分应该来自预训练，比如提前用 1000 亿、1 万亿 token 的医疗数据训好。

 

Shawn Wang：Gemma 3 的论文里已经有一点这个味道了。

 

Alessio Fanelli：问题是，你到底需要几千亿 token，才能追上前沿基座模型的进步速度？如果我想做一个更强的医疗模型，而主模型 Gemini 还在不停进化，我需要 500 亿 token 吗？1000 亿？如果需要一万亿医疗 token，那数据根本就不存在。

 

Jeff Dean：医疗是一个特别有挑战的领域。很多医疗数据我们没有合适的访问权限，但很多医疗组织希望用自己的私有数据训模型。所以机会在于：和大型医疗机构合作，为它们定制模型，效果很可能比只用公开数据训练的通用模型更好。

 

Shawn Wang：对了，这和语言的话题也有点像。你最喜欢举的一个例子就是：把低资源语言放进上下文里，模型直接就能学会。

 

Jeff Dean：对，我们用过一个叫 Calaba 的语言，资源极度稀缺，全世界只有大概 120 个人说，还没有文字。

 

Shawn Wang：直接放进上下文就行，把整个数据集塞进去。

 

Jeff Dean：像索马里语、阿姆哈拉语这类语言，世界上是有一些文本的。我们不会把所有数据都放进 Gemini 训练，但放得越多，模型能力就越强。

 

Shawn Wang：我个人对语言学有副业兴趣，大学时修过几门课。如果我是语言学家，能用上这些模型，我会去问关于语言本身的根本性问题。比如萨丕尔—沃尔夫假说：你说的语言在多大程度上影响你的思维？有些语言里存在其他语言没有的概念，也有很多概念是重复的。还有一篇很有名的论文提到“柏拉图表征”：比如“杯子”的图片，配上大量带“cup”的文本，最后表征会收敛到差不多同一个位置。这套逻辑理论上也适用于语言，但有些地方不适用，而这些不适用的地方，恰恰反映了人类独有的概念差异，有些概念甚至英语里都不存在。这部分我觉得非常有意思。

 

Jeff Dean：我早年做过一个模型，把文本表征和图像模型结合起来，在 ImageNet 这类数据上训练，然后把顶层表征融合。你会发现，给模型一张它从未见过的新图片，它往往能给出正确标签。比如，模型学过望远镜和双筒望远镜，但没见过显微镜。给它看显微镜的图片，它居然能输出“microscope”这个标签，尽管从来没见过带这个标签的图。

 

Shawn Wang：这太酷了。

8 岁就开始琢磨：用算力做大神经网络

Shawn Wang：以你的视野，我们聊了硬件、模型、研究，你最希望被问到哪一类问题？

 

Jeff Dean：有件事我觉得挺有意思的。1990 年我本科毕业论文就做的是神经网络并行训练。那时候我就觉得，神经网络是正确的抽象方向，只是算力远远不够。系里那台 32 核的并行计算机，只能跑出稍微有趣一点的模型，远远解决不了真实问题。直到 2008、2009 年，摩尔定律带来了足够的算力，加上更大的数据集，神经网络才真正开始解决大家关心的真实问题：语音、视觉，最后是语言。

 

2011 年底我在谷歌开始做神经网络时，就坚定地认为：我们要用大规模并行计算，把神经网络的规模拉上去。我甚至把本科论文里的一些思路重新捡了起来，包括模型并行、数据并行，并且做了对比。可以说，我从 8 岁就开始琢磨这些事了，只不过那时候叫法不一样。

 

Shawn Wang：那篇论文是公开的吗？我们能找到吗？

 

Jeff Dean：可以的，网上就能查到。过去这 15 年里，把这些技术整合在一起，全力做规模化，是非常关键的。这既包括硬件层面的进步，比如推动 TPU 这类专用芯片的研发，也包括软件层面，做更高层的抽象，让人们能更方便地把想法交给计算机去实现。

 

Shawn Wang：你当时是否认同这个观点？或者现在有不同的复盘？

 

Jeff Dean：说的是算力配额的“大脑市场”机制？

 

Shawn Wang：对，算力配额。David 之前在 OpenAI 做负责工程的副总裁，后来也去过谷歌。他的核心观点是：OpenAI 敢于 all in，把赌注全压在一件事上；而谷歌更加“民主化”，每个人都有自己的配额。如果你相信规模化很重要，那这就是一个全公司层面的关键决策。

 

Jeff Dean：我部分同意。事实上，我当时还写过一页纸的备忘录，说我们把资源碎片化是很愚蠢的。那时候，谷歌研究室和 Brain 团队在做大语言模型，其他部门在做多模态，DeepMind 那边也在做 Chinchilla、Flamingo 这些模型。结果就是，我们不仅算力被拆分，最优秀的人才和精力也被拆分了。我当时就说，这样太傻了，为什么不合并起来，集中力量做一个从头就是多模态、全能的大一统模型？这就是 Gemini 项目的起源。

 

Shawn Wang：你这一页纸的备忘录成了，很不错。当时名字想好了吗？大家都知道，Gemini 是你取的。

 

Jeff Dean：是我取的。当时还有另一个候选名字，但我觉得，两个团队合在一起，某种意义上就像双胞胎。而且 NASA 也有 Gemini 计划，是阿波罗登月之前非常关键的一步。所以这个名字很合适，代表双子携手。

史上最高产工程师写代码：带 50 个“AI 实习生”

Alessio Fanelli：很棒。我知道时间不多了，最后很好奇：你现在怎么用 AI 写代码？你可以说是计算机历史上最高产的工程师之一。我看过一篇文章，讲你和 Sanjay 的合作方式，你说过：要找到和你思维合拍的人结对编程，两个人加起来才会是互补的合力。我就在想，你怎么看待代码智能体？你会怎么塑造一个和你思维兼容的代码助手？现在的工具你打几分？未来方向在哪？

 

Jeff Dean：首先，代码工具相比一两年前已经强太多了，现在真的可以把更复杂的任务交给它们。人类工程师和代码模型之间的互动方式，其实会反过来决定它怎么配合你。你可以让它写完备的测试，也可以让它帮你 brainstorm 性能优化思路。你和它交互的方式，会决定它的输出风格、解决问题的粒度，以及你希望它更自主，还是更频繁地和你对齐。没有哪一种风格是万能的。有些问题你需要高频交互，有些问题你直接说“帮我把这个实现出来”就行。

 

未来会出现更多独立软件智能体，帮你代劳各种事情。难点在于设计合适的人机交互模式、界面，决定它什么时候该打断你：“我需要更多指引”或者“我做完了，下一步做什么”。这部分我们还没有终极答案，模型变强之后，交互模式还会变。你可以想象成：你带了 50 个实习生，你会怎么管理？如果他们能力很强，你可能真的会想要 50 个。

 

Shawn Wang：但管理成本也很高。

 

Jeff Dean：没错。但未来很可能每个人都能拥有 50 个虚拟实习生。那你该怎么安排？你肯定会让他们组成小组，你不用管 50 个人，只需要对接 5 个小组，让他们各自干活。最终会演变成什么样，我也不完全确定。

 

Alessio Fanelli：那人与人的协作呢？AI 辅助编程的好处是能带来新的思路。但如果有大量代码智能体在并行写代码，其他人要介入就很困难，因为要追上巨量的上下文。你会不会担心，团队里的人会变得更孤立？

 

Jeff Dean：有可能。但反过来想，传统没有 AI 辅助的团队，50 个人干活，组织结构天然是层级化的，各组之间交互不多。但如果是 5 个人，每人管理 50 个虚拟智能体，这 5 个人之间的沟通带宽，反而可能比传统 5 个组长协调 50 个人的模式更高。

 

Alessio Fanelli：那你自己的工作节奏有改变吗？会不会花更多时间和人对齐架构、设计目标？

 

Jeff Dean：我觉得很有意思的一点是：以前教别人写软件，都会说要把需求文档写清楚，但大家其实都不当回事。但现在，如果你要让智能体帮你写代码，你必须极其清晰地定义需求，这会直接决定输出质量。你没说它要处理某种边界情况、没强调性能要求，它就可能不做。人们会越来越擅长清晰、无歧义地描述目标，这其实不是坏事，不管是不是工程师都是一项有用的技能。

 

Shawn Wang：我开玩笑说，现在给模型下指令，和高阶高管沟通没区别，像写内部备忘录一样，字斟句酌。而且我认为多模态非常重要。谷歌的 Anti-Gravity 团队一上来就做了很强的多模态，包括视频理解。这是你能给模型的、最高带宽的“提示词”，非常强。

 

Alessio Fanelli：你平时是怎么整理自己脑子里那些经验的？比如你那种超强的性能优化直觉，大家都说你一眼就能看出哪里能提效。那如果把这些经验写成通用文档，再让模型去检索学习，会不会很有价值？就像边界情况，就是个很好的例子。做系统的人脑子里都有特定的边界场景，但现在每次都要重复说一遍。你觉得人们会花更多时间去写文档、提炼通用经验吗？

 

Jeff Dean：我确实认为，写得好的软件工程指南会非常有用。既可以给模型当输入，也可以让其他开发者参考，让他们在写提示词时，更清楚底层系统应该实现什么。不一定需要为每个场景单独定制，只要有通用指南，放进代码智能体的上下文里，就会很有帮助。比如分布式系统，可以列出：要考虑哪些故障类型、有哪些处理方案，像 Paxos 复制、双写请求、只要一个返回即可容忍故障等。把 20 个这类分布式系统设计技巧总结一下，就能很大程度提升代码智能体生成可靠、健壮分布式系统的能力。

延迟能突破 1 万 token/s，人类不用读代码了

Shawn Wang：我就在想，Gemini 什么时候能自己造出 Spanner（解决了分布式系统 CAP 不可能三角的关系型数据库）？

 

Alessio Fanelli：搞不好代码它早就全看过了。这就是个好例子。CAP 定理是公认的真理，不能打破，但最后你们还是做出了看似打破它的东西。

 

Shawn Wang：我很好奇，模型算不算某种意义上“打破”了它？你会说你们打破了 CAP 定理吗？在特定假设下，比如精准时钟同步的前提下。

 

Alessio Fanelli：有时候你不必死守所谓的真理。但模型有时候会过于相信你告诉它的东西。

 

Jeff Dean：回到提示词和迭代的问题。我一直想做一个对比实验：一种是，用三次快速但普通的模型调用，中间加入人类对齐，人看一遍结果，再给新提示；另一种是，花很久写一个超长、超精细的提示词，直接丢给一个超强模型一次做完。我想看看这两种方式的效果差距。很多时候效果不好，不是模型不行，而是需求描述不完整，模型根本不可能猜到你想要什么。

 

Shawn Wang：就是定义不清晰，模型可以生成 10 个结果，只有一个是你想要的。而用轻量快模型多轮交互，反而够用。

 

Jeff Dean：我非常重视延迟。低延迟交互体验，比慢 10 倍、20 倍的系统舒服太多。未来我们会看到模型、软件、硬件整体延迟比现在低 20 倍、50 倍，这对需要大量交互的系统至关重要。

 

Shawn Wang：现在有两个极端，一边是极致快，另一边是 DeepThink 这种极致深思考。

 

Jeff Dean：如果不考虑成本和延迟，所有人都会一直用 DeepThink。如果底层硬件和系统把延迟再提 20 倍，成本下来，没理由不用。

 

Shawn Wang：帕累托曲线会一直往上走，不断外扩。我们来问点预测吧。你有没有什么一直关注的小测试，或者哪些东西你觉得现在还不够好，但很快能实现？

 

Jeff Dean：我说两个不算这一类的预测吧。第一，了解你、能访问你所有授权的个人数据的个性化模型，相比通用模型会带来巨大的价值提升。能关联我所有的邮件、照片、看过的视频、一切信息，这会非常有用。第二，越来越专用的硬件会让模型延迟更低、能力更强、成本更亲民，这一点也会非常关键。

 

Shawn Wang：你说的低延迟，大家一般用 token 每秒衡量。现在大概是 100 token/s，你觉得能到 1000？10000 有意义吗？

 

Jeff Dean：绝对有。因为有思维链推理。你可以并行做更多轮推演，生成更多代码，再用思维链校验正确性。10000 token/s 会非常强。

 

Shawn Wang：到 10000 token/s，人就不用读代码了，直接让模型生成。

 

Jeff Dean：它最终不一定输出 10000 token 代码，可能只有 1000 token 代码，但背后有 9000 token 的推理过程，这样的代码质量会高得多。

 

Alessio Fanelli：就像“如果我有更多时间，我会写一封更短的信”。Jeff，今天太棒了，感谢你的时间。

 

Jeff Dean：很开心，谢谢邀请。

 

参考链接：

https://youtu.be/F_1oDPWxpFQ

 

飞机上的景色,连接青海与甘肃的大地

喀什随手拍

木吉乡火山与十八罗汉峰

慕士塔格峰与冰川

路边随手拍

总行程包含往返日一共 7 天,稍稍有点赶,但核心景色已经体验了 7788.都说北疆看风景,南疆看人文,但这次旅程下来南疆的景色也让我刮目相看

1.除非我的某一项极强，比如资产千万以上才有可能覆盖我肢体残疾的问题，找到和我水平类似的女孩，不然只能向下兼容
2.世界上的人都是动物，都是自私的，都是权衡利弊的选择，人是权衡利弊的产物
3.利用谈恋爱的状态，但是不要挑明关系会很爽，这有利于事业
4.夫妻两个人都强势的家庭不稳定
5.我要找个愿意照顾我，听我话的

最近在主导重构团队的市场异动监控系统时，我反复在一个痛点上卡壳：业务逻辑跑得很完美，但偏偏总是因为数据接入端的脆弱而导致整条链路瘫痪。之前为了图快，项目里充斥着大量的网页端暴力抓取代码，或者是定时去拉取滞后的 CSV 静态表单。这种原始的交互方式，不仅响应速度根本跟不上高频的市场节奏，维护成本也极其高昂。在彻底推翻了旧架构并引入了专业的直连数据流之后，我才终于体会到了让数据如流水般稳定涌入系统的畅快感。

在后端架构设计的范畴里，“系统的高容错率与可用性”永远是一切业务展开的绝对先决条件。

曾几何时，我也在开发中陷入过误区，把大量的计算资源倾注于生成复杂的趋势分析图表和多维聚合大屏上。但实盘跑起来后，现实给了我沉重一击：一旦最底层的实时行情、买卖盘口或者资金流向数据出现了网络阻塞或部分字段丢包，建立在此基础上的任何高级告警策略都会瞬间失效，甚至发出完全相反的错误指令。
为了彻底根治这个顽疾，我在新版框架的中间件层强制注入了两项防御性规范：
第一，所有对外部数据源的拉取动作，必须包裹在最严格的异常捕获作用域内。网络抖动不可避免，但我们的核心守护进程绝不能因为一次 Timeout 就发生主线程崩溃。
第二，在反序列化阶段实施极其严苛的字段级完整性校验。无论是当前的搓合价、瞬时成交量还是振幅区间，但凡出现 None 值或类型不匹配，立刻触发降级策略直接丢弃该记录，坚决杜绝脏数据污染下游的业务池。这些处理看似增加了代码的冗余度，但在复杂的网络交互中，它们是保证数据链路长久存活的核心屏障。

落实到代码编排上，如何安全、高效地把外部的 JSON 数据流转化为系统内部的实例对象，是这套架构的重中之重。在这次重构中，我剥离出了这样一个极其精简的访问器逻辑：


import time
from alltick import AllTickAPI

client = AllTickAPI(api_key="你的API_KEY")

def get_stock_quotes(symbol):
    try:
        response = client.market.quotes(symbols=symbol)
        if response and response.get("data"):
            return response["data"]
        else:
            print(f"{symbol} 未返回行情数据")
            return None
    except Exception as e:
        print(f"获取行情异常: {e}")
        return None

quotes = get_stock_quotes("AAPL")
if quotes:
    print(f"AAPL 最新价: {quotes[0]['last_price']}")

这段逻辑的工程美学在于它的“边界感”。它专职负责将云端的最新快照安全拽回本地内存，并利用严密的 try-except 体系将所有潜在的 I/O 风险消化在了函数作用域内部，从而为整个异步监控体系奠定了一块坚如磐石的基石。

当干净的数据流蓄势待发，我们面临的下一个课题就是如何最大化地压榨这些数据的业务价值。在目前的微服务体系中，这些数据主要在两个核心处理器中流转：

首当其冲的是低延迟的事件触发机制。当关键标的的价格波动触及了我们写入配置中心的阈值红线时，系统必须做出无缝响应：

if quotes and quotes[0]["last_price"] >= 150:
    print("AAPL 价格突破 150 美元，需要关注")

这种完全解耦的推送机制，彻底取代了早期人工低效的网页轮询，确保了每一次关键波动都能被系统级捕捉。

其次，则是用于长周期维度下的技术因子提纯。我们会将拉取到的连续时间轴片段进行二次聚合，在内存中演算出均线等平滑指标，为后续的趋势判断提供参考系：

history_data = get_stock_quotes("AAPL")  # 假设返回多条历史报价
ma_10 = sum([item["last_price"] for item in history_data[-10:]]) / 10
print(f"10日均价: {ma_10}")

虽然算法层面并不复杂，但它能有效地过滤掉高频的杂讯，让原本晦涩难懂的原始报文变得具备统计学意义的“可读性”，这对系统投研模块的支撑是无可替代的。

在长期的重构与迭代中，我也逐渐沉淀了几条系统优化的最佳实践：比如必须引入漏桶或令牌桶机制来精确控制出网的请求频控，既保障了时效性又避免了被服务端主动熔断；要求将所有抓取失败的上下文详细记录至 ELK 堆栈中，方便后期针对性排查网络瓶颈；同时在工厂模式的设计下，确保底层的拉取逻辑拥有足够的柔性，以应对未来随时可能扩增的指数或行业板块等新维度的接入。

回首这次重构，我越来越意识到，能够找到一个诸如 AllTick 这样极其靠谱的数据服务提供商，并运用严谨的系统工程化思维将庞杂的市场动向转换为机器可以理解的语言，这才是任何一个金融开发项目中最具护城河价值的环节。

今天是第一天上班，十分不想干活，那些年前说年后再干的工作都堆上来了，但还是不想干。

虽然工作繁忙，但是怎么能阻挡得了想摸鱼的心呢。

「需求是做不完的，生活是自己的」

评论区抽 3 个，每人 18.88 红包送上，祝大家新年多摸鱼。

截止时间，明天（ 1.28 ）下午 6 点开抽。

微信图片_20260213092724_2808_3.jpg

中国大模型不断搅动全球AI格局。Kimi K2.5近期所展示的Agent Swarm架构，将智能体的协作模式从"单兵作战"推进到"集群智能"时代。K2.5支持100个子智能体并发、层级化编排，以及1500次的并行工具调用，这些技术参数标志着AI正式具备了“工业化流水线”的组织能力，引领了国内外的AI创新。

与此同时，海外开发者对OpenClaw的追捧，也揭示了一个并行趋势：当自动化能力不断变强，用户开始将目光从AI "能做什么"转向"如何与现有工作流无缝融合"。

这种融合的关键，在于智能体能否深度嵌入操作系统。枫清科技Fabarta个人专属智能体龙虾版的推出，恰好回应了这一需求，将企业级安全管控与本地执行能力下沉到个人终端。

基于苹果Mac mini深度适配的Fabarta个人专属智能体龙虾版已于1月底正式发布，也被称为“中国版龙虾”。该产品的一个重要的体验升级在于其构建的"长期记忆体系"。其内置的本地个人记忆库，基于企业级RAG能力，能够针对用户的常用术语、项目背景、文件路径及个人偏好，在本地逐步构建起可控的长期记忆体系，实现更精准的知识检索与复用。

这种"越用越懂"的特性，是对交互范式的突破：机器在保护隐私的前提下，持续适应人的思维路径，而非要求用户适应机器的逻辑。

而更具前瞻性的是，Fabarta个人专属智能体不是孤立的生产力工具，而是连接个人工作流与企业知识体系的桥梁。Fabarta个人专属智能体龙虾版既能作为Mac Studio企业知识中台（EKC）的终端延伸，实现"数据不出域"的精细管控，又能独立运行于个人设备，满足敏感数据的本地闭环处理。同时，Fabarta个人专属智能体已完成麒麟操作系统的深度适配，在麒麟KART系统级AI底座的加持下，该产品为信创生态中的政企用户提供从硬件到应用的全链路可信AI方案。

该智能体云端协同的弹性架构，恰是对Kimi 智能体集群思路的另一种诠释——不是通过堆叠智能体数量实现广度，而是通过操作系统级的深度整合，实现个人与组织、本地与云端的无缝切换。

正如软件与Windows的耦合、移动应用与iOS/Android的共生，个人智能体的真正普及，需要AI从云端应用转变为本地设备的基础设施层，换言之，个人智能体将不再是需要刻意调用的外部工具，而是能成为用户工作流中默认且无处不在的底层能力。

在行业探索智能体集群的横向扩展时，枫清科技持续深耕智能体与操作系统、企业系统、个人习惯的纵向整合。在这样的双轨演进中，技术的终极关怀始终是让人更从容地驾驭机器，更安心地释放创造潜能。

即刻登录枫清科技官网（https://fabarta.com/my-agent）下载Fabarta 个人专属智能体，把工作放心交给你的 “个人超级智能体”！

​

摘要：
混合检索通过融合向量检索、稀疏检索和全文检索三种模态，克服单一检索方式的语义或关键词盲区，提升召回率与精确度。OceanBase推出的AI原生搜索数据库seekdb支持单次查询同时调用三种模态，并提供内置加权融合机制及预设搜索模式。配合Agentic RAG动态选择策略，提升召回与精度。

  1. 从 Corrective RAG 到多模态检索

Corrective RAG（CRAG），通过文档评分和托底机制来提升 RAG 系统的可靠性，主要解决检索结果的质量验证问题。但在检索环节本身，传统 RAG 系统还存在一个根本性的问题：单一检索方式的盲区。

本章将解决这个问题：如何通过混合检索（Hybrid Search）结合多种检索方式，提升检索的召回率和精确度。

  1. 为什么需要混合检索？

2.1 什么是混合检索？

混合检索（Hybrid Search）是一种结合向量检索、稀疏检索、全文检索三种模态，通过加权分数融合来提升检索效果的技术。它通过让不同检索方式互补，克服单一检索方式的盲区，从而提高召回率和精确度。

2.2 单一检索方式的问题

我们先来看看单靠一种检索方式会遇到什么问题。

向量检索的盲区：

向量检索擅长理解语义和概念，但它会遗漏精确的关键词。比如你搜索 “GAAP” 或 “Q3 2023” 这样的专有名词，向量检索可能会返回一些概念相似但实际不相关的结果。还有一个问题是过度泛化——它可能返回概念上相似，但实际上答非所问的文档。

关键词检索的盲区：

关键词检索擅长匹配精确的术语，但它不理解语义。比如你搜索 “machine learning”，它找不到包含 “AI” 的文档；你搜索 “revenue”，它找不到包含 “earnings” 或 “income” 的内容。这就是语义盲区的问题。

问题的本质在于：向量检索会遗漏关键词，关键词检索会遗漏语义——每种方法都有自己的盲区。

2.3 混合检索：融合三种模态

混合检索的思路是：既然单一方法都有盲区，那就把它们组合起来。具体来说，混合检索结合了三种互补的检索方式：

三种检索方式各有侧重：

Vector Search （向量检索） → 理解语义相似度
Sparse Search （稀疏检索） → 匹配关键词和同义词
Full-text Search （全文检索） → 精确短语匹配

2.4 Hybrid RAG vs Corrective RAG

混合检索和纠错机制解决的是不同阶段的问题：

这两种技术可以完美配合：用混合检索提升检索质量，再用 Corrective RAG 进行质量验证。

  1. 三种检索模态详解

理解了混合检索的必要性后，我们来深入了解构成混合检索的三种核心模态。

3.1 向量检索（Vector Search)

向量检索通过将文本转换为稠密向量（Dense Embeddings，通常 768-1536 维），然后使用余弦相似度测量向量之间的角度，返回语义上最相似的文档。

它的优势在于理解概念和语义关系，能够处理释义和同义表达。但它无法精确匹配特定术语，比如 “GAAP” 或 “SKU-12345” 这样的专有名词。

适用场景：概念性查询，比如 “What causes inflation?”

3.2 稀疏检索（Sparse Search)

稀疏检索使用 TF-IDF（词频-逆文档频率）提取关键词，可以在词汇表内扩展同义词，基于关键词权重进行匹配（不是精确字符串匹配）。

TF-IDF 的原理是：Term Frequency × Inverse Document Frequency——在整个文档集中越罕见的词获得越高的权重。

稀疏检索的优势是能够匹配相关术语，比如 revenue、earnings、income 这些同义词，而且不需要嵌入模型。但它受词汇表维度限制，难以处理稀有专有名词。

典型应用场景：工具选择（Tool Selection）

稀疏检索在混合检索中发挥关键词匹配作用，特别在工具选择、术语敏感查询（如专有名词、技术缩写）中表现优异。

3.3 全文检索（Full-text Search)

全文检索通过构建带分词的倒排索引（Inverted Index），应用 BM25 评分算法（改进的 TF-IDF，加入了文档长度归一化），返回精确短语匹配的结果。

BM25 是 TF-IDF 的改进版本，它加入了文档长度归一化，避免长文档获得不公平的高分。

全文检索的优势是能够精确匹配短语（如 “Item 1A Risk Factors”），处理稀有专有名词，支持精确章节定位。但它无法处理拼写错误或变体，也不理解语义关系。

适用场景：精确章节查找，比如 “查找第 10-K 报告的风险因素章节”

3.4 三种模态的选择

没有单一模态是最好的，关键是根据查询模式组合使用：

  1. seekdb：AI 原生的搜索数据库

4.1 seekdb 是什么？

seekdb 是 OceanBase 推出的 AI 原生搜索数据库，它将向量存储、关系数据、全文搜索整合到一个统一的平台中。传统方案需要使用专门的向量数据库，会带来额外的运维成本和系统复杂度，seekdb 通过统一的多模型引擎解决了这个问题。

4.2 seekdb 的核心优势

4.3 为什么选择 seekdb 实现混合检索？

单次查询就能调用 3 种模态，无需调用外部服务
原生加权融合，内置 RRF 和线性组合算法
自动索引同步，向量、稀疏、BM25 索引自动维护
MySQL 协议，兼容现有工具和驱动
可以无缝迁移到 OceanBase 集群

  1. 实战：实现混合检索

5.1 准备环境：

加载 embedding 模型

配置 OceanBase 连接

5.2 加载文档

首先加载源文档演示混合搜索。

5.3 初始化混合存储

启用三种搜索模式：

1密集向量：通过嵌入实现语义相似性

2稀疏向量：通过 TF-IDF 加权计算关键词重要性

3全文检索：精确短语和关键词匹配

5.4 生成稀疏向量

稀疏向量使用 TF-IDF（词频-逆文档频率）来表示关键词的重要性。

词频（TF)：一个词在文档中出现的频率逆文档频率（IDF)：一个词在语料库中出现的稀有度或重要性

基于词汇：直接将词映射到索引（无哈希冲突）

我们将构建一个自定义的 TF-IDF 编码器，使其能够在 OceanBase 的 50 万维度限制内工作。

5.5 准备全文内容

全文搜索需要独立的索引内容。我们将通过元数据增强页面内容

5.6 添加包含三种模态的文档

将文档存储到向量数据库，并建立三种索引。

5.7 测试各个模态

分别测试三种检索方式，对比搜索结果。

每种模态返回不同的结果——向量检索找到语义相关的内容，稀疏检索找到关键词匹配，全文检索找到精确短语。

5.7.1 向量搜索

5.7.2 稀疏向量搜索（关键词匹配）

5.7.3 全文检索（精确匹配）

  1. 高级混合检索

在前面的步骤中，我们已经启用了三种检索模态并分别测试了它们的效果。现在的问题是：如何将这三种检索方式有效地组合起来？

这就是高级混合检索要解决的核心问题：通过加权分数融合，自动组合多种检索模态，获得比单一模态更好的检索效果。

6.1 内置分数融合机制

OceanBase 提供了 advanced_hybrid_search() 方法，可以自动组合三种模态的检索结果。

工作原理：

并行执行三种检索 - 同时运行向量检索、稀疏检索、全文检索
分数归一化 - 将每种模态的分数标准化到 0-1 范围
加权融合 - 应用权重公式：final_score = w₁×vector + w₂×sparse + w₃×fulltext
排序返回 - 按融合后的分数排序，返回 Top-K 结果
所有的分数归一化和融合逻辑都在 seekdb 内部自动完成，开发者只需要关注权重配置即可。搜索模式预设

6.1.1 搜索模式预设

不同类型的查询需要不同的权重配置。我们可以定义几种常用的搜索模式：

Balanced（平衡模式）

适合通用查询，比如 “Nike business in 2023”。权重配置：Vector 40%、Sparse 30%、Fulltext 30%。

Semantic（语义模式）

适合概念理解，比如 “What is Nike‘s strategy?”。权重配置：Vector 70%、Sparse 20%、Fulltext 10%。

Keyword（关键词模式）

适合特定术语、数字查询，比如 “Nike earnings2023”。权重配置：Vector 20%、Sparse 60%、Fulltext 20%。

Exact（精确模式）

适合法律文本、章节查找，比如 “Item 1A Risk Factors”。权重配置：Vector 10%、Sparse 20%、Fulltext 70%。

6.2 权重调优建议

从平衡模式开始 - 在不确定时使用 40/30/30 作为基准
根据业务场景调整 - 分析实际查询日志，找出主要查询类型
A/B 测试验证 - 对比不同权重配置的检索效果
允许动态调整 - 不同查询可以使用不同的权重配置

6.3 融合算法选择

除了线性加权组合，seekdb 还支持其他融合算法：

线性组合（Linear Combination) - 加权平均，适合大多数场景
RRF(Reciprocal Rank Fusion) - 基于排名融合，对分数尺度不敏感
最大值融合 - 取各模态的最高分，适合“或”逻辑
推荐做法：先使用线性组合，如果效果不理想再尝试 RRF。

💡 扩展知识：本节提到的 RRF 和最大值融合是常见的融合算法，seekdb 支持多种融合策略。具体 API 请参考官方文档。

  1. Agentic Hybrid RAG：让 Agent 选择最优策略

7.1 为什么结合 Agentic + Hybrid Search?

将智能决策和多模态检索结合，可以获得两者的最佳效果。

仅混合检索的特点：多模态（V+S+F）、更好的召回，但权重固定、总是执行检索。

Agentic + 混合检索的特点：动态搜索模式、多步推理、在不需要时跳过检索、多次搜索结果综合。

核心价值在于：Agentic RAG + Hybrid Search = 智能决策 + 多模态检索。

7.2 定义带动态搜索模式的工具

创建一个让 Agent 选择最佳搜索策略的工具。

可用的搜索模式：

balanced（通用场景 40/30/30）
semantic（概念和语义 70/20/10）
keyword（关键词查询 20/60/20）
exact（精确短语 10/20/70）
Agent 会分析查询并自动选择最佳模式。

7.3 使用 LangChain 创建 Agent

构建一个能够动态使用混合检索的智能 Agent。

Agent 能力：在搜索前分析查询类型、选择最优搜索模式、对复杂问题进行多步搜索、将结果综合为连贯的答案。系统提示词指导 Agent 何时使用每种搜索模式。

进阶提示：让 Agent 输出自定义权重（如 0.5/0.3/0.2），而不是预设名称，以获得更精细的控制。

7.4 Agent 实战示例

观察 Agent 如何动态选择搜索策略。

财务数据查询：

用户：“Nike revenue fiscal 2023?” → Agent 分析 → search_mode=“keyword”，理由：使用关键词模式查找特定数字。

战略问题：

用户：“What is Nike‘s innovation approach?” → Agent 分析 → search_mode=“semantic”，理由：使用语义模式理解概念。

章节查找：

用户：“Find Item 1A Risk Factors” → Agent 分析 → search_mode=“exact”，理由：使用精确模式进行精准匹配。

关键优势：Agent 根据查询分析智能选择搜索策略——无需手动调优。

  1. 核心要点总结

8.1 三种模态

Vector（向量检索）→ 语义理解
Sparse（稀疏检索）→ 关键词 + 同义词扩展
Fulltext（全文检索）→ 精确短语

8.2 加权融合

四种预设模式：balanced / semantic / keyword / exact
支持自定义权重组合模态
根据你的领域调优权重

8.3 Agentic 方法

让 Agent 选择搜索策略
每个查询的动态模式选择
复杂问答的多步搜索

8.4 seekdb by OceanBase

原生混合检索支持
单次查询 → 3 种模态
轻松迁移到 OceanBase 集群

8.5 实践建议

从平衡模式开始：在不确定查询类型时使用 40/30/30 权重
让 Agent 做决策：通过系统提示词指导 Agent 选择搜索模式
迭代调优：根据实际查询日志调整权重预设
组合使用技术：混合检索 + Corrective RAG = 更强大的系统

  1. 总结

在本章中，我们深入理解了混合检索（Hybrid Search）的多模态融合机制，学习了如何结合向量检索、稀疏检索和全文检索三种模态，并使用 seekdb 构建了完整的 Agentic Hybrid RAG 系统。让我们一起探索 Agentic RAG 和混合检索的更多可能性！

最近搜了一下 text 2 image image 2 video 的关键词，发现国内有很多开发者坐了类似的出海站点，看到他们都是一个类似模板的界面。

连多语言都还没做好就先上线推广了，另外使用赠送积分生成图片的效果也很比较差。

刚好有做副业的想法，也打算调研下怎么搞一搞

个人 bg：双非一本（学校勉强算个双一流），非信息技术类专业。
职业经历：
24 毕业

  1. 毕业后在团子做产品，但是当时所在部门不是很好，发展也不顺利，一年后组织调整让我背绩效走人。
  2. 当时对我来说打击还是挺大的，也有一个月没上班，在 npy 、家人的压力下个人认为算是病急乱投医地到了一家小公司，还是干产品，不过是 AI 方向的。
  3. 现在的公司很小，非常没有成长，个人知道是在这里浪费生命，但是确实家庭情况也不支持长时间空窗（个人未来大部分全靠自己，也还没结婚）

现状以及迷津：

  1. 个人非常厌恶小公司，很想回大厂，但是明显感觉自己简历脏了很多（团子出来还能接到 dd 、ali 等的面试，到这个小公司后目前还没一个正经大厂的产品面试），个人也知道，产品本来就卷经历、卷学历，现在简历脏了之后确实难度不小。
  2. 今年年后开始高强度找工作，但是目前还没进展，难免焦虑...想了解下：有没有大佬有类似经验可以参考的？以及如果我在想，如果 3 、4 月还没找到合适的，gap 一段时间有意义吗？（有可以支撑半年的积蓄）。

下面是一些我提出这个问题的具体背景：

  1. 我的情况是一个肢体残疾人，家里给介绍的相亲对象基本也类似，但我想找一个健全人，因为未来生活中，各种困难风险，都需要健康的身体或者乐观的心态去面对
  2. 对于和父母相处的家庭关系我是持比较失望态度的，因为在我小时候他们争吵太多，我每次听到的话都是“要不是因为你，我早就和你爸爸离婚了”，在这个前提下，我和父母的关系至少在我的角度看没有那么亲密，如果找一个终身需要人照顾的妻子，那么就不得不和他们住在一块或者交集很多，这是我现在不适应不知道如何处理的。
  3. 对于未来生活和孩子的期望，我期望至少有一个人能带给孩子健全的生活，照顾孩子等各个方面，不能让孩子承担我的不幸。举个例子：开家长会，健康的妈妈去和老师同学见面，也避免了孩子未来在同学中被嘲笑孤立当作异类。因为这是我的童年，我不想让类似的事发生在孩子身上
  4. 我始终秉承一个理念就是任何人帮助，都不如自己拥有来的实在。对于未来生活父母可以给到我帮助。无论我的妻子是正常人还是残疾人，但是这种帮助永远是有限的。我们自己能做到是比靠别人帮助更让我安心的
  5. 试错成本大是从我的现实状况和年龄考虑的。33 岁的年纪，残疾的身体，如果在打上一个离异的标签。恐怕以后都不会有机会了。

想问一问大家，我该以何种心态自处或者如何做

过年期间相亲,老家介绍了一个女生,小我 2 岁,人也算漂亮小圆脸(至少对我而言是偏好看方向的),家里长辈都认识(所谓的知根知底),现在接触两次, 能感觉出对面也是有想法的.

但是我动摇了

聊下来是感觉对方太乖了, 或者说生活太枯燥了, 不抽烟不喝酒无不良嗜好, 王者荣耀 60 星. 日常社交活动也很平淡,她说的是她公司同事除了老板, 其他同事也是不抽烟的至少她没见过. 跟朋友出去玩也就是吃饭聊天这些.

就是很普通常见的女生爱好, 视频网站都没会员, 用盗版 APP 随缘免广告追剧, 不用小红书, 不上 B 站, 倒是刷抖音.

我现在的问题是, 明明双方都在很努力的找共同话题, 但是聊不到一块去, 最后都是落回到工作/疫情经历/做饭 这种话题上.

感觉自己有点贱了, 这是个好女生, 但是我发现自己没有那种,就,勾人的想去了解沟通在一起的感觉.

以前是烦好些女生上来就各种生病,肩不能担手不能提的, 让你照顾人家.
现在是发现碰到普通人, 人家也没那么多事需要你去帮助照顾, 反而不知道如何相处了.

我也是一个人独处惯了,向来都是独立解决所有问题, 现在是真的没法想象两个人一起生活是什么样.
或者说我找对象的目的和原因是什么, 感觉就是到年龄了得有个对象这样.

我得有个憧憬和理由, 想听一下你们的经历.

在高频量化交易开发中，标的复牌信息的实时性是策略落地的核心前提，尤其是跟踪JMG这类重点标的时，复牌节点的信息时延，会直接影响策略信号捕捉效率与交易决策的有效性。对于量化开发者而言，如何高效、稳定获取复牌数据，快速筛选契合策略的标的，让数据获取环节适配策略执行节奏，是高频交易开发中的常见需求与痛点。

在实际开发与落地过程中，传统复牌信息获取方式存在明显短板：复牌信息分散于上市公司官网公告、各类财经网页，数据源杂乱且更新时序不统一；多标的集中复牌时，人工检索、逐页刷新的方式效率低下，易出现数据延迟与信号遗漏。同时，人工盯屏、反复刷新的操作，不仅占用大量开发精力，还会引入冗余无效信息，增加数据清洗与策略调试的成本，影响开发效率。

解决该问题的核心的是，接入标准化、低时延的实时数据源，通过程序化接口调用实现复牌信息主动抓取，替代被动人工查询。经过实操验证，借助专业数据接口抓取JMG复牌数据，可完全满足高频量化交易对数据实时性、稳定性的要求，成为策略开发的可靠数据支撑。仅需一段轻量化Python代码，即可完成复牌数据精准获取，无需跨渠道切换检索，具体实现代码如下：

from alltick import AllTick
client = AllTick(api_key="YOUR_API_KEY")
# 查询 jmg 復牌信息
result = client.stock.resume('JMG')
print(result)

代码运行后，可直接返回JMG复牌时间、涨跌幅限制、公告摘要等结构化数据，实现信息发布与数据获取同步，彻底解决网页刷新带来的时延问题。依托该稳定数据源，开发者可将工作重心从繁琐的数据采集、整理，转移至策略逻辑开发、参数优化等核心环节，提升市场判断的精准性与开发效率。

基于接口返回的标准化数据，可快速实现自定义筛选逻辑开发，让数据输出精准适配自有量化策略。在高频交易场景中，并非所有JMG复牌相关信息均具备策略参考价值，通常需聚焦涨幅达到特定阈值、契合策略方向的标的，利用接口返回数据可直接完成精准筛选，具体代码如下：

# 过滤涨幅大于 5% 的复牌
resumed_stocks = [s for s in result if s['limit_up'] > 5]
print(resumed_stocks)

该筛选逻辑可直接锁定符合策略标准的标的，简化数据预处理流程，提升分析效率。进一步可将数据抓取逻辑封装为定时任务，实现复牌数据自动化更新，无需人工干预即可保障数据实时性；同时，可将实时复牌数据持久化归档，结合历史行情数据开展对比分析，挖掘复牌节奏与价格波动的关联规律，为策略迭代优化提供数据支撑。

借助这类稳定的数据服务，JMG复牌信息跟踪全流程实现了标准化、自动化与高效化：数据获取实时可控、筛选逻辑精准可复用、更新机制自动化。传统人工整理、低效查询的模式被简洁的Python代码与自动化流程替代，大幅降低了非核心开发成本，让复牌信息跟踪成为策略落地的助力而非负担。

对于量化开发者与高频交易从业者而言，该方案的核心价值在于：以极简的代码实现高效的数据获取与筛选，剥离非核心的事务性工作，聚焦策略研发与实盘落地核心环节，用稳定的数据源支撑，实现量化策略开发与交易执行的高效协同。

随着企业数据安全与自主可控需求持续提升，本地化部署已成为中大型组织选型项目管理软件的核心考量。本次测评聚焦2026年主流企业级产品，筛选10款支持私有化部署、性能稳定、适配多行业场景的工具，全程保持中立客观，为企业选型提供专业参考，文末有对比表格。

一、测评核心维度说明

本次测评围绕企业真实使用场景，从部署与安全、功能完整性、易用性、扩展与集成四大维度展开，兼顾技术团队、传统行业、政企单位等不同需求，突出本地化部署的数据可控、内网可用、高并发稳定三大核心价值。

二、10大高性能本地化部署项目管理软件介绍

1. 禅道

核心定位：国产开源+商业双模式，研发项目全生命周期管理标杆

  • 部署与安全：支持Windows/Linux私有化部署，兼容鲲鹏、麒麟等信创环境，满足等保2.0要求。
  • 功能亮点：覆盖需求、任务、用例、缺陷、文档、统计全流程，敏捷与瀑布模式双支持，内置CMMI过程管理。
  • 易用性：中文原生界面，操作逻辑贴合国内团队习惯，开源版可免费使用。
  • 扩展集成：提供开放API，可对接Git、Jenkins、LDAP等系统，适合研发团队深度使用。

2. Jira Software（Data Center）

核心定位：全球领先的企业级敏捷研发管理平台

  • 部署与安全：数据中心版支持本地化部署，高可用集群架构，权限与审计体系完善。
  • 功能亮点：Scrum、Kanban、混合模式成熟，自定义工作流与字段能力极强。
  • 易用性：界面专业，学习成本中等，适合有一定规模的技术团队。
  • 扩展集成：生态插件丰富，无缝对接DevOps工具链，适配大型研发组织。

3. Microsoft Project Server

核心定位：经典项目组合管理（PPM）工具，微软生态深度集成

  • 部署与安全：Windows Server本地化部署，与AD域、Exchange、SharePoint无缝打通。
  • 功能亮点：甘特图、资源平衡、关键路径、项目组合分析能力行业领先。
  • 易用性：界面符合Office操作习惯，适合传统项目、工程、制造行业。
  • 扩展集成：微软全系生态适配，适合已采用微软技术栈的企业。

4. OpenProject

核心定位：开源免费、功能全面的国际化本地化项目管理系统

  • 部署与安全：开源内核，支持Docker一键本地部署，数据完全自主掌控。
  • 功能亮点：支持敏捷、瀑布、多项目管理，包含时间跟踪、预算、文档协同。
  • 易用性：界面简洁，社区版功能完整，无用户数限制。
  • 扩展集成：开放API，支持二次开发，适合预算有限、注重开源的团队。

5. Redmine

核心定位：轻量开源问题跟踪与项目管理经典工具

  • 部署与安全：Ruby环境搭建，支持Linux/Windows本地部署，插件化架构稳定。
  • 功能亮点：多项目、问题跟踪、甘特图、Wiki、自定义字段齐全。
  • 易用性：轻量化界面，响应速度快，适合中小团队。
  • 扩展集成：插件生态成熟，可通过插件扩展报表、工时、测试管理等能力。

6. 用友U8 Cloud项目管理

核心定位：业财一体本地化项目管理，适合制造与商贸企业

  • 部署与安全：支持私有部署与内网隔离，数据与财务、供应链统一管理。
  • 功能亮点：项目合同、成本、预算、物资、收款闭环管理，消除信息孤岛。
  • 易用性：流程贴合国内企业管理规范，实施成熟度高。
  • 扩展集成：深度对接用友ERP体系，适合以财务与成本管控为核心的组织。

7. 泛微项目管理

核心定位：协同办公+项目管理一体化，政企与服务行业优选

  • 部署与安全：本地化部署，支持流程审批、公文、项目一体化管控。
  • 功能亮点：项目流程可自定义，与OA、合同、费控无缝融合。
  • 易用性：界面轻量化，审批流友好，适合政企、咨询、服务行业。
  • 扩展集成：低代码平台支撑，可快速适配内部管理流程。

8. ONES（私有部署版）

核心定位：企业级研发项目管理，全流程效能管理

  • 部署与安全：支持私有化部署与集群扩容，满足高并发研发场景。
  • 功能亮点：需求规划、迭代管理、测试管理、效能分析一体化。
  • 易用性：现代UI设计，移动端完善，适合互联网与科技企业。
  • 扩展集成：CI/CD、代码库、知识库全面对接，支持大型研发团队管理。

9. 广联达项目管理

核心定位：工程建设行业垂直领域本地化项目管理

  • 部署与安全：支持企业内网部署，适配工程行业数据安全规范。
  • 功能亮点：进度、成本、质量、安全、资料、现场一体化管理。
  • 易用性：流程贴合建筑工程场景，行业模板丰富。
  • 扩展集成：对接BIM、造价、物资系统，工程建筑行业专用。

10. Zoho Projects（Enterprise）

核心定位：高性价比国际化企业级项目管理，轻量私有化

  • 部署与安全：支持私有服务器部署，数据加密存储，权限体系精细。
  • 功能亮点：任务、甘特图、文档、工时、报表齐全，轻量化无负担。
  • 易用性：界面简洁，上手快，适合跨区域中小团队。
  • 扩展集成：对接Zoho全系产品，API开放，支持轻量定制。

三、选型建议总结

  1. 研发团队优先：禅道、Jira、ONES，覆盖敏捷与DevOps全流程。
  2. 传统/工程行业：Microsoft Project、广联达、用友，贴合业务与成本管控。
  3. 预算有限/开源偏好：OpenProject、Redmine，免费可用、扩展灵活。
  4. 政企/协同需求：泛微，流程审批与项目一体化，适配内网环境。
  5. 轻量国际化：Zoho Projects，部署简单、性价比高。

四、结语

2026年本地化部署项目管理软件已形成国产成熟、国际稳定、行业垂直的多元格局。企业选型应优先匹配行业属性、团队规模、安全合规、集成需求四大关键点，在保证数据自主可控的前提下，提升项目交付效率与管理透明度。

五、本次表格基于前文测评内容整理，方便企业快速选型参考。

序号产品名称核心定位部署方式核心优势适用行业/团队核心功能亮点
1禅道国产开源+商业双模式，研发项目全生命周期管理标杆支持Windows/Linux私有化部署，兼容鲲鹏、麒麟等信创环境中文原生界面，贴合国内团队习惯；开源版免费，商业版功能完善；满足等保2.0要求研发团队、中大型企业、信创需求企业覆盖需求、任务、用例、缺陷全流程；敏捷与瀑布双模式；对接Git、Jenkins等工具
2Jira Software（Data Center）全球领先的企业级敏捷研发管理平台数据中心版本地化部署，支持高可用集群架构工作流与字段自定义能力极强；生态插件丰富；适配高并发研发场景中大型技术团队、互联网企业、跨国研发组织Scrum、Kanban、混合模式成熟；DevOps工具链无缝对接；权限与审计体系完善
3Microsoft Project Server经典项目组合管理（PPM）工具，微软生态深度集成Windows Server本地化部署，与微软全系产品无缝打通甘特图、资源平衡、项目组合分析能力领先；贴合Office操作习惯传统项目、工程、制造行业，已采用微软技术栈的企业关键路径管理、预算管控、资源调度；与AD域、SharePoint集成
4OpenProject开源免费、功能全面的国际化本地化项目管理系统开源内核，支持Docker一键本地部署，数据完全自主掌控开源免费，无用户数限制；功能全面，支持多项目管理；可二次开发预算有限团队、开源偏好企业、中小规模组织敏捷与瀑布模式支持；时间跟踪、预算管理、文档协同一体化
5Redmine轻量开源问题跟踪与项目管理经典工具Ruby环境搭建，支持Linux/Windows本地部署，插件化架构稳定轻量化，响应速度快；插件生态成熟；部署简单，维护成本低中小团队、初创企业、注重轻量化管理的组织多项目管理、问题跟踪、甘特图、Wiki、自定义字段齐全
6用友U8 Cloud项目管理业财一体本地化项目管理，适合制造与商贸企业支持私有部署与内网隔离，与用友ERP体系深度对接业财融合，消除信息孤岛；实施成熟度高，贴合国内企业管理规范制造、商贸企业，以财务与成本管控为核心的组织项目合同、成本、预算、物资、收款闭环管理；对接财务、供应链系统
7泛微项目管理协同办公+项目管理一体化，政企与服务行业优选本地化部署，支持流程审批、公文、项目一体化管控与OA、合同、费控无缝融合；低代码平台支撑，适配性强政企单位、咨询、服务行业，注重协同办公的组织项目流程可自定义；审批流友好；一体化协同管控能力突出
8ONES（私有部署版）企业级研发项目管理，全流程效能管理支持私有化部署与集群扩容，满足高并发研发场景全流程研发管理；现代UI设计，移动端完善；效能分析能力强互联网企业、科技公司、大型研发团队需求规划、迭代管理、测试管理、效能分析一体化；对接CI/CD工具链
9广联达项目管理工程建设行业垂直领域本地化项目管理支持企业内网部署，适配工程行业数据安全规范行业针对性强，模板丰富；贴合工程现场管理需求建筑、工程建设行业，工程施工企业进度、成本、质量、安全、资料、现场一体化管理；对接BIM、造价系统
10Zoho Projects（Enterprise）高性价比国际化企业级项目管理，轻量私有化支持私有服务器部署，数据加密存储轻量化无负担，上手快；性价比高；对接Zoho全系产品跨区域中小团队、国际化业务企业、轻量管理需求组织任务、甘特图、文档、工时、报表齐全；API开放，支持轻量定制

开工第一天，邮箱里堆满了各种"新年快乐+促销信息"的模板邮件。你扫了一眼，默默点了"标记为已读"——这大概是大多数人对开工季营销的真实反应。邮件营销不是发传单，而是递名片。尤其在春节后这个特殊节点，用户刚从假期模式切换回来，注意力稀缺，信任感脆弱。这时候硬推产品，就像在相亲局上直接谈彩礼，容易把天聊死。

图片

那开工季邮件营销到底该怎么做？分享几个实战思路
。一、先"拜年"，再"谈事"：
节奏比内容更重要很多人犯的错误是：把拜年当钩子，三句话不到就拐到"限时折扣"上。这种套路用户太熟悉了，熟悉到产生免疫。更自然的做法是把时间线拉长：
第一波（初七-初八）：纯问候，零推销"新年好！我们开工了，您那边怎么样？"——就这一句话，配一张团队真实的开工合影（不是 stock photo），落款用创始人或具体负责人的名字。这封邮件的唯一目的是唤醒关系，让用户记得列表里还有你这么个人。
第二波（正月十二后）：轻量价值输出等用户自己也进入工作状态了，再分享一些真正有用的东西：行业趋势简报、新年规划模板、或者你们团队整理的"节后复工效率工具包"。这时候用户有需求，你的出现就是及时雨。
第三波（正月十五后）：软性转化有了前两轮的铺垫，这时候提产品或服务，用户不会觉得突兀。甚至可以设计成"老用户专属开工福利"的形式，把营销包装成关系维护。
二、把"群发"做出"私聊"感：
细节见真心邮件营销最大的敌人是"系统感"。一旦用户感觉到"这是机器发给一万个人的"，阅读欲望就归零。几个提升温度的小技巧：

  1. 发件人不要用"市场部"用具体的人名，最好是用户曾经接触过的销售或客服。如果做不到一对一，至少做到"来自XX（你的客户经理）"。
  2. 主题行拒绝"标题党""开工大吉！全场5折起！！！"——这种邮件我直接删。"关于您去年咨询过的那件事"——这种我会点开。开工季的主题建议：克制、具体、带人名。比如"张总，节后第一件事想跟您同步"、"李经理，你们团队复工顺利吗？"
  3. 正文第一句话要"认人"不要用"尊敬的用户"。哪怕只是"听说您公司在上海，春节应该挺暖和吧"这种简单的地域关联，也能瞬间提升打开率。
    三、内容要有"余味"：别在邮件里把话说完
    好的营销邮件像好的短篇小说，结尾要留一点想象空间。不要试图在一封邮件里把产品功能、价格优势、客户案例全部讲透。而是聚焦一个痛点场景，给出一点启发，然后邀请用户进行下一步互动："如果您也在头疼这个问题，回复这封邮件，我发您一份我们内部的解决方案。""这周我在上海，方便的话可以喝杯咖啡？""附上我们整理的行业白皮书，看完如果有疑问，随时找我聊。"把邮件当成对话的开场白，而不是演讲的完整稿。
    四、邮件群发工具是杠杆，但别依赖自动化
    说到这里，必须聊聊工具。邮件营销做到一定规模，确实需要专业平台来支撑：送达率优化、A/B测试、用户分层、数据追踪……这些靠个人邮箱是玩不转的。市面上工具很多，如果你正在选型，可以看看U-Mail邮件营销平台。
    从实战角度看，U-Mail邮件营销平台更像是为“规模化发送场景”准备的基础设施，而不是简单发信工具。它有几个点，特别适合开工季冲量：
    ✔ 高信誉发送通道（海内外覆盖）对跨境、展会、外贸团队非常友好，进箱更稳定。
    ✔ 真正的1对1变量发送每封邮件都可以个性化，不是“看起来像群发”。
    ✔ 大批量稳定发送能力很多团队开工后要快速触达老名单，这一点非常关键。
    ✔ 可视化数据追踪谁打开、谁点击，一眼就能看清后续跟进重点。
    ✔ 支持API与系统对接如果你们已经有 CRM / ERP，新年做自动化触达会非常顺。当然，工具只是放大器。如果内容本身没有温度，再贵的平台也救不了打开率。开工季的邮件营销，本质上是一次关系重启的机会。
    过去一年积累的用户资产，值得用更有诚意的方式去激活。少想一点"怎么让他们买"，多想一点"怎么让他们记得我"。这个心态转变，比任何技巧都重要。新年伊始，祝你的每一封邮件都能被温柔以待。

这里记录每周值得分享的科技内容，周五发布。

本杂志开源，欢迎投稿。另有《谁在招人》服务，发布程序员招聘信息。合作请邮件联系（[email protected]）。

封面图

上海黄浦江边的艺术装置《航舵》。此处是船厂遗址，有一堵防汛墙，为了吸引人们走上去，以及配合造船主题，就设计了这么一个装置。（via）

当外卖员接入 AI

最近，美国有一条无人驾驶的新闻，引起很大反响。

Waymo 是一家无人驾驶公司，已经在多个美国城市开展出租车运营了。

它有一个最大的烦恼，就是乘客下车后，没关好车门或后备箱，导致车辆无法驶离。

奇怪的是，这样一家高科技公司，居然没有开发远程关车门功能，反而想出了一个另类的解决方案。

它给外卖小哥下单，付钱让他们赶到现场关车门。

有一个小哥看到了上面这张奇怪的订单，标价6.25美元，要求赶到1公里以外的一个地方，找到一辆 Waymo 出租车，把车门关上。完成后，还将额外收到5美元。

他觉得很稀奇，就截图发到了网上，这件事顿时就变成了新闻。

它的新闻点，其实不是接单关车门，而是程序在调动人力，完成自动化流程。

一直以来，程序只能调动计算机，突然之间，它可以调动人力了，某个环节计算机完成不了，它就自动找人来完成。这才是新闻。

这样做之所以能够成功，完全因为外卖员是一个自带 API 的人群，已经接入了软件系统，成为了自动化人力，程序可以通过接口去调用他们。

你仔细思考这件事，就会意识到，在人工智能和机器人的时代，外卖员有特殊的价值，将是一个很有想象空间的职业。他们的作用绝不仅是送外卖，而是可以升级为远程操控、程序调用的人力，是"机器 + 人"自动化流程的一环。

一旦 AI 模型跟人力结合在一起，模型的作用将大大扩展，现在的 OpenClaw 只能操作计算机，将来的 AI 助手还将是劳动力的调配引擎。

比如，我要装修一套房子，AI 做好了设计方案，然后就在网上分布细分任务，水电工接单做好水电，监理员接单上门确认后，AI 就自动结算费用，进入下一个环节，泥工、木工......直至装修完成。

到了那时，你在网上输入提示词"我要装修房子"，真的可能一套房子就被 AI 装修好了。

AI 平台因此会变成一个劳务平台，你可以通过 AI 找工作，上面有各种劳务需求，你接单去做，完成后收到报酬。

总之，一旦人力接入 AI，被它调配，AI 就不止是计算机革命，而是整个社会经济都将围绕它重构了。

[本周软件] PinMe：去中心化托管服务

链接会删除，网站会关闭，域名会消失，内容怎样永久保存在互联网？

现在有一种解决方案 IPFS（星际文件系统），通过分布式协议，在所有节点之间分享内容，而网址就是内容的哈希值。

所以，内容一旦上传 IPFS，就无法修改，因为哈希值会变，也无法删除，因为其他节点会有留存。

今天介绍的 PinMe，就是这样一个 IPFS 托管工具。

你可以通过它，将任何文件上传到 IPFS。上传一个静态网站，理论上就是永久可访问，任何人（包括你）都无法删改和关闭，任何一个 IPFS 网关都能打开浏览。

PinMe 会分配一个 ENS 域名，指向上传内容，这个域名写入以太坊区块链，也是永不消失。

它提供的免费储存空间有 1GB，更大空间和自定义域名需要付费。

文件可以网页上传，也可以用它的开源命令行发布工具，一行命令发布到 IPFS，该工具已经有2800颗星。如果要永久保存内容，大家可以试试看。

科技动态

1、音频线

材质越好的音频线，价格越贵，但真能听出差别吗？

一个美国音响爱好者做了一个实验，分别用专业音频铜线、香蕉和湿泥来传输音频。

他让不同的人来听，结果根本听不出差别。

这太令人惊讶了。一般认为，香蕉和湿泥土不是良好的导体，但是这个实验表明，它们只是电阻大一点，除了降低信号电平之外，不会对音频造成太大失真。

2、COBOL 代码的 AI 维护

COBOL 是上个世纪的编程语言，现在已经没人用了。

但是，美国很多大公司的关键系统是 COBOL 写的，始终没有下线，目前都由 IBM 公司维护，收费非常昂贵，因为除了他们就没人懂这门语言。

本周一（2月23日），Anthropic 公司突然在官网发布文章（上图），宣布他们的 Claude 模型可以自动分析 COBOL 代码，将其迁移到其他语言。

这篇文章立刻导致 IBM 股价大跌（下图）。

如果 AI 可以维护 COBOL 代码，是否意味着所有历史遗留软件的维护，都已经不成问题了？我们再也不必为接手老项目烦恼了？

3、AI 编程项目的版权

美国的司法规定，只有人类的智力成果才有版权，AI 的生成结果没有版权。

这意味着，AI 编程出来的代码，（在美国）是无版权的，任何人都可以自由使用。

除非项目明确披露哪些部分是 AI 生成的，哪些部分是人工编写的，这样可以对人工编写的部分主张版权。

4、僧侣机器人

日本京都大学发布了一款僧侣机器人，硬件为宇树机器人，软件为佛经训练过的 ChatGPT。

它步态缓慢，能做出双手合十、鞠躬等动作，能够跟你对话佛经，提供精神安慰，解答生活问题，还能主持祈福、洒净等简单法事。

当被问到"嗜酒困难"时，机器人回答："远离损己伤身之物，持守不饮酒戒，勤修善行，方为安乐。"又被问道"性情急躁、难以专注"怎么办？它建议："勿求速成，安住当下，逐一观照所遇之事，辨明本心所需，徐徐而理，自然澄明。"

京都大学在声明中表示，这款机器人将来可能协助或替代人类，完成一些宗教仪式，并且也能解决由于人口老龄化和劳动力减少，佛教僧侣不足的问题。

该机器人从3月起在京都青莲院门迹等寺庙进行为期6个月的实地测试，顺利的话，将于2027年推出商业版本，提供"寺庙机器人租赁服务"，帮助小型寺庙维持运营。

文章

1、SWE-bench Verified 测试应该放弃（英文）

OpenAI 公司创建的 SWE-bench Verified 是目前最常用的测试基准，用来衡量模型的编码能力。

本周，OpenAI 公司提出应该放弃它，因为有难以克服的缺陷，已经不准确，可以改用 ScaleAI 创建的 SWE-Bench Pro。

2、.plan 文件（英文）

作者提出，文本文件 .plan 是最好的任务管理系统。放在云盘上，随时随地使用任何设备，都能查看和编辑。

3、鲸落（英文）

一鲸落，万物生。本文通过很多例子，说明一个大项目终止后，并不会真的死亡，而是化作许多小项目，四处生长。

4、40 行代码实现无服务器 OCR（英文）

本文是一篇教程，作者用云函数调用 DeepSeek OCR 模型，将 PDF 格式的数学论文转为 Markdown。

5、两台路由器实现局域网无缝漫游（中文）

作者家中的两台路由器无法组 Mesh，本文介绍如何将它们组成同一个局域网，让设备可以无缝漫游。（@popring 投稿）

6、视觉隐藏的最新实现（英文）

视觉隐藏指的是，网页上看不见这个元素，但是网页阅读器能读到这个元素。本文介绍它的最新 CSS 写法。

7、OpenClaw 背后的引擎 Pi（英文）

OpenClaw 的走红，也带火了它的底层引擎 Pi。Pi 是一个 Coding Agent，跟 Claude Code 作用类似，但更轻量级。

工具

1、Oat

轻量级的 HTML + CSS + 极简 JS 的语义化 UI 组件库。

2、jsonriver

一个 JS 库，用于解析 JSON 字符流，可以作用 JSON.parse() 的替代品，后者不支持流模式。

3、Arcmark

一款开源的 macOS 桌面应用，用来管理浏览器书签，可以自动吸附在浏览器窗口的侧边。

4、Systemd manager tui

一个通过终端界面管理 Systemd 服务的工具。

5、weathr

一个终端应用，用来查看指定地点的天气，以动画形式展示。

6、CursorLens

开源的录屏桌面应用，用于制作产品演示与讲解视频。（@blueberrycongee 投稿）

7、结印（Ketsuin）

一个 Web 应用，通过火影忍者的手势输入法，摄像头识别手势进行文字输入。（@huanglizhuo 投稿）

8、Puter

一个需要自搭建、通过浏览器使用的云操作系统，参见介绍文章。（@cosmicqbit 投稿）

9、Penio

跨平台的教学可视化桌面应用，让鼠标、键盘在屏幕可视化凸显出来。（@game1024 投稿）

10、openhare

基于 Flutter 的跨平台桌面 SQL 查询工具，支持多种数据库，可以 AI 生成 SQL 查询和数据分析。（@sjjian 投稿）

AI 相关

1、BitFun

开源的 AI 编程 IDE，类似于 Cursor。（@GCWing 投稿）

2、Xcode Proxy

一个本地的基于 Python 的服务，让 Xcode 可以调用各种第三方 AI 服务。（@tianrking 投稿）

3、openapi-to-skills

将大型的 OpenAPI 文档转为按需加载的 Skills 结构，用来精确执行某个接口，以及减少 Token 消耗和幻觉。（@Yuyz0112 投稿）

4、Trending AI

开源手机应用，AI 总结 GitHub Trending 项目。（@HarlonWang 投稿）

5、Horizon

一个 Python 项目，从自定义的多个信息源收集新闻，进行筛选和摘要，生成一份日报。（@Thysrael 投稿）

6、JadeAI

基于 Next.js 的智能简历生成器，支持拖拽编辑、实时 AI 优化、50 套专业模板打造简历。（@twwch 投稿）

资源

1、Flashpoint Database

这个网站收集各种网页游戏和动画，目前有18万个游戏和3万个动画。

2、Claude Code 中文教程

包含10个完整章节的 Claude Code 中文教程仓库。（@KimYx0207 投稿）

3、海平面上升模拟器

用户在网页上设定海平面的上升高度，查看地球卫星地图的变化，哪些地区被淹没。（@ObservedObserver 投稿）

4、diode

面包板在线模拟网站，在网页上用各种电子元件，可视化模拟面包板电路项目，可以查看运行效果。

图片

1、世界第一个浏览器

1990年，欧洲核子研究中心的研究员蒂姆·伯纳斯-李（Tim Berners-Lee），发明了 WWW（互联网的网页浏览服务）。

现在，欧洲核子研究中心的官网提供世界第一个浏览器（上图），作为历史体验，供用户在线体验。

同时提供的，还有世界第一个网站（下图）。

2、显示器布局

程序员的工作台，往往放着1到 n 台显示器。

有人总结了这些显示器的放置方法，你属于哪一种？

文摘

1、卡车的空气动力学

1973年，美国宇航局的一个工程师骑自行车上班，遇到一辆大卡车在身边飞驰而过，卡车的气流将他连人带车推向路边。

大多数骑车人一定会心惊胆战，但是这个工程师立刻想到，大卡车的空气阻力非常大，所以才有这么强的气流。

回到实验室后，他就召集了一些同事，借来一辆旧福特厢式货车做实验，怎样才能改善空气阻力，提高燃油效率。

他们先在卡车外面包了一层方方正正的铝板（上图），测量基准阻力。

然后，将车头前部的垂直角打磨成圆角（下图），再测试阻力有没有变化。

接着，密封了车辆底部，使气流更顺畅地流过车身。

经过测量，将前部四个边缘全部打磨成圆角后，阻力降低了52%；密封车底后，阻力又降低了7%。他们估计，这可以使高速公路行驶时的燃油消耗减少15%至25%。

最后，他们又在驾驶室上方和底盘前方加装了整流罩，在车尾加装了尾翼，阻力又降低了15%。

他们当时改装的样车，跟2017年特斯拉推出的 Semi 卡车很相像。

言论

1、

美国最大的创业孵化器 YC 如今几乎只投人工智能领域，最新一轮它的投资组合中，高达88%的公司都基于人工智能。

这与它曾经倡导的逆向思维背道而驰，转而倾向于稳妥的追随潮流。

-- 《YC 是收留懦夫吗？》

2、

我们应该帮助实体店生存下去。当一家实体店开业，它会让其他人受益，会帮助街区吸引居民和潜在顾客，最终让本地区变得有活力和适合生活。

-- 《零售业提升土地价值》

3、

如果 AI 主导一切，那些无法被 AI 量化的东西，不是会特立独行，而是最终会被淘汰。

-- Ben Thompson，美国著名科技 UP 主

4、

美国企业有一个方面做得很好，那就是他们不会把时间和精力浪费在自己不擅长的事情上，而是对自己擅长的领域加倍投入。

他们只关注收益最大化，不关注成本最小化。

-- Ben Thompson，美国著名科技 UP 主

5、

创造力需要你有勇气去放弃确定性。

-- 埃里希·弗罗姆，德国哲学家

往年回顾

代币是什么（#339）

宽容从何而来（#289）

未来两种人会增加（#239）

下一个内卷的行业（#189）

（完）

  1. 1
  2. ...
  3. 18
  4. 19
  5. 20
  6. 21
  7. 22
  8. 23
  9. 24
  10. ...
  11. 252