写点什么

Cursor 编写 90% 代码,3 个月速成 AI App 吸粉破万,编程门槛真降低了?

Brandon Gell

  • 2025-02-02
    北京
  • 本文字数:12111 字

    阅读完需:约 40 分钟

大小:5.70M时长:33:11
Cursor编写90%代码,3个月速成AI App 吸粉破万,编程门槛真降低了?

曾经,构建一个电子邮件客户端需要数年时间和数百万美元的投入。但今年,多模态媒体公司 Every 的 Kieran Klaassen 推翻了这一切。他在短短三个月内用 AI 打造了 Cora——一种全新的管理电子邮箱的方式,并且迅速吸引到超过 10,000 名用户注册,这是在当前生成式 AI 加持的状态下才变得可能的事情。

 

那么,Cora 与其他管理电子邮箱的软件有什么不同?Kieran 又是如何利用 AI、只花了一晚的时间就做出了产品的初版 MVP(Minimum Viable Product,最小可行产品)?近日,在播客节目《AI & I》中,Cora 总经理 Kieran Klaassen、Every 的工作室负责人 Brandon Gell 和  Every 的 CEO Dan Shipper 一起,畅聊打造 Cora 的心路历程以及使用 Cursor 的独特经验。基于该播客视频,InfoQ 进行了部分增删。

 

核心观点如下:

  • 关键在于真正深入了解你要解决的问题,同时又能够非常自由地去做一些尝试。

  • 做软件越来越像做内容,写作越来越像编程。

  • 专注做好一件事,因为做好这一件事,会让你在其他方面的不足得到宽容。

  • 真正重要的不是编写代码,而是如何把它发布到实际环境中。

  • 牺牲一些东西往往是让你在自己关心的事情上取得进展的最佳方式。

  • 在建立公司和产品时,真正的关键是享受这个过程,接受其中的混乱和艰难。

 

用 AI 做 AI APP

 

Dan:介绍一下 Cora 是什么?

 

Kieran:Cora 来源于我们试图解决的一个问题——每当想到“电子邮件”这个词时产生的恐惧感。没人会兴奋地想着:“我要打开我的邮箱,看看那一万封未读邮件。”因为处理邮件很烦,我们开始着手开发 Cora,它的核心功能就是帮助你减少打开邮箱时感到的压力。Cora 将 90%的不重要邮件从你的收件箱中移除,并且每天两次生成简报(briefs)为你概述它们,让你可以集中精力阅读那些真正重要的信息。

 

Dan:举个例子,所有我不需要回复的邮件,比如新闻简报、促销信息等,我不需要一封封去归档和阅读它们。通过 Cora,我可以直接滚动鼠标,快速地浏览这些信息。如果这些邮件有我需要查看的内容,我也可以点击进入阅读完整邮件。对我来说,这节省了大量时间,让我每天处理邮件变得更加高效。

 

我认为 Kieran 说得非常对,Cora 真的解决了那种处理邮件时令人畏惧的感觉,反而让这件事变成了一种享受。此外,最重要的是,Kieran 是在三个月内完成了这个产品的全部开发,这真是相当疯狂。

 

Kieran:是的,我们花了三个月的时间来开发,但实际上大约在四个月前就开始有这个想法了。

 

Brandon:我们一开始并没有从简报入手,而是从目前很多产品都在做的地方开始——帮你草拟电子邮件。最初我们确实能得到很不错的草稿。但我们意识到,不管大模型如何模仿你的语气,如果它没有额外的上下文信息,它就无法为你写出一封好的电子邮件。所以,Cora 确实会为你草拟邮件,但它只会草拟它认为能够做得非常好的邮件,或者说那些你几乎不需要修改的邮件。

通过这个过程,我们发现实际上真正的负担并不是回应邮件的部分,回应邮件其实是一个比较愉快的部分,因为它意味着你可能推动了一些事情向前发展。真正让人感到压力的,往往是管理收件箱,这也是我们大部分时间都在做的事。

 

Dan:以前,最昂贵的部分是构建软件本身,但现在成本变得低廉得多,这意味着你要构建的东西变得更加重要。因此,从“有了一个想法,我们来做草拟”到“草拟可以,但其实我们花了很多时间在阅读和归档不需要回应的邮件,或许 AI 在这方面能做得更好”的转变,让人意识到,比起写底层代码,能够意识到这一点的价值在某种程度上反而更大了。

 

不过我很好奇,Kieran,你是如何这么快速地完成这些的?是因为你本身有多么出色的编程能力,还是你在利用 AI 来让自己工作更高效呢?

 

Kieran:我认为关键在于真正深入了解你要解决的问题,同时又能够非常自由地去做一些尝试。比如,Brandon 和我在电话里讨论可以从草拟邮件开始时,我灵感迸发,在走回家的时候就拿出手机,打开备忘录录音,说出一个大概的提纲。根据我之前作为程序员的经验,我开始思考用什么技术来实现这个想法,并把这些想法全都说出来,可能花了五到八分钟,然后把它们转成文字。那天晚上,我就做了一个 MVP,并发了封邮件给 Brandon 说,“嘿,Brandon,系统可以帮你自动草拟邮件了。”

 

Brandon:Cora 背后的代码有多少是 AI 写的?你觉得这个比例是多少?

 

Kieran:其实几乎所有的代码都是由 AI 写的,可能有 80%或 90%,但 100%的想法都是我自己想出来的。AI 像是一个合作伙伴,帮助我更快地完成那些繁琐的工作。

 

Brandon:你现在更像是一个懂得编程的写作者,而不是一个程序员。

 

Kieran:我有一点音乐人背景,所以对我来说,软件就像音乐,都是在讲一个故事。就像你用音乐来支持一部电影或短片,让观众产生某种情感一样,我也会以类似的方式看待软件开发。你创造了一种体验或者讲述一个故事,让人感受到某种情绪。这与传统的工程师解决问题的视角不同,后者的观点是:“我有一个程序,接下来要怎么做。”我总是想得很宏大,而且我并不太关心它是如何工作的。虽然我当然也在意代码的优美和结构,但更重要的是它是否有效。如果它能够解决问题,讲述一个故事,或者让你产生某种感觉,那就是最棒的。

 

Dan:我们之前讨论过做软件变得越来越像做内容的原因。因为现在写软件变得更容易了,AI 可以帮助完成很多工作。现在任何人都能做出一个邮件总结或者回复工具。大家都能解决问题,但能够打动人的工具才能赢得客户,才是最终的赢家。另外,写作也变得越来越像编程,因为你实际上可以通过写作来构建东西。所以,现在有一种融合的趋势。

 

长期以来,我们一直把软件工程看作是解决非常明确的问题的过程,因为软件开发成本曾经非常高,所以你不希望冒险去开发一个对别人没有实际帮助的东西。而你现在的做法,更像是从另一个方向切入,强调的是做一些能够让人产生情感反应的东西,这种方式与写作和创作本身是兼容的,很大程度上取决于品味、视野、经验和创造力等等,我认为软件正朝着这个方向发展。

 

Kieran:对于 Cora 来说,团队中的每个人都带来了他们的独特视野,提供了不同的解决方案来处理电子邮件。我们常听到人们说,“没有其他像这样的产品,它不一样。” 我们对此感到非常自豪。有时我们也会讨论,“是不是应该让用户的体验稍微轻松一点,或者让流程更加流畅?”我会想,也许做一些独特的设计或者以某种方式做出声明,也是可以的。尤其是为了让产品与众不同,这本身就来自于品味和一种感觉。

 

Dan: Kieran 你能不能再具体谈一谈你是如何在一个晚上构建 Cora 的第一个 MVP 的?你在开始一个新项目时,用到的 prompt 是什么样的?

 

Kieran:我通常是去散步,散步可以让我进入一种流动的状态。我会在脑海中开始构建一个 prompt,比如“你是一个非常优秀的 iOS 工程师,你非常擅长 Swift 18,你很棒”之类的开场白,类似这样就可以开始为思路设定基础。

 

接下来,我在脑海中想象这个应用。也许这个应用每个角落都有不同的颜色,带一点纹理,像是颗粒感的噪点纹理,可能还会使用“高端”和“苹果设计”这样的词语来描述它的感觉。在中间会有一个分隔线,其实这并不是一条线,而是由两个渐变部分组成。然后我会继续描述下去,直到我脑袋里没有更多想法为止,我才会停止录音。这个过程其实只是第一步,之后我不会直接从这里继续发展,而是要通过这个过程去整理并形成完整的思路。

 

Dan:我认为需要明确的是,也许像“我付你 1 万美元,给我一个好答案”这种方式可能会过时。但能够准确地表达“我想要一个这样的应用,我希望背景是这样的,我希望左侧按钮的风格是这样的”,这些细节实际上是不会消失的。这就是 prompt 工程,能够清楚地知道自己想要什么,能够在表达时做到精准,这非常重要。你脑海里有一个清晰的愿景,你在散步时尽可能详细地表达出来,你并不太担心自己表达得是否完全正确,因为你可以回头再修改,说“其实我不想要那个,我想要的是这个”。听起来你在做的是转录工作,那你是用什么工具进行转录的呢?

 

Kieran:我通常会使用语音备忘录,然后将其导入到 Mech Whisper,这是一个免费的语音转文字工具。不过现在,随着 iOS 18 的更新,语音备忘录也支持转录了,所以我有时也会使用这个功能。然后,我会将转录的文本导入到我选择的大模型,开始进一步处理,通常会将它转化为 PRD(产品需求文档)。大多数时候,我会说,“好吧,我有了这个想法”,然后有时我还会添加笔记本,创建一个文件的大纲,或者根据需要使用不同的工具。

 

Dan:你选择什么模型来将这些内容转化为 PRD?

 

Kieran:我总是尽量使用最好的模型,目前这个是 o1 Pro,其他模型也做得很好,比如 Claud Sonet。对于编程,我大多数时间使用 Cursor。但 o1 Pro 适用于其他一切,比如用来做规划、编码,还有思考策略,或者只是做一些非编码的合作,像是作为一个合作伙伴交换想法。

 

Dan:我自己几乎一直在使用 o1,它是我现在的主要模型。我也有 o1 Pro,基本是在进行编程工作时使用它,但我觉得它太慢了,有时候它会显得有点过于深思熟虑,可能 o1 的更快响应反而会更好。现在很多编程助手,比如 Windsurf 或者 Cursor Composer,它们有时会陷入死循环或做出奇怪的操作,所以当它们卡住时,我就把代码丢给 o1 Pro 说,“这个代码里有什么我应该注意的地方吗?它真的是按照我想的那样做吗?”这很有帮助,但除此之外,我大多数时间还是倾向于使用 o1。

 

Kieran:它的处理速度确实很慢。虽然有人可能会觉得这是个缺点,但对我来说,这也让我放松了一些。因为与 AI 合作可能会很有活力,但也会有些压力,因为它的处理速度太快了,一直让大脑处于高强度的运转状态。偶尔坐在椅子上什么也不做,等三到五分钟,反而让人感觉很清新。所以,我其实很享受这种节奏。

 

Brandon:你会有意去查看它的思维过程吗?

 

Kieran:我从来不看它的思维过程,因为它本身就是一个总结。我之所以使用它,是因为它是最新的模型,我想通过它学习更多。唯一真正了解一个模型的方法就是使用它——这就是进步的方式。所以,也许是因为它对我来说还比较新,我还没有完全理解或者习惯它的工作方式,这也是我选择使用它的原因之一。

 

Dan:Brandon 你最近在用什么模型?

 

Brandon:我主要在用 o1。我本来想说,我不像你们那样做那么多编程,但前几天我确实用它做了一个奢华的个人应用,我简直惊讶于自从上次尝试以来它的进步有多大。我还在开发一些产品,帮助我更好地学习西班牙语,实际上我一直找不到一款合适的口语闪卡产品。

 

Dan:什么是口语闪卡?

 

Brandon:它能和你对话,我希望它能读出我要说的词,然后我可以用西班牙语或英语回答。

Dan:那你成功了吗?

 

Brandon:成功了!很有趣,实际上大概用了三个 prompt 就把产品做到了能用的程度,然后加了一些错误处理,很快就搞定了。

 

Dan:你是用实时 API 吗?

 

Brandon:我最开始用的是谷歌的音频 API,效果很糟糕。现在我把它切换成实时 API 了。

 

Dan:我认为目前人们仍然低估了非技术人员甚至技术人员能够快速实现某些东西的容易程度。

Brandon:这就是为什么像 Replit Agent 这样的工具会变得如此重要。真正重要的不是编写代码——这可能是 o1 Pro 或 o1 最擅长的——而是如何把它发布到实际环境中,这才是现在的难点。

 

Dan:是的,所有环境配置的部分。对我来说,使用 Windsurf 和 Cursor Composer 有个不错的地方,就是它们现在可以使用文件系统。它们会设置好多这样的东西,然后假设它们运行“npm install”或者其他命令时,会安装所有的依赖项。如果遇到错误,它们会识别并自动修复,这为我节省了大量的时间。过去,我经常会因为一个错误问题而一直卡住,然后还得去 Google 查找解决方法,现在它们帮我解决了。Kieran,你主要是使用 Cursor Composer 对吧?有什么小故事吗?

如何驯服 Cursor


Kieran:我有个朋友,两天前我对他说:“你怎么不去做点什么呢?”他说,“但是我不太懂技术啊”,这种话我听过太多次了。我就说:“下载 Cursor Composer,试试做个简单的东西。”我给了他一些指导,结果昨天他给我发信息:“我又做了一个应用!”然后还发了视频,今天他又告诉我:“我为我女儿的学校做了一个应用。”他现在完全被 AI 这种东西给迷住了。

 

但问题是,做什么才有用?真正的有效方法就是:去做,去感受。因为如果你从没体验过这个过程,很难理解。而且,你需要明白一些东西,比如:Chat、Composer 和 Agent 模式之间的区别,知道哪个适合自己用。现在的限制因素不再是知识本身了。

 

Brandon:这需要耐心,还有你自己下定决心去面对问题。有时候我会想,我并不真正理解问题所在,这样做是不是不好?但我还是这么做。因为我的目标并不是理解这些东西,而是建成一个东西。

 

Dan:我一直在思考一个关于“分配经济”的理论——我们正在从知识经济向分配经济转型。在过去,知道多少东西决定了你如何获得报酬,而现在是看你如何分配智力(intelligence),而分配智力的技能就是目前人类管理者的技能。因为每个管理者都会问自己这个问题:有人做了一些工作,我是应该微观管理,深入细节,还是应该完全委派出去?我怎么知道什么时候做该做什么事?

 

我很好奇,对 Kieran 来说,你说过你理解正在编写的代码,那是因为你实际审查了大部分代码,还是因为你在 AI 编写代码之前已经设计好了架构,因此对系统的运作有很高的信心?你是怎么在“深入细节”与“委派”之间找到平衡的?

 

Kieran:Cora 的情况与我快速做一些小应用不同,因为我使用的是我已经使用了十多年的技术,我非常熟悉它。

 

对我来说,最重要的部分其实不是代码本身,而是出错的地方。如果出错,通常是因为想法或问题不够明确。比如说我们要定义什么是电子邮件,电子邮件可能处于什么状态。如果我对这些方面没有清晰的理解,那么 Cursor 生成的代码就很难正确。它会填充细节,但有时候这些细节可能会偏离原本的方向,这就不好了。所以,方向必须非常明确。

 

Dan:如何处理填充细节呢?就我的经验而言,虽然我主要是用 Cursor 做一些临时应用,但是每次我创建应用时,我又要重新做出所有决定。比如说,我用 Superbase 作为数据库,在那个 Composer 会话中,它记住了这些决定。但当我下次打开一个新会话时,它就会忘记很多这些信息,然后会做出新的或不同的决定。它可能会说,“哦,假设数据库是一个本地托管的 PostgreSQL 数据库,我们来连接它。” 然后我就会说:“不不不,是 Superbase。” 它就会问,“那 N file 在哪里?” 我会说,“在这里。”

 

你是否一直在创建上下文文件?你怎么确保 Cursor 记住你做过的决定呢?

 

Kieran:在项目中,你可以创建一个名为“Do Cursor Rules”的文件,将一些规则写在其中,并将其与当前项目关联。通常,当我发现问题时,我会直接进入这个文件进行编辑,操作非常简单。例如,对于控制器,我通常会在文件顶部添加标题“Controllers”,然后在下面写明有关控制器的相关信息,指示代码应遵循哪些规则。

 

这些规则通常来源于我在项目中遇到的问题或错误,当出现某个问题时,我会思考是否可以这样处理,如果可行,我就将这个解决方案添加到 Cursor Rules 中,这样下次就不需要每次都说明了。我确实是手动编辑的,如果可以自动化这个过程,一定很有趣。

 

Dan:我们作为一家媒体公司,核心成员是一些非常重视语言的写作和编辑人员。所以,我们所有应用的文案都会经过仔细的编辑,这个过程有时会比较耗时。我知道你把 Style Guide 放进了 Cursor Rules 里,目的是希望能减少一些文案编辑的工作。这个方法有效吗?Cursor Composer 是否能够将这个 Style Guide 应用到 APP 中?

 

Kieran:我认为是有效的。我最近也在将 Style Guide 应用到 APP 文案处理上,这样它就不会产生不一致的情况。到目前为止,它确实在一定程度上改变了我们写作的方式。

 

Dan:我给 Kieran 发送了我正在写的一篇文章的部分草稿,他将它保存为一个 Markdown 文件,并放在他的 Cora 项目中。他将使用自己的 Cursor Rules,其中包含了文案编辑的建议,并让 Cursor 根据我们的文案编辑 Style Guide 进行编辑。

 

我觉得很多人可能不明白这个 Agent 接口是多么有趣和重要,它会在每种工作流中变得普遍。现在它从代码开始,但最终会在所有领域都有应用,文字处理、我们生活的各个方面都会涉及到。我其实已经开始用它来做笔记,效果很棒。

 

Cursor 给出的反馈是:我已经应用了 Style Guide 规则来改进写作,并列出了关键的修改内容,例如标题和章节标题的标题大小写。我得仔细看看,但根据目前的情况来看,我猜测它还是缺失了一些内容,你需要做的是让它逐条执行规则来检查整个文件。

 

Kieran:如果我们想更深入地利用这个功能,你可以创建一个记事本来存放 Style Guide,然后引用那个记事本,并说“请逐行检查这个记事本中的所有内容”,或者你也可以选择让它只检查一次,然后再做其他处理。还有其他方法可以做到这一点,虽然目前它并没有专门为这种任务进行设置。不过,最酷的部分是,虽然这有点复杂,但你可以要求它基于这个想法创建一封促销邮件,并链接到完整的博客文章。

 

Dan:你基本上是在把它当作一个内容创作工具,而且不仅仅是用它来创作内容,还将内容整合到整个系统中,甚至它能为你编写相关的代码。我觉得很多人可能还没意识到,这种整合是多么强大,所有的部分结合在一起,能够让工作变得更加高效和流畅。同时,你需要时刻关注你的 Agent,因为它可能会做出你不希望它做的事情。你要注意到这些问题,然后修改原始提示,而不是等它自动执行。我的最后一个问题是:你能要求它逐行检查风格指南吗?

 

Kieran:我们来试一试。我现在做的是一个快速且简化的 Style Guide,里面写着“始终使用以下样式”,然后逐项检查并建议修改。我现在回到 Composer 命令,重置了一下。接下来我会进入记事本,选择这个叫做“新记事本”的文件,让我们看看它会怎么处理。还有一个很酷的功能是,虽然我们现在使用的是 Claude 3.5,但如果你想尝试其他模型,都可以轻松切换到,界面保持不变,然后看看效果如何。

 

Dan:我觉得现在这个功能还不完全成熟。我发现当前版本的 AI 模型,并不擅长在文本中找到每个违反规则的地方并应用规则。它们只能找到一些违反的地方。唯一能做到这一点的模型是 o1,但 o1 并没有出现在这些 Agent 接口中,因为它还不支持工具调用。不过,这个功能正在开发中,预计会在这个季度发布,我相信那时候它会彻底改变这个流程。

 

Kieran:是的,所以我切换到普通模式,因为我们不需要 Agent 来处理这个,它其实更像是一次性任务。普通模式和 Agent 模式的区别在于,Agent 可以按步骤进行思考,看到错误并修复它;而普通模式更多的是你输入一个指令,然后它给你一个回应。普通模式仍然可以创建文件或执行某些操作,你需要自己去发现错误并修复。不过,你仍然可以在普通模式中使用 o1 模型,这样效果也是不错的。

 

Dan:Agent 基本上是在一个循环中运行,尝试为你完成任务,而 Chat 则是告诉你该做什么。它有点像在你的 Cursor 中嵌入了 ChatGPT,你需要手动应用每个修改,而不是让 Agent 自动处理所有事情。

 

Brandon:对,Agent 可以根据遇到的问题逐步处理任务,但它目前还不能在单个提示中进行迭代操作,也就是说,它不能在一个提示内反复调整和改进,直到问题完全解决。

 

Dan:是的,它不会基于你最初的提示一直运行,直到它认为任务完成。它会一次性给出所有的回应,你需要手动应用这些修改,然后再继续说“好,我们继续”。

Cora 的未来


Dan:我们已经发布了 Cora,目前有 7000 人在等候名单上,我们也开始陆续从等待名单上把人放出来。这个过程其实很简单,就是给他们发送一封邮件,告知他们已被移出等待名单。我们决定采用这种方式,是因为用电子邮件注册并授权一个服务访问你的邮箱其实是一个非常有压力的事情。为了降低压力,我们采用了这种肩并肩的方式,这样我们能发现潜在的问题,并在初期就帮助用户解决这些问题,确保后续顺利。

 

但我想聊聊的是,当前我们在解决的主要问题是什么?我们如何从这里迈向下一步?

 

Brandon:我想分享一下其中最困难的部分,那就是我们总是使用自己做的产品。有时候我觉得,这可能会让我们产生一种错觉,认为这些产品是有效的,因为我们正在使用它们。所以我们可能在自我说服:一些我们遇到的问题并不是真正的问题。而且,这个问题几乎是无法回答的,因为很难判断产品是否真的存在这些问题。我觉得,手动进行用户引导帮助我们更好地理解,用户对于这款产品的真实关注点或顾虑是什么,尤其是对于这样一款管理工作中至关重要部分的产品。

 

目前我们大家都非常清楚的一个问题就是,Cora 会归档电子邮件,它可能会导致你看不到别人可能发送给你的重要信息。今天早上我们就讨论了这个问题——我们都没有遇到这个问题,但我们在引导一些用户时,他们确实有这种感受。那么,这到底是一个多大的问题呢?那些有此问题的用户,真的是我们理想中的目标客户吗?因为我们似乎并没有遇到这个问题,那我们是不是在自我安慰,觉得自己并不需要解决这个问题?所以,我认为在这个过程中,如何优先处理这些问题,成为了我们面临的一个重大挑战。

 

Dan:其实我非常喜欢我们能做出自己会使用的产品。但是,我认为潜在的缺点是,你第一次使用一个产品时,所有“我不熟悉这个产品”的问题都会浮现出来。一旦你使用了一段时间,这些问题就会慢慢消失了。只有通过接触更多的初始用户,你才会重新意识到:“哦,这就是从零开始使用这个产品的感觉。”你需要认真对待这些问题。但接下来,你还需要弄清楚,如果我们只进行过几次用户引导,而那些参与引导的用户并不喜欢这个引导体验或不喜欢这个产品,这意味着什么?我们该如何平衡他们的反馈和我们对产品的良好感觉?

 

我不知道大家的感觉如何,但我个人认为,最重要的是获取更多的数据。你需要尽可能地让更多人使用这个产品。当数据量增加时,你就可以开始大范围地分析,看到不同类型的用户反应。有些人非常喜欢这个产品,那我们就集中精力先关注这些用户;如果每个人都遇到同样的问题,那很明显我们需要修复一些东西。我想这就是人们在谈论创业的过山车时所指的——你从少数几个人那里获得早期数据,然后做出推测,这种过程要么让你感到非常兴奋,要么让你感到非常沮丧。随着数据量的增加,你对产品的评估就会更加客观和冷静。

 

Kieran:另一个角度是,你可以专注于解决最大的问题,或者你可以问自己,什么地方已经做得很好,怎么才能做得更好。有些人用了一天就会觉得:“哇,这太棒了。”或者那些试过 20 个类似工具的人会说:“虽然这些工具功能差不多,但你的产品真的不一样。”有些功能目前可能做得还不够好,甚至有些地方仍然让人非常烦恼,但他们仍然喜欢这个理念、喜欢它的价值。这就是另一种看待问题的方式:专注做好一件事,因为做好这一件事,会让你在其他方面的不足得到宽容。

 

Brandon:是的,感觉现在我们面临的核心问题是,Cora 提供了一种不同的方式来管理电子邮件。我们觉得这种新的方式挺好的,愿意接受这种管理邮箱的方式。然而,其他数百万的人是否也愿意以这种方式来处理他们的收件箱?

 

Dan:我很喜欢这种思维方式或转变,因为我认为初创公司常面临的问题之一,尤其是当要解决像电子邮件这样的大问题时,他们可能会认为,只有在构建出一个完整的电子邮件客户端、甚至达到像 Gmail 这样的竞争对手的标准之前,才能真正知道自己是否解决了问题,这种想法往往导致一场注定要失败的战斗。

 

早期你想要构建的产品应该是针对某一类特定用户,它应该在某些方面比现有的产品好十倍,足以吸引他们使用,尽管它在功能上可能无法与其他电子邮件产品媲美。我觉得这正是我们目前在做的事——比如简报。虽然最终希望 Cora 能成为一个完整的电子邮件客户端,但现在我们的任务是让它在某一特定功能上做到极致,做到即使它还不是一个完整的邮件客户端,人们依然愿意使用它。

 

同时,我们也需要弄清楚这些使用它的人是谁。它不会一开始就适合所有人,也不应该是这样。问题在于,是否有一群核心用户会非常喜欢它?我的理论是,虽然现在还太早说,但从目前产品的状态来看,答案是肯定的,100%会有一群人非常喜欢它,并且这对他们来说是一个非常有粘性且惊人的体验。

 

Brandon:想想看,电子邮箱现在几乎就像是传统的纸质邮件收件箱:有一堆垃圾邮件,我根本不会打开,直接删除——这和我的实体邮箱一模一样。有些邮件我会打开,但会迷茫,甚至不知道是否需要回复,感觉像是有些邮件在“欺骗”我。这种情况让人很困惑,而 Cora 完全颠覆了这种模式。我们面临的最大挑战之一就是:一方面,要有一个真正能解决问题的优秀产品,另一方面则是让大量的人知道 Cora 的存在,如何在这两者之间进行优先级排序——这就是产品构建过程中那种“模糊性”的体现,因为最终你必须做出决策。

 

Dan:我们已经谈论过很多次“你愿意牺牲什么?”因为作为一个组织,我们每个人在很多时候都不想放弃任何东西,但实际上,牺牲一些东西往往是让你在自己关心的事情上取得进展的最佳方式。

 

如果相信像 OpenAI 那样的机构所说的,我们可能在接下来的 1 到 2 年内就能实现 AGI。但对我来说,更有趣或重要的点是:目前所有大型实验室都在集中精力研发能够逐步解决问题的 AI——这种 AI 能够验证每一步解决方案的正确性,就像解决编码问题或数学问题一样。

 

一旦这一步完成,人们会意识到,世界上其实只有少数问题可以像这样逐步解决,而大多数问题则更为模糊,无法像那样被拆解成一个个可以验证每一步的解决方案。这些问题往往牵涉到品味、直觉、模式匹配等。然而,大模型并不擅长这些问题,因为我们不能像处理可证明的问题那样,通过相同的反馈回路来优化这些问题。反馈回路总是“做一些事情,从世界中获取数据,提出新的想法,新的视角,然后再次尝试,看看结果如何”。我觉得这是一个无法避免的现实,但它也非常美丽。对我来说,这是构建过程中最有趣的部分。

 

Brandon:我同意,这确实是最有趣的部分,同时也是最让人焦虑的部分,因为要做的事情太多了。你希望能够达到某个完成的状态,但现实是,这个完成状态根本不存在,在建立公司和产品时,真正的关键是享受这个过程,接受其中的混乱和艰难。对我来说,我是那种喜欢“二型乐趣”的人,二型乐趣是指那些看起来艰难痛苦,但在经历之后你会感到非常有成就感的事情,你必须学会享受这些艰难决策带来的困境,也许这就是为什么我喜欢做这类工作的原因。

 

Kieran:对我来说,合作也是一个重要因素。和那些能激发你思考、提出难题的人一起工作真的很棒。当你听到一个问题,心里突然想:“天哪,这个问题真好”时,那种感觉真是太棒了。

 

Brandon:我有时候会陷入细节,想要把所有事情都列出来,然后一一搞清楚,但 Kieran 特别擅长把我从这些琐碎的事里拉出来,说:“这些不重要,眼下我们有更大的问题需要解决,剩下的以后再处理。”我们这样相互合作,虽然“有趣”可能不是最合适的形容词,但确实是对我们关系和 Cora 的建设都非常有益。我们就像两块固执的石头,在相互摩擦中打磨出一颗璀璨的钻石。

你们有看到关于 OpenAI 和微软的协议吗?听说当 OpenAI 能够证明自己能够创造出价值 1000 亿美元的产品时,协议就会结束。

 

Dan:这是一个非常有趣的教训。在公司建设中,理想化的愿景往往能够激励人们,但当你为了迎合这种理想化愿景而创建复杂的商业结构时,最终你会发现其实常规的商业结构可能更有效。像 OpenAI,它有非盈利性质,又有盈利性质,还涉及微软投资等复杂的安排。然而,微软最后决定,等他们达到一定的收入目标后,就可以转为非盈利,或者根据需求做其他改变。

 

我认为,这种情况和人工智能的发展也有些相似。我觉得我们正处在这样一个阶段,认为人工智能在一到两年内可能会达到 AGI 的水平,觉得一切都将改变,未来会变得截然不同。而这种情绪有时也会带来一种焦虑,大家开始质疑:我们究竟要去往哪里?

 

有趣的是,这种情况其实出现在每一轮人工智能的浪潮中,每一次人工智能的热潮也伴随着类似的情绪。当人工智能的研发始于 50 年代时,人们曾说:“我们夏天就能搞定。”接着,60 年代和 70 年代又有了新的突破。人们发现,每当迈向一个新的阶段时,新的难题和复杂性也随之而来。

你们有没有过这样的经历?我曾去过天使之路徒步,天使之路上有一段特别有意思的路程,你需要绕过一系列的急转弯,然后有一段几乎是靠墙走的路,旁边就是悬崖,足足有 500 英尺的高度。有意思的是,当我到达山顶时,我突然发现远处有一个更高的山峰,我心想:“哦,原来还有这个更高的目标,我得去看看。”然后我又继续走,直到每次走到一个峰顶,都会发现远处有一个新的山顶。这就像是你永远在追逐一个看似马上就能达成的目标,但每次都又会发现一个新的目标。

 

我觉得,人工智能的发展就像这次爬山的经历一样。你会看到一个峰顶,觉得可以达到,然后一旦你到达那个峰顶,你会突然意识到还有一个更高的目标。就这样,一直向前进。这就是我对人工智能的看法,我们可能很快就会在某种定义下到达 AGI 的阶段,但这个过程也会暴露出更多的复杂性。所有那些乌托邦式的期望和末日论调可能会显得不那么重要,真正的现实将会远比我们想象的更为复杂。这反而让我感到兴奋,我喜欢这种不确定性和复杂性带来的挑战。

 

Brandon:你刚才描述的其实是所谓的“假峰”现象。我曾经看到过一个图,它展示了人类知识的全貌。图中,所有人类的知识以一个大圆圈的形式呈现。现在,我们可以把当前的人工智能发展看作这个圆圈的边缘,虽然它看起来很重要,像是一个巨大的变革力量,但如果你放大一点,你会发现,实际上它只是这个大圆的一部分。我们现在所学到的,实际上它只是渐进式的。容易产生一种末日情绪,觉得 AGI 一旦到来,就会改变一切,我们将失去工作,也无法再进行创造。但实际上,人类的现实情况是,AGI 的到来只是为另一个未知的领域打开了一扇门。

 

Dan:我想,把话题拉回到 Cora,这是我从 Cora 中学到的一个重要点。很多人会担心“如果人工智能彼此之间在发邮件,没有人类再发邮件,那怎么办?”但我发现使用 Cora 后,实际上我的收件箱里只剩下了人类的邮件。只有人类是我需要回复的对象,而 AI 则在帮助我整理其他所有内容。AI 正以更易于消化的方式把这些自动化的内容呈现给我,从而让我有更多时间去专注于那些真正值得关注的人。我觉得这个效果真的很棒,而这些“末日论者”根本没有意识到这一点。

 

参考链接:https://www.youtube.com/watch?app=desktop&v=MhKKKBG28a4

2025-02-02 14:0013195
用户头像
李冬梅 加V:busulishang4668

发布了 996 篇内容, 共 606.7 次阅读, 收获喜欢 1172 次。

关注

评论

发布
暂无评论

在 GraalVM 静态编译下无侵入实现可观测探索

阿里巴巴云原生

Java 阿里云 云原生

TIDB 分区表使用实践

TiDB 社区干货传送门

6.x 实践

一文了解TiDB的数据对比工具sync-diff-inspector

TiDB 社区干货传送门

实践案例

Java jdbc 驱动 maxPerformance 配置避坑

TiDB 社区干货传送门

开发语言 应用适配 数据库连接

绕过 MVCC 影响的 TiDB Delete 数据方法

TiDB 社区干货传送门

管理与运维 7.x 实践

Puppet 2024年度报告:平台工程发掘 DevOps 无限潜质

SEAL安全

DevOps 平台工程 puppet

详细教程:如何制作产品介绍二维码(二)

草料二维码

二维码 草料二维码 干货分享

DApp 链上合约质押挖矿系统开发丨技术搭建

l8l259l3365

牛市下一个板块该轮到谁?Gamefi赛道爆发你吃到了多少?

威廉META

开源分布式数据库 TiDB 架构以及HTAP 的实现

TiDB 社区干货传送门

TiDB 底层架构

月活超 1.1 亿,用户超 4 亿,你也在用的「知乎」是如何在超大规模 TiDB 集群上玩转多云多活的?

TiDB 社区干货传送门

实践案例 社区活动 数据库前沿趋势 OLTP 场景实践

万字心路历程:从十年老架构决定重构开始

阿里巴巴云原生

阿里云 云原生 iLogtail

iOS应用审核问题解决方案及优化方法 ✨

雪奈椰子

微隔离,做到真正零信任

德迅云安全杨德俊

cURL 命令全面解析:提高工作效率

Apifox

程序员 前端 后端 API curl

数据本地性如何助力企业在云上实现高效机器学习

Alluxio

机器学习 gpu 模型训练 云存储 Alluxio

容器架构下的性能测试实践方法

老张

性能测试 容器化

MES系统跟车间设备怎么连接?设备管理后的好处有哪些?

万界星空科技

数据采集 mes 设备管理 万界星空科技 智能设备管理

通过TiOperator备份数据到共享存储

TiDB 社区干货传送门

实践案例 集群管理 故障排查/诊断 备份 & 恢复

TiKV 状态变化

TiDB 社区干货传送门

开源一个教学型分库分表示例项目 shardingsphere-jdbc-demo

EquatorCoco

数据库 开源 分布式

教你用python爬取『京东』商品数据,原来这么简单!

技术冰糖葫芦

API 接口

【干货】需求驱动的配货

第七在线

金三银四 | 软件测试开发岗求职攻略来袭,快来抢先一步!

测试人

软件测试

实时计算Flink集成开源连接器-TiDB CDC Connector案例实践

TiDB 社区干货传送门

实践案例 应用适配 数据库连接

不再等待直接上答案,百度智能云推出数据库 Copilot

Baidu AICLOUD

数据库 大模型

Cursor编写90%代码,3个月速成AI App 吸粉破万,编程门槛真降低了?_生成式 AI_InfoQ精选文章