这位作者从 PHP 全栈转型 Go，全过程让 AI 陪着写。第 59 篇的任务很普通：把后台入口从 /admin 改成自定义路径（出于安全考虑）。技术本身不难，但这篇文章有意思的地方在于它记录了「AI 第一次写的代码」和「被 review 之后改的代码」之间的差距。
这是什么
背景：作者在做一个开源后台框架 ai-go-admin，后台所有路由默认挂载在 /admin 下。现在他想支持自定义，比如改成 /dfwef1dki，让管理员入口不那么显眼。
他先问了 AI 几种实现思路（文件配置 vs 常量），AI 给的方案是新增一个 app.admin_path 配置项。他看了一眼觉得路径类配置应该放在 server 命名空间下、而不是 app 下，让 AI 重做。
AI 重做后，作者发现它又犯了一个架构上的小毛病：在某个函数 BuildCheckPath 里，AI 让函数外面传 adminPath 参数进来，而不是让函数自己读配置。作者判断这个函数本身就在 infra 文件夹里（内部代码，不是公共包），完全可以自己读，不应该让上游传。
这是一个典型的「AI 能写代码，但需要被教怎么写得体」的场景。
行业怎么看
支持这种用法的工程师不少。一线开发者在 Twitter/X 和 V2EX 上反复提到的观点是：AI coding 工具最大的价值不是替代写代码，而是把「我想做什么」翻译成「可以跑的代码」；真正的设计判断仍然要人来做。
但也有反对意见。一位前阿里 P8 在知乎评论里写过类似的担忧：过度依赖 AI coding 会让初级程序员跳过「为什么这么写」的训练，等到要 review AI 输出、需要判断方案优劣时，反而接不住。这位作者能发现 app vs server 命名空间的问题、能判断 BuildCheckPath 该不该自己读配置，靠的正是传统软件工程训练。
还有一个被忽略的风险：AI 生成的代码看起来能跑，但工程上的细节（命名空间归属、参数传递合理性、中间件挂载位置）需要 review 才能发现。这位作者每期都在 review，这是个关键习惯。
对普通人的影响
对企业 IT：这类「AI 辅助开发」流程正在快速成熟，但企业若引入 AI coding 工具，仍需保留人工 review 这一环 — 否则代码能上线，架构债也会同时上线。
对个人职场：程序员的核心竞争力正在从「写」转向「判断」。能准确告诉 AI「哪里写得不对、为什么不对」的人，会比单纯写代码的人更值钱。
对消费市场：目前还看不到直接影响。但一个观察是：开源社区里这类「人 + AI 协作」的实战记录越来越多，比厂商发布会更能反映 AI 编程工具的真实能力边界。