用 AI Agent 从零生成网页原型：静态 HTML、Vue、React 怎么选，才能少返工、少烧 Token

如果你准备把需求交给 Codex、Claude Code、Hermes 或其他 AI Agent，让它直接生成一套可以点击、演示和修改的网页原型，最容易踩的坑往往不是页面不够漂亮，而是第一天就选错了技术架构。

只有六七个页面时，HTML+CSS+JavaScript 看起来最轻，Agent 很快就能把页面铺出来。但原型进入第十轮评审后，一个字段可能要同时修改列表、筛选、表单、详情、接口和数据；一个导航调整，也可能迫使 Agent 重新检查几十个页面。第一次少用的 Token，很可能在后续返工里成倍花回去。

反过来，如果只是做一次性的概念演示，却一开始就搭 React、权限、状态库和数据库，同样会把本来简单的原型做成一项工程。

用 AI 生成网页原型，真正应该比较的不是“哪个框架最先进”，而是“哪套架构能以最低成本撑过这个原型的完整生命周期”。

接下来会先把“页面是否组件化”和“数据是否需要 API 边界”拆成两条独立轴线，再把 HTML、Vue 3、React、Mock、MSW、Mock Server 和 SQLite 放进同一套工作量模型。读完以后，你应该能分别确定页面组织方式、数据路线、Token 预算、升级条件，以及交给 AI Agent 的实施边界。

文中的 Token 数字是统一工作量假设下的规划区间，不是 Vue、React、Ant Design、Element Plus 或任何模型公布的官方基准。模型、上下文长度、缓存、Agent 是否误读无关文件以及返工次数，都会显著改变实际消耗。

开始前先建立一个能比较的 Token 模型

没有统一工作量，任何 Token 排名都没有意义。下面使用两档原型作为参照。

小型原型：6～10 个页面，3～5 个数据实体，包含列表、查询、新建、编辑、详情，以及一个简单业务流程。

大型原型：30～60 个页面，12～20 个数据实体，包含多模块菜单、复杂表格、状态流转、跨页面联动、权限和异常状态。

一次中等变更：调整一个业务字段或状态规则，同时影响列表、筛选、表单、详情，必要时继续修改 API、数据库和验证。

估算公式可以写成：

生命周期 Token ≈ 首次创建（含一次标准验证）+ 变更次数 × 单次变更（含一次标准验证）+ 意外返工

表格中的“首次创建”和“单次变更”已经各自包含 Agent 读取相关文件、生成或修改代码、解释结果和一次标准验证，因此计算时不要再重复加一遍验证成本。“意外返工”只记录需求误解、验证失败后的额外修复和多轮重试；预算不包含 node_modules、图片理解和大段无关通用规则。组件库安装到项目里，并不等于 Agent 必须读取组件库源码。应在项目规则中明确禁止扫描 node_modules，否则任何框架的 Token 都可能失控。

先分清两条轴线：页面如何组织，数据如何连接

在比较 HTML、Vue 和 React 之前，必须把两个问题分开：页面是否组件化，以及数据留在浏览器还是通过 API / 服务层访问。它们相互影响，但不是同一件事。

轴线一：页面是复制堆叠，还是组件化组织

页面复制式原型把表格、筛选、弹窗、样式和交互分别写进每张页面；组件化原型则把重复结构收敛为公共布局、组件和状态逻辑。组件化不等于必须使用 Vue 或 React：原生 ES Modules、Web Components 或模板函数也能复用，只是成熟框架通常更容易维持清晰边界。

轴线二：数据留在浏览器，还是通过 API 边界访问

浏览器内数据可以来自静态 JSON、前端 Mock、统一状态仓库、localStorage 或 IndexedDB；API 边界后方可以是 MSW、JSON Server、Node API、SQLite 或正式数据库。是否需要 API，取决于原型要验证的是单人本地交互，还是共享持久化、服务端规则、事务与多人协作。

四种组合都可能存在

因此，纯前端静态部署不等于“没有组件化”，组件化也不等于“已经数据分离”。真正危险的是把页面复制式结构和页面内各自维护假数据同时用于大型复杂原型。

纯前端静态原型：数据留在浏览器，也可以组件化

页面组件 → 统一状态 / 静态 JSON / 前端 Mock
                       └→ localStorage 或 IndexedDB（可选）

只要使用统一状态和公共组件，纯前端原型也能在同一浏览器中保持列表、详情、统计和流程状态一致。它不需要独立服务，复制构建产物或部署到静态托管即可展示，首次生成、启动和部署通常最轻。

它的边界不是“不能做跨页面交互”，而是无法独立证明多人共享、服务端权限、并发写入、可信审计和事务回滚。只做单人交互演示时，这些能力可能根本不需要。

页面与数据访问分层：先建立 API 契约

页面组件 → API 请求层
            ├─ MSW handlers → 内存 fixtures
            ├─ JSON Server → db.json
            └─ Node API → SQLite

前端只依赖约定好的请求地址、字段和返回状态。MSW 可以运行在浏览器侧，它建立的是逻辑上的 API 边界，而不是独立服务器；JSON Server 和 Node API 才是独立运行的数据服务。这样以后替换数据实现时，页面组件不必跟着重写。

两种常见组合的 Token 成本

下面比较的是实践中常见的两个端点组合，不是全部可能性：

• 页面复制式 HTML + 静态 JSON。
• 组件化前端 + API 边界或独立数据层。

表中区间由后文前端路线和数据路线的规划区间组合而来，只用于预算和演示生命周期计算方法，不能单独证明某种技术必然更省 Token。

在本文规划模型中，页面复制式路线在小型首次创建时最轻；规模扩大、修改增多后，大量重复页面、手写状态和全局搜索会抬高成本。组件化和统一数据边界需要先投入组件、请求封装与错误处理，但能让一次规则变更集中在更少的文件中。

反例：四十多页复杂原型仍按“来一个需求，复制一张页面”推进

下面是由常见失败方式组合而成的教学案例，用于说明成本变化，不对应某个真实项目，也不是实测结果。

一位刚开始使用 AI Agent 制作原型的产品经理，要设计一套包含商品、采购、销售、库存和审批的管理系统。第一轮只有八张页面，于是直接让 Agent 为每张页面分别编写表格、弹窗、按钮和假数据。首次交付很快，看起来也足够完整。

问题出现在后续需求持续增加时。产品经理仍然按“再加一个筛选”“再补一个审批页面”“再做一个库存预警”逐条下指令，没有先建立设计变量、公共组件、数据模型和状态机。到第六轮评审时，原型已经增长到四十多张彼此独立的页面。

• 订单状态从三种扩展到五种，列表、详情、统计卡片和筛选项出现了不同叫法。
• 同一个“编辑商品”操作，有的页面打开弹窗，有的打开抽屉，还有的直接跳转新页面。
• 销售单取消后，销售列表显示“已取消”，库存页面的数量却没有恢复，仪表盘仍显示原来的统计值。
• 按钮高度、表格间距、状态颜色和空状态文案在不同批次生成的页面中逐渐分叉。
• 每次需求变更，Agent 都要重新搜索几十张页面；为了判断哪一份假数据才是准的，又把更多文件读入上下文。

这不是纯前端静态部署的必然结果，而是“页面复制 + 页面内局部假数据”共同造成的失控：

按照本文规划模型，这类大型页面复制式原型经历八次中等变更时，账面演算为：

页面复制式 HTML + 静态 JSON：
178～315K + 8 × 31～70K = 426～875K Token

组件化前端 + API / 数据层：
140～290K + 8 × 19～43K = 292～634K Token

按对应端点计算，模型中的账面差值为 134～241K Token。它只演示“首次预算 + 变更预算”的计算方法，不代表真实项目一定节省这些 Token；实际结果仍取决于模型、上下文缓存、组件质量、团队熟练度和验证强度。

三种最常见的“堆功能”反模式

组件化思维并不是“把所有东西都封装”。它要求先找出稳定且重复的结构，例如 AppLayout、FilterBar、DataTable、FormDrawer、StatusTag；业务规则则围绕实体、状态和操作集中维护。这样需求变更时，Agent 才能修改一个组件、一份状态规则或一个接口，而不是逐页打补丁。

如果已经陷入这种反模式，不要继续新增页面。应先暂停扩展，盘点重复样式与交互，建立最小组件清单并统一状态词典。若只需单人演示，可先迁到浏览器内统一状态；若还要共享持久化、服务端规则或事务，再建立 API 边界并选择 MSW、JSON Server 或 Node + SQLite。

最终要分别回答两个问题：页面是否需要组件化，以及数据是否需要 API 边界。不能因为 HTML 首次生成短，就复制几十张页面；也不能因为采用了 Vue 或 React，就默认必须增加数据库。

前端路线：首次最省与长期最省不是一回事

单位为约 K Token，即千 Token。

一次性小原型：原生 HTML 的确最省

只有几张页面、主要用于演示、评审后即归档且基本不再修改时，简单 HTML 路线不需要脚手架、路由、组件 Props、状态模型和 TypeScript 类型，在本文统一工作量假设下首次预算最低。这里比较的是“少量独立页面”的轻量写法；原生 JavaScript 同样可以通过 ES Modules、模板函数或 Web Components 实现组件化。

但这个结论有明确边界：页面少、交互浅、数据独立，并且不会经历大量跨页面修改。如果为了让原生项目可维护，又加入模板系统、组件注册、状态中心和自制路由，实际上已经在维护一套缺少生态支持的“小框架”，首次优势会很快消失。

中后台 CRUD 且频繁变更：Vue 3 + Element Plus 在本文模型中更省

在本文设定的中后台 CRUD 场景、相同模型和相近熟练度下，Vue 单文件组件把模板、逻辑和样式放在清晰边界内，Element Plus 又提供表格、表单、分页、弹窗、抽屉、日期和树形控件，因此规划预算相对较低。进销存、ERP、项目管理等中后台原型，可以把大量重复页面压缩为公共布局、查询栏、数据表格和表单抽屉。这是本文的估算前提，不是对所有项目都成立的框架排名。

Vue 官方提供的 Composables 也允许把分页、查询和状态同步等重复逻辑抽离复用。首次建立组件体系会多花一些 Token，但需求进入高频变更后，Agent 读取和修改的文件更少。

面向 React 团队或公开开发者生态：接受本文模型中的小幅预算差

本文预算模型假设 Agent 对 Vue 与 React 的熟练度相近，并按常见 React + TypeScript 中后台写法显式处理 Hook、JSX、状态更新、表格列配置和类型关系，因此给出的规划区间略高于 Vue 方案。这不是官方基准；如果团队、现有代码或 Agent 对 React 更熟悉，差距可能缩小，甚至反转。React 官方也强调，大型应用需要认真组织状态的唯一来源，避免重复状态带来修改成本，参见 Managing State。

它换来的是更广泛的开发者生态、公开示例和跨团队协作基础。Ant Design 本身提供企业级组件、TypeScript 类型、国际化和主题能力，见 Ant Design 官方介绍。当原型还承担公开模板、开发者教学或未来正式产品前端的职责时，这部分成本可能值得。

数据路线：Mock 不是一个工具，也不是数据库

前端框架只解决页面怎样复用，数据路线决定新增、编辑、刷新、共享、关联查询和状态流转是否可信。很多人会说“原型用 Mock 就行”，但 Mock 不是一项单独技术，更不是天然持久化的数据层。

先把 Mock 拆成四种层级

Mock.js 官方文档将其核心能力概括为生成随机数据和拦截 Ajax 请求。它适合减少手写假数据，但它不会自动获得共享数据库、事务或可靠持久化。自定义 JavaScript 生成器也属于同一层级。

Mock Service Worker则在网络层响应请求。页面仍按正式 API 的方式发起请求，因此 Mock 可以被关闭或替换，而不必修改组件的数据读取方式。

JSON Server会从 db.json 提供独立 REST API，属于 Mock Server。它比页面内 Mock 更接近前后端数据分离，但仍不等同于具有事务、约束和复杂权限的正式数据库。

数据路线 Token 规划表

下面只计算数据层，不包含前端框架。单位仍为约 K Token。

静态 JSON、前端 Mock 和 localStorage：轻，但边界不同

静态 JSON 适合固定展示数据。前端 Mock 适合按模板批量生成姓名、日期、状态和数量，能够更快覆盖空数据、少量数据和大量数据等视觉场景；两者默认都不会保存用户操作。

localStorage 可以让当前浏览器刷新后保留数据，却要自己处理序列化、数据版本、迁移失败和跨页面同步。部署到网上后，每位访问者仍然拥有彼此隔离的数据。它适合个人演示，不适合多人共同评审同一批数据。

MSW：适合验证接口行为，不负责数据库能力

MSW 可以模拟成功、超时、权限失败和不同状态码，让开发与测试复用请求处理器。它最适合“后端尚未完成，但字段、端点和错误规则已经确定”的场景。

它默认仍不负责真正持久化。若又为 MSW 补上 localStorage、多表关系、迁移和复杂状态机，Token 成本可能接近甚至超过一个轻量 SQLite 数据层。

JSON Server：标准 CRUD 很快，复杂流程会补很多代码

JSON Server 可以从 db.json 快速提供查询、分页和 CRUD API，适合验证页面和接口形状。其项目主页目前仍提示 v1 文档处于 Beta；事务、复杂状态流转、权限和业务校验仍需额外实现。

因此它适合“接口已经分离，但业务规则还很浅”的中间路线。若大量需求开始依赖自定义中间件和手写关联逻辑，应重新比较 Node + SQLite，而不是继续给 Mock Server 打补丁。

SQLite：首次不是最低，复杂原型的生命周期通常更稳

SQLite 是自包含、零配置、事务型的单文件数据库，不需要单独运行数据库服务器，见 SQLite 官方介绍。对于需要部署到 Linux、通过一个链接访问、保存共享演示数据并模拟多表流程的原型，它通常是更平衡的路线。

初始化时需要表结构、种子数据、数据访问层和 API，因此比静态 JSON 或 Mock 多花一些 Token；后续查询、关联、事务和一键重置可以依靠数据库能力，不再用 JavaScript 到处手工同步。

若计划使用 Node 自带的 node:sqlite，应先核对目标服务器的 Node 版本和稳定性标记。当前官方文档仍将该模块标记为 Release Candidate，见 Node.js SQLite 文档。技术方案应冻结运行时版本或选择经过项目验证的 SQLite 驱动，不能让 Agent 临时猜测。

什么时候浏览器内数据不再够用

复杂界面并不天然需要后端。只要原型面向单人演示，组件化前端配合统一状态仓库、localStorage 或 IndexedDB，也能可靠演示跨页面联动、状态流转和刷新保留。真正需要升级的，不是“页面看起来复杂”，而是评审开始要求共享数据、服务端规则、事务或可信审计。

如果只是验证“这个角色看到什么、按钮点下去如何反馈”，浏览器内状态已经够用；如果要验证“即使绕过界面也不能执行”，就必须有服务端授权。类似地，复杂流程可以在前端状态机里演示，但多人共享、事务一致性和可信审计不能靠页面脚本证明。

出现下面任意一项，就应建立 API / 服务层边界：

• 多位访问者需要共享并修改同一份数据。
• 权限、状态流转或校验必须由服务端强制执行。
• 一个动作涉及事务、并发写入、失败回滚或幂等处理。
• 评审要求可信审计、跨设备持久化或长期共享数据。

如果这些条件都没有，即使流程较长，只要页面已经组件化、数据集中管理，纯前端原型仍可能是成本更低且足够可信的选择。反过来，页面只有几张，但一开始就要求多人共享和服务端权限，也应尽早建立 API 边界。

建立边界后仍不必直接上正式数据库：已有接口契约、需要演示延迟和错误时用 MSW；需要快速提供独立 CRUD API 时用 JSON Server；需要共享持久化、关系查询、事务或服务端规则时，再使用 Node + SQLite。三条路线解决的问题不同，不能画成一条必然升级链。

四类场景应该怎么选

*先判断页面规模、变更频率和数据行为，再选择满足要求的最轻架构。*

场景一：一次性小型演示

HTML + CSS + JavaScript
静态 JSON 或简单前端 Mock
首次预算约 23～47K Token

适合少量页面、几乎不再修改、不需要共享数据的评审。Mock 的目标只是快速填充真实长度的数据，不应继续模拟事务、权限和复杂状态。

场景二：小型但会反复调整

Vue 3 + Element Plus
统一浏览器内 fixtures，或按数据要求选择 MSW / JSON Server
首次预算约 31～60K Token

页面会反复调整，所以应尽早建立公共布局、表单组件和统一状态，不再让每张页面维护自己的静态数组。如果只做单人演示，浏览器内 fixtures 就够了；需要验证 API 契约、延迟与错误时使用 MSW；需要独立 CRUD 服务时使用 JSON Server。只有共享持久化、关系查询或服务端规则进入验收范围，才升级到 Node + SQLite。

场景三：大型业务原型或准备继续开发

Vue 3 + Element Plus，或 React + Ant Design
统一数据访问层；满足服务层硬条件时使用 Node + SQLite

在本文“中后台 CRUD、相同模型、相近熟练度”的规划口径下，Vue 3 + Element Plus 的预算区间较低；如果现有团队、交付对象或后续代码基线是 React，就选 React + Ant Design。熟悉度和迁移成本通常比表格中的小幅区间差更重要。

大型项目不要复制一页改一页，应先建立 AppLayout、PageHeader、FilterBar、DataTable、FormDrawer、StatusTag 和统一数据访问层。若数据硬条件全部为否，访问层可以连接浏览器内状态；出现多人共享、服务端授权、事务或可信审计时，再连接 Node + SQLite API。组件边界越稳定，Agent 每次需要加载的上下文越小。

场景四：已接近生产系统

当原型需要真实登录、多角色安全边界、大量并发、完整审计、外部系统集成或正式 SLA，它已经不只是原型。此时应重新进行生产架构评审，而不是因为 SQLite 前期方便就机械沿用。

用六步完成一次技术选型

第一步：写清原型生命周期

输入页面数量、数据实体数量、预计评审轮次、部署方式和是否继续开发。输出一张范围卡，例如：

页面：12 个
实体：商品、采购单、销售单、库存记录
预计变更：8～12 轮
访问方式：本地开发，后期单一网址演示
数据要求：刷新后保留，可一键重置
后续：可能交给开发团队继续实现

验收方法：任何人看完都能判断它是一次性展示，还是持续演进的交互原型。

第二步：分别判断组件化和数据边界

先回答页面组织问题：

• 是否有重复出现的布局、筛选栏、表格、表单、弹窗或状态标签？
• 是否预计发生多轮跨页面修改？
• 同一字段、样式或交互是否会同时影响多张页面？

只要重复结构明显或需求会持续变化，就应组件化；页面极少、一次性展示且几乎不再修改时，才适合保持简单的独立页面。

再回答数据边界问题：

• 多位访问者是否要共享同一份数据？
• 权限、状态流转或校验是否必须由服务端强制执行？
• 是否涉及事务、并发、失败回滚或幂等处理？
• 是否要求可信审计、跨设备持久化或长期共享？

这些硬条件全部为否时，可优先使用统一的浏览器内状态；任意一项为是，就应建立 API / 服务层边界。验收方法：方案必须分别写清“页面为何要或不要组件化”和“数据为何要留在浏览器或进入服务层”，不能用一个答案代替两个判断。

第三步：计算生命周期预算

不要只比较首次创建。分别填写首次预算、单次变更预算和预计变更次数：

方案 A 总预算 = 首次预算 + 预计变更次数 × 单次变更预算
方案 B 总预算 = 首次预算 + 预计变更次数 × 单次变更预算

验收方法：正文表格的首次和单次区间已经包含一次标准验证，不得重复加算；需求误解、失败重试等意外返工应单独预留。前端表与数据表用于拆分比较，组合总预算只能各取一项相加，不能把多条候选路线重复累计。

第四步：选择满足要求的最轻前端

• 10 页以内、变更很少：优先原生 HTML。
• 页面不多但会持续调整：优先 Vue 3 + Element Plus。
• 大型后台原型：Vue 3 + Element Plus 或 React + Ant Design。
• 面向 React 开发者交付：直接选 React，不要为了少量 Token 增加迁移成本。

验收方法：所选方案必须同时解释“为什么选”和“什么条件下不再适用”。

第五步：在 Mock 与数据库之间选到正确层级

• 只展示固定数据：静态 JSON。
• 批量生成不同演示数据：Mock.js 或自定义生成器。
• 当前浏览器刷新后保留：localStorage。
• 已有 API 契约，需要模拟延迟和错误：MSW。
• 快速提供标准 CRUD API：JSON Server。
• 云端共享、关系查询、状态一致性：Node + SQLite。
• 已接近生产：停止原型化选型，重新评估正式数据库与安全架构。

验收方法：分别测试页面刷新、重开浏览器、另一位访问者进入、失败分支和数据重置；结果必须符合原型合同。

第六步：给 AI Agent 设置读取和修改边界

无论选择哪套技术，都要约束 Agent：

• 不扫描 node_modules 和构建产物。
• 先读取项目规则、目录说明、数据模型和当前任务涉及的文件。
• 先复用公共组件，不复制整个页面。
• 页面只通过统一数据访问层读写数据，不能在组件内临时加第二份假数据。
• 每次只实现明确需求，禁止顺手重构。
• 实际运行验证命令，记录退出码和关键结果。
• 未执行的验证必须标注“未执行”。

这一步通常比争论 Vue 和 React 更能节省 Token。

如何测出自己的真实 Token 成本

如果使用的 Agent 或 API 能显示输入、输出和缓存 Token，可以对候选方案做一次小型 A/B 测试：使用同一个模型、同一份需求、相同页面范围和相同验收标准，分别完成首次创建与两次跨页面修改。

建议记录：

不要用不同模型、不同上下文或不同完成标准进行比较。至少重复三次，使用中位数，才能减少偶然返工造成的偏差。若工具不显示 Token，就只能把本文区间作为预算，不应把估算写成实测结论。

常见失败方式

把“用了 Vue/React”误认为“已经建立 API 边界”。 组件化只解决页面组织；如果所有数据仍在浏览器，它依然是纯前端数据路线。解决方法是分别检查公共组件和数据访问边界，不要用框架名称替代架构判断。

把所有 Mock 当成一回事。 Mock.js、MSW 和 JSON Server 分别解决数据生成、网络拦截和独立 Mock API，能力边界不同。解决方法是先写清是否需要 API 契约、刷新保留和多人共享，再选工具。

只看首次生成速度。 页面很快出现，但每次变更都要全局搜索。解决方法是把预计变更次数纳入公式。

小项目过度工程化。 为六个展示页面引入复杂状态库、权限框架和数据库。解决方法是先写升级条件，条件未出现就不增加依赖。

把纯前端误认为只能复制页面。 静态部署的 Vue、React 或原生模块同样可以组件化并集中管理状态。解决方法是先消除页面复制和局部假数据；只有出现共享数据、服务端授权、事务或可信审计等硬条件时，才增加 API / 服务层。

复杂项目继续堆页面局部逻辑。 为了演示库存、审批和权限，在多张页面里各写一套状态同步。解决方法是先收敛公共组件、统一状态和状态机；若评审要求服务端一致性，再把规则移到轻量服务层。

把 Mock 当数据库。 演示时能新增，刷新或换一个浏览器后数据消失。解决方法是按刷新、重开浏览器、另一位访问者和失败回滚逐项验证。

为了省 Token 省掉验证。 代码变短了，但错误在后续轮次反复出现。验证不是额外浪费，而是避免返工的成本控制。

让 Agent 读取整个仓库。 大量无关源码进入上下文。解决方法是维护清晰目录、任务文件清单和禁止读取范围。

复制给 AI Agent 的选型任务

你现在只负责“用 AI Agent 生成网页原型”的技术架构选型，不要直接创建项目。

目标：分别判断页面是否需要组件化，以及数据应留在浏览器统一状态还是建立 API / 服务层边界；再从 HTML + CSS + JavaScript、Vue 3 + Element Plus、Vue 3 + Ant Design Vue、React + Ant Design 中选择前端路线；从静态 JSON、前端 Mock（Mock.js 或自定义生成器）、localStorage、MSW、JSON Server、Node + JSON、Node + SQLite 中选择数据路线。

请先读取我提供的需求、现有目录和约束，再输出：
1. 页面数量、数据实体、核心流程、部署方式和预计变更频率。
2. 哪些功能只需视觉演示，哪些功能必须验证真实数据行为。
3. 页面组织判断：是否组件化、公共组件清单及至少三条依据。
4. 数据边界判断：浏览器内统一状态或 API / 服务层，并指出是否出现共享数据、服务端授权、事务、并发、可信审计等硬条件。
5. 如果推荐浏览器内数据，写清它不能可靠验证的功能；如果推荐 API 边界，写清 API 契约、Mock 层级和升级到 SQLite 的条件。
6. 2～3 个候选组合及取舍。
7. 首次创建、单次中等变更、预计生命周期 Token 的区间。必须注明这是规划估算，不是官方基准或实测结果，并避免重复计算标准验证。
8. 推荐方案、适用边界、升级条件和停止条件。
9. Agent 后续只能读取的目录、禁止读取的目录、公共组件清单、数据访问边界和验证清单。
10. 不要安装依赖、不要写代码、不要部署，等待我确认技术方案。

原型范围：
[在这里粘贴页面、数据、流程、部署方式和预计变更次数]

最后的选择原则

真正的答案不是“HTML 最省”“用了 Mock 就够了”或“React 最先进”，而是选择满足当前生命周期的最轻架构：

• 一次性小型展示：HTML + 静态 JSON 或简单前端 Mock。
• 小型但持续修改：先组件化；只做单人演示时使用统一浏览器内状态，需要验证 API 契约或独立 CRUD 时再选 MSW 或 JSON Server。
• 大型、长期演进：使用 Vue 3 + Element Plus 或 React + Ant Design，并建立统一数据访问层；满足服务层硬条件时再配 Node + SQLite。
• 需要多人共享、服务端授权、事务联动或可信审计：建立 API / 服务层，不要继续把数据散落在各页面中。
• 接近生产：停止把它当普通原型，重新做生产架构与安全评审。

页面是否组件化，决定重复界面和需求变更是否容易维护；数据是否进入 API / 服务层，决定多人共享、服务端规则、事务和可信审计能否被验证。纯前端并不等于页面复制，组件化也不等于必须上数据库。框架决定页面如何复用，Mock 决定怎样模拟尚未完成的数据能力，数据库决定哪些行为能够被稳定保存和验证，而清晰的 Agent 边界决定 Token 会不会浪费在无关文件上。把这些选择分开判断，才是真正省 Token 的 AI 网页原型架构。