@chongyan/autospec 1.0.2 → 1.0.3

package/knowledge/07-standards/01-code-review.md

@@ -1,876 +0,0 @@
-# Code Review 评审规范
-
-> **版本**: v1.0
-> **最后更新**: 2026-03-26
-> **适用范围**: 所有项目代码评审
-> **核心理念**: Code Review 是代码质量保证的重要手段，也是工程师文化建设的重要环节
-
----
-
-## 一、评审原则
-
-### 1.1 什么时候做评审
-
-#### 两种研发模式的 CR 方案
-
-**1. 分支研发模式**（发布分支永久锁定）
-
-- **推荐方案**：开发分支每次提交评审
-  - 开发分支锁定，不允许直接 push
-  - 每次代码提交通过合并请求触发评审
-  - 评审通过才允许合并
-  - 开发分支发起合并到发布分支时不需要 review
-
-- **方案二**：开发分支整体评审
-  - 开发分支不锁定，允许直接 push
-  - 开发分支发起合并到发布分支时触发整体评审
-
-- **方案三**：每次提交评审 + 整体评审
-  - 每次提交侧重单次变更内容评审
-  - 整体评审侧重分支整体变更内容评审
-
-**2. 主干研发模式**（主干分支永久锁定）
-
-- 主干分支不允许直接 push
-- 基于主干拉取个人分支开发
-- 个人分支往主干合并时做评审
-- 评审通过后允许合并
-
-#### 核心要求
-
-根据《风险防范基本条例》：
-- **所有代码变更必须 Code Review**
-- 必须基于发布的应用上线代码对比
-- 代码评审发起人和评审人不能是同一人
-- 必须有记录、有明确的负责人与参与人
-
-### 1.2 评审速度
-
-**评审人响应速度要求**：
-
-- 每次评审应在**工作日 24 小时内**及时响应与反馈
-- 如无法及时完成所有评审，应在 24 小时内给出初步反馈
-- 及时响应有助于提高评审流程效率
-- 有助于评审人与发起人进行多轮沟通
-
-### 1.3 什么时候评审通过
-
-#### 评审通过的判断原则
-
-评审人通过以下重点内容判断代码是否通过：
-
-1. **功能实现达标** - 需求完整实现
-2. **代码设计合理** - 架构清晰，逻辑清楚
-3. **单元测试通过** - 测试用例充分
-4. **测试覆盖率达标** - 本次变更行的覆盖率 ≥ 工程整体覆盖率
-
-#### 解决评审意见冲突
-
-**核心原则**：只要当前变更对系统整体代码具有一定质量提升，评审人应倾向于通过，**不要苛求完美**。
-
-**化解冲突方式**：
-
-1. **面对面交流** - 尝试解决冲突并达成一致
-2. **保留评论** - 确保评论保留供团队成员参考
-3. **升级讨论** - 升级至更广泛团队讨论
-4. **TL 决策** - 让 TL 参与进来作出决策
-
----
-
-## 二、职责与礼节
-
-### 2.1 评审人职责
-
-#### 保证质量
-
-- 保证评审质量，把关代码质量
-- 识别代码中的风险和问题
-
-#### 有效评论
-
-**善于反馈**：
-
-- 反馈前三问思考：**是否是对的，是否有必要，是否可读**
-- 避免苛求每一行代码都是完美的，**抓住重点反馈**
-- 毫不吝啬地正向反馈：表扬、称赞、分享
-
-**评论内容**：
-
-- 使用第一人称，拉近人与人的距离
-- 围绕代码讨论发表观点，**不要指责代码作者**
-- 从整体框架上指导应该改进的地方
-- **切勿追求完美**
-- **切勿直接帮助发起人改动代码**
-- 确保可评审的代码模块大小合理
-- 评审内容过多应终止评审并要求发起人重新拆分
-
-### 2.2 发起人职责
-
-#### 拆分适合 CR 的代码块
-
-- 在系分设计评审阶段邀请评审人参与
-- 模块拆分尽量职责单一化、原子化、异步化
-- **通常保持在 100 行左右的大小较为合理**
-- 可通过提高分支频率来辅助拆分模块
-
-**举例分支命名**：
-```
-sprint-1/feat-a/step-1-of-5-modeling
-sprint-2/feat-a/step-2-of-5-mock-api
-```
-
-#### 充分准备
-
-- 完成**自测 + 自主 Review + 静态分析工具扫描**
-- 写清楚变更相关信息：原始需求、交互、系分
-- 可包括测试地址和账号
-- 给评审人打招呼，告知期望、紧急度
-- 邀请对代码、业务熟悉的同学 CR
-- 可以邀请质量同学 CR
-
-#### 有效反馈
-
-**谦逊交流**：
-
-- 保持谦逊，成长会更快
-- 评审是最直接也是最快的自我成长方式
-- 是难得的团队协作磨合机会
-- 围绕代码讨论发表观点，**不要指责评审人或反应过激**
-
----
-
-## 三、如何写好 CR 的标题和描述
-
-### 3.1 标题规范
-
-**要求**：
-
-- 采用祈使句，完整的一句句子
-- 简要说明本次代码变更的核心
-- 可以对变更的风险或影响面标明级别
-- 格式可参考 [Conventional Commits](http://conventionalcommits.org/)：`<type>[optional scope]: <description>`
-
-**示例**：
-```
-feat(parser): add ability to parse arrays
-fix(api): resolve null pointer exception in payment service
-refactor(user): extract user validation logic to separate class
-```
-
-**类型说明**：
-- `feat`: 新功能
-- `fix`: Bug 修复
-- `refactor`: 重构
-- `perf`: 性能优化
-- `test`: 测试相关
-- `docs`: 文档更新
-- `style`: 代码格式调整
-- `chore`: 构建/工具变更
-
-### 3.2 描述规范
-
-**必须包含的内容**：
-
-- 对所解决问题的简要描述
-- 对重点问题需要评审人关注的需要指明
-- 如果对 CR 时间有要求的可以向评审人指出
-- 针对解决冲突的 MR，指明冲突的文件或重点关注范围
-- 如果有已知缺陷，应当提及
-- 如果有遗留问题，应当提及
-- 附上相关背景信息：缺陷、需求文档、系分设计文档的链接或单元测试情况
-
-### 3.3 优秀描述案例
-
-**案例 1 - MR 背景详细描述**：
-
-```markdown
-## MR 背景
-本次 MR 要解决以下问题：
-
-1. 检测到存在跨域风险
-   链接：[安全报告链接]
-
-2. 检测到系统使用了会打开 jmx 端口的 drm 1.0 注册方法
-   相关 bug：[bug 链接 1], [bug 链接 2]
-
-3. 补充单元测试，提升质量分
-
-## 验证方式
-...
-```
-
-**案例 2 - CR 详细描述**：
-
-```markdown
-## 变更说明
-代码中需要增加日志配置，用于安全审计。
-
-## 需要关注的问题
-新增日志需要评估：
-- 异步/同步日志打印
-- 日志量大不大
-- 会不会对主链路服务调用有影响
-- 能不能降级
-- 对原来的容量评估是否有影响
-```
-
-### 3.4 不好的描述案例
-
-**反例**：
-
-- "改 bug" - 未说明改了什么 bug
-- "打补丁" - 未说明补丁内容
-- "增加一些功能" - 未说明具体功能
-- "删链接" - 未说明删除原因
-- "重构代码" - 未说明重构范围和目的
-
----
-
-## 四、评审内容 - 好代码三要素
-
-### 4.1 可读性
-
-#### 定义
-符合代码编码规则，代码简洁、容易理解。
-
-#### 后端评审要点
-
-**命名与注释**：
-- [ ] 命名是否能清晰表达变量的用途
-- [ ] 是否有清晰而有用的注释，解释"为什么"，而不仅"是什么"
-- [ ] 类和函数的注释是否合规，表述是否清晰
-
-**代码风格**：
-- [ ] 是否与团队内部的风格约束保持一致
-- [ ] 函数/源文件级代码风格是否一致
-- [ ] 是否存在嵌套超过 2 层的循环
-- [ ] 是否存在 if 判断条件分支个数大于 5 的情况
-- [ ] 函数长度是否符合要求
-- [ ] 是否存在为了提升性能而实现得非常晦涩的代码
-
-**业务属性**：
-- [ ] 金额必须明确**单位和币种**
-- [ ] 金额计算必须使用专用类型（如 Money 类）
-
-#### 前端评审要点
-
-**代码逻辑**：
-- [ ] 临界值处理方式
-- [ ] 业务规则实现方式
-- [ ] 异常情况处理与逻辑独立干净
-
-**代码风格**：
-- [ ] 整体结构是否清晰
-- [ ] 代码简明有序
-- [ ] 开启`pre-commit` 处理基础代码格式与低级错误
-
-**代码优雅**：
-- [ ] 命名合理清晰
-- [ ] 良好注释
-- [ ] 可读性高于简洁
-
-#### 算法评审要点
-
-- [ ] SQL 书写规范，脚本原子化切分，不过度堆砌
-- [ ] Python 清晰简洁，核心逻辑需有注释
-- [ ] 输入输出有举例
-
-### 4.2 可靠性
-
-#### 定义
-鲁棒性、性能、以及质量和技术风险设计上的整体最优。
-
-#### 线程安全
-
-- [ ] 是否使用全局变量
-- [ ] 是否使用 static 变量
-- [ ] 对共享对象的访问是否有锁/临界区保护
-- [ ] 无锁的实现方式是否清晰
-- [ ] 是否存在同时持有多个对象的锁的情况
-- [ ] 加锁顺序是否会导致死锁
-- [ ] 线程同步机制是否清晰
-- [ ] 是否会出现死等的情况
-- [ ] 正常/异常退出是否有序
-
-#### 安全性
-
-- [ ] 是否有**水平权限**漏洞风险（必须校验是本人操作）
-- [ ] 是否存在敏感信息泄露
-- [ ] 是否存在内部数据库连接，连接字符串是否明码
-- [ ] **WEB 表单提交必须防篡改**
-- [ ] **后端接口服务必须校验入参的合法性**
-- [ ] **异常 catch 后禁止不做任何处理就截断，严禁吞掉异常**
-- [ ] **比较对象必须使用 equals 方法**，不接受任何理由的空指针
-- [ ] 是否存在数组越界访问
-- [ ] 是否存在访问野指针、已关闭句柄的情况
-- [ ] 线程上下文变量的设置与清除必须配对，在 finally 中清理，避免内存泄漏
-- [ ] **业务数据状态处理做好并发控制，必须遵守一锁二判断三处理原则**，避免脏读
-- [ ] 一级业务不允许强依赖全局单点资源
-- [ ] 单点资源必须做到故障可切换，业务可降级
-- [ ] 合理设置对下层服务的**超时时间**
-- [ ] 是否存在整数溢出，是否存在缓冲区溢出
-- [ ] 是否存在 SQL 注入的漏洞
-- [ ] 是否处理了用户输入为 NULL 的情况
-- [ ] 函数调用的关键参数是否有检查
-- [ ] 是否存在 switch fall through（case 没有 break）
-
-#### 功能性
-
-- [ ] **用例完成度**：是否有有效的单元或接口用例
-- [ ] 单元测试用例是否覆盖所有需求点
-- [ ] 是否覆盖边界情况和异常情况
-- [ ] **可测性**：是否已经过测试或具备可测试的要求
-- [ ] 是否完整地实现了需求池中记录的需求点
-- [ ] 仅实现已经过系分评审的需求，超出需求范围的业务变更不允许
-- [ ] 代码覆盖率是否达标
-- [ ] 未覆盖代码是否存在隐患
-- [ ] 功能/接口是否向后兼容
-- [ ] 对外部库函数的使用是否符合调用规范
-
-#### 性能
-
-- [ ] 是否有线程安全、慢 SQL、数据热点等风险
-- [ ] **SQL 语句必须带 where 条件**
-- [ ] **杜绝 select ***
-- [ ] **增加或修改查询 SQL 必须保证走上索引**，避免全表扫描
-- [ ] 代码实现是否影响常用路径的性能
-- [ ] 对象复制和内存拷贝是否必要
-- [ ] 是否存在忙等待
-- [ ] 是否清楚锁
-- [ ] 临界区设置及长度是否合理
-
-#### 资源管理
-
-- [ ] 线程、内存、句柄等资源的生命周期是否清晰
-- [ ] 资源的申请/释放是否匹配
-- [ ] 是否遵守接口的使用要求
-- [ ] 异常处理路径对资源的释放是否合理
-- [ ] 是否有应对高并发、大数据量下资源使用的限制方案
-- [ ] 运行时诊断信息和 Trace 信息是否完备
-
-#### 异常处理
-
-- [ ] 日志级别是否准确
-- [ ] 在异常情况下是否会导致打印过量日志
-- [ ] 是否有吞掉错误码、未处理出错的情况
-- [ ] 是否有网络、IO、内存分配等操作的出错检查
-- [ ] 对第三方接口的使用中，出错判断是否符合其要求
-- [ ] 对极端情况/边界情况的处理是否合理
-- [ ] 出错处理代码对状态位及资源、句柄、引用计数的处理是否正确
-
-#### 可维护性
-
-- [ ] **服务方和调用方必须严格区分成功、失败、重复调用和未知异常**
-- [ ] 做好幂等性控制，未决状态回查等分支
-- [ ] 是否存在对可配置项硬编码的情况
-- [ ] 是否存在重复实现已有功能的情况
-- [ ] 是否存在死代码
-- [ ] 是否存在多余的 using/include
-- [ ] 是否有对执行顺序的不当依赖
-- [ ] 对不完善的实现是否明确标识`//TODO`
-- [ ] 代码实现和设计文档、用户帮助手册是否一致
-- [ ] 是否使用经过统一封装的第三方库函数（如中间件、各业务基础中台团队提供的标准库）
-
-#### 其他
-
-- [ ] **三板斧**：是否考虑了灰度、监控和应急场景
-- [ ] **链路风险**：是否有全链路的潜在风险设计场景
-- [ ] **缺陷**：是否提交存在已有缺陷，尤其是难以测试发现的，以及冲突解决错误
-- [ ] **精简度**：是否有可简化的复杂逻辑，是否有重复代码
-
-#### 前端特有评审要点
-
-**框架与工具**：
-- [ ] 框架类采用部门推荐的标准前端研发框架、类库的最佳实践
-- [ ] 检查 TypeScript 编译、stylelint、eslint 等 CI 有没有开启
-- [ ] TypeScript 里 any 的使用，杜绝滥用 any
-- [ ] XSS 问题要特别注意，React 里主要关注 dangerouslySetInnerHTML 的使用
-- [ ] 检查是否不必要的全局覆盖了 antd 的组件样式
-- [ ] 检查是否使用 css-modules，避免全局样式类名污染
-- [ ] 检查外部依赖是否有更好的推荐选择
-
-**安全性**：
-- [ ] RDS、安全服务化、CSRF
-- [ ] 超链接设置`target="_blank"` 会有安全隐患
-- [ ] package.json 依赖：锁版本、安全扫描
-
-**组件与设计**：
-- [ ] 功能实现：与 Pull Request 中描述功能一致，对其他模块无影响
-- [ ] 组件设计：需要考虑层级、职能、通信、函数式
-- [ ] 注意代码复杂度、如何最优解、代码复用需要按需引用
-- [ ] 代码血缘性：代码之间的相互关联性、依赖关系、联动关系
-- [ ] Fail Fast 原则
-- [ ] 检查对代码体积的影响，没有按需 import，或引入过大的第三方依赖
-
-**体验相关**：
-- [ ] 加载性能
-- [ ] 异常反馈
-- [ ] 动画效果：降级方案、性能体验是否影响
-- [ ] 交互反馈：防重复、使用动画
-- [ ] 兼容性：浏览器兼容性、端兼容性、JSAPI 兼容性
-
-**前端常见易犯错内容**：
-- 元素 id 自动变成全局变量
-- 前端做金额计算
-- for..in..数组
-- typeof null === 'object'
-- url 包含 ASCII 字符处理
-- 正则全局匹配
-- 服务端返回字符"1"、"true"
-
-#### 算法特有评审要点
-
-- [ ] 数据链路有效性确认，埋点正常，回流正常，样本正常
-- [ ] 从业务中引入常数需要确认，需显式文档注明用途和有效期限
-- [ ] 确认引入特征的质量，缺失值比例，更新稳定性
-- [ ] 确认特征数据维护者
-- [ ] 基于线上实际效果定期评估特征效果，去除低效特征
-- [ ] 确保验证集和训练集/测试集之间的日期隔离
-- [ ] 合理解决样本数据的 bias 和 imbalance
-- [ ] 合理解决 Training-Serving Skew
-- [ ] 合理融合业务知识
-- [ ] 合理融合多个模型
-
-### 4.3 可扩展性
-
-#### 定义
-代码编写设计能应对持续变化的业务需求。
-
-#### 后端评审要点
-
-- [ ] **可扩展性**：功能是否可以继续扩展支撑业务快速迭代
-- [ ] 共享对象的访问是否会成为热点
-- [ ] 是否会成为并发瓶颈
-- [ ] 锁粒度是否合理
-
-#### 前端评审要点
-
-- [ ] 对外协议清晰一致
-- [ ] 方便增加新特性
-- [ ] 谨慎增加新属性
-
-#### 算法评审要点
-
-- [ ] 对关键算法良好封装
-- [ ] 以第三方调用的方式使用算法
-- [ ] 保证算法的独立性和可复用性
-
----
-
-## 五、Code Review 检查清单
-
-### 5.1 评审前检查（发起人）
-
-**代码准备**：
-- [ ] 完成自测
-- [ ] 完成自主 Review
-- [ ] 运行静态分析工具扫描
-- [ ] 单元测试通过
-- [ ] 代码覆盖率达标
-
-**信息准备**：
-- [ ] 写清楚标题（符合规范）
-- [ ] 写清楚描述（包含所有必要信息）
-- [ ] 附上需求文档链接
-- [ ] 附上系分设计文档链接
-- [ ] 说明测试情况
-
-**人员准备**：
-- [ ] 邀请对代码熟悉的同学
-- [ ] 邀请对业务熟悉的同学
-- [ ] 必要时邀请质量同学
-- [ ] 给评审人打招呼说明期望
-
-### 5.2 可读性检查
-
-**命名与注释**：
-- [ ] 变量命名清晰表达用途
-- [ ] 函数命名符合规范
-- [ ] 类命名符合规范
-- [ ] 注释解释"为什么"而非"是什么"
-- [ ] 类和函数注释完整
-
-**代码结构**：
-- [ ] 代码风格与团队一致
-- [ ] 函数长度合理（建议<50 行）
-- [ ] 嵌套层次不超过 2 层
-- [ ] if 分支不超过 5 个
-- [ ] 没有为了性能而写的晦涩代码
-
-**业务规范**：
-- [ ] 金额有明确单位和币种
-- [ ] 金额计算使用专用类型
-
-### 5.3 可靠性检查
-
-**线程安全**：
-- [ ] 全局变量使用合理
-- [ ] static 变量使用合理
-- [ ] 共享对象有锁保护
-- [ ] 无死锁风险
-- [ ] 线程同步机制清晰
-
-**安全性**：
-- [ ] 有水平权限校验
-- [ ] 后端接口校验入参
-- [ ] 异常不被吞掉
-- [ ] 对象比较使用 equals
-- [ ] 状态处理遵守一锁二判断三处理
-- [ ] 有超时时间设置
-
-**功能性**：
-- [ ] 单元测试覆盖完整
-- [ ] 覆盖边界和异常情况
-- [ ] 需求实现完整
-- [ ] 向后兼容
-
-**性能**：
-- [ ] SQL 有 where 条件
-- [ ] SQL 不使用 select *
-- [ ] SQL 走索引
-- [ ] 无慢 SQL 风险
-- [ ] 无数据热点风险
-
-**异常处理**：
-- [ ] 日志级别准确
-- [ ] 不吞掉错误码
-- [ ] 极端情况处理合理
-- [ ] 资源释放正确
-
-**可维护性**：
-- [ ] 区分成功/失败/未知异常
-- [ ] 有幂等性控制
-- [ ] 无硬编码
-- [ ] 无死代码
-- [ ] 有 TODO 标识
-- [ ] 使用统一封装的第三方库
-
-### 5.4 可扩展性检查
-
-- [ ] 功能可继续扩展
-- [ ] 无并发瓶颈
-- [ ] 锁粒度合理
-- [ ] 对外协议清晰
-- [ ] 方便增加新特性
-
-### 5.5 其他检查
-
-- [ ] 考虑了灰度方案
-- [ ] 考虑了监控方案
-- [ ] 考虑了应急方案
-- [ ] 无已知缺陷
-- [ ] 无重复代码
-
----
-
-## 六、CR 最佳实践
-
-### 6.1 发起人最佳实践
-
-**1. 代码拆分**
-- 保持每次提交在 100 行左右
-- 职责单一，功能独立
-- 通过分支命名体现步骤
-
-**2. 自我检查**
-- 发起 CR 前自己先 Review 一遍
-- 运行静态分析工具
-- 确保测试通过
-- 检查代码覆盖率
-
-**3. 信息完整**
-- 标题简洁明了
-- 描述详细完整
-- 附上相关文档链接
-- 说明重点关注内容
-
-**4. 积极沟通**
-- 提前通知评审人
-- 说明期望和紧急度
-- 及时响应评审意见
-- 保持谦逊态度
-
-### 6.2 评审人最佳实践
-
-**1. 及时响应**
-- 24 小时内响应
-- 无法完成全部评审时给出初步反馈
-- 不要让发起人等待过久
-
-**2. 有效反馈**
-- 反馈前三问：是否正确、是否必要、是否可读
-- 抓住重点，不苛求完美
-- 使用第一人称
-- 围绕代码讨论，不指责人
-
-**3. 正向激励**
-- 发现好的代码要表扬
-- 学习他人优秀实践
-- 分享给团队其他成员
-
-**4. 合理判断**
-- 只要有质量提升就应通过
-- 不要苛求完美
-- 意见冲突时面对面沟通
-- 必要时升级到 TL 决策
-
-### 6.3 团队最佳实践
-
-**1. 建立 CR 文化**
-- CR 是学习和成长的过程
-- CR 是团队协作的机会
-- CR 是代码文化的体现
-
-**2. 制定团队规范**
-- 统一代码风格
-- 统一提交格式
-- 统一评审标准
-
-**3. 工具支持**
-- 使用静态分析工具
-- 配置 CI/CD 流程
-- 集成代码覆盖率检查
-
-**4. 持续改进**
-- 定期回顾 CR 效果
-- 总结常见问题
-- 更新团队规范
-
----
-
-## 七、常见问题 FAQ
-
-### Q1: 代码模块多大合适 CR？
-**A**: 通常保持在**100 行左右**较为合理。过大的代码块会降低评审效率和质量。
-
-### Q2: 评审人应该多久响应？
-**A**: 应在**工作日 24 小时内**响应。如无法完成全部评审，应给出初步反馈。
-
-### Q3: 什么时候应该评审通过？
-**A**: 满足以下条件：功能实现达标、代码设计合理、单元测试通过、测试覆盖率达标。只要有质量提升就应通过，不要苛求完美。
-
-### Q4: 评审意见冲突怎么办？
-**A**: 先面对面沟通，无法解决则升级到更广泛团队讨论，或让 TL 参与决策。
-
-### Q5: 发起人和评审人可以是同一人吗？
-**A**: **不可以**。根据《风险防范基本条例》，代码评审发起人和评审人不能是同一人。
-
-### Q6: 是否所有代码都要 CR？
-**A**: **是的**。根据规定，原则上需覆盖所有变更到线上的代码。
-
-### Q7: 评审人应该帮发起人改代码吗？
-**A**: **不应该**。评审人应该指导改进方向，但不要直接帮助改动代码。
-
-### Q8: 如何处理历史遗留代码？
-**A**: 只评审本次变更的代码。如果发现历史问题，可以建议单独提 issue 改进。
-
-### Q9: 单元测试覆盖率要求多少？
-**A**: 本次变更行的测试覆盖率应 **≥ 工程整体的测试覆盖率**。
-
-### Q10: CR 中发现的代码疫苗怎么处理？
-**A**: 代码疫苗是质量检测机制。发现后应该识别并评论，证明 CR 执行到位。
-
----
-
-## 八、附录
-
-### 8.1 术语表
-
-| 术语 | 说明 |
-|------|------|
-| CR | Code Review，代码评审 |
-| PR | Pull Request，合并请求 |
-| MR | Merge Request，合并请求 |
-| 代码疫苗 | 通过代码注入检测 CR 质量的机制 |
-| 三板斧 | 灰度、监控、应急三个关键环节 |
-| 一锁二判断三处理 | 并发控制原则 |
-
-### 8.2 参考资料
-
-1. **《风险防范基本条例》** - 代码评审强制要求
-2. **Conventional Commits** - 提交信息格式规范
-3. **前端研发框架最佳实践** - 前端开发规范
-4. **编码规范** - `knowledge/07-standards/00-coding-style.md`
-5. **数据一致性规范** - `knowledge/07-standards/02-data-consistency.md`
-
----
-
-## 九、AI 增强 Code Review
-
-> 本章节定义如何利用 AI 增强代码审查流程。
-> 与 [organization/01-ai-native-culture.md](../organization/01-ai-native-culture.md) 中的多代理审查系统互补。
-
-### 9.1 AI 审查角色定义
-
-| 角色 | 职责 | 检查维度 |
-|------|------|---------|
-| **架构审查 Agent** | 检查代码架构合理性 | 模块划分、依赖关系、扩展性 |
-| **安全审查 Agent** | 检查安全漏洞 | 注入、越权、敏感数据 |
-| **性能审查 Agent** | 检查性能问题 | 复杂度、N+1、缓存 |
-| **可维护性 Agent** | 检查代码质量 | 重复、命名、注释 |
-| **逻辑审查 Agent** | 检查业务逻辑 | 条件分支、边界处理 |
-
-### 9.2 AI 审查流程
-
-```
-代码变更提交
-       ↓
-并行启动多个审查 Agent
-       ↓
-     ├── 架构审查 → 问题列表 A
-     ├── 安全审查 → 问题列表 B
-     ├── 性能审查 → 问题列表 C
-     ├── 可维护性审查 → 问题列表 D
-     └── 逻辑审查 → 问题列表 E
-       ↓
-结果汇总
-       ↓
-     ├── 一致通过项
-     ├── 需修复项（按严重程度排序）
-     └── 需人工确认项
-       ↓
-人类最终确认
-       ↓
-     ├── 通过 → 合并
-     └── 不通过 → 反馈修正
-```
-
-### 9.3 AI 审查清单
-
-#### 安全检查项（AI 自动完成）
-
-| 检查项 | AI 能力 | 严重程度 |
-|--------|---------|---------|
-| SQL 注入 | ★★★★★ | 致命 |
-| XSS 跨站脚本 | ★★★★★ | 致命 |
-| CSRF | ★★★★★ | 致命 |
-| 越权访问 | ★★★★★ | 致命 |
-| 敏感数据泄露 | ★★★★★ | 致命 |
-| 硬编码密码/密钥 | ★★★★★ | 致命 |
-| 命令注入 | ★★★★★ | 致命 |
-
-#### 逻辑检查项（AI 自动完成）
-
-| 检查项 | AI 能力 | 严重程度 |
-|--------|---------|---------|
-| 空指针处理 | ★★★★☆ | 高 |
-| 边界条件 | ★★★★☆ | 高 |
-| 并发安全 | ★★★☆☆ | 高 |
-| 异常处理 | ★★★★☆ | 中 |
-| 业务逻辑正确性 | ★★★☆☆ | 中 |
-
-#### 性能检查项（AI 自动完成）
-
-| 检查项 | AI 能力 | 严重程度 |
-|--------|---------|---------|
-| N+1 查询 | ★★★★☆ | 高 |
-| 全表扫描 | ★★★★☆ | 高 |
-| 内存泄漏 | ★★★☆☆ | 中 |
-| 循环效率 | ★★★★☆ | 中 |
-
-#### 可维护性检查项（AI 自动完成）
-
-| 检查项 | AI 能力 | 严重程度 |
-|--------|---------|---------|
-| 代码重复 | ★★★★★ | 低 |
-| 命名规范 | ★★★★★ | 低 |
-| 注释完整性 | ★★★★☆ | 低 |
-| 函数长度 | ★★★★☆ | 低 |
-
-### 9.4 AI 审查配置
-
-```yaml
-# .ai-review.yaml
-review:
-  enabled: true
-
-  agents:
-    - type: architecture
-      enabled: true
-    - type: security
-      enabled: true
-    - type: performance
-      enabled: true
-    - type: maintainability
-      enabled: true
-    - type: logic
-      enabled: true
-
-  thresholds:
-    critical: 0    # 致命问题数量上限
-    high: 3        # 高危问题数量上限
-    medium: 10     # 中危问题数量上限
-
-  auto_fix:
-    enabled: true
-    types:
-      - style
-      - formatting
-      - simple_logic
-```
-
-### 9.5 与人类审查的协作
-
-#### AI 擅长领域
-
-- 大规模代码扫描
-- 模式匹配（安全漏洞、代码异味）
-- 风格一致性检查
-- 重复检测
-
-#### 人类擅长领域
-
-- 业务逻辑理解
-- 架构决策判断
-- 上下文理解
-- 创新/设计选择
-
-#### 协作模式
-
-```
-AI 预审（快速扫描） → 人类重点审查（AI 发现的问题）
-```
-
-1. **AI 先行**：AI 快速扫描，发现明显问题
-2. **人类聚焦**：人类聚焦于 AI 难以判断的领域
-3. **结果合并**：AI 发现 + 人类发现 = 完整审查
-
-### 9.6 最佳实践
-
-#### AI 审查最佳实践
-
-1. **不盲目信任 AI**：所有 AI 产出必须经过人类验收
-2. **选择合适场景**：AI 擅长模式匹配，人类擅长设计判断
-3. **持续优化提示词**：根据审查效果迭代 AI 提示
-4. **记录误报**：建立误报知识库，持续优化
-
-#### AI 审查反模式
-
-1. **完全依赖 AI**：安全问题也交给 AI，不做最终确认
-2. **忽视 AI 建议**：AI 发现问题不处理
-3. **不优化提示词**：提示词长期不更新
-
----
-
-**文档版本**：V1.1
-**更新日期**：2026-03-26
-**适用范围**：所有项目 Code Review
-**维护团队**：技术质量团队
-
----
-
-## 结语
-
-Code Review 不仅是代码质量保证的重要手段，更是工程师文化建设和团队成长的重要途径。
-
-**核心理念**：
-- CR 是学习和成长的过程
-- CR 是团队协作的机会
-- CR 是代码文化的体现
-
-**三个关键原则**：
-1. **及时响应** - 24 小时内反馈
-2. **抓住重点** - 不苛求完美
-3. **持续改进** - 从 CR 中学习
-
-让我们一起通过高质量的 Code Review，打造卓越的代码文化！