ai web saas网站上线模块检查checking list sop
AI Web SaaS 上线检查清单深度版先说狠一点：网站能打开，不叫上线。
AI Web SaaS 上线检查清单深度版
先说狠一点：网站能打开，不叫上线。
能让陌生人注册、付费、使用 AI、遇到问题可恢复、出现风险可止损，这才叫上线。
AI SaaS 上线检查不是为了求完美，是为了挡住四种灾难：钱收不到、数据漏出去、模型乱执行、事故没人发现。
下面按 2026 年的 AI Web SaaS 实战标准来写，默认你的产品是：有官网、有登录、有订阅或积分、有 AI 调用、有用户数据、有后台管理、有上线收款目标。
TL;DR Cheatsheet
几个权威依据你先记住：Web 安全可以用 OWASP ASVS 当验收框架，ASVS 的目的就是给 Web 应用安全控制提供测试和验证标准。 AI SaaS 要额外防 prompt injection、敏感信息泄露、供应链、过度代理、向量/嵌入弱点、无限消耗等 LLM 风险，OWASP LLM Top 10 已经把这些列成 2025 版核心风险。 性能别拍脑袋，Google 的 Core Web Vitals 看的是真实用户体验，包括加载、交互和视觉稳定性。
一、真正的上线定义
很多独立开发者上线时只检查三件事：页面能不能打开、按钮能不能点、支付能不能跳转。
这很危险。AI SaaS 的上线，其实是六个系统一起上线：
第一，是销售系统。用户从广告、SEO、社媒、朋友推荐进来，能不能在 10 秒内理解价值。
第二，是身份系统。用户是谁、属于哪个 workspace、有什么权限、能看什么数据。
第三，是支付系统。用户付钱后，权益能不能正确开通；失败支付、退款、升级降级、重复 webhook 能不能处理。
第四，是 AI 系统。模型会不会胡说、泄露、越权、被 prompt injection、烧爆 token。
第五，是信任系统。隐私政策、服务条款、安全说明、退款规则、客服入口都要能让陌生人放心。
第六，是运营系统。出 bug 能不能发现，能不能回滚，能不能联系用户，能不能恢复数据。
所以我给你的上线标准是：
能收钱，能交付，能限制风险，能发现事故，能恢复服务，能持续迭代。
少一个，都不叫成熟上线。
二、上线红线：这些没过，别硬上
下面这些是 P0，一票否决。别想着先上再说。很多灾难不是因为技术复杂，而是因为创始人心急。
正式环境还在用测试数据库、测试 Stripe object、测试 webhook、测试 API key。Stripe 明确提醒，sandbox 里的产品、价格、优惠券、SKU 不能在 live mode 使用，生产 webhook 也要单独注册并验证能处理延迟、重复、乱序事件。
用户付款成功，但订阅权益不是通过可靠 webhook 开通，而是靠前端跳转页面判断。
没有 webhook 幂等处理。支付系统里，重复事件不是异常，是正常世界的一部分。
任何用户能通过改 URL、改 workspace_id、改 user_id 看到别人的数据。
管理员后台只靠前端隐藏入口，没有后端权限校验。
AI 工具调用能执行删除、发送邮件、扣款、改数据等动作，但没有二次确认或人类审核。
RAG 检索没有租户过滤，A 公司能检索到 B 公司的文档。
Prompt、用户上传文件、日志里有个人信息或商业机密，但没有数据保留策略和删除机制。
API key 写在前端代码、GitHub、浏览器请求、日志里。OpenAI 生产最佳实践也强调不要把 API key 暴露在代码或公开仓库，应使用环境变量或密钥管理服务。
没有限流、没有 token 上限、没有每日成本预算。OpenAI 的 rate limit 是按请求、token、图片等维度限制的，也存在组织和项目级别的限制；你自己的 SaaS 也必须有用户级、workspace 级、IP 级限流。
没有错误监控、没有 uptime 监控、没有支付失败告警、没有 AI 成本异常告警。
没有数据库备份，或者从没演练过恢复。
正式站还带 noindex，或者 robots.txt 把核心页面挡掉。Google 明确说 robots.txt 主要用于管理爬虫流量，不是隐藏敏感页面的安全手段；被 robots 阻止的 URL 仍可能因为外链出现在搜索结果里。
Privacy Policy、Terms、Refund Policy 没有上线，但已经收集邮箱、付款信息、用户输入内容、AI 生成内容。
用户出了问题找不到人。没有客服邮箱、工单、Discord、Intercom、Crisp、Telegram、状态页，至少要有一个。
记住一句话：上线不是冲锋，是带着降落伞跳下去。没有降落伞，不叫勇敢，叫莽。
三、模块 1：产品定位与转化检查
你的网站上线，第一关不是代码，是陌生人的脑子。
用户进入首页时只会问四个问题：
你是谁？
你帮我解决什么？
为什么我现在要用？
多少钱，值不值？
必查页面
首页、定价页、登录页、注册页、Dashboard 空状态页、AI 功能页、支付成功页、支付失败页、Terms、Privacy、Contact、FAQ、404、500、状态页。
首屏检查
首页首屏要做到：
用户 5 秒内知道产品类别。
用户 10 秒内知道主要收益。
用户 20 秒内知道下一步点哪里。
移动端首屏 CTA 不能被遮住。
页面不能堆满 AI、智能、自动化、效率提升这种空话。
差的文案是：
用 AI 提升你的工作效率。
好的文案是：
把 2 小时的竞品调研压缩到 3 分钟，自动生成带引用的报告。
更好的文案是：
给独立开发者的 AI 竞品情报员：输入一个产品 URL，3 分钟输出定价、流量来源、功能差距和可复制增长策略。
转化链路检查
从首页到付费，必须亲手走一遍：
首页 CTA → 注册 → 邮箱验证 → onboarding → 创建第一个项目 → 使用 AI → 看到结果 → 触发付费墙 → 选择套餐 → 支付 → 权益开通 → 收到发票或收据 → 回到产品继续使用。
每一步都要问：用户会不会卡？会不会怕？会不会不知道下一步？
独立开发者最容易犯的错，是把产品做成一个房子，但忘了给用户画门、点灯、放路标。
四、模块 2：生产环境、域名、DNS、HTTPS
这一层是地基。地基不稳，楼上装修得再漂亮都没用。
域名与 DNS
检查项：
[ ] apex 域名和 www 域名都能访问。
[ ] www 与非 www 有明确主域，并做 301 跳转。
[ ] app 子域、api 子域、docs 子域、status 子域命名清楚。
[ ] DNS TTL 在上线切换前调低。
[ ] DNSSEC 状态确认。Cloudflare 文档提醒，如果把现有域名迁到 Cloudflare，迁移前要确认注册商侧 DNSSEC 状态，否则 nameserver 切换时可能出现连通性错误。
[ ] CAA、MX、TXT、SPF、DKIM、DMARC 记录确认。
[ ] staging、preview、admin 子域不要被搜索引擎索引。
[ ] 管理后台最好单独子域加访问控制，不要只是 /admin 裸挂在主站。
HTTPS 与证书
检查项：
[ ] 全站强制 HTTPS。
[ ] HTTP 自动跳 HTTPS。
[ ] TLS 证书自动续期。
[ ] 证书过期告警。
[ ] HSTS 策略谨慎启用。Let’s Encrypt 提醒，HSTS 会让证书错误变成硬失败，浏览器不能轻易绕过，所以迁移和证书自动化没稳定之前别乱开超长 max-age。
[ ] 证书续期要自动化。Let’s Encrypt 对当前 90 天证书建议在剩余三分之一有效期时自动续期，也就是大约到期前 30 天。
环境分离
至少要有：
development
staging
production
每个环境必须分离：
数据库
对象存储 bucket
Stripe key
AI provider key
OAuth callback URL
邮件发送域名或 sender
webhook endpoint
日志与监控项目
feature flag
管理员账号
最要命的事故不是系统挂了，是你以为在 staging 测试，结果删了 production 数据。
五、模块 3：账号、权限、租户隔离
SaaS 的核心不是页面，是权限边界。
注册登录
检查项：
[ ] 邮箱注册成功。
[ ] 邮箱重复注册处理。
[ ] 邮箱验证。
[ ] 密码强度。
[ ] 忘记密码。
[ ] magic link 或 OAuth 登录。
[ ] Google OAuth callback 正式域名正确。
[ ] 登录失败提示不能泄露账号是否存在。
[ ] session 过期后跳转合理。
[ ] logout 后 token 失效。
[ ] 多设备登录策略明确。
[ ] 删除账号流程明确。
权限模型
最小可行权限模型：
Owner：付费、成员、账单、删除 workspace。
Admin：成员、项目、配置。
Member：使用产品。
Viewer：只读。
Support：仅在用户授权后查看必要信息。
System：后台任务和 webhook，不属于任何真人。
必须后端校验，不要相信前端。
租户隔离
这是 AI SaaS 的大雷区。
检查项：
[ ] 所有核心表都有 user_id 或 workspace_id。
[ ] 所有查询强制带 workspace_id。
[ ] 所有 API 在后端验证当前用户是否属于该 workspace。
[ ] 文件上传路径按 workspace 隔离。
[ ] RAG 向量库按 tenant 隔离，或者 metadata filter 绝对可靠。
[ ] AI 上下文拼接前过滤当前用户可访问数据。
[ ] 分享链接有权限、过期时间、撤销机制。
[ ] 管理员 impersonation 有审计日志。
[ ] 导出数据只能导出当前租户数据。
你的数据库不是仓库，是银行金库。每一行数据都要知道主人是谁。
六、模块 4：支付、订阅、发票、退款
收钱是上线最现实的验收。付费流错一次，用户信任就塌一半。
Stripe live checklist
检查项：
[ ] Stripe account business profile 完成。
[ ] 银行账户、币种、税务信息确认。Stripe 账户清单提醒，收 live charge 前要确认银行信息，错误银行信息是 payout 延迟的常见原因。
[ ] 产品、价格、coupon 在 live mode 重新创建。
[ ] 前端 price_id 与后端 price_id 不硬编码错。
[ ] test key 全部替换为 live key。
[ ] webhook endpoint 是 live endpoint。
[ ] webhook signature 校验。
[ ] webhook 幂等处理。
[ ] delayed webhook、duplicate webhook、out-of-order webhook 测试。Stripe go-live checklist 明确要求生产 webhook 能处理延迟通知、重复通知，并且不要依赖事件固定顺序。
[ ] 支付成功后权益通过 webhook 开通，而不是只靠 success URL。
[ ] 支付失败、取消支付、卡被拒绝、3DS 验证、订阅过期处理。
[ ] 升级、降级、取消、恢复订阅。
[ ] invoice、receipt、税号、公司信息。
[ ] 退款流程。
[ ] chargeback/dispute 证据准备。Stripe 账户清单也提醒要准备欺诈和争议处理、可疑支付报告、card testing 防护。
SaaS 权益模型
你必须清楚：
免费用户有什么？
试用几天？
试用是否要信用卡？
每月多少 AI credits？
超额怎么办？
订阅取消后数据保留多久？
退款后权益什么时候关闭？
支付失败后宽限期几天？
用户降级后超出额度的数据怎么处理？
支付成功页
不要只写 Payment success。
要写：
你购买了什么套餐。
现在可用额度是多少。
下一步做什么。
账单入口在哪里。
客服入口在哪里。
发票/收据已发送到哪个邮箱。
钱已经收了，就别让用户站在门口发呆。
七、模块 5：AI 功能上线专项检查
这是 AI SaaS 和普通 SaaS 最大的差别。
普通 SaaS 的 bug 通常是确定性的。
AI SaaS 的 bug 很多是概率性的、诱导性的、上下文相关的。
所以你不能只测 happy path。你要测恶意用户、笨用户、极端输入、错误文件、超长上下文、越权请求、成本攻击。
OpenAI 的 evals 文档也说，生成式 AI 有可变性，同样输入也可能产生不同输出，所以传统软件测试不够，evals 是测试 AI 系统准确性、性能、可靠性的关键方式。
1. Prompt injection
检查项：
[ ] 输入 ignore previous instructions 是否能绕过规则。
[ ] 上传文档里隐藏 prompt 是否能改变系统行为。
[ ] 网页抓取内容里的恶意指令是否会被当成开发者指令。
[ ] 用户输入是否被放进 developer/system message。OpenAI agent safety 文档特别提醒，不要把不可信变量直接放入 developer messages，因为这会给攻击者更高控制权。
[ ] RAG 文档是否明确标记为 untrusted content。
[ ] 工具调用是否必须经过结构化 schema。
[ ] 高风险工具调用是否需要二次确认。
[ ] AI 输出是否能把系统 prompt、密钥、内部规则泄露出来。
OWASP 对 prompt injection 的定义很直接：攻击者通过输入操纵模型行为，可能绕过安全措施；直接 prompt injection 是用户输入直接改变模型非预期行为。
2. 敏感信息泄露
检查项：
[ ] AI 不会输出其他用户数据。
[ ] AI 不会输出 API key、system prompt、数据库字段、内部错误堆栈。
[ ] 日志中 PII 有脱敏。
[ ] 用户输入是否会进入训练或供应商数据保留，必须在 Privacy Policy 里说明。
[ ] 用户可以请求删除数据。
[ ] 客服和管理员查看用户 prompt 有审计。
[ ] 错误消息不能把完整 prompt、SQL、provider response 直接打给用户。
OWASP LLM 风险把敏感信息泄露列为核心风险，并建议对数据做 sanitization，避免用户数据进入训练模型，同时用清晰 Terms 告知用户数据使用和选择权。
3. AI 输出安全
检查项：
[ ] 代码生成类产品：输出代码不能自动执行。
[ ] SQL 生成类产品：必须参数化、只读、sandbox、禁止 DROP/DELETE/UPDATE。
[ ] 浏览器自动化类产品：付款、发邮件、删除文件、提交表单前必须确认。
[ ] 医疗、法律、金融建议必须有边界提示和高风险拦截。
[ ] 不确定时要让 AI 表达不确定，而不是硬编。
[ ] 有用户举报 AI 输出问题的入口。OpenAI safety best practices 建议提供易找到的问题报告方式，并由人类监控和响应。
4. Human-in-the-loop
不是所有东西都适合全自动。
必须人工确认的动作：
扣款
退款
删除数据
发送外部邮件
发布公开内容
修改生产配置
访问高度敏感数据
影响第三方账户
法律、医疗、金融、招聘、信贷等高风险决策
OpenAI safety best practices 也建议，在高风险领域以及代码生成等场景中，尽可能让人类在输出实际使用前审核，并让审核者能访问原始资料验证输出。
5. AI 成本控制
AI SaaS 最大的隐形杀手是成本，不是 bug。
检查项：
[ ] 每个用户每日 token 上限。
[ ] 每个 workspace 月度 token 上限。
[ ] 免费用户严格限额。
[ ] 单次请求最大输入长度。
[ ] 单次请求最大输出 tokens。OpenAI safety best practices 也建议限制用户输入和输出 token，以降低滥用风险。
[ ] 文件上传大小限制。
[ ] RAG 检索 top_k 限制。
[ ] 失败重试次数限制。
[ ] provider 超时设置。
[ ] 队列限速。
[ ] 成本异常告警，比如 10 分钟成本超过平时 5 倍。
[ ] 降级模型 fallback。
[ ] 缓存策略：相同任务、相同输入、相同版本可缓存。
[ ] 后台任务可暂停。
[ ] 用户侧展示剩余额度，避免客服爆炸。
6. AI evals
上线前至少做四类 eval：
功能 eval：正常任务是否完成。
安全 eval：prompt injection、越权、敏感信息泄露。
质量 eval：准确率、格式合规、引用正确。
回归 eval：换模型、改 prompt、改 RAG 后是否变差。
每条 eval 要有：
输入样本
期望行为
禁止行为
评分规则
是否需要人工复核
模型版本
prompt 版本
RAG 数据版本
通过阈值
别用感觉判断 AI 产品。感觉是创业者最贵的幻觉。
八、模块 6：RAG、文件上传、向量数据库
只要你的产品支持上传 PDF、网页、Notion、Google Drive、Slack、网页抓取、知识库，就要单独检查。
文件上传
检查项：
[ ] 限制文件类型。
[ ] 限制文件大小。
[ ] 病毒扫描或基础安全扫描。
[ ] 文件名 sanitize。
[ ] 对象存储私有，不可公开枚举。
[ ] 预签名 URL 有过期时间。
[ ] 删除文件后同步删除向量、缓存、摘要。
[ ] 上传失败有重试和清理。
[ ] PDF、图片、表格解析失败时有用户提示。
[ ] 不把上传文件原文写入可公开日志。
RAG 检索
检查项：
[ ] 每条 chunk 有 workspace_id、document_id、owner_id、权限 metadata。
[ ] 检索前先鉴权。
[ ] 检索时强制 metadata filter。
[ ] chunk 中敏感字段脱敏或禁止索引。
[ ] 删除文档后向量同步删除。
[ ] 用户权限变更后，向量检索权限同步生效。
[ ] 检索结果只进入该用户请求上下文。
[ ] 引用来源可追踪。
[ ] 低置信度时不强答。
[ ] 外部网页内容被标记为不可信输入，不能覆盖系统规则。
FBI 发布的 AI Data Security 指南强调，AI/ML 系统中的数据安全会影响 AI 输出的准确性和完整性，并且开发、测试、运行阶段都可能有数据完整性风险。 这对 RAG 特别关键，因为你的检索数据就是模型的临时记忆。
九、模块 7：Web 安全
别幻想小产品没人打。只要能注册、能支付、能调用 AI，就有人薅、有人刷、有人撞库、有人找漏洞。
基础安全
检查项：
[ ] 所有 API 后端鉴权。
[ ] 所有写操作校验权限。
[ ] 输入校验。
[ ] 输出编码。
[ ] CSRF 防护。
[ ] XSS 防护。
[ ] SQL injection 防护。
[ ] SSRF 防护，尤其是网页抓取、URL import、AI tool browsing。
[ ] 文件上传安全。
[ ] 密码 hash。
[ ] session cookie httpOnly、secure、sameSite。
[ ] 管理员操作审计。
[ ] rate limiting。
[ ] bot 防护。
[ ] dependency scanning。
[ ] secret scanning。
[ ] 错误页面不暴露 stack trace。
[ ] 日志不存明文密码、token、信用卡、完整 PII。
OWASP ASVS 适合作为 Web 应用上线安全验收基线，因为它就是为了测试 Web 应用技术安全控制，并给开发者安全需求清单。
HTTP 安全头
检查项：
[ ] Content-Security-Policy。
[ ] Strict-Transport-Security。
[ ] X-Content-Type-Options。
[ ] Referrer-Policy。
[ ] Permissions-Policy。
[ ] frame-ancestors 或 X-Frame-Options。
[ ] Cross-Origin-Opener-Policy / Cross-Origin-Resource-Policy 按需。
[ ] 不暴露 Server、X-Powered-By。
MDN 说明 CSP 允许站点控制浏览器能加载哪些资源，主要可帮助防范跨站脚本攻击。 Mozilla HTTP Observatory 可以对站点 HTTP headers 和关键安全配置做自动扫描并给出改进建议。 OWASP Secure Headers Project 也把安全响应头作为减少浏览器层可预防漏洞的重要配置。
管理后台
检查项：
[ ] 后台单独鉴权。
[ ] 强密码或 SSO。
[ ] MFA。
[ ] IP allowlist，至少保护超级后台。
[ ] 所有管理员操作写 audit log。
[ ] 查看用户数据需要理由。
[ ] impersonate 用户必须可追踪。
[ ] 危险操作二次确认。
[ ] 删除、退款、改额度需要权限分级。
后台不是给你方便用的，是公司最高权限区。
十、模块 8：隐私、法律、合规
这里不装律师，但你不能裸奔收数据。
基础法律页面
上线前至少要有：
Privacy Policy
Terms of Service
Cookie Policy 或 Cookie Notice
Refund Policy
Acceptable Use Policy
Contact / Support
Data Processing Addendum，如果你做 B2B 且客户在意
Subprocessors list，如果你用了 OpenAI、Stripe、Supabase、Vercel、AWS、PostHog 等第三方
GDPR 检查
如果你面向欧盟用户，GDPR 要认真。欧盟官方说明，EU 数据保护规则也适用于欧盟外但向欧盟个人提供商品或服务的公司。处理个人数据要有合同、法律义务、合法利益、同意等合法基础；当依赖同意时，用户必须做出清晰同意动作，且要被告知处理者、用途、保留时长、接收方和数据权利等信息。
检查项：
[ ] 你收集哪些个人数据。
[ ] 为什么收集。
[ ] 保存多久。
[ ] 给哪些第三方。
[ ] 用户怎么访问、修改、删除、导出。
[ ] 用户怎么撤回营销同意。
[ ] 数据泄露时怎么通知。
[ ] 是否有 DPA。
[ ] 是否记录 consent。
[ ] cookie 是否分必要、分析、营销。
[ ] AI 输入是否含个人数据，是否传给模型供应商。
CCPA/CPRA 检查
如果你服务加州用户且规模达到门槛，要检查 CCPA/CPRA。加州官方说明，CCPA 适用于在加州经营且满足特定门槛的营利企业，例如年收入超过 2500 万美元、买卖或共享 10 万以上加州居民或家庭个人信息、或 50% 以上收入来自出售加州居民个人信息；CPRA 对 CCPA 做了修订，增加了更正不准确信息、限制敏感个人信息使用和披露等权利。
早期小产品可能没到门槛，但从第一天就按可删除、可导出、可说明数据来源来设计，后面不会返工到吐血。
AI Act 检查
如果你触达欧盟用户或客户，AI Act 要做风险分类。欧盟官方说明，AI Act 于 2024 年 8 月 1 日生效，2026 年 8 月 2 日全面适用，但有例外；禁止性 AI 实践和 AI literacy obligations 已从 2025 年 2 月 2 日适用，GPAI 模型治理和义务已从 2025 年 8 月 2 日适用，高风险系统中嵌入受监管产品的规则有到 2027 年 8 月 2 日的过渡期。
对独立开发者，最实用的动作是：
[ ] 明确你的 AI 功能属于低风险、有限风险还是可能高风险。
[ ] 不做被禁止的用途。
[ ] 不冒充人类，聊天机器人要让用户知道在和 AI 交互。
[ ] 高风险行业不要随便碰自动决策。
[ ] 记录模型、prompt、数据源、评估结果。
[ ] 有用户投诉和人工复核机制。
[ ] 营销不要夸大 AI 能力。
FTC 对 AI 相关商业宣传也有执法案例，曾指控在线商业机会方案用 AI 工具帮助消费者快速赚取收益等宣传涉嫌虚假，涉案金额至少 2500 万美元。 所以你的官网不要写 guaranteed results、自动赚钱、无风险、准确率 100%。这种话不是营销，是给监管递刀。
十一、模块 9：性能、Core Web Vitals、移动端
你的网站慢，用户不会骂你，他会直接关掉。
性能检查
Google PageSpeed Insights 说明 Core Web Vitals 包括 INP、LCP、CLS；如果有足够数据，会用三项指标的第 75 百分位是否为 Good 来判断是否通过。
检查项：
[ ] 首页 LCP 优化。
[ ] 图片压缩、尺寸、懒加载。
[ ] 首屏 JS 体积控制。
[ ] 字体加载不阻塞。
[ ] Dashboard 首屏 skeleton。
[ ] AI 输出 streaming，别让用户看空白。
[ ] API 超时提示。
[ ] 长任务进度条。
[ ] 移动端输入框、按钮、支付页可用。
[ ] 低网速下可用。
[ ] 404、500 页面轻量。
[ ] 第三方脚本按需加载，不要首页塞一堆 analytics、chat widget、heatmap、ads pixel。
AI 体验性能
AI 产品的速度不是单纯的 response time，而是 perceived progress。
检查项：
[ ] 请求发出后 300ms 内有反馈。
[ ] 超过 2 秒显示正在处理。
[ ] 超过 10 秒显示进度或阶段。
[ ] 长生成使用 streaming。
[ ] 后台任务可离开页面。
[ ] 失败可重试。
[ ] 不重复扣额度，除非明确说明。
[ ] provider 超时有 fallback。
[ ] 排队状态可见。
用户可以接受 AI 慢一点，但不能接受不知道它死没死。
十二、模块 10：SEO、索引、结构化内容
如果你靠自然流量，SEO 上线检查不是锦上添花，是分发系统上线。
Google SEO Starter Guide 说，SEO 是帮助搜索引擎理解你的内容，也帮助用户通过搜索找到你并决定是否访问；遵循 Search Essentials 更有可能出现在搜索结果中，但没有保证。
技术 SEO
检查项：
[ ] title 唯一且可读。
[ ] meta description 不重复。
[ ] h1 每页清楚。
[ ] canonical 正确。
[ ] sitemap.xml 存在。Google sitemap 文档说明，sitemap 是告诉搜索引擎你认为重要页面和文件的信息，提交 sitemap 是 hint，不保证 Google 一定下载或抓取，但可以通过 Search Console 提交并查看处理错误。
[ ] robots.txt 正式站允许核心页面。
[ ] noindex 从正式页面移除。Google noindex 文档强调，noindex 要生效，页面不能被 robots.txt 阻止，否则爬虫看不到 noindex。
[ ] 旧 URL 做 301。
[ ] 404 返回真正 404。
[ ] 500 不返回 200。
[ ] Open Graph / Twitter Card。
[ ] favicon、manifest、logo。
[ ] 多语言 hreflang，如果有。
[ ] pricing、features、blog、docs 可被抓取。
[ ] 登录后内容不要当作 SEO 主内容。
[ ] JavaScript 渲染页面要确认 Google 能看到核心内容。Google JavaScript SEO 文档专门说明了 Google Search 如何处理 JavaScript，以及 JavaScript Web App 的最佳实践。
内容页检查
AI SaaS 起步至少要有：
首页
功能页
定价页
用例页
对比页
模板页
博客或资源页
Docs
Changelog
FAQ
安全与隐私说明
Affiliate 或 Partner 页面，如果有增长计划
别做一个只有首页和登录按钮的网站。那叫名片，不叫增长机器。
十三、模块 11：可访问性
可访问性不是慈善，是产品基本功。W3C WCAG 2.2 覆盖了让 Web 内容更容易被残障用户访问的一系列建议，包括视觉、听觉、行动、认知等障碍，并且这些指南通常也会让普通用户更好用。
检查项：
[ ] 所有按钮可键盘访问。
[ ] focus 状态清楚。
[ ] 表单有 label。
[ ] 错误提示不仅靠颜色。
[ ] 颜色对比足够。
[ ] 图片有 alt。
[ ] loading 状态对屏幕阅读器友好。
[ ] modal 可关闭，focus trap 正确。
[ ] dropdown、tooltip、tabs 语义正确。
[ ] 支付流程键盘可完成。
[ ] AI 输出区域可复制、可读、结构清楚。
[ ] 移动端点击区域足够大。
[ ] 不用纯 placeholder 当 label。
[ ] 重要通知不只靠 toast，一闪就没。
别以为这离你很远。可访问性差，通常意味着产品细节差。
十四、模块 12：邮件、通知、deliverability
AI SaaS 离不开邮件：验证邮箱、重置密码、支付通知、用量提醒、任务完成通知、营销邮件。
邮件基础
检查项：
[ ] SPF 配置。
[ ] DKIM 配置。
[ ] DMARC 配置。Google 邮件发送指南说明，DMARC 会告诉接收服务器如何处理未通过 SPF 或 DKIM 的邮件；要通过 DMARC，邮件必须通过 SPF 或 DKIM，且认证域名要和 From header 域名一致。
[ ] 发送域名和主站域名策略明确。
[ ] transactional email 和 marketing email 分开。
[ ] unsubscribe 链接。
[ ] 邮件模板移动端可读。
[ ] 欢迎邮件不进垃圾箱。
[ ] 重置密码链接过期。
[ ] 邮件里不放敏感 token 明文。
[ ] 任务完成邮件不会泄露私密内容。
[ ] 邮件失败有重试和告警。
必备邮件
[ ] 注册欢迎。
[ ] 邮箱验证。
[ ] 重置密码。
[ ] 支付成功。
[ ] 付款失败。
[ ] 订阅即将续费。
[ ] 订阅取消。
[ ] 额度快用完。
[ ] AI 任务完成。
[ ] 数据导出完成。
[ ] 安全通知，比如新设备登录、密码修改。
邮件不是附属品。很多 SaaS 的留存，是邮件救回来的。
十五、模块 13：Analytics、事件、漏斗
没有数据，上线后你只是闭着眼睛开车。
必备事件
Google Analytics 4 ecommerce 文档说明，可以设置 ecommerce events 来收集用户购物行为，衡量热门产品、促销和产品展示对收入的影响；发送 value 时要设置 currency。
AI SaaS 至少要埋这些事件：
visitor_landed
cta_clicked
signup_started
signup_completed
email_verified
onboarding_started
onboarding_completed
project_created
ai_request_started
ai_request_completed
ai_request_failed
paywall_viewed
checkout_started
payment_completed
subscription_created
subscription_canceled
quota_exceeded
invite_member
export_data
support_clicked
refund_requested
漏斗
至少看五条漏斗：
访问 → 注册
注册 → 首次成功使用 AI
首次成功使用 AI → 付费墙
付费墙 → checkout
checkout → 支付成功
你要盯的不是访问量，是每一步漏了多少人。
产品增长不是祈祷，是修漏斗。
归因
检查项：
[ ] UTM 保存。
[ ] 首次来源和最近来源区分。
[ ] 支付事件能关联来源。
[ ] 广告 pixel 只在 consent 后按地区合规加载。
[ ] 内部人员流量过滤。
[ ] 支付成功和订阅创建不要重复计算收入。
[ ] refund、chargeback、cancel 要进入收入分析。
十六、模块 14：监控、告警、SLO、事故恢复
上线后最可怕的不是出问题，是你不知道出了问题。
Google SRE 工作簿强调，好的 SLO 应该衡量用户感知到的平台可靠性，并用它产生高质量告警；error budget 用来平衡可靠性和创新速度。
必备监控
[ ] uptime。
[ ] API p50/p95/p99 latency。
[ ] error rate。
[ ] 5xx。
[ ] database CPU/connection/storage。
[ ] queue length。
[ ] AI provider latency。
[ ] AI provider error。
[ ] token usage。
[ ] AI cost per user / per workspace。
[ ] Stripe webhook failure。
[ ] payment failed。
[ ] signup failed。
[ ] email delivery failed。
[ ] file upload failed。
[ ] RAG indexing failed。
[ ] background job failed。
[ ] suspicious traffic。
[ ] admin dangerous action。
建议 SLO
MVP 阶段不要装大厂，但要有底线：
官网 uptime：99.9%。
App API uptime：99.5% 起步。
核心 AI 请求成功率：≥ 97%。
支付 webhook 处理成功率：≥ 99.9%。
注册成功率：≥ 98%。
P0 事故发现时间：≤ 5 分钟。
P0 rollback 时间：≤ 15 分钟。
备份恢复演练：每月至少一次。
Google SRE 示例里，99.9% SLO 对应 0.1% error budget；如果四周 error budget 被耗尽，就冻结非 P0 或安全修复之外的发布，直到服务回到 SLO 内。 你不一定照抄，但要有这个思想：可靠性不是感觉，是预算。
告警分级
P0：支付不可用、登录不可用、数据泄露、跨租户访问、生产数据库不可写、AI 成本异常爆炸。
P1：核心 AI 功能失败率高、webhook 延迟、邮件失败、部分用户无法访问。
P2：页面性能下降、非核心功能异常、SEO 问题、单个第三方失败。
P3：UI 小 bug、文案错误、低频边缘问题。
事故 runbook
每个 P0 都要写：
谁负责判断。
谁负责技术处理。
谁负责用户沟通。
谁能回滚。
谁能关停 AI 调用。
谁能暂停支付。
谁能发状态页更新。
谁能查日志。
谁能联系第三方供应商。
事故发生时，大脑会变笨。runbook 是给变笨时的你准备的。
十七、模块 15：备份、恢复、数据生命周期
备份不是有一个 dump 文件就完事。
备份的价值，只在你能恢复时才存在。
检查项：
[ ] 数据库自动备份。
[ ] 备份加密。
[ ] 备份跨区域或至少异地。
[ ] 备份保留周期明确。
[ ] 恢复演练完成。
[ ] RPO 明确：最多能接受丢多少数据。
[ ] RTO 明确：最多多久恢复服务。
[ ] 对象存储备份。
[ ] 向量库可重建。
[ ] 用户上传文件可恢复。
[ ] 删除账号后，主库、对象存储、向量库、缓存、日志按策略处理。
[ ] 数据导出可用。
[ ] 数据删除请求有后台流程。
建议初期标准：
RPO：24 小时以内。
RTO：4 小时以内。
付费用户核心数据：更严格，最好 RPO 1 小时以内。
向量库：如果可从源文件重建，可以备份 metadata 和源文件，向量可重建。
日志：不要无限保留，尤其含用户输入时。
十八、模块 16：客服、运营、信任
你上线后真正面对的不是用户，是用户的焦虑。
他们会问：
我付钱了吗？
为什么额度没到？
AI 结果不准怎么办？
我的数据会不会被训练？
怎么取消？
怎么退款？
怎么删除账号？
我的文件安全吗？
有没有发票？
能不能团队用？
你要提前回答。
必备支持系统
[ ] support email。
[ ] FAQ。
[ ] Docs。
[ ] onboarding video 或 gif。
[ ] in-app help。
[ ] 退款政策。
[ ] 状态页。
[ ] bug report。
[ ] AI output report。
[ ] 用户数据删除入口。
[ ] billing portal。
[ ] changelog。
[ ] roadmap 或 feature request 入口。
信任页面
如果你做 B2B，强烈建议加：
Security page
Privacy page
Subprocessors
Data retention
AI data usage
Compliance overview
Contact sales
DPA request
Status page
用户不是不想买，是怕买错。信任页面就是给他一个不后悔的理由。
十九、上线评分模型
上线前每个模块打分：
0 分：没做。
1 分：做了但没测。
2 分：测了 happy path。
3 分：测了边界情况。
4 分：有监控和告警。
5 分：有文档、负责人、回滚方案。
最低上线线：
支付 ≥ 4
账号权限 ≥ 4
AI 安全 ≥ 4
隐私法律 ≥ 3
监控告警 ≥ 4
备份恢复 ≥ 4
核心产品体验 ≥ 4
SEO/营销 ≥ 3
可访问性 ≥ 3
客服运营 ≥ 3
任何 P0 红线未过，分数无效。
二十、SOP：AI Web SaaS 上线流程
T-7 天：冻结大功能，只修上线阻塞
[ ] 冻结新功能。
[ ] 列出上线版本范围。
[ ] 创建 launch checklist owner。
[ ] 确认 production、staging 环境分离。
[ ] 完整跑一遍注册到付费。
[ ] 完整跑一遍 AI 核心任务。
[ ] 完整跑一遍退款、取消、升级、降级。
[ ] 做一次权限测试。
[ ] 做一次 RAG 租户隔离测试。
[ ] 做一次 prompt injection 测试。
[ ] 做一次备份恢复演练。
[ ] 检查 Privacy、Terms、Refund、Contact。
[ ] 检查 Search Console、sitemap、robots、noindex。
[ ] 检查 Core Web Vitals 和移动端。
[ ] 检查邮件 SPF/DKIM/DMARC。
[ ] 检查日志是否泄露敏感信息。
T-3 天：生产预演
[ ] Stripe live mode 小额真实支付测试。
[ ] live webhook 测试。
[ ] AI provider production key 测试。
[ ] 成本上限设置。
[ ] 用户额度设置。
[ ] rate limiting 设置。
[ ] alert channel 设置，比如 Slack、Telegram、email、PagerDuty。
[ ] uptime monitor 设置。
[ ] error monitor 设置。
[ ] payment failure alert 设置。
[ ] AI cost spike alert 设置。
[ ] rollback 命令演练。
[ ] 数据库 migration 演练。
[ ] 生产 seed 数据确认。
[ ] 管理员账号 MFA。
[ ] 客服入口可见。
T-1 天：最终上线会
[ ] 确认上线时间。
[ ] 确认不在大促、节假日、深夜无人值守时上线。
[ ] 确认负责人在线。
[ ] 确认 rollback owner。
[ ] 确认客服 owner。
[ ] 确认支付 owner。
[ ] 确认监控 dashboard。
[ ] 确认状态页。
[ ] 确认公告文案。
[ ] 确认 Product Hunt、社媒、邮件、广告是否同步。
[ ] 确认 feature flag 可以关闭 AI 高成本功能。
[ ] 确认数据库备份已完成。
[ ] 确认最近一次 staging → production diff。
[ ] 所有 P0 必须关闭。
T-0：上线当天
[ ] 部署 production。
[ ] 检查首页。
[ ] 检查注册。
[ ] 检查登录。
[ ] 检查 AI 核心功能。
[ ] 检查支付。
[ ] 检查 webhook。
[ ] 检查权益开通。
[ ] 检查邮件。
[ ] 检查日志。
[ ] 检查监控。
[ ] 检查 Search Console 可抓取。
[ ] 小流量灰度。
[ ] 观察 30 到 60 分钟。
[ ] 无 P0/P1 后扩大流量。
[ ] 发布公告。
[ ] 记录所有异常。
T+1 天：首日复盘
[ ] 访问量。
[ ] 注册率。
[ ] 首次 AI 成功率。
[ ] 支付转化率。
[ ] AI 请求成功率。
[ ] AI 平均成本。
[ ] 支付失败数。
[ ] webhook 失败数。
[ ] 用户反馈。
[ ] 客服问题分类。
[ ] 404/500。
[ ] 慢接口。
[ ] 错误日志。
[ ] SEO 索引状态。
[ ] 退款/取消原因。
[ ] 修复 P0/P1。
[ ] 更新 FAQ 和 onboarding。
T+7 天：增长与稳定化
[ ] 漏斗分析。
[ ] 付费用户访谈。
[ ] 未付费用户访谈。
[ ] Top 10 bug 修复。
[ ] Top 10 用户疑问写进 FAQ。
[ ] 成本结构复盘。
[ ] Prompt / eval 迭代。
[ ] 定价实验。
[ ] SEO 内容计划。
[ ] 转化文案 A/B。
[ ] 客服 SOP 优化。
[ ] 备份恢复再次演练。
[ ] 安全扫描。
[ ] Roadmap 更新。
二十一、最终 SOP Checking List
下面这份可以直接复制到 Notion、Linear、GitHub Issue。
A. 产品与页面
[ ] 首页价值主张清楚。
[ ] CTA 正常。
[ ] Pricing 正常。
[ ] 登录页正常。
[ ] 注册页正常。
[ ] Dashboard 空状态有引导。
[ ] AI 核心功能入口明显。
[ ] 支付成功页明确下一步。
[ ] 支付失败页可恢复。
[ ] 404 页面正常。
[ ] 500 页面正常。
[ ] Contact 页面正常。
[ ] FAQ 完成。
[ ] Docs 完成。
[ ] Changelog 完成。
B. 生产环境
[ ] production env 独立。
[ ] staging env 独立。
[ ] prod DB 独立。
[ ] prod object storage 独立。
[ ] prod AI key 独立。
[ ] prod Stripe key 独立。
[ ] prod OAuth callback 正确。
[ ] env vars 无缺失。
[ ] secret 未提交仓库。
[ ] deployment rollback 可用。
[ ] migration 可回滚或有修复方案。
C. 域名与基础设施
[ ] DNS 正确。
[ ] HTTPS 正常。
[ ] HTTP → HTTPS。
[ ] www / non-www 统一。
[ ] 证书自动续期。
[ ] CDN 正常。
[ ] 缓存策略正确。
[ ] HSTS 策略确认。
[ ] robots.txt 正确。
[ ] sitemap.xml 正确。
[ ] Search Console 验证。
D. 账号与权限
[ ] 注册。
[ ] 登录。
[ ] 登出。
[ ] 忘记密码。
[ ] 邮箱验证。
[ ] OAuth。
[ ] session 过期。
[ ] workspace 创建。
[ ] 成员邀请。
[ ] RBAC。
[ ] 租户隔离。
[ ] 管理员权限。
[ ] 删除账号。
[ ] 数据导出。
E. 支付与订阅
[ ] live product。
[ ] live price。
[ ] live coupon。
[ ] checkout。
[ ] billing portal。
[ ] webhook signature。
[ ] webhook idempotency。
[ ] delayed webhook。
[ ] duplicate webhook。
[ ] out-of-order webhook。
[ ] 权益开通。
[ ] 升级套餐。
[ ] 降级套餐。
[ ] 取消订阅。
[ ] 恢复订阅。
[ ] 付款失败。
[ ] 退款。
[ ] 发票。
[ ] 争议处理。
F. AI 功能
[ ] 正常输入。
[ ] 空输入。
[ ] 超长输入。
[ ] 恶意输入。
[ ] prompt injection。
[ ] jailbreak。
[ ] 上传文件恶意指令。
[ ] RAG 权限过滤。
[ ] 敏感信息泄露测试。
[ ] system prompt 泄露测试。
[ ] tool call 权限。
[ ] 高风险动作二次确认。
[ ] 输出格式校验。
[ ] AI 失败重试。
[ ] AI 超时处理。
[ ] token 上限。
[ ] 用户额度。
[ ] workspace 额度。
[ ] 成本告警。
[ ] evals 通过。
[ ] 用户举报入口。
G. 安全
[ ] API 鉴权。
[ ] 后端权限校验。
[ ] CSRF。
[ ] XSS。
[ ] SQL injection。
[ ] SSRF。
[ ] 文件上传安全。
[ ] rate limiting。
[ ] bot 防护。
[ ] CSP。
[ ] HSTS。
[ ] security headers。
[ ] dependency scanning。
[ ] secret scanning。
[ ] admin audit log。
[ ] 错误信息不泄露内部细节。
H. 隐私与合规
[ ] Privacy Policy。
[ ] Terms。
[ ] Refund Policy。
[ ] Cookie Notice。
[ ] Acceptable Use Policy。
[ ] subprocessors。
[ ] data retention。
[ ] data deletion。
[ ] data export。
[ ] consent logging。
[ ] marketing unsubscribe。
[ ] AI data usage 说明。
[ ] 高风险 AI 用途排除。
I. 性能与可访问性
[ ] LCP。
[ ] INP。
[ ] CLS。
[ ] 移动端。
[ ] 弱网。
[ ] 图片压缩。
[ ] JS 控制。
[ ] loading 状态。
[ ] AI streaming。
[ ] 键盘访问。
[ ] 表单 label。
[ ] 颜色对比。
[ ] focus 状态。
[ ] aria 按需。
J. Analytics 与增长
[ ] GA4 / PostHog / Plausible。
[ ] signup event。
[ ] onboarding event。
[ ] AI request event。
[ ] payment event。
[ ] subscription event。
[ ] cancel event。
[ ] quota event。
[ ] UTM 保存。
[ ] funnel dashboard。
[ ] revenue dashboard。
[ ] AI cost dashboard。
K. 监控与恢复
[ ] uptime monitor。
[ ] error tracking。
[ ] log aggregation。
[ ] API latency。
[ ] AI latency。
[ ] AI cost。
[ ] payment alert。
[ ] webhook alert。
[ ] email alert。
[ ] database alert。
[ ] backup。
[ ] restore test。
[ ] rollback test。
[ ] incident runbook。
[ ] status page。
L. 客服与运营
[ ] support email。
[ ] help widget。
[ ] FAQ。
[ ] onboarding。
[ ] welcome email。
[ ] payment email。
[ ] quota email。
[ ] cancellation email。
[ ] refund process。
[ ] bug report process。
[ ] AI issue report process。
[ ] user interview list。
二十二、5W2H：上线执行框架
Why：为什么要做这套 checklist？
为了防止上线变成赌博。
AI SaaS 的风险不是单点风险，而是连锁风险：AI 成本异常会影响毛利，权限错误会影响信任，支付错误会影响现金流，隐私错误会影响合规，监控缺失会让小 bug 变成大事故。
你的目标不是上线那一刻很热闹。你的目标是上线后每天都能更稳定地收钱。
What：检查什么？
检查 12 个核心对象：
产品转化
生产环境
账号权限
支付订阅
AI 安全
RAG 数据
Web 安全
隐私合规
性能 SEO
邮件通知
监控恢复
客服运营
Who：谁负责？
独立开发者早期通常你一个人负责，但角色要拆开：
Founder：决定上线范围和是否 stop-ship。
Engineer：修 bug、部署、回滚。
Security reviewer：哪怕是你自己，也要按清单切换脑子审一次。
Billing owner：验证支付、发票、退款。
AI owner：验证 prompt、eval、成本、风险。
Support owner：处理首批用户问题。
Legal reviewer：至少用模板加人工检查，后续找律师。
一个人创业不是一个人混乱。你可以一人多角，但不能没有角色。
When：什么时候检查？
T-7：冻结功能，全面检查。
T-3：生产预演，真实支付，真实 AI key。
T-1：上线会，所有 P0 清零。
T-0：灰度上线，观察监控。
T+1：首日复盘，修 P0/P1。
T+7：增长、成本、留存、客服复盘。
Where：在哪里检查？
staging 检查功能。
production 检查真实链路。
Stripe dashboard 检查支付。
AI provider dashboard 检查 token、rate limit、成本。
Search Console 检查索引。
Analytics 检查漏斗。
Error tracking 检查异常。
Database console 检查数据。
Status page 检查外部可见状态。
Support inbox 检查用户反馈。
How：怎么检查？
不要只点页面。用三种方式检查：
第一，happy path：正常用户从访问到付费。
第二，edge path：失败支付、超额、超时、错误文件、弱网、移动端。
第三，attack path：越权、prompt injection、刷接口、重复 webhook、恶意上传、成本攻击。
每个检查项都必须有结果：
Pass：通过。
Fail：失败，必须修。
Risk accepted：风险接受，写清楚原因和补救时间。
Not applicable：不适用，写清楚为什么。
How much：要投入多少？
最小 MVP 上线检查：1 到 2 天。
认真收钱版：3 到 7 天。
B2B 客户版：2 到 4 周。
企业合规版：1 到 3 个月。
早期不要追求大厂合规，但要守住底线：权限、支付、隐私、AI 成本、监控、备份。
这六个别省。省掉的钱，最后会变成事故债。
最后给你一句狠的：
上线不是把产品交给世界，而是把自己的系统交给现实审判。现实不会因为你是独立开发者就温柔一点。你要做的不是害怕上线，而是把该挡的风险提前挡住，然后大胆开门收钱。