什么职业更担心自己会猝死？程序员只能排第3 从设计到研发全链路 AI 工程化体系 | 新程序员|ai|自动化

什么职业更担心自己会猝死？程序员只能排第3 从设计到研发全链路 AI 工程化体系 | 新程序员|ai|自动化， 

什么职业更担心自己会猝死？程序员只能排第3

欢迎关注“新浪科技”的微信订阅号：techsina

文/董道力、高雅馨

来源：DT财经（ID:DTcaijing)

猝死与我们的距离，到底有多近？

今年春节期间，一则“B站员工过年加班猝死”的话题掀起人们的讨论。不论真相如何，这件事情都再一次勾起了不少人对猝死的恐惧。

把时间线往前推，近几年来关于猝死的新闻还有很多。

2019年11月27日，演员高以翔在录制节目时突然晕厥，节目组称医院诊断其为心源性猝死；2021年1月1日，《巴啦啦小魔仙》女主角之一孙侨潞因心梗猝死离世，年仅25岁；2021年1月5日，时尚博主“雅鲁藏布江女人”在北京飞往上海的飞机上，由于心脏骤停不幸离世……

除了被大家知晓的猝死事件，还有更多人在无声无息中被夺走了生命。据国家心血管病中心发布的《中国心血管健康与疾病报告2020》，在我国，每年有54.4万人逝于心源性猝死。相当于每分钟，就会有 1 个人因猝死离世。

猝死，已经成为悬在当代人头顶的达摩克利斯之剑。

#01

近6成00后担心猝死

最怕猝死的职业是主播

或许被过往的猝死案例敲响了警钟，不少人意识到，猝死距离我们每个人都并不遥远。

根据丁香医生《2021 国民健康洞察报告》，总地来说，超过一半的受访者都曾有过对猝死问题的担忧。

从不同年龄层来看，越年轻的群体，往往越容易担心自己会猝死。在00后群体中，近六成人有过“担心自己会猝死”的想法。而这一比例在70前群体中，仅为38%。

尽管猝死的诱因有很多，但根据丁香医生官方微博话题评论，加班值班是人们最担心自己会猝死的时刻。而对不同行业来说，担忧的程度也不尽相同。

如果按职业来细分，有71%的主播曾担心自己会猝死，在所有职业中占比最高。其次是快递员（60%）和程序员（59%）。

在最担心猝死的15个职业中，号称“宇宙尽头是编制”的公务员排行倒数第一。尽管近5成公务员表示担心过自己会猝死，但比起上榜的其他行业，他们的“生存压力”已经算相对轻松。

以均值52%为分界线，我们会发现，猝死压力较高的职业普遍存在着工作强度高、竞争激烈、自由度较低的特点。

比如最怕猝死的主播，别看直播间里的他们光鲜亮丽、热情亢奋，仿佛永远不会累，但主播行业头部效应明显，绝大部分资源已被头部大主播抢占，剩下为数不多的流量也成为众多小主播眼中的“香饽饽”，激烈的生存环境给从业者造成很大压力。

除此之外，工作节奏快、上播时间不固定、镜头前不能摸鱼等因素，也使主播们时刻处于紧绷状态。对他们来说，昼夜颠倒、饮食不规律、睡眠时间短是常有的事。

而快递员、程序员、自媒体工作者等职业，留给大众的印象无外乎辛苦、压力大、加班多。他们对于自身猝死的担忧，也超过了众多职业的平均值。

#02

为什么越来越多的

年轻人担心猝死？

为什么年轻人如此担心自己会猝死？

我们分析了知乎问题“为什么现在越来越多的年轻人猝死”中的回答，并总结出三个方面的答案——过劳的工作、不健康的生活方式与生理原因。

1. 过劳的工作

可以看到，工作是人们谈论最多的关键词，与之相关的加班、公司、过劳、上班等词也被频频提及。

不记得从何时起，打工人猝死的社会新闻已数见不鲜。2020年12月29日凌晨1:30，拼多多一名23岁女员工倒在了下班回家的路上，其内部通讯软件knock上还留着“肺宝为多多守边疆”的签名；2021年11月5日，比亚迪一员工猝死，根据打卡记录，其10月份有26天工作时长在12小时左右。

频频爆出因工作强度过大而猝死的新闻，让朝九晚十的打工人自动将猝死与加班熬夜联想在一起。而熬夜过程中，身体上可感知的变化，也让人忍不住担心猝死随时都会到来。

“因为工作原因经常熬夜加班，最近连续两天熬到4、5点钟，很明显地感觉身体吃不消。有时候深夜对着电脑心脏会疼，头也很疼，很担心自己会猝死。”27岁的阿良告诉我们。

2. 不健康的生活方式

在上榜关键词中，熬夜、睡眠、休息的背后体现了年轻人不规律的生活作息。

即便为了上班/上课不得不早起，年轻人依然放不下晚睡的坏习惯。通过熬夜刷手机换取即时快乐，把一天中完全属于自己的睡前时刻无限延长，刺激着年轻人深夜亢奋的神经。

“白天上班特别的累，感觉一起床就开始进入工作状态，所以晚上属于自己的时间总是能晚睡就晚睡。”小于告诉我们，“看到过一些关于猝死的新闻，但仗着自己年轻，还是忍不住熬夜。”

《科学大观园》曾刊登过科普熬夜猝死的文章，其中提到：“尽管熬夜通常不会造成猝死，但是熬夜会影响心血管健康，增加普通人群心源性猝死的风险。”年轻人一边“作死”熬夜，一边在睡眠之外的地方努力找补，于是“朋克养生”“保温杯里泡枸杞”也成为前几年的热词。

3. 基础疾病等生理原因

当人们讨论猝死时，身体、心脏、疾病等关键词也被提起。

据中国新闻网报道：“导致猝死发生的原因非常多，但大部分人都是因为已经有了疾病基础。例如，心脏疾病导致的心源性猝死，占猝死病因的75%；剩下的25%则是非心脏疾病，包括脑血管病、肺栓塞、电击、溺水等。”

如果本身存在心脏病、高血压等疾病基础，那么发生猝死的可能性将更高。而每当出现胸闷心悸和心跳加速的症状，大家内心关于“猝死”的那盏红灯也就亮了起来。

#03

无法逃离的猝死诱因——过劳

英国科学家贝弗里奇说：“疲劳过度的人是在追逐死亡。”

2019年5月，世界卫生组织更新《国际疾病分类》名单，将感觉精疲力尽、厌倦工作、想逃离工作岗位、心情愤懑、工作效率低等“过劳”现象列入影响健康状况或与健康相关联的因素。

根据2020年《中国急救医学》的一篇医学研究，劳累是造成猝死的主要诱因，占比达到24.53%。

自八十年代起,“过劳死”成为日本的热门话题。但“过劳死”的悲剧，并没有让打工人停下“拿钱换命”的脚步。相反地，这一现象在如今的社会环境中更加普遍。

日本学者森冈孝二曾对“到处都是工作狂”的日本社会进行过研究，他的结论对今天的中国也很适用。

1. 互联网让人们没有下班时间

在互联网尚未普及时，打工人下班后的时间是属于自己的。但随着日常工作与生活的界限逐渐模糊，“24小时on call”成为不少企业的常态。随时会响起的“钉钉”“滴滴”声，让打工人时刻处于紧张状态。

根据后浪研究所《2021年轻人加班报告》，仅有12.54% 的受访者表示下班回家后从不需要加班。超过6成人，会在下班后会回复工作消息。

去年6月，字节跳动一名实习生因在晚上12点前睡觉，没能及时支持工作，在公司内“一夜成名”；12月，有网友向财经博主匿名投稿，称因为晚上九点在家敷面膜，被公司处罚抄写材料。

（据截图，该员工被公示处罚，图源：网络）

当移动互联网拓宽了工作场景，活在5G通讯下的职场人再也没有下班时间。对长期处于紧张状态，随时待命的打工人而言，过劳自然出现。

2. 学历泛滥，工作细化，内卷加速

打工人内卷，造成了日益紧张的工作环境，也是导致过劳的重要原因。

随着社会优秀人才数量的不断攀升，学历的含金量随之被弱化。企业员工沦为 “螺丝钉”，守着眼前日复一日毫无挑战力的工作，眼看着个人竞争力降低，深感自己处于随时可以被取代的状态。

焦虑，迫使打工人通过不断的加班、延长工作时间，以求证明自己的价值，与此同时，过劳产生。

3. 生活成本高，消费主义盛行

如果说，以上两种原因促使了打工人加班过劳，那消费主义的泛滥，则成为维持打工人过劳状态的“燃料”。

据猎聘《当代年轻职场人现状洞察报告》，近七成90后为了赚钱而忍受加班。在消费主义社会的影响下，人们对于生活水平的要求不断提高，尽可能多地搞钱，以满足自己不断蓬勃的消费欲已经成为常态。

4. 娱乐上瘾剥夺睡眠时间

没有娱乐活动的人生是不完整的，“奶头乐”早已成为商家“绑架”消费者生活的利器。现代娱乐活动，有诸多模式与“成瘾性”进行了强绑定，如网游、短视频等。在这类娱乐方式的不断普及下，年轻人进一步丢失了睡眠时间。

华米科技公布的《2021年中国人健康状况报告》显示，2021年中国各年龄段人均睡眠时长均未达到7小时，2021年人均睡眠不足7小时天数相较2020年均有所增多3-4天。

本就处于过劳状态的打工人，其宝贵的睡眠时间又被娱乐活动不断占据。属于他们的过劳状态再次升级。

写在最后

《过劳时代》作者，被称为“过劳死问题研究第一人”的森冈孝二，在2018年死于过劳。

当员工加班猝死的新闻逐渐淡去，黑夜中大厂的灯火依然通亮。因为程序员过劳而建立的996.ICU网站也逐渐被人遗忘。

也许同这个网站一样，一个个鲜活的生命在猝死后，换来的不过是一阵唏嘘，而后便逐渐被人们遗忘，直到下一个猝死的人出现。

中国医学救援协会会长李宗浩说过，科学家早就认识到，世界上约有1/4的生命是在不该失去的时候过早终止的。意外是生活的一部分，这是成年人深谙于心的游戏规则，但它并非不可改变，尤其当赌注是以生命为代价。

借用腾讯某员工的话——“我们离ICU，真的就只有‘再加一次班’的距离，好好想一想，用你健康的、年轻的、充满活力的躯体，用一个又一个20多小时的高强度加班，换来一个所谓的‘业务突破奖’，一个玻璃制奖杯，一份几千块钱的激励奖金，到底值不值得。”


从设计到研发全链路 AI 工程化体系 | 新程序员|ai|自动化

【导读】将大模型技术产品化和工程化已成为业界各大公司在研发 AI 大模型之后的重点发力方向。这一转变促使 AI 工程化从概念验证迈向实际应用，展现出广阔的应用前景。本文将从设计与研发领域出发，深度分享 360 在工程化流程中的独特实践经验以及对未来 AI 工程化发展方向的独到见解。

本文出自 中的演讲，同时收录于《新程序员 008》。《新程序员 008》聚焦于大模型对软件开发的全面支撑，囊括 Daniel Jackson 和 Daniel Povey 等研发专家的真知灼见与“AGI 技术 50 人”栏目的深度访谈内容，欢迎大家点击订阅年卡。

作者 | 杨龙辉

责编 | 屠敏

出品丨新程序员编辑部

在大语言模型迅速发展的背景下，AI 工具和产品不断涌现，如广泛用于代码编写的 ChatGPT、GitHub Copilot，可以文生图的 Midjourney、轻松在本地运行大模型的 Ollama，以及 360 的智脑、文心一言和通义千问等国产 AI 工具，几乎覆盖了我们日常设计、编码、办公、协作、聊天、音频、视频等方方面面。只要是涉及人机交互的场景，基本上都能找到一个具有 AI 功能的工具。

从工程化角度来看，AI 工具在产品交付过程中，从需求分析到产品设计、开发再到上线运营，可以在很大程度上辅助人类工程师，提高工作效率和质量。我们团队早期就开始使用各种 AI 工具来提升效能，不过，这些多样化的工具，种类繁多，也带来了一些困扰。

首先，从应用性上来看，不同人对工具的使用效果差异很大。有些人使用 ChatGPT 生成代码时非常高效，而有些人则需要花费更多时间调试。此外，某些工具的使用方式复杂，未必适合所有人。

其次，团队协作也是一个问题。使用第三方工具时，往往依赖于它们的平台能力，导致与公司现有系统的集成度不高。如果遇到问题，解决方式通常是通过口口相传，缺乏系统化的知识共享。推广和培训这些工具需要成本，团队成员学习使用这些工具有一定难度，最终导致团队在一致性、标准化交付流程上也会存在差异化。

因此，我们团队内部讨论了两种解决方案：

第一种方案是开发 AI 工具。我们可以将外部的开源工具或插件（如 VS Code 中对接 GPT 的插件）集成到现有的软件中。经过研究，我们发现这种方式灵活性高、建设周期短、能够快速实现工具的统一和提升应用性。然而，缺点是集成度较低，只能在某些环节上起作用，无法进行上下游的深度集成，也容易形成数据孤岛。要想解决数据孤岛问题需要做更多的数据分析和整合，工具可能会演变成一个产品。

第二种方案是直接开发 AI 产品。我们思考是否要在软件开发的各个节点上使用领域模型，基于领域模型，再进一步构建 AI 服务，与工程化进行深度融合。这种方式不仅为平台提供 AI 能力，还能在模型之间实现互操作。例如，模型可以根据自然语言需求自动生成页面设计和代码，最终只需人工确认后上线。这种方式的优点集成度高、应用性强、数据可以在统一的工程服务中进行共享和二次调优。缺点是此方法建设成本高，需要在工作流程中构建领域模型。

两种方案各有利弊，究竟该如何抉择？当时的我们思考了一点，即这两种方式究竟哪一种可以实现工程效率最大化，因为工程的本质就是既提供了团队的规范，又能使团队的效能和产品质量达到最大化。基于这一点，我们选择了朝着 AI 产品化的方向发展，可以让整个工程化的链路能够迎来二次革新。

当然，这其中也有挑战：

成本问题：我认为对于小团队而言，直接使用开源工具或快速插件等AI工具即可，能够快速提高团队效率。但是，如果团队需要微调并部署一个大模型，还需要构建上层服务，那么首先要考虑团队是否具备相关专业能力。其次，微调模型需要依赖数据和机器成本，都是需要考量的因素。

安全隐私：隐私问题是一个重要考量，使用第三方模型可能会有数据泄露风险，尤其是对于以安全为主的 360 来说，这是不可忽视的。

能力限制：当前 AI 的泛化能力有限，对于未见过的数据，它往往会给出不准确的回答。其次是适配性问题，目前的 AI 在处理复杂任务时仍有局限性。

综合考虑这三个问题，可以发现 AI 在能力上有很大的改进空间。从 AI 的能力来看，它可以辅助人类完成一些工作，弥补人类在编码或设计上的不足，缩短交付周期。此外，AI 还可以处理重复性工作，提高工作效率和产品质量，辅助团队实现效能最大化，进而提升业务结果。

360 工程化流程的演进

现在，我们在朝着产业化方向发力的同时，360 的工程化流程也在不断地演进。在内部，我们按照三个步骤推进（见图 1）：首先建设统一的基础云服务平台实现自动化；其次基于流程自动采集数据构建数字化，因为在这个 AI 时代，数据至关重要；最后进入智能化阶段，建设领域专家模型赋能工程化。

图 1 效能云自动化与数字化建设

在自动化架构层面，当拿到产品需求后，我们会进行需求拆解，并自动分配给相应的设计和开发团队。设计师收到任务后，会创建对应的画板；研发人员则会创建相应的分支。通过任务这条主线，我们将工作流程串联起来。设计师完成视觉或交互设计后，可以提交给开发团队。开发团队通过视觉通信打开集成开发环境（IDE），进行编码、合并请求（MR）、提测。测试环节会自动创建提测单，进行冒烟测试、集成测试或验收测试。测试无误后，需求自动流转至上线，通过持续集成/持续部署（CI/CD）完成上线审批。需求完成后，我们会进行归档，并制作数据看板展示业务、性能和效能指标。

自动化架构的效能云基础服务包括数据、流程、权限、技术架构、规范和工具等。下一层则为需求池、代码库、设计工具、CI/CD、物料市场、审计流、安全、日志和监控等能力。最底层则是由 360 的三大平台提供支撑，分别是用于需求管理的极库云；用于管理设计物料如设计稿和设计工具的设计云；作为一站式研发平台的 FinerWork。

360 在数字化进程上从四个维度和三个视角展开，即从交付率、交付质量、交付成本和交付能力四个维度进行数据收集，立足于个人、团队和项目三个层面的视角。这一阶段的数据来源均是交付周期自动化采集。

数字化之后，进入智能化阶段。智能化分为两个方面：

一是构建领域模型：在办公、设计、代码、测试等不同领域建设专家模型，专家模型会根据对应在设计侧或研发侧的一些场景进行 AI 的能力的提供。例如，设计侧可以利用文生图功能或对 Sketch、Figma 插件进行能力增强；开发侧则可以通过代码生成、AI IDE 增强等方式提供支持。这些功能依赖于 360 智脑大模型。

二是基于领域模型构建 Agent 服务。在模型建立和服务能力就绪后，我们构建 AI Agent，使其能够自动完成简单的重复性任务。

此处，我们将从设计和开发两个方面寻找机会点和探索方向，因为在产品交付过程中，设计和开发阶段的需求弹性较大，因此成为提升交付速度的关键。

我们对设计与研发的过程进行了分析，绘制了流程图（见图 2），从中发现了两个关键痛点：设计团队从灵感迸发到具体化设计、优化完善的过程可能充满反复和不确定性——我们称这一阶段为“绝望的深渊”，因为它往往需要大量的尝试和修改，甚至没有产出；开发团队从工程初始化到实际编写业务逻辑的过程同样增速缓慢。

图 2 设计与研发过程分析

针对这两个核心场景的痛点，我们在模型构建时特别关注，通过建立领域模型赋能平台，向设计和开发平台提供 AI 能力。例如，通过文生图功能帮助设计师快速生成初步设计稿，从而显著提高设计效率；通过代码生成、代码审查和代码聊天等功能，协助开发人员进行代码设计和编写，提升开发效率。

360AI 在工程化中的实践

基于行业痛点和应用场景，我们将领域模型与业务相结合，构建了设计侧物料平台和研发侧工程平台。

设计侧物料平台

在设计物料平台方面，我们内部开发了一款名为“缤果 AI”的产品，该产品支持多端应用，包括 Web 端、Figma、Sketch 以及 Photoshop 端。这款产品集成了设计广场、AI 小工具和图片创作等功能。为了支撑这些功能，我们构建了一套产品架构（见图 3），涵盖了从模型到应用场景的解决方案。

图 3 缤果 AI 产品架构

在模型层面，我们依赖于 Stable Diffusion，基于此模型，我们进行了大量的微调工作以创建多个基础模型。随后，我们利用 LoRA 技术进一步微调风格模型。最终，我们将基础模型与风格模型结合，形成融合模型，用于特定场景，这些模型通过 Stable Diffusion 提供的 AI 能力集成到产品中，进而构建服务层，提供文生图、图生图、图片反推、延展以及线稿上色等功能，从而支持营销电商、定制化以及其他通用场景。此外，“缤果 AI”增强了设计工具 Figma、Sketch 以及 Photoshop 的功能。

在模型微调的过程中，我们总结出了一套被称为“631”的方法论：数据占 6 分，参数占 3 分，剩下的 1 分为“玄学”。之所以提及“玄学”，是因为在实际操作中，即使数据和参数都准备妥当，也可能得不到预期的结果，需要反复调试才能达到满意的效果。

微调过程包括数据准备、数据标注、参数调优、模型训练和结果测试。缤果 AI产品中，我们主要是对基础、风格模型做数据采集。具体而言，我们使用 Dreambooth 来训练基础模型，而 LoRA 则用于训练风格模型。

在数据准备完成后，我们会进行数据标注，使用封装的 Factory 库，利用 WebUI 能力先自动打标，然后导入到第三方工具，再进行人工筛选二次打标确认。没问题后，我们对模型进行参数调优，其中训练轮次和学期率是最重要的两个参数。接下来是模型训练阶段，我们会监控损失函数(loss)的变化趋势，一般认为损失值接近 时，模型训练结果较为理想，但最终仍需以实际测试结果为准。

基于“缤果 AI”，我们尝试将其应用于营销图片场景，还与智能硬件如 360 手表联动，通过使用“缤果 AI”替换底图，可以大幅缩短交付周期并提高效率。

研发侧工程平台

在研发工程方面，基于一站式的研发平台 FinerWork（见图 4），我们为研发提供了三大场景 AI 能力加持：聊天、代码和工具。产品架构底层依赖于 360 智脑模型，微调出代码聊天、代码补全、代码审查等领域模型。这部分的模型微调方法与设计侧物料平台相同，因此不再赘述。

图 4 FinerWork AI 产品架构

接下来，我们将着重关注 CodeChat 模型数据方案中的 npm 私有源文档数据采集与处理（见图 5）。这一过程分为数据采集、构建 Prompt、数据标注三个阶段。数据采集主要来源于工程平台的自动流程，以及代码工程中的流水线安装错误日志、IDE 安装、运行错误上报、私有包服务数据。

从关键数据中我们去提取一些标注，比如一些 OS 版本、语义化版本号、主版本文档功能等。有了这些信息之后，构建指令供大模型进行分析，分析结果经过人工审核确认后，用于扩充数据集，确保数据集的质量。完成数据准备后，开始进行模型训练和结果测试。

图 5 CodeChat 模型数据方案

微调后的 CodeChat 能够提供代码解析功能，并允许用户一键打开 IDE。应用场景包括流水线错误分析、IDE 内解决问题、APM 性能分析以及线上问题分析等。

AI IDE 也是研发侧工程平台的另一个重要组成部分，我们通过 AI IDE 做场景融合，最初使用 CodeServer，但后来选择了 OpenSumi。选择 OpenSumi 的原因在于其开放的 AI 能力、高度定制化的特性以及兼容 VS Code 插件市场的优势。基于 OpenSumi，我们提升了 AI 能力与 IDE 的集成度，实现了多种场景优化，如 AI Code、Inline Chat、智能终端、APM 性能分析、代码审查(Code Review)和即时通讯(IM)等。

AI 工程化未来畅想

面向 AI 工程化未来，我们从三个维度进行了深入思考：

基于大语言模型微调，产出特定领域模型；

基于领域模型进一步构建 Agent，增强复杂任务处理能力，让其能承担设计和研发中的重复性任务；

拥有 Agent 后，下一步可以实现多智能体系统（Multi-Agent）。

我认为 Multi-Agent 非常适合工程化，因为工程化的 SOP（标准操作程序）交付流程是固定的，从一个节点到另一个节点都是固定的，所以它可以对这些节点进行编排、共享、自主分工和协作。这也使得 Multi-Agent 能实现端到端的智能交付（见图 6），即从用户需求的产生到最终产品的交付，全过程实现自动化和智能化。当然，这一过程中依赖一个 Multi-Agent 运行时系统，该系统包含三个部分：

消息中心（Shared Message Pool）：用于所有智能体消息共享、发布和订阅；

工具库（Tools）：底层依赖各种 API、企业私有库、外部设置、外部搜索等工具来支持多智能体的运行；

Agent Detail：包含记忆模块、任务拆解和执行任务等。

举例说明，当用户提出开发一个 To Do List 的需求时，PM Agent 会将消息发送给 Engineer Agent。Engineer Agent 收到消息后，会通过内部记忆模块查看是否有类似的项目代码，并进行任务拆解和执行。任务执行完成后，消息会返回消息中心，通知 QA Agent 进行自动化测试。

图 6 Multi-Agent 实现端到端智能交付

整个过程非常流畅，而且每个 Agent 都可以有不同的演变，例如 Engineer Agent 可以进一步细分为专门负责写 React 工程的 React Agent，或者 User Proxy。同时，随着 Agent 模型的改进，未来工程化的各个节点可以实现从人类为主、Agent 为辅的参与模式逐步过渡到 Agent 为主导的过程，即实现从用户提出需求到 Agent 逐步完成所有开发和交付。

大模型刷新一切，让我们有着诸多的迷茫，AI 这股热潮究竟会推着我们走向何方？面对时不时一夜变天，焦虑感油然而生，开发者怎么能够更快、更系统地拥抱大模型？《新程序员 007》以「大模型时代，开发者的成长指南」为核心，希望拨开层层迷雾，让开发者定下心地看到及拥抱未来。

读过本书的开发者这样感慨道：“让我惊喜的是，中国还有这种高质量、贴近开发者的杂志，我感到非常激动。最吸引我的是里面有很多人对 AI 的看法和经验和一些采访的内容，这些内容既真实又有价值。”

能学习到新知识、产生共鸣，解答久困于心的困惑，这是《新程序员》的核心价值。欢迎扫描下方二维码订阅纸书和电子书。