docs: define which findings deserve attention

docs/kernel.md

@@ -194,6 +194,17 @@ CCR 的效果提升不是单纯换模型或扩大 prompt，而依靠三项能力
 Pipeline 提供稳定实验骨架，trajectory 说明问题发生在哪一步，Language / Project 决定还能补充哪些
 高价值事实。三者缺一时，效果变化都难以归因，也容易把成本增长误当成质量提升。
 
+沿这条演进线，新一代 Code Review 最终要回答的不是“还能找到多少问题”，而是**哪些问题值得打扰人**：
+
+- **需求不匹配或范围外的变化**：没有实现验收条件，或者做了需求、Spec 和 Agent 计划之外的事情；
+- **影响范围较大的变化**：涉及共享接口、核心数据、权限安全、事务并发、跨服务调用或关键业务链路；
+- **证据不足或相互冲突的变化**：缺少测试和验证，代码事实与 AI 结论不一致，或者上下游影响仍未确认；
+- **难以逆转的长期选择**：引入新的架构约束、核心依赖、数据模型或迁移成本；
+- **AI 自己也不确定的判断**：无法回到明确代码证据、依赖缺失 Context，或者只能给出低置信度推断。
+
+这些类别不是新的 Finding schema，而是 Pipeline、Knowledge 和 eval 的长期演进方向：优先建立足够证据、
+影响与可逆性判断，再决定是否交付，避免把“模型能评论”误当成“值得打扰开发者”。
+
 ## 4. 如何判断一项优化是否“对味”
 
 任何新能力都应明确落在以下一个问题上：