返回首页

24小时热榜

3作者: luthiraabeykoon大约 4 小时前原帖
我之前在这里提到过Julie,这是我公开构建的一个开源桌面AI助手。开源版本是本地优先且功能强大,但它假设你能自带模型或API密钥。 很多人告诉我同样的事情:“我只想安装它并让它正常工作。” 因此,我创建了Julie Zero。 Julie Zero是一个即装即用的高级版本。无需API密钥,无需设置。安装后即可立即使用。 Julie Zero的功能包括: - 实时查看你的屏幕,理解你正在查看的内容 - 通过点击、输入、导航和自动化工作流程来帮助你在不同应用之间切换 - 利用屏幕上的上下文,而不仅仅是文本提示,因此响应实际上是相关的 - 快速且低延迟,因此在实际工作中感觉可用 - 以本地优先的理念构建,并针对日常工作流程进行了优化 开源版本仍然存在,并且将始终存在。Julie Zero只是为了消除那些不想进行任何配置的用户的障碍。 定价: Julie Zero的月费为9.99美元,这只是类似Cluely高级工具价格的一小部分。 赠品: 我将向10个人赠送3个月的无限制Julie Zero访问权限。 获取方式: 在我的GitHub上为开源Julie仓库点个星:<a href="https://github.com/Luthiraa/julie" rel="nofollow">https://github.com/Luthiraa/julie</a> (确保你的GitHub账号连接了社交媒体,以便我可以联系你!) 我会给你发送一个一次性代码,享受3个月的高级访问权限。 我正在非常积极地进行构建并快速迭代。希望能收到在实际工作流程中使用它的人的反馈。欢迎提出问题。
3作者: pugdogdev大约 6 小时前原帖
大约一年前,我在开发 DockFlow(一个用于管理 macOS Dock 预设的 macOS 应用)时,在 Reddit 上遇到了 ExtraDock。其原始创作者开发了一个很酷的工具:可以在你的 Mac 上创建多个浮动 Dock,并将它们放置在不同的显示器上。但这个应用维护起来很困难,开发者希望转向其他项目。 我非常喜欢这个概念,看到 ExtraDock 和 DockFlow 可以完美结合。DockFlow 管理你的 Dock 配置,而 ExtraDock 则为每个显示器提供多个 Dock。我联系了开发者,达成了协议,并从头开始重建了整个应用。 当我首次收购 ExtraDock 时,它有潜力,但需要大量的改进。原始创作者建立了核心概念——多个浮动 Dock,但用户界面很基础,性能不稳定,并且与其他工具没有真正的集成。在过去的十个月里,我对其进行了全面重建。 变化简直天差地别。我重写了所有内容,消除了崩溃,增加了可自定义的小部件(间隔器、分隔符、时钟、Finder 垃圾桶小部件、Tamadocky 等等),并与 DockFlow 无缝集成,使你的 Dock 根据工作流程预设自动出现或消失。 三个月前,我意识到自己在不同显示器之间切换的时间太多。我有一台 14 英寸的 MacBook,两个 27 英寸的显示器,每个显示器上都有完全不同的工作流程。左侧显示器用于设计,右侧用于开发,第三个显示器用于沟通和参考材料。 问题是,macOS Dock 只存在于一个地方。因此,我不断地在屏幕之间跳转,以访问特定工作区所需的应用。 重建后的 ExtraDock 解决了这个问题。 现在我有三个专用的 Dock: - 左侧显示器:Figma、Photoshop、颜色选择器、设计资源文件夹 - 右侧显示器:Cursor、Terminal、Chrome、GitHub Desktop、项目文件夹 - 中间显示器:电子邮件、Notion、日历、管理文件夹 当我将 DockFlow 的预设从“设计”切换到“开发”时,ExtraDock 会自动隐藏我的设计 Dock,并显示我的开发 Dock。每个显示器都变成了一个专注于我实际工作内容的工作区。不再需要在错误的屏幕上寻找应用。 我还构建了一个神奇的功能:ExtraDock 的实时 Dock 小部件。 这使得它与其他浮动 Dock 工具不同。你可以真实地复制你的原生 macOS Dock,并进行实时更新。可以将其放置在任何地方。在不同的显示器上、不同的位置、不同的大小。 使其有效的功能: - 在你的屏幕上任意位置放置无限的 Dock - 拖放应用、文件夹和文件到你的 Dock 中 - 完全可自定义:颜色、大小、布局、图标 - 自动隐藏或始终可见——由你选择 - 在全屏应用(电影、演示文稿)期间自动隐藏 - 实时 Dock 小部件可以在任何地方复制你的原生 Dock - 自定义小部件:间隔器、分隔符、时钟、Finder/垃圾桶访问 - DockFlow 集成:Dock 根据你的预设切换做出响应 - 即使运行多个 Dock 也没有延迟 - 完全离线运行,无需操作系统权限(实时 Dock 在可访问性方面可以更好,但这是可选的) - 所有内容都保留在本地——无云端,无遥测 ExtraDock 有什么不同? 其他 Dock 替代应用如 Dockey 或 HyperDock 尝试完全替代 Dock。如果你想要一个完全自定义的体验,这很好,但很多人喜欢原生 Dock。他们只是希望能在每个显示器上都能使用它。ExtraDock 让你可以做到这一点。你可以保留你的原生 Dock(或使用实时 Dock 小部件克隆它),并在需要的地方添加无限的浮动 Dock。 定价: - 每年 9.99 美元 - 终身许可证 31.99 美元(现在而不是 39.99 美元) 如果不适合你,提供 14 天退款保证。 我很乐意听取你的反馈,并邀请你加入超过 600 名 ExtraDock 用户 :) 查看链接: [https://extradock.app](https://extradock.app)
3作者: cadabrabra大约 14 小时前原帖
这只是一个人们喜欢的叙述,因为它听起来很美好。或者说,这可能是因为它让人工智能听起来不那么威胁,甚至显得更容易接受。“别担心,人工智能只会取代你工作中重复的部分。”但是,如果你花一点时间去审视这个叙述,你会意识到它是多么荒谬。 人类已经找到了自动化重复的物理和数字劳动的方法,我们已经用机器和计算技术做了几十年甚至几个世纪。简单来说:如果是重复的工作,那么你根本不需要人工智能来自动化它。 事实上,我们希望人工智能自动化的任务恰恰是那些不重复的任务。这正是人工智能的初衷。 我们是如何从人工智能的最初目的转变为声称它将做我们已经做了几十年的事情的?这些叙述来自哪里,为什么人们会相信它们?
2作者: anon_anon12大约 1 小时前原帖
OpenClaw 看起来只是另一种在非人工智能中心平台上与 AI 聊天的方式,而不是通过命令行界面或公司的官网。为了真正使用它,你需要提供很多 API 密钥,这让我对它能够实现完全自主的印象大打折扣。是的,我明白这只是一次性的事情,但现在所有这些平台都有自己的 AI,为什么我还要经历这样的麻烦呢?而且有些 API 密钥还会过期或有某些限制。总的来说,这又是一个功能,而不是一个产品。
2作者: ghostinit大约 1 小时前原帖
2023年初,一家小型金融科技初创公司。截止日期:4个月内上线。工程团队只有3个人。我担任架构师,还有两名开发人员。我们已经准备好了。架构设计完成,基础设施在云端运行,后端框架也搭建好了。 开发人员正在构建功能。我们进展顺利。然后到了第二个月,管理层开始招聘。很多经理出现了。接着,他们引入了一位Scrum Master。这个家伙在第一周就想要实施完整的敏捷仪式。 每日站会、冲刺规划、回顾会议、待办事项梳理,所有的流程都来了。他的理由是:“你需要流程来扩展。”而我们只剩下8周的时间。 我们并不是在尝试扩展。我们只是想完成项目。我已经看到这种模式多次上演。小团队在交付,管理层对缺乏可见性感到不安,于是他们招聘流程专家。流程专家需要证明自己的存在,仪式被实施,一切都变得缓慢。 让我感到痛心的是时机。我们正在工作。为什么在距离截止日期只有8周的时候要修复那些并没有坏掉的东西?我真心好奇,为什么管理层不能就让工作团队独立运作?这是真正对可持续性的担忧,还是仅仅对缺乏控制机制的不安? 你对此有什么经验?
2作者: MarcelOlsz大约 3 小时前原帖
我使用苹果键盘的打字速度是每分钟160个单词。这绝对是我最喜欢的键盘,但我希望能有一个带有巧克力键和内置鼠标的人体工学键盘。我曾考虑过cybord imprint和kinesis advantage 360,但尽管kinesis的评价非常好,但它没有鼠标,而且对我来说价格太贵,虽然它是无线的,imprint也是如此。我的目标是将它用扎带固定在我的Herman Miller Aeron椅子的扶手上,这样我就不必移动手臂,可以轻松转身查看其他显示器,而不需要扭动脖子。有没有现成的解决方案可以订购,不需要焊接和组装?似乎选择不多。
2作者: cigol大约 4 小时前原帖
嗨,HN!我分析了2006年至2026年间的4000万条评论,并使用人工智能将它们整理成大约1万个主题。<p>你可以探索: - 随时间变化的上升/下降趋势 - 各个主题的示例评论及原帖链接 - 深度报告(比特币、英伟达、自动驾驶等)<p>大约花了一周时间完成。欢迎反馈!
2作者: m-hodges大约 5 小时前原帖
今天,使用代理进行秘密管理似乎缺乏有效性。代理需要 API 密钥来调用外部服务,但在这种情况下,常见的模式似乎失效了。在编写代理技能时,这一点尤为明显。 环境变量:代理具有 shell 访问权限。它可以运行 `env` 或 `echo $API_KEY` 来访问秘密,无论是通过提示注入,还是通过探索或调试。 .env 文件:同样的问题。代理可以执行 `cat .env`。该文件就在文件系统上,等待好奇的 `print()` 语句去读取。 代理进程/包装器:您可以启动一个单独的进程来保存秘密并代理请求。代理调用本地地址,从未看到密钥。这种方法有效,但带来了很大的操作开销。现在您需要运行基础设施,仅仅是为了将一个字符串隐藏在自己的工具之外。这也感觉像是在重新发明 MCP。 我一直在尝试的方案: 1. 使用凭据助手的操作系统钥匙串:捆绑或生成的脚本在运行时调用系统钥匙串(macOS 钥匙串、Windows 凭据管理器等)。代理可以调用该脚本,但无法直接查询钥匙串。像 Python 的 `keyring` 这样的库对操作系统钥匙串进行了抽象,使其在一定程度上可移植,但这都假设了特定的运行时环境,并需要用户通过操作系统进行交互。 2. 凭据命令逃生口:脚本接受 `--credential-cmd` 标志,运行任意 shell 命令以获取秘密(如 `pass show`、`op read`、`vault kv get` 等)。这种方法灵活,但代理可能会检查正在运行的命令并尝试访问它。 这两种方法都不算是真正的解决方案。代理可能会探测凭据。 其他人在代理工作流中是如何处理秘密的?是否有人在构建具有适当秘密隔离的代理运行时?这似乎是官方代理工具需要解决并交付的内容。