Claude 3.7 能稳定完成接口抽象、函数拆分、错误路径统一、测试补全等具体重构切口，但无法理解团队RFC、隐性依赖、本地gofumpt/revive规则及Git语义等需MCP注入的上下文。
Claude 3.7 在 Go 语言重构任务中，**能稳定完成 Senior Developer 愿意交出去的那类重构**——比如接口抽象、函数拆分、错误路径统一、测试覆盖率补全。但它不会主动质疑架构合理性，也不理解你团队上周在 RFC 里吵过的 context 传递方案是否该被废弃。
Go 重构时 go fmt 和 go vet 之外，Claude 实际接管了哪些环节
它真正起效的不是“重写整个包”，而是嵌入在开发者工作流里的具体切口：
- 把一个 300 行的
HandleRequest函数按职责拆成parseInput、validateAuth、executeBusinessLogic三组函数，并自动补上缺失的 error 类型断言和日志字段 - 识别出多个文件里重复的
if err != nil { return err }模式，建议用errors.Join或自定义WrapError封装，并给出 patch diff - 读取你当前目录下的
go.mod和Makefile，推断出项目用的是ginkgo而非testify，生成的测试用例就默认用It+Expect语法 - 当你说“把这个 HTTP handler 改成支持 streaming response”，它会检查你是否已 import
io和net/http，并提醒你Flusher接口在 Go 1.22+ 才稳定，避免往老版本里硬塞
go:embed 和 embed.FS 迁移时最容易漏掉的兼容性陷阱
Claude 3.7 能发现大部分显性问题，但对隐性依赖很迟钝。比如你把 //go:embed assets/* 换成 embed.FS 后，它可能不会提醒你：
-
http.FileServer(http.FS(fs))在 Go 1.21+ 才支持直接传embed.FS，旧版本需包装成http.Dir或用fs.Sub - 如果原代码用了
os.ReadFile("assets/logo.png")，Claude 会建议改成fs.ReadFile("logo.png")，但它不检查fs变量是否被正确初始化（比如漏了var fs embed.FS声明） - 当路径里含
..或变量拼接（如fs.ReadFile("assets/" + name)），它不会报错，但 runtime 会 panic —— 这类动态路径在embed.FS下根本不可用
为什么你给 gofumpt 加的自定义规则，Claude 3.7 很难复现
Claude 的代码生成基于语义理解，而非格式规则匹配。它知道“函数参数超过 4 个该拆成 struct”，但不知道你团队 .gofumpt.yaml 里写的 force-linebreaks-on-arguments: true 是强制每参数换行还是只对 map/slice 字面量生效。
更关键的是，它无法感知本地 gofumpt 版本差异：
- Go 1.22+ 的
gofumpt默认启用-extra，会重排if条件中的括号；而你本地用的是 v0.5.0，没开这个 flag - 它生成的代码在你机器上跑
gofumpt -w后，可能被二次格式化，导致 diff 里出现大量无关空行或括号位置变动 - 如果你用
revive配了自定义 linter 规则（比如禁止fmt.Sprintf在日志里用），Claude 不会主动规避，除非你在 prompt 里明确写出这条规则
真正卡住重构进度的，从来不是“能不能生成正确语法的 Go 代码”，而是它看不见你的 revive.toml、看不懂你 Git 提交信息里那个 [refactor] tag 的真实含义、也读不懂你们站会上说的“先别动 config 包，等 infra 团队 merge 那个 PR”。这些上下文，得靠 MCP 连接器喂进去，而不是靠 prompt 描述。
