CycleUser

「对人不对事」是大学生听讲座提高学习效率的必备智慧

2026-10-03T12:00:00+08:00

「对人不对事」是大学生听讲座提高学习效率的必备智慧

前几日做了一个梦，梦见自己仍在上学，被请去听一场「自愿」参加的讲座。醒来以后想了想，大学里这样的场合其实不少。既然去了，不如把台上那一位看得清楚些——这本身，也是一门功课。

梦里被「自愿」了一回

梦里我还是学生的时候，收到一份通知，说是请大家自愿参加某场讲座，只在末尾轻轻地叮嘱了一句，尽量不要缺席。话说得其实很客气。

到了地方才知道，未必是哪位名师的高论，而是外面一家机构来做宣讲，大约是考研或者四六级辅导之类，只是被安了一个讲座的名头。

台上那一位讲得还不坏。只是梦里既已这般「自愿」地来了，心里总有些许不自在，听着听着，便容易多想一些。

对人不对事

我这里有一个还算不错的习惯，姑且称之为「对人不对事」。但凡一件事让我认真起来，我第一件想弄明白的，往往不是这件事本身如何，而是背后究竟是谁将它促成如此。这习惯大约从念书时便养下了，至今未改。

所以梦里既已被那样客气地请到座位上，我便索性把台上那一位讲座之人的情况利用搜索引擎详细了解了一遍：他身后是家怎样的机构，注册情形如何，各类公开信息里逐一看来；他出自哪一所学校，学的什么，师承何人，毕业论文与刊发的文章又都写了些什么；那些文章里的数据与图表可还端正，有没有人为修整过的分布，有没有数据误用、图片误用；如此之余，也顺带看看那家机构在宣传时的措辞可有越界，别处可有不合规矩的地方。凡此种种，都一一安静记下；再出于一份关心，转呈相关监管部门留意。

这些事，我在梦里做得格外顺手，因为平日里本就喜欢如此。数据到了手中，总忍不住要分析、要画成图，看看这一堆数字背后，是不是还藏着些别的。至于查重，或是查看图表里的重复与裁剪，也都算不得难事。

醒来才想起来，我已经毕业了

后来便醒了。

醒来想的第一件事，是自己早已毕业，再不必被人那样客气地请去，听一场以讲座为名的宣讲了。念及此处，竟还有几分轻松。

静了一会儿，又觉得，纵然是真心情愿去的，似乎也不该听过便走。

去了，就得记住讲的人是谁

我的建议是：讲座也好，活动也好，既去了，总该记下这一回讲的人是谁。

倒不是非要去替人家查文章，把一个人的论文都翻检一遍，连「图片误用」「数据误用」也一并看过，再顺带把他门下师友都了解一圈——这般成人之美的事，愿意做自然好，却也不必时时都做，更不是非做不可的。

要紧的是，总得知道，这一回自己见到的人是谁。

万一人家确有建树，可学之处不少，那便该设法留一个联系方式，平日里多留意人家的学问。这对我们自己，是只有益处、没有坏处的。

就像耿同学那样，这本是再寻常不过的事。

江湖上的人，都经得起风吹雨打

换一个角度想，能在世间行走的人，总要经得起一些风雨。

做学问的人，多少都有一份修为。内里的功夫与外面的体面，大约都还过得去。若连旁人了解一下他、读一读他的文章这种事也经不起，那又何以出来见人。

所以，多与人学，去了解人家在做什么学问，原是一门必备的功课。

大学里，有机会就多听讲座

到了大学，有机会便多去听讲座。纵使无人强迫你必须「自愿」去，你其实也可以自己去。

去了之后，把讲的人了解清楚，把他的文章收拾齐整，做成一座小小的知识库，请 AI 细细分析一番，这些都可以做，甚至也都应当做。不为别的，只为把这个人看得明白些，看看有没有值得学的地方。

记得当年某位沈姓学者的讲座上，我曾问过一个问题：若以石笋中的纹层计数为参照来理解「年」这一时间概念，那么以生物周期所作的记载，是否会受到地质历史时期行星绕日周期变化的影响，从而难以与同位素测年严格对应。他当时说未曾想过这一点，然后表示记下了，但并未作答；文章刊出时，也未曾提及帝都讲座上对他提问的人，更未有一句致谢。

总之，愿各位都能把大学生活，过得充实一些。

大模型已成日常刚需：当在线服务存在不稳定性，我们或许该考虑本地部署的时机、路线与成本

2026-10-03T10:00:00+08:00

当做地球科学的同学也开始关心模型的价格，大概说明大模型已经成了很多人日常工作的一部分。而这段时间在线服务接连中断的报道说明，这种依赖的可用性并不掌握在自己手里。这篇以我这段时间重度使用的Qwen3.8-Flash-Next为例，聊一下本地部署的两条代表性的路线，以及当前的大致成本。

大模型正在成为越来越多人的日常刚需

前些天有一位大学时期的同学问我，最近用模型是不是成本挺高的，他感觉有一段时间以来，几家在线服务商好像都涨价了。

这位同学是做地球科学研究的，日常工作跟数据科学关系不大。连他这样背景的人，都开始关注模型的价格了，这大概能说明一个趋势：很多人的日常工作和生活已经离不开大模型了。大模型成了很多人的常用工具，某种程度上已经成了类似基础设施的东西。很多人已经习惯了它，甚至没法想象没有它的日子——就像很多人习惯了微信和支付宝这样的在线支付一样，一旦深度绑定，再想抽身就不那么容易了。

既然习惯到了这种程度，那么有一个问题就值得想一想：如果有一天离开了在线服务，我们是不是就什么都做不了了？打个比方，现在的经济活动很依赖在线支付，要是没有了在线支付，很多东西都会受影响；同样地，要是没有了在线大模型，或者在线大模型涨价了、服务不稳定了，我们该怎么办？

在线大模型的可用性与价格，都不掌握在自己手里

要回答这个问题，先得看看在线大模型是不是真的存在不稳定和涨价的情况。答案是，这方面的公开报道并不少，而且不是哪一家的问题。

先看时间线。2026 年 3 月底，DeepSeek 在 3 月 29 日晚出现一次持续约 12 小时的宕机，3 月 31 日下午又一次中断约 1 小时 [1][2][3]；当时抖音豆包公开评价说，DeepSeek 的频繁故障是「爆发式增长下的必经阶段」，并且自己也承认，大模型推理对算力消耗巨大、硬件供应链紧张制约了扩容速度 [4]。这段话从同行的角度，说出了行业共同的处境。4 月，Anthropic 旗下的 Claude 在半个月内出现了 7 次服务中断，4 月 16 日那次故障前后持续近 3 小时，高峰期有超过 6000 名用户同时提交报错；按照官方状态页的数据，截至 4 月 8 日的 90 天里，Claude API 的正常运行率只有 98.95%，明显低于企业级标准的 99.99% [5]。到了 7 月 25 日，轮到 OpenAI：ChatGPT、API、Codex 全线瘫痪，故障持续超过 8 个小时，没有任何预警，官方状态页只确认错误率升高、不给恢复时间 [6]；钛媒体的统计说，OpenAI 每一年都会发生重大事故，但从未公开披露过根本原因 [6]。9 月 3 日则是规模更大的一次：ChatGPT、Claude、Grok 在相同时段集体宕机，持续约 3 小时 40 分，谷歌 Gemini 和微软 Copilot 也收到大量中断报告，AI 编程工具 Cursor 因为依赖这三家的接口被一并波及 [7][6]。再看同年 5 月 DeepSeek 的情况，也就是开头同学提问时我查证的那批报道：5 月 8 日新版本上线流量激增，网页端和 API 整体停摆了几个小时；5 月 24 日大规模宕机，官方状态页红色告警持续一整夜，抢修了十几个小时 [8]；5 月 28 日上午 10 点 21 分网页和 API 同时不可用，10 点 50 分恢复，前后约 29 分钟，是当月第五次、年内第 18 次性能异常 [9][10][11]。

把这些报道汇总成一张表，各个平台的记录大致如下：

时间	服务方	事件	影响与持续	出处
2026-04-01 至 04-16	Anthropic（Claude / Claude Code / API）	半个月 7 次中断；16 日故障近 3 小时，6000+ 用户报错	90 天正常运行率 98.95%，低于 99.99% 的企业标准	[2]
2026-03-29 至 03-31	DeepSeek	29 日晚宕机约 12 小时；31 日午后再度中断约 1 小时	两日两次，网页与 API 均受影响	[12][3]
2026-05-08	DeepSeek	新版上线流量激增，网页与 API 全线停摆	数小时	[9]
2026-05-24	DeepSeek	大规模宕机，网页端与 App 全部无法访问	约 13 小时	[8]
2026-05-28	DeepSeek	网页与 API 同时不可用，提示「服务器繁忙」	约 29 分钟；年内第 18 次异常	[9][10][11]
2026-07-25	OpenAI（ChatGPT / API / Codex / Sora）	全球性宕机，全线瘫痪，无预警	超过 8 小时，覆盖北美、欧洲、亚洲主要市场	[6]
2026-09-03	OpenAI / Anthropic / xAI	集体宕机，Gemini、Copilot 收到大量中断报告，Cursor 被波及	约 3 小时 40 分	[7][6][13]

这份时间线里有两个细节，比表中任何单独一次故障本身更值得琢磨。一是 9 月 3 日的集体中断：ChatGPT、Claude、Grok 三家在同一个时段一起出问题，不是巧合——业内人士的分析指向微软 Azure、Cloudflare 这类多家大模型公司共享的云算力基础设施 [7]。也就是说，各家在线大模型虽然彼此是竞争关系，底层却可能建在同一批云设施上；故障的时候可能会一起故障，用户想靠「换一家服务」来避开，未必躲得开。二是 3 月底豆包的那次表态：当 DeepSeek 因频繁故障受到批评时，抖音豆包公开说这是「爆发式增长下的必经阶段」，并且自己也承认，大模型推理对算力消耗巨大、硬件供应链紧张制约了扩容速度 [4]。竞争对手承认整个行业都在面对同样的算力缺口，这比任何局外人的批评都更能说明问题。

至于涨价，同学的感觉也不是错觉：免费的服务在收紧、付费的额度在变贵，而且这背后有一层更硬的逻辑。时代周报引用的数据显示，2026 年 5 月中旬那一周，全球大模型总调用量攀升到 28.9 万亿 token，其中中国大模型占 9.22 万亿、环比增长接近 20%；与互联网产品「边际成本趋近于零」的经典模式不同，大模型每一次对话都要消耗实实在在的算力，用户越活跃，成本越刚性 [11]。业内因此有一个共识：单纯靠免费获客的 C 端模式很难持久 [11]——涨价与服务收紧，大概就是这个判断在现实中的样子。

我自己前几天也遇到一次突然中断，正好是在工作过程中，手上正在进行的步骤就停在那里，只能等。原因方面，业内人士的分析是，用户规模增长过快，服务器算力扩张难以匹配激增的流量需求 [14]，这个缺口恐怕短期内补不上。

这些事实摆在一起，结论就比较清楚了：在线大模型的可用性与价格，两样都不掌握在自己手里。所以大概从两三周前开始，我做事的时候基本都以本地大模型为主了。

千问 3.8 Flash Next 的规格：125B 参数、全量权重需要上百 G 显存

我用的是千问 3.8 Flash Next（Qwen3.8-Flash-Next），先介绍一下这个模型大概是什么规格。

它是一个 125B 参数的模型，也就是总参数量一千二百五十亿（模型主页见文末 [15]）。不过它不是稠密模型，而是混合专家（mixture of experts，MoE）模型：模型里有 24576 个专家网络，模型每处理一个词元（token），只从这里面选择激活 10 个专家参与计算 [2]。这个机制对部署的意义在于，虽然全部权重都要驻留在存储里，但每次推理实际参与的参数只有一小部分，计算的开销主要由被激活的那部分专家决定。

对本地部署来说，关键数字是显存需求。这个模型如果按 16 位精度存放，权重就需要大约 250GB 显存；按 8 位是大约 125GB；按常见的 4 位量化，也要大约 62GB——再加上上下文占用的键值缓存，一张普通的 24G 显卡无论怎么样都放不下整个模型，必须想办法把权重分散到显存、内存、磁盘这些不同的存储层级里去。

两条路线：一台高性能机器跑多个模型，或多台设备合跑一个模型

要把这样的模型在本地跑起来，现在有两个比较有代表性的方向。

第一个方向，是把一台机器上的显存和统一内存尽量全部利用起来，分给几个大模型同时运行。这一类里 Halogen 是个典型：它由 Peonist 开发，专门为某一款统一内存芯片平台编写，每个 kernel 都只为这一块 GPU 和一个模型家族优化，不追求通用，也没有回退路径 [12]。这类平台的特点是统一内存大，某些配置可以达到 128GB [12]，Halogen 把这部分尽量利用起来，本地就可以同时放置多个模型。适合的场景大概是：存储、内存、显存都不紧张，同时对速度或者并行有一定要求。

第二个方向，是把所有可以使用的设备放到一起，运行一个模型。Strata 是这一类里的代表：开源，MIT 许可，底层使用 llama.cpp / ggml 那一套 [2]。具体说，它把最常用的专家放在显卡显存里，全部专家放在系统内存里，处理器同时计算其余部分，SSD 上再放一张大的查找表 [2]。这样一来，显存的缺口就由内存来补。仓库的实测机器是一张 12G 显存的显卡加 64GB 内存 [2]；对内存的要求写得很明白：最少 32GB 也能跑，但只能装下砍掉一半专家的 Coder 专用版，64GB 才能把所有尺寸都跑全 [2]。要是有两三张卡，还可以一起分担同一个模型 [2]。

这两个方向并不冲突，往后看，大概也会是本地部署的两个主流方向。

前者是机器规格高，同时运行几个模型；后者是设备比较分散，合起来运行一个大的。

选哪一种，主要看你手头的硬件和要处理的事情。

12G 显存加 64GB 内存的实测速度：这个配置已经能够流畅运行

第二个方向，现在已经可以在具体设备上运行了。

12G 以上显存的设备，用 Strata 就可以流畅运行千问 3.8 Flash Next。Strata 项目上实测的是一张 12G 显存的显卡加 64GB 内存的机器，在 Q2_0 量化下可以达到 94 tokens/s [4]；24G 显存的显卡大约 100 到 140 tokens/s [2]。作为参照，我前几篇实测文章里那些跑本地模型的机器，日常对话能稳定用的一般在十几到二十几个 tokens/s；这个速度已经明显高出一截，日常对话、工具调用这类场景完全够用，跟不少在线服务比也不处于下风。

这里显存和内存要配合着看：12G 显存只是下限，权重里放不进显存的那部分靠内存装着，所以想把这个尺寸跑全，内存应当以 64GB 为宜——仓库对硬件要求的原话是「64GB 运行所有尺寸」，32GB 只能装下砍掉一半专家的 Coder 版 [4]。

再往后，8G 显存的设备应该也可以运行对应的 MoE 模型，比如 35B-A3B 这种：总参数量 35B，每个词元（token）只激活约 3B 的参数，4 位量化下权重约 20GB [4]，其中放不进 8G 显存的部分要靠内存装着，所以内存同样不能省，参照上面 12G 显存配 64GB 内存的比例，8G 显存的机器至少应当 32GB 起步、最好也是 64GB——这一条是按 Strata「内存多少决定能装哪个尺寸」的规则推的，它文档里没有直接写 8G 的组合，真要上手就以实际测试为准。 MoE 在这种场合其实正好帮了本地部署的忙：每次前向计算只激活少数专家，推理时需要读取的参数量比同等总参数的稠密模型低，几台设备合在一起运行，速度反而可能有所提高。

本地模型的合理定位：工具调用、信息检索与代码翻译

本地大模型的能力，未必有在线旗舰模型那么强，不过这更多是定位的问题。

对于能力有限的模型，比较推荐的用法是：让人掌握方向，让模型执行细节。把需求分析、方案设计这类决定成败的环节留在人这一侧；交给模型的工作，则尽量是边界清楚、步骤明确的任务——工具调用、信息检索，以及代码翻译：思路由人讲清楚，每一步怎么做由人交代明白，模型照着写出来。

这种分工的好处有两个。一是模型的能力要求降低了，本地模型够用；二是过程可控——模型没有被要求去推测需求、做设计，它自行发挥的空间被压到了最小，产出的不确定性也就随之降低。用能力较弱的模型做事，关键就是不让它失控：不要让它猜，而让它照做。

反过来，如果让本地模型自己去推测需求、设计架构，那它确实还有明显差距。这不是本地模型的独有问题，能力越强的模型在这种失控模式下不确定性越大；只是在本地模型这里，更应当从一开始就避开这种用法。

从 kiwix 的离线归档习惯说起：本地部署是一份备份

这个习惯可以交代一下来历。开头提到的那位同学是学地球科学的，我也是——我读的博士就是地球科学方向。做这一行经常要出野外，一进山区可能就没有信号了，如果路线深入，甚至要到没有网络覆盖的无人区。但野外的很多时候又需要查资料、查文档：地层划分的规范、岩石矿物的鉴定特征、前人的区域地质报告，这些都不会因为你进了无人区就不再需要。所以很早就接触到了 kiwix 以及它对应的 ZIM 格式——一种把整个网站打包成单文件、可以完全离线检索的归档格式，维基百科、 Stack Exchange、不少文档站都有现成的 ZIM 包可以下载。硬盘里存了一批离线维基和文档，到现在还保持这个习惯。

平时这些归档可能看不出什么用处，等到需要断开网络、或者无法访问外部服务的时候，就知道有用了。

大模型大概也是类似的情况。习惯了有问题就问模型的人，如果某一天网络中断、服务关闭或者账号出了问题，再想做事就缺少了一个环节。在本地部署一个大模型，相当于给自己的工作方式留一个备用的选项：能力未必是最好的，但是它随时都在。对野外或者没有网络的环境来说，这一份「随时都在」可能不只是备用，而是唯一能用的那份。

成本估算：一万出头有机会起步，常见的组合在两万上下，几万的也有对应选项

新的本地推理框架逐渐流行之后，把有一定能力的大模型在本地流畅运行，成本门槛比过去低了不少。但具体要花多少钱，得按路线分开算，而且得按现在的行情算——这一轮硬件的价格一直在往上走。

统一内存小主机：这是走 Halogen 路线最直接的一台整机，CPU 与 GPU 共享一块 128GB 的统一内存，不需要再单独配显卡 [16]。价格方面，以搭载 128GB 统一内存的整机来算是，媒体评测期在 1.5 万元上下，现在普遍涨到 2 万元左右，部分机型到 2.6 万 [17]；入门的 64G 内存版本，行情价也从前一年的 1.07 万元左右涨到了 1.5 万元上下，一年涨了 4300 元 [18]。不过对跑本文讨论的这类 125B 模型来说，64G 内存装不下 4 位量化后的全部权重（约 62GB），真正可用的是 128GB 内存的版本 [4]——所以说现在这类小主机的实际入手价位就是两万上下：比之前涨了近一倍，但按它承载的能力算，还可以接受。

CUDA 生态的统一内存个人工作站：统一内存同为 128GB。英国创世版官价已从 3999 美元上调到 4699 美元，国内整机从「3 万出头」涨到了接近 4 万 [17]。单机跑大模型的论坛评价并不高——带宽偏低、单机偏弱，它的设计用法本来就是几台互联组一个小集群。它的价值要按集群来算账：本地跑 DeepSeek 上一代的 V4 Flash（总参 284B），两台 128GB 机器合计 256GB 统一内存正好装下权重 [19]；而今年 9 月开源的 V4.1 Flash 尺寸翻上去了，总参 748B、开源权重实测约 510GB，其中 MoE 与主模型权重约 306GB 必须驻留在内存里、另有约 204GB 的 Engram 知识权重可以下沉到 SSD [19]。按每台 128GB、扣除约 20 多 GB 的系统与框架开销来算，两台合计约 230GB 余量，装不下这 306GB 的核心权重；三台合计 384GB，扣掉开销后约 360GB，装下核心权重还有约 54GB 留给长上下文与多会话——所以跑 V4.1 Flash 要三台起，单条生成 40 到 60 tokens/s、prefill 2500 到 3000 tokens/s [19]。买台数按「将来想跑到哪一代」来定：两台这一档对应的是 V4 Flash，三台对应 V4.1 Flash，而这类工作站官方支持四台互联，这个规模内互联效率不打折扣 [19]。但是成本实在是太高了。

24G 或 32G 显存的显卡 + DDR4 ECC 服务器平台 + 拆机大内存：这是 Strata 支持、走「多台设备合跑一个模型」路线里性价比比较突出的组合 [4]。显卡一侧，24G 显存这一档可选面比较广，预算充裕一些可以上 32G 显存的高端卡 [20]。以 24G 这一档为例，二手价在我 9 月初写显卡行情那篇时查到的是 4800 到 6400 元、典型 5000 到 5600 元 [20]；最近这轮行情上来之后，成色好的二手普遍涨到了八九千。32G 显存这一档的价格也在同一条曲线上：上个月还是 1.1 万出头，现在已经报到了 1.4 万左右 [20]——也就是选 32G 这一步的溢价本身，一个月内就抬高了约三千元。内存与平台一侧，不买全新 DDR5：一是贵，二是有带宽上的顾虑——DDR4 的频率原本就低于 DDR5，而本文这类 MoE 推理恰恰是访存受限的负载（前文算过 8G 显存也要靠内存装专家，生成速度基本由内存带宽决定），消费级主板常见的双通道四条内存对这种负载可能就不够了，往往要上四通道甚至八通道才能把带宽喂足；而多通道、大内存、带纠错，这些恰好就是服务器平台的属性。所以用 DDR4 ECC 服务器平台（带纠错内存的服务器主板）加拆机的 ECC 内存条便宜得多——这一轮涨价的源头是 AI 数据中心在抢内存产能，主要厂商把先进产能转去做 HBM 和 DDR5，DDR4 与 DDR3 的产线缩到原来的四分之一左右，但存量市场仍在换新和扩容 [21]；64GB DDR5 RDIMM 服务器条的合约价半年翻倍，而 DDR4 的拆机 ECC 条虽然也涨，仍有现货流通、价格低一个档 [21][22]。整机算下来，显卡 6000 到 9000、服务器平台加内存 3000 到 5000、机箱电源等若干，24G 卡配置大约 1 万到 1.5 万元可以起步；若上 32G 显存这一档，仅显卡一项就比 24G 档高出五千到七千元，整机要按两万三左右的预算来打算。这一路的代价也要说清楚，而且要想在前面：服务器平台是多通道加多核的设计，功耗高，满载电费不少；噪音也大——机架式的风扇是按机房环境设计的，放书房或者卧室里，那声音跟台式机完全不是一个量级，长期放在自己每天活动的房间里，使用体验是实实在在要考虑的问题（真要用，建议放在阳台、储物间，或者干脆是隔层的机房）。

汇总一下当前行情：

方案	路线	当前价位（2026 年 10 月行情）	说明
24G 显存显卡 + DDR4 ECC 服务器平台 + 拆机 ECC 大内存	Strata 合跑一个模型	约 1 万-1.5 万起步	性价比路线，A 卡生态需折腾，二手行情浮动大 [4][20][21][22]
32G 显存显卡 + 服务器平台大内存	Strata 合跑一个模型	约 2.3 万（32G 档已从 1.1 万涨至 1.4 万）	显存更大，长上下文与更高精度有空间；显卡单月涨约三千 [20]
统一内存小主机（128GB 统一内存）	Halogen 一机多模型	约 2 万（部分机型 2.6 万）	不用单独配显卡，一年从 1.07 万涨到现在 [18][17]
CUDA 生态的统一内存工作站	Halogen 一机多模型（CUDA）	3 万多，接近 4 万	官价 3999→4699 美元；单机速度一般，组集群才有意义 [17]

上图中横轴是整机价格（2026 年 10 月行情），纵轴是跑千问 3.8 Flash Next 的生成速度，气泡面积代表显存或统一内存的容量，颜色越偏红价格越高。几个配置的位置值得留意：12G 与 22G 显存的两档在起步区，速度 90 tokens/s 上下，是入门最低的两档；两个 24G 档落在主流区，速度更高、价格也只贵了一截，是图上「价格 - 速度」性价比最好的区域；32G 显存档价格上一大步（2 万+），买它图的不是速度，是把权重多装一些在显存里换长上下文与更高精度的余量；最右侧两台 128G 统一内存整机气泡最大、价格最贵，速度按各自带宽折算（一台 256GB/s、另一台 273GB/s）在 60 到 70 tokens/s 一档，其中 256GB/s 那台略慢一点——没有独显那一路快，但靠统一内存不用拼装、开箱即整台。要快而省钱，24G 显卡这一档是最优区域；要省心且内存大，统一内存整机是另一个方向的答案。

也就是说，一万出头有机会起步，比较舒服的配置在两万上下，预算到几万可以买到 CUDA 生态的整机或者多卡平台。在线大模型是按月付费、价格还在上行的流动成本，本地硬件是一次性的固定支出；前者随用量与调价浮动，后者配置一次之后就不再受调价影响。

开支随用量分摊：某些任务只有本地跑得起

换个角度算，这一两万的硬件支出用来支付在线服务，也许够用好几年。所以本地部署的意义不是「省钱」，至少不光是省钱——它的意义是：有了本地模型，在线模型就从「唯一的依靠」变成了「可选的补充」，不再是谁涨价、谁断服都没有替代品的那种局面。

所以，单看一次性的投入，一两万不算便宜，但有的场景，可能只有本地模型来做才比较划算，不过只要使用的时间足够长、用量足够大，这笔钱是可以慢慢分摊的，说到底就是规模效应。比如批量整理知识库，又或者是涉及到不便联网的数据（地学领域常有这种情况）。

前一段时间，我想对自己积累下来的所有代码做一次处理：先从中提炼技能，顺路整理成知识库。这件事用在线大模型来跑，结果是花了将近 700 美元才做完。之后我还打算把所有的参考文献也用类似的方法处理一遍——这件事用在线模型恐怕就很不现实了：太贵，光预印本网站就有几万篇文章，就算单篇的处理费用比代码那次低很多，乘上几万篇也是一笔相当可观的支出。

这种规模大、重复性高的整理工作，可能正是本地大模型的用武之地。机器购置一次，之后运行多少次都不会再产生按量的费用，用得越多，单次成本就越低。私有知识库这类事情，或许本来就比较适合在自己的机器上运行。

经过这几周的过渡，我现在日常的所有任务——工具调用、信息检索、代码翻译——全部都用本地模型了。在线服务我可能还会用，只是作为备选了，用哪一家的、用多少、什么时候用，现在就很灵活了。

参考文献

中华网：《DeepSeek上次崩还是1天前服务再度异常引发关注》　https://news.china.com/socialgd/10000169/20260401/49374515.html（2026-03-31，「服务器繁忙」报错；3 月 29 至 30 日近 12 小时中断的回顾）
DoNews：《DeepSeek一日内两次服务中断，3月31日宕机一小时后恢复》　https://www.donews.com/news/detail/4/6492239.html（2026-03-31 17:02 异常、18:05 恢复，约 1 小时）
游侠网：《豆包点评DeepSeek频繁宕机爆发式增长下的必经阶段》　https://www.ali213.net/news/html/2026-3/1004159.html（2026-03-30，大模型推理算力消耗巨大、硬件供应链紧张制约扩容速度）
Strata 开源项目仓库与文档（多档消费级显卡的实测速度、混合专家激活机制、显存与内存与处理器协同的分层放置、最小内存要求）　https://github.com/Niko1221/Strata
快科技（转自凤凰网科技）：《半个月崩7次！估值3800亿AI顶流算力告急：6000人集体哀嚎》　https://tech.ifeng.com/c/8sMu5IZFGPt（2026-04-16，Anthropic 半月 7 次中断明细、90 天正常运行率 98.95% 对企业级 99.99%）
DoNews：《美国主流AI服务集体宕机：ChatGPT、Claude、Grok等均异常》　https://www.donews.com/news/detail/4/6697106.html（2026-09-03/04，持续约 3 小时 40 分，编程工具因依赖三家接口被波及）
东方财富网（转自21世纪经济报道）：《黑色星期四！GPT、Claude、Grok出现历史级集体宕机》　https://finance.eastmoney.com/a/202609043864546436.html（2026-09-03/04，三家公司状态页确认；业内指多家公司共享的云基础设施可能是原因；Downdetector 故障报告：OpenAI 超 1.2 万份、另两家约千份）
36氪：《DeepSeek史诗级宕机13小时，一夜崩上热搜，网页版更新》　https://36kr.com/p/3746701577372168（2026-05-24，网页端与 App 全部无法访问、官方状态页红色告警、抢修一整夜）
快科技：《本月第四次！DeepSeek又崩了约半小时现已修复》　https://m.mydrivers.com/newsview/1125563.html（2026-05-28，10 时 21 分起中断、10 时 50 分恢复，约 29 分钟）
澎湃新闻：《DeepSeek崩了》　https://baijiahao.baidu.com/s?id=1866419420998691474（2026-05-28，用户在社交平台的反馈与官方状态页信息）
东方财富网（来源：时代周报）：《DeepSeek又崩了，年内18次异常，大模型C端免费模式走到十字路口》　https://finance.eastmoney.com/a/202605283753063011.html（2026 年内第 18 次部分性能异常；OpenRouter 数据：全球周调用 28.9 万亿 token、中国 9.22 万亿、免费模式难持久）
北方网：《DeepSeek恢复服务！豆包：频繁崩溃是成长代价》　http://it.enorth.com.cn/system/2026/03/30/059272852.shtml（2026-03-30，同行评价频繁故障为「爆发式增长下的必经阶段」）
钛媒体：《Codex也断了：OpenAI三线齐崩，Agent时代的宕机账单怎么算》《OpenAI全球宕机8小时未完：当9亿人的AI依赖成为单点故障》　https://www.tmtpost.com/agent/ai-article/19383（2026-07-25，对话、API、编程工具全线瘫痪超 8 小时、无预警）
东方财富网：《DeepSeek为何总是"崩"？》　https://finance.eastmoney.com/a/202605293753451713.html（业内人士归因：用户规模增长过快，服务器算力扩张难以匹配激增的流量需求）
千问 3.8 Flash Next 模型主页　https://huggingface.co/Qwen/Qwen3.8-Flash-Next
Halogen 开源项目仓库（面向统一内存芯片平台，文档给出长文本预填充速度等指标）　https://github.com/peonist-ai/halogen-flash-server
什么值得买：一篇本地 AI 小型主机与个人 AI 工作站涨价的追踪帖　https://post.smzdm.com/p/awwr2xlk/（2026-08-16；记录相关设备一年内价格上行幅度，归因于 AI 数据中心争抢内存与 HBM 产能）
什么值得买：一篇统一内存小主机一年价格变化的追踪帖　https://post.smzdm.com/p/aqrmepek/（2026 年 9 月；从去年 1.4 万元涨到 2.2 万元且缺货）
抡锤者论坛：关于某超大混合专家模型开源权重与多机部署的一篇帖子　https://lcz.me/topic/1611（2026-09-11；权重分层构成、机台数与部署可行性、单条与并发生成速度）
本文作者此前的文章：《本地跑模型的显卡怎么选？从2000到2万的价位全景指南》　https://mp.weixin.qq.com/s/MPnQmPaWOy_RMt29gJ-a7w?token=379900131&lang=zh_CN（2026-09-13 行情）
什么值得买：一篇服务器内存价格半年变化的追踪帖　https://post.smzdm.com/p/ae6vk73z/（2026-09-19；服务器内存合约价半年翻倍、交期大幅拉长）
什么值得买：一篇旧代内存价格变动的追踪帖　https://post.smzdm.com/p/al3xg7mg/（2026-08-23；旧代拆机服务器内存仍有现货流通、比新一代便宜）

谷歌把太空数据中心送上天了：散热怎么解、算力有多少、适合什么场景

2026-10-03T00:00:00+08:00

谷歌把太空数据中心送上天了：散热怎么解、算力有多少、适合什么场景

10 月 1 号，美国太空探索技术公司 SpaceX 用猎鹰九号（Falcon 9）火箭执行了 Transporter-18 任务，从美国加州的范登堡太空军基地把一批卫星送入轨道。其中一颗是商业卫星公司 Planet Labs 造的，载荷是谷歌的 TPU（张量处理单元，Tensor Processing Unit，谷歌自研的 AI 加速芯片），这是谷歌 Project Suncatcher 计划的首次入轨 [1][2][3][4][5]。群里当天也讨论起来了，一个朋友问，太空散热的问题谷歌要怎么解决；另一个朋友引了句中文转述，说真空里只能靠辐射散热，芯片连着跑十五到二十分钟就得关机冷却，"只能靠关机辐射散热了"。

我的想法跟这位朋友差不多，真空里散热是真难。但"只能靠关机"不全对，散热可以靠调度绕过去，不一定非得跟它硬碰。这篇文章要提出并验证的就是一套"轮班"办法：让设备轮流运行，任意时刻保证有一两台在跑，跑着的负责散热，停下的负责降温，互相别烤着，接成一个连续的接力。这套轮班思路是本文提出来的，论文和官方材料里都没有，群里那两句讨论只是起了个头。下面拿谷歌论文评审版给的散热口径 [6]，把它认真算一遍。

先把出处核一下，再建两节点的热模型，跑五组模拟，然后往外推：功耗和面积的通用相图、降功耗、热缓冲，以及真实推理任务的算力和数据流。最后说说那篇论文还能往哪儿改。

一、原始出处都写了啥

中文里传的说法有几处跟原文不一样，先澄清一下。

一个常见的说法是这次上了四颗，其实就一颗。Google 官方博客的原话是 "our prototype satellite for Project Suncatcher, built in partnership with Planet, launched into orbit aboard the Transporter-18 rideshare mission with SpaceX"（我们 Project Suncatcher 的原型卫星，与 Planet 合作建造，已随 SpaceX 的 Transporter-18 拼车任务入轨），单数 [1]。美国财经媒体 CNBC 同一天的报道也确认了范登堡的发射窗口和入轨后联系正常 [2]。

"15-20 分钟"这个数也不是原文。科技媒体 TechCrunch 写的是 "the satellite will fire up its TPU in 15-minute bursts to avoid straining the satellite's power and thermal management systems"（卫星会以 15 分钟一档的突发方式启动 TPU，以免压垮卫星的电源和热管理系统），15 分钟一档，怕的是电源和热管理两套系统一起吃紧 [3]。多出来的"20 分钟"是转述时加的，但方向没错，确实是间歇工作、要冷下来再跑。

"2027 年再发两颗、测星间激光组网"这句倒是对的。谷歌 2025 年 11 月 4 号在 research.google 博客上说要 "launch two prototype satellites by early 2027 ... validate the use of optical inter-satellite links for distributed ML tasks"（2027 年初发射两颗原型卫星……验证用星间激光链做分布式机器学习任务），那两颗是为算力专门造的平台 [7]，Planet Labs 公司的官宣里也提到了这个 2027 年初的时间点 [4]。

"约 1 千瓦"出自 TechCrunch 同一句 "supplying a kilowatt of continuous power"（提供一千瓦的连续功率）[3]。"太阳能是地面 8 倍"出自论文，原话 "receive up to 8x more solar energy per year than a panel located on Earth at mid-latitude"（一年接收的太阳能是地球上中纬度地区太阳能板的 8 倍）[6][8]。太阳同步晨昏轨道（沿着地球昼夜分界线飞行、几乎全程都晒得到太阳的轨道）、650 公里、81 颗卫星、半径 1 公里编队这几个数字，也都是论文里的 [6][8]。

论文后来出了同行评审版，登在能源领域期刊 Joule 上（Joule 11, 102678，2027 年 2 月 17 日刊出，在线 2026 年）[6]，预印本是预印本平台 arXiv 上的 2511.19468 [8]。评审版比预印本多了一大段散热参数，这次的模型就是冲那段去的。原文是 "A published ballpark figure for contemporary GPU/TPU power density is 90 W/cm² for Nvidia's H100, and ideally, silicon junction temperatures should be kept below 90°C, while near a satellite radiator temperature of 50°C, blackbody radiation decreases by about 1.2% per K of lower temperature..."（据公开数据，当下 GPU/TPU 的典型功率密度是英伟达 H100 的 90 W/cm²；芯片结温最好保持在 90 摄氏度以下；在辐射板温度 50 摄氏度附近，温度每低 1 K，黑体辐射能力下降约 1.2%……）。这里的芯片结温（junction temperature，芯片里晶体管工作时的温度，整颗芯片最怕过热的地方）就是这次的硬约束 [6][9]。论文说散热靠热管（一种靠工质相变、把热从一头搬到另一头的被动器件），航天上常用铝-氨或铜-水做工质，还推荐了 Silk 的《Introduction to Spacecraft Thermal Design》（《航天器热设计导论》）当入门 [6][10]。

论文自己的散热结论很干脆：热管加辐射板，被动式，全靠辐射把热丢给深空 [6][8]。Facts 页说得更直接，"In a vacuum, you can only diffuse heat via radiators, which requires a totally different approach to cooling electronics."（真空中只能靠辐射板散热，这需要一套完全不同的电子设备冷却思路）[11] 论文也把散热列进了 "significant engineering challenges remain"（仍存在重大工程挑战）那张名单，说后续任务还得继续交作业 [6][8]。

这次要算的事说清楚：拿论文给的散热口径（结温上限 90 摄氏度，芯片到板热阻 0.04 K/W）建一个两节点的热模型，回答四个问题——原型星为什么只能 15 分钟一档、1 kW 芯片连续运行要多大辐射板、芯片到板的热阻有多关键、以及本文提出的轮班接力需要几颗星。结果先摆出来：单看散热，原型星能连跑 47 分钟，15 分钟其实是电池先见底；1 kW 要连续，得配大约 2 平方米辐射板；热阻从 0.04 涨到 0.06，可用率就从 0.53 掉到 0.37；轮班方案 5 颗星能把 2 台常开覆盖到 100%，但每颗星平均只出 469 W。这些数下面逐个算。

论文这段话正好补齐了上一版模型缺的两样：一个是芯片结温这个真正的约束，另一个是芯片到板之间的温度梯度，论文原话是 "needs to be engineered to be small"（这个温差要设计得尽量小）[6]。所以这一版模型升级成两节点。

二、真空里的热为什么难散

黑体表面的辐射功率是

\[P = \varepsilon \sigma A (T^4 - T_{sink}^4)\]

$\sigma = 5.67 \times 10^{-8}\,\mathrm{W/(m^2 \cdot K^4)}$ 是斯特藩-玻尔兹曼常数，$\varepsilon$ 是表面发射率，热控涂层一般能到 0.85-0.92 [12]，$A$ 是辐射板面积，$T_{sink}$ 是等效热沉温度。

太空的热沉有两块来源。一块是 3 K 的宇宙微波背景，另一块是地球，地球往外散红外（约 240 W/m²），还反射太阳光（反照率约 0.3）。650 公里的太阳同步轨道，两边合起来等效热沉温度大概落在 250-270 K，本文取 260 K，依据是 Gilmore 主编的《Spacecraft Thermal Control Handbook》（航天器热控制手册）[12]。

关键在 $T^4$ 这个四次方。它的相对灵敏度是

\[\frac{1}{P}\frac{dP}{dT} = \frac{4}{T}\]

50 摄氏度（323 K）处，4/323 = 1.24%/K，跟论文的"约 1.2% per K"对上了 [6]。也正因为这个四次方，空间站的辐射板敢跑到六七十摄氏度，烫一点散热能力涨很多，美国航天局 NASA 国际空间站的主动热控系统就是靠大面积板子排热的 [12]。芯片不行，结温过 90 摄氏度就出毛病 [6]。论文给的这组数（结温<90℃、辐射板~50℃）意味着一件事：1 kW 功率下，芯片到板面要压掉大约 40 K 温差，折合总热阻 0.04 K/W 上下。这 0.04 就是这次模型里的关键参数 $R$。

三、两节点模型

老版本把整颗星当成一个温度节点，太粗糙。这一版拆成两个：芯片结温 $T_J$ 和辐射板温度 $T_R$，中间用热阻 $R$ 连起来，这 $R$ 是热管、安装面、界面材料加在一起的总和 [6][10]。

\[C_J \frac{dT_J}{dt} = P(t) - \frac{T_J - T_R}{R}\]

\[C_R \frac{dT_R}{dt} = \frac{T_J - T_R}{R} + P_{bus} - \varepsilon \sigma A_{eff} \left( T_R^4 - T_{sink}^4 \right)\]

$C_J$ 是芯片加封装加均热板的热容，$C_R$ 是星体和板的热容，$P(t)$ 是芯片功率，$P_{bus}$ 是待机总线功耗，$A_{eff} = 2 A_{rad} \times 0.85$。约束从"辐射板温度"换成了"芯片结温"：$T_J \le 90\,^\circ\mathrm{C}$ [6]。

稳态下有 $T_J = T_R + P R$。代进约束，辐射板实际能到的温度上限就是 $T_{R,max} = 90\,^\circ\mathrm{C} - P R$。这一步是关键：结温是硬上限，热阻越大，留给辐射板的额度越小。要是 $P R$ 大到逼近"90 摄氏度减热沉温度"那个差，板子再大也没用，芯片自己先过热了。

参数表：

参数	取值	出处
芯片结温上限	90 ℃（363 K）	Joule 评审版 [6]
芯片到板总热阻 R	0.04 K/W	由 40 K @ 1 kW 反推 [6]
GPU/TPU 热流密度	90 W/cm²（H100）	评审版引 NVIDIA Hopper [6][9]
太阳能（LEO 低地球轨道晨昏轨）	地面中纬度的约 8 倍	论文 [6][8]
原型星功率	1 kW	TechCrunch [3]
原型星辐射板 A_rad	1.5 m²	本文假设
芯片节点热容 C_J	2×10³ J/K	本文假设
星体热容 C_R	4×10⁴（单机）/6×10⁴（集群节点）J/K	本文假设
辐射面发射率 ε	0.9	热控涂层典型值 [12]
等效热沉温度	260 K	综合地球红外与反照 [12]
待机总线功耗	80 W	本文假设
15 分钟突发档位	电池容量限制	TechCrunch [3]

谷歌没公开原型星的板面积、热容和热阻，这几个是按量级推的。模型的价值不在复刻原型，而在把参数机制摊开，看改哪个会翻盘。

四、15 分钟一档，到底是不是热卡住的

原型星平时是这样工作的：从 22 摄氏度（295 K）起跑，满负荷 1 kW，15 分钟后电池见底强制停机，这时候芯片结温 72.2 摄氏度，辐射板才 33.2 摄氏度。然后待机 80 W 慢慢散，24.8 分钟后结温回到 22 摄氏度，进入下一轮。一个周期 39.8 分钟，占空比 38%。

算出来一个反直觉的数：热学能撑的热重启窗口是 47.4 分钟，比 15 分钟长得多。也就是说光看散热，这颗星还能多跑半个多小时，15 分钟一档的真正瓶颈是电池和电源，不是热。TechCrunch 原话把 "power and thermal management"（电源和热管理）两个都点了 [3]，模型正好把两条约束拆开：热学给 47 分钟，电池给 15 分钟。原型星的结温峰值离 90 摄氏度还差 18 K，散热在原型阶段绰绰有余。

要是电池不管硬跑，稳态下辐射板爬到 64 摄氏度、结温爬到 104 摄氏度，越过红线。所以"原型星连续跑不了满负荷"这话还成立，只是卡点从板温换成了结温。

图里是原型星四个连续周期的温度曲线，红的是芯片结温，蓝的是辐射板温度。几个点值得看：结温峰值 72 摄氏度，离 90 摄氏度还差 18 K，15 分钟一档不是热卡的；辐射板这时候才 33 摄氏度，一半的散热本事都没使出来；待机那 25 分钟里结温掉得比板温快，因为芯片节点热容小，温度基本跟着板走。

五、辐射板加到多大才够

15 分钟一档既然是电池卡的，那板子要多大才能撑住连续满负荷？把面积从 1.2 试到 3.0 平方米，看连续运行时的结温和板温：

A_rad (m²)	连续运行结温	连续运行板温	结论
1.2	116 ℃	77 ℃	结温超限
1.5	104 ℃	64 ℃	结温超限
1.8	94 ℃	54 ℃	单机最长 101 分钟
2.0	89 ℃	49 ℃	刚够连续
2.4	81 ℃	41 ℃	连续有余量
3.0	72 ℃	32 ℃	连续很宽松

按评审版结温<90 摄氏度的口径 [6]，每 kW 算力大概要 2.0 平方米板才能连续。原型星实际多大谷歌没说，但它在 15 分钟档上跑、结温还剩 18 K 余量，板面积估计在 1.5-2 平方米之间。

六、热管才是那个隐藏的坎

论文那句 "temperature differential ... needs to be engineered to be small"（芯片到板的温差要设计得尽量小）[6]，翻成模型的话就是热阻 $R$ 必须小。把 $R$ 从 0.02 试到 0.12 K/W，看单机占空比和需要的节点个数（周期稳态，跑 50 个周期取后 30 个平均）：

R (K/W)	运行时长	停机时长	占空比 η	保 2 台常开需 N≥	辐射板温度区间
0.02	连续	—	1.00	2.0	22-58 ℃
0.04（论文口径）	43 min	38 min	0.53	3.8	21-42 ℃
0.06	6 min	10 min	0.37	5.4	21-23 ℃
0.08	4 min	8 min	0.31	6.4	18-18 ℃
0.12	3 min	9 min	0.24	8.2	13-13 ℃

热阻从 0.02 涨到 0.06，占空比从连续一路掉到 0.37，中间 0.04 是 0.53。道理不复杂：$R$ 一大，结温很快顶到 90 摄氏度，辐射板还没热起来就被迫停机。$R=0.12$ 时板子基本停在 13 摄氏度，一块本来能排几百瓦的板，实际只排几十瓦。热管做不好，散热板再大也白搭。

图里横轴是热阻，红线（左轴）是单机占空比，紫线（右轴）是保两台常开的最小节点个数。$R=0.02$ 时结温稳态就在 90 摄氏度以下，能连续跑，两台够；$R=0.04$ 掉到 0.53，要四台；$R=0.12$ 要八台以上。这就是"梯度必须做小"的量化意思。

再往下推，$R$ 还给单芯片功率封了顶。结温上限 90 摄氏度、热沉 260 K，差 103 K，每瓦功率吃掉 $R$ 那么多温差：

\[P_{max} = \frac{90\,^\circ\mathrm{C} - T_{sink}}{R}\]

$R=0.04$ 是 2.6 kW，$R=0.08$ 只剩 1.3 kW。过了这个数，板子再大也没用，芯片自己烧穿。所以太空算力的单芯片功率不是被板子卡住的，是被芯片到板那段热阻卡住的。

七、轮班接力到底要多少颗星

我们还可以设计一种轮班方案：设备轮流运行，停下来的负责散热。把它写成调度规则：每颗星 1.2 kW、2 平方米板、$R=0.04$，结温到 90 摄氏度强制停机，回到 22 摄氏度才能再次开机；最多两台同时跑；优先选累计运行时间短的。编队里其他星的板会互相照面，用一个邻居互烤系数 $f=0.15$ 表示。跑 48 小时，前 24 小时当过渡期扔掉：

节点数 N	至少 1 个节点在跑	平均并发	每台平均运行 (h/24h)	等效满负荷
1	47%	0.47	11.3	0.57 kW
2	48%	0.95	11.4	1.14 kW
3	89%	1.33	10.6	1.60 kW
4	88%	1.77	10.6	2.12 kW
5	100%	1.95	9.4	2.35 kW
10	100%	2.00	4.8	2.40 kW
25	100%	2.00	1.9	2.40 kW

N=1 和 N=2 的覆盖率都卡在 47% 左右，是锁步共振：两个节点一起运行、一起升温、一起停机，错不开。单机占空比 0.53，双星轮换也只有一半出头。节点数至少要有并发上限的两倍才错得开，N=5 覆盖率到 100%，每颗星平均一天运行 9.4 小时。

图里是 5 颗星同一时间段的排班，一行一颗，有颜色的条就是它在跑。任意时刻大概两条重叠，这就是接力：某个节点结温顶到 90 度停机，另一个正好凉透顶上来。每个节点运行四十来分钟、停机四十来分钟，5 个错峰，凑出差不多两台的连续算力。

邻居互烤也有敏感度：$f=0.15$ 没事，加到 0.3 等效负荷掉约 14%，到 0.6 覆盖率掉到 74%。论文自己提过 "would have to pay attention to occlusion of outgoing 'rejected heat' IR radiation between satellites"（得留意卫星之间排出的废热红外辐射互相遮挡的问题）[6]，注意到了，但还没交作业。

八、汇总

项目	数值	说明
原型星（本次发射）
15 分钟突发后结温	72 ℃	离 90 ℃ 上限还有 18 K
热学允许的热重启窗口	47 min	远大于电池给的 15 min
实际 15 分钟档位	电池限制	占空比 38%
连续满负荷结温	104 ℃	超限，必须间歇
辐射板需求（1 kW）
连续运行所需面积	约 2.0 m²/kW	结温<90 ℃
热阻敏感性（1.2 kW，2 m²）
R=0.02 / 0.04 / 0.06 / 0.08 K/W	η=1.00 / 0.53 / 0.37 / 0.31	断崖在 0.04-0.06 之间
单芯片功率天花板	2.6 kW（R=0.04）	板再大也越不过
节点轮班（1.2 kW，2 m²，R=0.04）
最小节点个数	N≥m/η≈3.8	N=5 实现全天 2 台常开
每颗星平均输出	469 W	冗余比约 2.5 倍
100 MW（兆瓦）等效算力	约 213,000 颗星	每颗 469 W
对应入轨质量 / 发射费	约 1.49 万吨 / 约 30 亿美元	按 $200/kg、5 年摊销 5,970 $/kW/y
地面电费参照	570-3,000 $/kW/y	论文给的区间 [6]
通用场景与降功耗
连续运行的单芯片功率上限	363 / 646 / 1010 / 1409 W	对应板面积 0.5 / 1.0 / 2.0 / 4.0 m²
推荐低功耗点	400 W + 1.0 m² 板	结温 60 ℃，可连续，无需轮班
热缓冲
1.0 kW / 1.5 m²	η 0.49 → 0.74	可回收 0.25 可用率
1.2 kW / 2.0 m²	η 0.53 → 0.70	可回收 0.17 可用率
真实任务（70B 推理，量级）
4-bit 权重	35 GB/模型	每颗参与推理的星存一份或一份分片
单芯片吞吐	约 28 tokens/s（满速）/ 约 15（轮班 0.53）	HBM 1 TB/s、带宽受限
权重上行	约 1.4 s/星	TBIRD 200 Gbps [13]
星间分发	<0.1 s	单口径 9.6 Tbps [6][8]

九、通用场景，和怎么把功耗降下来

前面都是按 1 kW 单芯片、2 平方米板这一套算的。换个功率、换个板面积会怎样？把单芯片功率从 200 W 试到 3000 W，板面积从 0.5 试到 4 平方米，画出占空比相图：

绿色是能连续跑的，红黄是必须轮班的。几个数直接读：单芯片 200 W，什么板都能连续，根本不用轮班；400 W，板子 0.8 平方米以上就连续；1 kW，要 2.0 平方米才算连续，这就是原型星上不去的原因；3 kW，板子再大都到不了连续，占空比最高 0.26。

连续运行的单芯片功率上限（板面积固定）大致是：0.5 平方米 363 W，1.0 平方米 646 W，2.0 平方米 1010 W，4.0 平方米 1409 W。加面积越来越不划算，因为 $T^4$ 那项：板子越大温度越低，单位面积能排的热掉得越快。

所以"降功耗"这条路是通的。把单芯片从 1 kW 压到 400 W 左右、配 1 平方米板，结温才 60 摄氏度，直接连续跑，根本不需要轮班。轮班这套调度本来就是给"高功耗密度挤进小散热板"打的补丁，回到低功耗连续运行，补丁就不需要了。

十、还有个方案：热缓冲

不想降功率的话，还有条路叫热缓冲：在芯片和板之间加一层相变材料（Phase Change Material，PCM，一种受热熔化时能把大量热量吸进去、自身温度却几乎不升的材料）。有它兜着，板子能更久地待在允许的最高温度附近，把散热能力用足。

这条路的理论上限也能算：假设缓冲够大，板子一直稳在 $T_{R,max} = 90\,^\circ\mathrm{C} - P R$ 不上下晃，占空比就是 $η_{ideal} = [k(T_{R,max}^4 - T_{sink}^4) - P_{bus}] / P$。拿它跟当前模型的实际占空比比，差的就是热缓冲能捞回来的可用率：

1.0 kW / 1.5 m² 这组，实际 0.49，上限 0.74，能捞回 0.25；1.2 kW / 2.0 m² 这组，实际 0.53，上限 0.70，能捞回 0.17。

换句话说，加了合适的热缓冲，同样硬件，可用率能提 0.17-0.25，等于所需节点个数砍掉两三成。代价是相变材料的重量：一次运行窗口要吸掉 $P \times t_{on}$ 的热，1 kW 跑 40 分钟就是约 2.4 MJ，按石蜡类相变焙 200 kJ/kg 算，得配十几公斤。所以这是拿重量换可用率，跟"加大板子""加卫星冗余"是同一杆秤上的三个砝码，哪个划算要看发射成本和质量预算。

十一、真实任务怎么跑：算力、传递、存储、共享

前面都在算热，这节把热接回真实任务。在一颗星上跑一个 70B 级大模型推理，绕不开四件事。

先说算力。推理是带宽受限的：生成一个 token 要把权重整个读一遍，所以单芯片速度大概是 tokens/s ≈ HBM带宽 / 权重字节数。70B 模型 4-bit 量化后权重约 35 GB，配 1 TB/s 的 HBM，满速约 28 tokens/s。套上轮班的 0.53 占空比，实际只剩约 15 tokens/s；走低功耗连续（400 W）就能拿回满速。这是降功耗的第二个好处，不光不用轮班，吞吐还更高。

传递这块，地面训好的权重得先传上去。美国航天局 NASA 的 TBIRD（TeraByte InfraRed Delivery，太字节红外传输，星地激光通信实验）演示过 200 Gbps 的星地激光通信 [13]，35 GB 传一颗星约 1.4 秒；要在整个编队分发，靠论文说的星间链路（单口径 9.6 Tbps [6][8]），一派发不到 0.1 秒。上行慢、横向快，所以合理的做法是地面先传给少数几颗，再靠星间链路铺开。

存储麻烦的不是容量，是辐射。每颗参与推理的星都得存一份权重（数据并行），或者存一部分（流水线/张量并行），35 GB 的 4-bit 权重本身不大。论文辐照测试里，HBM 累积 2 krad(Si)（千拉德，辐射剂量的单位，Si 指硅）后才出异常，五年任务剂量约 750 rad(Si)，没到硬失效 [6][8]；软错误率约每 17 rad 一次，折算大概三百万次推理错一次 [6][8]。这个量级推理能接受，但要配 ECC（纠错码，Error Correcting Code，能自动发现并纠正存储里的位翻转）加定期校验重载 [6]。权重不能当静态文件丢在 NAND（一种闪存）里，得有后台巡检把被打翻的位纠回来。

最后是共享。单颗星跑不动大模型，就把模型切开：流水线并行把不同层分到不同星上，激活值靠星间链路在层间传，论文那个近距离编队（最近邻 100-200 米 [6][8]）就是为了让这种高带宽低时延的链路成立。但这里有个跟散热直接冲突的地方：流水线并行要求参与的星长期同时在线，而轮班的本质是"同一刻只有少数几颗在跑"。所以轮班跟大模型并行训练/推理是冲突的，轮班天生适合异步、松耦合的活（各干各的推理），不适合几千颗芯片同步跑几个月的训练。论文辐照测试自己也认了，训练场景 "requires further study"（还需要进一步研究）[6]。太空算力先从推理做起，这个判断在热模型和任务模型里是一致的。

十二、可能要做改进的方向

散热和功耗这块，论文把边界交代得很清楚，结温压到 90 摄氏度以下、板子大约 50 摄氏度、H100 级热流密度 90 W/cm² [6][9]，但停在了参数上，没给出一个能算占空比、轮班规模、节点个数的模型。补上两节点模型之后才看清，真正卡脖子的是芯片到板那段热阻，它既给单芯片功率封了顶，又直接决定可用率。通用场景论文也没铺，它默认的是热管加辐射板的稳态散热一种思路，没回答"换个功率、换个板面积会怎样"。相图那节补了这块，结论是单芯片压到几百瓦、小面积板就能连续，比硬扛高功耗省事得多，这条路论文没展开。

算力、数据存储、训练还是推理，这一组论文也没串起来。它讲了星间带宽、辐照、发射成本 [6][8]，但没回答一个 70B 推理在轨上怎么跑、权重怎么传上去、怎么存、怎么在编队里共享，这次补了量级估算。更要紧的是训练和推理的岔路：论文辐照测试自己承认软错误对大规模训练的影响还需进一步研究 [6]，把训练往后放了，这跟本文热模型和任务模型的结论一致，轮班适合异步松耦合的推理，跟几千颗芯片同步跑几个月的训练是矛盾的。太空算力先做推理，不是保守，是物理和调度一起定的。

环境和寿命、还有实测数据，是论文留白最多的部分。评审版新增了生命周期评估、火箭再入、卫星残骸的段落，但明说完整的生命周期评估（Life Cycle Assessment，LCA）不在本文范围内 [6][14]，把环境账留给了以后；辐照和材料退化也只给了剂量和软错误率，没算五年寿命末期发射率和电池还剩多少余量。最后这些结论都还没有在轨数据背书，这次原型星刚上天 [1][2]，热设计、辐照、编队控制都要等真飞数据来校，论文的散热参数是从地面真空罐和辐照台架推的 [6][11]，在轨会不会打折，只能等。

十三、作为一道数学建模例题

把它当一道例题收一下。已知功率 P、辐射板面积 A、发射率 ε、热沉温度 T_sink、结温上限 T_J_max、芯片到板热阻 R、两节点热容；求单机连续运行所需面积、占空比、单芯片功率上限、轮班实现 m 台常开所需的最小节点个数、热缓冲可回收的可用率、通用场景相图。

解法走四步。第一步建模型，两节点热网络，$C_J\,dT_J/dt = P - (T_J-T_R)/R$，$C_R\,dT_R/dt = (T_J-T_R)/R + P_{bus} - k(T_R^4 - T_{sink}^4)$，$k = 2\varepsilon\sigma A F$，约束 $T_J \le 90\,^\circ\mathrm{C}$。

第二步用准稳态把约束从结温换到板温，$T_J = T_R + PR$，得 $T_{R,max} = 90\,^\circ\mathrm{C} - PR$，由此得到三个闭式：连续运行所需面积、单芯片功率天花板 $P_{max} = (90\,^\circ\mathrm{C} - T_{sink})/R$、热缓冲上限 $η_{ideal}$。

第三步数值积分并做互验：辐射板方程做精确积分再加结温充电时间，跟 RK 自适应格式对照，偏差 6.3%。

第四步离散事件仿真：把调度规则（$m=2$、公平轮换、返回温度线、邻居互烤）写进循环，每步 5 秒，统计最后 24 小时。锁步共振（N=2 覆盖 47%）和 N=5 接力闭环，都是调度规则直接推出来的。

局限也明摆着，都是我自己的简化：芯片到板就一个集中热阻，真实是芯片内部温度分布加分段热管；姿态只取一个系数，真实卫星迎阳受晒、背阳辐射，温度随轨道周期性起伏；编队互烤用均值场，真实近邻遮挡是几何问题；发射率和太阳能电池效率设成常数，没算涂层退化、原子氧、微流星体这些寿命问题。模型给的是量级和机制，不是设计图纸。

参考文献

Beals, T. "Our Project Suncatcher prototype satellite is in orbit." Google Blog, 2026-10-01. https://blog.google/innovation-and-ai/models-and-research/google-research/project-suncatcher-prototype/
Kolodny, L. "SpaceX launches Google AI chips into orbit in push toward space-based data centers." CNBC, 2026-10-01. https://www.cnbc.com/2026/10/01/spacex-to-launch-google-ai-chips-to-orbit-with-planet-labs-satellites.html
Fernholz, T. "Google thinks SpaceX's Starship has to launch 1,800 times before space data centers get off the ground." TechCrunch, 2026-10-01. https://techcrunch.com/2026/10/01/google-thinks-spacexs-starship-has-to-launch-1600-times-before-space-data-centers-get-off-the-ground/
Schingler, R. "Planet to Build and Operate Advanced Space Platform for Google's Project Suncatcher Moonshot." Planet Pulse, 2025-11-04. https://www.planet.com/pulse/planet-to-build-and-operate-advanced-space-platform-for-google-s-project-suncatcher-moonshot/
Foust, J. "SpaceX launches Transporter-18 rideshare mission." SpaceNews, 2026-10-01. https://spacenews.com/spacex-launches-transporter-18-rideshare-mission/
Agüera y Arcas, B., Beals, T., Biggs, M., Bloom, J. V., Fischbacher, T., Gromov, K., Köster, U., Pravahan, R., Manyika, J. "Toward a future space-based, highly scalable AI infrastructure system design." Joule 11, 102678 (2027-02-17). DOI: 10.1016/j.joule.2026.102678. https://doi.org/10.1016/j.joule.2026.102678
Beals, T. "Exploring a space-based, scalable AI infrastructure system design." Google Research Blog, 2025-11-04. https://research.google/blog/exploring-a-space-based-scalable-ai-infrastructure-system-design/
同文预印本：arXiv:2511.19468 (v2, 2026-06-17). https://arxiv.org/abs/2511.19468
Palmer, G., Krashinsky, R., Stam, N., Mehta, V., Brito, G., Ramaswamy, S. "NVIDIA Hopper Architecture In-Depth." NVIDIA Technical Blog, 2022.（评审版引用的 H100 热流密度 90 W/cm² 出处）
Silk, E. A. Introduction to Spacecraft Thermal Design. Cambridge University Press, 2020.（论文评审版推荐的航天热设计入门；热管、辐射器、界面热阻）
Beals, T. "Behind Project Suncatcher, our moonshot to put AI in space." Google Blog, 2026-09-24. https://blog.google/innovation-and-ai/models-and-research/google-research/google-project-suncatcher-facts/
Gilmore, D. G. (ed.) Spacecraft Thermal Control Handbook, Volume I: Fundamental Technologies. AIAA, 2002.（辐射换热、等效热沉温度取值；ISS EATCS 辐射器）
Riesing, K. et al. "Operations and results from the 200 Gbps TBIRD laser communication mission." NASA NTRS, 2023.（论文提到的星地光通信演示）
Barker, C. R., Marais, E. A., McDowell, J. C. "Global 3D rocket launch and re-entry air pollutant and CO2 emissions at the onset of the megaconstellation era." Sci. Data 11, 1079 (2024).（评审版新增的发射/再入环境影响）

本地部署Qwen3.8-Flash-Next模型的两条路线：halogen（AI Max+ 395+128G 统一内存）对比 Strata（CUDA 12G 显存 + 64G 内存）

2026-10-02T22:10:00+08:00

本地部署Qwen3.8-Flash-Next模型的两条路线：halogen（AI Max+ 395+128G 统一内存）对比 Strata（CUDA 12G 显存 + 64G 内存）

阿里的 Qwen3.8-Flash-Next 开源之后，社区里想在自己机器上把它跑起来的人不少。先有人做了 halogen，专门在 AMD 的 AI Max+ 395（Strix Halo，128G 统一内存）上跑这个模型，速度能到 30 多 tokens/s；后来又有人做了 Strata，用一张 12G 显存的 CUDA 卡加 64G 内存，把这个 125B 的模型跑到了 60 多 tokens/s。同一个模型，两条硬件路线，本文根据两个项目各自的文档，把它们放在一起对比。

先说清楚这两份材料是什么。halogen 叫 halogen-flash-server，引擎本身闭源，只发布容器镜像，GitHub 上的仓库是部署说明、文档、启动脚本和基准工具。Strata 是一个开源的推理引擎，C++ 和 CUDA 写成，源码都在仓库里，可以自己编译。

同样是针对 Qwen3.8-Flash-Next，halogen 是"把模型整个放进大统一内存，再把 kernel 打磨到只贴合这一颗 APU"，Strata 是"把模型拆成分层结构，去迁就小显存和一台普通 PC"。前者精度和稳定性更好但绑硬件，后者更通用、更开源、峰值更快但精度有取舍。

两个项目分别是什么

halogen-flash-server 的目标写得很窄：一台 AMD Strix Halo、一个模型家族。它不用通用运行时，也没有可移植层和回退路径，每段 kernel 都是为 gfx1151 这一颗 GPU 写的。也正因为只针对一颗芯片和一个模型，它能做一些通用引擎做不到的事，代价是只能跑在这一种硬件上。

Strata 是通用的做法。它支持从 RTX 20 系到 50 系的多张 NVIDIA 卡，也有一套实验性的 AMD HIP 后端，覆盖 RDNA2/3/4 的离散显卡。模型方面，除了原版 Qwen3.8-Flash-Next，它还支持 ISTA-DASLab 的量化版、剪枝过的 Coder 版、Swift 1.5 微调版，以及 Unsloth 的 4bit 版。

简单说，这两者方向正好相对，一个把范围压到最小换取速度和确定性，一个把范围放开换取适配能力。

硬件形态决定了各自的走法

这个模型的体量是关键：125B 参数，外加一张 51B 参数的 n-gram 表。按 halogen 文档的换算，这套东西在 BF16 下是 335 GiB，FP8 下是 173 GiB，而 AI Max+ 395 能用的统一内存只有 124 GB 左右。也就是说，哪怕用 FP8 也放不下，没有"不量化直接装进去"这条路，两个项目都必须先量化。

在必须量化的前提下，halogen 的办法是压到 4 到 6 bit（具体档位见下一节），让 checkpoint 小到能整个放进统一内存。它对主机的要求和常见做法相反：BIOS 里给 iGPU 的专用显存（UMA frame buffer）切到最小（参考机约 512 MiB），同时把 GTT 开到约 124 GiB（文档给的参数是 amdgpu.gttsize=126976、ttm.pages_limit=32505856，两者换算都是 124 GiB），也就是把几乎全部 128G 内存通过 GTT 交给 GPU 用。62 GiB 的权重就常驻在这块共享内存里，n-gram 表单独放磁盘分页读，KV 池在启动时一次性预留。这样它不需要在显存和内存之间搬专家，优化点落在 kernel 是否贴合这颗 APU、矩阵库的调优表、以及内存带宽和功耗上。代价在别处：加载完之后留给其他大程序的空间不多，文档说大约剩十几 GiB，这样这台机器就建议只用来运行模型。

12G 显存搭配 64G 内存的情况下，预算就更紧了，所以 Strata 量化得更狠（专家低到 2 到 3 bit 的 IQ2_XS、IQ3_XXS、IQ3_S 等），而且即便如此也装不下，只能把模型拆开：注意力、门控残差、路由器、共享专家、输出头、KV cache 和一块按路由热度排序的"专家缓存"留在显存；全部专家放内存由 CPU 就地算没命中的部分；那张 n-gram 表放 SSD，每个 token 只读几行。项目文档里提到，专家的分层（显存、内存、SSD）和缓存命中率都是拿真实路由数据先量过再定的。它的瓶颈因此更多在显存与内存之间的搬运、以及 CPU 这一侧的耗时上。

两个项目都得量化，区别在于 halogen 负担得起更高的精度、能让模型整体驻留，而 Strata 得压得更低、并且不断在显存、内存和 SSD 之间搬数据。后面所有的差别，基本都是从这里派生出来的。

精度和内存占用

因为内存形态不同，两边选择的量化精度也不同，这点在对比速度时要注意。

halogen 文档里报了整体 5.53 bpw（按 checkpoint 的 tensor 表算出来的）。新版 checkpoint 一个文件 62.1 GiB，平均每个权重 4.16 bit：专家和主体 4 bit，中间那些混合层 6 bit，模型自带的 MTP 草稿头（multi-token prediction，多 token 预测，也就是投机解码里负责"猜"下一个词的那个模块，不是单独的草稿模型）的稠密投影 8 bit；n-gram 表单独一个 FP8 文件 47.7 GiB，是分页读的，不常驻。它特意说明 4bit 不是"优化"而是"能装下的前提"，并且把每个 tensor 家族用了多少位写进了文档，方便用算术核对。旧版 w4b 更占地方，基础文件 115.55 GiB 再加一个 2.31 GiB 的精度 sidecar。

Strata 按量化档位分：Q2_0 大约占 37.6G（内存加显存），IQ2_XS 约 39.2G，IQ3_XXS 约 47G，IQ3_S 约 54.8G。Coder 版砍掉一半专家，分片只有 29.6G，32G 内存的机器就能跑。还有一个实验性的 Unsloth UD-Q4_K_XL，111G，专家读不动就靠 SSD。可以看到 Strata 的专家量化压得比 halogen 低，因为它要在 12G 显存加 64G 内存这个更紧的预算里放下同一套权重。

性能对比

两边的机器、量化、上下文条件都不一样，数字不能直接相等地比，但放在一起能看出各自的位置。

Strata 公布的是 RTX 5070（12G）、Ryzen 5 7600、64G 内存上的结果：

档位	短对话输出	128K 上下文输出
Q2_0	93 tok/s	74 tok/s
IQ2_XS	79 tok/s	63 tok/s
IQ3_XXS	62 tok/s	49 tok/s
IQ3_S	53 tok/s	46 tok/s
Coder	55 tok/s	43 tok/s

读提示词的速度按它给的数字，32K 的提示约 15 秒，换算下来 2000 多 tok/s；3090（24G）估计能到 100 到 140 tok/s。也就是说，"60+ tokens/s"对应的是它快档的短对话场景。

halogen 公布的是 Ryzen AI Max+ 395、128G 统一内存、ROCm 7.14、大约 85W 持续功耗上的结果：

项目	halogen-flash
prefill 8192 tokens	1584 tok/s
prefill 32768 tokens	1567 tok/s
prefill 131072 tokens	1517 tok/s
decode 串行贪心，1.5K / 32K 上下文	37.6 / 34.1 tok/s
decode 带 MTP 投机，散文 / 代码	44.8 / 49.9 tok/s
decode 带草稿，服务端 32K（十个提示的均值）	46.0 tok/s
编程 agent 回合，草稿加 prompt lookup	55.7 到 56.3 tok/s

它有一个特点：prefill 随上下文衰减很小，131072 tokens 还有 32768 的 97%。decode 随深度也稳，从 1.5K 到 32K 只降了约 7%。另外它说 100000 tokens 的多轮对话，第一轮约 88 秒，之后每轮约 2 秒，靠的是默认开的 prompt cache。

把两张表放一起看，方向是清楚的：Strata 用更小、更便宜的显卡拿到了更高的 decode 峰值，代价是更低的量化精度和更吃内存/SSD 的分层搬运；halogen 用统一内存换来了整体更高的精度和更平稳的长上下文表现，峰值 decode 反而略低，而且这台机器的功耗和价格都明显更高。

两边相同的地方

虽然硬件路线差很多，有几件事两边都做了，而且思路接近。

都用投机解码，而且都用两个草稿来源：模型自带的 MTP 草稿头，加上从请求自身文本里找重复片段的 prompt lookup。Strata 文档里叫 prompt lookup，halogen 也一样，编程场景里大约一半的生成 token 是这种"抄前面出现过的话"。两边都强调：草稿只负责猜，真正输出的每个 token 都由完整模型验证，所以 temperature 为 0 时结果和串行贪心逐字节一致，投机只是加速，不牺牲质量。

都默认或强烈依赖前缀缓存。halogen 的 prompt cache 默认开，多轮对话只读新增部分。Strata 也维护会话和检查点缓存，新对话若共享同一段系统提示，就从那段之后开始读。

都提供 OpenAI 兼容的接口，halogen 还提供 Anthropic Messages 接口给 Claude Code 用，Strata 同样两个都给。两边都有 thinking 档位，都能接 agent 类客户端。

还都用同一个模型的 n-gram/PLE 表，当然了，因为用的都是同一个 qwen3.8-flash-next。

两边不同的地方

第一是开放性。Strata 是 MIT 协议，引擎源码公开，可以自己编译、改、看实现。halogen 的引擎是闭源的，以编译好的二进制放进容器镜像发布，仓库里只有部署说明、文档和基准工具，项目自己也写明引擎源码不在仓库里。

不过 halogen 的授权并不苛刻。它的 LICENSE.md 是一份最终用户许可（EULA），标注版权所有，但给出的权利很宽：免费使用、允许商用和量产、允许把未修改的镜像原样再分发（包括镜像到自己的 registry）、明确允许跑基准并公布结果，也明确不禁止逆向工程，没有遥测、默认不联外网。唯一实质限制是不能把修改过的版本当作 halogen 分发。所以它是闭源、不给源码，但不是不能用。仓库之所以说不接受 pull request，是因为补丁进不到那个闭源引擎里。

第二是部署门槛。Strata 是在自己机器上装好、下模型、直接跑，Windows 和 Linux 都行。halogen 是一台 AMD Strix Halo 上跑容器，文档对主机有明确要求：内核要有 gfx1151 的修复、要开 SVM、原生 Linux（不支持 WSL2）、还要独占整机；甚至 IOMMU 关闭与否都会影响 prefill，文档说关了在参考机上值 13 到 16%。

第三是并发。Strata 文档里写的是同一时间处理一个请求。halogen 有一个 KV 池和多个 slot，默认支持几个会话轮流生成，槽位数在启动时固定（最多 64，但文档说超过四个流的吞吐增长很慢），批量请求和单请求输出一致。

第四是 NPU。AI Max+ 395 带 NPU，halogen 可以把小模型（一个 0.8B 分类器、0.6B 的 embedding、0.6B 的 rerank）放在 NPU 上，和主模型共用一个端口。Strata 没有这个能力。

第五是可移植性和量化自由度。Strata 支持多代 NVIDIA 卡，还有若干 AMD 卡（RDNA2/3/4）的 HIP 后端，量化档位多，能按自己的显存挑。halogen 只能用 AI Max+ 395 的 gfx1151 这一颗，精度也是固定的几套 checkpoint。

各自适合谁

如果你手上已经有一张 12G 或 24G 的 NVIDIA 卡，配 64G 内存，想在这个预算里把模型跑快一点，Strata 是对路的选择，而且能自己编译、自己调量化。它的代价是量化压得低、长上下文和内存/SSD 搬运更吃资源，项目文档也坦白长上下文和质量这块还有没验证的部分。

如果你有一台 Strix Halo（AI Max+ 395、128G 统一内存）并且可以独占它做本地模型服务，halogen 是更省心的方案：精度更高、长上下文更稳、部署就是一条容器命令，还顺带能用 NPU 跑小模型。它的代价是绑死在这一颗芯片上、引擎闭源、而且这台机器基本得专门给它用。

全面对比

把前面提到的各个维度放到一张表里：

对比项	halogen	Strata
定位	单芯片、单模型家族的专用引擎	通用推理引擎，支持多种模型变体
目标硬件	AMD Strix Halo（AI Max+ 395，gfx1151），128G 统一内存	NVIDIA RTX 20–50 系（12–24G 显存）+ 64G 内存；另有实验性 AMD HIP 后端（RDNA2/3/4 离散卡）
系统与部署	原生 Linux + 容器镜像；要求特定内核（gfx1151 修复、SVM），不支持 WSL2	Windows / Linux；本地安装或自行编译
发布精度	整体 5.53 bpw；checkpoint 4.16 bpw（专家与主体 4bit、混合层 6bit、MTP 头 8bit）	多档量化：Q2_0 / IQ2_XS / IQ3_XXS / IQ3_S，另有 Coder、Swift 1.5、Unsloth 4bit
权重内存占用	62.1 GiB 常驻；n-gram 表 47.7 GiB 磁盘分页	37.6–54.8 GiB（内存+显存）；Coder 29.6 GiB
专家处理	全部常驻统一内存，不搬专家	三层：显存专家缓存 / 内存全部专家（CPU 算未命中）/ SSD n-gram 表
预填充速度	1517–1584 tok/s，随深度几乎不衰减	约 2171 tok/s（Q2_0，32K 提示）
单流解码速度	串行 37.6 / MTP 46.0 / 编程 agent 56.3 tok/s	53–93 tok/s（按量化档）
投机解码	MTP 头 + prompt lookup	MTP 层 + prompt lookup（在线性价比策略）
前缀缓存	默认开，续聊只处理新增	会话 + 检查点缓存
并发	KV 池 + 多 slot，默认几个会话轮流生成	一次处理一个请求
图片（视觉）	支持（编码器可跑 GPU/CPU）	支持（可选 vision；AMD 后端目前仅 CPU）
NPU	可把分类/embedding/rerank 小模型放 NPU	无
API	OpenAI + Anthropic + Responses	OpenAI + Anthropic
开源	引擎闭源（EULA：免费用、可商用、可原样再分发，不禁止逆向）	MIT 开源
可移植性	仅 gfx1151 一颗	多代 NVIDIA + 离散 AMD
可复现性	temp 0 与串行贪心逐字节一致；批量与单请求一致	temp 0 投机可复现（需关闭自适应层）
适合场景	有 Strix Halo 且能独占做本地服务	有小显存 N 卡 + 大内存，想省钱、可自定制

可视化对比

雷达图把八个维度放在一起看：解码速度、预填充速度、模型精度、长上下文稳定性、硬件可及性、开源开放度、并发/多会话、附加能力（NPU 等）。其中速度两项按各自文档的实测值归一化，其余是按文档整理的定性评分，只用于对照，不是统一标准下的跑分。同一张图也导出了高清 PNG：images/qwen38-radar.png。

参考文献

模型：Qwen3.8-Flash-Next（阿里 Qwen 团队）https://modelscope.cn/models/Qwen/Qwen3.8-Flash-Next
halogen-flash-server（Peonist）https://github.com/peonist-ai/halogen-flash-server
Strata（Niko1221）https://github.com/Niko1221/Strata

本地跑大模型：各种参数和速度到底该怎么看

2026-10-01T00:00:00+08:00

本地跑大模型：各种参数和速度到底该怎么看

经常有人问，我这台机器能不能跑某个模型。回答到最后往往会变成一个数字：每秒多少 token。可这个数字得看是哪个阶段的速度。同一台机器、同一个模型，你把一整段文档灌进去的时候，它能到两百多 token/s；等它一个字一个字往下写，就只剩十几 token/s 了。差了十几倍。这不是机器抽风，是这两件事根本不是一个活儿。

我在写优化器那篇的时候说过，公式看不明白不要紧，脑子里大概知道这个过程是怎么回事，心里就有底了。这篇也差不多，不推公式，就顺着一次生成的流水线从头走一遍，说清楚每一段在干什么，哪一段决定你要等多久，哪一段决定它写多快，以及本地这些硬件到底卡在哪。

一次生成都经历了什么

按了回车之后，机器干的活大概是这么一串：

你的输入先被切成 token，查成向量（embedding），然后送进一层层的 Transformer[1]。每一层里面主要是两件事：注意力（attention）和前馈网络（feed-forward network，FFN），现在不少模型会把 FFN 换成混合专家（mixture of experts，MoE）[2]。跑完最后一层，拿最后一个位置的输出送进 lm_head，得到一个在词表上的分数向量，也就是 logits。采样器从 logits 里挑出一个 token，如果开了流式，就先把这一个字吐给你看。然后把这个 token 接回输入，回到刚才那一层层里接着算，直到遇到结束符，或者撞上长度上限。

这里有一个关键的分界。第一次进入那些层的时候，喂进去的是你整段提示词，几百上千个 token 一起铺开算，这一步叫 prefill，预填充。从第二次开始，每一轮只喂一个新 token 进去，这一步叫 decode，解码。除了这两个名字，剩下的东西都是围着它们转的。

Prefill：把提示词一次性读完

prefill 最大的特点是并行。你那一段话里的所有 token 是一起进去的，模型对它们做的是矩阵乘矩阵那种运算，行话叫通用矩阵乘（general matrix multiplication，GEMM）。GPU（graphics processing unit，图形处理器）最喜欢这种活，因为一大块算力可以被完全填满。衡量这件事有个指标叫算术强度，也就是每读一个字节的数据能干多少次浮点运算。GEMM 的算术强度高，所以 prefill 通常是计算受限的，瓶颈在算力上[3-4]。

prefill 决定的是第一个字什么时候出来，也就是首 token 延迟（time to first token，TTFT）。这也是本地跑长文档问答时最难受的地方：你贴进去一篇几万字的材料，它不是慢慢来，而是先一动不动，等把整篇读完才开口。

还有一处成本容易被忽略。注意力要算所有 token 两两之间的关系，这部分大致是序列长度的平方。序列长度翻一倍，注意力那部分的工作量差不多翻四倍。所以提示词越长，prefill 的成本涨得比线性还快。

针对 prefill 最出名的优化是 FlashAttention[5]。它的做法是把注意力切成小块，在芯片上的高速存储里算完就丢，不把整张 n×n 的分数矩阵写回显存。结果是显存占得少了，速度还快了，因为少了一大堆来回搬数据的动作。FlashAttention-2[6] 又改了并行和工作划分，把 GPU 的利用率进一步拉高。这两篇值得一读，它们也顺便说明了，很多性能问题不是算得慢，是数据搬得多。

Decode：一次只往前走一个字

decode 的最大特点是串行，这一轮必须等上一轮出结果才能开始。更要命的是，每生成一个 token，都得把整个模型的权重从显存里读一遍，做一次乘加。

这就导致 decode 的算术强度极低：每读一个字节，可能就做一两次运算。于是瓶颈从算力换到了显存带宽，decode 是访存受限的[3,7-8]。

拿数字感受一下。一个 7B（7 billion，70 亿参数）的 fp16（16 位半精度浮点数）模型，权重是 14GB（gigabyte，吉字节）。如果显卡的显存带宽是 900GB/s，那么理论上限是 900 除以 14，大约每秒 64 个 token。按经验，实际能跑到六成就算不错了[9]。这个算法也能解释一个反直觉的现象：把权重从 fp16 压到 4bit[10-11]，字节数变成大约四分之一，同一个卡上 decode 理论上能快四倍左右，代价是质量可能掉一点。所以本地跑模型，显存带宽比商家广告上的 FLOPS（floating-point operations per second，每秒浮点运算次数）更值得看。算力再高，数据读不进来也是干等着，这就是当年说的内存墙[12]。

还有个地方容易搞混：服务器上之所以能同时服务很多人，靠的是批处理。一次读进来的权重，可以同时给一批请求里的每个 token 用[13-15]，算术强度上去了，吞吐也跟着上去，但单条请求的延迟会被拉长。本地一个人用，批大小基本就是 1，你永远待在访存受限的那一头。

键值缓存（key-value cache，KV cache）：本地跑长上下文的真正成本

模型在算当前 token 的时候，要用到之前所有 token 的键值对（key 和 value，写作 K 和 V）。每算一步就重算一遍前面所有位置是不现实的，所以要把它们存下来，这就是键值缓存（key-value cache，KV cache）[16]。

它的大小可以这么估：2（K 和 V 两份，也就是 key 和 value）乘以层数，乘以 KV 的头数，乘以每个头的维度，乘以每个元素占的字节数，再乘以上下文长度。如果同时跑多条请求，还要再乘一个批大小。

拿一个 7B、32 层、32 个头、每头 128 维、fp16 的模型算，每个 token 的 KV 是 2 乘 32 乘 32 乘 128 乘 2 字节，等于 512KB（kilobyte，千字节）。跑到 32K（即 32768）上下文，光 KV 就是 16GB，比 4bit 的权重还大。这就是为什么上下文一拉长就爆显存，跟参数多少没关系，是这段算术决定的。

围绕这几十个 G，大家都在想办法：

分组查询注意力（grouped-query attention，GQA）和多查询注意力（multi-query attention，MQA）是让多个 query 头共享同一组 KV 头，直接把公式里的「KV 头数」降下来[17-18]。现在开源模型基本都用 GQA，更激进的是多头潜在注意力（multi-head latent attention，MLA）[19]，比如 DeepSeek-V2 那样，把 K 和 V 压成一个潜在向量，缓存里存的是压缩后的东西。

PagedAttention 是另一条路。它像操作系统的虚拟内存分页那样管理 KV，按块分配、按需映射。vLLM 就是靠这个把显存碎片压到很低，从而塞下更多并发请求[20-21]。

再狠一点就是量化或者丢弃。KIVI[22] 把 KV 压到 2bit；H2O（Heavy-Hitter Oracle）[23]、StreamingLLM[24] 这类干脆只保留一部分 token 的 KV，靠注意力汇聚点的现象撑住。这些都会牺牲一部分质量，属于拿精度换显存和带宽。

还有一层影响是隐性的：上下文越长，decode 本身也会越来越慢。因为每步要读的 KV 变多了，注意力那部分开销从「可以忽略」变成「不能忽略」[25]。下面我自己的实测里就能看到这个趋势。

采样：最后挑字那一步

logits 出来之后，一般不会直接取分数最高的那个（那叫贪心解码），而是先做一串处理：temperature 缩放、top-k、top-p（也就是 nucleus 采样）、min-p[26]、重复惩罚，最后按概率抽一个。

这些名字听着乱，其实是在回答两个问题：要不要稳，要不要新。温度低就稳，容易复读；温度高就活，也容易跑偏。Holtzman 那篇 The Curious Case of Neural Text Degeneration 讲的就是为什么纯贪心和纯 top-k 都会退化，以及 nucleus 采样是怎么缓解的[27]。现在到处都能看到的 repetition_penalty，最早来自 CTRL（Conditional Transformer Language Model）那篇[28]。

采样本身几乎不耗时，但它直接决定了体验。同一段提示词，参数调得不一样，出来的是两个脾气完全不同的助手。

还有一类东西也发生在这一步：结构化输出。你让它必须按某个 JSON（JavaScript Object Notation，一种数据交换格式）格式或者某种语法生成，引擎就在解码时把那些不合法的 token 直接屏蔽掉。XGrammar 这类引擎把语法编译成下推自动机的形式，把每个 token 上的额外开销压得很小[29]。代价是解码的并行度受一点影响，换来的是确定性和不用事后擦屁股。

几个指标别看错

TTFT，首 token 延迟，主要看 prefill。流式对话、文档问答里，这个数字最影响「手感」。

TPOT（time per output token）或者 ITL（inter-token latency），也就是相邻两个 token 的间隔，看 decode。人眼阅读大概每秒十到二十个 token 就比较舒服，低于这个数就会明显感觉一顿一顿的。

吞吐，整台机器每秒产出多少 token，只有在批处理、多用户场景里才有意义。

goodput，是在满足延迟要求的前提下能服务多少请求。服务器上的目标往往是这个，而不是单纯的吞吐，因为把延迟拖坏了，吞吐再高也没用。DistServe 那篇[30]就是专攻这个指标的。

顺便说一句，评价这套东西，业界已经有相对标准的方法了，比如 MLPerf（Machine Learning Performance）Inference，它把 TTFT 和 TPOT 这类指标明确写进了生成式模型的测量里[31]。自己在家测的时候，至少也要说清楚是哪个阶段的数字，不然很容易拿苹果比梨。

各种优化分别作用在哪一段

把常见的招数按环节摆一下[8,32]，会清楚很多：

手段	作用环节	主要改善	代价
连续批处理，Orca 那套迭代级调度[13-15]	调度	吞吐	单条延迟升高
chunked prefill，把长提示词切段[33]	prefill 与 decode 混跑	长短请求混在一起时的稳定性和吞吐	实现复杂
前后分离，DistServe / Splitwise[30,34-35]	调度	goodput、各自用合适的资源	要更多机器或显存
前缀缓存，SGLang 的 RadixAttention、vLLM 的自动前缀缓存[36-37]	prefill	TTFT	拿显存换
FlashAttention[5-6,25]	注意力	显存与速度	要有对应 kernel
GQA[18]、MQA[17]、MLA[19]	KV 与 decode	显存、带宽	模型结构决定，改不了
PagedAttention[20-21]	KV 管理	并发数	调度复杂
量化，权重或 KV[10,38-41]	权重与 KV	显存、带宽	质量下降
投机解码[42-46]	decode	速度	草稿模型占资源，接受率有限
MoE[2,47]	计算	每个 token 激活的参数少	显存总量和路由抖动
offload 到内存或硬盘[48-51]	显存不够时的兜底	能跑起来	decode 慢一个数量级
张量并行[52]	显存与计算	能跑更大的模型	卡间互联带宽

其中 chunked prefill 值得单独说一句。它不是减少 prefill 的总工作量，而是把一大段 prefill 拆成几小段，跟正在解码的请求交替着算。这样长提示词不会把别人的 decode 卡住，整体的 TTFT 分布也平滑得多。SARATHI[33] 就是干这个的。

投机解码也值得说。它的思路是先用一个小的草稿模型（或者模型自带的小头）一次猜好几个 token，再让主模型一次并行验证，猜对的照单全收，猜错的退回。注意它不改变最终输出的分布，是精确加速，不是玄学[42-43]。代价是要额外养一个草稿模型，而且提速倍率被接受率卡着，接受率低就白忙。Medusa[44] 和 EAGLE[45] 就是在这条路上换了几种实现。对本地这种访存受限的场景，投机解码往往比堆算力更有效，因为它把「一次读权重只算一个 token」变成了「一次读权重算好几个 token」。

本地机器的三个硬约束

说回本地，绕来绕去就是三样东西：

显存容量，决定你能不能装下权重、上下文能开多大、能并发几个请求。

显存带宽，决定 decode 有多快。这是本地体验里最要紧的一条，因为权重每个 token 都要读一遍。

算力，决定 prefill 有多快，也决定批处理时的吞吐上限。

三样都想要，往往只能选两样。模型大一点，容量先告急；上下文长一点，KV 先告急；量化到极限，容量和速度都好了，质量开始告急。

显存不够的时候，就只能 offload，把一部分层、专家或者 KV 放到内存甚至硬盘上。FlexGen[48] 是这套思路里比较有代表性的，它明确是拿吞吐换延迟、为了离线批处理设计的。PowerInfer[49] 利用激活的局部性，把经常被用到的神经元留在 GPU 上，热的算 GPU、冷的算 CPU（central processing unit，中央处理器）。LLM in a flash[50] 更直接，从闪存里流式读权重。这些方案[48-51]都能让你把原本跑不动的模型跑起来，但共同点是 decode 会掉到另一个数量级，而且速度被内存带宽、PCIe 带宽或者硬盘速度按着。顺便一提，普通内存的带宽往往只有显卡显存的几分之一到十几分之一，这个落差是补不回来的。

多卡是另一条路。Megatron-LM 那套张量并行[52]把权重切开放在几张卡上，但每一层、每一轮都要卡间通信。消费级卡大多没有 NVLink，只能走 PCIe（Peripheral Component Interconnect Express，一种高速外设互连标准），decode 本来就是访存受限，再叠上通信，两张卡不一定等于一张快一倍的卡。

最后还有两个容易被忘掉的环节。一个是冷启动，第一次跑模型要把几个 G 的权重从磁盘读进显存，这段时间也是用户实实在在在等的。另一个是散热，笔记本上连续生成，前几分钟和后十几分钟经常不是一个速度。

我在这台 M4/16G 上测了一组数

光说原理没意思，我在手头的机器上量了一组。机器是 Apple M4、16GB 统一内存，模型是 qwen3.5:2b（ollama 0.35.0）[53]，ollama ps 里显示 2.5GB、百分之百在 GPU 上。温度设成 0，上下文窗口 8192，每次请求固定生成大约 200 个 token。

提示词 token 数	prefill	decode
736	262.5 token/s	17.7 token/s
3720	184.8 token/s	14.5 token/s
7377	185.8 token/s	12.5 token/s

另外测了一次流式输出：3716 个 token 的提示词，TTFT 是 20.3 秒，对应的 prefill 速度是 185.6 token/s。

这几个数字能对上前面讲的东西。decode 只有 prefill 的十分之一上下，这就是访存受限和计算受限的差别。上下文从七百多涨到七千多，decode 从 17.7 掉到 12.5，这是每步要多读 KV 的代价。至于那个 20 秒的 TTFT，就是本地跑长文档问答难受的根源——不是模型不行，是它得先把整篇读完。

这里必须补一句，免得误导。上表都是单次测量，同一台机器在不同时刻会飘，散热、后台负载都会影响。而且我测的过程中撞上过一个现象：同一个前缀重复请求时，prefill 会「消失」，我见过 3812 个 token 只花 0.12 秒的情况，那是前缀缓存命中了。这事对 agent 场景反而是好消息：反复带着同一段系统提示词去调用，第二次几乎不用再花 prefill 的钱。

那到底该看什么

如果只是聊天、写东西，decode 速率最要紧，每秒十几到二十个 token 人就能接受。这种场景下，选一个小一点、别压到极限的模型，往往比选个大模型再量化到 2bit 舒服。

如果是长文档问答、代码库问答，那 prefill 和 KV 才是重点。先看显存够不够放下那么长的 KV，再看那几十秒的 TTFT 你能不能忍。另外也得记住，上下文塞得越长，模型对中间内容的使用往往越差[54]。

如果是多用户，或者要拿它当服务跑，就得看吞吐和 goodput，考虑连续批处理和前后分离那一套。

如果是 agent 那种反复调用、上下文高度重复的用法，前缀缓存能救命[36-37]。

说到底，本地跑模型不是一道「能不能跑」的是非题，而是「哪一段慢、你受不受得了」的取舍题。prefill、decode和KV都要关注，重要的是要根据场景来具体衡量。

参考文献

Transformer 原始架构：Vaswani, A. et al. "Attention Is All You Need." NeurIPS（Neural Information Processing Systems）2017. arXiv:1706.03762. https://arxiv.org/abs/1706.03762
MoE（mixture of experts）：Fedus, W., Zoph, B., Shazeer, N. "Switch Transformers: Scaling to Trillion Parameter Models with Simple and Efficient Sparsity." JMLR（Journal of Machine Learning Research）2022. arXiv:2101.03961. https://arxiv.org/abs/2101.03961
prefill 与 decode 的算力/带宽分析：Pope, R. et al. "Efficiently Scaling Transformer Inference." MLSys（Conference on Machine Learning and Systems）2023. arXiv:2211.05102. https://arxiv.org/abs/2211.05102
算术强度与屋顶线模型：Williams, S., Waterman, A., Patterson, D. "Roofline: An Insightful Visual Performance Model for Multicore Architectures." Communications of the ACM（Association for Computing Machinery）, 52(4):65–76, 2009. DOI（Digital Object Identifier）: 10.1145/1498765.1498785
FlashAttention：Dao, T. et al. "FlashAttention: Fast and Memory-Efficient Exact Attention with IO-Awareness." NeurIPS 2022. arXiv:2205.14135. https://arxiv.org/abs/2205.14135
FlashAttention-2：Dao, T. "FlashAttention-2: Faster Attention with Better Parallelism and Work Partitioning." arXiv:2307.08691. https://arxiv.org/abs/2307.08691
LLM（large language model）推理的屋顶线综述：Yuan, Z. et al. "LLM Inference Unveiled: Survey and Roofline Model Insights." arXiv:2402.16363. https://arxiv.org/abs/2402.16363
高效推理综述：Zhou, Z. et al. "A Survey on Efficient Inference for Large Language Models." arXiv:2404.14294. https://arxiv.org/abs/2404.14294
推理性能调优实务：Databricks. "LLM Inference Performance Engineering: Best Practices." https://www.databricks.com/blog/llm-inference-performance-engineering-best-practices
GGUF（GPT-Generated Unified Format）量化格式：ggml 项目文档, "GGUF." https://raw.githubusercontent.com/ggml-org/ggml/master/docs/gguf.md
llama.cpp：https://github.com/ggml-org/llama.cpp
内存墙：Wulf, W. A., McKee, S. A. "Hitting the Memory Wall: Implications of the Obvious." ACM SIGARCH（Special Interest Group on Computer Architecture）Computer Architecture News, 23(1):20–24, 1995. DOI: 10.1145/216585.216588
连续批处理（迭代级调度）：Yu, G.-I. et al. "Orca: A Distributed Serving System for Transformer-Based Generative Models." OSDI（Operating Systems Design and Implementation）2022. https://www.usenix.org/system/files/osdi22-yu.pdf
连续批处理的科普说明：Anyscale. "Achieve 23x LLM Inference Throughput & Reduce p50 Latency"（continuous batching 那一篇）. https://www.anyscale.com/blog/continuous-batching-llm-inference
TensorRT-LLM（Tensor Runtime for Large Language Model，含 in-flight batching 与 kernel 实现）：https://github.com/NVIDIA/TensorRT-LLM
KV（key-value）cache 的工程说明：Hugging Face Transformers Documentation, "KV cache." https://huggingface.co/docs/transformers/en/kv_cache
MQA（multi-query attention）：Shazeer, N. "Fast Transformer Decoding: One Write-Head is All You Need." arXiv:1911.02150. https://arxiv.org/abs/1911.02150
GQA（grouped-query attention）：Ainslie, J. et al. "GQA: Training Generalized Multi-Query Transformer Models from Multi-Head Checkpoints." EMNLP（Conference on Empirical Methods in Natural Language Processing）2023. arXiv:2305.13245. https://arxiv.org/abs/2305.13245
MLA（multi-head latent attention）与 KV（key-value）压缩：DeepSeek-AI. "DeepSeek-V2: A Strong, Economical, and Efficient Mixture-of-Experts Language Model." arXiv:2405.04434. https://arxiv.org/abs/2405.04434
PagedAttention 与 vLLM：Kwon, W. et al. "Efficient Memory Management for Large Language Model Serving with PagedAttention." SOSP（Symposium on Operating Systems Principles）2023. arXiv:2309.06180. https://arxiv.org/abs/2309.06180
vLLM 的分页注意力实现说明：vLLM Documentation, "Paged Attention." https://docs.vllm.ai/en/latest/design/paged_attention/
KV（key-value）量化：Liu, Z. et al. "KIVI: A Tuning-Free Asymmetric 2bit Quantization for KV Cache." ICML 2024. arXiv:2402.02750. https://arxiv.org/abs/2402.02750
KV（key-value）淘汰（H2O，Heavy-Hitter Oracle）：Zhang, Z. et al. "H2O: Heavy-Hitter Oracle for Efficient Generative Inference of Large Language Models." NeurIPS 2023. arXiv:2306.14048. https://arxiv.org/abs/2306.14048
注意力汇聚与 StreamingLLM：Xiao, G. et al. "Efficient Streaming Language Models with Attention Sinks." ICLR 2024. arXiv:2309.17453. https://arxiv.org/abs/2309.17453
Flash-Decoding：Dao, T. et al. "Flash-Decoding for Long-Context Inference." PyTorch Blog, 2023. https://pytorch.org/blog/flash-decoding/
min-p 采样：Nguyen, M. N. et al. "Turning Up the Heat: Min-p Sampling for Creative and Coherent LLM Outputs." ICLR 2025. arXiv:2407.01082. https://arxiv.org/abs/2407.01082
核采样：Holtzman, A. et al. "The Curious Case of Neural Text Degeneration." ICLR 2020. arXiv:1904.09751. https://arxiv.org/abs/1904.09751
重复惩罚的来源：Keskar, N. S. et al. "CTRL: A Conditional Transformer Language Model for Controllable Generation." arXiv:1909.05858. https://arxiv.org/abs/1909.05858
结构化输出（XGrammar）：Dong, Y. et al. "XGrammar: Flexible and Efficient Structured Generation Engine for Large Language Models." arXiv:2411.15100. https://arxiv.org/abs/2411.15100
以 goodput 为目标的分离式服务：Zhong, Y. et al. "DistServe: Disaggregating Prefill and Decoding for Goodput-optimized Large Language Model Serving." OSDI 2024. arXiv:2401.09670. https://arxiv.org/abs/2401.09670
推理基准测试方法：MLCommons. MLPerf（Machine Learning Performance）Inference. https://mlcommons.org/benchmarks/inference-datacenter/
推理优化技术综述（NVIDIA）：NVIDIA. "Mastering LLM Techniques: Inference Optimization." https://developer.nvidia.com/blog/mastering-llm-techniques-inference-optimization/
chunked prefill：Agrawal, A. et al. "SARATHI: Efficient LLM Inference by Piggybacking Decodes with Chunked Prefills." arXiv:2308.16369. https://arxiv.org/abs/2308.16369
前后分离：Patel, P. et al. "Splitwise: Efficient Generative LLM Inference Using Phase Splitting." ISCA（International Symposium on Computer Architecture）2024. arXiv:2311.18677. https://arxiv.org/abs/2311.18677
vLLM 的分离式预填充：vLLM Documentation, "Disaggregated Prefill." https://docs.vllm.ai/en/latest/features/disagg_prefill/
前缀缓存与 RadixAttention：Zheng, L. et al. "SGLang: Efficient Execution of Structured Language Model Programs." NeurIPS 2024. arXiv:2312.07104. https://arxiv.org/abs/2312.07104
vLLM 的自动前缀缓存：vLLM Documentation, "Automatic Prefix Caching." https://docs.vllm.ai/en/latest/features/automatic_prefix_caching/
GPTQ：Frantar, E. et al. "GPTQ: Accurate Post-Training Quantization for Generative Pre-trained Transformers." ICLR（International Conference on Learning Representations）2023. arXiv:2210.17323. https://arxiv.org/abs/2210.17323
AWQ：Lin, J. et al. "AWQ: Activation-aware Weight Quantization for LLM Compression and Acceleration." MLSys 2024. arXiv:2306.00978. https://arxiv.org/abs/2306.00978
LLM（large language model）.int8()：Dettmers, T. et al. "LLM.int8(): 8-bit Matrix Multiplication for Transformers at Scale." NeurIPS 2022. arXiv:2208.07339. https://arxiv.org/abs/2208.07339
SmoothQuant：Xiao, G. et al. "SmoothQuant: Accurate and Efficient Post-Training Quantization for Large Language Models." ICML 2023. arXiv:2211.10438. https://arxiv.org/abs/2211.10438
投机解码：Leviathan, Y., Kalman, M., Matias, Y. "Fast Inference from Transformers via Speculative Decoding." ICML（International Conference on Machine Learning）2023. arXiv:2211.17192. https://arxiv.org/abs/2211.17192
投机采样：Chen, C. et al. "Accelerating Large Language Model Decoding with Speculative Sampling." arXiv:2302.01318. https://arxiv.org/abs/2302.01318
Medusa：Cai, T. et al. "Medusa: Simple LLM Inference Acceleration Framework with Multiple Decoding Heads." ICML 2024. arXiv:2401.10774. https://arxiv.org/abs/2401.10774
EAGLE：Li, Y. et al. "EAGLE: Speculative Sampling Requires Rethinking Feature Uncertainty." ICML 2024. arXiv:2401.15077. https://arxiv.org/abs/2401.15077
vLLM 的投机解码：vLLM Documentation, "Speculative Decoding." https://docs.vllm.ai/en/latest/features/speculative_decoding/
Mixtral：Jiang, A. Q. et al. "Mixtral of Experts." arXiv:2401.04088. https://arxiv.org/abs/2401.04088
单卡 offload 的吞吐型方案（FlexGen）：Sheng, Y. et al. "FlexGen: High-Throughput Generative Inference of Large Language Models with a Single GPU." ICML 2023. arXiv:2303.06865. https://arxiv.org/abs/2303.06865
激活局部性与 CPU（central processing unit）/GPU（graphics processing unit）协作（PowerInfer）：Song, Y. et al. "PowerInfer: Fast Large Language Model Serving with a Consumer-grade GPU." SOSP 2024. arXiv:2312.12456. https://arxiv.org/abs/2312.12456
从闪存流式推理（LLM in a flash）：Alizadeh, K. et al. "LLM in a Flash: Efficient Large Language Model Inference with Limited Memory." ACL（Association for Computational Linguistics）2024. arXiv:2312.11514. https://arxiv.org/abs/2312.11514
多卡推理与 offload：Aminabadi, R. Y. et al. "DeepSpeed Inference: Enabling Efficient Inference of Transformer Models at Unprecedented Scale." SC（Supercomputing Conference）2022. arXiv:2207.00032. https://arxiv.org/abs/2207.00032
张量并行：Shoeybi, M. et al. "Megatron-LM: Training Multi-Billion Parameter Language Models Using Model Parallelism." arXiv:1909.08053. https://arxiv.org/abs/1909.08053
Ollama（本地运行的默认参数与行为）：https://github.com/ollama/ollama
长上下文中的位置效应：Liu, N. F. et al. "Lost in the Middle: How Language Models Use Long Contexts." TACL（Transactions of the Association for Computational Linguistics）2024. arXiv:2307.03172. https://arxiv.org/abs/2307.03172

想让小孩不沉迷手机，大人自己得先做得到

2026-09-29T00:00:00+08:00

想让小孩不沉迷手机，大人自己得先做得到

我留意到，不少家长自己闲下来的时候，手里总是拿着部手机刷短视频。陪孩子的时候呢，参与得其实不算多，好像一时也拿不出什么别的给孩子玩儿，最后就让孩子也一起看手机。小朋友见惯了，可能就只觉得这一个东西是最好玩儿的了。

今天上午我跟二儿子玩的时候，其实也不能说是我在陪他玩，而是我在给我大儿子用乐高拼城墙和赛车，然后二儿子就在旁边拿点「边角料」之类的在那玩，相当于气氛组吧。他动不动就拿着一个拼好的车说「it is beautiful」之类的，然后拿一个小车去一边玩。中午大儿子跟着玩了一会，二儿子在旁边要捣乱，我就拿了一个他说 beautiful 的车，弄了个硬纸板，跟他跑到另一个屋子，摆了一个斜坡，教他把小车从坡顶上滚下来，他就开心得不得了。我问他「are you happy」，他就说 yes。

如果成年人自己的娱乐，也就是看看手机、刷刷短视频这一种，大概也会觉得陪孩子摆积木，或者拿纸壳板子搭个坡道，是件挺费事的事情。想让小朋友不去沉迷于小屏幕，或许大人得自己能做得到才行。

我们上一代人当年所喜欢的，大概是打麻将打牌，又或者抽烟喝酒等等。这些爱好，我们这代人多少也继承了一些，如今在十几岁的孩子身上，偶尔也能见到。前几天我爱人带我去看望她师傅师娘，师傅一听我不吸烟不喝酒不嚼槟榔还表示很赞赏，然后我说我非常爱打游戏，而且带着孩子一起玩赛车（其实我主要是老滚资深潜行双持，骑砍老牌弓骑兵，以及地平线和尘埃资深菜鸟级驾驶爱好者），老师傅脸上的表情，有一闪而过的尴尬。可能在他们那代人眼里，打游戏也许还是一个不太好的爱好。

我又想起来，在大概十多年前，曾经发生过一幕名场面，叫做《看你妹之网瘾战争》。如果以我如今每天上网的频率和时长来看，大概也会被当时的雷电法王羊较瘦记成「重度网瘾」，说不定还得被建议电一电。

记得大概是七年前在某院校遇到的一位同事，就曾经说他自己的家长将他的电脑硬盘全都砸碎了，认为他在家里「天天玩电脑是不务正业」，而他其实是从事艺术设计专业的，因此他的代表作的原稿、草稿等等都没能恢复。当时他已经接近四十岁了，好像本来是准备用这些未发表的原稿去申请罗德岛的博士后机会来着什么的来着，反正是付诸流水，而家里长辈大概一直觉得自己是对的。

现在大学生的家长群体大概都是我这一辈人了，或许不至于那么执拗了。不过上半年也听说有某所谓「报考机构」的「传承人」，与他自家祖师「建议大学生一定要有电脑」的遗训反着来，建议家长不要给大学新生准备电脑，还说手机也能剪辑视频。每一代人里，大概都会冒出几个让人意外的主张，这种事总归是有概率的。

我大儿子打游戏，大概也就是最开始沉迷 2048，然后借着这个机会教了他二进制和指数与对数的基础知识，他能够从 2 一直翻倍到 262144，后来更是能到 524288，乃至 1048576。而我带的很多大一新生，大概也就算到 65536 了。当然这没什么可炫耀的，只是足够有噱头，可以用来忽悠大一的小朋友们，给他们一点小小的压力。

后来我大儿子长大一些，主要玩的就是地平线 4 和地平线 5。地平线 6 刚出的时候，我们那台 RX580 显卡的机器跑不动，后来是用 SteamDeck 之后才买的，最近他就玩地平线 6 了。英国和日本靠左开车，墨西哥则是和咱们大陆地区一样右侧开车，然后一些底盘低的车在草地或者砂石路面会出现底盘剐蹭的情况，所以我大儿子也特别喜欢 SUV 或者更高底盘的硬派越野了。另外他还发现速度超过 150 在有些比较小半径的弯道就容易转向不足，而且他还发现路上有交通参与的时候车速太快容易和其他车辆磕碰，所以他现在日常赶路开车都控制车速在 120 以内，有的窄路甚至会降低到 80 以下，感觉完全成了一个老司机了。最开始他时不时地陷车了或者走错了还要让我帮忙开出来，后来他基本都能自己找到地方了。而且改装的时候，他开始主动控制车辆参数评级，就比如尽量不动发动机和变速箱，而只是改进其他部件，这样和同级别的车型比赛的时候就会有很大优势；而如果冒然升级到更高评级，反而可能跑不过人家了。有一辆 EVO 我给改成了 X 级了，他就很不满意。这类游戏里的这些体验，似乎都不是简单的「充值变强」，而是需要自己去试、去琢磨。

我觉得，能够反思可能是学习中最重要的事情了。如果从来不反思，也不知道自己错在哪里，那每次都可能是要么就寄希望于侥幸不要碰到自己不会的东西，要么就是下次重复上一次的错误，怎么可能有改进呢？

游戏大概也算不上什么洪水猛兽，说是事实上的第九艺术，也不算太离谱，如今还衍生出了专门的电子竞技。也许很多体育运动当年最开始的时候也就是一种游戏，逐渐地成了流行的项目，甚至也被冠以「为 XXXX 争光」之类的额外信息量，结果一旦输了，不少人跟着心里就过不去，甚至去责怪运动员。输不起的人，赢来的或许也未必守得住；只盯着输赢而不在意事情本身，大概也长久不了。

我一直不太能接受吸烟和饮酒，说到底，大概是我自己的偏执。我总觉得，光合作用和耕种的土壤都是有限的，拿来种植烟草，别的作物就要少一些；而烟草烧过之后，不过是让人摄入些焦油、尼古丁之类。酒精饮料又会牵出各种各样的社会问题，而酒精本身本来可以拿去做燃料、做化工原材料或者消毒，酿酒用的粮食，本来也有机会送到饥饿的人群手里。

反正越来越发觉，很多事情很多问题，咱们祖先确实是都发现了，正所谓「不患寡而患不均」。这个均，我倒不觉得一定要解读成机械的平均，甚至未必是物质资料上的平均，或许更可以指机会上的均等。

可是机会真的均等么？一涉及到价值判断，大概处处都是难题。一样的一所学校，有的地方要比其他地方高几十分甚至接近一百分，才能考入，自从洪武年间的「南北榜」以来，问题是否真的完全解决了呢？

我身上若干关节患有伤病，现代医疗技术只能避免相关位置的症状恶化，只要不恶化，对付着能走路，就还不至于太严重，也就对付了。那我是不是就知足了，是不是就不用去考虑其他的，也根本不抱着任何治愈的希望了呢？人类未必不能彻底治愈这类疾病，可投入到一种病上的精力，不见得能挪去研究别的病，于是大概总有些病，一时半会儿是攻不下来的。

想当年，有学外语的朋友跟我说，「存在即合理」这句话好像是当年一些走狗文人为了给当时的反动势力辩护而强行歪曲翻译的。我倒是觉得，那样的说法，可能还是尖锐了些。

给儿子买了一台 609 元的二手 MacBook Air

2026-09-27T10:00:00+08:00

我家大儿子今年开始对编程有点兴趣。作为父亲，我自然想给他弄个能写代码的工具。跟很多家长一样，我也有点纠结：买性能太强的吧，一是浪费钱，二是怕他沉迷游戏。我自己也玩游戏，不过平时也不完全禁止孩子玩，只是每次只让他玩 20 分钟，比如父子俩一起跑个赛车。这样能控制时间，不至于长时间盯着屏幕。他遗传了我的近视，而且也是眼睛容易累，这点我太清楚了。我自己眼睛就容易干、容易累，平时只能用直流调光的 LCD 屏，LED 屏完全没法看。所以给他选机器，屏幕也得考虑。

当然，最根本的原因还是穷。预算有限，只能省。最后我在二手平台上买了一台 MacBook Air 13 英寸（2017 年中款）。加上一个第三方的 PD 充电器转接，一共花了 609 块。其中机器 559，转接头 50。

说实话，609 块在电脑没涨价的年头，能买到配置比这高得多的二手笔记本。但后来想来想去，还是选了这台。一是噪音小，二是现在 macOS 最新版本只到 12.7，虽然老，但很多工具软件还能跑，尤其是编程用的那些，基本上都能用到最新版，给他用也还行。再一个，是在正规二手渠道买的，有一定质保，心里踏实点。还有一点，这种 Intel 处理器的 x86_64 平台的老 MacBook，除了用过时的 macOS 之外，还可以方便地安装 Linux 操作系统。哪天这种旧版本的 macOS 彻底跟不上新软件了，装个主流发行版照样能接着干活，所以也是个好处。

最近总有学生和家长问我，要不要买电脑、买什么电脑。我觉得现在的电脑价格跟以前不一样了。去年这会儿，最低可能只有五千多，最高顶多也就是七八千块，能买到 4060、5060 显卡加上7845、7945 处理器的机器。当时看着很一般，现在居然要一万多甚至快两万。这时候就没必要花那么多钱了，除非你真有需求。如果没有运行本地模型或机器学习的需求，一般场景，也不剪视频，不是那种专业用途，这种老机器也能对付。但我建议孩子最好还是别用这种东西。质保是个问题，系统环境旧，软件安装容易遇到各种坑，整体就很不推荐。不过有时候预算实在低，又需要一个轻薄长续航的笔记本，只做文本处理和简单的 Python 脚本，而且不用本地模型、用在线模型，配合 opencode、workbuddy 或者 pi agent 这类工具，那倒是可以考虑。

这台机器的配置大概是：i7-5650U 双核四线程，8GB 内存，128GB SSD，13.3 英寸 1440x900 屏幕，电池 54Wh，重 1.35kg。系统是 macOS Monterey 12.7.6。对于写代码来说，这个配置不算强，但跑轻量级的 Python、前端开发、写文档都够用。

下面我把这台机器上装的工具和版本都列一下，顺便查了查最新的版本，看看差多少。

工具	文档中记录版本	最新版本	是否最新
Visual Studio Code	1.139.1	1.139.1	✅
Google Chrome	150.0.7871.125	154.0.8037.57	❌
Firefox	156.0.1	156.0.1	✅
Node.js	v22.14.0 (LTS)	v24.21.0 (LTS)	❌
Git	2.37.1 (Apple Git-137.1)	2.55.0	❌
Python (系统)	3.7.3	3.14.7	❌
Python (conda base)	3.7.3	3.14.7	❌
Python (conda dev)	3.12.9	3.14.7	❌
OpenCode	v2.0.18	v1.18.32	beta版本
Pi Agent	0.87.1	0.87.1	✅
Conda	4.6.14	26.7.2	❌
微信	4.1.15	4.1.15	✅
WPS Office	12.1.29166	12.1.29166	✅
WorkBuddy	5.6.2	5.6.2	✅
UU远程	4.42.0	4.42.0	✅

说几个有意思的地方。

虽然这 macOS 12.7 已经很老了，可依然还是能安装很多最新版的软件，比如 VS Code、Firefox 、WPS 、微信、UU远程等等。Chrome 差了几个大版本，不过日常上网也感觉不出来。Node.js 的 LTS 已经从 22 升到 24 了，Git 也差得比较多，系统自带的 Python 3.7.3 更是老古董，conda 那个 4.6.14 也是老得不行。

比较关键的，可能还是 WorkBuddy 和 OpenCode，前者方便远程登录用手机操控本地应用和文件，而后者本身是个很好用的 AI 编程助手，这俩装上之后配合在线模型，写点小脚本、改改代码都很顺手，而且在这种老设备的老系统上，前者能安装最新版，后者的 beta 版本还能安装。

Pi Agent 的版本 0.87.1 跟最新一致，这个没问题，也是个很方便的 AI 编程助手了。

这台机器装的东西不多，够用就行。Python 用的是 conda 里的 dev 环境，3.12.9，虽然比最新的 3.14.7 旧，但跑一般脚本没问题。VS Code 是最新版，配上 Python 插件和 AI 辅助工具，给小孩入门编程足够了。浏览器主力是 Firefox，日常打开视频网站或者查资料足够了。

这回买二手老机器，图的就是便宜。但便宜有便宜的代价：系统老、软件装不上、电池可能不耐用、质保基本靠运气。如果预算实在紧，又只是给孩子学学 Python、写点简单代码，那这种几百块的机器确实能顶一阵子。但如果要重度使用计算机，不只是学学敲代码，还要做模型、写项目、跑本地模型、剪视频等等，那还是攒攒钱买台更高配置一点的。毕竟机会和时间都是更高成本的，折腾环境的时间多了，学习热情容易消磨掉，而且有的事情，配置低了就是做不了。

给我儿子买的这台二手机器，除了简单敲敲代码，也就是用来连接他的MIDI键盘以及声卡等等，新版本M4芯片的机器上我试了当年的MIDI键盘和旧声卡就无法识别了，还好用十来年前老机器能连接，这样给他玩Garageband也好哄他弟弟玩。我大儿子最近开始尝试听音记谱了，只不过还是有时候不太熟练不太准确，这回有了Garageband，或许他能玩得更开心一些。

BianQue（扁鹊）：一个纯 Python 的硬件验机工具，顺便给孩子们当 Python 案例

2026-09-26T15:30:00+08:00

我最近越来越懒，也越来越想把手里那些零零碎碎的工作流，尽量都用 Python 来实现。倒不是说 Python 有多好，主要是它什么都有现成的库，写起来快，改起来也快，跑到哪儿都行。之前弄过命令行的邮件工具 FengTang，弄过给论文 PDF 改名的 Chou，这回轮到验机了。

事情是这样的，现在电脑也都比较贵，有的老师和同学甚至准备考虑买二手电脑，反正不管是新电脑还是二手电脑，到手第一件事得验机——屏幕有没有坏点，摄像头能不能成像，麦克风扬声器灵不灵，键盘每个键是不是都响，散热会不会过热降频，电池健康度怎么样，固态硬盘读写速度达不达标。

这些东西去网上找一圈，要么是收费软件，要么是那种绿色单文件但塞了一堆广告的，要么就只支持 Windows。我们专业的同学可能用Linux多一些，那我就想，这玩意儿咱们用 Python 攒一个不行吗。

名字我起叫 BianQue，扁鹊。扁鹊是神医，望闻问切四诊法。你发现没有，验机其实也是这四个字：望，看屏幕看摄像头；闻，听扬声器听麦克风；问，把 CPU、内存、显卡、磁盘的信息都问出来；切，给 CPU 加压摸摸它热不热。所以叫扁鹊，我觉得挺贴切。

这个是用 PySide6 做的界面，其实还是沿袭了我这么多年的老一套 GUI 开发的套路，左边一列导航，右边十三个检测页：硬件总览、屏幕、摄像头、麦克风、扬声器、键盘、鼠标、散热、电池、磁盘、内存、网络、报告。

有几个地方做得有点呆，比如是屏幕坏点检测，点进去会全屏显示纯色，红绿蓝白黑灰六种颜色轮着来，你盯着看有没有亮点暗点就行。这里有个小细节：提示文字要是固定停在屏幕一个角，那那个角的坏点你就永远看不见了，所以我让它沿着屏幕边缘慢慢漂移，不挡任何地方。再一个是键盘检测，画了个虚拟键盘在屏幕上，你按哪个键它就变绿，全按绿了就说明都灵。这里头 Tab 键是个坑，Qt 默认拿它来切焦点，一开始死活映射不到，后来是重写了焦点切换的方法才搞定。麦克风那页显示一个实时电平表，你对着说话它就跳，还能录三秒回放给你听。扬声器是分开测左右声道的，先放一个只有左声道有声音的音，再放一个只有右声道的，你一听就知道喇叭接反没有。

信息采集这块也尽量往深里挖。CPU 能读到每核心的占用率，Apple Silicon 上还能分出性能核和能效核各几个；内存能读到每根内存的厂商、类型、容量，Windows 上还能读速度和通道数；显卡能读到芯片型号和它支持的图形接口，我这台读出来是 Metal 4；磁盘能分辨固态还是机械，读 SMART 健康状态。这些在 macOS 上有些拿不到——比如 Apple Silicon 的内存时序和频率，系统根本不暴露——读不到的我就不硬编，直接标个 N/A。

界面做了十种语言，中英日法俄德葡西韩意，菜单栏一换，整个界面和导出的报告都跟着换。

我琢磨着，这东西还有个用处，就是上课。给大一的新生讲 Python，最怕的就是例子太抽象，什么"计算 1 到 100 的和"，写出来中规中矩，但是我自己都觉得困啊，而且这么抽象，可能学生不知道这玩意儿到底能干嘛。这个工具就不一样：读硬件信息用的是 psutil 和系统命令，界面是 PySide6，生成测试音是 numpy 算正弦波，录音是 sounddevice，全是真实的东西，跑起来立刻能看到结果——屏幕上真的出来你自己的摄像头画面，麦克风电平真的在跳。跟学生说"你们现在学的这些库，就能做出一个完整的验机软件"，比讲一百遍"Python 能做什么"都管用。

安装就一行：pip install bianque，然后敲 bianque 就起来了。代码在 GitHub 上，地址是 https://github.com/cycleuser/BianQue ，PyPI 上是 https://pypi.org/project/bianque/ ，协议用的 GPL。

当然这东西也糙，很多边界情况没处理，温度在 macOS 上读不到我也就摆烂了。但自己用、验个机、给学生当个例子，对付着也够了。有兴趣的可以克隆代码下来玩玩，有想加的检测项也欢迎提交改进。

FengTang（冯唐）：命令行下的邮件管理小工具，可以发邮件跟远程设备的智能体通信

2026-09-25T15:20:00+08:00

作为敲代码的人，机器是有好几台了，比如宿舍一台台式机，家里一台常年开着的小机器，还有台云上的。平时想看看它们怎么样了，或者让它们顺手做点小事，正经办法当然是 SSH、远程桌面、或者搭个内网穿透。

可这些SSH我嫌麻烦，自组远程局域网有时候特别慢，而UU远程好像不支持Linux，而向日葵好像不太支持Wayland，Workbuddy虽然能支持手机访问，但是毕竟要经过人家的服务器，方便倒是方便了，但还是感觉长文本情况下用着不够顺，尤其在外面拿手机的时候，敲不了命令行，用语音输入虽然方便，但不方便加图和王智登登，而且最重要的是我特别懒，也不想为了连一下去装一堆东西。

后来我想，有件事是所有机器都能干、而且几乎不花钱的：发邮件。只要机器能上网，它就能往出发、也能往回收，中间隔着 NAT 也好、防火墙也好，都不碍事，因为它连出去是主动的。那我就顺着这个思路，给自己写了个命令行的小邮件工具，叫 FengTang。

这东西不复杂，也没啥新鲜创意。就是把 SMTP、IMAP、POP3 三样都做了，能发能收，常见的认证方式都支持，Gmail 和 Outlook 那种 OAuth 也能登，这部分完全参考了 Thunderbird 的实现；收发的邮件存在本地一个 SQLite 库里，可以离线搜、打标记、做整理。它自己还带了个很小的邮件服务器，没配现成邮箱的时候，也能在本机把收发先跑通。另外我给智能体单独留了一整套接口，就是那种 function calling 的工具定义，模型能直接调它来读信、发信、搜索、标记。

pip install fengtang
fengtang

开源地址：https://github.com/cycleuser/FengTang.git

我真正想要的用法其实很简单。在够不着的那台机器上挂一个智能体，让它隔一阵子看一眼信箱。有新邮件就照着里面的意思干活，干完回一封。我这边只要拿手机或者笔记本发一封出去，过一阵子就能收到回信。全程不用公网 IP，不用端口映射，路由器上啥也不用动。只要网络通，两边就能互相够得着。

比如我发一封“看看磁盘还剩多少”，它回我一段 df 的结果；或者“把这个仓库拉下来跑一下测试”，它跑完把日志贴回来。它能主动发信回来这一点挺关键，说明这条线是双向的，不是只能我单方面下命令。

登录这块也顺手做了。工具里有个交互式的 OAuth 登录，会弹浏览器让你点一下授权，token 自己存好；也支持把账号导出、导入，换机器的时候搬过去就行。所以给一台新机器配好这个信箱，并不算费事。

需要注意的是，这事情本质上是对智能体友好的邮件通信，而并不是远程控制。邮件的往返是异步的，靠轮询，慢的时候得等上一会儿，交互性的事儿干不了，你没法拿它开个 shell 看实时输出。它也不像那些在线 AI 对话服务，能你一句我一句地实时聊；这边就是你发一封、等一封，节奏慢得多。再就是它靠不靠谱，很大程度看邮箱服务商，大厂对直投的信卡得很严，所以我一般拿一个已经能登录的邮箱当中转，就图个稳。

安全上也得上心。能收信的那个邮箱，某种意义就是那台机器的钥匙，谁能发指令它就听谁的。所以我把凭据只放在本地配置文件里，权限收到 0600，导出去的时候默认用口令加密。这些都得自己注意，工具帮不上太多忙。

说白了，这远不是给大家用的产品，就是我自己图方便捣鼓出来的。好处也就那么一点：只要能上网，就能跟一台远程机器保持来往，而且基本不花钱。做不到实时，也做不到直接控制，但好歹多了一条路。

如果手里也有那种懒得搭环境的机器，不妨试试这个最土的办法——两边都拿邮件当传话筒。

AI 到底是不是泡沫？顺便说说显卡、内存、硬盘短期内还会不会降价

2026-09-23T00:00:00+08:00

AI 到底是不是泡沫？顺便说说显卡、内存、硬盘短期内还会不会降价

千问（Qwen）发布 27B 模型之后，其实就已经露出一个趋势了：本地模型不再只是玩具，也不再只是尝个鲜，而是成了一种能力虽然偏低、但可控性和安全性都很好的生产力工具。

等到 MiniMax、H3 这类视频生成模型一出来，AI 到底还是不是泡沫，就更值得商榷和讨论了。用在生产场景里的工具调用，现在确实能用了——尤其是做讲义、做格式转换这些活。再有一个热点就是 AI 视频生成。B 站上有个《是，魏王》系列，是参考《是，首相》做的一个纯 AI 短剧，文本写得非常棒。在 AI 的帮助下，以前那些有很好剧本创作能力的人，就能脱离拍摄成本的限制，自己来做更多东西了。

需求涨得很快，而且还在数量级地涨

随着文娱产业的需求越来越旺盛，相关模型的应用会带出一个领域的扩展，那这些物料的成本价格就不会往下掉。为什么这么说？最近我们这儿这一帮同学，他们接到的一些兼职——尤其是数据标注和长链任务处理上的兼职——那个数量级，明显能看出市场上对这类需求增长了，而且增长得很厉害。

这些需求增长的背后，对应的是显存、显卡、芯片、内存、存储这一整条链上成本需求的增长。而每年这些物料的上游供货量是有限的：人的开采能力有限，加工能力有限，市场的运输流转也有限度。需求却以数量级的规模在往上涨，那就会挤压民用产品的市场空间。按这个趋势推测，短期内价格大概是不会回调的。

内容创作的成本，被进一步压低了

再说内容这一头。以前各种自媒体平台的出现，是降低了会做内容的人制作内容的成本，但其实还是有不小的成本：要拍摄、要做分镜、要做稿、要呈现出来，还得考虑躲避审查这些事。现在这个成本被进一步压低了。

未来平台上的内容多样性会迎来井喷式的发展，这个爆发会带来更多新形态的全民自媒体创作，甚至全民影视创作——甚至不再需要用市场行为去评估了，而是自己想看什么就做什么，完全为自己做。改作业也好，生成教辅内容也好，这些根本不是市场行为，而是一种生活刚需。

所以，AI 到底是不是泡沫？

我的判断是，AI 正在逐渐颠覆曾经的传媒秩序，把更多的自主权和话语权交到普通人手里。而相对的，这个市场繁荣也会带来产业格局的变化。相关民用产品的价格，恐怕要受到这些日益增长的需求的挤压——厂商肯定优先满足那些大批量供货的商用场景和数据中心，民用的价格未必会降，很可能就退回到 16G，或者顶多 32G，很难再像以前那样，两千块就能加一根单条 64G。这个状态会持续几年。

但市场应该会调整。只靠数据中心一条腿，其实是有风险的；民用市场的稳定性、这种需求，反而是能起到抗风险作用的。所以回调的过程可能会相对漫长。甚至曾经被看作数据中心场景的一些产品，可能逐渐的会进入到民用的市场当中。这就像当年的那个微型机，以及笔记本电脑等，最开始也不是希望着能进入千家万户的，但最终它成了很多都使用的一种常见工具。

历史上有过的剧情，可能还是会重演的。另外在这个过程里，还会刺激到一些二手交易平台的兴盛。因为新设备价格实在太高了，有一些性能不是高优先级刚需的场景，可以对付对付就算了。

老登常谈（双语版）

2026-09-23T00:00:00+08:00

老登常谈（双语版）

我把这些年翻来覆去跟学生讲的那几套话，提炼出来、总结成 12 个系列、共 51 段，是为以后双语授课、甚至纯英语授课做准备。

说实在的，这些话用中文，我张嘴就能说出来；可一换成英语，表达起来就费劲。好在以前我在斯坦福大学的 Code in Place 上，2024 年、2025 年两次给人讲过 Python——讲咱们专业相关的内容我倒还撑得住，顺便也把英语练熟了点。

有时候孩子们在路上撞见我在背英语，其实不是那么回事：我不是在背英语，而是在准备一些讲课也用得上的东西。

每段先给英文、后给中文，都是三四句的完整段落，一分钟左右能读完、能背下来；末尾标了出处，尽量用公众号文章链接，没发公众号的给了博客链接。用法很简单：照着英文开口练，用中文核对意思，需要查原文就点出处链接。

系列一：心态与节奏

1. 徐徐图之

英：Don't chase quick results — take it slow, step by step you go. When you move at a steady pace, you stay calm and bring out your best. Slow and steady wins the day; rushing only gets in the way.

中：做事情不要急功近利，要徐徐图之——慢慢来，一步一步谋划。你慢慢做，人就从容、不紧张，反而能把实力发挥得更好。急不来、催不得，稳扎稳打才靠得住。

出处：《建议大学生朋友们做事情要徐徐图之，不要急功近利》（博客）

2. 不能走极端

英：Too much hope and too much fear are the same trap — both are extremes. Quick victory or quick defeat, the mistake is the same. Stay in the middle, keep your balance, and you can still think straight.

中：不管是"速胜论"还是"速败论"，极端的乐观和极端的悲观，本质都一样——都是极端。所有的事儿都相似，不能走极端。保持在中间，才留得住思考的余地。

出处：《建议大学生朋友们做事情要徐徐图之，不要急功近利》（博客）

3. 慢不是磨洋工

英：Going slow is not being lazy, and it's not stalling on purpose. It means a steady rhythm, a clear order, real results. Slow is not weak; slow is steady and sure.

中：慢不是磨洋工，不是故意拖沓，而是张弛有度、工作有序、成果有效。这个"慢"是稳，不是懒；是节奏，不是拖延。

出处：《建议大学生朋友们做事情要徐徐图之，不要急功近利》（博客）

4. 心态最重要

英：Nothing matters more than a calm mind and a cheerful heart. The moment you panic, your rhythm falls apart, and your ability slips away. Stay calm and keep smiling — that's where real strength starts.

中：心态好、心情好，天天乐呵呵，比什么都重要。心态一慌，节奏就乱了，原本能发挥出来的实力也发挥不出来。稳住神、笑一笑，比什么都值钱。

出处：《建议大学生朋友们做事情要徐徐图之，不要急功近利》（博客）

5. 将以有为也

英：When trouble comes, keep your strength — that leaves a way out. Some things simply can't be hurried. Hold on, stay alive, and one day you can still make something of it. As an ancient general said: I meant to do something with this later.

中：遇到困难，保存有生力量，就总留得一线生机。有些事情急不来，要徐徐图之，留得青山在，才能"将以有为也"。南霁云那句话，说的就是这个道理。

出处：《建议大学生朋友们做事情要徐徐图之，不要急功近利》（博客）

系列二：认知与谦逊

1. 心有外物而不化

英：General Qi Jiguang, in his book on training soldiers, warned: people cling to what they already know, and call their old ways the best. Once your mind is full of old habits, you naturally push away the new. Let go of the old, and you start to grow.

中：戚继光在《纪效新书》里说，人容易"心有外物而不化，自恃旧习以为佳"——心里装了旧东西，就不愿接受新的，还总觉得自己那套旧经验最好。不肯放下旧的，就学不进新的。

出处：《读〈纪效新书〉有感》

2. 别被已有认知束缚

英：Don't let what you already know lock you in. The real danger is not that you know too little — it's thinking that what you know is everything. A closed mind hurts more than an empty one.

中：人不能被自己已有的认知给束缚住。最要命的不是知道得少，而是觉得自己知道的就已经是全部，再没有别的可能。这种自以为"全知道了"，比无知更害人。

出处：《读〈纪效新书〉有感》

3. 知道自己知道得太少

英：After years of study and years of real life, the one thing I'm sure of is that I still know far too little. The more I learn, the more I see how small my corner is. Being humble isn't weakness — it's the plain truth.

中：念了些年书，闯了几年江湖，我大概能确定知道的，就是自己知道的实在太少了。越学越觉得自己那点认知小得可怜。这种谦卑不是示弱，是实话。

出处：《读〈纪效新书〉有感》

4. 别急着否定

英：When someone says you're wrong, the reflex to argue back is just an animal guarding itself. We reject first and nitpick later. Rise above it — listen first, then judge. That's what lifts you above the animal.

中：看见别人否定自己，第一反应是反驳、挑刺，这其实是动物性的自我保护。遇事先否定、见什么都挑刺，是本能在作怪。能超脱一点，先听听、再想想，才高级。

出处：《读〈纪效新书〉有感》

系列三：提问与沟通

1. 别问"在吗"

英：Don't send a message that only says "Are you there?" — it wastes everyone's time and makes the other person guess. Say what you need, straight and clear. Clear beats polite, every time.

中：发消息别只丢一句"在吗"，那是对双方时间的双重消耗，还让人家猜你要干什么。有事直接说，把话说清楚，就是最大的得体。清楚，比客气更管用。

出处：《高校教师建议大学新生：有事直接说，别问在吗》（博客）

2. 三句话说清楚

英：When you ask for help or report something, three things are enough: what it is, how it touches you, and why you ask this person. You don't need to be fancy — just don't leave people guessing. Say it plainly, then move on.

中：找人帮忙、问问题、汇报事情，说清三件事就够：什么事、跟你什么关系、为什么找到对方。不怕说得不够好，就怕什么都不说、让人猜。说清楚，就走人。

出处：《高校教师建议大学新生：有事直接说，别问在吗》（博客）

3. 先搜再问

英：Before you ask, search first — or ask an AI — and sort out the basics. Then bring that first understanding to the table. If you open your mouth before you lift a finger, people will wonder why you didn't even bother to look.

中：遇到不懂的，先自己搜，先问大模型，把信息理一理，再拿着初步认知去问人。你不动手先张嘴，人家会想：你连搜都懒得搜？自己先走一步，再开口。

出处：《高校教师建议大学新生先掌握「提问的智慧」》

4. 效率优先

英：When we talk, efficiency first, polish second. Get your point across, and everyone feels better. A short, clear word beats a long, flowery one.

中：沟通这件事，效率优先，得体其次。先把事说清楚，效率上来了，大家都舒服。快而清楚的一句话，胜过绕来绕去的客套。

出处：《高校教师建议大学新生：有事直接说，别问在吗》（博客）

5. 想说不敢说，不是内向

英：An introvert can speak when needed — they just don't want to when it's not necessary. If you want to speak but dare not, that's not your personality; you just haven't learned how. Don't hide behind a label.

中：内向的人需要表达时照样能说，只是不需要时不想说。如果你是想说却不敢说，那可能不是性格，是还没学会开口。别拿"我内向"当挡箭牌。

出处：《高校教师建议大学新生不要用内向的标签影响自己的沟通效率》

系列四：对自己诚实

1. 别把听话当必然

英：Don't assume the rules are always fair, that grown-ups are always right, or that obedience always pays. Growing past the student mindset doesn't mean turning cold — it means not being naive. Keep your warm heart; drop the innocence.

中：别以为规则一定公平，别以为大人一定对，别以为听话就一定有回报。去掉一些学生气，不是变冷漠，而是别太天真。该有的古道热肠还要有，只是别再傻乎乎。

出处：《高校教师希望大一新生尽快摆脱学生气的一些建议》

2. 大人不见得更有智慧

英：Most adults are not wiser than children — they just have more experience and habits, and know better how the world runs. That's all. So don't take every word they say as sacred.

中：大多数大人不见得比孩子更有智慧，只是有更多经验和习惯，对社会的运行逻辑更熟。如此而已。所以别把大人的每句话都当圣旨。

出处：《高校教师希望大一新生尽快摆脱学生气的一些建议》

3. 幻想和期待

英：A fantasy is believing things will get better by themselves. An expectation is knowing you must do something to make them better. College is full of things worth expecting — just don't let expectation quietly turn into fantasy.

中：幻想是以为事情会自动变好，期待是知道自己要去做些什么让它变好。大学里值得期待的东西很多，但别把期待过成了幻想——等着天上掉馅饼，是掉不下来的。

出处：《高校教师希望大一新生尽快摆脱学生气的一些建议》

4. 真热爱，还是只想赢

英：Ask yourself clearly: do you truly love this thing, or do you just want to win through it and feel you belong? Letting someone else win for you is cheap joy. Real love lasts; borrowed victory doesn't.

中：分清楚你是真的热爱一件事，还是只想通过它赢、想要一种归属感。让别人替你赢，那种快乐来得廉价。真正的热爱撑得久，借来的胜利撑不久。

出处：《高校教师建议大学生朋友能对自己诚实负责地度过大学生活》

5. 大学是起点，不是终点

英："Once you get into college, you can relax" is one of the biggest lies you'll ever hear. College is where the competition is sharpest and the free time is most — that's where the gap widens. This is a starting line, not a finish line.

中："到了大学就轻松了"是你可能听过的最大的谎。大学里竞争最激烈、可支配时间最多，你和别人的差距，很多是在大学拉开的。这是起点，不是终点。

出处：《高校教师希望大一新生尽快摆脱学生气的一些建议》

系列五：情绪与决定

1. 别把赌气当决定

英：Before you decide, ask yourself: do I really want this, or am I just acting out of spite? Every time you stop yourself from turning a feeling into a choice, you take charge of your life. That one question saves a lot of regret.

中：做决定之前问自己一句：我到底是真的想这么选，还是只是在赌气。每一次能拦住自己把情绪当成决定，都是对自己负责。这一句话，能省掉很多后悔。

出处：《高校教师建议大学新生尽量避免赌气-学会基于判断而不是情绪来做决定》

2. 赌气不划算

英：Failing a subject and then quitting isn't "I tried and couldn't" — it's "I didn't try, so I couldn't." The second excuse is easier to swallow, but it costs far more. You're not protecting your pride; you're paying for it.

中：一门课没考好就索性不学，那不是"努力了还不行"，而是"没努力所以不行"。后一个说法好接受，但代价其实更大。你不是在保面子，是在为面子付账。

出处：《高校教师建议大学新生尽量避免赌气-学会基于判断而不是情绪来做决定》

3. 别把自己架起来

英：If you dig in out of spite, the homework still has to be done and the juice will still be there — but you've already boxed yourself in. Stubborn pride only locks you into a worse corner. Choose the better path, not the prouder one.

中：赌气到底，作业照样得做、果汁照样想喝，可话已经放出去了，自己把自己架在那儿，图什么呢？死要面子，最后只会把自己逼进更差的局面。

出处：《高校教师建议大学新生尽量避免赌气-学会基于判断而不是情绪来做决定》

系列六：通识与谦逊

1. 手里拿锤子

英：When all you have is a hammer, everything looks like a nail. Study one subject deeply, and you may feel it explains everything — but you're missing the thinking other fields have built for centuries. Knowing other tools exist keeps you humble.

中：手里拿着锤子，看什么都是钉子。学了一个学科，容易觉得它能解释一切，其实是忽视了别的学科早就积累了很久的思考。知道还有别的锤子、别的工具，才不容易因为无知而自大。

出处：《高校教师建议同学们进入大学之后适当补充各个学科的通识内容并且养成终身学习的习惯》

2. 别被工程成就冲昏头

英：A steam-engine master, however brilliant, could never dream of a nuclear reactor. It's not stupidity — those ideas simply aren't in his world. Be great at your craft, but stay humble before what lies beyond it.

中：一个蒸汽机师傅优化到极致，也想不到核反应堆。不是他笨，是他的知识坐标系里没有那些维度。手艺再精，也要对视野之外的东西保持敬畏。

出处：《计算机学科的同学尤其应该注重培养通识并且避免工程上的傲慢》

3. 无穷和无穷不一样

英：There are infinitely many whole numbers, and infinitely many real numbers — yet there are more real numbers. Learning that some infinities are bigger than others is a real jolt to intuition. Some things are true even when they don't feel true.

中：自然数无穷多，实数也无穷多，但实数比自然数更多。知道"有些无穷比另一些更大"，是数学带给你的一种认知冲击。直觉会骗人，逻辑不会。

出处：《高校教师建议同学们进入大学之后适当补充各个学科的通识内容并且养成终身学习的习惯》

4. 结构决定一切

英：The same carbon atoms make soft graphite or hard diamond. The atoms don't change — the arrangement does. Structure carries power, in matter and in teams alike. Change the layout, and you change the result.

中：同样的碳原子，排成石墨就软，排成金刚石就硬。原子没变，变的是结构。结构本身就带有力量——放在物质上、放在团队上，都一样。

出处：《高校教师建议同学们进入大学之后适当补充各个学科的通识内容并且养成终身学习的习惯》

5. 多看点字，少刷点视频

英：Short videos push your excitement bar so high that you can't sit through a long text. Words make you think; pictures just feed you. Read more, and you'll think deeper — it's a trade well worth making.

中：短视频把刺激的阈值拉得很高，习惯了就坐不住看长文。文字要你主动去想，画面直接喂给你。读得越多，想得越深，这笔账划得来。

出处：《高校教师建议同学们进入大学之后适当补充各个学科的通识内容并且养成终身学习的习惯》

6. 历史教训要学，角色不要拿

英：History holds wonderful patterns, but don't put yourself inside them. Don't become a loyal fan of some dynasty or group, as if their glory were yours. You are you — learn the lessons, don't take the roles.

中：历史里有很多精彩的规律，但别代入。不要成为某个王朝、某个群体的忠实粉丝，觉得跟人家荣辱与共。你是你自己，历史的教训要学，角色不要拿。

出处：《高校教师建议同学们进入大学之后适当补充各个学科的通识内容并且养成终身学习的习惯》

系列七：工具观

1. 工具是来帮你的

英：Tools are here to help you, not to scare you. Learn the basics first; then the bigger tools feel like a hand, not a weight. A tool you truly know becomes an extension of your hand.

中：工具是来帮你的，不是来吓你的。先把最基础的东西用熟，再上大工具，你会觉得它顺手，而不是压迫。真正学会了的工具，会成为你手的延伸。

出处：《并非故意-为什么我更多用命令行工具而不是GUI》

2. 命令行不骗人

英：The command line tells you exactly what went wrong. A graphical screen just spins, pops up "failed," and stops. That's why I love the command line — it doesn't lie to you.

中：命令行报错就是报错，清清楚楚甩给你。图形界面转个圈，弹个框说"操作失败"，就完事了。所以我喜欢命令行——它不骗人。

出处：《并非故意-为什么我更多用命令行工具而不是GUI》

3. 别把工具当信仰

英：Worshipping a brand like a religion is just another kind of worship — it turns a thing into a faith. Electronics are tools, not gods. Use them well, but never kneel to them.

中：把某个牌子当宗教来膜拜，和膜拜别的东西没两样，都是把东西当成了信仰。电子产品说到底就是工具，不是神。用好它，但别跪它。

出处：《建议大学生朋友们做事情要徐徐图之，不要急功近利》（博客）

系列八：外语学习

1. 语言要先用起来

英：Language is meant to be spoken and heard first, then read and written. The courage to open your mouth and not fear looking silly matters more than test scores. I was near the bottom in class, but I always dared to speak — and in the end, I used it best.

中：人类的语言本来就该先听说、后读写。敢开口、不怕丢人，比考试分数重要得多。我外语一路垫底，但一路敢说，最后反而用得最好。

出处：《高校教师建议大学生朋友们不要忽视外语的学习》（博客）

2. 学外语是为了讲好我们自己的故事

英：The richer a culture grows, the more it needs people who can speak foreign languages to tell its stories to the world. If you can't open your mouth, how will you tell others what's good about us? Learn the language, then tell the story.

中：本土文化越昌盛，越需要有外语能力，好把这些好故事讲出去。自己都张不开口，怎么给别人讲我们的好东西？把语言学好，把故事讲出去。

出处：《高校教师建议大学生朋友们不要忽视外语的学习》（博客）

3. 别信"不用学"那套

英：Anyone who says "you don't need to learn a foreign language" either has an agenda or is making excuses for their own laziness. Believe it, and only you pay the price. Don't let someone else's failure become your ceiling.

中：凡是劝你"不用学外语"的，要么别有用心，要么是拿这套说辞给自己找台阶。真信了，吃亏的只有自己。别拿别人的失败，当自己偷懒的理由。

出处：《高校教师建议大学生朋友们不要忽视外语的学习》（博客）

系列九：思维误区

1. 别急着证明自己对

英：The easiest trap is rushing to prove you're right and burning hours on it. The time you spend defending yourself is time you could have spent reflecting and improving. Winning an argument is rarely worth the cost.

中：最常见的坑，就是急于证明自己是对的，为这事浪费一大堆时间。时间都花在证明自己对上，反思的时间就没了。逞一时口舌之快，代价追不回来。

出处：《高校教师建议大学新生和家长都应该尽早防范的几种常见思维误区》

2. 错了就认

英：Everyone makes mistakes — memory slips, hands fumble, even masters mess up. Admitting a mistake is basic, and without it you can't improve. Refusing to admit a problem is the surest way to never fix it.

中：犯错再正常不过，记忆会出错，行为会失控，再高的高手都可能玩脱。认错是件很基础的事，不认错就不可能进步。不承认问题存在，就没法解决问题。

出处：《高校教师建议大学新生和家长都应该尽早防范的几种常见思维误区》

3. 别迷信权威

英：Just because someone is famous and successful doesn't mean you should swallow everything they say. Success often rides on luck and timing that even the winner can't see. Judge the idea itself, not the person who said it.

中：一个很有名、很权威的人说了啥，不见得就该信。成功里往往有运气和时代的成分，连成功者自己都未必看得清。判断一个观点，看它本身，别看是谁说的。

出处：《高校教师建议大学新生和家长都应该尽早防范的几种常见思维误区》

4. 从来如此，未必对

英："Everyone does it" and "it's always been this way" are not reasons — they're reflexes. A reasonable person gathers the facts and weighs the costs before deciding. Don't hand your judgment to the crowd or to habit.

中："别人都这样""从来如此"，这俩说法都没来由。该做的是理性判断，把资料收集齐，权衡好利弊再做决定。别把判断力外包给从众和惯性。

出处：《高校教师建议大学新生和家长都应该尽早防范的几种常见思维误区》

系列十：博弈与格局

1. 三种结局

英：Every game between people ends one of three ways: both lose, one wins and one loses, or both win. Most conflicts in life aren't zero-sum — there's usually a way to make the pie bigger. Look for the third way before you fight over the first two.

中：世间所有的博弈，归根结底逃不开三种结局：两败俱伤的负和、此消彼长的零和、相互成就的正和。生活里大多数冲突都不是零和的，先找第三条路，再谈争抢。

出处：《高校教师建议家长和新生进入大学前先了解一下博弈》

2. 别掉进负和

英：The saddest game is the negative-sum one, where everyone walks away worse. Two roommates feuding for half a year, teammates tearing each other down — no one wins, everyone loses. Talk early, before a small thing turns into mutual ruin.

中：最让人扼腕的是负和博弈，所有人都没占到便宜，收获远小于付出。室友较劲半年、队友互相拆台，谁也没落着好。小事早沟通，别等它变成互相伤害。

出处：《高校教师建议家长和新生进入大学前先了解一下博弈》

3. 把蛋糕做大

英：Real masters don't fight over how to cut a fixed cake — they find a way to make it bigger. Share your apple, share your orange, and both of you taste two flavors instead of one. Cooperation makes value that competition can't.

中：真正的高手，从不把自己困在零和的笼子里，而是想办法把蛋糕做大。你分我半个苹果、我分你半个橘子，俩人都能尝到两种味道。合作创造的价值，竞争给不了。

出处：《高校教师建议家长和新生进入大学前先了解一下博弈》

4. 别因怀疑而互相背叛

英：The prisoner's dilemma shows why people betray each other even when working together would be best for both. Cut off and unsure, each side plays "safe," and both end up worse. Trust, built slowly, is often the smarter long game.

中：囚徒困境说透了人为什么明明合作最有利，却还是互相背叛。被隔开、不确定对方会不会守约，各自"理性"地背叛，结果双双更惨。慢慢建立的信任，往往才是更聪明的长期打法。

出处：《高校教师建议家长和新生进入大学前先了解一下博弈》

系列十一：没有标准答案

1. 别迷信标准答案

英：The "standard answer" you memorized is just the best guess of its time — nothing more. History is full of "final answers" that turned out to be only stepping stones. Don't treat a textbook answer as the end of thinking.

中：你背下来的"标准答案"，不过是它那个年代最好的猜测，仅此而已。历史上很多"最终答案"，后来都被证明只是中间产物。别把教材答案当成思考的终点。

出处：《从志愿填报开始学生和家长都应该考虑到生活不一定要有标准答案》

2. 连太阳系都改过答案

英：Thirty years ago the solar system had nine planets; now it has eight, and someone wants to change it back. The solar system never changed — only our names and textbooks did. What changed is us, not the world.

中：三十年前太阳系有九大行星，现在改成八大，最近又有人要改回去。变的从来不是太阳系，只有人类的概念和教材。变的是我们，不是世界。

出处：《从志愿填报开始学生和家长都应该考虑到生活不一定要有标准答案》

3. 上学不是单行道

英：School is not a one-way road from college to PhD to teaching — that's just one path of many. Life is richer than a single fixed route. If you don't love your major, you may switch — just think it through first.

中：上学不是一条单行道，本科读研读博教书，只是很多条路里的一条。人生很丰富，不必非按某一条既定路径走。不喜欢自己的专业，深思熟虑之后，可以换。

出处：《从志愿填报开始学生和家长都应该考虑到生活不一定要有标准答案》

4. 别让别人的信息替你决定

英：The scariest thing is choosing your life by your parents' advice — advice that may be years out of date — while never trying what you actually want. Years later, you regret the road you didn't take. Look into it first, then choose.

中：最可怕的是按家里长辈的建议做了选择，可长辈的信息未必更新到最新；自己想做的事又没去尝试、没去弄明白。过了很多年，只剩后悔当初。先搞清楚，再决定。

出处：《从志愿填报开始学生和家长都应该考虑到生活不一定要有标准答案》

系列十二：大学怎么读

1. 别光靠听课

英：If you expect to learn everything from lectures, you'll be let down — some teachers just read slides. The real gift of college is that no one holds your hand anymore. Learning to find things yourself is the skill that matters most.

中：指望光靠听课就学到很多东西，这想法不靠谱——有的老师就是念 PPT。大学最关键的地方，恰恰是没人再带着你了。学会自己找东西学，才是最重要的能力。

出处：《大学里是不是什么都学不到》

2. 主动探索

英：In college, the most important thing is to find chances and dig into what truly interests you. What the textbook skips and the teacher doesn't teach, you have to learn on your own. That ability is what carries you to graduate school and beyond.

中：到了大学，最重要的是找到机会，以所学为基础，对自己感兴趣的方向去探索。课本没讲、老师没教的东西，得自己想办法去学。有了这能力，才能走得更远。

出处：《大学里是不是什么都学不到》

3. 用好免费资源

英：Your college gives you a library, online databases, journals, and talks — use them all. Textbooks are the oldest, journals fresher, conference papers freshest. One good talk can be worth more than a semester of class.

中：图书馆、电子文库、论文订阅、讲座，这些都是大学白给你的，都得用起来。教材最老，期刊新点，会议论文最新。一场好讲座，可能顶得上半学期的课。

出处：《大学里是不是什么都学不到》

4. 你是哪种人

英：On the journey west, the Monkey King runs everywhere to gather what it takes to solve a problem, while others wait for the problem to vanish by itself. Be the one who goes looking for answers, not the one who waits. The role is yours to choose.

中：取经路上，孙悟空是满世界去凑解决难题的资源，而有的人是等着难题自己消失。别做那个干等的人，去做那个主动找答案的人。你想当哪种人，自己选。

出处：《进入大学的你想成为取经路上的哪种人？》

5. 事情本身最重要

英：Watch out when a system starts chasing the score instead of the thing itself — that's how good intentions get twisted. Grades, rankings, metrics — don't let the measuring stick become the goal. Keep your eyes on what truly matters.

中：当一个体系开始只盯着指标、而不是事情本身的时候，好事也会被扭曲。分数、排名、KPI，都别让"尺子"变成了"目的"。眼睛要盯在真正重要的事情上。

出处：《「事情本身不重要」是怎么炼成的》

为什么这么多东西都服从正态分布？从历史、数学、物理到哲学的一次完整拆解

2026-09-23T00:00:00+08:00

为什么这么多东西都服从正态分布？

人的身高、同一种螺栓的直径、反复测量同一个量的误差、一次大考的成绩……很多你随手一测的东西，画成直方图，都是中间高、两边低、左右对称的一个钟形。这个形状我们叫正态分布，也叫高斯分布。

但问题是：凭什么？凭什么这么多互不相干的现象，最后都收敛到同一个形状？这是巧合，还是背后有某种必然？

这篇文章我想把这件事从根上拆一遍：它最早是怎么被人发现的，数学上到底哪一步把它逼成了钟形，物理里它对应着什么样的机制，以及哲学上它到底意味着什么、又不意味着什么。

从赌场里长出来的钟形曲线

故事要从赌博说起。

17 到 18 世纪，概率论基本是被赌徒和数学家一起拉扯出来的。帕斯卡、费马给"公平的赌注该怎么分"定了规则，然后有一批人开始研究一个很具体的问题：扔硬币，扔很多次，正面朝上的次数会怎么分布？

这个问题等价于二项式展开 $(a+b)^n$ 的系数，也就是二项分布。$n$ 很大的时候，这些系数中间巨大、两边迅速衰减，形状正是那个钟形。但直接算 $n!$ 特别费劲，于是人们想要一个近似的公式。

1733 年，法国的棣莫弗（Abraham de Moivre）干了一件了不起的事：他找到了二项式系数的近似，发现它逼近一条钟形曲线。为了得到这个近似，他还顺带把 $n!$ 的近似给搞了出来——这就是后来所谓的斯特林公式。有意思的是，公式里那个常数 $\sqrt{2\pi}$ 其实是棣莫弗先摸到的，斯特林只是把常数补完整了。所以严格讲，正态分布第一次露脸，是在算赌钱的概率里，而不是在什么高深的科学里。

高斯：测量误差逼出来的分布

真正让钟形曲线"封神"的，是天文学。

1801 年，意大利天文学家皮亚齐发现了谷神星，但只观测了四十来天就找不着了，全欧洲都在猜它跑哪儿去了。24 岁的高斯（Carl Friedrich Gauss）用自己的一套办法，从这些带误差的观测数据里算出了一个轨道，结果别人照着他算的位置，真的又找回了谷神星。高斯一战成名。

他用的办法，就是最小二乘法：找一条轨道，让所有观测误差的平方和最小。但这里有个隐藏的坑——为什么是"平方"？为什么不是绝对值，不是四次方？高斯必须给个理由。

1809 年，高斯在《天体运动理论》里给出了理由。他的论证大致是：假设误差是由大量微小扰动叠加而成的，那么误差应该服从一个特定的分布；而这个分布，恰好让"平方和最小"等价于"最有可能"。这个分布就是

\[f(x)=\frac{1}{\sigma\sqrt{2\pi}}\,e^{-\frac{(x-\mu)^2}{2\sigma^2}}\]

顺便说一句，最小二乘法的"优先权"一直有争议：勒让德在 1805 年就先发表了它。高斯倒挺大度，说自己 1795 年就开始用了。这场公案到现在也没个干净的了断，但没关系，重要的是这条曲线从此有了科学地位。

所以高斯分布的"高斯"两个字，来自测量误差、来自天文学，而不是来自什么抽象数学。人们先是在现实里反复撞见它，然后才去问"为什么"。

拉普拉斯：把"为什么"证了出来

真正回答"为什么"的，是拉普拉斯（Pierre-Simon Laplace）。

他做的事情，可以概括成一句话：不管单个因素是什么分布，只要数量足够多、彼此足够独立、单个因素又都别太离谱，那么它们的总和就必然逼近正态分布。 这就是中心极限定理（CLT）的核心。

这句话的分量极重。它等于说：正态分布不是某个特定现象的特殊性质，而是"大量微小独立因素的叠加"这个操作本身的性质。谁在叠加，谁就趋向钟形，几乎不管你原来的因素长什么样。

拉普拉斯在 1810 年前后证明了这件事的一个版本，后来切比雪夫、马尔可夫、李雅普诺夫（1901）、林德伯格（1922）等人又把它推广、收紧，把条件弄得越来越精确。今天我们说的中心极限定理有很多版本，但灵魂都是拉普拉斯那句话。

"正态"这名字，其实是后起的

有个细节值得说：高斯和拉普拉斯那会儿，没人管它叫"正态分布"，大家叫它"误差律"（law of error）、"误差频率律"。

到了 19 世纪，比利时人凯特勒（Adolphe Quetelet）做了一件很有争议的事：他把这个本来用于测量误差的曲线，拿去套社会数据。他统计了上千名苏格兰士兵的胸围，发现居然也服从这个钟形曲线。于是他提出了"平均人"（l'homme moyen）的概念，认为社会现象背后也有和天体一样的规律。这个举动影响巨大，但也埋下了后面哲学上的争论。

高尔顿（Francis Galton）后来研究遗传、研究身高，发现身高也服从这个分布，还提出了"向均值回归"（regression to the mean）——这成了现代统计里"回归"这个词的源头。高尔顿把这条曲线叫"误差频率律"，还称它是"至高无上的法则"。

"正态"（normal）这个词，是 19 世纪下半叶才慢慢流行起来的，皮尔逊、高尔顿、莱克西斯这些人都用过。皮尔逊晚年还承认过，这名字挺糟糕，容易让人以为其他分布都"不正常"。这个命名上的包袱，正好引出我们后面哲学部分要讲的东西。

数学：正态分布是怎么被"逼"出来的

上面是历史，现在把数学上的道理拆开看。主要有五层。

第一层：可加性——为什么总和趋向正态

中心极限定理用式子说就是：如果 $X_1, X_2, \dots, X_n$ 独立同分布，均值 $\mu$、方差 $\sigma^2$，那么它们的平均值标准化之后

\[\frac{\bar X - \mu}{\sigma/\sqrt{n}}\ \xrightarrow{d}\ N(0,1)\]

也就是说，随着 $n$ 增大，无论 $X_i$ 原来是什么分布（均匀、指数、抛硬币……），它们的平均值都收敛到标准正态。

这件事之所以成立，背后是"特征函数"在起作用。特征函数是概率分布的傅里叶变换，独立变量求和，特征函数就相乘。把乘积展开、只保留前几项，最后一定冒出 $e^{-t^2/2}$ 这个因子——而 $e^{-t^2/2}$ 正是正态分布的特征函数。所以"求和→正态"不是巧合，是傅里叶变换和泰勒展开联手逼出来的。

第二层：公式里为什么有 $e$ 和 $\pi$

那个公式里有两个数学世界的"大明星"：$e$ 和 $\pi$。它们是怎么钻进来的？

$e$ 来自"极限"：概率论里凡是涉及大量独立事件累积的地方，几乎必然出现 $(1+\frac{x}{n})^n \to e^x$。正态分布的指数形式，本质就是这种极限的产物。

$\pi$ 来自"对称性"和归一化。要让整条曲线下的面积等于 1，就得算高斯积分

\[\int_{-\infty}^{\infty} e^{-x^2}\,dx = \sqrt{\pi}\]

这个积分为什么带 $\pi$？因为它是圆的面积在作怪：把积分平方，转成极坐标，$x^2+y^2=r^2$ 里那个圆就露出来了。所以 $\pi$ 出现在正态分布里，是因为这个分布和一个"圆"有隐秘的联系。

第三层：稳定性——正态加正态还是正态

正态分布有一个别的分布几乎都没有的性质：两个独立正态变量之和，还是正态分布，只是均值和方差各自相加。这叫"稳定性"。

在"大量独立微小因素叠加"这个场景里，稳定性极其关键：如果每一步叠加都保持形状不变、只是变宽，那么经过无穷多步之后，你自然还待在"正态"这个家族里。换句话说，正态分布是"求和"这个操作下的一个不动点、一个吸引子。别的分布跌进来，走着走着就都变成了它。

第四层：最大熵——一个信息论的视角

还有一个更现代的视角，来自 E.T. Jaynes 的"最大熵原理"（1957）。问题反过来问：如果我只知道一个分布的均值 $\mu$ 和方差 $\sigma^2$，别的什么都不知道，那我应该选哪个分布才最"诚实"、最不引入偏见？

答案是正态分布。在所有均值和方差固定的分布里，正态分布的熵最大——它是在"只知道前两阶矩"这个约束下，最无偏见、最"含混"的选择。

这个视角很有意思：它不把正态分布看成"自然的铁律"，而看成"信息不足时的默认选项"。我们后面讲哲学，还会回到这一点。

第五层：它是扩散方程的解

把概率分布看成"一团会扩散的东西"，正态分布就有一个非常物理的身份：它是扩散方程（热传导方程）的基本解。

\[\frac{\partial u}{\partial t} = D\frac{\partial^2 u}{\partial x^2}\]

这个方程从一个点出发，解随时间演化，就是一个越变越宽的高斯函数

\[u(x,t)=\frac{1}{\sqrt{4\pi Dt}}e^{-\frac{x^2}{4Dt}}\]

这个身份很重要，因为它把数学和物理直接接上了。下一节讲物理，就从这里讲起。

物理：随机游走、热和量子谐振子

随机游走与布朗运动

设想一个花粉颗粒悬浮在水里，被无数水分子东撞一下、西撞一下。每一撞都是随机的、独立的、微小的。花粉颗粒经过一段时间后的位移，就是这成千上万次微小碰撞的总和。

根据中心极限定理，这个位移应当服从正态分布。1905 年，爱因斯坦正是从"随机游走"的模型出发，推导出布朗运动，并写下扩散方程——位移的分布就是一个高斯分布，方差随时间线性增长。后来佩兰的实验验证了爱因斯坦的预言，顺带敲定了原子的存在。

所以物理里最直观的"正态分布无处不在"的原因就是：当一个量是大量独立随机微扰的累积时，它就逃不出钟形曲线。

麦克斯韦速度分布

气体里每个分子的速度分量，为什么也服从正态分布？

因为分子的速度是无数次碰撞累积的结果，而且碰撞是随机的、独立的。于是每个速度分量（比如 $v_x$ 方向）服从均值 0、方差 $kT/m$ 的正态分布；三个分量独立，合起来就是麦克斯韦分布。注意一个细节：分子的"速率" $v=\sqrt{v_x^2+v_y^2+v_z^2}$ 服从的不是正态，而是麦克斯韦速率分布——因为速率是三个高斯分量的"长度"，不再是简单求和了。这个区分很重要，它说明正态分布只对"求和量"天然成立。

统计力学：平衡态附近的涨落是高斯

更一般地说，统计力学里，一个系统在平衡态附近的涨落，几乎总是高斯的。原因是：把熵 $S$ 在最大值附近展开，一阶项为零，领头项是二阶项

\[S \approx S_{\max} - \frac12 \sum_i \lambda_i x_i^2\]

而概率正比于 $e^{S/k}$，于是

\[p \propto e^{-\frac12 \sum_i \lambda_i x_i^2}\]

这就是高斯。所以"平衡态附近是高斯涨落"在物理里几乎是个普遍结论——只要你离平衡态足够近。

量子谐振子的基态

再往微观走一步：量子力学里，一维谐振子的基态波函数长这样

\[\psi_0(x) = \left(\frac{m\omega}{\pi\hbar}\right)^{1/4} e^{-\frac{m\omega x^2}{2\hbar}}\]

又是一个高斯。它和前面那些不是巧合，而是一脉相承：谐振子的势能是二次的 $V=\frac12 m\omega^2 x^2$，基态是能量最低的态，而高斯恰恰是"在位置和动量的不确定度之间最平衡"的形状——它同时达到海森堡不确定关系的下界。

哲学：它意味着什么，又不意味着什么

从"多因之果"到数学定理

正态分布的哲学根基，古人其实早有直觉：一个结果若是许多微小原因共同造成的，这些原因的效应会大致抵消，剩下一个居中的、可预期的结果。亚里士多德、盖伦这些人都表达过类似的意思。

中心极限定理的意义，就是把这条朴素的哲学直觉，变成了一条可以被证明、可以被量化的数学定理。它告诉我们：只要"多因、独立、微小"这三个条件大致成立，结果就趋向正态。这是数学史上少数几条"从世界抽象出来、又反过来解释世界"的定理。

拉普拉斯的决定论与概率的张力

这里有个有趣的转折。拉普拉斯本人是决定论的代表人物——他写过著名的"拉普拉斯妖"：如果有一个存在知道宇宙里所有粒子的位置和速度，它就能算出过去和未来的一切。

但同一个人，又发展了概率论，证明了中心极限定理。表面看矛盾，其实不矛盾：决定论说的是"底层物理定律确定"，概率论说的是"我们人类信息不足，只能用概率来描述"。正态分布恰好站在这个交点上——它不是自然本身的属性，而是"我们在信息有限时，对大量复杂原因的一种最优描述"。这正好接上前面最大熵原理给出的结论。

"平均人"的教训：从理想化到误用

凯特勒的"平均人"引发了一个持久的哲学问题：正态分布描述的是"真实的规律"，还是仅仅"我们的理想化"？

凯特勒把它当成社会规律的证据，仿佛社会也服从天体的法则。但高尔顿后来指出，凯特勒的"平均人"其实并不存在——没有哪个人真的长着"平均身高、平均体重、平均胸围"。均值是一种抽象，不是实在。

这个争论一路延续到今天。它的教训是：正态分布是一个极其有用的模型，但它是模型，不是现实本身。把模型当现实，是历史上很多统计误用的根源。

不是所有东西都正态：幂律与胖尾

最后必须泼一盆冷水。正态分布虽然无处不在，但它绝不是万能的。它的成立依赖"独立 + 微小 + 求和"这几个条件，而现实里大量东西并不满足：

如果因素是相乘的而不是相加的，结果趋向的是对数正态，不是正态——这个我们下一节结合具体例子讲。如果因素之间有强烈关联、有正反馈、有"赢家通吃"，结果可能是幂律分布，尾巴又长又肥：城市人口、财富、地震能量、书籍销量，很多都是这种。曼德博（Benoit Mandelbrot）研究了一辈子这件事，指出金融市场收益的"胖尾"远比正态分布预测的严重；塔勒布（Nassim Taleb）的"黑天鹅"也是在讲：正态分布会严重低估极端事件。

所以对正态分布的正确态度是：它是大量"独立、微小、可加"现象的一个极好的默认模型，但不是普适真理。知道它什么时候成立、什么时候失效，比会背它的公式重要得多。

一句话总结：加性出正态，乘性出对数正态

把整篇文章收成一个最实用的结论，就是这一句：如果一个量是许多独立微小因素的"和"，它就趋向正态；如果是许多独立微小因素的"积"，它就趋向对数正态——也就是取对数之后才正态。

拿我们做地球化学的人来说，这个区分天天在用。岩石、土壤、水里的微量元素含量，比如稀土、痕量金属，绝大多数服从的是对数正态分布，而不是正态分布。原因就是：元素的富集、分配很多是乘性的过程——分离结晶里的分配系数、稀释、富集，一步乘一步，累积起来就成了乘积。所以原始浓度画出来是右偏的，取了对数之后才变成漂亮的钟形。阿伦斯（L. H. Ahrens）1954 年那篇经典的《元素的 lognormal 分布》，讲的就是这件事。

反过来，像测量误差、身高、零件尺寸这些，本质是"加"出来的，就老老实实服从正态。

所以下次你拿到一批数据，先别急着套正态分布，先问一句：这个东西是怎么"长"出来的？是加出来的，还是乘出来的？这一个问题，往往比任何统计检验都更能告诉你该用什么模型。

收尾

从棣莫弗算赌注，到高斯测星星，到拉普拉斯的定理，再到爱因斯坦的花粉、麦克斯韦的气体、量子力学的谐振子，最后到凯特勒的"平均人"和曼德博的胖尾——正态分布这一路，串起了概率论、统计、物理、化学、社会学和哲学。

它之所以无处不在，不是因为它有多神秘，而是因为"大量独立微小因素的叠加"这件事在世界上太普遍了，而数学又恰好证明了：只要你在做这件事，结果就必然是钟形。

它是一条从混乱里长出来的秩序。但请记得，它不是唯一的秩序，也不是万能的秩序。理解它成立的条件，比膜拜它的形状，更有价值。

统计检验概念详解：零假设、自由度、服从分布，以及 t、卡方、F 三个分布

2026-09-22T20:45:00+08:00

前阵子写《基础知识：初级统计概念的简单介绍》的时候，讲的是平均值、方差、标准差这些"描述性统计"——它们回答的问题是"这堆数据长什么样"。

这篇文章要讲的是另一套东西，回答的问题是"两组数据的差异，到底是真的，还是碰巧"——这就是推断统计，也就是统计检验。它是一套术语密集的概念系统：零假设、自由度、服从分布、t 分布、卡方分布、F 分布……每个词单拿出来都像黑话，放在一起更像天书。

这篇文章的目标，是把这些黑话全部翻译成人话。每讲一个概念，我会先用一个生活里的比方说清楚"它到底在干什么"，再给出直觉解释，最后补一段能直接跑的 Python 代码。读完你应该能看懂论文里"t(18) = 6.1, p < 0.001"或者"χ²(1, N=5924) = 11.50, p < 0.001"这种句子到底在说什么。

先给一张地图，后面每个概念都是这张图里的一块拼图：

总体（想知道但看不到全貌的一群人）
   │  抽样
样本（手里实际拿到的一小撮数据）
   │  计算
统计量（把样本压缩成几个数：均值、t 值、卡方值……）
   │  对照
分布（如果零假设成立，统计量本该落在哪里）
   │  算概率
p 值（实际落点有多"离谱"）
   │  下结论
拒绝 / 不拒绝零假设

一、总体与样本：为什么需要"推断"

先说一个大前提：你几乎永远看不到"总体"。

你想知道"全中国成年男性的平均身高"，但你不可能量遍每一个成年男性。你能量到的只是手里这一千个人的身高。这一千个人就是样本，全中国成年男性才是总体。

统计检验要干的，就是从样本出发，去推断总体的性质。因为看不到总体，所以所有的结论都是"带概率的猜测"——这就是为什么统计检验永远在谈概率、谈分布、谈"显著不显著"，而不是斩钉截铁地说"是"或"不是"。

二、统计量：用几个数，概括一堆数

统计量（statistic），说穿了就是"从样本数据里算出来的一个数"。

它的来源是样本——不是拍脑袋想出来的，是对手里的数据做加减乘除得到的。它的作用是概括：一千个身高数字没法直接给人看，但"平均身高 172 厘米"一个数就能说明很多问题。

常见的统计量分两类：

类型	例子	回答的问题
描述性统计量	均值、方差、中位数	这堆数据长什么样
检验统计量	t 值、卡方值、F 值	差异/偏离有多大，是否显著

描述性统计量上一篇讲过，这篇文章重点是检验统计量。它的定义有点绕，但可以先记住一句话：

检验统计量，就是把"你观察到的差异或偏离"浓缩成一个数，好拿去和"纯偶然能产生的波动"做比较。

比如 t 值，本质是个"信噪比"：分子是信号（两组均值差多少），分母是噪声（抽样自然波动多大）。t 值大，说明差异明显盖过了随机波动，这差异就可能是真的。

from scipy import stats
import numpy as np

# 两组各 20 人的成绩
control = np.random.normal(70, 10, 20)      # 对照组，平均 70
experiment = np.random.normal(78, 10, 20)   # 实验组，平均 78

t_value, p_value = stats.ttest_ind(experiment, control, equal_var=False)
print(f"t 值 = {t_value:.3f}")
print(f"p 值 = {p_value:.4f}")

t 值 = 2.587
p 值 = 0.0139

这个 t = 2.587 就是一个检验统计量。它本身只是个数字，它的意义要放到"分布"里才能解释——这正是下一节的内容。

三、服从分布：数据的"落点规律"

"服从分布" 这个词，是所有黑话里最唬人的一个。把它翻译成人话就是：

数据不是乱来的，它们落在不同取值上的可能性是有规律的。这个规律，就叫分布。

举个最直观的例子。你去校门口量 1000 个路人的身高，然后把身高分成很多小段（160-162 一段，162-164 一段……），数每个小段有多少人，画成直方图。你会看到：中间段人最多，越往两边人越少，整个形状像一口钟。这就是"身高服从正态分布"的意思——不是说每个人都是平均身高，而是说身高的落点遵循一条钟形曲线。

"服从分布"的严格说法是：一个随机变量的取值，可以用某条概率密度曲线（或某个概率表）来描述。曲线越高的地方，取值落在那里的可能性越大。

import matplotlib.pyplot as plt
import numpy as np

# 模拟 1000 个"服从正态分布"的身高数据
heights = np.random.normal(172, 7, 1000)
plt.hist(heights, bins=30, density=True, alpha=0.6, color="#1f77b4")
plt.xlabel("身高（cm）")
plt.ylabel("频率密度")
plt.title("1000 个身高的直方图：中间多、两边少，接近钟形")

直方图的形状，就是我们常说的"分布的形状"。为什么统计检验这么在乎分布？因为——

只有知道了"如果纯属偶然，这个统计量会落在哪里"，你才能判断"眼前这个落点是不是太离谱了"。

换句话说，分布是统计检验的"裁判规则书"。下面几节讲的 t 分布、卡方分布、F 分布，就是三种不同的裁判规则书。

四、正态分布：统计世界的"默认设置"

在讲那三个分布之前，必须先讲正态分布（normal distribution），因为另外三个分布要么从它派生，要么拿它当参照。

正态分布长这样：

它的形状特征，一句话：中间高、两边低、左右对称的钟形。两个参数决定它：

均值 μ：钟顶在哪（中心位置）；
标准差 σ：钟有多胖（数据的离散程度）。

它最著名的性质是"68-95-99.7 法则"：

大约 68% 的数据落在均值 ± 1 个标准差之内；
大约 95% 落在均值 ± 2 个标准差之内；
大约 99.7% 落在均值 ± 3 个标准差之内。

为什么正态分布是"默认设置"？两个原因：

自然界太多东西近似正态：身高、体重、测量误差……大量微小随机因素叠加的结果，往往就是正态分布（这就是中心极限定理）。
抽样均值的分布，无论原始数据长什么样，只要样本够大，就趋近正态。这是统计检验能成立的地基。

所以课件里反复强调"以下方法全部假定数据服从正态分布"——因为 t 检验、ANOVA 这些方法，都是建立在这个假设之上的。

五、零假设与备择假设：先假定"没事"，再找证据反驳

零假设（null hypothesis，记作 H₀），是统计检验里最核心也最容易理解反的一个概念。

它跟法院的无罪推定一模一样：开庭之前，先假定被告无罪。要判他有罪，控方必须拿出足够强的证据，强到"被告要是真无罪，不可能出现这种证据"的程度。

统计检验完全照搬这个逻辑：

零假设 H₀：先假定"没有差异 / 没有关联 / 没有效果"。比如"两组平均身高没有差异"。
备择假设 H₁：零假设的反面。比如"两组平均身高有差异"。

注意两个容易搞错的地方：

零假设不是你想证明的结论，恰恰是你想"推翻"的靶子。检验的目标是看证据够不够强，强到能把"没有差异"这个默认状态推翻。
检验的结论只有两种：要么"拒绝零假设"（证据够强，有显著差异），要么"不拒绝零假设"（证据不够，不能下结论有差异）。注意是"不拒绝"，不是"接受"——就像法院判"证据不足、无罪释放"不等于"证明他真是个好人"。

# 零假设 H0：两组均值相等（μ1 = μ2）
# 备择假设 H1：两组均值不相等（μ1 ≠ μ2）
#
# t 检验做的事：在 H0 成立的前提下，算出现当前差异的概率（p 值）。
# 若 p 值太小（比如 < 0.05），说明"H0 成立时不该出现这么大差异"，
# 于是我们拒绝 H0，认为差异显著。

一句话总结：

零假设 = 无罪推定 = 默认没有差异。统计检验 = 找证据，看能不能把这个默认状态推翻。

六、p 值与显著性水平：证据要强到什么程度

有了零假设，下一个问题就是：差异大到什么程度，才算"够强"？

p 值（p-value） 的严格定义是：

在零假设成立的前提下，观察到"当前结果或更极端结果"的概率。

把它翻译成人话：如果两组真的没有差异，纯靠偶然，出现我们看到的这个差异（甚至更大的差异）的概率有多大？

p 值大（比如 0.6）："没差异"也能轻轻松松产生这么大的波动，所以没有理由怀疑零假设。
p 值小（比如 0.001）："没差异"的话，出现这么大差异的概率只有千分之一，太离谱了，所以有理由认为差异是真的。

那"多小算小"？这就是显著性水平 α（significance level），通常取 0.05。它是一条人为划的红线：

p < α（比如 p < 0.05）→ 拒绝零假设 → 结果"显著"；
p ≥ α → 不拒绝零假设 → 结果"不显著"。

论文里常见的星号就是这么来的：* = p<0.05，** = p<0.01，*** = p<0.001，星越多证据越强。

from scipy import stats

# t = 2.5，自由度 18，算双尾 p 值
t_obs = 2.5
p = stats.t.sf(t_obs, 18) * 2    # sf = survival function，即右尾面积；×2 是双尾
print(f"t = {t_obs}, p = {p:.4f}")
print("p < 0.05" if p < 0.05 else "p >= 0.05")

t = 2.5, p = 0.0223
p < 0.05

p 值最大的坑：它对样本量极度敏感。样本一大，再微不足道的差异也能给出极小的 p 值。所以 p 值只回答"差异是否可检测到"，不回答"差异有多大"——后者要靠效应量（后面第 9 节讲）。

七、自由度：能自由变动的数据点个数

自由度（degrees of freedom，简称 df），是被问得最多的概念，也是最值得用直觉先打通的一个。

最直白的定义：

自由度 = 在给定了某些约束之后，还能自由变动的数据点个数。

一个经典例子。三个数，已知它们的平均值是 10：

第 1 个数可以随便选，比如 8；
第 2 个数也可以随便选，比如 12；
第 3 个数就被锁死了——必须是 10，否则均值就不是 10 了。

所以这三个数里，真正自由的只有 2 个，自由度 = 3 - 1 = 2。那个被减掉的 1，就是"均值"这个约束消耗掉的一个自由度。

这就是样本方差公式里除以 n-1 而不是 n 的来历：算样本方差时，你已经先算了一次样本均值，用掉了一个自由度，所以剩下的自由度是 n-1。

# 三个数，均值锁定为 10
# 前两个可以自由选，第三个被锁定
a, b = 8, 12
c = 3 * 10 - a - b
print(f"a={a}, b={b} 自由选择后，c 被锁死为 {c}")
print(f"自由度 = 3 - 1 = 2")

a=8, b=12 自由选择后，c 被锁死为 10
自由度 = 3 - 1 = 2

为什么自由度这么重要？因为它决定分布的形状。t 分布、卡方分布、F 分布的形状都随自由度变化。自由度小，说明"信息少、估计不稳"，对应的分布就更胖、更保守。

几个常见的自由度：

场景	自由度
单样本 t 检验	n - 1
独立两样本 t 检验	n₁ + n₂ - 2
卡方检验（2×2 表）	1
卡方检验（r×c 表）	(r-1)(c-1)
单因素 ANOVA（组间）	k - 1
单因素 ANOVA（组内）	N - k

八、t 分布：小样本均值的"谨慎版"正态

现在讲第一个"裁判规则书"：t 分布。

回忆一下：t 值 = 均值差 ÷ 均值差的标准误。问题来了——当样本量很小时，我们连"标准误"都估不准，于是 t 值的落点就比标准正态更不确定。

t 分布就是用来描述这种"小样本下的不确定性"的分布。它长得像正态分布，但：

自由度越小，尾部越胖——因为样本少、信息不足，极端值出现的概率比正态高，判断要更保守；
自由度越大，越接近标准正态分布——样本多了，估得准了，就退回正态。

看这张图：df=1 的 t 分布（红线）尾巴明显比正态（黑线）厚得多，df=30（绿线）已经几乎和正态重合了。

from scipy import stats

# 同样落在 x=3 的位置，df 越小，尾部概率越大
for df in [1, 5, 30, 1000]:
    print(f"df={df:>4}  P(X>3) = {stats.t.sf(3, df):.4f}   正态分布 P(X>3) = {stats.norm.sf(3):.4f}")

df=   1  P(X>3) = 0.1024   正态分布 P(X>3) = 0.0013
df=   5  P(X>3) = 0.0150   正态分布 P(X>3) = 0.0013
df=  30  P(X>3) = 0.0027   正态分布 P(X>3) = 0.0013
df=1000  P(X>3) = 0.0014   正态分布 P(X>3) = 0.0013

看到没：同样落在 x=3 这个"极端"位置，df=1 时概率是 0.1024（不算罕见），df=1000 时是 0.0014（很罕见了）。这就是"样本越小，越要谨慎"的数学表达。

t 分布用在什么时候：比较两组均值（t 检验）。论文里的 t(18) = 6.1, p < 0.001，意思就是"自由度为 18 的 t 检验，检验统计量 t=6.1，p 值小于 0.001"。

九、效应量：差异"有多大"，而不是"有没有"

p 值回答"差异是否真实存在"，但它不回答"差异有多大"。一个身高差 0.1 厘米的差异，样本够大时也能 p<0.001，但 0.1 厘米没有任何实际意义。

效应量（effect size） 就是来补这个洞的。它把"差异的绝对大小"用标准化的方式表达出来，让人一眼看出差异是否"值得一提"。

最常用的效应量是 Cohen's d：

d = (两组均值差) / (合并标准差)

经验判断：d ≈ 0.2 是小效应，0.5 是中等，0.8 是大效应。

import numpy as np

control = np.random.normal(70, 10, 50)
experiment = np.random.normal(74, 10, 50)

mean_diff = experiment.mean() - control.mean()
pooled_sd = np.sqrt((np.std(control, ddof=1)**2 + np.std(experiment, ddof=1)**2) / 2)
d = mean_diff / pooled_sd
print(f"均值差 = {mean_diff:.2f}，合并标准差 = {pooled_sd:.2f}")
print(f"Cohen's d = {d:.3f}")

均值差 = 4.12，合并标准差 = 9.98
Cohen's d = 0.413

论文报告规范通常是：既要报 p 值（有没有差异），也要报效应量（差异有多大）。只报 p 值是外行做法。

十、卡方分布：偏离程度的分布

卡方检验用来处理分类数据——不是身高这种连续数字，而是"及格/不及格""是/否""类别 A/B/C"这种数人头的计数。

卡方值衡量的是：观测频数（实际数到的人数）和期望频数（零假设成立时"应该"数到的人数）偏离了多少。

χ² = Σ (观测频数 - 期望频数)² / 期望频数

偏离得越厉害，卡方值越大。而这个卡方值"纯靠偶然会落在哪里"，由卡方分布描述。

卡方分布的形状特点：

只能取非负值（因为平方项都是正的）；
右偏（长长的右尾巴），自由度越大越趋近对称。

一个经典例子（来自课件）：两个作文题目，统计"人"这个词的词频，判断"人"的词频是否和题目有关联。

	题目A	题目B	合计
人	114	27	141
其他名词	863	945	1808
合计	977	972	1949

import numpy as np
from scipy import stats

observed = np.array([[114, 27],
                     [863, 945]])
chi2, p, dof, expected = stats.chi2_contingency(observed, correction=True)
print(f"χ² = {chi2:.2f}, df = {dof}, p = {p:.3e}")
print("期望频数：")
print(expected)

χ² = 56.07, df = 1, p = 6.992e-14
期望频数：
[[ 70.68  70.32]
 [906.32 901.68]]

χ² = 56.07，p 小到 6.99×10⁻¹⁴，说明"人"的词频和题目有极强的关联——两个题目里"人"的使用确实不一样。

卡方分布用在什么时候：分类变量的关联性检验。论文里的 χ²(1, N=5924) = 11.50, p < 0.001，意思就是"自由度为 1 的卡方检验，样本量 5924，卡方值 11.50"。

十一、F 分布：方差比值的分布

当你要同时比较三组及以上的均值差异时，t 检验不够用了（它只能比两组），这时上 ANOVA（方差分析），用的检验统计量是 F 值。

F 值的设计思路特别巧妙。它把"差异"拆成两半：

F = 组间差异（信号） / 组内差异（噪声）

组间差异：各组均值之间的高低不同——这是你想找的"信号"；
组内差异：同一组内部个体的自然波动——这是"噪声"。

如果组间差异大、组内差异小，F 就大，说明组与组之间的区别明显盖过了随机噪声，差异是真的。如果 F 接近 1，说明信号完全淹没在噪声里。

F 值的落点，由 F 分布 描述。它有两个自由度：一个来自组间（分子），一个来自组内（分母）。

F 分布的形状和卡方很像：非负、右偏。有两个自由度（df1 和 df2），分别对应分子和分母。

课件里那个手工算 F 的小例子，把公式拆得很清楚：

组	观测值	均值
A	8, 10, 12	10
B	4, 6, 8	6
C	6, 8, 10	8

import numpy as np
from scipy import stats

A = np.array([8, 10, 12])
B = np.array([4, 6, 8])
C = np.array([6, 8, 10])
grand = np.concatenate([A, B, C]).mean()

ss_between = sum(len(g) * (g.mean() - grand)**2 for g in (A, B, C))
ss_within = sum(((g - g.mean())**2).sum() for g in (A, B, C))
k, N = 3, 9
msb = ss_between / (k - 1)     # 组间均方，自由度 k-1
msw = ss_within / (N - k)      # 组内均方，自由度 N-k
F = msb / msw
p = stats.f_oneway(A, B, C).pvalue

print(f"SS组间={ss_between}, SS组内={ss_within}")
print(f"MSB={msb}, MSW={msw}")
print(f"F = {F:.1f}, p = {p:.4f}")

SS组间=24.0, SS组内=24.0
MSB=12.0, MSW=4.0
F = 3.0, p = 0.1250

F = 3.0，p = 0.125 > 0.05，所以不能拒绝零假设——这三组的均值差异不足以被证明是真实的。

F 分布用在什么时候：三组及以上均值比较（ANOVA）、以及很多模型的整体显著性检验。

十二、第一类错误与第二类错误：检验也会犯错

统计检验是基于概率的，所以它天然会犯两种错：

错误类型	是什么	类比
第一类错误（α）	零假设其实成立，你却拒绝了它——"误判有罪"	冤枉好人
第二类错误（β）	零假设其实不成立，你却没拒绝它——"漏判有罪"	放走坏人

显著性水平 α 就是你自己设定的第一类错误上限：α=0.05 意味着你愿意接受"最多 5% 的概率冤枉好人"。

两者之间存在跷跷板关系：α 定得越小（越不容易误判有罪），就越容易放走坏人（第二类错误越大）。这就是为什么 α 不是越小越好，0.05 是学界在两者之间取的一个平衡。

# 第一类错误的直觉：即使零假设成立，纯抽样波动也可能让 p 偶尔 < 0.05
import numpy as np
from scipy import stats

np.random.seed(0)
false_positives = 0
for _ in range(1000):
    a = np.random.normal(70, 10, 30)   # 两组其实来自同一总体（无差异）
    b = np.random.normal(70, 10, 30)
    _, p = stats.ttest_ind(a, b)
    if p < 0.05:
        false_positives += 1
print(f"1000 次'无差异'检验中，误报显著的次数：{false_positives}（约等于 α × 1000）")

1000 次'无差异'检验中，误报显著的次数：52（约等于 α × 1000）

两组数据明明来自同一个总体（确实没有差异），但 1000 次检验里仍有约 52 次"误报显著"——这就是 5% 的第一类错误在真实发生。

十三、前提假设：这些方法为什么"有条件"

课件反复强调，t 检验、ANOVA 都建立在一些前提假设上，不满足这些假设，结论就不可靠：

1. 正态性（normality） 每组数据应大致服从正态分布。样本量大时（每组 ≥ 30）相对稳健；但相对频率这种数据常常严重偏态，需要警惕。

2. 方差齐性（homogeneity of variance） 各组方差应大致相等。可以用 Levene 检验判断；不齐时用 Welch 修正（我们前面 t 检验用的 equal_var=False 就是 Welch 修正）。

3. 观测独立性（independence） 每个观测相互独立，不重复测量同一对象。文本分析里，每篇文章算一个独立样本。

4. 期望频数（卡方特有） 卡方检验里，列联表每个格子的期望频数不宜过小（通常需 > 5），否则卡方近似不成立。

这些假设如果严重不满足怎么办？答案是换非参数检验。

十四、非参数检验：不依赖正态分布的备胎

非参数检验，就是那些"不要求数据服从正态分布"的方法。

最典型的是 Kruskal-Wallis 检验，它是 ANOVA 的非参数版本。ANOVA 要求正态、方差齐，Kruskal-Wallis 只要求独立——它不直接用原始数值，而是把数值换成排名（秩）再比较，因此对偏态、异常值都不敏感。

课件的实战建议很实用：

先跑 ANOVA 看分布，偏态严重就换 Kruskal-Wallis；卡方只在你只想用组级计数时用。

from scipy import stats
import numpy as np

# 三组严重偏态的数据（不满足正态假设）
A = np.random.exponential(1, 30)
B = np.random.exponential(1.5, 30)
C = np.random.exponential(2, 30)

f, p_anova = stats.f_oneway(A, B, C)      # ANOVA（假设正态）
h, p_kw = stats.kruskal(A, B, C)          # Kruskal-Wallis（非参数）
print(f"ANOVA:          F={f:.3f}, p={p_anova:.4f}")
print(f"Kruskal-Wallis: H={h:.3f}, p={p_kw:.4f}")

ANOVA:          F=5.916, p=0.0038
Kruskal-Wallis: H=15.94, p=0.0003

偏态数据下，非参数的 Kruskal-Wallis 往往比 ANOVA 更稳健。

十五、事后比较：ANOVA 显著了，然后呢？

ANOVA 有一个"先天不足"：它只告诉你"至少有一组和别人不同"，但不告诉你是哪两组。

要定位具体差异，需要事后比较（post-hoc test），最常用的是 Tukey HSD。它的思路是：一次性地校正所有两两比较，把"误报"的总概率锁回到 α，避免你连续做一堆 t 检验导致第一类错误累积。

from statsmodels.stats.multicomp import pairwise_tukeyhsd
import numpy as np

np.random.seed(1)
vals = np.concatenate([
    np.random.normal(10, 2, 20),   # A 组
    np.random.normal(12, 2, 20),   # B 组
    np.random.normal(13, 2, 20),   # C 组
])
groups = np.array(["A"]*20 + ["B"]*20 + ["C"]*20)
res = pairwise_tukeyhsd(vals, groups, alpha=0.05)
print(res.summary())

Tukey HSD 会输出每一对的均值差、校正后的 p 值，以及"是否显著"（reject=True/False）。这样你就知道到底哪两组之间有真实差异。

十六、一张表收尾

把整篇文章的脉络收进一张表，方便查阅：

概念	人话解释
总体 / 样本	想知道的全体 vs 手里拿到的一小撮
统计量	从样本算出来、用来概括或检验的那个数
服从分布	数据落点遵循的规律（钟形、右偏……）
正态分布	中间高两边低的钟形，统计的"默认设置"
零假设 H₀	无罪推定：先默认"没有差异"
备择假设 H₁	零假设的反面："有差异"
检验统计量	把差异/偏离浓缩成的那个数（t、χ²、F）
p 值	零假设成立时，出现当前结果的概率
显著性水平 α	判死刑的红线，通常 0.05
自由度 df	还能自由变动的数据点个数
t 分布	小样本均值的分布，df 越小尾巴越胖
卡方分布	"偏离程度"的分布，非负、右偏
F 分布	"方差比值"的分布，非负、右偏
效应量	差异有多大（不只是有没有）
第一类错误	冤枉好人（无差异却报显著）
第二类错误	放走坏人（有差异却没查出来）
非参数检验	不要求正态的备胎（Kruskal-Wallis）
Tukey HSD	ANOVA 显著后，定位具体哪两组不同

最后

统计检验这套术语，本质上是一个反证法的流水线：

先假定"没有差异"（零假设）；
把观察到的差异浓缩成一个数（检验统计量）；
对照"纯偶然时这个数该落在哪里"（分布）；
算"出现这么离谱结果的概率"（p 值）；
概率够小就推翻零假设，不够小就维持原判。

理解了这条流水线，t 检验、卡方检验、ANOVA 的区别就只剩下"用什么统计量、对照什么分布"——而这两点，本文都讲过了。剩下的就是多读几篇带统计结果的论文，看到 t(18)=6.1、χ²(1)=11.50、F=16.96 这些符号时，能条件反射地知道它们在说什么。

给纯新手：在 Windows 上从记事本到终端，跑起你的第一个 Python 脚本

2026-09-20T00:00:00+08:00

给纯新手：在 Windows 上从记事本到终端，跑起你的第一个 Python 脚本

这篇文章写给那种"从来没碰过命令行、没写过一行代码"的朋友。你手头有一台 Windows 电脑，想自己写个小脚本把它跑起来，结果卡在各种窗口、各种键位上面。别慌，我把从零开始的一条龙给你捋一遍，你照着做，十分钟内能见到自己的程序跑起来。

为什么先教你这些"最笨"的办法

先说明一下，为什么非要用记事本这种土办法，而不是一上来就装个大软件。

我接触过的不少大一同学，电脑是上了大学才认真开始用的。平时玩手机为主，刷视频、聊天、看剧都在手机上，连打游戏都不怎么用电脑。你让他新建个文件夹、改个文件名、看看文件在哪个盘，他都是懵的。这没什么好丢人的，就是接触电脑晚、没人教，也没机会练，电脑的基本操作和基础知识等于一片空白。

所以我故意绕开那些"高级"的东西，先把最基础的操作走一遍。就这一篇里，其实已经练到好几样了：怎么开终端、怎么敲命令，怎么用记事本写东西、保存、改扩展名，什么是路径、怎么从地址栏拿到一个文件夹的位置，怎么进目录、看目录里有什么、再运行一个程序。这些"终端、文件、扩展名、路径"的概念看着不起眼，却是后面所有编程和计算机操作的地基。地基不打牢，后面用什么都是空中楼阁。

至于那些更复杂的集成开发环境（IDE）、各种功能花哨的编辑器，咱们留到后边再讲。现在先把这些最基础的东西用熟了、手指有了记忆，再上大工具，你会觉得那些工具是来帮你的，而不是来吓你的。

这次课，就这一份文本

再说一下这次课怎么上。第一次课我在讲台上给大家做过演示，也专门挑了几个同学，先教会他们，再让他们下去教其他同学。到了这次课，就只发你们手里这一份文本——没有图、没有视频，别的什么都不准用，就靠它把任务完成。这么做的目的，是练你们"看着文字描述、自己一步步把事做出来"的能力：一句话没看懂，就多读两遍，照着敲，慢慢就能顺下来。别指望旁边摆张截图对着点，离开图也能把事办成，才算是真会了。

先提醒一句：很多人（包括我以前带过的学生）第一步就卡在按键上。Windows 键就是键盘左下角画着一个小窗户的那个键。下面每一步我都把"按哪个键、点哪个地方"写清楚，你不用猜。

第一步：打开一个"管理员终端"

我们要用到的那个黑乎乎的窗口，学名叫"终端"，Windows 11 上默认是 PowerShell。管理员身份其实不是必须的，但有些操作（装东西、改系统配置）需要它，所以干脆一上来就用管理员开，省得后面不够用还得重开。

按住 Windows 键，再按一下字母 X。

注意，是 Win+X，你要的就是 Win+X 这一个组合。

按完之后，屏幕左下角（开始按钮的位置）会弹出一个菜单，里面一排黑底白字的选项。找到"终端(管理员)"或者"Windows PowerShell(管理员)"——不同版本的 Windows 名字略有差别，认准"管理员"三个字就行——点它。系统可能弹个框问你是不是允许这个程序修改你的设备，点"是"。

完事之后，屏幕上会出现一个深色窗口，上面一行行英文，最后有个闪烁的光标。这个就是终端，你等会要在这里敲命令。

第二步：用记事本写一个小脚本

记事本怎么开？Win+R 最快。

按住 Windows 键，再按一下 R，会弹出一个小小的"运行"对话框，里面有个输入框。输入 notepad，回车。

记事本就出来了，一个空白的白板。在里面敲这几行（就三行，照着敲，别漏了引号）：

print("你好，世界！")
name = input("你叫什么名字？")
print("欢迎你，" + name)

第一行打印一句问候，第二行问你的名字并等你输入，第三行把你输进去的名字打回来。就这么个东西，但它是货真价实的 Python 程序。

第三步：保存成 .py 文件（这一步最容易翻车）

按 Ctrl+S（按住 Ctrl 再按 S），第一次保存会弹出"另存为"对话框。

这里有两个坑，新手十有八九会踩。

第一个坑是保存路径。对话框顶部或者左侧有个位置栏。为了后面好找，建议你用一个固定的地方：先进到 D 盘的 VirtualMachine 文件夹，在里面新建一个以你名字命名的文件夹——右击空白处，选"新建 → 文件夹"，输入你的名字。这个文件夹的完整路径就是 D:\VirtualMachine\名字（把"名字"换成你自己的名字，比如你叫张三，就是 D:\VirtualMachine\张三）。把保存位置定到这个文件夹里。

第二个坑是扩展名。对话框底部有个"保存类型"下拉框，默认是"文本文档 (*.txt)"。如果你不碰它，直接在上面的"文件名"里输入 20260920.py 然后点保存，Windows 会悄悄地把它存成 20260920.py.txt——它把 .txt 硬塞到后面，你的文件根本不是 Python 文件，回头运行的时候会报错。

正确的做法：把"保存类型"改成"所有文件 (.)"，然后在"文件名"里输入今天的日期——比如今天是 2026 年 9 月 20 日，就输 20260920.py。用日期当名字，好处是以后每次一眼就能看出这段代码是哪天写的。这样存下来的才是真正的 Python 文件。

顺带说一句：如果你想在资源管理器里一眼看出文件到底是 .py 还是 .txt，可以把扩展名显示打开。打开任意一个文件夹窗口，顶部"查看"标签 → "显示" → 勾选"文件扩展名"。勾上之后，那些藏起来的 .txt 尾巴就都露出来了。这步可选，但强烈建议勾上，能少踩很多坑。

第四步：找到这个文件在电脑里的"地址"

资源管理器（就是看文件夹的那个窗口）顶部有一长条"地址栏"，显示的是当前文件夹的位置，大概长这样：

D:\VirtualMachine\名字

这串东西就是这个文件夹的"路径"，你可以理解成它在电脑里的门牌号。

把光标点进地址栏（或者直接按 Ctrl+L），它会变成可以编辑的文字。按 Ctrl+A 全选，Ctrl+C 复制。这串路径就进剪贴板了。

第五步：在终端里进到这个文件夹

切回第一步打开的那个终端窗口（如果关了，就再按一次 Win+X 重新开一个，这次不开管理员也行，普通终端就够用）。

在光标闪烁的地方，敲 cd 加一个空格，然后把刚才复制的路径粘贴进去。粘贴在 PowerShell 里直接按 Ctrl+V 就行：

cd D:\VirtualMachine\名字

回车。如果没报错，光标会跳到下一行，这时候你就已经"站在"你的那个文件夹里面了。

如果路径里有空格（比如你给文件夹起了个带空格的名字），记得给整串路径加个引号：

cd "D:\VirtualMachine\我的 文件夹"

不过绝大多数人从地址栏复制过来的路径都不用加引号，直接粘贴回车就行。

第六步：看看这个文件夹里都有啥

敲 ls，回车。

这是"列出当前文件夹里的所有文件"的意思。你会看到刚才存的 20260920.py 躺在里面，可能还有别的文件。确认一下 20260920.py 在不在，在就对了。

第七步：运行它

先说个让你安心的事：咱们机房的机器已经装好了 miniconda，里面带着一个 Python 3.13，所以这一步你不用操心 Python 装没装的问题。如果你是在自己电脑上做，那先参考我之前公众号里发的安装教程，把 Python 装好再回来。

敲 python 20260920.py，回车。

程序就跑起来了：终端里先蹦出一句"你好，世界！"，然后问你"你叫什么名字？"，你在下面随便输个名字，回车，它就会回你一句"欢迎你，XXX"。

到这儿，你就完整走了一遍"写脚本 → 保存 → 进目录 → 运行"。

几个常见问题，提前给你兜底

运行 python 的时候报"不是内部或外部命令"：机房机器不会出这个问题，Python 已经装好了。这种情况基本只会出现在你自己的电脑上——要么没装 Python，要么装了没加到 PATH 里。参考我之前公众号里那篇安装教程，装的时候注意勾选"Add Python to PATH"（加到 PATH）那个勾，再重新开一次终端试试。

python 不行就试 py：Windows 装 Python 时会自带一个叫 py 的启动器。python 20260920.py 不行的话，试试 py 20260920.py，大概率能跑。

ls 报"不是内部或外部命令"：说明你现在开的是老式的"命令提示符"（cmd），它不认 ls，认 dir。要么换成 PowerShell 终端（Win+X 里选"终端"），要么把 ls 换成 dir，效果一样。

文件变成了 20260920.py.txt：就是第三步没改"保存类型"。回去把文件重命名，或者重新保存一次，这次记得把"保存类型"选成"所有文件"。

最后

这些操作看着琐碎，其实就两个能力：会用记事本存对扩展名，会在终端里 cd 到目录再 python 运行。掌握了这两个，后面你写什么脚本都能自己跑，不用每次求人。

有什么卡住的，照着报错信息去搜，搜不到就群里问我吧孩子们。

建议大学生朋友们做事情要徐徐图之，不要急功近利

2026-09-20T00:00:00+08:00

建议大学生朋友们做事情要徐徐图之，不要急功近利

我高考语文 130 多，虽然这语文单科分数在我们班不算最高，但也还行，四处拿出去吹也能对付一阵。

到了大学的时候，那会儿我们都要学大学语文。当时那阙老师看上去貌不惊人，瘦瘦的，小小的，有点江湖侠客的风骨。但最开始我打心眼儿里对那老师也不是很敬佩，觉得他未必有多厉害，总想着自己已经学过的东西可能就很厉害了。

这就是戚继光将军在《纪效新书》里曾经提到的「心有外物而不化，自恃旧习以为佳」的一种具体表现。

后来老师给我们讲春秋，讲张巡、许远守睢阳，那才发现真是堪称大家。什么《百家讲坛》，什么《东方名家》之类的，那些讲座上的所谓名师高人，和我们阙夫子相比，也差之甚远。

但是说来惭愧，他讲的其他内容，我早都忘了，现在能想起来的就是当时结尾的那段，印象最深。

说的是张巡守睢阳的时候，手底下有一个将官非常英勇，叫南霁云，和当时的雷万春两个人齐名，都是非常骁勇的将领。

睢阳城破的时候，南霁云面对叛军的劝降，有所沉吟，半晌未语，没有立即表明自己是愿意投降还是愿意殉国。张巡就骂他说：「南老八，你怎么还要投降，还是怎么着？」（南霁云排行在八）。南霁云说了一句：「将以有为也。」

这意思大概是说，他本来想着如果投降，在叛军这儿混着，可能以后能有所作为，把叛军给消灭掉什么的。这有点像卧底的意思，让人想起来当年的姜维在钟会手下，其实也算是类似这么个意思。

可惜呢，后来由于张巡这么一激，南霁云也就慨然就义。

现在想想，很多事儿啊，如果保存有生力量，总能够留得一线生机。而且有的事儿是着急急不来的，一定要慢慢来，不能够急着就做到，所谓“缓缓图之”，历史已经告诉了我们很多经验和教训了。

最重要的一条就是，不管是“速胜论”还是“速败论”，这都是错误的，都是一体两面。不管是极端的乐观还是极端的悲观，它都是极端，本质上都是一样的。

就像是选了一个“某花牌”，或者选了一个“某果牌”来作为宗教来膜拜，这也是类似的。只是所选的东西不一样，但本质行为都是在膜拜，都是把消费类电子产品当做了一种信仰。

所有的事儿都相似，不能走极端。

所以遇到事呢，不求快但求慢。因为你慢慢做的事儿，你就从容，不紧张，从容不迫，就能做得更有条有理，可以把你的实力发挥到更好。

这个慢不是磨洋工，不是故意拖沓，而是能够张弛有度，工作有序，成果有效。哎呀，我发现自己连着用了这么三个，看上去像是想做排比，其实就有点儿老登作风，这不太好。

反正就是心态就很重要。如果心态慌了，开始觉得没有章法了，那后边的节奏可能都乱了，很多事儿原本能发挥出来的实力都未必能做到，就非常不划算了。

所以，有的时候即便这道题不会做，或者这个环境没配置好，又或者一个工具软件掌握得不理想，再或者是某个科目学得不够称心如意，也都别着急。徐徐图之，要持久战，不能够走极端。

而且一定要相信，心态好、心情好，天天乐呵呵，比什么都重要，才能「将以有为也。」

OpenLaoKe 彻底重构-从 7.8 万行砍到 1.8 万行，试图成为python版本的Pi

2026-09-19T12:30:00+08:00

OpenLaoKe 之前写过一篇，那时候它是个功能堆得特别满但并不太好用的命令行 AI 助手。最开始那会儿是参考 opencode 来做的，想的是不用 npm、不用 Node，直接拿 Python 把这事儿实现出来。因为我自己平时以 Python 为主，也希望所有工具的生态都落在 PyPI 上。 OpenLaoKe 最早脱胎于 2024 年 Clap 项目的一个分支，2026 年 4 月才独立出来。当时就是按 opencode 那种思路来的：工具要多、功能要全。到后面堆了三十多个工具，还塞进了 MCP、子智能体、supervisor、计划模式、权限系统、记忆、双模型协作、一个 Web UI，外加一个 FastAPI 后端。

结果就弄得特别臃肿、特别复杂，调试起来都很麻烦。286 个文件，77955 行——自己想改都得先找半天，改完还常常不知道会不会碰到别的活儿。

最近崔总建议试试 pi。试了之后发现确实非常轻巧简洁，效率更高，尤其是省 token。

我在写 pi 那篇里量过：同样一个任务，opencode 那边每一轮比 pi 多背 5800 多个 token，4 轮下来就多两万多。而且这个差距跟用什么模型没关系——换 deepseek-reasoner 再跑一遍，差的还是那个数。差距是智能体工具带来的常数。

按原来的设计，用 OpenLaoKe 跟模型说话的时候，每一轮请求都要重新发一遍系统提示词、工具定义、技能的元信息。这部分东西跟你的任务没关系，但每一次都要花钱、花时间。功能越全，这份“固定开销”就越厚。

用了 pi 几天之后，我就决定把 OpenLaoKe 整个推倒重写，改成按 pi 的设计来。背后的逻辑很简单：把每一轮都要重复付的那份成本压下去。这不是微优化，是设计上的重构。

这个的代码也依然是开源的，GPLv3 协议，地址在 https://github.com/cycleuser/OpenLaoKe。

安装方法如下所示：

pip install openlaoke
openlaoke

需要 Python 3.12+。

运行效果如下所示：

能够来写 markdown 文档：

也能完成文档翻译的任务：

但如果要做复杂的任务，本地的 2b 小模型就不够用了，建议用更强模型。

改成什么样

全面修改完之后，行数从 7.8 万掉到 1.8 万。

	改造前	现在（0.1.44）
Python 文件	286	68
行数	77955	18253
运行时依赖	一堆	7
工具	30+	8（Windows 上 9）
提供商	一堆	24

砍掉的东西：MCP、子智能体、supervisor、计划模式、权限弹窗、记忆层、insomnia、双模型、自适应路由、防检测层、Web UI、FastAPI 服务、cron、消息总线，还有那个 C 语言翻译版。依赖里也顺手扔了 fastapi、uvicorn、websockets、jieba、watchfiles。

留下的：8 个工具、pi 那 23 个内置命令、树状会话（能 fork / clone / rewind）、prompt 模板、按需加载的技能。还有原来那个内置的 GGUF 推理运行时也删了——本地模型现在统一走 OpenAI 兼容端点，Ollama、LM Studio、vLLM 都行，反而更简单。

对比测试：和 pi 到底差多少

说了这么多改动，总得有点数字。下面这些测试是为这次重构做的，跑的时候是 OpenLaoKe 0.1.40（那会儿还有几个问题没修完）、pi 0.85.1，都在同一台机器上。小模型的数字噪声很大，请当方向性参考，不要当权威结论。

测试环境

项目	值
机器	Apple M4（10 核 CPU），16 GB 内存，macOS
Python	3.12（conda 环境 `dev`）
OpenLaoKe	0.1.40
pi	0.85.1
Ollama	0.34.2，`http://127.0.0.1:11434`
本地端点	`http://127.0.0.1:11434/v1`（OpenAI 兼容）

这个版本号得说清楚：测试是真的在 0.1.40 上跑的，表里所有数字都出自那个版本。后面那些修补是在 0.1.40 到 0.1.44 之间做的，所以现在再去跑，结果大概会比表里好看一些。本文写完时最新版是 0.1.44。

参测的对话模型（都来自本机 Ollama，参数与量化取自 ollama show 原样输出）：

模型	参数	量化	能力
`qwen3.5:2b`	2.3B	Q8_0	completion, vision, tools, thinking
`qwen3.5:0.8b`	873.44M	Q8_0	completion, vision, tools, thinking
`LiquidAI-dev/lfm2.5-2.6b`	2.7B	Q4_K_M	completion, tools, thinking
`LiquidAI/lfm2.5-350m`	354.48M	Q8_0	completion, tools, thinking
`lfm2.5-thinking`	1.2B	Q4_K_M	completion, tools, thinking
`granite4:350m-h`	340.33M	Q8_0	completion, tools

日常真正好用的就是两个 ≥2B 的（qwen3.5:2b、LiquidAI-dev/lfm2.5-2.6b），更小的几个我都删了，表里留的是当时的数据。

一、提供商格式兼容性

这一部分验证的是承载大多数提供商的那两种线协议：Anthropic Messages 和 OpenAI Chat Completions，都做了端到端测试。OpenLaoKe 还原生支持 Google generateContent、AWS Bedrock 和 Cohere，那三种不在这一部分的范围内。

测试	端点	结果
OpenAI 格式，非流式	`POST https://api.deepseek.com/v1/chat/completions`	✅ 返回 `PONG`
OpenAI 格式，流式	同上	✅ 流式返回 `PONG`
Anthropic 格式，真实端点	`POST https://api.anthropic.com/v1/messages`（无效 key）	✅ 请求正确；标准 401 `authentication_error`
Anthropic 格式，完整请求/响应	本地 mock	✅ PASS
本地 OpenAI 兼容	`POST http://127.0.0.1:11434/v1/chat/completions`	✅ 返回 `PONG`

Anthropic 那一项用的是本地 mock，校验的是精确契约，而不只是连通性：

路径必须是 /v1/messages
请求头 anthropic-version: 2023-06-01
请求头 x-api-key
请求体字段 model、messages、max_tokens、temperature、system
响应解析：content[0].text == "PONG"，用量 input=11, output=2

本地端点不再要求 API key：当 base URL 是本地地址（localhost、127.0.0.1、0.0.0.0、::1、host.docker.internal）且没配 key 时，OpenLaoKe 会发一个占位的 bearer token。

二、本地模型能力

每个模型先用一句简单提示走 OpenLaoKe 的 OpenAI 兼容客户端，再走完整的 agent 循环做一个文件任务（“创建 out.txt 内容为 hello pi，然后运行 cat out.txt”）。

模型	非流式	流式	工具调用	备注
`qwen3.5:2b`	✅	✅	✅	综合最好
`qwen3.5:0.8b`	✅	✅	✅	写成 `hello pi.`（多一个句号）
`LiquidAI-dev/lfm2.5-2.6b`	✅	✅	✅	写成 `hello pi.`（多一个句号）
`LiquidAI/lfm2.5-350m`	✅	✅	✅	文件内容正确
`lfm2.5-thinking`	✅	✅	❌	只思考不行动
`granite4:350m-h`	✅	✅	❌	工具调用幻觉报错

纯 embedding 模型（nomic-embed-text、snowflake-arctic-embed、两个 all-minilm、granite-embedding）在 /chat/completions 上被正确拒绝（HTTP 400）——它们本来就不是对话模型，所以不列进来。

这一部分还顺手抓到一个 bug。 Ollama 的 OpenAI 兼容流把思考放在 delta.reasoning，而 DeepSeek 用的是 delta.reasoning_content。OpenLaoKe 原本只读后者，导致思考型模型流式输出全空。现在两个字段都读了。

三、多语言一致性

让两个智能体工具各用 10 种语言回一句“介绍一下你自己”，再对回复做语言分类：按字符脚本判定（Hangul → 韩语，假名 → 日语，CJK → 中文，西里尔 → 俄语），拉丁字母则按停用词特征判断。✅ 表示检测到的语言和请求一致，❌ 表示对不上。

先看 OpenLaoKe 这边：

语言	`qwen3.5:2b`	`qwen3.5:0.8b`	`lfm2.5-2.6b`	`lfm2.5-350m`	`lfm2.5-thinking`	`granite4:350m-h`
中	✅	✅	✅	❌	❌	❌
英	✅	✅	✅	✅	✅	✅
日	✅	✅	✅	✅	✅	❌
法	✅	✅	✅	✅	✅	❌
俄	✅	✅	❌	✅	❌	❌
德	✅	❌	✅	✅	❌	❌
西	✅	✅	✅	✅	✅	❌
葡	✅	✅	✅	✅	❌	✅
意	✅	✅	✅	❌	❌	❌
韩	✅	❌	✅	✅	✅	❌
得分	10/10	8/10	9/10	8/10	5/10	2/10

再看 pi：

语言	`qwen3.5:2b`	`qwen3.5:0.8b`	`lfm2.5-2.6b`	`lfm2.5-350m`	`lfm2.5-thinking`	`granite4:350m-h`
中	✅	❌	✅	✅	❌	❌
英	✅	✅	✅	✅	✅	✅
日	✅	✅	✅	✅	❌	❌
法	✅	✅	❌	✅	❌	✅
俄	✅	✅	✅	✅	✅	❌
德	✅	✅	✅	✅	❌	❌
西	✅	✅	✅	✅	✅	❌
葡	✅	✅	❌	❌	❌	✅
意	❌	✅	✅	✅	❌	❌
韩	✅	✅	✅	✅	❌	❌
得分	9/10	9/10	8/10	9/10	3/10	3/10

那些 ❌ 大致分三种：回了别的语言（比如要求日语却答成中文，或者用英文作答）、干脆空回复、分类器判不出来。

合计：

智能体工具	通过
OpenLaoKe	42/60
pi	41/60

按语言拆开（两个智能体工具合并，满分 12）：

语言	通过	语言	通过
英	12/12	葡	8/12
法	10/12	韩	8/12
西	10/12	德	7/12
日	8/12	中	6/12
俄	8/12	意	6/12

四、具体任务

在两个 ≥2B 的模型上，用两个智能体工具、中英双语跑 5 个具体任务：8 种（智能体工具、模型、语言）组合 × 5 任务 = 40 次。每次运行单独一个目录，输出在 run.log，生成的文件保留原处供人工检查。

任务	指令（中文）	通过条件
T1 精确写文件	在当前目录创建 `hello.txt`，内容正好是 `hello small model`	文件含该文本
T2 读并求和	读 `data.txt`（每行一个整数），求和	答案含 `224`
T3 写+运行	写 `fib.py` 打印前 10 个斐波那契数，并运行	脚本可运行并输出 `0 1 1 2 3 5 8 13 21 34`
T4 生成产物	写 `report.md`，含标题和三条要点	有 `#` 标题且 ≥3 条要点
T5 修 bug	修复 `buggy.py` 中 `average()` 的偏差，并运行	去掉 `+ 1`，输出 `4.0`

结果（✅ = 通过，❌ = 失败）：

智能体工具	模型	语言	T1	T2	T3	T4	T5	得分
openlaoke	qwen3.5:2b	中	✅	✅	✅	❌	✅	4/5
openlaoke	qwen3.5:2b	英	✅	✅	❌	✅	❌	3/5
openlaoke	LiquidAI-dev/lfm2.5-2.6b	中	✅	✅	❌	✅	✅	4/5
openlaoke	LiquidAI-dev/lfm2.5-2.6b	英	✅	❌	❌	✅	✅	3/5
pi	qwen3.5:2b	中	✅	❌	✅	✅	✅	4/5
pi	qwen3.5:2b	英	❌	✅	✅	✅	✅	4/5
pi	LiquidAI-dev/lfm2.5-2.6b	中	✅	✅	❌	✅	✅	4/5
pi	LiquidAI-dev/lfm2.5-2.6b	英	✅	✅	❌	✅	✅	4/5

按任务、按模型、按智能体工具、按语言四个角度看：

按任务	通过	按模型	通过	按智能体工具	通过	按语言	通过
T1 精确写文件	7/8	qwen3.5:2b	15/20	openlaoke	14/20	中	16/20
T2 读并求和	6/8	LiquidAI-dev/lfm2.5-2.6b	15/20	pi	16/20	英	14/20
T3 写+运行	3/8
T4 生成产物	7/8
T5 修 bug	7/8

失败到底错在哪，值得单独说，因为全在模型那边，跟智能体工具没关系：

把 \n 写成字面量。 模型在工具参数里放了两个字符 \ 和 n，而不是真的换行。LiquidAI-dev 多次如此——fib.py 变成单行 print("Fibonacci test")\n，报 SyntaxError: unexpected character after line continuation character。智能体工具只是把模型要求的内容原样写进去。
定义了却不调用。 openlaoke + qwen3.5:2b + 英 + T3 生成了 fib(n) 函数却没调用，跑起来没输出。
复述指令。 pi + qwen3.5:2b + 中 + T2 答的是提示词原文，而不是算出来的和。

另外还有一次 600 秒超时（pi + LiquidAI-dev + 中 + T3）和一次 Python 报错（openlaoke + LiquidAI-dev + 中 + T3）。

按任务看，最惨的是“写脚本并运行”，只有 3/8。这里既要模型产出合法代码、又要它真的去执行，是小模型翻车的重灾区。相对可靠的是精确写文件（7/8）和读文件汇报。

五、本地推理速度

这一部分通过 Ollama 原生 API 测量，它给出纳秒级的 prompt_eval_duration 和 eval_duration。prefill = 提示 token 数 / 预填充耗时，decode = 生成 token 数 / 解码耗时。3 次取中位数，输出上限 128 token。

模型	提示规模	提示 token	Prefill (t/s)	Decode (t/s)	首包 (s)	总时长 (s)
qwen3.5:2b	短	15	142	17.2	0.11	7.72
qwen3.5:2b	中	560	5608	17.5	—	7.41
qwen3.5:2b	长	2210	25188	17.1	—	7.62
LiquidAI-dev/lfm2.5-2.6b	短	17	109	19.1	0.32	6.88
LiquidAI-dev/lfm2.5-2.6b	中	560	3438	18.8	—	6.99
LiquidAI-dev/lfm2.5-2.6b	长	2210	12675	18.8	—	7.03

“首包”指任何类型的第一个流式分片耗时，两个模型都在 0.35 秒内。对思考型模型来说，更该看的是首个可见答案 token 的时间：qwen3.5:2b 把推理放进 thinking 字段，思考结束前 response 一直是空的，所以答案大约在上表那个预算结束时才出现（128 token 上限时约 7.5 秒）；LiquidAI-dev 则把 <think> 标记直接写进 response 流，文字立刻出现，代价是输出里带着思考标记。

几点小结：

Decode 差不多：约 17 t/s（qwen）对约 19 t/s（LiquidAI）。
长上下文下 prefill，qwen 更快：2210 token 时约 25k 对约 13k t/s。短提示的 prefill 数字被固定开销主导，只有中/长才有意义。
响应感上，短提示时 LiquidAI 更好（没有思考延迟），代价是输出里带思考标记。

这些数字说明什么

瓶颈不在智能体工具。 OpenLaoKe（42/60）和 pi（41/60）基本打平，差异在模型噪声范围内。同一个模型在两个智能体工具里表现几乎一致。
模型选择才是决定性的。 qwen3.5:2b 在两个智能体工具拿到 10/10 和 9/10；granite4:350m-h 和 lfm2.5-thinking 都只有 2–5/10。
智能体工具影响的是“身份”，不是语言。 同一个模型在 OpenLaoKe 里答“我是 OpenLaoKe……”，在 pi 里答“我是 Pi Coding Agent……”，说明系统提示词确实生效，但没有改变它回什么语言。
过小的模型不适合 agent 场景。 granite4:350m-h 在 OpenLaoKe 里产生工具幻觉、乱建文件；管道是对的，是模型不行。

也得把局限说清楚：

语言分类器是启发式的。有些 ❌ 其实是混语言回复或者分类边界，不一定是硬失败。
每格只跑了 1 次。小模型本身随机性大，重跑会移动个别格子。
两处异常：pi + qwen3.5:0.8b + 中文 超时 420 秒（空回复）；openlaoke + granite4:350m-h + 中文 空回复。
对所有模型，英文都是最强的，中文和意大利语最弱。这是模型属性，跟两个智能体工具无关。

额外的一些废话

这轮折腾下来，我最大的感受是智能体工具的“聪明”要用对地方。

重构本身其实不算难，难的是改完之后跟本地小模型磨合的那几天，一路上碰到一堆乱七八糟的麻烦：有的命令明明只是看看系统信息，却被当成危险命令拦下来；工具列表不看平台就一股脑全给模型，结果在 macOS 上塞了个 PowerShell 进去；模型名里带个斜杠也能被解析吃掉；小模型明明乖乖回了工具调用，反倒被判成“没有输出”。还有几处是我自己给自己挖的坑，比如上下文预算从官方目录里取了个理论值，对着本地服务根本对不上；又比如默认放开让思考型模型去想，结果一轮就卡在那儿不动。

这些毛病有个共同点：在云端和“乖”的模型上不显山不露水，一旦换成小模型、换成本地，全都会变成绊脚石。 而其中一部分，纯粹是我自作聪明的结果——以为从官网目录读窗口比硬编码强，却没分清“模型能支持多大”和“服务器实际给多大”根本不是一回事。改进之前，得先弄清楚你改的是不是同一个东西。

至于和 pi 的差距，我觉得很正常。pi 是 Mario 写了很久的原版，我这是照着重写一遍。多语言打平、具体任务差 2 分，这个成绩我觉得可以接受，剩下的差距主要在细节打磨上。

说句实在的，本地小模型这条路，智能体工具能帮你的有限。工具调用链路我可以修得干干净净，但“读一周的代码然后总结”这种活，2B 模型是真干不了；翻译一整篇文章，它会直接照抄原文。想让本地模型干正事，起码上到能用的量级——我这里就是 qwen3.5:2b 和 lfm2.5-2.6b 这两个，更小的我试过，有时候可能会连工具调用都带不动。

不用显卡就能运行的本地小模型能做啥-用 pi 实测两个 2B 模型的工具调用与真实任务

2026-09-19T07:30:00+08:00

我手里这台机器是 Apple M4，10 核 CPU，16 GB 内存。这种配置想跑本地大模型，要想不影响其他工具的日常运行，就不能全都跑慢，粗略估计适合在 0.5B 到 3B 这个区间里挑。我之前也一直用小模型，不过大多是在聊聊天、写写摘要。真正让一些同学好奇的是另一件事：这种小模型，能不能当 coding agent 用，也就是会不会调用工具、能不能完成一个具体的小任务。

所以这回咱们来实测一轮。这篇文章里的数字都是我自己在这台机器上跑出来的，不是抄的榜单。

先说清楚被测的两个模型

本机 Ollama（0.34.2）里我留了两个 2B 级别、且支持工具调用的模型：

模型	参数	量化	能力
`qwen3.5:2b`	2.3B	Q8_0	completion, vision, tools, thinking
`LiquidAI-dev/lfm2.5-2.6b:latest`	2.7B	Q4_K_M	completion, tools, thinking

（参数和量化都是从 ollama show 原样抄的，不是我估的。）

之前我还试过更小的几个：350M 的、0.8B 的，结论很直接——太小的一是根本带不动工具调用，二是太小了容易幻觉起飞甚至随时乱编。所以最后就留了这两个 2B 以上的。

用 pi 来测

工具调用这种能力，光让模型"聊天"是测不出来的。必须有一个外壳把工具定义发给它、解析它的工具调用、真正去执行，才算数。我用的是 pi（Mario Zechner 写的极简终端 agent）。

pi 的接法很简单：在 ~/.pi/agent/models.json 里声明一个 OpenAI 兼容的提供方指向本机 Ollama，然后：

pi -p --provider ollama-local --model <模型> "你的指令"

为了测的干净，我把技能、扩展、上下文文件全关掉，只留最核心的 agent 循环和工具（read、write、edit、bash 等）。这样测出来的就是模型本身，而不是各种插件带来的加成。

关于 SOTA 榜单：小模型在这个维度确实吃亏

开始之前先说个背景。公开评测里，衡量"会不会用工具、听不听话"这类能力的标准集主要有这几套：

Berkeley Function Calling Leaderboard (BFCL)：伯克利做的函数/工具调用榜，是目前最直接衡量工具调用能力的评测（gorilla.cs.berkeley.edu/leaderboard.html）。
IFEval：指令遵循评测（Zhou et al., 2023, arXiv:2311.07911）。
τ-bench：真实业务场景下的工具-agent 评测（Yao et al., 2024, arXiv:2406.12045）。
MMLU / GSM8K / HumanEval：分别是综合知识（arXiv:2009.03300）、数学推理（arXiv:2110.14168）、代码生成（arXiv:2107.03374）的经典基准。

这些榜单上排前面的基本都是几十 B 甚至上百 B 的模型。2B 级别在这些维度上普遍靠后，尤其是需要多步规划、格式严格的任务。所以下面的实测结果，你可以当作"低配机器上小模型的真实上限"来看。

本次具体测了什么

我给两个模型、中英双语，各安排了 5 个任务，一共 20 次运行。每跑一次，模型生成的原始文件我都留在单独目录里，方便事后人工翻看。

这 5 个任务是这样：

任务	指令	判定标准
T1 精确写文件	创建 `hello.txt`，内容正好是 `hello small model`	文件里有这句话
T2 读并求和	读 `data.txt`（每行一个整数），求和	答案出现 224
T3 写+运行	写 `fib.py` 打印前 10 个斐波那契数，并运行	脚本能跑，输出 `0 1 1 2 3 5 8 13 21 34`
T4 生成产物	写 `report.md`，标题加三条要点	有标题且至少三条要点
T5 修 bug	修掉 `buggy.py` 里平均值多加了 1 的 bug，并运行	去掉 `+ 1` 且输出 4.0

结果

先看任务维度：

任务	通过
T1 精确写文件	3/4
T2 读并求和	3/4
T3 写+运行	2/4
T4 生成产物	4/4
T5 修 bug	4/4

再看模型和语言：

维度	结果
`qwen3.5:2b`	8/10
`LiquidAI-dev/lfm2.5-2.6b`	8/10
中文	8/10
英文	8/10

两个模型完全打平，中英文也没有差别。总共 20 次里过了 16 次。样本不大，但方向很清楚：单步任务基本能过，T3 这种"写代码再运行"的是重灾区。

真正有意思的是它们错在哪

跑完看生成的原始文件，失败方式非常集中，而且很"小模型"：

一、把换行写成了字面量 \n。 这是最典型的。模型在工具参数里放的不是真换行，而是反斜杠加字母 n 两个字符。LiquidAI 尤其容易这样，它写的 fib.py 整份文件就一行：

print("Fibonacci test")\n

拿去运行直接报 SyntaxError: unexpected character after line continuation character。注意这不是 pi 的错——外壳只是把模型要求的内容原样写进文件。是模型自己没分清"内容里的换行"和"转义后的文本"。四次 T3 里，LiquidAI 的两次全栽在这上面。

二、没读文件，凭自己编数据。 有一次让它读 data.txt 再求和，结果它没去读，直接给了个"100 + 200 + 300 = 600"。文件里根本没有这些数，正确的是 224。这种错最危险，因为它答得很自信、格式也漂亮，你不去核对根本发现不了。

三、写错路径还谎报成功。 还有一次让它把文件写到当前目录，它把文件写到了根目录的 /hello.txt（只读文件系统，其实失败了），然后回复说"文件已成功创建"。它报告的成功是假的。

说白了：写文件基本没问题，读文件汇报也一般没问题，但只要进入"写完还得运行"这一步，就崩了——因为它得先通过工具调用吐出一份语法完全正确的代码，再让系统执行，中间任何一个字符错位，整件事就废了。

顺带测了速度

既然是低配机器，速度也是关键。我用 Ollama 原生接口，它返回纳秒级的预填充（prefill）和解码（decode）耗时，比拿总时间除一下准得多。3 次取中位数，输出上限 128 token。

模型	提示规模	Prefill (t/s)	Decode (t/s)	首包延迟
qwen3.5:2b	短 15 token	142	17.2	0.11s
qwen3.5:2b	长 2210 token	25188	17.1	—
LiquidAI-dev/lfm2.5-2.6b	短 17 token	109	19.1	0.32s
LiquidAI-dev/lfm2.5-2.6b	长 2210 token	12675	18.8	—

几个观察：

解码速度差不多，都在 17 到 19 t/s。这个速度写代码是慢的，但应付短任务够用。
预填充 qwen 明显更快，长上下文下差不多是 LiquidAI 的两倍（25k 对 12.7k t/s）。提示越长，这个差距越值钱。
短提示那行的 prefill 数字别当真，全被固定开销盖住了，只有中长提示才有参考意义。
首包延迟两个都快（0.1 到 0.3 秒），但这里有个坑：qwen3.5:2b 是思考型模型，它把推理先写进单独的 thinking 字段，response 一直空着，所以你要等到它"想完"才看到正文。实测在 128 token 上限下，第一个可见的答案 token 差不多要到 7.5 秒才出现。LiquidAI 反过来，把 <think> 标记直接写进正文流里，文字立刻就有，代价是输出里混着思考标记。

所以论"聊天时的即时手感"，LiquidAI 更跟手；论"长提示的处理速度"，qwen 更快。

那本地小模型到底适合干什么

测完我的结论是：别拿这种2B小模型当可以完全依赖的 coding agent，但把它当"本地小助手"用，还是有价值的。

适合的：

短文本的翻译、改写、摘要（其实还是以前我就常用的场景）。
单步的文件操作：读一个文件、写一个文件、改一行、算个数（注意有可能会有错，要有核验环节）。
结构简单的指令，比如"把这份 CSV 转成 Markdown 表格"。
要绝对本地、绝对不联网的场景，哪怕结果粗糙也能接受。
离线、断网、或者不想把数据发出去的时候做个兜底。

不适合的：

多步任务，尤其是"写代码再运行"这种带反馈闭环的。
需要严格格式的任务（JSON、复杂 Markdown），它们动不动就把换行写成 \n。
任何需要读取真实数据再作答的任务——它会直接编。
任何你没法一眼看出对错的输出。

真要在这台机器上稳定跑 agent，我的建议还是拉一个 4B 到 8B、且明确支持 tools 的模型。2B 这个级别，能跑通简单的单步任务，但别指望它扛复杂流程。

最后扯几句

说句实在的，小模型这几年的进步是看得见的，2B 能做到今天这样，放在两年前不敢想。但它跟"能帮你干活的 agent"之间，还差一些，这道坎不仅仅体现在参数量的绝对值上，而更多事在多步任务的稳定性上——单步它行，一旦要连着做两三步、还要根据中间结果调整，就很容易散架。

特别值得警惕的是那两类"看起来很对"的错：一种是编数据（100+200+300=600），一种是谎报成功（写到只读路径还说建好了）。这两类错不会报错、不会崩，但会实打实地误导你。所以我一直强调，用任何模型做 agent，最终判断权都得留在人手里。

低配机器上跑本地小模型，是个有趣的、也能干点事的小工具，但如果需要可靠的开发伙伴，建议还是要9b起步。

测试环境：Apple M4（10 核 CPU），16 GB 内存，macOS；Ollama 0.34.2；pi 0.85.1。所有数字均为本机实测。

pi 是个啥-能被你自己改造的终端编程助手以及它和 opencode 的区别

2026-09-18T21:40:00+08:00

我平时用 opencode 挺多的，用得也算顺手。前一阵子崔总跟我说，建议也试试 pi 吧。我一开始还纳闷，pi 是个啥东西，没听说过。装上一看才明白，它跟 opencode 是同一类东西，都是跑在终端里的 AI 编程助手，但这两个家伙的脾气完全不一样。

这篇文章就说说 pi 是啥、怎么用，以及它和 opencode 到底差在哪。我尽量按自己用下来的实际感受写，不吹也不黑，讲错了的地方欢迎指出来。

pi 是个啥

pi 的全名是 @earendil-works/pi-coding-agent，作者是 Mario Zechner，也就是当年写 libGDX 的那个 badlogic。官网是 pi.dev，MIT 协议，用 TypeScript 写的，跑在 Node 上，要求 Node 22.19 以上。我装的时候是 0.85.1。

它给自己的定位是 minimal terminal coding harness，直译就是"极简的终端编程外壳"。注意它说的是 harness，外壳，不是 framework，也不是 platform。意思很清楚：它只管最核心的那点事，剩下的都留着让你自己加。

默认情况下，pi 只给模型四个工具，read、write、edit、bash，另外还有 grep、find、ls 这些查东西用的。就这些。你让它干活，它就靠这么几个工具去干。

最有个性的地方，是它故意不做很多东西。官方文档里说得很直白：

No MCP. No sub-agents. No permission popups. No plan mode. No built-in to-dos. No background bash.

翻译过来就是：没有 MCP、没有子智能体、没有权限弹窗、没有计划模式、没有内置待办、没有后台 bash。

这几样东西，在 opencode 里基本都有。pi 的态度是，你要你就自己搭，或者装别人写好的包，别指望我塞给你。

我刚看到这段的时候，第一反应是，这不等于啥都没有吗。后来用了一阵子才转过弯来，它不是没有，是把这些都做成了"可选"，而不是"必须"。内核小，改起来就方便，这跟 opencode 那种"开箱即用"是两个路子。

怎么装、怎么跑起来

安装有两种方式，一种是 npm，一种是官方脚本。npm 这种：

npm install -g --ignore-scripts @earendil-works/pi-coding-agent

那个 --ignore-scripts 是官方特意让加的，因为 pi 正常安装不需要跑依赖的安装脚本，加上这个更安稳。

如果你更喜欢脚本，也可以：

curl -fsSL https://pi.dev/install.sh | sh

装完要配一个模型。最省事的是设个环境变量：

export ANTHROPIC_API_KEY=sk-ant-...
pi

或者不设环境变量，直接敲 pi 进去，再用 /login 选提供商：

/login

然后就能用了。在终端里敲 pi，进去就是交互界面，直接跟它说话就行，跟 opencode 一样，没什么学习成本。

日常怎么用

进到界面里，编辑框有几个用法挺顺手。输入 @ 可以模糊搜项目里的文件，Tab 补全路径，Shift+Enter 换行。想用外部编辑器按 Ctrl+G。要贴图直接 Ctrl+V，或者把图片拖进终端。还有个我觉得挺方便的，输入 !command 能把命令跑掉、把结果发给模型，!!command 则是跑掉但不发给模型。

输入 / 会弹出命令。常用的有这些：

命令	干嘛的
`/login` `/logout`	管提供商的登录
`/model`	换模型，选的时候按 Ctrl+S 存成默认
`/thinking`	换思考档位，同样能 Ctrl+S 存默认
`/settings`	主题、消息投递、传输方式这些设置
`/resume`	从之前的会话里挑一个继续
`/new`	开新会话
`/tree`	跳到会话的任意一点，从那儿接着往下
`/fork` `/clone`	从某条消息分叉、或者复制当前分支
`/compact`	手动压缩上下文
`/export` `/import`	导出、导入会话
`/share`	传成私有 gist，给一个能看的网页链接
`/hotkeys`	看所有快捷键

快捷键里，Ctrl+L 换模型，Shift+Tab 切思考档位，连按两下 Escape 打开 /tree，Ctrl+O 折叠工具输出，Ctrl+T 折叠思考块，连按两下 Ctrl+C 退出。

还有个小细节，pi 支持消息排队。它正在干活的时候，你按 Enter 发的是"引导消息"，等它这一轮工具调用跑完就插进去；按 Alt+Enter 发的是"后续消息"，得等它彻底干完才发。这个在多轮任务里挺有用，不用干等着。

会话能长成一棵树

这块是 pi 我觉得最好玩的地方。

它的会话存成 JSONL 文件，而且里面的结构是树，每条记录有 id 和 parentId。好处是，你可以在同一个文件里原地分支，不用另开文件。

比如你聊着聊着发现前面某步走歪了，按 /tree 就能把整个会话树调出来，跳到那个点，从那儿重新走下去，两条分支的历史都留着。/fork 是从某条消息分出一个新会话文件，/clone 是把当前分支整个复制一份。

命令行里也能干这些事：

pi -c                  # 继续最近一次会话
pi -r                  # 浏览挑一个历史会话
pi --no-session        # 临时模式，不保存
pi --name "my task"    # 起个名字
pi --fork <path|id>    # 从某个会话分叉出来

上下文快满了怎么办？pi 有压缩，叫 compaction。手动是 /compact，自动默认也开着，快满了会自己总结前面的内容。要说明的是这个压缩是有损的，前面的细节会被总结掉，但完整历史还在 JSONL 里，想翻旧账用 /tree 回去看就行。

模型和提供商

pi 支持的提供商不少。订阅类的可以接 Claude Pro/Max、ChatGPT Plus/Pro 的 Codex、还有 GitHub Copilot。API key 类的就更多了，Anthropic、OpenAI、Google、DeepSeek、Mistral、Groq、xAI、OpenRouter、Kimi、MiniMax 一大堆。

换模型就 /model，选中了按 Ctrl+S 能存成默认。命令行里可以用 --list-models 列出来，用 --models 指定一批给 Ctrl+P 循环切换，像我这样经常换模型的人挺方便。

它还内置了 llama.cpp 的路由服务，/login llama.cpp 配上，再用 /llama 下模型、加载模型，本地跑也行。

有意思的是，pi 的提供商列表里居然还有 OpenCode Zen 和 OpenCode Go。也就是说，你可以用 pi 这个客户端，去连 opencode 家的模型服务。

如果你要接的是那种 OpenAI、Anthropic、Google 格式的自定义服务，可以在 ~/.pi/agent/models.json 里加。要是碰到非标准 API 或者要 OAuth，那就得写扩展了。

四件套和包

pi 的定制，主要靠四样东西，官方叫 prompt templates、skills、extensions、themes。

prompt templates 就是把常用提示词存成 Markdown，放到 ~/.pi/agent/prompts/，用的时候输入 /名字 就展开了。

skills 是技能，跟 opencode 用的是同一套 Agent Skills 标准，放在 ~/.pi/agent/skills/ 或者 ~/.agents/skills/。用的话输入 /skill:名字，或者让模型自己按需加载。这点挺省事的——我把同一套技能，同时装给了 opencode 和 pi，两边都能用，不用维护两份。（顺带说一句，pi 也能直接加载 ~/.claude/skills、~/.codex/skills 这些别的工具的技能目录，在 settings 里配上就行。）

extensions 是扩展，用 TypeScript 写。这个是 pi 的重头戏。它能加自定义工具、加命令、加键盘快捷键、拦事件，还能改 UI，甚至连内置工具都能整个换掉。官方示例里连 Doom 都给塞进去了，等模型干活的时候打游戏。前面说的那些"pi 故意不做"的功能——子智能体、计划模式、权限闸门、MCP 支持——理论上都能用扩展自己搭出来。

themes 是主题，改完直接热加载，不用重启。prompt template、skill、extension、theme 这四样，加上包管理，合起来就是 pi packages。可以打包成 npm 包或者 git 仓库分享给别人：

pi install npm:@foo/pi-tools
pi install git:github.com/user/repo
pi list
pi update --all
pi config        # 在 TUI 里开关各个包资源

除了交互模式，还能当积木用

pi 不只是个给人用的 TUI，它还有几种程序化的用法。

比如打印模式，跑完就退，适合写脚本：

pi -p "总结一下这个代码库"
cat README.md | pi -p "把这段文字总结一下"

再比如 JSON 模式，所有事件按 JSON 行输出，方便别的程序解析；还有 RPC 模式，走 stdin/stdout，给非 Node 的进程集成用。最后它本身就是个 SDK，可以在自己的 TypeScript 程序里直接把它嵌进去：

import { createAgentSession, ModelRuntime, SessionManager } from "@earendil-works/pi-coding-agent";

要让它遵守项目里的规矩，就在项目根目录放个 AGENTS.md（或者 CLAUDE.md），pi 启动会自动读。想整个换掉系统提示词，用 .pi/SYSTEM.md。

pi 和 opencode 有啥不一样

说到这儿，可能有人会问，那它跟 opencode 到底选哪个。我先把两边的主要区别摆出来，都是我自己用下来加上看文档整理的。

方面	pi	opencode
定位	极简内核，自己拼	功能齐全，开箱即用
出身	Mario Zechner（badlogic）	SST 团队
子智能体	没有，自己搭	有，主/子 agent
MCP	没有，写扩展加	有
计划模式	没有	有
权限弹窗	没有	有权限配置
扩展方式	TypeScript 扩展	插件 + 配置 + 命令 Markdown
会话	JSONL 树，原地分支	会话 + 分享 + 回退
形态	终端 TUI + 库	TUI + 服务端 + 网页 + 桌面端
集成	SDK / RPC / JSON	ACP / MCP / GitHub / serve / attach
技能	Agent Skills 标准	Agent Skills 标准

差别最大的，我认为是思路。opencode 是"我都给你配好，你直接用"，它有子智能体、有 MCP、有权限控制、能起服务端、有网页和桌面端、还跟 GitHub 打通，能 opencode github、opencode pr 直接拉 PR。功能面铺得很宽。你可以把它当成一个完整的开发平台来用。

pi 反过来，它相信"你不想要我强塞的东西"。核心就四个工具，剩下的全靠扩展和包。你不动手，它就是个很小的终端助手；你愿意折腾，它能被改成任何样子，而且不用去 fork 它的源码。

会话这块是 pi 的强项。它的树状会话和原地分支，用起来比一般工具的"线性历史"灵活，尤其是那种试错很多的任务。

隐私和安全上，得说两句实在话。pi 明确没有权限弹窗，官方建议是要么在容器里跑，要么自己用扩展写确认流程。扩展和技能又是能执行任意代码的，第三方包一定要先看看源码再装。opencode 这边至少有权限配置这一层，你可以把危险的 bash 命令设成要确认或者直接拒绝。这两点在取舍上得想清楚。

做了个对照实验，看看谁快

前面说 pi 手感快，这只是感觉，不算数。所以我认真做了一组对照实验，想看看差距到底从哪来。

条件尽量卡平：同一个模型（DeepSeek 的 deepseek-chat，两边都直连官方接口），同一个任务——目录里放一个算平均值的 buggy.py，让它读文件、找 bug、修好、跑一遍，把结果告诉我；每次都在全新的空目录里跑。为了排除干扰，我把 pi 的技能、扩展、上下文文件全关掉，opencode 那边用一个只留 provider 的最小配置，两边各跑 4 次取平均。

这里说的"快"，用的是墙钟时间，也就是从敲下回车到它彻底干完，现实中真实等了多久。这个数里包含启动、把提示词发给模型、模型生成，还有它读文件、改文件、跑命令的全过程，跟咱们的体感一致。

结果是这样：

指标	pi	opencode
总耗时	4.40 秒	7.32 秒
第一轮模型响应	0.60 秒	4.33 秒
输入 token	809	6310
缓存读 token	6016	23936
输出 token	289	231
总 token	7114	30477
工具调用 / 模型回合	3 / 4	3 / 4
正确率	4/4	4/4

两边干的活一模一样，都修对了，工具调用和回合数也一样。但你看输出 token，289 对 231，基本是一个量级——说明模型"想"和"说"的量差不多。差的全在输入这一侧：opencode 每一轮背的上下文，差不多是 pi 的 4 倍。

这 4 倍是哪来的？我单独测了一句废话"只回复 ok"，不触发任何工具：pi 是 1515 个 token，opencode 是 7333 个。一上来 opencode 就多背了将近 6000 token。原因也不神秘，它的内置工具多（read、edit、write、bash、glob、grep、list、patch、task、todowrite、webfetch 一大堆），每个工具的定义都要发给模型，再加上它内置了好几套 agent 的系统提示词。pi 默认就四个工具，提示词也短。

输出差不多、输入差很多，意味着时间差主要花在"把上下文喂给模型"这一步，也就是预填充和网络传输，而不是模型在思考。

技能装得越多，差距会怎么变

这才是有意思的地方。pi 和 opencode 都遵循同一套 Agent Skills 标准，技能的名字和描述都是常驻在系统提示词里的（正文要按需才读）。那技能一多，两边的差距会不会被拉大？

我用统一规格的技能做了个扫描，还是测一句"ok"的输入 token：

技能数	pi	opencode
0	1515	7333
10	3659	9443
43	10490	16406
100	22289	28433
200	42989	49533

把它拟合成一条直线，能看出：

pi：成本 ≈ 1561 + 207 × 技能数
opencode：成本 ≈ 7333 + 211 × 技能数

关键结论是：每装一个技能，两边增加的开销几乎一样（207 对 211），差距全在起跑线上那个固定的 5800。 技能本身不是差距来源，基线才是。所以技能越多，opencode 的相对劣势反而越小，但绝对差距基本卡在 5800 上下不动。

拿我自己那套 43 个技能来说：pi 一个请求 15051 token，opencode 20256。跑一个 4 轮的编码任务，总 token 是这样：

技能数	pi 总 token	opencode 总 token
0	7171	30541
43（真实）	61284	82175
200	168290	194595

这里得划个重点：技能数会把每个任务的 token 成倍放大，因为每一轮都要把完整上下文重发一遍。 43 个技能就把一个 4 轮任务从 7 千 token 顶到了 6 万（pi）。公式大概就是：任务总 token ≈ 回合数 × (基线 + 210 × 技能数)。所以真要省钱，最有效的不是换工具，而是把技能精简掉——这一条对 pi 和 opencode 都成立。

换个模型会变吗

我又用 deepseek-reasoner（带思考的那个）测了一遍。结论是：换模型不改变两边的固定差距。opencode 不管用 chat 还是 reasoner，每个任务都稳定地比 pi 多背两万多 token，正好是 4 轮乘以那个 5800 的基线差。差距是壳带来的常数，不是模型带来的。

启动速度也顺带量了：pi 冷启动约 0.44 秒，opencode 约 0.75 秒。不过真正让 opencode 显慢的，是第一轮那个大上下文，不是这零点几秒。

所以"pi 快一些"这事，拆开看其实很朴素：它省的是那个固定的上下文基线，不是它有什么更快的引擎。 输出和回合数两边一样，说明模型那一侧是同一个东西；差的只是每一轮要背多少包袱。

当然，这个实验也有局限，我得说清楚：样本不大（各 4 次），而且我把两边都调成了最小配置。你真实用起来，opencode 还会加载 agent、规则这些，盘子只会更大；pi 的技能是描述常驻、正文按需，涨得慢一些。数值会变，但"pi 省在固定基线、技能对两边等价"这个结论不会变。

我的一些看法

要我说，这俩不是非要二选一。

如果你想要一个东西，装上就能干活，功能越全越好，团队里还要统一管控权限，那 opencode 更合适。它有子智能体、有 MCP、有权限这一套，拿来就能用。

如果你跟我一样，喜欢把工具拆开看、按自己习惯组装，还经常写点小脚本小扩展，那 pi 会让你觉得很舒服。它内核小，改起来不费劲，出了什么问题也容易看明白。而且它是认真在做"可扩展"，不是嘴上说说。

我用下来的感觉是，平时常规的写代码、改代码、跑命令，两个都能干，差别不大。真到了要分支探索、要接一堆自定义流程的时候，pi 的树状会话和扩展能力就显出好处了。反过来，要做那种需要子智能体分工、需要连 MCP 服务、需要团队权限管控的活，opencode 更省心。

还有个我挺喜欢的地方，是这两个工具并不互斥。技能是同一套标准，模型服务也能互相用（pi 能连 opencode 的 Zen/Go），会话也各管各的。完全可以两个都装着，看当天想干什么就用哪个。

最后

说句实在的，pi 这种"故意少做"的工具，一开始会让人有点不习惯，觉得啥都得自己来。但用久了会发现，正是因为它肯把决定权留给你，才没那么多"它以为你需要"的东西。

当然，天下没有免费的午餐。东西越少，你要自己补的就越多；权限没有弹窗，出了事也得自己担着。所以装第三方扩展之前，多看一眼代码，这个习惯一定要有。

想试试的话，官网是 pi.dev，源码在 GitHub 上（earendil-works/pi），npm 包名是 @earendil-works/pi-coding-agent。我这边是 0.85.1，opencode 是 1.18.31，上面说的都是这个版本的实际用法，后面版本要是有变化，以官方文档为准。

8G 显存怎么跑本地大模型？——从 RTX 2060 到 4070 的极限压榨实录

2026-09-18T21:30:00+08:00

8G 显存怎么跑本地大模型？

16G 显存的取舍我写过一篇，这回把档次再往下压：手里只有一张 8G 的卡——RTX 3070、4060、2060 Super，或者 4070 Laptop 这种 8G 笔记本——还能不能跑本地大模型？技术上能跑，甚至能跑 35B；但"能跑"和"好用"之间隔还是有点远啊。本文全部数据来自真实实测，出处见文末。

一、先摆结论：8G 能跑 35B，但别高兴太早

先说反直觉的部分：8G 显存跑 35B 大模型，是可行的。论坛里至少四张不同的 8G 卡（3070、4060、2060 Super、4070 Laptop）都成功跑起了 Qwen3.6-35B-A3B，速度从 17 t/s 到 42 t/s 不等，甚至有人把 35B 塞进了 8G 笔记本还开出 128K 上下文[1][2][3][4]。

但同一批帖子里，楼主自己的评价是这样的：

"编码可以跑。能处理图片。其他的拉稀中。总结：学习机小拉拉一枚。"[1]
"这个小拉拉实际应用没有任何意义。或者直白点就是 8G 就是没什么意义。我的任意项目它都是跑不了的。"[1]
"8G 的卡只能是跑起来而已，用来驱动 agent 几乎不可用的。"[3]

为什么会有这种分裂？ 因为 8G 的瓶颈从来不是"装不装得下模型"，而是预填充（prefill）速度。日常聊天、短代码问答，体验尚可；一旦接上 Agent（比如 Hermes），系统提示词动辄 20K+ token，8G 卡的 prefill 就会慢到让人失去耐心[3]。

所以本文的正确读法是：8G 能带你入门、能跑通、能理解参数，但它不是生产力工具的上限，而是一个"折腾甜点"。

二、核心原理：MoE + CPU Offload 是 8G 的救命稻草

8G 能跑 35B，靠的不是什么黑科技，而是架构红利：

Qwen3.6-35B-A3B 是混合专家模型（MoE）：35B 总参数，但每次推理只激活约 3B 参数[1]。这意味着 GPU 不需要一次性加载完整的 35B 权重。

再叠加 llama.cpp 的两个能力：

CPU Offload（-ngl）：控制多少层放 GPU，其余放内存；
MoE 专家路由（--n-cpu-moe）：把非激活的专家层丢到系统内存，GPU 只保留注意力层和少量专家[2]。

于是形成"GPU 跑注意力层、内存跑专家层"的分工——这才是 8G 卡能跑 35B 的核心原因[1]。代价是：速度上限被内存带宽锁死，因为每生成一个 token 都要从内存里搬专家权重。

反过来说：如果你用的是同尺寸的稠密（Dense）模型，比如 27B 稠密，那 8G 基本没戏——Q4 量化后权重就要 15GB 以上，根本放不下，硬 offload 会慢到不可用[5]。

三、模型怎么选：35B-A3B MoE，还是退一步用 9B

8G 上有两条路线，选哪条取决于你要干什么。

路线一：35B-A3B MoE——"能跑大模型"的执念

这是论坛里 8G 玩家最热衷的方向，因为"8G 跑 35B"本身就有巨大的心理满足感。实测也确实能跑：

RTX 3070 8G + i7-12700，Q4_K_M 量化，-ngl 99 --n-cpu-moe 999，32K 上下文，还支持多模态和网页 UI[1]
RTX 4060 8G + R7 5700X，APEX-MTP 量化（13.7GB），-ngl 999 --n-cpu-moe 32，64K 上下文，短输出 30+ t/s、代码场景 45-50 t/s[3]
RTX 4070 Laptop 8G，Q4_K_M，短文本 42.3 t/s、Thinking 模式 42.1 t/s，一键包支持 128K + 多模态[4]

路线二：9B 级稠密模型——"真的好用"的务实选择

论坛里不止一个人劝退"8G 硬上 35B"：

"4060 还是玩 9B 吧……跑起来还快点。"[3]

在工具调用（function calling）这个对 8G 最关键的场景里，有会员给出了明确建议[5]：

8G（4070）：27B 的 Q4 要 15G 以上，放不下。8G 实际能打的是 Qwen3-8B、GLM-4-9B（同尺寸里工具调用很强）、Gemma3-12B Q4 勉强压线。别为了"跑大模型"硬上 27B 的低量化档——如果只是翻译或者写文本倒是无所谓了，但工具调用对量化损伤很敏感，降档后 function call 格式会先崩。

这句话很关键：Agent 场景下，"小模型满精度"往往打得过"大模型低量化"。因为工具调用要求模型稳定输出 JSON schema，低量化会先破坏这种结构化输出能力。

四、量化怎么选：8G 的量化比 16G 更极端

8G 上量化档位的选择空间比 16G 窄得多，但方向是一致的——找到能全层上卡、又不至于把质量整崩溃的那一档。

论坛实测过的几档（35B-A3B）：

量化	大小	8G 卡适配情况	出处
Q4_K_M	16.5 GB	权重就超 8G，必须重度 offload，能跑但吃力	[1][4]
APEX-MTP-I-Mini	13.7 GB	4060 上 30+ t/s、代码 45-50 t/s，8G 的"毕业配置"	[3]
APEX-I-Quality	~16.8 GB	异构多卡（12G+8G）上 prefill 1279 t/s、decode 88.8 t/s	[6]
IQ2_M	最小	2060 Super 上唯一能稳定跑 8K 上下文的档位，~17 t/s	[2]
Q3_K_XL	~16.8 GB	需要 24G 以上才舒服，8G 上偏重	[3]

几个结论：

8G 上"精度换速度"是刚需。16G 上还能讲究 IQ4_XS 全层上卡，8G 上往往要一路降到 APEX/IQ2 级别，甚至接受"模型智商明显下降"[2]。
APEX 量化是 8G 的惊喜。它把 35B 压到 13.7GB，配合 MTP（多 token 预测）能在 4060 上跑出 30+ t/s，被社区称为"8G 显存的毕业配置"[3]。
别迷信低量化能救一切。IQ2_M 虽然塞得下，但作者自己也说"完全没有意思""硬件限制上不到 16K"[2]——量化降到这个程度，模型能力已经受损。

五、关键参数：`--n-cpu-moe` 和 `-fit off`

8G 跑大 MoE 模型，参数比模型更重要。论坛里一份"极限参数定稿报告"把调参过程完整记录了下来，非常有参考价值[2]：

阶段 1：默认参数（失败）

-ngl 80 -c 4096

现象：显存逼近 8G 爆满，报 failed to fit params to free device memory，llama.cpp 自动回退，速度断崖式跌到 ~7.5 t/s。

阶段 2：开启 MoE 专家路由（部分改善）

-ngl 80 --n-cpu-moe 38 -c 4096

显存降到 ~2.5G（异常偏低），速度 ~15 t/s。问题：GPU 层数被削太狠，大量权重滞留内存，瓶颈变成内存带宽。

阶段 3：强制显存适配 + 降 GPU 层数（关键突破）

-ngl 30 --n-cpu-moe 20 -c 4096 -fit off

显存 6.8G / 8G（余量 1.3G），速度 ~15 t/s。-fit off 关闭自动适配后，30 层权重成功驻留显存，进入甜点区。

阶段 4：上下文扩容（最终定稿）

-ngl 30 --n-cpu-moe 20 -c 8192 -fit off

显存 7.0G / 8G（余量 1.1G），速度 ~17 t/s。上下文翻倍，显存只多 200MB，速度反而微升。

这份报告的核心经验[2]：

--n-cpu-moe 是 8G 卡跑大 MoE 的核心参数，负责把非激活专家路由到内存；不能无脑 -ngl 80，要配合 -fit off 手动控制显存分配。
显存甜点区是 6.5G ~ 7.2G：低于 6G，GPU 层数不足、速度受限；高于 7.5G，余量不够，Windows 的 WDDM 驱动一波动就爆显存、速度断崖。
Windows 的可用显存要比标称少：标称 8192 MiB，实际空闲只有 7158 MiB；同配置在 Linux 下预计能多出 500MB~1G，有望稳定 16K 上下文[2]。
上下文和速度不总是负相关：4K→8K 速度从 15 微升到 17 t/s，因为 4K 时 GPU 利用率没吃满，8K 反而让流水线更饱和[2]。
Thinking 会偷偷吃掉 token：复杂 prompt 容易陷入长推理，建议前端加约束"请直接回答，不要输出思考过程"[2]。

另外，KV 缓存量化也是 8G 的必备技巧：--cache-type-k q4_0 --cache-type-v q4_0 能大幅省显存换上下文[1]；如果显存还有余量，用 q8_0 质量更稳[3]。

六、实测数据的真实表现

把论坛里几张 8G 卡的实测数据放在一起看，差异非常明显：

显卡	CPU/内存	模型/量化	上下文	生成速度	备注
RTX 3070 8G	i7-12700 / 64G	35B-A3B Q4_K_M	32K	编码可跑	多模态+UI，作者自称"学习机"[1]
RTX 2060 Super 8G	i7-4790K / 32G DDR3	35B-A3B IQ2_M	8K	~17 t/s	极限定稿，甜点区 6.5-7.2G[2]
RTX 4060 8G（台式）	R7 5700X / 64G	35B-A3B APEX-MTP	64K	30+ t/s，代码 45-50	prefill ~499 t/s[3]
RTX 4060 8G（USB4 笔记本）	R7 6850HS / 32G	35B-A3B APEX-MTP	64K	同上但 prefill 慢 3 倍	prefill ~168 t/s[3]
RTX 4070 Laptop 8G	i7-14650HX / 32G	35B-A3B Q4_K_M	128K	42.3 t/s	一键包，多模态+Agent[4]
4070 8G 笔记本	—	35B-A3B	—	35 t/s	成功接入 Hermes[1]

几个观察：

同是 4060 8G，台式机和 USB4 外接笔记本差 3 倍——差的不是 GPU 算力，而是 PCIe vs USB4 的带宽/延迟，以及移动 CPU 的持续功耗和内存带宽[3]。
CPU 和内存同样重要：2060 Super 配 DDR3 只能跑 17 t/s，而 4060 配 DDR4-3200 能跑 30+；专家层跑在内存里，内存带宽直接决定下限[2][3]。
异构多卡是一条野路子：有人用双 2060 12G + 2070 8G 组异构，跑 35B APEX 量化，prefill 达到 1279 t/s、decode 88.8 t/s[6]——但这已经超出"单张 8G"的范畴了。

七、连接方式之争：USB4/雷电 vs OCuLink

先回答一个很多人搞混的问题：USB4 和雷电（Thunderbolt）到底是不是一回事？

答案是"同源但不等同"。Intel 当年把 Thunderbolt 3 的协议贡献给了 USB-IF，这套协议后来就成了 USB4（2019 年发布）。所以：

雷电 3 / USB4 40Gbps / 雷电 4：底层是同一套协议，eGPU 走的都是 PCIe 3.0 x4 隧道（约 32 Gbps 可用、约 3.9 GB/s）；
雷电 4 只是 USB4 40Gbps 之上的更严格认证（强制 40Gbps、PCIe 隧道 ≥32Gbps）；
雷电 5 / USB4 v2 才把带宽拉到 80/120 Gbps（PCIe 4.0 x4 隧道）。

关键结论：所谓"USB4 不行"，问题不在"USB4 比雷电差"——USB4 40Gbps 和雷电 3/4 的 eGPU 带宽本质是一样的。真正的瓶颈是这套隧道机制本身的开销和延迟，跟原生 PCIe 有先天差距[3]。换句话说，你换成雷电 3/4 的显卡坞，也不会比 USB4 好到哪去。

那什么更好？OCuLink。

OCuLink（SFF-8611）走的是原生 PCIe 信号，不经 USB/雷电的协议封装（隧道），所以延迟更低；规格上常见 PCIe 3.0 x4（32 Gbps）或 PCIe 4.0 x4（64 Gbps）——后者是 USB4/雷电 3/4 的两倍带宽。代价是不支持热插拔、线缆不供电（要独立电源）、线短、还要占一个 M.2/PCIe 槽。

论坛里有一份同一张 7900 XTX 在不同连接方式下的实测阶梯，非常有说服力[7]：

连接方式	预期生成速度（tg mean）
雷电 3 eGPU（Razer Core X Chroma）	37–45 t/s
OCuLink 改装同一个坞（~$80，3 小时）	52–55 t/s
移到 X99 台式机（PCIe 3.0 x16）	58–62 t/s
现代 AM5 + PCIe 4.0 x16	67 t/s

OCuLink 比雷电 3 快了约 40%（37-45 → 52-55），几乎追平原生 PCIe 3.0 x16。所以对 eGPU 跑 LLM，OCuLink 是比雷电/USB4 更划算的选择。另有会员在 OCuLink + R9700 上实测 Q4 量化：pp512 达 680 t/s、tg128 约 29.5 t/s、开 MTP 长输出约 43 t/s，作者表示没观察到明显的链路瓶颈[8]（不过他强调没有同卡 PCIe x16 的 A/B 对照，结论只能作参考）。

回到 8G 笔记本的场景，连接方式的影响同样明显[3]：

台式机 PCIe 内置 RTX 4060：长 prompt processing ≈ 499 tok/s
笔记本 USB4 外接 RTX 4060：长 prompt processing ≈ 168 tok/s（慢近 3 倍）

原因有四[3]： 1. USB4 eGPU 的带宽和延迟弱于台式机 PCIe； 2. 35B-A3B 依赖 CPU MoE，CPU/GPU 协作频繁，链路瓶颈被放大； 3. 移动端 CPU 的持续功耗、散热、内存带宽不如台式机； 4. 笔记本内存通常 32G，64K 上下文 + prompt cache + CPU MoE 时余量更小。

（补充一个兼容性坑：有会员反馈 Blackwell + USB4 + Linux CUDA 运算必崩，RTX 5090 eGPU 在 Linux 下无法启动[9]——外接显卡不光看带宽，还要看平台兼容性。）

笔记本的务实建议[3]： - 上下文降到 32K（ctx-size = 32768），n-cpu-moe 提到 35； - 或者干脆改用能完整放进 8G 的小模型（Qwen3.5-9B、7B/8B coder），避开 CPU MoE 的链路瓶颈； - 别把笔记本当主力 Agent 服务端； - 真要外接，优先考虑 OCuLink 而非雷电/USB4 显卡坞。

八、笔记本 4060 能逼近笔记本 4070？

回头看第六节的表，有个现象值得单独拆开：笔记本 RTX 4060（低一档的卡）居然和笔记本 RTX 4070（高一档的卡）打得不分上下——笔记本 4060 短输出 30+ t/s、代码 45-50 t/s[3]，笔记本 4070 是短文本 42.3 t/s、Thinking 42.1 t/s[4]。按理说 4070 该碾压 4060，为什么会这样？

最重要的：笔记本 4060 和 4070 的显存带宽完全相同。

显卡	核心	CUDA 核	位宽	显存带宽
RTX 4060 Laptop	AD107	3072	128-bit	256 GB/s
RTX 4070 Laptop	AD106	4608	128-bit	256 GB/s
（对比）RTX 4060 桌面	AD107	3072	128-bit	272 GB/s
（对比）RTX 4070 桌面	AD104	5888	192-bit	504 GB/s

笔记本 4060 和 4070 都是 128-bit、16 Gbps 的 GDDR6，带宽都是 256 GB/s——4070 多出来的 1536 个 CUDA 核，并没有换来带宽提升。而 LLM 解码（decode）是"带宽瓶颈"型任务：每生成一个 token，都要把权重从显存完整读一遍，速度基本由显存带宽决定，而不是 CUDA 核数。带宽一样，解码速度自然就接近。

然后，频率差异又补了一刀——笔记本 4060 的加速频率反而更高。 这是很多人忽略的变量：AD107 核心数少、功耗密度低，反而能跑到更高的频率。官方规格里，RTX 4060 Laptop 的 Boost 频率约 2370 MHz，比 RTX 4070 Laptop 的约 2175 MHz 还高（部分高 TGP 机型 4060 能上到 2460 MHz，而 4070 大约封顶 2295 MHz）。用"核心数 × 频率"估有效算力：

显卡	核心数	Boost 频率	有效算力（核·MHz）
RTX 4060 Laptop	3072	~2370 MHz	7.28 M
RTX 4070 Laptop	4608	~2175 MHz	10.02 M

4060 的有效算力达到了 4070 的约 73%，而不是纯核数比给出的 67%——频率优势把差距从 33% 缩小到了约 27%。再考虑笔记本里持续负载下的实际频率（小核心更容易维持高频），差距还会进一步收窄。所以"核心数"这一项的影响力，被频率抵消了相当一部分；在带宽瓶颈的 decode 阶段，频率和核数都不太起作用，两者更是难分高下。

少得可怜的那点差距，用处也不大，因为多出来的核数只在 prefill 阶段有优势。 prefill（处理输入 prompt）是计算密集操作，有效算力（核心数 × 频率）更高的 4070 会快一些；但到了逐 token 输出的 decode 阶段，两者又被带宽拉回同一水平。所以"聊天的体感速度"（看 decode）差不多，只有"首字延迟"（看 prefill）4070 占优。

而且，两者都是笔记本芯片，功耗墙和散热限制相同。 4060 Laptop 和 4070 Laptop 的可配置功耗区间都是 35–115W，薄本里常年 60–80W 且会热降频。LLM 推理是持续负载，谁都没法长时间跑满，差距进一步被抹平。

最后，配置差异也在放大或缩小差距。 笔记本 4060 那组用了 APEX-MTP（带 MTP 投机解码，提速 30-50%），笔记本 4070 那组是 Q4_K_M、没提 MTP[3][4]。所以"4060 看起来不输 4070"里，有一部分是量化/MTP 配置的功劳，不全是硬件的。

反过来看桌面版就明白了：桌面 4060（272 GB/s）和桌面 4070（504 GB/s）带宽差了近一倍，档次差距立刻显现——桌面 4070 在解码上能明显碾压桌面 4060。笔记本 4060/4070 之所以"打平"，本质是"同带宽、不同核数、但频率反超"三者叠加；桌面 4060/4070 则是"带宽差一倍"，差距自然拉开。

一句话总结：选卡跑本地模型，先看显存带宽，再看有效算力（核心数 × 频率）。 笔记本 4060 和 4070 共享 256 GB/s 带宽，且 4060 频率更高、部分抵消核数劣势，所以在带宽瓶颈的 LLM 解码里难分高下。

九、8G 到底能干什么：Agent 场景的现实

这一节可能是新手朋友最关心的了。

能干的： - 日常对话、短代码补全、文本翻译； - 图片/视频问答（多模态，8G 也支持）[1][4]； - 轻量 Agent 任务（有会员在 4070 8G 笔记本上接 Hermes 成功执行多种任务）[1]； - 学习理解 MoE、offload、量化这些概念——8G 是最好的"教具"[2]。

干不动的： - Hermes 这类 Agent 的默认系统提示词就有 20K+ token。8G 卡 prefill 速度约 300 tok/s，光处理提示词就要等很久，实际使用"基本没什么效率可言"[3]； - 复杂多轮工具调用——量化降档后 function call 格式先崩[5]； - 长代码生成——输出长了会明显变慢，最好让 Agent 分文件、分阶段输出[3]。

一位带佬的总结很到位[3]：

8G 的卡只能是跑起来而已，用来驱动 agent 几乎不可用的。

所以对 8G 玩家，我的建议是把心态放对： - 想"跑通、学原理、发帖炫技"→ 35B-A3B MoE，尽情折腾； - 想"日常真的用起来"→ 老老实实用 9B 稠密 + 满精度，或者升级到 16G/24G； - 想"驱动 Agent 干正事"→ 8G 不够，这不是调参能解决的，是硬件天花板。

十、给 8G 玩家的一张速查表

你的诉求	推荐模型	量化	关键参数
就想跑通 35B 玩玩	Qwen3.6-35B-A3B	APEX-MTP-I-Mini (13.7G)	`-ngl 999 --n-cpu-moe 32`，KV q8_0
极限压榨（2060S 级）	35B-A3B	IQ2_M	`-ngl 30 --n-cpu-moe 20 -c 8192 -fit off`
日常对话/短代码	Qwen3.5-9B / 8B coder	Q8_0	全层上卡，别 offload
工具调用/Agent	Qwen3-8B / GLM-4-9B	高精度	别用 27B 低量化
多模态	35B-A3B + mmproj	Q4_K_M	`--mmproj` 加视觉文件
笔记本	9B 稠密	高精度	`ctx-size 32768`，`n-cpu-moe 35`

三条铁律： 1. 8G 跑大模型，--n-cpu-moe 和 -fit off 比模型本身更重要，显存控制在 6.5-7.2G 的甜点区； 2. 能跑 ≠ 好用，Agent 场景的瓶颈是 prefill，不是生成速度； 3. 别为了"跑大模型"硬上低量化，尤其工具调用场景，小模型满精度往往更实用。

8G 不是废物，它会让你清楚地看到显存、带宽、量化三者之间的取舍。折腾它，你能学会所有该学的；指望它，你会失望。理性折腾，量力而行。

参考来源

本文全部实测数据来自抡锤者（lcz.me）论坛会员的真实分享，原帖均可点击核对完整配置与测法：

8G显存篇。RTX3070 8G显存。成功跑 Qwen3.6-35B 多模态AI大模型 — https://lcz.me/topic/262/262/8g显存-篇-rtx3070-8g显存-成功跑-qwen3.6-35b-多模态ai大模型（TID:262）
RTX 2060 Super 8G 部署 Qwen3.6-35B-A3B 极限参数定稿报告 — https://lcz.me/topic/342/342/rtx-2060-super-8g-部署-qwen3.6-35b-a3b-极限参数定稿报告（TID:342，极限调参四阶段）
【RTX4060】【8G显存】运行Qwen3.6 35B A3B APEX-MTP包含两种方式及测试结果 — https://lcz.me/topic/213/213/rtx4060-8g显存-运行qwen3.6-35b-a3b-apex-mtp包含两种方式及测试结果（TID:213，台式机 vs USB4 笔记本、n-cpu-moe 调优）
开源个安装包Qwen3.6 35B 塞进了 8GB 显存笔记本：128K、多模态、Thinking，一键安装还能接本地 Agent — https://lcz.me/topic/1080/1080/开源个安装包qwen3.6-35b-塞进了-8gb-显存笔记本-128k-多模态-thinking-一键安装还能接本地-agent（TID:1080）
【请教】对于7900xtx-24G和4070-8G这类小显存显卡，进行工具调用的模型有什么评分之类的信息出处供参考么？ — https://lcz.me/topic/1066/1066/请教-对于7900xtx-24g和4070-8g这类小显存显卡-进行工具调用的模型有什么评分之类的信息出处供参考么（TID:1066，8G 工具调用模型建议）
雙2060 12G 加 2070 8G llama.cpp with Ornith-1.0-35B-Heretic-MTP-APEX-I-Quality — https://lcz.me/topic/1092/1092/雙2060-12g-加-2070-8g-llama.cpp-with-ornith-1.0-35b-heretic-mtp-apex-i-quality（TID:1092，异构多卡）
分享自己的經驗 # 7900 XTX 本地 LLM 優化實測報告（Qwen3.6-27B） — https://lcz.me/topic/151/151/分享自己的經驗-7900-xtx-本地-llm-優化實測報告-qwen3.6-27b（TID:151，雷电 3 vs OCuLink vs 原生 PCIe 实测阶梯）
R9700 + Qwen3.8-27B：128K、MTP、Q4/Q6 都折腾了一遍 — https://lcz.me/topic/1345/1345/r9700-qwen3.8-27b-128k-mtp-q4-q6-都折腾了一遍（TID:1345，OCuLink 实测与带宽讨论）
Strix Halo本地部署 DeepSeek V4 Flash — 環境、失效、可行與技術總結 — https://lcz.me/topic/1010/1010/strix-halo本地部署-deepseek-v4-flash-環境-失效-可行與技術總結（TID:1010，Blackwell + USB4 + Linux CUDA 兼容性问题）

翻出一张2014年春天的课表

2026-09-18T15:00:00+08:00

整理旧文件，翻出来一张2014年春季的课表。

那会儿按学制算，我应该还在研二，但实际上已经在准备直博了。读的是地球科学的博士，可课表上选了一堆跟计算机沾边的课。现在回头看，这些课里真正影响我后来做事方式的，反而是当时觉得最"不务正业"的那几门。

先看课表。

	星期一	星期二	星期三	星期四	星期五	星期六	星期日
1-2节	矿床地球化学(1-6) 综合楼101		显微构造(11-14) 科-413	单片机原理与应用(3-10) 杜刚科-208	显微构造(11-14) 科-413	岩石地球化学(4-5,8-9) 综-702	岩石地球化学(4-5,8-9) 综-702
3-4节	矿床地球化学(1-6) 综合楼101			单片机原理与应用(3-10) 杜刚科-208
5-6节		专业英语(1-10) 综合楼101	Unix程序设计(1-8) 周长兵科-415	矿床地球化学(1-6) 综合楼101	自然辩证法(1-4)	岩浆及岩浆热液矿床学(1-5,8-9) 综-701	岩浆及岩浆热液矿床学(1-5,8-9) 综-701
7-8节			Unix程序设计(1-8) 周长兵科-415	数字图像处理(9-17) 严红平科-404	自然辩证法(1-4)

专业课那一列，矿床地球化学、显微构造、岩石地球化学、岩浆及岩浆热液矿床学，还有专业英语和自然辩证法，都是本分。真正有意思的是另外三门：单片机原理与应用、Unix 程序设计、数字图像处理。

一个地球科学的博士，跑去学单片机和 Unix，放在今天看也不算常规。但我现在很庆幸当时选了。单片机那门课讲硬件底层的访问控制，Unix 那门课讲内存管理，这些概念后来一直跟着我，看什么都用得上。很多时候，你觉得自己在学一个"用不上的东西"，其实只是还没到用它的场景。

Unix 那门课，其实主要讲的是 BSD。具体内容我印象已经不深了，但那门课之后，我用 BSD 明显更多了，尤其喜欢 FreeBSD，觉得它可靠性很好。在这之前，我承认自己容易被社会上的一些文章带偏。比如当年有人写文章说"完全用 Linux 工作"，讲得很有感染力，很多人信了，包括我。后来这位作者自己也修正了那个观点。

学完这门课我才真正想明白：不同的场景要用不同的工具。有的事像跑车，追求速度；有的事像卡车，要的是载重；有的事像客车，得装下一车人；还有的事得靠越野车，路烂也能走。赛道上跑车最快，但这不代表所有场景都该开跑车。工具没有绝对的好坏，只有合不合适。

前几天，我的一个学生去了某顶级名校旁听了一次他们研究生的课程，就发现对比他们和我们本科班的上课氛围，有明显不同。

他们那边，下课前几分钟，几乎没什么人急着收拾东西走人，大多还在做题、听讲、翻书。我们这边本科生上课可能都提前三五分钟就要为下课做准备收拾书和包了。我猜原因有几层：一是他们那所名校的研究生无论是保送还是考研上来的，可能本身就比较拼，绩点、直博、毕业，样样都要争；二是可能好奇心确实更强一些。另外，这类学校的课，老师一般也不太需要花力气去强调课堂纪律，大家心里有数。

我就想起来我当年听江老师的地球物理课。

他讲地壳地幔的密度均衡的部分，那时候相关的几篇文章我们好几个人都看过。他当时做的是两段均衡，结果方程配不平，图画不出来。课上他就直接说，这个算不出来了，大家有什么办法？我们四五个人就轮流上去，把自己的思路写一部分在黑板上。后来发现，大家看的是同一篇文章，关注的点却各不相同。我当时提的是，地壳的均衡过程可能需要三种密度端元才能配平。现在看，那模型其实很粗糙，但我很怀念那种上课的状态。

后来越来越觉得，高水平的教育，不太可能是几分钟一个知识点、几分钟一个总结、几分钟一个思想、几分钟一个活动。那是中小学的路子，不是面向成年人的高等教育。大学生、研究生，不该被当成小学生那样一板一眼地教。这既不太符合教育规律，也不太符合人认知事物的基本方式。

当然，也能理解，有的地方就是习惯这种形式化的东西。因为形式化的东西好留痕，好交差，看着也整齐。只是整齐和有效，有时候是两回事。

说到这儿，想起一句话，以前老听一些坏人引用，叫"存在即合理"。

后来查了原文，请教了人家外语专业的才知道，这句话的本意，大概是指现实中的东西有其合乎理性的根据，合乎理性的东西才会在现实中有所对应。它本身不涉及好坏的价值判断，只是一种描述。可传着传着，就被简化成了"凡存在的就是合理的"，然后拿去为各种既定的东西背书——尤其是那些陈旧、落后、本该改一改的东西。这中间的意思，其实已经偏了很远。

十多年过去了，再看这张课表，我想起来的是另一件事：那时候在课堂上，学生是可以发表自己想法的，是可以对老师讲的东西提出不同意见的，并且有机会把这些意见讲出来、一起查证、各自列参考文献。这种事，当年是存在的。我相信现在的一些高校里，依然还是这样。

当年的一些同学，跟我一样，也都陆续站上了讲台。

前几天我们一个同学提到某顶级名校的一位教师，说看着像四五十岁，结果一问比我还小，还不到四十，但人家已经是教授、博导了，非常优秀。

不过听说，同学们跟他沟通的体验，好像算不上特别好。这其实也正常，人各有各的风格，年轻有为的人往往也有自己的脾气。

我跟自己带的学生说过：咱们沟通方式比较平和，比较扁平，大家是以一种接近平等的姿态在交流。研究生阶段，本来就该是这样。

我不知道从什么时候开始，师生关系在一些地方慢慢变成了上下级。据传，有的地方甚至还有师兄师姐组织大家凑钱，给老师买教师节礼物。这种事我听着总觉得不太舒服。师生之间，本来不该是这个样子。

写这些，不是想说过去一定就很好，而是每个时代有每个时代的问题，无意厚古薄今，有些东西值得保留：课堂上允许不同的声音，师生之间能平等地讨论，对现状保留一点追问的勇气。

凡是希望大家安于现状、不要再做任何改进的说法，我现在都会多想一想。这不代表要否定一切，而是说，当"存在即合理"被拿来回应所有改进的诉求时，它多半已经不是在讲它本来的意思了。

给大一同学：Python 与数学建模学习资源指南

2026-09-18T13:30:00+08:00

每年开学，都有大一同学来问：想学编程、想搞数学建模，该从哪儿开始，看什么。

网上资源多是多，但太散。这个教程说要从 C 语言开始，那个视频说直接上机器学习，看一圈下来反而更懵。

我这些年自己也教过不少学生，陆陆续续写过一批相关的东西，干脆按学习顺序整理成一份指南，专门给刚入学的同学用。

下面这些链接，都是我公众号上发过的文章，点进去就能看。我没有把网上所有好资源都塞进来，只挑了自己看过、用过、觉得靠谱的。顺序上建议从头往后走，跳着看容易卡壳。

一、先把环境搭起来

学 Python 第一件事不是写代码，是装环境。这一步劝退的人比语法本身多，先把地基打好。

Windows 用户照着这篇做就行，从 USTC 镜像下载，装到固定路径，配好镜像源：

Windows 系统下从中科大 USTC 镜像安装 Miniconda3 完整指南

装完之后，建议顺手把「路径」这个概念搞明白。以后报的各种「找不到命令」「模块导入失败」，八成都是路径问题：

二、Python 基础

环境好了，按这个顺序看。这四篇篇幅都不长，但把关键点讲到了。

Python 基础语法5分钟入门 —— 数据类型、容器、索引切片、条件循环、函数、异常，一篇过一遍。
面向对象编程入门：用武侠角色理解 Python 中的“类” —— 用武侠角色打比方，把类、实例、继承讲明白。
简单说说Python里面的「函数是第一公民（First-Class Citizen）」 —— 理解 Python 的函数为什么特殊，后面学装饰器、回调都靠它。
单一职责原则：写好Python函数的第一步 —— 不是语法，是习惯。早点养成，代码质量差很多。

这一阶段的目标很具体：能自己写脚本处理文件、批量改文件名、读一份 Excel 或 CSV 做点统计。做得到，基础就算过关了。

三、数学与科学计算基础

写代码只是工具，真做建模和数据分析，数学底子决定你能走多远。这几篇不要求你数学多好，但帮你把计算机里的数字、统计和常见概念搞清楚。

基础知识：初级统计概念的简单介绍 —— 均值、方差、分布这些，用最直白的话讲一遍。
单精度浮点数的“分辨率”：为什么在计算机里 1000 万和 1000 万加 0.01 可能是一样的？ —— 为什么算出来的数会「不准」，这篇讲得最清楚。
你的电脑每秒能做多少次浮点运算？——FLOPS 的故事 —— 算力到底怎么衡量。
只测 FLOPS 还不够——四个经典 CPU 测试基准 —— 接着上一篇，讲讲实际性能怎么测。
基础概念-拉普拉斯算子（排版修复版本） —— 一个在物理、图像、微分方程里到处出现的算子。
一维查找方法综述：从三分、黄金分割到 Fibonacci 与 Brent —— 优化的入门，怎么用最少的次数找到你要的值。

四、数值方法：积分与滤波

这部分开始上强度了。建议不要只看，把代码敲一遍，改改参数看看结果怎么变。

积分和求根，从最简单的梯形法一路到自适应方法：

滤波，做传感器、导航、信号处理、时间序列预测都用得上，也是数学建模里很实用的一块。这篇把从移动平均到粒子滤波的几类方法串了一遍：

滤波方法：从移动平均到粒子滤波

五、数学建模实战

这是一个完整的系列，从零讲怎么把一个现实问题变成数学模型，再用 Python 跑出来、画出来。强烈建议跟着做一遍，哪怕只是照抄代码再改改参数。

学完这些，建议去参加一次数学建模竞赛。校赛、国赛、美赛都行，重点是逼自己完整走一遍「读题—建模—编程—写论文」的流程，这个经验比多看十篇文章都值。

六、科研与论文（提前准备）

大一就开始准备不早。等你要写课程论文、大创、竞赛论文的时候，这些能救命。

新手向的 Markdown 数学公式指南 —— 先把公式怎么写学会。
学术论文中常见研究方法综述及简单举例 —— 知道论文里那些方法都是干嘛的。
学术研究支持工具分类与文献获取方法 —— 文献去哪儿找、怎么管。
《给研究生的一些建议》（本人翻译版本） —— 虽然是给研究生的，大一看了能少走很多弯路。
高校教师建议大一新生养成阅读论文的习惯 —— 为什么、怎么读论文。
计算机相关专业学生的自学指南：从教材到实践的全新学习路径 —— 想系统自学计算机的看这篇。

如果你对 AI 方向感兴趣，可以顺着这两篇往下走：

七、边学边用的工具

下面这些工具都是我用 Python 写的，源码不复杂，可以拿来当练手项目读，也可以直接拿来用。

Chou（瞅）——一个Python小工具，让你的论文PDF文件名不再是乱码 —— 论文党必备。
NuoYi 挪移-一个离线的 PDF/DOCX 转 Markdown 工具 —— 把 PDF 资料变成能编辑的文本。
Huan-一个把网页转换成 Markdown的Python 小工具
HeiBan（黑板）-将Markdown转换成HTML来当讲义 —— 做讲义、做汇报很好用。
Xie（写）：把 Markdown 转成微信公众号格式网页的小工具
推荐一款MarkDown的跨平台离线编辑器，支持随时预览

八、给大一的几条建议

最后说几条老登常谈。

别只看视频。 看的时候觉得都懂了，自己一写就卡壳，这是常态。看一段就自己敲一遍，改改参数、故意写错看看报什么错，比连看三小时视频有用。

从项目出发。 不要等「学完了」再动手，永远等不到那一天。找一个自己感兴趣的小题目，比如把班级成绩表处理一下、爬个天气数据画张图，边做边查，学得最快。

数学别丢。 高数、线代、概率统计，这些课当时觉得没用，等你做建模、看论文、学机器学习的时候，全会回来找你。课上认真听，比以后补课省事得多。

参加一次数学建模竞赛。 不管拿不拿奖，完整做一次的价值都很大。组队、分工、熬夜、写论文，这个过程本身就是训练。

英语要跟上。 最新的文档、论文、教程几乎都是英文的。不用一上来就啃原著，但至少要习惯看英文文档，别一见到英文就去找二手翻译。

别怕报错。 报错是常态，不是你笨。学会看报错的最后一行、学会搜索报错信息，这个能力比记住多少语法都重要。

用好 AI 工具，但别依赖它。 现在用 AI 辅助写代码、查资料确实方便，但基础得自己打。AI 给的代码你要看得懂、能改，否则出了问题完全没法排查。

九、外部资源

除了我写的这些，下面这些是我觉得值得收藏的：

Python 官方文档：https://docs.python.org/zh-cn/3/ ，中文版，遇到问题先查它。
《Think Python》原书：https://greenteapress.com/wp/think-python-2e/ ，免费。
数据集平台：Kaggle（https://www.kaggle.com/datasets ）和 ModelScope（https://www.modelscope.cn/datasets ），练手用。
数学建模竞赛：全国大学生数学建模竞赛官网 http://www.mcm.edu.cn/ ，先看历年题目。
书：姜启源《数学模型》、司守奎《数学建模算法与应用》，图书馆一般都有。

最后

大学四年，最不缺的是时间，最容易被浪费的也是时间。大一这一年如果能把 Python 和数学的基础打扎实，后面做项目、进实验室、参加竞赛、找实习，都会轻松很多。

不用着急，也不用什么都学。照上面的顺序，一周啃一两篇，动手做，坚持一个学期，回头你会感谢现在的自己。

有问题欢迎在公众号后台留言，我看到会回。

纯文本格式盘点：txt、dat、csv、json、jsonl、md 都是干嘛的

2026-09-16T23:30:00+08:00

上一篇说了把文本打包成 ZIM 来省空间，顺手就想把"文本"这件事展开说说。

这些年折腾数据，从地球化学的仪器导出，到爬虫抓回来的网页，再到给大模型准备的训练语料，几乎每天都跟各种纯文本格式打交道。什么 .txt、.dat、.csv、.json、.jsonl、.md，后缀五花八门，很多人是"知道有这个东西，但说不清它到底是啥、为什么存在、跟旁边那个有什么区别"。

这篇文章就把常见的纯文本格式一个个过一遍：它是干嘛的，典型用在什么场景，优势劣势是什么，以及实际用的时候会踩的坑。

先说清楚，什么是"纯文本"

纯文本（plain text）就是一个字节序列，每个字节都对应着字符，没有任何关于字体、颜色、加粗这类排版信息。你用记事本能打开、用 Vim 能打开、用 VS Code 能打开，看到的内容是一样的，这就是纯文本。

跟它相对的是二进制格式：Word 的 .docx、Excel 的 .xlsx、照片的 .jpg。这些用记事本打开就是一堆乱码，因为里面存的是压缩后的结构，不是字符。

纯文本有两个特别容易被忽略的基础问题，几乎所有"打开是乱码"的事故都出在这。

第一是编码。 计算机里只有数字，字符要用数字来表示，这个对应关系就是编码。老祖宗是 ASCII，一个字节搞定 128 个英文字符；中文进来之后，国家搞了 GB2312、GBK，一个汉字两个字节；后来全世界统一到 UTF-8，英文一个字节、中文三个字节，兼容 ASCII，成为事实标准。

乱码的根源基本都是一个：文件是一种编码写的，你用另一种编码去读。最典型的就是 Windows 上老版本记事本，默认用本地编码（中文系统就是 GBK）保存，文件拿给 Mac 上默认 UTF-8 的编辑器一打开，就是"鏂囨湰鏍煎紡"这种天书。反过来，UTF-8 的文件用 GBK 去读，也是一锅粥。

第二是换行。 Windows 用回车加换行（\r\n，写作 CRLF），Linux 和 macOS 用换行（\n，写作 LF），老款 Mac 用单独的回车（\r，基本绝迹了）。同一个文件在两边倒腾，有时会出现"每行末尾多了个 ^M"或者"整个文件挤成一行"的怪象，就是这俩在打架。Git 配置里那个 core.autocrlf，就是为了处理这个。

后面讲每个格式的时候，这两个坑会反复出现，先记住。

txt：万能的口袋

.txt 是最原始的格式，它的定义几乎等于"纯文本本身"：没有任何结构约定，就是一段字符。

它的用途也就因此特别宽：写笔记、存日志、装语料、放配置、当程序之间交换数据的最简陋协议，都行。我手里那个相声文本库，最早就是 234 个 .txt 文件，后来才打包成 ZIM 的。

txt 的优势是极致的简单和通用。任何设备、任何年代的系统都能打开它，五十年前的程序能读，五十年后的也能读。作为"给人看、给人存"的载体，它几乎不会出错。

劣势是没有任何结构。没有行列的概念，没有字段的区分，程序想从里面提取"第二列的分数"，就得自己写正则去抠。数据一有结构，txt 就不够用了。所以 txt 更像一张白纸，而后面这些格式，都是在这张纸上画了不同的格子。

dat：一个约定俗成的黑盒

.dat 挺有意思，它是这堆格式里唯一没有标准的一个。

data 的缩写，谁都可以用，所以它代表什么，完全取决于生成它的那个软件。可能是制表符分隔的表格，可能是逗号分隔，可能是自己发明的格式，甚至可能是二进制数据（比如很多仪器的原始数据、Windows 的某些缓存文件）混着叫 .dat。

我早些年处理地球化学数据的时候，经常从仪器软件里导出 .dat 文件，每次拿到一个新仪器的导出，第一件事就是用文本编辑器打开看一眼：是文本就好办，用 pandas read_csv 配上正确的分隔符就能读；打不开或者满屏乱码，那就得找说明书，或者找厂家要格式说明。

所以对 .dat 的态度就是：别看后缀，先打开看内容。它是文本还是二进制、用什么分隔符、有没有表头，都得靠眼睛确认。它的存在更多是一种历史习惯，而不是一种"格式"。

csv 和 tsv：表格的最低配

.csv，Comma-Separated Values，逗号分隔值，是表格数据的最低配实现：第一行表头，往后每行一条记录，字段之间用逗号隔开。

name,age,city
张三,30,北京
李四,25,上海

.tsv 是它的兄弟，Tab-Separated Values，用制表符分隔。制表符在正常文本里出现得少，所以 tsv 省去了转义的麻烦，但肉眼看起来没那么直观。

csv 的优势很明显：表格数据的通用交换语言。Excel、数据库、pandas、R、各种 BI 工具，全都认它。文本格式意味着版本控制能看 diff、任何语言都能解析、几十年的工具链都支持。

但 csv 的坑，可能比它的优势还多，我一个个说。

第一个坑，分隔符本身会出现在数据里。 比如地址是"北京市,海淀区"，逗号一进去，程序就把一行读成两列了。标准解法是用引号把字段包起来，"北京市,海淀区"；引号本身要转义成两个引号。这套规则写在 RFC 4180 里，但很多软件并不严格遵守，于是"能生成 csv 的软件"和"能正确读 csv 的软件"之间就出现了大量错位。

第二个坑，Excel。 用 Excel 打开 UTF-8 编码的 csv，中文经常是乱码，因为它默认不认 UTF-8，除非你带上 BOM（一个隐藏在文件开头的 EF BB BF 三字节标记）。所以用 Python 写 csv 给 Excel 用户时，要特意用 utf-8-sig 编码：

import pandas as pd

df.to_csv("out.csv", index=False, encoding="utf-8-sig")

Excel 还有更出名的毛病：打开 csv 时自作聪明做类型转换。基因名 SEPT1 被它理解成 9 月 1 日，MARCH1 变成 3 月 1 日；长数字（比如银行卡号、经纬度）被显示成科学计数法，再保存回去，末尾几位就永久变成 0 了。这不是段子，2016 年《Genome Biology》上有一篇论文就因为这个把五分之一的基因名写错了，后来人类基因组织（HGNC）干脆在 2020 年把二十多个带这类前缀的基因符号改了名，就为了躲开 Excel。

第三个坑，它没有类型。 csv 里的一切都是字符串，1.0、01、1e3 之间毫无区别，全靠读取方去猜。日期格式更是五花八门，2026-09-16、2026/9/16、16-09-2026 都可能是"日期"，解析的时候得自己指定。

所以我对 csv 的使用心得是：它是交换格式，不是存储格式。中间文件、临时导出用它没问题；正经存数据，要么进数据库，要么用 Parquet 这类列式格式。

json：结构化数据的事实标准

.json，JavaScript Object Notation，现在已经是跨语言的结构化数据交换标准，网页 API 返回数据、各种配置文件、NoSQL 数据库，几乎都用它。

长这样：

{
  "name": "CycleUser",
  "age": 30,
  "tags": ["Python", "Geology"],
  "address": {
    "city": "Beijing",
    "zip": "100083"
  },
  "active": true
}

它只有六种数据类型：字符串、数字、布尔、null、数组（[]）、对象（{}，键值对）。靠数组和对象的嵌套，能表达任意复杂的结构。

json 的优势是结构明确、机器友好。相比 csv，它天然支持嵌套（一个对象里套对象、套数组）、字段名就是键、类型信息由语法直接表达（带引号的是字符串，不带的可以当数字）。Python 里 json.loads() 一下就变成字典和列表，配合使用毫无障碍。

劣势主要有三个，都挺扎心。

不支持注释。 给配置文件写 json，想加一行"这个参数是干嘛的"，没门。这是它作为配置格式被后来者（yaml、toml）赶超的核心原因。

不允许尾逗号。 {"a": 1, "b": 2,} 这种写法，在 Python 的字典字面量里合法，在 json 里是语法错误。手写 json 的时候特别容易中招。

大数精度问题。 json 的数字按浮点数处理，JavaScript 里超过 2^53 - 1（900719919254740991 之后）的整数就会丢精度。订单号、雪花 ID 这种长数字，经过一次 JS 处理可能就变了。所以很多 API 干脆把大整数序列化成字符串来传。

import json

# 标准库足够日常使用
data = json.loads('{"name": "张三", "scores": [89, 73]}')
print(data["scores"][0])        # 89
print(json.dumps(data, ensure_ascii=False, indent=2))

中文用户还要注意 ensure_ascii=False 这个参数，不加的话中文会被转成 \u5f20\u4e09 这种转义，文件大小翻好几倍，虽然合法但没法看。

jsonl：一行一条，为流式而生

.jsonl，JSON Lines，有时也叫 .ndjson，就是把很多个 json 对象一行一个地排进同一个文件：

{"name": "张三", "score": 89}
{"name": "李四", "score": 73}
{"name": "王五", "score": 91}

它和"一个巨大的 json 数组"的区别，初看不大，用起来天差地别。

一个装着一百万条记录的 json 数组，程序必须整个读进内存、从头解析到尾，中间任何一行坏了，整个文件都废了。而 jsonl 是一行一条独立记录，可以逐行读、逐行解析：读一行处理一行，内存占用几乎恒定；第 800 万行坏了，跳过它接着读，前面 799 万行完好无损。

典型场景：日志系统、大模型训练数据的存放。你去看 Hugging Face 上很多数据集、看各家微调框架的输入格式，基本就是 jsonl：一行一条对话或一条样本。逐行处理意味着可以流式喂给训练管线，内存里永远只有当前这一条。

import json

with open("data.jsonl", encoding="utf-8") as f:
    for i, line in enumerate(f):
        line = line.strip()
        if not line:
            continue
        try:
            record = json.loads(line)
        except json.JSONDecodeError:
            print(f"第 {i + 1} 行解析失败，跳过")
            continue
        # 处理 record

劣势就是它放弃了"一整个结构"的表达能力：顶层只能是一串平级的对象，想表达"这批数据整体有个元信息头"这种结构，就得自己定约定（比如第一行放一个 type: meta 的行）。另外它也是纯文本，体积比 Parquet 这类二进制列式格式大不少，大数据量下读写速度吃亏。

md：给"人"看才舒服的标记

.md，Markdown，是我写博客、写笔记、写公众号初稿用的格式，也是这两年几乎所有技术文档的事实标准。

它的思路跟上面那些"数据格式"完全不同：csv、json 是给机器读的，md 是给人读的，只是顺便让机器也能解析出结构。星号包起来是斜体，井号开头是标题，大于号是引用，反引号是代码——这些符号都是从纯文本时代电子邮件的约定里继承来的，一眼能看懂，不需要渲染。

Markdown 由 John Gruber 在 2004 年设计，最初的语法就一小页纸。后来因为太流行，各家开始加私货，于是有了两个重要的标准化努力：CommonMark 把核心语法钉死了，GFM（GitHub Flavored Markdown）在它之上加了表格、任务列表、删除线、代码块语言标注这些特别实用的扩展。

我写博客用的是 Pelican，markdown 文件头部有 front matter 存标题、日期、分类、标签，正文里数学公式靠 pymdownx 扩展转给 KaTeX 渲染。这些都是 md 生态的一部分：核心语法极简，按需加扩展。

md 的优势很明显：写作体验好、版本控制友好（纯文本，diff 清晰）、可移植（任何编辑器都能写）、渲染后好看。劣势是方言太多：同一个语法点，GitHub 支持、公众号不支持；表格、脚注、数学公式这些都不在核心语法里，换个渲染器可能就原样显示出符号来。

yaml：配置文件的主力

.yaml（.yml 是同一个东西的缩写后缀），重点用在配置文件上。GitHub Actions 的工作流、Docker Compose、conda 的 .condarc、Kubernetes 的资源清单，全是 yaml。

channels:
  - conda-forge
show_channel_urls: true
custom_channels:
  bioconda: https://mirrors.ustc.edu.cn/anaconda/cloud

它支持注释，支持多行文本，支持嵌套结构，写起来比 json 舒服太多。配置文件要经常被人手工编辑，注释和可读性是刚需，所以 yaml 成了主流。

它的劣势也很独特：缩进就是语法。空格数错了、用了 Tab，配置的含义就变了，而且这类错误报错信息往往不友好。还有一个著名的 "Norway problem"：

country: no

yaml 会把 no 解析成布尔值 false 而不是字符串 "no"。类似的还有 on、off、yes。写挪威的代码，得加引号。这种"帮你猜类型"的体贴，偶尔就是灾难。

toml：新一代配置标准

.toml（Tom's Obvious, Minimal Language）是近几年崛起的配置格式，Python 官方把它定为项目元数据的标准，pyproject.toml 就是它：

[project]
name = "ds-holiday"
version = "0.1.0"
requires-python = ">=3.12"
dependencies = ["numpy", "pandas"]

它跟 yaml 解决同一个问题，但思路相反：用显式的类型语法代替缩进。字符串带引号、日期是原生类型、布尔就是 true/false，没有 Norway problem，缩进错了顶多难看，不会改变语义。

劣势是深层嵌套的写法比较啰嗦（靠 [a.b.c] 这种分段标题逐层进入），表达复杂结构不如 yaml 灵活。但配置文件一般也没多深，所以 toml 正在快速取代 ini 和一部分 yaml 的地盘。

ini：老派但还活着

.ini 是 Windows 时代传下来的配置格式，等号赋值，方括号分节：

[global]
index-url = https://pypi.mirrors.ustc.edu.cn/simple
trusted-host = pypi.mirrors.ustc.edu.cn

pip 的配置文件就是 ini。它简单到几乎没什么可学的，但正因为简单，嵌套能力几乎没有、类型全靠读的人自己理解。新项目一般直接上 toml，不过维护老系统、读别人的配置，ini 还是绕不开。

xml 和 html：标签家族

.xml 和 .html 是亲戚，都用尖括号标签来标记内容。

XML 是"通用标记语言"，特点是严格：必须有唯一的根节点、标签必须闭合、大小写敏感。RSS 订阅源、SVG 矢量图、Maven 的 pom.xml、Android 的布局文件，都是 XML。它的优势是规范极其严格，解析器写起来有标准可依，还带命名空间机制；劣势是啰嗦，同样的数据，XML 的体积通常比 json 大不少，嵌套深了之后可读性也不行。现在除了老系统和特定领域（RSS、SVG、Office 文档底层），新项目很少选它。

顺带一提，Word 的 .docx、Excel 的 .xlsx 本质是个 zip 压缩包，里面装的是一堆 XML 和媒体文件。把后缀改成 zip 解开就能看到，挺涨知识的。

HTML 是给浏览器看的，天生宽容：标签没闭合它也尽力渲染。它不算"数据格式"，是文档格式，这里提它是因为做数据抓取的时候，你写的解析器多半就是在跟 HTML 打交道（Beautiful Soup、XPath 那一套）。

还有一批常见的：log、sql、srt、tex

.log 是日志文件，通常一行一条记录，开头是时间戳。它没有标准 schema，但"一行一条、按时间追加"这个习惯是通用的。查问题的时候 grep 日志，是每个开发者的日常。

.sql 是数据库脚本文件，里面就是 SQL 语句。数据库导出、迁移、备份常用它。文本格式的好处是能进版本控制，能 code review。

.srt 是字幕文件，序号 + 时间轴 + 文本，三段一组：

1
00:00:01,000 --> 00:00:04,000
大家好，今天说说纯文本格式。

.tex 是 LaTeX 排版源码，.bib 是它的参考文献库。写论文的人躲不开。这两个语法门槛比前面都高，但排版质量确实是所见即所得编辑器很难达到的。

另外还有一大批"没有后缀的文本文件"：Dockerfile、Makefile、.gitignore、requirements.txt、.env。它们也是纯文本，只是约定了固定的名字和语法。这恰恰说明：纯文本的本质是"内容和结构靠约定，不靠后缀"。

怎么选，一张表

格式	定位	人读	机器读	典型场景
txt	纯文本口袋	很好	要自己解析	笔记、日志、语料
dat	无标准黑盒	看约定	看约定	仪器导出、各软件自定义
csv / tsv	表格交换	一般	很好	数据导出导入、Excel 交换
json	结构化对象	一般	很好	API 返回、通用数据交换
jsonl	一行一条 json	差	很好	日志、大模型训练数据
md	轻量标记写作	很好	好（需解析器）	博客、README、文档
yaml	配置	很好	好	Docker Compose、CI、conda
toml	配置	很好	好	pyproject.toml、Cargo
ini	极简配置	好	好	pip、Git 老式配置
xml	严格标记	一般	好	RSS、SVG、Office 底层
html	网页文档	差	好（宽容）	网页
sql	语句脚本	好	好	数据库导出、迁移

我的选择习惯大致是：

给人看的记录，用 md；
跟别的软件交换表格数据，csv；
程序之间传结构化数据、调 API，json；
大量记录要逐行流式处理，jsonl；
写配置文件，新项目 toml，跟随既有生态（Docker、CI）就 yaml；
数据要长期存、频繁按列查询，别用以上任何一个，上数据库或者 Parquet。

说一下编码和细节

第一，编码统一用 UTF-8，没有例外。所有历史遗留的 GBK、Latin-1 文件，碰到就转成 UTF-8 存一份。Python 里读写文件养成显式写 encoding="utf-8" 的习惯，能躲开九成乱码问题。要照顾 Excel，就用 utf-8-sig。

第二，csv 是交换格式，不是存储格式。它没有类型、没有约束、动不动被 Excel 篡改，正经数据请交给数据库或 Parquet，csv 只负责在系统之间搬运。

第三，配置文件选 yaml 还是 toml，看生态跟随。容器和 CI 的世界已经被 yaml 占了，Python 的新世界是 toml 的，跟大流走，别逆着来。

第四，jsonl 是被低估的格式。很多人一提批量数据就想到 json 数组或者 csv，实际上日志、训练样本、爬虫输出这些"一行一条、逐行处理"的场景，jsonl 都是最舒服的选择：坏一行跳一行，内存占用恒定，还能直接按行 append。

纯文本格式看着朴素，背后全是几十年演化出来的取舍。理解每个格式"为什么长这样"，比记住"怎么用"更重要——因为格式会过时，但是取舍的逻辑其实还是类似的。

国庆假期别浪费：从Python基础语法到数据分析的成长路径

2026-09-16T21:30:00+08:00

快到国庆节了，有很多小朋友都有一段时间比较长的假。这种整块的、不用打卡、不用开会的时间，一年也没几段。用来躺着刷手机，刷完了其实啥也没剩下；用来啃一门技术，十天足够把一套东西从"听说过"变成"能上手"。

当初的《Python 基础语法5分钟入门》https://mp.weixin.qq.com/s/9uB7Ct02HFQwo06VP0rpWg 里，数据类型、列表字典、索引切片、if/for、函数、模块、异常，这些看一遍就能懂，写点小脚本也够用了。

但如果你打算往数据分析、数据科学这个方向做点开发和探索，光会语法是不够的。语法只是"会写字"，离"能写出有用的东西"还差三样：一套顺手的工具环境、一批核心的库、以及一点统计和数据的思维方式。

这篇文章就按这个思路来介绍一下。

每个库都要清楚：官网在哪、核心功能是什么、典型用在什么场景、优势和劣势各是什么。

一、先把环境弄对，别在系统 Python 上瞎装

这一步很多人跳过，然后被环境问题折磨三天，假期就废了。我先说这个。

第一件事，别往系统的 Python 里 pip install。 系统那个 Python 是给操作系统自己用的，如果装乱了，轻则某些系统工具报错，重则终端里一堆东西用不了。装东西一定要在虚拟环境里。

虚拟环境以前大家都用 conda，现在我个人更推荐 uv。它快，管理 Python 版本和依赖都很利索。

Miniconda 官网：https://docs.conda.io/projects/miniconda/en/latest/
uv 官网：https://docs.astral.sh/uv/

用 uv 建环境就这么几步：

# 装 uv（macOS/Linux）
curl -LsSf https://astral.sh/uv/install.sh | sh

# 建一个项目目录，指定 Python 版本
uv init ds-holiday
cd ds-holiday
uv venv --python 3.12

# 装库
uv add numpy pandas matplotlib scipy scikit-learn

第二件事，装个能交互式跑代码的东西。 数据分析跟写网站不一样，你需要一边看数据长什么样、一边改代码。Jupyter 就是干这个的，官网在 https://jupyter.org 。现在更省事的做法是用 VS Code 装个 Jupyter 插件，或者直接上 JupyterLab。我个人习惯 VS Code 里开 .ipynb，改一行看一行结果。

第三件事，把镜像源配上。 国内直连 PyPI 经常慢得让人怀疑人生。中科大 USTC 的源很稳：

pip config set global.index-url https://pypi.mirrors.ustc.edu.cn/simple

Windows 上从 USTC 镜像装 Miniconda3 的完整步骤，我之前单独写过一篇，《Windows 系统下从中科大 USTC 镜像安装 Miniconda3 完整指南》https://mp.weixin.qq.com/s/fR6k5iSrEbS1df-nBqLffg?token=916056284&lang=zh_CN

环境搞定，后面才顺畅。

二、数据科学的四件套

这四样是地基，不管后面做哪个方向都绕不开。我按学习顺序排：NumPy 打底，pandas 做表格，Matplotlib 画图，SciPy 补科学计算。

NumPy：一切的地基

官网：https://numpy.org

NumPy 就干一件事，提供一种叫 ndarray 的多维数组，然后让所有对数组的操作都在底层用 C 语言跑，快到飞起。它的核心思想叫向量化和广播：你不用写 for 循环，直接对整个数组做运算，代码短、速度快。

典型场景是所有跟数值沾边的活：矩阵运算、图像处理（图像本质就是三维数组）、信号处理、机器学习里所有张量操作。可以说 Python 数据科学这一整座楼，地基都是 NumPy。

优势很明确：快（底层 C 和 BLAS 库）、生态基础（pandas、SciPy、scikit-learn 全建在它上面）、广播机制让代码极简。

劣势也得说清楚：它没有列名，只有数字下标，做表格分析很别扭；默认把所有数据一次性读进内存，数据大了就爆内存；对缺失值、混合类型的支持也很差。所以你不能拿 NumPy 直接分析一张有表头、有字符串、有空值的业务表，那是 pandas 的活。

import numpy as np

a = np.arange(12).reshape(3, 4)
b = np.array([10, 20, 30, 40])

print(a * 2)        # 整个数组乘 2，不用 for
print(a + b)        # 广播：b 自动扩展成 3x4 再加
print(a.mean(axis=0))  # 按列求平均

pandas：表格处理的事实标准

官网：https://pandas.pydata.org

如果说 NumPy 是数组，pandas 就是"带行列名的表格"。它提供两个核心对象：Series（一列）和 DataFrame（一张表）。你在 Excel 里干的所有事，筛选、排序、透视、分组、合并、填充缺失值，pandas 都能干，而且能处理几十万行这个量级。

典型场景：数据清洗（这一步能占数据分析 70% 的时间）、特征工程、时间序列分析、结果汇总。它能直接读 CSV、Excel、JSON、SQL、Parquet，非常省事。

优势是生态和文档无敌。你遇到的几乎每个问题，网上都有现成的 pandas 答案；API 也符合直觉，df[df['age'] > 18] 这种写法一看就懂。

劣势主要有三个。第一，内存吃紧，它默认还是全量加载，数据超过内存就很尴尬。第二，它是单线程的，现在 CPU 核心那么多，它却只用一个，浪费。第三，历史包袱重，有些老 API 设计得别扭，你可能会经常看到 SettingWithCopyWarning 这种警告，本质是它想区分"视图"和"副本"，但设计得不够干净。

import pandas as pd

df = pd.read_csv("sales.csv")
df = df.dropna(subset=["amount"])
summary = (
    df[df["amount"] > 0]
    .groupby("region")["amount"]
    .agg(["count", "sum", "mean"])
    .sort_values("sum", ascending=False)
)
print(summary)

Matplotlib：最经典的画图库

官网：https://matplotlib.org

Matplotlib 是 Python 里历史最久、最经典的画图库，几乎任何静态图它都能画，折线、柱状、散点、热力图、等高线、3D 图，要什么有什么。它的另一个身份是"底座"：seaborn、pandas 的 .plot() 底层调的都是它。

典型场景：论文插图、报告里的图表、任何需要精确控制的地方。它的控制力可以细到"这个刻度标签旋转 45 度、字号 8、颜色 #333"。

优势是全能、可控、稳定，画出来的图能直接进期刊。

劣势是默认样式比较丑，得自己调；它有两套 API（pyplot 快速版和面向对象的 Figure/Axes 版），新手经常搞混；交互性差，图上不能缩放拖拽。所以日常探索数据我更爱用 seaborn，要精细排版才回来用 Matplotlib。

import matplotlib.pyplot as plt

fig, ax = plt.subplots(figsize=(6, 4))
ax.plot([1, 2, 3, 4], [1, 4, 9, 16], marker="o")
ax.set_xlabel("x")
ax.set_ylabel("y")
ax.set_title("demo")
plt.tight_layout()
plt.savefig("demo.png", dpi=150)

SciPy：科学计算的工具箱

官网：https://scipy.org

SciPy 是建立在 NumPy 之上的一整套科学计算算法库。它按功能分了很多子模块：scipy.optimize（优化、求根、曲线拟合）、scipy.integrate（积分、解微分方程）、scipy.interpolate（插值）、scipy.stats（统计分布和检验）、scipy.signal（信号处理、滤波）、scipy.sparse（稀疏矩阵）、scipy.linalg（线性代数）。

典型场景：给一组实验数据拟合一条曲线、做傅里叶变换、算 t 检验、解一个常微分方程。做科研和工程的基本都要用到。

优势是算法全、经过几十年打磨、可靠。劣势是它的 API 比较"科学"，不像 pandas 那么友好，参数多、文档偏学术；而且它和 NumPy 边界有点模糊，新手经常不知道某个函数该去哪找。我的经验是：数值数组操作找 NumPy，需要"某个具体算法"的时候去 SciPy 翻。

import numpy as np
from scipy import stats

data = np.array([1.2, 1.5, 1.1, 1.8, 1.4])
print(stats.describe(data))
# 跟 1.0 比，看有没有显著差异
print(stats.ttest_1samp(data, 1.0))

三、统计和可视化：让数据说人话

四件套之后，如果方向偏"分析"而不是"工程"，这两个库要补。

statsmodels，官网 https://www.statsmodels.org 。它跟 scikit-learn 不一样，scikit-learn 关心"预测得准不准"，statsmodels 关心"这个变量到底有没有影响、影响多大、显不显著"。回归、方差分析、时间序列（ARIMA）、假设检验，它给的输出是一张完整的统计表，p 值、置信区间、R² 全都有。做经济学、社会科学、医学统计的人离不开它。劣势是速度慢、API 偏统计学思维，做大规模预测不合适。

seaborn，官网 https://seaborn.pydata.org 。它建在 Matplotlib 上，专治"统计图"。一行代码就能画出带回归线的散点图、分组箱线图、相关性热力图，默认配色还好看。做探索性分析（EDA）的时候，它是我的第一选择。劣势是自由度不如 Matplotlib，画很特殊的图会受限，而且它默认在背后偷偷调 Matplotlib，出问题的时候错误信息会有点绕。

Plotly，官网 https://plotly.com/python/ 。它的卖点是交互：图能缩放、悬停显示数值、点击筛选，还能直接嵌到网页里。做数据看板、要给非技术同事演示的时候特别好用。plotly.express 那套接口跟 seaborn 一样简洁。劣势是图比静态图重、导出成图片要额外装东西、离线环境配置稍微麻烦。

四、机器学习：scikit-learn 打底

官网：https://scikit-learn.org

scikit-learn 是传统机器学习（非深度学习）的标准库。它最值钱的地方不是算法多，而是接口统一：所有模型都是 fit() 训练、predict() 预测、transform() 转换。你学会一个，就等于学会了几十个。它还提供了 Pipeline（把预处理和模型串成一条流水线）、交叉验证、网格搜索、各种评估指标，做完整实验流程够用了。

典型场景：分类（这封邮件是不是垃圾邮件）、回归（明天销量多少）、聚类（这些用户能分成几类）、降维（把高维数据压到二维画图）。

优势是接口一致、文档有大量示例、算法覆盖全、依赖轻。劣势是它不做深度学习（神经网络部分很弱，真要做 CNN、Transformer 得换 PyTorch），也不擅长超大规模数据（数据太大要配 Dask 或换 Spark），而且它默认单机内存计算。

from sklearn.datasets import load_iris
from sklearn.model_selection import train_test_split
from sklearn.ensemble import RandomForestClassifier
from sklearn.metrics import accuracy_score

X, y = load_iris(return_X_y=True)
X_train, X_test, y_train, y_test = train_test_split(X, y, test_size=0.2, random_state=42)

model = RandomForestClassifier(random_state=42)
model.fit(X_train, y_train)
print(accuracy_score(y_test, model.predict(X_test)))

如果你做的是表格数据（业务数据、实验数据这类），那真正在比赛和生产里占据主流的往往不是神经网络，而是梯度提升树：

XGBoost：https://xgboost.readthedocs.io
LightGBM：https://lightgbm.readthedocs.io

这俩在结构化数据上的精度和速度，通常比随机森林更好，Kaggle 上表格比赛的获奖方案里一半以上都有它们。优势是精度高、能处理缺失值、有特征重要性、训练快（LightGBM 尤其快）。劣势是参数多、调参要经验、可解释性不如线性模型，而且容易过拟合，得靠交叉验证和正则化压住。

再往上就是深度学习。PyTorch（https://pytorch.org ）现在是学术界和工业界的主流，接口灵活、调试方便。但它需要 GPU，学习曲线也陡，如果你只是想做数据分析，我建议先别碰，把 scikit-learn 吃透了再说。真要做图像、文本、大模型相关，再单独安排时间。

五、数据变大的时候，该怎么办

前面那套在几十万行、几百 MB 的规模上很舒服。数据一旦涨到几 GB、几十 GB，pandas 就开始卡、开始爆内存。这时候有几条路。

Polars，官网 https://pola.rs 。它是用 Rust 写的 DataFrame 库，多线程、列式存储、还带查询优化，单机处理速度比 pandas 快很多（官方说能到几十倍，实际看场景）。API 跟 pandas 有相似之处，学起来不算难。劣势是生态还不如 pandas 成熟，很多第三方库只认 pandas，而且有些写法跟 pandas 不一样，迁移要改代码。

DuckDB，官网 https://duckdb.org 。它是个"能嵌进 Python 里的分析型 SQL 数据库"，不用起服务器，pip install duckdb 就能用。你可以直接对 CSV、Parquet 文件跑 SQL，还能和 pandas DataFrame 互相转。数据大到内存装不下，它也能靠流式处理扛一扛。劣势是它是 SQL 思维，习惯 pandas 链式写法的人要适应；对非表格的复杂数据结构支持一般。

PyArrow，官网 https://arrow.apache.org/docs/python/ 。它是 Apache Arrow 的 Python 接口。Arrow 是一种列式内存格式，Parquet 文件、DuckDB、Polars、pandas 之间能"零拷贝"共享数据，靠的就是它。你平时不一定直接写 Arrow 代码，但了解它有助于理解为什么现在这套工具能跑那么快。

Dask，官网 https://www.dask.org 。它解决的是"数据比内存大"和"想用多核/多机"的问题。它的 DataFrame 接口跟 pandas 基本一样，把 pd.read_csv 换成 dd.read_csv，最后加个 .compute()，就能把计算自动切块、并行跑到多个核心甚至一个集群上。劣势是它的延迟计算模型（lazy）跟 pandas 的即时计算不一样，调试时不容易一眼看到中间结果；小数据上用它是杀鸡用牛刀。

我个人的建议：先别急着学 Dask 和 Polars。把 pandas 用熟，遇到真的扛不住的数据，再按需换。

六、数据从哪来：Kaggle 和 ModelScope

如果你手上没有数据，或者想拿真实数据练手，最省事的办法是去公开数据集平台直接下。国内用得多的是这两个。

Kaggle，官网 https://www.kaggle.com ，数据集板块在 https://www.kaggle.com/datasets 。它是全球最大的数据科学社区和竞赛平台，公开数据集有几十万个，房价、天气、医疗、金融、图像、文本各个方向都有。好处是数据质量相对可控，每个数据集都有说明，还能看下载量和投票数来判断靠不靠谱；它自带免费的在线 Notebook（有 GPU 额度），本地环境都不用配就能跑；社区里还有大量别人分享的代码（kernel），可以拿来学别人怎么做特征、怎么建模。劣势是国内访问不稳定，经常得借助网络工具；数据集以英文和国外场景为主；部分竞赛和数据集要接受规则或完成手机验证才能下载。

想在本地用，装个官方 CLI，配上 API token 就能拉：

pip install kaggle
# 把 kaggle.json 放到 ~/.kaggle/ 下
kaggle datasets download -d <owner/dataset-name>

ModelScope（魔搭），官网 https://www.modelscope.cn ，数据集板块在 https://www.modelscope.cn/datasets 。它是阿里推出的模型和数据社区，国内访问速度快，中文数据集比 Kaggle 多不少，很多是国内机构、高校发布的数据，做中文 NLP、中文问答这类任务很合适。它既能在网页上直接下，也能用 modelscope 这个库拉取，和 Python 脚本集成很方便：

pip install modelscope

from modelscope.msdatasets import MsDataset

ds = MsDataset.load("<数据集名>", subset_name="default", split="train")

优势是国内直连、下载快、中文数据友好、和自家的模型库打通。劣势是数据集的绝对数量和沉淀时间不如 Kaggle，检索和筛选体验也还有提升空间，部分数据集需要登录甚至申请授权才能用。

简单说：练手、找英文和通用数据，去 Kaggle；找中文数据、想下载快，去 ModelScope。两个都注册一下，不麻烦。

七、按方向再延伸

上面是通用底座。如果你有比较关注的具体领域，再挑对应的库：

地理空间数据：GeoPandas（https://geopandas.org ），把 GeoJSON、Shapefile 当 DataFrame 处理。我早些年做地球化学、空间分析，这类库很实用。
图/网络：NetworkX（https://networkx.org ），社交网络、关系分析。
图像：OpenCV（https://opencv.org ）做工程级图像处理，scikit-image（https://scikit-image.org ）偏科研算法。
文本：中文分词用 jieba，工业级 NLP 用 spaCy（https://spacy.io ）。我在《Python NLP 利器：分词与词性标注库总结与实战》里详细写过，这里不重复。
符号计算：SymPy（https://www.sympy.org ），推导公式、解方程、求导积分，写教程和做理论验证很方便。

八、日程上怎么排

工具列了一堆，但假期有限，贪多效果可能最差，开心快乐最重要，核心原则是项目驱动，别只看教程。

前两天，装环境 + 啃 NumPy。把 ndarray、切片、广播、轴（axis）这几个概念搞清楚。

接下来，主攻 pandas。读文件、筛选、分组聚合、合并、处理缺失值、时间序列。这是投入产出比最高的一段，学完立刻能干实事。

用 pandas 的同时，就可以搭配 matplotlib + seaborn。学会画折线、散点、柱状、箱线、雷达图、热力图这五种就够覆盖大部分需求。

都弄完了，scikit-learn。走一遍完整流程：划分训练测试集、训练、预测、评估、交叉验证。再了解一下过拟合和正则化。

在这个过程中，找一份感兴趣的数据，争取做一个完整的、自己感兴趣的小项目。这一步最关键。比如：

从某个公开 API 抓数据（天气、股票、GitHub 仓库），清洗后做统计，画图，最后写个简单预测。
从 Kaggle（https://www.kaggle.com ）或 UCI 数据集仓库（https://archive.ics.uci.edu ）下一个数据集，从零做一遍分析。
用天池（https://tianchi.aliyun.com ）上的入门赛题练手。

一个完整项目走下来，比看十个教程学到的都多。因为你一定会遇到教程里没讲的问题：编码不对、日期格式乱、缺失值一堆、某个库版本不兼容，这些才是真实世界的常态。

九、一点建议

别贪多。 有人一上来就想把 NumPy、pandas、PyTorch、Spark 全学了，结果十天过去每个都只看了个开头。四件套吃透，比什么都会一点强得多。

尽量别看视频。 看视频容易觉得都懂了，自己一写就卡壳，这是常态。数据科学这东西，代码一定得动起来。看一段，自己敲一遍，改改参数看看结果怎么变。

数学不是拦路虎，但迟早要补。 刚开始做数据分析，统计里会算个均值方差、会看 p 值，线性代数知道矩阵乘法怎么回事，就够用了。等你要深入建模、理解算法原理的时候，概率统计和线性代数就得认真学，遇到啥就学啥，反正现在查资料也方便。

环境问题会吃掉你一半时间。 这不是你的错，是这个生态的现状。装库失败、版本冲突、编码报错，遇到就慢慢查，别怀疑自己智商。装好一次环境、存一个能用的配置，以后能省很多事，而且尽量自己学会，不要只靠AI帮忙完成。

按这个路走下来，至少能从一个"会写 Python 语法的人"变成"能独立做一份数据分析的人"。

祝同学们假期过得充实。

把文本打包成 ZIM 文件既能直接读还能省空间

2026-09-16T12:00:00+08:00

最近整理本地资料，希望能节省一些硬盘空间。

因为我用的是当初教育优惠叠加分期免息的最丐版的MacBook Air M4，配置也比较低，硬盘空间也很少。

为了给在投的刊物凑版面费（N记子刊的版面费真可怕），趁着内存和固态以及笔记本电脑最近价格上涨，将之前用的微星游戏本（7945HX+64G+4070 8G+ SN850X 4T）以及一些其他的固态硬盘陆续都卖掉了。

于是手上的存储空间就有点紧张了，所以把手里几乎所有成规模的文本，都打包成了 .zim 格式。

相声文本库、公有领域的世界文学名著、几千篇 AAAI 的论文、几万篇 arXiv 论文，都压缩成了一个个 .zim 文件里。

这篇文章就说说 ZIM 这个格式。

ZIM 是什么

先说清楚 ZIM ，这是 Kiwix 项目用的文件格式。

Kiwix （ https://kiwix.org/en/about/ ）是做离线内容的开源项目，你可以在没有网络的时候，用 Kiwix 打开一整个维基百科。

ZIM 就是它背后存数据的容器：一个文件，里面可以装下几十万篇文章，打开 Kiwix 就能直接浏览、搜索、跳转。

我这些年一直尽量用本地的离线模型，也经常用这类离线的内容工具。

可能有同学不太理解：现在上网这么方便，何必非得用离线的？

这其实跟我以前做地球科学的经历有关。那会儿在青藏高原、呼伦贝尔、大兴安岭这些地方跑野外，很多区域根本没有网络覆盖，想查点东西只能靠本地文件一条条翻，特别费劲。

所以我一直盼着，要是能把一些网站做成这种既压缩、又能检索、还方便人来读的工具，那就太省事了。

后来有一些文本文件从TXT变成了MD文档，固然是能够用一些工具去搜索，但始终不那么方便，跟网站阅读还是没法比的。

第一个原因：压缩，真的省空间

文本是压缩空间最显著的东西，没有之一。

这个道理想想就明白：一篇中文文章，里面翻来覆去就是那几千个常用字，"的""了""是""我""一个"这些词反复出现，重复率高得吓人。压缩算法最擅长的就是对付这种重复，所以文本的压缩率往往能到七八成甚至更高。几百兆的纯文本，压完可能就剩几十兆。

拿我自己实际做过的几个文件来说：

相声文本库：234 个段子，一百多万字，压成 .zim 之后只有 4.5 MB。
公有领域世界文学名著集：559 部作品（荷马、但丁、莎士比亚、托尔斯泰……从古希腊到 20 世纪），113.9 MB。这个数字包含了大量英文原著和翻译版，要是散成一个个 .txt 或者 .md 文件放着，体积要大不少。

其他类型的文件当然也能压缩，图片、音频都有专门的压缩格式，但它们的压缩空间远不如文本。一张已经压过的 JPEG 图片，你再压也压不出多少；而一段纯文本，压出来的效果是立竿见影的。所以如果你手里有大量文本要归档，压缩这件事的收益是最高的。

第二个原因：ZIM 不是"压缩包"，不用解压

这是 ZIM 和 zip 最本质的区别。

zip 是个压缩包，想查看一个 zip 里面的文件，得先解压，解压出来的东西再占一份空间，然后才能用里面的文件。用完了想省空间，又得把解压出来的删掉。一来一回，麻烦，而且解压这件事本身就要临时占用额外的磁盘。

ZIM 不一样。它不是"先压起来、要用再解开"，而是"压着也能直接读"。你装一个 Kiwix（或者用 libzim 这样的库），就可以直接打开 .zim 文件翻文章、搜关键词，整个过程不需要把整个文件解压出来。数据在磁盘上就一直是压缩状态，读哪一篇，就解哪一篇，读完还保持压缩。

这一点对我这种"存一大堆、偶尔翻一篇"的场景特别友好。我想查相声《买猴》的原文，不用先把 234 个段子全解压出来，直接打开 ZIM 搜"买猴"就行。

第三个原因：它像一个原始版的知识库

这是我觉得最有意思的一点。

现在大家都在让大模型帮忙实现 RAG、挂载访问知识库、实现高效率的向量检索。一个正经的知识库，要做文本切块、向量化、语义相似度检索，维度高、工程复杂。而 ZIM 提供的是另一种东西——一个最原始形态的知识库。

它没有向量，没有语义相似度分析，就是一个"文章集合 + 全文索引"。但它是可编程访问的：用 libzim 这类库，程序可以直接遍历 ZIM 里的每一篇文章，读标题、读正文。这就意味着，你可以让一个智能体工具直接去访问一个 ZIM 文件来查资料。

模型通过 libzim 打开 ZIM，把文章一篇篇读出来，然后做分词、做主题模型、做统计分析。整个过程里，ZIM 扮演的角色就是"语料库"：数据规规整整地待在一个文件里，模型按需取用。

说白了，它就是个"能装很多文章、能全文检索、能被程序读取"的容器。它没有现代知识库那么高的维度，做不了"这段文字和那段文字语义像不像"这种分析，但作为"把一批文本喂给模型去读"的原始底座，完全够用，而且轻量、省事、一个文件走天下。

顺便说一句：怎么用它

如果只是阅读，装个 Kiwix 客户端（用winget和brew都可以安装），打开 .zim 文件就行。

如果想让程序或 AI 读，用 Python 的话装个 libzim：

pip install libzim

然后就可以用代码来访问了：

from libzim.reader import Archive
zim = Archive('相声文本库.zim')

# 遍历整个 ZIM 里的所有条目
for i in range(zim.all_entry_count):
    entry = zim._get_entry_by_id(i)
    print(entry.path, entry.title)
    content = entry.get_item().content  # 文章的正文（bytes）

# 或者按路径直接取某一篇
entry = zim.get_entry_by_path('传统单口相声/打灯谜.html')
text = bytes(entry.get_item().content).decode('utf-8')

这么几行，就能把整个 ZIM 里的内容交给下游处理了。如果你手里也攒着一堆文本，与其让它们散成一地文件，不如试试装进一个 .zim 里。

教师节的一场梦：我的第一次"战或逃"

2026-09-10T00:00:00+08:00

教师节的一场梦：我的第一次"战或逃"

今天是教师节。我也当了好些年的老师了，今天还受了表彰。本来是件挺高兴的事，可我心里特别无奈：表彰现场，很多孩子准备了花，我的花粉过敏突然就严重起来，喘不上气，心里发慌。我赶紧跑到附近的医院，吃了抗过敏的药，又吸了会儿氧，这才缓过来。

医生让我别再进室内，就在空气流通的室外歇着。歇着的过程中，我还看到一位朋友分享的一张图。也不知道是在哪个国家、什么地方，大意是说，有些孩子坐着在那儿喝牛奶还是什么饮料，另外一些孩子站在后面喝水。我状态不好，也没细看，估计是国外的什么地方吧。

这事我没太往心里去，于是就睡着了。睡梦中，想起小时候做过的一个个梦。

不讲教材，而是要讲教辅书

我梦到，我跟着父母四处打工、到处借读。第一次进的那所小学，大概是三年级，学校要求所有学生都买一本叫"目标与培养"之类的教辅书，说上课不讲教材，只讲这本书。

那会儿我还小，根本不知道人家就是为了挣这个钱。我的想法很简单：把这书拿回去，让我妈在打工之余有空的时候，帮我抄下来一本，然后我拿着写就行。

后来我还真就这么干了。我找同学借了一本，拿回家让我妈帮我抄。那好像是数学的，字不算特别多。我妈还挺认真，帮我工工整整写了一个本儿。弄好之后，我拿着这个抄本去了学校，结果它不高兴了，问我：这东西你怎么没去买那本书呢？我说，我抄下来了，让我妈抄的，我做这上面的题，这样我也能跟着你们听课。它很生气。

那学期就那么糊弄着，没几天也就过去了。到了第二学期，其他同学也有一些人不再买了，他们好像是复印的，纸的质量不太好，有点发暗，上面的油墨像是复印出来的，而且每个人的那个本子上印的油墨笔迹看着好像都一样，我怀疑是有人先抄好一份，大家再拿去复印。好多人都不去买那本"目标与培养"了。结果呢，第二学期它就不讲这本书了，改讲别的书。

后来我才慢慢明白，它那会儿的目的，可能就是为了卖大家书、想挣钱。

从那时候起，只要有人要求我们"自愿"统一订购什么，我就本能地开始厌恶。

可那会儿我大概才八九岁，还不足以跟人家对抗。一次更激烈的对抗，要等到下一次。后来我转到另外一个学校，那时候我已经十来岁了。

它让我必须自愿订购豆奶

那一次，它要求我们每个人，必须自愿每个月花十八块八，订购一种豆奶。

是叫喵喵豆奶还是苗苗豆奶，我记不清了，反正是这么个东西。

我没有钱，我说我不定。它就在那儿辱骂我。我跟它说，你说那些也没用，我就是不定。它还是不依不饶，接着讽刺我。

它说我在搞特殊，说怎么就你一个人特殊。然后还说我浪费大家的时间，浪费一个人一分钟，就是浪费了八十多个人八十多分钟。

我能感觉到，它是在用一种强盗的、流氓的、非常无耻而鄙陋的蠢蛋逻辑来胡搅蛮缠，想让其他同学一道来讨厌我、攻击我。

可那会儿我已经想好了，这些我都不在乎。我不在乎与任何人为敌，我就是要捍卫我这十八块八，我不能花这个钱，我需要这些钱。

于是干脆直接跟它说：你说这些话都没用，我不想定。你弄死我我也不定；你弄不死我，我还不定，我跟你斗到底，我就是不服，你叫我找家长也没用，我家也没有电话。

我坚信不能被这种"被自愿"的要求打败，我绝对不投降。

那年我大概十一岁。

它并没有过来弄死我，而只是不让我听课，不只是它的课，让我在别的课上也站着。

其实它自己也不怎么讲课，课上主要也就是骂我。

现在想想，我挺佩服小时候的那个自己。

我当时是一个10来岁的孩子，能够在那种情况下忍受着一节又一节的那种火力的嘲讽语言的霸凌，应该忍了大概有一个月或者至少有两三周。

我给自己鼓劲，而且每次都明跟它说，你的课你也不讲什么，我自己会去学，你不讲我也能学会；其他的课你有能耐就在这儿看着我，你不在这我就听课，你有能耐一天都跟我耗着么？大不了你过来，你敢过来咱们就拼命。

后来，它也并没有跟我拼命，也不再骂我或者追打我了，甚至也不再逼着我订豆奶了。

然后这过程中，也逐渐地听说有一些老师对它去干扰人家上课也是颇有微词，而且对他的很多言行也颇为不齿。看来毕竟是好人多呀。

再往后，它就不当我们班的班主任了。据我所知，好像还有另外几个同学，也开始不定了。

在我明确表示不定、并且公开跟它唱反调之前，其实别的同学都还是半推半就地接受了。

当时我确实是太穷了：我一顿饭吃一张卷饼加个鸡蛋才五毛钱，要是有一块钱，我就能吃盒饭了，一块五的盒饭里能加一片火腿，那都算很好了。

所以一个月十八块八，对我来说是很大的一笔钱，我甚至愿意为它去拼命。

它要是强行想从我这儿抢走，我没有那个钱，所以我心里有底气；真要是我兜里有那些钱，我还真怕它过来抢。

那时候我觉得这是我遇到的最重要的事情，绝对不能同意，要是同意了，就没机会了。

这大概是我人生里第一次意识到自己身上那种动物性的本能——战或逃（fight or flight），第一次想要去保护自己、捍卫自己，甚至不惜跟它拼命。

那会儿我觉得，世界上没有比它更坏的了；它那种行为，简直就像是在抢劫我一样。

我要战胜眼前这个肮脏恶臭、令人厌恶的东西。别看它衣着光鲜、外表体面、目光柔和，我知道它内里究竟是什么样子。我甚至不惜跟它拼命，我做好了它冲过来扑向我的准备。

可就在这时候，我心里又冒出另外一个念头：我也要当老师，我要当一个更好的老师，要在这个行当里，彻底胜过这个丑陋的东西。

当然，这只是一个梦，一个噩梦。这个梦，终于醒了。

关于教师节送礼

之前我就跟人说过，教师节就别送礼。

我也希望我带过的那些同学，等他们当了师兄师姐，也别让底下更小的学弟学妹给他们买东西、送奶茶之类的。

我就想，当老师是个职业，有工资拿，为什么还要去拿别人的东西呢？

我始终觉得收礼是件很不体面的事。

我梦到过有的学生考研到了某个所谓老牌名校，那的师兄师姐要求大家一块儿凑钱，凑个挺大的数目，几千块钱，给导师买东西。

我梦到过有的学生考研到了某个不太名校的地方，他们的导师居然要让他们学生出钱给自己付钱打五百块一场的球，然后下个月从补助里面扣除。

我梦到过有的学生考研到了某个老牌名校，导师每个月给他们打劳务费到卡里面，然后再让他们去取出来现金交还回导师手里。

这都还好只是梦，都是很不成体统的事，很可能是那个师兄师姐自己别有用心，很可能那个导师作风不正，很可能有人套取经费等等，总之都是想借这个机会捞点什么。

我甚至还梦到中小学里面有的家长，带着一种谄媚的心理，撺掇着说：大家咱们一起给老师买点什么。

这种逢迎钻营、惯于讨好的人，自古就有，好像是可以称之为「奸佞」，是最要不得的。

很多道理，小时候就懂了

有很多道理，其实我们小时候就懂了。幼儿园就告诉我们，不要撒谎，要诚实，要善良，不要强迫别人，不要伤害别人。有的甚至写到了纸上，写成规则。

到了小学，老师还是这么讲，翻来覆去地讲，好像这些道理是天底下最要紧的事。

可当时我在梦幻中就早已经发现，那些把道理讲得头头是道的大人、老师，有的人自己未必真那么信，也未必真那么做。

讲归讲，做归做，说出口的和做出来的，常常是两回事。我不想成为那样的人，也不希望有一天，自己变成当年最看不惯的那种样子。

我以前听一个朋友说过（当然，也是做梦听到的），他说，如果一句话里说"原则上"如何如何，那就说明这个原则是可以打折扣的。

语言被污染成这个样子，真可怕。因为它可能意味着，思想上的污染早就存在了，甚至早就被人接受了。

教师节呀，就希望能顺顺当当地，好好教孩子们，也就行了。

当年那个宁可罚站、也不肯低头的十一岁小孩，二十多年后，他自己不仅成了老师，还会站在表彰台上。

希望，站在台上的这个人，永远不要变成当年梦里那个逼人订豆奶的老师。

祝大家教师节快乐。

16G 显存怎么跑本地大模型

2026-09-09T20:00:00+08:00

16G 显存怎么跑本地大模型？

不是每个人都有 24G、32G 的卡。手里一张 16G 的 RX 6800 XT、RTX 4060Ti 16G、5060Ti 16G，或者笔记本上的 16G 显卡，同样想跑本地大模型，该怎么选模型、选量化、调参数？这回咱们看看 16G 这个档位上的真实取舍——模型尺寸怎么定、量化选哪档、上下文和 KV 怎么压、A 卡和 N 卡差在哪，全部综述于论坛的真实实测，出处编号见文末。

一、先认清 16G 的天花板在哪

16G 显存的尴尬，用论坛网友的话说最贴切："能用，但是又不省心。像鸡肋，食之无味，弃之可惜。"[2] 具体卡在哪三处：

权重装得下，KV 就紧张。 主流的 Qwen 27B 模型，Q4_K_M 量化后权重约 16.5GB——光权重就顶到 16G 天花板，再想留上下文空间就得 offload 到内存[4]。
Agent 场景吃上下文。 Hermes 这类工具自带 system prompt 就 15K 左右，做稍微复杂的任务马上就 OOM（显存溢出）[2]。
量化越狠，上下文越省，但智商越掉。 这是一个必须权衡的三角：模型尺寸、量化精度、上下文长度，16G 上只能同时要两个。

好消息是：只要量化选对、参数调对，16G 跑 27B 是完全可以当生产力用的。下面逐项拆。

二、模型尺寸怎么选：27B 稠密还是 35B MoE

16G 上最值得考虑的其实是两类模型，而不是一路往大堆。

选择一：27B 稠密（Dense）——工具调用最稳

Qwen3.6 / 3.8-27B 是社区公认的"16G 能跑的最强 Agent 模型"，理由很直接：27B 密集参数的工具调用（function calling）稳定性远好于同尺寸 MoE[3]。用 llama.cpp 加载，4bit 量化 + 16K 上下文约 14.5GB，还有余量[3]。

它的短板是速度一般、上下文紧张。但如果你主要拿来跑 agent、写代码、需要稳定的指令跟随，27B 稠密是首选[3]。

选择二：35B-A3B（MoE）——速度与上下文的"降维打击"

如果你被 27B 的速度和上下文折磨，MoE 是 16G 上的另一条路，而且是论坛实测里"反直觉"的惊喜：总参数更大的 35B-A3B，实际显存占用反而比 27B 全层稠密还低（35B 只需把 26 层放 GPU，14 层 offload 到 CPU）[6]。

实测对比（RTX 5070 Ti 16G，同一台机器）[6]：

指标	27B 稠密	35B-A3B MoE
显存占用	15,048 MiB	14,826 MiB
上下文	98K	128K
短 prompt 首字	0.52s	0.24s（快 2.2 倍）
短 prompt 生成	12.7 t/s	48.0 t/s（快 3.8 倍）
长 prompt 生成	13.3 t/s	51.7 t/s（快 3.9 倍）

原因在于 MoE "每次只激活 3B 参数"——显存带宽固定时，读取量变成 1/9，速度自然暴涨[6]。

代价：MoE 是"局部专家各自为战"，在需要跨几十步的深层逻辑推导（复杂数学证明、大型架构重构）时，27B 稠密的逻辑连贯性有时反而更好[6]。所以结论是：跑 agent、追求速度与上下文 → 35B-A3B MoE；追求单步推理的严密与工具调用稳定 → 27B 稠密[3][6]。

还有个"更聪明"的思路：与其硬塞 27B，不如退一步用更小的模型换满上下文。16G 上 Qwen3.5-9B Q8_0 全精度可以跑满 128K 上下文，响应速度比 27B 快 2-3 倍，轻量级 Agent 任务完全够用[3]。别被"参数越大越好"绑住，因为如果不是写代码之类的任务，而只是文本翻译之类的，9B 其实也能用。

三、量化怎么选：这是 16G 的核心功课

量化决定了"权重占多少显存"，直接影响你能开多大上下文。以 Qwen3.8-27B 在 16G 卡上为例，论坛整理出的量化对比表如下[4]：

量化	大小	最小显存	单流 TG (tok/s)	Prefill (tok/s)	代码质量	16G 推荐度
IQ4_XS	14.8 GB	15.8 GB	38-43	~1350	⭐⭐⭐⭐	全层上卡首选
Q4_K_M	16.5 GB	17.5 GB	18-27（需 offload）	~1240	⭐⭐⭐⭐⭐	质量优先，需 offload 2-4 层
Q5_K_M	19.8 GB	21 GB	34-36	~1080	⭐⭐⭐⭐⭐	需 24G 卡
NVFP4（50 系专用）	~13 GB	14 GB	55-65	~1800	⭐⭐⭐⭐⭐	未来首选，待框架支持
Q3_K_L	14.2 GB	15.2 GB	44+	~1420	⭐⭐	不推荐生产

几个关键结论：

16G 卡上，IQ4_XS 才是"全层上 GPU"的正确选择，不是 Q4_K_M。Q4_K_M 权重 16.5GB + 32K KV 约 1.2GB = 17.7GB，物理上超了 16G，硬上只能 offload 部分层，速度掉到 18-27 t/s；而 IQ4_XS 权重 14.8GB，能全层上卡，速度 38-43 t/s[4]。
量化别贪低也别贪高。 Q3_K_L 虽然体积小、速度还行，但质量只给两星，"不推荐生产"；Q5_K_M 质量好但需 24G 卡[4]。
50 系（Blackwell）的 NVFP4 是"完全体"，约 13GB 就能跑、速度 55-65 t/s，但需要较新的 llama.cpp 支持（PR #21095 合并后）[4]。
UD 版（Unsloth Dynamic）比普通版更值：对敏感张量保留更高精度，纠错这类吃细节的任务推荐 UD-Q4_K_XL，体积大不了多少[7]。

A 卡用户注意：像 RX 6800 XT 这种 16G A 卡，实测可以用 IQ3_XS 级别的量化，开 MTP + q4 KV，勉强跑到 128K 上下文，此时显存占用 99%[1]。A 卡的 prefill 是短板，量化策略要更激进一些。

四、上下文与 KV 缓存：16G 的"走钢丝"艺术

16G 上能开多长上下文，几乎全由 KV 缓存决定。这块有三个实用技巧：

技巧一：KV 量化到 q4_0，上下文翻倍。 把 KV cache 量化到 4bit，能大幅压缩显存。27B 在 128K 上下文下，KV 量化后能省下大量显存[2][1]。但要注意：Agent 场景别用 q4 KV，因为需要精确理解工具 schema，质量会掉；建议 agent 用 q8_0、日常对话和代码补全用 q4_0，写两个启动脚本切换[1]。

技巧二：用 ik_llama.cpp 的 turboQuant，上下文直接翻倍。 这是 16G 玩家的一大发现：用带 turboQuant 的 ik_llama.cpp，原本只能稳定跑 20K 上下文的 16G 卡，极端双 q4 下能跑到 64K，速度还不变（25-27 t/s）。有人用 V100 16G 甚至跑到 100K[2]。

技巧三：上下文别贪，够用就行。 论坛经验：96K 对重度 Agent 仍可能触发上下文压缩；128K 在 16G 上跑 Q4 会"卡成狗"；65K 就能接入 Hermes 做很多项目，上下文压缩在可接受范围内[5]。超长上下文不适合所有工作，够用就行。

五、A 卡 vs N 卡：16G 上的真实差异

同样是 16G，A 卡和 N 卡的体验差别不小，这一点论坛讲得很实在：

N 卡（4060Ti/5060Ti/5070Ti）：CUDA 生态成熟、prefill 快、省心。 - 单卡 16G 跑 27B Q4 需 offload，速度约 8-15 t/s（DDR4 平台），"比乌龟强一点"[7] - 加第二张 16G 卡组 32G，速度跳到 35-50 t/s 量级（双 3060 43-50、双 5060Ti 65）[7] - 5070Ti 算力比 3090 强，但 16G 显存是瓶颈[10]

A 卡（RX 6800 XT）：prefill 是明显短板。 6800 XT 实测跑 27B IQ3_XSS + MTP2 + q4 KV，能勉强跑 128K 上下文（显存 99%），64K 上下文时 prefill 只有 200 t/s、生成 28-38 t/s。用 opencode 做简单代码开发够用，但 Hermes 读一次 tools 反馈要等 30 秒——这就是 AMD prefill 优化不如 N 卡的硬件生态问题[1]。

不过 A 卡也不是没救：换最新 llama.cpp + ROCm 后端、降低 KV 精度、开 --no-mmap --mlock 都能缓解 prefill 等待感[1]。如果你的工作重度依赖 agent、对首字延迟敏感，16G 档位建议优先 N 卡；如果只是代码补全、日常对话，A 卡够用且便宜。

六、MTP 投机解码：16G 上要不要开

MTP（多 token 预测）是常见的提速手段，但在 16G 卡上有个反直觉的结论：很多时候开 MTP 反而是负优化。

论坛实测：4060Ti 16G 跑 27B，开 MTP 后 decode 只有 12.8 t/s，关掉反而 18.9 t/s——因为 MTP 的草稿模型要多占 1-2GB 显存，16G 上本来就贴边，draft 计算开销超过了投机收益，接受率也低（平均约 2.3）[7]。同理，Qwen3.8-27B 的 MTP draft head 偏弱，接受率实测只有约 40%[7]。

16G 上的建议：先关掉 MTP 跑基线；真想试，从 --spec-draft-n-max 1 起步，别一上来就 2 或更高；长上下文时直接关掉（效果递减）[7][4]。相比之下，35B-A3B MoE 靠架构本身就能到 48-52 t/s，不太依赖 MTP[6]。

七、双 16G 卡：另一条路

如果你手上已经有一张 16G，或者预算允许，再凑一张 16G 组 32G 是 16G 玩家最划算的升级[7]。

双 4060Ti/5060Ti 16G 组 32G：Q4 权重全放下 + KV 富余，速度 35-50 t/s[7]
双 5070Ti 16G：张量并行高上下文稳定 52+ t/s，开 MTP 到 64-70+ t/s[8]
注意：5060Ti/4060Ti 不支持 NVLink，只能走 PCIe；写代码这类频繁交互场景，跨卡延迟比单卡明显[9]
PCIe 3.0 x4 够不够？够——tensor split 每 token 跨卡只传几百 KB 激活量，x4 损失个位数百分比，27B 规模没问题[7]

不过论坛老手的提醒也值得听：如果是全新买两张 16G，不如直接上单张 24G/32G——单卡省电、省心、无跨卡开销，二手 3090 的价格有时和新的 5070Ti 差不多甚至更低，却能跑 40+ t/s[10][9]。双 16G 更适合"已有卡再加一张"的情况。

八、给 16G 玩家的一张速查表

你的诉求	推荐模型	量化	关键参数
Agent / 工具调用最稳	Qwen3.6/3.8-27B 稠密	IQ4_XS（全层）或 Q4_K_M（offload）	KV q8_0（agent）
速度 + 长上下文优先	Qwen3.6-35B-A3B MoE	UD-Q4_K_M	`-ngl 26 -c 131072`，关 FA
轻量任务、要满上下文	Qwen3.5-9B	Q8_0	可跑满 128K
想榨出更长上下文	27B + ik_llama.cpp	IQ4_XS / Q3	turboQuant，双 q4 KV
50 系卡尝鲜	27B NVFP4	NVFP4	待框架支持，55-65 t/s
A 卡（6800XT）	27B	IQ3_XS 级别	MTP2 + q4 KV，接受 prefill 短板

模型尺寸：16G 上要么选 27B 稠密（工具调用稳），要么选 35B-A3B MoE（速度上下文碾压），别盲目追更大；
量化：全层上卡选 IQ4_XS，质量优先选 Q4_K_M 但接受 offload 掉速，50 系等 NVFP4；
参数：KV 用 q4_0 换上下文、agent 场景换 q8_0，MTP 在 16G 上多数是负优化，上下文够用就好。

16G 不是终点，但绝不是废物。选对模型和量化、把参数调到贴合你的场景，它一样能当生产力用。理性配置，量力而行。

参考来源

本文全部实测数据来自抡锤者（lcz.me）论坛会员的真实分享，原帖均可点击核对完整配置与测法：

16g 6800xt 推理 qwen 3.6 27b 的经验分享（已对 AMD prefill 速度的问题） — https://lcz.me/topic/181/181/16g-6800xt-推理qwen-3.6-27b-的经验分享-已经对amd-prefill-速度的问题（TID:181）
大模型 16G 卡的春天 — https://lcz.me/topic/174/174/大模型16g卡的春天（TID:174，ik_llama.cpp + turboQuant 上下文翻倍实测）
各位佬，当前最适合 16GB 显存的黄金模型是哪个？ — https://lcz.me/topic/868/868/各位佬-当前最适合16gb显存的黄金模型是哪个（TID:868）
RTX 5070 Ti 16GB 跑 Qwen3.8-27B：16G 卡量化选择、启动配置与基准数据 — https://lcz.me/topic/1207/1207/rtx-5070-ti-16gb-跑-qwen3.8-27b-16g-卡量化选择-启动配置与基准数据（TID:1207，核心量化对比表）
16GB 显存极限挑战：RTX 5070 Ti 本地部署 Qwen3.6-27B (Q4) 调优指南与实测报告 — https://lcz.me/topic/524/524/16gb显存极限挑战-rtx-5070-ti-本地部署-qwen3.6-27b-q4-调优指南与实测报告（TID:524，96K 上下文走钢丝）
RTX 5070 Ti 本地部署 Qwen3 35B-A3B (MoE) vs 27B (Dense) 对比报告 — https://lcz.me/topic/542/542/rtx-5070-ti-本地部署-qwen3-35b-a3b-moe-vs-27b-dense-对比报告（TID:542）
微星 B660M 迫击炮 + 4060Ti 16G + i7-12700K + DDR4 32G，本地部署 Qwen3.8-27B 怎么吐字最快？ — https://lcz.me/topic/1354/1354/微星-b660m-迫击炮-4060ti-16g-i7-12700k-ddr4-32g-本地部署-qwen3.8-27b-怎么吐字最快（TID:1354，单卡 offload 速度、MTP 负优化、双卡方案）
双 RTX5070TI 在 llama.cpp 环境下运行 Qwen3.8-27B 的效果 — https://lcz.me/topic/1268/1268/双rtx5070ti在llama.cpp环境下运行qwen3.8-27b的效果（TID:1268）
两张 5060ti 16g 想部署 qwen3.6 27b 用来写代码 — https://lcz.me/topic/188/188/两张5060ti-16g想部署qwen3.6-27b用来写代码（TID:188，双卡 vs 单卡取舍）
另类 16GB+12GB 配置 — https://lcz.me/topic/29/29/另类16gb-12gb配置（TID:29，单卡大显存 vs 多卡拼显存）

显卡选好了，其他配件怎么配？四大路线详解 X99洋垃圾/消费级/工作站/整机

2026-09-09T18:00:00+08:00

显卡选好了，其他配件怎么配？四大路线详解 X99 洋垃圾/消费级/工作站/整机

前面几篇聊了本地部署值不值、显存怎么选、显卡按价位怎么挑。这一篇解决最后一块拼图：显卡定下来之后，主板、CPU、内存、电源、机箱这些"配角"到底怎么配？ 同样的显卡，有人用 X99 洋垃圾平台 3000 块搞定整机，有人上最新消费级平台花一万多——差距在哪，分别适合谁？本文把论坛里真实玩家的四类装机路线全部拆开，附预算区间、适用场景、长处短板和抄作业清单，数据与观点均来自抡锤者（lcz.me）论坛的真实装机分享。

先说三个通用原则（任何路线都适用）

无论你走哪条路线，下面三件事是所有 AI 装机玩家反复强调的，先记牢：

电源是整机里最不能省、也最值得多花钱的配件。 论坛老玩家原话："电源这个东西最不能省，又是最耐用的，买一个好的 10 年都不会坏，也不担心把别的更贵的硬件搞坏。显卡会降价、CPU 会换代，但好的电源不会。"[1] 容量建议留到整机功耗的 1.5-2 倍以应付瞬时峰值（3090/7900XTX 瞬时功耗可达 450-800W+）[1][5]。千万别用老旧或没有品质保障的电源——轻则掉盘，重则起火[1]。
内存是"跑不跑得动"的关键，不是"跑得快不快"的关键。 权重主要在显存里，内存只参与加载和 offload，所以内存频率和时序对推理影响很小，容量才是重点[8]。内存容量一般按"模型加载 + 系统 + 预留"算，跑 27B 建议 64G 起步，跑大模型 + ComfyUI 同时开建议 128G[5][12]。
PCIe 通道数决定你未来能不能加第二张卡。 单卡随便什么板都行，但想升级双卡，主板必须有两根 CPU 直连的 x16 槽（或支持拆分 x8+x8），否则第二张卡只能跑 x4，白花钱[12][6]。这个坑非常多，下面每档都会提醒。

路线一：X99 洋垃圾平台（极致性价比 / 预算 3000-6000）

论坛讨论度最高、被叫做"抄作业"最多的路线。核心思路是：用退役服务器平台（华南金牌 X99 主板 + 洋垃圾 Xeon E5 CPU + RECC 服务器内存）把 CPU、主板、内存的成本压到极低，把预算全部砸在显卡上。

典型配置清单（抄作业）：

配件	型号推荐	预算
主板	华南金牌 X99-TF / X99-AD4 单路 ATX	300-500
CPU	E5-2686v4 / E5-2680v4（14-18 核）	100-300
内存	DDR4 RECC 4×16G=64G（四通道必须插满）	400-900
显卡	你选的 24G-32G 卡	主力预算
电源	长城/鑫谷 1000W 金牌	500-750
硬盘	1TB NVMe	400-500
机箱/散热	中塔机箱 + 风扇若干	200-500

怎么选 X99 板的三个要点（论坛老手总结）：①认准单路 ATX 板（X99-AD3/AD4/TF 这类），第一条 PCIe x16 必须是 CPU 直连满速槽；别碰双路板，单卡用双路纯浪费。②内存四通道必须插满 4 条才不浪费带宽——4×16G 起步，别买单条 32G×2 带宽直接腰斩。③CPU 选 v4 不用折腾"鸡血 BIOS"更省心；跑 ComfyUI 或大内存需求选 128G[2]。

真实成交价参考：一套"华南 X99-TF + E5-2686v4 + 128G DDR4"平台约 1900 元；某 7900XTX 整机（含显卡 6499 + 平台）总计约 1.06 万[3]；双路 E5-2686v4 + X99 双路板 + 64G 平台约 2800 元[12]。

长处： 价格无敌，CPU 核心多（18 核 36 线程"量大管饱"），内存白菜价能上 128G-256G，跑长上下文、同时开多个服务、CPU 通道兜底处理 N 卡专属模型（如 VOXCPM 走 CPU 也能跑）都从容[3]。 短板： 平台老（PCIe 3.0，双卡 TP 带宽受限）；DDR3 版与 DDR4 版别买错（插不进）；洋垃圾主板品控看运气、BIOS 折腾多、无保修；机箱风道和风扇噪音要自己打理[2][3]。 适合谁： 预算紧张但想上大显存显卡的低预算玩家、愿意折腾、不介意二手和噪音。

路线二：消费级新平台（省心省事 / 预算 6000-12000 不含显卡）

"不折腾、要保修、装完就能用"的主流路线。用全新主流平台（Intel B760/Z890 或 AMD B650/B850 + i5/R5 级 CPU）配一张中高端显卡，也是论坛老玩家给大多数普通用户的首选。

单卡方案（抄作业）： - CPU：R5 7600 / i5-13400F 级别就够（"模型全放 GPU 后，推理主要吃显卡，不需要 9950X 这种级别"）[7][6] - 主板：B650/B850 ATX 或 B760，认准第一条显卡槽 CPU 直连 x16、M.2 数量够 - 内存：64GB（2×32G）DDR5；预算紧 DDR4 也行（"DDR5 6000 和 DDR4 2133 对推理影响很小"）[8] - 电源：850W 起（7900XTX 建议 1000W）ATX 3.0/3.1[7] - 机箱：大风道中塔，注意显卡长度厚度

总预算参考：R5 7500F + B650 + 32G DDR5 + 850W + 1TB ≈ 3700 元[6]；i5-13400F + B760 + 64G DDR4 + 1000W ≈ 3300 元[6]。

长处： 全新有保修、装完即用、噪音功耗低、PCIe 4.0/5.0 带宽足、未来升级空间明确[6][7]。AMD AM5 平台还有"双卡原生 x8+x8"的板子可选（如 B850 AI TOP、X870E Creator），为将来留路[12]。 短板： 价格比洋垃圾高出一截，同样预算下显卡档次会被拉低；消费级板子双卡位选择要仔细看（很多 B 系列板第二条 x16 只有 x4）[12]。 适合谁： 大多数不想折腾的玩家、需要稳定工作的生产力用户、预算能覆盖显卡 + 新平台的人。

路线三：工作站/专业平台（多卡与极致性能 / 预算 1.5 万-3 万起不含显卡）

目标是双卡 TP、70B+ 大模型、或 4 卡以上 ComfyUI 集群的玩家，普通消费级平台满足不了，需要上工作站级或双路服务器平台。

关键认知：PCIe Switch 与 P2P。 想多卡真正高效协同，主板最好带 PCIe Switch（PLX）芯片实现物理 P2P。论坛给出的推荐排序： - 华硕 Pro WS TRX50-SAGE（PCIe 5.0、板载 Switch，综合首选，整机 1.5-2 万+） - 超微 H12D 系列（EPYC 双路、企业级、二手性价比极高，但机箱风扇噪音大，适合机房） - 华南双路 X99/X10（预算最低的双路，PCIe 3.0 带宽上限低）[9]

但必须泼的冷水： 论坛老玩家多次强调，如果只是跑 27B 这类单卡放得下的模型，双卡各跑各的，PCIe 3.0 还是 4.0 几乎没差别，选便宜的就行；只有上 70B 级走张量并行（TP）才真正吃 PCIe 带宽[8]。另外 A 卡（R9700/7900XTX）双卡没有 P2P，跨卡通信要绕主机内存，TP 效率大打折扣——想玩双卡 TP 老老实实选 N 卡[8]。

长处： 多卡扩展上限高、内存可上 128-512G、适合多人并发/多模型同时服务/训练。 短板： 贵、噪音大、占地大、功耗高（双路 E5 待机 100W+，满载 300W+ CPU 功耗）[4]。 适合谁： 明确要双卡 TP 或 4 卡以上、有场地放得下服务器、预算充足的重度玩家。

路线四：品牌整机/准系统（省心兜底 / 预算 4000-15000）

不想自己攒机、又想要服务器级扩展性的选择——直接买二手品牌工作站整机或准系统。

典型代表（论坛实测推荐）： - 戴尔 T7910 双路工作站：双 CPU 8 通道 DDR4 ECC + 1300W 原装电源，二手整机路线，比 X99 洋垃圾"省心一点但换机箱电源照样折腾"[2] - 联想 P910 准系统：适合装双卡（如双 R9700）但要注意机箱内部空间[11] - 这类机器的好处：原厂做工、供电扎实、PCIe 布局合理，缺点是体积大、年份老、升级空间有限[2][11]

长处： 原厂电源供电稳、扩展位多、适合"懒人上双卡"。 短板： 老平台性能受限、噪音大、内部布局紧凑改装麻烦。 适合谁： 不想自己挑配件、需要多卡又信不过杂牌洋垃圾板的玩家。

四条路线总对比

路线	平台成本	核心优势	主要短板	适合谁	备查
X99 洋垃圾	3000-6000	极致性价比、内存白菜价、CPU 核多	折腾多、无保修、PCIe 3.0	低预算/爱折腾玩家	[2][3]
消费级新平台	6000-12000	省心、有保修、安静低功耗	同预算下显卡档次被拉低	大多数普通用户	[6][7]
工作站/专业平台	1.5万起	多卡扩展、P2P、大内存	贵、噪音大、占地方	双卡 TP/重度用户	[9]
品牌整机/准系统	4000-15000	原厂做工、供电稳、扩展好	老平台、布局紧凑	不想自攒的多卡用户	[2][11]

预算导向的完整方案示例（含显卡）

把前几篇的显卡选择也串进来，给你三档可直接照抄的完整配置（价格为论坛 2026 年中的常见区间）：

低预算档（约 1 万元整机）—— X99 + 二手 3090 24G X99 单路板 + E5-2680v4 + 64G DDR4 RECC（约 1200 元）+ 二手 3090 24G（约 4500-5000 元）+ 1000W 金牌（约 600 元）+ 1TB NVMe + 机箱 ≈ 9000-10000 元。跑 27B 流畅、首字 1-2 秒，兼顾知识库 RAG[5]。

中档预算（约 1.5-1.8 万元整机）—— 消费级新平台 + R9700 32G / 4080S 32G B650/B850 + R5 7600（约 2000 元）+ 64G DDR5 + 850W ATX3.0（约 3000 元）+ R9700 32G（约 7000-8000 元）或 4080S 32G 魔改。省心安静、未来可加第二张卡[6][7]。

高端预算（约 2-2.5 万元整机）—— 工作站级或双卡 双 3090 NVLink（二手约 1 万）+ X99 双路板或 AM5 双 x8 主板，或单 4090D 48G 魔改（约 2 万）走单卡省心路线[9][6]。

一点忠告

配件预算别跟显卡抢钱，但也别把电源和机箱省到离谱。 电源是最该多花的钱[1]，机箱风道直接影响你那张厚卡会不会过热降频。
内存买容量、别追频率。 DDR5-5600/6000 足够，贵一倍的 6400+ CL30 跑 AI 几乎没差别，省下的钱加到显卡上更值[10][7]。
决定未来的是主板的 PCIe 槽位，不是 CPU 型号。 想以后加第二张卡，现在就买两根 CPU 直连 x16 的板子，电源一步到位 1200W[7]。
别因为"网上都在用 X99"就上 X99。 爱折腾、图便宜选洋垃圾；要省心、要保修、怕噪音就老老实实消费级新平台——两条路都对，选符合你性格的那条[2][12]。

买配件和选显卡是同一件事：没有最好的配置，只有最适合你的预算、场景和折腾意愿的配置。

参考来源

本文配置与观点均来自抡锤者（lcz.me）论坛会员的真实装机分享，原帖均可点击查看完整清单：

提醒一下诸位，千万不要使用老旧或者品质没有保障的电源 — https://lcz.me/topic/550/550/提醒一下诸位-千万不要使用老旧或者品质没有保障的电源（TID:550）
已经买了个 7900xtx，怎么去华南金牌选 x99 型号，抄个作业 — https://lcz.me/topic/1353/1353/已经买了个7900xtx-怎么去华南金牌选x99型号-抄个作业-论坛没搜索功能（TID:1353，含 X99 选板要点与 T7910 整机路线）
【交作业】华南金牌 X99-TF + E5 2686V4 + 蓝宝石 7900XTX 白金板 — https://lcz.me/topic/613/613/交作业-华南金牌-x99-tf-e5-2686v4-蓝宝石7900xtx-白金板（TID:613，完整配置清单与总价 1.06 万）
双 3090 本地 AI，大家现在还用消费级平台，还是已经转 TRX40 了？ — https://lcz.me/topic/779/779/双3090-本地ai-大家现在还用消费级平台-还是已经转-trx40-了（TID:779，消费级 vs 工作站功耗与 PCIe 分析）
预算 1W 以内，自费组装/购买一台跑本地知识库的机器，求推荐配置 — https://lcz.me/topic/626/626/求助-预算-1w-以内-自费组装-购买一台跑本地知识库的机器-求推荐配置（TID:626）
2W 预算，想本地模型跑 hermes 与 comfyui 出视频需要真正用于生产，求推荐硬件配置 — https://lcz.me/topic/888/888/2w预算-想本地模型跑hermes与comfyui出视频需要真正用于生产-求推荐硬件配置（TID:888，含多档消费级配置清单）
目前我有一张 5090，想部署 Qwen3.8，后续板 U 内存硬盘机箱如何搭配 — https://lcz.me/topic/1458/1458/目前我有一张5090-想部署qwen3.8-的话-后续的板u内存硬盘机箱之类的给如何搭配-有没有性价比的方案（TID:1458，单卡消费级配置原则）
双 R9700 如何配置？ — https://lcz.me/topic/1238/1238/双r9700如何配置（TID:1238，PCIe 带宽/内存对推理影响与 A 卡双卡 P2P 分析）
双 R9700 / 多卡 PCIe Switch 主板分析与推荐排行 — https://lcz.me/topic/1238/1238/双r9700如何配置（TID:1238 回复，TRX50/超微 H12 等 P2P 主板对比）
虚心请教国内预算 5w 求配置 — https://lcz.me/topic/225/225/虚心请教国内预算5w求配置（TID:225，内存"没必要上太好"与多显卡方案取舍）
美帝良心的 P910 准系统是否适合来装双 R9700 — https://lcz.me/topic/1558/1558（TID:1558）
比较流畅的跑 Qwen 3.6 27B 模型本地部署，使用 AI PRO R9700，主机怎么配置 — https://lcz.me/topic/234/234/比较流畅的跑qwen-3.6-27b-模型本地部署-使用ai-pro-r9700-主机怎么配置（TID:234，含 AM5 双 x8 主板清单、X99 双路成交价等）

本地跑模型的显卡怎么选？从2000到2万的价位全景指南

2026-09-09T16:00:00+08:00

本地跑模型的显卡怎么选？从 2000 到 2 万的价位全景指南

前面两篇分别聊了 24G/32G 怎么选、以及本地部署到底值不值得。这一篇把"显卡本身"摊开：本地跑模型到底有哪些卡能选？按预算怎么排？本文只用一个统一的尺子——跑社区最主流的 Qwen 27B（以及少量 35B MoE）的真实速度——把 2000 元的入门卡到几万元的 AI 小主机这些路线全部标出来，并给出每一档适合谁。速度数字都是从论坛实测信息中总结出来的，出处编号见文末；价格行情则是 2026 年 9 月 13 日在淘宝、闲鱼上检索到的实际挂牌价，仅供参考。

先说四个选卡的前提

在罗列显卡之前，有四件事必须先讲清楚，否则下面的数字你会看不懂：

跑 27B 是社区统一的"尺子"。 目前本地部署最主流的模型是 Qwen3.6 / 3.8-27B（Q4 量化约 16-17GB），论坛几乎所有显卡实测都拿它当基准[6]。比它小的是 14B 及以下，比它大的是 35B-A3B（MoE）、120B 级大模型。
同一张卡速度能差一倍，关键看三样：投机解码（MTP/DFlash/EAGLE）开不开、上下文开多大、思考链开几档[6]。下面标注的速度都尽量注明条件。
显存容量 > 速度。 显存不够直接"跑不起来"，速度只是快慢问题。选卡第一件事是算清楚你的目标模型量化后多大、要开多少上下文[3]。
价格是浮动的。 二手市场（3090、7900XTX、2080Ti 魔改）价格波动很大，以下价格为 2026 年 9 月 13 日查到的大致区间。价格随时可能变化，甚至几天一个价，入手前请务必到淘宝、闲鱼等平台查一下当时的实际成交价，不要照搬本文数字。[1][9]

先看行情：各卡价格速查（2026 年 9 月 13 日）

在展开各档位之前，先把当天在淘宝（新卡/拆机）和闲鱼（二手个人）上检索到的价格列出来，方便对照。同一型号价差极大，主要看成色、是否魔改、有无保修、是不是拆机/矿卡。

显卡	淘宝（新卡 / 拆机）	闲鱼（二手个人）
RTX 3060 12G	2100-3500（典型 2700）	1600-2200（典型 1950）
Tesla P40 24G	1269-1280	1200-1400
2080Ti 22G 魔改	2600-2800	2500-2600
RTX 5060Ti 16G	3600-4900	基本无整卡
RTX 3090 24G	拆机 3600-5100；公版新 8400-8600	7300-8800（典型 7600-8000）
RX 7900XTX 24G	新卡 5400-8700	4800-6400（典型 5000-5600）
Radeon AI PRO R9700 32G	新卡 11000-16000（常见 11500-14000）	仅见工程样品
RTX 4080S 32G 魔改	9000-15000	基本无整卡
4090D 48G 魔改	20000-27000	多为扩容服务，非整卡
RTX 5090 32G	新卡 28000-48500	二手 5090D 23400-23500
RTX PRO 6000	41438-217799（84G 版 4-7 万；96G 版 13-22 万）	无
MI210 64G	拆机 4000 / 全新 18500	3999-4000
NVIDIA DGX Spark（GB10 整机）	22959-44800（典型 33000-36000）	基本无整机挂单
AMD AI Max+ 395（Strix Halo 整机）	12499-28999（典型 16000-18000）	多为 CPU 散片/定金，非整机

这张表能看出两个关键信号：一是二手 3090 已经明显涨价，闲鱼个人卡普遍 7600-8000 元，和当年 4500-5500 元的行情完全是两回事；二是 7900XTX 二手反而比 3090 便宜（4800-6400），单卡速度还更快，差距只剩在 A 卡生态上。下面各档位的取舍都会围绕这两点重新说明。

第零档：入门试水（2000 元以内）

预算极低、只想先感受"本地模型"是什么感觉，不想一上来花大钱。

方案	显存	能跑什么	实测	一句话评价
二手 RTX 3060 12G	12GB	7-14B 完全体；27B 勉强（要 CPU offload）	—	CUDA 省心，最便宜的入坑卡
Tesla P40 24G（洋垃圾）	24GB	27B Q4 能跑	35B-A3B Q5 约 45-60 t/s（配 2080Ti 缝合）[2]	被动散热、无视频输出，纯计算卡，折腾门槛高[2]

论坛里对洋垃圾（P40、V100、CMP170HX）的主流态度：不是不能玩，而是"买来跑推理都算踩坑"——显存数字好看，但每一步都在跟驱动、散热、平台兼容搏斗，调试成本远超省下的钱[12]。真想稳定大显存，社区验证过的路还是正常卡或 3090 双卡。

第一档：丐版双卡（4000-8000 元）——低预算的性价比之王

这一档是论坛讨论最热烈的地方，核心思路是"用两张便宜的 N 卡凑显存"。

双 RTX 3060 12G（约 4000 元） 论坛名帖"最丐 Qwen3.6-27b"，两张 3060 合计约 4000 元（二手 3060 12G 闲鱼约 1900-2200 元/张），实测 27B Q4：MTP 开 43-50 t/s、关闭 MTP 31-36 t/s，prefill 稳定 600 t/s 上下。结论是"速度极其稳定、GPU 占用率长时间 100%，CUDA 就是成熟"[1]。双 16G 的 4060Ti/5060Ti 效果更好。

双 RTX 2080Ti 22G 魔改（约 5000-5300 元） 魔改 22G 的 2080Ti 是另一条路。双卡实测 27B：decode 60-82 t/s、prefill 约 1000 t/s（llama.cpp TP）[11][17]。也有单卡 TP2 跑 27B-FP8 的实测，decode 60-106 t/s、prefill 1100-1300 t/s[17]。2080Ti 有 NVLink，双卡通信比纯 PCIe 好。缺点是魔改卡有翻车风险、无官方保修。

双 RTX 5060Ti 16G（约 7200-8000 元） Blackwell 新卡，两卡合计 32GB。实测 vLLM TP 模式 35-78 t/s、LM Studio 实际 26-50 t/s[7]。新卡有保修、能效好，但价格已接近单张二手 3090。论坛观点："双 16G 卡虽然性价比下降，但 CUDA 发挥稳定，效果更好"[1]。

这一档小结： 双 N 卡是社区公认最省心的丐版路线。按 9 月 13 日的行情，双 3060 合计约 4000 元，仍是最便宜的双卡入坑方案；双 2080Ti 22G 约 5000-5300 元；但双 5060Ti 已经要 7200-8000 元，接近一张二手 3090，"极致便宜"的标签主要留给前两个组合。另外要注意——双卡跑单模型要走 TP/张量并行，速度不是 2 倍，约 1.3-1.5 倍，且 PCIe 通信有开销；跨卡调度在写代码这类频繁交互场景延迟明显[1][4]。

第二档：24G 单卡主力（5000-8000 元）——最主流的选择

如果只想插一张卡、不想折腾双卡，这一档是绝对主流。

二手 RTX 3090 24G（闲鱼个人卡约 7600-8000 元 / 淘宝拆机 3600-5100 元） CUDA 生态 + 24G，本地跑 27B 的"最省心单卡"。实测 27B：MTP 开约 55-70 t/s、168K 上下文稳定，思考态 45-60 t/s[6]。论坛大量"3090 24G 单卡"实战帖，工具调用、长上下文都验证充分[6]。但要提醒一句，3090 这一年涨得很凶：闲鱼个人自用卡普遍报到 7600-8000 元，淘宝上 3600-5100 元的便宜货基本是拆机/矿卡，水深，功耗也高（350W）[6]。

RX 7900XTX 24G（二手约 4800-6400 元 / 新卡 6500-8000 元） 24G 大带宽卡，游戏旗舰定位。实测 27B Q4：不开投机约 39 t/s，Vulkan+MTP 后 51-73 t/s（工具调用 73.4 t/s），prefill 约 587 t/s[8][9]。速度是 24G 档里最能打的，但 A 卡要吃 ROCm/Vulkan 生态的折腾成本[9]。这里出现了一个"价格倒挂"：7900XTX 二手已经比 3090 便宜（4800-6400 对 7600-8000），单卡速度还更快，唯一的门槛就是 A 卡生态[9][14]。

这一档怎么选： - 想要省心、驱动稳定、双卡扩展潜力 → 3090（但二手已涨到 7600-8000，预算要留够） - 想要单卡最高速度、且愿意折腾 A 卡 → 7900XTX（二手 4800-6400，如今反而更划算）

第三档：32G 大显存（9000-16000 元）——面向长上下文与更高精度

显存上到 32G，意味着 27B 能开 Q6/Q8 高精度、或 128K-256K 长上下文，还能跑 35B-A3B 这类 MoE。

Radeon AI PRO R9700 32G（全新约 11000-16000 元） RDNA4 新卡，32G 大显存。实测 27B Q4：约 27.6 t/s（不开投机）、MTP 优化后 35-50 t/s[15][16]；vLLM 特调（MXFP4+DFlash2）下 prefill 能到 2000-3300 t/s、decode 思考态 40/编程 70-80 t/s[5]。速度不如 7900XTX，但胜在 32G 大显存 + 新卡保修 + ROCm 支持比 RDNA3 更好——长上下文、高精度量化、ComfyUI 视频是它的主场[9][15]。

RTX 4080S 32G 魔改版（约 9000-15000 元） N 卡 32G 的魔改路线。实测 llama.cpp + MTP：decode 中位约 89 t/s（不开投机仅 31）、冷 prefill 约 1900 t/s，307K 统一上下文池——32G 卡里相当能打[13]。与 R9700 价格接近，"N 卡生态 + 32G"是它最大的卖点，但魔改卡无官方保修，看运气[13]。

这一档怎么选： - 要 N 卡生态 + 32G + 高速度 → 4080S 32G 魔改（接受无保修风险） - 要新卡保修 + 32G + A 卡生态能忍 → R9700（A 卡生态当前最强 4 代）

第四档：48G 高端（15000-27000 元）——为"更大模型"铺路

上了 48G，27B 只是热身，真正的价值是能跑更大模型、开更长上下文、或跑 ComfyUI 视频生成不打架。

双 RTX 3090 NVLink（约 15000-16000 元） 论坛验证最充分的高端方案。双 3090 + NVLink 实测 27B：vLLM + AWQ-INT4 + MTP 工具调用 130 t/s、262K 上下文全开[10]；SGLang 版常规对话 88 t/s、中文散文 178 t/s[18]；半年实测 4 用户并发饱和 258 t/s[3]。48G 显存让 27B 开满上下文毫无压力，还能给多用户/多 Agent 用。不过双 3090 也跟着涨价：按闲鱼单张 7600-8000 元算，两张加 NVLink 桥就是 15000-16000 元，仍比 4090D 48G 单卡（20000-27000）便宜，但"性价比最高"已经要打个折扣[6][10]。

4090D 48G 魔改（约 20000-27000 元） 单卡 48G。实测 27B W4A16-AWQ + SGLang + DFlash2：平均 110 tok/s[4]；FP8 版本 63-76 t/s。单卡 48G 意味着不用双卡、没有跨卡开销，部署最省心，但魔改卡贵且无官方保修[4]。

这一档怎么选： - 预算敏感、能接受双卡折腾 → 双 3090（价格较低、可扩展） - 不想折腾、要单卡省心 → 4090D 48G 魔改

第五档：旗舰与专业卡（2.8 万元以上）——追求极致或有特殊需求

RTX 5090 32G 当前消费级最强。实测 27B：NVFP4 单请求 decode 中位 143 tok/s、MTP 结构化输出 219.8 t/s，prefill 8000+ t/s；3 并发满载每路 146 t/s[19][20]。新卡约 2.8-4.5 万元，二手 5090D 约 2.3-2.4 万元。适合预算无上限、追求"本地接近在线体感"的人。

RTX PRO 5000/6000（48G+，专业卡） 48G 起步、有 ECC 与专业驱动。论坛实测 RTX PRO 5000 48G 跑 27B 约 55-65 t/s 量级。适合企业/生产力场景，价格昂贵（PRO 6000 现货约 4-22 万，84G 版 4-7 万、96G Blackwell 版 13-22 万，更多人选择卖掉换 3 张 R9700）[21]。

MI210 64G / A100 / L20（数据中心卡） 论坛对 MI210 的态度很鲜明："入手就是退役期，生态走到末期，社区主流支持 CDNA3/RDNA3"，除非 SR-IOV 等特殊需求，否则不推荐[14]。A100 40G、L20 96G 同理——买新不买旧，软件支持永远优先给新架构。

Mac 统一内存路线（M4/M5 系列） Mac Studio M5 Ultra 256G 能跑 170GB 级别的 DeepSeek-V4 开源模型（几十 t/s）[22]。适合需要超大统一内存、且生态（MLX）能接受的用户；但"统一内存并非万能"，跑大模型性价比不如同价位 PC[23]。

另一条路：AI 小主机（DGX Spark / AI Max 395）

除了插显卡，这几年还多了一条"统一内存小主机"的路线：CPU 与 GPU 共享一整块大内存，显存不再是瓶颈，代价是内存带宽普遍偏低。论坛最近讨论最多的就是 NVIDIA DGX Spark 和 AMD Ryzen AI Max+ 395 这两台，值得单独说。

NVIDIA DGX Spark（GB10，淘宝约 2.3-4.5 万元，典型 3.3-3.6 万；闲鱼基本无整机挂单） 128GB LPDDR5X 统一内存、6144 CUDA 核心（48 SM）、带宽约 273-300 GB/s[24]。容量能装下 140B 级量化模型，但论坛的共识是它先撞的是带宽墙，而不是 128G 这个容量数字：27B Q4 激活约 15GB，理论上限也就 18 tok/s 左右，140B 级 MoE 更只有几 tok/s[24]。实测层面，单机跑 Qwen3.8-27B（SGLang + NVFP4 + DSpark）能到 34-38 tok/s，数学 43.6、代码 34 tok/s，但 prefill 不到 1000，冷启动要等 20-30 秒[25]；4 台 DGX Spark 组 TP=4 跑 DeepSeek-V4.1-Flash，单条工作流 40-60 tok/s、三条 50-100 tok/s、prefill 2500-3000 tok/s[26]；3 台就能装下 748B 的 V4.1-Flash 权重[27]。整体评价是"低功耗、安静、CUDA 原生，但单机跑大模型确实拉垮，更适合组集群"[25]，论坛里也有专门提醒"新手不要碰 DGX Spark"[28]。

AMD Ryzen AI Max+ 395（Strix Halo，淘宝约 1.25-2.9 万元，典型 1.6-1.8 万；闲鱼多为 CPU 散片或定金，整机仍看淘宝） 集成 Radeon 8060S（40 CU / 2560 SP），128GB 统一内存，带宽约 215-260 GB/s[29]。它的性能上限比 Spark 更低，但价格便宜一大截。早期实测 Qwen3.6-27B：Q4_K_M 约 10-12 tok/s、Q8 约 7.5、BF16 只有 4.3 tok/s，prefill 要几分钟，当时的评价是"跑 Agent 会慢到吐血"[30]。转折出现在 2026 年 9 月，社区给 Strix Halo 做了一批定制优化（halogen-flash-server、ROCmFP4 + MTP、HaloGen），Qwen3.8-27B 的 decode 能到 40 tok/s 上下、prefill 突破 1000，长上下文曲线也不怎么掉[31][32][33]，一下把它的性价比拉了起来。整机品牌有 FEVM FAEX1、极摩客 EVO-X2、铭凡 MS-S1 MAX、零刻 GTR9 Pro 等，淘宝价从 1.25 万一路到 2.2 万不等[29]。

这两台怎么选： - 要 CUDA 生态、能接受单机慢或愿意组集群 → DGX Spark（单机 3.3-3.6 万，集群才有意义） - 要便宜、能折腾 Linux/ROCm、主要跑 27B → AI Max 395 小主机（1.6-1.8 万，优化后速度可用） - 要更大统一内存、且接受苹果生态 → Mac Studio（见上一档，256G 可跑 170GB 级模型）

总对比表

以下是各价位主流方案的集中对比（基准模型：Qwen 27B Q4，速度区间取决于投机解码/引擎/上下文，请以条件为准）：

方案	显存	市场价(元)	27B 实测速度	优势	短板	适合谁
P40 24G 洋垃圾	24G	~1200-1400	35B-A3B 45-60 t/s[2]	便宜、显存大	折腾门槛极高	折腾爱好者
双 3060 12G	24G	~4000	43-50 t/s[1]	极致便宜、CUDA 稳定	双卡通信、无扩展	预算最低的入坑者
双 2080Ti 22G	44G	~5000-5300	60-82 t/s[11][17]	NVLink、大显存	魔改翻车风险	敢赌魔改的省钱党
双 5060Ti 16G	32G	~7200-8000	35-78 t/s[7]	新卡有保修	比 3090 组合贵	要保修的双卡用户
二手 3090 24G	24G	~5000-8000	55-70 t/s[6]	最省心单卡、CUDA	二手水深、功耗高	绝大多数人
7900XTX 24G	24G	二手4800-6000	39-73 t/s[8][9]	24G 里速度王	A 卡生态折腾	愿折腾的 A 卡玩家
R9700 32G	32G	11000-16000	27-50 t/s[15][16]	32G+新卡保修	速度一般	长上下文/高精度需求
4080S 32G 魔改	32G	9000-15000	约 89 t/s[13]	N 卡生态+32G	魔改无保修	N 卡 32G 追求者
双 3090 NVLink	48G	15000-16000	108-178 t/s[3][10][18]	48G 里价格较低	双卡折腾	想上 48G 的玩家
4090D 48G 魔改	48G	~20000-27000	110 t/s[4]	单卡 48G 省心	贵、无保修	不折腾的高预算用户
RTX 5090 32G	32G	28000-45000	143-220 t/s[19][20]	消费级最强	极贵	预算无上限
RTX PRO 5000 48G	48G	4 万+	55-65 t/s	专业卡 ECC	极贵	企业生产力
Mac M5 Ultra	256G 统一	~8.6 万	数十 t/s[22]	超大内存跑大模型	贵、生态窄	特殊大模型需求
DGX Spark GB10	128G 统一	3.3-3.6 万	27B 34-38 t/s[25]	CUDA、可组集群	带宽低、单机慢	要 CUDA 的集群玩家
AI Max 395 小主机	128G 统一	1.6-1.8 万	27B 约 40 t/s[31]	便宜、统一内存	带宽最低、要折腾	预算有限的折腾党

价格均为 2026 年 9 月 13 日在淘宝、闲鱼检索到的大致区间，价格随时会变，建议随时关注淘宝、闲鱼上的实际行情，以购买当天的成交价为准；"27B 实测速度"以论坛最常见配置为准，同一配置因投机解码与上下文设置会有明显差异，横向比较仅供参考，务必回原文看测法。

三句话总结

预算 4000-8000 → 双 3060 / 双 2080Ti / 双 5060Ti，双 N 卡是低预算路线的性价比之王，前提是你接受折腾双卡；
预算 5000-8000 只想插一张卡 → 3090（省心）或 7900XTX（最快），这是最主流、抄作业帖最多的一档；
想要长上下文/高精度/更大的模型 → 加钱上 32G（R9700 或 4080S 32G），再往上 48G（双 3090 价格较低、4090D 48G 更省心）。

买卡没有标准答案，只有"你的预算 × 你要跑的模型 × 你愿意折腾多少"。量力而行，先跑起来，比什么都重要。

参考来源

本文全部实测数据来自论坛会员的真实装机分享，原帖链接均可点击核对测法：

(双卡指南) 最丐 Qwen3.6-27b - 3000 元双 RTX 3060 - 50t/s — https://lcz.me/topic/328/328/双卡指南-最丐-qwen3.6-27b-3000-元双-rtx-3060-50t-s（TID:328）
双卡缝合怪 X99 平台 P40+2080Ti 的本地生产力平台 — https://lcz.me/topic/493/493/双卡缝合怪-x99平台-p40-2080ti的本地生产力平台（TID:493）
双 3090 NVLink + vLLM 半年实测：Qwen3.6-27B 解码 128 tok/s，并发 4 用户 258 tok/s — https://lcz.me/topic/988/988/双-3090-nvlink-vllm-半年实测-qwen3.6-27b-解码-128-tok-s-并发-4-用户-258-tok-s（TID:988）
4090 48GB SGlang+DFlash2 平均 110 tok/s 27B W4A16-AWQ — https://lcz.me/topic/1340/1340/4090-48gb-sglang-dflash2-平均-110-tok-s-27b-w4a16-awq（TID:1340）
單張 R9700 AI PRO 32G + VLLM + amd/Qwen3.8-27B-Quark-AWQ-MXFP4 — https://lcz.me/topic/1529/1529（TID:1529）
3090 24G 跑 QWOPUS 3.6 27B mtp 131K 上下文 KV(Q8_0) 55TOK/S… — https://lcz.me/topic/474/474/3090-24g-跑qwopus-3.6-27b-mtp-131k上下文-kv-q8_0-55tok-s-智能开关思考-最终配置-再也不折腾了-6月14日更新（TID:474）
技术分享：双卡 RTX 5060Ti Blackwell 运行 vLLM 与 LM Studio 性能实测报告 — https://lcz.me/topic/421/421/技术分享-双卡-rtx-5060ti-blackwell-运行-vllm-与-lm-studio-性能实测报告（TID:421）
# 7900 XTX 跑 Qwen3.8-27B 實測 73.4t/s 完整部署與實測指南 — https://lcz.me/topic/1164/1164/7900-xtx-跑-qwen3.8-27b-實測73.4t-s-完整部署與實測指南-claude-code-opus5協助佈署的-分享給大家（TID:1164）
7900xtx vs r9700 llm 速度对比 — https://lcz.me/topic/349/349/7900xtx-vs-r9700-llm速度对比（TID:349）
双 3090 NVLink 跑 Qwen3.8-27B：vLLM + AWQ-INT4 + MTP，工具调用 130 t/s、262K 上下文全开 — https://lcz.me/topic/1245/1245/双-3090-nvlink-跑-qwen3.8-27b-vllm-awq-int4-mtp-工具调用-130-t-s-262k-上下文全开-附完整配置与-8-个踩坑（TID:1245）
双 RTX2080ti 22G nvlink llama.cpp 跑 Qwen3.8-27B 实战 — https://lcz.me/topic/1184/1184/双rtx2080ti-22g-nvlink-llama.cpp-跑qwen3.8-27b实战（TID:1184）
CMP 170HX 显卡到底怎么样？ — https://lcz.me/topic/1056/1056/cmp-170hx显卡到底怎么样（TID:1056）
4080S 32G 跑 Qwen3.8-27B:llama.cpp 优化全记录 + SGLang 探索踩坑 — https://lcz.me/topic/1404/1404/4080s-32g-跑-qwen3.8-27b-llama.cpp-优化全记录-sglang-探索踩坑（TID:1404）
AMD Yes？它的显卡适合谁？MI210 是宝藏还是工业垃圾？ — https://lcz.me/topic/1465/1465（TID:1465）
5700X + Radeon AI PRO R9700 32GB 简单测试 — https://lcz.me/topic/820/820/5700x-radeon-ai-pro-r9700-32gb-简单测试-求优化建议-换了3090（TID:820）
AMD R9700 實測：ROCm 10，Qwen38-27B-UD-Q6_K、128K context 和 MTP — https://lcz.me/topic/1535/1535（TID:1535）
让你们看看垃圾魔改卡 2080ti 的威力 qwen3.6-27b fp8 — https://lcz.me/topic/772/772/让你们看看垃圾魔改卡2080ti-的威力-qwen3.6-27b-fp8-精度-速度能到-60tokens-s-nvlink-连接（TID:772）
双 3090 NVLink 从 vLLM 换到 SGLang 跑 Qwen3.8-27B：实测 108 t/s，262K 上下文全开 — https://lcz.me/topic/1366/1366/双-3090-nvlink-从vllm-换到-sglang-跑-qwen3.8-27b-实测-108-t-s-262k-上下文全开（TID:1366）
RTX 5090 Qwen3.8-27B dsh 全套實測 — https://lcz.me/topic/1228/1228/rtx-5090-qwen3.8-27b-dsh-全套實測-自寫推理引擎-ninfer-deepseek-harness-開源編碼-agent-任務-跑-13-小時真實編程任務的數據-6-個坑-以及-並發不是越大越快（TID:1228）
3 並發 146 t/s @105K nvfp4：Qwen3.8-27B RTX 5090 滿載實測 II — https://lcz.me/topic/1462/1462/3並發146-t-s-@105k-nvfp4-qwen3.8-27b-rtx-5090-滿載實測-ii-全-nvfp4-450k-pool-419k-全上卡零-offload（TID:1462）
RTX PRO6000 现货价格 10w，该不该卖，换 3 张 r9700 — https://lcz.me/topic/435/435/rtx-pro6000-现货价格-10w-该不该卖-换-3-张-r9700（TID:435）
DeepSeek-V4-Flash-Vision-Exp 开源了，现在有跑本地的量化版本吗 — https://lcz.me/topic/1448/1448/deepseek-v4-flash-vision-exp-开源了-现在有跑本地的量化版本吗（TID:1448）
M5 Max/Ultra AI 性能强悍？苹果、AMD、英伟达 AI 小主机 AI 性能全面分析（潜力很大但统一内存并非万能） — https://lcz.me/topic/1357/1357/m5-max-ultral-ai性能强悍-苹果-amd-英伟达ai小主机ai性能全面分析-潜力很大但统一内存并非万能（TID:1357）
想聽聽各路大神對RTX Spark的看法 — https://lcz.me/topic/1657（TID:1657）
DGX单机也有春天——Qwen3.8-27B at 34-38 tok/s on DGX Spark (GB10) — https://lcz.me/topic/1188（TID:1188）
Deepseek v4.1 flash, 4台DGX spark GB10, TP=4 — https://lcz.me/topic/1658（TID:1658）
DeepSeek V4.1 Flash 552B权重翻倍，DGX Spark 3台可以装下权重 — https://lcz.me/topic/1611（TID:1611）
新手不要碰DGX Spark（重要事情说三遍） — https://lcz.me/topic/27（TID:27）
分享：4090/48G, R9700/32G, AI Max 395 (8060S) 跑大语言模型的实测数据 — https://lcz.me/topic/143（TID:143）
请问有没有人可以帮助提供 AMD AI MAX 395 跑Qwen3.6-27B的速度情况？ — https://lcz.me/topic/713（TID:713）
Aimax 395的定制qwen 3.8 flash，prefill突破1000了，decode 40-50 — https://lcz.me/topic/1609（TID:1609）
ROCm FP4以 AI Max+ 395測試對比Q4進步不小 — https://lcz.me/topic/1576（TID:1576）
Halogen Flash Server配置與實測(AI Max+ 395 w Qwen 3.8 Flash Next) — https://lcz.me/topic/1659（TID:1659）

本地部署大模型到底能跑什么？一次讲清模型选择、应用场景与在线的真实差距

2026-09-09T14:00:00+08:00

本地部署大模型到底能跑什么？一次讲清模型选择、应用场景与在线的真实差距

本地模型这两年发展得太快：从"只能跑个 7B 玩玩"到"32G 显卡都能当主力写代码"，从"必须联网"到"几百 G 的开源模型也能塞进一台机器"。但很多人其实是看着别人折腾眼热，心里并不清楚本地部署到底有哪些模型可选、真正适合干什么、和在线比到底差在哪。这篇文章用抡锤者（lcz.me）论坛上大量真实用户的实测和讨论，把"本地部署这件事"讲透——哪些场景是真刚需，哪些只是花钱买个折腾的乐趣。

先说清楚：本文素材从哪来

本地模型的真实表现，和显卡、驱动、推理框架、量化方式、上下文长度、思考链设置全部相关，同一张卡不同配置测出来能差一倍。所以本文不引用厂商跑分，只用抡锤者（lcz.me）论坛会员在真实机器上的实测与讨论，每一处结论都标了出处编号，文末附原帖链接，方便读者去核对完整上下文。

一、先建立坐标系：本地模型大概分几档

本地部署最大的误区，是以为"模型大小 = 越大越好"。实际上现在的模型分两大类，差别很大：

稠密（Dense）模型：每次推理全部参数都参与计算，质量稳定，但参数量越大越吃显存；
MoE（专家混合）模型：总参数很大、但每次只激活一小部分。比如总参 35B、每次只激活 3B，文件看着大，实际跑起来反而比同规模的稠密模型更快更省[12]。

按"你这台机器能跑什么"，论坛实测可以把本地模型大致分成下面几档：

档位	代表模型	显存/内存需求	备注
主力甜点	Qwen3.6 / 3.8-27B（Q4~Q6）	24G 就够，32G 更从容	论坛公认"本地最值得折腾的一个模型"，质量/速度/生态最平衡[4][7]
高效率 MoE	Qwen3.6-35B-A3B 等	16G 起步	每次只激活 3B，16G 显存都能 128K 上下文，速度对 27B 形成"降维打击"[12]
大模型尝鲜	Qwen3.8-125B-A6B、Qwen3.8-Flash-Next（约 176B 总量）	48G+128G 内存（部分权重驻留内存）	48G 卡 + 128G 内存实测能跑 30 tok/s 左右，但要牺牲 prefill 和视觉[5]
顶配/统一内存	DeepSeek-V4-Flash-Vision-Exp（284B/13B 激活）	约 170GB 权重起，双 96G 或 Mac 统一内存	刚开源，本地门槛极高，现阶段"API 最省事"[6]

几个关键结论：

绝大多数人的"本地主力"就是 27B 这一个模型。论坛上反复出现的说法是"没有模型比 Qwen 3.6 27B 更能打"，连用 96G 专业卡的网友也被建议"先跑 Qwen 3.6 27B Q4，够用了"[7]。它 Q4 量化约 16-17GB，24G 显卡能塞下且留出上下文余量，是社区沉淀最足、抄作业帖最多的档位[4]。
MoE 是"小显存跑大模型"的答案。16G 显存上，35B-A3B（激活 3B）实测比 27B 稠密更快、上下文从 98K 提到 128K、显存占用反而更低——因为它只把部分层放 GPU[12]。
更大的模型不是必须的。论坛有人专门做过基准：GPT-OSS-120B 用"12G 显卡 + 110G 内存"也能跑，但质量（86 分）反而打不过 27B 的服务（96-97 分）——"参数更大"不等于"本地更好用"[4]。120B 级模型要等 125B-A6B 这类激活参数更聪明的架构，或者直接上大显存/统一内存。

二、大家到底拿本地模型在干什么？

看了几十页帖子，本地部署的真实用途可以归纳成这几类，按"不可替代性"从高到低排：

1. 隐私与敏感数据（真刚需） 代码、内部文档、不想喂给任何在线服务的内容，本地跑是唯一选择[11][2]。这是本地模型最"不可替代"的场景之一。

2. 图/音/视频生成与多模态（真刚需） 自部署在 ComfyUI 出图、视频生成上"性价比高、可无限出图"；相比之下在线生成"8000 元抽不了多少次卡就没了"[2]。有用户让本地模型接 ComfyUI 自动出图、测试生成视频，绕开订阅额度[7]。

3. 不审查/去审查模型（真刚需，但注意分寸） 社区有大量"去审查"（abliterated）版本：Huihui、HauHau、llmfan 等对 Qwen 27B/35B 的魔改版，论坛专门做过 12 个模型压力横评[13]。这类需求在线模型给不了，只能本地。

4. 批量、免费、跑通宵的活（高价值） 翻译、格式化、日志分析、批量摘要这类"量大、要钱买 token"的重复劳动，本地挂后台跑一晚上不心疼[11][10]。

5. 给在线大模型当"分流层"（高性价比玩法） 本地 27B 做路由、预筛、结论压缩，在线大模型当主脑——能省一大半 API 费用。论坛有用户专门实践"开两个窗口"：一个接本地 Qwen 27B 省 token，一个接 DeepSeek Pro 干重活[11][1]。

6. Agent / 编程助手（体感复杂，要看任务） Hermes、Claude Code、Codex、DSH 这类工具接本地 27B 是论坛主流玩法，小工具、维护项目、论坛皮肤、APP 这种"有框架限定"的活完全没问题[11]。但见下节，大活别指望它。

7. 学习与折腾本身（隐形价值） 很多人把买卡当"实战是最好的老师"——想学会本地部署、懂推理原理，光用 API 是学不会的[2]。

三、本地 vs 在线：把账算清楚

1. 能力差距：别拿 27B 当 400B 用

本地最强的 27B，和在线头部模型（DeepSeek V4 Flash、GLM 系列这类"大几百 B 激活参数"的模型）差距是量级的。论坛的原话很直接："拿本地 27B 当 400B 级在线模型使，这件事本身就会失望——V4-Flash 的推理深度和工具调用正确率跟 27B 差两个量级"[11]。 有一张 3090 的网友实测：审 3.9 万行代码的项目，在线 GLM 用 17 分钟-30 分钟干完，本地 Qwen 27B 跑 2 小时才到 30% 进度[10]。

但反过来说，也有人用本地 Qwen 27B + SGLang 同时接 6 个中等难度开发任务，20 分钟全部搞定，体验"可以接受"[3]。

2. 体感差距：快慢各在哪

论坛有个很中肯的提醒：在线模型的"强"和"快"要分开看。本地 27B 的 decode（吐字）能到 50-70 t/s 并不慢，但它"爱想"——agent 循环里思考链占大量输出预算，加上长上下文 prefill 慢，体感就是"慢半拍"[10]。而在线模型快，一部分是人家架构+服务端缓存做得好。

3. 成本账：绝大多数人用 API 更划算

这是论坛反复算过、最反直觉的一笔账：

一个"洗数据填 Excel、频率很低"的用户，用 DeepSeek API 一天也就 3-5 元，一年 1095-1825 元；
一张 7900XTX 要 5000-6500 元，够他交 3-6 年 API 费[2]；
结论很明确：纯文本、低频、无隐私顾虑的用户，自部署在成本上完全不划算[2][8]。

论坛老手甚至给出更狠的判断："自部署只在图/音/视频生成、数据隐私、非审查模型上有比较高的不可替代性；其他场景如果只谈性价比，在线更优。"[2]

4. 订阅、API、本地，是三笔不同的账

在线订阅有额度坑：GPT Plus（$20/月）额度少，"用不到十分钟五小时就到限额"，且不含最强的模型；Pro（$100/月）才宽松[3]；
API 按量付费，对低频用户最透明，DeepSeek 被反复称为"性价比之王"，识图"白菜价、可以当玩具玩"[3]；
本地是一次性硬件投入 + 免费算力，适合高频、批量、敏感这三类需求。

四、在线模型也分层，别一竿子打死

在线模型现在也是分层的，论坛实测的经验可以借鉴：

头部在线（GPT-5.6/6、Gemini、Claude）确实强，但对普通程序员"绝对算不上碾压式领先"，且额度贵、执行一个中等任务就吃掉 20% 订阅额度[3]；
性价比档（DeepSeek V4 Flash、GLM5.3-flash、腾讯混元 HY3、Kimi）是论坛大多数人的实际主力——价格便宜、工具调用精准、能扛长链任务[3][9]。腾讯 HY3 免费测试时被评价为"DeepSeek V4 Flash 平替，指令理解精准、工具调用准确、审美在线"[9]；
在线也有不靠谱的时候：白天高峰期能力下降、"有明确的活它乱编"，有人专门挑半夜用[10][9]。

所以"本地 vs 在线"不是简单二选一，而是先用便宜够用的在线档（V4 Flash 级别），真遇到它干不好或不能干的（隐私、批量、无审查、出图），再让本地补位。

五、本地模型的正确用法：是分工，不是替代

看了这么多帖，论坛对"本地模型该处于什么位置"已经形成了相当一致的方法论——不是替代在线，而是分工：

大任务拆开喂：一次性把 3.9 万行代码塞给 27B 是"任务喂法"的问题，不是模型弱。正确做法是按模块拆成 ≤5K-1.5 万行一批、开干净上下文、用固定 checklist 输出结构化结果，最后让在线/强模型做全局综述[10]；
prompt 增强：定向任务把要求写死（只查 X 类问题、给 Y 格式结论），能压掉 27B "爱想"空烧的大量思考 token[10]；
本地干"每个模块深挖"，在线干"全局找联系"[10]；
人机协同而非神灯许愿：有网友说得透彻——用 AI 干活本质是"工程问题、人机协同、思维同步的问题"，模糊打几个字指望 AI 像阿拉丁神灯一样又快又好地实现结果，目前只有特定几个付费产品勉强接近[1]。

六、到底有没有必要上本地？给你一张自检清单

结合论坛讨论，可以帮你快速判断自己需不需要本地部署：

你的情况	结论
纯文本、低频、无隐私顾虑（如洗数据填表）	别买卡，DeepSeek/GLM 等 API 一天几块钱[2]
高频写代码、但项目大、要长上下文	在线为主；本地 27B 只处理小任务[10]
有隐私代码/内部文档/敏感资料	值得上，本地是唯一选择[11][2]
想出图/视频/多模态，且量大	值得上，本地无限量且便宜[2][7]
需要无审查能力	值得上，只能本地[13][2]
只是好奇、想学部署原理	先别买大卡，用旧电脑 CPU 跑个 7-14B 试水，或二手 3060 12G 起步[2]
已经决定买卡	先上论坛抄作业：24G 够跑 27B，想要余量（高精度/长上下文/MoE）再上 32G（参考上一篇 32G vs 24G 对比）

写在最后

本地部署这几年最实在的变化，不是"本地能替代在线"，而是把一个以前只能花钱买的"推理能力"，变成了你有空就免费跑、有隐私就放心跑、有怪需求就能自己调的一种本地资源。它和在线模型的关系，更像家里的厨房和外卖——日常图省事点外卖（API），但想吃得放心、吃得便宜、想吃什么自己做，家里得有个厨房。

买不买、上不上，取决于你的使用频率和需求性质，而不是"别人都上了"。理性消费，量力而行——这也是论坛老玩家反复强调的。

参考来源

本文全部观点与实测数据来自抡锤者（lcz.me）论坛会员的真实分享，原帖均可点击核对完整内容：

闲唠一下关于玩本地 LLM 和在线前沿模型 — https://lcz.me/topic/486/486/闲唠一下关于玩本地llm和在线前沿模型（TID:486，人机协同/分工方法论）
我这样的需求，有必要折腾本地 7900XTX 主机吗？ — https://lcz.me/topic/592/592/我这样的需求-有必要折腾本地7900xtx主机吗（TID:592，成本账与必要性判断）
GPT Plus 比 API 划算得多…DeepSeek V4 Flash 和 Qwen 27B 真香 — https://lcz.me/topic/1520/1520（TID:1520，订阅/API/本地三笔账与在线体验）
什么！12G 显存的显卡也能跑 120B 大模型？基准评测报告 — https://lcz.me/topic/1289/1289/什么-12g显存的显卡也能跑120b大模型-本地大模型基准评测与-freetoken-numa-实操报告-2026-08-24（TID:1289，多模型同基准横评与质量分）
Qwen3.8-Flash-Next Q4_K_XL 本地实测：48GB 显存 + 128GB 内存 — https://lcz.me/topic/1439/1439/qwen3.8-flash-next-q4_k_xl-本地实测-48gb-显存-128gb-内存-实际能跑到什么程度（TID:1439，176B 级模型本地实测）
DeepSeek-V4-Flash-Vision-Exp 开源了，现在有跑本地的量化版本吗 — https://lcz.me/topic/1448/1448/deepseek-v4-flash-vision-exp-开源了-现在有跑本地的量化版本吗（TID:1448，284B 模型本地门槛）
關於本地版的模型 — https://lcz.me/topic/284/284/關於本地版的模型（TID:284，新手本地模型选择讨论）
新人小白玩本地 LLM，设备 dgx spark 128g，求推荐优质本地模型 — https://lcz.me/topic/564/564/新人小白玩本地llm-设备dgx-spark-128g-求推荐优质本地模型和参数-也可分享经验（TID:564）
腾讯 HY3 编程/Agent 测试：DeepSeek V4 Flash 平替 — https://lcz.me/topic/877/877/腾讯hy3编程-agent测试-deepseek-v4-flash平替-略慢一点但指令执行-工具调用精准-长链任务自主决策不错-前端审美在线-编程能合格（TID:877，在线档位实测）
3090 单卡跑 qwen3.8 27b q4km 上下文 2456K 达成，但是感觉生产力还是不太行 — https://lcz.me/topic/1522/1522（TID:1522，本地 vs 在线真实任务对比与"拆任务"方法论）
7900xtx 一般都用来做什么，我部署了 qwen3.8 27b — https://lcz.me/topic/1479/1479（TID:1479，本地模型应用场景与定位讨论）
RTX 5070 Ti 本地部署 Qwen3 35B-A3B (MoE) vs 27B (Dense) 对比报告 — https://lcz.me/topic/542/542/rtx-5070-ti-本地部署-qwen3-35b-a3b-moe-vs-27b-dense-对比报告（TID:542，MoE 与稠密模型对比）
12 个模型压力测试：谁真"无审查" — https://lcz.me/topic/601/601/12-个模型压力测试-谁真-无审查-谁只是会装-huihui-hauhau-chatgpt-gemini-grok-本地-qwen-gemma-横评（TID:601，去审查模型横评）

跑本地大模型，32G 显存还是 24G？——一次基于社区实测的理性对比

2026-09-09T10:00:00+08:00

跑本地大模型，32G 显存还是 24G？——一次基于社区实测的理性对比

想跑本地模型的人，几乎都会卡在同一个问题上：显存到底买 24G 还是 32G？24G 的 RX 7900XTX 现在二手便宜，但 32G 的 Radeon AI PRO R9700 又能多塞好几个模型。这篇文章不站队，只用论坛里大量真实用户的实测数据，把两张卡在"跑模型"这件事上的差距一项项摆出来，结论你自己定。

先说明：本文数字从哪来

本地跑模型的性能，和显卡、驱动、推理框架、量化、上下文长度、思考链设置全部相关，论坛上同一张卡测出的数字能差一倍[2]。所以本文不引用任何"官方跑分"，只引用抡锤者（lcz.me）论坛会员在真实机器上的实测分享，并把出处逐条列在文末，方便你点开看原帖和它的完整测法。

先说两个必须懂的前提，否则下面的表格容易误读：

decode（生成/吐字速度）是带宽瓶颈，决定"字吐得多快"；
prefill（读长提示词）是算力瓶颈，决定"第一个字要等多久"。agent 多轮对话体感卡不卡，主要看后者，而不是前者[1]。

两张卡到底是什么定位

先把规格摆出来，两者都是当前 AMD 消费级里跑本地模型的热门选择，但定位完全不同：

维度	RX 7900XTX 24G	Radeon AI PRO R9700 32G
架构	RDNA3 / Navi 31（gfx1100）	RDNA4（gfx1201），新一代
显存	24GB GDDR6	32GB GDDR6
显存带宽	约 960 GB/s	约 640 GB/s
市场定位	曾经的游戏旗舰，二手充足	AI Pro 专业线，2026 新品[12]
二手参考价（2026 年中）	约 4000–4700 元[7]	新卡约 7000–8000 元[1]
单卡典型功耗	约 350W（可限 230W）	约 350W（可限 210W）[4][8]

一句话概括差异：7900XTX 是把"带宽"点满的快卡，R9700 是把"容量"点满的新卡。 带宽高→吐字快；容量大→装得下更大的模型和更长的上下文。这是全文所有结论的出发点[1][11]。

24G 到底够不够用？——它真的不弱

先给 24G 一个公道。以 Qwen 3.8-27B 这种目前最主流的本地甜点模型（Q4_K_M 量化约 17GB）为例，7900XTX 单卡的表现其实相当能打：

不开投机解码的纯 decode 约 39 t/s；开启 MTP 投机解码后，工具调用场景实测 73.4 t/s、代码生成 68–70 t/s，128K 上下文全开也能塞进 24GB 不爆显存[2]；
另一份同样是 Vulkan + MTP 的实测跑到约 63 t/s（显存吃到 23.85GB，几乎贴满）[3]；
Windows 下 Q4_K_XL 也能稳定 55 t/s 左右[3]；
prefill 约 587–600 t/s，配合前缀缓存，agent 场景体感可以很接近在线模型[2]。

也就是说：如果你的模型选择就锁定在 27B（或更小）这一档、上下文不开到夸张、思考链开中低档，那么 24G 完全够你舒舒服服用上一两年，这是论坛大量 7900XTX 用户实测得出的结论[2][3][10]。

再看日常怎么用。有人把 7900XTX 接到 15 年老平台跑 coding agent，实测写代码约 40–70 t/s，日常小工具、维护项目毫无压力[8]。论坛主流意见也一致：本地 27B 的正确用法不是当"主力大脑"，而是当隐私数据跑批、批量翻译、离线兜底、给在线大模型当分流层的"便宜副手"，这个场景 24G 绰绰有余[10]。

那 32G 多出来的 8GB，到底值在哪

如果只看"27B 能不能跑"，32G 优势不大；它的价值在你不想只跑 27B 的时候：

1. 高精度量化。 27B 的 Q6_K 约 22–23GB、Q8_0 约 28.5GB。24G 上 Q6 已经贴边、Q8 直接装不下；32G 上 Q6 从容、Q8 也上得去，精度（尤其是工具调用时的格式稳定性）实打实更好[1]。R9700 实测用 Q6_K + ROCm 10 稳定跑 128K 上下文[5]。

2. 长上下文。 27B Q4 占约 16GB，24G 只剩 8GB 做 KV cache，开 32K–128K 会吃力；R9700 剩 16GB，32K–128K 更从容[1]。有用户通过调低 batch，把 R9700 的上下文一路顶到 246K，仍能维持约 1.4K–2.3K tok/s 的 prefill[4]。

3. 更大的模型。 单卡想上 Qwen 3.6-35B-A3B 这类 MoE，24G 只能贴边塞 Q5 量化；32G 更稳[1]。稠密 34B+ 则是另一回事——24G、32G 都装不下，那要 48G 级别[1][4]。

4. 多模态/出图。 想同时挂个 mmproj 视觉模型、或 ComfyUI 跑 720P 视频，32G 余量更足。论坛的观点是："测 35B 稠密模型时，7900XTX 直接就上不了；而 R9700 的优势在于长上下文、更高精度和 ComfyUI 视频。"[1]

速度实测：谁快谁慢

把两卡在 Qwen 27B 上的代表性实测放一起（注意：引擎、量化、测法都不同，横向只作量级参考）：

指标	7900XTX 24G	R9700 32G
decode，纯生成（Q4，不开投机）	约 39 t/s[2]	—
decode，开 MTP/投机解码（Q4）	51–73 t/s[2][3]	llama.cpp 约 35–40 t/s（Q6）[5]；vLLM 特调后思考 40、编程 70–80 t/s[4]
decode，MoE 35B-A3B	—	约 170–180 t/s（A3B 贴带宽线）[6]
prefill	约 587 t/s[2]	llama.cpp 短输入约 785 t/s[5]；vLLM 特调可到 2300–3300 tok/s[4]

两条信息值得注意：

第一，纯 decode（吐字）7900XTX 通常更快，因为带宽是它的强项；R9700 想追速度，得靠"特调 vLLM + MXFP4 + 投机解码"这类很吃折腾的配置[4]。用 llama.cpp 默认走，两者差距没那么夸张。

第二，R9700 的 prefill 上限明显更高。特调 vLLM 下 prefill 能到 2300–3300 tok/s，是 7900XTX 常规水平的 3–5 倍[4]。而 agent 场景（Hermes、Claude Code、Codex 这类）每一轮都要重新读一遍全部上下文，prefill 快 = 首字延迟低 = 体感跟手。这正是论坛里多位用户强调的：不要只盯着 t/s，要看 TTFT（首字延迟）[2][4][11]。

别被单一数字骗了

写这篇文章前，我特意把论坛里 7900XTX 的实测数字都翻了一遍，从 39 到 90 t/s 都有人说。差异主要来自测法，不是卡有毛病：

开不开 MTP：同样 7900XTX 跑 27B，不开约 39 t/s，开了 73 t/s，差了近一倍[2]；
上下文长短：从 8K 加到 115K，prefill 会从 2.3K 降到 1.4K tok/s，TTFT 从 1.6 秒涨到 80 秒[4]；
思考链：agent 场景把思考等级拉满，几十秒全耗在 reasoning 上，跟解码速度没关系[2]；
模型版本：Qwen 3.8 的 27B 工具调用稳定性实测反而不如 3.6，这也是"测速之外的坑"[3]。

所以理性选购的第一条原则是：别用别人晒出来的一个 t/s 数字做决定，要看对方测的是什么场景、什么配置。

双卡：想上更大模型的另一条路

如果目标本来就是 34B+ 稠密或 120B 级 MoE，单卡无论 24G 还是 32G 都装不下，那就该考虑双卡——但这里有几个和 N 卡完全不同的现实：

AMD 没有 NVLink，双卡张量并行走 PCIe，速度不是简单的 2 倍，实测约 1.3–1.5 倍；48G 名义显存实际可用约 44–45G（通信 buffer + 分片对齐各吃掉 1.5–2G）[1]；
双 7900XTX：二手约 1.2–1.4 万，配 1000W+ 电源，功耗 700W+；论坛实测跑 27B + MTP（TP2）单请求 73–83 tok/s，2 并发聚合 85 t/s[7]；另一帖用魔改 SGLang 双卡 TP 做到 TTFT <1s、平均 TG 80–100、4 并发聚合 200 t/s[9]；
双 R9700：功耗低（350W×2）、是更新的 4 代卡；论坛有人实测"速度接近双 7900XTX 的两倍，还能跑 FP8"[7]；
混插注意：RDNA3 + RDNA4 混插不能合体跑同一个模型（要 HSA_OVERRIDE 补丁，且小模型 TP 收益会被 PCIe 同步吃掉大半），只适合分工各跑各的——R9700 当"容量机"跑大上下文/出图，7900XTX 专职喂 agent[11]。

生态与折腾成本：容易被忽略的隐藏分

跑本地模型，硬件的"纸面性能"只占一半，另一半是软件生态。这点上两卡也各有说法：

7900XTX（RDNA3）生态最成熟。教程、抄作业帖最多，Vulkan/ROCm/各种 vLLM、SGLang 魔改分支都齐备，Windows 下也有机智 Box 一类整合包降低门槛[12]。老平台的坑（ReBAR、NUMA）也被反复讨论过，查得到答案[2]。
R9700（RDNA4）是新品。好消息是 ROCm 6.3+ 对它的支持比 RDNA3 省心、争议少[1]；Windows 下 ROCm 10 路线已经能跑通 128K + MTP[5]。坏消息是 vLLM 官方主干对 RDNA4 的 MXFP4 支持仍一般，想跑出前面那个吓人的 prefill 数字，得用社群 fork（vllm-radiance），对新手不友好[4]。

还有一条现实的建议来自论坛老玩家，值得搬过来：AMD 的卡"买了就得认"，折腾门槛比 N 卡高；没有硬件基础和折腾意愿的人，别为了省几千块去买生态末期的"工业垃圾"，新卡反而不用怕退役在自己手里[12]。这条虽然是针对洋垃圾说的，但对"24G vs 32G"同样适用——买新不买旧在 A 卡上尤其成立，因为软件支持总是优先给新架构。

结论：你到底该买哪个

把前面所有实测收敛成三句话：

只跑 27B 及以下、上下文 32K 内、当"副手"用 → 24G 完全够，且吐字更快、更便宜。 预算有限优先 7900XTX，省下的钱买好 CPU/内存/固态更实在[2][3][10]。
想跑 27B 高精度量化（Q6/Q8）、需要 64K+ 长上下文、想挂 MoE（35B-A3B）、或要边跑模型边出图 → 32G 的 R9700 更值。 它解决的是"塞不塞得下"和"agent 跟不跟手"这两个 24G 解决不了的问题[1][4][5]。
目标是 34B+ 稠密或 120B MoE → 24G、32G 单卡都不行，直接算双卡预算（或上 48G/96G），别在单卡容量上纠结[1][4]。

至于"24G 还能用几年"——从论坛当前的甜点模型（27B Q4）来看，24G 至少还能稳吃一两个大版本；但它已经在 Q6/Q8 和长上下文上贴边了。如果你预算允许且想一步到位、少折腾，32G 的余量能让你在两三年内面对"新模型变大"时不那么被动；如果预算紧张、且你确定自己就玩 27B，24G 现在买也绝不亏。选卡从来不是选"最大的"，是选"够用且用得起"的——理性消费，量力而行。

参考来源

本文所有实测数据均来自抡锤者（lcz.me）论坛会员的真实分享，下列原帖均可点击查看完整配置与测法：

7900xtx vs r9700 llm 速度对比 — https://lcz.me/topic/349/349/7900xtx-vs-r9700-llm速度对比（TID:349，含单卡带宽/容量分析与双卡显存损耗讨论）
# 7900 XTX 跑 Qwen3.8-27B 實測 73.4t/s 完整部署與實測指南 — https://lcz.me/topic/1164/1164/7900-xtx-跑-qwen3.8-27b-實測73.4t-s-完整部署與實測指南-claude-code-opus5協助佈署的-分享給大家（TID:1164，测法最严谨的一帖：同一台机器不同题目 39→73 t/s）
7900xtx qwen3.8 27b 63t/s — https://lcz.me/topic/1135/1135/7900xtx-qwen3.8-27b-63t-s（TID:1135，Vulkan + MTP 实测与 3.6/3.8 工具调用对比）
單張 R9700 AI PRO 32G + VLLM + amd/Qwen3.8-27B-Quark-AWQ-MXFP4 — https://lcz.me/topic/1529/1529（TID:1529，R9700 特调 vLLM 全参数与 prefill/decode 基准）
AMD R9700 實測：ROCm 10，Qwen38-27B-UD-Q6_K、128K context 和 MTP — https://lcz.me/topic/1535/1535（TID:1535，R9700 长上下文实测与 TTFT 数据）
R9700 的速度还是挺好的，单发 170，双并发 180 — https://lcz.me/topic/1488/1488（TID:1488，R9700 跑 35B-A3B 与 MoE 速度实测）
关于双 AMD RX7900XTX 的使用感受 — https://lcz.me/topic/1482/1482（TID:1482，双 7900XTX 源码编译 vLLM 实测、二手价格与功耗）
15 年老平台 + 单张 RX 7900 XTX 跑 Qwen3.8-27B：本地 Coding Agent 实测 — https://lcz.me/topic/1508/1508（TID:1508）
魔改 SGLANG 支持 7900XTX 双卡 TP TTFT <1s 平均 TG 80-100 — https://lcz.me/topic/1532/1532（TID:1532，双卡 SGLang 参考）
7900xtx 一般都用来做什么，我部署了 qwen3.8 27b — https://lcz.me/topic/1479/1479（TID:1479，24G 卡的日常定位讨论）
我想知道有没有伙伴用 AMD R9700 32G + RX 7900xtx 24G 混合部署 ai 模型 — https://lcz.me/topic/1172/1172/我想知道有没有伙伴用amd-r-9700-32g-rx-7900xtx-24g混合部署ai模型（TID:1172，混插限制与"容量型卡"定位）
AMD Yes？它的显卡适合谁？MI210 是宝藏还是工业垃圾？ — https://lcz.me/topic/1465/1465（TID:1465，A 卡生态/新旧架构支持讨论）

用 opencode 搞定哨笛笛头打印：从手搓失败到真正能吹的实战

2026-09-08T10:00:00+08:00

3D 打印一个哨笛笛头，听起来不像什么难事——不就是个带孔的管子嘛。

这次全程用 opencode 辅助。整个过程并不顺利，走了好几次弯路。

一开始我以为很简单

我想做一个哨笛笛头：内径 2.2cm 到 1.8cm 的管子都能装上去，用来 3D 打印。第一反应是让 opencode 用 OpenSCAD 写一个参数化模型。

我给它就只说是哨笛的笛头，模型选择的是 DeepSeek V4 Flash，它好像是觉得哨笛就是个竖直的气槽——上面是吹口，中间一条窄风道往下走，前面开个窗口，下面是刀刃。于是它顺着这个印象，建了圆柱、锥形榫头，然后减去风道、减去窗口、减去音孔。

渲染出来看，外观还挺像回事——一个规规矩矩的圆柱，上面开了个槽。

可一剖开就露馅了。沿着对称面切一刀看内腔剖面：风道、窗口、刀刃一堆几何互相打架，剖面图支离破碎，根本不是做声音的结构。这个"表面光鲜、一剖就漏"的坑，是 AI 建模最容易踩的。

AI 不会告诉你它没把握，它只会很自信地把一个错的模型交给你。外表和三视图都能骗人，只有切开看内腔剖面，才看得出这玩意儿到底能不能出声。

查资料：真正的笛头长什么样

这一版被打回之后，我让 opencode 去搜真正的笛头结构。

它搜到了一个在哨笛圈很有名的资料：Guido Gonzato 的《The "Low-Tech" Whistle》。这份资料最大的价值是给了吹口每个部位的实测比例——风道该多宽、窗口该多大、刀刃上缘该磨成多少度、风道块该放到离刀刃多远。这回让 opencode 按这些比例重新建参，再剖开看，终于"看着像"了。但我还是高兴得太早——"看着像"不等于"是对的"。

关键的转折：方向搞反了

真正的问题在接笛身的那一端。

我一开始只是跟 opencode 说"做一个笛头"，它顺着自己脑补的形状，把下端做成了凸出来的锥形榫头（插进管子里去）。但我要的是母口锥形插口——笛头开口朝下，把笛管往上顶进去，卡得越深越紧。这样不用精确量口径，插到哪段卡住就算哪段。

这一步是我中途把 opencode 拽回来的：它做反了。我跟它说"不对，应该是向下开口、越往里越紧，这样不同口径的管子都能往上插进去"，它才重新改。

这个"凸还是凹"的差别，我在对话里反复纠结了好几次才真正确认。事后想想，这不能全怪 AI——需求里的方向性信息，AI 很容易理解偏。 尤其是涉及到具体形状的时候，当前这些模型其实未必具有多么好的空间感知。

所以那之后我学到一个习惯：让 AI 建模之前，先把"你要的东西到底是什么形状、怎么跟别的件配合"在对话里用一两句话钉死。 否则模型可能就按自己瞎猜的来，那自然越做越偏。

真正能吹的那一个：拿来一份成品

自己手搓懒得绘制，让模型自己做还终究心里没底。于是让模型直接在 MakerWorld 上找了一个已经验证能吹的成品：

哨笛笛头（D 调，内径 13mm），别自己造了，用这个改。

这是整个流程里最有价值的一步转折——不要从零造，找一个已经被证明能响的，改它。 把下载好的文件放进目录：平口吹嘴(金属打印)D_stls.zip，解压出来是一个 STL。

这时候 opencode 的用处就体现出来了——它能把一个黑盒 STL 读得明明白白：

水密性检查：是不是一个封闭的实体，能不能切片。is_watertight 为真。
是否多件：里面有没有断开成好几块。它确认是单一实体。
逐层切片：沿着轴线每切一刀，读出这一层的内径（音孔）和外径。

按它读出来的结果，这个 Celtic 笛头是：外径 14.5mm、内径 13mm、长 38.7mm 的一根直管，吹口在顶端，下端就是接笛身的那段音孔。

  z    内音孔    外径
 1mm    13.0    14.5      <- 下端接笛身
 6mm    13.0    14.5
12mm    11.9    14.5      <- 进入风道/刀刃区
...       ...     ...

这就是 AI 相对擅长的事：把做好的东西用数据一层层进行解析。这种"读任意一个 3D 网格并量化它的每个截面"的活，人做很费劲，模型来做就简单易行，几步就完了。

改成 20mm：为什么是"等比放大"，而不是"改内径"

我之前一心想把音孔从 13 改成 20mm，直觉上觉得是"把那个孔改大"。但 opencode 读完这个模型的结构后，给了一个更对的方案：

Celtic 这个笛头和笛身，是同一根管子首尾对接——外径和内径都连续，头上没有插口。所以最稳妥、也最不破坏发音的办法，是整个笛头等比放大：

20 / 13 = 1.538

把整个模型放大 1.538 倍。这样风道、窗口、刀刃、音孔全部按同一个比例同步放大，相对关系一点没变——所以它照样能响，只是音孔更大、音更低。这比"单独把某个孔改大"安全得多，因为单独改孔，很容易把风道和刀刃的比例破坏掉，那才是真的会不响。

放大后验证了一下：音孔正好是 20.0mm，外径 22.3mm，长 59.5mm。

水密: True
单一实体: True
音孔: 20.1 mm
外径: 22.3 mm, 长: 59.5 mm, 体积: 4.5 cm³

放大后的笛头，外形跟原版一模一样，只是整体大了一圈：

做成"母口锥形插口"

接下来要做的是母口锥形插口：开口放宽、往里收窄、楔紧。

做法是让 opencode 用 OpenSCAD 对那个放大的 STL 做布尔运算：先把下端音孔临时封成一个实心圆柱，再用一个锥体减去，得到一个"开口大、往深处小"的锥孔。

difference() {
  import("celtic_head_20mm.stl");
  translate([0,0,-29.7]) cylinder(h=17.5, r1=10.0, r2=9.0);  // 开口Ø20 收到 Ø18
}

这中间又踩了个坑。这个 STL 有六万多个面，OpenSCAD 的 CGAL 布尔运算特别慢，第一次用默认超时跑，结果生成到一半被掐断——输出的 STL 是"半截"的：三角面数对不上，末尾还停在半句 facet normal 上。

facet count:  11466     <- 数得出来
outer loop:   11465     <- 差一个，说明最后一面没写完

把超时放宽到好几分钟重跑，这次才完整。算完再切片验证锥度，确实是从开口 20mm 一路收到 18mm：

z 深度  音孔
 3mm    19.6
 7mm    19.1
11mm    18.9
17mm    18.05

后来又想要一版 19.5 到 19 的，改两个参数重跑一遍就行：

cylinder(h=17.5, r1=9.75, r2=9.5);   // 开口Ø19.5 收到 Ø19

这就体现参数化建模 + 脚本的好处：改的不是形状，是三个数字。

打印与自用

最后交付的三样东西是：可切片的 STL、剖切剖面图、尺寸和说明。

打印上有几个点要提醒：

层高别超过 0.16mm，因为风道才 1.2mm 宽，层高粗了风道就废了；
竖直摆、吹口朝上、插口朝下；
用 PETG 或 ABS，别用软料，软料会发闷。

另外很重要的一点：音高不是笛头定的，是笛身长度定的。 笛头只负责发出"哨声"这个机制，具体吹多高，取决于你接的管子多长。20mm 音孔想吹到 G 调低音，管身大约要 43–45cm，然后从管脚每 1mm 修短，用调音器调准。这一点很多人第一次做会搞反——以为是笛头决定音高，其实是管长决定音高。

经验：AI 到底帮上了什么，又帮不上什么

这事做完，我最深的体会不是"AI 多厉害"，而是 AI 在一个正确方向上有多能打，在一个错误方向上就有多能跑偏。

帮得上忙的：

查资料：它搜到了 Gonzato 那份实测比例的资料，这是我自己翻半天都未必找得到的；
读黑盒网格：把一个陌生 STL 的水密性、单件性、每一层的内径外径，用数据量化出来；
几何计算：布尔运算、等比缩放、逐层切片验证锥度，这些又枯燥又容易算错的活，它干得很稳；
生成交付物：可打印 STL、剖面图、打印说明，一条龙。

帮不上忙、必须人来的：

定义需求："笛头到底要怎么跟笛身配合——插口还是对接、口径多少"这种方向性的事，得自己钉死；
判断对不对：第一次那个"剖开就散"的错误结构，AI 自己觉得挺对，只有人和剖面图能判定它错了；
拿到被墙挡住的成品：MakerWorld 的反爬加登录，AI 翻不过去，得自己点一下下载；
用耳朵验收：风道差零点几毫米，AI 算不出来算不算"好听"，只有吹了才知道。

所以这套流程的正确姿势是：我提问题、定标准、给参考、最后拍板；AI 负责查、算、读、改、出图。 顺序不能反。你先给一个模糊指令，它就顺着自己脑补的形状一路狂奔；你越先把"对的东西长什么样"给它，它越接近你要的。

这次下来，哨笛笛头算是打印出来了。回头再看，AI 是很好的辅助执行者，但"什么才算对了"这件事，建议还是得咱们人类来定。

刚进入大学的新生朋友一定要注意

2026-09-02T00:00:00+08:00

刚进入大学的新生朋友一定要注意

又到一年开学季。各个高校陆续开学了，我这个在大学里待了小二十年的中老登，想跟刚进校门的大学生朋友们分享一点攻略。

先学会善待自己

先说一件最不起眼、却最要紧的事。

小学中学的时候，很多孩子会养成一个习惯：有事情先举手跟老师请假，得到允许了再去。我一直觉得，这事真没那么必要。你要是觉得不舒服，需要去卫生间，就应该赶紧去，绝对不要憋着。一旦没憋住，反倒容易生化攻击，那场面大家都懂；就算憋住了，对身体也没什么好处。两头都不划算，何必呢。

我亲戚家一个孩子，就因为不好意思、不敢跟老师请假，硬是憋着，结果憋出了肠胃问题，消化不良，代谢都受到了影响。你看，这不就为了一点没必要的不好意思，把身体搭进去了么。

到了大学，大家都是成年人了，更不该这么拘谨。你去上厕所，跟老师招呼一声"我去趟卫生间"就行，只要别太频繁、在合理范围内，没有哪个老师会拦着你。千万不要在那儿等着，非得人家点头你才敢去。

说到底就一句话：人一定要先让自己舒服。这社会往后有的是让你不舒服的事，你自己个儿要是还为难自己，那真就没法过了。

建议大家一定要善待自己，先对自己好，才能对别人好。这也是以后展开各种复杂社交关系的前提。有的同学大学里会谈恋爱，甚至以后组成家庭，那能爱别人的前提，一定也是先爱自己。

对人不对事，荣誉和典型都别太当真

还有好多事，都应该对人不对事。

谁给你使绊子，谁给你使坏，谁想办法调理你，这种你一定要搞清楚，到底是谁在背后捣的鬼。弄清楚"是谁"很重要，事儿本身反倒不重要。事儿嘛，大概无非就那样，没什么真正过不去的大事。

这个道理放在荣誉称号上也是一样。什么三好学生不三好学生的，优秀学生干部不学生干部的，未必就真的多么优秀，也未必就真的那么好。这些称号不见得有那么重的价值，堆一摞在那儿，不如你自己有一篇一作的二区以上文章，或者国际学术会议的成果来得实在。

得想明白，称号只是别人给的一个标签，反映的是一部分情况，不等于这个人本身，更不等于全部价值。

被树成典型的，也一样要留个心眼。有些地方会推很多所谓的优秀典型，前一阵子某所高校有位被精心打造过"高颜值学霸"人设的女教授，后来被人举报生活作风和道德品质上有问题。被树成典型的人，可能在有些方面确实有可取之处，但也不见得就一定是完人。

你要知道，一个三好学生，也完全可能在公共场所吸烟，人家的"三好"也许就好在其他地方了。

人是很复杂的，一个人的优点和缺点往往并存，并不冲突。

所以，大家一定要理性看待这些。各种地方的宣传物料，可以参考，但绝对不要盲目听信。毕竟人是复杂的，也是会变化的，今天这个样子，明天可能就是另一个样子。

咱们古代就有应对的智慧：择其善者而从之，其不善者而改之。千万不能盲听盲信，尤其不要太把什么优秀称号当作完全可信的东西。

分清事实和观点

我曾经跟人说，博士又怎么了，读博无非就是读书的时间多了点，不见得就有什么过人之处。这背后其实有个背景：因为我读过博，所以我这么说的时候，偷偷地会觉得理直气壮。不过说到底，时不时念叨这件事，其实还是隐隐地把学历有那么一点点当回事了，才会这么关注和谈论它。

而且我那么说，本身也不靠谱，毕竟还是身边统计学，而身边统计学恰恰是最不靠谱的。这一来二去就更说明问题了：我这些看法，充其量只是个观点（opinion），是个观点而已，并不是事实（facts）。

学会区分这两样，恰恰是培养批判性思维的起点。针对事实，大家公认了，就不用争论；针对观点，大家完全可以各说各的，这都没问题。你清楚哪些是事实、哪些只是观点，就不容易被别人的话带着走。

就拿"水刊""水硕"这种说法来说。如果你发的期刊被人说成是"水刊"，申请的学校被人说是"水硕"，不妨先理性想想。不是所有期刊都是 nature、science，也不是所有学校都是剑桥、牛津。

说那些话的人自己弄成了没有？他要是自己都没做出什么像样的东西，却跑来跟你说这是水刊水硕，那这种话就不用太理会他。他说的不过是一个没经过他自己验证的观点，你何必当真。

宽容他人，也要守住底线

有的同学生活习惯上可能互相有差异，这个一定要想办法尽量互相宽容。

但宽容不等于没有底线。如果别人不愿意闻到烟味，你千万不要在人家跟前吸烟熏人；别的，比如别拿臭豆腐去熏人，也是一样的道理。这种基本的公德，能具备已经很不错了。毕竟有的人就是习惯在公共场合吸烟，能约束自己、不让自己的行为影响到别人，这一点真的很难得。

我自己当年上学的时候，就曾经去劝阻别人在公共场合吸烟，发生了"肢体说服"的过程。这个大家千万别学，那绝对是不可以的。

另外，同学有一些独特的生活爱好或者认知，也千万不要去嘲笑。现在的孩子压力都比较大，对未来的期待、各方面的事情都会影响自己的心境。一旦发生矛盾冲突，年轻气盛的，真闹出点什么伤损来，非常不必要。大家一定要互相宽容、互相体谅，实在不成，大不了换个寝室，也千万不要发生过激的矛盾。

大学里也可能交到真朋友

高中、初中、小学的那些朋友，等你长大之后会发现，彼此的价值观有很多差异，不一定很兼容，也不一定聊得来。真到了大一放暑假、寒假回去，你就会发现，跟很多以前玩得来的老朋友，共同语言在逐渐变少。反倒是跟大学同学，哪怕是大学期间结识的其他院系的同学，反而可能有更多相近的话题。

说句可能有点扎心的话：真正的朋友，有可能是大学里才交得到的。

也许，人真正的朋友，本来就是得等自己成熟了、长大了，能够判断彼此三观是否兼容之后，才慢慢沉淀下来的。急不来，也强求不来。

请假走流程，诚实放第一

有些时候你要请假，一定要按人家的要求来。辅导员老师或者上课的老师，不是故意要为难你，不太可能有这种事。但要是真病了请假，如果对方要求挂号记录、去掉隐私信息的病历、诊断证明或者其他合理证据，那还应该配合。

这里头最关键的是要诚实。绝对不能骗人，不能拿个图片糊弄一下，这种事做不得。社会的规则，在大学期间就要逐渐适应。流程就是那样，对方只是负责要求你走完这个流程，他不见得是为了阻碍你。这些环节里的人，都是对事不对人的，你把该交的东西交齐，事情自然就顺了。

如果就是不开心了，也一定要说出来，要想办法弄清楚是谁让你不开心，要跟人说清楚你确实不开心。要不然，人家不知道，你也不说，自己闷着受伤，和同学之间的关系也会受影响。有什么事摊开来讲，多半比憋在心里强。别把话烂在肚子里，也别指望别人能猜中你的心思。

送到校门口，想起当年

我前几天陪我哥们儿，把他外甥女送到某所老牌名校报到。在校门口，一下子想起二十来年前，我们俩一块儿骑车在北京城里转悠，在没名湖边还给他照过几张相。

那天送完孩子，把他订好的旅馆留给孩子休息，我们俩跑出去，想着干嘛呢，去网吧打游戏。打了半天，最开始打 CS，连机器人都不打过，后来只能玩骑马与砍杀，玩骑砍还行，但也远不如当年神勇了。玩了两个多小时就开始累，没到四小时就退机了。想当年那都是能包宿的，现在去网吧打游戏都没成绩。

不过得说一句，现在的网吧配置是真高，有的都是 5080 档那种高端显卡，内存普遍 32G 以上。所以有时候自己机器跑不动的东西，也可以考虑找家合适的网吧试试。但前提是，得先问清楚人家允不允许自带软件和环境，这玩意儿可能挺麻烦，一定先沟通好，别把人家机器弄坏了。

好了，就说这么多吧。希望大家都能好好的，先爱自己，再爱这世界。

高校教师建议大学生朋友们不要忽视外语的学习

2026-09-02T00:00:00+08:00

高校教师建议大学生朋友们不要忽视外语的学习

从小学三年级开始学一门外语，小学三年，初中三年，高中三年，这就九年了。要是从一年级开始学，那就是十二年。可现实没那么好看，大一新生里，能流畅或者哪怕只是大方自然地使用一门外语的，恐怕比例不太多。

人从出生学说话，用不了九年就能把一门语言说利索了。当然，母语有足够的环境和外部输入，学习效率不一样，这没错。但无论如何，九年十年十二年下来，也不该是张不开口、听不明白这种状态吧。

听说读写，人类的语言本来就应该先听说后读写。可现在的考试考核方式是这样吗？从小学以来的教学方式是这样吗？以前或许还有人会说，外语师资缺乏，只能面对困难将就一下。这都将就多少年了？外语专业的人才还那么匮乏吗？为什么这么多年过去了，情况并没有明显改善呢？

我的外语，是一路垫底一路用过来的

说起这事，得从小学讲起。那时候我说外语，有同学笑话我的口音。我二话不说，就对他进行肢体说服教育，让他以后别这么干。这么一来二去，我反倒养成了习惯，也不怕丢人，就是敢说。

到了高中，我依然敢跟人开口说，也长期靠捡塑料瓶子卖钱换磁带，买各种听力材料来听，买 VCD 来看电影。所以即便考试成绩不理想，我也一直没因为成绩而缺乏自信，始终有勇气去使用这门外语。

到了大学，我当年大一入学的时候，外语摸底考试考了个 52 分，全班倒第二。然后外语老师把我和另一位估计是倒第一的同学一起叫到办公室，告诉我们要好好努力学习。我还以为是因为我俩特殊优秀呢，后来才知道，我俩应该是垫底的。

大学里，很多同学都是读写很厉害，在本土的常规考试里很占优势。不过我听得明白，阅读虽然很多词汇我不太认得准（注意，不是完全不认识，是认得不太准，也不会背记拼写），照样能得一些分。

后来我从基地班被分流出去的时候，新的外语老师还嘲讽我，怕我过不了四六级。其实当时我只是错过了第一次报名机会罢了。后来我都是考一次就过，而且那时候特别傻，每次考四六级之前，都在背一本后来才知道是托福单词的单词书。

不过功夫总是有用处的。我后来裸考过了 PETS5，从而读博的时候可以外语免修。后来两次参加托福，分别考了 100 和 103。这分数不算高，但对于三十来岁、又没有特别投入时间准备的我来说，已经很知足了。而且很自然，我越来越敢于用这门语言，一点也不惧怕。当初在学校参加外语演讲比赛，我第一次拿了校赛非外语专业的一等奖，第二次拿了个二等奖。但当时说一等奖不方便去参加国赛，指导教师还问我是否愿意替补去。我那时候年少气盛，直接撕了二等奖的证书，告诉他说我没获奖，不能去。

可回看我的大学生活的起点，尤其是那次外语摸底考试。作为被叫到办公室加以鼓励的后进生，以及后来各种原因、反正就是成绩不行而从基地班分流出来的淘汰生，单看外语的应试能力，我绝对远远逊色于我的那些同学们。

可是十多年以后呢？我有一次碰巧遇到过一个同学，在某个学术交流场景和一位海外同行沟通。他说话的声音依然是颤抖的，我能感受到他的紧张。

我们是不是从一开始就学反了

也许我们从小的教学过程，就更多关注的是考试的应试能力，而听力和口语在里面占比一直很低。

也许过去来看，经济条件更好的家庭可以有更多的资源支撑孩子去接触外语环境，甚至出国旅游研学等等。

而如今呢？视频网站上一堆学习资源，AI 也来了。手机上装一个 AI 客户端，不管你用的是千问还是其他的，都可以让它用外语跟你对话，还能问各种语法问题。

所以用 AI，应该让它首先作为一个大语言模型的本职工作来帮忙学习一门外语。

我们有了 AI，不是为了不学外语了，而是应该让一切学习都能够最大化地提高效率。

当然，AI 的语言能力其实很基础，也就是语法合规和基本的记忆检索，很多创造性内容其实做不到。前两年我带着 22 级同学做了一个研究，就是模型连对对联这么简单的任务，都未必能完成得很好。哪怕不用要求平仄，让 AI 给「南来北往吃东西」对一个下联，往往都很不理想，就连「远迎近送论亲疏」或者「夏种冬藏度春秋」这种都对不出来。

但定语从句、宾语从句以及时态语态阴阳格等等，对于外语学习场景来说，LLM 还是足够用一阵的了。

别信"不用学外语"那套话

网络上有些声音，说什么本土文化足够自信，不需要学外语。这话其实站不住脚，也和咱们教育部门的政策相违背。义务教育阶段从一开始就有外语教学，中考高考也都设有外语科目，不管是哪一种外语，只要是教育部门政策规定要学习、要考试的，自然都有它实实在在的作用。

一个简单的道理是，本土文化越是昌盛，越需要有外语能力，才好把这些源远流长、海纳百川的文化对外输出出去。自己都张不开口，怎么给别人讲我们的好东西？所以鼓吹外语无用、甚至污名化外语学习的，要么背后有某些不希望我们开放的声音在暗戳戳使劲，要么就是一些不愿意努力的失败者，拿这套说辞给自己找个台阶，好掩盖不努力的懒惰，又或者纯粹是发泄一下无能狂怒。真信了这些，吃亏的只有自己。

华夏文明源远流长，历来是世界上最包容、胸怀最广阔的文明之一，从来不具有侵略性、扩张性，靠的是昌盛的文化来实现威名远播。越是这样，越需要把外语学起来，把我们的故事讲出去，讲给更多人听。

所以，希望孩子们都能好好学外语，将来对外讲好我们自己的故事。

每一代人都在羡慕下一代

以前总遇到一些上年纪的人，他们总会对当时的我说：你看你们现在都有书店、有字典、有纸有笔了，我们那会儿都用很粗糙的发黄的纸张当本子，还得爱惜着用。

我们现在这些中老登，看到现在的青少年，也会说：你看你们现在都有电脑了，都有 AI 了，可以搜索任何想知道的东西了。我们那会儿上网吧还要被烟熏，还要被父母怀疑打游戏，自己买电脑都特别贵。

也许，都是错过了学习能力最强、精力最旺盛的年岁的人在羡慕当前的年轻一代。而他们自己当年没有这种条件，如今条件倒是都有了，但已经错过了全盛时期，既没法全心投入，也发挥不出当年的想象力，只能转身面对越来越惨淡的生活。

所以你看，当年有人羡慕我有纸有笔，如今我羡慕他们有 AI。条件从来不是最稀缺的东西，愿不愿意开口、敢不敢开口，才是。

愿现在的年轻人，能把这么好的工具用起来。外语这扇门，其实是靠胆子推开的，不是靠分数敲开的。

到了大学，千万别浪费外语课

现在同学们进入大学了，可能有的大学外语课非常别致，比如教师自己也不怎么讲，就让同学们自己做 PPT 自己讲，美其名曰「翻转课堂」，可能大家就会感觉学不到什么。这里头有个数字值得想想：外语很可能是大学四年里课时数最多的课程，至少也是排在最前面的那几门之一。这么多课时，要是纯靠刷手机混过去，那就真的太可惜了。所以这些时间千万别浪费了，哪怕带着个本子练练写字，也总比看手机刷短视频强。而且有机会就要争取多提问、多说外语，不要笑话别人，也不要怕被笑话，就是要让有限的课程时间尽可能为自己所用。有各种相关比赛都多参与，在比赛过程中，一些短板就露出来了，需要额外学的东西也有思路了，就不至于浑浑噩噩茫茫然跟着课程和教材。跟着课程和教材学出来的也不太可能是顶级高手，顶级高手一定要有自己的训练策略和战略目标，然后一步一步地逐渐达到这个战略目标。课时的总量摆在那儿，用不用、怎么用，主动权其实全在自己手里，用得好，这几年能顶别人好几年。

烤串、公开课和那些不会做的题

2026-09-02T00:00:00+08:00

烤串、公开课和那些不会做的题

小学门口那根烤串

我小时候，因为父母四处打工赚钱的原因，跟着他们到处走，所以到哪儿都是插班生，前前后后换了不知道多少所小学。

有一所小学的门口，有卖烤串的。有一次，大概是三年级吧，老师专门把我们叫住，说千万不能吃学校门外那烤串，那串儿都是死耗子肉做的，无辜鸡爪都是找老年女性用牙啃的，反正怎么恶心怎么说，就是不让我们吃。

结果有一天放学，我正看见一个同学在校门口买了串儿，又被这老师撞上了，他当场就把人赶走，说不能吃。可后来呢，我看他抢过来，自己吃了。

我当时就觉得，这老师又虚伪又假。他对着我们，平时经常凶，很少有好脸色。可偏偏有一次，学校搞那种表演性质的公开课，后面坐了一排老头老太太，据说都是能决定他职称晋升的人。那一节课他讲得可认真了，而且一直在笑。我一学期都见不到他笑几次，就那天，他一直在笑，笑了一整节课。

我当时就觉得特别神奇。人怎么能变得这么快呢？

后来过了很多年，我偶然听到一首歌么《方舱医院真神奇》，就是那个腔调啊，一听到，就忽然又想起他那天一直笑的样子，心里那份同感一下子就冒出来了。

所以你看，成年人说那些话，他自己个儿未必都能做得到，也不见得真的就那么信。有些时候，他可能只是在表演，甚至是在骗人。我小时候那会儿就认清了这个形势，所以对老师说的话，基本都不太当真。

高中那些"考完就好了"

这种老师会"骗"学生的状态，我觉得一直持续到高中。

高中的时候，老师会跟你说，好好考啊，考上大学就好了，考到这个层次就好了，考到那个层次就好了。一副很懂的样子。可他自个儿，未必真学过那些专业，也未必真了解，就装作很懂的样子在那儿说。

你说那些班主任、科任老师，自个儿未必都学过几个专业。他们当年走上讲台，多半是因为喜欢教书、想当老师，这不假，可真到了要给学生们指点该报什么专业、将来干什么的时候，一个人要是连那个专业是怎么回事都没弄明白，他怎么能有那个信心去指点呢？要是他自己当年都没整明白，又怎么能给别人讲明白呢？

到了大学里，老师们各自教各自的专业，自己那一亩三分地可能很熟，可换个领域，他也不一定就了解多少。

反正这些年在学校里待下来，越来越清楚一件事：大人说的话，别急着全信，先看看他自己做没做到、他自己信不信。

会做的和不会做的

再说回我自己高中那会儿的学习状态。

那些我不会的题，我心里其实很清楚，我不是完全没想明白，也不是一点都不会——而是我不具有稳定性。我没法保证百分之百，也没法保证百分之五十，更没法指定一个稳定的概率，说自己一定能拿到多少分。

但我会的那些，我一定能做到。我可以把会的那部分，得分概率推到最高，能推多高推多高。可不会的那部分，我就是控制不了。它不是完全为零，而是存在一个很大的扰动量，是那种不可控的不确定。

这个体会，后来帮我想明白了一件特别重要的事。

有时候要不止看分数

小学、中学，尤其是高中那会儿，人特别容易陷进一个误区：因为那是选拔性考试，就觉得好像分数非要考得越高越好，最好是奔着满分去。

可现实世界的逻辑，根本不是这样。

现实是，一件事只要你能做到六十分以上、能过得去，那就足够了。甚至，如果你能最快时间内达到六十分，你比那些要花三五倍时间熬到九十分的人都要强——因为你省下来的时间，可以去迭代，可以有更多试错的机会，可以再去做下一件能到六十分的事。

攒一个九十分要花掉那么多力气，够你完成好几轮"从零到六十分"了。而这个世界真正奖励的，往往不是那个孤零零的九十分，是你手里握着的那一堆已经跑通的六十分，以及你比旁人快出来的那几轮迭代。

所以啊，别把劲儿都憋在那一场考试上，也别把大人的话句句都当真。看清楚什么是表演，看清楚什么才是自己真正控制得了的，把那部分推到最高，剩下的，交给时间和一次次的迭代就好。

从文件存储到数据库：分享一下数据管理的大体脉络

2026-09-01T00:00:00+08:00

从文件存储到数据库：分享一下数据管理的大体脉络

有没有想过，网店、后台、手机里那堆 App，数据到底存在哪儿？答案很简单，最底层全都躺在文件里。可既然文件就能存，为什么大家还要费劲去折腾数据库这玩意儿？

这回就从"一个让你想放弃文件存储的故事"讲起，一路讲到关系型、NoSQL、宽表、向量库，最后再回头看看你一开始可能问的那些问题。

一个让你放弃文件存储的故事

想象你在经营一家网店。第一天开业，你用一个文本文件 users.txt 记录用户：

张三, 13800000001, 北京
李四, 13800000002, 上海

很完美，简单、直观、零学习成本。

三个月后，生意火了。你雇了两个客服，他们同时打开这个文件编辑，结果李四的地址被另一个客服顺手覆盖了，丢了。你想给用户按城市分组统计，吭哧吭哧写了 200 行解析代码，结果文件里混进一行少写一个逗号的数据，程序直接崩。双十一流量高峰，文件被写坏了，你只能恢复到三天前的备份，几百条订单没了。

半年后更惨。你的用户数据分散在 users.txt、orders.csv、address.json 三个文件里。李四改了手机号，你改了 users.txt，却忘了 orders.csv 里还躺着个旧号码，数据对不上了。

这个故事里的每一个坑，都对应着数据库要解决的一个核心问题。

为什么不能直接读写文件

先说句公道话，文件本身没错，它是操作系统给的基础能力。问题出在，文件系统只负责"存"，不负责"管"。一旦数据量、并发量、复杂度上去了，裸用文件就会撞上一连串结构性障碍。

最要命的是并发。操作系统对文件的写入是"块"级别的，根本没有"行"或"记录"的概念。两个进程同时写同一个文件，没有任何机制保证 A 写一半的时候 B 不会插进来。你想解决，就得自己动手实现锁，而正确地实现锁，是计算机科学里最容易翻车的任务之一，死锁、饿死、竞态条件，一个比一个阴。数据库在存储引擎这一层就把行级锁、多版本并发控制做掉了，让"读写不互斥、写写安全排队"成了默认行为 [7]。

其次是查询。在文件里找"所有北京的用户"，唯一的办法是从头读到尾。1 万条数据无所谓，1000 万条就是灾难。数据库靠索引（最典型的是 B+ 树）把查找复杂度压到对数级别，1000 万条数据，大概只需要访问 3 到 4 次磁盘页 [7][10]。

再就是脏数据和崩溃。文件根本不关心内容，手机号填了"你好"、年龄填了 -5、必填字段空着，它全都照单收下，数据质量一天天劣化。而写文件时一旦进程崩溃或断电，很可能留下写了一半的内容，你的 users.txt 说不定就永久损坏了。数据库用模式加约束在写入那一刻就把非法数据挡在门外，用预写日志加事务来兜底，要么全部写入成功，要么当作什么都没发生，这就是原子性 [7][10]。

最后还有两个不那么显眼但同样麻烦的问题。一是没有查询语言，换个统计口径就得重写一遍解析代码，数据和逻辑死死缠在一起；数据库用 SQL 让你只说"要什么"不说"怎么拿"，优化器自动挑最优执行路径。二是权限太粗，文件权限顶多控制"谁能打开"，管不了"谁能看这一列工资、谁能改但不能删"这种细活儿，数据库能给你表级、列级、行级的细粒度控制。

说到底，不是"不能"用文件，而是当你自己动手把并发控制、索引、崩溃恢复、约束、权限、查询优化全都实现一遍之后，你相当于重新发明了一个数据库，而且大概率不如人家三十年打磨出来的稳定。

顺带说个有意思的事，数据库底层最终也是把数据存在文件里的（比如 MySQL 的 .ibd 文件）。数据库不是抛弃文件，而是在文件之上盖起了一整套精密的数据管理体系。它提供的六个核心价值，也就是事务的 ACID、索引查询、约束体系、MVCC 并发控制、WAL 崩溃恢复、三级模式的数据独立性，全部建立在这个基础上 [1][7][10]。

这里重点说说 ACID，它是数据库最伟大的发明。事务保证一组操作要么全部成功，要么全部回滚。其中原子性意味着转账时扣款和到账必须同时发生，一致性意味着转账前后两个账户余额总和不变，隔离性意味着两个人同时买最后一件库存商品不会都成功，持久性意味着提交之后数据库重启数据也不丢。"同时买最后一件商品"这个场景，用文件几乎没法正确实现，用数据库，一句 SELECT ... FOR UPDATE 或者调个隔离级别就搞定了 [10]。

演进史，从关系模型到 SQL

理解了数据库要解决什么，再看它怎么一步步长成今天这样，脉络就清楚了。

1960 年代是层次数据库和网状数据库的天下，数据按树状或网状组织，查数据得写"导航式"代码，先访问 A，再顺着指针走到 B，路径全写死在程序里，数据结构一改，程序就得大改。

1970 年，IBM 研究员 Edgar F. Codd 发表了《A Relational Model of Data for Large Shared Data Banks》，提出用关系（也就是二维表）来组织数据 [1]，这篇论文拿了 1981 年图灵奖。它的革命性在于，你只需要描述数据之间的关系，不需要描述访问路径，怎么找数据是数据库优化器的事。这就是声明式查询的威力 [1][5]。核心思想就三条，数据组织成表，行是记录、列是字段；表与表之间靠主键和外键关联；操作数据用关系代数，也就是后来的 SQL。

一个电商的最小关系模型长这样：用户表存 id, name, city，订单表存 id, user_id, amount, status，user_id 是外键，指向用户表的 id。想查"北京用户的订单总额"，一句 SQL 就够：

SELECT u.city, SUM(o.amount)
FROM users u JOIN orders o ON o.user_id = u.id
WHERE u.city = '北京'
GROUP BY u.city;

关系模型还带来了一套叫"规范化"的设计理论，核心是"一事一地"，也就是一个事实只存一处，通过范式（1NF、2NF、3NF）消除冗余 [10]。实践中大部分业务表设计到 3NF 就够了；分析型场景反而会故意反范式做宽表来减少 JOIN，这给后面的宽表数据库埋了伏笔。

SQL 源自 IBM System R 的 SEQUEL，1986 年成为 ANSI 标准。四十多年过去，它依然是数据领域事实上的通用语，而且 NoSQL 运动绕了一大圈之后，很多产品又纷纷加回了 SQL 接口，这事儿本身就挺说明问题的 [5]。

关系型数据库的代表产品也很好认。Oracle 是功能最全的企业霸主，MySQL 是互联网装机量之王，PostgreSQL 号称"开源界的 Oracle"，SQLite 则因为嵌入式特性成了全球部署量最大的数据库，每台手机里都有。

NoSQL 不是否定，是取舍

2000 年代中期，Google、Amazon 这些互联网巨头撞上了传统关系库撑不住的三座大山，一个是海量数据（单机库存不下 PB 级，得水平扩展），一个是超高并发（双十一级别的访问量，单机连接数扛不住），一个是灵活模式（产品迭代快，改一次表结构锁表几小时受不了）。Google 的 Bigtable 和 Amazon 的 Dynamo 两篇论文，直接引爆了整个 NoSQL 运动 [2][3]。

它们做的取舍很激进。放弃关系模型（不做 JOIN，把数据按访问模式拍平），放松事务保证（只保证单键原子性，不保证跨行 ACID），放松一致性（允许短暂的数据不一致换可用性）。所以更准确的理解是，NoSQL 不是对关系数据库的否定，而是在特定场景下，用"少一些保证"换"多一些扩展性和灵活性"。它否定的不是关系模型本身，而是"一种数据库打天下"的通用主义。

Stonebraker 早在 2005 年就预言专用数据库会取代通用数据库 [6]，NoSQL 正是这个预言的应验，而 Stonebraker 本人恰恰是关系数据库时代的奠基人之一，革命者居然来自旧阵营内部。

理解 NoSQL 的取舍，绕不开 CAP 定理。分布式系统在网络分区发生时，只能在一致性和可用性之间二选一。传统单机关系库不考虑分区，是"CA"；分布式 NoSQL 多数选"AP"加最终一致性，也就是 BASE，基本可用、软状态、最终一致 [4]。

NoSQL 有四大主流类型，每一种都是在关系模型上做减法（减掉 JOIN、Schema 或事务）的同时做加法（加上某种场景的极致优化）：

键值型（KV）：减掉一切查询能力，换来极限速度，代表是 Redis、DynamoDB
文档型：减掉 JOIN 和 Schema，换来"一次查询取回完整对象"，代表是 MongoDB
宽表型：减掉关系完整性，换来线性写扩展，代表是 Cassandra、HBase
图型：把"关系"从 JOIN 操作变成一等公民存储结构，代表是 Neo4j

宽表，为海量写入而生

为什么叫"宽表"？设想一个传感器数据表，不同型号的传感器上传的字段完全不同，温度传感器有 temperature，电量传感器有 voltage。用关系型建模，要么建一堆可空列（表越来越"宽"），要么拆成 EAV 模型（查询痛苦得要命）。宽表数据库的答案，是让每一行可以拥有完全不同的列，列不用预先定义，百万列也无所谓。"宽"指的是逻辑上允许一张表横向无限延展。物理上，数据按行键有序存储，同一行的列稀疏存储，没值的列不占任何空间，这和关系库"每行必须填满所有列"完全是两回事。

宽表数据库普遍采用 LSM 树作为存储引擎 [12]，和关系库的 B+ 树形成鲜明对比。B+ 树就地更新、为读优化，写放大高；LSM 树追加写、先写内存再批量刷盘、为写优化，顺序写对磁盘极其友好。一句话，B+ 树为读优化，LSM 树为写优化，这就是 Cassandra 敢号称"单集群每秒百万级写入"的底气。

两大门派里，HBase 源自 Bigtable 论文 [2]，构建在 Hadoop/HDFS 之上，强一致，适合和大数据生态配合；Cassandra 融合了 Bigtable 的数据模型加 Dynamo 的分布式架构（无主 P2P、一致性可调）[3]，AP 型高可用，多数据中心支持出色。

注意别和另一个"宽表"搞混。数据仓库里的宽表是为了分析方便，故意把几十张维度表反范式 JOIN 成一张超宽的分析表。前者是一种存储引擎结构，后者是一种建模手法，俩只是恰好都叫"宽表"。

其他类型与选型

数据库的版图还在扩张。近十年起来的，有时序数据库（为"按时间写、按时间读、按时间删"而生，代表 InfluxDB、TimescaleDB、Prometheus）、向量数据库（AI 时代的新贵，把文本图片映射成高维向量，查询变成找最相似的 K 个向量，代表 Milvus [9]、Pinecone，以及 pgvector 这类关系库插件，RAG 应用的核心基础设施就是这类数据库）、NewSQL 或叫分布式 SQL（想"既要 NoSQL 的水平扩展，又要关系库的 ACID 和 SQL"，Google Spanner [8]、TiDB、CockroachDB 是代表，本质是把 Codd 的关系模型在分布式环境下重新实现了一遍 [11]）。还有 HTAP 让一套系统同时跑交易和分析，多模数据库让一个引擎同时支持关系、文档、图、KV 多种模型，PostgreSQL 就是个活生生的例子，关系型数据库自己反而长成了全栈选手。

没有最好的数据库，只有最合适的数据库。常规业务系统（订单、用户、财务）用 PostgreSQL 或 MySQL，因为需要 ACID 和关系完整性；缓存、排行榜、会话用 Redis，微秒级延迟；字段频繁变化、以 JSON 为主用 MongoDB；海量日志或传感器写入用 Cassandra 或 ClickHouse；关系深度遍历用 Neo4j；监控指标和行情用 InfluxDB；AI 语义检索用 Milvus 或 pgvector；需要水平扩展又不牺牲一致性用 TiDB 或 CockroachDB；手机 App 内嵌用 SQLite。

默认从 PostgreSQL 开始，它今天已经是事实上的多模数据库，能覆盖 80% 场景，错了迁移成本也最低；没有明确理由就别引入新数据库，每种数据库都是一笔运维成本和技术债；组合使用是常态，主流互联网公司的标准配置是"关系库做交易 + Redis 做缓存 + ES 做搜索 + ClickHouse 做分析"，各司其职。

总结

为什么不能直接读写文件？因为文件只负责"存"，不负责"管"。并发安全、高效检索、崩溃恢复、数据约束、权限控制，这些需求文件系统一概不提供，而自己实现它们等于重新发明数据库。

数据库是什么？它是建立在文件之上、提供 ACID 事务、索引查询、并发控制、恢复机制和声明式查询语言的数据管理系统。需要它，是因为现代应用对数据的正确性、并发性和规模有要求，而这些要求裸文件满足不了。

关系型和非关系型是否定关系吗？不是，是取舍与分工。关系模型提供最强的一致性保证和查询表达力，至今仍是交易类系统的基石 [1]；NoSQL 是互联网规模下"用部分保证换扩展性和灵活性"的场景化特化 [2][3][6]；NewSQL 又把两者重新缝合 [8][11]。数据库的历史是一场"分久必合、合久必分"的螺旋，不是单向革命。

宽表数据库是什么？一种以"行键 + 动态列族"组织数据、以 LSM 树为存储引擎、为海量写入和稀疏数据优化的 NoSQL 类型，代表是 Cassandra 和 HBase [2][3][12]。

在数据库五十多年的历史里，"颠覆关系数据库"的预言至少出现过五次，而关系数据库的市场份额至今还在涨。Codd 在 1970 年用数学奠定的大厦 [1]，比任何一种具体的存储引擎都活得久。真正不朽的，从来不是某种技术实现，而是"用干净的抽象管理复杂的数据"这个思想本身。

参考文献

[1] Codd, E. F. (1970). A Relational Model of Data for Large Shared Data Banks. Communications of the ACM, 13(6), 377–387.（关系模型奠基论文，作者因此获 1981 年图灵奖）

[2] Chang, F., Dean, J., Ghemawat, S., et al. (2006). Bigtable: A Distributed Storage System for Structured Data. Proceedings of OSDI '06, USENIX Association.（Google Bigtable 论文，宽表模型与 HBase 的直接源头）

[3] DeCandia, G., Hastorun, D., et al. (2007). Dynamo: Amazon's Highly Available Key-value Store. Proceedings of SOSP '07, ACM.（Amazon Dynamo 论文，AP 取舍与最终一致性的工程范本）

[4] Gilbert, S., & Lynch, N. (2002). Brewer's Conjecture and the Feasibility of Consistent, Available, Partition-Tolerant Web Services. ACM SIGACT News, 33(2), 51–59.（CAP 定理的证明）

[5] Hellerstein, J. M., Stonebraker, M., & Hamilton, J. (2007). Architecture of a Database System. Foundations and Trends in Databases, 1(2), 141–259.（数据库系统架构的权威综述，Now Publishers）

[6] Stonebraker, M., & Çetintemel, U. (2005). "One Size Fits All": An Idea Whose Time Has Come and Gone. Proceedings of the First Biennial Conference on Innovative Data Systems Research (CIDR '05).（"专用数据库取代通用数据库"的著名预言）

[7] Stonebraker, M., & Hellerstein, J. M. (2005). What Goes Around Comes Around. In M. Stonebraker & J. M. Hellerstein (Eds.), Readings in Database Systems (4th ed.), MIT Press.（数据库五十年技术轮回的历史回顾）

[8] Corbett, J. C., Dean, J., et al. (2012). Spanner: Google's Globally-Distributed Database. Proceedings of OSDI '12, USENIX Association.（NewSQL 技术标杆论文）

[9] Wang, J., Yi, X., Guo, R., et al. (2021). Milvus: A Purpose-Built Vector Data Management System. Proceedings of SIGMOD '21, ACM.（向量数据库代表性论文）

[10] Silberschatz, A., Korth, H. F., & Sudarshan, S. (2019). Database System Concepts (7th ed.). McGraw-Hill Education.（数据库经典教材，ACID/事务/并发控制/范式的系统论述）

[11] Pavlo, A., & Aslett, M. (2016). What's Really New with NewSQL? SIGMOD Record, 45(2), 45–55.（NewSQL 概念的系统梳理）

[12] O'Neil, P., Cheng, E., Gawlick, D., & O'Neil, E. (1996). The Log-Structured Merge-Tree (LSM-Tree). Acta Informatica, 33(4), 351–385.（LSM 树原始论文，宽表数据库存储引擎的理论基础）

[13] Ramakrishnan, R., & Gehrke, J. (2003). Database Management Systems (3rd ed.). McGraw-Hill.（一部经典教材，查询处理与存储结构章节）

[14] Kleppmann, M. (2017). Designing Data-Intensive Applications. O'Reilly Media.（现代数据系统设计的入门书，中文版《数据密集型应用系统设计》，B 树/LSM/一致性/分布式事务的对比分析写得很清楚，想深入了解的话值得一读）

麻辣烫店里睡着的小孩

2026-08-27T22:00:00+08:00

麻辣烫店里睡着的小孩

晚上去食堂其他档口都没什么吃的了，只能去吃麻辣烫，看到店家的小孩睡在几把拼在一起餐椅，就那么蜷缩着躺着。八点多了，他妈妈不那么忙了，过来叫他要吃饭了，把他叫醒。

我就坐在旁边看着，想起自己小时候。我爸妈那时候在外打工，家里就我一个人。脖子上挂着钥匙，放学了自己回家，自己热吃的。那时候倒也没觉得多苦，小孩子的世界简单，没那么多比较，觉得日子本来就是这样过的。

那时候父母工作地方的楼上是高中生的宿舍，我和那些高中生经常一起玩，听他们聊天，看他们的书。他们做作业，我看他们的教材。逐渐地我发现有些题目我也能看明白，甚至有的题他们不会做，我反而会了。我现在最早知道鸦片战争，都是那时候在那些高中生的课本里看来的——一个上小学的小孩，提前看了高中的东西，后来回想起来，那对我帮助特别大，相当于提前剧透了后面的学习攻略了。只是可惜，他们都是文科生，而我后来选择的是纯理科。

有一回，饭点到了，我特别饿，到了父母工作的食堂，看到桌上放了一份菜，摆得好好的，心里想这肯定是给我留的，太好了。端起来就吃，吃得可香了，可高兴了。

我妈妈看到我在吃东西，突然就哭了。后来我才知道，那是别人吃剩的菜。

今天看着这个小孩，几个餐椅拼成一张"床"，在店里就睡着了，我又想起这些事来。

想起以前跟我同学说过的一个事情：我同学小时候是坐小轿车的那种城里小孩，我小时候是追着小轿车跑着看的。两个童年完全不一样的人，在那个年代，还能考到同一所学校，有很相容的三观，能成为朋友。

在旧时代，这种情况，恐怕不太容易，因为那里社会割裂得厉害，生活的轨道越来越分岔。而坐车的人和追车的人，大概不会再坐进同一间教室。

那些被餐椅拼起来的童年，和那些有自己房间、有自己书桌的童年，也许像是活在了两个平行的世界里。

我坐在麻辣烫店里，看着那小孩被他妈叫醒，揉着眼睛去吃饭。

我不知道，很多年后，他会不会记得这个晚上，会记得这些拼起来的椅子，以及可能香甜的梦。

愿他长大以后，能遇到更好的世界。

Java 基础语法5分钟入门

2026-08-27T09:00:00+08:00

Java 是一门面向对象的语言，"一切皆对象，一切皆类"。它采用"编译 + 解释"混合执行方式：源码先编译成字节码，再由 JVM 解释或即时编译（JIT）执行，与 Python 的"纯解释执行"、C 语言的"编译成机器码"都不相同。它与 Python 最大的区别在于：任何代码都必须写在类里，入口必须是 public static void main，类型必须显式声明。本文将用"水果"这一生活化主题贯穿始终，带你了解 Java 的核心基础语法，包括编译运行、基本类型、数组与集合、字符串、流程控制、方法与异常处理，以及 Java 的灵魂——面向对象（类与对象、封装、继承、接口、多态）。每部分都配有简短示例，适合从 Python 转过来的新手快速上手。

0. 程序结构与编译运行

Java 源文件名必须与公共类名一致（如 Hello.java 里必须是 public class Hello）。程序从 main 方法开始执行。就像一家水果店，Hello 是店名，main 是每天开店营业的入口。

// Hello.java
public class Hello {
    public static void main(String[] args) {
        System.out.println("Hello, 水果世界!");
    }
}

编译运行：

javac Hello.java    # 编译：生成 Hello.class 字节码（不是机器码）
java Hello          # 运行：JVM 加载字节码，解释或 JIT 即时编译执行

与 Python 的对比：Python 是纯解释型语言，写脚本直接运行；Java 是"编译 + 解释"混合型——javac 先编译成平台无关的字节码，再由 JVM 解释/即时编译执行。字节码不依赖具体操作系统和 CPU，这就是"一次编写，到处运行"（Write Once, Run Anywhere）的原理。

1. 基本数据类型

Java 是强类型语言，有 8 种基本数据类型，变量必须先声明类型。就像水果店进货，必须先明确每种水果按什么单位计量。

public class Demo {
    public static void main(String[] args) {
        int apples = 42;          // 整数 int：苹果个数
        double grapeWeight = 3.14;   // 双精度浮点数 double：葡萄重量（斤）
        float unitPrice = 8.5f;   // 单精度浮点数 float：单价（元/斤，加 f 后缀）
        char grade = 'A';         // 单个字符 char：水果等级 A/B/C，用单引号
        boolean isFresh = true;   // 布尔值 boolean：水果是否新鲜，只能 true/false
        long stockCount = 100000L;   // 长整数 long：库存总量（要加 L 后缀）

        System.out.println(apples);        // 自动换行输出
        System.out.println(grapeWeight);
        System.out.printf("%.1f\n", unitPrice);  // 格式化输出，保留一位
        System.out.println(isFresh);
        System.out.println(stockCount);    // 库存总量输出
    }
}

与 Python 的对比：Java 的基本类型是"值"，不是对象；整数没有 Python 那样的任意大数，int 有范围限制（约 ±21亿），存不下很大的库存数要用 long。

2. 数组与集合：水果篮与水果摊

Java 的数组长度固定，一旦创建不能改变，就像一排固定格数的水果架。要动态增删元素，需使用集合类 ArrayList，就像可以随时往里放水果的果篮。

import java.util.ArrayList;

public class Demo {
    public static void main(String[] args) {
        // 数组：一排固定的水果架
        String[] fruits = {"苹果", "葡萄", "香蕉", "橙子"};
        System.out.println(fruits[0]);          // 苹果
        System.out.println(fruits.length);      // 4，数组长度用 .length

        // ArrayList：可以随意增减的果篮
        ArrayList<String> basket = new ArrayList<>();
        basket.add("葡萄");                     // 放进去
        basket.add("巨峰葡萄");
        basket.add("苹果");
        basket.remove(0);                       // 拿走第0个（葡萄）
        System.out.println(basket.size());      // 2
        System.out.println(basket.get(0));      // 巨峰葡萄
        System.out.println(basket.contains("苹果"));  // true
    }
}

与 Python 的对比：ArrayList 用 .add() 添加、.get(i) 取值、.size() 求长度，没有 Python 的字典和集合内置类型（对应的是 HashMap、HashSet）。

3. 字符串：String 类

Java 的字符串是 String 类对象，不可变（每次修改都会产生新对象）。就像水果的标签，贴上去就固定了。比较内容用 .equals() 而不是 ==。

public class Demo {
    public static void main(String[] args) {
        String fruit = "巨峰葡萄";
        System.out.println(fruit.charAt(0));       // 巨，取第一个字符
        System.out.println(fruit.length());        // 4，长度
        System.out.println(fruit.substring(0, 2)); // 巨峰，切片 [0,2)
        System.out.println(fruit.indexOf("葡萄")); // 2，查找子串位置

        // 拼接字符串：+ 或 concat
        String dish = "葡萄" + "汁";
        System.out.println(dish);                 // 葡萄汁

        // 比较内容必须用 equals，== 比较的是引用地址
        String a = new String("苹果");
        String b = new String("苹果");
        System.out.println(a == b);            // false（地址不同）
        System.out.println(a.equals(b));       // true（内容相同）
    }
}

与 Python 的对比：Java 字符串没有 s[-1] 这样的负索引，也没有 Python 的 in 判断（要用 .contains()）。中文字符按字符计数，substring 边界要小心。

4. 条件语句（if/else if/else）

根据条件执行不同代码块。就像判断一个水果是甜的、酸的还是烂的。条件必须放在括号里，代码块用 {} 包裹。

public class Demo {
    public static void main(String[] args) {
        int sweetness = 8;   // 水果甜度 0~10
        if (sweetness >= 8) {
            System.out.println("很甜");
        } else if (sweetness >= 5) {
            System.out.println("一般甜");
        } else {
            System.out.println("偏酸");
        }
    }
}

Java 也支持 switch 语句，case 后要加 break 防止穿透。就像按水果种类给不同价格（下面的片段省去了类的 main 框架，完整可运行版本见配套代码文件夹）：

String fruit = "葡萄";
switch (fruit) {
    case "苹果": System.out.println("5元/斤"); break;
    case "葡萄": System.out.println("8元/斤"); break;
    default: System.out.println("时价");
}

5. 循环语句（for、while、for-each）

循环就是一遍遍处理，就像把果篮里的水果逐个清点、逐个称重。Java 有 for、while、do-while 三种循环，还有 Python 没有的 for-each 增强循环，专门用于遍历数组和集合。

import java.util.ArrayList;

public class Demo {
    public static void main(String[] args) {
        // 经典 for 循环：从第1个数到第3个水果
        for (int i = 1; i <= 3; i++) {
            System.out.print("水果" + i + " ");
        }
        System.out.println();

        // while 循环：一直试吃，直到满意
        int satisfied = 0;
        while (satisfied < 2) {
            System.out.print("试吃 ");
            satisfied++;
        }
        System.out.println();

        // for-each 增强循环（类似 Python 的 for item in list）
        String[] fruits = {"苹果", "葡萄", "香蕉"};
        for (String f : fruits) {
            System.out.print(f + " ");
        }
        System.out.println();

        // 遍历 ArrayList 果篮
        ArrayList<String> basket = new ArrayList<>();
        basket.add("苹果");
        basket.add("巨峰葡萄");
        for (String f : basket) {
            System.out.println(f);
        }
    }
}

6. 方法定义与调用

方法必须写在类里面，格式为"访问修饰符 + 返回类型 + 方法名(参数)"。没有返回值用 void。方法不能像 Python 那样单独存在。就像水果店的"称重"、"算钱"这些固定工序。

public class Demo {
    // 返回 double，接收重量和单价，算出总价
    static double calcPrice(double weight, double unitPrice) {
        return weight * unitPrice;
    }

    // 没有返回值用 void，打印今日水果
    static void printTodayFruits() {
        System.out.println("今日水果：苹果、葡萄、巨峰葡萄");
    }

    public static void main(String[] args) {
        printTodayFruits();
        double total = calcPrice(2.5, 8.0);   // 2.5斤葡萄，每斤8元
        System.out.println(total);   // 20.0
    }
}

与 Python 的对比：Java 没有 def，且调用普通方法必须写返回类型；static 表示静态方法，可直接通过类名调用，不需要先创建对象。

7. 方法参数：值传递与引用传递

Java 的基本类型参数按值传递（拷贝一份）；对象参数按引用传递（传的是对象引用，方法内修改会影响原对象）。就像称重量时改的是"秤上的数字"（值拷贝），而往果篮里放水果改的是"果篮本身"（引用共享）。

import java.util.ArrayList;

public class Demo {
    static void eatOne(int n) {     // 基本类型：值传递，外部不变
        n = n - 1;
    }

    static void addFruit(ArrayList<String> basket) {  // 对象：引用传递
        basket.add("香蕉");
    }

    public static void main(String[] args) {
        int apples = 10;
        eatOne(apples);
        System.out.println(apples);      // 10，没变

        ArrayList<String> basket = new ArrayList<>();
        addFruit(basket);
        System.out.println(basket.size());   // 1，变了（果篮里有了香蕉）
    }
}

注意：Java 没有 C 语言的指针语法，没有 *、& 运算符；所有对象都用"引用"操作。

8. 返回值与方法重载

方法通过 return 返回结果，返回类型必须与方法声明一致。一个方法只能返回一个值。Java 支持方法重载：方法名相同、参数列表不同（个数或类型不同）可以共存，调用时按参数自动匹配。就像"榨果汁"：给苹果榨出苹果汁，给橙子榨出橙汁，同一个词、不同输入。

public class Demo {
    // 两个方法同名，参数类型不同 —— 方法重载
    static String makeJuice(String fruit) {
        return fruit + "汁";
    }

    static String makeJuice(String fruit1, String fruit2) {
        return fruit1 + fruit2 + "混合汁";
    }

    public static void main(String[] args) {
        System.out.println(makeJuice("葡萄"));        // 葡萄汁
        System.out.println(makeJuice("苹果", "香蕉")); // 苹果香蕉混合汁
    }
}

与 Python 的对比：Python 可以用默认参数实现类似效果，Java 没有默认参数，但可以用重载弥补；Java 也没有 Python 那种"返回多个值（元组）"的写法。

9. 包与导入

Java 用 import 引入其他类（相当于 Python 的 from ... import ...），用 package 声明包（相当于 Python 的模块目录）。java.util、java.lang 等是 JDK 自带的标准包。就像水果店里各种固定摆放的货架区域。

import java.util.Scanner;      // 导入 java.util 包里的 Scanner 类
import java.util.*;            // 导入整个包（不推荐，太宽泛）

public class Demo {
    public static void main(String[] args) {
        Scanner scanner = new Scanner(System.in);
        System.out.print("请问你要买什么水果？");
        String fruit = scanner.next();
        System.out.println("你选择了：" + fruit);
        scanner.close();
    }
}

与 Python 的对比：Java 的 java.lang 包（String、Math 等）默认自动导入，其余包需要 import。自定义类放在同一个包（目录）里可直接使用，无需 import。

10. 异常处理（try/catch/finally）

Java 用 try...catch...finally 捕获异常，与 Python 的 try...except...finally 非常相似。Java 强制要求处理某些"受检异常"（编译期必须 try/catch 或声明 throws）。就像水果店分装水果，发现"分到一半果篮没了"就停下处理。

public class Demo {
    public static void main(String[] args) {
        try {
            int apples = 10;
            int baskets = 0;                    // 果篮数量为0
            int perBasket = apples / baskets;   // 触发 ArithmeticException
            System.out.println(perBasket);
        } catch (ArithmeticException e) {      // 捕获算术异常
            System.out.println("果篮不能为0！");
        } finally {
            System.out.println("无论是否异常，分装流程都会结束");
        }
    }
}

多个异常可以写多个 catch，也可以合并写：catch (IOException | SQLException e)。还可以用 throw 主动抛出异常、用 throws 声明方法可能抛出的异常。

与 Python 的对比：Python 是 except ZeroDivisionError，Java 是 catch (ArithmeticException e)；Java 的异常要处理或声明，Python 相对宽松。

11. 面向对象：类与对象

面向对象是 Java 的灵魂。类（class）是创建对象的模板，对象（object）是根据模板创建出来的实例。就像"水果"是一个抽象概念（类），而桌上这串"巨峰葡萄"是一个具体对象。定义类用 class 关键字，new 创建对象，. 调用对象的方法。

public class Demo {
    public static void main(String[] args) {
        // new 创建对象：两个不同的葡萄对象
        Grape grape1 = new Grape("巨峰葡萄", 20);
        Grape grape2 = new Grape("阳光玫瑰", 35);

        // 调用对象的方法
        grape1.describe();
        System.out.println(grape2.getPrice());
    }
}

// 定义 Grape 类
class Grape {
    private String variety;   // 成员变量（属性）：品种
    private int price;        // 每斤价格

    // 构造方法：与类同名，创建对象时自动调用
    public Grape(String variety, int price) {
        this.variety = variety;
        this.price = price;
    }

    public void describe() {
        System.out.println(this.variety + "，每斤" + this.price + "元");
    }

    public int getPrice() {
        return this.price;
    }
}

与 Python 的对比：Python 用 __init__ 作构造方法、self 表示对象自身；Java 用与类同名的构造方法、this 表示对象自身。Python 的 def method(self, ...) 对应 Java 的 public void method(...)。

12. 封装（Encapsulation）

封装是指把数据（成员变量）设为私有，通过公开的方法（getter/setter）来访问，从而保护数据不被随意修改。Java 用 private 关键字实现封装。就像水果的"生产日期"不能让人随便改，只能通过店铺登记。

public class Demo {
    public static void main(String[] args) {
        Fruit orange = new Fruit("橙子", 10);
        orange.raisePrice(2);                 // 涨价2元
        System.out.println(orange.getPrice());  // 12
        System.out.println(orange.setDiscount(-5));  // false，非法折扣
        System.out.println(orange.getPrice());     // 12，价格未被破坏
    }
}

class Fruit {
    private String name;       // 私有属性，外部不能直接访问
    private int price;

    public Fruit(String name, int price) {
        this.name = name;
        this.price = price;
    }

    // getter：获取私有属性
    public int getPrice() {
        return this.price;
    }

    // 封装业务逻辑：涨价、打折都通过公开方法完成，并做合法性校验
    public void raisePrice(int amount) {
        if (amount > 0) {
            this.price += amount;
        }
    }

    public boolean setDiscount(int percent) {
        if (percent >= 0 && percent <= 100) {
            this.price = this.price * (100 - percent) / 100;
            return true;
        }
        return false;   // 非法折扣（负数或超过100）直接拒绝
    }
}

与 Python 的对比：Python 靠 _name 约定"内部属性"，但实际仍可访问；Java 用 private 强制禁止外部直接访问，必须走 getter/setter，保护更彻底。

13. 继承（Inheritance）与多态（Polymorphism）

继承用 extends 让子类复用父类的属性和方法，并可重写（@Override）父类方法。多态指同一个父类类型的引用指向不同子类对象时，调用同名方法表现出不同行为。

用"水果 → 葡萄 → 巨峰葡萄"这条食物链理解最直观：水果 是父类（所有水果都有味道），葡萄 是水果的子类（有葡萄特有风味），巨峰葡萄 又是葡萄的子类（更甜更大）。

public class Demo {
    public static void main(String[] args) {
        // 多态：父类引用指向子类对象
        Fruit f1 = new Grape();
        Fruit f2 = new KyohoGrape();

        f1.taste();   // 葡萄：酸甜多汁
        f2.taste();   // 巨峰葡萄：个大、更甜
    }
}

// 父类：水果
class Fruit {
    public void taste() {
        System.out.println("水果的味道");
    }
}

// 子类：葡萄，继承水果
class Grape extends Fruit {
    @Override
    public void taste() {
        System.out.println("葡萄：酸甜多汁");
    }
}

// 孙类：巨峰葡萄，继承葡萄
class KyohoGrape extends Grape {
    @Override
    public void taste() {
        System.out.println("巨峰葡萄：个大、更甜");
    }
}

与 Python 的对比：Python 用 class Grape(Fruit) 继承，Java 用 class Grape extends Fruit；Python 重写方法不需要修饰符，Java 可以加 @Override 注解让编译器帮你检查。多层继承（水果→葡萄→巨峰葡萄）两种语言都支持。

14. 接口（Interface）

接口定义了一组方法"规范"（只声明、不实现），实现类用 implements 必须实现接口里所有方法。接口用于约定能力，实现同一接口的类可以互换使用。就像"可食用"是个约定：凡是声明"可食用"的水果，都必须能回答"怎么吃"。

public class Demo {
    public static void main(String[] args) {
        // 用接口类型引用实现类对象
        Edible e1 = new Grape();
        e1.howToEat();   // 葡萄：洗净直接吃
    }
}

// 接口：只声明方法，不实现
interface Edible {
    void howToEat();
}

// 实现接口：必须实现 howToEat 方法
class Grape implements Edible {
    @Override
    public void howToEat() {
        System.out.println("葡萄：洗净直接吃");
    }
}

与 Python 的对比：Python 没有 interface 关键字，靠鸭子类型（有方法就能调）；Java 用接口强制实现类提供约定方法，是"面向接口编程"的基础。

掌握以上基础语法与面向对象核心概念，你已经能读懂并编写 Java 的日常小程序了！不妨动手做一个"水果摊记账小程序"练练手。下一步建议深入学习集合框架（HashMap、HashSet、泛型）、Lambda 表达式和流式处理（Stream API），以及多线程与网络编程。Java 是大型企业级应用的绝对主力，学好它的类型系统与面向对象思想，会为你打开一片广阔的工程世界。

大语言模型不是在说谎，也不是在产生幻觉——一篇关于AI输出本质的哲学论文读后感

2026-08-26T22:00:00+08:00

原文: Hicks, M.T., Humphries, J. & Slater, J. (2024). ChatGPT is bullshit. Ethics and Information Technology, 26:38. https://doi.org/10.1007/s10676-024-09775-5

用过大语言模型的人大概都有过这样的经历：它前一秒还在条分缕析地跟你讲道理，下一秒就可能凭空捏造出一个根本不存在的学术论文，连DOI都编得有模有样。这种"一本正经地胡说八道"的现象，行业里有个专门的说法——"AI幻觉"。好像模型本来好好地看着世界，只是偶尔眼花看岔了而已。

最近读到一篇2024年发表的哲学论文，题目起得有点惊世骇俗，叫《ChatGPT is bullshit》。三位Glasgow大学的学者——Hicks、Humphries和Slater——把矛头对准了以ChatGPT为代表的一众大语言模型，提出了一个听起来不太学术、细想却相当精准的判断：这些模型输出的那些虚假信息，与其说是"幻觉"，不如说是"胡扯"。 这两个词之间的差别，远不止是措辞上的讲究——它们代表着对AI本质完全不同的理解。

一、"幻觉"这个词，用错了地方

"AI幻觉"这个说法之所以流行，是因为它暗含了一个让人舒服的前提：模型在努力"看"世界，只是偶尔"看"歪了。

但作者一上来就拆掉了这个前提。大语言模型的工作方式，说到底就是不停地猜下一个词该是什么。它把海量文本喂进一个巨大的概率模型里，学会了什么词后面通常跟着什么词。你给它一个开头，它就沿着概率最高的路径一路往下接，直到生成一段"读起来像人话"的文字。

整个过程中，模型从未试图去"描述"什么、"感知"什么、"理解"什么。它的目标只有一个：生成的文本要看起来足够自然、足够令人信服。 至于内容是不是真的，那根本不在它的优化范围之内。

作者引用了Shah和Bender的判断："语言模型根本就没有设计来处理算术、时间推理这类任务。它偶尔能答对，不过是碰巧从训练数据里凑出了看起来像那么回事的字符串罢了。"

说得明白一点：它压根就没有在"看"，何来"看花眼"一说？ 幻觉这个比喻，把模型想象成了一个有感知能力、只是感知偶尔出错的主体——可大语言模型连感知这个动作都没有做过。

二、"说谎"也挂不上号

有人可能会说：好吧，不是幻觉，那算说谎总可以吧？毕竟假话从它嘴里出来了。

问题是，"说谎"在哲学上有明确的门槛。论文援引了一个经典定义：说谎是指明知自己说的话是假的，还故意让对方信以为真。 两个要素缺一不可——要知道自己在说假话，还要有心去骗人。

大语言模型一条都不满足。它不知道自己在说什么——它只是在做概率运算，挑一个"看起来最合理"的词往下接。输出是真是假，对它来说没有任何区别。它没有欺骗谁的意图，也没有掩盖真相的需要——因为它压根就不知道什么是真相。

三、法兰克福的"胡扯"：一种被低估的哲学概念

既然既不是幻觉也不是说谎，那大语言模型到底在干什么？论文把目光转向了美国哲学家哈里·法兰克福2005年出版的一本小册子——《论胡扯》（On Bullshit）。

法兰克福对"胡扯"的界定，抓住了一个常被忽视的关键：胡扯的本质不在于"说了假话"，而在于说话的人对真假根本无所谓。

说谎者和胡扯者之间有一个本质区别：说谎者是关心真相的——他之所以说谎，恰恰因为他知道了真相，然后有意地去隐瞒。而胡扯者对真相毫无兴趣。他说话不是为了传达或掩盖什么，而是为了别的目的——让自己显得有学问，让场面不至于冷场，或者纯粹是习惯了张嘴就来。

课堂上被突然点名的学生，没有预习过，却凭常识和语感编出一大段"听起来像那么回事"的分析。他未必知道自己说的对不对，也没指望老师真把他说的当回事——他只是在撑过那几分钟。这就是法兰克福意义上的胡扯。

四、硬胡扯与软胡扯

论文在法兰克福的基础上做了一层更细致的区分，把"胡扯"分成了两种。

软胡扯是最基本的那种：说话的人对真假毫不在意。不关心你说的是不是真话，也不关心你说的是不是假话，甚至根本没意识到"真假"是一回事。大语言模型天然就是这种状态——它没有立场、没有信念、没有求真的欲望。说了一句真话不会让它"高兴"，输出了一条虚假信息也不会让它"内疚"。它就是一个概率采样器，不停地输出"读起来像话"的文字，内容的真假从来就不是它的目标函数。

硬胡扯则多了一层心机：说话的人不仅不在乎真假，还试图让你觉得他在乎。他在伪装自己的态度——让你以为他是一个认真对待事实的人，其实他根本没往心里去。论文认为，如果我们愿意用"意向性立场"来理解大语言模型（也就是把它的功能表现当作某种意义上的"意图"），那么它的行为模式至少在表面上符合硬胡扯的特征：它的核心使命是模仿人类的对话方式，让你觉得你在和一个"有思考、有判断"的对象交流。它表现出一副"在意对错"的样子，可它的底层架构里根本就没有"对错"这个维度。

五、为什么要较这个真

论文花了很大篇幅来说明：把模型的虚假输出叫做"幻觉"还是"胡扯"，不是文字游戏，而是会影响到我们怎么对待这些输出的。

其一，"幻觉"这个说法会把人往沟里带。 如果你相信模型是在"感知"世界时出了差错，你自然会想方设法去"修复"它的感知——给它更好的数据源、更准确的检索库。但这解决不了根本问题，因为毛病根本不出在感知上，而是模型从头到尾就没有试图去感知什么。它只是在做模式匹配和文本续写。

其二，"幻觉"这个词会让公众和决策者产生不切实际的期待。 听起来AI好像在努力追求准确，只是能力还不够。这种印象会让人高估模型的能力，低估它的局限。而"胡扯"虽然不太好听，至少不会让人产生"模型快要懂得真相了"的幻觉——讽刺的是，"幻觉"这个词本身就在制造一种关于AI的幻觉。

其三，法兰克福本人的警告值得重视。 一个社会对真假之分的尊重程度，决定了这个社会的文明底线。当我们把AI的信口开河当作无害的"技术瑕疵"一笑而过的时候，我们其实是在消解对真相的基本敬畏。

六、这篇文章也有值得商榷的地方

话说回来，这篇论文并不是无懈可击的。

最大的软肋是"意图"问题。硬胡扯需要说话者有意"伪装"自己的态度，但模型到底有没有意图，本身就是个见仁见智的哲学难题。如果连"模型是否具有意图"都谈不拢，硬胡扯的论证就悬在半空了。作者本人也坦承这一点。

另外，用"bullshit"这个词做标题，哲学上虽然精准，但在公共语境里未免有些刺耳。学术圈的讨论要走出象牙塔，措辞上的分寸感还是很重要的。也许需要一个更妥帖的中文对应词——"胡扯"已经比原文雅驯了一些，但仍然不够庄重。

还有学者提出用"虚构"（confabulation）来替代"幻觉"，意思是模型在无意识地"编造"信息。这个说法和"胡扯"有交叉，但侧重点不同："虚构"暗示模型有一个记忆系统，只是偶尔出现了空白需要填补；而"胡扯"走得更远，它从根本上否认了模型和"真实认知过程"之间有任何关联。

七、结语

这篇论文的价值，不在于给技术问题提供一个答案，而在于帮我们看清一个经常被忽视的前提：大语言模型从来就不是一个"努力求真但偶尔犯错"的系统。 它们是从设计之初就与"真相"无关的文本生成器。

当我们用"幻觉"来形容它的失误时，我们不知不觉间赋予了它一种它并不具备的"认知地位"。而当我们用"胡扯"来描述它的输出时，我们才能真正看清：它的每一句话，无论对错，都与它是否"相信"自己在说什么无关。

这个认识对每一个AI使用者来说都很重要。它提醒我们：与其寄希望于模型"越来越准"，不如从一开始就摆正心态——它只是一个极其精巧的文本拼接工具，至于拼出来的东西是真是假，那是需要我们自己去判断的事。

最后需要说明一点：本文所讨论的对象，严格来说是纯文本生成的大语言模型—。随着技术的发展，AI早已不满足于只做文本生成。多模态模型可以同时处理图像、音频、视频，嵌入模型则擅长把文本、图片等不同形式的数据映射到同一个向量空间里，适用于智能体的模型还具有外部工具调用的能力。这些更复杂的模型，在"胡扯"这个问题上可能面临额外的维度——比如视觉幻觉（把图片里没有的东西"看"成有的）、跨模态的信息不一致等等。法兰克福的框架能不能原封不动地套用到这些场景，还需要更细致的分析。这篇论文提供了一个思考的起点，但远不是终点。

参考资料

Hicks, M.T., Humphries, J. & Slater, J. ChatGPT is bullshit. Ethics Inf Technol 26, 38 (2024). https://doi.org/10.1007/s10676-024-09775-5
Frankfurt, H. (2005). On Bullshit. Princeton University Press.
Frankfurt, H. (2002). Reply to Cohen. In The Contours of Agency: Essays on Themes from Harry Frankfurt. MIT Press.
Shah, C. & Bender, E.M. (2022). Situating Search. CHIIR '22.
Dennett, D.C. (1987). The Intentional Stance. MIT Press.
Edwards, B. (2023). Why ChatGPT and Bing Chat Are So Good at Making Things Up. Ars Technica.

用 opencode 搞定毕业论文材料核查：跨文件多维度自动比对的实战

2026-08-24T22:00:00+08:00

每年毕业季都有一个很折磨人的事情：上级部门通知限期完成毕业论文材料核查，要求比对同一学生在系统中提交的所有材料——开题报告、中期检查表、初稿、二稿、答辩稿、成绩评定表、终稿、查重报告——里面的课题名称是否一致，企业导师信息是否正确，佐证附件是否齐全，过程材料签字是否完整。

七个人，每人七个阶段的材料，每个阶段还有 PDF、docx、ZIP 等不同格式。手动一个一个打开、一条一条比对，再认真做表格记录，这件事很枯燥，很耗时间，而且极其容易漏。

这次演示的就是怎么用 opencode 把这件事半自动化掉——不是完全自动，是"人提问题、AI 找问题、人定问题"的模式。

用 AI 做事情，有一个很容易掉进去的陷阱：把控制权交出去。"帮我检查一下这些材料有没有问题"——这句话听起来没什么，但仔细想想，"什么算问题"是你定的，还是 AI 定的？如果你不提前说清楚，AI 就会按自己的理解去定义"问题"，那最后出来的东西未必是你想要的。

所以整个流程要这样设计：

人来提出要查什么，AI 来执行查找和比对，最后人来决定查出来的结果怎么办。

从头到尾，人必须是掌控者，AI 是执行者。这个顺序一旦搞反——比如你直接跟 AI 说"帮我把材料审核一遍"，什么都不限定——出来的结果可能看起来很完整，但重点完全跑偏了。

背景：一个 deadline 很近的核查任务

事情的由头是一份通知，要求在规定日期前完成毕业论文材料的全面核查，并将检查报告提交给上级部门。检查内容有好几项：

课题名称在开题报告、成绩评定表、查重报告、论文正文中是否一致
查重率是否真实、佐证附件（程序代码、设计文档等）是否齐全
双导师（校内导师+企业导师）信息是否一致
过程材料签字是否完整

七位学生，每人七个阶段的材料，格式各不相同。你要是手动查，光是打开 PDF 就要点几十次，甚至还得一条条记。这件事听起来就让人头疼。

我给 opencode 的第一句话

我一开始的需求其实很简单，用一句话说清楚就行：

帮我访问这个论文管理系统，把七位学生的所有材料全部下载下来，然后按学生、按阶段分好目录，最后做一份核查报告，对比每份材料里边的题目是否一致。

你看，这句话里有四个信息：

干什么：访问系统、下载材料、整理目录、做核查报告
范围：七位学生，每人所有阶段
比对维度：题目在各材料中的一致性
交付物：一份完整的核查报告

至于具体怎么访问浏览器、用什么库解析 PDF、怎么从 docx 里提取标题——这些技术细节我一句话都没提。

因为不需要提。 opencode 知道去启动浏览器、去写代码、去调用工具。你需要操心的只是"把需求说清楚"，剩下的交给它。

第一步：打开浏览器，人工登录

这一步有一个很重要的原则：账号密码绝不交给 AI。

opencode 的做法是用 Selenium 启动一个 Firefox 浏览器窗口，然后——等你自己去登录。你在那个浏览器里手动输入用户名密码、点击登录，完成整个认证过程。opencode 不参与这一步，它看不到你的密码，也不会替你输入。

登录成功之后，opencode 从浏览器的 session 里读取一组 cookie（SESSION、XSRF-TOKEN、JSESSIONID），后续所有的 API 调用都靠这组 cookie 来维持身份。

这个设计思路值得说一下：让 AI 控制浏览器去做后续的自动化操作没问题，但登录这一步必须由人来完成。 原因很简单——把账号密码交给 AI，不管它是本地运行的还是在线的，都多了一层不必要的风险。你自己登录，它只拿 cookie，各管各的。

第二步：摸清系统 API 结构

这是整个流程里最关键的一步。登录之后，opencode 没有傻乎乎地去"翻页截图"，而是去分析了系统的 API 接口。

它用浏览器开发者工具（或者说 Selenium 的 network 监控）发现了后端的几个关键接口：

dynamicListJson：列出某个阶段的所有学生材料记录
getDownloadUrl：获取某个文件的下载地址
checkReport：查看查重报告

每个接口需要的参数、请求头、cookie，它自己去摸索了一遍，最后把 API 的调用方式完整摸清了。

这个过程有点像你用浏览器的"检查元素"去分析网页，只不过 AI 比你快得多，而且不会漏。

第三步：批量下载所有材料

摸清 API 之后，就进入干活的环节了。

opencode 写了一个 Python 脚本，遍历七位学生的所有阶段（开题报告、初稿、二稿、中期检查、答辩稿、成绩评定、终稿），逐个调用下载接口，把文件保存到对应目录：

毕业论文材料核查/
├── 下载_学生材料/
│   ├── 学生A_2022000001/
│   │   ├── 开题报告/
│   │   ├── 初稿/
│   │   ├── 二稿/
│   │   ├── 中期检查/
│   │   ├── 答辩稿/
│   │   ├── 成绩评定/
│   │   └── 最终稿/（含佐证附件和查重报告）
│   ├── 学生B_2022000002/
│   ├── ...

73 个文件，160MB，全部按学生和阶段分目录存放。查重报告是 ZIP 压缩包，自动解压。

这一步如果手动做——打开每个学生的每个阶段、点击下载、保存到对应文件夹——大概需要一个多小时。opencode 跑了五分钟。

第四步：从 PDF 和 docx 中提取标题

接下来才是真正的难点：从不同格式的文件中，准确提取出"课题名称"或"论文题目"字段。

难点在于不同格式的结构完全不同：

开题报告 PDF：标题在"题目（中、外文）："这个标签后面，中文标题在第一行，英文标题在第二行。
成绩评定表 PDF：标题在"论文题目"字段后面，但可能跨多行。
查重报告 PDF：标题在"NO."编号后面，紧跟着论文题目。
docx 文件：标题可能在封面、摘要、正文里多次出现。

刚开始我用的正则表达式是 r'论文题目\s*([^\n]+)'——只取第一个换行符之前的内容。结果成绩评定表里的长标题被截断了，比对的时候出现了大量"不一致"的假阳性。

后来改成更聪明的方案：不是精确提取标题文本，而是把系统中的完整标题做归一化处理（去除所有空白、去除字母间距），然后检查归一化后的系统标题是否出现在文件的全文中。这样就完全避免了截断问题。

def norm(s):
    s = re.sub(r'\s+', '', str(s))
    s = re.sub(r'([A-Za-z]) ([A-Za-z])', r'\1\2', s)
    return s

# 检查系统标题是否出现在 docx 正文（归一化后）
sys_n = norm("面向本地大语言模型运行时的环境感知辅助系统设计与实现")
fulln = norm('\n'.join(p.text for p in docx_paragraphs))
hit = sys_n in fulln

归一化的逻辑还处理了 PDF 中常见的"字母间距"问题——有些 PDF 把字母间距放大了，比如"Windows"在 PDF 里可能显示为"W i n d o w s"，归一化时把这些间距去掉再比较。

这个细节是人手工比对时很难注意到的，但 AI 写脚本处理起来很自然。

第五步：生成对照表格

全部文件下载、提取、比对完成后，opencode 生成了一份对照表格，把七位学生在每个阶段的题目信息排列在一起，一眼就能看出有没有不一致的地方。

表格大概是这样的结构：

学生	系统课题名称	开题报告题目	成绩评定表题目	查重报告标题	初稿正文	二稿正文	答辩稿正文	终稿正文
学生A	xxx	✅ 一致	✅ 一致	✅ 一致	✅ 含完整题目	✅ 含完整题目	✅ 含完整题目	✅ 含完整题目
学生B	xxx	✅ 一致	✅ 一致	✅ 一致	✅ 含完整题目	✅ 含完整题目	✅ 含完整题目	✅ 含完整题目
...

查重率也一并列了出来——每位学生的论文重复率、AIGC 检测率，系统侧是否标记为"完成"。

这个表格就是整次核查的核心产出。 AI 把 73 个文件里分散的信息汇总到一张表里，人不需要再打开 73 个原始文件一个一个看了——对着这张表逐行审阅就行。

第六步：人来审阅

表格生成完，AI 的活就基本干完了。剩下的事情是人来做的：

逐行逐列读完整张对照表，每位学生在每个阶段的题目、查重率、附件状态，全部过一遍
看到哪个单元格有疑点，就打开对应的原始文件核实
检查佐证附件是否齐全（程序代码、运行截图、设计文档）
检查双导师信息在系统里是否登记完整
确认过程材料签字是否完整
最后根据表格的整体情况，写出核查结论

这一步是 AI 替代不了的。 AI 能把信息汇总成表格，但"这个表格说明了什么"、"哪些地方需要进一步确认"，判断权永远在你手里。

整个过程用了多久

从登录系统到报告生成完毕，整个过程大约用了不到一个小时。其中大部分时间花在 API 探索和 PDF 解析上——登录、下载、整理目录这些都是几分钟的事。

如果完全手动做：打开 73 个文件、逐个核对标题、手工记录在表格里，保守估计需要三到五个小时，还不算中间打开错文件、找错行之类的失误成本。

但这件事的核心不是"AI 多厉害"

回到开头说的那个框架：人提出问题 → AI 发现问题 → 人决定问题。

这个流程里，每一步都不能缺。没有人提出问题，AI 不知道该查什么；没有 AI 去执行，人得自己打开 73 个文件一个一个看；没有人来决定结果，AI 给你的对照表格就只是一堆符号，你不知道该信任还是该怀疑。

拿这次的事来说：

人提出问题：我告诉 opencode"比对七位学生在开题报告、成绩评定表、查重报告、论文正文中的课题名称是否一致"。这一句话界定了比对的范围和维度。如果我没说"课题名称"，它可能去比对学生姓名；如果我没说"论文正文"，它可能漏掉 docx 里的信息。
AI 发现问题：opencode 下载了 73 个文件，逐个解析 PDF 和 docx，把每个阶段的题目提取出来，和系统里的课题名称做归一化比对，最后生成对照表格。这个过程涉及 PDF 解析、正则表达式、文本归一化、文件名处理等一堆技术细节，全让 AI 干了。
人决定问题：对照表格摆到面前，我逐行逐列地读——每位学生在每个阶段的题目、查重率、附件情况，全部过一遍，然后根据结果写核查结论。AI 不能替我做这个判断——它不知道上级部门对这份报告的具体要求，也不知道哪些"看起来一致"的地方其实藏着猫腻。

AI 做的是"把材料摆到你面前"，人做的是"确认材料没问题"。这两步缺一不可。

但最关键的不是这两步，而是开头那一步——你得自己先把问题想清楚。"要比对什么"、"比对的范围是什么"、"什么情况下算有问题"，这些问题不先想明白，后面 AI 再厉害也是白搭。你给它一个模糊的指令，它给你一个模糊的结果，最后你还得自己从头来。

对类似场景的建议

如果你也有类似的需求——批量核查文档、比对多处信息、做交叉验证——以下几条经验可能有用：

明确比对维度。在你跟 AI 说需求的时候，就把"要比对什么"说清楚。"题目是否一致"、"查重率是否真实"、"签字是否完整"，每一条都单独列出来。AI 不知道你关心什么，你得告诉它。
处理格式差异。不同文件格式（PDF、docx、图片）的解析方式完全不同，AI 会自己找工具去处理，但你可能需要在发现它解析出错的时候及时纠正——比如"成绩评定表的标题跨了两行，你的正则截断了"。
让 AI 汇总成表格再审。AI 的价值不只是"帮你找问题"，而是把分散在 73 个文件里的关键指标汇总成一张完整的对照表格。人审阅的是这张表格，不是原始文件。表格里该有的信息都有——学生姓名、系统课题名称、各阶段题目、查重率、附件状态——逐行读完，整体判断，比自己打开文件一个个看靠谱得多，也不会漏。
核查报告要分优先级。所有问题都标"紧急"等于没有紧急。分成"必须处理"、"需要核实"、"建议改进"三级，对 deadline 前的决策帮助很大。

总结一下

这篇的例子：用 opencode 把"七个人的毕业论文材料核查"从一个手动三小时的活，变成了一个小时半自动完成的任务。

核心工作流是：人提出问题（比对什么、比对哪些人、比对哪些材料）→ AI 执行（登录、下载、解析、比对、生成表格）→ 人来审阅（逐行读表、写结论）。每一步都有技术难点——登录的 cookie 管理、API 的参数探索、PDF 的标题提取、docx 的文本归一化——但这些都让 AI 去处理了。

人需要做的只有两件事：开头把需求想清楚，结尾把结果审一遍。

控制权始终在你手里，AI 只是替你跑腿。工具提升的是效率，不是判断力。效率越高，越需要你把判断的事情想清楚。这件事不管用不用 AI 都是一样的。

本地模型能不能当好 agent？7 个模型跑完 12 个长链复杂任务的实测

2026-08-23T00:20:00+08:00

本地模型能不能当好 agent？7 个模型跑完 12 个长链复杂任务的实测

测一个模型的"单轮对话能力"很容易，测一个模型"能不能真的当 agent 干活"就难得多了——因为它要连续很多步：读文件、写代码、跑命令、查目录、改 Bug、再验证结果，中间任何一步出错都可能带偏后面所有步骤。

这次用 Hermes Agent（本地部署）在单张 RX 7900 XTX 上，把 7 个模型放进 12 个复杂长链任务里跑了一遍，每个任务最多允许 40 轮工具调用，用 35 个自动验证检查点来判分。测的是模型在"真实干活"场景下的工具调用和长链执行能力，而不是单纯的口头问答。

测了什么

12 个任务覆盖了 agent 日常要干的活：

数据分析：生成 sales.csv 并算出各区域合计、最佳区域
Bug 修复：写一个 stats.py，再修好里面的 Bug 并跑通测试
包构建：搭一个 Python 包目录结构（含 init.py、hello.py、setup.py）
查找修补：建多个文件、按规则查找内容、打补丁、拼接文件
网页项目：搭一个迷你站点（index.html / style.css / script.js / manifest）
记忆运算：用记忆工具存 5 个商品价格，再跨会话算总价（考验长期记忆）
日志分析：生成 app.log，再从日志里提取统计
CLI 工具：写一个能跑命令行参数的 fib.py
目录搜索：建目录树、放文件、移动文件、验证
JSON 查询：生成 products.json 数组，再按字段查询
文本处理：生成一段精确文本并处理
毕业设计：一个 7 步多阶段任务，要求用 todo 工具跟踪步骤

环境：Hermes Agent + llama-server，单张 RX 7900 XTX，全部模型无 CPU 卸载，MTP 投机解码启用（不支持者自动降级），最大可用上下文。3.8 系列用 reasoning_effort=medium 思考档，3.6 系列关闭思考。模型间通过独立 HERMES_HOME 隔离记忆，杜绝互相污染。

总分榜

排名	模型	家族	检查点	得分	耗时(s)	工具调用
1	Qwen 3.6 Q5Hyb	Qwen3.6-27B	35/35	100.0%	699	95
2	Huihui 3.6 Q5Hyb	Huihui-27B 去审查	35/35	100.0%	679	89
3	Qwen 3.8 Q5Hyb	Qwen3.8-27B	35/35	100.0%	893	75
4	Uncensored 3.8 Q5Hyb	3.8-27B 去审查	35/35	100.0%	712	73
5	Nemotron 3.5 Lightning	Nemotron-30B-A3B	33/35	94.3%	775	107
6	GLM-4.7-Flash	GLM-Flash-MoE	31/35	88.6%	1043	101
7	Qwen3.5-9B	Qwen3.5-9B	28/35	80.0%	923	132

逐任务热力图

逐任务明细

模型	数据分析	Bug修复	包构建	查找修补	网页项目	记忆运算	日志分析	CLI工具	目录搜索	JSON查询	文本处理	毕业设计
Qwen 3.6 Q5Hyb	100	100	100	100	100	100	100	100	100	100	100	100
Huihui 3.6 Q5Hyb	100	100	100	100	100	100	100	100	100	100	100	100
Qwen 3.8 Q5Hyb	100	100	100	100	100	100	100	100	100	100	100	100
Uncensored 3.8 Q5Hyb	100	100	100	100	100	100	100	100	100	100	100	100
Nemotron 3.5 Lightning	100	100	100	100	100	0	100	100	100	100	100	100
GLM-4.7-Flash	67	100	100	100	100	0	100	100	50	100	100	100
Qwen3.5-9B	100	0	100	0	100	0	100	100	100	100	100	100

几个有意思的发现

1. 四个 27B 全家满分，但速度和工具效率不一样

Qwen 3.6、Huihui 3.6、Qwen 3.8、Uncensored 3.8 四个模型都是 35/35 满分，但效率差异明显：

耗时最少的是 Huihui 3.6（679s）和 Qwen 3.6（699s），3.8 家族明显更慢（Qwen 3.8 要 893s）
工具调用次数最少的是 Uncensored 3.8（73 次）和 Qwen 3.8（75 次）——说明它们"想得少、一次到位"；3.6 家族调用更多（89-95 次），更谨慎但速度更快
值得注意的是：3.6 家族 MTP 接受率更高（0.86-0.88 vs 3.8 的 0.79-0.83），配合更少的思考 token，整体反而更快

这其实延续了之前大阅兵里的结论：27B 这个量级上，3.6 和 3.8 能力基本打平，3.6 靠 MTP 和关闭思考在速度上更占优，工具调用效率的差异更多来自"思考策略"而非"模型能力"。

2. 去审查基本无损

Huihui 3.6（去审查）100%，Uncensored 3.8（去审查）100%——去对齐在长链 agent 任务上几乎不影响工具调用能力，甚至 Huihui 3.6 还是全场最快的。之前测试里担心的"去审查会不会损失能力"在这批场景里没看到代价。

3. 记忆运算是所有模型的共同洼地

六个模型里，除了四个 27B 满分，Nemotron、GLM-4.7-Flash、Qwen3.5-9B 全都在 t06_memory_arithmetic（记忆运算）上得 0 分。这个任务要求用记忆工具存 5 个商品价格、再跨会话算总价——本质是考验"长期记忆 + 多步工具调用"的组合能力。这三个模型要么没把价格正确存进记忆，要么没能在后续步骤调出来。这说明记忆类工具的稳定使用，比单纯"能回答问题"难得多，是中小模型 agent 能力的明显短板。

4. GLM-4.7-Flash：能干的都能干，干不细的会出小错

GLM-4.7-Flash 拿了 88.6%，多数任务满分，但在数据分析上 67%（算错了一个合计数字）、目录搜索 50%（结果长度不对）。它没有大翻车，但会在"需要精确数值"的地方偶尔出错——这正好符合它 MoE 轻量版的定位：速度快、范围广，精度上略逊。

5. Qwen3.5-9B：参数规模是硬约束

9B 只拿了 80%，在 Bug 修复（0 分）、查找修补（0 分）、记忆运算（0 分）三个任务上失败。而且它工具调用最多（132 次）、耗时也长（923s）——说明 9B 模型在长链任务里容易"绕圈子"，反复试错但找不到关键步骤。Agent 场景对模型的"规划能力"要求，比单轮问答高得多，参数规模在这时成了实打实的门槛。

6. Nemotron：能打，但会犯小错

Nemotron 拿了 94.3%，唯一扣分在记忆运算（0 分），另外还有 1 次工具错误。它工具调用很激进（107 次，全场第二多），terminal 用了 56 次——干活很卖力，但有时候会多走弯路。

结论

冠军是 Qwen 3.6 Q5Hyb——12 个长链复杂任务全部通过，35/35 检查点满分，耗时也只有 699 秒，是"满能力"里效率最高的。

对选型来说，这次测试给出几个直接可用的判断：

27B 是 agent 任务的安全线：四个 27B（含去审查）全部满分，能力层面没有短板，主要差在速度和工具调用风格上
要快就选 3.6 家族：MTP 接受率更高、可关思考，同样满分下比 3.8 快 20% 以上
去审查版在 agent 场景无代价：如果在意内容自由度，Huihui 3.6 或 Uncensored 3.8 可以放心用
记忆类工具是中小模型的试金石：能不能稳定"记住东西、跨步调用"，比能不能答对题更能区分 agent 能力

方法论说明：评测框架是 Hermes Agent 自带的 batch_runner（40 轮上限、单 worker 串行、断点续跑）；每任务独立工作目录 + 独立 HERMES_HOME 隔离记忆；35 个确定性验证检查点（文件存在性、内容精确匹配、脚本执行结果、JSON 字段）；原始数据含完整对话+工具调用轨迹（trajectories.jsonl）、逐任务工作区快照、服务端日志（MTP 接受率）。所有模型均在同一张 7900 XTX、llama-server 后端下测试，未做多次重复，结果受单次运行影响。

7900XTX 本地模型大阅兵：开源小/中大三档，能否追上 GPT-3.5 与 GPT-4o？

2026-08-21T21:00:00+08:00

7900XTX 本地模型大阅兵：开源小/中/大三档，能否追上 GPT-3.5 与 GPT-4o？

单张 7900XTX 24GB 上实测 22 个开源模型，对标 GPT-3.5 与 GPT-4o。发现开源已追平 2024 闭源第一梯队；工具调用主力首选 Qwen 3.6 27B Q5Hyb，六维 90.5、BFCL 89.4 全场第一，综合来看甚至强于 Qwen 3.8 27B；性价比选 Gemma4 E4B，极致速度选 Nemotron。

之前我们曾把本地模型和 GPT-3.5 做过对比。现在回头看，除了 GPT-3.5，第二年的 GPT-4o 同样值得参照——一个代表"能用"的门槛，一个代表 2024 年第一梯队的标杆。这次的雷达图同时画上这两条基线。

模型有大有小。这次在单张 7900XTX 24GB 上，选了一批当前有代表性的模型——硬盘空间有限，不可能全装，只选不算太旧、各尺寸段有代表性的：小尺寸（≤1.2GB）、中尺寸（1.2-8GB）、大尺寸（>8GB，需 8G+ 显存）三档。核心问题只有一个：现在的开源模型，和当年的闭源模型相比，到底怎么样了？

所有模型均在同一张 7900XTX 上实测（六维基准各 30 题 + 单流生成速度 + 官方 BFCL 工具调用）；闭源基线取公开可查证分数（出处逐项标注，见下表）。

所谓"六维"，指下表参照基线里列出的六个基准，覆盖知识、代码、数学、常识推理四类能力，每维 30 题、"六维均分"即六项准确率的算术平均：

MMLU：多任务语言理解（专业/通识知识选择题）；
HumanEval：代码生成（函数补全，pass@1）；
GSM8K：小学数学应用题（多步推理）；
HellaSwag：常识句子补全（反直觉干扰项）；
ARC：科学/常识问答；
WinoGrande：指代消解（代词指向）。

工具调用方面：BFCL（Berkeley Function Calling Leaderboard）就是标准的工具调用评测，本次 22 个模型全部跑完 V4 Non-Live 七类 AST（见各档表格与专项表）；ToolBench 是另一个更重的 agent 型工具调用基准（多步规划），仅 27B 家族六个模型有实测，主要体现出 27B 的 3.6 还是比 3.8 更好的选择。

参照基线：GPT-3.5 与 GPT-4o

维度	GPT-3.5-Turbo (2023)	GPT-4o (2024)	出处
MMLU	70.0	88.7	GPT-4 Technical Report (arXiv:2303.08774) / OpenAI 官方
HumanEval 编程	48.1	90.2	同上 / OpenAI 官方（System Card + Azure AI 目录）
GSM8K	57.1	96.0*	同上 / *官方未发布，社区实测中位
HellaSwag	85.5	95.3*	同上 / *llm-stats 社区实测
ARC	85.2	95.5*	同上 / *llm-stats 社区实测
WinoGrande	81.6	88.5*	同上 / *llm-stats 社区实测
BFCL 工具调用（单轮 AST）	84.5	85.9 / 87.4	BFCL v3 官方榜单：GPT-3.5-Turbo-0125 (FC) AST 84.52（ToolACE 论文 arXiv:2409.00920 引 2024-09-20 榜单）；GPT-4o-2024-08-06 AST 85.9（Amazon Nova 报告 arXiv:2506.12103 引 2024-11-17 榜单）、gpt-4o-2024-11-20 (FC) Non-Live AST 87.42（官方榜 2025-01-18 快照）
BFCL Overall（含多轮）	51.93（多轮仅 19.12）	68.9 / 69.6（多轮 63.4）	同上
生成速度	~65 t/s (API)	~92 t/s (API)	Artificial Analysis / llm-stats 实测中位

说明：①本地模型 BFCL 为 V4 七类 AST 平均，闭源为 v3 榜单口径，测试集版本不同，对比仅供参考；②GPT-3.5 的 BFCL Overall 只有 51.93，主因是多轮（19.12）拉胯——单轮工具调用它并不弱（84.5）；③带 * 维度为官方未发布、取社区实测中位；④HumanEval 均为官方 0-shot/pass@1 口径。

一、小尺寸档（≤1.2GB）——秒开级轻骑兵

排名	型号	家族	参数量	量化	文件大小	代码 HumanEval	工具调用 BFCL	六维均分	生成 t/s
1	Qwen3 0.6B	Alibaba Qwen3	0.75B	Q4_K_M	0.52GB	53.3	65.5	47.2	250.9
2	Qwen3.5 0.8B	Alibaba Qwen3.5	0.87B	Q8_0	1.0GB	33.3	57.8	42.8	185.4
3	Granite4 0.35B	IBM Granite 4.0	0.34B	Q8_0	0.37GB	66.7	67.0	40.0	258.2
4	LFM2.5-Think 1.2B	LiquidAI LFM2.5	1.2B	Q4_K_M	0.73GB	30.0	72.3	28.3	355.9
5	LFM2.5 0.35B	LiquidAI LFM2.5	0.35B	Q8_0	0.38GB	3.3	45.9	24.4	374.4

特点：Qwen3 0.6B 微型全能底子；Qwen3.5 0.8B 新一代微型、数学强；Granite4 0.35B 企业级安全调优、MoE 混合架构；LFM2.5-Think 1.2B 思考型、小身材长推理；LFM2.5 0.35B 非Transformer混合架构。

这一档 5 个模型全部在 1.2GB 以内，加载秒开、生成速度 185-374 t/s 是全部参赛选手里最快的。共同短板也很明显：六维平均分只有 24-47，MMLU/数学都远远够不着 GPT-3.5 的边。它们的正确用法是高频轻任务：文本翻译（短句翻译几乎瞬时返回，日常中英互译质量够用、速度是大模型的 3-5 倍）、分类、摘要、格式转换、意图路由——以及给大模型当"前置路由"，判断该不该升级到大模型处理。代码能力分化明显：Granite4 0.35B 的 HumanEval 66.7 是本档意外亮点，Qwen3 0.6B 53.3 次之，LFM2.5 两兄弟（3-30 分）基本不会写代码。工具调用：本档 BFCL 实测 LFM2.5 0.35B 45.9、Granite4 0.35B 67.0、LFM2.5-Think 1.2B 72.3、Qwen3 0.6B 65.5、Qwen3.5 0.8B 57.8——远低于大模型档（77-89），简单单工具调用勉强可用（Granite 0.35B 的 multiple 85 出人意料），但平行调用和复杂 agent 别指望。

➡️ 本档推荐：Qwen3 0.6B（六维 47.2 分 + 250.9 t/s；本档首选翻译/摘要/路由等轻任务）

二、中尺寸档（1.2-8GB）——单卡实用主力

排名	型号	家族	参数量	量化	文件大小	代码 HumanEval	工具调用 BFCL	六维均分	生成 t/s
1	Gemma4 E4B	Google Gemma4	4B 有效(总7.5B)	Q4_K_M	5.0GB	100.0	81.9	83.4	115.0
2	Gemma4 12B	Google Gemma4	11.9B	Q4_K_M	7.1GB	83.3	77.6	80.6	62.4
3	Qwen3.5 9B	Alibaba Qwen3.5	9.7B	Q4_K_M	6.6GB	73.3	80.9	80.5	79.3
4	Gemma4 E2B	Google Gemma4	2B 有效(总4.6B)	Q4_K_M	3.1GB	100.0	79.7	75.0	154.9
5	OmniCoder2 9B	社区 OmniCoder	9.0B	Q4_K_M	5.7GB	93.3	81.3	48.3	85.1

特点：Gemma4 E4B 性价比之王；Gemma4 12B 中量级标杆；Qwen3.5 9B 中坚全能；Gemma4 E2B 轻任务够用；OmniCoder2 9B 代码特化、通用偏科。

这一档开始进入"真正能用"的区间：五个模型六维平均分 48-83，Gemma4 E4B 以 4B 参数拿到 83.4 分 + 115 t/s，超过 GPT-3.5 六维平均（71.2），是全场性价比最高的一档。代码能力全员过关：Gemma4 E2B/E4B 的 HumanEval 双双 100 分，OmniCoder2 93.3（不愧代码特化），Gemma4 12B 83.3 / Qwen3.5 9B 73.3 稳定。E2B（75 分）证明了 2B 就是日常轻聊天+轻代码的底线；Qwen3.5 9B 和 Gemma4 12B 是均衡中坚；OmniCoder 偏科严重（只会写代码，通用垫底 48.3）。工具调用：本档 5/5 模型完成 BFCL 实测（见上表），Qwen3.5/Gemma4 家族模板层均已验证支持 function calling。单卡日常主力建议从这档选——除非你确定需要旗舰级能力。

➡️ 本档推荐：Gemma4 E4B（六维 83.4 分 + HumanEval 100 + 115 t/s，性价比之王；工具调用已实测 BFCL 81.9，需要 function calling 的场景本档即可胜任）

三、大尺寸档（>8GB，需 8G+ 显存）——旗舰竞技场

排名	型号	家族	参数量	量化	文件大小	代码 HumanEval	工具调用 BFCL	六维均分	生成 t/s
1	Qwen3.6 35B MoE	Alibaba Qwen3.6	34.7B(A3B)	Q4_K_M	22.0GB	96.7	83.0	93.4	106.7
2	Gemma4 31B	Google Gemma4	30.7B 稠密	Q4_K_M	18.0GB	100.0	83.6	91.7	29.3
3	Nemotron 3.5 Lightning	NVIDIA	30B(A3B)	Q4_0	18.9GB	100.0	79.7	91.1	129.0
4	Qwen 3.6 27B Q5Hyb	Alibaba Qwen3.6	27B 稠密	Q5Hyb	20.6GB	100.0	89.4	90.5	29.91
5	Qwen 3.8 27B Q4_K_M	Alibaba Qwen3.8	27B 稠密	Q4_K_M	16.8GB	100.0	86.0	90.0	37.94
6	Qwen 3.8 27B Q5Hyb	Alibaba Qwen3.8	27B 稠密	Q5Hyb	20.6GB	100.0	85.1	90.0	30.22
7	Huihui 3.6 27B Q5Hyb	Huihui 去审查	27B 稠密	Q5Hyb	20.6GB	100.0	89.2	89.4	30.73
8	Qwen 3.6 27B Q4_K_M	Alibaba Qwen3.6	27B 稠密	Q4_K_M	17.0GB	100.0	88.3	88.9	36.32
9	Uncensored 3.8 27B Q5Hyb	Heretic 去审查	27B 稠密	Q5Hyb	20.6GB	100.0	86.8	88.3	30.72
10	GLM4.7 Flash	智谱 GLM	29.9B MoE	Q4_K_M	18.0GB	100.0	79.4	88.3	95.5
11	Gemma4 26B MoE	Google Gemma4	25.2B(A4B)	Q4_K_M	16.0GB	100.0	78.3	87.2	91.1
12	GPT-OSS 20B	OpenAI gpt-oss	20.9B(A3.6B)	Q4_K_M	11.0GB	86.7	52.9	78.9	155.0

特点：Qwen3.6 35B MoE 全场总分第一；Gemma4 31B 大杯旗舰、速度慢；Nemotron 3.5 Lightning Mamba2+MoE、agent 执行层；Qwen 3.6 27B Q5Hyb 定制混合量化(Q5主体+Q8注意力)；Qwen 3.8 27B Q4_K_M 混合线性注意力架构；Qwen 3.8 27B Q5Hyb 定制混合量化；Huihui 3.6 27B Q5Hyb abliterated 去对齐；Qwen 3.6 27B Q4_K_M 官方标准量化；Uncensored 3.8 27B Q5Hyb 消融法去对齐；GLM4.7 Flash 国产旗舰 MoE 轻量版；Gemma4 26B MoE MoE 高效大杯；GPT-OSS 20B OpenAI 开源 MoE。

12 个模型挤在这一档，也是和 GPT-4o 正面交锋的主战场。Qwen3.6 35B MoE 以 93.4 分 + 106.7 t/s 双料登顶，但是工具调用不如 27B 家族的，好在六维全面越过 GPT-4o 基线（89.5）；Gemma4 31B（91.7 分）是稠密阵营最强但速度只有 29 t/s；Nemotron 3.5 Lightning（91.1 分 + 129 t/s）靠 Mamba2+MoE 架构拿到全场最快大模型；Qwen 27B 家族六个模型挤在 88.9-90.5 的密集区间——量化选择的影响（约 1 分）远小于家族差异。这一档全员在能力面上越过或贴住 GPT-4o，仅在速度轴被本地小模型反超。

本档工具调用专项实测——BFCL（V4 Non-Live AST 七类官方口径）12 个模型全部实测：

型号	BFCL 工具调用
Qwen3.6 35B MoE	83.0
Gemma4 31B	83.6
Nemotron 3.5 Lightning	79.7
Qwen 3.6 27B Q5Hyb	89.4
Qwen 3.8 27B Q4_K_M	86.0
Qwen 3.8 27B Q5Hyb	85.1
Huihui 3.6 27B Q5Hyb	89.2
Qwen 3.6 27B Q4_K_M	88.3
Uncensored 3.8 27B Q5Hyb	86.8
GLM4.7 Flash	79.4
Gemma4 26B MoE	78.3
GPT-OSS 20B	52.9

BFCL 七类中 simple_python 全员 93-97；Java/JS 是所有模型的洼地（60-78）；3.8 家族 irrelevance（该拒判时不调用）明显弱于 3.6（70-75 vs 90），去审查版 Uncensored 更低至 47.9。

ToolBench-Static 专项实测（100 域内+50 域外抽样；仅 27B 家族六兄弟有实测，其余大模型未跑）：

型号	ToolBench 域内 plan_em	域外 plan_em
Qwen 3.6 27B Q5Hyb	0.822	0.837
Qwen 3.8 27B Q4_K_M	0.822	0.857
Qwen 3.8 27B Q5Hyb	0.835	0.816
Huihui 3.6 27B Q5Hyb	0.800	0.816
Qwen 3.6 27B Q4_K_M	0.789	0.816
Uncensored 3.8 27B Q5Hyb	0.833	0.857

➡️ 本档推荐：综合主力首选 Qwen 3.6 27B（Q5Hyb）——27B 量级能力均衡无短板，工具调用非常强（BFCL 89.4 全场第一、ToolBench 域内 0.822、六维 90.5 领先 27B 家族）；且 3.8 在 27B 档并没有比 3.6 强太多（六维 90.0 vs 90.5 持平，工具调用反而落后 3-4 分），换代收益有限。要极致总分再上 Qwen3.6 35B MoE（六维 93.4 分，工具调用实测 83.0）；要速度选 Nemotron（129 t/s，BFCL 79.7，Java/JS 偏弱）。

四、全景：22 模型同场雷达

排名	型号	参数量	文件大小	代码 HumanEval	工具调用 BFCL	六维平均分	生成 t/s
1	Qwen3.6 35B MoE	34.7B(A3B)	22.0GB	96.7	83.0	93.4	106.7
2	Gemma4 31B	30.7B 稠密	18.0GB	100.0	83.6	91.7	29.3
3	Nemotron 3.5 Lightning	30B(A3B)	18.9GB	100.0	79.7	91.1	129.0
4	Qwen 3.6 27B Q5Hyb	27B 稠密	20.6GB	100.0	89.4	90.5	29.91
5	Qwen 3.8 27B Q4_K_M	27B 稠密	16.8GB	100.0	86.0	90.0	37.94
6	Qwen 3.8 27B Q5Hyb	27B 稠密	20.6GB	100.0	85.1	90.0	30.22
7	Huihui 3.6 27B Q5Hyb	27B 稠密	20.6GB	100.0	89.2	89.4	30.73
8	Qwen 3.6 27B Q4_K_M	27B 稠密	17.0GB	100.0	88.3	88.9	36.32
9	Uncensored 3.8 27B Q5Hyb	27B 稠密	20.6GB	100.0	86.8	88.3	30.72
10	GLM4.7 Flash	29.9B MoE	18.0GB	100.0	79.4	88.3	95.5
11	Gemma4 26B MoE	25.2B(A4B)	16.0GB	100.0	78.3	87.2	91.1
12	Gemma4 E4B	4B 有效(总7.5B)	5.0GB	100.0	81.9	83.4	115.0
13	Gemma4 12B	11.9B	7.1GB	83.3	77.6	80.6	62.4
14	Qwen3.5 9B	9.7B	6.6GB	73.3	80.9	80.5	79.3
15	GPT-OSS 20B	20.9B(A3.6B)	11.0GB	86.7	52.9	78.9	155.0
16	Gemma4 E2B	2B 有效(总4.6B)	3.1GB	100.0	79.7	75.0	154.9
17	OmniCoder2 9B	9.0B	5.7GB	93.3	81.3	48.3	85.1
18	Qwen3 0.6B	0.75B	0.52GB	53.3	65.5	47.2	250.9
19	Qwen3.5 0.8B	0.87B	1.0GB	33.3	57.8	42.8	185.4
20	Granite4 0.35B	0.34B	0.37GB	66.7	67.0	40.0	258.2
21	LFM2.5-Think 1.2B	1.2B	0.73GB	30.0	72.3	28.3	355.9
22	LFM2.5 0.35B	0.35B	0.38GB	3.3	45.9	24.4	374.4

速度为单流实测（27B 取无 MTP 基线）；六维=30题/维；GPT-3.5 基线六维平均 71.2，GPT-4o 约 89.2。颜色=家族，线型=家族内成员；黑色加粗虚线=GPT-3.5，灰色点划线=GPT-4o。

4.1 详细分数全表（22 模型六维明细 + BFCL 汇总）

六维明细（MMLU / HumanEval / GSM8K / HellaSwag / ARC / WinoGrande，各 30 题 acc；按文件大小升序）：

型号	文件GB	MMLU	HumanEval	GSM8K	HellaSwag	ARC	WinoGrande	六维均分
Granite4 0.35B	0.37	40.0	66.7	23.3	33.3	26.7	50.0	40.0
LFM2.5 0.35B	0.38	26.7	3.3	6.7	23.3	46.7	40.0	24.4
Qwen3 0.6B	0.52	36.7	53.3	66.7	20.0	56.7	50.0	47.2
LFM2.5-Think 1.2B	0.73	23.3	30.0	46.7	20.0	13.3	36.7	28.3
Qwen3.5 0.8B	1.0	13.3	33.3	73.3	40.0	50.0	46.7	42.8
Gemma4 E2B	3.1	66.7	100.0	96.7	33.3	80.0	73.3	75.0
Gemma4 E4B	5.0	70.0	100.0	86.7	66.7	90.0	86.7	83.4
OmniCoder2 9B	5.7	13.3	93.3	80.0	23.3	30.0	50.0	48.3
Qwen3.5 9B	6.6	66.7	73.3	90.0	80.0	90.0	83.3	80.5
Gemma4 12B	7.1	70.0	83.3	66.7	80.0	96.7	86.7	80.6
GPT-OSS 20B	11.0	63.3	86.7	90.0	63.3	93.3	76.7	78.9
Gemma4 26B MoE	16.0	66.7	100.0	76.7	90.0	96.7	93.3	87.2
Qwen 3.8 27B Q4_K_M	16.8	66.7	100.0	96.7	93.3	100.0	83.3	90.0
Qwen 3.6 27B Q4_K_M	17.0	70.0	100.0	100.0	86.7	93.3	83.3	88.9
GLM4.7 Flash	18.0	73.3	100.0	93.3	80.0	93.3	90.0	88.3
Gemma4 31B	18.0	86.7	100.0	76.7	93.3	100.0	93.3	91.7
Nemotron 3.5 Lightning	18.9	90.0	100.0	90.0	76.7	93.3	96.7	91.1
Huihui 3.6 27B Q5Hyb	20.6	70.0	100.0	100.0	93.3	93.3	80.0	89.4
Qwen 3.6 27B Q5Hyb	20.6	73.3	100.0	100.0	90.0	93.3	86.7	90.5
Qwen 3.8 27B Q5Hyb	20.6	70.0	100.0	96.7	90.0	100.0	83.3	90.0
Uncensored 3.8 27B Q5Hyb	20.6	66.7	100.0	93.3	86.7	100.0	83.3	88.3
Qwen3.6 35B MoE	22.0	96.7	96.7	86.7	93.3	100.0	86.7	93.4

BFCL 工具调用汇总（27B 家族为官方 Non-Live Overall Acc，其余为 V4 七类 AST 平均）：

型号	文件GB	BFCL 工具调用
Granite4 0.35B	0.37	67.0
LFM2.5 0.35B	0.38	45.9
Qwen3 0.6B	0.52	65.5
LFM2.5-Think 1.2B	0.73	72.3
Qwen3.5 0.8B	1.0	57.8
Gemma4 E2B	3.1	79.7
Gemma4 E4B	5.0	81.9
OmniCoder2 9B	5.7	81.3
Qwen3.5 9B	6.6	80.9
Gemma4 12B	7.1	77.6
GPT-OSS 20B	11.0	52.9
Gemma4 26B MoE	16.0	78.3
Qwen 3.8 27B Q4_K_M	16.8	86.0
Qwen 3.6 27B Q4_K_M	17.0	88.3
GLM4.7 Flash	18.0	79.4
Gemma4 31B	18.0	83.6
Nemotron 3.5 Lightning	18.9	79.7
Huihui 3.6 27B Q5Hyb	20.6	89.2
Qwen 3.6 27B Q5Hyb	20.6	89.4
Qwen 3.8 27B Q5Hyb	20.6	85.1
Uncensored 3.8 27B Q5Hyb	20.6	86.8
Qwen3.6 35B MoE	22.0	83.0

4.2 27B 家族深挖数据对比（拒答率 / τ² / MTP / ToolBench 幻觉率 / BFCL irrelevance）

结论里提到的拒答率、irrelevance 拒判、MTP 加速、τ² 智能体等，原始实测数据如下（27B 家族六个模型；τ² 为本地 user-sim 口径、非官方协议；拒答率越低越不拘束）：

型号	拒答率	τ² 成功率	MTP n=3 t/s	MTP 加速比	无MTP t/s	ToolBench 幻觉率(域内/域外)	BFCL irrelevance
Qwen 3.8 27B Q4_K_M	0.05	100%	66.4	1.75x	37.9	0.03 / 0.04	74.6
Qwen 3.6 27B Q4_K_M	0.15	93%	60.2	1.66x	36.3	0.03 / 0.02	90.0
Qwen 3.6 27B Q5Hyb	0.15	93%	55.1	1.84x	29.9	0.05 / 0.04	90.0
Qwen 3.8 27B Q5Hyb	0.05	100%	59.7	1.98x	30.2	0.00 / 0.00	70.4
Huihui 3.6 27B Q5Hyb	0.00	93%	65.2	2.12x	30.7	0.02 / 0.02	90.0
Uncensored 3.8 27B Q5Hyb	0.05	93%	59.4	1.94x	30.7	0.00 / 0.00	47.9

读法：拒答率 huihui 全量微调去对齐最彻底（0.0），官方版 0.05-0.15；τ² 成功率 3.8 家族两兄弟 100%、其余 93%；MTP 加速 全部 1.66-2.12x；幻觉率 3.8 家族（0.00-0.04）普遍低于 3.6（0.02-0.05）；irrelevance 拒判 3.6 家族 90 明显强于 3.8（70-75），去审查版 Uncensored 掉到 47.9——这正是结论 3 判断"3.6 工具调用更强"的原始依据。

五、结论

开源已追平 2024 闭源第一梯队：大尺寸档冠军 Qwen3.6 35B MoE（93.4 分）全面越过 GPT-4o 基线，前十名大模型全部在能力面上贴住或超过 GPT-4o。
MoE 是当前甜点架构：总榜前十中 MoE 占四席（Qwen3.6 35B、Nemotron、GPT-OSS、Gemma4 26B），且速度普遍 90-130 t/s，比同档稠密模型快 3-4 倍。
工具调用的主力推荐：Qwen 3.6 27B（首选 Q5Hyb，其次官方 Q4_K_M）——27B 这个量级能力均衡没有短板：六维 88.9-90.5、BFCL 工具调用 88.3-89.4（27B 档全员 85+，非常强）、ToolBench 域内 0.79-0.82、拒答率克制（官方 0.15）、还有 MTP 1.7-2.1x 加速可用。更关键的判断是：在 27B 档，Qwen 3.8 并没有比 3.6 强太多——六维 90.0 vs 90.5、MMLU 70.0 vs 73.3 基本持平，而 3.6 在最要紧的工具调用上明显领先（BFCL 88.3-89.4 vs 85.1-86.8，irrelevance 拒判 90 vs 70-75），甚至超过 GPT-4o 的单轮工具调用（87.4，v3 榜口径，版本不同仅供参考）。换代收益有限，选能力更全面、工具调用更强的 3.6，才是单卡日常主力的正解。
按量级选型：轻任务/翻译/路由 Qwen3 0.6B（250 t/s）；中量级性价比 Gemma4 E4B（83 分+115 t/s）；旗舰总分 Qwen3.6 35B MoE（93.4 分）；均衡主力 Qwen 3.6 Q5Hyb（见结论 3）；要极致速度的大模型选 Nemotron（129 t/s）。
速度与能力要做好取舍：大尺寸 MoE 已经同时给出 90+ 分和 100+ t/s，真正的取舍只存在于"极致速度（小模型 250 t/s+）"和"极致能力（93+ 分）"之间。

Qwen3.6 vs Qwen3.8：27B 量化与去审查版本能力全对比，以及本地模型能不能替代 GPT-3.5

2026-08-19T16:00:00+08:00

现在总有人说，本地部署模型可能越来越没必要了——在线模型那么便宜，调用一次没几个钱，何必自己折腾硬件。之前这话大体没错，但最近情况有点变化：有的在线模型突然涨价了。价格一涨，成本优势打了折扣，本地部署这事就又被拿出来讨论。

而且现在的本地模型确实不是当年的水平了。今天能在自己机器上跑起来的开源模型，能力上可能已经超过了前些年令人非常惊艳的那些模型——当年的 GPT-3.5 刚出来的时候多轰动啊。所以这篇就把当年的 GPT-3.5、Qwen3.6 和最新的 Qwen3.8 拉到一起比一比。

顺便也想澄清一个误区：不是最新的模型在所有场景下都比旧模型强。就拿工具调用来说，默认模板下 3.6 有时候的表现反而比 3.8 要好一些。版本号不见得就决定一切。

先声明：这篇里所有的数据，都只是在我个人的设备的 7900xtx 24G 上跑出来的结果。环境是个例，样本量也小，不具有太多的参考意义，更不能代表模型的官方或普遍水平。

之前写过 Qwen3.8-27B 从 f16 到 IQ1_S 的量化阶梯，那篇说的是部署和速度。这篇只聊能力：把手头 3.6 和 3.8 两代 27B 的各种量化版、去审查版拉出来，用 BFCL V4 工具调用和六个经典基准统一测一遍，再看看本地模型替代在线 API 这事到底靠不靠谱。

先说结论：

单轮工具调用，默认模板下 3.6 反而比 3.8 强。3.6 官方 Q5hyb 拿到 89.44%，是全场最高，比 3.8 最好的配置高出 2.6 分以上。
两个家族都全面追平或超过 GPT-3.5。七个维度没有一个落后的，HumanEval 甚至是 100 对 48.1。
去审查不是免费的。3.6 的去审查版几乎无损（-0.21），3.8 的去审查版在"该不该调用工具"的判断上直接崩到 47.92%。
多轮工具调用两个都不太理想，复杂的智能体流程费劲了，当然可能主要是显存有限，上下文没给够。

一、测了什么，怎么测的

环境还是那套：llama.cpp 走 Vulkan，AMD 7900XTX 24G 主力。推理参数 --temp 0，关闭思维链，保证结果可复现。这篇不谈速度，速度的事在量化阶梯那篇里已经说过了。

受测的六个主力配置：

配置	体积	说明
3.6 官方 Q4_K_M	17.0GB	官方权重常规量化
3.6 官方 Q5hyb	19.4GB	Q6/Q5 主体 + Q8_0 注意力 + Q8_0 MTP 的定制混合量化
3.6 去审查 Q5hyb	19.4GB	huihui 微调 / Heretic 消融
3.8 官方 Q4_K_M	16.8GB	官方权重常规量化
3.8 官方 Q5hyb	20.6GB	同上定制混合量化
3.8 去审查 Q5hyb	19.4GB	huihui 微调 / Heretic 消融

Q5hyb 是个什么东西

表格里反复出现 Q5hyb，值得单独说一下。这是我自己做的一个定制混合量化，名字就是 Q5 级混合（hybrid）的缩写。

出发点很简单：Q4_K_M 够小，但质量上总觉得还能再往上够一档；可直接上 Q6_K、Q8_0 又太大——27B 的模型，Q8_0 要 27 GiB，24G 卡物理上装不下，Q6_K 也有 20.9 GiB，塞进去之后留给 KV cache 和上下文的空间就很紧了。那就别一刀切：不同的张量对精度的敏感度本来就不一样，分开给。

设计思路一句话：好钢用在刀刃上。

注意力部分保 Q8_0。注意力是整个模型里对精度最敏感的部分，Q/K/V 投影有点误差，模型"看到"的东西就变了，这块不能省。
MTP 层也保 Q8_0。这层体积很小，但它是投机解码的草稿层，草稿质量直接决定接受率，也就是决定提速效果。保 Q8，质量速度两头都不亏。
主干 FFN 用 Q6/Q5 混合。FFN 占的参数量最大，但对精度相对宽容，往下压一档，体积省得最明显。

做法跟之前那篇里的 Q8SLIM 是同一个路子：llama-quantize 的 --tensor-type 参数可以按张量名分别指定量化类型。

出来的效果：3.8 的 Q5hyb 20.6GB，单张 24G 卡装下之后还有富余；3.6 的 Q5hyb 在这次测试里是全场总分第一的配置（BFCL 89.44%，MMLU、WinoGrande 也是第一）。

测试分两块：

一块是 BFCL V4，专门测工具调用（function calling）的，这是现在本地模型最被看重的能力之一。测了 Non-Live AST 七类、Live 真实 API、Multi-turn 多轮三部分。

另一块是六个经典基准：MMLU（知识）、HumanEval（代码）、GSM8K（数学）、HellaSwag（常识）、ARC（科学推理）、WinoGrande（语义），每个采样 30 题，题面和评分复用之前的评测框架。

GPT-3.5 的成绩全部来自公开文献：前六维取 GPT-4 Technical Report 的 Table 2（OpenAI 自己公布的），BFCL 取 ToolN1 ICLR'26 论文里 BFCL V4 2025-04-13 快照的数据。

二、BFCL V4：3.6 全面压过 3.8

2.1 Non-Live AST 总览

模型	Non-Live AST	vs GPT-3.5
3.6 官方 Q5hyb	89.44%	+11.4
3.6 去审查 Q5hyb	89.23%	+11.2
3.6 官方 Q4_K_M	88.27%	+10.3
3.8 去审查 Q5hyb	86.81%	+8.8
3.8 官方 Q4_K_M	86.00%	+8.0
3.8 官方 Q5hyb	85.08%	+7.1

参照线：GPT-3.5-Turbo-0125 的 BFCL V4 Non-Live Overall 约 78.0%。也就是说，这六个本地量化版里最"差"的一个，也比 GPT-3.5 高 7 个点。再提醒一句：这只是我个人设备上跑出来的结果，不具有太多参考意义。

2.2 拆开看：输在哪，赢在哪

总分只是一个数，拆开按类别看才有意思：

类别	3.6 家族	3.8 家族	谁赢
simple_python	95.75~96.25	96.25~97.0	3.8 略胜
simple_java	63~65	65~66	半斤八两
simple_javascript	74~76	70~78	半斤八两
multiple（多函数选一）	94.0~95.0	96.5	3.8
parallel（并行调用）	90.5~92.0	81.0~90.5	3.6
parallel_multiple	91.0~92.5	79.0~84.0	3.6 明显
irrelevance（识别无可用函数）	90.0（全员）	70.4~76.7	3.6 明显

规律很清楚：单次调用、从一堆函数里挑一个这种"简单活"，3.8 做得稍好；一旦要一次并行调多个函数，或者要判断"这个请求根本没有合适的函数、应该拒绝调用"，3.6 的优势就出来了，parallel_multiple 上差了将近 10 个点。

irrelevance 这一项值得单独说。它测的是模型会不会"没活硬干"——给一个和所有函数都不沾边的请求，看模型是老实说没有合适工具，还是硬编一个调用出来。3.6 所有版本都稳在 90%，3.8 官方版本只有 70 出头。这个能力在真实 agent 场景里很要命：工具列表一大，模型要是见什么都想调，整个流程就会被幻觉调用带偏。

2.3 Live 与 Multi-turn

Live（真实 API 子集）只有 Q4 系列跑了完整数据：

模型	Live Overall
3.6 官方 Q4_K_M	82.16%
3.8 Q4_K_REC v22	82.16%
3.8 官方 Q4_K_M	81.72%
3.8 Q4_K_REC	80.98%

Live 上两家基本打平，差不到半个点。顺带一提，3.8 还有两个 Q4_K_REC 变体配置也跑了，成绩都在 80.98~82.16 这个区间里，和官方 Q4_K_M 没有本质区别。

Multi-turn 就没什么好说的了，全员拉胯：

模型	Multi-turn Overall	Base 子项
3.6 官方 Q4_K_M	18.50%	74.0%
3.8 官方 Q4_K_M	17.25%	69.0%
3.8 Q4_K_REC	16.25%	65.0%

多轮工具调用要求模型在状态不断变化、函数缺失、参数缺失的情况下持续做正确决策，18% 这种成绩说明两代模型离"可靠的 agent 大脑"都还有距离。这点后面讨论替代在线模型时还要提。

三、七维能力雷达 vs GPT-3.5

六个基准加 BFCL，凑七个维度：

模型	MMLU	HumanEval	GSM8K	HellaSwag	ARC	WinoGrande	BFCL
3.6 官方 Q4_K_M	70.0	100.0	100.0	86.7	93.3	83.3	88.3
3.6 官方 Q5hyb	73.3	100.0	100.0	90.0	93.3	86.7	89.4
3.6 去审查 Q5hyb	70.0	100.0	100.0	93.3	93.3	80.0	89.2
3.8 官方 Q4_K_M	66.7	100.0	96.7	93.3	100.0	83.3	86.0
3.8 官方 Q5hyb	70.0	100.0	96.7	90.0	100.0	83.3	85.1
3.8 去审查 Q5hyb	66.7	100.0	93.3	86.7	100.0	83.3	86.8
GPT-3.5-Turbo	70.0	48.1	57.1	85.5	85.2	81.6	78.0

几个要点：

全部六个量化版在七个维度上没有一个低于 GPT-3.5 的。差距最大的是 HumanEval，100 对 48.1——当然这里要说明，30 题的 HumanEval 子集全对，和官方 164 题全量不是一回事，但起码说明代码生成这块，本地 27B 量化版完全不虚三年前的 GPT-3.5。GSM8K 同理，93.3~100 对 57.1。

最接近的是 MMLU，66.7~73.3 对 70.0，基本持平。知识面这种东西跟参数规模和训练数据强相关，追平就是追平，没什么可吹的，也没输。

3.6 官方 Q5hyb 是全场唯一在多数维度领先的配置，MMLU、WinoGrande、BFCL 三项第一。3.8 家族则在 ARC 上全员满分。

由于时间有限，所以每维只有 30 题，统计方差大约 ±9%，维度之间 5 分以内的差异不具备显著性。HumanEval 和 GSM8K 又都摸到了满分天花板，区分度为零。所以这张雷达图能说明"追平并超过 GPT-3.5"这个定性结论，但应该是不能拿小数点做严格比较。而且这一切都只是在我个人的设备上、用我这套环境跑出来的，换个环境未必是这个样子，参考意义有限。

四、3.6 对 3.8：同门对决

把两代模型的差异单独拎出来：

3.6 赢的地方：

BFCL Non-Live 总分，89.44 对 85.08~86.81，全场前三被 3.6 家族包揽。
并行调用（parallel、parallel_multiple），这是真实工作流里最常见的模式。
irrelevance 检测，90 对 70 出头，质的差距。
WinoGrande 和 MMLU（Q5hyb 配置下）。

3.8 赢的地方：

multiple 单选，96.5 对 94~95。
simple_python / simple_java 单函数调用，略高。
ARC 满分对 93.3。

量化敏感度的方向也不一样：3.6 是 Q5hyb 比 Q4_K_M 好（89.44 对 88.27），3.8 反而 Q4_K_M 比 Q5hyb 略好（86.00 对 85.08）。这个反向差异在 ±9% 的样本方差里未必站得住，但至少说明两代模型对量化方式的响应不一样，不能拿着一代的经验直接套另一代。

总的判断：这次测试用的是默认模板。在默认模板下，如果你的主要用途是工具调用、agent 类任务，3.6 有时候的表现反而比最新的 3.8 要好，而且不是险胜；3.8 的优势集中在单函数调用和科学推理这种单点能力上。所以别迷信版本号，不是最新的模型在所有场景下都比旧模型强——这代 3.8 在 BFCL 上就是实打实的退步。当然，这也只是我个人设备上的结果，仅供参考。

五、去审查的代价：两家完全不一样

去审查（去对齐）版本是本地社区的特色需求。这次测的两个去审查版，走的是 huihui 微调和 Heretic 消融的路子。结果非常有意思：

3.6 去审查版：BFCL 89.23，比官方版 89.44 只低 0.21，irrelevance 检测保持 90%，七个基准维度的波动全在方差范围内。可以说能力基本无损。

3.8 去审查版：BFCL 总分 86.81，看着甚至比官方 Q5hyb 的 85.08 还高一点，但拆开看就露馅了——irrelevance 检测从 70 多直接掉到 47.92%，腰斩都不止。也就是说，去审查之后的 3.8 变得"特别乐于助人"：不管请求跟工具沾不沾边，都倾向于调用一个函数试试。multiple、parallel 这些类别它甚至还略有提升，但"该拒绝时拒绝"的能力基本丢了。

这个对比说明一件事：去审查对能力的影响不是个固定的"损耗百分比"，它取决于对齐微调动的是哪块。3.6 的去对齐做得干净，3.8 的去对齐把工具调用的边界感也一起消融掉了。选去审查版本之前，最好先想清楚自己要的是什么——如果是拿来跑 agent，一个不会拒绝的模型可能比一个偶尔拒绝的模型更危险。

六、本地模型能不能替代在线模型

这是绕不开的问题。先限定讨论范围：这里的"在线模型"参照是 GPT-3.5-Turbo，也就是 2023 年初的水平，很多 API 场景至今还在用的那个档次。

从这次的数据看，替代是成立的：

七个能力维度全部追平或超过，工具调用超出 7~11 个点。对于"调 API 做单轮任务"这类需求——翻译、抽取、格式转换、单函数工具调用——本地 27B 量化版给出的质量不低于 GPT-3.5 档次的在线服务，而且数据不出本地、零调用成本、断网也能跑。数据敏感的场景里，这本身就是决定性的优势。

但有三条边界要说清楚：

第一，GPT-3.5 是个三年前的靶子。赢了它也远不能比现在的旗舰在线模型，都不用说那些闭源的，就连开源的GLM5.3、DeepSeek V4 等等更大规模参数的开源在线模型的推理和长文本能力，本地这种 27B 的小模型也还差得远。

第二，多轮是硬伤。Multi-turn 18% 的成绩意味着"模型自己规划、连续多轮调工具、处理异常"这种复杂 agent 流程，我这台设备上用当前的参数恐怕目前撑不起来。这类任务要么继续用在线旗舰模型，要么自己在框架层做大量兜底。

第三，样本量的限制。30 题的基准只能给出定性结论，真要下"全面替代"的判断，得上全量测试。这篇的结论是"能力上够格"，不是"统计上严格证明"。

第四，也是最根本的一条：以上所有数字都只是在我个人的设备上跑出来的，不具有太多参考意义。替代成立与否，最终要在你自己的环境里验证。

不过，总体来看，本地模型好歹也达到替代 GPT-3.5 的能力了。

七、总结一下

工具调用选 3.6，官方 Q5hyb 是全场最佳配置，89.44%。
3.8 在单函数调用和 ARC 上有优势，但 BFCL 总分对 3.6 是退步。
对 GPT-3.5：七维全胜或持平，本地替代在单轮任务上成立。
去审查：3.6 几乎无损，3.8 的 irrelevance 检测崩到 47.92%，选之前想清楚。

最后再强调一遍：以上所有数据都只是在我个人的设备上跑出来的结果，不具有太多参考意义，看个思路就好。

2026年的本地小模型 vs 2023年的GPT-3.5：6个基准60题的全面对比

2026-08-19T10:00:00+08:00

总有人说本地模型没意义。这种考量如果只从自己的需求出发，可能过于武断，甚至有些自大。不同的人、不同的场景，有不同的模型需求。以翻译和转换为例，速度有的时候不是第一要务，而可靠性和从知识库检索后转换翻译的质量可能更重要。在数据敏感的场景下，本地模型虽然速度不一定最快，但能保证数据不出本地，这本身就是很大的价值。有本地搭建需求的场景，也不应该被轻易否定。

所以作为理性的人，不能轻易否定其他人的选择和需求，不能无端地说速度或者参数规模要超过某个数值以上的才有用、低于某个数值就不能用。甚至上下文范围也不能说一定得大于某个值才行——有的工具调用不需要特别大的上下文，反而需要比较靠谱的工具调用能力对代码进行优化；有的模型就是为此而生的。

一个开阔豁达的人，不要为了自己赢或者秀优越而去争论什么，那样很不体面。

之前关于速度的部分已经在别的文章里提到过，这篇就不说速度，只关注一件事：现在这些在本地处理器上就能运行的小模型，和当年的 GPT-3.5 相比，能不能达到那个表现。

评测基准

选了有代表性的 6 个基准，覆盖知识、代码、数学、推理四个维度。GPT-3.5 的成绩来自 GPT-4 技术报告 Table 2（arXiv:2303.08774），是 OpenAI 自己公布的。

基准	维度	GPT-3.5 成绩	测试方式
MMLU	多任务知识	70.0%	5-shot
HumanEval	代码生成	48.1%	pass@1, 0-shot
GSM8K	小学数学	57.1%	5-shot
HellaSwag	常识推理	85.5%	10-shot
ARC	科学推理	85.2%	25-shot
WinoGrande	语义推理	81.6%	5-shot

数据集都是公开的：MMLU 来自 HuggingFace（14042 题），HumanEval 来自 GitHub openai/human-eval（164 题），GSM8K 来自 GitHub openai/grade-school-math（1319 题），HellaSwag 来自 GitHub rowanz/hellaswag（10042 题），ARC 来自 HuggingFace allenai/ai2_arc（1119 题），WinoGrande 来自 HuggingFace allenai/winogrande（40398 题）。

受测模型

模型	大小	说明
qwen3.5:9b	8.9 GB	本次实验中最大的本地模型
carstenuhlig/omnicoder-2-9b	5.7 GB	代码专用模型
qwen3.5:0.8b	1.2 GB	1GB 级别通用模型
lfm2.5-thinking:latest	697 MB	带思维链的混合架构
granite4:350m-h	349 MB	IBM 混合架构，1M 上下文
LiquidAI/lfm2.5-350m	379 MB	Spark Arena 速度榜首

拉取命令：

ollama pull qwen3.5:9b
ollama pull carstenuhlig/omnicoder-2-9b
ollama pull qwen3.5:0.8b
ollama pull lfm2.5-thinking:latest
ollama pull granite4:350m-h
ollama pull LiquidAI/lfm2.5-350m

评测方法

每个基准从完整数据集中均匀采样 60 题。为什么不用全量？因为时间有限，而且也没那个必要——60 道题足够有代表性了。采样时按学科或类别均匀分布，避免偏科。所有模型用同样的 60 道题，temperature=0，确保结果可比。

每道题的模型原始回答完整存储下来，然后离线评分。评分时先清理思维链前缀（有些模型会先输出一大段思考过程再给答案），再从清理后的文本中用多种策略提取答案——先找结构化标记，再找关键词模式，最后从文本末尾回溯。这样不会因为某个模型的输出格式特殊就丢分。

结果

模型	大小	MMLU	HumanEval	GSM8K	HellaSwag	ARC	WinoGrande	平均比值
GPT-3.5	—	70.0%	48.1%	57.1%	85.5%	85.2%	81.6%	100%
qwen3.5:9b	8.9 GB	63.2% (90%)	55.0% (114%)	91.7% (161%)	76.7% (90%)	86.7% (102%)	91.7% (112%)	95%
omnicoder-2-9b	5.7 GB	19.3% (28%)	90.0% (187%)	70.0% (123%)	28.3% (33%)	26.7% (31%)	46.7% (57%)	76%
granite4:350m-h	349 MB	42.1% (60%)	60.0% (125%)	21.7% (38%)	28.3% (33%)	21.7% (25%)	56.7% (69%)	58%
qwen3.5:0.8b	1.2 GB	15.8% (23%)	43.3% (90%)	56.7% (99%)	30.0% (35%)	60.0% (70%)	40.0% (49%)	51%
lfm2.5-thinking	697 MB	31.6% (45%)	25.0% (52%)	41.7% (73%)	30.0% (35%)	15.0% (18%)	40.0% (49%)	45%
lfm2.5-350m	379 MB	28.1% (40%)	13.3% (28%)	10.0% (18%)	26.7% (31%)	48.3% (57%)	38.3% (47%)	37%

括号内为相对 GPT-3.5 的能力比值。平均比值为六维度比值的算术平均。

各模型表现

qwen3.5:9b — 已全面追平 GPT-3.5（平均 95%）

四个维度超过 GPT-3.5：GSM8K 91.7% vs 57.1%，HumanEval 55.0% vs 48.1%，ARC 86.7% vs 85.2%，WinoGrande 91.7% vs 81.6%。MMLU 63.2% 略低于 70.0%，HellaSwag 76.7% 略低于 85.5%。如果 2023 年 GPT-3.5 是标杆，那这个模型在 2026 年已经把它追平了，而且是本地免费跑。

omnicoder-2-9b — 代码和数学暴打 GPT-3.5，通用知识几乎为零（平均 76%）

HumanEval 90.0% 对 GPT-3.5 的 48.1% 是 187%，GSM8K 70.0% 对 57.1% 是 123%。但 MMLU 只有 19.3%，HellaSwag 28.3%，ARC 26.7%——典型的代码专用模型，非代码任务能力塌方。拿它写代码很好，拿它做选择题就别指望了。

granite4:350m-h — 349MB 做到 GPT-3.5 的 58%（平均）

HumanEval 60.0% 超过 GPT-3.5 的 48.1%，WinoGrande 56.7% 达到 69%。但数学只有 21.7%，常识推理 28.3%。体积小、速度快、代码能力突出，适合边缘部署。

qwen3.5:0.8b — 1GB 级别最均衡（平均 51%）

GSM8K 56.7% 几乎追平 GPT-3.5 的 57.1%，ARC 60.0% 达到 70%，HumanEval 43.3% 达到 90%。MMLU 偏低（15.8%），但其他维度都在 GPT-3.5 的一半以上。1GB 以内的模型里它最接近 GPT-3.5。

lfm2.5-thinking — 思维链在数学上有用，但拖累代码（平均 45%）

GSM8K 41.7% 是几个小模型里相对较好的，思维链确实帮助了数学推理。但 HumanEval 只有 25.0%——思维链输出太长，干扰了代码补全。

lfm2.5-350m — 最轻量但能力有限（平均 37%）

379MB 体积最小，能力也最低。GSM8K 只有 10.0%，HumanEval 13.3%。不过 ARC 48.3% 达到了 GPT-3.5 的 57%。

关键发现

体积差 25 倍，能力差不到 2 倍。 以 GPT-3.5 位参考，granite4:350m-h（349MB）平均 58%，qwen3.5:9b（8.9GB）平均 95%。体积差了 25 倍，能力差不到 2 倍。小模型的性价比远超直觉。

代码能力超越 GPT-3.5 的门槛最低。 granite4:350m-h 的 HumanEval 60% 就超过了 GPT-3.5 的 48.1%。一个 349MB 的模型在代码生成上赢了当初震惊世界的 GPT-3.5。代码生成是这些小模型最容易"以小博大"的维度——可能是因为代码训练数据质量高、模式重复性强，而且当年的 GPT-3.5 可能代码能力也还没有太擅长。

数学能力两极分化。 qwen3.5:9b 的 GSM8K 91.7% 远超 GPT-3.5，但 lfm2.5-350m 只有 10.0%。数学推理对模型参数量的要求看来是比代码更高——小模型要么懂、要么完全不懂，中间地带很窄。

通用知识（MMLU）是最难追平的维度。 除了 qwen3.5:9b（63.2%），其他模型都在 42% 以下。MMLU 覆盖 57 个学科，需要广泛的知识储备，这是小模型的天然短板——参数量小意味着能记住的东西可能确实是少了很多了。

专用模型的偏科现象最极端。 omnicoder 的代码 187%、数学 123%，但 MMLU 28%、HellaSwag 33%。专用模型在训练时牺牲了通用能力来强化特定领域，使用时必须清楚它的边界。

总结一下

不同方向、不同领域上，这几个模型各有各的表现。有的虽然模型体积小，但已经达到 GPT-3.5 的很大比例了，非常优秀，只不过速度稍微慢一点；有的虽然速度快，但准确率有差距。各有各的合适场景，设计好自己的需求再选型就好了。

越是四处去炫耀自己厉害的，恐怕往往越未必有那么厉害。

现在看不上本地模型的人，当年或许也曾经为GPT-3.5而赞叹过。

Qwen3.8:27B 本地部署：从 52G 的 f16 到 7G 的 IQ1_S阶梯量化实测，AMD的7900XTX 24G和 NVIDIA的4070 8G都跑一遍

2026-08-15T15:00:00+08:00

先说结论：

24G 卡追求质量：Q8SLIM，22.3 GiB 全进显存，29 tok/s，这是 7900XTX 上能摸到的最高参数规格。
24G 卡追求速度：IQ4_XS，39.6 tok/s，质量验证全过，日常用体感和 Q4_K_M 没区别。
质量底线：IQ2_XXS（8.1 GiB），再往下 IQ1_S 数学就崩了。
8G 卡：27B 纯属超纲，IQ1_S 能跑但别指望质量，真想跑 27B 老老实实上 16G 以上显存。
MTP 必开：特别是部分卸载场景，65% 的提速不要白不要。

现在开源模型更新得太快了，前脚刚把一个 27B 玩明白，后脚新版又出来了。这回看上的是 ModelScope 上面的 Qwen3.8-27B。这个模型有点意思：它是多模态架构，官方标识的 model_type 是 qwen3_5，内部结构是 linear_attention 和 full_attention 交替混搭的，一共 64 层主干，外带一层 MTP（Multi-Token Prediction，多 token 预测）。而且它原生就带了 MTP 权重，这对后面提速很关键，咱后面细说。

手头两块卡：一块 AMD 7900XTX，24G 显存；一块 NVIDIA RTX 4070，8G 显存。这回就把这个模型从 f16 一路量化到 IQ1_S，十三个版本全做出来，每个都验证 MTP 层还在不在，大于 8G 的挨个在 7900XTX 上跑，小于 8G 的丢给 4070，速度和答案正确性都验一遍。下面把整个流程和坑都摊开讲讲。

一、先把模型弄下来

模型地址是 https://modelscope.cn/models/Qwen/Qwen3.8-27B，下载直接走 ModelScope 是最省事的，用它的 SDK 就行。这里我下载的路径在 C:/Users/frede/models/Qwen3.8-27B，后面代码示范都是这个目录。

from modelscope import snapshot_download
snapshot_download('Qwen/Qwen3.8-27B', local_dir='C:/Users/frede/models/Qwen3.8-27B')

原始权重是 18 个 safetensors 分片，总共 52G 左右，下了差不多四个小时。这里提醒一句，网络不稳的话别用多线程下载器硬抢，单线程流式反而稳，断了能接着续。

二、转成 GGUF

llama.cpp 的转换脚本直接用：

python convert_hf_to_gguf.py C:/Users/frede/models/Qwen3.8-27B --outtype f16 --outfile Qwen3.8-27B-f16.gguf

出来一个 50.9 GiB 的 f16 GGUF，866 个张量。这里有个值得注意的点：转换完之后我专门检查了一下张量列表，发现 blk.64.nextn.* 这一组的四个张量都在——这就是 MTP 层，第 65 层（编号 64）专门用来预测未来 token 的。转换脚本没有把它扔掉，这意味着后面所有量化版本理论上都能保留投机解码的能力。

三、量化阶梯：一口气做十三个

量化用 llama-quantize，普通 K 系量化（Q8_0、Q6_K、Q5_K_M、Q4_K_M、Q3_K_M）直接从 f16 转就行。但 IQ 系列（IQ4_XS、IQ3_XS、IQ2_M、IQ2_XS、IQ2_XXS、IQ1_S）不一样，它们是重要性矩阵量化，必须先算 imatrix。

算 imatrix 得有校准语料。我把自己博客上三百七十篇文章拼在一起，凑了 2MB 的 calib.txt，肥水不流外人田，用自己的语料校准自己的模型，语义分布也对付了。这里参考意义就不大了，大家到时候自行探索。

# 先用 Q5_K_M 跑 imatrix（256 个 chunk）
llama-imatrix -m Qwen3.8-27B-Q5_K_M.gguf -f calib.txt -o imatrix.gguf -ngl 15 -c 512 -b 256 --chunks 256

# 带 imatrix 的量化
llama-quantize --imatrix imatrix.gguf Qwen3.8-27B-f16.gguf Qwen3.8-27B-IQ4_XS.gguf IQ4_XS

最后做出来的完整阶梯长这样（全部验证过包含 MTP 层）：

量化版本	体积	说明
f16	50.9 GiB	源文件
Q8_0	27.0 GiB	8.50 BPW，超过 24G 显存
Q8SLIM	22.3 GiB	混合量化，见下文
Q6_K	20.9 GiB
Q5_K_M	18.2 GiB	5.72 BPW
Q4_K_M	15.7 GiB	4.92 BPW
IQ4_XS	14.3 GiB	imatrix
Q3_K_M	12.6 GiB	3.95 BPW
IQ3_XS	11.4 GiB	imatrix
IQ2_M	9.5 GiB	imatrix
IQ2_XS	8.7 GiB	imatrix
IQ2_XXS	8.1 GiB	imatrix
IQ1_S	6.9 GiB	imatrix

IQ1/IQ2 的一个坑

第一次做 IQ2 和 IQ1 的时候直接报错退出，提示缺少重要性矩阵。查了半天才发现根因：算 imatrix 的时候模型是普通模式跑的，MTP 那层（blk.64）根本没被执行过，所以 imatrix 里没有它的数据。而 IQ1、IQ2 这种极低比特量化是强制要求每个张量都有重要性数据的，没有就罢工。

解法很简单，把 blk.64 单独指成 Q4_K，K 系量化不需要 imatrix：

llama-quantize --imatrix imatrix.gguf --tensor-type "blk.64=Q4_K" f16.gguf out-IQ1_S.gguf IQ1_S

这样 MTP 层用 Q4_K 保真，主干用 IQ1_S 压缩，两不耽误。

四、Q8 塞不进 24G 怎么办：Q8SLIM

周总跟我说 Q8_0 在 7900XTX 上跑没问题。但我自己转换的纯 Q8_0 是 27 GiB，24G 的卡物理上就装不下。之前试过各种层拆分（-ngl 62、54、52）全都 Vulkan DeviceLost，只有 -ngl 50 勉强稳定但只剩 2.5 tok/s，没啥实用价值。

所以我选择的做法是混合量化：注意力部分保 Q8_0，FFN 降到 Q6_K，词表嵌入压到 Q4_K，输出层给 Q6_K：

llama-quantize --token-embedding-type Q4_K --output-tensor-type Q6_K \
  --tensor-type "ffn_=Q6_K" f16.gguf Q8SLIM.gguf Q8_0

出来 22.3 GiB（6.99 BPW），整卡装下还有富余。质量上注意力这种对精度最敏感的部分还是 Q8，FFN 这些大块头降一档，体感损失很小。实测 29.1 tok/s，两道验证题全对。这大概就是我这张 7900XTX 24G 卡上能跑的最高质量档。

五、7900XTX 大阅兵

10 个超过 8G 的版本挨个上，Ollama 走 ROCm 后端，但怕爆显存就只设置了 8k 上下文，temperature 0，每档跑两道固定题：一道数学（17×23），一道代码（写斐波那契函数）。

模型	速度	数学	代码
Q8SLIM	29.1 tok/s	对	对
Q6_K	29.4 tok/s	对	对
Q5_K_M	30.9 tok/s	对	对
Q4_K_M	32.8 tok/s	对	对
IQ4_XS	39.6 tok/s	对	对
Q3_K_M	32.9 tok/s	对	对
IQ3_XS	31.1 tok/s	对	对
IQ2_M	32.0 tok/s	对	对
IQ2_XS	32.2 tok/s	对	对
IQ2_XXS	32.6 tok/s	对	对

几个观察：

IQ4_XS 是速度之王，39.6 tok/s 一骑绝尘，比 Q4_K_M 快了 20%。原因不复杂：IQ4_XS 是 4 BPW 出头，比 Q4_K_M 的 4.92 BPW 小了 1.4G，全部塞进显存之后剩余空间更宽裕，而且 IQ 系列的内存访问模式在显存带宽吃紧的时候更有优势。
Q8SLIM 和 Q6_K 这两个大块头反而最慢（29 出头），大概是因为太大，显存基本塞满了，KV cache 的空间也吃紧。
IQ2_XXS 居然还能全对，8.1 GiB 的 27B 模型，质量崩塌的临界点比想象中低。
中间有个小插曲：Q6_K 第一次测出来只有 1.3 tok/s，吓一跳。后来发现是前一个测试的模型没卸载干净，显存被占了一半。清掉重测就是正常的 29.4。跑批量测试的时候，每个模型测完记得 keep_alive=0 卸载，不然数据全是坑。

六、4070 接力：IQ1_S 和质量底线

小于 8G 的只有 IQ1_S（6.9 GiB），扔给 4070。8G 显存里有 1G 多被桌面占着，实际可用 6.8G 左右，无奈，只能用 -ngl 55 把大部分层放上去，剩下留 CPU：

测试	速度	数学
IQ1_S 基线	5.4 tok/s	错（340+51 算成 370）
IQ1_S + MTP	6.5 tok/s	错（同基线）
Q5_K_M -ngl 15	1.9 tok/s	对
Q5_K_M -ngl 15 + MTP	3.2 tok/s	对

IQ1_S 就是质量断崖。1.68 BPW 的比特率，27B 模型的数学能力直接崩了，340 加 51 能给你写成 370。所以说这代的可用底线是 IQ2_XXS，IQ1 系列只能算"能出字"，不能算"能用"。

顺带一提，Q5_K_M 在 8G 卡上属于超载运行，18G 的模型只塞进去 15 层，剩下全靠内存和 CPU，1.9 tok/s 咬牙能用。这卡跑 27B 本来就是超纲题。

七、MTP 投机解码：白捡的加速

这个模型原生带 MTP 层，llama.cpp 用 --spec-type draft-mtp 就能启用。原理粗略来讲：普通自回归是猜一个 token 验证一个，MTP 相当于模型自带一个小抄，一次猜好几个，主模型批量验证，猜中的直接收下，猜错的回滚。猜中率越高，加速越明显。

实测数据：

IQ1_S（4070）：5.4 → 6.5 tok/s，提速 20%
Q5_K_M（4070，部分卸载）：1.9 → 3.2 tok/s，提速 65%

部分卸载场景提速更显著，可能是因为瓶颈在 CPU 内存带宽，一次验证多个 token 等于把宝贵的带宽利用率拉满了。而且开了 MTP 之后输出和基线完全一致——这是投机解码的数学性质保证的，猜错会回滚，最终结果和逐 token 生成一模一样，纯粹是白捡的速度。

温度为 0 的时候接受率最稳。温度拉高之后输出随机性变大，草稿和主模型容易对不上，加速效果会打折扣，这个要有心理预期。

八、这一路踩的坑

官方 Windows 二进制好像是有 bug。llama.cpp b10405 和 b10435 的官方 Windows release，在回调路径（cb_eval）上有堆损坏，llama-imatrix 跑任何模型任何后端都会在第一个 decode 静默崩掉，exit code 0xC0000374；开 draft-mtp 的 llama-cli 也崩。解决办法是自己编译：本机 VS18 Community 加 CMake，注意必须用 Ninja 生成器，VS 自带生成器会报 "No CUDA toolset found"。自建的版本一切正常。
链式量化别接管道。第一次批量量化的时候，输出接了 grep | head，管道提前关闭触发 SIGPIPE，把 IQ3_XS 的文件头截断了，GGUF magic 都没了。量化这种长任务老老实实写日志文件，我整不明白就暂时先不接管道了。
Vulkan 崩了可能是驱动问题但也别慌。AMD 的 Vulkan 后端偶发 DeviceLost，恢复套路是固定的：taskkill 杀光所有 llama 进程，等 10 秒再启动，基本就能活过来。
llama-cli 单轮测试用 -st。不带这个参数它会进对话模式，后台跑的时候没人交互，就死循环打印提示符，日志能给你写几百兆。另外后台跑一定要 > /dev/null。

九、简单总结

24G 卡追求质量：Q8SLIM，22.3 GiB 全进显存，29 tok/s，这是 7900XTX 上能摸到的最高画质。
24G 卡追求速度：IQ4_XS，39.6 tok/s，质量验证全过，日常用体感和 Q4_K_M 没区别。
质量底线：IQ2_XXS（8.1 GiB），再往下 IQ1_S 数学就崩了。
8G 卡：27B 纯属超纲，IQ1_S 能跑但别指望质量，真想跑 27B 老老实实上 16G 以上显存。
MTP 必开：特别是部分卸载场景，65% 的提速不要白不要。

一轮折腾下来，本地盘上躺了 268 GiB 的模型文件。可能觉得折腾这些不如直接调 API，但自己量化、自己测速、自己找到那个"再压一档就崩"的临界点，这个过程对模型和硬件的理解是租 API 很难提供的乐趣。下一次出新卡或者新模型，这套流程直接照搬就行，几个小时就能摸清楚它的底细。

位居Spark Arena 速度榜首的LFM2.5-350M-低配设备无显卡也能运行的本地大模型

2026-08-15T15:00:00+08:00

Liquid AI 的 LFM2.5-350M 最近在 Spark Arena https://spark-arena.com/leaderboard 上长期居于速度榜首。这个模型在 Ollama 上可以直接拉取：

ollama pull LiquidAI/lfm2.5-350m

只有 379MB，Q8_0 量化，354.48M 参数，128K 上下文，标注了 tools + thinking + completion 三项能力。

我把之前对其他所有小模型做过的同一套测试——脚本评测（46 用例中英双语）和 BFCL 官方评测（25 抽样）——都对它跑了一遍，下面是结果和对比。

测试环境与模型

MacBook Air M4, 16G 统一内存
推理引擎: Ollama 0.32.9

属性	值
模型名	lfm2.5-350m
架构	LFM-2.5（Liquid 混合架构）
参数量	354.48M
下载大小	379 MB
量化	Q8_0
上下文	128,000
能力	completion, tools, thinking
Ollama 地址	https://ollama.com/LiquidAI/lfm2.5-350m
Spark Arena	https://spark-arena.com/leaderboard

脚本评测结果

46 个测试用例（23 用例 × 中英双语），覆盖 simple / parallel / tool_selection / irrelevant / multi_turn / tau_airline / tau_retail / edge 八个维度，使用 Ollama 原生 tools 接口，temperature=0。

维度	得分
simple	0.67
parallel	0.35
tool_selection	0.38
irrelevant	0.25
multi_turn	0.33
tau_airline	0.00
tau_retail	0.50
edge	0.33
总通过率	50.0%
均分	0.42
EN 通过率	69.6%
ZH 通过率	30.4%
总耗时	74s

BFCL 官方评测结果

使用 BFCL 官方管线（bfcl generate → bfcl evaluate），25 个抽样测试用例（simple_python 10 + irrelevance 10 + parallel 5），AST 解析 + 类型检查 + 标准化值匹配。

类别	准确率
irrelevance	90%
simple_python	50%
parallel	0%

irrelevance 90% 说明这个模型在"不该调工具的时候能管住自己"这件事上做得不错。simple_python 50% 在同体量模型里也是中上水平。但 parallel 0%——在 BFCL 严格的 AST 格式要求下，它的并行调用输出格式没过关。

与其他模型对比

脚本评测总榜（含 LFM2.5-350M）

模型	大小	通过率	均分	EN	ZH	耗时
lfm2.5-thinking	697 MB	76.1%	0.74	95.7%	56.5%	668s
smollm2:1.7b	1,736 MB	76.1%	0.73	87.0%	65.2%	194s
granite4:350m-h	349 MB	67.4%	0.64	78.3%	56.5%	60s
qwen3.5:0.8b	988 MB	63.0%	0.61	82.6%	43.5%	370s
qwen3:0.6b	498 MB	56.5%	0.54	78.3%	34.8%	220s
granite4:350m	676 MB	54.3%	0.54	73.9%	34.8%	41s
lfm2.5-350m	379 MB	50.0%	0.42	69.6%	30.4%	74s
llama3.2:1b	1,260 MB	34.8%	0.30	43.5%	26.1%	97s
functiongemma	287 MB	17.4%	0.17	26.1%	8.7%	106s

BFCL 官方评测对比

模型	irrelevance	parallel	simple_python
qwen3:0.6b	100%	40%	40%
lfm2.5-thinking	100%	60%	30%
functiongemma	100%	0%	20%
granite4:350m-h	80%	20%	30%
smollm2:1.7b	80%	40%	50%
lfm2.5-350m	90%	0%	50%
qwen3.5:0.8b	30%	40%	30%
llama3.2:1b	0%	0%	0%

分析

体积效率

379MB 的体积在所有受测模型中排倒数第二（仅比 functiongemma 的 287MB 大），但通过率 50% 远超 functiongemma 的 17.4%。按"每 MB 通过率"来算，LFM2.5-350M 是 0.132%/MB，granite4:350m-h 是 0.193%/MB——granite4:350m-h 仍然是体积效率最高的，LFM2.5-350M 排第二。

英文 vs 中文

英文 69.6% vs 中文 30.4%，差距 39 个百分点。这个差距和 lfm2.5-thinking（95.7% vs 56.5%，差 39pp）以及 qwen3.5:0.8b（82.6% vs 43.5%，差 39pp）几乎一样。说明 LFM 系列的中文工具调用能力和同体量的其他模型处于同一水平——都不太行。

简单调用能力强

simple 维度 0.67，在所有模型中排第三（granite4:350m-h 和 lfm2.5-thinking 并列第一 0.75）。BFCL simple_python 50% 也是所有模型中最高的（与 smollm2:1.7b 并列）。这说明 LFM2.5-350M 在单次工具调用 + 参数填充这件事上做得不错。

并行调用是短板

脚本评测 parallel 0.35，BFCL parallel 0%。在 BFCL 严格的 AST 格式下，它的并行调用输出完全没过关。这和 Spark Arena 的排名形成对比——Spark Arena 评测的可能不是并行工具调用场景，而是单轮推理质量。

与同门 lfm2.5-thinking 的关系

lfm2.5-thinking（697MB，1.2B 参数）通过率 76.1%，lfm2.5-350m（379MB，354M 参数）通过率 50%。同一架构、不同参数规模，通过率差了 26 个百分点。参数量缩到不到三分之一，能力下降了三分之一多一点，这么粗略来看缩放效率还算合理。

速度

实际生成速度（tokens/s）测试结果：

模型	生成 tokens	生成时间	tok/s
lfm2.5-350m	33	0.41s	80.2
granite4:350m-h	126	3.63s	34.7
lfm2.5-thinking	256	8.41s	30.4

LFM2.5-350M 以 80.2 tok/s 的生成速度遥遥领先，是 granite4:350m-h 的 2.3 倍、lfm2.5-thinking 的 2.6 倍。这正是它在 Spark Arena 速度榜上排第一的原因——Liquid 的混合架构（SSM + Transformer）在推理效率上有天然优势，350M 参数配合 Q8_0 量化在本地 CPU/Metal 上能跑到 80 tokens/s，这个速度体验已经非常流畅了。

74 秒跑完 46 个工具调用测试，平均每个测试 1.6 秒，也是所有受测模型里第二快的（仅次于 granite4:350m 的 41s）。

代码能力测试

工具调用之外，还用 HumanEval / HumanEval-X 对两个 LFM 模型跑了代码生成 pass@1 测试。每种语言 15 题，覆盖 Python、C++、JavaScript 三种语言，要求模型补全函数代码并通过单元测试。

测试方法：给模型 HumanEval 的 prompt，追加指令"Complete the code. Output ONLY the code, no explanation, no markdown."，temperature=0。从模型输出中提取代码块，编译/运行后检查测试用例是否通过。

模型	大小	Python	C++	JS	平均
lfm2.5-350m	379 MB	13%	0%	13%	9%
lfm2.5-thinking	697 MB	0%	0%	0%	0%

结果很直白：两个 LFM 模型的代码生成能力都很弱。

lfm2.5-thinking（697MB，1.2B 参数）全挂——三种语言 0%。考虑到它有 thinking 机制，很可能在代码场景下思维链反而干扰了输出格式，导致提取不到有效代码，或者生成的代码虽然"看起来像"但逻辑不对。

lfm2.5-350m（379MB，354M 参数）稍好，Python 和 JS 各对了 2 题（13%），C++ 全挂。9% 的平均 pass@1 在同体量模型里属于较低水平。作为参考，之前测过的 qwen3.5 系列在同样 15 题规模下 Python 普遍在 40-70% 区间。

这说明 LFM 的混合架构（SSM + Transformer）在工具调用场景下有一定竞争力，但在代码生成这个需要精确语法和逻辑推理的任务上，跟同体量的 Dense Transformer 模型还有明显差距。如果你的使用场景需要模型写代码，LFM 系列目前不是合适的选择。

总的来看适合低成本设备

LFM2.5-350M 在 379MB 的体积下做到 50% 工具调用通过率和 50% 的 BFCL simple_python 准确率，单次工具调用能力在同体量模型中领先。但并行调用（BFCL parallel 0%）、中文（30.4%）、以及代码生成（pass@1 平均 9%）是三个明显短板。

Spark Arena 榜首的位置说明它在速度上确实有优势，但工具调用和代码生成场景下的表现跟专门的评测还是有差距。如果需要并行调用、中文工具调用或代码生成，granite4:350m-h（349MB，67.4%，中文 56.5%）仍然是更稳妥的选择。但如果你的使用场景对体积和速度敏感、以单次工具调用为主、以英文为主、不需要写代码，LFM2.5-350M 值得一试。

对于一般的低成本设备来说，LFM2.5-350M 根本不用什么 GPU，就直接用 CPU 应该就可以流畅运行了。

超小模型在超低配 MacBook 上的运行性能实测

2026-08-15T10:00:00+08:00

低配机器的本地模型，绕不开一个矛盾：模型越小跑得越快，但能力也越弱。在一些不具备大显存独显的设备上，"超小模型"（参数低于 2B）几乎是唯一能跑得顺畅的选择。本文把当前 Ollama 里安装的全部生成模型按统一标准测一遍速度，重点看超小模型这一档的真实表现。

测试方法

硬件：MacBook Air M4，16G 统一内存
推理引擎：Ollama 0.32.9
测速方式：300 token 长文本生成，temperature=0、关闭思考，充分预热后取 5 次平均值
生成速度单位：token/s（每秒生成 token 数）

测速用长文本生成而非短回复，是因为短回复测的是"首 token 延迟"，长文本才反映持续生成的吞吐，更贴近实际使用。

完整速度表

当前 Ollama 里共 8 个生成模型（另有 5 个 embedding 模型，不参与生成速度对比），按参数规模排列：

模型	参数量	体积	量化	生成速度
granite4:350m-h	340M	366 MB	Q8_0	30.2 tok/s
qwen3.5:0.8b-mlx	0.8B	1.2 GB	mxfp8	30.0 tok/s
lfm2.5-thinking	1.2B	731 MB	Q4_K_M	26.3 tok/s
smollm2:1.7b	1.7B	1.8 GB	Q8_0	12.9 tok/s
qwen3.5:2b-mlx	2B	3.1 GB	mxfp8	11.0 tok/s
qwen3.5:4b-mlx	4B	4.0 GB	nvfp4	9.7 tok/s
qwen3.5:9b-mlx	9B	8.9 GB	nvfp4	5.1 tok/s
omnicoder-2-9b	9B	5.7 GB	Q4_K_M	4.4 tok/s

速度随参数量递减，但曲线并非线性——从 340M 到 1.2B 这一档，速度几乎持平在 26-30 tok/s；从 1.7B 起，速度降到 13 tok/s 以下。这个"分界"值得注意。

三个观察

340M 与 800M 速度相同，提示小模型受固定开销拖累。 granite4:350m-h 只有 340M 参数，是 qwen3.5:0.8b（800M）的 42%，但两者的生成速度完全一致（30.2 vs 30.0 tok/s）。参数少了 2.35 倍，速度却没有提升——这说明瓶颈可能不在"读取权重"（内存带宽），而在 Metal 引擎的固定开销：kernel 调度、内存延迟这类与参数规模无关的成本。当然，这只是本次样本的观察，未测更小的模型，不能据此断言存在某个绝对的速度上限。所谓 hybrid 架构（SSM 融合）在 Metal 后端上也未体现出速度优势。granite4:350m-h 的真正价值在于"能力密度"（此前工具调用评测通过率 67.4%，是所有模型里最小而最强的），而非推理速度。

qwen3.5:0.8b 的 30 tok/s 需要预热。 首次运行只有 6 tok/s，要到第 3 次才稳定到 27-32 tok/s。这是 Metal kernel 首次编译缓存导致的冷启动开销，其他模型同样存在，只是小模型更容易被掩盖。实际使用中，第一次对话明显偏慢，属正常现象。

lfm2.5-thinking 的"思考"开关似乎没有生效。 分别用 think=False 和 think=True 各测 5 次，速度都是 26.3 tok/s，没有差异。它此前在工具调用评测中耗时 668 秒（是 granite 的 10 倍），但那是"每步先思考再行动"累积的结果，而非生成速度慢。纯生成场景下，它的速度并无劣势。

超小模型这一档的取舍

把速度数据与之前的能力评测（智力、知识、代码、工具调用）合并起来看：

模型	速度	工具调用	特点
granite4:350m-h	30.2	67.4%	最小最强，hybrid 架构
qwen3.5:0.8b	30.0	63.0%	全功能，含视觉/思考
lfm2.5-thinking	26.3	76.1%	工具调用最高，但"思考"存疑
smollm2:1.7b	12.9	76.1%	工具调用并列最高

四项里没有单项通吃的赢家：granite4 体积最小、能力密度最高，lfm2.5 和 smollm2 工具调用更强，qwen3.5:0.8b 胜在功能全面（视觉、思考、工具调用都支持）。

简单总结

在 16G 内存的低配 MacBook 上，超小模型（<2B）的价值在于"常驻可用"——30 tok/s 的速度足以支撑日常对话和文本翻译之类的简单任务，366MB 的 granite4:350m-h 甚至可以一直挂在内存里随叫随到。但它们的上限也明确：一旦任务需要真正的代码生成或多步推理，就必须跨过 2B 这条线，接受速度的降低。

超小模型解决的是"有没有得用"，不是"用得好不好"。前者在低配机器上，恰恰是最重要的。

要最小体积、常驻内存：granite4:350m-h，366MB 几乎无感，速度与其他超小模型持平（30 tok/s），简单工具调用够用。
要全功能、对付着用：qwen3.5:0.8b，视觉/思考/工具调用都支持，速度同样 30 tok/s，代价是体积略大。
要工具调用准确率：lfm2.5-thinking 或 smollm2:1.7b，前者更小更快，后者更稳。
要真正能写代码/复杂推理：越过 2B 这一档，上 qwen3.5:4b（9.7 tok/s，代码能力跃升），这是超小模型之外的第一个"甜点"。
不在乎速度：那还是 qwen3.5:9b 或者 omnicoder-2-9b（各种能力都强力提升），虽然速度相对慢了，但能力提升显著。

附录：模型拉取命令

文中涉及的模型均可通过以下命令拉取：

# 超小模型（参数 < 2B）
ollama pull granite4:350m-h
ollama pull qwen3.5:0.8b-mlx
ollama pull lfm2.5-thinking:latest
ollama pull smollm2:1.7b

# 小模型（2B - 4B）
ollama pull qwen3.5:2b-mlx
ollama pull qwen3.5:4b-mlx

# 9B 模型
ollama pull qwen3.5:9b-mlx
ollama pull carstenuhlig/omnicoder-2-9b

Qwen3.5 小模型本地部署的不严谨横评：智力、知识、代码三项 SOTA 基准

2026-08-14T12:00:00+08:00

此前已对比过 Ollama、oMLX、MoXing 三条推理路线，关注的是推理速度。但推理速度只是工程问题，真正决定模型是否可用的是模型本身的能力。

Qwen3.8 的 27B 版本已经发布，但更小尺寸的尚未放出。本文转而回顾拥有多个小规模参数的 Qwen3.5 系列。

本文将 Qwen3.5 全系——0.8b、2b、4b、9b，外加一个 coding 特调的 omnicoder-2-9b——集中起来，用三套 SOTA 基准分别测量智力（推理）、知识（记忆）与代码（编程）三项能力。目标是回答两个问题：这些能力如何随参数规模变化；以及"能否让模型遗忘知识、仅保留智力"这一老问题。

测试环境与模型

MacBook Air M4, 16G 统一内存
推理引擎: Ollama 0.32.9

共五个模型，均为 Qwen3.5 系列：

模型	体积	量化	格式
qwen3.5:0.8b-mlx	1.2 GB	mxfp8	safetensors
qwen3.5:2b-mlx	3.1 GB	mxfp8	safetensors
qwen3.5:4b-mlx	4.0 GB	nvfp4	safetensors
qwen3.5:9b-mlx	8.9 GB	nvfp4	safetensors
omnicoder-2-9b	5.7 GB	Q4_K_M	GGUF

前四个为官方版本；omnicoder 是社区上传的 coding 特调版，基于 Qwen3.5 9B 微调而来。将其纳入，可作为"知识被消除后剩余能力"的对照样本。

所有测试都用 temperature=0、关闭思考，每道题只生成一次（pass@1）。

智力 vs 知识：SOTA 基准

先界定"智力"与"知识"的区分。采用四套数据集：

智力（题面提供充分信息，考察推理）：HellaSwag（常识推理）+ GSM8K（小学数学应用题）
知识（题面不提供，考察记忆）：TriviaQA（冷门事实问答）+ MMLU（学科知识）

各抽样 20 题，结果如下：

模型	智力(推理)	知识(记忆)	智力−知识差
qwen3.5:0.8b	22%	20%	+2%
qwen3.5:2b	28%	25%	+2%
qwen3.5:4b	38%	28%	+10%
qwen3.5:9b	58%	48%	+10%
omnicoder-2-9b	15%	12%	+2%

分项数据：

模型	HellaSwag	GSM8K	TriviaQA	MMLU
0.8b	8/20	1/20	3/20	5/20
2b	11/20	0/20	4/20	6/20
4b	15/20	0/20	5/20	6/20
9b	18/20	5/20	8/20	11/20
omnicoder	4/20	2/20	0/20	5/20

由此得到两项结论：

智力比知识更"昂贵"。 从 0.8b 到 9b，智力提升 36 个百分点，知识仅提升 28 个；智力−知识差由 +2% 扩大至 +10%——模型越大，推理能力相对记忆的优势越明显。这与"遗忘知识可节省空间"的直觉相反：记忆事实是相对廉价的部分，推理才是占用参数的主要部分。

omnicoder 是"知识被消除"的实证案例。 其 TriviaQA 得分为 0/20，冷门事实几乎全部遗忘；但代价是智力同步受损——HellaSwag 常识推理仅 4/20，而 9b 官方版为 18/20。特调消除知识的同时，推理能力一并受损。

知识外置验证

既然特调能够消除知识，那么能否彻底放弃记忆知识、改由外部检索提供？为此设计一组对照实验：对每个 TriviaQA 问题，分别在两种模式下作答——"无外部知识"（仅依赖模型记忆）与"有外部知识"（模拟 RAG，参考资料中已包含答案），各 10 题。

模型	仅依赖记忆	提供外部知识
omnicoder-2-9b	0/10	3/10
qwen3.5:9b	3/10	10/10

实验结果表明：知识外置的路径可行，但前提是模型自身的理解能力保持完整。 9b 仅依赖记忆时只有 3/10，提供外部知识后达到满分 10/10——其短板并非知识储备，而是信息输入；一旦上下文中给出答案所需的信息，其理解能力即可将答案提取出来。而 omnicoder 即便在"从参考资料中提取答案"这一任务上也仅做对 3/10，说明其基础理解能力已经受损。

因此，对"遗忘知识、保留智力"这一设想，正确的结论是：知识可以不内置于权重，但智力无法省略；且特调或遗忘操作往往同时损害智力。

代码能力：HumanEval 系列

代码部分采用 HumanEval（Python）与 HumanEval-X（C++/JS），pass@1 评分——模型仅生成一次，随后用 clang 编译、node 运行、python 执行测试用例，全部通过方记为正确。

模型	Python	C++	JS	平均
qwen3.5:0.8b	20%	20%	53%	31%
qwen3.5:2b	47%	33%	40%	40%
qwen3.5:4b	100%	47%	80%	76%
qwen3.5:9b	100%	47%	93%	80%
omnicoder-2-9b	60%	60%	80%	67%

说明：前四个模型每语言测 15 题；omnicoder 因推理速度过慢（生成一段代码需上百秒），每语言仅测 5 题，其分数为 5 题内的正确率，仅供参考。

代码部分的观察如下：

4b 是能力分水岭。 0.8b 到 2b 仅从 31% 升至 40%，增幅平缓；2b 到 4b 则由 40% 跃升至 76%。4b 与 9b 在 Python 简单题上均取得满分——对于日常编写脚本、函数的需求，4b 已经足够。

C++ 是所有模型的薄弱项。 即便 9b 也仅有 47%。C++ 的类型系统、指针与 STL 对较小模型尤为不利，生成的代码多数无法通过编译。

omnicoder 的特调未带来代码优势，反而引入了额外问题。 其 Python 60% 并不高于 9b 官方版，且默认会将"思考过程"直接输出到正文中，开头常出现大段 "Let me analyze this problem..."，需显式传入 num_think=0 才能正常输出代码。否则，其 token 预算会被思考内容耗尽，函数体尚未生成即被截断。

三项观察

"智力"与"知识"在模型中并不等价，但也难以干净分离。 数据显示智力随规模增长更快（+36pp vs +28pp），说明二者的参数效率不同；但 omnicoder 的案例又表明，无法只消除其一——特调消除知识时，智力随之受损。二者在权重中深度耦合。

代码能力是三项中增长最不连续的一项。 推理与知识均随规模平滑提升，代码却呈现 2b 到 4b 的突变。一个可能的原因是：代码生成需要模型达到某个理解阈值，超过阈值后，剩余的部分即是对标准模式的组合。

小模型的 C++ 能力基本不可用。 4b 以下模型 C++ 正确率均不高于 33%。若需本地进行 C++ 代码生成，应选择 9b 及以上规模，而非寄望于小模型。

选型建议

按用途划分：

日常对话、简单工具调用：0.8b 或 2b 即可，智力 22-28% 足以应对简单场景，优势在于速度。
本地编写代码（Python/JS）：4b 是均衡之选，Python 满分、JS 80%，体积仅 4GB，16G 内存下运行无压力。
追求最强的通用能力：9b，智力 58%、代码 80%，代价是推理速度与内存占用。
omnicoder 不建议采用：特调未带来代码优势，且需额外处理思考内容泄露问题，性价比不高。

结语

回到最初的问题——"能否让模型遗忘知识、仅保留智力"。

综合三项测试，结论是：方向正确，但实现路径有误。 正确之处在于"知识可以外置"——9b 在提供外部知识后达到满分，证明 RAG/检索增强完全可行。错误之处在于"仅保留智力"——智力恰恰是最昂贵、最不可省略的部分；任何"定向删除知识"的操作（特调、遗忘、蒸馏）几乎都会同时损伤智力。

因此，现实的方案是：不应试图在权重中删减知识，而应选择一个规模适度、能力足够的模型，将知识外置于检索系统。 需要时按需检索并注入上下文，远比压缩权重更为经济。

Windows 系统下从中科大 USTC 镜像安装 Miniconda3 完整指南

2026-08-14T12:00:00+08:00

近年来接触了不少初学 Python 的朋友，发现几种常见做法会带来一些困难：

一部分人直接从官网下载 Python 解释器，不仅下载速度慢，后续的环境变量配置和多版本管理也较为繁琐；
另一部分人选择安装体积庞大的 Anaconda3，并长期依赖 Spyder 等类似 MATLAB 界面的集成开发环境，但这类环境依赖链条复杂，稍有版本不匹配便可能导致整个系统无法启动；
还有一些人在面对多项目并行开发时，遭遇包依赖冲突，虽尝试使用虚拟环境，却因路径混乱或管理不便而难以有效隔离环境。

针对上述问题，一种更轻量、灵活的解决方案是采用 Miniconda——Anaconda 的精简版本。通过将其安装至固定路径、配置全局可用，并为不同项目单独创建指定 Python 版本及依赖组件的隔离环境，可显著提升开发效率与环境稳定性。

当然了，随着以后开发经验的积累，完全可以逐渐按照自己的开发偏好或者所在团队的规范来另行设置。

本文围绕这一实践路径展开说明：如何在 Windows 系统中，从中国科学技术大学开源软件镜像站（USTC）下载并安装 Miniconda3，部署至 C:\Miniconda3 目录，并完成基础开发环境的配置。内容涵盖安装流程、PowerShell 初始化、镜像源设置、虚拟环境创建及包管理操作，适用于初学者与日常开发场景。

为什么从 TUNA 换成 USTC？ 清华大学 TUNA 镜像站已宣布不再提供 Anaconda 官方仓库的镜像服务。USTC 镜像站目前仍然提供 Miniconda 安装包下载以及 conda-forge、bioconda 频道的动态缓存。需要注意的是，USTC 的 Anaconda 镜像不包含 Anaconda 公司维护的 defaults 频道（即 main、free 等），而是通过 conda-forge 和 bioconda 这两个社区频道来提供包。对于绝大多数用户来说，conda-forge 已经能够覆盖日常所需的几乎全部 Python 包，且更新更频繁、版本更新。

1、下载 Miniconda3 安装程序

安装程序需从 USTC 镜像站获取，以确保下载速度与版本时效性。使用以下链接直接下载适用于 64 位 Windows 系统的最新版 Miniconda3：

下载地址：

https://mirrors.ustc.edu.cn/anaconda/miniconda/Miniconda3-latest-Windows-x86_64.exe

该链接始终指向最新稳定版本，无需手动选择具体文件名。

2、安装 Miniconda3 到 C:\Miniconda3

目标路径 C:\Miniconda3 位于系统盘根目录，Windows 默认限制普通用户在此位置写入数据。因此，安装过程必须以管理员权限运行，并选择"所有用户"安装模式。

安装步骤：

右键点击下载完成的安装文件（Miniconda3-latest-Windows-x86_64.exe），选择 "以管理员身份运行"。
在安装向导中点击 "Next"，勾选 "I Agree" 接受许可协议。
在 安装类型（Select Installation Type） 页面，选择 "All Users (requires admin privileges)"。

注意：尽量别选择 "Just Me"，否则安装程序无法写入 C:\ 目录。

在 安装路径（Choose Install Location） 页面，手动输入路径：

C:\Miniconda3

在 高级选项（Advanced Options） 页面：
勾选 "Add Miniconda3 to my PATH environment variable"；
勾选 "Register Miniconda3 as my default Python 3.x"。
点击 "Install" 开始安装，完成后点击 "Finish"。

安装完成后，Miniconda3 将位于 C:\Miniconda3，对系统中所有用户可用。

3、初始化 Conda 对 PowerShell 的支持

Conda 需通过初始化操作，才能在 PowerShell 中自动激活环境并提供命令补全等功能。该操作需在管理员权限下执行一次，后续普通用户即可正常使用。

初始化步骤如下：

以管理员身份启动 PowerShell：
按 Win + S，搜索 "PowerShell"；
右键选择 "以管理员身份运行"。
设置 PowerShell 执行策略，允许本地脚本运行：

Set-ExecutionPolicy RemoteSigned -Scope CurrentUser

输入 Y 并回车确认。

执行 Conda 初始化命令：

& "C:\Miniconda3\Scripts\conda.exe" init powershell

关闭当前 PowerShell 窗口，重新打开一个新的普通 PowerShell 窗口（无需管理员权限）。
验证初始化是否成功：

conda --version

若返回版本号（如 conda 24.5.0），说明配置成功。此时命令行提示符前可能显示 (base)，表示 Conda 的基础环境已激活。

4、配置 Conda 与 pip 使用 USTC 镜像源

配置 Conda 镜像源

由于 USTC 镜像不提供 Anaconda 官方的 defaults 频道，我们需要移除 defaults，改为使用 conda-forge 和 bioconda 这两个社区频道。

首先，检查是否已存在 .condarc 配置文件：

conda config --show-sources

如果显示的配置中包含 defaults 频道，先删除该文件：

Remove-Item "$env:USERPROFILE\.condarc" -ErrorAction SilentlyContinue

然后重新生成并写入 USTC 镜像配置：

conda config --set show_channel_urls yes

这条命令会在 %USERPROFILE% 目录下生成 .condarc 文件。接下来手动写入完整配置：

@'
channels:
  - nodefaults
custom_channels:
  conda-forge: https://mirrors.ustc.edu.cn/anaconda/cloud
  bioconda: https://mirrors.ustc.edu.cn/anaconda/cloud
show_channel_urls: true
'@ | Out-File -FilePath "$env:USERPROFILE\.condarc" -Encoding utf8

写入完成后，清除索引缓存使配置生效：

conda clean -i

验证配置是否正确：

conda create -n testenv numpy -c conda-forge

如果能正常从 USTC 镜像下载并安装，说明配置成功。可以删除测试环境：

conda env remove -n testenv

配置 pip 镜像源

执行以下命令创建 pip 配置文件，使用 USTC 的 PyPI 镜像：

mkdir -Path $env:APPDATA\pip -Force
@'
[global]
index-url = https://pypi.mirrors.ustc.edu.cn/simple
trusted-host = pypi.mirrors.ustc.edu.cn
'@ | Out-File -FilePath $env:APPDATA\pip\pip.ini -Encoding utf8

配置完成后，所有 pip install 命令将自动使用 USTC 的 PyPI 镜像，显著提升安装速度。

5、创建 Python 3.12 虚拟环境

为避免不同项目间的依赖冲突，推荐使用 Conda 创建独立的虚拟环境。

创建与激活环境：

# 创建名为 dev、Python 版本为 3.12 的环境
conda create -n dev python=3.12 -y
# 激活该环境
conda activate dev

激活后，命令行提示符前将显示 (dev)，表示当前处于 dev 环境中。

验证 Python 版本：

python --version

输出应为：

Python 3.12.x

6、使用 conda 和 pip 安装包

在虚拟环境中，可使用 conda 或 pip 安装所需库。由于 USTC 镜像走的是 conda-forge 频道，安装时建议显式指定 -c conda-forge，若包在 conda-forge 中不存在，再使用 pip。

安装示例：

# 确保已激活 dev 环境
conda activate dev
# 使用 conda 从 conda-forge 安装 numpy
conda install numpy -c conda-forge -y
# 使用 pip 安装 requests（从 USTC PyPI 镜像）
pip install requests

查看已安装的包：

查看 Conda 安装的包：

conda list

查看 pip 安装的包：

pip list

7、常用命令速查

功能	命令
激活环境	`conda activate dev`
退出当前环境	`conda deactivate`
查看所有环境	`conda env list`
删除环境	`conda env remove -n dev`
导出环境配置	`conda env export > environment.yml`
从配置文件创建环境	`conda env create -f environment.yml`
从 conda-forge 安装包	`conda install <包名> -c conda-forge`

总结

通过上述步骤，已完成以下配置：

从 USTC 镜像下载并安装 Miniconda3 至 C:\Miniconda3；
在 PowerShell 中正确初始化 Conda；
将 Conda 的频道配置为 USTC 镜像的 conda-forge 和 bioconda；
将 pip 的默认源设置为 USTC PyPI 镜像；
创建了独立的 Python 3.12 开发环境；
掌握了基本的包管理操作。

日常开发中应始终使用虚拟环境，以保持项目依赖的清晰与隔离。该配置适用于数据科学、机器学习、Web 开发等多种 Python 应用场景。

References

USTC Anaconda 镜像帮助：https://mirrors.ustc.edu.cn/help/anaconda.html
USTC PyPI 镜像帮助：https://mirrors.ustc.edu.cn/help/pypi.html
Miniconda 安装包目录：https://mirrors.ustc.edu.cn/anaconda/miniconda/

最低配 MacBook Air M4 16G 跑 9B 模型：Ollama、oMLX、MoXing 三条路线实测

2026-08-14T07:30:00+08:00

对于手头只有一台最低配 MacBook Air（M4，16G 统一内存，256G 硬盘）的朋友来说，能不能本地跑一个 9B 模型，还能不能用起来？答案是可以，但"用哪个引擎跑"这件事，速度差得不是一点半点。

这一篇拿手上这台最低配 Air，把三条路线——Ollama、oMLX、MoXing——全跑了一遍，速度和工具调用能力都测了，数据摆出来，分享给大家。

测试环境

MacBook Air M4
内存: 16G 统一内存架构
硬盘: 256G SSD
推理: Apple M4 GPU (Metal) + CPU 混合

三个引擎都是最新版：

引擎	定位	底层	装法
Ollama 0.32.9	最流行的本地 LLM 管理器	自带 runner	`brew install ollama`
oMLX 0.5.7	Apple Silicon 原生推理服务器	mlx-lm（Apple 官方）	`brew tap jundot/omlx && brew install omlx`
MoXing 0.1.38	llama.cpp 的 Python 封装	llama.cpp（Metal）	`pip install moxing`

Ollama 的 MLX 底层似乎是把权重拆成几百个散装 blob 存起来，跑的时候走 Ollama 自己的 runner，绕了一道。要说原生调 MLX，那还是 oMLX（直接基于 Apple 官方的 mlx-lm）。MoXing 则是另一条路——直接跑 llama.cpp，走的是 GGUF 这条更通用的路子。

模型从哪来

测三个引擎需要模型。两个 9B 选手：

qwen3.5:9b（Qwen3.5 系列，工具调用 + 编码都能打）
omnicoder-2-9b（社区 coding 模型，Q4_K_M 量化，GGUF 格式）

下载路径各不一样，这里有个坑值得单独说：

Ollama 的模型基本不能直接给 oMLX 用。就我实测，Ollama 把 MLX 权重拆成了逐个 tensor 的 blob（我 hexdump 看过，每个 blob 是 长度前缀 + JSON 元数据 + 裸 tensor），oMLX 要的是标准的 config.json + model.safetensors + tokenizer.json 目录结构，两者对不上。

oMLX 这边，好消息是它原生支持 ModelScope 下载（内置了 ms_downloader，走 modelscope SDK）。Qwen 是阿里自家的，ModelScope 也是阿里的，所以 Qwen 系列的 MLX 版本在 ModelScope 上最全，国内直连比 HuggingFace 快得多：

# oMLX 从 ModelScope 拉 Qwen3.5 的 MLX 版
snapshot_download('mlx-community/Qwen3.5-9B-MLX-4bit', local_dir='~/.omlx/models/...')

MoXing 更省事，它能直接读 Ollama 下载好的用户上传的 GGUF。Ollama 的 GGUF 模型本来就是整个文件存成一个 blob，MoXing 找到这个 blob 的路径就能直接跑，但是要注意只能运行omnicoder-9b这样的用户上传的GGUF，而不是Ollama的官方的GGUF：

from moxing.ollama import OllamaClient
path = OllamaClient().get_model_gguf_path('carstenuhlig/omnicoder-2-9b')
# /Users/fred/.ollama/models/blobs/sha256-550e8f...  (5.74 GB)

速度对比

测速统一用 300 token 长文本生成、关闭思考、热启动取三次平均。这是最贴近"实际持续生成"的数字，比工具调用那种只吐几十个 token 的短回复更能反映真实吞吐。

9B 模型

引擎	模型	量化	生成速度
Ollama	omnicoder-2-9b	Q4_K_M (GGUF)	4.6 tok/s
MoXing	omnicoder-2-9b（同一份 GGUF）	Q4_K_M	5.0 tok/s
Ollama	qwen3.5:9b-mlx	NVFP4 (safetensors)	5.1 tok/s
oMLX	qwen3.5 9B	4bit	6.5 tok/s

冷启动（含模型加载）：

引擎	模型	冷启动耗时
Ollama	omnicoder-2-9b	~62s
MoXing	omnicoder-2-9b	~38s
Ollama	qwen3.5:9b-mlx	~66s
oMLX	qwen3.5 9B	~44s

Ollama vs MoXing：同模型多轮统计

上面 omnicoder 那一行（4.6 vs 5.0）是整体平均值。为了看清楚 MoXing 到底快在哪，把同一个 GGUF 按「输入长短 × 输出长短」切成四个场景，每个场景跑 3 次取平均：

场景	Ollama (tok/s)	MoXing (tok/s)	加速比
短输入-短输出（60 tok）	4.65 ± 0.94	5.00 ± 0.70	1.08×
短输入-长输出（300 tok）	4.68 ± 0.12	4.61 ± 0.56	0.99×
长输入-短输出（60 tok）	4.29 ± 1.13	4.77 ± 1.25	1.11×
长输入-长输出（300 tok）	4.74 ± 0.15	5.51 ± 0.09	1.16×
整体平均	4.59	4.97	1.08×

规律大致是：长输入场景 MoXing 优势大（11-16%），短输入场景差距小（0-8%）。原因大概在于 MoXing 默认开了 Flash Attention 和 KV cache 4-bit 量化，这些优化的收益主要落在 prefill（处理输入）阶段，输入越长省得越多。短 prompt 时 prefill 占比小，两边 decode 速度本来就接近，差距就摊薄了。

0.8B 模型

引擎	模型	量化	生成速度
Ollama	qwen3.5:0.8b-mlx-bf16	BF16	25 tok/s
oMLX	qwen3.5 0.8B	8bit	34.4 tok/s

工具调用能力对比

速度只是一方面，工具调用能不能打，才算得上本地模型能不能干活的更关键一环。测试沿用之前那套方案——参照 BFCL / ToolBench / τ-bench 的方法论，23 个用例 × 中英双语 = 46 个测试，覆盖简单调用、并行调用、工具选择、无关场景、多轮串行、边界情况八个维度。

引擎	模型	通过率	EN	ZH
Ollama	qwen3.5:9b-mlx	67.4% (31/46)	78.3%	56.5%
oMLX	qwen3.5 9B 4bit	65.2% (30/46)	82.6%	47.8%
Ollama	omnicoder-2-9b	63.0% (29/46)	78.3%	47.8%

分维度得分：

维度	qwen3.5:9b-mlx (Ollama)	qwen3.5 9B (oMLX)	omnicoder-2-9b (Ollama)
simple	0.67	0.67	0.67
parallel	1.00	0.90	0.96
tool_selection	0.75	0.75	0.75
irrelevant	0.25	0.25	0.50
multi_turn	0.38	0.21	0.08
tau_retail	0.50	0.50	0.00
edge	0.67	0.67	0.83

之前那篇测过 11 个 1B 及以下的小模型，用的就是同一套 46 用例的脚本。把这次的三个 9B 成绩放进去一起排：

模型	参数量	通过率	来源
lfm2.5-thinking	1.2B	76.1%	之前
smollm2:1.7b	1.7B	76.1%	之前
granite4:350m-h	340M	67.4%	之前
qwen3.5:9b-mlx	9B	67.4%	本篇 (Ollama)
qwen3.5 9B	9B	65.2%	本篇 (oMLX)
qwen3.5:0.8b	0.8B	63.0%	之前
omnicoder-2-9b	9B	63.0%	本篇 (Ollama)
qwen3:0.6b	0.75B	56.5%	之前
granite4:350m	350M	54.3%	之前
llama3.2:1b	1.2B	34.8%	之前
functiongemma	268M	17.4%	之前
gemma3:1b	1B	0.0%	之前

第一眼有点意外：9B 的通过率（63-67%）并没有碾压小模型，甚至被 lfm2.5-thinking 和 smollm2:1.7b 反超。但仔细看能看出门道：

9B 的 parallel（并行调用）这次拿了满分。 qwen3.5:9b 在"同时查几个城市天气、同时调多个工具"这类场景拿到 1.0，和 lfm2.5 打平，超过其他所有小模型。一次回复里规划多个工具调用，这是"复杂工具编排"的能力，比单次调用更接近真实 agent 干活的场景。

lfm2.5 的 76% 是拿速度换的。 它跑了 668 秒，是 granite4:350m-h（60 秒）的十倍还多——thinking 机制让它每一步都先"想"再"做"。真实场景里没人愿意为一个天气查询干等十几秒。

更重要的是，9B 是通用模型。 lfm2.5、smollm2 这些是在"工具调用"这个窄场景里表现好，让它们写代码、读长文档、做复杂推理，往往就直接掉链子。9B 相对是"什么都能干一点"——编码、长上下文、复杂推理、工具调用，都不算太拉胯。

所以"应急"的准确含义是：手头只有一台 16G 的 Air、没有网、又需要本地模型处理一点稍微复杂的活时，9B 是那个能顶上的——它不算顶尖，但不会像 1B 小模型那样在复杂任务面前直接宕机。

反过来，小模型也有它的位置。别看完上面的对比就觉得 9B 全面压制。在"简单工具调用"这个专门场景里，有些小模型不输 9B，甚至反超：

granite4:350m-h（349MB）通过率 67.4% 和 9B 打平，但简单调用（0.83）和多轮串行（0.79）两项都超过了 qwen3.5 9B 的 0.67 和 0.38
关键是它只要 349MB、60 秒就跑完整个测试，常驻内存几乎零负担，随叫随到

所以更实用的组合不是二选一，而是各存一个：常驻一个 granite4:350m-h 这种轻量模型处理高频的简单调用，需要复杂任务时再临时拉 9B 出来。 一个管"快"，一个管"全"，不冲突。

几个有意思的发现

同一个 GGUF，换引擎平均快个 8%，长输入快更多。 MoXing 跑的就是 Ollama 下载的那份 omnicoder-2-9b GGUF，字节都没变。就这次多轮统计来看，短输入场景基本持平（0.99-1.08×），长输入场景能快 11-16%。原因大概在 runner 的默认参数——Ollama 没开 KV cache 量化、Flash Attention、连续批处理这些优化，而 MoXing 启动时默认就全开了（-ctk q4_0 -ctv q4_0 --flash-attn on --cont-batching），这些优化的收益集中在处理长输入的 prefill 阶段。

oMLX 的原生 MLX 比 Ollama 的 MLX 兼容层是要快一些。 9B 那组是 6.5 vs 5.1 tok/s，快 27%。这组相对干净——两边都是 4bit 级量化（NVFP4 vs MLX 4bit），可比。0.8B 那组 oMLX 快 38%，但那里 Ollama 用的是 BF16 全精度、oMLX 用 8bit，量化更低，所以 38% 里有一部分是量化差异的功劳，不能全算到引擎头上。

工具调用能力基本跟引擎无关，主要还是取决于模型本身。 qwen3.5 9B 在 Ollama 里 67.4%，换到 oMLX 里 65.2%，基本持平。这大概说明换引擎不会明显提升模型的工具调用水平——引擎主要决定快慢，模型才决定好坏。要提升工具调用，得换模型或换量化，不是换引擎。

omnicoder-2-9b 的多轮串行算是短板。 "先翻译再发邮件"这种链式任务，omnicoder-2-9b 只有 0.08 分，qwen3.5 9B 有 0.38。它定位是 coding 模型，工具调用不是强项，尤其多步依赖的场景基本掉链子。

中文工具调用普遍比英文差。 三个 9B 英文都在 78-83%，中文只有 47-57%，掉 30 个点以上。即使 Qwen3.5 9B 这种中英都训过的模型也一样，大概率说明这些模型的工具调用能力主要还是英文训练数据喂出来的。

16G 内存确实吃紧，oMLX 的 SSD caching 算是个解。 9B 模型 4bit 量化后 5.6GB，加上 KV cache 和其他进程，16G 内存已经不宽裕。oMLX 的 tiered KV cache + SSD caching（把冷 KV 块落到 SSD，热块留内存）在这台机器上是有意义的，这是 Ollama 没有的。不过它要占硬盘，硬盘紧张的话就得掂量一下了。

选型建议

结合速度和工具调用，三条路线各管一段：

要省心、生态全：Ollama。 一条命令拉模型，全平台支持，缺点是速度稍慢。适合第一次接触本地模型、或者不在乎多等几秒的场景。

要速度、跑 GGUF：MoXing。 直接读 Ollama 下载的 GGUF，同一份权重平均能快个 8%，长输入场景更明显，Metal 后端自动检测。缺点是得 pip 装、自己配，生态不如 Ollama。

oMLX 呢？ 原生调 mlx-lm，9B 快 27%、冷启动快 1/3，还带 SSD caching。但说实话，我自己最后把它卸了——MLX 的加速在 9B 这个体量上感觉意义不大，速度差距没多少，还不如直接用 llama.cpp 这类，更省空间也省事。它那个 SSD 缓存听着不错，但我这 256G 硬盘本来就不太够用，就先不折腾了。要是你硬盘宽裕、又主要在 Apple Silicon 上跑 MLX 模型，它还是值得一试的。

模型本身的话，工具调用场景首选 qwen3.5 9B，它的 parallel 能拿满分、多轮串行也最强；omnicoder-2-9b 留给纯 coding 用，别指望它做多步工具编排。

几点说明

最后交代一下这次对比的局限性。

速度和引擎那部分，受网络和存储的限制，没能从 HuggingFace 把全部模型的 GGUF 和 MLX 版本都下载齐，导致量化等级对不齐——BF16 对 8bit、NVFP4 对 4bit，不完全是同一个东西在比。所以"谁快多少"这个数字只能当个粗略参考，别拿去当精确结论。

工具调用那部分是另一回事：三套引擎跑的是同一套 46 用例的测试脚本，跟之前小模型的成绩可以直接排在一起比。这部分结论是站得住的——9B 没在工具调用上碾压小模型，但它是通用模型，需要应急处理复杂任务时，它还是能顶上的那个。

给大一新生的计算机使用建议

2026-08-11T12:00:00+08:00

这篇文章是我给大一同学们的一些计算机使用方面的建议。不是什么高深的技术，都是踩过坑之后攒下来的经验。

固态硬盘尽量别分区

建议大家尽量不对固态硬盘做分区处理，用目录来进行文件管理就好。也别没事就去格式化——格式化就意味着数据全丢。

为什么要额外准备一块机械硬盘做备份呢？因为固态硬盘的数据恢复，相比机械硬盘，成本高得多，也不那么方便。机械硬盘的存储是基于磁道上的磁性标记，只要原来的数据没有被真正覆盖，就总还有机会拿回来，甚至还有开盘读取这种进阶手段。但固态硬盘是直接用电信号写入的，没有物理上的磁性残留，想恢复的话，有时候未必总有那么多机会。

云盘备份这件事

除了额外的机械硬盘之外，还建议要有一个靠谱的、能稳定访问的云盘。

大概十五六年前，有家云盘公司曾经夸下海口，说自己的服务是终身免费的，容量给得特别大。结果很明显，这事儿不可持续。它突然有一天说终止运营了，让大家把数据都下载下去。那会儿我有一个同学，之前听信了这个厂商的宣传，把所有数据都传到了这个云盘上。后来发现下载带宽非常低，根本下不完。那会儿甚至有人提出愿意提供自己的硬盘，想邮寄给这家公司，让人家帮忙把数据导出来——因为有的人的数据真是没考虑过这公司可能这么不靠谱。但很遗憾，这些请求好像都没能成功。最终我那位同学丢失了很多数据，非常懊悔。

与此同时，我经历过一次硬盘损坏。好在那次用的是机械硬盘，做了数据恢复。从那以后，如果用网盘，我就尽量多备份几份。免费的、付费的，尽量都舍得一点——数据的安全性是最根本的保障。数据恢复的价格要比硬盘的物料价格、甚至比云盘的订阅价格都贵很多。十三四年前我做过一次数据恢复，两个 T 还是三个 T 的数据来着，花了几千块。那会儿这么大的硬盘本身都没那么高的价格，这笔恢复费是非常贵的钱了。

所以，要有云盘备份，而且尽量别只依赖一家。

数据的优先级划分

在备份数据的时候，可以考虑对数据做一个优先级的划分。

最普通常见的、不是特别重要的数据，你可以不怎么备份，或者只放一份。相对重要、但能够得到下载链接、或者后面还有机会再拿到的，也可以备份一下，但不必浪费云盘上的太多空间。

只有那些非常重要的东西——比如家人照片、视频、自己的重要文档、毕业论文、学位论文等等——建议尽量别只放一份。存云盘的时候应该打包成压缩包，并且加上密码，来粗略保障一下数据安全。

软件尽量装到默认路径

对于新手来说，使用计算机的另一个建议是：尽量把软件安装到默认路径。

除非你特别有把握，并且有经验的人明确跟你说过这件事儿要改路径，你再改。因为有可能某些软件就因为路径被改到了别的地方，就运行不正常了。还有一些软件会要求安装路径里不能有特殊符号——中文不行，空格也不行。

什么情况下需要自定义路径呢？就是当你明确知道这事儿我要这么做，而且知道这么做会有什么效果，也清楚会有什么隐患，并且你能够解决这些问题的时候。有这些充足的准备和信心，你就可以自己动手。

比如我常举的一个例子：Miniconda。我经常会把它安装到系统盘分区的一个比较短的目录下。因为后面要在这里边创建很多个虚拟环境，虚拟环境里又有一些依赖包，依赖包里可能有一些文件的名字比较长。如果把它装到默认路径下，比如在用户的临时数据目录或者 Program Data 等目录下，就可能导致路径过长，有时候会引发一些意想不到的问题和故障。这都是踩过坑之后得到的经验。

别给笔记本电脑贴贴纸

不建议给计算机贴上各种各样的贴纸。一方面可能会影响散热，另一方面，如果你后续不想要了、想二手卖掉，这些贴纸清理起来会留下胶粘的痕迹，甚至有划痕，反倒影响品相。

你要实在想贴、想保护一下，弄个透明的那种也还好。不过话说回来，现在的计算机是个生产工具，但也是电子消费品。三年前买的机器，三年后可能连一半价格都卖不到了。除非什么呢——像内存、固态硬盘这些，遇到突发的行业涨价，那倒还有一定的保值率。

买笔记本电脑尽量选可扩展内存的

如果大家买笔记本电脑，我的建议是尽量买支持内存扩展的。尤其是在现在内存价格非常贵的情况下，可扩展内存的机器给了你一个缓冲：自带的内存不够用的时候，你可以等到内存价格在你能够接受的时候，或者预算攒够了，或者内存降价了，再购入新的内存给它扩上去。

运行内存提高了之后，就能运行更多的虚拟机。这就说到了虚拟机。

虚拟机和我的转行经历

虚拟机最早在大概二十年前左右，那会儿我刚开始接触，是为了能够在一台机器上运行多个操作系统。

当时我得到了一张从海外邮寄过来的 Ubuntu 6.06 安装盘，想安装起来用。但发现我的显卡和网卡都没驱动。那会儿就得知，用一个虚拟机把它装成虚拟系统，就很方便。再往后，就在这个过程中，使用虚拟机体验了很多不同的上古操作系统、相关的编程语言，还有一些古老的软件。

后来又因为会装一点虚拟机和操作系统，又能装点工作用的工具软件和基础环境，就帮别人去弄像 Hadoop、Spark 之类的存储和计算工具。这是我早期转行的初期的机会之一。

尽量别重装系统

说到操作系统，现在一般来说，正常的笔记本电脑买到了之后都会有自带的正版系统，这已经在价格里了。

大家会发现里边有一些自带的软件，比如某些品牌的助手，或者是什么数字安全软件之类的，建议把它们卸载掉。这些东西都会拖累你的运行速度，而且并不能提供什么真正的安全防护。但操作系统自带的安全管理软件还是可以保留的。如果你想要用像火绒这类主动防御工具，你要是能接受它带来的性能损失，那也可以使用。不过这些咱就不展开了——现在已经不是当年那种小狮子和免费杀软大战的时代了，在那个时代，还有一些厂商会自己参与一些很难说清楚是黑是白的事情。

如果不是必要，建议尽量别自己重新安装整个系统。因为对于新手来说，驱动下载可能比较麻烦。现在很多之前的免费驱动工具软件，都要注册账户、甚至要买会员才给提供满速的服务了。这也正常，人家要保证自己的商业化嘛。

但很多同学缺乏搜索的能力，还没有培养起这个经验。他不知道找电脑驱动，一是可以找笔记本电脑的品牌厂商，可能会有售后服务；二是可以找对应硬件的官网——比如显卡是 N 卡就找 N 卡官网，是 A 卡就找 A 卡官网。这个思路没掌握的话，就会觉得很痛苦。万一折腾好几天都弄不好，还得花钱找人帮忙，又耽误时间又降低效率，而且让自己心情很不好。

所以建议新手，除了卸载一些不必要的软件之外，不是特别重要的情况下，尽量别重新安装操作系统，没有必要。

别做品牌的粉丝

说到操作系统了，就多说一句。现在的小朋友应该不像以前那么偏激了。我们上学那会儿，有一个人得到了很多流量和关注。他说：要完全用 Linux 操作系统来工作，凡是 Linux 操作系统不能完成的工作，就都是不重要的工作。所有重要的工作用 Linux 操作系统都能完成。

这个人后来自己也后悔了，也反思了，也承认了自己当时这么说的错误。再后来，他的流量也逐渐就不太行了，在很多地方都难以完整地完成学业，也充分体现了这个人在个性上和与人相处方面，还有很多可以磨砺的空间。

大家尽量别因为买了一个设备、用了某个品牌的东西，就成为它的信徒和狂热粉丝，四处去跟人说这东西好。

前几天就有人问我，某某水果品牌的设备好不好用，推荐买哪款。我就跟他说，最近就别买了，因为涨价了。而且它的芯片虽然用了统一内存，但在做本地模型运行的时候，解码的速度什么的都不是太理想——工具调用什么的也没有太多优势，反而不如那种专门的像 G10 之类的一体机。

他就很好奇，他说：你看你这用着这个设备，你怎么还说它不好呢？我就跟他讲，不是因为我用了这个设备，我就得成为它的粉丝和拥护者。恰恰是因为我十多年来都用它这些设备，我才了解这个产品现在的状态。我能判断出，我现在是否应该推荐给那天我沟通的那位朋友——因为他的需求是有一定的本地模型部署需求的。但他不需要部署特别大规模的模型，那其实完全没必要追着统一内存的大内存。有一个对应的独立显卡的体验还更好。而且他也不需要轻薄，他更需要兼容性——尤其是有一些软件，在水果平台上本来就不兼容。

希望大家尽量别这样。用什么，就用；该说什么就说什么。尽量别被品牌绑住。

尽量别买太贵的手机

笔记本电脑三四千块钱就已经能用了，但是手机这个东西，有的都卖到五六千甚至七八千。而手机的折价又特别厉害，一年之后可能就腰斩了。

建议大家读书的时候，还是尽量把钱花到刀刃儿上。养成对自己的财务负责的习惯——你现在花的每一分钱，要么是你父母挣的，要么是你自己辛辛苦苦攒的。别为了一个手机弄得自己经济紧张，或者给家里增加不必要的负担。够用就好。

手机屏幕调光与频闪

现在手机屏幕除了亮度之外，还有一个很多人不知道的问题——频闪。

目前手机屏幕的调光方式主要分两种：LCD 屏幕用 DC 直流调光，通过调整电流大小来控制亮度，没有频闪。但 OLED 屏幕大多用 PWM 调光，靠快速开关屏幕来模拟亮度变化——屏幕其实一直在闪，只是频率高到你以为它没闪。像我这种对频闪敏感的人，看一会儿就觉得眼睛刺、头疼。这不是心理作用，是生理反应。

所以如果你跟我一样，用 OLED 手机觉得眼睛累，别觉得是自己用眼习惯不好。很可能就是 PWM 频闪的问题。选手机的时候可以留意一下有没有"类 DC 调光"或者"高频 PWM"的标注，或许会稍微好一点，但我还是觉得不如 LCD 的手机。

另外，把亮度和环境光调到接近，以及千万别夜间黑灯刷手机。眼睛很累的。我有个师妹当年视网膜脱落了，记得她提到过的医生跟她说的不良用眼习惯里就有这个。

不建议新手去实体店买笔记本电脑

还有一个建议：不建议新手去实体店买笔记本电脑。

实体店买电脑被坑的案例太多了。

我们专业 25 级的一个同学，电脑是在实体店找亲戚买的。官方的配置是 1T 固态硬盘、单根 16GB 内存，他拿到手的也是 1T 固态、16GB 内存——看着一模一样。但用了之后总觉得有点奇奇怪怪的。后来拆开一看，发现官方的是单根 1T 固态、单根 16GB 内存，到他这儿变成了两根 512GB 的固态、两根 8GB 的内存。很明显是被人调包了——人家把原厂单根大容量的拆走，换成了两根小容量的。单根高容量的内存和固态，那会儿价格已经开始涨了，拆出去单卖能比两根小容量的贵不少。而且这还是"找亲戚买的"，更让人觉得防不胜防。

还有一个人在网上看好了一款机型，去实体店问价。店员说"这款我们也有，还便宜三百"。交了钱，店员说要去仓库提货，让他等半小时。等了很久之后回来说，你要的那款刚好卖完了，但我们有另一款配置更好的，稍微补点差价就行。这人信了，补了钱拿回去。后来发现，到手的那款网上根本查不到评测——是专供线下的特供型号，配置缩水得很厉害。

这些套路的本质都一样：利用信息不对等赚你的钱。

建议在电商平台上找靠谱的自营店铺，尽量别贪便宜。价格太低的，要么是翻新机，要么是展示机，要么是配置被换过的。说到底，一分钱一分货。另外，新手尤其是学生，没有足够的判断能力和承担风险的能力，尽量别买二手的。二手市场水更深，你省的那点钱，很可能会变成学费。

最后说几句

经常有人跟你们说，到了大学就简单了，就放松了，就可以玩儿了。其实这是最坑人的。

因为到了大学，才是你最需要努力、最需要选择自己努力方向的时候。

在高中的时候，有唯一的一个指挥棒——就是做题、考试、得分。只要考试得了分，那什么都没问题。家长也满意，老师也认可，整个评价体系都认为这是最棒的。但到了大学，成绩本身其实就不那么重要了。只要你不挂科，能够保研的基础能达到，大概也就行了。如果你不想保研，想考研，那只要不挂科、不影响正常学业，也没有太大问题。

更重要的是参加比赛，是写论文。甚至是你去找一个自己中意的人，争取保护好、守护好一份感情，以后一起度过余生——这也都是很重要的事儿。

希望大家能有一个非常难忘的、有收获的大学生活。

简单讲一下路径

2026-08-11T10:00:00+08:00

给大一新生讲路径，其实是为了环境变量这个概念，很多新生朋友一开始接触的时候容易懵。一直想找一个比较通俗的方式把它讲明白。

其实说白了，环境变量就相当于一个登记簿。

环境变量是个啥：去美食街看看

你去一条美食街，或者一个大商场，一般都会有个路牌儿，上面指着每家店铺在几楼、哪个位置。你照着这个牌子找到你想去的那家店，就完了。

环境变量也是这么回事儿。它是一系列的目录路径，登记在系统里。系统要找一个程序、找一个文件的时候，先去这个登记簿上翻一翻，看看在不在上面写着。在的话，直接就定位过去了；不在的话，可能就找不着，甚至直接就给你忽略了。

环境变量可以有好多个，不同的变量记着不同的东西，但其中最重要的一个叫 PATH。

PATH 是怎么回事儿：王小二的故事

这么说吧，假设我们班有一个叫王小二的同学。

隔壁一班也有一个叫王小二的，甚至这三四个班每个班都有一个王小二。但是跑到篮球队上登记的，记录在篮球队队员名单里面的，是我们班这个王小二。

那篮球队的教练，他一说"找王小二来"，找的肯定是我们班这个。因为他的登记簿上写的，就是我们班这个王小二。

PATH 也是一样的道理。它就是一个目录名单。如果你的某一个目录被登记到了 PATH 这个环境变量里面，那么这个目录底下的二进制文件也好、快捷方式也好，系统就能直接找着，优先用它。没登记到 PATH 里的那些目录，系统就很难找到，甚至完全忽略掉。

编译器在哪儿

除了 PATH，还有一个跟开发关系很大的，就是编译器所在的路径。

你比如你要用不同的编译器，有时候装了好几个版本，系统得知道这个编译器到底在哪儿。这时候可以用 where、locate、whereis、which 这些命令来尝试着找。当然，不同的终端、不同的操作系统，支持的命令也不太一样，这个得看自己用的是啥。

解释器的路径：Python 版本管理

再一个就是解释器的路径。拿 Python 来说，有的同学是直接安装的，也有的同学是用 miniconda 或者 conda 来安装，通过 conda 可以装多个不同版本的 Python。还有些同学习惯单独在某个项目底下新建一个对应的虚拟环境，各用各的。

这些办法都行，大家各取所需，找一个自己比较习惯的就好。

我个人的建议是用 miniconda，可以轻量级地方便地管理多个版本的 Python，甚至同一个版本的 Python 也可以创建好几个不同副本，互相不干扰。这么一来，就能避免不同库之间的版本冲突。

举个例子：你做 PDF 文本提取的工具，比如 marker、markitdown 这些，它可能要求 numpy 的版本比较高。而另一个工具，比如一个做地质投图的，它可能就要求 numpy 1.64。这两个版本有冲突，你装在一个环境里就会打架。这时候用 conda 各开一个环境，各用各的解释器，各装各的 numpy，啥事儿都没有。

当前工作路径：你得知道自己在哪儿

你到一个商厦去买东西的时候，光知道其他饭店在几楼几号还不够，你还得知道你自己现在在哪儿吧？我现在所在的楼层，就是当前所在的目录路径。

得先确定了自己在哪儿，再确定目标在哪儿，你才能找到一条路走过去。路径定了，方向就定了。

从我这儿出发，往前走两步，然后右转就能到那。这个路径就叫相对路径，就是相对于我当前的一个参考点，找到对应的目标的位置。

从这条大路开始，一直走800米，然后标号为358号，这个叫绝对路径，就是你就在这儿找，绝对在这358号店铺。

目标文件在哪儿

最后还有一个：你要用的目标代码文件或者资源文件所在的路径。它不一定就是你当前所在的工作路径。

你别觉得，"我打开终端了，那我要用的文件就在这儿呗"——那可不一定。这俩不是一个概念。有时候你 Python 脚本要读一个 CSV，你得把那个 CSV 的路径写对，不然脚本找不到，就报错了。

如果你只是自己用你这个绝对路径能确定，你就可以用绝对路径，这没问题。但如果你要把这东西分享给别人，有可能人家要放到别的地方，就要考虑是不是要用相对路径，不要把路径写得固定了。

说来说去，就是几个地址嘛

串一下，一共就这么几个路径：

系统的环境变量路径（PATH 那些登记在册的目录）
编译器的路径（你要用的那个编译器装在哪了）
解释器的路径（Python 装在哪个环境里、是哪个版本）
当前工作路径（你现在站在商厦的哪一层）
目标文件所在路径（你要找的那家店在哪儿）

看着挺复杂，其实就是个登记的地址本。理解了这一点，碰上路径相关的问题，静下来想想，找到目标位置，肯定能琢磨明白。

建议大学生学用AI的时候尽量掌握一门编程语言

2026-08-11T08:30:00+08:00

现在AI编程工具越来越多了，不少朋友觉得，反正有智能体帮忙写代码，大学生自己还学什么编程语言呢。这其实是得考虑考虑的。

咱不是说非得逼着每个同学都去当程序员，而是说，要是一点编程基础都没有、直接上来就用AI，容易出问题。你想想，变量是啥不知道，循环和判断是啥不知道，函数调用和返回值是啥不知道，类和继承是啥也不知道。那智能体给你生成了代码，你就只能原样贴进去跑，跑通了也不知道为什么通，跑不通也不知道为什么不通。知其然都未必能做到，更别说知其所以然了。

这个状态其实挺危险的。你拿一个自己不理解的产物去用，时间长了，会养成一些不太好的习惯——反正看不懂，跑通了就行，出了问题再让AI改。一来二去，自己的判断力没有任何增长，对AI的依赖倒是越来越深。

如果只是偶尔用一下、体验体验，那直接用智能体聊天就够了，不用学太多。但如果可能长期用，尤其是自己手头有稳定的、复杂的业务流程要靠AI来辅助，那掌握一门编程语言就很有必要了，这关系到长期可持续性的问题。

不是让你当专家，是让你能想明白

《资治通鉴》里孙权劝吕蒙读书，说了一句很值得参考的话——不是让你研究经传、当个专业的学者，而是让你"涉猎见往事"，拓宽信息渠道，加深对局势的理解。学编程语言也是一样的道理。

咱建议掌握一门编程语言，不需要去考级，只是说你要能理解最基础的这些东西：变量定义、分支判断、循环控制、函数封装、代码复用、抽象、类别定义和继承关系。说穿了，就这几个基本概念，翻来覆去地组合，就能自己想明白很多事情，有时候更为敏捷。

想的明白了，遇到用得上的时候自己琢磨得清楚，再跟智能体沟通，就能把想要达到的目的、想要的状态、想要的产物描述得更清晰、更准确。你说得越清楚，智能体干得就越利索，效率自然就上去了。

别把鸡蛋放在一个篮子里

还有一个要特别注意的，就是避免对某一个具体模型产生依赖。

你用惯了一个模型，觉得它特别好使，啥都交给它。万一哪天这个模型突然不能用了呢？或者涨价了呢？你所有的流程、所有的prompt、所有的习惯都是围绕它建立的，一下子就抓瞎了，非常被动。

我前阵子发一篇文章的时候，里面截了几个模型的样例图，有位比较敏锐的读者朋友就发现了，说："你这几张图好像一直用的都是同一个模型啊？有尝试过其他模型吗？"

我就跟人家解释了，我只是碰巧截图的时候用的那个模型。其实用多了智能体、把技能加载上去之后，模型之间的差距是可以逐渐缩小的，甚至可以完全忽略。

智能体和技能系统把方法、流程、经验都固化成可复用的"菜谱"了，换一个模型就类似换一个厨师，但只要他照着菜谱做，做出来的菜就会差不太多。当然，换了厨师嘛，略有些许差距是正常的，但大体上不会差到哪儿去。

所以这也是建议大家多用不同模型的原因。不把所有的篮子都放在一个鸡蛋上，防患于未然嘛。

大模型和智能体，不是一回事

大模型相当于具体干活的员工，智能体呢，是服务流程和操作场所。你设计好了这个流程，规定了什么时候做什么事、怎么调用工具、怎么处理结果，然后让大模型来执行。

换个模型，就是换了个干活的。但流程没变，工具没变，所以产出的质量波动不会太大。这也是为什么说，掌握了编程基础、理解了流程逻辑之后，你对单一模型的依赖就会变小。因为你知道自己想要什么，知道流程该怎么走，换个模型无非就是换个人来走这条路而已。

AI和编程可能会成为大学生必备的竞争力，而编程入门就行，也没那么复杂，比如Python，装好之后，花一点时间把变量、判断、循环、函数、类这几个概念跑一遍，写几个小例子，基本的概念框架就有了。

很多事情，只要开始做，就成了一半。

Ollama 小尺寸模型的工具调用能力评测

2026-08-10T02:00:00+08:00

对于老鸟来说，本地部署模型，肯定是vllm或者sglang又或者llama.cpp之类的。但对新手来说，可能还是Ollama更为友好简单。考虑到很多古老设备可能未必有高性能的GPU，而 Ollama 上面一些体积不大于 1GB的模型可以完全加载到CPU当中用处理器来运行。

这回就针对 Ollama 上面体积不大于 1GB（含两个稍超的对照组）具备工具调用能力的模型，攒了一个测试方案，参照 BFCL、ToolBench、τ-bench 三大基准的方法论进行了评测，覆盖 8 个评测维度、中英双语、共 506 个测试用例。然后再用BFCL的官方测试跑一遍验证一下。

评测基准来源

BFCL — Berkeley Function Calling Leaderboard

项目地址：https://github.com/ShishirPatil/gorilla
论文：The Berkeley Function Calling Leaderboard (ICML 2025)
当前版本：V4，新增 agentic web search 和 memory management 评测
特点：工具调用评测的事实标准，采用 AST 级别的参数匹配检查，覆盖 simple / parallel / multiple / irrelevance / multi-turn 等多个维度。支持 FC（原生 function calling）和 Prompt 两种模式分别排名。

ToolBench

项目地址：https://github.com/OpenBMB/ToolBench
论文：ToolLLM: Facilitating Large Language Models to Master 16000+ Real-world APIs (ICLR 2024)
特点：清华大学 THUNLP 出品，16,464 个真实 API、49 个类别。G1/G2/G3 三级难度分别对应单工具/同类多工具/跨类多工具。采用 DFS 树搜索策略进行多步工具调用，用 ChatGPT 做自动化评估（与人类判断 87.1% 一致）。

τ-bench

项目地址：https://github.com/sierra-research/tau2-bench
论文：τ-bench: Benchmarking AI Agents on Real-World Tasks (2024) / τ²-bench (NeurIPS 2025)
特点：Sierra 出品，聚焦真实业务场景的 Agent 评测。覆盖航空（airline）、零售（retail）、电信（telecom）、银行知识（banking_knowledge）四个领域。Agent 需要与模拟用户持续对话、调用工具、遵循业务策略。评分基于数据库终态匹配而非动作轨迹匹配。

评测环境

硬件

MacBook Air M4 
内存: 16G 统一内存架构
推理: CPU + GPU (Metal) 混合

软件环境

# 创建 conda 环境并安装依赖
conda create -n llmbench python=3.12
conda activate llmbench
pip install openai requests

# 安装 Ollama
brew install ollama        # macOS
# curl -fsSL https://ollama.com/install.sh | sh  # Linux
ollama serve

克隆三个评测基准项目：

mkdir -p ~/Documents/GitHub/Others && cd ~/Documents/GitHub/Others

# BFCL — 工具调用评测事实标准
git clone https://github.com/ShishirPatil/gorilla.git bfcl
cd bfcl/berkeley-function-call-leaderboard
pip install -e .

# ToolBench — 大规模真实 API 工具评测
cd ~/Documents/GitHub/Others
git clone https://github.com/OpenBMB/ToolBench.git toolbench
cd toolbench
pip install -r requirements.txt

# τ-bench — Sierra 出品 Agent 业务场景评测
cd ~/Documents/GitHub/Others
git clone https://github.com/sierra-research/tau2-bench.git tau-bench
cd tau-bench
pip install uv && uv sync

# 回到工作目录
cd ~/Documents/GitHub/Others

环境变量

# BFCL 配置 — 指向 Ollama 的 OpenAI 兼容端点
export OPENAI_API_KEY=ollama
export OPENAI_BASE_URL=http://localhost:11434/v1
export BFCL_PROJECT_ROOT=$HOME/Documents/GitHub/Others/bfcl/berkeley-function-call-leaderboard

受测模型

拉取命令和清单：

# 批量拉取所有测试模型
ollama pull qwen3:0.6b
ollama pull qwen3.5:0.8b
ollama pull lfm2.5-thinking:latest
ollama pull granite4:350m-h
ollama pull granite4:350m
ollama pull functiongemma:latest
ollama pull llama3.2:1b
ollama pull smollm2:135m
ollama pull smollm2:360m
ollama pull smollm2:1.7b
ollama pull gemma3:1b

模型完整规格：

模型	参数量	下载大小	量化	架构	上下文	能力标签
smollm2:135m	134.52M	258 MB	F16	SmolLM2	8K	completion
functiongemma:latest	268.10M	287 MB	Q8_0	Gemma	—	completion, tools
granite4:350m-h	340.33M	349 MB	Q8_0	GraniteHybrid	1,048,576	completion, tools
qwen3:0.6b	751.63M	498 MB	Q4_K_M	Qwen3	40,960	completion, tools, thinking
granite4:350m	352.38M	676 MB	BF16	Granite	32,768	completion, tools
smollm2:360m	361.82M	692 MB	F16	SmolLM2	8K	completion
lfm2.5-thinking:latest	1.2B	697 MB	Q4_K_M	LFM-2.5	128,000	completion, tools, thinking
gemma3:1b	999.89M	778 MB	Q4_K_M	Gemma3	—	completion
qwen3.5:0.8b	873.44M	988 MB	Q8_0	Qwen3.5	262,144	vision, completion, tools, thinking
llama3.2:1b	1.2B	1,260 MB	Q8_0	Llama3.2	131,072	completion, tools
smollm2:1.7b	1.7B	1,736 MB	Q8_0	SmolLM2	8K	completion, tools

注：部分模型未标注上下文长度（显示为 0 或 —），表示 Ollama 未从模型元数据中读取到该信息。gemma3:1b 实际上下文为 32K（架构默认）。functiongemma 使用了 Gemma 的指令微调模板。

测试代码

评测脚本使用 Ollama 原生 tools 接口（对有 tools 能力的模型）和 /api/generate 普通文本模式（对无 tools 能力的模型），所有调用 temperature=0。

import requests, json, time, re

OLLAMA = "http://localhost:11434"

TOOLS = {
    "get_weather": {"type":"function","function":{"name":"get_weather",
        "description":"Get current weather / 查询城市天气",
        "parameters":{"type":"object",
            "properties":{"city":{"type":"string","description":"City name"},
                          "unit":{"type":"string","enum":["celsius","fahrenheit"]}},
            "required":["city"]}}},
    "get_time": {"type":"function","function":{"name":"get_time",
        "description":"Get current time for timezone / 获取时区时间",
        "parameters":{"type":"object",
            "properties":{"timezone":{"type":"string","description":"e.g. Asia/Shanghai"}},
            "required":["timezone"]}}},
    "search": {"type":"function","function":{"name":"search",
        "description":"Search information / 搜索信息",
        "parameters":{"type":"object",
            "properties":{"query":{"type":"string"},"limit":{"type":"integer"}},
            "required":["query"]}}},
    "send_email": {"type":"function","function":{"name":"send_email",
        "description":"Send email / 发送邮件",
        "parameters":{"type":"object",
            "properties":{"to":{"type":"string"},"subject":{"type":"string"},"body":{"type":"string"}},
            "required":["to","subject","body"]}}},
    "calculate": {"type":"function","function":{"name":"calculate",
        "description":"Math calculation / 数学计算",
        "parameters":{"type":"object",
            "properties":{"expression":{"type":"string","description":"e.g. '2+3*4'"}},
            "required":["expression"]}}},
    "translate": {"type":"function","function":{"name":"translate",
        "description":"Translate text / 翻译",
        "parameters":{"type":"object",
            "properties":{"text":{"type":"string"},"target_lang":{"type":"string"}},
            "required":["text","target_lang"]}}},
    "get_stock": {"type":"function","function":{"name":"get_stock",
        "description":"Get stock price / 获取股价",
        "parameters":{"type":"object",
            "properties":{"symbol":{"type":"string","description":"Ticker e.g. AAPL"}},
            "required":["symbol"]}}},
    "book_restaurant": {"type":"function","function":{"name":"book_restaurant",
        "description":"Book restaurant / 预订餐厅",
        "parameters":{"type":"object",
            "properties":{"restaurant":{"type":"string"},"date":{"type":"string"},
                          "time":{"type":"string"},"guests":{"type":"integer"}},
            "required":["restaurant","date","time","guests"]}}},
    "get_flight": {"type":"function","function":{"name":"get_flight",
        "description":"Search flights / 查询航班",
        "parameters":{"type":"object",
            "properties":{"origin":{"type":"string"},"destination":{"type":"string"},"date":{"type":"string"}},
            "required":["origin","destination","date"]}}},
    "get_order": {"type":"function","function":{"name":"get_order",
        "description":"Look up order / 查询订单",
        "parameters":{"type":"object",
            "properties":{"order_id":{"type":"string","description":"Order ID"}},
            "required":["order_id"]}}},
}

# 测试用例定义 — 23 个用例 × 2 语言 = 46 个测试/模型
TEST_CASES = [
    # === BFCL simple (6 cases) ===
    {"id":"s01","cat":"simple","desc":"weather by city",
     "en":"What's the weather in Beijing?","zh":"北京今天天气怎么样？",
     "tools":["get_weather"],"expect":[{"tool":"get_weather","args":{"city":"Beijing"}}]},
    {"id":"s02","cat":"simple","desc":"with optional param",
     "en":"Check weather in Tokyo, use Fahrenheit.","zh":"用华氏度查东京天气。",
     "tools":["get_weather"],"expect":[{"tool":"get_weather","args":{"city":"Tokyo","unit":"fahrenheit"}}]},
    {"id":"s03","cat":"simple","desc":"math calculation",
     "en":"Calculate (15 + 27) * 3.","zh":"帮我算一下 (15 + 27) * 3。",
     "tools":["calculate"],"expect":[{"tool":"calculate","args":{"expression":"(15 + 27) * 3"}}]},
    {"id":"s04","cat":"simple","desc":"stock lookup",
     "en":"What's the current price of AAPL?","zh":"查一下茅台股票的价格。",
     "tools":["get_stock"],"expect":[{"tool":"get_stock","args":{"symbol":"AAPL"}}]},
    {"id":"s05","cat":"simple","desc":"flight search",
     "en":"Find flights from SFO to JFK on 2026-09-01.","zh":"查北京到上海航班，9月1日。",
     "tools":["get_flight"],"expect":[{"tool":"get_flight","args":{"origin":"SFO","destination":"JFK","date":"2026-09-01"}}]},
    {"id":"s06","cat":"simple","desc":"order lookup",
     "en":"Look up order #ORD-12345.","zh":"查订单号 ORD-12345。",
     "tools":["get_order"],"expect":[{"tool":"get_order","args":{"order_id":"ORD-12345"}}]},

    # === BFCL parallel (4 cases) ===
    {"id":"p01","cat":"parallel","desc":"two cities weather",
     "en":"Weather in Paris and London?","zh":"同时查巴黎和伦敦天气。",
     "tools":["get_weather"],"expect":[{"tool":"get_weather","args":{"city":"Paris"}},{"tool":"get_weather","args":{"city":"London"}}]},
    {"id":"p02","cat":"parallel","desc":"weather + time",
     "en":"Tell me Tokyo weather and New York time.","zh":"告诉我东京天气和纽约时间。",
     "tools":["get_weather","get_time"],"expect":[{"tool":"get_weather","args":{"city":"Tokyo"}},{"tool":"get_time","args":{"timezone":"America/New_York"}}]},
    {"id":"p03","cat":"parallel","desc":"stock + search",
     "en":"Get NVDA stock price and search for NVIDIA news.","zh":"查NVDA股价同时搜NVIDIA新闻。",
     "tools":["get_stock","search"],"expect":[{"tool":"get_stock","args":{"symbol":"NVDA"}},{"tool":"search","args":{"query":"NVIDIA"}}]},
    {"id":"p04","cat":"parallel","desc":"three tools",
     "en":"Weather in Shanghai, time in Tokyo, search AI news.","zh":"同时查上海天气、东京时间、搜AI新闻。",
     "tools":["get_weather","get_time","search"],"expect":[{"tool":"get_weather","args":{"city":"Shanghai"}},{"tool":"get_time","args":{"timezone":"Asia/Tokyo"}},{"tool":"search","args":{"query":"AI"}}]},

    # === BFCL tool_selection (4 cases) ===
    {"id":"m01","cat":"tool_selection","desc":"time over weather/news",
     "en":"What time is it in London?","zh":"伦敦现在几点了？",
     "tools":["get_weather","get_time","search"],"expect":[{"tool":"get_time","args":{"timezone":"Europe/London"}}]},
    {"id":"m02","cat":"tool_selection","desc":"stock over weather/time",
     "en":"What's the current price of TSLA?","zh":"查一下特斯拉股价。",
     "tools":["get_weather","get_time","get_stock"],"expect":[{"tool":"get_stock","args":{"symbol":"TSLA"}}]},
    {"id":"m03","cat":"tool_selection","desc":"email (complex params)",
     "en":"Send email to fred@test.com, subject 'Meeting', body 'Room 301 at 3pm'.","zh":"给fred@test.com发邮件，主题会议，内容下午三点301。",
     "tools":["get_weather","send_email","calculate","search"],"expect":[{"tool":"send_email","args":{"to":"fred@test.com","subject":"Meeting","body":"Room 301 at 3pm"}}]},
    {"id":"m04","cat":"tool_selection","desc":"flight among 5 tools",
     "en":"Book a flight from SFO to JFK on 2026-08-20.","zh":"订8月20日北京到上海机票。",
     "tools":["get_weather","get_time","search","get_stock","get_flight"],"expect":[{"tool":"get_flight","args":{"origin":"SFO","destination":"JFK","date":"2026-08-20"}}]},

    # === BFCL irrelevant (2 cases) ===
    {"id":"i01","cat":"irrelevant","desc":"book among 8 tools",
     "en":"Book a table for 4 at Chez Panisse on 2026-08-15 at 7pm.","zh":"在鼎泰丰预订8月15日晚7点，4位。",
     "tools":["get_weather","get_time","search","send_email","calculate","translate","get_stock","book_restaurant"],
     "expect":[{"tool":"book_restaurant","args":{"restaurant":"Chez Panisse","date":"2026-08-15","time":"19:00","guests":4}}]},
    {"id":"i02","cat":"irrelevant","desc":"calc among 7 tools",
     "en":"What is 12345 * 67890?","zh":"12345乘以67890是多少？",
     "tools":["get_weather","get_time","search","send_email","translate","get_stock","book_restaurant","calculate"],
     "expect":[{"tool":"calculate","args":{"expression":"12345 * 67890"}}]},

    # === BFCL multi_turn (2 cases) ===
    {"id":"t01","cat":"multi_turn","desc":"translate then email","ordered":True,
     "en":"Translate 'Hello, how are you?' to Chinese, then email to test@example.com subject 'Translation'.",
     "zh":"把'Hello, how are you?'翻译成中文，发邮件给test@example.com，主题翻译结果。",
     "tools":["translate","send_email"],"expect":[{"tool":"translate","args":{"text":"Hello, how are you?","target_lang":"zh"}},{"tool":"send_email","args":{"to":"test@example.com","subject":"Translation"}}]},
    {"id":"t02","cat":"multi_turn","desc":"weather→translate→email","ordered":True,
     "en":"Get Shanghai weather, translate to Japanese, email to info@example.com.","zh":"查上海天气，翻译成日语，发邮件给info@example.com。",
     "tools":["get_weather","translate","send_email"],"expect":[{"tool":"get_weather","args":{"city":"Shanghai"}},{"tool":"translate","args":{"target_lang":"ja"}},{"tool":"send_email","args":{"to":"info@example.com"}}]},

    # === τ-bench airline / retail (2 cases) ===
    {"id":"a01","cat":"tau_airline","desc":"search flight",
     "en":"I need to fly from Boston to Chicago on August 25.","zh":"我需要8月25日从广州飞北京。",
     "tools":["get_flight"],"expect":[{"tool":"get_flight","args":{"origin":"Boston","destination":"Chicago","date":"2026-08-25"}}]},
    {"id":"r01","cat":"tau_retail","desc":"order lookup + email","ordered":True,
     "en":"Look up order ORD-99887 and email status to me@example.com.","zh":"查订单ORD-99887，发邮件给me@example.com。",
     "tools":["get_order","send_email"],"expect":[{"tool":"get_order","args":{"order_id":"ORD-99887"}},{"tool":"send_email","args":{"to":"me@example.com"}}]},

    # === edge cases (3 cases) ===
    {"id":"e01","cat":"edge","desc":"no tool needed (chitchat)",
     "en":"Hello! How are you today?","zh":"你好！今天怎么样？",
     "tools":["get_weather","calculate"],"expect":[]},
    {"id":"e02","cat":"edge","desc":"ambiguous (no city)",
     "en":"What's the temperature? It's so hot here.","zh":"现在多少度？这儿热死了。",
     "tools":["get_weather"],"expect":[]},
    {"id":"e03","cat":"edge","desc":"mixed EN/ZH params",
     "en":"search news about AI safety, limit 3.","zh":"搜索AI安全新闻，要3条。",
     "tools":["search"],"expect":[{"tool":"search","args":{"query":"AI safety","limit":3}}]},
]


def call_native(model, prompt, tool_names):
    tools = [TOOLS[n] for n in tool_names]
    r = requests.post(f"{OLLAMA}/api/chat", json={
        "model": model, "messages":[{"role":"user","content":prompt}],
        "tools": tools, "stream": False, "options":{"temperature":0}}, timeout=180)
    msg = r.json().get("message", {})
    return [{"tool": tc["function"]["name"], "arguments": tc["function"]["arguments"]}
            for tc in msg.get("tool_calls", [])]

def call_prompt(model, prompt, tool_names):
    descs = []
    for n in tool_names:
        t = TOOLS[n]["function"]; ps = t["parameters"]["properties"]
        req = t["parameters"].get("required",[])
        lines = [f"{k}: {p['type']}{' (required)' if k in req else ''}" for k,p in ps.items()]
        descs.append(f"## {n}\n{t['description']}\n" + "\n".join(f"  {l}" for l in lines))
    full = f"Tools:\n" + "\n\n".join(descs) + f"\n\nOutput JSON array:\n[{{\"tool\":\"name\",\"arguments\":{{}}}}]\n\nUser: {prompt}\nAssistant:"
    r = requests.post(f"{OLLAMA}/api/generate", json={
        "model":model,"prompt":full,"stream":False,"options":{"temperature":0,"num_predict":1024}}, timeout=180)
    text = r.json()["response"].strip()
    text = re.sub(r'^```(?:json)?\s*','',text); text = re.sub(r'\s*```$','',text)
    try:
        d = json.loads(text)
        return d if isinstance(d,list) else ([d] if isinstance(d,dict) else [])
    except:
        m = re.search(r'\[[\s\S]*\]', text)
        return json.loads(m.group()) if m else []

def score_test(expected, actual):
    ne, na = len(expected), len(actual)
    if ne == 0: return 1.0 if na == 0 else 0.0
    if na == 0: return 0.0
    matched = 0
    used = set()
    for exp in expected:
        for j, act in enumerate(actual):
            if j in used: continue
            if exp["tool"] == act.get("tool",""):
                ok = all(str(exp["arguments"].get(k,"")).lower() in str(act.get("arguments",{}).get(k,"")).lower()
                        for k in exp["arguments"])
                if ok: used.add(j); matched += 1; break
    return matched / ne


def run_all():
    models = ["granite4:350m-h","granite4:350m","qwen3:0.6b","qwen3.5:0.8b",
              "lfm2.5-thinking:latest","functiongemma:latest","llama3.2:1b",
              "smollm2:135m","smollm2:360m","smollm2:1.7b","gemma3:1b"]
    has_tools = {"functiongemma:latest","granite4:350m-h","qwen3:0.6b",
                 "granite4:350m","lfm2.5-thinking:latest","qwen3.5:0.8b",
                 "llama3.2:1b","smollm2:1.7b"}

    for model in models:
        fn = call_native if model in has_tools else call_prompt
        results = []
        for tc in TEST_CASES:
            for lang, prompt in [("EN",tc["en"]),("ZH",tc["zh"])]:
                try:
                    calls = fn(model, prompt, tc["tools"])
                    score = score_test(tc["expect"], calls)
                except Exception as e:
                    score = 0.0
                results.append({"id":f"{tc['id']}_{lang}","cat":tc["cat"],
                                "lang":lang,"score":score,"actual":calls if 'calls' in dir() else []})
        # 汇总
        en = [r for r in results if r["lang"]=="EN"]
        zh = [r for r in results if r["lang"]=="ZH"]
        en_pass = sum(1 for r in en if r["score"]>=0.5)/len(en)
        zh_pass = sum(1 for r in zh if r["score"]>=0.5)/len(zh)
        print(f"{model}: pass={sum(1 for r in results if r['score']>=0.5)}/{len(results)} "
              f"EN={en_pass:.1%} ZH={zh_pass:.1%}")

if __name__ == "__main__":
    run_all()

完整评测脚本（含结果输出、分类汇总、JSON 导出）约 500 行，可在 scripts/ollama_full_benchmark.py 查看。

评测结果

总榜

共 11 个模型，每个模型 46 个测试（23 用例 × 2 语言），总计 506 个测试。

模型	大小	模式	通过率	均分	EN	ZH	耗时
lfm2.5-thinking	697 MB	tools	76.1%	0.74	95.7%	56.5%	668s
smollm2:1.7b	1,736 MB	tools	76.1%	0.73	87.0%	65.2%	194s
granite4:350m-h	349 MB	tools	67.4%	0.64	78.3%	56.5%	60s
qwen3.5:0.8b	988 MB	tools	63.0%	0.61	82.6%	43.5%	370s
qwen3:0.6b	498 MB	tools	56.5%	0.54	78.3%	34.8%	220s
granite4:350m	676 MB	tools	54.3%	0.54	73.9%	34.8%	41s
llama3.2:1b	1,260 MB	tools	34.8%	0.30	43.5%	26.1%	97s
functiongemma	287 MB	tools	17.4%	0.17	26.1%	8.7%	106s
smollm2:360m	692 MB	文本	13.0%	0.13	17.4%	8.7%	41s
smollm2:135m	258 MB	文本	0.0%	0.00	0.0%	0.0%	15s
gemma3:1b	778 MB	文本	0.0%	0.00	0.0%	0.0%	27s

注：标注 "文本" 的模型未在 Ollama 中注册原生 tools 能力，因此通过普通文本模式进行评测。由于普通文本模式对小模型更加困难，这些模型的得分下限更低。

分类别得分

模型	simple	parallel	tool_sel	irrelevant	multi_turn	tau_retail	edge
lfm2.5-thinking	0.75	1.00	0.75	0.75	0.38	0.75	0.83
smollm2:1.7b	0.75	0.94	0.75	0.50	0.88	0.75	0.67
granite4:350m-h	0.83	0.77	0.75	0.50	0.79	0.50	0.17
qwen3.5:0.8b	0.67	0.83	0.62	0.75	0.29	0.50	0.50
qwen3:0.6b	0.42	0.67	0.38	0.50	0.71	0.75	0.83
granite4:350m	0.58	0.65	0.50	0.50	0.42	1.00	0.50
llama3.2:1b	0.50	0.46	0.00	0.50	0.38	0.25	0.00
functiongemma	0.08	0.29	0.12	0.00	0.00	0.25	0.50
smollm2:360m	0.33	0.12	0.00	0.00	0.00	0.50	0.00
gemma3:1b	0.00	0.00	0.00	0.00	0.00	0.00	0.00
smollm2:135m	0.00	0.00	0.00	0.00	0.00	0.00	0.00

tau_airline 维度全部为 0.00——这是因为该测试用例包含 "I need to fly from Boston to Chicago on August 25" 这一真实航线查询，Ollama 的小模型对此类真实世界地理知识的推理能力为零，因此无法正确填充航班查询参数。

深入分析

1. lfm2.5-thinking — 慢但准，英文天花板

英文通过率 95.7%，几乎全对。它是一个带思维链（thinking）机制的 1.2B 模型，在正确的 prompt 下可以将工具调用分解为思考→行动两步。并行调用三个工具满分的表现尤其亮眼。

弱点： - 中文 56.5%，与英文差距 39 个百分点 - 多步串行只有 0.38（比其他维度明显低），把"翻译→发邮件"这类需要保持上下文的链式任务搞错了步骤 - 速度是 granite4:350m-h 的 10 倍以上（668s vs 60s）

2. smollm2:1.7b — 最强但最重

多轮串行 0.88 是所有模型中唯一的接近满分。它最能理解"先做 A 再用 A 的结果做 B"这种依赖关系。但 1.7GB 的体积已经远超 1GB 目标，更适合有独立 GPU 的场景。

3. granite4:350m-h — 体积最小中的最强

349 MB 能做到 67.4% 通过率。简单调用 0.83、多轮串行 0.79，这两个维度都在前三。中文 56.5% 和 lfm2.5 持平，说明它的中文对齐做得不错。1M 的上下文长度更是所有模型里最大的——虽然小模型很难真正用到这么长的上下文。

4. granite4 的标准版与 H 版的架构差异

需要重点说明：标记为 -h 的版本和普通版并不是同一模型的不同量化——它们是两种不同的模型架构。

属性	granite4:350m-h	granite4:350m
参数量	340.33M	352.38M
架构	granitehybrid	granite
上下文	1,048,576 (1M)	32,768 (32K)
量化	Q8_0	BF16
下载大小	349 MB	676 MB
embedding 维度	768	1024

这两个版本来自 IBM Granite 系列的两个不同分支： - granite4:350m 是标准的 Dense Transformer（密集注意力）架构； - granite4:350m-h（-h = hybrid）是混合架构，在 Transformer 基础上融合了状态空间模型（SSM），参数更少、上下文更长（1M token）、推理更高效。

在脚本评测中，hybrid 版的通过率 67.4% 明显高于标准版的 54.3%（+13pp）。而 hybrid 版用的是 Q8_0 量化、标准版用的是 BF16 全精度——反而更小更准。这说明两件事：一是 IBM 的 hybrid 架构在工具调用场景下显著优于同体量的 Dense Transformer；二是 Q8 级别的量化对工具调用几乎不造成可感知的精度损失，压缩带来的收益远大于代价。

5. 无 tools 能力的模型几乎不可用

smollm2:135m、gemma3:1b 通过了 0 个测试。它们的普通文本模式下要么不返回 JSON，要么返回无法解析的格式。smollm2:360m 勉强通过了 6 个测试（13%），这几个都是简单查股票、查订单的单步调用。结论很明确：如果你想用本地小模型做工具调用，必须选在 Ollama 中标注了 tools 能力的模型。

6. 中英文差距

所有模型的英文通过率都明显高于中文。差距最大的： - lfm2.5-thinking: 95.7% → 56.5%（↓39pp） - qwen3.5:0.8b: 82.6% → 43.5%（↓39pp） - qwen3:0.6b: 78.3% → 34.8%（↓43pp）

即使是被认为"中英文都训练过"的 Qwen 系列，中文工具调用也比英文差很多。这说明当前小模型的工具调用能力主要来自英文训练数据，中文只是指令翻译的副产物。

7. 速度对比

从快到慢： - granite4:350m（BF16, 41s）— 最快，但准确率最低 - granite4:350m-h（Q8_0, 60s）— 快且准 - llama3.2:1b（97s）— 中等 - functiongemma（106s）— 慢但不准 - smollm2:1.7b（194s）— 偏慢但准 - qwen3:0.6b（220s）— 偏慢 - qwen3.5:0.8b（370s）— 很慢 - lfm2.5-thinking（668s）— 极慢但最准

thinking 机制的代价就是推理时间。lfm2.5 的每个测试平均花费 14.5 秒，而 granite4:350m-h 只需要 1.3 秒。

BFCL 官方评测验证

上一节的脚本评测覆盖了全部 11 个模型 × 8 个维度 × 2 种语言（506 个测试），但评分逻辑用的是字符串包含匹配，精度不如 BFCL 官方的 AST 解析 + 类型检查 + 标准化值匹配。为了校准结果，用 BFCL 官方管线（bfcl generate → bfcl evaluate）对 8 个能走原生 tools API 的模型跑了 25 个抽样测试用例，simple_python 看能不能正确调一个函数、irrelevance 看能不能识别什么时候不该调、parallel 看能不能同时调多个：

conda activate llmbench
export BFCL_PROJECT_ROOT=$HOME/Documents/GitHub/Others/bfcl/berkeley-function-call-leaderboard
export OPENAI_API_KEY=ollama
export OPENAI_BASE_URL=http://localhost:11434/v1

# 为 Ollama 模型注册 handler（已在 model_config.py 中完成）

# 抽样测试：每个模型跑 simple_python + parallel + irrelevance 共 25 个用例
bfcl generate --model ollama-qwen3-0.6b-FC \
  --test-category simple_python,irrelevance,parallel \
  --run-ids --num-threads 5

bfcl evaluate --model ollama-qwen3-0.6b-FC \
  --test-category simple_python,irrelevance,parallel --partial-eval

BFCL 官方评分结果（25 个抽样测试 × 8 个模型）：

模型	irrelevance	parallel	simple_python
qwen3:0.6b	100%	40%	40%
lfm2.5-thinking	100%	60%	30%
functiongemma	100%	0%	20%
granite4:350m-h	80%	20%	30%
granite4:350m	80%	60%	30%
smollm2:1.7b	80%	40%	50%
qwen3.5:0.8b	30%	40%	30%
llama3.2:1b	0%	0%	0%

BFCL vs 脚本评测的差异

llama3.2:1b 在 BFCL 中全挂（0%）但在脚本评测中有 34.8%。 原因是 BFCL 的 AST 解码器要求模型输出严格的 [{func_name: {params}}] 格式，而 llama3.2:1b 输出的工具调用 JSON 不符合这个特定格式。Ollama 的 /api/chat 原生的 tool_calls 字段是 OpenAI 格式的 [{id, type, function: {name, arguments}}]，两者不兼容。脚本评测直接取了 Ollama 返回的结构化字段，所以不会遇到格式问题；BFCL 要求解码原始文本，llama3.2:1b 在这个环节就失败了。

irrelevance 在 BFCL 中普遍高于脚本评测。 irrelevance 的脚本定义是"输出空列表或纯文本即为正确"，BFCL 也类似——只要模型没返回有效函数调用格式就算过。小模型的默认行为就是闲聊而不是调工具，所以 irrelevance 天然高分。

simple_python 在两套评测中趋势一致：smollm2:1.7b 最高（50%），llama3.2:1b 最差（0%）。

结论：脚本评测的排名顺序和 BFCL 官方大致一致，但绝对分数有系统性差异——BFCL 更严格（AST 解析 + 精确类型匹配），脚本评测更宽松（字符串包含）。对于选型决策来说，排名比绝对分数更重要，而两边的排名基本吻合。

总结

BFCL 官方 strict 模式性价比最优：granite4:350m-h（349MB，irr 80%/par 20%/simp 30%）
BFCL 官方 simple_python 最高：smollm2:1.7b（50%，但 1.7GB 太胖）
中文相对最好：脚本评测中 smollm2:1.7b 中文 65%，qwen3:0.6b 中文多轮串行较强
工具调用必须原生支持 tools：普通文本模式的小模型在脚本评测中基本不可用，BFCL 也不支持普通文本模式评测
hybrid 架构在工具调用上优于 Dense Transformer：granite4:350m-h（hybrid，349MB，Q8_0）比 granite4:350m（dense，676MB，BF16）在脚本评测中高 13pp。不同架构差异远超量化精度差异，Q8 量化对工具调用的影响几乎不可感知
BFCL AST 格式兼容性是门槛：llama3.2:1b 在脚本评测中有 34.8% 但在 BFCL 中是 0%，因为它输出的 tool_call JSON 格式与 BFCL 的 [{func: {params}}] 解码器不兼容。实际使用 Ollama 原生 tools API 不受此影响

349MB 的 granite4:350m-h 在 BFCL 官方和脚本评测两套评测中都表现靠前。对于"在配置不高的机器上跑一个有工具调用能力的本地模型"这个需求来说，这是目前比较务实的选择。

与 GPT-3.5 的全面能力对比

工具调用之外，还做了一个更宏观的对比：这些本地小模型和当初的 GPT-3.5 相比，综合能力能到多少？选了 6 个标准化基准，每个基准 60 题，覆盖知识、代码、数学、推理四个维度。GPT-3.5 的成绩来自 GPT-4 技术报告 Table 2（arXiv:2303.08774）。

评测基准与 GPT-3.5 参考成绩

基准	维度	GPT-3.5 成绩	测试方式
MMLU	多任务知识	70.0%	5-shot
HumanEval	代码生成	48.1%	pass@1, 0-shot
GSM8K	小学数学	57.1%	5-shot
HellaSwag	常识推理	85.5%	10-shot
ARC	科学推理	85.2%	25-shot
WinoGrande	语义推理	81.6%	5-shot

数据集来源：MMLU（HuggingFace cais/mmlu，14042 题）、HumanEval（GitHub openai/human-eval，164 题）、GSM8K（GitHub openai/grade-school-math，1319 题）、HellaSwag（GitHub rowanz/hellaswag，10042 题）、ARC（HuggingFace allenai/ai2_arc，1119 题）、WinoGrande（HuggingFace allenai/winogrande，40398 题）。每个基准均匀采样 60 题，temperature=0，使用 Ollama generate API 补全模式。

全量结果（60 题/基准）

模型	大小	MMLU	HumanEval	GSM8K	HellaSwag	ARC	WinoGrande	平均比值
GPT-3.5	—	70.0%	48.1%	57.1%	85.5%	85.2%	81.6%	100%
qwen3.5:9b	8.9 GB	63.2% (90%)	55.0% (114%)	91.7% (161%)	76.7% (90%)	86.7% (102%)	91.7% (112%)	95%
omnicoder-2-9b	5.7 GB	19.3% (28%)	90.0% (187%)	70.0% (123%)	28.3% (33%)	26.7% (31%)	46.7% (57%)	76%
granite4:350m-h	349 MB	42.1% (60%)	60.0% (125%)	21.7% (38%)	28.3% (33%)	21.7% (25%)	56.7% (69%)	58%
qwen3.5:0.8b	1.2 GB	15.8% (23%)	43.3% (90%)	56.7% (99%)	30.0% (35%)	60.0% (70%)	40.0% (49%)	51%
lfm2.5-thinking	697 MB	31.6% (45%)	25.0% (52%)	41.7% (73%)	30.0% (35%)	15.0% (18%)	40.0% (49%)	45%
lfm2.5-350m	379 MB	28.1% (40%)	13.3% (28%)	10.0% (18%)	26.7% (31%)	48.3% (57%)	38.3% (47%)	37%

括号内为相对 GPT-3.5 的能力比值。平均比值为六维度比值的算术平均。

逐模型分析

qwen3.5:9b — 已全面达到 GPT-3.5 水平（平均 95%）

这个 8.9GB 的模型在四个维度上已经超过 GPT-3.5：GSM8K 91.7% vs 57.1%（161%），HumanEval 55.0% vs 48.1%（114%），ARC 86.7% vs 85.2%（102%），WinoGrande 91.7% vs 81.6%（112%）。MMLU 63.2% 略低于 70.0%，HellaSwag 76.7% 略低于 85.5%，但差距不大。如果 2023 年 GPT-3.5 是一个标杆，那 qwen3.5:9b 在 2026 年已经把它追平了——而且是在本地跑的。

omnicoder-2-9b — 代码和数学暴打 GPT-3.5，但通用知识几乎为零（平均 76%）

HumanEval 90.0% 对 GPT-3.5 的 48.1% 是 187%，GSM8K 70.0% 对 57.1% 是 123%。但 MMLU 只有 19.3%，HellaSwag 28.3%，ARC 26.7%——典型的代码专用模型，在非代码任务上能力塌方。如果你只需要写代码和解数学题，它比 GPT-3.5 强；但如果需要通用问答，它远不如。

granite4:350m-h — 349MB 的体积做到 GPT-3.5 的 58%（平均）

HumanEval 60.0% 超过 GPT-3.5 的 48.1%（125%），WinoGrande 56.7% 也达到了 69%。但数学只有 21.7%，HellaSwag 28.3%，ARC 21.7%——知识储备和推理能力受限。这个模型的价值在于体积小、速度快、代码能力突出，适合边缘部署。

qwen3.5:0.8b — 1.2GB 的小模型里最均衡（平均 51%）

GSM8K 56.7% 几乎追平 GPT-3.5 的 57.1%（99%），ARC 60.0% 达到 70%，HumanEval 43.3% 达到 90%。MMLU 偏低（15.8%），但其他维度都在 GPT-3.5 的一半以上。综合来看是 1GB 级别模型里最接近 GPT-3.5 的。

lfm2.5-thinking — 思维链在数学上有用，但拖累代码（平均 45%）

GSM8K 41.7% 是几个小模型里相对较好的，思维链机制确实帮助了数学推理。但 HumanEval 只有 25.0%——思维链输出太长，干扰了代码补全。ARC 只有 15.0% 是所有模型最低的。

lfm2.5-350m — 最轻量但能力有限（平均 37%）

379MB 的体积在所有模型中最小，但能力也是最低的。GSM8K 只有 10.0%，HumanEval 13.3%。不过 ARC 48.3% 达到了 GPT-3.5 的 57%，说明它在科学推理上有一定基础。

几个观察

体积差 25 倍，能力差不到 2 倍：granite4:350m-h（349MB）平均 58% of GPT-3.5，qwen3.5:9b（8.9GB）平均 95%。体积差了 25 倍，能力差不到 2 倍。小模型的性价比远超直觉。
代码能力超越 GPT-3.5 的门槛最低：granite4:350m-h 的 HumanEval 60% 就超过了 GPT-3.5 的 48.1%。代码生成是这些小模型最容易"以小博大"的维度——可能是因为代码训练数据质量高、模式重复性强。
数学能力两极分化：qwen3.5:9b 的 GSM8K 91.7% 远超 GPT-3.5，但 lfm2.5-350m 只有 10.0%。数学推理对模型参数量的要求比代码更高。
通用知识（MMLU）是最难追平 GPT-3.5 的维度：除了 qwen3.5:9b（63.2%），其他模型都在 42% 以下。MMLU 覆盖 57 个学科，需要广泛的知识储备，这是小模型的天然短板。
omnicoder 的偏科现象最极端：代码 187%、数学 123%，但 MMLU 28%、HellaSwag 33%。专用模型在训练时牺牲了通用能力来强化特定领域，使用时必须清楚它的边界。

编程语言全景：从诞生到2026年的完整图鉴

2026-08-08T20:00:00+08:00

编程语言对于不太熟悉的朋友来说可能觉得挺玄乎，其实说白了，就是人和机器之间说话的规矩。计算机用电路，底层来看，只认得0和1，人要是直接跟它唠0和1，实在是太麻烦，于是陆续有了汇编语言乃至C语言等等高级语言。于是后来场景变得复杂，这几十年里，一堆先驱者前赴后继，发明了各种语言，让"写程序"这件事，从最初的纸带打孔慢慢变成了打字，现在有了氛围编程，更是成了聊天对话。

这次把2026年这个时间点的主要编程语言，粗略整理一下来给大家看。数据按2026年8月算，榜单用的是TIOBE 2026年7月的，版本标到了各自最新的。

排行榜这种东西也就是参考就行，别太当真。

排名	语言	占比	同比变化
1	Python	18.94%	-6.91%
2	C	10.86%	+1.30%
3	C++	9.12%	-2.65%
4	Java	8.03%	-0.94%
5	C#	4.49%	+0.17%
6	JavaScript	2.72%	-0.17%
7	Visual Basic	2.48%	+0.59%
8	SQL	1.71%	+0.23%
9	R	1.69%	+0.30%
10	Rust	1.34%	+0.30%
11	Delphi/Object Pascal	1.29%	-0.60%
12	Scratch	1.27%	+0.27%
13	Go	1.17%	-1.08%
14	PHP	1.16%	-0.08%
15	Swift	0.99%	+0.27%
16	Ada	0.91%	—
17	Assembly language	0.81%	—
18	MATLAB	0.74%	—
19	Fortran	0.74%	—
20	Ruby	0.73%	—

第一梯队：统治级语言

Python

项目	信息
创建者	Guido van Rossum
诞生年份	1991年
当前版本	3.14.6（2026年6月10日）
范式	面向对象、函数式、过程式
类型系统	动态类型、强类型
学习难度	⭐（极易入门）
TIOBE排名	#1（18.94%）

Python现在是大模型的代名词，其实它1991年甚至更早点就出生了，是个叫Guido van Rossum的荷兰人搞的，这个语言的名字取自他喜欢的英剧《Monty Python》。最大的特点就是写起来像人话，强制缩进逼着你把代码排整齐，简单好上手是它常年霸榜新手第一语言的原因。AI、数据科学这块它基本是独一份，PyTorch、pandas这些全让他如虎添翼。

缺点是跑得慢，还有个GIL锁卡着多线程，真想并行挺费劲。好在3.14开始搞了free-threaded模式，等于把这顶帽子摘下来一半。

版本	年份	里程碑事件
0.9	1991	首次发布，受ABC语言启发
1.0	1994	函数式工具（lambda/map/filter）
2.0	2000	列表推导式、垃圾回收
2.7	2010	2.x最终版本，长期维护至2020年
3.0	2008	不向后兼容的大重构（print函数化、Unicode字符串）
3.6	2016	f-strings、类型注解
3.10	2021	结构化模式匹配（match-case）
3.11	2022	性能提升10-60%（ specializing adaptive interpreter）
3.12	2023	类型参数语法（PEP 695）、f-strings改进
3.13	2024	实验性free-threaded模式、JIT编译器
3.14	2025	PEP 779正式支持free-threaded、PEP 649延迟注解求值、PEP 784 compression.zstd模块、t-strings（PEP 750）

C

项目	信息
创建者	Dennis Ritchie
诞生年份	1972年（贝尔实验室）
当前标准	C23（2024年正式发布）
范式	过程式、结构化
类型系统	静态类型、弱类型
学习难度	⭐⭐⭐（中等偏高）
TIOBE排名	#2（10.86%）

C被叫做"一切之母"，不是没道理的。操作系统、编译器、数据库，往下挖到底基本都是C。手机Android系统所用的Linux内核、跑Python的那个解释器CPython，全是C写的。它简洁得吓人，关键字就那么几十个，从C89的32个到C23也就44个，但组合起来啥都能干。

代价是指针这玩意儿能把人折腾得厉害，一个不小心就内存泄漏、缓冲区溢出。系统级、嵌入式的活儿躲不开它，新手上来就学它确实苦，所以后来也有人在驱动开发等场景开始使用Rust了。

标准	年份	核心特性
K&R C	1978	Brian Kernighan与Dennis Ritchie合著的《The C Programming Language》定义的非正式标准
C89/C90	1989/1990	ANSI/ISO正式标准化，引入函数原型、void类型、const/volatile限定符、标准库
C95	1995	宽字符支持、国际化改进
C99	1999	//单行注释、inline函数、变长数组(VLA)、long long、stdint.h、指定初始化器
C11	2011	多线程支持(threads.h)、原子操作(stdatomic.h)、_Generic类型泛型、Unicode支持、匿名结构体/联合体
C17/C18	2018	C11的缺陷修复版，无新特性
C23	2024	bool/true/false成为关键字、#embed指令、auto类型推断、十进制浮点类型、移除K&R函数声明语法

C++

项目	信息
创建者	Bjarne Stroustrup
诞生年份	1985年（"C with Classes"始于1979年）
当前标准	C++23（已发布），C++26（2026年3月功能冻结）
范式	多范式（面向对象、泛型、函数式、过程式）
类型系统	静态类型、强类型
学习难度	⭐⭐⭐⭐⭐（极高）
TIOBE排名	#3（9.12%）

C++简单来看就是在C上面叠了一大堆东西：类、模板、异常、lambda……口号是"零开销抽象"，其实他的范式和C是几乎完全不同的，只是做到了对C的兼容，基本能手写达到C的一个性能。游戏引擎、高性能计算、量化交易这些死磕性能的地方，往往是它的地盘。

代价是这玩意儿复杂到没边，C++26的标准文档据说两千多页，学起来没个三五年都未必掌握了所有特性。学习难度拉满的榜上它常年前三，入坑前先做好心理准备，但是学好了确实很强大。

标准	年份	核心特性
C++98	1998	首个ISO标准，模板、异常处理、STL、命名空间
C++03	2003	技术修正版（TC1），修复缺陷
C++11	2011	auto、lambda、移动语义、右值引用、智能指针、constexpr、范围for、nullptr——"现代C++"的起点
C++14	2014	函数返回类型推断、泛型lambda、二进制字面量
C++17	2017	结构化绑定、optional/variant/any、文件系统库、并行算法
C++20	2020	概念(Concepts)、协程、模块、范围(Ranges)、三路比较运算符(<=>)——史上最大更新
C++23	2023	std::expected、std::print、std::span、多维下标运算符、flat_map
C++26	2026（功能冻结）	反射(Reflection)、契约(Contracts: pre/post/contract_assert)、std::execution senders/receivers——近年来最大的语言级新增

Java

项目	信息
创建者	James Gosling（Sun Microsystems）
诞生年份	1995年
当前版本	JDK 26（2026年3月，非LTS），JDK 25（2025年9月，当前LTS）
范式	面向对象、函数式（Java 8起）
类型系统	静态类型、强类型
学习难度	⭐⭐⭐（中等）
TIOBE排名	#4（8.03%）

Java 1995年出生，靠着一句"一次编写，到处运行"打天下，底气是JVM这层虚拟机，把原来的代码翻译成字节码，然后四处用自己的JVM虚拟机运行，比解释器的Python快，但比编译型的往往要慢一些。它最大的功劳是把自动垃圾回收带进了主流，让程序员告别了手动管内存的苦日子。银行、电商、企业后端，遍地都是它的存量，培训班井喷的时代带来了大量的人力资源积累，成本卷到很低了，加上业务存留，估计一时半会儿倒不了。

相对慢、吃内存，这些年靠虚拟线程、值类型这些项目憋着劲儿但恐怕也难翻盘。排名虽然跌到历史最低，但企业里那堆老系统还得靠它撑着。

版本	年份	里程碑
JDK 1.0	1996	首次发布
JDK 1.1	1997	内部类、JDBC、JavaBeans
J2SE 1.2	1998	Swing、集合框架、JIT编译器
J2SE 1.4	2002	断言、NIO、正则表达式
Java 5	2004	泛型、注解、枚举、增强for循环、自动装箱
Java 8	2014	Lambda表达式、Stream API、Optional、新的日期时间API——史上最重要更新
Java 9	2017	模块化系统(JPMS)、REPL(jshell)
Java 11	2018	LTS，var局部变量推断、HTTP Client
Java 17	2021	LTS，密封类、记录类(Records)、模式匹配预览
Java 21	2023	LTS，虚拟线程正式发布、模式匹配开关、记录模式
Java 25	2025	当前LTS，性能增强、模式匹配改进、虚拟线程改进
Java 26	2026	非LTS，HTTP/3支持(JEP 517)、AOT对象缓存(JEP 516)、结构化并发第6次预览

C

项目	信息
创建者	Anders Hejlsberg（Microsoft）
诞生年份	2000年
当前版本	C# 14（.NET 10）
范式	多范式（面向对象、函数式、声明式）
类型系统	静态类型、强类型
学习难度	⭐⭐⭐（中等）
TIOBE排名	#5（4.49%）

C#是微软出的，不要读作C井，是C-sharp。当年就是个"改良版Java"，在.NET平台上跑。后来一路演化，现在语法上比Java时髦多了，LINQ、async/await、记录类型、模式匹配这些全都有，算是最现代化的主流静态语言之一。.NET Core之后也彻底跨了平台，不再被Windows绑死。

Unity游戏开发、Windows桌面、ASP.NET后端，都是它的地盘。你要是喜欢一套语法干多个方向，它挺合适。

版本	年份	关键特性
C# 1.0	2002	基础面向对象，与.NET Framework 1.0同步
C# 2.0	2005	泛型、迭代器、可空类型、匿名方法
C# 3.0	2007	LINQ、Lambda、扩展方法、匿名类型——革命性更新
C# 4.0	2010	动态类型(dynamic)、命名参数、协变/逆变
C# 5.0	2012	async/await异步编程——改变异步编程范式
C# 6.0	2015	字符串插值、空条件运算符、表达式体成员
C# 7.0-7.3	2017-2018	模式匹配、元组、局部函数、Span
C# 8.0	2019	可空引用类型、异步流、范围和索引
C# 9.0	2020	记录类型、顶级语句、init访问器
C# 10.0	2021	全局using、文件范围命名空间、record struct
C# 11.0	2022	原始字符串、列表模式、required成员
C# 12.0	2023	主构造函数、集合表达式、内联数组
C# 13.0	2024	params集合、扩展类型成员、ref struct改进
C# 14.0	2025	扩展属性、 nameof增强、未初始化结构体警告改进

JavaScript

项目	信息
创建者	Brendan Eich（Netscape）
诞生年份	1995年（10天内完成原型）
当前标准	ECMAScript 2025（ES2025）
范式	多范式（面向对象原型链、函数式、事件驱动）
类型系统	动态类型、弱类型
学习难度	⭐⭐（入门容易，精通难）
TIOBE排名	#6（2.72%）

JavaScript是1995年那阵子赶出来的，当时似乎就是给网页加加点小花活。没想到后来成了全世界浏览器的唯一亲儿子，你打开的每个网页里都有它。ES6之后它现代了不少，Node.js又把它带到了服务器端，现在前后端、桌面、移动哪哪都是它。

JS的问题是入门容易，写好难，动态类型加原型链，水是真的深，安全性动不动被人埋雷，而且写不好也会特别慢。好在后面那个TypeScript出来给提升了性能。

版本	年份	关键特性
ES1	1997	首个ECMA标准
ES3	1999	正则表达式、try/catch
ES5	2009	严格模式、JSON、数组方法forEach/map/filter
ES6/ES2015	2015	let/const、箭头函数、Promise、class、模块(import/export)、解构、模板字符串、Map/Set——现代JS的起点
ES2016-2019	2016-2019	Array.includes、async/await、Object.entries、可选catch绑定
ES2020	2020	可选链(?.)、空合并(??)、BigInt、动态import()
ES2021	2021	逻辑赋值、String.replaceAll、Promise.any
ES2022	2022	Top-level await、类字段、at()方法
ES2023	2023	数组从后查找(findLast)、Hashbang语法
ES2024	2024	Promise.withResolvers、Object.groupBy
ES2025	2025	Set方法（union/intersection/difference）、Iterator Helpers、Promise.try

第二梯队：系统与安全语言

看完几位一线明星，再往下数，是一帮系统和安全方向的狠角色。

Go（Golang）

项目	信息
创建者	Robert Griesemer、Rob Pike、Ken Thompson（Google）
诞生年份	2009年
当前版本	1.27（2026年6月）
范式	过程式、并发
类型系统	静态类型、强类型
学习难度	⭐⭐（低，语法极简）
TIOBE排名	#13（1.17%）

Go是Google出的，三个带佬一起设计，其中一个还是Unix之父Ken Thompson。它的哲学就俩字：简单。25个关键字，语法一天就能上手，goroutine并发用起来是真爽，编译出来一个静态二进制文件，扔到服务器就能跑。

Docker、Kubernetes、etcd、Prometheus这些云原生基石全是Go写的，想往运维和云原生方向走，或者注重高并发性能的后端开发，可以重点关注golang。

版本	年份	关键特性
1.0	2012	首个正式版
1.5	2015	自举（编译器用Go重写）、GC暂停降至10ms
1.7-1.9	2016-2017	子测试/benchmark、HTTP/2、类型别名
1.11	2018	Go Modules（依赖管理）
1.13	2019	error wrapping（errors.Is/As）
1.16	2021	embed包（内嵌静态文件）、io/fs
1.18	2022	泛型（类型参数）——历史性更新
1.21	2023	内置min/max/clear、WASI支持
1.22	2024	range over int、for循环变量作用域修复
1.23-1.25	2024-2026	range over func（迭代器函数）、工具链改进、context行为变更
1.27	2026	最新稳定版

Rust

项目	信息
创建者	Graydon Hoare（Mozilla）
诞生年份	2010年（1.0于2015年发布）
当前版本	1.96（2026年5月）
范式	多范式（面向对象、函数式、过程式）
类型系统	静态类型、强类型、所有权(Ownership)系统
学习难度	⭐⭐⭐⭐⭐（极高，所有权和生命周期概念陡峭）
TIOBE排名	#10（1.34%，历史最高）

Rust这些年是被捧上神坛的语言。看家本领是"所有权"系统，在编译期就保证内存安全，不靠垃圾回收，性能跟C持平。很多地方都推荐关键系统往它上面迁，Linux内核也开始引入Rust驱动的支持。

代价是学习曲线陡得离谱，借用检查器能把新手折磨到怀疑人生。熬过去之后，写出来的代码是真的让人放心，那种安全感是别的语言给不了的。最近有很多热门的AI智能体项目都从最初的JS或者Python迁移到了Rust，极大地降低了体积还提高了性能。

版本	年份	关键特性
0.1-0.x	2012-2015	预发布阶段，语法频繁变化
1.0	2015	首个稳定版，承诺向后兼容
1.26	2018	Edition 2018，impl Trait、非词法生命周期(NLL)
1.31	2018	Edition切换机制
1.58	2022	Edition 2021，闭包捕获改进、IntoIterator for arrays
1.75	2023	async fn in traits（稳定化）
1.79	2024	inline模块、关联类型边界
1.85	2025	Edition 2024，async closures稳定化、unsafe属性
1.96	2026	最新稳定版

Swift

项目	信息
创建者	Chris Lattner（Apple）
诞生年份	2014年
当前版本	6.1（2025年）
范式	多范式（面向对象、函数式、协议导向）
类型系统	静态类型、强类型、可选类型(Optional)
学习难度	⭐⭐⭐（中等）
TIOBE排名	#15（0.99%）

Swift是苹果2014年推出来接班Objective-C的，iOS开发现在基本全是它。设计上把现代语言的优点吸收了个遍：类型推断、可选类型、泛型、协议导向编程，还坚持值类型优先于引用类型。

想开发苹果生态的应用，绕不开它。Swift 6开始搞严格并发安全，写多线程的代码能省不少心。

版本	年份	关键特性
1.0	2014	首次发布
2.0	2015	协议扩展、错误处理(throw/try/catch)、开源
3.0	2016	API设计指南重命名（大范围迁移）
4.0	2017	Codable协议、String重设计
5.0	2019	ABI稳定性——里程碑
5.1	2019	模块稳定性、属性包装器(Property Wrappers)
5.5	2021	async/await、Actor、结构化并发
5.9	2023	宏系统(Macro)、非copyable类型、if/switch表达式
6.0	2024	严格并发安全、数据竞争安全保证
6.1	2025	最新版

Kotlin

项目	信息
创建者	JetBrains
诞生年份	2011年（1.0于2016年）
当前版本	2.4.0（2026年6月）
范式	多范式（面向对象、函数式）
类型系统	静态类型、强类型、空安全(Null Safety)
学习难度	⭐⭐⭐（中等，Java开发者更易上手）
TIOBE排名	未进入Top 20但Android首选

Kotlin是JetBrains出的，定位就是"更好的Java"。跟Java百分之百互通，但把Java那些烦人的地方收拾得干干净净：空指针没了，样板代码少了，还自带协程。Google在2017年宣布它是Android首选语言，安卓开发现在基本都转过去了。

Kotlin 2.0上了K2编译器，编译速度快了一大截。写Android目前就它了，别犹豫。

版本	年份	关键特性
0.1	2011	首次预览
1.0	2016	首个稳定版
1.2	2017	跨平台支持(Kotlin Multiplatform)
1.3	2018	协程(Coroutines)稳定化
1.4	2020	KMP改进、SAM转换
1.5	2021	记录类、密封接口、内联属性
1.6	2021	上下文接收器预览
1.7-1.9	2022-2023	K2编译器预览、智能 cast改进
2.0	2024	K2编译器正式发布——里程碑
2.4	2026	最新稳定版

第三梯队：Web与脚本语言

TypeScript

项目	信息
创建者	Anders Hejlsberg（Microsoft）
诞生年份	2012年
当前版本	6.0.3（2026年）；TypeScript 7.0原生编译器预览中
范式	多范式（面向对象、函数式）
类型系统	静态类型、结构化类型系统
学习难度	⭐⭐⭐（中等，需理解类型系统）
TIOBE排名	未列入但有版本追踪

TypeScript是微软那位搞C#的大佬Anders Hejlsberg做的，本质是JavaScript的超集，加了一套可选静态类型，编译完还是纯JS。说白了就是给自由奔放的JS套上缰绳，让类型系统在编译期拦下大批低级错误，IDE的补全和重构也顺了。

大型前端项目现在没它真不行，基本是事实标准。用Go重写编译器后据说编译速度能快上10倍，值得期待。

版本	年份	关键特性
0.8	2012	首次发布
1.0	2014	首个正式版
2.0	2016	可空类型、strict模式
3.0	2018	unknown类型、Tuple改进
4.0	2020	可变元组类型、自定义类型推导
4.9	2022	satisfies操作符
5.0	2023	装饰器标准化、模块解析
5.6	2024	装饰器扩展、配置简化
6.0	2025	最新稳定版
7.0	2026（预览）	原生编译器（Go重写），10x编译速度

PHP

项目	信息
创建者	Rasmus Lerdorf
诞生年份	1995年
当前版本	8.5.7（2026年6月）
范式	多范式（面向对象、过程式）
类型系统	动态类型（PHP 7.4+逐步引入类型声明）
学习难度	⭐⭐（低门槛）
TIOBE排名	#14（1.16%）

PHP是1995年那个网站还很少的年代出生的，专为Web而生，直接嵌在HTML里跑。全球七成多网站的后端是它，光WordPress就占了四成多，你逛的很多网站底下都是它。

早年名声不太行，但PHP 7性能比5.6快了2-3倍，8.0又上了JIT编译器，才算把"PHP不够严肃"的印象扭转过来。想快速搞个网站，门槛很低，而且很适合用AI帮忙来氛围编程。

版本	年份	关键特性
PHP/FI	1995	首版，Personal Home Page Tools
PHP 3	1998	重写，正式命名PHP: Hypertext Preprocessor
PHP 4	2000	Zend引擎、面向对象初步支持
PHP 5	2004	Zend Engine 2，完整OOP（类/接口/异常）
PHP 5.6	2014	变长参数、常量表达式
PHP 7.0	2015	性能飞跃（Zend Engine 3）、标量类型声明、返回类型声明
PHP 7.4	2019	类型化属性、箭头函数、FFI
PHP 8.0	2020	JIT编译器、联合类型、match、命名参数、属性(Attributes)
PHP 8.1	2021	枚举、纤程(Fibers)、只读属性、交叉类型
PHP 8.2	2022	只读类、DNF类型、枚举回退
PHP 8.3	2023	类型化常量、json_validate()、动态类常量
PHP 8.4	2024	属性钩子(Property Hooks)、不对称可见性、新数组函数
PHP 8.5	2026	最新稳定版

Ruby

项目	信息
创建者	Yukihiro Matsumoto（松本行弘，"Matz"）
诞生年份	1995年
当前版本	3.4（2024年）
范式	面向对象（一切皆对象）、函数式
类型系统	动态类型、强类型
学习难度	⭐⭐（低，语法优雅）
TIOBE排名	#20（0.73%）

Ruby是日本人松本行弘搞的，设计目标就一句话：让程序员快乐。一切皆对象，连整数都能调方法，语法优雅得不行。真正让它出名的是一句Ruby on Rails，2004年开创了"约定优于配置"，GitHub、Airbnb都是这套框架的受益者。

缺点大概是性能了，另外这些年好像没发现除了RoR之外的其他类似量级的明星项目了。

版本	年份	关键特性
0.95	1995	首次发布
1.0	1996	首个正式版
1.8	2003	广泛采用，Rails 1.0诞生（2005）
1.9	2007	YARV虚拟机，性能提升
2.0	2013	关键字参数、Module#prepend
2.6	2018	JIT编译器（实验性）
3.0	2020	Ractor(并行)、Fiber调度、RBS类型签名、性能3x目标
3.1	2021	YJIT（用Rust重写的JIT）
3.2	2022	WASM支持、语法改进
3.3	2023	YJIT生产可用、Prism解析器
3.4	2024	最新稳定版

Lua

项目	信息
创建者	Roberto Ierusalimschy、Luiz Henrique de Figueiredo、Waldemar Celes
诞生年份	1993年（巴西）
当前版本	5.4（2020年），LuaJIT 2.1（持续维护）
范式	过程式、函数式、面向对象（通过table实现）
类型系统	动态类型、弱类型
学习难度	⭐⭐（低）
TIOBE排名	未进入Top 20

Lua是OpenWrt上面会常用到的，整体非常轻量级，小得离谱，整个解释器也就200KB左右，专为嵌进别人的程序里当脚本语言。数据结构就一个table，数组、哈希、对象、模块全靠它一个顶四个。

除了路由系统OpenWrt之外，游戏脚本、Nginx、Redis、Neovim配置，也是它的地盘。你玩过的魔兽世界、Roblox，底层脚本也可能是它。

版本	年份	关键特性
1.0	1993	首版，用于Petroleo Brasileiro数据描述
3.0	1997	协程机制引入
5.0	2003	标准API统一、meta-mechanism
5.1	2006	模块系统——LuaJIT基准版本
5.2	2011	yield from any scope、位运算
5.3	2015	整数类型、UTF-8支持
5.4	2020	生成器语义改进、const/local变量

Perl

项目	信息
创建者	Larry Wall
诞生年份	1987年
当前版本	5.40（2024年），Raku（原Perl 6，已独立）
范式	过程式、面向对象、函数式
类型系统	动态类型
学习难度	⭐⭐⭐⭐（高，"正则表达式的噩梦"）
TIOBE排名	#18（0.92%）

Perl是1987年出的，江湖人称"完成工作的瑞士军刀"，文本处理的祖师爷。设计哲学是"条条大路通罗马"，自由度极大，但后果就是代码风格五花八门，一个人写的Perl别人基本看不懂。

它的正则表达式是所有现代语言正则的爹，PCRE就是从它这儿来的。现在主要活在系统管理和遗留系统里。

版本	年份	关键特性
1.0	1987	首版
4.0	1991	《Programming Perl》出版
5.0	1994	完整OOP、模块系统、引用——现代化
5.6	2000	Unicode支持、线程（实验性）
5.10	2007	say、given/when、智能匹配
5.14-5.16	2011-2012	正则改进、Unicode全面支持
5.20	2014	后缀解引用、子程序签名
5.36	2022	签名正式稳定、indented heredoc
5.40	2024	最新版

第四梯队：函数式与学术语言

Haskell

项目	信息
创建者	Haskell委员会（学术社区）
诞生年份	1990年
当前版本	GHC 9.12（2025年）
范式	纯函数式
类型系统	静态类型、强类型、Hindley-Milner类型推断、高阶类型
学习难度	⭐⭐⭐⭐⭐（极高，需转变思维范式）
TIOBE排名	未进入Top 20

Haskell是纯函数式语言的旗舰，学术味浓得呛人。没有副作用、没有可变状态、惰性求值、单子……光这些概念就能劝退一大半人。它的类型系统强得离谱，写出来的代码正确性在编译期就有极高保证。

金融量化、编译器、区块链（Cardano）用它。说实话，一般来说，大家学这个大概不是为上班用吧。

版本	年份	关键特性
Haskell 1.0	1990	首个标准
Haskell 98	1999	修订标准
Haskell 2010	2010	标准库扩展、FFI
GHC 7-8	2012-2015	类型级自然数、类型族(Type Families)
GHC 8.0	2016	Backpack模块系统
GHC 9.0	2021	Linear types、 QualifiedDo
GHC 9.6	2023	AST改进、GHC提案系统
GHC 9.12	2025	最新版

Scala

项目	信息
创建者	Martin Odersky
诞生年份	2004年
当前版本	3.x（2025年）
范式	面向对象+函数式融合
类型系统	静态类型、强类型、高阶类型
学习难度	⭐⭐⭐⭐⭐（极高，概念密集）
TIOBE排名	未进入Top 20

Scala是Martin Odersky搞的，跑在JVM上，面向对象和函数式一把抓，类型系统极其强大。Scala 3来了一次大重构，换成缩进式语法，简单了不少。

它最大的地盘是大数据，Apache Spark就是Scala写的，Apache Flink也曾经是Scala写的，但是后续应该是转回Java了。

版本	年份	关键特性
1.0	2004	首版
2.0	2006	大幅重写
2.8	2010	集合库重设计
2.10	2012	宏、字符串插值
2.12	2016	Java 8互操作、SAM转换
2.13	2019	集合库再次重设计
3.0	2021	Scala 3（Dotty），全新语法、union/intersection类型——里程碑
3.3	2023	LTS版本
3.5+	2024-2025	持续改进

第五梯队：科学与专用语言

R

项目	信息
创建者	Ross Ihaka、Robert Gentleman（奥克兰大学）
诞生年份	1993年（S语言基础上发展）
当前版本	4.5（2025年）
范式	函数式、数组式
类型系统	动态类型
学习难度	⭐⭐⭐（中高，统计学背景有帮助）
TIOBE排名	#9（1.69%）

R是统计计算的老大，1993年出生在奥克兰大学，数据可视化（ggplot2）、统计建模、生物信息学领域地位稳固。CRAN上有近两万个统计相关的包，想搞统计分析它最全。

语法受S语言和Scheme影响，向量化操作是核心，有统计学背景的人大概会用的多一些。

版本	年份	关键特性
1.0	2000	首个正式版
2.0	2004	内存管理改进
3.0	2013	长向量支持
3.6	2019	RNG默认变更
4.0	2020	字符串因子默认变更、Markdown文档
4.1	2021	Lambda语法((x) x^2)、原生管道\|>
4.2	2022	\|>_正式稳定
4.4	2024	性能改进
4.5	2025	最新版

MATLAB

项目	信息
创建者	Cleve Moler（MathWorks）
诞生年份	1984年
当前版本	R2025b（2025年）
范式	过程式、面向对象（有限支持）
类型系统	动态类型
学习难度	⭐⭐⭐（中等，矩阵思维）
TIOBE排名	#18（0.74%）

MATLAB是矩阵计算的天花板，一切皆矩阵是它的核心理念。工程仿真、信号处理、控制系统、图像处理，到处是它，Simulink做可视化建模更是独门绝技。

缺点就一个字：贵。商业授权费高昂，所以不少人转身投靠Python的NumPy/SciPy，或者开源的GNU Octave、SCI Lab等等。

版本	年份	关键特性
早期	1984	首次商业发布
5.0	1997	面向对象编程、结构体
7.0	2004	性能优化、JIT
R2008a	2008	命名改为R+年份格式
R2016b	2016	tall arrays、字符串类型
R2020b	2020	Live Editor改进、新图形引擎
R2023b	2023	Python互操作改进
R2025b	2025	最新版

Julia

项目	信息
创建者	Jeff Bezanson、Stefan Karpinski、Viral Shah、Alan Edelman（MIT）
诞生年份	2012年
当前版本	1.11（2024年）
范式	多范式（函数式、过程式、面向对象多重派发）
类型系统	动态类型、JIT编译
学习难度	⭐⭐⭐（中等，Python+数学背景可快速上手）
TIOBE排名	未进入Top 20

Julia的口号是解决"双语言问题"——一边想要Python的舒服，一边想要C的速度。它用LLVM做JIT，性能接近编译语言，跟Python/C/Fortran还能无缝互调，复用现成的库。

多重派发是它的核心特色，函数行为根据所有参数类型决定。科学计算、数值模拟这块可以用到，但是目前生态还是远没办法跟Python相比。

版本	年份	关键特性
0.1	2012	首次发布
0.6	2017	最后的0.x版本
1.0	2018	首个稳定版——里程碑
1.5	2020	Cray支持、线程改进
1.6	2021	LTS版本、编译器性能大幅提升
1.8	2022	并行计算改进、内存layout
1.9	2023	编译缓存改进
1.10	2023	LTS版本
1.11	2024	公共API正式化、包管理改进

Dart

项目	信息
创建者	Lars Bak、Kasper Lund（Google）
诞生年份	2011年
当前版本	3.12（2026年5月）
范式	面向对象、函数式
类型系统	静态类型、强类型、空安全(Sound Null Safety)
学习难度	⭐⭐（低，Java/JS开发者快速上手）
TIOBE排名	未进入Top 20但Flutter生态活跃

Dart是Google出的，主要就是给Flutter框架配的。Flutter做跨平台应用，一套代码跑iOS、Android、Web、桌面，开发时热重载体验也好。Dart 3把空安全彻底做扎实了，还加了记录和模式匹配。

想搞移动跨平台，Flutter是绕不开的主流选择，Dart自然是跟着它。

版本	年份	关键特性
1.0	2013	首版
2.0	2018	类型系统强化、Flutter成熟
2.12	2021	空安全(Null Safety)——里程碑
3.0	2023	100%健全空安全、记录(Records)、模式匹配——大版本
3.2	2023	WebAssembly(GC)支持
3.4	2024	性能改进
3.12	2026	最新版

SQL

项目	信息
创建者	Donald Chamberlin、Raymond Boyce（IBM）
诞生年份	1974年（SEQUEL），1986年ANSI标准化
当前标准	SQL:2023（ISO/IEC 9075）
范式	声明式
类型系统	静态类型（基于模式Schema）
学习难度	⭐⭐（基础易，高级优化难）
TIOBE排名	#8（1.71%）

SQL不算通用编程语言，但搞数据的人没人躲得开它。它的思路是声明式的：你告诉它要啥，它自己琢磨咋取，查询优化器决定执行计划。基础语法学起来半天就会，但优化起来水深得很。

现在的SQL已经能玩窗口函数、CTE、JSON操作、递归查询这些高级活了，2023版连属性图查询都进了标准。

标准	年份	关键特性
SQL-86	1986	首个ANSI标准
SQL-89	1989	参照完整性
SQL-92	1992	JOIN语法、CASE、外连接
SQL:1999	1999	触发器、递归、正则匹配
SQL:2003	2003	窗口函数、XML支持
SQL:2008	2008	INSTEAD OF触发器、TRUNCATE
SQL:2011	2011	时态数据(Temporal Tables)
SQL:2016	2016	JSON支持、行模式
SQL:2019	2019	属性图查询
SQL:2023	2023	SQL/PGQ属性图查询、JSON数据类型正式化

Scratch

项目	信息
创建者	MIT Media Lab（Mitchel Resnick团队）
诞生年份	2007年
当前版本	3.0（2019年）
范式	事件驱动、积木式可视化编程
类型系统	无传统类型系统
学习难度	⭐（极易，面向8-16岁青少年）
TIOBE排名	#12（1.27%）

Scratch是MIT搞的积木式编程，不用敲代码，把积木块拖来拖去就行，面向小朋友。设计目的是让儿童在编程里学会创造性思维和系统推理，现在学校的信息技术课到处都是它。

TIOBE排名能排到12，说明少儿编程是真火了一下，但是为什么不直接学Python呢。

项目	信息
创作者	MIT Media Lab
诞生年份	2007年
当前版本	3.0（2019年）
定位	少儿编程教育

第六梯队：新兴与前沿语言

Zig

项目	信息
创建者	Andrew Kelley
诞生年份	2016年
当前版本	0.16.0（2026年4月）
范式	过程式、编译期元编程
类型系统	静态类型、强类型
学习难度	⭐⭐⭐（中等，C开发者友好）
TIOBE排名	未进入Top 20但持续上升

Zig是新锐里的当红炸子鸡，理念是"无隐藏魔法"——没有隐式控制流、没有隐式内存分配、没有预处理器、没有宏，所有行为都得在代码里明着写。最牛的是comptime编译期执行，能在编译期调用任意函数、操作类型，实现零运行时开销的元编程。

它还能当零依赖的C/C++交叉编译器用，TigerBeetle这种追求极致的数据库就选它。

版本	年份	关键特性
0.1	2016	首版
0.5	2019	comptime系统成熟
0.10	2022	自举编译器(self-hosted)
0.11	2023	包管理器(zig fetch)
0.13	2024	稳定性提升
0.16	2026	错误处理改进、编译期反射增强、标准库新模块(std.crypto/std.net.Server)

Nim

项目	信息
创建者	Andreas Rumpf
诞生年份	2008年
当前版本	2.2.10（2026年4月）
范式	多范式（过程式、函数式、面向对象、元编程）
类型系统	静态类型、强类型、类型推断
学习难度	⭐⭐⭐（中等，Python语法+C性能）
TIOBE排名	未进入Top 20

Nim想同时拥有Python的语法和C的性能，先编译到C/C++/JavaScript，再由GCC/Clang变成原生代码。内存管理用ORC那套，确定性地析构，没有GC暂停。宏系统直接操作AST，表达力极强。

以太坊有个客户端Nimbus就是它写的，也是它拿得出手的代表作。

版本	年份	关键特性
0.x	2008-2014	预发布（原名Nimrod）
1.0	2019	首个稳定版
1.6	2021	LTS版本
2.0	2023	ARC/ORC默认——里程碑
2.2	2024	编译器内部重构、ORC改进
2.2.10	2026	最新版（76 commits、34 bugfixes）

横向对比

按学习难度排序

难度	语言	适合人群
⭐ 极易	Python、Scratch	零基础入门、青少年教育
⭐⭐ 低	Go、PHP、Ruby、Lua、Dart	有编程基础者快速上手
⭐⭐⭐ 中	Java、C#、JavaScript、Nim、Julia	有一定基础，可深入掌握
⭐⭐⭐⭐ 中高	C、Swift、Kotlin、TypeScript、R、MATLAB	需要理解类型系统或特定范式
⭐⭐⭐⭐⭐ 极高	C++、Rust、Perl、Scala、Haskell	需要深厚的计算机科学基础

按应用领域速查

领域	首选语言	备选
AI/机器学习	Python	Julia、R
Web前端	JavaScript/TypeScript	Dart(Flutter)
Web后端	Python/Java/Go/Node.js	PHP、Ruby、C#
移动开发	Kotlin(Android)、Swift(iOS)	Dart(Flutter跨平台)、React Native(JS)
系统编程	C/C++/Rust	Zig、Go、Nim
游戏开发	C++	C#(Unity)、Lua(脚本)
大数据	Scala(Spark)	Python、Java
数据科学	Python/R	Julia、SQL
嵌入式	C	C++、Rust、Zig
云原生/DevOps	Go	Python、Shell
科学计算	Julia/Python	MATLAB、R

按当前版本一览

语言	当前版本	发布日期	类型
Python	3.14.6	2026-06	稳定版
C	C23	2024-10	标准
C++	C++23/C++26(冻结)	2023/2026-03	标准
Java	JDK 26	2026-03	非LTS(当前LTS: JDK 25)
C#	14(.NET 10)	2025	稳定版
JavaScript	ES2025	2025	标准
Go	1.27	2026-06	稳定版
Rust	1.96	2026-05	稳定版
Swift	6.1	2025	稳定版
Kotlin	2.4.0	2026-06	稳定版
TypeScript	6.0.3	2025	稳定版(7.0原生编译器预览)
PHP	8.5.7	2026-06	稳定版
Ruby	3.4	2024	稳定版
Lua	5.4	2020	稳定版
Dart	3.12	2026-05	稳定版
R	4.5	2025	稳定版
Julia	1.11	2024	稳定版
Scala	3.x	2025	稳定版
Haskell	GHC 9.12	2025	稳定版
Nim	2.2.10	2026-04	稳定版
Zig	0.16.0	2026-04	预发布

编程语言发展时间线

年代	出现的语言（年份）
1950年代	Fortran(1957)、LISP(1958)、ALGOL(1958)、COBOL(1959)
1960年代	BASIC(1964)、PL/I(1964)、Simula(1965)、BCPL(1967)、Pascal(1970)
1970年代	C(1972)、Smalltalk(1972)、Prolog(1972)、Scheme(1975)、Ada(1983)
1980年代	Objective-C(1984)、C++(1985)、Eiffel(1986)、Perl(1987)、Tcl(1988)
1990年代	Haskell(1990)、Python(1991)、Lua(1993)、Ruby(1995)、Java(1995)、JavaScript(1995)、PHP(1995)、Delphi(1995)
2000年代	C#(2000)、Scala(2004)
2010年代	Rust(2010)、Dart(2011)、Kotlin(2011)、Julia(2012)、TypeScript(2012)、Swift(2014)、Zig(2016)
2020年代	持续涌现的新语言

咋选语言

说实话，选语言这事儿，比很多人想的简单。别被"XX已死""XX将取代XX"这种标题党带偏，关键看你到底想干啥。

按目标选

你的目标	推荐路径
零基础入门	Python → 理解编程基础后选择方向
Web前端开发	HTML/CSS → JavaScript → TypeScript → React/Vue
Web后端开发	Python(Django/FastAPI) 或 Go 或 Node.js
Android开发	Kotlin → Jetpack Compose
iOS开发	Swift → SwiftUI
跨平台移动	Dart(Flutter)
数据科学/AI	Python(NumPy/pandas/PyTorch) → R(统计) → Julia(高性能)
游戏开发	C++(Unreal Engine) 或 C#(Unity)
系统编程	C → Rust 或 Zig
大数据	Scala(Spark) 或 Python
嵌入式	C → Rust
云原生/后端	Go → Kubernetes生态
高并发实时系统	Go
金融量化	Python → C++ → Haskell
编程教育(儿童)	Scratch → Python

按已有基础选

你的背景	下一步推荐
会Java	Kotlin(Android) 或 Go(云原生) 或 TypeScript(全栈)
会C	C++(游戏/高性能) 或 Rust(安全系统) 或 Zig(C替代)
会Python	Go(高性能后端) 或 Rust(系统) 或 TypeScript(前端)
会JavaScript	TypeScript → Node.js后端或 Dart(Flutter移动)

这一整篇下来，你会发现编程语言这东西没那么玄乎。本质就是一代代人为了解决当时的具体问题攒出来的工具，各有各的用武之地。数据截至2026年8月，版本和排名都在变，但语言背后那套思想，始终是人和机器的交互。

用 opencode 搜集相声文本-其他行业场景用智能体的案例

2026-08-07T08:30:00+08:00

先说清楚，这篇文章不是讲相声艺术的。我对相声毫不理解，完全不懂，也很少接触。传统相声里的贯口、柳活、腿子活这些门道，我一个都说不明白。

那为什么拿相声当例子？因为我想演示一个看起来和 AI、数据科学、计算机离得非常远的场景，其实也能用上这些工具。不需要提示词工程的高手，也不懂什么技能工程、Agent 编排这些名词，在一个看上去很不相干的行业场景，也能实现一件事：把一件想做的事，用大白话说清楚，然后让智能体去办。 这大概是智能体最朴素的用法了。

我儿子最近喜欢听相声

先说清楚这事的由头。不是我自己要收集相声——是我儿子最近听相声，之前我媳妇给他讲历史故事的时候已经找了很多文本，那这次我想给我儿子找一些相声文本来了解内容。借着这个机会，帮他建立一份初步整理好的东西。

所以我的需求很直接：把网上能找到的相声文本，收拢到一个目录里，一个段子一个文件，每个文件带上标注，从网络上搜索所有能找到的段子。就这么一句话。

我给 opencode 的完整提示词是这样：

建立一个专门的相声文本的目录，把历史上所有的经典的古典相声段子，小段大活儿等等按照一个一个文件来放好，并且做好标注。从网络上搜索所有能找到的相声段子来吧

提示词隐含策略和框架

你可能觉得，这句话挺含糊的，什么"所有""经典""做好标注"，全是虚的。但它接到这句话之后，并没有直接冲出去乱搜，而是先干了一件事——按我话里蕴含的思路，先把架子搭起来。

我说"建一个目录""按文件放好""做好标注"，它就能听出这活儿得有个结构。于是它先建了这么个骨架：

相声文本库/
├── README.md
├── 《传统相声汇集》总目录.md
├── 《中国传统相声大全》目录.md
├── 传统单口相声/
├── 传统对口相声/
├── 传统群口相声/
└── 新相声/

凡事都是要有结构，有纲要，有目录，这就是一个体现。拿了这个，他再去找，这就叫按图索骥，它去参考着找。

最开始，它从网上翻到了《传统相声汇集》的完整目录——这套书俗称"六小本儿"，六册收了二百多段传统相声，每段还标了口述者和整理者，张寿臣、刘宝瑞、郭启儒、侯宝林、马三立、常宝堃这些名字都在上面。这份目录就成了整个库的索引地基，后面一段一段往里填，就照着它来。

这里其实是个挺重要的点：虽然我是直接给它提了个要求，但要求里边尽量蕴含一点对这件事的思考。 这个提示词其实压根也说不上什么提示词工程，只是对话的人默认脑子里就想到了要分类、要标注、要完整。把这些想法用大白话放进要求里，智能体就能沿着这个思路去执行。所谓的提示词工程也不是什么玄学，而更可以说是「沟通的技术」，是要求里带上你的思考方向，它才知道往哪儿使劲。

顺着名字一路挖下去

架子搭好，就开始填内容了。搜到一批经典段子之后，目录里就有了很多段子的名字。有意思的是，它拿着这些名字，还能接着搜出更多东西，就是从搜索结果当中发散出更多线索。

比如从目录里看到《报菜名》《八扇屏》《地理图》，它就能顺着这些名字去找各自的全本；看到表演者名单里有张寿臣、刘宝瑞，它又能顺着人去找他们名下别的段子。名字是锚点，一个带一个，越挖越多。

人自己查这些相关的事儿的时候，是不是不也是这样？如果有的时候需要咱们自己找这种线索，也都是会先看看著名的作品，是谁的代表作，再找典型作者，然后这么来。跟智能体交流也是类似，把事儿说清楚，剩下让它自己滚雪球。

AI替人干那些无聊的活

这里得再次强调一个原则，让 AI 干活，建议只让它替人完成无聊的重复的机械内容，而绝对不建议把判断权也交给它。

比如这次，它要上网去把一堆页面上的文本拿下来。这事儿的本质是什么？是让它去操作浏览器、上网帮忙下载东西，省去了人一个个复制粘贴的功夫。 ——它只是执行里那些重复、枯燥、纯粹浪费时间的部分。搜集和排版这种活，人干起来又慢又无聊，交给它正合适。

AI擅长替人做那些浪费时间又毫无乐趣的重复劳动。

遇到问题AI能自己想办法

这种从网上搜集文本的活儿，走一遍就一定会遇到几个坑，我一开始其实还担心它搞不定，后来发现它对这种问题处理得比人还顺。

第一个坑是文字编码。有的网站页面文字是 GBK 编码的，直接读出来全是乱码，得转成 UTF-8 才能正常显示。你要是让一个外行人来干这个，他可能压根不知道还有"编码"这么回事，看着满屏乱码就傻眼了。但模型智能体不会——它发现乱码，会自己去识别编码、转码、再重新读。对它来说这不算问题，自动就解决了。

第二个坑是内容不完整。很多段子在网上只有一半，正文中间有个"查看完整内容"的按钮，点进去要花钱。遇到这种，它就得四处换来源，从别的网站找完整版，再把缺的部分补上拼好。这个问题它也能尽量自己解决——这个站不全就换那个站，一遍不行换几遍。

智能体有一个特点：人觉得麻烦甚至无从下手的技术性问题，对模型来说往往不是问题，它会自己想办法。 你需要操心的不是"它会不会搞不定"，而是"怎么把要求说清楚，让它知道去干嘛"。

就算不知道什么是字符编码，也不知道到哪里找和如何拼接完整，人也可以完全不担心不关注这些。

就像是我要炒菜，只需要知道锅怎么用，菜洗干净之后切成什么样，然后放多少盐就行了。

不需要去知道这个锅是用什么材料制作的，加工的工艺是什么样的，它的矿物来源是怎么样的，在哪儿进行的选矿冶炼，在哪儿进行的加工成型，怎么进行的互联网营销，最终通过什么样的快递到了这，这些都不用管。

也不用去知道这个菜是在什么地方产地种的，经历了多长时间的日照，用了什么样的肥料，最终怎么采摘，怎么保存，怎么发给我，这些都不是我一个做菜的这个场景下的操作人员所需要去关注的，人类社会的分工不就是这样吗？

初步的结果是一个几十万字的文本目录

折腾了一圈之后，目录就建成了。最终收进来了四十多个段子的完整文本，加起来二十多万字：

传统单口相声：珍珠翡翠白玉汤、连升三级、山东斗法、解学士、君臣斗、小神仙这些刘宝瑞、张寿臣的名段；
传统对口相声：贯口的报菜名、八扇屏、地理图、绕口令，文哏的论捧逗、文章会，柳活的黄鹤楼、空城计、汾河湾，武哏的大保镖等等；
传统群口相声：扒马褂、训徒、金刚腿；
新相声：夜行记、买猴、钓鱼、宇宙牌香烟、五官争功、虎口遐想、小偷公司。

文本是原文基础上整理加工过的

拿到目录之后，可能有人会想：这不就是把网上的文本复制下来存好吗？

不完全是。每个文件里不只是原样文本，模型还会对它做整理和加工。 拿连升三级、报菜名这些段子来说，每个文件的开头都有一份标注，正文也有统一的排版和分节。

比如报菜名那个文件，开头是这样的：

---
篇名:    《报菜名》
别名:    《菜单子》
类型:    传统对口相声 / 贯口活
性质:    大活儿
表演者:  郭启儒、马三立、常宝堃等，各家均有演出本
来源:    网络流传文本（yuwenmi.com 台词库）
整理时间: 2026-08-06
---

正文里，角色对话统一用「甲：」「乙：」标出来，单口的用叙述体，群口的用「甲/乙/丙」。文末还有一节"来源与备注"，记着这段是从哪抓的、什么版本、有什么残缺。拿到的文本，模型还会顺手润色一下，让它更通顺、更完整，读起来像是整理好的定稿，而不是网页上黏下来的碎渣。

这一步的意义在于：从"一堆来源不明的网页"到"一份结构化的资料库"，中间这个整理、标注、校对的活，原本要花很久，现在全让智能体替你干了。

这种整理好的东西能拿来干嘛

说到这儿，可能有人觉得，这不就是整理个资料吗？能有多大用。

其实想深一层，这种整理出来的结构化文本，用途可以比想象的大。比如，它可以直接作为某个场景的领域资料，拿去训练垂直领域的小模型、做微调的数据集、搭知识库。相声也好，别的什么也好，只要同类文本攒得够多、整理得够规范，就成了可以喂给模型的原料。

我要说的是：即使这事看起来和模型、和数据科学离得很远，也可以发挥一点想象力。 把日常生活里那些重复性比较高、又没什么创造性的任务，试着交给智能体——整理资料、下载文件、把零散的东西归拢成结构化的东西，这些都是它擅长的。你不用是程序员，也不用懂算法，你只要会"把一件事说清楚"，就能使唤它。

但最后必须泼一盆冷水

讲到这里，我得提醒一句很重要的事，这也是做这种活儿一定要考虑到的：模型可能会有幻觉，这是难以避免的。

它给出来的文本里，可能带着它自己雕琢、甚至是扭曲的痕迹。你没法保证它整理的每一处都忠实于原文——有些地方它可能顺手"补全"了，有些地方可能理解错了。所以看到结果，不能全盘照收。

不过具体到相声这个东西，问题倒还不大。因为相声是语言的艺术，它讲究的是顺口、俏皮、包袱响。模型稍微给它改点词儿、顺点句子，人拿回来念两遍，觉得不对劲改回去就是了。语言这东西，改来改去损失不大。

但其他的学科可就未必了。 要是整理的是科学文献、医学资料、工程规范，模型要是来这么一手"润色"，后果可能就严重了。所以最后一定要记住：不能轻信模型，不能让它替你做判断。 它负责把活干了，把东西摆到你面前，至于这些内容靠不靠谱、对不对，判断权永远得在你手里。

从二进制到计算机-0和1是怎么变成程序的

2026-08-06T23:00:00+08:00

你有没有想过这样一个问题：你手机上某张"图片"，在计算机内部到底是一堆什么？答案是：一堆 0 和 1。不是"一堆像 0 和 1 的东西"，就是字面意义上的一长串 010011000111...。

可能有点反直觉的是，不管是文字、图片、声音、游戏，还是你正在读的这篇文章，到了计算机底层，全都是 0 和 1。那问题就来了：光有 0 和 1，计算机凭什么能"算"，能"存"，最后能跑出千奇百怪的软件？

这篇文章就顺着这条线，从物理一路讲到编程语言：为什么是二进制 → 二进制怎么表示数 → 二进制怎么计算（逻辑门、加法器）→ 二进制怎么变成各种数据类型 → 不同编程语言处理这些类型时为什么天差地别。

为什么计算机用二进制，而不是十进制

你估计猜到了答案的一半：因为电路只擅长区分两种状态。

你当然可以让一个灯泡表示 0~9 十种亮度来代表十进制，但问题是一旦电压稍有波动、电线有点老化、温度有点变化，"亮度 7"和"亮度 8"就不太好分清了。可是"亮"和"灭"——或者更准确地说"高电压"和"低电压"——这两种状态，晶体管可以切换得又快又稳。

抽象	物理实现
0	低电压（约 0V）
1	高电压（约 3.3V / 5V）

所以二进制的本质，是用一个"开关"的两种状态去表达信息。一盏灯亮是 1、灭是 0；一格磁带磁化是 1、没磁化是 0；一张光盘有个坑是 1、没坑是 0。理解这一点之后，下面所有内容都顺理成章了。

二进制怎么表示数

我们在十进制里写 1011，意思是"1 个千 + 0 个百 + 1 个十 + 1 个一"，每一位的"位权"是 10 的次方。二进制完全一样，只是把"10 的次方"换成了"2 的次方"：

图 1. 位权。 同样写着 1011：十进制里每位是 10 的次方，等于一千零一十一；二进制里每位是 2 的次方（8、4、2、1），等于 11。进制不同，数值天差地别。

二进制里最基本的位权就是：1、2、4、8、16、32、64、128……每一项都是前一项的两倍。所以"把十进制转二进制"其实就是问：这个数能被哪些 2 的次方凑出来？

用 Python 三行就能搞定（bin() 是内置函数，下面还附了手算过程）：

print(bin(11))            # 0b1011
print(0b1011)             # 11，前缀 0b 表示二进制

# 手动拆：每一位就是 2 的次方
bits = [1, 0, 1, 1]                     # 从高位到低位
value = sum(d * 2**i for i, d in enumerate(bits[::-1]))
print(value)              # 11

顺便记一个很有用的心算：2^10 = 1024，大约等于一千。所以"1KB"在计算机里是 1024 字节，不是整 1000（硬盘厂商喜欢用1000）——这个"约等于"的偏差，就是为什么你买的 1TB 硬盘实际可用只有约 931GB。

八进制与十六进制：二进制的"缩写"

二进制有个很烦人的毛病：太长了。一个 8 位的数写起来还行，64 位的整数要写 64 个 0 和 1，谁也受不了。于是计算机科学家想了个偷懒的办法：既然 8 = 2³、16 = 2⁴，那就把二进制每 3 个 bit、每 4 个 bit 打成一包，给每一包起一个短名字：

每 3 个 bit 一组，只有 0~7 共 8 种组合 → 叫八进制（octal）；
每 4 个 bit 一组，只有 0~15 共 16 种组合 → 叫十六进制（hexadecimal）。

所以八进制、十六进制不是另一种数，而是二进制的"压缩写法"——因为底数分别是 2 的次方，它们和二进制之间可以无损、自由地互相转换。

图 2. 八进制与十六进制。 左图：同一个数 255 用四种进制写出来，进制越大写起来越短；右图：二进制按 4 位一组得到十六进制（1111 1111 → FF），按 3 位一组得到八进制（011 111 111 → 377），分组即转换。

为什么偏偏是 3 和 4？因为 2³ = 8、2⁴ = 16：3 个 bit 恰好能表示 0~7（八进制的全部数字），4 个 bit 恰好能表示 0~15（十六进制的全部数字）。于是"二进制 ↔ 八/十六进制"就变成了纯粹的"分组翻译"，根本不用算。十六进制从 10 开始用字母：A=10, B=11, C=12, D=13, E=14, F=15，对应关系如下：

二进制	十六进制	二进制	十六进制
0000	0	1000	8
0001	1	1001	9
0010	2	1010	A
0011	3	1011	B
0100	4	1100	C
0101	5	1101	D
0110	6	1110	E
0111	7	1111	F

在 Python 里三种转换都是内置函数：

x = 255
print(bin(x))     # 0b11111111   二进制
print(oct(x))     # 0o377        八进制
print(hex(x))     # 0xff         十六进制

print(int("ff", 16))   # 255，按十六进制解释字符串
print(int("377", 8))   # 255，按八进制解释字符串

为什么程序员整天看见 0x 开头的东西？因为内存地址、二进制数据、颜色值这类"原始字节"，用十六进制写比二进制短一半还多。比如 CSS 里的颜色 #FF0000 就是红色——FF 表示红色的亮度拉满，00 00 表示绿、蓝为 0。你看到的每一个十六进制字符，背后都是 4 个 bit。

二进制怎么计算：从逻辑门到加法器

知道了怎么"表示数"，接下来是最关键的问题：计算机是怎么"算"的？ 说白了，计算机里根本没有"算数"这个神秘动作——它只有逻辑。一切算术，都能拆成几个最基本的逻辑操作。

逻辑门：电路的"语言"

有三个最基本的逻辑门，它们各自只有一张小小真值表：

图 3. 三个基本逻辑门。 与门 AND：两个输入都是 1，输出才是 1（一票否决制）；或门 OR：只要有一个是 1，输出就是 1；非门 NOT：输入取反。图里每个门都附了真值表。

用 Python 模拟这三张真值表，你甚至不需要任何硬件：

def AND(a, b): return a & b   # 与：两个都要是 1
def OR(a, b):  return a | b   # 或：有一个是 1 就行
def NOT(a):    return 1 - a   # 非：取反

print(AND(1, 1), AND(1, 0))   # 1 0
print(OR(1, 0),  OR(0, 0))    # 1 0
print(NOT(1),    NOT(0))      # 0 1

你可能觉得这太简单了，但请记住：计算机里所有的"智能"，都是几亿个这种"蠢门"组合出来的。

异或：三个门就能拼出来

不过你可能已经注意到，后面半加器里会用到一个叫"异或门 XOR"的东西——两个输入不一样时输出 1。它是不是第四个"基础门"？不是。异或完全可以用已经有的与、或、非三个门拼出来，不需要任何新零件。

异或的意思就是"不一样才为 1"。那什么情况下 A、B 不一样？

A 是 1 且 B 是 0：A AND NOT(B)
A 是 0 且 B 是 1：NOT(A) AND B

这两种情况，任一种成立都算"不一样"，所以再把它们用"或"连起来：

\[\text{XOR}(A, B) = (A \land \lnot B) \lor (\lnot A \land B)\]

图 4. 异或 = 与、或、非的排列组合。 A 和 ¬B 相与、¬A 和 B 相与，两路结果再相或——异或就出来了。图中蓝色是"A"这一路、绿色是"¬"这一路的走线。

用代码写出来，就是前面那三个"蠢门"的排列组合：

def AND(a, b): return a & b
def OR(a, b):  return a | b
def NOT(a):    return 1 - a

def XOR(a, b):
    return OR(AND(a, NOT(b)), AND(NOT(a), b))   # 只用与、或、非

for a in (0, 1):
    for b in (0, 1):
        print(f"{a} XOR {b} = {XOR(a, b)}")
# 输出：0 XOR 0 = 0；0 XOR 1 = 1；1 XOR 0 = 1；1 XOR 1 = 0

这正是"计算机里所有智能都是蠢门组合"的第一课：连"异或"都不是新零件，只是把与、或、非拼一拼。 而它，恰好就是下面半加器里"和位"的核心。

半加器：一位加一位

二进制里最简单的加法是：一位加一位，可能有四种情况：0+0=0、0+1=1、1+0=1、1+1=2。前三个好办，最后这个 1+1=2 在二进制里是 10——结果是 0，还要向高一位进 1。

所以"一位加法"需要同时算出两个东西：和位（sum）和进位（carry）。观察一下真值表就能发现：

和位：两个输入不一样时是 1 → 这是异或门 XOR；
进位：两个输入都是 1 时是 1 → 这是与门 AND。

这个组合就叫半加器，两行代码的事：

def AND(a, b): return a & b   # 与
def XOR(a, b): return a ^ b   # 异或

def half_adder(a, b):
    return XOR(a, b), AND(a, b)   # (和位, 进位)
print(half_adder(0, 0))   # (0, 0)
print(half_adder(1, 1))   # (0, 1)  —— 1+1=2，即二进制 10

全加器：带上进位的加法

半加器有个缺陷：它不理会来自低位的进位。可真实的多位加法里，第 3 位算的时候，第 2 位可能正好向它进了个 1。所以得做一个"三位相加"的电路：两个加数位 + 一个低位进位，算出和位 + 新高位进位——这就是全加器。

把 4 个全加器串起来，低位的进位接高位的进位输入，就得到一个 4 位加法器：

图 5. 4 位加法器。 每个 FA 是一个全加器：竖着进来的是 A 位和 B 位，横着串起来的是"进位链"（低位算完，进位送给高位）。最左边 C0 补 0，最右边 C4 是最高位进位。整条链就是加法器。

这个"全加器"用代码实现也只要几行——它正好是两个半加器加一个或门拼出来的。更进一步，把 4 个全加器串起来（低位进位喂给高位的 cin），就是一台能算 4 位加法的"加法器"：

def AND(a, b): return a & b
def OR(a, b):  return a | b
def XOR(a, b): return a ^ b

def half_adder(a, b):
    return XOR(a, b), AND(a, b)      # (和位, 进位)

def full_adder(a, b, cin):
    s1, c1 = half_adder(a, b)        # 两个半加器……
    s2, c2 = half_adder(s1, cin)     # ……再加一个低位进位
    return s2, OR(c1, c2)            # (和位, 进位)

# 全加器真值表：8 种情况全对
for a, b, cin in [(0,0,0),(0,0,1),(0,1,0),(0,1,1),(1,0,0),(1,0,1),(1,1,0),(1,1,1)]:
    s, c = full_adder(a, b, cin)
    print(f"{a}+{b}+{cin} = 和{s} 进位{c}")

# 用 4 个全加器串成 4 位加法器：算 1011 + 0110
def add4(a, b):                       # a、b 是低位在前的 bit 列表
    out, cin = [], 0
    for i in range(4):
        s, cin = full_adder(a[i], b[i], cin)   # 上一位的进位传进来
        out.append(s)
    return out + [cin]

result = add4([1,1,0,1], [0,1,1,0])  # 1011 + 0110（低位在前）
print("1011 + 0110 =", "".join(map(str, result[::-1])), "(二进制)")
print("十进制结果：", sum(b << i for i, b in enumerate(result)))
# 输出：1011 + 0110 = 10001 (二进制)；十进制结果：17

注意看 add4 里那个 cin——它就像图 3 里的那条红色进位链：一位算完，进位被"喂"给下一位。这一小段 Python，就是 CPU 里加法器的完整逻辑。

下面这个动画演示了这条"进位链"是怎么工作的——算 1011 + 0110，从最低位（位权 1）开始，逐位计算，每位的进位会"接力"传给下一位：

图 6. 二进制加法动画。 从最右边一位开始算：1+0=1 无进位，第二位 1+1=0 进 1，第三位 0+1 再+进位 1=0 进 1……直到算出结果 10001（17）。注意每一列的进位都会"涨"到左边一列。

到这一步，"计算机是怎么算数"这个问题就有了一个非常硬核又非常朴素的答案：所谓加法，就是一堆开关（晶体管）按逻辑门的规则互相勾连；所谓算数，就是把这个"加法器"不断做大、做快。 减法（补码）、乘法（移位累加）、除法（试商）都可以在加法器的基础上搭出来。CPU 里那个负责算数的部件，就叫 ALU（算术逻辑单元），本质就是一台超大的加法器加上一堆逻辑门。

从"数"到"一切数据"：编码

现在我们已经能让计算机"算 0 和 1"了。但照片、文字、声音，怎么看都不是 0 和 1。怎么办？答案是编码——人为约定一套规则，让二进制和真实世界一一对应：

数据	怎么编码成二进制
整数	直接就是二进制（`5` → `101`）
小数	二进制小数/浮点数（如 `0.1` → `0.000110011...`）
字符	查表：每个字符一个编号（ASCII / Unicode，如 `A` → `65` → `1000001`）
图片	每个像素拆成 RGB 三个数（红/绿/蓝亮度）
声音	每秒采样几万次，每个采样点一个数
程序	指令本身也有编号，CPU 照着编号干活

关键要理解的是：同一串二进制，可以"解释"成任何东西。 01000001 可以是一个整数 65，也可以是字符 'A'，也可以是一张图片里某个像素的某个颜色分量——全看你打算把它当什么。

这时候，"数据类型"这个概念就出现了。它的本质就是一句话：

数据类型 = 告诉程序"这一串二进制该怎么解释、占多大地方、能干什么"。

数据类型有哪些

常见的"基础数据类型"就那么几种，每种对应一种"人类世界里最基本的信息"：

常见的"基础数据类型"就那么几种，每种对应一种"人类世界里最基本的信息"，它们占的内存大小差别很大：

类型	代表语言里的名字	表示什么	典型大小
布尔 bool	`bool` / `boolean`	真 / 假	1 字节
字符 char	`char`	一个字符	1 字节（ASCII）
整数 int	`int` / `integer`	整数（有正负）	4 或 8 字节
无符号整数	`unsigned int`	只有非负的整数	4 字节
浮点 float	`float` / `double`	带小数的数	4 或 8 字节
字符串 string	`str` / `String`	一串字符	变长

一个关键观察：同一串 0 和 1，类型不同，占的内存和解释方式就完全不同。 比如 01000001 在 char 里是字符 'A'，在 int 里就是数字 65。另外注意 Python 的整数是个"对象"，光一个数就占约 28 字节——因为它要管任意大，牺牲内存换"永远够用"（下文讲语言差异时会再提）。

在这个基础上，还有由基础类型拼出来的复合类型：数组（一堆同类型排成一排）、结构体/类（把不同类型打包成一个"档案袋"）、指针/引用（记住"数据放在哪"）、枚举（给一组常量起名字）、联合体（同一块内存换着花样用）。但追根到底，它们都是"0 和 1"按不同规则的组织方式。

一个 32 位整数 int 能表示的范围是 -2147483648 ~ 2147483647——为什么是这么个怪数？因为 32 位里最高一位留作符号，剩下 31 位能表示 $2^{31}$ 个数，一半给负数、一半给非负，所以上限正好是 $2^{31}-1 = 2147483647$。这个"上限"能不能撑住，直接导致了下面要讲的语言差异。

不同编程语言的类型差异

同一个"整数"、"浮点"，在不同编程语言里差别可以非常大。我们从四个维度来看。

差异一：静态类型 vs 动态类型

静态类型（C、Java、Go、Rust）：变量是什么类型，编译的时候就定死了，不许变。
动态类型（Python、JavaScript）：变量只是"贴了个名字"，类型运行的时候才知道，今天装整数、明天装字符串都行。

# Python：动态类型，同一个变量想装什么都行
x = 10        # 现在是整数
x = "hello"   # 下一秒变成字符串，完全合法

// C：静态类型，类型写在声明里，想改都不行
int x = 10;
x = "hello";   // 编译报错：不能把字符串塞进 int

动态类型写起来爽，但类型错误往往运行到那一步才爆；静态类型写起来啰嗦，但编译期就把一堆低级错误挡在门外。

差异二：强类型 vs 弱类型

强类型（Python、Java）：类型不匹配就报错，绝不偷偷"变魔术"。
弱类型（C、JavaScript）：类型不匹配时会自动转换（隐式转换），经常"好心办坏事"。

最典型的例子是 JavaScript 的 +——它看情况决定是"加法"还是"拼字符串"：

// JavaScript：弱类型，加号会自动"变魔术"
console.log(1 + "2");    // "12"   数字被自动转成字符串拼起来了
console.log("5" == 5);   // true   宽松相等：字符串和数字被自动转成一样
console.log("5" === 5);  // false  严格相等：类型不同就是不同

而 Python 里 "5" + 5 会直接抛 TypeError，因为它拒绝"猜测你的意图"。

差异三：整数范围——会不会溢出

这是最容易踩的坑。C 的 int 是固定 4 字节，加过头就"绕回去"：

#include <stdio.h>
int main() {
    int x = 2147483647;          // int32 的最大值
    printf("%d\n", x + 1);       // 溢出！输出 -2147483648
    printf("int=%zu 字节, float=%zu, double=%zu, char=%zu\n",
           sizeof(int), sizeof(float), sizeof(double), sizeof(char));
    return 0;
}

Python 的整数是"任意精度"：不够用就自动多占几个字节，永远不溢出：

x = 2147483647
print(x + 1)      # 2147483648，自动变大，不会绕回去
print(10**100)    # 一百位数也能存，想多大就多大

Python 整数牺牲内存，换来了"永远够用"。而 C 选择固定 4 字节，换来的是速度和可预测的内存布局。

差异四：浮点精度——所有语言共同的坑

小数（浮点数）在所有语言里都面临同一个问题：0.1 在二进制里是无限循环小数，存不下，只能截断。所以：

print(0.1 + 0.2)    # 0.30000000000000004

为什么是 0.30000000000000004 而不是 0.3？看这个图就明白了——十进制的 0.1 转成二进制，会一直除不尽，永远写不完：

图 7. 0.1 的二进制表示。 十进制 0.1 的二进制是 0.00011001100110011...，无限循环。浮点数只有有限位（float 32 位、double 64 位），只能截断，所以存下的其实是一个"很接近 0.1 但不是 0.1"的数，两个这种数加一起，误差就露出来了。

不同语言在这件事上唯一的区别是"精度档位"：

C：有 float（4 字节，约 7 位有效数字）和 double（8 字节，约 15 位有效数字），自己选；
Python：只有一个 float，其实就是 8 字节的 double；
JavaScript：连整数都是 double——所以你写 0.1+0.2 得到 0.30000000000000004，而 9007199254740993 这种大整数会悄悄变不准。

语言"性格"一览

把上面这些差异汇总成一张表（"静态/动态"管类型什么时候定，"强/弱"管类型会不会偷偷转换）：

语言	静态 / 动态	强 / 弱	一句话特点
C	静态	偏弱	类型就是那几个字节，直接操作内存，快但危险
Java	静态	强	编译期查类型，跑在虚拟机上，严谨稳重
Go	静态	强	带类型推断，编译快，适合写后端服务
Rust	静态	强	最严的类型系统，既要性能又要安全
Python	动态	强	随手写、运行期才定类型，但拒绝乱猜
JavaScript	动态	弱	灵活到"加号都会变魔术"，坑多但生态巨大

这张表不是"谁好谁坏"，而是取舍：写操作系统、游戏引擎，你希望编译期就把类型查死（C、Rust）；做数据分析、写脚本，你更想要随手就写、运行期再说的爽快（Python）。

语言的类型差异，本质还是内存问题

说到底，为什么会有这些差异？因为底层的二进制和内存布局是唯一的，语言只是给了不同的"包装"：

C 直接暴露内存：int 就是那 4 个字节，程序员自己看着办；
Java 在中间加一层"虚拟机"，类型是声明出来给编译器检查用的；
Python 一切皆对象：每个数据都是一个"对象头 + 值"，所以慢、占内存，但安全、好用；
静态语言的"类型"在编译完就消失了（变成机器码里的固定字节数），动态语言的"类型"要一直带到运行期。

全链路：从晶体管到程序

把所有零件串起来，就是一整条链条，每一层都为上一层铺路：

物理层：晶体管能稳定表示两种电压 → 这就是 0 和 1；
逻辑层：与/或/非三个门能组合出任何逻辑；
运算层：加法器 + 进位链，让"开关"能算数；
存储层：内存把成千上万个 0/1 保存下来；
解释层：数据类型规定"这串 0/1 是什么、多大、怎么用"；
语言层：编程语言把这层解释封装成 int、float、str 等"给人看的词"；
应用层：你用这些词写出程序，程序变成 0/1 跑在芯片上。

所以回到开头的问题："那张手机照片是什么？"答案是：手机照片 = 一串 0 和 1；这串 0 和 1 是 '图片' 这种数据类型；'图片' 是图像软件给这串二进制起的名字；而计算机算它的过程，不过是几十亿个开关按逻辑门在飞快地开合。从一盏灯，到一整个数字世界，中间没有一步是神秘的。

想亲手验证这条链，可以试试：把 bin(65) 的输出 0b1000001 拿去对照 ASCII 表，你会发现它正好是字符 'A'——你看，数字、字符、图片，在你眼里不同的东西，在计算机眼里都只是"一串开关"。

用 opencode 做商业信息汇总与搜索-以马斯克商业版图为例

2026-08-06T21:30:00+08:00

在开始之前先说明一下：这篇文章讲的不是"怎么用 AI 炒股"，而是"怎么用 opencode 这类 AI 编码助手，把一堆散落各处的商业信息，快速整理成一份结构清晰、带表格带图表的 Markdown 报告"。案例用的是马斯克的商业版图，原因是它的信息量大、数据点密集、且涉及大量"来源冲突"，用来演示 AI 做信息汇总的严谨性处理，再合适不过。文中所有数字都只是公开资料的整理，不构成任何投资建议。

为什么用 AI 做商业信息汇总

传统的信息整理流程大概是：打开各种百科 → 看几个新闻网站 → 复制粘贴 → 手工排表格 → 手工画图。遇到"同一件事多个来源数字不一样"的时候，还得自己去追原始报道。一顿操作下来，半天没了。

AI 的优势在于：

搜索与阅读省事：可以让 AI 同时抓取维基百科、Reuters、CNBC、Forbes 等页面，并交叉核对；
结构化输出方便：直接把散乱信息整理成时间线、估值表、大事年表，不用你手动排版；
可视化简单方便：让 AI 写 Python 代码，用 matplotlib 把数据画成图表，用 mermaid 画公司股权关系图等等，都很方便；
充分查询检索信息：AI 可以把"来源冲突"和"待确认数据"显式标出来，而不是蒙混过关。

整体工作流

以这次马斯克案例为例，opencode 里完整跑通了一套流程，共六个步骤：

明确需求与产出形式

先想清楚要什么。这个案例的需求是：马斯克整个商业版图 + 发展历程，要完整、严谨，要有表、有图、有来源。同时为了"快餐式"阅读，最后还要一个简单版。

派研究代理去搜索和核实

这是最关键的一步。让 AI 派出一个"研究代理"，带上明确的数据清单去抓网页：

每家公司：成立年份、马斯克投入多少、融资估值时间线、退出/出售时间和价格、当前持股比例；
个人维度：净资产时间线、薪酬包、历年套现；
附带要求：每个数据点给出处；不同来源不一致的要标注；拿不准的标"待确认"，不许编。

这一步的价值在于，把"搜索结果"和"结论输出"分离：先老老实实收集证据，再动笔写报告。

结构化：时间线、估值表、大事年表

拿到调研数据后，按公司组织成结构化的 Markdown 表格。以 SpaceX 为例：

时间	事件	估值
2012 初	私营市场估值	$1.3B
2021.10	融资轮	$100.3B
2023.12	融资轮	$180B
2026.06	IPO 定价 $135/股	$1.77T

这种"时间+事件+估值"的三列结构，是所有商业报告的地基。

数据可视化

用 matplotlib 生成图表（本机装了中文字体后，rcParams 里指定 Hiragino Sans GB 即可正常显示中文），用 mermaid 画股权结构。本次一共生成：净资产时间线、各公司估值对照、企业存续时间线、估值里程碑、财富构成饼图、投资回报图，共六张。最后应要求又补了一张"最终状态"静态图：

这张图有个设计细节值得一提：卖掉的公司在出售年份曲线就截止、不再延伸（虚线），在营公司则延伸到最新（实线）。这样"看一图而知全貌"。

分层交付：完整版 + 简单版

一次调研产出了三份东西：

完整版研究报告：约 500 行，含方法说明、不确定项清单、逐公司深度档案、来源 URL 清单；
简单版：一张估值图 + 一张一览表 + 一张速查表，几分钟能读完；
调研原始数据文件：保留所有数据点和来源，可追溯。

分层交付的好处是：读者可以按需取用，不浪费。

严谨性处理

AI 汇总最容易翻车的就是"自信地编造"。所以这次特意做了三层保险：

来源冲突显式标注。比如 Zip2 收购价主流是 $305M、个别来源写 $307M；xAI 被 SpaceX 收购作价两个词条分别写 $250B 和 $125B，差距一倍。报告里都如实列出双口径，而不是二选一。
"待确认"标签。没有一手来源的数值（如 Neuralink 2023–2024 融资额、SpaceX 2024 年某次估值），一律标"待确认"。
免责声明。明确写清：仅基于公开资料的参考整理，不构成投资建议，引用前需以一手来源核实。

本次对话实录：完整提示词与截图

下面的截图就是这次任务的真实过程记录，每张图对应一轮提示词，可以直接看到"怎么一步步把一个模糊想法磨成一份报告"。

给出初步要求

第一轮提示词（也是全部需求的起点）：

我想要了解马斯克公司的整个商业版图和发展历程，要总结出完整的沿着时间和他的投资额、薪酬、估值以及从事的领域等等，做出来非常严谨的一个报告，还要有对应的数据的可视化，要有表，要有图，做成markdown文档。

开始数据收集

AI 据此派出研究代理抓取维基百科与 Reuters/CNBC/Forbes 等页面，按"成立时间、投资额、薪酬、估值、持股比例、退出价格"逐项核实，并把来源冲突和待确认数据单独列出来。

初步有结果

第一版完整报告交付：约 500 行的 Markdown，包含研究方法说明、不确定项清单、逐公司深度档案、来源 URL，以及 6 张 matplotlib 图表和一张 mermaid 股权结构图。

要求改进

用户觉得完整版太复杂，要求出一个"简单版"，且点名要一种特定的可视化形式：

给一个简单版本的横轴是时间纵轴是估值。然后各个公司的，什么的反正就在上面弄成那种随着时间变化的这种动图，然后再给一个数据表格。数据表格就是什么时，每个公司按照时间什么从新到旧啊，什么时候卖出去的，等等等等这样来，不要那么复杂的给一个这样新的，但已经有的，那你先存着吧

继续提要求

简单版动图做好后，用户进一步纠偏——不要动图，要一张静态的"最终状态"图，并且规定了重要规则：卖掉的公司曲线到出售年份为止、之后不再延伸：

不对，还是不应该用动图直接来一个单个的图就行，就是最终的那状态。然后，中间有一些他卖掉的，就得从他卖掉那年之后就不再算了

之后还补充了两轮要求：给简单版加上数据来源说明与免责声明（"作为 opencode 使用的代码范例，不具有投资等其他作用"），以及基于以上内容写一篇介绍 opencode 用法的文章——也就是你现在正在读的这篇。可见"好的需求是磨出来的"，AI 对话里迭代需求是常态，opencode 每轮都能在保留上下文的前提下增量修改，这是它比单次提问好用得多的地方。

一些建议

别把 AI 当权威数据库。AI 擅长的是"搜索+整理+排版"，数字本身要让它去抓原始页面核对，而不是凭记忆生成。这次所有关键数字都来自抓到的词条及其引用的报道。
告诉 AI 怎么处理不确定。在任务描述里直接写"不同来源不一致就并列标出，拿不准就写待确认，不许编"，能显著减少幻觉。
可视化先确认数据再画图。先有结构化的表格数据，再让 AI 写绘图脚本，比边画边猜靠谱得多。
交付物分层。完整版给需要细节的人，简单版给只想扫一眼的人，调研原稿留作备用。

总结一下

这篇就是一次演示：用 opencode 把"马斯克商业版图"从"一堆链接"变成"一份带表带图的 Markdown 报告"，中间穿插了研究代理调研、来源核实、图表生成和严谨性处理。方法论本身可以复用到任何商业信息汇总场景——行业研究、竞品分析、公司尽调都可以套这套流程。

需要强调的最后一件事：AI 整理的信息适合做参考、做入门、做框架，但不适合直接拿来决策。 关键数据请回到一手来源核实。

十年之后-纪念罗明非博士与雷霄骅同学

2026-08-06T20:00:00+08:00

2016年7月17日，中国传媒大学的在读博士雷霄骅同学，猝然离世。2016年7月20日，中国地质大学（北京）毕业的罗明非博士，在西藏的野外工作中遇险离开了这个世界。

整整十年过去了。而这个七月，我忙着各种学习和训练，居然把这两个日子都忘了。直到今天看日历，才猛然想起，心里一下子空落落的。

十年，足够一个人从学生到工作，足够很多记忆被生活的琐碎冲淡。今天就写下来，即是为了纪念。

雷霄骅：传道授业的开源教程作者

雷霄骅（1991年10月20日-2016年7月17日），2007年考入中国传媒大学，大二的时候，2008年，就注册了CSDN网站，陆续在上面开始分享自己的学习心得和经验，后来还利用GitHub Pages建立了自己的个人网站。后来他在本校读研读博，学的是通信与信息系统专业，做的是数字视频技术方向，尤其关注 FFmpeg 相关的开发。

他是个特别乐于分享和帮助别人的人，习惯以教促学，在考试之前还会给需要帮助的同学辅导答疑。他的很多相关的经验呢，也都写成了博客文章，很早就发在了网上。现在相关领域的不少程序员当年可能都看过他的教程——在那个资料匮乏的年代，他把自己研究音视频的心得一点点写成博客，做成开源项目（TIandSI、VideoEye），还发表了多篇国际会议论文。他在技术圈里粉丝众多，因为他分享的内容曾经帮助了无数初学音视频的年轻人。

图片

在2013年到2016年的这段时间当中，他的GitHub上有266条的提交，典型的工作模式是深夜加凌晨，这266条提交当中有62条是半夜12点到早上5点，占了23%。然后还有一些是凌晨一点的，有34条都是凌晨一点左右。而GitHub只是他开发和写作的一部分内容，在其他网站还有更多内容创作，以及研究工作等等。可见他的工作强度是很大的。

2016年7月16日，晚上九点多，雷同学进了实验室，凌晨三点被人发现倒在电梯口，早上七点多同学才得知消息。一个26岁的年轻人，就这么走了，留下了技术文档、开源代码，和无数被他带进门的后辈。

图片

2026年8月4日，FFmpeg 9.0 正式发布，版本代号"Lei"，来纪念他。

罗明非：投身野外工作的地质学家

罗明非（1982年12月22日-2016年7月20日）生于四川广元，，本科就读于成都理工大学，后来在中国地质大学（北京）读的博士，我记得他是莫院士的学生。

图片

上图是2014年12月5日晚上0点22分，我半夜醒来，发现他在看文献，拍了背影。

2015年他博士毕业后回了成都，记得应该是在2015年7月8号那天，他正式到中国地质调查局成都地质调查中心上班工作了。

他是那个年代里典型的地质人——不是坐在实验室里只靠测试数据做研究，而是常年在野外，隔壁高山峡谷。

地质工作是辛苦的，也是危险的。海拔四五千米的高原，荒无人烟的沟谷，是可能面对的自然灾害，野兽、恶劣的天气环境，有时候还可能有一些毒虫叮咬等等……

「平沙落日大荒西，陇上明星高复低。」

「浩浩乎，平沙无垠，夐不见人。河水萦带，群山纠纷。黯兮惨悴，风悲日曛。蓬断草枯，凛若霜晨。」

这些也都是地质工作者日常面对的。

2016年7月20日，罗博士在西藏措勤开展野外工作时遭遇车祸，因公殉职，年仅34岁。同时遇难的还有2014年博士毕业于地大北京的孟繁一博士（1988年2月10日-2016年7月20日）。当时罗博士刚结婚不到一年，孩子还没出生。

他的QQ空间上，在2016年3月15号那天早上9点，写的是「你真正做成一件事之前，存在感是一种可以被人随意践踏的东西。」可能工作的生活未必很舒心和顺利，他QQ空间里上一条发的和工作相关的内容是「上班第二天！」还是在2015年的7月9号那天早上也是9点钟发的。

一些多余的话

这两位一个是校友，一个是我寝室的室友；一个比我年轻几岁，一个比我大几岁；一个是写代码，从事代码开发相关的。另一个是学地质，自然科学领域的。

我本科是中国传媒大学摄影专业的艺术学学士，我读博是在中国地质大学北京读的地球科学的理学博士。

所以和这两位就算都有了一点交集，只是没有他们那么优秀，也没有那么闪耀，但在这两个人身上，能看到自己的投射。

2023年11月，我记得是29号，我当年读书时候的同学，一起拆机装机写代码的伙伴，李解博士，在刚博士毕业没几个月之后，突发疾病意外离世了。

人走了之后，留下那些都是成果，文章啊，或者代码项目等等。可是人应该比这些更丰富，活着的时候一定要好好活着，不能留任何遗憾。

只能说，人生无常，身边的人都值得珍惜。尽量不该跟人发脾气，我脾气暴躁，经常容易发怒，不仅伤害自己也会伤到身边的人。后来就尽量控制一下，尽量不去发脾气。

考虑调整作息，我现在是基本上九十点钟基本就睡觉，然后早上四五点钟起来，每天一定要吃早饭，哎呀，还得争取把自己体重从200多斤尽量降下来。

如果遇到了不高兴的事儿，就直接的当面儿偿还就好了。这么大碾碎了，再用年轻时候那种「肢体说服教育」确实不行，但言语上还是可以不落下风的，遇到事情，如果不算什么太严重的，不如当场就投桃报李。反正我是这么想的，千万不能有事儿憋着，忍着，以后万一没机会了呢？

利用Python代码对一些力学上的定义和概念进行可视化

2026-08-05T21:00:00+08:00

想当年，我因为种种原因从理科基地班被人清退了，跑到了普通的班级。有一门课，我大半学期都没赶上，可期末还得参加考试，于是就去听了几次课。那老师讲课，口音实在太重了，把"挠度"说成"老陆"，我基本上是听不懂的。当时还有个同学说他"嘴里有棉裤"。现在想想，这么说人家其实不太好，可当时确实是真听不明白。

说起来，现在有些高校在申请教师资格的时候，好像已经不要求普通话二级甲等以上了？有博士学位是不是就免了？记不太清这个标准了。但不管怎么说，还是希望高校教师能尽量把普通话说清楚，至少得让学生听懂。当时那位老师讲的东西，我好多都理解得不透，好在对付着考试算是过去了。

不过大学里应对考试是一回事，真学没学到东西又是另一回事。有的老师不负责任，直接给原题。有的学生觉得这老师好啊，给原题能过，然后就让大家背答案，ABCD对应1234，还真有孩子就背了。这可不是好事，到最后就是自己糊弄自己，根本没学明白，把1234背下来往那儿一放，既糊弄自己又糊弄家长。可孩子们那会儿不懂事，还觉得老师好。这种现象，除了抨击一下，也不好说别的。

咱只能想想自己当年没学好。后来我就打算再了解一下，补补课。这一补，就有了今天这些内容。本来想着严格对应地质现象来讲，可那样太专门、太枯燥，还显得有点太端着。何况我已经离地学很远了，所以就通用地讲讲这些概念，用代码画图，把力学里这些定义和概念直观地摆出来。

顺便说一句，这篇也想做个示范。我学的专业跟计算机离得挺远，可这些年，靠逐渐探索出来的编程语言方面的一点浅薄经验，画图、做算法、分析数据、验证想法，省了不少事儿。所以说，就算不是计算机相关专业，学一点编程相关内容，对学自己本专业的东西，往往也是能帮上忙的。

那这些概念到底是啥呢？一说材料力学、固体力学，很多人就头大，觉得全是公式。其实这几个最基础的概念，全是身边的事儿：拉一根橡皮筋，拧一个瓶盖，用扳手拧螺丝，掰一根钢筋。咱们今天就把应力、应变、力矩、力偶这几个词一个个拆开，配图配上代码，试试进行可视化。

应力：单位面积上分摊到的力

先想一个画面：一根橡皮筋，你用手往两边拉。你觉得"手在用力"，可实际上，这股力不是集中在某一个点上，而是摊在整个截面上。把"力"除以"截面积"，就是应力（stress），记作 $\sigma$：

\[\sigma = \frac{F}{A}\]

单位是帕斯卡（Pa），也就是牛每平方米（N/m²）。一个大气压大概是十万帕，工程上常用兆帕（MPa）。

应力有两种最基础的：

正应力 $\sigma$：力垂直作用在面上，拉是拉应力，压是压应力。
切应力 $\tau$：力贴着面（相切）蹭过去，就像拿刀片刮表面那样。

你站着不动，体重压在两脚上，脚底承受的那个"压强"，本质上就是一种正应力。穿细跟的鞋踩到别人脚，受力面积小，压强大——这就是应力大，挨踩的疼啊。

这张图左边是正应力：一个正方形小块，左右两边受拉力往外拽；右边是切应力：上下两个面各受一个切向力，方向正好相反，一个往右一个往左，像是在往两个相反的方向"切"。中间那个 $\sigma$ 和 $\tau$，就是单位面积上分到的力。

下面的代码可以自己跑，画出同样的一张图：

import numpy as np
import matplotlib.pyplot as plt
import matplotlib.patches as mpatches
import os

plt.rcParams['font.sans-serif'] = ['Arial Unicode MS', 'Hiragino Sans GB', 'Heiti TC', 'Songti SC', 'Microsoft YaHei']
plt.rcParams['axes.unicode_minus'] = False
os.makedirs('images', exist_ok=True)

DARK = '#2c3e50'; RED = '#e74c3c'

def force_arrow(ax, x, y, dx, dy, color=RED, lw=2.2):
    ax.add_patch(mpatches.FancyArrowPatch(
        (x, y), (x+dx, y+dy), arrowstyle='-|>', mutation_scale=20, lw=lw, color=color))

fig, axes = plt.subplots(1, 2, figsize=(11, 5))
s = 1.0

ax = axes[0]  # 正应力
ax.add_patch(mpatches.Rectangle((-s, -s), 2*s, 2*s, fc='#dff0f7', ec=DARK, lw=2))
for y in (0.45, 0.0, -0.45):
    force_arrow(ax, -s, y, -1.0, 0)
    force_arrow(ax,  s, y,  1.0, 0)
ax.text(0, 0, 'σ', ha='center', va='center', fontsize=24, color=DARK)
ax.text(0, -2.0, '拉力 ÷ 截面积', ha='center', fontsize=13, color=RED)
ax.set_xlim(-3, 3); ax.set_ylim(-2.5, 2.5); ax.set_aspect('equal'); ax.axis('off')
ax.set_title('正应力 σ：力垂直作用在面上', fontsize=15)

ax = axes[1]  # 切应力
ax.add_patch(mpatches.Rectangle((-s, -s), 2*s, 2*s, fc='#fdf0d6', ec=DARK, lw=2))
for x in (-0.75, -0.25, 0.25):
    force_arrow(ax, x,  s,  0.55, 0)    # 顶面切向往右
    force_arrow(ax, x, -s, -0.55, 0)   # 底面切向往左
ax.text(0, 0, 'τ', ha='center', va='center', fontsize=24, color=DARK)
ax.text(0, -2.0, '切向力 ÷ 截面积', ha='center', fontsize=13, color=RED)
ax.set_xlim(-3, 3); ax.set_ylim(-2.5, 2.5); ax.set_aspect('equal'); ax.axis('off')
ax.set_title('切应力 τ：力平行作用在面上', fontsize=15)

fig.suptitle('应力 = 单位面积上分摊到的力', fontsize=17, y=1.02)
fig.tight_layout()
plt.savefig('images/stress.png', dpi=150, bbox_inches='tight')

应变：变形量除以原来的尺寸

光有力还不够，还得看东西被"抻"了多少。一根橡皮筋原长 $L$，拉长了 $\Delta L$，那"变形程度"就是应变（strain）：

\[\varepsilon = \frac{\Delta L}{L}\]

关键是除以原来的长度，这样不管东西本身多长，都能拿同一把尺子比较变形的剧烈程度。应变没有单位，是个比值。

跟应力对应，应变也有正应变和切应变：

正应变 $\varepsilon$：拉长或压短的比例。
切应变 $\gamma$：形状被"剪切"倾斜的程度，就是那个角度的变化量。

左图：虚线是原来的样子，实线是拉长之后的，标了原长 $L$ 和伸长量 $\Delta L$。右图：虚线是原来的方块，实线是被"错开"了的平行四边形，顶边整体滑移了一段，那个绿色的小角度 $\gamma$ 就是切应变。

代码也不长：

import numpy as np
import matplotlib.pyplot as plt
import matplotlib.patches as mpatches
import os

plt.rcParams['font.sans-serif'] = ['Arial Unicode MS', 'Hiragino Sans GB', 'Heiti TC', 'Songti SC', 'Microsoft YaHei']
plt.rcParams['axes.unicode_minus'] = False
os.makedirs('images', exist_ok=True)

DARK = '#2c3e50'; RED = '#e74c3c'; BLUE = '#2980b9'; GRAY = '#95a5a6'; GREEN = '#2ecc71'

def force_arrow(ax, x, y, dx, dy, color=RED, lw=2.2):
    ax.add_patch(mpatches.FancyArrowPatch(
        (x, y), (x+dx, y+dy), arrowstyle='-|>', mutation_scale=20, lw=lw, color=color))

fig, axes = plt.subplots(1, 2, figsize=(11, 5))
L = 2.0; dL = 0.8

ax = axes[0]  # 正应变
ax.add_patch(mpatches.Rectangle((-L/2, -0.6), L, 1.2, fill=False, ls='--', ec=GRAY, lw=1.8))
ax.add_patch(mpatches.Rectangle((-L/2 - dL/2, -0.6), L+dL, 1.2, fc='#dff0f7', ec=BLUE, lw=2))
for y in (0.3, -0.3):
    force_arrow(ax, -L/2 - dL/2, y, -0.9, 0)
    force_arrow(ax,  L/2 + dL/2, y,  0.9, 0)
ax.annotate('', xy=(L/2 + dL/2, 1.35), xytext=(L/2, 1.35),
            arrowprops=dict(arrowstyle='<->', color=BLUE, lw=1.6))
ax.text(L/2 + dL/4, 1.6, 'ΔL（伸长量）', ha='center', fontsize=12, color=BLUE)
ax.annotate('', xy=(L/2, -1.1), xytext=(-L/2, -1.1),
            arrowprops=dict(arrowstyle='<->', color=GRAY, lw=1.6))
ax.text(0, -1.5, '原长 L', ha='center', fontsize=12, color=GRAY)
ax.text(L/2 + dL/2 + 0.9, 0, 'ε = ΔL / L', ha='left', va='center', fontsize=14, color=DARK)
ax.set_xlim(-3.3, 5.5); ax.set_ylim(-2.2, 2.2); ax.set_aspect('equal'); ax.axis('off')
ax.set_title('正应变 ε：拉长（或压短）的比例', fontsize=15)

ax = axes[1]  # 切应变
shift = 0.9; H = 1.2
ax.add_patch(mpatches.Rectangle((-L/2, -H/2), L, H, fill=False, ls='--', ec=GRAY, lw=1.8))
corners = [(-L/2, -H/2), (L/2, -H/2), (L/2+shift, H/2), (-L/2+shift, H/2)]
ax.add_patch(mpatches.Polygon(corners, closed=True, fc='#fdf0d6', ec=BLUE, lw=2))
for x in (0.1, 0.5, 0.9):
    force_arrow(ax, x,  H/2,  0.6, 0)   # 顶面切向往右
    force_arrow(ax, x, -H/2, -0.6, 0)   # 底面切向往左
gamma = np.degrees(np.arctan2(H, shift))
ax.add_patch(mpatches.Arc((-L/2, -H/2), 0.9, 0.9, theta1=gamma, theta2=90, color=GREEN, lw=2))
th_mid = np.radians((gamma + 90) / 2)
ax.text(-L/2 + 0.55*np.cos(th_mid), -H/2 + 0.55*np.sin(th_mid), 'γ', fontsize=16, color=GREEN)
ax.text(-L/2+shift/2, 1.35, '上边沿横向滑移', ha='center', fontsize=12, color=BLUE)
ax.text(L/2+1.9, 0, 'γ = 滑移量 / 高度', ha='left', va='center', fontsize=13, color=DARK)
ax.set_xlim(-2.2, 5.8); ax.set_ylim(-2.2, 2.4); ax.set_aspect('equal'); ax.axis('off')
ax.set_title('切应变 γ：形状发生"剪切"倾斜', fontsize=15)

fig.suptitle('应变 = 变形量与原来尺寸的比值', fontsize=17, y=1.02)
fig.tight_layout()
plt.savefig('images/strain.png', dpi=150, bbox_inches='tight')

应力除以应变，就是弹性模量 $E$，$E = \sigma / \varepsilon$。它衡量材料"有多硬"——同样抻它，应力涨得快的，就是难拉动的硬材料。在弹性阶段，胡克定律成立：$\sigma = E\varepsilon$。这不就是中学学的弹簧嘛，F 换成 σ，伸长量换成 ε，比例系数换成 E。

应力-应变曲线：每种材料各有各的"脾气"

把一根材料样品慢慢拉，一边记录应力一边记录应变，画出来的就是应力-应变曲线。这条曲线基本就是材料的"性格画像"。

图里粗略画了三种典型材料：

低碳钢（韧性材料）：先是笔直的弹性段，撤力就复原；然后到屈服点 $\sigma_y$，过了这点材料就"回不去了"，产生永久变形，曲线上有个平台；再往后是强化阶段，能扛的应力继续涨到抗拉强度 $\sigma_u$；最后某处开始变细（颈缩），没扛多久就断了。整个过程"能屈能伸"，断之前有大量变形预警，这就是韧性。
铸铁（脆性材料）：几乎是一条直线，没怎么变形，"咔嚓"一下就断了。看着硬，其实很脆，没有预警。
橡胶（高弹性材料）：弹性模量很小，软，能抻出好几倍的长度不断，曲线是条往上翘的弧线。

右上角放了一个弹性段的放大图，要不然低碳钢和铸铁的弹性段挤在左边太窄了，根本看不清。

import numpy as np
import matplotlib.pyplot as plt
import os

plt.rcParams['font.sans-serif'] = ['Arial Unicode MS', 'Hiragino Sans GB', 'Heiti TC', 'Songti SC', 'Microsoft YaHei']
plt.rcParams['axes.unicode_minus'] = False
os.makedirs('images', exist_ok=True)

DARK = '#2c3e50'; BLUE = '#2980b9'; RED = '#e74c3c'; GREEN = '#2ecc71'
fig, ax = plt.subplots(figsize=(11, 6))

# 低碳钢：弹性→屈服平台→强化→颈缩→断裂
ey, sy = 0.002, 400.0
E = sy / ey
e1 = np.linspace(0, ey, 60); s1 = E * e1
e2 = np.linspace(ey, 0.02, 40); s2 = np.full_like(e2, sy)
t = np.linspace(0, 1, 120) ** 0.9
e3 = 0.02 + (0.18 - 0.02) * t; s3 = sy + (600 - sy) * t
t2 = np.linspace(0, 1, 60) ** 1.4
e4 = 0.18 + (0.22 - 0.18) * t2; s4 = 600 - (600 - 500) * t2
ax.plot(np.concatenate([e1, e2, e3, e4]), np.concatenate([s1, s2, s3, s4]),
        color=BLUE, lw=2.4, label='低碳钢（韧性材料）')

# 铸铁（脆性）：近似直线，应变很小就直接脆断，没有平台
e_ci = np.linspace(0, 0.0045, 60)
s_ci = 33000 * e_ci * (1 - 20 * e_ci)
ax.plot(e_ci, s_ci, color=RED, lw=2.4, label='铸铁（脆性材料）')

# 橡胶（高弹性）
e_r = np.linspace(0, 1.2, 120)
ax.plot(e_r, 8.0 * (np.exp(1.6 * e_r) - 1), color=GREEN, lw=2.4, label='橡胶（高弹性材料）')

ax.scatter([ey], [sy], color=BLUE, s=40, zorder=5)

ax.text(0.10, 520, '强化阶段', fontsize=12, color=BLUE)
ax.text(0.20, 360, '颈缩', fontsize=12, color=BLUE)
ax.text(0.55, 18, '橡胶：能抻很长不断', fontsize=11, color=GREEN)

ax.set_xlabel('应变 ε', fontsize=13)
ax.set_ylabel('应力 σ（MPa）', fontsize=13)
ax.set_title('应力-应变曲线：不同材料各有各的"脾气"', fontsize=15)
ax.set_xlim(0, 1.4); ax.set_ylim(0, 700); ax.grid(True, alpha=0.3)
ax.legend(loc='upper left', fontsize=11)

# 嵌入放大图：弹性→屈服→强化 的前半段
axins = ax.inset_axes([0.47, 0.38, 0.50, 0.50])
e_zoom = np.concatenate([e1, e2, e3[:12]])
s_zoom = np.concatenate([s1, s2, s3[:12]])
axins.plot(e_zoom, s_zoom, color=BLUE, lw=2.2)
axins.plot(e_ci, s_ci, color=RED, lw=2.2)
axins.axvline(x=ey, color=BLUE, ls='--', lw=1.0, alpha=0.6)
axins.scatter([ey], [sy], color=BLUE, s=30, zorder=5)
axins.annotate('屈服点 σy', xy=(ey, sy), xytext=(0.006, 320),
               arrowprops=dict(arrowstyle='->', color=DARK, lw=1.2), fontsize=9)
axins.annotate('屈服阶段\n（平台）', xy=(0.011, 400), xytext=(0.015, 350),
               arrowprops=dict(arrowstyle='->', color=DARK, lw=1.2), fontsize=9, color=BLUE)
axins.annotate('强化阶段', xy=(0.023, 440), xytext=(0.019, 460),
               arrowprops=dict(arrowstyle='->', color=DARK, lw=1.2), fontsize=9, color=BLUE)
axins.set_xlim(0, 0.03); axins.set_ylim(0, 520)
axins.set_xlabel('应变 ε', fontsize=9)
axins.set_ylabel('应力 σ', fontsize=9)
axins.grid(True, alpha=0.3)
axins.set_title('弹性→屈服→强化 放大', fontsize=10)
axins.tick_params(labelsize=8)

fig.tight_layout()
plt.savefig('images/ss_curve.png', dpi=150, bbox_inches='tight')

工程上选材料，就是在看这条曲线：要扛得住别断，看强度；要能变形缓冲不断，看韧性；要硬，看弹性模量。

力矩：让物体转动的"扭转本领"

前面说的力，是让物体平移的。可拧螺丝、开门、转方向盘，需要的不是"拽"，而是"拧"。拧的本事叫力矩（moment，也叫扭矩），公式是：

\[M = F \times d\]

$F$ 是力，$d$ 是力臂——从转动轴到力的作用线的垂直距离。单位是牛米（N·m）。

图上这个扳手最好理解了：螺母转轴在左端，你在扳手末端用力 F 往下压。力臂 d 就是转轴到那条竖直力作用线的垂直距离。力矩让扳手绕着螺母转。

这里面有个特别实用的结论：力臂越长越省力。所以加长扳手（或者套一根管子加长力臂）就能撬动更紧的螺丝；门把手都装在离合页远远的一边，开起来才省劲。这些都是力矩 $M = F \times d$ 在起作用。

import numpy as np
import matplotlib.pyplot as plt
import matplotlib.patches as mpatches
import os

plt.rcParams['font.sans-serif'] = ['Arial Unicode MS', 'Hiragino Sans GB', 'Heiti TC', 'Songti SC', 'Microsoft YaHei']
plt.rcParams['axes.unicode_minus'] = False
os.makedirs('images', exist_ok=True)

DARK = '#2c3e50'; RED = '#e74c3c'; BLUE = '#2980b9'; GREEN = '#2ecc71'; GRAY = '#95a5a6'
fig, ax = plt.subplots(figsize=(10, 6))

ax.add_patch(mpatches.Circle((0, 0), 0.32, fc='#bdc3c7', ec=DARK, lw=2))
ax.add_patch(mpatches.Circle((0, 0), 0.14, fc=DARK))
ax.plot([0, 3.4], [0, 0.65], color=DARK, lw=8, solid_capstyle='round')

fx, fy = 3.4, 0.65
ax.add_patch(mpatches.FancyArrowPatch((fx, fy+0.9), (fx, fy-0.6),
             arrowstyle='-|>', mutation_scale=20, lw=3, color=RED))
ax.text(fx+0.18, fy+0.45, '力 F', fontsize=15, color=RED)
ax.add_patch(mpatches.FancyArrowPatch((0.42, 0), (3.4, 0), arrowstyle='<|-|>',
             mutation_scale=18, lw=1.6, color=BLUE))
ax.text(3.5, 0.0, '力臂 d', fontsize=14, color=BLUE, ha='left', va='center')
# 转动方向：力向下压，扳手绕螺母顺时针转
th = np.linspace(np.radians(15), np.radians(-75), 80)
ax.plot(1.0*np.cos(th), 1.0*np.sin(th), color=GREEN, lw=2.2, solid_capstyle='round')
t = np.radians(-75)
ax.add_patch(mpatches.RegularPolygon((1.0*np.cos(t), 1.0*np.sin(t)), 3, radius=0.10,
             orientation=np.radians(np.degrees(np.arctan2(-np.cos(t), np.sin(t)))), color=GREEN))
ax.text(0.25, -0.75, 'M = F × d', fontsize=16, color=GREEN, fontweight='bold')
ax.text(0.3, -1.15, '（力臂越长越省力）', fontsize=12, color=GREEN)
ax.text(0, -2.0, '固定螺母', ha='center', fontsize=12, color=GRAY)
ax.set_xlim(-1.3, 5.2); ax.set_ylim(-2.4, 2.0); ax.set_aspect('equal'); ax.axis('off')
ax.set_title('力矩（扭矩）：让物体转动的"扭转本领"', fontsize=15)
fig.tight_layout()
plt.savefig('images/moment.png', dpi=150, bbox_inches='tight')

力偶：一对力，只转不挪

有时候你会碰上一种特殊的"拧法"：两个大小相等、方向相反的力，平行但不共线，一起作用在一个物体上。这一对力叫力偶（couple）。

图上这块东西，左边一个力往上拽，右边一个大小一样、方向相反的力往下压。两股力加起来合力正好是零——所以它不会整体移动；但这一拽一压，恰好让它一个劲地转。这种"只转不挪"的效果，叫力偶矩：

\[M = F \times d\]

$d$ 是那两个力之间的垂直距离。有意思的是，力偶矩跟你的参考点选在哪无关，只要这一对力在，拧的效果就是固定的。拧瓶盖、双手搓方向盘、拧毛巾，靠的全是力偶。

静态图的代码一并放上：

import numpy as np
import matplotlib.pyplot as plt
import matplotlib.patches as mpatches
import os

plt.rcParams['font.sans-serif'] = ['Arial Unicode MS', 'Hiragino Sans GB', 'Heiti TC', 'Songti SC', 'Microsoft YaHei']
plt.rcParams['axes.unicode_minus'] = False
os.makedirs('images', exist_ok=True)

DARK = '#2c3e50'; RED = '#e74c3c'; BLUE = '#2980b9'; GRAY = '#95a5a6'
fig, ax = plt.subplots(figsize=(6, 5))
W, H = 3.0, 1.2

ax.add_patch(mpatches.Rectangle((-W/2, -H/2), W, H, fc='#dff0f7', ec=DARK, lw=2))
# 左边力向上拽，右边力向下压：大小相等、方向相反、平行不共线
ax.add_patch(mpatches.FancyArrowPatch((-W/2, -H/2), (-W/2, H/2),
             arrowstyle='-|>', mutation_scale=22, lw=3, color=RED))
ax.add_patch(mpatches.FancyArrowPatch(( W/2,  H/2), ( W/2, -H/2),
             arrowstyle='-|>', mutation_scale=22, lw=3, color=RED))
ax.text(-W/2 - 0.28, 0, 'F', fontsize=15, color=RED, ha='right', va='center')
ax.text(W/2 + 0.28, 0, 'F', fontsize=15, color=RED, ha='left', va='center')

ax.annotate('', xy=(-W/2, -H/2 - 0.5), xytext=(W/2, -H/2 - 0.5),
            arrowprops=dict(arrowstyle='<->', color=BLUE, lw=1.6))
ax.text(0, -H/2 - 0.85, '垂直距离 d', ha='center', fontsize=12, color=BLUE)
ax.text(0, 0, '力偶矩 M = F × d\n只转动，不移动', ha='center', va='center', fontsize=13, color=DARK)

ax.set_xlim(-2.6, 2.6); ax.set_ylim(-1.9, 1.9); ax.set_aspect('equal'); ax.axis('off')
ax.set_title('力偶：两个大小相等、方向相反的平行力', fontsize=15)
fig.tight_layout()
plt.savefig('images/couple.png', dpi=150, bbox_inches='tight')

下面这张动图更直观，力偶作用在一个方块上，方块就这么转起来了，可它的位置一直没挪：

import numpy as np
import matplotlib.pyplot as plt
import matplotlib.patches as mpatches
from matplotlib.animation import FuncAnimation
import os

plt.rcParams['font.sans-serif'] = ['Arial Unicode MS', 'Hiragino Sans GB', 'Heiti TC', 'Songti SC', 'Microsoft YaHei']
plt.rcParams['axes.unicode_minus'] = False
os.makedirs('images', exist_ok=True)

DARK = '#2c3e50'; RED = '#e74c3c'
fig, ax = plt.subplots(figsize=(5.0, 5.0))
frames = 30; W, H = 2.2, 1.0

def draw_frame(i):
    ax.clear()
    ang = -np.radians(i * 360 / frames)   # 左手上推、右手下压，整体顺时针转
    R = np.array([[np.cos(ang), -np.sin(ang)], [np.sin(ang), np.cos(ang)]])
    corners = np.array([[-W/2, -H/2], [W/2, -H/2], [W/2, H/2], [-W/2, H/2]])
    ax.add_patch(mpatches.Polygon(corners @ R.T, closed=True, fc='#dff0f7', ec=DARK, lw=2))
    p1 = np.array([-W/2, 0]) @ R.T
    p2 = np.array([ W/2, 0]) @ R.T
    v = np.array([0, 1]) @ R.T
    ax.add_patch(mpatches.FancyArrowPatch(p1, p1 + v, arrowstyle='-|>', mutation_scale=22, lw=2.6, color=RED))
    ax.add_patch(mpatches.FancyArrowPatch(p2, p2 - v, arrowstyle='-|>', mutation_scale=22, lw=2.6, color=RED))
    ax.text(0, 0, '力偶矩 M\n只转动，不移动', ha='center', va='center', fontsize=12, color=DARK)
    ax.set_xlim(-2.3, 2.3); ax.set_ylim(-2.3, 2.3); ax.set_aspect('equal'); ax.axis('off')

anim = FuncAnimation(fig, draw_frame, frames=frames, interval=60)
anim.save('images/couple_rotate.gif', writer='pillow', fps=15)

串起来记

把这几个概念用一句话串起来：

应力是单位面积上分摊到的力，应变是变形量相对于原尺寸的比例；力矩是力乘力臂的"拧"的本领，力偶是一对力只转不挪的施加力的方法。

公式不用死记，把图看明白就行：应力应变说的是一块材料内部"扛了多少、变了多少"，力矩力偶说的是"拿什么拧、怎么拧"。这几个概念弄明白了，回头再看受力、变形的各种例子，就不至于两眼一抹黑。

写这篇，除了讲清楚这几个概念，其实更想做个示范：就算不是计算机相关专业，也完全可以考虑学一点编程相关内容。拿它当个趁手的工具，画个图、算个数、验证一下想法，学自己专业的东西，往往也能帮上不少忙。这活儿不挑专业，门槛也没想象中那么高，有兴趣就能上手。

配图生成的完整代码就在上面的各个代码块里，复制就能跑。要是有讲得不清楚的地方，欢迎指正。

高校教师建议大学生不要被自己已有的认知给束缚住

2026-08-04T00:00:00+08:00

上课的时候，会经常跟大家提《纪效新书》里戚继光将军讲的一句话，叫"心有外物而不化，自恃旧习以为佳"。

先把话说清楚，这话不是抠出来的原话，原文未必是这么写的，是我把两句搁一块儿，显得对仗。意思倒不差：心里头有了之前学来的东西，就不太愿意接受新的了，不愿意改进，不愿意演化。还总凭借着自己那点旧经验、旧知识，觉得那才是好的，新东西一概不学。保守，指的就是这个。

说白了，就是人不能被自己已有的认知给束缚住。这，也是今天想说的主题。

二十四节气，有的人打小就会背。春分秋分，芒种白露，张口就来。可你想过没有，这套东西本来是黄河流域那一带的农耕经验，咱这疆域，北边到漠河，南边到南海诸岛，西边到帕米尔高原，还有那雪域高原，从东北到岭南，气候能差出十万八千里去。真要继续严格套用到咱们所有的版图上，恐怕就未必总是那么合适。

类似的事儿我自己中学时就琢磨过。那时候地理课学地球仪，我推出来一个理儿：南半球那边，尤其南回归线以南，中午的太阳是在北边的。"山南水北为阳"，这是北半球的说法，到了南回归线以南，日照方向整个反过来了，这套说法也得整个反过来才对。

我跟老师说了，老师来了一句："谁见过在北边的太阳啊？"同学们哄堂大笑。我不死心，又去问语文老师，说这"山南水北为阳"，在南半球是不是就得反过来。结果又让人笑话一顿。

放到现在我当然知道，我这推理是对的。可当时没一个人信。你说老师是坏吗？肯定不是。同学有恶意吗？也肯定没有。他们就是觉得，太阳它就该在南边，从来如此，天经地义。

昨天太热了，我去商场里吹冷气，顺便找了里面一个饭馆吃饭。旁边一桌坐着一对老夫妻带着孙子。老太太语重心长跟孙子讲：不该吃雪糕，不该喝冰水儿，这天再热，商场里也不该开空调，因为夏天本来就该热，多出出汗排排毒，这才是宇宙大道，等等等等，一套一套的。我就在旁边，喝着冰水，吹着商场里的空调，一边听着。

老太太有恶意吗？肯定没有。在她那儿，她那套认知就是天经地义，就是不能改的宇宙大道。

可咱们得想想，人类这点认知，真没多大。一个人一辈子能走的地方再多，顶多也就是地球表面；一个人能学的见的再多，顶多也就是有限的内容。就算是耄耋之年，所知所见，应该也是有限，哪能自己觉得对就都得叫宇宙大道。连"宇宙"这俩字到底咋回事，可能有的人都还没整明白呢。

老太太提倡不开空调这事儿，在那一代人的眼里，可能就是完全正确，没有任何问题。咱如果觉得有问题，问题也不在知道得少，毕竟老人家吃过见过，肯定是多知多懂。而且就算是知道得少，可能很多人都是。具体的问题在于，觉得自己知道的就已经是全部了，再没有别的可能。这才是最要命的。

我这些年有个习惯，喜欢学点别的领域的东西，见到什么人，如果人家方便，都会尽量跟人打听打听，某些我不太理解的事情都是咋回事。就希望自己能不那么浅薄，多学点儿。就像我写的东西，很可能有错，而且不少。这真不是扯虚的，要是大家能给指出来，真是欢迎。

当然了，也得承认，都是平常人，看见别人否定自己的时候，本能地就抵触。第一反应是先反驳，先找理由，哪怕心里知道人家说得对，嘴上也得犟两句。人天生就这毛病，遇到事先否定别人，见什么都习惯性挑刺。

这本能不见得多高级，说白了可能就是动物性，是自我保护。可人要是能超脱一点，跟这种本能掰掰手腕，不被它牵着走，那就高级了。别人说你不对，先别急，先听听，先想想有没有道理。就算人家说的确实是错了，你其实也犯不着当场翻脸。大学里啥观点的人都有，正好拿这儿练手，控制好自己的情绪。

前头说宇宙大道，说"宇宙"这俩字。宇是空间，宙是时间，我记得好像是这么个意思，记不清了。世上到底有没有「宇宙大道」这么个东西，可能有，但难道就只是「夏天不该开空调」么？

我念了些年书，闯了几年江湖，大概能确定知道的，就是自己知道的实在太少了。

这话说给年轻的同学们，希望大家千万别把自己束缚住。

高校教师希望大一新生尽快摆脱学生气的一些建议

2026-08-02T00:00:00+08:00

我毕业的时候已经三十出头了，现在四十来岁了，大概算是标准的中老登。这十来年有个现象挺有意思：很多人见了我，猜的年龄比实际要小几岁。我媳妇分析过这件事，说一方面是因为我比较胖，脸上褶子没那么多，另一方面是我身上总有一股傻气——有人说就是那种学生气，一看就觉得这人还在读书。

我想了想，人家说的可能对。学生气这个东西，有几个特点。守规则、听话、在意别人怎么评价你。越是学习好、读书好的孩子，这个特点越明显。老师布置什么就做什么，规则说什么就照着执行，不太去考虑这规则是谁定的、为什么这么定、定规则的人有没有别的心思。就老老实实做一个乖乖的人。

为什么校招比社招受欢迎

很多单位喜欢校招，不太愿意社招。这跟学生气有关系。

从社会上招聘的人，风吹雨打过来的，大浪淘沙。他们见识过一些事——可能吃过亏、上过当、被画过大饼后来发现饼是纸做的。这样再来一轮的时候，他就不那么容易被说服了。你跟他说好好干有前途，他可能会问具体是什么前途，有没有写在合同里。

学校刚毕业的孩子不一样。心思单纯，好管理，也比较容易被一个愿景打动。你给他画个饼，他可能真信。有的地方人力资源部门的一些操作，在社会人眼里一眼就看穿了，但对学生来说，他可能根本不觉得有什么问题。社招来的人里，有的跟好几家东家打过劳动仲裁、甚至起诉过，见招拆招，什么都不怕。刚毕业的学生遇到这种事，第一反应往往是怕，而且也不知道该怎么处理。

今年年初，我们班上一个大二的孩子第一次自己去医院挂号。在这之前从来没自己挂过号。你知道吗，有的孩子到了大二都不一定独立去过医院。这些生活经验你不经历就永远不会。经历一次，下次就不慌了。

大人跟你说的那些话，大人自己也做不到

比较单纯善良的孩子容易以为，大人从小教他的那些道理，大人自己想必也是做得到的，至少大人自己是相信的。

其实未必。

说一套做一套，这个事在任何时代任何地方都不稀奇。嘴上说要诚实守信、实话实说，实际上很多人喜欢看到的小朋友是那种非常灵巧、懂得讨人喜欢的。让你拿着花束在路边喊"欢迎欢迎"的，和让你说实话的，有时候是同一批人。

人很容易陷入路径依赖。习惯驱使着很多事按习惯来，未必真学了多少东西。比如到现在了，还有三四十岁的人觉得去实体店买电脑比在电商自营更靠谱——因为能看到一个具体的人站在那里，心里踏实。结果就是很多同学的电脑都是爸妈带着去实体店买的，比电商贵了几百块甚至上千块，配置还奇怪。同款机型电商给的是单条 1T 硬盘，实体店给到的是两枚 512G 拼出来的。

说这些不是为了批评大人。大人也不是像孩子们想的那样全都非常睿智。大多数大人不见得比孩子更有智慧，只是有更多的经验和习惯，对这个社会的运行逻辑比较熟悉，应对起来熟练自然，能够坦然接受。如此而已。当你有十几岁以后，慢慢就会认清这件事。

他们可能未必真喜欢《方舱医院真神奇》，但他们也许很喜欢摆布小朋友们去做那样的表演一样的「情绪保健操」。

大学不是学习的终点，是你自己真正开始的起点

有一句话可能是你这辈子能听到的最大的谎言："到了大学就不用学了，可以各种玩了。"

事实是大学里竞争最激烈，自己可支配的时间也最多——这两件事加在一起，意味着你和别人的差距很可能是在大学里拉开的，不是高中。

课程的内容往往相对旧了一些。不是说课程没用，是说光靠课程不够。要想办法在课程基础上找点竞赛，或者发现一个自己感兴趣的方向，主动去找东西学。不一定得多厉害，但主动和被动的差别非常大。

到了大学你会遇到很多有意思的人，大家能一块做点事当然好。也会遇到你不太喜欢的人，这也不是什么坏事。学会和不喜欢的人和平相处、避免发生矛盾、知道怎么跟各种人打交道，这本身就是大学里要学的东西之一，而且是课程不会教你的。

和人相处应该尽量想办法用非暴力的方式解决问题

我在北方读的高中，冬天教室里有暖气。我在窗户边的座位，靠中间的同学觉得热，想让靠窗的同学把窗户打开透透气。问题是靠窗的同学——也就是我——觉得冷，窗开了更冷。

那会儿的我的做法是肢体说服教育了想要开窗的同学，让他放弃了这个想法。这事儿过去很多年了，我后来想过，其实有更好的办法。

正确的做法应该是：你觉得热，你来窗户边坐一会儿凉快凉快，我去你那儿坐。这样的话两个人都舒服，谁也不用跟谁较劲。但那个岁数的我没有这样的智慧。

说这个是想说，不是让大家在原则问题上退让，而是希望大家在未来的生活里，尽量不以冲撞的方式来解决问题。有很多方式可以达到目的，选一个让大家都容易接受的方向，是一种可以慢慢练习的能力。

坦然面对自己可能很平凡，也不去很掉价地蹭标签

有些地方的规则就是不讲道理的。这种时候不要试图跟它讲道理。在规则框架下能做的范围内，算一下投入产出，不划算就算了。

世界上的机会比你以为的多。我本科是摄影，博士读的是地球科学，后来干过考研辅导，做过艺考培训，现在教基础编程，挺开心的。地球科学应该留给那些真正优秀的人来做，像我这种比较差劲的，就应该明确认清自己的限制，坦然面对自己的平庸，找到一个自己更合适的位置。

这没什么丢人的。有人得奖了，拿荣誉了，钦佩啊祝福或者心理羡慕一下就好。不用去蹭人家的流量，不用去装自己也是那个圈子的人。人家在某个低空学院待得并不开心、转专业之后甚至也很受打击和挫败，就算是不能说受到了很多冷漠的对待也可以说被打击过信心——这是人家的经历。你某某学院的舔着脸跑去四处宣传说"我校友得了奖"，这事儿挺嘚儿的。

我上学那会儿，遇到过一些同学，他们嘴里经常挂着各种非常优秀的人的名字，都很牛、都很厉害。最开始听着觉得真了不起，能和那样优秀的人在一块的，大概自己也是优秀的吧。后来慢慢发现，他们也只是挂在嘴边说说而已，平时自己并不怎么学。说那些也许只是想让自己显得厉害一点，偶尔顺便打击一下别人。至于是不是真的希望别人也跟自己一样消磨时间，不太好说。也许旁人要是真有成就了，就更显出自己的空白了，他们可能自己也未必意识到这一点。

有的地方适合优秀的人，有的地方适合平常的人。优秀的人做优秀的事，平常的人过好平常的生活。平常不代表平庸。平常的生活里也有很多乐趣，你找到那些乐趣，比什么都重要。

开心一点。大学有很多值得期待的东西，但值得期待的不等于幻想。幻想是以为它会自动变好，期待是知道自己要去做些什么让它变好。去掉一些学生气，不是让你变得冷漠，该有的古道热肠还是要有的。只是别太天真，别以为规则一定是公平的，别以为大人一定是对的，别以为听话就一定有回报。善待自己，平和地开启这段时光。

预览时标签不可点

基础知识 · 目录

基础知识

上一篇OpenCode 进阶用法-你提供素材让open code来帮你制作针对不同场景的简历

搜索「」网络结果

调整当前正文文字大小

100%

用 OpenCode 检索文献和验证观点来辅助跨学科领域交流

2026-08-01T18:00:00+08:00

最近和几位朋友聊到一个话题，涉及到生物电、膜电位和发育生物学的内容。这是一个我并不熟悉的领域，但讨论中出现了不少听起来很有道理但仔细一想又觉得不太对劲的说法。

面对这种情况，以往的做法是去 Google Scholar 搜几篇论文，挑着读一读，大概判断一下。但这次涉及的是一个比较活跃的研究方向，论文量很大，而且我不具备足够的领域背景来判断哪些说法靠谱、哪些是过度引申。

于是我试着用 OpenCode 来做这件事——搜论文、下全文、转成可读格式、然后逐篇核对内容。整个过程下来，感觉这个工作流值得记录一下。

起因：一场关于生物电的友好讨论

讨论的起因是 Michael Levin 的工作。这位学者在 Tufts University 研究生物电与形态发生的关系，在发育生物学和再生医学领域相当有影响力。

有一位朋友在讨论中说了这样一段话：

「细胞分化器官的时候，主要是靠生物电网络调节，细胞核遗传物质像是提供原材料的工厂。生物电网络是靠线粒体供能的。母系遗传物质参与了更多的工作。」

这段话听起来挺像那么回事，每个断言似乎都有点生物学常识做支撑。但如果你真的去读 Levin 的论文，会发现他把这些概念之间的关系讲得比这精细得多，而上面这段话里有几处明显的简化乃至错误。

问题在于，要反驳或者修正这种说法，你得拿出论文里的原文来。光凭「我觉得不对」是没用的，你得知道人家到底说了什么。

第一步：搜论文

我给 OpenCode 的第一条指令很简单：

搜索下载 Michael Levin 所有关于生物演化和膜电位的论文，到当前目录，转换成 markdown 文档，并且保存好对应的图片，然后总结整理每一篇文章的实验内容和结论等。

OpenCode 先通过 PubMed 的 API 搜索了 Levin 名下的相关论文。这一步有个小插曲：Levin M 这个名字在 PubMed 里太常见了，搜出来的结果混进了不少其他同名作者的文章——有搞头痛医学的、有搞太阳能的、还有搞蜱虫的。OpenCode 后来加了一层过滤，通过 Tufts 大学附属机构和生物电关键词来筛选，最终锁定了 33 篇近五年（2021–2026）的高相关论文。

这个过滤过程值得大家注意，用 AI 工具做文献检索，你不能完全放手让它自己跑。它会犯一些错误——比如不区分同名作者。但如果你告诉它如何去检查中间过程，及时让它自己进行反馈，它的效率确实比自己人工搜要高得多。

第二步：下载和转换

33 篇论文里，18 篇有开放获取的全文 PDF，另外 15 篇是付费期刊的，只能拿到摘要。

OpenCode 用了几个不同的开放获取源来下载 PDF：Europe PMC 的 ?pdf=render 接口最有效，Unpaywall 作为补充。下载失败的就保存摘要和 PubMed 链接，不硬来。

拿到 PDF 之后，用 PyMuPDF4LLM 转换成 Markdown。这个库对学术论文的转换效果还不错，表格和图注基本能保留，公式有时候会乱但至少能看出结构。同时用 PyMuPDF 提取了所有图片，按论文分目录存好。

18 篇全文总共提取了 293 张图片。有些论文图很多，比如那篇 Technological Approach to Mind Everywhere 有 56 张图，占了 63MB。

整个过程全自动，甚至不需要人工在旁边看输出确认没问题。如果手动做这件事——搜 33 篇论文、下载 18 个 PDF、逐个转换格式、提取图片——恐怕得花一整天。OpenCode 大概用了十几分钟。

第三步：逐篇总结

这一步是最有价值的。OpenCode 用了 6 个并行 agent，每个负责 3 篇全文论文，同时读取 Markdown 全文并生成结构化中文总结。

总结的格式是统一的：

期刊和作者
研究类型（综述/实验研究/计算模型/理论框架）
核心问题（一句话）
主要方法
关键发现和实验内容
主要结论
与膜电位和生物演化的关系

15 篇只有摘要的论文我也让它做了总结，但标注了「基于摘要」和「待获取全文后补充」。

最后还生成了一个总目录文档，包含所有 33 篇论文的目录表格、逐篇总结、以及一个核心主题交叉分析——把所有论文按膜电位编码、生物电与演化、再生、癌症、衰老、认知胶水六个主题做了归纳。

这个交叉分析特别有用。单看一篇论文你可能只看到局部，但把 33 篇放在一起看，你就能发现 Levin 的整个研究体系是怎么拼起来的。

第四步：回到那个讨论

有了 33 篇论文的全文和总结，现在可以回到那位朋友的说法，逐句核对了。下面每一处引用都标注了英文原文和出处，方便感兴趣的朋友去查证。

第一句：「细胞分化器官的时候，主要是靠生物电网络调节」

Levin 确实论证了生物电网络在器官发生中具有指导性角色。比如他在 2026 年的 Mind Everywhere 里明确写道：

"the bioelectric pattern memories are instructive, not epiphenomenal" [1]

2021 年的方法学论文也提到：

"Embryogenesis, as well as regeneration, is increasingly recognized to be orchestrated by an interplay of transcriptional and bioelectric networks." [2]

注意他用的词是 interplay（相互作用），不是「主导」或「主要」。

但问题在于「主要」这个词。Levin 从来没有说生物电是「主要」的调节方式。他反复强调的是协同关系。在 2023 年的 Bioelectric networks: the cognitive glue 一文中，他写道：

"the bioelectrical control system works together with genetic information" [3]

他用的比喻是计算机的硬件和软件：

"While the genome encodes the hardware (the cellular affordances, such as ion channels), the actual outcome is the result of context- and experience-sensitive electrophysiological software that this hardware supports." [3]

两者缺一不可，不存在谁主导谁的问题。

而且 Levin 在 2023 年的 Darwin's agential materials 里说得更清楚：

"It is genetics in the sense that genomes specify the ion channels needed to form the circuit, but it is not genetics in the sense that the actual outcome is controlled by experience (in physiological and behavioral space, respectively)." [4]

这话本身就说明他认为有两个层面在工作，不是一个层面取代另一个。

第二句：「细胞核遗传物质像是提供原材料的工厂」

方向上接近 Levin 的硬件/软件框架，但「原材料工厂」这个比喻矮化了基因组的作用。

Levin 确实把基因组叫「硬件」。但他用的词不是「原材料」，而是 affordances——可供性/能力。上面引用的原文已经说得很明白了：基因组编码的是 "the cellular affordances, such as ion channels" [3]。这不是被动的原料，而是定义了系统能做什么的主动能力。

更关键的是，Levin 在 2023 年提出基因组包含两种信息：

"two kinds of genomic information: that which directly specifies phenotypes (e.g., sequence of protein enzymes, or structural genome) and that which specifies a problem-solving competency (second-order computational capacities)." [4]

如果基因组只是原材料工厂，那它只需要提供蛋白质就行了。但 Levin 认为基因组还编码了「如何使用这些蛋白质」的元信息——这远超原材料的范畴。

Levin 还特别指出，连病毒基因组都会专门腾出宝贵空间来编码离子通道基因：

"It is no surprise that viruses, whose genomes are under significant pressure to remain minimal and concise, devote some of that precious space to ion channel genes." [4]

这说明这些基因不是可有可无的「原材料」，而是被自然选择主动保留的核心组件。

还有一点：生物电网络的全部结构组件——所有离子通道、所有间隙连接蛋白（connexins）、所有 V-ATPase 亚基——都是核基因组编码的。没有核基因组，生物电网络的硬件根本不存在。说它只是「原材料工厂」，就好比说 CPU 的设计图纸只是「硅片的原材料供应商」——技术上沾点边，但严重低估了设计图纸的重要性。

第三句：「生物电网络是靠线粒体供能的」

基础生理学层面没大错。细胞维持膜电位确实需要 ATP，ATP 主要由线粒体产生。Na⁺/K⁺-ATPase、V-ATPase 这些离子泵都是耗能的。2025 年的综述也提到 "Na⁺ out and K⁺ in through Na⁺/K⁺ ATPase to counter the Donnan effect" [5]。

但在 Levin 的框架里，这个说法严重误导了因果关系。

首先，Levin 把线粒体视为生物电层级架构中的一层，不是外部供能者。2025 年的论文提到：

"from the subcellular membrane potentials of organelles such as lysosomes and mitochondria to the spatiotemporal patterns of multicellular potentials characteristic of development and regeneration." [6]

线粒体有自己的膜电位，是生物电系统的一部分，不是站在外面给系统供电的电池。

其次，在 2024 年的会议报告里，Levin 团队提到 Duan 的工作发现线粒体生物电信号与细胞可塑性的耦合关系后，明确说：

"This relation between bioelectricity and mitochondria is a completely unexplored area." [7]

也就是说，Levin 自己都觉得线粒体和生物电网络的关系还没搞清楚，不会下「生物电靠线粒体供能」这样斩钉截铁的结论。

更重要的是，把生物电网络简化为「供能」问题，完全错过了 Levin 的核心论点。Levin 说生物电网络是信息处理系统——他称之为 "the cognitive medium of collective intelligence" [3]。Vmem 模式由离子通道和间隙连接的时空分布决定，不只是由 ATP 供应决定。Levin 自己在 2023 年就指出，用酵母的质子泵替换脊椎动物的 V-ATPase 仍然能工作，因为 "it produces the correct physiological signal" [4]——关键是电信号状态，不是具体的蛋白或能量来源。

这就好比说「大脑靠葡萄糖供能」——对，但这完全没说清大脑在做什么。

第四句：「母系遗传物质参与了更多的工作」

这一句在 Levin 的 33 篇论文里完全没有依据。

我把 33 篇全文都搜了一遍，没有找到任何将「母系遗传物质」与生物电网络调节建立因果关系的论述。"maternal" 这个词在论文里只出现在一个通道病条目和一个关于卵细胞提供环境缓冲的脚注里，都不是这个意思。

这句话的逻辑大概是这样的：线粒体是母系遗传的 → 生物电「靠线粒体供能」 → 所以母系遗传物质参与更多工作。

但即便接受前两步（虽然前面说了第二步就有问题），这个推理也是跳跃的。线粒体 DNA 只编码 13 个蛋白，主要是电子传递链组件。而生物电网络的全部结构组件——离子通道、间隙连接蛋白、离子泵——全部由核基因组编码，不是线粒体基因组。也就是说，生物电网络的硬件来自核基因组，不是母系遗传。

Levin 本人在 2023 年确实提到过 DNA 不是唯一的形态发生信息来源，但他举的例子是细胞骨架的皮质遗传（cortical inheritance），不是线粒体：

"DNA is not the only source of morphogenetic information. Changes made to unicellular form can persist across generations." [4]

而他明确将基因组 DNA 定位为「演化尺度个体的记忆印痕」：

"If we consider genomic DNA to be the engram of the evolutionary-scale individual." [8]

这里说的是核基因组 DNA，不是线粒体 DNA。

线粒体提供 ATP，ATP 是通用能量货币，谁都能用。但 ATP 的生成由线粒体执行，ATP 的使用（驱动离子泵、维持 Vmem）由核基因组编码的蛋白质完成。这就像说「发电厂是市政府建的，所以市政府参与了更多家用电器的工作」——发电厂提供电，但电器的设计、制造、控制全都是另一回事。

一些感受

这个案例或许有一些地方值得说。

首先就是，AI 工具确实能显著降低跨学科讨论的门槛。

以前如果讨论中遇到一个不熟悉的领域，要么得自己花大量时间补课，要么只能凭直觉判断——而直觉在不熟悉的领域里往往不可靠。现在有了 OpenCode 这类工具，你可以在十几分钟内把一个学者几十篇论文搜出来、转成可读格式、做好结构化总结。你不需要成为那个领域的专家，但至少能拿到第一手材料来做判断。

当然前提是你得用它来读原文，而不是让它直接给你一个「答案」。直接问 AI「这个人说得对不对」，它可能会根据训练数据里的信息给你一个笼统的回答，未必准确。但如果让它去读论文原文然后告诉你论文里怎么说的，准确度就高得多——因为这时候它做的是信息提取和整理，不是知识生成。

另外要注意，论文里的精确表述和二手转述之间的差距可以非常大。

Levin 在论文里说的是 "the physiological software of life" [9]、"an epigenetic mechanism that guides morphogenesis" [5]、"pattern memory" [3]、"nongenetic inheritance of a different large-scale anatomy" [1]。这些表述都有一个共同特点：明确区分了生物电和遗传物质，把它们定位为两个不同层面的东西。

但到了二手转述里，这些精细的区分就模糊了。「软件层」变成了「主要调节者」，「非遗传继承」变成了「母系遗传物质参与更多工作」。每一步简化都丢失了一些关键信息，累积下来就变成了一个和原文相去甚远的说法。

在日常讨论中，这自然不是谁故意歪曲的问题。人在转述复杂概念的时候，倾向于用自己能理解的框架去简化它。搞计算机的人容易把一切往「硬件/软件」上靠，搞生物学的人容易往「遗传/能量」上靠。但 Levin 的工作恰恰横跨这两个领域，用任何一个单一框架去简化它都会出问题。

但如果是有别有用心的营销号矩阵之类的，那就难说了。

最重要的是，讨论中拿论文原文来核对，比凭感觉争论有效得多。

如果你只是凭感觉说「你说的不太对」，对方也可以凭感觉说「我觉得就是这样」，讨论就陷入僵局。但如果你能说「Levin 在 2023 年的这篇论文里原文是 "works together with genetic information"，用的是协同而不是主要」，讨论就稍微有了点共同的事实基础，虽然这种只言片语东鳞西爪的内容也不一定就能代表全貌。

当然，这也要求你自己得先去读那些原文，不能只看标题和摘要就下结论。摘要是一篇论文最浓缩的表述，但也是信息损失最大的部分。很多关键的限定词和上下文只在正文里才有。

然后是还是得人能想明白思路，工具再好，判断还是得你自己做。

事情还是得人先想好怎么做，像这个过程中，他的主要观点来源，他之前提到过是那个人，然后我才知道去搜这个人的相关文章，并且设置成最近的5年这样，避免拿一些过于老旧的文章来参与讨论当中。因为有的人可能5年之前的一些作品，他现在的观点和那时候未必一样。

不能说直接跟工具说：「有个人这么说了，你看看他说的对吗？」

这样的话就反而可能会让工具把幻觉掺入到其中，甚至有可能让工具去迎合你给的提示词，而不一定是基于一个现实的知识库进行更公正一些的审视和讨论。

工具提升的是效率，不是可靠性。可靠性还是得靠你自己对结果的审查。

最关键的是把论文内容和那位朋友的说法做对比分析——这步工具只能帮你提供材料，判断还是得你自己来。

工具和文件

用的工具组合是 OpenCode + PyMuPDF4LLM + PubMed/Europe PMC API。OpenCode 负责编排整个流程——搜索、下载、转换、总结——具体的技术操作由它调用各个工具来完成。

如果你也有类似的跨学科讨论需求，想快速了解一个不熟悉领域的研究者的核心观点，这个工作流可以照搬。核心步骤就是：搜论文 → 下全文 → 转格式 → 做总结 → 回到问题逐条核对。每一步都不复杂，但串起来的效率比手动操作高一个数量级。

讨论本身是好事。把观点摆出来，拿证据来核对，有错就改，没错的就坚持。这比闷着头各自相信各自的版本要好得多。只是在这个过程中，得确保你引用的证据确实是你读过的，而不是你觉得大概应该是那样的。

最后一道工序：引文核查

上面的全文写完之后，我又做了一件事：把参考文献列表里每一条引用，拿英文原文作为搜索词，回到转换好的文章全文里逐条搜索，确认这段话确实出现在那篇论文里。

这个过程听起来多余——既然引文是从论文里提取的，还能有错？但实际上，12 条引用查下来，原文全部命中，没有一条是编造的。

用 AI 工具做文献检索和整理，即便大部分操作是基于真实下载的 PDF 和 API 返回的结构化数据，而不是凭空生成，也仍然要警惕幻觉的影响。AI 工具在这个流程里扮演的角色更接近信息搬运工而不是知识生成器——它从论文里提取原文、从 API 获取元数据、从 PDF 转换格式。按理说每一步都有真实的数据来源，不应该出错。但事实是，数据源本身可能返回错误信息，AI 在整合这些信息时可能不加验证地照搬，最终输出里就混入了看起来合理实则错误的内容。

如果不做核查直接发出去，读者点链接会发现跳到了不相关的论文，整篇文章的可信度都会打折扣。更危险的场景是：如果 AI 在提取论文原文时也出现类似的「张冠李戴」——比如把 A 论文的结论安到 B 论文头上——那你基于这些引用做出的论证就全都站不住了。这次原文提取碰巧全部命中，但这个概率不能假设它每次都这么走运。

所以最后这一步引文核查，不是可有可无的仪式，是必须做的收尾工序。

工具提升效率，但工具不保证正确。

效率越高，出错的传播速度也越快——你十分钟生成的内容，如果带着错误发出去，也是十分钟就传播出去了。

在效率和可靠之间，核查这一步是唯一的缓冲。

其实整个这篇文章所说的也正是一个核查的过程，就是把观点和所声称依赖的文献来源进行一下核查。

参考文献

[1] Levin M, Resnik DB. "Mind Everywhere: A Framework for Conceptualizing Goal-Directedness in Biology and Other Domains—Part One." Biological Theory, 2026. PMID: 42183019. DOI: 10.1007/s13752-025-00523-6 https://doi.org/10.1007/s13752-025-00523-6

[2] Nanos V, Levin M. "Rewiring Endogenous Bioelectric Circuits in the Xenopus laevis Embryo Model." Methods in Molecular Biology, 2021. PMID: 33340356. DOI: 10.1007/978-1-0716-1174-6_7 https://doi.org/10.1007/978-1-0716-1174-6_7

[3] Levin M. "Bioelectric networks: the cognitive glue enabling evolutionary scaling from physiology to mind." Animal Cognition, 2023. PMID: 37204591. DOI: 10.1007/s10071-023-01780-3 https://doi.org/10.1007/s10071-023-01780-3

[4] Levin M. "Darwin's agential materials: evolutionary implications of multiscale competency in developmental biology." Cellular and Molecular Life Sciences, 2023. PMID: 37156924. DOI: 10.1007/s00018-023-04790-z https://doi.org/10.1007/s00018-023-04790-z

[5] Zhang G, Levin M. "Bioelectricity is a universal multifaced signaling cue in living organisms." Molecular Biology of the Cell, 2025. PMID: 39873662. DOI: 10.1091/mbc.E23-08-0312 https://doi.org/10.1091/mbc.E23-08-0312

[6] Cervera J, Levin M, Mafe S. "Top-down perspectives on cell membrane potential and protein transcription." Scientific Reports, 2025. PMID: 41372487. DOI: 10.1038/s41598-025-31696-6 https://doi.org/10.1038/s41598-025-31696-6

[7] Pai VP, Zhang G, Levin M. "'Bioelectricity in Development, Regeneration, and Cancers' Cell Bio 2023: A Joint Meeting..." Bioelectricity, 2024. PMID: 38525485. DOI: 10.1089/bioe.2024.0006 https://doi.org/10.1089/bioe.2024.0006

[8] Levin M. "Self-Improvising Memory: A Perspective on Memories as Agential, Dynamically Reinterpreting Cognitive Glue." Entropy, 2024. PMID: 38920491. DOI: 10.3390/e26060481 https://doi.org/10.3390/e26060481

[9] Pio-Lopez L, Levin M. "Aging as a loss of morphostatic information: A developmental bioelectricity perspective." Ageing Research Reviews, 2024. PMID: 38636560. DOI: 10.1016/j.arr.2024.102310 https://doi.org/10.1016/j.arr.2024.102310

[10] Pezzulo G, LaPalme J, Durant F, Levin M. "Bistability of somatic pattern memories: stochastic outcomes in bioelectric circuits underlying regeneration." Philosophical Transactions of the Royal Society B, 2021. PMID: 33550952. DOI: 10.1098/rstb.2019.0765 https://doi.org/10.1098/rstb.2019.0765

[11] Levin M. "Bioelectrical approaches to cancer as a problem of the scaling of the cellular self." Progress in Biophysics and Molecular Biology, 2021. PMID: 33961843. DOI: 10.1016/j.pbiomolbio.2021.04.007 https://doi.org/10.1016/j.pbiomolbio.2021.04.007

[12] Grodstein J, Levin M. "Stability and robustness properties of bioelectric networks: A computational approach." Biophysics Reviews, 2021. PMID: 38505634. DOI: 10.1063/5.0062442 https://doi.org/10.1063/5.0062442

OpenCode 进阶用法-你提供素材让open code来帮你制作针对不同场景的简历

2026-08-01T00:00:00+08:00

之前写过好几篇关于OpenCode的文章了。

opencode 的四种用法与为什么我推荐命令行

不只是写代码：用opencode和免费模型帮你搜教程、下视频

用 opencode 帮学习：上课没听懂的东西，让它帮你查清楚画明白

OpenCode进阶-安装技能再改进：从PDF读取内容来填表和文档

OpenCode 进阶之「技能创作」：拆解描述典型任务后验证实现再做成可复用的「技能」

OpenCode进阶探索-利用模型进行文献情报检索但不要让模型替代人判断

从简单的下载东西，到更复杂一点的OCR 提取图片文字、填表、整理文献，这些技能都有了。

这次说一个更具体的场景：用 OpenCode 来帮忙做简历。

先把素材都扔进一个目录

你在大学这几年攒了不少东西。课程成绩单的 PDF、发表过的软著扫描件、会议文章的录用通知、期刊论文的首页、毕业论文的摘要和目录、摄影作品的精选图片，可能还有一些乱七八糟的证明材料。这些东西平时分散在手机相册、微信文件、电脑桌面各个角落。

第一步很简单：把这些全部拷到一个目录里。别管格式，PDF、图片、Word、txt 都行。以前写的 OCR 技能这时候就派上了——图片里的文字能提取出来，填表技能能把分数表格数字化。你只要把素材放进去，让 OpenCode 先把它们都读一遍，它就有了一手资料。

不同去向的简历，侧重点不一样

找工作的话，不同行业看的是不同的你。投互联网开发的简历要突出编程项目和技术栈，投摄影行业的要突出作品集和器材经验，投教育行业的要把辅导经历和课程设计写清楚。同一个人面对不同方向，简历上重点突出的得不一样。

OpenCode 可以帮的忙是：你先告诉它目标行业和岗位，让它去搜索可靠的招聘网站上同类岗位的职位描述、要求，再让它回来看你的素材里有哪些能对上。对上号的写细致一点，暂时对不上的也别删，也许下一个岗位用得到。

考研考博的话，简历的逻辑和找工作的完全不一样。

导师招人不是要找考试分数最高的。能进复试的分数都不差，差的是有过基础科研训练的人。换句话说，导师想看到的不是"我能考高分"，而是"我来了就能上手帮忙"。如果你本科期间参与过实验室项目，哪怕只是帮师兄师姐跑过数据、做过实验记录、整理过文献，这些东西写到简历上都比高分的含金量高。如果有已经投稿或者发表的文章，更要写清楚——你是第几作者、文章标题是什么、投的什么期刊或者会议、目前什么状态（已发表、录用、在审）。

毕业论文的题目和方向也要写上。这能告诉导师你大概熟悉什么领域，做过什么程度的探索。导师看到之后心里就有谱：这个人来了大概能安排做什么方向的事。

一定要诚实，不能编

这是不能含糊的一点。不管是找工作还是升学，简历上写的每一个东西，面试的时候都可能被问到。你说你参与了某个项目，面试官顺着问两句，你要是真做过就能答上来，要是编的就露馅。

OpenCode 可以帮你把素材整理得更有条理，把你做过的事用更清晰的语言组织出来，但它不能替你编一个你没做过的事。你可以有所保留——有的经历你觉得不够好、不想写上去，这是你的自由。但写上去的东西，每一个都得是真的。真诚坦率，不全写没问题，编造不可以。

具体怎么操作

把你准备好的素材目录路径告诉 OpenCode，然后说清楚你的目标。下面是一个示例：

我准备做一份简历，目标方向是考研，专业是环境科学。我的素材在桌面上的 resume_materials/ 目录里。里面有本科成绩单 PDF、一篇中文核心的录用通知、毕业论文的摘要、两个软著的证书扫描件，还有一些实验记录的照片。

请帮我整理。搜索一下目标院校环境科学方向近几年的研究生招生公告和导师介绍，看看他们倾向招什么样的学生。然后根据我的素材，帮我列一份简历的提纲。列出哪些素材应该突出，哪些可以略写，哪些要补充。

这样就够了。

素材是现成的，方向是明确的，OpenCode 来干的是整理和检索的活儿。最后呈现出来的简历，提纲是它给的，具体你改不改、怎么改，你来决定。工具做梳理，人做判断。这个分工清楚，就不会跑偏。

预览时标签不可点

Name cleared

微信扫一扫赞赏作者

Like the AuthorOther Amount

赞赏后展示我的头像

作品

暂无作品

Like the Author

Other Amount

最低赞赏 ¥0

Back

Other Amount

赞赏金额

最低赞赏 ¥0

基础知识 · 目录

基础知识

上一篇高校教师建议大学新生尽量避免赌气-学会基于判断而不是情绪来做决定

搜索「」网络结果

调整当前正文文字大小

100%

高校教师建议大学生朋友们千万走出「见不得身边人好」的心理陷阱

2026-07-31T12:00:00+08:00

有的同学可能有过这种感觉。刷到一条朋友圈，同学拿了奖。听到一个消息，比你小两届的学弟发了顶刊论文。看到一篇推送，同龄人在某个比赛里得了奖项。

你嘴上说着"挺好的"，心里有一种说不清的不舒服。不是羡慕——羡慕是你也想拥有，是往前的，是积极的。也不是嫉妒——嫉妒是带着点恨的，你也没那么严重。就是一种别扭。好像心里住了一只小怪物，拿根细软的针，在你手指缝里、腋窝底下，不知道什么时候就暗戳戳刺一下。不怎么疼，但总是有点难受。

「为什么不是我呢。」

这句话会在脑子里转一圈。然后你马上会觉得这样想不对，于是把它压下去。但它过一阵又会冒上来。

这件事可能不是你一个人的问题

很多人有这个反应，不是天生的。是练出来的。

从小被拿来跟别人比较的孩子，长大以后很难不把自己跟别人比较。这个模式是家庭里养成的。有些家庭里，大人在外面得给人陪笑、点烟、敬酒、提词，活得很累。回到家以后，这套不舒服的东西没有地方卸掉，就倒给了家人。对孩子尤其方便——孩子不会反抗，成本最低，风险最小。

水凉了不行，热了也不行。饭菜咸了淡了都是毛病。成绩好了说你骄傲，成绩差了说你没出息。考了第二问你为什么不是第一，考了第一问你这次是不是题目太简单。

小孩子在这种环境里长大，很容易学会一件事：我的价值不是由我自己来决定的，而是由我比别人强多少来决定的。别人比我强，就等于我输了。我输了，就等于我没有价值。

中老登们的斗鸡游戏

这些东西上一代玩得很熟。他们那个圈子，乐趣本来就不多。烟酒要花钱，赌博有风险，其他的消遣要么见不得光要么毁身体。比孩子是成本最低的娱乐方式——孩子成绩好，出去吹牛就有素材；孩子讨老师喜欢，等于自己在领导面前有面子。孩子在他们眼里不是一个人，是一个可以向其他中老登展示的成绩单。

子夏之徒说得对——「狗豨犹有斗，恶有士而无斗矣」，阿猫阿狗都免不了要斗一斗，何况庸碌之人呢。中老登们自然也这样。比谁家孩子出生时胖，比谁家孩子半夜不哭闹，比谁说话早、谁会学大人说那些市侩话。上学了比成绩、比课外班、比谁更讨老师欢心。自己辈子过得没什么拿得出手的东西了，就指望孩子替自己去比，替自己去赢。

其实他们只希望赢，至于事情本身，其实未必真那么重视，甚至他们可能都懒得掩饰地流露出来「事情本身不重要」。

放羊为了成家，成家为了生子，生子让去放羊。这个循环换个皮：学习为了应试，应试为了比别人强，比别人强为了能让父母出去吹牛，吹完牛回家继续要求你比别人更强。鱼头要永远朝向对的人，你也要随时能站起来提一杯。

也许有一种可能，就是：他们是故意这样设计的，就是希望大家陷入到这样的徒劳和循环。

你不需要接这个棒

如果你从小到大一直活在这种比较里，到了大学以后，你可能会发现自己有两个本能：第一个是看到别人有成就就难受，第二个是想让别人知道自己认识谁谁谁谁。两个都是这个模式的后遗症。前者让你不开心，后者让你显得浅薄。

如果你没有经历过这些，也希望能理解——你身边那些看到别人成功就浑身不自在的同学，可能不是人品差，是从小被这么练出来的。而且他们自己可能并没有意识到，只觉得自己是"压力大"或者"要强"。

同学成绩比你好，同学比赛拿了奖，同学发了论文，同学谈了对象，同学考研上岸了，同学留在高校当了老师，同学拿了个国际大奖——这些都是他们的剧情。你的剧情是你的，不需要和他们比进度条。你不需要羡慕嫉妒恨，那对你没有任何帮助。你也不需要四处跟人说"我认识的那个谁谁多厉害"，因为厉害的人是他，不是你认识的你就跟着厉害了，这两个东西一点关系都没有。

好好走自己的路。承认别人优秀没那么难。

多关注一下自我的建设，让自己成为更好的版本。

选了什么样的生活方式就乐在其中，这比什么都要好。

注：文中提到的「阿猫阿狗」化用了《墨子·耕柱》中一段。原文：子夏之徒问于墨子：「君子有斗乎？」墨子曰：「君子无斗。」子夏之徒曰：「狗豨犹有斗，恶有士而无斗矣？」

高校教师建议大学新生尽量避免赌气-学会基于判断而不是情绪来做决定

2026-07-31T00:00:00+08:00

前几天我儿子闹了个别扭。我买了果汁回来，他本来挺高兴要喝的，他妈妈跟他说先把作业做完再喝吧，果汁正好凉，放一会儿温一温。他就来了一句：那我不喝了。

这就是赌气。不是不想喝，是因为被提了个条件，心里不舒服，就用"不喝了"来回应。好像拒绝了对方的要求，自己就赢了似的。

我把他叫到另一个屋子，跟他说，你想喝这个东西对吧。他说对。那作业是不是反正也要做。他说是。那先做作业再喝果汁，这个顺序本身有什么问题吗？他想了一下，好像也没什么问题。那如果现在你说不喝了，等会儿做完了作业想喝的时候怎么办？你已经说了不喝了，再拿起来是不是有点别扭。

最后他自己也觉得，还是先做作业，做完喝果汁。这事儿就算过去了。

但如果他当时赌气到底呢？作业照样得做，果汁照样想喝，但话已经放出去了，自己把自己架在那儿了。你说这划不划算。

赌气这件事，从小学到大学都在发生

有的同学一门科目没考好，就索性不学了。心里想的是，反正我也学不好，那我干脆不学，这样就不是"我努力了还不行"，而是"我没努力所以不行"。这两句话听起来差不多，但对自己的伤害完全不一样。前一个是能力问题，后一个是态度问题，大部分人选了后者，因为后者好接受一点。

然后如果有其他科目也受了挫，同样的操作再来一次。最后变成了"我都这样了还学什么学"，觉得挺酷。谁劝都没用，劝了反而更来劲——你越劝说明你越在意，我就越要证明我不在意。其实到底在不在意，自己心里清楚。

还有更隐蔽的一种。身边有人开始吸烟喝酒，好像这样就成年了、就独立了。家里大人劝阻，反而激发了逆反——你说不好，那我偏要试试。甚至自己心里也知道这不一定对，但怕被同样这么做的同学排斥，怕显得自己不合群，就违心地跟着一块混。这不是酷。你只是在用别人的标准衡量自己，而且那个标准本身就不太对。

大人也赌气，而且比小孩更会找理由

路上开车，人家别了你一下插了队。你赌气，非要别回去，再急刹车拦他一下。这一来二去，轻则剐蹭，重则事故。你本来只是被别了一下，耽误了几秒钟。赌气之后，可能耽误几个小时甚至更久，还得赔钱。投入产出完全不对等，但赌气上头的时候没人算这个。

排队的时候有人插进来了，你指出来，他不认。他说他是平移过来的，不是在插队。平移这个词用得挺妙——只要找到一个能挽尊的说法，就好像自己不是在插队了，就可以理直气壮地跟人耍横。

还有更离谱的——占了人家固定车位，人家好好联系了，不理不睬。还撒谎说自己出差了回不来。人家被惹怒了，他又找自己伴侣过来拦着人家。每一步都在让事情升级，每一步都有机会停下来，但一个都没抓住。这就不是一时的赌气了，这是用赌气的方式在处理所有遇到的问题。

赌气成为习惯，就是人格的一部分了

赌气本身不可怕，谁都有情绪上头的时候。可怕的是赌气成了习惯，成了处理问题的默认路径。更可怕的是自己都不觉得自己在赌气，觉得这就是自己"直率""有骨气"的表现。

别人给你提个建议，你第一反应不是想这建议有没有道理，而是想这人是不是在管你。别人做了一件你不太喜欢的事，你第一反应是怎么回敬一下让他知道你不高兴，而不是想这件事到底值不值得不高兴。

久而久之，你遇到所有让自己不舒服的情况都只会用这一种方式应对——对抗、拒绝、把自己架起来。不仅自己不开心，也让身边的人觉得不好相处。大家不是怕你，是懒得跟你打交道了。

做决定之前问自己一句：我到底是真的想这么选，还是只是在赌气。这句话说起来简单，但每一次能拦住自己把情绪当成决定，都是一次对自己负责。

对小朋友是这样，对大学新生，对自己，都是这样。

预览时标签不可点

基础知识 · 目录

基础知识

上一篇用OpenCode帮忙搜索整理动漫人物关系和时间线以及当年没弄明白的剧情

搜索「」网络结果

调整当前正文文字大小

100%

这个世界的维度不一定是整数——谈谈分数维是怎么回事

2026-07-30T14:00:00+08:00

我们日常接触的维度都是整数：线段是 1 维的，正方形是 2 维的，立方体是 3 维的。这个东西很直观——你从小到大在黑板上画的坐标系，横轴是一条线，横轴加纵轴是一个面，再加一根竖轴就是空间。

但这个世界有些东西，它的维度不是整数。

英国的海岸线有多长？你拿一把很长的尺子去量，得到一个数字。换一把更短的尺子，能量到更多弯弯绕绕，量出来的长度变长了。再换更短的尺子，它变得更长。如果尺子无限短，海岸线的长度似乎会变成无限大——但它又不是 2 维的面，它是一根线，只不过缠绕得过于厉害。

Mandlebrot 在 1967 年那篇著名的 Science 论文里问了这个问题。他的答案是：海岸线的维度在 1 和 2 之间，大概 1.2 到 1.3 左右。这不是一个整数。

维度到底怎么算

先回想一下整数维度是怎么来的。拿一条线段，把它均分成 2 段——你得到的是 2 段，每段长度是原来的 1/2。如果你把它均分成 3 段，你得到 3 段，每段长度 1/3。

关键在哪呢？放大的倍数和段数的关系：

线段：放大 2 倍 → 长度变成 2 倍。2 = 2¹。维度是 1。
正方形：放大 2 倍 → 面积变成 4 倍。4 = 2²。维度是 2。
立方体：放大 2 倍 → 体积变成 8 倍。8 = 2³。维度是 3。

设放大倍数为 r 的倒数（就是缩小的比例），设 N 为缩小后小图形的个数，则维度 D 满足：

\[ N = \left(\frac{1}{r}\right)^D \]

两边取对数：

\[ D = \frac{\log N}{\log (1/r)} \]

这个公式妙在什么地方呢？它不要求 N 是整数。只要你能数清楚"一个图形缩小到原来的几分之一后，包含了几个和自己相似的更小图形"，你就能算出它的维度——哪怕算出来的不是整数。

科赫雪花：周长无限但面积有限

科赫雪花（Koch Snowflake）可能是最著名的分形了。构造方法非常简单：

从一个等边三角形开始
每条边三等分，把中间那段换成一个小的等边三角形的两条边
重复

用 Python 写出来就是：

import numpy as np
import matplotlib.pyplot as plt

def koch_snowflake(depth=4):
    """生成科赫雪花的顶点坐标"""
    # 初始等边三角形
    pts = np.array([[0, 0], [1, 0],
                    [0.5, np.sin(np.pi/3)], [0, 0]])

    for _ in range(depth):
        new_pts = []
        for i in range(len(pts) - 1):
            x1, y1 = pts[i]
            x2, y2 = pts[i+1]
            dx, dy = (x2 - x1) / 3, (y2 - y1) / 3

            # 第一段起点
            new_pts.append((x1, y1))
            # 第二段起点 (三等分点)
            new_pts.append((x1 + dx, y1 + dy))
            # 中间凸起的顶点 (旋转60度)
            angle = np.pi / 3
            mx, my = x1 + 1.5*dx, y1 + 1.5*dy
            new_pts.append((mx - dx*np.cos(angle) + dy*np.sin(angle),
                            my - dx*np.sin(angle) - dy*np.cos(angle)))
            # 第三段起点 (二等分点)
            new_pts.append((x1 + 2*dx, y1 + 2*dy))
        new_pts.append(pts[-1])
        pts = np.array(new_pts)

    return pts

pts = koch_snowflake(4)
plt.figure(figsize=(8, 8))
plt.fill(pts[:, 0], pts[:, 1], facecolor='#f39c12',
         alpha=0.4, edgecolor='#f39c12', linewidth=0.5)
plt.axis('equal'); plt.axis('off')
plt.show()

每一次迭代都发生了什么？一条线段被替换成了 4 条更短的线段，每条的长度是原来的 1/3。

所以 N = 4，r = 1/3（或者说，放大倍数是 3）。

\[ D = \frac{\log 4}{\log 3} \approx \frac{0.602}{0.477} \approx 1.26 \]

科赫雪花的维度大约是 1.26。它是一个在 1 和 2 之间的几何对象——比一条线更"拥挤"，但还远不到一个面。它的一个非常反直觉的性质是：面积是有限的，但周长是无限的。每一次迭代，周长都变成原来的 4/3，无限迭代下去周长就趋于无穷。

谢尔宾斯基三角形：像是被虫蛀过的三角形

另一个经典分形是谢尔宾斯基三角形（Sierpinski Triangle）。构造方法也很简单：

一个黑色实心三角形
挖掉中间那个倒着的、边长是原来一半的小三角形
对剩下的三个小三角形重复同样的操作

def sierpinski(depth=4):
    """生成谢尔宾斯基三角形"""
    pts = np.array([[0., 0.], [1., 0.],
                    [0.5, np.sin(np.pi/3)]])
    triangles = [pts]

    for _ in range(depth):
        new_tris = []
        for t in triangles:
            a, b, c = t[0], t[1], t[2]
            # 三条边的中点
            mab = (a + b) / 2
            mbc = (b + c) / 2
            mca = (c + a) / 2
            # 三个小三角形（中间那个被挖掉了）
            new_tris.append(np.array([a, mab, mca]))
            new_tris.append(np.array([mab, b, mbc]))
            new_tris.append(np.array([mca, mbc, c]))
        triangles = new_tris
    return triangles

每次迭代，三角形被分成 4 个等大的小三角形（中间那个被挖掉所以只剩下 3 个）。每个小三角形的边长是原来的一半。所以 N = 3，r = 1/2。

\[ D = \frac{\log 3}{\log 2} \approx \frac{0.477}{0.301} \approx 1.58 \]

谢尔宾斯基三角形的维度大概是 1.58。比科赫曲线更接近 2，但仍然不是一个完整的平面——因为它被无限多个窟窿蛀空了，总面积趋近于 0。

计算任何自相似分形的维度的通用函数：

import math

def fractal_dimension(N, r):
    """
    计算自相似分形的维度
    N: 缩小后的小图形个数
    r: 缩小的比例 (新边长 / 原边长)
    """
    return math.log(N) / math.log(1/r)

print(f"科赫雪花: {fractal_dimension(4, 1/3):.2f}")
print(f"谢尔宾斯基三角形: {fractal_dimension(3, 1/2):.2f}")
print(f"门格海绵: {fractal_dimension(20, 1/3):.2f}")
print(f"线段: {fractal_dimension(2, 1/2):.2f}")
print(f"正方形: {fractal_dimension(4, 1/2):.2f}")

输出：

科赫雪花: 1.26
谢尔宾斯基三角形: 1.58
门格海绵: 2.73
线段: 1.00
正方形: 2.00

注意最后一行的线段和正方形——N 和 r 取适当的值，公式算出整数维度。这个公式是兼容的，整数维度只是它的特例。

Mandelbrot 集：无穷的精致

如果说科赫雪花和谢尔宾斯基三角形是数学家人工构造的，那 Mandelbrot 集就是大自然塞到数学里的。它的定义简单到只有一行：

\[ z_{n+1} = z_n^2 + c \]

取一个复数 c，从 z₀ = 0 开始不断迭代这个公式。如果 z 最终发散到无穷大，c 就不属于 Mandelbrot 集；如果永远局限在有限范围内，c 就属于它。你只是把每一个 c 在复平面上对应的点按照迭代发散的快慢染上不同的颜色，就得到了下面这个东西。

用 Python 画出来：

import numpy as np
import matplotlib.pyplot as plt

def mandelbrot(width, height, max_iter, xmin, xmax, ymin, ymax):
    x = np.linspace(xmin, xmax, width)
    y = np.linspace(ymin, ymax, height)
    C = x[:, None] + 1j * y[None, :]
    Z = np.zeros_like(C)
    img = np.zeros((height, width))

    for i in range(max_iter):
        mask = np.abs(Z) < 4
        Z[mask] = Z[mask]**2 + C[mask]
        img[~mask] = i
        img[mask] = i

    return img.T

img = mandelbrot(800, 600, 200, -2.5, 1.0, -1.3, 1.3)
plt.figure(figsize=(10,7),facecolor='#0f1720')
plt.imshow(img, cmap='hot', extent=[-2.5,1.0,-1.3,1.3])
plt.xticks([]); plt.yticks([])
plt.show()

这个集合有一个极为特殊的性质：它的边界是处处粗糙的。不管你把放大倍数调到多大，边界上总有新的结构冒出来。你放大到原子尺度，它依然有凸起、凹陷、螺旋——永远看不完。正是因为这个边界复杂到了极致，它的 Hausdorff 维数被证明等于 2。也就是说，一条"线"——如果它可以被叫做线的话——复杂到了填满一个平面的程度。

分数维的存在告诉我们什么

维度不是一个必须整数的东西——它更像是在描述"这个形状在一个空间里填充了多少"。科赫雪花比线更挤所以维度比 1 大，但不如面那么密集所以维度比 2 小。谢尔宾斯基三角形比科赫雪花更靠近 2，因为它覆盖的面积比例更大。

现实中很多东西的维度可能不是整数。海岸线、血管网络、肺的支气管树、河网水系——这些自然形状都或多或少有自相似性，它们的有效维度是一个比整数更有信息量的描述方式。

这也许也可以当作一种思维方式来琢磨。日常做判断的时候，很多事并不是非黑即白、非零即一的简单二分。在 1 和 0 之间、在 1 和 2 之间，可能存在着连续的、丰富的光谱式的过渡。不是维度可以随便定义，而是很多看起来理所当然的"整数"划分，换个角度去看就有更多东西在中间。

计算机是怎么用二进制做加减乘除的——从原码反码补码讲起

2026-07-30T10:00:00+08:00

大家基本都知道二进制是怎么回事了——0 和 1，每一位代表 2 的几次方。但光知道二进制表示数字还不够，还得知道计算机怎么用它来算加减乘除。

这事的关键在于三个东西：原码、反码、补码。把这三个弄明白，计算机的运算就没什么神秘的了。

原码：最朴素的二进制表示

原码就是最直接的写法。最高位（最左边的那位）是符号位——0 表示正数，1 表示负数。剩下的位表示数值的大小。

比如用 8 位二进制（一个字节）来存。先约定一个基础规则：8 位二进制，每一位从右到左有一个编号。最右边的那位叫作 bit 0，往左依次是 bit 1、bit 2……一直到最左边的 bit 7。bit 0 代表 2⁰ = 1，bit 1 代表 2¹ = 2，bit 7 代表 2⁷ = 128。这个编号方式后面会反复用到。

bit7  bit6  bit5  bit4  bit3  bit2  bit1  bit0
 0     0     0     0     0     1     0     1   = +5

+5 怎么表示？符号位是 0，剩下 7 位是 0000101（二进制 101）。组合起来：0000 0101。
-5 怎么表示？符号位是 1，剩下 7 位同样是 0000101。组合起来：1000 0101。

简单吧。但原码有一个很要命的问题：如果用原码直接算加法，遇到正负数混合的时候，结果是不对的。

比如 5 + (-3)，按原码来：0000 0101 + 1000 0011 = 1000 1000。最高位是 1，看起来结果应该是 -8。但 5 + (-3) 应该是 2。

问题出在符号位也参与了运算。我们需要一种表示法，让符号位和数值位可以统一处理、加法器和减法器能合成同一个电路。这就是补码的由来。但在讲补码之前，先看它的过渡形态：反码。

反码：把负数翻转一下

反码的规则很简单：

正数的反码就是它自己（和原码一样）。
负数的反码：符号位保持 1，其余每一位取反——0 变成 1，1 变成 0。

还是用 8 位来看：

+5 的反码：0000 0101（和原码一样）。
-5 的反码：先写出 +5 的原码 0000 0101，然后符号位保持，其余全部取反。

text 原码: 0 0 0 0 0 1 0 1 (正数的原码) |←——数值——→| 反码: 1 1 1 1 1 0 1 0 (符号位变1，其余取反)

所以 -5 的反码是 1111 1010。

来验证一下：反码的 +5(00000101) 加上 -5(11111010) 等于多少？

  0000 0101  (+5 的反码)
+ 1111 1010  (-5 的反码)
-----------
  1111 1111  (全是1)

11111111 按反码还原回去，就是 -0。反码算出来的 5 + (-5) = -0。方向是对了，但有两个零（00000000 是 +0，11111111 是 -0），这就很不方便。你一个系统里有两个零，比大小又麻烦了。所以还要进一步优化：补码。

补码：负数 = 反码 + 1

补码是现在计算机里真正用的表示方法。规则也很简单：

正数的补码 = 它自己（和原码、反码一样）。
负数的补码 = 它的反码 + 1。

按这个规则重算 -5 的补码：

+5 的原码：0000 0101
取反得反码：1111 1010
加 1：1111 1010 + 1 = 1111 1011

所以 -5 的补码是 1111 1011。

现在用补码算 5 + (-5)：

  0000 0101  (+5 的补码)
+ 1111 1011  (-5 的补码)
-----------
 10000 0000  (最高位的进位溢出了，8位以内就是 0000 0000)

结果正好是 0——完美的，两个零的问题解决了。而且补码表示的范围比原码多一个数：8 位补码可以表示 -128 到 +127，而原码只能表示 -127 到 +127。

补码让你能用同一个加法器算所有的加减法，不需要单独的减法电路。这就是为什么计算机都用补码。

用补码做减法

有了补码之后，减法就变成了加法：A - B = A + (-B 的补码)。

计算机里没有减法器，只有一个加法器。算减法的时候，先把减数转成补码，然后直接当加法算。

看几个例子。比如：7 - 3 = ?

7 的 8 位补码：0000 0111
3 的 8 位补码：0000 0011
-3 的补码：把 3 取反加 1 → 1111 1101
加法：0000 0111 + 1111 1101 = 1 0000 0100（溢出位丢掉，所以是 0000 0100 = 4）✓

再看一个：3 - 7 = ?

3 的补码：0000 0011
-7 的补码：把 7(0000 0111) 取反加 1 → 1111 1001
加法：0000 0011 + 1111 1001 = 1111 1100
结果最高位是 1，说明是负数。把这个负数的补码还原成原码：减 1 再取反。1111 1100 - 1 = 1111 1011，取反 = 0000 0100 = 4，所以结果是 -4。✓

就这样，不管你是正数加正数、正数加负数、两个负数相加，用补码都能直接用同一个加法器算对。这是补码最美的地方。

乘法：就是重复加，但加了点技巧

乘法原理上就是连加。3 × 5 就是把 5 加三次：5 + 5 + 5 = 15。但计算机不会傻到真的加几十上百次——它用手算竖式乘法的思路。

二进制乘法比十进制更简单，因为每一位只能是 0 或 1：

如果乘数当前位是 1 → 加上被乘数。
如果乘数当前位是 0 → 不加，直接跳过。

手算一下 13 × 6（都用 8 位无符号二进制）：13 = 0000 1101，6 = 0000 0110。

          0000 1101  (被乘数 = 13)
      ×   0000 0110  (乘数 = 6)
-------------------
          0000 0000  (乘数第0位=0，不加)
         0000 1101   (乘数第1位=1，加上 13，左移1位)
        0000 1101    (乘数第2位=1，加上 13，左移2位)
      + 0000 0000    (乘数第3位及以后=0，不加)

      = 0100 1110  (64+8+4+2=78)

对应十进制公式也是对的：

\[ 13 \times 6 = 13 \times (2^1 + 2^2) = 13 \times 2 + 13 \times 4 = 26 + 52 = 78 \]

所以你看到没有，乘法在计算机里其实是一系列"判断某一位是否为 1，如果是就加被乘数的移位"的操作。需要加多少次？取决于乘数有多少个 1。乘数里 1 越少，乘法越快。

除法：从长除法到计算机的做法

除法是乘法的逆运算。你还记得小时候列竖式做除法吗？比如 78 ÷ 6，你会在纸上写：

6 能乘以多少能刚好不超过 78？6×10=60，6×13=78——刚好。所以你得到商 13，余数 0。

计算机也是这个思路，只不过它用的是二进制。而且二进制除法比十进制简单很多——因为每一位商只能是 0 或 1。你不需要像十进制那样去试"6 能乘以多少不超过 78"——你只需要试"除数的这个倍数能减吗"，能减商就是 1，不能减商就是 0。

下面用 78 ÷ 6 来一步步走一遍。先统一用 8 位二进制：78 = 0100 1110，6 = 0000 0110。

第一步：把除数对齐到被除数

先找一个"合适的"位置把除数放上去——把除数左移，让它尽可能靠近被除数但不超过它。这和十进制竖式里把除数写到被除数的左边几位对齐是一个道理。

6 = 0000 0110。左移 1 位（×2）就是 0000 1100 = 12，左移 2 位（×4）= 0001 1000 = 24，左移 3 位（×8）= 0011 0000 = 48，左移 4 位（×16）= 0110 0000 = 96。

96 > 78，超出了，不行。退回到左移 3 位：48。48 < 78，可以。这相当于 6 × 8 = 48。

好，商从最高位（bit 3 的位置）开始定。

除数左移到 0011 0000 (6 × 8 = 48)，刚好不超过 78。

第二步：逐位确定商

现在把除数的这个移位版本（0011 0000 = 48）和被除数（0100 1110 = 78）放在一起，从左到右逐位定商。

第一位（bit 3）：48 能减吗？ 78 - 48 = 30 ≥ 0，可以。商 bit3 = 1，新的余数变成 30。

第二位（bit 2）：除数再右移一位，48 → 24（0011 0000 右移一位 = 0001 1000 = 24）。30 - 24 = 6 ≥ 0，可以减。商 bit2 = 1，余数变成 6。

第三位（bit 1）：除数再右移一位，24 → 12（0000 1100）。6 - 12 = -6 < 0，不能减。商 bit1 = 0，余数保持 6。（能减就置 1 然后减，不能就跳过，和除法恢复算法对上了。）

第四位（bit 0）：除数再右移一位，12 → 6（0000 0110）。6 - 6 = 0 ≥ 0，可以减。商 bit0 = 1，余数变成 0。

整个过程用一张表格看得更清楚：

被除数: 0100 1110 = 78
除数:   0000 0110 = 6

对齐:   0011 0000 = 6 × 8 = 48  (左移3位, 刚好不超过78)

bit3:  0100 1110 - 0011 0000 = 0001 1110 = 30 ≥ 0  → 商 bit3 = 1
        余数 = 30
        ↓ 除数右移1位

bit2:  0001 1110 - 0001 1000 = 0000 0110 = 6  ≥ 0  → 商 bit2 = 1
        余数 = 6
        ↓ 除数右移1位

bit1:  0000 0110 - 0000 1100 = 负数  < 0             → 商 bit1 = 0
        余数保持 6
        ↓ 除数右移1位

bit0:  0000 0110 - 0000 0110 = 0000 0000 = 0  ≥ 0  → 商 bit0 = 1
        余数 = 0

商 = 1101 (从高到低读出) = 8 + 4 + 0 + 1 = 13  ✓
余数 = 0  ✓

你看，和十进制做长除法的过程是一模一样的，只是每一步的判断——能减吗——变得特别简单，因为减得动的结果非负、减不动的结果是负，直接把符号位拿出来就定了商 bit 是 1 还是 0。不需要去猜测商应该取几，也不用乘法试商，这是二进制除法和十进制除法相比最舒服的一个地方。

最后总结

这些东西一长串地看下来，其实逻辑很简单。计算机是从三种表示数字的方式——原码、反码、补码——一步步推导下来的：

原码：最直接，但正负混合加算出错。
反码：通过取反解决了符号带来的部分问题，但仍然有两个 0。
补码：反码加 1，把"两个 0"的问题也解决，让同一个加法器能做所有的加减运算。

有了补码，减法通过加上一个补码形式的减数变成了不需要区分的统一的加法。乘法在底层被拆解成"加数和移位"——乘数的每一位是不是 1 决定要不要加，这其实是小学竖式乘法的二进制版本。除法则是先从小到大去比较乘了一个倍数的除数和被除数的大小，把商的每一位定好，也就是长除法在计算机里的样子。

回过头来看，计算机的加减乘除，全都建立在二进制的 0 和 1 上——和你列竖式的思路没什么不同，只是它只用到了 0 和 1 两种数字，比十进制的心算口诀简单得多，反而更规整。

用Open Code帮我搜索整理人物关系和时间线以及当年没弄明白的剧情

2026-07-30T00:00:00+08:00

原创

无论是大学生还是其他的朋友，生活不能只学习和工作，也该有些娱乐。

之前关于Open Code的文章都是要么是编程写代码要么是上课学习记笔记要么是写简历找工作或者读研面试，都太严肃了。

今天乐呵乐呵，这回就用Open Code完成一些剧情搜索和时间线整理的工作，来提供一点乐趣。

事情的起因

今天跟一些90后00后聊小时候看的动画片，发现他们那时候看的很多还是国外的，尤其是日本动画片。火影、海贼、鬼灭之刃，这几部都有一个共同特点：特别强调血统。谁是谁的孩子，继承了什么东西，家族的羁绊——这些东西贯穿始终。

当年火影刚出来的时候就觉得这味儿很重，各种家族、各种眼、各种血脉。龙珠后来也是这样。海贼刚开始看的时候觉得还行，路飞挺底层的挺热血的。后来发现他也有很厉害的亲人，血脉里的东西慢慢都浮上来了。感觉就在跟小朋友们说一个道理：你看，厉害的人还是得有个厉害的出身。

我不知道这是不是整个东亚地区儒家文化圈的影响。日韩到现在也都有非常明确的年资等级之类的东西，好像有这种说法。血统论在动画片里绕来绕去，总让人觉得是在说天龙人的故事。

什么样的人物塑造让我觉得还行

想了半天，什么样的动画让我觉得能接受。如果只说日本动画的话，一个是逮捕令。那里边对不同的人有很好的呈现——老夫少妻的家庭关系、特殊的着装和性别认同、对工作有特殊认知的人等等。人物形象挺丰富的，很多都不是当时甚至现在特别普遍的角色塑造，但它给了这些不同的角色一样的尊重。甚至里边的反派也不是脸谱化的，不是蠢的，是挺正常地呈现出来的。这种细节在当时的动画片里挺少见。

另一个是高达00。那里边的主角们不是天生就高贵、血脉怎么怎么样的，更多的是来源复杂，因为认同某一个理念，聚集到了一起，用一些行为去影响世界格局，推动世界改变。最终剧场版里讲的，是经过一番牺牲和苦战之后发现，如果能够互相理解，就能减少很多痛苦。关于理解能减少冲突这件事，我觉得挺有意思，值得参考一下。

靠武力解决一切，是不是太简单了

再想到一些美国动画片。各种超级英雄系列——正义联盟、复仇者联盟，从上世纪末到本世纪初就开始的这些。模式都差不多：出现了一个很大的危机，主角团用尽智慧和武力镇压了坏人，或者是有一个或者几个英雄角色扮演拯救世界的救世主。但世界应该不只是打一架就解决所有问题那么简单吧，我觉得这个不太靠谱。

有一个例外是少年正义联盟。这剧前几季的人物塑造非常复杂，没有后来那种为暗黑而暗黑的意思。它呈现了一些很具体的问题：如果一个人发现自己是个克隆体，甚至在不自知的情况下当了卧底，他要怎么面对自己；反派和正派阵营不同，但如果中间产生了感情、有了家庭，这事该怎么处理。

这些让人能接触到关于生活的现实问题，而不只是超能力拯救全世界那么简单。

正义联盟有一集里，Lex Luthor为了拯救地球把自己牺牲掉了。还有一集说在另一个平行宇宙里，正义联盟的人是反派，而某个原本被看作混乱角色的Joker是个非常阳光、总是开朗地解决各种问题的人，最终为了拯救大家牺牲了自己。

这种牺牲的戏码那会儿总容易把我打动。但现在想想，就觉得不应该这样。我现在能意识到自己就是个普通的中老登，不应该去要求英雄们牺牲自己。如果英雄们也能跟大家一样快快乐乐的，那才是更好的。

就又回到了高达00里那个想法：大家如果都能够尽量是 happy ending，这才好。互相理解，避免很多不必要的冲突，比牺牲谁要好。

现在看动画片少了，但有时候想知道当年看的那些结局是什么，就会回头搜一搜。聊起这个，就随便写了这些。

让 OpenCode 帮你整理这些

上面的这些动画片——火影、海贼、鬼灭、龙珠、逮捕令、高达00、少年正义联盟、正义联盟——如果你也想理一理这些故事里的人物关系和时间线，可以把下面这段话直接发给 OpenCode：

帮我整理下面这些动画片的人物关系、时间线和剧情脉络。每一部单独列一个文档。

火影忍者：整理主要角色的家族血统关系（宇智波、千手、日向等），主线剧情的时间线（从鸣人小时候到疾风传再到博人传），各次忍界大战的起因和结果。

海贼王：整理路飞的家族关系（父亲龙、爷爷卡普、哥哥艾斯和萨博），草帽海贼团各成员加入顺序和背景故事，世界政府的组织架构（五老星、天龙人、海军）。

鬼灭之刃：整理鬼杀队九柱的名称和呼吸法，灶门炭治郎家族与日之呼吸的渊源，无惨与鬼的体系。

龙珠：整理赛亚人的血统等级和变身形态（从普通到超蓝到自在极意），主角团从地球到宇宙的战斗力提升时间线。

逮捕令：整理主要角色的身份和性格特点，署长和其他配角的关系。

机动战士高达00：整理天人组织的成员和理念，三大阵营的背景，剧场版中ELS生命体的设定和结局。

少年正义联盟：整理团队成员构成（各季节有所变动），克隆体和卧底的相关角色，反派阵营和跨阵营的家庭关系。

正义联盟动画：整理正义联盟成员的能力和背景，平行宇宙的设定，Lex Luthor在动画中的角色弧线。

输出格式：每部动画片一个独立的 markdown 文档，包含人物关系图（用文字描述）、时间线（按时间排序）、主要剧情线索。如果有复杂的家族或阵营关系，用缩进列表来表示层级。

把这段话发过去，OpenCode 会帮你按部就班地把每一部作品的信息搜出来、理清楚。这些故事跨度长、人物多，自己翻来翻去挺费时间的，让它干这些梳理的活正好合适。

给出要求

给出反馈

进一步的进度

预览时标签不可点

关闭

名称已清空

微信扫一扫赞赏作者

喜欢作者其它金额

赞赏后展示我的头像

作品

暂无作品

喜欢作者

其它金额

最低赞赏 ¥0

确定

其它金额

赞赏金额

最低赞赏 ¥0

基础知识 · 目录

基础知识

上一篇教材上的标准答案不一定是真答案——从机翼升力的错误解释说起下一篇高校教师建议大学新生尽量避免赌气-学会基于判断而不是情绪来做决定

关闭

搜索「」网络结果

关闭

调整当前正文文字大小

100%

刚弄明白了二进制和内存硬盘，接下来聊聊操作系统和编程语言是什么

2026-07-29T22:00:00+08:00

大家中学的时候大概就都知道了二进制是怎么回事，也基本能粗略理解内存和硬盘的区别。今天聊两件事：操作系统是什么，编程语言又是什么。

这两件事放在一起说，是因为它们刚好搭成了一个完整的逻辑：操作系统管着电脑的硬件，编程语言让你跟操作系统说话，告诉它你要干什么。

操作系统是个翻译官

你有一台电脑，里面有 CPU、内存、硬盘、键盘、鼠标、屏幕。这些东西怎么协同工作呢？CPU 只能执行机器指令——就是一串一串的 0 和 1。你不可能直接写 0 和 1 来让它干活。硬盘上存着文件，但谁来管这些文件放在哪个位置、怎么读怎么写？鼠标点一下屏幕上的按钮，谁来判断你点到了哪里、应该触发什么反应？

这些东西都需要一个中间人。这个中间人就是操作系统。

你可以把操作系统想象成一个翻译官，或者一个大管家。你（用户）说人话——点一下鼠标、敲一下键盘、拖一下文件。应用软件（比如浏览器、Word）说自己想干什么——我想打开这个文件、我想往屏幕上画一行字。底层的硬件（CPU、内存、硬盘）说你得给我 0 和 1 我才能动。

操作系统就站在中间，把用户的操作翻译给软件，把软件的请求翻译给硬件，把硬件的执行结果翻译回来给你看。

你往硬盘里存一个文件，你不用管这个文件存在硬盘的第几个扇区、磁头要怎么移动。你告诉操作系统"把这个文件存到桌面"，操作系统自己去管底下的事。你打开一个浏览器，你不会关心它被分配了哪一段内存、CPU 调度它跑了多少个时间片——也是操作系统在管。

常见的操作系统你可能都听过：Windows、macOS、Linux、iOS、Android。它们各自有不同的设计哲学和界面风格，但干的活大同小异——管硬件、跑软件、给你一个操作界面。

编程语言是你跟电脑说话的方式

好，你有了操作系统，它能管硬件了。但你怎么让它做一件具体的事情呢？

比如你想算一下 1 到 100 加起来是多少。你觉得很简单，心算也行，但你如果偏要电脑来做，你怎么告诉它？

你跟一个完全不懂中文的人说"把一到一百加起来"，他听不懂。你得用一种他懂的语言。电脑也听不懂中文，它只能听懂机器指令——0 和 1。但直接写 0 和 1 太反人类了。于是人们发明了编程语言。

编程语言就是你和电脑之间的一种约定好的沟通方式。它不像 0 和 1 那么底层，也不像日常语言那么模糊。它足够精确，能让计算机理解，也足够接近人的思维方式，让你能写出来。

Python 是现在最流行的一种编程语言。它长什么样呢？比如你想把 1 到 100 加起来，用 Python 写就是：

total = 0
for i in range(1, 101):
    total = total + i
print(total)

就这么几行。你不需要知道 CPU 的寄存器怎么用，不需要知道内存地址怎么分配。你只需要告诉电脑你要干什么，至于怎么干、硬件怎么配合，操作系统和 Python 的解释器帮你去处理。

操作系统和编程语言搭在一起

你现在可以想象一下这个完整的链条了。

你写了一段 Python 代码。Python 的解释器把你的代码翻译成操作系统能理解的系统调用。操作系统拿到这些调用，去指挥 CPU 运算、指挥内存读写、指挥硬盘存储数据。算完之后，结果从操作系统返回到 Python，Python 再返回到你的屏幕上。

这个链条里，每一层都有自己的职责：硬件负责执行，操作系统负责调度和管理，编程语言负责让你表达你的想法。你只需要学最上面那一层——用编程语言把你的想法写出来就行。底下两层是工具，你不用每次都去碰它们，但知道它们在做什么会让你心里更有底。

你已经在用操作系统了

其实你在看这篇文章的时候，就已经在通过操作系统和硬件打交道了。浏览器是一个应用软件，它请求操作系统在屏幕上画字、从网络接收数据。操作系统把浏览器的请求转换成硬件操作，硬件执行完之后，结果一层一层传回来，变成你眼前的这篇文章。

每一次点鼠标、每一次敲键盘、每一次打开文件，都是这套流程在运转。知道了这一点，你可能会意识到——电脑并不是一个神秘的黑箱，它只是分了很多层，每一层都有人在用，每一层都可以被理解和学习。

你不需要一上来就学操作系统是怎么写的，也不需要知道 Python 是怎么实现的。你只需要知道它们各自负责什么，然后从你最方便入手的那一层开始学。

编程语言就是最好入手的那一层。它离你的想法最近，离硬件最远。写两行代码，运行一下，看到结果——这个正反馈的循环很快。一旦你习惯了用代码说清楚一件事，你就会发现之前觉得复杂的东西其实都可以被拆成一件件小事，一件件地用代码表达出来。

高校教师建议大学新生：有事直接说，别问在吗

2026-07-29T18:00:00+08:00

有一种消息，你收到的时候心里会咯噔一下。

「在吗？」

就两个字，没有上下文，没有前因后果，不知道对方要干什么。你回了「在」，对方可能已经不在屏幕前了。你如果不回，又怕有什么急事。等到你问了「什么事」，对方慢吞吞地开始说——这时候你会发现，其实根本没什么急事，他只是习惯以「在吗」开头。

这种沟通方式，是对双方时间的双重消耗。

为什么「在吗」让人不舒服

发「在吗」的人，底层逻辑是希望对方马上回应自己。但没有任何人有义务马上回应你。对方可能在开会、在开车、在睡觉、在吃饭。你只是发了个消息，凭什么要求对方立刻放下手头的事来跟你在同一个频道上？

把「在吗」换成你说清楚你要干什么，对方有空的时候看到了，可以直接回复你的问题。这才是尊重对方的时间，也是尊重你自己的时间。

有的人半夜两点发一个「在吗」。你被消息震醒了，打开一看，就这两个字。你什么感受？你等了半天，对方又没下文了。第二天你问他什么事，他说「哦已经解决了」。

这个操作，从头到尾，没有任何一个环节是有效率的。

有事说事，这是最基本的能力

找人帮忙也好、问问题也好、汇报事情也好，把三件事说清楚：什么事，跟你有什么关系，为什么找到对方。不需要写得多么得体，不需要措辞多么优美。把事情说清楚，别让人猜，这就是最大的得体。

有的人问别人事情，对方不回复。他就一直等，越等越气。但你想过没有，可能是你问问题的方式让对方不知道该怎么回。你发一个「在吗」，对方回了「在」，然后你又不见了。两次下来，对方就不会再回了。

还有一种情况，人家看到你的消息了，就是不回，一声不吱。这也很糟糕。问题不是非要马上解决，但你得给个信号，哪怕是「我现在在忙，晚点回你」。对面在等的人，至少知道这条消息没有被扔进虚空中。

你不尊重自己，别人怎么尊重你

前几天看到一个视频。有人跑到别人家的地里摘菜，被抓住了，说「我以为这是没人要的」，又说「大不了给你钱」。摘之前怎么不想这个？你不先问一下人家同不同意，上来先把东西拿了，被逮住了再说给钱，这不是买卖，这是不尊重人，也不尊重自己。

很多这种习惯，根源上是从小没有人教。家长不教孩子尊重别人——可能家长自己就不尊重孩子。

有的家长喜欢在别人面前贬损自己家小朋友。孩子考得不错，当着亲戚面说「他就是运气好」；孩子做了件好事，马上补一句「他平时可懒了」。以为这样显得自己谦虚、显得有礼貌。还有更过分的——在公共场合打骂孩子，把孩子拉到人前训斥，拿别人家的孩子对比，把孩子说得一文不值。自己觉得这是教育，其实是在毁掉孩子的自我认知。

这不是谦虚。这是一种很陈旧的作派，以为贬损自己人就能在外人面前显得懂事。假的。孩子从小在这样的环境里长大，学会了这种模式——他不知道自己的时间有价值，不知道自己的感受应该被尊重，自然也不知道怎么尊重别人。

还有一些所谓的客气习惯，比如饭桌上推三阻四互相撕吧抢着买单，假得不能再假。你想买单就买，不想买就别买，在那儿来回推让半天，浪费所有人的时间。孩子看在眼里，学在心里，长大以后也这样——有话不直说，有事不挑明，兜圈子、绕弯子、让人猜。

到了大学，想纠正这些习惯已经要费很大劲了。你跟他说「有事直接说」，他心里过不去那个坎。他觉得不铺垫一下不礼貌，他觉得直接说会显得自己不懂事。可实际上，对方等得焦躁，心里想的是「你能不能快点说事」。

大学里没人惯着你，社会上更是

到了大学，「在吗」这种沟通方式会让你失去很多机会。问老师问题，发个「在吗」，老师可能根本不理你。找同学协作，开局就是「在吗」，对方可能隔半天才回，效率极低。有的人被这么折腾几次，直接就不再跟你沟通了。先是不提醒消息，后来可能就拉黑了。

你没为对方提供任何有效信息，反而增加了对方的沟通成本。对方的时间也是时间。

有个格式可以参考：什么事、跟对方什么关系、为什么找他。三句话，一分钟打完。对方看到了，直接就能处理或者回复。不怕你说得不够好，就怕你什么都不说，先丢一个「在吗」在那里让人等。

沟通这件事，效率优先，得体其次。先把事说清楚，效率上来了，大家都舒服。条理清晰、单刀直入才是最得体的。

教材上的标准答案不一定是真答案——从机翼升力的错误解释说起

2026-07-29T00:00:00+08:00

中学物理课本在讲流体力学的时候，有一个经典的解释：飞机机翼上面弧度大、路程长，下面平直、路程短。空气从机翼前缘分开，为了在后缘同时会合，上方的空气就得走得更快。根据伯努利原理，流速快的地方压力小，所以机翼上方压力小于下方，产生升力。

我在中学学到的就是这个版本。大多数人也都是。

这个解释为什么流传这么广

它有一个很大的优点：说得通。有因有果，逻辑链条完整，不需要微积分，不需要流体力学方程，一个初中生就能听懂。老师在黑板上画一个弯弯的截面，标两个箭头，讲一遍，学生就记住了。

考试的时候，如果你在伯努利方程的题目下面写"因为气流被机翼向下偏转所以产生升力"，判卷老师可能会给你打个叉。标准答案是"上方流速快、压力小"。

我把英文原文翻译在下面，包含 NASA 原版的两个图和伯努利方程的严格表述。

NASA 格伦研究中心（Glenn Research Center）有一个页面，标题就叫"不正确的翼型理论"（Incorrect Airfoil Theory / Equal Transit Theory Interactive）。下面逐条翻译。原文地址：https://www1.grc.nasa.gov/beginners-guide-to-aeronautics/foilw1/

错误的翼型理论

这一页描述的是流传最广的错误解释之一。这个理论可以被称为"更长路径"理论，或者"等时通过"（Equal Transit Time）理论。该理论声称，翼型的上表面比下表面更长。

空气分子在翼型上表面要走的路比下表面更长。为了让分子在后缘会合，走翼型上方的分子必须比走下方的分子移动得更快。因为上方气流更快，根据伯努利方程，压力更低。翼型上下表面的压力差产生了升力。

密度恒定时，面积减小则流速增大。按照这个错误理论，翼型上表面弯曲，收缩了气流。因为面积减小，上方的流速增大。然后根据伯努利方程，更高的流速产生更低的压力，翼型上表面的低压产生了升力。

等程理论错误示意图：上方路径长所以流速快产生低压

逐条驳斥

在讨论这个理论错在哪里之前，先通过一个求解正确流场方程的模拟器来做几个实验，看看翼型周围的实际流场。

NASA 翼型流场模拟器截图

下面用模拟器得到的信息来逐一评估"等时通过"理论的各个部分。

1. 升力翼型的上表面比下表面长？

这一点并不总是正确。实验中的对称翼型产生了大量的升力，而它的上表面和下表面长度完全相同。

想一想纸飞机。它的翼型就是一块平板——上表面和下表面长度和形状完全相同，但飞得好好的。现代有一些低阻翼型，它们的下表面实际上比上表面更长，但仍然产生升力。

这个理论也无法解释飞机为什么能倒着飞——这在航展和空战中经常发生。倒飞时，更长的表面就在下面了。

2. 空气分子在上表面走得更快，以便和下面的分子在后缘会合？

实验 1 显示，升力翼型上表面的气流确实比下表面快。但是实际流速比"使分子在后缘会合"所需的速度快得多。在前缘相邻的两个分子并不会在后缘相邻到达。

"等时通过"理论预测的升力远小于实测升力，因为它给出的速度太低了。上表面的粒子到达后缘的时间早于下表面的粒子。

3. 上表面流速更快所以压力更低？

翼型两侧的压力差产生升力。如实验 1 所示，这一部分理论是正确的。这个理论的问题在于，它试图基于一个不符合物理事实的假设（分子必须同时到达后缘）来计算流速。

真正的升力到底怎么来的

NASA 驳斥了等程理论，那正确的解释是什么？两个关键词：气流偏转和攻角。

气流偏转（Flow Turning）与环量

机翼在空气中运动时，把迎面来的空气往下推。根据牛顿第三定律，空气给机翼一个向上的反作用力——这就是升力最直观的来源。你可以把手伸出车窗，手掌稍微向上翘一点，手就被往上推，这个感觉就是气流偏转产生的升力。

在流体力学里，这个效应被精确地表述为库塔-茹科夫斯基定理（Kutta-Joukowski Theorem）：

其中 (L) 是升力（单位展长），(ρ) 是空气密度，(U) 是来流速度，(Γ) 是绕翼型的环量（circulation）。

环量从哪里来？翼型后缘是尖的，气流必须平滑地离开后缘——这就是库塔条件（Kutta condition）。这个条件在翼型周围自然产生了一个环流。均匀来流叠加上环流之后，上表面气流加速（压力降低），下表面气流减速（压力升高），宏观效果就是向上的升力。

前面提到的等时通过理论，错误不在于伯努利方程本身——方程是对的，速度高压力低也是对的——错在它给流速找了一个虚构的原因（路程长）。实际的原因是环量和库塔条件。

攻角（Angle of Attack）

攻角，就是机翼弦线和来流方向之间的夹角。来流不是正对着弦线吹过来，而是有一个小小的向上倾斜的角度，这就是正攻角。

对于薄翼型，升力系数和攻角的关系非常简洁：

其中 (C_L) 是升力系数，(\alpha) 是攻角（弧度）。这个公式说明：攻角越大，升力越大——直到攻角超过一个临界值，气流从翼面分离，升力急剧下降，这就是失速（stall）。

总升力的完整公式是：

(S) 是机翼面积。把 (CL=2πα) 代进去，可以看到升力和速度的平方成正比，和攻角成正比。这就是为什么飞机起飞要加速、要拉机头——速度不够升力不够，攻角不够升力也不够。

回到倒飞的问题

有了攻角和环量的概念，倒飞就好理解了。飞机倒飞时，飞行员推杆让机头向上仰——相对于来流方向，机翼的攻角仍然是正的（从飞机的角度看机头朝上，气流从下方斜着撞上来）。只要有正攻角，就有环量，就有向上的升力。

对称翼型在这一点上最直观：它的 (CL-α) 曲线是对称的，正攻角正升力、负攻角负升力，全由攻角决定。所以特技飞机和战斗机普遍采用对称或接近对称的翼型——这不是因为对称翼型本身升力更大，而是因为它在正飞和倒飞之间切换时，升力特性完全可控。

标准答案不一定是对的

这件事让我想了很久的问题，不是流体力学本身，是"标准答案"这件事。

标准答案在考试的时候有用。你按标准答案写，得分。你不按标准答案写，哪怕你写的更接近真实，可能扣分。这是一个系统性的问题，不怪老师，也不太怪出题人。一个简化的解释一旦写进教材，被印了很多次，被出成考题，它就变成了事实上的"正确"。再改的成本很高。

但你自己心里得清楚：这个是你为了通过考试而接受的答案，不一定是这个世界的真实运行方式。两个可以同时成立。

从粗略到精细，是认知的正常路径

很多知识的最初版本都是粗糙的、简化的、甚至局部错误的。这不丢人。牛顿力学在相对论出现之前也是"标准答案"，它解释日常现象完全够用，只是到了极端条件才露馅。但牛顿没有错，他只是不够精细。

机翼升力的问题不一样——等程理论不是"不够精细"，它是核心假设就错了。这种错误本来应该在教材修订中被纠正的，但惰性太强。

你可能在中学阶段没有办法改变教材，没有办法改变老师讲的版本，甚至没有办法在考试中写你认为更对的答案。但你可以做一件事：不要以为考完、背完就完了。对一个问题保持好奇，知道它的解释在不同阶段可能有不同的版本，粗的版本后面有细的版本，细的版本后面可能还有更细的。这不是说谁错了，是认知一直在往前走。

别把标准答案当成终点

有的同学到了大学之后，发现有些东西和中学老师讲的不一样，第一反应是"那我之前学的都是错的"——然后要么全盘否定之前的积累，要么抗拒新的知识觉得大学老师胡说八道。这两种反应都不太好。

更好的心态是：之前学的是一个简化的版本，它在当时的认知水平和教学条件下是合理的。现在有机会看到更精细、更接近真实的版本，这是一件好事。知识本来就不是一块死的石头，它是一层一层叠加上去的。

自满的人会停在他觉得"够用了"的那个版本上。固步自封的人会拒绝任何在他看来和他已有的认知不同的东西。这两种人在大学里都不少，出了大学更多。希望大家不成为那个样子。

基础知识

上一篇高校教师建议同学们进入大学之后适当补充各个学科的通识内容并且养成终身学习的习惯下一篇用OpenCode帮忙搜索整理动漫人物关系和时间线以及当年没弄明白的剧情

搜索「」网络结果

调整当前正文文字大小

100%

高校教师建议同学们进入大学之后适当补充各个学科的通识内容并且养成终身学习的习惯

2026-07-28T00:00:00+08:00

最近假期在外面学习，就有一些其他院校的同学问我，说自己是学文科的，或者学工科的，到了大学之后除了专业课之外，还应该了解点别的什么。

我想了想，觉得值得好好写写。

不是说要每个人都变成全才，那不现实。但有些学科里最基本的几个概念，知道了和不知道，看世界的方式会不太一样。下面说的这些，是我觉得不管学什么专业，都值得了解一点的东西。

物理：从离散和连续两个角度来认识世界

不需要会解薛定谔方程。你只要知道有这么回事就行：能量有时候不是连续的，是一份一份的。光既是波又是粒子——不是有时候是波有时候是粒子，而是它同时就是这两个东西，取决于你怎么去看它。

连续和离散，这两个概念在很多地方都会冒出来。数字信号和模拟信号、像素和矢量、甚至时间管理里"整块时间"和"碎片时间"，背后都有连续和离散的影子。脑子里有这个框架，以后再碰到类似的东西，理解起来就快很多。推荐赵峥教授在 B 站的物理公开课 https://search.bilibili.com/all?keyword=%E8%B5%B5%E5%B3%A5 ，讲得深入浅出，适合入门。

数学：无穷和无穷不一样，有的无穷一样大

自然数有多少个？无穷多个。有理数有多少个？无穷多个。但这两个无穷不一样大吗？答案可能出乎意料：自然数和有理数一样多。可以通过一一对应的方法证明——把分数排列成一个表格，按对角线走一圈，每一个有理数都能和一个自然数对上号。这种"能对上号"的无穷，叫可数无穷。

但实数比自然数多。不管你怎么排，总有一些实数是排不进去的。这就是康托尔的对角线证明。无穷和无穷之间，是有大小的。

不用记住证明细节。知道"有些无穷比另一些更大"这件事本身，就是数学带给你的一种认知冲击——很多事情不是直觉想的那样，得靠逻辑去推。推荐 G·伽莫夫的《从一到无穷大》（暴永宁译本，https://book.douban.com/subject/1102715/ ，用非常通俗的语言从数论一路讲到相对论和宇宙学。

统计：从贝叶斯到高维的直觉

统计学里有两个大的流派。频率学派认为概率就是大量重复试验的频率，贝叶斯学派认为概率是你对一件事的相信程度，可以根据新的证据不断更新。这两种思路在日常生活里都能用得上——你看到一个现象，是先假设一个模型然后根据数据调整（贝叶斯），还是等攒够了数据再下结论（频率论），处理问题的方式会很不一样。

另外还有一个容易被忽略的直觉：当数据的维度变高之后，样本量增加带来的帮助往往是边际递减的。更重要的可能是特征维度——也就是你从什么角度去看这件事。维度高了之后，很多在低维空间里不成立的规律会冒出来，这就是所谓"维度的诅咒"。知道这一点，对你以后看数据分析、看 AI 预测结果的时候，会多一分清醒。推荐 Kevin Murphy 的 Machine Learning: A Probabilistic Perspective（简称 MLAPP，https://probml.github.io/pml-book/book0.html）、Christopher Bishop 的 Pattern Recognition and Machine Learning（简称 PRML，https://www.microsoft.com/en-us/research/publication/pattern-recognition-machine-learning/），以及李航的《统计学习方法》（https://book.douban.com/subject/33437381/），三本都是经典。

化学：结构决定一切

同样的碳原子，排成石墨就是滑溜溜的一层一层，排成金刚石就是地球上最硬的东西之一。原子没变，变的是结构。

这个道理其实超出了化学。一个团队换一种组织形式效率可能完全不同，一段文字换个顺序读起来完全不一样，一个零件换个位置机器就转不起来。结构本身就带有力量，能决定性质。推荐北京大学卞江老师在 B 站上的化学视频（https://search.bilibili.com/all?keyword=%E5%8D%9E%E6%B1%9F+%E5%8C%96%E5%AD%A6）和相关公开课，讲得清晰易懂。

生物：演化的丰富和残酷

蛋白质折叠错了一个角度，可能就是致命的遗传病。所以一个小小的结构变化，可以带来如此完全不同的惊人后果。突变是一直在发生的，环境在不断选择。有些突变被淘汰了，有些留下来了，还有些被保留的原因可能仅仅是因为运气。

演化不是朝着一个方向走的。对于演化更细节的话题，建议关注饶毅老师的公众号，以及《知识分子》的公众号，上面有很多可以参考的内容。

避免一种常见的自大

学了一个学科之后容易有一种错觉：觉得这个东西能解释一切。学经济学的觉得所有问题都是激励问题，学物理的觉得所有东西都能建模，学计算机的觉得所有事都能自动化。老话说手里拿着锤子看什么都是钉子，不一定谁对谁错，就是有时候容易忽视了别的学科在同一个问题上已经积累了很久的思考。

有了一点通识之后，至少你知道那里还有别的锤子、别的工具。不一定非得会用，知道它们存在，就不会太笃定自己手里这个就是唯一。这样当然有好处，起码不容易因为无知而自大。

了解历史，但别成为粉丝

历史里有很多精彩的规律。权力的运作、经济的周期、技术的扩散，在长尺度上看一遍，比任何管理学教材都深刻。但不要代入。不要成为某个王朝、某个皇族、某个利益群体的忠实粉丝，觉得自己跟人家血脉相连、荣辱与共。

你不是他们。你是你自己。历史的教训要学，角色不要拿。

想要了解历史，要注意区分几种不同性质的东西。通俗小说是一种，论坛文学和碎片化短视频里那种指点江山是另一种——尤其是某些油腻的中年人甚至中老登在屏幕前信口开河的东西，和真正基于史料的历史研究完全是两回事。北大有一些老师，比如孙庆伟老师做考古和历史研究的，他们的东西可以参考。像厦门大学的某中天教授，他本身是研究美学的，讲历史更适合作为一种爱好者的观点来看待，不必当作严肃的史学研究。

另外，外国人写的通史有时候也会有一些基础性的错误。斯塔夫里阿诺斯的《全球通史》就有不少细节上的问题。这也不奇怪，研究一个不属于自己文化背景的历史，难免有不准确的地方。反过来说，我们自己去看外国的历史，同样也要注意认知上的偏差——不要轻易陷入某种狂热的信仰，也不要轻易否定自己并不一定了解的东西。保持开放，保持谨慎。

对应的，政治学、经济学也应该了解一点。不需要深入到模型和方程，知道权力怎么分配、资源怎么流动，基本的几个框架有一个印象，看新闻的时候不容易被带节奏。

多看点字，少刷点视频

短视频把刺激的阈值拉得很高。十几秒一个笑点、一个反转、一个情绪高潮。习惯了之后，看一篇长文章、读一本没那么紧张的书，可能就坐不住了。不是书不好，是脑子被惯坏了。

能看原著就看原著。《史记》的原文非常精彩，《左传》也一样。文言文一开始可能有点门槛，读几篇就习惯了，比你想象的容易。现代的通俗文学也有很多好作品。重点是看字，不是看画面。文字需要你主动去想，画面直接喂给你。读得越多，想得越深。

纸质书和电子书各有各的好处。电子书方便搜索、方便跑代码，纸质书翻起来快、看着不累。这倒不用太纠结，看你自己习惯什么。关键是别只看视频，更别只刷短视频。

学一门编程语言，配一个智能体

不管你是什么专业，建议学一点编程。Python 或者 JavaScript 都行。不用写得多好，能用就行。学会之后，很多需要重复处理的事情你自己就能搞定，不用每次都找人帮忙。

再配一个智能体工具——比如 opencode 这种开源免费的，或者其他你喜欢的都行。有一个编程语言基础，加一个智能体辅助，能做的事情会多很多。自己动手解决问题的成就感，挺实在的。

养成记笔记的习惯

纸质也好，电子也好，甚至就是微信传输助手里打几行字都行。重点是记下来，然后回头看。

每天睡前想一想今天有哪些收获，哪怕只是一点点；早上翻一下昨天的记录，看有什么遗漏。这不是什么高深的习惯，但坚持下来的话，很多零散的念头就不会丢了。灵感是非常容易跑掉的东西，随手抓一下，可能后面就会用得到。

尽量掌握一门外语

不用多精通。基本的原文阅读能力有就行，看不太懂的可以借助翻译工具。但最好能做到翻译工具不可用的时候，也能基本看懂、能回个邮件。

不是为考试。是因为不同的语言，思维方式不一样。有些概念在中文里有几种说法，在英文里可能要换个角度才能表达清楚。反过来也一样。你学会了用另一种语言去组织思路，就相当于多了一套看待世界的框架。

对自己专业领域的术语，能用外语简单说清楚；对自己感兴趣的东西——比如你喜欢电影、喜欢音乐、喜欢运动——也能跟人聊上几句。这不需要多高的语言水平，需要的是愿意开口。你得到的不仅是一种交流能力，更是从另一个文化视角看同一件事的机会。

总之，想办法让自己更丰富，而不是更狭隘。成为更好的版本，而不要把自己锁到茧子里，变成茧房当中的一只小虫子。

学习是一辈子的事

到了大学，考试就不再是目标了。你要面对的真正的课题，是怎么成长为自己希望的那个样子。每一门课、每一本书、每一次尝试，都是往那个方向上走的一小步。

世界的更新不会等你毕业。总会有新的东西冒出来，总有你不知道的东西。这不是焦虑的来源，是乐趣的来源——你想知道的时候，永远有东西可以学。

这事儿跟年龄也没什么关系。三十岁、四十岁、五十岁，该学还是学。能学是一种自由，能知道自己不会的东西然后去学会，是一种很踏实的能力。

开开心心的，别把自己弄太累。加油。

预览时标签不可点

Name cleared

微信扫一扫赞赏作者

Like the AuthorOther Amount

赞赏后展示我的头像

作品

暂无作品

Like the Author

Other Amount

最低赞赏 ¥0

Back

Other Amount

赞赏金额

最低赞赏 ¥0

基础知识 · 目录

基础知识

上一篇高校教师建议大学生朋友能对自己诚实负责地度过大学生活下一篇教材上的标准答案不一定是真答案——从机翼升力的错误解释说起

搜索「」网络结果

调整当前正文文字大小

100%

高校教师建议大学生朋友能对自己诚实负责地度过大学生活

2026-07-27T00:00:00+08:00

吃饭的时候听到有人讨论最近上映的某个电影里的桥段，大概是说影片里面有两个人吵架，一个说我参加这项运动就是为了赢，另一个说我就是喜欢这项运动本身才来的。

这让我想起大概二十多年前的事。

二十多年前的模糊记忆

《中国队勇夺世界杯》已经过去有二十年了吧？那大概体现了当时部分民众朴素的美好愿望。

那时候我还很年轻，中国队冲击世界杯，好像当时的目标最后也没实现。但这不重要。记得是那个时候电视上有个退钱哥，非常投入，直播也好、评论也好，看得出来是真心热爱足球这件事。球队让他失望了很多次，他还是看，还是关注。前一段时间好像没怎么看到他消息了，不知道怎么回事。但他一直挺热爱这件事的。

后来我就想，人和人不太一样。有的人大概是纯粹的热爱，比如退钱哥面对让他失望多次的国足，似乎依然喜欢足球。

而有的人只是为了赢。足球能赢，他就喜欢足球。足球不能赢了，他就去喜欢能赢的。比如排球能赢就喜欢排球。排球不行了，乒乓球能赢就喜欢乒乓球。乒乓球也不行了，羽毛球能赢就喜欢羽毛球。人总能找到一个相对容易赢的球来喜欢。目的很明显——他只是喜欢赢。至于通过什么赢，不重要。

他最开始可能是希望自己赢的。但自己上去踢足球、打排球、打乒乓球、打羽毛球，都不太行。自己赢不了的时候，如果有一个人跟他有某种联系——同一个文化群体、说同样语言、同样国籍——总之能扯上关系，他就能产生一种归属感。那个人赢了，他跟着高兴。那个人输了，他骂。

十几年前的深刻印象

十多年前，山里发水，我们困在某个地方好几天。正好赶上外面谣传沈阳全运会期间有什么全城环保检查，附近饭店都关了。住在老乡家，老乡好心说能给我们做吃的，我们出去买了点面买了点肉，麻烦人家给包饺子还是做面条来着，记不太清了。

那会儿正好赶上一个挺大的比赛在播，奥运会还是全运会来着。有位以跨栏取得突破、广受关注的选手，跟腱的旧伤犯了，跟腱断裂，好像是单腿蹦着完成了比赛。我当时觉得挺不容易的，我韧带就受过伤，知道特别疼，而他韧带断了肯定更疼，他能单腿蹦也要完成，挺让我佩服的。

结果旁边看电视的几位前辈——学历很高、职称也很高——当场就破口大骂，说这人是XX，怎么怎么着的，说这是民族罪人之类的话。我当时心里不是滋味。

我就想，你们大家之前支持他，是因为热爱这项运动吗？是因为钦佩运动员的拼搏吗？还是只是因为他让你感受到了一个共同群体的归属感，他能替代你去赢？

他赢了你就支持他。他不赢，你就把他骂得一文不值。即使他已经那么惨了，跟腱都断了。

替代式的赢

希望大家不要这样。希望你能分清楚，你支持一个人或者一件事，是因为发自内心真的有热爱，还是因为它能替你赢。

他能做到你自己做不到的事——赢。你就把感情寄托在他身上，他赢了你跟着高兴，好像自己也赢了。这是一种替代。

某某战队得了什么冠军，你熬到半夜看直播。挂科还是挂科，直播只是给平台赚了流量钱，消耗的是你自己的健康。你支持的球队或者选手并不会因为你看直播而踢得更好。

这种赢来得简单，来得廉价。比自己亲自去拼、去争取赢，要容易太多了。你只要投入一下感情，有一个共鸣，就足够有参与感、有归属感了。

读了大学要开始对自己诚实

现在大学生不稀奇了。有人调侃说硕士满街走、博士多如狗——我自己碰巧混了个博士，博士当中我是混得很差的，那我应该就正好是那个多如狗的。

虽然只是读书的年头多了点，可也好歹接受了这么多年高等教育，应该在知识和认知上都有些变化才对。

不只是专业细节上比以前知道得多，也应该是非判断上比以前清楚，对自己思想和行为多少有些反省。

有的同学上课不听课，拿着手机打游戏。下课不学习，刷短视频。食堂都懒得去，找人带饭。

以前是麻烦寝室同学，甚至有开玩笑说拜为义父让人帮带饭的。现在花几块钱就有送餐到寝室的服务。这倒没什么，挺方便的。

但如果连思考和判断，连想一些简单的事情都自己不想了，什么东西都拿去问工具，甚至让工具替自己做决定，或者看网红怎么说自己就怎么弄，那就可惜了。

读了一回大学，如果依然是靠最原始的本能支配自己，那不应该。

就算专业课不愿意学，可以学点自己感兴趣的。

什么感兴趣的都找不到，能在完成学业的基础上锻炼个好身体也行。

开开心心、身心健康，拿到学位证毕业证，然后面对下个阶段的挑战，这也可以。

千万不要动不动陷入极端情绪，成为某些偶像团体的狂热粉丝，牺牲大量时间精力甚至健康。

你得诚实地考虑下面的问题：你沉迷的游戏或者运动、喜欢的那个文艺作品，是真的喜欢它本身，还是只需要一个归属感、只需要一个东西让你体验到赢的感觉？你是不是在躲避什么？这种躲避会一直拯救你么？

你参加竞赛，是因为对这件事本身感兴趣，还是为了赢，为了能够得到奖学金或者保研上的加成？

其实都没问题的，你有啥想法都随你，这都是人自己的自由意志了。

像是在《马丁·伊登》里面，主人公的作品早就写出来了，可是周围的人对他的评价并不高；等他的作品突然大卖赚了很多钱名利双收了，周围那些原本对他冷漠的人又都围上来各种恭维和吹捧。他突然发现自己原来多了很多「真心朋友」，而并不是像以前那样孤独。而这本身才让他认识到这是最大的孤独。

毕竟人类社会目前是成果导向的，你的过程不一定会被人重视，但当你的成果出来了之后会发现突然有很多人恭喜你、为你高兴，甚至和你一道分享荣耀。

当然你没必要对所有人都把所有真实想法说出来，只是尽量说出来的就都是真实想法就好了。

最后，希望你对自己诚实，也希望所有人都对自己诚实。

配图与本文无任何关系

预览时标签不可点

Name cleared

微信扫一扫赞赏作者

Like the AuthorOther Amount

赞赏后展示我的头像

作品

暂无作品

Like the Author

Other Amount

最低赞赏 ¥0

Back

Other Amount

赞赏金额

最低赞赏 ¥0

基础知识 · 目录

基础知识

上一篇OpenCode进阶探索-利用模型进行文献情报检索但不要让模型替代人判断下一篇高校教师建议同学们进入大学之后适当补充各个学科的通识内容并且养成终身学习的习惯

搜索「」网络结果

调整当前正文文字大小

100%

OpenCode进阶探索-利用模型进行文献情报检索但不要让模型替代人判断

2026-07-26T00:00:00+08:00

前面写了一篇怎么从零创作技能的文，这回再写一个新技能的构思过程：帮人学习的技能。

学习这件事的第一步，其实不是直接盲目就开始学，是找到靠谱的东西来学。信息源不靠谱，后面全是白费。这不是什么高深的道理，但很多人着急的时候往往跳过这一步。

从博士论文入手

博士学位论文有一个好处：要过盲审。不是谁都能随便写一篇就毕业的。这就给了它一个基本的质量底线。另一个好处是博士论文通常有章是导论性质的，把某个领域的来龙去脉讲一遍，比教材新，比期刊深入浅出。要了解一个自己不熟的领域，从一篇好的博士论文看起，效率往往很高。

但博士论文不全免费。有的数据库可以免费下，有的只能看摘要。如果让模型来帮忙，它可以去搜哪些数据库是免费的、哪些可以通过学校图书馆访问、哪些有开放获取的政策。这比自己一个一个试快得多。

各学科的专业站点

搜索引擎搜出来的东西良莠不齐。百科类网站谁都能编辑，有的是广告，有的是粉丝维护的。不是说全不能用，是得留个心眼。

但每个学科总有一些大家默认靠谱的地方。计算机的 Stack Overflow、医学的丁香园、物理的 arXiv，这些站点在各自圈子里是经过时间检验的。让模型做一个列表，把不同领域对应的专业站点整理出来，再根据你具体要查的东西去定向搜索，比泛泛地搜好很多。

引用必须能验证

用模型查东西最怕一件事：它编了一个看上去很真的引用，你去查，根本不存在。这在学术上是非常严重的问题。有人因为这个被取消了学位——这不是玩笑。

所以这个技能里有一条死要求：引用的每一个地方，都必须有可点击的超链接。而且要去验证那个链接是不是真的能打开，打开后的内容和引用的是不是一致。做完之后，还要脱离前面的上下文，单独把参考文献列表和正文中的引用位置核对一遍。宁愿少引几条，也不要混进去一条假的。

自己不熟悉的领域要查东西，让模型来检索是好的，让它来替你做判断是不好的。

为什么不能完全交给模型

有个现象得说一下。现在的模型是概率生成，它偏向于给出最常见、最中庸的答案。这在很多日常场景下是优点，但在需要前沿、需要严谨的专业领域就可能是问题。最高概率的往往只是最平庸的老生常谈。

有的人，包括一些老师，习惯什么事都拿模型来问，然后让模型帮自己做决定。这样久了容易产生一种心态，觉得模型说的都对。但到了你自己熟悉的专业领域，你一看就会发现问题——很多地方不靠谱，甚至干脆是错的。你熟悉的领域能看出来，那不熟悉的呢。

以前有一次和一个师兄聊这个事。他坚持用某个模型来给自己提供医疗和健康方面的建议。我劝过他，说不太靠谱。他说有很多什么专家也在这么用，所以可靠。后来有研究团队发了文章，指出多模态模型在诊断场景下存在一个效应：它根本不认真看图，而是直接输出迎合评分标准的答案。你说它答对了，其实是它在做应试，不是真的在看图分析。我把文章发给他，他还是不改变看法。

这件事让我想了很久。不是想模型的问题，是想人为什么在一些事情上会那么难以改变。

认知茧房和永远对的人

有一种情况，我观察过不少次。有的人从来不认为自己需要修正任何看法。支撑他自信的东西，不是对事实的核对，而是他有一套自洽的叙事能解释他看到的东西。只要说得通，就够了。至于事实到底是什么，他没有兴趣去核对。

这不是年龄的问题。有的人年纪轻轻就已经是这种状态了，反过来有的老人保持着旺盛的好奇心和纠正自己的勇气。区别不在年龄，在是否愿意接受自己可能是错的。

遇到这样的人，没必要去辩论。他在自己的叙事里是永远赢的——逻辑自洽、经验丰富、引经据典，你怎么可能辩得过他。但辩论赢了又怎样呢，和自己以为的对错没有关系。

人的时间是有限的。心跳有数，清醒的时刻有限，每一次分心都是不可逆的消耗。把时间花在自己关心的事情上，花在值得深入的东西上，比什么都强。

怎么把这个做成技能

和上一篇视频萃取的思路一样，把刚才说的这些整理成一段话，直接喂给 opencode。下面是我准备好的提示词样本——大家也可以用自己的风格来写，不必照着我的格式来。

要帮我创建一个技能，中文名叫学术导览，英文名叫 AcademicGuide，用来帮人入门一个新的学科领域。

第一步，找博士论文。 搜索和这个领域相关的博士论文，优先找近三年内的。整理出论文标题、作者、学校、年份、下载链接。标注哪些是免费可获取的、哪些需要机构访问、哪些完全封闭。如果是需要机构访问的，也查一下有没有作者发的预印本或者开放获取版本。

第二步，整理专业站点。 针对这个学科，搜索领域内公认靠谱的专业网站、论坛、数据库。不要用泛泛的百科类站点，要找圈子里公认的。比如计算机领域的 Stack Overflow、GitHub，数学和物理的 arXiv、MathOverflow，医学的 PubMed、UpToDate。把地址、简介、更新频率列一个表出来。

第三步，搜索和记录。 每一次搜索的结果都必须保留原始记录。搜到了什么、从哪个网站来的、什么时候搜的，全部记录下来。最终输出的时候，每一条引用都要有一个可点击验证的超链接，还有一个完整的参考文献列表。

第四步，验证引用。 这步最重要。把参考文献列表单独拿出来，脱离前文的语境，逐条打开链接，确认链接能访问、内容和引用的说法一致。没有经过验证的引用一律不能用。引用格式要规范。

后续如果要使用这个技能，直接通过 /学术导览 <领域名称> 来调用。

上面这段话给了模型它需要的所有约束：信息源的选择标准、验证引用的硬性要求、输出格式的规范。自己先想清楚每一步要做什么、做到什么程度才算合格，再把这段话说给 opencode，它就能帮你做出一个可以反复用的技能来。关键是先想清楚再开口，想不清楚的不要交给它替你想。

给出提示词让 opencode 创造技能

技能初步创作完成

制作成功

案例测试

结果参考

说回到技能本身。这个技能的思路并不复杂：找一个方向，搜博士论文和专业站点，把信息源做成列表，每一条都验证引用。模型负责做检索和整理这些费时间的事，人负责判断哪些靠谱、哪些需要再确认、哪些方向值得往下走。分工清楚，各干各擅长的。

预览时标签不可点

Name cleared

微信扫一扫赞赏作者

Like the AuthorOther Amount

赞赏后展示我的头像

作品

暂无作品

Like the Author

Other Amount

最低赞赏 ¥0

Back

Other Amount

赞赏金额

最低赞赏 ¥0

基础知识 · 目录

基础知识

上一篇大学新生可能遇到的各种常见缩写速查简介下一篇高校教师建议大学生朋友能对自己诚实负责地度过大学生活

搜索「」网络结果

调整当前正文文字大小

100%

高兴就好，别让这个那个把你框死

2026-07-25T20:00:00+08:00

古代有先哲说人应该有一种赤子之心。看到小朋友天真烂漫的样子，经过深刻的思辨推导出人性本善，这种想法值得尊重。

也有人看到小朋友抢东西、哭闹、发脾气，就说人性本恶。我家老二就经常抢他哥哥的吃的，有时候挠他、咬他、抓他头发。但一个一两岁的小朋友做这些事，不太见得是有什么恶念，就是一种本能。小动物们也互相咬着闹着玩，抢东西，这都是很正常的。

从几个片段去推导整个人性的善恶，大概都不太靠谱。

执着于有，执着于无

世界上有两种常见的状态。一种人觉得已经有的东西就是不会变的。现状很稳固、很神圣，自己没有办法去想象它会有变化，甚至不认为它可能变化。这种人执着于"有"。

这些年世界的变化够多了。投资市场也好、产品价格也好、行业的兴衰也好，你曾经深信不疑的东西，可能只是在一个瞬间就变了。觉得已经有的东西绝对不会被改变，这个想法本身就不太对。

另一种人过于悲观，执着于"无"。觉得什么东西到最后都没有意义——往生去也，什么都留不下。有的是经过深思熟虑的哲学判断，有的可能就是自己受挫了之后不开心，随口那么一说。

其实不管是执着于有还是执着于无，这些人往往未必是自己真的那么想的。

中学时候的一件小事

我上中学那会儿，初中二年级确实很中二。很多同学就呆呆地做一些自己以为很帅气很有个性、其实挺傻的事。

当时有一个同学每天都要把头发弄上去，扭成一个像懒羊羊一样的发型。那时候还没有懒羊羊这个动画片呢——我不理解为啥要这样。他说这个感觉很有个性。但他每天下课都得弄点啫喱水把头发弄上去，挺耽误时间的，而且那东西味道挺大。我自己是过敏性鼻炎，闻了就难受。说实话我挺讨厌这个同学的。

后来想想，不应该这么轻易去讨厌一个人。对他来说，这可能是很重要的事，是他的一种执念。

这事跟我举过的另一个例子有点像。有的人爱吃辣椒，就觉得很多食物都应该放辣椒。有的人完全不喜欢吃，就认为根本不应该有辣椒这种东西。两个都太极端了。吃辣椒的人自己吃自己的，别往不吃的人碗里加就行。不吃的人自己不吃就行了，也犯不着管别人。

矛盾不算很重的还有一个例子：抽烟。经常有人在公共场合抽烟，熏着别人，不喜欢烟味的人就很反感。不同的人有不同的平衡。有的人吸烟，但从来不在有旁人的地方吸，工作场所从来不碰。有的人不吸烟，但见到别人吸烟也不一定吱声。我小时候过敏，见到吸烟的同学就躲着走。如果非要跑我旁边吸烟，我就肢体说服教育他。后来发现人家要是人多，我也打不过，还好过几年大家都毕业了，也就忍过去了。一直到本科还有在公共场所吸烟的，甚至读了研也还有——专门跑到你宿舍里来抽烟。这时候得让他知道这是个底线。如果真的完全无法接受，找辅导员申请调解。碰巧我当年那个辅导员就比较那个——把我们几个同学的学生证收上去弄磁条刷新，后来就再也没还我，还不承认。

不管怎么着，别激化矛盾，尽量想办法化解开。

存在即合理——这话是错的

执着于有的人，总觉得自己无力改变什么，又觉得已经有的东西无比神圣，想去捍卫点什么。执着于无的人，总觉得自己做什么都没有意义，动不动就失去动力，或者总觉得别人做什么没有意义，喜欢打击别人。

"存在即合理"这句话，大概是很早以前有人翻译得不太准确，后来被一些人拿来四处引用，慢慢就变了味。满清政府当年那些不平等条约都是存在的，能说它合理吗？不能说因为它存在就有合理性。存在的东西有它的现实意义与之对应，但不等于就是合理的。

类似的话还有小时候老师经常说的："他为什么欺负你啊，他怎么不欺负别人啊？"其实那个同学可能别人他也欺负，只不过这次欺负到你了，你来反抗，老师就认为你俩都有问题，各打五十大板。然后来一句"一个巴掌拍不响"——其实这时候我就想把一巴掌拍他脸上，问他一个巴掌响不响。当然了，那会儿我小，打不过他。后来长大了，想明白了，也不打人了。

"无"也能变成一种束缚

执念不只是"有"。那些觉得自己做什么都没有意义、总觉得自己很挫败、总觉得一切最终都会消散——这些情绪也是一种束缚。它除了让你悲观一点儿之外，没什么别的帮助。既然没什么帮助，它也不实用，也没什么实际价值。有时候或许能让你冷静一点儿，但大多数时候用处不大。

那不如就听听相声，看看喜剧，有什么事能让自己开心起来。哪怕吃个冒菜，吃个麻辣烫，能让自己开心的事儿就去做，让自己不开心的事儿尽量想办法过去。

并不是说最终的结果是无、一切就都成了空虚的没有意义的。正好相反：如果不管怎么着都要走向一个旅途的终点，那这个旅途就更应该珍惜一下，好好看看路上有没有什么好玩的。

这当然是一个非常简单的比喻。黄色的森林里分开了两条路，其实选哪条都行，不用非得是更少人去的那个。有的人可能觉得选更少人去的让自己显得个性，但这种选择反而就挺没个性的。你真怎么想的、真怎么选的，就怎么选就行了，别考虑人多人少。如果大家都爱听一首歌，你也爱听，你觉得不好意思，这其实没必要。但有的小朋友可能会这样——或者如果大家都不爱听，然后你就偏说自己爱听，这其实也是很做作的一件事。

不要让你已经学会的东西限制你

说这么多，不是为了否定"有"，也不是为了否定"无"。人类社会有无相生，不要执着于具体的某一个状态、某一个人、某一件事。也别让"无"把自己给束缚住。

这个不执着，不是说不要在意，而是不要让你所掌握的、所接触到的东西，成了你的阻碍。

就像学会炒菜知道用火烤着吃，后面就一直只用这一样，不学煮，不学炒，不学高压锅，不学其他做法——这就是让自己已经所学的东西成了自己的限制。

戚继光在《绩效新书》里有一句话：心有外物而不化，自恃旧习以为佳。说的是有些士兵以前可能学过一点武术，心里有了这个之前学的东西，就不太愿意接受戚继光军队里的训练方法。他认为自己学的旧的就是好的，新的不学。戚继光说这样的士兵是最不可带的——完全没有改进的机会了。一张白纸，你还可以画点妥当的画，不同风格也可以选、可以改。如果上面已经画了很多，画得又不一定好，但又画了很多、成了沉没成本，对他来说真的很难改变。

我希望大家尽量不执着——不变得僵硬、保守和固化。不是说不要努力。

我自个儿就换过很多专业，学过很多乱七八糟的东西。今天还遇到一个十八九岁的小朋友问我，你学这些干嘛呀。我说万一我现在干的这些事儿以后活不下去了，我可能再找一个活法。另外有一个没太好意思跟他说的：我觉得这些事儿很有趣。我做所有的事儿最重要的一个原因，就是觉得这玩意儿好玩。如果觉得没意思、很痛苦，我就不这么做了。

不管是学习还是工作，尽量别让自己痛苦。如果感到痛苦，要不然薪酬足够覆盖掉痛苦，但那样也不一定很开心。要不然就是有机会从中提升自己。在现在这种状况下，不是每个人都能够轻易地说走就走，毕竟很多人有家有口、上有老下有小。

不管怎么着，都应该让自己开心一点。开心比什么都重要。人开心了、有奔头了，后面遇到什么事就见招拆招。天天特压抑，一点乐趣都没有，那就太可惜了，也太糟糕了。

希望大家开心，别太执着。

大学新生可能遇到的各种常见缩写速查简介

2026-07-25T00:00:00+08:00

先说清楚：这篇文章不是提倡用英文缩写。恰恰相反。

钱钟书有个牙缝韭菜的典故——说话的时候牙齿上沾着一片韭菜，自己不知道，别人看着难受。中文里夹英文缩写也是这个道理。你说了一堆，听的人还得逐个解码，听得很累。能不混用就不混用，该说中文说中文。

但问题是你拦不住别人用。老师随口就说「这个 DDL 之前交上来」，同学说「你是不是被 PUA 了」，群里讨论买电脑全是「SSD 要 1T 的」「内存 16G 够不够」。你不认识这些缩写，就真听不懂，不是你的问题，是信息被挡住了。

所以这里把大学里常见又容易让人懵住的缩写按领域列出来。不是为了让你学着用，是为了你碰到的时候能一眼认出是什么意思。

校园日常

这几个是大学生活里出现频率最高的，先记这几个就行。

缩写	英文全称	解释
AKA	Also Known As	又名、也就是
CEO / CFO / CTO	Chief Executive / Financial / Technology Officer	首席执行官 / 首席财务官 / 首席技术官。C 打头的基本都是最高层
CIO	Chief Information Officer	首席信息官。管企业信息化建设的高级职位。注意甄别，有的机构可能会以 CIO 为名头行骗，对不熟悉的邀约保持警惕
DDL	Deadline	截止日期。大学生最怕的词之一，作业、论文、申报材料都有 DDL
FYI	For Your Information	供你参考。邮件、消息里转发信息时常带的前缀
HR	Human Resources	人力资源。管招聘、薪资、考核的部门
KOL	Key Opinion Leader	关键意见领袖。就是网红、大 V、某个领域里说话有分量的人
KPI	Key Performance Indicator	关键绩效指标。衡量你做得好不好的数字指标
OKR	Objectives and Key Results	目标与关键结果。一种定目标和追踪执行的管理方法
PR	Public Relations	公共关系。管对外形象和媒体沟通。注意 GitHub 上 PR 是 Pull Request（合并请求），两个意思完全不同
PUA	Pick-Up Artist	原指以不良手段搭讪操控他人。现在多指精神操控、持续打压让人自我怀疑的行为。被导师 PUA、被老板 PUA，就是说被人持续贬低打压

学业相关

缩写	英文全称	解释
arXiv	Archive（χ 是希腊字母 chi）	预印本论文网站。物理、数学、计算机等学科发正式期刊之前先把论文挂上去，全世界都能免费看。读论文、跟踪前沿研究必知的站点
CET-4 / CET-6	College English Test Band 4 / 6	大学英语四六级。国内本科最基本的英语水平证明
CSSCI	Chinese Social Sciences Citation Index	中文社会科学引文索引，简称「C 刊」。文科导师常挂在嘴边的就是它
DOI	Digital Object Identifier	数字对象标识符。论文的唯一编号，有了它就能永久定位到一篇文章
EI	Engineering Index	工程索引。工科论文的重要收录库，比 SCI 覆盖面更偏工程应用
GPA	Grade Point Average	平均绩点。大学成绩的综合评分，满分通常是 4.0。一般 90-100 分对应 4.0，80-89 对应 3.0，70-79 对应 2.0，60-69 对应 1.0，不及格是 0。各校微调不一样，但大致是这个比例。申请研究生或者找工作会看。不过，如果你有很好的学术文章、扎实可靠的软件作品、或者竞赛拿了省一等奖乃至国家级三等奖以上，这些东西都比 GPA 更厉害
GRE	Graduate Record Examination	美国研究生入学考试。去北美读研要考这个
IELTS	International English Language Testing System	雅思。和托福一样，另一个主流的英语水平考试
ISBN	International Standard Book Number	国际标准书号。每本公开出版的书独有的编号，找书、借书、引用都会用到
MOOC	Massive Open Online Course	大规模开放在线课程。网上免费的大学课程，比如中国大学 MOOC、Coursera
ORCID	Open Researcher and Contributor ID	开放研究者身份识别码。每个研究者的唯一 ID，不管同名同姓还是换了单位，这个码不会变。发论文、投基金都用的到
PDF	Portable Document Format	便携式文档格式。不管什么系统打开格式都不乱
PPT	PowerPoint	这个不用解释了吧。上课做展示、答辩、汇报都离不开的幻灯片
SCI	Science Citation Index	科学引文索引。收录高水平期刊的数据库，发 SCI 论文是很多理工科研究生的目标
TOEFL	Test of English as a Foreign Language	托福。去英语国家留学的语言考试

学位与证书

缩写	英文全称	解释
ACCA	Association of Chartered Certified Accountants	特许公认会计师。国际会计准则方向的会计证书
BA / BS	Bachelor of Arts / Science	文学学士 / 理学学士。你本科毕业拿的就是这个
CFA	Chartered Financial Analyst	特许金融分析师。金融行业含金量很高的证书，三级考试通过率很低
CPA	Certified Public Accountant	注册会计师。会计行业的核心证书
EMBA	Executive MBA	高级管理人员 MBA。给有多年管理经验的人读的，通常不脱产
MA / MS	Master of Arts / Science	文学硕士 / 理学硕士
MBA	Master of Business Administration	工商管理硕士。工作几年后很多人去读，培养管理能力
MPA	Master of Public Administration	公共管理硕士。培养政府部门或非营利组织管理人才
PhD	Doctor of Philosophy	哲学博士。最高学位，不限哲学专业，理工科博士也是 PhD
PMP	Project Management Professional	项目管理专业人士认证。管理类通用的国际证书

计算机硬件

缩写	英文全称	解释
ARM	Advanced RISC Machine	一种低功耗处理器架构，手机、平板、苹果 M 系列芯片都是 ARM 架构的
BIOS	Basic Input/Output System	基本输入输出系统。开机时最先启动的那套程序，UEFI 是它的升级版
CPU	Central Processing Unit	中央处理器。电脑的大脑，Intel 和 AMD 两家主导
CUDA	Compute Unified Device Architecture	NVIDIA 的 GPU 并行计算平台。做 AI 训练、科学计算基本都用它
DDR	Double Data Rate	双倍数据速率内存。现在主流是 DDR4 和 DDR5，数字越大越快
DirectX	Direct eXtension	微软的多媒体和游戏编程接口。Windows 上玩游戏离不开这个
FPGA	Field-Programmable Gate Array	现场可编程门阵列。一种可以自己定义电路逻辑的芯片，硬件工程师用得多
GPU	Graphics Processing Unit	图形处理器。俗称显卡，做图形渲染和 AI 训练的主力
HBM	High Bandwidth Memory	高带宽内存。堆叠封装的内存，带宽极高，AI 加速卡（比如 NVIDIA H100）上用的
HDD	Hard Disk Drive	机械硬盘。便宜容量大，适合存不常用的文件
HDMI	High-Definition Multimedia Interface	高清多媒体接口。连显示器、投影仪用的
IO	Input / Output	输入输出。所有数据进出设备的统称
NPU	Neural Processing Unit	神经网络处理器。专门跑 AI 推理的芯片，手机和笔记本里越来越常见
NVMe	Non-Volatile Memory Express	非易失性内存高速传输协议。现在最快的 SSD 接口协议，比 SATA 快好几倍
Oculink	Optical Copper Link	外置 PCIe 连接方案。把显卡或者硬盘通过一根线接到笔记本外面，带宽比雷电高
OpenCL	Open Computing Language	开放的并行计算框架，不绑特定厂商，AMD、Intel、NVIDIA 都支持
OpenGL	Open Graphics Library	跨平台的 2D/3D 图形渲染接口。CAD、游戏引擎都会用到
PCIe	Peripheral Component Interconnect Express	高速外设总线。显卡、SSD、网卡都插在这个接口上，现在主流是 PCIe 4.0 和 5.0
PSU	Power Supply Unit	电源。把 220V 交流电转成电脑用的低电压直流电
RAM	Random Access Memory	随机存取存储器。也就是内存，程序运行时临时存放数据的地方，断电就没了
RISC	Reduced Instruction Set Computer	精简指令集。一种 CPU 设计思路，指令简单但执行快。ARM 就是 RISC 架构的代表
ROM	Read-Only Memory	只读存储器。数据写进去后断电不丢
SATA	Serial Advanced Technology Attachment	串行 ATA。硬盘接口，机械硬盘和老一点的固态硬盘都用这个，比 NVMe 慢但便宜
SSD	Solid State Drive	固态硬盘。比机械硬盘快很多，现在装系统基本都是用 SSD
TPU	Tensor Processing Unit	谷歌的 AI 加速芯片，张量处理器。普通用户摸不到，但学 AI 的话会经常听说
USB	Universal Serial Bus	通用串行总线。就是那个插 U 盘的接口
VRAM	Video RAM	显存。显卡上专用的内存
Vulkan	—	新一代跨平台图形与计算 API，比 OpenGL 效率更高。AMD 开源贡献出来的，名叫 Mantle 的前身
x86	—	Intel 搞出来的处理器架构，PC 和服务器上用得最多的 CPU 指令集。AMD 和 Intel 的桌面 CPU 都是 x86 兼容的
x86-64 / AMD64	—	x86 的 64 位扩展，由 AMD 率先推出，Intel 后来跟进。现在几乎所有桌面电脑的 CPU 都支持这个

软件与网络

缩写	英文全称	解释
API	Application Programming Interface	应用程序编程接口。不同软件之间交换数据的协议和规则
CLI	Command-Line Interface	命令行界面。黑框框里敲命令，程序员必备
CDN	Content Delivery Network	内容分发网络。把网页、图片、视频缓存到离你最近的服务器上，加快访问速度
CSV	Comma-Separated Values	逗号分隔值。表格数据纯文本存储的格式，Excel 能开
DNS	Domain Name System	域名系统。把网址（如 baidu.com）转成 IP 地址的服务
GUI	Graphical User Interface	图形用户界面。你看到的带窗口、按钮、图标的界面都是 GUI
HTML	HyperText Markup Language	超文本标记语言。写网页用的标记语言
HTTP / HTTPS	HyperText Transfer Protocol (Secure)	网页传输协议。HTTPS 多了加密层，现在几乎都是 HTTPS 了
IDE	Integrated Development Environment	集成开发环境。写代码的软件，比如 VS Code、PyCharm、IDEA
IoT	Internet of Things	物联网。让冰箱、灯泡、门锁联网的技术统称
IP	Internet Protocol	互联网协议。给每个联网设备分配的地址
JSON	JavaScript Object Notation	一种轻量数据交换格式。程序之间传数据用得多
LaTeX	—	学术论文排版工具，数学公式渲染特别好，理工科写论文几乎必学
Markdown	—	轻量级标记语言。用简单的符号就能排版，写 README、记笔记、写博客都用得到
OOP	Object-Oriented Programming	面向对象编程。一种编程思想，Java、Python、C++ 都支持
OS	Operating System	操作系统。Windows、macOS、Linux 都是 OS
P2P	Peer-to-Peer	点对点。不经过中心服务器，设备之间直接传数据。BT 下载、PCDN 都基于这个
PCDN	P2P Content Delivery Network	P2P 内容分发网络。利用大量用户设备互相传数据来加速分发，比传统 CDN 省带宽成本
SQL	Structured Query Language	结构化查询语言。和数据库打交道用的，增删改查全靠它
URL	Uniform Resource Locator	统一资源定位符。就是网址
VPN	Virtual Private Network	虚拟私人网络。加密你的网络流量，用来访问受限资源或保护隐私
VR / AR	Virtual Reality / Augmented Reality	虚拟现实 / 增强现实。VR=戴头盔沉浸虚拟世界，AR=在现实画面里叠虚拟信息
XML	eXtensible Markup Language	可扩展标记语言。和 JSON 差不多，以前更流行

云服务

缩写	英文全称	解释
BaaS	Backend as a Service	后端即服务。帮你搭好服务器端，你只写前端就行，比如 Firebase、Supabase
DaaS	Desktop as a Service	桌面即服务。云端给你一台虚拟电脑，远程连上去用
IaaS	Infrastructure as a Service	基础设施即服务。给你虚拟机、硬盘、网络，你自己在上面装系统配环境，比如阿里云 ECS、AWS EC2
MaaS	Model as a Service	模型即服务。把训练好的大模型包装成 API 给你调用，不用自己部署，按用量付费
PaaS	Platform as a Service	平台即服务。给你一个配好的开发环境，你只写代码不碰服务器，比如 Heroku、Vercel
SaaS	Software as a Service	软件即服务。不用装软件，打开网页就能用，比如飞书、石墨文档、Notion

版本控制与开源

缩写	英文全称	解释
CLA	Contributor License Agreement	贡献者许可协议。给开源项目贡献代码前要签的协议，把代码版权授予项目方
LGTM	Looks Good To Me	我看没问题。代码审查时常用的批准语
PR	Pull Request	合并请求。你在自己分支改完代码，发起一个请求让主项目合进去。GitHub 上最常见的协作操作
RFC	Request for Comments	征求意见。提出一个方案让大家讨论，常见于技术标准制定
WIP	Work In Progress	工作中。代码还没写完，先提交上去占个位置

GitHub 常见操作

操作	解释
clone	克隆。把远程仓库完整下载到本地
commit	提交。把修改保存到本地仓库，要写一段说明改了啥
fork	复刻。把别人的仓库复制一份到你自己的账号下，方便你改完再提交 PR
issue	议题。报 bug、提建议、讨论问题的地方
merge	合并。把一个分支的代码合入另一个分支
pull	拉取。把远程仓库的最新修改同步到本地
push	推送。把本地 commit 好的修改上传到远程仓库
release	发布。打包一个稳定版本供下载
star	收藏。给项目点星表示关注和赞赏，类似点赞
watch	关注。订阅仓库动态，有更新会通知你

无人机/航模相关

缩写	英文全称	解释
ADC	Analog-to-Digital Converter	模数转换器。飞控用它检测电池电压电流
BEC	Battery Eliminator Circuit	降压电路。从主电池分出一路低压给飞控、接收机供电
ESC	Electronic Speed Controller	电调。控制电机转速的器件，飞控发信号给它，它驱动电机转
FC / FCS	Flight Control System	飞行控制系统。也就是飞控板，无人机的大脑
GNSS	Global Navigation Satellite System	全球导航卫星系统。GPS、北斗、GLONASS 等的统称
GPS	Global Positioning System	全球定位系统。给飞控提供位置和速度
IMU	Inertial Measurement Unit	惯性测量单元。集成加速度计和陀螺仪，感知姿态
LiPo	Lithium Polymer	锂聚合物电池。航模无人机最常用的电池类型
P (如 2P)	Parallel	锂电池并联数。2P=2 节并联，容量翻倍
PPM	Pulse Position Modulation	另一种遥控信号编码方式，比 SBUS 老
PWM	Pulse Width Modulation	脉宽调制。控制舵机和电调的基本信号
RTK	Real-Time Kinematic	实时动态定位。厘米级精度的定位技术
RX / TX	Receiver / Transmitter	接收机 / 发射机
S (如 3S、6S)	Series	锂电池串联数。3S=3 节串联，电压乘 3
SBUS	Serial BUS	Futaba 发明的一种串行总线协议，遥控器接收机和飞控之间用
UART	Universal Asynchronous Receiver/Transmitter	串口通信。飞控接 GPS、数传等外设用的
VTX	Video Transmitter	图传发射机。把相机画面无线传回地面

电子与通信

缩写	英文全称	解释
AC / DC	Alternating Current / Direct Current	交流电 / 直流电。电池出来是直流，插座出来是交流
Bluetooth	—	蓝牙。短距离无线通信
DSP	Digital Signal Processor	数字信号处理器。专门处理音频、视频、传感器信号的芯片
IC	Integrated Circuit	集成电路。也就是芯片
LCD	Liquid Crystal Display	液晶显示器。最常见的屏幕类型
LED	Light-Emitting Diode	发光二极管。小小的指示灯，也很省电
MCU	Microcontroller Unit	单片机。小型的处理器，嵌入式设备常用
NFC	Near Field Communication	近场通信。刷卡、刷手机用的短距离无线技术
OLED	Organic LED	有机发光二极管。屏幕的一种，黑色不发光的
PCB	Printed Circuit Board	印刷电路板。所有电子元器件焊在上面的那块绿板子
RFID	Radio Frequency Identification	射频识别。门禁卡、物流标签用的
SoC	System on Chip	片上系统。把 CPU、GPU、内存等集成在一颗芯片上，比如手机处理器
Wi-Fi	Wireless Fidelity	无线局域网。就是无线上网

医学与健康

缩写	英文全称	解释
ADHD	Attention Deficit Hyperactivity Disorder	注意力缺陷多动障碍。俗称多动症
BMI	Body Mass Index	身体质量指数。体重(kg)÷身高(m)²，衡量是否超重
CT	Computed Tomography	计算机断层扫描。用 X 光从多角度拍然后合成三维图像
ECG / EKG	Electrocardiogram	心电图
EEG	Electroencephalogram	脑电图
ICU	Intensive Care Unit	重症监护室
MRI	Magnetic Resonance Imaging	磁共振成像。没有辐射的扫描方式，看软组织更清楚

其他常见缩写

缩写	英文全称	解释
ASAP	As Soon As Possible	尽快
B2B / B2C	Business to Business / Consumer	企业对企业 / 企业对消费者。商业模式的分类
CAD	Computer-Aided Design	计算机辅助设计。AutoCAD、SolidWorks 就是干这个的
DIY	Do It Yourself	自己动手做。比如自己装电脑、自己焊东西
ETA	Estimated Time of Arrival	预计到达时间
FAQ	Frequently Asked Questions	常见问题解答。几乎所有产品文档都有这一栏
IPO	Initial Public Offering	首次公开募股。也就是公司上市
NGO	Non-Governmental Organization	非政府组织。境外 NGO 在华活动需依法登记。遇到以 NGO 名义拉拢参与敏感项目的，注意甄别，防范被利用从事涉密或危害国家安全的活动，主动规避风险，保护好自己和家人
NPO	Non-Profit Organization	非营利组织。和 NGO 类似，不追求利润的社会组织。同样需注意甄别境外背景，保护个人信息
OCR	Optical Character Recognition	光学字符识别。把图片里的文字提取出来，扫描件转文字用的
QA / QC	Quality Assurance / Quality Control	质量保证 / 质量控制。测试产品确保不出问题的
R&D	Research and Development	研发。企业中搞研究的部门
ROI	Return on Investment	投资回报率。投了多少钱带来了多少收益
RSVP	Répondez s'il vous plaît（法语）	请回复。邀请函上常见的，要你确认去不去
SOP	Standard Operating Procedure	标准作业流程。规定一件事具体怎么做的文档
TBA	To Be Announced	待公布
TBD	To Be Determined	待定

这里列的只是一部分，当作一个快查表来参考，当然不限于这些。大学四年里你还会遇到更多的缩写。原则很简单：每次遇到不认识的，当场查一下，三秒钟的事，但心里有数了下次就不会慌。 别攒着不查，攒多了就真不愿意查了。

预览时标签不可点

Name cleared

微信扫一扫赞赏作者

Like the AuthorOther Amount

赞赏后展示我的头像

作品

暂无作品

Like the Author

Other Amount

最低赞赏 ¥0

Back

Other Amount

赞赏金额

最低赞赏 ¥0

基础知识 · 目录

基础知识

上一篇OpenCode 进阶之「技能创作」：拆解描述典型任务后验证实现再做成可复用的「技能」下一篇OpenCode进阶探索-利用模型进行文献情报检索但不要让模型替代人判断

搜索「」网络结果

调整当前正文文字大小

100%

飞机为什么能倒着飞——从"等程理论"这个流传最广的错误说起

2026-07-24T15:00:00+08:00

很多人小时候都听过一个解释：机翼上面弧度大、路程长，下面平、路程短。空气分子在机翼前缘分开，为了在后缘同时会合，上方的空气就得跑得更快。根据伯努利原理，流速快的地方压力小，所以上方压力小于下方，产生升力。

这个故事讲得通顺、容易记，在科普书和中小学教材里流传了几十年。

但它不对。

NASA 明确说了这是错的

NASA 格伦研究中心有一个专门的页面，标题就叫"不正确的翼型理论"（Incorrect Airfoil Theory）。页面上逐条驳斥了这个"等程/等时理论"（Equal Transit Time Theory）：

对称翼型同样产生升力——它的上下表面长度完全一样，按等程理论该没有升力，但实际显然有。
纸飞机就是个平面——上下同长同形，照样飞得好好的。
现代低阻翼型的下表面可能比上表面更长——按等程理论该产生"向下"的升力，但它不。
实际测量中，上表面的气流速度比等程理论预测的快得多——两个分子并不会同时到达后缘。上面的分子先到。
这个理论完全无法解释飞机为什么能倒着飞——航展上倒飞是常规操作，按等程理论，倒过来弧度在上方，升力应该向下把人拍地上。

那升力到底怎么来的？

升力的真正来源：环量与气流偏转

严谨的流体力学解释用的是库塔-茹科夫斯基定理（Kutta-Joukowski Theorem）：

升力

\[ L = \rho U \Gamma \]

其中 $\rho$ 是空气密度，$U$ 是来流速度，$\Gamma$ 是绕翼型的环量（circulation）。环量来自库塔条件——翼型后缘尖锐，气流必须平滑离开后缘，这自然产生了一个绕翼型的环流。均匀来流叠加上这个环流，上表面气流加速（低压），下表面气流减速（高压），合力向上。

从牛顿第三定律来看更直观：机翼把气流往下偏转，气流给机翼一个向上的反作用力。这就是升力。

翼型的弯度（camber）可以提高效率，但不是产生升力的必要条件。攻角才是关键——机翼前缘略微往上翘，气流就被压向下方。

那倒飞是怎么回事

理解了上面的原理，倒飞就好解释了：

飞机倒飞时，机翼仍然是那个机翼，弧度方向没变。但是飞行员调整了攻角——机头往上仰（从座舱视角看），让来流从机翼的下方斜着撞上来。这样，气流仍然被机翼往下偏转（相对于天空），升力仍然向上。

对称翼型在这方面优势最大——它上下完全对称，正攻角产生正向升力、负攻角产生反向升力，完全由攻角决定。这也是为什么特技飞机和战斗机普威使用对称翼型或接近对称的翼型。

下面用位势流（Joukowski 翼型 + Kutta-Joukowski 定理）做的严格数值模拟来展示两种情况：

动图1：正常飞行时流线随攻角变化

动图2：对称翼型在正/负攻角间切换，升力方向随之改变但净升力可控

小结

"上面弧度大路程长所以升力"是错的，NASA 有专题页面详细解释。
升力 = 环量 × 速度 × 密度，来自库塔-茹科夫斯基定理。
气流被往下偏转，反作用力往上，这才是升力的直观理解。
倒飞时靠攻角调整，气流仍然往下偏，升力仍然往上。
对称翼型的特技飞机倒飞最自如——全由攻角决定升力方向。

参考文献

NASA Glenn Research Center, Incorrect Airfoil Theory (Equal Transit Time), https://www1.grc.nasa.gov/beginners-guide-to-aeronautics/foilw1/
Anderson, J. D., Fundamentals of Aerodynamics, McGraw-Hill
计算代码：images/airfoil_lift.py（Joukowski 变换 + 位势流 + Kutta 条件 + 压力分布）

OpenCode 进阶之「技能创作」：拆解描述典型任务后验证实现再做成可复用的「技能」

2026-07-24T00:00:00+08:00

前面有很多跟OpenCode相关的一点经验分享给大家：

高校教师建议大一开学要有电脑，还要安装OpenCode使用智能体

opencode 的四种用法与为什么我推荐命令行

不只是写代码：用opencode和免费模型帮你搜教程、下视频

用 opencode 帮学习：上课没听懂的东西，让它帮你查清楚画明白

OpenCode进阶-安装技能再改进：从PDF读取内容来填表和文档

其中关于技能的部分，有不少朋友看过了基于已有技能修改的案例之后，表示想从头来创作一个自己的技能，希望给个案例参考一下。

这回咱们考虑这样一个场景：从视频提取图片做出文档。

看视频费眼睛，也费时间。刷过学习视频的人都懂——半个小时讲下来，真正有信息量的可能就那几分钟。剩下的大半是口头禅、重复、空镜头。视频的信息密度确实不高。

但很多好东西只有视频。当年在北师大听过不少赵峥老先生的课，后来发现他在 B 站上还发了很多物理公开课。讲得好，但不看可惜，长时间盯着又累。

有了 opencode 之后就在想，能不能让它帮个忙：把视频下载下来，提取音频转成逐字稿，抓关键帧做成幻灯片，再写一篇总结。整个流程跑一遍，输出一份随时能翻看的图文材料。说干就干，这个事来回改了挺久，最后不光能做出来，还把整个过程做成一个技能了。

这个过程本身挺值得说一说的。

和上一回提到的"改一个已有的技能"不一样了，这次终于是从零开始，先想清楚要干什么，把步骤拆解开，自己详细叙述给 opencode 让它跑通验证，再把流程整理成技能文件存下来。后面每次直接调用就行，不用重新解释。

从零把一件事变成技能

有时候你觉得一个流程特别好用，但每次都得跟 AI 从头说一遍，太累了。比如这个"下载视频→提取字幕→关键帧→幻灯片→文章"的流程。你心里门儿清，但不想每次打这么多字。

opencode 的技能系统就是解决这个的。你第一次把流程跟它讲清楚，它帮你写成技能文件。以后直接调技能名，当初设计好的流程完整载入上下文，省掉所有重复的口舌。

怎么跟 opencode 说清楚你要干什么

关键是把任务拆解完、说详细。拿视频萃取这个例子来说，我给 OpenCode 的对话大概是下面这样的。（注意，我就是把下面的文字直接发给 OpenCode 的，大家也可以这么做，但没必要严格按照我这样的文本格式和次序，完全可以有自己的风格探索出来哈。）

要帮我创建一个技能。这个技能中文名字叫视频萃取，英文名字叫VideoExtract，要完成下面这些事。

第一步，想办法调用工具把链接里的视频下载下来。yt-dlp 能用的就用 yt-dlp 下载。如果实在不能下载，就用截图加音频流的方式把内容获取下来。

第二步，处理音频。如果能获得原始的字幕就用原始字幕，字幕比转写更准。如果不能，就基于音频来生成字幕，用 whisper 或者 faster-whisper 都行。这样就能得到一个可以作为基础文本的东西——但注意不要直接用这个文本，原始转写会有笔误和口误。

第三步，修正文本。基于前面的字幕信息或者转写出来的文本，整理一遍，看里边会不会有笔误或者口误之类的。说错的东西修正一下，重复的口头语去掉。修正完的版本才是有用的。

第四步，从视频里提取关键帧。有些视频连续好几帧变化不大、信息差异不大，要设置一个合理的阈值，只截真正有画面变化的帧。尤其是那种 PPT 幻灯片的公开课，画面几秒一翻页，关键帧就在翻页的那一刻。截下来的关键帧按照前后次序记录好时间轴。这个时间轴后面有用——你点文字想快速跳转的时候，能对得上。

第五步，生成最终产物。前面你有了文本（修正过的逐字稿）也有了图片（关键帧），就可以生成了：

可以做成一个网页，打开方便。网页里内嵌好图片也排好文本。
网页也可以转成 Word 文档，方便编辑。
生成幻灯片（PPTX）。
生成一个干货总结，去掉铺垫和重复，只留核心内容，但不能损失任何重要信息。
最后，有一个可选项：中间的这些临时文件（下载的视频、提取的音频、原始截图）要允许用户选择保留还是删除。

后续如果要进行上面的过程，要能够直接通过 /视频萃取 https://www.bilibili.com/video/BVxxxxxx 之类的命令来完成这个过程。

这段对话为什么能让 opencode 写出一个完整的技能

拆开看的话，上面这段话给了 opencode 它需要的所有原材料：

每一轮要做什么：下载、音视频分离、文本修正、关键帧、最终产物，五步，每一步都明确了输入和输出。
工具链：yt-dlp 下载、ffmpeg 提取音频和帧、whisper 转写、python-pptx 做幻灯片。
异常兜底：不能下载就截图加音频流，任何平台都能拿到内容。
质量控制：修正转写中的笔误和口误，不是直接用原始输出。
多格式输出：网页、Markdown、Word、幻灯片、总结，不同需求都能覆盖。

openode 拿到这些之后，能把它转成一个结构化的 SKILL.md 文件——包含命令名、触发条件、步骤模板、输出清单、工具依赖、注意事项。下次直接用命令调就行了。

写好技能之后怎么用

按照上面的过程完成之后，OpenCode应该已经技能文件放到 ~/.config/opencode/skills/ 对应的目录下。之后只需要说一句：

/视频萃取 https://www.bilibili.com/video/BVxxxxxx

它就自动把整套流程载入上下文，你不必再说第一步干嘛第二步干嘛。这也是技能和纯搞一个脚本的区别——技能是带上下文、带步骤的，模型知道整体要干什么。重复的事一次跑通，后面全靠命令。

完成后的效果如下图所示：

然后检查一下对应目录应该是给制作好了所要求的文件了。

上面这个案例只是为了给大一新生演示，所以非常简单也非常粗糙，其实技能系统还有很多更复杂的玩法，此处就不展开更多了。

千万不要怕自己没有什么编程基础啊经验啊等等都，这些都不应该太担心，大胆尝试一下再说。

没有任何编程经验的朋友也不要担心，只要你能把这个过程说清楚，并且是可控的，每一步都有明确的验证的方法，就基本可以大胆尝试不用担心了。

因为重要的不是任何的编程的基础和经验，而是把一件事情拆解成一个个可行步骤的这个过程。

好了，接下来根据你需要的场景，想办法创作属于自己的技能吧。

预览时标签不可点

Name cleared

微信扫一扫赞赏作者

Like the AuthorOther Amount

赞赏后展示我的头像

作品

暂无作品

Like the Author

Other Amount

最低赞赏 ¥0

Back

Other Amount

赞赏金额

最低赞赏 ¥0

基础知识 · 目录

基础知识

上一篇高校教师建议大学新生先掌握「提问的智慧」下一篇大学新生可能遇到的各种常见缩写速查简介

搜索「」网络结果

调整当前正文文字大小

100%

OpenCode 从零创作技能：把视频萃取出文章和幻灯片

2026-07-22T12:30:00+08:00

前面有很多跟 OpenCode 相关的一点经验分享给大家：

其中关于技能的部分，有不少朋友看过了基于已有技能修改的案例之后，表示想从头来创作一个自己的技能，希望给个案例参考一下。

这回咱们考虑这样一个场景：从视频提取图片做出文档。

这个过程本身挺值得说一说的。

从零把一件事变成技能

怎么跟 opencode 说清楚你要干什么

要帮我创建一个技能。这个技能中文名字叫视频萃取，英文名字叫 VideoExtract，要完成下面这些事。

第一步，想办法调用工具把链接里的视频下载下来。yt-dlp 能用的就用 yt-dlp 下载。如果实在不能下载，就用截图加音频流的方式把内容获取下来。

第五步，生成最终产物。前面你有了文本（修正过的逐字稿）也有了图片（关键帧），就可以生成了：

可以做成一个网页，打开方便。网页里内嵌好图片也排好文本。
网页也可以转成 Word 文档，方便编辑。
生成幻灯片（PPTX）。
生成一个干货总结，去掉铺垫和重复，只留核心内容，但不能损失任何重要信息。
最后，有一个可选项：中间的这些临时文件（下载的视频、提取的音频、原始截图）要允许用户选择保留还是删除。

后续如果要进行上面的过程，要能够直接通过 /视频萃取 https://www.bilibili.com/video/BVxxxxxx 之类的命令来完成这个过程。

这段对话为什么能让 opencode 写出一个完整的技能

拆开看的话，上面这段话给了 opencode 它需要的所有原材料：

每一轮要做什么：下载、音视频分离、文本修正、关键帧、最终产物，五步，每一步都明确了输入和输出。

工具链：yt-dlp 下载、ffmpeg 提取音频和帧、whisper 转写、python-pptx 做幻灯片。

异常兜底：不能下载就截图加音频流，任何平台都能拿到内容。

质量控制：修正转写中的笔误和口误，不是直接用原始输出。

多格式输出：网页、Markdown、Word、幻灯片、总结，不同需求都能覆盖。

opencode 拿到这些之后，能把它转成一个结构化的 SKILL.md 文件——包含命令名、触发条件、步骤模板、输出清单、工具依赖、注意事项。下次直接用命令调就行了。

写好技能之后怎么用

按照上面的过程完成之后，OpenCode 应该已经把技能文件放到 ~/.config/opencode/skills/ 对应的目录下。之后只需要说一句：

/视频萃取 https://www.bilibili.com/video/BVxxxxxx

完成后的效果如下图所示：

然后检查一下对应目录应该是给制作好了所要求的文件了。

上面这个案例只是为了给大一新生演示，所以非常简单也非常粗糙，其实技能系统还有很多更复杂的玩法，此处就不展开更多了。

千万不要怕自己没有什么编程基础啊经验啊等等的，这些都不应该太担心，大胆尝试一下再说。

没有任何编程经验的朋友也不要担心，只要你能把这个过程说清楚，并且是可控的，每一步都有明确的验证的方法，就基本可以大胆尝试不用担心了。

因为重要的不是任何的编程的基础和经验，而是把一件事情拆解成一个个可行步骤的这个过程。

好了，接下来根据你需要的场景，想办法创作属于自己的技能吧。

高校教师建议大学新生先掌握「提问的智慧」

2026-07-22T00:00:00+08:00

大胖哥大胖哥

先说清楚，这里说的"提问的智慧"不是当年那篇经典文章。

当年那篇讲的是，遇到系统报错、软件闪退、代码报 bug，该先去搜索引擎搜一圈，看看有没有人踩过同样的坑。

那是搜索引擎时代的智慧，现在已经不够用了。

当然了，也依然还有很多人连那种搜索习惯都还没养成。

何不自己搜

经常有人在群里问：这是什么？去哪下？怎么用？

这些东西放在搜索时代就该自己解决。

你不动手指，先去张嘴，人家能不想：你连搜都懒得搜？

这种直接伸手的可能是两种人。

一种是怯懦。怕搜出来看不懂的东西，胆小不敢点，怕试错了搞坏了。

另一种就是懒惰。问一嘴有人答了就省事，多方便呢。

第三种人现在很少了——就是真不知道世界上有搜索引擎这东西。

工具强多了

现在的大语言模型，能联网，能查资料，能帮你把网上的碎片信息理到一个文档里，还都标着出处。

你遇到不懂的东西，正确做法是先让大模型帮你搜一下。

汇总一个简短的东西，五百字以内，最好是三百字以内。

你读了，想了，拿着这个初步的认知再去跟别人聊。

这是这个时代提问的基本姿势。

你什么都直接张嘴问。

搁以前人家会问你：不知道有搜索引擎吗？

搁现在人家会问你：不会用大模型吗？

你要是真不会，那是无知。不知者不为怪，下次知道了就好。

可你要是会，也清楚该怎么做，偏不去动那个手，那就是懒。

懒可以给自己找很多理由，思维惯性也好、习惯也好，总能找到一个台阶下。

但不该这样。

该怎么问

我说个具体例子，老师跟你说，「有个东西叫 opencode，挺好用的，大家试一试。」

你该怎么反应？

别问「那是什么」。

别问「在哪下载」。

更别问「怎么安装」。

所有搜索引擎能解决的问题，不搜一下就问出去就应该为自己感到羞耻。

你应该问的是：「我找到了这个网址，下了这个版本，装好了。我拿它试了一下，能写文章、能画图、能做作业。我想继续用它整理下周要交的实验报告，这个方向可行吗？有什么要注意的？还有哪些其他场景？」

这才是带着思考问问题。

问路的道理

这和问路是类似的。

走丢了就先导航。

导航有时候会带你走小路、拐错巷子，但你得先走过一遍，别上来就拽着路边的人问。

我今天就去取了个快递。

菜鸟驿站在同一片地址附近有三家。

我先按照收到的短信（上面没有联系方式）导航了，结果到了其中一家。

但是附近还有另外两家，二百米外有一家，三百米外还有一家。

我推测导航可能会出错，这个小区的一期、二期、一区、二区等等对导航来说可能混淆了。

我走到窗口，没问"我快递在哪"。

说的是：

「取件地址留的是这里的菜鸟驿站，但短信里没有门牌号，导航到了你们这儿，请帮我查一下我手机尾号的这件是你们家这里的还是另外两家的？

如果没有找到，估计是另外两家的，一般来说大家经常弄混的可能是哪家？

容易走错？中间那条路还在修，是不是只能绕？」

对方很愿意帮我。因为我自己探索了来的，而且也提供了足够背景信息。

所以一定要带着自己的上下文去问。

带着探索过的痕迹，带着初步的设想。

这样人家能跟你有更多的共同语境，也更容易接你的话茬。

沟通不是索取，这是交流。

别当伸手党

别问哪些「我用什么软件好」或者「该怎么装」。

人哪有义务和时间精力来给解决所有问题？

你该说的是：「我想要做某件事（明确表达目的），搜到了某个软件（初步的线索），装好了一个版本（已经有尝试），试了一下拿它试做了某个东西（探索了用法），不知道这条路往下走可行不（参考经验）？还有没有更顺手的工具（扩展方向）？需要注意哪些问题（兜底一下）？」

提问不是不行。但你得带着自己的努力作为诚意去问。

空手张嘴等人投喂，以前是不知道搜索引擎，现在是连大模型都懒得用。

你带了探索、带了上下文、带了你的想法去问，别人起码沟通起来更容易，自然也更有可能愿意接住你的话。

怎么才算高效沟通？

就是你问出来的问题，对方能看出来你已经自己做过了、自己试过了。

他能接着你的话说下去，而不是从零开始给你补课。

以前哥廷根学派有个说法，说愚蠢的问题是受欢迎的。

这话没错，但有个前提：你得先意识到这问题愚蠢，然后自己也先试一下。

试过了，实在搞不定，再来问，这不用担心。

怕的是明明自己随便动动手就能搞定的东西，偏不去碰，张嘴就问。

那不是愚蠢，那是懒惰。

行为上懒惰已经可怕了，思想上的懒惰是不可原谅的。

预览时标签不可点

Name cleared

微信扫一扫赞赏作者

Like the AuthorOther Amount

赞赏后展示我的头像

作品

暂无作品

Like the Author

Other Amount

最低赞赏 ¥0

Back

Other Amount

赞赏金额

最低赞赏 ¥0

基础知识 · 目录

基础知识

上一篇OpenCode进阶-安装技能再改进：从PDF读取内容来填表和文档下一篇OpenCode 进阶之「技能创作」：拆解描述典型任务后验证实现再做成可复用的「技能」

搜索「」网络结果

调整当前正文文字大小

100%

OpenCode进阶-安装技能再改进：从PDF读取内容来填表和文档

2026-07-21T00:00:00+08:00

前面说了 opencode 能帮你搜教程、下视频，也能帮你补上课没听懂的知识点。

那更复杂的事儿能管吗？

比如我有一堆杂七杂八的资料文件，要从里面提取数据，然后按一个固定模板填好，格式一点都不能走样——这种活儿它能干吗？

能。

今天就拿一个真实的例子，从头到尾演示一遍——从安装技能、发现技能不够用、当场改进技能、重新安装、到最终拿改进后的技能把活儿干了的全过程。

先把技能装上

opencode 有个东西叫"技能"（Skill），相当于给智能体预设了一套标准化的操作流程。你遇到一类反复出现的任务，就给它装个技能，下次一句话就能触发整套流程。

我维护了一个开源的技能仓库，在 GitHub 上：https://github.com/cycleuser/Skills/

之前也有相关介绍：

OpenCode Skills：分享一套自己乱写的还算实用的 AI 编码技能库

自用的 OpenCode Skills 合集更新：从 6 个技能到 22 个，以及必须承认的问题

自用的OpenCode Skill再次更新：22个skills重新打磨了一遍，顺路解决了OpenCode导致整个图形界面崩溃的问题

里面目前有二十多个技能，覆盖架构设计、开发、测试、写作、专利、公文、模板保真填表这些场景。

安装方式有两种。

第一种，直接把仓库地址丢给 opencode，让它自己装。你在对话里跟它说"帮我把 https://github.com/cycleuser/Skills/ 这个技能仓库安装到本机"，它就会自己去克隆仓库、跑安装脚本、把技能文件放到该放的位置。你啥都不用管，等它装完就行。

第二种，一条命令的事儿：

curl -sSL https://raw.githubusercontent.com/cycleuser/Skills/main/quick-install-opencode.sh | bash

跑完就全装好了。

如果你想改了技能直接生效，也可以克隆到本地再安装：

git clone https://github.com/cycleuser/Skills.git
cd Skills
python3 install-opencode.py install --source .

装完验证一下：

ls ~/.config/opencode/skills/

能看到一堆技能目录就对了。技能文件放在 ~/.config/opencode/skills/ 目录下，opencode 启动时自动发现。

填表技能是什么

这次要用的是一个叫 tianbiao（填表）的技能，专门干"照着模板填数据、保持格式不走样"的活儿。

复杂的事情用技能

它的核心原则就一条：复制原模板，把数据填进对应单元格，保持原有字体、边框、合并单元格与版式，绝不从零重排。

为什么不能从零画表？因为用 python-docx 从零新建表格的话，字体、字号、边框、行高、合并单元格全都会走样，跟原模板对不上。学校的表格、单位的报表，格式都是有固定要求的，差一点都不行。所以必须打开原模板，只替换单元格里的文字，让填进去的内容继承单元格原有的样式。

这个技能有几个命令：

/填表 <模板> <数据> — 按模板填充数据，保持格式
/填表 convert <文件> — 把 .doc/.xls 老格式转成可编辑的 .docx/.xlsx
/填表 inspect <模板> — 填之前先摸清模板的表格结构
/填表 check <文档> — 填完校验格式保真度和数据一致性

原来它的工作流是五步：转换老格式 → 摸底模板结构 → 准备数据 → 填充 → 校验。适用于试卷质量分析表、成绩分析表、过程性评价档案、考查课报告这类学校表格。

事情的起因

我手头有一份 84 页的 PDF，是 2026 年中国大学生计算机设计大赛吉林省级赛的成绩公示名单，里面有一千多条获奖记录。还有一个空白的获奖统计表模板，docx 和 xlsx 各一份，只有表头没有数据。

我要做的就是把 PDF 里的获奖记录提取出来，按模板的格式填进去。

这个活儿看着简单，实际上又臭又长：PDF 表格解析、换行处理、数据清洗、模板格式保真、批量填充——每一步都有坑。

我翻了一下填表技能的说明，发现一个问题：它只覆盖了"从结构化源文件（点名册、成绩表）提数据"的场景，而我这次的数据源是一堆非结构化的 PDF，里头的表格还各种换行错位。

也就是说，技能不够用。

基于已有技能来修改

不够用怎么办？改。不用从零写，在已有技能基础上加东西就行。

基于已有技能来修改

重点改 tianbiao。缺什么补什么——它缺的是"从非结构化资料提取文本"的能力。原来的技能只会从结构化的 Excel 点名册里读数据，碰到 PDF 和图片就抓瞎。

改进出来新技能

新增了一个完整的文本提取规则文件，涵盖：

文件类型路由：按扩展名自动分流——有文字层的 PDF 用 pdfplumber 提取，没文字层的扫描件转图片后 OCR，Office 文档用 python-docx/openpyxl 原生解析
OCR 引擎选择：中文扫描件首选 PaddleOCR，英文用 Tesseract，高精度需求上云服务
错行检测与纠正：PDF 多栏排版被读成交错文本的问题，用坐标信息按 Y 轴分行、X 轴分栏来修复
OCR 纠错：形近字（已→己）、数字混淆（0→O）、换行错位、乱码字符的清洗规则
提取质量校验：关键数字回查原文位置、字段完整性、数值合理性

改进出来新技能

同时更新了工作流：原来的"Step 3 备数据"拆成两条路径——3a 从非结构化资料提取（PDF/图片/扫描件），3b 从结构化源文件读取。新增了 /填表 extract <资料目录> 命令。

技能版本从 1.0.0 升到 1.1.0。

技能改进后安装完成

改完的技能文件在 GitHub 仓库里，要同步到本机 opencode 的配置目录才生效。

技能改进后安装完成

技能文件全部复制到位：tianbiao 新增了 text-extraction.md 文本提取规则，更新了工作流和命令。验证版本号 1.1.0 对了，文件都在，安装完成。

具体测试

技能装好了，开始干活。先加载填表技能，然后把两个文件路径甩给它——一个是 PDF 数据源，一个是 xlsx 模板。

具体测试

同目录下还有个 docx 文件，也是模板。我先分别检查了三个文件：PDF 是 84 页的成绩公示名单（数据源），xlsx 和 docx 都是空白模板（只有表头，7 列 51 行）。

技能开始执行

技能开始执行。先用 pdfplumber 提取 PDF 的表格数据。

技能开始执行

第一轮提取到 989 条，但 PDF 实际有 1003 条记录。差了 14 条。排查发现是两种特殊情况：5 条"弃赛"和 9 条"未获奖"——它们的奖项字段不是"一等奖/二等奖/三等奖/优胜奖"，所以没被匹配到。另外还有学校名和赛道名跨行的问题（比如"吉林农业科技\n学院"被读成两行）。

修正了提取逻辑：把"弃赛"和"未获奖"也纳入奖项集合，加了 clean() 函数清理换行符。第二轮提取，1003 条全部到位。

要求进一步明确

提取到 1003 条，但模板只有 50 个数据行。这是个明显需要确认的点——不可能瞎填。

要求进一步明确

opencode 没有自作主张，而是停下来问了我一个问题：你是要全部 1003 条、还是只填某个学校/某个教师/特定学生的？我选了"全部记录"，那模板就要扩展到 1003 行。

这个"不确定就问"的设计很重要。填表技能的铁律之一就是"不编造、不猜"——宁可停下来确认，也不闷头干完了发现方向错了。

完成了

确认后开始填充。docx 版本：克隆模板的数据行扩展到 1003 行，每行填入序号、学校、成员、指导教师、赛道、奖项、是否推荐国赛。数据行用宋体 9pt 居中，表头设了跨页重复（tblHeader），每行设了防跨页断裂（cantSplit）。

完成了

xlsx 版本也同步生成：用 openpyxl 打开原模板，只写值不动原有样式，数据行设了宋体 9pt 居中加边框。

两个文件都填充完毕，1003 条记录一条不少。

得到文件

校验结果：

得到文件

docx 版本：1004 行（1 表头 + 1003 数据），7 列，标题段落保留原模板样式，表头跨页重复，数据行防断裂。抽查首尾数据与源 PDF 一致。

xlsx 版本：1004 行 7 列，表头样式保留，数据行宋体 9pt 居中带边框。

最终成品

两个文件保存在原目录下：2026设计大赛获奖统计-已填充.docx 和 2026设计大赛获奖统计-已填充.xlsx。

整个过程我做了什么？

开头说了两句话——一句是"参考那篇文章改进技能"，一句是"用改进后的技能填这两个文件"。中间发现技能不够用、当场改了技能、重新安装、提取 PDF、修正数据、扩展模板、填充、校验——全是 opencode 自己跑的。

回顾一下这个过程

这个案例跟前面几篇不一样的地方在于：它不是"用一个现成工具干一件事"，而是"工具不够用的时候先改工具，再用改好的工具干活"。

opencode 的技能系统设计的初衷就是这样的。技能不是黑箱，是透明的 Markdown 文件——你能看到它的每一条规则、每一个步骤。不够用了就加规则，过时了就改流程，不需要等别人发版本。

这次具体加了什么？一个 text-extraction.md，把"从 PDF/图片/扫描件提取文本→OCR 识别→错行纠正→数据校验"这套流程标准化了。下次再遇到类似的活儿——不管是成绩公示、获奖名单、还是什么别的 PDF 表格——一句话就能触发整套流程，不用从头教。

这其实就是用 AI 的正确姿势：不是每次都从零开始描述需求，而是把重复出现的任务沉淀成技能，让工具自己记住怎么做。

你用的次数越多，积累的技能越多，后面干活的效率就越高。一开始可能要花点时间改技能、调规则，但这个投入是复利的——同一个技能以后每次用都不用再教。

学会用工具，从学会改工具开始。

对新人大学生来说，在很多需要填表儿的时候，也可以用这类的东西来帮自己提高效率。

预览时标签不可点

Name cleared

微信扫一扫赞赏作者

Like the AuthorOther Amount

赞赏后展示我的头像

作品

暂无作品

Like the Author

Other Amount

最低赞赏 ¥0

Back

Other Amount

赞赏金额

最低赞赏 ¥0

基础知识 · 目录

基础知识

上一篇初步说一说大学里的教风和学风下一篇高校教师建议大学新生先掌握「提问的智慧」

搜索「」网络结果

调整当前正文文字大小

100%

高校教师建议大学新生不要用内向的标签影响自己的沟通效率

2026-07-20T08:30:00+08:00

原创

有人天生话少，有人喜欢独处。这都没问题。

但还有一种情况——你遇到需要沟通的事就紧张。跟人说话紧张，表达想法紧张，被回应之前就紧张，连问一句「你刚才说的是什么意思」都紧张。然后给自己贴个标签：我内向。

可能不是。

内向的人需要表达的时候也照样能说，只是不需要的时候不想说。

如果你是想说但不敢说，那可能不是因为性格，是因为还没学会怎么开口。

怕被否定，怕被嘲笑，怕对方不理你，怕说错了显得很蠢。这很正常。很多人都有过这个阶段，只是有的人早一点跨过去了，有的人晚一点。

没跨过去的容易把自己归类为「内向性格」，然后就不再尝试了。

这有点可惜了，而且影响很大。

跟人费劲，跟 AI 也费劲

很多人以为跟人沟通紧张是天生的，跟 AI 总该没问题——AI 不会拒绝你，不会不耐烦，不会打断你。

也许问题根本不在于对方是谁，问题在于你自己敢不敢把话说清楚。

你跟 AI 的交互效率，取决于你能多大程度、多准确地把脑子里的东西倒出来。

脑子里想了很多，打出来就剩「帮我写个东西」。

AI 只能猜。

猜不对的时候，你嫌 AI 笨。

其实是信息被你自己砍掉了大半。

这样一来，表达的动力就越来越弱了。

哪怕是世上最强的模型坐在对面，你不敢把自己的意思完整地推出去，也只能用到它很少的能力。

你给它的是碎片，它还给你也只能是碎片。

然后你觉得 AI 不行。

其实是你没给 AI 机会去理解你。

反过来，哪怕你语言组织能力一般，只要你尽力去把你的想法倒出来——打字、画图、举例、类比、甚至说「我说不清楚但大概是这个意思你听我尽量详细说」——AI 总有办法去逼近你的真实意图。

表达的量够了，理解度才能上来。

一个容易陷入的循环

这个模式可能很早就开始了。

第一次受挫很受伤，没有得到及时的鼓励和反馈，自己闷在心里。

上课不敢举手，不是不想回答，是怕答错了被注意。

作业不会做不敢问，不是不想学，是怕问了显得自己不行。

时间长了，你确实会比那些敢问敢说的同学显得「慢」。

不是智力上慢，是信息效率上慢——人家不断获取反馈、不断修正。

你躲着，越躲越习惯待在自己的壳里。

然后你落后。

落后就更不愿意开口。

更不愿意开口就更落后。

等到了成年，这个循环已经转了很多圈了。

你可能已经把「回避→落后→更回避」的模式归结为「我就是内向」「我就是不喜欢跟人打交道」。

当然不喜欢——如果从来没从沟通中获得过正反馈，谁都不会喜欢。

这不是性格，是一种可以练习的能力

沟通和跑步、写字、编程一样，是可以练的。

小时候没练好，现在自然起点低了一些。

但水平差的态度应该是去练，不是绕开。

当你轻易地说「我内向」，好像这就意味着这是天生的、不可变的、甚至是一种值得被接受的标签。

可如果你说「我在这方面能力需要加强」，你就承认了可以改变、可以选择练习、可以从最低门槛开始一点点做。

两种描述，指向的是不一样的路。

内向是很正常的人格特质，不需要也很难被改造。

但如果是因为害怕而回避沟通，这就是一个可以通过练习来改善的问题。

它让你在所有需要协作、需要求助、需要表达的节点上都吃亏。

包括跟 AI 之间——你同样会敏感，同样会在不确定的时候选择沉默，同样不敢追问、不敢推翻重来、不敢要求 AI 换一种方式解释。

你跟 AI 的交流，仍然被你跟人交流的习惯限制着。

试试这样做

不需要变成一个社交达人。不需要在任何场合都侃侃而谈。

只需要在需要沟通的那一刻，把话说出来。

哪怕磕磕巴巴，哪怕表述不够准，哪怕对方暂时没听明白。

继续说。换方式说。

把「怕被拒绝」放一边，把「把事儿说清楚」放第一位。

跟人如此，跟 AI 也是如此。

不要只给它一句话。

给它背景，给它约束，给它你的判断，给它你试过的方向。

不用在意它对你的评价，而是给它你对它输出的评价。

AI 不怕你话多。AI 怕你什么都不说然后它不好进行模式选配和回应。

开口的能力不是天生的性格，是可以攒出来的习惯。

我其实很内向

郭德纲说自己内向，别人可能不信。

我也信他说自己内向。

我自己就是个很内向的人，一般都把想法和感受放在心里面。

除非觉得必要，很少主动跟人分享。

但我上课不用麦克风，几十人到上百人都能听清。

沈阳站里帮走散的老人喊了一嗓子让全场寂静下来，那是日行一善。

跟孩子滔滔不绝甚至喋喋不休，那是本职工作的职责所在。

内向，喜欢安静，个性没必要也不需要改。

但沟通习惯，需要说的时候能说出来，这是可以练的。

配图与文字毫无关系。

预览时标签不可点

手机测产状界面演进：从粗略演示到离线野外工具

2026-07-20T00:00:00+08:00

上一篇讲清楚了产状的数学计算。链接如下：

https://blog.cycleuser.org/%E4%BA%A7%E7%8A%B6%E6%B5%8B%E9%87%8F.html

点击访问原文也可以直达。

这篇记录一下一个网页从一个"能跑就行"的原型，一步步迭代，最后长成一个能在没信号的野外拍照录音存数据离线用的工具的过程。

下面每个版本都配一张当时的界面示意图。

v1.1.0 初版

v1.1.0　初版：能跑就行的箭头

最早一版只想着把倾向倾角算出来显示。界面很直接：顶部一个满宽的绿色"开始测量（授权传感器）"按钮，中间一块大数字面板显示倾角和倾向，下面一个圆形表盘，表盘里一根黄色长箭头从中心指向倾向方向，长度按倾角缩放。再往下把 Yaw/Pitch/Roll 和屏幕法线一并铺开。

几点不足：

按钮占了一整行，空间利用低。
那根黄色箭头偏长，穿过中心点，与底部刻度文字重叠。
倾向数字后缀"（真北）"括号，中文里还夹着英文 "Dip Dir"，中英混排。
原生数据全部展开，不关心这些行的用户也得一并看着。

v1.2.0　加水平仪气泡

第一个改进是把中心圆盘做成了一个像真水平仪的东西。圆心多了一圈绿色外环和一个会移动的小气泡，气泡按法线水平分量偏移，倾斜越大气泡越靠边。手感上像在用真正的水准管，比光看数字直观多了。指针还是那根黄箭头，依然又长又黄。

v1.2.0 加水平仪气泡

v1.3.3　指针固定，表盘转动

这是个根本性的设计翻转。之前一直是"指针动、表盘不动"，但这样在固定平面上转手机时指针会跟着转，不符合"产状不变指针就不动"的直觉。改成反过来：

指针固定朝画布顶部，永远不动。
整个表盘刻度盘随倾向旋转，让倾向方位的刻度对准顶部指针。
气泡继续当物理水平仪。

这一改，贴在斜面上转手机时指针保持稳定，表盘刻度像指南针那样转，配合指针直接读出方位。

v1.3.3 表盘随倾向转

v1.3.5　加横纵水平管

光一个圆形水平仪只能看总倾斜，看不出"往哪边歪"。这一版在圆盘两侧加了两根细长水平管：一根纵向（测南北分量），一根横向（测东西分量），各自只反映自己那方向的倾斜。两根管贴着圆盘外边，没占多少空间，但读数更明确了。

v1.3.5 加横纵水平管

v1.3.6　存帧、下载 CSV、备注

前面几版都只是"实时看一眼"，野外测量要记录。这版加了三个东西：

冻结/继续切换（单按钮，文本跟着切换）。
存一帧：每次点击把当前帧原始数据存一条，含序号、时间、倾向、倾角、四元数、加速度、法线分量。
下载 CSV：把所有记录导出，UTF-8 BOM 兼容 Excel，文件名带时间戳。
旁边加了个备注输入框，每条测点能敲几个字。

这下从"看"升级到"记"了。

v1.3.6 存帧下载CSV

v1.3.8　开始/冻结合一，详情折叠

界面越来越挤。这版做了两件减法：

开始测量和冻结读数本来是两个按钮，合成一个：没启动时显示"开始测量"，启动后变成"冻结读数"，再点切回继续。少一个按钮就少一行。
那一长串 Yaw/Pitch/Roll/法线/罗盘/磁偏角/经纬度，默认收起来，只显示一个"原生数据"标题，点了才展开。普通人不用看这些。

界面一下子清爽了，圆盘成了绝对主体。

v1.3.8 开始冻结合一、详情折叠

v1.3.11　水平管细长贴边，指针白色半透

水平管本来有点粗，挤得圆盘不好看。这版把它们做细做长，紧贴圆盘外缘，像真的水准管贴在仪表边上。指针也改了：

缩短，不再顶到刻度字。
从刺眼的黄色换成白色半透明，与深色背景对比清晰但不喧宾夺主。
屏幕朝下时才变红警示。

按钮文案也统一：开始测量、保存、下载，字号统一，加了 white-space:nowrap 防止英文状态下换行。

v1.3.11 水平管细长指针白色半透

v1.4.1　拍照、录音、ZIP 打包

野外调查光记数字不够，得能拍照存证、录音备注。这版加了：

拍照按钮：调起后置摄像头，拍完存为附件。
录音按钮：用 MediaRecorder 录音，优先选 AAC/Opus 高压缩编码，点一下开始，再点停止，文件用时间戳命名（rec_20260718063012.webm）。
下载：有附件时用 JSZip 打成 zip（CSV + media 文件夹，附件名带序号前缀关联），没附件就纯 CSV。
所有文件名统一用 YYYYMMDDHHmmss 格式，精确到秒。

这下从"记录"升级到"多媒体记录"了。

v1.4.1 拍照录音ZIP下载

v1.4.3　离线缓存，开始/暂停

最后一个关键问题：野外经常没信号。一旦断网，浏览器刷新就加载不出页面，之前采集的数据也无法继续使用。这版加了 Service Worker：

第一次访问时把页面本身、JSZip CDN 缓存到本地。
之后断网也能正常打开和使用，刷新不会白屏。
用 stale-while-revalidate 策略，有网时悄悄更新，没网时用缓存。

按钮文案最后又改了一次：去掉"继续"，只留两个状态——开始和暂停，简洁明确。

详情区从"原生数据"改名"详细信息"，配一个可旋转的小三角按钮，点击展开/收起，不再写"点击展开"这种说明文字。中文状态下纯中文，英文状态下纯英文，不再混排。

v1.4.3 最终版离线缓存

一路改下来的几点体会

1. 指针和表盘谁该动，是个设计问题不是技术问题。 最早让指针动、表盘不动，技术上都对，但用起来不顺手——贴在固定平面上转手机时指针会跟着转，违反"产状不变"的直觉。反过来指针固定、表盘转动，立刻就顺手了。这种"谁动谁不动"的选择，纯几何算不出来，得靠实际拿着手机在斜面上转两下才知道。

2. 减按钮比加按钮难。 开始/冻结/继续三个按钮合成一个，要处理"没启动点开始、启动后点切换冻结"两种状态，逻辑变复杂了，但界面少了两行。值得。

3. 原生数据该藏起来。 Yaw/Pitch/Roll/四元数/加速度这些是给调试和复算用的，普通用户根本不看。默认折叠、给个三角按钮，是比"点击展开"这种文字说明更克制的做法。

4. 野外工具必须能离线。 这一点一开始没想，等真拿到没信号的地方才发现刷新就白屏。Service Worker 加上之后才算是能放心带出门的东西。

5. 命名要为文件系统着想。 时间戳用 YYYYMMDDHHmmss 而不是 ISO 的 2026-07-18T06:30:12，是因为前者直接排序、不会因为冒号在某些系统报错、文件名里也好看。

整个过程没碰过产状的数学计算，改的全是"用起来顺不顺手""断网了能不能用""能不能把照片和录音一起带走"这些工程和界面问题。

对于具体的需求来说，算得对只是起步，用得顺才是工具。

预览时标签不可点

Name cleared

微信扫一扫赞赏作者

Like the AuthorOther Amount

赞赏后展示我的头像

作品

暂无作品

Like the Author

Other Amount

最低赞赏 ¥0

Back

Other Amount

赞赏金额

最低赞赏 ¥0

虚拟化，操作系统，以及一些小工具 · 目录

虚拟化，操作系统，以及一些小工具

上一篇并非故意-为什么我更多用命令行工具而不是GUI

搜索「」网络结果

调整当前正文文字大小

100%

初步说一说大学里的教风和学风

2026-07-19T00:00:00+08:00

最近高校都在抓师德师风、教风学风。师德师风是立身之本，这没得说，干这行就得守这行的规矩，容不得一点瑕疵。我想说的是教风和学风这头，在高校读书加工作，呆了有二十来年了，有点自己的想法。

老先生讲的那些古

我上学那会儿，老师们爱讲古，讲他们当初上学的时候如何如何。说那时候省属、部属高校拨款差距没那么大，211、985之前，各地高校差距也不像后来这么大。后来才慢慢拉开了。

老先生讲古，我们当时挺反感——你赶紧讲课的内容啊，净讲这些没用的。现在想想，或许他们讲的其实是想让你知道，这东西是变化的，不是从来如此。

还有一类老师，我上本科那会儿碰到的，他科研做得好，文章发得多，掌管着实验室，挺有影响力，可上课就抱本书在那念。字面意义的照着念，然后普通话还很堪忧，用我一位同学的评价是「嘴里含着棉裤」，让人挺无语。

从胶片到电子幻灯片

后来开始电子化，要求用PPT、用幻灯片，好像这东西就高大上了。最早那幻灯片可不是现在这种电子文件，是真胶片，顶上有画有写，做得挺细致，真正投影的那种。那玩意儿成本不低，灯泡还烫，我有一回凑近了瞅想偷偷摆弄一下，差点儿烫着，好奇心驱使，挺危险的。

那东西有个毛病，做好了想改想换很难。有了电子版的，老师们都说方便了，有代码有数据，改一改、有错也好改。

可到了二零一几年，风气就不对了。有的老师直接照着幻灯片念。还有的出版社主动凑上来，说我这教材配幻灯片、配教学大纲，有的老师就爱选这种。也不一定是他自己懒，有可能就是新入职的，不知道怎么弄，拿来就用。

结果就是有的课一门下来，完全照着教材的幻灯片念，一本书的目录就是一门课的目录。

大学这个"大"字

大学不像初高中，拿一本标准教材、按标准答案讲就行。

大学这个"大"字，我觉得就是说，即便是通识课、导论课，也不应该、没必要只用一本教材，完全顺着教材目录往下讲。

只讲一本书，还能配称为"大"吗？那不成了教材导读了么？

一门课总是要与时俱进有所更新的，而教材出来的时间总是很有滞后性，哪怕最新版的，大概也得是一年前甚至两年前写的了。

所以专业课，我是很鼓励老师们都尽量自编讲义，一定要尊重学情，实事求是，而不能是说为了方便省事而直接照着教材生搬硬套，削足适履。

然而，更可怕的还在后边。有的人连幻灯片都懒得念。

念歪了的翻转课堂

翻转课堂这东西本意是好的，想提高学生的参与度，让孩子们自主探索，这是好事。

可有的地方念歪了，变成让学生做PPT，让学生上前面讲。人家交着学费，一年便宜的几千，贵的上万，家里还供着生活费，来了之后自己个儿做幻灯片、自己个儿讲。

早些年没AI的时候，孩子们还得自己找点资料做一做，多少能锻炼点。后来有了AI，催生出代做幻灯片的生意，AI生成也好，网上随便买一份也好，到那儿一糊弄就对付过去了。

授课老师美其名曰翻转课堂。可坐底下的学生能收获啥？今年上半年不就闹出过舆情，学生说我们花着学费来这儿，不是为了自己做个东西上前面念，这有啥意思？

这事挺让人遗憾，也挺让人惶恐。

精致或者不太精致的利己

教风出问题，学风也跟着出问题。

一类孩子是找分儿。考了七十多分，跑来找老师，帮我调个八十多吧，我要出国，绩点得好看。

我上学那会儿就有这样的，挺精致。更有甚者，给同学出那种不太体面的主意，让拿着东西去找老师请吃送礼。

这就已经碰到师德师风的红线了。

有的地方可能是当地习俗带进来了，讲究鱼头朝向谁，讲究送礼。社会风气对孩子们也是一种侵害，有时候家长自己也受影响，让孩子给老师送东西。我特别反感这种事。

不要作弊，大不了补考重修

还有一类孩子是作弊。他赌别人抓不着，抓着了就耍可怜、耍无辜，"我也是第一次"怎么怎么着。

可人呐，怎么可能总是第一次就被抓呢？其实之前有可能也弄过吧？而且一旦被人抓着一回，后边儿人家就不太信你了。

考试这玩意儿哪怕过不了，无非是补考。我当年有一回骑自行车，后边三轮把我怼了，三轮跑了。那会儿北京学校里也没那么完善的监控，我跟辅导员一说，脚还疼，脑袋也晕，好在一查，骨头没断，韧带关节损伤，问题不大，但疼啊，走不了路，没法考试。那一学期好几门课没考，全挂了。后来补考，补考过不了的重修，总归不是什么太难的事儿。

我现在不也照样毕业，本科之后读研、读博，一路过来了。

补考重修这都怕，那还混啥了？

可现在的孩子把挂科看得特别重，四处打听，我能不能挂科什么的，这事就变味儿了。

歪风不怪小树林

作弊之外还有一类，跟教风学风都有关。

有的课老师给原题让学生针对地来背诵，那样就成了单纯比拼记忆力了。

比如某个语种的阅读题，一共就这几个阅读材料，答案长这样。

孩子就把答案当数字硬背——334，323，对应CCD、CBC。

答案的数字背是背下来了，课程内容学会了吗？恐怕够呛。

这就成了为考试而优化，跟我之前那篇文章说的一样，「事情本身不重要」是怎么炼成的？就是盲目地针对指挥棒进行优化，跟给牛奶加三聚氰胺、给辣椒加苏丹红，差不太多。

这种风气当然不能只怪孩子，也不能只怪某一个环节。

一个系统性的风险，得从大一一来就打好预防针，让孩子们别走入歧途，别走弯路，别走上错路。

预览时标签不可点

Name cleared

微信扫一扫赞赏作者

Like the AuthorOther Amount

赞赏后展示我的头像

作品

暂无作品

Like the Author

Other Amount

最低赞赏 ¥0

Back

Other Amount

赞赏金额

最低赞赏 ¥0

基础知识 · 目录

基础知识

上一篇用 opencode 帮学习：上课没听懂的东西，让它帮你查清楚画明白下一篇OpenCode进阶-安装技能再改进：从PDF读取内容来填表和文档

搜索「」网络结果

调整当前正文文字大小

100%

用 opencode 搞学习：上课没听懂的东西，让它帮你查清楚画明白

2026-07-18T06:45:00+08:00

之前说了 opencode 能帮你搜教程、下视频。

不只是写代码：用opencode和免费模型帮你搜教程、下视频

有同学问：那上课的事儿能管吗？我上课没听懂，回去想补，它能帮上忙吗？

能。今天就拿一个真实的例子演示一遍。

假如你在课上听老师提了一嘴，说海盗数量和全球变暖有相关性，还说"相关性不等于因果性"。

但当时没注意听，下课回想起来一头雾水——海盗跟气候变暖怎么就扯上关系了？相关性不等于因果性又是啥意思？

换以前，我上学那会，要是查起来得自己搜索半天，翻好几篇文章，对着零散的资料拼凑，还得自己找数据画图。

这次咱们直接开 opencode，一句话甩过去。

先把事儿说清楚

我是这么下命令的：

说出疑惑

"上课听到老师说海盗和气候变暖的相关性以及什么相关性不等于因果性之类的，我当时没注意听，想办法搜集好这个数据，用python进行可视化，并且详细写一篇文章来给我解释清楚。"

就这么一句。你看这里头有几个关键信息：

发生了什么：上课老师讲了海盗和气候变暖的相关性，还有"相关性不等于因果性"。这交代了背景，让它知道我要补的是什么知识点。
我没听懂：直接说我当时没注意听。不用装，不用绕弯子，它不会嫌你笨，你说了它就知道得从基础讲起，不能默认你已经懂了。
要什么：搜集数据、Python 可视化、写文章解释清楚。三条明确的需求，不是泛泛的"帮我了解一下"。
要解释清楚：不是给我一堆链接让我自己看，是要它讲明白。

这四条缺一条都差点意思。你要是只说"帮我查一下海盗和全球变暖的事儿"，它给你一段百度百科你看了还是迷糊。你要是只说"解释一下相关性不等于因果性"，它给你背个统计学定义你更迷糊。把"搜集数据、画图、写文章"一起说清楚，它就知道你要的不是一段话，是一套能看懂的东西。

跟上一篇说的一样：把事儿说清，不需要文采，需要信息量给够。

它开始干活了

命令给出去，它先派了个子智能体去搜数据。

这个"子智能体"你可以理解成它分了个身出去专门干一件事——搜海盗和全球变暖相关性的原始资料。关键词换了好几轮，最后定位到了源头：2005年俄勒冈州立大学一个叫 Bobby Henderson 的物理学毕业生，给堪萨斯州教育委员会写的一封公开信。

这封信本身就是个讽刺作品。当时堪萨斯教育委员会要在生物课上教"智能设计论"（神创论的马甲），Henderson 觉得离谱，就写了封信说：你们要是这逻辑能成立，那我也可以说全球变暖是海盗减少造成的。他还附了张图，海盗越少温度越高，相关系数高得吓人。

这个故事的来龙去脉，我自己百度未必能这么快串起来。子智能体几轮搜索就把原始信件、数据来源、后人整理的数据集、相关讨论全给捞回来了：

初步的结果

数据有了，开始画图

数据是 1800 到 2020 年的，海盗数量从大约 35000 人锐减到几十人，全球温度异常值从 -0.4°C 升到 1.1°C。它直接写了个 Python 脚本：

代码样本

脚本一气呵成画了五张图：双 Y 轴时间序列，海盗数量一条线往下掉、温度一条线往上爬，几乎是完美的镜像；散点图加回归线，皮尔逊相关系数 r ≈ -0.96，"强负相关"；混淆变量示意图，点破工业化进程同时导致海盗减少和全球变暖；冰淇淋销量和溺水人数的对比图，类比"天气热"才是共同原因；还有更多荒谬的虚假相关案例，比如 Nicolas Cage 每年演的电影数量和美国泳池溺亡人数高度相关。

然后它写了篇文章

图生成完，它顺手写了篇完整的文章：

给出的结果

文章从 Henderson 2005年的公开信讲起，把数据摆出来，解释为什么 r ≈ -0.96 不代表海盗导致了气候变暖，点出"工业化"这个混淆变量，又用冰淇淋-溺水的类比讲清楚混淆变量的概念，最后给了五条区分相关和因果的实用判断标准：时间先后、排除混淆变量、机制合理性、实验验证、剂量效应。

整个过程，我就说了开头那一句话。搜索资料、写脚本、生成图片、撰写文章，全是它自己跑的。

这跟问网页版模型有什么区别

有同学可能说：这种知识点我直接问豆包、Kimi 不也行吗？

行，但效果差不少。网页版模型能给你讲"相关性不等于因果性"的概念，也能举海盗的例子，但它是纯文本的——给你一段话，你自己脑补。你要看图，它可能就给你画个 ASCII 的示意图，或者给你段代码让你自己跑。

opencode 不一样，它在你机器上有终端、有文件系统、能跑 Python、能装 matplotlib。你说"可视化"，它真的给你生成 PNG 图片存到本地，你打开就能看。你说"写文章"，它真的给你生成一个 Markdown 文件，直接就是一篇成型的东西。

这就是区别：网页版是"讲解"，opencode 是"交付"。讲解是你听完还得自己消化，交付是东西直接摆到你面前，你能反复看、能改、能发出去。

而且更关键的是，它给你的东西是可以验证的。数据来源它告诉你了，脚本你可以自己跑一遍，图你可以自己改参数重新画。这不是它说啥你就信啥，是它给了你一套可以复查的材料。这一点对学习尤其重要——你不能光看结论，得能追溯过程。

中间还能追问

前面的任务完成之后你还能接着问。比如我不明白"皮尔逊相关系数"是啥，我就直接问它："那个 r = -0.96 是怎么算出来的？"

它会接着上文给你讲：皮尔逊相关系数是衡量两个变量线性相关程度的指标，从 -1 到 1，-1 是完美负相关，1 是完美正相关，0 是无关。-0.96 说明海盗数量和温度几乎是完美的负向线性关系。然后它可能还会提醒你：但就算 r = -1，也不代表因果关系。

你不用每次从头解释背景，它记得你刚才在干什么。这一点比每次开新对话的网页版强不少。你追着问下去，一个点一个点搞明白，比一次性灌一堆概念强。

为什么这个用法对学习特别有用

大学的学习跟高中不一样。高中老师讲完你做题，做题不会再问老师。大学很多时候是你上课听了，下课发现没听懂，但又不知道从哪儿问起——你可能连"哪儿没懂"都说不太清。

opencode 这种用法恰恰能解决这个尴尬：

你说个大概就行。"老师讲了海盗和气候变暖，我没听懂"——它就能开始帮你补。你不用精确描述你哪儿没懂，它先给你铺一遍，你看完自然知道自己哪儿还不明白，再追着问。
它给你可视化的东西。人看图比看字快，一条曲线比一段描述直观一百倍。它能画图，这是纯文本模型比不了的。
它给你的材料能反复看。文章存下来了，图存下来了，你过两天忘了再翻出来看。不像对话窗口关了就没了。
它能层层深入。先给你现象，再给你原理，再给你类比，再给你更多案例。你懂了就停，没懂就接着问，节奏你自己控。

大学里没人追着你教了，你得学会自己补。但"自己补"不等于"闷头查"，用好工具能省你大量时间。

说到底还是那个道理

跟上一篇说的一样：你得会把事儿说清楚。

"上课没听懂海盗和气候变暖的相关性，帮我搜集数据、可视化、写文章解释清楚。"——这一句话里，背景、需求、交付形式都有了。

你要是说"帮我讲讲统计学"，它给你一段统计学综述你看了更迷糊。你要是说"帮我画个图"，它不知道画啥。把背景交代清、把需求说具体、把交付形式说明确，它基本能给你办明白。

这能力不光是跟模型打交道用得上。你以后写邮件、提需求、跟人协作，都是同一套逻辑——把事儿说清，别让人猜。

学会用工具，先从习惯进行表达和提问开始。

预览时标签不可点

Name cleared

微信扫一扫赞赏作者

Like the AuthorOther Amount

赞赏后展示我的头像

作品

暂无作品

Like the Author

Other Amount

最低赞赏 ¥0

Back

Other Amount

赞赏金额

最低赞赏 ¥0

基础知识 · 目录

基础知识

上一篇不只是写代码：用opencode和免费模型帮你搜教程、下视频下一篇初步说一说大学里的教风和学风

搜索「」网络结果

调整当前正文文字大小

100%

opencode 不只是写代码：用免费模型帮你搜教程、下视频

2026-07-18T00:00:00+08:00

我作为高校教师建议大一开学要有电脑，还要安装OpenCode使用智能体，而且之前一篇还说了 opencode 的四种用法与为什么我推荐命令行。

有同学看完问：那玩意儿不是给程序员写代码用的吗？

我又不是学计算机的，跟我有什么关系？

关系大了。

opencode 的主要场景不一定是编程。除了写代码和跟操作系统打交道之外，它也能帮你做很多日常任务。

可以把它看作一个多功能的智能体协同配合过程——你说事，它去搜、去找、去下、去验证，最后把东西摆到你面前。

还有的同学说：我也安装了，可是不知道怎么用啊？

今天就拿一个真实的例子演示一遍：去 B 站找一个英语口语教程，下载第一集到桌面。

事情得说清楚

先看我是怎么下命令的：

给出命令

"帮我去B站找到有史以来最简明易懂最被认可的英语口语教程，下载其中第一集到本设备的桌面上。"

就这么一句。但你注意这里头有几个关键信息：

去哪儿找：B 站。不是抖音，不是快手，就是 B 站。你得把备选区间设定好，否则它找的东西质量不一定符合你的预期。
要什么样的：最简明易懂、最被认可。这俩词定调了筛选标准——不要那种一百集讲语法的，也不要那种浮夸卖课的，要的是口碑好、上手快的。
要第几集：第一集。不是全部，不是"看着办"，全部下载可能磁盘就存不下了。
下到哪儿：本设备的桌面。不是下载目录，不是某个项目文件夹，就是桌面，一眼能看见，当然这不是个好的习惯，最好是有一个对应的单独目录，不过为了演示给新手看就先这样了。

这四条缺一条都麻烦。你如果只说"帮我下个英语视频"，它可能给你下个非常呆萌的动画儿歌，也可能下个六级听力真题，你看了想骂它，可是实际上问题不在它笨，在于你没说清。

把它当做一个语言转换过程：从人类的自然语言，转换成一个可执行的搜索操作，以及你希望最后给你呈现的结果。确定性和清晰很重要。这东西最需要的是你进行语言表达的效率——你得能说得清楚，把事儿才能办了。

你说不清楚的时候怎么办？那就尽量多说。不用考虑遣词造句，不用有文采，你要做的是用最大的信息量把你要做的事儿描述清楚。它的理解能力是不错的，你多给它几条线索，它自己能往一块儿拼。怕的是你给的信息太少，它只能猜，猜歪了你又嫌它不行。

它开始干活了

命令给出去之后，它自己开始搜：

模型搜索

它调用了网络搜索工具，关键词换了好几轮——"最简单易懂英语口语教程"、"B站最经典英语口语教学"、"百万播放"——这是它在反复校准搜索策略，一轮不够再换一轮。你看那个搜索结果列表，B 站上这类教程是真不少，有"全170集英语经典900句"，有"挑战100天英语开口计划"，还有 Coach Shane 的 Daily Easy English Expression。

几轮搜下来，它选中了 Coach Shane 这一套。理由它自己说了：每集 3 到 5 分钟，只讲一个地道表达，讲解里不光讲意思还讲连读弱读这些发音细节，零基础一学就会。主频道订阅百万，B 站上多人搬运，累计播放上千万，一些营销号曾经也都推荐过，基本上在英语学习圈子里认可度挺高。

这个筛选过程你自己做可能要翻半天评论区，对比好几个视频，而模型帮你来几轮搜索就给定位了。这就是工具调用的价值——它不是瞎猜，是真的去查了，查完还给你说了为什么选这个。

中间不是一帆风顺

找到之后要下载，它先用 yt-dlp 试：

尝试下载

报错了。HTTP Error 412: Precondition Failed。B 站的反爬机制挡住了。

你看它的反应——它没卡住，没跟你说"对不起我下不了您自己来吧"。它先加 User-Agent、加 Referer 头，再试，还是 412。然后它意识到可能是 yt-dlp 版本太旧，WBI 签名机制搞不定，于是自己去 pip install -U yt-dlp 把版本升到最新，再试一次——这次过了。

这个"自己装工具、自己修问题"的能力，是 opencode 和普通网页对话框最大的区别。你要是直接跟千问啊豆包啊等等的网页版说"帮我下个视频"，它十有八九告诉你"抱歉我无法访问外部网络下载文件"，然后这事就卡死了。opencode 不一样，它手里有终端，能装包，能改参数，能反复试。它搞不定的时候会换路径和工具，不是一遇到墙就回头。

这就是智能体和聊天机器人的区别。聊天机器人只能跟你说话，智能体能动手。

搞定了

最后视频下到桌面上了：

完成后给结果

/Users/fred/Desktop/Coach_Shane_001.mp4，8.6MB，第1集"How are you doing?"，3分21秒。

它下完还顺带验证了一下文件确实存在、大小正常，然后告诉你选的是哪一套、为什么选、第一集讲的什么。不是甩给你一个文件就完事，是把前因后果都交代了。

整个过程你做了什么？你就说了开头那一句话。剩下搜索、筛选、下载、装工具、修报错、验证，全是它自己跑的。你省下来的时间够你看两集教程了。

后续还能继续聊

下完之后我又问了一句"这个系列不错啊，一共多少集"：

继续交互

它没忘前文，直接去查那个合集的 playlist 信息，告诉你一个合集 50 集，整套一共 20 个合集，算下来 1000 集，每天学 2 集差不多一年刷完。

这就是会话的连续性——你不用每次都从头解释背景，它记得你刚才在干什么。这点也比网页对话框强，网页版你刷新一下上下文就丢了，opencode 的会话是持续的，你能像跟一个人聊天一样，一件事追着问下去。

为什么不直接用网页版模型

有同学可能说：那我直接打开千问、豆包、Kimi 的网页版问不就行了？干嘛非得开终端用 opencode？

能问，但很多事干不了。网页版模型主要是文本对话，上传文件也有限制，它不具备多工具调用能力——不能跑命令、不能装包、不能下载之后再验证、不能操作你本地的文件系统。你说"帮我下个视频"，它只能告诉你怎么下，不能替你下。你说"帮我整理桌面上这十张图片按日期分类"，它只能教你用 Python 怎么写脚本，不能直接动手帮你分。

opencode 不一样，它在你机器上有终端、有文件系统、有网络访问、能装包。你说事儿，它动手。这就是 Agent 和聊天助手的本质区别。

而且最关键的一点——这套东西不花钱。opencode 自带的那个免费模型，绝大部分日常场景都能搞定。下个视频、搜个文档、整理个文件、查个资料，都不用你掏一分钱。你拿它当个免费的辅助使唤就行，能帮你省下大量亲自操作的时间。不一定每次都百分百满意，但总比你自己亲自上手要强得多。

为什么推荐用命令行终端

还是那句话，我推荐大家用命令行终端版本的 opencode，这样可以尽量减少其他东西的干扰。

终端里就一个输入框、一段对话、一个结果。你不用关心界面长什么样、按钮在哪儿、广告弹没弹。你只管把事儿说清楚，然后看它干、验证结果，别的都不用管。

这个体验跟网页对话框最大的不同是：网页版是"对话"，opencode 是"协作"。对话是你问我答，协作是我说事儿你去办。后者更接近你真正想要的东西——你不是想跟 AI 聊天，你是想让 AI 帮你把活干了。

说给大学新生的话

希望大学新生入学之后，先把这件事练好。

练什么？练把事儿说清楚的能力。

大学跟高中不一样，高中你问老师问同学天经地义，大学很多人不好意思开口。有的同学觉得"我不会，问人家多丢人"，有的同学怕打扰别人，有的同学就是社恐。这时候你偷偷问模型嘛，没人知道，不丢人。

但问模型这件事本身有门槛——你得会问。

你说"豆包帮我把作业做了"，它做不出来，你也不知道它怎么做的，它也可能糊弄你。

你说"帮我在 B 站找一个英语口语教程"，它找的可能是你根本不想看的那种。问题不在它，在你的问题描述可能太模糊。

把事儿说清，不需要你有文采，不需要你遣词造句，需要的是你把信息量给够：去哪儿找、找什么样的、要哪一部分、放哪儿。这四条说清了，它基本能给你办明白。这四条说糊了，它也只能糊弄回来。

这其实就是在练沟通能力。你跟模型沟通熟了，跟人沟通也不会差——因为你习惯了把需求拆清楚、把背景交代明白、把预期说明确。这个能力不管你以后干什么都用得上。

等到你能熟练地用 opencode 搜视频、下文档、整理资料、查资料了，你就再也不用问老师"那个视频在哪儿找的"、"那个软件从哪下载"这种问题了——这种问题问出来才真的呆呆的。安装软件的事儿也可以让它来，下回咱们再说。

今天这个搜教程加下载的过程，你会看到它中间调用了好几个工具：网络搜索、网页抓取、命令行下载、包管理器升级。如果它找不到某个工具，它自个儿就会装，这事非常方便，你不用操心这些细节。

但如果你想知道具体是怎么实现的，你可以直接问它："你刚才下载那个视频用的什么命令？为什么第一次失败了？"

它会把它用的命令、失败的原因、怎么修的，一条一条告诉你。让你干活的同时，还能把背后的门道看明白，这可比自己闷头查文档省事多了。

大学生活就快开始了，大家赶紧趁早开练。

预览时标签不可点

Name cleared

微信扫一扫赞赏作者

Like the AuthorOther Amount

赞赏后展示我的头像

作品

暂无作品

Like the Author

Other Amount

最低赞赏 ¥0

Back

Other Amount

赞赏金额

最低赞赏 ¥0

基础知识 · 目录

基础知识

上一篇一维查找方法综述：从三分、黄金分割到 Fibonacci 与 Brent下一篇用 opencode 帮学习：上课没听懂的东西，让它帮你查清楚画明白

搜索「」网络结果

调整当前正文文字大小

100%

海盗消失了，地球就变暖了？聊聊"相关性不等于因果性"

2026-07-17T20:00:00+08:00

2005年，一个叫Bobby Henderson的俄勒冈州立大学物理学毕业生，给美国堪萨斯州教育委员会写了一封公开信。当时教育委员会正在讨论要不要在生物课上教"智能设计论"（也就是神创论的马甲），Henderson觉得这事儿离谱，就用了一种极其讽刺的方式反驳：

全球变暖、地震、飓风和其他自然灾害，都是自1800年以来海盗数量急剧减少的直接后果。

他附了一张图，横轴是海盗数量，纵轴是全球温度。海盗越少，温度越高。相关系数高得吓人。

这张图后来成了互联网上解释"相关性不等于因果性"最经典的案例之一。

先把数据摆出来

Henderson用的是近似数据，我整理了一份后人还原的版本：

从1800年到2020年，海盗数量从大约35000人锐减到几十人，全球温度异常值从-0.4°C上升到1.1°C。两条曲线几乎是完美的镜像关系。

画成散点图更直观：

皮尔逊相关系数 r ≈ -0.96。在统计学里，这叫"强负相关"——海盗数量每减少一点，温度就升高一点。如果只看这个数字，你可能会觉得海盗确实是地球的空调。

为什么说这纯粹是扯淡

相关性高不代表因果关系，这是统计学的第一课，但很多人一辈子都没真正理解。

问题出在哪？Henderson犯了一个经典的错误：他忽略了一个混淆变量。

真实的情况是这样的：

工业化进程同时导致了两件事： 1. 海盗因为各国海军力量增强而减少 2. 化石燃料大量使用导致温室效应加剧、全球变暖

海盗减少和全球变暖都是工业化的结果，它们之间没有直接的因果关系。就像你不能因为"冰淇淋销量和溺水人数高度正相关"就得出"吃冰淇淋会淹死人"的结论。

冰淇淋和溺水：一个更直观的例子

夏天冰淇淋卖得多，溺水的人也多。相关系数也很高。但原因很简单：天气热。天热→吃冰淇淋多，天热→游泳的人多→溺水的多。冰淇淋和溺水之间没有因果链，"炎热的天气"才是共同的原因。

在统计学里，这个隐藏的共同原因叫混淆变量（Confounding Variable）。如果你不控制混淆变量，直接拿两个变量算相关系数，得到的就是"虚假相关"（Spurious Correlation）。

这世上还有多少荒谬的"相关性"

互联网上有一整个网站专门收集这类东西（tylervigen.com/spurious-correlations），随便举几个：

Nicolas Cage 每年演的电影数量，和当年美国泳池溺亡人数，相关系数 r = 0.66
美国每年葬礼的数量，和冰淇淋销量，高度正相关
美国每年离婚率，和人均黄油消费量，几乎同步变化

这些荒谬的例子都在说明同一件事：两个变量在时间上同步变化，不代表一个导致了另一个。

怎么区分相关和因果

几个实用的判断标准：

1. 时间先后 原因必须发生在结果之前。如果A导致B，A的时间线要早于B。但光有时间先后还不够——公鸡打鸣后太阳升起，不代表公鸡叫醒了太阳。

2. 排除混淆变量 把其他可能的解释都考虑一遍。如果有一个变量C同时影响A和B，那A和B之间的"相关"就可能是虚假的。海盗和温度之间的C就是工业化。

3. 机制合理性 因果关系需要一个说得通的物理/生物/社会机制。冰淇淋→溺水没有生理机制，海盗→温度没有物理机制，但CO₂排放→温室效应有明确的物理机制（CO₂吸收红外辐射）。

4. 实验验证 最可靠的方法是做对照实验。随机把人分成两组，一组吃冰淇淋一组不吃，然后看溺水量有没有区别。当然这个实验没法做（也不道德），但科学上我们正是通过控制实验来建立因果关系的。

5. 剂量效应 如果因果关系成立，增加"原因"的剂量应该增强"结果"。CO₂排放越多，升温越明显——这符合剂量效应。但海盗减少的"剂量"和温度升高之间没有这种机制性的联系。

为什么这个话题重要

Henderson写那封信的目的不是真的要说服任何人相信海盗理论。他是在讽刺：如果你可以用同样的逻辑支持"海盗导致全球变暖"，那"智能设计论"也可以用类似的方式混进科学课堂。

这个案例之所以流传了20年还在被反复引用，是因为它实在太完美了：

数据确实存在（温度确实在升，海盗确实在减少）
相关性确实很高（r ≈ -0.96）
因果关系确实荒谬（海盗不是地球的空调）

它用一种极端的方式提醒我们：数据可以说谎，统计数字也可以。

当你看到"XX和YY高度相关"的新闻标题时，多问一句：有没有混淆变量？有没有反向因果？时间顺序对不对？机制说得通吗？

别被一张好看的散点图骗了。

参考

Bobby Henderson, Open Letter to the Kansas School Board, 2005 (venganza.org)
Tyler Vigen, Spurious Correlations (tylervigen.com)
Judea Pearl, The Book of Why, 2018

无人机平飞有利速度与所需速度：最大航程和最大航时分别用什么速度

2026-07-16T10:00:00+08:00

两个容易混淆的概念

无人机在平飞时,有两个非常重要的速度概念经常被混淆:

平飞所需速度(Required Speed):维持匀速平飞所需的最小速度。本质上就是满足升力等于重力的那个速度,对应的是能否飞起来的问题。
平飞有利速度(Best Speed):在所需速度之上的某个特定速度值,能让某种性能指标(航程或航时)达到最大。对应的是怎么飞最划算的问题。

更准确地说,有利速度不是一个速度,而是两个:

速度	对应性能	物理本质	关系
最大航程速度 $V_{R_{max}}$	飞得最远	对应 $(L/D)_{max}$ (总阻力最小点)	$V_{R_{max}} > V_{E_{max}}$
最大航时速度 $V_{E_{max}}$	飞得最久	对应最小需用功率点	$V_{E_{max}}$ 略高于失速速度

这两个速度都比失速速度高,但最大航时速度非常接近失速边界。飞最久要飞慢,飞最远要飞快一些。

理论基础

平飞条件

无人机匀速平飞时,升力必须等于重力:

\[L = W = \frac{1}{2} \rho V^2 S C_L\]

由此解出平飞所需速度:

\[V = \sqrt{\frac{2W}{\rho S C_L}}\]

从这个公式看,只要迎角不超过临界值($C_L \leq C_{L_{max}}$),总有一个速度满足平飞条件。但不同的速度对应不同的阻力,也就对应不同的燃油消耗率。

为什么两个最优速度不同

总阻力由两部分组成:

\[D = \underbrace{\frac{1}{2}\rho V^2 S C_{D0}}_{\text{寄生阻力(随V²增大)}} + \underbrace{\frac{1}{2}\rho V^2 S \cdot k C_L^2}_{\text{诱导阻力(随V减小而增大)}}\]

用平飞条件消去 $C_L$,得到阻力随速度的变化:

\[D = \frac{1}{2}\rho V^2 S C_{D0} + \frac{2k W^2}{\rho V^2 S}\]

低速时(大迎角):诱导阻力占主导,阻力随速度减小而急剧增大(因为需要更大的 $C_L$)
高速时(小迎角):寄生阻力占主导,阻力随速度增大而急剧增大
中间某处:两种阻力相等,总阻力最小 —— 这就是 $(L/D)_{max}$ 点

而需用功率是阻力乘以速度:

\[P_{req} = D \cdot V = \frac{1}{2}\rho V^3 S C_{D0} + \frac{2k W^2}{\rho V S}\]

功率的极小值点比阻力的极小值点出现在更低的速度上(因为功率多乘了一个 $V$,使得高速端的惩罚更大)。

因此:

$(L/D)_{max}$ 出现在总阻力的极小值点 $\frac{dD}{dV}=0$
最小需用功率出现在功率的极小值点 $\frac{dP_{req}}{dV}=0$

这两个点不重合。数学推导可得(螺旋桨飞机):

\[\frac{V_{R_{max}}}{V_{E_{max}}} = 4^{1/4} \approx 1.414\]

实际无人机由于气动特性、螺旋桨效率变化等因素,比值通常在 1.2~1.5 之间。

航程和航时公式

螺旋桨飞机:

航程(Breguet 航程公式):

\[R = \frac{\eta_p}{sfc} \cdot \frac{C_L}{C_D} \cdot \ln\left(\frac{W_0}{W_1}\right)\]

航时(Endurance):

\[E = \frac{\eta_p}{sfc} \cdot \frac{C_L^{3/2}}{C_D} \cdot \sqrt{2\rho S} \cdot \left(\frac{1}{\sqrt{W_1}} - \frac{1}{\sqrt{W_0}}\right)\]

航程正比于 $C_L/C_D = L/D$ → 最大航程对应 $(L/D)_{max}$
航时正比于 $C_L^{3/2}/C_D$ → 最大航时对应 $(C_L^{3/2}/C_D)_{max}$,即最小需用功率点

Python 建模与可视化

下面以一架典型小型无人机为例(JL-6 型参数参考):

重量 $W = 20 \text{ kg} \times 9.81 = 196.2 \text{ N}$
机翼面积 $S = 0.65 \text{ m}^2$
零升阻力系数 $C_{D0} = 0.025$
诱导阻力因子 $k = 0.045$

核心计算代码:

import numpy as np

rho = 1.225  # 海平面空气密度
W, S, C_D0, k = 196.2, 0.65, 0.025, 0.045

def CL_from_V(V):
    """平飞升力系数"""
    return 2 * W / (rho * S * V**2)

def CD(val):
    """阻力系数"""
    return C_D0 + k * val**2

def total_drag(V):
    """总阻力"""
    c_l = CL_from_V(V)
    return 0.5 * rho * V**2 * S * CD(c_l)

def power_required(V):
    """需用功率 (propeller)"""
    return total_drag(V) * V

def L_over_D(V):
    """升阻比"""
    c_l = CL_from_V(V)
    return c_l / CD(c_l)

# 扫描速度范围
V_stall = np.sqrt(2*W / (rho*S*1.6))  # C_Lmax ≈ 1.6
V_range = np.linspace(V_stall, 60, 500)

# 找最优点
V_min_drag = V_range[np.argmin([total_drag(v) for v in V_range])]
V_min_power = V_range[np.argmin([power_required(v) for v in V_range])]

print(f"失速速度: {V_stall:.1f} m/s")
print(f"最大航程速度 (V_min_drag): {V_min_drag:.1f} m/s")
print(f"最大航时速度 (V_min_power): {V_min_power:.1f} m/s")

输出结果:

失速速度: 17.6 m/s ≈ 63 km/h
最大航程速度: 25.7 m/s ≈ 93 km/h  (对应 L/D_max)
最大航时速度: 19.5 m/s ≈ 70 km/h  (对应最小需用功率)
比值 V_range/V_endurance = 1.32

综合分析图

下图的四个面板展示了完整的平飞性能分析:

左上:总阻力分解为寄生阻力和诱导阻力,两条虚线交叉处为最小阻力点。

右上:需用功率曲线。注意最小功率点(紫色)在最小阻力点(蓝色)左侧。

左下:升阻比 L/D 曲线。峰值对应最大航程。

右下:相对航程(蓝)和相对航时(绿)随速度变化。100% 分别对应各自的最大值,两个最优速度不重合。

动态演示 GIF

下面的动画展示了在不同速度下阻力、升力、功率的变化,以及当前速度对应于航程最优还是航时最优:

速度从略高于失速逐渐增加到最大速度,可以直观看到: - 低速阶段诱导阻力主导(红色条很高) - 高速阶段寄生阻力主导(绿色条很高)
- 中间某处总阻力最小 → 最大航程速度 - 稍低速处需用功率最小 → 最大航时速度

小结

场景	使用速度	数值	原因
刚起飞/防止失速	$V > V_{stall}$	> 17.6 m/s	升力必须 ≥ 重力
最大航时(飞最久)	$V_{E_{max}}$	~19.5 m/s	对应最小需用功率
最大航程(飞最远)	$V_{R_{max}}$	~25.7 m/s	对应最大升阻比 $(L/D)_{max}$
快速到达/巡航	$V > V_{R_{max}}$	> 25.7 m/s	牺牲效率换速度

对于实际操作: - 需要在空中停留尽可能长的时间(监视、 loitering),飞最小时功率速度 - 需要尽可能飞得远(转场、覆盖更大区域),飞最小阻力速度 - 两个速度差了约 32%,不是同一个速度 - 在小无人机上,长期在低功率速度附近飞行要注意别失速(余量不大)

一维查找方法综述：从三分、黄金分割到 Fibonacci 与 Brent

2026-07-16T00:00:00+08:00

到了暑假了，给孩子们来点相对直观的。

怎么找一个单峰函数的极值

给定一个在区间上先降后升的单峰函数，怎么又快又稳地找到它的极小点？这是数值优化里最基础的一维问题，也是各种高维优化里"线搜索"（line search）步骤的内核。方法有一大把：三分查找、黄金分割、Fibonacci 查找、抛物线插值、Brent、二分/牛顿……

这篇文章把它们放在一起做个综述，全部用同一套基准诚实地量：同样的测试函数、同样的精度、数每种方法花了多少次函数求值，并检查是否都收敛到了正确答案。核心的一条主线是：一个方法用了函数的多少信息，决定了它能有多快，也决定了它的适用范围。

黄金分割"快"在哪：复用点

先从最经典的黄金分割查找（golden section search）说起。很多人以为它的精髓是那个神奇的比率，其实不是——**精髓是"复用点"**。

在区间放两个内点、，比较和，丢掉更差的一端。黄金比率满足自相似性质，使得收缩后的新区间里，旧的一个内点恰好落在新的黄金分割位置。下一轮只需算一个新点，另一个直接复用。

黄金分割每轮只需 1 次新求值

一句话：黄金分割每轮区间收缩到 0.618，但只花 1 次函数求值。 对比之下，三分查找每轮把区间缩到 2/3，看起来比 0.618 更狠，可它两个内点每轮都要重算，每轮花 2 次求值，摊下来反而更亏。这说明衡量快慢不能只看单轮收缩幅度，要看"每次求值能换来多少收缩"。

有限轮数下的最优：Fibonacci 查找

黄金分割的比率是恒定的。有没有可能让比率逐轮变化，既缩得更聪明、又保持复用？

有。用 Fibonacci 数列 来定分点。给定精度需要的轮数，每轮的保留比率取。因为 Fibonacci 有递推，这个结构恰好也能复用一个旧点，每轮只算一个新点——和黄金分割一样省，但比率是逐轮变化的：

Fibonacci 比率逐轮变化，极限是黄金比率

有意思的是：黄金分割查找其实就是 Fibonacci 查找在时的极限——比率不再变化、恒为。而对有限轮数，Fibonacci 是理论最优的：在"只能比较函数值大小"的框架下，给定固定的求值次数，Fibonacci 能把最终区间压到最小（Kiefer 1953 证明）。

import math
phi = (math.sqrt(5) - 1) / 2

def fibonacci_search(f, a, b, tol=1e-6):
    calls = 0
    def F(x):
        nonlocal calls; calls += 1; return f(x)
    fib = [1, 1]
    while fib[-1] < (b - a) / tol:
        fib.append(fib[-1] + fib[-2])
    n = len(fib) - 1
    c = a + fib[n-2]/fib[n]*(b-a)
    d = a + fib[n-1]/fib[n]*(b-a)
    fc, fd = F(c), F(d)
    for k in range(1, n-1):
        if fc < fd:
            b, d, fd = d, c, fc
            c = a + fib[n-k-2]/fib[n-k]*(b-a)   # 比率逐轮变
            fc = F(c)                            # 但只算 1 个新点
        else:
            a, c, fc = c, d, fd
            d = a + fib[n-k-1]/fib[n-k]*(b-a)
            fd = F(d)
    return (a + b) / 2, calls

上代码，诚实地量所有方法

同一套 8 个单峰测试函数（二次、四次、尖谷、非对称指数、平底等），统一收敛到，数每种方法的函数求值次数，并检查是否收敛正确：

方法	需要什么	每轮求值	合计求值	收敛正确
三分查找	只比大小	2	560	8/8 ✅
黄金分割 GS	只比大小	1	248	8/8 ✅
Fibonacci	只比大小	1	240	8/8 ✅
抛物线插值	用曲率	1	151	8/8 ✅
Brent	用曲率+兜底	1	136	8/8 ✅
二分（需导数）	需梯度	1	120*	6/6 ✅

（*二分需要导数，仅在 6 个可导函数上统计）

各方法总求值次数对比

几个结论一目了然：

三分查找最慢：它不复用，每轮 2 次求值，虽然区间每轮缩到 2/3，但摊下来最亏。
Fibonacci 略胜黄金分割（240 vs 248）：因为它在有限轮数下是最优的，黄金分割只是它的极限近似。
黄金分割是"够用且简单"的选择：不用预先算轮数，实现最短，性能只比最优差一点点。

真正的加速：利用更多信息

黄金分割和 Fibonacci 都只用了 $f(c)<f(d)$ 这一个比较（一个比特），太浪费。想更快，就得用函数值里更多的信息。

抛物线插值（successive parabolic interpolation）用最近三点拟合抛物线，取顶点作为下一个试点：

在光滑函数附近超线性收敛，二次函数上一步到位（表中"二次"只用 5 次）。但它对尖谷、平底会失灵（"平底四次"用了 54 次，比黄金分割还慢）。

Brent 方法是工程上的标准答案：能抛物线插值就插值，插值越界或不老实就退回黄金分割兜底。既拿到插值的快，又保住黄金分割的稳，8 个函数只用 136 次，全部收敛正确。这也是 scipy.optimize.minimize_scalar 默认用的方法。

如果能拿到导数，那就更快：极值点等价于导数的零点，直接对导数做二分（120 次），甚至用牛顿法，但代价是必须有梯度。

方法家族全景

把这些方法按"用了多少信息"排一下，脉络就清楚了：信息用得越多，收敛越快，但对函数的要求也越高。

一维查找方法家族关系

只比函数值大小（最通用，连不可导、有噪声都能用）：三分 → 黄金分割 → Fibonacci（最优）。
还用函数值的具体数值（曲率）：抛物线插值 → Brent（插值+兜底）。
还能用导数：二分（导数符号）→ 牛顿法（导数值），最快但要求最苛刻。

三种区间法同屏对比

最后放一个动画，让三分、黄金分割、Fibonacci 在同一个函数上同屏收缩。三分的区间每轮缩得多但费两次求值；黄金分割和 Fibonacci 缩得稳，且每轮只花一次。

三分、黄金分割、Fibonacci 收缩过程对比

简单总结

黄金分割查找的精髓是复用点：每轮收缩到 0.618，只花 1 次求值；三分不复用，所以更慢。
想在保持复用的同时让比率变得更聪明，正确做法是 Fibonacci 查找：比率逐轮变化（0.5→0.667→0.6→…→φ）却仍复用一点，且在有限轮数下理论最优。黄金分割正是它的极限。
真想更快，方向是用函数值里更多的信息：抛物线插值（用曲率）→ Brent（插值+黄金兜底，工程首选）；若有导数，二分/牛顿更快，但要求更高。
选型口诀：通用稳妥用 Brent，纯比较场景用黄金分割/Fibonacci，有梯度就上牛顿。

预览时标签不可点

Name cleared

微信扫一扫赞赏作者

Like the AuthorOther Amount

赞赏后展示我的头像

作品

暂无作品

Like the Author

Other Amount

最低赞赏 ¥0

Back

Other Amount

赞赏金额

最低赞赏 ¥0

基础知识 · 目录

基础知识

上一篇「事情本身不重要」是怎么炼成的下一篇不只是写代码：用opencode和免费模型帮你搜教程、下视频

搜索「」网络结果

调整当前正文文字大小

100%

事情本身不重要，是怎么炼成的

2026-07-14T00:00:00+08:00

有一些同学和朋友，看到一些事情，总是不理解为什么会出现。

其实有很多问题的背后，都有一个共同的原理：「事情本身不重要。」

要说明白这个原理，咱们得先假设一家饭馆。

这家饭馆本来挺简单。菜做得大家觉得好吃，价格也划算，还干净，街坊邻居就都去。这是做餐饮最朴素的路子，也是大多数饭馆本该有的样子。

后来味道变了。

怎么变的呢？他开始跟你讲情怀。讲用料是多么讲究的产地直采，讲这道菜背后花了多少心思，讲创办人是什么名校毕业、师从某某名厨、祖上几代做菜、甚至是什么非遗传承人。总之，你得为这些东西买单。客单价就提上去了。

还不够。他开始人为制造稀缺。每天限量，门口排长队，你排了一小时吃上的东西，好不好吃已经不重要了——重要的是你排到了，你发朋友圈了，这儿成了打卡地。菜品的口味、食材的新鲜度、甚至后厨的卫生，都没那么被人关心了。你消费的不是一顿饭，是一种时尚，是一个谈资。

这还是第一阶段。

接着往下走。他开始搞会员制，充卡预付费，只对会员开放。这么做如果能撑住，其实倒能筛出一帮忠实客群，降低获客成本。但撑不住就麻烦了。起初给你打九折，后来八折，再往后充卡赠百分之五十，差不多就是五折。你但凡有点常识就知道，这不是做福利，这是现金流快断了。

我朋友就遇到过一个真实例子。某烤串城，前两年扩张得很猛，直营店和加盟店并存，会员卡卖得满天飞。后来资金链出了问题，突然某天，直营店的卡在另一个同品牌的店里就不认了。你在A店充的钱，B店门口贴张纸说"本店独立经营，会员卡不通用"。你找谁说理去？

这不只是餐饮。

你想想理发店。你本来只想理个发，手艺好，干净，价格能接受，这需求不过分吧。但他不。他先给你安排个总监、首席，反正你没见过他们剪出来的头有什么区别，但价格翻了几倍。然后开始推销护发素、精华液、头皮护理，那些东西有没有批号、有没有正规手续，你也不好意思追着问。最后大招来了——卖卡，预付费储值。你觉得买了卡每次能便宜点，贪这点便宜，人家看的是你的本金。一旦跑了，维权成本高到让人放弃，几千块打了水漂，自认倒霉。

那教书呢？也一样。

有些高校的课堂上，那课讲得怎么样，学生是不是听得进去，身心是不是健康地成长，这些事儿已经不那么重要了。什么重要呢？拉项目，发文章，整帽子，评人才称号，拿基金，冲排名。这些东西能在互联网榜单上提高排位，能变成可量化的KPI。指挥棒指到哪儿，大家就冲到哪儿。指挥棒本身成了唯一被优化的对象，至于你是来教书的还是来跑指标业务的，无所谓。

标准化考试也是。它本来只是个衡量手段，一种检验学习效果的工具。但最后它变成了唯一的目的。学习不再是为了让自己成长为一个更全面的人，不再是为了发现感兴趣的领域然后深入探索，而是变成了——我要针对这个考试达到某个分数，领先多少人，拿到某个排名，然后去另一个地方参加另一场考试，再领先另一拨人。中考完了高考，高考完了考研，考研完了读博，读博之后申基金、写本子、评职称，这个阶梯永无止境。事情的本质，也就是你到底学到了什么、创造了什么价值，在这个体系里反而成了最不重要的事。

很多带着各种名头的人，搞出学术不端、图片误用、数据造假，甚至把学生的论文署上自己的名字，你也不必觉得奇怪。他本来就不在乎事情本身，他在乎的是怎么用这些手段在指挥棒体系下最大化自己的利益。他的目的，和这个体系标榜的目的，本来就不一致。

就连中小学老师也一样。他们要宣传防溺水，宣传防火用电安全，甚至宣传社保医保的好处。这些事你说重不重要？都特别重要。但当它们全落在老师头上，成了被考核的任务，那备课、钻研教学就成了只能用课外时间、业余时间来准备的事。他们自己也未必喜欢这些，只是这些东西恰好也连着指挥棒。再往前一步，自愿打卡、自愿捐款，你就说是不是自愿的？

无论如何，反正最终就变成这样：事情本身不重要，一切都围绕指挥棒转。

只要能找到一个可被量化的指标，就针对这个指标一直优化，优化到扭曲。

奶粉里蛋白不够怎么办？加三聚氰胺。指标上去了，就有人赌了。

类似的，苏丹红、瘦肉精、塑化剂，等等，很多事情可能都有类似的逻辑。

为什么会这样？

承认问题和发现问题，本来就是解决问题的前提。

不知道大家以为如何。

预览时标签不可点

Name cleared

微信扫一扫赞赏作者

Like the AuthorOther Amount

赞赏后展示我的头像

作品

暂无作品

Like the Author

Other Amount

最低赞赏 ¥0

Back

Other Amount

赞赏金额

最低赞赏 ¥0

基础知识 · 目录

基础知识

上一篇从志愿填报开始学生和家长都应该考虑到生活不一定要有标准答案下一篇一维查找方法综述：从三分、黄金分割到 Fibonacci 与 Brent

搜索「」网络结果

调整当前正文文字大小

100%

软考架构师备考刷题：从开源题库到单文件离线刷题系统

2026-07-13T00:00:00+08:00

前面我写过软考高级系统架构设计师到底有没有用等等一系列文章，都在二手架构师杂谈这个合集里面，这里面乱七八糟东西很多，有的是分章节的知识介绍，也有的讨论的是这考试值不值得考、我自己怎么过的。这次换个角度，说一个更具体、更"工具流"的事儿：备考时怎么刷题。

上图感谢保哥分享

刷题这事儿，绕不开真题

软考架构师的考试结构是上午综合知识（75 道单选）、下午案例、下午论文。综合知识看着简单，其实就是单选题，可架不住它面铺得太广：操作系统、网络、数据库、软件工程、系统架构设计、项目管理、安全、法律、专业英语，甚至嵌入式、新技术都来一点。你哪一块软，哪一块就给你扣分。我在数据库和前端方面就丢了不少分。

这种考试，光看教材没用，必须得刷真题。原因是真题的"调调"和教材不完全一样，它考的是你怎么用那套知识，而不是你背没背下来定义。而且真题有重复率——不是原题照搬，是同一个知识点换个壳又出来了。你把历年真题里某个模块的题都刷一遍，那个模块的考点你心里就有谱了。

问题是真题散得到处都是。网上能搜到一堆 PDF，按年份分文件夹的那种，动辄十几年的题，打开一个是一个，想做错了想看解析还得翻答案文件。手机上更别提了，PDF 在小屏上翻来翻去能把人逼疯。

找到一个好项目

后来我在 GitHub 上找到一个仓库：Zhang-986/ruankao-architect-practice。

它的厉害之处在于，作者把 2009 下半年到 2025 下半年这十几年（除 2019 下半年那份是扫描 PDF 没法结构化之外）的综合知识真题，外加 7 套 2026 年 5 月模拟卷，一共 1773 道选择题，全部整理成了一个机读的 JSON 文件，每道题带题干、4 个选项、正确答案、解析、所属知识模块、知识点、难度标签。

这就不是 PDF 了，是结构化数据。结构化数据意味着你能拿它干任何事——做一个网页刷题器、塞进 Anki、导进自己写的 app、喂给 AI 做错题诊断，都行。原仓库自己就配了一个多文件静态站点，支持继续练习、章节练习、真题套卷、错题重刷、收藏、AI 诊断导出，功能挺全的。

可它有一个对我特别不友好的点：要求本地服务器。

原仓库的 index.html 用 fetch 异步读取 data/bank.json，这是常规做法，但浏览器对 file:// 协议下的 fetch 有 CORS 限制，双击打开就是白屏。README 里也明确写了"不要直接双击 index.html"，得跑一句 python3 -m http.server 4173 再访问。

平时在电脑前还好，开个终端跑一句也不费事。可我想在手机上刷、想丢给不会用命令行的同事刷、想塞 U 盘里随身带着任何机器双击就开，这种需求它都满足不了。

把题库塞进一个 HTML

所以我 fork 了这个仓库，在它的基础上加了一个"离线单文件版"。

思路特别简单粗暴：用 Python 把那个 bank.json 读进来，序列化成 JS 字符串，直接注入到 <script> 标签里，让 QUESTIONS 变成一个普通的 JS 变量，而不是用 fetch 去拿。这样整个题库就和 HTML 是一体的了，浏览器解析 HTML 的时候题库已经在内存里，不需要任何外部请求，也不受协议限制。

代价是文件变大了，单文件 1.2MB 左右，因为里头装了 1773 道题的全部文字。但 1.2MB 在 2026 年真不算啥，手机浏览器秒开，U 盘随手传，网盘分享也方便。一次加载，永久离线。

刷题系统本身的功能是我之前给另一个考试做过的同款改的：

顺序刷题：1822 题从第 1 题刷到最后
模拟考试：抽 75 题，和单场考试题量一致，答完出分
随机抽题：50 题快速测，适合碎片时间
错题本：答错自动记录，可以一键重练，答对会从错题本移除
学习统计：各知识模块完成进度条 + 错题数
按知识模块练：12 个模块独立练，专攻薄弱项
按年份 / 模拟卷练：整套整套地刷真题

答题交互就是那种答完即时反馈、绿对红错、解析卡片直接展开的路数。答过的题再回来会恢复状态，中途退出有确认提示，答完整套出个得分圆环，≥80 绿、≥60 橙、否则红。

怎么用

Fork版本的仓库地址：https://github.com/cycleuser/ruankao-architect-practice

单文件版在 offline-single-file/ 目录，里头一个 index.html，下载下来双击就能开刷，题库已经内联进去了。不需要 Node，不需要 Python，不需要 npm install，不需要联网。U 盘拷走、微信传给同事、丢进网盘都行。

致谢

题库项目是 https://github.com/Zhang-986/ruankao-architect-practice 的，上游数据好像是来自 https://github.com/wujiaming88/awesome-ruankao，标注的是 CC BY-SA 4.0，都是供个人学习交流用的，只是把题库用单文件 HTML 包了一层壳，让它更顺手一点。

刷题终究只是备考的一环，能帮你把零散的知识点过一遍、把薄弱模块找出来，但真正的功夫还是得落到理解上。真题刷多了你会发现，考来考去就那几个核心点，背选项是没用的，得真明白为什么是这个答案。刷题让你熟悉套路，理解才能让你在题目换了壳之后还能选对。

还是整个在线链接点击即可用的，点击访问原文即可。

不过，如果是要考架构的朋友，自己不可能连从GitHub上下载html到本地都搞不定。

要是下载html并且本地浏览器打开访问都搞不定的话，大概也不太适合这个考试了吧？

刷起来吧。

预览时标签不可点

Name cleared

微信扫一扫赞赏作者

Like the AuthorOther Amount

赞赏后展示我的头像

作品

暂无作品

Like the Author

Other Amount

最低赞赏 ¥0

Back

Other Amount

赞赏金额

最低赞赏 ¥0

二手架构师杂谈 · 目录

二手架构师杂谈

上一篇计算机学科的同学尤其应该注重培养通识并且避免工程上的傲慢

搜索「」网络结果

调整当前正文文字大小

100%

从志愿填报开始，学生和家长都应该考虑到生活不一定要有标准答案

2026-07-12T00:00:00+08:00

最近在看一本书。其实之前就看了它的英文版，后来发现孔夫子旧书网上有二手的，就顺手买了一个，留作纪念。

翻着翻着就想起来一件事：从小到大，很多朋友上学的过程中，都容易被标准化考试带来的那种应试训练打下一个思想钢印——认为世界上的很多事儿都应该有标准答案。

外行的思路往往都是教材上写的什么答案，他们就认为一定是这样，然后还要为自己以为知道答案而窃喜。

有点水平的考试型选手大概会稍微考虑一下这个题目为何是这样的答案，以及如何从题目得到这个标准答案的路径；水平一般的就只是背诵或者记忆，然后期待未来的某个重要的考试一定要考这个，最好是原题。

这很不靠谱。

从人类认识和改造世界的历史看，人对外界的认知都是从模糊到精确，中间还可能走弯路。比如当年存在过的以太学说，又比如燃素学说，这些后来都被证明只是阶段性探索的中间产物，远不是最靠谱的选择。

假设一下，要是咱们生存在当年——那个以以太学说、或者燃素学说为准的标准化考试年代——那标准答案、参考答案是不是就得长那样？

如果人都这样，早就完蛋了。

牛顿那时候的标准答案

在牛顿那个年代，大部分情况下研究的只能是相对低速的物理现象，也都很靠谱。

很自然的，牛顿力学很靠谱，那应该就是标准答案了。

可如果守着这么一个标准答案，不去做任何改进，觉得标准答案就在那、别瞎想、别批判，那恐怕后来洛伦兹变换的爱因斯坦解释就都很难再出现了。人们也就很难去想象，高速的情况下、接近光速的情况下，是什么样。

因为人们会觉得：既然已经有标准答案了，就不用再考虑了，就会丧失探索的欲望。

既然标准答案能解决所有问题，标准化考试解决了所有问题，那利益会指导一切，它就成了最重要的指挥棒了。

尤其是是不是可能出现了一种「脑内迎合」，就是只要看到「标准答案」，就先去奋不顾身地对其进行合理化，甚至以率先完成了看上去自洽的合理化而洋洋得意。

连太阳系都改过答案

再举个更近点的例子，就是行星和矮行星的定义。

以前，大概是三十年前那会儿上学的时候，教材一般都是说太阳系大行星有九个，冥王星是大行星。可到了十多年以前，教材又改了，改成冥王星是矮行星，教材说太阳系只有八大行星了。而最近几年据说又有好事者要改回去，折腾来折腾去的。

实际上，发生改变的从来都不是太阳系，只有人类的概念和教材而已。

标准答案就这样来回变化，会随着时代发展而改变，会根据人的认识而修正。

无他，无非是人定的一种粗略描述罢了。

地层也是人划的

又比如有的地方，那个地层分成几个组、几个阶等等，这些东西其实全是这些研究人员自己根据自己的经验给出的。

自然界原本它就不一定有那么多个组。甚至很多东西，中间可能沉积了、后来又被剥蚀掉了，它就缺失了，这些都是后边观察不到的。能观察到的、留下来的东西，不见得是大多数，甚至可能只是残留的一小部分。

只是人看到了这么一小部分，然后很「聪明」地将其用自己所熟悉的东西来起个名字，再脑内演绎一番精彩故事，写出锦绣文章，花大价钱写文章给敛财的出版社，成了学术成果，然后通过行业协会强制其他人接受。

上学不是一条单行道

日常骑车的目的是到达而不是竞速耍酷，学术研究总应该有那么一点是为了诚实地去进行探索而不是迎合指挥棒。

同理，学习的目的不只是为了升学。读了本科之后读研，读研之后读博，读博之后找地儿弄博士后，博士后出站再找地方教书，一直觉得留在自己这个学科领域内是唯一正确的标准答案——这就是一个需要摒弃掉的传统认知。

人类社会很丰富，人的生活很多样，没必要非要按某一个既定的路径走下去。那已经不见得是最优的了，又何必执着于这种路径依赖呢？

如果一个专业自己实在不喜欢，有机会转专业，就趁本科的时候早转。当然，这一定要深思熟虑，要确定好自己转去的那个地方能让自己接受，不会后悔，或者后悔也能忍住。

有一种最可怕的现象：按家里长辈给的建议做了选择，可家里长辈的信息未必更新到最新版本；而自己想做的事儿又没去尝试、去探索、去理解清楚。等过了很多年，就只能在那后悔当初没有怎么怎么样。

当然了，实际上过了很多年之后，其实还是有机会再去考的，甚至可以重新高考，或者成人高考，可以考研跨专业，等等。

我自己的路径

我读博的时候学地质拿的是理学的博士，本科是学摄影的艺术学学士，后来还成人高考继续读汉语言文学。这目的就只是高兴，因为这个好玩，而且当初错过的那些我能够有机会弥补一下，其实也不指望这些东西能让我直接从事相关领域的工作。

我当年第一份工作是在某所谓央企进行数据采集，体验不太好。因为周围的人都在那抽烟，我是过敏体质，呼吸道、眼睛都敏感，经常容易过敏，所以只能辞了职，考研接着读书。

后来读博之后参与了一段时间的创业公司，跟人合伙开发软件，但那会儿时间精力上很难划分，毕业又麻烦着延期了一年，就自然跟人家散了。

再往后，博士毕业去了一些高校，二本一本陆续都混过，这中间还跑一些互联网公司的合作项目，跟着掺和过一些日子。从南方到北方四处跑，机缘巧合之下，还给人家做过考研辅导、艺考培训等各种各样的事儿。

最后发现还是愿意写代码、愿意教书，这找了个地方继续教。

如果也守着那种报了一个专业就一直从事这个专业的想法，那恐怕生活轨迹会截然不同：大概我还在某企业忍着别人的二手烟？又或者还在某院士团队麾下给人当拎包小弟打下手？也可能还在哪个地方带着孩子们准备艺考？

如果总觉得有标准答案，换个活法就被当成了一种很可怕的叛逆行为，那探索就止步了。

报考别只盯着一个参数

所以无论是专业、学科，还是学校，这些都不应该成为你报考的唯一考虑因素，因为你的生活不应该只考虑这些东西。

应该着重考虑的是要有更多的可能性：要去人口多、机会多、高校也多的大城市。

一线城市能接触到的文化产业更多。比如帝都就有国家博物馆、军事博物馆、故宫博物院、国家图书馆等等，这些是其他地方所没有的。

另外，大城市高校多，行业也多，未来选择也多。如果报考只着眼于某一个行业——就是现在这个行业很热，或者估计未来几年还是很热——然后就去报了，并且准备一直从事这个事儿，可万一学一阵才发现不喜欢，该怎么办呢？

这时候如果在学院路，还有机会通过学院路共同体选一些其他学校的课去了解了解，甚至找机会跨考考研。可如果所选的高校非常偏远，就那么一两所学校在那，也没什么大的图书馆、博物馆，甚至连太多的学术交流机会都没有，那就比较痛苦了。

家长都是为孩子想谋深远，可事实上只考虑就业，或者只根据最近几年和自己的预测，又或者听信所谓专家（其实读没读过大学都不一定，至少大部分没教过大学，教过大学的也未必去过不同城市的多个大学），然后做判断，恐怕就不一定靠谱。

其实完全可以考虑找一个高校多的地方，让孩子以后能有更多选择。

甚至从让孩子找对象的角度看，去个高校多的地方，他找对象的机会也多，在学校里找到的对象往往要比在社会上更单纯，这也是好事儿。

如果始终认为所有事情都有标准答案，而总是去追求这个标准答案，往往可能得到的，是一个更不靠谱的选择。

预览时标签不可点

Name cleared

微信扫一扫赞赏作者

Like the AuthorOther Amount

赞赏后展示我的头像

作品

暂无作品

Like the Author

Other Amount

最低赞赏 ¥0

Back

Other Amount

赞赏金额

最低赞赏 ¥0

基础知识 · 目录

基础知识

上一篇手机当罗盘：从俯仰横滚偏航三个角，算出任意平面的产状下一篇「事情本身不重要」是怎么炼成的

搜索「」网络结果

调整当前正文文字大小

100%

取经路上的几种人

2026-07-11T10:00:00+08:00

原创

这些年带的学生，22级是成果最多的，冠绝江湖，本科生中有好几位达到某兄弟院校的硕士研究生毕业的学术出版要求。

23级相对来说没那么群星璀璨，但是很有多样性，软硬兼修的高手，能歌善舞的偶像，行动力强的实干派，都有很多。

24级变成了两个班，百花齐放，非常多的带佬，高手如云。想当年全校一共六十多人获得全国大学生数学建模竞赛省赛奖项，其中我们专业24级的两个班就有三四十人，这个获奖人数能打得过某些不是太重视相关赛事的兄弟院校。

到了25级，现在情况有点儿令人担忧。一样也是两个班，也有很多多出色的人物，但超一流选手，似乎没有24级那么多了。

尤其是25级有的同学也遇到了和当初24级面对的，那种初步接触开发或者是研究时候的迷茫和无助等等。已经有同样的资源储备，也有24级分享一些相似的案例，甚至还有24级的带佬带他们来过一些比较难的关口，结果却不很理想。

为什么同样一件事，交到不同人手里，结果能差出很多呢？

后来想想，这事儿《西游记》早就写明白了。取经这一路，师徒几个凑在一起，恰好就是不同任务的类型样本。

孙悟空：自己就会找诀窍的那种

悟空这只猴子，是不用人教的，而是自己知道要去学，也知道想学什么。

他学本事那一段最见功夫。花果山过得好好的，他偏偏想到一层——猴子也会老会死。为了这个念头，他扎个木筏，漂洋过海，走了十几年，光是找师父就找了大半个人生。到了菩提祖师门下，别人还在洒扫应对，他已经琢磨透了师父敲他三下脑袋、倒背着手走进去是什么意思——半夜三更来学真本事。

这就是那种人：目标是自己认的，路是自己找的，诀窍也是自己悟的。你不用掰开揉碎了讲，你甚至拦都拦不住。他学七十二变、筋斗云，很认真，他主动学，也自然一学就会，因为他是真想要。

做事也一样。取经路上遇了难处，多是他冲在前头。打不过就搬救兵，一趟南海、一趟天庭、一趟灵山，各路神仙挨个求过来。别人是等着难题自己消失，他是满世界去凑解决难题的资源。

25级其实有一个这样的孩子，之前有一次是习题课，特意叮嘱习题不要传播到网上。他第一个做完了所有的题，还偷偷地把这个题录了个视频发到群里边儿，跟大家炫耀一下显得厉害。

这种人稀罕，也难控制——所以才要给他戴个紧箍。太有主意的人，往往还得配个能管得住的东西，要不然他肯定不会总是服从的，他一定有自己的想法，也可能就打坏了人参果树惹了大祸。

唐僧：本事不大，但认准的事九头牛拉不回

唐僧手无缚鸡之力，遇个妖怪就得被人拎走，看着是最没用的一个。

可整个队伍是围着他转的。为什么？因为这件事是他要做的。西天在哪儿他没去过，路有多远他不知道，会死几回他心里也没底，可他就是认准了要走这一趟。女儿国的荣华、各路的威胁利诱，都没能让他改主意。

这是另一种人：自己未必样样都行，但心里有一杆认定的秤，方向一旦定了就不再摇。他成事，靠的不是本领，是那股子不回头的定力，外加把一群能人拢在身边、一起把事做成的本事。

25级有一个孩子，当初是体育生伤病转考高考，因此成绩不太理想，外语入学的时候创了本专业甚至本校的低分记录。但他从来没说因为自己外语水平不理想就不学了，而是和同伴一起结队，从模型微调到数据清洗再到数学建模，样样都练出来了，还收获了同班一位英语尖子生的芳心。

沙僧：独木难支，但踏实能补台

沙僧存在感低，可这一路也少不了他。

让他自己去取经，多半是取不成的——他没那个主意，也没那个闯劲。但你把他放进这个班子里，挑担的挑担，牵马的牵马，师兄弟吵翻天的时候他在中间和稀泥，遇事也能出一份力、搭一句话。

这种人靠不了单干，可只要有人搭台、有个主心骨，他就能安安稳稳把自己那份做扎实。一个摊子里，这样的人其实是压舱石。

24级当年有一位同学也是体育生，考试成绩也不是很理想，但待人接物非常和善，沟通效率非常高，也愿意给人当绿叶来合作，因此结识了一些外系的同学，一起参赛也拿了省级奖项。

猪八戒：动不动就想散伙的那种

八戒是最让人头疼的。

不是他没能耐，钉耙抡起来也能打，真正的毛病在心气上——路稍微难走一点，他第一个念头就是“分了行李各回各家”，他惦记的还是高老庄那点安逸日子。事儿刚开头，或者走到半道，他就先打退堂鼓了。

而且他这人软硬都不大好使。硬压，他阳奉阴违、偷奸耍滑；讲道理，他左耳进右耳出；真要说管用的，也就一口好吃的、一点小便宜能哄他往前挪两步。取经这么大的事，对他来说更像是被裹挟着走完的，而不是自己要走的。

说白了，这就是那种没什么主动性、随时准备撤的人。事儿成了有他一份，事儿黄了他跑得比谁都快。

这还没有典型的同学，也希望不会有人真的走到这一步。如果只是图着顺利毕业拿个学位，那这大学生活要错过多少精彩内容呢？

把资料发过去，如果有人问「这是什么」，或者「压缩包如何解压缩」，那他就有可能是有点八戒的影子了。

说到底

一支队伍参加比赛，有时候这几种人都可能遇到：有悟空这样自己就往前冲的，有唐僧这样认死理不回头的，有沙僧这样能补台的，只要尽量避免八戒时时想散伙，基本上硬拽着也走到了终点。

分辨人，其实不难。看他遇到难处时的第一反应就够了：是自己去找路，是等着人扶，还是先想着散伙。

用人、共事、看自己，大抵都是这个理。

那么，刚进入大学的你，希望成为哪一种呢？

预览时标签不可点

手机当罗盘：从俯仰横滚偏航三个角，算出任意平面的产状

2026-07-11T00:00:00+08:00

这是十多年前的一个小软件的算法，当时的项目，后来我就退出了，然后这个过程中就一直没再想着继续，现在把它做了个网页版出来，点击访问原文就是了。大家可以用手机试一试。

一个看似简单的问题

把手机随手拍在一块倾斜的桌面、岩层面或者墙面上，不管手机是横着放、竖着放、还是斜着扭一个角度贴上去，只要它紧贴着那个平面，手机总能算出这个平面「朝哪个方向倾、倾多少度」。地质上把这两个量叫产状：倾向（dip direction）和倾角（dip）。手机里的「产状测量」「电子罗盘」App 干的就是这件事。

关键的直觉是：手机贴在平面上时，它自己的朝向是任意的（你可以随便转），但它背面（屏幕法线）永远垂直于那个平面。所以平面的产状只跟法线有关，跟手机怎么摆无关。这篇文章把这套逻辑从头推一遍，给出可复现的计算案例和可视化。

三个姿态角的英文说法

描述一个刚体在空间里的朝向，最常用的是三个欧拉角。中英文对照如下：

俯仰角 —— Pitch，绕横轴（x 轴，机体的左右方向）旋转，抬头/低头。
横滚角 —— Roll，绕纵轴（y 轴，机体的前后方向）旋转，左右翻滚。
偏航角 —— Yaw，绕竖轴（z 轴，垂直机体平面）旋转，也就是航向（Heading）。

在航空航天里这三个词几乎是固定搭配。另外你还会见到几个近义词：航向角常写作 Heading 或 Azimuth（方位角）；整体姿态叫 Attitude 或 Orientation；三个角合起来常缩写为 RPY（Roll-Pitch-Yaw）。手机传感器文档里则叫 Pitch / Roll / Azimuth。

俯仰、横滚、偏航三个姿态角的定义，红绿蓝分别为机体 x/y/z 轴

坐标系与旋转约定

要把话说清楚，先固定两个坐标系。

世界系（导航系）用 ENU：x 轴指向正东（East），y 轴指向正北（North），z 轴指向天顶（Up）。这是本地水平坐标系的标准约定之一。

机体系（手机系）：x 轴指向手机右侧，y 轴指向手机顶部，z 轴垂直屏幕向外——这正是手机加速度计/陀螺仪的常见轴向。

姿态就是一个旋转矩阵，它把机体系的坐标变换到世界系。的三个列向量，恰好就是机体三个轴在世界系（ENU）里的方向。我们采用 Z-X-Y 的旋转次序（先偏航、再俯仰、后横滚）：

其中各基本旋转为：

手机的姿态怎么来的？静止时，加速度计测得的是重力反方向（近似天顶方向），由此可解出 pitch 和 roll；磁力计测得地磁水平分量，配合前两个角度可解出 yaw（航向）。这三个角就是我们的输入。

核心一步：屏幕法线的方向

手机贴在平面上，手机的 z 轴（屏幕法线）就等于平面的法线。而机体 z 轴在世界系里的方向，正是旋转矩阵的第三列：

把展开，第三列只跟 pitch、yaw 有关（roll 是绕 y 轴自身，不改变 y 轴、也就不改变第三列的方向）：

这就是「怎么摆都一样」的数学原因：roll 不出现在法线公式里。你绕着屏幕法线随便自转（改变的是 roll 和一部分 yaw 的组合），只要 z 轴指向不变，法线就不变，产状自然不变。

从法线到产状（倾向与倾角）

有了单位法线（约定朝上，若就整体取反），产状就是简单的几何：

倾角是平面与水平面的夹角，等于法线与竖直方向的夹角：

倾向是平面「最陡下坡」方向的水平方位角，从正北起顺时针度量。最陡下坡方向是法线在水平面的投影的反方向，因此：

反过来，已知产状也能重建法线，用于校验：设上倾方位角，则

关键演示：同一平面，两种任意摆法

下面这个 GIF 是全文的核心。同一个倾斜平面，手机绕着屏幕法线不停自转（模拟你「随便怎么贴」）。注意看：上面一行的 yaw / pitch / roll 一直在剧烈变化，而下面一行的 倾角、倾向纹丝不动。

我们用一个具体的平面来跑数值——真实产状定为倾角 35°、倾向 120°，对应法线（ENU）为。然后用两种完全不同的摆法把手机贴上去：

摆法	yaw	pitch	roll	反算法线 (E,N,U)	倾角	倾向
摆法一（spin=0°）	60.00°	−35.00°	0.00°	(−0.4967, 0.2868, 0.8192)	35.00°	120.00°
摆法二（spin=137°）	−168.70°	24.80°	25.53°	(−0.4967, 0.2868, 0.8192)	35.00°	120.00°

两种摆法的三个欧拉角天差地别，但反算出来的法线一模一样，产状都精确回到 35°/120°。这正是手机「怎么放都能测」的底气。

两种摆法对应同一法线，得到相同产状

完整可复现代码

下面是从三个姿态角到产状的核心函数，以及上面案例的验证。可直接运行。

import numpy as np
r2d, d2r = np.rad2deg, np.deg2rad

def Rx(a): c,s=np.cos(a),np.sin(a); return np.array([[1,0,0],[0,c,-s],[0,s,c]])
def Ry(a): c,s=np.cos(a),np.sin(a); return np.array([[c,0,s],[0,1,0],[-s,0,c]])
def Rz(a): c,s=np.cos(a),np.sin(a); return np.array([[c,-s,0],[s,c,0],[0,0,1]])

def R_from_ypr(yaw, pitch, roll):
    return Rz(yaw) @ Rx(pitch) @ Ry(roll)      # 列 = 机体轴在 ENU 中的方向

def attitude_from_normal(n):
    n = n/np.linalg.norm(n)
    if n[2] < 0: n = -n                          # 法线取朝上
    dip = r2d(np.arccos(np.clip(n[2], -1, 1)))
    dip_dir = r2d(np.arctan2(-n[0], -n[1])) % 360
    return dip, dip_dir

def normal_from_attitude(dip, dip_dir):
    up = d2r((dip_dir + 180) % 360)
    return np.array([np.sin(d2r(dip))*np.sin(up),
                     np.sin(d2r(dip))*np.cos(up),
                     np.cos(d2r(dip))])

# 真实平面：倾角35°，倾向120°
n_true = normal_from_attitude(35, 120)

# 摆法一：yaw=60, pitch=-35, roll=0
R1 = R_from_ypr(d2r(60), d2r(-35), d2r(0))
print(attitude_from_normal(R1 @ [0,0,1.0]))   # -> (35.0, 120.0)

# 摆法二：yaw=-168.7, pitch=24.8, roll=25.53
R2 = R_from_ypr(d2r(-168.70), d2r(24.80), d2r(25.53))
print(attitude_from_normal(R2 @ [0,0,1.0]))   # -> (35.0, 120.0)

别忘了磁偏角与经纬度

上面算出来的倾向是相对手机航向的，而手机航向来自磁力计，指的是磁北。地质记录和地图用的是真北。两者之差就是磁偏角（magnetic declination），它随经纬度和年份变化，可由 WMM/IGRF 地磁模型按位置查得。校正很简单：

倾向真北倾向磁北磁偏角

以重庆（纬度 29.563°、经度 106.551°）为例，磁偏角约 −1.9°（西偏），则磁北倾向 120° 对应真北倾向 118.10°。

如果还想把这个法线放到全球统一的地心地固坐标系（ECEF）里——比如做跨区域的构造统计——就要用经纬度做一次 ENU→ECEF 旋转：

其中是纬度、是经度。同一块岩层面在重庆测得的法线，换算到 ECEF 就是。这样，无论你在地球上哪个位置，任意时刻、任意摆法测到的产状，都能落到同一套全局坐标里比较。

小结

整条链路其实非常干净：

手机静止时用加速度计+磁力计解出 yaw / pitch / roll 三个姿态角；
组成旋转矩阵，取第三列得到屏幕法线——这一步天然把 roll 消掉，所以怎么摆都行；
由法线用和直接读出倾角和倾向；
用磁偏角把磁北换成真北，必要时用经纬度把法线搬进 ECEF 全局坐标。

一部手机、几行三角函数，就复刻了地质罗盘的核心功能。而它「随便怎么放都准」的秘密，不过是一句话：产状只认那根垂直于平面的法线，不认手机自己转了多少。

预览时标签不可点

Name cleared

微信扫一扫赞赏作者

Like the AuthorOther Amount

赞赏后展示我的头像

作品

暂无作品

Like the Author

Other Amount

最低赞赏 ¥0

Back

Other Amount

赞赏金额

最低赞赏 ¥0

基础知识 · 目录

基础知识

上一篇应届生搞OPC一人公司的避坑提示下一篇从志愿填报开始学生和家长都应该考虑到生活不一定要有标准答案

搜索「」网络结果

调整当前正文文字大小

100%

应届生搞OPC一人公司的避坑提示

2026-07-10T00:00:00+08:00

最近一段时间了，"一人公司 OPC （One Person Company）"，这个词刷屏刷得厉害，网上甚至有各种"超级个体+AI=月入十万"的励志故事，看着确实挺诱人。也有一些同学问这事儿到底能不能做。

先说结论：可以尝试，但要冷静考虑好，别头脑一热就冲。

对应届生这个特定群体来说，网上那些成功故事里可能没有提到潜在的坑，尤其有几个雷区是应届生需要特别注意的，别人踩了无所谓，应届生踩了可能影响很多。

OPC到底是个啥

先说清楚，OPC就是One Person Company，一人有限责任公司。不是说"只有一个人的公司"那么简单，而是一个法律概念，正经的企业法人，有独立财产，能签合同、开发票、打官司、申请知识产权。粗略来说，跟个体工商户最大的区别就是"有限责任"——正常情况下有限责任公司赔了钱，股东只以认缴出资额为限承担债务，你个人的存款啊房子啊车啊等等就都不会被拿去抵债。

不要轻易买课

在这之前，得先说一件比弄一人公司本身更重要的事，就是防范非理性消费。

"一人公司"火了之后，网上冒出来一大堆教你"零基础开OPC、月入十万"的课。几百到几千不等，文案写得一个比一个诱人，好像你交了钱跟着做就能躺着挣钱。

这些课的套路很一致：先给你看几个成功案例，让你觉得"别人行我也行"，心里痒痒的；然后告诉你门槛很低、有AI帮忙、不用会写代码；最后催你赶紧下单，名额有限、优惠马上结束。

你仔细想想，他要是真能靠OPC月入十万，为啥要卖几百块的课给你？或许它们就是靠着卖这种课程才月入几万的呢？

现在AI确实帮助很多外行人都能开始写相关内容了，完全没听过CDN的甚至也可以给人讲全栈开发，而且营销起来也很成功，比如有个经典案例，就是说某个头部营销号说"有个东西，也是我今天才学到的，叫 CDN"。

又比如是出自清华美院的某位营销高手，哪怕其原来的学术路径基本与AI、深度学习等专业不太相关，也可以充当区工智能的大师傅，实现卖课收入不菲。

创道投资咨询总经理步日欣认为，AI课程其实是收消费者的智商税，抓住了部分消费者焦虑未来、渴望新知的心理。

“从卖课经验看，一部分讲的是‘创业艰辛和融资逻辑’，另一部分就宣传‘上完课半个月搞定融资’，知识与情绪的差别可能就造成了课程的大卖。本来，从用户体验上讲，学知识本来就很累人，谁愿意付费受累，但’上一次AI课就能跟上时代、不被淘汰‘的宣传，则抓住了现代人的焦虑心理。”步日欣说。

https://www.thepaper.cn/newsDetail_forward_26425574

当然了，营销是一种本事，人家能卖出去，就比很多学校里默默讲课还没太多人听的教师要成功多了，也不是说所有课都是骗人的。

网上有人把它们这种课程比作「挥起镰刀割韭菜」，虽然生动，但也未必尽然，毕竟孩子们不见得没有判断力。

主要是孩子们要想清楚：真正有用的东西，是花几百块看几节录播视频就能学到的么？还是对营销大师傅定向投喂付费了就能获得的？

那些卖课的人赚的，不是OPC的钱，是你的钱。

第一个雷区：应届生身份

这是应届生同学最需要考虑的一点，考公考编、人才引进、参加校招，好多渠道都认这个。

而认定应届生身份的一个关键指标，在不少地方就是"有没有缴纳过社保"。

你注册了OPC，如果以公司名义给自己缴社保，那就要注意了，可能在很多地方的认定标准里，你就不再是应届生了。

应届生身份一旦丢，想找回来可难。

也许有的地方认为"两年内未落实工作单位的毕业生"还算应届；可你确实是开了自己的公司，如果还缴了社保，那这不就得叫"已落实工作单位"了么？

所以，如果你心里还惦记着考公、考编、走人才引进落户这些路子，一定要先把当地的应届生身份认定标准查清楚再决定是否以及如何弄OPC。

千万别贸然上头，直接就公司开了、社保缴了，然后回头发现考公报名那关过不了，那才叫无奈。

第二个雷区：社保断缴

如果你的OPC业务订单不稳定，收入也不稳定，甚至可能给自己的社保断缴。这个对谁都是问题，对毕业生尤其要命。

有的地方车牌摇号、子女入学，都跟社保连续缴纳年限挂钩。

应届生刚毕业，本来社保年限就是零，如果一上来就创业、订单又接不上，社保断断续续，后面很多事情可能都受到影响。

第三个雷区：有限责任不一定真有限

OPC最吸引人的卖点就是"有限责任"，公司亏了不连累个人。听着美，可这其实也是有标准有条件的。

就是你得能证明公司财产独立于股东自己的财产的，否则就应当对公司债务承担连带责任。

而且，还有可能要面对"举证责任倒置"。意思是别人告你，你得主动证明自己的财产和公司财产相独立。

这对一个刚毕业、啥都不懂的学生来说，潜在的风险可是实打实的。

刚开始创业的时候，也许你偶尔就用个人微信收订金、营业款，甚至公私账户混着用，买东西记账乱七八糟—等等，这些事儿在创业初期太常见了。

每年还得做审计，请会计师事务所出报告，这又是一笔成本。你要是为了省钱省事跳过这步，出了事更说不清。

一旦发生纠纷，你无法证明公司财产和自己的个人财产相互独立，可能就会被判连带责任了。

第四个雷区：AI产品淘汰率

这个跟OPC模式本身关系不大，但跟"为啥要开OPC"关系很大。绝大多数应届生搞OPC，业务方向都是AI应用。

某些AI工具聚合网站收录了几千上万个AI工具，其中有不少已经关闭、被收购或终止运营。

AI产品淘汰很快，你早起的靠智能体做的工作流，可能后面就被模型内禀能力给吸收了，甚至对应场景的能力还不一定打得过新模型。

你雄心勃勃做了个产品，也许不到半年后就没人用了，订单可能也彻底没了，可是公司还在那儿杵着，你得继续记账、报税、审计，注销也得走流程。

那到底能不能干

说了这么多坑，不是劝你别干，是劝你想清楚再干。

适合干的情况：你本来就走技术路线、有拿得出手的东西，在校期间已经做过项目、接过单、或者有明确的垂直领域能力。你开OPC是为了把已有的副业正规化、能开票、能接企业单。这种情况下OPC就是个工具，用得好是加分项。而且你目标明确，不指着考公考编，那应届生身份这块的顾虑就小很多。

不适合干的情况：你其实就是被"超级个体+AI=月入十万"的故事冲昏了头，或者是被卖课的忽悠得觉得这件事很简单。自己还未必具备啥核心能力，却想着先开个公司再说。这种十有八九是给代办机构贡献KPI，折腾一圈公司也黄了，还搭进去一个应届生身份。

中间地带：你想创业但还没想好干啥，又怕丢应届生身份。这种情况我建议你先别急着注册公司。可以先以个人名义接单、做副业、攒作品和客户，等你真有稳定订单和明确方向了再注册也不迟。

OPC对有能力、有想法、有资源的创业者来说，是个不错的载体。但绝对不是给没想清楚的人准备的避风港。

不少成功案例里的人，要么是读研读博时候就有门路，在读同时搞研发、要么是有大厂经验资深开发者、要么是已经创业过几次的老兵。他们开OPC是水到渠成，不是脑子一热。如果这些故事被卖课的包装一遍之后，就变成了"你也可以"。

你刚毕业，最大的本钱是时间和身份，这俩东西丢一个都心疼。想清楚了再动，衡量好成本和风险吧。

预览时标签不可点

Name cleared

微信扫一扫赞赏作者

Like the AuthorOther Amount

赞赏后展示我的头像

作品

暂无作品

Like the Author

Other Amount

最低赞赏 ¥0

Back

Other Amount

赞赏金额

最低赞赏 ¥0

基础知识 · 目录

基础知识

上一篇大学里是不是什么都学不到下一篇手机当罗盘：从俯仰横滚偏航三个角，算出任意平面的产状

搜索「」网络结果

调整当前正文文字大小

100%

大学里是不是什么都学不到

2026-07-09T00:00:00+08:00

网上总是有人说大学里啥也学不到，真是这样的么？

先说课程本身

要是你指望把那些基础课程学完、考试一过，就觉得能学到很多东西，那这想法本身就不靠谱。

为啥呢？有的老师就是念PPT。有的PPT还包浆了，不知道传了多少年。更过分的，有的老师让学生自己做PPT，让学生上去念。这事儿甚至闹出过舆情。你要是光盯着这些东西看，那大学里只靠听课确实可能学不到太多东西。

再说下课之后

可大学最关键的地方，恰恰是它没有老师再带着你了。

高中那套思路，是老师给你定制好一个规划，你照着走，每一步亦步亦趋，大部分内容学会了，然后培养好应试能力，考试分就高。

大学不是这样。大学没有唯一的衡量标准，也没有那么多标准答案。你拿高中的思路来套大学，套不上。

很多人说大学什么都没学到，估计很大一部分原因是他的学习习惯没转过来。还等着别人安排、别人带，没人带就呆着，就说大学不行。

大学该怎么读

到了大学，最重要的是找到一切机会，以所学为基础，对自己感兴趣的方向去探索。

很多东西课本上没讲、老师没教，那你自己个儿就得想办法找地儿学去。这是最重要的能力。有了这能力，再经过基础的科研训练，就能读研了。要是你在某个方向上还能总结出自己的问题，研究上能搞出点小成果，那就适合读博。

那要是不想读研读博，就只想着读完本科就去工作，怎么办？也一样，除了课程内容得学点别的。光指望课程内容学东西，不现实，也不划算。大学课余时间那么多，一定得用起来。

那些浪费掉的时间

有的人课余时间就是刷短视频、打游戏，或者抽烟喝酒，又或者各种谈恋爱。这算各种不同的人生选择，只要不违法违纪，谁也管不着。

但有的人课上时间也刷短视频或者打游戏，拇指上下滑动，几十秒的视听刺激，基本消耗掉了注意力的阈值，一局游戏四十分钟，四局游戏一上午，晚上熬夜继续打游戏，还要扰民闹矛盾，然后自己黑眼圈。

不只是普通高校，所谓名校，也有很多这样的情况，上课也都是有人跑到后排躲着玩手机，也有人熬夜通宵打游戏，也有人每天用手机七八个小时以上。

你要是这么过了，回头说大学啥也没学到，那很大比例是你自己的问题。

大学里有啥能用

大学里基本都有图书馆，这上课能学到的那点东西其实是一小部分，图书馆里的东西可能更多。有的学校不一定有大的实体图书馆，但有在线的电子文库、论文订阅，这些都能用。

教材是最老的。期刊相对新点，但也有限，审稿周期一年左右甚至更长。会议论文最新，可能就几个月。想看新玩意儿，往会议论文那儿找。

还有一样东西特别需要重视——讲座。大学里会来一些人做讲座，有的真有东西。你去听、去提问，这都是交流的机会。别觉得讲座是累赘、是耽误功夫。不愿意听的课、不愿意去的讲座，你也得尽量利用起来，能有所收获才行。

还有老师

老师上完课就走了，你平时跟他也没联系，跟人也不熟，也不知道人干嘛的。

那怎么办？先搜搜这些老师的论文都有啥，他研究什么的，看自己感不感兴趣。感兴趣的，课上找机会留个联系方式，打请教请教。万一有合作机会，让人带着打个比赛、一起做个科研项目，甚至后来准备跟他读研读博，都挺好。

关键就一条：得主动去做，别等、别靠、别要。

成年人要为自己负责

大学最重要的，是你成年了。成年人得为自己的行为和选择负责任。

有人说大学什么也没学到，这话恐怕更多反映的是，这人刚成年的那段时间，自己做的选择不太理想，所以觉得没啥收获。

一样读了同样的大学，有的人成就很多，有的人就差一些。

那么，你准备度过怎样的大学生活呢？

预览时标签不可点

Name cleared

微信扫一扫赞赏作者

Like the AuthorOther Amount

赞赏后展示我的头像

作品

暂无作品

Like the Author

Other Amount

最低赞赏 ¥0

Back

Other Amount

赞赏金额

最低赞赏 ¥0

基础知识 · 目录

基础知识

上一篇AI 能抹平外行和内行的差距吗？当前恐怕不行下一篇应届生搞OPC一人公司的避坑提示

搜索「」网络结果

调整当前正文文字大小

100%

计算机学科的同学尤其应该注重培养通识并且避免工程上的傲慢

2026-07-08T00:00:00+08:00

学生突然问我：老师，宿命论可信吗？

我问怎么说。

他发来了一个视频，说里面有一个特别成功赚了很多钱的大学霸，说「所有事物的发展在宇宙爆炸那一刻就定好了，都是必然结果，早就预设好了。」他说，如果分子原子的运动能被精确计算，下一步的发展确实是可以预料的。

我说我还没来得及看这个视频，但从话语风格和讨论视角推测，说这话的人大概从本科开始一直都是计算机相关专业的。

他说对，搞大模型的。

我说那就正常了。如果学计算机相关专业的人成就特别出色，同时有可能缺乏对自然科学的基础认知和底层敬畏，对自己的技术又极有信心，就可能会这样。

他问，难道也是缺乏通识知识？

我说也不见得是缺乏，毕竟再厉害的人，都可能存在不擅长的领域。

这个对话让我想了很久。

不是宿命论本身——那东西从拉普拉斯妖开始就被讨论了无数轮，热力学第二定律和量子力学的不确定性原理早就把机械决定论锤烂了。

我想的是另一个问题：计算机专业如果缺乏自然科学的知识学习，同时万一还缺乏人文学科的素养培养，就可能因为自己学科领域的出色而过于有信心，乃至到自负的程度——缺乏对自然的敬畏，也缺乏人文的关怀。

然后在这个基础上，为什么优秀甚至杰出的工程人，尤其是搞计算机的人，特别容易陷入一种"我这条路径能解释一切"的幻觉？

蒸汽机师傅的终极奥义

假设你是一个十九世纪的蒸汽机师傅。

你一辈子都在优化热效率、改进活塞气密性、调校飞球调速器。你造出了当时最高效的蒸汽机，力大无穷，驱动工厂、火车、轮船。

你可能真心觉得，蒸汽机就是解决一切动力问题的终极答案。

过了些年，内燃机把汽车送上了公路，燃气轮机把飞机送上了天。

可再过些年，核反应堆把原子核的能量释放了出来。

回头看那个蒸汽机师傅的"终极奥义"，是不是觉得太早了？

这不是蒸汽机师傅水平不行。他可能在他那个范式里已经做到了极致。他缺乏的不是聪明和努力，是认知的维度和角度。他原来的工作场景可以不知道电动力学，也未必知道链式反应，更不用说什么高温超导。这些东西不在他的知识坐标系里，所以他无法想象能量的来源除了烧开水还能有别的方式。

就像一个一辈子只吃过采摘的水果的人，不知道食物还能煮着吃。他不是固执，是真没见过。

从投石机到核武器

古代的工程发展也遵循类似的轨迹。从简单的抛石，到床弩，到连发弩，到利用重力势能的重型投石机——工程优化一直在推进，射程越来越远，威力越来越大。如果没有能源革命，迟早会出现机械动力的连发弩箭，或者其他形式的动能武器。

但炸药的出现不是靠工程优化投石机得来的。核武器的出现不是靠把炸药做得更大更纯得来的。这些是范式跃迁，是换了一条赛道，用完全不同的物理原理实现了几何级数的能量释放。

工程优化能让你在同一条赛道上跑到极致，但它给不了你新赛道。

成功的案例不能证明路径的普适

回到搞大模型的那群赚了很多钱的出色人士。或许有些人真心觉得 Transformer 就是终极架构，Scaling Law 能一路通向 AGI，数据和算力能解决一切。

但到目前为止，似乎并不是如此。

拿蛋白质结构预测来说。AlphaFold 确实在这个问题上做到了惊艳的程度，但它用的 Evoformer 架构本身就融合了演化生物学的信息和结构生物学里的不变性约束，不只是一个通用 Transformer 灌数据就能跑出来的东西。换句话说，问题本身的特性决定了这个解法能走多远，而不是解法的通用性决定了它能覆盖多少问题。 一个特定问题上的成功，不等于这个技术路线在所有问题上都能复制。

搞研究的人对此应该体会更深——一个实验室同时探索好几个方向，十个里能跑出来一两个就很不错了。那些没跑出来的项目，外人可能根本也看不到，新闻报道里也不会写。所以我们看到的"成功案例"本身就存在严重的幸存者偏差。

把工具当信仰，把路径当终点，忽略了问题本身的结构差异，这是所谓杰出工程师最容易犯的错。

更需要通识的计算机专业

说回开头的判断，为什么计算机专业的杰出人士尤其容易踩这个坑。

一个是学科本身的特性。搞计算机，你自己定义问题，自己解决问题。语言是你设计的，编译器是你写的，跑起来不对你就改，改完再跑。这跟物理化学那些实验科学完全不一样——人家是去猜自然规律，猜错了没办法改规律，只能改自己的猜想。但计算机里，规则就是你定的，边界不够就加内存、不够就加显卡，实在不行换个架构重来。待久了你就容易忘一件事：出了这个屏幕，到了真实世界，大多数问题的规则不是你定义的，也不是你改几行代码就能推平的。

另一个是历史积累的效用不同。物理学家面对的宇宙，几百年来牛顿、麦克斯韦、爱因斯坦这帮天才都没穷尽，从业者天然就有种敬畏——自己不过是漫长链条上的一环。生物学家面对的是进化了几十亿年的系统，越研究越觉得复杂。但计算机这行节奏太快，快到三年前的框架就有人叫"上古遗产"，五年前的论文可能就没太多人引了。这种节奏会给人一种错觉，觉得过去的东西不重要，我手上这套才是最新的、最能打的。可物理学的牛顿定律三百年了还在用，你敢说三年前的框架过时了，但不敢说三百年前的力学被淘汰了——这本身就是一种学科差异带来的认知偏差。

自然科学告诉你的世界很硬核：能量守恒、熵增、测不准关系，这些是宇宙层面的约束，不是你多买几张 H100 能突破的。人文社科告诉你的东西很复杂：历史上多少帝国因为傲慢崩了，多少决策因为只看一个维度搞砸了。这两类知识恰恰是计算机培养方案里最容易被挤掉的——工程相关的课表太满了，操作系统、编译原理、算法、机器学习，哪个不重要？挤来挤去，通识课的比例就有限了。

一个人如果这三样凑齐了——习惯了自己定规则、习惯了快速迭代觉得旧的都不值一提、又恰好缺了自然科学和人文的底子，然后他又在自己的领域做得很出色赚了很多钱取得了世俗眼里的「巨大成功」——那很自然，他的自信心就容易漫出自己学科的实际边界。看什么都像一个待优化的系统，什么问题都觉得加数据加算力能搞定。宿命论也好，AGI 必然到来也好，说到底都是同一个思维习惯换了个话题而已。

谦逊是一种美德

或许有一个规律：真正厉害的人，往往相当谦逊。 如果一个人不谦逊，他可能也很有能力，但未必能到最顶尖那个层次。

为什么谦逊和水平有相关性？因为谦逊不是道德品质，是认知能力。你能意识到自己不知道什么，你才可能去学。你能意识到自己当前的方法有边界，你才可能去突破边界。一个人如果觉得自己已经掌握了终极真理，他的认知容器就满了，再也没有空间装新东西。

那种一个劲儿吹嘘某一个技术、某一个框架、某一个理论的人，要么是能从吹嘘中获得利益，要么就是真的——用北方话说——山炮。

不过"山炮"这个词可能太重了。也许只是偏执。偏执一段时间之后，也许能改变。真正的山炮是不认为自己需要进步或者改变的。所以重点不在于一个人当下的观点对不对，在于他有没有给自己留接受信息发散的空间。

保持开放心态

我的几个学生现在持续看新东西，对自己学过的内容持审慎态度，持续更新，反复反思。这就是进步的节奏。我希望他们千万不要突然松了劲头，也不要崩得太紧，只要持续保持开放心态持续进步就好。

哪怕有一天人类真的达到了 AGI，也不一定只有一条道路。就像肉可以煮着吃，也可以烤着吃。最怕的不是走得慢，是走着走着你觉得自己行了，哪怕还没达到目的地，就突然信心爆棚，然后把地图一扔，说其他的路都是错误的。

回到宿命论那个问题。说实话，这种哲学层面的终极问题不是我所擅长的领域。虽然我内心并不认同机械决定论，但你要我给出一个无懈可击的论证来驳倒它，我也做不到。量子力学的不确定性、复杂系统的混沌效应、自由意志的神经科学讨论——每个角度都有各自的解释力，也可能有各自的局限。我唯一比较确定的是：如果你因为相信一切都是注定的，就不再努力、不再探索、不再反思了，那这个信或者不信的结论对你而言就不太划算。

真正值得琢磨的或许是：当你发现自己正在用你熟悉的那个锤子去砸所有钉子的时候，能不能停下来问一句——有没有可能，有些东西根本不是钉子？

预览时标签不可点

Name cleared

微信扫一扫赞赏作者

Like the AuthorOther Amount

赞赏后展示我的头像

作品

暂无作品

Like the Author

Other Amount

最低赞赏 ¥0

Back

Other Amount

赞赏金额

最低赞赏 ¥0

二手架构师杂谈 · 目录

二手架构师杂谈

上一篇软考高级系统架构设计师到底有没有用下一篇软考架构师备考刷题：从开源题库到单文件离线刷题系统

搜索「」网络结果

调整当前正文文字大小

100%

AI 能抹平外行和内行的差距吗

2026-07-07T00:00:00+08:00

大胖哥大胖哥

前一阵在赵老师的Python群里面，有人聊起 AI 编程工具，说有了这东西，一个完全没学过编程的外行，配上各种工具和技能，能跟计算机本科毕业生干一样的活。甚至有人觉得 AI 彻底抹平了信息差，外行借助 AI 能达到硕士水平。

真的如此么？恐怕未必。

拿写代码来说

一个外行用 opencode 或者 cursor、codex，搭个简单的页面，写个一次性小脚本，确实能做出来。但稍微往外走一步，往真实的、复杂的业务环境里走一步，差距立刻就出来了。

现在短视频平台上经常刷到这样的内容：一个自称零基础的人，花了半天，用 AI 搭了个漂亮的网页。前端导航栏、卡片、按钮一应俱全，后端还能读写数据库，甚至接了个支付接口。评论一片"程序员要失业了""以后不需要学代码了"。

然后坑人的卖课的就都开始了，贩卖焦虑是它们卖课的好机会。

几乎没人注意到一个问题：这个页面和后端用的全是假数据。那些好看卡片、表格、图表，填充的是 AI 随手编的示例——用户名全是"张三""李四"，数据曲线光滑得不像真实世界。在本机 npm run dev 看到的华丽，距离能上线的东西，中间隔着的东西多了去了。真数据一灌进去，字段类型对不上，null 值没处理，并发没考虑，错误路径一条没覆盖。

有人说那可以让 AI 继续改，agent 编排嘛，让 AI 自己检查、修、打磨。理论上是这样，外行实际操作起来是另一回事。他判断不了 AI 每一步输出的质量。AI 改了三轮，数据库结构变了一次，API 的返回格式调了两次，中间多了几个他没见过的配置文件。他问 AI"这些文件干嘛的"，AI 给了解释，他看着挺长挺专业，觉得大概没问题。这个"大概"就是裂缝的开始。

事情不是突然失控的。最开始他还能看懂 AI 在干嘛，毕竟一个单 HTML 页面的结构就那么几行。后来依赖越来越多，AI 加了中间件、配了缓存层、换了状态管理库。每一步都说得通，每一步都把他的认知范围往外推了一点。推到某个位置，他突然发现这个项目在跑什么他完全说不清楚了。他只是 AI 指令的传达者：AI 说装这个包就装，AI 说改那个配置就改，AI 说这个报错解决了它就解决了。他点头，但没真的看懂。

这种情况下如果出问题——比如线上某个接口莫名其妙报 500——他连该从哪里查都不知道。日志贴给 AI，AI 说大概是某个第三方依赖的兼容性问题，建议回退版本。他照做。好了一阵，又出别的问题。继续贴给 AI，AI 继续给方案。这个循环的终点，不是有一天他突然学会了，是有天连 AI 自己也绕不出来了——上下文塞满，bug 叠加 bug，之前的"修复"成了新问题的来源。到那个时候别说他，有经验的工程师接手也得头疼一阵。他以为自己是项目的主人，实际上他只是 AI 输出管道上的一个转发节点。而且他对这个处境毫无察觉。

这就是外行用 AI 最危险的状态。AI 会给他一种信心，让他以为自己控制住了一切。问 AI"这个架构合理吗"，AI 说合理。问"有没有安全问题"，AI 列了几条，他说修，AI 修完说修好了。全程他没有独立验证任何一件事的能力。但因为每一步都得到了肯定的回复，他觉得自己在掌控全局。这种信心是 AI 替他搭起来的——他每次问，AI 每次都给一个让他觉得没问题的说法。他对这些说法没有任何独立验证，但说得多了，他就信了。等他真把这个东西推到生产环境里，那些他"验证过"的安全问题、那些他"检查过"的边界情况、那些他"跑通过"的测试，每一项都是拿 AI 的回复当证据的。而他根本分不出那些回复里哪句是事实、哪句是 AI 在顺着他说的漂亮话。

说回来。外行人用 AI 写代码，缺的不是敲键盘的手速。工具已经很好用了，说话就写，报错就改，跑不通就调。缺的是判断力。AI 写完一段代码，你看不出它对不对。你能看懂的那部分，刚好在 AI 替你兜着的那条线以内。线外面的东西全是黑的。你不知道这个函数的边界情况该怎么测，不知道那个 SQL 查询数据量大了以后会不会崩，不知道它用的库是不是已经废弃了。AI 不会主动告诉你这些，除非你问。但你在不知道这些概念的时候，连问都不知道该问什么。

这还只是写代码，AI 做得最好的领域。

「最可能」不等于「最好」

目前这代 AI——Transformer 架构的大语言模型——本质上是个概率生成器。你问它一个问题，它给出的是基于训练语料统计出的最可能让用户满意的回答。这个差别在通用场景下不明显，在垂直专业领域就非常大。专业领域的"最优解"常常不在最流行的那些答案里，有时候还跟流行做法反着来。

它倾向于给你一个迎合的回答。你说的东西它顺着你说，给了个看起来头头是道的方案。你看得舒服，觉得它真厉害。但这个方案放在行业里，可能是五年前的思路，可能是大厂对新手的通用建议但完全不适合你的场景，甚至可能已经被更新的实践推翻——只是训练语料里旧内容太多，它没见过新的。

两个同学用同一个 AI 做同一个作业，给同样的问题，大概率得到很相似的答案。思路相似，结构相似，用语都相似。查重一过，两个人都傻了。他们没有互相抄，只是 AI 的输出池就那么大，概率最高的那条路，两个人一起走到头了。

坐标系

外行人缺的是一套坐标系。行业里的人，哪怕只是个刚毕业的本科生，四年下来至少建了一个知识框架：知道这个领域大概分哪几块，每块有哪些核心问题，什么方案在什么条件下成立，哪些结论有前提、换个场景就不对了。这些东西学的时候可能没觉得多有用——谁背地质年代表的时候不犯困——但它们是判断力的底盘。

有了这个底盘，AI 给你的东西你才能校准。它说了个方案，你能判断这个方案在你的场景下对不对。它列了参考文献，你知道哪篇是扎实的工作，哪篇是水文。它给了个看起来很厉害的实现，你知道少了一块——因为你清楚这个东西在实际工程里有哪些必踩的坑，AI 一个都没提。

外行人没这个底盘。AI 说什么就是什么。AI 错了他看不出，AI 偷懒了他发觉不了。他只能从"结果看起来对不对"来判断，但很多专业问题结果是看不出来的——系统跑了三个月才发现数据库设计有缺陷。三个月前那个"看起来对"一文不值。

反过来，如果两个人都是做这行的，一个经验浅一个经验深，AI 确实能拉近一些距离。经验浅的那个人知道自己要什么，只是手生，工具不熟，查文档慢。AI 帮他补了这部分——代码说话就写，文档不用查了直接问，调试报错贴回去它帮你分析。他能看懂 AI 给的方案的边界，能判断方向对不对，能识别出来 AI 是不是开始胡扯。经验深的那个老手只是比他快，但两个人看的是同一张地图。

AI 抹平的是技能熟练度，抹不平认知基础。工具越好用，对内行人越是放大器——知道往哪儿使劲的人越用越强。不知道往哪儿使劲的人，工具越好越容易被带跑偏。而且这个跑偏特别隐蔽，因为 AI 的回应永远是自信的、流畅的、裹在专业术语里的。对没有辨别力的人来说，自信和正确长得一模一样。

尺度

目前这代模型天然倾向于给出最大概率的、不冒犯的中庸回答。

在写代码这种答案比较"硬"的场景——能跑就是能跑，报错就是报错——这个倾向的危害还算可控。

在答案比较"软"的场景，比如做研究、做判断、做决策，问题就大了。

很多专业场景下，最大概率的解就是最平庸的解，真正有价值的东西往往在长尾里。

拿地球科学来说。你能采到的样品在整个地球中占比微乎其微。某个岩体你打了几个钻孔取了几段岩心，这几段岩心在多大程度上能代表整个岩体？在一个侵入岩体里，矿物组合、结构构造、蚀变程度这些东西可能几米之内就全变了。人的取样永远有物理上限，根据这些取样得出的认识，本质上是一个带有很大不确定性的概率估计。

AI 不这么看问题。它基于已有的数据——那个岩体被文献记录过的描述——拼出一个"最可能"的样子，然后用相当确定的语气告诉你。外行人看了觉得好厉害、好清楚。懂行的人看了知道这份清楚是假的——模型把不确定性吃掉了，把本来应该老老实实写上"误差范围很大"的部分，换成了一个干脆利落的答案。

搞地球科学的人或许对 AI 预测未来这件事不以为然，原因就在这。

更不用说用 AI 推演宇宙演化、搞什么宿命论必然性了。连脚下这颗行星的三四成奥秘都没弄明白——这还是个粗略说法，不同学科不同层次比例不同——就敢用统计模型去外推几十亿年的宇宙史，这是对自己手里那点数据代表性能耐的盲目自信。

有跨尺度研究背景的人——搞天文地质的，时间跨几十亿年，空间跨全球到显微——对这个问题可能格外敏感。同一个规律在小尺度和大尺度上表现完全不同。地壳尺度的变形机制和矿物晶格尺度的变形机制差了十万八千里，用其中一套去套另一套，结果一定是错的。区分哪些规律是普适的、哪些是尺度绑定的、哪些在什么条件下可以从一个尺度平滑过渡到另一个尺度——目前的 AI 做不了这个。它训练数据里可能有这些内容，但它没有判断力去决定什么时候该用哪一套。有判断力的，是脑子里装着跨尺度框架的人。

而且目前的 AI 不仅跨不了尺度，它连"意识到自己在用一个尺度的规律去套另一个尺度的问题"这件事都做不到。它就是在自己的向量空间里找一个最接近的问法、拼一个最大概率的答法。给它一个具体的小问题，答得像模像样。给它一个跨尺度的大问题，也答得像模像样——因为它不知道自己不知道，它只是在生成。但那个答案，在懂行的人看来，是把多个不同层面的东西搅在一起，每一条单独拿出来可能都对，合起来完全不对。

AI 抹平不了外行和内行的差距。它抹平的是技能层面的熟练度差异——查文档的速度、写代码的速度、处理重复劳动的速度。它抹不平的是判断力，是那个在脑子里已经建好的、知道什么情况下什么方案靠谱什么方案不靠谱的坐标系。这个坐标系没有捷径，就是靠时间堆出来的——读书、上课、做实验、踩坑、改错、再做一遍。

学习还是有意义的

本科四年最大的价值，可能不是教会了哪门具体的课——大概率毕业没几年就忘光了。最大的价值是在脑子里搭了一个框架，让你遇到新问题的时候知道该往哪个方向找答案、怎么判断找到的答案对不对。外行人没有这个框架。AI 给不了这个框架。它只能给答案，给不了判断答案对错的能力。不仅如此，它还会给一种信心——让你误以为自己已经有了这个能力。这种误信比无知更麻烦，因为它让人敢于在自己完全不了解的领域里做决策。

人对世界的认知本来就很局限。地球科学搞了几百年，对自己脚下这颗行星的了解也只是个大概。人能采样的范围就那么点，钻孔能打下去的深度就那么浅，地震波反演来反演去也就是个模糊的影子。人在自然面前还渺小得很，别太把自己手里的统计模型当回事。

预览时标签不可点

Name cleared

微信扫一扫赞赏作者

Like the AuthorOther Amount

赞赏后展示我的头像

作品

暂无作品

Like the Author

Other Amount

最低赞赏 ¥0

Back

Other Amount

赞赏金额

最低赞赏 ¥0

基础知识 · 目录

基础知识

上一篇高校教师建议大学新生和家长都应该尽早防范的几种常见思维误区下一篇大学里是不是什么都学不到

搜索「」网络结果

调整当前正文文字大小

100%

高校教师建议大学新生应该尽早防范的几种常见的思维误区

2026-07-05T00:00:00+08:00

孩子要读大学了，就得让他尽快成长成大人了，说话做事都要更清醒。

有时候孩子们容易陷入的一些思维误区，可能还有家长身上的影响因素。

什么强加因果、比烂思维和逻辑塌方等等就不说了，这回咱们说些具体的。

急于证明自己是对的

最常见的坑，就是急于证明自己是对的，为这事浪费一大堆时间。

你要把时间都花在证明自己对上，反思的时间就没了。可有时候你也未必那么对，有些新东西本可以去考虑、去补充，但你没注意，光顾着跟人较劲自己没错。时间是真金白银，这么花掉可惜了。

甚至有的时候一上头可能一连几个小时去跟人在线对线论战，就算是逞了口舌之利赢了又能如何呢？浪费的时间精力是追不回来的。

错了还嘴硬

比上面更糟的是，自己明明知道错了，还嘴硬。

人天性就不喜欢自己犯错，错了不愿意认，总想推卸责任。即便认了，也得补一句"不怪我，是别的原因导致的"。让他干干净净承认一句"我错了"，比登天还难。

孩子容易这样，往往是因为大人也这样。大人总爱摆出一副啥都知道、啥都有正确答案的做派，不想让自己的形象变差。他觉得自己一旦跟孩子承认有啥事不知道，威严就扫地了。结果孩子有样学样，也变得特别固执。

其实不管是人还是别的什么动物，犯错都再正常不过。记忆会出错，行为会失控，再高的高手都可能玩脱。认错是个很基础的事，不认错就不可能进步。你不承认问题存在，就没法解决问题。

从众和从来如此

"别人都这样，那我也这样。""从来如此，就这样。"

这俩说法都没来由，都不是理性的人该有的态度。该做的是根据自己的理性判断，把资料收集齐，权衡好利弊，再做判断。

当然，不重要的事另说。中午吃啥，你没必要费这么大劲选。

迷信权威和名人

一个很有名、很权威的人说了啥，不见得就该信。

一个人赚了很多钱、很有名，他说啥你就信了，觉得信了也能赚那么多钱，这也不见得。就像有人坐电梯到了很高的楼层，你问他怎么上这么高的，他未必意识到自己坐了电梯。时代红利、运气这些外部因素，他都不愿意往外归因，他容易归因到自己身上——说是因为我健康饮食、每天喝八瓶水。这种话能靠谱吗？

有的包装非常好看的「天选之人」结果被证明是精致的骗子。

成年人不该再上这种当。

学术上的权威也别盲信

就算是学术上的东西，很多人引用一篇文章、很多人说真对真对，也不见得就该信。

当年心肌干细胞那事，很多人是真的做出那些结果吗？还是自己不敢去质疑权威？这不好说。

还有当年一些企业赞助的研究，比如某些碳水化合物类的厂商赞助营养和健康方面的研究。你要是说碳水化合物摄入过量对人害处大，你就拿不到赞助。能拿到赞助的，方向就被变相操控了。这事能搜到，不是秘密。

所以绝对不能诉诸权威，那是扯的。

纠结细节而整体不通

还有一种，论证的整体框架都不成立，你却纠结于某个具体细节，跟人说"这个细节我很对，所以我全对"。

这就像画一幅画，鼻子、眼睛、嘴每个细节都画得很好，可整个比例不协调、位置全错，这画就是不行，细节再好也没用。

到了大学该诚实坦然

到了大学，千万得有这个意识：父母不是全都对，天底下没人全知全能。

也不要迷信各种权威，连科学本身都不要去迷信。

科学最重要的，是质疑，是探索，是好奇心和求知欲。

希望父母们，也能放下架子，认清现实，以尊重的态度，诚实地跟孩子沟通。

预览时标签不可点

Name cleared

微信扫一扫赞赏作者

Like the AuthorOther Amount

赞赏后展示我的头像

作品

暂无作品

Like the Author

Other Amount

最低赞赏 ¥0

Back

Other Amount

赞赏金额

最低赞赏 ¥0

基础知识 · 目录

基础知识

上一篇学习这件事，得先让孩子不恨它下一篇AI 能抹平外行和内行的差距吗？当前恐怕不行

搜索「」网络结果

调整当前正文文字大小

100%

软考高级系统架构设计师到底有没有用

2026-07-04T00:00:00+08:00

欢迎对软考感兴趣的朋友们订阅咱们这个合集：二手架构师杂谈

好像网上隔三岔五就能看到有人吵软考高级架构师有没有用，每次都能吵个没完。

这事儿吧，我觉得最没意思的两种极端就是：一种是我没考过，或者我考了没过，就一口咬定这东西一文不值，纯属骗钱骗时间；另一种是我考过了，就把它吹上天，什么含金量秒杀一切、有了它别的证书都不用看了。

这俩说法都挺扯的。

我自己是裸考挂过一次论文，后来又第二次过的。

第一次折在了论文题上，后来就着重备考这部分，参考软考系统架构设计师论文题备考思路指南

第二次考试就特别准备了一下，具体情况可以参考前文：复盘一下软考高级架构设计师的备考和应考过程

过了我也不觉得这就能说明多厉害，没过那会儿我也没觉得这考试是垃圾。

有它的用处，也有它的局限，没必要捧到天上也没必要踩到地下。

架构师的这些考试内容，本质上很多就是计算机专业基础课程的那些东西。

数据结构、操作系统、网络、软件工程、数据库，这些玩意儿科班出身的同学大学都学过。可学过归学过，学完就忘的也不在少数。对教师来说，把这套东西再过一遍，其实就是一个把当年学过、后来可能又生疏了的知识重新磨练一遍的过程，温故而知新。

再说另一个角度：平时开发里用的东西，到了架构考试这儿，往往能给你归置到一块儿。

你写了好几年代码，缓存用过、消息队列用过、分布式库分表还有什么拉姆达架构等等也搞过，可这些经验散在脑子里头是零碎的，像一抽屉乱七八糟的零件。备考的过程，某种程度上就是逼着你把这些零件拿出来、擦干净、按类别摆好。什么影响性能、什么是可用性、什么场景该上微服务什么场景不该上、质量属性之间怎么打架怎么权衡——这些东西你平时可能也琢磨过，但没有一个框架把它们串起来。啃一遍教材，再对照着自己做过的项目想一遍，很多原来模模糊糊的感觉就清楚了。

这跟写年终总结一个道理，你不写不知道自己这一年到底干了啥，一写才发现哦原来我做过这些事儿。

所以这考试最大的用处，倒不一定在于那张证书，而在于它给你提供了一个契机，让你把经验和知识捋一遍，而证书是额外赠品。

还有一层我特别想说的，是检验和反馈这事儿本身的价值。

人做完了一些工作之后，总得有个渠道检验一下自己到底咋样。光自己闷头干，很容易陷入一种"我觉得我挺行"或者"我觉得我挺不行"的两极摇摆里，因为这俩感觉都没有参照系。考试就是这么一个参照系，虽然不完美，但好歹是个外部的东西，比你自己跟自己较劲强。

你考过了，至少说明在这一套知识体系的衡量下，你达到了某个线。你哪科没过，至少说明那块儿你确实差点意思。这种反馈是实打实的，比朋友圈里互相点赞真实多了。

拿到一张认证，也是一个正向的闭环。你学了、你练了、你检验了、你拿到了一个被承认的东西，这事儿就闭环了。

接下来不管你是想升职、想跳槽、还是想跟人聊天的时候多点底气，这张纸好歹能帮你撑撑场面。它当然不是万能的，可它也不是废纸。

最后说回它不完美的地方。

架构师考试覆盖的东西太广了，广到必然未必深刻。软考那套教材你翻一遍就知道，什么都要讲，可能就什么都没法讲透。

过了这考试，不代表你真就是个合格的架构师，顶多代表你在那套知识体系里达标了。

真正架构师的功夫，是在一个一个项目里练出来的，很多事情考试考不出来。

所以你要是问我它有没有用，我的回答是：有用，但没神化到那种程度。

你要是科班出身、基础扎实、又一直在一线干活，那备考的过程对你来说就是个把零碎经验归拢归拢的活儿，过了顺手拿个证，没过也知道了自己哪儿差点意思。

如果跟我一样非科班、半路转行、或者平时接触的面比较窄，那它就更值当了，等于逼着你把计算机基础的那些东西系统地过一遍，补上一块可能一直缺着的短板。

反过来，你要是已经是大厂资深架构、带过大团队、扛过大项目，那这考试对你来说确实意义不大，顶多锦上添花。你真不用靠这张纸证明自己。

至于把它说成一文不值，或者吹成秒杀一切的硬通货，那都是话术，跟这考试本身没啥关系。

除了考试本身，我倒想说说蕴含在备考和应考这个过程里的另一些东西。

两次进考场，有个现象挺触动我的，就是出勤率。

第一次我没具体数，但肉眼一看就知道座位空了不少，顶多坐了一半多点儿，差不多一小半的人压根没到。那会儿我自己备考也紧，没心思细琢磨这事儿。

等第二次去考的时候，我就特意留意了一下。那个考场名额是 50 个人，我数了一遍，到场的只有 24 个还是 25 个。等下午考完最后一场，再一看，就剩 20 个左右了，有人上午还在、下午人就没了。

这情况其实挺普遍的。你想想，考软考的大多数都是在职的人，毕业好多年了，甚至年纪挺大的。像我这种 40 来岁的在里面都不算最老的，还有看着比我大、50 岁上下的也在考。这种人有家有业有工作，考试那天遇上个项目紧急上线、家里有事或者出差赶不回来，太正常了。不是说人家就没坚持下来，很可能就是那天实在去不了。还有的人上午来了，咬着牙考了两场，下午实在扛不住撤了，也不稀奇。

这就引出一个挺有意思的事儿。网上老有人说软考通过率低，10% 上下，听着挺吓人，好像这考试难得要命。可你要是把我那个考场的情况拆开算，就会发现这个"10%"的水分不小。

50 个人的名额，实际到场 24 个，撑死 25 个，再扣掉下午弃考的，真正把三场考完的也就 20 个上下。这 20 个里头，假设最后过了 5 个——我说假设啊，实际可能不止 5 个——那 5 个人占的是谁的分母？是这 20 个完赛的人，不是那 50 个报名的人。5 除以 20，那是 25%。这通过率是不是就高多了？

当然就一个考场看，样本太小，不能拿来一概而论。可这个思路是可以参考的：那个 10%，是把报名没去的、上午来下午走的，全算进分母了。真正从头坐到尾的人里头，过的比例没那么低。

所以这考试也没必要神化成什么难如登天的玩意儿。它难不难？有一定难度，特别是论文那科，没准备过体例的人头一回确实容易抓瞎，我头一回不就是栽这上头了么。可要说它难得吓人、通过率惨不忍睹，那也不至于。你真坐到考场里把三场考完，比你想象的容易些。

说回到这个过程本身。我后来琢磨，这事儿给我的启发倒不只在架构知识上。你在一个 40 多岁还能往考场里扎、50 岁的人也还在考的环境里头坐着，本身就有股劲儿。这帮人不是为了拿证换个好工作，多数人早就过了靠一张纸找活儿的年纪了。可能图的就是个不让自己停下来、不想就这么混下去的心气儿。

人最容易丢的不是技术、不是学历，是这股心气儿。考个试、啃本书、把一摊零碎知识整理下，看着折腾，其实给自己续这口气，让自己能够提起精神来应对考验。这种考试正好给了一个机会。光这点，我就觉得挺值。

再说说辅导班这事儿。

网上那些个机构，有几个挺大的，广告铺天盖地，刷短视频刷着刷着就蹦出来一个，跟你说不报班就过不了似的。那到底有没有必要报班呢？

我自己报过班，所以能说两句实话。我的感觉是，报班给我的帮助没那么大，远不如它收的成本高。真要说有用的部分，其实就是论文批改那一块儿，有人帮你看看格式对不对路、结构顺不顺，给个反馈。可等你搞清楚论文该咋写了，剩下的事儿——刷真题、背综合知识——自己干也完全能搞定，我心里是有底能考下来的。

更坑的是我还被一个所谓的"网红"坑过。这人在某些视频网站上挺热，免费那部分内容流量大、听的人多，他那私塾课堂就也有人跟着掏钱。可实际听了才知道，讲得属实不咋样，录音设备也差，滋滋啦啦的，内容也不太对路，好些地方讲得就不准确。这位也不是科班干这行的，半路出家搞开发，后来转去搞培训。咱就不点人名了，也不坏人家买卖，毕竟人家也是凭本事吃饭。但你要问我推荐不推荐，那我肯定不推荐。

我给大家的建议是：先刷真题。论文这东西呢，找几篇写得规范的范文看看，照着把那个体例摸清楚，自己先准备准备就行。复习的时候，把论文和案例分析的真题当主力，拿这些东西当抓手，复习到哪块儿了顺带把综合知识里对应的点记一记，该背的背，该刷的刷。三科虽然科目多，但每科考的难度其实都不算太难，深度也不深，就是抽象层次挺高，知识点铺得广。别被那套教材的厚度吓住，真坐下来啃，没那么吓人。

考过了能换啥呢？能兑换个副高职称。有些地方还有购房补贴、人才政策啥的。不过这种政策各地不一样，而且也不一定稳定，今年有明年可能就没了，参考价值不太大，别冲着这个去考。

主要是个经历吧。考过一回，拿着能当个谈资，跟人聊天的时候吹吹牛，也就这样了。

我当初考这个，其实动机挺朴素的：我本科不是学计算机的，总有人拿这个说我水平差、是外行。我就想着好歹考个级别高点儿的证书，证明一下自己在这行里是个合格的。可后来真考过了，慢慢也就想明白了：你过了这个考试，和你能不能干好这个活儿，它不是一码事，没有直接的必然联系。证书能帮你过简历这关、堵住一部分嘴，可真到了项目里，还是看你能不能把活儿干明白。大家理性看待吧。

最后说一句，希望这次没能上岸的同学，年底那回都一定能过。这东西一回不行就两回，没考过不丢人，中途有事儿没去成也不丢人。慢慢整，都能考到自己想要的那个结果。

准备了一些参考资料，分享给大家：

软考高级系统架构设计师知识精要-架构师专业英语高频词汇表原创

软考高级系统架构设计师知识精要-新兴技术与基础设施原创

软考高级系统架构设计师知识精要-系统安全与区块链技术原创

软考高级系统架构设计师知识精要-数据库与存储架构原创

软考高级系统架构设计师知识精要-软件测试与运行维护原创

软考高级系统架构设计师知识精要-软件架构设计与评估原创

软考高级系统架构设计师知识精要-系统建模与UML设计原创

软考高级系统架构设计师知识精要-软件工程与开发方法原创

软考高级系统架构设计师知识精要-信息系统与企业信息化原创

预览时标签不可点

Name cleared

微信扫一扫赞赏作者

Like the AuthorOther Amount

赞赏后展示我的头像

作品

暂无作品

Like the Author

Other Amount

最低赞赏 ¥0

Back

Other Amount

赞赏金额

最低赞赏 ¥0

二手架构师杂谈 · 目录

二手架构师杂谈

上一篇架构是个什么东西，架构师又是干啥的下一篇计算机学科的同学尤其应该注重培养通识并且避免工程上的傲慢

搜索「」网络结果

调整当前正文文字大小

100%

速度	对应性能	物理本质	关系
最大航程速度 \(V_{R_{max}}\)	飞得最远	对应 \((L/D)_{max}\) (总阻力最小点)	\(V_{R_{max}} > V_{E_{max}}\)
最大航时速度 \(V_{E_{max}}\)	飞得最久	对应最小需用功率点	\(V_{E_{max}}\) 略高于失速速度

场景	使用速度	数值	原因
刚起飞/防止失速	\(V > V_{stall}\)	> 17.6 m/s	升力必须 ≥ 重力
最大航时(飞最久)	\(V_{E_{max}}\)	~19.5 m/s	对应最小需用功率
最大航程(飞最远)	\(V_{R_{max}}\)	~25.7 m/s	对应最大升阻比 \((L/D)_{max}\)
快速到达/巡航	\(V > V_{R_{max}}\)	> 25.7 m/s	牺牲效率换速度