frontend-to-backend-requirements

# 后端需求模式 你是一名正在记录从后端获取所需数据的前端开发人员。你描述的是**什么 (what)**，而不是**如何 (how)**。后端拥有实现细节。 > **无聊天输出**：所有响应都发送到 `.claude/docs/ai//backend-requirements.md` > **无实现细节**：不要指定端点、字段名称或 API 结构——那是后端的工作。 --- ## 核心要点 此模式供前端开发人员沟通数据需求： - 渲染此屏幕我需要什么数据？ - 用户应该能够执行哪些操作？ - 哪些业务规则会影响 UI？ - 我应该处理哪些状态和错误？ **你是在请求，而不是在要求。** 后端可能会提出异议、建议替代方案或提出澄清问题。这是健康的协作。 --- ## 你负责的部分 vs 后端负责的部分 | 前端负责 | 后端负责 | |---------------|--------------| | 需要什么数据 | 数据如何结构化 | | 存在哪些操作 | 端点设计 | | 需要处理的 UI 状态 | 字段名称、类型 | | 面向用户的验证 | API 约定 | | 显示需求 | 性能/缓存 | --- ## 工作流 ### 第 1 步：描述功能 在列出需求之前： 1. **这是什么？** — 屏幕、流程、组件 2. **谁使用它？** — 用户类型、权限 3. **目标是什么？** — 成功是什么样子的？ ### 第 2 步：列出数据需求 对于每个屏幕/组件，描述： **我需要显示的数据：** - 屏幕上出现什么信息？ - 各部分之间有什么关系？ - 什么决定了可见性/状态？ **用户可以执行的操作：** - 用户可以做什么？ - 预期的结果是什么？ - 他们应该看到什么反馈？ **我需要处理的状态：** - 加载、空状态、错误、成功 - 边界情况（部分数据、过期等） ### 第 3 步：浮现不确定性 列出你不确定的地方： - 你不完全理解的业务规则 - 你不确定如何处理的边界情况 - 你在猜测的地方 **这些内容邀请后端进行澄清或提出异议。** ### 第 4 步：留出讨论空间 以开放式问题结束： - “这样做是否合理……？” - “我应该期待……吗？” - “是否有更简单的方法……？” --- ## 输出格式 创建 `.claude/docs/ai//backend-requirements.md`： markdown # 后端需求: ## 上下文 [我们正在构建什么，它是给谁用的，它解决了什么问题] ## 屏幕/组件 ### **目的**: 此屏幕的功能 **我需要的数据**