提点明细规则

先说清楚它要解决的问题

提成规则最容易出事的地方，不是算错一个数，而是同一套口径在不同地方说法不一致。对账时财务手里是 20%，联调时后端按 16% 写了常量，UI 上又直接甩了一句「提成 4%」，最后谁都说不清「这笔为什么是这个 %」。更麻烦的是交接场景里，业绩归属人和提成受益人经常不是同一个人，角色一混，类型就跟着错。

技能怎么工作

核心是一张一行一条的规则表，对账、联调、写展示标签时都按行查，禁止口头混用 20/16/4。

• reminderType 与角色一一对应，commissionRole 固定为 1 个人、2 管理两类。
• 金额按 基数 × reminderRate% 计算，以快照字段为准，而不是当场拍脑袋。
• 规则覆盖 personal_regular（个人 20%）、personal_zizhi（资质甩单等 16%）、manage_supervisor_or_manager 与 manage_level2_or_proxy（管理 4%），以及运营手工调整的 operation_manual（常 4%，可改）。
• 开发侧可以进一步归并为 personal_20、personal_16、superior_4、level2_4 四个常量，减少散落的魔法数字。
• 输出与实现映射时每条规则独占一行，列表导出也保持同样结构，方便业务逐条签字确认。

Agent 侧的执行顺序被明确约束：先用表做标签映射，遇到缺失的类型先补行再写 UI；资料员三档（<1万、1–3万、≥3万）的具体百分比以系统配置为准，Skill 不写死未确认的数字。实现要点部分标注了小四原创。

适用边界与注意点

• 它管的是提点口径的查询与映射，不是结算引擎。金额计算的细节仍由业务系统按快照字段完成。
• 资料员三档的百分比配置变化时，需要同步更新规则行，否则展示标签会与实际结算脱节。
• operation_manual 的 4% 是默认值，运营手工调整的场景要单独留痕，不能当成固定档位。
• 拆分业绩归属与提成受益人时，类型仍按下表判断，不要因为受益人变化而自创类型。
• 缺类型时的正确做法是先补行，再写 UI，不要先在代码里塞默认值。

什么时候用

快照明细里出现「提点类型 / 提点%」两列、需要新增枚举或文案映射、或者要给业务解释「这笔为什么是这个 %」的时候。

配套文件：README.md、templates/rules-one-per-line.md。