IT瘾软件推荐

“Claude Code 这条路线错了”，元老级 AI 大师 Jeremy Howard 开炮：马斯克和 Dario 根本不懂现代软件工程-36氪

Wed, 18 Mar 2026 10:24:11 CST

Claude Code 这种开发方式还会让人类无法学习新知识，个人能力无法得到提升。企业也正因 AI 编程累积的技术债走向衰亡，这些债务使他们既无法维护现有产品、也难以开发新产品。 “所以我觉得这就是在把企业和员工往被淘汰的绝路上推。无法理解现在竟有这么多大公司的高管在推动这种做法，简直令人惊讶。”

AI 很快会自动化软件开发？大模型未来可以直接输出机器码？Jeremy Howard 不客气地说：说这话的人，多半没当过现代软件工程师。

这句话出自一位重磅人物。Jeremy Howard 是 fast.ai 创始人、Kaggle 传奇人物，也是 ULMFiT 论文作者——后者几乎定义了后来“预训练 + 微调”的语言模型范式。某种意义上，今天大家习以为常的很多大模型训练思路，都能往回追溯到他那一代研究者的探索。也因此，当 AI 编程、智能体和自动化软件开发成为行业最热话题时，他的判断尤其值得听一听。

他首先点名批评了当下流行的一些技术话题。比如 Anthropic CEO Dario Amodei 在《技术的青春期》中提出，顶尖工程师借助 AI 可以获得极高效率，并由此推断普通软件工程师的工作很快会被自动化。Jeremy 认为这种推断“这根本说不通”。

同样被点名的还有马斯克。后者曾表示，大语言模型未来可以直接输出机器码，到那时人类将不再需要库文件和编程语言了。Jeremy 的评价是：这帮人都没当过现代软件工程师。在他看来，很多人误以为软件工程只是把代码输入 IDE，但事实“根本不是”。

他说其实几十年前很多人就觉得即将出现第四代编程语言之类的东西，类似“软件编写越来越简单，再也不需要程序员和软件工程师了，谁都可以生产代码”。但在软件工程这个特殊领域，大模型虽然可以大量生成代码，却并不意味着它能胜任真正的软件工程工作。Jeremy 说自己现在“大概有 90% 的代码都是由模型代劳”，但“这并没有显著提升效率，因为编程从来就不是效率的瓶颈。”

他认为大模型也有能力范围，也会“装作理解”。在很多任务上，这种表象已经足够好用。但一旦问题超出训练数据的分布范围，这种理解就会迅速崩塌，大家会发现“这玩意原来这么蠢……”。

另外，对于 Claude Code，他更是从头批到尾。

最近不少人惊叹 Claude Code 用 Rust 写出了一个 C 编译器。但 Jeremy 与 LLVM 创始人 Chris Lattner 讨论后发现，这个所谓的“新编译器”其实并没有真正突破现有技术路线。因为 LLVM 体系早已存在于大量训练数据中，而 Rust 只是另一种实现语言。将其转换为 Rust，本质上就是在训练数据的片段间进行插值。所以本质上，这仍然是一种风格迁移问题。

“训练数据中已经有构建编译器的方法，而且很多现成的软件都可以实现。”“其本质都是对现有成果的明显照搬。这正是我眼中最核心的挑战所在：要想做出真正原创性的成果，就不能依赖大语言模型。”

除了技术能力本身，Jeremy 也批评了当前 AI 编程工具的发展方向。

在他看来，人类历史上最重要的软件创新——从 Smalltalk 到 APL，再到 Mathematica——都强调人与计算机之间的紧密互动。开发者可以实时操作对象、观察系统状态、调整参数，从而建立直觉和理解。

而像 Claude Code 这样的工具，却走向了相反的方向：开发者只需要输入 prompt，剩下的代码由模型生成，甚至不需要理解整个系统。这种模式虽然看起来效率很高，但却在逐渐削弱开发者对软件系统的理解。

Jeremy 认为，这种趋势是让人类逐渐与自己的代码脱节，甚至有些“不人道”。在他看来，AI 编程真正的挑战并不是让模型写更多代码，而是如何设计一种新的协作方式，让人类和 AI 在同一个交互环境中共同工作，而不是让人类逐渐退出软件开发过程。

更严重的是，Claude Code 这种开发方式还会让人类无法学习新知识，个人能力无法得到提升。企业也正因 AI 编程累积的技术债走向衰亡，这些债务使他们既无法维护现有产品、也难以开发新产品。

“所以我觉得这就是在把企业和员工往被淘汰的绝路上推。无法理解现在竟有这么多大公司的高管在推动这种做法，简直令人惊讶。”

以下是播客整理：

语言模型微调是怎么诞生的

Dr. Tim Scarfe：Jeremy Howard，我大概是从 2017 年、2018 年那会开始关注你的。你那篇著名的 ULMFiT 论文让我印象深刻，当时我在微软工作，还专门就此做过演讲。如今大家理所当然的观点，即只需依托文本语料库对语言模型进行微调，就能持续训练并实现专业化，就是从那篇文章中孕育出来的。

Jeremy Howard： 其实这也不完全是第一次尝试，准确讲其实是第二次。更早几年前 McCann 和 Andrew Dai 也做过类似的研究，但他们忽略了一个关键点——预训练数据集必须是通用语料库。

所以我只是幸运地抓住了这个关键点，但这一切也确实跟我几十年间的哲学与认知科学积累有关系。

我对正则化一直情有独钟，而且尤其推崇这样的实践思路：先构建一套高度灵活的模型，再通过添加正则化项、而非缩减架构规模来增加约束性。

这一点在当时的学术界引发了极大争议，但也并不算是我们的独创见解。Stephen Merity 当时的做法是：选取 LSMT 这种循环神经网络的经典模型（目前的研究也开始逐渐回归此类模型），在保持极致灵活性的同时叠加五种不同类型的正则化方法。他几乎涵盖了一切能想到的正则化类型，而这也成为我的研究起点：构建一套既能随心所欲发挥强大能力，又能按需严格约束的深度学习模型。在此基础之上，我需要海量的文本数据集。有趣的是这同样跟 Stephen 有关，他曾参与 Common Crawl 项目，还协助创建了维基百科数据集。

后来我意识到，维基百科的数据集中其实包含大量预设性假设，比如用 unk 来标记未知词汇，就是说完全采用了经典 NLP 方法。

于是我重构了整套数据集，创建了新版维基百科数据集，现在它也成为我的通用语料库。之后我采用 AWD-LSTM 模型进行训练，仅用一晚时间就成功实现。

当时我用的是一块游戏显卡，前后跑了八个小时。旧金山大学的资源有限，所以我用的好像是一块 2080 Ti 显卡。

第二天清早醒来时，模型训练已经完成——其架构采用的正是如今大家熟悉的三段式。预训练、中训练、后训练。我当时想：既然能预测维基百科的下一个词，模型肯定掌握了大量世界知识。于是我尝试用特定语料进行微调，也就是现在所谓监督式微调数据集，而我用的是电影评论数据集。

事实证明，它特别擅长预测这类文本中可能出现的下一个词，从而掌握大量电影知识。这次的训练只用了大概一个小时，接着又花了几分钟对下游分类器做了微调——用的是一套经典的学术数据集。

我尝试解决的是当时最困难的一种分类问题，即从 5000 条影评中判断观众对于某部影片的情感倾向（正面 / 负面），但如今这项任务已经很简单了。那时候只有高度专业化的模型才能较好完成，甚至有人专门为此撰写博士论文。而我仅用 5 分钟完成微调的模型，就超越了全部原有研究成果。

Dr. Tim Scarfe：这确实令人惊叹，而更值得玩味的就是你那精细的微调方法学成果。

Jeremy Howard： 没错，我们的微调方法是 Fast AI 团队自主研发的。当时 Fast AI 刚刚成立一年，还处于起步阶段。我们当时做了一个极具争议的决定：专注于对现成模型的微调，因为我们坚信微调的力量。同期也有其他研究者在探索这个方向，比如 Jason Yosinski 也做过非常出色的研究。

我记得他在博士期间就研究过如何优化模型及其性能上限，计算机视觉领域也有不少其他研究者在做探索。

我们算是先行者之一，当时不少团队都在深入探索微调技术。我们的想法是，用单一学习率一次性微调整个模型可能行不通，因为模型中不同的层次具有不同的行为特性。

这正是 Jason Yosinski 研究揭示的一大关键。而我们进一步提出了新思路：仅训练末层效率更高，因为只需要对末层进行反向传播。

在确定末层效果良好之后，再逐步扩展到倒数第二层、第三层。我们采用“鉴别式学习率”的机制，即为不同层次分配不同的学习率。

还有另一个我们曾反复强调，但多年来无人在意的关键洞见，即必须对每个 batch 归一化层进行微调。所有归一化层都需要精细微调，因为它们会改变整体的整体规模。只要以此为前提，通常只需微调最后一到两层，就能获得接近顶尖水平的性能结果，整个过程只需要几秒钟。

Dr. Tim Scarfe：是的，鉴别式学习率很有意思。因为当时的主流观点是：如果在模型微调中把学习率设定得过高，就会破坏表示结构。所以大家普遍认为必须采用极低的学习率，否则模型本身就跑偏了。

Jeremy Howard： 那时候还不存在公认的最佳解决方案，也没人讨论过这个话题。就当时的情况看，人们根本就不关注迁移学习。

而 Rachel 和我坚信迁移比任何事情都重要，因为只需要一方把超大规模模型训练出来，其余研究者就能直接进行微调。所以我们决定要钻研这项技术，为此投入大量时间并反复尝试了各种方案。但最终发现，直觉往往才是最简单明了的路径——那些在直觉上可行的方案，基本都跑通了。

这跟当今的机器学习普遍实践有着根本上的差异——如今的研究似乎都围绕着消融实验展开，强调不能做任何假设或者猜测。但这完全不符合实际。我发现几乎所有预期有效的方案都能一次成功，因为我投入大量时间培养出这种直觉，获得了对梯度行为规律的深刻理解。

Dr. Tim Scarfe：但我觉得好像也存在过二元对立的现象：持续学习希望在保持泛化能力的同时持续训练模型，而微调则专注于就特定任务做优化。长期以来存在着这样的认知：模型确实可以做定制，可以按需调整，但这会牺牲泛化能力并削弱表征能力。对这个你是怎么看的？

Jeremy Howard： 没错，确实存在这种现象，但应该没有你讲的那么严重。根本问题在于，人们往往忽略了对激活函数与梯度分析的观察。

因此我们在 Fast AI 软件中内置了一项核心能力：允许用户一览整个神经网络结构。

经过几次操作之后（学习过程只需要几个小时），研究者就能快速意识到当前是属于过拟合、欠拟合或者某个层出现了问题。

这也不算什么奥秘。具体来讲，假如当某些神经元陷入“休眠”状态，即无论如何微调都出现梯度归零——这种情况往往发生在梯度趋向无穷大的情况。但这类问题总能修复，所以实际效果远比大家想象的要好。只要训练得当，适合连续学习的模型也同样能通过微调出色地完成特定任务，只要谨慎处置即可。

Dr. Tim Scarfe：某种意义上，我们确实需要让神经元休眠。让我具体解释一下：我们需要扭曲模型的行为来引入隐式约束，因为没有约束就谈不上创造或者推理能力等等。所以从这个角度我们就能让模型拒绝做某些事，转而去做别的事。

Jeremy Howard： 我倒不这么看。对我而言，在思考 AI 时应该多多参考人类的思维模式，这很有启发。我发现二者行为的相似性要远大于差异性，而我由此产生的直觉往往非常靠谱。

要知道在人类学习新事物时，并不一定要忘却旧知识。所以我发现：当模型尝试学习两项相似的任务时，这两种能力的同时提升效果往往好于只专注单一任务的模型。

Dr. Tim Scarfe：这让我想起 LeCun 实验室的 DINO 论文。虽然当时仅限于视觉模型，但这种自监督学习框架的核心思想仍极其重要：我们在进行预训练时，要尽可能保持多样性和保真度，这样在执行下游任务时才能拥有更多可利用的锚点。

Jeremy Howard： 没错，半监督和自监督学习确实曾是被严重低估的领域。而 Yann LeCun 绝对是该领域最重要的研究者之一。当年我还专门写过一篇博文，就为了吐槽为什么半监督学习方面的研究者那么少。Yann LeCun 冥过我的文章，还推荐了几篇我遗漏的重要文献。但最令我惊讶的是，这种方法的效果居然这么好——本质上就是设计一项预处理任务。

所以设想一下，我们在 ULMFiT 之前就做过这个设想，类似于在医学影像领域取一份组织切片，遮住几个像素块，然后预测原本的内容是什么。

我在南佛罗里达大学带的一些学生就在做这方面研究，基本上就是在复用我们和其他人已经在视觉领域做过的工作。比如这种遮罩方法就不是我们的发明，在计算机视觉领域早有实践，但我们会自然想到在预测单词方面也值得尝试。

以通用预训练模型为起点这一核心思路，在计算机视觉领域早已存在。其实有篇 2015 年左右发表的经典论文，内容完全基于实证研究，展示了当我们用预训练的 ImageNet 模型去预测雕塑家的身份或者建筑风格时，该模型在每项任务中都取得了最先进的结果。但令我惊讶的是，人们看到这些成果后竟然没有联想到：这种方法也理应适用于其他领域——包括基因组序列分析、语言处理乃至其他方向。我发现人们往往缺乏想象力，总认为某项技术只能局限于特定领域。

Dr. Tim Scarfe：确实如此，我觉得这里面有两个关键点。首先，我们其实是暗示存在一种类似古德哈特定律（即任何被设定为目标的衡量指标，都将失去反映真实情况的能力）的短视效应——我们最终得到的只是想要的结果，其他一切都会被牺牲掉。事实显然并非如此，因为在语言模型中我们是可以优化困惑度的。如你所说，这似乎涉及到分布假说，即词语的含义取决于其上下文环境。当我们拥有海量关联数据时，无论是掩蔽自动预测还是类似的技术，模型似乎都能生出一种可称为“理解力”的东西。

Jeremy Howard： 我始终将其视为抽象层次。当模型需要预测时，比如判断棋谱的开局是不是采用了 Bobby Fischer 的习惯下法，再以国际象棋的标准记谱法预测后续棋路，那它就首先得掌握棋谱知识。至于判断“此提案是否被 1956 年的美国总统否决”，那么模型不仅要知晓总统的身份，更要理解“总统”这一制度性概念的存在，进而理解领导人概念、人类社会中的等级制度、人类族群乃至物理世界的存在。如果不掌握这些层层递进的认知，就无法准确预测句子中的下一个词。

所以我的基本思考是这样：建立 ULMFiT 的初衷，正是要尽可能压缩这种知识的获取过程，还必须在模型深处建立起抽象层次结构。如果做不到这一点，谈何精准预测下一个词？要知道，深度学习模型的本质就是通用学习机器，我们又掌握了通用训练方法。因此我推测：只要数据正确且硬件足够强大，理论上我们就能构建起这种词序预测机，它没有理由不能隐式构建起对文本描述对象的分层结构化理解。

Claude Code 的“创造力”，本质上还是插值组合

Dr. Tim Scarfe：但我觉得 AI 的认知还相当浅显。它们确实掌握着无数表层统计关系，也能实现极强的泛化能力。但关键在于，我想参考你之前关于创造力做出过的论述。我认为知识的本质就是约束，而创造力则是在遵循这些约束的同时推动知识演进。所以 AI 并不具备创造力，你之前也持有相同的观点。既然如此，你一方面承认它们具备认知能力，另一方面又否认其具备创造力。这该怎么理解呀？

Jeremy Howard： 我倒不记得自己明确这么讲过。只记得在跟 Peter Norvig 一起接受采访时，我们都提到：其实 AI 在某种意义上是具备创造力的，只是我们用词要谨慎一些。比如我非常敬重的 Piotr Wozniak，他重新发现了间隔重复学习法，由此建立起 SuperMemo 系统，获得了现代记忆大师的称号。

他之所以将毕生精力投入到对记忆的研究，根本原因在于他坚信创造力源自海量的记忆储备，即以全新的方式组合记忆内容才是激发创造力的绝佳途径。

大语言模型在这方面表现相当出色，但也存在一种其完全无法胜任的创造力，也就是突破分布式模型的局限。我认为这就是解决这个问题的关键所在。

不过我想强调的是：对这个问题必须保持极度审慎的态度。如果简单断言大模型缺少创造力，其实是种极具误导性的表达——它们确实能做出看似具有创造性的表现。但要进一步追问：大模型能不能真正突破训练分布的边界，答案肯定是否定的。但训练数据集如此庞大，其中插值的方式又极其繁多，我们还远不清楚它的边界到底在哪里。当然，我每天都能见证这种现象——毕竟我的工作就是研发，始终游走在训练数据的边界附近，做出各种前所未有的尝试。

我发现了一种奇怪的现象，不知道你有没有见过，我每天都会遇到很多次：语言模型会突然从极聪明变得特别蠢，甚至连最基础的逻辑前提都无法理解。它就好像突然意识到：哎呀，问题超过我的训练数据分布范围了。变笨就是一瞬间，任何讨论都毫无意义，模型突然就失控了。

Dr. Tim Scarfe：没错，我非常欣赏 Margaret Boden 提出的创造力分层理论：创造力分为组合式、探索式和变革式三种。而当前的模型确实已经发现了组合式创造力的秘密。

但于我而言，关键在于约束的设置。这也是 Boden 的观点，连达芬奇都说过：创造力的本质就是约束的艺术。你提到的对话工程学也是这个道理。问题在于，当我们跟语言模型对话时，本质上就是给予规范，整个过程需要反复迭代。我们人类的思考也是如此，智能的实现就是在大脑中构建想象形式的乐高积木，同时遵守各种约束条件。

在遵守这些约束并持续演进之后，由此带来的成果就是创造。所以在为语言模型添加约束时，无论是通过监督、批评者还是验证者的方式，它们就能展现出创造力。AlphaEvolve 就已经呈现出这样的能力。但问题在于，当模型脱离约束，它们身上就会出现我们谈到的行为塑造现象。正因如此，语言模型也就无法突破自身训练数据的分布范围。

Jeremy Howard： 我想说的是，语言模型之所以无法突破分布范围，根本原因是这类数学模型本身的局限性。虽然理论上可行，但实际效果极差。就像二维数据的拟合曲线一旦超出数据覆盖区域，曲线就会在空间内向各个方向疯狂延伸。

我们本质上就是在做这件事，只不过是在多维空间中操作。当人类知识库里的全部内容都成为组合素材时，语言模型或许会表现出震惊世人的组合式创造力。

我觉得这也是人们常常误解的点，比如昨天我跟 Chris Latner 讨论 Claude Code 怎么编写 C 编译器时，他认为这是款纯净室编译器，因为它是用 Rust 编写的。

Chris 本人就是当今使用最广泛的 C/C++ 编译器的缔造者，基于 LLVM 运行，而 LLVM 则是编译器普遍采用的基础架构。而且神奇的是，Chris 压根没用过 Rust，也没提供过任何编译器源代码。

所以 Rust 版本的 C 编译器就是净室实现，但也跟大模型的工作原理存在出入。Chris 的所有工作都体现在了大模型的训练数据当中；LLVM 得到广泛应用，无数项目都基于它构建，其中也包括各种 C/C++ 编译器。将其转换为 Rust，本质上就是在训练数据的片段间进行插值。所以本质上，这就是风格迁移的问题。所以最多只能称之为组合式创造力。从生成的代码仓库就能发现，新项目直接复制了 LLVM 代码片段，而 Chris 坦言“我当初犯了错，就不该采用这种没人用的办法”。

而 AI 是唯一照搬了 Chris 这种办法的开发者。之所以会这样，就是因为大模型还没能真正发挥创造力。它还是在训练数据当中寻找某种非线性的平均点——比如在 Rust 技术和编译器构建技术间找交集。

Dr. Tim Scarfe：这些说法都成立。首先，我们不能也不该低估这种组合式创造力的规模。虽然很多代码片段都来自网上公开的结果，但它也确实搭建了完整的测试框架——每次代码提交都会触发测试，相当于建立了实时审查机制。这就是 AI 自己搞的自主反馈循环。

某种程度上，这跟 OpenAI 和 Gemini 最近的研究非常相似——让 AI 自建评估函数来尝试解决数学问题。但人们往往忽略了一点：运用评估函数本身，就代表着 AI 对问题并不完全理解。它仍然在通过暴力搜索和统计模式匹配来解题，并将验证器当作约束。

Jeremy Howard： 所以说大模型根本没必要这么搞。因为训练数据中已经有构建编译器的方法，而且很多现成的软件都可以实现。所以它直接借用现有方案并将其转换成了 Rust 语言。单凭这点，就已经相当惊人。

虽然我对数学不像对计算机科学那么熟悉，但我也常跟数学家们交流，发现在埃尔德什差异问题（对于任意常数 C，总能找到等距的有限子序列，使其元素累加和的绝对值超过 C）等领域也存在类似的现象。部分问题虽然得到了新解，但并非顿悟式的突破。大模型往往还是在整合人类已知的相关知识点来解题。

“ 这帮人都没当过现代软件工程师”

Dr. Tim Scarfe：再来聊聊 Claude Code。你曾经深入探讨过氛围编程的问题，Rachel 也写过一篇有趣的文章，引用 METR 研究所的成果，发现人们在进行氛围编程时生产力反而有所下降。

还有 Anthropic 的研究，这里我们稍做回顾。Dario 前段时间发表了一篇题为《技术的青春期》的文章，大意是：Anthropic 拥有众多顶尖软件工程师，在 AI 辅助下开发效率极高。而后他将这种情况粗暴推广到普通软件工程师群体，宣称 AI 很快就能全面实现工作自动化，届时将导致大面积失业。

Jeremy Howard：这根本说不通。 几天前马斯克也讲过类似的话，说什么大语言模型可以直接输出机器码。到那个时候，我们就完全不需要库文件和编程语言了。

问题在于，这帮人都没当过现代软件工程师。我不确定 Dario 有没有做过真正的软件工程师岗。软件工程是门特殊学科，很多人误以为软件工程就是简单把代码输入到集成开发环境。根本不是，编程的本质是另一种风格迁移问题。我们拿到待解决问题的规范说明，而后运用组合式创造力找出训练数据中能够填补两者间隙的部分来解决问题，再将其与目标语言的语法进行插值处理，最终形成代码。

Fred Brooks 几十年前曾写过一篇著名论文《没有银弹》，其内容对当下的情况做出了精准预言。当时很多人都觉得即将出现第四代编程语言之类的东西，类似“软件编写越来越简单，再也不需要程序员和软件工程师了，谁都可以生产代码”。但他则预言称，技术的进步最多只能带来 30% 的效率提升。

这就是他的结论，未来十年之内软件开发的效率提升空间只有 30%。我虽然觉得没必要这么悲观，但软件工程中的绝大部分工作确实不止于编写代码。某种意义上，Dario 的部分观点也有道理，比如当下很多人已经在靠语言模型为生成代码。我自己就是这样，大概有 90% 的代码都是由模型代劳。但这并没有显著提升效率，因为编程从来就不是效率的瓶颈。

语言模型确实给我的研究工作带来不少帮助，比如预判哪些文件需要修改。但在我尝试让大模型设计前所未有的解决方案时，结果永远是场灾难。

实际上，它每次给我的都是看起来差不多的设计，而这往往就是灾难的根源。我明明想要创造新事物来消除这种相似性，但它总在延续过去，这就是最大的冲突点。

Dr. Tim Scarfe：我发现很多科技从业者对于认知科学和哲学概念都有严重误解。我们节目也采访过很多杰出人物，比如曾撰写了《知识法则》一书的 César Hidalgo，还有神经科学哲学家 Mazviita Chirimuuta 也反复强调过知识具有变幻莫测的特性。我认为知识在本质上是有视角属性的。

我不觉得单靠维基百科上那种纯抽象、脱离视角属性的条目就足以还原知识的全貌。换言之，我认为知识有着具象性且充满生命力，脱胎于我们体内。组织存在的意义就在于守护并演进知识。而在把认知任务委托给语言模型时，自然会产生一种诡异的悖论效应：组织内部的知识反而受到侵蚀。

Jeremy Howard：确实，这真的令人不安。网上经常出现这样的争论：有人坚称大语言模型根本就啥都不懂，只是装作可以理解。另一些人则反驳：别胡说八道，看看大模型刚刚帮我搞定了什么问题。有趣的是双方都有道理——大语言模型实际上确实是在扮演一个理解了问题的人。

它们假装可以理解，恰恰呼应了 Daniel Dennett 早期认知科学研究的精髓，中文房间实验（设想一个仅懂英语的人通过操作中文翻译程序手册处理外部中文提问，使外界误判其具备理解能力，以此论证计算机仅模拟智能表象而缺乏真正认知状态）的核心思想也正是如此。房中人的表现确实很像懂中文，因为我们提的所有问题都能得到答案。但实际其只是在海量的书籍或机器中查找信息。当然，在装懂不影响结果的范围之内，到底是装聪明还是真聪明并不重要。

所以 对于很多任务，大语言模型只需要装懂就足够了——毕竟在实际应用中，是不是真懂根本无关紧要。可如果哪天越过了边界，很多人才会惊觉：天哪， 大模型这玩意原来这么蠢……

Dr. Tim Scarfe：顺带一提，我是 Searle 的拥趸，他曾提到因果具有可还原性、但本体不具备可还原性，也就是强调存在现象学这个维度。这也是知识变幻莫测的精妙所在，它本质上承袭了康德的思想：世界错综复杂，无人能够完全理解。正如盲人摸象，我们不可避免各自拥有不同视角。

由于复杂度过高，因此每个人都在进行建模。但有趣的是，语言模型有时似乎表现得能够理解事物，而这种理解的根源在于监督者为其提供了框架。在这套框架内，当我们从大象的视角观察，认知结论竟然出奇连续。只是现在，我们往往忽略了监督者为模型设定的这套框架。

Jeremy Howard： 没错，所以这相当于 Searle 与 Dennett 之争，也就是《意识的解释》与“中文房间”这两种视角的思辨。有趣的是，当时的讨论跟我们当下的争议有着完全相同的本质，只是从纯思想实验转向现实层面。回归抽象讨论很有必要，因为这能让我们抽离当前困境、不再受到现实中具备强大模仿能力的模型影响，真正回归问题的本质。

总之我想强调的是，我们正身处一种微妙的历史节点：人们极易对 AI 的能力产生误解。尤其是那些分不清编程和软件工程区别的朋友，就更容易误解。

是的，这就正好转回了你提出的问题——这种认知差异会对组织产生怎样的影响。要知道，许多组织的本质就是在押注一个投机性的前提：AI 将有能力比人类更出色地完成一切工作，至少在编程领域可以做到。我对此深感忧虑，无论是从组织还是从全人类的角度讲都是。对人类来说，一旦没有机会主动运用设计、工程和编程能力，也就失去了发展和成长的机会。人类可能逐渐凋零。身为研发型初创公司的 CEO，我必须要强调：如果团队成员停止成长，我们就注定会失败。

我们绝不能让这种情况发生，而单纯提升针对 AI 的特定提示词技巧或者 CLI 框架使用能力，并不算成长。这就像在不理解互联网原理的情况下死磕亚马逊云科技的接口细节——毫无价值。这类知识既不可复用，又没有继承意义。虽然它能够在当下解决实际问题，但必然随着时间推移逐渐侵蚀从业者的信心。

大模型反而让开发者变笨了？

Dr. Tim Scarfe：我认同这种自然规律，而且对你尤其重要。在整个职业生涯中，你一直致力于提升人们的技术与 AI 素养。而你说的大模型编程技巧，很像是开自动驾驶汽车了——人根本没多少机会上手。

这里存在一个临界点——当我们不再专注于亲自解题，而把能力委托出去，就会积累下认知债。这就是当前的现实。几周前 Anthropic 自己的研究就完全推翻了 Dario 的观点，研究结果甚至发现，确实有少数参与者通过提出概念性问题来保证对实现技术的掌控。他们确实能展现出学习曲线，但大多数人根本做不到。

我有个假设：生成式 AI 编程的理想状态应该是看齐人类开发者，毕竟我们几十年来一直在编写软件，也具备抽象认知能力、能在熟悉的领域灵活运用。我们还能明确需求，消除大量模糊性、跟踪进展、反复调整，且全程掌控开发流程。但现实情况是，现在的人们会默认进入自动驾驶模式，对实际发生的情况一无所知——这反而让开发者变笨了。

Jeremy Howard：我在 2014 年创立了首家医疗深度学习公司 Enlitic。初期我们专注于放射学领域，当时许多人就担忧这会削弱放射科医生的专业能力。但我坚信恰恰相反——为此我还深入研究了飞机电传操纵系统、汽车防抱死刹车系统等技术应用案例。当可以自动化的任务环节成功实现自动化之后，专家反而可以专注于真正关键的环节。

我们在实践当中也难了这一观点。在放射学领域，我们发现如果能自动识别肺部 CT 扫描中的潜在结节，那么放射科医生可以专注于分析结节性质，判断其恶性程度并制定治疗方案。这正是微妙的差别所在。如果能有效实现某些环节的完全自动化，从而减轻人类认知负担、专注于核心工作，结果无疑是积极的。至于软件开发领域的情况，我觉得更难以断言——毕竟我搞开发已经有四十多年，亲自写过大量代码。除非遇到特别奇怪或者复杂的情况，否则只需瞥一眼代码，我就能立刻判断出代码功能和运行状态等结论。

我凭直觉发现的这些可优先的点，还有预见到的潜在风险，如果没有长期编程积累恐怕很难很难达到。目前我觉得真正受益于 AI 的人群有两类：要么是完全不会编程的初学者，现在他们可以把脑海中的想法快速转化成应用。只要 AI 有能力帮他们快速实现需求，就完全可以了。另一类是像我和 Chris Latner 这样的资深开发者，因为我们能让 AI 代劳相当一部分编程工作和研究任务。但处于中间水平的人才是真正的绝大多数，这让我非常担忧，他们几乎失去了进步的空间和可能性。

不用亲自写代码也许没什么，但我们没办法确定，因为之前没出现过这种情况。这就像回到小学阶段，学校禁止孩子们使用计算器，就是为了锻炼他们对数字的感觉和运算能力。那开发者还要不要经历前五年的磨练，亲手编写所有代码？我真的不知道。

总之我自己比较悲观，对于大部分从业经验从 2 年到 20 年之间的开发者，这可能是在慢慢侵蚀他们的竞争力。

Dr. Tim Scarfe：没错，这又涉及 Cesar Hidalgo 提出的知识本质论。他认为知识具有不可替代性，即无法直接交换。其核心观点是：学习过程在某种意义上不可能被简化。学习者必须亲身经历，直面摩擦和考验。学习的过程就是构建世界模型的过程，会经历所谓“现实的反噬”——我们不断犯错、不断更新自己大脑中的模型，并向其中持续添加一致性约束。但直接使用大模型输出的代码，显然是回避了这种“必要之难”。Anthropic 的研究也提出类似的结论：由于回避了摩擦，开发者根本学不到任何东西。

Jeremy Howard： 没错，所谓“必要之难”是教育学领域提出的概念，最早可以追溯到十九世纪重复间隔学习的开创者 Ebbinghaus。Piotr Wozniak 的近期研究也发现了相同的规律：记忆的形式需要付出艰辛努力。这也解释了为什么“过度复习”反而有害，因为信息会过早浮现。而间隔重复学习法（例如 Anki 和 SupereMemo）则努力在记忆即将遗忘的临界点处安排复习。

这确实需要付出艰辛的努力。我花了十年时间学习中文，只为探究学习的本质。在使用 Anki 时我深刻体会到：它总在记忆即将消退的临界点安排复习，抓住濒临遗忘的节点刺激神经元连接。这种模式执行起来特别特别累，但效果确实惊人。所以哪怕后面十几年不再坚持系统学习，我仍能流利使用中文。

Dr. Tim Scarfe：说回你提的放射学案例，还有人们常说的客服中心。我们总觉得组织中的岗位存在着高智力需求和低智力需求之分。但我觉得，智能的本质就是对知识的适应性获取和整合。假设低智力需求岗位（比如客服）不需要适应变化，就意味着组织中存在着某些稳定不变的环节。

这部分环节可以自动化，无需更新知识储备。但结合放射学案例，这种观点可能忽略了整体性知识的重要性。比如客服中心也会遇到大量特殊的、极端的案例。各种意外状况层出不穷，这些信息会向上传递，促使组织逐步适应。所以在推广自动化流程之后，工作人员实际上会丧失创造流程的能力，进而削弱组织知识的演化能力——这无异于自毁长城。

Jeremy Howard：完全正确。在我的公司，我始终提醒同事们：我真正关注的只有一件事——你们的个人能力在多大程度上得到了提升。我并不在意大家提交了多少 PR，开发出了多少功能。就像 Tcl 语言的发明者 John Oustenrhout 最近在斯坦福讲座中提出的精彩观点：一点点斜率就能弥补大量截距。

这里的核心论点是，人生中若能专注于加速成长的事物，那效果要远胜于执着那些已经擅长、拥有高横坐标值的事物。因此我真正关心，也是我认为对公司至关重要的唯一目标，就是让团队专注于提升斜率。没错，如果只专注于在现有 AI 的能力边界之内追求成果，那关注的就仍然是横坐标值。

所以我觉得这就是在把企业和员工往被淘汰的绝路上推。无法理解现在竟有这么多大公司的高管在推动这种做法，简直令人惊讶。

毕竟这是个大家都不熟悉的领域，MBA 课程里也从没提到过，所以一旦判断失误——也很可能就是失误，那人们根本就意识不到。这本质上是为公司埋下了毁灭的种子。

更令人费解的是，股东们竟然会纵容这种行为。这将催生出高度投机性质的市场操作。众多企业正因 AI 编程累积的技术债走向衰亡，这些债务使他们既无法维护现有产品、也难以开发新产品。

Dr. Tim Scarfe：像 François Chollet 这样的行家其实也不少，他们真的很懂。他就始终强调 AI 发展的本质，就是领域认知模型的拟态式共享，以及如何配合人类共同蒸馏这些模型。说到共享，这恰恰是 AI 编程面临的另一大扩展难题。

在理想状态下，只要我们深谙某个领域，有能力用极致的细节做出定义，那么只需告知 Claude Code 执行任务即可——我们脑袋里的模型框架并不重要。

但在组织环境下，我们需要把知识共享给全体成员。必须承认，知识的获取瓶颈就是组织内部真实存在的严重问题。如果只有我一个人在使用 Claude Code，效率大概能提升 50 倍——人们的兴奋之情也正来源于此。但要跟其他人共享，AI 编程工具就起不了什么作用了。大家似乎并没有意识到这个瓶颈，也没发现这就是大多数组织难以将 AI 转化为现实生产力的原因。

Jeremy Howard：实际上没人能在保持高质量的前提下产出 50 倍的软件。 我们刚刚完成相关研究，发现人们实际交付的成果只能说略有增加。这就是残酷的事实。我本人其实热衷于发掘 AI 的潜力，但我妻子 Rachel 最近发文指出，所有激发人们热烈追捧的因素汇聚起来只是一股暗流。

Dr. Tim Scarfe： 对，暗流这个概念我也想提来着。

Jeremy Howard： 所以这就很尴尬了。我认识的几乎每位前段时间对 AI 驱动编程充满热情的人，在回头审视自己一路走来构建的成果时，都彻底改变了看法：这些东西还有人在用吗？还有受众吗？还能帮自己赚钱吗？ 其实几乎所有利润，都被意见领袖或者炒币那帮家伙卷走了。

氛围编程就像老虎机

Jeremy Howard：依托 AI 的编程本质上更像是老虎机——让人产生可以掌控一切的错觉。我们当然可以精心设计提示词、管理模型参数清单、调整 skill 参数等等，最后再拉下拉把。

输入指令，然后得到结果，这就像凭运气拉出三颗樱桃并排。“我再改条指令，再多加点上下文”，之后再次拉动拉把、不停重复。

这就是随机性。我们偶尔能赢一把，觉得太棒了、AI 这东西太牛了！但这本质上具备赌博的全部特征：伪装成胜利的失败、高度随机、虚假的控制感——这些都是博彩公司精心编排的元素。虽然这并不代表 AI 没用，但……真的也没多有用。

Dr. Tim Scarfe：明白。Rachel 还提到赌博的另外一个标志性特征，就是让人自欺欺人地以为掌握了局势，但实则不然。但我们也可以探讨一下乐观情绪：我觉得 AI 编程在受控场景下的确非常有用，前提是我们能够理解并设定约束。从好的角度来讲，那我们确实不会因此失业，毕竟这部分工作量会相应增加。至于成瘾性，那也是真实存在的：我曾经连续 14 个小时使用 Claude Code 输出代码，确实非常上瘾。你说得对，就像老虎机一样，非常贴切。

而且那也是我最疲惫的一次编码经历，精疲力竭之后我连着休息了好几天才恢复，那状态实在糟透了。

Jeremy Howard： 一点没错。我也获得过一些不错的结果，过去几年还围绕已知的成功路径构建起完整的产品体系，也就是专注于中等规模的模块化开发：确保各个模块完全可控、可设计，并能通过自定义抽象层逐步构建起超越组件本身功能的整体系统。最近我们还遇到个很有意思的情况，其实也可以算是实验：我们之前高度依赖 IPKernel 组件，它也正是驱动 Jupyter Notebook 的核心。但在 IPyKernel 从版本 6 升级到版本 7 之后，就彻底失效了。我们尝试使用的两款产品都出现了故障：其一是名为 nbclassic 的原始 Jupyter notebook，其二是我们自主开发的 solve it 产品。

它们会随机崩溃。IPyKernel 的代码超过 5000 行，结构极其复杂，涵盖多线程、事件处理、锁机制、与 IPython 的接口、ZMQ 通信协议以及 DebugPy 调试框架等等。我完全摸不着头脑，找不到崩溃的原因——所有测试都能顺利通过。于是我好奇，AI 能不能帮我解决这个问题？真的，我一直好奇目前的 AI 能够独立处理的任务规模上限在哪里。

事实证明，它确实能够解决。前后花了两周时间，虽然没能深入理解 IPyKernel 的运作机制，但我还是花了不少精力把它拆解成一个个独立组件。最终 AI 在两小时内就给出了答案——我最早用的是 GPT 5.2，没能搞定；花每月 200 美元升级到 GPT 5.3 Pro 版后就好了。

总之，通过在两个版本和两套模型之间反复切换，我花了几周时间才让系统正常运行。如你据说，整个过程毫无乐趣可言，既疲惫又焦虑，因为我始终无法掌控局面。但有趣的是，这是我目前唯一能够让新版 Python Jupter 内核成功运行的办法——至少就我所知，它找到了完美兼容版本 7 协议的办法。 这让我不禁陷入深思：我不喜欢 AI 辅助的工作感受，但因为传统软件工程理论不足以解决问题，我又别无选择。

新的难题又来了——我并不理解解决问题的这段代码，那我该不该把公司产品押在上面？我真的不知道该怎么办，我不知道它会不会引发内存泄漏；如果协议稍作改动，它后续还能不能正常运行；是否存在会导致全盘崩溃的极端状况等等。这真是个前所未见的巨大困局。

“AI 写代码很厉害，但软件工程一塌糊涂”

Dr. Tim Scarfe：那我们还是得从控制权的角度讨论——必须承认，我们对代码的控制能力正受到严重侵蚀。最初由 AI 生成的代码占比仅为 10%，随后这个比例不断攀升，而且我们无能为力。大约半年之后，提交上来的 PR 中就有约 60% 代码由 AI 生成。这就是后果。

人正逐渐跟自己的代码脱节。乐观的判断认为：AI 编程只强调功能主义即可——只要智能体可以正确完成任务，我们就可以认可 AI，无须深究其构成原理。毕竟软件领域从来都是这样。

商业领域肯定很认可这套逻辑，毕竟人家做的是业务，本来就没办法亲自编写代码、也掌握不了快速排序算法的实现细节。所以只要所有测试都能顺利通过、代码可以成功部署，流程按部就班推进，那不就得了？

Jeremy Howard： 实事求是讲，这种观念我觉得还满有道理，但还不够。我们必须重视软件工程的重要意义，因为它的核心就是强调各个组件到底是什么、应该如何运作，再以此为基础将其组合成更庞大的整体，进而持续迭代以构建出宏大的系统。

只有做好了这一点，我们才能在十年之后靠 AI 打造出远超当下想象的顶尖软件。没错，只有卓越的软件工程能力才可以实现这种突破。以 IPyKernel 为例，我发现它本身就是个极其庞大的组件。

因为很明显，IPyKernel 的原始开发团队没能打造出一套可以正确验证其功能的测试集，所以才导致包括原始 nbclassic（即 IPyKernel 的源项目）在内的众多实际应用项目都无法正常运行。这正是我们 Answer.ai 开发团队的当前重点：寻找规模适应的模块，并确保其正确性。

要如何识别这些模块、如何加以设计、如何进行组合——这些能力都需要几十年的开发经验才能掌握。 我自己也是，自认为经过二十年的历练才算掌握到个中精髓。这确实是个大问题，毕竟软件工程能力的重要能力远超以往任何时候，但当下又恰恰欠缺培养这种能力的场景。未来的开发者要如何保证自己可以胜任这份工作，已经成为极具挑战性的课题。

Dr. Tim Scarfe：还有种观点是这样：抽象和表征事物的方式其实有很多。要知道这个世界如此复杂，我们人类熟悉的软件抽象与表征方式，可能更多是自身认知局限的映射。即使是在科学和物理领域，人们也更倾向以高度简化的方法来建模。但复杂科学往往必须直面事物的构造性、耗散性以及缠杂交织的本质。

也许当下就有很多软件已经超出了人类的理解上限，对吧？比如许多采用 actor 模式的全球分布式软件应用，其本质上已经属于复杂系统。我们只能通过模拟和测试来尝试理解，因为没人真正知道所有组件间如何协同运作。所以乐观地看，也许软件工程的顶层设计已经在践行这种新理念，而这也正是 AI 有望达成的终极目标。

Jeremy Howard： 倒也未必。比如说 Instagram 和 WhatsApp 这类公司，仅凭十余名员工就主导了各自领域，甚至击败了谷歌和微软等巨头。我觉得这只说明大厂那种软件开发模式正在失败，我们也亲眼目睹许多巨头正陷入日益绝望的境地。就拿微软 Windows 和苹果 MacOS 的质量来说，过去五到十年间已经遭遇显著下滑。还记得当初 Dave Cutler 逐行审阅 NT 内核代码，确保每一行都完美无瑕的时代吧？那才是真正优雅卓越的软件典范。但如今世上不会有人觉得 Windows 11 是优雅精妙的软件。所以我们可以真的需要先打造出完全可按的小组件，再把它们堆叠起来实现构建。

问题是 AI 在这方面表现相当糟糕。我这可是基于实证得出的结论，它们在软件工程领域简直不堪一击，而且这种情况可能永远不会改变。因为我们总要求 AI 突破训练数据的边界，尝试构建前所未有的事物，追求超越现有方案。换言之，我们一方面只提供有限的训练数据，另一方面又指望它别单纯照搬训练过的内容。这点常常让人们困惑——他们看到 AI 编程能力如此出色，便误以为这等同于软件工程能力。但这二者的本质完全不同，重合度也很低。目前还没有任何实证数据表明大语言模型在软件工程领域实现了任何显著的能力提升。

每当我们审视 AI 完成的软件工程案例，比如 Cursor 开发的浏览器或者 Anthropic 搞出来的 C 编译器——另怀疑，我认真看过这些项目的源代码，再加上更熟悉编译器的 Chris Latner——其本质都是对现有成果的明显照搬。这正是我眼中最核心的挑战所在：要想做出真正原创性的成果，就不能依赖大语言模型。

理论上我们没办法相信大模型会涌现出这种原创能力，实证数据也同样支撑不了这样乐观的猜想。

最先进的 AI，却在用 40 年前的开发环境

Dr. Tim Scarfe：没错，我觉得这场对话最大的价值就在于，我们需要实现 AI 与人类的协同合作。由人类提供理解力，还有我们之前讨论过的各种知识层面的支持。但与此同时，AI 仍然不失为一种重要且强大的工具。我们只要设计出运作模式或者工作方式，确保自身的独特能力、特别是理解力不被削弱就行。

Jeremy Howard： 没错，这里确实有条微妙的分界线，也是我们在教学与内部开发时关注的核心点。我这二十年来持续探索的方向，终将成为支撑整个体系的关键。Stepehn Wolfram 创造了 notebook 界面，虽然其中很多理念可以追溯至 Samlltalk、Lisp 和 APL，但其意义仍然非常值得肯定。他的核心思想在于：当人类能够实时操作计算机内部对象、研究它们、移动它们并加以组合，就可以通过计算机实现更多可能。

而 Smalltalk 的核心理念也正是基于对象，APL 同样以数组为基础。Mathematica 本质上就是功能强大的 Lisp 语言，只是在此基础上融入了优雅的 notebook 界面，让开发者能够构建出动态生成的活文档。

几年前我开发了 nbdev 工具，它能在 notebook 界面跟丰富的动态环境中构建起生产级软件。我发现这极大提升了自己的编程效率。虽然我从来没做过全职编程工作，但大家可以看看我的 GitHub 代码仓库产出——根据统计数据，我几乎是全澳大利亚最高效的程序员。这证明我的办法确实行之有效。我开发的许多工具被大量用户采用，凭借的就是出色且丰富的构建方式。

如今我们发现，在把 AI 置与跟人类相同的交互环境中时，其表现同样会显著提升。可以看到，常规的 AI 编程工具，比如大家使用 Claude Code，其运行环境跟人类 40 年前使用的环境极为相似。这本质上仍然是基于代码行的终端界面。它当然可以使用 MCP 或者其他工具，但目前多数时候借助的仍然是经典的 bash 工具。

我非常喜欢 bash 工具，在日常工作中也会频繁使用各类命令行工具。从本质上讲，它就是依赖文本文件作为与外界交互的媒介，这实在有点简陋。所以我们将人类与 AI 置于 Python 解释器内，立刻就得到了能帮助人类与 AI 对话的强大工具——一种优雅且富有表现力的编程语言。

现如今，AI 能与计算机对话，人类能与计算机对话，计算机又能与 AI 对话。在这种丰富的交互生态中，人类与 AI 得以实时协作，共同构建起双方都能使用的工具。这也是我所追求的核心价值，创造一个让人类能够参与、成长且共享的环境。

于我而言，使用 SolveIt 的体验跟你之前提到的 Claude Code 恰恰相反。用了几小时后，我感觉神清气爽，快乐而充实。

Dr. Tim Scarfe： 我来谈谈自己的看法。你刚刚的核心观点，就是具备交互性、状态感知且能够提供反馈的环境，具有某种神奇的魔力。这是因为我们的大脑能够处理特定的工作单元，我们会通过反复推敲加现实检验的方式来思考问题。正因为如此，我才会在攻读博士期间选择使用 Mathematica 和 MatLab。

我完全赞同你的结论。这种 REPL 环境能让我们直接操作数组、生成图像图谱、实时调整参数以即时呈现变化效果。这确实是优化思维模型的绝佳方式。不过 Claude Code 也能实现类似的功能，关键在于适当使用操作技巧。高效使用 Claude Code 的开发者普遍具备这种能力。我也开发过内容管理工具，也就是 Rescript，它在制作纪录片视频时能自动提取字幕文本，帮我核查陈述内容的真实性。

总之，AI 素养的核心在于理解语言模型在能力上的不对称性。在要求其处理鉴别型任务时，它们的表现往往非常出色。例如在子智能体模式下要求其逐条验证主张时，它的准确性就远高于生成模式下批量生成的主张。关于状态反馈机制，我们可以采用结构化 XML 导出方案，配合侧边栏可视化应用来形成反馈循环。

对我而言，这文治武功 AI 的优势所在，也是善于借 AI 之力的使用者们的首选用法。

Jeremy Howard： 是的，但我并不完全认同你的观点。我知道也可以在 Claude Code 中实现相同的效果，也同意具体效果取决于使用者的 AI 素养，但 Claude Code 的设计初衷并不在此。它并不擅长此类操作，这也不是跟 Claude Code 交互的自然方式。我倒不觉得这是 AI 素养的问题——在我看来，如果工具无法以人类熟悉的方式获取更深的知识、更愉悦的体验和更紧密的联结，还有对工作内容的透彻理解并建立情感纽带，那这绝对是工具的问题，不能说是人的问题。

工具的设计就应该符合人体工程学。但如今，很多模型和工具的评估标准就只是能否接管完整任务并独立完成。这在我看来是种重大谬误。真正的关键在于：人类在使用之后，能否真正掌握该领域的知识，进而轻松构建出更多成果。

Claude Code 正在背离“人机共创”的软件传统

Dr. Tim Scarfe：我完全赞同。但还有另一个有趣的视角——Joel Grus 曾有一场著名的演讲，我们稍后会具体聊。他说 Notebook 程序糟糕透顶，从软件工程角度看简直不堪入目。当时，哪怕是到现在可能也仍然如此，我其实挺认同他的观点。毕竟我也从事过机器学习的运维工作，在大型机构中负责探索数据科学与软件工程之间的连接。

相较于 Notebook，Claude Code 其实更偏重软件工程领域，因为它能生成幂等、无状态及可重复的成果。如你所说，从教育角度看这种基于状态的反馈其实很好，因为我能够理解到底发生了什么。之后只要把它转化成可部署的成果就行了。

所以你能聊聊 Joel Grus 的观点吗？记得你当时的回应还闹得挺大的，给我们讲讲呗。

Jeremy Howard： 他当时拍了段精彩的视频，就叫《我不喜欢 Notebook》，制作精良而且超级搞笑。现在我承认，我当时的观点完全错了。

他列举了很多 Notebook 做不到的事，但其实都能做到。他说 Notebook 实现不了的功能，其实我每天都在靠 Notebook 实现。可那场演讲虽然错误百出，却实在妙趣横生。后来我模仿他的风格做了段《我喜欢 Notebook》的视频，基本照搬了他的大部分 PPT 并注明了出处，然后逐条反驳了每条谬误。

不过你提到的核心问题确实切中了要害——这本质上其实是软件工程与科学研究等领域在工作方式上的根本差异。我认为这种二元对立确实存在，这样的割裂也着实令人遗憾。软件开发的推进方向出了偏差， 当前的模式完全聚焦于可复现性，却无视僵化代码与文件的持续膨胀。 项目里全都是死代码、死文件，这事我强烈推荐大家去看看 Brett Victor 的论述，他的讲解特别精彩。他反复证明：最重要、最正确的方向，永远是跟所做之事建立起直接且符合直觉的联结。

他也将此作为自己的使命，确保人们能够建立起这种联结。我也把这当作自己的使命。于我而言，传统软件工程已经大大偏离了这样的联结。我觉得它令人作呕、简直恶心，更可悲的是人们正被迫以这样的方式工作。这不止反人道，而且模式本身根本就行不通——经验证明其效果极差。对 AI 是如此，对人类更是如此。

事情并不总是这样的。回到早期，比如 Alan Kay 的 Smalltalk，Iverson 的 APL，还有 Wolfram 的 Mathematica。在我看来，那才是“黄金时代”。

那个时代的人真正关心的问题是： 如何让人类尽可能紧密地与计算机一起工作。 比如鼠标的诞生也是如此，通过点击和拖拽操作将计算机中的对象可视化为可移动的实体。可多年过去，如今我们却失掉了正确的方向，这实在令人痛心。

而像现在用 Claude Code 这样的工具时，默认的工作方式却完全相反：你需要深入到一个系统内部，那里有一整个文件夹的代码文件，但你甚至从来不会去看它们。你与系统的全部互动，只是通过一个 prompt。

老实说，这让我真的感到反感。我是真的觉得这种方式有点不人道。

而我的使命，其实二十年来一直没有变：就是想办法让人们不再用这种方式工作。

Dr. Tim Scarfe：明白。但回想起来，我当初跟数据科学家们共事时，他们都在用 Jupyter Notebook。当时我就发现，如果把这些 notebook 直接提交到 Git 仓库，效果通常不太理想。

大多数数据科学家根本不懂 Git 操作，他们会打乱单元格的执行顺序，导致结果无法复现，类似的问题层出不穷。我同意你的观点，这些工具确实更能融入工作流程。但这又回到了我之前提出的核心问题：就像我们讨论客服中心时说的，那属于低智力需求的工作。要知道，数据科学家之所以属于高智力工作，是因为他们在创造前所未有的事物。他们在探索问题的边界，在认知模糊的领域开疆拓土。当然有人会争辩，说如果数据科学家能够清晰界定问题的边界，也许就能借助 Claude Code 实现精准落地了。但是我们该如何在这两个世界之间架起桥梁？

Jeremy Howard： 我觉得这个主意实在没有必要，你总不是想把人从探索性的环境中剥离出来吧？科研的进步源自人们建立洞见的过程。包括费曼在内的众多大师，那些伟大的科学家总会强调通过构建思维模型来深化直觉，而这些模型需要经年累月与研究对象的交互才能形成。以费曼为例，由于从事理论物理研究，他不可能实际接触旋转的夸克，但他会尝试研究旋转的盘子。我们必须自己想办法找到深度交互的方式。我见过很多数据科学团队，他们不只是对 Git 不熟悉，他们对自己本该理解的事物也不熟悉。

所以他们的头头往往是一位软件工程师，解决方法就是要求所有数据科学家都停止使用 Jupyter Notebook。现在，他们被迫使用各种可复现的虚拟环境，而这种做法在不断摧残团队。我目睹过太多类似的情况了。正确的解决之道并不在于增设更多纪律条文和官僚职位，而在于解决实际问题。比如我们开发了一款名叫 nb merge driver 的工具——很多朋友不了解，其实 notebook 本身非常适合 Git。只是 Git 并没有默认为 notebook 提供合并驱动，而仅支持基于行的文本文件。可 Git 系统是支持插件扩展的，所以我们可以轻松通过插件兼容 JSON 文件。

于是我们开发了这类驱动程序。现在只要使用我们的 merge 驱动进行 Git 差异比较，就能在单元格级别上看到差别。每次遇到合并冲突，可以直接定位到单元格级别的具体冲突点，保证 notebook 始终可以在 Jupyter 中打开。NBDime 也实现了相同的功能，大家可以随意选择。我认为这才是解决之道：继承 Brett Victor 的理念，让人们紧密把握探索性工具。所以一定要完善探索性工具，我甚至认为所有软件开发者都应该采用探索式编程，以深化对于所处理对象的理解。这样我们才能建立起对目标的强大思维模型，进而逐步提出更优解、建立更加完善的测试。

我自己几乎不需要调试器，因为我的程序里基本不存在 bug。这并不是因为我编程技艺超群，而是我采用微步迭代的方式开发——每个小步骤都经过验证，我会亲眼见证其运行效果并且实时交互。如此一来，bug 根本就无处藏身。

Dr. Tim Scarfe：其实我对这事有点矛盾。我认同你的观点，但也会质疑那些宣称组织运作模式终将固化、不再有进一步优化空间的家伙。可创新的本质就是适应性嘛，对吧？我们应该尽可能扩大适应性的覆盖范围，所以必然需要有人持续测试新想法、发现新的限制条件。

但同样的，我们也需要那些稳健可控的技术，比如用云服务和持续集成 / 持续交付（CI/CD）等方式将成果投入生产环境。

Jeremy Howard：没错。比如 nbdev 就自带开箱即用的 CI 集成，还内置了测试功能——毕竟源代码都是 notebook 形式，整个探索过程都包含在内：API 如何动作、调用时的效果、函数实现方式、使用示例、说明文档等等。在这样的环境下，大家自然能把软件工程处理得更好。总之就应该全都要。

AI 没大家说得那么吓人

Dr. Tim Scarfe：你还记得那份关于《应将存在性风险列为紧急优先事项》的声明吗？当时 Hinton 和 Demis Hassabis 都有联合署名。而你基本上是通过反驳来回应的。聊聊那时候的情况吧，你觉得我们应该担心 AI 带来的存在性风险吗？

Jeremy Howard： 那只是特定时期的问题，对吧？如今的形势已经有所转变，实在是谢天谢地。我们所处的整个学术社群，从某种意义上赢下了这场论战。现在我们面临其他更为紧迫的问题，但当时的主流观点是：AI 即将实现自主化。这种随时可能实现的自主，也许会将世界推向毁灭。这种观点很大程度上源自 Alizia Yukowski 的研究，但其结论已经在多个层面被证明是错的。

Dr. Tim Scarfe： 他们当然也有反驳的理由。

Jeremy Howard：没错，就像邪教做出的末日预言一样，只要不给出具体的日期，他们就总有话说。

Dr. Tim Scarfe： 那我稍微修正一下：当前的大模型在特定领域确实可以作为智能体，ARC 挑战赛的结果已经证明了这一点。因此如果把方向收窄一些，可能自主的目标真会更快实现。而这就带来了新的难题：当全面的智能化与自主性实现之后，如果缺少知识和约束，AI 只会更快走向错误方向。很多人其实没有意识到大模型在认知层面的匮乏……

Jeremy Howard： 但这些都跟我反驳的核心观点无关——我们始终强调，那份声明对于真正的危险所在做出了误判。没错，当一种极具颠覆性的技术涌入世界，就会让某些人获得颠覆性的力量。而那些痴迷权势的家伙必然会试图垄断这项技术。

技术越强大，渴求者们的欲望就会越强烈。所以真正的问题在于：如果不在乎这些潜在风险，单纯想尽快推进自主 AI 的崛起，那么唯一的结果就是权力得到空前的集中。这正是当下我们已经反复见证的现实。所有的权力都被交给了超大型科技企业和政府，普通人根本就无法染指。而在我的威胁模型当中，这是最糟糕的结果，因为它带来了权力的过度集中。而渴望权力的人只要拿下那个集中的点，就能获得一切。

Dr. Tim Scarfe：那我们能不能明确一下“权力”的定义？因为我们刚刚也聊过，AI 的实际影响力并不像大众想象中那么强。

Jeremy Howard：我认为 AI 到底有没有那么强大或者那么深远的影响，其实都不重要，因为这纯属推测。我坚持的是，这种权力就不该集中在少数公司或者政府手中。因为一旦集中，贪婪者会迅速将其垄断，进而摧毁整个人类文明。过去几百年来，人类社会曾经反复遭遇过这种困境。

就像文字发明之初，只有极少数精英能够掌握书写能力，而史册也就在他们的指尖流转。当时也有类似的论调：若放任大众书写，他们必将写下我们不愿见到的内容，后果不堪设想。

可印刷术的普及证明，根本没这回事。选举制度的推行也是如此。社会始终在与既得利益者的本能性偏见对抗，试图证明变革并不是威胁。所以当我们讨论 AI 可能变得极其强大时，那带来的成果到底是让少数人掌控收益，还是把成果共享给整个社会？

我的观点肯定是后者。当然也有人会说，不用担心啦，AI 不可能发展得那么强大。这个不重要，因为大家根本就没有确凿的证据，谁也说不准未来会发生什么。但我可以明确地讲：万一那么强大的技术出现了，那我们应该放任马斯克或者特朗普一人将其掌控吗？这明智吗？

Dr. Tim Scarfe：Dan Hendricks 曾经讨论过攻防不对称性的话题。建立制衡性的防御体系确实非常重要，但权力失衡又是一种不容辩驳的现实。无论是 Meta 还是 Facebook，这类平台掌握着所有用户数据，知晓我们的全部行为。至于 OpenAI 和 Claude 这类技术，实际效果反而不如预期，因此允许人类继续参与其中。可数据确实还是由他们掌握的，对吧？

假设我们在研发创新技术时使用 Claude，那上传的信息就能让他们轻松复制我们的成果。所以具体来讲，你指的是哪些风险？

Jeremy Howard： 我指的风险并不是这些具体的情况，而是一个假设性的问题：如果 AI 变得极其强大，未来会是什么样的样貌？

Dr. Tim Scarfe：比如现在就有人宣称，AI 代表着新的生产方式。这在我看来完全是夸夸其谈，那依你的判断，这里具体存在怎样的风险？

Jeremy Howard： 按目前的技术状态来讲，我认为最大的风险就是人们会丧失持续提升自身能力的机会，逐渐陷入能力衰退的陷阱。这才是我最担忧的问题。

隐私风险确实存在，但我至少不觉得比谷歌和微软早期的情况更严重。你之前在微软工作过，肯定清楚他们掌握着多少普通用户的 Outlook 和 Office 数据。谷歌也是如此，Google Workspace 和 Gmail 用户的数据量已经说明了一切。这些隐私问题确实存在，但我认为更可怕的是企业只是外包商，负责替政府进行数据收集的可能性。

过去是 ChoicePoint 和 Acxiom 这类公司，如今又出现了 Palantir 等企业。美国政府不能亲自建立大规模公民数据库，但法律却不禁止企业自建数据库，这就相当于政府把业务外包给了企业。这才是最大的问题，当然并不是 AI 时代的独有难题。

以你所在的英国为例。众所周知，英国的监控体系早已实现全面覆盖，这也让对监控数据的利用更加便捷。以及需要资源充足的机构投入足够的人手，才能让土地上发生的一切都尽在掌握，但现在 AI 能够轻松完成。所以我不是说 AI 时代才带来了隐私问题，但它至少让隐私问题扩大化了。

原文链接：

https://www.youtube.com/watch?v=dHBEQ-Ryo24&t=3914s

本文来自微信公众号 “InfoQ”（ID：infoqchina），作者：核子可乐、Tina，36氪经授权发布。

Indeed招聘数据显示全球软件工程师的岗位招聘量全面反弹

Mon, 02 Mar 2026 16:33:58 CST

根据近期Indeed的招聘数据和相关行业分析，软件工程师的岗位招聘量正处在一个总量增长但结构分化的关键时期。最新的数据明确显示，市场对软件工程师的需求并非缩减，而是在持续增加，但这背后伴随着对技能要求的深刻变革。

📊 核心数据：岗位总量在增长

根据金融巨头Citadel Securities在2026年2月底引用Indeed的数据，软件工程师的职位数量同比增长了11% -3。此外，2026年1月的行业分析也显示，单月全球软件工程领域的招聘岗位曾突破10.5万个，标志着行业从之前的增长放缓中全面反弹 -7。

🔍 数据背后的趋势解读

这11%的增长并非简单的数字游戏，它反映了当前技术就业市场的几个深层变化：

AI的“替代论”被证伪，需求转向“增强”：尽管外界担忧AI会导致大规模失业，但实际数据反驳了这一点。正如Citadel Securities的报告所指出的，AI更像是一个“生产力冲击”，类似于历史上的电气化和计算机，它正在创造新的经济机会和岗位，而非简单地消灭工作 -3。企业利用AI扩大产出，反而催生了新的开发需求 -5。
岗位结构发生剧变：初级岗承压，资深/复合型岗紧缺：增长的岗位主要集中在需要深厚经验和跨学科能力的领域。与此同时，初级开发者的入门路径变得崎岖 -5。
- 人才流向高价值领域：人才正大量涌向人工智能/大模型、机器人与具身智能、生物信息学、新能源与气候科技、网络安全等高技术壁垒领域 -6 -7 -8。
- 企业招聘更务实：企业不再满足于“会写代码”，而是极度渴望能解决实际问题、有系统架构能力、懂业务逻辑的复合型人才 -8。
AI重塑了工程师的核心技能：现在的工程师，核心竞争力不再是单纯的编码速度，而是利用AI作为“力量倍增器”，并具备判断AI何时出错、优化系统设计、保障安全与合规的能力 -5。简单来说，市场需要的是能驾驭AI的专家，而非被AI替代的“代码民工”。

💡 总结与展望

Indeed上软件工程师岗位11%的年增长是一个强有力的信号：技术变革正在创造新的就业机会。但这意味着，未来的机会将更加青睐那些主动拥抱变化、持续学习、并将技术深度与业务广度相结合的工程师。

未来两年的软件工程

Tue, 13 Jan 2026 16:14:28 CST

原文：未来两年的软件工程网址：

https://addyosmani.com/blog/next-two-years/

作者：阿迪·奥斯马尼

软件行业正面临一个奇怪的拐点。AI 编程已从单纯的“超级自动补全”，进化为能自主执行开发任务的 AI 智能体 (AI Agents)。曾经助推科技界“抢人大战”的经济泡沫已破，取而代之的是对效率的硬性指标：企业现在更看重利润而非增长，更青睐老手而非应届生，更倾向于用神兵利器武装精简的团队。

与此同时，新一代开发者正步入职场，心态截然不同：他们务实地追求职业稳定，质疑“内卷文化”（hustle culture），并且从入行第一天起就是 AI 的原住民。

未来充满了不确定性。以下是将在 2026 年之前重塑软件工程的五个关键问题，我为每个问题设想了两种截然不同的情景。这并非预言，而是帮助大家做准备的透镜。目的是基于当下的数据，结合社区特有的良性怀疑精神，为应对未来提供一份清晰的行动指南。

---

1. 初级开发者问题

核心结论：随着 AI 接管入门级任务，初级招聘可能崩盘，也可能随着软件渗透各行各业而反弹。两种未来，生存法则截然不同。

传统的“学编程、找工作、升高级”路径正在动摇。哈佛大学一项涵盖 6200 万工人的研究显示，企业采用生成式 AI 后，初级开发者就业率在六个季度内下降了约 9-10%，而高级开发者几乎不受影响。过去三年，

大型科技公司对应届生的招聘腰斩

。有位工程师曾讽刺道：~“既然 AI 编程智能体更便宜，何必花 9 万美元雇个初级新手？”

这不全赖 AI。

利率上升和疫情后的修正等宏观因素

在 2022 年就已造成冲击。但 AI 加速了这一趋势。现在，一个高级工程师配上 AI，能抵得上过去一个小团队。公司倒也没怎么大裁员，而是悄悄关上了初级招聘的大门。

反转情景：AI 释放了各行各业对开发者的巨大需求。医疗、农业、制造和金融业都开始通过软件实现自动化。AI 非但没取代开发者，反而成了“力量倍增器”，将开发工作扩展到了从未雇佣过程序员的领域。我们将看到更多入门级角色，只是形式变了：即“AI 原生”开发者，快速为特定细分领域构建自动化方案。

美国劳工统计局仍预计

2024 至 2034 年间软件岗位将增长约 15%。如果企业用 AI 是为了扩大产出而非单纯砍人头，

他们将需要人类来抓住 AI 创造的机会

。

悲观情景有个常被忽视的长期风险：今天的菜鸟是明天的大神。切断人才输送管道，5 到 10 年后就会出现领导力真空。

行业老兵称之为“慢性衰退”

：一个不再培养接班人的生态系统。

应对策略：

初级开发者：精通 AI，做个多面手。证明“你 + AI”能抵得上一个小团队。利用 AI 编程智能体（Cursor/Antigravity/Claude Code/Gemini CLI）构建大功能，但要理解并能解释每一行代码。死磕 AI 难以替代的技能：沟通、拆解问题、领域知识。关注邻近角色（QA、开发者关系、数据分析）作为切入点。建立作品集，特别是集成 AI API 的项目。考虑学徒制、实习、合同工或开源项目。别做“待培训的应届生”，要做能快速学习、即插即用的工程师。

高级开发者：初级人员减少，意味着更多脏活累活会落到你头上。依靠自动化处理常规任务，但别事必躬亲。设置 CI/CD、代码检查器（linters）和 AI 辅助测试来捕捉基础问题。通过开源或指导同事进行非正式辅导。

向管理层坦诚“全高级团队”的风险

。如果初级需求反弹，做好有效带人和委派任务的准备。你的价值在于放大整个团队的产出，而不仅仅是贡献代码。

---

2. 技能问题

核心结论：随着 AI 包办大部分代码，核心编程技能可能退化，也可能因人类转向监督角色而变得前所未有的重要。未来几年将决定：我们是牺牲理解换速度，还是两者兼得。

84% 的开发者现在经常使用 AI 辅助

。许多人遇到 Bug 或新需求，第一直觉不再是写代码，而是写提示词（Prompt）并拼接 AI 生成的片段。入门级程序员正在跳过“练基本功”的阶段：他们可能永远不会手写二叉搜索树，也不会独自调试内存泄漏。

技能天平正在倾斜：从实现算法转向懂得向 AI 提问并验证其输出。

职业阶梯的第一级现在考的是提示和验证 AI

，而非生写代码的蛮力。一些高级工程师担心这会造就一代“去技能化”的开发者，无法独立写出好代码。AI 生成的代码可能藏着微小的 Bug 和安全漏洞，经验不足的开发者很难发现。

反转情景：AI 处理那 80% 的常规工作，人类死磕那 20% 的硬骨头。架构、棘手的集成、创造性设计、边缘情况——这些是机器搞不定的。AI 的普及非但没让深度知识过时，反而让专家经验变得价值连城。这就是“高杠杆工程师”：利用 AI 放大力量，但必须深刻理解系统才能驾驭它。

如果人人都有 AI 编程智能体，区分高下的标准就是知道 AI 何时在胡说八道。

正如一位高级工程师所言

：“最好的软件工程师不是写代码最快的人，而是懂得不信任 AI 的人。”

编程方式在转变：少打样板代码，多审查逻辑错误、安全缺陷和需求偏差。关键技能变成了软件架构、系统设计、性能调优和安全分析。

AI 可以秒生成 Web 应用，但专家能确保它符合安全规范

，且没有引入竞态条件（Race Conditions）。

2025 年的开发者舆论严重分裂。有人承认几乎不再“亲手”写代码，呼吁面试改革；有人则认为跳过基础会导致 AI 出错时无力“救火”。

行业开始期待工程师两者兼备

：既有 AI 的速度，又有保证质量的内功。

应对策略：

初级开发者：把 AI 当学习工具，别当拐杖。当 AI 建议代码时，搞懂它为什么行，找出它的弱点。偶尔关掉 AI，徒手写关键算法。扎实 CS 基础：数据结构、算法、复杂度、内存管理。把项目做两遍：一遍用 AI，一遍徒手，对比差异。学习提示工程（Prompt Engineering），精通工具。刻意练习严格测试：写单元测试，看懂堆栈跟踪（别一上来就问 AI），熟练使用调试器。深耕 AI 无法复制的软实力：系统设计、用户体验直觉、并发推理。展示你既能用 AI 极速产出，又能在 AI 歇菜时力挽狂澜。

高级开发者：做质量和复杂度的守门员。磨练核心专长：架构、安全、扩展性、领域知识。练习用包含 AI 组件的模型设计系统，推演故障模式。时刻警惕 AI 代码中的漏洞。拥抱导师和审查者的角色：界定哪里能用 AI，哪里必须人工审查（如支付或安全代码）。投入创造性和战略性工作；让“初级人员+AI”处理常规接口，你来决定建哪些接口。投资软技能和跨领域知识。紧跟新工具。加倍投入人类开发者的不可替代性：健全的判断力、系统级思维和指导能力。

---

3. 角色定位问题

核心结论：开发者角色可能缩水为单纯的审计员（监督 AI 代码），也可能扩展为设计和治理 AI 系统的核心编排者。无论哪条路，想创造价值，光写代码已经不够了。

两极分化十分严重。悲观视角下，开发者的创造性被剥夺。他们不再构建软件，只是审计和看管 AI 的输出。AI 系统（或使用无代码平台的“公民开发者”）负责生产；人类负责审查、纠错、查重和批准。制造者变成了检查者。风险管理的焦虑取代了创造代码的乐趣。

有报告称，工程师花更多时间评估 AI 生成的合并请求（Pull Requests）和管理自动化管道，写代码的时间反而少了。编程不再像创造性地解决问题，更像是合规检查。一位工程师感叹：“我不想沦为代码保洁员，专门清理 AI 扔过墙来的垃圾。”

另一种未来则有趣得多：开发者进化为高级编排者，集技术、战略和伦理责任于一身。AI 只是“工人”，人类开发者是架构师或总包商，设计系统、分配任务、将众多组件编织成网。

某低代码平台 CEO 描绘了这一愿景

：在“代理式（Agentic）”开发环境中，工程师变身“作曲家”，指挥 AI 智能体和软件服务协同演奏。他们不亲自写每一个音符，但定义旋律：架构、接口、智能体交互方式。这个角色跨学科且充满创造力：集软件工程、系统架构和产品策略于一身。

乐观来看：AI 处理了死记硬背的工作，迫使开发者转向高价值活动。工作可能更有趣了。总得有人决定 AI 该造什么，验证产品是否合理，并持续改进。

局势取决于组织如何整合 AI。视 AI 为裁员工具的公司，会让剩下的工程师当保姆维持运转。视 AI 为增效工具的公司，会保持团队规模，但要求交付更宏大的项目。

应对策略：

初级开发者：寻找写代码之外的机会。主动承担写测试用例、设 CI 管道或应用监控的任务：这些技能符合审计/维护者的角色。通过个人项目保持创造热情，别丢了构建的乐趣。培养系统思维：学习组件如何通信，什么才是好 API。阅读工程博客和系统设计案例。熟悉代码生成以外的 AI 工具：编排框架、AI API。提升沟通能力（书面和口头）。写文档要像给别人讲课一样。问资深同事问题时，别只问“能跑吗？”，要问“我想全了吗？”。准备好成为验证者、设计者和沟通者，而不仅仅是码农。

高级开发者：向领导力和架构职责靠拢。制定标准，确立框架。定义代码质量清单和 AI 伦理规范。关注 AI 软件的合规与安全。深耕系统设计和集成；主动梳理跨服务数据流，识别故障点。熟悉编排平台（Kubernetes, Airflow, Serverless, Agent 工具）。加倍投入技术导师角色：多做代码审查、设计讨论、技术指导。练就一眼看穿代码（人写的或 AI 写的）本质的能力。培养产品和商业嗅觉；理解功能背后的商业逻辑。跟随产品经理，倾听客户声音。通过原型、黑客马拉松或新技术研究保护你的创作火花。从代码员进化为指挥家。

---

4. 专才 vs. 通才问题

核心结论：路走窄了的专才恐被自动化淘汰。在快速变化、AI 渗透的环境下，T 型工程师更吃香：既有广泛的适应力，又有一两手绝活。

鉴于模型、工具和框架兴衰更迭极快，押注单一技术栈风险极大。当新 AI 工具能轻松搞定某项技术时，该领域的旧日大师可能会突然发现自己不再抢手。那些死守“单一技术栈、框架或产品”的开发者，可能一觉醒来发现天变了。

想想那些没随行业转型的 COBOL 开发者、Flash 开发者或移动引擎专家吧。现在的不同在于变化的速度。AI 自动化让某些编程任务变得微不足道，直接削弱了相关岗位的价值。如果一个专家只会微调 SQL 或切图，AI 能替他干 90% 的活。

招聘经理永远在追逐最新的利基市场。前几年是云基础设施，现在是 AI/ML。死磕过气技术的人，会随着领域退潮而陷入停滞。

相反，新形式的专业化——“多才多艺的专家”或

T 型开发者

正在崛起。一竖是深厚的专精领域，一横是广泛的涉猎。

这些工程师是多学科团队的“粘合剂”

，能跨界交流，填补空白。

公司不再想要太浅或太窄的开发者

；他们想要核心强、能跨栈的人。一来是为了效率：T 型人才无需等待交接，能端到端解决问题。二来是为了创新：知识交叉能碰撞出更好的方案。

AI 工具其实是通才的神器。后端工程师可以用 AI 做个像样的 UI；前端专家可以用 AI 生成服务端代码。AI 让人的能力边界大幅拓展。反观深度专才，领地被自动化蚕食，却难以突围。

近 45% 的工程职位现在要求精通多领域

：编程 + 云基建，或者前端 + ML 基础。

应对策略：

初级开发者：尽早打好宽基。即便为了特定岗位入职，也要把头探出孤岛看世界。做移动端就学学后端；做前端就试试写个 Server。学习 Docker 或 GitHub Actions 等部署工具。找到一两个真正让你兴奋的领域深钻，作为垂直专长。把自己打造为混合型人才：“专注云安全的全栈”或“懂 UX 的前端”。利用 AI 快速扫盲新领域；对后端一窍不通？让 ChatGPT 写个 API 范例研究下。养成持续重塑技能（re-skilling）的习惯。参加黑客马拉松或跨职能项目，逼自己做通才。告诉经理你想接触项目的不同部分。适应力是你早期的超能力。

高级开发者：绘制技能图谱：哪是专长？哪是皮毛？选一两个相邻领域，练到能对话的程度。你是后端数据库专家？去学学现代前端框架或 ML 管道。在弱项领域用 AI 辅助做个小项目。将深厚专长与新语境结合；比如专精 Web 性能，就去研究 ML 推理优化。设计你的角色，让它更跨职能。主动当多领域项目的“集成冠军”。指导他人，互通有无。更新简历，体现多面手能力。利用经验识别模式，迁移知识。做 T 型人才的榜样：在专业领域深耕（这是你的底气），但积极横向拓展。

---

5. 教育问题

核心结论：CS 学位还是金字招牌吗？还是会被训练营、在线平台和企业培训等“快车道”超车？行业数月一变，大学恐怕追赶乏力。

四年制计算机科学学位长期以来是入行的硬通货。但这一传统正受到挑战。

一种未来：大学依然重要，但日益脱节。学位仍是门槛，但课程更新慢、审批流程长，跟不上需求。学生和雇主觉得学术界与工业界是两个世界，教的理论变不成干活的技能。

应届生反映，在校没学过云计算、现代 DevOps 或 AI 工具。如果大学耗费巨资和时间，却提供低相关性的教育，它们就有被视为昂贵“守门人”的风险。但许多公司惯性使然，仍要求本科学位，压力全在学生身上——得靠训练营和网课自救。

学生背负巨额债务，企业却要花数十亿培训应届生

，因为他们缺乏职场技能。大学可能加门 AI 伦理课，添个云计算选修，但等落实时，行业工具早换代了。

颠覆性情景：新体系正日益取代传统教育。编程训练营、在线认证、实战作品集、企业内训学院正在崛起。

2024 年，近 45% 的公司计划取消部分职位的学位要求

。

训练营已经成熟。毕业生也能进大厂。这些项目短平快（12 周），主攻实战：主流框架、云服务、团队协作。招聘的硬通货正变为实时作品集、微证书和实战技能。一个漂亮的 GitHub 主页或硬核证书，能帮你绕过学位门槛。

企业驱动的教育正在兴起：公司自建培训管道或联手训练营。大厂甚至开设内部“大学”。AI 本身也提供了新路径：AI 导师、交互式沙盒、个性化辅导。

模块化学习比昂贵的学位更普惠。只要有网，任何地方的孩子都能上 Coursera，做出和硅谷人才一样的作品集。

应对策略：

有抱负/初级开发者：别光指望学位。用实战项目补课：建个网站，给开源项目提个 PR。找实习。如果课程落伍，就上网自学。考取行业认可证书（GCP, AWS, Azure）证明动手能力。如果是自学或上训练营，打磨作品集：至少有一个文档完善的硬核项目。活跃于社区：贡献开源，写技术文章。混 LinkedIn、参加聚会，建立人脉。找老司机为你背书。保持持续学习；技术保质期很短。把 AI 当私人导师。用具体方式证明实力：作品集、证书、能侃侃而谈项目细节，这些才是敲门砖。

高级开发者和领导者：一纸文凭吃不了一辈子。投资继续教育：网课、工作坊、大会、考证。以新方式验证技能；准备好在面试中解决实际问题。用新技术做副业。重新评估招聘要求：真的非要 CS 学位吗，还是看重技能和学习力？推动“技能优先”招聘，扩大人才池。支持内训或学徒制。建立导师圈，帮带非科班出身的新人。与教育机构互动：反馈课程差距。在职业发展中践行一点：实战成就和持续学习，远比多拿个学位重要。

---

结语

这些情景并非非此即彼。现实往往是混合体。有的公司削减初级岗位，有的在新领域扩招。AI 自动化了常规代码，却拔高了人类代码的标准。开发者可能上午审查 AI 输出，下午设计高层架构。

贯穿始终的主线是：唯一不变的是变化本身。紧跟趋势并保持怀疑，你就不怕被炒作忽悠，也不怕被末日论吓倒。更新技能、做多面手，并专注于人类独有的特质（创造力、批判性思维、协作），你将始终立于不败之地。

无论未来是迎来编程复兴，还是代码自我编写的世界，永远需要这样一种工程师：思考全面、持续学习、用技术解决真问题。

预测未来的最好方式，就是亲手创造它。

斯坦福大学的现代软件开发者课程The Modern Software Developer

Tue, 09 Dec 2025 11:21:59 CST

课程链接：

https://themodernsoftware.dev

斯坦福计算机科学系又一次站出来告诉所有人：谁才是真正的风向标

2025秋季新开的CS146S：现代软件开发者，直接把我们最近一年新兴的AI原生软件工程整套活儿塞进了课堂

课程完整复刻AI时代的全生命周期流水线：

从零手搓编码Agent、玩转MCP协议、魔改AI IDE，到用Claude Code和Devin真刀真枪开干；

再到Warp终端代理、Semgrep实时堵安全漏洞、Graphite自动stack PR、Vercel v0一个提示词吐出生产级全栈，最后用Resolve给上线后的系统装上自主修复的“大脑”

整条线下来，几乎看不到人

这些工具其实早就被我们X上的开发者玩烂了：

Cursor、Windsurf、Aider、Continue dev、Cody、Copilot、Warp已经是标配
Cursor、Windsurf、Aider、Continue dev、Cody、Copilot、Warp 已经是标配

Semgrep+Claude把安全审查干到飞起，Graphite把PR叠成艺术品，Vercel v0+Next.js 15让全栈开发变成一句话的事

Resolve和LangSmith则直接让系统学会自己修bug

同时不愧宇宙第一大系，每周都有Cognition、Anthropic、Warp、Semgrep、Graphite、Vercel、a16z的创始人或核心开发者亲自来拆SOTA工具；作业全用最新闭源商业模型，期末项目占80%，交一个能跑的AI原生产品

虽然很fancy，但有一点小小提示：

对刚进CS殿堂或者想系统性吃透AI原生开发的新同学来说，这门课就是当前全球最硬、最完整的神课，能让你直接对齐2030年的生产力

但如果你已经天天Cursor+Claude Code+Vercel v0打仗的老兵，深度确实差点，更多是拿来对对表、补补漏

2026年如何开发软件产品

Mon, 01 Dec 2025 09:10:30 CST

1. 2026年后，纯粹的前端、后端、算法、策略岗位会越来越少，活得滋润的都是那种“左手敲代码、右手会让AI干活”的全能构建者。我问了十几个还在一线带团队的大牛，他们现在招人第一条要求就是：你能不能用AI把开发速度干到以前3倍？别再死磕手写一切了，学会借力才是王道

2. 版本控制不会Git的，2026年连面试都不用去了。SVN？那是上古神器，提了别人只会笑你。代码必须上GitHub，Gitee只适合放一些不能见光的小项目。最重要的安全常识：凡是能把你账户搞爆的东西（API Key、私钥、数据库密码），全部写进.gitignore，永远别犯低级错误，不然分分钟被人薅羊毛

3. 云服务器直接选最新版的Ubuntu LTS，Windows Server除非你想天天跟环境配置打架。想省事到极致？前端项目直接丢Vercel，免费额度够用一辈子，git push一下全自动构建部署，10秒上线，爽得飞起。很多百万用户量的独立开发产品到现在还在用Vercel免费版，真的香

4. 域名必须是自己的，越短越好记越好。别再用一堆乱七八糟的 http://github.io二级域名了，看起来就廉价。像wquguru这种个人品牌，直接买个短域名，所有产品都挂在子域名下面，用户一看到就知道是“老王家出的东西”，信任感直接拉满。我现在看到好的短域名就跟抢茅台一样下手

5. 部署必须Docker化，不接受反驳。以前最常见的扯皮就是“在我电脑上能跑”，现在直接给别人一个docker-compose.yml，谁都能一键跑起来。参考我自己的项目结构： https://github.com/wquguru/llm-council-zenmux… ，根目录干干净净，所有服务都能单独起，别人拿过去改两行就能用

6. 前端铁打的组合：Next.js + Tailwind + Shadcn UI。为啥？因为所有大模型在这套技术栈上训练的数据最多，让Claude Code帮你写组件，90%的情况下直接能用，改两行就完美。想用React + AntD也可以，但你会发现AI吐出来的代码永远差一口气。Python党想快速出demo就Streamlit，但只准做内部工具

7. 后端新手直接上FastAPI，老鸟随便你用啥。逻辑不复杂的全栈项目，直接用Next.js的API Routes就够了，全程TypeScript一门语言吃天下，上下文切换成本为零。性能真到瓶颈了再去搞NestJS、Go、Rust，到那时候你已经有钱请人了

8. 项目文件夹要让人看懂，更要让AI看懂。根目录建议这样分：frontend、backend、agents、docs，再加两个神仙文件夹：.spec（放所有规范和决策记录）+.chat（把跟AI的关键对话直接cp进去）。下次你或者别人让AI接手维护，它直接就能看懂前因后果，效率直接起飞

9. 做AI Agent千万别先摸LangChain，那东西就是黑盒子中的黑盒子，调试到崩溃。直接上官方SDK：OpenAI SDK、Claude SDK，代码量少20倍，Token省30%，还100%可控。我现在所有新Agent项目全部原生SDK，调试速度快到飞起

10. 数据库+认证直接Supabase一把梭，开源的Firebase，免费额度离谱地高，后端代码能少写80%。缓存用Upstash，Serverless Redis，跟Vercel无缝打通。一个月几块钱就能扛住几十万日活，独立开发者闭眼冲就对了。省下来的钱和时间拿去喝奶茶不好吗？

AI 能帮你写代码，但还是得靠人把代码变成软件

Wed, 29 Oct 2025 10:29:26 CST

最近发现了一个很有意思的现象，越来越多人拿着 AI 写出来的代码找我，问我能不能帮他们把这些东西变成真正能用的产品。

这些人通常不是技术背景，可能是律师、销售或者其他领域的专业人士。他们有好点子，也用上了最新的 AI 工具，甚至真的把一个看起来能跑的 demo 做出来了。

但到了某个节点，他们就卡住了，然后开始满世界找技术合伙人或者 CTO。

这让我想到一个问题：如果 AI 真的能完全取代软件工程师，为什么这些人还需要我们？

我也一直用 AI 辅助写代码，也看了很多别人的演示。慢慢地我意识到一件事：AI 确实会写代码，但它造不出软件。这两者之间有条很深的鸿沟。

写代码其实不难，解决一个个独立的、定义清晰的小问题，现在的 AI 已经做得很好了。但软件工程难的从来不是这个。

真正的挑战是当你要把 demo 变成产品的时候，你得同时处理几百个这样的小问题，还要让整个系统保持可维护、可扩展。

这就是那些人找上门来的根本原因。他们能用 AI 快速搭出一个功能演示，但要让它变成真正能上线运行的产品，就完全是另一回事了。

我看过他们发来的代码，说实话，所谓的"让它变得可以上线"，基本上就是推倒重来的意思。

不是代码写得不对，而是整个结构、集成方式、长期维护的考量，这些东西根本就不在那些代码里。

软件工程师的核心工作其实是管理复杂度。

一个真正的生产系统做的事情，单独拆开看都不复杂，但要同时做好几百件简单的事，还要让它们协同工作，这才是真正考验人的地方。

我也不知道为什么 AI 现在还做不到这一点，可能这就是这个职业的本质吧。但至少现在，这条线还是很清晰的：

AI 能帮你写代码，但把代码变成软件，还是得靠人。

工具在进化，但有些能力的门槛，并没有因此降低。

ElasticSearch 和 Kibana 再次变成自由软件

Mon, 02 Sep 2024 17:21:48 CST

2021 年初，开发 Elasticsearch 和 Kibana 的 Elastic 公司宣布更改许可证，新版本将不再使用 Apache 2.0 而是使用 Elastic License 和 Server Side Public License，此举旨在禁止云服务商如 AWS 使用它的软件作为一种服务提供给客户。但许可证的更改也意味着 Elasticsearch 和 Kibana 不再是开源软件了。亚马逊随后宣布创建 ElasticSearch 开源分支 OpenSearch。三年之后，Elastic 再次宣布更改许可证，Elasticsearch 和 Kibana 将采用 Affero GPL 许可证，它们再次成为开源自由软件。OpenSearch 带来的竞争压力让 Elastic 公司再次拥抱开源，但已经跳船的用户会回到旧的船上吗？

如何构建高质量软件：一个被忽略的课题 [译] | 宝玉的分享

Sat, 09 Dec 2023 11:55:31 CST

by Florian Bellmann

你是否曾在一个软件项目中发现缺少关键的质量保证（QA）措施？这种情况其实在很多公司和项目中都普遍存在。很多人虽然知道有质量保证这个环节，也明白我们应该去实施它，但所有的努力往往都集中在产品发布前的那一轮紧张的 QA 冲刺中。这种压力巨大的时刻，往往只能保证软件勉强能用。而且，这种混乱在下一次的发布周期中又会重演，而且毫无改善。

大学教给你的

谈到大学教育，如果你学习计算机科学，你会发现课程并没有教授如何确保软件的质量标准。大部分时间都在学习算法、计算机的工作原理、一些编程语言和概念的历史等等。至少在我的学习经历中，还包括了一个学期关于项目管理和敏捷开发的内容。这些知识固然重要，但却完全没有涉及 QA。这是非常遗憾的，因为超过 90% 的计算机专业学生毕业后都会在公司里工作，而在这些环境中，按时交付没有缺陷的软件是非常必要的。

公司如何勉强按时交付

我已经见过太多次了：在项目预算紧张的情况下，质量保证（QA）标准和措施往往是最先被牺牲的。这些措施通常被安排在项目的最后阶段，但如果开发耗时过长（这种情况很常见）或者出现需求膨胀（几乎总是会发生），那么就没有剩余的时间来进行 QA 了。结果，我们只能进行最基本的非结构化测试，然后上线一个结构脆弱的数字产品。

在一些公司或团队中，确实存在一些 QA 标准。这通常是由团队中的资深成员来强制执行。他们很可能已经深刻体会到，没有 QA 的话，后续的工作会变得极为困难。遗憾的是，即使存在这些标准，也并不足以确保质量。这些团队经常只是为了满足项目管理的指标而编写测试，而不是真正关注质量。

如何打破日复一日的工作循环

我花了好几年的时间积累经验和信心，才敢在项目中指出缺失的 QA（质量保证）措施。我与管理层争论、在产品发布的紧张时刻苦苦挣扎、处理生产系统的故障，还要四处寻找缺失的监控措施。这些经历并不愉快。对于代码库或项目的其他改进，比如重构，情况也差不多，因为这些对管理者来说并不直观。但对 QA 来说，挑战尤为巨大，因为如果我们从未实施过任何措施，我们也就无法学会正确的方法。

当你的单元测试通过了，但集成测试失败时的情景。

只有持续提出问题，反复引发讨论，我们才能找到跳出这个无尽循环的第一步。

讨论金钱的重要性

我后来意识到，我之前的论点并不够有效。向那些不直接参与代码工作的人解释软件“更稳定”或“维护更容易”这些观点，对他们来说太抽象了。我们需要谈论的是金钱。作为开发者，我们需要讨论不进行 QA 所带来的成本。这是商业和管理层更通用的语言。现在，我总是试图用类似这样的例子来说明 QA 措施的重要性：‘如果我们现在不这样做，4 个月后的开发工作（以及相关成本）将增加 15%。’或者‘我们需要为所有功能实现单元测试，否则我们的发布稳定化阶段会越来越长。这与我们构建的每个功能直接相关，因为我们需要每次手动测试所有的副作用。这将导致我们在每次发布时取得的进展越来越少。’

根据我的经验，这种观点的转变有助于更清晰地传达问题的核心。最终，你的努力将让每个人的生活变得更好，尽管目前还不是每个人都意识到这一点。

最小有效剂量

为了保持现实，重要的是不要在 QA（质量保证）措施上进行过度设计并投入过多的初期成本。我们不应该阻碍整个项目的进展，而且这种方法也不太可能获得所有利益相关方的支持。我建议始终专注于应用程序中最关键的部分。通常，会有某个特定用例、功能或其他核心内容，整个应用就是围绕它构建的。一些对于客户而言至关重要的核心功能必须正确运行。对这些功能进行测试。想出措施和方法，确保它们始终按预期运行。

我很喜欢“最小有效剂量”（MED）这个概念。它指的是能产生预期结果的最小剂量。在 QA 中，这可能意味着一个手动测试计划、流水线中的自动化测试，或者其他方式。这是一个好的起点。如果核心功能得到了保障，你可以逐步扩展到其他稳定性更高的领域。例如，对于所有新功能，都增加一个单元测试。此外，考虑一下那些你无法控制的信息来源，如外部 API 或用户输入。找到验证它们的方法，因为这些地方是软件由于误用而崩溃的潜在风险点。进行迭代和逐步改进，这也适用于 QA。

我关注的事项

每当我开始或加入一个新项目，我都会特别关注质量保证（QA）的概念。不论项目大小，我认为团队应该对此有深入的思考。

我们准备发布什么产品？
我们需要确保哪些功能能够正常运作？
我们如何达成这个目标？
我们有意放弃哪些措施，背后的原因是什么？

拥有一份关于这些内容的书面文件，以及一个测试计划，是软件发展的坚实基础。这表明我们作为一个团队已经考虑了前进的方向。再次强调，考虑到最小有效剂量的重要性。此外，我建议定期回顾所选择的方法，比如每季度进行一次。

在编写新代码时，我虽然不采用测试驱动开发（TDD），但我强烈推荐在 编写软件的同时编写测试。这是编写测试的最佳时机。如果你在实现功能的同时编写测试，你的代码就必须被结构化成可以实际测试的形式。事后为现有软件编写测试往往会发现代码过于互相依赖，或者违反了单一职责原则。通过测试，你可以证明你理解了期望的行为，并确保一切都按预期工作。如果愿意，这甚至可以被看作是一种代码文档。

项目的好处

当你积极发言时，周围的人会感受到你对项目的关心。提出有关质量的讨论并建议可能的解决方案，可以增强你作为开发者的影响力。这不仅对你个人有利，也有利于整个项目。它能够提升开发人员和管理人员的工作生活质量，并且这种改变是显而易见的。

只有实施了合适的 QA 措施，项目才能健康、稳定地成长。

让项目变得更好的方法

你的项目中已经开始实施 QA（质量保证）措施了吗，还是一切仍显得很脆弱？你是否渴望提升自己的开发技能，成为编写优质软件的佼佼者？

先从小事做起。思考一下你项目中的最小有效剂量（MED）。主动承担责任，成为你团队中推动积极变革的引领者。不是每个人都需要成为 QA 的倡导者，但你可以通过身体力行，教会团队成员必要的方法和技巧。激发团队内的讨论。

行动起来吧。

祝好，
Flo

流动的爱？约会软件技术可供性如何影响用户的择偶实践

Wed, 25 Oct 2023 23:49:32 CST

作者：安美星

来源：微信公众号：羊村传播（ID：yangcunmedia）

近年来，主打陌生人交友的各类社交平台在青年人群体中风靡，替代朋友、同学、亲戚等传统熟人社交成为其拓展社会交往范围、寻求亲密关系的重要渠道。高成本的线下社交、难以突破的固定圈层以及来自社会期望的压力等，使那些有婚恋需求的人们寄希望于各种约会软件，试图将其作为寻找自己“另一半”的渠道。拥有地理定位、学历身份认证以及算法配对功能的约会软件确实让部分用户得偿所愿，收获了从认识到相爱再到相伴的圆满爱情。然而，随着约会软件合法化并嵌入到社会文化肌理，其作用也不再局限于拓展社会网络，而是潜移默化地改变着人们的择偶实践。

01

追溯：“罗曼蒂克”的兴起与数字化时代的爱情

尽管西方贵族有“罗曼蒂克（romantic）”的爱情，在中国也不乏才子佳人的故事，但“父母之命，媒妁之言”才是传统社会婚恋关系的真实写照。一直到19世纪现代化社会来临之后，“个人化”自由选择配偶“婚姻私人化”才开始兴起，由此才有真正意义上的“浪漫的爱”。吉登斯认为现代社会对于平等和自我的强调将“性”从繁殖中解放出来，人们越来越追求一种平等的基于双方情感和满足的“纯粹的关系”。对于纯粹浪漫关系的追求也使人们将关系中的亲密性和幸福感凌驾于社会文化准则之上，这种充满偶然性和不确定性的关系逐渐变得难以维持(Hobbs et al.，2017)。面对这些变化， 学者们指出当代人的“后现代”爱情观一方面重视情感的交流与表达，追求轰轰烈烈的爱情，另一方面又觉得基于激情的婚姻不够扎实。

进入数字化时代，在线约会软件的出现与流行成为学者们关注的焦点。围绕约会软件是否会影响人们的择偶实践和亲密关系这个问题，人们展开了一系列相关研究，包括用户关系忠诚度(Alexopoulos et al.，2020）、择偶倾向（Barrada et al.，2021)、形象展演(Hanson, K. R.，2021)以及约会实践(Solis et al.，2019)等。有研究显示，约会软件的使用会对人们的亲密关系产生负面的影响，使不少关系陷入危机，比如缺乏沟通、降低关系忠诚度(Alexopoulos et al., 2020）、引发信任危机、引起不必要的攀比等问题频现(Rosenfeld，2018)。但同时这也让人们意识到线下关系的重要性，特别是当关系出现危机的时候，面对面的沟通可能让双方准确地意识到问题所在并得到有效解决。此外，约会平台的算法逻辑及其隐含的政策使后现代的浪漫关系具有乌托邦特性：一种无风险的、无痛苦、高效率的互动，剥夺了浪漫关系的复杂性(Bandinell, C.，2022)。有研究者表示约会软件的“滑动”逻辑会破坏亲密关系的发展(David et al.，2016)。综上，约会软件流行不仅仅在亲密关系中充当渠道和媒介，而是嵌入亲密关系实践并影响着现代人的择偶观。

02

解读：技术可供性视角下的约会软件对择偶实践的影响

技术可供性强调行动者意图与技术性能的相互关系，指某一特定背景下行动者感知到的其能够使用媒介展开行动（与其需求与或目标有关）的潜能与媒介潜在特性、能力、约束范围的关系。在技术可供性的视角下，技术、社会与人之间不是简单的技术决定社会或者社会决定技术的二元互构关系，而是人与技术之间的一种功能性平衡。技术可供性理论启发我们不再孤立的研究技术，而是强调技术、环境与行动者等多方面的关系结构决定了用户在数字环境中潜在行为和结果。约会平台的技术架构赋予其可编辑性、连接性、个性化以及社交性等可供性，这些技术特性能够为用户所感知并据此展开各种行为，最终塑造了数字时代的择偶实践。

连接性与社交性降低人们对于关系的忠诚度。约会软件通过技术将移动端的用户紧密联系，相较于传统的社群和组织，无论是质量还是数量上，约会软件都为用户提供了更多的选择。与此同时，约会软件基于地理位置的接近性来为用户推送匹配对象逻辑，方便人们将虚拟空间中的互动对象纳入现实择偶的范围(Yeo & Fung，2016)。不少用户利用平台的连接性“在与一个人约会的同时与两三个人维持关系” (Hobbs et al.，2017)。多样化的选择和便捷的沟通方式为用户提供了选择的余地，让其对失去有恃无恐，也难以心甘情愿地投入到长期关系的维持中。有研究显示， 在线约会平台中感知到有更多的可潜在对象和约会成功率会正向影响用户对关系的不忠倾向(Alexopoulos et al.，2020)。

个性化强化择偶的功利化倾向。个体化时代的婚恋具有自由和风险并存的特征，人们一方面要忠于自己的情感和兴趣，另一方面也要尽可能挑选合适的伴侣，否则就要为自己的选择负责，承担失败的风险。这种情感和经济的双重逻辑使个体面临着选择的困境。约会平台的算法技术通过协同过滤识别具有相似特征的用户并推测用户喜好，根据用户在其他社交平台的关系网络和数字痕迹来为其推送所谓的“最优选择”对象，从而缩小用户的选择范围，降低选择成本。这看似为用户提供了一种自主选择和控制的感觉，在一定程度上解决个体完全凭借自己感觉做选择的困境，却在一定程度上择偶的功利化倾向。在这个以算法为中介、数据驱动的婚恋市场中，个体被算法和社会标准评估，外貌、职业、经济状况等成为衡量一个人的标准，理性和效率被应用于爱情和性的复杂性。在线约会平台变成婚恋关系市场化文化中一个工具，那些看似正确的选择不过是基于物质条件的综合考量，而非个人品行气质的独特魅力，传统那种偶然的相遇变成了一种“购买和处理商品”的行为。(Bandinelli & Gandini，2022)。

可编辑性增加了择偶的不确定性。为了弥补在线社交沟通线索缺失的特点，约会软件推出文字、图片、视频、表情包等语言线索来使用户互动更加真实具体，这也为用户进行自我形象展演提供了空间。由于身体的不在场，以及时空关系的非对称性，在线软件上的“我们”更多的是营造的“我们”，个体基于某种社交动机会自主迎合社会标准，对自我形象进行塑造，而非真实的我的直接反映。通过挑选表现较好的照片、表达自己独特的喜好和生活方式等来吸引目标对象关注、获得算法推荐成为用户彼此间心照不宣的手段。 用户的“人设”与真实情况出现或大或小差别，这放大了交友过程中的不确定性。在这种不确定性的驱动下，用户将交友平台比作危险的“黑暗丛林”，在使用中保持谨慎(孙萍 et al., 2023)。

03

反思：从技术可供性视角看见“真实”的约会软件

任何媒介技术都有其偏向性，在技术可供性的支持下，在约会软件上，人们从认知到建立浪漫关系的过程被极大地缩短，同时放弃一段关系的成本逐渐减少，纯粹且长久的情感关系难以维持。此外，约会软件的技术效率逻辑与商业的功利逻辑相互耦合，并进一步作用于平台用户的择偶实践。约会软件建构了一个流行的、碎片化的虚拟社交空间，在发挥积极效用的同时，也带来了一些负面影响。

便捷性和高效率的互动模式，促使用户陷入择偶认知陷阱。在快节奏和高压力的生活方式下，人们很难有充足的精力和时间来深入了解不同的人。在线约会软件通过大数据等技术提供了用户的基本信息，包括职业、薪资、学历、外貌形象、择偶标准、兴趣爱好、生活方式等，方便用户快速了解对方。这种高效率还体现在用户能够仅仅凭借双方之间的相互点赞等简单互动就展开聊天，其匿名性的特征又避免了害羞和胆怯使对话更加开放和直白，这些技术特性使得关系的建立更加迅速高效。移动终端的普及又使用户能够利用碎片化的时间随时随地地认知了解陌生对象并展开聊天。但这种短时间高频率的互动经不起任何的考验，一旦双方发现并没有线下发展的可能便马上放弃彼此的关系(Hobbs et al., 2017)。情感本应是深入的、持久的，但是由于参与的低成本和高效率，约会软件带来广阔的选择空间，参与者陷入一种“下次还会遇到更好的”“马上就可以认识新的人”的认知，陷入快速拓展人际关系、快速进入选择、快速丢弃的循环之中。

时空异步建构“流动的空间”，催生“流动的爱”。鲍曼（2003）提出由互联网中介的约会是一种“流动的爱”，他认为，虚拟关系正在逐渐取代更固定和持久的“真实”关系，媒介技术的广泛使用导致个人更多地考虑短暂的联系，而不是终身的伴侣关系。约会正在转变为一种娱乐活动，人们将其视为随时可以“按下删除键”的一次性活动(Bauman, 2013)。线上约会平台通过算法技术、LBS技术等建构了一个“流动的空间”，与以熟人社交为主的微信等平台不同，在此建立起来的虚拟人际关系呈现出流动性的特征。在线约会平台的互动没有约定俗成的固定社交礼仪，人与人之间的连接与断连变得十分容易。人们通常会间歇性浏览交友软件，消息的回复也没有固定时间，交友平台使用习惯呈现流动化、碎片化的特征。此外，交友平台给人们带来了“流动约会”的体验，即建立一种来去自由、并非绑定的交流关系。这样的“浅层社交”随时可以开始和结束，但又不得不在充满不确定性的关系中以“最疏离的频率”谈论最亲密的话题，因此亲密关系的建立被蒙上了一层割裂感(孙萍等，2023)。

工具理性与数字技术的结合，推动亲密关系的市场化。美国社会学家乔治·瑞泽尔提出了“麦当劳化（McDonaldization）”的概念来解释现代社会运作的逻辑，麦当劳取得成功的四大理性化原则：高效率、可计算性、可预测性和全面控制，在当代社会具有广泛的应用范围(Ritzer，2021)。有学者将其应用到在线约会中，认为社交平台和软件的介入使青年的情感需求逐渐裹挟在技术和效率的追逐之中，亲密关系呈现出短期性、快餐式的样态(罗逸琳等，2022)。 约会软件将工具理性与数字技术相结合，通过确立可计算的衡量标准以推动恋爱过程的高效率。在这种标准化氛围之下，用户逐渐用一种商品化的视角来看待自己。他们认为在婚恋市场中自己需要参与到自我品牌建构的过程中，将自己推销为“令人满意的商品”(Hobbs et al.，2017)。由此，亲密关系成了一种具有“商品化的游戏”，人们通过有选择地自我呈现来展示自己的魅力，并将其作为交换来筛选理想对象以便从中获利(Bandinelli & Gandini，2022)。

我们需要注意，技术特性虽然能够影响人们的婚恋方式，但并不能发挥决定性的作用。当代婚恋困境的形成更多是人们情感疏离且社会支持不足的结果，在线约会软件用户的择偶难题不仅是个体的困境，而是社会环境的反应和社会公共需求的表达。因此，除了约会软件完善技术架构、为用户搭建健康有序的交友平台之外，政府、社会组织以及个体等社会主体都要参与其中，共同解决人们的婚恋压力与生存困境。

参考文献：

Alexopoulos, C., Timmermans, E., & McNallie, J. (2020). Swiping more, committing less: Unraveling the links among dating app use, dating app success, and intention to commit infidelity. Computers in Human Behavior, 102, 172-180.

Bandinelli, C., & Gandini, A. (2022). Dating apps: The uncertainty of marketised love. Cultural Sociology, 16(3), 423-441.

Bandinelli, C. (2022). Dating apps: towards post-romantic love in digital societies. International Journal of Cultural Policy, 28(7), 905-919.

Barrada, J. R., Castro, Á., Fernández del Río, E., & Ramos-Villagrasa, P. J. (2021). Do young dating app users and non-users differ in mating orientations? Plos One, 16(2), e0246350.

Bauman, Z. (2013). Liquid love: On the frailty of human bonds. New York:John Wiley & Sons.

Beck, U., & Beck-Gernsheim, E. (2018). The normal chaos of love. New York:John Wiley & Sons.

David, G., & Cambre, C. (2016). Screened intimacies: Tinder and the swipe logic. Social Media+ Society, 2(2), 2056305116641976.

Hanson, K. R. (2021). Becoming a (gendered) dating app user: An analysis of how heterosexual college students navigate deception and interactional ambiguity on dating apps. Sexuality & Culture, 25(1), 75-92.

Hobbs, M., Owen, S., & Gerber, L. (2017). Liquid love? Dating apps, sex, relationships and the digital transformation of intimacy. Journal of Sociology, 53(2), 271-284.

Portolan, L., & McAlister, J. (2022). Jagged love: Narratives of romance on dating apps during COVID-19. Sexuality & Culture, 26(1), 354-372.

Ritzer, G. (2021). The McDonaldization of society. In the Mind's Eye (pp. 143-152). London: Routledge.

Rosenfeld, M. (2018). Are Tinder and Dating Apps Changing Dating and Mating in the USA?. In: Van Hook, J., McHale, S., King, V. (eds) Families and Technology. National Symposium on Family Issues, vol 9. Springer, Cham.

Solis, R. J. C., & Wong, K. Y. J. (2019). To meet or not to meet? Measuring motivations and risks as predictors of outcomes in the use of mobile dating applications in China. Chinese Journal of Communication, 12(2), 204-223.

Yeo, T. E. D., & Fung, T. H. (2016). Relationships form so quickly that you won't cherish them: Mobile dating apps and the culture of instantaneous relationships. Proceedings of the 7th 2016 international conference on social media & society,

罗逸琳, 罗昊, 黄静, & 李晓愚. (2022). 流水线式相亲：微信相亲平台中的择偶观念与社会交往研究. 传媒观察(04), 73-79.

孙萍, 李宜桐, & 于小童. (2023). “中介化爱情”之困：理解线上交友平台的媒介化与性别化. 妇女研究论丛(01), 117-128.

作者简介：安美星，主编：曾润喜，执行主编：杨柳。本文转载自微信公众号：羊村传播（ID：yangcunmedia），新鲜有趣的新闻传播学术发现之旅。由重庆大学曾润喜老师团队运营。

John Deere 预测到 2030 年软件收入将占到十分之一

Thu, 15 Sep 2022 18:24:44 CST

愈来愈多的硬件制造商拥抱软件订阅模式，硬件通常是一次性收入，而软件订阅模式能提供持续的收入来源。最新一家计划拥抱软件订阅模式的是农机巨头 John Deere，该公司预测到 2030 年软件收入将占到总收入的十分之一。该公司投入了数十亿美元开发自动驾驶拖拉机以及能区分杂草和农作物的智能喷雾器，通过为智能农机出售订阅软件获取持续收入。Bernstein 的分析师估计，农机软件的平均毛利率为 85%，设备毛利率为 25%。John Deere 计划将 150 万机器和 5 亿英亩的土地接入其运营中心，提供基于云端的智能农业服务。农民们未必喜欢这一转变，他们已经向 FTC 投诉，指控 John Deere 公司非法的拒绝提供维修农机所需要的软件和技术数据。

如何做一个好的软件架构师

Wed, 25 May 2022 18:52:48 CST

最近有人问我一个好的架构师需要哪些能力，我回想了一下自己差不多10年的架构师生涯，又去网上搜了一些什么是好的架构师的文章，把自己觉得重要的东西总结在了下面。技术方面就不多说了，这篇文章主要谈谈非技术方面的软实力。

架构师的日常工作

我们首先从架构师的日常工作开始说起，当然每个架构师的工作会不尽相同，我下面列了一些我日常工作中需要做的事情。从这里我们基本就可以看出来架构师需要具备的能力。

收集和评估功能和非功能需求
调研和评估技术选项，选择技术栈
制定开发标准，比如编码标准，代码评审流程，测试要求等
决定部署模式
设计系统架构
向别人（业务需求方、项目管理方、关联产品、开发测试人员、其他利益相关方）讲述或者推销系统架构
评估别人提出的系统架构
估计开发量
预防和缓解项目的技术风险，制定在风险发生时的应急预案
确保系统设计在团队中得以正确的实施
监督代码质量和非功能需求的实现
制定团队和产品的技术方向
组织团队和产品的技术文档
管理和提升团队的技术能力
保障团队在实现功能需求的同时，流出足够的时间来改善产品质量比如消除技术债
参与各种技术讨论，向别人提问，也回答别人的问题
等等

架构师需要的硬实力

一个好的软件架构师肯定得既懂技术，又懂业务，还懂项目管理，这是我认为好的架构师需要具备的三项硬实力。好的架构师既是软件专家，又是领域专家，还是流程专家。然而每个人的精力有限，不可能做到样样精通，就需要合理的把握深度和广度，也就是我们常说的 T型结构，在某些方面是专家，有深度。同时涉猎很多方面，有广度。

懂技术

对于软件来说，要深度就意味着得上手写代码，所谓纸上得来终觉浅。在做系统架构的时候时不时的要动手写个原型，排除一些技术上的风险和不确定性。要广度就意味着得持续学习，所谓读万卷书行万里路，多看新技术，多看别的产品是怎么做的，比如 ThoughtWorks的技术雷达就是一个很好的参考。

懂业务

这个就需要在项目的开发过程中多问为什么，真正理解用户的需求。对于很多程序员来说领域知识可能没有软件知识有趣，但是只有真正理解领域知识，才可能做出对用户真正有用的产品。

懂项目管理

这个要求相对比较容易做到，毕竟做了几年程序员后对软件开发流程都熟悉了。我觉得最值得注意的是 关于项目风险的把控，除了最直观的技术风险，要考虑非技术风险，比如预算、团队情况、对其他团队的依赖等。对所有的技术和非技术风险，都要有相应的预防缓解措施（mitigation plan）和应急预案（contingency plan），这些很多时候都是做系统架构时必须考虑的制约因素。

架构师需要的软实力

和上面的硬实力不同，软实力的养成更需要经验的累积和刻意的训练，我觉得往往比硬实力更难获得，但是这些 软实力在某种程度上更能决定架构师的水平。下面就是我认为好的架构师需要具备的九项软实力。

一、既有远见，又能务实的能力

架构师是团队的技术领袖，需要给出团队的技术发展路线图，所以一定要有远见（Vision），要知道尽管现在还没达到，但是将来我们的产品应该是什么样子。同时架构师也要和项目经理、产品经理一起保证产品能够按时发布，满足业务需求，这就要求架构师能够务实，理解在现有的约束（发布日期，团队能力，外部依赖等）下，我们能把产品做成什么样子。

这就意味着架构师脑子里从技术的角度需要有一条清晰的路径，这条路径上贯穿着产品的长期目标、中期目标和短期目标。架构师要保证短期目标和中期目标都在这条路径上，不会出现南辕北辙的情况。既有远见、又能务实说起来容易做起来很难，需要知道什么时候应该坚持，什么时候可以妥协，这就是下面这条 权衡的能力。

二、权衡的能力

我一直觉得架构设计就是一个不断权衡的过程，如果针对一个问题，有一种解决方案在各方面都明显的好过其它所有的选项，在这种情况下是不需要架构师的，直接做就好了。可是现实中有很多问题的不同解决办法之间总是各有优缺点，有的方案符合产品长远目标，但是开发量太大不能及时交付；有的方案能让产品很快推出，但是会留下技术债让后来的维护和添加新功能更麻烦。如何在不同的选项之间权衡就成了每个架构师时时刻刻需要面对的问题。

架构权衡分析方法Architecture Tradeoff Analysis Method (ATAM)就是一种帮我们做权衡的方法。在ATAM的流程中所有的利益相关方包括需求方，领域专家，项目管理者，架构师，开发，测试都齐聚一堂，我们一起明确：

业务功能需求
非功能需求
约束
架构目标和原则
质量属性效用树

在这个基础上，大家一起充分讨论可选的架构方案的优缺点，特别要看是不是符合我们的架构目标和原则，从而得出最合适当前情况的方案。ATAM的流程是相对繁琐和耗时的，往往只需要针对重大决定才需要这么做。但是这个思维方法我觉得是每个架构师都应该掌握的，针对其它或大或小的问题，都可以在自己的脑子里走一遍，让自己带上不同人的帽子，找到最适合当前的解决方案。

除了要权衡不同的解决方案，还需要权衡不同事情的优先级，随着负责的事情越来越多，区分轻重缓急也越来越重要。有些决定必须马上做，晚了就会让团队干等着，或者给团队带来将来的返工。有些决定可以以后等掌握了更多的信息再做，随着不确定性越来越小，我们做出的决定也会更加明智。有些决定必须自己做，有些决定可以委托给别人做，这就引出了下面这条 委托放权的能力。

三、委托放权的能力

在我看来委托放权的能力有两个部分：

一个是从优先级或者重要性出发，关注对你来说最重要的决定。比如架构师通常更关心模块或者服务之间的关系，模块或者服务内部的设计细节就可以委托给别人来做。如果我们的产品是对可靠性要求很高，对性能没有什么要求，我们就可以专注于影响可靠性方面的设计决定，把影响性能的决定委托给别人来做。同样的，如果你关注的是几个产品串成一整套完整的解决方案，那你就可以专注于产品之间的关系，每个产品内部委托给每个产品的架构师来决定。
另一个是要知道自己的能力圈，在硬实力的部分我们说过，我们的能力会是一个T型结构，这就意味着很多方面我不是专家。要勇于承认自己在很多领域的不足，在这些领域如果有技术专家的话要大胆的求助别人，不要强行做决定。架构师的目标是做出好的产品，带出好的团队，不是证明自己是这个屋子里能力最聪明的人。

无论是自己做决定，还是把这个做决定的权利委托给了别人，都意味着架构师要有 做决定的能力。

四、做决定的能力

架构师需要做很多的决定，需要给出很多的答案。在业务需求方会问架构师这个需求可不可行、容不容易，项目经理会问架构师这个版本需要多少工作量，开发会问架构师这两个解决方案哪个更好，测试会问架构师这次改动会影响哪些方面，需要做哪些回归测试，等等等等。

这里面很多问题随着经验的增长会越来越容易回答，但是也有些问题随着经验的增长反而会越来越难回答，我自己的感觉是和上面提到的架构师需要具备的 权衡的能力很相关。正是因为架构师做了很多的权衡，所以更明白很多决定，很多答案都不是非黑即白的。架构师当然可以尽可能多的收集信息，就像上面权衡的能力那部分提到的，做一个最合适的决定，但是往往我们需要在没有完全准备好的时候就给出答案，做出决定。这个时候，架构师作为团队的技术负责人，要勇于拍板，要坚定自信的做出决定，当然做出错误决定的时候也要勇于承担责任。

架构师在很多时候和开发人员、测试人员是没有上下级关系的，和项目经理、业务需求方更没有上下级关系，同样的，和其它需要配合的部门也没有上下级的关系。但是架构师做出的决定，或者架构师建议的方案却需要很多人采纳、接受，这就是下一个架构师需要具备的软能力—— 说服别人的能力。

五、说服别人的能力

培养自己的说服能力，我觉得可以从下面四个方面入手。

首先是让自己成为一个值得信任的人，让别人喜欢听从你的建议（至少在技术这个方面）。这个没有什么捷径，就是要珍惜自己的羽毛，尽量让自己做的每个决定都是有理有据，都是在当时情况下做出的最好的决定。很多时候有很多非技术的因素会对最终的决定有影响，架构师最好在给别人讲述的时候把技术因素和非技术因素区分清楚。有时候一些所谓的办公室政治也在所难免，但是架构师的底线我觉得是在所有的讨论中关于技术的部分一定是要合理的，一旦这个底线被越过的话，别人会对你的技术能力产生怀疑，这个时候就丧失了信任的基础。
其次要有求同存异、追求双赢的思维方式。自己的主张中一定要有优先级的概念，要明确哪些是必须争取的，哪些是可以让步的。在和别人的谈判中要抓大放小，确保自己的主要目标要达成。
第三是寻找盟友，要建立自己的人脉。这个并不是说要搞小团体，拉帮结派，而是你需要在工作中有一些愿意帮你、替你说话的盟友们。建立人脉和第一条有点关系，首先基础就是别人觉得你是一个值得信任的人。另外不要吝啬自己的帮助，多帮帮别人以后都会有回报的。盟友不止是技术方面的，也需要在管理层和业务方找到自己的盟友。
第四是要有同理心，站在别人的角度思考问题。人们常说想要说服别人需要的是诉诸利益，而非诉诸理性。很多时候告诉别人这么做给他们带来的好处远比讲大段大段的道理更有用。这也就是英文里常说的WIIFM（What’s in it for me）。另外一个方面，如果你的方案给别人带来了一些损失，你也要站在对方的角度，尽量想办法让这个损失最小化，或者和别人分担这个损失，再或者从别的地方给与一些补偿。

如何让自己更有同理心，就引出了下面一个能力—— 理解别人的能力。

六、理解别人的能力

理解别人的能力包含三个层面，第一个层面就是简单的 听明白别人说的话。这个要求看似简单，其实很难。随着自己知识和经验的累积，在很多时候我们和别人沟通的时候，我们是可以大概猜到别人要表达的意思的，在这种情况下更要有意识的控制自己，不要轻易的去打断别人，或者先入为主的认为自己已经知道了别人要说什么。沟通最重要的目的就是获取信息、达成共识，获取信息靠的就是倾听，达成共识靠的就是上一条的说服。我们可以在认真听完别人说什么之后，再去用自己的语言去总结复述别人说过的话，来确保自己理解的和别人想表达的是一样的。倾听是一个宽泛的词，它真实的意思包含听别人说了什么，也包含读别人写给你的邮件和消息，还包含在沟通时看别人的表情和动作等身体语言。判断自己有没有做好这条听明白别人说的话，最好的方式是看看自己在别人说完之后能不能问出一针见血、直击要害的好问题。还有一个万能问题也能帮助我们听明白别人说的话，那就是“ 为什么”。最常见的应用场景是当我们和业务需求方沟通时，他们经常会说需要一个功能，这个很有可能不是一个需求，而是一个解决方案，多问一句“用户为什么需要这个需求？”或者“有了这个需求能给用户带来什么好处”能更好的帮助我们裂解真正的需求是什么，往往我们就能一起头脑风暴出一个更好的解决方案。

理解别人的能力的第二个层面是 看明白别人做的事。每个人做事情都有背后的动机，看明白别人做的事的目的是根据别人的行为来更好的理解别人关注的点，从而理解别人的优先级，这样我们才能预判别人在什么场景下会做出什么样的行为，更重要的是如何通过改变会影响别人的动机的情况从而让别人做出我们希望做的事情。特别是当别人做了一些你看起来很反常的事情，或者说了一些很反常的话的时候，更要注意，这多半意味着你之前对别人的理解不到位，你忽略了一些很重要的东西，而这些东西对别人有很大的影响。

理解别人的第三个层面是 想明白别人的想法，或者说从别人的角度来思考问题。所谓的“己所不欲，勿施于人”就是说你不想要别人怎么对你，就别怎么对别人。同样的还有“己所欲之，施之于人”，就是说想要别人怎么对你，就怎么对待别人。只有真正的想明白了别人的想法，才能更好的知道在说服别人的时候，哪些东西是别人最在意的，是不能妥协的，是你需要调整你的方案来一起保护的，或者需要在你的方案里面给与补偿的。

理解别人并不是只是为了说服别人，也为了让别人更好的帮助你解决问题。举个简单的例子，假如你调用了其他团队的一个服务，这个服务在某些情况下返回值不是你所期待的，你怎么跟这个团队沟通呢？第一种做法是你说“你们提供的服务有问题，有bug，你们代码是怎么写的？导致我们的服务都挂掉了，赶紧在A时间之前修好”，第二种做法是“我们发现在X场景下你们服务返回的值是Y，我们觉得返回Z更合适。我们做了A的调试方法，得到了B的调试结果。因为这个问题导致我的服务中断了，希望你们在C时间之前能帮忙修好，如果有困难请告诉我们，我们一起想办法，如果需要我们协助的我们一定全力以赴”。哪种做法更有利于问题的解决呢？

我们经常会看到有的人很容易获得别人的帮助，有的人却到处碰壁。除了上面 说服别人的能力里在寻找盟友里提到的要互帮互助建立人脉之外，更重要的是你有没有把别人帮你的门槛很低。大部分人都是乐于助人的，因为帮到了别人会让自己开心。同样的大部分的人都是好为人师的，因为教了会让自己觉得有成就感。选择不施予援手大部分仅仅是因为提供帮助太麻烦，如果你在请求帮助时把自己的诉求说的很明白，把需要别人做的事情也说的很明白，让别人不怎么费劲就能给你提供帮助，这样的话很多时候别人时愿意帮你的。

怎么把自己的诉求说明白，怎么把对别人的要求说明白，就需要下面这条 把问题说清楚的能力。

七、把问题说清楚的能力

我们平时要讨论的技术问题大部分都是比较复杂的，怎么把复杂问题讲清楚就是一项重要的能力，只有首先把问题讲清楚了，才能找到解决的办法。

把问题讲清楚的第一步是自己把问题想清楚了，就像橡皮鸭调试中所说的，很多情况下，只要我们能把问题描述清楚，答案自然而然的就浮现出来了。很多情况下我们没有想出来解决办法，只是因为我们没有想清楚问题本身。

做好把问题想清楚的第一步，接下来就是怎么把这个自己想清楚的问题再明白无误的传递给别人。把问题给别人说清楚一定要因人而异，要充分理解谈话的对象，知道他们 关注的点是什么，然后针对这个关注的点重新抽象问题，重点突出，无关的部分简化。比如如果要和领导层说问题完全没必要谈到技术细节，和开发测试说问题完全没必要谈到项目预算。另外还需要尽量 使用听众的语言，基于已有的共识，比如和业务需求方讨论时尽量避免软件术语，尽量使用他们熟悉的领域语言。

把问题说清楚有一些技巧，比如先说结论，再说论据。先说重点，再说补充。还有一定要简洁、简洁、简洁。

和不同的人用不同的语音和模型和来交流，就意味架构师需要下面这条 从多个层面上抽象的能力。

八、从多个层面上抽象的能力

从多个层面进行抽象是说对同一件事情，要有不同维度，不同粒度的抽象。或者用软件的话说就是针对同一个Model，要有不同的View。举个例子来说，项目的系统架构需要有不同的视图（View），就算是同一个试图，也需要有不同的细节粒度。换句话说，架构师在准备系统架构的时候，需要有一个完备的架构作为基础（Model），然后可以提取出不同的试图来服务不同的应用场景。就算是同一个试图，还需要有类似于放大和缩小按钮一样的功能，可以站远了看宏观或者走进了看微观。比如同样的事情，再给CEO做汇报和给别的架构师做分享，当然需要不同的细节力度。架构师除了要在写代码的时候会抽象，也需要在写文档时会抽象。考虑到架构师在很多时候的沟通工具是幻灯片（PowerPoint），这当然就意味着架构师需要有写文档和画图表的能力。

不同的文档和图表用在不同的场合，给不同的对象传递他们最关注的信息。这也就引出了下面一条 协调各方的能力。

九、协调各方的能力

架构师在很多时候可以起到粘合剂的作用，能够有效的协调各方实现我们的目标。

在团队内部，架构师基于自己懂技术、懂业务、懂项目管理这三个硬实力来协调项目经理、业务需求方和开发团队。对于项目经理来说，架构师帮助项目经理理解和管理项目的技术风险，并且一起找出最有利于团队的发展路线。对业务需求方来说，架构师帮助业务需求方更好的找到真正的业务需求，衡量各种解决方案中哪个选项最能给用户带来价值。对于开发团队来说，架构师帮助他们理解业务需求，并且把有利于开发团队长远利益的非功能需求，比如重构、消除技术债等反馈给项目经理和业务需求方，安排在项目的开发计划中，保证团队在实现功能需求的同时，有足够的时间来做对于团队来说最有利的事情。

在不同的团队之间，架构师通过架构师之间的网络，充分实现技术层面的沟通和合作。架构师之间的交流更简单和直接，很多时候可以绕开所谓的办公室政治和各个团队之间目标不一致的情况，从技术这个争议相对较小而且更容易达成共识的独特角度出发，实现各个团队更好的合作。

总结

上面就是我觉得成为一个好的架构师需要具备的三硬九软，以后有机会再针对里面的每一条展开聊聊。

参考文章：

本文在总结自己的思考的同时参考了下面这些文章。

Path to a Software Architect
What makes a good software architect? What are the defining characteristics of an architect, and differences between an architect and an engineering manager?
So, you want to be an architect?
5 Personality Traits of a Great Software Architect
Two key traits of an Effective Software Architect and how to maintain them
16 things to practice to become a better software architect
Software Architect Role, Skills, and Impact on Product Success

从 TikTok“重 QA 轻测试”来看中美软件开发之间的差异

Wed, 02 Mar 2022 13:18:41 CST

[cp]看到InfoQ推送的一篇文章《从 TikTok“重 QA 轻测试”来看中美软件开发之间的差异》http://t.cn/A6671nbJ ，讲了一位曾在一家在美中企（TikTok）工作了一年多的华裔（之前任职于 Snapchat 和 Facebook），在 YouTube 上发布了一个视频“5 crazy things about working for Tiktok(why we quit our PM and engineering jobs)”，从五个方面总结了他从中国企业里学到的经验。

感觉整个一个高级黑啊，看起来像夸实际上是在吐槽！完全就是靠堆人力成本来弥补软件工程上的不足。

原始视频链接：http://t.cn/A6671nbi

摘录文中翻译如下：

第一点：很多西方企业都会写单元测试，每个人都知道这是非常基本的事情。但这里的中国工程师们不需要编写单元测试！每项代码提交都指望 QA 部门的手动测试，团队在提交之前手动测试每个 code commit 提交。

你可能认为这完全是疯了，为什么不写单元测试？利用 QA 进行测试，实际上是希望工程师们关注于功能，并快速启动，写测试就完全交给了 QA。

而且让人震惊的另一件事情是，代码合并请求也不需要批准。在一个十万人的企业里（这不是一个小型初创企业），没有单元测试也没有代码审查，仅依赖于 QA，但这却是“有效”的方式！也没有发生过重大宕机事件。

中国企业的产品团队往往人员更多，也更倾向于依靠运营团队推动业务增长；这一点与美国被动加数据驱动的增长思路不太一样。我注意到中美科技企业之间的主要差异，是中国企业对人力的依赖性更高，这个优势也是中国企业得以迅速占领新市场的核心原因。

第二点：在中国企业，很少见到一对一式的会议，因为扩展性太差了。各个团队内部很少进一步细分，所以需要跟更多同事开展交互。经常见到那种典型的、自上而下的会议，一开就是 90 多分钟，期间 60 多人同时参会。大多数情况下，都是 1 个人在前面讲、剩下的人在翻看会议资料。很少有欧美公司里常见的那种畅谈会或者讨论会。

第三点：为了防止猎头挖人，这里并不公布明确的组织结构体系。组织结构高度扁平，某些工程经理需要接手 200 多份绩效评估报告（未经划分！），有些报告提交者甚至不知道自己的顶头上司长什么样子。

第四点：从流程与执行上来说，中国企业里的屁事不多，大家都在低头忙工作，很少会去传闲话或者搞道德评判。另一方面，中国企业在流程设计上还不够成熟。文档与改进团队的同事们无论做得多好，但很难得到激励。也没人审查工程师们的代码。

第五点：从工作与生活的平衡上来说，美国团队不需要 996，但要求必须适应中国时区。这真挺难的，也是造成人员流失的主要原因，我接触过的所有 PM 都在工作一年后离职了。

中国的 STEM（科学、技术、工程与数学）专业博士是美国的四倍，但技术岗位反而比美国更少，所以这里的竞争烈度要高于美国，大家把这种状况称为“内卷”。中国的同事们很怕自己失去技术优势并被社会的发展甩在身后，所以他们才能迸发出巨大的工作能量。 http://t.cn/A6671D2n[/cp]

2022年软件开发的22个趋势

Mon, 07 Feb 2022 23:52:00 CST

本文来自微信公众号：小智的互联网观察（ID：hear_and_tell），作者：唐小智，原文标题：《22个2022年软件开发的趋势预测及其解读》，头图来自：unsplash

Md Kamaruzzaman 是 Medium 的一位科技博客作者，更新频率比我强不了多少，但他对软件开发行业的认识比我要强太多，毕竟专业出身的差距摆在这儿。Kamaruzzaman 个人介绍是一位解决方案架构师，同时也是一位科技作者、全栈开发，专注在云和大数据方向，base 德国。

2019 年底，我策划翻译过他对 2020 年软件开发的趋势预测（《 20 个 2020 年软件开发趋势预测》），反响非常好，好到出乎我的意料。坦白说过去几年的开发者社区工作经历让我深刻地认识到，愿意抬头看天的人永远是少数，愿意每年去分析一下软件开发行业的过去现在和未来的人就更少了，毕竟“墨菲定律”的存在就意味着永远有人的预测会翻车，贻笑大方，远不如报道几篇某某云宕机了，某某研发删库了的八卦新闻性价比来得高。

很有意思的一个事情是，研发同学往往并不直接与客户打交道，多数市场动向和认知观察也往往来自于市场部门或开发者关系，但技术发展的趋势往往却与商业化直接挂钩，这就导致了一个很有意思的现象，即——运营/市场拿着研发一半的工资，却还要时刻掌握市场动向，行业脉搏，用工程师能听懂的语言反哺给研发，最终保证技术发展、产品迭代的路线不至于出现大的纰漏。

这对于做开发者社区的同学来说，是先天的弊病和必须的要求，也是开发者运营同学实现个人品牌能力和增值的一大出路。所以，其实各个行业都类似，愿意保持思考，持续学习的人，总是可以跑赢很多人，研发同理。

废话不多说，切入今天的正题。

1. 集中式基础设施：云优先是新的规范

同往年一样，第一条预测依旧跟云有关，今年在基础设施这个关键词前面多出了一个 集中式（Centralized）的前缀，这跟当前云计算行业的下沉还是有关系的，如果关注互联网行业比较多的人，可能会觉得分布式云是现在的发展趋势，但其实对于正在数字化转型的非互联网行业而言，集中式的基础设施仍旧是第一选择。

2022 年，仍旧会是公有云快速发展的一年，Gartner 预测 2022 年公有云的收入将增长 16%，在互联网以外的各个行业，金融、政务、出行、工业、民生等多个行业，公有云都会得到有效的利用。所以如果你是非互联网企业的决策者或从业者，现在开始认真关注云计算还来得及。

2. 去中心化基础设施：边缘的云

边缘计算开始被广泛关注，大概也就是最近两年的事情，我看了一下 2019 年做的那篇趋势预测里，其实没有写边缘计算，但 2021 年的版本里已经有了。跟公有云希望将存储、计算能力和 AI/ML 集中在一个中心位置（可用区域）的特点不同，边缘计算本身是一种去中心化的方式，它希望将存储、计算能力和 AI/ML 部署在靠近用户的地方。低延迟场景（游戏）、低网络带宽（离岸站点）、无网络、监管要求、实时用例（联网车辆）、智能设备（物联网）这些都是需要边缘计算的场景。

再加上 5G 和 Web 3 等关键技术的兴起，边缘计算在 2022 及以后得到广泛采用是很合理的预判。事实上最近两年各大云厂商已经在开始有意识地推边缘计算的能力和产品了，我印象中国内几大云厂商都有相关的案例，比如我之前采访过的华为云的 KubeEdge。

Kamaruzzaman 提到了一项比较关键的动议——“ State of the Edge”，旨在标准化边缘计算技术。“标准化”这个词是我特别敏感的一个点，因为从商业化的角度看，在没有实现事实标准之前，商业化的拓展往往是杂乱无序或者说没有核心优势的，而形成事实上或人为认定的标准以后，商业化的动向才能更为明朗。毕竟三流企业做产品，一流企业做标准。

3. 公有云：多云将获得更多的动力

阻碍企业上云的一大绊脚石，就是厂商锁定的问题。毕竟云厂商在商业信誉这块上，总是或多或少存在一些黑历史，要么硬盘坏了，要么剽合作伙伴方案，要么抄开源项目代码。你把企业安身立命的核心资产、数据都放在某一家云上，且不说安全的问题，以后要想迁移都是个麻烦。

所以多云、混合云的发展趋势是实实在在肉眼可见的，Kamaruzzaman 提到了很多致力于提供云服务中立性的 API 服务，比如 MinIO（兼容 S3）、Aviatrix（云原生网络）、Volterra（分布式云服务）、LightOS（云原生存储）等。

还有一点比较有意思的是，Google 正在致力于将他们的流行服务，比如 Big Query 引入到其公有云竞争对手 AWS、Azure 里，但这种现象在国内的云计算行业是否有类似案例或者说未来会不会有类似案例，我个人表示怀疑……

4. 容器：K8s 将成为基础，而 Docker 将会反弹

如果要对现代 IT 产业的关键技术做个排名，容器毫无疑问将占据一席之地。在容器化技术的普及化中，K8s 发挥了巨大的作用。背靠大厂（Google）、足够努力、精心设计、快速迭代，才有了今天成为事实标准的 K8s。

但另一方面，随着 K8s 技术的成熟，未来关于 K8s 本身的吸引力会持续减少，这有点类似于跨越鸿沟理论中的技术采用生命周期，K8s 我认为已经到了晚期大众这个阶段。所以 Kamaruzzaman 表示，K8s 已经成为现代软件开发的引擎，但也由于其本身的成熟度而导致进展缓慢。从这个角度看，有点类似于 Java。

Docker 是另一个在容器化历史进程中发挥了关键作用的技术，不幸的是，即便在全盛时期，Docker 也没有找到商业化的终南捷径，加上公司一系列的骚操作，在与 K8s 的正面对决中败下阵来。

2022 年起，Docker 宣布推出新的订阅模式，继续做着商业化的艰难探索。坦白说，这个小标题预测的结论并非定论，更多是 Kamaruzzaman 基于 Docker 的历史功绩提出的美好祝愿，我其实也一样。Docker 是我对开源行业产生浓厚兴趣的开始，希望它能有一个好的未来。

延展阅读：《 Docker 麻烦大了》

5. 网络安全：每个人都会认真对待安全

对初创公司或者中型公司来说，网络安全就像“房间里的大象”，他们可以看到网络安全的需求，却没有足够的资源去实现他。这其实也是公有云能迅速落地下沉的一大原因，初创企业不需要自己去搭建底层的基础设施，也省去了网络安全的防护，只要部署在公有云上就行，其他的事交给云厂商。

可当云厂商遭到网络攻击，或者出现故障时，受到影响的就绝不只是一家公司而已。事实上，2021 年曝出来的云厂商高危漏洞也不在少数，2022 年公有云厂商和 Linux 都要在安全方面更努力地工作。

除了云安全，另一个常见的网络安全来源于开源软件。之前奇安信有过相关数据报告，90%的开源软件存在安全漏洞，这对于在开源软件基础上构建起来的互联网本身就是个令人不寒而栗的问题。幸运的是，高危漏洞的利用没有那么容易。不幸的是，很多世界流行的开源软件，背后的维护者甚至只有两三个人，比如 2021 年最受关注的 log4j 漏洞，影响了全世界近一半的 IT 公司。

我们需要思考一个问题，为什么世界流行的开源项目却得不到应有的收益？为众人抱薪者，不可使其冻毙于风雪。

6. 区块链：加密货币之外的生活终于开始了

区块链经常与加密货币联系在一起，每次有人被加密货币嘎了腰子，就有人开始痛骂区块链技术。但从技术上来讲，加密货币只是区块链技术的一个实现方式，却并非区块链的全部或唯一用例。

2021 年区块链一个非常流行的新用例是 NFT（Non-Fungible Tokens），之前勇士队球星库里花了 18 万美元买了一张 NFT 的头像就火出了圈。虽然，我也不懂这玩意儿贵在哪了……

NFT 目前更多用在数字艺术方面，但显然可以期待它未来的使用场景。从这个点延伸出去可以看到，区块链技术正在越来越为人所正视，注意是正视。IDC 预测 2022 年区块链技术的解决方案增长将达到 75%，考虑到目前该项技术的普及程度，我觉得这个数字不算盲目乐观。

区块链一个为人所诟病的点在于能源消耗，在国内双碳政策的前提下，区块链要想获得长远发展，必然还是需要做出一些改变的，像以太坊那样，在 2022 年由能源密集型的“proof of work”模型转向绿色的“proof of stake”模型。

7. 机器学习：AutoML 和无代码人工智能将使机器学习民主化

我之前策划“稀土开发者大会”的时候，用过一句文案叫“机器都在学习，你凭什么例外”。这个点说的就是机器学习，但从实际的行业发展来看，机器学习的应用规模还是受到不小的制约，最大的原因是——搞机器学习的专家太少了。第二个原因是——大多数公司不需要完全的机器学习，有限的使用就够了。

AutoML 就是在有限情况下实现机器学习使用的一种方式。某种意义上，它就相当于低代码/无代码，不同之处在于，低代码/无代码是降低开发的门槛，而 AutoML 是降低机器学习的使用门槛。

8. 人工智能：狭义人工智能将被广泛采用

我最近在看阿西莫夫的科幻系列，里面提到过的“机器人三大准则”、由机器人协助建立的行星文明等等故事，讲述的就是人工智能的终极目标之一——让 AI 可以和人一样聪明，甚至更聪明。但从 AI 发展的 60 多年历程里，我们离这个目标还差得远。

跟机器学习一样，深度学习在过去十年间获得了大量采用和快速增长，预计在未来仍将如此。人工智能发展的终极目标在肉眼可见的当前触不可及，但让人工智能代理在特定领域协助/增强人类还是问题不大的。

9. 深度学习库：TensorFlow 将继续统治

深度学习的轮子有很多，但你基本上可以只看这两个： Google 的 TensorFlow，Meta 的 PyTorch。

TensorFlow 在其 2.0 版本中进行了自我更新，并引入了动态图形、Python 友好和许多其他变化。它还提供了 Tensorflow.js 以在浏览器中使用 AI 库。其另一个创新是 Tensorflow Lite，它提供了在移动和 Web 上部署 Tensorflow 的功能。Tensorflow 还发布了 Tensorflow Extended（TFX），这是一个用于部署生产 ML 管道的端到端平台。

PyTorch 是另一个主要的人工智能库，它引入了动态图形和 Python，对开发人员也更友好。它还发布了 PyTorch Mobile，支持在 Android/iOS 设备上使用 PyTorch。它通过 PyTorch Profiler 为开发人员提供了更多的友好性来调试大型 AI 模型。

从 Stack Overflow 的调查数据来看，TensorFlow 继续保持统治地位似乎并没有什么悬念。

10. 数据库：多模型、多用途数据库正在兴起

过去几年间，数据库领域的一个趋势就是用一种特定的数据库去匹配特定的用例，比如：

RDBMS：用于结构化数据的事物
Wide-Column Database：用于低延迟，分布式数据库
Key-Value Store：用于分布式缓存
Graph Database：用于极端关系数据
Document Database：用于具有半结构化数据的事物
Distributed SQL：用于具有事务保证的低延迟，分布式数据库
OLAP Database：用于数据仓库和数据分析

这种方法的一个缺点是，我们经常需要为一个应用程序使用多个数据库。现在有一个新的趋势，即每个数据库将提供一个以上的模型并服务于一个以上的用例。PostgreSQL（Multi-Model）、Azure CosmosDB（Multi-Model, Multi-purpose）、SingleStore（OLAP 和 OLTP）是这些数据库的先驱。

11. 数据密集型计算：Spark VS 公有云

Kamaruzzaman 介绍道，Apache Spark 几乎已经取代 Hadoop 生态系统成为默认的数据密集型计算框架。Spark 还使用相同的 API 提供接近实时的流处理。

另一个获得很多关注的开源框架是 Apache Beam，其提供了一个统一的编程模型来定义和执行数据处理管道：批处理和流处理。这个背后的身影少不了 GCP、Azure 和 AWS。

所以如果你不想用云，或许只有 Spark 一个选择。

12. 实时流计算：Flink VS 公有云

这个点的意思跟上一条颇为类似，简单来说就是，实时流计算这里，除了 Flink 啥都不推荐。即便要在公有云上用，也建议用 Flink，感觉无脑上就行了。话说回来，确实在这个领域里我目前也没见过有能跟 Flink 掰掰手腕的轮子。

13. DevOps：现代 DevOps 的智能可观测性

几年前，可观测性只对大型企业至关重要。然而，伴随着云本地开发和微服务架构的迅速崛起，可观测性对整个现代软件开发都至关重要。除了传统的日志记录、监控、跟踪，还需要 K8s 集群的遥测、拓扑数据等等。

其实 DevOps 这种理念一直处在持续的发展中，当它跟 AI 结合时就变成了 AIOps，当它强调安全时，就有了 DevSecOps，轮子的实现有各种形态，归根结底还是看需求是什么。

14. 快速应用开发：低代码/无代码（LCNC）将继续蓬勃发展

低代码/无代码（Low Code/No Code，简称 LCNC）旨在降低开发 Web/移动应用的障碍，而无需开发人员（或少量开发人员）。在未来的几年里，我们仍然需要开发人员来开发应用程序。但也有很多用例表明，低代码/无代码框架/工具确实可以显著加快应用程序开发。

整个 2021 年称之为低代码元年都不为过，这一年光是我见过的低代码创业公司就不下三五家，一场关于低代码是否业界毒瘤的争论更是引爆了行业沸点。预计 2022 年，这些场景下会有更多低代码/无代码的身影：

Web/移动 App 开发
网站和登陆页面
使用对话流的智能聊天机器人
电子商务
机器学习
人工智能（视频、音频、图像）
工作流管理
使用 RPA 的过程自动化

15. 软件架构：面向企业的微服务和微前端

目前主流的后端架构有三种选择：单体、微服务和 Serverless，三者各有优势、劣势和适用的场景。对于微服务而言，其是云原生场景下绝佳的架构选择，从企业发展角度来看，不论是上云后的改造，还是云原生的架构设计，都以微服务为首选。

前端领域的程序复杂性往往受到轻视，而微前端的思想内核跟微服务是一样的，都是为了解决复杂性而生，化整为零。因此可以畅想的是，微前端也会是未来前端开发的首选架构模型，另一个好消息是，主流的 JS 框架都支持微前端。

16. 软件开发：人工智能将协助开发人员和 QA

软件开发本身很有意思的一个地方在于，开发人员不喜欢做那些乏味的、可预测的、重复的脏活累活，所以各种轮子应运而生。研发们享受的是创作解决问题的解决方案，而非享受问题。人工智能在实现终极目标之前，更多的价值往往就体现在这些地方上，比如使用 GPT-3 和 NLP 库自动地完成这些任务。

另外就是去年刚推出的一些自动生成代码的工具，比如 GitHub 的 Copilot。很多人喜欢玩梗说，AI 已经可以自己写代码，自己 Debug 了，程序员还有人要吗？但实际上目前 AI 的能力仍旧是狭义层面的，但如果你只能、只会做脏活累活，那你确实比较危险，不是吗？

17. 编程语言（主流）：Python 将引领潮流

我刚入行那会儿，Python 还没今天这么火，那个时候大家讨论的是 Java 和 C 语言，甚至 Go 语言在中国的热度感觉都不比 Python 差。可一瞬之间，Python 就在 TIOBE 编程语言排行榜上干到了第一名：

Python 具有简洁、解释性、动态、门槛低等特性（然而我却没学会，从入门到放弃），这些在 Python 之禅里都有很直观的体现，更关键的是，Python 并不仅仅局限在软件开发行业里，很多做数据、图表的行业同样可以用 Python 实现很多工作。加上数据科学的火热，Python 的火爆不难理解。2021 年 Python 的登顶不会是昙花一现，悬念或许在于，以后谁会把它顶下来？我个人期待 Rust。

18. 编程语言（企业）：Java 反击

主流的企业级编程语言，很长一段时间里代名词就是 Java。Java 的语言设计，JVM 的强大，共同构筑了 Java 生态。但在云原生兴起以来，Java 其实受到了非常大的挑战。我年前发过一条朋友圈专门聊过这个话题：

目前看有两个技术趋势会对 Java 造成比较大的影响，一个是云原生，一个是 Serverless。造成影响的原因跟 Java 语言的特性有关，这门语言设计就是为了大型应用复杂场景，而云，尤其是 Serverless，更加适合轻量化、业务逻辑简单的应用。话说回来，其实制约云原生和 Serverless 发展的，也恰恰是在大型应用复杂场景下的管理问题、安全问题。

一个好消息是： Java 社区一直在持续地迭代创新，保证 Java 的生命力。比如 GraalVM 等现代化的特性，在 Java 近几年保持周期发布的当下，凭借现代化特性的更新和严格且无与伦比的向后兼容性，你可以不用再问 Java 老矣，尚能饭否。而是，接着奏乐，接着舞！

19. 客户端 Web 框架：面向企业的 React 和 Angular

前端三大框架早已是耳熟能详的存在：来自 Meta 的 React，来自 Google 的 Angular 和来自尤雨溪的 Vue。Kamaruzzaman 给出 React 和 Angular 会在企业中得到更多重用，而非 Vue 的原因是：前两者背靠两大企业，而 Vue 过于依赖尤雨溪，且提到了 Vue 的安全考虑。

我不知道这个安全考虑指的是软件方面的安全，还是地缘方面的安全，这里不做评价。但我想提的是，如果 Vue 在过于依赖尤雨溪的情况下，仍旧做到了如此流行，岂非更加说明 Vue 的牛逼所在？你觉得呢？

20. 服务器端框架（Java）：用于微服务和无服务器应用程序的本地框架

Spring MVC/Spring Boot 是 Java 里最主要的服务器端框架，它遇到的问题跟 Java 遇到的问题是伴生问题，因为 Java 受到了云原生趋势的挑战，导致了它的问题。在 Redhat 推出 Quarkus 后，云原生开发的首选框架易主，因为后者使用了 GraalVM 而非传统的 OpenJDK。终于，Spring 也声明了将发布 Spring Native，同样使用 GraalVM 进行云原生开发。

2022 年如果开发云原生 Java 应用程序，可以考虑使用 Java 原生框架。如果场景仍旧是单体 Java 应用开发，继续使用传统框架亦无不可。

21. 应用开发：更灵活的原生应用

移动应用开发一直是个庞大的市场，并且仍将持续膨胀下去。目前主流的移动应用开发有四种模式：原生开发、跨平台开发、混合开发和云开发。

原生开发和跨平台开发是应用最广的开发模式，前者提供了最大的灵活性，后者提供了“Write once，Run everywhere”的诱人可能。

去年写过一篇苹果发布会的文章苹果：没想到吧，我自己做了“小程序”，里面借着苹果生态分析了一下原生开发的发展，重点在于其软硬件的协同。Kamaruzzaman 预测 2022 年原生开发将占据主流，重点在于跨平台开发不如原生灵活。未来如何，且走且看。

22. API 技术：REST、gRPC 和 GraphQL 将共存

现代软件开发通常是 API 驱动的开发，API 轮子可以说是多如牛毛，但知名度最高的也就这三个了：REST、gRPC 和 GraphQL。

这三个主流 API 技术，一个最古老，同时也是最成熟、最广泛使用（REST）；一个由 Google 创建，在服务和服务通信方面更快更高效（gRPC）；一个由 Meta 开发，以为特定的用例定义数据结构的形状，并在一次访问中获取所有数据。

这简直是完美体现软件开发没有银弹一词的场景，各有各的擅长，也各有各的弊病，企业按需使用，每个轮子都有前景。我们都有光明的未来！

原文链接：

https://md-kamaruzzaman.medium.com/?p=fcc82c263788

本文来自微信公众号：小智的互联网观察（ID：hear_and_tell），作者：唐小智

我国软件业运行态势良好

Fri, 28 Jan 2022 06:38:05 CST

　　本报北京1月27日电（记者韩鑫）工业和信息化部日前公布2021年我国软件和信息技术服务业运行情况。数据显示，2021年，我国软件业运行态势良好，全国规模以上企业超过4万家，累计完成软件业务收入94994亿元，同比增长17.7%，两年复合增长率为15.5%。

　　业务收入保持较快增长的同时，盈利能力也在稳步提升。2021年，软件业利润总额11875亿元，同比增长7.6%，两年复合增长率为7.7%；主营业务利润率提高0.1个百分点达9.2%。

　　“软件业稳步增长得益于数字经济的快速发展。”赛迪研究院信软所信息技术研究室主任许亚倩分析，软件是数字经济发展的基础，也是信息技术与产业融合的纽带。一方面，疫情带来的宅经济、线上经济以及信息化发展进入快车道，拉动软件业需求不断增长，另一方面，制造业数字化转型步伐加快，重点领域关键工序数控化率、数字化研发设计工具普及率分别提升到55%和74.4%，产业数字化推进也驱动了软件业快速发展。

　　分领域来看，软件产品收入平稳较快增长。2021年，软件产品收入24433亿元，同比增长12.3%，增速较上年同期提高2.2个百分点。其中，工业软件产品实现收入2414亿元，同比增长24.8%，高出全行业水平7.1个百分点。“随着融合应用的日益深入，工业软件将进入快速发展期，有力支撑我国软件产业链升级和制造业转型升级。”许亚倩说。

　　信息技术服务收入增速领先。2021年，信息技术服务收入60312亿元，同比增长20.0%，高出全行业水平2.3个百分点。其中，云服务、大数据等服务增速强势，共实现收入7768亿元，同比增长21.2%，占比较上年同期提高4.6个百分点。信息安全产品和服务收入增长加快。2021年，信息安全产品和服务收入1825亿元，同比增长13.0%，增速较上年同期提高3个百分点。

　　去年11月，工信部印发了《“十四五”软件和信息技术服务业发展规划》，为推动软件产业做大做强提供政策支撑。“政策红利释放下，今年一季度，我国软件业预计将延续去年的良好运行态势，产业规模将稳步增长，产业结构将持续优化，关键领域关键产品供给能力有望进一步加强。”许亚倩说。

　　《人民日报》（ 2022年01月28日 07 版）

通讯软件聊工作导致违法美国SEC、CFTC对摩根大通处罚2亿美元

Sun, 19 Dec 2021 16:17:56 CST

因为放纵高管和员工使用即时通讯软件和私人邮箱讨论工作事宜，周五美国SEC和商品期货交易委员会（CFTC）分别对摩根大通证券开出了合计2亿美元的罚单。

值得一提的是，监管机构对业务数据保管问题进行处罚并不常见，而这次两家监管机构也没有给全球最大银行避免承认错误直接和解的机会。摩根大通将向SEC支付1.25亿美元罚金，而CFTC的罚单价值7500万美元。最新罚单大幅超过SEC在2006年时就类似违法行为对摩根士丹利开出的1500万美元罚单。

根据SEC公告，摩根大通证券承认，至少在2018年1月至2020年11月期间，该机构的员工经常在私人设备上使用即时通讯软件和个人邮箱讨论证券业务问题，而公司并没有依照联邦《证券法》对这些记录进行留存。该机构同时承认，这一违法情况在公司里是非常普遍的行为，包括身负监管责任的董事总经理和其他高级管理人员也经常用私人设备讨论业务。

而在CFTC的调查报告中，显示摩根大通类似行为违反《商品交易法》的历史可以追溯到2015年。

SEC执法部副主任Sanjay Wadhwa周五表示，摩根大通的违法行为阻碍了SEC数宗正在进行的调查，迫使监管部门采取额外的步骤。这一处罚显示违规行为的严重性，公司必须共享投资者保护的责任，而不是造成阻碍。

摩根大通在今年八月曾披露正在接受有关“数据保存问题”的调查。据媒体报道，两大监管机构的行动也对员工产生了影响。摩根大通此前曾指示公司的交易员、银行家、金融顾问，甚至一些支行员工保存好自己个人设备的数据，以备监管调查使用。

监管部门同时也表示类似的调查仍在进行中，更多的金融机构可能被涉及，希望相关公司能够自行汇报存在的违规行为。

Windows Defender是2021年最好的反病毒软件

Fri, 26 Nov 2021 07:10:00 CST

品玩11月26日讯，位于德国的IT安全研究机构AV-TEST发布了针对Windows 10家庭用户的2021年10月最佳反病毒程序评估报告。在这份报告中，该组织评测了来自不同公司的21个不同的反恶意软件程序，测试中还包括微软的Windows Defender。

结果，Windows Defender在这次评估中获得了18分的满分。因此，它获得了"AV-TEST顶级产品"认证，总分高于17.5分的产品才能获得这一称号。

然而，它并不是唯一的顶级产品，其他安全程序，如Avira、AVAST、AVG、Bitdefender、ESET等，也获得了这个认证，除了上述产品以外的测试结果都低于17.5分，因此只能获得"AV-TEST认证"的徽章。

Draw.io 15.8.4 - 免费开源的绘图软件

Wed, 24 Nov 2021 22:15:39 CST

简介

draw.io desktop是一款非常好用的在线流程图绘制工具，允许用户能够快速、自由的创建简单的图标、流程图、网页模版构架图、框架图等，并可通过浏览器Chrome插件就可以快速创建想要的效果图，适用于商务、工程、电气、网络设计、软件设计等诸多领域的专业绘图。

截图

下载

博客下载

复杂性正在杀死软件开发者

Sun, 21 Nov 2021 00:39:12 CST

现代软件系统日益增长的复杂性正在慢慢杀死软件开发人员。你怎样才能重新获得控制权，而又能充分利用这些技术所能提供的优势？

"复杂性是致命的，"Lotus Notes的创建者和微软的老员工Ray Ozzie 在2005年的一份非常有名的内部备忘录中写道。"它在吞噬开发者的生命；它使产品难以规划、构建和测试；它带来了安全挑战；它使用户和管理员感到沮丧。"

如果Ozzie认为当时的情况很复杂，你不禁要问他会如何看待软件开发者在云原生时代所面临的复杂性。

在过去我们通常会构建一个单体架构的应用程序，并把它们部署在一个看得见摸得着的物理服务器上。而现在单体架构应用会被分解成多个微服务，打包成容器，用Kubernetes进行部署，在分布式云环境中托管，这一转变标志着我们的软件的复杂程度有了明显的提升。再加上用户对于丰富功富和软件体验的更高期望，使得软件设计需要更多考虑安全性和弹性：对开发者的要求从未如此之高。

"当你转向如此普遍的微服务环境时，复杂性明显增加，"亚马逊首席技术官Werner Vogels在 2019年的AWS峰会上说。"在所有东西都在一个单体应用中的日子里，它更容易吗？是的，对于某些部分来说肯定是这样。"

或者，正如他的同事，AWS的devops产品营销主管 Emily Freeman在2021年所说，现代软件开发是 "关于熵的研究，它不会变得更简单。"

另一方面，复杂的技术从未像现在这样容易被使用，它们通常是一些单一的API：从基本的库和框架，到图像识别能力，甚至整个支付技术。使用这些已有的技术进行简单地组装，并在上面建立你的业务逻辑。但这真的那么简单吗？

"成为一名软件开发人员从来没有像今天这样困难，"咨询顾问、前Walt Disney企业技术战略总监Nigel Simpson说。"虽然我们已经看到了能力的提升，通过使用应用开发和机器学习的高级框架，使开发人员能够做得更多，但这是有代价的。爆炸式增长的选择和技术发展的速度使开发者很难跟上时代潮流，许多开发者陷入了困境"。

基本与偶然的复杂性

软件机构Simple Thread的联合创始人Justin Etheredge对基本的和偶然的复杂性进行了有益的区分，他告诉InfoWorld："基本的是你所工作的商业领域的复杂性，事实上企业是极其复杂的环境，所以他们试图解决的问题本身就很复杂。另一个领域是偶然的：这是我们的工具以及我们为了解决一个问题而在工具上构建的部分所带来的复杂性。"

云原生时代迎来了比以往任何时候都更多的、潜在的偶然复杂性，这导致了开发者和他们的领导之间的矛盾：前者希望利用他们更多地利用工具，后者则希望他们专注于为客户提供价值。

Etheridge说："鉴于今天对软件开发人员的需求，公司没有手段来推动开发人员走向主要为客户提供价值的思维模式。"让更多的工程师以这种方式思考是一个挑战。

选择的弊端

云计算和开放源码软件运动的普及，使开发人员在构建和运行更多可扩展、有弹性、模块化和可更新的应用程序方面的选择数量以不可阻挡的速度上升。

Humanitec公司的创始人Kaspar von Grünberg在接受InfoWorld采访时说："以前的一切都简单得多，不是因为我们这个行业犯了错，而是因为这些系统的需求急剧增长，我们必须加快交付的速度。

云原生计算基金会（CNCF）维护着一个交互式的图表，其中包含了构成云原生生态系统的近1000种独特服务，其中许多是免费和开源的。此外，三大云计算供应商，亚马逊网络服务、微软Azure和谷歌云都向客户提供约200种独特的服务，涉及计算、存储、数据库、分析、网络、移动、开发工具、管理工具、物联网、安全和企业应用。

"目前，应用程序开发的过程实在是太碎片化了；每个企业架构都是三层的，每个数据库都是关系型的，每个商业应用都是用Java编写并部署到应用服务器的日子已经过去了，"RedMonk的分析师Stephen O'Grady在 2020年的一篇博文中写道。"现如今，基础设施的唯一最具决定性的特征是：没有单一的决定性特征。它是多样化的，甚至是错误的"。

或者，正如前Tumblr首席技术官Marco Arment在2015年写道："由于大多数现代网络开发环境中涉及的工具数量庞大以及它们迅猛的演化速度，Web应用开发从未像今天这样复杂、令人费解。"

云计算供应商在产品开发方面通过采取久经考验的方法（小型化、独立、双比萨团队为响应客户需求而构建服务）得到的结论是：开发人员已经在很大程度上被授予自主选择权，选择如何将这些众多的工具、模块以一种能够提供商业价值的方式组装在一起。

"在云中，你就像糖果店里的孩子"，金融服务企业Two Sigma的平台工程主管Camille Fournier在接受InfoWorld采访时说，"但随着你的成长，并试图让事情能有机结合起来，复杂性绝对会成倍增加。"

这导致许多人质疑这种程度的选择总体来说对普通的软件开发人员是否是一个积极因素。或者，正如O'Grady在 2020年的那篇博文中总结的那样，"在某些情况下，庞大的可用工具清单所固有的复杂性可能成为一种优势，而不是一种麻烦。"

让我们建立一个内部平台

这种日益增长的复杂性导致许多组织采用集中式平台模式，即由内部平台团队负责审核工程师最需要的工具，建立模板，并规划黄金路径，以缓解他们进入生产的旅程，同时也集中了财务管理、安全和治理等功能，以减轻单个开发人员的认知负担。

以音乐流媒体巨头Spotify为例，Spotify产品经理Gary Niemen在 2020年的一篇博文中写道："回顾六年左右的时间，Spotify曾经（现在仍然）致力于以团队的自治来实践敏捷工程的文化。"这带来了所有的优势，也带来了复杂的问题，包括一个碎片化的开发者工具生态系统。也就是，找到如何做某事的唯一方法是问你的同事。"

随着Spotify规模的扩大，它发现原本推动其快速增长的方法实际上已经开始失效。它需要进行整合和简化。"那些被证实有效的或推荐的工具应该很容易被找到。该工具的使用方法应该是清晰的。在使用方面，应该有高质量的用户说明。而且，如果用户碰到问题，在哪里获得支持应该是显而易见的，"Niemen写道。

Humanitec的von Grünberg在 2021年的一篇博文中写道，一个好的内部开发者平台的关键是，在为希望继续完成手头工作的开发者提供自助服务和抽象出最没有价值的任务之间找到平衡，而不使开发者感到受限。

"拥有黄金路径的想法不是为了限制或扼杀工程师，也不是为了设定标准而设定标准。有了黄金路径，团队就不必重新发明轮子，有更少的决定要做，并且可以将他们的生产力和创造力用于更高的目标"，Spotify产品经理Niemen 写道："他们可以重新开始快速行动"。

问题是，"开发人员喜欢重新发明轮子。没有什么比建造一个更好的捕鼠器更让我满意的了，"顾问Simpson说。但在这个世界上，很多答案就在Stack Overflow上，这是否是对开发者时间的最佳利用？

微软开发者部门产品副总裁Amanda Silver说："总会有一些组织试图钳制，而另一些组织则试图赋予开发者权力。核心是开发者速度的概念。我们可以建立系统，让开发者可以写出只有他们能写的代码，而不会分心或有负担地去学习那些对他们来说没有区别的领域。"

旅游技术公司Amadeus成立于1987年，经历了这些技术变革的浪潮，它在大型机上建立了最初的应用程序，在21世纪初转向在开放的Linux平台上构建，现在则主要倾向于用Kubernetes编排调度的容器化应用程序。

Amadeus的基础设施和云计算主管Edouard Hubin告诉InfoWorld："我们的开发者需要能够在我们提供的核心基础上进行开发，所以这个想法是一种平台方法，我们为他们提供能力。新技术为安全性和稳定性带来了更多的复杂性。当你开放这样一个系统时，你希望有稳定性。数据驱动型应用的兴起对我们来说是一个完全不同层次的复杂性....。它带来了一种编写应用程序和建立反馈循环的新方法。所有这些东西都是新的，并带来了复杂性。"

因此，Hubin希望在他能做到的地方隐藏复杂性，要么通过内部团队设计解决方案，要么在有价值的地方使用托管服务。以数据库为例，Amadeus曾经管理自己的MongoDB实例，但现在使用供应商管理的MongoDB Atlas选项。该公司对管理的Kubernetes也采取了类似的观点。

这并不意味着工程师不会推动新的工具进入生态系统。"有时你必须说不，"Hubin说。"最近，我们有一些人试图引入一个新的数据库。他们说得有道理，但如果标准选项不是很好，对公司来说，控制我们使用的数据库的种类[仍然]总体上更有益。"

每个大型组织都有一个广泛的工程师群体，一些人专注于建立有弹性的系统，并以最快的速度向客户提供功能，而另一些人则拼命地想修补最新的技术。两者都有价值，但需要谨慎管理，Two Sigma的Fournier说。s

她说："你需要的是那些兴奋地审视底层原理并了解精通新事物的人--因为我需要有人来管理裸金属的Kubernetes集群--但我也需要那些兴奋地研究新事物、了解它如何工作、确定它在整个公司的有用之处的同时--以及好的伙伴来做原型并确定是否值得投资来解锁一项新事物。"

供应商如何应对复杂性

与云计算软件业务中的许多同行一样，谷歌云的首席开发者倡导者Kelsey Hightower认为，目前提供给开发者的选择水平既是 "礼物，也是诅咒"。

礼物是有一个近乎无限的技术目录可供构建。诅咒是开发人员 "被拉入我们将基础设施泄露给他们的工作流程的情况"。现在，随着许多供应商专注于托管服务和抽象化，钟摆似乎正在向另一个方向摆动。在巨大的分裂之后，我们是否应该进行一次大整合？

"这个职业不仅仅是写代码；那是达到目的的手段，"Hightower说。"也许我们在说，我们已经创造得足够多了，可以暂停创造新的东西，让我们所拥有的东西成熟起来，回到我们各自的角色，即消费技术。也许这就是我们在过去十年中看到的devops和协作运动的圆满结局。"

市场正在通过不断增加的独特的服务、托管选项、框架、类库和平台来应对这种复杂性，以帮助开发者应对其环境的复杂性。

"当然，没有供应商现在或将来能够提供每一个必要的部分。即使是拥有最多样化的应用组合和历史上前所未有的发布节奏的AWS，也不可能满足每一个开发者的需求，也不可能拥有每一个相关的开发者社区，"O'Grady在 2020年的一篇博文中写道。

尽管如此，"有充分的证据表明，我们正在逐渐摆脱将买家和开发者送入迷宫般的过道，让他们承担挑选原件和从头组装的任务。如果云计算的第一个时代是由基元（译者注：包括非常底层的基础设施、类库等）定义的，那么它的日子就要结束了。O'Grady在另一篇文章中写道，"下一个时代可能是由我们在这些基元之上建立的抽象概念来定义的，正如计算行业自成立以来所做的那样。

虽然将这些基元组装成连贯的内部平台已被证明是许多以工程为主导的组织的成功解决办法，但更多的传统企业绝对会寻求他们的供应商来帮助他们缓解这种复杂性。

Kubernetes的创始人之一、现任VMware研发副总裁的Craig McLuckie在接受InfoWorld采访时说："复杂程度不如环境中的不一致性"。他认为自己的角色是寻找方法，"让开发者在处理环境的复杂性增加时生活得更轻松，这是由工具链的碎片化和高度可扩展系统的本质所推动的。"

正如MongoDB布道者Matt Asay最近为InfoWorld所写的那样，"如今云计算的真正故事是谁能最好地整合各种云服务。云将变得更加有趣，准确来说是以一种变得更加无聊的方式实现。

需要机械共鸣

如果我们正坐在大简化的悬崖边上，我们是否失去了作为一个软件开发者的本质？

正如英国传奇赛车手杰基-斯图尔特（Jackie Stewart）所说："你不一定要成为一名工程师才能成为一名赛车手，但你必须有机械共鸣。" 或者说，要成为真正的伟大，你必须对你所操作的机器有所了解。

虽然现代的软件开发人员不能指望对他们建立的复杂的、可扩展的、分布式的系统有充分的机械共鸣，但也应该尽可能多地去了解可以找到一个掌握的元素。

"开发者喜爱秩序的人。我们喜欢了解系统是如何工作的，一直到底层的硬件和我们正在建立的架构。但与此同时，也有许多其他领域，你不一定想深入了解它，"微软的Silver说。

许多开发人员和他们的团队的任务是确定他们的专业知识在哪里最有价值，在哪里被浪费在重新发明轮子上。"咨询师Simpson说："我们最好的希望是公司能认识到这个问题，并努力让开发人员摆脱对机器是如何工作的担心。回到构建软件，这是他们最擅长的事情。"

软件开发者从来没有像今天这样有如此多的复杂性和选择，但也从来没有像现在这样多的选择来把它抽象化。这只是归结于你和你的组织在追求你们的目标时能承受多少复杂性。

2021 年最佳开源软件榜单｜InfoWorld

Fri, 19 Nov 2021 00:00:00 CST

公众号关注 “GitHubDaily”

设为 “星标”，每天带你逛 GitHub！
来自OSC社区

大家好，我是小 G。

作为一家信息技术媒体公司，InfoWorld 成立于 1978 年，目前隶属于 IDG。

每年。InfoWorld 都会根据软件对开源界的贡献，以及在业界的影响力评选出当年的 “最佳开源软件” (BOSSIE)，该奖项评选已经延续了十多年。

本次获奖的 29 个开源项目包括：软件开发、开发、云原生计算、机器学习等类型，下面我们一起来看看，有没有熟悉的面孔！

1、Svelte 和 SvelteKit

在众多创新的、开源的、前端的 JavaScript 框架中，Svelte 及其全栈对应的 SvelteKit 可能是最有野心和远见的。

Svelte 一开始就通过采用编译时策略来颠覆现状，并以出色的性能、持续的发展和卓越的开发者体验向前迈进。

SvelteKit 现已进入公测阶段，它延续了 Svelte 的传统，通过采用最新的工具，并将部署到无服务器环境作为一项内置功能来实现飞跃。

地址：https://github.com/sveltejs/svelte

2、Minikube

Minikube 是一个易于在本地运行 Kubernetes 的工具，可在你的笔记本电脑上的虚拟机内轻松创建单机版 Kubernetes 集群。便于尝试 Kubernetes 或使用 Kubernetes 日常开发。

地址：https://github.com/kubernetes/minikube

3、Pixie

Pixie 是 Kubernetes 应用的可观察性工具，它可以查看集群的高级状态，如服务地图、集群资源和应用流量；还可以深入到更详细的视图，如 pod 状态、火焰图和单个 full-body 应用请求。

Pixie 使用 eBPF 自动收集遥测数据，它在集群本地收集、存储和查询所有的遥测数据，使用不到 5% 的集群 CPU。Pixie 的用例包括集群内的网络监控、基础设施健康、服务性能和数据库查询剖析。

地址：https://github.com/pixie-io/pixie

4、FastAPI

FastAPI 是一个高性能 Web 框架，用于构建 API。主要特性：

快速：非常高的性能，与 NodeJS 和 Go 相当
快速编码：将功能开发速度提高约 200％至 300％
更少的错误：减少约 40％的人为错误
直观：强大的编辑器支持，自动补全无处不在，调试时间更少
简易：旨在易于使用和学习，减少阅读文档的时间。
简短：减少代码重复。
稳健：获取可用于生产环境的代码，具有自动交互式文档
基于标准：基于并完全兼容 API 的开放标准 OpenAPI 和 JSON Schema

地址：https://github.com/tiangolo/fastapi

5、Crystal

作为一个提供具有 C 语言的速度和 Ruby 语言的表现力的编程语言的项目，Crystal 已经开发了好几年了。随着今年年初 Crystal 1.0 的发布，该语言现在已经足够稳定到可以用于一般工作负载。

Crystal 使用静态类型和 LLVM 编译器来实现高速度，并避免在运行时出现空引用等常见问题。Crystal 可以与现有的 C 代码接口，以进一步提高速度和便利性，它还可以使用编译时宏来扩展基础语言的语法。

地址：https://github.com/crystal-lang/crystal

6、Windows Terminal

Windows Terminal 是一个全新的、流行的、功能强大的命令行终端工具。

包含很多来社区呼声很高的特性，例如：多 Tab 支持、富文本、多语言支持、可配置、主题和样式，支持 emoji 和基于 GPU 运算的文本渲染等等。同时该终端依然符合我们的目标和要求，以确保它保持快速、高效，并且不会消耗大量内存和电源。

地址：https://github.com/Microsoft/Terminal

7、OBS Studio

OBS Studio 是一款用于实时流媒体和屏幕录制的软件，为高效捕获，合成，编码，记录和流传输视频内容而设计，支持所有流媒体平台。

高性能实时视频 / 音频捕获和混合。创建由多种来源组成的场景，包括窗口捕获、图像、文本、浏览器窗口、网络摄像头、捕获卡等。
设置无限数量的场景，用户可以通过自定义过渡无缝切换。
带有每个源滤波器的直观音频混合器，例如噪声门，噪声抑制和增益。全面控制 VST 插件支持。
强大且易于使用的配置选项。添加新源，复制现有源，并轻松调整其属性。
精简的设置面板使用户可以访问各种配置选项，以调整广播或录制的各个方面。
模块化的 “Dock” UI 允许用户完全根据需要重新排列布局。用户甚至可以将每个单独的 Dock 弹出到自己的窗口中。

地址：https://github.com/obsproject/obs-studio

8、Shotcut

Shotcut 是一款跨平台的视频编辑工具，允许人们在应用效果和分层的同时，对音频和视频轨道进行所有的标准修正。Shotcut 有一个非常活跃的社区，并提供大量的操作视频和指导，以帮助新手和高级摄像师。

它可以在 Mac、Linux、BSD 和 Windows 上运行 -- 尽管是跨平台的，但与同类工具相比，它的界面很敏捷，使用起来也相对简单。

地址：https://github.com/mltframework/shotcut

9、Weave GitOps Core

Weave GitOps 支持有效的 GitOps 工作流，以将应用程序持续交付到 Kubernetes 集群中。它基于领先的 GitOps 引擎 CNCF Flux。

地址：https://github.com/weaveworks/weave-gitops

10、Apache Solr

Apache Solr 是基于 Lucene 的全文搜索服务器，也是最流行的企业级搜索引擎。Apache Lucene 是你所使用的大部分软件的搜索功能背后的基础搜索技术 -- 包括其他搜索引擎，如 Elasticsearch。

与 Elasticsearch 不同的是，Solr 放弃了它的开源许可，不过它仍然是免费的。Solr 是可集群的、可在云端部署的，并且强大到足以建立云端级的搜索服务。它甚至包括 LTR 算法，以帮助自动调整和加权结果。

地址：https://github.com/apache/solr

11、MLflow

MLflow 由 Databricks 创建，并由 Linux 基金会托管，是一个 MLOps 平台，可以让人跟踪、管理和维护各种机器学习模型、实验及其部署。它为你提供了记录和查询实验（代码、数据、配置、结果）的工具，将数据科学代码打包成项目，并将这些项目链入工作流程。

地址：https://github.com/mlflow/mlflow

12、Orange

Orange 旨在使将数据挖掘 "富有成效且有趣"。Orange 允许用户创建一个数据分析工作流程，执行各种机器学习和分析功能以及可视化。

与 R Studio 和 Jupyter 等程序化或文本工具相比，Orange 是非常直观的。你可以将小部件拖到画布上以加载文件，用模型分析数据并将结果可视化。

地址：https://github.com/biolab/orange3

13、Flutter

Flutter 由 Google 的工程师团队打造，用于创建高性能、跨平台的移动应用。Flutter 针对当下以及未来的移动设备进行优化，专注于 Android and iOS 低延迟的输入和高帧率。

它可以给开发者提供简单、高效的方式来构建和部署跨平台、高性能移动应用；给用户提供漂亮、快速、jitter-free 的 app 体验。

地址：https://github.com/flutter

14、Apache Superset

Apache Superset 是 Airbnb （知名在线房屋短租公司）开源的数据探查与可视化平台（曾用名 Panoramix、Caravel ），该工具在可视化、易用性和交互性上非常有特色，用户可以轻松对数据进行可视化分析。Apache Superset 也是一款企业级商业智能 Web 应用程序。

地址：https://github.com/apache/superset

15、Presto

Presto 是一个开源的分布式 SQL 引擎，用于在线分析处理，在集群中运行。

Presto 可以查询各种各样的数据源，从文件到数据库，并将结果返回到许多商业智能和分析环境。更重要的是，Presto 允许查询数据所在的地方，包括 Hive、Cassandra、关系型数据库和专有数据存储。

一个 Presto 查询可以结合多个来源的数据。Facebook 使用 Presto 对几个内部数据存储进行互动查询，包括他们的 300PB 数据仓库。

地址：https://github.com/prestodb/presto

16、Apache Arrow

Apache Arrow 为平面和分层数据定义了一种独立于语言的柱状内存格式，为现代 CPU 和 GPU 上的高效分析操作而组织。

Arrow 内存格式还支持零拷贝读取，以便在没有序列化开销的情况下进行闪电式的数据访问。Arrow 库可用于 C、C++、C#、Go、Java、JavaScript、Julia、MATLAB、Python、R、Ruby 和 Rust。

地址：https://github.com/apache/arrow

17、InterpretML

InterpretML 是一个开源的 Explainable AI（XAI）包，其中包含了几个最先进的机器学习可解释性技术。

InterpretML 让你训练可解释的 glassbox 模型并解释黑盒系统。InterpretML 可帮助你了解模型的全局行为，或了解个别预测背后的原因。

在它的许多功能中，InterpretML 有一个来自 Microsoft Research 的 "glass box" 模型，称为 Explainable Boosting Machine，它支持用黑盒模型的近似值进行 post-hoc 解释的 Lime。

地址：https://github.com/interpretml/interpret

18、Lime

Lime（local interpretable model-agnostic explanations 的简称）是一种 post-hoc 技术，通过扰动输入的特征并检查预测结果来解释任何机器学习分类器的预测。

Lime 能够解释任何具有两个或更多类的黑盒分类器，其同时适用于文本和图像领域。Lime 也被包含在 InterpretML 中。

地址：https://github.com/marcotcr/lime

19、Dask

Dask 是一个用于并行计算的开源库，可以将 Python 包扩展到多台机器上。Dask 可以将数据和计算分布在多个 GPU 上，无论是在同一个系统中还是在一个多节点集群中。

Dask 与 Rapids cuDF、XGBoost 和 Rapids cuML 集成，用于 GPU 加速的数据分析和机器学习。它还与 NumPy、Pandas 和 Scikit-learn 集成，以并行化其工作流程

地址：https://github.com/dask/dask

20、BlazingSQL

BlazingSQL 是一个基于 RAPIDS 生态系统构建的 GPU 加速 SQL 引擎。RAPIDS 基于 Apache Arrow 柱状内存格式，cuDF 是一个 GPU DataFrame 库，用于加载、连接、聚合、过滤和操作数据。它是 cuDF 的 SQL 接口，具有支持大规模数据科学工作流和企业数据集的各种功能。

地址：https://github.com/BlazingDB/blazingsql

21、Rapids

Nvidia 的 Rapids 开源软件库和 API 套件让你有能力完全在 GPU 上执行端到端的数据科学和分析管道。

Rapids 使用 Nvidia CUDA 基元进行底层计算优化，并通过用户友好的 Python 接口暴露了 GPU 的并行性和高带宽内存速度。Rapids 依赖于 Apache Arrow 柱状内存格式，包括 cuDF，一个类似 Pandas 的 DataFrame 库；cuML，一个机器学习库集合，提供 Scikit-learn 中大多数算法的 GPU 版本；以及 cuGraph，一个类似 NetworkX 的加速图分析库

地址：https://github.com/rapidsai/cudf

22、PostHog

PostHog 是一个为开发人员构建的开源产品分析平台。自动收集你网站或应用程序上的每个事件，无需向第三方发送数据。它在用户级别提供基于事件的分析，捕获你产品的使用数据以查看哪些用户在你的应用程序中执行了哪些操作。它会自动捕获点击次数和综合浏览量，以分析你的用户在做什么，而无需手动推送事件。

地址：https://github.com/PostHog/posthog

23、LakeFS

LakeFS 提供了一种 "以管理代码的方式管理你的数据湖" 的方法，为对象存储增加了一层类似于 Git 的版本控制。

这种对 Git 语义的应用让用户可以创建自己的隔离的、零拷贝的数据分支，在上面工作、实验和建模分析，而没有破坏共享对象的风险。LakeFS 为你的数据带来了有用的 commit notes、元数据字段和 rollback 选项，同时也带来了维护数据完整性和质量的验证 hooks-- 在一个未提交的分支被意外地合并回生产中之前，运行格式和模式检查。

通过 LakeFS，管理和保护代码库的熟悉技术可以扩展到现代数据库，如 Amazon S3 和 Azure Blob 存储。

地址：https://github.com/treeverse/lakeFS

24、Meltano

Meltano 是今年从 GitLab 中分离出来的，一个免费的开源 DataOps 替代传统 ELT（提取、加载、转换）的工具链。Meltano 的数据仓库框架使得为你的项目建模、提取和转换数据变得容易，并通过内置的分析工具和简化报告的仪表盘来补充集成和转换管道。

Meltano 提供了一个可靠的提取器和加载器库，以及对 Singer 标准的 data extracting taps 和 data loading targets 的支持，Meltano 已经是一个数据编排的动力源。

25、Trino

Trino（原名 PrestoSQL）是一个分布式 SQL 分析引擎，能够对大型分布式数据源运行极快的查询。

Trino 允许你同时对数据湖、关系型存储或多个不同来源执行查询，而不需要复制或移动数据进行处理。而且 Trino 与你的数据科学家可能使用的任何商业智能和分析工具配合得很好，无论是交互式的还是临时性的，最大限度地减少了学习曲线。

随着数据工程师努力支持越来越多的数据源的复杂分析，Trino 提供了一种优化查询执行和加速不同来源的结果的方法。

地址：https://github.com/trinodb/trino

26、StreamNative

StreamNative 是一个高度可扩展的消息和事件流平台，大大简化了实时报告和分析工具以及企业应用流的数据管道铺设。

StreamNative 将 Apache Pulsar 强大的分布式流处理架构与 Kubernetes 和混合云支持等企业额外功能、大型数据连接器库、简易认证和授权以及用于健康和性能监控的专用工具相结合，既简化了基于 Pulsar 的实时应用程序的开发，又简化了大规模消息传递背板的部署和管理。

地址：https://github.com/streamnative

27、Hugging Face

Hugging Face 提供了最重要的开源深度学习资源库，它本身并不是一个深度学习框架。Hugging Face 的目标是扩展到文本之外，支持图像、音频、视频、物体检测等。Infoworld 指出，深度学习从业者应在未来几年内密切关注这个 repo。

地址：https://github.com/huggingface/transformers

28、EleutherAI

EleutherAI 是一个由机器学习研究人员组成的分布式小组，旨在将 GPT-3 带给所有人。

2021 年伊始，EleutherAI 发布了 The Pile，是一个 825 GB 的用于训练的多样化文本数据集；并在 6 月公布了 GPT-J，一个 60 亿参数的模型，大致相当于 OpenAI 的 GPT-3 的 Curie variant。

随着 GPT-NeoX 的出现，EleutherAI 计划将参数一直提高到 1750 亿，以与目前最广泛的 GPT-3 模型竞争。

地址：https://github.com/EleutherAI/gpt-neo

29、Colab notebooks for generative art

首先是 OpenAI 的 CLIP（对比语言 - 图像预训练）模型，一个用于生成文本和图像矢量嵌入的多模态模型。虽然 CLIP 是完全开源的，但 OpenAI 的生成性神经网络 DALL-E 却不是。

为了填补这一空白，Ryan Murdoch 和 Katherine Crowson 开发了 Colab notebooks， CLIP 与其他开源模型（如 BigGAN 和 VQGAN）结合起来，制作 prompt-based 生成性艺术作品。

这些 notebooks 基于 MIT 许可，于过去几十年间在互联网上进行了广泛传播，被重新混合、改变、翻译，并被用来生成了惊人的艺术作品。

地址：https://github.com/openai/CLIP

如果你今年有看过一些比较酷炫或实用的开源项目，也欢迎在评论区分享。

视频剪辑软件「剪映」的学习笔记

Wed, 20 Oct 2021 00:19:12 CST

介绍

有了吉宝之后，最近偶尔会上传她的视频到抖音上，为了让视频更好玩儿，开始利用空闲时间学习视频剪辑。抖音官方有一个视频剪辑软件「剪映」，功能挺强大，因此，立个小目标，下半年持续学习输出它的使用笔记。

学习教程

胖姐的迷糊小生活一位自媒体妈妈，出了很多关于剪映的视频剪辑教程。
B站/史上最精简最全的剪映教程【基础篇】比较系统，但是介绍的比较基础，入门还可以

界面

可以在设置中关闭自动添加片尾

比例

首页菜单下，调整视频的比例。

背景

首页菜单下，用于填充比例的视频空余的部分，下面的选项是单选，不叠加的：

画布颜色
画布样式
画布模糊

设置画布的效果默认是给时间轴上那段视频片段设置，如果要将画布样式设置给所有的视频，那么，点击界面上的「应用到全部」按钮即可。

剪辑

首页菜单下，剪辑中提供了很多功能，可以点击「剪辑」进入剪辑状态，此外，单击视频也会自动进入剪辑状态。

分割
变速
音量
变声
删除
降噪：对录制的视频中音频进行降噪处理
复制
倒放
定格：就是选取了视频中指定时间点画面持续几秒钟，类似于截图。

美化

美化下提供了两个主要的功能：美颜和美体

美颜：
- 磨皮
- 瘦脸
美体：
- 瘦身
- 长腿
- 瘦腰
- 小头

音频

首页菜单下

音乐

导入音乐：在音频-》音乐-》导入音乐下，支持输入一段音乐的链接地址进行导入。用这个功能就可以实现将网易云音乐的分享链接粘贴到这里，作为视频的背景音乐了。

音效

这个菜单下提供了很多音效，例如：

综艺：
- 疑问-啊？：那种黑人问号的场景使用
- 震惊
- “喂”
- 屏蔽脏话
- 土拨鼠大吼：啊！
- 剧场欢呼
- 口哨
- 尴尬
- 无语
- 打嗝
- 放屁声
- 黑线
- 亲
- 悲伤长叹
笑声
- 多人大笑
- 观众笑声
机械声
- 打字声
- 机械键盘打字声
- 系统警告
- 时钟滴答
- 门铃
BGM
- Hello it’s me
- 小朋友你是否有很多问号
- 疑惑
人声
- 我太难了
- 什么？（日文）
游戏
- 一杀
美食

录音

可以给视频通过自己录音的方式进行配音。

音频编辑

当点击添加的音频时，会自动进入音频编辑的状态。

踩点

提供了「自动踩点」的功能，能够在音频的时间轴上进行踩点标记，这样的话，就可以在一些音频点上进行照片的添加、转场等，这样会使视频效果更具有节奏感。

变声

例如可以将自己录制的配音进行变声处理，提供了一些选项：

大叔
萝莉
女生
男生
怪物

文本

新建文本

给视频配上文本，充当字幕

识别字幕

针对视频里的声音或者你给视频添加的录音进行识别，自动生成字幕。

文本编辑

点击添加的文本，会自动进入文本编辑状态

文本朗读

针对自己添加的文本，进入文本编辑状态，选择文本朗读，提供了很多特效声音来朗读你的文本：

动漫小新
说唱小哥
台湾女生
动漫海绵
小萝莉
东北老铁

贴纸

首页菜单下，提供了贴纸的菜单。

点击添加的贴纸，四个角的功能有所不同，提供了缩放、编辑、删除、复制的功能。

选中贴纸，进入编辑状态，提供了若干动画效果的设置：

入场动画
出场动画
循环动画：
- 心跳：这个效果不错，比如结合一个手指，心跳效果可以起到引人注目效果。
- 旋转

滤镜

首页菜单下，提供了滤镜的菜单。

调节

首页菜单下，提供了调节的选项。在该菜单下提供了如下的功能：

亮度
对比度
饱和度
光感
锐化
高光
阴影
色温
色调
褪色
暗角
颗粒

特效

人脸道具

这个功能很赞，可以实现针对拍摄的视频自动识别人脸，然后用选择的道具替换，避免露脸了。

画面特效

画面特效中提供了很多选择，例如：

基础-》开幕：这个在很多视频的开场可以使用一下
动感-》抖动：有种画面抖动效果
动感-》灵魂出窍：有种画面抖动效果
动感-》毛刺：有种画面抖动效果
边框-》录制边框：有种正在摄影的感觉
自然-》玫瑰花瓣：很唯美
复古-》复古DV：给画面一种老电影的感觉
分屏-》三屏

转场

点击 2 个视频片段之间的分隔键，会弹出转场的选项：

基础转场
- 左移
- 右移
- 上移
- 下移
运镜转场
- 推近转场
- 拉远
特效转场
MG转场
幻灯片
遮罩转场

国家队出品的学习网站，还免费！_软件应用_什么值得买

Tue, 17 Aug 2021 12:51:44 CST

1、国家中小学网络云平台

点此进入传送门

国家中小学网络云平台是当时为了疫情期间停课不停学设计的，界面清晰无广告，课程涵盖了从小学一直到到高三。授课教师都是来自全国各地的优秀教师，比起辅导机构的老师更正规，更有经验。果然国家出品才是真正的良心出品，就这样精华级别的课程，竟然完全不收任何费用！

2、国家基础教育资源网

点此进入传送门

国家基础教育资源网的界面也是非常简洁明了。这里有从小学到高中的各种资源，包括公开课、课件、教案等，而且都根据教材分门别类了，不管你们学校用的是人教版还是北师大版，都能找到相应的学习资源。阵主看了一下，这个网站甚至连育儿和学前班的教程资源都有，真的是从孩子出生管到上大学啊！

3、一师一优课一课一名师

点此进入传送门

现在“一师一优课一课一名师”这个网站已经收录了将近一千七百万节公开课了，国家队出手，果然恐怖如斯！不管是小学初中还是高中，不管是语数外主课还是体育书法等副课，这里都是应有尽有。如果孩子不满足于课堂上学的东西，回家完全可以来这里继续学习，还不用给辅导机构充钱，多棒啊。

4、人民教育出版社官方网站

点此进入传送门

人民教育出版社的官网上也有不少学习资源，配上人教版自己的教材，学习起来自然也是事半功倍。不仅如此，人教版官网上面还有不少关于教材课程设计的探讨，我觉得家长和孩子如果能一起了解一下的话，也会对如何学习该门课有更深的认识。

对于语文课程，人民教育出版社也会有自己为课本中课文出的示范诵读，像很多偏远地区的老师自己普通话其实都会多少带一点口音，但是这个诵读真的是十分标准，也是非常珍贵的资源。

5、安徽基础教育资源应用平台

点此进入传送门

除了国家队出手的资源，我们的省队也出手了。安徽基础教育资源应用平台属实不错，界面非常简洁，从学前到高中的各类学习资源也都分门别类归纳好了，任君获取。里面的课程资源也是蛮丰富的，大家完全可以拿来找找对自己有用的学习资料。

结尾

好了，本文就分享到这里。大家有其他有用的学习网站的话，也欢迎在评论区补充呀！另外，活到老，学到老，之前分享的学习资源帖子也一并附在下方~

新年学习的FLAG已经立下，就让这8个公开课网站助你完成目标吧！创作立场声明：如果对大家有帮助的话，欢迎大家点赞分享，转发收藏呀！大家好，我是聚灵阵主。又好久没有发文啦，这次带来的是阵主整理的公开课网站合集。说实话，公开课网站这种东西很有用，但是没有必要把阵主推荐的网站全部收藏，收藏一部分，然后需要学什么就在里面搜就行了。就目前的互联网来看，资源并不短缺，短缺的聚灵阵主| 赞52 评论89 收藏220查看详情不管你是谁，总要聊点AI吧！人工智能入门书籍、视频、课程以及其他资源推荐创作立场声明：无任何利益相关，若是文章有什么纰漏疏忽错误之类的，欢迎大家指正！大家好，我是聚灵阵主。其实开着一篇我自己也很忐忑，毕竟阵主不算是深度的从业人员，但是我自己目前的专业也是跨在和人工智能的交叉学科上面。这篇文章准备搜集一些学习人工智能所需要的资源网站等，即使为身为小白的我自己准备的，也给大聚灵阵主| 赞67 评论132 收藏42查看详情 APP/网站/UP主，免费英语学习资源集锦，还愁学不好英语吗？创作立场声明：一些英语学习的经验和资源汇总。有帮助的话，还请给个点赞收藏打赏关注啊！大家好，我是聚灵阵主。我又双叒叕来啦。年底了，这次跟大家分享的是英语学习的网络资源。首先要说明的是，阵主分享的这些都只是工具，要真正地学好英语，最终还是靠自己！真正地学好英语，最终还是靠自己！真正地学好英语，最终还是聚灵阵主| 赞576 评论266 收藏5k查看详情众所周知，B站是一个学习网站，19位UP主带你好好学习！创作立场声明：快来B站搞学习！欢迎大家点赞打赏收藏评论啊！大家好，我是聚灵阵主，没错，我有又双叒叒来啦。说起今年，对阵主生活影响最大的，除了疫情，就是B站了，自从成为了B站用户之后，我这个沙雕视频爱好者竟然在里面找到了一堆正经或者不正经搞科普的UP主，今天阵主就来分享以下我觉得值得关注的这些只是区U聚灵阵主| 赞738 评论298 收藏6k查看详情

学生党最应该知道的资源---技能/软件/编程/英语/二外/计算机二级/其他学习/论文下载/电子书/PPT模板_哔哩哔哩_bilibili

Sun, 25 Jul 2021 23:13:24 CST

1、技能学习平台：哔哩哔哩、中国大学慕课、coursera、edX
2、软件操作：up主：oeasy、doyoudo、星月兮、Genji是真想教会你、旁门左道PPT、Excel自学成才、我是于干，+实战演练
3、编程：基础：菜鸟教程、进阶：CSDN、Github、stackoverflow、leetcode
4、英语：四六级尽早考+买真题，进阶：扇贝、中国日报网英语点津、Italki、Audible、NPR.org、考满分
5、二外：最好找老师，入门：多邻国
6、计算机二级：学校基础课、买题库，up主：小黑课堂计算机二级
7、其他：学吧导航
8、论文下载：学校图书馆或省市图书馆，知网、Web of Science、图书馆官网直接检索、SCI-HUB、Library Genesis、Z-Library
9、电子书：某宝、读秀、超星、书格、七彩英语、古腾堡计划、manybooks、鸠摩搜索、Library Genesis
10、PPT模板：OfficePLUS、PPT超级市场、51PPT模板、PPT汇、优品PPT、HiPPTer

to B软件为啥用户体验不好_阿朱=行业趋势+开发管理+架构-CSDN博客

Wed, 16 Jun 2021 12:45:53 CST

to B软件为啥用户体验不好？我今天从机制根源层面给大家说说。否则大家还停留在UI、UE的认知层面上。

（1）从甲方视角看

to B软件其实分为：高层决策软件、中层管理软件、基层业务操作软件。

大家抱怨的焦点其实是：中层管理软件。

实际上，对于高层决策软件，一般会呈现为大屏可视化，用户体验可好呢。因为用户体验不好的话，决策层就决定着合同的生死大权。

实际上，对于基层业务操作软件，尤其是面向消费者进行收费结算收银计费的，更是用户体验好。我过去做过零售业收费系统、医院计费收费系统，那操作人员，快的很。因为用户体验不好的话，就影响企业招财进宝。

大家抱怨的焦点其实是：中层管理软件。为啥？

就是因为：管理层有病，让员工吃药。

管理软件，买单的是领导，主要用的人却是员工（为了输入采集管理层需要的数据）。

买的人不用，用的人不买，这是企业管理软件用户体验不好的重要原因。

另外一个原因也是此问题的延伸。为啥买的人不用，用的人不买？

嘿嘿嘿，管理软件，在中国就容易变成管控软件，变成管理者对员工的控制工具。

所以买的人不用，用的人不买，这也是有道理的。

既然是控制工具，那控制的招儿就多了去了。

有人说，西方的管理软件也用户体验不好啊。难道西方也把管理软件像中国一样变成控制工具了？

嘿嘿嘿，你还真说对了。

你以为西方的管理软件是企业运营管理团队买的吗？错了。西方的管理软件是董事会买的。

500年前，1603年，世界上第一个股份制有限责任公司在荷兰产生。这家公司：

社会公开发行股票来募资
成立股票交易所进行股票售卖发行、转让
这么多社会股东，于是选举大股东成立董事会
董事会的人都是投资者股东，他们也不懂具体业务经营。所以由董事会雇佣职业经理人团队来具体日常经营

一帮都是投资者股东的董事会，为了防止这帮高级打工人为了短期利益骗他们，于是：

事前：董事会雇佣咨询公司做战略设计咨询、业务流程设计咨询
事中：董事会雇佣IT公司，把战略设计、组织设计、业务流程、绩效考核指标都固化到IT代码中，让经营团队日常开展业务时使用，把数据沉淀在IT系统中
事后：董事会雇佣会计师审计师事务所，从IT系统中抽取数据，来做事后审计

所以，西方企业服务（咨询服务、IT服务、会计师审计师服务）是兴盛了上百年。而我国，因为机制不同，所以这整个体系都没有。所以也谈不上前进发展。

很多人说中国企业的企业管理水平不成熟，等待中国企业管理水平成熟。

我想说：....。

（2）从乙方视角看

其实这还是从甲方视角来说的，但屁股是坐在乙方的。

首先说一个不知道对错的话，这个话是我展开话题的基础，如果这个前提假设错了，我的这个展开就是错的了。

这个话就是：中国，知识不值钱。

所以，咱们才会出现那两个网上段子：

1、中国段子：雷军被人骗了，花了三年时间，花了两百万，只是把小米Logo的直角改成了圆角。哈哈哈哈，给我15秒钟，给我100块，我一行JS代码就能做到

2、西方段子：我用粉笔画这根线，确实只值一美元。但是我在这个地方画这根线，值9999美元。

很多甲方抱怨乙方的企业管理软件做的太不人性了。然后我说：如果我有本事，把现在这1000个功能点简化成十个功能点，还卖现在这个价格，你们能同意吗？

答案是：不同意。

对，这就是中国。1000个功能点你可以卖100万，但你达到同样功效的十个功能点却卖不了100万。这就是认知。

我们还停留在为数量认知的水平，还没有上升到为质量认知的水平。

优化企业管理软件的用户体验其实很容易：

从业务视角出发：做企业业务流程重组
从技术视角出发：应用自动化/传感器、智能化/RPA，让企业管理软件静默后台工作，不需要前端人工来操作
从考核视角出发：每年要求软件操作（按钮点击和文本输入）减少15%。如此坚持6年，就会减少90%的按钮和文本输入

但是，你敢这么要求吗？

我想起了京东和四通一达的例子。京东物流主要是自己用，所以如果不提高效率，成本全是自己的。所以京东物流拼命做无人仓、无人机、无人车。而四通一达主要是给别人搬箱子，搬一次就收一次的钱。所以四通一达没有优化效率的动力，因为机制原因，自己越优化，自己越不容易赚钱。

这就是机制问题，怎么优化也是杯水车薪。如果做软件是自己自用而不是卖给别人，那自己自用当然是越简单越好，否则就是给自己自找麻烦。如果是卖给别人，那就越复杂越好，这样就能在竞标时说：我们为啥比竞争对手卖的贵、我们为啥比竞争对手好，就是因为，我们有1500个功能点，竞争对手才1000个功能点。

（3）从乙方商业模式视角看

过去是软件模式，一旦发版，就安装到了一家家客户的内部。如果这时候你才发现一个BUG，这要升级，那花费的成本、效率可就费死劲了。

所以过去开发软件，都是一年发一个版本：3个月产品设计、3个月架构设计、3个月开发、3个月测试。

所以你会看到SAP，1993年发布C/S模式的R/3 ERP套件，2014年才发布B/S模式的S/4 ERP套件。这一下子就过去了20年。而且再过三年就2024年了，从2014年发布S/4，到2024年，十年又过去了。

所以很多人抱怨为啥很多企业管理软件还在用IE6。无他，因为企业管理软件的节奏是：十年甚至二十年才一个大改变，每年一点小修补。

但是SaaS时代不一样了。很多人不明白为啥欧美SaaS公司大多创办于1997-2003这个年头。

其实是因为欧美SaaS这个新模式的产生，是当初由两拨人融合而成的。一拨人是传统软件人出身，但想搞互联网。因为1997年亚马逊、雅虎上市，市值都飞到天上去了。人人都想做互联网，想发财。像Salesforce的创始人就是Oracle传统软件出身，想模仿Amazon的电子商务网站模式，在网上卖软件、支付软件费、运行软件。还有另一帮人是做互联网创业的，可惜2001年世界互联网泡沫破裂了，不好融资了，要么死，要么转型。所以这帮互联网人就被迫转型搞了企业软件。但是这两拨人搞企业软件都不是用新技术把过去的传统企业软件重搞一次，而是这两拨人融合成了一种新模式，这就是既不像传统软件，又不像互联网电子商务网站的一种新模式，那就是：公有云、多租户、网上营销、网上试用、网上支持、网上使用、网上社区支持。你说这像不像不带流量的天猫商铺啊。

而中国从2015年以来兴起新一波SaaS，进来的人却大多是传统软件人，主要是用新技术把老东西重做一次，而且研发模式也是传统软件研发模式，只不过周期缩短成了一个季度发一个版本。还是版本管理模式。

我在京东的时候，我没听说京东的网站是按照版本来研发的。

我今天从机制根源层面给大家分析了：TO B软件为啥用户体验不好了。

大家也就明白了：to B软件，用户体验会永远不好。

这是机制决定的。

只有业务+IT一体化的羊毛出在狗身上的互联网公司电子商务公司，做企业生产力工具，才会体验好。如果互联网公司电子商务做企业内部管理软件，也是一样的烂用户体验德行。

海康威视：形成软件开发方法论，社会经济到了由商业需求拉动的时代

Sat, 29 May 2021 17:56:00 CST

近日，海康威视举行投资者问答会议。

在AI市场机会上，海康认为AI的机遇已经得到行业普遍认同，未来AI成本会持续降低，AI技术在改善产品性能上作用很大，AI算法和大数据等，会带来许多之前想做但做不到的业务机会，也会开拓新玩法，未来会打开更多市场。

在软件投入上，组件化的开发已经是海康确定的软件开发方法论。近几年海康的软件开发环境、管理环境、运维环境的使用都已经成熟，过程更规范、更有效率。未来PaaS、DaaS、SaaS层面都有更多的事情可做，海康各个层次的软件研发管理维护的资源团队都会再进一步加大投入。

海康从可见光走向全光谱，发力多维感知，是作为一家做物联网、大数据的公司必然选择，既然是必然选择就先不考虑产出比。海康预期三年未来市场端变化将非常复杂，对海康靠技术创新的公司将有更多机会。

未来10年，创新业务保持更快增长的确定性较高。

未来几年，三个BG都将有不错发展，受不同因素影响会有阶段快慢。

PBG会受限于地方政府的财政和疫情，但政府项目的数据规模大、应用复杂程度高，会一直是应用高地，也会有新的业务形式；

EBG从长期看比PBG市场更大，社会的经济增长到了更多由商业需求拉动的时代；

SMBG会围绕服务渠道伙伴、工程伙伴，连通线上线下，提高运转效率，改善生态，扩大海康的业务影响力。

尽管未来有诸多不确定性，但海康的销售和研发的费用投入上，必须做两件事：

一事平台的搭建与持续维护，与行业应用不断做新的融合；二是产品，基于创新业务和基础技术开发上的产品。

做企业既要有风险管控能力，也需对保持对机会的追求。

以下是调研全文重要内容，雷锋网作了不改变原意的整理与编辑：

Q：目前AI的应用逐渐落地，公司觉得国内外市场机遇怎么判断？

A：经过过去几年的发展，行业中的玩家已经更加认同，AI是个基础技术，在很多方面都会发挥作用。未来AI的成本还会持续的降低，AI技术在帮助产品性能的优化和改善上帮助是很大的，由此会打开越来越多的市场。

AI的算法和大数据相关的应用，会带来许多以往我们想做但是做不到的业务机会，也开拓更多新技术平台上的新玩法。

国内的应用走得快一些，但很难说用我们在国内锻炼出来的产品和方案直接复制海外市场。海外市场对AI应用的观点不同，AI应用的发展节奏也不同，不同国家和地区之间的发展路径也是不一样的。还是要根据每个国家每个地区的不同需求，来制定不同的产品策略与方案。

Q：算法、数据对业务越来越重要，也看到海康为了适应对算法和数据的开发而在软件开发的方式上不断转型，用组件为基础开发软件已经看到很多成效，未来的软件投入主要是什么层次和方向上的？

A：过去几年海康谈的比较多的是统一软件架构，组件化的开发已经是公司确定的软件开发方法论，也是用来整合各个团队开发资源的基础。

这几年的软件开发环境、管理环境、运维环境的使用也都已经成熟，这些环境能保障软件开发和管理维护的过程更规范，更有效率。

在这些基础能力上，我们也在针对数据和应用做很多工作，做PaaS和DaaS，把PaaS和DaaS4这两层搭起来用起来，现在已经有一些应用和模型基本上成熟了。

SaaS部分海康和伙伴们分工协作，直接面对用户场景做定制开发。随着我们统一软件架构这个整体方法论的成熟，以及方法论之下各种技术工具不断被打磨，我们有了将应用和数据做深做厚的能力，也有了协调更多的软件研发资源，做更大规模开发的能力，未来PaaS、DaaS、SaaS层面都有更多的事情可做，我们的产品会更加丰富，公司各个层次的软件研发管理维护的资源团队会再进一步加大投入。

Q：年报中判断未来三年是机遇期，也提到了海康正在从可见光走向全光谱，请问从可见光走向非可见光的部分，公司要怎么投入，能带来多少回报？

A：非可见光在场景中最重要的作用在于，在某些场景下，某种感知方式可以发挥不可替代的作用，比可见光会更加有效，即使只在整体方案中占不多的比例，但作为补充会非常有价值。

对于投入和回报，在初始阶段我们对产出不是特别关心，早期也不知道会做成怎么样。只是觉得对海康来说作为一家做物联网、大数据的公司，多维感知是我们必然的一个选择，既然是必然选择就先不考虑产出，效果交给时间。

未来三年我们预期市场端的变化将是非常复杂的，包括逆全球化的趋势、上游供给侧的变革，会带来很多产业的结构发生深刻的变化。未来几年，尤其是像我们这样靠技术创新发展的公司来说，应该有更好的机遇。

Q：如果未来三年是海康的一个大发展阶段的话，三个BG和创新业务的收入占比会是一个什么样的分布？

A：创新业务整体来说占比还小，但是我们的创新业务很聚焦，可以和海康在技术能力、客户资源、产业链配合上有很强的协同效应，所以创新业务在下一个10年中保持更快的增长都是确定性比较高的。

未来几年，三个BG都会有不错的发展，但是受到某些因素的影响，会出现阶段性的有快有慢，会不一样。

PBG在过去2年多的时间里受限于地方政府的财政状况，今天疫情之下政府也在继续为企业降低负担，也在削减自身的财政收入，但是政府项目的数据规模大，应用复杂程度高，会一直是应用的高地，也会不断有新业务形式发展出来，带动公司的进化。

从长期发展来看，EBG应该比PBG要大一些，社会也到了经济增长更多的由商业需求拉动的时代。SMBG方面我们会围绕服务渠道伙伴、工程伙伴做更多的工作，连通线上线下，让我们生态里的行业从业者更专业、更规范的开展工作，也用互联网后台的建设和管理帮他们提升运转效率，通过他们扩大海康的业务影响力。

Q：海康的费用率从季度环比看是往下走的，在销售费用和研发费用的投入上接下来是什么节奏？

A：未来还有很多不确定性，我们肯定会做很多事情。

一是平台搭建，还需要不断的维护，更多的行业应用会起来，会有一些新的融合；

二是产品，包括在创新业务、在基础技术开发上面，未来可能都会有大的变化。

在当前国内大循环和国际双循环的大环境下，中国和美国在高科技上的投入态势会和过去20年有很大的差别，中国的科技产业的地缘分布结构可能会有很大的调整。

我们相信在包括半导体、高科技、材料、基础算法等很多方面，中国企业在未来10年、15年会有很大的发展空间，这是我们看到的机遇，也要抓住这个机遇，保持相当的投入力度。费用率未来还是会继续往上走，我们做企业既要对风险有能力管控，也要对机会保持追求。雷锋网雷锋网雷锋网

免费开源剪辑软件Shotcut推荐和使用教程 - 简书

Sun, 23 May 2021 22:16:09 CST

最近想剪辑一下教学视频，想着能不用盗版尽量不用盗版，况且自己的需求并不复杂，又不是剪辑电影电视剧了，就没有下载那几个大牌的剪辑软件。

简单研究了一下免费的剪辑软件，最后选择了Shutcut。这是一个开源的免费软件，官网地址是 https://shotcut.org/。官网进去是英文版的，不要恐慌，软件下载下来界面有中文版。

Shotcut软件的界面.png

下面大概说一下这个软件怎么使用。

导入素材，建立时间线

将需要剪辑的素材拖动到「播放列表」区域，将素材导入到软件。
点击时间线下面的「三横线符号」，打开附加操作菜单，在里面选择添加视频轨道，根据需要可以再添加音频轨道或多个视频轨道。

Shotcut剪辑-添加视频轨道.png

将素材拖动到对应的轨道上。如果需要素材先后播放，就拖动到同一个轨道上，如果需要视频以画中画的形式叠加播放，就拖动到不同轨道上。

音频视频对齐

教学视频往往会同时录制多个视频，比如一个是电脑录屏，一个是教师出境。

剪辑时如果两个视频没有对齐的话，教师的口型就对不上声音，或者PPT翻页和声音不一致。

Shotcut这个软件的一个好处是每个视频轨道都可以显示音频波形，通过对比音频波形可以很方便的对齐视频。视频对齐后，将其中一条的音轨关掉，保留收音效果较好的那一条视频的音轨。

音频对齐.png

调整画中画位置

改变上层视频的位置和大小

导入两个视频时，视频都会居中布置，如果需要调整上层视频的位置的话，需要在 「时间线」里面选中上层视频，然后在 「滤镜」中选择 「位置与尺寸」，就可以调整上层视频的位置了。

调整画中画位置.png

实际上，不光上层视频可以调整位置，下层视频也可以调整位置，从而做出两个视频并列的效果。

上层视频位置和大小的变换

有时在教学视频里面，上层视频（比较教师出境视频）的大小和位置是需要变化的，比如说PPT首页的时候，教师出境视频比较大，内页的时候，出境视频会比较小。

这种情况，首先需要对视频进行切割。选中需要切割的视频，将播放点的竖线拖动到你要切割的位置。在时间线上面的工具栏选择 「于播放点处切割」，选中的视频就可以被切割为2个视频，可以单独设置滤镜，选择 「位置和尺寸」滤镜，就可以重新设置上层视频的位置和尺寸了。

这里有一个小技巧，通过音频波形，可以迅速的找到PPT的翻页点，因为翻页点上基本不说话。

切割视频.png

因为上层视频发生了变化，为了不显得太突兀，可以增加一个淡入淡出的效果。

在前一段视频上增加一个 视频淡出滤镜，在后一段视频上增加一个 视频淡入滤镜。完成后时间轴上会出现两个半透明的三角形。

淡入淡出.png

显示字幕、文字

首先在视频轨道上方再增加一个新轨道。

然后在工具栏的 「打开其他」里面选择 「文本」，在打开的对话框里输入你要显示的文本内容。

插入文本.png

输入文本后点OK，在预览框里会显示文本的内容，将其拖动到新增加的轨道上。注意拖动的时候不要点中间那个点，要按住文本框的其他位置拖动。否则的话不会把文本框拖动到时间线上，而是会把文本框在画面上移动位置。

插入文本效果.png

将文本拖动到轨道上之后，就可以在滤镜里设置文本的字体、颜色等。

拖动文本效果.png

设置转场动画

如果在要把两个视频相连的话，可能需要设置转场动画。

将一个轨道上的两个视频重叠，重叠的部分就会变成紫色的沙漏形状。右键点击这个沙漏，选择 「属性」，就可以设置转场动画了。

转场动画.png

视频输出

最后就是进行视频输出了，也就是将剪辑好的视频按照一定的格式保存到本地。

Shutcut没有按照素材来源自动选择参数的功能（还是说我没发现？），需要手动选择参数。

在工具栏上选择 「输出」功能（图标是一个光盘💿），打开输出界面。来源选择 时间线，硬件编码器推荐不要勾选。勾选了硬件编码器的话，如果你的显卡支持硬件编码，导出会比较快，但是视频质量低于不使用硬件编码。

输出.png

左边的列表是常见的视频编码和参数选择，如果对编码器比较懂的话，还可以点高级自己设置。如果对视频编码不太懂的话，这里推荐几个选项。

内建里面的「H.264 High Profile」，这个导出以后是「.mp4」格式，兼容性较好。
内建里面的「HEVC Main Profile」，这个导出以后也是「.MP4」文件。HEVC也叫H.265，压缩率比H.264高一些，但是个别老一点的设备可能不兼容。

选择格式之后，点击 「输出文件」，选择保存位置。

确定后，在界面最右边的任务里面会显示进度，泡杯茶耐心等待吧。

漫长的进度条.png

本文同时发表在我的博客「吕旭说」上。

有没有什么推荐的电子相册制作软件或网站？ - 知乎

Sun, 23 May 2021 08:20:45 CST

在线电子相册制作网站（1-2）

1、bilibili云剪辑

2、右糖在线视频制作

Windows客户端软件（3-4）

3、蜜蜂剪辑

4、Adobe Premiere

Mac OS客户端软件（5-6）

5、iMovie

6、Final Cut Pro X（FCPX）

制作电子相册教程：

在线电子相册制作网站（1-2）

1、bilibili云剪辑

b站2020年初推出的在线云端剪辑服务，无需导出、一键投稿到b站 ，不支持导出下载呢

需要用74以上版本Chrome内核浏览器如：Chrome，Opera等才可以使用，无法在手机等移动设备上运行哦，滤镜、转场、变速、变声、字幕、贴纸、粒子、特效等功能：

首先点击【资源库】-【上传】，上传你想要做成相册的文件（图片、视频、音乐），将素材拖曳到下方的时间轴，就可以按需调整持续时长、添加转场滤镜等。

以上的操作完成后，可以点击右上角【立即投稿】，选即可一键投稿到b站喽~

2、右糖在线视频制作

右糖制作电子相册教程：

【右糖教程】3分钟带你快速上手右糖视频制作_哔哩哔哩 (゜-゜)つロ干杯~-bilibiliwww.bilibili.com

右糖是一款拥有丰富模板的在线视频制作工具，模板场景涵盖：【婚礼爱情】、【生日祝福】、【成长记录】、【团建活动】、【商业宣传】、【教育党政】，外加如：哈利波特预言家日报动态报纸等【创意模板】效果；

使用右糖，你可以轻松把照片制作为充满设计感的影集视频，支持调整视频比例（1:1、16:9、9:16）、添加字幕（更换字体、颜色等）、替换背景音乐、添加视频LOGO等功能。

Windows客户端软件（3-4）

3、蜜蜂剪辑

蜜蜂剪辑制作电子相册教程：

【蜜蜂剪辑教程】如何制作相册MV_哔哩哔哩 (゜-゜)つロ干杯~-bilibiliwww.bilibili.com

蜜蜂剪辑是一款由傲软软件公司开发的专业视频剪辑软件，Windows、Mac都可使用。软件体积小，性能稳定，对电脑配置没有要求，素材多、易操作等主要特性深受视频up主们的喜爱，只需简单的几步操作就可以剪出创意满分的短片。

4、Adobe Premiere

Pr 是一款常用的视频编辑软件，兼容性与功能丰富度兼顾，对电脑配置有一定要求，下载使用前需要了解自己的电脑配置是否达标。

配置要求：
Windows

Intel® Core™2 双核以上或 AMD 羿龙®II以上处理器
Microsoft ® Windows®7 ServicePack 1或 Windows 10
4GB的 RAM（建议使用8GB）
4GB的可用硬盘空间用于安装;（无法安装在可移动闪存存储设备在安装过程中需要额外的可用空间）
需要额外的磁盘空间预览文件、其他工作档案（建议使用10GB）
1280x800+像素屏幕
7200 RPM或更快的硬盘驱动器（多个快速的磁盘驱动器，最好配置RAID 0或SSD固态硬盘，推荐）
声卡兼容ASIO协议或Microsoft Windows驱动程序模型
QuickTime的功能所需的QuickTime 7.6.6软件
可选：Adobe认证的GPU卡的GPU加速性能
互联网连接，并登记所必需的激活所需的软件，会员验证和访问在线服务。

【教程】制作简单的电子相册-第②弹-_哔哩哔哩 (゜-゜)つロ干杯~-bilibiliwww.bilibili.com

MacOS

多核Intel处理器
macOS10.10及更高版本
4GB RAM内存（建议使用8GB）
4GB的可用硬盘空间用于安装;（无法安装在使用区分大小写的文件系统上，或可移动闪存存储设备在安装过程中需要额外的可用空间）
需要额外的磁盘空间预览文件和其他工作档案（建议使用10GB）
1280x800+像素屏幕
7200转硬盘驱动器（多个快速的磁盘驱动器，优选RAID 0配置，推荐）
QuickTime的功能所需的QuickTime 7.6.6支持组件
可选： Adobe认证的GPU卡的GPU加速性能
互联网连接，并登记所必需的激活所需的软件，会员验证，访问在线服务。

Mac OS客户端软件（5-6）

5、iMovie

iMovie是一款由Mac编写的视频编辑软件，iMovie因为其界面功能的简洁而受到欢迎，大多数的视频编辑工作，只需要简单的点击和拖拽就能完成，同样物色了一个b站视频教程~

超轻松学剪辑！苹果认证专家带你探索 iMovie 视频剪辑的奥秘！_哔哩哔哩 (゜-゜)つロ干杯~-bilibiliwww.bilibili.com

6、Final Cut Pro X（FCPX）

FCPX是一款Mac专用的图像处理软件，利用它，你也可以很轻松地制作出一部精美电子相册。功能强大，最高支持8K清晰度的视频导出。

制作电子相册教程：

让你的照片动起来！教你如何用FCPX制作简单的视频相册_哔哩哔哩 (゜-゜)つロ干杯~-bilibiliwww.bilibili.com

和2个基本操作上手教程：

10分钟上手Final Cut Pro X，零基础新手快速入门，视频剪辑基本操作教学_哔哩哔哩 (゜-゜)つロ干杯~-bilibiliwww.bilibili.com 【Final Cut Pro 教程】全系列视频拍摄、剪辑与后期制作教程丨放牛班乌托邦出品【Final Cut Pro X 教程】【fcpx教程】www.bilibili.com

软件工程的最大难题 - 阮一峰的网络日志

Mon, 10 May 2021 12:43:30 CST

一、引言

大学有一门课程《软件工程》，研究如何组织和管理软件项目。

说实话，这门课不适合本科生，因为学生可能体会不到，课程到底要解决什么问题。只有亲身参与过大项目的开发，经历过大团队，才能感受为什么软件工程很重要，又很难做对。

软件开发有一个难题，叫做"扩展"（scaling），即怎样服务更多的用户。你有10000个并发用户，跟你有10个并发用户，这是完全不同的概念，哪怕功能完全相同，背后的实现是完全不一样的。并发用户数上升一个数量级，软件就必须重构，大量问题随之产生。

大项目的技术难度高，管理难度更高，而且大团队的生产率往往很低，行动缓慢。 《软件工程》就是研究，如何扩展软件和团队，适应大项目的需要。

国外有很多专著，研究这个问题。前些日子，我读到一篇文章，推荐了两本书。第一本叫做《加速：构建和扩展高性能技术组织》，第二本叫做《规模：生物，城市和公司的普遍法则》。

我看了这两本书的介绍，觉得很有启发，下面就做一些摘录。

二、大项目的困境

一个典型的大型软件项目，开发过程通常是下面这样。

最开始的时候，它是一个小项目，开发人员就是两三个人，甚至可能只有一个人。产品比较简单，功能很有限。

第一版发布后，拿给客户使用，反响不错。客户要求的新功能，能够很快开发出来，Bug 修补也很快，因为早期客户往往可以与开发人员直接沟通，快速反馈。

公司于是决定投入更多人员，开发这个项目。团队慢慢变大了，软件开始变得复杂，开发速度逐渐变慢了，2.0 版花费的时间比预期要长一点。Bug 的修复难度开始增加。总之，新功能的开发日程变久了。

公司的自然反应是进一步扩充团队。但是更多的新成员其实会降低其他人的生产率，一个普遍现象是团队规模越大，每个人的平均生产率越低。

几年以后，代码逐渐老化，复杂性不断增加，项目开始停滞不前。某些极端的情况下，软件的维护成本变得非常高昂，并且几乎不可能进行更改。

最终，这个项目成为技术债务，等待被新项目替换。

三、为什么大项目的开发效率低？

大项目就像一头大象，让人望而生畏。可是一旦需要奔跑，大象就会步履蹒跚，被猎犬远远甩在后头。它快不起来的原因有两个。

（1）代码复杂度

随着代码量的增长，单个开发者想要理解整个代码库，变得越来越困难。如果团队超过五个人，每个人负责一个功能，那么单个人几乎不可能追踪系统的所有工作进度。

当你中途加入团队，整个项目是一个紧密耦合的大型系统，你又不理解系统的每一个工作细节。这时，你就不太敢修改以前的代码，因为不知道随之而来的全部影响。

你不真正理解系统，也就不会感到自己是代码的主人。你会很犹豫要不要重构，过时的代码开始累积，技术债务就这样出现了。长此以往，开发变得越来越不愉快和令人无法满意，最终导致人才流失。后面接手的新人，更难于重构那些遗留下来的代码。

（2）团队原因

随着团队成员的增加，交流成本开始指数式上升。如果整个团队有 n 个程序员，为了了解其他人的工作，你需要跟 n - 1 个人逐一交流（口头或者书面），那么整个团队的交流路径总数就是 n * (n - 1) / 2。这意味着，交流成本的增长速度是人员增长速度的平方，团队人数越多，协同的难度就越大。

大团队保持扁平化管理，也会越来越困难，必须拆分成较小的群体。这时，对等的交流会被自上而下的交流所取代。团队成员会感觉，自己从平等的利益相关者，转变为普通的工作人员，工作动机受到了影响，责任感和主人翁意识都会淡漠。

管理层为了解决问题，会尝试组建新团队和新的管理架构。但是，不管怎么做，大型组织都很难保持所有成员的积极参与。

四、解决方法：代码解耦

大项目的开发效率不高，把这个问题归咎于程序员的技术水平低和管理不善，都是没用的。 根本原因是软件规模的增长，必然使得代码和团队变得笨重。除非很早就认识到问题的根据，采取缓解对策，否则前面描述的情况，迟早都会出现。

解决这个问题，要从代码和团队两方面着手。

代码层面的解决方法是，将软件解耦，拆分成组件或者模块，防止各个部分紧密地耦合在一起。每个组件和模块，都可以独立开发，通过公开的接口被其它部分调用。

这样的话，就大大减轻了开发者的负担，只需要负责自己的代码即可，不需要关心其他部分的实现。每个部分都可以单独重构，不担心影响到其他部分。

五、解决方法：团队解耦

除了代码解耦，团队层面也需要解耦，要把人员分开。

这可以参考互联网的架构。互联网是迄今为止最成功的大型软件解耦实例，它之所以能够扩展，是因为它由一个个独立的节点组成。为了防止节点之间互相依赖，各个节点都遵循以下规则。

遵守公开的通信协议。

不需要了解其它节点的内部实现，就可以与之通信。

节点之间不直接共享状态，只通过通信交换数据。

每个节点单独开发和部署。

大团队也应该遵循类似的原则，进行解耦。

每个子团队都可以独立运作，不依赖外部人员。

子团队内部的运作，不需要被外部知道。

子团队之间的协调，应该按照公开的协议和规则，最好能够自动完成，避免私下协商。

六、团队解耦的注意点

团队解耦有一些注意点。

（1）子团队的人数不宜过多，每个子团队最好不要超过5个人。

（2）子团队应该是一个小型的全功能软件开发组织。

很多大团队按照人员角色分组，比如架构组、开发组、DBA 组、测试组、工程组等等，这是错误的。这样完全没有解耦，还是瀑布式流程，各组之间依然互相依赖，工作时必须与别组单独协商。而且，可能会产生利益冲突，比如，开发组希望尽快交付，而测试组希望多一点时间测试。

正确做法是按照软件的业务功能分组，每组负责一个全流程的软件大功能，设计、编码、测试、部署、支持等人员都在同一组。这样才能做到解耦，以及独立的交付和重构。每组内部使用什么工具、如何实现某个功能，都是自己决定，各组之间不需要共享内部细节，也不依赖别组的工作。

（3）大团队应该保障子团队的自主权，按照子团队提供的功能和商业价值，进行资源分配。

（4）软件架构师的角色很重要。

软件架构师的关注点，不应该是团队使用的工具和技术，而是各种服务与整个系统运行状况之间的协议和通信，保证代码和团队可以正确解耦。

（5）代码解耦和团队解耦的关系。

理想情况下，代码解耦与团队解耦保持一致，形成一对一的关系，一个子团队负责一个独立的模块。实际运作中，一个子团队负责几个模块也可以，但是一个模块不能由多个子团队来参与。

（6）通信（模块之间的、子团队之间的）尽量规范化，争取做到过程简单、文档充分，最好有规范的 API，这样无需任何人员交流，就能建立通信。

（完）

软件开发管理的11条真理

Sun, 07 Mar 2021 16:06:44 CST

软件开发过程管理被比作放养猫。换句话说，你不能真的做到这件事，但你可以尽你最大的努力去做。再换句话说，软件项目就像试图在NBA防守勒布朗·詹姆斯(LeBron James)一样。你根本就阻止不了他，最多只能希望牵制到他。

软件项目的开发管理是一门不精确的科学，这不是什么秘密。以下是我这些年来学到的11条真理，它们帮助我理解了，要管理软件开发项目这个奇怪的世界，我们的能力是多么的有限。

1. 估算总是错误的

无论是你花一个小时还是一年的时间来做估算，估算结果都是错误的。事情本来就是这样的。结果不一定错得大相径庭，可能只错了那么一点点，但肯定还是错的。

如果你看到一份错误报告，并认为“修复它需要一个小时”，那么几乎可以肯定的是，它不会正好需要一个小时。它可能需要45分钟，也可能需要3个小时，但正好花上一小时的可能性很小，甚至可能仅仅相差一两分钟。现在，你可能会说，“大约一个小时”。这实际上是一个更好的估算，因为具体的、精确的估算是错误的。

眼下，对于一个可能只需要一个小时的短小项目来说，这不是什么大问题。但是…

2. 项目越大，你的估算就越不准确

项目越大，估算就越不精确，尤其是在项目一开始就做的估算。就像上例那个一小时的估算，如果你将一个项目估算为一年，那么它可能需要9个月或者36个月。在某些情况下，它甚至可能需要五年时间。没有办法知道这个项目是什么时候开始的。

项目越大，“未知的未知”就越多。通常项目越大，就会有越多的人参与。也就是说，随着项目规模的增加，会有更多的变量和更多的事情发生，而这些你根本就无法预料。所有这些事情都会增加项目的时间，而这些时间你一开始就不会做到计划里，原因很明显，你并不知道它们会发生。

3.注意力和专注力是我们最宝贵也是最稀缺的东西

在构建软件时，完成一个项目所需的最有价值的一件东西，就是团队中的开发人员以不受干扰的方式集中精力的能力。

分心的事情越少，团队的效率就越高。就是这么简单。软件开发经理的主要职责之一就是减少团队分心的次数和持续时间。

当软件开发人员不受干扰时，他们有很高的工作效率。当他们被打断时（无论是由于开会还是被人问问题或者其他的什么事情），他们会快速丧失工作效率。我们都知道“心流”，都知道进入并维持在“心流”状态有多困难。流动的时间就像黄金一样宝贵，应该予以保护。

4. 霍夫斯塔德定律是真理

霍夫施塔特定律是这么说的：

“即使你考虑到了霍夫施塔特定律,项目的实际完成时间也总是比预期的要长。”——维基百科（ https://en.wikipedia.org/wiki/Hofstadter%27s_law"）

这与估算有关，但值得注意的是这句格言的妙处。你可以虚报你的估算，因为你认为这样可以为你赢得完成任务的时间。你可以添加额外的因素，将“未知的未知因素”做到计划里，并增加你的估算，从而考虑到实际将比你认为的时间更长，但是最终，实际上完成一个项目仍然会比你认为的实际上更长的时间要更长。

5. 你不能加快软件开发，你只能限制其减慢的程度

这条真理对于一些管理者来说真的很难理解。软件需要多久就需要多久。没有办法让它更快。你可以要求团队投入更多的时间。你可以挥起鞭子、拿起大棒。你可以乞求、哄骗、恳求开发人员。你可以说，“但是，这应该只需要三个月啊！”但最后从长远来看，你无法提高软件开发团队的速度。

如果你开始意识到霍夫斯塔德定律的正确性并认为“我能让这些人工作得更快”那么你就错了。你所能做的就是减少他们的干扰，让他们自主工作，从而防止他们降低工作速度。这个区别很微妙，但却很重要。

6. 你只能在非常短的时间内出现赤字

同样地，你可以要求团队投入更多的时间，熬夜、周末加班，以及种种“鞭笞”的手段，你可能会从中获得一些(非常)短期的收益。

但如果你试图让它成为一种常态，如果你试图让团队的引擎始终在RPM的红线上运行，它就会被烧坏。很快，你就会看到收益递减。人，就像赛车上的引擎一样，不能长时间承受过多压力，否则就会出现故障。

7. 大脑时间比屁股时间更重要

没有什么比要求工作时长更能降低生产力了（例如，你的开发人员要连续几个小时坐在椅子上）。你可以度量工作时长，感觉得到了一个能够真正显示出人们工作效率的指标。但是这样做就错了。要求工作时长只会使团队士气低落，因为他们实际上是想把时间花在思考上。

大脑时间才是最重要的。你这样想：假设你是一位经理，对于你来说最重要的是看到团队坐在电脑前“工作”。你在办公室里走来走去，看着那些开发人员坐在椅子上敲击着键盘。真是一番繁荣景象。

但之后你偶然发现一些开发人员只是坐在那里盯着屏幕。就是这样傻坐着，他们只是坐在那里傻看。搞什么鬼！大概半个小时，他们什么都没做！

但是，他们确实是在工作。他们正在思考。他们在用大脑思考解决一个非常困难的问题。也许他们甚至会站起来，在办公室里转上一圈。最后，他们坐下来，写下11行代码，并将用户故事标记为完成。

他们符合你的“屁股时间”标准吗？不符合。他们是否为一个非常困难的问题想出了一个巧妙的解决方案？是的。

屁股时间证明不了什么。大脑时间意味着一切。

8. 硬件比开发人员的时间更便宜，而且要便宜得多

开发人员其实很贵的。要吸引顶尖人才，你就得支付有竞争力的薪水。他们每一个小时的时间都不便宜。尽管如此，许多公司并没有意识到开发人员这一个小时的时间具有极高的价值，舍不得为团队提供硬件。

还是算了吧，电脑很贵的！额外的内存会让硬件预算超标的！

好吧，可能是会超出预算，但那是因为你的预算有问题！

现在我们来算一笔账：假设你每年付给每名开发人员10万美元，或者每小时大约50美元。假设他们每天花一个小时等待编译器完成工作。然后，假设你可以为开发人员的机器添加一些内存和更快的处理器，将等待编译的时间减少到每天45分钟。那么一名开发人员每天就能节省15分钟。以一年200天计算，也就是总计50个小时。按每小时50美元计算，每名开发人员每年可节省2500美元。如果速度更快的机器的增量成本是500美元，结果如何呢？

我们来算一下。如果你有20个开发人员，那么用更快的机器反而会为你节省4万美元的投资。口算应该就能算得出来。

这只是为了减少编译时间的等待。另外，做其他事情的速度也都会更快。

如果你的预算不允许更快的机器，那么就需要调整你的预算。

9. 你不能度量软件开发人员的生产力

就这一主题我曾写过一篇文章"。

可以这么说，试图以一种客观的方式衡量开发人员的生产力是徒劳的，根本就不应该这样做。有一些方法可以从主观上度量生产力，但这些方法需要经验和良好的判断。这些能力都很难得到，一旦拥有它们，就能为你带来非常宝贵的价值。

10. 如果你没有读过《人件》，那么你就不是一个真正的软件开发经理

在我看来，只有一本书能教你如何管理软件开发人员：那就是由 Tom DeMarco和Timothy Lister一起编写的《人件" 》"(一定要选择第三版……)。

这本书非常优秀，见解深刻，一针见血，条理清晰，毫无保留。这本书里面充满了管理软件项目和软件开发人员的智慧。它是永恒的经典之作。

快快找来读一读吧！

11. 质量是一种认知，而不是缺陷数量

这一点真的让人很难接受。

基本前提是：你的缺陷管理工具中的缺陷已经趋近于零，而人们却仍然可以认为你的软件有缺陷。你的缺陷管理工具中可能有大量的缺陷，而人们却可以认为你的软件像磐石一样坚固。缺陷管理工具中的缺陷数量与软件质量之间没有关系。

在此，我并不是说你不应该尝试减少你的缺陷数量，而是恰恰相反。但是最终，你的软件只有在你的客户认为它质量够高的时候才可以说它是高质量的，而你的缺陷数量不一定能说明这一点。很奇怪，是吧？

当我们谈到这个话题时，“高”的缺陷数量意味着什么？如果你的代码库有100,000行代码，“高”的定义是什么？那么500万行代码呢？谁说的？

结论

即使在最好的情况下，让一个软件项目在短跑道上安全着陆也是一个具有挑战性和困难的命题。在这个过程中，再加上一些模棱两可，再加上一些随时可能出错的定时炸弹，成功才是奇迹。

诀窍在于接受和理解这些模棱两可，并与之和谐相处，而不是与之对抗。接受这11条真理将有助于解决这一问题。

原文链接：

11 Things I’ve Learned About Software Development Management"

译者简介：

冬雨，小小技术宅一枚，从事研发过程改进及质量改进方面的工作，关注编程、软件工程、敏捷、DevOps、云计算等领域，非常乐意将国外新鲜的IT资讯和深度技术文章翻译分享给大家，已翻译出版《深入敏捷测试》、《持续交付实战》。

[原]Lehman的软件演化定律

Wed, 17 Feb 2021 17:19:14 CST

自20世纪70年代以来，M. M. Lehman通过对软件系统演化现象的观察，陆续总结了8条定律，称之为定律并非那么严谨，但是对于认识软件维护的规律，改进软件维护的过程具有很好的指导意义。

1 （1974年）持续变更定律。系统必须持续调整以适应各种变化，否则这些系统将变得越来越不令人满意。

2 （1974年）复杂度增长定律。随着系统的演化，其复杂度会逐渐增加，除非采取措施来降低或保持其复杂度。

3 （1974年）自我调整定律。软件演化过程的是自调整的，每次演化版本的度量数据近似正态分布。

4 （1978年）组织稳定性守恒定律。尽管软件开发组织随着时间的推移会发生变化，但软件演化过程的总体生产率是基本稳定的。

5 （1978年）熟悉度守恒定律。系统的每次更新量保持稳定。系统所需完成的更改越多，维护人员掌握所有更改所需的技能和知识就越困难，这会减缓系统的更新速度。

6 （1991年）持续增长定律。在系统生存周期内，系统功能数量必须持续增加才能维护客户满意度。

7 （1996年）质量下降定律。随着软件的不断演化，系统质量看起来会下降。

8 （1996年）反馈系统定律。系统演化过程是一个多循环、多代理、多层次的反馈系统。反馈来自于多个方面，如用户、业务领域、环境、系统本身等，系统需要对这些反馈作出反应，随着系统的老化，复杂度的增加，变更往往变得越来越困难。

作者：dylanren 发表于 2021/02/17 17:19:14 原文链接 https://blog.csdn.net/dylanren/article/details/113835828

阅读：21

为什么开发一款软件只要 3 个月，开发一款硬件却要一年

Thu, 07 Jan 2021 08:28:23 CST

背景

我们公司在软件开发上的速度极快：

2012 年猿辅导公司刚成立的时候，想做一款教育微博，我们花了 3 个月的时间做完上线。
2013 年我们想做猿题库，我们花了 2 个月的时间做完上线。
2014 年我们想做小猿搜题，我们仅花了 1 个月时间，就完成了功能开发。

而我们在开发斑马点读笔（题图）的时候，前后却花了将近 10 个月的时间，远远超过软件开发的时间。

2020 年我们有多款在研的硬件产品，我们试图压缩硬件产品的研发周期。但是执行下来发现，在极端顺利的情况下，也需要 6 个月的开发周期。稍有一些意外，就可能拖到 8 个月甚至 10 个月才能完成量产。

教育硬件还算简单的，我们再来看看手机产品。熟悉苹果的朋友都知道，苹果一般需要花 2 年时间，才能发布一个全新的手机设计。中间间隔的那一年，苹果仅仅会做一个小改款，升级一下 CPU 主频或者摄像头像素，整体的设计并没有什么变化。

问题

为什么硬件研发的周期远高于软件研发呢？

答案

原因一：硬件的链条长，环节复杂，但是对调整的容忍度低

软件研发的时候，最后一刻有严重 Bug，我们可以熬熬夜修好再上线。上线之后有小问题，我们可以在几天之后发布一个小版本升级。所以，软件可以用 Scrum 来快速迭代，业界常见的迭代周期是两周一次发布。

硬件如果最后一刻发现有严重的 Bug，那么不好意思，你需要重新制作模具。而不算模具的修改评审时间，仅仅开模的时间通常都需要 30 天左右。而开模前还需要重新做结构设计的调整，开模之后需要重新试模，外观调整之后可能涉及的 IC 排布的调整，包装设计的调整，3C 重新认证，运输测试重做等等，基本上相当于一夜回到解放前。

打个比方，硬件的外观大的调整有点类似于大家玩陶瓷，你好不容易做好了，进熔炉烧制好了，然后你发现有一个设计缺陷，那这个陶瓷只能完全报废掉了。

不止是硬件部分，电子部分的调整其实也很难。教育硬件产品通常逻辑不复杂，为了节省成本和功耗，硬件产品的逻辑通常使用掩模的工艺来进行烧录。这种烧录的能力现在还是集中在台湾地区，所以烧录时间要好几周。而且烧录有量的要求，一次烧录的起订量通常是 5K 左右的。

如果你研发到量产阶段，才发现有一个逻辑要修改，那么对不起，整个 IC 部分至少 5000 的起订量需要报废掉重做，重做周期可能好几周。这还没有算上 PCBA 电路板的重新贴片带来的时间成本。

所以，硬件的外观、电子逻辑在研发过程中的调整，都可能对整个产品的研发进度产生极大的影响。

为了防止这种事件发生，硬件在研发环节中，加入了多次的确认和检查，比如在开模之前先做 EVT 验证，又比如工业（ID）设计和结构（MD）设计做出来要打手板验证等。于是，我们就有了一个相对来说比较复杂的项目管理流程。

下图是小米公司的项目计划模版，可以看出一个硬件的研发牵扯的环节非常多。稍微不注意就会有差错。

即便这样，也还是很容易出错。我们在实践中，单单在包装工程上就出现过多次失误。比如和供应商时，不能很好地控制包装方案与成本；又比如设计的包装不利于运输，使得物流箱的成本变得很高。又或者打样的时候来回多次沟通，每次都打样不到位等。

但就像只要有程序就一定有 Bug 一样，硬件研发过程很难保证一定是完美的。所以如果有大问题只能召回或者报废，小问题只能忍着先发布，下一版再迭代。iPhone 每一代新品发布，就还是伴随着一些问题，历史上最有名的是 iPhone 4 的死亡之握，最终苹果没办法，所有人免费送了一个手机壳才解决。

原因二：硬件的资金成本更高

硬件当前的 3D 打印技术和电子电路的技术，仅可以用来做用户试用，验证一些功能设计上的问题。

但是硬件产品从一个高保真的原型手板到量产，其实需要克服很多工艺上的问题，在这个过程中，就需要花很多钱。这些钱都是需要摊薄到未来的大规模量产上的，否则就很不经济。

打个比方，我们做一款玩教具，假设这个玩教具的开模费用是 20 万，那么如果我们只生产 2000 台，那么摊到每台上的模具费用都有 100 块钱。而一个模具通常可以用 50 万次，正常量产后的每台玩教具的模具费用只有 0.5 元。这里面差了 200 倍的成本。

所以为了把产品的成本控制下来，同时也为了保证开模注塑工厂的利益（不然别人不跟你玩），通常首批玩教具生产的量都需要是 5000 左右的，这就是一笔不小的投入费用。

IC 的部分也一样，掩模烧录的起订量通常也是 5000，这也是一笔不小的费用。

最后假设我们什么都很顺利，花 20 万开了模，做了 5000 套玩具，假设每款玩具的制造成本是 100 块，那么一共就花了 70 万元。

硬件第一批产品出去后，多多少少会有一些问题，这个时候你就需要尽快把存货卖出去，否则你回收不回来资金，很难启动第二轮的生产。我看《马斯克传》，当年 Tesla 的第一代车就是因为有很多小毛病差点卖不出去，最终他没办法让所有员工都出去卖车，才逃过一劫。乐视当年做手机，手机卖不出去，最后好多都直接送出去，因为放在仓库里面电池亏电太久也报废了。

第一代产品有小毛病没卖好，资金又都压在存货上，有大量公司都被库存和资金周转搞死了。

小结

硬件研发链条长，在研发过程中的任何调整，都可能对整个产品的研发进度产生极大的影响。
硬件的研发需要基础量和开模，使得资金门槛高，给后续库存和资金周转带来挑战。