我的笔记里有一张表，记着这些年想过、做过、最后关掉的东西。关掉的原因几乎没有一条是”技术做不出来”。多数是做完之后没人用，或者有人在用，但没人愿意付钱。
每次回头看那张表，我都能认出同一个错误：我在还没确认有人要的时候，把系统做得太完整了。
我判断一个需求，先看有没有人在将就
大模型让”能做什么”这件事变得很便宜，于是最容易被跳过的一步是：这个需求现在是怎么被解决的。
我现在的第一个动作不是想产品，是去找那些”将就”的痕迹。论坛里有人发帖求一个工具，评论区有人手工代做，群里有人用一张 Excel 熬了半年——这些都是将就。将就意味着有人已经在为这件事付出时间或钱，只是付得不体面。
反过来，如果一个场景里没有人抱怨、没有代做、没有临时方案，只有我一个人觉得”这应该有人做”，我基本会放弃。不是因为它一定不成立，而是因为我教育市场的成本，付不起。
第二个判断是规模。太小的需求养不活，太大的需求一定会被平台顺手吃掉。通用写作、翻译、语法检查这类事，不是做不好，是做完之后随时会被某个系统级更新覆盖。我更愿意待在那条尴尬的中间带：大厂立项嫌小，一个人做又足够吃。
第三个判断比较主观：这件事有没有明确的使用终点。用户按下按钮，拿到一个能直接用的结果。如果我的产品交付的是”一个更强的对话窗口”，那它其实没有终点，用户要自己想办法把对话变成结果。这种产品的付费率通常很差，因为它卖的是可能性。
中间带具体有多宽，我一直没算清楚。我的感觉是按人群分，不按功能分：一个很窄的职业，配上一条很具体的工作流。窄到写行业报告的人一眼就知道这是给他的，宽到里面至少有几千个愿意为省时间付钱的人。这个估算方法很粗，但我没有更好的。
我删掉过一个自己很喜欢的想法。它解决的是我自己的一个真实麻烦，可我在任何社区里都找不到为这件事将就的人：没有人抱怨，没有人代做，也没有人在用某种土办法绕过去。这说明麻烦只在我这儿成立。我把它留在笔记里，隔几个月看一眼，到现在还没动。
MVP 的重点是砍，不是建
我第一次做的时候，花了三周做登录、找回密码、用户中心、历史记录。上线那天我很满意，然后发现前十个来试的人里，有六个在看到注册页的时候就走了。
那之后我改了一个很粗暴的规则：第一版不登录。状态存在浏览器里，服务端按 IP 记次数，用完就弹支付。这个方案在技术上不优雅——用户换设备就丢了记录，清缓存也会丢——但它把从”打开”到”看见结果”的距离缩到了一屏。
砍掉的东西我列过一张单：多模型切换、历史归档、分享海报、深色模式、多语言。每砍一个，我都会心疼一下，因为那些是我会做、也做得出来的东西。但心疼归心疼，它们对”有人愿意付钱吗”这个问题一个都答不上来。
我也砍过功能之外的东西：不写自定义 CSS，不自己搭鉴权，不自建服务器。这些决定让我后来在技术上有点被动——样式受组件库限制，鉴权出问题只能等平台修。但换来了两周上线。对一个还没验证的东西，两周和两个月是两个物种。
第一版让人觉得拿不出手，通常说明砍得还不够。
有个细节我坚持了很久：支付链路要在第一版里。不是为了收钱，是因为没有支付入口，我永远不知道自己在做的是产品还是练习。有了入口，哪怕一天只有一单，我也能拿到一个真实的信号：有人愿意用钱交换这个结果。这个信号比一百条”做得不错”有用。
第一版我明确接受了一堆技术债：所有逻辑挤在几个文件里，没有测试，日志靠打印，出错就靠我肉眼看。我知道这些东西将来要还，但那时候更需要知道的是有没有人愿意付钱。真正让我难受的不是欠债，是三个月后回来还债时，我已经看不懂自己写的东西了。所以现在我会留一条底线：数据结构和支付回调必须写清楚，其余的可以先糊。
定多少钱这件事，其实是同一件事的另一面。太低，来的人不认真，客服成本反而高；太高，还没验证就先劝退了所有人。
我试过按月订阅，效果很差。工具类产品大多不是每天用的，用户月末看一眼账单，就会开始怀疑自己为什么要付这笔钱。后来改成买断或者按次，退订率立刻好看了，因为它和”我需要做这件事”对上了，而不是和”我需要一直做这件事”。
免费额度我也调过几次。给太多，我的 API 账单先撑不住；给太少，用户还没走到那个”原来它可以这样”的瞬间就用完了。现在的做法是让免费额度刚好够完整跑通一次真实任务，第二次就开始收费。粗暴，但清楚。
我还在犹豫要不要涨价。按成本算，现在的价格撑得住；按价值算，它替用户省下的时间远超这个数。可涨价这件事对一个没有品牌的小工具来说，风险不在转化率，在口碑。我暂时没有动。
合规和平台依赖，是两道真实的墙
写代码这件事，现在反而是整条链里最简单的一段。真正会让人停在半路的是另外两件。
一件是合规。国内做生成式内容的产品，上架时要面对的不只是应用商店的审核，还有算法备案这一层。个人主体在很多环节上走不通，时间成本也不是一个人能随便承担的。我见过有人把审核当成运气问题，反复提审、反复被拒，最后项目就死在这上面。
我的做法不聪明，但省事：底层用已经备案的模型，产品里把”内容由 AI 生成”标清楚，不去碰自己解释不了的能力边界。真要长期做，就先在海外跑，等有现金流了再回来处理主体和备案。这不是什么高明策略，只是承认自己付不起那个成本。
也有人走另一条路：提审时把 AI 功能藏起来，过审之后用远程配置打开。听起来像是省了一整套手续，实际是在赌没人巡查。这类事的后果不是这次被拒，是主体和域名一起进黑名单，之前积累的全没了。我不会拿这个赌，不是因为我更守规矩，是因为我输不起。
另一件是平台依赖。每次模型厂商开发布会，我都会有一阵不安：如果它顺手把我做的这件事做了，我剩下什么。这个问题没有技术答案，只能靠位置回答。我做的事情如果只是”把提示词包一层”，那确实没有剩下什么。
护城河在业务里，不在模型里
我不相信一个人的产品能在模型层面建立优势。算力、数据、人才都不在同一个量级上，硬碰是浪费时间。
能积累的东西在别处。一个是流程：用户不想和 AI 聊天，他想要一个按钮，按下去之后自动完成抓取、清洗、生成、导出这一串动作。把这一串串起来，交付的就不再是”AI 能力”，而是一个省事的工具。别人要复制，得把这一串重新走一遍。
另一个是领域里的私有细节：某个行业的模板长什么样，哪些词不能用，报表的格式有什么约定。这些东西不在公开语料里，模型不会自己知道，只能靠一个个用户教出来。
还有一个最容易被忽略的：界面。聊天框是万能的，也是最难用的。把提示词换成几个滑块、一个画布、一张符合行业习惯的表单，用户的学习成本会降一大截，迁移成本会涨一大截。这件事不酷，但它有效。
我对”沉淀私有数据”这个说法一直有点保留。理论上很对，实际上大多数小工具根本攒不到足够的数据，攒到了也未必用得上。一个用户一周用三次，一年下来也就那么点记录，做不了训练，做检索也显得勉强。真正攒下来的是更软的东西：用户反复改的那几处、客服被问得最多的那几句、他绕开我的产品去做的那一步。这些不进数据库，但会变成下一版的设计。
所以我不太愿意把护城河说得太实。它更像是一层层加厚的理解，而不是一道能画出来的墙。别人要抄，抄得走界面，抄不走我为什么把那个按钮放在那里。
获客我没什么秘诀。写解决具体报错的文章，在目标人群聚集的地方回答具体问题，把开发过程公开出来。这些动作都很慢，慢到让人怀疑有没有用。买量我试过一次，几百块钱换来一堆注册和零付费，之后就没再碰。
那些”一次发布就爆”的故事，我后来不太信了。一次性的大流量对工具类产品没什么用，来的人当天看看就走，留下的数据难看，还容易让我误判。真正撑住一个产品的，是几十个入口在很长一段时间里持续带来的人：一篇两年前写的问题解答，一个被别人转发的截图，一个同类工具推荐列表里的自然出现。
有些判断我还没有把握。
比如”一个人”这件事，到底是优势还是阶段性的限制。一个人决策快、成本低、能贴着用户改，但遇到需要资质、需要信任、需要线下的时候，一个人就是天花板。我现在倾向于把它当成阶段，而不是信仰。
比如融资。拒绝融资听起来很硬气，但它的前提是产品本身能产生现金流。如果做的是一个需要长期投入才有回报的东西，这套逻辑就不成立。我不认为”不融资”比”融资”更正确，只是对我做的这类小工具，资本进来之后要的增长速度，会把我逼到做我不想做的功能上。
销售这件事也一样。我没有销售，也不打算有，但”不招销售”不等于”不需要被介绍”。我只是把那件事拆成了自己能做的部分：把说明写清楚，让产品本身能在一分钟内被看懂，把每一个新用户的问题都当成文档缺口。这套东西的效率远低于一个会打电话的人，好处是我不用为了养活一个销售去定更高的价。
那张表我还在往里加。最近一条是三个月前关掉的，原因写得很短：能做，但没人等。这句话现在是我最常用的过滤器。
评论