prompt: 我们公司目前在搞 AI 提效，现在我即将负责一个点，就是“AI辅助代码检视”。我们的代码都是放在开源平台 gitcode。我给你讲下我们的开发流程。我们公司分 3 个区，分别是B区，Y区和 G区，信息流通的方式是：B区 -> G区 -> Y区。只能单向流动，而不能反过来。正常的开发流程是在 B 区 fork 开源仓代码到自己的仓，记为 private-repo，然后 clone 下来开发。开发好后，提交到 private-repo。然后去 G 区/Y区，在设备上 clone 下来自己的 private-repo，进行验证。如果需要修改，则还需要在 B 区修改，然后 push 到 private-repo，再到 G区/Y区 clone 下来验证。直到验证Ok。然后从 private-repo 提 PR 到公共的仓库，接受大家检视，最后合入。你帮我看看，这种开发流程中，我在哪些点可以使用到 “AI 辅助代码检视”来提升效率呢？

这边和豆包交流了一下，我理解基于我们当前的情况，应该是在 2 个点去部署 AI 检视：


 +++++++++++++++++     1. fork     +++++++++++++++++        4. pull
 |               | --------------> |               | ---------------------+
 | public-repo   |     5. pr       | private-repo  |                      |
 |               | <-------------- |               |                      |
 +++++++++++++++++                 +++++++++++++++++                      |
                                        |    ^                            |
                               2.  pull |    | 3. push                    |
                                        v    |                            v
                                   +++++++++++++++++                   +++++++++++++++++
                                   |               |                   |               |
                                   | B zone        |                   | Y/G zone      |
                                   |               |                   |               |
                                   +++++++++++++++++                   +++++++++++++++++

在第 3 处和第 5 处部署即可：

  • 第一步：B 区 commit 前 pre-commit 钩子 → 拦基础规范 / 语法问题（和 3 步版一致）；
  • 第二步：提 PR 后 webhook → 全维度检视（增加跨区适配检视项），一次检视覆盖「基础问题 + 跨区问题 + 核心问题」； 适配点：gitcode 的 PR 增量 diff 能完整识别所有修改，合并检视项后，仅需 1 次 AI 调用

在决定在哪里部署后，接下来要看具体如何实现。

首先，我觉得代码开发主要分为这 3 类问题：

  • 规范类问题，比如函数和变量命名是否规范，使用 try...catch 语法时是否符合业界的最佳实践等等。
  • 业务功能性问题，比如当前的实现是否有场景遗漏
  • 程序架构上的问题，比如函数和类的组织是否合理，代码是否满足面向对象的七大原则（单一职责，开闭原则，依赖倒置，里氏替换法则，迪米特法则，接口隔离，合成复用），是否可以使用设计模式去重构。

有了这 3 类问题后，我们如何针对这 3 类问题做 AI 辅助检视呢？

对于规范类问题，主要的步骤如下：

  • 编程标准结构化，而不是纯文本投喂，把它拆解成“规则条目 + 示例 + 反例”的结构化 prompt。
  • 规范类问题可以结合静态分析工具，做“AI+工具”双校验，意思是用现成工具先扫一遍，AI 再做补充检验。这样做可以减少 AI 的计算成本。

对于业务功能类问题，核心是让 AI 懂业务，主要是因为 AI 缺乏上下文。主要的步骤如下：

  • 第一步，提前沉淀“业务知识库”，作为 AI 的固定 skill，意思就是说，让 AI 先懂我们的业务场景，我理解类似于 Claude Code 使用 /init 命令先生成一个 Claude.md，作为它对整个项目的理解，这个理解不会太细，但是会对项目有个整体性的把握。
  • 第二步，检视时绑定“代码对应的业务场景”，这一步可以要求在 commit 信息/PR 描述中注明“本次修改对应的业务场景”，AI 结合这个场景，就可以精准判断了。第三步；结合“历史问题库”，做场景化的查漏补缺。

对于架构类问题，主要的步骤是：

  • 第一步，让 AI 自动生成“项目架构文档”，而非手动编写。
  • 第二步，架构检视分 2 层，“局部代码合规性“ + ”全局架构一致性“。让 AI 基于架构文档，做 2 层检视，局部层，查看当前修改是否OK；整体层，查看当前修改是否影响项目的整体结构- 第三步，聚焦”增量架构问题“，不做全量复盘。每次 PR 来了只看增量代码。

一些具体实施的注意事项： 1、无论哪类问题，AI 输出的结果都要包含：

  • 问题类型（规范/功能/架构）
  • 问题代码行 + 问题描述
  • 风险等级（高/中/低）
  • 具体修改建议（详细说明）

2、分阶段开放检视能力，避免初期误报过多

3、建议“反馈闭环”，让 AI 越用越准

接下来，我需要了解一些工具的用法：