#框架

avatar
Ehco
1周前
之前担心年轻dev全靠vibe coding长不出建模直觉，又想了一下就和当年有人说用了ORM就不会写SQL了，用了框架就不懂HTTP了 确实每一层抽象都会让一部分人丢掉底层感觉，但每一代也都活下来了，只是"核心能力"的定义一直在漂移 可能真正危险的不是AI写代码，是团队里没人愿意做design review 🤔
#Vibe Coding #建模直觉 #ORM #SQL #框架 #Http #抽象 #核心能力 #AI写代码 #design review
avatar
indigo
2周前
截至 2027 年，对 Blackwell 和 Vera Rubin 架构的订单总额已达 1 万亿美元，比去年 5000 亿美元的预估翻了一番。Nvidia 已经不再仅仅是一家卖芯片的公司，它正在构建整个 AI 经济的基础设施底层⚡️ 在 GTC 2026 开幕演讲上，黄老板花了大量篇幅阐述了「未來 AI 工厂经济效能」的分析框架 — Token 经济学（不是 Web 3 的 Tokenomics）。图表中纵轴是每瓦 token 产出（吞吐量），横轴是 token 速率（推理速度）。 他解释了两个轴的商业意义：纵轴代表在固定电力下能产出多少 token，直接对应产能和营收规模。横轴代表每次推论的速度，也等于 AI 的智慧程度 —「AI 越聪明，你的吞吐量就越低，你思考得越久」但更聪明的 AI 可以卖更高的价格。 但 Rubin 把整条曲线大幅上移了：在低交互端（Free 层，50 TPS/User）比 Blackwell 快 2X，在高交互端（Premium 层，400 TPS/User）达到 10X。这意味着同样 1GW 电力，Rubin 在最吃算力的高端推理场景下效率提升最为惊人。图四的汇总最为直观：Blackwell 架构下 1GW 数据中心年营收约 $30B，Rubin 直接拉到 $150B——5 倍跃升。 “假设你是一个研究人员，每天使用 5000 万个 token，以每百万 token 150 美元计算。作为一个研究团队，这根本不算什么” 黄老板相信这就是未来！假设我们把 25% 电力分给免费层拉客户，25% 给中间层，25% 给高端层，25% 给顶级层，然后算总账。Rubin 之所以能实现 5X 营收跳跃，核心原因是它在高价值的 Premium 层（$45/M tokens）效率提升最大（10X），而这个层级贡献的营收密度也最高。 在电力受限的世界里，架构效率直接等于印钞能力。未来每一家云端服务商、每一家电脑公司、每一家 AI 公司、每一家公司，都会在思考他们的 token 工厂效率。你今年做的事，明年就会精确反映在你的营收上🤔
#NVIDIA #AI经济 #黑威尔与维拉·鲁宾架构 #订单总额 #AI工厂经济效能 #框架 #GTC2026 #Token经济学
avatar
你不需要谁谁谁，这个老师，那个老师，这个“100%胜率巨鲸”，那个“内幕巨鲸”，你需要的仅仅是一个审视每笔投资的框架。
币圈“1011”六倍崩盘：高杠杆爆仓潮，谁在裸泳？· 6476 条信息
#投资 #框架 #审视 #胜率 #内幕
avatar
卫斯理
6个月前
nestjs怎么样？ 有朋友玩过嘛？
#nestjs #技术讨论 #编程 #框架 #求推荐
avatar
等周五周六了，看起来框架定了
#周末 #计划 #期待 #框架 #安排
avatar
是的，这次跟上次会谈调性特别相似，好像现在财金领域特别喜欢用“框架”这个词，可能是“宏观”“架构”这些词在语义上逐渐贬值而采用的新说法吧。不管换什么新词，总之就是中美谈判取得了一些进展。两国你来我往也是见招拆招，你打我的TikTok我就干你的英伟达。想必一战二战冷战的前辈们从来没有想到有一天世界上前两号强国最后打来打去只是在争夺你手机上能刷到什么内容吧，其实真的还挺有现实魔幻主义的幽默感。。。
中美经贸磋商框架：虽有进展，仍存变数· 46 条信息
#中美谈判 #框架 #TikTok #英伟达 #现实魔幻主义
avatar
低空飞行
7个月前
UI 组件框架层级表
#UI组件 #框架 #技术 #层级 #中性
avatar
继续折腾我的BunPI - 崩屁，框架，第4天。
#BunPI #崩屁 #框架 #开发
avatar
idoubi
1年前
# 分享一个 idea 最近 AI Coding 越来越🔥。此类产品依赖的一项核心能力，是对 AI 生成的代码实时预览。 不同的项目代码，用到的预览方案不太一样。 如果生成的代码是单个文件，直接放到 iframe.srcdoc 就能预览，这个方案实现起来很容易。 如果生成的代码是多个文件，涉及到框架 / 组件 / 依赖，预览方案要复杂很多。 比如，让 AI 生成一个 Landing Page，按照 nextjs 的项目规范返回代码，AI 生成的文件树示例： - app/page.tsx - app/globals.css - components/ - Header.tsx - Hero.tsx - Features.tsx - Footer.tsx 这样的一组代码文件，要实时预览，就必须走自定义预览服务的方案。 考虑到想切入 AI Coding 赛道的产品很多，每个人都去实现一个预览服务，成本很高。 可以做一个通用的 code-preview 服务，提供 API 供第三方接入，支持预览任意类型的项目代码，包括单文件 / 多文件。 这个 code-preview 服务，可以用 go 实现，基于 docker + 预置镜像支持各类项目的预览需求。 1. 先制作几套常用的代码模板，打包成 docker 镜像，包括 - vite + react - vite + vue - nextjs + shadcn/ui - nuxtjs 2. 用 go 实现一个服务管理模块 - 接收上游传递的代码包 - 解压缩拿到所有的代码文件 - 根据预览的项目类型，选用特定的 docker image 启动 docker 容器，挂载要预览的代码文件到容器，替换掉模板中的特定文件 - 返回容器的预览端口，拼接可公网访问的预览地址给到上游 - 接到上游预览关闭信号，销毁 docker 容器，或者通过定时程序来清理不再活跃的 docker 容器 3. 需要评估预览服务的启动耗时（文件传输耗时，容器启动耗时），需要支持并发请求（可能会有本地端口占用冲突的问题，服务器资源不够问题） code-preview 服务跟 AI Coding 业务完全解耦，业务方请求 AI 生成完代码，请求 code-preview 服务的 API 拿到预览地址，通过 iframe.src 预览 code-preview 服务需要保证稳定性和启动预览的速度，如果因为代码问题导致预览报错，需要把错误信息返回给业务方，以便业务方带上错误请求 AI 修正代码后重新启动预览 code-preview 服务按照业务方的 API 调用次数计费 跟 bolt 公司用到的 WebContainer 技术有点类似，只不过 WebContainer 是跑在浏览器端，code-preview 服务是跑在云端，code-preview 的接入会更方便，灵活性也会更高。预览速度方面需要调试后才能对比。 你看好这套方案吗？
#AI #AI Coding #实时预览 #生成代码 #多文件预览 #iframe.srcdoc #框架 #组件 #依赖 #Landing Page