combo-needs-to-direction

name	combo-needs-to-direction
description	需求发现 → 方向定界 组合 Skill。从用户痛点出发，系统跑完微需求检测、 真需求验证、四层拆解，输出可直接进入方向定界的 Direction

需求发现 → 方向定界

一句话定位

从一个模糊的痛点线索出发，跑完需求发现全流程，直接输出 Direction Brief。

何时触发

• 你有一个产品想法，需要快速验证并进入方向定界
• 不想分别调用多个工具卡，需要一站式输出
• 需要从"我有一个想法"到"方向定界简报"的最短路径

输入

一个模糊的产品想法或痛点描述。

示例输入：

"我想做一个帮律师自动审查合同的 AI 产品"

编排流程

输入: 模糊想法
  ↓
【Step 1】微需求检测 (p0a)
  → 是否存在被忽视的微需求？
  → 是否需要重新定义问题？
  ↓
【Step 2】需求四层拆解 (p0c)
  → 表达层：用户说了什么
  → 场景层：问题发生在哪里
  → 处境层：谁被困住了
  → 代价层：不解决会怎样
  ↓
【Step 3】真需求验证 (p0b)
  → 5问验证：长期性、代价、补偿行为、结构性、自然存续
  → 真/伪判定
  ↓
【Step 4】方向定界准备
  → 将需求发现结果转化为 Direction Brief 输入
  → 明确问题定义、场景切入、资料条件
  ↓
输出: Direction Brief（可直接进入 p1）

综合输出格式

direction_brief_input:
  source: "原始想法"
  
  problem_definition:
    surface_problem: "表面问题"
    deep_problem: "深层问题"
    why_different: "为什么不同"
  
  scenario_entry:
    user: "目标用户"
    scenario: "使用场景"
    pain_point: "核心痛点"
  
  evidence:
    micro_needs: ["微需求发现"]
    real_need_validation: "真需求验证结果"
    cost_evidence: "代价证据"
    compensation_behaviors: ["补偿行为"]
  
  data_readiness:
    available_data: "可获取的数据"
    data_sensitivity: "数据敏感度"
    access_difficulty: "获取难度"
  
  preliminary_judgment:
    worth_pursuing: true/false
    confidence: "high/medium/low"
    key_risks: ["风险列表"]
    next_step: "进入方向定界 (p1)"

一句判断

好的方向定界，始于好的需求发现。不要带着假设进入方向定界，要带着证据。

核心概念

概念一：需求发现和方向定界是两个不同的判断

需求发现回答"这个问题值不值得做"，方向定界回答"这个问题怎么切入"。很多团队跳过需求发现直接做方向定界，结果是在一个伪需求上浪费方向定界的时间。

两阶段的核心差异：

维度	需求发现 (P0)	方向定界 (P1)
核心问题	这个问题真实吗？	这个问题怎么切入？
关键判断	真/伪需求	go/no-go
输出物	Needs Brief	Direction Brief
方法论	微需求检测+四层拆解+真需求验证	五维度判断+资料审查+能力评估

不要带着假设进入方向定界，要带着证据。

概念二：从需求发现到方向定界的转换逻辑

需求发现的输出必须转化为方向定界的输入。转换的关键是把"问题语言"转化为"实验语言"：

需求发现输出：
  - 核心问题是什么（问题定义）
  - 用户在什么处境中遇到这个问题（场景切入）
  - 问题的深层结构是什么（约束条件）
  
方向定界输入：
  - 问题定义 → 问题是否真实且高频？
  - 场景切入 → 场景是否可切入？
  - 约束条件 → 资料是否可得？能力是否可能？

概念三：三个拦截点——在进入方向定界前必须通过

拦截点	判断标准	不通过则
真需求验证	五问 ≥3 通过	回到需求发现重新定义
Agent 适配	评分 ≥60	考虑非 AI 方案
处境清晰度	能描述 ≥2 个具体场景	补充用户研究

三个拦截点不是形式检查，而是防止在错误方向上浪费资源。

概念四：Direction Brief 的五个必答问题

从需求发现到方向定界，最终输出的 Direction Brief 必须回答五个问题：

1. 问题是否真实且高频？ → 来自需求发现的真需求验证
2. 场景是否可切入？ → 来自需求发现的处境映射
3. 资料是否可得且可控？ → 新增审查（可得性、可脱敏性、可授权性、可结构化、持续供给）
4. 能力是否可能成立？ → 新增评估（用最强模型做最小验证）
5. 价值是否值得继续？ → 新增判断（即使技术可行，是否足以形成产品价值）

概念五：不建议推进的四种情况

情况	原因	建议
资料条件不成立	没有足够资料或无法脱敏/授权	先解决资料问题
容错率极低且不能保留人工接管	医疗诊断、法律结论等	重新定义场景边界
场景频率太低、价值太弱	投入产出不划算	寻找更高频场景
团队无法获得真实反馈	无法验证假设	先建立反馈渠道

分步执行

Step 1：需求发现——微需求检测 + 四层拆解 + 真需求验证

输入：用户原始想法

处理：

1. 微需求检测：用五问检测是否存在被忽视的微需求
2. 四层拆解：表达层→场景层→处境层→代价层
3. 真需求验证：五问判断（长期性、代价、补偿行为、结构性、自然存续）

输出：需求验证结果 + 重定义的问题（如有）

---

Step 2：拦截点检查——是否值得进入方向定界

输入：Step 1 的需求验证结果

处理：

1. 真需求验证：五问 ≥3 通过？
2. Agent 适配：评分 ≥60？
3. 处境清晰度：能描述 ≥2 个具体场景？

输出：通过/不通过 + 不通过的原因和建议

---

Step 3：问题语言转换——从功能语言到问题语言

输入：已验证的需求

处理：

1. 将"我想做 X 产品"转换为"用户在 Y 场景下遇到 Z 问题"
2. 明确问题的真实性和频率
3. 明确场景的切入方式

输出：问题语言描述（含场景和频率）

---

Step 4：资料条件审查——五维度审查

输入：问题语言描述

处理：

1. 可得性：团队能拿到哪些资料？
2. 可脱敏性：资料能否脱敏处理？
3. 可授权性：资料使用是否获得合规授权？
4. 可结构化：资料能否被清理、索引和持续供给？
5. 持续供给：资料是否会持续更新？

输出：资料条件审查报告

---

Step 5：能力评估 + 价值判断

输入：问题描述 + 资料条件

处理：

1. 用最强模型做最小验证，判断 AI 在该场景的能力上限
2. 评估即使技术可行，这个方向是否足以形成产品价值
3. 评估进入实验的条件

输出：能力评估 + 价值判断 + 进入条件

---

Step 6：输出 Direction Brief

输入：Step 1-5 的全部输出

处理：

1. 整合问题定义、场景切入、资料清单
2. 明确风险边界和必须人工接管的场景
3. 定义进入实验的条件
4. 如果条件不满足，给出"不建议推进"的明确结论

输出：Direction Brief

示例 1：律师合同审查——从需求发现到方向定界

场景描述：用户说"我想做一个帮律师自动审查合同的 AI 产品"。

Step 1 需求发现：

• 微需求检测：律师每天花大量时间审查合同中的重复性条款，这是高频微需求
• 四层拆解：
  • 表达层："帮律师自动审查合同"
  • 场景层：律师在办公室审合同，面对几十页 PDF
  • 处境层：初级律师不敢漏掉风险条款（怕被合伙人骂），但又不确定哪些条款有风险
  • 代价层：漏掉一个风险条款 → 客户损失 → 律所声誉受损
• 真需求验证：5/5 通过（长期存在、代价持续、有补偿行为、有结构、自然存续）

Step 2 拦截点检查：

• 真需求？✅
• Agent 适配？✅（合同审查有明确边界，错误可人工兜底）
• 处境清晰？✅（初级律师审合同、合伙人复核）

Step 3 问题语言转换：

• 原始："帮律师自动审查合同"
• 转换："初级律师在审查合同时，无法快速识别高风险条款，导致漏检和效率低下"

Step 4 资料条件审查：

• 可得性：✅ 监管规则（公开）、历史合同（需脱敏）
• 可脱敏性：⚠️ 需移除客户信息
• 可授权性：⚠️ 需法务确认
• 可结构化：✅ 可整理为知识库
• 持续供给：✅ 合同持续产生

Step 5 能力评估 + 价值判断：

• 能力评估：AI 能识别合同中的关键条款（80%+准确率），能匹配相关法规
• 价值判断：审查时间从 2 小时降至 30 分钟，新人培训周期从 3 个月降至 1 个月
• 进入条件：获取 100 份脱敏合同、法务确认可用性、完成影子验证

Step 6 Direction Brief：

# Direction Brief：AI 合同审查助手

## 目标问题
初级律师审查合同效率低、漏检风险高，过度依赖合伙人经验

## 场景边界
- 先做：风险条款高亮、法规引用、相似案例提示
- 暂不做：最终合规判断、替代律师签字

## 资料盘点
- ✅ 监管规则（公开）
- ⚠️ 历史合同（需脱敏+法务确认）

## 能力假设
AI 能识别关键条款、匹配法规、标记风险

## 风险边界
- 所有 AI 输出仅供律师参考，不作为法律意见
- 最终判断权归律师

## 进入条件
- [ ] 获取 100 份脱敏合同
- [ ] 法务确认可用性
- [ ] 完成影子验证（AI vs 律师对比）
- [ ] 条款识别准确率 > 85%

---

示例 2：AIOps 故障分诊——从需求发现到方向定界

场景描述：用户说"我们想做 AIOps，自动修复生产故障"。

Step 1 需求发现：

• 微需求检测：运维团队每周多次面对告警风暴，每次故障触发几十条告警
• 四层拆解：
  • 表达层："自动修复生产故障"
  • 场景层：值班工程师在监控大屏前，告警不断弹出
  • 处境层：新人值班时不敢做判断（怕误操作放大事故），老工程师被频繁打扰
  • 代价层：定位时间长 → 故障影响扩大 → 用户投诉
• 真需求验证：5/5 通过

Step 2 拦截点检查：

• 真需求？✅
• Agent 适配？⚠️ "自动修复"风险极高，但"辅助分诊"适配
• 处境清晰？✅

Step 3 问题语言转换：

• 原始："自动修复生产故障"（过于激进）
• 转换："故障发生时，如何更快完成初步判断和分诊"

Step 4 资料条件审查：

• 可得性：✅ 历史故障工单、日志样本、监控信号、处理手册
• 可脱敏性：✅ 已脱敏
• 可结构化：✅ 可整理为知识库
• 持续供给：✅ 故障持续产生

Step 5 能力评估 + 价值判断：

• 能力评估：告警聚类、日志解释、案例召回可行
• 价值判断：定位时间从 45 分钟降至 15 分钟
• 关键边界：错误归因可能放大事故，不适合全自动

Step 6 Direction Brief：

# Direction Brief：AIOps 故障分诊辅助系统

## 目标问题
故障告警过多（平均 30 条/次），定位时间长（平均 45 分钟），过度依赖专家经验

## 场景边界
- 先做：告警聚类、日志摘要、相似案例召回、初步归因建议
- 明确不做：自动修复、自动重启、自动切流

## 资料盘点
- ✅ 历史故障工单（2000 条，已脱敏）
- ✅ 日志样本（ELK 可查询）
- ✅ 监控信号（Prometheus）
- ✅ 处理手册（Confluence）

## 能力假设
能理解日志、关联多源信号、召回历史案例，输出"先看哪里"的建议

## 风险边界
- 所有输出只能作为建议，不作为命令
- 高风险动作必须双人确认
- AI 不能直接操作生产环境

## 进入条件
- [x] 资料可用性确认
- [x] 风险边界与 SRE 团队达成一致
- [ ] 完成影子验证（对比人工判断）
- [ ] 召回准确率 > 80%

需求发现是方向定界的地基。地基不稳，方向定界就是在沙子上盖楼。