企业官网建设流程全解析

在上一篇文章里，我把“用AI做开发”这件事的整体思路理了一遍，包括怎么拆分需求、怎么给AI描述任务、怎么把AI输出的代码整合进项目。这篇继续推进，聚焦一个所有人都会碰到、但很少有人真正做扎实的场景：登录界面。

登录界面看起来简单，无非一个手机号/邮箱输入框、一个密码框、一个登录按钮，顶多再加个“记住我”。但一旦进入真实项目，事情就没那么轻松了：前端要处理表单校验、错误状态、加载状态；后端要处理接口鉴权、密码加密、会话过期、刷新令牌；中间的联调还要考虑超时、网络异常、设备兼容。任何一个环节掉了链子，用户第一眼就会觉得“这产品不靠谱”。

而AI在这个场景里能帮上大忙，前提是你知道怎么指挥它。这篇把我实际操作中验证过的流程完整走一遍，包括提示词怎么写、代码怎么生成、接口怎么联调、坑都踩在哪里。这篇的内容不是让你复制一段代码就跑路，而是把“用AI做登录界面”这件事从需求到上线整个链路拆开，给你一套可以复用的方法论。

1. 动手之前的思路拆解

1.1 为什么选“登录界面”作为AI开发练习对象

登录界面是典型的全栈任务。它不只是一个长得好看的HTML页面，背后牵扯到好几层逻辑：

• 前端需要做表单校验、状态切换、用户提示；
• 后端需要处理鉴权逻辑，生成和校验令牌；
• 数据库需要存储用户凭证和安全信息；
• 安全层面要考虑密码存储方式、防暴力破解、登录状态过期等。

一个登录界面能把“CRUD”之外的大量真实工程问题暴露出来。而且它足够小，一个下午就能做完，非常适合验证AI辅助开发的工作流是否靠谱。

另外，用户在登录环节的耐心极低。页面样式挫、按钮反馈慢、报错信息看不懂，用户直接就跑掉了。所以登录界面还考验开发者对细节和体验的把控——这一点AI生成代码时通常不会主动思考，需要你去补足，恰好能练习“审查AI代码”的能力。

1.2 用AI做开发的核心工作流

我实践下来，用AI做项目不能指望“一句话生成整个功能”。更稳定的方式是五步工作流：

1. 拆需求：先用自然语言把功能列表写清楚，越细越好；
2. 写提示词：按照角色、背景、任务、约束的结构组织描述，发给AI；
3. 生成代码：分模块让AI输出代码，而不是一次性生成整个项目；
4. 审查合入：每一段代码都要自己过一遍，确认逻辑正确、边界处理完善；
5. 联调迭代：跑起来测试，把报错信息回传给AI，让它修改。

这个流程最大的价值在于，你不是把责任甩给AI，而是让AI当你的编码协作者。重要的决定依然由你来做，AI只负责把想法变成代码，这样出现问题时你知道往哪里排查。

2. AI落地前的提示词准备

2.1 一套可复用的提示词模板

如果你让AI“写一个登录界面”，它大概率给你一个只有HTML和CSS的静态Demo，没有逻辑、没有接口。原因是你给的信息太少，AI只能按最低标准理解需求。

我常用的模板是四段式：

【角色】 你是一名资深全栈开发者，擅长前端工程化和后端安全设计。 【背景】 我正在开发一个跨平台Web应用，技术栈是React+TypeScript+Node.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开发登录界面，最常见的坑不在地基，而在各种细节的接缝处。我整理了一份问题速查表，都是实际遇到过的。

5.1 排查实例：AI生成的代码为什么在移动端失效

有次调试时发现，AI生成的登录按钮在移动端点击后页面会刷新，但桌面端表现正常。排查过程是这样的：先看浏览器console，发现没有任何报错；再看Network面板，发现请求根本没发出去，而是页面主动刷新了。

问题出在AI生成的代码只写了onClick事件，没有管button默认行为。在PC端浏览器里，<button>不带type属性时默认为submit，但页面上没有form包裹，所以没有副作用。到了移动端，浏览器对缺失type的button更激进，触发了隐式提交。

修法很简单，给<button>加上type="button"，或者把表单提交事件统一用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接入。不过那些都是后话了，先把眼前这个登录做好，用户进来的第一道门顺畅了，后面的一切才有机会发生。