空谷 Arvin Xu

统计数据

16
文章
0
粉丝
0
获赞
49
阅读
avatar
🐂 啊!
avatar
逗哥 🐂 ！ 咱也自掏腰包送 10 本给 LobeChat 用户，点赞参与~ 😋
#LobeChat #送书 #用户 #逗哥
avatar
不知道大家最近有没有感觉 Cursor 变笨了，应该是官方默认把原来读 200 行的逻辑改成了读 50 行，感觉是为了省成本😅
AI编程工具激战：Claude Code、Gemini Cli崛起· 346 条信息
#AI编程：Kimi搅局，Claude封号，群雄逐鹿· 480 条信息
#Cursor变笨 #Cursor性能下降 #Cursor读取行数减少 #Cursor省成本 #Cursor体验变差
avatar
听闻 WildCard 一事，突然想到自从我们开了水星银行以后，海外支付就再也没愁过 🤣 需要长期订阅一个 Vendor 的服务，就给这个服务单独开一张 Vendor Lock 的 Virtual Card 以及还给我们团队有需要的小伙伴每人开了一张 Virtual Card 用于支付海外 AI 服务 😆
avatar
详情链接：
avatar
我们的 Marketplace 项目是从 0 开始做的，到现在 1.3w 行 ts。其中应该 80~90% 是 vibe coding 出来的，只有 db 部分的查询是我们自己 refined 的来确保可维护性与查询性能。 我设计好架构并调过 Cursor Rules 以后，所有的增删改查基本上都能写的不错，所以算是是 vibe native 的架构方案。 在做 LobeChat 的逻辑的时候，目前只有单个模块的实现可以 vibe，比如我们做了个各个常见系统依赖的 checker ，以模块维度去做的话 90% 以上可以 vibe 。 但让它做长程的，跨模块的项目组织，这个能力就差很多了。还有前端 UI 部分模型做的都很差，基本上都是我自己写的。所以总体来说 LobeChat 里面可能只能 vibe 一半左右的代码。 不过好在 ai 基本上都能帮我 vibe 掉我不喜欢写的业务逻辑，且能写的很健壮，而我自己写 UI 则能写的很快乐，整体来说还是非常提效的。 但我们在做这个 feature 的时候还做了大量的 coding 以外的工作，比如自动化 CI/CD、跨项目联调等等，这些目前 AI 都帮不上什么忙，还是挺费时间的。比如 Marketplace 我们写完核心功能大概是 5月 20 号左右，但各种验证测试、迭代直至6月中旬左右才搞完。
AI编程工具激战：Claude Code、Gemini Cli崛起· 346 条信息
#AI编程：Kimi搅局，Claude封号，群雄逐鹿· 480 条信息
#Marketplace项目 #Vibe Coding #LobeChat #AI提效 #CI/CD耗时
avatar
[1/5] 还是想说一说做「一键安装 MCP 插件」这个 Feature 的整个心路历程。 去年 11 月 MCP 协议推出的时候我就看了这个协议。当时就觉得这个东西很不得了，其中最让我觉得惊艳的是 Local 部分的集成和使用。 但要利用好这个能力，势必要一个桌面端才能承载，所以基本上那个时候就下定决心今年必须要把桌面端给做出来。
avatar
[1/5] 📢 LobeChat 1.97.0 史诗级更新来啦~ 🥳 6000+ MCP 插件桌面端一键安装！🤯 经过累计长达 2~3 个月时间的开发，我们终于完成了 LobeChat 有史以来最大的一个项目： MCP Marketplace & 桌面端一键安装！
avatar
差不多搞完了，大活即将到来 😋
avatar
MCP 生态是真的繁荣🤯 咱的 Marketplace 上了半个月， Server 数量就 5k 了… 😲
avatar
在深度开发 LobeChat 的时候我就发现单纯的 Prompt Engineering 可能不再能很好地表征 llm 应用的实现。「 Context Engineering 」 这个说法，的确更好表达了当前的 AI 应用的本质
avatar
Cursor 的 Claude 4 Opus Max 居然不再按 API 计价了🤯 included 在 Pro 计划里了。这不得使劲薅？
avatar
不看不知道，一看吓一跳，原来开源能帮我们每个月省下来 600 美金的 Github Actions 的成本🤯
avatar
今天参加了良渚的 Demo Day，的确感觉整个环境、氛围还有大家的精神面貌都很不一样。期待这个“东方硅谷”的崛起~ 🚀
#良渚 #Demo Day #东方硅谷 #创业 #科技
avatar
最近在考虑将 LobeChat 的 AI Completion 实现全面转向 Nodejs Runtime ，来问问大家的看法： 站在 2025 年的当下来看，调用 AI 接口还有没有必要使用 Edge Runtime？使用 Vercel Fluid Compute 是否是 Edge Runtime 的上位替代？ 目前我们仍然使用 Edge Runtime 的考虑点： 1. Edge Runtime 没有时长限制，因此理论上具有无限时长的连接时间； 2. 从计价模型上来说，Edge Runtime 按请求次数收费，价格上可以说低于 NodeJS Runtime 一个数量级； 但 Edge Runtime 的缺点： 1. 无法支持连接 DB，虽然像 neon 这样的Serverless PG 服务商可以支持 edge runtime 的连接，但是考虑到我们的大量 Docker 用户还需要 Node 版 PG，这个方案就不可行； 2. Edge Runtime 必须要在多少s 之前有首 token 响应否则就会超时，这对于很多需要长时思考的模型来说并不友好 换成 NodeJS Runtime 的好处： 1. 可以直接连 DB，这样后面做 spend 落库分析都会很简单； 2. 可以长时运行，应该不会有 EdgeRuntime 的首 token 响应还会超时的问题； 缺点： 1. 计费上可能会更贵， Vercel 的 Fluid Compute 还是一个新东西，需要一个吃螃蟹的人真真实实探下这个底； 2. Vercel 上免费版的时长应该是最大90s，Pro 可以到达 800s，这就意味着免费版的 Vercel 自部署用户一个 ai 请求到了 90s 就会被掐断了，而如果是 edge runtime 则不会有这问题。 欢迎大家 share 自己的实践经验！🫡
avatar
空谷 Arvin Xu
10个月前
[1/9] 聊聊我们在做 LobeChat ( ) 过程中积累下来的一些实操经验吧。 我感觉很多人都不了解 Edge Runtime 和 NodeJS Runtime 的区别（对应 Vercel 的 Serverless Function，下统称 NodeJS Runtime），最后踩到坑里，甚至带来天价账单。 接下来我介绍的内容应该可以帮你理清很多概念，并在实际生产中避免踩坑，并大幅节省成本~🤯 (省 $5000 不是梦 😎)