AutoThink：本地 LLM 的自适应推理技术
AutoThink 是一个旨在提升本地大型语言模型（LLM）运行效率的项目。它引入了一种自适应推理技术，能根据用户问题的复杂度智能分配计算资源。这项技术的核心在于区分简单和复杂问题，并为后者分配更多“思考”所需的 token，同时通过“转向向量”引导模型推理。
项目核心与技术
AutoThink 的主要目标是解决本地运行 LLM 时的效率瓶颈。其核心思想是并非所有问题都需要模型投入同等计算资源。项目通过判断问题的复杂度（高或低），为高复杂度问题分配更多 token（如 70-90%），为简单问题分配较少（如 20-40%）。
此外，项目利用了“转向向量”（steering vectors）技术，这是一种源自微软 Phi-4 论文的方法，用于引导模型的推理过程，使其更侧重数值准确性、自我纠正或更全面的答案探索。
测试结果与优势
作者在 DeepSeek-R1-Distill-Qwen-1.5B 模型上进行了测试。结果显示，在某些推理任务（如 GPQA-Diamond）上性能有显著提升。更重要的是，由于简单问题处理得更快，总的平均 token 使用量反而减少了。
AutoThink 的一大亮点是它完全在本地运行，不依赖任何外部 API，理论上可以应用于任何本地推理模型。
社区讨论与思考
评论区对 AutoThink 展开了热烈讨论。一个主要话题是商业模型（如 Gemini, OpenAI）是否已具备类似自适应能力，有人观察到它们对简单问题响应快，复杂问题“思考”久，但也有人认为是缓存或模型固有特性。
讨论还涉及开源模型的“过思”（overthink）问题，即对所有问题都投入过多计算。大家认为“过思”的定义很主观，取决于对答案精度和速度的需求。用户无法手动控制商业模型的思考深度也是一个痛点。
尽管存在挑战，许多人对 AutoThink 表示赞赏，认为它对提升开源模型竞争力至关重要。评论中也分享了优化本地 LLM 的土办法（如根据查询大小使用不同硬件），甚至提出了先用简单模型生成初步答案再喂给推理模型的创意想法。大家普遍对提高本地 LLM 效率和智能分配资源的方法感兴趣，并探讨了如何准确判断问题复杂度以及满足用户对答案精度和速度的需求。
UEFI 环境下的 PoE+ 供电协商解决方案
文章介绍了一个巧妙的解决方案，用于解决嵌入式系统中 PoE+ 供电依赖操作系统（OS）级协商的问题。通过在 UEFI 固件环境中运行一个自定义应用，设备可以在 OS 启动前就获得足够的电力。
问题背景：PoE+ 与 LLDP 的困境
标准的 PoE (802.3af) 提供高达 15.4W 的电力，但这对于某些需要更高功率（如 23W 运行，18W 启动）的嵌入式 x86 系统来说不够。PoE+ (802.3at) 可以提供高达 30W，但一些网络交换机要求设备通过 LLDP (Link Layer Discovery Protocol) 协议进行协商才能提供更高功率。问题在于，LLDP 协商通常发生在 OS 层面，这就形成了一个死循环：设备需要更多电力来启动 OS，但需要 OS 运行才能进行 LLDP 协商请求更多电力。物理层分类不足以满足这些交换机的要求。
解决方案：UEFI 应用进行协商
幸运的是，系统在初始 BIOS/UEFI 启动阶段的功耗较低，可以维持在 15.4W 以下。这提供了一个机会窗口。作者意识到 UEFI 固件环境具备网络栈访问能力，可以处理 TCP/IP。解决方案是开发一个独立的应用程序，使其在 OS 加载之前、在 UEFI 环境中运行，专门负责执行必要的 LLDP 协商并请求更高的功率级别。
在遇到主板厂商的阻碍后，他们找到了一位固件专家，开发了这个名为 PoePwrNegotiator 的 UEFI 应用。通过在 EFI shell 中使用一个简单的脚本 (startup.nsh)，该应用可以在启动时自动运行。这个自定义的 UEFI 应用成功协商到了所需的电力，确保了设备的可靠启动。作者现已将其开源，以帮助遇到类似问题的其他人。
社区讨论与相关思考
评论区引发了一些有趣的讨论。不少人立即联想到 USB Power Delivery (USB-PD)，并讨论了其协商机制（电阻或协议）。大家对为何 PoE 供电协商不总是由硬件芯片组处理而非依赖固件或驱动表示惊讶。
关于 PoE 标准本身、安全性和线缆限制（如铜包铝 CCA 线缆）的讨论也很深入。人们探讨了标准为何设定固定功率级别，并提出了线缆质量、电压降、以及线缆束中过热或火灾的风险等担忧。还有人好奇笔记本电脑或手机在关机状态下如何处理充电和电源协商，以及 BIOS 或专用充电控制器是否负责预启动电源管理。
《The Level Design Book》：一本关于游戏关卡设计的免费在线书籍
《The Level Design Book》是一本专注于电子游戏 3D 关卡设计的免费在线书籍。它旨在为不同经验水平的设计师提供一个易于理解、最新且具有批判性的学习资源。
书籍内容与特点
这本书系统地涵盖了 3D 游戏关卡设计的整个流程，从前期制作、战斗设计、布局、Blockout（粗模搭建）、脚本、灯光到环境艺术和最终发布。它不仅教授技术和流程，还深入探讨了关卡设计的文化、历史，并提供了丰富的案例研究，包括对经典游戏关卡（如《黑暗之魂》的 Undead Burg、《Thief》的 Assassins）和现实世界地点（如迪士尼乐园）的分析。
此外，书中还包含了教育者笔记、项目计划、工具列表和资源推荐，使其成为一个全面的学习工具。这本书可以免费在线阅读，并遵循 CC BY-NC-SA 4.0 许可协议。需要注意的是，网站明确指出这本书仍在大量建设中，结构和内容可能会有较大变动。
社区讨论与相关话题
评论区首先出现了一些关于“Level Design”双关含义的幽默评论。随后，许多人表达了对早期游戏关卡设计（如《Doom》到《Half-Life》时代）的怀念，认为它们比现在更具趣味性。但也有人反驳说，对于业余爱好者而言，现在是最好的时代，拥有大量易用的工具（如 Trenchbroom）和活跃的社区（如 Arcane Dimensions）。不过，为现代 AAA 大作制作用户地图或 Mod 确实变得非常困难。
关于 AI 和 LLM 在关卡设计中的应用也引发了讨论。有人畅想用 LLM 描述即可自动生成关卡，但更多人认为这会剥夺创造乐趣，且 AI 难以理解“有趣”和“有挑战性”，可能只会生成平庸的复制品。大家还讨论了现代游戏关卡是否变得过于“安全”和无聊，缺乏早期地图的惊喜感。评论中也提供了寻找作者信息（在 Appendix 中，创始人是 Robert Yang）和学习关卡设计的实用建议，如参加 Game Jam、阅读相关书籍或使用 Godot 等免费引擎进行实践。
构建高效 Monorepo 环境的关键要素
这篇文章深入探讨了如何构建一个高效的 Monorepo 环境，强调要实现开发者生产力的提升，需要投入大量精力构建或定制核心工具链。
Monorepo 的目标与核心原则
选择 Monorepo 不应盲从，而应基于提升一致性、组织协作和共享工具等实际目标。其核心原则是确保所有关键操作（如状态检查、构建、测试）的性能与代码变更量相关（O(change)），而非与整个仓库大小相关（O(repo)）。
关键工具与基础设施
对于大型 Monorepo，标准的 Git 可能不足，需要考虑稀疏检出或虚拟文件系统等高级源码控制技术。构建系统必须能高效构建目标并确定受变更影响的部分。虽然 Bazel 或 Buck2 功能强大，但作者建议如果可能，尽量利用现有生态系统的构建工具，并开发或使用“目标确定器”来识别需要重新构建或测试的代码。测试系统需要处理大量测试，支持自动重试 flaky tests 并只运行受影响的测试。持续集成（CI）系统依赖于目标确定器来触发必要的作业，而 Merge Queue 等机制对于保持主分支健康至关重要，