研究与实现之间的接口边界

为什么要划线

研究侧关注假设与验证速度，工程侧关注稳定性、可观测性与可维护性。两套目标没有高下之分，但如果不明确接口，责任会落到「中间地带」：既没有人负责数据口径，也没有人负责运行时的失败处理。

本文只讨论职责与接口的结构，不讨论任何具体研究方法、参数选择或决策逻辑，也不提供任何形式的信号或建议。

一条清晰的接口

我们建议把边界定义为三类对象，而不是让两侧共享同一份可变状态：

对象	归属	约束
数据契约	工程侧	版本化、只读、变更需评审
运行配置	研究侧	显式声明、可被校验
结果记录	双方	结构化、含输入标识

研究侧输出的是带完整输入标识的结果记录，工程侧消费的是这份记录，而不是研究过程本身。这样两侧可以独立演进。

boundary {
  upstream:  研究侧 → run_config + input_manifest
  downstream: 工程侧 → result_record + diagnostics
  shared:    versioned_contract
  forbidden: 共享可变全局状态
}

变更如何传递

接口变更需要版本号，而不是通知。契约升级时保留旧版本一段时间，让在途运行可以完成；结果记录中带上契约版本，便于事后区分「结论变化」与「口径变化」。

小结

边界清晰的价值在于可审计：任何一次运行，都能回答输入是什么、口径是哪一版、谁负责哪一段。本文为工程方法论讨论，不含标的意见与业绩表述。

示例内容 · 需核实。