自研C++节点编辑器：摆脱第三方库束缚，AI辅助下的核心架构实践

写一个自己用的 C++ 节点编辑器，最大的感受是什么？不是连线算法难写，不是鼠标交互难调，而是当你把第三方节点库接进自己的业务架构之后，才发现每一个定制需求都要绕过它原有的设计假设：改样式要看内部实现，加节点类型要适配它的默认生命周期，升级一个小版本，整个存档读写可能都得跟着重写。

这个项目做到第十弹，本质上就是把整个流程反过来：不迁就库，而是自己把控编辑器每一层的行为。配合 AI 辅助编码，把节点注册、画布交互、序列化、执行引擎都掌握在自己手里，同时还能保持版本迭代的节奏。

这一轮更新，除了常规的新功能之外，花了不少时间处理一类“看起来没问题，跑起来就出错”的 Bug。其中最典型的那个，和 C++ 标准库函数签名有关。AI 生成的清理节点代码用了std::remove_if，看起来专业，结果是节点只是被搬到容器尾部，根本没被真正删除。这个坑后面会单独复盘。

这篇内容会从“为什么坚持自研”讲起，梳理节点编辑器的核心概念，再拆解本轮重大更新的设计思路和关键代码，最后用实际 Bug 来反推 AI 辅助开发中的边界。如果你也在做类似的编辑器项目，或者正在用 AI 写 C++，这一篇应该能给你一些可落地的参考。

1. 这篇文章真正要解决的问题

CSDN 上关于节点编辑器的文章很多，但大部分在讲“怎么用某个现成库”，或者贴一段NodeEditor的示例就结束了。真正让开发者头疼的，往往是库已经接入、业务场景开始变复杂之后的阶段：

• 想给节点增加自定义外观，可能需要继承一个复杂的渲染基类。
• 想优化连线命中检测，但鼠标事件已经被库内部吞掉了。
• 想改存档格式，但库自带的序列化方案和你业务的配置系统对不上。
• 想升级版本，结果发现 API 不兼容，以前保存的场景打不开。
• 想在运行时屏蔽某个引脚或动态增删连接，库的扩展点又不够开放。

这些问题的共同本质是：库帮你解决 80% 的通用场景，但最后 20% 恰好是你的业务核心，而这 20% 往往是库最不灵活的角落。

所以这篇文章不只是讲“更新了什么功能”，更想讲清楚一条决策路径：为什么在已有第三方库可用的情况下，反而应该考虑自研；自研之后，如何用 AI 辅助把迭代成本降下来；以及怎么避免 AI 生成的代码引入隐蔽的 C++ 陷阱。

适合读这篇文章的人有三类：

1. 正在接入或已经接入第三方节点编辑器，但被定制能力卡住的 C++ 开发者。
2. 想用 AI 辅助开发大型 C++ 项目，但担心代码质量和 Bug 可控性的工程师。
3. 对节点编辑器内部实现感兴趣，想了解注册机制、序列化、执行器、撤销重做等核心模块怎么写的人。

2. 第三方节点库的“最后一公里”问题与自研边界

先明确一个判断：不是所有项目都需要自研节点编辑器。如果你的需求只是简单地展示节点、拖动连线、读取连接关系，第三方库完全够用。但如果你需要深度定制交互、数据流、序列化和运行时行为，那就要重新评估“第三方库省下的成本，是否足够覆盖后续改造成本”。

2.1 第三方库的典型问题

结合实际项目体验，第三方节点库通常会在这几个环节出问题：

第一，交互层定制受限。典型的第三方库会自带一套鼠标事件处理和绘制流程。你想实现“按住空格键平移画布 + 滚轮缩放 + 拖拽多选 + 键盘快捷键删除”，可能不是写几行配置就能完成的，而是要重写事件分发或拦截默认行为。项目的实际体感是：常规操作越简单，扩展反而越难，因为库已经替你做完了决定。

第二，序列化格式与业务模型冲突。节点库通常有自己的存档格式，它关心的是“哪个节点在哪个坐标、引脚之间怎么连”。但业务系统可能还需要保存节点参数、版本号、平台差异、权限信息、资源路径等。如果强制用自己的业务模型去映射库存档，每次升级都是一次兼容性灾难。

第三，执行引擎不一定适合你的业务。很多节点编辑器本身就是纯 UI 库，不负责节点执行。真正要驱动“节点图跑起来”的时候，要么自己写拓扑排序和执行器，要么去接一个并不契合的第三方图表执行框架。这时候，UI 库省下来的工作量，又有一部分被填了回来。

第四，依赖和编译成本。大型第三方库可能引入 Qt、Boost 或其他重型依赖，导致整个工程编译时间变长、包体变大、跨平台问题增多。如果项目本身并不需要这些依赖，那这笔编译成本是实打实的负债。

2.2 什么情况下才应该自研

这个项目走到第十弹，早已不是“试试看”的阶段。自研的核心收益其实是：所有关键模块的边界都由自己定义，后续迭代不受外部 API 演进影响。AI 在其中扮演的角色，是把这种“自定义能力”的编码成本压到可控范围。

从系列文章的演进来看，自研之后最大的好处是：出 Bug 时可以直捣根因，而不是去翻第三方库源码来确认它是由哪个内部 state 导致的行为异常。这对一个长期维护的项目来说，价值远高于初始阶段节省的那点工程量。

3. 节点编辑器核心概念与整体项目结构

在展开代码之前，先统一概念。节点编辑器的基本对象只有四类，很多复杂的问题到最后都能归约到这四个对象的关系上。

3.1 核心概念

Node（节点）：执行单元，也是图的基本对象。节点持有输入引脚、输出引脚、参数数据和计算函数。在设计时，节点最好尽量“无 UI 感知”，只关心数据进出和内部逻辑，这样后续扩展不同外观才不会污染核心代码。

Pin（引脚）：节点的输入输出端口，是连接的最小单位。引脚必须携带数据类型信息，否则连接校验只能隔离在“是否能连”层面，无法在编译期或运行时提前拦截“连错类型”。

Connection（连接）：源引脚到目标引脚的有向边。连接关系需要独立存储，不能只存在节点的临时数组里，否则序列化和撤销重做都会变得复杂。

Graph（图）：节点与连接的集合，是编辑器的操作对象。图需要维护自己的节点 ID 分配、连接完整性、拓扑排序缓存。

一个容易被忽略的设计点是：执行模型与编辑模型必须分离。编辑模型关注节点位置、引脚坐标、选择状态；执行模型关注数据流和调用顺序。如果混在一起，后续做多线程执行、回放执行、单步调试时几乎会寸步难行。

3.2 项目结构

以当前项目为例，代码按以下模块组织：

node_editor/ ├── include/ │ ├── core/ // 节点、引脚、连接、图模型 │ ├── editor/ // 画布交互、选择、快捷键、撤销重做 │ ├── serialization/ // 存档格式与版本迁移 │ └── execution/ // 执行器、拓扑排序、数据流 ├── src/ │ ├── core/ │ ├── editor/ │ ├── serialization/ │ └── execution/ ├── examples/ │ ├── math_graph/ // 数学计算图示例 │ └── script_graph/ // 命令流图示例 └── tests/ ├── unit/ └── regression/

这个结构的核心目标是：渲染相关代码不进入 core 和 execution，序列化代码只与模型层交互。这样做的好处是，换 UI 框架不会牵动执行引擎，改存档格式不会影响节点计算逻辑。

4. 本轮重大功能更新的设计思路

这一轮更新，有几个功能点和 Bug 修复的取舍值得展开说。它们不是拍脑袋加上去的，而是从实际使用中暴露出来的问题反向推导出来的。

4.1 渲染缓存与命中检测优化

早期版本的画布渲染是“全量重绘”模式：每次鼠标移动或节点更新，都要遍历所有节点重新计算坐标、重绘连接线。这种实现简单，但在节点数量超过 100 个之后，拖拽和连线的响应会明显变慢。

本轮更新引入了渲染缓存：每个节点保存自己的边界矩形、引脚屏幕坐标、连接线路径；只有在节点坐标变化、引脚数量变化或连接增删时，才标记对应缓存失效。鼠标点击时，优先通过创建的反转索引来缩小命中检测范围，先把候选集缩小到几个节点，再在这几个节点内精确遍历引脚。

这个改动的设计原则是：把“每次全量算”改成“按需局部算”。从代码量上看，增加了一个RenderCache结构体和少量失效逻辑；从交互体感上看，拖拽响应变得更平滑，缩放时也不再出现明显掉帧。

4.2 撤销重做机制落地

之前版本的删除节点没有撤销能力，误删一个配置复杂的节点组，只能手工接回去，体验极差。本轮引入 Command 模式来实现撤销重做。

设计时没有直接把“撤销”做成节点快照。快照方案在节点数少时很好用，但一旦节点数量上涨、图像复杂度增加，频繁序列化整张图的开销会非常大。最终采用的做法是：每条操作记录一个反向操作。比如：

• 新增节点 → 撤销 = 删除节点。
• 删除节点 → 撤销 = 恢复节点及其全部连接。
• 移动节点 → 撤销 = 恢复旧坐标。
• 新增连接 → 撤销 = 删除连接。

关键在于删除节点时，不仅要保存节点数据，还要保存它引出的所有连接和参数信息，否则撤销时无法完整恢复。这个“反向操作”设计在后续做快捷键、批量操作时也顺带解决了重复代码问题。

4.3 序列化格式升级与版本迁移

旧存档格式是简单的自定义文本，属性和节点块挤在一起，缺少版本号。一旦结构变了，旧存档几乎无法解析。这轮更新把存档格式彻底切到 JSON，并增加格式版本字段。

新格式设计为自解释结构：

• 顶层有version字段。
• 节点与连接分块保存。
• 每个节点保存node_type、node_id、position、params。
• 每个连接保存source_node、source_pin、target_node、target_pin。
• 加载时，先读版本号，根据不同版本选择对应的迁移函数。

所谓“迁移函数”，是指从旧版本结构映射到新版本的逻辑。例如旧版用x、y分开存坐标，新版用position字段存数组，迁移函数就负责把x/y转成position。这个机制看起来多写了一点代码，但从项目长期维护角度看非常值得。

4.4 快捷键系统与批量操作

画布交互必须具备键盘直达能力。本轮新增了ActionManager，把删除、复制、粘贴、撤销、重做、框选统一注册为 Action。

复制粘贴的体积比预期大，因为不只是复制节点参数，还要复制连接关系，同时要生成新的节点 ID，避免粘贴后 ID 冲突。实现上分成两步：先从选中节点构建一个“剪贴板图”，再在新位置执行图插入。整个过程通过 Command 包装，同样支持撤销。

5. 关键代码实现：节点注册、序列化与执行器

这部分给出本轮更新中比较有代表性的三段代码：节点注册宏、序列化保存/加载、简单执行器。它们不需要依赖任何特定 UI 框架，核心逻辑可以直接复用。

5.1 节点注册机制

自研节点编辑器里，节点类型数量会不断增加。如果每次新增节点都要手动改工厂函数，维护成本会非常高。这里采用宏注册 + 静态工厂的方式，让新增节点只需写一行注册代码。

// 文件路径：include/core/Registry.h #pragma once #include <functional> #include <memory> #include <string> #include <unordered_map> class Node; using NodeFactory = std::function<std::shared_ptr<Node>()>; class NodeRegistry { public: static NodeRegistry& instance() { static NodeRegistry registry; return registry; } bool add(const std::string& typeName, NodeFactory factory) { factories_[typeName] = std::move(factory); return true; } std::shared_ptr<Node> create(const std::string& typeName) const { auto it = factories_.find(typeName); if (it == factories_.end()) { return nullptr; } return it->second(); } std::vector<std::string> allTypeNames() const { std::vector<std::string> names; for (const auto& item : factories_) { names.push_back(item.first); } return names; } private: std::unordered_map<std::string, NodeFactory> factories_; }; // 注册宏：在全局作用域用一次，即可完成节点类型注册 #define REGISTER_NODE(CLASS_NAME) \ static bool _node_reg_##CLASS_NAME = \ NodeRegistry::instance().add(#CLASS_NAME, \ []() -> std::shared_ptr<Node> { \ return std::make_shared<CLASS_NAME>(); \ })

使用方法示例：

// 文件路径：examples/math_graph/Nodes.cpp #include "core/Registry.h" #include "core/Node.h" class AddNode : public Node { public: AddNode() { setName("Add"); addInput("a", ValueType::Float); addInput("b", ValueType::Float); addOutput("result", ValueType::Float); } Value compute(const std::vector<Value>& inputs) const override { return Value(inputs[0].asFloat() + inputs[1].asFloat()); } }; REGISTER_NODE(AddNode);

宏背后的原理是：利用静态变量的初始化时机，在程序启动阶段把工厂函数塞进全局NodeRegistry。这样在 UI 层创建节点时，只需要一个typeName字符串，不需要硬编码庞大的if-else链。

这个机制给后续扩展带来的好处非常明显：新增节点只需要新建类、写REGISTER_NODE，其余代码不需要动。存档加载时，即便遇到序列化文件里出现新类型节点，也能通过NodeRegistry::create动态实例化。

5.2 序列化保存与加载

序列化推荐使用nlohmann/json这类成熟 JSON 库，重点是版本字段和迁移函数的设计。

// 文件路径：src/serialization/GraphSerializer.cpp #pragma once #include "core/Graph.h" #include <nlohmann/json.hpp> #include <string> namespace GraphSerializer { constexpr int kCurrentFormatVersion = 3; nlohmann::json nodeToJson(const Node& node) { nlohmann::json json; json["node_type"] = node.typeName(); json["node_id"] = node.id(); json["position"] = {node.x(), node.y()}; if (!node.params().empty()) { json["params"] = node.params(); } return json; } nlohmann::json connectionToJson(const Connection& conn) { nlohmann::json json; json["source_node"] = conn.sourceNodeId; json["source_pin"] = conn.sourcePinName; json["target_node"] = conn.targetNodeId; json["target_pin"] = conn.targetPinName; return json; } nlohmann::json graphToJson(const Graph& graph) { nlohmann::json root; root["version"] = kCurrentFormatVersion; nlohmann::json nodesJson = nlohmann::json::array(); for (const auto& node : graph.nodes()) { nodesJson.push_back(nodeToJson(*node)); } root["nodes"] = nodesJson; nlohmann::json connsJson = nlohmann::json::array(); for (const auto& conn : graph.connections()) { connsJson.push_back(connectionToJson(conn)); } root["connections"] = connsJson; return root; } std::string saveGraphToString(const Graph& graph) { return graphToJson(graph).dump(2); } bool loadGraphFromString(Graph& graph, const std::string& content, std::string& error) { nlohmann::json root; try { root = nlohmann::json::parse(content); } catch (const std::exception& e) { error = std::string("JSON 解析失败: ") + e.what(); return false; } int version = root.value("version", -1); if (version < 1 || version > kCurrentFormatVersion) { error = "不支持的存档版本: " + std::to_string(version); return false; } // 这里做从旧版本到新版本的迁移。 // 实际项目中建议把 v1 到 v2、v2 到 v3 的迁移写成独立函数， // 通过数组循环串起来，而不是直接 if/else 堆在加载函数里。 if (version < kCurrentFormatVersion) { // migrateJsonToCurrent(root, version); } graph.clear(); for (const auto& item : root["nodes"]) { auto node = NodeRegistry::instance().create(item["node_type"].get<std::string>()); if (!node) { error = "未知节点类型: " + item["node_type"].get<std::string>(); return false; } node->setId(item["node_id"].get<std::string>()); node->setPosition(item["position"][0].get<float>(), item["position"][1].get<float>()); if (item.contains("params")) { node->setParams(item["params"]); } graph.addNode(std::move(node)); } for (const auto& item : root["connections"]) { const auto& srcNode = item["source_node"].get<std::string>(); const auto& srcPin = item["source_pin"].get<std::string>(); const auto& dstNode = item["target_node"].get<std::string>(); const auto& dstPin = item["target_pin"].get<std::string>(); graph.addConnection(srcNode, srcPin, dstNode, dstPin); } return true; } } // namespace GraphSerializer

这里真正需要强调的工程点是：加载失败时，旧图不能半毁。比较稳妥的做法是先把节点和连接数据全部解析到临时结构体里，全部合法后再 clear 原图并一次性写入。否则加载到一半发现未知类型，原图已经被清空，损失就是不可逆的。在“加载旧存档”这类操作上，任何不完整的写入都应该避免，必要的时候可以先备份当前图再加载，这个习惯在保存节点配置文件、脚本资源等场景下尤其重要。

5.3 拓扑排序与简单执行器

执行器的作用是遍历整个图，按照“先依赖后依赖者”的顺序执行节点计算。下面这段代码是一个简化的顺序执行器，不考虑多线程，只演示核心思路：

// 文件路径：src/execution/GraphExecutor.cpp #pragma once #include "core/Graph.h" #include <queue> #include <unordered_map> namespace GraphExecutor { struct ExecResult { bool success = true; std::string errorMessage; std::unordered_map<std::string, float> outputValues; }; ExecResult executeGraph(const Graph& graph) { // 1. 统计每个节点的入度 std::unordered_map<std::string, int> inDegree; std::unordered_map<std::string, std::vector<std::string>> adjList; for (const auto& node : graph.nodes()) { inDegree[node->id()] = 0; } for (const auto& conn : graph.connections()) { adjList[conn.sourceNodeId].push_back(conn.targetNodeId); inDegree[conn.targetNodeId]++; } // 2. 标准 Kahn 拓扑排序 std::queue<std::string> ready; for (const auto& item : inDegree) { if (item.second == 0) { ready.push(item.first); } } std::vector<std::string> execOrder; while (!ready.empty()) { std::string nodeId = ready.front(); ready.pop(); execOrder.push_back(nodeId); for (const auto& nextId : adjList[nodeId]) { if (--inDegree[nextId] == 0) { ready.push(nextId); } } } if (static_cast<size_t>(execOrder.size()) != graph.nodes().size()) { return ExecResult{false, "图中存在环，无法执行", {}}; } std::unordered_map<std::string, float> values; // 3. 按顺序执行节点 for (const auto& nodeId : execOrder) { auto node = graph.nodeById(nodeId); std::vector<Value> inputValues; for (const auto& pin : node->inputs()) { auto connOpt = graph.connectionInto(nodeId, pin.name()); if (connOpt.has_value()) { const auto& conn = connOpt.value(); inputValues.push_back(Value(values[conn.sourceNodeId])); } else { inputValues.push_back(pin.defaultValue()); } } Value result = node->compute(inputValues); values[nodeId] = result.asFloat(); } return ExecResult{true, "", values}; } } // namespace GraphExecutor

这段代码的核心逻辑并不复杂，但它是很多执行引擎的骨架。后续如果要支持多线程执行，只需要在拓扑排序结果上做“分波次”调度，让同时进入 ready 队列的节点并行执行；如果要支持断点调试，则需要为每个节点增加一个执行前回调。

从项目维护的角度看，执行器最好保持成独立的纯逻辑模块，不依赖 UI 层任何状态。这样单元测试可以直接构造图、执行、断言结果，不需要启动编辑器窗口。

6. 一个值得记录的 Bug：std::remove_if 没有真正删除元素

这一轮的 Bug 修复中，最值得复盘的是删除节点时遇到的一个问题，跟标准库函数的签名语义有直接关系，尤其是 C++ 初学者和 AI 辅助场景下特别容易踩中。

6.1 Bug 现象

当时的功能是“删除选中节点”。实现路径并不复杂：先收集选中的节点 ID，然后从std::vector<std::shared_ptr<Node>>里移除它们。功能在测试小图时表现正常，但一旦删除节点数量较多，再次执行图时会出现“幽灵节点”——节点列表里看起来没有了，但结果仍包含旧节点的输出。

排查日志时发现，graph.nodes()的size()在删除后确实变小了，但遍历一些迭代器时仍能访问到被删节点的数据。这就很像标准库remove_if的经典误解。

6.2 根因分析

这段代码是 AI 生成的：

// 错误示例：看起来没问题，实际上没有真正删除 auto& nodes = graph.nodes(); std::remove_if(nodes.begin(), nodes.end(), [&](const std::shared_ptr<Node>& node) { return selectedIds.count(node->id()) > 0; });

问题在于，std::remove_if只负责把“不需要删除”的元素往前搬，它不负责缩小容器大小。它返回的是新的逻辑尾迭代器，真正的“删除”需要调用erase配合remove的返回值，也就是经典的erase-remove idiom。

对这个项目的影响是：被“移除”的节点对象仍然留在容器尾部，graph.nodes()的size()没变。后续执行器遍历时，这些节点仍会参与计算，就出现了“节点列表里看起来没有、实际执行却还在”的幽灵效果。

这也是 C++ 标准库函数签名中比较隐蔽的一个设计：remove_if名为 remove，实际是“把元素移动到末尾并返回新尾部”，而不是直接析构。AI 生成这类代码时，如果训练样本里没有足够多的正确范式，很容易把remove_if当成一次性删除函数来用。

6.3 正确修复方案

修复方式就是标准的 erase-remove idiom：

// 文件路径：src/core/Graph.cpp #include <algorithm> void Graph::removeNodes(const std::unordered_set<std::string>& nodeIds) { auto& nodes = nodes_; // 1. 先删除与这些节点相关的连接 std::erase_if(connections_, [&](const Connection& conn) { return nodeIds.count(conn.sourceNodeId) > 0 || nodeIds.count(conn.targetNodeId) > 0; }); // 2. 删除节点本身 std::erase_if(nodes, [&](const std::shared_ptr<Node>& node) { return nodeIds.count(node->id()) > 0; }); // 3. 标记相关缓存失效 invalidateRenderCache(); }

注意这里用了 C++20 的std::erase_if，它内部就是remove_if + erase组合，语义直观，且返回实际删除的元素个数，适合容器删除场景。如果你的项目仍在 C++17 环境，可以改为：

nodes.erase( std::remove_if(nodes.begin(), nodes.end(), predicate), nodes.end());

6.4 这类 Bug 的共性启发

这个 Bug 看起来小，但它提醒了 AI 辅助开发中一个很关键的问题：AI 擅长生成“看起来正确”的代码，但对底层语义的把握不一定可靠。特别是在 C++ 这种“不同重载、不同签名导致行为完全不同”的语言里，过于依赖 AI 生成的结果而不做代码审查，会把一些隐蔽的语义错误带到生产环境。

处理这类 Bug 的顺序建议是：先看现象，再查数据流，最后才锚定某个 API 的语义。如果一开始就怀疑std::remove_if是不是有问题，可能需要提前了解“标准库算法不改变容器大小”这一条基本准则。多花点时间读标准库的签名和返回值说明，往往比排查半天业务逻辑更高效。

7. 功能更新验收与效果验证

功能更新不能只靠“我跑了一下没问题”来验收。这个项目目前采用了一套相对固定的验证流程：

7.1 手动功能验收清单

在编辑器里打开测试场景，按下面的清单逐项检查：

7.2 自动化回归测试

手工验收能覆盖主流程，但回归测试要靠自动化才能长期坚持。当前项目对执行器和序列化模块各维护了一组单元测试。

# 运行执行器与序列化单元测试 cmake --build build --target node_editor_tests -j4 ./build/node_editor_tests --report_level=detailed

测试用例设计上有一条经验：不仅要测试“正常连接”的图，还要测试空图、单节点图、带环图、未连接输入引脚的图、重复连接等边界情况。很多 Bug 不是出现在常规路径，而是出现在这些“看起来不该发生”的结构里。

7.3 性能的简单观察方式

渲染缓存更新后，可以用两个指标快速判断是否有效：

• 节点数量超过 100 后，拖拽是否仍然流畅。
• 连续缩放时，CPU 占用是否出现明显尖峰。

如果项目里已经接入编译器自带的性能分析工具，可以对render()和hitTest()分别采样，观察耗时是否与节点数呈线性关系，而不是每次都全量遍历。简单记录每一次鼠标操作的耗时日志，也能在开发阶段快速捕捉卡顿问题。

8. 常见问题与排查思路

自研节点编辑器迭代到现在，踩过的坑基本集中在这几类。整理成表格，方便对照排查：

排查顺序上，先确认最小复现路径，再看日志和数据结构，最后才改代码。如果只知道“加载不对”就直接改逻辑，很容易修好一个点、破坏另一条路径。

9. 总结、最佳实践与后续方向

做自研节点编辑器的价值，到第十弹这个阶段已经比较清晰：它真正换来的不是“不用第三方库”的炫耀，而是对交互、序列化、执行行为的完整控制权。维护这类项目，有几个实践经验值得沉淀。

9.1 命名与模块边界

节点编辑器涉及到的名词很多，Node、Pin、Connection、Graph、Port、Socket等等。项目里统一了命名规则：模型层叫Node/Pin/Connection/Graph；交互层叫Canvas/Selection/Action；序列化层只叫Serializer/Migration；执行层叫Executor/GraphExecutor。命名统一之后，AI 生成的代码和手写代码之间更容易对齐，代码审查也更加顺手。

9.2 序列化永远要先考虑版本兼容

序列化格式一旦被存档文件使用，就不能随意变更。每改一次结构，都要问三个问题：旧版本文件还能不能读？迁移逻辑有没有测试？新版本的写入是否会破坏旧版本工具读取？这三个问题回答不上来，就不要动格式。存档是用户资产，任何加载失败、数据丢失都很难用“升级了新版本”来解释。

9.3 AI 辅助编码的边界

这十弹过程中，AI 参与了不少功能迭代，但有一个经验越来越明确：AI 适合生成样板代码、算法骨架、独立函数和测试用例，不适合直接改与现有架构深度绑定的代码。让 AI 生成一个拓扑排序器，大概率是靠谱的；让 AI 直接修改某个类的私有成员和生命周期，风险就会明显上升。

如果让 AI 修 Bug，正确的姿势是：准备好最小复现样本、描述清楚当前输出和预期输出、要求它只修改一个函数。而不是把整个工程丢过去问“为什么这么慢”。前者能得到一个可验证的补丁，后者往往得到一个听起来合理的解决方案，实际却引入新的问题。

9.4 后续可以继续深入的方向

当前执行器还是单线程顺序执行。下一步可以考虑：

1. 可视化断点与单步执行：在节点上打断点，执行到该节点时暂停并显示输入输出值。
2. 数据流预览：把中间数值实时显示在引脚附近，方便调试复杂图。
3. 数学表达式节点自动生成：输入公式，自动生成对应节点组，减少重复造节点的工作量。
4. 局部刷新与增量执行：只重算受影响节点，而不是每次变更都整图执行。

这些方向都建立在已有基础上。自研编辑器最大的好处就在这里：每一个新功能都可以逐步叠加，不需要担心上游库能不能支持某个奇怪的交互需求。

如果你也正在把 AI 用到 C++ 项目里，最想提醒的还是那句：AI 生成的 Bug 往往藏得比手写代码更深，因为它看起来太合理了。把 Bug 当成学习材料，仔细读标准库的签名和返回值说明，整理一份团队的“AI 代码审查清单”，比单纯追求生成速度更有价值。