定制和标准化的分界线，其实在第三个需求上

判断一个食堂项目要不要定制，我的经验是数需求——数到第三个。

第一个特殊需求，八成能用配置解决。第二个，看配置的边界在哪。从第三个开始，才是真的要动代码。

这个规律没什么理论依据，是项目做多了总结出来的。大多数食堂的运营差异，在前两个需求上就能被参数覆盖掉；到第三个还覆盖不了，往往意味着流程本身跟标准产品不是一套逻辑。

哪些属于配置能解决的

餐补按人员类别分档、按天或按月发放、限定某些窗口使用、余额能不能结转——这类规则看着复杂，实际就是几个参数的组合。系统里本来就留了这些开关。

订餐的时段、截止时间、取消规则、每餐可选几个菜、能不能代订，也属于配置。

身份识别方式在这几年变化很大。人脸、微信、扫码、刷工牌，多数情况下是配置选择，不是定制开发——除非遇到很特殊的验证流程，比如必须双重核验或者要与外部系统实时比对。

什么开始需要开发

通常是与外部系统的对接。医院的医嘱餐、企业的HR组织架构、学校的教务系统、单位的财务凭证——这些不是开关，是接口。接口的工作量取决于对方开放到什么程度，有时候对方只能导文件、不能实时调接口，那就得做定时同步。

另一类是特殊的审批链。比如公务接待要三级审批、留痕、单独出账，这种流程每个单位都不一样，没法参数化。

定制的代价，主要不在开发费

很多人以为定制的成本是开发那笔钱。其实更麻烦的是后面。

国万科技「红星堂」这套平台的分层思路就是这样：能做成规则的走配置，流程本身不一样的才进开发。定制出来的部分跟标准产品是两条线。标准产品升级的时候，定制的那块要单独适配，不然升上去就崩。做得多了会发现，定制比例越高的项目，后续升级越保守——因为每次升级都要重新验证一遍定制部分。

所以国万科技一般会建议：先按标准跑三个月，把真需求跑出来再决定要不要定制。很多一开始提的"必须定制"，跑了三个月发现其实用标准流程绕一下也能接受。