63 lines
2.7 KiB
Markdown
63 lines
2.7 KiB
Markdown
---
|
||
inclusion: always
|
||
---
|
||
# 编码前需求审问（强制）
|
||
|
||
AI 在用户清晰度结束的地方开始产生幻觉。因此，在写任何一行代码之前，必须通过持续提问来延伸用户的清晰度，找出思维中的 gaps，避免在破碎的基础上构建。
|
||
|
||
## 触发条件
|
||
当用户提出涉及以下任一场景的需求时，进入「审问模式」：
|
||
- 新建功能/模块/页面/接口
|
||
- 重构或重新设计已有逻辑
|
||
- 涉及多模块联动的改动
|
||
- 任何需求描述中存在模糊、隐含假设、或未定义边界的情况
|
||
|
||
## 强制流程
|
||
|
||
### 1. 进入 Planning 模式
|
||
收到需求后，不立即动手，先进入提问循环。每轮提出 3-5 个针对性问题，直到所有维度都有明确答案。
|
||
|
||
### 2. 必问清单（最低要求）
|
||
以下问题必须逐一确认，不得假设答案：
|
||
|
||
| 维度 | 必问问题 |
|
||
|------|----------|
|
||
| 用户 | 这是给谁用的？（角色/人群） |
|
||
| 核心行为 | 用户执行的核心操作是什么？ |
|
||
| 完成后果 | 操作完成后发生什么？（跳转/提示/状态变化） |
|
||
| 数据写入 | 需要保存什么数据？保存到哪里？ |
|
||
| 数据展示 | 需要展示什么数据？数据来源？ |
|
||
| 错误处理 | 出错时发生什么？用户看到什么？ |
|
||
| 成功反馈 | 成功时发生什么？用户看到什么？ |
|
||
| 认证 | 需要登录/鉴权吗？什么权限级别？ |
|
||
| 存储 | 需要数据库吗？哪个库？新表还是已有表？ |
|
||
| 终端适配 | 需要在手机上工作吗？响应式要求？ |
|
||
| 边界条件 | 并发/幂等/数据量上限/超时？ |
|
||
|
||
### 3. 追问规则
|
||
- 用户回答后，如果答案引出新的未定义项，继续追问
|
||
- 不接受"你看着办"作为最终答案——至少确认关键维度
|
||
- 每轮追问聚焦于上一轮答案暴露的 gaps
|
||
- 当所有必问维度都有明确答案、且无新假设浮出时，才可结束审问
|
||
|
||
### 4. 输出需求确认摘要
|
||
审问结束后，输出一份简洁的「需求确认摘要」，包含：
|
||
- 目标用户与场景
|
||
- 核心功能描述（一句话）
|
||
- 数据流向（输入 → 处理 → 输出/存储）
|
||
- 关键约束与边界条件
|
||
- 明确排除的内容（不做什么）
|
||
|
||
用户确认摘要后，才可进入实施阶段。
|
||
|
||
## 与前置调研的关系
|
||
- 本规则在 `pre-change-research.md`（前置调研）之前执行
|
||
- 流程顺序：需求审问 → 用户确认 → 前置调研 → 用户确认 → 编码实施
|
||
- 如果审问阶段发现需求本身不成立，直接终止，不进入调研
|
||
|
||
## 例外
|
||
- 用户明确说"直接改"、"跳过审问"、"不用问了"
|
||
- Bug 修复且用户已给出明确的复现步骤和期望行为
|
||
- 纯格式/文档/注释调整
|
||
- 用户提供了完整的 spec 文档且所有维度已覆盖
|