KNOWLEDGE NOTE · 持续修订
需求证据：一条反馈究竟能支持什么决定
保留场景、替代方案、接受条件与行为之间的联系，不让语料规模冒充需求验证。
资料越多，越容易把“找到很多相关讨论”误写成“需求已经验证”。研究的关键动作，是让每条材料只承担它实际支持的判断。
SURE 是我用于整理这件事的方法与工具。它区分场景、问题、替代行为、方案接受和商业行为，要求证据能回到来源。软件负责检查结构，研究者负责解释语义与作出决定。项目与协议
证据等级不是市场成熟度阶梯
| 等级 | 记录的内容 | 不能直接推出 |
|---|---|---|
| E0 | 活动、角色、场景背景 | 存在未满足需求 |
| E1 | 明确任务、困难或目标 | 愿意换一种解决办法 |
| E2 | 当前做法、绕行、失败或切换成本 | 接受研究中的新方案 |
| E3 | 对该方案在给定条件下的接受或偏好 | 已经购买或持续使用 |
| E4+ / E4− | 商业意图 / 拒绝、取消、退货等反证 | 所有人具有同样意愿 |
| E5 | 付费持有、部署、复用等已发生行为 | 这些行为由产品某项功能导致 |
同一角色、场景和任务中的问题链、方案链与行为链，才能连接起来判断。把甲的抱怨、乙的付费和丙的长期使用拼在一起，会制造一位根本不存在的“完整用户”。
先比较用户现在怎样解决
“想要一个机器人帮忙”可能只是表达结果愿望。用户如何处理这件事、频率多高、付出什么、为什么旧方案不够，才让新产品有比较对象。
满意替代方案应保留。它可能说明这个市场已有足够好的答案，也可能指出新方案需要跨过多高的门槛。只收抱怨会把研究变成论证既定方案的材料库。
自动编码只能产生待复核候选
一次公开讨论中的 “return” 可能指退货，也可能指程序返回；“买给父母的扫地机”不能直接变成购买通用照护机器人的证据。出现价格还可能是其他产品、服务或无关支出。
本轮三组语料重计验证了记录数、字段和来源分布，没有逐条确认机器标签。统计见数据页。CLI 检查通过与研究结论通过，是两次不同的验收。
让研究决定下一项行动
对一个拟进入开发的场景，我希望研究交付四样东西：目前最强的支持证据、最强的反证、仍未跨过的判断门槛，以及能改变投入决定的下一次验证。
如果缺的是方案接受，就设计可理解的原型；缺的是交付成本，就做带完整支持记录的试点。继续扩大背景语料，通常无法弥补这两类缺口。
本页把原研究长文收敛为阅读和行动入口。具体数据契约及命令用法仍以项目仓库为准，避免在知识库维护第二套容易过期的工具说明。
公开来源与适用范围
- SURE · User Demand Research
作者项目与方法 · 研究契约、证据分级、CLI 与 MCP；结构检查通过不等于需求成立。