最新

嘿，HN， 我创建了一个名为 nowrite.fun 的小型实验性写作工具。 这个概念非常简单： 你设置一个计时器（例如 5 分钟），开始写作——如果你停止输入，你的文本就会消失。没有草稿，没有恢复，没有宽恕。 这个工具受到像 Write or Die 这样的应用启发，但从头开始重建，使用了轻量级的技术栈：Deno + TypeScript、XState、anime.js 和 canvas-confetti。托管在 Deno Deploy 上。 它是一个用于短时间集中写作的工具——一条推文、一段博客、一则新闻简讯。 继续输入 → 你赢了。 犹豫 → 它就消失了。 它很简约，有点紧张，但出乎意料地激励人心。 我还在 Product Hunt 上发布了它，想看看这种奇怪的、近乎自虐的用户体验是否能引起共鸣： [https://www.producthunt.com/posts/no-write](https://www.producthunt.com/posts/no-write) 如果你觉得它有趣或有用，我非常感谢你的点赞！ 期待你的想法、功能建议或性能吐槽。 在这里试试： [https://nowrite.fun](https://nowrite.fun)

大家好，我是 Dapr 的维护者。我们新增了一个示例，展示了如何构建一个对话代理，该代理能够上传、解析和理解复杂文档，同时保持长期记忆。这个示例还展示了代理如何将文件上传到多个存储提供商。期待大家的反馈。

最近，氛围编码趋势引起了广泛关注，但我认为我们需要对其在生产应用中实际能带来的效果进行现实检验。 我对像 Lovable.dev 和 Bolt.new 这样的工具进行的简要探索显示，它们有效运行的基础是传统编码的基础设施，如 Supabase。这表明，氛围编码的最终成功依赖于其背后基础设施的质量和广度。 在原型设计和简单应用中，氛围编码展现出了一定的潜力。但对于复杂的生产系统，我依然持怀疑态度。我对其他人在使用这些工具进行超出基础实现的应用时的经验感到好奇。 在我看来，前进的道路需要为特定领域设计的专业基础设施工具。在我的工作中，我开发了 ChainReact.NET 库，提供了涵盖整个应用栈（前端、后端、业务逻辑等）的高级抽象，专门用于业务应用。这种方法可能为氛围编码在该领域真正有效提供所需的基础。一刀切的解决方案可能不会成功。相反，为不同应用类别量身定制的基础设施更具潜力。 你怎么看？我们如何能够弥合氛围编码的宏伟愿景与生产现实之间的差距？哪些基础设施领域最迫切需要开发，以使氛围编码变得可行？

在使用大型语言模型（LLM）API时，您遇到了哪些可靠性、成本和性能问题？例如，您在使用OpenAI的文件API时遇到了哪些问题？