第一篇：从零到一 — 一个客户，一个问题，一个原型
本篇解决的问题：你有一个模糊的想法，但怎么确认它值得做成产品？怎么从一个听到的抱怨中，挖出真正值得用代码解决的问题？然后怎么用最低成本做出第一个原型验证？
本文核心：JTBD（Jobs To Be Done）方法论实战 + AI 辅助客户访谈 + 静态原型搭建，帮你在写代码之前先确定你在解决真问题。
故事起点：一个朋友的抱怨
一个周五晚上，朋友 L 在群里抱怨：
"烦死了，每周五要花大半天对账。从银行导出账单、从后台导出订单、Excel 手动匹配，经常对不上还要逐条查。公司现在才 30 个人，等规模上来我是不是不用干别的了？"
L 是一家 B2B 电商公司的财务，公司用一套标准的进销存系统，但系统和银行流水之间的对账全靠人工。每周五她都要经历同样的流程：导出、匹配、查差异、发邮件问销售、再改。
群里其他人表示同情，然后话题很快转移了。
但你在想：这是一个问题，而且是一个重复发生的问题。 如果 L 一个人就花半天/周，全国有多少个"L"在干同样的事？这个问题值不值得用代码解决？
你决定先不写代码。你需要验证三件事：
- 这个问题到底是"L 的操作效率问题"，还是"普遍存在的深层需求"？
- 如果是后者，客户真正想完成的任务是什么？
- 有没有人已经在解决这个问题，客户为什么不满意？
你需要一个方法，JTBD 就是最好的起点。
JTBD 实战：从抱怨到需求
JTBD（Jobs To Be Done）的核心思想很简单：客户不是买产品，而是"雇佣"产品来完成某个任务。
Clayton Christensen 说过一句经典的话：
"People don't want a quarter-inch drill, they want a quarter-inch hole."
客户不想要一个电钻，他想要墙上的一个孔。搬到我们的场景：L 不想要一个"对账工具"，她想要的是"确保公司的钱一分没少"。
Step 1：客户访谈——不是问"你觉得这个功能怎么样"
很多人做"客户访谈"的方式是：做一个原型，然后问对方「你觉得这个怎么样」。这几乎是无效的。对方会客气地说「挺好的」，然后永远不会用。
正确的做法是回溯式访谈：让对方详细描述上一次做这件事的全部过程。
周末你请 L 喝了杯咖啡，问了五个问题：
- 触发事件：「上周五对账之前发生了什么？是你自己想起来去做的，还是有人催你？」
L 说：每周五下午财务总监会提一句「这周账平了吗」，然后她就去做。但上个月有次总监周四就问了，因为有笔大额付款需要确认，她很被动。
关键洞察：她的任务不只是"对账"，还包括"在老板问之前就完成"。需求里隐含了一个时效性要求。
- 完整流程：「从你打开电脑到发出对账结果，每一步都做了什么？包括打开哪个文件夹、点了什么都说说。」
L 从打开银行网站说起，描述了登录 → 选择日期范围 → 下载 CSV → 打开进销存系统 → 导出订单报表 → 打开 Excel → VLOOKUP 匹配 → 标黄差异行 → 写邮件给销售确认 → 修正 → 再跑一遍 → 截图发群。一共 12 步。
关键洞察：流程里最痛苦的不是"匹配"本身，而是"标黄差异行后找人确认"这一步。这意味着核心瓶颈不是技术，是协作。
- 痛点时刻：「在哪一步你觉得最烦？有没有哪次特别崩溃？」
L 说：有次银行流水的格式变了，VLOOKUP 公式全垮，她花了一个小时调。还有一次销售改了订单金额但没通知她，对账对不上，她查了 40 分钟才发现是销售的问题。
关键洞察：痛点不是"操作复杂"，是不可靠——她对不上账的时候不知道是自己错了还是别人错了，排查时间不可控。
- 替代方案：「除了你现在的做法，你试过别的方法吗？公司有没有买过什么工具？」
L 说老板问过能不能用某 SaaS 对账工具，但一个月要 3000 块，而且不支持他们银行的导出格式，售后说「可以定制，10 万起」。于是作罢。
关键洞察：市场上有产品但要么太贵、要么不灵活。这是一个中等价位 + 灵活适配的机会窗口。
- 理想结果：「如果有一个魔法工具，你希望它做什么？」
L 说：「我希望它自动帮我对，对不上的自动标记、自动通知对应的人确认，我只需要看最终结果就行。」
关键洞察：她想要的不是一个更好的 Excel，而是一个自动化工作流——导入、匹配、差异分发、确认、汇总。
Step 2：用 AI 整理访谈输出
你把录音转文字（用飞书妙记或通义听悟），然后把转录文本扔给 AI：
"帮我从这段客户访谈中提取以下信息：
- 客户的真实任务是什么（不是他们说的表面需求）
- 完成这个任务的完整步骤
- 每一步的痛苦程度（0-10 打分）
- 他们试过但不满意的替代方案
- 如果完美解决，他们期望的结果是什么"
AI 会帮你抽出结构化的洞察。你得到的核心结论是：
- 表面需求：一个对账软件
- 真实 JTBD：在老板询问之前，automatically 完成银行流水和订单的匹配，快速定位差异并通知责任人
- 痛苦峰值：差异确认环节（7 分）和银行格式变更导致的公式崩溃（8 分）
- 替代方案不满原因：贵（3000/月）、不灵活（不支持定制格式）
- 期望结果：自动化对账 + 自动差异分发 + 只看结果
Step 3：画用户旅程地图
基于访谈，画出 L 的对账旅程：
触发 → 登录银行 → 下载流水 → 登录系统 → 导出订单 → VLOOKUP 匹配 → 标差异 → 发邮件确认 → 等待回复 → 修正 → 再匹配 → 截图发群
😐 😤 😤 😐 😐 😤😤😤 😤😤😤 😤😤😤 😡 😐 😤 😐
痛苦集中在中间的「匹配 → 差异 → 确认」三段。如果做一个工具，就应该集中火力解决这三段，其他步骤先别碰。
核心假设卡片
在写任何代码之前，先写下你的核心假设。如果这些假设被推翻，整个产品的方向就需要调整。
| 假设 | 验证方式 |
|---|---|
| L 的痛点不是个例，50 人以下公司的财务都有类似问题 | 再访谈 3 个类似规模公司的财务 |
| 自动对账能帮她从 4 小时降到 30 分钟 | 拿第一版跑真实数据对比 |
| 客户愿意为这个付 99-299 元/月 | 做出能用的版本后直接问 |
| 银行格式多样性是可解的（核心是解析引擎） | 收集 5 家主流银行的 CSV 格式做适配 |
第一个原型：一张前端页面
原型是什么？
很多人以为原型要做成一个能跑的完整应用。错了。原型的目标只有一个：拿给客户看，验证你的理解是否正确。
你打开终端，建一个最简单的 Vite + React 项目：
npm create vite@latest reconciler-prototype -- --template react-ts
原型里有什么？
三个区域，一个页面对账的完整流程：
-
左侧：上传区域（只是个好看的框，还不能真上传）
- "拖拽或点击上传银行流水（支持 CSV/Excel）"
- "拖拽或点击上传订单报表"
-
中间：匹配结果（写死的假数据，但看起来真实）
- 表格展示：银行流水行 / 订单行 / 金额 / 状态
- 匹配成功的行标绿色 ✅
- 差异行标红色 ⚠️，带"通知负责人"按钮（不能真点）
-
右侧：汇总面板（假数据，但数字合理）
- "本周对账结果：35 笔匹配成功，3 笔差异"
- "预估节省时间：3.5 小时"
为什么用假数据？
因为你要验证的是交互模型，不是技术可行性。让客户看到这个页面后，问她：
- "如果这些是真实数据，这个展示方式你能不能一眼看出哪些有问题？"
- "你更习惯上传文件还是授权银行 API 直连？"
- "差异行的'通知负责人'，你希望通知谁？用什么方式？"
原型的代码分层
即使只有一页，也可以先搭好基础结构（反正 AI 写）:
src/
pages/
Reconciliation.tsx # 对账主页面
components/
FileUpload.tsx # 上传组件（占位）
MatchTable.tsx # 匹配结果表（假数据）
SummaryPanel.tsx # 汇总面板（假数据）
data/
mock.ts # 假数据
技术栈： React + TypeScript + Tailwind CSS。没有后端，没有数据库，没有 API。npm run dev 就能跑。
Vibe Coding 提示词示例： "帮我在 React + TypeScript + Tailwind 里做一个对账结果的表格组件，显示银行流水行和订单行的匹配情况。匹配成功的行用绿色，有差异的行用红色高亮，每一行右侧有一个'通知'按钮。数据用 props 传入，写一个 mock 数据文件。"
拿给客户看
周末把 L 约出来，打开 localhost:5173，把笔记本推到她面前。
她看了 15 秒说：
「对，就是这个感觉！但是我平时不是先上传银行再上传订单，我一般是两边一起打开然后对着看。能不能两个文件框并排放？」
15 秒，你就得到了第一个修正方向。如果这时候你已经写完了后端和数据库，改起来成本就高了。
她接着问：
「什么时候能真正用起来？」
这就是你要的信号——进入下一阶段的信号。
什么时候进入下一阶段？
你已经验证了：
- ✅ L 会为这个场景付费（至少她说了，虽然不一定是真话）
- ✅ 交互方向是对的（她理解了，而且给了具体改进意见）
- ✅ 她表达了使用意愿
进入信号：客户看过原型后说「什么时候能用？」
这时候，就该把静态原型变成真正可运行的 Demo——加上后端、数据库，让客户能用自己的真实数据跑一遍。这是第二篇的内容。
本篇总结
| 做了什么 | 为什么做 | 花了多久 |
|---|---|---|
| 客户访谈（JTBD 方法） | 确认是真问题还是假痛点 | 1 小时访谈 + 2 小时整理 |
| AI 辅助分析访谈内容 | 从对话中提取结构化洞察 | 30 分钟 |
| 画用户旅程地图 | 定位真正的痛苦峰值 | 20 分钟 |
| 写假设卡片 | 明确什么情况下该 pivot | 15 分钟 |
| Vibe Coding 出静态原型 | 验证交互方向，不用写真逻辑 | 2 小时 |
总投入： 约 6 小时（不含学 JTBD 的时间），零成本。
当前系统形态： 一个前端页面 + 写死的假数据，没有后端、没有数据库。能跑在 localhost 上，能拿给一个客户看。
本月账单：$0（甚至不需要部署）
AI 在这个阶段的角色： AI 写 90% 的代码，你负责选择方向、判断真假需求。AI 能帮你 5 分钟搭出一个好看的页面，但无法告诉你"这个页面解决的是不是真问题"——那是你的工作。
下一步
当客户说「什么时候能用？」——进入第二篇：把静态原型变成可运行的 Demo，加上真后端和数据库。
为什么要在 SaaS 创业系列里单独聊用户研究？
因为产品失败的根源，很少是「技术做不出来」。绝大多数死在「做出来的东西没人要」。而「没人要」的根源，又很少是「用户骗了你」——绝大多数是你自己骗了自己。
本篇不谈具体工具（问卷怎么设计、访谈提纲怎么写），谈更底层的两件事：为什么我们很难真正理解别人的问题？怎么才能把 ego 关掉，听见那些沉默的信号？
Ego 的三个陷阱
陷阱一：「我也是用户，所以我知道问题在哪」
你是一个 28 岁的软件工程师，每天坐在空调房里写代码。你在做一个给 50 岁线长（工厂产线小组长）用的排班工具。
你拍脑袋想：「排班嘛，就是拖拽几个人到时间格子里，支持冲突检测，最好有个 AI 自动排。」
你花了两个月做了这个工具，去工厂给线长试用。线长打开电脑，愣了三秒，然后拿起旁边的白板笔，在白板上画了今天的排班。
你问他：「为什么不用我们的工具？」
他说：「白板改起来快。我想换人，擦掉就行。你这个，我要先点进去，再拖，再保存——太慢了。」
你的 ego 在于：你以为「解决问题 = 做一个功能更全的工具」。 但对线长来说，「解决问题 = 更快地完成排班然后去干别的事」。你的工具增加了步骤，所以被白板打败了。
陷阱二：「用户说想要这个，我就做了」
你做了一个 SaaS 对账工具。第一批客户 L 说：「能不能加个功能，自动发邮件给客户催款？」
你花了三天做了。上线了。L 用了两次，再也没用过。
你问她为什么。她说：「我发现客户不理邮件的。后来我直接打电话催，效果好多了。」
你的 ego 在于：你以为用户说要什么，就等于解决了什么。 但用户是在「用他们能想到的语言」描述他们想要的结果。L 要的不是「邮件催款功能」，是「客户快点付款」。邮件只是她当时能想到的手段。
正确做法：当用户提一个功能需求时，追问三次「为什么？」。
「能不能加个邮件催款功能？」
「为什么需要催款？」
「有些客户拖，对不上的账要拖一周才处理。」
「为什么他们拖？」
「因为确认差异他们要去查自己的系统，查一次要十几分钟，嫌麻烦就不查了。」
「那如果他们能在手机上点一下就能确认？」
你最后做的不是「邮件催款」，而是一个「差异一键确认 + 自动对账销账」的移动端流程。用户说的和用户要的，中间差了三层追问。
陷阱三：「数据告诉我用户喜欢这个」
你做了 AB 测试。版本 A（你的新设计）比版本 B（旧版）点击率高 23%。你觉得方向对了。
但你没有看到的数据：点击率高是因为用户找不到他们想要的功能，在页面上到处乱点。
你也没有看到的数据：点击完以后，80% 的用户的下一步行为是关掉页面——因为没找到。
你的 ego 在于：你只想看到证明自己是对的数据。 那些沉默的、不点击的、关掉页面的人，才是你该真正去理解的人。但他们不会主动告诉你「你的产品不好用」——他们就直接不用了。
四种真正理解用户的方法
方法一：别看他说什么，看他做什么
观察 > 访谈 > 问卷。
一个用户在你的对账工具里上传了 CSV，点了「开始对账」，等了 4 秒，结果出来——35 笔匹配，3 笔差异。
然后你看他的操作日志：他没有点「通知负责人」按钮，而是打开了微信，截了个图发给了销售。
你的产品给了他一个功能（系统内通知），他更需要的是「把差异截图发给销售然后在微信里聊」。
你在工位上设计的「通知负责人」流程完全正确——但在用户端，这个功能被绕过了。他不需要一个「更好的通知按钮」，他需要的是「和销售用他们惯用的方式沟通」。
实操：在功能上线后，不要只看点击率。看「用户实际怎么完成这个任务」。如果 50% 的用户在某个步骤绕开了你的设计，说明你的设计有问题，不是用户的问题。
方法二：当你的用户不是你
你的 SaaS 产品做的是财务对账。你的用户是 35-50 岁的财务人员。她们的工作场景、思维方式、对软件的接受度，和你完全不同。
你很难「共情」——因为你没做过财务。但你可以靠近。
操作建议：
- 去客户的办公室坐半天。不是访谈——是安静地坐在角落，看她工作。你会注意到她桌面上有好几个 Excel 窗口同时打开（因为系统之间不互通）、电话响了三次都是销售来确认对账差异（你才知道对账不只是「匹配」）、她写了一个便利贴贴在显示器上：「XX 客户格式不同，记得先转 CSV」（你才知道自己支持的格式太少）
- 在客户同意的情况下，录屏看他怎么用你的产品。录屏会上瘾——你已经看了 100 遍自己的产品，你不会注意到「这个按钮的文案让人困惑」。但一个第一次用的人，鼠标在那个按钮上悬停了 8 秒——这是困惑的信号。
方法三：找拒绝你的人聊
你发出去的试用邀请里，有些人注册了、一次都没打开过。这些人是你的金矿。
给 3 个「注册后一次都没用」的人发微信：
「我是 XX 产品的创始人。我看到你注册了但还没用过。你不需要说好话——告诉我为什么不感兴趣，比夸我有用 100 倍。如果你愿意，给你寄一箱水果。」
三个人都回复了：
- 「我其实是帮朋友注册的。我自己不做财务，所以没用。」
- 「我下载了但打开发现要传 CSV，我不知道什么是 CSV。」
- 「我那个月刚好离职了，没来得及用。」
第一个不是你的问题。第二个是致命的产品问题——你在界面里假定用户知道什么是 CSV。
你的产品介绍里没有出现「CSV」这个词。但打开以后第一个上传按钮就写「上传 CSV 银行流水」。一个不会用「CSV」这个词的财务（她们说自己用的是「Excel 表格」），看到这个按钮就走掉了。
你写了 5 万行代码，用户卡在了第一个词上。
方法四：「五岁小孩测试」
你能不能用三句话、不带任何行业术语，向一个完全不了解你产品的普通人解释清楚你的产品在解决什么问题？
❌ 「我们是一个基于云原生架构的智能财务对账平台，支持多源异构数据的自动匹配与异常分发。」
✅ 「我做一个软件，帮那些每周要花半天时间对账的财务，把 3 小时的工作变成 3 分钟。」
第二个版本你可以在出租车上说出来。第一个版本没人听得懂——包括你的潜在客户。
强迫自己用极简的语言解释产品，不是文案优化——是验证你到底有没有真正理解你在解决谁的问题。
如果你需要「平台」「架构」「异构」「自动匹配」这些词来解释你的产品，说明你还没有想清楚「这个产品对人类到底有什么用」。
做了一个功能，但没人用——怎么办？
任何新功能上线后，给两周时间观察数据。然后问自己：
- 有多少人用了这个功能？ （如果低于 20% 的目标用户 → 可能入口太深、或这个功能不是刚需）
- 用了的人，完成任务的关键指标有变化吗？ （比如对账耗时从 15 分钟降到 5 分钟 → 功能有价值；耗时没变化 → 功能是摆设）
- 不用的人是「不需要」还是「没找到」？ ——不知道就去问
每次功能上线，你至少打 3 个电话给目标客户。
不是发问卷（回收率 3% 的问卷毫无意义），是打电话。
「我是 XX 的创始人。我想知道你为什么没用这个新功能——不是客套话，你告诉我真实原因，我才知道要不要继续做。」
自我审视的五个问题（每次做决策前问自己）
- 这个功能是解决了我的痒点，还是用户的痛点？ ——「这个 UI 动画好酷」是你的痒点；客户对账要 3 小时是她的痛点
- 如果我是目标用户，但是一个完全不同的身份（年龄/行业/技术水平），我会怎么评价这个功能？ ——试想你是 50 岁的财务、刚生完孩子回来上班的注意力有限的新妈妈、每天被销售电话轰炸的暴躁线长
- 我上一次和真实用户聊天是什么时候？ ——如果不是 7 天内，你已经在用自己的想象做产品了
- 有没有数据被我选择性忽略了？ ——注册率、留存率、某功能的使用率——你只看涨的那些，还是也看跌的？
- 我的产品能不能用一句话解释给出租车司机听？ ——如果不，说明你的产品定义还不够清晰
最后的话
做产品的人最容易犯的错，不是不懂技术，不是不懂市场——是过于相信自己的判断。
你以为你知道用户要什么。你以为你做了对的功能。你以为数据在替你说话。
真正的用户研究，不是验证你有多对。是找到你错在哪里。
每一次你发现「原来用户是这么想的」，都是一次 ego 的死亡。而每一次 ego 的死亡，都让你的产品更接近一个真正能帮到人的工具。