这是一个系列 Blog作者将以一个 PHP 全栈工程师的身份利用 AI 工具claude code、codex、deepseek、豆包等从零开始学习 golang 语言并最终完成 ai-go-admingithub | gitee开源项目的制作全程记录分享。在上一期我们已经完成 “改用 AGENTS.md”本期将完成登录接口整合点选验证码AI 大翻车、阶段目标改变登录接口整合点选验证码在之前我们已经完成了前端的点选验证码组件实现和服务端的验证码生成、验证功能实现接下来为登录接口整合人机验证功能。登录接口/admin/login也是现成的只是之前没有人机验证接下来的工作哪怕扫地阿姨都能轻松完成但是 CC 给我拉了坨大的如果不是有人工逐行review这次生成的代码会导致重大系统漏洞且开发者还自我感觉良好。提示词登录页发起登录请求前调起点选验证码组件携带验证码组件提供的验证数据请求登录接口服务端登录接口的控制器内对点选验证数据进行复验大的来了阅读过之前章节的朋友都知道我一般是不上图的但为防止读者认为我是编的我截图了 AI 的输出如图我没黑 AI它就是在瞎搞。最终完整代码如下是的先查用户名、检查状态账号、验证密码最后才检查了人机验证码是否正确。聪明的读者已经明白了黑客根本不需要提交正确的人机验证码就能通过接口的返回确定密码是否正确等黑客确定了正确的密码然后从容的打开浏览器输入账号密码人工点选验证码完成登录好好的登录接口被写成了正确密码测试接口。最让我觉得翻车的是我的登录接口只缺人机验证且代码带有注释cc 偏偏还是将验证写错了位置并不是说其他逻辑不全位置写错都还情有可原。下面请看 cc 的解释你在internal/service/admin/admin.go中增加的验证点选验证码逻辑为什么是在账号检查、密码检查之后这样人机验证还有意义吗你说得对当前顺序不合理。验证码作为人机验证应该放在最前面否则攻击者可以在不通过验证码的情况下探测用户名是否存在、密码是否正确。正确顺序应该是验证码 → 用户名 → 账号状态 → 密码......阶段目标改变原本是打算直接做好mall同时兼顾admin的用途但调研了BuildAdmin的小伙伴们更加期待的是 Go 版本的干净 admin船小好掉头新的计划是反过来即先做好 admingithub | gitee再基于admin去完善mall当然其实前期两个项目的东西就是一样的只是后续mall会额外多出更多功能。