name: skill-validation
version: 1.0.0
description: Validates new feature requirements before development begins. Combines requirement smell detection (ambiguity, incompleteness, untestability), deduplication against existing features, and multi-dimensional scoring (RICE + ISO 29148 hybrid) to produce go/no-go decisions with improvement suggestions. Trigger words: "验证需求", "评估需求", "需求评审", "validate requirement", "这个需求靠谱吗", "/validate".
需求验证判别系统
版本：v1.0.0 | 状态：已落地 | 触发：/validate、"验证需求"、"评估需求"、"需求评审"、"这个需求靠谱吗"
在中大型功能需求提出时，先验证再动手——检测需求气味、排查功能雷同、多维度打分，输出"通过 / 改进 / 驳回"的结构化判定。
目录
为什么需要
不验证需求直接开发：
"加个 XXX 功能" → 写代码 → 发现需求模糊 → 返工
"做个 YYY 模块" → 写代码 → 发现跟现有功能重复 → 浪费
"需要 ZZZ 能力" → 写代码 → 发现价值不高 → 搁置
验证后再开发：
┌────────────── 需求验证 ──────────────┐
│ │
│ Phase 1: 气味检测 → 需求写清楚了吗？ │
│ Phase 2: 雷同排查 → 已有功能覆盖吗？ │
│ Phase 3: 价值打分 → 值得做吗？ │
│ Phase 4: 综合判定 → 通过/改进/驳回 │
│ │
└───────────────────────────────────────┘
问题在动手前暴露 → 省时间、省精力
触发词
- "验证需求"、"评估需求"、"需求评审"
- "这个需求靠谱吗"、"这个功能值得做吗"
- "帮我判断一下这个需求"
- "validate requirement"、"validate feature"
- "/validate"
适用场景
| 场景 | 例子 | 谁发起 |
|---|
| 新功能提出 | "我们要做一个知识库功能" | 产品/技术负责人 |
| 需求评审会前 | "下周评审，先跑一遍验证" | 开发者 |
| 外部需求对接 | "客户要求加个 XXX" | 产品经理 |
| 技术方案前置 | "这个方案的需求合理吗" | 架构师 |
| 积压需求清理 | "Backlog 里这些需求还有效吗" | 团队 lead |
不适用场景（避免误触发）：
- Bug 修复（用
/verify）
- 1-2 天的小改动（直接做）
- 纯技术重构（用
/risk）
执行流程
执行进度：
- [ ] Phase 1: 需求气味检测
- [ ] Phase 2: 功能雷同排查
- [ ] Phase 3: 七维度价值打分
- [ ] Phase 4: 综合判定与建议
Phase 1: 需求气味检测
借鉴 ARTA（9 种气味）和 Paska（NLP + 修复建议）的学术模式，适配 LLM 判别。
逐项检查以下 8 种需求气味，每项标记「无气味」/「有气味」：
| # | 气味类型 | 检测标准 | 示例 |
|---|
| 1 | 模糊性 (Ambiguity) | 含"等"、"相关"、"适当"、"一些"等模糊词 | "支持一些常见格式" → 哪些格式？ |
| 2 | 不完整性 (Incompleteness) | 缺少主语/宾语/条件/异常处理描述 | "用户可以导出" → 导出什么？什么格式？ |
| 3 | 不可测试性 (Untestability) | 无法定义验收标准 | "系统要快" → 多快算快？ |
| 4 | 不原子性 (Non-atomicity) | 一条需求包含多个独立功能 | "支持导入导出和批量编辑" |
| 5 | 矛盾性 (Contradiction) | 与已有需求或系统行为冲突 | "所有用户可见" vs 已有的 RBAC 权限 |
| 6 | 过度约束 (Over-specification) | 限定了实现方式而非目标 | "用 Redis 做缓存" → 目标是什么？ |
| 7 | 隐式依赖 (Implicit dependency) | 依赖未明确说明的前置功能 | "在知识库中搜索" → 知识库还没实现 |
| 8 | 无边界 (Unbounded scope) | 没有明确的范围边界 | "支持所有文件类型" → 真的所有？ |
检测方法：
- 提取需求描述的关键语句
- 逐项对照气味检查表
- 有气味的条目给出 具体位置 + 修复建议
Phase 2: 功能雷同排查
对照 codebase-snapshot.md 的功能状态表和 MongoDB 集合列表，排查功能重叠。
排查步骤：
1. 从需求中提取核心功能关键词
2. 对照已完成功能列表，检查是否已有覆盖
3. 对照部分完成/未实现功能，检查是否在规划中
4. 对照 MongoDB 集合列表，检查是否已有数据模型
5. 给出雷同度评估：
- 无重叠：全新功能
- 部分重叠：可在现有功能上扩展
- 高度重叠：现有功能已覆盖或即将覆盖
如果发现重叠，需说明：
- 重叠的具体功能是什么
- 建议"复用 / 扩展 / 独立开发"哪种策略
Phase 3: 七维度价值打分
融合 RICE（Intercom）、WSJF（SAFe）和 ISO 29148 质量属性。
每个维度 1-10 分，附简要理由：
| # | 维度 | 评分标准 | 权重 |
|---|
| 1 | 用户价值 (User Value) | 解决多少用户的什么痛点？频次多高？ | 20% |
| 2 | 需求清晰度 (Clarity) | Phase 1 气味检测的综合结果 | 15% |
| 3 | 雷同度 (Novelty) | Phase 2 排查结果，越新颖分越高 | 10% |
| 4 | 技术可行性 (Feasibility) | 现有架构能否支撑？依赖多复杂？ | 15% |
| 5 | 战略对齐 (Strategic Fit) | 与产品方向、核心架构模式是否一致？ | 15% |
| 6 | 时间敏感度 (Time Criticality) | 延迟交付的成本有多高？ | 10% |
| 7 | 维护负担 (Maintenance Cost) | 长期维护成本、对系统复杂度的增量 | 15% |
加权总分计算：
总分 = Σ(维度分数 × 权重)
Phase 4: 综合判定
判定标准：
┌─────────────────────────────────────────┐
│ │
│ ≥ 7.0 通过 │
│ → 需求质量达标，建议进入 /risk 评估 │
│ │
│ 5.0-6.9 需改进 │
│ → 输出改进清单，修订后重新验证 │
│ │
│ < 5.0 驳回 │
│ → 说明主要原因 + 替代建议 │
│ │
│ 特殊规则： │
│ - Phase 1 有 ≥3 个气味 → 自动降级为需改进 │
│ - Phase 2 高度重叠 → 自动降级为需改进 │
│ - 用户价值 ≤ 3 → 无论总分，最高为需改进 │
│ │
└─────────────────────────────────────────┘
输出模板
# 需求验证报告
> **需求**: [一句话概述需求]
> **提出方**: [产品/客户/技术]
> **验证日期**: [日期]
## Phase 1: 需求气味检测
| # | 气味类型 | 状态 | 问题描述 | 修复建议 |
|---|----------|------|----------|----------|
| 1 | 模糊性 | 无气味/有气味 | [具体问题] | [修复建议] |
| 2 | 不完整性 | 无气味/有气味 | [具体问题] | [修复建议] |
| 3 | 不可测试性 | 无气味/有气味 | [具体问题] | [修复建议] |
| 4 | 不原子性 | 无气味/有气味 | [具体问题] | [修复建议] |
| 5 | 矛盾性 | 无气味/有气味 | [具体问题] | [修复建议] |
| 6 | 过度约束 | 无气味/有气味 | [具体问题] | [修复建议] |
| 7 | 隐式依赖 | 无气味/有气味 | [具体问题] | [修复建议] |
| 8 | 无边界 | 无气味/有气味 | [具体问题] | [修复建议] |
**气味总结**: [N/8 项有气味]
## Phase 2: 功能雷同排查
| 关键词 | 匹配的现有功能 | 重叠程度 | 建议策略 |
|--------|--------------|----------|----------|
| [关键词1] | [功能名 / 无匹配] | 无重叠/部分重叠/高度重叠 | 复用/扩展/独立 |
**雷同结论**: 无重叠 / 部分重叠 / 高度重叠
## Phase 3: 七维度价值打分
| # | 维度 | 分数 | 权重 | 加权分 | 理由 |
|---|------|------|------|--------|------|
| 1 | 用户价值 | N/10 | 20% | N | [一句话] |
| 2 | 需求清晰度 | N/10 | 15% | N | [一句话] |
| 3 | 雷同度 | N/10 | 10% | N | [一句话] |
| 4 | 技术可行性 | N/10 | 15% | N | [一句话] |
| 5 | 战略对齐 | N/10 | 15% | N | [一句话] |
| 6 | 时间敏感度 | N/10 | 10% | N | [一句话] |
| 7 | 维护负担 | N/10 | 15% | N | [一句话] |
| | **加权总分** | | | **N/10** | |
## Phase 4: 综合判定
**判定结果**: 通过 / 需改进 / 驳回
**判定依据**:
- 气味检测: [N/8 有气味]
- 功能雷同: [无重叠/部分重叠/高度重叠]
- 加权总分: [N/10]
- 特殊规则触发: [有/无]
**下一步建议**:
1. [建议 1]
2. [建议 2]
---
**改进清单**（需改进时输出）:
| # | 问题 | 改进方案 | 优先级 |
|---|------|----------|--------|
| 1 | [问题] | [方案] | P0/P1/P2 |
端到端示例
示例：验证"知识库功能"需求
输入：
"我们需要做一个知识库功能，用户可以上传文档，系统自动解析并建立索引，支持语义搜索和问答。"
# 需求验证报告
> **需求**: 知识库功能——用户上传文档，自动解析建立索引，支持语义搜索和问答
> **提出方**: 产品
> **验证日期**: 2026-03-19
## Phase 1: 需求气味检测
| # | 气味类型 | 状态 | 问题描述 | 修复建议 |
|---|----------|------|----------|----------|
| 1 | 模糊性 | 有气味 | "文档"未限定类型（PDF？Word？纯文本？） | 明确支持的文档格式列表 |
| 2 | 不完整性 | 有气味 | 缺少：单文档大小限制、总存储限额、解析失败处理 | 补充边界条件和异常处理 |
| 3 | 不可测试性 | 有气味 | "语义搜索"无精度指标，"问答"无质量标准 | 定义搜索 Top-5 命中率目标、问答准确率基线 |
| 4 | 不原子性 | 有气味 | 一条需求含 4 个独立功能（上传、解析、搜索、问答） | 拆分为 4 个用户故事 |
| 5 | 矛盾性 | 无气味 | 与现有系统无冲突 | — |
| 6 | 过度约束 | 无气味 | 未限定技术实现 | — |
| 7 | 隐式依赖 | 有气味 | 语义搜索依赖向量数据库（当前架构仅 MongoDB） | 明确是否引入向量库，还是用 MongoDB Atlas Search |
| 8 | 无边界 | 有气味 | "问答"范围不清——单文档问答还是跨文档？实时还是异步？ | 限定 MVP 范围 |
**气味总结**: 6/8 项有气味
## Phase 2: 功能雷同排查
| 关键词 | 匹配的现有功能 | 重叠程度 | 建议策略 |
|--------|--------------|----------|----------|
| 文档上传 | 附件上传（attachments 集合） | 部分重叠 | 扩展现有附件系统 |
| 文档解析 | PRD 文档解析（documents 集合） | 部分重叠 | 复用解析管线，扩展格式 |
| 语义搜索 | 无匹配 | 无重叠 | 独立开发 |
| 问答 | 对话系统（sessions/messages） | 部分重叠 | 在现有对话中扩展知识库上下文 |
**雷同结论**: 部分重叠——文档上传和对话系统有复用基础
## Phase 3: 七维度价值打分
| # | 维度 | 分数 | 权重 | 加权分 | 理由 |
|---|------|------|------|--------|------|
| 1 | 用户价值 | 8/10 | 20% | 1.6 | 知识管理是高频痛点 |
| 2 | 需求清晰度 | 3/10 | 15% | 0.45 | 6/8 气味，需大幅补充 |
| 3 | 雷同度 | 6/10 | 10% | 0.6 | 部分基础设施可复用，核心搜索是新的 |
| 4 | 技术可行性 | 5/10 | 15% | 0.75 | 向量库是新依赖，需评估引入成本 |
| 5 | 战略对齐 | 7/10 | 15% | 1.05 | 符合 AI Agent 方向，但当前 codebase-snapshot 标记为"部分完成(UI占位)" |
| 6 | 时间敏感度 | 4/10 | 10% | 0.4 | 非紧急，无外部 deadline |
| 7 | 维护负担 | 4/10 | 15% | 0.6 | 向量索引、文档解析管线的长期维护成本高 |
| | **加权总分** | | | **5.45/10** | |
## Phase 4: 综合判定
**判定结果**: 需改进
**判定依据**:
- 气味检测: 6/8 有气味（≥3 自动降级）
- 功能雷同: 部分重叠
- 加权总分: 5.45/10
- 特殊规则触发: 气味 ≥3 自动降级
**下一步建议**:
1. 拆分为 4 个独立用户故事，逐个验证
2. 明确 MVP 范围（建议先做单文档上传+解析，搜索和问答作为 Phase 2）
3. 向量数据库选型需单独做技术调研
---
**改进清单**:
| # | 问题 | 改进方案 | 优先级 |
|---|------|----------|--------|
| 1 | 需求不原子——4 个功能混在一起 | 拆分为：上传、解析、搜索、问答 4 个故事 | P0 |
| 2 | 文档格式未定义 | 明确 MVP 支持 PDF + Markdown，后续扩展 | P0 |
| 3 | 语义搜索无验收标准 | 定义 Top-5 命中率 ≥ 80% | P1 |
| 4 | 向量库依赖未评估 | 先调研 MongoDB Atlas Search vs Qdrant | P1 |
| 5 | 问答范围不清 | 限定 MVP 为单文档上下文问答 | P1 |
输出质量规则
必须遵循
- 四阶段全覆盖：即使某阶段全部通过，也要输出完整表格，不能跳过
- 每个气味有修复建议：不能只说"有问题"不说"怎么改"
- 雷同排查基于事实：必须引用
codebase-snapshot.md 中的具体功能名或集合名
- 打分有理由：每个维度必须附一句话理由，不能只有数字
- 判定可解释：最终结果必须列出判定依据和触发的特殊规则
- 改进清单可执行：每条改进必须足够具体，能直接行动
禁止
- 禁止跳过气味检测：不能因为"需求看起来还行"就跳过 Phase 1
- 禁止虚假对标：雷同排查必须基于实际代码库，不能凭印象
- 禁止模糊判定："可能通过"不行，必须是「通过/需改进/驳回」之一
- 禁止忽略特殊规则：气味 ≥3 必须降级，用户价值 ≤3 必须降级
- 禁止过度乐观：宁可打低分让团队重视，也不要放过有问题的需求
与其他技能的协作关系
新需求提出
│
▼
"验证需求" → 【需求验证技能】(本技能)
│
├─ 通过 → "评估风险" → 【风险矩阵技能】(/risk)
│ │
│ └─ 设计方案 → "追踪链路" → 【路径追踪技能】(/trace)
│
├─ 需改进 → 修订需求 → 重新验证
│
└─ 驳回 → 归档原因 → 提出替代方案
完整质量保障链条：
需求阶段 设计阶段 实现阶段 验收阶段
│ │ │ │
需求验证 风险矩阵 路径追踪 交叉验证
/validate /risk /trace /verify
"靠谱吗" "有啥风险" "怎么跑的" "做对了吗"
│ │ │ │
└──────── 冒烟测试（贯穿各阶段）──────────┘ │
交接清单
/handoff
注意事项
- 不过度分析：如果需求只有 1-2 句且明显清晰（小改动），告知用户直接做即可
- 渐进式输出：先输出 Phase 1 结果，如果气味严重可提前终止并建议修订
- 与 /risk 互补：本技能验证"需求本身"，/risk 验证"技术方案"，不要混淆
- 尊重上下文：评分时充分参考
codebase-snapshot.md 中的架构模式和技术栈
- 可批量执行：可一次验证多个需求，输出对比表格帮助优先级排序
