收集需求后按票数排序，很直观，也容易让讨论忽略没有参加投票的人和没有表达清楚的任务。票数可以作为一种线索，却不能独自证明开发价值。本文用虚构的内部资料工具讨论说明证据卡方法，不提供真实用户比例、投入产出数据或任何产品的确定开发计划。
先核对投票来自谁
记录参与对象、收集范围和当时展示的题目。主动回应的人不一定代表全部使用者，同一人是否重复表达也需要核对。没有完整信息时明确说明限制，不根据少量反馈推算总体需求。投票的意义取决于收集方式，不能只留下一个数字，删除它形成的背景后再拿来作跨需求比较。
把功能名称还原成任务
虚构讨论里有人希望批量整理资料，先问他原本要完成什么、目前在哪里卡住、多久会遇到一次。具体频次需要真实记录，不由整理者猜测。功能只是可能方案，任务和问题才是讨论基础。不要直接把一个提议名称当成唯一解法，也不要因为名称热门就默认它解决的是最重要问题。
补上现在如何处理
了解使用者已经采用哪些替代办法，以及仍然无法解决的部分。有人用现有功能组合已经完成任务，有人依然需要大量人工核对，两者不能仅按相同的一票处理。记录实际流程与限制，不把所有额外步骤都自动换算成效率损失，更不要编造每次节省多少时间来强化说服力。
区分已知影响与预期收益
观察到反复遗漏某项资料，是问题证据；认为新增功能可以避免遗漏，是待验证的方案假设。两者应分开。可以设计小范围原型或人工流程试验，观察是否解决关键困难，但结果未出现前不能宣称已经有效。用户说喜欢一个想法，也不等于确认未来会持续使用或愿意付费。
在共同标准下比较候选
结合任务重要性、证据充分程度、实际约束和验证成本讨论，不必强行把每项都变成精确分数。资源与技术可行性应由相关负责人评估，未知部分列出下一步。票数高但问题不清，可以先补访谈；票数少但存在明确阻塞，也值得进一步查证。排序理由应能回到材料，而非只剩一个总分。
决定后记录为什么先做或暂缓
把采用的依据、仍有风险和准备验证的信号写清，后续条件变化时再复查。建议选少量候选需求试用证据卡，先补最影响判断的信息，不为每个想法制作冗长档案。本文配图是方法示意，不是英飞需求后台截图。优先级讨论需要帮助团队选择下一步行动，而不是让一串票数代替所有判断。