业务增长路由

它解决什么问题

业务增长相关的问题天然分散在多个职能里：客户健康度评分和流失预警归客户成功，RFP/RFI 应答和竞品定位归销售工程，管道覆盖和预测准确率（MAPE）归收入运营，而合同、SOW、DPA 又属于法务与商务交叉地带。当这些请求同时出现在一个对话里，通用助手往往只能靠临时提示词应付，输出质量不稳定，指标口径也不统一。

@user_3c6cb52e/business-growth-skills 的做法是不再让一个大而全的提示词硬扛所有场景，而是把四类能力拆成独立技能，由一个路由层负责分诊。

技能如何工作

这个路由层本身不提供任何工具，它的职责很纯粹：

• 识别请求信号，例如“客户健康度”“流失风险”“扩容机会”指向客户成功
• 匹配到唯一技能，从路由表中选出最合适的那一个
• 加载对应的 SKILL.md，进入该技能自己的工作流
• 多条规则同时命中时，先追问一个澄清问题，而不是猜一个方向

四个子技能分工明确：

• customer-success-manager：处理客户健康评分、流失风险和扩容打法
• sales-engineer：负责 RFP/RFI 覆盖、竞品定位和 PoC 计划
• revenue-operations：关注管道覆盖、预测准确率（MAPE）和 GTM 效率
• contract-and-proposal-writer：产出提案、合同、SOW、DPA 等文档草稿

在指标计算上，技能要求调用子技能自带的 Python 打分器，而不是凭感觉手工估算。这一点对预测准确率这类容易被“拍脑袋”的指标尤其重要——用同一套代码计算，口径才一致。

适用边界与注意点

• 路由层只负责分诊，不具备业务能力本身；它的价值取决于四个子技能的工作流质量
• 输出的合同、SOW、DPA 全部是供人复核的草稿，不能直接当作法律意见使用
• 指标结果来自代码计算，仍需业务方确认其是否符合实际业务定义
• 当请求同时命中多行路由规则时，技能会先反问一句，这意味着交互轮次可能比预期多一次

适合把这套技能用在已有明确业务分工、需要把客户成功到营收履约的链路拆开处理的团队。如果所有增长事项都压在一个角色身上，拆分反而增加理解成本。