DAILY REPORT · 日报
2026年09月14日
星期一 · 4 条发布
我让Grok找回MVP滑板到汽车图
我跟 Grok bot 说: 帮我在 X 上找一张图片:图里好像是一个交通工具,最开始是滑板车,慢慢变成自行车,然后变成小汽车,好像是这样的。 这张图讲的是:一个产品不要先关注细节,而是先从最核心的功能开始,把它做出来,然后不断迭代这个最核心的功能。
它一会回复我: 对上了:就是 Henrik …
2 张图片
我跟 Grok bot 说: 帮我在 X 上找一张图片:图里好像是一个交通工具,最开始是滑板车,慢慢变成自行车,然后变成小汽车,好像是这样的。 这张图讲的是:一个产品不要先关注细节,而是先从最核心的功能开始,把它做出来,然后不断迭代这个最核心的功能。
它一会回复我: 对上了:就是 Henrik Kniberg 那张 MVP 图。我把原图发你,并再在 X 上捞带图帖。
找到了。就是 Henrik Kniberg 2016 年那张经典图:上面「Not like this」是先造轮子/底盘(细节堆叠,中间不能用);下面「Like this」是滑板 → 滑板车 → 自行车 → 摩托车 → 敞篷车(每次都能从 A 到 B,再迭代)。
原图如下。出处:Making sense of MVP
进化版(原作者的升级思考) Henrik 后来觉得 MVP 这个词太模糊,画了 Earliest Testable / Usable / Lovable 三段进阶版(滑板=最早可测试,自行车=最早可用,摩托=最早可爱),在原博文里,还讲了 Spotify 和 Minecraft 作为真实案例——Spotify 的「滑板」就是能流畅播放几首歌的原型,Minecraft 的「滑板」是一个人写了 6 天代码的方块世界。
顺带说一个有意思的点:掘金上有篇《关于「从滑板到汽车」这张图的思考》专门讨论这张图的常见误解——「滑板变不成汽车」「用户要汽车你给滑板他会愤怒」都是钻比喻的牛角尖。图的本意是:用户真正要解决的是出行问题,没人能在第一天就确定汽车是正确答案,渐进交付让你每一步都拿到反馈、随时修正方向。 原博文的图都是外链,直接点开就能看。要不要我把其中几个版本下载打包发你?(可以直接存进你 Obsidian 当素材)
我让Grok Bot写一键保存好文章
我让 Grok Bot 把昨天晚上我们开发的整个工具,写到做自己天天用的东西这个网站中去了。
提示词是这样的。
我想写一篇文章,文章就叫做《一键保存好好文章》。 我想写到:/Users/runwithcc/Obsidian-LifeOS/40-天天用的东西/工具/一键保存好文章/00-文章发布-一 …
1 张图片
我让 Grok Bot 把昨天晚上我们开发的整个工具,写到做自己天天用的东西这个网站中去了。
提示词是这样的。
我想写一篇文章,文章就叫做《一键保存好好文章》。 我想写到:/Users/runwithcc/Obsidian-LifeOS/40-天天用的东西/工具/一键保存好文章/00-文章发布-一键保存好文章.md 里面。
文章想写这样的几个部分啊。第一个部分呢,就是我想展示一下我的效果。那我的效果呢,我后续可能会截图或者录制视频。那基本上我会说,当我在使用这些微信公众号啊、小红书啊,还有 X 啊,当我看到一些好的内容的时候,我就很想要把它留下来为我所用。所以呢,这个时候啊,我就像是这个初步的分拣员。那我好像在进货一样。看到了一批货物摆在我的面前,我要快速分拣。哎,这个好我就留下,这个好我就留下。啊,等到后续我再做相应的处理。那怎么样子才能够把它留到我的知识库里呢?我的方式就是先复制一下,复制好了之后呢,直接呼出快捷指令,然后点击相应的类目,直接就可以进入到我的知识库了。
我觉得它解决了我很多问题。
-
初检员最需要的是有感受。这个感受好,我就要快速把它保存下来,一定要低摩擦。以前有一些方法可能得点好几下,我这个点两下就行了。
-
以前这些信息都放在不同的库里,这些库都是别人的,导致我很难把信息拿到自己手里。经常是我保存的地方出了问题,后续就再也读不出来了。
-
初筛员筛选完之后,后续是要加工的。我在加工的时候看到一篇文章,要尽可能给它打标签,让它自动到我的知识库另一部分留存。
这个留存过程中,如果所有信息都是分散的,我处理起来就会非常麻烦。它一下子帮我节省了处理时间。 4. 现在是 Agent 时代,Agent 要读取各种各样收集到的内容。我不想让它还要很麻烦地去别人那里读,只想让它在我自己这里能读得到。
接下来,我介绍一下这个工具的一些典型特征。 1、使用时间: 总的来说,我刷各种各样的信息,主要是在早晨起床后的空闲时间;中午偶尔会看一下;有时候在等 Agent 干活的时候会看一下;晚上睡觉前也会快速看一下。
2、使用频率: 我觉得一天大概要用若干次。有时候一天过滤各种各样的信息源,大约要过三四十条,所以每天使用频率非常高。
3、工具使用程度: 这个工具可以使用的程度大约到了哪个阶段?一共分为5个不同程度:
- 有用:表示局部上有用。
- 能用:表示 MVP。
- 好用:表示我用的时候已经不觉得烦,也不觉得有问题了。
- 爽用:用起来特别爽,会带来正向激励。
- 复用:不仅我能用,不仅在这里能用,还能用到其他地方。
目前我觉得这个工具大约达到了“爽用”阶段。
4、更新点: 这个工具有什么需要更新的点,我也不是特别清楚。有哪些特征,你到时候看一看,也可以帮我加一点进去。
再写一下这个工具的相应支持,不用写得太复杂,让小白能看懂流程就行:
- 我的步骤是怎样的?
- 每一个步骤都需要哪些东西?
- 这个东西在设计时的关键点是什么?
最后一个,就是让别人也能生产一个,来教别人怎么生产,对吧?你帮我写一个简单的教程。
比如:
-
给你的 Agent 表达什么?或者第一步是不是要先准备好一些必备条件?比如准备好一个服务器、一台本地常开的电脑、一个文件夹,这些资料都先准备好。
-
给出一段提示词。
-
跑通并且微调。
-
达到自己好用或者爽用的阶段。
最后,这篇文章也要号召大家做完之后前来留言,给我做一个反馈。觉得有效的话可以反馈,这样可以加入到我的群里(做自己天天用的东西)面来。
写的这个东西,不要写得太过于冷淡。要充满生命力、朝气蓬勃,有喜悦、打开、分享的气息。
写好后直接给我存到我的 Markdown 文档里就行,文件的属性部分不要调整。