使用 AI 编程开发大模型测试系统的实践与技巧

约 6 分钟 · 3096 字 · 5 views
使用 AI 编程开发大模型测试系统的实践与技巧

使用 AI 编程开发大模型测试系统的实践与技巧

导读：文章以"用 Trae/Cursor 从零开发 LLM 测试系统（FastAPI + React）"为案例，核心结论是 AI 编程的关键在"写提示"而非"写代码"：把大需求拆成接口结构→数据模型→前端组件→联调日志的可验证小任务，配以"角色 + 目标 + 要求 + 上下文 + 样例"的提示词模板，再靠 MVC 分层、统一日志、ORM 迁移与 AI code review 兜底质量，走完从架构设计到部署上线的全流程。适合尝试用 AI 辅助开发内部工具、或想评估候选人在 AI 编程实践中真实功底的工程团队。

一、实践：用 AI 编程从零搭出一个 LLM 测试系统

1. 项目背景

我们用 Trae（以及同类的 Cursor 等 AI 编程助手）从零开发了一个「LLM 测试系统」。这个系统负责对接团队内部的大模型问答服务，完成测试与校验工作，技术栈采用 Python（FastAPI）+ React。

整个过程走下来，最大的感受是：AI 编程的关键不在于「让 AI 帮我写完所有代码」，而在于「让 AI 参与设计、实现、优化的全过程」。下面按时间线分享我们的做法。

2. 功能拆分：把大需求拆成可验证的小任务

在跟 AI 交互时，我们不会直接丢一个「大需求」过去，而是把它拆解成一个个可验证的小任务，按节奏迭代：

  • Step 1：设计接口结构（输入、输出、接口路由）
  • Step 2：实现数据库模型（ORM 定义）
  • Step 3：实现前端交互组件
  • Step 4：联调与日志输出

每个阶段都给出一个具体的提示，例如：

请帮我生成一个 FastAPI 接口，用于新增测试任务，输入参数包括模型名、prompt，返回任务 ID。

这样结构化的提问，能让 AI 输出更符合整体架构思路的代码，而不是一次性产出一大坨难以调试的东西。

3. 给 AI 写需求：提示词模板

「高质量提示词 ≈ 高质量代码」，我们实践出一个推荐结构：

你是一个资深全栈工程师，项目使用 Python + React。

目标：实现 ×× 功能。

要求：
1. 遵循 MVC 结构。
2. 遵循命名规范（snake_case / PascalCase）。
3. 所有接口需返回统一格式 { code, message, data }。
4. 日志统一使用 logging 模块。
5. 提供类型注解与必要注释。

几个技巧要点：

  • 多用「要求：」「请遵循：」这样的约束式语句，让 AI 输出边界清晰；
  • 给出完整上下文（项目架构、现有文件结构），AI 才知道往哪个框架里填代码；
  • 给出输入输出样例，让模型明确需求边界，避免自由发挥。

4. 架构设计：MVC 分层与目录规范

即使有 AI 帮忙，架构仍然要人来定。我们坚持经典的分层约定：

层 职责 技术选型
Model 层 数据库实体与业务逻辑 SQLAlchemy / Pydantic
View 层 前端页面 React + Tailwind
Controller 层 API 层（接口路由） FastAPI

AI 辅助开发时，用提示词把结构固化下来：

请帮我为 FastAPI 项目创建一个标准的 MVC 结构，包含 models/、controllers/、routes/、schemas/ 等模块。

通过这类结构化命令，AI 可以快速生成基础模板，并自动填充依赖，项目骨架几分钟就能立起来。

5. 编码规范统一：日志与前端样式

系统调试阶段，日志尤为关键。统一日志格式，才能方便地追踪 AI 自动生成模块的行为：

import logging

logging.basicConfig(
    level=logging.INFO,
    format="[%(asctime)s] [%(levelname)s] %(name)s: %(message)s",
)
logger = logging.getLogger(__name__)

我们会在给 AI 的每个文件提示里要求它自动引入 logger，而不是用 print() 调试。前端则统一使用同一套 UI 库（如 shadcn/ui + Tailwind），并在提示词里强调风格一致：

请生成一个与系统现有风格一致的卡片组件，使用 Tailwind。

这样跑出来的前端界面，一致性会明显好很多。

6. 数据库迁移与部署

数据库方面，开发早期选用 SQLite 方便本地测试，后期切换到 MySQL。因为一直坚持 ORM（SQLAlchemy），迁移成本很低：

  • 保持 ORM 层不变；
  • 在 config.py 中调整连接字符串；
  • 让 AI 生成迁移脚本，例如：「请帮我生成从 SQLite 迁移到 MySQL 的 Alembic 脚本。」

部署环节同样可以交给 AI 帮忙生成 Docker 配置。典型结构：

Dockerfile (backend)
Dockerfile (frontend)
docker-compose.yml
.env

提示词范例：

请生成一个 docker-compose 文件，启动 FastAPI（端口 8000）与 React 前端（端口 3000），并连接 MySQL 容器。

AI 能自动生成带网络桥接和 volume 映射的完整配置，docker-compose up -d 即可跑起来。

7. 用 AI 做 code review

开发后期，我们让 AI 直接参与代码审查：

请帮我审查以下 FastAPI 路由是否存在安全风险或风格不一致。

实测 AI 能发现重复逻辑、异常未捕获、SQL 注入风险等常见问题，相当于多了一位不睡觉的结对审查者。

二、技巧清单

把上面的实践沉淀成一张可以直接照做的清单：

  • [ ] 功能拆分：把需求拆成「接口结构 → 数据模型 → 前端组件 → 联调日志」的小任务，逐个验证；
  • [ ] 提示词模板：角色 + 目标 + 要求 + 上下文 + 输入输出样例；
  • [ ] 分层先行：MVC 结构（models/、controllers/、routes/、schemas/）先让 AI 生成骨架；
  • [ ] 规范固化：把团队规范沉淀成项目级提示模板/规则（PEP8、统一日志、类型注解、接口返回格式、固定文件结构），避免每次重复描述；
  • [ ] 日志优先：所有 AI 生成文件统一引入 logging，禁用 print 调试；
  • [ ] 前端一致性：固定 UI 库（shadcn/ui + Tailwind），提示词里带「与现有风格一致」；
  • [ ] 数据库迁移：坚持 ORM，切换数据库只改连接串，迁移脚本交给 AI（Alembic）；
  • [ ] 部署配置：Dockerfile / docker-compose 直接让 AI 生成；
  • [ ] Code review：提交前让 AI 走查一遍安全风险与风格问题。

三、避坑点

  • 一次给一个大需求：AI 输出会失控、难以调试。要小步提交、逐阶段验证，每个任务可独立验证；
  • 不给上下文：AI 生成代码容易风格漂移。先给项目架构和现有文件结构，再让它写代码；
  • 不统一规范：每个文件的命名、日志、返回格式各写各的。把规范写进提示模板/项目规则，一次说清；
  • 用 print 调试：AI 生成的模块一多，根本定位不了问题。统一走 logging，带时间与级别；
  • 忽略迁移脚本：从 SQLite 切 MySQL 时容易踩坑。坚持 ORM + Alembic，只改连接字符串；
  • 直接信任 AI 输出：生成完不等于质量过关。让 AI 再做一轮 code review，重点查安全风险与重复逻辑。

四、总结与展望

这次项目让我们确信：AI 编程的关键不在于「写代码」，而在于「写提示」。只要把功能拆解清楚、规范定义清晰，AI 就能大幅降低重复劳动，成为优秀的结对编程伙伴，帮你快速走完从架构设计 → 代码实现 → 部署上线的全流程。

后续还可以继续探索的方向：

  • 让 AI 自动生成接口文档（Swagger + Markdown）；
  • 自动生成单元测试；
  • CI/CD 与 AI 辅助部署联动。

📌 相关阅读