返回首页
最新
一个用于管理和语义比较大型语言模型（LLM）提示的命令行工具。通过使用嵌入（OpenAI或本地）检测意义层面的变化，超越了文本差异的比较。该工具对于版本控制、测试以及持续集成/持续交付（CI/CD）工作流非常有用。
我和我的联合创始人在这个夏天申请了YC，推出了一个完整的量化平台——在一个地方进行回测、优化和策略部署。但由于监管的复杂性，我们遇到了困难，不得不进行转型。
在我的联合创始人转向其他项目时，我继续专注于核心问题：为什么从回测到实盘交易如此困难？我们最初的平台只支持一个回测框架，并通过Alpaca作为经纪商。这种方式脆弱且受限。
因此，我构建了StrateQueue，作为一个开源库。现在它支持四个主要的回测框架（Backtrader、Zipline、PyAlgoTrade、bt），并提供统一的API。经纪商方面也是如此——支持IB和Alpaca，未来还会增加更多。添加新的经纪商非常简单。
关键的洞察是，大多数人并不需要另一个回测平台——他们需要的是从现有回测到生产环境的桥梁。StrateQueue处理那些复杂的部分：实时数据流、经纪商API、错误处理、监控和延迟优化。
无论使用哪个框架，你只需三行代码就能从回测切换到实盘。
我非常希望能听到曾经经历过这种生产部署噩梦的人的反馈。
我正在构建LiquidIndex，这是一个RAG API服务，旨在轻松为AI应用添加个性化上下文。与其构建一个完整的系统来上传、处理和搜索用户的文件或笔记，不如直接调用几个API。它处理了复杂的部分——例如连接到Notion或Google Drive，将数据拆分成可用的片段，并使其可搜索。然后，当你想用这些数据回答问题时，只需查询，它会给你最相关的结果——可选地附带一个LLM生成的答案。没有管道，没有基础设施，没有麻烦。
以下是核心API：
1. 创建客户（这是存放数据的空间）
2. 创建上传会话（这是用户上传数据的地方）
3. 查询
当前连接器：文件上传、Google Drive、Notion、Dropbox
支持的文件类型：PDF、文本文件、Markdown、CSV和XLSX（包括Google文档和表格）
网站： [https://liquidindex.dev/](https://liquidindex.dev/)
可以查看游乐场，体验一下它是如何工作的！
将您关心的类别、主题和风格输入，WallTrek 将为您自动生成壁纸。每次看到它生成的新作品总是令人惊喜。该软件是开源的，使用 Dalle3，并支持自带密钥（BYOK）。
我是一名软件工程师和键盘爱好者，曾想要定制的键帽套件，但找不到我喜欢的款式。这促使我创建了Thockfactory，一个在线键帽配置器，让任何人都能设计和订购自己喜欢的定制套件。
第一版于2024年4月上线，但在收到反馈和我自己使用后的体验中，我意识到商店和配置器需要彻底改进。我完全关闭了网站，并几乎重建了所有内容，专注于提供更好的用户体验和更顺畅的订购流程。
非常欢迎任何反馈、错误报告或想法。您可以在这里尝试配置器：<a href="https://thockfactory.com" rel="nofollow">https://thockfactory.com</a>
我很乐意回答有关技术栈、制造或其他任何问题。
作为软件工程师，我们常常面临一个选择：是自己编写代码，还是使用现有的库来完成这项工作。无论我们是否愿意，最终都会添加依赖项。事先检查新依赖项的情况无疑是一个良好的实践：它是否在维护？由谁维护？它有多少问题，其中有多少是错误？这些错误是否正在修复？未来的计划是什么？发布频率如何，API 破坏的频率又是怎样的？
我们最喜欢的解决方案之一是 OpenSSF Scorecard 项目（<a href="https://github.com/ossf/scorecard">https://github.com/ossf/scorecard</a>），我们自己也在使用，并且强烈推荐它。
我们围绕这个项目构建了 shouldiuse.dev，使结果可以作为网站访问，并借此机会首次在专业项目中深入探索了大量 LLM 辅助编码。在这个过程中，三位成员（开发者和非开发者）各自开始了初步原型的“氛围编码”，一位使用 v0，一位使用 lovable，另一位使用 Cursor。起初，我们对生成这些原型的速度和外观感到惊讶，但很快就遇到了合并不同想法的问题，因为有多种不同的网络框架和版本在使用。前端的工作主要集中在细节和小调整的处理上。
与此同时，在后端，我们开始编写一个使用 ossf/scorecard 库的 Go 应用程序，以执行我们想要的许多检查。为了在这一方面也尝试 AI，我们故意大量使用 Copilot，并尝试不同的模型和提示。我们还增加了通过 GitHub API 收集的依赖检查的更多指标，最后通过 OpenAI 生成文本摘要。
生成最终文本推荐的提示包括：
* 一个标题，说明角色、能力和限制，以及预期的响应格式（JSON，且不使用列表/项目符号）——我们还要求它保持批判性、客观性，并给出简短而清晰的答案。
* Scorecard 检查的结果
* 额外的社区相关数据
* 在 FAQ 部分显示的问题——这些问题的答案也由 LLM 生成。
由于这样的检查涉及大量使用 GitHub API，我们要求用户在请求检查时输入 GitHub 个人访问令牌。第一次在 shouldiuse.dev 上检查一个仓库时需要几秒钟，但之后结果会存储在 PostgreSQL 中，以便后续更快检索。
目前它仅适用于公共 GitHub 仓库，但如果有需求，我们可能会添加其他平台。
我们还添加了一个带有内置身份验证的远程 MCP 服务器，因此您可以直接从 IDE 访问 <i>shouldiuse</i>，并在编码助手引入新依赖时自动检查，以确保只将安全的依赖项添加到项目中。
最初作为一个有趣的内部实验，迅速让我们惊讶于它的实用性。我们并没有计划公开发布它，但我们认为这可能对其他开发者有用，因此想在这里分享。如果您有任何反馈，欢迎提出！
嘿，HN！<p>这个想法源于我无法购买到GPU，并且不断输给机器人和黄牛。我想利用这个机会看看我能在“氛围编码和设计”方面走多远。<p>最终结果相当不错！以下是一些幕后细节。在未来的博客文章中，我会详细介绍构建这个项目的幕后过程。<p>- 登陆页面是使用React/Typescript/Tailwind.css构建的（我之前从未使用过）<p>- 仪表板基于Evidence.dev，使用Markdown中的SQL查询，并结合一些自定义的JavaScript进行图表格式化（同样是我之前从未使用过的 :)<p>- 能够将这样的想法从脑海中变为现实，原本需要我花费数月的时间在Stack Overflow和Google上学习React/Typescript/JavaScript，但这次只花了大约一个月（每天1-2小时）。<p>* “氛围编码”常常被误解，即人们有时认为这是一种魔法药丸。从构建这个项目的经验来看，我可以告诉你，不能像精灵的愿望那样轻易让网站变为现实。仍然需要付出相当大的努力来引导大型语言模型（LLM），在出现问题时进行调试，需要对设计有一定的想法，以及如何让它看起来好看，进行多次迭代。从第一次迭代到最终迭代之间，可能进行了大约500次迭代。