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