C/C++ 静态分析告警整改：按规则分组的 AI 迭代修复

C/C++ 批量告警整改，不能只给 AI 一句“修复所有问题”。 需要明确：流水线失败是否由违规触发，本轮修改哪条规则，修改后怎样继续，以及反复未解决时何时停止。

Parasoft 的 cpptest-ai-agent-demo 提供了可检查的 C++ 源码、GitHub Actions 配置与 AI 调用脚本。本文沿该官方示例，拆解 cpptest-fix-all-violations 的任务控制。这里引用的是公开源码与流程，未运行 C/C++test，也不将示例写成客户实测结果。

一、同一函数中的不同问题，需要按规则限定修改范围

官方 Demo 的 Bank.cxx 包含以下函数，原样摘录，仅统一换行符：

Account* Bank::getAccount(int num, string password)
{
Account* userAccount = NULL;
if (myAccounts.size() > num)
{
userAccount = (Account*)myAccounts[num];
}
if ((userAccount != NULL) && (password.compare(userAccount->getPassword()) != 0))
{
// account wrong if account number does not match
userAccount = NULL;
}
// No account with this number/password exists!!!
return NULL;

}

这段代码同时涉及容器访问、显式类型转换与口令判断。具体哪些位置触发哪条规则，需要以启用的分析配置和报告为准，不能仅凭源码指定告警编号。

从源码还可直接看出，函数末尾无条件返回 NULL。这涉及账户查询的返回语义，应单独分析修改要求；Agent 即使读取了完整函数，也不能在修复选定规则时顺手重写这部分逻辑。按规则限定范围，有助于区分规范整改与业务逻辑变更。

官方工作流先运行 cpptest-analyze.sh，通过 get_violations_from_report_file 读取 reports/report.xml，按工具严重程度选择规则，再调用 get_rule_documentation 获取规则说明。Agent 随后结合告警消息与代码，尽量实施最小修改，本轮只处理选定规则。

分组依据是规则，而非文件或函数。 同一规则可以覆盖多个文件中的违规；同一个函数内，也可能需要分轮处理不同规则，避免一次修复混入多个整改目的。

二、CI 失败后，先检查退出码中的违规标志

官方流水线使用 cpptesttrace make clean all 生成分析输入，配置 Recommended Rules，并向分析 Action 传入 -fail。AI Autofix 步骤在分析步骤失败时进入，但内部还有一层判断。

以下摘自 .github/workflows/cpptest-autofix-github.yml 的 run 段，仅移除外层缩进：

exitCode=${{ steps.run_cpptest.outputs.exitCode }}
if [ "$exitCode" -ge 130 ] || [ $((exitCode & 2)) -eq 0 ]; then
echo "C/C++test exit code does not indicate violations. No autofix needed."
exit 0
fi

exitCode & 2 检查违规标志位：退出码大于等于 130，或该位未置位，都会结束本步骤，后面的 Agent 调用不会执行。代码先区分失败原因，避免把任意分析失败都交给 AI 改代码。

${{ … }} 是 GitHub Actions 表达式，由流水线执行前替换，这段代码不能直接当作本地 Bash 脚本运行。该输出要求分析配置包含 -fail，官方注释注明 Action 自 2.0.3 起提供 exitCode 输出。

三、每条规则独立迭代，用新报告决定下一步

进入修复后，C/C++test 负责分析，MCP 工具提供报告和规则信息，Skill 规定步骤，Agent 实施修改。一次尝试必须包含“修改代码、重新分析、读取结果”；当前规则仍有违规，才继续尝试。

官方参数的计数范围如下：

假设先限定两条规则，每条最多尝试三次，可以在原 Autofix 步骤的 env 段追加以下配置。这是依据官方参数说明改编的局部差异，其他退出码判断、分支创建与 Agent 调用保持原配置。

env:
CPPTEST_COMMIT_FIXES: 1
+ CPPTEST_RULES_LIMIT: 2
+ CPPTEST_ITERATION_LIMIT: 3
WORKFLOWS_DIR: ${{ github.workspace }}/.github/workflows

这允许处理两条规则下的多处告警，每条规则分别拥有最多三次尝试机会。第一条规则达到上限仍未解决，会被标记为本轮无法修复并跳过，后续规则继续处理；达到规则数量上限，则停止本轮任务。

这些参数由 Skill 工作流读取，不是 cpptestcli 的命令行选项。设置变量本身不会启动 AI 修复，仍需通过已配置的 Agent 调用批量修复 Skill。

官方调用脚本读取 cpptest-agent-prompt.md，其中明确要求使用该批量 Skill。因而，一次任务能否按规则迭代，取决于 Agent 加载工作流、访问 MCP 工具以及调用分析脚本的完整衔接。迁移到现有工程时，脚本生成的报告目录还需与 Skill 读取路径一致。

图注：每次修改后重新读取分析结果；规则数量与每规则尝试次数独立限制。

四、复查通过后，按规则保留修复提交

官方示例启用了 CPPTEST_COMMIT_FIXES=1。当前规则的违规修复并通过复查后，工作流要求为该规则提交修改，再处理后续规则，避免把多条规则的修复累积成同一个提交。

没有启用提交时，仍可修复和复查，只是跳过提交；达到上限后跳过某条规则，也不表示相关代码已经自动回滚。代码差异仍需人工审查，尤其应留意未解决规则留下的改动。

图注：按规则提交为后续查看变更提供线索，不代表自动接受或合并。

Parasoft C/C++test 在这一过程中提供告警、规则依据和每轮复查反馈，AI 工作流据此连续推进整改。评估时可以从少量规则开始，核查每轮是否重新分析、残留违规是否进入下一轮，以及停止条件是否按配置执行，再检查修改与现有代码审查要求的适配程度。

代码节选版权：Copyright 2026 Parasoft Corporation，Apache License 2.0。