最新

嘿，我是龚超，目前在Zai工作。<p>上个周末，我踢完足球回家的路上，突然有了一个想法。我产生了构建它的冲动，整个周末都在忙着开发——*AgentShield*。<p>如今，每个人都在使用Cowork、Claude Code或各种AI代理来处理文件和编写代码。这很棒，但有时AI会“失控”，搞乱你的文件，让你无法恢复到原来的状态（别问我怎么知道的……）。<p>对于代码，你可以使用Git，但这需要提交，并且对大文件不太友好。<p>AgentShield在你的工作空间周围设置了一个保护屏，实时监控文件的变化。当事情搞砸时，你可以*一键回滚*，给你一个*“后悔药”*。<p>在底层，它使用零拷贝技术，占用空间极小。这个工具是献给所有被AI搞得一团糟的兄弟们。欢迎来试试！<p><a href="https://github.com/tomsun28/agentshield" rel="nofollow">https://github.com/tomsun28/agentshield</a><p>PS：我只在macOS上测试过。

随着我越来越多地追求有组织的自主编码，我需要一种安全的方法在我的Mac上以YOLO模式运行Claude Code。 我查看了很多选项，包括Docker，但后来发现了Lima（Linux for Mac）以及Chris Hager撰写的这篇关于如何使用Lima为你的Mac创建开发沙箱的优秀指南。这个过程创建了一个Ubuntu虚拟机，映射到你的开发目录，并提供读写访问、端口和SSH转发、对语言安装的Mise支持以及自动代码代理安装。 我按照他的指南进行了操作，成功在自己的设备上运行，然后想尝试将其打包成一个Claude技能进行分享。结果，真的很好用！ 要设置，只需在Claude Code中前往 /plugin -> marketplace 并添加 recodelabs/lima-devbox 然后安装该技能，并请求Claude为你创建一个虚拟机。Claude会问你一些问题，然后开始为你构建虚拟机。 附注 - 这让我深刻体会到，代理技能确实是你所需的一切。与其编写指南或将其封装成应用程序/TUI，不如将你想要自动化和分享的任何知识或流程直接融入到一个技能中。这绝对感觉像是未来。 如果你有改进的想法，非常欢迎你的反馈和PR。 谢谢！Matt

为了更好地说明背景，这个项目最初并不是作为一个大型独立发布来规划的。1月16日，Ollama 增加了对与 Anthropic 兼容的 API 的支持，我很好奇在实际操作中能推向多远。因此，我决定尝试将本地的 Ollama 模型直接接入 Claude Code 风格的工作流程，看看是否能真正实现端到端的功能。 以下是使这一切成为可能的 Ollama 发布说明：<a href="https://ollama.com/blog/claude">https://ollama.com/blog/claude</a> 从技术上讲，我所做的事情相对简单： - 检测 Ollama 中可用的本地模型。 - 当无法访问互联网时，客户端会自动切换到基于 Ollama 的本地模型，而不是远程模型。 - 从用户的角度来看，这与 Claude Code 的工作流程是一样的，只是由本地推理支持。 实际上，到目前为止，表现最佳的模型是 qwen3-coder:30b。我还测试了最近发布的 glm-4.7-flash，但它在可靠地遵循工具调用指令方面存在困难，因此尚不适用于这个工作流程。

基本上就是这个标题。背景是：我需要更换手机，同时也想借此机会思考一下我在手机操作系统中重视的方面（隐私和控制）与我在便利性方面的需求（应用程序可用性、无缝连接等）。<p>我正在收集意见，除了在这里问还有哪里合适呢？<p>你对移动操作系统的选择有什么经验或看法？你会推荐使用非主流操作系统版本的品牌吗（例如Fairphone）？

Three.js 最近推出了 TSL（Three.js 着色语言），这是一种用纯 JavaScript/TypeScript 编写着色器的方法，可以编译为 GLSL 和 WGSL。我构建了这个编辑器，以提供一个可视化界面，供 TSL 生态系统使用。它允许开发者为 WebGPU/WebGL 原型设计着色器，并实时查看结果。这是一个测试版发布，我希望能收到反馈。

嗨，HN！我们是来自星座空间的Kamran、Raaid、Laith和Omeed。我们构建了一个人工智能系统，可以在卫星链路故障发生之前预测其故障（<a href="https://youtu.be/069V9fADAtM" rel="nofollow">https://youtu.be/069V9fADAtM</a>）。 我们四人都在SpaceX、蓝色起源和NASA从事卫星操作工作多年。在SpaceX，我们负责Starlink的星座健康管理；在蓝色起源，我们参与了New Glenn的下一代测试基础设施的开发；在NASA，我们处理深空通信。我们发现同一个问题不断出现：当你注意到链路正在恶化时，往往已经丢失了数据。 核心问题在于卫星射频链路受到数十个相互作用变量的影响。一颗卫星从上方经过时，你需要预测链路在接下来的几分钟内是否会保持稳定。这取决于：轨道几何（仰角不断变化）、对流层衰减（湿度通过ITU-R P.676影响信号损失）、雨衰（通过ITU-R P.618计算，毫米/小时的降雨率直接转化为Ka波段及以上的分贝损失）、电离层闪烁（我们跟踪来自磁力仪网络的KP指数），以及网络拥堵等因素。 传统的方法是反应式的。操作员监控仪表板，当信噪比（SNR）降到阈值以下时，他们会手动重新路由流量或切换到备用链路。如今，轨道上有10,000颗卫星，预计到2030年将超过70,000颗，这种方法无法扩展。 我们的系统每秒接收大约100,000条来自卫星、地面站、气象雷达、物联网湿度传感器和空间天气监测器的遥测数据。我们实时运行基于物理的模型——完整的链路预算方程、ITU大气标准、轨道传播——来计算应该发生的情况。然后，我们在其上叠加机器学习模型，这些模型基于来自实际多轨道操作的数十亿数据点进行训练。 机器学习部分是最有趣的。我们使用联邦学习，因为星座运营商（可以理解）不想共享原始遥测数据。每个星座在自己的数据上训练本地模型，我们只聚合高层次的模式。这使我们能够在不同轨道类型和频段之间进行迁移学习——低轨道Ka波段链路的学习经验有助于优化中轨道或地球静止轨道的操作。 我们可以在3到5分钟内以超过90%的准确率预测大多数链路故障，这为在数据丢失之前重新路由流量提供了足够的时间。该系统完全容器化（Docker/Kubernetes），可以在隔离环境中本地部署，也可以在GovCloud（AWS GovCloud，Azure政府云）或标准商业云上运行。 目前，我们正在与国防和商业合作伙伴进行测试。仪表板显示实时链路健康状况，60/180/300秒的预测，以及根本原因分析（这是雨衰吗？卫星是否在地平线以下？拥堵吗？）。我们通过API公开所有功能——遥测接收、预测、拓扑快照，甚至提供一个大型语言模型聊天接口用于自然语言故障排除。 我们仍在努力解决的难点包括：预测准确性在较长时间范围内（超过5分钟）会下降，我们需要更多稀有边缘案例的标记故障数据，而联邦学习的设置需要在不同运营商的安全边界之间进行仔细协调。 我们非常希望听到任何在卫星操作、射频链路建模或大规模时间序列预测方面有经验的人的反馈。我们还缺少什么？在生产网络运营中心环境中，什么能让这个系统真正有用？ 欢迎提出任何技术问题！