处理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: truenew-from-rev: origin/main# 和 main 分支对比# 已有的问题不报告（但记录在基线中）max-issues-per-linter: 0max-same-issues: 0# 本地开发时运行全量检查用这个：# 将当前所有问题写入基线文件# golangci-lint run --issues-exit-code=0 --out-format=json > .golangci.baseline.json

效果：

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

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

告警类型排行（修复前）：1. errcheck (724条) - 未检查 error 返回值2. ineffassign (312条) - 无效赋值3. unused (298条) - 未使用的变量/函数4. staticcheck SA1019 (187条) - 使用了 deprecated API5. 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.ymlname: AI Code Reviewon:pull_request:types: [opened, synchronize]jobs:ai-review:runs-on: ubuntu-lateststeps:- uses: actions/checkout@v3- name: Get PR diffid: diffrun: |git fetch origin ${{ github.base_ref }}git diff origin/${{ github.base_ref }}...HEAD > pr.diff- name: AI Reviewuses: ./actions/ai-reviewwith:diff_file: pr.diffmodel: gpt-4oreview_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 能力饱和之后引入，分担机械性的检查工作。最重要的是——治理要有可见的进展。每周的"告警数下降曲线"是团队的动力来源，让大家看到这件事真的有进展，而不是在"做无用功"。