在上一篇文章里我把“用AI做开发”这件事的整体思路理了一遍包括怎么拆分需求、怎么给AI描述任务、怎么把AI输出的代码整合进项目。这篇继续推进聚焦一个所有人都会碰到、但很少有人真正做扎实的场景登录界面。登录界面看起来简单无非一个手机号/邮箱输入框、一个密码框、一个登录按钮顶多再加个“记住我”。但一旦进入真实项目事情就没那么轻松了前端要处理表单校验、错误状态、加载状态后端要处理接口鉴权、密码加密、会话过期、刷新令牌中间的联调还要考虑超时、网络异常、设备兼容。任何一个环节掉了链子用户第一眼就会觉得“这产品不靠谱”。而AI在这个场景里能帮上大忙前提是你知道怎么指挥它。这篇把我实际操作中验证过的流程完整走一遍包括提示词怎么写、代码怎么生成、接口怎么联调、坑都踩在哪里。这篇的内容不是让你复制一段代码就跑路而是把“用AI做登录界面”这件事从需求到上线整个链路拆开给你一套可以复用的方法论。1. 动手之前的思路拆解1.1 为什么选“登录界面”作为AI开发练习对象登录界面是典型的全栈任务。它不只是一个长得好看的HTML页面背后牵扯到好几层逻辑前端需要做表单校验、状态切换、用户提示后端需要处理鉴权逻辑生成和校验令牌数据库需要存储用户凭证和安全信息安全层面要考虑密码存储方式、防暴力破解、登录状态过期等。一个登录界面能把“CRUD”之外的大量真实工程问题暴露出来。而且它足够小一个下午就能做完非常适合验证AI辅助开发的工作流是否靠谱。另外用户在登录环节的耐心极低。页面样式挫、按钮反馈慢、报错信息看不懂用户直接就跑掉了。所以登录界面还考验开发者对细节和体验的把控——这一点AI生成代码时通常不会主动思考需要你去补足恰好能练习“审查AI代码”的能力。1.2 用AI做开发的核心工作流我实践下来用AI做项目不能指望“一句话生成整个功能”。更稳定的方式是五步工作流拆需求先用自然语言把功能列表写清楚越细越好写提示词按照角色、背景、任务、约束的结构组织描述发给AI生成代码分模块让AI输出代码而不是一次性生成整个项目审查合入每一段代码都要自己过一遍确认逻辑正确、边界处理完善联调迭代跑起来测试把报错信息回传给AI让它修改。这个流程最大的价值在于你不是把责任甩给AI而是让AI当你的编码协作者。重要的决定依然由你来做AI只负责把想法变成代码这样出现问题时你知道往哪里排查。2. AI落地前的提示词准备2.1 一套可复用的提示词模板如果你让AI“写一个登录界面”它大概率给你一个只有HTML和CSS的静态Demo没有逻辑、没有接口。原因是你给的信息太少AI只能按最低标准理解需求。我常用的模板是四段式【角色】 你是一名资深全栈开发者擅长前端工程化和后端安全设计。 【背景】 我正在开发一个跨平台Web应用技术栈是ReactTypeScriptNode.js。 这是我项目中的登录模块需要与后端真实接口联调。 【任务】 请帮我实现一个完整的登录功能包含 1. 前端登录页面支持手机号密码登录包含表单校验、错误提示、加载状态 2. 后端登录接口接收手机号和密码校验成功后返回JWT令牌 3. 密码使用bcrypt加盐存储数据库操作使用已有Prisma schema。 【约束】 - 代码用TypeScript编写风格保持简洁 - 前端使用React Hooks不要用类组件 - 接口返回格式统一为 { code, message, data } - 不要生成测试代码不要生成多余注释。这样写完之后AI输出的内容会明显更聚焦因为它知道你是谁、你在什么项目里、你的技术栈是什么、你要的边界在哪里。2.2 上下文工程让AI记住你的项目背景很多人用AI写代码时有一个共同痛点这次生成的代码和上次生成的代码风格不一致甚至互相冲突。原因在于AI没有记忆每次对话都是一次全新开始。解决这个问题我建议在项目目录下维护一个project-context.md文件把项目情况固定下来项目模拟跨平台系统 前端React 18 TypeScript Vite 后端Node.js Express Prisma MySQL 认证方案JWT短期访问令牌 Refresh Token长期刷新令牌 状态管理Zustand UI组件自研组件库不使用第三方UI库 接口约定统一返回 { code, message, data }每次开始新对话时先把这段上下文发给AI再提具体需求。实测下来AI生成的代码贴合度能提升一个量级几乎不用做结构性返工。提示词和上下文准备到位之后AI输出的“底子”就会好很多。接下来真正动手实操看看AI生成的代码长什么样、要改什么地方。3. 实操过程AI从零生成登录模块3.1 前端登录页面生成我在某次模拟项目里让AI按照上述模板生成了前端登录页面。它给出的React组件核心代码如下这是基于常见实践的补充示例// 登录页面核心逻辑 const handleSubmit async (values: LoginFormValues) { setLoading(true); try { const response await loginRequest(values); authStore.setTokens(response.data.accessToken, response.data.refreshToken); navigate(/dashboard, { replace: true }); } catch (error) { if (error instanceof ApiError error.code AUTH_FAILED) { setFormError(手机号或密码错误请重新输入); } else { setFormError(网络异常请稍后重试); } } finally { setLoading(false); } };这版代码的逻辑是对的调用接口前设置loading成功跳转失败区分错误类型最后在finally里恢复按钮状态。说明AI对“异步流程处理”这样的通用场景已经掌握得不错。不过只让AI生成到“能跑”是不够的。我要求它补充了登出逻辑、会话过期自动跳转这两个能力请在现有登录模块基础上 1. 增加token过期检测接口返回401时自动调用刷新令牌接口 2. 刷新仍然失败则清空本地登录态跳转回登录页 3. 在页面顶部增加一个用户菜单包含“退出登录”按钮。这个迭代过程很顺因为上下文没有断AI知道之前生成了什么所以它给出的改动能直接嵌进已有的代码结构里。3.2 后端登录接口生成后端接口这块AI生成的代码大致如下按实际项目结构整理过// 登录接口服务层 export async function loginWithPassword(phone: string, password: string) { const user await findUserByPhone(phone); if (!user) { throw new ApiError(AUTH_FAILED, 手机号或密码错误); } const isValid await comparePassword(password, user.passwordHash); if (!isValid) { throw new ApiError(AUTH_FAILED, 手机号或密码错误); } if (user.status ! 1) { throw new ApiError(ACCOUNT_DISABLED, 账号已被停用); } const accessToken signAccessToken({ uid: user.id, role: user.role }); const refreshToken signRefreshToken({ uid: user.id }); await saveRefreshToken(user.id, refreshToken); return { accessToken, refreshToken, userInfo: buildPublicUser(user) }; }这段代码让我比较满意的地方是它在“用户不存在”和“密码错误”时返回了同样的错误文案避免通过接口探测账号是否存在这是安全检查的基本功AI能自动写出来说明训练数据里包含了不少规范的代码模式。3.3 前后端联调的关键细节代码生成之后联调阶段有几个容易忽略的点AI帮你写代码时大概率也不会主动想到状态码规范成功都走200业务错误统一用code字段区分这样前端处理逻辑会非常干净超时时间登录接口设置了10秒超时避免弱网环境下卡死loading防重复提交按钮loading状态开启后要禁用否则用户双击会发出两个请求。这些细节不是AI能凭空生成的需要你在需求描述里提出来或者代码生成后自己补充。这也是为什么我一直强调AI写的代码只是一个良好的起点真正的工程质量还是要靠人来把关。4. 登录模块的安全与边界处理4.1 密码存储不要自己发明算法在密码存储这件事上最常见的错误是自己拼一个“加盐哈希”算法或者用简单的MD5/SHA1。MD5和SHA1本身不是为密码散列设计的计算速度太快暴力破解的性价比太高。正确做法是使用专门的密码哈希算法和标准的加盐机制。我让AI生成的是基于bcrypt的实现关键代码如下// 使用bcrypt进行密码哈希和校验 const SALT_ROUNDS 10; export async function hashPassword(plainPassword: string) { return bcrypt.hash(plainPassword, SALT_ROUNDS); } export async function comparePassword(plainPassword: string, hashedPassword: string) { return bcrypt.compare(plainPassword, hashedPassword); }这里的SALT_ROUNDS 10不是随手写的。它代表bcrypt内部加盐和哈希的迭代次数10轮在主流服务器上的耗时大约在50-100毫秒。这个量级对用户体验几乎无感但能让暴力破解的尝试频率被压制到极低水平。轮数太高比如15反而会让正常的登录请求也变慢得不偿失。4.2 令牌机制短期访问令牌长期刷新令牌登录成功后不能只发一个token就不用管了。token有效期太短用户天天要重新登录太长token泄露后风险很大。实践中通用的方案是双token机制访问令牌access token有效期设为2小时前端每次接口请求都带上它刷新令牌refresh token有效期设为7天只在访问令牌过期时使用用于换取新的访问令牌。这样做的好处是就算攻击者拿到了访问令牌它的有效期有限损失可控。而刷新令牌虽然有效时间长但没有被前端业务代码直接使用只有在特定接口才会暴露风险面小得多。我对AI的要求很明确AI也给出了一套可用的刷新逻辑请为后端补充一个POST /auth/refresh接口 - 接收refreshToken - 校验refreshToken合法性并从存储中比对是否匹配 - 校验通过则重新签发访问令牌 - 如果refreshToken不存在或已过期返回401前端需要重新登录。生成出来的代码里有一点做得很好保存refreshToken时做了“一次性消费”的处理——每次刷新成功后旧的刷新令牌立即作废并换发新令牌防止令牌重放。4.3 防暴力破解与登录日志AI生成的登录接口默认没有防爆破能力需要额外补充。我按照一个通行做法让AI实现连续失败锁定同一手机号连续5次密码错误锁定15分钟验证码弹出同一IP当天登录失败超过10次强制要求图片验证码登录日志记录每次登录成功/失败的时间、IP、设备信息审计时能追溯。// 登录失败计数逻辑Redis实现 export async function recordLoginFailure(phone: string) { const key login_fail:${phone}; const count await redis.incr(key); if (count 1) { await redis.expire(key, LOGIN_FAIL_WINDOW_SECONDS); } if (count MAX_FAIL_COUNT) { await redis.set(login_lock:${phone}, 1, EX, LOCK_SECONDS); await redis.del(key); } return count; }这个流程清晰而且AI生成的代码基本可以直接用。不过需要特别注意锁定逻辑千万不能出现数据竞态——如果两次请求同时读取到失败次数是4都会放行就会破坏锁定机制。最终方案是让Redis的incr命令保证计数原子性这里是我手动修正的AI不会主动考虑并发问题。5. 常见问题与排查实录AI开发登录界面最常见的坑不在地基而在各种细节的接缝处。我整理了一份问题速查表都是实际遇到过的。典型问题出现原因排查思路与解法前端能跑但登录接口一直报500后端没有同步创建用户表或密码字段类型不对检查数据库迁移是否执行确认密码长度字段足够容纳bcrypt哈希登录成功后刷新页面就变回未登录状态本地存储的token键名前后端不一致统一token键名优先从localStorage读取并做存在性校验移动端页面点击登录按钮没反应输入框被浏览器自动填充事件覆盖button的type被默认成submit导致整页刷新显式设置typebutton对表单提交事件调用preventDefault密码错误提示“系统异常”后端的错误被统一捕获后丢掉了业务错误码全局异常处理里先判断是否为ApiError是则返回业务code否则返回系统错误切换账号登录后拿到的是上一个用户的信息前端全局状态未清理退出登录时清空所有用户相关的store字段不只是清token5.1 排查实例AI生成的代码为什么在移动端失效有次调试时发现AI生成的登录按钮在移动端点击后页面会刷新但桌面端表现正常。排查过程是这样的先看浏览器console发现没有任何报错再看Network面板发现请求根本没发出去而是页面主动刷新了。问题出在AI生成的代码只写了onClick事件没有管button默认行为。在PC端浏览器里button不带type属性时默认为submit但页面上没有form包裹所以没有副作用。到了移动端浏览器对缺失type的button更激进触发了隐式提交。修法很简单给button加上typebutton或者把表单提交事件统一用handleSubmit接管。这种问题AI很难提前判断需要你在自测阶段用真实移动设备走一遍流程。5.2 排查实例后端密码字段长度不足另一个高频翻车点AI生成的Prisma模型里密码字段用的是String default()没有明确长度。MySQL里默认的varchar(191)存普通密码没问题但bcrypt生成的哈希字符串长度是60个字符包含$2b$10$这样的前缀再加上盐值超出默认长度后数据库会直接截断。现象是用户注册时密码能写入但登录时校验永远失败因为存进去的哈希已经被截断了。解决办法是建表前明确约束model User { id Int id default(autoincrement()) phone String unique passwordHash String db.VarChar(128) status Int default(1) createdAt DateTime default(now()) updatedAt DateTime updatedAt }这类问题如果按照“AI生成代码→直接跑”的流程会浪费大量时间在奇怪的故障上。所以自检时必须具备一个审视清单字段类型、字段长度、默认值、唯一约束、索引。AI写代码时不会有意识地做这些数据库层面的考量。5.3 排查实例登录报错但接口200这种问题最迷惑人。页面始终提示“登录失败”但Network面板里请求状态是200。原因是AI生成的代码里后端返回统一结构{ code, message, data }业务失败时HTTP状态码依然用了200而前端只在HTTP ! 200时才进入错误分支。我在联调时让AI修正了这种处理方式。前端在拿到响应后首先判断code字段是否等于约定的成功值而不是看HTTP状态码。这是一个约定问题前后端必须对齐否则就会产生这类“接口通但事没办成”的假象。6. 用AI做登录模块的经验小结当前面这些步骤都走完登录模块基本上就具备上线条件了。回过头看用AI做这个模块的价值不只是“写代码快”它更重要的作用是帮你把脑海里模糊的方案快速变成可运行的东西然后你基于一个看得见摸得着的雏形去迭代、去修正。在这个过程中我有几个比较深刻的体会。第一AI写代码的能力确实强但它不会替你思考需求边界。你如果只是说“做一个登录”那它给你的就是千篇一律的模板当你把技术栈、接口约定、安全要求、错误处理策略都写清楚它产出的东西才真正贴合你的项目。第二代码审查是不可省略的环节。AI可能写出字段长度不够、并发处理缺失、错误码不一致这类问题。学会用审查清单去审视AI代码比学会让AI写代码更重要。第三安全因素必须自己把关。AI会给你一个能跑的登录接口但不会主动告诉你登录失败次数要不要限制、令牌要不要过期、刷新令牌要不要一次性。这些问题得靠你的工程判断来补。另外给一个实用的收尾技巧模块开发完成后把本次AI对话里那些有效的提示词和上下文存下来下次做注册、找回密码、个人中心这些模块时你就能直接复用一整套风格一致的代码不用再重新解释一遍项目背景。登录界面作为一个切入点已经能把AI辅助开发的核心套路跑通。下一步可以去挑战更有意思的部分比如权限控制的动态路由、多因素认证、第三方OAuth接入。不过那些都是后话了先把眼前这个登录做好用户进来的第一道门顺畅了后面的一切才有机会发生。 
长河君 · 2026/10/18 15:10:21 · 阅读 1.2k AI辅助开发登录界面：全栈流程、安全细节与实战方法论
在上一篇文章里我把“用AI做开发”这件事的整体思路理了一遍包括怎么拆分需求、怎么给AI描述任务、怎么把AI输出的代码整合进项目。这篇继续推进聚焦一个所有人都会碰到、但很少有人真正做扎实的场景登录界面。登录界面看起来简单无非一个手机号/邮箱输入框、一个密码框、一个登录按钮顶多再加个“记住我”。但一旦进入真实项目事情就没那么轻松了前端要处理表单校验、错误状态、加载状态后端要处理接口鉴权、密码加密、会话过期、刷新令牌中间的联调还要考虑超时、网络异常、设备兼容。任何一个环节掉了链子用户第一眼就会觉得“这产品不靠谱”。而AI在这个场景里能帮上大忙前提是你知道怎么指挥它。这篇把我实际操作中验证过的流程完整走一遍包括提示词怎么写、代码怎么生成、接口怎么联调、坑都踩在哪里。这篇的内容不是让你复制一段代码就跑路而是把“用AI做登录界面”这件事从需求到上线整个链路拆开给你一套可以复用的方法论。1. 动手之前的思路拆解1.1 为什么选“登录界面”作为AI开发练习对象登录界面是典型的全栈任务。它不只是一个长得好看的HTML页面背后牵扯到好几层逻辑前端需要做表单校验、状态切换、用户提示后端需要处理鉴权逻辑生成和校验令牌数据库需要存储用户凭证和安全信息安全层面要考虑密码存储方式、防暴力破解、登录状态过期等。一个登录界面能把“CRUD”之外的大量真实工程问题暴露出来。而且它足够小一个下午就能做完非常适合验证AI辅助开发的工作流是否靠谱。另外用户在登录环节的耐心极低。页面样式挫、按钮反馈慢、报错信息看不懂用户直接就跑掉了。所以登录界面还考验开发者对细节和体验的把控——这一点AI生成代码时通常不会主动思考需要你去补足恰好能练习“审查AI代码”的能力。1.2 用AI做开发的核心工作流我实践下来用AI做项目不能指望“一句话生成整个功能”。更稳定的方式是五步工作流拆需求先用自然语言把功能列表写清楚越细越好写提示词按照角色、背景、任务、约束的结构组织描述发给AI生成代码分模块让AI输出代码而不是一次性生成整个项目审查合入每一段代码都要自己过一遍确认逻辑正确、边界处理完善联调迭代跑起来测试把报错信息回传给AI让它修改。这个流程最大的价值在于你不是把责任甩给AI而是让AI当你的编码协作者。重要的决定依然由你来做AI只负责把想法变成代码这样出现问题时你知道往哪里排查。2. AI落地前的提示词准备2.1 一套可复用的提示词模板如果你让AI“写一个登录界面”它大概率给你一个只有HTML和CSS的静态Demo没有逻辑、没有接口。原因是你给的信息太少AI只能按最低标准理解需求。我常用的模板是四段式【角色】 你是一名资深全栈开发者擅长前端工程化和后端安全设计。 【背景】 我正在开发一个跨平台Web应用技术栈是ReactTypeScriptNode.js。 这是我项目中的登录模块需要与后端真实接口联调。 【任务】 请帮我实现一个完整的登录功能包含 1. 前端登录页面支持手机号密码登录包含表单校验、错误提示、加载状态 2. 后端登录接口接收手机号和密码校验成功后返回JWT令牌 3. 密码使用bcrypt加盐存储数据库操作使用已有Prisma schema。 【约束】 - 代码用TypeScript编写风格保持简洁 - 前端使用React Hooks不要用类组件 - 接口返回格式统一为 { code, message, data } - 不要生成测试代码不要生成多余注释。这样写完之后AI输出的内容会明显更聚焦因为它知道你是谁、你在什么项目里、你的技术栈是什么、你要的边界在哪里。2.2 上下文工程让AI记住你的项目背景很多人用AI写代码时有一个共同痛点这次生成的代码和上次生成的代码风格不一致甚至互相冲突。原因在于AI没有记忆每次对话都是一次全新开始。解决这个问题我建议在项目目录下维护一个project-context.md文件把项目情况固定下来项目模拟跨平台系统 前端React 18 TypeScript Vite 后端Node.js Express Prisma MySQL 认证方案JWT短期访问令牌 Refresh Token长期刷新令牌 状态管理Zustand UI组件自研组件库不使用第三方UI库 接口约定统一返回 { code, message, data }每次开始新对话时先把这段上下文发给AI再提具体需求。实测下来AI生成的代码贴合度能提升一个量级几乎不用做结构性返工。提示词和上下文准备到位之后AI输出的“底子”就会好很多。接下来真正动手实操看看AI生成的代码长什么样、要改什么地方。3. 实操过程AI从零生成登录模块3.1 前端登录页面生成我在某次模拟项目里让AI按照上述模板生成了前端登录页面。它给出的React组件核心代码如下这是基于常见实践的补充示例// 登录页面核心逻辑 const handleSubmit async (values: LoginFormValues) { setLoading(true); try { const response await loginRequest(values); authStore.setTokens(response.data.accessToken, response.data.refreshToken); navigate(/dashboard, { replace: true }); } catch (error) { if (error instanceof ApiError error.code AUTH_FAILED) { setFormError(手机号或密码错误请重新输入); } else { setFormError(网络异常请稍后重试); } } finally { setLoading(false); } };这版代码的逻辑是对的调用接口前设置loading成功跳转失败区分错误类型最后在finally里恢复按钮状态。说明AI对“异步流程处理”这样的通用场景已经掌握得不错。不过只让AI生成到“能跑”是不够的。我要求它补充了登出逻辑、会话过期自动跳转这两个能力请在现有登录模块基础上 1. 增加token过期检测接口返回401时自动调用刷新令牌接口 2. 刷新仍然失败则清空本地登录态跳转回登录页 3. 在页面顶部增加一个用户菜单包含“退出登录”按钮。这个迭代过程很顺因为上下文没有断AI知道之前生成了什么所以它给出的改动能直接嵌进已有的代码结构里。3.2 后端登录接口生成后端接口这块AI生成的代码大致如下按实际项目结构整理过// 登录接口服务层 export async function loginWithPassword(phone: string, password: string) { const user await findUserByPhone(phone); if (!user) { throw new ApiError(AUTH_FAILED, 手机号或密码错误); } const isValid await comparePassword(password, user.passwordHash); if (!isValid) { throw new ApiError(AUTH_FAILED, 手机号或密码错误); } if (user.status ! 1) { throw new ApiError(ACCOUNT_DISABLED, 账号已被停用); } const accessToken signAccessToken({ uid: user.id, role: user.role }); const refreshToken signRefreshToken({ uid: user.id }); await saveRefreshToken(user.id, refreshToken); return { accessToken, refreshToken, userInfo: buildPublicUser(user) }; }这段代码让我比较满意的地方是它在“用户不存在”和“密码错误”时返回了同样的错误文案避免通过接口探测账号是否存在这是安全检查的基本功AI能自动写出来说明训练数据里包含了不少规范的代码模式。3.3 前后端联调的关键细节代码生成之后联调阶段有几个容易忽略的点AI帮你写代码时大概率也不会主动想到状态码规范成功都走200业务错误统一用code字段区分这样前端处理逻辑会非常干净超时时间登录接口设置了10秒超时避免弱网环境下卡死loading防重复提交按钮loading状态开启后要禁用否则用户双击会发出两个请求。这些细节不是AI能凭空生成的需要你在需求描述里提出来或者代码生成后自己补充。这也是为什么我一直强调AI写的代码只是一个良好的起点真正的工程质量还是要靠人来把关。4. 登录模块的安全与边界处理4.1 密码存储不要自己发明算法在密码存储这件事上最常见的错误是自己拼一个“加盐哈希”算法或者用简单的MD5/SHA1。MD5和SHA1本身不是为密码散列设计的计算速度太快暴力破解的性价比太高。正确做法是使用专门的密码哈希算法和标准的加盐机制。我让AI生成的是基于bcrypt的实现关键代码如下// 使用bcrypt进行密码哈希和校验 const SALT_ROUNDS 10; export async function hashPassword(plainPassword: string) { return bcrypt.hash(plainPassword, SALT_ROUNDS); } export async function comparePassword(plainPassword: string, hashedPassword: string) { return bcrypt.compare(plainPassword, hashedPassword); }这里的SALT_ROUNDS 10不是随手写的。它代表bcrypt内部加盐和哈希的迭代次数10轮在主流服务器上的耗时大约在50-100毫秒。这个量级对用户体验几乎无感但能让暴力破解的尝试频率被压制到极低水平。轮数太高比如15反而会让正常的登录请求也变慢得不偿失。4.2 令牌机制短期访问令牌长期刷新令牌登录成功后不能只发一个token就不用管了。token有效期太短用户天天要重新登录太长token泄露后风险很大。实践中通用的方案是双token机制访问令牌access token有效期设为2小时前端每次接口请求都带上它刷新令牌refresh token有效期设为7天只在访问令牌过期时使用用于换取新的访问令牌。这样做的好处是就算攻击者拿到了访问令牌它的有效期有限损失可控。而刷新令牌虽然有效时间长但没有被前端业务代码直接使用只有在特定接口才会暴露风险面小得多。我对AI的要求很明确AI也给出了一套可用的刷新逻辑请为后端补充一个POST /auth/refresh接口 - 接收refreshToken - 校验refreshToken合法性并从存储中比对是否匹配 - 校验通过则重新签发访问令牌 - 如果refreshToken不存在或已过期返回401前端需要重新登录。生成出来的代码里有一点做得很好保存refreshToken时做了“一次性消费”的处理——每次刷新成功后旧的刷新令牌立即作废并换发新令牌防止令牌重放。4.3 防暴力破解与登录日志AI生成的登录接口默认没有防爆破能力需要额外补充。我按照一个通行做法让AI实现连续失败锁定同一手机号连续5次密码错误锁定15分钟验证码弹出同一IP当天登录失败超过10次强制要求图片验证码登录日志记录每次登录成功/失败的时间、IP、设备信息审计时能追溯。// 登录失败计数逻辑Redis实现 export async function recordLoginFailure(phone: string) { const key login_fail:${phone}; const count await redis.incr(key); if (count 1) { await redis.expire(key, LOGIN_FAIL_WINDOW_SECONDS); } if (count MAX_FAIL_COUNT) { await redis.set(login_lock:${phone}, 1, EX, LOCK_SECONDS); await redis.del(key); } return count; }这个流程清晰而且AI生成的代码基本可以直接用。不过需要特别注意锁定逻辑千万不能出现数据竞态——如果两次请求同时读取到失败次数是4都会放行就会破坏锁定机制。最终方案是让Redis的incr命令保证计数原子性这里是我手动修正的AI不会主动考虑并发问题。5. 常见问题与排查实录AI开发登录界面最常见的坑不在地基而在各种细节的接缝处。我整理了一份问题速查表都是实际遇到过的。典型问题出现原因排查思路与解法前端能跑但登录接口一直报500后端没有同步创建用户表或密码字段类型不对检查数据库迁移是否执行确认密码长度字段足够容纳bcrypt哈希登录成功后刷新页面就变回未登录状态本地存储的token键名前后端不一致统一token键名优先从localStorage读取并做存在性校验移动端页面点击登录按钮没反应输入框被浏览器自动填充事件覆盖button的type被默认成submit导致整页刷新显式设置typebutton对表单提交事件调用preventDefault密码错误提示“系统异常”后端的错误被统一捕获后丢掉了业务错误码全局异常处理里先判断是否为ApiError是则返回业务code否则返回系统错误切换账号登录后拿到的是上一个用户的信息前端全局状态未清理退出登录时清空所有用户相关的store字段不只是清token5.1 排查实例AI生成的代码为什么在移动端失效有次调试时发现AI生成的登录按钮在移动端点击后页面会刷新但桌面端表现正常。排查过程是这样的先看浏览器console发现没有任何报错再看Network面板发现请求根本没发出去而是页面主动刷新了。问题出在AI生成的代码只写了onClick事件没有管button默认行为。在PC端浏览器里button不带type属性时默认为submit但页面上没有form包裹所以没有副作用。到了移动端浏览器对缺失type的button更激进触发了隐式提交。修法很简单给button加上typebutton或者把表单提交事件统一用handleSubmit接管。这种问题AI很难提前判断需要你在自测阶段用真实移动设备走一遍流程。5.2 排查实例后端密码字段长度不足另一个高频翻车点AI生成的Prisma模型里密码字段用的是String default()没有明确长度。MySQL里默认的varchar(191)存普通密码没问题但bcrypt生成的哈希字符串长度是60个字符包含$2b$10$这样的前缀再加上盐值超出默认长度后数据库会直接截断。现象是用户注册时密码能写入但登录时校验永远失败因为存进去的哈希已经被截断了。解决办法是建表前明确约束model User { id Int id default(autoincrement()) phone String unique passwordHash String db.VarChar(128) status Int default(1) createdAt DateTime default(now()) updatedAt DateTime updatedAt }这类问题如果按照“AI生成代码→直接跑”的流程会浪费大量时间在奇怪的故障上。所以自检时必须具备一个审视清单字段类型、字段长度、默认值、唯一约束、索引。AI写代码时不会有意识地做这些数据库层面的考量。5.3 排查实例登录报错但接口200这种问题最迷惑人。页面始终提示“登录失败”但Network面板里请求状态是200。原因是AI生成的代码里后端返回统一结构{ code, message, data }业务失败时HTTP状态码依然用了200而前端只在HTTP ! 200时才进入错误分支。我在联调时让AI修正了这种处理方式。前端在拿到响应后首先判断code字段是否等于约定的成功值而不是看HTTP状态码。这是一个约定问题前后端必须对齐否则就会产生这类“接口通但事没办成”的假象。6. 用AI做登录模块的经验小结当前面这些步骤都走完登录模块基本上就具备上线条件了。回过头看用AI做这个模块的价值不只是“写代码快”它更重要的作用是帮你把脑海里模糊的方案快速变成可运行的东西然后你基于一个看得见摸得着的雏形去迭代、去修正。在这个过程中我有几个比较深刻的体会。第一AI写代码的能力确实强但它不会替你思考需求边界。你如果只是说“做一个登录”那它给你的就是千篇一律的模板当你把技术栈、接口约定、安全要求、错误处理策略都写清楚它产出的东西才真正贴合你的项目。第二代码审查是不可省略的环节。AI可能写出字段长度不够、并发处理缺失、错误码不一致这类问题。学会用审查清单去审视AI代码比学会让AI写代码更重要。第三安全因素必须自己把关。AI会给你一个能跑的登录接口但不会主动告诉你登录失败次数要不要限制、令牌要不要过期、刷新令牌要不要一次性。这些问题得靠你的工程判断来补。另外给一个实用的收尾技巧模块开发完成后把本次AI对话里那些有效的提示词和上下文存下来下次做注册、找回密码、个人中心这些模块时你就能直接复用一整套风格一致的代码不用再重新解释一遍项目背景。登录界面作为一个切入点已经能把AI辅助开发的核心套路跑通。下一步可以去挑战更有意思的部分比如权限控制的动态路由、多因素认证、第三方OAuth接入。不过那些都是后话了先把眼前这个登录做好用户进来的第一道门顺畅了后面的一切才有机会发生。