Cherry Studio 代码评审判定矩阵风险分级、修复授权与「值不值得修」决策指南【免费下载链接】cherry-studioAI productivity studio with smart chat, autonomous agents, and 300 assistants. Unified access to frontier LLMs项目地址: https://gitcode.com/GitHub_Trending/ch/cherry-studio导读本文围绕 Cherry Studio 仓库中内置的自动代码评审技能gh-pr-review的核心决策文档——判定矩阵judgment-matrix.md——展开系统讲解在代码评审发现一个问题之后「怎么分级、要不要修、谁有权修、修到什么程度」的完整决策框架。读完本文你将掌握一套可直接复用的风险分级Low / Medium / High判定方法、默认报告与显式授权修复之间的边界规则以及识别「伪修复反模式」的判别清单适用于任何在 Cherry Studio 这类含评审 Agent 的项目中落地自动化代码评审的场景。一、判定矩阵在整个评审流水线中的位置Cherry Studio 的gh-pr-review技能把一次评审划分为五个固定阶段见 SKILL.md阶段内容引用参考1Product Demand 门禁语义影响判定SKILL.md § Review Stages2Consumer 评审共享表面是否有真实消费者consumer-review.md3Architecture-First架构先行评审cherry-review-guidance.md4Implementation实现清单 A/Bcode-checklist.md / doc-checklist.md5Style / Conventions风格清单 C同上判定矩阵是第 4、5 步之后、输出结论之前的「过滤闸门」清单code-checklist / doc-checklist回答「要找什么」而判定矩阵回答「发现的问题要不要修」。在 local-review.md 的 Step 3 中明确要求「Consultjudgment-matrix.mdfor risk level assessment, worth-fixing criteria, and special rules. Discard issues that are not worth reporting」依据判定矩阵评估风险等级、判断是否值得修复并应用特殊规则丢弃不值得报告的问题teams-review.md 的 Phase 3Filter仅协调者执行同样把判定矩阵作为风险分级与自动修复队列路由的唯一权威。换句话说一个评审发现只有通过判定矩阵的筛选才会出现在最终报告中。二、风险分级按「问题」而非按「类别」判定判定矩阵首先明确一个容易忽视的前提风险等级是按单个问题per-issue评估的而不是按类别per-type。同一个类别例如 rename可能因影响范围不同而属于低风险或高风险——把问题归入某个通常低风险的类别、然后机械套用低风险处置是错误做法。2.1 三级风险定义与示例风险规则典型示例Low低只存在一种合理修复方式null 检查、修正错误注释、按约定重命名、删除冗余重复代码、修复明显的 off-by-one 错误、缺失的 useEffect 清理、缺失的 i18n key、过宽的 DataApi refresh 换成明显更窄的 keyMedium中存在多种修复方案但不涉及设计决策或外部契约跨函数抽取共享逻辑、删除未使用的内部方法、简化跨函数控制流、调整内部模块边界、把 handler 的业务逻辑移入既有 service 方法、修复不稳定的 SWR key 或 external-store 快照High高涉及设计决策或外部契约公共 API 变更签名、行为、弃用、IpcApi 契约变更、架构重构、存在多种可行方案的算法替换、引入新依赖、改变数据持久化/序列化格式、涉及空间-时间权衡的性能优化、超出声明 bug 范围的用户可见行为变更、构建系统配置变更、为非 SQLite 副作用新增 DataApi 端点、新增 BootConfig key、跨服务事务重设计、持久化迁移三者的分界本质是**「唯一解」→「多解但无外部影响」→「牵动设计与契约」**。低风险的标志是修复路径唯一且不会引入新风险中风险允许有多种合理实现但都在模块内部消化一旦触碰公共 API、IPC 契约、数据格式、构建配置或用户可见行为就必然升级为高风险。2.2 判定矩阵与严重度语言的关系判定矩阵的风险等级Low/Medium/High与 cherry-review-guidance.md 中的报告严重度Blocker / Warning / Notice是两套互补的坐标风险等级决定「怎么处置」严重度决定「怎么措辞」。后者规定运行时正确性、数据丢失、安全问题、契约破坏、不安全的迁移属于Blocker强制基线文档违规最低按Warning报告绝不允许降级为 Notice 或与附近代码一致设计意图存疑用Notice且除非有代码证据否则不得当作 bug。三、分级处置默认报告显式授权才修复判定矩阵的核心处置表定义了「每个风险等级在什么模式下允许做什么」模式低风险中风险高风险Report-only默认任意目标报告报告报告Authorized fix显式fix调用仅本地目标自动修复报告可行方案与权衡报告可行方案与权衡3.1 授权来源永远来自调用而非目标或信心判定矩阵强调一条刚性原则授权来自调用invocation从不来自目标类型或评审者信心。即默认情况下无论评审对象是文件、分支、commit 还是 PR都只做分析与报告不改动工作树、不写 GitHub只有当调用参数中显式出现fix或等价的显式用户措辞如 review and fix …且目标是本地目标时低风险问题才允许自动修复submit同理只有显式授权才允许向 GitHub 提交评审。这一点在 SKILL.md 的 Authority model 一节得到呼应评审请求只授权分析与报告执行授权由调用时刻显式授予并且 SKILL.md 明确本小节只授予权力、绝不重述映射——风险→动作的映射只能查阅判定矩阵避免两处定义漂移。3.2 中高风险的处理规范对于中、高风险问题即使已授权修复评审必须罗列所有可行方案feasible options说明每个方案的关键权衡key trade-offs可以给出评审者倾向optional recommendation绝不把某个选项表述为已经被选定绝不中途询问用户要修哪些与 SKILL.md 的 Interaction contract 一致正常评审流程不打断、不提问。实现选择的最终决定权保留给用户——因为中高风险往往存在多个合理修复替用户选定方案等于替用户做了设计决策。3.3 测试基线规则绝对红线凡是会改变测试基线截图对比、golden files的修复一律不自动应用——无论风险等级多低都改为报告。理由很直接自动改动测试基线等于悄悄改变验收标准必须由用户知情后决定。3.4 Legacy-data 规则main分支特例判定矩阵记录了项目的一项特殊约束直接反映 Cherry Studio 当前的数据架构演进Redux 已被移除Dexie / ElectronStore 是一次性 v1 栈throwaway v1 stacks禁止修复或扩展当 diff 引入了新的 v1 用法时要报告该问题并把实现引导到 Cache、Preference、DataApi 或 v2 migrators 等正确落点在已经动手修改的区域允许顺手清理死掉的 v1 残留无关区域的清理仍超出范围真正的 v1 维护性修复应归属v1分支绝不能在main上自动修复。这一规则与 code-checklist.md 中 B8No new Redux, Dexie, or ElectronStore dependency is introduced onmain以及 renderer 数据 hook 审查要求相互印证。四、值不值得修四项决策原则判定矩阵用四个等级覆盖发现一个问题后是否动手的完整光谱Must fix必须修——问题影响运行时正确性、安全性或安全security。Fix when clear清晰则修——问题属于代码质量改进性能、简化、架构。仅当解决方案无歧义且不引入新风险时才修。性能改动有额外门槛既要有语义等价的高置信度又要在收益 vs 新增代码复杂度之间净收益为正。Fix when inconsistent不一致则修——问题涉及命名、初始化、注释或文件组织。仅当违反上下文加载的项目规则、或与周边代码既有模式相矛盾时才修。Always skip总是跳过——纯风格偏好不违反任何一致性规则、基于假设的未来需求而非当前代码的建议、以及对没有正确性问题的稳定代码的替代性重写。这套原则的核心精神与 cherry-review-guidance.md 的 Anti-Fragmentation 原则完全一致不要为想象中的未来调用者做泛化不要在没有证据时要求抽象最小修复就是最符合边界的修复。五、例外清单这些情况总是值得修/报判定矩阵在四项原则之外为 Cherry Studio 的技术栈定制了一批总是成立的例外规则评审时直接生效重复代码抽取当相同逻辑明显重复时修复不按数量阈值判定按复杂度和维护成本判断非 bug 修复的公共 API 签名变更只有对 API 消费者有明确收益时才修且永远标记为高风险测试覆盖缺口与回归风险只标记、不修复——报告给用户知晓禁止自动修复console.log→loggerService总是值得修项目约定参见 code-checklist C1「Logging usesloggerServicewith proper context — noconsole.log」硬编码 UI 字符串 → i18n总是值得修code-checklist C1「All user-visible strings use i18next」强制文档违规命名约定、进程架构文档、数据文档以及触碰时的 lifecycle/IPC/window/job 文档至少按 Warning 报告绝不允许以风格偏好或与附近代码一致为由排除实体泄漏进通用表面跨模块或模块内总是值得报告。唯一合法的修复是恢复所有权——把关注点搬回所属领域或显式扩展点。旁路表side tables、在通用契约上加元数据标志、或增加新的特判都不是修复既不能应用也不得作为修复建议提出。扩展点已存在时通常为中风险需要新设计时升为高风险详见 cherry-review-guidance.md § Entity Leakage 与 Fix DirectionDataApi 被用于纯副作用总是值得报告若修复会改变 IPC/API 契约则属高风险cherry-review-guidance.md § Data System And DataApi Boundaries 明确规定 DataApi 只服务于 SQLite 支撑的业务数据不是通用 RPCHandler 级业务逻辑当归属 service与最小移动路径都清晰时值得修否则作为设计确认来报告绕过 owner service 业务规则值得报告。但只读left join数据匹配不在此列——除非它重新实现了另一领域的校验、过滤、排序或行映射渲染层数据 hook 缺陷可能导致陈旧 UI、破坏乐观更新状态或泄漏订阅值得报告新增 BootConfig key必须给出前置生命周期pre-lifecycle的显式理由并获得技术负责人确认BootConfig 应极其罕见参见 cherry-review-guidance.md 中ask for tech-lead confirmation的要求。六、反模式这些「修复」不要做判定矩阵专门列出一类频繁产生误报、除非有强证据表明存在真实 bug否则一律跳过的反模式。它们看似是合理的代码改动实则要么是伪优化、要么是隐藏的行为变更投机式优化Speculative optimizations——构建系统微调、缓存新增、条件守卫但没有任何被证明的失败或可测量的瓶颈。对应 B1 性能审查的纪律性能问题只针对已测量的热路径做有语义等价证据的定点修改。文档示例简化Documentation example simplification——从示例中删掉那些刻意保持冗长以服务教学目的的属性、参数或步骤。这与删除冗余代码不是一回事doc-checklist.md 排除清单第 5 条也明确保护示例的完整属性。伪装成 bug 修复的行为变更——如果提议的修复改变了可观察行为而非仅实现细节必须核实原行为确实是 bug 而不是有意的设计选择。当仅凭 diff 上下文无法确认设计意图时标记但不要修cherry-review-guidance.md 的 Fix Recommendation Policy 也把设计意图不清晰归类为向作者提问而非给出修复。main分支上的 legacy 栈修复——不要修 Dexie / ElectronStore 行为也不要重新引入 Redux。新引入的依赖要报告v1 维护性工作路由到v1分支。唯一例外在已经接触过的区域移除无法影响 live v2 行为的死残留是被允许的。七、判定矩阵如何驱动三种评审引擎判定矩阵不是孤立文档它被三种评审引擎在各自流程中显式引用local-review.md小范围单 Agent 评审Step 3 用判定矩阵过滤问题、丢弃不值得报告者Step 4 应用Handling by Risk Level决定在AUTHORIZED_FIX下哪些自动修、哪些只报告且保持每个修复在缺陷所在的高度defect altitude上不越级打补丁。teams-review.md大范围多 Agent 评审协调者在 Phase 3 独占地执行去重、存在性核验、风险分级再按判定矩阵把问题路由到自动修复队列或报告通道Phase 4 的自动修复只接收低风险且位于缺陷高度的修复——旁路表、元数据标志、额外特判、症状补丁一律不得进入自动修复队列。pr-review.mdPR 评审包装器PR 评审永不改代码AUTHORIZED_FIX false其 Step 4 报告中中/高风险问题的修复建议同样遵循判定矩阵的多方案 权衡 可选倾向、绝不替用户选定格式。三份流程文件都只引用判定矩阵而不重述其规则SKILL.md 明令this section grants the authority and never restates the mapping保证决策逻辑单点维护、无处漂移。八、落地建议把判定矩阵变成评审 Agent 的强制契约把以上规则落实为可执行的评审行为可以总结为一张速查表场景动作问题影响正确性/安全/安全边界Must fix已授权时直接修问题有多解但不涉及外部契约报告中风险列方案、列权衡、给可选倾向绝不替用户选问题触及公共 API / IPC / 数据格式 / 构建配置报告中风险同上且变更公共 API 签名非 bug 修复时永远高风险问题会改测试基线无论风险等级绝不自动修只报告main上出现新 v1 用法 / 需修 v1 栈报告并路由到 Cache/Preference/DataApi/v2 migrators 或v1分支console.log/ 硬编码 UI 字符串总是值得修项目约定实体泄漏、DataApi 纯副作用、强制文档违规总是值得报告Warning 起步投机优化、文档示例简化、伪装成 bug 的行为变更默认跳过除非有强 bug 证据最终判定矩阵的价值在于把评审发现 → 处置决策从评审者的个人风格中抽离变成一份可由 Agent 逐条执行、也可由人工复核的确定性契约——这正是 Cherry Studio 将仓库级评审技能与 code-checklist.md、doc-checklist.md 等清单分层设计的原因清单保证看得全判定矩阵保证判得准、改得稳。【免费下载链接】cherry-studioAI productivity studio with smart chat, autonomous agents, and 300 assistants. Unified access to frontier LLMs项目地址: https://gitcode.com/GitHub_Trending/ch/cherry-studio创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
