编码正在变得越来越简单。N年之前就有低代码平台让非技术人员用“拖拉拽”的方式搭建页面，在大语言模型迅猛发展的今天，各种AI编程助手更是让“人人都是开发者”成为可能，外网火爆的8岁小孩哥用Cursor写游戏的新闻让许多人惊呼“编程门槛已被彻底打破”，“5分钟写出一个App/微信小程序”的自媒体文章更让我们这些大龄码农倍感焦虑。

然而，我在使用Cursor写代码的时候发现它并不是那么听话，跟它说一个需求它常常脑补一些别的功能，让它改一个bug，可能又顺带着引入一个别的bug。在长时间跟Cursor“斗智斗勇”之后，我发现要让AI成为靠谱的开发者同事，还并不仅仅是会生成代码那么简单。真正的开发能力源于对系统性思维的掌握，而非单纯的代码编写技巧。就像一个优秀的建筑师不仅需要懂如何堆砌钢筋混凝土，更需要掌握空间规划、力学原理甚至有美学思维，一名优秀的开发者不仅要会堆砌代码，更需要具备领域建模、业务流程抽象、上下游协同等更全面的能力。

本文将探讨在AI时代，哪些开发者背后的隐藏技能仍然不可或缺，以及如何让在企业内真正落地“人人都是开发者”。

一、建模：万物皆有模型

什么是“建模”？建模就是“构建模型”的缩写，是将不同的、复杂的现实世界抽象为通用的、便于理解的形式。在软件开发中，建模意味着识别出系统中的关键元素及其关系，并以结构化的方式表达出来。

《Thinking in UML》一书把所有的软件系统抽象为人、事、物、规则 这几个核心要素，

• • 人：系统的使用者和参与者，具有不同的角色、权限和行为特征
• • 事：系统中发生的活动、事件和流程
• • 物：系统中的资源、数据和对象
• • 规则：定义系统运行边界和约束的各种条件

这种抽象的模式亘古不变，并且会让原本复杂的世界变得简单清晰很多。比如，设计一个在线选课平台，用人、事、物、规则来建模的话，可以画一个类似的图

基于这个底层模型，可以设计数据库表的结构，比如学生信息都有哪些，课程的信息都有哪些，学生跟所选课程之间的关系通过什么表来记录等等。

这个底层模型需要开发者事先跟AI讲清楚达成共识，否则一句话需求“设计一个在线选课系统”，在现阶段很难让AI直接生成可用的版本。如果你再有个性化的需求，AI就更无法帮你实现出来了。

二、画流程图：让复杂过程可视化

之前听一个架构师讲，“凡是动词都有其流程”。在确定系统的底层模型之后，需要再把核心的流程图画出来。流程定义了业务如何运转、数据如何流动、用户如何与系统交互。比如要实现“学生登录系统”这个动作，健壮的系统需要考虑到通过什么方式认证身份，如果用户名不合法要怎么处理，密码遗忘要怎样找回等等流程。比如，

流程图是开发者与业务人员的共同语言，它能够清晰展示业务逻辑和系统工作流，发现潜在的逻辑缺陷和优化空间，是开发实现和测试验证的基础。

在实际开发中，AI已经可以根据自然语言描述生成流程图代码（如Mermaid或PlantUML），但开发者可能仍需要手动微调，确保流程符合业务需求。

三、确定通信协议：系统互联的桥梁

在对流程图达成共识之后，需要进一步设计交互协议/API。这些API出现在不同的对象相互通信的交互点。比如上图的前端与后端有一个交互是“发送登录请求”，那么就需要有一个API的定义。完善的API文档应包括URL、请求格式、响应格式、认证方式等信息。这个用户登录API的文档可能如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

API: 用户登录  
URL: /api/v1/auth/login  
方法: POST  
内容类型: application/json  
  
请求体:  
{  
  "username": "string", // 用户名  
  "password": "string"  // 密码  
}  
  
成功响应 (200 OK):  
{  
  "token": "string",       // JWT令牌  
  "user": {  
    "id": "string",        // 用户ID  
    "username": "string",  // 用户名  
    "role": "string"       // 用户角色  
  }  
}  
  
错误响应 (401 Unauthorized):  
{  
  "error": "string",       // 错误代码  
  "message": "string"      // 错误描述  
}

上下游交互的API设计方式与上方类似，只是在企业内部可能会有通信更加高效的RPC协议。

当前AI可以帮助生成API文档，但开发者仍需要理解业务需求，确定合适的接口粒度，评估AI生成的接口设计是否符合安全性、性能和可扩展性要求。在与上下游确定API协议之后，就可以分别进行开发啦。

四、设计测试用例：AI质量保障的基石

现在可以让AI写代码了吗？且慢。如同再优秀的程序员也会写bug一样，AI也会写出bug。并且AI在开发者的提示之后，可能越改越乱。如果你不懂代码，简直不知道它在修复这个bug的过程中，是否引入了新的bug

让代码没有bug的方式是测试。在传统软件行业中，开发者和测试人员是两种不同的角色，测试人员根据对产品流程的理解产出测试用例。良好的测试用例应覆盖所有关键功能和业务场景，包含正常流程和各种异常情况。

在1990～2000年，软件开发流行一种“测试驱动开发（TDD，Test-Driven Development）”的方法论，其核心思想是 先编写测试用例，再实现功能代码。在确保所有测试通过后，对代码进行优化和重构。有测试作为保障，开发者可以放心地进行重构，而不必担心引入新的错误。如此重复循环，逐步完善系统功能。

听起来很不错，但实际落地过程中会面临很多挑战，由于需要额外编写测试代码，TDD可能会增加开发时间，红-绿-重构的流程显得过于繁琐和教条。更麻烦的是，在测试过程中需要构造各种测试数据，传统方式不仅麻烦，还可能会遗漏。

好消息是TDD理论有望在AI时代重焕升级，毕竟测试用例、测试数据都可以让AI来生成嘛。

• • 不想自己写测试用例？只需要告诉AI：请根据PRD用产出测试用例，需要考虑各种边界条件，用Xmind的格式输出。开发者只需要review测试用例，确保测试用例的设计与产品原型保持一致。
• • 测试数据不好构造？只需要告诉AI：以下是我的建表语句: CREATE TABLE xxxxxx，请针对于XX文件XX方法帮我生成测试数据的insert SQL，正常场景和各种异常场景都要考虑到就可以得到直接能用的测试数据。

五、设置编码规约：一致性的保障

在设计完所有的测试用例之后，在正式写代码之前，还有一件事需要做。为了让AI能写出可读性强、扩展性好、风格统一的代码，必须要让它遵循一些约束条件。比如，变量如何命名、代码如何缩进、日志如何打印、异常如何处理等等。

阿里巴巴Java开发规约是业内广泛采用的编码规约，可以把强制、建议的规约显式写出来让AI遵循，在Cursor中可以使用Rules来完成对规约的设置，

六、正式编码：一次只做一件事

终于可以开始写代码了，为了让整个开发过程太过发散，避免“胡子眉毛一把抓”，强烈建议“一次只做一件事”，每次代码修改只聚焦在一个功能点，完成之后提交，然后再做下一个。

“一次只做一件事”也体现了软件工程中的单一职责原则（Single Responsibility Principle）：一个类应该只有一个引起它变化的原因。即每个类只负责一个功能领域，每个方法只完成一个明确定义的任务。

体现在AI编程上的最佳实践是开发者先写注释，由AI生成代码。这样每个方法上都有标准的注释，极大增强了代码的可读性。把业务逻辑全部都写完之后，可以让AI把代码的流程图用mermaid语法输出出来，跟PRD中流程做一次double check

结语：人人都可以是“创造者”

AI编程可以说是AI应用领域中最早找到PMF（Product Market Fit，产品市场匹配）的方向之一，并且已经展现出强大的商业化潜力。

AI工具可以降低开发门槛，提高开发效率，然而，想要真正用好AI，跟它结对编程，更重要的是建模能力、把复杂的问题拆解成简单任务的能力，以及能跟其他角色更好的协作能力。

AI时代，必将“人人都是开发者”、“人人都是产品经理”、“人人都是设计师”、“人人都是XXX”，在这个新的范式里，人人都可以是“创造者”，用AI释放自己的想象力、执行力与影响力。不会某项技能不会决定你的天花板，能不能提好问题、能不能带着AI一起解决问题，才是AI时代的核心竞争力。

在程序员的世界中，有一条广为人知的“鄙视链”：“Talk is cheap, show me the code”。这句话常用来强调代码的实际价值，而轻视那些夸夸其谈的人。我们常常把这句话奉为圭臬，然而，生成式AI让这句话发生了反转，现在是“Code is cheap, show me the prompt”。让AI生成代码、让AI生成文字、让AI生成XX，“talk”成了影响AI生产力的核心因素。

在实际工作中，不论是技术规划、技术交流、技术方案等，都需要通过文字来表达，我把这些文字统称为技术类文章。文章写得好可以极大提升自己的技术影响力，但写技术文章无疑是比写prompt更复杂、更困难的任务。身边很多程序员同事会因为觉得日常工作过于简单而无事可写，或因为自己“小时候语文不好”而无从下笔。如果再要求要写出深度，就更是“难于上青天”了。

写出高质量的技术类文章通常意味着清晰的选题、充分的调研、深入的思考，以及清晰有逻辑的表达。笔者在近两年累计写了百余篇技术类文章，以下是我对写作“套路”的经验总结，欢迎批评指正。

一、以“问题”驱动选题

写技术类文章不是“为赋新词强说愁”，它的首要目标是解决现实问题。现实问题可以是要对某个方案达成共识，可以是一次向上汇报，也可以是围绕自己的经验教训做分享。例如，在国内企业大规模出海的过程中，肯定会面临多国家部署、多时区、多币种等问题，对于这类问题是否有最佳实践，是否能沉淀成架构模式，或是指导手册，或是工具能力？

还有一种选题思路是“举一反三”，遇到一个小问题，可以思考在更大范围内该问题是否也存在，或者其他同类型的问题是否存在。例如，某个技术类工单是因为网络抖动导致调用下游失败，可以思考针对下游异常的通用重试策略是怎样的？如果遇到NullPointerException导致的故障，可以思考通用的异常处理模式是怎样的，如何分级处理异常？

当然，如果一时想不起来也没关系，可以保持对问题的持续“探测”。工作就是在不断解决问题，如果在解决问题时更再多想一层、更进一步，那就会持续超出别人的预期。如果同时还能有技术类文章的沉淀产出，那就是一石三鸟了。

机会总以问题的形式出现。

二、用“卡片笔记法”积累素材

没有人从零开始写作，高质量的输出需要更多高质量的输入。在写作之前至少要看看市面上是否已经有了相关主题的内容，别人的角度是怎样的，避免自己以为写的是洞见，但其实早已经是常识了。既然花时间写，那就说点别人不知道的，写点真正新鲜的内容。

很多同学反馈说，读过很多书但是记不住啊。对此，我深有同感，我现在重读一些书，看到自己之前在空白处写的读书笔记会有种错觉：“这是我写的吗？”，完全没印象了。《卡片笔记写作法》一书把这种笔记称为“思想的坟场”。这里的残酷真相是：

很多人在阅读时习惯划线、标注，甚至摘抄原文。然而，这些做法看似是在记录信息，实际上很少能帮助我们真正理解和消化内容。如果不经过主动的思考和总结，这些所谓的“笔记”其实并没有多大作用。

真正有用的笔记方法是德国社会学教授卢曼创造的卡片笔记法。卢曼使用这种方法在30年内出版了58本著作和数百篇文章，成为20世纪最伟大的社会学家之一。我也是卡片笔记法的拥趸，使用flomo（浮墨笔记）两年多，已积累了2600+笔记卡片，近400个标签，并还在持续记录中。

flomo也是受卢曼卡片笔记法启发做的笔记软件，他们的创始人去年出了一本《笔记的方法》，把记笔记的关键方法进一步提炼为三个，

1、用自己的话做笔记

真正有效的笔记应该是用自己的话复述。不是说要摘录原文的话，再写自己的感想，而是要用自己的话，用自己的经验，把作者的观点推导出来，变成就像自己说的一样。这两种方式是完全不同的，一种是评论，另一种是阐述。

这一点跟“费曼学习法”的道理是一样的，你只有能把别人教会，你才算真的懂了。很多时候你以为你看懂了，合上书之后，并不能把作者的观点复述出来，这还不是真正的理解

2、笔记的标签管理法

《笔记的方法》讲，笔记的价值在于增援未来的自己。我们需要高效地对已有笔记进行管理，才能在未来用的时候找得到、用得上。而“标签”就是对笔记做管理的最佳实践。

例如，在传统的文件夹模式下，「电动按摩椅」要么被放在「家用电器」中，要么被放在「家具」中，相互排斥。而标签的好处在于，你可以在任意一个卡片上添加多个标签，方便你将来的回忆和查找。在flomo中还可以通过多级标签的方式对笔记做更结构化的管理。例如，我最近在读《华为数字化转型之道》，就用标签把这本书和我们的一款产品联系了起来

3、持续不断回顾

做了笔记并不是终点，持续回顾不仅能抵抗遗忘曲线，还能让老笔记与新想法产生碰撞，说不准会有新的启发。flomo支持每天随机回顾4~24条笔记，在回顾卡片笔记时，我一般会对笔记做重新整理：

• • 删：删除不知所云的笔记，删除只有url的笔记、删除重复的内容、删除有事实错误的卡片。大胆删吧，很多内容以前没看，以后也不会看
• • 加：增加标签，关联已有卡片。比如，2023年记录的一个卡片，突然发现跟2024年的项目相关，那就在原来的基础上增加项目标签。这里的本质是新增连接，新连接产生的新想法，就是知识的复利。

三、用“黄金思考圈”深入思考

很多技术同学很擅长解决实际问题，可能最终结果也不错，但在项目复盘的时候，问及“为什么这么做不那么做”、“为什么做这个不做那个”、“为什么是你做不是ta做”的时候就懵了。要避免项目复盘的时候被别人问懵，需要自己在立项方案中事先回答这些“灵魂拷问”。

作家Simon Sinek在《Start With Why》一书中提出一种思考模型：“黄金思考圈”，它强调伟大的领导者和组织不是从“做什么”开始思考和沟通，而是从“为什么”开始，然后是“怎么做”，最后才是“做什么”。

（网图，侵删）

由于技术类文章是为了解决实际问题，因此最好也遵循这样的模式，写出自己的解决方案的推演逻辑。这样不仅可以让文章的结论更有说服力，也可以避免读者再通过问题来获取你的思考过程，让文章更清晰。

现在我越来越赞同卢曼的观点：“不写，就不可能系统性地思考”。写作不仅是思考的外化，更可能是思考的本身。

四、站在“读者视角”做结构化表达

写到这里，终于可以说说如何落笔了。如果前面准备得比较充分，写下来就是水到渠成的事。我们唯一需要注意的就是要站在“读者视角”表达。

当你看到这个观点的时候，先不要盲目赞同，用黄金思考圈审视一下，至少应该能问出3个问题，

1. 1. Why，为什么要站在读者的视角写作？
2. 2. How，如何站在读者视角写作？
3. 3. What，站在读者视角写作具体包括哪些内容？

这么简单且正确的一句话，如果你不能清晰地回答这3个问题，那说明你并没有真的理解，而只是“知道了”。下面是我的回答

1. 1. 为什么要站在读者视角写作？

• • 读者不是必须要读你的文章，你的文章必须要对读者有用，才能吸引他们读下去
• • 读者读文章需要消耗精力，你需要尽量不“额外”消耗对方精力，才能让ta读完（还可以追问：为什么读者读文章需要消耗精力？我们大脑是如何理解一件事的？）

2. 2. 如何站在读者视角写作？使用“金字塔”的结构呈现，先提出结论，然后再提供支持这个结论的论据，包括数据、事实、分析等。（市面上讲职场写作的培训课，底层都是《金字塔原理》）
3. 3. 站在读者视角写作具体包括哪些内容？

• • 有吸引力的开头：用故事化的方式写序言，写出背景、冲突、疑问、回答。
• • 金字塔内部的纵向关系：父主题用于勾起读者的疑问，子主题是父主题的回答
• • 金字塔内部的横向关系：归纳与演绎是仅有的两种思想组织形式

你有没有发现本文也是按照金字塔的方式构建的？

• • 序言中的“然而”、“但是”都是表达“冲突”，核心是要回答读者头脑中已有的问题，或者可能会提出的问题，确保能够吸引读者的注意
• • 本文的每一个父标题、子标题都遵循了金字塔的结构，用户可能对父标题产生疑问，为什么这么说？应该怎么做？子标题负责回答、解释、阐述
• • 同级的标题与标题之间是在同一个层级，并且符合归纳或演绎逻辑。例如，“以问题驱动选题”、“用卡片笔记积累素材”、“用黄金思考圈深入思考”、“站在读者视角做结构化表达”是归纳了“写出高质量技术文章”的四个步骤；演绎的形式一般会用“故”、“所以”、“因此”的关键词来呈现，大家后续在读文章的时候，也可以做一些留意。

结语、我们的写作能力从何而来？

至此，本文的正文就写完了，希望能对你有一些启发。最后我想跟你探讨一下：我们的写作能力是从哪儿来的？

写作能力当然不是天生的，它只是一种技能。回顾我们的教育过程，高考作文要求不低于800字，有范文、要用“好词好句”；大学生、研究生要求写论文，但并没有老师系统性地讲过如何写论文，如何用概念、逻辑、数据、实例对观点进行证明；工作之后，更没有动力学习如何写作。也就是说，哪怕你已经工作了很多年，如果没有刻意练习，你的写作能力可能还停留在高中水平，甚至更低。

对于技术类文章，或者论文等非虚构类写作，生成式AI很可能也指望不上。我们不需要AI生成正确的废话，更需要提供洞见、解决问题。短期而言，AI无法替代具有洞见的人类工程师，更无法替代掉能解决实际问题的工程师。AI可以作为写作的辅助工具，但它不是写作的全部，更不是写作本身。

好在写作并不难，只需要持续地学习和练习。《卡片笔记写作法》说，“如果你想写好一篇文章，你只需要对一个好的草稿去做打磨；如果你想写出一个好的草稿，你只需要把一些笔记变成连贯的文字；如果你想把文字变得连贯，只需要整理那些卡片盒中的相关笔记；如果你想有很多相关联的笔记，只需要在阅读时有一支笔。”

翻开书，拿起笔，从阅读开始，从记录卡片笔记开始。祝每位技术同学都能写出既有深度又有洞见的文章，发挥出更大的影响力。

朱光潜（1897年10月14日－1986年3月6日），中国现代著名的美学家、文艺理论家、教育家。早年在北京大学学习，后赴英国留学，先后在爱丁堡大学和伦敦大学学习，获得博士学位。他的主要学术贡献包括对西方美学理论的引进和研究，其著作《西方美学史》是中国美学研究的经典之作。

《给青年的十二封信》是朱光潜先生在20世纪30年代写给青年读者的一系列信件，最初发表在《中学生》杂志上，后被集结成书。值得一提的是，《谈美》也是以书信体的形式，将美学知识娓娓道来，是经典的美学启蒙读物。

我觉得先生偏爱书信体，体现了一种平等的尊重，也拉近了与读者的距离，用现在的流行语来说就是”没有爹味“，就像与朋友聊天一样，聊自己的观点和思考，让人如沐春风。前段时间团建时，无意中听到同事推荐，读起来爱不释手，分享几篇我的读书笔记，权当是学生的一点反馈。

谈动

我们上大学的时候流行“郁闷”，现在的年轻人流行“emo”。无意义感、不爽的感觉在持续侵扰着不同时代的青年，但我没想到朱光潜是这么劝慰大家的：“我们究竟还是自然的奴隶，要想’征服’自然，必须先服从自然、顺应自然，我们是’动物’，所以天性就是动。人好动、好发展和创造。动、发展、创造，是顺应天性，就会快乐，不动、不发展、不创造就会烦恼。”

动起来！行动起来！作为大厂的一颗大号螺丝钉，我会习惯性焦虑，项目的进展、团队的方向、职业的规划，时常萦绕于心，但这些啊，归根结底在于想得太多做得太少，一旦动起来，就不觉得惶惶不可终日了。毕竟，不动什么都不会改变，动起来总有一丝生机。

在财务自由之后，就会开心吗？叔本华说，人总是在痛苦和无聊之间来回摇摆。对于有着“闲愁”烦恼的人来说，消解的方式也是一样的。动起来！弹弹琴、养养花、打打球，即便不喜欢这些，就说说笑笑、跑跑跳跳也是好的。

谈静

人生乐趣，一半得于活动，一半得于感受。动静结合，互为补充。《谈静》主要说的就是“感受”。不同的人对同一件事的感受能力有很大差别。比如同样看到一条鱼，有的人看到的是食材，有的人看到的是鱼的种类和习性，有的人看到的是鱼的自由自在或是鱼与水的关系。

很多天才或有成就的人，不仅仅是他们做得好，更多的可能是他们的感受力异于常人。比如音乐家能听出多个音的和谐与否，音盲甚至区分不了自己是否跑调。优秀的演员之所以优秀，首先是他们能感受到什么是自然的表演，知道“应该”是什么样的。

这种感受力，一半是天生，一半是后天修炼。很多时候我们麻木不仁，是“心”太忙了。但是到底应该于百忙之中偶然获得“静趣”？作者没有说，可能也是每个人都不一样。多读书、多旅行，偶尔把身体和大脑抽离出日常环境，可能是一种途径。

谈升学与选课

这篇非常具体。我惊讶于他作为”青年人的导师“，竟然这么接地气。因为升学和选课的问题，我曾经也被亲戚家的小孩问过。年轻的大学生不知道怎么选课，跟我们当时读大学时如出一辙。我现在知道选课不要急功近利，要更多基于自己兴趣，而不是基于臆断出来的工作需要。一方面是工作需要与学校教育之间相差太大，在大学里学到的内容很难直接用于工作；另一方面是这样的心态会消解掉”好奇心“和”求知欲“。好奇心会会让人主动思考，“工作需要”对每个知识点都会权衡是否会考，反而心浮气躁、患得患失。

先生说职业教育需以宽大自由的博雅教育或通识教育为基础，否则人会肤浅乏味。现代社会过度强调”效率“，甚至有种把人异化的倾向，在社会这个大机器上作为一颗螺丝钉或齿轮，当停下来的时候反而不知所措。从个人幸福的角度出发，我们也要尽可能多涉猎其他领域的知识，在自己的精力范围因，尽可能多选择自己喜欢的课程。

还有有的时候选课犹豫，可能是害怕选错课导致的时间或精力的浪费。但我认为很多时候”遗憾“比”浪费“更可惜，尤其是在提升自己这个大的”战略“方向上，需要做到”饱和式攻击“，哪怕有点点浪费，也认了。

谈人生与我

先生说，“我有两种看待人生的方法，一种是把自己放在前台，跟世界的一切人和物玩把戏；一种是把自己摆在后台，袖手看旁人在那里装腔作势。”

站在前台时，不把自己看得太特殊，甚至主动把自己“物化”等同于花鸟鱼虫。对此我是认同的，这样不会太敏感，遇到一些不开心的遭遇可以很快调节自己，在遇到开心的事情也可以心存感激。再有啊，花鸟鱼虫可能比人类更幸福啊。“我请你在春天到百花齐放的园子里去，看看蝴蝶飞，听听鸟儿鸣，然后再回到十字街头，仔细瞧瞧人们的面孔，你看谁是活泼，谁是颓废？请你在冬天积雪凝寒的时候，看看雪压的松树，看着站在冰上的鸥和游在水中的鱼，然后再回头看看遇苦便叫的那“万物之灵”，你以为谁比较能耐苦持恒呢？”

先生站在后台看人生的态度呢？俩字：看戏。没有是非善恶视角，纯看戏。“悲剧也就是人生一种缺陷。它好比洪涛巨浪，令人在平凡中见出庄严，在黑暗中见出光彩。假如荆轲真正刺中秦始皇，林黛玉真正嫁了贾宝玉，也不过闹个平凡收场，哪得叫千载以后的人唏嘘赞叹？”

话虽如此，但对此我并不以为然。比如我之前读蔡磊的《相信》，就被他的故事震撼和感动。在蔡磊自己病情逐渐恶化的情况下，他向渐冻症发起了史无前例的、自不量力的、愚公移山般的“反击”，在被劝无数次“别折腾了”之后，竟然被他劈出一条小路，先以自己作为节点连接了众多病友，创建了全球最大的渐冻症病友大数据平台，再通过自己的人脉不断寻找外部资源，亲自带队做新技术的探索与研发，让整个流程变得更高效成本更低。我想这样的故事，是没有办法用冷眼来看的，必须有热血的行动。

后记

本书是很薄的小册子，虽然是几十年前的书，但很多建议还是颇有启发，不觉过时。太阳底下无新事，很多事情也在重复发生，我们不要觉得物质世界的发展、科技的进步造就了有更先进思想的人，知识不能遗传，也就意味着历史上有太多的人经历了我们类似的苦闷烦忧，他们的困境、他们的思考、他们的行动，都可以供我们借鉴。

最近读了几本“故事书”，感觉都颇有启发，也很有趣。读李飞飞的《我看见的世界》，写自己如何从底层的华人移民一步步成为斯坦福大学教授，并被人们尊称为”AI教母“；读田浩江的《歌剧院的图兰朵》，写自己从北京锅炉厂工人到纽约大都会歌剧院的一幕幕酸甜苦辣。我们花几个小时看过的书啊，都是凝结了别人几年甚至几十年的生活经验，这信息密度，这智慧含量，怎么能让人不读下去！

最近，“萝卜快跑”的新闻频频出现在我们的视野中，无人驾驶技术正在逐步走进我们的生活。这一技术的出现不仅预示着交通方式的变革，也引发了关于就业、安全和社会变革的广泛讨论。

有人为科技进步和创新的便捷性欢呼，认为这是中国技术进步的象征；也有人担忧这将威胁到网约车司机的生计，甚至可能引发社会不稳定因素。无人驾驶真的来了吗？以后还用买车吗？网约车司机何去何从？无人驾驶是好的技术吗？虽然我不是从业者，但希望管中窥豹，推演一下未来的样子

二、自动驾驶的分级及当下坐标

根据国际汽车工程师学会SAE的标准，自动驾驶技术分为六个等级，从完全手动驾驶的L0到无需人工干预的L5。L1提供单一自动化功能支持，L2能同时执行多个自动化功能，L3在特定条件下实现完全自主驾驶，L4在限定区域内无需人工干预，而L5则在任何区域都能完全自主驾驶。

工信部2024年公布有9家车企进入全国首批L3自动驾驶上路通行试点名单，包括一汽、上汽、广汽、长安、北汽蓝谷、比亚迪、蔚来、上汽红岩以及宇通客车。百度Apollo、小马智行（Pony.ai）等企业具备L4级无人驾驶能力。

目前没有企业能做到L5级别的无人驾驶，不管是以特斯拉为代表的纯视觉方案（FSD），还是国内车企常见的多传感器融合方案，都面临复杂环境下的种种挑战。例如，摄像头在夜间或恶劣天气下的视觉感知能力会下降，激光雷达在雨雾天的穿透能力有限。在遇到陌生交通环境时，相比于人类驾驶员，自动驾驶的泛化能力明显不足，比如在武汉发生过两辆萝卜快跑出租车因互相谦让对方，导致交通堵塞。

三、不同视角下的无人驾驶

根据Fortune Business Insights的调研报告，2023年全球自动驾驶汽车市场规模达到18.8亿美元，预计到2032年将增长至387.8亿美元，复合年增长率为 42.3%，显示出这一领域的巨大潜力和增长速度。自动驾驶的技术进步不是自然发生的，其背后有一个巨大的市场引擎作为驱动。会涉及到交通行业上下游的各个角色，我们看看比较关键的几个视角，

1、政府视角

中国政府对自动驾驶技术的发展是高度重视和支持的，不仅在政策上提供便利，还在多个城市设立了测试区域，以促进技术的发展和应用。比如，《新一代人工智能发展规划》将自动驾驶列为重点发展领域，并提出到2025年实现高度自动驾驶的商业化应用目标。

在社交媒体平台上，“无人驾驶震惊外国人”等相关视频不断破圈，也让无人驾驶成为武汉的科技名片。最近几天外交部发言人也点赞了“赛博武汉”，称这些外国游客沉浸式的随手拍展现了中国发展的勃勃生机。可见，不管是地方政府还是中央，都对无人驾驶的这种科技创新持正面态度。

2、企业视角

新能源车企、传统车企、互联网相关企业都在积极布局自动驾驶赛道，加上下游的配件、传感器、控制系统等，自动驾驶是一个完整的产业链。

根据前瞻经济学人的报道，2014-2023年间，中国无人驾驶汽车领域共发生投资事件620起，投资金额2122.12亿元人民币，显示出资本市场对这一领域的高度关注和投入。

最近火出圈的萝卜快跑号称已经在L4路测1亿公里，虽然现在还在贴钱教育市场，但“低价”收集到的轨迹数据才最核心的技术壁垒。

3、网约车司机视角

网约车司机作为即将被无人驾驶“颠覆”的对象，心中可能五味杂陈。一方面是本身网约车已经很卷，性价比越来越低；另一方面是几千万的员工数量，一旦被失业将会是几千万个家庭的苦难，甚至是整个社会的不安全因素。

考虑到网约车司机的受教育程度和年龄，拥抱新技术的挑战还是很大的。车企如何吸纳这部分人员的就业，以及政策上是否能通过再教育、补贴等方式让这部分人“软着陆”，是构建和谐社会的关键措施。

4、乘客视角

乘客对萝卜快跑大多是正面反馈，其中最明显的感知是“便宜”，叠加上优惠券平均每公里不到￥1块钱；其次是“安全”，在行驶过程中会保持安全距离，遇到行人或车辆时会明显减速或急刹车，据百度的数据显示，萝卜快跑实际车辆出险率仅为人类司机的1/14；还有“省心”，不需要考虑车里是否有异味、是否需要跟司机尬聊等等

从这几个视角推演下来，自动驾驶已经是大势所趋，就像纺织工人砸向蒸汽机的铁锤无法阻挡工业革命一样，自动驾驶的技术进步也不会眷顾因循守旧的人。

四、面向未来，适者生存

对于车企而言，降低成本和提高安全性是赢得市场的关键。例如，通过采用更高效的传感器和算法，可以减少车辆成本并提高其在复杂环境中的适应性。百度称萝卜快跑的整车成本已经从45万下降到了20多万，成本降低了60%；为了更安全，在云端还有云驾驶员处理一些特殊情况。在未来，谁能更安全地服务乘客，谁能把运营成本做到更低，谁就能立于不败之地。

对于网约车司机，虽然无人驾驶不会立刻让大量网约车司机失业，但未来生存空间一定越来越小。好在无人驾驶的到来，也必将催生新职业的诞生，比如传统司机转型为无人驾驶的”路测安全员“、无人驾驶车辆的监控员、做无人驾驶车的清扫运维等，可能是适应这一变革的有效途径。当然，可以在政策的引导下转做其他行业，毕竟，我们说这辆车是一辆车，和我们说这个人是一个司机是完全不同的。车无法决定自己的身份和用途，而司机如果下班或者转行，他就不再是一个司机了。

在这个快速变化的时代，每个人都应该具备终身学习的能力，不断掌握新的技能、适应新环境。或许，无人驾驶带来的不只是技术革命，还有人的重新定位，以及无限可能。

本周5月14日，OpenAI发布了最新的大模型GPT-4o，多项优化能力以及与AI实时互动的场景让人印象深刻。看很多公众号文章已经在各种吹捧GPT-4o，我们也来凑个热闹看看未来世界的样子。

GPT-4o（“o”代表“全能”）是更自然的人机交互的一步——它可以接受任何文本、音频、图像和视频的组合作为输入，并生成任何文本、音频和图像的组合输出。它可以在 232 毫秒内响应音频输入，平均响应时间为 320 毫秒，这与人类在对话中的响应时间相似。

测试下来，感觉GPT-4o已经不仅仅是传统意义上的大“语言”模型，而是一个功能全面的智能体了。

一、图片识别：惊人的细节捕捉能力

随手拍一张小朋友在上网课的照片，让GPT-4o来识别，相比于GPT-4来说，GPT-4o描述了更多的细节

可以看出来，GPT-4o的图片识别不仅限于表面，它甚至能够深入到图片的语义层面。它能够识别出图片中的情感和故事，比如孩子对学习的渴望，或是家庭环境中的温馨和安宁。这种深层次的理解，让GPT-4o在图片识别上超越了简单的图像处理，它能够提供更加丰富和人性化的解读。

二、批改作业：小学生的学习助理

不少小学生家长对辅导作业都非常头疼，尤其是对语文的写作。我们试试GPT-4o是否可以承担学习助理的职责，把“看图写话”拍照给它。这对AI是一个很大的挑战，首先它要理解哪个区域是题目，哪个区域是回答；其次要能理解这幅画想要表达的内容；再次要将所有的手写体正确识别为标准汉字；最后进行批改审阅后输出

这个能力显著超越GPT4，GPT4不仅没有理解哪部分是题目，还把题目中的汉字识别错了，把”小朋友，猜一猜，这是什么季节？“ 识别为”小熊熊，挥一挥，这是什么树？“

对比GPT4的图片识别能力，就能意识到GPT-4o能力的”恐怖“。在辅导作业这件事上，AI已经超越我了。可以想象，随着模型的不断升级，GPT-4o在教育领域的应用将更加广泛，为孩子们提供更加丰富和个性化的学习体验，优质的教育资源从此不再稀缺，真正实现因材施教。

三、编辑音乐：0基础0代码搞定

音乐是人类情感的表达，现在也可以用AI生成各种风格的音乐了，我之前写了两篇用Suno.ai生成音乐的文章可以查阅。用Suno.ai生成音乐虽然简单，但音质较差，没法发布成网易云音乐中的歌曲。这次，我们让GPT-4o来帮忙升级一下音质

GPT-4o可以分析声音的质量，并提供改善音质的建议，但这还不够，因为太复杂了，我不想掌握这些音乐编辑软件。再提一个更“过分”的要求，

GPT-4o的服务态度，真的很好呢。下载后，真的可以用，音质似乎提高了很多，尽管我听不出来明显差别

四、搜索RAG：有待提升

直接问最近比较火的综艺节目《我是歌手2024》参赛歌手和排名情况，虽然GPT-4o已经可以搜索了，但回答的结果并不正确。第二期排名里，海来阿木是第5名，杨丞琳是第7名被淘汰。

拿同样的提示词来问Kimi（左图），回答出正确的答案，并且Kimi在参考资料的数量和推理结果上都优于GPT-4o（右图）

五、语音交互：最自然的沟通方式

在人机交互的历史中，语音一直是一种最自然、最直接的沟通方式。GPT-4o的语音交互功能，正是将这种自然沟通方式提升到了一个新的水平。语音交互只在手机App上可用，网页版是没有的。

这里要说一下字节的豆包app，我认为豆包的语音是国内AI App中声音是最自然流畅的，停顿、音色、语气助词都恰到好处，毫无AI痕迹。

六、实时交互：尚未开放

跟Google2个多小时I/O大会相比，OpenAI的26分钟“发布会”，狙击Google的意味太明显了。Introducing GPT-4o的视频中，主持人演示了可以与ChatGPT进行实时交互，非常自然流畅，但这个能力还没有对所有人开放。

GPT-4o的实时交互能力，在技术上是完全可行的，这预示着实时交互技术已经达到了一个新的高度，它不仅提升了用户体验，还为未来开辟了新的应用场景，结合着VR、AR，提供沉浸式的体验

评测总结：大模型还没到边界

现在回看ChatGPT3.5，GPT3.5是AI时代的“iPhone4时刻”，它开启了AI时代。但不得不说，纯纯的大语言模型现在已经显得笨拙和落伍。我们现在看到的GPT-4o已经俨然是一个智能体了。GPT-4o在图像识别以及复杂任务规划方面表现的相当亮眼，如果再加上实时图像识别和语音交互功能，将带来极具科幻感的体验。

其实真正让我惊讶的不是GPT-4o的能力，而是GPT-4o的输入混合了文本、视觉和音频，所有的输入和输出都由同一个神经网络处理。“由于 GPT-4o 是我们第一个结合所有这些模态的模型，我们仍然只是在探索模型能做什么以及它的局限性。” 说大白话就是It works，但我们都不知道是怎么回事，我们正在朝着未知的未来狂奔…

CAP定理，这个名字你可能听过无数次，但你真的了解它吗？本文将从似懂非懂的CAP定理入手，深入理解「分区」的关键因素，探讨CAP的进阶版本：PACELC，帮助你在十分钟内理解CAP定理。

目录

• 1. 前言：似懂非懂的CAP定理
• 2. 对「分区」的理解是关键因素
• 3. CAP的进阶版本：PACELC

• 3.1 只有分区出现时，才需要抉择A和C

• 3.2 没有分区问题时，需要考虑L和C

• 4. PACELC对我们的启发

1. 前言：似懂非懂的CAP定理

大名鼎鼎的CAP定理，相信很多人都听过，但具体是什么意思，对我们日常工作有什么指导价值呢？最近在学习数据架构，翻阅了一些资料，发现能讲明白的比较少。比如，CAP定理在百度百科中，它是这么解释的：

CAP原则又称CAP定理，指的是在一个分布式系统中， Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），三者不可兼得。

• 一致性（C）：在分布式系统中的所有数据备份，在同一时刻是否同样的值。（等同于所有节点访问同一份最新的数据副本）
• 可用性（A）：保证每个请求不管成功或者失败都有响应。
• 分区容忍性（P）：系统中任意信息的丢失或失败不会影响系统的继续运作。

再来看维基百科的词条解释：

• 一致性（Consistency）（等同于所有节点访问同一份最新的数据副本）
• 可用性（Availability）（每次请求都能获取到非错的响应——但是不保证获取的数据为最新数据）// Every request receives a (non-error) response, without the guarantee that it contains the most recent write.
• 分区容错性（Partition tolerance）（以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择。）

理解CAP理论的最简单方式是想象两个节点分处分区两侧。允许至少一个节点更新状态会导致数据不一致，即丧失了C性质。如果为了保证数据一致性，将分区一侧的节点设置为不可用，那么又丧失了A性质。除非两个节点可以互相通信，才能既保证C又保证A，这又会导致丧失P性质。

维基百科中对于可用性的描述，「非错的响应」跟「不管成功或失败都有响应」的描述应该是同一个意思，但明显有歧义；单纯看这两个定义非常的晦涩和抽象。比如，「分区容错性」到底是什么意思呢？CAP的一致性一般是指「强一致性」，但现实中的分布式系统大量都是最终一致性，它是否还具备指导意义？还有还有一些文章会结合着ACID，BASE一起讲，概念叠概念，缩写加缩写，看得我也是云山雾罩。

这些问题困扰了我好久，本篇文章算是自己的一篇笔记，如有不正确的地方，欢迎批评指正。

// 核心观点，省流不看版本

• 当我们谈论“分区”时，就是在指节点之间的通信已经中断或不可达，形成两个或多个独立运行的分区；
• 只有分区出现时，才需要抉择A和C；
• 没有通信问题时，需要选择延迟L和C。

2. 对「分区」的理解是关键因素

「分区容错性」在很多文章中被解释为：系统可以在网络分区情况下继续运行。但这句话过于抽象，应该如何理解？

在分布式系统中，节点分布在不同的机器、不同的网段，甚至不同的机房内。当网络故障时，会把系统分成两个或多个独立的运行单元。而当我们谈论“分区”时，就是在指节点之间的通信已经中断或不可达，形成了两个或多个分区。

通过几道测试题，验证你是否真的懂了

Q1

点击空白处查看答案

如果系统的节点都分布在同一个机房，这个系统还会出现分区吗？

是。即使在同一个机房内，分布式系统设计者仍然需要考虑到分区容错性。事实上，在现代的云架构和微服务架构中，即使在同一数据中心内，设计者仍然假设分区是可能发生的，并使用合适的策略和技术来应对这种情况。

Q2

点击空白处查看答案

如果系统有10台机器，无状态地提供服务，这个系统还是出现分区的吗？

是。当我们谈论分区容错性或网络分区时，我们指的是系统中某些机器可能由于网络原因而无法与其他机器通信。这与系统是否有状态或无状态无关。

Q3

点击空白处查看答案

所有的分布式系统都可能出现分区，对吗？

对。任何涉及多台计算机之间网络通信的分布式系统都可能遭遇网络分区，无论网络基础设施有多可靠，总存在失败的可能性。

Q4

点击空白处查看答案

在物流供应链系统中，会有多个子系统；订单从电商系统进入到物流履约系统、再经过处理进入仓储系统、打包出库后进入配送系统，最后进入末端站点系统；如果把整个供应链看成一个大的系统的话，这多个子系统是否可以理解为多个「分区」？

不可以。这些子系统有独立的职责，它们在正常操作中并不被视为不同的“分区”，而是正常和预期的数据交换。但是，如果在某些情况下，例如由于网络问题或其他故障，导致物流履约系统无法与仓储系统通信，那么在那个特定时刻，这两个子系统可以被视为处于不同的“分区”。

由于分布式系统中，总是可能存在因网络原因导致的“分区”存在，所以CAP定理可以退化为是选择CP还是选择AP的问题，即分布式系统需要在「可用性」和「一致性」之间作出选择。看起来好像变简单了，但我再问你：

Q

点击空白处查看答案

在分布式系统中，是否可能不存在分区？

是。在上文中，我说**「当我们谈论“分区”时，就是在指节点之间的通信已经中断或不可达**，形成两个或多个独立运行的分区」。节点之间的通信当然可能恢复，当网络没有问题的时候，就可以理解为不存在“分区”了。而当没有分区P的时候，我们自然不需要做可用性和一致性的抉择，鱼和熊掌我们都要。

你有没有发现，CAP并没有考虑一个分布式系统中的重要因素？分布式系统的关键特性在于，系统中的组件通常在物理上是分散的，并且在运行时彼此独立，分布式系统之间的相互通信必须要考虑到「网络延迟」。对，CAP忽略的重要因素就是「延迟」，Latency。

3. CAP的进阶版本：PACELC

CAP定理是Eric Brewer在2000年提出的猜想，虽然在2002年得到了证明，但距离现在已经有20多年，我们大可抱着怀疑的态度来审视它。事实上，Eric Brewer自己在2012年写过一篇文章对CAP定理做了一版更新的解释：CAP Twelve Years Later: How the “Rules” Have Changed，其中补充了对延迟的描述

In its classic interpretation, the CAP theorem ignores latency, although in practice, latency and partitions are deeply related. Operationally, the essence of CAP takes place during a timeout, a period when the program must make a fundamental decision-the partition decision:

• cancel the operation and thus decrease availability.
• proceed with the operation and thus risk inconsistency.

在其经典的解释中，CAP 定理忽略了延迟，尽管在实践中，延迟和分区是密切相关的。在操作上，CAP 的本质发生在一个超时期间，一个程序必须做出一个基本决策的时期——分区决策:

• 取消操作，降低可用性
• 继续操作，存在一致性的风险

2010年耶鲁大学Daniel J. Abadi提出的PACELC可以看作是CAP定理的一个扩展或是校准。不要被PACELC这么多字母吓到了，它其实很简单，核心说了两件事：

1. 如果存在分区P，那么系统需要选择A或者C，跟CAP一样；

2. 否则Else，选择延迟Latency或是C // 要么延迟低 && 无法保证强一致性，要么延迟高 && 保证强一致。

▐ 3.1 只有分区出现时，才需要抉择A和C

用两个案例来说明CP和AP的场景

**【历史工单案例】**商家ERP调用仓储发货接口，某次发货请求调用超时后被统一封装成了调用失败的错误码，但实际仓储成功作业后出库。上游ERP看到失败后重新发起对菜鸟仓储的推单请求，导致重复发货资损。

这个案例中，调用请求超时让商家ERP和菜鸟仓储系统形成了两个「网络分区」，双方的状态都处于一个不确定态；在这个案例中，菜鸟的系统选择了可用性A，显式地告诉商家ERP确定性的结果，结果就是放弃了一致性C，数据不一致导致重复发货资损。

在这种场景更好的做法是选择一致性C，放弃可用性A。也就是说，如果没有办法保证一致性，宁可不可用。毕竟跟重复发货导致的资损相比，单笔请求不可用的危害小多了。不可用之后可以由系统规则或人工做兜底的检查，最终实现一致性。

**【架构设计案例】**菜鸟快递员使用揽件app上门揽件，为了不阻塞快递员的操作，在弱网或者离线环境下，允许快递员先使用app完成揽收操作，等网络状况恢复后再进行数据同步。

这种在弱网或没有网络的场景下，手机端的app和云端的server形成了两个分区。这里明显是选择了可用性A，而短暂地放弃了数据的一致性C。从这里也能发现，CAP定理还有一点没有讲，那就是当分区不存在之后，恢复数据一致性需要基于业务场景提前设计策略。

▐ 3.2 没有分区问题时，需要考虑L和C

A high availability requirement implies that the system must replicate data. As soon as a distributed system replicates data, a trade-off between consistency and latency arises.

高可用性要求意味着，系统必须复制数据。一旦分布式系统复制了数据，就会出现一致性和延迟之间的权衡。

**【架构设计案例】**菜鸟某业务作为物流行业的基础设施，在N年前实现了异地双活架构，要求在各数据节点保持强一致同步，折中接受了跨城写的延迟。

**【架构设计案例】**以下是两个例子说明了在没有分区存在时，选择延迟（Latency）而放弃一致性（Consistency）的场景：

• 实时多人在线编辑文档（如 Google Docs）：当多个用户同时编辑同一个文档时，为了提供流畅的用户体验，系统可能会允许短暂的不一致性（比如，不同用户看到的内容稍有差异）。一旦用户的编辑被提交，系统会尝试合并这些更改。
• 社交媒体的时间线或信息流（如 Twitter 或 微博）：当用户发布新的动态或图片时，为了快速响应，这些更新可能不会立刻对所有用户可见。系统可能会选择首先将这些更新存储在某些节点上，而其他节点稍后再获取这些更新。这意味着，在某个短暂的时间内，不同的用户可能看到的信息流是不同的。

4. PACELC对我们的启发

对于程序员或架构师来说，掌握PACELC协议不仅是体现了对分布式系统设计原理的深刻理解，更重要的是可以指导系统设计。由于CAP和PACELC定理已经被证明是存在的，我们在实际工程实践中，针对于一致性（Consistency）、可用性（Availability）、分区容忍性（Partition Tolerance）和延迟（Latency）需要做一些折中和权衡。

在云原生架构下，分布式系统面临着更复杂的网络及运行环境，网络分区、节点故障等异常已经是“常态”或者“共识”。如何在网络异常或延迟的情况下，保障业务系统的稳定性与健壮性，是每一位开发者不得不面对的问题。希望本篇文章可以对开发者有所启发，让每位同学都能用通过健壮的代码为用户提供稳定、高效和可靠的服务。

▐ 延伸阅读

[01]. CAP Twelve Years Later: How the “Rules” Have Changed

https://www.infoq.com/articles/cap-twelve-years-later-how-the-rules-have-changed/

END

阅读更多好文

• 应用机器内存过高的排查&优化
• 你怎么知道我用Arthas火焰图排查了性能问题？
• 菜鸟通用导入导出解读篇