用途
frontend-to-backend-requirements 是一个面向前端开发者的技能模式，用于将前端对后端数据的需求整理成文档，便于与后端开发者沟通。它适用于前端需要向后端说明 API 需求，或用户提到“backend requirements”等场景。
核心理念
该模式要求前端开发者记录自己需要从后端获取哪些数据，但只描述“需要什么”，不描述“如何实现”。后端拥有实现细节的决定权。
输出与限制
所有回复都写入 .claude/docs/ai/<feature-name>/backend-requirements.md，不在聊天中输出。不指定端点、字段名或 API 结构，这些由后端决定。
前端与后端的职责边界
前端负责：需要什么数据、存在哪些操作、需要处理哪些 UI 状态、面向用户的校验、展示要求。
后端负责：数据结构如何组织、端点设计、字段名和类型、API 约定、性能与缓存。
工作流程
-
描述功能：这是什么（页面、流程、组件）、谁使用（用户类型、权限）、目标是什么（成功是什么样）。
-
列出数据需求：针对每个页面或组件，描述需要展示的数据（屏幕上出现什么信息、各部分之间关系、什么决定可见性或状态）、用户可执行的操作（用户能做什么、预期结果、应看到什么反馈）、需要处理的状态（加载、空、错误、成功，以及部分数据、过期等边缘情况）。
-
暴露不确定之处：列出不完全理解的业务规则、不确定如何处理的边缘情况、自己正在猜测的地方，邀请后端澄清或反驳。
-
留出讨论空间：以开放性问题结尾，例如“这样做是否合理？”“我是否应该预期……？”“有没有更简单的方式……？”
输出格式
创建 .claude/docs/ai/<feature-name>/backend-requirements.md，包含以下章节：标题为“Backend Requirements: <Feature Name>”；Context 说明正在构建什么、面向谁、解决什么问题；Screens/Components 下逐个描述页面或组件的用途、需要展示的数据、操作、需要处理的状态（空、加载、错误、特殊）以及影响 UI 的业务规则；Uncertainties 列出不确定项；Questions for Backend 列出向后端提出的问题；Discussion Log 记录后端回复、做出的决定和需求变更。
好请求与坏请求
坏请求（规定实现）：“我需要一个 GET /api/contracts 端点，返回包含 id、title、status、created_at 字段的数组。”
好请求（描述需求）：“我需要展示合同列表。每一项显示合同标题、当前状态和创建时间。用户应该能按状态筛选。”
坏请求（假设结构）：“provider 对象应该嵌套在合同响应里。”
好请求（描述关系）：“对于每份合同，我需要显示提供方是谁（名称，可能还有 logo）。”
坏请求（没有上下文）：“我需要合同数据。”
好请求（带上下文）：“仪表盘上有一个‘最近合同’小组件，展示最近 5 份合同。用户点击一个进入详情页。”
鼓励反驳
在需求中包含这类提示：“如果这不符合数据的组织方式，请告诉我”“欢迎提出更好的方案建议”“不确定这是不是正确的思考方式”“如果这没必要地增加了复杂度，请反驳我”。
好的协作 = 前端描述问题，后端提出解决方案。
规则
不提供实现细节，不指定端点、方法、字段名；描述而非规定，说需要什么，不说如何提供；包含上下文，说明为什么需要有助于后端做出更好选择；暴露未知，不隐藏困惑，邀请澄清；邀请反驳，明确征求后端意见；更新文档，将后端回复加入 Discussion Log；保持谦逊，是请求而不是要求。
后端回复之后
更新需求文档：将回复加入 Discussion Log、根据反馈调整需求、标记已解决的不确定项、记录做出的决定。该文档成为双方达成共识的最终依据。
适用场景
适用于前端开发者需要向后端团队说明数据需求、希望以协作文档方式对齐接口预期、并避免越界规定实现细节的场合。
限制
该技能依赖将输出写入指定文件路径；不提供具体端点或字段设计；有关平台、收费、价格等信息暂未提供。