最新

嗨，HN， 我已经做了很长时间的开发者，和你们中的许多人一样，我对AI编码工具的“全有或全无”问题感到沮丧。 你请求AI修复一个bug或实现一个功能，它却重写了整个文件。它会更改你的导入，重命名你的变量，或者删除它认为不必要的注释。这就像把生产服务器的根权限交给一个初级开发者（像我一样），仅仅是为了更改一个配置文件。 因此，29天前，我开始构建Yori来解决信任问题。 **概念：语义容器** Yori引入了一种语法，充当AI的防火墙。你可以在文本文件中定义一个`$${ ... }$$`块。 块外（宿主）：你的手动代码、架构和结构。AI无法触碰这些内容。 块内（容器）：你用自然语言表达意图。AI只能在这里生成代码。 **示例：myutils.md** ```cpp EXPORT: "myfile.cpp" // 我的手动架构 - AI无法更改此部分 #include "utils.h" void process_data() { // 容器：AI在这里受到沙箱限制，但可以继承文件的其余部分作为上下文 $${ 使用快速排序对输入数据向量进行排序。 过滤掉负数。 打印结果。 }$$ } EXPORT: END ``` **工作原理：** Yori是一个C++包装器，用于解析这些文件。EXPORT块内和容器外的内容将按原样复制。当你运行`yori myutils.md -make -series`时，它会将提示发送到本地（Ollama）或云端的LLM，生成语法，填充块，并使用你的本地工具链（GCC/Clang/Python）编译结果。 如果编译失败，它会将错误反馈给LLM进行重试（自我修复）。 **我认为这很重要的原因：** 1. 安全性：你不再给AI“根权限”来访问你的文件。 2. 意图作为源：提示保留在文件中。如果你想将逻辑从C++迁移到Rust，你可以保留提示，只需更改编译目标。 3. 增量构建（即将添加）：命名容器允许缓存。如果提示没有更改，你就不需要支付API调用的费用。 这是一个开源项目（MIT），使用C++17，并且可以在本地运行。 我很想听听你们对“语义容器”概念的反馈。这是我们一直缺失的AI编码抽象层吗？请告诉我你的想法。此外，如果你无法运行yori.exe，请告诉我出了什么问题，我们会看看如何解决。我在GitHub上开了一个问题。我也在为这个项目制作文档（GitHub wiki），请期待很快发布。 GitHub: [https://github.com/alonsovm44/yori](https://github.com/alonsovm44/yori) 谢谢！

我不太明白的是，当硬件不断升级，人们能够在本地运行大型语言模型（LLMs）时，这些人工智能即服务（AI-as-a-service）公司将如何在未来生存。当然，目前租用与购买的选择明显倾向于租用，但我可以想象未来人们会购买一台放在家里的台式电脑，并在那台机器上进行所有个人推理。甚至可能会有推理池来分担多个用户的负载。你认为这种情况可能发生吗？这些公司的应对计划是什么？