最新

这是我最近一直在思考的一个模型。它展示了一种我猜想可能存在的模式：使用 Web 技术创建终端应用程序、BBS 式共享用户版块以及其他创意和分享形式，但将其渲染到终端并通过 SSH 访问。 我喜欢这种方式，它带回了一些早期互联网的感觉，并且利用了 Web 技术，但避开了公共的万维网，尽管它仍然在互联网上。 你现在就可以尝试一下，我正考虑将自托管的专业应用程序部分作为一项核心功能。但目前，该项目被组织为一个浏览器渲染引擎，我为此投入了八年时间，从 2018 年底开始，大部分时间没有使用 AI，所有代码都是我自己编写的。然后是一个终端渲染器，它连接到浏览器渲染器，获取其输出和记账信息，并将其渲染到终端。 这个终端渲染器是我设计的，包括布局算法，但几乎所有的代码都是 AI 编写的。所以，在那方面，我基本上是一个软件设计师和 AI 引导者。我的工作流程基本上是一次只使用一个代理，我会监控它，根据我的直觉在它遇到困难或需要帮助时进行引导，并朝着目标前进。再加上我作为设计师和决策者的角色。 AI 会做出很多决定，但大部分决定是我做的。所以，这只是描述了我创造这个终端应用的过程，它大约有一年历史了。 最初，它是使用 Gemini Pro 3.1 创建的，当时（一年前）它可能是处理复杂任务最强大的模型。我当时是在免费的 AI Studio 网页应用程序上完成的，就像粘贴代码列表一样。显然，有了现在的代理，整个工作流程都顺畅多了。 这个演示有一个某种程度的限制，所以如果它达到了限制，请告诉我。它可能不会，但请随时告诉我。你今天就可以自托管它。如果你想这样做，请告诉我。 这段文字是我口述的，然后添加了标点和段落，但措辞没有改变。

各位 HN 的朋友们！ 在我们 Kenobi[0] 的工作中，我曾利用 Codex 分析一个 HTTP 存档（HAR）文件，以评估一个网站是否可以被程序化地使用，即通过暴露其底层/未公开的 API。这种方法比我预期的效果要好得多，于是我开始寻找一种简单的方法来为其他网站实现这一点。 我没有找到完全符合我需求的产品，于是我们决定开发 Harpist——一个包含两部分的产品：i. 一个 Chrome 扩展，允许你录制 HAR 文件并查看生成的文档；ii. 一个 CLI 工具，可供代理（agents）用于精炼这些 HAR 文件，创建 oRPC 合

从成千上万行人工智能编写的代码，到一些可能导致大量已深度定制的安装崩溃的系统特定操作，或者是我多虑了？

我创建了一款应用程序，可以比较 Uber、Lyft、Waymo、Tesla Robotaxi、Curb 和 Empower 的实时价格和等待时间。它会在一个列表中显示所有乘车选项，当您准备好预订时，它会直接跳转到提供商的应用程序，并预先填好路线。 我通过逆向工程打车手机应用程序，了解它们如何从服务器获取价格。您可以使用您的打车账户登录我的应用程序，然后我的应用程序会向打车应用程序使用的相同 API 请求实时价格。重要的是，我的应用程序采用设备端方法构建：您手机上的应用程序会在本地存储身份验证令牌，并直接向每个打车公司的服务器发送网络请求。这可以保护您的账户隐私。我写了一篇博客文章，展示了我的应用程序发送的网络请求，您可以自行验证：https://blog.hackney.app/p/how-hackney-works 这似乎是一个显而易见的应用程序。为什么它之前不存在？这是因为大多数打车公司不提供公开的价格和等待时间 API。Uber 确实提供了一个，但他们禁止将其用于价格比较。当有人使用官方 API 构建了一个比较应用程序时，Uber 终止了他们的 API 访问：https://www.benedelman.org/news-053116。现在有一些不使用官方 API 的应用程序，但它们会将您的账户令牌通过其服务器运行，并在服务器端发送价格请求。 为了集成打车提供商，我的应用程序会发送用于登录、令牌刷新、乘车价格和乘车历史的网络请求（用于支持一个功能，该功能可以显示您跨应用程序的统一乘车历史以及您在每次乘车中节省了多少钱）。一些打车应用程序会实施证书锁定，以阻止您查看其网络请求，还有一些应用程序使用 Protobuf（一种不包含原始字段名称的数据格式）与服务器通信。使用这种方法构建应用程序在技术上很复杂，但它使得各种原本无法存在的有用产品成为可能。 该应用程序完全免费。未来，我可能会通过订阅或与打车公司合作来实现盈利。我很乐意听取您的反馈。您今天就可以下载它。 iOS：https://apps.apple.com/us/app/hackney-compare-rideshares/id6754620049 Android：https://play.google.com/store/apps/details?id=app.hackney

我最近试用了 npm 的新分阶段发布机制。这是一种糟糕的开发者体验。（https://docs.npmjs.com/staged-publishing） 我总体上支持这个概念（出于安全目的），但批准分阶段发布的开发者必须为每个单独的分阶段包单独输入他们的通行密钥，即使它们都是同时分阶段和批准的。任何发布包含多个包的单体仓库的人都会抓狂（我已经快疯了）。 为了避免自己抓狂，我不得不回退到非分阶段发布。