用架构约束代替文档约束：把业务流程集中到引擎侧防止"偷偷改流程"

在[[插件化解决文档失真与团队碎片化的双重矛盾]]描述的引擎/插件架构中，一个关键的设计决策是：不允许接入产品在插件里自定义业务流程本身，只能从引擎提供的若干标准流程中选择，流程的具体实现用工作流引擎承载并且完全跑在引擎一侧（连交互界面的渲染都发生在引擎的Server上）。这个决策背后的洞察是，”统一流程”这件事光靠制度和规范文档去要求是靠不住的——业务方永远有足够的动机和空间在执行细节上悄悄跑偏，规范文档管不住代码实际怎么写；只有当流程图和交互本身在物理上就不属于业务方能触及的代码范围（而是运行在引擎的进程和Server里），业务方才真正”想改也改不了”，统一才从口号变成了架构层面的既成事实。这条经验可以泛化成一条更通用的判断原则：当团队发现某个”约定”反复被违反、单靠流程和文档管不住时，与其继续加强培训、加强Review，不如反过来审视能不能把这个约定从”人要遵守的规则”变成”代码结构本身不允许被违反”——后者的执行力远高于前者，因为它不依赖任何人的自觉性。