性能优化 on 庞玉栋个人博客

《2026年中国人工智能计算力发展评估报告》发布，智能体重塑算力基础设施，智能算力规模预计增长87.9%

Tue, 22 Sep 2026 01:07:01 +0800

原文：《2026年中国人工智能计算力发展评估报告》发布，智能体重塑算力基础设施，智能算力规模预计增长87.9%

作者：李冬梅

来源：InfoQ 中国（架构）

正文

9 月 21 日，国际数据公司（IDC）与浪潮信息联合发布《2026 年中国人工智能计算力发展评估报告》（以下简称《报告》）。作为业内首份聚焦智能体基础设施的研究报告，《报告》指出，智能体（Agent）正在重塑算力基础设施，以乘数效应推动 Token（词元）消耗激增，带动中国智能算力规模斜率大幅上调，算力跃升为与水利、电网、铁路等同等级的国家战略基础设施。

IDC 预测，全球活跃智能体数量将从 2026 年的 7940 万个增长至 2030 年的 22.16 亿个，复合增长率达到 129.8%。随着智能体任务从简单的信息检索、内容生成，向需要多轮推理、工具调用和跨系统协作的复杂任务演进，Token 消耗被指数级放大。同期全球 Token 消耗量复合增长率达 4822.6%，约为活跃智能体数量增速的 37 倍。中国增长同样显著，2026-2030 年中国活跃智能体数量复合增长率达 151.2%，同期中国 Token 消耗量的复合增长率高达 3499.3%。

智能体数量与 Token 消耗的快速增长，正带动算力需求持续攀升。2026 年中国智能算力规模预计达到 2576.5 EFLOPS，同比增长 87.9%，到 2030 年将进一步达到 10524.3 EFLOPS；2025-2030 年智能算力规模复合增长率由上一版本预测的 46.2%提升至 50.3%。同时，中国人工智能算力市场规模将在 2026 年达到 515 亿美元，同比增长 37%，并在 2030 年达到 1501 亿美元，2025-2030 年复合增长率达 31.8%。

中国智能算力规模及预测，2020-2030

《报告》围绕智能体规模化带来的新一轮算力变革，从算力供需、Agent 基础设施重构、行业 AI 应用成熟度及区域 AI 算力发展格局等多角度展开研究，分析智能体如何推动人工智能在模型能力持续演进的基础上，加速走向规模化应用，并进一步重塑中国人工智能算力产业的发展路径。

智能体重塑城市 AI 格局，北京、杭州、深圳位列前三

智能体加速进入生产和业务流程，正在改变城市 AI 算力竞争的评价逻辑。《报告》首次将智能体应用落地、具身智能产业布局、大模型开发以及推理算力基础设施等纳入城市人工智能算力发展水平的关键评价指标。

Altum：蚂蚁集团新一代大模型训练数据处理系统设计与实践｜QCon上海

Mon, 21 Sep 2026 18:00:00 +0800

原文：Altum：蚂蚁集团新一代大模型训练数据处理系统设计与实践｜QCon上海

作者：QCon全球软件开发大会

来源：InfoQ 中国（架构）

正文

从「构建 AI」到「驾驭 AI」，100+ 实战案例拆解 AI Native 时代的工程新实践！

推理模型持续突破能力边界，Coding Agent 深度参与研发流程，Agent Runtime、Agent Framework 快速演进……AI 正在从回答问题的模型，演变为能够自主规划、调用工具、执行任务的软件系统。AI 不再只是软件中的一个能力，而开始成为软件系统的一部分。这意味着软件工程面对的挑战也发生了变化：团队需要思考的不再只是如何训练模型、模型、部署模型或优化 Prompt，而不是如何让具备自主能力的 AI 稳定、可信、可控地运行。模型决定 AI 能做什么，系统决定 AI 能否真正创造价值。

在这一背景下，2026 年 QCon 全球软件开发大会大会 · 上海站正式启动。本次大会将于 10 月 22 日—24 日举办，聚焦 Harness AI 时代的工程实践，围绕 AI Native 架构、Agent Runtime、AI Infra、Data Systems、Agent 安全与可观测、Loop Engineering、Vibe Coding、具身智能与世界模型、端云协同等前沿技术方向，邀请全球技术社区与产业一线的实践者，系统性分享前沿洞察与实战经验，共同探索 AI 从能力到系统、从实验到生产的真实路径。

蚂蚁集团 & 大模型训练数据处理系统 Altum 技术负责人王鑫已确认出席 “AI Infra：算力效率决定规模化落地” 专题，并发表题为《Altum：蚂蚁集团新一代大模型训练数据处理系统设计与实践》的主题分享。在大模型训练数据规模持续提升、模型迭代效率持续加快的背景下，业界在模型数据处理的 GPU 效能、任务稳定性、数据交付时效等方面面临巨大挑战。蚂蚁通过新一代大模型训练数据处理系统 Altum 的建设，尝试系统化解决这些问题。本次分享将重点介绍在性能、稳定性、效率等方面提升的关键技术策略和背后的思考与取舍，以及业务生产实践案例。

Apache Member（Apache 软件基金会成员），多个 Apache 顶级项目的 PMC Member、Committer，多个 Apache 孵化器项目的 Mentor。蚂蚁集团新一代大模型训练数据处理系统 Altum 技术负责人、实时智能技术负责人。加入蚂蚁集团前曾就职于阿里巴巴，并参与大数据领域早期创业。具备数据智能领域引擎、平台、数据解决方案的复合背景，当前重点关注 AI Data Infra 的建设。

单个机柜到底能跑多少个 Agent？答案不在 GPU 身上

Sat, 19 Sep 2026 18:55:19 +0800

原文：单个机柜到底能跑多少个 Agent？答案不在 GPU 身上

作者：李文朋

来源：InfoQ 中国（架构）

正文

过去几个月，大厂接连发布了新一代基础模型。Claude Fable 5.1、Gemini 3.8 Flash 与 GPT-6 Astra 等层出不穷。

不难看出，这些模型几乎都在追求 Agent 的适配能力，让整个推理时间更长，工具调用更顺，决策链条也更稳。

这也让 Agent 加速进入企业端。数据显示，2026—2027 年，中国企业场景中的活跃智能体（Agent）数量单年同比增长超 200%，到 2031 年预计可达到 3.5 亿个。

值得注意的是，这种全民狂欢的背后，数据中心正面临巨大的挑战。

现有数据中心基础设施，基本都是为大模型单次推理调用的吞吐量而设计的，并未真正考虑过 Agent 那种高频、突发、有状态，并且工具调用穿插其中的工作负载。

谷歌最近的调研提出，近 83% 的企业高管认为基础设施需要为 Agent 时代重新调整。前不久，AMD 也表示 CPU 和 GPU 的配比要重新调整；8 月，AWS 和 NVIDIA 更是宣布，要联手搞下一代 AI 基础设施。

然而，这些说法更多是围绕输入端的能力参数——比如有多少核心、多少带宽、在功率上限下能运行多少节点。

英特尔在 8 月发布的一份白皮书中，却表明了不同的立场。英特尔提出，对数据中心进行优化的关键，并不在于提升理论参数值，而是考虑它在实际应用场景下，满足延迟承诺时，能够维持多少 Agent 的任务量。

一句话说就是：“去计算数据中心的实际工作量，而不是理论的性能上限。”

这是一个系统级的论点。对于还在摸索 Agent 生产到底需要什么基础设施的行业来说，不失为值得认真对待的思路。

预告：在 9 月 22 日～23 日，英特尔将会在苏州举办 2026 年 Intel Connection 大会，会上会展示最新的 DCG 产品，以及面向企业 AI 应用落地场景的对应产品。那里或许也有行业所寻求的解决方案。

华为全联接大会2026：360与昇腾AI联合打造解决方案，为AI Agent全面提速

Sat, 19 Sep 2026 09:58:00 +0800

原文：华为全联接大会2026：360与昇腾AI联合打造解决方案，为AI Agent全面提速

来源：雷锋网（AI 媒体）

正文

2026年9月17日，第十一届华为全联接大会在上海开幕。大会期间，360集团与昇腾AI联合打造解决方案。以360智能体工厂为核心的智能体基础设施与昇腾AI深度协同，面向AI Agent场景实现全面提速，为复杂任务执行、多智能体协作和长链路推理提供更高效、更稳定的底层支撑。这也是双方继2026世界人工智能大会联合展示后，合作成果的进一步深化落地。

图说：华为全联接大会期间360与昇腾AI展台

作为360智能体基础设施的核心组件，360智能体工厂承担智能体生成与编排职能，支持通过自然语言快速生成智能体并组建多智能体协作蜂群。其首创的“蜂群多智能体协作技术”支持多智能体多层嵌套、灵活组队与共享协作记忆，实现任务自主规划与协同执行，使原本需要2小时的多角色协作任务缩短至20分钟，效率提升6倍。

随着AI Agent从单轮问答迈向复杂任务执行，异步并行、多智能体协同、长上下文推理以及高频工具调用逐渐成为主流应用形态。Agent运行过程中需要持续进行任务拆解、规划决策、工具调用和结果反馈，这对底层算力平台的稳定性、吞吐能力和响应速度提出了更高要求。

针对智能体场景中的长序列推理和频繁KV Cache读写等挑战，昇腾AI进行了针对性性能优化，通过长序列优化、吞吐优化、运行时优化及算子优化等能力提升，有效降低首Token时延，提升整体吞吐效率，为高并发、长链路Agent任务提供稳定支撑。

在深度理解、通用理解和智能体执行等典型场景中，搭载DeepSeek、Qwen、GLM等主流模型时，昇腾AI已具备良好的开箱性能，经过进一步优化后实现整体性能提升。基于昇腾AI算力支撑，360智能体工厂在内测过程中已实现超过1000步复杂任务连续执行不中断，任务成功率达到95%以上。同时，360智能体工厂采用透明化人机协同机制，将智能体的思考过程、任务规划路径和执行状态全程可视化，让用户能够实时掌握任务进展与执行结果，而底层毫秒级响应能力则为这一体验提供了坚实保障。

图说：360智能体工厂与昇腾AI合作路径示意

当前，AI产业正从“大模型竞争”逐步走向“智能体竞争”。智能体的价值不仅取决于模型能力，更依赖于模型、工具、工作流与算力基础设施之间的协同效率。此次360与昇腾AI联合打造解决方案，正是智能体基础设施与国产AI算力协同发展的又一次实践探索。

未来，双方将持续推进智能体基础设施与国产AI算力生态融合创新，为AI Agent规模化应用提供更高效、更稳定的底层支撑，助力更多企业加速迈向AI时代。

由「前沿雷达」于 2026-09-20 采集。正文取自原文页面，已保留出处链接。标题与正文版权归原作者所有。

服务端 I/O 性能大比拼：Node、PHP、Java 和 Go

Sat, 14 Oct 2017 19:47:46 +0800

理解应用程序的输入/输出（I/O）模型，意味着其在计划处理负载与残酷的实际使用场景之间的差异。若应用程序比较小，也没有服务于很高的负载，也许它影响甚微。但随着应用程序的负载逐渐上涨，采用错误的I/O模型有可能会让你到处踩坑，伤痕累累。

正如大部分存在多种解决途径的场景一样，重点不在于哪一种途径更好，而是在于理解如何进行权衡。让我们来参观下I/O的景观，看下可以从中窃取点什么。

在这篇文章，我们将会结合Apache分别比较Node，Java，Go，和PHP，讨论这些不同的语言如何对他们的I/O进行建模，各个模型的优点和缺点，并得出一些初步基准的结论。如果关心你下一个Web应用的I/O性能，那你就找对文章了。

I/O基础知识：快速回顾

为了理解与I/O密切相关的因素，必须先来回顾在操作系统底层的概念。虽然不会直接处理这些概念的大部分，但通过应用程序的运行时环境你一直在间接地处理他们。而关键在于细节。

系统调用

首先，我们有系统调用，它可以描述成这样：

你的程序（在“用户区域”，正如他们所说的）必须让操作系统内核在它自身执行I/O操作。
“系统调用”（syscall）意味着你的程序要求内核做某事。不同的操作系统，实现系统调用的细节有所不同，但基本的概念是一样的。这将会有一些特定的指令，把控制权从你的程序转交到内核（类似函数调用但有一些专门用于处理这种场景的特殊sauce）。通常来说，系统调用是阻塞的，意味着你的程序需要等待内核返回到你的代码。
内核在我们所说的物理设备（硬盘、网卡等）上执行底层的I/O操作，并回复给系统调用。在现实世界中，内核可能需要做很多事情才能完成你的请求，包括等待设备准备就绪，更新它的内部状态等，但作为一名应用程序开发人员，你可以不用关心这些。以下是内核的工作情况。

阻塞调用与非阻塞调用

好了，我刚刚在上面说系统调用是阻塞的，通常来说这是对的。然而，有些调用被分类为“非阻塞”，意味着内核接收了你的请求后，把它放进了队列或者缓冲的某个地方，然后立即返回而并没有等待实际的I/O调用。所以它只是“阻塞”了一段非常短的时间，短到只是把你的请求入列而已。

这里有一些有助于解释清楚的（Linux系统调用）例子：-read()是阻塞调用——你传给它一个文件句柄和一个存放所读到数据的缓冲，然后此调用会在当数据好后返回。注意这种方式有着优雅和简单的优点。-epoll_create()，epoll_ctl()，和epoll_wait()这些调用分别是，让你创建一组用于侦听的句柄，从该组添加/删除句柄，和然后直到有活动时才阻塞。这使得你可以通过一个线程有效地控制一系列I/O操作。如果需要这些功能，这非常棒，但也正如你所看到的，使用起来当然也相当复杂。

理解这里分时差异的数量级是很重要的。如果一个CPU内核运行在3GHz，在没有优化的情况下，它每秒执行30亿次循环（或者每纳秒3次循环）。非阻塞系统调用可能需要10纳秒这样数量级的周期才能完成——或者“相对较少的纳秒”。对于正在通过网络接收信息的阻塞调用可能需要更多的时间——例如200毫秒（0.2秒）。例如，假设非阻塞调用消耗了20纳秒，那么阻塞调用消耗了200,000,000纳秒。对于阻塞调用，你的程序多等待了1000万倍的时间。

内核提供了阻塞I/O（“从网络连接中读取并把数据给我”）和非阻塞I/O（“当这些网络连接有新数据时就告诉我”）这两种方法。而使用何种机制，对应调用过程的阻塞时间明显长度不同。

调度

接下来第三件关键的事情是，当有大量线程或进程开始阻塞时怎么办。

出于我们的目的，线程和进程之间没有太大的区别。实际上，最显而易见的执行相关的区别是，线程共享相同的内存，而每个进程则拥有他们独自的内存空间，使得分离的进程往往占据了大量的内存。但当我们讨论调度时，它最终可归结为一个事件清单（线程和进程类似），其中每个事件需要在有效的CPU内核上获得一片执行时间。如果你有300个线程正在运行并且运行在8核上，那么你得通过每个内核运行一段很短的时间然后切换到下一个线程的方式，把这些时间划分开来以便每个线程都能获得它的分时。这是通过“上下文切换”来实现的，使得CPU可以从正在运行的某个线程/进程切换到下一个。

这些上下文切换有一定的成本——它们消耗了一些时间。在快的时候，可能少于100纳秒，但是根据实现的细节，处理器速度/架构，CPU缓存等，消耗1000纳秒甚至更长的时间也并不罕见。

线程（或者进程）越多，上下文切换就越多。当我们谈论成千上万的线程，并且每一次切换需要数百纳秒时，速度将会变得非常慢。

然而，非阻塞调用本质上是告诉内核“当你有一些新的数据或者这些连接中的任意一个有事件时才调用我”。这些非阻塞调用设计于高效地处理大量的I/O负载，以及减少上下文切换。

到目前为止你还在看这篇文章吗？因为现在来到了有趣的部分：让我们来看下一些流利的语言如何使用这些工具，并就在易用性和性能之间的权衡作出一些结论……以及其他有趣的点评。

请注意，虽然在这篇文章中展示的示例是琐碎的（并且是不完整的，只是显示了相关部分的代码），但数据库访问，外部缓存系统（memcache等全部）和需要I/O的任何东西，都以执行某些背后的I/O操作而结束，这些和展示的示例一样有着同样的影响。同样地，对于I/O被描述为“阻塞”（PHP，Java）这样的情节，HTTP请求与响应的读取与写入本身是阻塞的调用：再一次，更多隐藏在系统中的I/O及其伴随的性能问题需要考虑。

为项目选择编程语言要考虑的因素有很多。当你只考虑性能时，要考虑的因素甚至有更多。但是，如果你关注的是程序主要受限于I/O，如果I/O性能对于你的项目至关重要，那这些都是你需要了解的。“保持简单”的方法：PHP。

回到90年代的时候，很多人穿着匡威鞋，用Perl写着CGI脚本。随后出现了PHP，很多人喜欢使用它，它使得制作动态网页更为容易。

PHP使用的模型相当简单。虽然有一些变化，但基本上PHP服务器看起来像：

HTTP请求来自用户的浏览器，并且访问了你的Apache网站服务器。Apache为每个请求创建一个单独的进程，通过一些优化来重用它们，以便最大程度地减少其需要执行的次数（创建进程相对来说较慢）。Apache调用PHP并告诉它在磁盘上运行相应的.php文件。PHP代码执行并做一些阻塞的I/O调用。若在PHP中调用了file_get_contents()，那在背后它会触发read()系统调用并等待结果返回。

当然，实际的代码只是简单地嵌在你的页面中，并且操作是阻塞的：

关于它如何与系统集成，就像这样：

相当简单：一个请求，一个进程。I/O是阻塞的。优点是什么呢？简单，可行。那缺点是什么呢？同时与20,000个客户端连接，你的服务器就挂了。由于内核提供的用于处理大容量I/O（epoll等）的工具没有被使用，所以这种方法不能很好地扩展。更糟糕的是，为每个请求运行一个单独的过程往往会使用大量的系统资源，尤其是内存，这通常是在这样的场景中遇到的第一件事情。

注意：Ruby使用的方法与PHP非常相似，在广泛而普遍的方式下，我们可以将其视为是相同的。

多线程的方式：Java

所以就在你买了你的第一个域名的时候，Java来了，并且在一个句子之后随便说一句“dot com”是很酷的。而Java具有语言内置的多线程（特别是在创建时），这一点非常棒。

大多数Java网站服务器通过为每个进来的请求启动一个新的执行线程，然后在该线程中最终调用作为应用程序开发人员的你所编写的函数。

在Java的Servlet中执行I/O操作，往往看起来像是这样：

由于我们上面的doGet方法对应于一个请求并且在自己的线程中运行，而不是每次请求都对应需要有自己专属内存的单独进程，所以我们会有一个单独的线程。这样会有一些不错的优点，例如可以在线程之间共享状态、共享缓存的数据等，因为它们可以相互访问各自的内存，但是它如何与调度进行交互的影响，仍然与前面PHP例子中所做的内容几乎一模一样。每个请求都会产生一个新的线程，而在这个线程中的各种I/O操作会一直阻塞，直到这个请求被完全处理为止。为了最小化创建和销毁它们的成本，线程会被汇集在一起，但是依然，有成千上万个连接就意味着成千上万个线程，这对于调度器是不利的。

程序员，如何从平庸走向理想？

Fri, 25 Aug 2017 21:10:04 +0800

我算是靠坑蒙拐骗进了程序员的门，然后一路狂奔。26 岁之前几乎没有任何写代码的经验，研究生毕业却意外选择了一家不可能提供培训的初创公司，在每日担忧公司倒闭、害怕被炒鱿鱼以及同事冷落白眼的三重压力下逆流而上，一年半后离职，已是拥有 500 万用户产品的后台主程。从前我对计算机技术心怀畏惧，认定技术高人一定有佛光笼罩，昼夜不息运键如飞日吐代码上万行。现在也算见过一些世面了，回首那段忐忑不安宛如初夜的过程，我却不发觉有任何的励志意味，而是视为一种理所当然。理想的程序员，和理想的建筑师、理想的财务师、理想的按摩师没有任何的差别，他们本质上都是一群手艺人。我相信理想的程序员人人皆可成为。

近三年总在互联网圈厮混，我认识过一些程序员，共事过一些程序员，领导过一些程序员，又面试过一些程序员。他们学历不同，有的来自北大，有的来自北大青鸟，有的是博士，有的是高中肄业；资历也不同，有的来自 BAT，有的来自某破产基金公司（还是一个销售）；年限也从 0 到 15 年不等。但我认为程序员只需分三类：天才的程序员、理想的程序员、平庸的程序员。天才的程序员我只敢说接触过 3 个，这是天命。7 分由你是颗精子的时候就已决定，拥有绝佳的数学天赋、冷静致密的逻辑、为解决难题宁愿不眠不休而深以为乐的技术热情；3 分来自起步要早早早，恨不得同龄人玩泥巴的时候就得开始玩电脑，大学毕业前就突破一万小时法则，后面的已是游戏人生。

天才的程序员可遇不可求，更不能长有，我看到的 90% 仍是平庸的程序员。IT时代的膨胀，已让程序员如同文艺复兴时的印刷匠一样的普通，多数投入祖师爷门下的人，仅是为了更大的饭碗，更高的待遇，更好的生计。平庸的程序员编写腐烂的代码，没有规范和一致性，固守旧世界的语言，还好谈论大的架构和性能，说的比做的漂亮。而毫无例外的，他们认定技术没有出路，做产品、营销和管理的是更高大上的手艺，而他们当中的 99%，又会自然的流露出自己恰巧具备了那方面的天赋，至于进程为什么会崩溃这样的小问题是不屑于去了解的。

而我最喜欢和理想的程序员相处，恨不得与他们同吃同住，如果允许，我希望我的队伍能插满他们的旗帜。理想的程序员心眼儿不坏（他们从来都不是办公室政治的宠儿，是一群单纯明亮快乐的手艺人），有天真烂漫的好奇心（他们的眼睛里经常闪着「哇，这个是怎么做到的！」），永远精益求精（他们的口头禅是「我再研究一下」），还乐于分享（他们活跃于 GitHub、各大问答社区和你的身边，舍得将宝贵时间用于帮助新手）。是的，他们不需要被管理，只需要给一个大的方向，总能回报以意想不到的结果。

理想的程序员与平庸的程序员只有一墙之隔。两者的差距只有 6 个一点点，而人与人的差距，正是在这日积月累的一点点中，被永远拉开了。有意思的是，我发现这6个一点点都和意识有关，也就是程序员和其他一切新兴产业的工种一样，只需要意识加上时间的锤炼，人人皆可达到理想的阶段。理想的程序员必然也是一个优秀的 problem-solver.

第 1 个一点点：专注眼下

见过太多心猿意马的程序员，我不得不把「专注眼下」作为天字第一条。他们往往有各式各样的小梦想，比如做个小茶农、做个小鹅贩、做产品、做销售、做投资，却被程序员的高薪或是没有转行的魄力「耽误」了，而因为不专注，他们不在意做好自己的本分，不在意锤炼自己的技能，不在意学习新兴的技术。不可否认，这世界上存在着伟大的产品（像乔老爷）、伟大的销售（像埃里森）、伟大的投资客（像彼得菲），而他们毫无例外都是程序员出身。可你听说过巴菲特评价盖茨的话么，比尔盖茨如果转行去卖狗，那他一定是全世界最大的狗贩。我坚信除了少数的天才外，冥冥众生均可以在多个领域取得成功，只要保持足够的专注。而哪怕你下一年就想卖狗去，程序员的经验仍然能训练你强大的逻辑、谨慎和耐心，放在哪个行业都是相当可观的竞争力。

第 2 个一点点：思考力与推动力

我认为处理 bug、崩溃、调优、入侵等突发事件比编程本身更能体现平庸程序员与理想程序员的差距。当面对一个未知的问题时，如何定位复杂条件下的核心问题、如何抽丝剥茧地分析问题的潜在原因、如何排除干扰还原一个最小的可验证场景、如何抓住关键数据验证自己的猜测与实验，都是体现程序员思考力的最好场景。是的，在衡量理想程序员的标准上，思考力比经验更加重要。

有时候小伙伴跑过来，问我「提交了一个任务被卡住了，怎么办」的时候，我总觉得他可以做得更好。比如，可以检查试验别的任务，以排除代码自身的原因；可以通过 Web UI 检查异常（如果没有账号，可以让我提供）；可以排查主机日志或删除缓存，再不济，总应该提供任务 ID 和控制台日志给我。理想的程序员永远不会等事情前进，他们会用尽一切方法让事情前进。

第 3 个一点点：Never Say No

记得从前厂离职之前，找老板谈话，他说我最大的优点就是从来不和他说这个做不到。后来我发现在很多团队里，都存在一种技术和产品的对立，程序员往往以「技术上无法实现」来挡产品的需求，而产品也往往以「Facebook可以为什么我们做不到」来奚落程序员。这两句话应该属于禁语，从根本上都不利于程序猿和产品狗的相亲相爱。

一句「技术上无法实现」是容易出口，可有多少人在说出这句话的时候，心里是 100% 肯定的？如果不肯定，为什么不能回去谷歌一下再回答？原本我以为程序员是充满想象力，在因为有想象力，才能诞生那么多改变我们生活的软件和互联网产品。见识多了，才了解大部分程序员已经在与 bug 的对抗中变得保守而不愿担当风险，与此同时许多团队也不愿意宽容失败。于是「Say No」变成一种习惯性的抵触，还记得曾国藩为什么解散湘军么？他说那支军队已「暮气渐深」，不能打仗了。要做理想的程序员，就不能给自己滋生暮气的机会，如果面对不合理的需求，可以把时间成本摆出来，把曲线救国方案亮出来，简单粗暴「Say No」是不可取的。

第 4 个一点点：投资未来

程序员是一个非常残忍的职业。你所学所用的语言、框架、模式，很可能在数年内就成昨日黄花了；你现在嘲笑的另一群程序员，可能马上就能转身来嘲笑你了。所以理想的程序员除了做好自己的本分，还要花费时间来投资未来。什么是「投资」？投资就是你现在投入的时间，在未来会以更多的时间或者金钱（看看早几年学习 iOS 的程序员现在的薪酬！）回报你。举我自己的领域 — 数据挖掘为例，08 年左右 Hadoop 开始兴起，一时「大数据」概念火热，Hadoop 工程师万金难求，各互联网公司纷纷把数据统计、数据分析和数据挖掘的业务切换到分布式平台上。这几年眼看 Hadoop 还在不断迭代，Spark 又异军突起，一举刷新了 Hadoop 保持的排序记录，以内存存储中间数据带来的性能优势和丰富的数据结构让人爱个不停，各种奇异的小 bug 和陡峭的学习曲线又让人打退堂鼓。那么，明眼人都知道 Spark 是未来的趋势（内存会越来越便宜），在主业务放在 Hadoop 的条件下，就可以适当把一些小模块切换到 Spark 上，同时留意 Spark 社区的发展。很快从 Spark 获得的性能收益就能把之前投入的学习时间挣回来。