最新

在与Claude、Gemini以及Cursor内部的其他人合作了几个月后，我厌倦了不断修复回归问题和重新解释我项目的逻辑。虽然人工智能令人印象深刻，但在没有适当上下文的情况下却显得盲目。 我不想要更多的提示技巧，我需要的是结构。因此，我构建了一个框架，为大型语言模型（LLMs）提供： – 明确的项目规则和约束 – 清晰的逐步开发协议 – 随时间演变的记忆系统 – 人工干预的检查点，以减少失败 这彻底改变了我在实际软件项目中使用人工智能的方式。我将其开源分享，希望能帮助其他人提升他们的人工智能开发工作流程。 欢迎提出问题或深入讨论技术细节。 → 上面的链接，欢迎反馈！

与AI聊天应用的体验有时会显得脆弱——它对网络故障没有韧性，响应也不像传统搜索那样是确定性的。正如Garry Tan所说（<a href="https://x.com/garrytan/status/1927038513108701662" rel="nofollow">https://x.com/garrytan/status/1927038513108701662</a>），“当给定的响应返回并在中途失败时，感觉就像是灾难性的数据显示丢失，而下一次重试的效果也不如预期。” Vercel最近发布了一个“可恢复流”（“resumable-stream”）包（<a href="https://github.com/vercel/resumable-stream" rel="nofollow">https://github.com/vercel/resumable-stream</a>），旨在通过使用Redis作为后端存储来解决这个问题。 我觉得我们可以通过s2.dev简化这个方法（我是团队中的一名工程师），并创建了一个分支，最终借用了API，但其他部分完全重写了：<a href="https://github.com/s2-streamstore/resumable-stream" rel="nofollow">https://github.com/s2-streamstore/resumable-stream</a> - S2流的成本低，因此不需要优化仅在有其他读者时才刷新，流始终被创建并写入。 - 与Redis通常是短暂的特性不同，令牌始终是持久的，并且在流的数量或数据量方面没有内存限制。 - 依赖于S2内置的并发控制。一个唯一的围栏令牌确保只有一个写入者，并且乐观地提供一个序列号，以匹配预期分配给下一个记录的序列号，以便在重试时去重。 它与Chat SDK完美集成，您可以在这里尝试：<a href="https://ai-chatbot-s2.vercel.app" rel="nofollow">https://ai-chatbot-s2.vercel.app</a>，在较大的响应期间重新加载页面！ 未来有一些有趣的可能性，比如围绕共享流构建多人聊天体验。

大家好，我用Python制作了这个简单的图形用户界面工具，用于测试硬件的FLOPs速度。欢迎大家试用、反馈意见或贡献代码。