这是一个原腾讯的产品经理讲转入大模型创业公司工作的故事，文章是23年6月写的，现在看来也还不过时，文章既有故事性，也有很多作者的心得体会，对于对AI感兴趣的职场人士还是很有启发的：
加入一家公司，其实就是在投资自己的时间，而且这种投资还很难构成投资组合，一投就是 All in。
我的建议是：想清楚自己现在的处境，也想清楚未来的处境，想清楚自己的动力源，别因为 FOMO 而做决定。因为我觉得未来应用层的机会还非常多，可以造出非常深的壁垒，而现在还没到应用层爆发的时间点。再等等，也不急。
这篇访谈还挺通俗的，对于想了解AI和工程师的人来说值得一读，我是从头看到尾了。不过讲的很多东西都是常识，了解这些只是第一步，知易行难，能不能做到以及坚持下去就看个人了，不能太理想化。
袁进辉：人才的特质可以用两个维度来衡量：能力和冒险精神。那些既有能力又特别喜欢冒险的人，最适合创业；而有能力但不喜欢冒险的人，可能更适合在大公司工作；介于两者之间的人，则可以考虑加入其他创业公司。当然，还有一些折中的方案。比如像字节跳动的很多业务，是通过并购进入的。这也是一种解决思路：虽然加入了一个大公司，但是作为被并购的单位，仍然可以相对独立地运营一个新业务。例如，抖音就是被并购进字节后发展起来的。所以在创业和就业之间，还存在着多种可能性。
这篇讲用户增长的文章比较有启发点的是里边的用户数据模型，对模型进行科学分析后找出优化的关键指标，也就是杠杆最有效的地方，然后用常见的增长激励方式就生效了。当然文章里也说了“我们必须运用我们的判断力来将这种游戏机制适应 Duolingo 的环境。”：
DAU、WAU 和 MAU 可以很容易地从这些区块中计算出来，这使得随着时间的推移对它们进行建模变得容易。这是该模型的一个关键特性。此外，通过操纵箭头所代表的比率，我们可以模拟随着时间推移这些比率的复合和累积影响；换句话说，这些比率是产品团队可以拉动以增长 DAU 的杠杆。
在创建模型后，我们开始每天拍摄数据快照，以创建过去几年来所有这些用户群和留存率如何逐日演变的历史。利用这些数据，我们可以创建一个前瞻性模型，然后进行敏感性分析，以预测哪些杠杆对 DAU 增长的影响最大。我们为每个比率运行了一个模拟，在三年内每季度将单个比率移动 2%，而保持所有其他比率不变。
Rust专家讲Async现状的文章，这个问题在Python里也有，大多数人只知道Async/Sync用起来比较麻烦，不知道它的来龙去脉，作者在文章里引用了几个讲问题本质的链接，可以有一个深入的了解。另外作者之前写的选择 Rust 语言：Should I Rust or should I go?也可以看看。
这个作者写的Git的故事蛮生动的，而且旁征博引，里边可谓是英雄辈出了，当然软件版本控制系统还有许多别的支流，只是没有Git这么流行和被我们了解了。
作者之前写的Redis作者的故事，也可以读下。
一个 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.
Python async 感觉每过几年就要被人拿来否定下，这次是 Peewee 的作者，asyncio 和 Gevent 的项目我都经历过，感觉作者讲的挺有道理的：
Unlike asyncio, gevent transforms all the blocking calls in your application into non-blocking calls that yield control back to the event loop. As a result, you can continue to use the libraries you’re familiar with, and the exact same codebase can be run with or without gevent “enabled”
还好，社区这几年比较务实，在努力提升 Python 语言自身的性能。
之前一直看着 Redis 作者 antirez 的博客，现在台湾有个作者搜索整理了下 antirez 的故事，还蛮有意思的，antirez 也在 Hacker News 上回复了，开源软件就是这么有意思。
一个独立开发者开发的 ChatGPT 相关产品，做得挺好的，他总结了产品的结果，并说了自己对这个方向的看法：
在过去的这一个月里面，OpenPrompt 获得了：
- 16 万独立访客
- 1.2 万个注册用户
- 341 个付费用户
- 收到付款 0.98 万人民币
OpenPrompt 的愿景
- 当你面对一个无法想象大小的数据库，不知道如何挖掘数据时，给你一些例子，看看别人是怎么挖的。
- 当你面对一个聪明人，不知道如何与他交流时，我们给你一些例子，看看别人是怎么问的。
- 我们把这些挖掘，询问，变成可以复用的 Prompt，提升效率，节省时间。
今天看到善用佳软翻译的《Vim作者访谈 2022》，就看了下，感觉还挺好玩的，有两点比较有共鸣吧：
Software development is much more of a craft. And a craftsman uses whatever tools he thinks will get the best result, no matter if they are what everybody else is using or something different. And a good craftsman makes his own tools when needed.
Most people have their most productive time in the morning, therefore it is much better to set a hard time limit on when to stop. Perhaps make a note of where you were, then relax a bit, get some good sleep and continue the next morning. Quite often the problem that you were stuck with yesterday suddenly gets a new insight and you know what to do. The term “sleep on it” actually works, at least it does for me.
最近折腾 Kafka 的迁移和高可用时，两次碰到了这个坑，所以专门记下来并分享下，就是 __consumer_offsets topic 的 replication factor 一定要大于 1，具体可以看上边链接的文章，讲得非常清楚了。另外再说一个我自己碰到的误区吧，Kafka 停止的脚本是 kafka-server-stop.sh，但是脚本执行完后 server 是要经过一个清理的过程才会停的，所以如果看进程还在的话要等一会儿，不要着急着直接杀进程，否则可能会丢失数据，而且下次再启动时恢复又要好长时间了。