ECC 中 /go-review 命令实战Go 代码从静态分析到并发安全的完整审查工作流【免费下载链接】ECCThe agent harness performance optimization system. Skills, instincts, memory, security, and research-first development for Claude Code, Codex, Opencode, Cursor and beyond.项目地址: https://gitcode.com/GitHub_Trending/ev/ECC在 ECCagent harness 性能优化系统中/go-review是面向 Go 项目的一条专项代码审查命令它通过go-reviewer智能体对git diff中的 Go 变更执行静态分析、安全扫描、并发审查与 Go 惯用法idiomatic检查最终按 CRITICAL/HIGH/MEDIUM 三级严重度生成可判定的审查报告。本文基于仓库内的 go-review 命令文档、go-reviewer 智能体定义 及其关联技能文档完整拆解这条命令的审查流水线、分级标准、自动检查命令与配套知识体系帮助你在提交代码、评审 PR 或接手新 Go 代码库时建立一套可复制、可验证的 Go 质量门禁。/go-review 在 ECC 命令体系中的定位ECC 将命令commands、智能体agents与技能skills三者组合成可复用的工作流。/go-review在 命令注册表 中的登记信息如下{ command: go-review, description: Comprehensive Go code review for idiomatic patterns, concurrency safety, error handling, and security. Invokes the go-reviewer agent., type: testing, primaryAgents: [go-reviewer], allAgents: [go-reviewer], skills: [golang-patterns, golang-testing], path: commands/go-review.md }从这份登记可以看出其协作关系命令本体是 commands/go-review.md西班牙语版本见 docs/es/commands/go-review.md执行主体是 agents/go-reviewer.md而深度知识则挂载在 skills/golang-patterns/SKILL.md 与 skills/golang-testing/SKILL.md 两个技能上。go-reviewer智能体的声明文件头部frontmatter定义了它的运行约束name: go-reviewer description: Expert Go code reviewer specializing in idiomatic Go, concurrency patterns, error handling, and performance. Use for all Go code changes. MUST BE USED for Go projects. tools: Read, Grep, Glob, Bash model: sonnet从源码结构看该智能体仅被授予Read、Grep、Glob、Bash四类工具并指定sonnet模型属于典型的“只读审查 运行诊断命令”型角色不会直接改写业务代码。文档中声明的行为是“所有 Go 代码变更都必须使用MUST BE USED”即它被定位为 Go 项目变更的默认审查者而非可选项。六步审查流水线/go-review被调用后按固定流水线推进这六个步骤在 docs/es/commands/go-review.md 中完整列出Identify Go Changes通过git diff找出本次修改的.go文件Run Static Analysis执行go vet、staticcheck与golangci-lintSecurity Scan检查 SQL 注入、命令注入、竞态条件race conditionConcurrency Review分析 goroutine 安全性、channel 使用方式、mutex 模式Idiomatic Go Check核对代码是否符合 Go 社区惯例与最佳实践Generate Report将问题按严重度分级汇总输出报告。对应地智能体定义 中给出的是可执行的“被调用动作序列”When invoked: 1. Run git diff -- *.go to see recent Go file changes 2. Run go vet ./... and staticcheck ./... if available 3. Focus on modified .go files 4. Begin review immediately也就是说第一步永远是用git diff -- *.go圈定审查范围——只审改动过的文件避免对全量代码库做无差别扫描这也是该命令能在大仓库中保持响应速度的设计前提。何时使用 /go-review文档给出的五个典型使用时机见 docs/es/commands/go-review.md编写或修改了 Go 代码之后提交commitGo 变更之前审查包含 Go 代码的 Pull Request 时接手并熟悉一个新的 Go 代码库时学习 Go 惯用模式把审查报告当作教学材料时。前三个属于质量门禁场景后两个则是“以审查代替阅读”的入门场景——让智能体按统一标准指出代码中的反模式比逐行通读更高效。三级严重度分类CRITICAL / HIGH / MEDIUM/go-review报告的核心是按严重度归类问题。命令文档docs/es/commands/go-review.md定义了三级清单而 go-reviewer 智能体 在其中给出了更细粒度的检查项。两级文档合并后的完整检查面如下CRITICAL必须修复SQL/命令注入database/sql查询中的字符串拼接、os/exec中未校验的输入智能体定义中另列了路径穿越未做filepath.Clean 前缀校验的用户可控路径、无依据的unsafe包使用、InsecureSkipVerify: true的不安全 TLS 配置无同步的竞态条件共享状态缺少同步原语goroutine 泄漏没有取消机制的长生命周期协程硬编码凭据源码中出现 API key、密码不安全的指针使用关键路径上被忽略的错误用_丢弃错误、可恢复错误使用panic而非返回、缺少fmt.Errorf(context: %w, err)风格的错误包装、用err target代替errors.Is/As比较。HIGH应当修复错误包装缺少上下文信息该返回错误却使用paniccontext.Context未向下传播无缓冲 channel 导致的死锁发送方无接收方接口未满足interface not satisfied错误缺少 mutex 保护、缺少defer mu.Unlock()代码质量问题超长函数50 行以上、过深嵌套4 层以上、该 early return 却写 if/else、可变全局变量包级可变状态、定义无人使用的“接口污染”。MEDIUM建议考虑非惯用代码模式如包名含下划线、错误消息未小写开头导出符号缺少 godoc 注释循环内低效字符串拼接应使用strings.Builderslice 未预分配容量未使用 table-driven 测试写法ctx context.Context未作为函数首参、循环内defer造成资源累积风险。可以看到命令文档给出的是“报告分类粒度”智能体定义给出的是“逐条可核对的检查项”二者配合构成了完整的审查依据。自动执行的诊断命令文档docs/es/commands/go-review.md声明的自动检查命令为# 静态分析 go vet ./... # 进阶检查若已安装 staticcheck ./... golangci-lint run # 竞态条件检测 go build -race ./... # 安全漏洞检查 govulncheck ./...其中有两点适用前提需要注意staticcheck与golangci-lint是可选工具文档明确标注“if installed”智能体侧对应表述为if available未安装时应以go vet结果为准govulncheck用于已知漏洞vulnerability扫描属于补充性安全手段。智能体定义 中的诊断命令清单比命令文档多一条测试侧命令go vet ./... staticcheck ./... golangci-lint run go build -race ./... go test -race ./... govulncheck ./...差异在于增加了go test -race ./...——构建期 race 检测验证的是编译通过性而带-race的测试运行才能真正触发竞态检测器race detector在测试用例中捕获数据竞争。此外golang-patterns 技能 还给出了一份推荐的最小.golangci.yml配置启用errcheck、gosimple、govet含shadow、ineffassign、staticcheck、unused、gofmt、goimports、misspell、unconvert、unparam等 linter可作为落地golangci-lint run时的配置参考。一份完整的审查报告长什么样文档提供了一个可直接对照的报告样例docs/es/commands/go-review.md其英文版在 commands/go-review.md 中附带了问题代码与修复代码两相对照更完整Usuario: /go-review Agente: # Reporte de Revisión de Código Go ## Archivos Revisados - internal/handler/user.go (modificado) - internal/service/auth.go (modificado) ## Resultados del Análisis Estático ✓ go vet: Sin problemas ✓ staticcheck: Sin problemas ## Problemas Encontrados [CRÍTICO] Condición de Carrera Archivo: internal/service/auth.go:45 Problema: Mapa compartido accedido sin sincronización Fix: Usar sync.RWMutex o sync.Map [ALTO] Context de Error Faltante Archivo: internal/handler/user.go:28 Problema: Error retornado sin context Fix: Envolver con context return fmt.Errorf(get user %s: %w, userID, err) ## Resumen - CRÍTICO: 1 - ALTO: 1 - MEDIO: 0 Recomendación: FALLAR: Bloquear merge hasta que se corrija el problema CRÍTICO英文版中第一条 CRITICAL 问题给出了完整的“问题代码 → 修复代码”对照// 问题包级共享 map 被并发读写 var cache map[string]*Session{} // Concurrent access! func GetSession(id string) *Session { return cache[id] // Race condition } // 修复读写锁保护 var ( cache map[string]*Session{} cacheMu sync.RWMutex ) func GetSession(id string) *Session { cacheMu.RLock() defer cacheMu.RUnlock() return cache[id] }第二条 HIGH 问题则演示了标准的错误包装修复return err改写为return fmt.Errorf(get user %s: %w, userID, err)保留%w以便上层用errors.Is/As继续判断——这条修复建议与 golang-patterns 技能 中“Error Wrapping with Context”一节给出的模式完全一致体现了命令、智能体、技能三层文档口径统一。报告结构的固定要素包括被审查文件清单标注 modified、静态分析工具逐项通过/失败状态、按严重度排列的问题列表文件:行号 问题描述 修复建议、数量汇总以及一条明确的合并建议merge recommendation。审批判定标准PASS / WARNING / FAIL判定规则非常简洁docs/es/commands/go-review.md状态条件PASAR: Aprobar通过无 CRITICAL 或 HIGH 级问题ADVERTENCIA警告仅有 MEDIUM 级问题谨慎合并FALLAR: Bloquear阻断发现 CRITICAL 或 HIGH 级问题智能体定义 使用同样的三态标准Approve / Warning / Block因此该判定可以作为 CI 门禁的机器可读输出只要报告末尾出现FALLAR/Block字样即应阻止合并。MEDIUM 问题不阻断但会留存在报告中供后续迭代处理这与 Go 社区“简单优先、渐进改进”的作风相符。审查依据的知识底座golang-patterns 与 golang-testing注册表将golang-patterns与golang-testing挂接到go-review上意味着审查结论的“标准答案”来自这两个技能文档。skills/golang-patterns/SKILL.md 提供了审查时引用的惯用法基线核心三原则简单清晰反对过度聪明的闭包写法、零值可用如bytes.Buffer与内嵌sync.Mutex的Counter无需初始化即可用、接受接口返回结构体错误处理fmt.Errorf(load config %s: %w, path, err)式包装、哨兵错误ErrNotFound等、errors.Is/As判断、绝不裸丢弃错误并发模式worker pool sync.WaitGroup、context.WithTimeout取消与超时、graceful shutdown、errgroup协调协程以及一个与 CRITICAL 级“goroutine 泄漏”直接对应的反例/正例对照——无缓冲 channel 发送前未检查ctx.Done()会永久阻塞正确做法是带缓冲 channel 加select监听取消性能项slice 预分配make([]Result, 0, len(items))、热路径用sync.Pool、循环拼接用strings.Builder或strings.Join——这正对应 MEDIUM 级的三条性能检查项反模式清单长函数裸返回naked return、用panic做控制流、把ctx塞进结构体而非作为首参、值/指针接收者混用。skills/golang-testing/SKILL.md 则支撑 MEDIUM 级“table-driven 测试未使用”这条检查文档给出了 RED-GREEN-REFACTOR 的 Go 版步骤、table-driven 结构体用例模板与覆盖率验证命令审查时可以引用它作为“应当怎么改”的依据。跨工具适配Opencode 侧的检查清单ECC 支持多 harness 运行因此go-review命令存在一份 Opencode 适配版本。其 frontmatter 声明agent: go-reviewer与subtask: true并通过$ARGUMENTS透传用户参数正文是一份可直接执行的四维 checklist### Idiomatic Go - [ ] Package naming (lowercase, no underscores) - [ ] Variable naming (camelCase, short) - [ ] Interface naming (ends with -er) - [ ] Error naming (starts with Err) ### Error Handling - [ ] Errors are checked, not ignored - [ ] Errors wrapped with context (fmt.Errorf(...: %w, err)) - [ ] Sentinel errors used appropriately - [ ] Custom error types when needed ### Concurrency - [ ] Goroutines properly managed - [ ] Channels buffered appropriately - [ ] No data races (use -race flag) - [ ] Context passed for cancellation - [ ] WaitGroups used correctly ### Performance - [ ] Avoid unnecessary allocations - [ ] Use sync.Pool for frequent allocations - [ ] Prefer value receivers for small structs - [ ] Buffer I/O operations报告输出格式统一为[文件:行号] 问题描述 Suggestion与主文档的[CRÍTICO]/[ALTO]报告结构互为印证。命名规范细节接口名以-er结尾、错误变量以Err开头、包名小写无下划线在命令主文档中只以“godoc/命名”一笔带过而这份 checklist 将其展开为可勾选项是理解 MEDIUM 级“非惯用模式”判定的最佳入口。与其他命令的组合使用文档docs/es/commands/go-review.md明确了 Go 工具链命令的组合顺序先用/go-test文档确保 table-driven 测试通过并达到覆盖率目标再审查代码质量若出现构建错误先用/go-build文档修复编译问题——静态分析对无法编译的代码意义有限提交前运行/go-review作为最后一道质量门禁与 Go 语言无关的通用顾虑如 API 设计、项目结构交给/code-review。落地限制与适用前提工具依赖staticcheck、golangci-lint、govulncheck均为可选未安装时自动检查退化为go vetgo build -race模型依赖go-reviewer的 frontmatter 声明model: sonnet实际运行效果以当前 harness 可用模型为准审查范围流程以git diff -- *.go圈定范围对未纳入 git 追踪的文件不生效判定强度PASS/WARNING/FAIL 是智能体给出的建议值最终合并决策仍以团队门禁规则为准。综合来看/go-review的设计思路是把 Go 社区的分散共识Effective Go、go vet、staticcheck、race detector固化成“命令 智能体 技能”三层结构命令定义何时跑、跑什么工具智能体定义逐条检查项与判定标准技能文档提供修复时的标准答案。对 Go 项目而言这套组合可以直接作为提交前检查与 PR 评审的标准化流程使用。【免费下载链接】ECCThe agent harness performance optimization system. Skills, instincts, memory, security, and research-first development for Claude Code, Codex, Opencode, Cursor and beyond.项目地址: https://gitcode.com/GitHub_Trending/ev/ECC创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考