这次我们来看一个用 AI 搭档开发 DNS 监控面板的实战项目。这不是一个现成的工具而是一个完整的开发记录重点在于如何利用 AI 编程助手如 Cursor、GitHub Copilot从零开始构建一个能用的系统并解决过程中遇到的各种“翻车”问题。对于想学习 AI 辅助编程、提升全栈开发效率或者需要搭建一个轻量级 DNS 健康状态看板的开发者来说这个记录提供了非常具体的路径和避坑指南。项目的核心目标是开发一个能够定时探测指定 DNS 服务器如8.8.8.8,114.114.114.114的响应状态、解析延迟和可用性的 Web 监控面板。整个过程涉及后端探测服务、前端数据展示、数据库存储以及最终的部署上线。最值得关注的点在于如何将 AI 作为“编程搭档”高效地生成代码、调试错误并优化架构而不是仅仅把它当作一个搜索引擎。本文将带你复盘从构思到上线的关键步骤环境与工具选型、AI 提示词工程、核心功能模块DNS 探测、数据存储、API 接口、前端图表的开发、遇到的典型“翻车”场景及其解决方案以及最终的部署和优化建议。如果你关心如何将 AI 真正融入开发生命周期而不仅仅是写几句注释那么这篇文章值得你仔细阅读。1. 核心能力速览能力项说明项目类型全栈 Web 应用后端服务 前端面板核心功能多 DNS 服务器定时探测、响应延迟与可用性监控、历史数据图表展示、异常状态告警基础技术栈后端: Python (Flask/FastAPI), 数据库 (SQLite/PostgreSQL)前端: Vue.js/React ECharts/Ant Design ChartsAI 工具: Cursor, GitHub Copilot, Claude硬件门槛极低。本地开发无需特殊 GPU云服务器最低 1C1G 即可运行。部署方式Docker 容器化部署或直接使用 Python 环境运行。是否支持 API是。提供查询探测结果、手动触发探测等 RESTful API。是否支持批量任务是。核心即定时批量探测任务可配置探测目标列表和频率。适合场景个人或团队内部网络监控、DNS 服务商质量对比、AI 辅助编程学习案例。2. 适用场景与使用边界这个项目适合以下几类开发者或运维人员全栈开发学习者想通过一个完整项目练习前后端协同、数据库设计和 API 开发。运维或 SRE 工程师需要一个小巧、可自定义的 internal tool 来监控核心 DNS 或网络服务的健康状况。对 AI 编程感兴趣的技术人员希望深入了解如何高效使用 Cursor、Copilot 等工具提升从需求到代码的转化效率。中小团队需要轻量级监控方案不希望引入 Zabbix、Prometheus 等重型系统的复杂性和资源消耗。使用边界与注意事项非企业级监控该项目定位为轻量级监控工具不具备分布式、高可用、海量数据存储等企业级特性。对于生产环境核心业务监控建议采用更成熟的方案。探测频率与网络影响高频探测如每秒一次可能会对目标 DNS 服务器造成不必要的压力也可能被对方视为恶意行为。请合理设置探测间隔如每分钟或每5分钟一次。数据准确性探测结果受本地网络环境、服务器负载等因素影响数据仅供参考不能替代专业的网络诊断工具。安全与权限部署时请注意 API 接口的访问控制避免暴露到公网导致未授权访问或成为攻击跳板。合规性监控的 DNS 服务器应为自有或已获得授权的服务器避免对公共 DNS 进行滥用性测试。3. 环境准备与前置条件在开始让 AI 搭档写代码之前我们需要先搭建好基础环境。1. 开发环境操作系统Windows 10/11, macOS, 或 Linux (Ubuntu 20.04)。本文以 macOS/Linux 环境命令为例。Python版本 3.8 或以上。这是后端服务的主要语言。Node.js版本 16 或以上。用于构建前端项目如果前端选择 Vue/React。代码编辑器强烈推荐 Visual Studio Code并安装好 Cursor 或 GitHub Copilot 插件。这是我们的“AI 搭档”主战场。Git用于版本控制。2. 工具与账号AI 编程工具确保 Cursor 或 GitHub Copilot 已正确安装并登录。准备好一个清晰的需求描述即你的“提示词”。数据库选择 SQLite简单无需安装或 PostgreSQL更稳定适合生产。对于初学者从 SQLite 开始。包管理Python 的pip Node.js 的npm或yarn。3. 网络与权限确保开发机可以正常访问互联网并能对目标 DNS 服务器如8.8.8.8执行ping和nslookup/dig命令。如果计划部署到云服务器需要准备好服务器 SSH 访问权限和域名可选。4. 项目初始化与 AI 提示词工程项目的起点不是直接写代码而是给 AI 一个清晰、结构化的任务描述。1. 创建项目骨架首先手动或在 AI 帮助下创建基本的项目目录结构。这是一个好的开始mkdir dns-monitor-panel cd dns-monitor-panel mkdir backend frontend touch backend/requirements.txt backend/app.py backend/dns_prober.py backend/models.py backend/config.py touch frontend/package.json frontend/README.md2. 编写核心“需求提示词”打开 Cursor在项目根目录或backend目录下新建一个TODO.md或PROJECT_BRIEF.md文件向 AI 清晰地描述项目# DNS 监控面板项目需求 ## 目标 构建一个Web监控面板用于监控多个公共DNS服务器的可用性和响应速度。 ## 功能需求 1. **后端服务 (Python Flask/FastAPI)** * 定时任务每5分钟探测一次预设的DNS服务器列表例如[8.8.8.8, 114.114.114.114, 1.1.1.1]。 * 探测内容解析一个固定域名如 www.baidu.com记录解析是否成功、解析耗时毫秒。 * 数据存储将每次探测结果时间戳、DNS服务器IP、状态、延迟存入数据库SQLite。 * RESTful API - GET /api/dns/servers: 返回监控的DNS服务器列表。 - GET /api/dns/status: 返回所有服务器的最新状态。 - GET /api/dns/history?server_ipiphours24: 返回指定服务器最近N小时的历史数据。 - POST /api/dns/probe-now: 手动触发一次立即探测。 2. **前端面板 (Vue.js Element Plus ECharts)** * 仪表盘以卡片形式展示每个DNS服务器的当前状态在线/离线、平均延迟、最近一次检查时间。 * 历史图表使用折线图展示单个服务器在选定时间段内的延迟变化趋势。 * 状态日志表格展示最近的探测事件包括时间、服务器、状态、延迟。 3. **部署** * 使用Docker Compose将后端、前端和数据库容器化。 * 提供一键启动脚本。 ## 技术栈偏好 - 后端FastAPI (优先) 或 Flask - 数据库SQLite (开发) / PostgreSQL (生产) - 前端Vue 3 Vite Element Plus ECharts - 任务调度APScheduler - DNS解析dnspython 库将这个文件作为上下文提供给 AI在 Cursor 中可以通过引用或直接打开该文件聊天。接下来你就可以开始让 AI 生成各个模块的代码了。5. 核心模块开发与“翻车”实录这是与 AI 搭档编程的核心环节也是“翻车”高发区。我们将分模块进行并记录典型问题。5.1 翻车点一DNS 探测模块的准确性与超时目标编写dns_prober.py 实现可靠、可配置的 DNS 探测。AI 生成的初始代码可能类似这样# AI 初始版本可能过于简单 import dns.resolver import time def probe_dns(server_ip, domainwww.example.com): resolver dns.resolver.Resolver() resolver.nameservers [server_ip] start time.time() try: answers resolver.resolve(domain) end time.time() return True, (end - start) * 1000 # 成功返回延迟(ms) except Exception as e: return False, None # 失败翻车与优化超时控制缺失如果 DNS 服务器无响应上述代码会卡住很久。必须设置超时。解析异常笼统Exception太宽泛无法区分是网络超时、服务器无响应还是域名不存在。缺乏重试机制单次探测可能因网络抖动失败。TCP/UDP 协议默认 UDP 可能被屏蔽有时需要尝试 TCP。优化后的代码示例# backend/dns_prober.py import dns.resolver import dns.exception import time from typing import Tuple, Optional def probe_dns(server_ip: str, domain: str www.baidu.com, timeout: int 3) - Tuple[bool, Optional[float]]: 探测指定DNS服务器的解析能力和延迟。 Args: server_ip: DNS服务器IP地址 domain: 要解析的测试域名 timeout: 超时时间秒 Returns: (success, latency_ms): 成功与否以及延迟毫秒失败时延迟为None resolver dns.resolver.Resolver() resolver.nameservers [server_ip] resolver.lifetime timeout # 总超时 resolver.timeout timeout # 每次请求超时 start_time time.perf_counter() try: # 尝试解析A记录 answers resolver.resolve(domain, A) end_time time.perf_counter() latency_ms (end_time - start_time) * 1000 # 简单验证是否有答案 if answers and len(answers) 0: return True, round(latency_ms, 2) else: return False, None except (dns.resolver.NXDOMAIN, dns.resolver.NoAnswer): # 域名不存在或无答案但服务器有响应可视为成功但记录特殊状态 end_time time.perf_counter() latency_ms (end_time - start_time) * 1000 return True, round(latency_ms, 2) # 或者定义另一种状态 except (dns.resolver.Timeout, dns.exception.Timeout): # 超时 return False, None except Exception as e: # 其他异常如网络不可达、拒绝连接等 # 可以在这里记录更详细的日志 return False, None # 可以添加一个带重试的封装函数 def probe_dns_with_retry(server_ip: str, domain: str www.baidu.com, retries: int 2) - Tuple[bool, Optional[float]]: for i in range(retries 1): success, latency probe_dns(server_ip, domain) if success: return True, latency if i retries: time.sleep(0.5) # 短暂等待后重试 return False, None与 AI 的协作将初始代码和错误场景如超时描述给 AI让它帮你添加try-except块、设置resolver.lifetime和resolver.timeout并优化返回结果的结构。5.2 翻车点二数据库模型与定时任务集成目标设计models.py定义数据表并在app.py中集成 APScheduler 定时任务。AI 可能生成的数据库模型# backend/models.py (SQLAlchemy示例) from sqlalchemy import create_engine, Column, Integer, String, Float, DateTime from sqlalchemy.ext.declarative import declarative_base from sqlalchemy.sql import func import datetime Base declarative_base() class DnsProbeRecord(Base): __tablename__ dns_probe_records id Column(Integer, primary_keyTrue, autoincrementTrue) server_ip Column(String(15), nullableFalse, indexTrue) # 增加索引便于查询 status Column(String(10), nullableFalse) # success, failure latency_ms Column(Float, nullableTrue) # 成功时有值 created_at Column(DateTime(timezoneTrue), server_defaultfunc.now(), indexTrue) # 记录时间并加索引翻车与优化表结构设计status字段用字符串存储可能效率较低可考虑用布尔值is_success。server_ip长度 15 对 IPv4 足够但对 IPv6 不够可改用String(45)。定时任务启动时机在 Web 框架如 Flask中直接在模块层面启动 APScheduler 可能会导致在开发服务器如 Flask debug reloader中启动多个调度器实例。任务持久化APScheduler 默认任务存储在内存中进程重启后任务会丢失。对于生产环境需要配置作业存储如 SQLAlchemyJobStore。优化后的定时任务初始化示例Flask 上下文内# backend/app.py (部分代码) from flask import Flask from apscheduler.schedulers.background import BackgroundScheduler from apscheduler.jobstores.sqlalchemy import SQLAlchemyJobStore import atexit # ... 其他导入和配置 ... def create_app(): app Flask(__name__) # ... 数据库等配置 ... # 配置并启动调度器确保只启动一次 if not hasattr(app, scheduler): jobstores { default: SQLAlchemyJobStore(urlapp.config[SQLALCHEMY_DATABASE_URI]) } scheduler BackgroundScheduler(jobstoresjobstores) scheduler.add_job(funcprobe_all_servers_job, triggerinterval, minutes5, iddns_probe_job, replace_existingTrue) # 仅在非调试模式或主进程中启动 if not app.debug or os.environ.get(WERKZEUG_RUN_MAIN) true: scheduler.start() # 优雅关闭 atexit.register(lambda: scheduler.shutdown()) app.scheduler scheduler # ... 注册蓝图、路由等 ... return app与 AI 的协作向 AI 描述“如何在 Flask 应用工厂模式中安全地初始化 APScheduler并避免重复启动”让它生成符合上下文的代码。同时可以要求 AI 为DnsProbeRecord模型生成对应的 Pydantic 模型用于 API 请求/响应验证。5.3 翻车点三API 接口设计与前端联调目标创建清晰、实用的 RESTful API并让前端能够顺利调用。AI 生成的 FastAPI 路由可能如下# backend/api/endpoints.py (FastAPI 示例) from fastapi import APIRouter, Depends from sqlalchemy.orm import Session from typing import List from .. import models, schemas, crud from ..database import get_db router APIRouter(prefix/api/dns, tags[dns]) router.get(/servers, response_modelList[schemas.DnsServer]) def get_servers(db: Session Depends(get_db)): 获取监控的DNS服务器列表可从数据库或配置读取 # 这里可以从配置或一个专门的‘servers’表读取 servers [{ip: 8.8.8.8, name: Google DNS}, ...] return servers router.get(/status, response_modelList[schemas.DnsStatus]) def get_latest_status(db: Session Depends(get_db)): 获取所有服务器的最新状态 # 需要编写一个复杂的SQL查询或使用crud函数获取每个server_ip的最新一条记录 status_list crud.get_latest_status_for_all_servers(db) return status_list router.get(/history, response_modelList[schemas.DnsProbeRecord]) def get_history(server_ip: str, hours: int 24, db: Session Depends(get_db)): 获取指定服务器的历史数据 import datetime since datetime.datetime.utcnow() - datetime.timedelta(hourshours) records db.query(models.DnsProbeRecord).filter( models.DnsProbeRecord.server_ip server_ip, models.DnsProbeRecord.created_at since ).order_by(models.DnsProbeRecord.created_at.desc()).all() return records翻车与优化N1 查询问题get_latest_status如果对每个服务器都单独查询一次最新记录效率极低。需要优化为单次查询。时间处理数据库中使用 UTC 时间API 返回时需要前端处理或统一返回时间戳。分页缺失/history接口如果数据量大需要支持分页 (limit/offset或 cursor)。CORS 问题前端单独部署时调用后端 API 会因跨域请求被浏览器阻止。优化方案使用窗口函数优化查询让 AI 帮你写一个使用ROW_NUMBER()的 SQL 查询一次性获取每个服务器的最新记录。统一时间格式在 Pydantic 模型 (schemas.DnsProbeRecord) 中将created_at字段配置为返回 ISO 格式字符串或时间戳。添加分页参数修改/history接口接受limit和offset参数。配置 CORS在 FastAPI/Flask 应用中添加 CORS 中间件。# FastAPI CORS 配置示例 from fastapi.middleware.cors import CORSMiddleware app FastAPI() app.add_middleware( CORSMiddleware, allow_origins[http://localhost:3000], # 前端开发服务器地址 allow_credentialsTrue, allow_methods[*], allow_headers[*], )与 AI 的协作将具体的性能问题如“如何用 SQLAlchemy 一次性查询每个分组的最新记录”抛给 AI让它生成优化后的crud.get_latest_status_for_all_servers函数实现。同时要求 AI 为分页查询生成通用的工具函数。5.4 翻车点四前端图表数据绑定与状态管理目标使用 Vue 3 和 ECharts 绘制延迟趋势折线图。AI 生成的 Vue 组件可能只给出基础架子template div refchartRef stylewidth: 600px; height: 400px;/div /template script setup import { onMounted, ref } from vue; import * as echarts from echarts; const chartRef ref(null); let chartInstance null; onMounted(() { chartInstance echarts.init(chartRef.value); // ... 需要在这里获取数据并设置选项 ... }); /script翻车与优化数据获取与响应式图表数据需要从后端 API 异步获取并响应式地更新图表。图表自适应窗口大小改变时图表需要重绘 (resize)。代码组织图表配置选项 (option) 可能很复杂直接写在setup中不利于维护。错误处理API 请求失败时需要有用户提示。优化后的组件示例template div el-alert v-iferror :titleerror typeerror show-icon closeerror / div refchartRef stylewidth: 100%; height: 400px;/div el-select v-modelselectedServer placeholder选择DNS服务器 changefetchHistoryData el-option v-forserver in serverList :keyserver.ip :label${server.name} (${server.ip}) :valueserver.ip / /el-select el-select v-modelselectedHours placeholder选择时间范围 changefetchHistoryData stylemargin-left: 10px; el-option v-forh in [6, 12, 24, 48, 72] :keyh :label最近${h}小时 :valueh / /el-select /div /template script setup import { onMounted, onUnmounted, ref, nextTick } from vue; import * as echarts from echarts; import { getDnsHistory } from /api/dns; // 假设封装好的API函数 import { getDnsServers } from /api/dns; const chartRef ref(null); const chartInstance ref(null); const historyData ref([]); const serverList ref([]); const selectedServer ref(8.8.8.8); const selectedHours ref(24); const error ref(); const loading ref(false); // 获取服务器列表 const fetchServers async () { try { const res await getDnsServers(); serverList.value res.data; if (serverList.value.length 0 !selectedServer.value) { selectedServer.value serverList.value[0].ip; } } catch (err) { error.value 获取服务器列表失败: ${err.message}; } }; // 获取历史数据并渲染图表 const fetchHistoryData async () { if (!selectedServer.value) return; loading.value true; try { const res await getDnsHistory(selectedServer.value, selectedHours.value); historyData.value res.data; renderChart(); } catch (err) { error.value 获取历史数据失败: ${err.message}; } finally { loading.value false; } }; // 渲染ECharts图表 const renderChart () { if (!chartInstance.value) { chartInstance.value echarts.init(chartRef.value); } const timestamps historyData.value.map(d new Date(d.created_at).toLocaleTimeString()); const latencies historyData.value.map(d d.latency_ms); const option { title: { text: ${selectedServer.value} 延迟趋势, left: center }, tooltip: { trigger: axis }, xAxis: { type: category, data: timestamps, name: 时间 }, yAxis: { type: value, name: 延迟 (ms) }, series: [{ data: latencies, type: line, smooth: true, markLine: { data: [{ type: average, name: 平均值 }] } }], grid: { left: 3%, right: 4%, bottom: 10%, containLabel: true } }; chartInstance.value.setOption(option); }; // 处理窗口大小变化 const handleResize () { chartInstance.value?.resize(); }; onMounted(async () { await fetchServers(); await fetchHistoryData(); window.addEventListener(resize, handleResize); }); onUnmounted(() { window.removeEventListener(resize, handleResize); chartInstance.value?.dispose(); }); /script与 AI 的协作将粗糙的组件代码和具体需求“需要下拉框选择服务器和时间范围数据变化后自动更新图表并且要处理窗口缩放”告诉 AI让它帮你整合 Element Plus 组件、编写fetchHistoryData函数和完整的renderChart逻辑。6. 部署上线从开发机到服务器开发完成后我们需要将应用部署到服务器使其能够 7x24 小时运行。1. Docker 容器化这是最推荐的方式。让 AI 帮你编写Dockerfile和docker-compose.yml。后端 Dockerfile 示例# backend/Dockerfile FROM python:3.10-slim WORKDIR /app COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt -i https://pypi.tuna.tsinghua.edu.cn/simple COPY . . CMD [uvicorn, main:app, --host, 0.0.0.0, --port, 8000]前端 Dockerfile 示例 (基于 Nginx)# frontend/Dockerfile FROM node:18-alpine as build WORKDIR /app COPY package*.json ./ RUN npm install COPY . . RUN npm run build FROM nginx:alpine COPY --frombuild /app/dist /usr/share/nginx/html COPY nginx.conf /etc/nginx/conf.d/default.conf EXPOSE 80docker-compose.yml 示例# docker-compose.yml version: 3.8 services: postgres: image: postgres:15-alpine environment: POSTGRES_DB: dnsmonitor POSTGRES_USER: user POSTGRES_PASSWORD: your_secure_password volumes: - postgres_data:/var/lib/postgresql/data restart: unless-stopped backend: build: ./backend ports: - 8000:8000 environment: DATABASE_URL: postgresql://user:your_secure_passwordpostgres:5432/dnsmonitor DNS_SERVERS: 8.8.8.8,114.114.114.114,1.1.1.1 depends_on: - postgres restart: unless-stopped frontend: build: ./frontend ports: - 80:80 depends_on: - backend restart: unless-stopped volumes: postgres_data:2. 服务器部署与持续运行将代码上传到服务器如通过 Git。运行docker-compose up -d启动所有服务。使用docker-compose logs -f查看日志排查启动问题。配置 Nginx 反向代理如果需要域名和 HTTPS。使用crontab或 systemd 确保 Docker Compose 在服务器重启后自动运行。翻车点环境变量配置错误、数据库连接失败、端口冲突、前端构建后 API 请求地址不对需要配置为后端服务地址。务必在服务器上先测试docker-compose up看日志再后台运行。7. 性能优化与监控增强基础功能跑通后可以考虑以下优化数据库索引优化确保server_ip和created_at字段上有索引大幅提升历史查询速度。探测任务异步化使用 Celery Redis/RabbitMQ 将探测任务从 Web 主线程中剥离避免阻塞 API 响应。前端数据缓存对于历史数据前端可以加入本地缓存如localStorage减少重复请求。简单告警在后端定时任务中加入逻辑判断如果某个 DNS 服务器连续失败 N 次或平均延迟超过阈值则发送邮件或 Webhook 通知如集成钉钉、飞书、企业微信机器人。健康检查端点为后端服务添加/health端点方便容器编排工具如 Kubernetes或监控系统检查服务状态。8. 常见问题与排查方法问题现象可能原因排查方式解决方案后端服务启动失败1. 端口被占用2. Python 依赖缺失或版本冲突3. 数据库连接字符串错误1.netstat -tlnp | grep :80002. 查看启动错误日志3. 检查DATABASE_URL环境变量1. 更换端口或杀死占用进程2. 重建虚拟环境严格按requirements.txt安装3. 校正连接字符串前端页面空白或 JS 错误1. 前端资源未正确构建2. API 请求地址 (baseURL) 配置错误3. 后端 CORS 未配置1. 浏览器开发者工具查看 Console 和 Network 标签2. 检查前端构建命令和nginx.conf3. 确认后端 CORS 中间件已启用且允许前端源1. 重新npm run build2. 在前端配置文件中正确设置后端 API 地址3. 调整后端 CORS 配置定时任务不执行1. APScheduler 未正确启动2. 时区问题导致任务时间错乱3. 在开发服务器 reloader 下重复启动1. 查看应用日志是否有调度器启动信息2. 检查服务器和代码中的时区设置3. 使用app.debug和WERKZEUG_RUN_MAIN判断主进程1. 确保scheduler.start()被调用2. 统一使用 UTC 时间3. 采用“应用工厂模式”并添加启动保护DNS 探测全部超时1. 服务器本身网络出站被限制2. 目标 DNS 端口 (53) 被防火墙屏蔽3.dnspython解析库异常1. 在服务器上手动执行nslookup www.baidu.com 8.8.8.82. 检查服务器安全组/防火墙规则3. 尝试使用subprocess调用系统dig命令测试1. 解决服务器网络问题2. 开放 UDP/TCP 53 端口出站规则3. 降级或重装dnspython数据库查询缓慢1. 缺少索引2. 查询语句未优化如 N1 查询3. 历史数据量过大1. 使用EXPLAIN ANALYZE分析查询计划2. 检查 ORM 生成的 SQL 语句3. 考虑按时间分表或归档旧数据1. 为高频查询条件添加索引2. 优化查询逻辑使用 join 或窗口函数3. 增加数据清理任务9. 最佳实践与使用建议版本控制与提示词存档将TODO.md或PROJECT_BRIEF.md也纳入 Git 管理。这是你与 AI 协作的“需求文档”对于复盘和后续迭代至关重要。分阶段验证不要等全部写完再测试。每完成一个模块如探测函数、单个 API、一个前端组件就立即进行验证。善用 AI 的调试能力将完整的错误信息日志直接复制给 AI如 Cursor 的 Chat 界面它往往能精准定位问题根源甚至给出修复代码。配置外部化将 DNS 服务器列表、探测频率、数据库连接等配置项放在环境变量或配置文件中不要硬编码在代码里。日志记录在关键位置如探测开始/结束、数据库操作、错误捕获添加详细的日志输出便于线上问题排查。安全第一永远不要在代码或配置文件中明文存储密码、密钥。Docker 镜像中不要包含.env或密钥文件。生产环境务必为数据库设置强密码并限制后端服务的网络访问权限。监控你的监控为这个监控面板本身设置一个简单的存活监控如定时访问其/health端点确保它一直在工作。通过这个从“翻车”到“上线”的全过程我们可以看到AI 编程搭档并非万能它无法理解模糊的意图也会写出有缺陷的代码。但它是一个强大的加速器和灵感来源。关键在于开发者要扮演好“架构师”和“质检员”的角色提出清晰、具体的问题并对 AI 生成的代码进行批判性审查、测试和优化。这个 DNS 监控面板项目就是一个完美的练习场它规模适中、涉及全栈能让你在实践中掌握与 AI 协作开发真实可用的软件。