admin

原链 mp.weixin.qq.com

这篇访谈对于很多对AI感兴趣的行业内人都有可读性，因为笔记是个大众型产品，跟用户息息相关，然后会议这个场景也很普遍，另外Notion最近也出了会议笔记功能。我感觉这个创始人比较实在，没有什么玄乎的概念或者炫耀，是有愿景然后也踏实做产品，并承认竞争和未知，这篇对谈整体给人的感觉很好。

这意味着 Granola 的价值要在用完一场会议后才显现，不太理想。构建产品时，你希望「魔法时刻」在前 20 秒出现。但这让产品好太多了。我们花六个月走错路，直到终于接受有更好的办法。

在这个领域，唯一答案是，你得比别人更快地造出更好的东西。有切换成本，有小的「护城河」，但唯一取胜之道是持续比别人更快地产出优于他们的产品。

现在信息和灵感来源太分散，我们往往只看一个孤岛里的数据。我想有个工具，能从我的个人生活、上下文，以及人类的集体智慧中，动态提取最相关的信息，实时呈现给我，让我能解读和利用。这个工具是什么样子，还没人知道。

原链 mp.weixin.qq.com

Arc浏览器是近几年在桌面软件领域少有的创新之一，我从多年使用的Firefox都切换了过来，是“新界面”的影响。这篇创始人的访谈，能提供不少方法论和价值观方面的启发，在我看来核心是说：

先有个长远的愿景：

计算机发展史上，iMac 是为互联网时代打造的友好易用电脑。我们觉得只要在界面设计、用户体验以及功能模型精细微调方面做好，长期会产生综合优势。

然后是创新的想法和空间：

定目标方式很灵活，可能有点随意。以新产品为例，「速度要快、延迟要低」这类长期目标，有整体规划，之后我就不深入参与了，主要是由我们的工程师每六周推进。

下来是合适可行的方法：

我们推崇 「少说多做」，多做原型的文化。做出原型后在团队分享，大家试用。这种自下而上、靠原型推动的模式，没有死板体系。现在看，哪些行得通，哪些不行，很容易判断，因为浏览器是每天都在用的产品，试用原型时能直观感觉到好用与否。

另外张宁之前写的这篇介绍文章也可以看看，The Browser Company：打造新界面。

原链 mp.weixin.qq.com

这是一个原腾讯的产品经理讲转入大模型创业公司工作的故事，文章是23年6月写的，现在看来也还不过时，文章既有故事性，也有很多作者的心得体会，对于对AI感兴趣的职场人士还是很有启发的：

加入一家公司，其实就是在投资自己的时间，而且这种投资还很难构成投资组合，一投就是 All in。

我的建议是：想清楚自己现在的处境，也想清楚未来的处境，想清楚自己的动力源，别因为 FOMO 而做决定。因为我觉得未来应用层的机会还非常多，可以造出非常深的壁垒，而现在还没到应用层爆发的时间点。再等等，也不急。

原链 mp.weixin.qq.com

这篇访谈还挺通俗的，对于想了解AI和工程师的人来说值得一读，我是从头看到尾了。不过讲的很多东西都是常识，了解这些只是第一步，知易行难，能不能做到以及坚持下去就看个人了，不能太理想化。

袁进辉：人才的特质可以用两个维度来衡量：能力和冒险精神。那些既有能力又特别喜欢冒险的人，最适合创业；而有能力但不喜欢冒险的人，可能更适合在大公司工作；介于两者之间的人，则可以考虑加入其他创业公司。当然，还有一些折中的方案。比如像字节跳动的很多业务，是通过并购进入的。这也是一种解决思路：虽然加入了一个大公司，但是作为被并购的单位，仍然可以相对独立地运营一个新业务。例如，抖音就是被并购进字节后发展起来的。所以在创业和就业之间，还存在着多种可能性。

原链 mp.weixin.qq.com

这篇讲用户增长的文章比较有启发点的是里边的用户数据模型，对模型进行科学分析后找出优化的关键指标，也就是杠杆最有效的地方，然后用常见的增长激励方式就生效了。当然文章里也说了“我们必须运用我们的判断力来将这种游戏机制适应 Duolingo 的环境。”：

DAU、WAU 和 MAU 可以很容易地从这些区块中计算出来，这使得随着时间的推移对它们进行建模变得容易。这是该模型的一个关键特性。此外，通过操纵箭头所代表的比率，我们可以模拟随着时间推移这些比率的复合和累积影响；换句话说，这些比率是产品团队可以拉动以增长 DAU 的杠杆。

在创建模型后，我们开始每天拍摄数据快照，以创建过去几年来所有这些用户群和留存率如何逐日演变的历史。利用这些数据，我们可以创建一个前瞻性模型，然后进行敏感性分析，以预测哪些杠杆对 DAU 增长的影响最大。我们为每个比率运行了一个模拟，在三年内每季度将单个比率移动 2%，而保持所有其他比率不变。

原链 pmthinking.com

Notion最近达到1亿用户了，前一段时间刚好看到少楠建的Notion中文wiki，所以分享下，喜欢Notion的人挺多的，少楠的产品沉思录里边的东西也挺多的，可以对感兴趣的内容仔细看下。

原链 kerkour.com

Rust专家讲Async现状的文章，这个问题在Python里也有，大多数人只知道Async/Sync用起来比较麻烦，不知道它的来龙去脉，作者在文章里引用了几个讲问题本质的链接，可以有一个深入的了解。另外作者之前写的选择 Rust 语言：Should I Rust or should I go?也可以看看。

原链 blog.brachiosoft.com

这个作者写的Git的故事蛮生动的，而且旁征博引，里边可谓是英雄辈出了，当然软件版本控制系统还有许多别的支流，只是没有Git这么流行和被我们了解了。

作者之前写的Redis作者的故事，也可以读下。

原链 kerkour.com

一个 Rust 语言专家写的文章，说明 Rust 适合的领域和不适合的场景，觉得说得很实在，跟我实际使用的体验比较切合，而且作者在下面这两点的看法也很有品味：

The standard library is anemic

you then have many implementations and ecosystems competing for basic features such as cryptographic primitives, async runtimes or HTTP servers, leading to incompatibilities, bugs, busywork and lost time.

async is hard

Now you have sync functions and libs, async functions and libs, and different runtimes that are incompatible and thus require dedicated libraries for I/O. When discussing with a friend who is into Python, he told me that they are experiencing the exact same problem and it creates a lot of busywork writing wrapper for sync code to be called by async code.