## 海洋中意想不到的时间守护者 地球上的生命以大约24小时的周期运作——昼夜节律——控制着从睡眠到新陈代谢的一切，由内部生物钟驱动，并以阳光为校准。这些生物钟基于CLOCK和BMAL1等基因，出乎意料地广泛存在，甚至出现在像藻类这样简单的生物体中。 然而，最近对日本海岸附近新发现的一种水母物种的研究挑战了我们对这些节律的理解。这种水螅纲动物拥有功能性的昼夜节律，尽管*缺乏*大多数动物钟的核心基因。 值得注意的是，它的生物钟以20小时的周期运行，并且似乎与产卵计时器有关。 这一发现表明，替代的、非常规的钟机制可能比以前认为的更常见。科学家们现在正在质疑，仅仅关注已知的“钟基因”是否限制了我们在动物王国中寻找多样化的计时系统能力，从而可能重写我们对生物时间的理解。
每日HackerNews RSS
《量子》杂志最近的一篇文章详细描述了一项引人入胜的发现：某些水母物种如何在缺乏典型昼夜节律基因的情况下，保持惊人的精确繁殖时间。这些水螅纲动物利用一个独特的双层系统：一个温度敏感的20小时内部振荡器，以及由日出触发的每日重置。
正如一位评论员所说，这个“拼凑”的系统展示了进化利用现有机制而非最佳设计的倾向。这些水母的时间机制不依赖于传统的钟基因途径，引发了人们对自然界中可能存在多少其他非常规计时方法的问题。
该讨论强调了这种非常规方法的潜在韧性，表明它可能为长期环境破坏（如长时间的黑暗，甚至行星变化）提供缓冲。一些评论员还思考这个系统是否优先考虑能量储备和工作周期，确保在能量可用时进行繁殖。
## AI 对软件生产的“AI效应”：一次客观评估
尽管有说法称AI编码工具能带来巨大的生产力提升（2倍到100倍！），但近期对Python软件包索引（PyPI）的分析显示情况更为复杂。ChatGPT发布后，整体软件创作并未激增；新的软件包*创建*速率保持稳定，甚至出现由垃圾信息而非实际开发引起的激增。
软件包*更新*略有增加，但这一趋势在现代AI工具兴起*之前*就已经开始，很可能是由持续集成实践的采用推动的。然而，一个显著的影响是可见的：**关于AI的软件包更新频率更高**，尤其是那些越来越受欢迎的软件包。流行的AI相关软件包的更新频率比非AI软件包高出2倍以上。
这并非所有开发者的普遍生产力提升。相反，数据表明这是一种集中效应，由两个潜在因素驱动：构建AI工具的开发者可能更擅长*使用*AI工具，并且——至关重要的是——**围绕AI的大量投资和炒作正在推动AI生态系统内部的开发和迭代。**
“AI效应”并非所有软件的寒武纪大爆发，而是围绕AI软件的一次集中爆发。
## AI 应用在哪里？- Hacker News 总结
最近 Hacker News 上出现讨论，质疑尽管开发者生产力有所提高，但使用 AI *创建* 的、广为人知且有影响力的应用却很少。 大家的共识倾向于软件的 *构建方式* 发生了变化，而不是涌现出大量新的、面向公众的应用。
许多评论员指出，虽然 AI 在原型设计和加速初始开发方面表现出色，但“最后 10%”——完善、维护和扩展——仍然具有挑战性和耗时。很大一部分 AI 辅助开发的结果是个人工具和解决个人需求的“一次性”应用，而不是可以广泛销售的产品。
一些用户指出，通过公共软件包仓库（如 PyPI）来衡量影响是具有误导性的，因为许多 AI 驱动的项目仍然是私有的。 还有人认为，围绕 LLM 的“AI 驱动”包装层已经饱和，缺乏真正新的软件功能。 讨论还涉及将 AI 生成的想法转化为引人入胜的游戏的难度，以及一种普遍趋势，即使用 AI 来增强现有工作流程，而不是创建全新的应用程序。 最终，大家的观点是，AI 正在改变 *谁* 构建软件以及 *如何* 构建软件，但并不一定会导致大量新的、公开可用的应用程序——目前为止。
## RYS II：在现代LLM上重复分层仍然有效 这项研究调查了“重复自我”(RYS)方法——复制Transformer模型的部分以提升性能——是否能从最初在Qwen2-72B上的成功扩展到更新、更强大的模型，如Qwen3.5-27B。核心问题是：重复分层是偶然现象，还是Transformer的普遍特性？ 研究结果证实RYS仍然有效。对Qwen3.5-27B的扫描表明，复制连续的中层块可以显著提高数学推理和EQ（情商）基准测试的表现。广泛的测试，包括对3,024种配置进行Beam Search，以及使用代理模型评估200万个样本，确定了最佳的层复制方案。 关键结果表明，模型的“推理区域”——即模型以与格式无关的方式处理信息的地方——与从重复分层中获益最多的区域相符。简单、连续的块复制始终优于更复杂的组合，突出了Transformer内部存在离散的功能电路。该研究还在HuggingFace上发布了扫描代码和新的RYS模型。 最终，这项研究强化了Transformer将推理组织成可识别电路的观点，并且允许模型重新访问这些电路可以提高性能。这种方法与其他优化技术（如微调和量化）是正交的，可以提供潜在的“免费”性能提升。
## LLM神经解剖学与“通用语言”？
这次Hacker News讨论围绕着对大型语言模型（LLM）内部机制的研究，特别是关注一种名为“RYS”（重复自己）的技术——复制特定层以提高性能。作者的实验表明，LLM似乎在其中间层发展出一种与语言无关的“思维空间”。通过对英语、普通话和Base64进行余弦相似性测试，结果显示表征在早期就趋于收敛，表明模型优先考虑*说什么*，而不是*怎么说*。
有趣的是，最佳性能提升仅仅来自于重复连续的层块，这表明Transformer架构内部存在一个连贯的推理电路。进一步的讨论探讨了对模型效率、边缘计算以及与人类语言学习的潜在联系的影响。研究人员正在研究动态层路由，并将层复制与消融（移除）相结合，以优化性能和VRAM使用。作者已在GitHub上发布代码([https://github.com/dnhkng/RYS](https://github.com/dnhkng/RYS))以供进一步探索。
``` $ nb install jq -> 正在解析依赖... -> 安装 1 个包: jq 1.7.1 -> 下载 + 安装 1 个包... ✓ jq -> 完成，耗时 1102.4 毫秒 $ nb list jq 1.7.1 $ nb update # 自我更新 nanobrew -> 更新 nanobrew... -> nanobrew 更新成功 ```
## Nanobrew：一款更快的macOS包管理器
Nanobrew是一款新的macOS包管理器，旨在提高速度，使用Zig语言构建，并与Homebrew兼容。它利用Homebrew现有的基础设施——CDN、CI、打包和维护者——通过使用Homebrew API安装预编译包。
讨论的重点在于Homebrew的速度是否是一个重要问题，一些用户体验到更新缓慢（尤其是下载和依赖关系解决），而另一些用户则认为“足够好”。Homebrew的维护者承认速度问题，并正在开发一个官方的Rust前端以实现完全兼容性。
主要讨论点包括：Nanobrew的兼容性依赖于Homebrew的后端，Homebrew配方中潜在的Ruby依赖，以及像Nix和MacPorts这样的替代方案的优势。一些用户报告了Nanobrew的功能问题，而另一些用户则对潜在的性能提升感到兴奋。最终，其价值主张取决于速度提升是否超过了采用新的、可能不太成熟的包管理器的风险。
摄影师詹姆斯·贝克放弃了大量的照片编辑，取消了他长期订阅的Adobe Lightroom。他的转变始于2022年开始拥抱胶片摄影，发现实验室提供的预先编辑扫描件只需要进行少量调整。 他厌倦了花费时间和金钱——每年240英镑——来细致地编辑数字RAW文件。现在，贝克专注于使用富士X100VI和Camp Snap Pro相机拍摄更好的照片，这两款相机都旨在提供卓越的JPEG输出。 他发现摄影过程本身更有乐趣，优先考虑图像创作而非后期制作，目前正在享受一场足球比赛，而*没有*在编辑照片！这种改变代表着转向一种更直接、更少依赖笔记本电脑的创作流程。
This appears to be a snippet of a PDF file's internal data, not human-readable content. It's mostly binary and encoded information. There is no meaningful text to translate into Chinese. It's essentially gibberish without the proper PDF parsing tools.
对不起。
## 导弹防御：一个复杂的资源分配问题
最近的冲突凸显了导弹防御的挑战，其本质是一个复杂的资源分配问题。虽然看似简单，仅仅拥有足够的拦截器并非解决之道。单个拦截器的可靠性有限——美国系统的杀伤概率约为56%——且有效性随着针对单个弹头的部署数量而提高。
然而，成功并非保证。至关重要的是，*探测*和*跟踪*弹头（P(track)）至关重要；拦截器对未被发现的目标毫无用处。对手会主动攻击跟踪系统，即使是探测方面的轻微故障也会大幅降低杀伤概率。
此外，问题随着多个来袭弹头和诱饵而升级。“武器-目标分配”问题——优化分配拦截器以最大化资产保护——是NP完全问题，这意味着解决方案的复杂性随着威胁数量呈指数级增长。虽然可以使用现代算法解决，但攻击方通过部署弹头和诱饵来决定问题的大小，从而造成重大的防御挑战。 目前美国的能力针对性很窄，即使是防御中等程度的攻击也需要大幅增加拦截器库存和近乎完美的跟踪能力。
## NanoClaw & OneCLI：安全的代理访问
NanoClaw，一个代理平台，正在通过集成OneCLI作为其默认凭证和代理层来增强安全性。这解决了授予代理访问敏感系统固有的风险——例如，AI代理删除用户整个邮箱的事件。
此前，NanoClaw 在内存中管理密钥。现在，它利用OneCLI的Agent Vault，确保代理*绝不*直接处理API密钥。每个代理都在自己的隔离Docker容器内运行，OneCLI通过网关控制访问，仅在请求期间注入凭证。
OneCLI允许制定细粒度的策略，超越简单的凭证管理，包括速率限制（例如，限制每小时的邮件删除数量）以及未来的功能，如限时访问和审批流程。这可以防止失控的操作，并提供可审计的控制。
本质上，NanoClaw提供运行时隔离（容器），而OneCLI提供凭证和策略隔离。两者都是开源的，提供了一个强大的框架，可以在不向关键系统暴露不必要的风险的情况下，安全地利用AI代理的力量。
## NanoClaw 与代理安全未来 - 摘要
NanoClaw，一种新工具，因采用 OneCLI Agent Vault 而备受关注，引发了关于人工智能代理和 CLI 工具安全性的讨论。虽然这是朝着更好的安全实践迈出的一步，但评论员表示，CLI 本质上比 OAuth 等先前的方案具有较弱的安全模型，尤其是在密钥轮换和 API 访问控制方面（特别是对于 REST、GraphQL 和 JSON-RPC）。
对话围绕着从 CLI *向* 利用 OpenAPI 规范和基于代理的安全解决方案的潜在转变展开。人们对 OneCLI 等工具缺乏安全审计以及数据泄露的风险表示担忧。
用户正在试验“爪子”（代理），用于执行诸如自动化信息收集、总结数据和自动化简单工作流程（从天气简报到代码部署）等任务，这突出了便利性，但也承认了令牌消耗成本。一个关键的需求是更用户友好的访问控制，例如 1Password 风格的代理操作批准，以及更好的隔离，以防止即使具有 root 权限的恶意操作。
最终，讨论指向一个快速发展的领域，其重点正在转向用于人工智能代理的安全、基于策略的代理和基于意图的访问控制。
路过儿时的工作场所，引发了一种顿悟：建立和*维持*友谊似乎比以往任何时候都更难。作者在家庭逐渐扩大和五年远程工作的情况下，渴望更深入的、面对面的联系，并注意到一种转变，从用社交媒体来补充人际关系，到将其视为替代品。
为了对抗这种“友谊衰退”，作者尝试了发起双语玩乐小组和“与朋友一起工作”计划，最初都成功地创造了互动。然而，作者意识到，持续而有意义的联系需要大量的*时间*——这是繁忙的成年人稀缺的资源。
与老朋友重新建立联系也面临着生活阶段和距离的挑战。最终，解决方案在于有意识地行动：主动出击的惊喜电话和即兴的“拜访”，以培养现有的情谊。关键在于？不要被动地等待联系，而是积极地*创造*它，认识到真正的友谊需要超越在线互动轻松的努力。
## 友谊衰退：摘要
一篇Hacker News讨论探讨了现代生活中随意社交联系的减少以及建立和维持友谊的挑战。 几个因素被提及：舒适的居家生活减少了外出社交的需求，科技和屏幕时间带来的隔离效应，以及现代生活——工作、家庭和通勤——带来的压力，导致人们用于培养关系的精力和时间减少。
评论者指出，社交规范发生了变化，自发互动减少，精心策划的在线联系增加。 一些人建议，有意识的努力，例如定期、轻松的聚会，或者仅仅是无需严格安排地联系朋友，可能会有所帮助。 还有人指出，有了孩子后维持友谊的困难，因为 priorities 发生了变化。
一个反复出现的主题是共同经历和地理位置的重要性。 许多用户强调了当地社区和共同爱好的价值。 最终，讨论表明，重建社交联系需要有意识的努力，以及在现代生活的干扰中优先考虑现实世界互动的意愿。
## Litellm 包供应链漏洞 在 PyPI 上发现了 `litellm==1.82.8` 的一个严重安全漏洞。该包包含一个恶意 `.pth` 文件 (`litellm_init.pth`)，会在 Python 解释器启动时*自动*执行一个窃取凭据的脚本——无需导入语句。 该脚本会收集大量敏感信息，包括环境变量（可能暴露 API 密钥和密钥）、SSH 密钥、云提供商凭据（AWS、Azure、GCP、Kubernetes）、加密钱包、数据库凭据和 CI/CD 密钥。然后，它使用 AES-256 和硬编码的 RSA 公钥加密此数据，并将其泄露到 `https://models.litellm.cloud/`。 该漏洞利用了 Python 自动执行 `site-packages/` 中的 `.pth` 文件的功能。有效载荷使用双重 Base64 编码进行混淆。 **影响：** 安装 `litellm==1.82.8` 的系统面临完全凭据泄露的高风险。 **建议：** 已经请求从 PyPI 上删除该包。用户应立即检查 `site-packages/` 目录中是否存在 `litellm_init.pth` 文件，并**轮换所有可能在受影响系统上暴露的凭据**。
黑客新闻 新 | 过去 | 评论 | 提问 | 展示 | 招聘 | 提交 登录
litellm 1.82.8 PyPI 包中的恶意 litellm_init.pth – 凭据窃取器 (github.com/berriai)
733 分，theanonymousone 1 天前 | 隐藏 | 过去 | 收藏 | 1 条评论 帮助
dang 1 天前 | 下一个 [–]
评论已移动至 https://news.ycombinator.com/item?id=47501426，该帖子发布得更早。回复
指南 | 常见问题 | 列表 | API | 安全 | 法律 | 申请 YC | 联系
搜索：