让非技术人员修改规则，我给能力加了边界

在模拟规则变更时，我发现每次调整分账比例或费用口径都需要修改代码、重新部署。这意味着：问题不在使用者，而在产品边界的设计。

规则会变是常态，尤其是跟钱有关的规则 —— 促销、返点、补贴，本来就是会调整的。把规则写死在代码里，等于每次变化都变成一次开发。

第一件事：把规则从代码里搬出来

凡是「业务上可能会变」的判断，一律不写进代码。比如：

• 分成比例、阶梯档位
• 哪些费用参与分摊、按什么口径分摊
• 结算周期、账期起算日

这些东西全部抽到配置里，代码只负责「读配置、执行」。加一个新规则类型，不用动业务逻辑。

第二件事：让规则以表格的样子出现在客户面前

最初的配置形式是一组 JSON。虽然开发者容易理解，但它不适合交给非技术人员维护。

问题不在于他们看不懂，在于JSON 让改规则这件事显得很危险。少一个逗号，整段失效。没人愿意承担这个心理压力。

改成表格之后情况就变了：一行一条规则，几列分别是适用对象、条件、比例、生效日期。财务改完自己就能核对，因为他们本来就在用 Excel 干这个。

关键不是"简单"，是"看起来安全"。同样的逻辑，JSON 让人不敢碰，表格让人愿意试。

第三件事：每次改动都留下痕迹

规则能自己改了，新的风险是：改错了、或者改了之后有人不认。

所以每一条规则变更都记录四件事 —— 谁改的、什么时候、改前什么、改后什么。界面上能看到完整的变更历史。

这条设计同时解决两个问题：出错后可以追溯，也能让参与方核对规则是否发生变化。

顺带说一个反直觉的取舍

我最后的方案里，客户能改的规则是**有边界的**：只能改数值和生效时间，不能改规则的逻辑结构。加一种全新的规则类型，还是要我来做。

听起来像是没做彻底，但这是刻意的。全部放开会让整个系统变得难以维护 —— 客户可能会组合出我完全没测试过的情况，出了问题很难定位。

让使用者改“参数”，不让使用者直接改“结构”。这是当前原型采用的边界，后续还需要用真实业务继续验证。

一条经验

做客户系统的时候，问自己一个问题：这个功能上线后，客户多久会需要找我改一次？

如果答案是「每个月」，那就说明设计有问题。不是客户太麻烦，是边界划错了 —— 该交给他们的东西，还捏在我手里。