我使用本地 Qwen 27b 构建了一个工具框架来替代 OpenCode

分享我构建的本地大语言模型运行框架，它基于 Qwen 3.x 27B（超过90%本地构建），在本人监督下完成——并非“氛围编程”产物。它是免费的、无遥测、开源（采用 AGPL 协议）。适用于 Windows 和 Linux（抱歉，暂不支持 Mac）。我用它处理自己的编码及混合工作流。 **与其它框架的不同之处** - **即时代码审查**：在工具调用前通过护栏进行代码审查，便于在编辑获批前进行检查。 - **三方对话**：代理和用户均可在子代理线程中聊天，实现三方对话。任何聊天对话均可转为另一个主聊天对话的子代理对话——形成嵌套对话。 - **语音听写批注**：通过语音听写进行批注。说话总是比打字快，因此更具生产力。 - **自动化编译**：可以从任意 GitHub 分支编译 llama.cpp，并使用配方脚本执行，配合可自定义界面，实现优雅的小型自动化。 **整体功能** - **服务器管理器**：可在此运行大语言模型，并与 Open-Code/Claude Code 等工具配合使用。 - **内置 MCP 工具**：文件系统、网页抓取、代码图谱、待办事项等。可通过外部 MCP 扩展。 - **子代理任务分配**：使用子代理拆分并卸载任务，利用其他对话作为信息来源。 - **对抗性 AI 审查**：使用第二个对抗性 AI 审查所有 AI 消息，根据你的规则避免潜在陷阱。 - **语音聊天**：语音听写与 AI 交互，通过 TTS 获取答案——无需离开语音模式即可进行批注和评论。 - **工作模式**：通过工作模式切换 AI 在规划、构建、研究或审查时的行为。完全可自定义。 - **自定义编译后端**：为你的系统自定义编译 llama.cpp 后端，GPU 无关——支持 CUDA/ROCm/Vulkan。 网站：https://warpdrv.ai GitHub：https://github.com/mikjee/warpdrv 欢迎反馈（或点星），谢谢 :) 对，没错——我就是用这个框架构建了这个框架 :D **使用硬件**：Strix Halo 128GB (FEVM FAEX1) + RTX Pro 5000 48GB --- **通过这次经历观察到和学到的一些事** - **每个功能/缺陷一个对话**：我让对话紧扣当前主题。如果有多个话题，我会为每个话题单独创建对话，而不是在同一个对话中讨论所有内容。高度聚焦于单一话题的对话能产生质量高得多的结果。 - **在大型代码库中探索占据大量时间**：最初我在 CLAUDE.md 中提供了项目描述及其所有功能。但后来我发现 AI 在探索或准备相关文件列表时会感到吃力，会遗漏重要文件，尤其是在规划新功能时。因此，我改为仅包含简短的项目描述，不涉及所有功能，并在 CLAUDE.md 文件中附加了通过脚本递归生成的项目所有文件和文件夹的完整列表（嵌套树状结构）。这更有助于模型预先根据文件名判断哪些文件可能相关，并通过文件夹层次结构了解项目结构。 - **就像正常编码一样，起步容易，但随着代码库增长会变得更难**：早期做出的决策非常重要。本地开发至少需要一双警惕的眼睛来引导或推动模型朝着正确的方向前进——完全无人监督的“氛围编程”适用于云端模型构建那些需求范围有限的应用。如果你的应用要用于任何级别的严肃用途，资深开发级别的编码经验是绝对必要的。 - **不要污染你的上下文**：如果你对代码库有很好的概览，我建议你定期拒绝模型认为可能有用但实际上无关的文件读取请求。将模型控制在你清晰的指导范围内，可以避免大量不必要的探索。 - **预先修正不良实践**：糟糕的代码、反模式总会被继承。如果你留下一个不良的代码模式并接受它作为技术债务，模型会读取它并再次使用。模型倾向于遵循已建立的代码库模式，而你接受为技术债务的那个坏代码，会在你构建的每个新功能中扩散。 - **旨在提高生产力**：使用 AI 编码需要在自主性和控制之间取得微妙平衡。自主性过高会降低代码质量，而控制过多则需要更多人力时间。务必在编辑生效前进行审查。更好的做法是使用即时审查。我正是为此创建了护栏功能——我可以给出具体指令，让它在编辑请求和我批准编辑之间形成一个层。这也打破了下意识点击“允许”的坏习惯。 --- 请让我知道你对这个项目的看法，以及你本地使用 Qwen 的经验。谢谢 :)