yanxulong/AIEC_Skills
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

需求文档skill回溯专家博弈之前

Browse Source
This commit is contained in:
闫旭隆
2025-12-11 14:19:36 +08:00
parent 5f329d7b4c
commit f4314c3ede
117 changed files with 28969 additions and 3325 deletions
Download Patch File Download Diff File Expand all files Collapse all files

393
.claude/skills/requirement-generator-v1/assets/agent_dev.md Normal file
View File

@ -0,0 +1,393 @@
---
type: agent_dev
keywords: [agent, skill, 自动化, 智能助手, 助手, langchain, langgraph, 机器人, bot, 对话, workflow, 工作流, multi-agent]
priority: high
---
# Agent 开发项目配置
本配置用于端到端的 Agent 开发项目，包括但不限于：
- Claude Code Skill/Agent
- LangChain Agent
- LangGraph Workflow
- Multi-Agent 系统
- 其他 AI Agent 框架
## 模板路径
templates/agent_dev_template.md
## 启动问题示例
以下问题仅作为参考，根据用户初始描述的详细程度和信息完整度动态选择和调整。
### 示例问题：主要任务
```yaml
question: "这个智能助手主要帮助用户完成什么任务？（可多选，或在'其他'中详细描述；需要帮助请输入'需要帮助'）"
options:
- label: "信息查询和检索"
description: "帮助用户查找、搜索、整理信息"
- label: "数据处理和分析"
description: "对数据进行清洗、转换、分析"
- label: "自动化任务执行"
description: "自动完成重复性工作或流程"
- label: "辅助决策支持"
description: "提供建议、分析、推荐"
multiSelect: true
```
**使用时机**：用户初始描述未明确说明具体任务时使用。如已明确，跳过此问题。
---
### 示例问题：预期价值
```yaml
question: "预期带来什么价值？（可多选，或在'其他'中详细描述；需要帮助请输入'需要帮助'）"
options:
- label: "提高效率"
description: "节省时间，加快处理速度"
- label: "降低成本"
description: "减少人力投入，降低运营成本"
- label: "提升质量"
description: "提高准确性，减少错误"
- label: "增强用户体验"
description: "简化操作，提升满意度"
multiSelect: true
```
**使用时机**：用户初始描述未说明价值或目标时使用。可与其他问题合并。
---
### 示例问题：使用场景
```yaml
question: "用户在什么情况下会需要使用这个助手？（可多选，或在'其他'中描述具体场景；需要帮助请输入'需要帮助'）"
options:
- label: "定期自动执行"
description: "按时间表自动运行，如每天早上、每周等"
- label: "用户主动调用"
description: "用户有需求时手动触发"
- label: "事件触发"
description: "特定事件发生时自动执行，如文件变化、消息到达等"
multiSelect: true
```
**使用时机**：了解基本任务后询问。根据回答深入询问具体触发条件、频率等细节。
---
### 示例问题：架构复杂度
```yaml
question: "任务是否需要多个专门的助手配合完成？（或在'其他'中描述；需要帮助请输入'需要帮助'）"
options:
- label: "不需要，单个助手就能完成"
description: "任务相对简单，流程单一"
- label: "需要，任务复杂，需要多个助手协作"
description: "需要将任务拆分给不同的专门助手"
multiSelect: false
```
**使用时机**：用户描述涉及多步骤、复杂流程时询问。如选择Multi-Agent，后续深入询问各Agent职能和协作方式。
---
## 访谈启动策略
### 分析用户初始描述
访谈前先分析用户初始输入的信息完整度：
**信息完整度检查**
识别用户初始描述中已包含的信息：
- ✓ 明确任务/功能 → 跳过"主要任务"问题
- ✓ 说明使用场景 → 跳过或简化"使用场景"问题
- ✓ 提到价值/目标 → 跳过"预期价值"问题
- ✓ 描述复杂流程/多步骤 → 主动询问Multi-Agent需求
- ✓ 提及外部系统 → 深入询问数据集成细节
- ✓ 涉及性能/安全 → 追问具体指标
**动态起始点选择**
| 用户描述情况 | 起始策略 | 示例 |
|------------|---------|------|
| 详细完整 | 直接补充细节 | "如何定义'重要联系人'？" |
| 基本清晰 | 从1-2个示例问题开始 | "使用场景"+"预期价值" |
| 模糊简略 | 依次使用示例问题 | "主要任务"→"使用场景"→... |
| 技术导向 | 引导到业务需求 | "这个功能主要帮用户解决什么问题？" |
### 启动原则
1. **先分析，后提问**
- 仔细阅读用户初始描述
- 识别已有信息和缺失信息
- 避免询问已明确的内容
2. **避免机械执行**
- 示例问题不是固定流程
- 根据实际情况选择和调整
- 灵活组合或跳过问题
3. **动态调整深度**
- 用户回答内容丰富 → 快速推进
- 用户回答简短模糊 → 追问细节
- 用户不确定 → 提供更多选项或示例
4. **保持对话自然**
- 基于上一轮回答提出下一个问题
- 合并相关信息的询问
- 避免突兀的话题跳转
## 访谈策略指南
### 访谈目标
收集完整的业务需求信息，用于生成结构化需求文档。
### 访谈方式
- 使用 AskUserQuestion 工具进行所有提问
- 每个问题独立、可单独回答
- 提供2-4个常见选项
- 在question中明确提示"可在'其他'中详细描述"或类似说明
- 系统自动添加"其他"选项
- 使用业务语言，避免技术术语
### 信息收集范围
**基础信息**：
- 项目背景和目标
- 核心功能列表
- 目标用户和使用场景
- 使用入口和触发方式
**架构信息**（如需Multi-Agent）：
- Agent角色划分和职能
- Agent能力边界
- Agent间协作关系和数据传递
**功能细节**：
- 输入输出定义
- 需要访问的外部数据和系统
- 完整的交互流程
- 异常和分支处理
**交付规划**：
- MVP核心功能
- 后续优化和高级功能
- 分阶段目标
**非功能需求**：
- 用户明确的技术约束
- 性能要求（用户数、响应时间等业务指标）
- 安全和隐私要求（业务层面）
- 其他特殊需求
**验收标准**：
- 功能验收条件
- 非功能验收条件
### 动态访谈原则
1. **基于回答识别缺口**
- 分析每轮回答获得的信息
- 识别仍缺失的领域
- 确定后续提问方向
2. **适应项目复杂度**
- 简单项目：快速收集核心信息即可
- 复杂项目：深入询问架构、流程、分阶段等
- Multi-Agent项目：详细了解各Agent职能和协作
3. **聚焦关键特征**
- 如涉及高性能：追问具体性能指标
- 如涉及高安全：追问敏感数据处理
- 如需集成外部系统：追问数据流转细节
- 如涉及复杂流程：询问异常和分支处理
4. **避免重复和冗余**
- 不重复提问已获取的信息
- 合并相关信息的提问
- 综合考虑用户回答的详细程度
5. **灵活调整问题深度**
- 用户回答简短模糊：追问细节
- 用户回答内容丰富：快速推进其他信息
- 用户不确定：提供更具体的选项或示例
### 完整性检查
每轮访谈后评估已收集信息的完整性，当以下核心信息都已获取时，可结束访谈：
**必需信息**：
- 项目背景和目标
- 核心功能列表（至少3个）
- 典型使用场景（至少1个）
- 基本输入输出
- 验收标准（至少3条）
- **分阶段交付计划**（MVP功能、降级功能、难度依赖）
**可选但建议收集**：
- Agent架构细节（如需Multi-Agent）
- 外部系统集成需求
- 完整交互流程
- 性能和安全要求
### 问题生成规范
**语言风格**：
- 使用业务语言
- 问题清晰具体
- 避免技术术语
**question文本**：
- 在问题中明确提示用户可以使用"其他"选项
- 示例："（可多选，或在'其他'中详细描述）"
- 示例："（或在'其他'中说明您的具体情况）"
**选项设计**：
- 尽可能从不同角度覆盖，边界明晰简洁，10个以内
- 选项描述简洁明确
- 覆盖主要情况，不穷尽所有可能
**选项设计规范**：
#### 互斥性原则
**单选问题**（multiSelect: false）：
- ✅ 选项应完全互斥，无重叠
- ✅ 边界清晰，用户能明确判断属于哪一个
- ❌ 避免数量范围重叠（如"1-10人"和"5-20人"）
- ❌ 避免概念包含关系（如"Web界面"和"移动端界面"同时出现在"访问方式"问题中）
**多选问题**（multiSelect: true）：
- ✅ 选项可从不同角度切分，允许合理组合
- ✅ 每个选项应代表独立的需求维度
- ❌ 避免选项之间有逻辑依赖（如"数据收集"和"基于收集的数据分析"）
#### 维度统一原则
**同一问题的所有选项应属于同一分类维度**
❌ **错误示例**（维度混乱）：
```yaml
question: "用户如何使用这个工具?"
options:
- 输入问题主动调用 # 维度：触发方式
- 命令行/编程接口 # 维度：交互界面
- Web界面 # 维度：交互界面
multiSelect: false
```
问题：第1个选项是"触发方式"，第2、3个是"交互界面"，维度不统一
✅ **正确示例**（维度统一）：
```yaml
question: "用户通过什么方式访问工具?"
options:
- 命令行接口
- Web界面
- 桌面应用
multiSelect: false
```
或者拆分为两个问题：
```yaml
question: "工具的触发方式?"
options:
- 用户主动输入问题调用
- 定时自动执行
- 事件触发（如文献更新）
multiSelect: true
---
question: "工具的交互界面?"
options:
- 命令行/API接口
- Web浏览器界面
- 桌面客户端
multiSelect: false
```
#### 边界清晰原则
**数量范围选项**：
```yaml
# ❌ 边界重叠
- 1-10人
- 5-20人
# ✅ 边界清晰
- 个人使用（1-5人）
- 小团队（6-50人）
- 中大型（50人以上）
```
**概念分类选项**：
```yaml
# ❌ 包含关系
- 医疗数据
- 患者健康记录 # 属于医疗数据的子集
# ✅ 平级分类
- 患者健康记录
- 医学影像数据
- 临床试验数据
```
#### 完备性检查
- 2-4个选项应覆盖**80%的常见场景**
- 如果某个场景>10%用户可能选择，应作为预设选项
- 剩余<20%的长尾场景通过"其他"覆盖
- 当不确定时，优先设计偏通用的选项+依赖"其他"
**multiSelect设置**：
- 核心功能、使用场景、数据访问、触发方式、预期价值 → true
- 规模量级、架构复杂度、二选一决策 → false
**上下文关联**：
- 基于之前的回答调整问题
- 识别项目特点后深入相关领域
- 根据项目复杂度调整问题数量
### 访谈示例场景
**场景1：详细完整的描述**
用户输入：
```
我想做一个邮件助手，每天早上7点自动扫描我的工作邮箱，
提取来自重要联系人的邮件，总结关键内容，生成一份摘要报告
发送到企业微信。主要是为了节省每天30分钟的邮件筛选时间。
```
应对策略：
- 已包含：任务（邮件整理）、场景（每天早上7点）、价值（节省30分钟）、触发方式（定时）
- 缺失：重要联系人定义、摘要格式、异常处理、输入输出细节
- 起始问题："如何判断'重要联系人'？是基于发件人列表，还是其他规则？"
**场景2：基本清晰的描述**
用户输入：
```
我想开发一个智能客服助手，帮助回答用户常见问题。
```
应对策略：
- 已包含：任务类型（辅助决策/信息查询）
- 缺失：使用场景、触发方式、价值、数据来源
- 起始问题：从示例问题"使用场景"开始，然后询问知识来源
**场景3：模糊简略的描述**
用户输入：
```
想做一个自动化工具。
```
应对策略：
- 信息极少
- 从示例问题"主要任务"开始，依次引导

291
.claude/skills/requirement-generator-v1/assets/feature_update.md Normal file
View File

@ -0,0 +1,291 @@
---
type: feature_update
keywords: [优化, 改进, 迭代, 更新, bug, 修复, 重构, 升级, 增强, enhance, improve, refactor]
priority: high
---
# 功能优化/更新项目配置
本配置用于已有项目的功能优化、更新迭代、bug 修复等场景。
## 模板路径
templates/feature_update_template.md
## 核心问题配置
### 问题 1：当前问题识别
```yaml
question: "请描述当前功能存在什么问题或不足？"
type: "text"
prompt: |
比如：
- 功能不完善，缺少某些能力
- 性能不好，速度慢
- 用户体验差，操作复杂
- 经常出错
- 维护困难
```
---
### 问题 2：优化目标
```yaml
question: "优化后，您希望达到什么效果？"
type: "text"
prompt: |
请尽可能具体地描述，比如：
- "查询速度从 3 秒缩短到 1 秒以内"
- "增加批量导入功能"
- "优化操作流程，减少点击次数"
- "降低出错率"
```
---
### 问题 3：影响范围
```yaml
question: "这次优化会影响哪些功能或用户？（或在'其他'中描述；需要帮助请输入'需要帮助'）"
options:
- label: "只影响这一个功能"
description: "局部优化，不影响其他功能"
- label: "会影响相关的几个功能"
description: "需要同步调整其他功能"
- label: "会影响整个系统"
description: "架构或核心功能的调整"
```
---
### 问题 4：兼容性要求
```yaml
question: "优化后，原有的功能和数据是否需要保持兼容？（或在'其他'中描述；需要帮助请输入'需要帮助'）"
options:
- label: "必须完全兼容，不能影响现有用户"
description: "向后兼容，不需要数据迁移"
- label: "可以有小的调整，但要保证数据不丢失"
description: "需要数据迁移，但应该简单"
- label: "可以重新设计，旧数据可以手动迁移"
description: "不保证兼容，手动或复杂迁移"
```
---
### 问题 5：性能指标（如涉及性能优化）
```yaml
question: "如果涉及性能优化，请描述当前速度和期望速度。"
type: "text"
prompt: |
比如：
- "现在加载需要 10 秒，希望 2 秒以内"
- "现在只能处理 100 条数据，希望能处理 10000 条"
- "高峰期经常卡顿，希望流畅运行"
```
---
### 问题 6：测试与验收
```yaml
question: "如何验证优化是成功的？"
type: "text"
prompt: |
请列出具体的验收标准，比如：
- "查询 1000 条数据在 1 秒内返回"
- "批量导入 10000 条数据无报错"
- "用户操作减少到 3 步"
```
---
## 通用映射规则
```yaml
# 问题类型 → 优化重点
issue_type_mapping:
"速度慢|性能差|加载时间长":
focus: "性能优化"
metrics: "响应时间、吞吐量"
approaches: ["缓存", "索引优化", "异步处理", "数据库优化"]
"功能不完善|缺少能力|用户需求":
focus: "功能增强"
metrics: "功能完整度、用户满意度"
approaches: ["需求分析", "功能设计", "API 扩展"]
"操作复杂|体验差|难用":
focus: "用户体验优化"
metrics: "操作步骤、用户反馈"
approaches: ["交互优化", "流程简化", "UI 改进"]
"经常出错|不稳定|bug":
focus: "稳定性提升"
metrics: "错误率、可用性"
approaches: ["异常处理", "边界检查", "测试覆盖"]
"代码混乱|难维护":
focus: "代码重构"
metrics: "代码质量、可维护性"
approaches: ["架构优化", "代码清理", "文档完善"]
# 影响范围 → 测试策略
scope_mapping:
"局部优化":
testing: "单元测试 + 功能测试"
risk: "low"
rollout: "直接发布"
"中等范围":
testing: "集成测试 + 回归测试"
risk: "medium"
rollout: "分阶段发布"
"大范围":
testing: "全面测试 + 压力测试"
risk: "high"
rollout: "灰度发布 + 回滚预案"
# 兼容性要求 → 实现策略
compatibility_mapping:
"完全兼容":
strategy: "增量优化"
migration: "不需要"
risk: "low"
"需要迁移":
strategy: "版本升级 + 迁移脚本"
migration: "自动迁移"
risk: "medium"
"不保证兼容":
strategy: "重新设计"
migration: "手动迁移或弃用旧数据"
risk: "high"
```
## 文档结构建议
```markdown
# {功能名称}优化 - 需求文档
## 1. 现状分析
- 当前问题描述
- 问题影响和严重程度
- 问题根因（如已知）
## 2. 优化目标
- 功能目标
- 性能目标
- 质量目标
- 优先级
## 3. 优化方案概述
- 主要优化方向
- 技术方案（如已明确）
- 预期效果
## 4. 功能变更
- 新增功能
- 修改功能
- 废弃功能
## 5. 技术变更
- 架构调整
- 数据库变更
- API 变更
- 依赖更新
## 6. 兼容性与迁移
- 向后兼容性
- 数据迁移方案
- 回滚策略
## 7. 影响范围
- 受影响的模块
- 受影响的用户
- 风险评估
## 8. 测试策略
- 测试范围
- 测试用例
- 性能测试（如需要）
## 9. 发布计划
- 发布方式（灰度/全量）
- 发布步骤
- 监控指标
## 10. 验收标准
- 功能验收
- 性能验收
- 稳定性验收
```
## 特殊场景处理
### 性能优化项目
额外关注：
- 性能基线测试
- 瓶颈分析
- 优化前后对比
- 性能监控方案
### 架构重构项目
额外关注：
- 架构演进路径
- 服务拆分/合并
- 技术债务清理
- 团队能力评估
### 紧急 Bug 修复
额外关注：
- 问题复现步骤
- 临时解决方案
- 根因分析
- 防止复发措施
## 选项设计规范
### 互斥性原则
**单选问题**（multiSelect: false）：
- ✅ 选项应完全互斥，无重叠
- ✅ 边界清晰，用户能明确判断属于哪一个
- ❌ 避免数量范围重叠（如"1-10人"和"5-20人"）
- ❌ 避免概念包含关系
**多选问题**（multiSelect: true）：
- ✅ 选项可从不同角度切分，允许合理组合
- ✅ 每个选项应代表独立的需求维度
- ❌ 避免选项之间有逻辑依赖
### 维度统一原则
同一问题的所有选项应属于同一分类维度。
❌ **错误示例**（维度混乱）：
```yaml
question: "用户如何使用这个工具?"
options:
- 输入问题主动调用 # 维度：触发方式
- 命令行/编程接口 # 维度：交互界面
- Web界面 # 维度：交互界面
multiSelect: false
```
✅ **正确做法**：拆分为两个问题，或统一到同一维度
### 边界清晰原则
**数量范围**：避免重叠，如"个人使用（1-5人）"、"小团队（6-50人）"
**概念分类**：确保平级，避免包含关系
### 完备性检查
- 2-4个选项应覆盖**80%的常见场景**
- 长尾场景通过"其他"覆盖
- 当不确定时，优先设计偏通用的选项+依赖"其他"

325
.claude/skills/requirement-generator-v1/assets/testing.md Normal file
View File

@ -0,0 +1,325 @@
---
type: testing
keywords: [测试, 验证, 检验, test, 质量保证, qa, 单元测试, 集成测试, 性能测试, 自动化测试]
priority: medium
---
# 测试项目配置
本配置用于各类测试项目，包括功能测试、性能测试、安全测试等。
## 模板路径
templates/testing_template.md
## 核心问题配置
### 问题 1：测试对象
```yaml
question: "需要测试哪个功能或系统？"
type: "text"
prompt: "请描述测试对象，包括功能名称、版本等"
```
---
### 问题 2：测试类型
```yaml
question: "主要测试什么方面？（可多选，或在'其他'中详细描述；需要帮助请输入'需要帮助'）"
options:
- label: "功能是否正常工作"
description: "验证功能符合预期"
- label: "系统性能和速度"
description: "检查响应时间、承载能力"
- label: "安全性和数据保护"
description: "检查是否有安全漏洞"
- label: "多个功能协同工作"
description: "验证各模块集成后的表现"
multiSelect: true
```
---
### 问题 3：测试范围
```yaml
question: "需要测试哪些具体场景？"
type: "text"
prompt: |
请列出关键的测试场景，比如：
- 用户登录
- 创建订单
- 查询历史记录
- 边界情况（极端输入）
- 异常情况（网络中断、数据错误等）
```
---
### 问题 4：测试数据
```yaml
question: "测试时需要使用什么数据？（或在'其他'中描述；需要帮助请输入'需要帮助'）"
options:
- label: "使用真实数据"
description: "从生产环境或实际业务获取"
- label: "使用模拟数据"
description: "自己构造测试数据"
- label: "两者都需要"
description: "生产数据 + 模拟数据"
```
---
### 问题 5：测试方式
```yaml
question: "测试是手动进行还是自动化？（或在'其他'中描述；需要帮助请输入'需要帮助'）"
options:
- label: "手动测试就够了"
description: "人工操作和检查"
- label: "希望自动化执行"
description: "写脚本自动运行测试"
- label: "部分自动化，部分手动"
description: "混合模式"
```
---
### 问题 6：性能指标（如涉及性能测试）
```yaml
question: "如果测试性能，什么样的表现算合格？"
type: "text"
prompt: |
比如：
- "页面加载时间不超过 2 秒"
- "支持 100 人同时使用不卡顿"
- "处理 10000 条数据在 1 分钟内完成"
```
---
### 问题 7：验收标准
```yaml
question: "怎样才算测试通过？"
type: "text"
prompt: |
请列出具体的通过标准，比如：
- "所有核心功能无报错"
- "性能指标达标"
- "安全扫描无高危漏洞"
- "覆盖率达到 80%"
```
---
### 问题 8：测试环境
```yaml
question: "在什么环境下进行测试？（或在'其他'中描述；需要帮助请输入'需要帮助'）"
options:
- label: "开发环境（自己电脑）"
description: "本地开发环境"
- label: "专门的测试环境"
description: "独立测试环境"
- label: "接近真实的生产环境"
description: "预生产环境"
```
---
## 通用映射规则
```yaml
# 测试类型 → 测试策略
test_type_mapping:
"功能测试":
approach: "测试用例设计"
tools: ["手动测试", "Selenium", "Cypress", "Playwright"]
metrics: ["功能覆盖率", "缺陷密度"]
"性能测试":
approach: "压力测试 + 监控"
tools: ["JMeter", "Locust", "k6"]
metrics: ["响应时间", "吞吐量", "资源占用"]
"安全测试":
approach: "漏洞扫描 + 渗透测试"
tools: ["OWASP ZAP", "Burp Suite", "SonarQube"]
metrics: ["漏洞数量", "安全评级"]
"集成测试":
approach: "接口测试 + 数据验证"
tools: ["Postman", "pytest", "Jest"]
metrics: ["接口覆盖率", "数据一致性"]
# 自动化程度 → 实现方式
automation_mapping:
"手动测试":
tools: "测试用例文档"
efficiency: "low"
cost: "人力成本高"
"自动化测试":
tools: "测试框架 + CI/CD"
efficiency: "high"
cost: "初期投入高，长期收益大"
"混合模式":
tools: "自动化框架 + 手动补充"
efficiency: "medium"
best_for: "核心流程自动化，边界场景手动"
# 测试环境 → 准备工作
environment_mapping:
"本地开发环境":
setup: "最简单"
reality: "与生产差异大"
suitable_for: "单元测试、快速验证"
"独立测试环境":
setup: "中等复杂度"
reality: "接近生产"
suitable_for: "集成测试、功能测试"
"预生产环境":
setup: "复杂"
reality: "几乎等同生产"
suitable_for: "性能测试、上线前验证"
```
## 文档结构建议
```markdown
# {功能/系统名称}测试 - 需求文档
## 1. 测试概述
- 测试对象
- 测试背景
- 测试目标
## 2. 测试类型与范围
- 测试类型（功能/性能/安全/集成等）
- 测试范围（包含和排除的部分）
- 测试深度
## 3. 测试场景
- 正常场景
- 异常场景
- 边界场景
- 用户故事/测试用例
## 4. 测试数据
- 数据来源
- 数据量级
- 数据准备方式
- 隐私保护要求
## 5. 测试环境
- 环境配置
- 依赖服务
- 测试工具
## 6. 测试方式
- 自动化策略
- 测试框架和工具
- CI/CD 集成
## 7. 性能指标（如适用）
- 响应时间要求
- 吞吐量要求
- 并发要求
- 资源限制
## 8. 验收标准
- 通过标准
- 覆盖率要求
- 缺陷标准
- 性能基线
## 9. 测试计划
- 测试阶段
- 时间安排
- 人员分工
## 10. 交付物
- 测试报告
- 测试用例
- 自动化脚本
- 缺陷列表
```
## 特殊场景处理
### 性能测试项目
额外关注：
- 性能基线建立
- 压力测试策略（阶梯式/持续/峰值）
- 瓶颈分析工具
- 监控和报警
### 安全测试项目
额外关注：
- OWASP Top 10
- 常见漏洞类型
- 合规要求（等保、PCI-DSS 等）
- 渗透测试授权
### 自动化测试项目
额外关注：
- 测试框架选择
- 测试代码架构
- CI/CD 集成
- 维护成本
### 兼容性测试项目
额外关注：
- 浏览器/设备矩阵
- 操作系统版本
- 第三方依赖版本
- 向后兼容性
## 选项设计规范
### 互斥性原则
**单选问题**（multiSelect: false）：
- ✅ 选项应完全互斥，无重叠
- ✅ 边界清晰，用户能明确判断属于哪一个
- ❌ 避免数量范围重叠（如"1-10人"和"5-20人"）
- ❌ 避免概念包含关系
**多选问题**（multiSelect: true）：
- ✅ 选项可从不同角度切分，允许合理组合
- ✅ 每个选项应代表独立的需求维度
- ❌ 避免选项之间有逻辑依赖
### 维度统一原则
同一问题的所有选项应属于同一分类维度。
❌ **错误示例**（维度混乱）：
```yaml
question: "用户如何使用这个工具?"
options:
- 输入问题主动调用 # 维度：触发方式
- 命令行/编程接口 # 维度：交互界面
- Web界面 # 维度：交互界面
multiSelect: false
```
✅ **正确做法**：拆分为两个问题，或统一到同一维度
### 边界清晰原则
**数量范围**：避免重叠，如"个人使用（1-5人）"、"小团队（6-50人）"
**概念分类**：确保平级，避免包含关系
### 完备性检查
- 2-4个选项应覆盖**80%的常见场景**
- 长尾场景通过"其他"覆盖
- 当不确定时，优先设计偏通用的选项+依赖"其他"