前言

在软件开发流程中，代码审核是确保代码质量的关键环节。传统的代码审核通常依赖于团队成员之间的相互审查，这不仅耗时，而且可能受到审核者经验和专业知识的限制。随着生成式 AI 的发展，越来越多的团队，也开始借助生成式 AI 的能力进行代码审核。

Amazon Q Developer 是亚马逊推出的专为专业开发人员设计的人工智能助手，旨在提升代码开发和管理效率。其主要功能包括代码生成、调试、故障排除和安全漏洞扫描，提供一站式代码服务。本文主要介绍其代码审核的能力。你可以在亚马逊云科技控制台、IDE 插件、以及命令行工具（CLI）等地方中使用到 Amazon Q Developer。Amazon Q Developer for IDE 可以作为开发人员开发过程中自检的审核助手；在开发阶段进行代码质量提升，而 Amazon Q Developer for CLI 提供了命令行工具，让企业可以结合自有的 CI/CD 流程进行代码审核。

使用 Amazon Q Developer 进行自动化的代码审核方案，具有以下优势：

• 一致性：应用统一的代码审核标准

• 效率：快速完成审核，减少人工审核时间

• 全面性：能够检查多方面的问题，包括代码风格、质量、安全性等

• 可集成性：可以轻松集成到 CI/CD 流程中

• 持续学习：基于大量代码库训练，能够识别最新的最佳实践

而 Amazon Q Developer For CLI 在命令行界面中已集成了上下文感知、环境感知、Agent 执行等多种能力，比起直接调用大模型，可减少企业集成时的工程化时间，不必再重复造轮子。

接下来，我们将介绍两个场景的代码审核场景：（1）在开发过程中进行代码审核；（2）在 CI/CD 过程中使用 Amazon Q Developer 进行代码审核。本文不再针对如何安装 Amazon Q Developer 等进行介绍，您可以参考官方文档进行安装（在 IDE 中安装 Amazon Q/在命令行中安装 Amazon Q）。同时 Amazon Q Developer 分为个人用户和企业用户，由于个人用户每月有一定限额，建议在企业内部使用企业用户以获取更多的使用额度。

1. 开发期间 – Amazon Q Developer IDE

Amazon Q Developer 可以检查您的代码库中是否存在安全漏洞和代码质量问题，以改善应用程序在整个开发周期中的状况。

Amazon Q 会检查您的代码是否存在以下类型的代码问题：

• SAST 扫描 – 检测源代码中的安全漏洞。Amazon Q 可识别各种安全问题，例如资源泄漏、SQL 注入和跨站脚本。

• 机密检测 – 防止泄露代码中的敏感或机密信息。Amazon Q 会检查您的代码和文本文件中是否有硬编码密码、数据库连接字符串和用户名等机密。机密调查结果包括有关未受保护的机密以及如何保护它的信息。

• IaC 问题 – 评估基础架构文件的安全状况。Amazon Q 可以审查您的基础设施即代码（IaC）代码文件，以检测配置错误、合规性和安全问题。

• 代码质量问题 – 确保您的代码符合质量、可维护性和效率标准。Amazon Q 会生成与各种质量问题相关的代码问题，包括但不限于性能、机器学习规则和 AWS 最佳实践。

• 代码部署风险 – 评估与部署代码相关的风险。Amazon Q 会确定部署或发布您的代码是否存在任何风险，包括应用程序性能和操作中断。

• 软件组成分析（SCA）- 评估第三方代码。Amazon Q 会检查集成到您的代码中的第三方组件、库、框架和依赖关系，确保第三方代码是安全和最新的。

如需查看 Amazon Q 用于审查您的代码的探测器的完整列表，请参阅 Amazon Q 探测器库。

当你编写代码时，Amazon Q Developer 会自动审查您正在编写的文件，一旦在您的代码中检测到代码问题，就会立即生成代码问题。当 Amazon Q 执行自动审查时，它不会生成就地代码修复。当您使用 Amazon Q 时，自动审核默认处于启用状态。我们也可以在 IDE 的 Amazon Q chat 框中手动执行/review，进行代码审核。以下为一个演示（可点击查看大图）

2. CI/CD 期间 – Amazon Q Developer CLI

以下为使用 Amazon Q Developer CLI 进行代码审核的效果（可点击查看大图）：

以下是代码审核结果的样例，实际生产中我们可以对审核规则，以及审核报告格式进行自定义：

多文件代码审核报告

总体项目评估

这是一个电子钱包项目，包含 AWS Lambda 函数和 GitLab CI/CD 配置。整体代码质量中等，但存在一些需要改进的地方，包括安全性、错误处理和代码质量方面的问题。

文件概览

1. .gitlab-ci.yml - CI/CD 配置文件 - 3 个问题

2. ewallet/controller/balance.py - 钱包余额查询 Lambda 函数 - 4 个问题

3. put_comment.py - GitLab MR 评论脚本 - 2 个问题

详细文件审核

.gitlab-ci.yml

总体评估

该文件定义了 GitLab CI/CD 流程，包括构建和代码审核阶段。整体结构清晰，但存在一些安全和配置问题。

问题清单

CI-001: 硬编码的 AWS 账号和区域

严重程度: 严重类型: 安全位置: .gitlab-ci.yml:7-8 描述: CI 配置中硬编码了 AWS 账号 ID 和区域信息。原因: 硬编码的凭证和配置信息可能导致安全风险，并使配置难以在不同环境中重用。修复建议:

# 原代码
login_ecr:
  stage: build
  script:
    - aws ecr get-login-password --region us-west-2 | docker login --username AWS --password-stdin xxxxxxx.dkr.ecr.us-west-2.amazonaws.com

可以修改为:

# 修改后的代码
login_ecr:
  stage: build
  script:
    - aws ecr get-login-password --region ${AWS_REGION} | docker login --username > AWS --password-stdin ${AWS_ACCOUNT_ID}.dkr.ecr.${AWS_REGION}.amazonaws.com

修改说明: 使用环境变量替代硬编码的 AWS 账号和区域，提高安全性和可移植性。

CI-002: 缺少作业依赖关系

严重程度: 一般类型: 可维护性位置: .gitlab-ci.yml 描述: 作业之间没有明确的依赖关系定义。原因: 缺少依赖关系可能导致作业执行顺序不正确，特别是当流水线变得更复杂时。修复建议:使用needs关键字定义作业依赖关系：

amazon-q-code-review:
  stage: review
  needs:
    - login_ecr
  # 其他配置...

修改说明: 添加明确的依赖关系可以确保作业按照预期顺序执行，提高流水线的可靠性。

CI-003: 镜像引用使用硬编码值

严重程度: 一般类型: 可维护性位置: .gitlab-ci.yml:39 描述: Docker 镜像引用使用了硬编码的 URI。原因: 硬编码的镜像引用使配置难以在不同环境中重用，并可能导致维护问题。修复建议:

# 原代码
  image: xxxx.dkr.ecr.us-west-2.amazonaws.com/cicdtest:latest 

可以修改为:

# 修改后的代码
  image: ${ECR_REPOSITORY_URI}/cicdtest:latest

修改说明: 使用环境变量替代硬编码的镜像 URI，提高配置的可移植性和可维护性。

ewallet/controller/balance.py

总体评估

这是一个 Amazon Lambda 函数，用于查询钱包余额。代码结构清晰，但存在一些安全和错误处理方面的问题。

问题清单

BAL-001: 安全风险 - 错误消息泄露内部信息

严重程度: 严重类型: 安全位置: ewallet/controller/balance.py:54-62 描述: 在错误处理中，直接将异常信息返回给客户端。原因: 暴露详细的异常信息可能会泄露系统内部结构，为攻击者提供有用信息。修复建议:

# 原代码
except ClientError as e:
    return {
        'statusCode': 500,
        'headers': {
            'Content-Type': 'application/json',
            'Access-Control-Allow-Origin': '*'
        },
        'body': json.dumps({
            'message': f'Internal server error: {str(e)}'
        })
    }

可以修改为:

# 修改后的代码
except ClientError as e:
    # 记录详细错误信息供内部使用
    print(f"Error accessing DynamoDB: {str(e)}")
    return {
        'statusCode': 500,
       'headers': {
            'Content-Type': 'application/json',
            'Access-Control-Allow-Origin': '*'
        },
        'body': json.dumps({
            'message': 'Internal server error occurred. Please try again later.'
        })
    }

修改说明: 记录详细错误信息供内部调试使用，但向客户端返回通用错误消息，避免泄露系统内部信息。

BAL-002: 缺少输入验证

严重程度: 严重类型: 安全位置: ewallet/controller/balance.py:18-19 描述: 函数直接使用路径参数而没有进行验证。原因: 缺少输入验证可能导致安全漏洞，如注入攻击或意外行为。修复建议:

# 原代码
# Get wallet ID from path parameters
wallet_id = event['pathParameters']['id']

可以修改为:

# 修改后的代码
# Get wallet ID from path parameters
if not event.get('pathParameters') or 'id' not in event.get('pathParameters', {}):
    return {
        'statusCode': 400,
       'headers': {
            'Content-Type': 'application/json',
            'Access-Control-Allow-Origin': '*'
        },
        'body': json.dumps({
            'message': 'Missing wallet ID'
        })
    }
wallet_id = event['pathParameters']['id']
# 验证wallet_id格式是否正确（例如UUID格式）
if not wallet_id or not isinstance(wallet_id, str) or len(wallet_id) > 100:
    return {
        'statusCode': 400,
        'headers': {
            'Content-Type': 'application/json',
            'Access-Control-Allow-Origin': '*'
        },
        'body': json.dumps({
            'message': 'Invalid wallet ID format'
        })
    }

修改说明: 添加输入验证，确保路径参数存在且格式正确，防止潜在的安全问题。

BAL-003: 缺少日志记录

严重程度: 一般类型: 可维护性位置: ewallet/controller/balance.py 描述: 代码中没有适当的日志记录，这会使问题排查变得困难。原因: 缺少日志记录会使系统运行状态不透明，难以监控和调试。修复建议:添加适当的日志记录：

import logging
logger = logging.getLogger()
logger.setLevel(logging.INFO)
def lambda_handler(event, context):
    logger.info(f"Processing request for wallet balance. Event: > {json.dumps(event)}")
    try:
        # 现有代码...
        logger.info(f"Retrieved wallet details for ID: {wallet_id}")
        # 返回结果...
    except ClientError as e:
        logger.error(f"DynamoDB error when retrieving wallet {wallet_id}: {str(e)}")
        # 错误处理...
    except Exception as e:
        logger.error(f"Unexpected error: {str(e)}")
        return {
            'statusCode': 500,
            'headers': {
                'Content-Type': 'application/json',
                'Access-Control-Allow-Origin': '*'
            },
            'body': json.dumps({
                'message': 'Internal server error occurred'
            })
        }

修改说明: 添加结构化日志记录，包括请求信息、处理结果和错误情况，便于监控和问题排查。

BAL-004: 缺少通用异常处理

严重程度: 一般类型: 错误处理位置: ewallet/controller/balance.py:17 描述: 只捕获了 ClientError，没有处理其他可能的异常。原因: 未处理的异常可能导致 Lambda 函数崩溃，影响用户体验。修复建议:

# 原代码
try:
    # 业务逻辑...
except ClientError as e:
    # 错误处理...

可以修改为:

# 修改后的代码
try:
    # 业务逻辑...
except ClientError as e:
    # 特定错误处理...
except Exception as e:
    # 记录未预期的异常
    print(f"Unexpected error: {str(e)}")
    return {
        'statusCode': 500,
        'headers': {
            'Content-Type': 'application/json',
            'Access-Control-Allow-Origin': '*'
        },
        'body': json.dumps({
            'message': 'Internal server error occurred'
        })
    }

修改说明: 添加通用异常处理，确保即使发生未预期的错误，函数也能返回适当的响应而不是崩溃。

put_comment.py

总体评估

这是一个用于向 GitLab 合并请求添加评论的脚本。代码简单明了，但存在一些错误和安全问题。

问题清单

PC-001: 未定义的变量引用

严重程度: 阻塞类型: 功能位置: put_comment.py:19 描述: 脚本尝试使用未定义的变量comment_body。原因: 这是一个编程错误，会导致脚本运行失败。修复建议:

# 原代码
response = requests.post(url, headers=headers, json={"body": comment_body})

可以修改为:

# 修改后的代码
response = requests.post(url, headers=headers, json={"body": yaml_content})

修改说明: 使用已读取的yaml_content变量替代未定义的comment_body变量。

PC-002: 敏感信息处理不当

严重程度: 严重类型: 安全位置: put_comment.py:8 描述: 使用环境变量REGISTRATION_TOKEN作为 GitLab API 的私有令牌。原因: 使用注册令牌而非专用 API 令牌可能导致权限过大，增加安全风险。修复建议:

# 原代码
private_token = os.environ.get("REGISTRATION_TOKEN")

可以修改为:

# 修改后的代码
private_token = os.environ.get("GITLAB_API_TOKEN")

修改说明: 使用专门的 API 令牌环境变量，而不是复用注册令牌，遵循最小权限原则。

跨文件问题

CROSS-001: 配置文件命名不一致

严重程度: 一般类型: 可维护性位置: changes.txt 中列出了.gitlab-ci.yml和gitlab-ci.yaml描述: 项目中同时引用了两种不同命名的 GitLab CI 配置文件。原因: 配置文件命名不一致可能导致混淆，并可能在某些情况下导致 CI/CD 流程失败。修复建议: 统一使用.gitlab-ci.yml作为配置文件名，并删除或重命名gitlab-ci.yaml文件。

总体改进建议

1、 增强安全性: 避免硬编码凭证和敏感信息，使用环境变量或安全的凭证管理服务。

2、 改进错误处理: 在所有代码中实现全面的错误处理，包括输入验证和适当的异常捕获。

3、 添加日志记录: 在关键操作点添加结构化日志，有助于问题诊断和性能监控。

4、 代码标准化: 确保配置文件命名和引用的一致性，避免混淆。

5、 添加单元测试: 为 Lambda 函数添加单元测试，提高代码质量和可靠性。

6、 使用环境变量: 将硬编码的配置值替换为环境变量，提高代码的可移植性和安全性。

7、 实施代码审查流程: 建立正式的代码审查流程，确保代码质量和安全性标准得到维护。

接下来，我将详细介绍如何通过 GitLab CI/CD 流程集成 Amazon Q CLI 来实现自动化代码审核。

2.1 代码审核的前提条件

• 亚马逊云科技账户并已启用 Amazon Q Developer

• GitLab 环境，配置好 GitLab Runner，适用于 GitLab api 调用的相关 token

• Docker 环境

• Amazon ECR 仓库用于存储自定义 Docker 镜像

• S3 桶，可以访问此 S3 桶的用户或者角色

• 本节所用代码均可在此 Github 仓库中找到。代码结构如下：

├── .gitlab-ci.yml #gitlab cicd 所用的pipeline├── Dockerfile # gitlab pipeline运行时所用docker 镜像├── ewallet # 测试使用的代码├── improve_rules # 审核规则│   ├── improved_code_review_standards_part1.md #包含一般原则、代码审查流程和检查清单的第一部分（代码风格和代码质量）│   ├── improved_code_review_standards_part2.md #包含功能实现、安全性和性能部分│   ├── improved_code_review_standards_part3.md #包含测试、日志记录、可维护性和特定场景，如并发、事务、幂等性和远程调用│   ├── improved_code_review_standards_part4.md #包含语言特定的检查点、中间件使用指南、通信指南、工具推荐和持续改进│   └── llm_code_review_feedback_format.md # 审核报告规则└── put_comment.py # 审核结束调用api填写评论的代码

接下来，您可以参考以下步骤，在团队中实现使用 Amazon Q developer CLI 协助实现代码审核。

2.2 整体流程

实现基于以下流程：

1. 开发者提交代码或创建合并请求

2. GitLab CI/CD 流程触发

3. 使用预配置的 Docker 镜像运行 Amazon Q Developer CLI 进行代码审核

4. Amazon Q Developer CLI 分析代码变更并生成审核报告

5. 审核结果作为评论添加到合并请求中

2.3 环境准备

2.3.1 Amazon Q Developer CLI 登录权限

Amazon Q developer CLI 目前需要交互性登录，但对于审核流程，我们需要将登录自动化，因此我们需要将认证后的凭据给到 Gitlab runner 使用。首先我们需要找一台服务器，以 Linux（Ubuntu）为例，安装并登录 Amazon Q（登录过程参考此文档），登录后凭据存储在~/.local/share/amazon-q/。

为了对 CI/CD 上下文进行身份验证，我们需要将其持久化到某个共享位置。我在这个例子中使用了 S3，但这包含敏感数据，因此建议使用 S3 VPC 端点，并限制对此 S3 桶的访问权限来源，比如限定 IP 等等。

使用以下命令将凭据上传到 S3：

aws s3 sync ~/.local/share/amazon-q s3://<amazon-q-bucket>/amazonq-credentials/amazon-q #<amazon-q-bucket>替换为你自己的S3桶，并记录这个地址

2.3.2 Docker 镜像准备

我们需要创建一个包含 Amazon Q CLI 和必要工具的 Docker 镜像，作为 GitLab pipeline 运行的环境，其 Dockerfile 如下：

# 基于Ubuntu 22.04FROM ubuntu:22.04# 避免交互式提示ENV DEBIAN_FRONTEND=noninteractive# 安装必要的软件包RUN apt-get update && \    apt-get install -y \    curl \    git \    jq \    python3 \    python3-pip \    apt-transport-https \    ca-certificates \    gnupg \    lsb-release \    software-properties-common \    sudo && \    rm -rf /var/lib/apt/lists/*# 添加GitLab Runner仓库RUN curl -L "https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh" | bash# 安装GitLab Runner# 如果要安装指定版本的runner，类似于apt install gitlab-runner=17.7.1-1RUN apt-get update && \    apt-get install -y gitlab-runner && \    rm -rf /var/lib/apt/lists/*# 安装AWS CLIRUN pip3 install --no-cache-dir awscli requests && pip install requests# 安装Amazon Q CLIRUN curl --proto '=https' --tlsv1.2 -sSf https://desktop-release.q.us-east-1.amazonaws.com/latest/amazon-q.deb -o amazon-q.deb && \    apt-get update && \    apt-get install -y ./amazon-q.deb && \    rm amazon-q.deb && \    rm -rf /var/lib/apt/lists/*# 创建配置目录RUN mkdir -p /etc/gitlab-runner

镜像中包含：

• Amazon Q CLI

• Amazon CLI

• Git

• Python 环境

将此 Dockerfile 打包成镜像，并上传到私有镜像仓库中，此处我们选择 Amazon ECR，并记录镜像名称。

2.3.3 GitLab 环境准备

准备一台 EC2 安装 Gitlab runner，并给此 EC2 一个角色，具备 AmazonEC2ContainerRegistryFullAccess 以及 AmazonS3FullAccess 权限，注册该 runner 时，注意选择 tag 为 ubuntu,docker,amazon-q，以便后续的 runner 运行节点选择，以下为注册 tag 的参考命令：

 gitlab-runner register --registration-token "<your-runner-reg-token>" --url "<your-gitlab-server-url>" --tag-list "ubuntu,docker,amazon-q" --non-interactive

• 准备一个 Gitlab Token，具备 API 全权限，用于审核完成后调用 API 填写 comment。

• 设置 GitLab 变量，给流程使用。

变量一，Key 为 AMAZON_Q_S3_URI，值为 2.3.1 Amazon Q developer CLI 登录权限中创建的 S3 路径，Visibility 为 Visible，Flags 为 Expand variable reference。

变量二，Key 为 REGISTRATION_TOKEN，值为上一步中的 Gitlab Token，由于此为密钥，所以设置 Visibility 为 Masked，Flags 为 Expand variable reference，其他参考如上图。

变量三，Key 为 Region，值为 Amazon ECR 的所在 region，Visibility 为 Visible，Flags 为 Expand variable reference。

变量四，Key 为 Accountid，值为 Amazon ECR 的所在账户 ID，Visibility 为 Visible，Flags 为 Expand variable reference。

变量五，Key 为 Image，值为上一步 Docker 镜像的名称，Visibility 为 Visible，Flags 为 Expand variable reference。

2.4 GitLab CI/CD 配置

审核阶段的主要步骤包括：

1. 克隆完整仓库

2. 确定需要审核的代码变更

3. 同步 Amazon Q 配置（如果有）

4. 运行 Amazon Q CLI 进行代码审核

5. 保存审核结果

审核流程所用的 .gitlab-ci.ym 文件如下，注意将$Region、${Accountid}、$Image进行替换，其中${Image}为上一步上传到 ECR 的镜像名称。

stages:  - build  - reviewlogin_ecr:  stage: build  script:    - aws ecr get-login-password --region ${Region} | docker login --username AWS --password-stdin ${Accountid}.dkr.ecr.${Region}.amazonaws.com
variables:  # 定义 Amazon Q 提示  PROMPT: |    你是一个代码审核助手，以下文件中包含代码审核规则    improve_rules/improved_code_review_standards_part1.md - 包含一般原则、代码审查流程和检查清单的第一部分（代码风格和代码质量）    improve_rules/improved_code_review_standards_part2.md - 包含功能实现、安全性和性能部分    improve_rules/improved_code_review_standards_part3.md - 包含测试、日志记录、可维护性和特定场景，如并发、事务、幂等性和远程调用    improve_rules/improved_code_review_standards_part4.md - 包含语言特定的检查点、中间件使用指南、通信指南、工具推荐和持续改进    请审核changes.txt中的修改，但不要直接修改文件，以中文输出，并参考improve_rules/llm_code_review_feedback_format.md中的推荐格式进行输出至文件amazon_q_review.md中。完成后，请检查amazon_q_review.md确保所需内容完整。审核完成后运行python脚本put_comment.py将审核结果添加到merge comment中，运行完成后回复完成，不需要对任务做总结，运行过程中不要修改任何文件。然后退出运行q cliamazon-q-code-review:  stage: review  variables:    GIT_STRATEGY: clone  # 使用clone确保获取完整仓库  # 使用您已配置的 Runner 标签  tags:    - ubuntu    - docker    - amazon-q  # GitLab CI/CD 配置文件# 使用预配置的 GitLab Runner 运行 Amazon Q 代码审查  image:${Image}  script:    - echo "CI_MERGE_REQUEST_IID $CI_MERGE_REQUEST_IID"    - echo "CI_MERGE_REQUEST_TARGET_BRANCH_NAME  $CI_MERGE_REQUEST_TARGET_BRANCH_NAME"    - echo "CI_MERGE_REQUEST_SOURCE_BRANCH_NAME $CI_MERGE_REQUEST_SOURCE_BRANCH_NAME"    - echo "CI_COMMIT_BEFORE_SHA  $CI_COMMIT_BEFORE_SHA"    - echo "CI_COMMIT_SHA  $CI_COMMIT_SHA"    - echo "AMAZON_Q_S3_URI $AMAZON_Q_S3_URI"    - echo "REGISTRATION_TOKEN $REGISTRATION_TOKEN"    - git branch -a    - git fetch --all --prune    - touch changes.txt    - echo "Processing changes..."    - if [ -n "$CI_MERGE_REQUEST_IID" ]; then git diff --name-only $CI_MERGE_REQUEST_TARGET_BRANCH_NAME $CI_MERGE_REQUEST_SOURCE_BRANCH_NAME > changes.txt 2>/dev/null || git diff --name-only origin/$CI_MERGE_REQUEST_TARGET_BRANCH_NAME origin/$CI_MERGE_REQUEST_SOURCE_BRANCH_NAME > changes.txt 2>/dev/null || git diff --name-only HEAD~1 HEAD > changes.txt 2>/dev/null || echo "No changes detected" > changes.txt; fi    - if [ -z "$CI_MERGE_REQUEST_IID" ]; then git diff --name-only $CI_COMMIT_BEFORE_SHA $CI_COMMIT_SHA > changes.txt 2>/dev/null || git diff --name-only HEAD~1 HEAD > changes.txt 2>/dev/null || echo "No changes detected" > changes.txt; fi    - if [ -n "$AMAZON_Q_S3_URI" ]; then aws s3 sync $AMAZON_Q_S3_URI ~/.local/share/amazon-q; fi     - ls -l ~/.local/share/amazon-q    - echo "/help" | q chat    - q chat -a -- "$PROMPT"        - mv amazon_q_review.md amazon_q_review_$CI_PIPELINE_ID.md     # 定义何时运行此作业  rules:    - if: $CI_PIPELINE_SOURCE == "merge_request_event"      when: always    - when: never    artifacts:    paths:      - amazon_q_review_$CI_PIPELINE_ID.md    expire_in: 1 month

2.5 审核流程详解

当开发者创建合并请求时，GitLab CI/CD 流程会自动触发，执行以下步骤：

1. 确定变更文件：使用 Git 命令确定合并请求中的变更文件，并将文件列表保存到 changes.txt

git diff --name-only $CI_MERGE_REQUEST_TARGET_BRANCH_NAME $CI_MERGE_REQUEST_SOURCE_BRANCH_NAME > changes.txt

2. 运行 Amazon Q CLI：使用预定义的提示运行 Amazon Q CLI 进行代码审核，审核完成后，Amazon Q 会生成一个 Markdown 格式的审核报告，包含对代码的分析和改进建议。这个报告会通过 Python 脚本 put_comment.py 添加到合并请求的评论中，使开发者能够直接在 GitLab 界面查看审核结果。

q chat -a -- "$PROMPT"

以下是 Prompt 的样例：

你是一个代码审核助手，以下文件中包含代码审核规则    improve_rules/improved_code_review_standards_part1.md - 包含一般原则、代码审查流程和检查清单的第一部分（代码风格和代码质量）    improve_rules/improved_code_review_standards_part2.md - 包含功能实现、安全性和性能部分    improve_rules/improved_code_review_standards_part3.md - 包含测试、日志记录、可维护性和特定场景，如并发、事务、幂等性和远程调用    improve_rules/improved_code_review_standards_part4.md - 包含语言特定的检查点、中间件使用指南、通信指南、工具推荐和持续改进    请审核changes.txt中的修改，但不要直接修改文件，以中文输出，并参考improve_rules/llm_code_review_feedback_format.md中的推荐格式进行输出至文件amazon_q_review.md中。完成后，请检查amazon_q_review.md确保所需内容完整。审核完成后运行python脚本put_comment.py将审核结果添加到merge comment中，运行完成后回复完成，不需要对任务做总结，运行过程中不要修改任何文件。然后退出运行q cli

我们使用了一套完整的代码审核规则，这些规则分为四个部分：

• 一般原则、代码风格和代码质量

• 功能实现、安全性和性能

• 测试、日志记录、可维护性和特定场景

• 语言特定检查点、中间件使用指南和通信指南

这些规则存储在项目的 improve_rules 目录中，作为 Amazon Q 的提示输入。

3. 保存审核结果：将审核结果保存为 CI/CD 流程的构件，以便下载查看。

mv amazon_q_review.md amazon_q_review_$CI_PIPELINE_ID.md

2.6 自定义与扩展

本代码审核的流程，可以根据团队需求进行自定义和扩展：

1. 调整审核规则：修改 improve_rules 目录中的文件，定制适合团队的代码审核标准

2. 增强审核报告：修改 Amazon Q 提示，调整审核报告的格式和内容

3. 集成其他工具：在 CI/CD 流程中添加其他代码质量工具，与 Amazon Q 审核结果结合

4. 自动修复：扩展实现，使 Amazon Q 不仅提供建议，还能自动修复某些问题

5. 增加安全控制：沙箱运行 Amazon Q Developer CLI，减少 API 和 IAM 的相关权限等

2.7 Amazon Q Developer CLI 的智能体能力详解

在 2.5 审核流程详解中，我们利用 prompt 让 Amazon Q 完成了代码审核、审核结果写入文件、调用脚本将审核结果上传到 Gitlab 等操作。使用到了 Amazon Q Developer CLI 的强大的智能体能力，以下为 Gitlab 的运行日志，我们可以来观察一下 Amazon Q 的运行过程。

最终，Q 完成了自己的任务，在 Merge 流程中写上了自己的评论！

总结

在本篇博客中，我们通过 Amazon Q Developer 实现了代码开发的审核，通过 Amazon Q Developer IDE，我们在开发阶段扫描出代码安全问题，提升了代码质量。通过将 Amazon Q CLI 集成到 GitLab CI/CD 流程中，我们实现了一个自动化的代码审核系统。这个系统能够在开发者提交代码或创建合并请求时，自动分析代码变更，提供全面的审核意见，帮助团队保持高质量的代码标准。

Amazon Q CLI 的 AI 能力使得代码审核不再仅仅依赖于团队成员的人工审查，而是能够借助 AI 的力量，更快速、更全面地发现潜在问题。这不仅提高了开发效率，也有助于团队成员学习和遵循最佳实践。而 Amazon Q Developer CLI 的智能体模式，还可以在流程遇到问题时自我修复，保证流程的运行顺利。

随着 Amazon Q 功能的不断增强，我们可以期待这个自动化代码审核系统在未来变得更加智能和有效，为软件开发流程带来更多价值。

*前述特定亚马逊云科技生成式人工智能相关的服务仅在亚马逊云科技海外区域可用，亚马逊云科技中国仅为帮助您了解行业前沿技术和发展海外业务选择推介该服务。

参考文档:Automating Code Reviews with Amazon Q and GitHub Actions

本篇作者

本期最新实验为《Agentic AI 帮你做应用 —— 从0到1打造自己的智能番茄钟》

✨ 自然语言玩转命令行，10 分钟帮你构建应用，1 小时搞定新功能拓展、测试优化、文档注释和部署

💪 免费体验企业级 AI 开发工具，质量+安全全掌控

⏩️[点击进入实验] 即刻开启 AI 开发之旅

构建无限, 探索启程！