Scene analysis

Scene Analysis — 场景分析与路径判断

咨询链位置

在 SOP 中： Module 0，所有 AI 项目的真正起点。在进入任何技术设计之前，必须先完成场景分析。

核心理念： 整体以 AI Native Agent Builder 为主。DL 小模型是场景驱动的补充，不是架构预设。大小模型连用只在场景真正需要时才引入。

常见联动：

• 结论为"适合大模型/Agent" → pseudo-ai-detection → ai-native-vs-ai-enhanced
• 结论为"需要感知能力补充" → dl-problem-framing → dl-model-selection
• 结论为"不适合 AI" → 直接 Vibe Coding 或流程优化
• 结论模糊 → pseudo-ai-detection 先过一遍

---

核心判断框架

第一步：需求分类（A/B/C/D）

在进入任何技术讨论之前，先做分类：

类别	描述	典型特征
A 类	适合大模型 / 知识问答 / Agent	涉及语言、知识、推理、多步流程、内容生成
B 类	适合 workflow / 信息汇编 / 助手	有固定流程、需要信息整合、低复杂度自动化
C 类	更适合规则 / 检索 / BI / 数据治理	逻辑清晰可规则化、统计分析为主、数据质量问题
D 类	当前不建议推进	条件不具备、风险过高、伪需求

分类判断的八个问题：

1. 这个问题主要涉及语言、知识、问答、总结、内容生成？
2. 这个问题需要处理大量文本/资料/制度/文档？
3. 这个问题需要多步流程，而不是单轮问答？
4. 这个问题需要调用多个工具或外部系统？
5. 这个问题更像结构化筛选/规则判断/统计分析？
6. 这个问题结果错误会带来较大业务风险？
7. 这个问题必须保留人工审批或确认？
8. 这个问题当前更像数据治理或流程规范问题？

分类逻辑：

• 问题 1-4 多数为"是" → A/B 类
• 问题 5 或 8 为"是" → C 类优先
• 问题 6-7 都为"是"且问题 1-4 不明确 → D 类（先做人工流程规范）

---

第二步：技术路径初判

确认分类后，判断具体技术路径：

场景分类结论
      ↓
A/B 类（涉及语言/推理/流程）
  ├── 单轮问答 / 知识检索 → 知识库问答助手（RAG）
  ├── 多步流程 / 工具调用 → Workflow 助手
  ├── 复杂推理 / 自主决策 → Agent（进入 Module 1-6）
  └── 快速原型验证 → AgentBuilder 低代码原型

C 类（规则/数据/检索）
  ├── 规则明确 → 直接写代码（Vibe Coding）
  ├── 数据分析为主 → BI 工具 / SQL
  └── 数据质量差 → 先做数据治理

D 类 → 暂缓，先解决前置条件

关于 DL 小模型的引入时机：

DL 不是必选项，只在以下场景才引入：

• 核心输入是图像/视频（CV 任务）
• 核心输入是文档图片/票据（OCR 任务）
• 核心输入是传感器时序数据（时序任务）
• 核心输入是语音录音（Speech 任务）

如果没有上述类型的输入，直接走大模型/Agent 路径，不需要 DL。

---

第三步：优先级判断

维度	高优先级信号	低优先级信号
业务价值	高频、高痛点、影响面广	低频、边缘场景
实施难度	数据具备、流程清晰	数据缺失、跨部门依赖多
当前基础	有可用数据、有推动权限	数据孤岛、需要大量前置条件
验证可能性	可以快速出 MVP 验证	需要半年以上才能看到效果

---

第四步：DL 与大模型的组合决策

不要预设架构，让场景决定组合方式：

场景只需要感知（识别/检测/提取）
  → 只用 DL 小模型（路径 A）
  → 例：工业缺陷检测、仪表数值读取

场景只需要推理/生成/对话
  → 只用大模型/Agent（路径 B）
  → 例：月报生成、知识问答、流程决策

场景需要感知 + 推理
  → 大小模型连用（路径 C）
  → 小模型负责感知，大模型负责理解和生成
  → 例：票据识别+财务入账、质检+原因分析

规则可以完全描述
  → 不需要 AI（路径 D）
  → 例：固定格式报表、数据统计、格式转换

大小模型连用的触发条件（必须两个都满足）：

1. 有非结构化输入（图像/音频/扫描件）需要先感知
2. 感知结果需要被进一步理解、分析或生成自然语言

---

输出格式

## 场景分析报告

**业务场景：** [描述]
**提出部门/来源：** [填入]
**分析日期：** [日期]

### 需求分类
- 类别：A / B / C / D
- 三句话理由：
  1. [第一个判断依据]
  2. [第二个判断依据]
  3. [第三个判断依据]

### 技术路径
- 推荐路径：知识库问答 / Workflow / Agent / AgentBuilder原型 / 规则代码 / DL小模型 / 大小模型连用
- DL 是否需要：是（原因）/ 否
- 路径理由：[一句话]
- 不推荐其他路径的原因：[一句话]

### 优先级
- 级别：高 / 中 / 低 / 暂缓
- 业务价值：[评估]
- 实施难度：[评估]
- 当前基础：[评估]

### 第一阶段建议
- 做什么：[一句话，具体且可验证]
- 不做什么：[明确排除]
- 验证标准：[怎么算成功]

### 下一步
- 路径 A/B/Agent → `pseudo-ai-detection` 再过一遍，然后 `ai-project-definition`
- 路径 C（DL）→ `dl-problem-framing` → `dl-data-strategy`
- 路径 D → 说明原因，建议替代方案

---

常见误判与纠正

误判 1："我们要做一个 AI 系统" 没有明确用户、任务和验证标准的需求，不是 AI 项目，是愿景。先用本 Skill 做场景分析，再进入项目定义。

误判 2："这个要加 AI，让它更智能" "更智能"不是需求。问：智能在哪一步体现？这一步现在怎么做的？加了 AI 之后用户的操作会有什么具体变化？

误判 3："我们需要大小模型连用" 大小模型连用是场景结论，不是架构预设。先判断有没有感知任务（图像/音频/时序），再判断感知结果是否需要进一步理解，两个都是才考虑连用。

误判 4："DL 精度不够，用大模型视觉理解" 大模型做图像感知（分类/检测/OCR）的成本是专用小模型的 10-100 倍，速度慢 10-50 倍。工业量产场景用专用小模型，大模型做分析层。

误判 5："规则能做，但 AI 更高级" 高级不等于合适。规则方案：2 天完成，零运维成本，100% 可解释。AI 方案：2 周开发，需要维护，有不确定性。如果规则够用，就用规则。