Neo-ZQYY/.kiro/steering/planning-interrogation.md

inclusion

inclusion
always

编码前需求审问（强制）

AI 在用户清晰度结束的地方开始产生幻觉。因此，在写任何一行代码之前，必须通过持续提问来延伸用户的清晰度，找出思维中的 gaps，避免在破碎的基础上构建。

触发条件

当用户提出涉及以下任一场景的需求时，进入「审问模式」：

• 新建功能/模块/页面/接口
• 重构或重新设计已有逻辑
• 涉及多模块联动的改动
• 任何需求描述中存在模糊、隐含假设、或未定义边界的情况

强制流程

1. 进入 Planning 模式

收到需求后，不立即动手，先进入提问循环。每轮提出 3-5 个针对性问题，直到所有维度都有明确答案。

2. 必问清单（最低要求）

以下问题必须逐一确认，不得假设答案：

维度	必问问题
用户	这是给谁用的？（角色/人群）
核心行为	用户执行的核心操作是什么？
完成后果	操作完成后发生什么？（跳转/提示/状态变化）
数据写入	需要保存什么数据？保存到哪里？
数据展示	需要展示什么数据？数据来源？
错误处理	出错时发生什么？用户看到什么？
成功反馈	成功时发生什么？用户看到什么？
认证	需要登录/鉴权吗？什么权限级别？
存储	需要数据库吗？哪个库？新表还是已有表？
终端适配	需要在手机上工作吗？响应式要求？
边界条件	并发/幂等/数据量上限/超时？

3. 追问规则

• 用户回答后，如果答案引出新的未定义项，继续追问
• 不接受"你看着办"作为最终答案——至少确认关键维度
• 每轮追问聚焦于上一轮答案暴露的 gaps
• 当所有必问维度都有明确答案、且无新假设浮出时，才可结束审问

4. 输出需求确认摘要

审问结束后，输出一份简洁的「需求确认摘要」，包含：

• 目标用户与场景
• 核心功能描述（一句话）
• 数据流向（输入 → 处理 → 输出/存储）
• 关键约束与边界条件
• 明确排除的内容（不做什么）

用户确认摘要后，才可进入实施阶段。

与前置调研的关系

• 本规则在 pre-change-research.md（前置调研）之前执行
• 流程顺序：需求审问 → 用户确认 → 前置调研 → 用户确认 → 编码实施
• 如果审问阶段发现需求本身不成立，直接终止，不进入调研

例外

• 用户明确说"直接改"、"跳过审问"、"不用问了"
• Bug 修复且用户已给出明确的复现步骤和期望行为
• 纯格式/文档/注释调整
• 用户提供了完整的 spec 文档且所有维度已覆盖