领域启发式应从该领域真实问题库归纳，而非把通用条目改写措辞
别名: 问题库归纳 · 领域知识 · 检查条目 · 措辞改写陷阱
概念解释
领域条目应来自事故报告、审计缺陷、工单、现场观察和专家复盘中反复出现的界面相关失效。仅仅把"反馈""一致性"改成本行业词语，不会产生新的检查能力。归纳式构建（inductive heuristic building）要求从具体案例抽象出触发条件、界面线索和判断标准。这一条紧接在"通用启发式覆盖不到领域失效模式"之后：上一条说明了为什么需要额外条目，这一条说明这些额外条目应该从哪里来——答案是真实案例，不是文字游戏。
机制
把"提供信息丰富的反馈"改写成"提供信息丰富的患者状态反馈"，看起来像是一条新的领域条目，实际上只是换了名词，评估者靠它检查不出任何通用条目原本就检查不出的问题——这类改写之所以没用，是因为它没有引入任何新的结构性信息，通用条目原本缺失的正是"这个领域里，哪些数据必须同时可见、哪些顺序被法规锁定、哪个自动化环节会掩盖责任归属、哪种状态组合会导致高危歧义"这类具体到该行业运作方式的知识，这些知识不可能靠给通用词汇加前缀凭空生成。真实问题库之所以有效，是因为它把这些结构直接暴露出来：归纳时先把相似的历史案例聚类，再比较"最终被避免的路径"和"最终酿成事故的路径"之间到底差在哪个具体的界面细节上，把这个差异写成条目，条目自然带着可检验的触发条件和界面线索，而不是一句听起来专业的空话。
边界
问题库本身存在偏差：主动上报多的问题不一定是最重要的问题，而某些长期没有被记录下来的失效模式，恰恰因为从未被记录，反而会在问题库里彻底缺席——一个只依赖历史工单和事故报告构建的清单，天然会对"经常被抱怨但影响小"的问题过度敏感，对"影响巨大但极少发生、还没来得及被记录"的问题视而不见，这需要领域专家主动补充潜在风险和"近失事件"（差点酿成事故但被及时拦下的情况）来纠正这个偏差。归纳过程也不能照搬每一个案例的具体细节：如果一条条目里塞满了某次具体事故的所有背景信息，它就只能匹配那一次事故本身，遇到同一类问题的变体反而识别不出来，条目需要保留能推广的判断条件，把具体案例降级为附带的正反例说明，而不是条目本身的定义。
怎么落地
- 收集问题库时不能只依赖正式上报的事故，还要主动纳入近失事件、一线专家私下反映的担忧和用户为绕开某个缺陷而形成的非正式操作习惯，这几类信息往往比正式工单更早暴露真正的风险点。
- 按触发对象、界面位置、当时缺失的关键线索和实际后果给案例聚类，为每个聚类归纳出一条候选条目，而不是给每个案例单独写一条。
- 每条候选条目都附上真实的正例（应该被拦下但没拦下的场景）、反例（表面相似但实际不属于该问题的场景）、适用角色和证据来源，让条目从一开始就带着可验证的边界。
- 验证办法：让没有参与撰写条目的一线专家用这条候选条目回溯检查原始案例集，确认它既能捕捉到写条目时依据的那个原始案例，也能捕捉到该案例的合理变体——只命中原始案例说明条目写得过窄，需要重新归纳。