hardhackerlabs · anson0370 · Apr 19, 2024 · Apr 19, 2024 · Apr 19, 2024
diff --git a/pages/build/buildstack.mdx b/pages/build/buildstack.mdx
@@ -47,7 +47,7 @@ Remix 看起来是一个不错的选择，但它的 action 将一个页面的所
 
     Go 比 Python 可以消耗更少的资源。如果你有 “白嫖” 过 AWS 的免费 EC2，你会发现这些免费的 ec2 只有 1vCPU 和 1G 内存。cpu 其实还好，毕竟作为独立开者新发布的产品，可能也没多少人使用，也没什么流量；但 1g 的内存极有可能会是一个硬伤，1g 内存被操作系统占用后，剩下给到你的也就是只有几百兆了，这远低于我们今天使用的笔记本电脑，像 python、java 这类带虚拟机的编程语言，一启动就可以占用上百M、甚至几百M 的内存，所以 1g 的 “白嫖” ec2 总体来说是捉襟见肘的。
 
-    Go 语言在这方面的表现就是非常优秀了，轻松把内存稳定控制在几十M 内，只要我原意做，控制在十几M 也不是不可以。
+    Go 语言在这方面的表现就是非常优秀了，轻松把内存稳定控制在几十M 内，只要我愿意做，控制在十几M 也不是不可以。
 
     资源就是成本，是钱。作为独立开发者或startup，我们可以不在意编程语言的性能，但不能忽视资源消耗的多少问题。特别是刚起步的时候，能够让你的产品轻松的部署在任意环境，节省每一分钱都是有意义的。
 

diff --git a/pages/build/llm.mdx b/pages/build/llm.mdx
@@ -53,7 +53,7 @@ Podwise 的整个 AI 后台服务主要由两条工作流驱动完成：
 
 三：LLM 总结流程中的并发设计，涉及到了这样的几种模式（在 langchain 中也有这样的概念）：
 
-- 序并发：就是可以将多个任务提交给 llm 后，返回的结果不需要任何顺序。
+- 无序并发：就是可以将多个任务提交给 llm 后，返回的结果不需要任何顺序。
 - 有序并发：将多个任务提交给 llm 后，返回的结果必须根据业务需要排序的。
 - 完全串行：就是多个任务只能串行，一个一个的执行，往往前一个任务是后一个任务的输入。
 Podwise 将第三种串行执行这种模式提升到了工作流上完成控制，所以工作流是先做章节总结，然后做全文总结，最后是 mindmap。在工作流一个节点内部，大多数对 llm 的调用都是由无序或者有序并发模式组成的。
@@ -66,7 +66,7 @@ prompt 一般有两种形式：结构化 prompt 和对话式 prompt。
 
 结构化 prompt 的优点是通过规范的结构把任务介绍得很清楚，缺点就是往往很长，比较复杂。而对话式 prompt 更加简单，更符合日常的说话习惯，缺点是难以一句话描述清楚任务，最后得不到满意的结果，需要进行多轮对话才能获得最终结果。两种 prompt 都有自己的适合场景，结构化的 prompt 更合适用来内置到产品工作流中，由开发者编写、维护，podwise 采用的就是这种复杂的 prompt 形式。对话式 prompt 就合适用在 chat bot 场景，直接由用户发出。
 
-1. **结构 prompt**
+1. **结构化 prompt**
 
 podwise 的结构化 prompt 框架覆盖了如下一些内容：
 
@@ -92,19 +92,20 @@ podwise 的结构化 prompt 框架覆盖了如下一些内容：
     - 输出格式使用简单的 markdown 语法，自己解析 markdown
     - 借助编程做好容错处理
 
-1. **prompt 管理**
+2. **prompt 管理**
 
 我们采用模板技术来定义 prompt，然后通过模板变量去控制 prompt ，比如多语言等。使用模板来管理 prompt 后，就不需要为不同的情况都写一份 prompt，只需要抽象好 prompt 模板 + 模板变量即可。
 
-1. **prompt 测试**
+3. **prompt 测试**
+
 - OpenAi playground
 - Google AI Studio
 - https://promptknit.com/
 
 在调试 prompt 的时候，温度（temperature）应该是最常用的一个选项。也就是设置不同的温度，可能会得到不同的效果。像总结文章这种需求，需要基于原文的事实，那最好是温度设置低一些，倾向 0 都可以。温度设置得很高，大于 1 ，LLM 就会更大概率做自由发挥了。还是看自己的业务场景，以及更多的测试。
 
-1. **prompt 迭代**
+4. **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,8 +11,8 @@ title: 最初的 200 个用户
 
 - 一个是邮件的内容可能被当成 Spam 邮件或者被加入营销邮件的列表中，导致流失。
 - 另一个是我们对于邮箱召回的期待过高，因为毕竟会经历 收件 - 打开 - 访问 - 注册 四个步骤才能转化一个注册用户，而业界网站的访问-注册转化通常在 15%-30% 之间，举个例子：肯定有人刚看到 Landing Page 的时候觉得特别需要，但看到营销邮件的时候热情已经消退了，所以也就流失了。凑热闹的也肯定会有了。所以邮箱的的转化率肯定是不如 1:1 论坛转化的，从数据上来说也可以解释。
-我们在这次邀请之后，在 Amazon SES 上加入了邮件的追踪，用来计算转化率，更能数据化的分析用户到底在哪个环节流失了，推荐大家在是用邮件系统是时候都开启这个服务。
+我们在这次邀请之后，在 Amazon SES 上加入了邮件的追踪，用来计算转化率，更能数据化的分析用户到底在哪个环节流失了，推荐大家在使用邮件系统的时候都开启这个服务。
 
-但其实在我们获取用户的过程中还是犯了个错误，我们只关注了渠道的易用性，没关注渠道的契合性。V2EX 作为以开发者，产品经理为主要活跃群体的平台，本身与 Podwise 与播客听众并不是特别契合，我们当初之所以选择 V2EX 只是因为它对产品发布友好，如果重新再来一次的话，我们可能会选择在即刻的一起听播客 群组 和 小红书 招募用户，这样会用户群会更聚焦一些，然后对产品的帮助也会更大。
+但其实在我们获取用户的过程中还是犯了个错误，我们只关注了渠道的易用性，没关注渠道的契合性。V2EX 作为以开发者，产品经理为主要活跃群体的平台，本身与 Podwise 与播客听众并不是特别契合，我们当初之所以选择 V2EX 只是因为它对产品发布友好，如果重新再来一次的话，我们可能会选择在即刻的“一起听播客”群组和小红书招募用户，这样会用户群会更聚焦一些，然后对产品的帮助也会更大。
 
 总之，在 Podwise 在通过 Landing Page 和 V2EX 社区的宣发后，成功获得了最初的 200 个用户，为我们能够持续构建服务开了个好头。
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 自己的规模化盈利了。但没办法，我们不能通过惩罚客户来弥补自己的错误。