第三篇：多原型并行 — 一个客户问题，三个技术方案
进入信号：你不确定哪种解法最好，你做的 Demo 客户说好但方向可能不止一个。
本篇解决的问题：同一个客户问题，可能有截然不同的解法。怎么用 vibe coding 同时探索三个方向，各自验证不同的假设？三个原型的代码怎么管理？什么时候该砍掉一个？
为什么不能只做一个原型？
Demo 跑通后，你想到了一个关键问题：
L 的对账流程最痛苦的是「差异确认」环节——找到 3 笔差异只要 3 秒，但搞清楚每一笔为什么有差异，还是要她发邮件去问销售。3 秒找出问题，30 分钟解决问题。
这时候你有三个选择：
- 方向 A（深化对账）：把匹配算法做得更智能，支持分次付款、部分退款、模糊金额匹配，减少差异数量，从源头降低确认成本。
- 方向 B（协作闭环）：对账不只是一个计算问题，它本质是跨部门协作。直接做一个轻量的「差异确认 + 通知 + 销账」工作流，让销售直接在小程序/网页上确认，财务只看结果。
- 方向 C（平台化）：不做一个特定行业（B2B 电商）的对账工具，而是一个通用的数据匹配引擎——用户自定义导入格式、匹配规则、审批流程。天花板更高，但复杂度和开发成本也高。
你不知道哪个方向对。这才是多原型真正的价值——不是做三倍的工作，而是用最快的方式排除两个错误答案。
三个原型的定位与假设
原型 A：智能匹配引擎（深化当前方向）
核心假设：客户最大的痛点在「匹配不准、差异太多」——如果能匹配到 95% 以上，差异化确认的工作量会降到可忽略。
技术重点：
- 匹配策略升级：金额模糊匹配（±2% 容差）、日期窗口匹配（±3 天）、多字段组合匹配
- 支持部分匹配：一笔银行流水匹配多笔订单（分次付款）
- 匹配历史学习：客户手动修正的匹配规则自动记住，下次自动应用
验证指标：匹配率从 92%（当前）提升到 98% 以上。
目标客户：同行业（B2B 电商）的 3 个财务，需要匹配量大（>200 笔/周）。
代码管理：fork 当前 Demo，改匹配引擎。项目名 reconciler-smart-match。
原型 B：财务协作工作流（横向扩展）
核心假设：对账的核心瓶颈不在匹配，在确认。做一个轻量的协作工具，让财务发起确认、销售在手机上确认、自动销账，比一个更聪明的匹配引擎更有价值。
技术重点：
- 差异标记后自动生成「确认单」，发送给对应销售
- 销售端：微信小程序 / 移动端 H5，收到通知 → 看订单 → 点「确认无误」或「需要修正」
- 财务端：Dashboard，按状态看已确认/待确认/有争议
- 操作留痕：谁、什么时候、确认了什么
验证指标：差异确认周期从平均 4 小时缩短到 30 分钟。
目标客户：同样找 B2B 公司的财务，但选那些「财务和销售沟通成本高」的公司（团队规模 20 人以上）。
代码管理：新起项目 reconciler-collab。复用原型 A 的文件上传和匹配逻辑（直接复制，不要建共享库——现在探索才该做的事情）。
原型 C：通用数据匹配平台（底层抽象）
核心假设：对账只是「两张表按规则匹配」这个通用问题的一个特例。如果能做一个让用户自定义导入格式、匹配规则、审批流的数据匹配引擎，天花板远高于单一行业的对账工具。
技术重点：
- 用户自定义 Schema：上传 CSV/Excel 后，用户自己映射字段
- 可配置匹配规则：AND/OR 组合条件、容差设置、优先级排序
- 可配置工作流：匹配后做什么——标记、通知、导出、API 回调
- 模板市场：预设「银行对账」「发票核验」「库存盘点」等场景模板
验证指标：是否有用户能在不看教程的情况下，5 分钟内完成一次自定义匹配规则。
目标客户：不再是特定行业的财务，而是任何需要「两张表对账」的人——电商运营对库存、市场核对广告费、行政核对报销单。
代码管理：新起项目 matchflow-platform。代码与 A、B 几乎不共享——因为这个方向在底层数据模型上就完全不同。
三个原型的项目管理
怎么管 3 套独立代码？
这时候不要搞 monorepo、不要建公共库、不要想代码复用。直接建 3 个独立仓库：
~/Projects/
reconciler-smart-match/ # 原型 A
reconciler-collab/ # 原型 B
matchflow-platform/ # 原型 C
每个项目独立的技术决策、独立的依赖、独立的部署。理由是：
- 探索阶段代码复用是幻觉：你觉得三个项目共享上传组件，但改了 A 的组件后 B 不一定需要那个改动——维护共享库的时间成本远超重写的成本。
- 独立部署不互相影响：A 挂了不影响 B 的客户测试。
- 砍的时候干净利落：整个文件夹删掉就好，没有「但是那个共享模块还被 C 用着」的问题。
每两天出一个原型
Vibe coding 的核心优势在这个阶段爆发：
- 原型 A（深化匹配）：在现有 Demo 上改，2 小时改匹配算法 + 1 小时改 UI 展示匹配详情。一天出。
- 原型 B（协作工作流）：新起 Next.js 项目，AI 写通知系统 + 移动端 H5。前端页面多一点，但逻辑不复杂。一天半出。
- 原型 C（通用平台）：Schema 设计最重——用户可自定义意味着数据模型要支持动态字段。这是三个里最坑的，但 AI 可以写好 Schema 调整的大框架。两天出。
一周内，三个方向的原型都有了。
找客户跑：三类客户，三种反馈
原型 A 反馈：匹配率上去了，但没解决根本问题
你找了 L 的同行——另一家 B2B 电商的财务 M。M 每周对账量比 L 大一倍（400+ 笔/周）。
M 用完之后说：
「匹配率很高，确实厉害。但是你知道吗，我们公司的销售经常改单不改价——他口头答应客户减 100 块，系统里的价格没改。匹配再准也没用，我还是要找销售确认。」
核心发现：匹配率从 92% 到 98% 确实难做，而且即使做到了，核心瓶颈还是协作问题。方向 A 解决了一个真实问题，但不是最关键的问题。
原型 B 反馈：痛点被真正打中了
你找了第三家公司的财务 C，她的团队 30 人，销售分布 3 个城市。她最烦的就是「找销售确认对不上的账」。
试用协作工作流之后：
「这个太需要了。以前要打电话、发微信、追着问，现在我在系统里点一下，销售那边就弹通知了。而且能看谁确认了谁没确认——再也不会有人装没看见了。」
她追问：
「能不能加个审批？有些差异大的要财务经理看过才行。还有能不能导出确认记录给老板看？」
核心发现：协作是核心痛点。拉上销售后，自然延伸出审批、导出等需求。这个方向有生命力。
原型 C 反馈：太灵活了，反而不知道该怎么用
你找了一个做电商运营的朋友 D，他需要核对库存和订单。
他打开原型 C，面对「自定义匹配规则」界面，沉默了很久：
「我不知道该怎么设置。我其实只需要你告诉我库存和订单对不上，然后我去查就行了。你让我自己设计规则，我不会。」
核心发现：通用性是一个陷阱——能把产品卖给更多人 ≠ 更多人会买。通用工具需要用户具备「数据思维」，但大多数目标用户没有。他们想要的是「帮我解决我的问题」，而不是「给你一个工具你自己组合」。
反馈汇总
| 原型 A | 原型 B | 原型 C | |
|---|---|---|---|
| 核心假设 | 匹配不准是最大痛点 | 协作瓶颈是最大痛点 | 通用性价值更大 |
| 验证结果 | 部分成立，但不是最关键 | 成立，客户主动提新需求 | 不成立，通用性用户不买账 |
| 客户反应 | 「不错，但是…」 | 「这个太需要了！」 | 「我不知道怎么用」 |
| 结论 | 保留，但不做主力方向 | 主力方向 | 砍掉 |
砍掉方向 C：为什么不是浪费？
原型 C 花了你两天时间。但它帮你排除了一个巨大的错误——如果你没做这个原型，你可能会一直惦记着「做一个通用平台」这个诱人的方向，在 A 和 B 之间摇摆时忍不住往 C 的方向偏，反而把主力方向做成了四不像。
这些花在「错误方向」上的时间不是浪费，是节省了你未来可能花在这个方向上的几个月。 排除了一个错误的答案，等于排除了 33% 的方向风险。
当前代码状态
三个独立项目，代码没有共享，维护靠复制粘贴改。原型 C 已经放弃。原型 A 的匹配引擎后续可以并入原型 B。
技术上的尴尬：原型 B 的代码已经很乱了——因为两天赶出来的协作工作流里塞了太多一次性逻辑。通知是硬编码的邮件模板，移动端 H5 是直接写在一页里没拆分，数据库里多了好几张临时表。
这个尴尬是正确的。你不需要在探索阶段追求代码质量。
什么时候进入下一阶段？
你已经验证了：
- ✅ 方向 B（协作工作流）是三个里最有生命力的
- ✅ 客户不仅说好，还主动提了审批、导出的需求——这是真需求的特征
- ✅ 方向 A 的匹配技术可以保留，方向 C 可以放弃
但你也有新问题：
- L 把原型 B 推荐给了另一个同行，对方也想用——你开始有了第二个客户
- 原型 B 的代码是为 L 一个人写的，L 的销售部门 5 个人，新客户的销售部门 15 个人
- 不同客户的需求开始打架：一个要短信通知，一个要飞书通知
进入下一阶段的信号：新客户自己找上门了——不是你去推，是客户推荐来的。
这时候，你面临一个更根本的问题：你的产品到底是 ToC 还是 ToB？ 这将决定后面所有技术决策的方向。
这是第四篇的内容——岔路口。
本篇总结
| 做了什么 | 花了多久 |
|---|---|
| 三个方向的原型设计 | 1 天 |
| 原型 A（智能匹配）开发 + 测试 | 1 天 |
| 原型 B（协作工作流）开发 + 测试 | 1.5 天 |
| 原型 C（通用平台）开发 + 测试 | 2 天 |
| 找客户跑，收集反馈 | 2 天 |
当前系统形态： 2 套独立的单体应用（原型 C 已放弃），各有自己的 Next.js + Prisma + Supabase 栈。服务 3 个不同类型的测试客户。代码复制粘贴，没有共享。
本月账单：$0（三个项目各用 Supabase 免费层）
下一步
新客户自己找上门——进入第四篇：ToC 还是 ToB？这个决定会改变后面的一切。