需求听起来很简单：让算法编排支持"一个节点接多个输入源"。
实际改动要穿过六个地方：数据模型、接口 DTO、业务服务、数据库迁移、消息队列下发、前端表单。任何一层漏掉，表现都是"配置保存了但执行时不生效"。
先定字段，再写代码
第一件事不是改代码，是把承载语义的那一个字段定下来——pipeline_input_node_id——然后要求它在每一层都以同名同义出现，包括序列化边界。命名不一致是这类改造最常见的失败源：前端 camelCase、后端 snake_case，中间还要过一层消息队列。
老数据怎么办
新字段对已有配置是空的。直接拒绝会让存量配置全部失效，所以定义了 6 条兼容与校验规则，覆盖"空值回退到旧结构""多输入但只填了一个""引用了不存在的节点"这些情况。改造的难点从来不在新逻辑，在旧数据。
上线那天的另一个问题
生产环境的实际情况是：没有 git 凭据、工作区有未提交改动、还有几套历史遗留的启动脚本互相干扰。这时候"git pull && 重启"这条路是走不通的。
做法是列一份最小文件清单——这次改动实际涉及哪几个文件——用 rsync 按内容校验同步（--checksum、不改权限），再重启对应进程。好处是范围完全可控：即使同步中断，也只会影响清单内的文件，不会把整个工作区搅乱。
在生产上，可回滚的窄改动，比"正确但面积大"的改动更值得选。