最近很多人在做“AI 测试用例生成”这类项目。大家普遍以为最大的难关是算法是模型调优结果真正动手时却发现项目连基本的目录结构都没有后端接口和前端页面各写各的数据库表结构改了三次还对不上等到想联调的时候一天已经过去了。如果你也卡在这里这篇内容应该能帮你换一个思路。本文要聊的不是写测试用例生成算法本身而是如何使用 AI 编码工具里的Plan 模式在 10 分钟左右搭好一个“AI 测试用例项目”的全栈框架包括后端服务、前端页面、数据库模型、接口联调和运行验证。我会把 Plan 模式和普通手动模式的区别讲清楚给出可直接复制的提示词模板、工程目录、核心代码和排查清单。先给一个明确判断Plan 模式的价值不在“让 AI 自动写代码”而在“让 AI 先给方案、列任务、再动手”。对于全栈框架搭建这类任务它比直接让 AI 生成一坨代码要可靠得多。1. 这篇文章真正要解决的问题很多开发者在接触 AI 编程工具时都有一个误区以为工具的强弱取决于它一次能生成多少代码。实际上一次生成 500 行代码很容易难的是这 500 行代码和你已有的工程结构能不能融合。举个例子。你说“帮我生成一个测试用例管理系统的后端”工具可能真的会生成一个main.py里面有路由、有数据库连接、有模型定义。但当你继续让它“加一个用户登录接口”时它可能又生成了一份新的main.py和你之前那份完全对不上。几次迭代之后工程目录里出现大量重复文件代码风格混乱最终只能推倒重来。这正是“全栈项目框架”搭建最痛苦的地方它不是单一任务而是一组互相依赖的任务组合。它要求目录结构、数据模型、接口路径、前端路由、环境变量都保持一致。如果一开始没有整体规划后面每一步都在还债。Plan 模式解决的正是这个问题。它让 AI 在写代码之前先输出一份工程计划包括项目采用什么技术栈前后端目录结构怎么划分数据库表结构有哪些字段接口路径如何设计哪些任务先做、哪些任务后做各模块之间如何联调。你可以先审查这份计划确认没问题后再让 AI 执行。对全栈框架搭建来说这个“先规划后实施”的流程比直接让 AI 干活重要得多。读完这篇文章你会得到三样东西一份可复用的 Plan 模式全栈搭建提示词模板一套 AI 测试用例项目的工程结构和技术选型方案一条从生成代码到启动验证的完整排查路径。2. Plan 模式是什么先理解“计划”和“执行”的分工先说清楚概念。在不同 AI 编码工具里Plan 模式的名字不完全一样有的叫 Plan Mode有的叫 Planning有的叫“规划模式”。但核心逻辑是相通的AI 先做需求分析和任务拆解在你确认之后再进入代码生成阶段。要理解 Plan 模式最好先对比一下 AI 编码工具的几种常见模式。这里用一组表格来说明模式典型称呼工作方式适合场景风险点手动/普通模式Normal、Direct、手动模式直接根据当前对话生成代码或修改文件单文件小改动、临时脚本、代码片段补全容易推倒重来不改动时也容易带偏上下文Plan 模式Plan、规划模式、先计划后执行先生成方案、拆解任务确认后再实施全栈框架搭建、多模块改造、新项目初始化需要你具备基本技术判断力去审核方案自动/代理模式Auto、Agent、自主执行模式自动拆解任务并连续执行直到目标完成单一目标明确的批处理任务、规范化改造依赖工具链稳定性出错时容易在错误方向越走越远这组对比里有几个点值得展开。第一手动模式不等于“不能用”。在修改一个函数、调整一段样式、解释一段报错时手动模式反而是效率最高的因为它不需要额外“规划开销”。但如果任务是“搭建整个项目框架”手动模式的问题就暴露了AI 只能根据当前窗口的内容做判断看不到全局也无法保证多次生成的文件之间风格一致。第二Plan 模式和自动模式容易混淆。很多人听到“自动模式”就觉得更高级以为它连计划都能省了。其实自动模式的核心是“自主执行”它依然需要有一个明确的计划只不过计划由 AI 自己生成并自己执行。而 Plan 模式把“计划”这一步单独拿出来交给你审查你可以把关、调整、否决。对于全栈项目这种需要明确工程约束的场景Plan 模式更符合“先设计后编码”的工程习惯。第三Plan 模式真正降低的是返工成本。直接让 AI 生成代码生成得再快错了也要重来。而 Plan 模式把错误拦截在编码之前你在方案阶段就能发现技术栈不合理、表结构缺字段、接口设计不统一等问题。这个阶段改错误的成本远低于代码写完再改的成本。从我的经验看Plan 模式最适合三类任务从零搭建新项目骨架给现有项目增加一个完整的功能模块重构或迁移技术栈比如从单体脚本改造成前后端分离工程。AI 测试用例项目的全栈框架搭建正好同时命中前两类。这也是为什么用 Plan 模式来做这件事效率提升会非常明显。3. 项目全景AI 测试用例系统到底需要哪些功能很多文章讲“全栈项目”上来就贴目录结构读者也不知道为什么要有这些目录。这里我想反过来先从业务功能推导工程结构。假设你要搭建一个“AI 测试用例生成系统”最小可用版本应该包含以下功能核心功能测试用例生成用户输入一段需求描述系统调用大模型接口生成对应的测试用例集合包括用例编号、前置条件、操作步骤、预期结果、优先级等字段。辅助功能用例管理生成的用例可以保存、查看、删除。要做到这一点后端需要有一个数据库表来存用例前端需要有用例列表页和详情页。辅助功能生成历史用户可能多次生成系统需要记录每次生成的需求文本、模型版本、生成时间、生成结果。这决定了数据库需要一个“生成记录表”。辅助功能模型配置不同场景可能需要调用不同模型系统需要允许用户配置模型名称、API 地址、API Key。这里要特别提醒API Key 属于敏感信息不能硬编码在前端或代码里应该通过环境变量管理并且在后端只读使用。工程能力接口联调前端调用后端接口后端访问数据库和模型服务。这就需要有明确的接口协议、统一的响应格式、跨域处理方案。把这些功能映射到工程上你就很容易理解一个全栈框架为什么必须是下面这个样子ai-testcase-platform/ ├── backend/ # 后端工程 │ ├── app/ │ │ ├── main.py # FastAPI 入口 │ │ ├── core/ # 配置、安全、依赖 │ │ ├── models/ # 数据库模型 │ │ ├── schemas/ # 接口请求/响应模型 │ │ ├── services/ # 业务逻辑包括 AI 调用 │ │ ├── routers/ # API 路由 │ │ └── utils/ # 工具函数 │ ├── requirements.txt │ └── .env.example ├── frontend/ # 前端工程 │ ├── src/ │ │ ├── api/ # 请求封装 │ │ ├── views/ # 页面 │ │ ├── components/ # 组件 │ │ └── router/ # 路由配置 │ ├── package.json │ └── vite.config.ts ├── docs/ # 项目文档 │ ├── API.md │ └── database.md └── README.md从这个结构可以看出技术栈选型和业务功能是强绑定的。后端需要快速开发 HTTP 接口方便对接第三方 AI 接口所以 Python FastAPI 是很自然的选择前端需要表单输入和列表展示Vue 3 加 Element Plus 可以快速实现数据库用 MySQL 存储用例和历史记录Redis 可以留到后续做缓存和限流。下面是本文使用的推荐技术选型版本号以你实际安装为准这里重点是组合逻辑层级技术选型作用前端Vue 3 Vite Element Plus Axios页面、请求、组件后端Python FastAPI SQLAlchemyAPI 服务、ORM数据库MySQL 8.x持久化存储测试用例和生成记录AI 接入OpenAI 兼容 HTTP 接口测试用例生成模型调用环境管理Python venv npm依赖隔离和包管理这里做一个保守提示如果你所在环境无法使用 MySQL也可以先用 SQLite 跑通流程框架结构完全一致只是连接串不同。很多全栈项目在早期阶段都用 SQLite 做原型验证之后再切换到 MySQL。4. 环境准备与前置条件开始搭建之前先确认本机环境。这部分如果缺项后续步骤会反复出错建议先花三分钟检查一遍。4.1 后端环境需要安装 Python 3.10 或更高版本并确认 pip 可用。在终端执行python --version pip --version如果 Python 版本过低建议先升级。创建项目虚拟环境并安装依赖的命令如下mkdir -p ai-testcase-platform cd ai-testcase-platform python -m venv venv source venv/bin/activate # Windows 环境使用 venv\Scripts\activate pip install fastapi uvicorn sqlalchemy pymysql python-dotenv httpx pydantic这里逐个说明依赖的作用fastapiWeb 框架负责路由和参数校验uvicornASGI 服务器负责启动应用sqlalchemyORM负责数据库操作pymysqlMySQL 驱动python-dotenv读取.env环境变量httpx异步 HTTP 客户端用来调用大模型接口pydanticFastAPI 自带依赖用于数据校验FastAPI 安装时会自动带上。4.2 前端环境需要 Node.js 18 或更高版本并确认 npm 可用node --version npm --version使用 Vite 创建 Vue 3 项目npm create vitelatest frontend -- --template vue cd frontend npm install npm install axios element-plus vue-router这里需要说明npm create vite在不同版本下交互提示可能不同如果它询问框架选择 Vue 即可。安装element-plus是为了获得现成的表格、表单和按钮组件避免自己写 UI。4.3 数据库准备如果使用 MySQL需要先创建数据库CREATE DATABASE IF NOT EXISTS ai_testcase DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;后端连接数据库时建议把连接信息放到.env文件避免写死在代码里。示例DATABASE_URLmysqlpymysql://root:yourpasswordlocalhost:3306/ai_testcase AI_API_BASEhttps://api.example.com/v1 AI_API_KEYyour-api-key AI_MODELgpt-4o-mini这里特别提醒.env文件要加入.gitignore不能提交到代码仓库。API Key 一旦泄露会造成不必要的资损风险。仓库中只保留.env.example让别人知道需要配置哪些变量。5. 核心流程拆解用 Plan 模式搭全栈框架的 7 个步骤环境准备好之后进入正题。下面是用 Plan 模式搭建全栈框架的完整流程一共七步。5.1 明确需求描述Plan 模式的效果很大程度取决于你最初的需求描述。描述里至少要包含四个要素项目类型、目标功能、技术栈偏好、交付范围。一个推荐的描述模板是请帮我规划一个 AI 测试用例生成平台的全栈项目框架。 项目定位 - 用户输入需求文本调用大模型 API 生成测试用例 - 生成的用例可以保存、查看、删除 - 提供生成历史记录功能。 技术栈偏好 - 后端Python FastAPI SQLAlchemy - 前端Vue 3 Vite Element Plus - 数据库MySQLORM 建表 - AI 接入OpenAI 兼容接口 交付范围 - 输出完整的项目目录结构 - 输出后端数据库模型和核心接口设计 - 输出前端页面和请求封装方案 - 输出启动和联调步骤 - 先不要写具体业务代码只需要规划方案。注意最后一句“先不要写具体业务代码只需要规划方案”这是触发 Plan 模式的关键。它让 AI 进入规划状态而不是立刻生成代码。5.2 让 AI 输出工程计划当你用 Plan 模式发送这个需求后AI 通常会输出一份计划包括目录结构、技术选型、数据库表、接口清单和任务顺序。合格的计划应该包含以下内容后端目录结构里models、routers、services、schemas等模块划分清晰前端目录结构里api、views、components、router分层明确数据库至少包含“测试用例表”和“生成记录表”两张核心表接口设计覆盖“生成用例、查询列表、删除用例、查看历史”几个核心动作任务顺序合理先建数据库层再写接口层最后做前端联调。如果 AI 输出的计划缺少某一部分比如没有提数据库表设计你应该在确认之前把它补上而不是直接让它开始干活。Plan 模式最大的价值就在这一步。5.3 审核技术方案和依赖AI 给出的技术方案不一定完全合理你需要快速检查几个关键点检查接口设计。例如“生成用例”接口应该用POST /api/testcases/generate还是POST /api/generate建议采用带资源前缀的 RESTful 风格路径统一管理。检查数据模型。例如“测试用例”表需要包含testcase_id、title、precondition、steps、expected_result、priority、created_at等字段而不是只有一个“用例内容”字段。字段拆分得越细前端展示和后续筛选就越容易。检查安全边界。例如 API Key 是否放在环境变量里CORS 是否只放行指定的前端域名删除接口是否校验权限。如果计划里完全没提这些你最好主动加进去。5.4 确认计划并开始执行计划确认后切换到执行模式让 AI 按照计划生成代码。注意这一步要指定“按步骤执行”不要一次性生成所有代码否则你很难定位问题。推荐的执行指令好的按计划开始执行。请先完成后端的数据库模型和核心配置再写接口层每完成一步告诉我文件路径和需要安装的依赖。这种分步执行方式能让 AI 每生成一个模块你都检查一个模块避免到最后一次性面对几十个文件。5.5 前后端分别生成与自测后端生成完成后先启动后端服务用接口文档或 curl 验证核心接口是否返回正常前端生成完成后先跑起页面确认路由和页面组件能正常展示再进行联调。这里有一个常见问题很多人在前后端都写完后再联调结果同时出现一堆错误分不清是前端的问题还是后端的问题。正确做法是分阶段验证每一层稳定后再进入下一层。5.6 联调与数据打通前后端分别验证通过后开始联调。这一步重点验证前端能否调用后端接口后端能否从数据库读取和写入数据大模型接口能否真实返回测试用例前端能否正确解析并展示后端返回的用例列表。如果联调失败不要急着让 AI 重写代码先按第 9 章的排查清单定位问题。5.7 框架迭代与文档沉淀框架跑通后后续功能迭代都基于这套骨架进行。建议把 Plan 模式生成的 API 文档、数据库设计文档放到项目的docs目录方便团队协作和后续维护。6. 完整示例Plan 提示词与生成结果对比这一章给出一个从“Plan 提示词”到“AI 生成的计划”再到“核心代码”的完整示例。你可以直接复制以下内容到你的 AI 编码工具中尝试。6.1 Plan 模式提示词模板请先不要写代码而是输出一份项目规划方案。 我准备开发一个 AI 测试用例生成平台请设计全栈项目框架。 业务场景 1. 用户在前端输入需求文本 2. 后端调用大模型接口生成测试用例 3. 生成的用例保存在数据库用户可以查看和删除 4. 系统记录每次生成的历史支持重新查看。 请输出 1. 后端目录结构使用 FastAPI 2. 前端目录结构使用 Vue 3 Vite 3. 数据库表结构包含测试用例表和生成记录表 4. 核心 API 接口路径和请求响应格式 5. 开发任务的先后顺序。6.2 AI 可能输出的计划结果以下是 AI 在 Plan 模式下可能给出的计划摘要你可以对照检查自己的项目是否覆盖完整【技术方案】 后端FastAPI SQLAlchemy MySQL 前端Vue 3 Vite Element Plus Axios 数据库ai_testcase 【目录规划】 backend/app/ core/config.py # 全局配置 models/ # SQLAlchemy 模型 schemas/ # Pydantic 模型 routers/ # API 路由 services/ # 业务逻辑和大模型调用 main.py # 应用入口 frontend/src/ api/ # Axios 请求封装 views/ # 页面视图 components/ # 通用组件 router/ # 前端路由 【数据库表】 testcase: id, title, precondition, steps, expected_result, priority, created_at generation_record: id, requirement, model_name, status, result_summary, created_at 【接口设计】 POST /api/testcases/generate GET /api/testcases DELETE /api/testcases/{id} POST /api/testcases/{id}/save这个计划的合理之处在于它把“生成”和“保存”分开生成接口只负责调用模型并返回结果保存接口才负责写入数据库。这样设计的好处是用户可以先预览生成结果确认满意后再保存避免数据库里堆积大量无用的中间数据。6.3 后端核心代码FastAPI 入口与配置下面是后端入口文件的完整示例# 文件路径backend/app/main.py from fastapi import FastAPI from fastapi.middleware.cors import CORSMiddleware from app.core.config import settings from app.routers import testcase_router app FastAPI(titleAI 测试用例生成平台, version0.1.0) # 开发环境允许前端本地跨域访问生产环境请按实际域名收紧 app.add_middleware( CORSMiddleware, allow_originssettings.CORS_ORIGINS, allow_credentialsTrue, allow_methods[*], allow_headers[*], ) app.include_router(testcase_router, prefix/api) app.get(/health) def health_check(): return {status: ok}对应配置文件# 文件路径backend/app/core/config.py import os from dotenv import load_dotenv load_dotenv() class Settings: DATABASE_URL: str os.getenv( DATABASE_URL, mysqlpymysql://root:passwordlocalhost:3306/ai_testcase ) AI_API_BASE: str os.getenv(AI_API_BASE, https://api.example.com/v1) AI_API_KEY: str os.getenv(AI_API_KEY, ) AI_MODEL: str os.getenv(AI_MODEL, gpt-4o-mini) CORS_ORIGINS: list os.getenv(CORS_ORIGINS, http://localhost:5173).split(,) settings Settings()配置类集中管理所有环境变量后续修改配置只动.env文件不需要改业务代码。这里用load_dotenv()保证本地开发能读取.env中的配置。6.4 测试用例生成接口“生成测试用例”是整个项目最核心的接口。它接收用户的“需求文本”组装 Prompt调用大模型接口然后把返回结果解析成结构化用例列表。# 文件路径backend/app/schemas/testcase.py from pydantic import BaseModel from typing import List, Optional class TestcaseGenerateRequest(BaseModel): requirement: str model: Optional[str] None class TestcaseItem(BaseModel): id: str title: str precondition: str steps: str expected_result: str priority: str class TestcaseGenerateResponse(BaseModel): result: List[TestcaseItem] class TestcaseSaveRequest(BaseModel): title: str precondition: str steps: str expected_result: str priority: str generation_id: Optional[int] None# 文件路径backend/app/services/ai_service.py import json import httpx from app.core.config import settings SYSTEM_PROMPT 你是一名资深测试工程师。用户会提供一个软件需求描述 请生成一组测试用例输出 JSON 格式字段包括 title, precondition, steps, expected_result, priority。 steps 使用换行分隔。 async def generate_testcases(requirement: str) - list: payload { model: settings.AI_MODEL, messages: [ {role: system, content: SYSTEM_PROMPT}, {role: user, content: requirement}, ], temperature: 0.3, } headers {Authorization: fBearer {settings.AI_API_KEY}} async with httpx.AsyncClient(timeout60) as client: resp await client.post( f{settings.AI_API_BASE}/chat/completions, jsonpayload, headersheaders, ) resp.raise_for_status() data resp.json() content data[choices][0][message][content] # 这里假设模型按约定返回 JSON 数组实际接入时需做容错 return json.loads(content)# 文件路径backend/app/routers/testcase.py from fastapi import APIRouter, HTTPException from app.schemas.testcase import TestcaseGenerateRequest, TestcaseGenerateResponse from app.services.ai_service import generate_testcases router APIRouter(prefix/testcases, tags[testcases]) router.post(/generate, response_modelTestcaseGenerateResponse) async def generate(req: TestcaseGenerateRequest): if not req.requirement.strip(): raise HTTPException(status_code400, detail需求描述不能为空) try: result await generate_testcases(req.requirement) return TestcaseGenerateResponse(resultresult) except Exception as e: raise HTTPException(status_code500, detailf生成失败: {str(e)})这段代码里最值得注意的是ai_service.py的职责划分。它只负责调用大模型接口并解析返回结果不涉及数据库操作。这样设计是为了将来替换模型供应商时只改这一个文件即可。实际接入时模型返回的内容格式往往不稳定解析 JSON 之前需要做一层清洗和容错比如去除 Markdown 代码块标记、修复非法 JSON 等。6.5 前端核心代码请求封装与测试用例页面前端部分用 Axios 封装请求// 文件路径frontend/src/api/request.js import axios from axios const request axios.create({ baseURL: http://localhost:8000/api, timeout: 60000 }) export default request测试用例生成页面!-- 文件路径frontend/src/views/TestCaseGenerate.vue -- template div classgenerate-container el-card template #headerAI 测试用例生成/template el-input v-modelrequirement typetextarea :rows6 placeholder请输入需求描述例如用户登录功能要求支持手机号和验证码登录 / el-button typeprimary :loadingloading clickhandleGenerate 生成测试用例 /el-button /el-card el-table v-iftestcases.length :datatestcases stylemargin-top: 16px el-table-column proptitle label用例标题 min-width180 / el-table-column propprecondition label前置条件 min-width150 / el-table-column propsteps label操作步骤 min-width220 / el-table-column propexpected_result label预期结果 min-width180 / el-table-column proppriority label优先级 width90 / /el-table /div /template script setup import { ref } from vue import request from ../api/request const requirement ref() const testcases ref([]) const loading ref(false) async function handleGenerate() { if (!requirement.value.trim()) { return } loading.value true try { const { data } await request.post(/testcases/generate, { requirement: requirement.value }) testcases.value data.result || [] } catch (error) { console.error(生成失败, error) } finally { loading.value false } } /script这段代码的逻辑很直接输入需求文本点击按钮然后通过request.post调用后端生成接口把返回的用例数组渲染成表格。loading状态用于防止重复点击和提升交互反馈。如果你希望“生成后保存到数据库”可以在表格下方再加一个“保存这条用例”按钮调用POST /api/testcases/{id}/save接口。模板字段中的id可以临时用时间戳生成保持前端展示一致即可。6.6 数据库模型示例如果需要把生成结果保存到数据库SQLAlchemy 模型可以这样设计# 文件路径backend/app/models/testcase.py from sqlalchemy import Column, Integer, String, Text, DateTime, func from app.core.database import Base class Testcase(Base): __tablename__ testcase id Column(Integer, primary_keyTrue, indexTrue) title Column(String(255), nullableFalse) precondition Column(Text, default) steps Column(Text, default) expected_result Column(Text, default) priority Column(String(16), defaultP2) created_at Column(DateTime, server_defaultfunc.now()) class GenerationRecord(Base): __tablename__ generation_record id Column(Integer, primary_keyTrue, indexTrue) requirement Column(Text, nullableFalse) model_name Column(String(128), default) status Column(String(32), defaultsuccess) result_summary Column(Text, default) created_at Column(DateTime, server_defaultfunc.now())这里用server_defaultfunc.now()让数据库生成创建时间而不依赖代码传入。测试用例表和生成记录表分开是为了避免在一条记录里保存大量重复文本后续做统计查询也更方便。7. AI 测试用例核心模块的实现思路全栈框架搭好之后真正决定项目质量的是几个核心模块。这里展开讲一下实现思路重点不是堆代码而是帮你建立模块之间的边界意识。7.1 Prompt 模板管理测试用例生成的 Prompt直接决定输出的质量。不建议把 Prompt 写死在接口里而是独立成模块或者放进配置文件。这样可以针对不同测试类型功能测试、接口测试、性能测试提示词做切换。推荐的最小 Prompt 结构你是一名资深测试工程师。 请根据以下需求描述设计完整的功能测试用例。 要求覆盖正常流程、异常流程和边界场景。 输出格式为 JSON 数组每个用例包含 title、precondition、steps、expected_result、priority 字段。 需求描述{requirement}这里的变量只有{requirement}其他部分固定。实际项目可以把这个模板放到services/prompts/目录通过读取文件的方式加载方便后续迭代。7.2 模型返回结果解析大模型返回格式不稳定是全流程中最大的坑。模型可能返回 Markdown 代码块包裹的 JSON也可能在 JSON 前后添加解释文字甚至返回不合法的 JSON。因此接口层不能直接json.loads(content)。更稳妥的做法是先尝试直接解析失败后用正则提取代码块中的 JSON 片段再做一次解析仍然失败就返回明确的错误提示并记录原始返回内容方便排查。这一步是 AI 测试用例项目能否真正可用的关键。很多人项目卡住不是因为框架没搭好而是因为模型返回格式稍微一变整个后端就报错。7.3 生成与保存分离前面提到过生成接口和保存接口要分开。“生成”是瞬时的、可重复的不落库“保存”是用户主动触发的才写入数据库。这个设计能避免测试过程中把数据库塞满无意义的垃圾数据也让前端交互更自由用户可以在表格里修改用例内容然后再保存。7.4 历史记录与结果回看生成历史的价值在于复现。用户可能想知道“我上一次输入了什么需求生成了什么用例”。实现上只需要在用户点击“生成”时异步写一条generation_record记录内容包括输入需求、模型名、时间、结果摘要即可。需要注意的是不要把整个生成结果原样丢进记录表。如果生成结果有几十条用例全部存在result_summary里会非常长。建议只存摘要信息或者只关联生成记录 ID具体结果在前端有需要时再重放。8. 运行结果与效果验证框架搭好、核心代码写完最关心的就是“能不能跑起来”。下面是一套标准的验证流程。8.1 启动后端在项目根目录执行cd backend source venv/bin/activate uvicorn app.main:app --reload --port 8000预期看到类似输出INFO: Uvicorn running on http://127.0.0.1:8000 INFO: Application startup complete.然后在浏览器访问http://127.0.0.1:8000/docs如果能打开 Swagger 接口文档说明后端启动成功。先用健康检查接口验证curl http://127.0.0.1:8000/health预期返回{status:ok}8.2 启动前端打开另一个终端cd frontend npm run dev预期看到VITE v5.x.x ready in xxx ms ➜ Local: http://localhost:5173/8.3 验证生成接口如果暂时没接真实大模型可以在ai_service.py里临时返回一组写死的测试用例验证整个链路是否通。这种“假数据联调”的方式在全栈开发中非常常见可以帮你把后端逻辑和前端展示先跑通最后再接真实模型。# 临时替代真实模型调用 async def generate_testcases(requirement: str) - list: return [ { id: 1, title: 验证正常登录, precondition: 用户已注册, steps: 输入账号密码点击登录, expected_result: 登录成功进入首页, priority: P1, } ]接入后前端页面输入需求并点击生成表格出现测试用例说明前后端接口联调成功。8.4 验证数据库读写如果接入了数据库可以在后端启动后调用一个写接口再查看数据库表数据是否新增。以“保存用例”接口为例curl -X POST http://127.0.0.1:8000/api/testcases/1/save \ -H Content-Type: application/json \ -d {title:验证登录,precondition:已注册,steps:输入账号密码,expected_result:登录成功,priority:P1}预期返回保存成功提示。随后查询数据库SELECT id, title, priority FROM testcase;如果能看到刚插入的数据说明数据库读写链路正常。8.5 判断成功标准一个全栈项目框架是否搭建成功可以从以下四个维度判断后端服务能正常启动接口文档可访问前端服务能正常启动页面可访问前后端能完成一次真实的请求-响应循环数据库读写正常数据能持久化。如果这四点都满足说明框架已经跑通后续功能迭代都建立在这个稳定的骨架之上。9. 常见问题与排查思路搭建过程中大概率会遇到一些问题。整理了一份高频问题排查表按照“问题现象、可能原因、排查方式、解决方案”展开。问题现象可能原因排查方式解决方案后端启动失败提示端口被占用8000 端口被其他进程占用lsof -i :8000或netstat -ano关闭占用进程或改用其他端口启动前端调用后端接口提示 CORS 错误后端未配置正确的跨域来源查看浏览器 Console 报错在 FastAPI 的 CORSMiddleware 中放行前端域名http://localhost:5173数据库连接失败数据库未启动、账号密码错误、库名不存在先检查.env中DATABASE_URL再用客户端工具连接测试修正连接串确认库已创建模型接口返回 401API Key 错误或未配置查看后端日志中的响应状态码检查.env中的AI_API_KEY确认 Key 有效模型返回内容无法解析为 JSON模型输出包含额外文本或 Markdown 格式打印原始content内容增加解析容错先提取 JSON 片段再解析前端刷新页面找不到路由前端路由使用了 history 模式但服务端未配置观察 URL 变化开发环境用 Vite 的historyApiFallback生产环境由 Nginx 配置重写生成的用例没有保存到数据库前端只调用了生成接口没有调用保存接口查看 Network 请求列表在页面增加保存按钮调用保存接口项目里出现了大量重复代码文件AI 没有按计划执行多次生成整份文件检查仓库文件变更记录让 AI 按步骤执行每次只改一个模块且先审阅计划再动手这些问题的共同点是不要一上来就怀疑 AI 写错了先判断是哪一层出了问题。前端还是后端、请求没发出还是响应没返回、数据没写入还是读取失败定位到具体层级后再修效率要高得多。10. 最佳实践与工程建议课程的后半部分把这次搭建过程中的工程经验总结成几条建议供你在自己项目里参考。10.1 把 Plan 模式当作“评审关口”Plan 模式不是用来让 AI 展示它有多少想法的而是给你一个“低成本纠错”的机会。在确认计划之前多花三分钟检查技术栈是否合理、表结构是否覆盖业务、接口路径是否统一。这个关口把得越严后面的返工就越少。最忌讳的操作是AI 给出计划后看都不看就说“可以开始吧”。那 Plan 模式就退化成了手动模式甚至更慢因为多了一次无意义的规划步骤。10.2 前后端联调要尽早开始不要让前后端各自开发到很后面才联调。最理想的做法是后端先把接口路径和返回格式确定下来前端用 Mock 数据并行开发后端接口就绪后前端把请求地址从 Mock 切到真实接口。这样能避免到最后一天才面对一堆接口契约问题。10.3 敏感信息坚决不进代码AI 测试用例项目必然要接入大模型 APIAPI Key、数据库密码、内部服务地址都属于敏感信息。这些内容只能出现在.env文件中并且.env必须加入.gitignore。仓库里只保留.env.example模板。如果你在 Team 协作还要约定哪些人不该接触到生产环境的 Key。最好通过专用的密钥管理服务注入环境变量而不是在本地.env里共享。10.4 每次生成代码后都要立即验证AI 生成代码后不要攒着一口气全部运行。每生成一个模块就做一次最小验证写完数据库模型先建表成功写完路由先访问接口不报错写完前端请求封装先发一个请求看到返回。这种“小步快跑”的节奏能把错误控制在最小范围。出了问题也只需要看最近一次改动的几行代码。10.5 文档即代码Plan 模式下 AI 生成的方案文档非常有价值。把 API 接口说明、数据库设计说明保存到项目的docs目录后续再接新成员、迭代新功能时都会省很多沟通成本。建议在 Plan 提示词里明确要求 AI 输出这些文档而不是只输出代码。10.6 不要让 AI 替你决定安全边界全栈项目涉及用户输入、数据库操作、模型调用安全边界必须由你来把关。AI 会为你生成代码但它不会为你的项目负责。这个项目里至少要注意用户输入必须做长度限制和空值校验删除接口在前端要有二次确认在后端要校验记录是否存在大模型接口调用要做好超时处理避免请求长时间挂起所有接口响应统一用结构化 JSON方便前端统一处理错误生产环境必须关掉调试模式并限制可访问来源。这些内容不一定都需要在首版实现但规划阶段就要写进方案里技术债不能靠后续“再说”来解决。10.7 用版本管理兜底全栈框架搭建过程中AI 可能会突然生成一份和预期完全不同的文件。建议每次让 AI 动手前都在 Git 里留下一份干净的分支或提交。这样即使 AI 改错了也能一键回滚重新调整计划再执行。Plan 模式搭配版本管理才称得上完整的“规划-执行-回滚”闭环。11. 总结与后续学习方向本文的核心观点是AI 测试用例项目的难点不在单点功能而在全栈框架的工程一致性。Plan 模式通过“先规划、后执行”的流程把返工成本控制在编码之前是搭建全栈项目框架时值得优先使用的工作方式。文中给出了完整的 Plan 模式提示词模板、FastAPI 后端骨架、Vue 3 前端页面、数据库模型设计以及从启动到联调的验证路径。你可以直接拿这套结构作为自己项目的基础再根据实际的模型接口和业务规则做调整。如果你手里正打算做 AI 测试用例项目建议按下面的顺序动手先跑通uvicorn启动后端和npm run dev启动前端用假数据验证生成接口和前端展示再接入真实大模型重点处理返回格式解析最后补上数据库保存、历史记录和权限控制。把这套流程走完你的 AI 测试用例项目就有了一个随时可以扩展的工程骨架。后续再深入模型调优、Prompt 优化、提示词模板管理、测试用例批量导入导出都是在现在这个框架上继续叠加能力。希望这份完整的搭建思路对你后面做类似项目也有参考价值。