普通视图

发现新文章,点击刷新页面。
今天 — 2026年4月17日未分类

Claude KYC上线:中国开发者影响解析

2026年4月17日 08:57
昏黄羊皮纸背景上的现代门禁闸机与一张写着 Claude 的会员卡并置,闸机前站着程序员模样的人影,远处是抽象化的云端机房和护照自拍提示界面,钢笔彩色手绘的统一风格。

Claude 也要做 KYC,也要做实名认证了。中国程序员们的天塌了吗?

大家先别急着骂 Anthropic 反蒸馏。你以为他这次真正想打击的是蒸馏他模型的人吗?其实未必。真正先被打击的,可能是另外一类人。

一个健身房的比喻:Anthropic 真正在防谁?

一家老式健身房的前台与闸机,三类会员形成鲜明对比:有人偷偷记教练动作,有人疯狂刷器械并把会员卡递给别人代刷,另一个人办卡后转身离开,钢笔彩色手绘的统一风格。

设想一个场景:有一家健身房。

  • 第一种人想自己开健身房,于是进来偷师,报了所有课程,跟健身教练学完以后,回去自己开健身房。
  • 第二种人办了健身卡进来,把所有羊毛都薅干净。我这个健身卡是一年的,我就天天来;我来不了的时候,还找别人替我来,一定要把所有能用的都用完。
  • 第三种人是花了钱办健身卡以后,再也不来了。

那你说,健身房最喜欢哪种用户?肯定喜欢第三种。你交了钱,再也不来了。

第一种人防得住吗?其实防不住。这一次真正去防的,是中间这种:办了健身卡,就一定要把所有便宜都占干净,自己来不了还要让别人替自己来。要干掉的是这帮人。

所以大家想明白了没有?他并不是惦记着去搞那些蒸馏的人。第一拨人,就是跟着健身教练学,学完以后回去自己开健身房的人,这才是蒸馏的人。这些人你防不住。为什么防不住,待会再讲。

这一次 Anthropic 干的事情,其实就是健身房升级了门禁系统,保证你必须是同一个人来,保证不会有人用一张健身卡多人进入,要把这种用量打下来,尽量让“花了钱不来的人”多一些。这才是真正的意图。

至于反蒸馏,跟这次有关系,但关系真不大。它最大的关系,可能就是这次行动的一个借口,其他其实没什么意义。

为什么这件事会炸锅?

笔记本电脑屏幕上弹出身份验证窗口,要求上传护照和实时自拍,桌前的中国开发者神情错愕,旁边散落着代码稿纸、信用卡和翻译便签,钢笔彩色手绘的统一风格。

这个事情出来以后为什么炸锅了?因为现在 Claude 开始出现身份验证弹窗了。有些人确实已经弹了,要求提交政府证件,也就是护照、身份证这些东西,还要进行实时自拍,做人脸和证件核验。

社区里的第一反应就是:完了,Claude 也要做实名制了,中国程序员以后别用了。

一般讲 KYC,通常是在币圈里讲,叫 Know Your Customer,也就是平台核实用户真实身份的一套风险控制机制。

在 Claude 里,中国开发者一定占极大比例。因为本身中国开发者就多,而且中国开发者又愿意去用最好的模型。虽然国内也有些模型能用,但我见过很多开发者都跟我说,你自己的时间是有价值的,一定要买最贵的。因为模型的差价,对于模型质量来说,基本可以忽略不计。所以一定要用 Claude。

前几周我跟姜变做节目时,他的“龙虾”挂的就是 Claude Opus 4.6,买的是 200 美金套餐。他给我的解释就是:我一定要买最好的。

现在在 Claude 里,用量最高的一些人,实际上很多都是中国人。第一个人好像叫刘小排,也是我以前猎豹移动的一个同事。这些都是能登上全球榜榜首的人。那自然就一定要“收拾”你们,因为这是一帮特别喜欢薅羊毛、用量特别高的人。这样的用户,健身房不欢迎,Anthropic 也不欢迎。

时间线:Anthropic 如何一步步收紧

Anthropic 在 2025 年 9 月就开始收紧中国 API 的访问了。

2026 年 2 月,Anthropic、OpenAI、谷歌三家公司同时指控中国实验室蒸馏。

2026 年 4 月 14 日,官方帮助中心更新了 KYC 说明;4 月 15 日起,用户将陆续收到弹窗。

更残酷的现实是,这个闸机很可能根本不认你的证件。因为他们找的第三方 KYC 机构,压根就不承认中国护照这些东西。你上去说我想验证,根本没人理你。

先把事实厘清:分三层来看

我们先把事实厘清,分三层来看:第一层是官方说法,第二层是事实认证,第三层是我的观点。

第一层:官方说法

一张摊开的帮助中心文档页,上面写着 identity verification on Claude,旁边有放大镜、勾选框、IP 地址图标和护照照片框,像法务审阅文件的桌面场景,钢笔彩色手绘的统一风格。

先说官方说法。2026 年 4 月 14 日,Anthropic 官方帮助中心更新了一个名为 identity verification on Claude 的文件。

官方原文的措辞是:a few user use cases,也就是很少数的使用场景,不是全员强制。所以这是一种抽查,但具体抽到谁、没抽到谁,不会公布规则。

触发条件包括:

  • 访问某些高级能力,比如让它做破解、做一些危险的事情,或者一些色情相关内容,都可能被视为“高级能力”;
  • 例行的平台完整性检查,比如系统发现你的 IP 地址不对,或者一些跳转存在问题;
  • 其他安全与合规措施,描述得比较宽泛,具体怎么筛选谁来拍照片,并不会说得很清楚。

现在它要求你的证件、账号、IP 地址必须“三码合一”。你说我提供一个泰国证件,那你的 IP 也得是泰国的,账号申请地区也得是泰国,不能中间有叉,一旦有叉就可能被干掉。

API 用户方面,官方明确说明当前不在本轮影响范围内。也就是说,你开账号以后在里面用 API,这一轮没影响。因为 API 本身相对更贵,Claude 也贵。

这也是为什么我说,这次主要处罚的是薅羊毛的人,而不是那些上你这来学课程、回去准备自己开健身房的人。因为那帮人是 API 客户,这次跟他们没关系。至于以后会不会再收拾,不好说。

第二层:已经确认的事实

已经确认的事实是什么?

  1. Anthropic 帮助中心页面确实在 2026 年 4 月 14 日更新了 KYC 说明。
  2. 部分用户已经从 4 月 15 日开始收到 KYC 验证弹窗。
  3. Anthropic 同期更新了 unsupported regions 销售限制说明,明确点名中国,告诉你中国是不支持的区域。
  4. 2026 年 2 月,Anthropic 指控 DeepSeek、Moonshot AI,也就是月之暗面,还有 MiniMax,创建了 24,000 个虚拟账号,通过 1,600 万次 API 调用蒸馏 Claude。
  5. Anthropic 在 2025 年下半年封禁了 145 万个账号,力度非常猛。你可以申诉,但成功率只有 3.3%。所以封了以后,很多时候还不如再开一个,别费那个劲。
  6. 这次使用的是第三方 KYC 服务商,这也是 Anthropic 官方确认的。也就是说,你的姓名、护照照片、人脸这些信息,不会直接传到 Anthropic,而是交给一个第三方服务商处理。这个服务商叫 Persona,由它来做第三方认证。

问题在于,Persona 对中国大陆证件基本不支持。绝大部分中国大陆用户,没法通过验证。

更麻烦的是,Persona 在 2026 年 2 月因为服务器配置错误,暴露了 2,456 个文件,包括证件照片、生物特征和 IP 等信息。Discord 也因此终止了和它的合作。也就是说,这家公司本身的安全性也没那么让人放心。

另外,2026 年 4 月 16 日,OpenRouter 等代理渠道也出现了中国用户受限现象。什么意思?就是原来中国用户用中国信用卡充 OpenRouter,也可以用 Claude 模型;以后如果你是用中国信用卡充值的 OpenRouter,就不允许再使用 Claude 模型了。但这一块没有任何官方公告,就是直接给你封掉了,这也很奇葩。

第三层:我的判断

我的判断是,很多人把这件事理解为反蒸馏,这个说法只对了一半。反蒸馏是这次事件的借口,不是核心诉求。这次 KYC 的核心诉求是反薅羊毛。

Anthropic 喜欢什么用户,讨厌什么用户?

天平两端形成对比,一端是安静付费却低频使用的普通会员,另一端是跨区登录、共享账号、批量调用的高消耗用户,背景像客服风控面板与健身房月卡账本叠合,钢笔彩色手绘的统一风格。

从用户画像来看,Anthropic 最喜欢什么用户?稳定付费、低投诉、低风控、正常使用、不把额度打满。比如我交了 20 美金也好,交了 200 美金也好,我就老老实实用,用量还很少。就像去健身房交了会费以后再也不去了,这是 Anthropic 最喜欢的。

Anthropic 最讨厌的用户是什么?高消耗、跨区访问、账号关系复杂、支付链路异常,可能共享、分销、转售,或者通过第三方工具批量接入。这些才是它真正想处理的对象。

蒸馏用户画像和羊毛党画像确实有重叠,但差异也很大。尤其是官方专门说了,这次不针对 API 用户,而 API 用户恰恰才是最像真正蒸馏用户的群体。所以从这个角度看,这事压根不是冲着反蒸馏去的。

这有点像苹果做隐私保护。苹果做隐私保护,表面上是保护隐私,实际上是为了把那些原本可以被挑挑拣拣的广告位重新卖出去。很多事情表面上一回事,实际上做的是另一回事。

我的判断就是,Anthropic 这次没有真正想搞反蒸馏,它要打的是羊毛党。就跟前段时间网飞打击共享账号是一个逻辑。

封号与 KYC:两件相关但独立的事

再说封号。首先要讲清楚一件事:Anthropic 是经常封号的。去年封了 145 万个号,申诉成功率 3.3%,说明它封号比例很高。

但这次 KYC 和封号之间没有必然联系。不是说我想封你号了,先给你做一次 KYC;也不是说做一次 KYC 就能申诉成功。这两件事是独立的。想封你,我就直接封;想让你做 KYC,你就去做,二者没什么联动。

已知的封号处罚条件

一块风控告示板上钉着多个标签:不支持地区、OAuth、数据中心 IP、高频 agent 调用、新账号新 IP、未满18岁,像侦探案板一样用红线连接到一个被封禁的账号页面,钢笔彩色手绘的统一风格。
  1. 不支持区域的访问和注册,比如中国用户访问。这个我自己就遇到过。我有一个谷歌邮箱,有一次忘了挂梯子,那个邮箱就直接废了。后来想救回来、想重新充值,根本不行,上来就是“这个邮箱被封禁了”,再也申请不开了。
  2. 第三方 OAuth 登录。比如玩“龙虾”的 OpenClaw、Harness、OpenCode,这些都是 Anthropic 明确禁止的。你现在用了,可能还没被抓到;但以后如果因为这个理由封你,也别去申诉,因为申诉时它也不会退你钱。
  3. 数据中心 IP 和非住宅 IP。因为我们挂梯子访问 Anthropic,梯子的 IP 很多都在云计算机房里。用这种 IP 去访问很容易出事。系统会识别你的 IP 是数据中心 IP 还是住宅 IP。所以现在很多人都在卖什么“固定住宅 IP”。至于这些 IP 怎么来的,大家自己脑补。
  4. 异常高频的 agent 调用,被识别为非人类行为。有些蒸馏行为会踩到这条。
  5. 新账号、新 IP、异常行为同时出现。很多人说“我这一直好好的”,那是因为你是老账号,用了很多年,一直在充钱。这样的账号即便 IP 有些跳动,通常也不太管你。但新账号、新 IP,一上来就可能秒封。经常能看到有人抱怨,刚封完一个账号,重新开一个,充了钱马上又被封,这种情况概率很高。
  6. API 探测和安全测试。虽然也会快速处罚封号,但碰到这种事的人其实不多,比如你做黑客测试,或者要求它做一些特别危险的事情。
  7. 未满 18 岁。如果系统跟你聊了半天,觉得你实在太幼稚,也有可能被封。

至于正常使用 Claude、很小心地用 Claude 的普通中国用户,其实还是可以继续用下去的。跟这次行动或者过往的封号条件,关系没那么大。

封号的典型特征

  • 无预警,多数没有事前警告邮件,直接就封,而且不解释。
  • 封号邮件通常不说明具体原因。
  • 有的时候会自动退款,但账号不恢复,这只是部分案例。
  • 新账号和新 IP 更容易秒封。
  • KYC 通过不等于免死金牌,通过 KYC 后仍然可能被封。

申诉与退款情况

申诉方面,确实有机制,但成功率很低,去年只有 3.3%。没有固定时限,也没有确认回执,大部分用户申诉之后都是石沉大海。你不能指望说我申诉了,24 小时、48 小时一定给我回复,不会的。你发了申诉信,没人理你,是正常的;有人理你,反而比较奇怪。现在也没有证据证明申诉必须先做 KYC,所以 KYC 和申诉也是独立体系。

退款方面,如果是政策违反,不退款。特别像我们在中国使用,就属于政策违反。

Anthropic 主动终止,也就是你没有违规,但我觉得你有些问题,又不想给你解释,就把你终止了,这种通常会按比例退款。比如你用了多少天,剩下的钱退给你。

申诉成功,一般是恢复使用,不会给你退款。自动退款但不恢复账号,也有部分案例。

所以我们有时候通过第三方购买 Anthropic 账号时,对方也会写清楚:如果 Anthropic 不给你退,我也不退;如果 Anthropic 退了,我可以帮你退一部分。

为什么中国开发者最疼?

一位中国开发者坐在深夜书桌前,屏幕分成支付失败、代理切换、风控警告、代码工作流中断五个小画面,桌上有咖啡、闹钟和多张虚拟卡,钢笔彩色手绘的统一风格。

为什么中国开发者最疼?大概有五层原因。

1. 地区问题

中国本来就不在 Anthropic 的支持范围之内,本身就是敏感地区。但中国人又特别勤奋,很努力、很认真地用 Anthropic 写各种程序。中国程序员数量多,而且又卷,所以这次封号会对很多中国程序员的个人账号造成影响。

2. 支付问题

大量中国开发者使用的是非标准支付路径,不是本地银行卡,因为中国银行卡本来就付不了,所以会用虚拟银行卡、代付、第三方平台充值等方式。这本来就在灰色地带。

而且虚拟信用卡代付里,确实有一部分会出现支付失败。以前我们做游戏就遇到过,用户先支付,过一段时间又申请挂失,说银行卡丢了,或者最后交割不过来。中国用户使用这些虚拟信用卡,也确实可能给 Anthropic 造成了一定经济损失,所以它也会倾向于把这些人筛出去。支付链路异常,本身就会触发风控画像。

3. 访问问题

代理 IP、时区异常、设备切换、网络环境异常,这些在中国用户身上都很常见。美国人该下班就下班了,我们一天 24 小时干。甚至有人在 X 上分享,半夜定闹钟起来,到 OpenClaw 上按个回车,把 5 小时额度刷完再接着跑。这种行为非常容易出问题。

挂梯子的人又经常换线路,没法保证统一 IP。对个人用户来说,这种正常使用场景,在风控系统里就是可疑信号。真正公司里反而不会有这个问题,因为公司会直接在美国 AWS 或谷歌云上租服务器,建立私有通道,IP 不会频繁变化。

4. 使用强度问题

中国人的勤奋程度太高了。把 Claude 当生产工具的开发者,调用频率和时长远高于普通用户。Anthropic 给你的套餐,本质上更像一个自助餐,它希望每个人进去礼貌地吃两口就走。哪像我们,进去以后猛吃猛造。

高频调用、长时间运行、复杂任务,在风控系统里绝对属于异常画像。越依赖 Claude 的人,反而越容易触发风控。

5. 替代成本问题

不是不能换 OpenAI、Gemini 或国内模型,而是换了以后,工作流会断,代码质量会下降,效率会受影响。对于程序员来说,他们还是更愿意用 Claude。

很多人劝我用 Claude,但因为我自己目前没有特别重的开发任务,所以我还在用 MiniMax、OpenAI、Gemini 这些模型,基本不影响我。但如果我今天突然有一个很重的开发任务,我也会义无反顾去买 Anthropic 套餐。

最讽刺的地方:不是不愿实名,而是你想实名都不让

最讽刺的细节是什么?中国用户对实名制本身一点都不陌生。因为在国内平台,都是要求实名认证的。没有任何一个中国 AI 平台会让你开账号充钱而不实名。

所以中国人对这件事太熟了。真正崩溃的点不是“怎么突然要实名了”,而是“我想实名,结果你不让”。不是平台要求我多走一步,而是平台把门装上了,但我的钥匙天然不兼容。这才是中国程序员最悲催的地方。

KYC 的真实效果边界:到底管不管用?

那么,KYC 的真实效果边界在哪?到底管不管用?为什么我说,对真正蒸馏它的人其实没什么用?

Persona 自身的安全记录并不让人放心

首先,Persona 的安全记录确实不怎么样。2026 年 2 月刚丢了 2,456 个文件,Discord 因此终止合作。我觉得 Discord 这一步做得挺对。

Persona 在 2024 年 9 月还出现过一次键盘记录漏洞,暴露了用户填写 KYC 时的内容。到现在到底修没修好,也不清楚。所以 Persona 本身就不是一个特别安全的 KYC 第三方机构。Anthropic 选它来做第三方,也被很多人嘲笑。

KYC 真正拦得住谁,拦不住谁?

一道狭窄安检门拦住普通个人开发者和共享账号用户,而另一侧大型海外实体、API 协议和组织化团队从更宽的企业通道通过,形成鲜明反差,钢笔彩色手绘的统一风格。

再说 KYC 对蒸馏的阻拦效果。它真正能拦住的,是低成本批量乱入的 VPN 用户、共享账号用户和虚拟支付用户。

而中国 AI 的这些大厂,不管是“四小龙”还是“六小龙”,你根本拦不住。人家是有组织、有预算的机构,不在乎省你这点钱。挂 API、按 Token 算,用海外实体签协议就行了。所以你想抓住他们,基本不现实。

这次真正能打击的是低门槛的灰产。那些 AI 公司本来就在海外有公司、做 VIE 架构,完全可以用海外实体开账号干活,没问题。

真正会被卡住的,更多是个人开发者,尤其是第一次开号的人。新账号很容易被拦住,但经过多层代理分散调用的路径,其实你也拦不住。所以即使现在我想继续用 Claude,我依然能用,不用太担心,只是会比原来贵一点。

KYC 的真正作用

所以 KYC 真正的作用是什么?

  1. 提高成本,把低技术门槛的滥用者挡在门外。
  2. 表达态度,在合规和舆论上展示“我已经尽力风控了”。Anthropic 的老大 Amodei 一直很喜欢出来表达态度,比如他说如果美国给中国卖 H200,就相当于给朝鲜供应核弹,立场是非常明确的,而且他在美国各大 AI 公司里算是最极端的一类。
  3. 用户筛选,把高消耗、低透明、高风险的用户尽量处理掉。

这就是这次 KYC 干的三件事。

但灰色市场不会因此被干掉,只是成本会增加。该干嘛还是干嘛。中国人翻了这么多年墙,币圈的人做了这么多年假 KYC,他这一个新手上来,除了表演一下行为艺术,不会有太多其他效果。

现有生态里,待认证、待开号、企业账号拆分、代理分销,在 KYC 之下依然可以继续,只是成本稍微上升。KYC 上线以后,代理的风险和利润空间都会上升。黑灰产会升级,但不会被消灭。

实际受害者的顺序,大概是:普通人先疼,然后代理涨价,黑灰产升级,真正专业绕路的人、真正蒸馏他模型的人,根本拦不住,也不是针对他们去的。

行业背景:美国 AI 大厂正在集体收紧

这件事还有一个行业背景:美国 AI 大厂实际上都在集体收紧。

2025 年 9 月,Anthropic 开始对中国方向收紧 API 访问。

2025 年 12 月,谷歌对抓取蒸馏和模型抽取问题发表过声明。当时它的 Nano Banana 刚出来,谷歌其他模型比如 Gemini 3、Gemini 3.1 算是能打,但和 OpenAI、Anthropic 比还是有差距。现在我用谷歌模型已经越来越少了,但他们家的生图模型绝对最好用,虽然不一定最漂亮,但最准确。

肯定会有很多中国模型公司去抓它的图片回来做升级。现在再看阿里的通义万相、字节的 Seedream 5.0,已经越来越接近 Nano Banana 的水平了。至于怎么追上的,我只能说纯属巧合,其他不知道。

到了 2026 年 2 月,Anthropic、OpenAI、谷歌几乎同期公开指责中国实验室蒸馏。三家还联合成立了一个叫“前沿模型论坛”的机构,共享威胁情报,说谁发现被蒸馏了,谁发现了什么问题,大家互相通报。

其实这三家本来都是死对头。OpenAI 当初就是为了对抗谷歌建立的;Anthropic 又是 OpenAI 叛将出来创办的。所以这三家能联合起来搞这个论坛,本身就挺不容易。

在这三家里,谁面对蒸馏和假账号的经验最丰富?其实是谷歌。它这么多年面对各种刷广告、SEO,经验丰富得一塌糊涂。如果他们三家真的认真协同起来,确实有可能降低蒸馏概率,或者提高蒸馏成本。但你说这三家能有多真心实意地合作,大家自己脑补就好了。

当前各家的状态

  • Anthropic:直接上 KYC 了,虽然是选择性的,只有很少一部分用例会遇到。
  • 谷歌和 OpenAI:自己并没有做类似的事情,只是发了公告,说了几句话,实际动作没有那么大。
  • 地区开放情况:谷歌目前其实还在稍微向我们靠拢一点,准备开香港地区使用,但好像香港 IP 挂 Gemini 现在还是有问题。在香港能正常用的,OpenAI 不行,Anthropic 不行,xAI 可以。谷歌宣称要开,但到目前为止似乎还没有真正打开。

闭源模型怕蒸馏,开源模型不怕

一侧是紧锁金属柜里封存的闭源模型卷轴,另一侧是摊开供人研读的开源权重图纸,几位工程师分别在复制、训练和讨论,形成开放与封闭的对照,钢笔彩色手绘的统一风格。

至于蒸馏,谷歌、OpenAI 和 Anthropic 这些闭源模型公司,肯定都不希望被蒸馏。但开源模型对蒸馏本来就不限制。

无论是 LLaMA、千问,还是国内的 MiniMax、GRM,你都可以直接拿权重去用,蒸馏根本不算什么大问题。真正不希望被蒸馏的,就是这些闭源模型公司。

总结:这次事件的三层表述

总结一下,这次事件有三层表述。

  1. 官方说法:这是少数场景下的身份验证,是安全与合规的一部分。
  2. 已经确认的事实:选择性 KYC 已经上线了;第三方 provider 对中国大陆证件支持有限;中国开发者的使用门槛确实被抬高了。
  3. 我的判断:表面上这是反异常调用、反蒸馏,底层更像是一次针对高消耗、低透明、跨区、高风险用户群体的筛选和清洗,本质上是反薅羊毛。

结论:中国程序员的天塌了吗?

阴天之下的城市天际线并未坍塌,只是通往 Claude 的桥梁被设了更高收费站和更窄车道,程序员仍背着电脑继续前行,神情疲惫却未停步,钢笔彩色手绘的统一风格。

最后一句:中国程序员的天塌了吗?还没有塌到不能干活的状态,但原来那条便宜、灵活、默认可用的路,确实不通了。

以后还能不能用 Claude?大概率还能用,就是稍微贵一点。代理代价会更高,路径会更窄,不确定性会更强,更多人可能会被封号。

普通人会更艰难,代理商会更挣钱,真正有组织能力的人,该蒸馏还是照样蒸馏,一点都拦不住。这才是这件事情最现实、最残酷的真相。

Anthropic 这次不是要堵住那些偷师的人,而是要先赶走那些把会员卡用得太狠的人。这就是这一次的故事。


背景图片

GPU 计算的起源

作者 bigwhite
2026年4月17日 08:20

本文永久链接 – https://tonybai.com/2026/04/17/the-origins-of-gpu-computing

大家好,我是Tony Bai。

在今天的人工智能时代,GPU 已成为数据中心的核心算力引擎,但它的崛起并非一夜之间的奇迹。ACM通讯文章《The Origins of GPU Computing》回溯了 GPU 计算的三十年发展史,揭示了从并行计算、图形系统到流处理等关键技术如何在政府资助的学术研究中逐步成熟,并最终汇聚成推动深度学习革命的基础设施。文章不仅梳理了技术脉络,也展示了学界与产业之间如何通过人才与思想的流动,共同塑造了现代 GPU 计算的格局。

本文是这篇文章的译文,供大家学习参考(格式有调整,更适合公众号阅读)。


政府资助的并行计算、流处理、实时着色语言和可编程图形处理单元(GPU)的学术研究直接推动了 GPU 计算的发展。GPU 被广泛应用于现代数据中心,并促成了当前的人工智能(AI)革命。生产 GPU 的英伟达(Nvidia)现已成为世界上最有价值的公司。这种计算变革及其产生的经济价值,得益于超过 30 年的政府资助研究。政府资助不仅有助于发展许多关键的技术创新,还培养了大量将这些技术带入行业的学生。

本文追溯了 GPU 计算的起源。我们首先描述了 GPU 计算所构建的技术(并行计算、并行图形系统、可编程着色器(shaders)和流处理)的发展,然后详细介绍了这些技术是如何转移到英伟达和其他公司,并最终应用于现代机器学习的。

赋能技术

GPU 计算建立在并行计算、并行图形系统和流处理的早期工作基础上。这些技术是通过超过 30 年的政府资助学术研究发展而来的。

并行计算

当你学习计算时,你了解到的是中央处理器(CPU)按顺序执行一系列指令。

实际上,芯片包含数十亿个并行切换并由导线连接的晶体管。开关和导线是物理计算机的基本构建块,它们同时运行。

此外,晶体管切换消耗的能量很少,而沿导线的通信消耗的能量要多得多。

通信需要功率来将信号从一点发送到另一点;功率随着距离的增加而增加,如果是在芯片之间进行信号传输,功率消耗将非常巨大。

虽然顺序计算机可能比并行计算机更容易理解,但顺序计算机必须通过同时切换的晶体管和同时传输信息的导线来实现。顺序计算机使用许多晶体管并行计算结果,然后仔细地以与顺序执行一致的方式组装这些结果。

创建这种执行是顺序的“幻觉”,在功率和性能上都是低效的。随着可用晶体管数量的增加,这种低效性也随之增加。在现代半导体技术中构建计算机的自然方式是设计并行计算机。GPU 比 CPU 更高效,因为它们是大规模并行计算机。

GPU 计算建立在并行计算的早期工作之上。与所有并行计算机一样,在 GPU 上运行的并行任务或线程必须相互同步和通信。

线程需要通信来使用由另一个线程产生的数据。同步是必要的,以在数据可用时发出信号,确保消耗的是正确的值。

并行计算、同步和通信的许多基础知识是由政府资助的学术研究开发的。由加州理工学院 Chuck Seitz 领导的 DARPA 资助的“宇宙立方”(Cosmic Cube)项目发展了并行计算的许多基础知识。在该项目上开发的硬件是英特尔 iPSC、Delta 和 Paragon 机器的蓝图,以及几台早期的能源部 ASCI 机器。“Cosmic-C”编程语言引入了异步消息传递和集合通信,后来以消息传递接口(MPI)的形式成为编程大型并行机器的标准。

麻省理工学院(MIT)的 DARPA 资助的 J-Machine 和 M-Machine 项目开发了用于通信和同步的低开销机制,以及现代互连网络的许多关键方面。这些机制使得并行性可以在非常细的粒度上被利用,最少只需 10 或 20 条指令即可作为一个可调度的工作单元。J-Machine 的许多特性被 Cray T3D 和 T3E 计算机直接采用。

并行计算有着超越这一特定历史分支的丰富历史。由于篇幅有限,我们无法进行完整的综述。Culler 等人的文章提供了一个很好的回顾。

GPU 计算与所有高性能计算一样,深受这一遗产的影响。它使用 MPI 进行节点间的通信,使用互连网络连接这些节点,并且在此研究过程中开发的许多通信和同步机制被用于协调并行计算。

并行图形系统

虽然不如传统的并行计算和超级计算机广为人知,但并行图形和成像计算机有着悠久的历史。

处理和生成图像需要巨大的计算量。例如,如果一台每秒处理一百万条指令的计算机(1MIPS)对百万像素图像的每个像素应用一次算术运算,计算机需要一秒钟来处理一张图像。

渲染电影和游戏中的 3D 虚拟世界比图像处理每像素需要的计算量大几个数量级。例如,为现代电影生成的图像每个像素需要大约十亿次浮点运算。因此,为了在实践中有用,图形和成像需要高性能的并行超级计算机。这些计算机在大规模数据集合上并行计算。

一个早期的 DARPA 资助研究项目是吉姆·克拉克(Jim Clark)在斯坦福大学领导的几何引擎(Geometry Engine)。

几何引擎促成了硅谷图形公司(Silicon Graphics)的成立,该公司率先开发了 3D 图形工作站。SGI 硬件架构和 OpenGL 软件库定义了现代 GPU 架构。

另一个值得注意的政府资助研究项目是亨利·福克斯(Henry Fuchs)及其合作者在北卡罗来纳大学领导的 Pixel Planes 系列高性能图形系统。事实上,Pixel Planes 5 是一台相当通用的单指令多数据(SIMD)计算机,它在 128 x 128 图像上运行并行计算。其他早期并行图形和图像计算机的例子包括 NASA 的大规模并行处理器(MPP)、Ikonas 图形系统和 Pixar 图像计算机。

早期 GPU 实现了类似于早期 SGI 工作站的固定功能图形流水线。当整个 OpenGL 图形流水线可以在单个芯片上实现时,英伟达引入了“GPU”一词。1999 年推出的英伟达 Geforce 256 由 1700 万个晶体管组成,是第一款商用 GPU。

在此之前,在皮克斯(Pixar)工作期间,Hanrahan 开发了 RenderMan,这是一个生成照片级逼真图像的系统。该系统彻底改变了电影行业,因为它能够生成可以与相机拍摄的实景无缝结合的图像。RenderMan 的一个关键组件是着色语言,它使用户能够扩展系统以模拟复杂的材质和光照。

虽然最初的 GPU 实现了固定功能流水线,但它们是由可编程组件构成的。不幸的是,这些处理单元因系统而异,因代而异。需要的是一种可移植的编程模型。由于 GPU 的主要应用是电脑游戏,因此将 RenderMan 着色语言适配到 GPU,以便游戏开发者可以创造新的光照和着色效果似乎是自然而然的。

在斯坦福大学的一个 DARPA 资助项目下,为当时的 GPU 设计并实现了一种实时着色语言(RTSL)。着色语言程序现在被称为着色器(shaders)。博士后学者 Bill Mark 领导了斯坦福 RTSL 的设计,后来加入了英伟达。他与另一位前斯坦福研究生 Kurt Akeley 一起增强了该技术,并创建了 Cg 着色语言。Cg 导致了微软 HLSL 和 OpenGL GLSL 的开发。

人们很快意识到,这些早期的着色语言足够灵活,可以实现科学计算中的许多算法。研究人员采用了诸如矩阵乘法、线性求解器、流体动力学求解器和分子动力学等算法在着色器上运行。这导致了 GPGPU(通用 GPU)计算运动的兴起。

流处理

DARPA 和 DOE 在斯坦福大学资助的关于 Imagine 流处理器和 Merrimac 流式超级计算机的工作发展了流处理,这是一种导致算术强度(计算与带宽之比)增加的并行计算形式。

如前所述,处理器消耗的大部分功率是在通信上。在芯片之间发送信号尤其耗电。芯片外通信也比芯片内通信慢得多。

流处理包含两个减少内存带宽需求的主要思想。

第一个是利用生产者-消费者局部性,使得一个阶段(生产者)将其结果转发给下一个阶段(消费者),而无需写入和读取内存。

第二个主要思想是将计算组织成称为内核(kernels)的函数。每个内核获取一个数据包,对该包执行函数,并输出另一个数据包。函数中的算术运算数量大于对内存的读写次数。这两种技术显著减少了内存访问次数,并提高了流处理架构的效率。

在流处理器中,计算被组织成产生和消耗数据流的内核。产生内核会将输出流写入流寄存器文件(SRF)。消费内核会从 SRF 读取输入,而数据无需写入或从内存中读取。通过适当的调度来匹配流的批处理大小与 SRF 的容量,这种组织使得应用程序能够维持非常高的算术强度(算术与内存带宽之比)。

一个设计和构建 Imagine 流处理器的 DARPA 资助项目于 1997 年在 MIT 启动,并于同年晚些时候转移到斯坦福大学。Imagine 是一台用于信号和图像处理工作负载的图形和媒体处理器。它由许多带有本地寄存器文件的并行算术单元、一个中央流寄存器文件和一个内存系统组成。内核从流寄存器文件读取流,通过本地寄存器文件传递中间结果,并将输出流写回流寄存器文件,供下一个内核读取。

Stream-C 编程语言被开发用于编程 Imagine。它扩展了 C 编程语言,增加了描述内核和流的构造。开发了众多的图形、信号处理和图像处理应用程序来调整和评估该架构。它在纹理映射光栅图形上的性能与当时的固定功能 GPU 相当。

在一次 DARPA 主要研究人员会议上,本文作者意识到这项技术可以应用于高性能计算,并构思了 Merrimac 项目。斯坦福 DOE ASCI 中心的计算机科学(CS)部分被重定向以追求这种高性能计算方法。该中心的年度报告提供了流处理发展史的详实记录。

Merrimac 架构被定义为将流处理适配到科学应用。与 Imagine 相比,主要变化是增加了科学计算所需的数据类型(如 FP64),将架构扩展到通过互连网络连接的多个节点以处理大规模问题,并增加了许多弹性特征,以支持在具有合理故障率的情况下进行大规模计算。

Stream-C 编程语言演变成了 Brook。Brook 背后的关键思想是将流编程的想法与更传统的数据并行计算合并。内核函数成为保持高算术强度的关键处理原语。

Brook 被适配以针对 2000 年代初的 GPU。这些 GPU 运行可编程顶点和片段着色器。着色器实现了内核,但指令数量有限且寄存器很少。常见的数据并行编程原语(如 map、reduce/scan、filter、gather 和 scatter)是通过在低级图形着色器之上构建虚拟数据并行计算机来实现的。这种抽象使得大量现有的并行算法可以在 GPU 上运行,并且早期着色器的局限性逐渐被消除。

早期利用内核执行高算术强度计算的一个很好的例子是稠密矩阵-矩阵乘法,它是现代神经网络算法的基础。在执行矩阵-矩阵乘法时,需要读取两个 n×n 矩阵并写入一个 n×n 矩阵。矩阵乘法需要 n³ 次乘加运算。因此,算术强度为 O(n)。这一事实众所周知,并导致了针对带有缓存的 CPU 进行矩阵乘法分块的有效方法。分块在 GPU 上运行时也非常有效。

斯坦福 ASCI 中心的数值科学家将几种科学代码移植到 Brook,以便在 Merrimac 模拟器上运行。这些代码包括计算流体动力学、磁流体动力学和 n 体模拟。n 体模拟是高效 GPU 应用的一个很好的例子。原子对之间的力由天体物理模拟中的引力定律给出,但非结合原子之间的相互作用由 Lennard-Jones 势(甚至更复杂的经验势)近似。这些函数需要许多算术运算。对于这些模拟,相邻原子存储在“邻居列表”中。分子动力学模拟立即成为 GPU 的主要应用。

GPU 和流处理器的一个关键特征是它们具有多种形式的硬件并行性。

每个 GPU 由许多核心组成。每个核心包含一个 SIMD 处理单元(通常为 32 宽)。

此外,每个核心都是多线程的。

回想一下,GPU 是为图形应用程序开发的,其性能取决于将纹理应用于三角形的效率。

纹理映射涉及计算三角形内每个像素片段的纹理坐标,然后使用这些坐标从图像中获取。这些纹理获取具有空间局部性,但时间局部性很小。空间局部性可以通过小型缓存来处理,但由于缺乏一致性,缓存无法处理时间局部性。

高效的纹理映射要求 GPU 隐藏这些纹理获取的延迟。早期 GPU 通过让片段请求纹理、挂起该片段的执行,并立即切换到处理另一个片段来实现这一点。这是多线程的简化版本,这意味着 GPU 需要有许多并行线程同时运行。任务总数是核心数乘以 SIMD 算术单元数(称为 warp)乘以线程数。Blackwell B200 GPU 拥有 384 个流多处理器(SMs)。每个 SM 有 64 个驻留 warp,每个 warp 有 32 个线程。因此,该 GPU 上有 786,432 个任务同时执行。

技术转移

流处理架构和编程系统通过人员流动从斯坦福转移到了英伟达。英伟达的一位架构师 John Nickolls 听说过流处理,并招募了 Bill Dally 在 2003 年为英伟达的 NV50 架构提供咨询。(NV50 于 2006 年作为 G80 发布)。流处理器的许多特性被合并到了该架构中。NV50 的“共享内存”发挥了 Imagine 和 Merrimac 中 SRF 的作用。

Ian Buck(Merrimac 项目的研究生和 Brook 的主要开发人员)于 2004 年加入英伟达。Ian 与 John Nickolls 合作将 Brook 演进为 CUDA。CUDA 合并了 Brook 和 Cg(一种图形着色语言)的最佳特性,并采纳了 Brook 程序员的反馈。关于该技术如何从斯坦福转移到英伟达的故事在一篇演示文稿中进行了描述。Mike Houston(该项目的另一位研究生)加入了 AMD,并直接使用 Brook 作为其 GPU 的编程语言。G80(NV50)和 CUDA 于 2006 年在超级计算大会上发布。

当 CUDA 于 2006 年发布时,很少有人了解并行编程,更不用说 GPU 流编程了。为了克服这一劳动力短缺,Wen-Mei Hwu 和 David Kirk 通过为教授讲授 CUDA 编程课程来推广 GPU 计算。参加这些课程的教师随后教授了成千上万的学生使用 CUDA 进行并行编程。从 Cosmic Cube、J-Machine 和 M-Machine 借来的并行计算技术既被应用于 GPU 内部(以协调多个 SM),也被应用于跨 GPU(构建多节点 GPU 系统以解决大型问题)。

赋能 AI

现代机器学习依赖于三个关键要素——海量数据集、具有许多层和权重的庞大模型,以及优化权重的计算能力。核心算法(深度神经网络、卷积网络、使用反向传播的训练和随机梯度下降)自 20 世纪 80 年代或更早以来就一直存在。大型标注数据集,例如 PASCAL 和 Imagenet,出现在 21 世纪初。最近的进展,例如将文本嵌入到向量空间中,使得自然语言深度学习成为可能。Transformers(“注意力就是你所需要的”)用带有历史记录的易于训练的神经网络取代了难以训练的循环神经网络。GPU 计算使得大规模数据集的网络训练在经济上变得可行。一旦展示了这种能力(Alexnet, GPT),AI 的能力就得到了迅速提升。AI 的快速采用为改进 GPU 计算系统提供了更大的动力。

英伟达的机器学习也得益于学术界与产业界的协同效应。2010 年,作者之一(Dally)与吴恩达(Andrew Ng)的一次早餐交谈促成了一个英伟达与斯坦福之间的联合项目,旨在 GPU 上构建深度神经网络。Bryan Catanzaro 领导了该项目的英伟达部分。在此项目中开发的软件成为了 CuDNN,它为英伟达 GPU 上的深度学习提供了一个现成的库——从而推动了深度学习的普及。

结论

GPU 计算背后的技术(已促成了现代机器学习)主要归功于 30 年的政府资助学术研究。

并行计算、并行图形系统和流处理的研究为 GPU 计算奠定了基础。在这些研究项目中培养的许多学生后来进入行业,转移了这些技术并利用其开发了创新产品。

从斯坦福流处理项目到 GPU 计算的转移非常直接,学术上的 Brook 语言演变为 CUDA,流处理器的功能被整合到 G80 GPU 中。

GPU 提供的高效、易于编程且性能极高的计算平台,通过计算着色器促成了当前的机器学习革命——提供了缺失的成分,以补充早已可用但一直缺乏计算能力的算法和数据。

资料链接:https://cacm.acm.org/federal-funding-of-academic-research/the-origins-of-gpu-computing/

关于作者

威廉·J·达利是美国加利福尼亚州圣克拉拉英伟达公司首席科学家兼高级副总裁,同时也是斯坦福大学电气工程与计算机科学的兼职教授。

帕特·汉拉汉是美国加利福尼亚州斯坦福大学电气工程与计算机科学的佳能荣休教授。


还在为“复制粘贴喂AI”而烦恼?我的新专栏 AI原生开发工作流实战 将带你:

  • 告别低效,重塑开发范式
  • 驾驭AI Agent(Claude Code),实现工作流自动化
  • 从“AI使用者”进化为规范驱动开发的“工作流指挥家”

扫描下方二维码,开启你的AI原生开发之旅。


你的Go技能,是否也卡在了“熟练”到“精通”的瓶颈期?

  • 想写出更地道、更健壮的Go代码,却总在细节上踩坑?
  • 渴望提升软件设计能力,驾驭复杂Go项目却缺乏章法?
  • 想打造生产级的Go服务,却在工程化实践中屡屡受挫?

继《Go语言第一课》后,我的《Go语言进阶课》终于在极客时间与大家见面了!

我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造!30+讲硬核内容,带你夯实语法认知,提升设计思维,锻造工程实践能力,更有实战项目串讲。

目标只有一个:助你完成从“Go熟练工”到“Go专家”的蜕变! 现在就加入,让你的Go技能再上一个新台阶!


商务合作方式:撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求,请扫描下方公众号二维码,与我私信联系。

© 2026, bigwhite. 版权所有.

兩岸視角下:台灣媒體的信任危機

作者 Wesley Lee
2026年4月17日 08:00
在當今全球資訊流動最為密集的區域中,台灣的媒體生態呈現出一種極度自由卻又充滿張力的奇特景致。要深入探討這種被外界戲稱為「媒體亂象」的現象,首先必須建立在對其核心參與者的科學篩選之上。 根據牛津大學路透新聞學研究所(Reuters Institute for the Study of Journalism)發佈的《數位新聞報告》,以及無國界記者組織(RSF)對亞洲媒體環境的長期觀測,我們選取了在台灣最具覆蓋力且具代表性的十家新聞媒體作為討論基礎。這些媒體包括

Rust 还没进前十,TIOBE 就开始唱衰了?

作者 bigwhite
2026年4月17日 07:36

本文永久链接 – https://tonybai.com/2026/04/17/tiobe-ranking-and-the-decline-of-rust-hype

大家好,我是Tony Bai。

过去几年,技术圈最热门的“猜谜游戏”之一,就是预测 Rust 什么时候能杀入 TIOBE 排行榜的前十。

这门被誉为“天选之子”的语言,连续多年霸榜 Stack Overflow“最受喜爱”的宝座,被微软、亚马逊等巨头奉为重写底层基础设施的“银弹”。所有人都觉得,它冲进前十,只是时间问题。

但就在最近,TIOBE 指数发布了 2026 年 4 月的最新排名。

榜单本身平平无奇,Rust 的排名甚至还从去年同期的 18 位微升到了 今年的16 位。

然而,TIOBE 的 CEO Paul Jansen 亲自撰写的一篇社论,却像一盆冷水,劈头盖脸地浇在了所有 Rustacean(Rust 开发者)的头上。

Paul Jansen 用极其明确的措辞,给这门甚至还没来得及摸到前十门槛的语言,提前下了一份“病危通知书”:

“Rust 的崛起显示出放缓的迹象。……它进入前十的梦想,现在看来比以前更加遥远了。”

这篇社论,瞬间引爆了全网的讨论。

无数 Rust 开发者感到匪夷所思,甚至有些愤怒:我们还没真正发力,你怎么就开始唱衰了?

这背后,到底是 TIOBE 对技术趋势的精准预判,还是这把统治了我们十几年的“认知标尺”,已经彻底失灵了?

今天,我们就来扒开这张榜单的底裤,看看在喧嚣的数据背后,Rust 的真实处境,究竟是怎样的。

官方的“诊断书”:Rust 的“阿喀琉斯之踵”

我们先来看看 TIOBE CEO Paul Jansen 的“诊断报告”。

他指出,Rust 在今年年初曾一度冲到历史最高排名第 13 位,但仅仅三个月后,就又跌回了第 16 位。

他给出的解释是:

“一个可能的解释是,尽管 Rust 能够生产出高效和安全的代码,但对于非专家程序员来说,它仍然难以学习。虽然专家们愿意投入时间去掌握这门语言,但更广泛的主流采用似乎面临着更大的挑战。”

这段话,精准地戳中了 Rust 社区最敏感、也最引以为傲的那根神经——陡峭的学习曲线

为了追求极致的内存安全,Rust 发明了极其复杂的“所有权(Ownership)”和“借用检查(Borrow Checker)”系统。这套系统像一个极其严苛的导师,在你编译代码的每一个环节,都对你进行着灵魂拷问。

无数新手在入门 Rust 时,都会经历一段被称为“与编译器搏斗”的痛苦时期。

TIOBE 的观点很明确:这种“精英主义”的设计哲学,正在成为 Rust “出圈”的最大障碍。

榜单的原罪:用“百度指数”去衡量火箭科学

TIOBE 的诊断听起来似乎很有道理。但我们必须先问一个更底层的问题:TIOBE 指数,到底是个什么东西?

TIOBE 的排名,本质上是一个基于“搜索引擎查询量”的指标。它在全球 25 个主流搜索引擎上,统计包含 +” programming” 关键词的页面数量。

看懂了吗?这套诞生于 十多年前的评判标准,在 2026 年的今天,已经变得极其荒谬

它衡量的是一门语言在公网上的“话题度”和“声量”,而不是它的“真实价值”和“商业应用”。

这就像用“微博热搜”的次数,去评判一位科学家的学术贡献一样可笑。

用这把“旧尺子”去衡量现代编程语言,会产生几个致命的认知偏差:

1. 越是难学、坑越多的语言,排名越高。

这恰恰是 TIOBE 逻辑最诡异的地方。Paul Jansen 一边抱怨 Rust 太难学,一边却忽视了,正是因为“难学”,新用户才会频繁地去 Google 搜索“Rust a lifetime that lives long enough”、“the trait Borrow is not implemented for String”这些令人抓狂的报错信息。

每一次“救命”的搜索,都在为 Rust 的 TIOBE 排名,贡献着宝贵的 KPI。

2. 越是成熟、生态完善的语言,排名越吃亏。

随着一门语言的成熟,它的文档会越来越完善,社区的最佳实践会沉淀下来。开发者遇到的问题,更多地会在官方文档、IDE 提示、或者小圈子的 Slack/Discord 里被解决,而不会产生大量的公开搜索。

没有问题,就没有搜索。没有搜索,就没有 TIOBE 排名。

3. TIOBE 无法衡量“生态位”的价值。

Rust 的江山在哪里?在 Linux 内核里(注:最近发布的Linux Kernel 7.0里,Rust已经正式转正了!),在 Windows 的系统组件里,在 Cloudflare 的边缘网络里,在 Figma 的渲染引擎里,在那些对性能和安全要求达到极致的底层基础设施里。

这些领域的开发者,是金字塔尖的系统程序员。他们讨论问题,是在 GitHub Issue、Zulip 频道,而不是在 CSDN 上问“我的 &mut 为什么传不进去”。

Rust 的价值,深藏在那些不会产生大量公开搜索记录的、高壁垒的硬核场景里。而 TIOBE 的爬虫,可能永远也爬不到那里。

真实的版图:Rust 正在经历一场“青春期的烦恼”

扒开 TIOBE 的“障眼法”,我们该如何客观看待 Rust 在 2026 年的真实处境?

Rust 并没有“增长放缓”,它只是在经历一场必然的“出圈阵痛”。

任何一门新技术的发展,都会经历两个阶段:

  1. 从 0 到 1 的“深耕期”:吸引最硬核、最狂热的一批早期用户,在特定的垂直领域里,将自己的核心优势打磨到极致。Rust 在“系统编程”领域,已经完美地完成了这个阶段。
  2. 从 1 到 N 的“出圈期”:试图将自己的影响力,扩展到更广阔的领域,吸引更多的主流开发者。

Rust 现在正处于从阶段一向阶段二过渡的关键时期。它那套为系统编程量身打造的、极致安全的内存管理哲学,在 Web 开发、数据科学、GUI 应用等场景下,确实给很多开发者带来了巨大的心智负担。

Rust 社区内部,关于是否应该为了“易用性”而牺牲部分“极致性”的争论,也从未停止。比如,关于异步运行时的分裂(Tokio vs async-std)、关于标准库的精简与扩充,都反映了这种“青春期的烦恼”。

Rust 没有停滞,它只是在“成长的十字路口”,在思考自己到底想成为谁。

我们真正应该关注什么?

作为身处一线的工程师,我们应该如何看待 TIOBE 的这份“诊断书”?

第一,永远不要把“流行度”作为技术选型的唯一标准。

JavaScript 很流行,但你不会用它去写操作系统内核。COBOL 极其冷门,但全球的银行系统依然跑在它上面,顶级 COBOL 程序员的薪资高得吓人。

技术的价值,永远取决于它在特定场景下,解决了多大规模、多高难度的商业问题。

第二,警惕“易用性”的陷阱。

Go、Python 很简单。但这种简单,可能是以牺牲“运行时安全保证”(比如Python 的动态类型、Go的Nil指针等)为代价的。

Rust 的“难”,恰恰是把所有可能在深夜引发线上雪崩的风险,全部前置到了编译阶段。它用“编译时的痛苦”,换取了“运行时的安宁”。

这种设计哲学,对于金融交易、底层基础设施、航空航天等“不容有失”的领域来说,是无价之宝。

第三,对自己的成长负责,而不是对榜单负责。

与其每个月焦虑地刷新 TIOBE 的排名,不如去问自己几个更本质的问题:

  • 我所处的行业,未来 3-5 年最核心的技术瓶颈是什么?
  • 为了解决这些瓶颈,我需要掌握哪些不可替代的底层能力?
  • 哪门语言的生态和哲学,与这个方向最契合?

你的技术护城河,从来不是由 TIOBE 的排名决定的,而是由你所处行业以及要解决问题的深度决定的。

小结:你的价值,与榜单无关

TIOBE 的这份榜单,与其说是一份严肃的技术报告,不如说是一场成功的“引流狂欢”。

它用一个看似客观的数据,精准地挑动了每个程序员心中最敏感的那根“身份焦虑”神经。

但作为身处一线的工程师,我们必须保持清醒。

衡量一门技术价值的唯一标准,从来不是它在搜索引擎上的热度,而是它在真实的商业世界里,解决了多大、多复杂、多有价值的问题。

当你在用 Rust 构建着下一代安全操作系统,或者用它重写着公司最核心的交易引擎时,你根本无需关心 TIOBE 上的排名是 16 还是 60。

因为你正在创造的价值,早已不是这些过时的“声量指标”所能衡量的。

你的技术栈没有背叛你,但你的认知,可能会。


今日互动探讨:

你觉得 TIOBE 对 Rust“增长放缓”的判断准确吗?你认为 Rust 陡峭的学习曲线,是它最大的优势,还是最大的障碍?

欢迎在评论区分享你的看法!


还在为“复制粘贴喂AI”而烦恼?我的新专栏 AI原生开发工作流实战 将带你:

  • 告别低效,重塑开发范式
  • 驾驭AI Agent(Claude Code),实现工作流自动化
  • 从“AI使用者”进化为规范驱动开发的“工作流指挥家”

扫描下方二维码,开启你的AI原生开发之旅。


原「Gopher部落」已重装升级为「Go & AI 精进营」知识星球,快来加入星球,开启你的技术跃迁之旅吧!

我们致力于打造一个高品质的 Go 语言深度学习AI 应用探索 平台。在这里,你将获得:

  • 体系化 Go 核心进阶内容: 深入「Go原理课」、「Go进阶课」、「Go避坑课」等独家深度专栏,夯实你的 Go 内功。
  • 前沿 Go+AI 实战赋能: 紧跟时代步伐,学习「Go+AI应用实战」、「Agent开发实战课」、「Agentic软件工程课」、「Claude Code开发工作流实战课」、「OpenClaw实战分享」等,掌握 AI 时代新技能。
  • 星主 Tony Bai 亲自答疑: 遇到难题?星主第一时间为你深度解析,扫清学习障碍。
  • 高活跃 Gopher 交流圈: 与众多优秀 Gopher 分享心得、讨论技术,碰撞思想火花。
  • 独家资源与内容首发: 技术文章、课程更新、精选资源,第一时间触达。

衷心希望「Go & AI 精进营」能成为你学习、进步、交流的港湾。让我们在此相聚,享受技术精进的快乐!欢迎你的加入!

img{512x368}


商务合作方式:撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求,请扫描下方公众号二维码,与我私信联系。

© 2026, bigwhite. 版权所有.

Codex Security代码审计初体验

作者 phithon
2026年4月16日 23:40

昨天申请并通过了OpenAI的个人认证,加上前段时间以开源贡献者的身份申请了OpenAI和Anthropic的赞助,分别获取了两家的max会员半年,我会写几篇文章,分别分享一下Codex Security的使用体验、Codex和Claude Code的对比、GPT Cyber模型的使用体验等。

image-20260416215809229.png

这篇文章先介绍一下Codex Security的使用体验,因为扫描额度有限,我只测试了几个仓库,...

写作风格的反建议

2026年4月16日 08:00
Dan Luu 在 [[https://danluu.com/writing-non-advice/][Some thoughts on writing]] 中提出了一个反直觉的观点:大多数写作建议本质上是在说"像我这样写",而真正重要的是找到适合你自己的风格。 * 四位博主,四种风格 Dan Luu 观察了 2000 到 2017 年间他社交圈中最受欢迎的编程博客作者:Joel Spolsky、Paul Graham、Steve Yegge 和 Julia Evans。这四个人在以下维度上截然不同: - 话题选择 - 文笔风格 - 文章长度 - 幽默类型(如果有的话) - 技术细节的深度 - 支撑证据的多少 - 细腻程度(nuance) 以长度为例,Julia Evans 和 Dan Luu 都从 2013 年开始写博客。到 2017 年底,两人的总字数相近,但 Julia 发布的文章数量大约是 Dan Luu 的十倍。 * 经典风格 vs 详实风格 Paul Graham 的写作属于 Thomas & Turner 在 [[https://amzn.to/3dRLMgR][Clear and Simple as the Truth]] 中定义的"经典风格"(classical style)。这种风格的特点是: - 文笔干净、直接、简洁 - 不呈现支撑证据,因为"真理只需要准确的呈现,不需要论证" - 作者呈现全知姿态,将经验结晶为永恒的、绝对的序列 Dan Luu 的风格则截然相反。他的句子往往冗长、蜿蜒,刻意包含结构化论证和证据,并附上适用性说明。他认为不加证据的陈述无法说服读者,他更希望读者了解他得出结论的理由,从而能在理由层面上同意或不同意。 * 风格来自目标,而非模仿 Dan Luu 认为风格应该从你的目标和天赋出发。他个人的写作目标包括: - 解释多数人不理解的技术话题(如分支预测、malloc、缓存分区) - 论证少数派观点(如文件系统不好用、上市公司薪酬其实很高、monorepo 并不蠢) - 做评测 - 讨论有趣的现象(如有趣的断裂点、知识转移的困难、偏差的正常化) 当你把"详细讨论"这个偏好与上述任何一个目标结合,得到的风格就和前面提到的所有作者都不同。 * 抄袭表面的失败 模仿他人风格之所以困难,是因为人们往往抄袭的是表面元素而非深层驱动力。 Natalie Wynn(ContraPoints)观察到抄袭她风格的人会堆砌华丽的视觉效果,却不理解这些视觉元素之所以存在是因为它们与主题有关联。她的建议是:"试着说点什么。" 实用射击领域的 Rob Leatham 说,学生模仿他握枪的姿势,却不知道那个姿势不是目标,而是其他动作的结果。 Brian Enos 回忆自己最初盲目模仿当地最佳射手的姿势体系,练了一两年后发现那些姿势并不适合自己的身体结构和态度,最终从各种射击风格中汲取灵感,形成了自己的方法。 Dan Luu 舞蹈教练的抱怨也类似:学生会问左脚应该交叉在右脚前面还是后面,但真正重要的是脚的位置是否合理,这取决于人的重心如何移动。 更一般的规律是:不理解就抄袭,必然会抄到不重要的表面细节上。 * 写作过程的设计 Dan Luu 开始写博客时设定了以下过程目标: 1. *低启动成本* ——他观察到最常见的博客格式是只有一篇"我开博了"的文章。所以他没做任何研究就用了 Octopress(后来证明是个大错误,应该用纯 HTML 或 WordPress),但低启动成本的理念是对的 2. *通过每篇文章改进写作技术* ——不纠结于单篇文章的质量 3. *只在有值得发布的内容时才发布* ——他认为过程目标比结果目标更适合个人项目。固定频率发帖可能导致追求数量而牺牲质量 4. *写一个自己愿意订阅的博客* ——避免:拆分文章、标题党、重复炒同一话题、没有 RSS 5. *在自己的平台上写* ——他开始写博客时,Posterous 已被 Twitter 收购后关闭,Blogspot 被 Google 收购后严重损害读者体验。当时的热门平台 Svbtle 和 Medium 后来也各遭遇困境。不能信任别人的平台不会在你脚下消失或为了盈利而改变 * 写作方法的演变 Dan Luu 的写作方法经历了几个重要变化: ** 拆分优于合并 早期他担心单个想法不够有趣,会等待把多个想法合并成一篇文章。回头看,早期许多文章分开发布效果会更好。例如 2016 年关于薪酬的文章同时讨论了薪酬可能趋向双峰分布和程序员相对于其他高薪行业门槛极低,两个想法不应该捆绑在一起。 ** "显而易见"的东西值得写 他曾经回避写看起来太显而易见的内容。后来他改变了看法,许多最有影响力的文章恰恰是那些他曾经认为"太显而易见不值得写"的主题。 ** 大量使用案例 受 Ben Kuhn 的建议影响,他开始大量举例。大量举例能减少读者自行脑补出错误理解。例如他写过一篇关于"某项技能达到前 5% 需要什么水平"的文章,但给的案例太少,结果很多读者误以为国际象棋特级大师(实际水平远超前 0.1%)只是前 5% 的程度——读者用自己的想象填补了示例的空白,却填错了。 Jamie Brandon 也经历了类似转变。他早期的写作常常出现金句,但与真实世界的联系较松散。后来他转向聚焦具体示例,因为:(a) 非具体的想法很难证伪,容易自欺;(b) 让读者更容易吸收你试图传达的想法,而非某个表面相似但不同的想法。示例能把想法"钉"住,让它可以被正确检视。 ** 叙事连贯性 在专业编辑的帮助下,他更注重文章上下句、上下段之间的逻辑衔接,让文章读起来更顺畅。但他也承认这有极限——你没法让所有人都读懂。一个证据是:在 Reddit 或 Ask MetaFilter 上,如果一个提问包含两个条件,大量回答者只会看到其中一个就作答,完全无视另一个条件。既然很多人连一个简短的提问都不愿完整阅读,作者不可能靠优化文章结构来解决"读者不认真读"的问题。因此他的原则是:只为那些愿意认真阅读的读者优化文章结构,不值得为不认真的人浪费精力。 * 反馈的悖论 Dan Luu 对写作反馈的看法是: - *大多数反馈是有害的* ——本质上是"你应该像我这样写",往往只关注表面问题而忽略结构性问题,而且会把有自然美感的文笔变成平庸的"Strunk & White 体" - *对负面反馈的态度因类型而异* :对于"论证有逻辑漏洞"的批评,他非常认真对待;对于"这篇文章很无聊/没意义"的评价,他基本忽略——回顾过去,那些告诉他文章改变了自己人生的人最多的文章,恰恰也收到了最多的"无聊/没用"评价 - *他的解决方案* :雇佣了一位他尊重其写作和编辑能力的专业编辑,在文笔方面听从编辑意见;同时有一群信任的人审查文章的有趣程度和论证可靠性 - *识别坏反馈的方法* :观察一个人给别人反馈的质量。给你坏反馈的人通常给别人反馈也一样差,这样可以在几分钟内判断其反馈是否值得重视,而不必花几小时自我怀疑 * 灵感无处不在 当被问到灵感从哪来时,Dan Luu 的回答是:到处都是。他有大约一百篇已经基本可发布的草稿,如果算上脑子里构思好但没写下来的,数量要以千计。 他举了一个例子:最近开始玩 surf ski(一种皮划艇),几周内就产生了大约二十个博客文章想法——关于独木舟划桨的演变和设计(技术角度两篇,文化因素两篇)、皮划艇划桨设计(五六篇)、船体设计的技术方面(四篇)、文化历史方面等等。 不是因为他对皮划艇特别感兴趣,而是 *一切看起来都足够有趣,值得写二十篇文章* 。世界是巨大的、奇妙的,任何话题深入下去都有无穷的有趣内容——就像分形图案,不管怎么放大,都能看到新的结构。

文件充满了危险——Dan Luu 谈文件系统的可靠性陷阱

2026年4月16日 08:00
2019 年,Dropbox 宣布 Linux 版只支持 ext4 文件系统。Reddit r/programming(最大的英文编程论坛之一)上最高赞的评论是: #+BEGIN_QUOTE 我不太理解,为什么应用程序要直接支持这些文件系统?内核不是已经抽象了底层存储细节吗? #+END_QUOTE #+BEGIN_QUOTE 这不应该是操作系统的工作吗? #+END_QUOTE 大多数人觉得文件很简单——打开、写入、关闭,能出什么问题?Dan Luu 在 [[https://danluu.com/deconstruct-files/][Deconstruct 2019]] 的演讲 "Files are fraught with peril" 给出了令人不安的答案:从 API 到文件系统到物理磁盘, *每一层都有可能导致数据丢失或损坏的陷阱* 。 * 三层风险速览 ** 文件 API:安全写一个文件有多难 假设我们要把文件内容从 =a foo= 改成 =a bar= 。最直觉的做法是调用 =pwrite= 系统调用: #+BEGIN_SRC C pwrite([file], "bar", 3, 2) // 在偏移 2 处写入 3 字节 #+END_SRC 问题在于:如果在写入过程中崩溃或断电,你可能得到 =a boo= 、 =a bor= 这样的半写入状态——数据损坏。 要安全地写文件,需要实现一个"撤销日志"(undo log),并且逐步保证每个步骤的持久性和顺序: #+BEGIN_SRC C creat(/d/log) // 1. 创建日志文件 write(/d/log, "...[checksum],foo", 7) // 2. 写入原始数据和校验和 fsync(/d/log) // 3. 确保日志落盘 fsync(/d) // 4. 确保父目录记录了日志文件 pwrite(/d/orig, "bar", 3, 2) // 5. 修改原始文件 fsync(/d/orig) // 6. 确保修改落盘 unlink(/d/log) // 7. 删除日志 #+END_SRC 为什么每一步都不可省略: - 不加 checksum(步骤 2): =data=writeback= 模式下,日志文件可能包含垃圾数据,"恢复"时反而把垃圾写入原始文件 - 不 fsync 父目录(步骤 4):崩溃后日志文件可能不存在,等于没有保护 - 不 fsync(步骤 3、6): =data=ordered= 模式下,操作可能被重排序,导致文件先被修改、日志还没写完 而这一切只是在 ext3/ext4 一个文件系统家族内部的差异。换成 btrfs、ZFS、XFS,行为又有不同。 2014 年的一项研究对 Leveldb、LMDB、GDBM、HSQLDB、SQLite、PostgreSQL、Git、Mercurial、HDFS、Zookeeper 做了静态分析,发现 *除 SQLite 的特定模式外,所有软件都有文件 API 使用方面的 bug* 。这些软件的开发者已经比绝大多数程序员更了解文件系统了。 为什么 API 这么难用?本质原因是四个难题叠在一起: 1. *安全写文件面临的挑战和并发编程一模一样* ——你需要保证原子性、保证操作顺序 2. 文件 API 在不同文件系统、不同挂载模式下的行为还不一致 3. 文档不清楚 4. 性能与正确性有固有冲突。 =fsync= 同时做了两件事:barrier(防止操作重排序)和 cache flush(强制数据写入磁盘)。很多时候你只需要 barrier 来保证顺序,但 =fsync= 强迫你连带执行代价极高的 cache flush。2013 年的一项研究修改 ext4 加了一个只做 barrier 不做 flush 的操作,发现性能接近完全禁用 cache flush(即 unsafe 模式)的水平——说明 =fsync= 接口捆绑导致的性能惩罚几乎等于安全与不安全之间的全部差距。但大多数人无法自己改文件系统,只能在性能和安全之间妥协,而妥协往往意味着不安全 ** 文件系统:fsync 的错误处理几乎不可能做对 文件系统的错误处理经历了漫长的改进。2005 年的一项研究发现,大多数文件系统几乎丢弃了所有写错误。到 2017 年,Wesley Aptekar-Cassels 和 Dan Luu 重新测试,发现基本错误处理已有显著改善。 但 =fsync= 的错误处理依然是个灾难。在 2018 年 Q2 之前的 Linux 内核上,=fsync= 遇到错误(比如磁盘写入失败)时,错误很可能会被直接丢弃,甚至报告给错误的进程。即使在较新的内核上,=fsync= 报错之后的局面也很棘手: - *XFS 和 btrfs* :已修改但未持久化的数据会被直接丢弃,无法恢复 - *ext4* :数据不会立刻丢弃,但被标记为"未修改",文件系统不会再尝试写入;内存紧张时随时可能被清除 - *ZFS on Linux* :CPU 使用率飙升,系统可能挂起或不可用 PostgreSQL、MySQL、MongoDB 的应对策略是: *遇到 =fsync= 错误直接崩溃进程,让用户从最近的检查点恢复* 。这不是过度谨慎,而是因为在 Linux 上确实没有更好的恢复方法。 更糟糕的是 =syncfs= ——它 *根本不返回错误* ,意味着静默数据丢失。 这个问题也不限于 Linux。当 PostgreSQL 团队首次提出"fsync 错误时应该崩溃"时,开发者 mailing list 上的第一反应是: #+BEGIN_QUOTE 你一定在开玩笑……如果 [fsync 的当前行为] 确实如此,我们需要反击这种内核脑残行为。 #+END_QUOTE 但讨论完细节后,所有人都同意崩溃是唯一正确的选择。 ** 磁盘:厂商声称的和实际的内容 磁盘厂商在数据手册中声称的不可纠正错误率(UBER): | 类型 | 厂商声称的 UBER | |------|-----------| | 消费级 HDD | 1e-14 | | 企业级 HDD | 1e-15 | | 消费级 SSD | 1e-15 | | 企业级 SSD | 1e-16 | 看起来很可靠?1e-14 意味着每读 1e14 bit 才会出一个错。但 10TB HDD 全量读一次就是 8e13 bit——差不多就该出一个错了。读十几遍就几乎必然会遇到错误。 而实际观测值远比厂商声称的糟糕: - Microsoft 的研究观测到 SSD 错误率 1e-11 到 6e-14 - Facebook 的研究观测到 SSD 错误率 2e-9 到 6e-11 2e-9 意味着每 250MB 就可能出现一个不可纠正错误——比声称的值差了 50 万到 500 万倍。 SSD 的数据保持能力也不像想象中那么可靠。一块剩余 90% 写入寿命的 SSD 厂商声称数据可保持约 10 年,但接近寿命终点的 SSD 可能只能保持数据 3 个月到 1 年。Luke Leighton 测试了 6 款声称有断电保护的 SSD,其中 4 款在断电测试中失败——凡是 Intel 以外的品牌都失败了。 * 那些不管用的偏方 网上讨论"如何安全写文件"时,总有人提出各种"一个技巧就够了"的说法。Dan Luu 阅读了两千多条互联网评论后,总结了最常见的两种: ** "用 rename 代替覆盖写入" 做法是:先写入临时文件,再用 =rename= 覆盖原文件。理由是 POSIX 规范说 =rename= 是原子的。 问题在于两层: 第一,POSIX 说 =rename= 是原子的,指的是在 *正常操作* 下原子——要么成功要么失败,不会出现"重命名了一半"的状态。但崩溃时并非如此。崩溃可能发生在文件系统已经把新文件名写入了目录、但还没来得及删除旧文件名指向的数据的时刻。结果是:新文件指向的是不完整的内容,旧文件的数据也丢失了。大多数主流 Linux 文件系统至少有一种挂载模式会出现这种情况。 第二,=rename= 不保证按程序顺序执行。你可能先写入临时文件,再 =rename= 覆盖原文件——程序逻辑上是这个顺序。但文件系统可能先执行 =rename= ,再写入临时文件的内容。崩溃后你会发现:新文件存在,但内容是空的或旧的。 btrfs 是主流文件系统中唯一明确保证 =rename= 在崩溃时也原子的(仅限覆盖已有文件的场景)。但 2018 年的一项测试发现了大量原子性 bug——btrfs *声称*有这个保证,*实现*上却经常做不到。也就是说,即使你为了 =rename= 的原子性专门选用 btrfs,也得不到可靠的安全保证。 ** "只追加不覆盖" 追加写入也不保证顺序或原子性(已有多项研究证实)。相信追加是安全的是很多实际 bug 的来源。 * 实用建议 ** 用数据库代替直接文件操作 如果你需要可靠地存储数据,SQLite 是一个很好的选择。它是在前述研究中 *唯一* 没有文件 API bug 的软件(在特定模式下)。相比自己处理 fsync、undo log、checksum,让成熟的数据库来处理这些复杂性要可靠得多。 这不是说绝对不能用文件——但如果你在写一个需要降低数据损坏率的应用,优先考虑数据库。 ** 备份策略 鉴于磁盘错误率远高于厂商声称的数值、SSD 断电保护经常失效、文件系统 =fsync= 错误处理有缺陷, *定期备份是不可替代的* 。不要依赖任何单层保护。 ** 理解文件系统选择的代价 Dropbox 只支持 ext4 不是偷懒。支持多种文件系统意味着要针对每种文件系统的 bug 和特殊行为做适配,测试矩阵指数级增长。对于一家需要可靠同步数据到磁盘的公司来说,限制支持的文件系统范围是务实的工程选择。 如果有人告诉你"文件系统都一样,内核已经抽象了",让他们看看 ext4 三种 =data= 模式下完全不同的崩溃行为。
昨天 — 2026年4月16日未分类

反驳本质复杂性——Dan Luu 论为什么《没有银弹》错了

2026年4月16日 08:00
1986 年,Fred Brooks 发表了经典论文 [[http://worrydream.com/refs/Brooks-NoSilverBullet.pdf][No Silver Bullet]](《没有银弹》),论证程序员生产力的提升空间极其有限。他的核心逻辑是:编程任务中包含一层"本质复杂性"(essential complexity),这层复杂性不可能被任何技术进步所消除。然后用 Amdahl 定律推导——如果 =1/X= 的复杂性是本质的,那么技术改进最多只能带来 =X= 倍的生产力提升。 Brooks 在论文中明确断言:至少一半的编程复杂性是本质的,因此所有技术创新加在一起,最多也只能带来 2 倍的生产力提升。 Dan Luu 在 [[https://danluu.com/essential-complexity/][Against essential and accidental complexity]] 一文中对此提出了有力反驳。 * Brooks 预见了什么,又错过了什么 Brooks 的论证策略是对当时的各类工具逐一评估,声称它们要么无效,要么已经发挥了全部潜力。这个策略的问题在于:他低估了尚未出现的工具类别,也低估了已有工具的改进空间。 ** 高级语言远未到头 Brooks 把高级语言当作一个已经"开发完毕"的类别。事实是,论文发表后不久,脚本语言(Perl、Python)崛起,带 GC 的语言全面取代了手动内存管理。如今没人会为了写一个 Web 应用而选择 C——现代语言带来的生产力提升远超 2 倍。 ** 版本控制与 CI/CD Brooks 在 1995 年的补充文章中提到 Microsoft 每天构建一次,还质疑这是否有必要,因为 Bell Northern Research 当时是每周构建一次。 而现实是:90 年代 Microsoft 开发 Windows 2000(3000 万行代码、5000 人团队)时,连支持分支的版本控制系统都没有。他们通过复制整个源代码树来模拟分支,手动合并。5000 人的团队,好日子一天只能合并 100 个变更。 仅仅版本控制和 CI/CD 这两项工具的进步,对大型项目而言就远超 2 倍的生产力提升。 ** 测试工具与实践 Brooks 提到测试的重要性,但唯一想到的改进方向是"让初学者更容易测试的专家系统"。他没能预见到现代测试框架、模糊测试(fuzzing)、静态分析工具、valgrind 等工具的出现。 Ken Thompson 曾声称语言安全特性没用,Jamie Zawinski 则认为在紧迫的截止日期下自动化测试是浪费时间。如果用这种旧式实践去构建现代规模的软件项目——比如一个分布式数据库——大多数团队根本产不出可用的产品。 ** 硬件速度 Brooks 写道:"一个工作站能有效地利用多少 MIPS 呢?"他认为硬件速度不会再显著提升开发效率。 事实恰恰相反:更快的硬件消除了大量偶然复杂性。ggplot 这样的工具之所以能存在,正是因为计算机足够快,开发者不需要榨干每一分性能。如果机器慢几个数量级,大多数现代工具根本不会出现。 Dan Luu 用自己的工作举例:写一个 Presto SQL 查询扫描 100TB 数据,几分钟完成。在 1986 年,光是获得足够的计算资源来完成这个任务就需要大约 10 台 Cray-2(全球总共只生产了 27 台),更不用说编写查询本身了。 * 本质复杂性?在实践中毫无意义 Dan Luu 指出,在他做过的所有非平凡问题中,偶然复杂性都占绝对主导地位。本质复杂性的比例低到无法估计。 以日志解析为例:从几十万台机器 scp 日志、用 Rust 脚本解析几 TB 数据。整个任务的"本质"部分——理解问题、决定查什么——只占极小比例。剩余全是偶然复杂性:连接池管理、日志格式不统一、库的选择与配置、性能优化…… 以指标查询为例:写 SQL 查询扫描数百 TB 数据、用 ggplot 生成图表。这个任务在 1986 年根本不会被想象为"可解决的问题"——偶然复杂性大到超出了 Brooks 的想象力。 Dan Luu 的结论是:Brooks 所说的"本质复杂性上限",本质上是他想象力的上限,而非技术进步的真正边界。 * 为什么这类论证总是失败 Brooks 的论证模式并不新鲜。Cliff Stoll 1995 年在 Newsweek 上写文章嘲笑互联网的前景: #+BEGIN_QUOTE 远见者们看到的是远程办公、交互式图书馆、多媒体教室……他们说电子市政厅和虚拟社区将会出现。商业将从办公室和商场转移到网络和调制解调器上。 胡说八道。你的在线数据库不会取代每天的报纸……电子出版?试着在光盘上读一本书。你也不能把笔记本电脑带到海滩上。 #+END_QUOTE 把 Stoll 的话做个查找替换,本质上和 Brooks 说的是同一件事:技术的改变收到我们想象力的制约。 Dan Luu 还指出了 Brooks 论文的一个结构性问题:论文中多处论述相互矛盾。Brooks 一方面声称没有单项改进能在十年内带来 10 倍提升,另一方面又声称所有改进加在一起不能超过 2 倍——原文指出这两个主张虽然没有严格矛盾,但放在同一篇论文中令人困惑。更关键的是,论文各部分的推理无法组合使用:把一段的论点与另一段的论点放在一起,很容易得出荒谬的结论甚至直接矛盾。此外 Brooks 对"本质"与"偶然"、"语言"与"库"等概念的区分并不清晰,导致整篇论文无法自洽。 * 2022 年补充 Dan Luu 在 2022 年补充道:很多人为 Brooks 辩护说"他真正想说的是 X",但不同人提出的 X 各不相同。这恰恰说明 Brooks 的论文像一张罗夏墨迹测试——读者各取所需。如果论文的含义如此"显而易见",人们不应该对它的含义有如此多不同的解读。

青岛

2026年4月16日 19:24

我人生中有好几件难以释怀的事,青岛之行就在其中。其他的还有面试香港的大学、带爸妈去杭州旅行等,都是想起来就失眠的程度。不过好在时间可以治愈一切,我也创造了很多弥补的机会,所以现在来写这篇文章刚刚好。果然一切都是最好的安排,写完就翻篇吧~

计划

2023年夏天,我利用日本长假安排了8月12号到16号的五天四夜旅行,这也是第一次带上双方父母一起旅游的重大尝试。由于人数众多,我又希望大家可以住在一起,于是订了民宿。意料之外情理之中,民宿实际情况比网站照片破旧,但好歹能住。这里还是要感谢比我们更早到达的爸爸妈妈们,提前收拾好了房间。也是因为这次住得不咋地,后来我在三亚之旅安排了五星级酒店,算是一雪前耻了!

跟团一日游
跟团一日游
日期 计划
8/12 周六 到达青岛。地铁到五四广场,入住民宿,出门觅食(肯德基),饭毕散步回家早点休息(看灯光秀)。
8/13 周日 跟团一日游。两辆车,独立成团。不去最美转角,时间留给吃海鲜~结束后再去农贸市场买点海鲜带回家煮了吃晚饭。
8/14 周一 豆哥先回日本。
极地海洋公园(2号线海游路站B出口)。坡坡免票,爷爷外公外婆优惠,奶奶我全票。早点回家买菜煮饭给爷爷奶奶外公外婆。
8/15 周二 石老人海水浴场。超市买玩沙工具、租帐篷、带换洗衣服。嘀嘀打车回民宿。
8/16 周三 回家。

一些笔记——

极地海洋公园攻略
极地海洋公园攻略

不排队路线推荐
1、先去「球幕影院」(人很少!)
2、再去「深海奇幻馆」(人也很少!)
3、再去「海平线剧场」
4、再去「冰雪乐园」
5、最后去「极地海洋馆」
⚠️特别提醒:不着急、慢慢逛,我们平日营业至晚上8:30,周末营业至晚上9:00!

五四广场 晚上
奥帆中心
栈桥
金沙滩
海底世界 开船去奥帆
石老人海水浴场
 
居民区小吃店
 
防晒
拉肚子药
坡坡退烧药
 
撑伞
防晒帽
防晒霜
墨镜
防晒衣
 
身份证

赶不上变化

五天旅行砍头去尾,满满当当安排了三天,结果最后只完成了第一天。原因也是不可抗因素——台风,无能为力、无可奈何、无计可施、无所适从。豆哥由于工作关系只好改了航班提早回来,而我本来想着一拖五(一个娃四个老人)继续旅程,无奈彼时心力不足,最后搞到大哭收场,婆婆安慰我说没关系,下次再玩,这次就先各回各家。最后我爸妈自己组织剩余行程走了其他城市,然后按原计划日期回家,而公婆则改了航班跟我们一起解散。我和坡坡回程的机票钱还是婆婆出的,那也是我第一次在机场现场买机票,真的贵。我一边内疚一边心疼,但见婆婆不慌不忙气定神闲地把信用卡往桌上一放,我一下子就被那个气场折服了。是啊,最差不过就是这样的结果——没完成旅行,还多花了钱。这是我一直想要规避的结果,但无力的是当时的我无法做到。

朋友圈
朋友圈

一来我没有一拖五的自信,二来我跟豆哥的关系彼时陷入了比较困难的状况。其实并不是什么大事,就是豆哥那阵子太忙了,我们都没有好好相处。我心中委屈,本想借着这次旅行好好修复一下关系,结果遇到台风,可以说我的内心已经接近崩溃边缘。再加上是我提出的跟爸妈们一起旅行,如果我中途退出,等同于背叛了约定。于是在多重重压下我不知不觉把自己逼到了绝路,最终崩盘。现在回头看,是我过于勉强自己了,不想也不敢袒露自己的脆弱,硬撑害人呐!而且我还是习惯性硬撑,自己压根没意识到。

但还是留下了美好回忆

小鱼山顶
小鱼山顶

带四个老人旅行一直是我心中小小的愿望,因为我自己喜欢旅游,也擅长做旅行计划,所以乐于为之。而且爸妈们退休了,我们又不在身边,带他们出去玩可能是唯一我们能尽孝道的事了。第一次的尝试虽然状况百出,从结果上来看也挺失败的,但还是留下了很多美好的回忆。我真庆幸将包车游放在了第一天,虽然累,但以最有效率的方式了解了青岛这座城市。而更珍贵的是我们在小鱼山顶合影、在啤酒博物馆干杯、在民宿里打闹的瞬间,让我更加体会到家人的意义。

啤酒博物馆
啤酒博物馆

爸妈们的宽容抚慰了我的心,原来我在他们面前还可以做小孩,还可以出错,还可以脆弱。我也开始坦然面对自己的不够成熟,毕竟成熟诞生于无数次不成熟的经历之后。以前总感慨,小时候觉得天塌下来的事,长大后再看根本不算什么。所以人们才说时间是最好的良药,我就算成年了当妈了,还有很大的成长空间。也许这就是人生的乐趣,不确定性有两面,悲观看待是未知的恐惧,乐观看待是不被定义的无限可能。

最后以坡坡的无敌笑容为结尾。只要我们还会笑,就没什么困难能把我们打倒!

嘻嘻哈哈
嘻嘻哈哈

你得先学会生活 Chat with PY

作者 素生
2026年4月16日 19:04

时间:2026年4月7日

地点:青羊宫茶园

拜师时,老师说,你得先学会生活。当他请教老师教一些法门时,老师面露难色,你这样太刻意了,不好。

“越来越多科研的一些局部流程,还有整体的闭环都可以用AI”,可以从“原来比较狭窄的一些科学问题,扩大到非常丰富的科学问题上”,“对于很多人来说,AI,尤其是AGI的技术,也会进一步扩散到很多有基本科研素养的人的手里,使得很多不是科班的,或者不是这个专业的,都可以去做广义的research。”

“有一个案例,有一个人养的狗身上长了好几个肿瘤,他就跟AI去聊,想到了用mRNA编辑去给狗打针对性的疫苗,他研究出一个治疗方案,刚好一个实验室去承接,就给他做了个性化的疫苗,然后就把狗的癌症遏制住了,就是这两个月的事,一年两年前的AI可能局限在去看一些片子,但现在因为有更多的生命数据,或者更个性化的一些数据,结合更强大的AI,就可以形成非常多的解决方案。”“相当于,每个人都能成为一个黑客,可以成为科学黑客,进一步结合自己生命、生理性的数据,基因层的数据,还有记录性的数据过程,互动性的数据,关系型的记录,就可以成为自己生命的,life的黑客了。”

但其实在这里,我感觉到的,是心的重要性,心更加重要了,而不是黑客的过程或结果。

“成都的朋友说,他小时候成都的夏天一点都不热的,因为盆地有足量的水,每天蒸腾到天上去,水走不掉,晚上再下回来,他说小时候夏天晚上经常睡不着觉的,每天晚上都是暴雨,打雷的那种暴雨,现在还是缺水,很明显缺水,水质也一般般。”

“我觉得很有趣,很多都是来了成都之后才知道这些事情的,你不来,这些信息会离你很远,你如果不在,是完全看不见的。”

“上周有朋友过来,开年会,非要让我带她去人民公园,主要去看相亲角,我以为没啥意思,然后就看进去了,男的1600多,女的1600多,全公益的,信息就全挂在那儿”,“这是大数据啊,成都的平均薪资,国有企业上班赚多少钱,私有企业上班赚多少钱,工程师赚多少钱,平均薪资,哪些岗位挣钱多,全有了。”当然有钱有背景的,还有高端装备的工程师,成飞啥的肯定不用在这相亲哈哈。

(玄学,我的理解就是)“给一个外力,让这个人改变”,(反者道之动),“习惯、行为改变了,思考方式变了,人就变了”

“投资人的世界,有自己的一套语言系统和理解的系统,很多细分领域都是这样,创业做公司,公司治理时是一个结构,对外去跟投资人聊,是另外一个结构,投资人日常看的领域不同,他的思考角度和起手也就不一样,他下最终投资决定的那个关键的东西,也是不一样的。”“做企业就只能自己去一个一个试,可能要做一些针对性的调整,应对不同场合。这是现实中复杂的地方。”“所以都说,要找理念契合的投资方,这样的钱,这样他才能陪你更长时间。”

“你想把投资人从他的那个语言体系里面拉出来,该用你的方式思考是不可能的,只有极少数的投资人能做到。”

“比如选择to B还是to C,就是完全两种路线,等于是在决定你要讲哪种语言,决定你是学韩语,还是学意大利语,完全两种语言,两种体系。”

“很多时候你的客户是个黑盒,你需要做实验才能了解他们。人就是这么成长的,你不犯错的话,是不可能成长的。没有经过实验和失败就没有判断力。自己的判断力一定是跟特别具身的线索相关的。”

“Andrej Karpathy的博客就讲过,他自己做自己的实验,跑在自己的服务器上,让AI在解决新问题的时候,去调用已经有的成功结果,去复用,他的这个分享非常值得学习的,每个人都是这样,这样做自己的实验,因为每个人的目的不同,每个人的感知不同,依照自己的感知去做实验,然后把实验结果自己记录好,后面把它们拼凑在一起,形成一个更大的模型,去做想做其他东西,因为不可能所有人解决问题都是用同一套解决方案,对吧?每个人都有不同的方案,但前提是你对所有的模块都很了解,这样组合起来才有芒格说的那个Lollapalooza效应。”

“每个人都有,一定有,但问题是很多人从来没有积累过、记录过。”

“前阵子我才明白很多卖茶的地方怎么赚钱,为什么能一直在一个地方待着不动,其实他们每年都有段时间不见人的,出去找茶的。前两周有春糖会,四川有全国70%以上的白酒产量嘛,这个春糖会规模大,要开十天,前几年更火,春糖会期间酒店都是大涨价的,订不到房间的,这么贵还要来成都参加这个展会,说明是必须来,关乎到赚钱的,可能一个展会下来,一年的酒就卖光了,就是这个意思。”

“关键是不同批次的酒,不同地方的酒,味道不一样的,要用这十天来找自己的客户的,茅台不用,茅台只参加最后几天的展会,前几天的酒店展会茅台不参加,为啥,因为他不愁卖嘛,酒啊茶啊,这些都是非标品,原料、环境、气候都会有影响,最终你是要来给非标品找买主的,时间短了肯定不行,必须要尝的,要思考后再决定的,遇到了合适的买主,一个批次就会被人全买走。前几天我老丈人跟我说,他在大连嘛,有那种卖散酒的店,店里好几缸大酒坛子,正常卖肯定一年都卖不掉,但后来突然有一天,他发现有一个缸空了。人家就是这样赚钱的,一年的钱都赚完了,这是一种商业模式。”

“但他要知道他的客户喜欢什么,然后去找那种酒或茶就可以了,两边都要知道怎么卖掉,谁可能会买。非标产品就得找非标的大客户。”

“有个以前的同事后来做字画生意的,也是每年去找画家看画,看好的就一次性买下全部库存,然后帮画家做推广。”

“他就独占这个稀缺性。”

“这不就是股权投资吗?刚才说的,跟创始人要遇到那个合适的投资方是一样的,融资谈了一年,但谈到了一个合适的,他会跟你一起,跟你一起未来的承担风险。”“不过跟卖酒还是不一样,他是一次性的,属于一个销售和贸易行为,股权投资是属于合作性的,因为我给你投资,我还帮你分担风险,这风险本来是全在你身上的,但我投了钱进来,就有风险转到了我身上,你就相当于把风险零售了,零售给别人了。”

“其实相当于你讲了一个故事,他投资参与到了这个故事里面,成了一个参与者。买单了你这个故事。然后你的故事发展的好与坏,反过来也决定了他自己这个钱的未来。”

“我感觉现在AI的下半场都在用认知科学的东西。”

“AI输出的内容,它是外化的一个东西,它在试图让你理解一个东西,但是它是另外一套东西,它仍然没有本体性。”

“但我觉得你看个人在用这些东西的时候,其实就是在实践认知科学。机器的强大,更加彰显出来人的局限性,或者人的思考能力有一些边界,你得顺应它,你得省着点用,你得珍惜它。”

“但人有很多灵性的东西,就是很难用语言形容出来的东西,是很微妙的。你可以用认知科学的东西去类比这些东西,但是没有办法完全表达出来,我就感觉现在去读一些小说呀,诗歌啊,都反而比以前更有价值。”

“比如真实的,拍纪录片,拍比如宫保鸡丁怎么做的,很早以前很多纪录片的导演就在讨论这件事情,这个东西是最值得记录的,为什么没有人去记录。一道菜到底怎么做,可能能录1000种做法,但它能反映出每个人的不同特质。这会很奇妙。这是过程的记录。”

“对,我们做茶,我就发现不同的道士,青城山上的,他们都各有一套,包括采叶的方式,清明那几天不能吃肉啊,还有不能化妆,这都是前人的实验,实验下来的结果。”

“是啊,所以所有已然存在的东西,每一个都那么有意思。”

“我家楼下那些鸟,我觉得性格都差别很大的,有的鸟我都能认出来,就是你要长期地看它啊。你得投入大量的时间精力,一些面貌才能呈现出来,甚至可能是从来没有人记录过的东西,可能有古人做过,但没记录过。”

“群体层面的分布也就是钟形曲线,个体尺度的发育过程也就是前额叶成熟峰值,横向看人是分布,纵向看人是轨迹,但AI让这种原始的分布出现了松动,越来越多的人得以跳出这个原始分布了,成为life hacker,nature hacker。”“原来我们可能是个非常非常陡峭的分布,现在呢,可能一方面它更陡峭了,峰值可以更高,但另一方面,它腰部的这一部分人,从规模上和多样性上来说也会越来越丰富。”

“我最早跟一个朋友总聊,就说AI最好的一点,就是它是作为黑盒子的大模型来说,最好的一点是,它里面暗含了所有的方向,所有的向量,就跟易经一样,所有的方向上都有分布,所有的信息都在里面,之前大家会讨论,怎么问出一个好问题,现在讨论这件事的人变得少了很多,但这永远是最重要的,就是所有的向量都在里面,你怎么把那个方向提炼出来。”

说到这里其实很像在图书馆里找书,找到一本就可以找到一片。

“随机性的那部分,更多是在我的身体里,在我的脑子里,随机性以外的东西,我可以从那里面提取出一些东西来。”

“AI只能判断你现在的向量方向,但他没有办法去收集你的所有向量,你的丰富度是难以想象的。” “这样你才能跟AI等量齐观。”

“人的多样性还是很美妙的。大家在这种工具的辅助下,就可以在一些方向,个性化的方向上,或者跟自己的场景,跟自己的上下文,跟灵感和随意性密切结合的方向上,可以走的特别特别远。不要把人的多样性给锁死。人需要在生活里看到更多的关系,在自然里看见更多的关系。”

“你刚才提到有一个感触就是怎么让人更自由,其实人还是要站在地上的,但是大模型是一个二层楼,意思就是人已经蹦不上去了,爬也爬不上去了,它确实比人高,但人可以上去。仅仅二层楼,就已经可以让平地上的人看到不一样的风景和视角,反过来会影响人的未来。AGI呢,可能是一栋非常高的这种摩天大厦,人就可以看到全景的东西,或者接近全景的东西。反过来你还是可以随时在地面或二楼的,甚至是各层之间去切换,并不是说我就要一直站在楼顶,我的感觉。”

“去过那个大楼顶端就可以了,但是去过,有过这样的高峰体验之后,反过来是可以让人在地面生活得更好的。”

“未来可以带着创造性去生活,当你有无数个可能都可以做的时候,你去做哪个,其实就是人的选择。”

“你看我们都属于从最早开始玩儿AI的嘛,现在慢慢已经到了一个新的阶段了,做了好多年实验了,我们在想的东西跟别人就真的很不一样。很多人可能现在才开始,一起步就是最好的模型,我们就变成了最原住民的那一波,怎么说,亲自体验和看了这个过程之后,反而做出的是跟别人不一样的决定,我觉得这个是很好的。现在很多人一入场就直接Claude牛逼就完事了,我们至少知道,再多问几个看看哈哈。不同时期开始用,这个思路还是很不一样的。“

“认知科学的角度也是这样嘛,是认知的一个锁定嘛。在它峰值期前面,在它最有开放度那个期间,它有些模糊的东西,有一些非常模糊的东西。”“他没有那么多选择,去走一条完全新的路,一个他不熟悉的路线。因为他从来没有走过另外一条路。他没有他没有体验过另外一个世界,这一点是非常重要的。”

“技术路线或者学术路线,在相当程度上就是被他过过往的经历,尤其是早期大脑发育,前额叶发育完毕之前那个阶段的经历决定的。”

“哈哈对,头盖骨闭合了,发育彻底停止了,后面就只能存玩存量了,然后你最多再玩5年,35岁就开始体能下降了。”

“所以AI很重要的一个作用就是,他其实无法一次性或者短时间内改变所有人,但是会让大批量的青少年能够在非常短的时间,感受到那个峰值的一个感觉。”

“但是人家小孩儿不是这么用AI的,哈哈,人家在谈恋爱!”


CHANGELOG

  • 20260416 Arlmy 整理、发布

LLM 在 DevOps 中的三种角色

2026年4月16日 08:00
原文:[[https://dzone.com/articles/ai-driven-devops-for-saas][AI-Driven DevOps for SaaS]] Suresh Kurapati 在 DZone 发表了一篇关于 AI 驱动 DevOps 的文章,内容涵盖从预测性管道到 AIOps 自愈运维的完整图景。其中最有意思的部分是 LLM(大语言模型)在 DevOps 中的应用——因为代码、配置、日志本质上都是文本,而这正是 LLM 的主场。 * 代码与配置生成 LLM 最直接的用途是用自然语言生成基础设施配置。一个工程师可以用"帮我生成一个 Python Flask 应用的 Dockerfile 和 GitHub Actions 工作流"这样的提示词,在几秒内得到可用的配置。 实际案例更有说服力:有团队让 LLM 为数十个微服务生成了 90% 的 Kubernetes YAML 模板,CI/CD 配置时间缩短了 70%。工程师只需审查和微调 AI 生成的配置。 GitHub Copilot 是 IDE 集成的典型例子。使用这类 AI 辅助编程工具的开发者完成任务的速度提高了 55%,63% 的组织报告代码交付到生产的速度加快了。 * 智能排障 当流水线失败或生产事故发生时,日志和错误信息往往铺天盖地。LLM 能做什么: - 将上千行堆栈跟踪浓缩为简洁的问题解释 - 聚类相似的错误信息,定位到出问题的组件 - 推荐修复方案 研究表明,基于 LLM 的日志分析可以将事件解决时间从数小时缩短到数分钟。本质上,LLM 扮演了一个"读过所有日志的专家工程师"的角色。 * 基础设施代码的安全审查 LLM 还能审查基础设施定义中的错误和安全风险。例如,扫描一个 Terraform 脚本后,LLM 可能发现某个 S3 存储桶被配置为公开访问,并建议改为私有——相当于用自然语言做了一次合规审查。 这种用法为 DevOps 流水线增加了一层额外的保障,能捕捉可能导致安全漏洞的错误配置。 * 流水线中的 AI 集成示例 原文提供了一个 GitHub Actions 工作流示例,展示如何将 AI 风险评估集成到部署流程中: #+BEGIN_SRC yaml name: CI Pipeline with AI Gates on: [push] jobs: build_test_deploy: runs-on: ubuntu-latest steps: - name: Checkout code uses: actions/checkout@v3 - name: Build and Run Tests run: | ./build.sh && ./run_tests.sh - name: AI Code Risk Analysis id: ai_review run: | DIFF=$(git diff HEAD~1 HEAD) JSON_PAYLOAD=$(jq -n --arg diff "$DIFF" '{"diff": $diff}') RESPONSE=$(curl -s -X POST -H "Content-Type: application/json" \ -d "$JSON_PAYLOAD" https://api.example.com/ai/code-risk) RISK_LEVEL=$(echo "$RESPONSE" | jq -r .risk) echo "risk_level=$RISK_LEVEL" >> $GITHUB_OUTPUT - name: Deploy to Staging if: ${{ steps.ai_review.outputs.risk_level != 'high' }} run: ./deploy.sh staging - name: Abort Deployment (High Risk) if: ${{ steps.ai_review.outputs.risk_level == 'high' }} run: echo "Deployment blocked due to high-risk code changes." #+END_SRC 核心逻辑:流水线在部署前将代码差异发送给 AI 服务进行风险评估,高风险变更自动阻止部署。

Markon Review Express Weekly #36

作者 Vistaing
2026年4月16日 17:51

周报目录

Markon Review Express Weekly #36

📰 一般资讯

  • Take-Two 可能已裁掉整个 AI 团队
  • Eurogamer 介绍 Inkle 推出的游戏写作及叙事主题文集
  • Rock Paper Shotgun:Linux 正处在承接 PC 游戏的最好时代
  • Windows Central 暗示微软正考虑不再让《COD》加入 Game Pass

📊 市场动态

  • Aftermath:并不存在一个单一的“游戏行业”
  • 触乐:2026 年,游戏行业的大门更难敲开了
  • 黑客泄密材料显示,《GTA Online》目前的日均收入仍超 130 万美元
  • GamesIndustry:中国产商如何主导手游市场,西方又还能怎么竞争

🎙 观点讨论

  • Lucas Pope 称现在不太敢公开自己在做什么,怕被抄、被 AI 收进知识库
  • Game Developer:想在“注意力战争”里留住玩家?试试叙事吧
  • Unwinnable: 《星球大战:旧共和国武士》教我,别总等着游戏奖赏你
  • Eurogamer《黑与白》访谈:Lionhead 的设计如何成为现代人工智能的先驱
  • GamesIndustry:开发者不“懒”,游戏更新也不总是理所当然
  • Unwinnable:孤独的风景

📰 一般资讯

Take-Two 可能已裁掉整个 AI 团队

据 Eurogamer 等媒体报道,根据 Take-Two Interactive 前 AI 团队成员的社交媒体消息,Take-Two 可能已裁掉整个 AI 团队,其中包括 AI 负责人 Luke Dicken。Dicken 曾在 Take-Two 收购的 Zynga 效力约十年,他近日在 LinkedIn 上的发文称,自己领导的团队过去 7 年一直在研发辅助游戏开发的技术,目标是“把创新方案和产品设计结合起来,服务整个开发流程”。

公司 CEO Strauss Zelnick 此前曾多次公开表示,AI 本身不具备创造力,也做不出《GTA》水准的作品;Eurogamer 认为,这次裁掉 AI 团队,可能是 Take-Two 高层迄今为止最明确的一次动作,说明 Take-Two 至少没有跟随 Krafton、Square Enix、EA 等很多行业龙头,大举押注 AI。不过在笔者看来,目前可能还不好判断,Take-Two 是在理性压制 AI 的地位,还是对内部 AI 工作流搭建已经感到满意。

🔗 来源:Eurogamer,作者 Vikki Blake

Eurogamer 介绍 Inkle 推出的游戏写作及叙事主题文集

Markon Review Express Weekly #36

本文推荐了 Inkle 近期推出的 《The Game Narrative Kaleidoscope》,该书收录了 100 多篇关于游戏写作与叙事设计的短文,作者都是有丰富相关从业经验的人。本文收录了很多段关于部分短文的感想,供还没购入本书的读者先行感受一下内容氛围:

🔹 Mary Kenney 写作的主题是“如果玩家痛恨你(fucking hates you),该怎么办”,谈的是开发者在经历“玩家门”(GamerGate)之类的恶意之后,怎样重新找回对受众的信任。

🔹 Christine Love 认为,提供给主角的“邪恶路线”选项之所以成立,不是因为它“坏”,而是因为它能制造戏剧性,但曾参与《异域镇魂曲》(Planescape: Torment)的 Adam Heine 又给了一个相反角度:当“残酷”已经开始成为现实世界中可行的政治策略,他反而不再想提供那种“邪道”幻想。

🔹 作者还提到一篇围绕“留白”展开的文章,Pete Stewart 和 Alex Epstein 都认为,世界观不该解释得太满,谜团、空缺、误导、互相矛盾的叙述,反而会逼着玩家自己去补完世界。

🔹 Jordan Mechner 给出的一个价值判断:游戏不是其他媒介的附庸,“游戏就是玩家做的所有事”,如果把玩家长时间按在过场里、只让其旁观别人的冒险,体验就可能开始“溺水”。

🔗 来源:Eurogamer,作者 Robert Purchese

Rock Paper Shotgun:Linux 正处在承接 PC 游戏的最好时代

Markon Review Express Weekly #36

本文记录了作者将游戏操作系统从 Windows 切换为 Linux 的经验,包含 Linux 版本推荐、游戏兼容性配置、与 Windows 相比的利弊,这不是一篇极其严谨的、技术细节丰富的教程,但介绍的口吻直观且轻松,适合不熟悉 Linux 系统的读者参阅。

🔗 来源:Rock Paper Shotgun,作者 Joe Chivers


Windows Central 暗示微软正考虑不再让《COD》加入 Game Pass

Markon Review Express Weekly #36

据 Eurogamer 援引 Windows Central 近日透露的信息,微软正在重新评估《使命召唤》(Call of Duty,下称 COD)在 Game Pass 的首发策略,或许今年我们会看到《COD》被移出 Game Pass。

Windows Central 的编辑 Jez Corden 在视频中提到,《COD》庞大的体量,吸走了 Game Pass 吸收来的、用于创新的资金,而玩家们可以相对廉价地方式玩到《COD》,反过来也损伤了《COD》的商业表现。Corden 还猜测,重新划分 Game Pass 层级、为《COD》在更昂贵的订阅层级中找到位置,也是可能的选项。

🔗 来源:Eurogamer,作者 Vikki Blake


📊 市场动态

Aftermath:并不存在一个单一的“游戏行业”

Aftermath 的 Luke Plunkett 想通过这篇评论提醒一件事:他注意到最近有很多观点,将 3A 游戏的困境、主机市场的疲软、裁员潮、融资收缩等,不假思索地概括成“游戏行业崩溃”,他觉得这种说法太粗糙了、或者说难免太“美国中心”,因为“电子游戏”不是仅存于局部地区、一个单一行业,而是一种融合媒介,包括但不限于作为艺术被欣赏、作为商品被消费、作为体验而被游玩。

文章拿 1983 年北美主机崩盘作对照,指出当年塌方的也只是并行市场中的一块,放眼今天,真正处在剧烈收缩中的,或许还是西方 3A 这条线,而 Steam、移动 F2P、Roblox、Itch、中日韩各自的本地市场等,各方仍在按自己的逻辑运转。

🔗 来源:Aftermath,作者 Luke Plunkett

触乐:2026 年,游戏行业的大门更难敲开了

Markon Review Express Weekly #36

本文采访了多名尝试进入游戏行业的应届生(或准应届生),以及一位外包公司 HR,通过他们的感受和经历,展现了中国 2026 年游戏行业春招的一些表现:有人卖力分发简历,却只拿到几次测试机会;有人长时间卡在初筛阶段,查进度查到短信验证码被系统限流;去年还在招的很多 2D 动画、运营、发行等岗位,今年已呈明显的缩招趋势。

结合几位访谈对象的观点,文章认为,AI 是导致变化最重要的因素之一。触乐提到,不少厂商已经把 AI 工具从加分项抬成必选项:美术岗要熟悉 Stable Diffusion、LoRA 等 AI 生图技术栈,技术岗普遍要求较深的 AI 使用经验,策划和运营岗也被期待将 AI 贯穿到工作流里,凭自动化降低人力成本。更麻烦的是,行业也在同步“去初级化”:脉脉数据显示,2026 年前两个月,新发部岗位中 1 年以内经验岗位同比减少约 20%,原本给予新人试错、积累经验的区间正加速消亡。

由于 AI、降本增效的影响,大厂对外包的依赖亦在加深,受访的 HR 告诉触乐,现在甲方对外包的都已经到了“能单打独斗”“以一抵十”,新人不只在和同届竞争,也在和更有经验、但同样被压价的外包从业者竞争。

🔗 来源:触乐,作者 姚楚杉

黑客泄密材料显示,《GTA Online》目前的日均收入仍超 130 万美元

Markon Review Express Weekly #36

黑客组织 ShinyHunters 近期以其掌握的“敏感财务数据”,向 Rockstar Games 提出勒索,并在后者未予理睬后公开了这些内部经营数据。Polygon 在梳理 ShinyHunters 泄露的内容时发现,它们表明 Rockstar 通过《GTA》实现了相当优异的经营成绩。

泄露信息显示,《GTA Online》直到今天都还在一刻不停地“印钞”,2025 年 9 月到 2026 年 4 月期间,《GTA Online》平均每周营收约 959 万美元、日均约 131.9 万美元,意味着全年会接近 5 亿;作为对照,《荒野大镖客》在线模式 Red Dead Online 同期平均每周营收只有约 50.7 万美元——这也已经是很多游戏梦寐以求、难以企及的水平了。Polygon 调侃道,现在我们可能更清楚,为什么《GTA VI》能推迟这么多次、Take-Two 却依然从容了。

🔗 来源:Polygon,作者 Patricia Hernandez

GamesIndustry:中国产商如何主导手游市场,西方又还能怎么竞争

Markon Review Express Weekly #36

本文作者 Tanja Loktionova 是乌克兰游戏行业咨询机构 Values Value 的创始人,本文显然带有一定的宣传意味(比如帮西方工作室与“神秘的东方力量”牵线),但也不妨碍我们体会一下,一个外部视角对中国游戏市场现状的观察。文章很长,笔者摘录了其中几个比较有代表性的论点。

🔹 据 AppMagic 统计,2026 年 2 月全球收入最高的 15 款手游里,有 7 款属于中国公司,单月内购收入 6.68 亿美元。作者认为,优势的建立最早可以追到 2000 年代中国盗版游戏的泛滥,买断制难以为继,本土团队被迫更早转向 F2P;等全球转向移动游戏时,对于如何理解付费玩家的课题,中国厂商早已多积累了十几年的经验。

🔹 作者举了一个例子,有中国公司在谈收购欧洲团队时,要求包括美术、UI/UX 在内的整支团队一起迁往中国,包办搬迁、签证、工作许可、子女就学等生活需求。她想说明的是,收购方理解团队作为一个整体的价值,而不只是顶着个别关键人员。

🔹 作者提到一个成都手游公司的案例,这是她的机构服务过的团队:该公司 2017 年先后在基辅、爱丁堡设立美术团队,不是因为便宜,而是看重这些本地团队在 UI 解构、色彩逻辑、内容可理解性等方面的直觉,相信他们更懂目标客群。该公司后来被国内大厂收购,公司高层认为,上述两支海外团队提升了收购溢价。

🔹 文章最后谈到,中国厂商正在加速拥抱 AI,AI 显著提升了产出效率,作者引用一档播客节目中的说法,有时候一个梗刚在抖音上出现,第二天就有游戏关卡里加入了这个梗。作者认为,西方公司真正能押注的,恐怕只剩更少的人、更高的人才密度、产出独一无二的创意。

🔗 来源:GamesIndustry,作者 Tanja Loktionova


🎙 观点讨论

Lucas Pope 称现在不太敢公开自己在做什么,怕被抄、被 AI 收进知识库

《请出示文件》(Papers, Please)、《奥伯拉丁的回归》(Return of the Obra Dinn)开发者 Lucas Pope 最近在与 Mike Rose、Rami Ismail 的播客里谈到,自己现在越来越少公开展示开发中的项目了。

Pope 说,他一直很喜欢边做边说,很想把手上的东西拿出来分享,但现在的环境让他没那么舒服了,因为在自己做完之前,那些想法可能就会被别人抄走,或者被 AI 抢先“吸入”(Slurp up)、变成别的东西。

Pope 表示“分享”当然不是某种必须遵守的规矩,但它类似于一种越来越强的直觉性防备。他说自己是那种“很想把东西真正做完”的人,正因为如此,才会更在意点子在中途流失的风险。对 Pope 来说,这种不安全感已经影响到表达欲本身,他坦言,希望这种感觉终能过去、自己还能重新自在地谈论手上的作品。

Pope 还阐述了某种“成功的枷锁”:因为《请出示文件》《奥伯拉丁的回归》收获太多好评,他对下一款大型新作的推出更谨慎了,他会忍不住想,自己已经意外走运了两次,或许没必要再冒着让人失望的风险试第三次。

🔗 来源:VGC,作者 Chris Scullion

Game Developer:想在“注意力战争”里留住玩家?试试叙事吧

本文是 Game Developer 编辑对今年 GDC 上一场内容分享的整理,分享人是两位编剧 Alexa Ray Corriea、Adam Dolin。两人尝试反思一个近来在行业内很常见的焦虑:玩家的注意力正在被短视频、AI 聊天机器人等不断切碎;如果游戏连玩家的专注都留不住,创作与商业方面的问题就会一起爆发。两人的答案是,不必模仿某些平台对用户停留时长的疯狂索取,而是回到游戏自己更擅长的东西上:剧本、叙事设计,以及在背后支撑的系统设计,让玩家更深地参与内容,而不只是被动消费。

Dolin 从更技术、偏玩家交互的视角切入。他举了横版动作游戏《信使》(The Messenger)中的一个例子,谈到一个玩家触发商店老板发表关于“幸福”的演讲、拿到“Fine, I Won't Open It”成就的段落。

Dolin 认为这段不只台词写得好,场景里相关的交互更是值得关注:柜子会持续提示可互动,老板会一再警告玩家别碰,再威胁说要让你听一段不能跳过的无聊故事,直到数次触发后才突然抛出一大段出人意料的独白;按钮提示怎么闪、文字怎么滚、警告重复到第几次才真正触发,最终都会决定玩家到底是在阅读一段话,还是在参与一段编排精致的故事体验。

Corriea 的展开角度则是:玩家到底要不要复杂、尖锐、可能引发争议的故事?她的回答并不是简单鼓励开发者们“胆子大一点”:她首先指出,很多工作室内部的保守倾向并不一定出于恶意、而是可能出于商业上的危机感,对特定岗位的人来说,怎么样多卖游戏、让公司活下去是其首要议程,稳定、安全本身也是一种真实的价值判断。Corriea 认为,如果团队成员们没有先弄清彼此在风险、道德、创作上的价值排序,就贸然推进复杂叙事,很容易把本来善意的分歧演化成内部冲突。在上述认识的基础上,Dolin 给出了两个研究案例。

其中一个是覆盖 3.7 万人、跨越不同政治立场的跟踪研究,结论是接触相反观点的媒体内容未必会改变立场,但会降低对立情绪。Dolin 认为,人们完全有能力处理复杂的信息,然而人们的很多主要资讯获取平台,其设计初衷就是为了防止人们接触到不同的观点。

另一项研究则围绕《底特律:化身为人》(Detroit: Become Human),研究发现,相比只旁观相关片段,亲自操作主角 Kara 保护小女孩免受家暴的玩家,会更强烈地“代入”角色,并提升对现实中受害者的共情、降低隐性偏见,不同性别玩家的受影响程度相当。对 Corriea 和 Dolin 来说,这恰好说明,真正能让玩家停下来、留下来、甚至带着一些不适继续思考下去的,往往不是最圆滑、最保险的内容,而是那些愿意挑战玩家、促使自我反思、也可能打破类型预期的创作之道。用 Corriea 的原话说:“你的受众有能力理解细微的差别。”

🔗 来源:Game Developer,作者 Bryant Francis

Unwinnable: 《星球大战:旧共和国武士》教我,别总等着游戏奖赏你

Markon Review Express Weekly #36

本文回忆了作者与 《星球大战:旧共和国武士》(Star Wars: Knights of the Old Republic,下称 KOTOR)的一次碰撞。

她 2025 年才开始接触并认真游玩 RPG,某次长途旅行中,她花 5 美元买下了本作正在打折的 Switch 版。一开始《KOTOR》给她的印象并不算好:画面显旧、操作笨重、站桩过场令人失望,玩起来堪比写作业。

很快,一次“不被奖励”的瞬间让她真正沉浸到游戏里。文章提到,费了千辛万苦救出某位绝地阵营的主要角色后,等来的不是常见的感谢和回报,而是一种近乎轻蔑的反应,这冲击了作者已被现代 RPG 普遍做法训练出来的习惯,而《KOTOR》没有这么做,这位被救出的角色,仿佛在玩家到来之前就已存在,而不是塑造玩家成为世界中心的一颗棋子。

作者认为,当游戏拒绝立刻满足你、刻意拉开距离时,游戏世界反而更像是真实存在,驱动玩家感到好奇、紧张、投入,这比即时满足更强效;《KOTOR》真正改变她的,不是它给你什么,而是它选择不要马上给你什么。

🔗 来源:Unwinnable,作者 Mer Mora

Eurogamer《黑与白》访谈:Lionhead 的设计如何成为现代人工智能的先驱

Markon Review Express Weekly #36

《黑与白》(Black & White)是 Lionhead Studios 于 2001 年推出的一款“神”模拟游戏,玩家用一只悬空的手管理村庄、施放神迹,并培养一只会闯祸、会从玩家操作中学习、会逐渐形成某种性格的巨兽,对抗敌对巨兽“Nemesis”的威胁。Eurogamer 近日推出一篇访谈,在《黑与白》发售 25 周年之际,重点采访了该作当年的核心开发者 Peter Molyneux、Richard Evans。

这篇访谈令笔者最感兴趣的部分,是它把《黑与白》中精巧的巨兽 AI 设计,放到了 AI 行业发展的大背景里,看到了《黑与白》在 AI 技术时间线上特殊的位置。访谈中提到,该作不仅有 Molyneux 天马行空的设计,还有 Evans 在极其有限的算力下,写出了一套有效的强化学习机制,能让巨兽从玩家的奖惩、示范、引导中快速领悟;Evans、前 Lionhead 开发者 Demis Hassabis 后来都去了 Google DeepMind,这意外地让《黑与白》成了如今的“世界模型”、生成式 AI 等技术的一次早期预演。

这篇访谈篇幅较长,细节繁多,以《黑与白》为例,展现了游戏作为“数字生命”试验田的那种契合度,欢迎感兴趣的读者参阅。

🔗 来源:Eurogamer,作者 Lewis Gordon

GamesIndustry:开发者不“懒”,游戏更新也不总是理所当然

近日,针对《PEAK》发布的愚人节更新,有人发布 X 指责开发商 Landfall 的制作人员懒惰、更新散漫(原帖已删除、可在 IGN 的报道中了解帖子里具体写了什么),而 Landfall 毫不示弱地阐述了自己的主张:《PEAK》已经推出了很多更新!我们和 Aggro Crab(联合开发商)都不是在线服务(Live service)工作室,任何更新都是额外福利、而非玩家应享有的权利。

本文以上述事件为引子,探讨了一个这几年愈发普遍的现象:越来越多玩家把看待在线服务型游戏的标准,往几乎所有的游戏上套用,默认后者应该持续更新、不断追加内容,一旦停更,就容易产生“开发者懒”“游戏被抛弃了”的观点。作者认为,对于以高强度、低稳定性、高倦怠率著称的游戏行业,这种说法尤其刺耳、不公。

在线服务型游戏的崛起当然是原因之一。作者指出,过去十年里,通行证、赛季、活动等模式固化下来,塑造着玩家们的默认预期,连单机游戏也开始被放进这个错位的预期,人们开始因为 Steam 在线人数下滑、指出某个叙事完整的单机作品“死了”,或者因为几个月没出 DLC 或补丁,就说它“被放弃了”。作者同时也认为,伴随在线服务大行其道的,更有“粉丝”这层身份本身的畸变,仿佛只要成了粉丝,就天然拥有被倾听、被满足、甚至左右作品方向的权利。

作者接着论述到,这种预期也是行业自己慢慢孵化出来的:数字发行、长尾销售、DLC 爆发、订阅服务兴起,开发者们比以往任何时候,都更能、更愿意实现游戏在公众视野里的停留。再加上《无人深空》(No Man's Sky)、《赛博朋克 2077》(Cyberpunk 2077)这类“自我救赎”个别案例的传颂,很多人开始相信,不管是什么游戏都应该继续变好,症结可能只在于开发者是不是“懒”。

作者最后提出一种呼吁:他支持 Landfall 在《PEAK》上强调的观点,做完一个项目、更新一阵,然后带着新想法转向下一个项目,这是再正常不过的创作节奏,对独立团队尤其是如此;如果大家都认同,自己花的钱对应的就是买到手的那个版本,后续绝大部分内容都算开发者额外分享的福利,那就太理想了——但这个行业可能已经投入了太多、把玩家预期塑造到了另一个方向。

🔗 来源:GamesIndustry,作者 Rob Fahey;IGN,作者 Rebekah Valentine

Unwinnable:孤独的风景

Markon Review Express Weekly #36

作者对比《塞尔达传说:旷野之息》(ゼルダの伝説 ブレス オブ ザ ワイルド)、《塞尔达传说:王国之泪》(ゼルダの伝説 ティアーズオブザキングダム),分享了一个有意思的观点:风景从来不只是背景板,它在塑造玩家如何理解世界、理解自己;《旷野之息》《王国之泪》看似共用同一个海拉鲁,实际却描绘了两种完全不同的空间情绪。

在《旷野之息》里,主角林克从沉睡中苏醒,看到的是各种地貌、遗迹构成的广阔世界,决定此地气质的不是“大”、而是“空”:相当多游戏时间里,你不会遇到多少人或任务,只是听见风吹过草地和树林、看见动物从身旁经过、残缺的守护者倒在山谷、神庙空空荡荡、村落只剩切片。作者觉得,是对灾后世界的生动描绘、并非仅是传统意义上的留白:海拉鲁还在,但曾经赋予这片土地意义的文明结构已经坍塌,“缺席”塑造着孤独。

作者觉得《王国之泪》几乎相反。还是同样的地貌,路上有更多旅行者、学者、施工队,聚落四周升起脚手架,被遗弃的地方有了新用途,“超级手”为代表的建造系统本身,也鼓励玩家集合散落的零件、拼装出有用的设施。作者认为,如此种种令《王国之泪》的风景不再主要是让人独处、沉思的场所,而更像一个正在被集体修补、重新占领的世界。

作者总结到,他更偏爱的还是《旷野之息》,原因很简单:它让“静谧”本身成为游戏意义的一部分,这种体验如今越来越难获得了。

🔗 来源:Unwinnable,作者 Justin Reeve

生日快乐 — 又是一年二十九

作者 obaby
2026年4月16日 13:52

年复一年,时间似乎过的很快,又过的很慢。今天一直在忙各种事情,直到现在才有片刻的空闲,来庆祝下自己的生日。

这一年发生了很多意料之外的事情,甚至有的事情到现在还没有结论,后续如何更是一个未知数。然而,不管如何,生活还是要继续的。这慢慢人生,没有太多的时间去彷徨,去挣扎,去苦闷。

好几天之前,刷到一个视频,我跟对象说,我要把这个在我生日那天发朋友圈,之前保存下载,今天早上就出现在了自己的朋友圈了,虽然没人点赞,没人回复,我倒是也不在乎,自己开心就好。

至于生日礼物,上周的时候对象就问自己想要什么。

『我要三折叠』

『没有』

『我要双折叠』

『也没有』

对于这种折叠屏手机,只是没用过,有点喜欢,可能也没那么喜欢。昨天中午,趁着午饭的时间,去乐客城外面的华为体验店看了一眼。

只是出来之后,原来的华为竟然变成了小米。高德搜了一下发现地标还没变,但是在其他的地方有另外两个,只好往另外一边的华为体验店走。

中午时间,店里没几个顾客,连店员都没几个。看了下三折叠跟双折叠,三折叠太贵,双折叠的尺寸总是觉得有些奇怪。

双折叠的感觉就是叠起来,打开比例看着都挺奇怪的。三折叠的价格,实在是不敢恭维,快两万块钱买个手机,这已经远远超出自己的可承受范围了。走之前给对象发消息,得到了明确答复,坚决不同意买三折叠。

最后,目标还是落在了mate 80 和pure 80上,至于mate,那个中间的摄像头总是感觉有些别扭,店员还说,那个特别商务,看起来比较大气。问题是,我不喜欢商务风啊。

鉴于线下还能领国补,虽然没有自己想要的金色,还是果断下单了,最终选的的白色,黑色也不喜欢。

还给了一堆乱七八糟的赠品,聊胜于无吧。

之前的p70 pro彻底放弃了,而至于30,也的确支撑的有点吃力,至于90,新机价格大概率比较贵,所以现在马上换代了,80 就80吧。

晚上回家的时候,收到了对象送的猫和老鼠的小手办,老鼠被压成鼠饼的那一集,嘻嘻。

中午的时候,买的新的车载空气清新剂和另外一条瑜伽裤到了,之所以再买一条是感觉上一条的弹力不够大,跳绳的时候没有足够的压力支撑。

上面是原来的,现在已经没什么味道了、下面是新买的。

味道还是蛮清新的,喜欢女生味的可以考虑下哦,香型:香奈五号。香奈儿的就不考虑了哈,那个太贵了,很多仿这个香味的。

比原来的大一圈,放到前面的杯架刚刚合适。

至于瑜伽裤,感觉弹力的确比上一条要好一些,价格也自然是贵了点,上一条黑色瑜伽裤的两倍。

上身效果:

最后,贴一下现在的手机壁纸,希望锦鲤给所有人都带来好运哦:

我要赚钱钱 我要暴富富
我要变美变瘦变酷酷
我要钱多多 我要买车车

From RAG to Knowledge Compilation

作者 finisky
2026年4月16日 11:43
<p>RAG re-retrieves, re-assembles, and re-reasons on every query. Ask something that requires synthesizing five documents and the model has to find all five, stitch them together, and derive the answer from scratch. Ask ten times, retrieve ten times. Nothing accumulates.</p> <p>Karpathy recently posted a gist called LLM Wiki proposing a different approach: instead of retrieving at query time, have the LLM pre-compile knowledge into a structured wiki and query the compiled result.</p>

从RAG到知识编译

作者 finisky
2026年4月16日 08:39
<p>RAG 的工作方式是每次提问都重新检索、重新拼接、重新推理。问一个需要综合五篇文档才能回答的问题,模型每次都得从头找到这五篇,拼起来,再给你答案。问十次,找十次。什么都没积累下来。</p> <p>Karpathy 前两天发了一个叫 LLM Wiki 的 gist,提了一个不同的思路:别让模型每次现场检索了,让它把知识预先编译成一个结构化的 wiki,查询的时候直接查编译好的结果。</p>

PARA Org-mode 测试配置

2026年4月16日 08:00
* 前置说明 这份配置用于测试博文《AI 时代的 PARA 方法》中的 Org-mode PARA 实现。 使用方式: 1. 先执行 [[创建目录结构]] 中的 shell 代码块(=C-c C-c=) 2. 将 [[Emacs 配置]] 中的代码加入你的 =init.el= 或 =*scratch*= buffer 执行 3. 用 =M-x org-capture= 测试四个模板 4. 用 =C-c C-w= (=org-refile=) 测试归档 基础目录设为 =~/我的笔记= ,可按需修改 =org-para-base-dir= 。 * 创建目录结构 #+BEGIN_SRC shell :tangle (format "/tmp/para-setup-%s.sh" (user-login-name)) PARA_DIR="$HOME/org" # 创建 PARA 四层目录 mkdir -p "$PARA_DIR/projects/2026-博客重构" mkdir -p "$PARA_DIR/projects/2026-Anki插件开发" mkdir -p "$PARA_DIR/areas/健康" mkdir -p "$PARA_DIR/areas/财务" mkdir -p "$PARA_DIR/areas/职业" mkdir -p "$PARA_DIR/resources/emacs" mkdir -p "$PARA_DIR/resources/python" mkdir -p "$PARA_DIR/resources/linux" mkdir -p "$PARA_DIR/archives" # 创建 inbox 文件(org-capture 目标) cat > "$PARA_DIR/projects/inbox.org" << 'EOF' #+TITLE: Projects Inbox #+FILETAGS: :project: ,* Projects Inbox EOF cat > "$PARA_DIR/areas/inbox.org" << 'EOF' #+TITLE: Areas Inbox #+FILETAGS: :area: ,* Areas Inbox EOF cat > "$PARA_DIR/resources/inbox.org" << 'EOF' #+TITLE: Resources Inbox #+FILETAGS: :resource: EOF # 创建 journal 文件 touch "$PARA_DIR/journal.org" # 创建示例项目文件(供 org-refile 测试) cat > "$PARA_DIR/projects/2026-博客重构/index.org" << 'EOF' #+TITLE: 2026 博客重构 #+FILETAGS: :project: ,* TODO 重新设计博客首页 SCHEDULED: <2026-04-20 日> ,* TODO 迁移到新的静态站点生成器 ,* DONE 梳理现有文章分类 CLOSED: [2026-04-10 四] EOF cat > "$PARA_DIR/projects/2026-Anki插件开发/index.org" << 'EOF' #+TITLE: 2026 Anki 插件开发 #+FILETAGS: :project: ,* TODO 调研 Anki 插件 API ,* TODO 设计卡片模板系统 ,* INPROGRESS 编写核心功能代码 EOF # 创建示例领域文件 cat > "$PARA_DIR/areas/健康/index.org" << 'EOF' #+TITLE: 健康 #+FILETAGS: :area: ,* 每周运动目标:3 次 ,* 年度体检:每年 Q1 ,* TODO 预约牙科检查 EOF cat > "$PARA_DIR/areas/财务/index.org" << 'EOF' #+TITLE: 财务 #+FILETAGS: :area: ,* TODO 完成 2025 年度报税 DEADLINE: <2026-05-31 日> ,* 每月记账复盘 EOF # 创建示例资源文件 cat > "$PARA_DIR/resources/emacs/index.org" << 'EOF' #+TITLE: Emacs 学习笔记 #+FILETAGS: :resource: ,* Org-mode 技巧 ,** 使用 columnview 生成任务报表 ,** org-roam 双向链接配置 ,* Elisp 常用模式 ,** advice-add / advice-remove ,** defmacro 与 defun 的区别 EOF echo "PARA 目录结构创建完成:" echo "" tree "$PARA_DIR" 2>/dev/null || find "$PARA_DIR" -type f | sort #+END_SRC #+RESULTS: | PARA | 目录结构创建完成: | | | | | | | | | /home/lujun9972/org | | | | | ├── | archives | | | | ├── | areas | | | | │   | ├── | inbox.org | | | │   | ├── | 健康 | | | │   | │   | └── | index.org | | │   | ├── | 职业 | | | │   | └── | 财务 | | | │   | └── | index.org | | | ├── | journal.org | | | | ├── | projects | | | | │   | ├── | 2026-Anki插件开发 | | | │   | │   | └── | index.org | | │   | ├── | 2026-博客重构 | | | │   | │   | └── | index.org | | │   | └── | inbox.org | | | └── | resources | | | | ├── | emacs | | | | │   | └── | index.org | | | ├── | inbox.org | | | | ├── | linux | | | | └── | python | | | | | | | | | 13 | directories, | 9 | files | * Emacs 配置 #+BEGIN_SRC emacs-lisp :tangle (format "/tmp/para-config-%s.el" (user-login-name)) ;;; para-config.el --- PARA Org-mode 配置 -*- lexical-binding: t; -*- ;; ============================================================ ;; 基础设置 ;; ============================================================ (defvar org-para-base-dir "~/org" "PARA 方法的根目录。") ;; ============================================================ ;; TODO 关键字:支持 INPROGRESS 等自定义状态 ;; ============================================================ (setq org-todo-keywords '((sequence "TODO(t)" "INPROGRESS(i)" "|" "DONE(d)" "CANCELLED(c)"))) ;; ============================================================ ;; org-capture 模板:快速捕获到 PARA 各层 ;; ============================================================ (setq org-capture-templates `(("p" "Project - 项目任务" entry (file+headline ,(expand-file-name "projects/inbox.org" org-para-base-dir) "Projects Inbox") "* TODO %?\n %U\n %a\n %i" :empty-lines 1) ("a" "Area - 领域任务" entry (file+headline ,(expand-file-name "areas/inbox.org" org-para-base-dir) "Areas Inbox") "* TODO %?\n %U\n %a\n %i" :empty-lines 1) ("r" "Resource - 资源笔记" entry (file ,(expand-file-name "resources/inbox.org" org-para-base-dir)) "* %? :resource:\n %U\n %i" :empty-lines 1) ("j" "Journal - 日记" entry (file+datetree ,(expand-file-name "journal.org" org-para-base-dir)) "* %?\n %U" :empty-lines 1) ;; 便捷模板:带链接的选择式捕获 ("c" "Capture with choice" entry (file+headline ,(expand-file-name "projects/inbox.org" org-para-base-dir) "Projects Inbox") "* TODO %^{任务描述}\n %U\n %a\n %i" :empty-lines 1))) ;; ============================================================ ;; org-refile 目标:归档到 PARA 各文件 ;; ============================================================ (setq org-refile-targets `((,(expand-file-name "projects/*.org" org-para-base-dir) :maxlevel . 2) (,(expand-file-name "projects/**/*.org" org-para-base-dir) :maxlevel . 2) (,(expand-file-name "areas/*.org" org-para-base-dir) :maxlevel . 2) (,(expand-file-name "areas/**/*.org" org-para-base-dir) :maxlevel . 2) (,(expand-file-name "resources/*.org" org-para-base-dir) :maxlevel . 1) (,(expand-file-name "resources/**/*.org" org-para-base-dir) :maxlevel . 1) (,(expand-file-name "archives/*.org" org-para-base-dir) :maxlevel . 1))) (setq org-refile-use-outline-path 'file) (setq org-outline-path-complete-in-steps t) ;; ============================================================ ;; org-agenda:PARA 视图 ;; ============================================================ (setq org-agenda-files (append (directory-files-recursively (expand-file-name "projects" org-para-base-dir) "\\.org$") (directory-files-recursively (expand-file-name "areas" org-para-base-dir) "\\.org$"))) ;; 自定义 agenda 视图:按 PARA 层级分组 (setq org-agenda-custom-commands '(("P" "PARA 视图" ((agenda "" ((org-agenda-span 'week))) (todo "TODO|INPROGRESS" ((org-agenda-overriding-header "活跃项目任务") (org-agenda-files (directory-files-recursively (expand-file-name "projects" org-para-base-dir) "\\.org$")))) (todo "TODO" ((org-agenda-overriding-header "领域维护任务") (org-agenda-files (directory-files-recursively (expand-file-name "areas" org-para-base-dir) "\\.org$")))))) ("p" "仅项目任务" todo "TODO|INPROGRESS" ((org-agenda-overriding-header "项目任务") (org-agenda-files (directory-files-recursively (expand-file-name "projects" org-para-base-dir) "\\.org$")))))) ;; ============================================================ ;; org-roam 集成(可选,需要安装 org-roam) ;; ============================================================ (with-eval-after-load 'org-roam (setq org-roam-directory org-para-base-dir) ;; 通过 filetags 区分 PARA 类别 ;; 在 org 文件头部添加: #+filetags: :project: 或 :area: 或 :resource: 或 :archive: (setq org-roam-node-display-template "${tags:20} ${title:*}") ;; 按类别过滤 org-roam 节点 (defun my/org-roam-filter-by-tag (tag) "返回一个过滤函数,只保留带有 TAG 的 org-roam 节点。" (lambda (node) (member tag (org-roam-node-tags node)))) (defun my/org-roam-list-notes-by-tag (tag) "列出所有带有 TAG 的 org-roam 笔记文件路径。" (mapcar #'org-roam-node-file (seq-filter (my/org-roam-filter-by-tag tag) (org-roam-node-list)))) ;; 快捷命令:按 PARA 类别浏览笔记 (defun my/org-roam-find-project () "查找或创建项目笔记。" (interactive) (org-roam-node-find nil nil (my/org-roam-filter-by-tag "project"))) (defun my/org-roam-find-area () "查找或创建领域笔记。" (interactive) (org-roam-node-find nil nil (my/org-roam-filter-by-tag "area"))) (defun my/org-roam-find-resource () "查找或创建资源笔记。" (interactive) (org-roam-node-find nil nil (my/org-roam-filter-by-tag "resource")))) ;; ============================================================ ;; 辅助函数:PARA 维护 ;; ============================================================ (defun my/para-archive-project (project-file) "将一个完成的项目移到 archives 目录。 PROJECT-FILE 是项目文件或目录的路径。" (interactive (list (completing-read "归档项目: " (directory-files (expand-file-name "projects" org-para-base-dir) t directory-files-no-dot-files-regexp)))) (let* ((archive-dir (expand-file-name "archives" org-para-base-dir)) (project-name (file-name-nondirectory project-file)) (dest (expand-file-name project-name archive-dir))) (rename-file project-file dest) (message "已归档: %s -> %s" project-name dest))) (defun my/para-show-stats () "显示当前 PARA 各层的文件数量统计。" (interactive) (let ((stats (cl-loop for category in '("projects" "areas" "resources" "archives") for dir = (expand-file-name category org-para-base-dir) for count = (length (directory-files-recursively dir "\\.org$")) collect (cons category count)))) (with-output-to-temp-buffer "*PARA Stats*" (princ "PARA 目录统计\n") (princ (make-string 30 ?=)) (terpri) (cl-loop for (cat . cnt) in stats do (princ (format "%-15s %d 个文件\n" cat cnt))) (terpri) (princ (format "总计: %d 个文件\n" (cl-loop for (_ . cnt) in stats sum cnt)))))) ;; 快捷键绑定(可选) (global-set-key (kbd "C-c p c") #'org-capture) (global-set-key (kbd "C-c p a") #'org-agenda) (global-set-key (kbd "C-c p s") #'my/para-show-stats) (global-set-key (kbd "C-c p A") #'my/para-archive-project) (provide 'para-config) ;;; para-config.el ends here #+END_SRC * 测试步骤 ** 1. 创建目录结构 在 shell 中执行: #+BEGIN_SRC shell bash /tmp/para-setup-$(whoami).sh #+END_SRC 或者在 org 文件中 =C-c C-c= 执行 [[创建目录结构]] 的代码块。 ** 2. 加载 Emacs 配置 #+BEGIN_SRC emacs-lisp ;; 方式一:直接加载 (load "/tmp/para-config-$(whoami).el") ;; 方式二:在 *scratch* 中 eval-region #+END_SRC ** 3. 测试 org-capture | 快捷键 | 模板 | 目标 | |--------|------|------| | =C-c p c= → =p= | Project 任务 | projects/inbox.org | | =C-c p c= → =a= | Area 任务 | areas/inbox.org | | =C-c p c= → =r= | Resource 笔记 | resources/inbox.org | | =C-c p c= → =j= | 日记 | journal.org | ** 4. 测试 org-refile 在任何 org 条目上按 =C-c C-w= (=org-refile=),应该能看到: - projects 下的项目文件 - areas 下的领域文件 - resources 下的资源文件 - archives 目录 ** 5. 测试 agenda 视图 | 快捷键 | 视图 | |--------|------| | =C-c p a= → =P= | PARA 总览(按周 agenda + 项目任务 + 领域任务) | | =C-c p a= → =p= | 仅显示项目任务 | ** 6. 测试统计 =C-c p s= 显示各层文件数量。 * 快捷键速查 | 快捷键 | 功能 | |--------|------| | =C-c p c= | org-capture | | =C-c p a= | org-agenda | | =C-c p s= | PARA 统计 | | =C-c p A= | 归档项目 | | =C-c C-w= | org-refile(在任何 org 条目上) |
❌
❌