一人公司最小可行系统：网站、产品、支付、数据和自动化缺一不可

检查 launch-checklist.md：/pricing 页面有了，Stripe Product 没建；登录能进，订阅状态没同步；GA4 有 page_view，支付按钮点击没事件；反馈表收到邮件，但没有任务流转。

很多独立开发者第一次上线时，以为“能跑起来”就够了。等用户付款后还在后台手动发邮件、免费额度超限才开始查账单，复盘、监控和边界的重要性才会显出来。

一人公司最小可行系统要解决的问题不在“最小”，而在“可行”。它不是把工具列表缩减到最少，而是确保上线前每个业务动作能完整跑通：用户能访问、产品能交付、支付能履约、状态能同步、数据能复盘、反馈能回流、成本有边界。

先用下面的清单定位断点，再决定哪些模块做最低版本、哪些可以延后。

最小系统验收表：上线前必须闭合的接口清单

最小可行系统的验收标准不是“功能都有了”，而是每个业务动作能否完整跑通。我见过不少独立开发者在上线前一晚还在补 Stripe webhook、Supabase RLS 和 GA4 事件，就是因为早期只关注“页面能显示”，没有提前设计支付、权益、数据和反馈的闭合。

以下是上线前必须验收的接口清单：

验收模块	必须闭合的接口	常见遗漏点	验收动作
网站入口	页面能访问、路由无 404、静态资源加载、构建次数有监控	构建次数超 Cloudflare Free 限额、错误日志没人看	用真实设备访问首页和定价页；检查 Cloudflare Pages 构建记录
产品形态	产品有明确形态（内容站/工具站/SaaS）、定价页有价格说明	只有产品介绍，没有价格或购买入口；Stripe Product 没建	在 Stripe Dashboard 检查 Products/Prices 是否创建；访问 /pricing 页面确认价格显示
支付流程完整	Checkout Session 能创建、webhook 能接收、支付成功后权益开通、失败/取消有处理、订阅状态能同步	webhook 没配置；支付成功但用户权益没开通；退款后订阅状态没更新	用 Stripe 测试卡完成一次支付流程；检查 webhook 日志和数据库订阅表
用户系统	登录能进、RLS 打开、订阅状态同步到用户表、免费用户和付费用户权限不同	只放登录按钮，没有 RLS；登录后所有用户都能看到付费内容	登录后检查 Supabase 数据库的 subscriptions 表；用免费账号验证 RLS 是否生效
数据事件	GA4/GSC 已配置、5–8 个业务事件有埋点、支付/注册/试用事件能追踪、错误和崩溃有报警	GA4 只有 page_view，没有支付按钮点击、注册完成等业务事件	在 GA4 DebugView 验证事件采集；在 GSC Performance report 检查查询和页面
反馈回流	反馈表能提交、反馈有任务流转、客服邮件有响应	反馈表只发邮件，没有任务看板或跟进流程	提交一条反馈，检查是否进入任务看板或邮件队列
自动化边界	Webhook/API/Cron 有用量警戒线、错误有报警、自动任务有回滚方案	自动化任务失败后没有告警；用量超限后才知道	检查 Cloudflare Workers 用量；设置用量警戒线和错误日志监控
成本监控	Cloudflare/Supabase 用量有记录、免费额度边界清楚、超限有预案	免费 Supabase 项目闲置后被暂停；Workers 请求超限后才发现	检查 Cloudflare 用量和 Supabase 项目活跃状态；记录升级触发条件

验收清单中的每一项都需要实际操作，而不是只在代码仓库里检查配置文件。上线前至少完成一次完整支付流程、一次登录和权限验证、一次数据事件追踪和一次反馈提交。

网站入口层：最小部署的技术栈和边界

网站入口是最小系统的第一层，可以先用静态站或轻量框架落地，但构建次数、文件数和动态函数都要进成本表。很多独立开发者选择 Cloudflare Pages 或 Astro 作为第一个内容站的入口，因为静态化部署维护压力低，但免费额度有边界，不能当成架构承诺。

技术栈选择表

产品形态	推荐技术栈	构建成本	动态函数成本	适用场景
内容站	Astro / Hugo / Hexo	Cloudflare Pages Free：500 builds/month、20,000 files、25 MiB asset	Pages Functions 计入 Workers	博客、文档站、SEO 内容页、产品介绍页
工具站	Astro + API 调用	同上	API 调用计入 Workers（100,000 requests/day）	单页工具、查询工具、计算工具、数据可视化
SaaS	Astro + Supabase	同上	Workers + Supabase Edge Functions	多用户、订阅、权限、数据库读写

截至 2026 年 7 月 26 日，Cloudflare Pages 官方限制仍是 Free 计划每月 500 次构建、单次构建 20 分钟超时、最多 20,000 个文件、单个资产最大 25 MiB。Pages Functions 的请求计入 Workers 配额；Workers Free包含每天 100,000 次请求和每次调用 10 ms CPU。

静态资源请求不等于整套系统没有成本。内容站依赖大量图片、视频或下载文件时，还要单独考虑对象存储、CDN、转换和出站流量。

不能只靠 AI 批量生成

Google Search 的生成式 AI 内容指南允许 AI 辅助研究和组织原创内容，但用生成式 AI 批量制造没有用户增量价值的页面，可能触发 scaled content abuse。网站入口需要真实产品、真实反馈和实际复盘，不能只靠自动铺出几百个 SEO 页面。

内容站的性能调优可以参考 Astro 5 性能优化实战，但最小系统不需要先追求 Lighthouse 100 分，只需保证页面能访问、资源能加载、CTA 能工作、构建失败有人看。

产品层：内容站、工具站还是 SaaS？第一个版本做什么

产品层决定了支付、用户、数据和自动化四层的复杂度。内容站、工具站、SaaS 是复杂度递进的三个层级，不是三个并列按钮。第一个版本应优先选择技术最熟、支付最简单、用户数据最少的形态。

产品形态判断表

产品形态	技术栈复杂度	支付复杂度	用户数据需求	第一个版本适用性
内容站	低：静态 + CMS + SEO	低：一次性付费或免费	低：邮箱订阅、RSS、评论	高：适合 SEO 导流、内容变现、测试市场需求
工具站	中：静态 + API + 轻量后端	中：一次性付费或订阅	中：轻量用户系统、使用记录	中：适合验证产品功能、单次收费或订阅
SaaS	高：认证 + 数据库 + 订阅 + RLS	高：订阅、用量计费、退款	高：多用户、权限、订阅状态、数据隔离	低：适合已有明确付费用户、技术栈成熟

判断标准

第一个版本先做哪一个，取决于三个因素：

1. 技术栈熟悉度：已经熟悉 Astro 或 Hugo，可以先做内容站快速验证；熟悉 Supabase 或 Postgres，工具站或 SaaS 才有更低的实现风险。
2. 支付复杂度：一次性付费通常比订阅简单，订阅又比用量计费简单。第一版可以先选一次性付费或免费留资，把复杂计费留到有真实需求后。
3. 用户数据需求：内容站可能只需邮箱订阅和 RSS；工具站需要使用记录；SaaS 需要身份、权限、订阅状态和数据隔离。

产品形态不是身份标签。只要一个核心动作还不稳定，就不该先做账号中心、团队空间和模板市场。

支付层：不是最后才接的按钮，而是会反向影响数据结构

支付层是最小系统中风险最高的一层。它会反向影响数据库、用户、权益、后台和邮件通知的设计。Stripe Checkout 能收钱之后，webhook 没配置权益开通、退款后状态没更新、订阅结束后仍有权限，都会变成真实履约问题。

支付流程步骤清单

Stripe 的最小支付闭合包含以下步骤：

步骤	Stripe 对象	必须闭合的接口	常见遗漏点
1. 创建产品	Products	在 Stripe Dashboard 创建产品；在定价页显示价格	/pricing 页面有价格，但 Stripe Product 没建
2. 创建价格	Prices	配置金额、币种、计费周期、计费模型（一次性/订阅/用量）	订阅价格没有设置 interval；用量计费没有设置 meter
3. 创建 Checkout Session	Checkout Session	配置 line_items、mode、success_url、cancel_url	success_url 只跳转页面，没有验证支付状态
4. 配置 webhook	Webhook endpoint	接收 checkout.session.completed、invoice.paid、customer.subscription.deleted 等事件	webhook 没配置；支付成功后没有开通权益
5. 履约	自定义逻辑	支付成功后在数据库开通权益、发送确认邮件	权益开通依赖手动操作，没有可追踪流程
6. 退款处理	Refunds	退款后更新订阅状态、收回权益、发送退款通知	退款后状态没同步，用户仍然能访问付费内容
7. 订阅状态同步	Subscriptions	订阅续费、取消或到期时更新状态	到期后没有检查状态，用户权益没有收回

支付模型决策表

支付模型会反向影响数据结构：

支付模型	数据结构影响	权益管理	适用场景
一次性付费	用户表加 paid_at 或 purchase_id 字段	一次开通，永久或限期访问	数字产品、课程、模板、工具单次购买
订阅	创建 subscriptions 表（user_id、stripe_subscription_id、status、current_period_end）	按周期开通和收回，需要状态同步	工具、SaaS、会员制内容
用量计费	创建 usage 表（user_id、meter、amount、timestamp）	按用量开通和限制，需要额度表	API 服务、云存储、计算资源

Stripe 的 Products/Prices 模型允许创建新 Price，再把 lookup key 转移到新 Price。应用通过 lookup key 查价时，可以避免把具体 Price ID 写死在多个位置，但价格变更仍需要按官方流程创建和激活新价格。

履约、退款和订阅状态同步需要 webhook 与数据库逻辑，不能依赖前端 success 页面或 Dashboard 手动操作。更深入的支付平台与数据表设计可继续阅读 一人公司支付系统选型。

测试卡验证流程

上线前必须在 Stripe 测试环境完成一次完整支付流程：

1. 在 Stripe Dashboard 使用测试环境
2. 使用 Stripe 当前文档提供的成功、失败和需要额外验证的测试方式
3. 在 Checkout 页面填写测试信息，完成支付
4. 检查 Payments 和 Events 日志，确认预期事件已触发
5. 检查数据库的 subscriptions 或权益记录，确认状态已同步
6. 登录后验证权益是否开通，再用无权益账号验证访问边界

测试环境验证完成后，再为正式环境单独核对密钥、webhook endpoint、事件签名和通知。

用户层：最小系统至少要区分身份、权限、订阅状态

用户层不是只放一个登录按钮。最小用户系统至少要区分身份、权限、订阅状态和数据访问边界。登录能进，但所有用户都能读到付费数据，通常是授权设计而不是登录组件的问题。

Supabase Auth 可以处理密码、magic link、OTP、社交登录和 SSO 等认证方式；JWT 与数据库 RLS 共同承担授权边界。认证回答“你是谁”，RLS policy 才决定“你能读写哪一行数据”。

最小用户系统清单

用户能力	Supabase 能力	最小系统必须闭合的接口	常见遗漏点
身份认证	密码、magic link、OTP、社交登录、SSO	用户能登录、能获取 JWT、能访问自己的数据	只放登录按钮，没有配置授权边界
权限管理	RLS（行级安全）	不同用户只能访问自己的数据；付费用户能访问付费内容	RLS 没打开或 policy 写得过宽
订阅状态同步	Stripe webhook → subscriptions 表	支付成功、续费、取消或到期时更新状态	状态只留在 Stripe，没有同步到应用
数据访问边界	RLS policy	用户只能访问自己的数据；管理员路径有独立权限	数据隔离没有验证，用户能看到其他用户数据

Supabase 项目以 Postgres 为数据基础，Auth、Storage、Realtime 和 Edge Functions 与项目能力协作。订阅状态同步应由可信后端处理，前端不能直接决定用户是否有付费权益。

上线前要用至少两个账号验证 RLS：一个有权益，一个无权益；同时检查浏览器端没有暴露 service role 或其他高权限密钥。

数据层：5–8 个业务事件，而不是一个统计脚本

数据层不是装一个 GA4 或统计脚本就结束。最小数据层只需要 5–8 个会改变决策的业务事件，但必须覆盖访问、点击、核心动作、注册、支付、错误和反馈。

业务事件清单

业务事件	GA4 事件名	何时触发	复盘用途
页面访问	page_view	页面加载	内容入口分析、SEO 流量来源
支付按钮点击	begin_checkout 或自定义事件	用户点击购买或订阅按钮	转化漏斗、定价页效果
注册完成	sign_up	用户完成注册	注册转化率、导流效果
试用开始	自定义事件 trial_start	用户开始试用或免费体验	试用转化率、体验改进
支付完成	purchase	后端确认支付成功后	收入分析、支付流程改进
错误和崩溃	自定义事件 error_occurred	前端报错、API 失败或核心动作异常	错误监控、稳定性改进
反馈提交	自定义事件 feedback_submit	用户提交反馈或问题	反馈率、问题分类

GA4 可以把对业务重要的动作标记为 key event。Realtime 和 DebugView 用来验证采集，但正式复盘还要确认事件参数、来源与去重逻辑。

数据复盘步骤

上线后每周至少复盘一次：

1. GA4：检查业务事件：在 DebugView 验证采集，在报表查看访问、注册、试用和支付的转化路径。
2. GSC：检查查询和页面：在 Performance report 查看点击、曝光、CTR、平均排名、查询和页面，不只看总访问量。
3. 产品分析：判断是否需要更细数据：当 GA4 聚合数据无法回答具体用户做了什么、做了几次、在哪一步流失，再引入 PostHog 等产品分析工具查看漏斗、留存和用户行为。

产品还没赚钱时，GSC、日志和错误报警仍有价值：它们能暴露入口查询、定价页卡点、核心动作失败和高频错误。等出现付费用户后再补采集，之前的失败原因通常已经无法还原。

自动化层：哪些第一天做，哪些会增加风险

自动化分为两类：第一天值得做的低风险重复动作，以及一旦出错就会放大损失的动作。AI 编程工具可以加速开发，但不能替代收款、权限、安全与数据复盘的验收。

Codex 等 coding agent 可以协助理解代码库、实现功能、审查、调试、测试和迁移。它们属于开发协作层，支付履约、权限边界、生产密钥、用量告警和用户反馈仍需要负责人验收。

自动化边界判断表

自动化任务	第一天值得做	增加风险	用量警戒线
部署自动化	Git push 后自动构建和部署	构建次数超限；构建失败没有通知	Pages 构建次数与超时
通知自动化	支付事件 → 权益记录 → 确认通知	webhook 失败没有重试；通知与权益状态不一致	Workers 请求、CPU 与重试量
备份自动化	主动导出关键数据；付费计划启用平台备份	免费计划默认没有自动备份；导出失败无人发现	数据库大小、存储和备份可恢复性
数据复盘自动化	GA4/GSC 数据定期导出；报表自动生成	频率过高；API 配额和数据延迟被忽略	GA4/GSC API quota
复杂编排	支付 → 权益 → 邮件 → CRM 的可观察流程	单点失败影响整条链；没有幂等和回滚	每步失败率、重试和死信
多系统依赖	Webhook、API、Cron、邮件、CRM 联动	系统延迟不同；失败后没有统一日志	动态请求、队列和外部 API 配额

Webhook/API/Cron 的警戒线

Webhook、轻 API 和 Cron 可以放在 Cloudflare Workers，但必须把当前平台边界写进成本表：

• Workers Free：100,000 requests/day、10 ms CPU/invocation。
• Workers Paid：每账户每月 5 美元起，Standard 包含 10M requests/month 和 30M CPU ms/month，超出后按量计费。

静态资源请求与动态 Worker 请求的计费方式不同。真正要监控的是请求量、CPU、重试、日志、KV、Queues、R2 等组合成本，而不是只盯一个“免费请求数”。

部署通知、支付确认、反馈入表和定期摘要适合先自动化；自动退款、删除生产数据、修改权限、群发消息和自动改价应保留人工确认，直到审计、幂等和回滚都能验收。

成本警戒线：免费额度不是架构承诺

免费额度是启动预算，不是架构承诺。Cloudflare 和 Supabase 的边界受动态请求、CPU、存储、egress、构建、日志和使用模式影响，不能承诺“永久免费”或“支撑 X 用户”。

成本/边界对照表

服务	Free 额度	付费起点/升级方向	易变风险	必须监控的边界
Cloudflare Pages	500 builds/month、20,000 files、25 MiB asset、构建 20 分钟超时	按 Cloudflare 账户计划升级 Pages 限制	配额和计划边界可能变化	构建次数、文件数、构建超时
Cloudflare Workers	100,000 requests/day、10 ms CPU/invocation；静态资产请求不计费用	Paid 每账户 $5/month 起，含 10M requests 和 30M CPU ms	价格、CPU、请求和关联产品配额会变化	请求次数、CPU、重试与用量告警
Supabase	50,000 MAU、500 MB database、1 GB storage、5 GB egress、2 个 Free projects，闲置一周后可能暂停	Pro $25/month，含 $10 compute credits	项目、计算、流量和安全功能边界会变化	MAU、数据库、存储、egress、项目活跃状态

上述数字已按 2026 年 7 月 26 日的 Cloudflare Pages 限制、Workers 定价与 Supabase 定价复核。上线时仍应重新查看官方页面，因为平台会调整配额和计费口径。

Supabase Free 项目闲置一周后可能暂停，而且 Free 计划不包含自动备份。核心业务不能只靠“项目还能打开”判断健康度；应检查项目活跃状态、数据导出、恢复方式和升级触发条件。

关于 Cloudflare 平台边界，可以继续阅读 Cloudflare 免费版限制清单和 Cloudflare 价格对比。

总结

一人公司最小可行系统不是把工具列表压到最短，而是让每个关键业务动作都有入口、结果和失败处理：用户能访问，产品能交付，支付能履约，权益能同步，数据能复盘，反馈能回流，故障能定位，成本有警戒线。

第一版不需要完美，但必须能验收。把 launch-checklist.md 放在代码仓库旁边，按真实用户路径完成支付、权限、事件、反馈和故障演练；后续再升级前端、后端、部署、数据库、支付与分析，不会因为少了一条基础接口而被迫返工整套系统。