分类目录归档:架构和远方

从架构师的角度来看 AI 编程带来的技术债务

在吹水群,聊到 AI 编程,OZ 大佬提到

感觉 AI 会写很多各种可能情况的无用代码?它不会调试,不知道外部模块调用返回的具体格式,就用一堆if else去处理,最后还没有处理对。

GZ 大佬也说到:

ai 写代码感觉太差了,不知道在写什么
会不会制造更难维护的屎山

大家现在都已经在 AI 编程的世界中畅游了,整个软件开发似乎正以一种前所未有的方式悄然发生。 Cursor、Windsutf、Trae、lovable 等等已经完全进入了当前软件开发的世界中。

AI 能够根据自然语言注释或上下文,瞬间生成代码片段、函数甚至整个模块,极大地提升了编码的「表面」效率。我们正迈入一个「人机结对编程」的新时代。

但是大佬们也开始担心其产生的一些可能产生的后遗症。

今天我们从架构师的角度来看 AI 编程可能会给我们带来哪些技术债务。

作为架构师,我们的职责是超越眼前的速度与激情,洞察长期影响和潜在风险。

当团队的开发者们沉浸在「Tab」键带来的快感中时,一种新型的技术债务正在无声无息地累积。这种债务不再仅仅是糟糕的设计或潦草的实现,它更加隐蔽、更具迷惑性,并且直接与我们赖以信任的开发范式相冲突。

1992 年 Ward Cunningham 首次提出了传统的技术债务,指的是为了短期速度而采取了非最优的、有瑕疵的技术方案,从而在未来需要付出额外成本(利息)去修复。

它通常体现在糟糕的代码、过时的架构或缺失的文档上。

然而,AI 技术债务的范畴远超于此。它深深根植于数据、模型、基础设施乃至组织文化之中,其「利息」不仅是未来的重构成本,更可能是业务决策的失误、用户信任的丧失、合规风险的爆发,甚至是整个 AI 战略的崩塌。

从大模型的本质上来看,「 AI 编程是一个基于海量代码数据训练的、概率性的“代码建议引擎”」。它的工作方式决定了其产生的技术债务具有全新的特点。我们可以将其归纳为三个相互关联的维度:微观的代码级债务、宏观的架构级债务,以及深层的组织级债务。

微观的代码级债务 ——「似是而非」的陷阱

这是最直接、也最容易被感知的债务层面,它潜藏在 AI 生成的每一行代码之中。

在传统编程逻辑下,代码是要写的,而在 AI 编程时,代码是生成的,程序员的作用不再是写代码,而更多的是读代码,审核代码。

AI 生成的代码通常语法正确,甚至能够通过单元测试,但其内部逻辑可能存在微妙的、难以察觉的缺陷。例如,它可能选择了一个在特定边界条件下有问题的算法,或者「幻觉」出一个不存在的 API 调用,甚至在一个复杂的业务流程中,遗漏了一个关键的状态检查。这些 Bug 不再是明显的语法错误,而是「看似正确」的逻辑陷阱。

AI 编程减少了写代码的需要的认知成本,但是极大提升了读代码的心智负担。我们不仅仅要检查代码是否符合规范,还需要检查是否满足需求,以及是否在业务逻辑上完备。如果我们没有管这些问题,将来就可能是一个定时炸弹,隐藏在线上,不知道哪天会爆。

我们知道,AI 的知识来源于其训练数据——通常是海量的开源代码。因为 AI 倾向于生成「最常见」或「最流行」的解决方案,而不是针对当前上下文「最合适」的方案。它可能会引入一个庞大的库来解决一个小问题,或者使用一个过时但常见的编程范式,而不是团队正在推广的、更现代的模式。

这是 「设计熵增」的债务。它会持续不断地将外部的、非标准的、可能是平庸的设计模式注入我们的系统。长此以往,系统的技术选型会变得混乱,代码风格会变得不一致,精心设计的架构原则(如轻量级、高内聚)会被一点点侵蚀。我们必须警惕这种「随波逐流」的设计倾向。

每一行 AI 生成的代码,都应被视为一个来源不明的「外部依赖」。因为 AI 生成的代码片段可能悄无声息地引入了新的第三方依赖。更危险的是,它可能复现了其训练数据中包含的、有安全漏洞的代码模式(例如,不正确的加密实现、SQL 注入漏洞等)。此外,它生成的代码可能源自某种具有严格传染性的开源许可证(如 GPL),而团队并未意识到,从而引发法律合规风险。

为此,我们需要建立机制,自动扫描这些代码中的安全漏洞(SAST)和许可证合规问题。我们需要推动一种「零信任」的代码审查文化:开发者对任何由 AI 生成并最终提交的代码,负有 100% 的理解和责任。

宏观的架构级债务 ——「无声」的侵蚀

如果说代码级债务是「树木」的问题,那么架构级债务则是「森林」的水土流失。这种债务更加隐蔽,破坏性也更大。

如过往我们已经有一套优雅的微服务架构,定义了清晰的通信协议(如 gRPC)、统一的错误处理机制和标准的日志格式。然而,在使用 AI 编程时,为了快速实现一个功能,可能会接受一个使用 RESTful API、采用不同错误码、日志格式也千差万别的代码建议。单次来看,这只是一个局部的不一致,但当团队中数十个开发者每天都在这样做时,整个架构的一致性就会被破坏掉。

这是由于 AI 编程缺乏对我们「项目级」或「组织级」架构约定的认知而导致的,AI 编程是一个无状态的建议者,不理解我们系统的顶层设计。偿还这笔债务的成本极高,可能需要大规模的重构。架构师的核心挑战,从「设计」架构,扩展到了如何「捍卫」架构,防止其在日常开发中被无声地侵蚀。

AI 编程非常擅长生成「胶水代码」——那些用于连接不同系统、转换数据格式的脚本。这使得开发者可以轻易地在两个本应解耦的模块或服务之间建立直接的、临时的连接,绕过了设计的网关或事件总线。系统的模块化边界因此变得模糊,耦合度在不知不觉中急剧升高。

这是一种「捷径」。AI 让走「捷径」的成本变得极低,从而放大了人性中寻求最省力路径的倾向。架构师需要提供同样便捷、但符合架构原则的「正道」。例如,提供设计良好、文档清晰的 SDK、脚手架和标准化的 API 客户端,让「走正道」比「走捷径」更轻松。

从领域知识的角度来看,AI 可以从文档和代码中了解到一些,但是可能做不到完整的理解。

软件的核心价值在于其对复杂业务领域的精确建模。我们需要给 AI 以某种方式注入领域知识,如通过维护高质量的、富含领域术语的内部代码库和文档,来「引导」或「微调」AI 模型,使其建议更具上下文感知能力。

深层的组织级债务 ——「温水煮青蛙」的危机

这是最深层、也最关乎未来的债务,它影响的是人与团队。

当我们严重依赖 AI 编程时,会慢慢失去思考力和对代码的掌控力。

如果初级开发者过度依赖 AI,习惯于「提问-接受」的工作模式,而跳过了学习、思考和调试的艰苦过程。他们能够快速「产出」代码,但对底层原理、算法选择、设计权衡的理解却越来越肤浅。知其然不知其所以然,长此以往,团队成员的平均技能水平可能会停滞甚至下降。

这是团队的「未来」债务。我们在用未来的能力,来换取今天的速度。一个团队如果失去了独立解决复杂问题的能力,其创造力和韧性将不复存在。架构师需要倡导一种新的学习文化,将 AI 视为一个「助教」或「陪练」,而不是「枪手」。例如,鼓励开发者不仅要采纳 AI 的建议,更要尝试用自己的方法实现一遍,或者让 AI 解释它为什么这么写,并对解释进行批判性思考。

我们过往会用代码行数或者功能交付速度等指标来衡量团队的生产力,当有 AI 编程后,这些传统指标会得到巨大的提升,一天生产几千行代码是常事了。管理者可能会为此感到满意,但实际上,系统内部的技术债务正在快速累积,维护成本和风险也在同步攀升。

这是「技术管理」债务。我们需要建立新的、更能反映真实工程质量的度量体系。例如,关注代码的「可变性」(修改一个功能需要触碰多少文件)、「圈复杂度」、单元测试覆盖率的「质量」(而不仅仅是数量),以及 Code Review 中发现的深度问题的数量。架构师需要向管理层清晰地阐释 AI 编程的「债务风险」,推动建立更成熟的工程效能度量。

AI 编程助手是这个时代给予软件工程师最强大的杠杆之一,它有潜力将我们从繁琐的样板代码中解放出来,去专注于更具创造性的设计和思考。然而,任何强大的工具都伴随着巨大的责任和风险。

作为架构师,我们不能成为新技术的「勒德分子」,也不能成为盲目的「技术乐观派」。我们的角色,是确保这个强大的杠杆,成为放大我们架构意图和工程卓越的「放大器」,而不是制造技术债务的「复印机」。

这要求我们重新思考架构师的职责:我们不仅是蓝图的绘制者,更是蓝图的守护者;我们不仅要设计优雅的系统,更要设计能让优雅得以延续的「开发体系」;我们不仅要关注技术,更要塑造文化。通过建立清晰的规则、打造坚实的工程护栏、培育健康的开发者文化,我们才能确保,在 AI 赋能的未来,我们构建的软件系统,不仅跑得更快,而且走得更远、更稳。

以上。

AI 编程下的舒适区不能一直呆着

上周和 GZ 大佬在群里吹水,聊到 AI 编程,其中他所在的大厂已经全面推行 Cursor,他提到在 AI 时代下依赖 AI 会导致程序员失去思考力和代码能力。

虽然 GZ 的观点有些尖锐,但其核心表述的:过度依赖这类 AI 工具,可能会导致程序员的独立思考能力和实际编码能力下降。 是有道理的,人都是有惰性的,由简入奢易,由奢入简难

AI 给编程带来了「捷径」和「舒适区」。有即时的满足感,有认知负载的降低,还有我好像什么都会了的错觉。

  • 即时满足感: AI工具能迅速生成代码、解答疑问,这种即时满足感是非常诱人的。就像以前需要自己做饭(从买菜、洗菜、切菜到烹饪),现在可以直接点外卖,省时省力,结果直接呈现。
  • 认知负荷降低: 思考是耗能的。AI 工具在很多时候替我们完成了初步的思考和构建工作,大大降低了认知负荷。大脑天然倾向于节能,所以会不自觉地依赖这种轻松模式。
  • 我好像什么都会了的错觉: 有了AI的辅助,很多以前觉得困难或耗时的任务变得简单,这容易让人产生一种「能力快速提升」的错觉,从而更愿意待在这个由AI构建的「舒适区」里。

美国心理学家 NoelTichy 提出的理论人类对外部世界的认识可分为三个区域:舒适区,学习区,恐慌区。

参考下面这张图:

图片来源:即梦 AI 生成

我们天生是喜欢舒适区的,有在 AI 的加持下慢慢滑向依赖的自然趋势。

  • 习惯的养成: 一旦习惯了 AI 带来的便利,就很难再回到过去那种凡事亲力亲为的「简朴」状态。第一次用 AI 生成复杂函数可能还会仔细研究,第十次可能就直接 Accepted 了。惰性会让我们不自觉地选择最省力的方式。
  • 「温水煮青蛙」效应: 思考能力和编码能力的退化,往往不是一蹴而就的,而是像温水煮青蛙一样,在不知不觉中慢慢发生的。每次都依赖一点点,每次都少思考一点点,日积月累,当真正需要独立面对复杂问题时,才发现「内功」已经荒废了。
  • 对「不便」的容忍度降低: 习惯了 AI 的「秒回」和「全能」,一旦遇到 AI 无法解决或需要自己深入研究的问题,可能会更容易感到沮丧、不耐烦,甚至选择回避。

当我们真的养成了这种依赖的习惯,适应了这种舒服区,就会面对能力退化后的困境

  • 核心技能的生疏: 长期依赖 AI 完成编码和调试,会导致对编程语言特性、底层原理、算法数据结构、系统设计等核心技能的生疏。就像长期开车的人,突然让他走一段远路,可能会觉得非常吃力。
  • 问题解决能力的下降: 独立分析问题、定位问题、解决问题的能力,是在一次次「啃硬骨头」的过程中锻炼出来的。如果这个过程被 AI 替代,那么这种宝贵的实战经验就会缺失。当 AI 「失灵」或给出错误方案时,便会束手无策。
  • 创新能力的抑制: 真正的创新往往源于对问题的深刻理解和多角度的尝试。如果满足于AI给出的「标准答案」,就可能失去探索更优解或全新解决方案的动力和能力。
  • 学习动力的削弱: 「反正有AI」,这种心态可能会削弱一些人主动学习新知识、钻研深层技术的动力。因为「奢华」的生活方式似乎唾手可得,何必再去「简朴」地刻苦修炼呢?

就像我们家包包公主说的,这算不算「没苦硬吃」呢?

小朋友的视角不一样,也很形象。我们再深入思考一下:

从某种程度上说,如果 AI 已经能完美、高效地解决一些重复性的、模式化的、或者我们已经非常熟悉且没有太多新学习价值的问题,我们还非要「绕过」AI,坚持用原始的、低效的方式去「硬磕」,那确实有点「没苦硬吃」的味道。这就像明明有洗衣机,还非要每一件衣服都手洗,只为了「体验劳动的艰辛」,效率上肯定是不划算的。

但是,这里面有个核心的思考:我们「吃苦」的目的是什么?

比如,AI 能快速生成一个标准的 CRUD 代码框架,我们非要一行一行手动敲,而且这个过程对我们来说已经没有新的知识增量了,那这种「苦」可能就真的是「没必要硬吃」。时间应该花在更有价值的地方。

如果是为了「锻炼核心能力」、「深化理解」、「探索未知」而吃苦:

  • 打地基的苦: 对于初学者,或者在学习新技术、新领域时,有些基础的「苦」是必须吃的。比如,亲手搭建环境、理解底层原理、调试简单的错误。这个过程 AI 可以辅助,但不能完全替代,因为这是建立认知框架和培养解决问题直觉的过程。直接跳过,地基不牢。
  • 理解「所以然」的苦: AI 给出了一个方案,我们不满足于「知其然」,而是要去深究「所以然」——它为什么这么写?有没有其他方案?优劣何在?这个思考和验证的过程,可能需要查阅资料、动手实验,是「苦」的,但这种「苦」能让我们真正掌握知识,而不是停留在表面。
  • 攻坚克难的苦: 面对复杂的、AI 也难以完美解决的、或者需要创新性思维的问题时,我们需要自己去分析、设计、试错。这个过程无疑是「苦」的,但正是这种「苦」孕育了核心竞争力和真正的技术突破。
  • 保持「手感」和「警惕性」的苦: 就像运动员需要日常训练来保持状态一样,程序员偶尔也需要「刻意练习」一些基础技能,或者对AI的输出进行严格的审视和重构,以保持对代码的敏感度和对潜在问题的警惕性。这种「苦」是为了防止能力退化。

明明有更优解(AI能完美胜任且无损学习),却固执地选择低效、重复且对能力提升帮助不大的方式。这是一种低效的勤奋,属于没苦硬吃。为了掌握核心技能、深化理解、培养批判性思维、解决复杂问题而进行的有目的的、高价值的努力。这是一种战略性的投入。不是没苦硬吃。

回到「由简入奢易,由奢入简难」和「人的惰性」

正是因为惰性的存在,我们很容易滑向完全依赖 AI 的「奢华」生活,从而不自觉地回避了那些必要的、能提升核心能力的「苦」。这时候,有意识地去「吃一些必要的苦」,就不是「没苦硬吃」,而是对抗惰性、保持清醒、主动投资未来的表现。

举个例子:

  • AI能帮我们写单元测试。如果我们只是为了应付覆盖率,让 AI 生成然后看都不看,那可能会错过很多理解代码逻辑和边界情况的机会。
  • 但如果我们让 AI 生成初步的测试用例,然后再仔细分析这些用例是否覆盖了所有关键逻辑、边界条件、异常情况,并在此基础上进行补充和优化,甚至思考如何设计更健壮的被测试代码——这个过程虽然也「苦」,但价值巨大。

那如何对抗这种「人性」?

正因为「惰性」和「由简入奢易,由奢入简难」是人性的一部分,所以对抗它需要刻意的练习

1.保持警惕意识: 时刻提醒自己,AI 是工具,不是替代品。享受便利的同时,要警惕能力滑坡的风险。

2.刻意练习:

  • 主动「脱离」 AI : 对于一些核心模块或自己希望提升的领域,尝试不使用或少使用 AI,强迫自己独立思考和编码。
  • 深究 AI 的答案: 不满足于AI给出的结果,而是去理解它为什么这么做,它的原理是什么,有没有更好的方式。把 AI 的输出当成学习材料,而不是最终答案。
  • 复盘与总结: 即使使用了 AI,也要对过程和结果进行复盘,总结学到的东西和 AI 的局限性。

3.设定更高的目标: 将 AI 视为达到更高目标的「杠杆」,而不是满足于现有水平的「安乐椅」。比如,利用 AI 节省下来的时间去学习新的架构知识、去钻研更复杂的算法、去思考更有创造性的解决方案。让 AI 帮助我们去追求一种更高层次的、更依赖人类智慧的「奢华」。

4.强化元认知: 思考自己是如何思考的,学习自己是如何学习的。意识到自己可能陷入了惰性思维,并主动调整策略。

5.对「思考能力」和「代码能力」的重新定义

  • 思考能力: 可能从「如何从零开始解决问题」更多地转向「如何清晰地描述问题」、「如何将大问题分解给 AI」、「如何评估和整合 AI 提供的方案」、「如何在更高层面进行架构设计和技术决策」。
  • 代码能力: 可能从「熟练编写每一行具体代码」更多地转向「快速理解和修改 AI 生成的代码」、「保证代码质量、可维护性和安全性」、「进行有效的Code Review(即使是AI生成的代码)」。

AI 编程工具,确实像一把双刃剑。它带来的「即时满足感」和「认知负荷降低」,很容易就把我们拽进那个诱人的「舒适区」。毕竟,谁不爱走捷径呢?可问题也随之而来,长期依赖这种「外挂」,我们自己的「内功」——独立思考和编码能力,真可能在「温水煮青蛙」般的日常中,不知不觉就打了折扣。

当然,这也不是说我们就得跟 AI 划清界限,放着高效的工具不用,非得事事躬亲,那确实有点「低效勤奋」,甚至真成了「没苦硬吃」。关键在于,我们得想明白,哪些「苦」是值得吃的,是能真正提升我们核心竞争力的「战略性投入」。

  • 那些AI能完美胜任、重复性高且对我们知识增量有限的活儿,大胆交给 AI,这叫明智地利用工具,解放生产力
  • 但那些关乎「打地基」、深究「所以然」、需要「攻坚克难」的硬骨头,以及为了保持「手感」和「警惕性」的刻意练习——这些「苦」,恰恰是 AI 时代我们安身立命的本钱。它们能帮助我们构建真正的理解,培养批判性思维,并最终驾驭 AI,而不是被 AI 所定义

所以,面对AI,我们不能简单地「躺平」享受,也不能盲目地「排斥对抗」。更重要的是,要保持那份警惕意识,用刻意的练习去对抗人性的惰性

这不仅仅是关于代码怎么写得更快,更是关于我们如何重新定义自己的「思考能力」和「代码能力」,如何在 AI 的浪潮中,通过主动学习和深度思考,完成一次自我进化。说到底,AI 是工具,方向盘始终还是握在我们自己手里,是选择成为更智慧的「驾驶员」,还是满足于当一个「乘客」,这道题,得我们自己用心作答。

实在没辙了!只好祭出AI,给自己撸了个图片占位生成器

对于前端开发者而言,图片占位生成器是一个不可或缺的工具。

在实际开发中,我们经常会碰到这样的场景:产品展示页面的布局已经完成,各个模块都已就位,唯独缺少产品图片。而此时设计团队反馈:「图片素材还在制作中,预计下周交付。」

另一种常见情况是,在调试图片列表的响应式布局时,需要各种尺寸的测试图片。传统做法是通过搜索引擎寻找合适的图片,然后逐一下载、裁剪、调整尺寸。这个过程往往耗时良久,严重影响开发效率。

除了效率问题,版权风险也不容忽视。在项目中使用网络图片时,我们必须考虑:这些图片是否有版权限制?是否适合在商业项目中使用?这些问题如果处理不当,可能会给项目带来法律风险。

还有一些场景,如我们动态生成图片,在图片上显示提示的内容这种相对小众的场景。

本周刚好有一个需求是给飞书捷径做一个小功能用到了图片占位生成。梳理完需求,大概如下:

  1. 能指定宽和高
  2. 能自定义文字
  3. 能指定文本颜色和背景色
  4. 能指定图片格式输出,支持 PNG
  5. 能指定文本大小
  6. 能在飞书中使用

首先我们看一下有哪些在线的图片占位生成器可用的。

我们先让最新的 Claude-4-Opus 大模型给出 10 个地址,如下图:

1. **Placeholder.com【不可用】**
- **URL**: https://via.placeholder.com/
- **使用方法**: `https://via.placeholder.com/300x200`
- **特点**: 简单易用,支持自定义颜色和文字

2. **Lorem Picsum【能用,随机真实图片】**
- **URL**: https://picsum.photos/
- **使用方法**: `https://picsum.photos/200/300`
- **特点**: 提供随机的高质量真实图片

3. **Placehold.it【跳到 Placeholder.com 也不可用了】**
- **URL**: https://placehold.it/
- **使用方法**: `https://placehold.it/350x150`
- **特点**: 经典的占位图服务,支持多种格式

4. **PlaceIMG【不可用】**
- **URL**: https://placeimg.com/
- **使用方法**: `https://placeimg.com/640/480/any`
- **特点**: 可选择不同类别(动物、建筑、自然等)

5. **Dummy Image【可用,不支持中文】**
- **URL**: https://dummyimage.com/
- **使用方法**: `https://dummyimage.com/600x400/000/fff`
- **特点**: 高度可定制,支持自定义背景色和文字颜色

6. **LoremFlickr【可用,不支持自定义内容】**
- **URL**: https://loremflickr.com/
- **使用方法**: `https://loremflickr.com/320/240`
- **特点**: 基于Flickr的真实图片,支持关键词搜索

7. **Placekitten【不可用】**
- **URL**: https://placekitten.com/
- **使用方法**: `https://placekitten.com/200/300`
- **特点**: 提供可爱的猫咪图片作为占位图

8. **Unsplash Source【不可用】**
- **URL**: https://source.unsplash.com/
- **使用方法**: `https://source.unsplash.com/1600x900/?nature`
- **特点**: 使用Unsplash的高质量图片库

9. **PlaceBear【可用,不支持自定义内容】**
- **URL**: https://placebear.com/
- **使用方法**: `https://placebear.com/200/300`
- **特点**: 提供熊的图片作为占位图

10. **FakeIMG.pl【可用,不支持中文】**
- **URL**: https://fakeimg.pl/
- **使用方法**: `https://fakeimg.pl/300x200/ff0000/ffffff?text=Hello`
- **特点**: 支持自定义文字、字体和颜色

以上 10 个站点看下来,就 1 和 5 相对符合需求,但都不支持中文。

AI 不行,搜索来凑,一顿 Goole 下来,又找到以下的几个:

1.placehold.co【可用,不支持中文】

示例:https://placehold.co/600×400?text=Hello+World

2.fakeimg.pl

示例:https://fakeimg.pl/300/?text=哈哈&font=noto

fakeimg.pl 在功能上需求都能满足,不管是大小、字体、中文,但是它在飞书中作为附件使用的时候竟然出错了。使用 dummyimage 却没有这个问题。 试了几次发现怎么都绕不过去,只能另想他法。

3.tool.lu

示例:https://iph.href.lu/600×400?text=哈哈哈

tool.lu 的图片占位功能能完全满足需求,但是和 2 一样,在飞书下会报错。

4.devtool.tech

界面最好的一个生成站点,但是格式是 SVG 的

以上只是基本可用的,还不排除那些功能不满足,失效了的,各种,折腾了两个小时,能满足需求的飞书用不了,飞书能用的不支持中文,死循环了。

只能自己撸了

祭出 AI,花了两小时(代码只花了半小时,还包括框架搭建),本地运行没有问题,把代码部署到线上,能正常显示,但是飞书用不了,一样的报错:

execute error,捷径执行出错:
Error: execute原始执行结果:
捷径返回错误码: FieldCode.Success 
 转换结果:transform cell value fail

这回是自己写的代码,终于可以定位并解决问题了。对比能用的地址和不能用的地址,从头文件中发现了两个字段的差别,一个是跨域:Access-Control-Allow-Origin,一个是返回长度:Content-Length

最终试验发现是:Content-Length

可能飞书在获取图片并上传成附件的时候做了判断或者校验(就是个 BUG)。

这个功能已经作为免费的服务放到了开发哥网站(还记得之前 Vibe Coding 写的那个网站不):

https://www.kaifage.com/tools/placeholder

以上。

多说一句,即梦 3.0 生图中的汉字越来越精细了。