Pro Vibe Coding 进阶指南

从原型到真正的产品。构建让用户愿意付费、每天使用、并且信任你来保管数据的应用。

这份指南写给那些已经学完 Pre-Vibe Coding、准备好做真实产品的人。

这份指南会告诉你怎么做——依然用 AI 来帮你写代码，依然用简单的语言解释，依然不需要计算机科班背景。

第 1 章：从玩具应用到真实产品

你做过一个待办事项 App，或者一个落地页，或者一个能展示些数据的小仪表盘。恭喜你——说真的。大多数人连这一步都没走到。

但你也注意到了一件事：你的应用感觉像个玩具。没有人能登录，没有付费方式，数据就算丢了也没人在乎，因为根本没有真正的用户。

这很正常。你之前开的是一个路边摊。

路边摊与餐厅的比喻。

你的待办事项 App，就是那辆路边摊小推车。你停在街边，做了些小吃，路过的人尝了尝说"还不错嘛"。食材是真实的，烹饪是真实的。但没有正经的大门，没有收银台，没有卫生许可证，也没有人管着服务质量。

现在你要开一家餐厅了。烹饪本身没变——AI 还是在帮你写代码。但一家真正的餐厅需要：

• 装着锁的大门（用户认证——让合适的人进来）
• 收银台（支付——收取用户的费用）
• 卫生许可证（安全——保护用户数据）
• 盯场的店长（监控——及时发现故障）
• 预订系统（用户账号与数据管理）
• 清晰的菜单（真正好用的界面，不只是原型）
• 不会着火的厨房（错误处理）
• 稳定的供应链（文件存储、邮件、第三方服务）

这 8 项功能，几乎每一个真实的应用都需要。好消息是：你不必一次全部做完。

分层构建。

从 MVP 开始——Minimum Viable Product，最小可用产品。说白了就是：你能构建的最精简版本，但仍然对用户有实际价值是什么？

• 第一层：用户认证 + 核心功能。用户能登录，能使用最主要的那个功能。
• 第二层：支付。用户能付费给你。
• 第三层：完善细节。邮件通知、文件上传、搜索、管理后台。
• 第四层：生产加固。安全性、错误处理、监控告警。

每一层都让你的应用更接近真实产品。而每一层，都是你和 AI 之间的一次对话。

光是这个提示词，就能把 AI 从"玩具模式"切换到"真实应用模式"。你在告诉它：我认真了，按照正式产品的标准来做。

第 2 章：选择技术栈（别想太多）

"技术栈"就是你的应用所使用的一组工具。就这么简单，没什么复杂的。

厨房设备的比喻。

选技术栈就像选厨房设备。燃气灶还是电磁炉？商用烤箱还是家用烤箱？炒锅还是铸铁锅？每种选择都能做出好菜。专业厨师有各自的偏好，但最终端上桌的食物都很美味。

你会看到有人说要用 Rust、Go、Elixir，或者这个月最流行的某个新技术。忽略他们。做 Vibe Coding，你需要的是 AI 对它非常熟悉、能快速写出可靠代码的技术栈。

这样筛选下来，有两个很好的选择。

选项一：Python 技术栈

前端：  React 或原生 HTML/CSS/JavaScript
后端：  FastAPI（Python）
数据库：PostgreSQL
ORM：   SQLAlchemy 或 Prisma

FastAPI 是一个 Python 后端框架。它快、现代，AI 对它了如指掌。如果你对 Python 思维方式更熟悉，或者你之后打算做数据处理、AI 或机器学习相关的功能，选这个。

选项二：JavaScript 技术栈

前端：  Next.js（基于 React）
后端：  Next.js API 路由（内置）或 Express
数据库：PostgreSQL
ORM：   Prisma

Next.js 把前端和后端合在一个框架里。用一门语言（JavaScript / TypeScript）搞定一切。如果你想要配置最少、结构最简洁的方案，选这个。

两个技术栈都使用 PostgreSQL。这是数据库。它是业界标准，免费开源，从 10 个用户到 1000 万用户都能应付。SQLite 适合你之前的玩具应用，PostgreSQL 适合真正的产品。

关键在于：选一个，然后开始动手。

不要花三天时间读对比文章，不要去论坛发帖求推荐。AI 对这两个技术栈都非常熟悉，你选的那个绝对能用。最好的技术栈，就是你实际开始构建的那一个。

AI 会生成一个看起来很专业的项目结构。目录分明，配置文件就位，数据库连接就绪。和手动从零搭建相比，你省了大概两天的时间。

还有一个你会经常看到的词：ORM。ORM 是代码和数据库之间的翻译器。你不用写原始的数据库指令，只需写普通的代码，ORM 会自动翻译成数据库能理解的语言。你可以把它想象成一个双语助理——你说中文，数据库说 SQL，ORM 负责从中协调。

第 3 章：登录的原理

你用的每一个 App 都有登录界面。微信、抖音、淘宝——它们都会在放你进去之前先确认你是谁。让我们来搞清楚那个登录界面背后究竟发生了什么。

音乐节手环的比喻。

你去参加一个音乐节。在入口，你把票给工作人员看。他们检查之后，在你手腕上套上一个手环。之后一整天，你不用再拿出票了——只需要亮出手腕，安保人员看到手环就放行。

互联网上的登录就是这样工作的。具体步骤如下：

就这些了。世界上每一个登录系统都是这样工作的。细节有差异，但模式始终相同。

会话（Session）与令牌（Token）——两种手环。

这个"手环"有两种实现方式：

会话（Session）——场馆保存名单。你登录时，服务器把你的名字写进一张清单，然后给你一个编号。你每次发请求，都带上这个编号。服务器查清单："编号 4729……好的，这是小明，可以进来。"凭证保存在服务器端。

令牌（Token）——你自己带着凭证。你登录时，服务器给你一个特殊的手环，你的信息已经编码在里面了。你每次发请求，都带上这个手环，服务器直接读手环，不需要查清单。凭证由你自己保管。最常见的格式叫做 JWT（JSON Web Token，读作"jot"）。

大多数现代应用使用令牌。服务器不需要维护清单，扩展起来更简单。

为什么密码绝对不能原文存储。

这点非常重要。任何负责任的应用都不会存储你的真实密码。从不。

想象你在纸上写了一段秘密内容，然后把它送进碎纸机，得到一堆独特的碎片。你无法把碎片还原回原文——这是单向操作。但如果有人用同一台碎纸机处理同样的内容，得到的碎片图案会完全一致。

这就是哈希（Hashing）。你注册账号时，服务器拿到你的密码，送进一个数学意义上的"碎纸机"（哈希函数），然后存储碎纸后的结果。你下次登录时，服务器对你输入的密码做同样的处理，再比对：碎纸后的结果和存储的一致吗？

就算黑客盗走了数据库，他们拿到的也是碎纸结果。毫无用处——无法还原。

三种常见的登录方式：

1. 邮箱 + 密码——最经典的方式。你设定一个密码，应用存储它的哈希值。
2. 微信登录（OAuth）——你让微信来替你作证。应用根本看不到你的密码。微信说"这个人是真实用户"，应用信任微信的背书。国内用户对这种方式最熟悉，转化率也最高。
3. 手机验证码——应用发一条一次性验证码到你的手机。你输入验证码，直接登录，不需要记密码。国内用户普遍接受这种方式。

每种方式都有取舍。微信登录对用户来说最简单（一键授权），在国内用户群体中转化率最好。邮箱密码最通用。手机验证码安全性高，但需要对接短信服务商（例如阿里云短信、腾讯云短信）。

第 4 章：用 AI 构建认证功能

做认证有一条黄金法则：不要从零自己写。

认证有上千种出错的可能。密码存储、会话管理、令牌过期、CSRF 攻击、暴力破解防护——问题列表很长。聪明的开发者不会自己实现这些，他们使用经过大量验证的成熟工具。

你有两条路可以走：

路线一：库（Library）——你自己托管所有东西

库是接入你应用的代码包。你的应用处理登录流程，但库负责做安全性相关的重活。

• NextAuth.js（现在叫 Auth.js）——用于 Next.js 应用。支持 OAuth、邮箱登录、会话管理，非常流行，免费开源。
• FastAPI Users——用于 Python 应用。处理会话和用户管理。

优点：免费，完全掌控，数据留在你自己手里。
缺点：配置工作更多。数据库设计、密码哈希、邮件验证你得自己搞定（虽然库会帮很多忙）。

路线二：服务（Service）——让别人替你搞定

服务是一家专门做认证的外部公司，替你包揽所有认证相关的工作，你只需接入他们的接口。

• Clerk——漂亮的预制登录页面，拖拽式接入，上手很快。
• Auth0——行业标准，大公司广泛使用，免费额度慷慨。
• Supabase Auth——和 Supabase 数据库一起免费提供。如果你本来就用 Supabase，非常合适。

优点：省力得多，安全性久经考验，登录/注册/找回密码的 UI 都是现成的。
缺点：依赖外部服务，用户量大了之后费用会增加。

关于微信登录： 如果你面向国内用户，强烈建议接入微信登录。你需要在微信开放平台注册应用，获取 AppID 和 AppSecret，然后按照微信 OAuth 流程对接。Clerk 和 Auth0 目前对微信登录的支持有限，这种情况下用 NextAuth.js 配合微信 OAuth 自定义 Provider，或者直接调用微信 SDK，会更灵活。

该如何选择？

• 全新项目、希望快速上线？使用 服务，比如 Clerk 或 Supabase Auth。
• 在已有项目基础上加认证？使用 库，比如 NextAuth.js。
• 需要接入微信登录或完全掌控数据？使用 库，自行对接微信 OAuth。

注册流程：

登录流程：

找回密码：

"记住我"功能：

接入微信登录：

接入微信登录需要在微信开放平台注册并通过审核，获取 AppID 和 AppSecret。AI 会带着你一步步操作，但要知道这部分需要在微信开放平台后台做一些配置，大概需要等待 1-3 个工作日的审核时间。

接入手机验证码登录：

第 5 章：保护页面和数据

现在登录功能已经有了，用户可以注册和登录。但此时此刻，任何人只要直接在地址栏输入 URL，还是能访问任意页面。这就好比你给前门装了锁，却把所有窗户都开着。

保安模式。

把你应用里的每一个页面想象成一家夜店里的不同区域。有些区域对所有人开放——首页、价格页面、登录页面。那是大堂。

但是仪表盘？设置页面？管理后台？这些区域门口有保安。你想进去之前，保安会查一下："你有手环吗？手环有效吗？好，进来。"没有手环，保安会把你送到门口（登录页面）。

这叫做受保护的路由。路由就是 URL 路径（比如 /dashboard 或 /settings）。受保护的路由就是需要登录才能访问的路径。

认证（Authentication）与授权（Authorization）——两个不同的问题。

这两个词听起来很像，但含义完全不同。

认证（Authentication）= 你是谁？（检查手环。）
授权（Authorization）= 你有权做什么？（检查你的手环能不能进后台区域。）

已登录的用户可以看自己的仪表盘。但他们能看别人的仪表盘吗？能删除别人的帖子吗？能进管理后台吗？

这就是授权。核心在于角色。

角色：谁能做什么。

大多数应用至少有两种角色：

• 普通用户（User）——可以使用应用、查看自己的数据、管理自己的账号
• 管理员（Admin）——可以看到所有内容、管理所有用户、更改系统设置

有些应用有更细化的角色：

• 审核员（Moderator）——可以审核和删除内容，但不能修改系统设置
• 编辑（Editor）——可以创建和编辑内容，但不能管理用户
• 只读用户（Viewer）——只能查看，不能修改任何内容

在数据库里，这通常只是用户表上的一个字段，比如 role: "admin" 或 role: "user"。就这么简单。

行级安全：用户只能看到自己的数据。

这一点至关重要。假设你的应用有笔记功能，每个用户有自己的笔记。如果不做处理，用户 A 只需在 URL 里改一个数字，就可能看到用户 B 的笔记。

行级安全的意思是：当数据库查询笔记时，自动过滤，只返回属于当前登录用户的笔记。就像一个文件柜，每个抽屉只对它的主人开锁。

第6章：在线支付的原理

关于在线支付，有一条最重要的规则：你永远不会碰到用户的银行卡号。

认真的。你看不到卡号。你不存储卡号。你不处理卡号。如果你这样做，你就是在违法，并且在自找麻烦。

那么，支付是怎么运作的？

收银台的类比。

想象你开了一家店。你可以从零开始自己造一台收银机——想办法接受银行卡，处理收据，处理退款，和银行对接，处理欺诈。或者，你直接去买一台现成的、能做这一切的收银机。

这台收银机，就是微信支付或支付宝。

微信支付和支付宝是国内最主流的两大支付平台。你把用户引导到支付流程，平台收款后把钱转给你（扣除少量手续费，通常在千分之几）。你不碰银行卡，安全验证、风控、凭证、税务——这一切都由平台处理。

国内绝大多数应用都使用这两个平台。AI对它们非常熟悉。选一个（或两个都上）。

用户付款的完整流程——一步步来：

注意：你的应用全程看不到任何银行卡信息。在第3步，用户会跳转到微信或支付宝的安全界面完成付款，然后再回到你的应用。你的服务器只会收到"成功"或"失败"两种通知。

一次性付款 vs. 订阅制。

一次性付款—用户付一次，得到商品。比如买一本电子书，付款后直接获得访问权限。

订阅制—用户每月（或每年）持续付款。比如视频会员。只要用户持续付款，就能一直用。取消了，权限就停止。

大多数SaaS应用（Software as a Service，即按月付费的在线软件）都采用订阅制。微信支付和支付宝都支持这两种模式。

第7章：构建支付功能

来实战。以下是在应用中接入支付的具体步骤。

第一步：注册微信支付商户。

你需要一个微信支付商户账号。前往微信支付商户平台（pay.weixin.qq.com）注册。个人开发者建议先注册个体工商户或企业主体，审核通过后你会获得几个关键参数：

• AppID — 你的应用唯一标识，前端和后端都会用到
• 商户号（mchid） — 你的商户唯一标识
• API密钥 / 私钥 — 绝对不能暴露在前端，放在 .env 文件里
• API证书 — 部分接口需要，下载后妥善保管

支付宝同理，去支付宝开放平台（open.alipay.com）申请，拿到 AppID 和应用私钥。

第二步：使用JSAPI支付（最常见的方式）。

JSAPI支付适合在微信内H5页面或小程序中收款，是目前最主流的微信支付场景。用户在微信里浏览你的页面，点击付款，直接唤起微信支付弹窗，无需跳出应用。

第三步：理解回调通知（异步通知）。

这是很多人感到困惑的地方，但其实很简单。

回调通知是指支付平台主动调用你的服务器，告诉你某件事发生了。就像餐厅给你打电话确认预订一样。你先打电话预订了位置（发起支付），一会儿餐厅回电话："您7点钟的位置确认好了"（支付成功）。

为什么不能在用户回到成功页面时再判断是否支付成功？因为用户可能关闭浏览器、断网、刷新页面。跳转不可靠。而回调通知是可靠的——平台会持续重试，直到你的服务器确认收到消息为止。

第四步：沙箱测试。

微信支付和支付宝都有沙箱（测试）环境。你可以用测试账号和虚拟金额走完整个支付流程，不会产生真实扣款。

• 微信支付沙箱：在商户平台开通，使用沙箱 AppID 和密钥，用微信开发者工具模拟支付
• 支付宝沙箱：在开放平台的沙箱环境中，下载沙箱版支付宝App，用测试账号模拟付款

在沙箱里把所有流程跑通后，再换成正式密钥上线。代码不需要改，只换环境变量就行。

第8章：订阅制与自动续费

大多数正式应用不只是一次性收款。它们有套餐，有不同档次，有让用户管理订阅的账单页面。我们来把这一切都搭起来。

套餐与档次设计。

几乎所有SaaS应用都有三个档次。一个常见模式：

在数据库里，每个用户有一个 plan 字段，值可能是 "free"、"pro" 或 "enterprise"。当用户尝试使用专业版功能时，你的应用检查：他的套餐是"pro"或更高吗？如果不是，就显示升级引导页面。

追踪用户当前套餐。

这些信息存在数据库里。每个用户需要几个字段：

• plan — 当前所在档次（free、pro、enterprise）
• pay_channel — 付款渠道（wechat、alipay）
• out_trade_no — 商户侧的订单号，用于对账
• subscription_status — 订阅状态（active、cancelled、expired、trialing）
• period_end_time — 当前计费周期结束时间

当平台发来通知说"这笔订阅续费成功了"，你就更新这些字段。当平台说"该订阅已取消"，同样更新一遍。

升级与降级。

用户从免费版升级到专业版时，你创建一笔新的订阅订单。从专业版升级到企业版，则更新现有订阅至新套餐。降级时同理——更新订阅，并按比例计算退款或不退款（根据你的产品策略决定）。

取消订阅。

用户取消时，你有两个选择：立即停止，或在当前计费周期结束时停止。大多数应用选择周期末取消——用户这个月已经付了钱，让他用完。

支付宝周期扣款（自动续费）。

支付宝提供"周期扣款"能力，用户授权后，系统可以在每个周期自动发起扣款，无需用户每次手动操作。适合订阅制产品。接入时需要在支付宝开放平台申请周期扣款权限。

账单与发票。

你可以在应用里展示用户的消费记录，从数据库中读取历史订单即可。用户很喜欢在账单页面看到自己的付款记录，有时候还需要下载电子发票（可以在平台商户后台申请开票能力）。

这是个大功能。AI可能需要多轮才能做完。这很正常。可以分步来——先做定价页，再做账单页，最后做回调处理。

第9章：超越简单表格

你的入门练习项目可能只有一两张数据库表格。待办事项应用的 tasks 表，博客的 posts 表。

真实的应用有5张、10张、15张，有时甚至数百张表。这些表彼此之间有着重要的连接关系。

关系：表格之间如何连接。

把你的数据库想象成一棵家族树。人与人之间有亲属关系——父母有孩子，兄弟姐妹共享父母，表亲通过祖父母联系。数据库表格的工作方式完全一样。

一对多：一个父级，多个子级。

一个用户发布多篇帖子。一家店铺有多种商品。一个班级有多名学生。

在数据库中，这意味着"子级"表（帖子）里有一列指向"父级"表（用户）。每篇帖子都有一个 user_id，表示"我属于这个用户"。

多对多：双向的关系。

学生和课程。一个学生选多门课。一门课有多名学生。双方都不"从属于"对方——关系是双向的。

你不能在课程表里加一个 student_id 列（因为一门课有很多学生）。也不能在学生表里加一个 class_id 列（因为一个学生选很多课）。

解决方案：一张位于两者之间的第三张表。它叫做关联表（或中间表）。它只有两列：student_id 和 class_id。

一对一：单一配对。

一个用户有一个个人资料。一笔订单有一张收据。这种情况比较少见，但当你想把一张大表拆分成多张小表时会用到。

数据库迁移：一间一间地翻新你的房子。

随着应用成长，你会需要修改数据库。这里加一列，那里改个表名，创建一段新的关联关系。

迁移（migration）是一个描述数据库单次变更的文件。把它想象成翻新房子——每次迁移是一个独立的施工任务："在二楼加一个卫生间"或者"拆掉厨房和餐厅之间的墙"。

你按顺序保存所有迁移。迁移1，然后2，然后3。每次都在上一次的基础上叠加。如果你要在新电脑上搭建数据库，只需按顺序执行所有迁移，就能得到完全一样的结构。

这是数据库的版本控制。对于真实应用来说不可或缺——因为你会一次又一次地修改数据库设计。

索引：快速查找的书签。

查书时，你会翻到最后的索引页。你不用逐页阅读——在索引里找到关键词，直接跳到对应页码。

数据库索引的工作方式完全一样。如果你经常按手机号查找用户，就在手机号这一列加索引。这样数据库就能瞬间找到用户，而不用扫描每一行。

经验法则：在所有你频繁搜索、排序或过滤的列上加索引。

什么时候SQLite不够用。

SQLite是一个轻量级数据库，把所有数据存在一个文件里。非常适合学习和原型开发。但当多个用户同时访问时它会出问题，复杂查询性能也跟不上。

PostgreSQL才是正式生产环境的选择。它能处理数千个并发用户，支持高级特性，是真实产品使用的数据库。从SQLite切换到PostgreSQL，就像从一个小本子换成一套完整的档案系统——理念一样，能力天壤之别。

第10章：用户角色与权限

每个真实的应用都有不同类型的用户，能做不同的事情。你的工作是决定谁能做什么。

简单方案：一个角色字段。

处理角色最简单的方式，是在用户表里加一个叫 role 的列。它存储 "user"、"admin" 或 "moderator" 这样的值。

然后在代码里检查：如果用户的角色是"admin"，就允许他做管理员能做的事。否则，显示"无权限"提示。

这对大多数应用来说足够了。如果你有2到4个边界清晰的角色，这就是你需要的全部。

灵活方案：权限表。

如果你需要精细控制呢？比如有些版主可以删帖但不能封号。有些管理员可以管理账单但不能查看用户数据。

这时就要用权限表了。不再是一个简单的"角色"列，而是一张完整的表，将用户映射到具体的操作权限：

张三（用户1）可以管理用户、账单和删帖。王五（用户3）可以删帖和封号。李四没有特殊权限——他是普通用户。

这需要更多初始配置工作，但给了你完全的灵活性。当你的角色边界不清晰时使用它。

多租户：公寓楼里的独立单元。

有些应用服务于多家公司或组织。想想企业微信——每家公司有自己独立的工作区。A公司的用户看不到B公司的消息。同一个应用，完全隔离的空间。

这叫做多租户（multi-tenancy）。类比是一栋公寓楼。大家住在同一栋楼里（使用同一个应用），但每套公寓（每个组织）完全独立。你走不进邻居家。

在数据库里，你给几乎每张表都加一个 organization_id。每次查询都按该组织过滤。当A公司的张三加载消息时，应用只拉取 organization_id 匹配A公司的消息。

第11章：文件上传

用户想要上传各种东西。头像。文档。帖子里的图片。简历。收据。

关键原则是：文件不放在数据库里。

你的数据库存储文本、数字和日期。存文件它非常糟糕。就像把真实的照片和活页夹塞进一个文件柜——它会迅速变得臃肿且缓慢。

文件应该放在对象存储服务里——一个专门为存储文件而设计的独立地方。你的数据库只存储文件最终存放位置的URL（网址）。

国内常用的对象存储服务：

• 阿里云OSS（对象存储服务） — 国内使用最广泛。稳定可靠。按用量计费。有丰富的SDK支持。
• 腾讯云COS（对象存储） — 与微信生态深度整合，适合微信小程序项目。有免费额度。
• 华为云OBS（对象存储服务） — 企业项目备选，合规性好。
• 七牛云 — 专注于媒体存储和CDN，图片处理功能丰富，有慷慨的免费额度，适合个人开发者起步。

它们都做同一件事：存储你的文件并给你一个URL。选一个AI最熟悉的（通常是阿里云OSS或七牛云）。

图片压缩与裁剪。

当有人上传一张4000x3000像素的照片作为头像时，你不会想每次都把完整图片发给客户端。那样又慢又费流量。你需要压缩它——生成一个更小的版本（比如200x200）用于头像显示，也许再生成一个中等版本用于其他场景。

阿里云OSS和七牛云都内置了图片处理功能，可以通过在URL后面加参数实现实时裁剪、缩放和格式转换，不需要另外写代码。

第12章：发送邮件与消息通知

真实的应用需要发通知。不是那种营销推广的（当然那个也要），而是"你的订单已发货"、"这是你的密码重置链接"、"有人评论了你的帖子"这类通知。

这类通知叫做触发式通知——由用户的某个操作触发。它们不是垃圾信息，用户是期待收到的。

国内的通知渠道。

在国内，触达用户的通知方式和海外不太一样。邮件当然还在用，但微信消息往往更高效，打开率也更高。

邮件发送选项（国内推荐）：

• 阿里云邮件推送（DirectMail） — 国内邮件发送的主流选择。到达率高，有详细的发送统计，与阿里云生态整合方便。每天有一定免费额度。
• 腾讯云SES（简单邮件服务） — 与腾讯云生态整合，适合已经在用腾讯云的项目。
• SendCloud（搜狐旗下） — 专注于邮件发送，有免费套餐，对个人开发者友好。

微信模板消息：

如果你的应用有关联微信公众号或小程序，可以给用户发送模板消息——这是微信官方提供的服务通知能力。用户关注公众号或使用小程序后，你可以推送标准化的通知，比如"您的订单#12345已发货，预计明天送达"。

模板消息不是广告推送，是服务通知，打开率远高于邮件。如果你的用户主要在微信生态里，优先考虑这个渠道。

触发式通知 vs. 营销通知。

触发式 — 由用户操作触发。密码重置、订单确认、欢迎消息、各类提醒。用户期待这些。你不需要额外获取许可（他们已经触发了该操作）。

营销类 — 新闻简报、优惠活动、公告。用户必须主动订阅。你需要提供退订功能。这在很多国家和地区是法律要求。对于这类通知，使用独立的渠道（比如邮件营销系统或公众号群发）。

不要混用。触发式通知必须立即到达。营销通知可以批量发送。如果你通过触发式渠道发了营销消息被标记为骚扰，你的密码重置通知也会发不出去。

消息模板。

没有人每次都手写通知内容。你创建模板——带有占位符的可复用设计。就像填空题：

"亲爱的【用户名】，您的订单#【订单编号】已发货！点击查看物流：【物流链接】"

AI在发送时自动填入具体内容。

第13章：搜索与筛选

每个有列表的应用都需要搜索功能。用户表？你需要按姓名或手机号搜索。商品页？你需要按分类和价格筛选。文章列表？你需要按标题和内容搜索。

基础搜索：检查文本是否包含搜索词。

这是最简单的方式。用户输入"苹果"，你就查找所有名称里包含"苹果"的商品。这个方法可行。对于小数据集（不超过1万条记录）速度也足够快。

进阶搜索：全文搜索。

当数据量变大，或者你需要更智能的匹配（搜索"跑步鞋"也能找到"运动球鞋"），就需要全文搜索了。PostgreSQL内置了这个功能。如果需要更强大的能力，可以考虑 Meilisearch（开源，适合自建）或阿里云OpenSearch（托管服务，适合企业）。

筛选：缩小列表范围。

搜索是按文本找内容，筛选是按属性缩小范围。"显示价格低于200元，且在3C数码分类，且好评4星以上的商品。"每个筛选条件就是一个过滤器，叠加使用。

排序：把结果排列好。

按时间（最新在前）、按价格（从低到高）、按名称（拼音顺序）、按热度。用户期待能排序，只是一个下拉框的事。

分页：每次显示20条，而不是一次显示10000条。

如果你的数据库有5万件商品，你不会一次全部加载。那会让浏览器崩溃，而且要等很久。

你每次只加载一页。第1页显示第1到20条。第2页显示第21到40条。以此类推。这就是分页。

有两种风格：

• 传统分页 — 带页码（第1、2、3页……像百度搜索结果一样）
• 无限滚动 — 滚动到底部时自动加载更多（像微博或抖音评论一样）

两种都可以。传统分页实现更简单，对大多数场景也更合适。

第14章：管理后台

你把应用做好了。用户在注册。现在你需要了解发生了什么。今天有多少用户注册？有没有需要审核的内容？有没有付款失败的情况？

每个真实的应用都需要管理后台。它不是给你的用户用的——是给你自己用的。

管理员通常需要看什么：

• 数据总览 — 总用户数、今日新增、本月收入、有效订阅数
• 用户管理 — 所有用户列表，可搜索、查看详情、修改角色、封禁/解封账号
• 内容管理 — 所有帖子/商品/内容条目，可编辑或删除
• 收款信息 — 最近的交易记录、付款失败情况、订阅统计
• 系统健康 — 最近的错误日志、接口响应时间、数据库大小

最简单的方案：一个 /admin 路由。

你不需要单独搭一个独立的后台系统。只需在现有应用里创建一个 /admin 区块，只有管理员角色的用户才能访问。

在这个区块里，用表格展示你的数据。用户表显示姓名、手机号/邮箱、注册时间、套餐、账号状态。交易表显示最近的收款记录。再加一个简单的数据看板，几个数字，可能再加一两个图表。

图表与数据统计。

数字是好的，图表是更好的。一条折线图显示过去30天的新增注册量，讲述了一个纯数字无法传达的故事。一个柱状图显示按月的收入趋势，让你一眼看出规律。

Chart.js、ECharts（国内开发者很熟悉，百度出品）等图表库让添加图表变得很简单。AI可以快速把它们接入进去。

内容审核。

如果你的应用有用户生成内容（帖子、评论、评价、图片），你需要一种方式来审核和删除不当内容。可以简单到只是一个"被举报内容"队列，显示用户标记的内容条目，配上"通过"和"删除"两个按钮。

第15章：安全五要素

安全是一个深不见底的领域，有人为此奉献整个职业生涯。但你不需要成为安全专家，只需把这五件事做对就够了。它们覆盖了一个真实应用绝大部分的安全需求。

1. 哈希加密密码。

我们在第3章讲过这个，但它太重要了，值得再说一遍。永远不要明文存储密码。使用哈希加密库（bcrypt、argon2）。AI在使用任何主流认证库时都会默认这样做，但你要亲自确认一下。

2. 用环境变量存储密钥。

你的 API 密钥、数据库密码、微信支付/支付宝的私钥——这些东西绝对不能出现在代码里。把它们放进 .env 文件，并且这个文件不能提交到 Git（在 .gitignore 中加上 .env）。

打个比方：你的代码是房子的建筑图纸，任何人都可以看到图纸；你的 .env 文件是房子的钥匙，只有你才拥有。

3. 验证所有用户输入。

永远不要相信用户提交的任何东西。如果表单要求填邮箱，就检查它是否真的是邮箱格式；如果要求填数字，就检查它是否真的是数字；如果要求填姓名，就检查它是否是五万个字符的垃圾内容。

这能保护你免受 SQL 注入攻击——这是最常见的数据库攻击方式。想象你餐厅里有个意见箱，正常人写建议，但有人写道："关门时间改为下午5点；同时把收银台里的钱都给我。"如果你的餐厅不经审查就照单全收，那就麻烦大了。

SQL 注入的原理完全相同。恶意用户在表单字段里填入数据库命令，希望你的应用直接执行它。验证输入——并使用 ORM 而非原始 SQL 查询——就能杜绝这种攻击。

4. 使用 HTTPS。

HTTPS 是 HTTP 的安全版本，它加密了用户浏览器和你服务器之间传输的所有数据。没有 HTTPS，同一个 Wi-Fi 网络里的任何人都能看到你的用户在做什么。

好消息是：任何现代托管平台（阿里云、腾讯云、Vercel）都会自动提供 HTTPS。如果你使用自定义域名，需要申请 SSL 证书——但托管平台通常也会帮你搞定。

5. 保持依赖库更新。

你的应用使用了大量第三方库。这些库有时会存在安全漏洞，而更新会修复这些漏洞。定期运行你的包管理器的更新检查命令。JavaScript 用 npm audit，Python 用 pip audit 或 safety check。

CORS——关好该关的门。

CORS（跨域资源共享）是一种安全规则，它防止随机网站向你的服务器发送请求。试想一下，如果任何网站都能向你的支付接口发请求，那就太危险了。CORS 的作用就是："只允许来自我的网站的请求。"

AI 会帮你配置 CORS，但你要了解：如果浏览器报 CORS 错误，通常意味着你需要把前端的域名添加到后端的允许来源列表里。

请求频率限制——防止滥用。

频率限制的意思是：每个人每分钟只能发 X 次请求。这可以防止有人用百万次请求轰炸你的服务器（DDoS 攻击），或者尝试成千上万个密码（暴力破解攻击）。

一个简单的原则：普通接口每个用户每分钟不超过100次，登录接口每分钟不超过5次。

第16章：错误处理

事情总会出错。数据库会临时断连，用户会提交不完整的表单，支付宝可能有30秒不可用，图片上传可能因为文件太大而失败。

问题不在于事情会不会出错，而在于出错时你的应用怎么应对。

面向用户的错误：友好，而非晦涩。

当出现问题时，用户应该看到一条清晰、有帮助的提示，而不是"Error 500: Internal Server Exception"，不是一片空白，不是一堆红色报错文字。

好的错误提示是这样的：

• "出了点问题，请稍后重试。"（用于意外错误）
• "该邮箱已被注册，请直接登录。"（用于已知的具体错误）
• "文件太大，最大限制为5MB。"（用于验证错误）

规律很简单：告诉用户发生了什么，告诉他们怎么做。

日志记录：给应用写日记。

当出现问题时，即使用户看到的只是一条友好的提示，你自己也需要知道发生了什么。这就是日志记录的作用。

你的应用每次发生重要事件时，都会把记录写入日志文件（或日志服务）。不只是错误——重要的操作事件也一样。"用户42完成注册。""收到29元支付。""图片上传失败：文件过大。"

把它想象成给应用写日记。当出了问题，翻开日记就能知道发生了什么。

错误追踪：在用户投诉之前就发现问题。

日志记录很好，但谁整天盯着日志看呢？没人。这就是错误追踪服务的用武之地。

Sentry 是最受欢迎的选择。它能自动捕获应用中的错误并发送通知给你。它会把相似的错误归类在一起，精确告诉你是哪一行代码出了问题，以及有多少用户受到影响。

就像给应用装了一个烟雾报警器。你不需要在每个房间里闻烟味——报警器会主动通知你。

错误边界：一个房间着火，其他房间安然无恙。

在真实的应用里，某一个功能崩溃了，不应该把整个应用都拖垮。聊天组件出错了，页面其他部分应该照常运行；搜索栏报错了，用户应该仍然能看到页面内容。

这就叫做错误边界。它包裹住应用的某个部分，并说："如果这个区域里的任何东西崩了，就显示一条备用提示，而不是让整个页面挂掉。"

就像大楼里的防火门。如果一个房间起火，防火门阻止火势蔓延，其余区域完好无损。

第17章：正式部署

你已经部署过演示项目了，也许放到了 Vercel 或某个云平台上，能访问，能看到页面。

但部署一个真实应用是另一回事。真正的部署意味着：它能保持稳定运行，它是安全的，你能在不搞砸任何东西的情况下更新它。

生产环境中的环境变量。

.env 文件在本地开发时用得上。在生产环境里，你需要通过托管平台的控制台来配置环境变量。每个平台都有设置页面，让你粘贴进去你的密钥。代码读取的方式完全一样——它不知道、也不关心这些值究竟来自 .env 文件还是平台的配置界面。

永远不要把 .env 文件上传到生产环境。通过控制台逐条配置每个变量。

生产环境用 PostgreSQL，不用 SQLite。

如果你在开发阶段一直用 SQLite，上线时必须切换到 PostgreSQL。SQLite 无法处理多用户同时访问数据库的情况。国内外的主流托管平台都提供托管 PostgreSQL 服务：

• 阿里云 RDS for PostgreSQL——国内首选，稳定可靠，有免费试用，配套中文支持
• 腾讯云 PostgreSQL——腾讯云生态内一站式托管，控制台友好
• Supabase——有免费套餐，控制台直观，适合个人项目和出海产品
• Neon——Serverless 架构的 PostgreSQL，有免费套餐，按用量自动扩缩容

创建生产数据库，并把它的连接字符串填入生产环境变量里。

域名 + ICP 备案 + SSL。

你的应用现在跑在类似 myapp.vercel.app 这样的地址上，测试用没问题。正式产品需要你自己的域名（比如 myapp.com` 或 `myapp.cn）。

关于 ICP 备案——这是中国大陆运营网站的法律要求，绝不能忽视。 如果你的服务器在中国大陆境内，域名必须完成 ICP 备案，否则网站随时可能被关停。

1. 注册域名——在阿里云（万网）、腾讯云或 Namesilo 购买域名。.cn 域名在国内更便宜，.com 更通用。
2. 申请 ICP 备案——如果服务器在中国大陆，通过你的云服务商（阿里云/腾讯云）申请 ICP 备案。准备好营业执照（企业）或身份证（个人）。审批周期约为7-20个工作日，提前规划好时间。
3. 配置 DNS——把域名指向你的托管平台（平台会告诉你具体填什么）。
4. 开启 SSL——启用 HTTPS，大多数平台会自动处理。阿里云和腾讯云均提供免费 SSL 证书。

域名费用大约每年50-150元（.cn），或70-100元（.com）。ICP 备案本身免费，但需要时间。

CI/CD：推代码，自动上线。

CI/CD 是持续集成/持续部署的缩写，说穿了就是一个简单的想法：每次你把代码推送到 GitHub，应用就自动部署新版本。

就像工厂里的流水线。你把东西放上流水线（推代码到 GitHub），它自动经过质检（运行测试）、打包发货（部署到生产环境）。

Vercel 和大多数国际平台会在你连接 GitHub 仓库后自动处理这一切。国内可以用阿里云效（Flow）或腾讯云 CODING——它们都支持连接 GitHub/Gitee 仓库并自动触发部署。推代码，等60秒，新版本就上线了。

预发布环境：正式上线前先排练。

预发布环境（Staging）是你生产应用的一个副本，只有你自己能访问。它有独立的数据库、独立的域名、独立的环境变量。和生产环境完全一致——但对外不公开。

在把重大改动上线到生产环境之前，先部署到预发布环境验证一遍。测试没问题后，再自信地推到生产。

就像正式演出前的彩排。同样的舞台、同样的服装、同样的台词——只是还没有观众。

数据库备份。

你的数据库是整个应用最重要的部分。代码没了，AI 能帮你重写；数据库没了，用户的数据就永远消失了。

设置自动备份。阿里云 RDS 和腾讯云数据库都提供自动每日备份，默认通常是开启的，但要进控制台确认一下。有些方案支持时间点恢复（Point-in-Time Recovery）——意思是你可以把数据库恢复到上周二下午3点47分时的状态。这个功能值得付费开通。

部署检查清单。

正式上线前，逐条过一遍这份清单：

• 已配置 PostgreSQL 数据库（不用 SQLite）
• 所有环境变量已在生产环境配置完毕
• .env 文件已加入 .gitignore（未提交到代码仓库）
• HTTPS / SSL 已启用
• 自定义域名已配置
• ICP 备案已完成（如服务器在中国大陆境内）
• 数据库自动备份已开启
• 错误追踪（Sentry）已配置
• 登录和注册接口已启用频率限制
• 所有密码已哈希加密（非明文存储）
• CORS 已配置为只允许你的域名
• 所有接口均已对用户输入进行验证
• 支付回调（Webhook）已接入（如适用）
• 邮件发送已测试并正常运行
• 管理员账号已创建
• CI/CD 自动部署已连接到代码仓库
• 预发布环境已搭建并验证通过
• 已有人（除你之外）测试过这个应用

把这份清单打印出来，逐条核对。如果有任何一条没打勾，在上线前请 AI 帮你补上。

你已经完成了前半部分。现在你知道如何为你的应用添加用户认证、支付、数据库设计、文件上传、邮件发送、搜索、管理后台、安全防护、错误处理和生产部署。

继续构建吧。

第18章：Chrome 扩展

你的网页应用是一家餐厅，用户需要主动来找你。而 Chrome 扩展是外卖服务——它把你的产品送到用户已经在用的地方。

Chrome 扩展是运行在 Chrome 浏览器内部的小程序。你看到 Chrome 右上角那排小图标了吗？那些就是扩展——广告拦截器、密码管理器、深色模式切换，全都是扩展。

好消息是：Chrome 扩展用的正是你已经掌握的 HTML、CSS 和 JavaScript。会做网页应用，就会做 Chrome 扩展。

Chrome 扩展的结构：

每个扩展都由几个部分组成，就像一个小团队，每个成员各司其职。

manifest.json 是身份证。它告诉 Chrome 你扩展的名称、版本、需要哪些权限，以及加载哪些文件。每个扩展都必须有一份。

popup（弹出页）是用户点击扩展图标时出现的小窗口。它就是一个迷你网页——HTML、CSS 加上少量 JavaScript。

content script（内容脚本）是运行在其他网页上的代码。广告拦截器就是这样工作的——它们向你访问的每个页面注入代码，然后把广告隐藏掉。你的内容脚本可以读取页面内容、修改页面样式，或者添加按钮。

background script（后台脚本）是幕后工作者。它监听事件、管理状态、协调各部件。即使弹出窗口关闭了，它依然在运行。

你能做什么？

作为一个会 Vibe Coding 的人，你能做出出奇好用的扩展：

• 效率工具——在任何网页上高亮文字并保存、截图、记录时间
• 页面改造——修改字体、屏蔽干扰内容、给任何网站加深色模式
• 数据工具——抓取价格、追踪页面变化、把表格导出为表格文件
• 快捷面板——一键访问你应用的核心数据
• AI 助手——在任何网页上选中文字，右键即可获得 AI 摘要或翻译

发布你的扩展：

把扩展上架 Chrome 应用商店并不复杂。

1. 开发者账号——在 Chrome Web Store 开发者后台注册账号，费用是5美元，一次性付清，仅此而已。
2. 打包文件——把所有扩展文件压缩成一个 zip 包。
3. 上传——进入后台，点击"新建项目"，上传 zip 包。
4. 填写信息——添加描述、截图和图标，就像填写应用商店的上架资料一样。
5. 审核——Google 会进行审核，通常需要1-3天。他们主要检查恶意软件和政策违规。

上架之后，更新很简单：改好代码，在 manifest.json 里更新版本号，重新上传一个新的 zip 包。用户会自动收到更新。

第19章：手机 App

这里有个秘密，能让很多人省下大把时间和金钱：你完全不需要学 Swift 或 Kotlin，就能把应用上架到手机。

有三条路可以走，各有利弊。

路径一：PWA（渐进式网页应用）

这就像把你餐厅的网站链接发给用户，说"把这个保存到桌面上"。PWA 是你现有的网页应用加上几个升级，让它能像真正的 App 一样安装在手机上。

你需要添加一个叫"Service Worker"的小文件（它会缓存应用，让其在离线时也能使用）和一个"manifest"文件（告诉手机你的 App 叫什么、图标是什么）。基本上就这些。

• 费用：免费。一分钱不用花。
• 应用商店：不需要。用户直接从你的网站安装。
• 兼容性：iPhone 和 Android 均支持。
• 局限：旧版 iPhone 上推送通知支持有限；无法访问某些手机功能；部分用户对非商店 App 有顾虑。

路径二：React Native / Expo

这就像在购物中心里开一家分店。你获得了流量、可信度和商场入口——但要遵守他们的规则。

React Native 让你用一套代码同时生成 iPhone 和 Android 应用。Expo 是一个工具集，让 React Native 的开发体验更轻松。写出来的代码和网页开发很像，最终产出的是真正的原生 App。

• 费用：Apple 开发者账号 99 美元/年；Google Play 一次性 25 美元。
• 应用商店：需要，在两大商店都有正式上架页面。
• 兼容性：一套代码，同时运行在 iPhone 和 Android 上。
• 局限：有一定学习曲线；某些手机功能需要额外配置。

路径三：Capacitor

这就像把你的餐车改造成固定摊位。你已经有一个运行中的网页应用了，Capacitor 把它包在一个原生壳里，让你能提交到应用商店。

• 费用：和上面一样的商店费用。
• 应用商店：需要。
• 兼容性：iPhone 和 Android。
• 最适合：已经有网页应用，只是想让它进商店。

如何选择：

安卓应用市场——中国大陆特有情况。

中国大陆没有 Google Play。安卓用户从各家手机厂商的应用市场下载 App：

• 华为应用市场（AppGallery）——华为和荣耀设备的主要渠道
• 小米应用商店——小米、红米设备
• OPPO 软件商店——OPPO、一加设备
• vivo 应用商店——vivo 设备
• 腾讯应用宝——跨品牌，装机量大，很多用户习惯用它

要覆盖大部分中国安卓用户，最低限度需要上架华为、小米和应用宝。每家平台的审核要求略有不同，通常需要提供营业执照（企业）或身份证（个人），并完成软件著作权登记（非强制但有助于通过审核）。

上架应用商店前要知道的坑：

• Apple 的30%抽成——凡是在应用内发生的数字内容购买，Apple 都要抽30%。实体商品没问题。但如果你在 App 内卖订阅、付费功能或数字内容，Apple 要分成，而且你必须使用 Apple 自己的支付系统。
• 审核时间——Apple 对每次更新都要审核，通常需要1-7天，而且会以奇怪的理由驳回。国内各安卓应用市场速度参差不齐，华为和小米通常3-5个工作日。
• 必须有隐私政策——App Store、Google Play 和国内各安卓市场都要求提供隐私政策链接。AI 可以帮你起草，但最好让律师审阅一遍。国内还需要符合《个人信息保护法》（PIPL）的要求。
• 必须提供截图——你需要为各种设备尺寸提供规格正确的截图。

第20章：桌面应用

大多数人都不需要桌面应用。网页应用对几乎所有场景来说都够用了。

但有时候确实需要。也许你的应用必须能离线运行，也许它需要访问本地文件，也许你的用户就是期待桌面体验——比如设计工具、代码编辑器或音乐软件。

关键在于：你其实早就会做了。

Electron——网页开发者的捷径

VS Code？用网页技术做的。Slack？网页技术。Discord？网页技术。Figma 桌面版？网页技术。

Electron 把你的 HTML、CSS 和 JavaScript 包装在一个桌面窗口里。你的网页应用就变成了 Mac 应用、Windows 应用和 Linux 应用。同一套代码。

代价是：Electron 应用体积很大，动辄100MB以上。因为每个 Electron 应用都内置了一个 Chrome 浏览器。用户对此褒贬不一。但它能用，而且是从网页应用变成桌面应用最快的路径。

Tauri——更轻量的选择

Tauri 做的事和 Electron 一样，但它使用系统内置的浏览器引擎，而不是自带一个 Chrome。结果是：应用体积极小（10MB 以内），运行也更快。代价是它相对较新，社区规模比 Electron 小。

用户怎么获取你的桌面应用：

两种方式：

1. 官网直接下载——在你的网站上放下载链接，用户下载后自行安装。简单直接，更新由你自己维护。
2. 应用商店——Mac App Store、Microsoft Store，或国内各主流应用商店。曝光度更高，更新更方便，但苹果/微软会抽成，而且要经过审核。

对于大多数 Vibe Coder 来说，如果你的应用在浏览器里运行得很好，就保持那样。桌面应用会增加额外的复杂度。但如果你的用户需要离线使用或深度访问系统功能，现在你知道该走哪条路了。

第21章：落地页——让访客变用户

你的产品做好了。现在需要有人来用它。

落地页是第一道关卡。用户通过搜索、朋友推荐、微博帖子、知乎回答找到你，然后打开这个页面。接下来的10秒决定一切：他们会注册，还是关掉标签页走人？

落地页不是一份简历，也不是一本说明书。它只做一件事：让访客点下那个按钮。

落地页的结构解剖。

一个高转化的落地页有固定的解剖结构。就像中餐馆的上菜顺序有讲究一样，顺序对了，体验才顺畅。

主标题是最重要的一行字。

大多数人写主标题时喜欢说自己的产品有多厉害。错了。用户不关心你的产品，他们关心自己的问题。

把主标题从"我们是最好的XXX工具"改成"你能用它做到什么"。对比一下：

• 差劲版：「全新AI驱动的智能合同管理系统」
• 好版：「5分钟搞定一份合同，再也不用找律师」

说人话。说用户脑子里已经有的那个问题。

副标题补充细节，按钮制造行动。

副标题解释"怎么做"。按钮上的文字要具体——"开始免费试用"比"提交"好，"领取你的30天免费额度"比"注册"好。让用户知道点击之后会发生什么。

社会证明——借用别人的信任。

刚开始没有用户怎么办？用你有的东西。早期内测用户的感谢截图、微信群里的正面反馈、你自己的使用案例——这些都算。随着用户增多，换成真实的用户数量和评价。

中国用户对社会证明特别敏感。"已有X家企业在用"、"来自腾讯/阿里的从业者推荐"这样的背书效果很好。如果有知名用户，征得同意后可以展示公司logo。

百度SEO——让搜索引擎找到你。

中国用户的主要搜索引擎是百度，不是Google。两者的SEO原理相似，但有一些重要区别。

首先，速度更重要。百度对页面加载速度的权重很高，国内服务器（阿里云、腾讯云、华为云）比境外服务器快得多。如果你的用户在中国大陆，把服务器放在国内。

百度SEO的核心要点：

• 页面标题（title 标签）：60字以内，包含核心关键词，放在最前面
• 描述（meta description）：150字以内，用一两句话说清产品价值，包含关键词
• H1标签：每页只用一个，包含核心关键词
• 内容质量：百度近年来越来越重视真正有价值的内容，不要堆砌关键词
• 移动端适配：必须。大多数中国用户用手机搜索和浏览
• HTTPS：百度明确将HTTPS列为加分项

注册百度站长平台（ziyuan.baidu.com），提交你的网站地图（sitemap），让百度更快索引你的页面。这相当于去百度那里报到登记。

也不要完全忽视Google。很多技术用户和出海业务的用户依然会用Google，而且Google Analytics和Search Console的数据质量更好。两边都要布局。

Open Graph标签——在微信/微博/知乎分享时好看。

当有人把你的链接分享到微信、微博、知乎时，会出现一张预览卡片——标题、描述、封面图。如果你不设置，这张卡片会很难看，有时甚至是空的。

Open Graph标签就是告诉平台"显示这张图、这个标题、这段描述"。把这几行代码加进你的<head>里：

封面图建议尺寸是1200×630像素。用Canva或者让AI帮你生成一张。微信分享的预览图至少要300×300像素，否则可能不显示图片。

落地页永远没有"做完"的时候——它是一个持续优化的过程。上线之后，用百度统计或Google Analytics看看用户在哪里离开，然后改掉那个地方。改标题，改按钮颜色，改第一屏内容——每次只改一个变量，看看转化率有没有变化。

第22章：邮件营销与微信公众号运营

在中国做产品，有一件事必须先说清楚：微信公众号比邮件更重要。

这不是说邮件没用。邮件依然是最稳定的触达方式之一，尤其是面向企业用户和出海产品。但在中国大陆，大多数普通用户不常查邮件，而是每天花几个小时刷微信。所以，本章两样都讲。

微信公众号——中国创业者的第一营销阵地。

公众号是你在微信生态里的"官方频道"。用户关注你，你发文章，他们在微信里就能看到。不需要他们主动打开网站，内容直接推到他们手里。

公众号分两种：

• 订阅号：每天可以发一次，显示在用户订阅号文件夹里。适合内容型产品、媒体号、个人品牌。个人也可以申请。
• 服务号：每月只能发4次群发，但每次都会直接出现在用户的微信对话列表里，像收到消息一样。适合企业产品、有实际服务需求的用户。只有企业才能申请。

如果你刚开始，先用订阅号——个人就能申请，门槛低，每天可以发内容，积累粉丝更快。等公司注册好了，再考虑升级或另开服务号。

公众号的自动回复——24小时不睡觉的客服。

公众号有个很实用的功能：自动回复。设置好之后：

• 用户关注时，自动发一条欢迎消息（介绍你是谁、能帮他做什么、怎么获取帮助）
• 用户发某个关键词时，自动回复对应内容（比如发"价格"就回复定价方案，发"试用"就回复注册链接）
• 用户发任意消息时，自动回复通用回复（"感谢您的消息，我们会尽快回复您"）

自动回复的欢迎消息是你给新粉丝的第一印象，要用心写。

公众号涨粉策略。

公众号最难的事就是从0涨粉。没有粉丝，内容再好也没人看。几个切实有效的方法：

• 产品内引导：在你的应用里，完成注册/核心操作后，展示一个"关注公众号，获取使用技巧/独家福利"的弹窗或页面。这是效率最高的方式
• 在知乎/小红书上写干货：文章末尾写"更多内容关注公众号XXX"
• 互推：找和你目标用户相似但不竞争的产品，互相在对方公众号推荐
• 线下活动二维码：如果参加展会或活动，印上公众号二维码
• 朋友圈引流：发一条有价值的朋友圈，带上公众号名称

模板消息——精准的系统通知。

服务号有一个强大功能：模板消息。当你的应用里发生特定事件时，可以通过公众号给用户发送结构化通知，直接出现在微信对话里。

比如：订单支付成功通知、账号到期提醒、新内容推送。用户体验远好于邮件，因为他们一直在刷微信。需要在微信公众平台申请模板消息权限，需要企业服务号。

邮件营销——面向企业用户和出海产品的必备工具。

邮件在to B（企业客户）场景里依然非常重要。企业用户更习惯用邮件沟通，而且邮件是你真正"拥有"的渠道——不受平台规则变动影响。

欢迎邮件序列——新用户来了，然后呢？

注册后的第一周是用户最活跃的窗口期。如果你什么都不做，他们就忘了你。用AI帮你写一套简单的欢迎邮件序列：

• 注册后立即发：欢迎，确认邮件，给一个立刻能上手的行动步骤
• 注册后第2天：分享一个使用技巧或成功案例，降低上手难度
• 注册后第4天：问他们有没有遇到问题，主动提供帮助
• 注册后第7天：分享进阶功能或告知付费升级的好处

邮件要短，要聚焦一件事，要有一个清晰的行动按钮。不要在一封邮件里塞五件事。

一个实用建议：在你的注册流程里，同时收集用户邮箱和引导关注公众号。两个渠道都要，不要只依赖一个。邮件是保险，公众号是主力。

第23章：社交媒体与内容创作

内容营销的核心逻辑是：在用户存在的地方，持续提供有价值的内容，让他们自然而然地了解你、信任你、最终使用你的产品。

但在中国，"社交媒体"和英文互联网世界完全不同。你需要重新选平台。

中国主要内容平台一览。

每个平台的用户画像和内容风格都不同。你不需要同时经营六个平台——先选一两个最适合你产品的，做好，再扩展。

• 微信公众号：主阵地。长文章、干货教程、产品更新公告。粉丝粘性最高，是你沉淀内容的地方。
• 微博：适合传播。短内容、话题讨论、热点借势。曝光效率高，但粉丝粘性不如公众号。适合发"能被转发的内容"。
• 小红书：适合生活方式类、工具类产品。图文笔记风格，种草属性强。如果你的产品能让生活/工作更好，小红书用户会主动分享。
• 知乎：适合建立专业权威。长篇问答、深度分析。如果你的用户是专业人士或决策者，知乎排名靠前的回答能带来持续的精准流量。
• 抖音：短视频。流量大，但需要持续高频输出。适合有故事感、能视觉化呈现的产品。
• B站：适合有深度的内容，尤其是技术类、教程类、创作者向的产品。用户年龄偏年轻，接受度高。

用AI写内容——不是偷懒，是提效。

很多人担心用AI写内容显得不真实。但现实是：AI的作用是帮你把脑子里的想法变成文字，而不是替代你的想法本身。你提供方向和角度，AI帮你快速打出草稿，你再打磨成自己的风格。

最有效的工作方式：

1. 想好一个对用户有价值的主题（这个AI替代不了你）
2. 给AI一个简单的提纲或几个关键点
3. 让AI写初稿
4. 你修改：加入自己的真实经历、改掉听起来像机器人的句子、确保表达是你的声音
5. 发布

用AI生成图片。

内容配图很重要，好看的图能让文章点击率提升一倍。国内有几个不错的AI图像生成工具：

• 通义万相（阿里云出品）：中文提示词支持好，对中国用户友好，有免费额度
• 文心一格（百度出品）：中文提示词效果不错，支持多种风格
• Midjourney / DALL-E：质量很高，但需要VPN和境外支付，适合出海产品

对于产品截图和功能展示图，直接截图加标注效果最好。AI生图适合封面图、配套插图、抽象概念的可视化。

内容复用流——一份内容，发五个地方。

每次创作都从投入产出比最高的格式开始，然后拆解复用。这是顶级内容创作者的工作方式：

用这个流程，你每写一篇文章，实际上发布了至少8条内容。AI帮你完成格式转换，你负责把控质量。

内容日历——保持节奏感。

没有节奏的内容等于没有内容。用户关注你，期待你定期出现。如果你消失两个月再突然发10条，效果远不如每周稳定发2条。

用AI帮你规划一个月的内容日历。你只需要告诉它：产品类型、目标用户、每周想发几次。它会帮你生成一个包含主题、平台、内容格式的排期表，你只需要照着做就行。

国内工具微博通和新榜可以帮你管理多平台内容发布和查看各平台数据。如果你的内容以公众号为主，微信公众平台后台自带的数据分析已经够用了。

第24章：用AI做客户服务

产品上线后，用户会有问题。"怎么退款？""我的数据在哪里？""这个功能怎么用？"

如果你一个人全靠手动回复，每天一大半时间会花在这上面。好消息是：大多数用户问题都是重复的。80%的用户问题，答案只有那么几个。AI可以帮你处理这些。

第一步：建立知识库。

知识库就是你把所有常见问题和答案整理成的一份文件。它是你客服体系的基础——无论是给AI用，还是给自己查，还是直接变成网站上的帮助中心，都从这里开始。

用AI帮你从零构建知识库：

在线客服工具。

国内最常用的在线客服工具：

• 企微客服：腾讯出品，直接接入企业微信生态。用户可以通过企业微信联系你，对已有企业微信账号的用户来说体验最好。
• 美洽：国内做得比较好的独立客服平台，支持网页端、App、微信公众号多渠道接入，有AI机器人功能。
• 智齿客服：功能较全，支持AI接待+人工接待无缝切换，适合有一定规模的团队。
• 微信小程序客服：如果你的产品是小程序，可以直接使用小程序内置的客服功能，用户在小程序内就能联系到你，无需跳转。

刚起步时，不需要上复杂的客服系统。一个公众号自动回复 + 一个微信客服号就够了。等用户量增长，再换专业工具。

AI客服机器人——7x24小时在线。

美洽和智齿都有内置的AI机器人功能，你把知识库上传进去，它就能自动回答用户的常见问题。遇到机器人回答不了的，再转给人工。

如果你想自己搭一个简单版本，用大模型API（通义千问、文心一言、或者Claude/GPT）加上你的知识库，做一个简单的问答机器人，成本很低。

邮件模板——快速回复常见问题。

有些问题还是需要人工处理：退款投诉、账号被封、企业采购咨询。用AI预先准备好常见场景的邮件模板，回复时直接套用，速度快三倍。

好的客服不只是解决问题，它是留住用户的机会。一个用户遇到问题，你快速、有温度地解决了，他往往比从未遇到问题的用户更忠诚。

第25章：运营与自动化

产品能赚钱之后，你会发现有大量的重复性工作：发票要开，报表要做，数据要整理，用户要提醒，系统之间的数据要同步……

这些事情合在一起，可以轻松吃掉你三分之一的时间。而其中大部分是可以自动化的。

发票与报销——中国特色的重要环节。

在中国，企业用户向你购买后几乎一定会索取发票（发票）。这不是选项，是必须的。没有发票，企业客户无法报销，他们可能直接选择竞争对手。

发票系统对个人开发者来说是个门槛：你需要工商注册，需要税务登记，才能正规开票。如果你还没注册公司，有几个过渡方案：

• 通过代账公司注册个体工商户，申请税控系统，可以开普通发票
• 和已注册公司的合伙人合作，由他的公司收款开票
• 使用第三方代开票平台（如慧算账等），小额度可以用

等规模上来了，直接注册公司，接入阿里发票平台或者百望云等电子发票服务，可以实现用户购买后自动开具电子发票，完全免人工。

用AI做数据整理。

每个月你可能需要整理用户数据、统计收入、清洗导出的Excel表格。这些工作费时费力又容易出错。把这类工作交给AI：

自动化工具——让系统自己干活。

自动化工具能把不同的应用连接起来，实现"当A发生时，自动做B"。你不需要写代码（或者只需要写一点点）。

主流工具对比：

• 集简云：国内最好用的无代码自动化平台，支持连接微信、钉钉、飞书、腾讯文档、企业微信、以及大量国内常用SaaS工具。访问速度快，中文支持好。
• 腾讯轻联：腾讯出品，深度整合腾讯生态（企业微信、腾讯文档、腾讯会议等），如果你主要在腾讯系里工作，选这个。
• Zapier：国际最知名的自动化平台，连接了6000+应用，包括大量国际工具。境内访问有时不稳定，但如果你的工具链以国际产品为主，它功能最强。
• Make.com（原Integromat）：比Zapier功能更强大，可以做复杂的多步骤流程，有视觉化的流程编辑器。学习曲线稍陡。

一些可以立刻自动化的典型场景（对应用¥成本）：

• 用户注册 → 自动加入企业微信群 → 发送欢迎消息
• 支付成功 → 自动给用户发短信/公众号消息通知
• 每天早上 → 自动从数据库拉数据 → 生成日报发到群里
• 收到用户反馈表单 → 自动创建待处理工单 → 通知对应负责人
• 每月1号 → 自动生成月度收入统计 → 发到你的邮箱

定期报告——用AI生成，不用自己做。

每周或每月，你需要了解产品的健康状况。不要手动做这些报告。用AI写一个脚本，定时运行，自动生成报告发给你。

一旦把这些重复性工作自动化，你会发现自己多了很多时间思考真正重要的事：产品方向、用户增长、下一个功能。这才是创始人应该花时间的地方。

第26章：数据分析与监控

你无法改进你不了解的东西。数据告诉你：用户在哪里流失、哪个功能没人用、哪个页面让人望而却步。没有数据，你只是在瞎猜。

选择你的分析工具。

在中国，Google Analytics的数据收集在大陆访问有时不稳定，而且数据存在境外，合规上有风险。国内有更好的选择：

推荐组合：百度统计（流量分析）+ 神策数据（用户行为分析）。如果你的产品有小程序，加上腾讯移动分析。Plausible和PostHog质量很好，如果你有技术能力自建服务器部署，在国内同样可以使用。

你真正需要关注的指标。

数据工具能给你几十个指标，但大多数是噪音。专注在这几个：

• DAU/MAU（日活/月活用户数）：你的产品是否有人在用，有没有在增长
• 注册转化率：访问落地页的用户里，有百分之几完成了注册
• 激活率：注册后完成核心操作的用户比例（比如发出第一条消息、上传第一个文件）
• 留存率：注册7天后、30天后还在用的用户占多少
• 付费转化率：免费用户里有多少升级为付费用户
• MRR（月经常性收入）：每月稳定的订阅收入，是SaaS最重要的健康指标

留存率是最能说明产品质量的指标。如果用户注册后很快就不再来，说明产品还没解决真实问题，再多的推广也是往漏桶里倒水。

故障监控——出问题要第一时间知道。

你的服务器不会永远100%在线。数据库会临时崩溃，云服务会有故障，代码更新有时会引入新bug。关键是：你要比用户先知道。

正确的方式是：设置自动监控，服务器出问题立刻收到警报。不要等用户来投诉，那时候已经晚了。

• UptimeRobot：免费，每5分钟检测一次你的网站是否在线，宕机时发邮件和短信给你。是最简单的起步方案，国内可以正常使用。
• 阿里云监控：如果你的服务器在阿里云，直接用它的云监控服务，能监控服务器CPU、内存、磁盘、网络，以及自定义的业务指标。深度集成，数据完整。
• Sentry：专注于代码错误追踪，当用户触发了一个未捕获的异常，Sentry会记录完整的错误信息（哪行代码、用户做了什么操作触发的）并立即通知你。是发现bug的利器。

性能监控——慢比宕机更常见。

网站彻底挂掉是少见的，但页面加载慢是每天都可能发生的。研究表明，页面加载时间超过3秒，超过50%的移动端用户会离开。

监控性能的几个关键指标：

• 页面加载时间：理想值3秒以内（移动端）
• 首字节时间（TTFB）：服务器响应时间，超过500ms要优化
• 数据库查询时间：单个查询超过100ms要检查是否缺少索引
• API响应时间：P95响应时间（95%的请求在这个时间内完成）

百度统计和阿里云监控都可以看到页面性能数据。如果发现某个页面特别慢，先查数据库查询，大多数性能问题出在没有索引的数据库查询上。

你的每日数据仪表盘。

每天早上花5分钟看一下这些数据，就能对产品健康状况了然于心：

数据分析不是为了看数字而看数字。每次看完数据，问自己一个问题："基于这个数据，我这周要做一件什么事？"然后去做那一件事。这才是数据驱动决策的真正意义。

你已经完成了从产品构建到上线运营的全部知识储备。现在最重要的事只有一件：去做，去发布，去获取真实用户的反馈。完美的产品不存在，但你手里已经有足够的工具和知识，能够构建真正有价值的东西了。

第27章：用AI做市场调研

在你写下第一行代码之前，先弄清楚一个问题：这个东西真的有人需要吗？

大多数产品失败不是因为技术问题，而是因为根本没有人想要。创业者用六个月把产品做得完美，上线之后——沉默。原因只有一个：从来没有真正验证过需求。

好消息是：AI 可以帮你完成大部分初步调研，省掉很多低效的摸索。

第一步：用AI做竞品分析。

市场上已经有什么了？竞品怎么收费？用户怎么评价它们？它们的短板在哪里？

不要直接去问 AI"有没有做 X 的应用"——这样太泛了。换一个角度：把你的想法描述给 AI，让它帮你找出直接竞品、间接竞品和替代品，然后一起分析每个竞品的定价模型、目标用户和公开的用户评论。

第二步：TAM/SAM/SOM — 用外卖的例子理解市场规模。

投资人常问三个数字。用外卖市场来理解它们：

• TAM（全球市场规模） — 全国所有餐厅的所有外卖订单总额。这是最大的数字，往往达到万亿级别。
• SAM（可服务市场规模） — 你能触达的城市和用户群的外卖市场。比如你只在二线城市做，只服务25-40岁上班族。
• SOM（可获取市场份额） — 你实际上在第一年能拿到的份额。哪怕是这个细分市场的1%，也是真实可执行的目标。

TAM 告诉投资人天花板有多高；SAM 告诉他们你的目标战场；SOM 告诉他们你第一步要干什么。三个数字加在一起，构成一个完整的市场叙事。

第三步：去中文社区找真实的用户声音。

不要在 Reddit 上找用户调研，中国用户不在那里。去这些地方：

• 知乎 — 搜索相关问题，看高赞回答和评论区。用户在这里描述真实痛点，比任何焦点小组都真实。
• V2EX — 程序员聚集地。在"产品"和"创业"节点发帖，直接问开发者社群。
• 即刻 — 搜索产品关键词，看用户的日常动态和吐槽。
• 小红书 — 如果你的产品面向消费者，这里是宝库。用户会分享产品体验，包括槽点。
• App Store / 应用商店评论 — 竞品的一星和两星评论，就是用户对你亲口说出的"这就是我需要的东西"。

第四步：做5次用户访谈。

在你正式动手之前，和5个目标用户聊聊天。不是推销，而是倾听。你要问的不是"你会用这个产品吗"（他们会为了礼貌说"会"），而是问他们现在怎么解决这个问题。现在用什么工具？哪里最让他们头疼？为这件事花过多少钱和时间？

找到5个真实在用竞品或手动解决类似问题的人，请他们喝杯咖啡，或者约一个30分钟的视频通话。哪怕是微信上的一段语音聊天也算数。

五次访谈之后，你会有两种感受：要么"每个人都提到了同样的痛点，这个需求是真实的"；要么"他们说的和我想的完全不一样，我需要调整方向"。两种结果都好。在画第一个原型之前拿到这个答案，比在产品上线半年后才意识到，便宜太多了。

第28章：找联合创始人

一个人做产品完全可以。很多成功的独立开发者都是单枪匹马。

但如果你想要更快成长、更大规模，或者干脆需要互补技能，那就需要找到联合创始人。

你需要什么样的联合创始人？

最简单的答案：你需要的不是和你一样的人，而是和你互补的人。

如果你擅长写代码（技术），你需要一个懂市场、擅长谈客户的人（商业/销售）。如果你有产品和商业感觉，你需要一个能把代码写得稳健可靠的人（技术）。

现实中最常见的组合是：一个 CTO（技术），一个 CEO（商业和产品方向）。这两个角色加在一起，几乎可以处理早期创业公司遇到的所有事情。

要注意的是：你们要在价值观层面对齐，不只是技能互补。你们对公司发展节奏的期待一致吗？对花钱节奏的看法一样吗？如果融资了，对上市或者被收购的态度是什么？这些问题越早聊清楚越好。

去哪里找联合创始人？

• 即刻 — 发一条"寻找联合创始人"的动态，说清楚你在做什么、你需要什么技能。即刻的氛围对这类帖子很友好，认真创业的人聚集在这里。
• V2EX — 在"创业"节点发帖。程序员多，找技术联合创始人效果好。
• 独立开发者社区 — 国内有很多微信群，搜"独立开发者"或"独立开发者出海"可以找到入口。
• 黑客松 — 参加主题相关的黑客松。在48小时的高压环境里和别人并肩工作，是了解一个人靠不靠谱最有效的方式。在几次活动里认识的人，抵得上一百份简历。
• 你的前同事 — 认识的人比陌生人可靠。你已经知道他们的工作方式、性格和能力。

期权归属与悬崖期 — 保护自己和对方。

假设你和一个联合创始人各持50%股权。如果他六个月后不干了，你凭什么让他留着一半公司？他没有做任何贡献，你却还要帮他分账。这就是期权归属（Vesting）机制要解决的问题。

典型做法是：股权在四年内逐步归属，前12个月是"悬崖期"（Cliff）。

• 头12个月（悬崖期）：如果联合创始人在一年内离开，不得到任何股权。
• 满12个月之后：25%的股权一次性归属（等于第一年的那部分一起发放）。
• 接下来的36个月：剩余75%股权按月均匀归属。

听起来复杂，但这是保护双方的标准安排。它确保了两件事：只有长期投入的人才能拿到完整股权；也给了双方"试用期"——如果在第一年发现合作不顺，分手成本最小。

联合创始人协议。

聊清楚之后，把一切落到纸面。一份联合创始人协议需要覆盖：股权比例、归属时间表、各自的职责分工、离职条款（如果一方离开，他/她的股权怎么处理）、知识产权归属（你做的所有代码都属于公司，不属于个人）。

国内可以找专业的商业律师事务所起草这份文件，费用通常在3000到10000元之间，看复杂程度和律所规模而定。在公司还小的时候花这笔钱，是最值的投资之一。很多联合创始人在友好分手或遇到纠纷时才后悔没有白纸黑字写清楚。

第29章：向投资人融资

融资不是创业的必选项。很多优秀的公司从来不融资，靠产品收入自我滚动。

但如果你需要加速增长、扩充团队，或者进入一个需要大量前期投入的市场，融资可以是工具箱里的一个选项。

融资阶段：钱从哪里来。

国内创业融资通常经历以下几个阶段：

• 自力更生（Bootstrapping） — 用自己的钱，或者产品收入，维持运营。风险最小，保持100%控制权。适合大多数早期独立开发者。
• 天使轮 — 通常金额在 ¥50万到¥200万之间。钱来自个人天使投资人，通常是成功创业者或行业人士。换取5%-15%股权。这个阶段你还在验证想法。
• 种子轮 — 金额在 ¥200万到¥1000万之间。通常来自早期VC基金或专业种子基金。产品已经有了一定用户数据，开始跑通增长路径。
• A 轮 — 金额在 ¥1000万到¥1亿之间。来自主流VC机构。这时你的产品已经验证了商业模式，需要资金大规模扩张。

国内主要的投资机构：

• 真格基金 — 专注天使和早期种子阶段，对创始人友好，决策快。
• 险峰长青 — 早期项目，尤其关注技术类创业，有大量被投企业的成功案例。
• 创新工场 — 李开复创办，关注AI、消费技术，提供较完善的孵化支持。
• 红杉中国 — 头部机构，从种子到成长期全阶段投资，品牌背书强。
• 高瓴创投 — 专注早期，偏好技术驱动型项目。
• IDG资本 — 国内最老牌的外资VC之一，各阶段均有投资。

商业计划书（BP）— 你的融资敲门砖。

在中国，融资时给投资人看的材料叫做 BP（Business Plan），通常是一份10-15页的 PPT 或 PDF。它不需要做得多么炫丽，但必须把以下问题说清楚。

标准的10页 BP 结构：

1. 封面 — 公司名称、一句话描述、联系方式。
2. 问题 — 你要解决什么问题？这个问题有多痛？有多少人有这个问题？
3. 解决方案 — 你的产品是什么？它如何解决这个问题？
4. 市场规模 — TAM / SAM / SOM，配上数据来源。
5. 产品演示 — 截图或演示视频，让投资人看到真实的产品。
6. 商业模式 — 怎么赚钱？每个用户贡献多少收入？
7. 数据与进展 — 用户数、营收、增长率。真实数字，哪怕现在很小。
8. 竞品分析 — 市场上有谁？你的差异化是什么？
9. 团队 — 创始人背景，为什么你们是做这件事最合适的人？
10. 融资计划 — 这轮融多少？估值多少？钱打算怎么花？

找到投资人的渠道：

• 创始人介绍 — 最有效的路径。让你认识的其他创始人把你介绍给他们的投资人。
• 即刻 — 很多投资人在即刻上很活跃。真诚地关注他们，参与讨论，当时机合适再发出合作的信号。
• 各类创业大赛和路演 — 36氪、创业邦举办的路演活动，是和投资人面对面的机会。
• 孵化器 — 部分孵化器（如创业工坊、各省市政府孵化器）提供直接与投资人对接的机会，且有政策补贴。

投资人每天看大量 BP，他们的注意力很宝贵。用一句话说清楚你在做什么，用数字证明你是认真的，其余的留给他们问。

第30章：资金管理与预算规划

钱不够用的时候，一切都会加速崩溃。不管你有多好的产品，银行账户归零就是 Game Over。

理解你的数字，不是会计的事，是生存的事。

你的主要成本项：

作为一个早期的独立开发者或小型创业公司，你的成本大致分这几类：

• 云服务器 — 阿里云 ECS 的入门款每月大约 ¥50 到 ¥500，根据配置浮动。轻量应用服务器更便宜，适合早期产品。腾讯云、华为云价格类似，定期有新人优惠活动。
• 数据库 — 阿里云 RDS 基础版约 ¥100-¥300/月。腾讯云 PostgreSQL 类似。
• 域名和备案 — 域名每年 ¥50-¥150，ICP 备案免费但费时间。
• 短信服务 — 阿里云短信，每条约 ¥0.045。每月发一万条差不多 ¥450，按量计费。
• 邮件服务 — 阿里云邮件推送，每月前2万封免费，超出按量计费。
• 人员成本 — 只有你一个人的话，这是零。招了人之后，这通常是最大的支出项。

你的收入来源：

• 订阅制 — 按月或按年向用户收费，是最稳定的 SaaS 收入模式。
• 一次性购买 — 用户一次付费，终身使用。适合工具类产品。
• 按量计费 — 用多少付多少，适合 API 类产品或高频使用场景。
• 私有化部署 — 国内 ToB 市场非常特别的一个需求。很多企业客户，尤其是金融、政府背景的，要求把软件部署在自己的服务器上，不愿意把数据放在 SaaS 云上。私有化部署通常收取一次性高额授权费，加上年度维保费。利润率高，但销售周期长。
• 增值服务 — 基础功能免费，高级功能付费。降低获客门槛，再用价值转化付费用户。

中国用户的定价心理：

在中国市场定价，有几个需要注意的点：

• 用户对高月费更敏感，对年费接受度更高。把月费和年费都展示出来，用年费赠送月数来凸显性价比（如"年付12个月享16个月"）。
• ¥9.9、¥19.9 这类价格比 ¥10、¥20 更受欢迎，心理上的感知差距比实际差距大。
• 对于 ToB 产品，报价不要太低，否则客户会觉得你的产品不可靠。
• 教育、医疗、政府行业的客户通常有固定的采购周期和预算，报价要配合他们的财年节奏。

了解你的核心财务数字：

• 每月经常性收入（MRR） — 每个月可以稳定入账多少钱？这是 SaaS 公司最重要的北极星指标。
• 每月运营成本 — 运转这个产品，每个月要烧多少钱？
• Runway（可运行时间） — 如果收入突然停止，你的账户余额能撑多少个月？最少保持6个月的 Runway，最好是12个月。
• 获客成本（CAC） — 你花了多少钱才获得一个付费用户？
• 用户终身价值（LTV） — 一个用户在整个使用周期里平均贡献多少收入？LTV 要大于 CAC，这个生意才可持续。

第31章：法律基础

法律不是用来吓人的，而是用来保护你的。越早把这些事情做对，越省事。

注册主体：你需要什么类型的商业实体？

在国内，最常见的两种形式是：

• 个体工商户 — 最简单，注册快，到当地工商局或在"全国企业信用信息公示系统"线上办理即可。适合刚开始、收入规模不大的独立开发者。缺点是以个人名义承担法律责任，没有有限责任保护。
• 有限责任公司（有限公司） — 最常见的企业形式，对应的是英文里的 LLC 或 C-Corp。公司是独立法律主体，你的个人资产和公司债务是分开的（有限责任）。适合有融资计划或需要对外签合同的情况。注册需要提交公司章程、股东信息和注册地址，通常1-2周。

注册有限公司不需要通过中间人。去当地市场监督管理局（工商局）或通过各省市的网上政务平台就可以完成。注册完成后你会获得一个统一社会信用代码（18位数字和字母组合），这是你公司的"身份证号码"，对外签合同、开发票、申请服务都要用到。

ICP 备案 — 在中国大陆运营网站的必要条件。

如果你的服务器在中国大陆境内，或者面向中国大陆用户提供服务，你的域名必须完成 ICP 备案。没有备案的网站随时可能被关停。

备案流程：

1. 通过你的云服务商（阿里云/腾讯云等）提交 ICP 备案申请。
2. 准备材料：有限公司提供营业执照；个人提供身份证。
3. 云服务商提交给工信部审核。
4. 审核周期：约7-20个工作日，节假日更长。
5. 审核通过后，你会获得一个备案号（格式如"沪ICP备XXXXXXXX号"），需要展示在网站底部。

如果你的用户规模达到一定程度，还需要考虑公安联网备案（在网站上线后30天内完成）。

数据合规 — 中国版的"隐私法"。

你可能在国外资料里经常看到 GDPR（欧盟通用数据保护条例）。在中国，对应的是三部重要法律：

• 《个人信息保护法》（PIPL） — 于2021年正式施行，类似 GDPR，规定了收集、存储、使用用户个人信息的规则，要求获得用户明示同意。
• 《数据安全法》 — 规定数据分级分类保护，要求对重要数据进行安全评估。
• 《网络安全法》 — 要求网络运营者收集用户信息须明确目的，用户有权要求删除个人信息。

实际操作上，你需要准备：隐私政策（说明你收集哪些数据、如何使用）、用户注册时的知情同意勾选框、以及响应用户"删除我的数据"请求的机制。

财税基础 — 不要让税务成为你的盲区。

• 小规模纳税人 — 年收入不超过500万元，增值税税率更低（一般是3%，特定时期可能有优惠），报税简单，适合早期公司。
• 一般纳税人 — 年收入超过500万元或主动申请认定，增值税税率为13%（软件和服务行业），可以抵扣进项税，成本更高但可以开增值税专用发票（大客户通常要求这个）。

大多数早期创业公司会选择找代账公司处理日常的财税工作，每月费用在 ¥200 到 ¥500 之间（根据城市和业务复杂度）。不需要自己精通财税，找一个靠谱的代账公司，把精力放在产品上。

第32章：用AI制定营销策略

好产品不会自己长腿走到用户面前。营销是让用户知道你存在，让他们相信你能解决问题，让他们迈出第一步去试一试。

这章的核心观点只有一个：先把免费的有机增长跑通，再考虑付费渠道。

先做免费增长，再做付费投放。

付费广告就像用水泵抽水。水泵一开，水就来了；水泵一停，水就没了。有机增长像在地里挖了一口井——挖的过程费力，但一旦挖通，你就有了持续的水源。

在你没搞清楚"什么样的用户会留下来、什么样的信息打动他们"之前，烧钱做广告只会加速死亡。把免费的渠道跑通，验证你的核心信息，再把钱投进去放大信号。

中国主要广告和内容渠道对比：

有机增长的几种打法：

内容营销 — 在知乎写深度回答，在 V2EX 分享产品开发的踩坑记录，在 B 站出教程视频。不是推销，而是真正提供价值。读者变成信任你的用户，这是最高质量的转化。

社区运营 — 在即刻、微信群、Discord（出海产品）建立围绕产品的社区。核心用户不只是用户，更是你的品牌大使。给他们专属福利，听他们说话，他们会帮你拉新。

产品本身带增长 — 最好的营销，是产品本身带增长。分享功能（"用这个工具生成了一份XXX，点击查看"）、邀请机制（邀请好友得XX天会员）、免费套餐的自然传播——这些都是产品驱动的增长，每一个新用户都是免费的。

上线时的发布策略：

• 即刻 — 发一条发布动态，说清楚你做了什么、解决了什么问题。配上截图或视频。即刻的创业氛围对首发很友好。
• V2EX — 在"分享创造"节点发帖，程序员用户多，反馈质量高。
• 少数派 — 如果你的产品是效率工具或 Mac/iOS 应用，少数派的读者是绝佳目标用户。
• 微信私域 — 你的朋友圈、你所在的各个微信群，是第一批用户最快的来源。不要觉得难为情，先从身边的人开始。

第33章：一个真实应用的生命周期

产品上线只是开始。接下来发生的，才是真正的挑战——也是真正的乐趣所在。

Bug 报告 — 你的免费质检员。

第一批真实用户会发现你从未想到过的 Bug。这是好事，不是坏事。收到 Bug 报告，意味着有人在认真用你的产品。

建立一套简单的 Bug 追踪机制。哪怕就是一个飞书多维表格，记录：谁报告的、什么时间、Bug 描述、复现步骤、严重程度、是否已修复。

优先级排序：影响到支付流程或数据安全的，立刻修。影响到核心功能的，本周修。影响体验但有绕过方法的，下一个版本修。视觉类的小问题，积攒一批再统一处理。

功能需求 — 分清楚信号和噪音。

用户会提出各种功能需求。这是好事，说明他们在认真使用，在思考产品能帮他们做更多的事情。

但你不能把每个需求都做进去。这条路通向一个什么都有、什么都不突出的产品。

一个简单的判断框架：如果同一个功能被3个以上不同用户独立提出，这个需求是真实的。如果只有一个用户提，先问清楚他们的使用场景，背后的真实需求是什么，再决定是否做。

技术债务 — 该还的债终究要还。

早期快速迭代，代码难免有些将就。这是合理的取舍，快速上线验证需求，比把代码写得完美更重要。

但技术债务会积累。用 AI 快速写出来的代码，有时候维护起来很痛苦。当你发现"加一个小功能要改七个文件"，"每次部署都提心吊胆"，"代码库里到处都是 TODO 和写死的配置"——这是信号，是时候集中还债了。

建议每季度做一次技术债务审计。找出最让你头疼的三个地方，集中一两周重构它们。不要等到整个系统都快撑不住了才动手。

什么时候该招人了？

很多人太早招人，很多人太晚招人。以下是一些信号：

该招人的信号：你有固定的收入来支付薪资，有一项非常清晰的工作只需要一种技能，你一个人已经成为增长的瓶颈，而不是产品或市场的瓶颈。

还不该招人的信号：你自己还没搞清楚要做什么，产品还在大幅度转型，收入不稳定，你只是想找人分担焦虑。

国内找人的主要渠道：

• BOSS 直聘 — 最主流的招聘平台，创始人直接和候选人聊，效率高。技术岗和产品岗覆盖全面。
• 拉勾 — 互联网垂直招聘平台，候选人质量普遍较高，适合招技术和产品。
• 猎聘 — 偏向中高端职位，适合招有经验的关键岗位。
• 即刻 / V2EX — 发一条招募帖，在你的目标社区里，往往能找到价值观高度吻合的人。

团队工具：

当你开始有了团队，工作方式也要升级。国内大多数团队用飞书（字节跳动出品）作为核心协同工具——即时通讯、文档、多维表格、日历、视频会议全在一个产品里。它对小团队免费，功能完善，API 开放，适合从两三个人到几十个人的阶段。

最后的话。

构建一个产品需要很长时间，但你比以往任何时候都更有优势。AI 帮你写代码，AI 帮你做调研，AI 帮你起草文件，AI 帮你分析数据。你需要做的是保持清醒：谁是你的用户，他们有什么真实的问题，你提供的解决方案是否真的有用。

上线，然后倾听。你的用户会告诉你接下来做什么。

附录 A：产品完整清单

把这份清单存起来，每次上线新产品前过一遍。

构建

• 用户认证已实现（注册、登录、密码重置）
• 密码使用 bcrypt 或 argon2 哈希加密
• 所有密钥在环境变量中，未硬编码在代码里
• .env 文件已加入 .gitignore
• 所有 API 接口对用户输入做了验证
• 登录和注册接口设置了频率限制
• CORS 只允许自己的域名
• 错误处理完整（友好的用户提示 + 后端日志）
• Sentry 或同类错误追踪已集成
• 数据库使用 PostgreSQL（非 SQLite）
• 所有数据库操作使用 ORM，没有原始 SQL 拼接
• 敏感接口（支付、管理员）需要身份验证

上线

• ICP 备案已申请并获批（服务器在中国大陆的必须完成）
• 公安联网备案已提交（上线后30天内）
• 自定义域名已配置（非平台默认子域名）
• HTTPS / SSL 已启用
• 生产环境变量已在云平台控制台配置
• 数据库自动备份已开启
• CI/CD 流程已配置（代码推送后自动部署）
• 预发布环境已建立并验证通过
• 健康检查接口（/health 或 /api/health）已上线
• 至少有一个人（不是你）完整测试过核心流程

发布

• 落地页清晰说明了产品是什么、解决什么问题
• 有效的 CTA（行动号召）按钮，链接到注册或试用
• 隐私政策已发布并链接到网站底部（符合 PIPL 要求）
• 用户服务协议已发布
• 网站底部显示 ICP 备案号
• 发布计划已确定：即刻、V2EX、少数派发布帖已写好
• 前100个用户的获取渠道已想清楚
• 用户反馈收集机制已到位（邮箱、微信群、表单）

商业

• 公司主体已注册（个体工商户或有限责任公司）
• 统一社会信用代码已获取
• 微信支付商户账号已申请并通过审核
• 支付宝商户账号已申请并通过审核（可选）
• 银行对公账户已开立（有限公司）
• 代账公司已签约，负责日常财税
• 定价方案已确定（套餐、金额、年付折扣）
• 发票开具流程已理清（税务局开通电子发票）

运营

• 数据分析工具已集成（百度统计、友盟+ 或神策数据）
• 核心指标仪表盘已建立（DAU、MRR、转化率等）
• 客服渠道已建立（邮件、企业微信、微信群）
• 常见问题文档已准备好
• 运营报告模板已建立（每周/每月回顾）
• 用户数据定期备份（除数据库备份外的业务数据）

增长

• 用户注册后的邮件序列（或微信消息序列）已配置
• 产品内有分享功能或邀请机制
• 至少一个持续内容渠道（知乎、B站、即刻）已开始产出
• NPS 或用户满意度调查已部署
• 付费用户的流失分析机制已建立
• 下一个功能版本的路线图已有草稿

附录 B："告诉AI"提示词合集

以下是全书提示词的汇总，按类别整理，方便随时查找使用。

构建功能

平台发布

上线推广

商业与法律

运营管理

增长策略

附录 C：服务对比表

以下对比基于2025年公开资料，价格可能随时调整，使用前请核实最新报价。

认证服务

支付服务

邮件服务（事务性）

文件存储

数据库

托管服务

数据分析

附录 D：创业成本速查表

真实的成本数字，帮你在起步时做出合理预算。

零成本试水：¥0-50/月

验证想法阶段，尽量不花钱。

精益运营：¥600-1350/月

产品验证了，有了第一批付费用户，开始认真运营。

规模增长：¥2000-8000/月

用户规模上来了，需要更好的配置和团队工具。

省钱技巧

• 学生优惠 — 阿里云、腾讯云均有学生专项优惠，认证后服务器价格可低至 ¥9.5/月。在校学生用学号认证，物超所值。
• 云厂商新人试用额度 — 各大云厂商对新注册用户有免费试用套餐（通常3个月），可以用不同邮箱注册多个账号来延长试用期（合理使用，不违规）。
• 孵化器补贴 — 各省市政府孵化器、高校创业中心常提供云资源补贴，有些可以拿到数万元的云额度。入驻门槛通常不高，值得打听。
• 双11 / 618 活动 — 阿里云和腾讯云在双十一、618 期间对续费套餐有大力度折扣，通常可以折上折，提前囤一两年的服务费用能省下不少。
• 年付比月付便宜 — 大多数云服务年付比月付便宜20%-40%。如果你确定要用某个服务超过6个月，直接年付。
• 按量计费 vs. 包月 — 流量很小时按量计费更划算；流量稳定后切换到包月更便宜。定期检查实际用量，别为用不上的资源付钱。