一周热榜

由于对本地标记和描述图像工具明显缺乏感到沮丧，我快速制作了一个简单的小工具。你只需启动它，然后启动 llama-server，并指向一个照片目录。它会逐一扫描这些照片，为每张照片添加说明，并在一个可编辑的界面中提供这些说明和标签。当你对它们满意时，可以保存，这样就会将这些信息写入图像的 EXIF 元数据中，然后继续处理下一张照片。

我是Netrinos的创始人。我构建了一个基于WireGuard的网状VPN，因为远程访问一直是个麻烦。经过多年的SSH隧道、IPsec的头痛和SSH日志的恐怖经历，我想要一个更简单的解决方案：安装、登录、完成工作。 Netrinos在您的设备之间创建了一个类似局域网的覆盖网络。连接是通过WireGuard进行的直接点对点连接，没有中央服务器来路由流量。每个设备都有一个稳定的IP和DNS名称（pc.you.netrinos.com）。当直接连接失败时，它们会回退到一个仍然是端到端加密的中继服务器。我们无法看到您的流量。 最具挑战性的问题是NAT穿越。UDP打孔大多数情况下有效。其余的则是对称NAT、CGNAT和串行NAT的组合。我们使用STUN风格的发现和中继回退来处理边缘情况。我对低端ISP路由器的不可靠性感到惊讶，以及为了在干净、简单的用户体验背后隐藏这些问题所需的技术魔法。 我们的技术栈包括用于客户端和服务器的Go后端，Linux和Windows的WireGuard内核模式（macOS为用户空间），以及用于跨平台用户界面的Wails.io。WireGuard承担了所有的重任，而Go将这一切连接在一起。 常见的使用案例包括：远程桌面连接到家用PC、在不暴露的情况下访问NAS，以及SSH连接到无头Linux设备。一位客户在现场管理数百个物联网设备，消除了处理客户路由器的需要。 我们刚刚发布了Pro版本，支持多用户、访问控制和远程网关路由。个人版是免费的（最多支持100个设备）。 我很想听听您对简单网状VPN的期望，当前工具中缺少什么，以及您的远程访问设置中缺少什么。使用代码HNPRO26可以享受30天的Pro版本试用。 <a href="https://netrinos.com" rel="nofollow">https://netrinos.com</a>

我一直在开发一个小工具，旨在减少在氛围编码工作流程中的提示摩擦。 实际上，很多迭代源于不够明确的提示：缺少约束、不清晰的范围、隐含的假设或混合的意图。这个工具将您想要构建的内容的粗略自然语言描述，重写为更明确、结构化的提示，提供更清晰的要求和背景，然后再发送给模型。 重点在于： - 使意图、约束和假设变得明确 - 减少提示的变动和微迭代 - 提高首次输出的质量，尤其是针对非技术构建者 它主要围绕氛围编码的用例（快速原型制作、AI辅助构建）设计，最适合与Lovable/Claude风格的工作流程配合使用，尽管在概念上它是模型无关的。 非常希望能得到技术反馈： - 提示规范化/重构是您认为有价值的内容吗？ - 您是通过系统提示、微调还是运行时提示转换来解决这个问题的？ - 在更复杂或长上下文的任务中，这个工具的效果如何？ 欢迎分享批评意见。

我们正在构建万亿参数的模型，并通过字符串连接将上下文嵌入其中。 我一直对“上下文工程”这个词感到困惑，因为它到处都是，但没有人明确说明它到底意味着什么。框架定义了工具循环，但却没有定义注入点。 这是一个关于上下文工程基础设施应如何构建的提议： - 可渲染的上下文组件（工具在用户界面和模型中的不同服务方式） - 可查询的对话（带有物化视图的事件流） - 响应式注入（基于对话状态触发的规则） - 注入队列（优先级、批处理、去重） - 可钩挂的架构 博客文章： [https://michaellivs.com/blog/context-engineering-open-call](https://michaellivs.com/blog/context-engineering-open-call) 代码库（早期设计阶段，寻找合作者）： [https://github.com/Michaelliv/context-engine](https://github.com/Michaelliv/context-engine) 希望能对这个方向获得反馈，特别是：规则应该如何表达 - 是领域特定语言（DSL）还是代码？现有框架的正确集成面是什么？

来自官方Zig源的包管理器，即“zig fetch”，让我感到非常烦恼。我讨厌必须先从一个URL获取项目，然后将代码复制到build.zig中，接着又没有智能提示，只能猜测我需要写什么，不需要写什么。这真是一团糟。 所以我解决了这个问题，构建了自己的包管理器zeP。 https://github.com/XerWoho/zeP 这是一个简单的包管理器和Zig版本管理器。 那么我学到了什么呢？首先，构建一个包管理器需要进行大量的规划。目前我仍处于预发布阶段，这里会有很多重大变化，但我已经做出的许多重大改动让我意识到，在承诺某件事情之前，我必须先停止编程，开始思考。 例如，我的可执行文件命名为zeP，这对Linux用户来说是个问题。他们总是必须输入带有大写P的zeP，这实在令人烦恼。 在此之前，我在zeP中有一个Zig版本管理器，在安装Zig版本或切换版本后，会更改可执行文件的路径。也就是说，每次安装或切换时都会添加一个新路径。 ~/.zig-0.15.1/x86-windows/:~/.zig-0.13.0/x86-windows:~/.zig-.... 可以想象，经过一段时间后，PATH变量会变得多么臃肿，而且不仅如此，这完全没有用，因为我会检查路径是否在PATH变量中，如果在，我就不会再添加它。也就是说（以上面的例子为例），zig 0.13.0将永远不会再被使用，因为它被0.15.1所覆盖。为了解决这个问题，我使用了符号链接。只在主路径~/.local/bin内，zig会在安装和切换之间进行符号链接。 符号链接对我来说非常好，因为我发现了pnpm的工作原理。pnpm使用符号链接，减少了安装、延迟和文件大小，因为有一个主文件夹包含所有文件，并且这些文件在项目之间进行链接。但是，有一个问题。如果你卸载一个包，它会删除主文件夹中的包，这意味着所有可能安装了该包的其他项目将会有一个悬空的符号链接。 再次，解决方案很简单。一个manifest.json。在这里，我们存储所有包及其链接的项目。这个文件会检查链接的项目，如果该包没有链接的项目，才会删除该包；否则，它只会解除项目的链接。 不用说，我遇到了许多需要测试的问题，并且亲自使用zeP。只有通过使用我自己的产品，我才能确定其他人可能遇到的问题。但有些人也提供了反馈，之后我修复了一些问题。 zeP有自己定制的打印结构。它接收数据，然后通过清空整个屏幕再重新打印。这是为了让我可以显示进度条等内容。然而，有用户讨厌zeP会完全占用整个屏幕。因此，现在zeP只会清除自己的行，而不会影响其他内容。 构建一个包管理器不仅需要我这边的测试，还需要社区的反馈。