产品定位要和用户的付费动机挂钩，这样的生意才会变得性感。

常见的3种付费动机：

1. 新增收入型（赚钱型）
- 用户因为使用你的产品而获得新的收入
- 例如：效率工具让他多接项目、营销工具带来更多客户
- 用户心理：投资回报率导向，愿意为增值付费
- 定价逻辑：可以按价值定价，甚至收益分成

2. 成本节省型（省钱型）
- 用户原本要花的钱，因为你的产品而减少了
- 例如：团购、比价工具、替代方案
- 用户心理：精打细算，对价格敏感
- 定价逻辑：必须明显低于替代方案

3. 消费预算型（花钱型）
- 从用户的娱乐、生活品质等消费预算中来
- 例如：游戏充值、视频会员、知识付费
- 用户心理：情感价值、体验导向
- 定价逻辑：参考同类消费品，注重心理定价

细拆的话，每一种动机都有很多case，2b和2c也有些许差异。

比如：同样是在线教育：
- 职业技能培训就是赚钱型，因为学了能涨薪
- 线上学科辅导就是省钱型，因为通常比线下便宜，有性价比
- 兴趣爱好课程就是花钱型，为的是个人满足感，讲的是让用户成为更好的自己

不管具体形式怎么变，最根本的就一点：客户的钱不是凭空来的，他们总有一些心里预期，而产品的价值呈现，就是去打动这个心理预期。

分享一个用claude画图的小技巧

claude做前端网页真的很擅长，可用性很高。但经常会遇到一个问题，那就是它所有的图标会默认直接用系统的emoji，有些和网页风格不搭的话，看起来就很丑，如图1。

而web开发里，其实有非常多好看的图标库，在iconfont里就能看到很多。

那么，只要让claude从第三方图标库里取就好了，提示词可以很简单，比如：

“我希望你不要用mac自带的emoji，而是去iconfont之类的平台上调用web的图标”

然后就得到了图2，claude调用了开源的Lucied React图标库，一下子就好看了很多。

硬核创业之前，不妨先学会做一些小生意

创业故事听多了的打工人，往往会有一种错觉，认为创业一定要特别有技术含量才是好的，一定要做当下最时髦的才有价值。

于是订阅的资讯全是各种“炸裂”的技术或产品进展，关注的都是“追求极致”的创业者大佬，学习的尽是非常先进的“硅谷”方法论，心里只觉着“改变世界”才有意思……

然而，现实是，很多人从来没有自己卖过货，从来没独立成交过哪怕1块钱。一上来就想学时代最先进的打法，步子迈得无比大。

结果往往连一个生意人最基础的思维都没有，典型的表现是：
- 不好意思开口找客户要钱，也不敢问客户为什么不掏钱
- 觉得自己做的东西没什么“技术含量“，所以不配收钱，同时觉得别人那些没技术含量的都是智商税，都是在卖给傻子
- 不敢叫卖自己的东西，觉得读书人做小生意太丢份，心里想着“我是来改变世界的，不是摆摊的”

如果还在这个段位，最重要的，不是fomo到害怕自己错过百亿级的大机会，而是先突破内心的障碍，先对最基本的人性好恶有感觉。

这个时代，讲技术的很多。社交媒体一打开，铺天盖地的都是让人学技术技能的课程，什么cursor的100种用法、什么AI办公自动化技术、或者小红书爆款笔记方法论等等。

但是吧，技术越学得多，越只有打工的份。因为出发点就错了。

同样是面对前段时间爆火的吉卜力风格头像：
- 打工人会想，哪里有教程，我也想学；
- 生意人则会想，我有没有认识的人会画这个，我能不能找到足够多的买家，然后怎么把买方和打工人串起来收钱。

结果呢，打工人就是又学会一项新技能，而生意人已经小赚了一笔并落袋为安。

看到了吗？生意人不会纠结“我自己不会做”，只关心怎么把买卖撮合起来。

当然了，这也不是说技术不重要。做小生意当然可以不掌握技术，但如果要做大做强，长久发展，终归是要把核心技术拿在自己手里的。不然被供应链卡一下脖子，生意可能直接就挂掉了。

但这是发展起来之后的问题，发展之前，不用纠结。

不懂技术可以外包，不会卖货就只能大龄毕业。先让自己成为一个能把东西卖出去的人，任何宏大的梦想，才有落地的可能。

世界很大，赛道很多，但真正能给你信心的，永远是一张张进账的收据。别怕小，先赚到 100 块，然后 1,000、10,000……台阶就在脚下，往上爬的时候再慢慢升级技术，也完全来得及。

所以，别再泡在一篇又一篇的创业故事或访谈里干巴巴焦虑了，走出去，卖卖货，体会一下真实的“人-货-场”，感受一下真正的现金流。

当收到第一笔钱之后，你就再也不是只会转发“创业干货”的人了。

千呼万唤始出来，TextIn文档解析已正式上架Dify插件市场，为广大dify用户提供最一流的文档解析体验，支持更快速、更稳定的非结构化文档处理，让大模型应用搭建更轻松。

详情见marketplace.dify.ai

感谢上架过程中提供支持与帮助的dify团队~
​
​

当做出了一个还有些结果的产品从0到1之后，再做第二个，就会更加有手感，也对之前看过的各类方法论开始有了融汇贯通之感。

以定性访谈为例，一个产品从无到有，变成MVP，通常有4批次访谈：

1、了解用户问题

这一步就是了解「圈定的用户」对现状有哪些不满意、不舒服。这些困难或麻烦，往往就是新的机会。

但要做产品，光是知道问题还不够，重点是发现「共性问题」。不然全是零散的问题，永远也不可能孵化出一个成熟的产品。

怎么判断有没有找到共性问题呢？

很简单，把从一个用户那里了解到的问题，问另外一些人，如果有一定比例的人都有共鸣，就说明是有普遍性的了。

2、概念验证

了解到共性问题之后，就要开始做产品的概念设计，也就是所谓的「核心特性」、「价值主张」等等。

比如拼多多早期的核心特性就是便宜、cursor主打的就是优秀的上下文管理。

每个产品，都是在解决一类用户的特定诉求。而这些问题的解法，通常不只有一个，因此需要定义清楚。

当定义了一个正确的价值主张之后，再去问用户，通常就会得到：“对对对，这就是我想要的”之类的回复。

3、解决方案验证

确认了产品的核心特性，接下来就是想办法快速做一个原型，然后让用户去试，看我们的解决方案，是不是真的能解决他们的问题。

每一个产品都有自己的架构，即使按最简单的分类，也有前端交互体验和后端能力。

每一块都有不同的设计点，比如前端是用web还是用小程序，后端是实时接口还是异步接口等等。产品设计，就是找到一个相对最友好的组合方式。

然后，再拿着这个原型，去找用户体验，看他们会不会用。

如果这一步也做对了，通常就会有“什么时候正式上线”之类的回复。

4、完整MVP验证

解决方案验证通过，说明产品不仅有机会，也说明初步做对方向了。接下来，就是补全一个产品应有的全部，变成一个小而完整的东西。

这其中，最需要补齐的就是「价格」。

虽然网络段子里经常有：“20万的雪铁龙C6老气横秋，12万的C6成熟稳重”，但“价格本身就是产品的一部分”，这个观念也是在有实操经验之后才真正有深刻体会。

更重要的是，有了定价，才有机会真实地看到用户买单的卡点。不然前面一直你好我好大家好，就容易以为已经做得很好了。

嘴巴可以骗人，但钱包不会。

如果用户不掏钱，那就正好去更深入地了解他们为什么不愿意买单。是太贵了，还是什么别的。

只有当圈定的那些用户里，真的有一批开始掏钱之后，才算是真正做出了一个完整的MVP。

---

最后，上面这些环节也不是完全死板的，可以根据实际情况合并或调整细节。但大体上，一个产品做到MVP，都离不开这几步。

希望不久的将来，可以用自己的产品案例做分享。

就是这个感觉，不可明状的“洞察力”也是可以拆解出来的，变得可理解，可练习

claude 4，一小时写出可用的api使用说明文档

最近在测试claude 4的能力边界时，整体感受已经是有不错能力的大学生水平了，但还不能独立做出可交付的结果。

分享一个测试的case。

我们在做的是API产品，经常能接到用户咨询各种接入问题，有时候还挺刁钻，挺定制。因此就想写一系列的使用帮助文档，免得人工一次次服务，最终没有任何沉淀。

之前也想搭一个chatbot直接帮助用户，但测试下来发现，LLM对api文档和响应结果的理解，仍然不到位，很多时候是错的。

于是只能退而求其次，先把使用文档写好。

这次用了claude做的augment插件，在vscode里装好就能用。以下是测试记录：

1、简单体验

首先放了平台的示例代码和API文档，然后给了一个提示词：

“文件夹下是textin产品的可调用示例代码和接口文档，请你从一个专业的技术内容运营的角度，帮我编写一些功能详细介绍文章，让其他人更加懂得如何使用这个api。文章里至少要包含：场景、问题拆解逻辑、示例代码、类似的问题，以及其他你觉得需要有的润色内容。
第一个功能点：如何将文档中返回的表格保存为图片？背景是，dpi不同，则返回的坐标不同，我应该怎么写这个代码？”

然后它就完全基于自己的理解，编造了json数据，代码也是瞎写。无奈，只好再增加信息。

2、限定AI的处理逻辑

这次我用了更加格式化的提示词，如下：

“我需要你对每个代码做完整的调用结果验证，确认是真实可用的。另外，我希望这个技术文档生成作为一个通用的任务，请帮我生成一份标准的提示词文档。再补充一点，在textin API的返回结果中，是有每一页的长宽信息的，你可以对照文档再看看。

因此，我希望的工作模式是：
1. 你先理解问题，然后理解api文档，并且对典型的json结果有了解
2. 根据用户的问题，梳理解题思路
3. 写代码并验证效果，如果有问题的，要修复，直到代码都可运行
4. 整合所有信息，生成一篇生动详实，有图有料的技术说明文档，类似于cookbook”

结果它仍然是用了自己编造的数据，好像不明确告诉它可以调用真实代码获取真实数据，它就不可以这样做一样。

没办法，我只好继续明示它。

3、明确让AI调用真实接口

这次，我不再让它自由发挥了，直接说我的思路，让它帮我实现，相应的提示词改成了：

”你的思路不太对，或者还是不够理解api文档。

首先，可以通过get_image=page，来获取页面图片，其中image_output_type控制了不同的图片返回形式，可以是base64, 或者image_id，两者都是可以写代码处理的，你需要讲解出来。

其次，在接口返回的图片基础上，只要有表格的坐标就可以执行截图操作了，而这也是接口会返回的。因此你不需要自己重新算一个裁剪范围。”

这次它终于能去发起真实请求，而不是自己瞎编一个数据了。

但它运行过程中，却跟我说没有获取到页面图片，并且想改代码重新请求。我直接就中断了它。

4、最后一次建议

在中断之后，我重新排查了一遍是否真的没有返回值。在看到有内容之后，我和它说：“你错了，json里已经返回了base64图片，在1713行，不需要你重新调用了”

然后，claude真就给到了惊喜！

在它的输出结果中，连续5个”太好了、太棒了、完美、太棒了、完美“，就好像是一个活人一般，在表达他把api调试成功的兴奋。

最后也真的实现了一个完全测试通过的代码，并输出了一份勉强可用的cookbook。

附图说明
- p1: 当claude真实调用接口并处理成功时的兴奋
- p2: 它自己理解的任务模式，确实完成得不错
- p3: 最终生成的cookbook示例
- p4: 待处理的示例文件，以及claude写的代码成功提取的表格图片

5、总结

即使是当下最先进的模型，也很难理解一个已有业务，它需要更多的上下文信息。但模型的进步真的很快了，在去年这个时候，想要1个小时就从0搭出一个可用、被验证过的文章，基本是不可能的。而现在，已经成为现实了。

现阶段，模型还是不能够自己闭环一个相对综合的任务，需要更多指导和在旁边的监督。这也要求监督的那个人，必须要比模型更懂这块具体业务才行。

但即使是现在这样子，效率提升也是巨大的。

以前写这样的技术文章，从写代码测试到文章组织，还需要研发与内容分工配合，一周能写2～3篇就算很高效了。而现在，1个人，1～2个小时就能出一篇，一周5个工作日，能写20多篇。直接就是10倍效率提升。

在费用方面，干这样一次活，大概要10次对话，而augment一个月50美金，不到400块钱，可以有600次对话，能干60个这样的活。性价比高极了。

时代，真的变了。

带产品团队之后，每天都能接到各个团队的各种需求：
- 投放侧想要加新的落地页；
- 增长侧想把seo做好；
- 运营侧想调整用户路径；
- 商务侧想推新的商业计费逻辑；
- 售后想要解决长期的bug，提高效率；
- 财务想要更方便地对账，减少人工；
- 设计觉得某些页面太丑，不协调，想要换掉；
- 研发侧有技术债要补；
- 产品自己还有主线的产品优化任务；
- ……

这么多的需求，如果不挡，不排序，整个产研团队就会疲于奔命。结局只会是又累，又没有成果。

合作方提需求，通常有2个特点：

其一，每个合作方都有自己的kpi，从他们自己的视角来看，他们提的需求都是紧急重要的，都需要尽快做好上线：

其二，每个人通常都想做一个完整的优化方案，并不会考虑研发难度和成本。

而资源总是有限的，没可能把每个人的需求都服务好。

于是，一个合格的产品leader，必须具备两个能力：

1）对业务发展方向有清醒的全局认识，能判断当下的前进方向是什么；
2）能摆平冲突，即使拒绝需求，也要让别人理解甚至支持。

这其中，最关键的还是业务判断力。

做100个无关痛痒的需求，对结果的贡献，往往都不如做对一两个需求。因为一个阶段只会有一个主要矛盾，不可能所有事情都同等重要。

就比如，当整个转化率明显在付费环节有大的跳水，那做流量增长就不会有本质上的改变；

又或者，当产品推出去，10个人里只有1~2个人能真正用明白，那么继续堆新功能也不会有太大的用处。

格鲁夫在《给经理人的第一课》里，提到了“杠杆率”的概念，最近慢慢对这个有了更深的体会。

所谓业务判断，就是把资源投在杠杆率最高的事情上，而杠杆率最高的事，就只会有一个。

所以，越是事多的时候，越要头脑清醒，保持冷静和专注。

之前在增长概念里，一直对变量控制、显著性、实验严谨性没有太切身的体会，但经历过一次错误归因后，就清醒多了。

最近一个实验里，目标是提升用户的API接通率，接到的用户反馈经常都是不会写代码，不会配参数，所以我们做缩短路径，丰富示例代码，简化参数等等功能。

做了这些改动之后，因为用户体量并不太大，所以选择了按时间序列来对比，也就是观察全量上线前后数据是否能显著变化并稳定下来。

发现第一周数据明显增长（环比+50%）的时候，我们自然而然地认为策略是有效的。直到第二周和第三周的数据逐渐降低，和策略上线前一样，这时重新去分析，才知道没做扎实。

原来之前的增长，只是流量变化带来的假象。投放调整，让一些低转化率的用户减少了，自然而然显得整体转化率变高。但同一来源的用户组，每周的转化率并没有显著提升，仍然在波动，就说明不能得出实验策略有效的结论。

以下是本次的踩坑笔记。

1、增长实验里，基础是控制变量

很多时候，我们以为自己严格控制变量了，但实际上并没有，尤其在产品早期，样本量比较少的阶段。因为样本量少，通常的选择都是按时间来对比，而不是严格做A/B测试。

然而时间本身就是一个变量，更不用说当前链路还有一些主动调整动作，那变量就更多了。

所以市面上的增长方法论里，才会有一条经验：样本量少的时候，时间序列是有效的，但可能要ABAB，或者ABBA之类的连续对比才能更好地排除时间干扰。

2、即使是小样本情况，也要对实验所需样本量有基础的概念

这其实是统计显著性的需求，就跟做物理化学实验一样，越是微小的区别，就越需要更多的重复实验才能明确是否有统计上的显著差异。

有一个网页计算器（www.evanmiller.org）
给定当前的转化率基线，给定预期提升的幅度，就能算出达到通常显著性所需的样本量。

比如基线是5%，预期相对提升50%，那所需样本要1273个。而如果每周的用户量只有200，理论上就需要6周的积累，才能真的说是否有效。

有这个概念，就能避免一些半场开香槟的操作。

同时，受限于样本量，早期团队的重心就要放在那些更容易带来明显变化的改动上，做那些肉眼可见的变化，甚至是做10x的变化。而不是去纠结几个百分点的变动，因为一次随机误差，可能就覆盖了这几个点。

也因此，早期多做定性访谈，很可能比定量实验更管用。

3、数据分析要扎实严谨

这跟前面两点有所关联，但更本质的，是需要严谨的态度。

比如这次虽然前端没有控制好变量，但在分析数据时，完全可以只看相对受干扰更少的渠道来源的用户变化，而不是混在一起看全量。

最后，所有的得失和经验，都最好沉淀下来，要有所收获，有所进步。每踩一个坑，就在地图上插一面小旗，终有一天，这些小旗会成为通向确定性的路标。

TextIn-文档解析-全新支持excel表格🎉

主要功能：
- .xlsx文件一键转markdown，更便于大模型理解
- 支持多sheet识别，每个sheet最大支持2000行文件
- 前端提供与表格编辑器同样的交互体验，支持行列定位，可切换sheet

尤其适用于搭建日常电子表格自动化处理的场景，比如将不同来源的excel都进行理解，让大模型提取数据，再录入erp系统，省去手工录数据的麻烦。

完整功能欢迎前往（www.textin.com）体验～