Year in Review 2019 — 当数字生活与工作相遇

对我个人而言,2019 是充满变化的一年。

这一年,我从美国回到国内,走出学校,走上了工作岗位。地理位置和社会角色的改变,自然会在生活中有所反映。但或许是因为我习惯了比较简单而规律的生活方式,这些变化对我日常生活的影响,并没有想象中来得大。

相反,我生活中的另一个重要部分——数字生活——却因此迎来了不少新的挑战。而我过去一年的很多时间,正是花在了应对这些影响做出调整上。通过这篇文章,我想对自己目前为止的经验和思考做一次总结。

一、一次失败的叛逃经历——macOS 和 Windows 双平台办公记

(一)两个契机

在去年以前,Windows 已经是我一个渐行渐远的记忆。和很多同龄人一样,我也是在 Windows 环境下完成了对电脑的启蒙。但自从带着 MacBook 上大学以后,我就很久没有主力使用过 Windows 设备。

不过,去年的两次契机,却让我在多年后重新捡起了对 Windows 系统的学习。

先是在去年四月,我筹划为自己的房间添置一台小主机。主要的目的是拿它当软路由,以及外出时充当 iPad 的远程桌面。最初的计划是继续选择熟悉的 Mac,买一台刚获得重大更新的 Mac mini。但在调研的过程中,体积更小、成本更低、配置更灵活的 Intel 第八代 NUC 意外进入了我的视野。就这样,我迎来了自己很久以来的第一台 Windows 设备。

用作软路由的 Intel NUC8I5BEH
用作软路由的 Intel NUC8I5BEH

但更重要的契机还是在九月。参加工作后,单位为我配发了一台 ThinkPad X390 作为办公电脑。本来,我并不介意背着 MacBook Pro 上下班,对换用 Windows 办公的效率也没有信心。但国内办公环境毕竟还是 Windows + Office 主导,多储备一点相关经验没有坏处。于是,我便把这台 ThinkPad 当作主力设备,希望通过类似「断奶」的方式,驱使自己再次熟悉 Windows 平台的办公应用。

ThinkPad X390(来源:NoteBookCheck;我本来应该用自己拍的图片,但因为太懒没把这台电脑背回家……)
ThinkPad X390(来源:NoteBookCheck;我本来应该用自己拍的图片,但因为太懒没把这台电脑背回家……)

(二)另眼相看

尽管与 Windows 的重逢多少有些不情不愿的因素——一次是迫于贫穷,一次是迫于饭碗——但实际尝试的感受却让我颇感意外。

我承认对 Windows 是有些刻板印象的。这或许是因为我上一次主力使用过的版本还是 Windows 8——微软自 Vista 以后又一次「黑历史」。在 Windows 8 中,微软试图将针对移动设备的 Metro UI 推广到桌面端,但不仅显得格格不入,也让本就平庸的界面设计更加混乱、割裂。我还记得每次新装系统,都要忙不迭地装上第三方主题和 MacType 改善视觉风格。另外,我当时刚开始对命令行和代码产生兴趣,但 Windows 对于开发环境的支持很欠缺,连 SSH 这种基本功能都要另装软件,给上手学习带来了很大不便。因此,在叛逃到 OS X 时,其美观的界面和与 Unix 的亲缘关系,很难不让我如沐春风、乐不思蜀。

但去年重新上手 Windows 时,它的进步却让我另眼相看。

外观方面,Windows 已经获得了一套完整的设计系统——Fluid,系统的美观度和界面统一性由此都获得了显著进步。

Fluid 设计系统(来源:微软)
Fluid 设计系统(来源:微软)

Windows 也摘掉了「对命令行不友好」的帽子。例如,WSL (Windows Subsystem for Linux) 的加入,让用 Linux 命令管理、编辑 Windows 下的文件变得非常简单。我在工作中经常需要整理大批层级很深的文件夹,并对其批量重命名、比较差异等。通过 WSL,我可以继续使用熟悉的 findgrepdiff 等命令完成任务。这大大降低了我从 macOS 迁移时的陌生感。

原生的新一代命令行 PowerShell 也让我耳目一新。与基于文本流的 Unix Shell 不同,PowerShell 将一切输入输出当作「对象」。因此,即使一句简单的 echo "hello world" 打印出的字符串,也可以通过 .Length 方法获得其长度,或通过 .CompareTo 方法与另一个字符串比较。这在运行单条命令时或许体现不出什么差别,但在需要多条命令协作时就能节约不少笔墨。

运行在 Windows Terminal 中的 PowerShell(来源:微软)
运行在 Windows Terminal 中的 PowerShell(来源:微软)

软件的迁移也远比想象中顺利。在换用 Windows 办公之前,我并不担心会在应用软件的迁移上遇到困难。毕竟,浏览器、聊天软件这些常用软件基本都是跨平台的,而每天打交道的 Office 全家桶则更是在 Windows 上才能发挥全部实力。我担心的是,在 Mac 上熟悉的效率和自动化工具没有对应的 Windows 版本。

事实表明这种担心是多余的。Windows 上不仅不缺少自动化软件,而且很多还功能更强、成本更低。例如,快捷启动工具 Listary 不仅匹敌 LaunchBar 和 Alfred,还附赠了类似于 Default Folder X 的「保存」对话框增强功能;QTTabBar 加持下的资源管理器,几乎能让 Finder 无地自容。最令人印象深刻的还数 AutoHotKey,它的脚本能力实现起键位修改(代替 Karabiner)、文件监控(代替 Hazel)等功能不在话下,而且还分文不取。

Alfred 和 LaunchBar 的替代品 Listary
Alfred 和 LaunchBar 的替代品 Listary

最后,在我的 NUC 上,Windows 做起服务器系统也是有模有样。虽然可能不入资深运维人员的法眼,但 Windows 自带的 IIS、活动目录等管理工具,可以让我零基础实现内网 WebDAV、FTP 等服务的搭建以及权限管理;运行 OpenWRT 软路由组网的需求,也可以通过内置的虚拟机 Hyper-V 解决。反观 macOS,在苹果大幅削减 macOS Server 的功能后,这些任务反倒都要求助于第三方软件了。此外,Windows 远程桌面功能所基于的 RDP 协议,虽然不比 Mac 和 Linux 上的 VNC 适用面广,但功能和性能表现却更好,例如无须额外配置就能串流声音、自适应客户端分辨率等。这为我用 iPad 躺在床上远程访问桌面软件提供了很大便利。

通过 Jump Desktop 远程访问的 NUC
通过 Jump Desktop 远程访问的 NUC

(三)功亏一篑

本以为从此可以舒服地用 Windows 办公,但没过两个月,Windows 平台的各种痛点却又把我赶回了 Mac。

这些痛点中,有的是 Windows 自身的老毛病。让我最头疼的就是对高分屏和多显示器的支持不足。由于经常需要打开多个浏览器窗口并同时编辑多个文档,外接屏幕是我工作中不可或缺的。我使用的是 21.5 寸的旧款 LG UltraFine 4K,物理分辨率为 4096 × 2304。在 Windows 上,如果按整数倍的 200% 比例缩放,屏幕元素就显得过大;如果设置为 175% 等非整数比例,实际效果就很考验运气,经常出现窗口边框正确缩放,内容却尺寸如旧或显示模糊的现象。在屏幕之间拖动窗口时,还会明显观察到比例切换带来的迟滞,甚至打乱窗口的布局。加上 Windows 顽疾一般的字体渲染问题,高分屏反而在很多时候让使用体验「减分」。

此外,尽管 Windows 10 加入了类似于 macOS 的多桌面(或称工作区)功能,但在操作逻辑上却显著不同,让我感到困惑而难以适应。

在 macOS 中,工作区是依附于显示器的,其范围就是显示器的四至。因此,工作区可以在主显示器和外接显示器间拖动。将一个窗口拖到外接显示器上,也就必然把它拖到了另一工作区。

但 Windows 却采取了一种完全相反的逻辑:显示器是依附于工作区的,一个工作区同时包含了主显示器和外接显示器的空间。因此,你无法将工作区单独指定给主显示器或外接显示器,也不能将其在两者之间移动。将窗口跨越屏幕拖拽并不会改变它所处的工作区;如果此后切换工作区,这个窗口仍然会消失,因为两个显示器都在显示另一个工作区了。

macOS 和 Windows 上工作区功能的逻辑区别
macOS 和 Windows 上工作区功能的逻辑区别

我并不否认 Windows 的设计可能有其合理性,但至少这非常不符合我的需求。我用外接显示器主要就是为了将一些不需要经常操作、但需要保持关注的窗口(例如邮件、微信、参考文档)「钉」在固定位置,解放出另一块屏幕用于写作、检索等主要任务。Windows 的设计在很大程度上排斥了这种使用场景(我知道可以设置某窗口「在所有桌面上显示」,但这毕竟还是一种妥协,也缺少灵活性)。

另一些痛点则来自于第三方。软件方面,之前提及的进步基本只限于系统本身和微软开发的软件。一旦将目光转向第三方软件,时光似乎就又倒转回了上一个十年。Windows 上固然不缺软件可用,但它们的设计感和易用性却仍然普遍低于 Mac 平台。很多软件就像是一个厌倦了工作的窗口接待员:我可以帮你办成事,但也别指望给你什么好脸色。

不同软件风格和操作的统一性也仍然很低。随手打开几个软件,你的桌面很可能就变成了一张几代同堂的全家福:有的是崭新的 UWP 应用,肩挎时髦的亚克力质感侧边菜单;有的还保留了早年的 Aero 风格和 Ribbon 工具栏,闪亮的水晶图标掩饰不住与时代的脱节;更有披着 Windows 9x 时代灰色素装的长者,浑身上下透露出历史的沧桑感。

风格杂糅的 Windows 软件生态
风格杂糅的 Windows 软件生态

硬件方面,配发的 ThinkPad 在工作中的表现也令我大跌眼镜。平心而论,单位给我的型号算是很厚道的:X390 虽然定位低于作为旗舰的 X1,但仍然属于高端的 X 系列;i7 处理器、16 GB 内存和 512 GB NVMe SSD 基本也都是可选配置中的高档。

但这台机器完全没有体现出与其定位相称的素质。首先,X390 的屏幕效果十分堪忧。标配的 1080p 雾面屏亮度不足且色彩暗淡,仿佛刚从漂白水里捞出来。在打开几个浏览器窗口和 Word 文档的负载下,它的电池可以在两个小时内从充满降到 20% 以下,「轻薄便携」和「商用」的标签因此也只能是说说而已了。

更大的问题还在于性能表现。无论我如何调整节能和功耗配置,只要连接外接屏幕,X390 几乎必然会在几十分钟后开始降频,最终挣扎在 600 MHz—800 Mhz 的区间内,并且除非重启不能恢复。在这样的极端低频下,即使打开资源管理器这样的简单操作都会变得极端缓慢,更不用提浏览器和 Office 这类资源占用大户了。

X390 连接外接显示器——一场噩梦
X390 连接外接显示器——一场噩梦

ThinkPad 的性能优化问题成为了将我从 Windows 系统劝退的最后一根稻草。如果说操作逻辑的不同可以适应、软件质量的平庸可以忍耐,但在老板要求发去文件时突然死机,或者因为软件崩溃让数小时的工作功亏一篑,就是另外一回事了。

表面上看,这些软硬件问题并不是 Windows 的责任。但一个平台的软硬件质量,很大程度上取决于平台给开发者和厂商提供了什么样的资源。Ars Technica 的资深 Windows 撰稿人 Peter Bright 就曾在比较 Windows 和 OS X 的软件开发生态时,指出微软没有给软件开发提供足够的工具。例如,如果 OS X 开发者需要给软件加一个文本框,那么 NSTextView 不仅提供了统一的文本框样式,而且还附带了拼写检查、撤销、文本格式、自动折行等一系列相关功能。而换成开发 Windows 软件,很多类似效果的实现就需要自力更生,功能缺失和不一致性也随之而来。另外,微软为了维持 Windows 的兼容性,让系统背上了沉重的历史包袱,也削弱了开发者采用新技术、迁移到新架构的动力。

令人窒息的极限实验:在 Windows 10 上运行 WIN16 架构程序(来源:TechGenix)
令人窒息的极限实验:在 Windows 10 上运行 WIN16 架构程序(来源:TechGenix)

类似地,微软虽然不能手把手帮厂商优化 Windows 硬件,但至少可以为厂商提供更多的标准和指导。微软并非没有做过类似尝试,例如与厂商合作推出「Signature Edition」特别机型,或通过 Windows Hardware Lab Kit 认证指导硬件设计等,但似乎都沦于三天打鱼两天晒网,成效十分有限。

显然,要真正改善 Windows 平台发展不均衡的现状,避免让对于第一方软硬件的大力投入成为一种「自娱自乐」,微软还需要更大的决心和毅力。

(四)功不唐捐

尽管我重新拥抱 Windows 的尝试以失败告终,这段经历也没有让我空手而归。最明显的收获,就是我终于重新捡起了不少 Windows 和 Office 技能,认识了一批 Windows 上的优秀软件,并积累了常用自动化流程在 Mac 之外的实现方法。

其次,从一个软件爱好者的角度,深度使用 Windows 让我摆脱了对它的刻板印象和有色眼镜,在回过头来评价 Mac 平台时,也有了新的参照系。Mac 并不处处比 Windows 更好,相反,制约 Windows 平台软件质量的很多因素,如今在 macOS 上也有抬头之势。例如,半桶水晃荡的 Catalyst 让开发者和用户都感到困惑,macOS Catalina 激进的安全策略严重影响了第三方软件的正常运行,苹果开发文档的质量出现明显下滑;等等。

macOS Catalina 上的地狱景象(来源:Twitter @tylerhall)
macOS Catalina 上的地狱景象(来源:Twitter @tylerhall)

最后,在两个系统上使用跨平台软件的体验,也让我感到跨平台的趋势并不会像很多评论认为的那样,让操作系统的区别变得无关紧要。Electron 等开发框架只是为软件运行提供了一个移动舞台,但最终的「演出效果」仍然取决于操作系统的后勤保障服务(如性能优化、字体渲染等)水平和开发者的用心程度。用户可能不关心或不了解自己用的是什么平台,但并不代表他们对于软件的差异和优劣就没有感知。正如 Twitterrific 的开发者在评价 Catalyst 时的那样,框架给跨平台开发带来的简便只是假象;没有为不同平台的针对性优化,没有对交互和设计的认真思考,就不可能做出真正优秀的跨平台软件。

二、「一切程序都是过滤器」——对生产力软件的重新思考

工作对我数字生活的另一项影响,是改变了我评价和选择生产力软件的思路。一方面,由于要处理的任务性质相对稳定,我对于工具的需求变得更加明确;另一方面,有限的闲暇时间也不允许我再以「玩玩具」的心态,四处尝鲜和频繁迁移。

以评价生产力工具的典型代表——任务管理软件为例。此前,我所用过的任务管理软件不可谓不多,对于它们各自的特征也都略知一二。但如果问我如何选择,我还是只能诉诸功能多少。实际上,现有多数评测文章的思路,也是「甲软件中的任务具有某些属性,乙软件中的任务具有某些属性;乙软件的属性设置更灵活,因此更好。」

但这种「比大小」的思路多少有些颠倒了主次。任务是独立于记录介质而存在的,它产生于生活和工作的真实需求。任务管理软件并不能凭空「创建」任务,而只能「刻画」现实存在的任务。这种刻画可能有角度、详略之分,但刻画的对象——任务——并不因此而受到影响。Todoist 不支持设置任务的「开始日期」,但一项任务并不因为被记在 Todoist 中,就不可能到未来某天才有条件执行;OmniFocus 直到 3.0 版才支持为任务添加多个「情景」,但记在其中的任务显然不是随着版本升级,才「一夜之间」涉及了生活的多个面向。

OmniFocus 的组织层级,这反映了开发者对任务管理的理解(来源:OmniGroup)
OmniFocus 的组织层级,这反映了开发者对任务管理的理解(来源:OmniGroup)

此外,既然是刻画,就必然存在遗漏,因为可能的观察角度是无限的。但「遗漏」并不等同于缺陷,而是不同软件主动取舍的产物,也是它们各自的特征甚至优势所在。实际上,任何任务管理软件在本质上都是一个「过滤器」,都代表着开发者基于对「任务」这一对象的理解,创作的一套过滤规则。

这就解释了为什么任务管理软件市场看似一片红海,但仍有源源不断的新产品被开发出来——一千个用户有一千种对任务的理解角度,任何一种描述方式都有其潜在的受众。OmniFocus 的追随者可能很难想象一个任务没有开始日期,但 Todoist 阵营却认为这是为了一览无余和便于管理,需要开始日期反而说明任务拆分得还不够细。反过来,其他软件的用户可能习惯了将任务随意移动,但 OmniFocus 却坚持任务必须依附于项目,而不能被直接放在文件夹中,否则就可能说明分类存在赘余

可见,选择一个任务管理软件,就是选择一种对任务的描述方式,就是在给开发者所宣传的那套过滤规则投票。既然如此,评价的标准就不应该是「比大小」,而是这些方式和规则在多大程度上符合自己的理解、契合自己的需求。

同样的方法也可以推广到其他生产力软件的选择上。例如,对于写作类工具,要被刻画的「对象」就是文档。那么,一份文档是一篇独立的作品,还是完整项目中的一页草稿?整理文档的方法除了标题和日期,是否还包括写概要、贴标签?文档能不能加附件、能不能相互引用?

对于这些问题的不同回答,最终就反映为软件的不同功能体系和操作逻辑。如果采取「白纸加铅笔」的极简模式,就会做出 Byword 这样的纯 Markdown 编辑器。在此基础上引入文档库、附件等概念,就逐渐进化到 iA WriterUlysses 这些写作、管理一体化工具。

而如果将复杂度推到极致,将写作描述为一个系统性、多阶段和非线性的项目,就催生出了 Scrivener 这样的「写作 IDE」。它的强大和复杂,正是因为开发者通过标签、关键词、概要、完成状态等足够多元的角度刻画文档(尤嫌不足的用户甚至可以自定义所需的属性)。而 Corkboard、Outliner 等令人眼花缭乱的功能,本质上都是一些预置的过滤规则,以将具有特定属性的文档筛选出来,并以卡片、大纲等形式呈现。

Scrivener 针对写作者设计的各种视图(来源:Literature & Latte)
Scrivener 针对写作者设计的各种视图(来源:Literature & Latte)

Scrivener 往往被认为特别适合小说等长篇写作。究其原因,正是它对于写作这件事的描述方式精准契合了作家的需求,例如以鸟瞰视角随意排布记录灵感的卡片、以时间线方式串联涉及特定角色的段落等。反过来说,如果你的需求只是做速记或写短文,或者习惯一气呵成的写作方式,那么自然会对 Scrivener 的体系和设计感到繁琐和困惑。

这种将软件看成过滤器的思路并不是我的原创。在初版于 1994 年《Linux 与 Unix 哲学》Linux and the Unix Philosophy)一书中,Mike Gancarz 就阐述过这种思想,并将其上升为 Linux 与 Unix 的一种「信条」。在他看来,计算机不能创造信息,只是在处理信息,把数据从一种形式转换为另一种形式——进行过滤。

当然,Gancarz 的写作对象是开发者,意在通过让他们认清软件作为过滤器的角色,在开发时注重提高兼容性和普适性。但换一个角度,这也能指导用户在选择软件时,更多地从自身出发,而不是颠倒主客,「拿着解法找问题」。

你可能发现我还没有介绍自己最终都选择了哪些生产力工具。但如果我上面的说理是成功的,你现在应该也不关心这个问题的答案了。

三、如何「自动」别人——自动化的局限

去年年底,一篇题为《别学写代码——学会自动化》Don’t Learn to Code — Learn to Automate)的文章在 Hacker News 上被贴出并受到热议。文章本身的观点并不新颖,无非是鼓励读者不要畏惧编程的学习门槛,而是从发现身边可以被自动化的任务做起,在需求驱动下自然而然地入门编程。

但善于批判思考的 Hacker News 用户们似乎对此不太买账。他们指出,在工作环境下,自动化并不总是可行的。例如,排名最高的评论就认为,「对于切近问题的员工,问题不在于没有能力自动化,而在于有某些因素压倒性地阻碍着自动化的动机。」

根据这则评论和其他用户在回应中的补充,这些「阻碍因素」包括:自动化方案的适用面过于狭窄、失败导致的翻工成本、向他人解释或推广的困难等。概言之,在工作环境下,自动化可能带来的有限收益,无法覆盖为之付出的成本和潜在的失败风险。

如果放在过去,我可能会有些不以为然——哪里有什么阻碍,无非是惯性思维作祟罢了。但在自己参加工作、并经历了几次不那么成功的自动化尝试后,我对于这些评论描述的问题也有了些第一手的体验。

我从事的法律工作,虽然通常被认为更接近于所谓的脑力劳动,是「创造性」的。但「创造」却也是以大量的重复性劳动为基础的。例如,为了支撑法律报告中的一句结论,事前可能需要到商标局的网站上搜集数百个商标的申请信息,或者到数十个政府部门网站上核查是否存在负面记录、并截图汇总等。

按道理说,这些都是适合用自动化代替人工的典型任务。我在刚上手时,也是第一时间感到手工处理的低效,并积极寻求通过程序解决的方式。但事实证明,这些尝试最终并没有明显减少完成工作所需的时间,而其原因也印证了 Hacker News 的上述讨论。

简化从商标局网站收集商标信息的 KeyboardMaestro Macro
简化从商标局网站收集商标信息的 KeyboardMaestro Macro

首先,自动化固然适合处理繁琐、重复的工作,但其逆命题却并不成立——繁琐、重复的工作未必容易被自动化。某些部门网站登峰造极的反爬虫、IP 限流机制,以及工作中某些明显不合理、却不得不遵从的格式要求,都可能为自动化带来无法克服的障碍。当然,这多少是因为我作为一个非科班出身的半吊子爱好者,编程能力确实有限。但即使有能力克服技术障碍,针对一个项目、一类模版找出的自动化流程,很可能因为需求、格式的细微变化,在其他项目、模版上毫无用武之地。自动化的「性价比」由此受到了极大限制。

其次,手工操作虽然繁琐,但却也具有结果可控、时间可预期的「好处」——只要老老实实做下去,总有熬出头的时候。即使因为失误耽误了时间,至少也能因为付出的劳动而博得点「同情分」,更容易得到谅解。相反,一旦在使用自动化的「奇技淫巧」时翻车,导致耽误期限或不合要求,只能自己承担全部的风险,而很难向他人解释。

再者,工作中大多数任务都是需要团队协作的,一个人效率的提高并不足以拉动团队的效率,但自动化却经常是难以被推广的。琢磨出如何使用 Word 的邮件合并功能,自动将上百张截图插入到多个文档的指定位置是一回事;但如何以一种通俗易懂的方式、向不知域代码为何物的同事介绍这种方法,就是我无能为力的另一回事了。

通过邮件合并为 Word 文档批量配图
通过邮件合并为 Word 文档批量配图

最后,从有些自私自利的角度来说,「活是干不完的」。即使通过自动化的方式更高效地完成繁琐的工作,由于这些任务本身并没有什么技术含量,也不会因此而收获更多赞许;相反,得来的可能只是更多的工作。

总之,当场景从个人兴趣切换到工作时,自动化就从一个纯粹的技术问题变成了一个同时涉及人际、组织关系和文化的综合问题,而这些附加因素是不可能靠代码解决的。一句话,你可以「自动」自己,却没法「自动」别人。

描述公司历史沿革的 TextExpander 模版
描述公司历史沿革的 TextExpander 模版

不过,尽管被现实泼了些冷水,我继续实践自动化的动力并没有因此被扑灭。每当被安排完成那些劳动力密集型的工作,我还是会首先考虑是否存在通过自动化更快完成的方法。结果,工作几个月来,我反而东一榔头西一棒地积攒了不少之前陌生的命令行脚本、网页前端和 Office VBA 相关知识,写起正则表达式也越发不假思索了。

这么做的动机在于,自己大费周章找出的自动化方案,诚然可能只适用于一次任务,但探索过程中积累的经验和技巧却是可以复用的。再退一步说,哪怕最终没有找到任何捷径,思考和尝试自动化的过程也至少能让我对于任务本身有更清晰的认识,在手工完成时少走弯路。

最重要的是,思考本身就是令人愉悦的。如果劳役终究无法避免,有什么理由不让自己更开心呢?

结语

如何总结工作对我数字生活产生的影响?某种程度上,它似乎让我变得更「挑剔」了。毕竟,当你从凭纯粹的兴趣驱动与设备和软件打交道,变为用它们服务于一些非常具体、需要为之负责的需求时,自然会在做选择时更加谨慎、更看重稳定而非新奇、更「功利」地计较投入产出比。

但挑剔的另一面也可能是包容。正因为知道了自己的选择是出于职业特定的场景和需求,才不会武断地否定别人的选择。正因为发现了自动化的诸多制约因素,才会尊重别人的操作习惯,不将自己的流程强加于人。

当然,我目前的工作经历还太过短暂,远不足以让我对这个问题做出定论。事实上,就在我试图通过这篇文章对现有思考做出总结的同时,现实生活的变化仍然在不停地形塑我的数字生活。但在这不居的变化中,仍然有一点令我稍感安心的发现:现实生活和数字生活的空间并不是此消彼长的。正如两个迎面相遇的地壳版块,碰撞的边界上将升起新的山峰。