第 58 期，零代码产出。开发者用 Claude Code、Codex（OpenAI 的代码生成模型）、DeepSeek、豆包等工具生成的后台配置管理代码，review 后基本全部放弃，人工重写花了一整天。原因不复杂：系统配置支持动态表单（用户运行时添加的表单字段），涉及 25 种输入组件，Go 语言又是强类型语言（变量类型必须严格匹配，不能像 PHP 那样自动转换），类型转换链条一环错就全错。

2 3

这是什么

4

这是一篇个人系列博客的第 58 篇，作者原本是 PHP 全栈工程师（既写前端也写后端的开发者），目标是用 AI 辅助从零学 Golang，并完成一个开源后台项目 ai-go-admin。本期任务：实现后台的系统配置管理页面，参考已有的 PHP 版本。

听起来是 AI 最擅长的场景：明确参照物 + 明确目标页面 + 已有数据模型。但实际结果是 AI 生成的代码 100% 被推翻。这种"AI 生成 + 人工推翻"的循环，在一个明确有参考实现的任务里依然出现，值得我们停下来看。

5 6

行业怎么看

7

一种声音认为，这恰好说明 AI 编程的现状：能跑通流程，但扛不住复杂业务规则。动态表单、类型转换、边界条件处理，恰恰是工程化项目最耗时间的部分，而 AI 目前在这类"需要理解上下文约束"的任务上表现不稳。

反对意见也有：开发者自身对 Go 的熟悉度，可能才是效率瓶颈。如果作者是 Go 老手，AI 生成 + 局部调整的模式或许可行。换句话说，这次翻车未必是 AI 的问题，而是"用 AI 学一门新语言"这种使用方式的代价。一个人用 AI 学英语写雅思作文，被打回来重写，不能说明 AI 写作工具没用。

还有一种更冷静的判断：58 期下来，AI 至少在样板代码（重复性高的模板代码）、函数级实现上仍然有效，只是不能替代对业务模型的深度思考。把它当"加速器"而非"替代者"，预期会更合理。

8 9

对普通人的影响

10

对企业 IT：如果团队正在评估 AI 编程工具，参考这位作者的实测：在有明确参照、任务边界清晰的模块里，AI 仍可能产出需要大幅返工的代码。落地预期要打折。

对个人职场：非程序员不必焦虑，AI 写代码的进步和你被替代的距离没有想象中近；但程序员同行可以留意：AI 不会让你失业，但会用 AI 的人可能让你的加班变少。

对消费市场：各类 AI 编程助手宣传的"效率提升 10 倍""一行需求生成整个项目"，目前看仍是营销话术。消费者按真实场景付费，企业采购按真实 ROI（投入产出比）算账，会更接近真相。