我会把工具分成两类：直接影响收入的第一周接好，只影响舒服程度的晚一点买。判断标准不是功能多不多，而是半夜出事时你能不能独自恢复。
7 层工具栈责任表
先建一张「工具栈责任表」。这张表比 Notion 里收藏 30 个 SaaS 更有用，因为它写的是谁负责、哪里告警、坏了怎么退回。
| 层级 | 默认选择 | 后台字段或材料 | 出事时先看哪里 |
|---|---|---|---|
| Web 应用 | Next.js、Rails、Laravel 三选一 | release id、commit sha、环境变量版本 | 部署日志、错误日志、最近一次发布 |
| 数据库 | Postgres | migration id、backup timestamp、connection pool | 慢查询、连接数、备份恢复点 |
| 支付 | Stripe Checkout 或 MoR | Checkout Session id、customer、subscription、payment_status | webhook 日志、订单表、Stripe Dashboard |
| 邮件 | Resend、Postmark | message id、bounce reason、suppression list | 退信列表、发送域名、DKIM/SPF |
| 错误日志 | Sentry | release、environment、user id、trace id | 最近 24 小时新增 issue |
| 行为分析 | PostHog、Plausible | user id、feature flag、conversion event | 付费漏斗、按钮点击、页面路径 |
| 模型调用 | OpenAI、Anthropic | model、input tokens、output tokens、cache tokens、cost | 单用户成本、单功能成本、失败率 |
如果一个工具不能填进这张表，先别买。它可能很好用，但不一定适合一人公司。
付款层要记哪些字段？
Stripe Checkout 的核心对象是 Checkout Session。不要只保存一个「支付成功」布尔值，后面退款、发票、订阅升级都会追着你要原始字段。
| Stripe 字段 | 存到你数据库的用途 |
|---|---|
id | 作为订单和 webhook 幂等键，避免重复开通权益 |
mode | 区分一次性付款、订阅和保存支付方式 |
payment_status | 判断 paid、unpaid、no_payment_required |
status | 区分 Session 是 open、complete 还是 expired |
customer | 绑定用户和 Stripe Customer |
customer_details.email | 账单邮件和客服检索 |
subscription | 订阅产品的续费、取消、升级入口 |
payment_intent | 一次性付款的争议、退款、风控排查 |
metadata.user_id | 把 Stripe 事件映射回内部用户 |
Stripe fulfillment 文档强调，履约不能只靠 success_url。用户付款后可能关闭浏览器，或者网络中断，成功页没有被访问。你要监听 checkout.session.completed，延迟支付方式还要看 checkout.session.async_payment_succeeded。履约函数用 Checkout Session ID 重新 retrieve，并写成幂等逻辑。
模型成本日志第一天就做吗？
做。AI SaaS 和普通 SaaS 的差别在毛利会被单个用户吃掉。Reddit 上有团队因为 OpenAI 用量拿到 3000 美元 surprise bill 的案例，很多小团队的真实问题不是模型不会用，而是月底才知道哪个功能在烧钱。
最低限度，把这些字段写进 ai_usage_events 表：
| 字段 | 例子 | 为什么要存 |
|---|---|---|
user_id | usr_123 | 找出亏钱用户 |
feature_id | pdf_summary | 比较功能毛利 |
provider | openai、anthropic | 供应商账单对齐 |
model | gpt-5.5、claude-opus-4-7 | 追踪模型切换影响 |
input_tokens | 1200 | 普通输入成本 |
output_tokens | 400 | 输出成本通常更贵 |
cached_tokens | OpenAI 的 usage.prompt_tokens_details.cached_tokens | 看 prompt cache 是否真省钱 |
cache_read_input_tokens | Anthropic 的缓存读取 tokens | 计算缓存命中后的成本 |
cache_creation_input_tokens | Anthropic 的缓存写入 tokens | 避免把首次写缓存当成异常 |
request_cost_usd | 0.014 | 按请求算毛利 |
latency_ms | 1800 | 区分成本问题和体验问题 |
error_code | rate_limit_exceeded | 处理限流和重试 |
OpenAI prompt caching 会在 usage.prompt_tokens_details.cached_tokens 里返回缓存命中 token。Anthropic prompt caching 会返回 cache_read_input_tokens、cache_creation_input_tokens 和 input_tokens。注意 Anthropic 文档里说，启用缓存后 input_tokens 只代表缓存断点之后的新输入，总输入要把 cache read、cache creation 和普通 input 加起来。
哪些后台先别买？
先别急着买 CRM、复杂工单、A/B testing、数据仓库、销售自动化、社媒排程。它们都可能有价值，但早期很容易变成「为了管理不存在的团队而买的工具」。
一人公司最先要稳定的是这 5 件事：
- 用户能登录。
- 用户能付款。
- 支付后权益能开通。
- 模型调用失败会降级或提示。
- 成本异常当天能报警。
做到这 5 件事，再去买让你舒服的工具。
后台权限和网络环境怎么收口？
支付、模型、部署和银行后台不要散在十几台设备上。Stripe webhook 排查、OpenAI 用量查询、Anthropic prompt cache 调试、Cloudflare 或 Vercel 回滚，经常会在同一个晚上发生。
我的做法是把财务和部署后台放进一套固定设备、固定 2FA、固定恢复码的清单里。跨城市办公或出差时，可以用海外银行 + Stripe + AI 工具全场景承载这些关键后台操作。这里解决的是登录连续性和后台可用性，不是给普通浏览做加速。
上线前检查表
| 检查项 | 合格标准 |
|---|---|
| Stripe webhook | checkout.session.completed 写入订单，重复事件不会重复开通 |
| Success page | 用 session_id 查询状态，但不承担最终履约 |
| 模型成本 | 每次请求能查到 user、feature、model、tokens、cost |
| Prompt cache | OpenAI/Anthropic 缓存字段进入日志，不靠感觉判断是否省钱 |
| 告警 | 支付失败率、模型失败率、单用户成本、队列堆积都有阈值 |
| 备份 | 数据库备份能恢复到最近 24 小时内的可用点 |
| 密钥 | Stripe、OpenAI、Anthropic、邮件服务密钥都有轮换记录 |
一人公司的工具栈要像背包。背包太重，你走不远；背包太轻，第一次下雨就会崩。