这里记录过去一周，我看到的值得分享的东西。

周刊开源（Github：wmyskxz/weekly），欢迎提交 issue，投稿或推荐精彩内容。

题图

当地时间 7 月 18 日，英国泰晤士河进行一年一度的“鹅口普查”^[1]。英国每年 7 月都要在流经英格兰东南部的泰晤士河段开展天鹅普查，清点天鹅数量，测量它们的大小、体重并检查身体状况。

本周讨论：AI 会瞄准你的工作吗？

（本周文案参考：Will AI target your job next?^[2]）

当历史学家回顾生命史上划时代的时刻，那么 2022 年春季很可能被视为 AI 指数级增长的拐点。因为这个春天，一系列 AI 模型发布了，例如 DeppMind 的 Gopher、Chinchilla、Goto，Google 的 PaLM、Imagen、Minerva 和 OpenAI 的 DALL-E 2。

特别值得一提的是比较出圈的 DALL-E 2，通过输入简单的文字，它就可以制作出精美的独一无二的艺术画，比如输入：an astronaut riding a horse in a photorealistic style（一位宇航员以逼真的方式骑马）。

目前该技术作为免费工具开放注册，这不仅为最新企业的解决方案开辟了一个相当有价值的市场基础，也意味着人类设计劳动力的终结，因为人工智能将最终取代低技能到中等技能的平面设计师。在不远的将来，随着人工智能颠覆各行各业，所有类型的工人都将被取代。

你会被人工智能取代吗？简短的回答是：是的——这只是时间问题。

但实际上更复杂一些，这取决于您所做的工作类型和 AI 开发速度。

未来来得比你想象要快

人类的思维擅长线性思考，比如我们很容易可以得知，走 30 步究竟有多远，但如果让你走 30 个指数级增长的步数（每一次步数翻倍），你会走到哪里去？

在这种情况下，预估显得很困难，但答案很惊人，走 30 个指数级增长的步数之后，您可以环绕地球 26 次！

当我们分成每 10 个指数级增长来查看，我们会发现前 20 个指数级稀松平常，临界点发生在 20-30 个指数级之间：

这也侧面证明了，指数级的进步是难以察觉的，就像海啸一样。

一旦人工智能在自动化方面的效率仅为 1%，它就会很快达到 100% 的效率。

以谷歌的 AlphaGo 为例。AlphaGo 花了数年时间才在围棋游戏中达到人类水平，才能击败 2 级高手。但 5 个月后，AlphaGo 已经能击败世界上最好的玩家（9 级）。经过九个月的努力，一个名为 AlphaGo Zero 的连续 AI 以 100 比 0 的比分击败了最初的 AlphaGo。

我们大多数人都陷入了线性思考。如果时间倒回到去年，您疑惑人工智能是否可以抵消视觉设计师承担的 10% 的工作，可能答案显而易见地不太可能。

就像现在大多人数人认为 Github 的 Copilot 或 DeepMind 的 AlphaCode 在未来五年内完成 80% 的软件开发任务是荒谬的。大多数专家正确地指出了系统的所有缺点以及仍然存在的挑战。

但是，他们没有考虑到两个指数驱动的因素：

AI 计算硬件每年减少 60%，这转化为训练指数级更大 AI 模型的能力；
算法和软件方面不断涌现的新 AI 进步导致其自身在 AI 基准测试中呈指数增长；

这两个指数相互叠加，将形成一场巨大的海啸。只需看看新的 AI 模型在黄金标准基准 (MMLU) 上的执行速度有多快。

到这里，您可能会问：这些软件和硬件的改进跟我现在的工作有什么关系呢？这需要我们把指数思维和人工智能的快速发展代入到劳动力经济当中。

转折点

让我们从一个思想实验开始，像 Google 的 PaLM 这样最先进的 AI 能否自动化 5% 的内容编写或客户支持工作呢？如果是，作家和客户支持会代表着失业吗？

什么时候人工智能可以自动化 50%？

在连续体中的某个时刻，根本不会有足够的新工作来弥补人工智能模型的效率提升。最重要的是，人工智能正在并行处理许多这些创造性的工作职能。在其他工作也被取代之前，这不会让大多数人有足够的时间重新学习技能。当人工智能自动化水平超过临界点（下图红色虚线）时，工人将被取代，因为根本没有足够的工作岗位可供人类填充——人工智能会在那个时候接管他们。

每个工作职能的临界点将根据工作的供需情况而有所不同。

我们以软件开发人员为例，根据美国劳工统计局的数据，到 2030 年，软件开发人员的工作岗位有望每年增长 22%。这是一个约 5 倍的累积增长，这相当于到 2030 年，人工智能需要将 80% 的工作自动化，才能跨越工作供需的临界点。

OpenAI 估计 OpenAI Codex（为 Github 的 Copilot 提供动力）已经可以完成 37% 的编码任务。DeepMind 的非商业 AlphaCode在编码比赛中比 Codex高出 59%。让我们降低 OpenAI 的估计，假设 Codex 可以自动化 20% 的人类软件开发人员任务。这是这样的：

哪些工作会受到影响？

斯坦福大学的 AI 专家 Vivienne Ming 博士曾讨论工作的未来。她说：

“
人工智能或机器人最不愿意解决的问题就是走到草莓地，采摘草莓，然后把它放在农家摊上。

换句话说，自相矛盾的是，劳动密集型工作将是最后一个被自动化的工作。许多人曾经认为这些工作将是自动化的第一个工作，而创造性工作将最后被自动化。但这还没有证明。这正在成为人工智能自动化的新秩序：

创意工作，如软件开发、图形设计、写作、摄影等；
专业工作，如会计师、律师、项目经理；
需要手、手臂和/或腿的运动和灵巧的工作；

这一切意味着什么？

具有欺骗性的指数进步的性质可能会让人们对新技术发展不屑一顾，或者根本没有意识到它们。

但是，通过以指数方式思考，您可以为未来做好更好的准备。在你的工作、投资和业务中，都会询问新的创新是否会从指数变化中受益。如果是这样，是否在早期阶段进展看起来很平淡？还是沿着曲线走得更远？

事实上，AI 变革性的进步已经在今天发生。有一件事是肯定的，人工智能将是一场海啸。

热点新闻

1、美国城市的「小」赌注：拉拢大公司的居家办公员工^[3]

当居家办公成为一种选择，许多大科技公司里的员工都果断「逃离硅谷」。而硅谷以外的城市，则在尝试吸引这个群体。

有人会好奇，这些居家办公的人又不会在生活地的城市找工作，为什么要吸引他们？

《WSJ》最近一篇报道指出，这就跟过去城市间竞争招商建工厂一样，只是，这些员工是更低成本的「赌注」。

每吸引了一个「大厂员工」，城市就更有可能在未来成为科技公司分部的进驻城市，或是成为建厂地。

每当有办公室迁入，每位「大厂员工」会创造 5 个新岗位，因为他们会增加对医疗健康、教育和其他服务业的需求。

其中最成功的城市，要数美国俄克拉菏马州塔尔萨。其「Tulsa Remote」项目在 2021 年已吸引了 1360 位新居民，到了 2022 年这个数字估计会达到 2400。

竞争城市中，最高愿意为搬迁的员工提供 1.2 万美元现金补贴，另配健身房会籍、儿童托管服务和办公室。

不过，那些搬了家的员工都说，现金补贴很好，但真正让他们搬家的是城市本身。

2020 年搬到塔尔萨的 IBM 产品经理 Mathew 现在已经是当地四个公寓的房东，还成了邻里协会的副主席，另外还开始做新应用作为创业：

“
把我留下来的是这里的机遇和人。

2、长江白鲟被正式宣布灭绝^[4]

国际自然与自然资源保护联盟（IUCN）发布全球濒危物种红色目录更新报告，宣布白鲟灭绝，长江鲟野外灭绝。

学界确认一个物种灭绝的通行标准是：在该物种最后一次被目击之后的 50 年内，再也没有任何目击记录。

而白鲟最后一次目击发生于 2003 年——

一条 3 米多长的白鲟撞进了四川宜宾南溪县一名渔民的大网，拖着船直入江心激流，差点掀翻渔船。这尾白鲟在安装了超声波跟踪器放归长江后，因追踪它的快艇触礁造成故障，信号丢失，白鲟最终不知所踪。

1993 年葛洲坝下发现的白鲟，可能是留存于世最清晰的白鲟照片图片来源：大自然杂志

据 IUCN 报告，全球现存的 26 种鲟鱼均面临灭绝威胁，约 2/3 的鲟鱼种群处于极度濒危状态。目前，鲟鱼面临的主要威胁包括：

野生鱼子酱和鱼肉非法贸易带来的非法捕捞。
水坝阻断鲟鱼的迁移路线。
不可持续的沙石开采破坏了鲟鱼的产卵场。
栖息地的丧失。

此外，鱼类保护生物学专家危起伟带领的研究小组此前曾在 2017 – 2018 年对长江流域进行了全面捕捞调查。除了白鲟以外，还有 140 种记录在案的鱼类没有被发现。

3、程序员奶爸自制AI喂奶检测仪，预判宝宝饿点^[5]

一位程序员老哥 Caleb 最近通过摄像头 + AI 算法的组合，他搞出一套婴儿饥饿自动检测系统，能在宝宝真正开始哭之前就及时发现。

并且程序一旦判定宝宝的饥饿可能性达到 100%，就给他的手机发送通知。

根据理论，哭出声代表婴儿已经进入饥饿的后期阶段。此时要想直接喂奶都不太容易，需要先安抚一下宝宝情绪。

饥饿的早期表现还包括咂么嘴（Smacking）或舔嘴唇，反复张嘴闭嘴，吸吮嘴唇、手指或其他衣物玩具等。

Caleb 根据观察自家小孩的经验，分别编写代码给这些行为赋予了不同权重。

PS：向程序员大佬低头....

文章

1、纸飞机库^[6]（英文）

收录了世界上一些飞得远、停留时间最长的纸飞机设计，有视频并且支持打印；

2、为什么长期计划不起作用以及如何解决它们^[7]（英文）

文章指出，长期计划注定失败的原因，除了错位激励（本来应该奖励交付有价值产品的团队，反而最终会奖励遵循计划并按时交付功能的团队），还有以下三个根本的假设无法遵守：

什么都不会出错；
产品开发人员准确地知道他们必须构建什么；
产品开发人员确切地知道每项任务需要多长时间

一旦上面的三个假设被打破，那么计划就会被推迟，所以：与其让你的计划更好，不如让它更短。

3、写出完美的问题^[8]（英文）

Stackover 上每天有许多人提问，作者在文章中详细地说明了，如果你要问问题，应该如何做到「完美」。

我认为黄金法则有两个：

在提问之前是否已经做过一些研究，并在询问中尝试解释你所做出的努力和思考；
想象一下你正在试图回答你刚才提出的问题；

4、Build your own X^[9]（英文、Github 仓库）

学习一门你感兴趣的东西最好的方法就是制造一个它！

这是一个 Github 仓库，收录了各种各样的工具和技术的实现方法，让你自己从头搭建属于你的 X。

5、倦怠终极指南^[10]（英文）

倦怠是一种由长期工作压力引起的心理状态，它有三个关键特征：

1）疲惫不堪；2）愤世嫉俗的感觉；3）还有一种无力感；

如果你正处于「倦怠」的状态或者对此感兴趣，可以戳进去看看或者保存一下。

6、每天节省 4w 美元的数据库规则^[11]（英文）

数据最佳实践如何严重缩减您的使用费用的“真实世界”示例，不明觉厉。

7、面向编码人员的实用深度学习 2022^[12]（英文）

一共九节课程，比较特别的是这个课程被世界各地各行各业超过 10 万人学习过，经过改版的 2.0 版本；

8、异步 API 通信的设计模式^[13]（英文）

消息代理和 Topic 是扩展架构、减少依赖以及提高安全性和可扩展性的一种丰富方式。文章介绍了作者发现的一些有用的模式。

好奇星人

1、为什么没人骑斑马 | 答案如下^[14]

人类不是没有努力过。在 19 世纪的南非，有人曾经坐上了斑马拉的马车；但很可惜，大规模驯化斑马几乎不可能。

根据戴蒙德的说法，要让一种动物值得、且可能为人类所用，需要考虑多个因素：

首先是饲料成本，毕竟牲畜总不能吃得比赚得多；
其次是生长速度、繁殖难度，如果长得太慢或者没法在人工环境下繁殖，总归会带来困难；
性格也很重要，如果动辄杀人、或者太容易紧张而难以接近，当然就不是合理对象；
最后，群居结构也要考虑在内。大多数独居动物都难以驯化，除了猫以外——不过，驯化猫也不是为了放牧，猫在驯化后，依然保持着独居生活；

斑马是马和驴的近亲，属于群居动物，最高时速超过 60 公里/小时，比马的最高时速（80公里/小时以上）还慢一点，但又比驴快。

斑马未能被驯化，首先还真是因为它的性格。爱发火，而且发火还伤人。

而且，斑马常年面对被捕的风险，有着敏锐的闪避反应。再威武雄壮的套马汉子，也很难套住它，更别说把它带回家、驯化为自己的坐骑了。

除此之外，斑马的生理特性也让它们不适宜驯化。斑马在圈养环境中不能很好地交配，驯养斑马难免不可持续。它也无法承担马承担的许多负重、运输工作。

总结：强扭的瓜不甜，就不要纠结了。

言论

1、

“
优秀的管理者在模棱两可中茁壮成长。对于优秀的管理者来说，世界没有好坏之分——它很复杂。优秀的管理者会找到一种方法来获得出色的成果，而无需依赖简化人员和周围世界的模型。

--好经理写得好^[15]（英文）

2、

“
当我们专注于极少数可以投入大量精力的项目时，我们的效率最高。

--爱因斯坦原理：少做多做^[16]（英文）

3、

“
1）做你需要的工作；2）了解超出预期并制定超越预期的计划；3）通过讲故事和分享您的工作为自己辩护；4）学会组织你的想法和清晰地沟通；

--作为软件工程师如何拥有自己的成长^[17]（英文）

4、

“
创作者也一样，我们喜欢并在乎创造这件事，我们玩的是更长的游戏，每天，每周，每个作品，每个项目，一个接一个，一点进步再一点进步，继续下去。
我们不必要是最有天赋的，但我们可以是最在乎，最持续的。

--玩更长远的游戏^[18]

5、

“
如果你想知道自己的人生是否有意义，有一个最简单的检测方法，就是你试着把你从小到大到今天为止，你的人生经历说成一个故事，不是那种「我哪一年出生，我爸爸妈妈是谁，我哪年读小学」这样的故事，而是一个真的有人物有情节，有开头有结尾有中间高潮起伏，有重点的故事，也就是说它是有个驱动力驱动它前进的故事，它可能是个爱情故事、励志故事，但无论如何有个主导动机。
如果你的人生能够被说成这样的一个故事，那么就是有意义。

--梁文道^[19]（视频）

6、

“
我想告诉各位管理者，编程不是那种能赶出来的工作，每个人每天就只能编几个小时的程。所以，各位管理者，最重要的是用更少的时间换更高的质量。没几个人能每天编 12 个小时的程，这是明显要收益递减的。
总之，编程是种创造性的工作，你不可能每天都有那么长时间充满着创造力。一天干 12 个小时，任何人都会筋疲力尽的。

--Bruce Eckel^[20]