每个 UClass 都持有一个“原型对象”——Class Default Object，简称 CDO。它存储了该类所有 UPROPERTY 的默认值。当 NewObject 创建新实例时，属性值是从 CDO 逐字段复制过来的，而非依赖 C++ 构造函数中的成员初始化列表。fill:#333;important;important;fill:none;color:#333;color:#333;im

前面四章谈了认知框架、能力盘点、技术路线和工程化实践。但转型终究要落在现实的地上。你有日常工作要做，有房贷或房租要付，有可能还有家庭需要照顾，每天能挤出来学习的时间可能只有一两个小时。在这些约束下，怎么把"转型"从一个念头变成实际发生的事情？怎么从第一步走到能找到AI工程师工作（或者把当前工作内容转向AI）的那一天？这一章不谈理想状态，只谈现实约束下的最优解。

AI行业里有一个心照不宣的秘密：绝大多数AI项目死在了从Demo到Production的路上。一个用Jupyter Notebook搭出来的Demo可能只花了一个下午。产品经理看了演示之后兴奋得不行，拍板说"就做这个"。然后你开始做真正的工程化——把同样的功能做到可以在生产环境里7×24小时稳定服务，可以应对突发的流量高峰，可以在依赖的外部服务挂掉时优雅降级，可以在出问题时快速定位根因，可以让其他

想象一个场景。你在终端里输入一段代码，代码的逻辑是确定性的——给定输入A，必然得到输出B，每次都如此，没有例外。现在想象另一个场景。你让一个大语言模型来决定该输入什么代码——模型根据你的自然语言描述"推理"出一段代码，然后自动提交给终端执行。这段代码是什么？你事先不知道。模型自己也无法精确预知——大语言模型的输出是采样过程的结果，受到温度参数、上下文窗口中的所有文本、模型对齐训练的综合影响。同样的

想象一个场景。你在终端里输入一段代码，代码的逻辑是确定性的——给定输入A，必然得到输出B，每次都如此，没有例外。现在想象另一个场景。你让一个大语言模型来决定该输入什么代码——模型根据你的自然语言描述"推理"出一段代码，然后自动提交给终端执行。这段代码是什么？你事先不知道。模型自己也无法精确预知——大语言模型的输出是采样过程的结果，受到温度参数、上下文窗口中的所有文本、模型对齐训练的综合影响。同样的

转型这件事，最容易犯的错误是从零开始。我注意到一个几乎带有规律性的现象：很多工程师一旦决定往AI方向走，第一反应就是打开Coursera或者B站，从吴恩达的机器学习课第一讲开始看，仿佛过去几年写的代码、踩的坑、做的系统设计全都不算数了。他们会买一本《深度学习》花书摆在桌上（更诚实一点的人会承认看了二十页就放下了），会关注一大堆AI领域的技术博主，会焦虑地比对自己跟那些知乎上"本科清华硕博斯坦福"的

自定义资产类型通常继承UDataAsset或UObject，加上 UCLASS/UPROPERTY。反射信息（UClass、FProperty），供 Details 和资产浏览器使用；序列化（保存/加载 uasset），无需手写格式。再配合UFactory（定义"新建"时如何创建实例）、（图标、右键菜单、双击行为），就能在内容浏览器里完整集成自定义资产。编辑器扩展的 C++ 代码同样遵守 UObj

OpenClaw 跑起来之后，你会遇到各种日常问题：通道断了、模型 API 超额了、某个 Skill 行为异常……本章是一本运维手册，按场景整理了常用的排查思路和操作命令。

Cron Jobs 就是定时任务：在指定时间或时间间隔触发一段操作。在 OpenClaw 里，你可以用 Cron Jobs 让它每天早上 8 点给你发今日简报（天气、日历、收件箱摘要），每 2 小时检查一次 CI/CD 状态有失败时主动告警，每周一整理一次你的 GitHub Issue 积压，或者每晚 11 点发一条「今天的未完成 Todo」。

走到这里，你已经把 OpenClaw 从头到脚拆了一遍。Part I 用产品视角理解了 OpenClaw 是什么以及它「个人 Agent OS」的定位。Part II 深入了 Session、Agent、Channel、Nodes/Browser 四大核心抽象。Part III 从源码层面走过了 Gateway 的骨架、启动流程，以及一条消息从入站到回复的完整链路。Part IV 解构了 Skil