diffwithgpt.com 是一个简单的概念验证工具，利用本地托管的 Qwen/Qwen-8B 模型来总结 git 差异。它目前索引了一小部分 Go/devops 仓库，并通过抽象语法树（AST）派生的上下文来丰富提交信息，以提高语义准确性（目前仅限于过去三年的提交）。其目标是评估轻量级本地大型语言模型（LLMs）是否能够提供有意义的变更日志摘要。我的动机是开发一个工具，帮助运维团队在进行更改时或帮助调试可能未在提供的变更日志中捕捉到的问题。任何反馈都非常感谢，因为我正在考虑是否值得扩展到其他仓库/语言。
返回首页
最新
目前，编程语言的受欢迎程度似乎是判断大型语言模型（LLM）是否能够熟练生成可用代码的最佳指标（例如，Python、JavaScript、Java、C等）。然而，我认为，那些需要较少额外推理（和/或令牌？）的语言可能会使LLM更频繁地生成可用代码。例如，我想不可变性对于LLM来说可能比局部可变性更容易“推理”。严格的格式、显式类型、简洁的语法等也可以做类似的推测。基于这种推理，我可能会期待函数式语言特别适合作为目标。
有没有证据支持这些观点？是否应该（或者已经有）考虑到LLM而开发的编程语言？我们会看到开发者更倾向于使用LLM更擅长的语言吗？
你好，
我们刚刚开源了MCP-UI，这是一个提供精简客户端和服务器SDK的项目，旨在通过原生MCP传递丰富的互动UI组件。我们相信，这将开启一个未来，让AI交互基于UI片段来实现互动体验。
MCP-UI旨在成为推动这一倡议的实验平台。希望通过实验，社区能够找到实现这一新未来的最佳方式。
在技术层面上，SDK使任何MCP服务器能够以“ui://” URI响应嵌入资源。客户端SDK允许主机使用支持的方法（目前是原始HTML或外部应用）来渲染，并通过事件处理后续交互（例如，进一步的工具调用）。我们需要更好的交付方式，从React Server Components和Remote-DOM开始，以提高安全性。还有许多其他目标需要实现，例如可扩展的协议协商。
你今天就可以开始构建——
GitHub: [https://github.com/idosal/mcp-ui](https://github.com/idosal/mcp-ui)（查看演示视频）
文档: [https://idosal.github.io/mcp-ui](https://idosal.github.io/mcp-ui)
支持UI的聊天客户端及合规示例服务器: [https://scira-mcp-chat-indol.vercel.app](https://scira-mcp-chat-indol.vercel.app)（输入“show tasks”查看实际效果！）
本地开发检查工具: [https://github.com/idosal/ui-inspector](https://github.com/idosal/ui-inspector)
关于MCP中UI的进一步阅读: [https://github.com/orgs/modelcontextprotocol/discussions/287](https://github.com/orgs/modelcontextprotocol/discussions/287)
欢迎分享想法、建议和贡献！期待看到我们能够用它构建出什么。