Week 2：需求理解与 Requirement IR

本周实现需求理解模块。系统不能把整份自然语言需求原样传给后续 Agent 后宣称已经完成分析，而应生成显式、持久化、机器可读的 Requirement IR。

需要实现

Requirement IR 至少表达：

• 稳定的需求 ID、类型和原文来源；
• 功能行为、前置条件和可验证验收标准；
• 数据、接口、技术和非功能约束；
• 需求之间的分解、依赖或冲突关系；
• 从原文无法确定、但实现必须处理的假设与待决问题；
• 后续产物能够引用的追踪标识。

小组可以采用 JSON、YAML、受约束 Markdown、自定义 DSL 或图结构，但必须提供形式化 Schema、解析或校验工具。系统需要区分“原需求明确规定”“合理推断”和“仍不确定”，不能静默补写需求。

本周交付

• 需求分析命令或模块接口；
• Requirement IR 定义、Schema 和校验器；
• 正常、含歧义和不完整输入的模块测试；
• Requirement IR 到下一模块的最小消费示例；
• 设计说明：表示能力、取舍、已知信息损失和演化方式。

如何检查

教学组提供若干小型需求材料，在相同预算下运行需求模块，并检查：

• 产物能否通过小组自己的 Schema 和课程最低语义检查；
• 每条关键需求是否有来源并具有可测试表述；
• 依赖、冲突、约束和不确定性是否被保留；
• 删除、修改或新增一条需求后，IR 是否产生可解释变化；
• 下游示例是否真实解析 IR，而不是重新读取原始需求绕过它。

评分不奖励字段数量。重点是 IR 是否保留了后续设计、测试和追踪真正需要的信息。