最新

我是Hemang，Clidey的联合创始人。在构建Docucod——我们的技术文档生成和维护平台时，我们需要一种简单、快速且灵活的方式来托管文档。 我们最初使用了Next.js和Vercel，但感觉这有些过于复杂。我们并不需要服务器端渲染（SSR），而且遇到了模糊的Webhook错误和部署问题。对于一个静态文档网站来说，这种复杂性似乎有些多余。 因此，我们构建了Dory——一个针对技术文档优化的最小静态网站生成器。它是用Preact、Vite、Tailwind、FontAwesome、Mermaid和Typescript构建的。 Dory对我们有效的原因： - 读取一组.mdx文件 - 一个dory.json文件定义结构/布局 - 无需SSR，无云锁定 - 快速构建，最小配置，随处部署 Dory的目标是保持真正的简单——易于设置、易于使用，并且对于任何构建静态文档的人来说，部署毫不费力。它的设计灵感来自于Gitbook、Docusaurus、Readme、Mintlify和Read the Docs等优秀工具。虽然我们计划随着时间的推移添加更多功能，但简单性将始终是核心原则。 一旦它变得更加稳定，我们将进行适当的比较，以查看加载时间、打包大小等所有重要指标。 现在还处于早期阶段（测试版！），但对我们来说运行良好，我们非常希望得到社区的反馈。 仓库链接：⁦[https://github.com/clidey/dory](https://github.com/clidey/dory) 感谢您的关注！

两者之间的区别，以及它们各自有用的原因。

嗨，HN， 我开发了一个命令行工具（CLI），用于上传文档并通过一个使用搜索工具的LLM代理进行查询，而不是将所有内容塞入上下文窗口。我录制了一个演示，使用了《CrossFit 2025 规则手册》，展示了这种方法与传统的RAG和直接上下文注入的比较。 核心见解是，运行在循环中的LLM与工具访问结合时，在知识检索任务中表现得极为有效。与其寄希望于正确的片段进入上下文，不如让代理进行迭代搜索、优化查询，并对找到的内容进行推理。 这个CLI处理完整的工作流程： ```bash trieve upload ./document.pdf trieve ask "关键发现是什么？" ``` 您可以自定义RAG行为，检查上传状态，响应会以可扩展的来源引用流回。我非常喜欢在终端中使用这个工作流程，并且我很好奇其他人是否也觉得这种范式如此吸引人。 如果有兴趣，我考虑增加更多命令和自定义选项。该工具对于最多1000个文档片段是免费的。 源代码在GitHub上可用，并通过npm提供。 欢迎对这种方法或CLI设计提供反馈！ [1]: [https://www.youtube.com/watch?v=SAV-esDsRUk](https://www.youtube.com/watch?v=SAV-esDsRUk) [2]: [https://news.ycombinator.com/item?id=43998472](https://news.ycombinator.com/item?id=43998472) [3]: [https://github.com/devflowinc/trieve/blob/main/clients/cli/index.ts](https://github.com/devflowinc/trieve/blob/main/clients/cli/index.ts) [4]: [https://www.npmjs.com/package/trieve-cli](https://www.npmjs.com/package/trieve-cli)