一周热榜

你在做什么工作？你有没有想到什么新的想法？

嗨，HN， 我们是Brendan和Michael，Sourcebot的创始人（[https://www.sourcebot.dev](https://www.sourcebot.dev)），这是一个用于大型代码库的自托管代码理解工具。我们在9个月前首次在HN上发布了代码搜索功能（[https://news.ycombinator.com/item?id=41711032](https://news.ycombinator.com/item?id=41711032)），现在很高兴与大家分享我们的最新功能：Ask Sourcebot。 Ask Sourcebot是一个智能搜索工具，允许您用自然语言提出关于整个代码库的复杂问题，并返回带有内联引用的结构化响应。您可能会问的某些问题包括： - “这个代码库中的身份验证是如何工作的？使用了什么库？用户可以通过哪些提供者登录？”（[https://demo.sourcebot.dev/~chat/cmdpjkrbw000bnn7s8of2dm11](https://demo.sourcebot.dev/~chat/cmdpjkrbw000bnn7s8of2dm11)） - “在Go中，我应该什么时候使用通道而不是互斥锁？找出两者的实际用法并包含在您的回答中。”（[https://demo.sourcebot.dev/~chat/cmdpiuqhu000bpg7s9hprio4w](https://demo.sourcebot.dev/~chat/cmdpiuqhu000bpg7s9hprio4w)） - “Zoekt代码搜索引擎中的分片是如何在内存中布局的？”（[https://demo.sourcebot.dev/~chat/cmdm9nkck000bod7sqy7c1efb](https://demo.sourcebot.dev/~chat/cmdm9nkck000bod7sqy7c1efb)） - “我如何从Rust调用C？”（[https://demo.sourcebot.dev/~chat/cmdpjy06g000pnn7ssf4nk60k](https://demo.sourcebot.dev/~chat/cmdpjy06g000pnn7ssf4nk60k)） 您可以在我们的演示网站上亲自尝试（[https://demo.sourcebot.dev/~](https://demo.sourcebot.dev/~)）或查看我们的演示视频（[https://youtu.be/olc2lyUeB-Q](https://youtu.be/olc2lyUeB-Q)）。 这与现有的工具如Cursor或Claude代码有什么不同？ - Sourcebot专注于**代码理解**。我们认为，开发团队面临的主要瓶颈不再是编写代码，而是获取必要的上下文，以便在更广泛的代码库中进行高质量的更改。这一点无论作者是人类还是大型语言模型（LLM）都适用。 - 与在您的IDE或终端中不同，Sourcebot是一个网页应用。这使我们能够发挥网页的优势：丰富的用户体验和无处不在的访问。我们投入了大量精力，将IDE的最佳部分（代码导航、文件浏览器、语法高亮）与定制的用户体验（丰富的Markdown渲染、内联引用、@提及）结合在一起，便于团队成员之间的共享。 - Sourcebot可以维护一个最新的索引，涵盖托管在GitHub、GitLab、Bitbucket、Gerrit等平台上的数千个代码库。这使您能够在不需要本地检出代码库的情况下提出问题。这在熟悉代码库的陌生部分或处理通常分散在多个代码库中的系统（例如微服务）时尤其有用。 - 您可以自带API密钥（BYOK）使用任何支持的推理模型。我们目前支持11种不同的模型提供商（如Amazon Bedrock和Google Vertex），并计划添加更多。 - Sourcebot是自托管的，公平源代码，且免费使用。 在技术实现上，我们将现有的正则表达式搜索、代码导航和文件读取API暴露给LLM作为工具调用。我们通过系统提示指示LLM使用这些工具获取必要的上下文，以充分回答用户的问题，然后提供简洁、结构化的响应。这包括内联引用，这些引用是LLM可以嵌入其响应中的结构化数据，客户端可以识别并适当地呈现。我们基于一些出色的库构建了这一功能，如Vercel AI SDK v5、CodeMirror、react-markdown和Slate.js等。 这种架构故意保持简单。我们决定不引入任何额外的技术，如向量嵌入、多代理图等，因为我们希望在现有条件下推动我们的能力极限。我们计划在获得用户反馈后重新审视我们的方法，了解哪些有效（哪些无效）。 我们对推动代码理解的边界感到非常兴奋。请试试看：[https://github.com/sourcebot-dev/sourcebot](https://github.com/sourcebot-dev/sourcebot)。谢谢！

我们生活在一个奇怪的不对称状态中：公司使用人工智能与我们交流，但我们仍然需要手动拨打电话。最近，各行各业的公司都在采用人工智能语音助手，包括大型零售商、家庭牙医诊所和当地药店。今年，我接过几次电话，听到的人工智能声音非常自然，体验起来相当不错。但这让我思考——如果他们使用机器人来拨打电话，为什么我们这些消费者仍然要亲自打电话呢？ 于是我开发了Piper：基本上是一个为你打电话的人工智能。你告诉它你需要什么（预约、查询订单、争议费用等等），它会在你进行实际工作的同时处理整个对话。目前它是一个网页应用程序，Chrome扩展正在等待批准，但不久你就可以点击任何电话号码，让Piper来处理。 一些技术细节比预期的要复杂： 延迟——在对话中，每毫秒都很重要，我们必须围绕键值缓存进行优化，已经将通过公共电话网络（PSTN）传输的首个单词延迟降低到约1000毫秒，这感觉相当自然。 保持语音助手的轨道——我们构建了自定义的上下文工程逻辑，持续更新助手的情境意识，让它知道何时被转接、何时处于等待状态等。 到目前为止，我们与早期测试者进行了约50次成功的通话。主要的失败发生在需要复杂验证或文件的情况下。此外，我们还暂时关闭了我们的IVR导航，发现了一些导致不必要转接的边缘案例，但我们正在努力修复这些问题。 我真的认为我们正朝着一个人工智能与人工智能进行大多数日常事务交流的世界迈进，而电话通话可能是这一现象首次大规模发生的真实例子！ 你可以在我们的网站上查看语音演示。 [https://pipervoice.com](https://pipervoice.com)