一周热榜

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

与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>，在较大的响应期间重新加载页面！ 未来有一些有趣的可能性，比如围绕共享流构建多人聊天体验。

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

现在我发现，与公司其他开发人员合作变得越来越困难，因为我们似乎都生活在一个充满人工智能的混乱之中。 我在工作中使用大型语言模型（LLMs），认为它们可以很有用，但我仍然会遇到一些连强大的Claude都无法解决的问题，这时我会想：“这个人对这个领域有很多知识，或者可能以前见过类似的错误，也许他们会知道！” 但结果往往不是这样！即使他们曾经知道，花费脑力去记住这些信息所需的精力也太宝贵了，他们宁愿把我的问题直接扔回他们选择的LLM中，然后用那个来回复我。另一个可以接受的回答是问我是否尝试过询问LLM该怎么做，因为也许那样就能解决问题。为什么还要费心呢？不如不断按下虚拟老虎机的生成按钮，直到得到一个有效的答案。 我曾有一个来自其他团队的人主动提出提交代码来修复我们遇到的问题，审查后我惊讶地发现，这几乎是我们自己向LLM询问后尝试并失败的内容的逐字复制。这是在回答“我们是否尝试过使用LLM来解决这个问题”时回答“是”的情况下发生的，但你永远不知道，这个人这次可能问对了方式…… 我最喜欢的另一个例子是被问到在我们开始构建之前，是否已经用AI检查过我们的“设计”。这可能是最基础的REST API设计，但如果我们遗漏了什么呢？我们怎么知道？如果我们请求AI的帮助，它还会帮我们吗？ 合作在哪里？学习和与他人分享的愿望在哪里？我们对自己所做的事情的信心在哪里？我们到底在这里做什么？