最新

我正在构建 LiquidIndex，一个 RAG API 服务，可以轻松地为 AI 应用添加个性化上下文。您无需构建一整套系统来上传、处理和搜索用户的文档或笔记，只需调用几个 API 即可。它处理了困难的部分——例如连接到 Notion 或 Google Drive，将数据分解成可用的片段，并使其可搜索。然后，当您想使用该数据回答问题时，只需查询它，它就会给您最相关的结果——可选地附带 LLM 生成的答案。无需管道，无需基础设施，无需烦恼。 以下是核心 API： 1. 创建客户（这是一个放置数据的空间） 2. 创建上传会话（这是用户上传数据的地方） 3. 查询 当前连接器：文件上传、Google Drive、Notion、Dropbox 支持的文件类型：PDF、文本文件、Markdown、CSV 和 XLSX（包括 Google Docs 和 Sheets） 网站：[https://liquidindex.dev/](https://liquidindex.dev/) 看看 Playground 感受一下它是如何工作的！

输入你感兴趣的类别、主题和风格，WallTrek 就会自动为你生成壁纸。每次看到它生成的壁纸都会有惊喜。开源项目，使用 Dalle3 模型，BYOK（自带 API 密钥）。

我是一名软件工程师，也是一名键盘爱好者。我一直想定制个性化的键帽，但找不到满意的。因此，我创建了 Thockfactory，一个在线键帽配置器，让任何人都能设计并订购自己的定制键帽套装。 第一个版本于 2024 年 4 月上线，但根据用户反馈和我自己的使用体验，我意识到商店和配置器需要全面改进。我完全关闭了网站，从那时起几乎重做了所有内容，重点是更好的用户体验和更流畅的订购流程。 欢迎提供任何反馈、错误报告或想法。您可以在这里试用配置器：<a href="https:&#x2F;&#x2F;thockfactory.com" rel="nofollow">https:&#x2F;&#x2F;thockfactory.com</a> 很乐意回答有关技术栈、制造或其他任何问题。

作为软件工程师，我们经常面临是自己编写代码还是添加现有的库来完成任务的决定。 不管我们喜欢与否——我们迟早都会添加依赖项。而且，事先检查新的依赖项被认为是很好的做法：它是否被维护？由谁维护？它有多少个问题，其中有多少是错误？这些错误是否正在被修复？路线图是什么？发布频率是多少，API多久会中断一次？ 我们最喜欢的已经存在的解决方案之一，可以回答这些问题，就是 OpenSSF Scorecard 项目（<a href="https:&#x2F;&#x2F;github.com&#x2F;ossf&#x2F;scorecard">https:&#x2F;&#x2F;github.com&#x2F;ossf&#x2F;scorecard</a>）——我们自己也在使用它，并且强烈推荐。 我们围绕它构建了 shouldiuse.dev，以便将结果作为网站访问，并借此机会首次在一个专业项目中深入研究了大量 LLM 辅助编码。 三个人（开发人员和非开发人员）各自开始试探性地编写初始原型，一个使用 v0，一个使用 lovable，一个使用 Cursor。起初，我们对生成这些原型以及它们看起来有多棒感到震惊，但很快就遇到了合并不同想法的问题，因为有多个不同的 Web 框架和版本在运行。前端的大部分工作肯定都花在了细节和小的调整上。 与此同时，在后端，我们开始编写一个 Go 应用程序，该应用程序使用 ossf/scorecard 库来执行我们想要的许多检查。为了也在后端尝试 AI，我们有意大量使用了 Copilot，并尝试了不同的模型和提示。我们还向依赖项检查中添加了更多指标，这些指标是通过 GitHub API 收集的，最后通过 OpenAI 生成文本摘要。 生成最终文本建议的提示包括： * 一个标题，说明角色、能力和局限性，以及预期的响应格式（JSON，没有列表/项目符号）——我们还告诉它要保持批判性、客观性，并给出简短而简洁的答案。 * Scorecard 检查的结果 * 其他与社区相关的数据 * FAQ 部分中显示的问题——这些问题的答案也由 LLM 生成。 由于此类检查涉及大量使用 GitHub API，因此我们要求用户在请求检查时输入 GitHub 个人访问令牌。第一次在 shouldiuse.dev 上检查存储库时，需要几秒钟，但随后结果会存储在 Postgres 中，以便以后更快地检索。 目前它仅适用于公共 GitHub 存储库，但如果有兴趣，我们可能会添加其他平台。 我们还添加了一个带有内置身份验证的远程 MCP 服务器，因此您可以直接从您的 IDE 访问 <i>shouldiuse</i>，并在编码助手向其中引入新依赖项时自动检查它们，以确保仅将安全的依赖项添加到项目中。 最初只是一个有趣的内部实验，但很快就让我们对它的实用性感到惊讶。我们没有计划公开发布它，但我们认为它可能对其他开发人员有用，因此我们想在这里分享它。欢迎任何反馈！

嘿，HN！ 这个想法的起源是我买不到 GPU，并且总是输给机器人/黄牛。我想着，我可以用这个方法看看我用“氛围编码和设计”*能做到什么程度。 结果相当不错！以下是幕后的一些细节。在未来的博文中，我将详细介绍构建它的幕后过程。 * 着陆页是 React/Typescript/Tailwind.css（我以前从未使用过） * 仪表盘基于 Evidence.dev - 这是 Markdown 中的 SQL 查询 + 一点点用于图表格式化的自定义 Javascript（同样，以前从未使用过 :) * 仅仅是把脑海中的这个想法变成现实，就得花上好几个月的时间，通过 Stack overflow/Google 搜索来学习 React/Typescript/Javascript，但这只花了一个月左右的时间（每天大约 1-2 小时） \* “氛围编码”通常是一个误称，也就是说，人们有时认为它是一个神奇的药丸。从构建这个过程中，我可以告诉你，你不能像阿拉丁神灯许愿一样让网站凭空出现。它仍然需要付出巨大的努力来引导 LLM，在出现问题时进行调试，需要对设计和品味有所了解，知道要构建什么以及如何让它看起来更好，并且要进行多次迭代。从第一次迭代到最终迭代，可能经历了 500 次迭代。