Forwarded from Hacker News 摘要
Telegraph
可能是一个严重的可能性
原标题：Possibly a Serious Possibility 在2025年5月3日，亚当·库查斯基发表了一篇文章，标题为《可能是一个严重的可能性》。文章探讨了冷战时期情报沟通中的模糊语言是如何影响决策的。故事的中心是1951年3月，时任CIA分析师的舍曼·肯特在讨论一份关于“1951年南斯拉夫入侵的可能性”的报告时，发现自己的措辞造成了严重的误解。 肯特在报告中使用了“应该被视为一个严重的可能性”这一表述，但他的上司和同事们对这个短语的理解大相径庭。一位政策规划委员会的主席甚至询问了肯特此语的具…
我也注意到这个问题还挺严重的，而且不限于表述概率，例如表述一些东西的质量时，“好”、“还行”、“一般”等词的含义也常常在对话双方之间有不同的认识。把词语的含义标准化成一些量化区间似乎不是好的解决方式，因为上下文就是很重要的。我常遇到的两种表达需求：
1. 表达一个事情发生的概率极其小（亿分之一到千分之一这种量级），对于当前目标来说造成的影响可以忽略，例如“有人一次就猜对了 6 位数验证码怎么办”。没有一个标准化词语对应这种概率，而且什么概率可以忽略也取决于具体业务情况。
2. 表达一个事情发生的概率虽然很小（1% 到 20% 这种量级），但对当前目标来说造成的影响是很大的。如果有人用英国这套标准化词语说我们网站有“remote chance”（0%-5%）或者“highly unlikely”（10%-20%）给用户显示错误的结果，我肯定不会理解为有 5% 甚至 20% 的用户受影响😂。我有时会说“这个功能会给很多用户显示错误的结果，当然这些用户占的比例数字是很小的，但是绝对数量上是很多用户了”。
当然了，在情报工作中，分析师可能不知道自己正在估计的一个概率对宏观目标的影响程度，这是情报使用者负责判断的，双方的上下文自然会有区别。“serious possibility”在我看来既有可能表示我们不能忽略这个可能性，要开始严肃地考虑它了（像是 30%），也有可能表示这个危险已经到了严重的程度（像是 70%）。除了故意用模糊的语言避免承担责任的情况，还是直接说数字吧。
1. 表达一个事情发生的概率极其小（亿分之一到千分之一这种量级），对于当前目标来说造成的影响可以忽略，例如“有人一次就猜对了 6 位数验证码怎么办”。没有一个标准化词语对应这种概率，而且什么概率可以忽略也取决于具体业务情况。
2. 表达一个事情发生的概率虽然很小（1% 到 20% 这种量级），但对当前目标来说造成的影响是很大的。如果有人用英国这套标准化词语说我们网站有“remote chance”（0%-5%）或者“highly unlikely”（10%-20%）给用户显示错误的结果，我肯定不会理解为有 5% 甚至 20% 的用户受影响😂。我有时会说“这个功能会给很多用户显示错误的结果，当然这些用户占的比例数字是很小的，但是绝对数量上是很多用户了”。
当然了，在情报工作中，分析师可能不知道自己正在估计的一个概率对宏观目标的影响程度，这是情报使用者负责判断的，双方的上下文自然会有区别。“serious possibility”在我看来既有可能表示我们不能忽略这个可能性，要开始严肃地考虑它了（像是 30%），也有可能表示这个危险已经到了严重的程度（像是 70%）。除了故意用模糊的语言避免承担责任的情况，还是直接说数字吧。
👍3
网页上如何处理长单词排版，以及环绕浮动体。
图 1：Chrome 和 Safari；图 2：Firefox。只有第 3 行第 2 列有区别，Firefox 认为 overflow-wrap 的意思是“不打断就一定会 overflow”时才打断，Chrome 和 Safari 认为“不打断就要撞上浮动体了”就可以打断。
word-break: break-all 太丑了。我之前基本都在用 overflow-wrap: anywhere，但 Firefox 文字环绕浮动体排版时会有问题，以及长单词前一行的空白我也不太满意。感觉只在长单词上指定 word-break: break-all 似乎比较好。
但这也不是我觉得最理想的状态，如果不能确定是不是长单词呢（例如用户自定义的用户名，可能短可能长）？我并不希望一个很短的用户名因为正好出现在行末而被打断了，而即使是长单词，如果起点已经很接近行末了，直接从下一行首开始也不错，没必要在上一行末尾放一两个字母。最理想的算法应该是对所有词一视同仁，如果哪个词不打断将会导致排版出现较大空白（上一行需要过早地结束）了，就打断这个词。目前 CSS 做不到这样的效果。
（CSS 还有个 hyphens: auto 的功能，可以自动找适合插入连字符的位置。但它没法保证能找到，这样不好，我希望优先找适合打断的位置，但如果找不到，也绝对不能溢出，可以随意打断。这个效果目前也是做不到的。）
图 1：Chrome 和 Safari；图 2：Firefox。只有第 3 行第 2 列有区别，Firefox 认为 overflow-wrap 的意思是“不打断就一定会 overflow”时才打断，Chrome 和 Safari 认为“不打断就要撞上浮动体了”就可以打断。
word-break: break-all 太丑了。我之前基本都在用 overflow-wrap: anywhere，但 Firefox 文字环绕浮动体排版时会有问题，以及长单词前一行的空白我也不太满意。感觉只在长单词上指定 word-break: break-all 似乎比较好。
但这也不是我觉得最理想的状态，如果不能确定是不是长单词呢（例如用户自定义的用户名，可能短可能长）？我并不希望一个很短的用户名因为正好出现在行末而被打断了，而即使是长单词，如果起点已经很接近行末了，直接从下一行首开始也不错，没必要在上一行末尾放一两个字母。最理想的算法应该是对所有词一视同仁，如果哪个词不打断将会导致排版出现较大空白（上一行需要过早地结束）了，就打断这个词。目前 CSS 做不到这样的效果。
（CSS 还有个 hyphens: auto 的功能，可以自动找适合插入连字符的位置。但它没法保证能找到，这样不好，我希望优先找适合打断的位置，但如果找不到，也绝对不能溢出，可以随意打断。这个效果目前也是做不到的。）
👍1
感谢博杰送了我一本他翻译的《图解大模型》，晚上看了前面一部分，终于理解注意力和 KV cache 是怎么工作的了（一直觉得我应该搞明白但没搞明白的两个概念，原来是紧密相关的呀）。
感觉至少前三章讲基础知识时节奏还是很快的，对我这种跨领域的读者来说有点难跟上😂不过后面似乎更大篇幅是比较偏实践和应用的，可能简单一些。
感觉至少前三章讲基础知识时节奏还是很快的，对我这种跨领域的读者来说有点难跟上😂不过后面似乎更大篇幅是比较偏实践和应用的，可能简单一些。
👍4
Adobe Acrobat 菜单 - 首选项 - 页面显示 - 渲染 - 增强细线，把这个取消勾选，细线就不会总是被渲染成一像素宽了，线条相交处也不会出现“额外伸出一像素”的渲染错误（见图一），而是会做反走样。适合用来检查文档中不同线条粗细关系、可辨识度，以及文档整体的墨色分布。
👍1
This media is not supported in your browser
VIEW IN TELEGRAM
我才发现 iOS 的滚动条能拖动😱虽然非常困难。
方法：先让滚动条出现，然后从屏幕右侧外沿开始按下手指，缓缓向左移动手指，使手指逐渐进入屏幕范围。不要太慢以至于滚动条在这个过程中消失了，但也不能太快。可能需要试多次才能成功，正确触发时滚动条会变宽并且有触觉反馈。
方法：先让滚动条出现，然后从屏幕右侧外沿开始按下手指，缓缓向左移动手指，使手指逐渐进入屏幕范围。不要太慢以至于滚动条在这个过程中消失了，但也不能太快。可能需要试多次才能成功，正确触发时滚动条会变宽并且有触觉反馈。
我想让游戏里有这样的机制：比如《文明》里面，如果我花了一些生产力训练了一个“城市发展专家”，就会有一个 AI 开始定期按我的要求产出报告，里面写着这个城市预计能发展成多少人口、多少生产力，适合建造哪些区域等等（而且是考虑了我用语言描述的具体要求的）。《动物园之星》里面，也可以帮我做一个某种我指定的风格的道路或者景观，因为手工一个一个摆放那些 3D 模型实在是太麻烦了。我感觉这不仅在游戏逻辑方面有道理（现实中的城市或者动物园当然可以花一些资源雇人来承担一些小范围的思考工作），而且是真的需要 AI 来做的事，靠非 AI 方案不太行。
另外，我认为这样可以解决游戏中总是很难平衡好的一个问题，就是如果给玩家太多细节可以控制的话，值得优化的细节无穷无尽，具体把一些思路转化成成果也需要大量体力劳动。不这样的话，又太不灵活了，自由度差。而且玩家很多时候还是需要在前期熟悉底层的基本原理的，这也是游戏乐趣的一部分，只是中后期同时管理很多东西时，每个都像前期一样微操就太辛苦了。可以让玩家在中后期才支付得起请 AI 的成本，并且如果想亲自优化某个细节也总可以做到。
另外，我认为这样可以解决游戏中总是很难平衡好的一个问题，就是如果给玩家太多细节可以控制的话，值得优化的细节无穷无尽，具体把一些思路转化成成果也需要大量体力劳动。不这样的话，又太不灵活了，自由度差。而且玩家很多时候还是需要在前期熟悉底层的基本原理的，这也是游戏乐趣的一部分，只是中后期同时管理很多东西时，每个都像前期一样微操就太辛苦了。可以让玩家在中后期才支付得起请 AI 的成本，并且如果想亲自优化某个细节也总可以做到。
我的键盘（poker 61 键）没有方向键，我一直习惯把 IJKL 用可编程层映射成方向键，在看视频和玩一些游戏的时候切换到可编程层，用这组方向键。刚刚才发现 YouTube 默认就支持 J 后退，L 前进，K 切换暂停状态，赞耶！
👍1
Hypercube's Channel
我做实验时常遇到这个需求：在对数意义下均匀地测试一个变量的一系列取值，例如每秒 10 个请求、100 个请求、1000 个请求时系统性能，或是 4KiB、8KiB、16KiB 等不同数据量的处理性能。 每次乘以 10 或乘以 2 都比较简单，但是如果希望乘以更小的数，还希望序列中的数字有效位数较少，对人来说看起来方便，就有点难了。例如每次简单地乘以 1.1 会得到 1.21、1.331、1.4641、1.61051。 于是我常在实验脚本中手写：[10, 13, 17, 20, 25, 30, 40, 50…
音乐领域的速度（tempo）：40, 42, 44, 46, 48, 50, 52, 54, 56, 58, 60, 63, 66, 69, 72, 76, 80（之后重复前面的序列乘以 2）
与 R 系列和 E 系列把 10 倍拆成 5/10/3/6/12/24 步不同，这个系列把 2 倍拆成 16 步，步长更短，以及在特定用途中更好记忆一点？（因为有 40 50 60 72 等比较“整”的数）
与 R 系列和 E 系列把 10 倍拆成 5/10/3/6/12/24 步不同，这个系列把 2 倍拆成 16 步，步长更短，以及在特定用途中更好记忆一点？（因为有 40 50 60 72 等比较“整”的数）
打印一个 9 页的乐谱时，我先是用了普通的 A4 双面打印、左侧订书针装订的方案，但这样很不适合快速翻页和平整地放在谱架上。和 AI 讨论了一番后才意识到更好的方案是用骑缝钉，也就是把几张横放的 A3 纸在中央钉起来/缝起来，然后对折，形成一本小册子。这样重做后得到的效果真不错！我觉得别的很多东西我也应该这样打印。
（这需要用复杂的方法重新排列原本的页，但一般软件都支持帮你重排成这样打印。另一个小的不便是这样最适合 4 的整数倍页，打印 9 或 13 页的内容会导致最后有空白页。）
（这需要用复杂的方法重新排列原本的页，但一般软件都支持帮你重排成这样打印。另一个小的不便是这样最适合 4 的整数倍页，打印 9 或 13 页的内容会导致最后有空白页。）
👍2
@taoky42 问了我一个我也遇到过很多次的问题：CSS 怎么在 inline layout 中让一个小图片和旁边的文本垂直居中对齐？vertical-align: middle 会把图片的中央对齐到周围文字的 x height 中央，而这个属性目前没有值能对齐到 cap height 中央或者汉字中央。
一个方法是把图片前后的文字分别包进 span 标签，让文字和图片是平级节点，然后在所有平级节点上指定 vertical-align: middle。但这样会把文字基线全都搞乱，还需要把文字分别包起来，并不是好主意。
最终我发现了这篇（排版非常漂亮的！）博客 https://blog.kizu.dev/cap-height-align/ 其中说的第一种方法我觉得就足够好了：
vertical-align: middle;
margin-block-start: calc(1ex - 1cap);
我做了一些测试确认它在图片和文字有各种尺寸关系、不同尺寸文字混排、不同 line height 等情况下都有正确的效果，非常不错。我能想到的注意事项：
1. 如果 cap height 中央和汉字中央不一致，它只能对齐到前者。我看了一遍相关 CSS 单位，后者好像做不到，但我的经验是很多字体中这二者基本是一致的。
2. 只适用于 inline layout，如果在 flex layout 等情况下已经用别的方案实现了对齐，重复使用这个会破坏对齐。
（如果不要求 inline layout，也就是说不需要图片和文字混合在一起换行，那就简单多了。例如要对齐一个按钮上的图标和文字，别用这个方法，用 flex。）
一个方法是把图片前后的文字分别包进 span 标签，让文字和图片是平级节点，然后在所有平级节点上指定 vertical-align: middle。但这样会把文字基线全都搞乱，还需要把文字分别包起来，并不是好主意。
最终我发现了这篇（排版非常漂亮的！）博客 https://blog.kizu.dev/cap-height-align/ 其中说的第一种方法我觉得就足够好了：
vertical-align: middle;
margin-block-start: calc(1ex - 1cap);
我做了一些测试确认它在图片和文字有各种尺寸关系、不同尺寸文字混排、不同 line height 等情况下都有正确的效果，非常不错。我能想到的注意事项：
1. 如果 cap height 中央和汉字中央不一致，它只能对齐到前者。我看了一遍相关 CSS 单位，后者好像做不到，但我的经验是很多字体中这二者基本是一致的。
2. 只适用于 inline layout，如果在 flex layout 等情况下已经用别的方案实现了对齐，重复使用这个会破坏对齐。
（如果不要求 inline layout，也就是说不需要图片和文字混合在一起换行，那就简单多了。例如要对齐一个按钮上的图标和文字，别用这个方法，用 flex。）
👍2