第三章 需求收集前的边界预判：行业调研、竞品分析、技术可行性扫描

产品需求收集并非从零开始。在第一次用户访谈或问卷发放之前，团队必须完成边界预判——通过行业调研、竞品分析、技术可行性扫描，锁定需求探索的合理范围，避免在立项阶段就陷入“什么都想做”或“技术不现实”的困境。

3.1 为什么需要边界预判？

缺乏预判直接导致两个典型问题：

• 需求发散：访谈时被用户的“愿望清单”带偏，产出大量无法落地的特性。
• 技术盲区：需求正式开发时才发现关键算法/算力/数据不可行，造成返工或砍需求。

3.2 三轴预判模型

我们将边界预判拆为三个并行的分析轴，分别对应市场/用户空间、竞争差异、技术约束：

3.3 行业调研：锁定用户场景基线

行业调研不是罗列市场规模数据，而是聚焦“用户在没有该AI产品时如何完成当前任务”：

1. 场景识别：通过行业报告、用户论坛、客服记录提取高频痛点。
2. 基线方案测量：手动完成一个任务的耗时、准确率、工具依赖。
3. 机会估算：AI介入后理论可提升的KPI上限。

3.4 竞品分析：绘制特性空白地图

关注点不是“竞品有什么”，而是“竞品没有做好”或“竞品做了但体验差”的区域：

• 列出主要竞品的AI模块（如智能补全、异常检测、摘要生成）。
• 标注每个模块的用户评价（应用商店、社交平台中的低分点）。
• 整理成竞品特性矩阵，用“已覆盖/弱覆盖/空白”标识。

竞品特性矩阵（片段示例）
+----------------+----------+----------+----------+
| 特性           | 竞品A    | 竞品B    | 竞品C    |
+----------------+----------+----------+----------+
| 实时翻译       | ✅强     | ✅强     | ❌无     |
| 专业术语优化   | ⚠弱     | ❌无     | ❌无     |
| 多轮对话记忆   | ❌无     | ⚠弱     | ✅强     |
+----------------+----------+----------+----------+

3.5 技术可行性扫描：约束前置

技术扫描的结果直接决定哪些候选特性可以进入需求收集池：

• 数据层面：是否存在标注数据？数据量级够训练？隐私合规是否允许？
• 模型层面：推理延迟能否满足实时性？显存/算力成本是否可控？有无现成预训练模型可微调？
• 工程层面：与现有系统对接的API变更量、模型部署方式（端侧/云端）、监控指标对齐。

技术约束清单（示例）
特性: 合同条款关键信息提取
- 数据: 已有5000份脱敏合同，但标注字段仅3个，需补充标注
- 模型: Bert-CRF 推理延迟 ~200ms/份，满足业务要求
- 工程: 需部署 GPU 推理节点，月成本约 ¥2000
- 风险: 少数民族语种条款无训练数据，暂不支持

3.6 边界预判与需求收集的衔接

三个分析轴的输出最终汇总为“候选特性红绿灯表”，作为用户访谈时引导问题的依据：

3.7 边界预判工作流（内联SVG框架图）

3.8 交付物模板

本章完成后应产出的文档结构：

# 
1. 行业调研摘要
   - 目标用户场景（3-5个典型场景）
   - 人工基线KPI（耗时、准确率）
   - 机会窗口量化（可提升倍数）
2. 竞品特性矩阵
   - 对标竞品列表 + 版本日期
   - 特性覆盖度表格（已覆盖/弱/无）
   - 差异化机会清单（格式：特性名 + 竞品短板描述 + 预估用户价值）
3. 技术可行性扫描
   - 候选特性清单
   - 数据可用性评估（有/无/需扩充）
   - 模型选型与延迟/成本估算
   - 工程风险等级（低/中/高）
4. 红绿灯表（最终入池建议）
   - 【绿灯】直接进入需求收集
   - 【黄灯】保留但需验证特定假设
   - 【红灯】本阶段放弃，记录原因