🫡开始做产品了，Build in Public 第一天。

Oginify，一个 Open Graph 配图生成器。粘贴任意 URL，AI 读懂页面，一次出四张 1200×630 社交分享图。一张贴合品牌，三张风格放开玩——终端、杂志、复古印刷，各有各的味道。

1️⃣做产品的念头
我是 SEOer，给客户做站，OG 图永远是最后一公里卡壳的地方。需求真实，高频，痛——英文圈管这叫 Dogfooding，吃自己的狗粮。但说实话，另一层原因是：我倒是想试试，做产品到底有多难。
所以不调研了，先开工。

2️⃣钱的事，简单说
目前 Lovable 搭 MVP，底层 Google Gemini 出图。一次生成四张约 $0.27（一块九毛五）。Lovable 每月只给 $1 免费 AI 额度，多了我扛不住。所以匿名用户每天免费 3 次——够试，也够我先活着。前两天刚办了香港银行卡，支付还没接上，但先跑起来再说。

3️⃣给谁用
所有有网站的站长。SEOer、独立开发者、内容站、电商站，只要你的页面需要一张像样的社交分享图。
当然，如果有vibe coding 工具像Lovable、CMS像Shopify这样的超级大 B 愿意内置这个功能，请直接联系我——开个玩笑，但梦想还是要有的。

4️⃣接下来
边做边公开：成本、额度、支付、功能迭代，全程摊开。后续也会聊聊 OG 图跟社交媒体传播、pSEO 之间的关系——这些是我日常在做的事，顺便写下来，算是 Build in Public 的一部分。

做 SEO 的、搞 设计 的、做过生图产品的朋友，欢迎来试，越 blunt 越好。产品难不难做，第一周就能知道个大概了。

👉 oginify.com

Build in Public：Oginify 的定价策略；省流：给完全没给产品定过价格的开发者-定高价，看情况下调

本文分两部分：Oginify 自身的定价逻辑与演进方向，以及一套可复用的工具型产品定价 playbook——后者可直接当作 checklist 使用。

—————————

Part 1 · Oginify 的定价策略

Oginify 做的是每个 URL 的 1200×630 可视化资产——Open Graph 预览图、Featured Image、部分横版展示广告等，共用同一生成管线。全球网站数以亿计，每站包含多个 URL；内容站、pSEO 站点单站可达数百乃至数千页。Vibe Coding 进一步降低了建站与改版成本；同一页面亦可能随季节、活动或 A/B 测试多次换图。因此在 TAM 层面，这是一个足够大的市场。

但单个用户的实际用量并不均匀，而是两极分化：有人一个月只需要几张（个人站、新产品几页）；有人需要为数千页面批量生成（pSEO 规模化站点、Agency 多客户、CMS 平台集成）。同一产品、同一规格，用量可以差三个数量级。Oginify 的定价逻辑正是由此而来——不是「市场小所以简单收费」，而是「市场大、用法分化，所以必须分层」：小量级用 Free 和 PAYG，中量级用订阅，大量级用 Enterprise 和 API。

1️⃣ 管线重构与成本基础
上线初期主流程为 AI 生成 4 张图，单次成本约 $0.30。6 月 3 日完成重构：主流程改为首屏截图 + 模板渲染，单次 2 张图、成本约 $0.005；AI 仅在 Regenerate 时触发。单位成本两周内变化两个数量级，免费额度（现为 6 张/天）与 SKU 设计必须跟随产品形态调整，而非一成不变。

2️⃣ 当前线上方案（v1 · 过渡）
Free 6 张/天；PAYG $0.99（2 张 + 6 次 Regenerate）；Bundle 10 $7.90；Bundle 50 $29.00；social-cards-skills MIT 永久免费。v1 是支付接入后的过渡结构——验证付费意愿、在 MoR 支付手续费（约 4.5% + $0.30/笔）下跑通 unit economics。$0.99 单笔通道费占定价 35%，不宜作为长期主力，仅宜作冲动入口。Pro / Studio 等 v2 档位规划中，以 Pricing 页线上为准。

3️⃣ 目标方案（v2 · 五层结构）
Free（6 张/天，试用）→ PAYG $2.90（小量级、冲动入口）→ Pro $19/月 · 100 张（中量级，Pricing 主推）→ Studio $29/月 · 300 张（升级，+$10 配额 ×3）→ Enterprise / API（大量级：sitemap 批量、Webhook、按量与 SLA）。年付统一 65 折（Pro $149/年、Studio $229/年）。PAYG 到 Pro 约 6–8 次回本——这一比例需通过 D3 邮件告知用户，不会自动被感知。Bundle 10/50 在 Pro 上线后下线，避免稀释主推档。
Enterprise / API 面向的并非「更贵的个人用户」，而是不同的交付形态：输入从粘贴 URL 扩展为 sitemap / CSV / CMS Webhook；输出从手动下载扩展为 CDN 托管与自动写回 og:image；计费从张数包转向按量或年约。social-cards-skills 仍以 MIT 服务开发者自托管——Skills 是 GEO 入口，API 是规模化托管需求，人群不重叠。

—————————

Part 2 · 工具型产品定价 Playbook（通用版 · 可收藏）
适用对象：单位成本可量化（每次调用 / 每次生成 / 每次 API 请求有明确成本）、存在 1–2 个同品类竞品锚点的 SaaS / AI / API 产品。不适用：纯服务（按工时）、纯内容（按 SKU）、纯硬件（BOM + 渠道毛利）。

1️⃣ 第一性原理（五条心法）
定价是定位，不是数学。价格是信号：卖给谁、与谁同台、用户将你视为专业工具还是玩具。成本只决定地板，定位决定天花板。锚点决定上限——$19/月在 $49 同品类用户眼里便宜，在 $9 通用工具用户眼里贵；选错锚点等于永远定不对价。先定高、下调有故事；先定低、上调要道歉——降价可包装 Launch Week / 黑五 / 周年庆，涨价只能发邮件解释。档位越少越好：每多一档，主推档视觉权重被稀释一次，5 档是上限，4 档更好，3 档最干净。价格不能频繁变动——SaaS 每年实质性调整 0–1 次；首发价即未来 12 个月的锚点，长期价等于首发价，促销承担折扣；若首发价与长期价相同，须预先规划 2–3 个「下调事件」制造紧迫感。

2️⃣ Step 1：算清单位经济
公式：单位成本 = 直接调用成本 + 摊销基础设施 + 支付通道成本。最容易漏的是支付通道——MoR / Stripe / Paddle 典型费率约 $0.30 + 4.5%，对低单价 SKU 是灾难：$0.99 净收仅 $0.645，通道占 35%；$1.99 占 20%；$2.90 占 15%；$19.00 占 6%。结论：单价低于 $2 的 SKU，通道吃掉约三分之一收入，PAYG 地板建议 $2.90 起。毛利红线：PAYG ≥ 80%（一次性，无续费摊销）；月订 ≥ 85%（覆盖流失风险）；年订 ≥ 90%（须留出折扣空间）。案例：PAYG $0.99 含 2 次调用 + 6 次重试，毛利仅 40%——数学上错误；改 $2.90 后毛利约 85%。

3️⃣ Step 2：找市场锚点
锚点三层级（强→弱）：同品类直接竞品（做同一件事）> 邻近品类工具链（用户已在用的相邻工具）> 通用替代品（弱锚，慎用）。用错锚点的典型错误：细分场景工具以 Canva 等通用大类（$9）为锚——品类宽故单价低，细分工具是工作流一环，用户付费心智是「专业工具」。正确锚点：同品类竞品（常见 $19–49/月），那是用户已被教育过的心理价位。怎么读锚点：竞品价不是天花板，是心理基准。跟竞品同价须提供 2–3 倍价值；便宜 30% 须解释为何便宜，否则被疑质量；贵 30% 须提供明显增量，否则被跳过。

4️⃣ Step 3：设计档位结构（五档框架）
Free → 试用漏斗，让用户试出「我喜欢这个工具」，不是长期替代品。PAYG → 冲动入口 + 定价锚，让想立刻付钱的用户付钱，且不应比订阅划算。主推订阅 → 视觉高亮的那档，服务「打算用一阵」的用户，不应有奇怪限制。升级订阅 → 主推用户的超额留存，不是新客入口。Enterprise → 让大客户找到联系方式，v1 不必标价。每一档只有一个唯一职责；违反职责的档位应删除。不要 Bundle 中间层：PAYG 已覆盖「只用一次」，再加 Bundle 等于「我们在纠结收不收钱」——用户会在五档里「先存着再说」。v1 不要做 Team：协作是未验证需求，座位管理 / 邀请流 / 权限模型会拖慢主线 6–8 周；升级档定位应是「主推的超额上限」，真有团队需求再开 Team SKU（如 $79/年 + 3 座位）。Enterprise 呈现：尚无真实客户时 Footer 一行小字 + mailto；累计 ≥3 次 Enterprise 入站后，再换第五张卡片（无价格 + Unlimited / API / Priority 三个 chip）。用量两极分化的 metered 产品（小量级 vs 大量级并存），须在顶部预留 Enterprise / API，不能只用订阅中间档硬接头部需求。

5️⃣ Step 4：校准档位间的数学关系
档位价差不是拍脑袋，须具备心理叙事链。三条关键比例：PAYG → 主推月订 = 6–8 次回本（「月用 6 次以上该买月订」）；月订 → 年订 = 65 折统一（约 35% off，SaaS 惯例，省 4 个月）；主推 → 升级 = 价格 +$10、配额 ×3（「多花十块，多拿三倍」——+$10 是用户说得出口的话，$19→$29 用户算不清是 +53% 还是 ×1.5，配额 ×3 是可见价值，两数各说各的不打架）。完整叙事链示例：PAYG $2.90 × 6.5 ≈ 主推 $19；$19 + $10 = 升级 $29；$19 × 12 × 0.65 ≈ $149/年；$29 × 12 × 0.65 ≈ $229/年。年付折扣必须档档统一——主推 65 折、升级 57 折，用户立刻判断「定价没想清楚」。比例不会自动说服人，须变成邮件：D3 邮件结构 = ① 算账（「你试过一次 $2.90，本月第 7 次单次成本已低于 PAYG，还剩 93 次没用」）+ ② 社会证明（1 个真实案例：月用 40 次省多少）+ ③ 截止日期（「7 天特惠首月 $14」）。定价是数学，转化是邮件——二者不能分开设计。

6️⃣ Step 5：留出下调空间
策略：长期价 = 首发价，促销来打折。不要设虚高原价再降——用户记住的锚点是长期价。上线当天可宣布 Launch Week：$19 → $14，用户看到的是「$19 的工具打 7 折」，7 天后回 $19，无人抱怨涨价。下调须绑故事：Launch Week 30–40% off（一次性）；黑五 / 网一 20–30% off（年度）；周年庆 15–25% off；学生 / 开源 50% off（长期）。永远不要默默降价——会教育老用户等下次促销。

7️⃣ Step 6：防御性护栏
三类护栏：PAYG 单次上限（限定 N 次调用 + M 次重试，防低价调爆成本）；Free 反机器人（Turnstile + 日上限 + 设备指纹）；订阅配额不结转（月底归零，年订按月分配，防囤积套利）。红线：每档算最坏成本 = 配额 × 单位成本 × 100% 使用率，最坏情形毛利仍 ≥ 60%，否则护栏不够。案例：PAYG = 2 次 + 6 重试上限，即使用户全部用完，成本约 $0.25，毛利仍 85%。

8️⃣ Step 7：落地页呈现（五条铁律）
定价对不对看数字，卖不卖得动看页面。① 主推档视觉权重最高——边框加粗 + Most popular + 配色稍亮，不是 Free 也不是最贵档。② 卡片数 = 实际可买档位数，不放 Coming Soon（流失信号，要么一起上要么删）。③ Enterprise：无真实需求时一行 mailto，有 inbound 时第五卡 + 3 chip。④ 文案锚定竞品——弱：「100 次/月」；强：「100 次/月，同价竞品 30 次的 3.3 倍」。⑤ 年付切换器默认 ON，第一眼看到年付价（已打折），月付是次选。

9️⃣ 发布前 Checklist（一页纸）
单位成本是否计入支付通道？PAYG 毛利 ≥ 80%、主推 ≥ 85%、年订 ≥ 90%？锚点是同品类竞品而非通用替代品？档位 ≤ 5？主推档视觉高亮？PAYG → 主推 6–8 次回本？年付 65 折档档统一？主推 → 升级 +$10、配额 ×3？长期价已定且规划 2–3 个下调事件？Free 有 Turnstile / 日上限？PAYG / 订阅有最坏成本封顶？页面无 Coming Soon？Enterprise 呈现与真实 inbound 匹配？每档文案锚定竞品？D3 邮件已准备？

🔟 反模式速查
用纯订阅强推用量分化明显的 metered 产品（缺 PAYG 或 Enterprise 顶部）→ 加 PAYG 入口 + 头部档位。纯买断错过 LTV → 加订阅。中间 Bundle 稀释主推 → 砍掉。通用替代品当锚点 → 换同品类竞品。虚高原价再降 → 长期价即首发价。Free 卡片权重高于付费 → 主推高亮。Coming Soon 占位 → 删。升级档绑未验证 Team 功能 → 定位为超额上限。单价低于 $2 → 提至 $2.90 起。年付折扣不统一 → 全档 65 折。频繁调价 → 年调 0–1 次。算好比例但没邮件 → D3 触发 PAYG→订阅转化。产品成本变了定价没调 → 重新跑 Step 1。

Oginify 定价页已上线，Free 6 张/天可直接试用。Part 2 建议收藏，发布新产品定价前对照 Checklist 过一遍。若你在做 metered 工具、用量两极分化明显，欢迎交流分层定价与 Enterprise 路径的设计。

帮转，之前是客户，Founder很nice，当时定位还是local business intelligence（网站features和database两个板块是我做的）

给那些希望用Vibe Coding开发独立商业化小产品赚刀乐的朋友们

Oginify 今天把支付接通了。
先说现状——目前付费和不付费在功能上没有任何区别，Pricing 页上只是一个简单的 Sponsorship 按钮，$0.99 买一次生成额度，本质上是「支持一下」的意思。但明天开始就要认真做定价策略、推进商业化了。支付链路得先跑通，后面才好调价格、调额度、调订阅形态。

选型最后用了 Clink（clinkbill.com）。下面客观对比一下我调研过的几家，以及为什么对一个国内主体、Lovable 托管、Vibe Coding 驱动的项目来说，Clink 是目前最顺的路径。

1️⃣ Stripe / Paddle / Clink：三类不同的东西
先说结论：Stripe 和 Paddle 不是同一类竞品，Clink 又和它们不完全重叠——但 indie 创始人选型时往往会在三者之间纠结，所以放在一起讲。

Stripe 是支付处理器（Payment Processor），不是 Merchant of Record。费率低（约 2.9% + $0.30），开发者体验公认最好——文档、SDK、社区都是行业标杆，checkout 可定制性也最强。代价是你自己就是法律意义上的卖家：全球销售税/VAT 注册、申报、chargeback 处理，合规责任都在你这边。Stripe Tax 能帮你算税，但不会替你注册和代缴。如果你 90% 以上收入来自美国、有财务团队或愿意雇 accountant，Stripe 通常是默认答案。

Paddle 是 Merchant of Record（MoR）。Paddle 在法律上是卖家，全球 VAT/销售税、chargeback、退款合规它帮你扛，费率更高（约 5% + $0.50）。适合面向全球 B2C 卖数字产品、不想碰税务合规、非美国主体又没有美国公司的 indie SaaS。缺点是 checkout 和定价模型的灵活度不如 Stripe，发票上是 Paddle 的名字不是你的。

Clink 的定位更接近「AI-native 时代的支付基础设施」——Hosted Page（跳转托管页）和 Embedded Elements（嵌入式）两种形态都支持，底层可以路由到多个 PSP，也覆盖订阅计费、全球税合规、135+ 币种。和 Stripe 比，Clink 帮你少踩一层「主体 + 合规 + 多网关对接」的坑；和 Paddle 比，Clink 在 Agent 经济、Vibe Coding 工具链集成上走得更前——后面会讲。

客观说：如果你是美国公司、有 finance 团队、要极致 checkout 定制，Stripe 仍然是最优解。如果你是全球 B2C、零税务耐心，Paddle / Lemon Squeezy 这类 MoR 更省心。Clink 的 sweet spot 是：国内注册主体、想快速出海收美元、又不想从零搭 Stripe + Tax + Webhook 全家桶的 indie 开发者——以及正在用 AI Agent / Vibe Coding 做产品的团队。

2️⃣ 为什么选 Clink：一天接入，且支持国内主体（当然Stripe该接还是得接）
对我个人而言，几个决定性因素：

第一，国内注册主体可以直接开户。Stripe 对大陆主体的门槛大家都懂；Paddle 也需要一定 onboarding 周期。Clink 这边我提交 KYB 资料、绑定收款账户、产品上架审核，整体节奏比预期快很多——从后台配置到 UAT 沙箱跑通，再到生产环境真实订单端到端验证，基本就是一天的事。

第二，customer service 响应极快。接入过程中遇到商户状态异常、Webhook 验签、环境切换等问题，@Julie汪楚航 @High寧 官方同学基本都能当天给到明确答复。对第一次接支付、没有专职 backend 的 solo founder 来说，这个权重比文档完美更重要。

第三，UAT / Live 双环境设计清晰。沙箱和生产完全独立——独立后台、独立 API Key、独立 Product、独立 Webhook。sk_test 只能配 uat-api，sk_live 只能配 api，四项（BASE_URL、SECRET_KEY、WEBHOOK_SECRET、PRODUCT_ID）必须同环境配套，否则直接 Invalid API Key。规则硬但好排查，比某些平台「沙箱能跑、上生产 mysteriously 挂掉」体验好。

3️⃣ Vibe Coding + Agent：接入速度是 Stripe 文档给不了的
Oginify 整个产品栈在 Lovable 上——oginify.com 是绑定的自有域名，不是迁出后的独立站。接 Clink 的方式是：把一份结构化接入文档（中文说明 + Agent Playbook）丢给 Lovable，让它按 playbook 创建三个文件：

服务端 createServerFn：调 Clink checkout/session API 创建支付会话
Webhook 路由：/api/public/clink-webhook 接收并验签回调
前端 Pricing 页：点按钮 → 收 email → 跳转 Clink 托管支付页

从「零支付代码」到 UAT 沙箱跑通，Agent 一轮对话搞定。上生产主要是后台配置切换（换 live productId、换 API Key、注册 live webhook、KYB 审核），代码改动极小。

Clink 官方文档里有Agentic Payment Skill，本质上是面向 AI Agent 可读的结构化接口说明——这和 Stripe 面向人类开发者的 docs 是不同路线。在 Lovable / Bolt / Cursor 这类 Vibe Coding 工作流里，Clink 的接入摩擦明显更低。Stripe 的 DX 对人类工程师最好；Clink 的 DX 对 AI Agent 更友好——两个维度，不矛盾。

4️⃣ 接入 Tips（踩坑实录，给后面要接的朋友）
以下是我 UAT → Live 切换过程中实际遇到的问题，按优先级排列：

Tip 1：Webhook 路径必须放 /api/public/* 下。Lovable 已发布站对非 public 路由有鉴权，Clink 回调会被挡掉。这是 Lovable 特有的坑，文档里不一定写。
Tip 2：Webhook 注册 URL 用稳定地址。Lovable 项目有两种 URL：基于项目名的（oginify.lovable.app，改项目名就失效）和基于 project ID 的（project--.lovable.app，永不变）。外部回调强烈建议用 project-- 格式或自定义域名。UAT 用 project---dev.lovable.app，生产用 oginify.com/api/public/clink-webhook。
Tip 3：UAT 和生产 Webhook 不要混用。UAT webhook 填生产域名 = 沙箱订单污染生产日志；生产 webhook 填 preview 地址 = 发布后回调打不到。
Tip 4：API Key 粘贴时检查前后空格/换行。这是 Invalid API Key 最高频的原因，不是 key 错了，是复制多了个换行。
Tip 5：Merchant status exception 不是代码 bug。生产环境 checkout 报这个，说明 KYB 未通过 / 收款账户未绑定 / 产品未激活——去 Clink 后台看商户状态，或者找 support。
Tip 6：Webhook 验签必须在 JSON.parse 之前读 rawBody。签名算法是 HMAC-SHA256 over `${timestamp}.${rawBody}`，先 parse 再验签 = 永远 401。
Tip 7：CLINK_SECRET_KEY 永远不进浏览器。所有 Clink API 调用走 createServerFn（服务端），前端只触发 serverFn 拿跳转 URL。
Tip 8：merchantReferenceId 每次必须唯一。我用 oginify_，重复会出奇怪问题。
Tip 9：successUrl / cancelUrl 必须是完整 URL（含 https://）。传 window.location.origin 拼路径，不要传相对路径。

5️⃣ 下一步：从 Sponsorship 到真正的定价

当前支付链路已生产验证（真实订单 → 托管页 → 回跳 → Webhook 200），但 Webhook 收到事件后还没落库——下一步是接用户系统、把订单和权益打通。定价策略明天开始聊：免费额度怎么调、PAYG 单价怎么定、要不要订阅包、Enterprise / API 怎么拆。

Build in Public 记录：第一次给自己的产品接支付，比想象中顺——不是因为支付本身简单，是因为选型选对了 + Agent 把 boilerplate 写完了。如果你也在 Lovable / 类似平台上做 indie SaaS、主体在国内、想收全球用户的美元，Clink 值得看看。

有需要那份可以直接拿给Agent看的接入文档可以即刻私信我，想vivo50的也可以试试pricing页面中间那档hh

WaytoAGI × 红杉中国的 AGIBuilder 孵化营，6 月 15 日至 28 日，上海 + 线上，为期 14 天。面向早期 AI 项目，从 Idea / Demo 往真实用户和真实反馈推一步——商业导师、种子用户验证、投资人反馈、食宿和算力支持，入围线下团队在上海红杉创新加速器期间食宿全包。报名截止 6 月 2 日。

我打算去待几天，带电脑，主要就是在那儿办公。有增长、SEO、vibe coding 相关的问题，欢迎来现场聊，或者即刻私信先约。

1️⃣SEO 这块，我日常会聊这些：
早期产品怎么选关键词和 landing 结构，而不是堆一篇「产品介绍」就等收录
工具型 / SaaS 页怎么按搜索 intent 切片——交易型、规格型、场景型、时效型，各自该长什么样
内容页和 pSEO 怎么控节奏，哪些该手写、哪些不该批量灌
OG 图、分享预览、meta 标签——怎么进发布流程，而不是上线后再补
GSC / GA 跑起来之后，先看哪些指标、怎么判断一页值不值得继续投入

2️⃣增长这块，偏早期、偏可执行：
冷启动阶段渠道怎么排优先级，什么适合 daily、什么适合等 milestone
免费工具、内容资产、产品页之间怎么互导，而不是每个 URL 各打各的
独立开发者 / 小团队怎么在没投放预算的情况下拿第一批真实用户
Build in Public 怎么和内容 SEO 并行，而不是二选一
什么时候该做 vertical landing、什么时候首页就够了

3️⃣vibe coding 这块，聊的是怎么在 AI 辅助开发里真的把东西 ship 出去：
用 Cursor / Agent 做产品，哪些环节提速明显，哪些反而要人工把关
prompt、页面结构、组件复用——怎么少返工
「先能跑」和「能上线给人用」之间，通常卡在哪几步
一个人或小团队，怎么在有限时间里兼顾产品、页面、增长

我去主要是自己干活，顺便开放交流。你可以带着具体问题来——一页 landing 不知道怎么写、不确定该先做 SEO 还是先做社区、vibe coding 做到一半卡住——都可以。也可以不聊问题，就是来看看别人怎么在 14 天里推项目，各干各的也行。

报名截止 6 月 2 日。6 月 15 日开营，上海见；想提前对的，即刻私信。

#AGIBuilder

这个主题绝对属于能蹭热点的“新词”

今天上线了一个超级好看的2026 FIFA World Cup 专题页。距赛事开幕（2026 年 6 月 11 日）约两周，页面以「时效性 vertical landing + 产品 preset 预调优」为定位先行发布，后续将依据 GSC 检索表现与生成转化数据迭代。

页面在信息架构上独立于通用 OG Generator 首页。通用首页主要承接「og image generator」类交易型检索；世界杯页则按输出规格与用户场景拆分为三个内容模块——Banner generator（1200×630）、Poster generator（1080×1080）、Story generator（1080×1350），分别覆盖链接预览、社媒方图、竖版 Story / 倒计时等检索 intent。

视觉层面，整页采用六层纵向连续手绘背景（Hero、Generator、Banner、Poster、Story、Closing），形成统一的赛事视觉系统，而非在通用 SaaS 模板上替换标题文案。交互区下方三个 section 各自主打一种输出比例，并对应一座 2026 主办国球场意象：Banner 模块为墨西哥阿兹特克球场（1200×630 横版），Poster 模块为美国现代球场（1080×1080 方图），Story 模块为多伦多 BMO Field 与 CN Tower（1080×1350 竖版）。三块背景共用同一设计语法——一侧为奶油色文案区，

另一侧为球场摄影；卡片区域在背景中预先绘制形状与画面，前端通过透明内区、描边框与文字 overlay 叠加，使球场影像从背景层透出。设计意图在于：用户滚动至各 section 时，无需先执行 Generate，即可建立对输出形态的直观预期，降低首次使用的心理门槛。

功能层未另起技术栈，仍沿用 Oginify 现有 AI 管线（页面理解、图像生成、浏览器端裁切）。与通用 Generator 的差异在于 preset 层：六个赛事 scene（赛报海报、球场、奖杯、球员致敬、倒计时、球迷横幅）替换通用 style chip；尺寸列表调整为赛事期间高频分享的五种格式；prompt 固定 2026 语境，并内置商标护栏（默认不生成 FIFA 官方标识、2026 官方 emblem、Jules Rimet 造型等）。FAQ 已明确说明与 FIFA 无隶属或许可关系，输出适用于 fan、editorial 及多数独立商业场景。输入支持 Text、URL、Reference image 三种模式，其中 URL 模式读取目标页的 og:title 与 og:description 作为生成上下文，适用于赛报、赛程及球队页面。

当前阶段尚处 early stage，event vertical 相对通用首页的转化效率有待 GSC 与 GA 数据验证。

Build in Public 进度记录：大概是小团队2～3周的工作量了，手把手教你怎么做内容营销和SEO

所有工作集中在过去两天内完成。不从产品功能清单切入，而从增长、内容与 SEO 视角梳理：各 URL 所覆盖的搜索意图、免费工具与 pSEO 页面的互导关系，以及测量体系的补齐情况。

核心判断保持不变：若仅依赖单一「og image generator」首页，搜索覆盖面与转化漏斗均过于狭窄。用户进站动机各异——查询规格、排查 meta、参考案例，或尚未意识到 OG 缺失——需由不同 landing 分别承接，再汇聚至 Generator。以下按此逻辑展开。

1️⃣ 搜索意图矩阵：按问题类型拆分 landing，而非依赖单一首页

OG 相关检索词并非同质集群。交易型（如「og image generator」）指向工具选型；规格型（如「twitter card generator」「responsive display ad image size」）反映用户已明确平台约束；诊断型（如「og image checker」「why is my link not showing preview」）源于既有问题待解；信息型（如「og image examples」「sites without og image」）则处于认知建立阶段。若仅保留首页 Generator，可覆盖的主要是竞争最为激烈的交易型词，其余三类意图将让位于竞品或内容站点。

过去两天上线的 output 扩展页，在 SEO 层面旨在横向复用同一转化能力、纵向切开不同搜索入口。Twitter Card 页（oginify.com）对应「1200×675」「summary_large_image」「X 时间线裁切」等 query cluster，与通用 OG 的 1200×630 相邻但彼此独立。Responsive Display Ad 页（oginify.com）对应 Google Ads / GDN 的「1200×628 + 600×600」「20% text rule」，目标用户偏 performance marketing，与 SEO 从业者部分重叠但并非同一人群。底层虽共用读页出图能力，各 URL 的 title、H1、FAQ、示例图及 meta 说明均按对应平台规范单独撰写——属于规格型 long-tail landing 的常规做法，而非简单增设导航 tab。

2️⃣ Input 多模态：覆盖「无可粘贴 URL」的长尾需求

URL → OG 路径适用于「已有落地页、需补全 meta」的场景；然而搜索与传播中仍存在大量无稳定 URL 的用例：活动视觉、Newsletter 头图、尚未上线的 launch page、仅有 logo 而无站点等。若仅保留 URL 入口，该部分流量将流失，且在「ai og image from text / from logo」类检索词上无法形成有效覆盖。

Text to OG（oginify.com）与 Image to OG（oginify.com）从增长角度旨在扩大可索引工具面并降低首次使用门槛。Text 路径内置 Enhance（提示词扩写），面向以中文描述需求、但不习惯撰写英文 prompt 的用户群体。Image 路径支持 Logo / Reference 标签，面向「持有参考卡片或截图、需按风格出图」的工作流，与模板类设计工具有用户交集，但 landing 文案聚焦 OG 规格而非通用设计场景。两条路径均支持 1200×630 / 1200×675 / 1080×1080 输出，便于与 Twitter、Instagram 等场景的内链互导。

3️⃣ 免费小工具：零 AI 成本的 SEO 漏斗入口

AI 生成受额度与单次成本约束；而「og image checker」「screenshot to og image」「free og image maker」等 query 的竞争强度通常低于 head term，且用户意图更为明确——优先解决问题，而非试用 AI。过去两天上线的三个免费工具页，定位均为「可被检索、可被收藏、不承担 AI 成本」：

Open Graph Validator（oginify.com）为漏斗中的关键节点。页面解析 og:* 与 twitter:*，输出 0–100 评分及 pass/warn/fail 清单，并在 X、Facebook、LinkedIn、Slack、Discord 五端提供预览。SEO 层面聚合 Facebook Sharing Debugger 及各平台 inspector 类需求；用户教育层面，直观展示「分享后的实际呈现」，较 landing 文案更具说服力。诊断型流量进入后，存在缺图问题的用户可自然流向 Generator 或 Free Maker。

Free OG Image Maker（oginify.com）覆盖另一关键词带：「og image template」「free og image maker」「vercel og alternative」。目标用户需要在浏览器内编辑文案、导出 PNG、无需注册——而非依赖 AI 生成。20 个模板分 Minimal / Editorial / Developer / Bold 四类，本地渲染，无上传环节。承接「明确需要 1200×630，但不愿订阅或自建 Satori」的需求，与首页 AI Generator 形成互补而非相互蚕食。

Above the Fold（oginify.com）对应「screenshot to og image」「above the fold og」等检索词。多数落地页最贴近实际的分享图即首屏内容；页面标题本身即具教育属性。采用无头浏览器截图并经浏览器端裁切为 1200×630，不占用 AI 配额。与 Validator 组合，形成「先校验预览 → 再截图或 AI 补图」的完整路径。

三页之间的内链与 CTA 设计为单向漏斗：Validator / Above the Fold / Free Maker 完成问题识别或出图后，如需品牌贴合或批量处理，再引导至 AI Generator。免费页承担搜索流量与信任建立；额度与付费逻辑保留于 AI 路径——属 early-stage 控制获客成本的务实安排。

4️⃣ Programmatic SEO：三条 use case 线，重质量、控节奏

pSEO 的主要风险在于过早批量产出薄内容导致域名质量受损。Oginify 内部文档中，page-type / site-type / style / image-size 四个维度可穷举数十至上百个 landing，但过去两天仅上线近二十条搜索意图清晰、与产品强相关、且可撰写非模板化正文的线路：

页面类型示例：oginify.com — 覆盖「homepage og image」「og image for landing page」等词，正文按 SaaS / 电商 / 媒体 / dev tool 分场景展开，各段附示例 card 及可复制 prompt。

网站类型示例：oginify.com — 覆盖「shopify og image」「product page open graph」等词，于单 URL 内展开 PDP / category / campaign / homepage 四层意图，信息量高于单一「ecommerce og generator」页面。

风格示例：oginify.com — 覆盖「neo brutalist og image」「brutalist social card」等审美长尾，竞争较低，传播属性较强。

各页结构统一：hero、价值说明、3–4 个场景块（含示例图）、prompt 可复制区、FAQ 及回链 Generator 的 CTA。非 CMS 批量灌字段，而是设定手写 quality bar；后续将按同模板扩展 page-type（pricing、changelog 等）与 site-type（SaaS、docs 等），但节奏保持审慎。衡量标准并非 URL 数量，而是各页能否独立获得 impression 且跳出率可控——需待 GSC 运行数周后方能评估。

5️⃣ 内容三件套：Gallery 与「缺 OG 清单」覆盖相反检索意图

oginify.com 与 oginify.com 围绕同一主题，但 SEO 意图刻意区隔。

Gallery 手工 curated 约 100 个知名产品的真实 og:image，按 SaaS / AI / Dev tools / Design / E-commerce 等分类。各品牌名本身构成低竞争长尾（如「stripe og image」「notion og image」），检索用户多为寻求参考的设计师与 growth 从业者。页面承担 inspiration → Generator 的转化路径。

Websites Without 为自动审计快照：当前跟踪 21 个知名站点（HN、Berkshire Hathaway、W3.org、GNU、arXiv、xkcd、Paul Graham 等），标注 og:image / title / description 缺失项并注明 snapshot 时间。覆盖「websites without og image」「missing open graph tags」及品牌 + missing og 等诊断词。叙事定位为「知名站点亦存在遗漏，建议自查」——与 Gallery「参考最佳实践」形成对照，二者均导向 Validator。

此类页面的竞争壁垒在于真实数据与手工验证，较 AI 批量生成的 listicle 在 EEAT 维度更具可信度，亦更易获得传播。主要风险为数据过期及点名可能引发的公关问题——页面保持中性 audit 口径，并提供 takedown / recheck 联系渠道。Platforms Built-in（各 CMS 内置 OG 能力梳理）规划为第三件，与上述两页构成完整决策链：参考灵感 → 对照反面 → 评估平台能力 → 必要时选用 Oginify。

6️⃣ 数据基建

页面扩张需配套测量，否则 pSEO 与漏斗优化缺乏依据。同期已完成 Google Search Console 域名验证、经 Google Tag Manager 部署 Google Analytics、以及 Bing Webmaster Tools 接入；IndexNow API 计划于下周对接，以缩短新页索引发现周期。后续将依据 GSC query 报告与 GA 来源数据，分别评估各 landing 的检索表现与漏斗转化。

7️⃣ 商业化：API 与 Enterprise

oginify.com 页面已上线，当前为 invite-only beta，通过邮件申请接入。定位并非现阶段 revenue 来源，而是叙事占位与 lead capture：在公开 API 契约之前，先收集 CMS 集成、CI 批量出图、SaaS 内嵌等真实场景。与开源 social-cards-skills 形成「自托管 vs 托管 API」两条路径，分别覆盖开发者与希望零运维的团队。

Enterprise 落地页尚未上线，方向仍在评估中。Build in Public 阶段，站点优先目标是跑通「内容 → 搜索 → 工具 → 分享」闭环并积累案例；toC 订阅受 OG 需求频次限制，纯个人站长路径难以支撑可持续商业化。更可能的路径指向 B 端——CMS 插件、Agency 批量、API 按量——但具体形态尚未定案，文档与页面层先保留接口与叙事空间。

8️⃣ 站外：BiP 内容、付费目录与外链

站内矩阵负责承接搜索流量；站外负责冷启动认知与 referral 信号。

Milestone 1 已发布 LinkedIn carousel www.linkedin.com
与 X 中文 Article x.com（Build in Public 首发），全文归档于项目 social-posts。BiP 内容与 SEO landing 为两条并行线：社媒渠道呈现决策过程与踩坑记录，landing 页承接 search intent，二者互不替代。

付费目录方面，已提交 TAAFT（There's An AI For That）$347 及 Toolify $99 推广。AI 工具类早期流量部分来源于目录站点；ROI 需待 GA referral 数据运行数周后评估，但现阶段完全依赖 organic 过于理想化。同时在自有站点及其他渠道补充指向 oginify.com 的外链，作为 domain 与 entity 信号的基础建设。

9️⃣ 优先级小结

概括而言：过去两天内完成了「搜索意图切片 → 免费漏斗入口 → 内容正反资产 → 测量层」的骨架搭建，而非先堆功能再补增长。

后续数周将重点观察：GSC 中哪类 query 率先产生 impression（Validator 诊断词、use case 长尾、规格型 landing）；免费工具与 AI Generator 的路径转化率；Gallery / Websites Without 的索引与长尾词分布；TAAFT / Toolify 收录后的 referral；IndexNow 接入后的新页 discovery 效率。use cases 按质量优先原则继续扩展，Enterprise 页上线时间待定。API beta 将收集首批 CMS / CI 集成需求，以验证 B 端叙事可行性。

体验到了做产品的乐趣

Build in Public 补充：在 Lovable 上把 OG 图尺寸这件事跑通，比我想象中费工夫。

Oginify 目前仍托管在 Lovable，底层用 Google Gemini 出图。产品路径是：粘贴 URL → AI 理解页面 → 输出四张 1200×630 社交分享图。听起来是标准流程，实际开发里，我在「模型输出 → OG 交付规格」这一环上迭代了相当久。

1️⃣ 两类典型失败，且往往不能同时避免

在 Lovable 内置 Gemini 生图时，我反复遇到两种问题：

第一种：不强制尺寸约束时，模型常返回大于或偏离 1200×630 的图片——比例可能是偏方形、3:2 或其他。文件能下载，但不符合 OG 规范；贴入 meta 后，各平台预览会自行裁切，最终用户看到的构图不可控。

第二种：强制输出 1200×630 时，尺寸达标，但裁切后信息损失严重——标题、logo 或主视觉被切掉，观感明显变差。根因通常是：模型按原生比例（如 1:1 或 3:2）生成满幅内容，再被硬裁进 1.91:1 画框，重要内容落在裁切区外。

直观感受是：问题不在「设计好不好看」，而在画布比例与交付比例不一致。

2️⃣ 1200×630 并非多数模型的默认输出

查阅 Gemini、GPT 等图像 API 后，结论比较一致：

Open Graph 常用规格是 1200×630（约 1.91:1），Facebook、LinkedIn、Slack 等链接预览均围绕这一比例。但主流生图模型很少提供「精确 1200×630」的一键输出——GPT 系多为 3:2（如 1536×1024），早期 Gemini 图像模型常见 1024×1024。要得到 OG 规格，往往需要在后端或前端做缩放、裁切，而裁切策略直接决定内容是否完整。

这也解释了 OG 图在 SEO 工作流里长期被后置：不是需求不存在，而是工具链默认不优先解决 1.91:1 的标准化。

3️⃣ 当前方案：预制 prompt + 中心安全区留白

在仍使用 Lovable 的前提下，我采用的 workaround 是：在预制 prompt 中不再强依赖「输出 1200×630」这类模型时常忽略的尺寸指令，改为：

让模型按原生比例出图，但要求所有可读内容——标题、logo、主视觉——落在画面中央的 1200×630 安全区内；安全区之外保持留白（纯白），不放关键信息。

裁切仍按 1200×630 执行，但裁掉的是留白区域，而非内容本身。跑通后，四张图（品牌贴合 + 三种风格）的主体完整性明显改善，终端风、杂志风等风格不再出现「半行标题」类问题。

代价是构图偏保守，部分平台缩略图可能略空；相比不可控的硬裁，这是目前可接受的 trade-off。

4️⃣ 这段经历对产品设计的意义

Build in Public 对我而言，不只记录功能上线，也记录这类「看起来次要、实则阻塞体验」的细节。

OG 图尺寸不是像素洁癖：它关系到 Validator 评分、Gallery 对照案例、以及用户分享链接时的第一印象。在 Lovable 上先把这条链路摸清楚，比过早讨论架构迁移更有价值——至少对我这个第一次做产品的人是这样。

5️⃣ 后续

项目仍在 Lovable 上迭代；支付、Validator、Gallery、开源 skills 等模块会继续在现有栈上完善。尺寸管线方面，也在关注能否通过 API 层 aspect ratio 等方式，减少对白边 workaround 的依赖——有进展会照常公开。

m.okjike.com
Build in Public 第二天，四个更新。

1️⃣支付准备就绪 oginify.com
Stripe步骤太繁琐还没弄完，先用了Clink，操作起来很方便；Day 1 就把商业化路径摆出来，接入还没完全跑通，先挂上。

2️⃣OG 校验器 oginify.com

贴 URL → 解析 og:title、og:image、og:description、twitter:card 等全套标签 → 0–100 综合评分 + pass/warn/fail 逐条清单。X、Facebook、LinkedIn、Slack、Discord 五个平台实时预览同一张图的效果。

这个产品不是拍脑袋加的。做 SEO 的都知道，OG 图问题分两种：一种是图不好看，一种是根本没配或者配错了。校验器解决第二种——而且量比第一种大得多。大多数站点的 OG 标签要么缺字段、要么尺寸不对、要么 twitter:image 和 og:image 冲突。
从产品角度，Validator 是 Generator 的漏斗顶部。用户来查问题 → 发现缺图或尺寸不对 → 旁边就是生成器入口。不用讲"OG 图很重要"这种正确的废话，让你自己看到评分低就难受。

3️⃣OG 图库 oginify.com
约 100 个知名品牌的真实 og:image，按 SaaS / AI / Dev tools / Design / E-commerce / Media / Fintech 分类。品牌方想下架邮件联系。
两个目的。第一层是 SEO 资产：Gallery 页面天然吃长尾搜索——"og image examples""social share card inspiration""最好的 OG 图案例"这类词，竞争对手没人认真做内容，这是个空位。100 个页面 × 品牌名 + 行业标签，搜索表面积不小。第二层是产品留存：用户不知道 OG 图能做成什么样，看案例比看教程有用。Gallery → Generator 是另一条漏斗。

4️⃣开源 social-cards-skills github.com
MIT 许可。og-image-generator（1200×630）+ twitter-card-image-generator（1200×675），6 种风格（Terminal / Magazine / Swiss / Pixel / Brutalist / Newspaper），Satori + resvg 渲染，Agent-Native 工作流。一行安装：npx skills add kostja94/social-cards-skills。
为什么开源：增长靠内容太慢，靠分发才快。开源项目是我验证过的增长和 GEO 双杠杆——之前其他 skills 靠 npm 安装量 + GitHub 自然流量拿到了很好的结果。GPT、Claude、Cursor 这类 Agent 生态里的可发现性，比搜索引擎的点击率靠谱。一个 npm 关键词排名带来的安装量，顶十篇 SEO 文章。Oginify 是产品，skills 是增长引擎，两个不冲突。

今天还加了多语种，把GSC，Google Tag Manager，robots，sitemap一批technical也一起弄完了🫠

看点我从100个产品里面找出来有设计感的OG图👇

m.okjike.com突然发现，原来我两年前就想做这个产品了

忘记算了🫠，识别主站用的是内置的Firecrawl（之前活动送了20万credits），fetch好像很多网站都提取不到信息；单次完整生成 ≈ $0.30
1️⃣Firecrawl 爬取 — $0.025（~8%） `/v2/scrape` + JSON extract，5 credits。基础爬取 1 credit，加 AI 结构化提取 +4 credits。如果页面 meta 信息本身够丰富（og:title/description/image 都完整），其实可以跳过 JSON extract 省掉这笔。代码里 `fetch-meta` 已经有了这个 fallback，但 `analyze-content` 路径每次都走 Firecrawl，加了短路逻辑就能省。

2️⃣LLM 内容理解 — $0.003（~1%） `gemini-3-flash-preview`，输入大概 3–5k tokens（页面 markdown 截断 8000 字符 + system prompt），输出 400–600 tokens（structured JSON）。$0.30/M in + $2.50/M out，这笔基本是零头。

3️⃣图像生成 ×4 — $0.268（~88%） `gemini-3.1-flash-image-preview`（Nano Banana 2），$0.067/张 × 4。这是绝对大头。切 Nano Banana 原版（`gemini-2.5-flash-image`，$0.039/张）能降到 $0.156，但今年 10 月 2 号下线，只能短期过渡。如果换 `openai/gpt-image-1-mini`（~$0.011/张），4 张只要 $0.044，总成本直接压到 $0.07。 //@hiyeshu: 没有识别主站的成本嘛