Fable 5 和 Mythos 5 被暂停访问的时间线大致如下：

1.Amazon 安全研究团队发现，Anthropic 的 Fable 5 在特定提示词下可能被绕过安全限制，输出部分受限的网络安全信息。

这些内容涉及软件漏洞挖掘、缺陷分析，以及可能被用于网络攻击的技术路径。

2.Amazon CEO Andy Jassy 随后将相关安全担忧报告给美国政府高级官员。

3.美国政府介入后，以国家安全和出口管制为由，要求 Anthropic 禁止“外国国民”访问 Fable 5 和 Mythos 5。

这里的“外国国民”范围很宽，不只包括海外用户，也包括身在美国境内的非美国籍人士，甚至包括 Anthropic 自己公司的非美国籍员工。

4.问题随之变得非常棘手：模型访问权限很难按“国籍”精准筛选。

一个用户在美国登录，并不代表他是美国公民；一个企业账号内部，也可能同时有美国籍员工和外国籍员工。企业客户、API 调用、内部员工权限都需要重新区分，执行难度很高，法律风险却很直接。

Anthropic 最终选择了最保守的处理方式：暂停所有客户对 Fable 5 和 Mythos 5 的访问。

昨天阿里关于钉钉管理文化的锐评通稿刚发出来，群里一些老阿里人就闻到味儿了，断言这是不准备保无招了。

果不其然，今天就把无招的CEO给拿掉了，公式做题就是快。

无招实名陈航，确实是严格意义上的钉钉创始人，算是阿里内部比较少有的能从马老师那里赢得第二次信任的人，顶着屡败屡战的压力做出钉钉，属于实打实的赫赫战功。

因为「云钉一体」的架构调整离职、时隔多年之后又被连带着创业公司被打包收购、重新被委以钉钉最高负责人的重任，这个叙事就很乔布斯，如果一切顺利的话。

但是没有这种如果。

钉钉内部对于无招第二次走人是比较开心的，工作强度实在太大了，更重要的是压力没有反馈，吃互联网这碗饭，忙没毛病，忙且没有意义才是问题。

话说回来，其实也很少看到有人对无招的品行发出质疑，员工觉得他未必是一个坏人，却在做刻舟求剑的事情，是用战术的勤奋，去掩盖战略的无能。

无招去年回归钉钉之后，第一件事情就是把核心团队搬回湖畔花园的民宅，那是阿里的耶路撒冷，马老师当年就是从这里带着「十八罗汉」起步的，在来往项目失败之后，无招也是在湖畔花园磨出了钉钉，可以说是圣地福地皆有之。

无招一直相信他可以让钉钉回到1999年、回到2014、回到大家都一无所有背水一战的那种状态，然后就能复制从前的路径，再次打出一场漂亮的翻身仗。

对于少数受到器重的核心骨干来说，这种带有高期待的高压力，或许是能转化成奋斗的动力，可是今夕何夕，时代已经变了，早就不是那种兄弟们干完一个项目去吃大肉喝大酒就能继续精神抖擞住在公司的版本了。

无招也一直相信重新去上门走访小企业的就能找对钉钉的方向，因为十几年前就是这么成的，姑且不论这个归因是不是成立的，十几年前的企业市场是什么环境，哪时的低数字化、低移动化和今天又是一个情况吗？

把以前的方法再做一遍就能翻盘，世上哪有这么简单的事情呢？

我记得三年特殊时期那会儿，形势还不是这样的，行业里被嘲讽最多的企业软件，其实是飞书⋯⋯

当时飞书被评价为字节人效比最低的BU，大几千人做一款根本没怎么赚钱的产品，和字节底下各种印钞机业务相比，简直是家族的污点，同期钉钉靠着远程办公和网课开会的红利，数据暴涨，风光无两。

AI兴起之后，市场两极反转，飞书用远低于钉钉的活跃用户体量，拿到了差距逐渐缩小、快要接近五五开的收入规模，这意味着在让企业买单的说服力上，飞书是强于钉钉的。

我觉得无招是有心魔的，既然「云钉一体」是错的，既然把我请回来拨乱反正，那么钉钉就一定要独立发展，不能再受阿里的体系节制，这有点像矫枉必须过正的逻辑，用一个极端去回应另一个极端，钉钉的AI化很有野心，但兜不兜得住，非常依赖具体的成绩。

选择比努力重要也是这个道理，方向不对，就会越努力越错。

看得出来，无招很喜欢自己的这个花名，但他做的事情，和引起的内耗，都完全没有「无招胜有招」的松弛，这很可惜。

by @阑夕ོ #科技圈大小事

看了一个浙大计算机系硕士毕业的日本留学生写的对中国 AI 人才培养体系的评价。我摘录一些你们看看：

“中国 AI 得以发展的核心原因，在于其从出生那一刻便已开始的资本主义式的竞争机制。”

“在中国，努力是有回报的……如果拼死读书、学习计算机科学并进入一家好企业，顶尖群体在毕业起薪时就能拿到1500万日元（约合73万人民币）的年薪。”

“中国的重点高中，其环境堪比日本专门用于复读的补习班（浪人塾）……这里没有社团活动、没有文化祭，也没有恋爱。”

“对于来自农村、未能接受到良好基础教育的人来说，考研是提升学历、改变门槛的机会。同时，这也是转换专业的机会。如果能跨考到薪资优渥的计算机科学专业并进入更好的大学，人生就能实现逆袭。”

“然而，这种竞争彻底摧毁了在日本被称为‘人生夏休’的大学生活。为了应对在本科四年级举行的被称为‘考研’的硕士入学考试，学生在高中三年之后，还要被迫再经历四年的高强度学习。通过这种模式，中国人的基础学术能力得到了极大的提升。”

“中国的大学设有宿舍，每月的房租折合日元仅需2000日元左右（约合100元人民币）。食堂设施完善，150日元（约合7-8元人民币）就能吃饱一餐。这种设计让学生完全不必为打工或家务分心，能够做到全神贯注于学业。”

“如果不通过如此严苛的审核就无法硕士毕业，因此学生们只能夜以继日地做研究，想方设法做出科研成果。（这种机制，正是中国在AI相关领域拥有海量专利的原因所在）而且该制度执行得非常严格，即便是已经拿到了企业录用通知，延期毕业也是家常便饭。（我个人就在大学内部评审阶段被拒绝过一次，导致毕业直接推迟了3个月……）”

“在投入研究的过程中，一些在日本可能会被视作过于严厉的严苛沟通，在中国往往也会被全盘接受并视为正规的指导。”

“正是依托这套严密的筛选与培养机制，中国已一跃成为仅次于美国的AI大国。”

via tombkeeper的微博

还没等我出手，Kimi已经公开预测了这届世界杯的冠军，太不像话了。

在动用包含300个子Agent的集群，从战术、球员、伤病、赛程、历史、舆情、天气、心理、赔率变动、专家观点全都跑了一遍之后，Kimi预测可能要夺冠的是：

德国。

行吧，聊这个我可真不困了，作为一个战绩可查的资深⋯⋯中国体彩消费者，我对Kimi敢于立Flag的勇气，是深感尊重的。

要知道，从盘口来看，德国的赔率（9.5）并不低，在所有球队里排在第7位，所以Kimi并没有按照最大概率——也就是最稳妥的方案——去做判断，是真有自己的想法的。

当然，即便是选夺冠热门法国、西班牙，赔率（4.5）的风险仍然很高，说白了，早在开幕前就暴论最后的冠军，本身就是一件吃力不讨好的事情。

所以我才要狠夸Kimi的「敞亮」，不光是冠军，Kimi还要对全部104场比赛全都做出公开预测，包括赛后核验以及复盘，一场不落。

这就更硬核了，完全不怕打脸呐⋯⋯（注意，该预测非投注建议、非投资建议、非收益承诺。）

严格来说，Kimi并没有笃信德国是最有希望夺得这届世界杯的参赛队伍，而是认为德国的市场定价在强队里过于低了。

在使用了8种数学模型——包括SLO评级、Sixon-Coles泊松、XGBoost机器学习、Opta蒙特卡洛模拟等等——对48支球队逐一分析之后，Kimi得出了这么一个结论：

德国的模型预测概率，和市场赔率存在最高的偏差值，达到+3.6pp。

什么意思呢？

就是在判断德国是否有机会捧起大力神杯这件事情上，模型比市场多预测了3.6个百分点，所以认定德国，在理性上是回报确定性最高的选择。

就很像量化投资的策略，一家公司好不好并不重要，重要的是它有没有被市场正确定价，一家被高估的好公司，和一家被低估的差公司，显然后者更有买入潜力。

不同的是，量化机构需要雇佣一大票分析师，以及重金采购商业软件，而Kimi靠着几百个Agent昼夜不息的连轴转，自个儿就把整个项目给做完了。

BTW，搞价值投资的巴菲特最讨厌量化了，还贡献过「Beware of geeks bearing formulas」的金句，哈哈哈⋯⋯

我很推荐大家去看一下Kimi同时发布的预测报告，完整版PDF超过200页，量大管饱，如果看不下去，扔给Kimi让它帮你总结也行，递归循环了有没有？

另外就是，应该也不需要我特别说明吧，Kimi这么兴师动众的「Predict In Public」，并非是为了真的去当那个洞悉神谕的预言家，作为一家注重审美和趣味大模型厂商，它是在用一种奇观的形式，向世界演示AI的能力边界和局限性。

世界是可被编码的，这是AI得以成立的底层逻辑。

无论是图灵坚信思考是一个工程问题、而非哲学家心中的灵魂之类，还是香农在上世纪五十年代就用人类受试者去玩猜字游戏、用以论证智能始于对信息的预测，所有的历史研究和前沿走向都并轨于同一个共识：

凡事皆可压缩。

当人类知识的总和被压缩到了极致，就能制造一个通晓万物的机器出来，它能通过模拟已经存在过的和还没有发生的所有过程，去得到每一项任务的最优解。

这听起来很科幻，也足以引起事关自由意志的思辨，但我们正确切的走在这条路上，大模型的运行原理就是预测下一个词元，这是众所周知的，香农的遗憾在于他买不到英伟达的GPU。

所以能够理解Kimi为什么要预测世界杯了么？

面对这种长链路、随机性、没有标准答案的复杂目标，如果AI也能完成媲美甚至优于人类表现的任务，那么它在通用性层面的可用，就不再存疑了。

2010年的世界杯，数以亿计的人类在围观一条名叫保罗的章鱼，用它黏糊糊的触手从闭合的箱子里选择比赛赢家。

16年后，开箱的角色变成了连生物都算不上的AI，从克苏鲁的古神符号，到后现代的赛博朋克，如此交替，本身就充满了隐喻。

隐喻那种不可言说的混沌，让渡给了可被测量的科技。

这让我想起在自己投入了无数个通宵的游戏「文明6」里，解锁信息时代的科技之后，会出现在屏幕上的那句台词：

「现在天上有31颗卫星在地球上空环绕，不为别的，就为了告诉你便利店怎么走。」

取之于硅，用之于碳，这才是AI正确的打开方式，对不对？

by @阑夕ོ #AI探索站

「福布斯」杂志报道了一种新型外围女的出现：Nerdy Escorts（科技宅名媛）。

众所周知，今年是上市大年，Anthropic、OpenAI、SpaceX全都是造富大户，而谷歌、英伟达等公司为了留人也不吝开出大额支票，前五家科技公司年内光是薪资税金就要缴出600亿美金以上。

盯准这些一夜暴富的程序员，有少部分传统的「商务模特」成功转型，把自己的每小时收入从几百美金提高到了3000-5000美金的级别，而且供不应求，档期排满。

她们的秘诀就是除了常规的上床之外，还愿意努力学习那群科技宅男擅长的话题，比如聊光模块、谈大模型、预测AGI等等，用流行的话来讲，就是能够稳稳接住客户的情绪价值，从而拿到了远超卖肉的服务费。

图上这个就是「福布斯」采访的其中一位从业者Meida Marek，看得出来她也坦然且愿意借助媒体宣传自己，所以在对谈里讲了很多大实话。

Meida Marek有大学学位，2024年毕业，在盘点自己的优势时，她发现除了长得漂亮、身材不错之外，在同龄人里，她是少有的能够理解高收入技术人群想聊什么的年轻女性，比如把一顿形式主义的睡前晚餐变成长达三小时的激烈辩论，而且客户往往非常享受于这种对等的思想交流，这在他们的人生经历里是不曾存在过的体验：

上学时是被班花们忽视的底层做题家，有钱后又只能吸引到胸大无脑的职业美女，当Meida Marek这样高知又性感的名媛出现在身边之后，会极其感动的向她们支付远高于市场的溢价。

Meida Marek说自己的日程已经排到了几个月后，正在考虑继续涨价，她会优先选择AI行业的客户，因为钱多事少懂礼貌，最近订她占比最高的，是英伟达公司的员工⋯⋯

这些科技宅名媛也会互相交流获客经验，并且得出一些共识，比如一定要开通x账号，除了发自拍之外，还得积极参与模型发展、生命科学等专业话题。

作为其中的头部从业者，Meida Marek的做法更是「精准打击」，她把自己的预约页面设计成了一个文字类RPG游戏，用户必须完成互动之后才能约她，而她的简介里，则写着曾经编过软件代码、对「龙与地下城」非常沉迷等信息。

戳中程序员们心窝的程度可想而知⋯⋯

Meida Marek目前的服务定价是3500美金/小时，她的好闺蜜Ada Hopper更牛逼，收费5000美金/小时，而且说得特别好笑：

「每天上网就是在随机刷出一些英伟达Bro，他们会惊讶的表示——什么？你知道什么是GPU？我去，太厉害了！」

Ada Hopper说，在这个行当，最赚钱的未必是最好看的妹子，你可以不是顶美，但聪明+小美的组合最能斩男，AI热潮就如淘金，实现致富的一定不是矿工，而是卖铲子的服务层，自己也是其中之一，为那些挖金子的人，提供温柔的陪伴。

「自闭症」这个马斯克同款的标签也是加分项，很多科技宅名媛会标注在简介里，承认自己患有这种疾病，是和那些真正被排挤过的男性客户拉近关系的捷径。

下海之前，Ada Hopper是在金融行业工作，预判到AI造富趋势之后，她果断投入了2万美金购买内衣、设计网站和拍摄写真，并开始广泛补课各种宅男技能，因为跟不跟得上话题强度，是决定复购率的关键。

比如她要懂得爱德华时代的服饰细节，对蒸汽朋克的钟表了如指掌，能对吹制玻璃器皿的方法谈笑风生，甚至当客户送上一套Mac Mini之后，她要现场安装运行OpenClaw以示欣喜⋯⋯

这钱赚得，也不容易。

Meida Marek也认同「兴趣交集」的重要性，她有一个客户，辞掉交易员的工作后创办了一家AI公司，他会用3万美金的包天价，让她飞到纽约陪自己过周末，还为了配得上她而减掉了不少体重，两人在高级餐厅唇枪舌剑，最后得出了一条双方都接受的思辨结论：对于聪明人而言，永生是一种道德义务。

科技宅名媛里甚至也有少数男模，他们的服务对象通常是高薪程序员的太太，这些人妻称自己为「Claude寡妇」，顾名思义，就是老公完全沉溺在了和Claude共度昼夜的生活里，以致于妻子也要在市场上找寻可被关心的替代品。

「福布斯」也采访了一些男客户，他们的共同点是：富裕、年轻、忙。这些人希望购买一种类似亲密关系的体验——有人在意自己、可以同桌聊天、以及在合适的时候到床上去——却又不想承担正常恋爱里的摩擦、拒绝和不确定性。

他们甚至创造出了一个梗：「单身直到B轮」，这句话被印在T恤上，半是玩笑，半是自白，意思是在公司正式上道之前，亲密关系被视为拖累自己的负担，所谓女人只会影响我拔剑的速度。

另外就是，这些人对于「老登消费」兴致不高，在兑现了高额期权之后，他们既不想买保时捷，也无意戴上劳力士，唯一的共识是，自己的时间很宝贵，所以花钱买时间，是很有必要的。

最后接受采访的科技宅名媛，是拥有硕士学位的Charlie Levine，她认为随着AI越来越普及，拥有真实的情感关系也会变得越来越稀缺，而负担得起别人为你付出真心，将成为一种奢侈品。

「当然不能把所有问题都推给ChatGPT，在没有AI的时代，有钱且孤独的人也一直都会为性付费，被AI改变的，是计算方式，当机器能以订阅包月的价格，提供秒回、顺从的扮演时，那么扮演本身就不再昂贵了，昂贵的事那个会说错话、会尴尬发笑、会反驳某个观点、会让整个房间感觉不像一个提示词的人。」

于是，这个行业就构成了一个阴暗的循环，AI让模拟出来的存在感变得普惠和充足，同时却又制造出了一个愿意为AI无法提供的东西付出高价的富裕阶层，去购买一个真实的人所能给予的注意力。

by @阑夕ོ #科技圈大小事

最近半年疯狂在用Codex，整理一下目前我最常用的10个日常场景。

1、产品需求池自动管理

开发赚钱的虚拟产品，首先是对核心需求的掌握。所以，我把用户反馈、评论区、私聊记录、差评、退款理由、同行产品页都丢进去，让 Codex 自动整理，甚至专门做了一个skill，判断：

解决的到底是用户什么痛点
交付轻，售后压力低，
尽量自动化
需求长期存在，
不过度依赖单一平台
用户容易理解，没有太多心智成本
竞争不激烈，没几个同行做

让Codex 帮你判断需求质量。现在最重要的能力不是“开发能力”，而是需求筛选能力

代码可以让AI写，但需求判断错了，写得越快，亏得越多。

2、自动做竞品拆解

除了从需求分析，还会让Codex做同行竞品的拆解。这件事很重要。
有很多产品，看起来销量不错，但一拆就发现，交付很重，售后很多，并不适合我这种想做轻交付、可自动化、一人公司模式的人。
所以我现在看竞品，不是为了抄。而是为了看清楚谁在卖，卖给谁，卖什么，怎么交付，利润空间在哪里，风险在哪里，还有没有没被满足的小需求，我去做，有什么独特的优势。
谋定而后动。

3、开发赚钱产品

前面讲的是需求判断，需求判断完之后，下一步就是把它开发成真正能卖钱的产品。这一点本来就是 Codex 最基础的事情:写代码。
以前做一个产品，很容易从零开始想。现在不是，现在是套流程，先判断需求，再拆核心功能，再确定页面和交付链路，再决定后端和数据库，最后部署上线，根据用户反馈继续迭代。这样一来，开发速度就非常快。
很多虚拟产品，本质上底层技术结构都很像，只是换了不同用户、场景和内容一旦模板跑通，后面就不那么吃力，而是复制、改造、组合、上线。
这也是我现在接定制项目的底气。因为客户要的东西，就是把一个需求变成能用、能交付、能上线、能收钱的产品。Codex 负责提高开发效率，而我负责判断需求、设计产品结构、把控交付边界、控制成本和风险。
所以我现在对 AI 编程最大的感受是，它不是让我变成一个传统程序员，而是让我有能力把一个赚钱想法，更快变成一个可交付的产品。
做得越多，积累越多，开发越快，我就越能抓住市场里的小机会。这才是 Codex 对我真正的价值。

4、自动整理卖点+作产品海报
产品做出来之后，下一步不是急着发售，而是先把卖点讲清楚。很多产品不是没价值，而是用户看不懂。你自己知道功能很多、很有用，但用户只关心一件事：这个东西到底能不能帮我解决问题？
所以我会把产品功能、用户痛点、竞品页面、用户反馈、聊天记录丢给 Codex，让它先帮我整理：这个产品适合谁，解决什么问题，能节省什么时间，能减少什么麻烦，为什么值得买，买完之后能拿到什么。
这些问题整理清楚之后，再让 Codex 基于卖点生成对应的商品海报。
产品做出来只是第一步。能不能把价值讲清楚，才是真正进入销售阶段。

5、搭建产品文档和交付说明
虚拟产品最怕一件事：东西做出来了，但用户不知道怎么用。
所以我会让Codex 帮我把产品自动整理成，使用教程说明书。
这样可以减少大量重复沟通。
6、用 flomo MCP 搜索素材写稿
写文章时，我会直接让 Codex 从 flomo 里搜索相关素材。
以前写一篇文章，要自己翻笔记、找案例、回忆之前讲过什么。
现在可以直接让它把相关笔记都捞出来，再按主题、观点、案例、金句整理。
这对我这种长期写作的人很有用。
因为真正有价值的内容，不是临时编出来的。
而是过去长期观察、思考、实践之后，被重新组织出来的。

7、用飞书CLI存稿入库
写好的稿件，我会通过飞书 CLI 直接存入飞书知识库。
不用再手动复制、粘贴、改格式、建文件。这类动作单次看起来不大，但每天重复，非常消耗人。
Codex 最适合干重复、琐碎、低创造力，但又必须做对。能自动化的，就不要用自己的注意力去换。

8、建立内容创作系统日报
我用 Codex 设置了一个内容创作系统轻量日报。
每天自动帮我回顾，哪些选题可以推进？哪些素材值得捞出来？哪些草稿需要继续处理？哪些文章可以改成视频？哪些内容可以导向产品？哪些旧内容可以重新分发？
这个东西特别适合自媒体人。
因为自媒体最大的内耗之一，就是每天都觉得自己要重新开始。
但其实你过去积累过很多东西。只是需要一个系统每天帮你捞起来。

9、自动做小红书封面

现在做小红书封面，我基本也会交给 Codex。
主要有两种方式：一种是看到不错的同行封面，就把图片丢进去，让 Codex 做多模态分析，拆出它的标题、排版、颜色、结构和视觉重点，然后在这个基础上稍微改一版，变成适合自己产品的封面。
另一种就是直接把产品卖点和笔记主题给 Codex，让它生成几版不同风格的封面图，不断测试哪种点击更好。封面这件事以前很耗时间，现在基本就是丢进去、分析、改图、测试。
稿定会员我都不充了。

10、其他零碎的杂活，我也是能用就用Codex，会有意外的惊喜

by @辉老板 #AI探索站

昨天去建材市场看瓷砖的时候，碰到一个福建老板，他代理的是一家叫做蒙娜丽莎的瓷砖。他自己的感觉是，过去几年建材行业发生了很大的变化，总体来说真的很难做。

主要有以下几点原因：
1. 家装市场整体在萎缩。
- 如果和开发商合作，只能做流水，实际上中间的成本非常多，基本上就是做一单亏一单，还要垫钱。
2. 如果做家装，需要和独立设计师以及一些装修公司合作。
- 国内像统帅、尚层以及大型装修公司，官方返点就是30个点，有的时候还需要给工程部的人和那些明星设计师额外的返点，平摊下来返点率要超过50%。如果不做这些返点，就得想办法去做团购或者小红书等渠道。
3. 关于小红书渠道：
- 我问他小红书好做吗？他说之前代理的是一个小品牌，要靠小红书上的团长发团购来做。小红书的团长总体来说比较好，一般只给3~5个点。但有些热帖需要加热，加热完以后来的线索转化很低。他去年在上面投了十几万，最后效果很差，主要原因是品牌本身没有势能。

价格高了，客户就跑，咨询的客户质量也参差不齐。几千块钱的消费，让你服务一堆东西。瓷砖还涉及到交付和退补货，如果利润不高，低于20个点、30个点，这个业务几乎是没法完成的。

现在在中国的话，平均下来：
* 一个800×800的中小规格的砖，差不多也就是三五十块钱。
* 一个600×1200的砖，可能也就是五六十块钱。
* 一个750×1500的砖，也就是一百块钱出头。

这可能是一线品牌的一个平均报价了。二三线牌子还要打七折。这其实比十年前都要便宜不少了。

但他对自己加盟蒙娜丽莎品牌还蛮有信心，也觉得收获蛮大。因为品牌有势能，势能意味着有自然流量，有自然流量成交的效率就会高很多。然后他也愿意去做一些新小区的团购，虽然现在为止要赚钱相比较过去是很难的。

我问他，为什么你去建材城永远得不到真实的价格？

他说很简单，因为他不知道你是哪儿来的，不知道你的真实意图。他报低价是只有风险没有好处的。绝大多数人到美凯龙这样的地方只是选型，他最后的决策可能来自于个人工作室，或者装修公司。而装修公司几乎和大型品牌都有绑定关系，平均的返点率就得30%。如果你报了低价，成交了，最后装修公司上报，你还得把返点吐出来，最后就倒贴钱。所以一些大的建材品牌，无论是像一些地板、瓷砖、卫浴，以及一些国内的淋浴房品牌，你都很难问到真实的价格，除非你明确的告诉他你所在的小区（豪宅就不说了容易被薅），以及是独立工作室设计，否则根本拿不到真实的价格。

by @杨天楠 #你不知道的行业内幕

赌场：
把现金换成筹码
然后找台老虎机
开始试手气
觉得运气好开始切高倍率
结果输得很惨
然后老实重新开局
中了个小奖，各种声光特效

vibe coding：
把现金换成credits/tokens
然后找个agent
开始试手气
觉得运气好开始切高倍率模型
结果出来的代码不是想要的
然后老实重写prompt
AI说你说得对，会稳稳接住你

有谣言说《给阿嬷的情书》在抖音花了2000万做宣发。

这事我门清，《给阿嬷的情书》总制作成本1400万，其中宣发预算只有廖廖几万，蓝导根本没想到会全国大爆，主配角里有五位潮汕本土网红，又动用了广东文旅局。

在当时的蓝导眼里，自带流量已经很顶了…

老年叶淑柔：吴少卿，@CK阿嬷 @CK不暴躁 电影上映前90万粉
谢南枝爸爸：方培松，@哇乐机 60万，他儿子@麦乐瑟 300万
客栈老板娘如姨 @潮汕如姨爱唱英语歌 38万
孙子@狗哥电影 + @万二之首 全网20万
邮差@陈海鑫 12万
拢共有500万粉丝的号召力

蓝导连大投资都拉不来的一个人，兜里分币不剩，只能靠潮汕五红+广东文旅局+高频路演做宣发，最初票房预期是5000万，能回个本+小赚。

五一期间阿嬷总票房4380万，已算满足预期，毕竟小语种，无大咖，没钱覆盖式宣发。

大麦娱乐是《给阿嬷的情书》唯一宣发方+第二出品方，大麦在蓝导拍完潮汕三部曲第一部后，决定投蓝导第二部和第三部戏，从此摇身一变知名伯乐。

大麦很少出钱做宣发，它有很强的站内资源和场地资源，常常以小博大，这次大麦协作组织了110场全国路演，已经算倾尽全力。

就算大麦加投宣发，在抖音一家投2000万，那简直是天方夜谭了…

青年谢南枝的演技好吧，她抖音账号@薯条tonton 到现在都只有4万粉丝，投流在哪里？预算在哪里？符合2000万的宣发效果？

2000万单平台是什么概念呢？
大概是春节档的曝光量，流浪地球2的半月水平。

蓝导做梦都想不到会有今天这等规模的口碑传播，他也没有这个钱去推广，还没分账呢。

院线票房一般是次月才分账，涉及到每一家影院的票房统计、扣税、核对数据等等，最快的结算能做到15天，最慢的3个月。

在这段时间里，蓝导能从哪里掏出来2000万付给抖音？算上其他平台得4000万了吧。

大麦娱乐能给蓝导垫付4000万？
凭交情义气？还是凭战略眼光？
直接垫出去五一档全部票房？
那时才刚刚保本啊。
要不怎么说人类最丰富的是想象力呢。

《给阿嬷的情书》五一档根本没发力，最多的一天票房1040万，5月10号母亲节才突然爆到了4000万，大家误以为是孙子/孙女写给奶奶/外婆的情书，全国观众拖家带口当温情片去看的，结果故事出乎预料的好，随后口碑传播才一发不可收拾。

分享情绪酝酿三天。
5月14-15号阿嬷正式破圈传播。

大麦最多再垫资个几百万，但是根本不需要了，已经有了人传人的恐怖现象，一路飙升到全国都爱看，我在各种群里看到朋友推荐了十几次，自己看完写了篇影评，5天1.3万赞。

像我这样的自来水太多太猛了啊，只有没看过的人，才会疯狂质疑全网都是宣发营销…

这部电影实在太克制了，观众们在影厅里宣泄不掉的情绪，溢出来变成了奔走相告。

by @兔撕鸡大老爷 #你不知道的行业内幕

马斯克起诉OpenAI的官司还是败了，这个倒是没有一点意外。

几次庭审虽然没有直播，但很多媒体都拿到了旁听席位，会有完整的问询记录流出，全程追完之后，只能说马斯克输得不冤。

从PolyMarket的盘口也能看出，庭审前马斯克打赢官司的概率最高能够接近45%，庭审后就降低到了30%左右，说明两边证词对完账，主要还是对马斯克不利。

双方的代理律师也完全符合各自的风格，马斯克的律师跟马斯克一样高举高打，特别具有攻击性，同时金句频出——或者说密集爆典——让我记忆深刻的是他向陪审团这么提问：

「想象一下，你们正在山里徒步，需要过一座独木桥，这时有人指出，那座桥的建造材质是山姆·奥特曼的真相，你们还会过桥吗？」

😆

对于法官来说，律师的脱口秀效果当然不是一个加分项，相比之下，OpenAI的律师更善于利用对方证词的漏洞。

比如马斯克申请传唤的证人、同时也是给他生过4个娃的特斯拉早期员工希冯，让她出示OpenAI早期承诺保持非营利结构的邮件。

而OpenAI的律师做了更多的功课，完成了一次非常精彩的局部反转，他让希冯同时承认了，在试图掌权OpenAI失败之后，马斯克开始疯狂挖OpenAI的人，包括我们现在都很熟悉的Andrej Karpathy，甚至想让山姆·奥特曼投奔特斯拉干AI⋯⋯

整体下来的感觉就是，马斯克想要建立的那套叙事，也就是OpenAI被一小撮人给密谋窃取了的剧本，很难成立，因为这个指控必须由严密的一套计划支撑，而且还得成功欺骗所有利益受损方，但马斯克拿不出来足够的证据。

你不能说一家公司的经营方针变了，就是被掉包了，你也不能说山姆·奥特曼及其「党羽」的人品不行，所以他们就是窃国大盗，包括马斯克本人的成功在这次官司里也成了负资产，有法学专家表示：

「他是这个星球上最聪明的人，财力雄厚，律师成群，所以他要说自己在长达数年的时间里被系统性的欺骗了，这怎么可能呢？」

😅

而且很不凑巧的是，马斯克原本准备好的说辞，和现实版本正好冲突了，他说OpenAI和苹果的「勾结」是影响恶劣的垄断，会断送其他AI公司的发展机会，但实际上在另一个案件里，OpenAI正在起诉苹果对合作的支持不力，根本没有给ChatGPT导流⋯⋯

微软的CEO纳德拉也是被传唤的证人之一，他的证词基本上对最终的结果盖棺定论了，他说在微软从2019年开始投资OpenAI，直到2023年ChatGPT大火，马斯克都从来没有联系他表示异议。

所以，法官的判决意见并不在于马斯克是对是错，是这起诉讼的发起时间太晚了，晚到「司马昭之心路人皆知」，马斯克是在报复，而法庭不能为了取悦他的私心，就毁掉一家正在蓬勃发展的公司。

by @阑夕ོ #科技圈大小事

gdb 的 call 大家都很熟悉了，不过它是如何实现的，这个问题困扰了我很多年，我阅读巨型项目源码的能力很差，大脑上下文只有 64 字节，以前硬啃 gdb 源码失败过很多次。但现在，感恩 codex，感恩百年未有之大变局。

我们直接来到最核心的部分，现在被 attach 的进程 (我喜欢称之为 debuggee，但 gdb 用的是 inferior) 已经被 ptrace 暂停在了断点，rip 指向断点的位置，我们执行 call printf("233\n")。以下只关注 x64。

第一个核心细节，gdb call 并不调用 call 指令。如果熟悉 bpf fentry 的实现就会知道内核是用 call trampoline 来做了一层“装饰器”，但 gdb call 并非如此，而是直接修改 rip 指向 &printf，让 cpu 硬跳转过去。https://github.com/MIPS/binutils-gdb/blob/37cb3cd8f896b8d0aa95ced818c6c7b1fb9ddc99/gdb/infcall.c#L1478

we don't execute a call instruction to call the function

第二个核心细节，构造 LR(return address)。rip 直接指向 &printf 确实可以跳过去，但是 printf 运行结束后的 ret 弹出 LR 到 rip 决定了 call 结束后的执行流，gdb 构造了一个特别的 LR 压到栈上，让 printf 结束后跳到↓。这个地址在 gdb 里叫做 bp_addr，根据系统架构 gdb 会自动选择 ON_STACK /  AT_ENTRY_POINT。

第三个核心细节，LR 指向用户栈某地址，where 写着 int3 指令。这真的很特别，特别在它有两层，第一层你以为它构造了一个 int3 让 call printf 结束后跳 int3，进程进入 trap stop 被 gdb 接管做一些收尾工作，然而这是不对的；真实情况是在第二层，int3 写在用户栈上，但用户栈内存没有 executable permission，不能执行写在这里的指令，所以 pop 这个栈地址到 rip 之后内核会抛出 SIGSEGV，然后 gdb 捕捉了这个预期的信号，把它当做 SIGTRAP 处理。这一步真的非常邪门，一开始 codex 读代码也读错，gdb 的注释也不太匹配，我亲自做了很多实验和检查，和 codex 吵了很多轮，确定了这确实是 x64 gdb 的逻辑： https://github.com/MIPS/binutils-gdb/blob/37cb3cd8f896b8d0aa95ced818c6c7b1fb9ddc99/gdb/infrun.c#L6327

[...] We do
something similar for SIGSEGV, since a SIGSEGV will be generated
when we're trying to execute a breakpoint instruction on a
non-executable stack. This happens for call dummy breakpoints
for architectures like SPARC that place call dummies on the
stack.

第四个核心细节，call 使用的栈直接跳过 x64 红灯区。精确来说，断点时刻 rsp 指向的是 debuggee 栈，但 call 用的是 rsp-128，这 128 字节在 gdb 里叫做 x64 red zone。上面说的栈上 int3 也是写在这里（bp_addr），rsp-128-1（int3 指令只有一个字节）；然后 rsp-128-16 作为 call 开始使用的栈，先把参数压栈，然后是执行栈。

第五次核心细节，堆上内存优先用 malloc 分配。我确实也很震惊，因为并非所有 debuggee 都有 malloc，怎么 gdb 会 call libc 函数。比如 call printf("233\n") 就会用堆上内存，把 "233\n" 写在堆上，然后 rdi 指向这个堆地址作为参数传递。我本来以为 gdb 会用 ptrace 注入 mmap syscall 给自己分配一小块内存，没想到竟然是 malloc。使用 gdb 命令 set debug infcall on 可以看到这是真的：

(gdb) set debug infcall on
(gdb) call printf("233\n")
[infcall] call_function_by_hand_dummy: enter
  [infcall] call_function_by_hand_dummy: calling __printf
  [infcall] call_function_by_hand_dummy: enter
    [infcall] call_function_by_hand_dummy: calling __GI___libc_malloc

让 gpt 花了一张示意图，费劲。

其实 gdb resume from breakpoint 也很魔法，下一期再见👩‍💻

住了500晚酒店才知道，为什么一定要订双床房。

我一直推荐大家住酒店的时候一定尽量订双床房。
即使一个人住，也要订双床房。
情侣住，也不要犹豫，还是订双床房。
大多数人住酒店选房型的逻辑是这样的：一个人住，选大床房。两个人住，选双床房。

但这个看起来非常合理的逻辑，实际上让你错过了一个亿。
且听我细细道来。

第一，双床房实用面积大。

很多人可能会认为大床房少一个床，应该更宽敞才对。其实不是。
同等级别的双床房和大床房，房间建筑面积基本一样，都是25-40平米。但也有的双床房会比大床房面积要大一些。另外，要塞下两张1.2米的床，酒店必须给双床房留出更多的走道和活动空间。两张床之间要有床头柜，两侧要有过道，这是设计规范的硬性要求。
而大床房呢？一张1.8米的床往房间正中一摆，左右各一个床头柜，视觉上显得大，但实际可活动的面积反而更紧凑。

更重要的是，双床房你多了一整张床的台面。
第二张床是什么？是你的行李台、衣服架、工作台、零食摊。
出差的人都知道，酒店房间里最稀缺是平面。你的电脑要放，充电器要放，文件要放，换下来的衣服要放。大床房里，这些东西只能堆在桌子上、椅子上、甚至地上。
双床房里，另一张床天然就是你的第二空间。衣服铺开晾着，行李箱的东西打开拿出来摊着，干净利落。你住过就知道，那种秩序感带来的舒适度，比大床多出来的那几十厘米宽度实用太多了。

第二、双床房能实现真正的干湿分离。

情侣或者夫妻出去旅行度个假，晚上高兴了，难免会有些对抗比较激烈的体育活动。比如打个篮球啥的
大床房只有一张床，经常打篮球的朋友都知道，1V1斗牛的过程中，有时候打到兴起了，两个人会频繁的有较激烈的身体对抗，也难免会在赛场上挥汗如雨，大汗淋漓。这在体育赛事中都是再正常不过的了，但打完比赛双方的身体都会很疲惫，谁也没有精力打扫战场，但是也没有备用的场地用来休息，这样体验就会不太清爽，影响睡眠，还会影响第二天的行程。

那双床房就不一样了。一张床负责对抗，一张床负责休息。打完比赛了，倒头就睡，一夜好梦。
真正的做到了干湿分离。
这是实实在在的生活智慧。
关注我，解锁更多酒店玩法。

第三，双床房更容易升级。

一家五星级酒店，一般双床房占总房量的60%-70%。例如一家560间房的酒店，双床房少说400间。它是酒店的基本盘。
当你订了一间标准双床房，酒店发现当天双床房快满了，但高级房、豪华房甚至行政房还有空的，酒店就可能主动帮你升上去。
原因是酒店要"腾笼换鸟"。把你从标准房升走，空出来的标准房可以卖给后面临时上门的客人。酒店不亏，你也白赚。

万豪体系里，金会员通常升一级，白金升两到五级。希尔顿的金会员和钻石会员也是类似的逻辑。
但大床房本来就少，酒店不需要腾这个位置。而且大床房往上对应的高级房型也少，酒店不会轻易把套房给一个订基础大床房的客人。

第四，双床房更便宜。

同样级别的房型，大床房经常会更贵，或者同价但更难订到。
为什么？因为大床房数量少，情侣和度假客群对它的需求高，稀缺性推高了价格。酒店也乐于用大床房锁定这些愿意花钱的客群。

但你多花了这20%，得到了什么？一张1.8米的床。和你家里的床一模一样大。你在家睡1.8米的床觉得正常，换到酒店就觉得"好大好舒服"，那是因为酒店的床垫、枕头、床品确实好，不是因为尺寸。
双床房里一张1.35米的床，一个人睡，翻身自由，四肢舒展，睡感不比大床差。

你花更少的钱，得到了：更大的实际空间、更好的卫生间布局、更高的升级概率、以及一张免费的万能置物台。
怎么算都是双床房赢。

第五，双床房能选到好位置的概率更高。

400间里面挑一间给你，和100间里面挑一间给你，哪个更灵活？
双床房数量多，分布广，覆盖了高楼层、低楼层、东南西北所有朝向，安静面和电梯旁都有。你在check-in的时候提一个小要求，高楼层、安静一点、远离电梯。前台有400间的调配空间，大概率能满足。
大床房很可能就不行了。总共几十间，分到哪间就是哪间，好坏全凭运气。

第六，双份早餐。

双床房几乎百分之百配两张早餐券。大床房就不一定了。
很多酒店的大床房分两种：含双早和含单早。含单早的便宜几十块钱，但如果你带了另一半，第二份早餐要单买，五星级酒店早餐单买一份动辄150-200块。你省的那几十块，一顿早饭就亏回去了。

双床房没有这个陷阱。两张床，两份早餐，天经地义。
第七，一个你可能没想过的场景：拼床。
三口之家出去玩，很多人习惯订大床房。一家人睡一起嘛。
但实际上1.8米的床，两个大人加一个孩子，真的挤。尤其孩子过了三岁，手脚乱蹬，一晚上谁也别想睡好。

双床房就简单了。两张1.2米的床拼在一起，瞬间变成2.4米的超级大床，比任何King Size都宽。很多酒店的双床房两张床就是可以推到一起的，你打个电话给前台说要拼床加个床垫，他们轻车熟路。
一间房的价格，2.4米的床，解决全家人的睡眠问题。

这件事的本质是一种思维方式。

我们习惯做选择用的是匹配逻辑，我一个人住，所以选大床房。需求和选项对应，感觉很合理。

但实际上我们应该用的是冗余逻辑，哪个选项给我留的余地最大？哪个选项的上限最高？哪个选项出错的概率最小？
双床房就是那个余地最大的选项。

双床房就是那个余地最大的选项。

by @风小海 #你不知道的行业内幕

SQLite tips：

1. https://www.sqlite.org/wal.html
pragma journal_mode = wal，这个简直是必须的，坏处非常微小，而会让你的数据库可以同时有任意多个只读事务外加一个读写事务。

2. https://www.sqlite.org/stricttables.html
可以把所有表都创建成 strict table，其中明确想保存自由类型的列用 any 类型就行。

3. 默认配置下，删除大量数据后，只能通过 vacuum 来释放不再需要的空间，它的原理是完全复制一份新数据库，再删除旧的，在磁盘很满时做不了。可以看一下自己删数据时用的连接是不是 pragma secure_delete = 1 的（或者先设置这个再删），如果是，就有一个巧妙的做法：确保停掉所有数据库连接，然后对数据库文件做 fallocate -d。这会把删掉的数据的位置都挖成洞，过程中不额外占用空间，并且业务中断时间也短得多。

pragma secure_delete = 1 的效果是把删除的数据都用 0 覆写，如果想让删除的性能更高，也可以关掉这一功能。

想方便地回收空间的话，标准做法是在创建任何表之前，先为数据库设置 pragma auto_vacuum = 1 或 2（详见文档），这会使数据库记录每个页面被引用的位置，使得空白页面可以和尾部的非空白页面交换，然后再 truncate。唉，要是 SQLite 能在可打洞的文件系统上用打洞来删除数据，secure_delete 和 auto_vacuum 的效果就都可以更低开销地实现了。

一边玩情趣玩具一边倍速刷完了 4th bpf 中国开发者大会视频 (https://space.bilibili.com/518970180/lists/7986231) ，质量还挺高的，比某些广告con好多了，随机发表感想：

陈鹏飞-基于eBPF的端到端请求追踪
对 HTTP1.1 注入 OTel headers，用 sockmap + sk_msg + bpf_msg_push_data 的做法，我的评价是没有吃过 sockmap 的巨型虫子不知这水有多深😀你在生产环境跑一个试试，go 程序默认开启的 mptcp 一秒就把 sockmap 崩了。
https://github.com/IntelligentDDS/zerotracer/blob/b9e2f2170e4508a251b5a30fd1199dca142ebb5d/src/bpf/tracing.bpf.c#L435

陈涛-eBPF内核栈解析特性现状及发展
最有含精量的是指出 bpf_get_stack 甚至 perf record 可能采集到其他进程的的栈，这是由于内核函数 get_perf_callchain 对同一个 cpu 会复用 callchain_entry，如果 process A 已经采集了栈还未返回，然后被 process B 抢占，而 process B 也执行 get_perf_callchain，那 B 的栈就覆盖了 A 的栈，等 A 调度回来恢复执行的时候返回的就是 B 的栈。实在是深邃的观察！👍
https://lore.kernel.org/all/20260206090653.1336687-1-chen.dylane@linux.dev/

黄富-给上游引入global percpu data特性
请关注 @eBPFTalk001 喵，请关注 @eBPFTalk001 谢谢喵。

黄竹刚-eBPF开发的10个实战陷阱
我参与写作的新书《eBPF 云原生安全：原理与实践》目前正在新鲜发售中

赵翔宇-面向Kubemetes的eBPF 云原生可观测实践
bpf 抓包抓得我眼前一亮，一般抓包就是把 skb header+payload 塞到 ringbuf 让本机用户态读出来，然后爱上报上报；这位同性居然把满足过滤条件的 skb redirect_clone 到 vxlan0 然后封包送到远程的抓包中心化服务器，太聪明了👍

曲盼旺-融合 eBPF 与 AI 技术的微架构能效分析研究
关注的是 CPU 硬件功耗而非软件的性能，通过 bpf 采集八项 per-task 的 PMU 指标（insns, cycles, stall-be, stall-fe, etc.），建立一个硬件能耗和他们的线性回归，这样可以在多重热点事件混杂时做归因。我觉得很有意思。

郑昱笙、于桐、李嘉耀-bpftime for GPU:将eBPF扩展到GPU上
工作量和复杂度都很惊人，我直接照抄一下它 nv_attach_impl：
Frida-gum hook __cudaRegisterFatBinary() 拦截 -> cuobjdump --extract-ptx 提取 PTX -> PTX pass 变换 -> LLVM 编译 bpf 成 PTX -> Register Guard -> nvPTXCompiler 编译 PTX 成 cubin -> 替换 GPU module
（如果 n 厂能官方收录这套方案就好了，球球了）

焦德伟-基于eBPF的带内带外协同能耗管理技术研究与实践面向LLMToken成本最大化
虽然没有听懂，但是和榨干硬件不同，speaker说大模型推理512上下文和4k上下文功耗相同，可以做 gpu 节能，拦截 ioctl(NVML_API_FUNC) syscall 返回，提取 GPU 状态参数，通过 IPMI out-of-band 接受 BMC 的策略，修改 ioctl 响应，降低功耗。

其余还有好几个 storage IO、bpf scheduler、bpf reuseport、bpf RDMA 等震撼内容，我水平有限正在学习😴

Bilibili

Linux内核之旅的个人空间-Linux内核之旅个人主页-哔哩哔哩视频

哔哩哔哩Linux内核之旅的个人空间，提供Linux内核之旅分享的视频、音频、文章、动态、收藏等内容，关注Linux内核之旅账号，第一时间了解UP主动态。

Copy Fail (CVE-2026-31431) 核心分析

这是一个极其危险且优雅的 Linux 内核本地提权漏洞，732 字节 Python 脚本直取 root。

───

为什么它不一样

| 漏洞         | 条件           | Copy Fail    |
| ---------- | ------------ | ------------ |
| Dirty Cow  | 需要竞态条件，可能崩溃  | ❌ 不需要        |
| Dirty Pipe | 版本特定，需精确管道操作 | ❌ 全版本通吃      |
| Copy Fail  | 直线路径，无竞态，无重试 | ✅ 一个脚本跑所有发行版 |

恐怖之处：

• 跨发行版：Ubuntu、Amazon Linux、RHEL、SUSE 全中，无需改脚本
• 隐蔽：只污染 page cache，磁盘文件不变，文件完整性校验（checksum）检不出
• 跨容器：page cache 全系统共享，容器逃逸 + Kubernetes 节点沦陷（Part 2 会讲）

───

技术根因（三层叠加）

2011: authencesn 加入内核（IPsec ESN 支持）
       ↓ 用调用者的 dst buffer 当 scratch pad，写超出边界
2015: AF_ALG 支持 AEAD + splice() 路径
       ↓ splice 能把 page cache 页直接塞进 crypto scatterlist
2015: authencesn 迁移到新 AEAD 接口
       ↓ 引入 assoclen + cryptlen 越界写
2017: algif_aead 加入"原地操作"优化 ← 致命一击
       ↓ req->src = req->dst，page cache 页被链进**可写**的 dst scatterlist

三层独立合理的改动，在 2017 年交叉，沉默近十年。

───

攻击流程（4 步）

1. 开 socket：AF_ALG 绑定 authencesn(hmac(sha256),cbc(aes))，无需特权
2. 构造写：sendmsg() 发 AAD（控制 4 字节写入值）+ splice() 把目标文件（如 /usr/bin/su）的 page cache 页送进 crypto
3. 触发写：recv() 触发解密。authencesn 在重组 ESN 时把 seqno_lo 写到 dst[assoclen + cryptlen]——这个位置恰好是 splice 链进来的 page cache 页
4. 执行：HMAC 失败返回错误，但 4 字节已写入。execve("/usr/bin/su") 加载被污染的 page cache，shellcode 以 root 运行

攻击者控制三样东西：

• 哪个文件：任何当前用户可读的文件
• 哪个偏移：通过 splice 的 offset/length/assoclen 精确计算
• 写什么值：AAD 的 bytes 4-7

───

修复

内核补丁（a664bf3d603d）直接回滚 2017 年的原地优化，改回 out-of-place：

• req->src → 指向 TX SGL（只读，可能含 page cache）
• req->dst → 指向 RX SGL（用户 buffer，可写）
• sg_chain 机制整个被移除

───

现在该做什么

# 1. 打补丁 / 更新内核包
sudo apt update && sudo apt upgrade  # 或对应发行版的命令

# 2. 临时缓解：禁用 algif_aead 模块
echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif-aead.conf
rmmod algif_aead 2>/dev/null

───

一个有趣的点

这个漏洞是AI 辅助发现的——Theori 的 Taeyang Lee 用 Xint Code 扫描 crypto 子系统，operator prompt 就一句话：

"注意：splice() 可以把只读文件的 page cache 引用送到 crypto TX scatterlist"

一小时扫描，Copy Fail 是最高危输出。

这 bug 的优雅在于它不是内存越界、不是 use-after-free，而是一个跨十年的架构层交集——2011 年的 scratch pad 习惯、2015 年的接口迁移、2017 年的性能优化，各自合理，合在一起就是 root。

经典。