From 4105a91186244b4924bb088d2e9cf929d770ae8c Mon Sep 17 00:00:00 2001 From: "liqiankun.1111" Date: Mon, 3 Aug 2026 20:35:50 +0800 Subject: [PATCH] docs: define which findings deserve attention Record the long-term Code Review objective: prioritize requirement drift, high-impact changes, conflicting evidence, irreversible choices, and explicit AI uncertainty instead of maximizing comment volume. --- docs/kernel.md | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/docs/kernel.md b/docs/kernel.md index 5dc5217..4d485f9 100644 --- a/docs/kernel.md +++ b/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. 如何判断一项优化是否“对味” 任何新能力都应明确落在以下一个问题上：