# Go Backend Requirement Analysis

> Go 后端需求分析：功能边界、验收标准、领域模型、API 契约、数据一致性规则、非功能需求、交付风险。在技术设计或编码前使用。

- Skill: `gmh5225/go-backend-requirement-analysis` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add gmh5225/go-backend-requirement-analysis`
- Raw SKILL.md: https://api.skillmd.com/api/skills/gmh5225/go-backend-requirement-analysis/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Integrations & APIs
- Author: gmh5225 (https://skillmd.com/u/gmh5225)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/gmh5225/go-backend-requirement-analysis

---


# Go 后端需求分析

在技术设计或编码前使用，适用于涉及后端功能、API、异步任务、存储变更或服务集成的需求。

## 适用时机

- 用户说"分析一下这个需求" / "帮我梳理需求" / "requirement analysis"
- 开始技术设计或编码前，需求尚未明确
- 用户描述的是业务目标，尚未转化为后端实现边界
- 任何涉及 API 设计、数据存储、异步任务或服务集成的新功能

## 输入

按优先级获取需求内容：

1. **对话上下文**：用户在消息中描述了需求，直接使用
2. **用户提供路径**：用户指定了 PRD / 需求文档路径，直接读取
3. **自动发现**：在当前工作目录中查找最近修改的需求文档

```bash
ls -t $(find . -maxdepth 3 \( -name "*prd*" -o -name "*requirement*" -o -name "*需求*" \) -name "*.md" 2>/dev/null) 2>/dev/null | head -5
```

若自动发现到多个候选文件，列出并让用户确认。若未找到任何文件，提示用户描述需求或提供文档路径。

## 目标

- 用后端术语重新描述业务请求
- 区分已确认事实、假设和未知项
- 产出可实施的验收标准
- 尽早暴露后端特有风险

## 工作流程

### 第一步：理解请求

提取以下信息：

- 业务目标
- 用户或上游系统的动作
- 预期输出
- 用户已明确的约束

如果用户描述模糊，做最小安全假设并标注为「假设」。

**EARS 结构化**：将需求改写为结构化句式，消除歧义：

| 句式 | 适用场景 | 示例 |
|------|----------|------|
| When [事件], the system shall [行为] | 事件触发型 | When 用户提交订单，系统应扣减库存 |
| While [状态], the system shall [行为] | 持续状态型 | While 支付待处理，系统应禁止取消 |
| If [条件], then the system shall [行为] | 条件分支型 | If 超出配额，系统应返回 429 并附 retry-after |
| The system shall [行为] | 无条件约束 | 系统应对 PII 字段静态加密 |

每条核心需求至少用一种 EARS 句式表达。

### 第二步：拆解后端维度

始终分析以下维度：

- 领域实体与状态转换
- API 或消息契约
- 读写路径
- 数据校验规则
- 权限与租户隔离边界
- 一致性与幂等性要求
- 失败处理与重试策略
- 可观测性预期
- 性能与容量预期
- 发布与回滚约束

### 现状验证（必做）

在产出需求文档之前，验证以下三项可行性：

**数据可用性**
- 所需数据是否已存在于系统中？
- 是否需要新增采集或迁移？历史数据如何处理？

**接口可行性**
- 依赖的上下游接口是否已存在？
- 契约是否稳定（版本、字段、SLA）？是否需要协调外部团队？

**依赖就绪度**
- 所需基础设施（队列、缓存、存储）是否已就绪？
- 依赖服务的当前状态（稳定 / 开发中 / 计划中）？

### 第三步：输出需求文档

使用以下结构：

```md
# 需求分析

## 核心结论

> **结论**：[一句话说明需求是否可行、主要约束、推荐的 MVP 范围]
>
> **关键风险**：[最高优先级的 1-3 个风险]
>
> **建议行动**：[下一步最重要的决策或确认项]

## 需求追溯表

| Req# | 需求描述 | 优先级 | 来源/假设 | 验收标准编号 |
|------|----------|--------|-----------|-------------|
| R1   |          | Must   | 用户明确  | AC1, AC2    |
| R2   |          | Should | 假设      | AC3         |

## 目标

## 范围内

## 范围外

## 参与方与依赖

## 领域模型

## API 或事件契约

## 业务规则

## 非功能需求

## 验收标准

| AC# | 场景 | 前置条件 | 操作 | 预期结果 | 可验证 |
|-----|------|----------|------|----------|--------|
| AC1 |      |          |      |          | ✅/⚠️/❌ |

> 可验证标注：✅ 数据和接口已就绪 | ⚠️ 需前置工作 | ❌ 当前不可验证（列入待确认项）

## 风险与待确认项
```

### 第四步：定义验收标准

好的验收标准应具备：

- 可观测性（能被测试或监控验证）
- 后端可验证（不依赖前端）
- 边界感知（覆盖边界条件）
- 失败感知（覆盖失败路径）

必须包含以下路径：

- 正常路径
- 无效输入路径
- 重复请求路径
- 依赖失败路径
- 权限失败路径

## Go 后端关注清单

- 是否有明确的请求边界和处理入口？
- DTO 是否与领域对象分离？
- 状态转换是否明确？
- 写操作是否需要幂等性？
- 最终一致性是否可接受？
- 超时、重试和取消规则是否已定义？
- 是否需要审计日志或指标？
- 是否有 SLO 或延迟目标要求？

## 输出规则

- 不要过早进入包结构或表结构设计。
- **不要写具体的 IDL 定义、数据库 schema 或代码片段**——需求层只描述"需要哪些参数、什么类型、互斥关系"，具体字段编号、annotation、Go struct 留给技术设计阶段。
- 不隐藏未知项，明确列出。
- 如果需求过大，拆分为阶段：MVP、加固、规模化。
- 优先给出精确的验收标准，而非实现建议。
- **核心结论必须置顶**，包含可操作的决策建议。
- **需求追溯表必须在核心结论之后**，确保每条需求可追溯至验收标准。

## 参考资料

- 快速问题清单参见 `references/checklist.md`

## 交接

需求分析完成后，在对话末尾告知用户可选的后续步骤，**等待用户明确指示后再继续，不得自动进入下一阶段**：

- `/go-backend-technical-design` — 组件与接口设计
- `/go-backend-architecture` — 跨服务或长期架构决策（可选）