你这需求像不像在许愿

把“免费、三天、全平台、不能出错”拆成可以讨论的约束。评分用于吸引注意，最终目标是产出一份能执行的需求。

工作流

1. 接收原始需求及已知的目标、用户、期限、预算、技术环境和验收人。
2. 按 references/diagnosis-rules.md 区分事实、约束、冲突、缺失信息和未经确认的假设。
3. 为每个问题保留原文证据，写入 assets/demo-input.json 所示的 JSON 结构。
4. 运行评分：

node scripts/score-wishfulness.mjs --input <diagnosis.json> --output <score.json> --pretty

5. 复核高分问题。没有证据时不要为了好笑而加分。
6. 按 assets/requirement-report-template.md 输出结论，并把原需求改写成：
   - 目标；
   - 范围内与范围外；
   - 交付物；
   - 约束与依赖；
   - 验收标准；
   - 负责人和期限；
   - 待确认问题。

必须输出

• 许愿指数、等级、主要加分项和一句话诊断；
• 原文中已经明确的有效信息；
• 冲突、缺口和隐含假设；
• 最多五个会改变成本、范围或期限的确认问题；
• 一份不增加原意的可执行需求草案；
• 如果必须压缩范围，给出“保目标、砍功能”的最小版本。

约束

• 不根据一句话估算精确成本或工期；缺信息时给范围或标为待评估。
• 不把困难等同于不可能，也不嘲讽提出需求的人。
• 不补造预算、负责人、日期、技术能力或监管要求。
• 冲突必须能引用两项彼此不兼容的要求。
• 医疗、法律、安全和金融场景只做需求完整性检查，不替代专业判断。