Go 项目代码质量治理：从 lint 到 AI Code Review 的工程化之路

Go 项目代码质量治理：从 lint 到 AI Code Review 的工程化之路

一、代码仓库 50 万行，CI 构建要跑 15 分钟，lint 报警 2300 条

接手一个遗留 Go 项目时，第一眼看 CI 日志就让人崩溃。golangci-lint 报出 2300 条 warning，go vet 有 87 个 issue，测试覆盖率 12%。更糟的是，这些报警在团队中已经"免疫"了——"一直是这样的，没事"。

代码质量治理不能靠"一次性清掉所有报警"——那会导致巨大改动引入新 Bug。正确的策略是"止血、疏通、排毒"三个阶段。

二、三阶段质量治理路线图

核心思路：不能"一刀切"要求全部代码立刻达标。给新代码严格要求（门禁），给老代码宽限期（逐步还债）。"亡羊补牢"的关键是：先确保不再产生新问题，再逐步清理老问题。

三、关键实施细节

阶段一：CI 门禁的"增量禁止"策略

.golangci.yml 中的关键配置：

issues:
# 只检查当前 PR 改动的问题
new: true
new-from-rev: origin/main # 和 main 分支对比
# 已有的问题不报告（但记录在基线中）
max-issues-per-linter: 0
max-same-issues: 0

# 本地开发时运行全量检查用这个：
# 将当前所有问题写入基线文件
# golangci-lint run –issues-exit-code=0 –out-format=json > .golangci.baseline.json

效果：

• 之前合并 PR 时 lint 被忽略（因为报的都是老问题）
• 之后任何新增的 lint 问题都会阻断 CI，但老问题不会被重复报告
• 每周修复一类老问题后，更新基线文件，告警数可见地下降

阶段二：告警分类和批量修复

对 2300 条告警做了分类统计：

告警类型排行（修复前）：
1. errcheck (724条) – 未检查 error 返回值
2. ineffassign (312条) – 无效赋值
3. unused (298条) – 未使用的变量/函数
4. staticcheck SA1019 (187条) – 使用了 deprecated API
5. gosimple (156条) – 可简化的代码

第三周专注修「errcheck」：用 sed 批量添加 _ = 忽略不需要的 error，再人工 Review 需要真正处理 error 的地方。一周修完 724 条，lint 告警降到 1576 条。

第四周修「ineffassign」：删除无效的赋值语句，发现其中有 12 处是真实的 bug（本意是赋值给某个变量但写错了名字）。

阶段三：AI Code Review 的引入

单纯的人工 CR 做不到覆盖每条 PR。引入 AI Code Review（基于 GitHub Action + LLM）：

# .github/workflows/ai-review.yml
name: AI Code Review
on:
pull_request:
types: [opened, synchronize]

jobs:
ai-review:
runs-on: ubuntu-latest
steps:
– uses: actions/checkout@v3

– name: Get PR diff
id: diff
run: |
git fetch origin ${{ github.base_ref }}
git diff origin/${{ github.base_ref }}…HEAD > pr.diff

– name: AI Review
uses: ./actions/ai-review
with:
diff_file: pr.diff
model: gpt-4o
review_focus: |
请检查以下问题（按优先级排序）：
1. 并发安全问题（goroutine 的资源泄漏、channel 死锁）
2. 错误处理是否正确（是否忽略了关键 error）
3. SQL 注入和输入验证
4. 资源释放（file handle、DB 连接）
5. 代码规范和可维护性

# AI 的 Review 评论作为 PR Comment 展示
# 标记为 "🤖 AI Review"，和人类 CR 区分开

AI Code Review 的定位：不是替代人类 CR，而是做"第一道防线"——把机械性的检查（变量未使用、资源未关闭、明显的并发问题）交给 AI，让人专注于逻辑和设计层面的 Review。实际效果：AI 平均每条 PR 发现 2.3 个潜在问题，其中约 60% 是人类 CR 也会发现的（相当于把 CR 的工作量分担了）。

四、治理成效数据

五、总结

代码质量治理的核心策略是"增量禁止、存量偿还"。新代码零容忍（CI 门禁阻断），老代码分批次修复（每周一类告警）。三个阶段的目标：止血（不再新增问题）→ 疏通（批量清理高频告警）→ 排毒（AI 辅助深层审查 + 架构优化）。AI Code Review 是最后一张牌，在人的 CR 能力饱和之后引入，分担机械性的检查工作。最重要的是——治理要有可见的进展。每周的"告警数下降曲线"是团队的动力来源，让大家看到这件事真的有进展，而不是在"做无用功"。