GLM 5.3：超越前代的开源新标杆

智谱 AI（Zhipu）正式发布了 GLM 5.3，这是继另一款大型模型后当天的第二个重磅开源发布。该模型被定位为极具竞争力的顶级开源架构，其性能表现足以与当前最先进的闭源前沿模型相抗衡。相较于前作 GLM 5.2，GLM 5.3 在能力上实现了显著跃升。尽管目前模型权重尚未立即开放下载，官方表示将在完成安全审查和充分准备后的几周内于 Hugging Face 发布。值得注意的是，GLM 5.3 并未进行大规模的基础训练扩展，而是主要依赖后训练阶段（Post-training）的缩放优化来实现能力的提升。

"It does seem very comparable to Kimmy K3 in terms of scores and benchmarks."

这一策略表明，后训练数据的优化对于提升模型推理能力至关重要。虽然 GLM 5.3 仍然属于超大参数规模，对于绝大多数普通用户而言，即使经过量化处理也难以在本地硬件上运行，但其作为万亿参数以下（Sub-trillion）的模型，能够在多个领域与前沿闭源模型掰手腕。这种在保持较小 footprint 的同时实现高性能的目标，正是当前大模型发展的终极追求之一。

参数规模与竞品性能深度对比

GLM 5.3 采用了混合专家（MoE）架构，总参数量约为 7,500亿，其中活跃参数约为 400亿。这一规模在开源模型中依然庞大，但相较于其他顶级竞品则显得更为紧凑。例如，Kimi K3 拥有 2.8万亿参数，而 DeepSeek V4 Pro (0813版本) 则拥有 1.6万亿参数。GLM 5.3 在编码等特定领域甚至展现出超越 DeepSeek V4 Pro 的潜力，这进一步印证了其架构效率。

以下是主要模型的关键参数与定位对比：

模型名称 总参数量 (Approx.) 活跃参数/架构类型 备注
GLM 5.3 ~750 Billion (MoE) ~40 Billion Active 智谱最新开源模型，后训练优化
Kimi K3 ~2.8 Trillion 信息不足 (MoE) 主要对标闭源前沿模型
DeepSeek V4 Pro (0813) ~1.6 Trillion 信息不足 近期发布，编码能力强
Qwen 3.8 Max 信息不足 信息不足 高性能闭源/开源混合参考

从数据可以看出，GLM 5.3 在参数量仅为 Kimi K3 四分之一左右的情况下，依然能在基准测试中保持极高的竞争力。这种效率优势使得它在资源受限的场景下具有独特的吸引力，同时也证明了模型能力不再单纯依赖参数总量的堆砌。官方发布的基准测试涵盖了多个维度，包括与 Qwen 3.8 Max 和 DeepSeek V4 Pro 的直接对比，结果显示 GLM 5.3 在编码任务中表现尤为突出。

训练细节、API变更与本地部署体验

在技术实现层面，GLM 5.3 引入了漏洞发现数据（Vulnerability discovery data）进行后训练，这使得模型不仅擅长识别孤立缺陷，更能通过多阶段推理形成完整的攻击链计划。这一特性引发了关于开源模型安全性的讨论，但官方强调这是为了提升模型的稳健性而非制造恐慌。此外，API 层面有一个重要变更：GLM 5.3 不再支持禁用思考模式（Thinking）。这意味着用户必须接受模型在推理过程中产生的额外计算开销。

"It was reasoning across multiple stages of exploits forming coherent plans for complete chains."

尽管启用了最高级别的推理努力，GLM 5.3 在平均输出 Token 数（Average output tokens per task）上相比 GLM 5.2 有显著下降。这一数据表明，新模型在推理效率上有所提升，能够在更少的步骤内达成目标，从而在一定程度上缓解了因禁用“关闭思考”选项而可能带来的延迟问题。为了测试这一特性，作者购买了智谱的编程计划（约 $65/月），并利用其提供的 1.5 倍限时配额提升（截至8月31日），通过智谱自家的 Zcode 应用进行深度测试。Zcode 界面类似于已停更的 OpenAI Codex，提供了流畅的代码交互体验。

浏览器 OS V2.7：自动化测试实录

在具体的功能验证环节，作者运行了 BrowserOS V2.7 任务。该版本基于之前的反馈进行了更新，要求模型生成具有动态效果的程序化壁纸并集成邮件客户端。测试结果显示，GLM 5.3 成功生成了包含声音效果、时间显示及动态背景的完整浏览器界面。与之前的 Qwen 3.827B 相比，GLM 5.3 生成的界面视觉效果更佳（"less hideous"），且支持右键菜单等高级交互功能。

测试过程中的关键表现包括： 1. 界面生成：成功渲染单文件、零深度的浏览器环境。 2. 交互功能：支持最小化/最大化全屏操作，并具备声音反馈。 3. 动态元素：实现了用户建议的动态壁纸切换和邮件通知弹窗。

"The background's cool. It’s definitely less hideous than the Quen 3.827B..."

尽管邮件通知弹窗被作者戏称为“令人作呕”（Disgusting），但这恰恰证明了模型能够处理复杂的 UI 事件和视觉反馈。整个测试过程展示了 GLM 5.3 在复杂多模态任务执行上的成熟度，特别是在理解用户细微需求（如动态壁纸）并转化为可交互代码方面的能力。这一案例不仅验证了模型的基准分数，更通过实际应用场景展示了其作为通用智能代理（Agent）的潜力。

Omni City：GTA克隆游戏的初步体验与基础功能

视频首先测试了GLM 5.3生成的“Omni City”，一款类似GTA的开放世界游戏。启动后，Start Menu界面简洁无动态特效但结构完整。玩家能够进入车辆并驾驶，虽然引擎音效缺失导致沉浸感稍弱（仅获三星评价），但游戏核心机制运行流畅。值得注意的是，碰撞后的NPC不会消失且会引来警车追捕，这一设计增加了游戏的真实感和挑战性。最终玩家因违规被通缉并罚款100美元， respawn机制正常。

“I did see a police car chasing us. I didn't... the folks we hit don't necessarily disappear.”

除了核心玩法，视频还测试了系统内置的浏览器和邮件功能。邮件通知作为浏览器的一部分正常运作，且Mini Map小地图显示清晰。视频制作者对比了不同版本的模型表现，指出Quen 3.627B（较旧版本）在角色行走动画上优于当前测试模型，其腿部动作更为独立自然。尽管存在这些细微差距，Omni City的整体完成度被认为“competently put together”（组装得当），是一个合格的基础原型。

Void Runner与系统工具：游戏流畅度及办公应用测试

接下来是“Void Runner”，一款小行星射击类游戏。视频制作者对飞船移动的流体感表示满意，并发现可以通过鼠标光标直接控制方向。游戏中包含能量道具和引擎发光特效，但碰撞判定机制明确（不可撞击特定障碍物）。随后测试了系统的文件管理、邮件分享及记事本功能。“Save as file.txt”操作被标记为acceptable（可接受），且系统音效并未像以往那样令人烦躁。

“The sound effects are actually not infuriating, which is not something they would normally infuriate me.”

在系统工具方面，帮助菜单列出了极长的潜在命令列表。视频制作者尝试了Notepad Synth应用，该工具能显示按键的具体频率并支持正弦波、锯齿波及三角波的切换。虽然无法调整八度音阶，但可调节的延迟效果（adjustable delay）被认为是一个亮点。此外，系统壁纸功能展示了Warp Starfield、Liquid Light及Neon Horizon等程序化背景。强调色（accent color）能同步改变动态壁纸的颜色，且24小时时钟选项和暂停/恢复播放功能均正常运作。

纽约滑板模拟器：C++生成与视觉缺陷的争议

视频的高潮部分是使用C++生成的“纽约市滑板模拟器”。该测试要求生成基于200年代初纽约街区的地图，耗时38分48秒后完成生成。由于模型默认无视觉能力（vision），制作者通过脚本验证按键和技巧，并利用Zcode工具发送图像进行反馈。生成的滑板物理引擎表现尚可：滑板与玩家角色独立，支持半管技巧、行人互动及车辆滑行（grinding）。

“This is worse than I expected by a significant amount. ... Quen 3.8 Max is a 2.4 trillion parameter model, but it absolutely blew this away.”

然而，视频制作者对视觉渲染质量表示极度失望。尽管物理机制（如喷泉滑行）和技巧系统有一定深度，但整体画面表现远低于预期。制作者明确指出，如果这是来自较小参数模型（如3.827B）的结果尚可接受，但作为GLM 5.3的输出则令人沮丧。与拥有2.4万亿参数的Quen 3.8 Max相比，GLM 5.3在视觉呈现上存在显著差距。尽管滑板独立性和部分环境互动（如半管调试）值得肯定，但整体结果被评价为“let down”（令人失望），暗示其在复杂3D场景的视觉生成上仍有不足。

新测试用例：1980年代主题摔跤游戏生成

最后，视频引入了一个新的提示词（prompt），旨在测试模型对未包含在训练数据中的新兴或特定风格概念的处理能力。该提示要求生成一款“1980年代主题的3D摔跤游戏”，风格需达到高端独立游戏的水平。具体要求包括：自由游玩模式（freeplay style）、开场屏幕、程序化音乐及风格化的视觉元素。

“Create a 1980s themes themed 3D wrestling game. The game should be at the level of quality one would see from a high-end indie game.”

这一测试旨在评估模型在缺乏先验训练数据情况下的泛化能力和创意生成能力。虽然视频片段在此处结束，未展示最终结果，但该测试案例的引入表明评测者正在探索模型在更复杂、更具风格化约束下的代码生成潜力。通过对比前两个测试（GTA克隆和滑板模拟），这一新案例试图填补对特定美学风格和非主流游戏类型生成能力的评估空白。

摔跤游戏生成：从网络故障到视觉修复

测试者尝试使用GLM 5.3开发一款名为“Mega Slam 86”的80年代风格摔跤游戏，但过程充满波折。首要挑战是服务端的稳定性问题，测试者指出该平台在多次使用中均出现不可靠的情况。 > “This was really frustrating because it kept having network errors. Their service is not very reliable.” 尽管存在这些技术障碍，模型最终仍成功生成了具备80年代美学特征的游戏框架。然而，初始生成的版本存在严重的视觉缺陷：光照过度曝光导致画面完全过曝，使得玩家无法看清摔跤手或擂台细节。测试者通过向模型提供具体的调试指令——包括降低光照强度、减少泛光效果（bloom）并调整曝光度——成功解决了这一问题。这一过程表明，虽然模型具备基础的场景构建能力，但在视觉参数调优上仍需人工干预才能呈现可用效果。

游戏逻辑与物理引擎的缺陷分析

在修复视觉问题后，测试者进行了实际的游戏操作体验。虽然游戏包含了裁判、观众席以及带有标语的观众等细节元素，但在核心玩法逻辑上暴露出明显短板。测试者发现角色动作的物理朝向和交互逻辑存在严重错误。例如，在执行“Tiger Torpedo”等招式时，角色的运动轨迹和身体朝向不符合摔跤运动的物理常识，导致角色被直接“砸穿”桌子等荒谬场景。 > “It could be really good, but like the people are not quite oriented properly... This is definitely one I'll be very interested to see the output from a number of different models.” 尽管游戏界面中出现了大屏幕回放等酷炫特效，但核心交互体验仅完成了约80%，剩余20%的关键物理逻辑缺失使得整体表现大打折扣。测试者认为，虽然模型能生成看似完整的游戏框架，但在处理复杂角色动画和物理碰撞逻辑时，仍需依赖其他更先进的模型进行对比验证。

RB26引擎3D建模与打印可行性评估

除了游戏开发，测试者还利用GLM 5.3生成了一个可3D打印的Inline-6 RB26引擎模型。该任务耗时约33分钟，相较于一些更简单的HTML生成测试而言，这一效率表现尚可。模型成功输出了SCAD文件，并指导用户通过特定步骤（如选择部件、按F6导出）生成STL文件。生成的模型包含六个独立的气缸部分和一个油盖，整体结构完整且细节清晰。然而，在评估3D打印可行性时，测试者发现了显著的设计缺陷。模型未充分考虑支撑结构的需求，特别是某些悬空部件和突出的“小凸起”（nubs）超出了打印床的范围或形成空中悬浮结构，这在实际打印中会导致失败。 > “This is not really able to be printed without supports... It's not possible to print this specific thing without having a gigantic amount of supports.” 尽管涡轮部分的朝向可能存在垂直/水平方向的偏差，但模型在几何生成的准确性上表现优异，能够识别出潜在的打印障碍（如悬空桥接问题），显示出其在工程建模方面的潜力，但仍需后期人工修正以符合3D打印的物理限制。

CAD 模型修复与细节处理能力

评测者首先测试了 GLM 5.3 对复杂 CAD 模型的修复能力，重点观察其处理支撑结构（Supports）和微小几何缺陷的表现。尽管在操作初期因未单独选择部件而误判模型损坏程度，但 AI 最终生成的结果在美学和功能上均有显著提升。它成功识别并修复了从特定元素下方伸出的微小凸起（nubs），包括风道部分的细节问题。 这种对局部几何特征的敏锐捕捉，证明了模型在处理工程级复杂结构时的逻辑推理能力。对于皮带、滑轮及电机前端等机械部件，模型不仅恢复了其基本形态，还展现了合理的材质质感。值得注意的是，AI 在确定哪些部件需要额外支撑时表现出独特的算法逻辑，这种基于物理直觉的判断令人印象深刻。 经过一夜的生成与优化，整体模型外观整洁且结构合理，验证了其在辅助工程设计方面的潜力。

"Even if I may have mistakenly told it like this is seriously messed up... it ultimately ended up in producing a significantly better result."

3D 手表网站的前端渲染与材质表现

随后，评测转向了一个基于 WebGL/Three.js 的交互式手表展示网站生成任务。该测试旨在评估模型在前端设计、3D 建模及实时渲染效果上的综合水平。加载完成后，评测者发现存在两个主要交互缺陷：表带方向渲染错误以及鼠标无法控制相机上下视角的平移。尽管存在这些交互障碍，模型在视觉呈现上仍展现出令人惊讶的细节。以 "Riviera Solstice" 型号为例，表盘背面的拉丝金属纹理与蚀刻文字的结合效果极佳，这种精细的材质表现通常难以在自动生成内容中看到。 表冠、表盘纹理及材质光泽度均表现出色，甚至呈现出类似 KeyShot 软件的光照反射效果（Emissive properties）。虽然秒针数量异常且表带方向有误，但整体材质渲染质量超越了预期。这种在静态视觉质量和动态交互控制之间的不平衡，反映了当前生成式 AI 在处理复杂前端逻辑时的局限性。

"The way it both has like this brushed material as well as the text written on it in a pretty darn nice way, I would say, all things considered."

游戏生成任务的性能瓶颈与迭代改进

在更具挑战性的 "Street Eat" 游戏生成测试中，GLM 5.3 在不到 40 分钟内生成了包含电影式开场动画和语音资产的游戏原型。然而，实际运行效果远低于预期。游戏内的城市环境缺乏动态元素，行人静止不动，玩家操作体验极差，被评测者形容为 "几乎没有任何移动"。 相比之下，此前测试的 Quen 27B 模型生成的游戏在行人移动等基础交互上表现更佳。面对这一失败，评测者要求模型重试并提升质量（V2 版本）。经过约 23.5 分钟的迭代，新版本增加了音频支持并声称改进了体验。然而，初步测试显示核心移动功能依然失效，玩家角色完全无法控制位移。 这表明模型在生成具有复杂物理交互和状态管理的游戏代码时，存在严重的逻辑断层。评测者认为当前结果仅相当于小型本地模型的水平，未能展现出大语言模型应有的复杂逻辑构建能力。

"I'm really so far I've not been hugely impressed with any of these 3JS results... It seems like this thing's really just trying as little as possible."

测试策略调整与后续方向

鉴于 GLM 5.3 在 Web 前端和复杂游戏逻辑生成上的持续低迷表现，评测者决定调整测试策略。模型在简单的视觉渲染上有所长进，但在需要深层逻辑和物理模拟的任务中表现乏力。 为了更全面地评估其能力边界，评测者计划暂时搁置对同类前端/游戏任务的重复测试，转而探索更能体现模型优势的领域。特别是针对 "物理世界" 相关的生成任务进行测试，以观察其在模拟现实物理规律方面的潜在能力。 这种策略调整旨在避免在模型不擅长的领域浪费资源，转而寻找能够激发其最大潜力的应用场景。目前的评价处于停滞状态，评测者对模型能否在后续测试中实现质的飞跃持谨慎观望态度。

"I don't want to continue giving it tests in scopes that it's consistently not really being impressive."

GLM 5.3在Subway FPS测试中的表现评估

在对GLM 5.3进行传统基准测试时，评测者选择了Subway FPS作为第一个考察对象。经过约22分30秒的运行，模型展现出了具备竞争力的图形生成能力。评测者特别指出，游戏中的武器模型质量良好，且支持左右移动视角。场景中的自动贩卖机被评价为“我在该测试中见过的最好的”，显示出模型在特定物体纹理和细节处理上的优势。尽管整体画面略显阴暗，但通过调整亮度滑块至220%，环境细节得以清晰呈现。此外，模型还生成了一些罕见元素，如子弹在环境中留下的永久孔洞、血迹污渍以及老鼠，这些细节增加了场景的真实感和趣味性。虽然画面中缺少列车这一常见元素，但评测者认为这属于设计选择而非缺陷。

"Good weapon model. Also some side to side movement... These vending machines are arguably the best vending machines I've seen in this."

尽管Subway FPS测试表现尚可，但评测者认为这并未完全展现出GLM 5.3的预期潜力。鉴于该模型在基准测试中表现相当于Kim K3水平，评测者希望进行更具挑战性的任务来验证其实际能力。因此，他决定放弃常规的图形生成测试，转而尝试一个涉及旧电子设备与现代计算机交互的逆向工程任务。这一转变旨在探索模型在复杂逻辑推理和硬件协议理解方面的极限，而非仅仅停留在视觉生成的表面。

逆向工程挑战：将iPod Nano变为GPU监控显示器

为了测试GLM 5.3在复杂系统逆向工程与协议解析方面的能力，评测者引入了一个极具挑战性的实验：将一台旧款iPod Nano（第4代）连接至电脑，并让模型生成代码或指令，使其屏幕显示当前电脑的GPU利用率等遥测数据。评测者坦言，这一任务极其困难，因为模型需要逆向工程iPod的显示协议、计算能力以及老旧连接接口的数据传输方式。这要求模型不仅理解软件层面的数据获取，还要掌握硬件层面的信号传输和协议兼容。

"I have an old iPod Nano here... I want this to show the GPU utilization of this computer. Because this is more in line with, I suppose, its abilities..."

评测者认为，这一任务更能反映模型在漏洞生成或系统控制类能力上的真实水平。他期望看到GLM 5.3能够像人类工程师一样，通过查阅开源资料、分析硬件引脚定义以及编写底层驱动脚本来实现这一目标。然而，随着测试的进行，模型虽然展现了大量的尝试和逻辑推演过程，但最终未能成功实现iPod屏幕的实时数据显示功能。这一失败并非因为模型缺乏创意或努力，而是受限于硬件物理限制和协议复杂性。评测者通过记录整个测试过程，展示了模型在尝试解决这一难题时的详细步骤和遇到的障碍。

测试失败原因分析与模型能力边界探讨

在长达数小时的尝试中，GLM 5.3消耗了评测者两次5小时的时间限制以及周限额的41%。模型尝试了多种方案，包括生成前端网站以可视化数据、编写Arduino脚本来调试引脚连接等。评测者指出，模型曾建议通过跳线iPod电缆的特定引脚（如13、15和16）来调试USB连接，并编写了相应的Arduino脚本。然而，由于评测者缺乏适配的线缆和硬件接口，这一方案无法在物理层面执行。更关键的是，iPod内部电池已完全失效，一旦断开电源设备即关机，导致任何需要持续供电的调试方案均告失败。

"It got to the point where it was like, 'I notice you have Arduino build tools on this system. How about we like jump some of the pins...'

尽管最终结果未达预期，但评测者强调，不能仅以成败论英雄。模型在测试过程中展现了惊人的工作量和创造力，包括生成详细的3D JS模拟图、撰写技术文档风格的复盘报告等。评测者认为，这一测试揭示了GLM 5.3在微逆向工程能力上的潜力与局限。虽然模型未能像GPT-5.6 Soul on Ultra那样在类似任务中取得功能性结果，但其尝试过程本身证明了其在处理复杂、多步骤硬件交互问题时的逻辑深度。评测者总结道，这类测试的价值在于探索模型能力的边界，而非仅仅追求即时的成功输出。

逆向工程挑战：零硬件修改实现 iPod Nano 实时显示 PC 状态

本次测试的核心案例是一个极具挑战性的逆向工程项目：目标是在不进行任何硬件修改的前提下，让一台 2008 年的 iPod Nano（经确认为第四代而非第五代）显示其连接的 PC 的实时系统状态。这一任务从简单的目标设定演变为复杂的固件考古学（Firmware Archaeology）过程。作者首先从 Apple 的 CDN 下载并解密了 N58 固件包、引导加载程序及诊断工具，随后在设备上对其进行拆解分析。通过映射模块和显示栈，作者识别出了关键的接口信息。

在载荷工程阶段，开发者从零开始编写了一个位置独立的 ARM V6 Thumb 模块。该模块通过 EFI 管道渲染器针对 Apple 的显示协议进行优化，并构建了一个自定义的 USB 设备栈来响应控制传输。整个 Payload 被封装在一个手写的 PE32 文件中，并通过自定义的 Go 工具链切片嵌入到 Apple 固件卷中。这一过程涉及大量的底层代码编写和协议逆向，旨在绕过苹果系统的常规限制。

"That's great. Thanks, cuz that was my mistake... make a 2008 music player display live vitals of the PC it's plugged into with zero hardware modification."

技术壁垒与调试困境：固件规则的血泪教训

随着项目深入，开发者遭遇了严峻的技术障碍。整个调试过程经历了大约 20 次电源循环，每次失败都揭示了固件的一条规则。例如，FFS（Flash File System）的校验和必须严格位于头部的特定字节位置；错误的偏移量或损坏的 GUID 会导致静默启动死亡。此外，Boot ROM 执行所需的入口桩（entry stub）必须精确位于文件偏移处，否则 Boot ROM 将执行零值。

数据传输也面临严格限制：Boot ROM 的 DFU（Device Firmware Update）缓冲区上限约为 152 KB，导致上传在块 149 处失败。更复杂的是 EFI 的分发顺序是位置敏感的，插入填充文件的 Payload 无法运行；位于第 28 位的 BDS App 会抢占控制权。最终的关键阻碍在于 DXE Core 仅从 LZMA 压缩部分启动模块，而开发者工具链生成的 LZMA 流被 Apple 的解码器拒绝。由于无法逆向工程出 Apple 确切的编码器设置，项目被迫中止。

"Roughly 20 power cycles, each returning one bit of truth. Each failure taught firmware's rules the hard way... The tool chains LZMA encoder produces streams Apple's decoder rejects."

模型表现评估：预期落差与具体案例反馈

尽管逆向工程过程令人印象深刻，但作者对 GLM 5.3 模型在整体测试中的表现感到失望。与基于基准测试的预期相比，实际结果并不强劲。作者特别指出了一些具体案例的失败：例如在 C++ 任务中，模型的表现远低于预期；而在生成“Skate”游戏代码时，不仅质量不佳，甚至在给予第二次机会后导致功能完全崩溃。

在其他测试中，虽然摔跤游戏的生成效果出色，但由于角色方向异常导致游戏无法正常运行；“Street Heat”等其他项目则需要在服务器环境下运行，且作者感觉模型在这些任务中并未全力以赴。所有测试均在最大思维模式（max thinking mode）下进行，排除了设置问题。作者认为模型虽然展现了智能和硬核的故障排除能力，但在最终产出上缺乏惊艳感。

"I don't really have a wonderful takeaway here because I find that basically a lot of the results we saw were just not as potent as I would have expected to see based off of the benchmarks... It felt like with a lot of these specific types of results, it just wasn't trying very hard."

总结与后续展望：开放态度以待社区反馈

综上所述，GLM 5.3 模型在本次测试中展现了强大的逆向工程逻辑和调试能力，但在实际代码生成和执行效果上并未达到作者的预期高度。作者承认模型在处理复杂故障排除时表现出色，但在具体应用如游戏生成和特定语言任务中存在明显短板。由于这是新发布的模型，作者保持开放态度，希望观察社区用户的实际体验是否与自己的测试结果一致。

"It was very cool. It was smart and clever and it did a lot of like hardcore troubleshooting, reverse engineering... I don't 100% know what to make of it right now."

作者表示将对后续发布的 Gemini 3.7 Flash 以及 Rednote 的 Dots LLM3（其前身曾带来幽默体验）保持关注，并邀请观众在评论区分享他们对 GLM 5.3 的使用感受，以进一步验证本次测试的结论。