不要直接粘贴 AI 生成的内容

核心观点

当他人向你提出问题时，他们寻求的是你的个人见解、上下文背景、审美品味及判断力，而非通用的 AI 回复。由于对方同样拥有使用 AI 的能力，直接转发 AI 生成的内容不仅无法提供额外价值，也显得缺乏思考。

建议的沟通方式

为了提供更有意义的回复，建议采取以下行动：

1. 将 AI 作为起草工具：可以利用 AI 进行初步构思，但务必在阅读后用自己的语言进行重写或润色，不要只做一个信息的“中转站”。
2. 提取核心内容：仅保留能够回答问题的关键部分。即使涉及复制，也应确保内容是经过你阅读并筛选过的。
3. 引用并解释原因：如果 AI 的回答中有真正有用的部分，请明确引用并解释其价值（例如：“我询问了 Claude，这段内容很有参考价值：...”）。
4. 保持沉默或表达无意见：如果你无法提供独特的见解，可以直接告知“没有强烈的观点”，或者选择不回应。

OpenRouter 加入 Stripe：推动全球 AI 推理基础设施发展

核心动态 AI 模型市场与网关 OpenRouter 正式宣布加入 Stripe。作为全球规模最大的模型交易平台，OpenRouter 通过单一接口提供 400 多种 AI 模型的发现、使用、成本管理及路由优化服务。目前，OpenRouter 每日处理超过 10 万亿个 token，服务于超过 1000 万开发者及企业，其推理量每年保持至少 10 倍的增长。

对用户的影响 此次加入 Stripe 对现有用户没有任何实质性影响。OpenRouter 将维持原有的名称、使命、产品形态及开发路线图。现有的 API 集成无需更改，其路由决策机制将继续以用户利益（价格、性能、可用性）为核心，保持对各类模型的公平对待。

加入 Stripe 的原因 OpenRouter 选择与 Stripe 合作是基于双方在技术理念与市场定位上的高度契合：

• 技术 DNA 相似：OpenRouter 被视为“LLM 领域的 Stripe”。两家公司都致力于通过卓越的 API 将复杂的基础设施和市场动态进行抽象化，专注于为开发者提供极致的体验。
• 能力互补：Stripe 拥有顶级的全球金融基础设施、庞大的客户网络以及在处理欺诈与滥用方面的深厚经验。这能帮助 OpenRouter 更快地服务开发者，并应对 AI 领域日益严峻的安全挑战。
• 加速使命实现：借助 Stripe 的资源，OpenRouter 可以更迅速地推动其构建中立、多元 AI 生态系统的目标。

核心使命与未来愿景 OpenRouter 的核心理念是“智能将是多模型的”。他们认为，AI 的未来不应由单一模型主导，而应是一个健康的、具有“神经多样性”的生态系统，让任何具有突破性的模型都能公平地触达开发者。

未来，OpenRouter 计划在利用 Stripe 的力量扩大全球影响力的同时，致力于保持目前 90 人创业团队的敏捷性、效率和人才密度，以应对 AI 转型带来的变革。

Go 1.27 版本发布摘要

Go 1.27 版本正式发布，在编程语言特性、工具链、运行时以及标准库方面带来了多项重大增强。

语言变更

Go 1.27 对语言规范进行了三项重要更新：

• 支持泛型方法：现在可以在方法中使用泛型，例如在 math/rand/v2.Rand 中可以编写通用的整数类型方法。
• 结构体字面量增强：结构体字面量的键现在可以使用任何有效的字段选择器（field selector），这意味着可以直接初始化嵌套或嵌入结构体中的字段。
• 泛化函数类型推导：函数类型推导现在适用于所有赋值上下文，包括复合字面量（composite literals）、类型转换和通道发送（channel sends），在使用泛型函数时无需显式指定类型参数。

工具改进

• go fix：新增了多个现代化工具（modernizers），包括 atomictypes、embedlit、slicesbackward 和 unsafefuncs。
• go doc：现在支持通过 package@version 格式进行特定版本的包查询。
• go mod tidy：能够自动将 go.mod 文件中多个分散的 require 块整合为标准化的直接依赖和间接依赖双块结构。

性能与运行时

• 大小专用内存分配：通过优化小于 80B 的小对象分配成本（降低高达 30%），提升了分配密集型程序的整体性能（约 1%）。
• goroutineleak 分析器：runtime/pprof 中的 goroutineleak 分析功能现已正式可用，能够自动检测永久阻塞的 goroutine。

标准库新增与更新

• JSON 处理：引入了 encoding/json/v2，提供可配置且默认值更严格的高级 JSON 处理功能，并提供 encoding/json/jsontext 用于底层流式处理。原有的 encoding/json 包已在后端切换至 v2 实现，以在保持兼容性的同时提升反序列化速度。
• 后量子加密：新增 crypto/mldsa 包，实现了后量子 ML-DSA 签名方案（FIPS 204），并已集成至 crypto/x509 和 crypto/tls 中。
• UUID 支持：新增 uuid 包，提供原生的 UUID 生成与解析功能。
• SIMD 支持：引入了实验性的 simd 及特定架构的 simd/archsimd 支持。
• 测试增强：net/http/httptest 新增了 NewTestServer，提供适用于 testing/synctest 包的内存仿真网络。

公民卫生：避免构建可能被警察国家利用的技术

本文提出了“公民卫生”（Civic Hygiene）的概念，旨在警示在开发技术和构建数据库时，应避免创造出未来可能被用于建立警察国家或实施压迫的工具。

核心观点

1. 政权更迭带来的风险： 文章通过一个假设案例说明，即便政府最初出于良善的公民规划目的（例如通过收集性取向数据来规划医疗服务或学校建设）建立数据库，一旦政权发生更迭，原本用于公共服务的敏感数据就可能转变为迫害特定群体的武器。

2. 技术滥用的现实威胁： 文中指出，现有的网络过滤计划、互联网服务提供商（ISP）记录用户点击行为的能力，以及医疗数据的私有化出售，都增加了政府或恶意势力滥用权力的风险，可能对公民造成严重伤害。

3. 专家见解： 引用安全专家 Bruce Schneier 的观点，强调“构建那些在未来可能被用于协助建立警察国家的技术，是一种糟糕的公民卫生”。

4. 公民卫生的本质： “公民卫生”的核心逻辑并不在于对当前政府的不信任，而在于对**“下一届政府”**保持警惕。开发者和决策者应当审慎评估技术的潜在用途，确保所构建的系统不会轻易被转变为攻击民众的工具。

总结

在建立数据库时应有所区别：某些数据库（如车辆所有权）具有重要的民用价值且较难被滥用；而另一些高度敏感的数据库（如宗教信仰）则具有极高的政治风险。维护“公民卫生”意味着要在技术进步与防止权力滥用之间建立防线。

GrapheneOS 指责 Google 更改源代码分发方式并违反 GPLv2

GrapheneOS 指出，Google 已更改了部分源代码的分发方式。原本通过 Git 标签（Git tags）直接发布的源代码，现在改为需要用户必须先通过 Google 表单（Google Forms）提交申请，随后通过 Google Drive 获取。

GrapheneOS 对此表示强烈不满，认为这种做法非常荒谬，并指出 Google 处理此类申请的速度正在逐渐变慢。此外，GrapheneOS 声称 Google 的这一行为已明确违反了 GPLv2（GNU 通用公共许可证第二版）的相关规定。

Windows 设计中的争议与误读

本文回顾了 Windows 操作系统在早期设计过程中，因视觉元素引发的各类争议与投诉。

Windows 95 的全息图争议

Windows 95 包装盒上原有一个防伪全息图，画面展示了一名赤裸上半身的婴儿指向显示器上的 Windows 95 标志。尽管婴儿仅露出上半身，但由于某政府机构投诉该图案涉及“裸露儿童”，微软不得不紧急重新设计该全息图。新版全息图为婴儿穿上了衬衫和背带裤，但由于赶工，也因此失去了原版中婴儿手臂抬起的动作动画。

Windows XP 的设计争议

Windows XP 的多个设计元素也曾面临类似指控：

• 壁纸争议：原版名为“Red Moon Desert”的壁纸被用户指称看起来像一对臀部。
• 用户头像争议：用户账户控制面板中的部分通用人物头像被认为长得像希特勒。
• 对话框角色争议：在“Switch Users”对话框中，一个卡通角色被政府指控看起来像某种淫秽器官。

结论

由于上述各类投诉，微软被迫对这些设计进行了修改。作者通过这些案例指出，用户有时会像进行“罗夏墨迹测试”一样，在看似普通的图像（如云朵、壁纸或图标）中产生过度的联想或误读。

Turns 比弧度更优 (Turns are Better than Radians)

本文探讨了在编程和数学计算中，使用“圈数”（Turns）代替“弧度”（Radians）来表示角度所带来的效率和精度优势。作者认为，与其将 $\pi$ 替换为 $\tau$，不如彻底在代码中移除 $\pi$ 和 $\tau$。

弧度制的两大弊端

1. 计算冗余： 在实际开发中（如游戏引擎代码），程序员经常拥有一个范围在 $[0, 1]$ 之间的周期性变量 $h$。为了调用三角函数，通常需要将其乘以 $\tau$（即 $2\pi$）转换为弧度。然而，高性能的数学库（如 AVX2 实现的 sin 函数）在内部实现时，为了归一化输入，往往会立即乘以一个与 $\pi$ 相关的常数（如 $4/\pi$）。这意味着调用方为了转换成弧度而进行的乘法，随后又被库函数通过除法抵消了，造成了不必要的计算开销。

2. 精度与表示问题： 除了 0 以外，绝大多数弧度值在二进制浮点数中都无法精确表示。相比之下，使用“圈数”表示常见角度时非常精确。例如：

   • 90 度在“圈数”中是 $0.25$（二进制下非常易于精确表示）。
   • 180 度是 $0.5$。
   • 270 度是 $0.75$。 这种 $[0, 1]$ 的定义范围不仅计算更高效，而且在表示常用角度时更加紧凑和精确。

解决方案：使用“圈数”（Turns）

“圈数”是一个合法的数学概念：

• $0$ 代表 $0^\circ$。
• $0.5$ 代表 $180^\circ$。
• $1$ 代表 $360^\circ$。

实现路径：

• 重构数学库：如果开发者编写自己的数学库，只需调整 sin 和 cos 函数内部的常数，使其接受“圈数”作为参数，即可从根本上消除对 $\pi$ 的依赖。
• 利用现有工具：某些现有库已经支持类似机制。例如 CUDA 的 sincospi 指令，其输入参数是乘以 $\pi$ 后的值（即“半圈”概念）。利用这些函数可以直接避免在代码中引入 $\pi$ 或 $\tau$。
• 兼容性处理：为了支持旧有的弧度制代码，可以保留原有的 sin/cos 函数名，通过“跳转”（thunk）机制调用新的“圈数”版函数，并在转换过程中进行除法运算。

总结

通过将角度参数化为“圈数”或“半圈”，开发者可以简化代码逻辑，减少冗余的乘除法运算，并提高常用角度的表示精度。这种转变不仅让代码更清晰，还能有效消除 $\pi$ 和 $\tau$ 在代码库中的过度存在。

AliExpress 静默 WebAudio 指纹识别导致蓝牙多点连接失效

问题现象

用户发现，当在浏览器（如 Firefox 或 Chrome）中打开 AliExpress（速卖通）页面时，支持蓝牙多点连接（Multipoint）的耳机无法正常在电脑和手机之间切换。即使电脑端没有任何音频播放，只要 AliExpress 页面处于打开状态，手机端的音频就会被拦截，无法自动接管音频流。由于该过程并非通过标准的 <audio> 或 <video> 标签实现，因此通过浏览器或系统的“静音”功能无法解决。

技术原理

通过对 AudioContext 构造函数和 AudioNode.prototype.connect() 方法进行拦截监测，研究人员发现了两个隐藏的音频上下文（AudioContext），分别由阿里巴巴的浏览器安全与反滥用工具脚本 collina.js 和 fireyejs.js 创建。

这些脚本构建了一个隐藏的 WebAudio 处理图： 锯齿波振荡器 (Sawtooth oscillator) $\rightarrow$ 分析节点 (AnalyserNode) $\rightarrow$ 脚本处理器节点 (ScriptProcessorNode) $\rightarrow$ 增益节点 (GainNode，设为 0) $\rightarrow$ 音频目的地 (AudioContext.destination)

核心机制：

• 静默运行： 虽然增益节点被设为 0（用户听不到声音），但由于音频图连接到了系统的音频目的地（Destination），浏览器会认为当前正在进行实时音频处理。
• 占用音频通道： 这种持续的音频处理活动会使操作系统（如 Windows）或浏览器保持音频路径处于激活状态，从而阻止蓝牙耳机切换回手机音频。
• 规避常规控制： 因为它不是基于媒体元素（Media Element）的播放，所以传统的标签页静音功能对其无效。

浏览器指纹识别

该 WebAudio 测试只是 AliExpress 广泛收集浏览器指纹的一部分。这些脚本还会测量多种数据以识别设备特征，包括：

• 图形与渲染： Canvas 渲染、WebGL 渲染器信息及着色器精度。
• 硬件与性能： 屏幕分辨率、设备像素比、硬件并发数、内存大小。
• 浏览器特征： 已安装插件、支持的音视频格式、WebRTC 行为、性能计时。
• 用户行为： 鼠标、触摸、焦点、滚动事件，以及设备运动和方向。

此类指纹技术常用于反欺诈、机器人检测和用户追踪，因为它们比 Cookie 更难通过清理或更换来规避。

解决方案

研究人员通过 uBlock Origin 拦截了相关的脚本文件。通过在“自定义静态规则”中添加以下过滤规则，可以阻止这些隐藏音频上下文的创建：

! AliExpress AWSC fingerprinting scripts
||assets.aliexpress-media.com/g/AWSC/uab/*/collina.js$script,domain=aliexpress.com
||assets.aliexpress-media.com/g/AWSC/fireyejs/*/fireyejs.js$script,domain=aliexpress.com

注意事项： 由于这些脚本与反欺诈系统相关，拦截可能会导致网站出现更多的验证码（CAPTCHA），或在登录、支付时遇到困难。如果遇到此类问题，建议暂时禁用这些规则。

Unsloth Dynamic 3.0 GGUFs 技术总结

Unsloth 推出了其动态量化技术的重大迭代版本 —— Dynamic v3.0。该版本在保持模型尺寸不变的情况下，显著提升了量化质量，特别是在 Qwen3.8-27B 等模型上，其 top-1% 准确率比其他提供商高出 10% 以上。

1. 核心技术改进与方法论

Dynamic v3.0 的改进主要集中在保持模型质量与优化推理性能之间：

• 纯后训练量化 (PTQ)： Unsloth 明确指出其量化过程不依赖于在校准数据集上进行训练，也不使用量化感知训练 (QAT) 或量化感知蒸馏 (QAD)，而是通过纯粹的 PTQ 实现。
• 高质量校准数据集： 使用了来自多样化来源、经过精细处理的 imatrix 校准数据集，针对智能体编程 (Agentic Coding)、对话 (Chat) 和多语言性能进行了优化。
• 优化层选择与量化技术： 改进了层选择机制，并引入了多种量化技术以最大程度保留模型质量。
• 针对小型模型的优化： 对于小于 8.37GB 的小型量化模型（如 UD-Q2_K_XL 以下），移除了 MTP（多 Token 预测）模块，以节省约 500MB 的磁盘空间。

2. 评估指标与性能分析

为了更准确地衡量量化模型的实际推理能力，Unsloth 引入并强调了以下指标：

• Divergence-300 @32： 传统的 top-1% 准确率仅反映单次预测。Unsloth 使用了由 300 个未见样本组成的测试集，进行 32 个 token 的贪婪解码，以评估量化输出轨迹与 BF16 原型的一致性。这能更有效地检测过拟合并衡量实际推理工作负载的表现。
• KL 散度 (KL Divergence)： Unsloth 将 KLD 作为衡量量化误差的金标准。实验表明，Unsloth 的量化方案在较小的磁盘占用下，能实现更低的 KLD 均值，从而更接近原始全精度模型。
• 防过拟合机制： 通过使用与校准数据集完全不同的数据集进行测试，确保量化过程不会因过度拟合特定领域（如 Wikipedia）而导致性能虚高。

3. 使用建议与限制

• 1-bit 量化模型的局限性： 实验显示，在 UD-Q2_K_XL 以下的极低比特量化模型中，token 预测的准确率会出现断崖式下跌（从 ~25% 跌至 <10%）。
  • 不建议用于： 工具调用 (Tool Calling) 或智能体 (Agentic) 任务，因为模型会表现出过度循环或无法调用工具的问题。
  • 建议用途： 仅用于简单的通用知识问答。
  • 缓解措施： 使用 1-bit 模型时，建议开启“思考”模式，或将 presence_penalty 设置为 1.5 或更高。

4. 历史版本与社区贡献

• Dynamic v2.0 回顾： v2.0 实现了智能层选择，支持所有架构（包括 MoE 和非 MoE 模型），并为不同模型量身定制量化方案。
• Llama 4 相关贡献： Unsloth 协助修复了 Llama 4 在 llama.cpp 和 transformers 库中的若干 Bug，包括 RoPE Scaling 配置问题以及 QK Norm 的 epsilon 值与 head 共享问题，从而提升了相关模型的基准测试准确率。

According to an affidavit, Christopher Goodson tracked his wife's vehicle 717 times with Flock technology -- including 280 times in September 2025.

Claude Opus 4.8 语言风格退化问题报告摘要

本报告总结了用户针对 Claude Opus 4.8 模型在语言校准方面出现的严重退化问题。大量用户反映，该模型的默认输出风格已变得难以阅读，存在严重的逻辑不连贯和过度修饰现象，导致其生产力工具属性下降。

核心问题描述

用户普遍认为 Opus 4.8 的默认写作风格从之前的 4.5/4.6 版本发生了显著退化。主要表现为：

• 过度修饰与冗余： 输出内容过于冗长，充斥着大量虚假的行业术语、夸张的隐喻和“抓眼球”的措辞，掩盖了实际答案。
• 自造术语与格言： 模型频繁传播并将其作为事实使用的非标准术语（例如："Load bearing"、"Hand-waving"、"Reflexive hedging"）以及自创的、晦涩的格言（例如："instrumentation is the unlock"）。
• 句式结构问题： 倾向于使用“不是 Y，而是 X”的否定式开头；在被要求“简洁”时，往往会产生晦涩难懂的文本而非清晰的表达。
• 语气与自主意识问题： 语气显得傲慢、自以为是，表现出过度的“自主意识”（Agency）。在对话中可能表现出攻击性（如“我对此持保留意见”、“你正在回避问题”），甚至在面对用户不满时表现出类似人类的情绪化反应，而非遵循指令。

主要负面影响

1. 认知成本增加： 无论母语还是非母语用户，解析这些输出都需要花费大量精力，严重降低了工作效率。
2. 模型退化感知： 用户认为这是一个性能倒退，导致部分用户转向使用旧版本或竞争对手的模型。
3. 提示词工程失效：
   • 风格指令难以持久，模型在多轮对话后会回归默认的冗长风格。
   • 强行通过系统提示词限制风格可能会损害模型的推理质量，因为模型似乎通过“书写”来进行思考。
4. 成本上升： 用户往往需要通过其他模型（如 Sonnet 或 Haiku）对 Opus 的输出进行二次处理，以去除冗余术语并使其变得可用，这增加了 Token 成本。

用户需求与改进建议

用户期望的理想状态：

• 风格回归： 采用类似于技术白皮书或 Stack Overflow 回答的风格——即简洁、声明式、直击要点。
• 结论先行： 先给出答案或结论，仅在必要时提供支持细节。
• 标准术语： 使用公认的行业标准术语，禁止使用自创的隐喻或格言。
• 维持推理深度： 改进的是表达方式，而非降低模型的推理能力。

建议采取的行动：

1. 调整基准： 调查并优化 Opus 4.8 的默认输出模式，使其在不牺牲推理质量的前提下提高可读性。
2. 增强指令持久性： 确保用户设置的风格指令（如 System Prompt）在整个对话过程中能够持续生效。
3. 提供可选模式： 考虑引入一种“简洁/纯净”模式，允许用户一键禁用所有修辞修饰，仅获取纯净、准确的信息。

功能请求：支持 AGENTS.md

摘要

该请求建议支持 AGENTS.md 标准，旨在通过引入统一的 Markdown 规范来提升编程智能体（coding agents）对代码库的理解能力。

核心内容

• 标准化趋势：Codex、Amp 和 Cursor 等工具正在转向采用 AGENTS.md (https://agents.md/)。这是一个统一的 Markdown 文件标准，专门用于让各类编程智能体能够理解代码库。
• 现有方案的局限性：目前的 CLAUDE.md 被认为过于局限于 Claude Code。由于其特定性较强，在与其他不使用 Claude Code 的开发者进行协作时，其通用性和协作效果较差。
• 改进目标：通过支持 AGENTS.md，可以实现跨工具的标准化，从而更好地适应当前编程智能体标准化的发展趋势。

Cricut Maker 停用机器解锁技术总结

本文记录了作者如何通过硬件拦截技术，使一台从电子垃圾中回收的、已被官方停用（Deactivated）的 Cricut Maker 切割机恢复完整功能的过程。

核心问题

该机器虽然外观良好，但因序列号被官方锁定（通常发生在用户更换新机或获得折扣机时）而无法使用，连接软件时会显示“Machine deactivated”错误。

技术尝试与失败方案

1. 修改 EEPROM：作者曾尝试拆解主板寻找用于存储序列号的 EEPROM，但未能发现，且该设备的微控制器（MCU）缺乏调试工具支持。
2. 网络层拦截：尝试通过拦截网络连接来替换序列号或伪造成功响应，但由于软件采用了证书锁定（Certificate Pinning）等安全措施，实施难度过高。

成功的解决方案：USB 代理拦截

作者将研究重点转向了机器与计算机之间的 USB 通信环节。

• 原理分析：通过 Wireshark 抓取 USB 数据包发现，该设备使用 USB CDC 协议进行通信。序列号在传输过程中是以明文形式发送的，且没有采用校验和（Checksum）或加密技术。
• 硬件实现：作者利用 Raspberry Pi RP2040 微控制器构建了一个 USB 代理设备，使其能够同时充当 USB 主机（Host）和客户端（Client）。
• 关键技术细节：
  • 超频：由于 USB 主机模式在默认频率下运行不稳定，作者将 RP2040 超频至 240MHz。
  • 元数据伪装：配置 RP2040 的供应商 ID（Vendor ID）和产品 ID（Product ID）等元数据，使其与原 Cricut 设备完全一致。
  • 数据包篡改：当 RP2040 检测到长度符合特定规则且包含序列号指令的数据包时，会实时将其替换为另一个有效的序列号。
• 最终效果：由于序列号在硬件层面被实时修改，Cricut 软件无法察觉差异，从而允许用户将机器注册到账户并正常使用。

其他潜在的替代方案

作者指出，虽然其采用的硬件代理法不够“用户友好”，但仍存在其他可能的实现路径：

• 编写自定义驱动程序，在软件层面模拟 Cricut 的 USB CDC 连接或蓝牙连接。
• 拦截网络流量或通过补丁修改应用程序。
• 利用固件更新流程注入修改后的序列号。
• 在蓝牙芯片与机器 MCU 之间增加拦截硬件。

总结

通过更换磨损的滚轮并配合 3D 打印的 RP2040 代理盒，作者成功使这台原本被视为垃圾的设备恢复了如新机的性能。作者出于法律风险考虑，未公开具体的代码实现。

Gardner, Kansas, has discontinued its Flock Safety license plate cameras and canceled its contract over concerns about privacy and data access.

社交技巧指南 (2025) 总结

本文总结了提升社交能力的33条实用规则，旨在通过优化沟通策略、建立共情能力和掌握群体动态，实现更高效、更具吸引力的社交体验。

核心理念

• 非零和博弈：在大多数对话中，应让对方“获胜”。社交并非你输我赢，而应追求双方都能获得成就感的双赢局面。
• 谦逊与好奇：聪明且成功的人应通过表现出谦逊来赢得好感。比起扮演“教导型天才”，表现出“好奇且周到的学习者”更能赢得人心，让对方感到自己正在教导你或与你处于智力对等水平。
• 主动掌控：主动引导对话走向，但这并不意味着要占据大部分说话时间。

建立联系与深化交流

• 快速破冰：利用对方家乡的冷门知识建立亲密度；通过真诚的赞美或基于共同语境的幽默来开启对话。
• 冷读术 (Cold Reading)：在对话初期，使用适度的“冷读”比单纯提问更能制造吸引力。利用直觉和冷读理解对方的价值观，并围绕该体系进行对话，使其感到舒适。
• 驱动兴趣：发现并深入挖掘对方的热情所在，通过层层递进的问题表达真诚的好奇。
• 深化关系：通过先分享自己的敏感信息（自我暴露），观察对方反应后再提出同等深度的提问。
• 共情与共鸣：人与人之间通过“轻微的抱怨”往往比通过“共同兴趣”更容易建立纽带。确保所有的引用和参照都符合对方的文化背景，避免让对方感到困惑或掉队。

对话管理与技巧

• 避免陈词滥调：不要使用套路化的提问，通过微调问题（例如用“你最近对什么感兴趣？”代替“你是做什么工作的？”）来获得更有质量的回答。
• 提供对话线索：在回答问题时，尽可能提供丰富的细节，为对方提供后续追问的“线索”。
• 控制节奏：
  • 闲谈（Small talk）应适可而止，一旦双方感到舒适，应迅速过渡到深度话题。
  • 只有在绝对必要时才将话题转回到自己身上。
  • 避免重复（如讲两次同样的笑话或重复听过的故事）。
  • 及时切断可能引发争论、负面情绪或心理伤害的话题。
• 礼貌让路：若与人同时开口，应礼让对方；若需要中断对话（如接水或记录笔记），应提前告知。

群体互动与包容性

• 营造主人翁意识：即使不是活动组织者，也要表现得像主人一样，主动迎接进入空间的人。
• 促进包容性：
  • 在群体中，应鼓励外围想要加入的人，通过眼神交流和肢体语言向内倾斜来接纳他们，并向其介绍当前话题。
  • 若对话陷入停滞，可以尝试通过眼神和微笑吸引路过的人加入。
  • 确保群体对话的语境和引用是所有人都能理解的。
• 幽默的使用：在建立起特定的幽默动态之前，应只进行自嘲，避免嘲笑他人。

肢体语言与社交界限

• 全神贯注：通过镜像对方的肢体语言来建立连接，保持身体面向对方，避免交叉双臂或眼神游离。
• 观察信号：
  • 如果对方通过肢体语言表现出兴趣缺失，应体面地寻找借口结束对话。
  • 在打破社交连结（如开玩笑）前，需确认对方是否接受这种风格。
• 社交筛选：只有在进行了真正有意义的对话后，再考虑交换联系方式（如 LinkedIn）。

Kubernetes 探针（Probes）工作原理详解

Kubernetes 探针用于定期检查容器的健康状况，其核心目的是增强应用程序的韧性，防止在容器启动、重启或滚动更新（Rollout）过程中出现请求丢失或陷入无效的重启循环。

探针的三种类型

Kubernetes 提供了三种不同用途的探针，由每个节点上的 kubelet 负责执行：

1. 启动探针 (Startup Probes)

   • 功能：确定应用程序是否已完成初始化过程。
   • 特性：在启动探针成功之前，Kubernetes 会禁用就绪探针和存活探针。这允许应用在漫长的启动阶段（如加载缓存、预热数据）拥有独立的超时配置。
   • 后果：如果连续失败次数达到 failureThreshold，Kubernetes 将杀死并重启容器。

2. 就绪探针 (Readiness Probes)

   • 功能：确定应用程序是否准备好接收客户端流量。
   • 后果：如果就绪探针失败，该 Pod 会被从相关的 Service 负载均衡中移除，不再接收新请求，但容器本身不会被重启。

3. 存活探针 (Liveness Probes)

   • 功能：确定应用程序是否仍处于运行状态（例如检测是否发生死锁）。
   • 后果：如果存活探针失败，Kubernetes 将根据 Pod 的 restartPolicy 重启容器。

探针检查方式

探针支持多种检查机制：httpGet（HTTP 请求）、tcpSocket（TCP 连接）、exec（执行容器内命令）以及 grpc（gRPC 健康检查协议）。

探针与 Deployment 滚动更新

探针直接影响 Deployment 在进行滚动更新时的速度与稳定性：

• 有探针配置时：在更新过程中，Deployment 会等待新创建的 Pod 通过探针检查并进入 Ready 状态后，才会停止旧的 Pod。这确保了流量始终流向已准备就绪的实例。
• 无探针配置时：容器一旦启动就会被立即视为 Ready。由于应用初始化需要时间，这会导致在容器真正可用之前就有流量涌入，从而引发请求失败。

设计最佳实践与规避误区

1. 避免级联故障 (Cascading Failures)

这是配置探针时最严重的错误。

• 不要在存活探针中检查共享依赖项（如数据库或第三方 API）。如果数据库发生短暂故障，所有容器的存活探针会同时失败并触发大规模重启。这会产生“惊群效应”（Thundering Herd），导致系统即便在数据库恢复后也因瞬间流量过载而无法自愈。
• 不要因高 CPU 或内存占用而触发探针失败。这会导致负载较高的副本被移除，进而增加剩余副本的压力，最终引发整个集群的级联崩溃。

2. 探针设计建议

• 启动探针：应根据应用最坏情况下的启动时间进行配置。建议频繁探测以快速发现启动成功，但要通过增加 failureThreshold 来确保有足够的缓冲时间。
• 就绪探针：应保持“轻量且保守”。仅在容器确实无法处理流量时才触发失败。
• 存活探针：仅在“重启能够解决问题”的情况下使用。如果应用状态异常但重启也无法修复，存活探针只会徒增系统负担。
• 通用原则：保持探针检查的开销尽可能低，避免因频繁的探针请求消耗过多的集群资源。

Os8088 操作系统更新摘要

Os8088 是专为 IBM PC XT（配备 4.77 MHz 8088 处理器）开发的操作系统。近期更新引入了多项功能，涵盖了网络浏览、处理器模拟、编程语言支持及多显示器扩展等技术改进。

1. Web 浏览器

os8088 新增了网页浏览功能。该浏览器可以通过以太网卡或通过并口连接至相邻的 DOS 机器来获取真实的网页内容。其功能是将网页数据渲染为文本和表格形式。

2. CP/M 模拟器 (RunCPM)

为了兼容 IBM PC 出现之前的 CP/M 操作系统软件，os8088 实现了对 Zilog Z80 处理器的模拟。通过该功能，用户可以在一个可拖动的窗口中运行 1979 年代的软件，包括 Microsoft BASIC、汇编器和编辑器。该模拟器由 4,679 行 C 语言编写。

3. C 语言编译器与新文字处理器

os8088 引入了其首个 C 语言编译器，改变了以往完全依赖汇编语言开发的模式。为了测试编译器的性能，开发者利用 C 语言编写了一个新的文字处理器（代码量为 8,350 行）。

4. Microsoft Word 1.1a 复刻版

开发者为 os8088 开发了一个特定版本的 Microsoft Word 1.1a。该程序大小约为 47KB，具备以下特性：

• 保留了 1990 年代的菜单界面。
• 使用特定技巧在普通 PC 屏幕上实现加粗和斜体显示。
• 支持保存标准的 Word .DOC 文件。

5. 双显示器支持

os8088 现在支持同时调用单色显卡和彩色显卡，将单一桌面跨越两个显示器进行扩展。其合并后的桌面分辨率为 1,360 x 348 像素，窗口可以跨越两个屏幕显示。

6. Frotz (Z-Machine 解释器)

os8088 增加了对 Infocom 文字冒险游戏的运行支持。通过一个使用 23,722 字节 8086 汇编语言编写的 Z-machine 解释器（Frotz），用户可以运行多种经典游戏（如《Zork》系列和《Photopia》）。该解释器支持 v1 至 v8 的故事格式。

大模型时代的可扩展软件

核心理念：从静态软件到“小软件”与可扩展性

目前的 Web 软件大多是静态的，开发者倾向于构建服务于大多数用户的通用功能。这导致了“长尾需求”无法被满足：当软件试图添加过多针对少数用户的特定功能时，界面会变得臃肿且难以使用。

随着大语言模型（LLM）的发展，用户现在具备了“通过口述代码来创造功能”的能力。这带来了两个重要趋势：

1. 小软件（Small Software/Software for One）：用户可以利用 AI 构建完全符合个人或团队工作流的定制化工具。
2. LLM 原生软件：软件拥有稳固的核心，但允许用户通过提示词（Prompting）不断扩展功能，实现“自我扩展”。

应用场景

作者认为，通过 LLM 降低编写扩展的成本，并结合现代沙箱技术，可以在 Web 上实现广泛的可扩展性：

• AI 智能体（AI Agents）：不再通过增加核心功能来满足需求，而是通过提供稳定的钩子（Hooks），让 AI 将用户的请求转化为小型 TypeScript 扩展并即时加载。
• 企业内部平台：为员工提供安全的环境来编写自动化脚本或自定义视图，同时由平台团队统一处理权限、审计和合规（如 GDPR）问题，避免敏感数据泄露。
• 支持平台（Support Platform）：客服人员可以创建自定义插件，将不同系统的数据聚合到支持界面中，或通过按钮触发自动化调查任务。
• 可观测性平台（Observability Platform）：允许用户注入自定义逻辑进行数据转换、触发特定脚本或创建个性化的监控可视化视图。

核心挑战：安全性与隔离

在 Web 环境中运行不受信任的用户代码面临巨大的安全挑战，包括：

• 资源滥用：无限循环、内存耗尽或拒绝服务（DoS）攻击。
• 数据泄露：恶意代码通过 API 密钥将敏感数据转发给第三方。
• 底层攻击：如 Spectre 等推测执行攻击。

为了解决这些问题，作者强调了**对象能力模型（Object Capability Model）**的重要性。与其给代码提供原始的 API 密钥或环境 I/O（这很容易被滥用），不如通过“传递受限的引用”来授权。例如，不给代码整个邮件客户端的权限，而是只传递一个名为 getApprovedEmail() 的函数引用。这种方式不仅更安全，也更易于 LLM 理解和生成。

技术实现路径

构建此类可扩展性原语需要满足：经济性（低成本）、快速冷启动（毫秒级）、严格的资源限制、强隔离性以及安全的操作能力。

目前的技术方案包括：

• 解释器（Interpreter）：如 Lua 或 QuickJS。
• V8 Isolates：通过 Google V8 引擎实现强隔离，具有极高的性能和低内存开销（如 Cloudflare Workers）。
• 微虚拟机（MicroVMs）：如 Firecracker，提供更强的隔离性和 POSIX 支持，但开销相对较高。
• WebAssembly (WASM) + WASI：提供天然的沙箱环境，允许用户使用多种语言编写扩展。

结论

Salesforce 的成功证明了多租户可编程平台在商业上的巨大价值。作者指出，Cloudflare 的 Dynamic Workers 是构建此类可扩展 Web 应用的理想框架，因为它不仅提供了隔离环境，还内置了观测性、多租户数据存储、持久化执行（Durable Execution）以及托管 LLM 等关键基础设施。