付费意愿是独立开发者最容易自我欺骗的环节。访谈时用户说“这个挺有用”，往往只是礼貌性肯定；真正决定项目成败的，是他是否愿意把真实资料交给产品、是否愿意在结果还不完美时先付一笔钱。验证付费意愿，本质上是在收集行为证据，而不是收集态度反馈。

访谈要追问已经发生的行为

把“你会不会用这个产品”换成对既有行为的追问：你现在怎么解决这个问题，每周花多少时间，最近一次发生是什么时候，这件事造成了什么损失，你为现有方案支付过多少钱，如果产品下周上线、什么条件下愿意付费。只有当对方愿意给出真实流程、样本数据或明确预算时，需求信号才算有效。泛泛的“有需求”不构成依据。

先用人工交付，再决定是否开发

冷启动阶段不必先建平台。更稳妥的做法是“人工服务加半自动工具”：用户提交需求，系统完成大部分处理，开发者手动检查并交付结果。这种方式效率不高，却能低成本回答几个关键问题——用户能否独立完成首次使用，是否在一周内再次回来，是否愿意把真实资料交给产品处理，以及流失原因究竟是价格、效果还是使用门槛。

判断信号时要分清层次。注册量和试用数说明曝光有效，不能说明付费意愿；愿意提供真实资料、愿意接受人工交付、愿意为一次结果付费，才是逐步升级的强信号。采用月订阅模式时，月费 199 元大约需要 252 个付费用户才能达到 5 万元月收入，499 元约 101 个，999 元约 51 个，这个估算尚未计入退款、折扣、欠费和税费，只能用于判断目标规模量级。

定价与成本必须放在一起算

AI 产品的定价不能只看服务器和模型调用，客服、退款、支付渠道、销售沟通、失败调用和人工审核都要计入。低价也不必然提升转化：如果用户真正担心的是结果不可靠，降价无法解决信任问题，反而会压缩后续迭代的余地。适合单人运营的收入结构通常是低门槛订阅、按量付费，或订阅叠加一次性配置与数据迁移服务，但服务占比过高时，产品会逐渐退化成外包。

达到收入目标不等于现金安全。模型费用、服务器、软件订阅、支付手续费、退款和税费都应单独记录，避免把流水当作利润。真正的验证顺序应当是：先确认一个窄而高频的问题，用人工交付验证付费，再让最小版本只跑通一条核心流程，获得首批付费用户后才考虑扩功能和加大获客。