需求导入流程（Phase 0）
Phase 0 — 从一句话需求到可评审的结构化产物。7 个步骤，3 个门禁，确保需求“想清楚再动手”。
Phase 0 完整流程
Section titled “Phase 0 完整流程”点击节点查看详情
📨 0.1需求收集
🔍 0.2需求澄清🚦 Clarification Gate
🔬 0.3可行性分析
⚖️ 0.4方案选型决策🚦 决策1: 方案选型
🎯 0.5Feature 基线 + Review Ready Gate🚦 Review Ready Gate
📋 0.6评审 PPT + 评审会议 + 决策回流🚦 评审决策
📄 0.7IR 生成
📑 0.8Proposal 拆分 + SR 生成🚦 GA Gate
🤝 0.9Handoff 交接🚦 Intake 完成确认
澄清门禁
需求中所有「待确认」项必须逐条向用户澄清。AI 不允许对不确定的需求直接生成下游产物。以用户判断为准。
代码证据优先
可行性分析必须基于实际源码检索（MCP + Agentic RAG）。禁止「看起来合理」的虚构分析。
方案对比不做推荐
feasibility 只给各方案的事实判断，不做选型推荐。decision.md 才做方案对比和推荐倾向，最终由用户决定。
三级 Gate
Clarification Gate（澄清完整性）→ Review Ready Gate（Feature 结构质量）→ 需求决策（立项审批）。
产出文件清单
Section titled “产出文件清单”| 产物文件 | 阶段 | 描述 |
|---|---|---|
01-requirement.md | 0.1 | 收集原始需求，生成 01-requirement.md（RR单号、诉求方、背景、目标、FR/NFR、约束）。禁止占位符——不确定项留到澄清环节 |
01-requirement.md (clarification_status) | 0.2 | 逐条澄清待确认项（禁止"待确认"/"TBD"），所有字段必须写入已确认事实。Clarification Gate 通过后才进入可行性分析 |
02-feasibility.md | 0.3 | 基于代码证据评估技术可行性（kb_precheck_path），按方案独立估算工作量（500行≈1人月）。禁止选型推荐 |
feasibility-inputs.md | 0.3 | 基于代码证据评估技术可行性（kb_precheck_path），按方案独立估算工作量（500行≈1人月）。禁止选型推荐 |
03-arch-decision-record.md | 0.4 | 两阶段执行：阶段A（候选对比+AI推荐倾向）→ 暂停等待用户决策 → 阶段B（决策定稿）。SIG评审会议做最终选型 |
04-feature.md | 0.5 | 生成 04-feature.md（价值/AC/影响性分析/Proposal拆分），由独立 subagent 执行 Review Ready Gate（12项检查） |
decision_gate_*.json | 0.5 | 生成 04-feature.md（价值/AC/影响性分析/Proposal拆分），由独立 subagent 执行 Review Ready Gate（12项检查） |
requirement-review.pptx | 0.6 | 生成评审PPT → 评审会议 → value-decision 记录决策纪要（Accepted/Rejected/PendingRe-review）并路由 |
decision_gate_*.json | 0.6 | 生成评审PPT → 评审会议 → value-decision 记录决策纪要（Accepted/Rejected/PendingRe-review）并路由 |
IR.md | 0.7 | Feature → IR（平台级 8 项评估 + 扩展维度确认），AC 编号全链路追溯 |
05-proposal*.md | 0.8 | IR → Proposal 拆分（每个 ≤ 复杂度上限）→ GA 审批 → SR 生成，RR单号全链路追溯 |
SR-*.md | 0.8 | IR → Proposal 拆分（每个 ≤ 复杂度上限）→ GA 审批 → SR 生成，RR单号全链路追溯 |
handoff.md | 0.9 | 生成 handoff.md 交接契约，RR单号 + 全套产物移交 Phase 1-9 交付流程 |