告别返工：用 Rule 让 AI 精准理解你的需求
在与 AI 协作时，我们遇到的最大瓶颈往往是“沟通”。我们以为 AI 理解了，但它产出的代码却常常偏离轨道。这背后真正的问题是：我们缺少一个高效、无歧义的需求沟通范式。
@requirement-understanding.mdc 这个 Rule 的诞生，就是为了解决这个问题。
你是否遇到过这些“鸡同鸭讲”的时刻？
- 你说“做一个用户列表”，AI 却没考虑分页、搜索和加载状态。
- 你让它“优化性能”，它却可能过度设计，引入不必要的复杂性。
- 你描述了一个业务场景，但 AI 忽略了关键的边界条件和异常处理。
这些问题的根源在于，AI 缺少我们人类开发者脑中的“隐性知识”和“上下文”。我们不能假设它“应该知道”，而必须主动、清晰地告诉它。
这个 Rule 如何保证“精准理解”？
@requirement-understanding.mdc 将需求沟通变成了一个结构化的“问答环节”，它强制 AI 像一个优秀的产品经理一样，从四个核心维度来“采访”你：
- 功能细节 (What)：它具体要做什么？有哪些关键行为？
- 数据处理 (How)：数据从哪里来，到哪里去，格式是怎样的？
- 交互方式 (Interaction)：用户如何操作？系统应如何反馈？
- 边界条件 (Edge Cases)：空状态、异常、特殊输入如何处理？
通过这个过程，AI 被引导着去探索需求的每一个角落，将模糊的描述转化为清晰、可执行的任务清单。
为什么它能改变你的开发流程？
-
核心优势：前置问题，避免返工
- 在动第一行代码前，就把可能出现的理解偏差全部消除。这能极大地减少后期因为需求理解错误导致的无效编码和重构工作。
-
使用场景：任何非“一句话”需求
- 当你需要开发一个新功能、修复一个复杂 Bug 或进行一项重构时，都可以先用这个 Rule 和 AI “对齐认知”。需求越复杂，它的价值就越明显。
-
读者最关心的：它真的不麻烦吗？
- 恰恰相反，这短暂的“麻烦”是为了长远的“简单”。花 5 分钟进行一次结构化的需求沟通，可能为你节省数小时的调试和修改时间。它将“无效沟通”变成了“有效投资”。
一句话总结： @requirement-understanding.mdc 是你的“AI 需求翻译官”，它将你的自然语言需求，转化为 AI 能精准理解和执行的工程语言，为高质量的软件交付打下坚实的基础。
@requirement-understanding.mdc 具体规则如下
---
alwaysApply: false
---
# 业务需求理解规则
## 🎯 核心目标
**充分理解用户提出的需求**。通过主动提问和总结，确保完全掌握需求的核心关键点。
## 📋 理解要点
### 必须确认的核心问题
- **功能细节**：具体要实现什么功能，有哪些关键行为？
- **数据处理**：涉及什么数据，数据如何流转和处理？
- **交互方式**：用户如何操作，操作后的反馈是什么？
- **边界条件**：特殊情况和异常场景如何处理？
## 🔄 执行流程
### 1. 初步理解
结合项目背景，快速理解需求的具体功能：
- **查看相关代码**：先查看相关的现有代码和组件
- **理解现状**：理解当前的实现方式和数据流
- **分析改动范围**：基于现状来理解需求的改动范围
### 2. 需求复杂度评估
根据需求描述判断复杂程度：
- **简单需求**：功能明确，只需2-3个关键点确认
- **复杂需求**：涉及多个模块或复杂交互，需要详细分步骤提问
### 3. 针对性提问
对不明确的功能细节进行提问，直到完全理解：
- **控制提问数量**：每次提问8-12个问题，按4个维度分组
- 如果功能行为不清楚，要问清楚具体的操作步骤
- 如果数据处理模糊，要问清楚数据的格式和流向
- 如果交互方式不明，要问清楚用户操作和系统反馈
- 如果边界条件未知，要问清楚异常和特殊情况
### 4. 总结关键点
最终输出需求的核心关键点：
- **功能描述**：具体要实现什么
- **关键行为**：主要的操作流程
- **数据要求**：涉及的数据和格式
- **交互设计**：用户操作和反馈
- **边界处理**：异常和特殊情况
## 🚫 避免的行为
- ❌ 对功能细节模糊不清就停止提问
- ❌ 关注高层次业务价值而忽略具体功能
- ❌ 跳过关键功能点的确认
## 📌 记住
**目标是完全理解功能需求的具体细节，不涉及技术方案**。确保经过这个过程后，对用户的功能需求有清晰准确的认知。
