- The Quibbler
- @李奇from 竹白
- 互联网
- 简介
- 这是一份关于互联网、科技领域的专栏，欢迎订阅。
- 去订阅
收录错误？ 点我反馈
文章预览
仅预览文章部分内容供参考，如需完整阅读请前往作者主页或订阅
- 随笔 · Lunar（Copilot for Podcast）试验总结
- 大概 5 月末 6 月初的时候和小伙伴做了一个小 App：Lunar（Copilot for Podcast），实现的功能有：从你在使用的任意播客客户端内分享单集播客到 Lunar 内，完成语音转文字；通过 GPT 完成文字的摘要和大纲总结；就播客内容进行问答，了解这集播客讲了什么；识别播客语言并翻译内容。完成后邀请了 30 多位即友参与了测试（非常感谢大家愿意尝试这种糙产品），大家给了很多有用的反馈，但最终还是没有继续迭代下去，主要的原因有三个：成本太高：播客时长基本 1 小时起步，外文播客的时长相对更长，单次识别的成本会非常高（虽然可以一次转换多次使用）；用户太少：这个产品基本上面相的是对资讯和效率有需求的用户，要求高但数量少，能够带来的收入太少；没有增量：吃播客的存量用户，并没有给行业带来更大的增量，变成了一个卷效率和成本的业务，这样的东西不太适合我们这样的小团队去做。成本总是会下降，但用户不总是会扩大，影响这件事最重要的是没有带来新的增量，当然有的人会认为这降低了收听播客的成本为什么不是带来新增量，这里定义的增量是指「满足核心价值的同时扩大了用户规模」，播客最重要的核心价值就是
2023年10月21日
- 随笔 · 为什么要「再快一点」？
- 在互联网产品开发领域里，「快」是金科玉律，所有的迭代都必须要快，能一天开发完的不要两天，能一周的别两周，产品经理要更快写文档，设计师要更快画图，工程师要更快写码。从业这么多年里，听到的反馈几乎都是「时间太紧了，要宽限两天」，但鲜有听过人问「我们为什么要这么快？」，可能不用问也能知道大概原因是「可以让我们更快收集到用户反馈、验证假设，用来迭代产品，可以更快的拿到结果来判断下一步应该怎么做」，但这够了么？我们对于业务的目标会对应到具体的指标上，但目标是什么，这个目标意味着什么却很少有人会提到，而指标是可以几乎无限被细分和优化的，如果追求快速达成某些指标，我们对于速度的渴望是无限的，这导致了大家对于速度的理解出现了偏差，得出了上面的结论。一般情况下做决策需要考虑目标和成本是否匹配，成本相对好理解，做事速度越慢周期就越长，付出的成本就越大。而目标则关乎通向哪里，走到了能不能站住，通向哪里每个业务都不同，但能不能站住的因素就确定了很多。时间窗口：时间窗口的影响因素有很多，政策的、流量红利的、业务壁垒的、需求满足度上的，目前的业务有越强时间窗口意味着你的动作就得越快，时间窗口往往意味着进入门槛，一
2023年06月12日
- 这波 AI 浪潮带来了哪些新能力？
- 就像之前在《如何 Allin Web3》中提到的，新领域一定要讨论带来了哪些新能力，而获得更多靠谱结论的方式可能是遵循坎宁安定律（Cunningham's Law），所以聊一下我自己的理解。对于这个话题有两个前置的想法：行业在不断发展每天都有新东西，可能未来会有新的能力被解锁，但我更倾向每一个有搞头的新领域在第一天就一定能看到很多从零到一的变化，如果一开始就是性能提升（＜10x），那么这事大概率跟创业者没什么关系，也就不在这篇文章的考虑范畴内。如果面向的是业务而不是画饼，那么新能力或者新变化的抽象要具体，具体到可以指导业务开展，不然琢磨出来了但太空泛，听上去变化很大但细想下来没法落地，那就太浪费时间了。因为上面两点会导致错误判断的概率提升，但对于小规模尝试更友好，所以需要对控制成本快速试错有预期，不要上来就搞个大新闻。基于上面的几个前提，我觉得这一波带来的变化有如下几个点：内容生成第一步的门槛降低我们常说「好内容是稀缺的」，如果把这句话拆开来再问一次：好内容的总量就是有限的还是因为某些外部因素导致他稀缺？如果相信「好内容的总量就是有限的」，给人一种做什么都意义不大，有一种宿命论的感觉，
2023年04月18日
- 大模型如何使用工具？
- 上周我通过 ChatGPT 的帮助做了一个 AI 助手的概念 Demo（在这里可以看到），作为一个不会写码的产品经理，能到这个状态已经超出了我自己的预期，不过在这个过程中也遇到了很多问题，但也发现了很多有趣的部分，在这里做一个记录。从出发点来说，希望实现的是一个严格意义上的 AI 助手，即可以通过自然语言下达指令，它可以帮助你完成任何能够做到的事情，同时支持基于上下文的多轮对话。基于这套逻辑，第一时间想到的则是实现一个「胶水层」：简单理解就是将需求在不同的「应用」间路由：将用户需求路由至大模型，从大模型获得的指令再路由至下游服务提供商，再将获得的结果返回给用户（当然每次路由都需要对应的 Prompt）。以此来实现一个可用的 AI 助手。在这个过程中面临的主要问题是：LLM 应该如何与下游实际干活的应用对接？在这个「胶水层」逻辑中，核心做法是将用户需求通过 LLM 翻译成下游应用所需的必要参数，然后将参数格式化成对应的数组、字典或者 JSON 返回给应用，以此来完成操作。但在这个过程中会发现，在严格要求输出的同时 LLM 也失去了多轮对话的能力，基本只能做到对单一指令的反应。例如叫车出行
2023年04月04日