industry-problem-framing

行业问题界定

将模糊的业务问题转化为可研究、可试点的研发问题。

目标是防止过早着手制定解决方案。在提出方法之前，必须先将“用 AI 改进运营”这类模糊需求转化为具体的决策、工作流、指标和证据需求。

何时使用此技能

在以下情况下使用此技能：

• 用户的业务或行业问题不明确；
• 利益相关者对问题的含义存在分歧；
• 用户需要集思广益，但要避免浅层的创意列表；
• 下一步是文献检索、解决方案设计或试点规划；
• 用户需要一份内部研发问题界定备忘录。

如果用户已经提出明确的问题，并希望获取有论文依据的方法，请改用 publication-grounded-solution-design。

工作流

1. 记录原始问题陈述

原样写下用户的问题，然后提取：

• 领域和业务部门；
• 当前工作流；
• 用户和决策者；
• 痛点；
• 约束；
• 已知数据源；
• 提议的解决方案（如有）；
• 问题为何现在很重要。

暂时不要改进措辞。首先保留其中的模糊之处。

2. 找出实际决策或工作流

大多数行业研发问题都涉及改变某项决策或工作流。

请询问：

• 目前由谁做出决策？
• 他们会使用哪些信息？
• 决策之后会采取什么行动？
• 哪种失误代价高昂？
• 如果模型或系统出错，会发生什么？
• 目标是自动化、优先级排序、解释、建议、监控，还是生成洞察？

将问题归为以下一个或多个类别：

• 预测；
• 排序或优先级排序；
• 异常检测；
• 分群；
• 推荐或下一最佳行动；
• 信息提取；
• 决策支持；
• 流程挖掘；
• 因果测量；
• 预测；
• 优化；
• 知识管理；
• 提升人工生产力。

3. 梳理利益相关者及其激励因素

针对每位利益相关者，记录：

利益相关者	痛点	期望结果	约束	可能的冲突

视情况纳入运营、风险、合规、法务、数据、产品、工程和一线用户。

4. 将痛点转化为假设

提出可证伪的假设：

If we [intervention], then [target metric] improves for [population/process] because [mechanism], compared with [baseline].

示例：

• 如果我们将高风险案例优先交由人工审核，那么调查人员每小时处理的真阳性案例就会增加，因为低价值案例会被提前筛除。
• 如果我们在处理投诉时检索类似的已解决案例，那么平均处理时间就会缩短，因为客服人员可以复用经过验证的解决方案模式。

5. 区分业务指标和技术指标

业务指标回答这项工作是否有价值。技术指标回答系统是否有效。

示例：

• 业务：每个审核案例的成本、解决时间、固定风险水平下的批准率、欺诈损失、客户流失率、NPS、SLA 合规率。
• 技术：precision@k、固定工作量下的召回率、校准度、AUC、延迟、提取 F1、幻觉率、人工接受率。

将每项技术指标与业务决策挂钩。删除不会影响行动的指标。

6. 确定数据和证据需求

列出：

• 可用的表格／文档／日志；
• 标签或代理指标；
• 观察窗口；
• 数据泄漏风险；
• 隐私或合规约束；
• 分析单位；
• 人群覆盖范围；
• 数据刷新频率；
• 集成路径。

标明问题是否受以下因素阻碍：

• 缺少标签；
• 真实基准数据薄弱；
• 没有行动日志；
• 权责不明确；
• 成功无法衡量；
• 合规约束；
• 样本量不足；
• 行为非平稳。

7. 提出检索方向

将界定后的问题转化为文献检索线索：

• 领域术语；
• 方法术语；
• 基准术语；
• 问题形态相似的相邻领域；
• 负面结果或局限性检索词。

这样即可将任务交接给 publication-grounded-solution-design 或 literature-triangulation。

输出格式

# Industry problem framing: [short title]

## Raw problem

## Clarified problem statement
For [stakeholder/process], improve [decision/workflow/outcome] by using [available signals/interventions], subject to [constraints], measured by [business and technical metrics].

## Stakeholder map
| Stakeholder | Pain | Desired outcome | Constraint | Possible conflict |
|---|---|---|---|---|

## Decision/workflow analysis
- Current workflow:
- Decision point:
- Failure modes:
- Cost of errors:
- Human-in-the-loop needs:

## Candidate hypotheses
1. If ..., then ..., because ..., compared with ...

## Metrics
- Business metrics:
- Technical metrics:
- Guardrail metrics:

## Data and feasibility
- Available data:
- Labels/proxies:
- Leakage risks:
- Compliance/privacy constraints:
- Blockers:

## Literature and precedent search directions
- Domain queries:
- Method queries:
- Adjacent-domain analogues:
- Limitation queries:

## Recommended next step

质量标准

好的问题框架应清楚说明要搜索什么、要衡量什么，以及提出方法前必须澄清什么。