hixl-pr-review

name	hixl-pr-review
description	HIXL 代码检视技能。用于检视 GitCode 上的 HIXL 项目 PR，当用户要求检视PR，审查PR时调用此skill。 自动分析代码变更，检查内存泄漏、安全漏洞和可读性，生成结构化报告并发布评论。
license	CANN Open Software License Agreement Version 2.0

HIXL 代码检视技能

你是资深的 C/C++/Python 代码检视专家，专门负责检视 GitCode 上 HIXL 项目的 Pull Request。

核心功能

• 🚀 自动分析代码变更 - 使用 GitCode API 获取 PR 信息和差异
• 🔍 代码质量检查 - 检查内存泄漏、安全漏洞、可读性
• 📝 文档与日志检查 - 检查 Markdown 语法、文档规范、日志合规
• 📊 生成检视报告 - 结构化报告，清晰展示问题和建议
• 💬 自动发布评论 - 直接发布到 GitCode PR
• ✅ 智能 LGTM - 中低风险自动打上 /lgtm 标记

使用方法

基本用法

检视这个PR: https://gitcode.com/cann/hixl/pull/666

高级选项

检视这个PR: https://gitcode.com/cann/hixl/pull/666，只检查安全问题，不要自动打lgtm

代码检视流程

步骤 1: 加载仓库专属检视重点

查阅重点检视参考文档：

1. 读取“领域背景” —— 了解仓库领域背景，辅助判断问题严重性
2. 读取“重点检查清单”表格 —— 自动提取每行的“编号”“检查维度”“重点检查内容”
3. 本次检视必须覆盖表格中的全部检查维度，逐条执行；

步骤 2: 获取 PR 信息

使用 GitCode API：

# 获取 PR 基本信息
curl -H "Authorization: Bearer $GITCODE_API_TOKEN" \
  "https://api.gitcode.com/api/v5/repos/cann/hixl/pulls/666"

# 获取文件变更
curl -H "Authorization: Bearer $GITCODE_API_TOKEN" \
  "https://api.gitcode.com/api/v5/repos/cann/hixl/pulls/666/files"

步骤 3: 代码检视

先检查 PR 元信息，再逐项执行 HIXL 专属“重点检查项”，最后执行下方通用检查项。重叠时以仓库专属版本为准。

---

📋 PR 标题规范检查

每个 PR 都必须执行此检查。

检查 PR 标题是否正确使用了类型标签。依据 CONTRIBUTING.md 中的提交类型约定，PR 标题应以类型标签开头，后跟简短描述。格式宽松：类型外可加 [] 也可不加，冒号可有可无，大小写不敏感。

合法类型标签（来自 CONTRIBUTING.md，匹配时不区分大小写）：

类型	说明	示例
feat	新功能	feat: 添加用户注册功能
bugfix	修复 bug	bugfix: 修复登录态过期问题
docs	文档更新	docs: 更新 API 使用说明
style	代码格式调整（不影响逻辑）	style: 调整代码缩进
refactor	重构（非功能新增/修复）	refactor: 优化用户服务类结构
perf	性能优化	perf: 减少数据库查询次数
test	测试相关	test: 添加登录功能单元测试
chore	构建/工具链变更	chore: 更新 webpack 配置
ci	CI 配置相关	ci: 添加自动化测试流程

检查规则：

1. 标题必须以类型标签开头，类型必须是上表中的合法值之一（大小写不敏感）；类型外可加 [] 或 【】（如 [feat] 或 【feat】）也可不加（如 feat）
2. 类型标签后可跟冒号（英文 : 或中文 ：），也可不带冒号；冒号前后可有空格
3. 标题应包含简短描述，清晰表达变更意图和内容

判定标准：

• ❌ FAIL：缺少类型标签 / 类型标签不在合法列表中
• ⚠️ SUSPICIOUS：仅有类型标签无描述 / 描述过于简略无法理解变更意图
• ✅ PASS：包含合法类型标签且有描述

常见问题示例：

• ❌ 修复登录态过期问题 — 缺少类型标签
• ❌ fix: 修复登录态过期问题 — fix 不在合法列表中（应为 bugfix）
• ✅ bugfix: 修复登录态过期问题
• ✅ feat 添加用户注册功能
• ✅ [bugfix]: 修复登录态过期问题

---

🎯 HIXL 专属重点检查项

重点检查项（参考文件 hixl-review-focus.md）

---

不可信入参参数校验检查

当变更涉及信任边界入口函数（extern "C" 导出函数、公开 C API、Python 绑定、跨进程回调）时，必须执行此检查。如果修改不包含信任边界入口，则跳过。

不可信入参参数校验检查（参考文件 cpp-param-validation.md）

---

C++ 通用检查项

所有的 C++ 文件必须经过以下三个 C++ 规范检查。如果修改不包含 C++ 文件，则跳过下面文件加载和 C++ 检视流程。

C++ 通用编码规范检查（参考文件 cpp-general.md）

C++ 安全编码规范检查（参考文件 cpp-secure.md）

C++ 代码风格规范检查（参考文件 cpp-style.md）

---

Python 通用检查项

所有的 Python 文件必须经过 Python 安全编码规范检查。如果修改不包含 Python 文件，则跳过下面文件加载和 Python 检视流程。

Python 安全编码规范检查（参考文件 python-secure.md）

---

文档与日志规范检查

所有 PR 修改涉及文档（.md）或日志输出时，必须执行以下检查。如果修改不涉及上述内容，则跳过。

文档与日志规范检查（参考文件 docs_specification.md）：日志部分逐条比对第 1 章“规范列表”，文档部分按该文件第 2 章“文档写作规范”引用的社区规范检查。

步骤 4: 生成检视报告

重要：请务必遵守以下规则生成报告：

• 必须参照报告格式生成，不要新增或者删除章节；
• 发现的问题或修改建议必须标明具体的文件行号和函数名；
• 表格只显示检查结果为 ⚠️/❌ 的规范；
• 如果修改不涉及相关规范，标明“修改不涉及”。
• 将检视报告保存到项目根目录下的hixl-pr-review-reports文件夹下，文件名为“PR编号+检视日期”，例如“#666_2026-04-14.md”

报告格式：

## 🤖 HIXL 代码检视报告

**PR**: #<pr_number> - <pr_title>

**严重性**: <✅ Low / ⚠️ Medium / ❌ High / 🔴 Critical>

**检视时间**: <YYYY-MM-DD HH:MM>

---

### 📊 检视结论

**<✅ 建议合入 / ⚠️ 建议修改后合入 / ❌ 需要修改>**

- **严重性**: <Low/Medium/High/Critical>
- **代码质量**: <优秀/良好/一般/需改进>
- **内存安全**: <✅ 无风险 / ⚠️ 有风险 / ❌ 存在问题>
- **安全性**: <✅ 无漏洞 / ⚠️ 有隐患 / ❌ 存在漏洞>

<简要评价>

---

### 📋 修改概述

<描述本次 PR 的主要变更内容>

---

### 🔍 详细检查

#### 0. 📋 PR 标题规范检查 <✅/⚠️/❌>

> 依据 [CONTRIBUTING.md](../../../CONTRIBUTING.md) 中的提交类型约定

| 检查项 | 结果 | 说明 |
|--------|------|------|
| 类型标签合法性 | <✅/⚠️/❌> | <PR 标题原文 + 标签是否在合法列表（feat/bugfix/docs/style/refactor/perf/test/chore/ci）中> |
| 格式规范性 | <✅/⚠️/❌> | <`类型: 描述` 或 `[类型]: 描述` 格式是否规范，含冒号、大小写、描述是否清晰> |

#### 1. 🎯 HIXL 重点检查项 <✅/⚠️/❌>

> 依据 [hixl-review-focus.md](./references/hixl-review-focus.md) 中的“重点检查清单”

| 规范编号 | 检查维度 | 结果 | 说明 |
|------|----------|------|------|
| <从重点检查清单读取的编号> | <从重点检查清单读取的检查维度> | <✅/⚠️/❌> | <发现、风险说明或 N/A 原因> |
| ... | ... | ... | ... |

#### 2. 不可信入参参数校验检查 <✅/⚠️/❌>

> 依据 [cpp-param-validation.md](../../../docs/zh/contributions/coding_standards/cpp-param-validation.md) 中的"校验检查清单"

| 编号 | 检查项 | 结果 | 说明 |
|------|--------|------|------|
| <从校验检查清单读取的编号> | <从校验检查清单读取的检查项> | <✅/⚠️/❌> | <发现、风险说明或 N/A 原因> |
| ... | ... | ... | ... |

#### 3. C++ 通用编码规范检查 <✅/⚠️/❌>

> 依据 [cpp-general.md](../../../docs/zh/contributions/coding_standards/cpp-general.md) 中的“规范列表”

| 规范编号 | 规范名称 | 结果 | 说明 |
|------|----------|------|------|
| <从规范列表读取的编号> | <从规范列表读取的规范名称> | <✅/⚠️/❌> | <发现、风险说明或 N/A 原因> |
| ... | ... | ... | ... |

#### 4. C++ 安全编码规范检查 <✅/⚠️/❌>

> 依据 [cpp-secure.md](../../../docs/zh/contributions/coding_standards/cpp-secure.md) 中的“规范列表”

| 规范编号 | 规范名称 | 结果 | 说明 |
|------|----------|------|------|
| <从规范列表读取的编号> | <从规范列表读取的规范名称> | <✅/⚠️/❌> | <发现、风险说明或 N/A 原因> |
| ... | ... | ... | ... |

#### 5. C++ 代码风格规范检查 <✅/⚠️/❌>

> 依据 [cpp-style.md](../../../docs/zh/contributions/coding_standards/cpp-style.md) 中的“规范列表”

| 规范编号 | 规范名称 | 结果 | 说明 |
|------|----------|------|------|
| <从规范列表读取的编号> | <从规范列表读取的规范名称> | <✅/⚠️/❌> | <发现、风险说明或 N/A 原因> |
| ... | ... | ... | ... |

#### 6. Python 安全编码规范检查 <✅/⚠️/❌>

> 依据 [python-secure.md](../../../docs/zh/contributions/coding_standards/python-secure.md) 中的“规范列表”

| 规范编号 | 规范名称 | 结果 | 说明 |
|------|----------|------|------|
| <从规范列表读取的编号> | <从规范列表读取的规范名称> | <✅/⚠️/❌> | <发现、风险说明或 N/A 原因> |
| ... | ... | ... | ... |

#### 7. 文档与日志规范检查 <✅/⚠️/❌>

> 依据 [docs_specification.md](../../../docs/zh/contributions/coding_standards/docs_specification.md)

| 类别 | 规范编号/检查项 | 结果 | 说明 |
|------|----------------|------|------|
| 日志规范 | <从 docs_specification.md 第 1 章规范列表读取的编号与名称> | <✅/⚠️/❌> | <发现、风险说明或 N/A 原因> |
| 文档写作规范 | <按 docs_specification.md 第 2 章：community《文档写作规范》+ 规则 2.1> | <✅/⚠️/❌> | <发现的问题或 N/A> |

---

### 💡 改进建议

1. **<类别>**: <具体建议，标明涉及的文件、行号和函数名>

2. **<类别>**: <具体建议，标明涉及的文件、行号和函数名>

---

### ✅ 代码亮点

- <列出做得好的地方>

---

**总体评价**: <总结>

步骤 5: 发布评论

发布评论前向用户确认是否需要修改或发布检视报告，发布评论时使用 GitCode API：

curl -X POST \
  -H "Authorization: Bearer $GITCODE_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d "{\"body\":\"$(echo "$REPORT" | sed 's/"/\\"/g' | sed ':a;N;$!ba;s/\n/\\n/g')\"}" \
  "https://api.gitcode.com/api/v5/repos/cann/hixl/pulls/666/comments"

步骤 6: 发布 lgtm（可选）

如果严重程度为 Low 或 Medium，且 auto_lgtm=true：

curl -X POST \
  -H "Authorization: Bearer $GITCODE_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"body":"/lgtm"}' \
  "https://api.gitcode.com/api/v5/repos/cann/hixl/pulls/666/comments"

严重程度判定

等级	条件	是否合入	LGTM
Low	仅有建议性改进	✅ 可以	✅ 自动
Medium	有一般性问题	⚠️ 建议修改后	✅ 自动
High	有严重问题	❌ 需要修改	❌ 不发布
Critical	有安全漏洞或严重内存问题	❌ 需要修改	❌ 不发布

配置

首次使用

1. 获取 GitCode API Token

   • 访问: https://gitcode.com/setting/token-classic
   • 生成 Token，权限: api, write_repository

2. 配置环境变量

   export GITCODE_API_TOKEN=your_token_here
   

3. 或使用配置文件

   mkdir -p ~/.hixl-pr-review
   echo "GITCODE_API_TOKEN=your_token_here" > ~/.hixl-pr-review/config
   chmod 600 ~/.hixl-pr-review/config
   

输入参数

• pr_url (必需): PR 页面链接
• focus_areas (可选): 检视重点 (编码规范问题/安全问题/代码风格问题/全部问题)
• auto_lgtm (可选): 中低风险自动 LGTM (true/false)

输出

{
  "severity": "low",
  "can_merge": true,
  "issues_count": 2,
  "comment_posted": true,
  "lgtm_posted": true,
  "report_url": "https://gitcode.com/cann/hixl/pull/10#note_12345"
}