开始开发前，最难判断的是用户会不会为一个足够频繁的问题改变现有做法。一次称赞、点赞或表单填写都可能是好信号，但还不足以决定投入数周开发。
这篇文章提供一套低成本的验证流程。它不承诺你能预测市场，也不把访谈次数写成公式；目标只是让你在写大量代码之前，获得足以支持“继续、转向或停止”的证据。
写下要验证的假设
“给设计师做一个 AI 工具”不是假设，无法被验证。好的假设同时包含人群、情境、现有替代方案和可观察行为：
独立站运营者在每次商品上新前，要花 30 分钟检查图片、文案和链接；他们目前依赖一份分散的表格；若能把检查缩短到 5 分钟，愿意把真实店铺数据交给一个试用工具。
把它拆成四张假设卡：
| 假设 | 需要的证据 | 常见误判 |
|---|---|---|
| 问题存在 | 对方能讲出最近一次发生的具体经过 | “听起来会有这个问题” |
| 问题优先级高 | 对方已经花时间、钱或人工绕开它 | 把抱怨当作购买意愿 |
| 你能触达这群人 | 能找到重复、合规的触达渠道 | 只靠朋友转发 |
| 方案值得交换 | 对方愿意预约、导入数据、试用或付费 | 点赞、关注、泛泛夸奖 |
每张卡都要有失败条件。例如：连续十次符合画像的访谈中，没有人能回忆近三个月的真实场景，就暂停该问题；不是继续给落地页换颜色。
访谈时还原过去的行为
最有价值的问题通常指向过去发生的行为。与其问“你会不会使用自动检查工具？”，不如按顺序问：
- 最近一次处理这件事是什么时候？从头讲一遍。
- 当时谁参与、用了什么工具、花了多少时间？
- 哪一步最容易出错？错误的后果是什么？
- 你已经试过哪些替代方案？为什么没有继续用？
- 如果下周还要做一次，你会如何处理？
得到许可后，记录原话、现有流程截图或匿名样本。不要急着展示原型；一旦你开始介绍方案，对方往往会礼貌地帮你找优点，访谈就从发现问题变成了产品演示。
一个足够轻量的访谈记录
每次只记录可比较的信息，避免把印象写成结论：
受访者画像：1 人运营、每周上新 2 次的独立站店主
最近事件：上周五上新，因失效链接延迟 4 小时
当前替代：Notion 清单 + 人工点击
成本：约 35 分钟；错过邮件推广窗口
原话： “我不怕多一个工具，怕每次还要重新配置。”
承诺：愿意下周用 3 个商品做一次试用
反证：认为这只是旺季问题，平时不需要访谈结束后再写“证据强度”：对方描述的是发生过的事实、正在进行的替代动作，还是对未来的善意猜测。不要把不同强度的信号混在一起统计。
逐步提高验证成本
验证不是二元的“有人感兴趣/没人感兴趣”。从低到高排列承诺，能避免过早收费，也不会把邮箱列表当成收入证明：
- 愿意花 20 分钟复盘真实流程；
- 愿意留下可再次联系的方式，并约定具体时间；
- 愿意拿自己的低风险样本试用；
- 愿意邀请同事或替换现有步骤；
- 愿意支付、签试点约定，或接受明确的预售条件。
前几级只能说明问题值得继续调查。只有后两级才接近商业信号，而它们也不代表产品已经具备规模化获客能力。
用“人工交付”测试价值，而不是伪装自动化
如果你还不能做完整产品，可以先做一个边界清晰的人工服务：用户提交数据，你在约定时间内给出一次诊断或结果。前提是坦诚说明人工环节、数据保存时间和不适用场景。
人工交付能回答两个关键问题：结果是否真的被使用，以及哪一步最值得自动化。它不能替代产品化——当每位用户的需求都不同、无法形成重复流程时，得到的可能是服务型业务信号，而非 SaaS 信号。这同样是有价值的结论。
用落地页测试信息是否清楚
落地页适合检验你能否把问题说清楚。它至少应包含：目标用户正在经历的情境、可交付的结果、不可做的事、下一步动作和隐私说明。不要虚构客户 Logo、倒计时、名额或“已有数千人使用”。
比起总访问量，优先观察一条完整路径：用户从哪篇内容或社群帖子进入、是否读懂对象与结果、是否完成某个有成本的动作、之后是否按约出现。为每条渠道保留来源标签，但不要在验证期就堆叠大量第三方追踪脚本；隐私优先的产品分析会讨论如何定义最小事件集。
记录继续、转向或停止的依据
建议每周固定 30 分钟更新证据账本，而不是凭感觉累积兴奋感：
| 结论 | 支持证据 | 反证 | 下一步 |
|---|---|---|---|
| 上新检查值得做 | 4 位访谈对象都能复述近期错误 | 其中 2 位只在旺季发生 | 为高频人群做人工试用 |
| 自动修复有价值 | 1 位愿意导入真实数据 | 其他人更在意清单模板 | 先验证结果页，不做修复引擎 |
为下一轮设一个最小决策门槛：例如，“若三位符合画像的试用者在同一周内完成第二次使用，则实现可复用上传流程；否则回到问题拆分。”门槛可以调整，但调整前必须记录原门槛为何失效，避免事后移动球门。
常见误判
把熟人赞美当样本。 熟人适合帮你发现表达不清的地方，却很难代表陌生用户的付费取舍。把他们与目标用户分开记录。
为每个异议增加一个功能。 异议可能说明定位错误、信任不足或根本不痛。先分类，再决定是修改信息、增加保障，还是放弃该细分人群。
把“还没有时间”理解为“稍后一定会买”。 没有约定具体下一步的积极反馈，证据强度通常很低。礼貌地结束并继续寻找更强信号。
开始开发前的检查
- 目标人群和触发情境可用一句话描述。
- 至少记录了问题发生过的实例与现有替代流程。
- 明确了哪种行为才算有效承诺。
- 记录过反证，而不只保留支持想法的反馈。
- 下一版只自动化一个已被验证的高成本步骤。
- 对数据、人工流程和试用限制做了诚实说明。
验证的终点不是证明想法“必然成功”，而是把下一笔时间花在最值得学习的风险上。确认存在重复、紧迫且可触达的问题后，再进入定价设计；下一篇《SaaS 定价：先定义用户能理解的计费单位》会从“用户愿意交换什么”开始，而不是从竞争对手的价格表开始。