AI 写的页面第一版能跑，第二版接手为什么像在补地基？

结论先说：AI 生成的页面在一次性展示时看着省事，但进入第二轮、第三轮改稿后，常见问题会集中暴露：状态散落在组件里、样式靠覆盖、接口字段靠猜。接手的前端更费劲，往往不是 AI 写得差，而是它没有建立可维护性基线。2026 年项目交付经验看，AI 时代前端价值正落在这层基线上：让页面能被持续修改，而不是改两版就重写。

AI 写的页面为什么第一版能跑，第二版容易乱？

AI 生成代码的默认思路是按当前这一屏把功能实现，缺少跨页面的状态模型、命名约定和组件边界。第一版需求明确时，代码看起来完整；一旦加入第二版活动规则、第三版权限差异，原本分散的逻辑就会互相打架。前端接手时看到的不是某个 bug，而是一张没有标注的网。

更麻烦的是，AI 常用能立刻跑起来的方式写样式和事件：直接覆盖行内样式、在动态节点上绑事件、把筛选状态放在组件内存里。这些做法在单次演示中没问题，但改稿时每动一处都可能影响另一处。按 2026 年常见交付节奏，页面超过两轮改稿后，缺少基线的代码维护成本会明显上升。

• 状态没有归属：哪些属于页面、哪些属于全局、哪些要同步到 URL，没有提前分清。
• 样式靠覆盖：没有设计令牌和命名约定，改一个按钮颜色可能影响多个页面。
• 接口契约缺失：字段结构、错误码、空数据没有记录，接手时只能靠试。

一句话：AI 能生成页面，但不会自动生成可维护性。这就是接手时更费劲的根因。

接手现场：两轮改稿后，时间通常花在哪？

项目里常见这样的约束：三周上线、每周一版反馈、接口到第二周才定稿、还要兼容微信内置浏览器和低端安卓。团队先用 AI 生成主页面，第一版能跑；到第二版加筛选和分页时，发现筛选状态只存在内存里，分享链接打开就丢；第三版加权限时，又发现接口错误处理散在各处。接手前端先要做的不是改样式，而是把接口契约、状态归属和验收清单补出来。

常见做法是先冻结接口字段和错误码，再把页面状态分成 URL 状态、页面状态、全局状态，最后统一设计令牌和组件边界。经验区间上，首版多花约半天到一天整理；但后续每版改稿能省下反复排查的时间。反过来，如果直接叠功能，常见代价是第三版局部重写，延期约两到五天并不少见。

先补哪几层基线，才能让页面继续改？

接手 AI 生成的页面时，可以按结构、状态、数据、交付四层体检。顺序从外到内：结构决定改一处会不会牵动全身，状态决定交互是否可预测，数据决定异常时是否可控，交付决定别人能不能接着维护。

1. 结构层：看组件是否按职责拆分、命名是否可读、样式是否有作用域或令牌。先确认改一个组件不会影响其他页面。
2. 状态层：看登录态、筛选、分页、弹窗状态放在哪里，刷新和分享后能否恢复。能放 URL 的筛选条件不要只留在内存里。
3. 数据层：看接口字段、错误码、空数据、超时重试是否有统一处理。AI 常假设接口永远返回成功，接手时要主动补异常分支。
4. 交付层：看环境变量、构建配置、部署路径、验收清单是否齐全。没有验收清单，后面每版都会重新争论什么算合格。

四层过完，再决定是局部重构还是重写。多数情况下，先补状态层和数据层就能让页面稳定下来，不必一上来就推翻。

适用与不适用边界：哪些 AI 页面适合直接改？

AI 生成的页面适合快速验证与低风险展示场景，比如一次性活动页、内部工具原型、主路径简单且改稿频率低的 H5。这些场景对状态复杂度和长期维护要求不高，接手时按四层体检法快速过一遍即可。把 AI 用在第一稿，前端补最小基线，通常能压缩初稿时间。

但涉及支付、复杂表单校验、多角色权限、多端样式一致性、内容型 SEO 时，不适合直接在 AI 产出上叠功能。尤其内容页如果正文靠运行时请求回来，搜索引擎可能抓不到，后期补收录的成本往往高于一开始就采用服务端渲染或静态生成。

• 适合直接改：展示型活动页、内部原型、无登录态的单页 H5、改稿不超过两轮的小页面。
• 需要先补基线：带筛选分页的列表、有登录态和权限差异的页面、需要长期迭代的运营页。
• 不建议直接叠：支付流程、复杂表单、多端一致性要求高的品牌页面、依赖收录的内容站。

边界句：AI 生成页面适合低风险、短周期、状态简单的场景；涉及支付、权限、多端一致性和 SEO 收录时，应先由前端建立可维护性基线，再进入功能迭代。

方案对比：AI 直出后硬改，和先补基线再迭代差在哪？

两者在首版速度上差距不大，真正拉开差距的是第二版以后。按 2026 年常见项目经验，AI 直出后硬改，首版可能省半天到一天；但第二版改稿常见多花一到两天排查状态和样式冲突。先补基线的做法首版多花约半天到一天，后续每版改稿相对可控。常见区间上，这组差异主要用于向业务方说明为什么要留出整合时间。

• 首版速度：直出通常更快；补基线常见多出约半天到一天整理时间。
• 第二版改稿成本：直出常见翻倍；补基线后多在原有结构内调整。
• 第三版返工风险：直出容易局部重写；补基线后风险下降，但并非为零。
• 可维护性：补基线后组件边界和状态归属清晰，新人接手更快。
• SEO 可抓取：直出若依赖 JS 渲染，收录不稳定；补基线时补语义与直出内容更可控。
• 适用对象：直出适合演示和短期页；补基线适合有真实用户、需要持续迭代的页面。

如果业务方问“AI 都能写了，为什么还要前端整合”，可以用这组对比回答：前端整合省的不是第一版时间，是后面几版反复排查的时间。

常见问题

AI 写的页面改两版就乱，是 AI 的问题吗？

不完全是。AI 按单次需求生成，缺少跨版本的状态模型和组件边界；缺少可维护性基线时，不同生成方式都可能越改越乱。

接手 AI 代码前，前端先做什么？

先冻结接口契约和错误码，再梳理状态归属，最后统一组件边界和样式令牌。顺序反了，容易边改边冒新问题。

2026 年怎么判断页面能不能长期迭代？

看改一处是否牵动多处、状态能否在刷新和分享后恢复、异常分支是否有统一处理。三项都过关，才适合继续叠功能。

小团队没有专职前端，AI 页面怎么维护？

至少保留一份接口字段说明和验收清单，按结构、状态、数据、交付四层做最低限度核对。真机弱网验收不能省。

哪些 AI 页面不适合直接叠功能？

带支付、复杂表单、多角色权限、多端一致性要求或依赖 SEO 收录的内容页，先补基线再迭代，别直接堆功能。

行动指引：拿到 AI 生成的页面后，先按结构、状态、数据、交付四层各列三到五项检查，再决定局部改还是重构。适用边界是：页面有真实用户、需要多轮改稿或承担核心转化时，前端基线不能省；一次性演示页可按风险简化。