correct more typos

hardhackerlabs · Apr 19, 2024 · dfb309d · dfb309d
1 parent f072967
commit dfb309d
Show file tree

Hide file tree

Showing 4 changed files with 5 additions and 5 deletions.
diff --git a/pages/build/llm.mdx b/pages/build/llm.mdx
@@ -108,4 +108,4 @@ podwise 的结构化 prompt 框架覆盖了如下一些内容：
 
 在开发 AI 产品的时候，不要纠结一步到位写好 prompt ，还是需要将重心放到完成整个业务流程和功能上。prompt 的编写也和代码一样，需要持续的迭代、优化。所以，需要好的 prompt 管理方式，方便持续的迭代、测试改进。
 
-在 prompt 不断的打磨，调试，并不是一件 roi 很高的事情，但有时候你又不得不做。
+对 prompt 不断地打磨，调试，并不是一件 roi 很高的事情，但有时候你又不得不做。
diff --git a/pages/grow/strategy.mdx b/pages/grow/strategy.mdx
@@ -12,9 +12,9 @@ Podwise 遵循 0 成本宣传策略，毕竟是白手起家，本身也没什么
 
 而低杠杆的平台比较适合做品牌和用户反馈，比如用户会下意识的去 Twitter、微博等平台找产品的官方账号，一方面看产品有什么最新的进展，更重要的是反馈问题等，而这些平台因为私信等功能其实还是比较适合做这样的功能的。所以对 Podwise 来说低杠杆的平台我们会主要做官方内容的宣发以及及时的问题反馈。
 
-总结一下，我们认为在前期我们最需要时通过论坛来做内容营销转化，有一定用户基础之后，再发力做品牌营销来巩固用户。
+总结一下，我们认为在前期我们最需要是通过论坛来做内容营销转化，有一定用户基础之后，再发力做品牌营销来巩固用户。
 
-我们再聊一下 ProductHunt 的 Launch，很多人把在 ProductHunt 的发布看的比较重，觉得能从这次发布中直接获取大量的用户，并借此获得不菲的营收。但其实往往是事与愿违的。因为 ProductHunt 网站的核心用户其实是产品经理和开发者，如果你的产品面向的用户是他们，那有可能，但大部分的产品其实是面向普通用户的，所以客群不匹配结果可想而知。而且现在 ProductHunt 因为这次 AI 产品的爆发，每天有大量的产品发布，而排行榜的日榜前三往往需要 800 票以上，这以自然流量转化到 upvote 上几乎是不可能的。所以最终发布在拼的其实不是产品力，而是人脉。对，ProductHunt 有很多 Telegram，Facebook，Linkedin 甚至包括微信的 upvote 群，如果你的发布没有这些群的帮助，那可能非常难排到前三。
+我们再聊一下 ProductHunt 的 Launch，很多人把在 ProductHunt 的发布看得比较重，觉得能从这次发布中直接获取大量的用户，并借此获得不菲的营收。但其实往往是事与愿违的。因为 ProductHunt 网站的核心用户其实是产品经理和开发者，如果你的产品面向的用户是他们，那有可能，但大部分的产品其实是面向普通用户的，所以客群不匹配结果可想而知。而且现在 ProductHunt 因为这次 AI 产品的爆发，每天有大量的产品发布，而排行榜的日榜前三往往需要 800 票以上，这以自然流量转化到 upvote 上几乎是不可能的。所以最终发布在拼的其实不是产品力，而是人脉。对，ProductHunt 有很多 Telegram，Facebook，Linkedin 甚至包括微信的 upvote 群，如果你的发布没有这些群的帮助，那可能非常难排到前三。
 
 说了这么多 ProduntHunt 的问题，那为什么还有这么多人冲着去发布。那是因为有很多 KOL，尤其是科技产品领域，因为制作内容的关系，他们会关注 ProductHunt 的日榜和周榜，并制作相关内容来获取粉丝关注，这就是 Producthunt 的意义。如果你之前发布过 ProductHunt，但却觉得没什么效果，那可能是因为你没有被他们说关注到。所以 ProductHunt 的意义并不是直接获取用户，而是通过日榜和周榜前三来获取 KOL 的关注，形成二次传播。这其实也是高杠杆的意义所在。
 

diff --git a/pages/launch/acquire.mdx b/pages/launch/acquire.mdx
@@ -11,7 +11,7 @@ title: 最初的 200 个用户
 
 - 一个是邮件的内容可能被当成 Spam 邮件或者被加入营销邮件的列表中，导致流失。
 - 另一个是我们对于邮箱召回的期待过高，因为毕竟会经历 收件 - 打开 - 访问 - 注册 四个步骤才能转化一个注册用户，而业界网站的访问-注册转化通常在 15%-30% 之间，举个例子：肯定有人刚看到 Landing Page 的时候觉得特别需要，但看到营销邮件的时候热情已经消退了，所以也就流失了。凑热闹的也肯定会有了。所以邮箱的的转化率肯定是不如 1:1 论坛转化的，从数据上来说也可以解释。
-我们在这次邀请之后，在 Amazon SES 上加入了邮件的追踪，用来计算转化率，更能数据化的分析用户到底在哪个环节流失了，推荐大家在是用邮件系统是时候都开启这个服务。
+我们在这次邀请之后，在 Amazon SES 上加入了邮件的追踪，用来计算转化率，更能数据化的分析用户到底在哪个环节流失了，推荐大家在使用邮件系统的时候都开启这个服务。
 
 但其实在我们获取用户的过程中还是犯了个错误，我们只关注了渠道的易用性，没关注渠道的契合性。V2EX 作为以开发者，产品经理为主要活跃群体的平台，本身与 Podwise 与播客听众并不是特别契合，我们当初之所以选择 V2EX 只是因为它对产品发布友好，如果重新再来一次的话，我们可能会选择在即刻的“一起听播客”群组和小红书招募用户，这样会用户群会更聚焦一些，然后对产品的帮助也会更大。
 

diff --git a/pages/review/fault.mdx b/pages/review/fault.mdx
@@ -4,7 +4,7 @@ title: 最不应该犯的错误
 
 如果有什么是我们最不应该犯的错误，那就是我们在定价的时候期望用信息差来赚钱。
 
-由于 Podwise 与 [Otter.ai](http://Otter.ai) 之类的产品有个很大的区别，Otter 是服务于会议场景，在会议的转录中，基本不太可能出现重复音频，所以 Otter 的转录时间是肯定会被用满的。但 Podwise 不一样，Podcast 的有很强的头部效应，所以热门节目只需要转录一次，就可以永远服务其他用户，而 Podwise 服务只需要转录一次，也就是利用一份资源消耗，赚取多份利润，这是 Podwise 规划盈利模型的基本逻辑。结果，在第一次测试的时候，多为用户直接提问，是不是你们会缓存节目的转录结果，下个用户来的时候就不用再次转录了。这里面产生了两个逻辑：有用户提说，如果是我转的，那我能不能哪后续的阅读分润？还有用户提另外一端，如果已经被转过的节目，我在学习的时候能不能只扣我 0.5 次。到这里我们才恍然大悟，做产品永远不能把用户当傻瓜，这是我们最大的错误。
+由于 Podwise 与 [Otter.ai](http://Otter.ai) 之类的产品有个很大的区别，Otter 是服务于会议场景，在会议的转录中，基本不太可能出现重复音频，所以 Otter 的转录时间是肯定会被用满的。但 Podwise 不一样，Podcast 的有很强的头部效应，所以热门节目只需要转录一次，就可以永远服务其他用户，而 Podwise 服务只需要转录一次，也就是利用一份资源消耗，赚取多份利润，这是 Podwise 规划盈利模型的基本逻辑。结果，在第一次测试的时候，多为用户直接提问，是不是你们会缓存节目的转录结果，下个用户来的时候就不用再次转录了。这里面产生了两个逻辑：有用户提说，如果是我转的，那我能不能拿后续的阅读分润？还有用户提另外一端，如果已经被转过的节目，我在学习的时候能不能只扣我 0.5 次。到这里我们才恍然大悟，做产品永远不能把用户当傻瓜，这是我们最大的错误。
 
 在接到用户的灵魂两问之后，我们也紧急讨论，最后决定将计费方式变更为：主动使用 AI 处理播客会扣除次数，但查看已处理过的节目则不扣除次数，并且 Podwise 平台会帮大家默认转平台上订阅 Top 100 的节目。从这个决定看，我们付出了巨大的代价，不仅无法利用播客的头部效应来降低成本，而且平台还默认转录内容当成大家免费的资源。在这之后，考虑到利润，我们只能寄希望于 ChatGPT 规模化降价以及 Podwise 自己的规模化盈利了。但没办法，我们不能通过惩罚客户来弥补自己的错误。