【商业化】做能收钱的海外AI产品
2647 人学过
一、什么是MicroSaaS？ 一个人也能做的订阅制生意
一、回顾
恭喜你看到这里！
你应该已经发现，我们上一章节的前面几节课，其实一直在为这节课铺路。
我们讲过从抱怨里找需求，从供需失衡里找机会，训练 Alpha 意识，以及“新词站”——怎么先抢入口、先接住第一波现金流。
把这些串起来，你会看到一条很清楚的线：
发现痛点、解决问题、提供服务，开发产品，赚“持续解决同一类问题”的钱。
新词站，很多时候赚的是"这几天、这几周"的时间差。词刚冒出来，需求涌上来，供给还没长齐，谁先做页面、先接支付，谁就先收钱。窗口关了，这波也就差不多了。
它也可以算一种MicroSaaS，但是周期一般不会太长。
标准的MicroSaaS 不一样。它面对的问题，从来没有"窗口关闭"这件事。某群人不是来看一次热闹，他们会反复回来解决同一个麻烦。
新词站，是先把门站住。
MicroSaaS，是把门后面的房子盖起来。
前者验证"有没有人进门"，后者验证"进来的人会不会留下来，并且反复付钱"。
二、什么是 MicroSaaS？
SaaS 的意思是 Software as a Service ， 软件服务。
那 MicroSaaS 是什么呢？
下面是我的定义
MicroSaaS，就是面向很窄的人群、解决一个具体问题、通常由一个人或极小团队运营、靠订阅或经常性付费活下去的软件产品。
你注意，我不断在强调“小”。
除非你是大厂，否则创业机会，总是从“小”的地方开始。
拆开看，这里面有四个关键点。
人群很窄。 它不是做给所有人用的。它往往是做给某一类很具体的人：独立开发者、跨境卖家、数据分析师、Shopify跨境电商店主、用 Notion 做知识库的人……很多时候，人越窄，越容易付钱。因为问题更具体，价值更直接。
问题很具体。 不是"提升企业效率"这种大话。而是：把自然语言变成 SQL、自动回复客户常见问题、把表单数据整理成可用格式、自动生成 SEO 页面。MicroSaaS 最怕的，不是问题太小，而是问题说不清楚。
团队很小。 很多 MicroSaaS，真的就是一个人做起来的。登录、支付、数据库、发邮件、AI 能力，今天几乎全有现成积木。你前面学的那套"预制菜思维 + 积木思维"，在这里真正落地了。
收入可重复。 月付也好，年付也好，credits 也好，本质都一样：用户愿意持续掏钱。这才是 MicroSaaS 真正值钱的地方——不是一锤子买卖，是长期关系。
三、MicroSaaS 真正卖的是重复
很多人听完会说："哦，就是做个小软件，搞个月付。"
也不能说不对吧，但是有点浅。
订阅，是问题的时间结构。
不是你页面上写了"$19/month"，这件事就成立了。
真正决定用户愿不愿意订阅的，是这件事：这个问题会不会反复出现，这件事要不要反复做，这个麻烦值不值得长期外包给工具。
如果一件事，用户一年只做一次，你凭什么每个月收他钱？
但如果一件事每周都要做，每次都浪费时间，每次都容易出错——他就很容易愿意把它交给一个工具长期代劳。
一次性需求，最多卖工具。重复性需求，才有机会卖订阅。
这也是为什么很多看起来不性感的工具，反而很赚钱。
靠的不是酷，靠的是烦。
越烦、越频繁、越标准化，越容易长成一门生意。
四、真实例子
我最喜欢讲的例子还是Citely，前面已经讲到过了。
一句话说清楚它做的事：把AI生成的虚假论文信息找出来。就这一件事。
你套前面讲的内容看看，会发现它解决的问题特别小。人群小、问题具体、团队小（1个人）、收入可重复（因为需要重复解决问题）。
唯一不小的是它的收入规模。这里我就先保密了，我会在合适的时候让Citely 的创始人来做一个分享。
Citely 没有做"全能学习助手"，没有做"AI 论文写作平台"，没有做"学生一站式工具箱"。
它只盯住了一个极其具体的麻烦——把AI生成的虚假论文找出来、把AI生成的虚假论文找出来、把AI生成的虚假论文找出来。这几乎是它的唯一功能！
这个问题有多高频？只要你在写论文（今天无论谁写论文，都会用AI协助），问题就会来。每篇都来。
Citely 就是把这一个动作做成了工具，然后收订阅费。
它卖的是：这件烦事，虽然很小，但是以后不用你自己动手了。
类似的其他的例子还有：
•
Resend：
◦
只做一件事 —— 帮做SaaS的人解决“给用户发邮件”这个小问题。我自己也是Resend的用户
•
Cleaup Pictures
◦
只做一件事 —— 帮你去掉一张图片里你不想要的内容。（比如旅游拍照，把路人P掉）
但这几个产品的用户口碑、用户规模、收入量级，都不小。
你已经学到这一课了， 这种产品的技术难度，对你来说并不大吧？ 基本上就是找到2～3个合适的API，做一个好用的交互，保证每次都能稳定发挥。
难的从来不是技术，而是发现真需求、解决真问题。
五、最大误区：做了伪需求
今天 AI 编程的能力越来越强， 做一个产品出来的门槛已经很低了。
我见过做 MicroSaaS 失败的，最大的原因只有一个 —— 做了伪需求。
如果一个问题，用户可以随便对付一下就过去了，危险。
如果不解决也没什么大不了的，危险。
如果只有很偶尔才出现一次，危险。
这个世界不再需要第10001个天气App，或者套壳的文生视频产品。
去找那些尚未被解决过的真问题吧！ （如果还不清楚怎么找，回到课程的上一章节复习）
我们再次强调：
1.
“需求”就是“有人愿意付出代价”。
2.
“产品”就是一个具体问题的解决方案。你解决的问题越麻烦、越具体，你的产品就越有价值。
3.
公式：什么人在什么场景下愿意花多少钱解决什么问题
你做的是不是伪需求？先用这三条自查。
回顾
MicroSaaS 不是缩小版的创业神话。
它是把一个反复发生的小问题，做成一门持续收钱的小生意。
以后你再看到一个需求，希望你脑子里跳出来的，不只是"这个功能能不能做"，而是多问自己：
•
这个麻烦，会不会每个月都来？
•
这个麻烦，如果有人尝试解决过，别人的解决方案足够好吗？ 我能比别人做得更好？
•
我能接触到有这个麻烦的真实用户，我能拿到真实反馈吗？
如果答案都是肯定的，恭喜你，有机会把它变成一门生意。
好，你已经知道什么是 MicroSaaS 了，下节课进入正题，我们拆解MicroSaaS 的基本构成！
下节课见！
二、MicroSaaS产品四件套：落地页、用户中心、核心功能、支付
前言
上一课我们搞清楚了 MicroSaaS 是什么。
这节课，我们往下走一步：一个 MicroSaaS，最少需要哪几块？
答案是四块。
我把它叫做产品四件套
MicroSaaS产品四件套：落地页、用户中心、核心功能、支付。
后面几节课，我们会把其中三块单独拆开来讲。现在我想先带你把这四块整体过一遍——每块是什么，为什么你需要它。
如果你不清楚每一块存在的理由，你就会在错误的地方花太多时间，在真正重要的地方反而偷懒。
一、落地页：你只有 8 秒
用户第一次打开你的网站，不会认真读的。
他会扫一眼，然后在 8 秒内做出判断：这东西跟我有关系吗？值得继续看吗？
8秒，就这么短。
落地页，尤其是落地页的首屏，是你在这8秒内打动用户的唯一机会。
它要回答三个问题，而且要快：这是什么？给谁用的？为什么我要掏钱？
很多人做落地页犯的最大错误，是"说自己"——写了一堆功能列表，写了"更智能、更高效、更全面"。
用户不在乎。用户只在乎一件事：这个东西能不能解决我的问题。
所以落地页的核心，不是展示产品，而是描述痛点。
你把用户的麻烦说得越准，他就越觉得"这是给我做的"。
去看 Resend 的落地页，第一句话是：
"Email for developers."
三个字。没有废话。一看就知道是给谁的。
再看Neon的首页。
也只有一句话：
Fast Postgres Databases for Team and Agents
说得少，说得准，说得狠。
这才是落地页该有的样子。句号。
落地页具体怎么做，后面我们会单独讲。
二、用户中心：让人留下来
用户看完落地页，觉得有意思，想试试。
然后呢？
他需要一个账号。需要登录。需要一个地方管理自己的使用记录、订阅状态、账单信息。
这就是用户中心。
很多人觉得用户中心就是个注册登录页面，做完就完了。
不是的。
它背后有一个很关键的逻辑：用户中心，是你和用户之间关系的起点。
没有账号，用户就是过客。
有了账号，他才是你的用户。
你才能知道他用了什么、用了多少、在哪里卡住了、什么时候不续费了。
拿我的 Raphael AI 举个例子，虽然匿名用户（也就是不登录的用户）可以画一些图，但是在匿名用户画图的过程当中，我的产品体验在想尽一切办法、不断地吸引用户去完成登录操作的。必须要他登录了，才是我的真用户，才有可能留存和付费。
用户中心通常包括：注册登录、个人信息、使用记录、订阅与账单。
好消息是，今天这块几乎不需要从头写。Clerk、Auth0、BetterAuth 这类工具，十分钟能接上。你不需要在这里发明轮子。具体怎么做后面会讲到。
但有一点要记住：用户中心和支付必须强绑定。
付费用户能用什么，免费用户能用什么，这条线要画清楚。你产品最值钱的那个功能，一定要放在付费墙后面。关于支付，这也是后面我们要单独讲的内容。
三、核心功能：你真正在卖的东西
前两块，落地页和用户中心，几乎每个产品都差不多。
核心功能，才是你和别人真正不同的地方。
它是你产品存在的理由，是用户掏钱的原因，是你反复打磨的地方。
还是看 Resend。它的落地页很简洁，用户中心很标准，支付也没什么特别。但它的核心功能，"给用户发邮件"这件事，做到了开发者真正喜欢用的程度：API 设计干净、文档清楚、送达率高、调试方便。
就这几点，让它在一堆邮件服务里站住了脚。
宁可只做一件事，也要把这件事做到用户离不开。
MVP 阶段最常见的错误，是功能做太多。
每多一个功能，就多一个出错的地方，多一倍的维护成本，多一层用户理解的负担。
你要问自己：如果把这个功能去掉，用户还有没有理由付钱？
如果没有，那它是核心功能，保留，打磨，做到极致。
如果有，那大概率可以砍掉。别舍不得。
这块没有通用答案，也没有现成工具能帮你。它是你对用户问题的独特理解，只能靠你自己。
至于核心功能怎么做，我们前面的课程已经讲了很多很多了，无论是“纸片人男友”还是“哄哄模拟器”，如果你生疏了，回去复习。
四、支付：让钱真正进来
很多人觉得支付是最后才需要想的事。这个想法会害了你。
没有支付，你做的是玩具，不是生意。
支付应该是你第一天就想清楚的事。
它不只是一个收钱的按钮。定价多少？分几档？要不要试用？订阅按月还是按年？每一个决定，都直接影响你的转化率和续费率。
还是看 Resend。免费版每月 3000 封邮件，够开发者测试和小项目用；付费版按用量阶梯收费，用得越多越便宜。
这个设计背后的逻辑是：免费先让你用起来，再让你离不开，然后自然升级。
这个模式叫做Freemium。 我的很多产品，也是这个模式。
MVP 阶段的支付，建议从最简单的开始：一个免费版，一个付费版，一个高级付费版。 后面还可以增加单独购买积分。别一上来就搞五六个套餐，把自己和用户都绕晕了。
Stripe 是今天最主流的选择，支持订阅、一次性付款、credits 等各种模式。
但对于国内的用户来说，接入Stripe不够方便，其他的方案后面我也会推荐。
具体怎么接，后面单独讲。
五、四件套的真实权重
虽然我列了四件套，但它们的权重完全不一样。
落地页、用户中心、支付，这三块今天都有现成方案，难点在于选型和接入。
你花在这三块上的时间，加起来不应该超过整个 MVP 的三分之一。
核心功能，才是你真正该花时间的地方。
一个常见的死法是什么呢？落地页做得很漂亮，用户中心做得很完整，支付接得很顺滑，但核心功能做得稀烂。
用户进来，用了一次，走了，不回来。
这就好比你装修了一间漂漂亮亮的餐厅，菜单设计得精致无比，收银系统也是最新的——但厨师不行，菜难吃。客人来一次就不来了。
前三块是装修，核心功能是厨艺。装修再好，菜不行，没人来第二次。
Citely 的核心功能很牛，但其它三件套非常简单，甚至可以说简陋。在Citely火了以后，已经出现大量的人来试图抄袭模仿 Citely 了，有的界面做得更加漂亮、定价更加便宜，但是这些都没用 —— 因为这些模仿者的“核心功能”差得很远，只是抄了个皮而已。
回顾
四件套，一句话总结：
•
落地页，解决"用户为什么要进门"。
•
用户中心，解决"用户怎么留下来"。
•
核心功能，解决"用户为什么掏钱"。
•
支付，解决"钱怎么真正进来"。
接下来三节课，我们把落地页、用户登录、支付分别拆开来讲。
等你明白其中的原理后，到"极速开发指南"那节，这三块都会装进 boilerplate 里，你只需要专注做核心功能，然后上线。
下节课见！
三、Landing Page：你只有8秒，用8秒打动用户
好的Landing Page设计原则
看多了产品你会发现，产品首页的结构都差不多，但真正让人想往下看的却很少
其实好的首页都在做同一件事——买时间
好的Landing Page设计原则：买时间
打个比方你就懂了
假设你想找一个大佬合作，但你们素不相识。你精心准备了一份四千字的合作方案。
然后呢？
他不会看的，没有人会打开一个陌生人的四千字。
所以你要怎么办？
你去他楼下蹲着，他总要坐电梯吧？你也跟着进去
电梯里只有30秒，你只能说一句话："我有个想法，可能对你有帮助。能给我五分钟吗？就五分钟。"
他很难拒绝。
这30秒的目的，就只是约到5分钟。
但注意，这5分钟的目的，也不是把方案讲完——5分钟是讲不完的。
你的目的，是用这5分钟，让他愿意跟你约一个小时的会。
看到了吗？每一步的目标都不是"成交"，而是"让他愿意给你下一步的时间"。产品的设计，也是这样的。
用户打开你的页面，只有几秒钟。
首屏，买的是什么时间？买的是他往下滑、去看你功能介绍的时间。
往下滑，买的是什么时间？买的是他点注册、去试用的时间。
再往下，买的才是他掏钱付费的时间。
就这样，一层一层地买。
所以回过头来看，很多人犯的最大的错误是什么？
是把首页当产品说明书来做。
恨不得第一屏就把所有功能都列出来，生怕用户不知道你有多牛。
但你想想，你在电梯里跟大佬说："我这个项目有六大核心功能，第一个是……第二个是……"
电梯门开了，
他走了。
你只有几秒。
首屏就是你的电梯演讲
就像你跟大佬一起坐电梯，你只有30秒的时间一样，用户打开你的首屏，你大概只有8秒。
在这8秒内，你需要打动用户，让他往下滑——买到他1~3分钟的时间，去看完你的全部首页、说服他注册登录。
好的首屏，只需要做好三件事：
简洁。有力。差异化。
一切都是为了在最短的时间内打动你。
给你看两个我觉得做得非常好的案例。
案例一：Neon
它的 Slogan 非常简洁，而且差异化很强——"老子就只干这一件事。"
你可能会觉得，这也太简单了吧？
但你想想，如果它写的是"AI数据管理服务"呢？
虽然也很简洁，但不好意思，真的有点吸引不了人。
市面上叫"AI数据管理服务"的产品少说几十个，你凭什么让人多看一眼？
Neon的聪明就在这里，一句话直接告诉你，我和别人不一样，我只做 Postgres 数据库，我更专业。
加上整个视觉风格，霓虹感十足，跟它的名字（Neon）完全契合。
你打开那个页面，一眼就知道这是一个有品味的产品。
要么往下滑，要么直接点 Get Started。
它买到时间了。
回头看看它做到了什么？
简洁——首屏没有任何多余的东西
有力——一句话就让你知道它是干嘛的
差异化——不管是文案还是视觉，都跟别人不一样
案例二：Simplify
这个更牛
我第一次看到的时候，真的觉得太厉害了
先看文案
Your entire job search. Powered by one profile.
什么意思？你整个求职过程，我全包了
这句话本身就很厉害。用户看完就知道，所有和找工作相关的事情，都可以在这里解决
再看它的功能展示区域
大部分人要展示一个"AI简历生成器"的功能，会怎么做？
放一张润色后的真实简历截图，对不对？上面写着"张三，XX大学计算机系毕业，2020-2023年在XX公司任软件工程师，负责XX项目……"
密密麻麻一大堆。
但 Simplify 没有这么做。
它放的是模糊处理过的简历图片。所有具体文字，全部打码、虚化、用色块替代。
你看不到这个简历是什么人的，写了什么东西。
但你能看懂这个人在用这个平台改简历、投简历、找工作……
就够了。
为什么要这么做？
如果把真实内容放上来，用户的注意力会被分散。
你放了一份完整的简历，用户的眼睛就会忍不住去读"这个人是什么学校毕业的"、"他之前在哪家公司"——但这些信息跟功能本身完全无关。
他在浪费精力去看一个虚构的人的简历，而不是在理解你的产品能帮他做什么。
Simplify 的设计师想得很清楚：我不想让你浪费一丝一毫的精力去看那些不重要的东西。
你看的时候也会觉得更自然、更舒服。
这个设计思路，值得你反复品。因为它背后是一个通用原则：
首屏的一切元素，都应该服务于"让用户理解你是干嘛的"这一个目标。任何偏离这个目标的信息，都是噪音，都应该被砍掉或模糊掉。
还有一个细节，非常巧妙。
这个产品的首页，故意做了半屏。
你看到下面还有东西，就会本能地往下滑。
就这么一个小动作，又从用户手里多拿到了两秒钟。
一切，都是设计好的。包括两侧悬浮的图标
这些 Logo 不抢你的注意力，你甚至一开始不太会去注意。但加与不加，放在一起对比，差别一眼就出来了
好的页面设计，不止是让你觉得"哇好漂亮"，而是让你不知不觉地往下走。
觉得好，但做不出来？
拆完这两个案例，你可能会觉得："我看的时候确实觉得好，但让我自己做，我做不出来。"
这很正常。
关键是你要从"觉得好"变成"知道它为什么好"。
我把它整理成三条：
第一，简洁、有力、差异化。
Neon 的"我只干这一件事"，Simplify 的"你只需要一个 profile"，都是一句话就让你知道产品是干嘛的，而且跟竞品有明显的区分。
不管你的产品是什么，用户在首屏想要知道的，都是"这个功能能帮我做什么"，而不是"这个功能长什么样"。
99%的情况下，答案都是前者。
所以，所有干扰"理解功能用途"的细节，都应该去掉，只留下最关键的视觉信息。
第二，装饰要"不打扰"，但不能没有。
Logo 滚动、渐变色背景、各种动效——这些东西不是核心内容，但它们营造了氛围。
好的装饰让用户"感觉对了"，却说不出来为什么。差的装饰让用户觉得"花里胡哨"，直接关掉。
判断标准很简单：去掉它之后，页面的感觉有没有变差？如果变差了，说明它在发挥作用，留着。如果没变化，说明它是多余的，砍掉。
第三，用设计引导用户的下一步动作。
半屏设计、露出下方内容、滚动暗示——这些都是在用视觉语言告诉用户"下面还有好东西"。你不需要写一行字说"请往下滑"，设计本身就应该完成这个引导。
这里分享一个很有意思的设计。
我们前面提到的导航站 TrustMRR ，在榜单拉到第25名的时候会出现这样一个实时访客地球仪，可以显示目前世界各地都有哪些人正在访问了这个网站。
放在榜单的中间，可能你已经翻无聊了，准备关掉，结果就因为这个小玩意儿，又多停留了几秒。
看到了吗，一切的目的，都是为了向用户买更多的时间。
首屏之下，标准结构照着来
首屏讲了这么多，那首屏往下呢？下面的内容怎么做？
说实话，首屏之下的部分，反而是最不需要你花太多心思的地方。
为什么？
因为它是标准结构。句号。
你去看100个做得好的产品页面，你会发现首屏下面的内容长得都差不多，大概就这几块：
功能介绍
用几个卡片或者图标，把你的核心功能展示出来。
每个功能配一段说明，再加一张功能界面截图，或者是使用流程示意。
CTA（行动号召）
也就是"立即使用"、"免费试用"之类的按钮，贯穿整个页面，隔一段就出现一次，让用户随时能点。
社会证明
用户评价、媒体报道、"已有 XX 万用户"、合作伙伴的 Logo 等等。
这些东西都是在做一件事：告诉用户，不是只有你一个人在看这个产品，很多人都在用了，并且给出了很高的评价。
定价方案
也就是订阅板块，免费版能用什么、付费版多少钱、有没有年付折扣。
FAQ（常见问题）
用户可能会问的几个问题，提前回答掉。
本质上是在消除顾虑。用户不注册，很多时候不是因为不想用，是因为有个小问题没想清楚。FAQ 就是帮他把这个小问题解决掉。
页脚相关信息汇总
包含联系方式、功能分类栏、产品条款、博客等等。
这些板块都有大量现成的模板，根据自己产品的需求选择合适的内容展示就行。
好设计从哪来——翻石头
看完前面的案例拆解，你可能觉得道理我都懂了。
但自己做的时候，还是不知道从哪下手。
那是因为你看得还不够多。
大家应该小时候都有在河边玩的经历：
一块一块地翻石头，大部分石头翻过来，底下什么都没有。但偶尔翻到一块——底下可能有棵小草、有个你没见过的虫子、有条小鱼……
你不知道哪块石头底下有东西，你也没法提前判断底下的是不是好东西——你只能一块一块地翻，翻得够多了，自然也就翻到了。
做 AI 产品，也得有一个“翻石头”的过程。把别人的产品都翻完了，你自然就知道谁好谁不好。
你得自己去打开几十上百个产品首页，看它的首屏长什么样、文案写了什么、配图怎么处理的、用了什么颜色、按钮放在哪里。
一个一个看，才能慢慢体会到，什么是好的设计，它为什么好，差的又差在哪里。
你把好的设计拆清楚了，这就是你的素材。你脑子里存的好设计越多，自己做的时候能调用的就越多，还是那句话：积木思维。
翻石头翻的不是石头本身，翻的是你的判断力。
你翻了一百块石头，你就知道什么样的石头底下大概率有东西、什么样的不值得翻。产品也是一样。
很多人翻石头，只在一条河里翻。把这条河翻烂了，实在翻不出什么新东西了。
其实除了看 AI 产品，你完全可以向其他领域拓展，翻别的河。
你去看跟 AI 没有关系的——电商的、工具类的、社交类的、甚至各种展览……你可能会从一个完全不相关的领域里，找到让你眼前一亮的设计。
两件东西本来不在一块儿，在各自的领域也不是什么新鲜事，但你跨领域地把它们连接到一起——在这个领域里，它就是创新的。
创新是遥远的连接
你其实并没有发明新东西，因为你用的那个东西在别的领域早就存在了。但你创造性地把它组合到了一起。距离越远，组合出来的东西就越让人觉得新鲜。
Duolingo 你肯定用过，或者至少听说过。它是全世界最大的语言学习 App。
但你知道它最重要的设计灵感来自哪里吗？
不是来自其他语言学习产品，而是手机游戏。
Duolingo 的设计师说过，当时他们团队有一半的人都在玩皇室战争，这对他们产品路线的设计带来了很大的影响，他们早期研究的不是竞品，而是愤怒的小鸟和皇室战争。
语言学习和手机游戏，八竿子打不着。
但 Duolingo 的团队看到了一件事：游戏让人每天都想打开的那套机制——连续登录奖励、经验值、排行榜、段位晋级——和语言学习需要用户"每天都回来练"的需求，本质上是同一个问题。
于是他们把游戏里的 streak（连胜记录）、leaderboard（排行榜）、league（联赛段位）全部搬了过来。
光是排行榜一个功能，就让用户在Duolingo 上花费的时间增加了近两成，整个游戏化策略叠加起来，四年时间让 Duolingo 的日活用户翻了四倍多。到现在很多学习类产品都在使用这个模式。
你看，Duolingo 并没有发明任何新东西。streak 在游戏里早就有了，排行榜也不是什么新概念。
但把它们从游戏搬到语言学习里，这个连接足够远，远到它的竞品想不到去那条河里翻石头。
所以翻石头这件事，翻的不只是量，还有翻的宽度。
你翻够了石头，手感自然就有了。
作业
去 Toolify 或者任意导航站上找 1 个你觉得Landing Page 做得好的产品页面，尝试回答这几个问题：
1.
它的首屏文案是什么？你看完 3 秒内能知道这个产品是干嘛的吗？也可以尝试写出你自己产品的首屏文案
2.
它跟同类产品的差异化体现在哪里？
3.
它的功能截图/配图做了哪些设计？
4.
有没有什么设计让你觉得眼前一亮？
四、用户登录：别自己造轮子，用现成的认证服务
前言
上一课我们讲了落地页。
用户被你打动了，点了那个按钮。
然后呢？
他需要一个账号。需要登录。需要一个地方让他知道自己是谁、用了什么、还能用多少。
这节课，我们讲用户登录。
一、你以为登录很简单
很多人第一次做产品，觉得登录没什么大不了。
不就是一个表单吗？用户名、密码，提交，查数据库，对上了就放进来。
然后他开始做了。
第一天，表单写完了。挺顺的。
第二天，发现密码不能明文存数据库，要加密。查了一下，bcrypt，好，加上。
第三天，发现要做"忘记密码"。要发邮件。邮件还不能进垃圾箱。又花了半天配邮件服务。
第四天，发现 session 管理没做。用户登录之后刷新页面就掉了。
第五天，有朋友提醒，这样会有 CSRF 漏洞。
第六天，用户问能不能用 Google 登录。OAuth 2.0，回调地址，access token，refresh token……
一周没了。
做出来的还是个问题一堆的半成品。
这不是你应该花时间的地方。
登录这件事，表面上是一个功能，背后是一整套安全体系。密码加密、session 管理、token 过期、第三方 OAuth、防暴力破解、防 CSRF……每一块单独看都不大，加在一起是个无底洞。
你的时间和精力，应该花在核心功能上。
登录，用现成的。
二、轮子已经有人造好了
市面上主要几个选择，我帮你梳理一下。
Clerk / Auth0
托管服务。接入快，文档好，体验不错。
但有两个问题：
•
贵。早期小项目可以用，等你用户量上来，账单会让你难受。
•
数据不在自己手里，这件事对 MicroSaaS 来说也是个隐患。
Supabase
这是我往期课程里推荐过的方案。
我有很多学生和朋友，都是用 Supabase 支撑了营收非常可观的项目。它不只是认证，还自带数据库、存储、实时功能，是一套完整的后端基础设施。
如果你已经在用 Supabase，完全可以继续用，没有必要换。有兴趣的朋友可以去了解。
BetterAuth
这一期我们以它为主。
原因很直接：开源、免费、数据存在你自己的数据库里。
和我们这期的技术栈——Next.js + Neon + Vercel——配合最顺。
没有额外账单，没有用户数据托管给第三方，一切都在你自己手里。
对于 MicroSaaS 来说，这很重要。你的用户数据，应该是你的。
三、BetterAuth 是什么
BetterAuth 是一个开源的认证库。
它的工作方式很简单：你告诉它用哪个数据库、支持哪些登录方式，它负责把一切跑通。
用户数据，比如账号信息、session 记录、OAuth token——全部存在你自己的 Neon PostgreSQL 里。
你完全掌控。
它支持邮箱密码登录、Google、GitHub、各种主流 OAuth provider，还支持魔法链接登录。
最重要的一点：它是为现代全栈框架设计的，和 Next.js 的配合非常顺滑，不需要绕弯子。
文档写得很清楚，遇到问题可以直接查。
四、一步步接进来
我们现在假设你已经有一个 Next.js 项目，连接了 Neon 数据库，部署在 Vercel 上。
如果还没有，先把这个基础搭好，再回来看这节课。
第一步：安装 BetterAuth
Bash
npm install better-auth
或
pnpm add better-auth同时需要安装数据库驱动：
Bash
npm install @neondatabase/serverless
或
pnpm add @neondatabase/serverless
第二步：配置 BetterAuth
在项目根目录创建 lib/auth.ts。你只需要在 TRAE 的对话框里告诉它，你要做什么，它会自动帮你在项目里创建好这个文件。
你可以这样跟 Trae 说：
在项目根目录下创建 lib/auth.ts 文件，内容如下：
TypeScript
import { betterAuth } from "better-auth";
import { Pool } from "@neondatabase/serverless";
export const auth = betterAuth({
database: new Pool({
connectionString: process.env.DATABASE_URL,
}),
socialProviders: {
google: {
clientId: process.env.GOOGLE_CLIENT_ID!,
clientSecret: process.env.GOOGLE_CLIENT_SECRET!,
},
},
});这里做了三件事：初始化 BetterAuth、连接你的 Neon 数据库、配置 Google 登录。
DATABASE_URL 就是你的 Neon 连接字符串。GOOGLE_CLIENT_ID 和 GOOGLE_CLIENT_SECRET 是下一步要申请的。
第三步：同步数据库表结构
BetterAuth 需要在你的数据库里创建几张表——用户表、session 表、account 表。
运行这个命令，它会自动帮你建好：
Bash
pnpm dlx auth@latest migrate
或
npx auth@latest migrate
在执行这一步的过程中，可能会出现两个警告，不用慌，我来解释一下
第一个警告
Base URL could not be determined
它的意思是：
“我知道你要做登录系统，但我不知道你这个网站到底的网址是什么。”
因为登录这件事不是只在你自己的页面里跳一跳，它会涉及：
•
登录后跳回哪里
•
Google 授权完回调到哪里
•
某些认证链接该生成什么网址
如果 BetterAuth 不知道你网站的地址，它就没法很确定地生成这些链接
所以在这里，需要先补上 BETTER_AUTH_URL
怎么解决？
如果你是本地开发，就在 .env.local 里加：
Plain Text
BETTER_AUTH_URL=http://localhost:3000（这里要确保开发服务器端口与 BETTER_AUTH_URL 配置匹配）如果以后上线到正式域名，再把线上环境变量配成：
Plain Text
BETTER_AUTH_URL=https://你的正式域名第二个警告
Social provider google is missing clientId or clientSecret
它的意思是：
“你代码里说你要用 Google 登录，但你没有把 Google 登录需要的凭证给我。”
这个问题，我们会在第五步详细解决
第四步：创建 API 路由
在 app/api/auth/[...all]/route.ts 创建文件：
TypeScript
import { auth } from "@/lib/auth";
import { toNextJsHandler } from "better-auth/next-js";
export const { GET, POST } = toNextJsHandler(auth);这一步把 BetterAuth 挂到 Next.js 的 API 路由上。所有认证请求都会走这里。
第五步：申请 Google OAuth 凭证
这一步很多人会卡住，我说清楚。
流程如下：
1.
打开 Google Cloud Console：https://console.cloud.google.com
2.
创建一个新项目（或者用已有项目）
3.
左侧菜单 → APIs & Services → OAuth consent screen
4.
在 Overview 点击 Get Started，填写应用名称、邮箱等信息，Audience 部分选择 External ，保存
5.
左侧菜单 → APIs & Services → Credentials
6.
点击 Create Credentials → OAuth client ID
7.
Application type 选择 Web application
8.
填写 Authorized redirect URIs：
本地开发填：
Plain Text
http://localhost:3000/api/auth/callback/google生产环境填：
Plain Text
https://你的域名/api/auth/callback/google
注意：这个回调地址必须和你代码里配置的完全一致，多一个斜杠都会报错。
9.
创建完成，拿到 Client ID 和 Client Secret
10.
把这两个值填进你的 .env.local：
Plain Text
GOOGLE_CLIENT_ID=你的client_id
GOOGLE_CLIENT_SECRET=你的client_secret对了，项目多了之后，你会发现每个项目都要有一套 Google OAuth 凭证。
怎么管理？
一般在同一个项目下创建管理就行，用不同的项目命名来区别——哪个凭证是哪个产品的，一眼就清楚。
第六步：前端加登录按钮
让 TRAE 创建 lib/auth-client.ts，内容填写如下：
TypeScript
import { createAuthClient } from "better-auth/react";
export const authClient = createAuthClient();在你的登录页面或者任何地方，加上 Google 登录按钮：
TypeScript
import { authClient } from "@/lib/auth-client";
export default function LoginButton() {
return (
<button
onClick={() => authClient.signIn.social({ provider: "google" })}
>
用 Google 登录
</button>
);
}测试一下，用户点击，跳转到 Google 授权页面，授权完成，回调回来，登录成功。整个流程就跑通了。
第七步：拿到当前用户
在任何需要知道"现在是谁在用"的地方——导航栏、用户中心、历史记录、设置页、核心功能等等，加下面的内容：
TypeScript
import { authClient } from "@/lib/auth-client";
const { data: session } = authClient.useSession();
// session.user 就是当前登录用户
// session 为 null 就是未登录就这么简单，你就知道当前用户是谁了。
比如在导航栏加上用户状态，登录了就显示用户信息，没登录就显示登录按钮。
补充：如果你还需要账号密码登录
BetterAuth 除了可以配置谷歌授权登录，还支持传统的账号密码登录
在src/lib/auth.ts里继续添加下面这个代码就行：
Plain Text
emailAndPassword: {
enabled: true,
}
这样，就同时支持账号密码登录了！
之后可以把本地的登录配置同步到 Vercel 上，如果 Vercel 上也能顺利登录，那就彻底跑通了
不过这里有个细节需要注意，部署到 Vercel 或者绑定了正式域名之后，记得在 Google Cloud Console 上同步添加新的回调 URL。
推荐直接在之前测试 localhost 的同一个 Web client 里添加，这样不用填写新的 Client ID 和 Client secret 了。
如果你的产品面向海外用户，建议将 Google 登录作为首选的登录方式。
为什么？
原因很直接：Google 登录绑定了真实的 Google 账号，有一定的注册门槛，可以有效阻止用户用临时邮箱反复薅免费额度。
而纯邮箱登录几乎没有门槛——临时邮箱服务随手可得，一旦你有免费试用或限额机制，就很容易被批量滥用。
有的人为了应对这种事情持续投入精力做风控和攻防，但换来的额外收入往往非常有限，性价比极低。
当然，如果你的目标用户中有不用 Google 账号的群体，额外提供邮箱登录作为补充就好。
对了，BetterAuth 还原生支持 Google One Tap 登录——就是用户打开你的网站时，页面右上角会自动弹出一个小卡片，显示当前浏览器已登录的 Google 账号，点一下就完成登录。全程不用跳转页面、不用输入密码。
体验非常顺滑。
五、三类用户，三种界面
登录接好了。
但登录不只是"让用户进来"这么简单。
登录，是你区分用户、引导用户的起点。
你的产品里，永远同时存在三类用户。对这三类用户，你要做三件完全不同的事。
第一类：匿名用户
没有登录。不知道你是谁。
对他，你只有一个目标：引导他登录。
让他看到产品的价值，让他感受到"这东西对我有用"。
但核心功能要挡住。给他一个足够强的理由去注册。
不要把所有东西都开放给匿名用户。开放太多，他没有理由登录。开放太少，他看不到价值，也不会登录。
这个度，需要你自己根据产品去找。
第二类：登录用户（免费）
他信任你了。愿意用自己的 Google 账号登录。
这是很重要的一步。
但他还没付钱。
对他，你的目标是：引导他付费。
让他用到免费额度的边界，让他感受到付费版和免费版的差距。在他最需要某个功能的时候，告诉他——这个功能在付费版里。
这是转化率最高的时机。不要浪费。
第三类：付费用户
他已经掏过钱了。
很多人做到这里就松懈了，觉得收到钱就结束了。
不是的。
对付费用户，你的目标是：引导他重复购买。
升级到更高套餐。单独购买额外积分。续费的时候给他一个理由继续。
记住：一个用户第一次付钱，是信任的开始，不是结束。
在代码里怎么区分这三类用户？
逻辑很简单：
TypeScript
const { data: session } = authClient.useSession();
const isPaid = session?.user?.isPaid; // 根据你的数据库字段判断，看是否付费
if (!session) {
// 匿名用户：展示产品价值，引导登录
return <ShowValueAndLoginPrompt />;
}
if (!isPaid) {
// 登录用户：展示免费功能，引导付费
return <FreeUserView />;
}
// 付费用户：完整体验，引导升级或复购
return <PaidUserView />;代码不难，难的是你想清楚了没有：每一类用户看到什么，不看到什么，在哪里被引导，引导去哪里。
付费墙的具体接法，我们支付那节课再展开。
回顾
•
登录看起来简单，背后是一套安全体系。别自己造，用现成的。
•
BetterAuth：开源免费，数据在自己手里，和 Next.js + Neon+ Vercel 配合顺滑。
•
Google 登录几乎是所有 MicroSaaS 的标配，回调地址一定要填对。
•
三类用户，三个目标：匿名用户引导登录，免费用户引导付费，付费用户引导复购。
•
登录是区分用户的起点，不只是"让人进来"。
下节课，我们讲支付。
下节课见！
五、海外订阅支付是怎么回事？
前言
这部分自学的难度比较大，请花足时间、多在社区里讨论交流。
对于新手来说，调试通过订阅支付，依赖于非常多的背景知识，是最大的一道门槛。
但由于它真的很难，零基础新手不太可能短时间内调通，请放平心态，报以耐心。
基础概念
在深入技术细节之前，让我们先了解一些基本概念：
支付网关：这是连接你的网站和银行/支付处理商的"桥梁"。就像一个虚拟的收银台，它安全地处理客户的支付信息，并确保资金能从客户账户转移到你的账户。
支付流程：一个典型的网上支付流程包括以下步骤：
1.
用户选择商品/服务并点击"购买"
2.
用户输入支付信息（信用卡、银行账户等）
3.
支付网关验证信息并处理交易
4.
支付网关通知你的网站交易结果
5.
你的网站响应结果（如显示成功页面或失败消息）
常见术语解释：
•
API：应用程序接口（Application Programming Interface）。简单来说，这是一种让不同软件系统相互"对话"的方式。在支付集成中，你将使用支付网关提供的 API 让你的网站能与支付网关通信。
•
Payment Intent（支付意向）：表示一次支付尝试，包含支付金额、货币和状态等信息。
•
Webhook（网络钩子）：一种自动通知机制，当特定事件发生时（如支付成功），支付网关会向你的服务器发送通知。
•
PCI DSS：支付卡行业数据安全标准，是处理信用卡信息时必须遵守的安全标准。
最适合中国人的 5 个支付网关
Stripe 为什么最火？
简单易用且功能强大。
对于个人开发者和初创公司来说，Stripe 提供了完善的文档和 SDK，集成过程非常顺畅。
在全球支持 46 个国家/地区，接受超过 135 种货币支付，并内置了高级的防欺诈系统 Radar，为商户和客户提供额外的安全保障 。
总的来说，Stripe 提供了开发者友好的体验和高度可定制的功能，适合大多数需要在线收款的项目。
Stripe 的核心功能包括但不限于：
•
支付处理：支持一次性付款、预授权、分期付款等多种场景。通过 Stripe，开发者可以接受信用卡、借记卡以及各种数字钱包支付，并且可以根据需要构建自定义的付款流程 。例如，你可以使用 Stripe API 创建支付意向（Payment Intent）来处理单次支付，或者直接使用 Checkout 等预构建组件快速接入支付。
Checkout 是托管模式，订单管理是自动的。 当你用 Checkout 创建一个 Session 时，Stripe 会自动帮你生成对应的订单记录，包括商品描述、金额、买家信息等，你在 Dashboard 里能直接看到每一笔"订单"的完整信息，几乎不需要你自己维护。坏处是支付页面是 Stripe 的域名，样式定制空间有限，用户体验上会有一次明显的"跳出再跳回"的感觉。
Payment Intent 是自建模式，本身不带订单概念。 它只是一笔钱的支付记录，没有"买了什么"的语义。如果你想做订单管理，需要自己在数据库里建一张订单表。好处是这个支付表单嵌在你自己的网页里，用户全程不离开你的网站，体验完全无缝。
•
订阅管理：Stripe 提供订阅计费功能（Stripe Billing），方便地管理按周期收费的服务。按月、按年自动扣款，升降级、试用期、优惠券，全都有，不需要你自己写定时扣款逻辑。
•
退款：处理退款在 Stripe 中也非常简单。无论是全额退款还是部分退款，Stripe 都允许商户方便地将款项退还给客户。你可以通过 Stripe 管理后台一键发起退款，也可以使用 Stripe 提供的 API 接口在代码中执行退款操作 。例如，通过调用 Stripe 的退款 API，可以对一笔 Charge 或 PaymentIntent 发起退款请求。Stripe 还会跟踪退款状态，确保资金按原路径退回到客户账户。
除上述功能外，Stripe 还提供账单开具、支付邮件通知、财务报表导出等一系列周边功能，几乎涵盖了在线收款所需的方方面面。这也是为什么 Stripe 被认为“开箱即用”却又足够灵活，能满足从简单博客打赏到大型电商平台的各种支付需求。
Paddle
Paddle 可以视作 Stripe 的替代方案之一，特别适合销售数字产品的个人和小团队。它采用 Merchant of Record （商家记录） 模式，意思是 Paddle 官方充当卖家替你处理支付事务和税务合规 。开发者使用 Paddle 时，只需在 Paddle 平台上创建产品和定价，接着将 Paddle 提供的结算页链接或嵌入式控件集成到自己的网站即可。
相比 Stripe 需要自行处理税率和开票等事务，Paddle 会自动帮你处理各国增值税、开票以及订阅管理等繁琐环节 。这一切使 Paddle 非常适合数字内容或 SaaS 订阅的销售。例如，你可以使用 Paddle 提供的 JavaScript SDK，在用户点击购买时弹出 Paddle 的结算弹窗，让用户完成支付和账单信息填写。由于 Paddle 把支付处理、订阅管理、税务合规和欺诈防护集成在同一平台，开发者无需额外配置太多工具即可开展全球销售 。
Paddle 的手续费相对固定且略高于 Stripe（官方费率约为成交额的 5%+0.5 美元起），但考虑到其代替商家承担税务和合规工作的便利，这对许多独立开发者而言还是可以接受的 。
Creem
Creem 是近年来兴起的支付集成平台，主要面向 SaaS 订阅业务，同时对接本地支付方式的需求。
对于希望快速开始订阅收费的开发者，Creem 提供了开箱即用的解决方案：只需在 Creem 后台配置好产品和订阅计划，然后将 Creem 的订阅组件嵌入你的 Next.JS 前端或者引导用户访问 Creem 托管的定价页面，即可开始收取订阅款项 。
Creem 的一大优势在于其本地化支持，尤其对中国开发者非常友好——无需注册海外公司或银行账户，只要用个人身份证和支付宝就能开通收款 。客户的付款将直接结算到你的支付宝等本地账户，解决了跨境收款难题。
税务处理、全球合规支持，Creem 也都有，和 Paddle 类似。
Dodo Payments
Dodo Payments 是近两年在独立开发者圈子里比较受关注的支付平台，主要面向 SaaS、AI 产品和各类数字商品。
它的模式叫 Merchant of Record（MoR） 模式，说白了就是 Dodo Payments 替你当法定卖家——全球支付、税务合规、拒付、风控，这些让个人开发者头疼的事情，它来扛。你只管把产品做好。这和 Paddle 的思路基本一致。对于卖订阅、一次性数字商品、积分或者按量计费的团队来说，这种模式的好处很实际：你不用自己搭一套支付+账务+税务的系统。
开发者工具方面，Dodo Payments 给得比较齐。后台建产品、设订阅计划、配 usage-based billing 规则，然后集成到你的网站或应用里就行。多语言结算页、本地货币显示、折扣码这些也都有。
对中国开发者来说，Dodo Payments 有一个实际优势值得注意：它的官方文档明确区分了 Individual 和 Registered Business 两种验证流程，而且可用国家列表里直接包含了 China。这意味着什么呢 ——它至少在官方层面，对中国个人开发者或小团队，比那些只认海外公司主体的平台友好得多。
Waffo
Waffo 是一家更新的全球支付与变现平台，创始团队有蚂蚁金服背景——这一点倒是让它天然对中国开发者的需求更有体感。它同样提供 MoR 服务。
Waffo 的卖点不只是收款，而是把税务合规、开票、订阅管理、续费优化、拒付处理和风控打包进了同一个平台。对于不想自己折腾 VAT / GST、对账、争议处理和本地支付接入的团队来说，这种"我全包了"的方案确实有吸引力。
但这里有一个关键门槛：Waffo 的服务对象需要是在香港运营的 business entity 或 non-profit organization。换句话说，它更适合已经有香港公司或者相关主体的团队，大陆个人开发者不能直接注册就用。
先审核 vs 后审核：五个平台的生死差别
接入海外支付，最怕的不是技术难度，是封号。
你辛辛苦苦跑通了支付流程，用户也开始付费了，结果某一天账号突然被封，钱还取不出来。这种事在出海圈子里，太常见了。
所以在选支付平台之前，你必须先搞清楚一件事：这个平台的审核机制。
Stripe：后审核，先爽后痛。
Stripe 是最多人用的，因为它接入门槛最低。你注册完、把 API 接好，马上就能收钱，全程没有人来审核你。听起来很爽对吧？
但它是后审核机制。意思是，等你有了收入之后，它会不定期来查你。查什么呢？查你的业务合不合规、内容有没有问题。一旦发现违规，直接封号，账户里的资金大部分拿不回来。
而且 Stripe 不支持中国个人身份、不支持中国公司身份。虽然你可以注册外国公司，以外国公司实体的身份去使用 Stripe。但这种方式本身就是违规的，非常不稳定。
风控严格，容易莫名其妙封号。不仅中国人会遇到，老外也会遇到。
Paddle：两头都审，对 AI 最严。
Paddle 的风控机制介于 Stripe 和 Creem 之间。它前面会做一轮审核，后面也有后审核机制，属于前后都管。
但 Paddle 有一点需要特别注意：它对 AI 产品的要求非常严格，比如 AI 换脸、AI 克隆声音、DeepFake、等可能被用于灰色地带的 AI 产品，这一条是写在官网里的。
如果你的产品涉及 AI 生成内容，Paddle 在后审核的时候会重点关注。
Creem：先审核，丑话说在前面。
Creem 走的是完全相反的路线——先审核。
你在接入之前，它就要审你。你的产品是做什么的，内容合不合规，商业模式是什么样的，它都要看。而且 Creem 的审核标准写得非常清楚：https://docs.creem.io/merchant-of-record/account-reviews/account-reviews
这种模式的好处是，一旦你通过了审核，后面被封号的概率就很小了。因为规则已经定好了，你在规则内做事，平台不会突然翻脸。
虽然前面多花了点时间过审核，但后面你的钱是安全的，当然也存在偶尔后期抽检的情况。
Dodo Payments：先审一轮，后面持续盯。
Dodo Payments 不是 Stripe 那种先接入再说，也不是完全放行后再抽查。它一开始就要你提交产品信息、收款账户资料，审核通过了才正式开放收款和提现。
但这不代表过了第一关就万事大吉。Dodo Payments 有一套持续监控机制——首笔交易、首次打款前、交易异常、退款拒付率升高、业务或域名变化，都可能触发复审。如果你做的是 AI 产品，还会重点看有没有 deepfake、impersonation、scraping、spam 这类风险。
简单说就是：门可以进，但里面有摄像头。你老实做事没问题，一旦风控指标异常，随时会被叫去"谈话"。
官方文档写得很清楚，建议直接看：
Waffo：主体先卡一道，后面保留很大的处置权。
Waffo 不是那种随便注册完就能长期放心跑的模式。它前面就有 KYC/KYB 流程，而且主体资格卡得更严，官方条款要求用户应是在香港运营的企业或非营利组织。
在品类上，Waffo 也会看得比较细，尤其是 AI / AIGC 相关业务，属于限制类目，会被重点关注。
它虽然没有像 Dodo 那样把审核流程写得特别细，但条款里明确保留了暂停、终止服务和限制账户的权利。至于具体怎么执行，它说了算。
Paddle、Creem、Stripe、Dodo Payments、Waffo
请记住这 5 个。
会有人告诉你：“还有很多更出名的啊，比如 Paypal、Adyen、Worldpay、Lemon Squeezy”，暂时不用理会他们。
我建议新手从 Creem 、 Dodo Payments 和 Paddle 开始，因为它们支持中国人用中文身份注册、审核不算特别严格。
等你有经验了，你可以注册一个海外公司，以海外公司的身份使用 Stripe。
支付接入的基本流程
以 Stripe 为例
无论你选择哪个支付网关，接入过程都遵循类似的步骤：
1.
安装和配置
◦
安装相关的 SDK（软件开发工具包）或库
◦
设置 API 密钥和其他配置信息
◦
配置 Webhook 以接收支付事件通知
2.
创建支付界面
◦
设计结账页面和支付表单
◦
集成支付网关提供的表单组件（如 Stripe Elements）
◦
确保界面响应式且用户友好
3.
实现支付逻辑
◦
创建后端 API 端点来处理支付请求
◦
与支付网关 API 通信以创建支付会话或意向
◦
处理支付结果和相应的业务逻辑（如更新订单状态、发送确认邮件等）
4.
处理回调和通知
◦
实现 Webhook 接收端点处理异步通知
◦
验证 Webhook 签名以确保安全
◦
根据支付状态更新更新你的系统
示意图如下：
如何快速接入支付？
在学习完「实战进阶」的前提下，接入支付并不难，我提供两个方法供你参考。
注：如果你还没学习完「实战进阶」，接下来你会看不懂、无从下手。如果出现这种情况，建议先回去学习 Next.js 基础。
下面这些资源，大多包含了从套餐展示、拉起收银台，到支付结果回传、订阅状态同步、用户自助管理的整条链路。
但真正上线前，还需要额外检查安全、异常处理、退款/争议、权限开通逻辑、正式环境配置等问题。
方法一：跟着教程走。
Creem
•
推荐！
•
•
非常凑巧，creem的官方demo，技术栈也是Next.js + TailwindCSS + shadcn/ui，已经学到了此时的你，应该一点也不陌生
Paddle
Stripe
Dodo Payments
•
官方 Next.js Adaptor：https://docs.dodopayments.com/developer-resources/nextjs-adaptor
•
官方 Next.js Minimal Boilerplate：https://docs.dodopayments.com/developer-resources/nextjs-boilerplate
•
官方 Next.js + Supabase Starter 教程：https://docs.dodopayments.com/developer-resources/supabase-boilerplate
Waffo
方法一：跟着教程走。
•
暂时没找到公开的教程或代码，需要完成基础验证后，才能拿到 API 文档。
方法二：直接套用官方的示例代码！
Stripe 、Creem、Paddle、Dodo Payments，都官方提供了基于 Next.js 框架的 demo
Creem
•
推荐！
•
Paddle
•
推荐！ 它的代码写得相当漂亮，功能也齐全
•
Stripe
•
不是特别推荐。代码已经没维护了。好在 Stripe 的接入很简单，看看教程，很快也能学会。
Dodo Payments
•
推荐！官方 Next.js + Supabase Demo：https://dodopayments-supabase-nextjs.vercel.app
•
另一个官方完整 Demo（也是 Next.js）：https://github.com/dodopayments/dodo-checkout-demo
•
对应在线 Demo：https://atlas.dodopayments.com
方法三：把教程文档发给 Cursor，让 Cursor 阅读教程后再做。
•
注意：这个方法并不能帮你绕过「你自己需要懂 Next.js」这个门槛。因为支付相对流程比较复杂，Cursor 不容易一次搞对，多多少少会出问题，需要你和 Cursor 一起协作解决。
配置 Creem
目前 Creem 需要邀请码才能注册登录，如果没有邀请码的话，可以先用 Dodo Payments 来测试学习。
creem 是比较适合新手的支付系统，在本环节中，你将在测试模式下，用测试卡进行充值，来测试你的网站
其中涉及到.env.local、 Webhook 路由、pricing.tsx等代码配置的内容，可以跟着操作，也可以先完成 Creem 配置后，到编写需求环节再统一完成
根据 Creem 官方文档和开源数据，至少需要配置下面这些信息
Plain Text
CREEM_API_KEY=你的Creem服务端API Key
CREEM_BASE_URL=https://test-api.creem.io（测试模式）/https://api.creem.io（正式环境）
CREEM_PRODUCT_ID=你的产品ID
CREEM_WEBHOOK_SECRET=你的Webhook Secret1.点击登录
2.打开测试模式
3.进入开发者模式
4.创建并复制 API
5.把 API 粘贴到.env.local 中，并填写API端点地址
测试环境
CREEM_API_BASE_URL=https://test-api.creem.io
正式生产环境
CREEM_API_BASE_URL=https://api.creem.io
6.在项目里增加 Webhook 路由
通常路径是src/app/api/webhooks/creem/route.ts
7.创建正式环境 Webhook
在 Creem 上点击 Webhook，再点击创建
Webhook URL 填写 https://你的域名/api/webhooks/creem
8.点击开发环境 Webhook
9.复制密钥
10.粘贴到.env.local 中，记住，填写后一定要保存
11.在 creem 中创建产品
12.填写信息
13.点击创建
14.复制产品 id
15.粘贴到.env.local和代码中（可以让 Cursor 直接配）
16.让 AI 读取官方文档，补充 checkout 路由等相关代码配置
提示词大致如下：
Plain Text
我已经完成了creem接入的所有环境配置，这是creem的开发文档，请仔细阅读。如果这些文档还不够，请你自己上网搜索更详细的文档。请帮我补充完整的接入代码
https://docs.creem.io/checkout-flow
https://docs.creem.io/learn/checkout-session/return-url
https://docs.creem.io/learn/webhooks/introduction
开发的时候我们使用测试模式，文档是https://docs.creem.io/test-mode 一般会完成下面这些任务：
•
新增或完善 Dodo checkout 创建路由
•
新增或完善 Dodo webhook 路由
•
接支付成功回跳页
•
根据 webhook 结果更新数据库里的订单/会员状态
•
保留测试模式配置，不误切到 live_mode
•
本地跑类型检查 / 构建检查
更新后，终止开发环境运行（快捷键 control+c），再次运行 npm run dev
祝贺你！现在你的网站，用户可以支付啦
点击支付
测试卡号：4242 4242 4242 4242
支付完成
权益变化
特别提醒：我们先用测试模式！
详细配置一定要看上文测试环境支付配置。
配置 Dodo Payments
根据Dodo Payments 官方文档和demo，至少需要配置下面这些信息
Plain Text
DODO_PAYMENTS_API_KEY=你的Dodo服务端API Key
DODO_PAYMENTS_ENVIRONMENT=test_mode（测试模式）/live_mode（正式接入）
DODO_PAYMENTS_RETURN_URL=http://你的域名/pricing/success
DODO_PAYMENTS_PRODUCT_ID=你的产品ID
DODO_PAYMENTS_WEBHOOK_KEY=你的Webhook Signing Key登录或注册 Dodo Payments - https://app.dodopayments.com
1.点击登录
2.打开测试模式
3.进入开发者拿 测试 API key
4.创建并复制 API
5.把 API 粘贴到.env.local 中
6.在项目里增加 Webhook 路由
通常路径是src/app/api/webhooks/dodo-payments/route.ts
8.复制密钥
9.粘贴到.env.local 中，保存
10.在 Dodo Payments 中创建产品
11.填写信息并创建
12.复制产品 ID
13.粘贴到代码中（也可以让 Cursor 配），记住保存
14.在.env.local里填写测试模式和RETURN URL
15.让AI根据官方文档补充其余代码
提示词大致如下：
Plain Text
我已经完成了dodo payments接入的所有环境配置，这是dodo payments的开发文档，请仔细阅读。如果这些文档还不够，请你自己上网搜索更详细的文档。请帮我补充完整的接入代码
https://docs.dodopayments.com/developer-resources/nextjs-adaptor
https://docs.dodopayments.com/developer-resources/nextjs-boilerplate
https://docs.dodopayments.com/developer-resources/supabase-boilerplate
https://github.com/dodopayments/dodo-checkout-demo
注意，我目前是测试模式更新后，终止开发环境运行（快捷键 control+c），再次运行 npm run dev 测试支付是否接入成功
点击支付
测试卡号：4242 4242 4242 4242
支付完成
注意：同样先用测试模式！
编写需求
把黄色部分改成你自己的。
需求文档，编写得越详细越好
这个 Prompt 的目的是读你现有项目代码，然后基本可以搭出支付接入的主要流程。
请帮我完成creem支付功能。
#背景信息
•
系统中已经集成supabase，你可以连接进去，查看，理解，构思需要补充的数据表；
•
关于supabase我们的所有配置，已经存在在.env.local里。
•
creem的开发文档，请仔细阅读。如果这些文档还不够，请你自己上网搜索更详细的文档。
•
•
请在开发期间，使用creem的测试环境！creem测试环境的API地址是https://test-api.creem.io
•
我已经在creem后台创建好了程序需要的一切变量，并且配置好了webhook地址为https://v0-simulator-design.vercel.app/api/webhooks/creem。请直接帮我完成环境变量配置，我懒，谢谢
◦
creem api key: creem_test_1TIRRm2v9XpPsM2wvOKqvz
◦
webhook secret: whsec_46kfNzVYGyAXpqZ2lCd119
◦
product id: prod_5Q2F41MD69333CxYnEjN54
#需求
1. 我们支持包月subscription。
2.请你同时在首页加上Pricing Table和购买按钮。
### 1. 产品定价策略
- **包月订阅**：价格是$10/月，包含的权益是无限次提问
我将会在creem后台创建一个用于订阅支付(subscription)的产品，美元10美元。我会提供Product ID给你。
### 2. 游戏机制
- 未登录用户：每次游戏可以最多对话3轮，则需要提示登录
- 免费用户：每次游戏可以最多对话7轮，则需要提示付费
- 付费用户：无限制
### 3. Creem配置
- 我已经在creem创建了账号、设置好了产品、设置好了webhook
- 我已经告诉你了我api key、product id、webhook secret，你可以帮我设置
### 4. 数据库结构
-请帮我设计。你可以根据.env.local里的环境变量，直接连接supabase。
- 如果可能的话，你可以帮我建好需要的表。
### 5. UI设计偏好
- 价格表放在首页底部
-对于免费用户，你需要设计明显的付费引导
如果有不明白的，你先问我，我们沟通好以后，再进行编码
我比较懒，在手动完成creem后台的所有设置后，我还可以让AI帮我配置好环境变量。（见上面的prompt）
担心保密性问题？不用太担心，因为这是测试环境。测试key即便泄露，也没关系。
用 claude code 完成代码
我们使用 Cursor + Claude Code 结合方式，帮我们快速搞定支付接入。
提示：由于支付任务较难，如果你只使用 Cursor 的话，需要你有一定的编程能力，至少能理解代码；新手如果使用claude code/codex，可以更快搞定。
关于claude code是什么，请参考课程：Claude Code：TRAE/Cursor 已经够好了，为什么还要用这个黑窗口？
把 V0 更改的代码，推送到 Github 上
从 V0 的环境，复制出来所有的环境变量，放到本地.env.local里
用 Cursor 打开项目，同步 V0 的更改。
这个时候，我们需要使用 claude code 来帮我们接入creem支付！ 任务比较困难，单靠cursor无法搞定。
只要需求文档写得足够清晰和详细，claude code可以一次性搞定支付。
在localhost进行简单测试，使用测试卡号可以付款
![link](data:image/svg+xml,<svg xmlns="http://www.w3.org/2000/svg" width="200" height="200"><rect fill-opacity="0"/></svg>)
20250605143652_rec_.mp4【在线播放】
Webhook
什么是Webhook？
方法一：映射本地端口到外网(推荐）
除非，你在本地使用ngrok或者cloudflare tunnel等工具，把本机端口映射为公网地址，否则，你无法测试Webhook。
看不懂上一句是什么意思？
可以问问claude code，它可以帮我们搞定ngrok
如果你想亲自搞明白其中的原理，不妨花一些时间，不断询问claude code，让它指导你测试、协助你学习。（推荐）
这都还嫌麻烦，也没关系，还有简单方法。接着往下读。
方法二：使用vercel给我们的固定公网地址
调试 Webhook，需要一个公网 URL 地址。如果你觉得本地映射到公网的方式比较麻烦，也可以直接使用 Vercel 给我们的固定公网地址。
先回到 Vercel，进入你的项目，确保你已经配置了全部环境变量。
小技巧：可以把本地的.env文件复制粘贴过去，自动配置；然后再根据需要做修改
我们可以把代码推送到 Github，并且部署到 Vercel，使用 Vercel 给我们的公网URL，就可以很方便的测试 Webhook了。
推送给 Vercel，等待部署。
再次检查，Creem 里设置的 Webhook 地址，是否正确
在网站上点击支付，然后分别关注 Vercel 里的日志和 Creem Webhook 里的日志。
分别如下图
请尽可能理解日志的意思。
如果不明白，可以把日志复制给claude code，让它解释给你听。
在我当前的示例中，是因为我的.env里配置的地址错了。它在本地的时候是localhost，但是配置到vercel的公网地址，应该修改，而我没有修改。。
还有一些其他错误，没关系，全部复制，放到claude code里，描述清楚你的场景。
很快，claude code就修好了。还告诉我详细的修改方法。
然后我们等待vercel自动部署、继续测试。
支付成功后，也到creem webhook查看日志。看看是否有错误
如果再遇到错误，就重复上面的操作进行排查和修改，周而复始。
请不要因为遇到错误而沮丧。我们作为初学者，应该有良好的学习心态，把每次报错，都当成一次学习的机会。
交互优化
当测试完支付后，我们围绕“支付”来升级交互界面、引导付费。
你可以尝试
1.
添加明显的付费引导
2.
给付费会员尊贵的标识
3.
设计产品：免费会员有哪些权限、付费会员有哪些权限、什么时候弹出付费引导
4.
……
Have fun!
六、极速开发指南：从零开始到正式上线，只需要1天
极速开发的要义
特别强调：
•
你没法只看这一篇就学会极速开发。请耐心先把前面的基础打牢，这一篇是前面所有内容的串讲实操。
•
但是，一旦你熟练掌握这篇内容——以后绝大部分AI MicroSaaS，你都可以一天内上线！
相信你已经发现，SaaS 项目的启动阶段，有大量重复又复杂的基础架构要搭。比如用户身份认证、订阅支付、数据库管理、权限控制、后台管理……
这些东西，跟你产品的核心差异化没有半毛钱关系，但却需要花费大量的时间精力进行开发，拖慢整个开发的进度。
怎么办呢？
大胆使用 Starter Kit
什么是 Starter Kit？
Starter Kit 是预配置好的应用开发模板或工具包——SaaS 产品开发中那些通用的基础设施和功能组件，别人已经帮你搭好了。
虽然市场上有各种各样的 Starter Kit，但考虑到我们的学员当前正在学习和使用 Next.JS，所以我重点推荐了基于 Next.JS 的套件。
这里有一个搞错的点：
Starter Kit 不是让你把登录、支付这些功能拆下来，装到别的项目里。
它是一个已经搭好的 SaaS 底座，从一开始就在 Starter 里做，把你的核心功能直接接到现成的通用能力上
先想清楚自己要做什么功能，然后可以直接在 Starter 里新增业务页面、业务表和业务 API，把核心功能接到现有的用户系统、支付系统和权限系统等这些通用能力上。
这样做的好处是，不用重复造轮子，把精力集中在真正有差异化价值的部分。
为什么要用 Starter Kit？
学到这里，你应该已经发现了——大部分 SaaS/MicroSaaS 的"基建工作"都差不多。
就好比，你要修一座桥，如果你能拿到同一条河上以前修过的桥的图纸，是不是会快很多？
常见的 SaaS Starter Kit，已经内置了如下功能：
•
漂亮的 Landing Page
•
用户体系，包括用户注册、登录、社交账号登录等。
•
支付体系，包括订阅支付、细节体系等等。
•
邮件体系
•
管理员用的用户管理系统
更强大的 Starter Kit，可能还有下面这些功能：
•
多语言
•
简易博客系统
•
端到端测试
•
多租户
•
分销体系
•
NewsLetter
•
Waiting list
•
手机 App 骨架代码
几款强大的 Starter Kit 推荐
下面前三款 Starter Kit，是我用得最多的 ，在这里推荐给大家。
注意：他们都是收费的！价格多在$299 美元（2000 人民币）左右。
对于新手，我的推荐排序： ShipAny ≈ MkSaaS ＞ MakerKit ＞ Supastarter ＞ Shipfast
不要急着买！！先看完本课！
ShipAny
ShipAny 的开发者是 idoubi，他也是咱们生财有术的圈友。
ShipAny 的优势
1.
界面美观，审美在线。
2.
对于简单应用来说，开发特别快
3.
同时支持多种支付网关，包括creem、stripe、paypal等等
4.
功能齐全，你能想到的AI SaaS功能，基本上都有了。包括但不限于：博客系统、分销系统集成、在线客服。
ShipAny的劣势
1.
功能虽然多，但代码健壮性一般。比如，框架里没有使用Redis之类的性能优化手段，每次用户session和积分都要读取数据库，效率相对差一些。不过，早期项目一般不会遇到这个问题。
2.
为了“快速”和“方便”，牺牲了一些“规范性”。比如核心环境变量配置没有使用env，而是存到了数据库里。 好处是配置起来特别快——但安全系数肯定会变小。数据库里的数据，理论上所有有权限的人都能看到。如果你要招员工、搞团队合作，这个做法就有风险了。但对于个人开发者和早期项目来说，完全可以接受。
一般来说，MVP 阶段的应用，我会优先选 ShipAny，它真的能省掉大量开发 MVP 的时间成本。等项目流量变大了，再去考虑补齐代码健壮性、性能优化的内容。
我的Raphael ( https://raphael.app ) 就是用 ShipAny 做的。
MkSaaS
官网地址是：https://mksaas.com/
这是一个后起之秀，刚刚发布不久，也是中国的开发者做的。
填入 coupon 优惠码 XIAOPAI，可以获的 $40 优惠。这是我给咱们课程专属的 coupon，请勿外传！仅限学员使用。
MkSaaS 的优势
1.
代码架构优秀，而且简单
2.
功能相对完整。
3.
长在了我的代码审美上！同时使用了 Next-Intel、Resend、Drizzle、Shadcn、MagicUI、Better-auth、Zustand 的 starter，全世界就这一个！我以前用其他的 starter，总得先手动修改、引入这些技术栈的。Mksaas 是唯一一个让我啥也不用改，直接用起来就很舒服的。
4.
性价比最高。
MkSaaS 的劣势
1.
不支持 Stripe 以外的其他支付平台。不过也还好，比较好改。
2.
比较新。
除了这些优点，真正让我推荐 MkSaaS 的原因，是这个作者比谁都勤奋，更新得比谁都快，什么新的技术出来他都会跟上。
不过有一说一，如果你是自己做项目，对于新手来说，它的配置流程会更繁琐一些。
如果你有比较多的学习时间，想深入理解每一层是怎么实现的，MkSaaS 是个好的选择。如果你只想最快速度出 MVP 验证想法，ShipAny 可能更合适。
MakerKit
MakerKit 是一套功能强大的 SaaS 启动模板，包含用户认证、支付订阅、后台仪表盘、邮件发送等常见功能。它突出的特点是易于扩展和文档支持好，非常适合想要迅速构建稳定产品基础的初创团队。
它是功能最全的 Starter Kit 。
还有两个特点值得一提：
•
它的数据库和后端用的是 Supabase，对新手非常友好。
•
赠送一套 App 的 starter，如果你同时想要做 app，它可以进一步帮你省时间。
SupaStarter
它是代码最健壮的 Starter Kit。如果你的项目未来会做得很大，这是可以考虑迁移过来的架构。
SupaStarter 我从三年前就开始使用了，最初版本也用 Supabase 做后端，后来新版本给去掉了。
但这个框架有一个可能会让人难受的地方：
•
它的代码架构很牛。这是一个双刃剑——对于大公司、复杂项目来说，是好事，但对新手并不友好。
Shipfast
Shipfast 强调极速开发和部署，涵盖了营销页面、用户订阅管理、身份验证、Stripe 支付集成等功能。适合想要极快验证市场需求，推出 MVP 的开发团队。
它是最适合初学者的 Starter Kit，一边使用，一边学习
一个可能比较难受的地方：
•
数据库设计偏薄弱。尤其是它的主版本数据库使用的是 MongoDB，在 SaaS 领域相对比较小众。
SassyKit
这是我最喜欢的 starter 之一，功能完整、代码健壮。不过它用的是 Laravel 框架（PHP语言），不是 Next.js，所以在本课程里不重点推荐。
大型演示：本课程配套的Sistine Starter（西斯廷）
为了配合本次课程，我决定做一套适合咱们学员的专属 Starter Kit。你可以用这套 starter 快速上手，上架产品。
有了前面的学习，加上一个好的Starter，你可以一天内上线一款可以收款的成熟产品！
从此，你只需要专注于两件事：核心功能和搞流量。
➡️代码仓库自动申请
➡️脚手架在线体验 （AI功能限制）
➡️环境变量配置文档
➡️脚手架使用文档（本地启动后也可获取）
登录：可使用 Google 账号登录
支付：可使用测试账号支付，测试订阅支付和积分购买功能
信用卡号：4242 4242 4242 4242， 其他信息随便填。
特色
【可登录、支付（creem）、管理后台、积分系统、定时任务、数据分析、多语种、邮件等】
【AI对话/AI生图/AI视频 3 种 demo 功能】
【年费积分按月定时发放/管理后台可手动控制用户状态/完整的法律框架/一定的性能提升】
技术框架选择
•
| 前端框架 | Next.js | 16.2.2 | 服务端渲染、文件路由、API Routes 一体化 |
•
| UI 组件库 | Shadcn/UI | Latest | 基于 Radix UI，可定制、无依赖锁定 |
•
| 样式方案 | Tailwind CSS | 3.4+ | 原子化 CSS，开发效率高，包体积小 |
•
| 数据库 | PostgreSQL | - | 生产级关系型数据库，ACID 保证 |
•
| ORM | Drizzle ORM | 0.44+ | 类型安全、轻量级、性能优秀 |
•
| 身份认证 | Better Auth | 1.5+ | 现代化认证方案，支持多种登录方式 |
•
| 支付网关 | Creem.io | - | ⭐ 支持中国大陆个人身份注册 |
•
| 类型系统 | TypeScript | 5.x | 类型安全，减少运行时错误 |
•
| 动画库 | Framer Motion | 11.2+ | 声明式动画，性能优秀 |
•
| 表单处理 | React Hook Form + Zod | Latest | 性能优化的表单方案 + 运行时验证 |
这是一个基于 Next.JS、Supabase 和 Creem.io 构建的现代化、生产就绪的启动套件。非常适合快速构建要有身份验证、订阅和积分系统的 SaaS 应用程序，可以让你的 MVP 开发速度提升 10 倍。
获取代码
这里我们用方法1。
通过方法1，可以把代码克隆到你自己的 Github 账户中，后续的操作跟前面课程一样。
创建完成后，可以在自己的账户里看到代码了
后续的操作，你已经会了
使用 Github Desktop 打开
再用 VS Code 或者 Cursor 打开
运行代码
在终端执行pnpm i 安装代码需要的依赖
然后执行 pnpm dev 运行代码
运行成功后，可以看到 http://localhost:3000 地址
点击 http://localhost:3000 地址
（使用cmd + 点击，可以直接打开）
就看到界面了
理解项目
这里我们推荐用 Claude Code/Codex 等Terminal类的工具，更加智能。
如果是Claude Code
如果你用的是 Claude Code，可以用 /init 命令
（项目里已经有CLAUDE.MD了，这一步其实可以跳过）
Claude Code 会生成一份详细的项目说明。生成文件叫做 CLAUDE.md ，无论是AI还是人类，都很方便阅读。
如果是Codex
如果你用的是Codex，使用 /init 命令，可以达到同样的效果。生成文件叫做 AGENTS.md
如果是Cursor
Cursor还没有类似的功能。
不过，你可以直接通过询问的方式来了解项目。
选择使用Claude-Sonnet-4.6模型，在询问的时候打开Plan 模式
如果是TRAE
你也可以直接通过询问的方式来了解项目。
他还可以给出使用建议
作业
1.
申请 Sistine Starter 的代码权限
2.
将代码克隆到本地，使用 Cursor/VS Code 打开。
3.
通过 AI，理解代码架构、理解代码核心功能模块、尝试找出快速上手的使用方法
先不要急着写代码，下节课，我们马上讲到！！
实操演练—快速开发和上线正式产品
下面我们用 Codex 来完成，对于这种难度的任务，它可以一次性完成。
如果你还没掌握 Terminal 类的AI编程工具，也可以继续用 Cursor，慢慢来，同样可以完成。
准备阶段
构思MVP需求
我打算做一个 AI 换衣服的产品。
流量获取思路： 社交媒体引流
付费思路：免费版有水印，并且最多只能穿一件衣服；付费版没有水印，可以让一个模特同时穿1～3件衣服。
次数限制
水印
单次试穿衣服数量限制
匿名用户
啥都不让用，必须登录
-
啥都不让用
已登的免费用户
3次/天
有
1
付费用户
200次/月
无
3
构思技术方案
火山引擎的 Seedream 系列模型可以搞定。还记得吗，在前面的课程里，我们已经用 Postman 调试通过了换衣服。
也就是说：我们只需要依赖 Seedream-4.0 / 4.5 / 5.0-lite 这几款 API，就能实现核心功能。推荐用最新的，比如，有条件用5.0，就没必要用4.0
找到 Seedream 的API文档，在这里 https://www.volcengine.com/docs/82379/1541523
阅读 API 文档，发现这几个模型允许用户通过 base64 的方式传输图片。那会让我们更加方便。
（不懂什么意思？记得问问 Tabbit 浏览器）
这里我先帮你问问
进一步查看，我们实际需要的能力是「多图输入单图输出」示例代码在这里
设计核心交互
简单画了一下，我希望在网站的 Hero 区域可以直接出现操作界面
构思实现步骤
我希望分两步走：
第一步：先完成核心功能（不需要任何的数据库、用户认证），方便我打磨交互。
功能可用后，再去做第二步：数据库、用户认证、支付、不同用户的权限限制。
快速实现核心功能
写完整的需求文档
你发现了吗，经过上面的讨论，需求文档其实已经写完了！
用单独的飞书文档来管理！
这一步不能马虎！要事无巨细、没有歧义。不妨把文档发给同组的同学讨论，看看是否有歧义。
这是我的，你可以参考
和 AI 讨论待确认项
把刚才的需求文档复制给 Codex 。
注意：图片需要单独贴。
Codex 给出了完整的计划，见下面的视频。
录屏2026-04-02 17.37.09.mov【在线播放】因为我的需求写得很完整，它只有少数问题需要和我确认。简单回复即可。
正式开始
魔法开始了
一共花了10分钟
Codex 还顺便告诉了我接下来要做的事——补充 API Key，按照它说的步骤来配置就行。
也可以把 Key 直接给它 （仅限于开发期间的 Key），让 Codex 帮你配置
访问界面，功能已经完全实现了！
看看效果
确认效果没问题后，提交代码到“网盘”(Github)
从核心功能到完整产品
有了核心功能，我们只需要利用 Starter 上的基础设施，就可以变成完整产品了。
这些基础设施包括： 数据库、登录(用户系统)、支付功能、 辅助页面。
我们先配置这些基础设施。
配置
注意：这里只演示了最小需要配置的东西。我们的 Starter 还有很多别的功能，包括邮件系统、博客系统、存储系统等等，你可以自行探索。
如果你是第一次接触这些东西，可能会花比较久的时间（1小时），请加油，不要被吓到～ 第一次慢，以后就快了。
完成数据库配置
需要复制 .env.example 并创建 .env.local
在 .env.local 中编辑 DATABASE_URL 变量
Plain Text
====================================
Database Configuration
====================================
PostgreSQL connection string
Format: postgresql://username:password@host:port/database?sslmode=require
DATABASE_URL="postgresql://username:password@host/database?sslmode=require"也可以直接让 Codex 完成这一步
之后获取数据库的连接字符串：
创建 postgresql 数据库，推荐：https://console.neon.tech/
1.创建项目
2.填写数据库名称
3.获取链接方式
•
生成数据库迁移文件：pnpm db:generate
•
执行数据库迁移：pnpm db:migrate
执行后，在 Tables 中查看，是不是已经建立了这些数据表。如果有，说明已经成功了。
配置用户 Google 账户登录
获取认证密钥（登录前，需要先配置数据库，因为用户信息都会存到数据库表里）
变量填写：
Plain Text
====================================
Authentication (Better Auth)
====================================
Secret key for Better Auth (must be at least 32 characters in production)
Generate with: openssl rand -base64 32
BETTER_AUTH_SECRET="your-super-secret-key-at-least-32-characters-long-for-production"获取方式：终端运行下面的指令，将得到的 32 位字符串填写进去，可以手动替换到上面标黄的位置，也可以让 AI 在生成后直接帮你替换
Plain Text
openssl rand -base64 32回调 URL 填写：
变量填写：
Plain Text
The URL where your app is hosted
BETTER_AUTH_URL="http://localhost:3000"•
填写方式：
◦
◦
正式环境：填写正式的环境域名
Google OAuth 变量填写：
Plain Text
====================================
Google OAuth (Optional)
====================================
Get these from: https://console.cloud.google.com/
Guide: https://authjs.dev/getting-started/providers/google
AUTH_GOOGLE_ID="your-google-client-id"
AUTH_GOOGLE_SECRET="your-google-client-secret"获取方法：
1.打开 Google Cloud Console，新建项目
2.在 Overview 点击 Get Started，填写应用名称、邮箱等信息，Audience 部分选择 External ，保存
3.左侧菜单 → APIs & Services → Credentials
点击 Create Credentials → OAuth client ID
Application type 选择 Web application
4.填写 Authorized redirect URIs
本地开发填：
Plain Text
http://localhost:3000/api/auth/callback/google生产环境填：
Plain Text
https://你的域名/api/auth/callback/google注意：这个回调地址必须和你代码里配置的完全一致，多一个斜杠都会报错。
5.创建完成，拿到 Client ID 和 Client Secret
把这两个值填进你的 .env.local：
Google 登录控制
Plain Text
Public Google OAuth settings
NEXT_PUBLIC_AUTH_GOOGLE_ENABLED="false"
NEXT_PUBLIC_AUTH_GOOGLE_ONE_TAP_ENABLED="false"•
变量说明
◦
前者控制整个 Google 登录功能的启用 / 禁用
◦
后者控制更快捷的 “Google One Tap” 登录提示是否显示
测试登录是否配置成功
同时，在Neon数据库后台，也应该能看到刚才登录用户的数据记录
配置支付收款 （有点难，可选）
前面课程说过，搞支付有点难。
你可以先完成其他环节，最后再做支付，要有足够的耐心。
环境变量
Java
====================================
Payments (Creem)
====================================
Get your API key and configure webhook endpoint in Creem dashboard
CREEM_API_KEY="your-creem-api-key"
CREEM_WEBHOOK_SECRET="whsec_..."
Optional overrides (use if your Creem test environment uses a different domain/path)
CREEM_API_BASE="https://test-api.creem.io"测试模式时填这个地址CREEM_API_BASE="https://api.creem.io"（正式生产环境地址）
CREEM_CHECKOUT_PATH="/v1/checkout/sessions"
Set to true to simulate checkout redirect (no external call). In this mode, checkout will redirect to /dashboard?success=1
CREEM_SIMULATE="false"
Webhook endpoint to configure in Creem dashboard (for reference):
https://your-domain.com/api/payments/creem/webhook获取方式
1.点击登录
2.打开测试模式
3.进入开发者模式
4.创建并复制 API Key
5.粘贴到.env.local 中
6.在项目里增加 Webhook 路由，通常路径是src/app/api/webhooks/creem/route.ts
7.创建正式环境 Webhook
在 Creem 上点击 Webhook，再点击创建
Webhook URL 填写 https://你的域名/api/webhooks/creem
8.点击开发环境 Webhook
9.复制密钥
10.粘贴到.env.local 中，记住，填写后一定要保存
11.在 creem 中创建产品
12.填写信息
13.点击创建
14.复制产品 ID
15.粘贴到代码中（也可以让 Cursor、Codex 配），记住保存
构造下一步需求
还记得我们最初的需求吗？
继续构造。这次要强调的是：整体文案、不同种类用户的权限。
再次拿出飞书文档，开始写。
主题色工具：https://tweakcn.com/
良好的学习习惯
1.
杜绝无脑复制，请你自己编写。
2.
作为学习的一部分，强烈建议你：看懂AI写的每一行代码；如果看不懂，逐一问AI。
3.
在这次的示例中，我一次让AI做了三个大类任务。新手可以拆分的更细，一次只让AI做一个任务。
实现
把需求文档发给 Codex，它开始工作了
你可以仔细看看 AI 的思考过程。这是学习的一部分。
Codex 提出了一些问题，根据需求回答即可。
开始写代码了
过程中，请你去看懂AI写的每一行代码。这是学习的重要组成部分。
如果看不懂，就问AI，直到全部看懂。
慢就是快。
这次，Codex 一共写了四十几分钟。
如果验收发现问题，可以继续和 Codex 对话，做微调。
可以看到
•
免费的已登录用户，有付费引导，有当天使用次数的计数
•
整体风格改成了给定的浅绿色主题
•
所有的文案改为围绕 AI 试衣服来编写
•
所有的文案做了多语言本地化，同时有英文版本和中文版本
打磨细节
后续的工作，就是一边测试，一边打磨细节了～
细节才是最花时间的。
以我的Raphael (https://raphael.app )为例，功能跑通只用了一天，打磨细节用了一周。
可能包括：
1.
Landing Page 控件和样式的修改。
2.
多种登录方式。例如：邮箱注册登录。
3.
不同等级的付费用户有不同的权限。就像ChatGPT一样，有$20/月的，也有$200/月的。
4.
增加积分购买功能，不止是包月。
5.
Logo 和 icon
6.
文案精细化打磨
7.
SEO
8.
页面性能
9.
博客文章
10.
品牌故事
11.
……
请和同学、助教们一起交流！
实操演练2-使用其他的Starter
刚才我们演示的是课程配套的starter，这个starter比较简单，它是一个教学用具，所以我们讲的比较详细。
在实际的开发过程当中，我鼓励大家使用商业的starter，因为它们代码更完善，功能更多下面我也演示两个用商业starter完成跟上面同样的任务。
ShipAny演示
安装完项目依赖后，让 Codex 直接运行该项目
用/init命令理解项目
写完需求文档，把第一步发送给 Codex
回复待确认项，开始改写代码
第一阶段完成
补充 API Key 后测试功能，运行成功
配置数据库、登录、支付等功能
构造下一步需求
等待 Codex 实现第二次需求修改
初版效果出来了，之后继续优化页面，打磨细节就行
MkSaaS演示
安装项目依赖并运行
用/init命令理解项目
和 Codex 讨论产品功能的技术方案，写完需求文档，把第一步发给 Codex
回复待确认项，开始改写代码
第一阶段完成
补充 API Key 后测试功能，运行成功
配置数据库、登录、支付等功能
构造下一步需求
等待 Codex 实现第二次需求修改
初版效果出来了，之后继续打磨细节就行
附： 第2个演示，来自助教 @彩笺
学习进度确认
你可以点击下方按钮，一键将整门课程标记为学完。
下一篇
