让 AI 生成的项目学会收钱：Stripe 集成实战指南
vibe coding 项目从 demo 到生意的距离，往往就是一个支付按钮。Stripe 是对 vibe coder 最友好的收款方案：文档写得让 AI 一读就懂，Checkout 托管页面零前端，Payment Links 甚至 5 分钟就能收款。这篇指南给两条集成路径、从 0 到第一笔钱的实操步骤，以及四个一定会踩的坑——其中第一个坑每年都让无数人丢钱。
为什么是 Stripe：对 vibe coder 最友好的三个理由
vibe coding 项目从 demo 到生意的距离，往往就是一个支付按钮。而在所有收款方案里，Stripe 是对「让 AI 写代码的人」最友好的一个，理由有三。
第一，它的文档是写给 AI 看的。这不是夸张：Stripe 的 API 文档结构清晰、示例完整、版本标注明确，是 agent「照着文档一次写对」成功率最高的一类文档。你给 agent 的 prompt 里贴上文档链接，它大概率第一次就能跑通。对比某些支付服务商 PDF 时代的文档，这个差距是代际的。
第二，Checkout 托管页面让你零前端收款。你不需要自己画卡号输入框、不用碰 PCI 合规——Stripe 托管的结账页处理一切，你只负责把用户送过去、把支付结果拿回来。对于「设计已经够让 agent 头疼了」的 vibe 项目，这是救命稻草。
第三，Payment Links 让你 5 分钟收到第一笔钱。在 Stripe 后台建个产品、定个价，生成一条链接，贴到你的落地页上——完事。验证期根本不需要写一行代码。记住这个顺序：先收到钱，再谈集成。
两条路：5 分钟的 Payment Links，和 1 小时的 Checkout 集成
路线 A：Payment Links（验证期）。适合场景：你还不知道有没有人愿意付钱。操作：在 Dashboard → Payment Links 新建，选产品、定价、是否允许优惠码，生成链接。把链接放到你的落地页按钮上。用户付款后，你在 Dashboard 看到订单，手动开通权益。丑，但是快。很多 indie 项目靠这条路线跑了三个月才写第一行支付代码——这是正确的顺序。
路线 B：Checkout Session + webhook（正式）。适合场景：有人付钱了，你需要自动化。流程：用户点「订阅」→ 你的后端创建 Checkout Session（调 Stripe API，5 行代码）→ 跳转 Stripe 托管结账页 → 用户付款 → Stripe 向你的 webhook 地址发送 checkout.session.completed 事件 → 你的后端验证签名、落库、开通权益。全程你唯一要写的「难」代码，就是 webhook 的签名验证。
给 agent 的 prompt 模板（直接复制可用）：「用 Stripe Checkout 实现订阅支付。技术栈是 [你的栈]。要求：1）创建 Checkout Session 的 API 路由；2）接收 checkout.session.completed 的 webhook 路由，必须用 Stripe 官方 SDK 验证 webhook 签名；3）价格 ID 从环境变量读，不要 hardcode；4）区分 test 和 live 模式。参考 Stripe 官方文档的 Checkout 快速开始。」
四个一定会踩的坑
坑一：webhook 不验证签名。这是每年都让无数人丢钱的坑。你的 webhook 地址是公开的，任何人都可以往它发 POST 伪造「付款成功」。正确做法：只信任 Stripe-Signature 头，用官方 SDK 的 constructEvent 方法验证。让 agent 写 webhook 时，把「必须验证签名」写进 prompt 的第一行，而不是备注里。
坑二：测试 key 和正式 key 混用。Stripe 的 test 模式和 live 模式是两套完全隔离的世界：key 不同、产品不同、webhook 不同。上线前检查清单只有三行：环境变量里是 sk_live_ 开头吗？Dashboard 右上角的「Test mode」开关关了吗？webhook 地址配的是 live 模式的 endpoint 吗？这三行每年都能救几个人。
坑三：价格在前端算。永远不要在前端决定用户付多少钱。正确姿势：价格只存在 Stripe 的 Price 对象里（用 Price ID 引用），后端创建 Session 时传 Price ID。凡是「前端传 amount 给后端」的写法，都是等着被薅羊毛——把价格改成 1 分钱只需要打开开发者工具。
坑四：订阅的 trial 和 proration 没想清楚就上线。免费试用几天？试用结束自动扣费还是要用户确认？用户中途升级套餐，差价怎么算（proration）？这些不是技术问题，是产品问题，但必须在写代码之前定下来——因为 Stripe 的每个选项都对应不同的 API 参数，返工比想清楚贵得多。
收到第一笔钱之后：定价、税务和退款
技术跑通只是开始。定价上，vibe 项目有个经验锚点：$9 / $19 / $49 三档，$19 是主力。别一上来就定 $99——你的获客渠道还撑不起高客单价；也别定 $3——支付手续费（Stripe 约 2.9% + $0.30/笔）会吃掉你不成比例的利润。
税务上，如果你有美国或欧洲用户，打开 Stripe Tax，让它自动算税。手动处理跨国税是地狱，别碰。退款政策页面是必须的——不写清楚退款规则，chargeback（拒付）纠纷会让你怀疑人生。最后一条经验：在收到第一笔钱之前，别谈「商业模式」。商业模式是收到钱之后才配讨论的东西，在此之前，你唯一的 KPI 就是那条 Payment Links 有没有人点。
从 demo 到生意，中间只隔一个支付按钮。而这个按钮，今晚就能加上。
相关文章
Zephos 团队在一个 Agent 搭起来的 Next.js + Supabase + Stripe 笔记应用里埋了 16 个上线杀手级问题，其中 2 个和支付有关：webhook 没验签、拿客户端传的 plan 直接开 pro。这篇指南把这两个坑拆成一套可落地的实战方法：webhook 签名三件套、服务端唯一真相源、订阅状态机、测试时钟和沙盒到生产 checklist。核心判断：和钱相关的逻辑必须手写或逐行审计，agent 只能写样板。
每个 vibe 项目迟早需要定时任务：每日数据同步、过期订单清理、账单对账、定时报告。AI 给你的第一个版本通常是 setInterval——开发够用，生产必死。这篇实战给出四种跑法的选型地图（应用内/Vercel Cron/GitHub Actions/Cloudflare），cron 表达式速查与时区坑，幂等性、防重叠分布式锁、失败重试与告警、可观测性 run log，以及 cron 接口的鉴权，最后附上线清单。
每个 vibe 项目迟早会遇到同一个时刻：列表页一打开就要查十几次库，并发稍高数据库就被打满。这篇实战从缓存的三问心智模型讲起，逐层拆解 HTTP 缓存头、Next.js 数据缓存、Redis 应用缓存与 AI 结果缓存（语义缓存/prompt 缓存），给出缓存键设计、穿透击穿雪崩的三件套解法和失效策略，最后附一份上线检查清单。