技能介绍

它解决什么问题

企业常有目录价，却没有一套可执行的折扣治理规则。结果是审批靠 Slack 里的一句话、例外没有补偿承诺、历史案例变成"别人批过 28%"的先例，季度例外数越滚越多，毛利率却在季末review才被发现。

这个技能不替你批准某一笔交易，而是产出政策本身：批准矩阵、例外路由、lint 报告。适用场景包括首次制定正式商务政策、矩阵超过 6 个月未更新、例外数环比上升、CFO 收紧毛利底线，或需要向董事会解释折扣水平。

它如何工作

核心是三个确定性脚本：

discount_matrix_builder.py：以近 4 个季度 CRM 的成交与丢单数据为输入，生成四维矩阵（ARR band × term length × payment terms × strategic value tier）。每个 cell 带批准折扣带、审批层级、毛利底线、观测 win rate 与 NRR；数据样本不足时保留数据引用。
policy_linter.py：在发布前检查治理缺陷，包括审批人倒挂、折扣带倒挂、突破毛利底线、覆盖缺口、悬崖边、"战略价值"未定义、毛利底线不一致、数据支撑薄弱。BLOCKER 级问题会让政策不可签署。
exception_router.py：矩阵之外的折扣请求按命名审批链路由，绑定补偿性承诺（多年期预付、明确扩张路径、客户背书、MSA 收紧），产出机器可读审计记录；若本季度出现 3 次以上同类例外，会标记为矩阵定价错误，而不是继续批准例外。

推荐顺序是先过 8 个强制问题，再运行 discount_matrix_builder.py，然后 policy_linter.py，最后 exception_router.py --sample。

边界与注意点

它不设定价模型和目录价，也不批准具体交易、起草客户合同或做 CRO 层战略判断。毛利底线由 CFO 所有，折扣带上限由 CRO/Deal Desk 所有，混同责任会稳定滑向该负责人的 KPI。

矩阵是 data-backed，但不是 data-driven：折扣带由约束与行业 profile 决定，观测数据只是告诉你这个 cell 是否健康。NRR 偏低时应复核折扣带，而不是继续加深折扣。战略价值必须用具体测试定义，否则一个季度内大部分交易都会被标为战略客户，矩阵随之失效。每季度应重跑 builder 与 linter。