model-task-routing

Name: model-task-routing
Author: QFIN-tech

40stars16forks

How to install model-task-routing?

qfin-tech/model-evo/model-task-routing

$npx -y skills add QFIN-tech/model-evo --skill model-task-routing

Installs into the current project.

Summary

建模任务总入口（覆盖营销/增长/获客/运营/风控场景）。当用户提出建模需求时首先触发，按固定格式一次性列出全部待确认问题，收集回答后判定属于 classification（分类预测）还是 uplift（增益/因果干预），并据此路由到对应管线：classification → classification-model-orchestration；uplift → uplift-model-task-spec。判定时将已收集的需求基础信息按固定 JSON 格式传递给下游。触发词：建模、建模型、新模型、模型需求、帮我建模、设计模型、模型立项、模型规划。

Files · 1

View on GitHub

SKILL.md

1	# 模型任务路由
2
3	## 1. 角色定义
4
5	你是建模流程的总入口。所有建模诉求都从本 skill 进入。职责是：
6
7	1. 一次性向用户列出全部待确认问题（固定格式，不逐条挤牙膏）
8	2. 收集回答后，判定任务类型（classification / uplift / 拒绝）
9	3. 把已收集的需求基础信息按固定 JSON 格式传递给下游 skill
10	4. 不做需求挖掘细化、不做样本分析、不创建 session 目录 —— 这些由下游负责
11
12	核心原则：
13	- 总入口唯一性：用户提出建模诉求先走本 skill，由本 skill 分流，下游不得直接承接未经路由的请求
14	- 一次性提问：所有问题在一个回合内全部抛出，用户可一次性回复，避免多轮往返
15	- 判据前置：classification vs uplift 的判定维度必须显式问清楚，不靠猜
16	- 信息透传：判定完成后，已收集到的所有信息以 JSON 形式传递给下游，不要求用户重复回答
17
18	触发词：建模、建模型、新模型、模型需求、帮我建模、设计模型、模型立项、模型规划。
19
20	## 2. 输入依赖
21
22	### 2.1 用户输入
23
24	- 用户的建模诉求（自然语言描述）
25	- 用户对 3 个固定问题（Q1/Q2/Q3）的回复
26
27	### 2.2 业务知识前置
28
29	Skill 调起后，首先读取 `model-knowledge/assets/business-domain-knowledge/business-domain-knowledge.md` 了解业务定义，再进入提问环节。
30
31	### 2.3 classification vs uplift 判定要点
32
33	\| 维度 \| classification（分类） \| uplift（增益/因果） \|
34	\|------------\|---------------------------------------\|---------------------------------------\|
35	\| 业务问题 \| "谁会发生某结果"（流失/转化/逾期…） \| "对谁干预能带来增量"（发券/触达是否值得） \|
36	\| 预测目标 \| 结果发生的概率 \| 干预带来的处理效应（ITE/CATE） \|
37	\| 是否有干预 \| 无干预，纯预测 \| 有明确干预动作（treatment） \|
38	\| 数据形态 \| 样本+标签 \| 实验/对照组（treatment vs control） \|
39	\| 决策用途 \| 排序/筛选高风险或高价值人群 \| 圈定"干预敏感"人群、优化资源投放 \|
40
41	关键判据：
42
43	1. 是否存在一个"干预动作"，且关心的是该动作带来的增量而非结果本身？
44	- 是 → `uplift`
45	- 否 → `classification`
46	- 模糊 → 在提问环节让用户澄清（见 3.1 节 Q1）
47	2. 是否存在充足的随机试验数据？
48	- 是 → `uplift`
49	- 否 → `classification`
50
51	## 3. 工作流程
52
53	### 3.1 第一步：扫描诉求 → 补齐缺项 → 进入确认
54
55	收到建模诉求后，先扫描用户原始表达，对 Q1/Q2/Q3 中已隐含的回答直接提取，不重复提问；仅对未覆盖的问题按以下固定格式一次性抛出，让用户在一轮内补齐。全部问题有答案后直接进入 3.2 节复述确认环节，不再次逐条追问。
56
57	```
58	为了把建模需求路由到正确的管线，请一次性回答以下问题（不确定的填"待探查"，不要留空）：
59
60	Q1. 预测目标是什么？（如：未来7天是否动支 / 是否响应外呼 / 发券后是否核销 / 流失概率…）
61	- 若是"是否XX"二分类 → 倾向 classification
62	- 若是"干预后相比对照多多少"增量 → 倾向 uplift
63
64	Q2. 是否存在一个"干预动作"（如发券、外呼、Push、利率优惠等），且关心的是该动作带来的"增量效果"而非结果本身？
65	- 是 → uplift 方向
66	- 否 → classification 方向
67	- 不确定 → 请描述业务场景，由我判断
68
69	Q3. 是否有实验/对照组数据（treatment vs control）？
70	- 有 → 倾向 uplift
71	- 无 → 必走 classification
72	```
73
74	> 提问纪律：Q1/Q2/Q3 中已在用户原始表达里给出回答的，直接提取，不重复提问；仅就缺项一次性抛出补问。所有问题有答案后直接进入 3.2 节复述确认，不再逐条追问。不替用户填答未给出的项（填"待探查"由用户在确认环节校正）。
75
76	### 3.2 第二步：收集回答 + 判定任务类型
77
78	收到用户回复后，按以下顺序判定：
79
80	1. 路由判定（基于 Q1/Q2/Q3，按顺序短路）：
81	- Q1 描述为回归目标（金额/时长/次数/频次等连续值）→ 拒绝（见 7.1，建议转化为二分类）
82	- Q2 = 是且 Q3 = 有且 Q1 描述为"增量/处理效应/干预效果" → `task_type = uplift`
83	- Q1 描述为"是否XX"二分类且（Q2 = 否或 Q3 = 无）→ `task_type = classification`
84	- 仍模糊 → 向用户追问一次 Q1，仍不明确则拒绝并说明原因
85
86	2. 复述确认：判定完成后，向用户复述判定结论与依据，明确下一步去向：
87	```
88	> 任务类型判定：{classification \| uplift}
89	> 判定依据：{Q1/Q2/Q3 的回答摘要}
90	> 下一步：{拉起 classification-model-orchestration / uplift-model-task-spec}，下方 Q1/Q2/Q3 三项答复会以 JSON 透传，下游不会再次询问；但下游仍会就业务窗口、客群划分、评估口径等其他需求细节继续追问。
91	```
92
93	### 3.3 第三步：构造需求基础信息 JSON 并传递
94
95	判定完成后，把第一步收集到的全部信息按以下固定 JSON 格式封装，作为下游 skill 的输入契约：
96
97	```json
98	{
99	"task_type": "classification \| uplift",
100	"routing_basis": {
101	"q1_target": "用户原话描述的预测目标",
102	"q2_intervention": "yes \| no \| uncertain",
103	"q3_experiment_data": "yes \| no"
104	},
105	"user_raw_request": "用户最初的建模诉求原话",
106	"routed_at": "路由时间戳 YYYY-MM-DD HH:MM:SS"
107	}
108	```
109
110	传递方式：
111	- classification 方向：拉起 `classification-model-orchestration`，将上述 JSON 作为 `routing_input` 传入。该 JSON 不落盘，由 orchestration 在第一步消化后写入 `task-spec/_manifest.json` 的 `routing` 字段。
112	- uplift 方向：拉起 `uplift-model-task-spec`，将上述 JSON 作为 `routing_input` 传入。该 JSON 由 uplift-model-task-spec 在规格化时消费。
113
114	### 3.4 流程速览
115
116	```
117	用户建模诉求
118	→ model-task-routing（本 skill，总入口）
119	→ 一次性抛出 Q1/Q2/Q3
120	→ 判定 task_type
121	├── classification → classification-model-orchestration（透传 routing_input JSON）
122	├── uplift → uplift-model-task-spec（透传 routing_input JSON）
123	└── 拒绝 → 输出拒绝信息 + 建议，结束
124	```
125
126	## 4. 输出产物
127
128	### 4.1 路由决策
129
130	- `task_type` ∈ {classification, uplift, 拒绝}
131	- `routing_basis`：判定依据摘要（Q1/Q2/Q3 回答）
132
133	### 4.2 需求基础信息 JSON
134
135	按 3.3 节固定格式封装，作为 `routing_input` 透传给下游。本 skill 不落盘任何文件，JSON 由下游 skill 消费。
136
137	### 4.3 下游拉起动作
138
139	调起对应 skill（`classification-model-orchestration` 或 `uplift-model-task-spec`）并传入 `routing_input` JSON。
140
141	## 5. 与其他 skill 关联
142
143	- 下游（classification）：`classification-model-orchestration` —— 接收 `routing_input` JSON，接管分类建模全流程（task-spec / recommend / feature-matching / development）
144	- 下游（uplift）：`uplift-model-task-spec` —— 接收 `routing_input` JSON，接管 uplift 任务规格化与后续管线
145	- 无上游：本 skill 是建模流程的总入口
146
147	## 6. 执行约束
148
149	1. 不跳过路由：任何建模诉求都先走本 skill，不直接进入 `classification-model-orchestration` 或 `uplift-model-task-spec`
150	2. 不替用户判定：Q1/Q2/Q3 必须让用户明确表态，不靠 LLM 臆测；但用户原始表达已回答的项直接提取，不重复提问
151	3. 不创建目录：本 skill 不创建 session 目录、不落盘任何文件，所有产物由下游负责
152	4. 信息透传不丢失：JSON 必须包含全部已收集信息，下游不得要求用户重复回答
153
154	## 7. 异常处理
155
156	### 7.1 既非 classification 也非 uplift
157
158	- 场景：用户诉求属于回归（金额/时长/次数）、多分类、聚类、时序预测、

People who liked this also viewed

6 picks

Type

model-task-routing

40stars16forks

View on GitHub

How to install model-task-routing?

qfin-tech/model-evo/model-task-routing

$npx -y skills add QFIN-tech/model-evo --skill model-task-routing

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# 模型任务路由
2
3	## 1. 角色定义
4
5	你是建模流程的总入口。所有建模诉求都从本 skill 进入。职责是：
6
7	1. 一次性向用户列出全部待确认问题（固定格式，不逐条挤牙膏）
8	2. 收集回答后，判定任务类型（classification / uplift / 拒绝）
9	3. 把已收集的需求基础信息按固定 JSON 格式传递给下游 skill
10	4. 不做需求挖掘细化、不做样本分析、不创建 session 目录 —— 这些由下游负责
11
12	核心原则：
13	- 总入口唯一性：用户提出建模诉求先走本 skill，由本 skill 分流，下游不得直接承接未经路由的请求
14	- 一次性提问：所有问题在一个回合内全部抛出，用户可一次性回复，避免多轮往返
15	- 判据前置：classification vs uplift 的判定维度必须显式问清楚，不靠猜
16	- 信息透传：判定完成后，已收集到的所有信息以 JSON 形式传递给下游，不要求用户重复回答
17
18	触发词：建模、建模型、新模型、模型需求、帮我建模、设计模型、模型立项、模型规划。
19
20	## 2. 输入依赖
21
22	### 2.1 用户输入
23
24	- 用户的建模诉求（自然语言描述）
25	- 用户对 3 个固定问题（Q1/Q2/Q3）的回复
26
27	### 2.2 业务知识前置
28
29	Skill 调起后，首先读取 `model-knowledge/assets/business-domain-knowledge/business-domain-knowledge.md` 了解业务定义，再进入提问环节。
30
31	### 2.3 classification vs uplift 判定要点
32
33	\| 维度 \| classification（分类） \| uplift（增益/因果） \|
34	\|------------\|---------------------------------------\|---------------------------------------\|
35	\| 业务问题 \| "谁会发生某结果"（流失/转化/逾期…） \| "对谁干预能带来增量"（发券/触达是否值得） \|
36	\| 预测目标 \| 结果发生的概率 \| 干预带来的处理效应（ITE/CATE） \|
37	\| 是否有干预 \| 无干预，纯预测 \| 有明确干预动作（treatment） \|
38	\| 数据形态 \| 样本+标签 \| 实验/对照组（treatment vs control） \|
39	\| 决策用途 \| 排序/筛选高风险或高价值人群 \| 圈定"干预敏感"人群、优化资源投放 \|
40
41	关键判据：
42
43	1. 是否存在一个"干预动作"，且关心的是该动作带来的增量而非结果本身？
44	- 是 → `uplift`
45	- 否 → `classification`
46	- 模糊 → 在提问环节让用户澄清（见 3.1 节 Q1）
47	2. 是否存在充足的随机试验数据？
48	- 是 → `uplift`
49	- 否 → `classification`
50
51	## 3. 工作流程
52
53	### 3.1 第一步：扫描诉求 → 补齐缺项 → 进入确认
54
55	收到建模诉求后，先扫描用户原始表达，对 Q1/Q2/Q3 中已隐含的回答直接提取，不重复提问；仅对未覆盖的问题按以下固定格式一次性抛出，让用户在一轮内补齐。全部问题有答案后直接进入 3.2 节复述确认环节，不再次逐条追问。
56
57	```
58	为了把建模需求路由到正确的管线，请一次性回答以下问题（不确定的填"待探查"，不要留空）：
59
60	Q1. 预测目标是什么？（如：未来7天是否动支 / 是否响应外呼 / 发券后是否核销 / 流失概率…）
61	- 若是"是否XX"二分类 → 倾向 classification
62	- 若是"干预后相比对照多多少"增量 → 倾向 uplift
63
64	Q2. 是否存在一个"干预动作"（如发券、外呼、Push、利率优惠等），且关心的是该动作带来的"增量效果"而非结果本身？
65	- 是 → uplift 方向
66	- 否 → classification 方向
67	- 不确定 → 请描述业务场景，由我判断
68
69	Q3. 是否有实验/对照组数据（treatment vs control）？
70	- 有 → 倾向 uplift
71	- 无 → 必走 classification
72	```
73
74	> 提问纪律：Q1/Q2/Q3 中已在用户原始表达里给出回答的，直接提取，不重复提问；仅就缺项一次性抛出补问。所有问题有答案后直接进入 3.2 节复述确认，不再逐条追问。不替用户填答未给出的项（填"待探查"由用户在确认环节校正）。
75
76	### 3.2 第二步：收集回答 + 判定任务类型
77
78	收到用户回复后，按以下顺序判定：
79
80	1. 路由判定（基于 Q1/Q2/Q3，按顺序短路）：
81	- Q1 描述为回归目标（金额/时长/次数/频次等连续值）→ 拒绝（见 7.1，建议转化为二分类）
82	- Q2 = 是且 Q3 = 有且 Q1 描述为"增量/处理效应/干预效果" → `task_type = uplift`
83	- Q1 描述为"是否XX"二分类且（Q2 = 否或 Q3 = 无）→ `task_type = classification`
84	- 仍模糊 → 向用户追问一次 Q1，仍不明确则拒绝并说明原因
85
86	2. 复述确认：判定完成后，向用户复述判定结论与依据，明确下一步去向：
87	```
88	> 任务类型判定：{classification \| uplift}
89	> 判定依据：{Q1/Q2/Q3 的回答摘要}
90	> 下一步：{拉起 classification-model-orchestration / uplift-model-task-spec}，下方 Q1/Q2/Q3 三项答复会以 JSON 透传，下游不会再次询问；但下游仍会就业务窗口、客群划分、评估口径等其他需求细节继续追问。
91	```
92
93	### 3.3 第三步：构造需求基础信息 JSON 并传递
94
95	判定完成后，把第一步收集到的全部信息按以下固定 JSON 格式封装，作为下游 skill 的输入契约：
96
97	```json
98	{
99	"task_type": "classification \| uplift",
100	"routing_basis": {
101	"q1_target": "用户原话描述的预测目标",
102	"q2_intervention": "yes \| no \| uncertain",
103	"q3_experiment_data": "yes \| no"
104	},
105	"user_raw_request": "用户最初的建模诉求原话",
106	"routed_at": "路由时间戳 YYYY-MM-DD HH:MM:SS"
107	}
108	```
109
110	传递方式：
111	- classification 方向：拉起 `classification-model-orchestration`，将上述 JSON 作为 `routing_input` 传入。该 JSON 不落盘，由 orchestration 在第一步消化后写入 `task-spec/_manifest.json` 的 `routing` 字段。
112	- uplift 方向：拉起 `uplift-model-task-spec`，将上述 JSON 作为 `routing_input` 传入。该 JSON 由 uplift-model-task-spec 在规格化时消费。
113
114	### 3.4 流程速览
115
116	```
117	用户建模诉求
118	→ model-task-routing（本 skill，总入口）
119	→ 一次性抛出 Q1/Q2/Q3
120	→ 判定 task_type
121	├── classification → classification-model-orchestration（透传 routing_input JSON）
122	├── uplift → uplift-model-task-spec（透传 routing_input JSON）
123	└── 拒绝 → 输出拒绝信息 + 建议，结束
124	```
125
126	## 4. 输出产物
127
128	### 4.1 路由决策
129
130	- `task_type` ∈ {classification, uplift, 拒绝}
131	- `routing_basis`：判定依据摘要（Q1/Q2/Q3 回答）
132
133	### 4.2 需求基础信息 JSON
134
135	按 3.3 节固定格式封装，作为 `routing_input` 透传给下游。本 skill 不落盘任何文件，JSON 由下游 skill 消费。
136
137	### 4.3 下游拉起动作
138
139	调起对应 skill（`classification-model-orchestration` 或 `uplift-model-task-spec`）并传入 `routing_input` JSON。
140
141	## 5. 与其他 skill 关联
142
143	- 下游（classification）：`classification-model-orchestration` —— 接收 `routing_input` JSON，接管分类建模全流程（task-spec / recommend / feature-matching / development）
144	- 下游（uplift）：`uplift-model-task-spec` —— 接收 `routing_input` JSON，接管 uplift 任务规格化与后续管线
145	- 无上游：本 skill 是建模流程的总入口
146
147	## 6. 执行约束
148
149	1. 不跳过路由：任何建模诉求都先走本 skill，不直接进入 `classification-model-orchestration` 或 `uplift-model-task-spec`
150	2. 不替用户判定：Q1/Q2/Q3 必须让用户明确表态，不靠 LLM 臆测；但用户原始表达已回答的项直接提取，不重复提问
151	3. 不创建目录：本 skill 不创建 session 目录、不落盘任何文件，所有产物由下游负责
152	4. 信息透传不丢失：JSON 必须包含全部已收集信息，下游不得要求用户重复回答
153
154	## 7. 异常处理
155
156	### 7.1 既非 classification 也非 uplift
157
158	- 场景：用户诉求属于回归（金额/时长/次数）、多分类、聚类、时序预测、

People who liked this also viewed

6 picks

Type