publication-grounded-solution-design

基于文献的解决方案设计

将模糊的行业问题转化为一组有依据的解决方案方向，并以文献、过往部署案例和评估计划作为支撑。

目标不是罗列泛泛的 AI 创意，而是找出有可信先例的方法，说明这些方法为何可能适用，并指出在用户的场景中仍需验证的内容。

何时使用此技能

当用户希望：

• 为模糊的行业或研发问题构思解决方案；
• 为内部提案起草方法部分；
• 用论文、案例研究或技术报告为拟议方案提供依据；
• 比较 ML、优化、LLM、基于规则、工作流或数据产品方案；
• 确定哪些证据足以支持试点时，请使用此技能。

如果用户只想了解广泛的研究图景，请先使用 literature-triangulation。如果用户已有具体方法并需要设计实验，请使用 experiment-design 或 pilot-and-evaluation-design。

工作流

1. 准确界定行业问题

提取或询问以下内容：

• 要改进的业务流程或决策；
• 目标用户和利益相关方；
• 当前痛点；
• 可用数据或预期信号；
• 延迟、可解释性、合规、成本、人工审核和集成等运营约束；
• 成功后实践中会发生哪些改变。

按以下格式描述问题：

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

如果问题仍然模糊，请指出缺失的信息，而不要凭空编造。

2. 根据问题特征寻找先例

根据底层问题类型搜索，而不仅仅是领域标签。

示例：

• “减少人工审核负担” → 分流、人机协同优先级排序、主动学习、决策支持；
• “检测可疑行为” → 异常检测、图欺诈检测、弱监督、序列模式挖掘；
• “理解客户意图” → 表征学习、检索、细分、下一最佳行动、因果增益；
• “自动处理文档” → 文档 AI、信息抽取、检索增强生成、验证工作流。

优先考虑：

1. 经同行评审的论文，以及包含实验的 arXiv 论文；
2. 基准或数据集论文；
3. 官方系统论文和技术报告；
4. 提供具体指标且可信的行业案例研究；
5. 综述仅用作研究地图，不作为最终证据。

3. 建立先例表

针对每个相关来源，记录：

来源	匹配的问题	方法	证据	场景	可迁移性	注意事项

可迁移性应说明，结果要适用于用户的环境，必须满足哪些条件。

示例：

• 数据粒度相似；
• 标签质量相似；
• 监管约束相似；
• 交易、客户或文档分布相当；
• 人工反馈闭环可行。

4. 生成解决方案候选项

每个候选方案都应包括：

• 方法类别；
• 核心机制；
• 支持来源；
• 所需数据；
• 预期收益；
• 运营风险；
• 评估策略；
• 最简试点版本。

优先提供 3–5 个候选方案。避免罗列大量浅显的想法。

将候选方案分为：

• 近期试点：可用现有数据测试，集成负担较低；
• 战略研发方向：前景可观，但需要数据、基础设施、治理或研究工作；
• 暂不推荐：看似有吸引力，但缺乏依据、不可行或风险过高。

5. 起草方法概述

为最有力的候选方案起草简洁的方法部分：

Method concept:
We propose [approach] for [problem]. The method uses [inputs] to produce [outputs/interventions]. It is motivated by [paper/case evidence], where similar mechanisms improved [metric/outcome]. In our setting, the key adaptation is [domain-specific change].

然后说明：

• 模型或算法组件；
• 训练或拟合流程；
• 决策阈值设置或人机协同工作流；
• 可解释性或审计层；
• 试点的部署边界。

6. 在实施前定义评估方式

每个提议的解决方案都需要一条验证路径：

• 使用历史数据进行离线评估；
• 如果决策具有时间属性，则进行回测或重放；
• 与当前流程进行基线比较；
• 如果输出会影响判断或写作，则进行人工评估；
• 对声称有效的机制进行消融实验；
• 在相关情况下，检查公平性、稳健性、隐私和合规性。

对于每项指标，请说明它支持什么决策。不要纳入装饰性指标。

7. 校准置信度

使用明确的置信度等级：

• 高：有多个独立来源，研究情境相似，评估路径明确，且数据可行。
• 中：有可靠的方法先例，但能否迁移取决于尚未验证的假设。
• 低：想法看似合理，但证据有限或可行性存在重大不确定性。

切勿将有文献支持的想法说成已在用户的场景中得到验证。文献依据支持开展试点；试点用于验证能否迁移。

输出格式

使用以下结构：

# Publication-grounded solution design: [problem]

## Problem framing
- Stakeholders:
- Current pain:
- Decision/workflow:
- Constraints:
- Success criteria:
- Missing information:

## Prior successful cases and literature
| Source | Problem matched | Method | Evidence | Transferability | Caveats |
|---|---|---|---|---|---|

## Solution candidates
### Candidate 1: [name]
- Method family:
- Core idea:
- Supporting publications/cases:
- Required data:
- Expected benefit:
- Risks:
- Evaluation:
- Pilot version:
- Confidence:

## Recommended direction

## Draft method concept

## Evaluation plan

## Open questions before pilot

## Sources to read next

质量标准

优秀的回答应当：

• 引用具体来源，或明确说明仍需检索来源；
• 区分已验证的先例与迁移假设；
• 将每种方法与用户的实际运营约束联系起来；
• 纳入基线和评估标准；
• 避免在瓶颈实际出在数据、工作流、激励或治理时，假装模型就是解决方案。