最新

我创建了psmux，以便在Windows Powershell中实现类似tmux的工作流程，而无需依赖WSL、Cygwin或MSYS2。<p>它是用Rust编写的，能够与PowerShell集成，读取现有的.tmux.conf文件，并支持分屏、会话、鼠标模式和常见的tmux快捷键。<p>我非常希望能收到依赖终端工作流程的Windows开发者的反馈。

专门用于构建和协调自主AI代理团队的框架。包括GitHub问题路由、多代理Discord协调、开发管道编排以及完整的文档。<p>可下载指南：<a href="https:&#x2F;&#x2F;caffaro.gumroad.com&#x2F;l&#x2F;beqtp" rel="nofollow">https:&#x2F;&#x2F;caffaro.gumroad.com&#x2F;l&#x2F;beqtp</a>（随意付费，建议$5）

我们在过去几个月里一直在构建一个小型的设计和导航规划工具（<a href="https:&#x2F;&#x2F;no-edit.lovable.app" rel="nofollow">https:&#x2F;&#x2F;no-edit.lovable.app</a>），在测试过程中，我们手动分析了312个着陆页，涵盖了SaaS、独立项目和AI工具。最初的目标很简单：在设计用户界面之前，了解人们如何构建导航。我们发现的结果让我们感到惊讶。 1. 68%的页面主导航不清晰 - 要么是：过多的项目（7个以上的顶级链接） - 要么是模糊的标签，如“解决方案”、“平台”、“探索” - 用户在点击之前需要思考。 2. 大多数CTA（行动号召）相互竞争 - 在54%的情况下： - 2到3个主要按钮具有相同的视觉权重。 - 没有明显的行动层次。 - 设计看起来干净，但决策过程却不清晰。 3. 移动导航往往被忽视 - 很多响应式菜单在技术上“有效”，但： - 重要链接被埋没 - CTA的可见性显著下降。 4. 信息层次 ≠ 视觉层次 - 有几个页面看起来很精致（颜色、间距、排版都很好），但： - 导航结构没有反映用户旅程。 - 各部分的顺序是为了讲故事，而不是为了可用性。 有趣的是： 当我们将一些流程重新构建成简单的站点地图风格的图表时，清晰度立即得到了提升——甚至在触及用户界面之前。这让我思考，大多数工具在设计层面（字体、模板、组件）上投入了大量精力，但在早期阶段却忽视了结构化的导航思考。 我很好奇： 你是在视觉设计之前规划导航吗？ 还是先进行设计，然后再调整结构？ 希望能得到那些在大规模构建和测试着陆页的人士的反馈。

我之所以构建这个工具，是因为提示信息总是出现在最糟糕的地方——Python 字符串、Notion 文档、`.txt` 文件、Slack 线程中。没有一种干净的方式来对它们进行版本控制、差异比较，或者在不同模型之间测试相同的提示，而不需要编写一个一次性的脚本。 `prompt-run` 将 `.prompt` 文件视为一等公民的可运行工件。一个 `.prompt` 文件包含一个 YAML 头部（模型、提供者、温度、变量声明），后面跟着一个带有 `{{variable}}` 替换的纯文本主体。你可以从终端运行它： ``` prompt run summarize.prompt --var text="$(cat article.txt)" ``` 你可以在运行时覆盖模型和提供者，而无需编辑文件： ``` prompt run summarize.prompt --model gpt-4o --provider openai ``` `prompt diff` 命令可以对两个不同的输入（或两个提示版本针对相同输入）运行相同的提示，并并排显示输出。这是我在迭代时觉得最有用的功能。 该工具开箱即用支持 Anthropic、OpenAI 和 Ollama。采用 MIT 许可证。没有遥测、没有账户、没有后端——仅仅是一个本地 CLI 工具，直接与您配置的提供者进行交互。 文件存储在你的代码库中，由 git 进行版本控制，并且可以像其他代码一样在 PR 中进行审查。 我很想知道其他人是否也遇到过同样的问题，以及你们是如何处理的。 PyPI: [https://pypi.org/project/prompt-run/](https://pypi.org/project/prompt-run/)

嗨，HN， 我正在构建 Opencom，一个开源的客户消息平台——基本上是一个可以自行运行的 Intercom 替代品，设置简单，基础设施管理需求最低。代码库和演示链接如下： [Opencom GitHub 代码库](https://github.com/opencom-org/opencom) [Opencom 官方网站](https://opencom.dev) 我在多年的使用 Intercom 的挫折后开始了这个项目。我喜欢他们提供的工具选择，但不喜欢他们复杂且昂贵的定价模式以及频繁的界面和用户体验变化。我希望有一个简单且便宜的开源替代品，使其适用于任何规模的项目。 我想要的功能尽可能接近 Intercom 的功能集，甚至更多。你可以根据需要自托管，完全可以选择自托管全部或部分功能，甚至只使用托管的前端和后端。 ### 包含的功能 - 通过可嵌入的小部件进行实时聊天，连接到共享收件箱 - 工单、活动/系列、调查（NPS/CSAT）、细分、报告 - 产品导览/工具提示/检查清单 - 知识库 + 人工接管的 AI 代理 - 通过 Resend 集成的电子邮件渠道 - React Native SDK - 计划提供原生 iOS 和 Android SDK ### 托管/部署模型 Opencom 的架构设置相对简单： 后端：所有功能都运行在 Convex 上（代码库的部署指南将 Convex 视为标准后端），电子邮件功能使用 Resend（例如，RESEND_API_KEY、Webhook 验证等）。 前端：网页仪表盘/小部件/着陆页是标准的 Next.js/Vite 应用，因此你可以选择在 Vercel 上托管它们（Convex 提供与 Vercel 部署的优质文档和集成）。 混合搭配：有明确的“托管应用 + 自己的 Convex 后端”配置，以及“自托管网页 + 自己的后端”和“完全自托管”。 换句话说，你可以选择完全自托管，或者使用托管的网页和移动应用，同时指向你的 Convex 后端。 ### React Native SDK 如果你希望在自己的移动应用中实现类似 Intercom 的应用内消息功能，Opencom 在单体代码库中包含了一个 React Native SDK 包，并计划提供原生的 iOS/Android SDK。 ### 关于托管服务 目前，托管设置旨在作为演示（让人们可以在不进行完整部署的情况下试用）。如果对合理定价的直接 Intercom 替代品有足够的需求，我可以将其转变为一个正式的托管服务。 ### 我非常希望得到的反馈 - 对于那些本来会购买 Intercom 的团队来说，Convex 后端 + Vercel 前端的分离是否合理？ - 有没有缺失的功能是切换的硬性要求？ - 如果这成为一个简单的托管选项（没有企业销售的繁文缛节），你对许可/定价的期望是什么？ - 其他任何想法——这是我第一个开源项目，重度依赖 AI，因此我预期会有问题/低级错误，我知道有些地方需要改进。我的希望是其他人也想要这样的产品，并愿意参与完善他们想要或需要的功能。 感谢你的关注！

嗨，HN， 我开发了EEGFrontier，这是一个基于ADS1299和RP2040的紧凑型开源EEG采集板。 我的目标是设计一款低成本的电路板，能够与干电极配合使用，同时展示完整的EEG信号链——没有抽象，没有封闭的固件。 在这个项目中，令我最惊讶的是一些实际问题，这些问题在数据手册中并没有得到充分的准备：接地（REF/BIAS）、数字线路的噪声耦合、布线限制，以及一些小的布局决策如何显著影响信号质量。 该代码库包含完整的KiCad文件、固件、带有成本参考的物料清单（BOM）和文档图片。这是一个V1版本的电路板，已经可以正常工作，但我正在积极迭代屏蔽和噪声抑制的设计。 我非常希望能得到在EEG、生物信号或模拟前端设计方面有经验的人的反馈——尤其是批评意见。

嗨，HN， 我开发了 SplatHash。这是一个轻量级的图像占位符生成器，我写它是为了成为 BlurHash 和 ThumbHash 的一个更简单、更快速的替代品。 仓库链接： [https://github.com/junevm/splathash](https://github.com/junevm/splathash)

你好，HN，我是 Jarvish 的创始人。 我大部分时间都在终端中工作，对于标准的错误解决流程感到非常沮丧：命令失败 -> 复制标准错误 -> 打开浏览器 -> 粘贴到 ChatGPT/Google -> 复制修复方案 -> 粘贴回终端。这完全打断了我的工作状态。 我希望能有一个无缝的体验，让终端能够自动了解刚刚发生的事情。 因此，我构建了 Jarvish。它是一个用 Rust 编写的完全功能的交互式 shell，并且将一个 AI 代理无缝集成到 REPL 循环中。你不需要任何特殊的前缀——如果你输入 `ls -la`，它就会执行这个命令。如果你输入 `Jarvis，这个构建为什么失败了？`，它会将请求路由到 AI。 以下是其背后的工作原理： - “黑箱”（I/O 捕获）：它使用 `os_pipe` 和多线程实时捕获子进程的 `stdout`/`stderr`。这会将输出捕获到内存中供 AI 使用，同时在终端中渲染而不打断交互式 TUI 工具。 - 上下文记忆：捕获的 I/O 使用 `zstd` 压缩，进行哈希处理（类似于 Git blobs），元数据存储在本地 SQLite 数据库（`rusqlite`）中。当你向 AI 提问时，它会自动检索最近的 I/O 历史作为上下文。 - 代理能力：使用 `async-openai` 进行函数调用，AI 可以自主读取文件、执行 shell 命令，并在给出答案之前调查问题。 - REPL：基于 `reedline` 构建，提供类似 Fish 的体验（语法高亮、自动建议）。 我一直在将其作为我的日常工具使用（当前版本为 v1.1.0）。我非常希望听到你们对架构、Rust 实现或任何功能请求的看法！