夜雨聆风最近写公众号时，我连续折腾了几个小工具。
一个是 Wails 本地开发者工具箱，一个是微信文件夹重复文件扫描器，还有一个是 Wails / Tauri 两个版本的代码行统计工具。
一开始我只是想找点真实 Demo。
毕竟单纯写“某某框架怎么用”，很容易写着写着就变成文档复述。真正做一个能跑的东西，哪怕功能很小，文章也会更像真实踩过一遍。
但这几轮做下来，我反而有个更明显的感觉：
如果是让 AI 帮我写本地小工具，Go 比我想象中更合适。
这不是我一个人的感觉。
上一篇 Wails / Tauri 对比下面，有朋友留言说：
AI 写 Go 进度快，省 token，AI 自动编译调试也快。
我看到这句其实挺有共鸣。
以前聊 Go，大家经常说它适合服务端、云原生、命令行、基础设施。这个判断没问题。
但最近让我感触更深的不是这些大词，而是一个很小的场景：
我突然想做一个本地工具，把需求丢给 AI，让它写第一版，然后我在旁边改、跑、验。
这个时候，Go 的很多“老优点”会突然变得很实用。
我说的不是所有项目
先把范围说清楚。
这里说的本地小工具，不是复杂商业桌面客户端，也不是大型企业系统。
我说的是这些东西：
扫一个目录，统计文件大小、重复文件、代码行数 处理一批 JSON、CSV、日志、Markdown 调本地命令，包一层简单界面 写一个开发者工具箱，放几个常用转换功能 做一个自己和同事能马上用起来的小 exe
这类工具的第一目标不是架构漂亮。
它更关心几件事：
能不能快点写出来，能不能跑，出错了好不好修，最后能不能打成一个别人也能打开的东西。
如果是一次性数据分析，Python 可能更顺手。
如果是复杂前端交互，Electron 生态还是成熟。
如果你本来就熟 Rust，又想要很强的安全模型和安装器生态，Tauri 也很值得试。
但如果你是 Go 开发者，或者只是想让 AI 快速帮你堆一个本地工具，Go 的体验会比想象中舒服。
Go 项目不容易被 AI 写散
我现在让 AI 写小工具，最怕的不是它不会写。
恰恰相反，现在 AI 太会写了。
你说“帮我做一个文件扫描器”，它可能立刻给你拉一堆依赖，顺手设计配置层、插件层、抽象接口、日志模块，代码看起来很完整，但你只是想扫个目录。
Go 在这点上有个好处：它不太鼓励把事情写得很花。
比如我之前写微信文件夹重复文件扫描器，核心逻辑其实就几件事：
扫目录，按文件大小先分组，只对同大小文件算 Hash，最后导出 CSV。
这套东西用 Go 标准库就能撑住：
filepath.WalkDir(root, func(pathstring, dfs.DirEntry, errerror) error { iferr!=nil { returnnil } ifd.IsDir() { returnnil } info, err:=d.Info() iferr!=nil||info.Size() ==0 { returnnil } groups[info.Size()] = append(groups[info.Size()], path) returnnil}) 这里不需要什么复杂框架。
文件遍历、路径处理、Hash、CSV、JSON、时间格式化，Go 标准库基本都能覆盖。
AI 生成代码时，也比较容易沿着这个方向写下去，而不是一上来把项目搞成一棵很大的依赖树。
代码行统计工具也是类似。
选一个目录，跳过 node_modules、.git、dist、target 这些目录，再按后缀统计文件数、总行数、空行、注释行。
这个需求不复杂，但很适合做成真实 Demo。
如果用 Go 写后端逻辑，AI 通常可以很快生成一版能跑的代码。你再把边界补一补，比如忽略目录、处理大文件、跳过权限错误，工具就开始像样了。
编译报错很适合 AI 来回改
这一点我以前没那么在意。
但现在用 AI 写代码，反馈回路很重要。
AI 写完一版，我一般不会只看代码。
我会直接让它跑：
go test ./... go build ./... Go 的报错通常很直。
少了一个导入、变量没用、类型不匹配、函数返回值不对，编译器基本会把文件和行号指出来。
AI 拿到这种报错，修起来也快。
很多时候一两轮就能收掉。
这和一些前端项目的体验不太一样。
前端当然也能让 AI 写，但报错链路有时候会比较绕：TypeScript、Vite、插件、依赖版本、路径别名、构建产物，全都可能掺进来。
不是不能修，就是上下文容易变长。
对 AI 来说，上下文越长，越容易开始猜。
Go 的好处是，很多小工具的错误现场很短。
报错短，文件少，依赖少，AI 就不容易偏。
这也是那位朋友说“省 token”的地方。
它不是玄学。
项目简单、错误直接、上下文干净，本来就更适合 AI 来回迭代。
Go 的“无聊”在这里反而是优点
以前我也觉得 Go 有些地方挺无聊。
错误处理一行一行写，语法没什么花活，格式化也没什么可争。
但写本地小工具时，我现在反而喜欢这种无聊。
因为我不太需要代码显得聪明。
我更希望它直一点。
半年后重新打开，还能看出来这个函数在扫目录，那个函数在算 Hash，另一个函数在导出 CSV。
AI 生成代码最容易出问题的地方，往往不是语法，而是它太愿意“顺手抽象一下”。
抽象一多，小工具就不小了。
Go 的风格会把这种冲动压住一点。
比如处理错误时，它通常会老老实实写：
file, err:=os.Open(path) iferr!=nil { return"", err} deferfile.Close() 这段代码没什么惊喜。
但本地工具里，我要的就是没惊喜。
扫微信目录时，可能碰到文件被占用、临时文件、权限问题。扫代码目录时，也可能遇到奇怪的编码和超大的生成文件。
这种时候，我宁愿逻辑朴素一点：当前文件失败就记录或跳过，不要让整个工具直接崩。
打包成一个 exe 也挺关键
本地小工具还有一个很现实的问题：
写出来以后，怎么用？
如果只是我自己在当前电脑跑，脚本语言都可以。
但如果我要发给朋友、同事，或者换台机器也想直接用，单个 exe 的价值就出来了。
Go 在这点上很省心。
CLI 工具可以直接编译：
go build -o tool.exe 如果需要界面，可以像我前面几篇那样，用 Wails 做一层桌面壳。
Go 负责本地能力，Vue 负责界面，最后打出一个桌面应用。
前面那个 Wails 工具箱，最终 exe 大概 8MB 多。
它不是什么复杂软件，但 JSON 格式化、Base64、时间戳、URL 编码、UUID 这些功能都能用。
这个体积和分发方式，对本地开发者工具来说就很舒服。
最近几个工具大概是这样：
这些都不是大项目。
但它们有一个共同点：需求很具体，结果能验证，写完马上能跑。
这种场景下，Go 和 AI 的配合感就很明显。
我现在会怎么选
如果只是扫文件、处理文本、批量转换、调用本地命令，我现在会优先想到 Go。
如果这个工具需要界面，但核心能力还是本地文件、本地命令、本地数据处理，我会考虑 Go + Wails。
如果是一次性清洗数据、画图、分析表格，Python 还是快。
如果是复杂商业桌面端，前端团队主导，Electron 依然稳。
如果目标是小体积桌面应用，并且团队能接受 Rust，Tauri 值得认真试。
我不会说 Go 能替代这些东西。
更准确一点说，我现在更愿意把 Go 当成本地能力层。
界面可以交给 Web 技术，具体是 Wails、Tauri 还是 Electron，看项目和团队。
但那些真正碰文件、跑命令、算数据、读写本地资源的逻辑，用 Go 写起来很稳，也很适合让 AI 先生成一版。
这可能是 AI 时代里 Go 的一个新优势
以前大家说 Go 简单，有时候像是在说它不够酷。
现在我倒觉得，这个简单变得更值钱了。
因为 AI 写代码以后，第一版代码不再是最难的。
难的是写完以后别失控。
你得能跑，能检查，能快速修，能看懂，能继续改。
Go 的类型系统、标准库、编译速度、统一格式化、单文件分发，在这个场景里刚好都能派上用场。
它不一定最炫。
但如果你经常会冒出一些小需求，比如扫个目录、查个重复、做个转换、包个本地界面，Go 确实很适合和 AI 搭在一起。
AI 负责把第一版快速推出来。
Go 负责让这个小工具别太快散掉。
对我来说，这就已经挺够用了。
