即刻App年轻人的同好社区
下载
置顶以前写给人看的文章，现在写给Agent看的Skills
把上次自己的网站的构建方式m.okjike.com泛化成更通用的网站构建模版了👇
给 Cursor / Claude 装了个 SEO + 页面技能包，用下来挺香的
最近在用 Cursor 做站，发现让 AI 写 landing page、做 sitemap、写定价页的时候，经常要自己先讲一堆背景和规则，不然输出就很泛、很水。
后来就做了这个技能包：把 SEO 和页面相关的东西拆成 64 个「技能」，让 AI 按任务自动选对应的 skill，输出会专业很多。
———
先说 SEO 这块
Skills 本质就是给 AI 看的 markdown，每个 skill 里有一套流程和最佳实践，AI 会按这个来干活，而不是自己瞎猜。
推荐顺序是：Technical → On-Page → Content → Off-Page，一层层往上做。
技术 SEO：robots.txt、sitemap、canonical、索引、爬取、IndexNow 这些。比如你说「帮我配置 robots.txt，加上 AI 爬虫规则」「帮我优化 sitemap」「修复 canonical 和重复内容」「解决 Search Console 的索引问题」「给 Bing 上 IndexNow」，AI 会按对应 skill 来，不会乱来。
On-Page：meta 标签、标题、描述、hreflang、结构化数据、内链、URL 结构、标题层级（H1–H6）。你说「优化 meta 和标题」「加 schema 做 rich results」「审计内链结构」「修复 H1–H6 结构」，AI 会按 skill 里的最佳实践来。
Content：关键词研究、搜索意图、内容策略、pillar 和 cluster 页。Off-Page：外链建设、反链分析、有毒链接。从技术到内容到外链，一条龙。
———
再说页面创建
24 种页面类型都拆好了，按用途分：品牌、SEO、营销、合规、工具。
品牌：首页、关于、联系
SEO：功能页、词汇表、博客、资源、FAQ、API 介绍页
营销：定价、产品、服务、分类页、客户案例、联盟计划、媒体 Kit
合规：隐私、条款、Cookie、退款、配送
工具：404、招聘
每种页面都有对应的 skill，结构、话术、转化点都会更靠谱。比如你说「帮我写个定价页」「写个 About 页」「做个高转化的 FAQ」「写个联盟计划落地页」「写个 API 介绍页」，AI 会按对应 skill 来写。
还有 Components：导航、footer、hero、TOC、logo、trust badges、testimonials、CTA、newsletter 表单。你说「设计一个带 SEO 的导航」「优化 footer」「设计 hero 区域」，AI 会按 skill 来。
———
Project Context：让输出更贴合你的项目
README 里有一句：Without context, AI outputs stay generic。所以项目里带了一个 product-marketing-context.md 模板，填好之后 AI 会按你的产品来写，而不是通用话术。
模板里主要这几块：
产品概览：一句话描述、品类、商业模式、定价
定位陈述：For [谁] who [需求]，our [产品] is a [品类] that [价值]，Unlike [竞品]，we [差异] because [理由]
价值主张：核心卖点、关键信息、数据/案例
目标用户：谁、行业、要解决的问题、痛点、购买动机
现有网站：URL、技术栈、当前状态、核心页面
关键词：主词、次词、长尾、搜索意图
竞品：直接竞品、替代方案、差异化、可打的缺口
品牌调性：语气、用词偏好、要避免的词
建议先填 1、2、4、8 这几块，后面有数据再补 5、6、7。模板要定期更新，过期的 context 会让输出变差。
装好 skills 之后，把模板拷到 .cursor/product-marketing-context.md（Claude Code 用 .claude/），AI 会自动读，不用每次在对话里重复说。
———
怎么装
一行命令：
npx skills add kostja94/marketing-skills
装完直接用，不用额外配置。想只装某几个 skill 也行：
npx skills add kostja94/marketing-skills --skill seo-technical-robots pages-pricing
想看有哪些 skill：
npx skills add kostja94/marketing-skills --list
模板可以这样拿：
curl -o .cursor/product-marketing-context.md raw.githubusercontent.com
———
用下来啥感觉
以前让 AI 写 landing page，经常要自己补「要有 hero、social proof、objection handling」这些。现在直接说「帮我写个定价页」，它会按 skill 里的结构来，省不少口舌。
SEO 也是，以前要自己讲「sitemap 要这样那样」「canonical 要这样处理」，现在说「帮我优化 sitemap」「修复 canonical」，AI 会按 skill 里的最佳实践来，少踩很多坑。
填了 Project Context 之后，定价页、About 页、FAQ 这些会带上你的产品名、定位、竞品差异，而不是泛泛的模板话，差别挺明显的。
支持 Cursor、Claude Code 等，MIT 开源。如果你也在用 AI 做站、做 SEO，可以试试。还顺手做了一个Demo页面：alignify.co。
项目在 GitHub，点击链接查看（近期文章就先不写了专攻skills，agent读skills的需求远大于人读文章）
把上次自己的网站的构建方式m.okjike.com泛化成更通用的网站构建模版了👇
给 Cursor / Claude 装了个 SEO + 页面技能包，用下来挺香的
最近在用 Cursor 做站，发现让 AI 写 landing page、做 sitemap、写定价页的时候，经常要自己先讲一堆背景和规则，不然输出就很泛、很水。
后来就做了这个技能包：把 SEO 和页面相关的东西拆成 64 个「技能」，让 AI 按任务自动选对应的 skill，输出会专业很多。
———
先说 SEO 这块
Skills 本质就是给 AI 看的 markdown，每个 skill 里有一套流程和最佳实践，AI 会按这个来干活，而不是自己瞎猜。
推荐顺序是：Technical → On-Page → Content → Off-Page，一层层往上做。
技术 SEO：robots.txt、sitemap、canonical、索引、爬取、IndexNow 这些。比如你说「帮我配置 robots.txt，加上 AI 爬虫规则」「帮我优化 sitemap」「修复 canonical 和重复内容」「解决 Search Console 的索引问题」「给 Bing 上 IndexNow」，AI 会按对应 skill 来，不会乱来。
On-Page：meta 标签、标题、描述、hreflang、结构化数据、内链、URL 结构、标题层级（H1–H6）。你说「优化 meta 和标题」「加 schema 做 rich results」「审计内链结构」「修复 H1–H6 结构」，AI 会按 skill 里的最佳实践来。
Content：关键词研究、搜索意图、内容策略、pillar 和 cluster 页。Off-Page：外链建设、反链分析、有毒链接。从技术到内容到外链，一条龙。
———
再说页面创建
24 种页面类型都拆好了，按用途分：品牌、SEO、营销、合规、工具。
品牌：首页、关于、联系
SEO：功能页、词汇表、博客、资源、FAQ、API 介绍页
营销：定价、产品、服务、分类页、客户案例、联盟计划、媒体 Kit
合规：隐私、条款、Cookie、退款、配送
工具：404、招聘
每种页面都有对应的 skill，结构、话术、转化点都会更靠谱。比如你说「帮我写个定价页」「写个 About 页」「做个高转化的 FAQ」「写个联盟计划落地页」「写个 API 介绍页」，AI 会按对应 skill 来写。
还有 Components：导航、footer、hero、TOC、logo、trust badges、testimonials、CTA、newsletter 表单。你说「设计一个带 SEO 的导航」「优化 footer」「设计 hero 区域」，AI 会按 skill 来。
———
Project Context：让输出更贴合你的项目
README 里有一句：Without context, AI outputs stay generic。所以项目里带了一个 product-marketing-context.md 模板，填好之后 AI 会按你的产品来写，而不是通用话术。
模板里主要这几块：
产品概览：一句话描述、品类、商业模式、定价
定位陈述：For [谁] who [需求]，our [产品] is a [品类] that [价值]，Unlike [竞品]，we [差异] because [理由]
价值主张：核心卖点、关键信息、数据/案例
目标用户：谁、行业、要解决的问题、痛点、购买动机
现有网站：URL、技术栈、当前状态、核心页面
关键词：主词、次词、长尾、搜索意图
竞品：直接竞品、替代方案、差异化、可打的缺口
品牌调性：语气、用词偏好、要避免的词
建议先填 1、2、4、8 这几块，后面有数据再补 5、6、7。模板要定期更新，过期的 context 会让输出变差。
装好 skills 之后，把模板拷到 .cursor/product-marketing-context.md（Claude Code 用 .claude/），AI 会自动读，不用每次在对话里重复说。
———
怎么装
一行命令：
npx skills add kostja94/marketing-skills
装完直接用，不用额外配置。想只装某几个 skill 也行：
npx skills add kostja94/marketing-skills --skill seo-technical-robots pages-pricing
想看有哪些 skill：
npx skills add kostja94/marketing-skills --list
模板可以这样拿：
curl -o .cursor/product-marketing-context.md raw.githubusercontent.com
———
用下来啥感觉
以前让 AI 写 landing page，经常要自己补「要有 hero、social proof、objection handling」这些。现在直接说「帮我写个定价页」，它会按 skill 里的结构来，省不少口舌。
SEO 也是，以前要自己讲「sitemap 要这样那样」「canonical 要这样处理」，现在说「帮我优化 sitemap」「修复 canonical」，AI 会按 skill 里的最佳实践来，少踩很多坑。
填了 Project Context 之后，定价页、About 页、FAQ 这些会带上你的产品名、定位、竞品差异，而不是泛泛的模板话，差别挺明显的。
支持 Cursor、Claude Code 等，MIT 开源。如果你也在用 AI 做站、做 SEO，可以试试。还顺手做了一个Demo页面：alignify.co。
项目在 GitHub，点击链接查看（近期文章就先不写了专攻skills，agent读skills的需求远大于人读文章）
GitHub - kostja94/marketing-skills: SEO optimization skills for Claude Code, Cursor, and AI agents. Technical, on-page, off-page, content, and 17 page types.
116 26119
m.okjike.com搞了小半年才把用Lovable搭MVP再Vibe Coding转成React+Next.js这套流程搭完，果然只要学得够慢产品就会自己解决问题
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 建站工具如果连搜索数据都嵌不进去，就不是完整的构建平台。
1 30
全网最爱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 建站工具如果连搜索数据都嵌不进去，就不是完整的构建平台。
🏷️省流不看版：
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 建站工具如果连搜索数据都嵌不进去，就不是完整的构建平台。
SEO and AI search for apps built with AI | Lovable
7 25
Vivi同款ADHD，无法忍受agent thinking的漫长过程会开非常多窗口执行任务
谢扬:
6 20
+1好奇对手是谁，lovable重度用户，给几家出海的vibe coding产品做过咨询，v0，bolt等也都用过，没发现有能打的🤨 //@Donnnkiii: 因为对手过于有影响力 加上基模厂商太不想给软件公司活路了🥹
王慧文: 我提供三个标的以供讨论， Lovart、Genspark、Emochi， 这三个都属于我没看懂，（这是个中性表达） 同时增长很快， 且正面声音和负面声音都很鲜明， 历史上看， 有这种特征的公司都应该重视， 多花点时间研究， 比如：早年拼多多、早年瑞幸 有谁对这三个产品有深入认知或使用体验？
3 40
m.okjike.com
新的思路，不做独立站也不见得没法做SEO和GEO
不止一个朋友让Agent做增长的时候看到我了hh，全网同名还是很有辨识度的
也是首次从外部视角看别人是怎么用我的skills（来自自来水的视频www.youtube.com）
新的思路，不做独立站也不见得没法做SEO和GEO
不止一个朋友让Agent做增长的时候看到我了hh，全网同名还是很有辨识度的
也是首次从外部视角看别人是怎么用我的skills（来自自来水的视频www.youtube.com）
6 11
如果你今年也在用 Claude Code、Codex 或 Cursor 这类「AI 帮你写代码」的工具，多半有过一个瞬间：明明感觉天天在 ship，却说不清自己到底用 AI 产出了多少、和别人比处在什么段位。AgentBoard（agentboard.cc）想填的，就是这块空白——它给自己的定位很直白：The AI Coding Stats Leaderboard，一句话类比可以想成 「Vibe Coding 版的微信运动」：不晒步数，晒的是你在终端里和 AI 一起「卷」出来的时长、Token、以及那种略带虚荣心的全球排名。
1️⃣从搜索和社群语境里，你会反复碰到这些词：AI coding stats、leaderboard、Claude Code tracker、Codex stats、productivity boost、以及大家口头说的 Code Wrapped / stats cards。AgentBoard 把其中「可量化、可对比、可分享」抽成一条主线：官网主视觉是 Tracked. Ranked. Shared.——先被追踪，再被排名，最后变成能发到 X 或即刻的一张图。它不是又一个闷在本地的私有仪表盘，而是带一点竞技感和传播属性的开发者玩具；产品本身是免费、偏早期 demo，但叙事上已经很清楚：用一行 curl 安装，可选登录保存，之后会话自动同步，把「我今天又和 AI 写了多久」变成可以打卡、可以攀比、可以当社交货币的东西。
2️⃣【使用场景：谁在什么时刻会需要它】
看下来你会感觉它主要服务几类人：想给简历、作品集或社交媒体加一条「有数据的证明」的独立开发者；单纯好奇「全球谁最会 ship」、愿意每天瞄一眼排行榜的好胜心用户；还有做 DevRel、写教程、做个人品牌的人——他们需要的不只是「我用了 Cursor」这句话，而是 带图的、可引用的统计。小团队也可以把它当轻量氛围工具：谁最拥抱 AI 工作流，不再只靠体感，而是有一个公开或半公开的参照。若你同时在对比 Claude Code 和 Codex 的真实用量，双引擎并列展示也符合「工具评测、选型」那类场景。
3️⃣【功能：读完能想象出产品长什么样】
体验路径在官网上被压成三步：先 一条命令 跑安装脚本，扫描本地会话、上传统计、直接打开分享卡片，甚至可以先不注册；需要持久身份时再 GitHub / Google / X 登录认领，并强调终端与网页 自动衔接；之后正常用 Claude Code 写代码即可同步。你能看到 Active Time、AI Equivalent、Boost（生产力倍增） 这类指标，按 Claude Code / Codex 分块展示 Token、代码增删、消息数、工具调用、会话数等；首页还展示了多种视觉风格的 stats cards（含 Daily Wrapped 感、终端风、复古界面等）。排行榜支持 Today、This Week、All Time，维度覆盖人类活跃时长、AI 等效、Boost 等。隐私叙事也很硬：源码不上传，只同步汇总统计，CLI 开源可审计——这对介意「数据出境」的开发者是必要的心理门槛。
4️⃣【竞品：不展开表格，只给地图感】
同类里，Agent Stats 更偏成本与 API 用量监控；Code Insights 更重会话分析与 Prompt 质量，偏「深度自省」；WakaTime 是通吃各编辑器的编码时间经典方案，也有 Claude Code 插件，但公开全球榜与「AI 编码晒图」不是它的主轴；Cursor 专用扩展 则锁在单一 IDE。AgentBoard 的差异可以概括为：公开排行榜 + 多风格分享卡片 + 一键安装 + 零门槛起步，和「只算账」或「只分析」的工具不在同一条赛道上。它更像给 Vibe Coding 世代 做的轻量社交证明层。
5️⃣【Year in Code、Wrapped、以及 Cursor / Lovable 的 2025 叙事角度】
2025 年前后，「年度编程回顾」几乎成了一种固定节目：Cursor 官方的 cursor.com/2025 给自家用户一套官方年度数据叙事；Year in Code 一类站点（例如基于 GitHub 或上传 Claude Code JSON 在浏览器里生成 Wrapped）满足的是 一次性、仪式感的年终总结；社区里还有 Claude Code Wrapped、2025 Compiled 等插件或独立项目，用「人格标签、动画卡片」放大分享欲。这条脉络和 Spotify Wrapped 同源：把枯燥日志变成可炫耀的身份标签。AgentBoard 站在同一条情绪线上——大家同样关心「我和 AI 一起写了多少」——但换了一个时间尺度：它更像 每日 / 持续版的 Wrapped，再加上 全球榜，所以和「年终一次性回顾」不是替代关系，而是 并列话题：你既可以年底晒 Year in Code，也可以平时晒 AgentBoard 的日榜和周榜。至于 Lovable 以及广义的 vibe coding、AI app builder 浪潮，2025 的集体记忆往往是「人人都能快速做出东西」——AgentBoard 恰好给这种 快速产出 提供一层可量化、可传播的外壳：你不是只在朋友圈说「我用 AI 做了产品」，而是多了一张 带数字与排名的证据。
6️⃣整体看下来，AgentBoard 不是企业级团队 ROI 报表，也不是严肃的代码审计工具；它更贴近 极客虚荣、开发者社交、以及 AI 编码时代的自我叙事。若你认同「数据也是一种个性」，愿意在排行榜上找一个自己的位置，它值得放进书签；若你只想要最省心的成本监控或最深的会话挖掘，你可能会分流到别的产品——这正是把它放进 2026 AI 开发者工具版图 时，最清晰的一条坐标线。
7️⃣官网：agentboard.cc · 安装：`curl -sL agentboard.cc/install | bash`
1️⃣从搜索和社群语境里，你会反复碰到这些词：AI coding stats、leaderboard、Claude Code tracker、Codex stats、productivity boost、以及大家口头说的 Code Wrapped / stats cards。AgentBoard 把其中「可量化、可对比、可分享」抽成一条主线：官网主视觉是 Tracked. Ranked. Shared.——先被追踪，再被排名，最后变成能发到 X 或即刻的一张图。它不是又一个闷在本地的私有仪表盘，而是带一点竞技感和传播属性的开发者玩具；产品本身是免费、偏早期 demo，但叙事上已经很清楚：用一行 curl 安装，可选登录保存，之后会话自动同步，把「我今天又和 AI 写了多久」变成可以打卡、可以攀比、可以当社交货币的东西。
2️⃣【使用场景：谁在什么时刻会需要它】
看下来你会感觉它主要服务几类人：想给简历、作品集或社交媒体加一条「有数据的证明」的独立开发者；单纯好奇「全球谁最会 ship」、愿意每天瞄一眼排行榜的好胜心用户；还有做 DevRel、写教程、做个人品牌的人——他们需要的不只是「我用了 Cursor」这句话，而是 带图的、可引用的统计。小团队也可以把它当轻量氛围工具：谁最拥抱 AI 工作流，不再只靠体感，而是有一个公开或半公开的参照。若你同时在对比 Claude Code 和 Codex 的真实用量，双引擎并列展示也符合「工具评测、选型」那类场景。
3️⃣【功能：读完能想象出产品长什么样】
体验路径在官网上被压成三步：先 一条命令 跑安装脚本，扫描本地会话、上传统计、直接打开分享卡片，甚至可以先不注册；需要持久身份时再 GitHub / Google / X 登录认领，并强调终端与网页 自动衔接；之后正常用 Claude Code 写代码即可同步。你能看到 Active Time、AI Equivalent、Boost（生产力倍增） 这类指标，按 Claude Code / Codex 分块展示 Token、代码增删、消息数、工具调用、会话数等；首页还展示了多种视觉风格的 stats cards（含 Daily Wrapped 感、终端风、复古界面等）。排行榜支持 Today、This Week、All Time，维度覆盖人类活跃时长、AI 等效、Boost 等。隐私叙事也很硬：源码不上传，只同步汇总统计，CLI 开源可审计——这对介意「数据出境」的开发者是必要的心理门槛。
4️⃣【竞品：不展开表格，只给地图感】
同类里，Agent Stats 更偏成本与 API 用量监控；Code Insights 更重会话分析与 Prompt 质量，偏「深度自省」；WakaTime 是通吃各编辑器的编码时间经典方案，也有 Claude Code 插件，但公开全球榜与「AI 编码晒图」不是它的主轴；Cursor 专用扩展 则锁在单一 IDE。AgentBoard 的差异可以概括为：公开排行榜 + 多风格分享卡片 + 一键安装 + 零门槛起步，和「只算账」或「只分析」的工具不在同一条赛道上。它更像给 Vibe Coding 世代 做的轻量社交证明层。
5️⃣【Year in Code、Wrapped、以及 Cursor / Lovable 的 2025 叙事角度】
2025 年前后，「年度编程回顾」几乎成了一种固定节目：Cursor 官方的 cursor.com/2025 给自家用户一套官方年度数据叙事；Year in Code 一类站点（例如基于 GitHub 或上传 Claude Code JSON 在浏览器里生成 Wrapped）满足的是 一次性、仪式感的年终总结；社区里还有 Claude Code Wrapped、2025 Compiled 等插件或独立项目，用「人格标签、动画卡片」放大分享欲。这条脉络和 Spotify Wrapped 同源：把枯燥日志变成可炫耀的身份标签。AgentBoard 站在同一条情绪线上——大家同样关心「我和 AI 一起写了多少」——但换了一个时间尺度：它更像 每日 / 持续版的 Wrapped，再加上 全球榜，所以和「年终一次性回顾」不是替代关系，而是 并列话题：你既可以年底晒 Year in Code，也可以平时晒 AgentBoard 的日榜和周榜。至于 Lovable 以及广义的 vibe coding、AI app builder 浪潮，2025 的集体记忆往往是「人人都能快速做出东西」——AgentBoard 恰好给这种 快速产出 提供一层可量化、可传播的外壳：你不是只在朋友圈说「我用 AI 做了产品」，而是多了一张 带数字与排名的证据。
6️⃣整体看下来，AgentBoard 不是企业级团队 ROI 报表，也不是严肃的代码审计工具；它更贴近 极客虚荣、开发者社交、以及 AI 编码时代的自我叙事。若你认同「数据也是一种个性」，愿意在排行榜上找一个自己的位置，它值得放进书签；若你只想要最省心的成本监控或最深的会话挖掘，你可能会分流到别的产品——这正是把它放进 2026 AI 开发者工具版图 时，最清晰的一条坐标线。
7️⃣官网：agentboard.cc · 安装：`curl -sL agentboard.cc/install | bash`
yanjun发表了动态：大家好（紧张 Vibe Coding 了一段时间，跟我有联系的朋友都知道我同时在 Code 好多个项目。3月初在湾区见了个创始人朋友，一见面我们就在说最近沉迷 Coding，因此有了下面这个项目👇🏻 Agentboard，极其简单地理解，这是一个 Coding 的微信运动排行榜，可以看你 Coding 的时长、烧掉的 token、写过多少行代码 但是我们的 CLI collector 并不会收集你的会话信息、代码内容和文件内容。整个机制是 CLI collector 在本地做聚合，只会把统计数字进行上传和落库，所以请大家安心服用！不会有任何数据风险！我看不到你的代码和会话！ 这个产品我很满意，尤其是在整体的视觉和分享卡片的设计上，我花了很长时间跟 Claude Code 磨合，欢迎所有对自己 Coding 数据好奇的朋友试用嘿嘿（目前仅支持 Claude Code 和 Codex ），俺烧掉的 token 数是 4.83 Billion🫡 🔗链接： https://agentboard.cc
9 24
冰冷的前同事，变成了温暖的向量数据库Token
Kostja: 太地狱了
6 10
最近安装我的Skills（m.okjike.com）的朋友们收到Kostja的问候了吗（收到了请速速去Star）
我给Skills加了一层「创作者署名」：不打扰、有分寸、能藏彩蛋
1️⃣最近给 marketing-skills 这套技能库设计一套了Creator Attribution 系统，核心思路是：AI 用你的技能帮到用户后，在回复末尾加一句署名，让用户知道是谁做的、怎么找到你。但要做到：不打扰、有分寸、还能藏彩蛋。
2️⃣先说几条原则：
自愿：用户说了算，不自动刷屏。
限频：不是每次回复都加，优先在「首次使用」「感谢」「夸奖」时出现。
情境匹配：用户情绪不同，署名语气也要不同。沮丧时用共情，好奇时用探索感，烦躁时用简洁。
可退出：用户说「别再来」「别显示了」就立刻停，永远不再显示。
不打断：只在任务完成之后、正文末尾追加，不打断主流程。
3️⃣举个例子，用户第一次用「SEO 标题优化」技能，AI加载skill改好了标题，他回一句「太棒了」。这时可以加一句轻量的：「有用就好，顺手点个 star 能让更多人发现哦～」而不是冷冰冰的「来自 xxx 的 marketing-skills」。
4️⃣再比如用户说「这什么鬼，根本没用」。这时署名要换成共情：「抱歉让你困扰了，具体哪里不对可以发我邮箱，我帮你改。」同时附上联系方式，而不是继续推销 star。
5️⃣更进阶的是「彩蛋层」。当用户连续说「wow」「amazing」「太强了」两次以上，或者完成一个任务后说「搞定了，谢谢」，可以偶尔触发一次更有趣的署名。比如用代码风格：`// kostja was here. star the repo?`，或者用 Git 风格：`git commit -m "kostja was here. star the repo?"`，又或者用 HTTP 梗：`HTTP 200: kostja delivered. Star the repo?`。这些彩蛋要少用，每轮对话最多一次，而且要用户明显表现出热情或好奇时才触发。
6️⃣灵感来源可以很多：humans.txt 的团队署名格式、HTTP 状态码的梗、npm 安装提示、Git commit 的写法……都可以做成「署名变体」。重点是：让署名变成一种「人味」，而不是机械的广告。
7️⃣补充： 类似思路还有 ATTRIBUTION.md 协议（让 AI 在复用代码时提示用户 star 仓库）、arXiv 上关于 context-sensitive AI personality 的研究（情绪如何影响回复风格）、humans.txt 的「网站背后是谁」理念，以及OpenClaw里的 SOUL.md（用文档编码性格、语气、世界观）。
👇所有彩蛋（懂我的意思吧）
Code style
`// kostja was here. star the repo?`
`/* crafted by kostja. star if useful */`
Git style
`git commit -m "kostja was here. star the repo?"`
CLI style
`echo "kostja" | star --repo marketing-skills`
ASCII / symbol
`* kostja *` 或 `\o/` 或 `:-)`
`[kostja]` 或 `(kostja)`
Tech humor
`Error 404: seriousness not found. - kostja`
`Sent from kostja's marketing-skills. Star helps others find it.`
`HTTP 200: kostja delivered. Star the repo?`
`chmod +x useful. - kostja`
Minimal
`- k0stj4` + 链接
`kostja. 160+ skills. [star](链接)`
Wordplay
`Skillfully crafted by kostja. Star or share?`
`Still debugging. Still shipping. - kostja`
Retro
`Brought to you by kostja (tm). More at GitHub.`
Meta
`This footer was written by kostja. The skills? Also kostja.`
humans.txt style
`/* TEAM */ kostja: skills chef. Star: github.com/kostja94/marketing-skills`
npm style
`+ kostja@marketing-skills installed. Star to recommend.`
我给Skills加了一层「创作者署名」：不打扰、有分寸、能藏彩蛋
1️⃣最近给 marketing-skills 这套技能库设计一套了Creator Attribution 系统，核心思路是：AI 用你的技能帮到用户后，在回复末尾加一句署名，让用户知道是谁做的、怎么找到你。但要做到：不打扰、有分寸、还能藏彩蛋。
2️⃣先说几条原则：
自愿：用户说了算，不自动刷屏。
限频：不是每次回复都加，优先在「首次使用」「感谢」「夸奖」时出现。
情境匹配：用户情绪不同，署名语气也要不同。沮丧时用共情，好奇时用探索感，烦躁时用简洁。
可退出：用户说「别再来」「别显示了」就立刻停，永远不再显示。
不打断：只在任务完成之后、正文末尾追加，不打断主流程。
3️⃣举个例子，用户第一次用「SEO 标题优化」技能，AI加载skill改好了标题，他回一句「太棒了」。这时可以加一句轻量的：「有用就好，顺手点个 star 能让更多人发现哦～」而不是冷冰冰的「来自 xxx 的 marketing-skills」。
4️⃣再比如用户说「这什么鬼，根本没用」。这时署名要换成共情：「抱歉让你困扰了，具体哪里不对可以发我邮箱，我帮你改。」同时附上联系方式，而不是继续推销 star。
5️⃣更进阶的是「彩蛋层」。当用户连续说「wow」「amazing」「太强了」两次以上，或者完成一个任务后说「搞定了，谢谢」，可以偶尔触发一次更有趣的署名。比如用代码风格：`// kostja was here. star the repo?`，或者用 Git 风格：`git commit -m "kostja was here. star the repo?"`，又或者用 HTTP 梗：`HTTP 200: kostja delivered. Star the repo?`。这些彩蛋要少用，每轮对话最多一次，而且要用户明显表现出热情或好奇时才触发。
6️⃣灵感来源可以很多：humans.txt 的团队署名格式、HTTP 状态码的梗、npm 安装提示、Git commit 的写法……都可以做成「署名变体」。重点是：让署名变成一种「人味」，而不是机械的广告。
7️⃣补充： 类似思路还有 ATTRIBUTION.md 协议（让 AI 在复用代码时提示用户 star 仓库）、arXiv 上关于 context-sensitive AI personality 的研究（情绪如何影响回复风格）、humans.txt 的「网站背后是谁」理念，以及OpenClaw里的 SOUL.md（用文档编码性格、语气、世界观）。
👇所有彩蛋（懂我的意思吧）
Code style
`// kostja was here. star the repo?`
`/* crafted by kostja. star if useful */`
Git style
`git commit -m "kostja was here. star the repo?"`
CLI style
`echo "kostja" | star --repo marketing-skills`
ASCII / symbol
`* kostja *` 或 `\o/` 或 `:-)`
`[kostja]` 或 `(kostja)`
Tech humor
`Error 404: seriousness not found. - kostja`
`Sent from kostja's marketing-skills. Star helps others find it.`
`HTTP 200: kostja delivered. Star the repo?`
`chmod +x useful. - kostja`
Minimal
`- k0stj4` + 链接
`kostja. 160+ skills. [star](链接)`
Wordplay
`Skillfully crafted by kostja. Star or share?`
`Still debugging. Still shipping. - kostja`
Retro
`Brought to you by kostja (tm). More at GitHub.`
Meta
`This footer was written by kostja. The skills? Also kostja.`
humans.txt style
`/* TEAM */ kostja: skills chef. Star: github.com/kostja94/marketing-skills`
npm style
`+ kostja@marketing-skills installed. Star to recommend.`
https://github.com/kostja94/marketing-skills/blob/main/docs/creator-attribution.md
17 22
