technical-requirements-interview

技术需求访谈

此技能将通过结构化访谈，帮助你从业务需求中推导出技术需求。

前提条件

• 已完成 {base_directory}/requirements/business-requirements.yaml 文件
• 清楚了解问题领域

访谈流程

规则

1. 一次只问一个问题——切勿在同一轮中提出多个问题
2. 先了解业务背景——在提出技术问题之前，先加载并理解业务需求
3. 提供选项——每个问题都包含 2-5 个推荐选项，以及自由填写的选项
4. 跟踪进度——所有问答对都会立即追加到 {base_directory}/artifacts/technical-interview.jsonl
5. 支持恢复访谈——如果 JSONL 文件已存在，则从上一个问题继续
6. 结构化输出——访谈完成后，在 {base_directory}/requirements/ 中生成 technical-requirements.yaml

访谈类别

访谈按以下顺序涵盖这些领域：

1. 架构与模式

   • 整体架构风格
   • 应用结构
   • 组件组织

2. 技术栈

   • 编程语言
   • 框架和库
   • 包管理

3. 数据模型与存储

   • 数据持久化策略
   • 数据库选择
   • 架构设计方法

4. API 设计

   • API 风格（REST、GraphQL、RPC）
   • API 框架
   • 版本控制策略

5. 安全与身份验证

   • 身份验证方法
   • 授权方式
   • 密钥管理

6. 测试策略

   • 测试方法（TDD、BDD 等）
   • 测试类型（单元、集成、端到端）
   • 测试框架

7. 开发与工具

   • 开发工作流
   • 代码质量工具
   • CI/CD 方案

8. 部署与分发

   • 部署目标
   • 打包策略
   • 发布流程

问题格式

每个问题遵循以下结构：

## [Category Name]

**Question:** [Clear, specific question]

**Options:**
1. [Option 1] (Recommended) - [Brief description and rationale]
2. [Option 2] - [Brief description]
3. [Option 3] - [Brief description]
4. Type your own answer

问题示例

架构

## Architecture & Patterns

**Question:** What architecture pattern best fits this project?

**Options:**
1. Monolithic application (Recommended) - Single deployable unit, simpler to develop and deploy initially
2. Microservices - Multiple independent services, better scaling but higher complexity
3. Serverless functions - Event-driven, scales automatically, but vendor lock-in
4. Plugin-based - Core engine with extensible plugins for flexibility
5. Type your own answer

技术栈

## Technology Stack

**Question:** Which programming language should be used?

**Options:**
1. TypeScript (Recommended) - Type-safe JavaScript, excellent tooling, large ecosystem
2. Python - Readable, extensive libraries, good for data processing and scripting
3. Go - Fast compilation, excellent concurrency, simple deployment
4. Rust - Memory safety without garbage collection, high performance
5. Type your own answer

数据存储

## Data Model & Storage

**Question:** What data persistence strategy is appropriate?

**Options:**
1. File-based storage (Recommended) - Simple, portable, no database dependency
2. SQLite - Embedded relational database, good for local tools
3. PostgreSQL - Full-featured relational database, better for complex queries
4. NoSQL (MongoDB, etc.) - Flexible schema, good for document-based data
5. In-memory only - Fast but no persistence, suitable for ephemeral data
6. Type your own answer

JSONL 格式

在 {base_directory}/artifacts/technical-interview.jsonl 中跟踪所有问题和答案。

请参阅 references/interview-jsonl-spec.md，了解完整的 JSONL 架构、字段定义和示例。

输出格式

访谈完成后，生成 {base_directory}/requirements/technical-requirements.yaml。

如果目录不存在，则创建目录：

mkdir -p {base_directory}/requirements
mkdir -p {base_directory}/artifacts

输出文档包含以下顶层部分：project、version、generated、business_requirements_ref、architecture、technology_stack、project_structure、data_model、api、security、testing、development、ci_cd、deployment、monitoring、performance、scalability、constraints、trade_offs 和 open_questions。

请参阅 references/output-spec.md，了解完整的文档规范，包括所有字段、类型和验证规则。

请参阅 references/example.yaml，查看完整示例。

用法

要开始新的技术访谈：

/technical-requirements-interview [base-directory]

如果未提供目录，则在当前目录中查找 requirements/business-requirements.yaml 并自动检测。

如果未找到，则提示用户：“你的需求文档位于何处？”

在继续之前，等待用户提供路径。将其存储为 base_directory。

此技能将自动执行以下操作：

1. 将 {base_directory}/requirements/business-requirements.yaml 中的业务需求加载为上下文
2. 检查是否存在 {base_directory}/artifacts/technical-interview.jsonl
3. 如果找到，则从上一个问题继续
4. 提出有针对性的技术问题
5. 完成后，在 {base_directory}/requirements/ 中生成 technical-requirements.yaml
6. 将访谈记录保存到 {base_directory}/artifacts/technical-interview.jsonl

决策跟踪

每项技术决策都应包含：

1. 决策 - 决定了什么
2. 理由 - 为什么选择这种方案
3. 考虑过的替代方案 - 还评估了哪些方案
4. 权衡 - 得到了什么／失去了什么
5. 可逆性 - 之后更改的难度

最佳实践

1. 符合业务需求 - 每项技术选择都应满足业务需求
2. 考虑约束 - 遵守时间安排、预算和技能方面的约束
3. 从简单入手 - 尽可能选择简单的方案，而非复杂方案
4. 为变化做好准备 - 尽可能做出可逆的决策
5. 记录决策理由 - 未来的你会感谢现在的你

审查与差距分析

生成 technical-requirements.yaml 后，自动执行差距分析：

一致性检查

业务一致性：

• 架构支持所有功能需求
• 技术选型符合业务约束
• 时间安排符合技术范围的实际情况
• 工具／服务选型遵守预算约束

完整性检查：

架构：

• 明确定义了架构模式
• 记录了各组件及其职责
• 数据流清晰
• 已识别集成点

技术栈：

• 指定了语言和运行时
• 列出了框架和库
• 在关键情况下指定了版本
• 考虑并记录了替代方案

数据模型：

• 定义了存储策略
• 记录了架构方案
• 若使用数据库，则定义了迁移策略
• 指定了数据验证方案

API：

• 选择了 API 风格（REST/GraphQL/RPC）
• 选择了框架
• 定义了版本管理策略
• 指定了文档编写方案

安全：

• 定义了身份验证方法
• 指定了授权模型
• 制定了密钥管理方案
• 制定了输入／输出验证策略

测试：

• 定义了测试策略（TDD/BDD 等）
• 指定了测试类型（单元／集成／端到端）
• 选定了框架
• 设定了覆盖率目标

部署：

• 确定了部署目标
• 选择了打包格式
• 定义了 CI/CD 方案
• 记录了发布流程

一致性检查

• 技术决策之间没有矛盾
• 各项技术选择彼此兼容
• 使用所选技术栈可以实现性能目标
• 安全方案符合数据敏感度

权衡分析

审查已记录的权衡：

• 每项权衡都有明确的理由
• 已认真考虑替代方案
• 已理解相关后果且可以接受
• 已评估可逆性

差距识别

需要检查的常见差距：

• 缺少错误处理策略
• 未记录边缘情况
• 未解决可扩展性问题
• 缺少监控／可观测性方案
• 数据迁移路径不明确
• 缺少安全威胁模型
• 未记录性能预算
• 缺少灾难恢复方案
• 依赖项版本管理策略不明确
• 缺少代码质量工具

未决问题审查

检查未决问题是否：

• 表述清晰
• 已列出可选方案
• 已了解其影响
• 已定义决策时间表

审查结果

生成差距分析报告，包含：

gap_analysis:
  business_alignment_score: [1-10]
  completeness_score: [1-10]
  consistency_score: [1-10]

  gaps_found:
    - category: [category]
      issue: [description]
      severity: [high/medium/low]
      recommendation: [how to address]
      business_impact: [what business requirement this affects]

  strong_areas:
    - [what's well-defined]

  trade_offs_review:
    - decision: [decision]
      assessment: [well-reasoned/needs-review/concerning]
      notes: [additional context]

  open_questions_assessment:
    - question: [question]
      blocking: [yes/no]
      recommendation: [resolve now/later/accept uncertainty]

  suggestions:
    - [improvement suggestions]

  ready_for_implementation: [yes/no/with-modifications]

如果发现关键差距（严重程度为高，或存在阻碍进展的未决问题），请询问：

“我发现技术需求中存在一些可能影响实施的差距。你希望：

1. 现在解决这些问题（我会提出后续问题）
2. 继续制定实施计划（在开发期间解决）
3. 审查这些差距并作出决定”

后续步骤

完成技术需求访谈和差距分析后：

1. 审查差距分析报告
2. 解决任何关键差距或阻碍进展的问题
3. 确认技术选型切实可行
4. 使用 /implementation-planner 生成实施计划

示例

完整的示例输出请参见 references/example.yaml。