《AI 写的前端代码为什么总是“能用但难维护”—— 一个 productdemo.html 的架构评审实录二》作者咏方舟-长江之流日期2026-07-111. 引言从“能用”到“好用”的距离在上一篇《AI 写的前端代码长什么样—— productdemo.html 的CRUD功能演示一》中我们完整展示了一个由 AI 生成的产品管理页面界面精致、功能齐全、交互流畅开箱即用堪称“快速原型”的典范。包括全部源码大家可以去查看。但我也在文末留了一个问题这样的代码真的可以直接上线、长期维护吗答案是否定的。如果说第一篇是“展示产品的光鲜外表”那么这一篇就是“拆开机器看内部构造”。今天我将以架构评审的视角逐条剖析这份代码在扩展性、可维护性、复用性、团队协作四个维度上的深层问题。一句话概括我的评价AI 生成的productdemo.html能用但属于「一次性演示代码」不具备架构级扩展能力。目前我正在推进的一项核心工作是将此前基于 XML 配置的报表与 CRUD 功能模块整体迁移至Visual Studio 2026开发平台并对底层架构进行深度优化重构。这次重构的关键在于选用.NET Standard作为底层基础库的规范标准。.NET Standard 是跨所有 .NET 实现的统一接口规范相当于一份“API 契约”基于它编写的类库可以被两类运行时同时调用一类是 Windows 专属的经典运行时.NET Framework另一类是跨平台的新一代运行时实现.NET Core现已统称为 .NET 5。通过这一架构设计我希望在兼容现有 Windows 生态的同时也为未来的跨平台部署留出充分空间让“配置驱动”的前端方案能够真正跑通全栈、适配多端。在上一篇[《AI 写的前端代码长什么样—— productdemo.html 的CRUD功能演示一》]前端其实调用的所有后端已在最新最轻量级架构上实现。请关注后面博文将贴出全部源码并讲解架构及调用关系。很早前我用EasyUI DataGrid应用模板方式和VS2019的布局输出前端并且以前做了页面输出提供者接口INormViewProvider。【开源】一个泛型接口的点睛之笔决定了一套架构跨过了 .NET 的几个版本下面这个的数据显示界面就是由新写的H5页面提供者根据是PC浏览器还是手机浏览器、自动换成折叠行的Card显示。我相信大家如果了解了这个架构和设计思路一定会有收获同样的XML配置你看可以切换风格这不知道省了多少代码而我一行前端也没写。2. 总体评价功能原型 ✅架构基础 ❌从功能验证的角度来看这个页面能跑、能调、能看增删改查、分页筛选、弹窗提示全部正常完成需求没有任何问题。但如果评审标准从“功能是否完成”切换到“代码是否易于长期维护”它就暴露出了 AI 典型的“写完就跑”风格 —— 只解决当下的显示问题不为未来的变化留出结构空间。我把问题归纳为4 个核心缺陷下面逐一展开。3. 问题拆解四个架构层面的硬伤3.1 渲染逻辑与数据逻辑完全耦合问题表现数据请求、分页计算、表格渲染、错误提示全部堆在loadList()这一个函数里。粗略一数它至少干了 6 件事构造请求参数发起网络请求解析响应数据更新分页状态渲染表格 HTML处理加载/空状态扩展影响如果产品表要加一个字段比如Category你需要同时修改SQL 查询语句、后端 DTO 映射、前端表格模板、排序字段配置、筛选条件逻辑……每一层都得改改了还可能漏。扩展性评分⭐☆☆☆☆极低— 每加一个字段全链路散落修改。3.2 API 调用没有统一封装问题表现loadList、saveProduct、deleteProduct、openEditModal这四个函数里分别直接写了fetch(url, { method, headers, body })。没有统一的错误拦截Token 自动注入超时处理Loading 状态管理请求重试维护影响假设后端接口路径从/api/product统一改为/api/v1/product你需要到 4 个不同的函数里分别修改漏改一处就全线崩溃。维护性评分⭐☆☆☆☆极低— 请求逻辑没有收敛到单一入口。3.3 状态管理用全局变量 DOM 查询问题表现分页状态靠currentPage、pageSize、totalRecords、totalPages四个全局变量散落各处筛选条件直接用document.getElementById().value实时读取没有任何 ViewModel 层复用影响如果产品管理页面要新增一个“热门产品”列表或者“已删除产品”列表这两个列表需要独立的分页、筛选、数据状态。当前的代码无法复用唯一的选择就是复制整个表格逻辑然后改字段名—— 然后你就有了两份需要同步维护的代码。复用性评分⭐☆☆☆☆极低— 代码与页面 DOM 结构死死绑定无法移植到其他模块。3.4 没有考虑 UI 组件化问题表现表格、分页器、模态框、Toast 全都是手写 DOM 操作createElement、innerHTML、classList.add/remove没有封装成任何可复用的 UI 组件。协作影响当团队里另一位同事要做一个“用户管理”模块时他需要重新写一个表格重新写一个分页器重新写一个模态框重新写一套 Toast这些代码不是“引用”自共享组件库而是复制一份改字段名。团队协作评分⭐☆☆☆☆极低— 每个人都在重复造轮子且造出来的轮子形状还不一样。4. 总结AI 完成了“0 到 1”但没给“1 到 100”留下空间综合以上四点可以得出一个明确的结论AI 生成的productdemo.html是“功能原型”级别的产物不是“架构级前端”的产物。它的价值在哪里✅ 项目初期用来快速演示给客户看确认需求方向✅ 作为MVP 原型验证技术可行性✅ 作为学习示例展示 CRUD 的基本交互模式但如果项目的目标是“长期维护、多人协作、持续迭代”那么它迫切需要一次架构层的前端重构重构方向具体措施统一请求层抽离apiClient集中处理错误、Token、超时、Loading状态管理引入 Vue/Pinia 或 React/Redux至少封装一个 Store 对象UI 组件化封装DataTable、Pagination、Modal、Toast等可复用组件业务逻辑分离将数据逻辑从 DOM 操作中剥离放入 Service 层或 Hooks5. 最后的思考人 AI 的最佳协作模式有人可能会问“既然 AI 生成的代码有这么多问题那是不是说明 AI 写代码不靠谱”我的观点恰恰相反AI 是非常优秀的执行者但不是合格的架构师。它擅长快速搭建一个功能完整的 Demo生成符合语法规范的样板代码完成重复性的编码工作它不擅长为未来的变化预留扩展空间做跨模块的抽象和复用设计权衡短期效率与长期维护成本所以正确的姿势应该是人做架构决策AI 做代码执行。架构师负责定义模块边界、设计数据流向、规划组件复用策略AI 负责在这些框架内快速生成具体实现。这样既能发挥 AI 的速度优势又能保证代码的长期可维护性。真正的架构师永远是人。AI应该是人的得力助手。明白了你希望用一段简短的过渡来收尾自然引出那三篇已有的文章作为参考而不是在正文里展开新架构的细节。以下是修改后的第二篇结尾从第5节之后开始替换6. 预告从“代码生成”到“配置驱动”说到重构的方向其实我一直在思考一个更根本的问题既然 AI 已经能自动生成 CRUD 代码那为什么我们不直接跳过“生成代码”这一步让前端连代码都不用写换句话说与其让 AI 去写一堆将来要改、要删、要重构的代码不如把业务配置和UI 渲染彻底分离 —— 前端只负责解析配置、动态渲染所有的业务逻辑数据源、过滤字段、显示列、表单结构全部由配置文件来定义。这套思路我称之为“配置驱动的前端架构”。事实上这个方向我已经实践了相当长一段时间也积累了一些初步的成果。感兴趣的朋友可以先看看我之前写的几篇文章了解一下这套理念的来龙去脉《不是程序员可能做报表吗》《DBA开发PC和手机报表解决方案及实践》《将复杂数据操作“标准化、配置化、平民化”之天下报表回归报表本质》这三篇文章讲的是这套架构的早期探索—— 如何通过 XML 配置让 DBA 和业务人员也能快速生成数据报表无需编写前后端代码。而我正在做的是把这套理念从“报表”延伸到完整的 CRUD 业务页面—— 增删改查、分页筛选、表单校验、状态管理全部由 XML 配置驱动前端一行代码也不用写。关于这套新架构的完整设计、XML 配置规范、以及它如何从根本上解决 AI 代码“能用但难维护”的痛点我会在后续文章中详细展开敬请期待。本文首发于 CSDN作者咏方舟-长江之流不用授权欢迎转载。如果你觉得有用欢迎点赞、收藏、评论让更多人看到 AI 代码的“另一面”。回顾上一篇[《AI 写的前端代码长什么样—— productdemo.html 的CRUD功能演示一》](#)