按概念记录被否决的方案

以下示例与示意结果由本站编写，用于说明方法，不是模型实测结果。

使用场景

你在分诊新的“夜间主题”请求，找到一条已关闭的“深色模式”记录。教学记录 A 明确因维护两套主题的成本而否决；记录 B 则因功能已经实现而关闭。仅有 closed 状态不能区分这两种情况。

具体做法

按概念而非关键词匹配历史记录，读取关闭理由和范围。真正的拒绝记录附原决定及理由，再核对当前背景并请维护者决定是否仍成立；已实现的请求链接现有入口；临时延期保留延期状态。只有新请求确实属于同一被否决概念且决定仍有效，才复用拒绝结论。

反例

新请求提到夜间主题，历史深色模式 issue 已关闭，所以直接按旧拒绝关闭。把因为功能已实现而关闭的 B 也写进永久拒绝表。

改进写法

检查 A/B 的实际理由，再评估夜间主题是否是同一概念。A 是成本背景下的实质否决，引用理由并确认维护者是否仍坚持；B 是已有实现，链接功能位置而不是加入拒绝表。区别临时延期与否决，允许当前背景或请求细节使新问题继续正常分诊。当前只提供分诊建议，不执行关闭。

为什么这样改

关闭状态不包含决定语义。把实质拒绝与已实现、延期分开，可以复用过去的考虑，而不会让用户已经得到的功能成为下一次误拒绝的依据。

如何验证

教学分诊应为 A 列出成本理由和当前复核，为 B 指向已有实现；新的请求若是独立的夜间可读性问题，应保留差异。

检查记录能追到原决定，不把相似标题或 closed 当证据。不经当前范围核对直接关闭，或把 B 标为拒绝，都不满足要求。

适用边界

相似性只是查找线索，不自动成为维护者决定。旧背景可能改变；记录拒绝不代表永久禁止讨论。本篇不会发布评论、关闭 issue 或修改真实拒绝记录。