还在为GitLab集成烦恼？这5个颠覆性方法让你秒变DevOps高手

于AI编程助力器具更为广泛盛行的现如今，怎样促使大型语言模型能够精确剖析代码间的差别进而输出具备结构的资料，变成了开发者公众比较留意的技术受重点之存在趋向。CQITer技术小组最近一段时间实践可以表示出来的情况是，凭借特定的提示用词工程以及格式扩充，能够切实增进语言处理大模型用于代码审核进程里面其所能应用属性的程度。

代码差异解析的技术需求

如今在现代软件开发进程里，代码审查这一环节是极其关键重要的。传统那种人工审查的方式，耗费时间又消耗精力，然而直接把原始diff格式提供给LLM去进行分析，存有许多的局限之处。技术团队发觉，一定要把标准Unified Format格式予以扩展，补充上新旧文件路径以及具体行号信息，才能够满足自动化代码审查的需求。

结构化数据设计的必要性

1. 团队设计了能够实现与GitLab API无缝对接的特定TypeScript类型规范。 2. 此规范要求LLM返回一种数组结构。 3. 该数组结构包含标题、文件路径、行号以及具体内容。 4. 这样的设计保证了后续程序可以准确解析LLM的输出。 5. 并且能将结果直接用于API调用。 6. 进而大幅提升了集成效率。

interface Review {
  // 表示修改后的文件路径
  newPath: string;
  // 表示修改前的文件路径
  oldPath: string;
  // 表示评审的是旧代码还是新代码，如果评审的是 + 部分的代码，那么 type 就是 new，如果评审的是 - 部分的代码，那么 type 就是 old。
  type: 'old' | 'new';
  // 如果是 old 类型，那么 startLine 表示的是旧代码的第 startLine 行，否则表示的是新代码的第 startLine 行
  startLine: number;
  // 如果是 new 类型，那么 endLine 表示的是旧代码的第 endLine 行，否则表示的是新代码的第 endLine 行
  endLine: number;
  // 对于存在问题总结的标题，例如(逻辑错误、语法错误、安全风险等)，尽可能不超过 6 个字
  issueHeader: string;
  // 清晰的描述代码中存在、需要注意或者修改的问题，并给出明确建议
  issueContent: string;
}
interface MRReview {
  reviews: Review[];
}

输入格式的扩展处理

最初的diff信息欠缺必需的上下文数据，于是团队研发了专门的预处理流程，经以此解析每个文件的diff内容，接着将其依照hunk拆分成好多代码块，并且依据hunk head消息计算每行代码处于新旧文件里的实际行号，如“(1,1)”意味着该行于旧文件的第1行，新文件的第1行 。

你是一个代码 MR Review 专家，你的任务是评审 Git Merge Request 中提交的代码，如果存在有问题的代码，你要提供有价值、有建设性值的建议。
注意，你评审时，应重点关注 diff 中括号后面带 + 或 - 的代码。

提示词工程的关键作用

@@ -1,16 +1,13 @@
import { Injectable } from '@nestjs/common';
   
-interface InputProps {
-  code_diff: string;
-  code_context: string;
-  rules?: string;
-}
+type InputProps = Record;
interface CallDifyParams {

系统给出的提示词，应当清晰地阐释扩展之后的diff格式究竟是什么意思，防止LLM出现理解偏差。团队于提示词里给出完备的TS类型定义以及输出样例，保证LLM能严格依照预先设定的格式来生成回应。这样的一种方法显著地让输出数据那种随随便便的状况有所减少，提升了最终结果的可预测情况。

## new_path: src/agent/agent.service.ts
## old_path: src/agent/agent.service.ts
@@ -1,16 +1,13 @@
(1, 1) import { Injectable } from '@nestjs/common';
(2, 2)  
(3, ) -interface InputProps {
(4, ) - code_diff: string;
(5, ) - code_context: string;
(6, ) - rules?: string;
(7, ) -}
( , 8) +type InputProps = Record;
(9, 9)  
(10, 10) interface CallDifyParams {

数据解析的异常处理

得到LLM的文本回应之后，要把它转变为能够操作的数据结构。团队设计的异常处理机制很完善，涵盖格式验证以及类型检查，还有错误恢复策略。在解析失败之际，系统会记录详尽日志，并且启动备用处理流程，以此确保整个审查过程的稳定性。

我们将使用下面的格式来呈现 MR 代码的 diff 内容:
## new_path: src/agent/agent.service.ts
## old_path: src/agent/agent.service.ts
@@ -1,16 +1,13 @@
(1, 1) import { Injectable } from '@nestjs/common';
(2, 2)  
(3, ) -interface InputProps {
(4, ) - code_diff: string;
(5, ) - code_context: string;
(6, ) - rules?: string;
(7, ) -}
( , 8) +type InputProps = Record;
(9, 9)  
(10, 10) interface CallDifyParams {
- 以 ”## new_path“ 开头的行内容，表示修改后的文件路径
- 以 ”## old_path“ 开头的行内容，表示修改前的文件路径
- @@ -1,16 +1,13 @@ 是统一差异格式(Unified Diff Format)中的hunk header，用于描述文件内容的具体修改位置和范围
- 每一行左侧括号内的两个数字，左边表示旧代码的行号，右边表示新代码的行号
- 括号后的 + 表示的是新增行
- 括号后的 - 表示的是删除行
- 引用代码中的变量、名称或文件路径时，请使用反引号（`）而不是单引号（'）。

系统集成的技术实现

你必须根据下面的 TS 类型定义，输出等效于MRReview类型的YML对象：
```ts
interface Review {
  // 表示修改后的文件路径
  newPath: string;
  // 表示修改前的文件路径
  oldPath: string;
  // 表示评审的是旧代码还是新代码，如果评审的是 + 部分的代码，那么 type 就是 new，如果评审的是 - 部分的代码，那么 type 就是 old。
  type: 'old' | 'new';
  // 如果是 old 类型，那么 startLine 表示的是旧代码的第 startLine 行，否则表示的是新代码的第 startLine 行
  startLine: number;
  // 如果是 new 类型，那么 endLine 表示的是旧代码的第 endLine 行，否则表示的是新代码的第 endLine 行
  endLine: number;
  // 对于存在问题总结的标题，例如(逻辑错误、语法错误、安全风险等)，尽可能不超过 6 个字
  issueHeader: string;
  // 清晰的描述代码中存在、需要注意或者修改的问题，并给出明确建议
  issueContent: string;
}
interface MRReview {
  reviews: Review[];
}
```

整个技术方案关联多个组件协同开展工作，先是从GitLab获取原始diff，接着历经格式扩展以及内容拼接，随后输入到LLM当中做分析，最后解析结果并且调用GitLab API提交评论。每一个环节全都经过精心设计，以此确保数据传输的准确性以及处理效率。

各级别的开发者于运用AI辅助代码审查其间，有没有碰到过输出格式不一样的技术方面的难题呢？欢迎于评论区域分享您所拥有的解决方案以及实践之内的经验，要是感觉本文对您具备一定帮助，请给予点赞支持并且分享给更多有着需求的技术性质的团队。

// 调用 LLM 的接口
const result = await callLLM('xxxxx');
// 解析数据
const data = yaml.load(result);
// 操作数据
data.reviews.forEach(() => {  })

输出模板（注意，我只需要 yaml 格式的内容。yaml 内容的前后不要有其他内容）:
```yaml
reviews:
  - newPath: |
      src/agent/agent.service.ts
    oldPath: |
      src/agent/agent.service.ts
    startLine: 1
    endLine: 1
    type: |
      old
    issueHeader: |
      逻辑错误
    issueContent: |
      ...
  - newPath: |
      src/webhook/decorators/advanced-header.decorator.ts
    oldPath: |
      src/webhook/decorators/commmon-header.decorator.ts
    startLine: 1
    endLine: 1
    type: |
      new
    issueHeader: |
      性能风险
    issueContent: |
      ...
```