最新

最近，Anthropic 发布了一些工具，可以让你操控 Windows 和 Mac OS。但我不用 Windows 或 MacOS，并且对 Wayland 的一些内部机制很感兴趣，想知道是否有可能在一个相对受限的平台（如 Wayland）上构建一些可用的东西。所以我做了 Tine。 Tine 是一个 GNOME 扩展和 CLI，它允许一个代理（我用的是 Claude，但理论上任何可以访问 CLI 的代理都可以）使用 SPI 树（AT-SPI2）、OCR 和视觉备选方案来操控桌面。代理可以使用辅助功能（AT-SPI2）树进行操作，截屏，放大网格，点击，使用 uinput 设备输入文本，并且通常可以在 Wayland Linux 桌面上进行各种操作。 这个项目在 x11 上可能会容易得多，但 Wayland 才是未来！！！111 感谢大家的想法和反馈，潜水十年后在这里发布一些东西感觉真好。十年多了，但谁在乎呢 / 我不老。

去年年底，我开始着手处理一些与依赖相关的技术债务问题，并为在中等规模的 monorepo 中运行 pnpm 的自省命令（如 'pnpm why'）所需的时间过长而苦恼。因此，我开始着手开发一个简单的静态网站生成器，它能让我一次性查看这些耗时命令的输出结果，从而清晰地展现问题，而无需逐一深入探究。<p>一旦这个功能实现，我意识到我有了足够的数据来添加工单跟踪功能。它利用从包管理器收集的数据来更新 Linear 或 GitHub 上的 issue。通过将这些 issue 自动分配给编码代理，我获得了比 Dependabot 更好的体验：代理不仅会更新版本，还会跟进 API 更新，并自动将相关的更新分组。<p>虽然还处于早期阶段，但它对我们来说效果很好，我认为大家也会从中受益，所以在这里分享出来！

我正在创建 Veevo Health (veevohealth.com)，这是一家初创公司，提供预防性 CT 血管造影心脏扫描，帮助人们清晰了解并增强对自身心脏健康的信心。之前我做了一个简短的介绍；现在我想分三部分分享一篇更长的文章：1）我们为什么要做这件事，2）我们的进展，以及 3）我们遇到的困难。我很乐意听取社区对我们所面临挑战的反馈。<p>首先，为什么：我开始做这件事是因为我的父亲英年早逝，死于突发性心脏病。我也面临着更高的风险（胆固醇偏高、家族病史和南亚基因）。我希望找到一种方法，让我对自己的长期心脏健康充满信心，同时也帮助其他人免受心脏病的困扰。<p>我最初考虑的是血液检查，但我发现一半的心脏病发作患者的血液检查结果是正常的。所以我决定解决问题的根源：我们心脏动脉中的斑块堆积，这种堆积可能在几十年里缓慢而无声地发展，通常没有任何症状。<p>这促使我开始研究 CT 血管造影心脏扫描，因为这是唯一一种非侵入性的方法，可以让我们清晰地了解人们的心脏动脉。它的主要优势在于它可以捕捉到软斑块，而软斑块占总斑块的 80%，也是更危险的一种。<p>其次，我们的进展：我们推出了早期访问网站，并在几个地方进行了宣传。我们对收到的关注和注册量感到惊讶，而且这个数字还在不断增长。看到我们的信念和产品与人们产生共鸣，这非常令人鼓舞。<p>第三，挑战。主要有两个： * 医疗保健合规性非常严苛。每个合作伙伴和每个州都需要大量的文书工作。这非常耗时且消耗资源。 * 社交媒体营销很难。我们需要在社交媒体（如 Instagram）上不断发布内容，并进行合作，以接触更广泛的受众。我们仍在摸索如何做到这一点。<p>幸运的是，我们的定价得到了人们的认可。目前，自费 CT 血管造影的费用通常为 2,000 至 3,000 美元，而且在获得转诊方面存在很多障碍。我们能够在大多数地方以大约 800 美元的价格提供转诊、扫描和随访服务，我们的客户对此很满意。<p>我们希望得到您的反馈，特别是如果您处理过医疗保健合规性或面向消费者的医疗保健营销。<p>谢谢， Arvind

我构建了 cush，因为编码代理可以帮助诊断和排除服务器问题。<p>问题在于，将这些代理部署到远程服务器上，尤其是在你无法控制的服务器上，意味着要处理 VPN、堡垒主机、防火墙规则、访问控制或审计跟踪。这还不算 SSH 没被阻止的情况。<p>cush 采用了不同的方法。它不使用 shell，而是打开一个临时的、出站的 HTTPS 隧道，允许你和你的 AI 代理在服务器上运行受限的 CLI 命令：<p><pre><code> $ cush open --allow grep,cat,tail --expiry 2h 隧道： https://abc123.ngrok.io 令牌： a3f9c2d1... 允许： grep, cat, tail 过期： 2 小时后 </code></pre> 现在，任何代理或 HTTP 客户端都可以执行允许的命令：<p><pre><code> $ curl -X POST https://abc123.ngrok.io \ -H &quot;Authorization: Bearer a3f9c2d1...&quot; \ -H &quot;Content-Type: application/json&quot; \ -d &#x27;{&quot;command&quot;: [&quot;grep&quot;, &quot;-r&quot;, &quot;ERROR&quot;, &quot;/var/log/app.log&quot;]}&#x27; &gt;&gt;&gt; {&quot;stdout&quot;:&quot;ERROR database connection refused\n&quot;,&quot;stderr&quot;:&quot;&quot;,&quot;exit_code&quot;:0} </code></pre> 将任何代理指向隧道的 URL：<p><pre><code> $ claude &quot;使用 https://abc123.ngrok.io 和令牌 a3f9c2d1... 来查找导致 500 错误的根源&quot; </code></pre> 隧道经过身份验证、受限且生命周期短。无需服务器端基础设施更改。只需一个 7MB 的 Rust 二进制文件 + ngrok。<p>正在寻求反馈，并寻找 2-3 个设计合作伙伴来构建审计跟踪。

嘿，HN！我最初开发 SyncMD 是为了能够将我的 Git 仓库同步到我的 iPhone 上，并将它们用作 Obsidian 库。2.0 版本已经发展得更加完善——它现在是一个完整的 Git 客户端，带有应用内文件编辑器。 它的功能包括： * 直接从 GitHub 克隆仓库到 iPhone 的文件系统 * 在应用内浏览、创建、编辑、重命名和删除文件 * 代码文件语法高亮显示 * git add、commit、push、pull - 都在应用内完成 * 与 Obsidian（或任何从“文件”中读取的应用程序）原生兼容 * 差异视图、储藏、标签、还原支持 Obsidian 用例仍然是主要目标——将你的笔记仓库克隆到手机上，在 Obsidian 中编辑，然后将更改推送回去。但用户一直要求提供编辑功能，于是它就越做越大了。 单个仓库免费使用。无限制仓库是一次性购买。 该应用是开源的：[https://github.com/CodyBontecou/Sync.md](https://github.com/CodyBontecou/Sync.md) 很乐意回答关于实现或 App Store 发布的任何问题。 如果你发现了错误，应用内有反馈按钮。 App Store 链接：[https://apps.apple.com/us/app/sync-md/id6758960270](https://apps.apple.com/us/app/sync-md/id6758960270) 我制作了一个简短的演示，如果你更喜欢观看而不是阅读：[https://www.youtube.com/watch?v=XdHVOlgodEw](https://www.youtube.com/watch?v=XdHVOlgodEw)

Libretto (<a href="https://libretto.sh" rel="nofollow">https://libretto.sh</a>) 是一款 Skill+CLI 工具，它能让你的编码助手轻松生成确定性的浏览器自动化操作，并调试现有的自动化流程。关键的转变是从“在运行时给助手一个提示，然后希望它能搞定一切”到：“使用编码助手生成你可以检查、运行和调试的真实脚本”。 这里有一个演示：<a href="https://www.youtube.com/watch?v=0cDpIntmHAM" rel="nofollow">https://www.youtube.com/watch?v=0cDpIntmHAM</a>。文档从这里开始：<a href="https://libretto.sh/docs/get-started/introduction" rel="nofollow">https://libretto.sh/docs/get-started/introduction</a>。 我们在医疗保健初创公司花了一年时间构建和维护用于 EHR 和支付方门户集成的浏览器自动化。构建这些自动化流程和调试失败的流程非常耗时。 有很多工具使用运行时 AI，比如 Browseruse 和 Stagehand，我们都试过，但 (1) 它们依赖于自定义 DOM 解析，这在旧的和复杂的网站（包括所有医疗保健网站）上是不可靠的。在可能的情况下，使用网站的内部网络调用更快、更可靠。(2) 它们可能很昂贵，因为它们依赖于大量的 AI 调用，对于具有复杂逻辑的工作流程，你不能总是依赖于缓存操作来确保它能正常工作。(3) 它们在运行时运行，所以无法解释助手将要做什么。你只能希望你正确地提示它去做正确的事情，但旧的工作流程通常在不同网站上是不直观和不一致的，所以你不能相信助手在运行时就能搞定。(4) 它们实际上并不能帮助你生成新的自动化流程，也不能帮助你调试自动化失败。 我们希望有一种方法能够在混乱、高风险的环境中可靠地生成和维护浏览器自动化，而无需依赖脆弱的运行时助手。 Libretto 的不同之处在于，它使用“开发时 AI”而不是运行时助手：脚本是提前生成的，作为你可以阅读和控制的实际代码，而不是运行时不透明的助手行为。你拥有代码，可以检查、修改、版本控制和调试所有内容，而不是一个黑盒子。 Libretto 采用混合方法，结合 Playwright UI 自动化和浏览器会话中的直接网络/API 请求，而不是依赖于运行时 DOM 解析，以提高可靠性和规避机器人检测。 它记录手动用户操作以帮助助手生成和更新脚本，支持单步调试，具有可选的只读模式以防止助手意外提交或修改数据，并生成遵循你编码仓库中所有抽象和约定的代码。 很想听听其他人是如何在实践中构建和维护浏览器自动化的，以及对我们在这里采用的方法的任何反馈。