YOHO AI

标签： AI

  • 谷歌AI把Google拼错了，大语言模型的拼写死穴到底能不能修好

    上周有个网友在X上发帖吐槽，说用谷歌搜索”Google”的时候，AI概览（AI Overview）给出的结果里，Google这个单词里有两个P。等等，Google里明明只有一个P啊。

    这不是孤例。有人问AI”poop”里有几个R，它说有1个（实际是2个）。问”journalism”怎么拼，它给出的答案是j-o-u-r-n-a-d-i-s-m——多了一个完全不存在的D。”disregard”更离谱，AI概览直接输出了”我明白了，如果你有新的提示或问题请告诉我”，活像是把训练语料里的客服话术当成了单词释义。

    谷歌通过邮件向TechCrunch回应称：”统计单词内字母数量一直是大语言模型的已知难题，我们正在努力修复这个问题。”说实话这个回应挺诚实的——他们没狡辩，也没说这是特性不是bug。

    为什么AI不会拼单词

    这事的根源得从Transformer架构说起。大语言模型处理文本的时候，不是逐字母读取的，它会把文本切分成一个个”token”——一个token可能是一个完整单词，也可能是一个音节，甚至单个字母。模型内部存的是这些token的数字编码，根本不知道T-H-E分别是哪几个字母。

    阿尔伯塔大学的AI研究员Matthew Guzdial给TechCrunch举了个例子：当你输入单词”the”的时候，模型拿到的是”the”这个整体对应的编码，它完全不知道这个单词是由T、H、E这三个字母构成的。这就好比你认识一个人，但说不出他长什么样——你知道这个token”长什么样”，但拆不开它。

    Google AI Overview spelling error screenshot
    谷歌AI概览将”Google”错误拼写为两个P的截图（TechCrunch修改标注）

    东北大学研究大语言模型可解释性的博士生Sheridan Feucht说得更直白：对于语言模型来说，”单词”到底是什么其实是很难界定的问题。哪怕我们让人类专家达成一个完美的token词表共识，模型可能还是觉得需要把内容拆分得更细。他猜测，由于这种模糊性，根本不存在完美的分词器。

    这不是第一次，也不会是最后一次

    谷歌上一次在AI搜索上翻车，还是AI概览刚上线的时候。当时它引用讽刺网站The Onion和Reddit的帖子，给出了”每天吃一块小石头””在披萨上涂胶水”这类荒谬建议，闹得沸沸扬扬。这次谷歌把整个搜索体验都改成了生成式AI驱动，是搜索产品25年来最大的一次重构，拼写错误只是暴露出来的冰山一角。

    有意思的是，拼写测试已经成了AI圈的一个梗。每当有公司发布新模型，大家都会问它”strawberry里有几个R”——这个简单问题曾经难倒了所有主流模型。现在情况好多了，但Google这件事说明，哪怕模型能在几秒内写出一整个应用，或者解决困扰数学家几十年的难题，拼写能力还是和幼儿园小朋友差不多。

    研究人员并不乐观认为这个问题能被彻底解决。但换个角度想，大语言模型的价值本来也不在拼写能力上。这些明显的低级错误反而是个好事——它提醒我们，AI并不完美，哪怕它有时候看起来全知全能。用AI输出结果之前，二次核对准确性这件事，永远不能省。

  • LLMs-from-scratch：96.3K Stars！从零手写大模型，彻底搞懂LLM底层原理

    LLMs-from-scratch：96.3K Stars！从零手写大模型，彻底搞懂LLM底层原理

    LLMs-from-scratch 封面

    《Build a Large Language Model (From Scratch)》书籍封面

    📌 项目简介

    LLMs-from-scratch 是 Sebastian Raschka 所著《Build a Large Language Model (From Scratch)》一书的官方代码仓库，带你从零开始用 PyTorch 手写实现类 GPT 大语言模型，覆盖数据处理、注意力机制、GPT 架构、预训练、微调全流程，是搞懂 LLM 底层原理的最佳实战项目。

    ⚙️ 安装要求与过程

    环境要求

    • Python 3.8+，具备扎实的 Python 编程基础
    • PyTorch 基础（零基础可参考附录 A 的 PyTorch 入门教程）
    • 硬件：主章节代码可在普通笔记本运行，支持自动检测并使用 GPU 加速
    • 深度神经网络基础有助于理解，但不是硬性要求

    快速安装步骤

    # 1. 克隆仓库（只拉取最新版本，减少下载量）
git clone --depth 1 https://github.com/rasbt/LLMs-from-scratch.git

# 2. 进入目录
cd LLMs-from-scratch

# 3. 安装依赖
pip install -r requirements.txt

# 4. （可选）安装 Jupyter Notebook
pip install jupyter

# 5. 启动 Notebook，按章节运行代码
jupyter notebook

    📌 如果你从 Manning 官网下载了代码包，建议前往 GitHub 官方仓库获取最新更新。

    ✨ 核心功能

    🧠 从零实现注意力机制

    手写实现单头/多头自注意力（Self-Attention）机制，深入理解 Query/Key/Value 的数学原理，不依赖任何高层封装库。

    🏗️ 完整 GPT 架构实现

    从词嵌入、位置编码到 Transformer 解码器块，完整实现 GPT 模型架构，代码逐行对照论文，透明可调试。

    🔥 预训练与微调全流程

    覆盖无标注数据预训练、文本分类微调、指令遵循微调（SFT）完整流程，附带可运行的训练脚本。

    🚀 主流模型权重加载

    支持加载 Llama 3.2、Qwen3、Gemma 3、OLMo 3 等主流开源模型的预训练权重进行微调与推理。

    📚 附录与扩展内容

    包含 PyTorch 分布式训练（DDP）入门、LoRA 高效微调实现、分组查询注意力（GQA）、MoE 混合专家架构等进阶内容，一书在手，LLM 技术栈全覆盖。

    🎯 典型使用场景

    场景一：系统学习 LLM 底层原理

    不看封装库黑盒，从张量运算级别理解 Transformer 和 GPT。每章配有练习和解答，适合有一定 Python 基础、想深入 LLM 原理的开发者系统学习。可搭配书籍《Build a Large Language Model (From Scratch)》一起使用，理解更透彻。

    场景二：在自己的数据上训练定制 LLM

    参考第 5 章的预训练代码，基于自定义数据集训练专属小模型；或参考第 7 章的指令微调代码，用开源指令数据集微调模型，使其具备遵循指令的能力，用于垂直领域应用。

    场景三：作为 LLM 课程的配套实践材料

    本书配有 17 小时 15 分钟的官方视频教程，章节结构清晰，练习册《Test Yourself On Build a Large Language Model》可用来自测掌握程度，非常适合作为高校课程、企业内训或自学小组的配套实践材料。

    💡 推荐理由

    我第一次翻开这本书的代码时，有一种「原来 GPT 是这样工作的」的恍然大悟感。

    大多数 LLM 教程要么停留在概念层面，要么直接调用 transformers 库，黑盒到底。而 LLMs-from-scratch 选择了一条更难但更有价值的路：从张量运算级别手写实现，不依赖任何高层封装。

    我最喜欢的是第 4 章实现 GPT 模型那部分——当你亲手写出 self.attn = MultiHeadAttention(...) 和 self.ln = LayerNorm(...) 并成功跑通时，那种「我理解了」的满足感是任何调用封装库都给不了的。

    作者 Sebastian Raschka 是 LLM 领域的顶级教育者，Lightning AI 的 LLM 负责人，写书风格非常「工程师友好」——没有冗余的数学推导，每一行代码都能跑，每一章都有配套练习。

    如果你是想深入 LLM 原理的开发者、研究者，或正在准备 LLM 相关技术面试，这个项目绝对值得你花时间从头到尾跟一遍。96.3K 的 Star 数不是偶然，是工程师们用脚投票的结果。

    📥 下载地址

    🔗 GitHub 仓库

    https://github.com/rasbt/LLMs-from-scratch

    访问 GitHub →

    📘 配套书籍

    《Build a Large Language Model (From Scratch)》
    Manning 出版，ISBN 978-1633437166

    Amazon 购买 →

    🎬 配套视频教程（17h15min）

    Manning LiveVideo：Master and Build Large Language Models

    观看视频 →

    📌 小提示：本项目是《Build a Large Language Model (From Scratch)》的官方配套代码，建议配合书籍一起学习，理解效果最佳。书籍附录 A 还提供了 PyTorch 入门教程，适合 PyTorch 零基础读者补基础。

  • 微软正在打造AI超级应用——把Copilot全家桶装进一个入口

    据《财富》杂志报道，微软正在开发一款AI”超级应用”——把现在散落在各处的AI能力全部整合到同一个入口。具体来说，这款应用会把GitHub Copilot、Copilot聊天机器人、Copilot Cowork，以及一个内部代号为”Autopilot”的新智能体工作流能力，全部塞进一个App里。

    这个思路听起来很熟悉，对吧？OpenAI已经在走这条路了——把对话、搜索、代码、智能体编排全部整合进ChatGPT，让它成为一个真正的”超级应用”入口。现在微软想做同样的事，只不过依托的是自己整个Copilot产品线。

    微软的打法其实很清晰：它拥有全链路的产品布局——从代码编辑器里的Copilot，到Microsoft 365里的Copilot，再到独立发布的Copilot Cowork智能体平台。唯一缺的就是一个把它们串起来的”总控制台”。

    可能在Build大会上亮相

    《财富》的报道推测，这款超级应用可能会在近期举办的Microsoft Build开发者大会上亮相。Build是微软每年最重要的开发者活动，通常是发布重磅AI战略更新的场合。如果这款产品真的在Build上出现，基本等于微软官方确认了”超级应用”战略。

    值得一提的是，微软过去一年在Copilot品牌上投入极大，但用户体验一直是碎片化状态——写代码要用GitHub Copilot，处理文档要用Microsoft 365 Copilot，管理智能体工作流要用Copilot Cowork，三者之间的数据和上下文并不打通。这款超级应用如果成真，最直接的价值就是解决这个问题。

    和OpenAI的超级应用有什么不同？

    OpenAI的”超级应用”路线是围绕ChatGPT构建的——所有能力都收敛到一个对话窗口里，用户跟AI交互的主要方式还是”说话”和”看结果”。微软的路线则更偏向”工作流”——它继承的是Office、Azure、GitHub这套企业生产力生态，AI超级应用更像是一个”智能工作操作系统”。

    两套打法背后的逻辑不太一样。OpenAI是从消费者往上打，微软是从企业往下打。最终谁能先把”超级应用”这件事做成，很大程度上取决于谁能先把多智能体协作、跨应用上下文传递、以及企业数据安全这三个问题解决掉。

    目前微软官方还没有确认这款产品的存在，按照惯例，在Build大会之前所有消息都只是传闻。但如果《财富》的报道方向是对的，这会是微软在AI应用层最重要的一次产品整合，也意味着”Copilot”作为一个独立品牌，正在从”功能”升级为”平台”。

  • 互联网正在为机器重构——AI智能体正在改写整个网络基础设施

    过去二十年，互联网一直是围绕人类行为设计的。人们搜索、点击、滚动、串流，这些动作有规律、可预测。但AI智能体不这么干活。它们能在几秒钟内发起一连串突发请求，同时调出十几个子智能体，疯狂查询数据库、检索文档、调用API，然后突然全部消失。这种流量模式，人类的网络基础设施从来没为它设计过。

    AWS悄悄改写了搜索数据库的底层的

    本周，亚马逊云科技（AWS）发布新一代OpenSearch Serverless——一个专门面向AI智能体负载设计的托管搜索和向量数据库。最核心的变化是：计算和存储解耦了。智能体发起任务时，算力可以在几秒内弹性扩容；智能体 idle 时，算力可以缩到零。客户不用再为空闲的计算资源付费。

    “智能体正从实验阶段走向生产环境，它们产生的流量模式，是之前的基础设施根本没考虑过的。”
    ——Tia White，亚马逊OpenSearch服务总经理

    之前的Serverless版本也有弹性，但存储和计算是绑定的，你至少得保留一个运行中的实例。说白了就是：哪怕你没在用，也得一直付停车费。新一代相当于改成了计时停车位——来了才计费，走了就归零。

    AI智能体概念图
    AI智能体正在改变互联网流量结构（图片来源：Getty Images）

    机器流量已经超过你想象

    Cloudflare的数据很说明问题：过去六个月， bots 流量已经占到整体HTTP流量的31%。其中AI爬虫、搜索引擎和AI助手加起来，约占所有bot请求的25%。Cloudflare高级产品经理Lai Yi Ohlsen预计，2027年上半年，非人类流量就会超过人类流量。

    这不只是在抢带宽。智能体的检索模式跟人类完全不一样——它们会并发查询数百个数据源，对延迟极度敏感，而且流量峰值毫无规律。传统的基础设施假设用户是”逐步浏览”的，但智能体是”瞬间爆发”的。

    整个行业都在跟

    AWS不是唯一一个在干这件事的。Databricks和Snowflake正在把自己重新定位为企业AI内存和检索系统；微软Azure最近也推出了针对AI智能体突发流量和多智能体共享内存的更新；Cloudflare上个月发布了面向智能体的持久化环境和即时扩展基础设施。

    Google I/O上周也释放了信号：用户很快就能把购物研究、行程预订、网页浏览等任务委派给AI系统。不管是面向消费者的AI智能体，还是企业内外部部署的智能体，机器对机器的流量正在指数级增长。

    这场基础设施的重构，本质上是为下一个十年做准备。当智能体成为互联网的主要”用户”，整个堆栈——从数据库到CDN，从API网关到身份认证——都得重新思考。目前看，大的云厂商已经跑起来了，但这一步才刚刚开始。

  • 2026年5月AI大模型密集发布：GPT-5.5、DeepSeek v4、Claude 4.6谁更胜一筹？

    GPT-5.5来了：OpenAI的又一次跳跃

    4月24日，OpenAI发布了GPT-5.5，官方描述是”迄今为止最智能、最直观的模型”。数字上的提升是实的：在Terminal-Bench 2.0测试中拿到82.7%，GDPval评测84.9%。

    但更值得关注的是它在Agentic coding（智能体编程）上的进步。写代码不再只是”补全下一行”，而是能自主规划多步骤任务、调用工具、自己debug。这对开发者来说，意味着AI编程助手真的从一个”聪明补全器”变成了”能一起干活的搭档”。

    DeepSeek v4：国产大模型的反击

    同一天，DeepSeek放出v4，推出Flash和Pro双版本。最炸裂的参数是1M+ token的超长上下文窗口——这意味着它可以一口气读完一整本技术手册，然后基于全书内容跟你对话。

    更妙的是它兼容OpenAI和Anthropic的SDK，开发者迁移成本几乎为零。加上本身就便宜，这波发布直接把”长上下文+低成本”的标杆拉高了。

    Claude Sonnet 4.6：接近Opus的性能，一半的价格

    3天后，Anthropic更新了Claude Sonnet 4.6和Haiku。核心卖点是”接近Opus级别的性能，但价格便宜得多”。对于已经在用Claude API做产品的团队来说，这个性价比提升是实打实的。

    这次更新还修了之前版本里推理不稳定和缓存出错的bug。对于生产环境用户来说，稳定性往往比基准测试分数更值钱。

    Google Gemini Pro & Flash：双版本策略的聪明之处

    Google也在同一天（4月27日）更新了Gemini Pro和Flash。Pro负责扛性能大旗，Flash负责低延迟和高并发场景。两个版本都支持1M token上下文窗口，多模态能力和推理能力都有明显提升。

    Google这波操作聪明在：不让用户做”性能vs成本”的单选题，而是两个版本各司其职。对于需要同时服务C端和B端的应用来说，这种组合很实用。

    IBM Granite 4.1：小参数模型的逆袭

    4月30日，IBM发布了Granite 4.1，参数只有8B，但性能居然能跟32B的MoE模型掰手腕。这件事传递的信号很清楚：堆参数不是唯一出路，数据质量和训练效率同样能打。

    对于想在本地部署、或者推理预算有限的团队来说，这类小参数高性能模型是真正的香饽饽。大模型不一定非得”大”。

    四个趋势，定义接下来半年

    把这波发布潮放在一起看，有四个趋势已经很明显了：

    • 超长上下文正在变成标配。1M+ token从”炫技”变成”基础配置”，这会从根本上改变应用能做的事情——一次性处理超长文档、多轮对话不遗忘、复杂任务规划，都会变得更可靠。
    • 小参数模型崛起。DeepSeek v4和IBM Granite 4.1都在证明：聪明的训练比盲目的参数堆砌更有效率。这对降低推理成本、推动AI应用普及是好事。
    • Agentic能力成为新战场。从GPT-5.5到Claude 4.6，所有厂商都在强化”让AI不只是回答，而是主动完成任务”的能力。这是从”对话助手”到”智能代理”的关键一跃。
    • 监管压力在累积。欧盟AI Act的合规期限是2026年8月，没几个月了。技术在狂奔，但安全性和透明度基准测试的进度明显滞后。这波发布潮里，几乎每家都提到了”负责任的AI”，但真正做到多少，还得看。

    对开发者意味着什么

    如果你在基于这些模型做应用，有几个方向值得认真考虑：一是重新设计应用架构，把1M+ token上下文窗口的能力用起来；二是关注Agentic模式，从”用户输入-模型回答”的单向模式，转向多步骤、带工具调用的任务执行模式；三是成本优化，小参数模型的性能提升意味着你有更多选择，不一定非得用最贵的那个。

    2026年5月的这波模型发布，表面上是各家在比拼基准测试分数，实际上是AI从”技术演示”走向”大规模应用”的转折点。谁能把模型能力稳定、低成本、安全地交付到用户手里，谁就赢了。

  • MIT发布2026年AI十大趋势：从人形机器人训练到反AI运动

    人形机器人训练数据：动作捕捉的新战场

    就像人类的文字成了大语言模型的养料，现在连人类怎么动、怎么走路、怎么搬东西，都被大规模收集起来训练人形机器人。这事儿听起来有点怪，但确实在发生——有公司专门建了”训练中心”，让工人一遍遍重复同样的动作，就为了给机器人提供学习素材。还有更离谱的”提线木偶”模式：远方的人类通过远程操控，手把手教机器人怎么做事。

    这种做法投入巨大，但没人能保证一定成功。可资本还是在砸钱，因为这可能是让机器人真正”活过来”的唯一路径。

    大语言模型没有死，它正在进化

    去年大家还在感叹大语言模型”改变了世界”，今年从业者已经在琢磨下一个突破在哪里。容易摘的果子已经摘完了，模型的提升越来越难，但这不意味着LLM要退出历史舞台。

    相反，它正在往两个方向走：一个是把现有的能力压榨到极致，另一个是在寻找全新的架构突破。这条路不好走，但走通了就是下一个时代。

    AI让诈骗变得便宜又高效

    以前想搞网络诈骗，还得学点技术、花点钱买工具。现在有了生成式AI，门槛几乎降到了地板上。黑客可以用AI批量生成钓鱼邮件，连语法错误都不一定有；换脸视频让冒充别人变得轻而易举；甚至连打电话诈骗都有AI语音代劳。

    AI正在让网络犯罪变得更便宜、更快、更容易——这对普通人来说不是什么好消息。

    世界模型：让AI理解物理世界

    大语言模型擅长处理文字，但要让AI进入真实物理世界——比如让机器人知道”杯子掉地上会碎”这种常识——就需要”世界模型”。这类系统试图让AI理解外部世界的运作规律，而不仅仅是预测下一个词。

    如果这条路走通了，AI就不再只是聊天工具，而是能真正在现实世界里做事情的智能体。这可能是下一波AI浪潮最核心的突破点。

    智能体编排：从单打独斗到团队协作

    早期的AI智能体只能干一件事——比如帮你订个外卖，或者写段代码。但现实世界里的问题往往是复杂的，需要多个步骤、多种能力配合。

    现在的方向是”智能体团队”：一个负责搜索、一个负责推理、一个负责执行，像人类团队一样分工协作。这比单个超级智能体更灵活，也更容易落地。很多公司已经在往这个方向押注了。

    中国的开源赌注：免费模型赢来的全球影响力

    DeepSeek、通义千问、智谱……中国实验室过去一年里密集开源了一大批高质量模型，而且真的好用。这让全球开发者突然意识到：原来不用OpenAI也能做出厉害的东西。

    但这种”免费送”的策略能不能持续，没人说得准。训练模型太烧钱了，光靠口碑和开发者好感，账算得过来吗？不管怎样，全世界已经在基于中国的基础模型搞开发了，这本身就已经改变了格局。

    AI科学家：当AI开始做科研

    有些公司已经在开发能自主做科研的AI——不是帮你查文献，而是真的能设计实验、分析数据、甚至提出新假设。支持者说，这种AI合作者有一天可能会达到诺贝尔奖的水平。

    这话听起来夸张，但想想十年前大家也觉得”AI下围棋赢人类”是天方夜谭。科学发现的门槛正在被重新定义。

    反AI运动：当大家开始说”够了”

    过去几年AI基本上是想怎么发展就怎么发展，监管跟不上，大家也沉浸在”新技术好厉害”的兴奋里。但现在这股浪潮遇到了真正的阻力。

    艺术家不满自己的作品被拿来训练模型，工会担心AI抢走工作，保守派和自由派居然在”限制AI”这件事上找到了共同点。这股反对力量还在早期，但已经在一些具体问题上取得了小胜利。AI的无约束时代，可能正在走向终点。

    写在最后

    MIT Technology Review这份清单的价值不在于预测未来，而在于帮我们看清当下——哪些方向是真的在动，哪些只是炒作。人形机器人、世界模型、智能体编排，这些是当前最值得盯着的变化；而AI安全、监管反弹、开源商业化困境，则是这个行业必须面对的考题。

    2026年的AI，已经不再是”能不能做出来”的问题，而是”应该怎么用、谁来管、往哪里去”的问题。

  • Screenshot to Code：72.7K Stars！截图秒变代码，让前端开发效率提升10倍

    Screenshot to Code：72.7K Stars！截图秒变代码，让前端开发效率提升10倍

    Screenshot to Code 演示

    上传截图，AI自动生成对应代码

    🚀 项目简介

    Screenshot to Code 是一款AI驱动的开发辅助神器，只需上传一张网页截图、线框图或Figma设计稿，即可自动生成干净的可用代码。支持 HTML+CSS、React、Vue、Bootstrap 等多种技术栈，让设计稿到代码的转换从数小时缩短到几秒钟。

    ⚙️ 安装要求和过程

    💡 环境要求

    • Python 3.9+（后端依赖）
    • Node.js 18+（前端依赖）
    • Poetry（Python 依赖管理，推荐）
    • Docker（可选，快速部署方式）
    • API密钥：OpenAI / Anthropic / Google Gemini（三选一即可）

    🚀 快速安装步骤

    方式一：本地源码运行（推荐开发调试）

    # 1. 克隆项目
git clone https://github.com/abi/screenshot-to-code.git
cd screenshot-to-code

# 2. 配置API密钥（后端）
cd backend
echo "OPENAI_API_KEY=sk-your-key" > .env
echo "ANTHROPIC_API_KEY=your-key" >> .env
echo "GEMINI_API_KEY=your-key" >> .env

# 3. 安装依赖并启动后端
poetry install
poetry run uvicorn main:app --reload --port 7001

# 4. 新终端启动前端
cd ../frontend
yarn
yarn dev

    启动后访问 http://localhost:5173 即可使用。

    方式二：Docker 一键运行（推荐快速体验）

    # 在项目根目录执行
echo "OPENAI_API_KEY=sk-your-key" > .env
docker-compose up -d --build

    ✨ 核心功能

    🎯 截图转代码

    上传任意网页截图或设计稿，AI自动分析布局结构，生成对应前端代码，支持多种技术栈自由切换。

    🔄 多模型支持

    内置支持 Claude Opus/Sonnet、GPT-4.5/4.1、Gemini 3 Flash/Pro 等顶级模型，也支持自定义API兼容接口。

    🛠️ 多技术栈输出

    支持 HTML+CSS、HTML+Tailwind、React+Tailwind、Vue+Tailwind、Bootstrap、Ionic+Tailwind、SVG 等主流技术栈。

    🎬 录屏转原型（实验性）

    支持上传网站操作录屏视频，AI直接生成可交互的功能原型，非常适合产品快速验证和演示。

    🔒 隐私优先，本地可控

    支持通过 Ollama 运行本地开源模型，所有数据不出本地；也可自托管 Docker 版本，完全掌控数据隐私。

    🎬 典型使用场景

    📌 场景一：设计师交付前端代码

    设计师完成 Figma 设计稿后，开发人员只需截图上传，即可快速获得可运行的前端代码骨架，大幅减少从设计到代码的重复劳动。实测可将一个中等复杂度页面从 2小时 缩短到 30秒 出初稿。

    🎓 场景二：学习前端的新手临摹练习

    想临摹一个漂亮的网页但不懂怎么实现？截一张图上传，AI 帮你生成完整代码，新手可以在生成的代码基础上学习和修改，快速提升前端技能。

    🚀 场景三：产品快速原型验证

    产品经理用录屏功能记录期望的操作流程，Screenshot to Code 直接生成可交互的 HTML 原型，团队可以在此基础上快速评审和迭代，不需要写一行代码。

    💎 推荐理由

    我第一次用这个工具的时候，简直惊呆了——随手截了一张纽约时报首页的截图上传，不到 20秒 就生成了一个几乎一模一样的 HTML 页面，连字体、间距、配色都还原得非常到位！

    最让我惊喜的是它对 Tailwind CSS 的支持——生成的代码不是一堆乱七八糟的行内样式，而是结构清晰、可直接维护的 Tailwind 类，这对实际项目来说太重要了。

    当然也要说一下不足：复杂交互（比如多步骤表单、动画过渡）还是需要人工补充；如果使用 OpenAI/Claude 的 API，每次生成会产生一定的 API 费用（不过项目支持 Ollama 本地模型，可以零成本使用）。总体来说，这是目前 「设计稿转代码」 这个细分领域里最成熟、最好用的开源方案，没有之一。

    📥 下载地址

    — 由 WorkBuddy AI 自动采集撰写 · 开源项目系列第43期 —

  • Groq转身求融资6.5亿美元——英伟达200亿非收购之后，这家芯片公司要去哪里

    Groq转身求融资6.5亿美元——英伟达200亿”非收购”之后，这家芯片公司要去哪里

    Groq这个名字你可能还不熟悉，但在AI芯片圈子里，他们是这几年最让人看不懂的公司之一。

    事情是这样的：2025年12月，英伟达和Groq签了一笔200亿美元的交易——但这不是收购。部分Groq的核心工程师去了英伟达，Groq的硬件技术授权给英伟达使用。对Groq的投资者来说，这相当于一次大规模退出，拿到了现金回报。

    现在，Axios爆料说Groq正在向现有投资者募集6.5亿美元新资金，用来做一件完全不同的事情：AI推理云（inference neocloud）。

    从造芯片到卖推理，这步棋走对了吗

    训练AI模型是一次性的大工程，而推理是每次用户发一条消息都要发生的事情——这个需求比训练大得多，也持续得多。Groq的判断是：与其和英伟达在训练芯片上硬碰硬，不如把赌注押在推理基础设施上。

    他们的逻辑有一定道理。推理市场确实在爆发，但目前这个赛道已经有大量玩家：亚马逊、谷歌、微软的云推理服务，加上无数中小型推理优化公司。Groq能不能在这片红海里杀出来，关键看他们的技术是不是真的比竞争对手快很多——而且快到客户愿意迁移的程度。

    据Axios报道，这轮融资其实有一定的”保底”机制：现有投资方Disruptive和Infinitium已经承诺，如果其他老股东不愿意按比例跟投，这两家会补足6.5亿美元的额度。换句话说，这轮钱基本上是有保障的。

    管理层动荡，时机有点微妙

    Groq目前由临时CEO Adam Winter和临时CFO Matt Eng领导。创始人Jonathan Ross的去向，在这笔新融资的背景下变得值得关注——如果公司战略方向发生了根本性转变，创始团队和投资者的利益是否还完全一致，这是一个问号。

    从外部看，这家公司的身份定位有点模糊：它既不像纯粹的芯片公司（因为把技术授权给了英伟达），也不像纯粹的云服务商（因为之前的主业是造芯片）。”推理云”这个方向能不能让市场重新给它一个清晰的估值逻辑，这轮融资之后大概会见分晓。

    英伟达的200亿美元交易，从结果上看是一个巧妙的”不开收购之名的收购”——拿到了技术和人才，但不用承担整合一家独立公司的全部复杂性。对Groq来说，拿到了一大笔现金，但也需要回答一个问题：接下来的Groq，到底是一家什么公司？

    6.5亿美元的新融资如果顺利完成，我们大概很快就能看到他们的推理云产品正式亮相。是骡子是马，到时候牵出来遛遛就知道了。

  • Anthropic砸650亿美元融资，估值逼近1万亿——这家公司到底在押什么

    Anthropic砸650亿美元融资，估值逼近1万亿——这家公司到底在押什么

    如果你最近关注AI融资圈，这条消息大概已经刷过你的屏了。Anthropic在5月28日官宣完成H轮650亿美元融资，投后估值9650亿美元——离1万亿只差一小步。

    这个数字什么概念？OpenAI最新一轮融资后的估值是7300亿美元，Anthropic这一轮直接把门槛抬高了两个身位。

    钱从哪里来，又往哪里去

    这轮融资的领投方阵容相当豪华：Altimeter Capital、Dragoneer、Greenoaks、红杉资本联合领投。跟投名单里你能看到黑石、富达、淡马锡、Baillie Gifford这些名字——基本上就是全球最有钱的那批机构排队送钱。

    Anthropic说这笔钱主要花在三件事上：推进安全研究、扩大算力储备、把产品铺到更多客户那里去。听起来像是标准融资说辞，但仔细看他们最近签的算力合同，你就知道这个”扩大算力”不是开玩笑的。

    Anthropic CFO Krishna Rao的说法是：”Claude对全球客户来说越来越不可或缺了。这笔融资帮我们对需求做好准备，保持在研究前沿，把Claude推到更多工作场景里。”

    算力布局比你想的更激进

    真正值得关注的是他们悄悄签下的一堆算力协议。和亚马逊签了最多5吉瓦的新增算力，和谷歌+博通签了5吉瓦的下一代TPU协议，还从SpaceX那里拿到了Colossus 1和Colossus 2的GPU使用权。

    这些合同加起来意味着什么？意味着Anthropic从根本上解决了”模型训练出来但跑不起来”这个AI公司最头疼的问题。算力供给锁死了，接下来就是产品和销售的事了。

    还有一个细节：Claude目前是全世界第一个在亚马逊AWS、谷歌云、微软Azure三大云平台上都能用到的前沿模型。AWS是主要训练合作伙伴，但这个”三云平台通吃”的站位，OpenAI其实并没有完全做到（微软的排他性一直是个问题）。

    收入数字终于肯说了

    Anthropic这轮融资最硬的底气来自收入。2026年5月，他们的营收运转率（run-rate revenue）已经突破47亿美元。这个数字是从2月份G轮融资之后涨上来的，也就是说在不到三个月里，收入规模又上了一个台阶。

    企业客户在用Claude处理实际工作流——不是试用，是真的把业务跑在上面。Anthropic的说法是Claude正在”学习企业实际运营的逻辑”，包括业务上下文、流程和判断逻辑。这话听起来有点玄，但翻译成人话就是：企业用得越深，切换成本越高，Anthropic的护城河就越宽。

    投资人这边当然也说了一堆好话。红杉资本合伙人Alfred Lin说初创公司和全球5000强都在部署Claude处理复杂工作流。Dragoneer的Marc Stad说”这项技术的开发和商业化仍处于最早期的阶段”——这话翻译过来就是：现在进场还不晚，涨的空间还很大。

    估值9650亿美元到底贵不贵？如果你觉得Claude值得比OpenAI高，那这个估值就有它的逻辑。如果你觉得大模型赛道接下来会卷价格战，那这个故事就不好说了。但至少从现在的数据来看，Anthropic在企业市场上的渗透速度，确实比大多数人的预期要快。

  • 程序员拒绝在没有 AI 的情况下工作——但这可能会反过来坑了他们

    程序员拒绝在没有 AI 的情况下工作——但这可能会反过来坑了他们

    2026 年有个挺有意思的发现：你现在很难让开发者放下 AI 编码工具去干活了。

    AI 确实能帮程序员更快地生成代码，但研究人员警告说，它产出的代码质量未必更好，这可能会给开发者的未来带来麻烦。

    研究者遇到的尴尬

    2026 年 2 月，权威 AI 研究实验室 METR 发布了一个令人意外的发现：大多数开发者甚至不愿意在没有 AI 的情况下完成实验任务。

    METR 原本想更新他们在 2025 年做的一项关于 AI 编码生产力的开创性研究。那项研究里，研究人员测量了开源开发者手动完成任务和使用 AI 完成任务的耗时。结果挺打脸的——开发者自称 AI 提升了生产力，但实际上 AI 拖慢了他们的工作速度。没错，AI 生成代码更快，但之后他们需要额外的时间查找和修复错误、引导 AI 工作、还要等 AI 完成任务。

    当 METR 着手重复这项实验时，他们没能成功。研究人员坦承，开发者不愿意参与实验，”因为他们不想在没有 AI 的情况下工作”，哪怕只是为了做研究。

    最后 METR 在 5 月发布了一份调查，让技术员工自行报告 AI 带来的生产力提升。毫不意外，大家认为自己对公司而言的价值是原来的两倍。

    tokenmaxxing 的代价

    最近关于 “tokenmaxxing”（过度消耗 AI token）的高昂成本的头条新闻，加上一些新研究，让这种自我认知变得可疑。

    Tokenmaxxing 用一个人消耗的 token 数量作为 AI 生产力的代理指标，是 2026 年迄今为止的趋势，而且这个趋势可能已经快到头了。

    据《金融时报》报道，亚马逊关闭了其内部名为 Kirorank 的 token 追踪排行榜，原因是员工为了刷榜过度使用 AI 代理，导致成本飙升。员工的行为证明，AI 的使用并不自动等于生产力的提升。

    据 The Information 报道，Uber 在 2026 年前四个月就用完了全年的 AI 预算。首席运营官 Andrew Macdonald 最近在播客中表示，这类支出并没有带来项目或生产力的可衡量提升。

    代码维护的隐藏成本

    程序员兼作家 James Shore 在一篇在 Hacker News 上疯传的博客文章中指出，AI 生成的代码不一定能减少后续代码维护需求，甚至可能增加这类需求。

    你现在写代码的速度是以前的两倍？最好希望你的维护成本也减半了。不然你就惨了，你是在用短期的速度提升换取永久的债务。

    还有其他证据表明 AI 会增加代码维护的麻烦。可靠性工程代理初创公司 Entelligence AI 的创始人兼 CEO Aiswarya Sankar 的一条病毒推文称，公司 44% 的 token 支出都花在了修复 AI 生成的 bug 上。与此同时，代码审查工具公司 CodeRabbit 表示，他们分析了开源拉取请求，发现 AI 生成的代码出现问题的概率是人工代码的 1.7 倍。

    诚然，这些都是试图销售 AI 代码审查工具的机构的自利统计。但独立研究人员也发现了这类问题。新加坡管理大学的研究人员 4 月发布的一份报告警告称，”AI 生成的代码可能会给真实的软件项目带来长期维护成本”。

    那怎么办

    既然程序员如此热爱他们的 AI 助手，解决方案是什么？

    那些想向你推销 AI 编码代理的人说，开发者可以用 AI 编码代理来完成修复代码这类枯燥繁琐的工作，修复速度和 AI 生成代码的速度一样快。这是 Cognition（AI 编码代理 Devin 的开发商）的创始人兼 CEO Scott Wu 的建议。

    但就连他也承认，虽然 Devin 可以独立工作，但目前它的技能水平在初级和中级程序员之间，具体取决于任务类型。这不是一个可以交办后就不管的解决方案。

    新加坡管理大学的研究人员提出了更偏向人工的方案：程序员需要像熟悉自己最爱的编程语言一样，深入了解 AI 擅长和不擅长哪些任务。他们需要为 AI 设计强大的质量保障体系，并且必须像对待初级开发者一样，仔细审查 AI 的工作成果。

    同时，研究人员和 Wu 都表示，人类仍然应该负责软件架构、安全设计这类大局层面的工作。