软件开发中的理性和感性决定（软件开发中的理性和感性决定了什么）

作者 | 邹欣 责编 | 梦依丹

出品 | CSDN（ID：CSDNnews）

问题

CSDN 这个 “软件” （网站，app，开发云、猿如意、插件、公众号等）在过去的很多年中，有很多用户使用，也有不少用户喜欢，还有更少的用户为之付钱。我们在商言商，怎么能让更多的人付钱使用我们的产品呢？用户的决定是怎么做的呢，我们有什么办法来影响用户的决定呢？搞软件看似高大上，其实还是有很多规律的。我们知道：

• 程序 = 算法 数据结构

• 软件 = 程序 软件工程

• 软件企业 = 软件 商业模式

在充分竞争的环境中，一个软件企业要生存发展，和美食一条街的一个小饭馆要生存发展类似，街上人流熙熙攘攘，他们对于一个小饭馆的态度不外乎是下面这个区间之内：

给我钱我也不去吃 … 如果免费，可以尝尝 … 看价格和就餐环境 … 很信任的品牌，有需要就吃 … 即使排队、涨价也要去吃

有人说 CSDN 比小饭馆高大上多了，它是一个有无限可能的平台！好，我们不妨用 “综合商城” 来比喻，如何？

给我钱我也不去，那里坏人多 … 那里没啥有意思的 … 免费逛逛，期待不要太高 … 有几个有意思的店但是环境太差 … 以前去过，后来有其他更好的商城就不去了 … 交钱办了会员，经常去那里的广场跳舞，吃饭看电影，很多优惠

大家在做这些决定的时候，是理性还是感性的呢？最近有一个做教育的团队不得不改行网上卖货了，结果买的人特别多，这些购买者，是做了理性还是感性的决定呢？

我的理解

在我的职业生涯中，我作为一个程序员，研发经理，到现在的 CSDN 职位，我越来越多的关注焦点，从具体的 “我的代码能编译”， “快速解决 bug”， 到 “软件能按时上线”， 到 “用户场景能满足需求”， 到 “研发团队的效率和成本“，到 “大量用户愿意成为长期付费用户”， 这些过程中，我和我的小伙伴们不断地做各种决定，开发出产品和服务，然后希望用户也做决定，成为我们的高兴的用户，能留存的用户，直至长期付费用户 … 每一步都有很多决定要做， 在这么多决定中，哪些是感性在主导，哪些是理性在主导呢？这篇博客，就谈这个问题。讲讲我自己的经历，和看过的别人的经历 – 这篇博客应该是感性的。

这个问题并不是只有在软件行业才存在， 经济学中的 “行为经济学” 也研究人在经济活动中的决定是怎么做的。我最近听了几个 Podcast （FreakOnomics），谈行为经济学，刚好把我以前读过的书和一些经历串联起来了，有些洞察和感想。这些感想我以前也有过，但是没有写下来，就淡忘了，后来又犯了同样的错误。我觉得应该写下文字，而且是公开的文字，让自己加深印象。大家工作都很忙，哪有时间啊？但是，我觉得，强迫自己 “闲下来写笔记”，还是有更好的长期回报的。我的前一篇博客也提到了 “思考，快与慢”，下面再来一句鸡汤：

闲是灵感的源泉，忙是思维的坟墓。

欢迎大家在评论区闲聊交流一下。

理性和感性

我们做软件开发，软件方面的创新，也有理性和感性的部分存在， 很多人以为，IT 界的创新和采用，大概率是理性的决定吧，其实也未必。

（一）美国硅谷有一个非常有名的研究院， Xerox Parc，1970-1980 年代，它一度孵化了很多颠覆性的 IT 技术，把这些技术集成起来，就是一个现代化的办公自动化系统 – PC，图形界面，所见即所得的编辑器，局域网。但是，它向各大公司推广这一套创新的时候，这些潜在的顾客并不买账。虽然有很多数据显示这一套系统能大大节约成本，顾客中做决定的人（公司里的大老板，负责 IT 采购的人，那时候还没有流行 CIO 这个头衔）事实上在做一个感性的决定：如果我冒险用了这个系统，而不是 IBM 系统，我会失去什么？结果，是这个感性的决定，让这个先行者失去了很多顾客。事实上，XeroxParc 的母公司在东海岸的老板，也是用感性驱动做了决定（“这些西海岸的研究员在胡闹什么？我不懂也不想让他们再胡搞了”）。直到 IBM 推出了 IBM PC，PC 的浪潮才真正掀起。

（二）我在微软公司的时候，曾经花了两年的时间来推动一件事情 – 在最新的 Windows 系统中推出某个重要改进。这对于简体中文版的 Windows 在用户中的价值是很重要的。当然，在微软这样伟大的公司，要说服决策者做这样的决定，还是需要很多工作，其中就有各种数据的支持。我们做了很多轮的实验的设计和数据收集工作，总部还有另外的团队独立来中国收集数据。我们也做了很多代码的改进，测试，等等。经过很多次小的讨论，我们终于和决策者开会了！在会上我展示了很多数据，从各个角度展现，这个改动是有很好的短期和长期的收益的。

但是在我展示这些数据和理性推导的时候，总部的一个决策者提出：

哎，你这个方面的数据说有 20% 的提高，但是我认为你们做调查的方式不科学吧，数据可信么？

哦，这个方面的数据，说有总共 12% 的提高，那说明这个项目的收益并不高啊，我们一定要继续推动么？

我正在想如何反驳 – 因为整个中国市场，12% 的提高也是很巨大的啊，怎么就是不高呢？难道Windows 在过去几年中曾有达到 12% 提高的改进么？这时候，一个来自第三方团队的资深的经理说话了：

当这个数据显示改进很大的时候，你说数据不可信，当这个数据显示改进并不是很大的时候，你就认为这个数据是可信的。你不就是铁了心不想要通过这个项目么？

这两位当时脸都涨红了，会议也陷入了沉默。他的话，像皇帝的新装里面的小男孩那样，童言无忌，指出了决策者并没有什么“理性决策”，而是一个感性的 “老子就是不愿让这个项目落地！”

（三）在大厂的环境中工作，很多情况下，是要说服别人同意你去做某事，一次我们要说服某 VP 同意某个提案，在和总监级别的大佬沟通的时候，他说， 你们的 PPT，摆事实，讲道理，列数据，很干巴巴的，这样的提案 VP 每天要读好几个，你们要把这个利害关系转化为这个 VP 有 visceral 感受的点！

啊？啥是 visceral？哦，原来他借用了 Don Norman 的设计的三个层次的术语。

就是要让被别人感到一种 本能/visceral 的反应 – 我的内心直觉就需要这个，我也说不清！

类似的描述还有：眼前一亮，内心柔软的部分被触动了，等等…

（四）用数据驱动的方式来分析问题，提出假设，再快速验证，这是很多人推崇的方法，特别是 Money Ball 这本书畅销之后。我也接受过这样的培训，还带队参加了更多的培训。我认为总的来看，这是有好处的，但是在具体的情况下，未必。

我们的一次实战产品设计中，产品经理想出了一个自认为好的点子，做了很多准备，然后我们请了一批符合条件的目标用户来接受访谈，几个人在采访室和用户聊，几个人通过闭路电视观察。其中的一次采访， 产品经理充满激情地向受访者描述了使用场景，最后问：你愿意用这个功能么？两个受访者都频频点头。产品经理就笔记本上数据的那个格子中打了✅，高兴地离开了采访室。我们几个在闭路电视中看到，产品经理离开后，两位用户互相望了一眼，都摇了摇头笑笑，也很快收拾东西离开了。

那么这个产品的点子，从理性的角度，得到了用户明确的首肯，但是从用户的肢体语言来看，用户根本就不理解，在产品经理热情的宣讲下，出于礼貌，回应了感性的点头，可能心想 – 快让老子回家吧。我们仔细分析那个产品经理的提案，充满了内部的术语，用户很难理解他在说什么。

在上面的几个例子中，理性地说服对方同意你的销售（产品/提案），都不太成功，为什么呢？因为每个人在面对一个产品/提案的时候，他内心的核心问题是 — 我能从中得到什么？我会失去什么？

（一）在很长的时间里，美国的 IT 部门，购买 IBM 等少数几个大厂的服务，才是安全的，我为何要冒险去支持一个第一代的颠覆式产品？

（二）这位决策者，在一年多前在日本推出了一个类似的改进，被当地的用户狠狠吐槽，作为不懂日文，也不懂中文的决策者，他心里想什么？

（三）这位 VP 心里扛的是巨大的成本和收益的 KPI，我们的提案，讲了很多技术方面的数据，微软的产品缺技术么？他心里 visceral 层次上，什么能打动他？我们能直接表达出这个意思么？

（四）一个产品提案，在数据上获得了 100% 用户的同意，但是用户是真的被说服了，还是出于感性的角度点了点头？产品经理有工资，只要做了提案，不管最后如何，做了就好。被采访的用户，公司会给他们几百块钱的礼物前来接受采访，只要点点头，摇摇头，就可以兑现礼物回家了。这个产品经理后来也把这个提案扔下不管了，那么，他和被采访的目标用户，谁是真的在乎这个使用场景么？

我参与了很多类似的产品提案讨论会，有一次在一个类似的会议上，一位大佬问一个热情播放PPT 的研究员：你真的相信你描述的这个未来么？如果你真的相信，你就去马上去做，不必列很多理由的！

从感性的角度，我们可以把一个团队的成员比作 “猪、鸡、鹦鹉”，他们合作开早餐店，他们都有想把产品做好的感性愿望，但是每个人的具体投入是不一样的：

猪：割自己身上的肉来做培根

鸡：每天贡献一个鸡蛋

鹦鹉：把别处听来的消息给团队转发一遍

你是一个决策者，你更重视谁的提案呢？

一个功能的成本

每一个功能，都是有成本的：

• 设计、实现成本

• 用户教育、习惯培养成本、打扰用户的成本

• 维护成本

• 以后要下线这个功能，还有很多其他成本

我以前在某研究院工作，和研究员一起做了一些创新性的图像特征提取的尝试，发现我们的提取的特征可以大大提高某种类型图像搜索的准确性。于是我们和搜索引擎团队联系，看看怎么把这个激动人心的特征放在搜索引擎上。对方的工程告诉我们，这个特定领域的图像搜索，虽然不是少数（不妨想象为搜索 “狗的类型”），但是和搜索引擎的主要图像搜索类型相比，就小两个数量级，和文字搜索相比，又小了一个数量级，因此，这个研究突破虽然很 excited，但是要放到产品上，“维护成本” 非常高。因为：

每天有海量的图片 视频进入搜索引擎，我们的工作流程是：

1. 我们的算法要快速处理这些图片 视频，抽取特征 （CPU intensive） –

2. 要把抽取出来的特征（一个向量，或者就是一些 100101010101011）放到内存中（memeoy intensive）-

3. 要保证搜索的检索速度不会变慢（因为99% 的搜索和 “小狗类型” 无关）

4. 这样，那些为数不少，但是占总量 （1%）的对“小狗类型” 感兴趣对用户会发现，这个搜索引擎太厉害了，太方便了，我要用它做默认的搜索工具！

在这个架构下，每天，公司在全球的机房中的一些CPU，内存就会分配来做上面的这些事情。后来我们的工程师花了大量的时间来改进抽取特征的速度，用更少的字节来表示抽取特征，直到我换到别的团队，他们都还没有能达到产品组的要求，后来似乎不了了之了。

这在大数据服务中，是比较常见的现象，我们当然要为高频的服务优化，谷歌也有 “牙刷（每天要用两次）标准”， 要看这需求的使用频率是否够高，是否值得用各种成本（特别是维护成本）来支撑这个功能。如果类似的事情发生在 CSDN， 我们要花费很多维护成本来做一个低频的功能 （例如用 OCR 扫描所有截屏，抽取其中代码，给用户使用），大家也会用数据分析用户获益/成本，我觉得这是非常理性的做法。

互联网大数据服务型企业的竞争，拼到最后，就是拼算法，效率，成本。

但是，还有一些功能，就是在某页面加一个链接，指向用户可能使用的下一个功能，这并没有什么成本，这个我们能快速上线么？还有一个办法，直接问用户他们的选择。

80/20 规律能支持我们砍掉用得少的功能么？

在网上流传一句非常广的话 百分之八十的用户只使用 Office 软件的百分之二十的功能，这的确是如此。但是，这个 ”观察到的现象“ 并不说明 因果关系， 不同的产品在竞争的不同阶段，有不同的重点。在下图的 “成长阶段”， 大部分软件都处于 “猛烈的功能军备竞赛” 的阶段，大家不断拓展软件能解决问题的范围，和易用性。

我用 MS Word 写了 4 本书，其中的 3 本书，是我用 Word 手动输入并修改的。我应该算是一个重度文字写作的用户，但是我的确在 80% 的时间里，只用其中的很少功能，可能 10%，但是我认为很有必要的一两个功能，是别人很少用的，别的编辑器也没有，只有 Word 有这些（而且以我习惯的方式）。所以，每个用户长尾有自己的长尾需求，一个面向百万用户的 App 就要提供那些长尾功能，挑战是要 “容易找到，确定性的交付” 这些体验。

我加入 MS Office 团队的时候 （1996），那个时候 Office 传统的 App 如 Word，Excel 的确已经有很多功能了，那时候就有这个 80/20 的说法，我们内部也流传自黑的各种笑话。还有进一步的数据说明，很多用户向 Word/Excel 团队提出的 “新功能建议” 大部分都是 Word/Excel 已经有的，深入分析发现，用户的痛点在于，面对众多的选择，他不知道他想要的功能藏在那个菜单和子菜单下面。“容易发现功能” 成为一个巨大的挑战。那个时候 Office 就开始建立数据采集的平台，根据数据， Office 还尝试了一个创新 – 在显示菜单的时候，先隐藏那些点击率低的项目，过了两秒钟左右，再来一个动画渐变，显示全部菜单项目。当时的项目经理想，大部分时间用户都是用那些最常用的，这样就替用户节约时间了。不料这个功能推出以后被骂死，因为

1）很多用户期待的是一个确定性，“我知道那个菜单项就在第四个，你不要把它提前到第二个，过两秒又改回到第四个！“

2）用户想找不常用功能的时候，更迷惑了。

在UX 设计的时候，一个用户场景 （scenario / story）的各个菜单，最好是达到 “don’t make me think” 的状态， 就安静地排列在那里，让用户习惯，这又怎么了？我们非要焦虑到每三个月改版一次，把 “blink” 改为 ”微社区“，然后又去掉 “微社区”，改回 “动态”， 位置从上挪到下方正中的圆圈，然后再挪到上面的另一个位置才显得我们做了事情么？与此同时那些真正影响用户体验的各种问题，我们的研发，产品，运营每天用我们自己产品的时候（如果用自己的产品的话），注意到这些问题了么？用户反馈读吗？转成 Jira 了吗？改正后告知用户了么？产品经理、研发带头人写这些bug 产生的模式分析么？

核心是让那些不常用的功能以一种自然的方式容易找到，而不是把它们从 UI 中删除。如果 Office 软件把它菜单中 最不常用 的 20% 从老地方删除，然后挪到 “Office” – “其他” – “不常用功能” – “这里”， 用户会出现什么反应呢？

我非常支持系统化地收集数据，系统化地看如何优化用户体验，改进质量，这里面有需要长期工作才能解决的，有短期工作就能解决的，有的并不太核心，有的可以做种实验，有些 bug 也不是一定要连夜修复，但是 团队的 “北极星” 指标还是对齐：CSDN 的 blink/动态 是让用户方便地随时随地交流 – 每天都有值得看的动态。

80/20 规律有时会给人带来不一样的思路， 有些是有趣的，有些对公司发展是有害的。我刚来 CSDN 的时候，听到这样的数据和观点：80 % 的搜索都是命中了 CSDN 前几年的博客，就是说，即使没有这两年的新博客，我们还能有 80% 的收入。我认为这是一个幻觉， 如果大家知道已经没有人在 CSDN 写博客了， 你看看用户还会来 CSDN 么！当新的内容和内容创作者离开 CSDN 的时候，他们是一个一个离开的，这数量虽然少，但是是非常危险的信号。我们要不断提高用户体验，让 CSDN 的创作飞轮转起来：

CSDN 有值得创作的话题 → 创作的工具很好用 → 创作后有真实的互动和流量 → 优秀创作者获得名和利的回报。

不正确的 KPI 对一个产品的影响

每个成员感性思考讨论之后，大家的意见会凝聚为一个产品的 KPI，这是理性讨论的结果。

从我自身的观察，很多大型的产品的衰败，是从使用率不高的功能的命运体现出来的。曾经一度 MSN messenger 和 Windows Live Space 是两款很不错的产品，一个是好友通信，一个是个人博客。它们一度有一个很好的功能：你的好友更新了他的space，那么他的MSN 聊天头像旁边就有一个小黄花出现，你点击后就可以看到这个好友的最新博客或者照片了。挺好的一个小功能。但是在一次改版后，这个功能就没有了。

我在微软研究院的时候，和 MSN 的团队打过几次交道，livespace 的团队倒没有，但是从类似的经历中，我可以想象出， livespace 的KPI 包括了 PV，如果有两种方式：

a）用户遍历他的所有好友的页面，看有没有更新

b）用户在另一个app上，只要看到了好友的更新，才来看网页

哪个对 PV 的 KPI 有利呢？

很多小功能就是在一些大功能的接缝处，帮用户节约时间和步骤，例如上面的那朵小黄花。但是，不正确的 KPI，往往统计的是 input metrics，或者过程性的metrics （页面 PV，搜索次数），这些指标当然有价值，但未必是 “用户满意度”。就这样，用户喜欢的小功能都慢慢没有了， 因为资源要投在 “大流量” 的地方， 用户越不来，产品经理就用越露骨的方法来拉用户，用户的满意度并没有提高，后来，Windows livespace 和 MSN 都没有了，当时微软还提出，用户可以多按几个按钮，转移到 WordPress 和 Skype，我也转移了，但是照片和很多联系人都丢失了 … …

后来我和同事们闲聊，有两个同事在不同的场合都说， 看到 MSN 的联系人头像旁浮现了小黄花，是我一天中最愉悦的时刻，微软的产品经理脑子装了什么，要把这种愉悦的体验删除呢？见不得用户用软件顺手么？

网上也有评论：https://www.zhihu.com/question/299685950 一个公司要发展，当然要做各种决定，例如为了成本砍掉一些服务，停止维护一些服务，等。但是我们要考虑的是，后续的收益是什么？是为了满足哪个 KPI 呢？

我们运营的是开发者的平台，我们也有海量的内容，如果简单的 ”海量内容“ 是我们的 KPI 的话，我们经常达到，有时还超额了。但是，用户真正关心的是 “高质量，确定性，能解决问题的内容”。

如果追求错误的 KPI， 我们会短期达到这些 KPI，但是它们的负面影响很难消除。

我们过份把用户 “物化” 为数据，把他们当作实现我们短期 KPI 的 “物料”， 用户也会弃 CSDN 如敝履，在知乎，头条上看看用户对 CSDN 对评价，这可能是 20% 不满的用户发出的，可能是过去的印象， 甚至是别有用心的用户发的，但是这些信息说明了很多问题。这是我们客服特地说明的这些已经纠正的 “老印象”， 理性地说，我们解决了这些问题，用户应该马上抛弃他们的旧印象，但是，感性地说，人并不是这样思考和做决定的。这些坏印象，可能要花 10X 的努力和时间来消除。

一些小众场景要修复么？一个软件如何提高它的质量

一个软件产品从小到大，从几个用户，到几万个，几百万个用户，我们当然要看很多因素，当你有上百万人都在有 PV，这个软件应该很可以了吧？再出问题，再不爽，也是万分之一，要重视么？要修复么？

大家觉得我们的App 直播连麦功能如何？早已经上线了，应该是 “足够好”，对吧？我原来也是这么认为的。2021/11/25， 我开始第一次实际主持 1 小时的 “直达CSDN” 连麦活动，第一次连麦就出现几个小 bug：

以后每周四晚上，我或者王路敏每次连麦都有新的 bug 出现，一次编辑部主持了一次和几个专家的连麦，使用某种版本的安卓手机的专家干脆就说不了话，这是比较尴尬的。那么我们怎么熬过来的呢？

产品经理，研发组长，研发总监每周四晚上出 bug 后都分析log，找到核心原因，快速解决，快速发版。（这里要鸣谢我们的 mobile 研发大牛：瑞瑞）

经过二十多个星期每次连麦 报bug 修复bug 上线，终于有一天晚上 9 点钟，我们结束了一个小时的连麦后，意识到今天一个 bug 都没有出现。这个 0-bug 时刻，就这样达到了。

最近的连麦还有几个小bug 出现，但是严重程度比最初已经轻很多了。这个时候，才是一种有信心的 “足够好”。

blink 在它的发展过程中，也有用户开始用它的 “使用率低“ 的功能， 有一次我们 top10 用户说要在 blink 帖一个他做俯卧撑的视频，搞了半天，就是贴不上。他的前一个帖子获得了 700 个评论，但是自从这次视频bug 之后，我看他就隐退了。有一次另一个重要用户要亲自在 blink 发帖子，庆祝一个重要日子，帖子带几个图片，但是死活发不出，我们研发连夜 debug，终于解决了，但是这个日子也过去了，用户也没有发帖子。这些万分之一的用户不爽之后，即使她是 top 用户，top 员工，要让他们再回来，也是非常难的。这些人走了之后，他们再也不会出现在我们的数据报表中了，无论我们如何埋点，如何分析。

在我职业生涯中，我过得还是比较顺的，最不顺的一段时间是 2005 年，我在 Brian Harry 领导下要开发下一代的软件项目管理系统 （TFS，是VS online 的前身）。Brian Harry 早年开发了 Visual Source Safe，是一个比较简单的源代码管理软件。类似 TFS 的项目做了一次，失败了，这是第二次努力，而且是用全新的 .Net 框架来写的， 我们当时用还是内测版的 C# 语言，内测版的 CLR 框架，内测版的 SQL Server，开发我们项目管理系统，不用说，bug 非常多。有一天 Brian 说，我们的产品可以跑了，我们就用这个版本来管理我们现在的项目。大家非常不满，说我们知道现在 bug 多，速度慢，但是这些都会修复，我们目前用内部的老系统来管理不是很好么？他坚持。于是就出现了：

我用最新版本的 TFS 报 bug：「TFS 在保存带附件的 bug 的时候崩溃」， 果不其然，在我填好数据，上传了附件，要保存的时候，TFS 崩溃了。bug 也没保存上。

怎么办？只好连夜修复，第二天用新版。那一段时间我每天都加班到深夜，Brian 带了部分团队在远程工作，他有时直接打电话来找人谈 bug，态度也很严厉。团队中有不少人都换组了， 因为微软这个伟大的公司，压力小而且管理友善的团队多得很，大家都可以自由换组。Brian 解释这样做的原因：

1. 真正用我们的产品，我们的代码要在实际使用中反复使用

2. 如果我们这几十人，全球分布的团队可以用 TFS 把我们的复杂项目管理好，我们才可以有信心把它卖给其他公司。

TFS 后来发布了，反响还不错。我也离开那个团队。微软有系统化的员工反馈系统，一度每个员工都可以查任何经理的业务目标和团队反馈数据。几年后我查了一下 Brian 的数据，他的员工反馈有一条 “希望团队文化更加包容 …”，我就笑了。

CSDN 要做一流的开发者的平台，成就一亿人，这一亿人就会带了很多 “小众” 场景，我们的产品也很丰富，一亿用户的需求也多种多样，我们自己也是 IT 人，我们平时用自己的产品么？写博客用到所有博客编辑器的 20% 还是 80% 的功能么？它们好用么？每一个给我们发帖发微信反馈 bug 的用户，他身后都有 100 个碰到同样的 bug 但是懒得告诉 CSDN，逐渐不用我们产品的用户，就像发 blink 遇到 “小众” 的 bug 的用户那样。我们对于这些纷纷扰扰，千头万绪的需求，bug，KPI，是如何设定优先级，如何处理的呢？

CSDN 是一个公司，每个人对于这个公司的目标要投入多少，自然是不一样的 （可以看猪、鸡、鹦鹉的故事）。离我 2005 年加班的时间又过了 17 年，经历了很多的项目和形形色色的人， 我自己也看了很多的埋点，数据，用户体验报告，和很多这样的同事共事过。还也看了很多软件工程、创业的书。我现在非常理解 Brian Harry 了。要把一件事请做成功，很重要的方面是要做 Hard 的选择，坚持解决 Hard 的问题。太包容，善良，有时 hard 的问题就主动找上来，例如发工资的钱不够了。

有些问题虽然表面上是小问题，但是这个小问题能出现，反映了团队的大问题，我们一起分析和解决这些大大小小的 hard 的问题吧。感性和理性，都在不同的阶段非常需要。

参考资料：

我以前读过关于 XeroxParc 的两本书：

• Dealers of Lightning: Xerox PARC and the Dawn of the Computer Age

• “玩闪电的牛人们” … 施乐公司PARC 研究院的故事，可歌可泣可叹。1970

原文链接：https://blog.csdn.net/SoftwareTeacher/article/details/128638754