第四篇：岔路口 — ToC 还是 ToB？这个决定改变后面的一切
进入信号：你有了一个被验证的产品方向，接下来要做商业化决策——服务个人还是服务企业？
本篇解决的问题：ToC 和 ToB 的本质区别是什么？怎么判断自己的产品更适合哪个方向？决定了之后，技术架构、定价策略、获客方式分别怎么走？
为什么这时候要停下来想清楚？
原型 B 跑出了真实需求——协作工作流的方向被验证了。L 推荐给了另一家公司的财务，对方也表示想用。
一切看起来很顺利。但有一个问题你还没仔细想过：
你服务的到底是谁？
- 如果服务个人用户（ToC），每个用户自己就是决策者，自己付费、自己使用。你要做的是让产品足够好用到他们愿意掏钱。
- 如果服务企业（ToB），决策者和使用者是不同的人——财务想用，但老板要审批、IT 要评估安全。你的产品不仅要「好用」，还要「好买」。
你现在还不确定。L 是个财务，她是「使用者」。但她只是推荐，真正的付费决策在她的老板那里。新来的客户也一样——财务找你，但掏钱的是公司。
你需要做选择了。因为 ToC 和 ToB 的路径，从这一刻开始，完全不同。
核心差异全景对比
| 维度 | ToC | ToB |
|---|---|---|
| 客户是谁 | 个人用户，自己决策、自己付费、自己使用 | 企业组织，决策者（老板/总监）≠ 使用者（员工） |
| 获客方式 | 流量驱动：SEO、社交媒体、口碑传播、App Store | 关系驱动：行业圈子、销售跟进、招投标、合作伙伴 |
| 付费决策周期 | 数分钟：看到 → 试用 → 觉得不错 → 付费 | 数周到数月：试用 → 内部评估 → 审批 → 采购流程 |
| 定价逻辑 | $5–30/月，免费增值 + 订阅制 | $100–10000+/月，按席位/按用量/按合同谈判 |
| 产品重心 | 体验、留存、自传播、成瘾性 | 可靠性、SLA、安全性、集成能力、合规 |
| 需求判断方式 | 数据驱动：AB 测试、漏斗分析、留存曲线 | 大客户驱动：大客户要的优先做，但要防「定制陷阱」 |
| 多租户含义 | 简单：每个用户看到自己的数据（user_id 隔离） | 复杂：一个公司下有老板、管理员、普通员工多种角色 |
| 安全合规 | 后期考虑，PP/ToS 就够了 | 第一天就要想清楚：数据在哪、谁能看、怎么删 |
| 失败模式 | 没人用（留存率低于某阈值） | 用的人很多但不赚钱（大客户吃掉所有定制资源） |
怎么判断你更适合哪个方向？
问自己三个问题：
1. 产品的核心价值是「个人效率」还是「组织效率」？
- 个人效率 → ToC。比如笔记工具、待办清单、个人记账——价值体现在一个人用它之后变得更好。
- 组织效率 → ToB。比如协作工具、审批流程、团队看板——一个人用没有意义，要整个团队用起来才产生价值。
你的对账工具： 核心价值是「财务发起确认 → 销售响应 → 自动销账」。这是一个协作流程，单人用没意义。偏向 ToB。
2. 谁掏钱？决策链条有多长？
- 个人掏钱 → ToC。决策者 = 使用者，体验好就买单。
- 公司掏钱 → ToB。财务想用 ≠ 公司会买单。你需要搞定的不只是使用者，还有审批者、IT、财务总监。
你的对账工具： 掏钱的是公司（老板批预算），决策链条是：财务提需求 → 财务总监评估 → IT 看安全 → 老板批预算。典型 ToB 决策链。
3. 你能接受多长的变现周期？
- 今天上线明天收钱 → ToC。适合没有积蓄、需要快速验证的 solo founder。
- 3 个月才收到第一笔款 → ToB。需要前期投入（关系维护、定制开发、安全合规），但客单价高，一个客户就够活。
真实建议： 如果你是独立开发者且存款有限，可以考虑从 ToC 做起——先靠订阅收入养活自己；如果你的产品天然是 ToB 场景（比如对账工具），那就老老实实走 ToB 路线，但要准备好「前面 3 个月不赚钱」的心理和资金准备。
本文的后续假设
因为对账工具天然是 ToB 场景，本篇之后的系列文章将以 ToB 为主要视角。但在每个关键节点，都会标注「如果是 ToC 你会怎么做」的对照，方便你在自己的产品上套用。
ToB 路线的第一次技术调整
决定了 ToB 方向后，你的技术视角就需要切换了。虽然现在只有 2 个客户，但你需要从第一天起就用「企业视角」设计系统：
不再是一个用户 == 一个人
在原型阶段，user 就是 L，一对一。现在你需要区分：
公司（Team）
├── 管理员（Admin） —— 财务经理，能配规则、看所有数据
├── 成员（Member） —— 财务操作员，能上传、对账、发确认
└── 协作者（Viewer） —— 销售，只能在移动端确认差异
数据库 Schema 需要加一张 teams 表和角色关联：
model Team {
id String @id @default(cuid())
name String
users User[]
}
model User {
id String @id @default(cuid())
email String @unique
name String?
teamId String
role String @default("member") // admin | member | viewer
team Team @relation(fields: [teamId], references: [id])
}
数据隔离的第一版实现
最简单的多租户——所有查询加上 teamId 过滤：
// 在 API Route 里
const teamId = getSessionTeamId(req); // 从 JWT 里取
const transactions = await prisma.bankTransaction.findMany({
where: { teamId: teamId },
});
不需要每个客户一个数据库，不需要复杂的 Row-Level Security——3 个客户的时候，WHERE team_id = ? 就够了。但这个意识要从现在就有，不然以后改起来要动每一行代码。
不要再在生产数据库上直接改 Schema
原型阶段你 prisma db push 直接推，数据表删了就删了。现在客户开始有真实数据了，你不能再随便清库。
npx prisma migrate dev --name add_teams_and_roles
从现在开始，每一次 Schema 变更都用 Migration 记录。这不仅是为了自己回溯，更是为了以后有团队成员加入时，他能 prisma migrate dev 一键重建环境。
如果是 ToC 产品，你会怎么走？
如果对账工具是 ToC 路线（比如个人财务管理），技术路径会有这些不同：
| 维度 | ToC 做法 |
|---|---|
| 用户模型 | 一个 email 一个账户，不需要团队/角色概念 |
| 数据隔离 | WHERE user_id = ?，简单 |
| 定价 | 免费版（每月 50 笔对账）+ Pro 版（$9.99/月无限） |
| 获客 | 做 SEO 内容「如何快速对账」→ 自然流量 → 注册 |
| 部署 | Vercel Hobby 起步，$0 跑好几个月 |
| 安全 | 前期做基本的 HTTPS + JWT 就够了，合规需求后面再补 |
但要注意——很多「看起来是 ToC」的产品，最终变现还是靠 ToB。Notion、Figma、Slack 都是「先用 ToC 方式获客，再用 ToB 方式赚钱」。如果你不确定，可以先按 ToC 获客 + 免费增值跑起来，等有了用户基数再切企业版。
什么时候进入下一阶段？
你已经做了最重要的商业决策——ToB 路线。
现在你有 2 个客户，都在试用。但这是在「熟人推荐 + 你亲自部署 + 你手动改 bug」的前提下跑通的。当第 3 个、第 5 个客户来的时候，你会发现：
- L 要的发通知方式是飞书，新客户要的是企业微信
- L 的对账规则是「金额 + 日期」，新客户说「我们还要对上采购单号」
- L 的差异确认给了销售 A，新客户说「我们销售分区域，差异要发给对应的区域经理」
需求开始打架了。
进入下一阶段的信号：新客户自己找上门，而且不同客户的需求开始冲突。
这是第五篇的内容——从 1 个客户到一群客户，怎么管理多客户、多租户、需求冲突。
本篇总结
| 做了什么 | 关键决策 |
|---|---|
| ToC vs ToB 全景对比 | 确认 ToB 方向 |
| 团队/角色数据模型 | 加了 Team、User、Role 三张表 |
| 数据隔离策略 | WHERE team_id = ? 最简实现 |
| 用 Migration 代替 db push | 保护客户数据 |
当前系统形态： 收敛到单一产品方向（协作工作流），保留了原型 A 的匹配引擎。2 个客户，开始有了多租户的雏形。代码仍然是一个单体应用。
本月账单：$0（Supabase 免费层 + Vercel Hobby）
下一步
新客户自己找上门——进入第五篇：从 1 个客户到一群客户。