name: analyze-transcript description: 分析会议记录以提取需求、决策和行动项。专为对话内容提取而设计。 argument-hint: <transcript-path> [–domain <domain-name>] [–speakers <speaker-roles>] allowed-tools: Read, Glob, Grep, Write, Skill

分析记录命令

从会议记录和对话内容中提取需求和决策。

用法

/requirements-elicitation:analyze-transcript ./meetings/kickoff-notes.md
/requirements-elicitation:analyze-transcript ./transcripts/stakeholder-call.txt --domain "checkout"
/requirements-elicitation:analyze-transcript ./notes/*.md --speakers "PM:ProductManager,TL:TechLead,UX:Designer"

参数

参数	必需	描述
transcript-path	是	记录文件路径或通配符模式
–domain	否	用于组织输出的域名
–speakers	否	说话者角色映射（格式：`缩写:角色`）

提取内容

需求

明确陈述的需求
讨论中隐含的需求
功能请求和建议

决策

商定的方法
技术选择
范围决策

行动项

做出的承诺
后续任务
分配

关注点

识别的风险
提出的问题
开放性问题

提取模式

决策标记

"我们决定..."
"结论是..."
"选择[选项]..."
"同意: ..."
"决策: ..."

行动项标记

"行动: [名称] 将..."
"待办: ..."
"[名称] 跟进..."
"我们需要..."
"下一步: ..."

需求讨论

"系统应该..."
"用户需要能够..."
"它必须处理..."
"需求: ..."
"功能请求: ..."

关注点标记

"我担心..."
"风险: ..."
"问题: ..."
"如果...？"
"问题: ..."

工作流程

步骤1：加载记录

使用Read工具读取记录文件。

步骤2：识别说话者

如果提供了–speakers，使用映射。否则，尝试从模式中识别说话者，如：

[名称]: 或 名称:
**名称**:
记录格式中的说话者标签

步骤3：提取内容

使用document-miner代理和记录特定提取模式。

提取：

需求（明确和隐含）
决策
行动项
关注点和风险

步骤4：属性和权重

对于每个提取：

记录说话者（如果可识别）
根据说话者角色应用权重
记录上下文

步骤5：保存和报告

保存到.requirements/{domain}/transcripts/ 报告发现摘要。

说话者权重

speaker_weights:
  product_owner: 高    # 业务需求
  technical_lead: 高   # 技术约束
  stakeholder: 高      # 领域需求
  developer: 中        # 实施洞察
  designer: 中         # UX需求
  unknown: 低          # 需要验证

示例

基本记录分析

/requirements-elicitation:analyze-transcript ./meetings/sprint-planning.md

输出：

分析: sprint-planning.md

识别的说话者:
- PM (ProductManager): 45条语句
- TL (TechLead): 32条语句
- DEV (Developer): 28条语句

提取结果:

需求 (8):
- REQ-TR-001: "用户应收到订单状态电子邮件通知" [PM, 高]
- REQ-TR-002: "API响应时间必须低于200ms" [TL, 高]
...

决策 (3):
- DEC-001: "使用PostgreSQL作为主数据库" [TL]
- DEC-002: "目标发布日期: Q2 2025" [PM]
...

行动项 (5):
- ACT-001: "TL 创建数据库模式文档"
- ACT-002: "PM 获取利益相关者签字"
...

关注点 (2):
- CONCERN-001: "第三方API可靠性" [TL]
- CONCERN-002: "新功能培训时间表" [PM]

保存到: .requirements/sprint-planning/transcripts/TR-sprint-planning.yaml

带说话者映射

/requirements-elicitation:analyze-transcript ./calls/client-call.txt \
  --speakers "JD:ClientCEO,SM:SalesManager,PM:ProductManager" \
  --domain "enterprise-deal"

输出：

分析: client-call.txt

应用说话者映射:
- JD → ClientCEO (权重: 高)
- SM → SalesManager (权重: 中)
- PM → ProductManager (权重: 高)

来自ClientCEO的需求 (5):
- REQ-TR-001: "必须与SAP集成" [JD, 高置信度]
- REQ-TR-002: "支持50,000并发用户" [JD, 高置信度]
...

来自ProductManager的需求 (3):
- REQ-TR-006: "需要仪表板自定义" [PM, 高置信度]
...

保存到: .requirements/enterprise-deal/transcripts/TR-client-call.yaml

多个记录

/requirements-elicitation:analyze-transcript ./meetings/*.md --domain "q1-planning"

输出：

找到4个匹配模式的记录

处理:
1. kickoff-meeting.md ........ 12需求, 4决策
2. technical-review.md ....... 8需求, 6决策
3. stakeholder-feedback.md ... 15需求, 2决策
4. sprint-planning.md ........ 5需求, 3决策

跨记录分析:
- 总需求: 40
- 检测到重复: 6 (合并为34)
- 冲突语句: 2 (标记为审查)

摘要保存到: .requirements/q1-planning/transcripts/summary.yaml

输出格式

保存的YAML结构

transcript_analysis:
  file: "sprint-planning.md"
  analyzed_date: "2025-12-25T14:30:00Z"
  domain: "{domain}"

speakers:
  - abbreviation: PM
    role: ProductManager
    statement_count: 45
    weight: 高
  - abbreviation: TL
    role: TechLead
    statement_count: 32
    weight: 高

requirements:
  - id: REQ-TR-001
    text: "系统应在订单状态更改时发送电子邮件通知"
    speaker: PM
    speaker_role: ProductManager
    context: "关于客户通信的讨论"
    original_quote: "当订单状态更改时，我们需要电子邮件通知"
    confidence: 高
    type: 功能

decisions:
  - id: DEC-001
    text: "使用PostgreSQL作为主数据库"
    speaker: TL
    context: "数据库技术选择"
    rationale: "团队专业知识和可扩展性需求"

action_items:
  - id: ACT-001
    text: "创建数据库模式文档"
    assignee: TL
    due_date: null  # 如果未指定
    context: "数据库决策的后续"

concerns:
  - id: CONCERN-001
    text: "高峰时段第三方API可靠性"
    raised_by: TL
    context: "集成讨论"
    severity: 中

conflicts:
  - items: [REQ-TR-003, REQ-TR-015]
    description: "冲突的性能目标"
    resolution_needed: true

集成

后续命令

# 分析后检查缺口
/requirements-elicitation:gaps

# 就提出的关注点采访利益相关者
/requirements-elicitation:interview "技术负责人" --context "API可靠性关注点"

# 与其他源合并
/requirements-elicitation:discover "{domain}" --sources transcripts,documents

最佳实践

记录准备

为获得最佳结果，记录应：

清晰识别说话者
使用一致的格式
包括时间戳（可选但有用）
用标题分隔主题

审查建议

分析后：

审查所有标记的冲突
验证低置信度提取
跟进开放关注点
如果尚未完成，分配行动项