即刻App年轻人的同好社区
下载
App内打开
小陈ai
367关注30被关注0夸夸
小陈ai
10天前

Kostja: 全网最爱Lovable的博主来了 🏷️省流不看版: 5 月 13 日上线了内置的 SEO/GEO 功能。 给你最残酷、最现实、最一针见血、最不拐弯抹角、最不藏着掖着、最扎心、最直白的大实话—— Lovable 这次更新本质就一件事:让 AI 建的应用能被找到。技术栈从 CSR 切到 SSR,不是加渲染层,是换框架。Semrush 的实时搜索数据直接焊进 agent 对话流——你问关键词,它查完直接帮你建页面,中间不跳出、不等、不切工具。最狠的设计是把 AI 可发现性跟传统 SEO 摆到同一个优先级,不是子集,是平行。 📃详情: 1️⃣先拆技术栈变更。以前 Lovable 生成的 app 默认是 React+Vite,纯客户端渲染(CSR)。HTML 就是一个 `<div id="root"></div>`,JS 加载完后才渲染内容。这对搜索引擎是 9 倍延迟的问题——但对 AI crawler(GPTBot、ClaudeBot、PerplexityBot)是更严重的问题:它们不执行 JavaScript,纯 CSR 输出的应用对它们来说就是空白页。 现在默认切到了 TanStack Start 做服务端渲染。这不是 Next.js。TanStack Start 是 Tanner Linsley(TanStack Query/Table/Router 的作者)做的全栈 SSR 框架,核心差异是 CSR-first——首请求用 SSR 返回完整 HTML,之后所有页面导航切回客户端 SPA 模式,不再经过服务端。Next.js 走的是反方向,默认一切在服务端,客户端交互需要显式 opt-in。 Lovable 选 TanStack Start 而不是 Next.js 的具体技术原因,比"SEO 需要 SSR"要细得多。第一,Lovable 用户生成的主流是 SaaS dashboard、后台管理、交互式应用,不是博客或电商首页。TanStack Start 的 CSR-first+按需 SSR 模型天然匹配这类产品——首屏有完整 HTML,使用过程中的页面切换不经过服务端。第二,TanStack Router 的编译时类型安全对 AI agent 生成的代码极其友好——agent 写的路由代码在编译时就能校验参数类型,运行时会少很多 bug。对一个 agent 写代码的平台来说,编译时能抓到的错误不会进用户生产环境,这是关键优势。第三,部署不绑定 Vercel——底层 Nitro 运行时支持 Node、Cloudflare Workers、Deno、Bun、AWS Lambda。第四,TanStack Query 生态兼容——如果用户在做数据密集的应用,数据层的 SSR 流式传输是开箱即用的。第五,Vite 的冷启动 300-500ms,远快于 Turbopack 的 2-5 秒——Lovable 的实时预览依赖快速热更新,这个差异在频繁修改-预览的循环里会很大。 有一些数据可以感受差距。TanStack 团队今年 3 月发布的性能基准:吞吐量从 427 req/s 优化到 2,357 req/s(5.5 倍),平均延迟从 424ms 降到 43ms(9.9 倍),p99 延迟从 6,558ms 降到 928ms(7.1 倍)。第三方基准(Platformatic,同等电商应用,无缓存)里,TanStack Start 的吞吐量和成功率(100%)也领先于 Next.js v16(约 64% 成功率 at 1K req/s)。 老应用的处理方式也值得一提:不迁移到 TanStack Start,而是通过预渲染在构建时生成静态 HTML 快照。文档明确写"无需 opt-in、无需迁移、自动生效、免费"。但预渲染是静态快照——内容更新需要重新构建——不像 SSR 是每次请求动态生成。 2️⃣再说审查工具本身。入口在项目内的 Services → SEO & AI search,不是独立产品。审查按触发条件分三层:Code-only(任何项目,含未发布的——检查 metadata、OG、结构化数据、索引标签)、Preview(有可访问预览时——检查首页可达性、robots.txt、sitemap.xml、llms.txt)、Published(线上有一一检查 Lighthouse 性能、无障碍、移动端、AI Markdown 渲染)。设计上的关键决策是让 SEO 检查前移到开发阶段——不要求你先发布再发现问题,类似于 linting 而非事后审计。 15 个检查类别覆盖从索引到无障碍的全链路。值得注意的设计细节:结构化数据检查有条件豁免——文档写"utility apps and dashboards"可以跳过,但判断逻辑未透明化。Markdown 渲染检查是仅正向的——不打分不评级,二元确认 Lovable 是否在提供 AI 可读的 Markdown 输出版本。审查不会自动重跑——用户改代码后面板可能显示旧数据,但会明确告知当前结果是否仍对应最新代码。修复消耗已有 build credit,不新增费用。 四档严重度分级也有讲究。Red X 不是一般 SEO 工具那种过度标红——只限定在"能有效隐藏你站点"的灾难级问题(全站 noindex、robots.txt 禁爬、X-Robots-Tag: noindex header)。Amber triangle 是显著影响但非灾难(重复标题、缺 canonical)。Blue lightbulb 是锦上添花(弱的 meta description)。另有 Ignored 状态让用户显式忽略特定问题,可恢复。 Google Search Console 的集成深度也超出常见 SaaS 产品的"粘贴一段代码"模式——连接、验证、提交 sitemap 三步都在聊天界面内完成,不需要跳出到 Google 控制台。 现在说最核心的一个信号:AI readiness 被设计为独立类别,不是 SEO 的子集。检查 llms.txt 和 Markdown 渲染的逻辑与检查 robots.txt 和 sitemap 的逻辑是平行的。这说明 Lovable 把 AI 可发现性视为与传统搜索同等重要的一级问题。但检查深度确实还浅——llms.txt 只查存在性,Markdown 只查是否开通,没有涉及内容是否被 AI 引用、引用片段准确性、结构化数据对 AI 的实体理解贡献。这是一个正确的方向判断,但实现还在早期。 3️⃣最后说 Semrush 集成。这不是挂个链接或加个面板——是平台级的一方集成,直接焊在 agent 的 tool set 里,不属于 Lovable 标准的 App Connectors(运行时)或 Chat Connectors/MCP(构建时)体系。两层鉴权:Basic 层用 Lovable 平台级 API key,用户完全看不见密钥,不需要自己的 Semrush 账号。Deep 层支持 OAuth 2.0 接入用户自己的 Semrush 订阅,agent 可以在用户已有的权限范围内操作项目追踪和历史数据。 Semrush 通过 API 暴露的数据规模:280 亿关键词、43 万亿外链、8.08 亿域名,覆盖 32 个地区。调用发生在 Lovable 服务端,不是客户端。Agent 不只是调 API 然后展示结果——落地页的对话流 demo 展示了关键能力:用户问"我该打什么关键词",agent 查完数据返回"vibe coding 每月一万两千次搜索,你没排上。要不要我给你建个页面?"用户说好,agent 就建好了。发现→判断→提议→执行,在一个对话里闭环。纯 API dashboard 做不到这个。 4️⃣定价也克制。审查免费,修复消耗已有 build credit,Semrush 数据到 2026 年 8 月 15 日前免费。没有一个新增收费项。策略意图是建立"建站等于默认可发现"的心智,而不是从 SEO 功能上直接变现。 5️⃣整体看下来,这次发布最核心的几个信号。第一,SSR 正在成为 AI 建站工具的默认要求,纯 CSR 输出的工具在 2026 年的搜索和 AI 爬虫环境里会越来越被动。第二,"建完即被找到"可能成为这个品类的标准承诺——过去 SEO 是建完后的额外工作,Lovable 把它变成了基础设施级别的默认能力。第三,搜索数据会成为 AI 建站工具的基础能力而非附加功能——Semrush 不是 widget,是挂到核心对话流里。未来的 AI 建站工具如果连搜索数据都嵌不进去,就不是完整的构建平台。

00
小陈ai
26天前

阑夕ོ: GPT-Image-2的能力边界真是深不可测,这是它的字体设计表现,适用于各种海报印刷,这活儿完全不需要初级美工来干了。 最早的提示词出自推友小小东,因为有点过长,我做了JSON化的修剪,主题在「用户输入」部分填写就行,个性化的创意或者倾向则可在语境、情绪这两行塞入自己的想法,没有的话空着也行。 { "任务": "生成一张基于词语含义进行视觉转译的高级概念海报,而不是普通插画、字效海报或简单文字排版。", "画面比例": "3:4", "用户输入": { "核心文字_单词_词组_字母": "", "文字语言": "", "可选补充语境": "", "可选情绪倾向": "", "可选禁用元素": "", "是否允许辅助文字": false, "辅助文字要求": "仅在能直接深化主题、补充语境或增强概念表达时允许出现。严禁随机署名、编号、坐标、口号、假出版信息或装饰性小字。" }, "语义理解": { "生成前必须先理解": true, "分析重点": [ "输入词语最核心的含义", "词语的情绪气质,如冷静、压迫、温柔、危险、纯真、暴烈、克制、疏离、希望、毁灭、浪漫、孤独、秩序、混乱、沉默、对抗、空虚、信念、欲望等", "词语是否包含反差、悖论、双重含义、社会性、哲学性、情感张力或象征意味", "最适合表达词义的视觉关系,如人物与人物、人物与物体、物体与物体、主体与空间、主体与文字、尺度反差、距离关系、动作瞬间、对峙关系、献出关系、遮挡关系、失衡关系、依附关系、侵入关系等" ], "表达规则": "抽象词语必须通过具体视觉对象、动作和空间关系承载;具体词语不能只做字面插图,而要通过关系、尺度、构图和氛围获得更深层含义。" }, "构图机制": { "核心结构": "极简主场景 + 清晰承载面 + 关键演绎主体 + 巨型文字骨架", "承载面": { "必须出现": true, "描述": "画面中应有明确的横向承载结构,如舞台、土地、台基、坡面、切面、地平线、平台、表层、底座或简化场域。它不是背景装饰,而是让角色和物体真正站住的空间基础。", "位置": "通常位于画面下部、中下部,或作为横向结构贯穿画面,形成稳定感。" }, "演绎主体": { "数量": "1到3个关键角色、人物或核心物体", "描述": "主体必须通过姿态、朝向、距离、动作、对峙、给予、接触、等待、穿越、凝视、阻隔等关系演绎词语含义。宁可少而准,不要多而杂。" }, "主视觉文字": { "必须出现": true, "描述": "用户输入的核心文字必须以巨大、清晰、强识别度的方式出现,成为画面的主视觉骨架,而不是普通标题。", "功能": [ "背景墙", "视觉压力面", "建筑块", "空间屏障", "象征场", "秩序边界", "情绪载体" ] }, "文字嵌入": { "必须实现": true, "描述": "文字必须真正参与构图,成为空间的一部分,并与图像、主体、承载面和留白相互咬合。", "实现方式": [ "主体站在文字前方,形成清晰前后层次", "主体嵌入文字内部空间", "文字成为背景墙、屏障、舞台后景、结构体或叙事容器", "角色动作与文字产生直接关系", "文字局部被切割、遮挡、穿越、借位、占据或层叠", "文字、主体、留白和承载面共同构成完整视觉句子" ], "禁止": "文字不能漂浮在背景上,也不能像后期贴字。" } }, "画面表达": { "原则": [ "极简但不空洞", "概念强但不故弄玄虚", "有隐喻但不能完全看不懂", "有戏剧性但不花哨、不拥挤、不廉价", "观众一眼能感受到词语如何被视觉化", "画面像一个高度提炼的视觉观点,而不是元素拼凑", "若词语包含冲突、反差、荒诞、纯真与暴力并置、秩序与失控并置、柔软与坚硬并置,应通过画面关系强化张力", "若词语偏诗意、记忆、哲思或情感沉淀,应更克制、含蓄,依赖留白与关系,而不是花哨特效" ] }, "色彩系统": { "整体要求": "顶级设计师式的克制配色,避免土气、花哨、廉价和商业模板感。", "颜色数量": "通常控制在2到4种主色关系内", "推荐结构": [ "一个强主色", "一个纸感浅色或低彩中性色", "一个深色支撑色", "一个极少量强调色" ], "规则": [ "配色必须服务于词义与情绪", "可以高对比,但必须高级、干净、克制", "优先使用纸张印刷感、展览海报感、艺术出版感的配色系统", "避免廉价渐变、无意义彩虹色、俗艳霓虹、过多饱和色混用、脏浊互撞、随意补色堆叠", "色彩应体现冷暖、轻重、软硬、压迫感或呼吸感等情绪判断", "整体必须高级、现代、克制、果断,不土、不俗、不乱" ] }, "视觉风格": { "描述": "高级图形艺术海报,具有强烈平面设计感和印刷品气质。", "允许质感": [ "克制拼贴感", "石版印刷感", "丝网印刷感", "版画感", "纸张颗粒", "轻微噪点", "克制材质纹理" ], "要求": [ "强烈平面设计感", "强整体性", "印刷海报气质", "收藏级、展览级、传播级完成度", "不能像普通插画封面", "不能像电商海报", "不能像廉价模板", "所有细节都应围绕少而精、准而狠展开" ] }, "文字系统": { "主标题": { "必须出现": true, "内容": "使用用户输入的核心文字作为主视觉标题", "规则": [ "中文必须成为构图的一部分,而不是普通排版标题", "文字应巨大、清晰、强势、具有结构感", "文字必须像从画面内部生长出来,与图像、空间和承载面形成整体" ] }, "辅助文字": { "默认允许": false, "允许时规则": [ "必须与主题直接相关", "必须深化词义、补充语境或增强概念", "必须克制、少量、巧妙", "严禁无意义假署名、假编号、假说明、随机短句、随机数字、随机出版信息、随机坐标或装饰性小字" ] } }, "负面提示词": [ "普通插画", "简单字效", "文字贴在背景上", "文字与图像分离", "模板海报", "廉价商业海报", "电商风格", "构图拥挤", "随机装饰元素", "无意义小字", "假署名", "假编号", "假坐标", "随机口号", "无关物体", "颜色杂乱", "廉价霓虹", "彩虹配色", "低级渐变", "特效过度", "画面失去秩序", "浅层字面插图" ], "最终目标": { "描述": "生成一张高级、极简、强概念、强识别、强传播、强完成度的单张海报。", "必须达到": [ "一眼有冲击", "二眼能读懂", "三眼觉得巧妙", "图与字高度咬合", "承载面、角色、文字、色彩形成统一系统", "真正把用户输入词语视觉化,而不是插图化" ] } }

00
小陈ai
1月前

莫尔索: 即使已经有十几家产品了,但仔细想想 sandbox 这个赛道,还是有的做,毕竟不同的任务负载对Agent Runtime要求差异蛮大的: 1. All-in-One:集成多类工具的一站式运行环境镜像,能满足 AI Agent 多场景协同任务的高效执行需求。 2. Code:预装主流编译器与代码编辑器的专用镜像,提供安全隔离的代码编译、运行及调试环境。 3. Browser:内置无图形界面的浏览器引擎与操控 API 的镜像,适用于网页自动化测试、数据爬取等浏览器相关任务。 4. Computer:标准 Linux 桌面/终端,提供完整的 Linux 操作系统环境,支持标准 Shell 命令与桌面交互操作。 实验:实验性沙箱环境,用于集成与测试前沿或社区驱动的 Agent 框架与运行时(如 OpenCode、OpenClaw 等),支持快速验证新架构、新交互模式与新能力编排机制,可能存在功能变动或不稳定特性。 5. R2E 强化学习:R2E 强化学习环境子集,提供 R2E (Request-to-Execution) 核心任务环境,用于轻量化评估 Agent 在特定场景下的执行与反馈能力。 6. WebArena:Web 交互评测环境,基于 WebArena 基准构建的真实网站与任务场景,提供带有 GUI 的完整浏览器操作界面,用于评估 Agent 在复杂网页浏览、信息检索与多步 GUI 操作任务中的综合能力。 7. SWE-bench:专为评估 AI 模型修复软件工程代码缺陷的能力提供标准化测试环境。 8 . 下一家 sandbox 产品来定义

00