用 AI 生成测试用例再搭一个带前端页面和后端接口的全栈项目听起来工作量不小。实际先用 Plan 模式把架构、目录、接口和数据模型定下来再让 AI 按模块生成代码整个项目框架确实可以在 10 分钟左右搭完。这里就把整个过程拆开Plan 模式和直接生成模式怎么选环境怎么准备项目骨架怎么落地测试用例生成链路怎么设计以及最容易踩的坑在哪里。先说结论这类项目最适合用 Plan 模式的人不是完全不懂代码的新手而是手里有需求、但对工程结构还没有明确想法的开发或测试工程师。Plan 模式最大的价值不是帮你少打几个字而是先逼你把“要做成什么样、模块怎么划分、接口怎么定义”想清楚。全栈项目和单文件脚本不一样前端、后端、数据库、接口契约只要有一个地方没对齐后面联调阶段会非常痛苦。1. Plan 模式到底解决了什么问题1.1 为什么全栈项目不适合一上来就生成代码很多人在 Cursor 或 Claude Code 这类 AI 编程工具里习惯直接输入一个需求让 AI 一口气生成整个项目。这种思路适合解决一个小函数、一个脚本、一个工具类。一旦碰到全栈项目问题就来了AI 生成的后端接口路由是 A 写法前端请求的是 B 路径数据库字段叫 create_time接口返回里写的是 createdAt页面调接口的请求体字段和后端模型参数对不上。最后代码堆了一堆但页面一点按钮就报错。这些问题的根因不是 AI 能力不行而是需求没有先被拆解成一份可检查的工程方案。Plan 模式做的事情就是在写代码之前先输出一份计划包含目录结构、技术选型、数据模型、接口定义、页面划分。人先看一遍有问题当场改确认后再进入执行阶段。等于把最容易出错的“系统设计”环节从代码生成里独立出来了。1.2 Plan 模式和直接生成模式怎么选以 Claude 这类工具的常见模式为例Plan 模式偏向“先规划后执行”直接生成模式下 AI 会直接修改文件。它俩各有适用场景场景推荐模式原因从零搭全栈项目Plan 模式需要先统一架构和接口契约修改一个独立函数直接生成改动小规划成本反而高重构多个模块Plan 模式需要先梳理影响范围修复明确报错直接生成问题定位清楚直接改更快接手别人的项目Plan 模式先理解结构避免乱改我的习惯是第一轮搭骨架用 Plan 模式把目录、接口、数据模型全部在计划里过一遍后面的细节修改、改 bug、调样式再用直接生成模式。这样既能控制整体方向又不会被一轮轮“先生成计划再确认”拖慢节奏。1.3 这个测试用例项目能做哪些事标题里说的“AI 测试用例项目”本质是一个带界面和接口的工具用户输入需求描述、接口文档或功能说明系统调用大模型自动生成结构化测试用例。项目最终包含这几块能力前端页面创建项目、填写需求、触发生成、查看用例列表和详情。后端服务接收请求调用大模型解析返回结果写入数据库。数据存储保存项目、用例、生成记录。导出能力把用例导出为 Markdown、JSON 或表格方便后续维护。这类项目适合拿来练手也适合小型团队内部使用。它不追求替代人工测试设计而是把“从需求到初版用例”这一步自动化人工再做复审和补充。理解了这一点后面设计功能时就不会跑偏。2. 动手前先确认环境和技术选型2.1 一套偏稳妥的全栈技术组合我第一次搭的时候用的是一套很常见的组合后面可以按自己习惯替换后端用 Python FastAPI前端用 Vue 3 加 Vite数据库先用 SQLite后续再切 MySQL 或 PostgreSQL。选 FastAPI 的原因有三个自带接口文档联调时直接打开 /docs 看接口Pydantic 能做请求参数校验异步支持比较好批量生成任务不会轻易把服务卡死。前端选 Vue 3 加 Vite 是因为脚手架简单组件划分清楚适合快速做管理类页面。SQLite 则适合前期开发和单机部署不用额外起数据库服务。这套组合不是唯一答案换成 Node.js 加 React、或者 Spring Boot 加 Vue 也可以。重点是让 AI 在 Plan 阶段把“后端框架、前端框架、数据库访问方式、要不要用 Docker”一次说清楚避免后面混着来。2.2 本地环境检查清单在让 AI 生成代码之前先花几分钟检查本机环境能省掉很多“代码没问题但跑不起来”的时间。我一般按这个顺序检查Python 版本建议 3.10 以上FastAPI 和 Pydantic 的新版本对旧 Python 支持不好。Node.js 版本建议 18 以上Vite 5 以上对 Node 版本有要求。包管理器后端用 pip 或 uv前端用 npm 或 pnpm选一个顺手的不来回换。端口占用后端默认 8000前端默认 5173检查是否被其他服务占用。Git 初始化先把项目目录纳入版本管理后面 AI 大改动时方便回退。低配置机器也能跑内存 8G 左右完全够。大量并发规划任务就不要在本机跑了那是后面要聊的边界问题。2.3 确认大模型接口可用整个项目依赖调用大模型生成用例所以动手前必须确认能访问到可用的模型接口。这一步很多人会忽略等到后端代码写完了一调接口才发现密钥不对、模型名填错、接口地址变了。常见要做的事情确认平台提供的是 OpenAI 兼容接口还是自家 SDK这决定后端请求写法。确认 API Key 有权限调用目标模型且账号配额或余额足够。确认模型名别把模型显示名和 API 模型 ID 搞混。先用一条简单请求测试接口能通再写代码。把接口可用性放在最前面确认后面的联调会非常顺畅。不同模型的响应速度、上下文长度和 JSON 输出稳定性差别很大这些直接决定测试用例生成的参数设计。3. 让 Plan 模式输出项目骨架3.1 第一步把需求写成结构化提示词Plan 模式要先给 AI 清晰的需求。不是简单写一句“帮我搭一个测试用例生成系统”而是把目标、用户、核心流程、技术约束都写清楚。我常用的提示词结构是这样的请用 Plan 模式分析下面这个项目先不要写代码。 项目目标做一个 AI 测试用例生成工具用户输入需求描述或接口文档 系统调用大模型生成结构化测试用例。 用户角色测试工程师、开发工程师。 核心流程 1. 用户创建测试项目填写项目名称和需求描述。 2. 用户点击生成后端调用大模型生成用例。 3. 用例按功能、边界、异常、接口分类展示。 4. 用户可以重新生成、编辑、导出用例。 技术约束 - 后端 Python FastAPI - 前端 Vue 3 Vite - 数据库 SQLite - 不要 Docker 请回答 1. 目录结构 2. 数据库表设计 3. 后端接口列表 4. 前端页面划分 5. 每个模块的关键类或函数这样写的目的是在把决策权交给 AI 之前先锁定技术边界。否则 AI 可能给你一个完全不同的技术栈或者设计出过重的架构。3.2 第二步评审 AI 给出的目录和接口设计AI 会基于上面的提示输出一份计划。这时候不要直接点执行先看几个关键点目录结构是不是前后端分离。前端页面和后端接口是不是一一对应比如前端“创建项目”页面要对上 POST /api/projects。数据库表是不是覆盖了项目、用例、生成记录这些核心实体。接口路径命名是否统一返回格式是否一致。评审过程中可以直接让 AI 改计划比如“接口返回统一包装成 code、message、data 结构”“用例表增加 status 字段”“所有模型 ID 使用字符串而不是自增整数”。这些修改发生在写代码之前成本几乎为零。如果等代码生成完再改就是改几十个文件的问题了。我实际操作时Plan 模式给出的第一版目录大体可用但接口设计偏多。本来设计了一堆管理端接口实际上单用户使用根本用不到删掉以后整个项目结构清爽很多。3.3 第三步按模块生成代码而不是一次生成全部计划确认后进入生成阶段。这里有个容易踩的坑不要一次性让 AI 助手“按计划生成所有代码”。全栈项目几十个文件一次性生成容易出现上下文窗口不够用、文件互相引用对不齐、生成到一半逻辑混乱的问题。我一般按这个顺序生成后端基础config、数据库连接、main 入口。数据模型项目、测试用例的表结构。后端服务调用大模型的客户端、用例解析逻辑。后端路由项目管理、用例生成、用例查询接口。前端基础Vite 脚手架、路由、API 封装。前端页面项目列表、生成页面、用例详情。联调修整跨域配置、请求路径、字段名对齐。每生成完一个模块先心里过一遍依赖关系再进入下一块。后端先把路由和模型跑通前端再接接口这样报错时定位范围小。3.4 第四步跑通最小闭环搭完框架后不要急着开发完整功能先把最小闭环跑出来。最小闭环指的是用户在页面填需求点击生成后端收到请求调用大模型返回用例并保存页面显示结果。这条链路只要通了整个项目的核心价值就成立了。最小闭环对应的关键文件通常不多backend/app/main.py # 后端入口 backend/app/routers/projects.py # 项目接口 backend/app/routers/testcases.py # 用例接口 backend/app/services/llm_client.py # 大模型调用 backend/app/services/generator.py # 用例生成逻辑 frontend/src/views/TestCaseGenerate.vue # 生成页面 frontend/src/api/index.ts # 前端请求封装先跑接口再用 curl 验证最后才碰页面。如果 curl 都通了页面报错就基本集中在前端传参和跨域。项目要交付给团队的话还可以让 AI 顺手生成 README 和接口文档这部分对后续维护很有用。4. 测试用例生成的核心链路和参数4.1 从需求文本到结构化用例的转换测试用例生成不能直接把用户原始文本塞给模型然后期望它输出规范结果。需要先做一层预处理把需求转成模型更容易理解和遵循的结构。输入需求通常是三类功能描述比如“用户可以用邮箱和密码登录系统”。接口文档比如 POST /api/login参数 email、password。既有测试点比如已经列出的验收标准和限制条件。处理流程可以是先由后端把输入文本整理成结构化提示词告诉模型当前项目的类型、业务背景、输入限制再要求模型按指定格式输出。这里最核心的是提示词模板的设计模板里要明确用例分类、字段定义、输出格式和数量要求。4.2 生成接口、Prompt 和参数设计后端提供一个生成接口常见的两种设计同步接口前端等待完整结果返回适合单条或少量生成。异步任务后端先返回任务 ID前端轮询结果适合批量生成。我建议前期用同步接口实现简单排错直观。等确实需要批量生成了再升级成任务队列。不要一上来就做异步那会引入任务存储、状态更新、轮询接口一堆复杂度。Prompt 参数里几个关键的设置参数建议原因temperature0.2 到 0.5太低会机械重复太高会编造步骤max_tokens按用例数量设置太少会截断太多会超时输出格式JSON便于后端解析和存储用例数量每种分类 3 到 5 条多了质量下降少了覆盖不足模型返回后后端必须做解析校验。经常出现的问题是模型返回了多余的 Markdown 代码块标记或者 JSON 里少了一个花括号。解析失败时可以做一次带错误信息的重试而不是把原始文本直接存进数据库。4.3 输出格式统一与校验不管模型怎么返回落到数据库和前端展示的用例结构必须是统一的。我建议用例模型包含这些字段id 用例唯一标识 project_id 所属项目 title 用例标题 category 分类功能/边界/异常/接口 precondition 前置条件 steps 操作步骤数组 expected 预期结果 priority 优先级高/中/低 status 状态待评审/通过/失败 source 生成方式AI生成/人工编辑 created_at 创建时间 updated_at 更新时间校验规则比较简单标题不能为空步骤至少一条预期结果不能为空category 必须在枚举范围内。不满足的用例标记为解析失败不要让脏数据进入前端。测试用例最终要给人看的格式统一比数量多更重要。5. 页面联调、批量生成与导出5.1 前端表单和后端接口怎么对牢全栈项目最常见的问题就是接口字段对不上。前端提交的是 projectName后端接收的是 name后端返回的 testcases 是数组前端数据结构里写成了对象。这些都要在联调时仔细核对。减少这类问题的办法是在 Plan 阶段就把接口定义写死然后前后端都参照同一份接口文档。FastAPI 的 /docs 页面在这里非常有用前端开发时直接打开看每个接口的请求和响应结构照着写请求代码。另一个办法是前端把 API 请求都集中封装在一个文件里不要散落在各页面字段统一改一处就行。5.2 批量生成时的任务队列与并发控制单条生成跑通后很多人会想批量生成一批用例。这时候不要简单地用前端循环调接口会带来几个问题页面持续等待、大模型接口限流、失败后整批重来。更稳妥的做法是把批量生成放到后端按列表逐条处理每条的生成结果单独保存。后端可以记录每个任务的进度和失败原因。碰到单条失败就跳过或重试不要影响整批。并发数控制在 1 到 3 个即可不同的大模型接口对并发限制差别很大开太高会直接报限流错误。5.3 用例导出和文档落盘测试用例生成之后常见需求是导出。前端页面通常做两个动作一个是在线查看和筛选另一个是导出成文件。导出格式优先做 Markdown 和 JSON后续要接测试管理平台再考虑 XLSX。导出逻辑放在后端比较合适前端只负责点击下载。后端根据 project_id 查出全部用例按分类排序拼接成文档再以附件形式返回。注意拼接时对步骤数组做换行处理预期结果和前置条件不要混在一个段落里生成的文档要能直接给测试评审用。6. 常见报错和排查顺序6.1 后端启动失败项目刚生成完最容易报的是后端起不来。常见原因按概率排序依赖没装全缺失某个库。Python 版本过低不满足依赖包要求。端口被占用。数据库文件路径不存在或者目录没有写权限。配置文件里的参数读不到比如 .env 没创建。排查顺序是先看启动日志再确认包版本再检查配置文件和端口。不要一报错就重新生成整个项目那样会破坏已经调通的模块。先把报错信息读清楚大多数启动失败都是环境问题。6.2 前端页面调接口报跨域前端 5173 端口调后端 8000 端口一定会遇到跨域问题。FastAPI 后端需要配置 CORSMiddleware这是最常被忘记的一步。配完还报跨域时检查后端是否重启、允许的来源是否包含前端地址、接口路径是否有前缀差异。前端接口也要注意 BASE_URL 配置。拿 Vite 来说开发环境通常配成 http://localhost:8000生产环境要改成实际后端地址。建议把 BASE_URL 放在环境变量文件里避免写死在代码中。6.3 AI 返回内容解析报错生成用例时最常见的报错是 JSON 解析失败。可能原因模型输出被截断、返回了 Markdown 代码块、字段名和预期不一致、模型擅自改了分类枚举。我的处理方式分三步先对返回文本做清理去掉代码块标记和首尾空白再做一次严格解析解析失败时带着错误信息让模型重新输出一次。重试也不要无限重试设成最多 2 次就够了。如果连续失败多半是提示词模板有问题调完再测。6.4 低配置环境下怎么降级如果你的机器内存只有 8G或者本机没有独立显卡这个项目是能跑的但要把预期调低。本机只做开发调试批量生成密集任务不建议在本机长时间跑。低配置环境下的调整项包括数据库用 SQLite不引入 MySQL 或 Docker前端开发时不开多余的服务日志级别可以调高减少磁盘写入批量生成时并发数降到 1。项目本身不依赖本地大模型推理所有生成都走接口所以机器性能影响的是项目运行流畅度不是生成能力本身。7. 几句实在建议Plan 模式搭全栈框架很快但“快”的前提是需求边界清楚、技术选型先定死、Plan 阶段认真评审。如果需求本身就是模糊的Plan 模式也救不了生成出来的结构再规范最后也要大改。10 分钟这个数字也不是每次都灵环境全新、依赖没装、网络不通的情况下第一次准备花掉 20 到 30 分钟都很正常。我个人更建议把这个项目当做一次完整的小型工程实践来做先跑通单条生成再做批量再接导出最后把日志和任务状态补上。每一步都验证过后再进入下一步看起来慢实际最稳。测试用例生成这一步AI 能做的是把“从需求到初版用例”的时间大幅缩短但它生成的用例仍然需要人工评审。边界条件是否覆盖、步骤是否真实可执行、预期结果是否符合业务规则这些还是测试工程师的判断范围。工具是用来提效的不是用来替人做质量决策的。如果以后要在这套框架上继续扩展可以优先考虑几个方向接入更多模型来源、支持上传接口文档生成用例、增加用例评审流程、把生成记录和人工修改版本做对比。这些都是同一个框架上的增量功能底层的项目结构在 Plan 阶段打好了后面迭代就没有那么痛苦。