能力案例建设中
StudioOps Admin：“订阅 + 积分”SaaS 的运营后台
订阅、积分流水、订单、滥用与欺诈案件、权限和审计放进一个内部后台——针对大多数 AI 产品采用的“订阅 + 积分”收费模式。
能力案例：使用合成数据演示，不是付费客户项目。
- 角色
- 独立完成 —— 产品、设计、架构、全栈开发、测试
- 技术栈
- Next.js 16React 19TypeScriptPostgreSQLPrisma 7Better AuthZodRechartsVitestPlaywright
概览
- 挑战： 按“订阅 + 积分”收费的产品，数据都在 PostgreSQL 里，依然运营不起来——积分要对得上账、要防 API 滥用和薅奖励、续费会失败、事后说不清谁改了什么。
- 方案： 一个只给员工用的后台：用户、套餐、三桶积分钱包和不可变流水、带幂等的支付事件、风险案件、5 角色权限、只追加的审计日志。
- 结果： 65 个单元 / 集成测试、6 个浏览器 E2E、17 条安全与风控验收全部通过；桌面和手机都可用。
挑战
SaaS 有了付费用户之后，难的不再是功能，而是这些问题：
- 用户说积分被扣了两次，客服能证明到底发生了什么吗？
- 有人用脚本刷接口，或者注册 50 个号薅注册积分，谁发现、谁来处理？
- 续费连续失败 3 次，有人跟进吗？
- 管理员改了价格、补了积分，六周后还有人说得清是谁、什么时候、为什么吗？
大多数团队靠手工查数据库来回答。等到钱、权限和审计开始重要的时候，就不够用了。
方案
风险是“案件”，不是一个分数。 支付失败、撞库、API 滥用、薅奖励由确定性规则自动开案。风控分析师认领案件、查看证据，然后解除、限制或升级——每一步都必须写理由。
积分永远对得上账。 订阅积分、购买积分、赠送积分分三个桶，各有过期规则。每次变动都写一条不可修改的流水；人工调整必须填理由，并和审计记录在同一个事务里提交。
权限在服务端生效。 Owner、管理员、运营、风控分析师、审计员共用一份类型化的权限注册表，导航、按钮、服务、接口都用它。隐藏按钮不算安全——审计员发写请求，真的会返回 403。
出事时用手机也能处理。 手机上把密集表格改成摘要卡片，而不是硬缩小。
技术亮点
- 所有写操作过同一道守卫： 登录会话 → 命名权限 → 限流策略，然后才进入业务逻辑。
- 金额用整数“分”存储， 每个订单保存商品快照，改价不影响历史订单。
- 支付事件幂等： 重放同一个回调，返回原结果，不会重复扣款、开通或发积分。
- 精确恢复： 限制账户前保存原状态快照，解除时恢复到完全一致的状态。
- 乐观并发： 两个分析师同时处理同一案件，后提交的返回 409，不会静默覆盖。
- 安全事件脱敏： 永远不存密码、Cookie、Token 或卡号。
质量与测试
| 层级 | 结果 |
|---|---|
| 单元 / 集成（Vitest） | 27 个文件、65 个测试通过 |
| 浏览器 E2E（Playwright） | 6 个测试通过，覆盖桌面 Chromium 和 iPhone 13 视口 |
| 安全验收 | SEC-001 ~ SEC-008 通过（401 / 403 / 429、脱敏、安全头） |
| 风控验收 | RISK-001 ~ RISK-009 通过（升级、去重、精确恢复、会话吊销） |
| 构建 | Lint、类型检查、生产构建全部通过 |
结果与边界
- 一个完整可演示的后台，使用确定性的合成数据：200 个用户、190 个账户、240 个订单、12 个风险案件、90 天指标。
- 支付是模拟的；这个案例没有面向用户的结账页面。
- 不包含：SSO、自定义角色、2FA、WAF / DDoS 防护、真实支付回调的签名校验。
- 下一步：模型调用成本与毛利统计——这是 AI 产品最关键的运营指标。
交付过程
| 阶段 | 产出 |
|---|---|
| 需求 | 书面规格：三种身份、要解决的问题、明确不做的范围 |
| 原型 | 页面流程图，以及 Dashboard、风险队列、案件详情的线框图 |
| UI | 设计规范：一个操作色、状态色配文字、移动端规则 |
| 架构 | 模块化 Next.js 单体 + PostgreSQL，所有写操作过同一道守卫 |
| 开发 | 规格先行，用 AI 编码 Agent 开发；每个模块都有书面计划 |
| 测试 | 单元、集成、E2E、安全与风控验收用例 |
| 上线 | Vercel + 托管 PostgreSQL，合成数据每日重置（进行中） |
完整方法写在这篇文章里：从需求到上线，独立交付一个 Web 产品到底需要什么。