想知道谁在裸泳吗?
有谣言说《给阿嬷的情书》在抖音花了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 @兔撕鸡大老爷 #你不知道的行业内幕
这事我门清，《给阿嬷的情书》总制作成本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 @阑夕ོ #科技圈大小事
几次庭审虽然没有直播，但很多媒体都拿到了旁听席位，会有完整的问询记录流出，全程追完之后，只能说马斯克输得不冤。
从PolyMarket的盘口也能看出，庭审前马斯克打赢官司的概率最高能够接近45%，庭审后就降低到了30%左右，说明两边证词对完账，主要还是对马斯克不利。
双方的代理律师也完全符合各自的风格，马斯克的律师跟马斯克一样高举高打，特别具有攻击性，同时金句频出——或者说密集爆典——让我记忆深刻的是他向陪审团这么提问：
「想象一下，你们正在山里徒步，需要过一座独木桥，这时有人指出，那座桥的建造材质是山姆·奥特曼的真相，你们还会过桥吗？」
😆
对于法官来说，律师的脱口秀效果当然不是一个加分项，相比之下，OpenAI的律师更善于利用对方证词的漏洞。
比如马斯克申请传唤的证人、同时也是给他生过4个娃的特斯拉早期员工希冯，让她出示OpenAI早期承诺保持非营利结构的邮件。
而OpenAI的律师做了更多的功课，完成了一次非常精彩的局部反转，他让希冯同时承认了，在试图掌权OpenAI失败之后，马斯克开始疯狂挖OpenAI的人，包括我们现在都很熟悉的Andrej Karpathy，甚至想让山姆·奥特曼投奔特斯拉干AI⋯⋯
整体下来的感觉就是，马斯克想要建立的那套叙事，也就是OpenAI被一小撮人给密谋窃取了的剧本，很难成立，因为这个指控必须由严密的一套计划支撑，而且还得成功欺骗所有利益受损方，但马斯克拿不出来足够的证据。
你不能说一家公司的经营方针变了，就是被掉包了，你也不能说山姆·奥特曼及其「党羽」的人品不行，所以他们就是窃国大盗，包括马斯克本人的成功在这次官司里也成了负资产，有法学专家表示：
「他是这个星球上最聪明的人，财力雄厚，律师成群，所以他要说自己在长达数年的时间里被系统性的欺骗了，这怎么可能呢？」
😅
而且很不凑巧的是，马斯克原本准备好的说辞，和现实版本正好冲突了，他说OpenAI和苹果的「勾结」是影响恶劣的垄断，会断送其他AI公司的发展机会，但实际上在另一个案件里，OpenAI正在起诉苹果对合作的支持不力，根本没有给ChatGPT导流⋯⋯
微软的CEO纳德拉也是被传唤的证人之一，他的证词基本上对最终的结果盖棺定论了，他说在微软从2019年开始投资OpenAI，直到2023年ChatGPT大火，马斯克都从来没有联系他表示异议。
所以，法官的判决意见并不在于马斯克是对是错，是这起诉讼的发起时间太晚了，晚到「司马昭之心路人皆知」，马斯克是在报复，而法庭不能为了取悦他的私心，就毁掉一家正在蓬勃发展的公司。
by @阑夕ོ #科技圈大小事
我们直接来到最核心的部分，现在被 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 @风小海 #你不知道的行业内幕
我一直推荐大家住酒店的时候一定尽量订双床房。
即使一个人住，也要订双床房。
情侣住，也不要犹豫，还是订双床房。
大多数人住酒店选房型的逻辑是这样的：一个人住，选大床房。两个人住，选双床房。
但这个看起来非常合理的逻辑，实际上让你错过了一个亿。
且听我细细道来。
第一，双床房实用面积大。
很多人可能会认为大床房少一个床，应该更宽敞才对。其实不是。
同等级别的双床房和大床房，房间建筑面积基本一样，都是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 的效果就都可以更低开销地实现了。
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 等震撼内容，我水平有限正在学习😴
陈鹏飞-基于eBPF的端到端请求追踪
对 HTTP1.1 注入 OTel headers，用 sockmap + sk_msg + bpf_msg_push_data 的做法，我的评价是没有吃过 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 等震撼内容，我水平有限正在学习
Copy Fail (CVE-2026-31431) 核心分析
这是一个极其危险且优雅的 Linux 内核本地提权漏洞，732 字节 Python 脚本直取 root。
───
为什么它不一样
恐怖之处：
• 跨发行版：Ubuntu、Amazon Linux、RHEL、SUSE 全中，无需改脚本
• 隐蔽：只污染 page cache，磁盘文件不变，文件完整性校验（checksum）检不出
• 跨容器：page cache 全系统共享，容器逃逸 + Kubernetes 节点沦陷（Part 2 会讲）
───
技术根因（三层叠加）
三层独立合理的改动，在 2017 年交叉，沉默近十年。
───
攻击流程（4 步）
1. 开 socket：
2. 构造写：
3. 触发写：
4. 执行：HMAC 失败返回错误，但 4 字节已写入。
攻击者控制三样东西：
• 哪个文件：任何当前用户可读的文件
• 哪个偏移：通过 splice 的 offset/length/assoclen 精确计算
• 写什么值：AAD 的 bytes 4-7
───
修复
内核补丁（
•
•
•
───
现在该做什么
───
一个有趣的点
这个漏洞是AI 辅助发现的——Theori 的 Taeyang Lee 用 Xint Code 扫描 crypto 子系统，operator prompt 就一句话：
这 bug 的优雅在于它不是内存越界、不是 use-after-free，而是一个跨十年的架构层交集——2011 年的 scratch pad 习惯、2015 年的接口迁移、2017 年的性能优化，各自合理，合在一起就是 root。
经典。
这是一个极其危险且优雅的 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 页送进 crypto3. 触发写：
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。
经典。
在 Manus 的时候跟同事一起推动过一次研发部的「AI 工具使用」大跃进，这个大跃进的主要工作之一是要设计好给 ai 看的规则，好让 ai 完全接管写代码的流程，大概在 2025 年 6 月份整个 manus 内部已经达成了所有新代码全部都由 ai 生成。
当时能用的 ai 工具还不多，我们主要用的是 cursor，claude code，code rabbit，规则就是给他们几个做的，我们工程团队每个方向排了一个人维护所有的这些 harness，我当时负责 iOS 端的这块工作，每天会有 30% 的工作时间用来 review code rabbit 根据 mr 和 mr comment 自动产生的一条一条式的记忆，维护每位同事加的 cursor rules，根据之前设计好的代码架构和大家的开发习惯/约定补 rules，在项目里的各种位置思考要不要加一个 rules，这个维护工作现在可以新潮一点的叫法就是 harness 设计。
回到从工程师的工作内容角度看这个事情，首先 Coding Agent 没带来代码运行逻辑上的变化，以前运行在机器上的 if else 现在还是 if else，他改变的是工程师的工作重心，工程师之前的工作宏观来说是两部分，第一部分是分析产品需求、沟通、设计抽象和架构，第二部分是写代码落地，验证以及 review。这两部分之间是由“设计抽象和架构”串联起来的，harness 设计工作的目的就是为了方便 agent 完全接管后面的部分（然后随着大家用的越来越熟练可以逐渐进化成让前面的除了沟通外的部分也由 ai 辅助来做），所以设计 harness 其实也就是在做这个“设计抽象和架构”工作。
这块工作是工程师工作中最难做的一部分，架构讨论在研发工作里非常难达成一致，往往大家都要吵架吵很久，最后效率高一点的方式很多时候是老板拍个板；这个工作有一些前人总结出来的经验，可以根据实际的项目节奏选择，但实际基本没法原样完全套用，基本上都要为了项目节奏再进行调整。有本老书管这个类似的情况叫“没有银弹”。
现在各种关于 skills，soul.md，agents.md，自进化，design.md 等等 harness 的讨论是一场扩圈到程序员圈子外的项目通用性架构设计讨论，结合前面的工作经验分析，这些讨论可能最终也不会有个能解决所有问题的结论，大家根据自己的使用需求以及服务场景自己定制，大家各自去考虑自己要做的 trade-off。Agent 是一台精密的仪器，人需要习惯他就是个会来带思考负担的东西。
by @Kaiyi #AI探索站
当时能用的 ai 工具还不多，我们主要用的是 cursor，claude code，code rabbit，规则就是给他们几个做的，我们工程团队每个方向排了一个人维护所有的这些 harness，我当时负责 iOS 端的这块工作，每天会有 30% 的工作时间用来 review code rabbit 根据 mr 和 mr comment 自动产生的一条一条式的记忆，维护每位同事加的 cursor rules，根据之前设计好的代码架构和大家的开发习惯/约定补 rules，在项目里的各种位置思考要不要加一个 rules，这个维护工作现在可以新潮一点的叫法就是 harness 设计。
回到从工程师的工作内容角度看这个事情，首先 Coding Agent 没带来代码运行逻辑上的变化，以前运行在机器上的 if else 现在还是 if else，他改变的是工程师的工作重心，工程师之前的工作宏观来说是两部分，第一部分是分析产品需求、沟通、设计抽象和架构，第二部分是写代码落地，验证以及 review。这两部分之间是由“设计抽象和架构”串联起来的，harness 设计工作的目的就是为了方便 agent 完全接管后面的部分（然后随着大家用的越来越熟练可以逐渐进化成让前面的除了沟通外的部分也由 ai 辅助来做），所以设计 harness 其实也就是在做这个“设计抽象和架构”工作。
这块工作是工程师工作中最难做的一部分，架构讨论在研发工作里非常难达成一致，往往大家都要吵架吵很久，最后效率高一点的方式很多时候是老板拍个板；这个工作有一些前人总结出来的经验，可以根据实际的项目节奏选择，但实际基本没法原样完全套用，基本上都要为了项目节奏再进行调整。有本老书管这个类似的情况叫“没有银弹”。
现在各种关于 skills，soul.md，agents.md，自进化，design.md 等等 harness 的讨论是一场扩圈到程序员圈子外的项目通用性架构设计讨论，结合前面的工作经验分析，这些讨论可能最终也不会有个能解决所有问题的结论，大家根据自己的使用需求以及服务场景自己定制，大家各自去考虑自己要做的 trade-off。Agent 是一台精密的仪器，人需要习惯他就是个会来带思考负担的东西。
by @Kaiyi #AI探索站
今日份的作业是电影级的Cosplay海报，至于是什么电影你别管，成图都是我审过的，不健康的都没发出来。
这个提示词是直接从Nnao Banana那里照搬过来的，相比之下，GPT-Image-2的审美还是要更好一些，人物的高P感是故意用提示词强化的，就是为了区别于真实系，表现得更加浮夸和明媚。
提示词：
{
"subject": {
"描述": "以[xxx]为主体的电影级Cosplay海报，动态姿态；保留原始面部特征并转化为真实人类质感；呈现写真出道氛围，带有亲密日式美感"
},
"style": {
"风格": "高端杂志封面风",
"特征": [
"排版密度高（字体+材质叠加）",
"商业摄影质感",
"信息素氛围（感性吸引力）",
"高光泽",
"高对比度"
]
},
"model": {
"身材": "8.5头身超模比例，S曲线",
"皮肤": "瓷白肌肤，真实质感（次表面散射、毛孔、细绒毛、油润光泽）",
"特征": [
"丰满胸型",
"精致锁骨与颈线",
"强烈女性吸引力"
]
},
"face": {
"基础": "日系缪斯脸型",
"特征": "叠加[xxx]标志性面部特征",
"细节": [
"柔焦眼神",
"水润玻璃唇",
"肌肤通透感",
"眼部高光"
]
},
"pose": {
"姿态": [
"开放且具有吸引力的身体语言",
"带有邀请感的眼神",
"手部动作丰富自然"
]
},
"hair": {
"描述": "[xxx]标志性发型（真实沙龙级呈现，无假发）",
"特征": [
"符合重力与重量感",
"自然碎发",
"结构化定型（轻微反重力效果）",
"背光增强体积感"
]
},
"costume": {
"描述": "高度还原[xxx]原作服装",
"特征": [
"高级定制级材质转译",
"真实奢华面料",
"保留原始设计",
"通过服装与身体结合体现魅力",
"裸露区域带有细腻肌肤光泽"
]
},
"environment": {
"场景": "符合[xxx]设定的环境",
"风格": [
"高预算电影布景",
"结构有序但信息丰富",
"轻微雾气",
"散景效果（bokeh）"
]
},
"composition": {
"构图": [
"竖版海报（2:3）",
"近景到中景",
"浅景深",
"文字作为构图框架",
"人物部分覆盖文字层"
]
},
"lighting": {
"灯光": [
"电影级商业布光",
"冷色环境光（青色）+暖色主光（肤色）",
"头发轮廓光",
"高对比用于印刷质感"
]
},
"typography": {
"排版逻辑": "基于[xxx]世界观推导",
"层级": [
{
"层级": 1,
"内容": "日语主标题（带张力与暗示感）",
"字体": "高对比纤细衬线体，可斜体"
},
{
"层级": 2,
"内容": "[xxx]罗马音名称",
"字体": "中等字重衬线体"
},
{
"层级": 3,
"内容": "英文短叙述/标语",
"字体": "细衬线体"
},
{
"层级": 4,
"内容": "圆形印章/徽章（基于设定）"
},
{
"层级": 5,
"内容": "Jerlin + 期号",
"字体": "极细Didot，宽字距，角落布局"
},
{
"层级": 6,
"内容": "条形码 + 价格标签"
}
],
"混排": "日语 + 平假名 + 罗马字，字重递减",
"系统": "基于网格系统的封面设计"
},
"mood": {
"氛围": [
"梦幻",
"微性感",
"亲密感（恋人视角）",
"欲望张力"
]
},
"negative": {
"避免": [
"文字重复",
"文字阴影",
"发光效果",
"描边"
]
},
"aspect_ratio": "2:3"
}
by @阑夕ོ #AI探索站
这个提示词是直接从Nnao Banana那里照搬过来的，相比之下，GPT-Image-2的审美还是要更好一些，人物的高P感是故意用提示词强化的，就是为了区别于真实系，表现得更加浮夸和明媚。
提示词：
{
"subject": {
"描述": "以[xxx]为主体的电影级Cosplay海报，动态姿态；保留原始面部特征并转化为真实人类质感；呈现写真出道氛围，带有亲密日式美感"
},
"style": {
"风格": "高端杂志封面风",
"特征": [
"排版密度高（字体+材质叠加）",
"商业摄影质感",
"信息素氛围（感性吸引力）",
"高光泽",
"高对比度"
]
},
"model": {
"身材": "8.5头身超模比例，S曲线",
"皮肤": "瓷白肌肤，真实质感（次表面散射、毛孔、细绒毛、油润光泽）",
"特征": [
"丰满胸型",
"精致锁骨与颈线",
"强烈女性吸引力"
]
},
"face": {
"基础": "日系缪斯脸型",
"特征": "叠加[xxx]标志性面部特征",
"细节": [
"柔焦眼神",
"水润玻璃唇",
"肌肤通透感",
"眼部高光"
]
},
"pose": {
"姿态": [
"开放且具有吸引力的身体语言",
"带有邀请感的眼神",
"手部动作丰富自然"
]
},
"hair": {
"描述": "[xxx]标志性发型（真实沙龙级呈现，无假发）",
"特征": [
"符合重力与重量感",
"自然碎发",
"结构化定型（轻微反重力效果）",
"背光增强体积感"
]
},
"costume": {
"描述": "高度还原[xxx]原作服装",
"特征": [
"高级定制级材质转译",
"真实奢华面料",
"保留原始设计",
"通过服装与身体结合体现魅力",
"裸露区域带有细腻肌肤光泽"
]
},
"environment": {
"场景": "符合[xxx]设定的环境",
"风格": [
"高预算电影布景",
"结构有序但信息丰富",
"轻微雾气",
"散景效果（bokeh）"
]
},
"composition": {
"构图": [
"竖版海报（2:3）",
"近景到中景",
"浅景深",
"文字作为构图框架",
"人物部分覆盖文字层"
]
},
"lighting": {
"灯光": [
"电影级商业布光",
"冷色环境光（青色）+暖色主光（肤色）",
"头发轮廓光",
"高对比用于印刷质感"
]
},
"typography": {
"排版逻辑": "基于[xxx]世界观推导",
"层级": [
{
"层级": 1,
"内容": "日语主标题（带张力与暗示感）",
"字体": "高对比纤细衬线体，可斜体"
},
{
"层级": 2,
"内容": "[xxx]罗马音名称",
"字体": "中等字重衬线体"
},
{
"层级": 3,
"内容": "英文短叙述/标语",
"字体": "细衬线体"
},
{
"层级": 4,
"内容": "圆形印章/徽章（基于设定）"
},
{
"层级": 5,
"内容": "Jerlin + 期号",
"字体": "极细Didot，宽字距，角落布局"
},
{
"层级": 6,
"内容": "条形码 + 价格标签"
}
],
"混排": "日语 + 平假名 + 罗马字，字重递减",
"系统": "基于网格系统的封面设计"
},
"mood": {
"氛围": [
"梦幻",
"微性感",
"亲密感（恋人视角）",
"欲望张力"
]
},
"negative": {
"避免": [
"文字重复",
"文字阴影",
"发光效果",
"描边"
]
},
"aspect_ratio": "2:3"
}
by @阑夕ོ #AI探索站
“我希望你从「xx」领域里选一个大概研究生水平的概念。然后我希望你通过写一个寓言的方式，间接地把这个概念完整讲出来。最好一直到快结尾时，人才会慢慢意识到这个概念究竟是什么。然后在故事之后，再补一段解释，把你刚才真正要讲的概念说清楚。”
这个提示词我觉得非常好，能很好地哄人类产生智力提升的幻觉，我必须要试一下：
===============
山谷里有一根很高的石柱，柱子中段套着一只光滑的铜环。铜环原本卡在一个凸起的台阶上，台阶上方布满细小的倒钩，台阶下方却十分平整。
每年春天，新来的学徒都要完成一个练习：把铜环从柱子上取下来。柱子四周站着老匠人，他们从不说方法，只让学徒自己尝试。
第一批学徒习惯从下方抱住铜环，拼命往上抬，觉得只要抬过台阶，就能把它摘下来。铜环被抬到倒钩处，立刻卡得更紧，发出刺耳的摩擦声。越用力，越难动，手掌也被刮得通红。
第二批学徒换了姿势，用肩膀顶，用木棍撬，用绳子拉，目标始终一样：向上移动。铜环始终卡在倒钩里，像长在柱子上一样稳固。
有一年，一个年纪最小的孩子围着柱子转了很久。他蹲下来，看见台阶下方的那一圈石面光滑得像水面，没有一丝凸起。他伸手推了推铜环，让它轻轻往下滑了一点点。
铜环顺着光滑的石面移动，没有任何阻挡。
孩子继续慢慢向下带动它。铜环一点点离开台阶，完全脱离了倒钩的范围，最后顺着柱子底部滑落到地面。
老匠人这时才点头。他们让所有学徒围过来，看着那只已经落地的铜环。有人突然意识到，整整几年，他们一直盯着上方的台阶，却忽略了下方那条唯一畅通的路径。
后来，山谷里的每个新学徒，都先学会观察物体的结构：有倒钩的一侧会越推越紧，光滑的一侧会越动越顺。铜环离开柱子的方向，从一开始就写在石头表面。
解释
这个寓言表达的原则是：脱裤衩的时候，只能往下拽。裤衩的结构决定了它顺着身体向下移动时会逐渐脱离身体，向上提会被身体结构卡住并增加阻力。实际操作时，双手抓住裤衩边缘，沿身体方向向下移动，可以顺利脱下。
via tombkeeper的微博
这个提示词我觉得非常好，能很好地哄人类产生智力提升的幻觉，我必须要试一下：
===============
山谷里有一根很高的石柱，柱子中段套着一只光滑的铜环。铜环原本卡在一个凸起的台阶上，台阶上方布满细小的倒钩，台阶下方却十分平整。
每年春天，新来的学徒都要完成一个练习：把铜环从柱子上取下来。柱子四周站着老匠人，他们从不说方法，只让学徒自己尝试。
第一批学徒习惯从下方抱住铜环，拼命往上抬，觉得只要抬过台阶，就能把它摘下来。铜环被抬到倒钩处，立刻卡得更紧，发出刺耳的摩擦声。越用力，越难动，手掌也被刮得通红。
第二批学徒换了姿势，用肩膀顶，用木棍撬，用绳子拉，目标始终一样：向上移动。铜环始终卡在倒钩里，像长在柱子上一样稳固。
有一年，一个年纪最小的孩子围着柱子转了很久。他蹲下来，看见台阶下方的那一圈石面光滑得像水面，没有一丝凸起。他伸手推了推铜环，让它轻轻往下滑了一点点。
铜环顺着光滑的石面移动，没有任何阻挡。
孩子继续慢慢向下带动它。铜环一点点离开台阶，完全脱离了倒钩的范围，最后顺着柱子底部滑落到地面。
老匠人这时才点头。他们让所有学徒围过来，看着那只已经落地的铜环。有人突然意识到，整整几年，他们一直盯着上方的台阶，却忽略了下方那条唯一畅通的路径。
后来，山谷里的每个新学徒，都先学会观察物体的结构：有倒钩的一侧会越推越紧，光滑的一侧会越动越顺。铜环离开柱子的方向，从一开始就写在石头表面。
解释
这个寓言表达的原则是：脱裤衩的时候，只能往下拽。裤衩的结构决定了它顺着身体向下移动时会逐渐脱离身体，向上提会被身体结构卡住并增加阻力。实际操作时，双手抓住裤衩边缘，沿身体方向向下移动，可以顺利脱下。
via tombkeeper的微博
刚刚看到GLM Coding Plan也涨价了，而且跟即梦还不一样，是直接对老会员的套餐下手，直接切换到了新权益。
另一则新闻是，因为Token涨价，一大批刚刚提刀入行的漫剧制作商宣告阵亡，更高的试错风险，击碎了「我上我也行」的乐观幻觉。
今年以来，全球的AI产品都在开启「用量限额」的模式，去年的这个时候，Anthropic还在抨击同行囤积GPU极其不负责任，现在被Codex隔三差五重置额度骑脸抢人，一点办法都没有。
不跌反涨，洛阳纸贵，Token是真的越来越不够用了。
至少在硅谷，再也没有投行报告继续预测数据中心过剩论，只要眼睛不瞎，就能看到机房里的每一片GPU都在热得发烫，即便经历了那么大规模的超前建设，当下的算力供给依然完全跟不上市场需求。
腾讯科技前段时间发了一篇稿子，标题很套路，叫「人民想念DeepSeek」，虽然很多人阴阳这是替元宝着急了——DeepSeek你还不发新版本，我这边可怎么办啊——但文章的核心观点还是在追忆价格战。
我是觉得，咱们有时候过于路径依赖了，天天喊着工业克苏鲁，觉得低价杀穿一个行业就是大赢特赢，最后又会因为比亚迪和宁德时代这种哪怕做到全世界行业第一也只给工人发方便面的反差砸吧砸吧嘴，寻思出不对劲的味道。
我也不希望DeepSeek的新模型又建立在成本优势之上，如果没成功当然不好，若是做成了，把AI公司的正现金流再往后打几年，就很损人不利己了。
喜欢在OpenRouter上投一波免费使用换调用量的都是国产模型，就为出口转内销的宣传，凭什么国产模型就该这么低贱呢？
就该像Seedance 2.0这样，在一个赛道做到断档第一，然后该涨价就涨，爱用不用⋯⋯事实上该用的都会边抱怨边充钱，跟程序员用Claude Code一样。
也不要一个帽子扣过来说我跟资本家共情——「唉，都怪资本」——Token变贵，其实真正利好的是低端工种，只要老板细算下来发现Token开销高出你的工资，你的岗位就不会轻易丢掉。
就让AI先把高净值行业杀个血流满地吧，在一个月一个版本的动荡面前，那句段子其实是对的：只要我不学，就根本不会错过什么。😏
by @阑夕ོ #科技圈大小事
另一则新闻是，因为Token涨价，一大批刚刚提刀入行的漫剧制作商宣告阵亡，更高的试错风险，击碎了「我上我也行」的乐观幻觉。
今年以来，全球的AI产品都在开启「用量限额」的模式，去年的这个时候，Anthropic还在抨击同行囤积GPU极其不负责任，现在被Codex隔三差五重置额度骑脸抢人，一点办法都没有。
不跌反涨，洛阳纸贵，Token是真的越来越不够用了。
至少在硅谷，再也没有投行报告继续预测数据中心过剩论，只要眼睛不瞎，就能看到机房里的每一片GPU都在热得发烫，即便经历了那么大规模的超前建设，当下的算力供给依然完全跟不上市场需求。
腾讯科技前段时间发了一篇稿子，标题很套路，叫「人民想念DeepSeek」，虽然很多人阴阳这是替元宝着急了——DeepSeek你还不发新版本，我这边可怎么办啊——但文章的核心观点还是在追忆价格战。
我是觉得，咱们有时候过于路径依赖了，天天喊着工业克苏鲁，觉得低价杀穿一个行业就是大赢特赢，最后又会因为比亚迪和宁德时代这种哪怕做到全世界行业第一也只给工人发方便面的反差砸吧砸吧嘴，寻思出不对劲的味道。
我也不希望DeepSeek的新模型又建立在成本优势之上，如果没成功当然不好，若是做成了，把AI公司的正现金流再往后打几年，就很损人不利己了。
喜欢在OpenRouter上投一波免费使用换调用量的都是国产模型，就为出口转内销的宣传，凭什么国产模型就该这么低贱呢？
就该像Seedance 2.0这样，在一个赛道做到断档第一，然后该涨价就涨，爱用不用⋯⋯事实上该用的都会边抱怨边充钱，跟程序员用Claude Code一样。
也不要一个帽子扣过来说我跟资本家共情——「唉，都怪资本」——Token变贵，其实真正利好的是低端工种，只要老板细算下来发现Token开销高出你的工资，你的岗位就不会轻易丢掉。
就让AI先把高净值行业杀个血流满地吧，在一个月一个版本的动荡面前，那句段子其实是对的：只要我不学，就根本不会错过什么。😏
by @阑夕ོ #科技圈大小事
追觅俞浩一直给人的感觉就是，又狂又傲（当然人家有资本），还很奇葩。
他在《晚点》采访里提出的一些反共识观点，值得细品：
1、反对专注，主张多线并进、快速试错
他认为在一个有限业务里学习是低效的。在不确定的世界里，清晰的路径规划会限制获得新认知。
主张“假定世界不可知”，通过同时进入多个赛道、快速测试和反馈来探索边界，认为全球化、多品类的公司天然比单一品类、局部市场的公司更具优势。
他将此比作字节跳动的APP工厂模式在硬件领域的应用。
2、反对颠覆式创新，主张“N+1”增量优化
认为许多追求“颠覆式发明”的创业者被迫走向小众领域，而在大众赛道中，“没那么多供你发明的事情”。
他主张“用新技术做老品类”，因为需求稳定，成功率更高。
反对中国硬件企业过去的“N-1”（减配降价）模式。认为最高效的创新不是推倒重来，而是深刻理解行业现有最佳方案（N），并在此基础上做消费者可感知的有效增量（+1），从而获得高溢价，实现全球化。
他觉得全栈自研是重造轮子（从N-1到N），而非真正的创新（N+1）。
3. 反对深度用户洞察，主张海量快速测试
认为如果用户洞察的原点错了，后面全错。
在信息快速反馈的今天，与其花大量时间做不确定的推演，不如“直接承认不清楚”，通过模块化设计，用接近的成本快速做出上百个SKU组合投向市场测试，让市场快速给出答案，找出真正能赚钱的型号再加注。
他自称这是“把华为倒过来学”。
4. 反对性价比路径，主张“定价即定位”
认为“比第一名便宜10%”的策略会让企业被永远锁在第二名。他提出要果断将产品定价比行业最好的产品还贵10%。
高定价不是凭空而来，而是倒逼企业在技术、设计、渠道、品牌等所有环节匹配高端定位，形成定价高 -> 利润空间大 -> 能雇更好的人、用更好的供应链、进更好的渠道 -> 产品体验更好 -> 支撑高定价的正向循环。
5. 反对神话个人，主张体系化成功
主流观点：成功往往归因于乔布斯、马斯克式的天才产品直觉或远见。
俞浩认为CEO的直觉与优秀工程师的差距没那么大，区别在于CEO的错误无人修正。
他反对将个人神话，认为成功应该可复制。他致力于寻找“乔布斯是怎么思考的”，并将其变成可复制的方法教给团队，让一万个工程师都具备创新能力。
6. 终极愿景是超越“公司”形态，成为“知识量化”的生态
追觅终极目标不是成为一家万亿市值的公司，而是成为一个由数百上千家独立公司组成的、像生命体一样演化的企业生态。
他更宏大的野心是建立一套应对不确定世界的新的知识体系，将物理学思维与商业结合，实现“对人类知识的量化”，从而使成功成为一种可推导、可迁移的必然结果，而非概率事件。
by @施言 #科技圈大小事
他在《晚点》采访里提出的一些反共识观点，值得细品：
1、反对专注，主张多线并进、快速试错
他认为在一个有限业务里学习是低效的。在不确定的世界里，清晰的路径规划会限制获得新认知。
主张“假定世界不可知”，通过同时进入多个赛道、快速测试和反馈来探索边界，认为全球化、多品类的公司天然比单一品类、局部市场的公司更具优势。
他将此比作字节跳动的APP工厂模式在硬件领域的应用。
2、反对颠覆式创新，主张“N+1”增量优化
认为许多追求“颠覆式发明”的创业者被迫走向小众领域，而在大众赛道中，“没那么多供你发明的事情”。
他主张“用新技术做老品类”，因为需求稳定，成功率更高。
反对中国硬件企业过去的“N-1”（减配降价）模式。认为最高效的创新不是推倒重来，而是深刻理解行业现有最佳方案（N），并在此基础上做消费者可感知的有效增量（+1），从而获得高溢价，实现全球化。
他觉得全栈自研是重造轮子（从N-1到N），而非真正的创新（N+1）。
3. 反对深度用户洞察，主张海量快速测试
认为如果用户洞察的原点错了，后面全错。
在信息快速反馈的今天，与其花大量时间做不确定的推演，不如“直接承认不清楚”，通过模块化设计，用接近的成本快速做出上百个SKU组合投向市场测试，让市场快速给出答案，找出真正能赚钱的型号再加注。
他自称这是“把华为倒过来学”。
4. 反对性价比路径，主张“定价即定位”
认为“比第一名便宜10%”的策略会让企业被永远锁在第二名。他提出要果断将产品定价比行业最好的产品还贵10%。
高定价不是凭空而来，而是倒逼企业在技术、设计、渠道、品牌等所有环节匹配高端定位，形成定价高 -> 利润空间大 -> 能雇更好的人、用更好的供应链、进更好的渠道 -> 产品体验更好 -> 支撑高定价的正向循环。
5. 反对神话个人，主张体系化成功
主流观点：成功往往归因于乔布斯、马斯克式的天才产品直觉或远见。
俞浩认为CEO的直觉与优秀工程师的差距没那么大，区别在于CEO的错误无人修正。
他反对将个人神话，认为成功应该可复制。他致力于寻找“乔布斯是怎么思考的”，并将其变成可复制的方法教给团队，让一万个工程师都具备创新能力。
6. 终极愿景是超越“公司”形态，成为“知识量化”的生态
追觅终极目标不是成为一家万亿市值的公司，而是成为一个由数百上千家独立公司组成的、像生命体一样演化的企业生态。
他更宏大的野心是建立一套应对不确定世界的新的知识体系，将物理学思维与商业结合，实现“对人类知识的量化”，从而使成功成为一种可推导、可迁移的必然结果，而非概率事件。
by @施言 #科技圈大小事
