同样是把一份量表的原始分换算成标准分，一种做法是把换算规则写进配置、由引擎读取执行，另一种是把公式和常模表直接写进代码。两者算出来的分数没差别，可一旦常模需要更新、增加一个年龄段的对照，或者换一套分界值，两种做法的成本就完全不在一个量级。
写死的代价：改一次动一次发版
把常模表和分段逻辑写进代码，意味着每次常模调整都要改源码、走测试、重新发版。一个平台上量表几十上百张，若每张的计分都散落在各自的函数里，改一张的分界值就要开发介入一次，还得担心动到别的量表。心理量表的常模并非一成不变：换了适用人群、补了新的年龄段样本、或者引用了修订后的分界标准，都会带来一次改动，而这类改动本该由懂量表的人来定，却因为写死而每次都得绕开发排期。更麻烦的是历史数据：代码一改，之前用旧公式算出的报告在重算时就会跟着变，想复现当初那份报告反而做不到。
配置化：把常模变成数据
配置化的思路是把“怎么算”从代码里抽出来，变成一份结构化数据：哪些题目属于哪个因子、原始分怎么汇总、按什么人群和年龄段查常模表、落在哪个区间给什么解释。引擎只负责按配置执行，不关心具体是哪张量表。这样新增或调整一张量表的常模，是改配置、审核、生效，不需要改引擎代码，更不用全量发版。
橙星云的计分就走配置化这条路，量表的因子结构、常模表和解释区间都以数据形式维护，新增量表或更新常模不必改动计分引擎本身。
版本与追溯：老报告不能被新常模改写
配置化真正省成本的地方，是它天然适合做版本。每套常模配置带上版本号，报告生成时记录用的是哪一版。之后常模更新，只对新答卷生效，历史报告仍能用当时那一版复现出完全一样的结果。写死的方案想做到这点，几乎要在代码里维护多套并行公式，维护成本很快失控。
什么时候配置化并不划算
配置化也不是没有代价。它要求先把量表的计分模型抽象清楚，把因子归属、汇总方式、常模查询和区间解释都拆成引擎能读懂的结构，前期设计和引擎实现更重；遇到计分方式特别古怪的量表，还得考虑配置表达不了时怎么开个口子。对那种只有一两张、计分极其特殊、几乎不会变的量表，直接写死反而更省事。判断点很清楚：量表种类多、常模会周期性更新、又要求历史可复现，就该配置化；数量少且稳定，写死也能接受。归根到底，改常模的成本差，就是“改一份数据、审核后生效”和“改一段代码、测试后发版”这两条路径的差别，量表越多、更新越频繁，这条差距就被放得越大。