一、案例介绍1.1 概述随着高校学生群体中二手物品交易需求的日益增长，传统的线下交易方式存在信息不对称、交易效率低、缺乏信任保障等问题。校园内大量闲置设备（如暖壶、电水壶、电扇、微波炉、移动硬盘等）在毕业季被丢弃或低价处理，造成了资源浪费。为解决这一痛点，本项目构建了一个面向校园场景的二手设备在线交易平台（AssetMgmt），实现设备信息的高效发布与精准匹配，保障交易流程的安全可靠。本项目采用前后端分离架构，后端基于FastAPI异步框架配合PostgreSQL数据库，前端基于Vue3 + Element Plus + Pinia，生产环境部署在华为云ECS上。全程使用华为云码道（CodeArts）代码智能体辅助开发，采用SDD（Specification-Driven Development）文档驱动方法论，探索云原生部署与AI辅助开发的高效实践路径。项目已经部署在华为云服务器上并且公网可访问（预计运行开放到7月31日结营之前），地址为：http://123.60.220.56/视频演示demo：https://github.com/Erictongtian/huaweishixi/blob/main/视频演示demo.mp4项目源代码仓库：https://github.com/Erictongtian/huaweishixi系统涵盖7大功能模块：功能模块核心功能用户认证注册（邮箱验证码）、登录、Token刷新、密码修改设备管理发布、编辑、上下架、图片上传排序、搜索筛选交易管理下单、确认/拒绝、交付、取消、并发控制评价管理交易完成后星级评价和文字评论分类管理管理员增删改查，展示分类在售设备数量个人中心修改昵称、头像上传、联系方式、密码修改用户管理管理员封禁/解封/注销/重置密码1.2 案例时间本次案例实践周期为2026年7月18日至7月24日，共计7天，分为三个阶段：阶段时间工作内容第一阶段：环境与开发7月18日-20日开发环境搭建，SDD文档生成，项目架构初始化，7大功能模块前后端开发第二阶段：完善与测试7月21日-22日个人中心、用户管理、邮箱验证码注册、UI美化，单元/集成/E2E测试第三阶段：部署与总结7月23日-24日华为云ECS生产部署，调试优化，文档整理1.3 案例流程本次案例遵循SDD文档驱动开发方法论，从需求描述到生产部署形成完整闭环，核心流程如下：需求描述：以自然语言描述项目需求，包括功能范围、业务规则、约束条件等；文档生成：通过CodeArts代码智能体的SDD技能，自动生成spec.md（需求规格）、design/*.md（详细设计）、tasks.md（任务分解）等完整文档体系；代码实现：根据设计文档，在CodeArts辅助下完成数据模型、业务逻辑、API接口、前端页面的开发与迭代；测试验证：编写单元测试、集成测试、E2E联调测试，确保功能正确性和系统稳定性；生产部署：通过CodeArts远程SSH能力，自动化完成华为云ECS环境配置、数据库初始化、服务部署与Nginx配置；验收交付：公网访问验证，代码推送GitHub，文档整理归档。1.4 资源总览本次案例涉及的核心资源如下：资源类别资源项规格/说明开发环境操作系统Windows 11 (x86_64)开发环境Python / Node.js3.13.13 / 22.21.1开发环境PostgreSQL18.4开发环境IDE华为云码道（CodeArts）代码智能体生产环境华为云ECS2vCPU / 2GiB / EulerOS生产环境Python3.12.8（源码编译）生产环境Nginx + systemd反向代理 + 进程守护第三方服务QQ邮箱SMTP验证码邮件发送（SSL:465）第三方服务GitHub代码版本管理第三方服务清华PyPI镜像依赖加速下载二、资源与环境准备2.1 开发环境资源项规格/版本用途说明操作系统Windows 11 (x86_64)本地开发环境Python3.13.13后端开发语言Node.js22.21.1前端运行时与构建工具PostgreSQL18.4本地数据库Git2.52.0版本控制IDE华为云码道（CodeArts）代码智能体AI辅助开发工具2.2 生产环境（华为云ECS）资源项规格/版本用途说明云服务商华为云基础设施提供方实例规格ECS 2vCPU / 2GiB应用服务器操作系统EulerOS (x86_64)服务器操作系统Python3.12.8（源码编译安装）后端运行环境PostgreSQL系统自带版本生产数据库Nginx系统自带版本反向代理 + 静态文件服务进程管理systemd后端服务守护与自动重启2.3 网络与安全配置华为云ECS实例需开放以下安全组端口：端口协议用途80HTTPNginx对外Web服务443HTTPS（预留）SSL加密访问22SSH远程运维管理5432PostgreSQL数据库访问（仅内网）8000HTTPFastAPI后端服务（仅Nginx内部代理）生产环境中PostgreSQL和FastAPI端口不对外暴露，所有外部请求通过Nginx反向代理转发，确保系统安全。2.4 第三方服务服务提供商用途SMTP邮件服务QQ邮箱（SSL:465）发送注册验证码Git仓库GitHub代码版本管理与协作PyPI镜像清华大学开源镜像站Python依赖加速下载三、系统架构设计3.1 总体架构系统采用前后端分离的B/S架构，分为表现层、应用层、数据层三个层次：表现层：Vue3 + Element Plus + Pinia，负责页面渲染、用户交互和前端状态管理；应用层：FastAPI异步框架，提供RESTful API服务，包含认证、业务逻辑、文件上传等模块；数据层：PostgreSQL数据库，存储用户、设备、订单、评价、分类、验证码等核心数据。3.2 技术选型层次技术选型理由后端框架FastAPI原生async/await支持，自动OpenAPI文档生成ORMSQLAlchemy 2.0异步ORM支持，与FastAPI完美配合数据库驱动asyncpg纯Python异步驱动，性能优于psycopg2异步模式数据库PostgreSQL支持部分唯一索引，并发控制方案的关键依赖前端框架Vue3组合式API，更好的代码复用和类型推导UI组件库Element Plus丰富的企业级UI组件状态管理PiniaAPI简洁，TypeScript支持优于Vuex构建工具Vite极速HMR，开发体验优秀3.3 数据模型设计系统核心数据模型包括6个实体，关系如下：User（用户）：1对多→Device、Order、Review；Device（设备）：多对1→Category、User；1对多→Order；Order（订单）：多对1→Device、User（买家）；1对1→Review；Review（评价）：1对1→Order；Category（分类）：1对多→Device；EmailCode（验证码）：独立表，关联email字段。3.4 API接口设计系统遵循RESTful规范，所有接口统一前缀 /api/v1，返回格式为 {code, message, data}。核心接口如下：模块方法路径说明认证POST/api/v1/auth/register注册（含邮箱验证码）认证POST/api/v1/auth/login登录认证POST/api/v1/auth/send-register-code发送验证码设备GET/POST/api/v1/devices设备列表/发布设备GET/PUT/api/v1/devices/{id}设备详情/更新订单POST/api/v1/orders下单订单PUT/api/v1/orders/{id}/confirm确认订单评价POST/api/v1/reviews提交评价分类GET/api/v1/categories分类列表用户GET/PUT/api/v1/users/me当前用户信息/更新3.5 部署架构生产环境部署在华为云ECS实例上，Nginx作为反向代理和静态文件服务器，Uvicorn运行FastAPI应用，systemd负责进程守护：客户端 → Nginx(:80) → FastAPI(:8000) → PostgreSQL(:5432) Nginx将 /api/* 请求代理至后端，/uploads/* 代理至后端静态文件，其余请求返回前端打包后的dist文件。后端通过systemd服务管理，开机自启、崩溃自动重启。四、使用华为云码道（CodeArts）代码智能体辅助开发4.1 开发流程概述本项目全程使用华为云码道（CodeArts）代码智能体作为核心开发工具，采用SDD（Specification-Driven Development）文档驱动开发方法论，从需求规格说明到代码实现、测试验证、生产部署，实现了AI辅助的全流程闭环开发。4.2 需求细化与文档生成在项目启动阶段，通过CodeArts代码智能体的SDD技能，从用户需求描述自动生成了完整的文档体系：首先让ai生成系统设计文档：设计文档产出：之后使用skill优化文档：然后根据系统设计文档生成SDD文档:SDD文档产出：spec.md：需求规格说明书，定义"做什么"（What to Build）；design/01~10.md：10份详细设计文档，涵盖认证、设备、交易、评价、分类、个人中心、数据模型、API接口、前端设计、用户管理等；tasks.md：任务分解文档（v1.2），4大部分24个任务，每个任务有明确的验收标准。CodeArts代码智能体根据自然语言需求描述，自动拆解为EARS格式的需求条目，并生成对应的技术设计文档，极大减少了需求遗漏和设计偏差。4.3 代码生成与迭代在代码实现阶段，CodeArts代码智能体发挥了以下核心作用：（1）模型与Schema自动生成：根据数据模型设计文档，自动生成SQLAlchemy模型类、Pydantic Schema类，包含字段校验、类型注解、关联关系等。（2）业务逻辑实现：根据API接口设计文档，自动生成Service层和API路由代码，包括参数校验、权限检查、异常处理、数据库事务等。（3）前端页面开发：根据前端设计文档，自动生成Vue3组件代码，包括模板结构、响应式数据、API调用、路由配置等。（4）实时调试与修复：在开发过程中遇到的问题（如asyncpg时区问题、MissingGreenlet异常、Element Plus样式覆盖等），CodeArts代码智能体能够快速定位根因并提供修复方案。4.4 测试与调试CodeArts代码智能体在测试环节提供了以下支持：后端单元测试：自动生成Service层测试用例，覆盖核心业务逻辑；后端集成测试：自动生成API端到端测试，覆盖认证、分类、评价、用户等模块；前端单元测试：自动生成工具函数和Store逻辑的测试用例；E2E联调测试：自动生成前后端完整交互流程的验证脚本。CodeArts代码智能体能够根据代码变更自动生成对应的测试用例，并在测试失败时分析错误日志、定位问题代码、提供修复建议，显著提升了测试效率。4.5 部署与运维在部署阶段，CodeArts代码智能体通过paramiko库实现远程SSH连接华为云ECS服务器，自动化完成以下操作：安装PostgreSQL、Nginx、Python 3.12（从源码编译）；配置数据库（创建库、设置密码、pg_hba.conf认证方式调整）；创建Python虚拟环境并安装全部依赖（配置清华镜像源加速）；初始化数据库表结构并导入种子数据；配置systemd服务实现进程守护和开机自启；配置Nginx反向代理（/api/→后端，其余→前端静态文件）；通过SFTP上传前端构建产物。整个部署过程无需手动登录服务器操作，CodeArts代码智能体通过脚本化方式一键完成，大幅降低了部署门槛和出错概率。五、解决方案5.1 用户认证与权限管理采用JWT双Token机制（Access Token + Refresh Token），Access Token有效期1小时，Refresh Token有效期7天。通过FastAPI的Depends依赖注入实现权限校验，区分普通用户和管理员角色。密码使用bcrypt加密存储，登录失败5次自动锁定30分钟。注册流程采用邮箱验证码机制：用户输入邮箱后点击"获取验证码"，后端生成6位随机数字验证码，通过QQ邮箱SMTP服务发送，验证码5分钟内有效，错误5次后自动失效，60秒内不可重复发送。5.2 设备信息管理设备管理支持完整的CRUD操作，设备状态机包含3个状态：on_sale（在售）、off_shelf（已下架）、sold（已售出）。设备发布时支持多图上传，图片可设置封面、拖拽排序。搜索支持关键词模糊匹配、分类筛选、成色筛选、价格范围筛选，结果支持按价格和时间排序。关键约束：设备存在pending或confirmed状态的订单时禁止下架，确保交易安全。分类设备数量仅统计on_sale状态的设备，避免数据误导。5.3 交易流程管理交易流程通过订单状态机驱动，包含5个状态：pending（待确认）→ confirmed（已确认）→ delivered（已交付）或 cancelled（已取消）。卖家确认订单后设备自动标记为sold，拒绝或取消订单后设备恢复on_sale。并发购买问题通过PostgreSQL部分唯一索引解决：在orders表上创建 idx_order_device_active 索引，确保同一设备同一时间只能有一个活跃订单（pending或confirmed状态），从数据库层面保证数据一致性。5.4 邮箱验证码注册注册流程采用"先验证后注册"模式，确保邮箱真实有效。技术实现要点：新建email_codes表存储验证码记录，包含email、code、used、fail_count、expires_at字段；发送验证码前检查：邮箱是否已注册、60秒内是否已发送（防刷）；验证码校验时检查：是否已使用、是否过期、错误次数是否超限（5次）；验证通过后标记used=True，用户is_verified=True，注册即可登录；邮件内容采用HTML模板，包含品牌视觉元素和6位数字验证码。5.5 用户管理模块管理员可对普通用户执行封禁、解封、注销、重置密码操作。关键设计：封禁/注销不可操作自己和其他管理员；注销用户时自动下架其所有在售设备、取消其所有活跃订单；封禁用户无法登录（在dependencies.py和auth_service.py中区分管理员封禁与登录失败临时锁定）；locked_until=None表示管理员封禁（永久），locked_until>now表示临时锁定。六、核心技术难点与解决思路6.1 并发购买竞态条件【问题】 多个用户同时对同一设备下单，可能导致同一设备被多人购买。【分析】 传统方案是在应用层加锁（如Redis分布式锁），但增加了系统复杂度和外部依赖。更优雅的方式是利用数据库的约束机制。【解决】 在PostgreSQL的orders表上创建部分唯一索引：CREATE UNIQUE INDEX idx_order_device_active ON orders(device_id) WHERE status IN ('pending', 'confirmed'); 该索引确保同一设备在pending或confirmed状态下只能有一条订单记录。当并发请求尝试插入第二条订单时，数据库会抛出唯一约束冲突异常，应用层捕获该异常后返回友好提示。这种方案零外部依赖、性能优异、数据一致性由数据库保证。6.2 asyncpg时区与MissingGreenlet问题【问题】 使用asyncpg驱动时，SQLAlchemy的server_default=func.now()会触发MissingGreenlet异常；datetime.now(timezone.utc)返回的带时区时间戳与PostgreSQL的timestamp without time zone字段不兼容。【解决】 将所有模型的默认时间戳从数据库端生成改为Python端生成：移除server_default=func.now()，改用default=_utcnow（Python端函数）；使用datetime.utcnow()替代datetime.now(timezone.utc)，避免时区后缀问题；_utcnow函数返回naive datetime（无时区信息），与PostgreSQL的timestamp字段兼容。6.3 Python 3.9兼容性与服务器Python版本升级【问题】 华为云ECS EulerOS默认Python版本为3.9.9，不支持Python 3.10+的str | None语法。初始尝试添加from __future__ import annotations，但与SQLAlchemy的Mapped类型注解存在冲突。【解决】 从CPython源码编译安装Python 3.12.8，配置清华PyPI镜像源加速依赖安装。编译命令：./configure --enable-optimizations --prefix=/usr/local/python312 && make -j2 && make install 安装后创建虚拟环境、安装项目依赖，彻底解决语法兼容性问题，同时获得Python 3.12的性能提升。6.4 邮箱验证码的防刷与安全【问题】 验证码接口可能被恶意刷量，导致邮件服务被封禁或资源浪费。【解决】 采用多层防护策略：60秒冷却期：同一邮箱60秒内不可重复发送验证码；验证码5分钟过期：过期后自动失效，需重新获取；错误次数限制：同一验证码错误5次后标记为已使用，需重新获取；邮箱唯一性检查：发送验证码前检查邮箱是否已注册；SMTP SSL加密：使用465端口SSL连接，防止邮件内容被窃取。6.5 用户封禁与临时锁定的区分【问题】 系统存在两种"锁定"场景：管理员手动封禁（永久）和登录失败自动锁定（30分钟临时），需要区分处理。【解决】 通过locked_until字段区分：场景locked_until值解锁条件管理员封禁None管理员手动解封登录失败临时锁定具体时间（now+30min）超过锁定时间自动解锁正常状态过去的时间或None（初始）无需解锁6.6 前后端跨域与生产环境代理【问题】 开发环境前端(5173端口)访问后端(8000端口)存在跨域问题；生产环境前端为静态文件，API请求需要正确路由。【解决】 采用不同策略处理：开发环境：Vite配置proxy，将/api和/uploads代理至后端，同时配置CORS中间件；生产环境：Nginx反向代理，/api/→后端8000端口，/uploads/→后端静态文件，其余→前端dist；前端API请求统一使用相对路径（/api/v1/...），无需硬编码后端地址。七、总结与展望本项目成功构建了一个功能完善的校园二手设备交易平台，实现了从需求分析、架构设计、代码开发、测试验证到生产部署的全流程闭环。项目的主要成果和经验总结如下：（1）AI辅助开发效率显著提升：通过华为云码道（CodeArts）代码智能体，从需求文档到可运行代码的转化效率大幅提升。SDD文档驱动方法论确保了需求的完整性和可追溯性，AI自动生成的代码质量和规范性达到了生产级标准。（2）技术架构合理可靠：FastAPI异步框架配合PostgreSQL和Vue3的组合，在2vCPU/2GiB的低配云服务器上运行流畅，证明了架构选型的合理性。（3）安全性设计完善：邮箱验证码注册、JWT双Token认证、并发购买防护、用户封禁机制等多层安全措施，有效保障了系统和用户数据安全。（4）部署运维自动化：通过CodeArts代码智能体的远程SSH能力，实现了从代码推送到生产部署的全自动化流程，降低了运维门槛。未来展望：引入实时消息通知（WebSocket），支持订单状态变更即时推送；增加设备收藏和关注功能，提升用户粘性；接入华为云OBS对象存储，替代本地文件存储方案；添加数据统计和可视化看板，辅助运营决策；支持微信/支付宝模拟支付，完善交易闭环。

1、概述1.1 案例介绍本案例基于华为云码道（CodeArts 代码智能体），通过自然语言需求驱动与多轮迭代优化，快速构建一套完整的济云酒店管理Web应用。系统覆盖房间管理、价格管理、客人管理、房费结算四大核心业务模块，实现从入住登记到在住消费，从退房结算到房态更新的酒店全业务闭环，采用纯前端技术栈实现，数据通过浏览器本地存储持久化，开箱即用。1.2 适用对象企业开发者个人开发者高校学生1.3 案例时间本案例总时长预计90分钟。1.4 案例流程说明：开通华为开发者空间，领取华为云码道代码智能体通用体验权限；梳理酒店业务需求，编写结构化提示词，提交码道生成初始单页应用；运行验证核心功能，针对业务闭环、交互体验进行多轮迭代优化；执行工程化拆分，将单文件重构为模块化多目录架构；完成全功能测试验收与品牌定制适配，交付最终项目成果。1.5 资源总览本案例预计花费139元。体验完成后请及时释放资源，避免产生多余的费用。资源名称规格单价（元）华为云码道（CodeArts）代码智能体专业版139/月2、环境和资源准备2.1 领取华为云码道代码智能体使用权限登录华为开发者空间，进入码道 CodeArts产品页，领取通用体验版权限，开通代码智能体（专业版）服务，获取在线代码生成与迭代能力。2.2 IDE安装与部署参考案例《AI IDE华为云码道（CodeArts）代码智能体安装部署》，完成Windows版华为云码道代码智能体安装部署。打开CodeArts软件，等待初始化，然后开始通过描述需求来生成项目代码。3、构建酒店管理应用3.1 项目需求构建3.1.1 核心需求梳理系统需实现酒店住宿全流程管理，核心包含四大业务模块：1.房间管理：房间信息增删改查、房间状态管理、多条件筛选搜索2.价格管理：基础房价配置、周末价格系数、长住优惠规则、特殊日期定价3.客人管理：客人信息档案管理、历史入住记录查询4.房费结算：自动核算房费、额外消费登记、押金抵扣、账单生成打印3.1.2 编写结构化提示词按照从功能目标到技术路径，从核心模块到优化补充、异常修复的结构编写生成提示词，明确纯前端技术栈、localStorage 持久化、左侧导航管理后台布局等要求，精准描述业务规则与字段定义。详细提示词见下：在HotelManagement文件夹下从零开始生成一套完整的酒店住宿管理Web应用，采用纯前端HTML+CSS+原生JavaScript技术栈，无需后端服务与构建工具，直接在浏览器打开index.html即可运行，所有业务数据通过localStorage持久化保存，刷新页面不丢失；项目定位：面向酒店前台工作人员的办公级管理系统，以信息清晰易识别、长时间操作低疲劳、业务流程全闭环、代码结构工程化为核心原则。请严格按照以下所有要求完整实现：一、项目架构与文件拆分规范采用工程化多目录结构，按职责分层拆分文件，禁止单文件堆砌代码，拆分后功能完整可用。最终目录结构如下：(此处目录结构详见下面的目录结构，略去)JS采用 HotelApp 全局命名空间挂载各模块方法，避免全局变量污染；index.html按依赖顺序正确引入所有文件，基础文件在前、业务文件在后。二、视觉风格规范（浅色商务办公风）不采用暗色主题，采用清爽专业的浅色商务风格，降低前台长时间操作视觉疲劳，强化关键信息辨识度。1. 色彩体系- 主色调：商务蓝 #165DFF，用于主按钮、选中态、重点数据高亮- 页面背景：浅灰色 #F5F7FA；卡片/表格/弹窗底色：纯白色 #FFFFFF- 状态色统一：空闲/成功 #00B42A，已入住/错误 #F53F3F，清洁中/警告 #FF7D00，维修中/禁用 #86909C；状态标签采用浅色背景+深色文字- 文字三级灰度：一级标题/关键数据 #1D2129，二级正文 #4E5969，三级辅助/备注 #86909C- 移除所有玻璃拟态、渐变光晕、深色特效，采用极简扁平化设计，减少视觉干扰2. 组件样式- 左侧导航栏：浅灰底色，选中项蓝色背景+白色文字，hover极浅蓝高亮，图标文字垂直居中- 卡片：统一8px圆角，带柔和阴影，内边距充足- 按钮：主按钮蓝色实心底+白字，次要按钮白底+灰边+深灰字，危险按钮红色底+白字；文字居中，左右内边距均衡- 输入框/下拉框：白底+浅灰边框，聚焦时边框变主色调+淡蓝色外发光- 表格：表头浅灰底色，行高充足，隔行极淡底色区分三、排版与对齐规范针对不同控件、不同字段类型采用差异化对齐，兼顾美观与信息读取效率。1. 表格类- 所有表头文字居中对齐- 文本类字段（房间号、客人姓名、房型、备注）左对齐- 数值类字段（房价、金额、入住天数、押金）右对齐- 状态标签列、操作按钮列居中对齐- 所有单元格内容垂直居中2. 表单类- 表单标签统一放在输入框顶部（顶部对齐），不左置- 输入框内文字左对齐，placeholder浅灰色- 表单底部提交/取消按钮组右对齐- 多列表单栅格布局，字段间距均匀3. 统计卡片/数据看板- 指标标签居上、浅灰色弱化，核心数值放大居中展示，辅助数据居下- 卡片标题左对齐，内容区按数据类型灵活对齐4. 通用规则- 所有按钮文字居中- 弹窗标题左对齐，底部按钮组右对齐- 空状态提示文字+图标整体居中四、核心业务功能模块完整实现酒店住宿全流程闭环，默认初始化8间示例房间与对应价格规则。1. 数据看板- 统计卡片：空闲房间、已入住、清洁中、维修中、今日入住、在住客人、今日收入、本月收入- 快捷操作入口：快速入住、快速退房、房间管理、账单管理- 今日在住房间列表展示2. 房间管理- 房间字段：房间号、楼层、房型（单人间/双人间/豪华间/套房）、床位数、基础日房价、状态、备注- 房间状态：空闲、已入住、清洁中、维修中，支持状态流转；清洁中房间可手动标记为空闲- 支持按房间号搜索、按状态/房型/楼层筛选，支持增删改查- 房间号全局唯一校验，已入住房间不可直接删除3. 价格管理- 基础房价：按房型配置基础日房价、周末价格系数- 长住优惠：可视化表单配置多条「连住天数+折扣比例」规则，无需字符串输入- 特殊日期价格：按日期区间配置特殊房价，支持备注说明- 房费结算时自动匹配规则，按天精准计费4. 客人管理- 客人字段：姓名、身份证号、联系电话、备注- 支持增删改查、关键词搜索，可查看客人历史入住与消费记录5. 快速入住- 支持选择空闲房间，填写客人信息、入住人数、押金、入住/退房日期、备注- 支持选择已有客人档案，一键填充信息，无需重复录入- 入住成功后自动更新房间状态为已入住，生成入住订单6. 快速退房- 选择在住房间自动加载入住信息- 支持添加额外消费，预设早餐、加床、洗衣、迷你吧等快捷选项，也可自定义- 支持半天房费规则（默认12点前退房按半天计费，可手动调整）- 实时预览账单明细，包含房费、消费、押金抵扣、应收总额- 支持选择支付方式（现金/微信/支付宝/银行卡）- 退房成功后房间状态自动变为清洁中，生成结算记录7. 房费结算- 结算记录列表，支持按日期区间筛选- 可查看账单详情，包含每日房费明细、额外消费明细- 支持账单打印功能，打印样式专门优化8. 历史记录- 入住记录、结算记录双标签页切换- 支持查看订单详情、账单详情9. 数据管理- 全量数据JSON导出、导入、清空- 不可逆操作均有二次确认五、交互体验与健壮性要求1. 交互优化- 移除所有原生alert/confirm，统一替换为Toast轻提示（成功/错误/警告三类，3秒自动消失）和自定义确认弹窗- 所有表单实时校验，错误提示显示在输入框下方- 所有模态框支持点击遮罩层关闭、按ESC键关闭，表单弹窗支持回车提交- 所有数据列表支持分页，默认每页10条，可切换10/20/50条/页- 侧边栏支持折叠/展开，桌面端可收起为纯图标模式- 所有提交按钮点击后立即禁用，防止重复提交2. 健壮性要求- 所有数值字段禁止输入负数，入住日期必须早于退房日期- localStorage数据损坏时自动初始化默认数据，杜绝白屏- 所有对象、数组操作前做非空判断，避免undefined类报错- 所有删除、结账等不可逆操作增加二次确认六、最终交付要求1. 直接打开 index.html 即可完整运行，无任何控制台报错、无资源4042. 全业务流程可正常跑通，数据联动正确，状态流转闭环3. 视觉风格、排版对齐严格符合上述规范4. 代码结构清晰，每个文件头部添加职责注释，关键逻辑添加说明注释5. 项目为纯静态，无需任何依赖、构建工具与后端服务3.1.3 提交生成需规划文档码道根据我们提示词的需求描述，创建好项目目录，并生成需求文档、实现方案、编码规划三个文档：3.1.4 审核设计文档3.2 项目代码实现3.2.1 项目结构说明HotelManagement/├── index.html # 主页面入口，仅保留 DOM 结构，无内联 CSS 和 JS├── css/ # 样式文件目录│ ├── base/│ │ ├── reset.css # 全局样式重置、CSS 变量（颜色 / 字号 / 圆角 / 间距 token）│ │ └── common.css # 通用工具类、统一间距规范│ ├── layout/│ │ └── global.css # 整体页面布局、左侧导航栏、右侧主内容区样式│ ├── components/│ │ ├── button.css # 全类型按钮组件样式│ │ ├── form.css # 输入框、下拉框、文本域、校验提示样式│ │ ├── table.css # 表格容器、表头、单元格样式│ │ ├── modal.css # 模态框遮罩、弹窗容器样式│ │ ├── badge.css # 状态标签、统计卡片、标签页样式│ │ └── pagination.css # 分页器组件样式│ └── pages/│ ├── dashboard.css # 数据看板页面专属样式│ ├── rooms.css # 房间管理页面专属样式│ ├── pricing.css # 价格管理页面专属样式│ ├── guests.css # 客人管理页面专属样式│ ├── settlement.css # 房费结算页面专属样式│ ├── checkin.css # 快速入住页面专属样式│ ├── checkout.css # 快速退房页面专属样式│ ├── history.css # 历史记录页面专属样式│ └── settings.css # 数据管理页面专属样式└── js/ # 脚本文件目录├── utils/│ ├── storage.js # localStorage 读写封装、数据初始化、异常兜底│ ├── validator.js # 表单格式校验工具（身份证 / 手机号 / 金额 / 日期）│ ├── date.js # 日期计算、入住天数核算、日期格式化│ └── ui.js # Toast 提示、确认弹窗、加载状态通用方法├── modules/│ ├── roomModule.js # 房间管理增删改查、筛选、状态流转│ ├── guestModule.js # 客人档案管理、历史记录、增删改查│ ├── priceModule.js # 基础价格、特殊价格、优惠规则、房费核算│ ├── checkinModule.js # 入住登记、订单生成、状态联动│ ├── checkoutModule.js # 退房核算、额外消费、结算提交│ ├── settlementModule.js # 结算记录、账单详情、打印│ ├── dashboardModule.js # 数据看板统计、指标计算、渲染│ ├── historyModule.js # 入住 / 结算历史记录查询、详情│ └── settingsModule.js # 数据导入、导出、清空└── app.js # 项目主入口、导航路由、全局事件绑定、模块注册3.2.2 关键源码讲解本项目代码已开源至cid:link_0，欢迎访问。3.2.2.1 storage.js 本地持久化工具（核心数据层）统一封装浏览器 localStorage 读写、异常捕获、系统初始化逻辑，是整个项目的数据底层支撑。所有房间、客人、订单、价格数据全部通过该文件存取，数据损坏时自动加载默认 8 间客房示例数据，避免页面白屏。统一存储前缀隔离项目数据，防止和其他网站缓存冲突；读写失败捕获异常并控制台打印错误；系统首次打开自动初始化全套基础业务数据；提供单条删除、全量清空、全量读取标准化接口，所有业务模块共用这套存储方法。3.2.2.2 calculator.js 房费计算引擎（业务核心算法）整套系统计费核心，自动按入住日期逐日核算房价，叠加基础价、周末溢价、节假日特殊价、长住折扣，自动计算应收总额、押金抵扣。自动计算入住自然天数，区分跨月 / 跨年日期；自动识别周六周日叠加价格系数；匹配自定义节假日特殊房价；按最长连住规则自动应用折扣；支持半天退房计费、额外消费累加、押金抵扣核算。本文件完全隔离复杂数学计算逻辑，页面交互层只需要传入房间和日期，直接拿到最终账单金额，避免前台手动算价出错。3.2.2.3 roomModule.js 房间业务模块（房态流转核心）封装房间增删改查、多条件筛选、房态状态合法流转校验，管控房间全生命周期。新增房间自动校验房间号唯一，重复直接拦截；限制非法房态切换：已入住房间不能直接改为维修、清洁房只能切空闲 / 维修；删除房间前置校验：正在入住的房间禁止删除；支持按楼层、房型、房号、状态多维度筛选房间列表。能够做到约束酒店真实业务规则，杜绝不符合运营逻辑的操作，保证房态数据自洽。3.2.2.4 app.js 项目入口 & 全局 UI 调度（页面中枢）系统唯一入口 JS，控制侧边栏导航切换、页面显示隐藏、全局 Toast 弹窗、页面自动渲染、时钟展示。页面 DOM 加载完成自动初始化存储、加载首页看板数据；侧边栏点击切换对应业务页面，自动高亮当前菜单；封装统一轻提示 Toast，替代原生 alert，风格和系统 UI 统一；封装通用确认弹窗，所有删除、清空高危操作复用；各页面渲染函数统一调度，看板、房间、客人列表自动刷新。主要负责串联所有业务模块，统一全局交互，分离页面渲染和底层数据逻辑。3.2.2.5 index.html 项目主入口页面（整体骨架）项目唯一 HTML 载体，定义整套系统页面 DOM 结构、导航菜单、9 大业务页面容器、弹窗模板、所有表单结构，统一引入拆分后的 CSS/JS 资源文件。采用侧边导航 + 右侧内容经典后台布局；分页面容器：看板、房间、客人、入住、退房、价格、结算、历史、数据管理；内置新增房间、新增客人、账单弹窗 DOM 模板；规范资源引入顺序：先基础 CSS、组件 CSS，再工具 JS、业务模块 JS，最后入口 app.js；内置打印专用页面布局，账单打印自动隐藏操作按钮。3.2.3 运行调试本项目基于原生HTML、CSS、JavaScript 开发，不用部署服务器，双击打开即可使用，所有业务数据都保存在浏览器本地。3.2.3.1 数据看板模块打开系统首先看到的是数据看板，这里汇总了酒店最核心的运营指标，前台上班第一眼就能掌握整体房态和营收情况。可以看到当前的空闲房、在住房、清洁房、维修房数量，还有今日入住数、在住客人数，以及今日和本月的营收统计。下方是今日在住客人列表，能快速看到每个房间的客人姓名和入住退房时间。左侧导航栏支持折叠收起，给内容区留出更多空间，设计上也兼顾了不同使用习惯：3.2.3.2 房间管理模块房间状态用四种颜色区分：绿色空闲、红色已入住、橙色清洁中、灰色维修中，辨识度很高，前台扫一眼就能掌握房态。支持新增和编辑房间信息，房间号会自动校验唯一性，不会重复；房态流转是受控的，比如已入住的房间不能直接删除，也不能随意改状态，必须按业务流程来，避免误操作。清洁完成的房间可以手动标记为空闲，回到可用状态；表格的排版也做了优化：表头居中对齐，房间号、房型这类文本左对齐，房价这类数值右对齐，操作按钮居中，符合财务类数据的阅读习惯，核对金额的时候更直观： 3.2.3.3 价格管理模块价格管理模块用来配置酒店的计费规则，支持多层定价逻辑。首先是各房型的基础日房价，然后可以设置周末价格上浮系数，比如周末房价是平时的 1.2 倍；所有规则配置好之后，退房结算时系统会自动算价，不用前台手动核算，既提高效率也避免算错账：3.2.3.4 客人管理模块客人管理模块用来维护客人档案；同时每个客人都有对应的历史入住和消费记录，方便酒店了解客史，提供更好的服务。新增客人时会自动校验身份证和手机号格式，填错了会实时提示： 3.2.3.5 快速入住模块快速入住页面是前台最高频使用的功能。首先选择空闲房间，这里只显示空闲状态的房间，已入住的不会出现，避免选错。填好客人信息、入住退房日期、押金和备注，点击确认入住就完成了。系统会自动生成入住订单，同时把房间状态改成已入住，整个流程联动起来，不用手动去改房态：切回房间管理看一下，302 已经变成红色的已入住状态，数据是实时同步的:3.2.3.6 快速退房 + 结算客人退房的时候，我们用快速退房功能。选择在住房间，系统会自动带出客人信息和入住时长，不用重复填写；右边是实时账单预览，房费是系统自动算的，已经叠加了周末价这些规则，加上额外消费，再抵扣押金，最后就是客人实际要付的金额，每一笔都清清楚楚；选择支付方式，确认退房就完成结算了。退房之后房间自动变成清洁中状态，等待保洁打扫完成后再放回空闲房态，形成完整的业务闭环：3.2.3.7 数据管理模块最后是数据管理模块，支持把所有业务数据导出成 JSON 文件备份，换电脑或者清缓存之后，可以再导入恢复，不用担心数据丢失。也可以一键清空所有数据，重置系统：整体来看，这套系统覆盖了酒店前台的全部核心业务，操作简单直观，不用复杂培训就能上手。如需要进一步了解功能，参见3.2.2节的仓库中视频。4、释放资源无云服务实例需要删除释放；若不再需要本济酒店管理系统项目，直接删除本地HotelManagement完整项目文件夹，即可释放本地磁盘存储空间；关闭华为开发者空间网页标签页，退出登录账号即可；如需彻底清空对话历史，进入码道对话页面删除本次项目全部提示词与代码对话记录。5、扩展资料说明想了解更多原生HTML/CSS/JS静态开发、本地存储相关技术可查阅 MDN 官方文档。

基于华为云码道代码智能体的运动场馆管理系统1、案例介绍1.1 案例介绍校园运动场馆资源分散、借用流程混乱、时间冲突频发？本案例基于 Vue3 + Express 全栈架构，借助华为云码道代码智能体，从零到一构建一套运动场馆智能管理系统。系统支持课表固定占用与临时借用双模式，提供基于时间段的可用场馆智能推荐，实现场馆资源的高效调度与零冲突管理。1.2 适用对象高校学生个人开发者企业开发者1.3 案例时间本案例总时长预计60分钟。1.4 案例流程┌──────────────┐ ┌──────────────────┐ ┌──────────────────┐ ┌──────────────┐ │ 1 本地环 │───▶│ 2.CodeArts智能体 │───▶│ 3.依赖安装与 │───▶│ 4.运行调试 │ │ 境准备 │ │ 生成代码 │ │ 环境适配 │ │ 与验证 │ └──────────────┘ └──────────────────┘ └──────────────────┘ └──────────────┘说明：准备本地开发环境，安装 Node.js，创建项目目录；在 CodeArts 代码智能体中输入需求，智能体自动生成前后端完整代码；安装项目依赖，遇到原生模块编译问题时由智能体自动适配解决；启动前后端服务，验证系统核心功能。1.5 资源总览本案例预计花费0元。资源名称规格单价（元）华为云码道代码智能体通用体验版免费Node.jsv20+免费2、环境和资源准备2.1 安装 Node.js本案例前端和后端均基于 Node.js 运行，需提前安装 Node.js v20 及以上版本。下载地址：https://nodejs.org/安装完成后，在终端验证：node --version npm --version 2.2 开通华为云码道代码智能体登录华为云控制台，搜索"CodeArts"，进入 CodeArts 服务页面，开通代码智能体通用体验版（免费）。开通后即可在 CodeArts IDE 中使用 AI 辅助编程功能。3、构建运动场馆管理系统3.1 创建项目目录在终端中创建项目目录：mkdir yundongchangguan cd yundongchangguan3.2 使用 CodeArts 代码智能体生成项目代码在 CodeArts IDE 中打开代码智能体对话窗口，输入需求：实现这个运动场馆管理系统：某学校有各类运动场馆若干，包括足球场、篮球场、羽毛球场等。运动场馆可以按照课表设置为一段时间固定时间占用，非固定占用时间可以临时借用。借运动场馆时可根据时间段需求系统提供可用场地推荐，也可通过场馆列表挑选借用；实现借用情况查询、取消借用功能。CodeArts 代码智能体将自动完成以下工作：识别任务复杂度，创建多步骤 Todo 清单进行任务管理一次性生成完整项目结构，包括 package.json、vite.config.js、index.html、路由配置、API封装自动选择技术栈：Vue3 + Element Plus + Express + SQLite，无需人工指定生成数据库模型与种子数据，预置10个场馆和12条课表，开箱即用实现所有 API 接口，含时间冲突检测与智能推荐逻辑生成前端页面组件，包括登录页、数据看板、场馆管理、课表管理、借用场馆、借用查询6个页面1）项目结构说明yundongchangguan/ ├── package.json # 项目依赖与脚本配置 ├── vite.config.js # Vite构建配置（含API代理） ├── index.html # 前端入口HTML ├── server/ # 后端服务 │ ├── index.js # Express服务入口 │ ├── database.js # 数据库初始化、工具函数、种子数据 │ ├── utils.js # 错误码定义、参数校验工具函数 │ ├── routes/ │ │ ├── auth.js # 登录认证与权限中间件 │ │ ├── dashboard.js # 数据看板API │ │ ├── venues.js # 场馆CRUD API │ │ ├── schedules.js # 课表管理API（含冲突检测） │ │ └── borrowings.js # 借用管理API（含推荐、取消、时间限制） │ └── tests/ │ ├── test.js # 工具函数与数据库单元测试 │ └── api-test.js # API集成测试 ├── src/ # 前端源码 │ ├── main.js # Vue应用入口 │ ├── App.vue # 主布局（侧边导航+用户信息） │ ├── router/ │ │ └── index.js # 路由配置（6个页面+登录守卫） │ ├── api/ │ │ └── index.js # Axios API封装层（含token拦截器） │ └── views/ │ ├── Login.vue # 登录页面 │ ├── Dashboard.vue # 数据看板页面 │ ├── VenueList.vue # 场馆管理页面 │ ├── ScheduleManage.vue # 课表管理页面 │ ├── BorrowVenue.vue # 借用场馆页面（推荐+列表双模式） │ └── BorrowingQuery.vue # 借用查询与取消页面 └── dist/ # 构建产物（部署用）2）关键代码讲解（一）用户登录与权限控制系统采用 Token 认证机制，登录后返回 token，后续请求携带 token 进行身份验证。管理员可增删改场馆和课表，普通用户只能借用和查询。// server/routes/auth.js const tokens = new Map() router.post('/login', async (req, res) => { const { username, password } = req.body const user = queryGet(db, 'SELECT * FROM users WHERE username = ? AND password = ?', [username, password]) if (!user) return res.json(fail(ERROR_CODES.AUTH_FAILED)) const token = `tk_${user.id}_${Date.now()}_${Math.random().toString(36).slice(2)}` tokens.set(token, { id: user.id, username: user.username, role: user.role, display_name: user.display_name }) res.json(success({ token, user: { id: user.id, username: user.username, role: user.role, display_name: user.display_name } })) }) function authMiddleware(req, res, next) { const token = req.headers.authorization?.replace('Bearer ', '') if (!token || !tokens.has(token)) return res.json(fail(ERROR_CODES.AUTH_TOKEN_EXPIRED)) req.user = tokens.get(token) next() } function adminMiddleware(req, res, next) { if (!req.user || req.user.role !== 'admin') return res.json(fail(ERROR_CODES.AUTH_FORBIDDEN)) next() } （二）时间冲突检测 — 系统核心业务逻辑场馆占用涉及课表（按星期循环）和借用（按具体日期）两种时间维度。系统采用区间重叠判定法统一处理：// server/routes/borrowings.js // 两个时间段重叠的充要条件：A_start < B_end AND A_end > B_start // 检测与课表的冲突（将借用日期转为星期几后比对） const date = new Date(borrow_date) const dayOfWeek = date.getDay() === 0 ? 7 : date.getDay() const scheduleConflict = queryGet(db, 'SELECT * FROM schedules WHERE venue_id = ? AND day_of_week = ? AND (start_time < ? AND end_time > ?)', [venue_id, dayOfWeek, end_time, start_time] ) // 检测与已有借用的冲突 const borrowConflict = queryGet(db, "SELECT * FROM borrowings WHERE venue_id = ? AND borrow_date = ? AND status = 'active' AND (start_time < ? AND end_time > ?)", [venue_id, borrow_date, end_time, start_time] ) （三）借用时间限制校验后端统一校验单次借用不超过2小时、不能借用过去日期：// server/utils.js function validateTimeRange(start_time, end_time, maxMinutes = 120) { const [sh, sm] = start_time.split(':').map(Number) const [eh, em] = end_time.split(':').map(Number) const startMin = sh * 60 + sm const endMin = eh * 60 + em if (endMin <= startMin) return { valid: false, message: '结束时间必须晚于开始时间' } if (endMin - startMin > maxMinutes) return { valid: false, message: `单次借用时长不能超过${maxMinutes / 60}小时` } return { valid: true } } function validateDateNotPast(dateStr) { const today = new Date(); today.setHours(0, 0, 0, 0) if (new Date(dateStr) < today) return { valid: false, message: '不能借用过去的日期' } return { valid: true } } （四）API错误码规范化// server/utils.js const ERROR_CODES = { SUCCESS: 0, PARAM_MISSING: 10001, // 缺少必要参数 PARAM_INVALID: 10002, // 参数格式不正确 AUTH_FAILED: 20001, // 用户名或密码错误 AUTH_TOKEN_EXPIRED: 20002, // 登录已过期 AUTH_FORBIDDEN: 20003, // 无权限 NOT_FOUND: 30001, // 资源不存在 CONFLICT: 40001, // 资源冲突 TIME_LIMIT_EXCEEDED: 40002, // 超出时间限制 SERVER_ERROR: 50001 // 服务器内部错误 } （五）数据库事务保护// server/database.js function runTransaction(db, fn) { db.run('BEGIN TRANSACTION') try { fn(db) db.run('COMMIT') saveDB() } catch (e) { db.run('ROLLBACK') throw e } } // 删除场馆时事务性删除关联数据 router.delete('/:id', authMiddleware, adminMiddleware, async (req, res) => { runTransaction(db, (db) => { db.run('DELETE FROM borrowings WHERE venue_id = ?', [id]) db.run('DELETE FROM schedules WHERE venue_id = ?', [id]) db.run('DELETE FROM venues WHERE id = ?', [id]) }) }) （六）前端表单校验与时间限制提示<!-- src/views/BorrowVenue.vue --> <el-alert type="info" :closable="false">单次借用时长不超过2小时，需提前1天预约</el-alert> <el-form ref="borrowFormRef" :model="borrowForm" :rules="borrowRules"> <el-form-item label="借用人" prop="borrower_name"> <el-input v-model="borrowForm.borrower_name" /> </el-form-item> </el-form> <script> const borrowRules = { borrower_name: [{ required: true, message: '请输入姓名', trigger: 'blur' }], borrower_dept: [{ required: true, message: '请输入部门/班级', trigger: 'blur' }], end_time: [{ required: true, message: '请选择结束时间', trigger: 'change' }, { validator: validateTimeLimit, trigger: 'change' }] } </script> 3.3 安装依赖与环境适配1）安装项目依赖npm install 2）遇到的问题：原生模块编译失败安装过程中 better-sqlite3 因需要原生编译而失败，报错信息：npm error command failed npm error command C:\WINDOWS\system32\cmd.exe /d /s /c prebuild-install || node-gyp rebuild --release npm error 'node' 不是内部或外部命令CodeArts 代码智能体自动处理过程：识别根因为 node-gyp 子进程找不到 node 命令，属于原生模块编译依赖问题自主将 package.json 中的 better-sqlite3 替换为 sql.js（纯JS实现，无需原生编译）重写 server/database.js，适配 sql.js 的异步初始化模式（initSqlJs()）增加 saveDB() 函数，在每次写操作后手动持久化到文件（sql.js 默认在内存中运行）同步更新所有路由文件（venues.js、schedules.js、borrowings.js）为 async/await 模式重新执行 npm install 成功这一过程体现了 CodeArts 代码智能体的问题诊断与自主修复能力，无需人工介入即可完成技术方案切换。3.4 运行调试与功能验证1）启动后端服务新开一个终端窗口，执行：cd yundongchangguan node server/index.js看到以下输出表示后端启动成功：服务端运行在 http://localhost:30002）启动前端开发服务器再开一个终端窗口，执行：cd yundongchangguan npx vite看到以下输出表示前端启动成功： VITE v5.x.x ready in xxx ms ➜ Local: http://localhost:5173/3）登录系统浏览器访问 http://localhost:5173，进入登录页面。使用预置账号登录：角色用户名密码管理员adminadmin123普通用户user11234564）数据看板登录后进入数据看板页面，展示场馆总数、可用场馆数、今日借用数、有效借用数等统计信息，以及场馆利用率排行和最近借用记录。5）场馆管理在场馆管理页面查看10个预置场馆的卡片展示，管理员可新增、编辑、删除场馆。6）课表管理在课表管理页面查看12条预置课表，管理员可新增课表（含冲突检测）、编辑、删除。7）智能推荐借用在借用场馆页面，切换到"智能推荐"标签，选择日期和时间段后点击"查找可用场馆"，系统自动排除有课表占用和已有借用的场馆。8）场馆列表借用切换到"场馆列表借用"标签，直接从列表中选择场馆，填写借用信息提交。表单校验会检查必填项和2小时时间限制。9）借用查询与取消在借用查询页面，按场馆/姓名/日期/状态筛选借用记录，可取消有效借用。10）单元测试运行单元测试和API集成测试：npm test 测试覆盖内容：测试类型测试项数量工具函数success/fail/validateRequired/validateTimeRange/validateDateNotPast10数据库预置数据/管理员用户/事务回滚5API集成登录/看板/分页/时间限制/过去日期/未登录拒绝/权限控制811）构建前端产物npx vite build4、核心技术难点与解决思路难点一：时间段冲突检测的准确性问题： 场馆占用涉及课表（按星期循环）和借用（按具体日期）两种不同维度的时间表示，需准确判定冲突。解决思路：课表以 day_of_week（1-7）表示周期性占用，借用以 borrow_date（具体日期）表示一次性占用检测借用冲突时，先将借用日期转换为星期几（new Date(borrow_date).getDay()），再与课表比对统一使用区间重叠公式 start_time < end AND end_time > start 进行冲突判定，避免边界条件遗漏难点二：原生模块编译失败的环境适配问题： 初始选用 better-sqlite3 作为SQLite驱动，但在Windows环境下因 node 不在系统PATH中，导致 node-gyp 编译失败。解决思路：CodeArts 代码智能体自动识别根因为原生模块编译依赖问题，而非代码逻辑错误自主将 better-sqlite3（需原生编译）替换为 sql.js（纯JS实现，WASM运行）重写数据库操作层，适配 sql.js 的异步初始化模式（initSqlJs()）增加 saveDB() 函数，在每次写操作后手动持久化到文件（sql.js 默认在内存中运行）所有路由处理函数改为 async/await 模式以适配异步数据库初始化难点三：用户权限与接口安全问题： 系统需区分管理员和普通用户角色，管理员可管理场馆和课表，普通用户只能借用和查询，所有接口需鉴权保护。解决思路：登录成功后生成内存级 Token，前端存储在 localStorage 并通过 Axios 拦截器自动携带后端通过 authMiddleware 校验 Token 有效性，adminMiddleware 校验管理员权限前端路由守卫拦截未登录访问，自动跳转登录页Token 过期时后端返回 20002 错误码，前端自动清除本地存储并跳转登录难点四：前后端数据一致性保障问题： 借用操作涉及冲突检测和数据写入两步，若写入过程中断可能导致数据不一致。解决思路：引入 runTransaction() 函数，在删除场馆等涉及多表操作的场景使用事务保护删除场馆时事务性删除关联的借用记录和课表记录，保证数据完整性事务失败时自动 ROLLBACK，避免脏数据项目代码及演示视频

用码道（CodeArts）从零搭建酒店住宿管理系统——AI编程实战案例一、前言本项目体验了华为云的码道（CodeArts）代码智能体，用它从零开始搭建了一个酒店住宿管理系统。整个开发过程中，从需求分析、数据库设计、后端API开发到前端界面实现，全程与AI对话完成。本文将以我和码道的交互对话为主线，完整记录这个开发过程，分享给对AI辅助编程感兴趣的开发者。最终技术栈：后端：Python Flask + SQLAlchemy + PyMySQL前端：Vue3 + Element Plus + Vite数据库：MySQL 8.0项目地址：https://github.com/Monday23333333/HotelManagementDemo二、第一阶段：需求描述与数据库设计我：帮我设计一个酒店住宿管理系统的数据库我向码道描述了酒店管理系统的基本需求：需要管理房间、客人、入住记录和账单。码道很快给出了完整的数据库设计方案。码道：生成了5张核心表 + 1张会员等级表-- 码道设计的6张表 room_type -- 房型（支持工作日/周末/节假日差异化定价） room -- 房间（状态：空闲/入住/维护/预订） vip_level -- 会员等级（经验门槛+折扣率） guest -- 客人（关联会员等级，经验自动累计） check_in -- 入住记录（状态：在住/已退房） billing -- 账单（房费+额外费用-折扣=总额） 我：会员等级由消费经验自动决定，创建客人时不需要手动选择VIP等级我补充了一个重要的业务规则：会员等级不应该手动选择，而是根据消费经验自动升级。码道理解后，在Guest模型中加入了exp字段和vip_level_id外键，并设计了自动升级逻辑。码道：修改了Guest模型，增加经验自动累计机制class Guest(db.Model): __tablename__ = 'guest' # ... vip_level_id = db.Column(db.BigInteger, db.ForeignKey('vip_level.id'), default=1) exp = db.Column(db.Integer, default=0) # 经验值，消费1元=1点 vip = db.relationship('VipLevel', lazy='joined') 三、第二阶段：后端API开发（从Spring Boot到Flask的转折）我：用Spring Boot实现后端API一开始我选择的是Spring Boot + MyBatis，码道也按照这个方案生成了代码。遇到问题：JDK环境不支持运行时发现本地只有JDK 1.7/1.8的JRE（非JDK），无法编译Java项目。Maven中央仓库还有SSL证书问题，依赖下载失败。我：本地JDK环境有问题，能换成Python方案吗？码道：建议切换到Flask + SQLAlchemy码道快速分析了环境问题，建议改用Python Flask + SQLAlchemy方案，并立即重新生成了全部后端代码。几分钟后后端就跑通了！# backend/app/__init__.py - 应用工厂 def create_app(): app = Flask(__name__) app.config.from_object(Config) CORS(app, supports_credentials=True) db.init_app(app) register_routes(app) return app # backend/app/config.py - 数据库配置 class Config: SQLALCHEMY_DATABASE_URI = 'mysql+pymysql://root@localhost:3306/hotel_db?charset=utf8mb4' SQLALCHEMY_TRACK_MODIFICATIONS = False JSON_AS_ASCII = False # backend/run.py - 启动入口 if __name__ == '__main__': app.run(host='0.0.0.0', port=8080, debug=True) 我：房费要按工作日和周末差异化计算码道：实现了_calc_room_charge函数，逐天判断工作日/周末def _calc_room_charge(checkin): room = Room.query.filter_by(id=checkin.room_id, deleted=0).first() rt = RoomType.query.filter_by(id=room.room_type_id, deleted=0).first() start = checkin.check_in_time end = checkin.actual_checkout_time or datetime.now() days = (end.date() - start.date()).days if days <= 0: days = 1 total = Decimal('0') for i in range(days): day = start + timedelta(days=i) if day.weekday() >= 5: # 周末 total += rt.weekend_price if rt.weekend_price else rt.base_price else: # 工作日 total += rt.base_price return total我：退房时如果房费未结算，要提示用户码道：新增了/api/check-in/settled/<id>接口和退房检查逻辑后端新增结算检查接口：@app.route('/api/check-in/settled/<int:id>') def checkin_settled(id): billing = Billing.query.filter_by(check_in_id=id, deleted=0, status='PAID').first() return success({'settled': billing is not None}) 支付时自动累加经验并升级会员等级：def _add_exp_and_upgrade(guest_id, amount): guest = Guest.query.filter_by(id=guest_id, deleted=0).first() if not guest: return exp_gain = int(float(amount)) # 消费1元=1点经验 if exp_gain <= 0: return guest.exp = (guest.exp or 0) + exp_gain # 从高到低匹配等级，自动升级 best_level = VipLevel.query.filter_by(deleted=0).order_by(VipLevel.min_exp.desc()).all() for vl in best_level: if guest.exp >= vl.min_exp: guest.vip_level_id = vl.id break 四、第三阶段：前端页面开发我：用Vue3实现前端页面，现代卡片式界面风格码道：生成了完整的7个页面 + 主布局 + API封装4.1 主布局：深色侧边栏 + 浅色内容区<!-- frontend/src/App.vue --> <template> <div class="app-container"> <aside class="sidebar"> <div class="logo"> <el-icon :size="28"><House /></el-icon> <span class="logo-text">酒店管理系统</span> </div> <nav class="nav-menu"> <router-link v-for="item in menuItems" :key="item.path" :to="item.path" class="nav-item" :class="{ active: $route.path === item.path }"> <el-icon :size="20"><component :is="item.icon" /></el-icon> <span>{{ item.label }}</span> </router-link> </nav> </aside> <main class="main-content"> <header class="top-bar"> <h2 class="page-title">{{ $route.meta.title }}</h2> </header> <div class="content-area"><router-view /></div> </main> </div> </template> 侧边栏采用深紫色渐变（#1e1b4b → #312e81），激活项带发光阴影。4.2 首页概览：客房可视化看板我：可视化面板的占用率要把预订和维护也算进去，不只是入住码道：修改了占用率计算逻辑，status !== 'AVAILABLE'都算占用<!-- frontend/src/views/Dashboard.vue --> const floorData = computed(() => { const map = {} for (const r of rooms.value) { const f = r.floor if (!map[f]) map[f] = { floor: f, rooms: [], occupied: 0, total: 0 } map[f].rooms.push(r) map[f].total++ // 占用率包含预订和维护（不只是入住） if (r.status !== 'AVAILABLE') map[f].occupied++ } return Object.values(map).sort((a, b) => b.floor - a.floor).map(f => ({ ...f, rate: f.total > 0 ? Math.round(f.occupied / f.total * 100) : 0 })) }) const floorBgColor = (floor) => { const r = floor.rate if (r === 0) return 'linear-gradient(90deg, #f0fdf4 0%, #ecfdf5 100%)' if (r <= 30) return 'linear-gradient(90deg, #fefce8 0%, #fef9c3 100%)' if (r <= 60) return 'linear-gradient(90deg, #fff7ed 0%, #fed7aa 100%)' if (r <= 90) return 'linear-gradient(90deg, #fef2f2 0%, #fecaca 100%)' return 'linear-gradient(90deg, #fef2f2 0%, #fca5a5 100%)' } 每层楼一行，房间用色块表示状态（绿=空闲、黄=入住、红=维护、蓝=预订），悬停显示详情弹窗。4.3 房间管理：卡片式展示房间以卡片形式展示，顶部色条标识状态，支持下拉快速切换房间状态。4.4 入住管理：退房未结算警示我：退房时如果房费没结算，提示"该客人房费还未结算，直接退房后将不可再结算。是否确认退房？"码道：在退房流程中加入了checkSettled检查和二次确认弹窗<!-- frontend/src/views/CheckIn.vue --> const handleCheckOut = async (row) => { try { const res = await checkSettled(row.id) if (!res.data.settled) { await ElMessageBox.confirm( '该客人房费还未结算，直接退房后将不可再结算。是否确认退房？', '房费未结算提醒', { confirmButtonText: '确认退房', cancelButtonText: '取消', type: 'warning' } ) } else { await ElMessageBox.confirm('确定办理退房？', '提示', { type: 'warning' }) } } catch (e) { if (e === 'cancel') { router.push('/billing') // 取消则跳转结算页 return } return } await doCheckOut(row.id) ElMessage.success('退房成功') loadCheckIns() } 4.5 入住管理：入住人数联动房型上限我：选择房间后，入住人数要跟房型的最大入住人数联动码道：用computed属性动态计算maxGuestCount，切换房间时自动修正const maxGuestCount = computed(() => { if (!checkInForm.value.roomId) return 10 const room = availableRooms.value.find(r => r.id === checkInForm.value.roomId) if (!room) return 10 const rt = roomTypes.value.find(t => t.id === room.roomTypeId) return rt ? rt.maxOccupancy : 10 }) const onRoomChange = () => { if (checkInForm.value.guestCount > maxGuestCount.value) { checkInForm.value.guestCount = maxGuestCount.value } } 4.6 会员体系：等级卡片与经验条<!-- frontend/src/views/VipLevel.vue --> <div class="vip-card" v-for="(vl, idx) in vipLevels" :key="vl.id" :style="{ borderLeftColor: levelColors[idx % levelColors.length] }"> <div class="vip-name" :style="{ color: levelColors[idx % levelColors.length] }"> {{ vl.name }} </div> <div class="vip-row"> <span class="vip-label">折扣率</span> <span class="vip-value discount"> {{ vl.discountRate < 1 ? (vl.discountRate * 10).toFixed(1) + '折' : '无折扣' }} </span> </div> <div class="vip-exp-bar"> <div class="vip-exp-fill" :style="{ width: Math.min(vl.minExp / maxExp * 100, 100) + '%', background: levelColors[idx % levelColors.length] }"> </div> <span class="vip-exp-text">{{ vl.minExp }} exp</span> </div> </div> 4.7 房费结算账单表格展示房费、额外费用、折扣和总额，支持支付、编辑和删除操作。五、完整项目结构hotel-management/ ├── backend/ # Flask后端 │ ├── app/ │ │ ├── __init__.py # 应用工厂：创建Flask实例、初始化DB和CORS │ │ ├── config.py # 数据库连接配置 │ │ ├── models.py # SQLAlchemy数据模型（6个） │ │ ├── routes.py # REST API路由（20+接口） │ │ └── response.py # 统一响应格式封装 │ ├── run.py # 启动入口（0.0.0.0:8080） │ └── requirements.txt # Python依赖 ├── frontend/ # Vue3前端 │ ├── src/ │ │ ├── App.vue # 主布局：侧边栏+顶栏+内容区 │ │ ├── main.js # Vue3入口 │ │ ├── router/ │ │ │ └── index.js # 路由配置（7个页面+路由守卫） │ │ ├── api/ │ │ │ ├── request.js # Axios封装（baseURL+拦截器） │ │ │ └── hotel.js # 全部API调用函数 │ │ └── views/ │ │ ├── Dashboard.vue # 首页概览+客房可视化 │ │ ├── Room.vue # 房间管理（卡片式） │ │ ├── RoomType.vue # 房型价格管理 │ │ ├── Guest.vue # 客人管理 │ │ ├── CheckIn.vue # 入住管理 │ │ ├── Billing.vue # 房费结算 │ │ └── VipLevel.vue # 会员体系管理 │ ├── index.html │ ├── package.json │ └── vite.config.js # Vite配置（代理8080）六、交互过程总结：我和码道的完整对话链路回顾整个开发过程，我和码道的交互可以概括为以下几个阶段：阶段我的输入码道的输出需求分析“帮我设计酒店住宿管理系统的数据库”6张表的完整设计业务规则“会员等级由消费经验自动决定”修改Guest模型，增加exp字段和自动升级逻辑技术选型“本地JDK有问题，换成Python”从Spring Boot切换到Flask，重新生成全部后端业务逻辑“房费按工作日/周末差异化计算”_calc_room_charge函数，逐天判断计价业务逻辑“退房时房费未结算要提示”新增settled接口 + 前端二次确认弹窗前端开发“用Vue3实现，现代卡片式风格”7个页面组件 + 主布局 + API封装需求修正“占用率要把预订和维护也算进去”修改Dashboard计算逻辑需求修正“入住人数要联动房型上限”computed动态计算maxGuestCount关键体会：自然语言即需求文档：我不需要写PRD，直接用对话描述需求，码道就能理解并实现遇到阻塞能快速转向：JDK环境出问题时，一句话就切换到Flask方案增量迭代非常自然：先搭骨架，再逐步补充业务规则，每次只需描述差异上下文记忆很关键：码道能记住之前的对话，修改时保持一致性，不会"失忆"七、运行方式# 后端 cd hotel-management/backend pip install -r requirements.txt python run.py # 启动在 http://localhost:8080 # 前端 cd hotel-management/frontend npm install npm run dev # 启动在 http://localhost:5173，代理API到8080 # 数据库 # 需要先创建 hotel_db 数据库，并执行初始化SQL 八、总结通过这次实战，我深刻感受到AI辅助编程带来的效率提升。码道（CodeArts）不仅能快速生成代码，更重要的是——它能理解我的业务需求，和我进行有意义的对话。当我说"退房时房费没结算要提示"，它不仅加了提示，还考虑了取消后跳转结算页的交互细节。当然，AI生成的代码不是万能的，复杂的业务规则、性能优化、安全加固等仍需要开发者的专业判断。AI是工具，人是核心——善用工具，让开发更高效！

汽车销售管理系统仓库地址：汽车销售管理系统 - AtomGit一、题目选择与分析选择题目：汽车销售管理能够实现4S店的车辆种类、价格等进行管理，能够对客户进行管理，实现客户购买车辆的流程管理，费用结算等功能。分析该题目，需要实现的功能：1.车辆管理功能说明添加车辆录入品牌、型号、价格、库存数量删除车辆移除不再销售的车辆信息修改车辆更新车辆的品牌、型号、价格或库存查询车辆查看所有车辆列表，支持按品牌或型号搜索 2.客户管理功能说明添加客户录入客户姓名、联系方式删除客户移除客户信息修改客户更新客户姓名或联系方式查询客户查看所有客户列表 3.销售管理功能说明生成订单选择一个客户和一辆车，创建销售订单更新订单状态订单状态流转：下单 → 已完成自动扣减库存订单完成后，对应车辆的库存自动减1库存校验库存为0的车辆无法被选择下单销售记录所有订单自动保存，可查看历史销售列表             二、利用码道执行任务根据上面的功能需求，我们组织自然语言发送给码道：请帮助我构建一个汽车销售管理的Web应用，要求如下：在当前工作空间目录下创建项目，生成代码； 要求页面符合后台管理系统简洁、美观的风格； 车辆管理、客户管理、销售管理三项基本功能齐全； 具体功能包括： 车辆管理：车辆的增删改查（品牌、型号、价格、库存）； 客户管理：客户信息的增删改查（姓名、联系方式）； 销售管理：选择客户和车辆生成订单，更新订单状态； 车辆售出后自动扣减库存，库存为0时不可销售； 销售记录自动保存，便于查看历史。 接下来进行规范编码的四个步骤1.需求规格设计需求规格文档保存在 .codeartsdoer/specs/car_sales_mgmt/spec.md。核心要点：车辆管理：增删改查（品牌、型号、价格、库存），库存仅通过销售自动扣减，已关联订单的车辆禁止删除客户管理：增删改查（姓名、联系方式），联系方式11位手机号全局唯一，已关联订单的客户禁止删除销售管理：选择客户和车辆创建订单，状态单向流转（待确认→已确认→已完成），支持取消；售出自动扣减库存、取消自动回退库存；库存为0禁止销售DFX约束：页面响应≤2秒、接口响应≤1秒、数据一致性保障、敏感操作二次确认2.实现方案创建实现方案设计保存在 .codeartsdoer/specs/car_sales_mgmt/design.md。核心要点：技术架构：前后端分离，React + Ant Design（前端） / Node.js + Express（后端） / SQLite（数据库）后端三层架构：路由层 → 服务层 → DAO层订单状态机：待确认 → 已确认 → 已完成（单向流转），可从待确认/已确认 → 已取消核心流程：订单创建/取消均使用事务保证库存扣减/回退的原子性接口设计：16个RESTful API（车辆5个、客户5个、销售6个）数据模型：3个核心对象（Vehicle、Customer、Order），订单冗余存储客户/车辆关键信息确保历史可追溯    3.编码任务规划需求规格文档保存在 .codeartsdoer/specs/car_sales_mgmt/spec.md。核心要点：车辆管理：增删改查（品牌、型号、价格、库存），库存仅通过销售自动扣减，已关联订单的车辆禁止删除客户管理：增删改查（姓名、联系方式），联系方式11位手机号全局唯一，已关联订单的客户禁止删除销售管理：选择客户和车辆创建订单，状态单向流转（待确认→已确认→已完成），支持取消；售出自动扣减库存、取消自动回退库存；库存为0禁止销售DFX约束：页面响应≤2秒、接口响应≤1秒、数据一致性保障、敏感操作二次确认        4.任务执行spec-design-agent SubAgent: 汽车销售管理系统实现方案设计实现方案设计文档保存在 .codeartsdoer/specs/car_sales_mgmt/design.md。核心要点：技术架构：前后端分离，React + Ant Design（前端） / Node.js + Express（后端） / SQLite（数据库）后端三层架构：路由层 → 服务层 → DAO层订单状态机：待确认 → 已确认 → 已完成（单向流转），可从待确认/已确认 → 已取消核心流程：订单创建/取消均使用事务保证库存扣减/回退的原子性接口设计：16个RESTful API（车辆5个、客户5个、销售6个）数据模型：3个核心对象（Vehicle、Customer、Order），订单冗余存储客户/车辆关键信息确保历史可追溯是否需要修改文档？如无需修改，请告知进入下一阶段。spec-task-agent SubAgent: 汽车销售管理系统编码任务规划编码任务规划文档已生成，保存在 .codeartsdoer/specs/car_sales_mgmt/tasks.md。共 6个主任务、24个子任务：主任务子任务数覆盖需求1. 项目初始化与基础架构搭建5工程结构、后端框架、前端框架、数据库表2. 实现车辆管理功能4车辆CRUD、唯一性校验、删除保护、库存只读3. 实现客户管理功能4客户CRUD、唯一性校验、删除保护、手机号格式4. 实现销售管理功能4订单创建/状态流转/取消、库存扣减回退、历史快照5. 集成联调与功能验证3后端接口验证、前端页面验证、端到端业务流程6. 部署配置与收尾2启动脚本、最终验收任务结束，在内置浏览器上可以看到成品  三、关键代码实现汽车销售管理系统关键实现1、整体架构项目采用前后端分离架构。后端基于 Node.js + Express，遵循经典三层架构（路由层→服务层→数据访问层），数据库使用 SQLite（better-sqlite3 驱动）。前端基于 React + Vite + Ant Design，通过 Axios 调用后端 RESTful API。三层架构的核心价值在于职责分离：路由层只负责参数校验和请求分发，服务层承载业务逻辑，DAO 层只做数据持久化操作。2、数据库初始化与事务保障数据库初始化模块 server/db/init.js 负责建表和索引创建。三张核心表为 vehicles、customers、orders，其中订单表冗余存储了客户姓名、联系方式、车辆品牌、型号等快照字段，确保客户或车辆被删除后订单仍可展示历史信息。// server/db/init.jsdb.exec(`  CREATE TABLE IF NOT EXISTS orders (    id INTEGER PRIMARY KEY AUTOINCREMENT,    orderNo TEXT NOT NULL UNIQUE,    customerId INTEGER NOT NULL,    customerName TEXT NOT NULL,    customerPhone TEXT NOT NULL,    vehicleId INTEGER NOT NULL,    vehicleBrand TEXT NOT NULL,    vehicleModel TEXT NOT NULL,    amount REAL NOT NULL,    status TEXT NOT NULL DEFAULT 'PENDING',    createdAt TEXT NOT NULL DEFAULT (datetime('now', 'localtime')),    updatedAt TEXT NOT NULL DEFAULT (datetime('now', 'localtime'))  );`); 系统开启了 WAL 模式提升并发读性能，并启用外键约束。订单编号采用 ORD + YYYYMMDD + 4位顺序号 格式，在事务内生成以保证唯一性。3、订单创建——库存一致性的核心订单创建是系统最关键的流程，必须保证"订单创建"与"库存扣减"的原子性。实现上使用 better-sqlite3 的同步事务 API，采用 db.transaction() 包裹整个操作：// server/services/OrderService.js - createOrdercreateOrder({ customerId, vehicleId }) {  const customer = customerDAO.findById(customerId);  if (!customer) throw new BusinessError(404, '客户不存在', 404);  const vehicle = vehicleDAO.findById(vehicleId);  if (!vehicle) throw new BusinessError(404, '车辆不存在', 404);  const db = getDb();  const order = db.transaction(() => {    // 事务内重新查询库存，防止并发超卖    const v = db.prepare('SELECT * FROM vehicles WHERE id = ?').get(vehicleId);    if (v.stock <= 0) throw new BusinessError(422, '该车辆库存不足，无法销售');    const orderNo = orderDAO.generateOrderNo();    const newOrder = orderDAO.create({      orderNo, customerId: customer.id, customerName: customer.name,      customerPhone: customer.phone, vehicleId: vehicle.id,      vehicleBrand: vehicle.brand, vehicleModel: vehicle.model,      amount: vehicle.price, status: 'PENDING',    });    // 库存扣减通过 WHERE stock > 0 双重保障    const changes = vehicleDAO.decrementStock(vehicleId);    if (changes === 0) throw new BusinessError(422, '该车辆库存不足，无法销售');    return newOrder;  })();  return order;} 关键设计点：①事务内重新查询库存，避免事务外的脏读；②decrementStock 使用 WHERE stock > 0 作为乐观锁，即使并发请求也能保证不超卖；③订单编号生成在事务内完成，确保编号连续且唯一。4、订单状态机与取消回退订单状态流转采用状态机模式，通过 STATUS_FLOW 映射表定义合法流转路径： const STATUS_FLOW = {  PENDING: ['CONFIRMED', 'CANCELLED'],  CONFIRMED: ['COMPLETED', 'CANCELLED'],  COMPLETED: [],  CANCELLED: [],}; 状态更新时校验目标状态是否在允许列表中，非法流转返回 422 错误。取消订单时同样使用事务保证"状态变更"与"库存回退"的原子性：cancelOrder(id) {  const order = orderDAO.findById(id);  if (order.status === 'COMPLETED') throw new BusinessError(422, '已完成订单不可取消');  if (order.status === 'CANCELLED') throw new BusinessError(422, '订单已取消');  const db = getDb();  db.transaction(() => {    orderDAO.updateStatus(id, 'CANCELLED');    vehicleDAO.incrementStock(order.vehicleId);  })();  return orderDAO.findById(id);}5、删除保护与业务校验车辆和客户的删除都有关联订单保护。服务层在删除前查询 orders 表是否存在关联记录：// server/services/VehicleService.js - deleteVehicledeleteVehicle(id) {  const vehicle = vehicleDAO.findById(id);  if (!vehicle) throw new BusinessError(404, '车辆不存在', 404);  if (orderDAO.existsByVehicleId(id))    throw new BusinessError(409, '该车辆存在关联销售订单，无法删除');  vehicleDAO.deleteById(id);} 同理，库存字段不可通过编辑接口修改——路由层的 Joi 校验 schema 中 updateSchema 不包含 stock 字段，从接口层面杜绝了手动修改库存的可能。6、统一响应与错误处理后端通过 server/utils/response.js 封装了三种响应格式（成功、分页、错误），所有接口返回统一的 JSON 结构 { code, data, message }。错误处理中间件捕获 BusinessError（业务异常）和 Joi 校验错误，自动转换为标准响应格式：// server/middleware/errorHandler.jsfunction errorHandler(err, req, res, _next) {  if (err.isBusiness) {    return res.status(err.httpStatus || 400).json(resp.error(err.code, err.message));  }  if (err.isJoi) {    return res.status(400).json(resp.error(400, err.details.map(d => d.message).join('; ')));  }  res.status(500).json(resp.error(500, '服务器内部错误'));} 前端 Axios 拦截器统一处理响应，code !== 0 时自动弹出 message.error 提示，开发者无需在每个 API 调用处重复编写错误处理逻辑。7、前端管理布局与页面交互前端使用 Ant Design 的 Layout 组件实现侧边栏+内容区的后台管理布局，Sider 支持折叠，Menu 根据当前路由高亮。三个页面（车辆、客户、销售）均采用 Table + Modal 模式：列表页展示数据和分页，点击"新增/编辑"弹出 Modal 表单，删除使用 Popconfirm 二次确认。销售管理页面最为复杂，创建订单时通过下拉选择器加载客户和车辆列表，选择车辆后自动填充金额（只读），库存为0的车辆标注"库存不足"并禁用选择。订单状态标签通过颜色区分（橙色待确认、蓝色已确认、绿色已完成、灰色已取消），更新状态时调用 getNextStatuses 接口获取合法目标状态列表，仅展示可流转的选项。  四、成品展示我们在浏览器中打开：打开两个终端（命令行窗口）终端1 - 启动后端：cd D:\md2\demo6node server/app.js终端2 - 启动前端：cd D:\md2\demo6\clientnpx vite在浏览器地址栏输入 http://localhost:3000 回车即可  五、总结与体会（一）项目总结本次专业实习以华为云码道为开发平台，完成了汽车销售管理系统的完整开发流程。从需求分析、方案设计、任务规划到编码实现，系统性地实践了企业级Web应用的全生命周期开发方法。在技术层面，项目采用前后端分离架构，后端基于Node.js + Express构建三层架构（路由层→服务层→DAO层），前端使用React + Vite + Ant Design搭建响应式后台管理界面，SQLite作为数据存储引擎。通过16个RESTful API接口实现了车辆管理、客户管理、销售管理三大核心功能模块。在工程实践层面，本次开发严格遵循了规范化的软件开发流程。码道平台的需求规格设计、实现方案创建、编码任务规划和任务执行四个阶段，让我深刻体会到结构化开发方法论在实际项目中的价值。特别是在订单创建与库存扣减的原子性保障、订单状态机的流转控制、删除保护等关键业务场景中，通过事务机制、乐观锁、状态校验等手段确保了数据的一致性和系统的健壮性。（二）核心收获1. 系统设计能力的提升通过对汽车销售管理系统的完整建模，我掌握了从业务需求到技术实现的转化方法。三层架构的职责划分、接口契约的设计、数据库表结构的规划，都让我对软件工程中的“高内聚、低耦合”原则有了更直观的认识。特别是订单表中冗余存储客户和车辆快照字段的设计决策，理解了“以空间换时间”在确保历史数据可追溯性方面的重要意义。2. 数据一致性保障的工程实践订单创建与库存扣减的并发控制是本次开发中最具挑战性的环节。通过使用数据库事务包裹整个操作流程，配合WHERE stock > 0条件作为乐观锁，有效防止了超卖问题。这一实践让我深刻理解了在并发场景下，单纯依靠应用层逻辑是不够的，必须借助数据库层面的原子性保证才能实现真正的数据一致性。 3. 全栈开发的综合能力从后端的接口开发、数据库操作，到前端的组件构建、状态管理，再到前后端的联调测试，我完整地经历了一个全栈项目的开发闭环。对Axios拦截器的统一错误处理、Ant Design组件的灵活运用、Vite构建工具的开发体验，都极大地拓宽了我的技术视野。4. 规范开发流程的认知码道平台引导的四个开发阶段让我认识到，优秀的代码不仅仅是写出来的，更是设计出来的。需求规格文档明确了“做什么”，实现方案文档回答了“怎么做”，任务规划则把大目标拆解为可执行的子任务，这种“文档驱动开发”的模式有效降低了项目的返工率和不确定性。（三）存在的不足与改进方向1. 功能层面的局限当前系统仅支持单机部署，缺乏多用户角色与权限管理机制。在实际4S店场景中，销售顾问、库存管理员、财务人员等不同角色应有不同的操作权限和数据可见范围。未来可引入基于角色的访问控制（RBAC），实现更细粒度的权限管理。2. 技术栈的深化空间数据库层面：SQLite适用于轻量级场景，生产环境可迁移至PostgreSQL或MySQL，并引入ORM框架（如Prisma或TypeORM）提升数据访问层的可维护性。缓存与性能优化：车辆列表、客户列表等高频查询接口可引入Redis缓存，降低数据库压力，进一步提升响应速度。前端状态管理：随着业务复杂度增加，可引入Zustand或Redux Toolkit管理全局状态，替代组件间层层传递props的方式。测试体系：当前项目缺少自动化测试覆盖，后续可补充单元测试（Jest）、集成测试（Supertest）和端到端测试（Playwright），保障系统迭代质量。3. 部署与运维目前系统仅在开发环境运行，未来可容器化部署（Docker + Docker Compose），并配置CI/CD流水线实现自动化构建与发布。同时可接入日志收集与监控告警系统，提升系统的可观测性。（四）未来展望本次实习项目是我从课堂知识走向工程实践的重要桥梁。通过亲手构建一个功能完整的业务系统，我不仅巩固了数据结构、数据库原理、网络编程等理论基础，更积累了宝贵的项目经验。面向未来，我希望在以下方向持续深耕：深入后端架构：学习微服务架构、消息队列、分布式事务等进阶技术，提升大规模系统的设计能力；拓展前端视野：研究Next.js服务端渲染、WebAssembly等前沿技术，探索更优的Web应用交付方案关注云原生生态：结合华为云等云服务平台，学习函数计算、容器编排、Serverless等云上开发模式，为未来职业发展做好准备。最后，衷心感谢学院提供的实习机会，感谢华为云码道平台提供的开发环境与规范指导，也感谢指导老师在项目过程中给予的宝贵建议。本次实习不仅让我完成了一个可运行的软件系统，更重要的是建立了一套科学的工程化开发思维，这将使我终身受益。 

汽车销售管理系统仓库地址：汽车销售管理系统 - AtomGit一、题目选择与分析选择题目：汽车销售管理能够实现4S店的车辆种类、价格等进行管理，能够对客户进行管理，实现客户购买车辆的流程管理，费用结算等功能。分析该题目，需要实现的功能：1.车辆管理功能说明添加车辆录入品牌、型号、价格、库存数量删除车辆移除不再销售的车辆信息修改车辆更新车辆的品牌、型号、价格或库存查询车辆查看所有车辆列表，支持按品牌或型号搜索 2.客户管理功能说明添加客户录入客户姓名、联系方式删除客户移除客户信息修改客户更新客户姓名或联系方式查询客户查看所有客户列表 3.销售管理功能说明生成订单选择一个客户和一辆车，创建销售订单更新订单状态订单状态流转：下单 → 已完成自动扣减库存订单完成后，对应车辆的库存自动减1库存校验库存为0的车辆无法被选择下单销售记录所有订单自动保存，可查看历史销售列表            二、利用码道执行任务根据上面的功能需求，我们组织自然语言发送给码道：请帮助我构建一个汽车销售管理的Web应用，要求如下：在当前工作空间目录下创建项目，生成代码； 要求页面符合后台管理系统简洁、美观的风格； 车辆管理、客户管理、销售管理三项基本功能齐全； 具体功能包括： 车辆管理：车辆的增删改查（品牌、型号、价格、库存）； 客户管理：客户信息的增删改查（姓名、联系方式）； 销售管理：选择客户和车辆生成订单，更新订单状态； 车辆售出后自动扣减库存，库存为0时不可销售； 销售记录自动保存，便于查看历史。 接下来进行规范编码的四个步骤1.需求规格设计需求规格文档保存在 .codeartsdoer/specs/car_sales_mgmt/spec.md。核心要点：车辆管理：增删改查（品牌、型号、价格、库存），库存仅通过销售自动扣减，已关联订单的车辆禁止删除客户管理：增删改查（姓名、联系方式），联系方式11位手机号全局唯一，已关联订单的客户禁止删除销售管理：选择客户和车辆创建订单，状态单向流转（待确认→已确认→已完成），支持取消；售出自动扣减库存、取消自动回退库存；库存为0禁止销售DFX约束：页面响应≤2秒、接口响应≤1秒、数据一致性保障、敏感操作二次确认2.实现方案创建实现方案设计保存在 .codeartsdoer/specs/car_sales_mgmt/design.md。核心要点：技术架构：前后端分离，React + Ant Design（前端） / Node.js + Express（后端） / SQLite（数据库）后端三层架构：路由层 → 服务层 → DAO层订单状态机：待确认 → 已确认 → 已完成（单向流转），可从待确认/已确认 → 已取消核心流程：订单创建/取消均使用事务保证库存扣减/回退的原子性接口设计：16个RESTful API（车辆5个、客户5个、销售6个）数据模型：3个核心对象（Vehicle、Customer、Order），订单冗余存储客户/车辆关键信息确保历史可追溯    3.编码任务规划需求规格文档保存在 .codeartsdoer/specs/car_sales_mgmt/spec.md。核心要点：车辆管理：增删改查（品牌、型号、价格、库存），库存仅通过销售自动扣减，已关联订单的车辆禁止删除客户管理：增删改查（姓名、联系方式），联系方式11位手机号全局唯一，已关联订单的客户禁止删除销售管理：选择客户和车辆创建订单，状态单向流转（待确认→已确认→已完成），支持取消；售出自动扣减库存、取消自动回退库存；库存为0禁止销售DFX约束：页面响应≤2秒、接口响应≤1秒、数据一致性保障、敏感操作二次确认        4.任务执行spec-design-agent SubAgent: 汽车销售管理系统实现方案设计实现方案设计文档保存在 .codeartsdoer/specs/car_sales_mgmt/design.md。核心要点：技术架构：前后端分离，React + Ant Design（前端） / Node.js + Express（后端） / SQLite（数据库）后端三层架构：路由层 → 服务层 → DAO层订单状态机：待确认 → 已确认 → 已完成（单向流转），可从待确认/已确认 → 已取消核心流程：订单创建/取消均使用事务保证库存扣减/回退的原子性接口设计：16个RESTful API（车辆5个、客户5个、销售6个）数据模型：3个核心对象（Vehicle、Customer、Order），订单冗余存储客户/车辆关键信息确保历史可追溯是否需要修改文档？如无需修改，请告知进入下一阶段。spec-task-agent SubAgent: 汽车销售管理系统编码任务规划编码任务规划文档已生成，保存在 .codeartsdoer/specs/car_sales_mgmt/tasks.md。共 6个主任务、24个子任务：主任务子任务数覆盖需求1. 项目初始化与基础架构搭建5工程结构、后端框架、前端框架、数据库表2. 实现车辆管理功能4车辆CRUD、唯一性校验、删除保护、库存只读3. 实现客户管理功能4客户CRUD、唯一性校验、删除保护、手机号格式4. 实现销售管理功能4订单创建/状态流转/取消、库存扣减回退、历史快照5. 集成联调与功能验证3后端接口验证、前端页面验证、端到端业务流程6. 部署配置与收尾2启动脚本、最终验收任务结束，在内置浏览器上可以看到成品  三、关键代码实现汽车销售管理系统关键实现1、整体架构项目采用前后端分离架构。后端基于 Node.js + Express，遵循经典三层架构（路由层→服务层→数据访问层），数据库使用 SQLite（better-sqlite3 驱动）。前端基于 React + Vite + Ant Design，通过 Axios 调用后端 RESTful API。三层架构的核心价值在于职责分离：路由层只负责参数校验和请求分发，服务层承载业务逻辑，DAO 层只做数据持久化操作。2、数据库初始化与事务保障数据库初始化模块 server/db/init.js 负责建表和索引创建。三张核心表为 vehicles、customers、orders，其中订单表冗余存储了客户姓名、联系方式、车辆品牌、型号等快照字段，确保客户或车辆被删除后订单仍可展示历史信息。// server/db/init.jsdb.exec(`  CREATE TABLE IF NOT EXISTS orders (    id INTEGER PRIMARY KEY AUTOINCREMENT,    orderNo TEXT NOT NULL UNIQUE,    customerId INTEGER NOT NULL,    customerName TEXT NOT NULL,    customerPhone TEXT NOT NULL,    vehicleId INTEGER NOT NULL,    vehicleBrand TEXT NOT NULL,    vehicleModel TEXT NOT NULL,    amount REAL NOT NULL,    status TEXT NOT NULL DEFAULT 'PENDING',    createdAt TEXT NOT NULL DEFAULT (datetime('now', 'localtime')),    updatedAt TEXT NOT NULL DEFAULT (datetime('now', 'localtime'))  );`); 系统开启了 WAL 模式提升并发读性能，并启用外键约束。订单编号采用 ORD + YYYYMMDD + 4位顺序号 格式，在事务内生成以保证唯一性。3、订单创建——库存一致性的核心订单创建是系统最关键的流程，必须保证"订单创建"与"库存扣减"的原子性。实现上使用 better-sqlite3 的同步事务 API，采用 db.transaction() 包裹整个操作：// server/services/OrderService.js - createOrdercreateOrder({ customerId, vehicleId }) {  const customer = customerDAO.findById(customerId);  if (!customer) throw new BusinessError(404, '客户不存在', 404);  const vehicle = vehicleDAO.findById(vehicleId);  if (!vehicle) throw new BusinessError(404, '车辆不存在', 404);  const db = getDb();  const order = db.transaction(() => {    // 事务内重新查询库存，防止并发超卖    const v = db.prepare('SELECT * FROM vehicles WHERE id = ?').get(vehicleId);    if (v.stock <= 0) throw new BusinessError(422, '该车辆库存不足，无法销售');    const orderNo = orderDAO.generateOrderNo();    const newOrder = orderDAO.create({      orderNo, customerId: customer.id, customerName: customer.name,      customerPhone: customer.phone, vehicleId: vehicle.id,      vehicleBrand: vehicle.brand, vehicleModel: vehicle.model,      amount: vehicle.price, status: 'PENDING',    });    // 库存扣减通过 WHERE stock > 0 双重保障    const changes = vehicleDAO.decrementStock(vehicleId);    if (changes === 0) throw new BusinessError(422, '该车辆库存不足，无法销售');    return newOrder;  })();  return order;} 关键设计点：①事务内重新查询库存，避免事务外的脏读；②decrementStock 使用 WHERE stock > 0 作为乐观锁，即使并发请求也能保证不超卖；③订单编号生成在事务内完成，确保编号连续且唯一。4、订单状态机与取消回退订单状态流转采用状态机模式，通过 STATUS_FLOW 映射表定义合法流转路径： const STATUS_FLOW = {  PENDING: ['CONFIRMED', 'CANCELLED'],  CONFIRMED: ['COMPLETED', 'CANCELLED'],  COMPLETED: [],  CANCELLED: [],}; 状态更新时校验目标状态是否在允许列表中，非法流转返回 422 错误。取消订单时同样使用事务保证"状态变更"与"库存回退"的原子性：cancelOrder(id) {  const order = orderDAO.findById(id);  if (order.status === 'COMPLETED') throw new BusinessError(422, '已完成订单不可取消');  if (order.status === 'CANCELLED') throw new BusinessError(422, '订单已取消');  const db = getDb();  db.transaction(() => {    orderDAO.updateStatus(id, 'CANCELLED');    vehicleDAO.incrementStock(order.vehicleId);  })();  return orderDAO.findById(id);}5、删除保护与业务校验车辆和客户的删除都有关联订单保护。服务层在删除前查询 orders 表是否存在关联记录：// server/services/VehicleService.js - deleteVehicledeleteVehicle(id) {  const vehicle = vehicleDAO.findById(id);  if (!vehicle) throw new BusinessError(404, '车辆不存在', 404);  if (orderDAO.existsByVehicleId(id))    throw new BusinessError(409, '该车辆存在关联销售订单，无法删除');  vehicleDAO.deleteById(id);} 同理，库存字段不可通过编辑接口修改——路由层的 Joi 校验 schema 中 updateSchema 不包含 stock 字段，从接口层面杜绝了手动修改库存的可能。6、统一响应与错误处理后端通过 server/utils/response.js 封装了三种响应格式（成功、分页、错误），所有接口返回统一的 JSON 结构 { code, data, message }。错误处理中间件捕获 BusinessError（业务异常）和 Joi 校验错误，自动转换为标准响应格式：// server/middleware/errorHandler.jsfunction errorHandler(err, req, res, _next) {  if (err.isBusiness) {    return res.status(err.httpStatus || 400).json(resp.error(err.code, err.message));  }  if (err.isJoi) {    return res.status(400).json(resp.error(400, err.details.map(d => d.message).join('; ')));  }  res.status(500).json(resp.error(500, '服务器内部错误'));} 前端 Axios 拦截器统一处理响应，code !== 0 时自动弹出 message.error 提示，开发者无需在每个 API 调用处重复编写错误处理逻辑。7、前端管理布局与页面交互前端使用 Ant Design 的 Layout 组件实现侧边栏+内容区的后台管理布局，Sider 支持折叠，Menu 根据当前路由高亮。三个页面（车辆、客户、销售）均采用 Table + Modal 模式：列表页展示数据和分页，点击"新增/编辑"弹出 Modal 表单，删除使用 Popconfirm 二次确认。销售管理页面最为复杂，创建订单时通过下拉选择器加载客户和车辆列表，选择车辆后自动填充金额（只读），库存为0的车辆标注"库存不足"并禁用选择。订单状态标签通过颜色区分（橙色待确认、蓝色已确认、绿色已完成、灰色已取消），更新状态时调用 getNextStatuses 接口获取合法目标状态列表，仅展示可流转的选项。  四、成品展示我们在浏览器中打开：打开两个终端（命令行窗口）终端1 - 启动后端：cd D:\md2\demo6node server/app.js终端2 - 启动前端：cd D:\md2\demo6\clientnpx vite在浏览器地址栏输入 http://localhost:3000 回车即可 五、总结与体会（一）项目总结本次专业实习以华为云码道为开发平台，完成了汽车销售管理系统的完整开发流程。从需求分析、方案设计、任务规划到编码实现，系统性地实践了企业级Web应用的全生命周期开发方法。在技术层面，项目采用前后端分离架构，后端基于Node.js + Express构建三层架构（路由层→服务层→DAO层），前端使用React + Vite + Ant Design搭建响应式后台管理界面，SQLite作为数据存储引擎。通过16个RESTful API接口实现了车辆管理、客户管理、销售管理三大核心功能模块。在工程实践层面，本次开发严格遵循了规范化的软件开发流程。码道平台的需求规格设计、实现方案创建、编码任务规划和任务执行四个阶段，让我深刻体会到结构化开发方法论在实际项目中的价值。特别是在订单创建与库存扣减的原子性保障、订单状态机的流转控制、删除保护等关键业务场景中，通过事务机制、乐观锁、状态校验等手段确保了数据的一致性和系统的健壮性。（二）核心收获1. 系统设计能力的提升通过对汽车销售管理系统的完整建模，我掌握了从业务需求到技术实现的转化方法。三层架构的职责划分、接口契约的设计、数据库表结构的规划，都让我对软件工程中的“高内聚、低耦合”原则有了更直观的认识。特别是订单表中冗余存储客户和车辆快照字段的设计决策，理解了“以空间换时间”在确保历史数据可追溯性方面的重要意义。2. 数据一致性保障的工程实践订单创建与库存扣减的并发控制是本次开发中最具挑战性的环节。通过使用数据库事务包裹整个操作流程，配合WHERE stock > 0条件作为乐观锁，有效防止了超卖问题。这一实践让我深刻理解了在并发场景下，单纯依靠应用层逻辑是不够的，必须借助数据库层面的原子性保证才能实现真正的数据一致性。 3. 全栈开发的综合能力从后端的接口开发、数据库操作，到前端的组件构建、状态管理，再到前后端的联调测试，我完整地经历了一个全栈项目的开发闭环。对Axios拦截器的统一错误处理、Ant Design组件的灵活运用、Vite构建工具的开发体验，都极大地拓宽了我的技术视野。4. 规范开发流程的认知码道平台引导的四个开发阶段让我认识到，优秀的代码不仅仅是写出来的，更是设计出来的。需求规格文档明确了“做什么”，实现方案文档回答了“怎么做”，任务规划则把大目标拆解为可执行的子任务，这种“文档驱动开发”的模式有效降低了项目的返工率和不确定性。（三）存在的不足与改进方向1. 功能层面的局限当前系统仅支持单机部署，缺乏多用户角色与权限管理机制。在实际4S店场景中，销售顾问、库存管理员、财务人员等不同角色应有不同的操作权限和数据可见范围。未来可引入基于角色的访问控制（RBAC），实现更细粒度的权限管理。2. 技术栈的深化空间数据库层面：SQLite适用于轻量级场景，生产环境可迁移至PostgreSQL或MySQL，并引入ORM框架（如Prisma或TypeORM）提升数据访问层的可维护性。缓存与性能优化：车辆列表、客户列表等高频查询接口可引入Redis缓存，降低数据库压力，进一步提升响应速度。前端状态管理：随着业务复杂度增加，可引入Zustand或Redux Toolkit管理全局状态，替代组件间层层传递props的方式。测试体系：当前项目缺少自动化测试覆盖，后续可补充单元测试（Jest）、集成测试（Supertest）和端到端测试（Playwright），保障系统迭代质量。3. 部署与运维目前系统仅在开发环境运行，未来可容器化部署（Docker + Docker Compose），并配置CI/CD流水线实现自动化构建与发布。同时可接入日志收集与监控告警系统，提升系统的可观测性。（四）未来展望本次实习项目是我从课堂知识走向工程实践的重要桥梁。通过亲手构建一个功能完整的业务系统，我不仅巩固了数据结构、数据库原理、网络编程等理论基础，更积累了宝贵的项目经验。面向未来，我希望在以下方向持续深耕：深入后端架构：学习微服务架构、消息队列、分布式事务等进阶技术，提升大规模系统的设计能力；拓展前端视野：研究Next.js服务端渲染、WebAssembly等前沿技术，探索更优的Web应用交付方案关注云原生生态：结合华为云等云服务平台，学习函数计算、容器编排、Serverless等云上开发模式，为未来职业发展做好准备。最后，衷心感谢学院提供的实习机会，感谢华为云码道平台提供的开发环境与规范指导，也感谢指导老师在项目过程中给予的宝贵建议。本次实习不仅让我完成了一个可运行的软件系统，更重要的是建立了一套科学的工程化开发思维，这将使我终身受益。 

基于华为云码道（CodeArts）代码智能体的幼儿园管理系统开发与 ECS 部署一、概述1.1 案例介绍本案例使用华为云码道（CodeArts）代码智能体，完成一个幼儿园管理系统的需求分析、方案设计、编码、测试和华为云 ECS 部署。系统面向幼儿园日常管理场景，实现了儿童学籍、班级、兴趣课程、食谱和调班记录管理，并提供“按班级查询儿童”和“按儿童查询班级及课程”两种查询方式。演示地址：http://121.36.40.212/演示环境中的儿童姓名、监护人和电话均为自动生成的测试数据，不包含真实儿童信息。管理账号和服务器密码不公开。1.2 核心业务要求幼儿园设大班、中班、小班三个年级；每个年级包含 3 个班，共 9 个班；每班包含 10 名儿童，共 90 名儿童；每名儿童学习舞蹈、跆拳道、钢琴、美术 4 门兴趣课程；支持儿童学籍、班级、课程和每日食谱管理；支持儿童调班，并保留可追溯的调班记录；支持根据班级查找儿童；支持根据儿童查找所在班级和所学课程。1.3 案例流程使用华为云码道梳理需求并生成解决方案；完成 Django 数据模型和 RESTful API；完成 Bootstrap 单页管理界面；初始化 3 个年级、9 个班级、90 名儿童和 4 门课程；编写自动化测试并修复课程数量、班级容量和调班一致性问题；购买华为云 ECS，完成系统部署；通过公网地址和健康检查验证部署结果。1.4 资源总览资源实际配置用途华为云码道（CodeArts）代码智能体训练营开发环境需求、设计、编码和问题修复弹性云服务器 ECS华北-北京四，1 vCPU、1 GiB运行 Django 应用操作系统Ubuntu 24.04 Server 64 位服务器运行环境云硬盘 EVS通用型 SSD，40 GiB系统与应用数据弹性公网 IP5 Mbit/s公网访问VPC 与安全组kindergarten-web网络隔离及端口访问控制费用采用按需计费，实际价格以华为云控制台为准。二、系统设计2.1 技术栈层次技术说明后端Python、Django 5.2ORM、业务 API 和管理后台前端Bootstrap 5、原生 JavaScript无需额外构建的单页管理界面数据库SQLite适合训练营单机演示，可切换 PostgreSQLWeb 服务Gunicorn生产环境 WSGI 服务静态文件WhiteNoiseDjango 生产环境静态文件服务进程管理systemd开机自启、异常重启和日志管理云资源华为云 ECS、EVS、EIP、VPC、安全组应用部署及公网访问2.2 部署架构2.3 核心数据模型系统包含 6 个核心模型：模型作用主要关系Grade大班、中班、小班年级信息一个年级包含多个班级Klass班级、班号和容量一个班级包含多名儿童Child儿童学籍及监护人信息属于一个班级，与课程多对多关联Course兴趣课程和课程容量与儿童多对多关联Recipe日期、餐次、菜名、食材和营养说明同日同餐次可管理不同菜品ClassTransferLog儿童调班历史记录原班级、新班级、原因和时间三、使用华为云码道辅助开发本项目按照规范驱动开发思路推进：需求描述 → 需求规格设计（spec） → 实现方案设计（design） → 编码任务规划（tasks） → 任务执行与测试 → 部署方案设计初始需求输入后，代码智能体将业务拆分为学籍、班级、课程、食谱、调班和综合查询等模块，并生成数据模型、接口设计、项目结构及实施任务。在开发过程中，码道还辅助完成了以下修复：将课程规则明确为“恰好选择 4 门不同的兴趣课程”；新增班级容量校验，班级达到 10 人后禁止继续加入；使用数据库事务保护调班操作；增加调班日志，保证操作可追溯；增加生产环境配置、Gunicorn、WhiteNoise 和健康检查；增加覆盖关键业务规则的自动化测试。四、系统功能展示4.1 首页概览首页显示在园儿童、班级、兴趣课程和年级数量。初始化完成后共有 90 名儿童、9 个班级、4 门兴趣课程和 3 个年级，每个年级均为 3 个班、30 名儿童。4.2 儿童学籍管理儿童学籍页面展示姓名、性别、出生日期、所在班级、兴趣课程和在园状态，并支持搜索、按年级筛选、新增、编辑和删除。新增儿童时需要录入监护人和班级信息，并且必须选择 4 门不同的兴趣课程。前端与后端都会校验该规则。4.3 班级管理系统初始化大班、中班、小班各 3 个班。班级列表实时显示容量、当前人数和是否已满，避免超额分班。4.4 课程管理系统提供舞蹈、跆拳道、钢琴、美术 4 门兴趣课程。每门课程可查看课程说明、容量和已选人数。4.5 食谱管理食谱按照日期和餐次管理，记录菜名、主要食材和营养说明，可按日期筛选。4.6 调班管理调班页面可选择儿童、查看当前班级、选择目标班级并填写调班原因。后端会锁定相关数据、检查目标班级容量，并在成功后生成调班记录。4.7 综合查询综合查询同时支持两种业务场景：选择班级后，显示本班全部儿童及其兴趣课程；选择儿童后，显示儿童基本信息、所在班级和所学课程。五、关键实现5.1 四门兴趣课程约束后端要求课程 ID 数量必须为 4，并且不能重复：def _validate_four_courses(course_ids): """每个儿童必须选择四门互不重复的兴趣课程。""" return len(course_ids) == 4 and len(set(course_ids)) == 4 创建或修改儿童时，如果不满足规则，API 返回 400，防止仅依赖前端校验而产生不一致数据。5.2 班级容量控制新增儿童和调班都会检查目标班级当前在园人数：def _klass_has_space(klass_id, *, exclude_child_id=None): students = Child.objects.filter(klass_id=klass_id, is_active=True) if exclude_child_id: students = students.exclude(pk=exclude_child_id) klass = Klass.objects.get(pk=klass_id) return students.count() < klass.max_students5.3 调班事务与日志调班操作使用 transaction.atomic()，同时通过 select_for_update() 锁定儿童和目标班级。只有容量校验通过后才记录日志并更新儿童班级：with transaction.atomic(): child = Child.objects.select_for_update().select_related('klass').get(pk=child_id) to_klass = Klass.objects.select_for_update().get(pk=to_klass_id) if not _klass_has_space(to_klass.id, exclude_child_id=child.id): return error('目标班级已满，无法调入') ClassTransferLog.objects.create( child=child, from_klass=child.klass, to_klass=to_klass, reason=reason, ) child.klass = to_klass child.save() 5.4 查询优化查询儿童信息时使用 select_related 和 prefetch_related 一次加载班级、年级和课程，减少重复数据库访问：children = Child.objects.select_related( 'klass', 'klass__grade' ).prefetch_related('courses') 六、自动化测试项目包含 6 项自动化测试，覆盖：每名儿童必须选择 4 门不同课程；满员班级拒绝新增儿童；调班成功后生成日志；满员目标班级拒绝调班；按班级、按儿童查询结果正确；初始化命令可重复执行，并始终生成 3 个年级、9 个班、90 名儿童和 4 门课程；公网健康检查返回正常状态。执行结果：Found 6 test(s). Ran 6 tests in 0.126s OK System check identified no issues (0 silenced).七、部署至华为云 ECS7.1 云服务器配置本项目部署在华北-北京四区域，实例名为 kindergarten-demo，使用 Ubuntu 24.04 Server、1 vCPU、1 GiB 内存、40 GiB 系统盘和 5 Mbit/s 公网带宽。7.2 上传并准备运行环境应用上传至 /opt/kindergarten/app，并在服务器创建独立 Python 虚拟环境：apt-get update apt-get install -y python3-venv python3 -m venv /opt/kindergarten/venv /opt/kindergarten/venv/bin/pip install \ -i https://pypi.tuna.tsinghua.edu.cn/simple \ -r /opt/kindergarten/app/requirements.txt7.3 初始化生产环境生产环境将随机生成的 DJANGO_SECRET_KEY、允许访问的主机和数据库路径保存在权限为 600 的 /etc/kindergarten.env 中，不写入源码。set -a . /etc/kindergarten.env set +a cd /opt/kindergarten/app /opt/kindergarten/venv/bin/python manage.py collectstatic --noinput /opt/kindergarten/venv/bin/python manage.py migrate --noinput /opt/kindergarten/venv/bin/python manage.py init_data7.4 systemd 服务Gunicorn 由 systemd 管理，以 www-data 用户运行，并配置开机自启和异常自动重启：[Service] User=www-data Group=www-data WorkingDirectory=/opt/kindergarten/app EnvironmentFile=/etc/kindergarten.env ExecStart=/opt/kindergarten/venv/bin/gunicorn \ kindergarten.wsgi:application \ --bind 0.0.0.0:80 \ --workers 2 \ --timeout 120 Restart=always RestartSec=3 启动服务：systemctl daemon-reload systemctl enable --now kindergarten systemctl status kindergarten --no-pager7.5 部署验证公网首页请求返回 HTTP 200，响应服务器为 Gunicorn。健康检查结果如下：GET http://121.36.40.212/health/ {"status":"ok"}八、部署问题与解决方案8.1 Docker Hub 基础镜像下载超时最初计划使用 Docker 部署，但 ECS 拉取 python:3.12-slim 时访问 Docker Hub 超时：failed to resolve reference "docker.io/library/python:3.12-slim" dial tcp ...:443: i/o timeout项目源码和部署文件均未受影响。考虑到训练营演示环境只有 1 GiB 内存，最终改用：主机 Python + venv + Gunicorn + systemd + SQLite这种方案依赖更少、资源占用较低，同时具备开机自启和异常恢复能力。项目仍保留 Dockerfile 和 Kubernetes 部署清单，后续可以将基础镜像同步到华为云 SWR 后恢复容器化部署。8.2 生产环境安全配置部署时进行了以下处理：DEBUG=False；SECRET_KEY 仅保存在服务器环境变量文件中；使用 ALLOWED_HOSTS 限制请求主机；使用 WhiteNoise 提供静态文件；Gunicorn 以非 root 用户运行；安全组开放 Web 访问端口，SSH 仅用于服务器管理；/health/ 只返回服务状态，不暴露业务数据；管理员密码不写入源码和帖子。九、总结通过华为云码道（CodeArts）代码智能体，本项目完成了从自然语言需求到可部署系统的完整闭环：业务需求被拆分为清晰的数据模型和 API；核心规则在前后端和自动化测试中得到多重保障；90 名儿童、9 个班级和 4 门课程的数据能够正确初始化；学籍、食谱、课程、调班和双向查询均可在统一界面中完成；系统已经部署到华为云 ECS，并通过公网访问和健康检查验证。本案例不仅展示了 AI 辅助编码，也记录了测试、部署失败恢复和生产配置过程。对于高校课程设计和中小型管理系统，华为云码道可以显著缩短从需求到上线的路径。

食评智管——校园食堂菜品评价管理系统基于华为云码道（CodeArts）代码智能体的应用构建实践 摘要本实验围绕训练营应用构建任务，使用华为云码道（CodeArts）代码智能体完成“食评智管——校园食堂菜品评价管理系统”的需求分析、数据库设计、代码生成、运行验证、代码审查和文档整理。系统采用 Node.js 与 Express 构建服务端，使用 EJS 完成服务端页面渲染，使用 Node.js 内置 node:sqlite 管理本地 SQLite 数据库，并通过 Bootstrap 提供基础响应式界面。普通用户无需注册即可浏览与搜索菜品、查看菜品详情、提交 1 至 5 分评分和文字评价；管理员通过固定演示账号登录后台，完成菜品新增、修改、删除和评价记录查看。项目启动时自动创建数据库、数据表和演示数据，使用参数化 SQL 进行数据访问，并通过 Session 中间件完成后台访问控制。测试覆盖主要页面、搜索、评价提交、平均分计算、管理员登录、菜品增删改查、数据库初始化以及异常页面等场景。初始化数据包含 8 条菜品、8 条评价和 1 个管理员；人工测试与视频演示后，当前数据库记录为 9 条菜品和 11 条评价。测试范围内未发现影响演示和提交的严重问题，项目达到最小可交付、可运行、可验证和可演示状态。关键词：华为云码道；Node.js；Express；EJS；SQLite；校园食堂；菜品评价目录1 实验任务与目标2 需求分析3 开发环境与技术选型4 系统总体设计5 数据库设计6 系统功能实现7 使用华为云码道完成应用构建8 实践验证与测试9 核心技术难点与解决思路10 项目不足与改进方向11 实验总结附录 A 项目运行说明附录 B 截图插入清单1 实验任务与目标1.1 实验任务本实验的任务是尽快完成应用构建选题并进行实践验证，使用华为云码道（CodeArts）代码智能体参与需求分析、代码开发、调试与测试，同时形成可发布的应用构建案例文档和演示材料。训练营成果要求强调系统架构、码道辅助开发过程、解决方案、核心技术难点和运行效果，因此本项目采用“小而完整”的最小可行产品路线，优先确保功能闭环、可运行、可演示和过程留痕。1.2 选题说明项目选题为“校园食堂菜品评价管理系统”。该选题业务边界明确、数据关系简单，能够在较短时间内完成菜品信息维护、搜索、评分、评价和后台管理等完整功能，同时便于使用码道进行需求拆解、代码生成、测试验证和文档整理。1.3 实验目标使用码道完成需求分析、设计、代码生成、测试与文档整理，并保留真实使用记录。实现普通用户浏览、搜索、查看详情、评分和文字评价等功能。实现管理员登录、菜品增删改查和评价记录查看等功能。使用 SQLite 自动初始化数据表和演示数据，降低运行与部署复杂度。通过自动路由测试和人工操作验证核心功能，形成测试与验收记录。生成可提交的实验报告、演示视频和代码仓库材料。图 1 码道登录与项目工作区2 需求分析2.1 用户角色角色使用方式核心权限普通用户无需注册登录浏览与搜索菜品、查看详情、提交评分与文字评价、查看历史评价管理员使用固定演示账号登录查看后台菜品列表、新增/修改/删除菜品、查看全部评价记录2.2 功能需求编号模块功能说明U1菜品列表显示图片、名称、原材料、价格、分类、平均分和评价数量U2菜品搜索按菜品名称进行模糊搜索，并支持清除搜索条件U3菜品详情显示完整菜品信息、平均分和历史评价U4评价提交填写评价人姓名，选择 1 至 5 分并输入文字评价A1管理员登录使用 admin/admin123 进入管理后台A2菜品管理完成菜品新增、编辑、删除与列表查询A3评价管理查看菜品、评价人、评分、评价内容和时间2.3 非功能需求Windows 环境下通过 npm install 和 npm start 运行。数据库文件、数据表和演示数据在首次启动时自动创建。主要输入字段具有基础校验，异常情况显示中文提示页面。页面使用 Bootstrap 布局，支持常见桌面浏览器访问。系统定位为训练营最小可行演示系统，不作为生产环境应用。2.4 需求边界为控制项目范围，本次不实现普通用户注册、图片文件上传、支付、短信、大模型 API、复杂 RBAC、前后端分离、Docker 和外部数据库。菜品图片采用 URL 字段；未填写或加载失败时显示本地默认 SVG 图片。图 2 码道生成并修正需求文档3 开发环境与技术选型3.1 开发环境项目配置操作系统WindowsNode.jsv24.18.0npm11.16.0开发工具华为云码道（CodeArts）代码智能体 Web IDE浏览器本地浏览器访问 http://localhost:3000数据库SQLite（Node.js 内置 node:sqlite / DatabaseSync）图 3 Node.js 与 npm 环境检查3.2 技术选型技术用途选型理由Node.js应用运行环境安装简单，与码道生成的 JavaScript 项目配合直接ExpressWeb 服务与路由结构轻量，适合小型 CRUD 应用EJS服务端模板渲染不需要单独构建前端项目，降低复杂度Bootstrap 5页面布局与组件通过 CDN 快速获得基础界面node:sqlite数据库访问Node.js 内置模块，无需安装原生数据库依赖express-session管理员会话用少量代码实现后台访问控制dotenv环境变量加载将端口和 Session 密钥与代码分离3.3 项目结构项目目录结构canteen-review/├─ app.js├─ db.js├─ package.json├─ package-lock.json├─ README.md├─ .env.example├─ public/│ ├─ css/style.css│ └─ images/default-dish.svg├─ views/│ ├─ index.ejs│ ├─ dish-detail.ejs│ ├─ error.ejs│ ├─ partials/│ └─ admin/├─ data/└─ docs/图 4 项目文件结构4 系统总体设计4.1 总体架构系统采用单体 Web 应用架构。浏览器向 Express 服务发送 HTTP 请求；Express 根据路由完成参数校验和业务处理；EJS 将查询结果渲染为 HTML 页面；SQLite 保存菜品、评价和管理员数据。静态样式和默认图片由 Express 静态目录提供。系统逻辑架构浏览器│ HTTP 请求 / 表单提交▼Express 路由与中间件├─ EJS 页面渲染├─ Session 管理员鉴权└─ 参数校验与错误处理│ 参数化 SQL▼SQLite 数据库(dishes / reviews / admins)4.2 普通用户业务流程访问首页 → 浏览菜品列表├─ 输入关键词 → 模糊搜索 → 查看结果└─ 点击菜品 → 查看详情与历史评价↓填写姓名、评分和评价↓校验并写入数据库↓重定向详情页并更新平均分4.3 管理员业务流程访问管理后台 → 登录验证├─ 验证失败 → 返回登录页并提示└─ 验证成功 → 写入 Session↓菜品列表 / 新增 / 编辑 / 删除 / 评价查看↓退出并销毁 Session4.4 页面与路由方法路由功能GET/首页与菜品名称搜索GET/dishes/:id菜品详情与历史评价POST/dishes/:id/reviews提交评价GET/POST/admin/login管理员登录页面与验证GET/admin/logout退出登录GET/admin/dishes后台菜品列表GET/POST/admin/dishes/new、/admin/dishes新增菜品GET/POST/admin/dishes/:id/edit、/admin/dishes/:id编辑菜品POST/admin/dishes/:id/delete删除菜品GET/admin/reviews评价记录列表5 数据库设计5.1 数据表关系数据库包含 dishes、reviews 和 admins 三张表。一个菜品可以对应多条评价；reviews.dish_id 通过外键关联 dishes.id，并设置 ON DELETE CASCADE，使管理员删除菜品时关联评价能够同步删除。管理员表用于保存固定演示账号。5.2 dishes 表字段类型/约束说明idINTEGER PRIMARY KEY AUTOINCREMENT菜品主键nameTEXT NOT NULL菜品名称ingredientsTEXT NOT NULL原材料priceREAL NOT NULL CHECK(price >= 0)价格image_urlTEXT DEFAULT NULL图片地址descriptionTEXT DEFAULT ''菜品描述categoryTEXT DEFAULT ''分类created_atDATETIME DEFAULT CURRENT_TIMESTAMP创建时间updated_atDATETIME DEFAULT CURRENT_TIMESTAMP更新时间5.3 reviews 表字段类型/约束说明idINTEGER PRIMARY KEY AUTOINCREMENT评价主键dish_idINTEGER NOT NULL, FOREIGN KEY关联菜品reviewer_nameTEXT NOT NULL评价人姓名ratingINTEGER CHECK(1~5)评分commentTEXT DEFAULT ''评价内容created_atDATETIME DEFAULT CURRENT_TIMESTAMP评价时间5.4 admins 表字段类型/约束说明idINTEGER PRIMARY KEY AUTOINCREMENT管理员主键usernameTEXT NOT NULL UNIQUE管理员用户名passwordTEXT NOT NULL演示密码，当前为明文存储5.5 数据库自动初始化getDb() 在首次调用时创建 data 目录并打开 canteen.db，启用 WAL 日志模式和外键约束。initDb() 使用 CREATE TABLE IF NOT EXISTS 建表，并在管理员表或菜品表为空时插入演示数据，从而避免每次重启重复插入。数据库初始化关键代码db = new DatabaseSync(DB_PATH);db.exec('PRAGMA journal_mode=WAL');db.exec('PRAGMA foreign_keys=ON');const dishCount = db.prepare('SELECT COUNT(*) AS cnt FROM dishes').get();if (dishCount.cnt === 0) {// 插入演示菜品与评价}数据状态：首次初始化插入 8 条菜品、8 条评价和 1 个管理员；完成当前人工测试与视频演示后，数据库记录为 9 条菜品和 11 条评价。6 系统功能实现6.1 菜品列表与模糊搜索首页读取查询参数 q。存在关键词时，通过 WHERE d.name LIKE ? 进行包含匹配；不存在关键词时返回全部菜品。查询同时使用 LEFT JOIN、AVG 和 COUNT 计算平均分和评价数量，保证无评价菜品仍能显示。菜品搜索与评分聚合const keyword = (req.query.q || '').trim();dishes = db.prepare("SELECT d.*, COALESCE(AVG(r.rating), 0) AS avg_rating, " +"COUNT(r.id) AS review_count FROM dishes d " +"LEFT JOIN reviews r ON d.id = r.dish_id " +"WHERE d.name LIKE ? GROUP BY d.id").all(`%${keyword}%`);图 5 系统首页图 6 菜品名称搜索结果6.2 菜品详情与评价提交详情路由根据菜品 ID 查询菜品信息、平均分与评价数量，再按时间倒序读取历史评价。评价提交路由先确认菜品存在，然后校验评价人姓名和评分范围，校验通过后通过参数化 INSERT 写入数据库并重定向回详情页。平均分在页面查询时实时计算，因此新增评价后自动更新。评价提交关键代码const ratingNum = parseInt(rating, 10);if (!reviewer_name || !reviewer_name.trim()) {errors.push('评价人姓名不能为空');}if (!rating || isNaN(ratingNum) || ratingNum < 1 || ratingNum > 5) {errors.push('评分必须是1到5的整数');}db.prepare('INSERT INTO reviews (dish_id, reviewer_name, rating, comment) ' +'VALUES (?, ?, ?, ?)').run(dishId, reviewer_name.trim(), ratingNum, (comment || '').trim());图 7 菜品详情与评价提交6.3 管理员登录与访问控制管理员提交用户名和密码后，系统使用参数化 SQL 查询 admins 表。验证成功时将 adminId 和 adminName 写入 Session。requireAdmin 中间件检查 Session，未登录访问管理页面时重定向到登录页；退出登录时销毁 Session。管理员鉴权中间件function requireAdmin(req, res, next) {if (!(req.session && req.session.adminId)) {return res.redirect('/admin/login');}next();}图 8 管理员登录页面6.4 菜品增删改查管理员后台显示菜品 ID、图片、名称、原材料、价格、分类、平均分和评价数。新增与编辑操作对名称、原材料和价格进行后端校验；删除操作使用参数化 DELETE，并依赖外键级联删除关联评价。图片地址留空时，模板使用 /images/default-dish.svg。图 9 后台菜品管理列表图 10 新增菜品表单图 11 新增菜品后的后台列表6.5 评价记录管理评价管理页面通过 LEFT JOIN 查询评价与菜品名称，并按评价时间倒序展示。管理员可以查看评价 ID、菜品、评价人、星级、评价内容和时间，为后续食堂菜品改进提供数据基础。图 12 后台评价记录7 使用华为云码道完成应用构建7.1 需求分析与选题细化在码道 Vibe-Coding 模式中，首先输入项目目标、技术栈、普通用户和管理员功能，并要求智能体只生成需求与设计文档而不立即编写代码。生成初稿后，根据原选题对品名、原材料、照片和价格的要求，继续让码道补充 ingredients、price 和 image_url 字段，并同步修改功能清单、数据表、页面和验收标准。7.2 任务拆解与项目文件生成码道将开发工作拆解为基础文件、数据库模块、主应用、静态资源、前台视图、后台视图、公共模板、README 和运行验证等 9 项待办。经授权后，智能体在当前项目目录中生成 package.json、app.js、db.js、EJS 页面和样式文件，并执行 npm install 与 npm start。图 13 码道开发任务清单图 14 码道批量生成项目文件7.3 自动运行与路由验证项目启动后，码道通过 PowerShell Invoke-WebRequest 对首页、详情页、管理员登录、后台拦截、搜索和错误页面进行 HTTP 状态验证，同时测试正确管理员账号的登录重定向。自动验证结果显示主要路由均达到预期状态码。7.4 测试与文档生成在完成人工功能操作后，继续让码道读取 app.js 和 db.js，生成测试与验收记录、核心代码说明和代码审查记录。这样既保留了智能体参与开发全过程的证据，也为最终案例文档提供了结构化材料。图 15 码道生成测试与验收记录7.5 使用过程留痕保留需求分析、需求修订、任务清单、文件变更和自动测试截图。保留码道历史会话，避免修改项目文件夹名称导致记录难以对应。在码道个人用量页面保存 Token 用量、请求次数和活跃记录截图。在费用中心保存专业版、代金券余额或抵扣记录截图。图 16 码道个人用量与活跃记录图 17 专业版使用记录8 实践验证与测试8.1 测试方法项目采用自动路由测试与人工功能测试相结合的方法。自动测试用于快速确认 HTTP 状态码、搜索内容和登录重定向；人工测试用于验证页面展示、表单交互、评价持久化、平均分变化、管理员增删改查和退出登录等可视化行为。8.2 自动路由测试路由预期实际结果GET /200200通过GET /dishes/1200200通过GET /admin/login200200通过GET /admin/dishes（未登录）302302通过GET /admin/reviews（未登录）302302通过GET /?q=红烧200 且包含红烧肉符合通过GET /dishes/9999404404通过POST /admin/login（正确账号）302 到 /admin/dishes符合通过8.3 普通用户功能测试用例测试内容结果TU-01首页展示菜品图片、名称、原材料、价格、分类和平均分通过TU-02搜索“红烧”仅返回红烧肉通过TU-03菜品详情与历史评价显示通过TU-04提交姓名、1~5 分和文字评价通过TU-05评价后平均分更新且刷新后数据仍存在通过TU-06姓名为空、评分未选时显示错误提示通过TU-07不存在菜品显示 404 友好页面通过8.4 管理员功能测试用例测试内容结果TA-01正确与错误管理员账号登录通过TA-02未登录访问后台被重定向通过TA-03新增菜品及字段校验通过TA-04修改菜品信息通过TA-05删除菜品与确认提示通过TA-06查看全部评价记录通过TA-07退出登录后需重新登录通过TA-08图片 URL 留空时显示默认图片通过8.5 数据库初始化验证验证项初始化预期当前状态结果dishes8 条演示菜品9 条，含人工测试新增 1 条通过reviews8 条演示评价11 条，含人工测试与视频演示新增 3 条通过admins1 个 admin/admin123存在通过重复启动不重复插入初始化数据数据不翻倍通过外键级联删除菜品同步删除评价符合预期通过8.6 验收结论本轮测试覆盖了普通用户菜品浏览、搜索、详情查看、评分评价，以及管理员登录、菜品增删改查和评价查看等核心功能。测试范围内各项用例均达到预期结果，未发现影响演示和提交的严重问题。项目已达到最小可交付、可运行、可验证和可演示状态，本轮验收通过。9 核心技术难点与解决思路9.1 兼容性与依赖安装最初需要确保本地 Node.js 环境能够被码道终端识别。安装 Node.js LTS/稳定版本并重新打开浏览器工作区后，node -v 与 npm -v 正常返回。数据库层选择 Node.js 内置 node:sqlite，避免 sqlite3 或 better-sqlite3 在 Windows 下可能出现的原生编译依赖问题。9.2 数据库首次初始化与重复启动数据库目录和文件需要在首次运行时自动创建，同时避免每次启动重复插入演示数据。解决方式是使用 fs.existsSync 创建 data 目录，CREATE TABLE IF NOT EXISTS 建表，并通过 COUNT(*) 判断表是否为空后再插入初始数据。9.3 平均评分与无评价菜品显示菜品列表既要显示有评价菜品的平均分，也要保留无评价菜品。系统使用 LEFT JOIN 保留全部菜品，用 AVG 计算评分，并使用 COALESCE 将无评价时的 NULL 转为 0，再由 EJS 根据 review_count 显示具体分数或“暂无评分”。9.4 管理后台访问控制后台页面不能被未登录用户直接访问。系统使用 express-session 保存管理员 ID，并将 requireAdmin 中间件加入所有后台查询和写入路由。未登录请求被重定向到登录页，退出时销毁 Session。9.5 输入校验与错误处理系统在前端表单 required、数值 min 属性之外，仍在服务端检查姓名、菜品名称、原材料、评分和价格，并通过 SQLite CHECK 约束提供第二层保护。不存在的菜品返回 404 页面，未处理异常由全局错误中间件返回 500 页面。9.6 代码审查与改进码道代码审查重点检查路由、参数化 SQL、Session 鉴权、异常处理和模板输入回显。审查后对搜索框及菜品表单的特殊字符回显进行了处理，并重新验证主要路由。需要说明的是，当前项目定位为训练营 MVP，代码审查结论仅代表本轮测试范围，不等同于生产级安全审计。10 项目不足与改进方向当前不足影响后续改进管理员密码明文存储不适用于真实系统使用 bcrypt 等算法保存密码哈希Session 使用默认内存存储服务重启后会话丢失，不适合多实例使用 Redis 等持久化 Session Store缺少 CSRF 防护与登录限流生产环境存在请求伪造和暴力尝试风险增加 CSRF Token、限流和安全响应头评分使用 parseInt 解析类似 4.5 的字符串可能被解析为 4使用 Number() 与 Number.isInteger() 严格校验Bootstrap 通过 CDN 引用断网时页面样式可能不完整将静态依赖下载到项目 public 目录普通用户无需登录无法限制重复评价或查看个人记录增加用户账号与“每人每菜一次”规则图片仅支持 URL外部图片失效时体验受影响增加对象存储上传和图片审核没有自动化单元测试回归验证主要依赖路由脚本和人工测试引入 node:test 或 Jest/SupertestSQLite 适合单机演示并发和扩展能力有限部署版可迁移到云数据库 MySQL/PostgreSQL10.1 可扩展功能增加评价关键词统计和满意度趋势图。结合大模型生成“高频问题、顾客满意点、改进建议”摘要。增加菜品分类筛选、价格区间筛选和排行榜。部署到华为云服务器，并使用 Nginx 与 PM2 保持服务运行。将图片保存到华为云对象存储，减少外链图片失效问题。11 实验总结本实验以完成训练营任务为目标，选择业务边界清晰的校园食堂菜品评价场景，利用华为云码道完成了从需求分析、数据库设计到代码生成、运行验证、代码审查和文档整理的完整过程。项目采用单体 Node.js 架构，功能覆盖普通用户菜品浏览、搜索、评价与平均分展示，以及管理员登录、菜品增删改查和评价记录查看。SQLite 自动初始化方案减少了数据库安装和部署成本，使项目能够通过 npm install 与 npm start 快速运行。通过本次实践，可以看到代码智能体不仅能够生成代码，还能够用于任务拆解、文件创建、错误排查、路由测试、代码解释和文档编写。与此同时，智能体输出仍需要人工确认目录范围、命令安全性、测试真实性和技术表述准确性。最终项目已达到最小可交付状态，后续工作重点是补齐截图、上传 GitCode、录制演示视频、发布案例文章并完成课程和考试要求。 

一、案例基本信息案例名称：智能论文投稿与审稿助手应用类型：面向高校学报、小型期刊编辑部的论文投稿预审、审稿人推荐与审稿辅助 Web 应用公网演示地址：http://114.116.247.53项目仓库地址：https://gitcode.com/Twumu7/manuscript-review-assistant.git核心技术栈：前端：Vue 3、TypeScript、Vite、Element Plus、Vue Router、Pinia、Axios后端：Python、FastAPI、SQLAlchemy、Pydantic v2、SQLite、python-docx、pdfplumber、bcrypt、pytest部署：华为云 ECS 实例、Docker Compose、Nginx、SQLite 数据卷AI coding 工具：华为云码道 CodeArts 代码智能体、项目级 Skill、自定义业务规则文档、对话式开发与调试本案例围绕“期刊投稿管理系统”这一传统管理系统选题展开，但没有停留在普通的增删改查，而是将论文投稿场景中的“稿件预审、栏目判断、审稿人匹配、审稿辅助、意见汇总、状态流转”拆解为一组可测试、可解释、可演示的智能业务能力。系统的目标不是替代编辑或审稿人做学术判断，而是通过智能体辅助完成规范检查、信息整理、候选推荐和流程自动化，从而降低编辑部的重复劳动成本。二、场景背景与痛点分析在高校学报或小型期刊编辑部中，论文投稿流程通常包含作者投稿、编辑初审、格式预审、栏目判断、审稿人遴选、审稿意见收集、修改或录用决策等环节。传统系统往往只提供稿件上传、状态管理和审稿意见填写功能，真正耗费编辑精力的部分仍需人工完成。典型痛点包括：投稿格式预审重复且细碎编辑需要检查标题、摘要、关键词、章节完整性、参考文献、匿名要求等规范。规则本身并不复杂，但检查项多、容易遗漏，且每篇稿件都要重复执行。栏目判断依赖编辑经验对跨学科稿件，编辑需要根据标题、摘要和关键词判断其更适合工学版、理学版、文科版还是生物医学版。该判断需要可解释依据，不能只给出一个结论。审稿人推荐需要兼顾匹配度与回避规则审稿人选择不仅要看研究方向和关键词，还要排除同单位、作者指定回避、不接收新任务、当前工作负载已满等情况。如果系统只做简单关键词匹配，容易推荐不合适甚至存在利益冲突的人选。审稿意见整理耗时审稿人填写的意见可能是零散笔记，编辑还需要从多份意见中提取共同问题、意见分歧、主要问题和次要问题。流程状态和权限边界容易混乱作者、编辑、审稿人三类角色对稿件和审稿信息的访问权限不同。若只在前端隐藏按钮而后端不做校验，就存在越权访问风险。因此，本项目的建设目标是：构建一个可运行、可测试的投稿审稿辅助系统，将确定性规则沉淀为代码，将智能辅助限定在“形式检查、推荐解释、意见整理”范围内，并通过华为云码道 CodeArts 代码智能体完成从规则文档、Skill、代码、测试到部署的完整开发闭环。三、功能边界设计本项目在立项时采用“完整 V1，一次交付”的策略。也就是说，产品版本上不再拆分 MVP 和二期版本，但工程实现仍按文档、后端、前端、测试、部署分阶段推进。3.1 已实现的核心功能系统包含三类用户角色：作者：创建投稿、上传 DOCX/PDF、查看本人稿件、查看预审报告、上传修改稿、查看通知。编辑：查看全部稿件、重新执行预审、确认栏目、查看审稿人推荐、分配审稿任务、查看意见汇总、作出最终决定、查看统计看板和审计日志。审稿人：查看分配给自己的任务、接受或拒绝任务、使用审稿辅助、保存草稿、提交审稿意见。核心功能包括：用户登录与注册，支持作者和审稿人自助注册，编辑账号由演示数据预置。DOCX/PDF 稿件上传，校验扩展名、MIME 类型和文件大小。DOCX 结构化解析，提取标题、摘要、关键词、章节、参考文献等信息。投稿规范预审，覆盖 M-001 至 M-014 共 14 条规则。栏目推荐，从工学版、理学版、文科版、生物医学版中给出推荐和备选栏目。审稿人推荐，输出排除原因、分项得分、综合得分、推荐理由和风险提示。审稿任务管理，支持分配、接受、拒绝、取消、超期标识。审稿辅助，生成检查清单并整理审稿笔记，但不自动提交正式意见。多审稿意见汇总，提取共同意见、分歧、主要问题和次要问题，并保留来源追溯。投稿状态流转和审计日志。站内通知。编辑统计看板。本地相似稿件检索，限定在系统已有稿件范围内，不等同于论文查重。3.2 明确不实现的功能为了避免项目范围失控，也为了避免学术伦理和责任边界问题，系统明确不实现以下能力：不做真正的论文查重。不自动识别抄袭。不判断论文创新性。不判断实验数据真实性。不自动录用或自动退稿。不生成整篇论文。不支持扫描 PDF OCR。不处理复杂公式识别。不做正式出版排版和版面费结算。不接入真实高校统一身份认证。不使用真实 SMTP、短信服务、Redis、消息队列、微服务、向量数据库或 Elasticsearch。边界设计对于基于智能体的应用开发非常关键。智能体的价值不是“替人做决定”，而是将重复性、规则性、信息整理型任务变得更高效，并且让每一个辅助结论都有依据可查。四、系统架构设计4.1 总体架构系统采用单体前后端分离架构。前端为 Vue 3 SPA，后端为 FastAPI 单体服务，数据库使用 SQLite，上传文件存储在本地文件系统或部署环境中的 Docker 数据卷。生产部署时，Nginx 提供静态文件服务并反向代理后端 API。该架构的特点是部署简单、依赖少、便于演示。系统没有引入微服务和中间件，避免为了展示复杂技术而牺牲可运行性。4.2 前端架构前端采用 Vue 3 + TypeScript + Vite。页面按角色划分：作者端：投稿创建、稿件列表、稿件详情、修改稿上传。编辑端：稿件管理、预审报告、栏目确认、审稿人推荐、意见汇总、最终决定、统计看板、审计日志。审稿人端：任务列表、审稿辅助、审稿表单。公共页面：登录、注册、站内通知。4.3 后端架构后端采用 FastAPI + SQLAlchemy + Pydantic，按如下层次组织：routers/：API 路由层，负责接收请求、调用服务、返回响应。services/：业务服务层，负责业务编排、事务处理、调用领域规则。domain/：领域规则层，包含预审规则、审稿人推荐规则、栏目规则、工作流规则、通知规则等纯函数。models/：SQLAlchemy ORM 模型。schemas/：Pydantic 请求和响应模型。utils/：文本差异等工具函数。核心服务包括：ParseService：解析 DOCX/PDF。PrecheckService：执行投稿预审并保存报告。SectionService：执行栏目推荐。ReviewerMatchService：执行审稿人排除和评分。WorkflowService：执行状态流转校验。ReviewAssistService：生成审稿辅助内容。ReviewSummaryService：汇总多份审稿意见。NotificationService：生成和查询站内通知。StatisticsService：生成编辑统计看板。AuditLogService：记录关键操作。4.4 数据模型设计系统主要数据对象包括：用户 users审稿人档案 reviewer_profiles稿件 manuscripts稿件文件版本 manuscript_files预审报告 precheck_reports审稿任务 review_assignments审稿意见 reviews站内通知 notifications审计日志 audit_logs稿件与文件版本分离，保证原始稿和修改稿不会互相覆盖。审稿任务与审稿意见分离，方便表示“待接受、已接受、已拒绝、已提交、已取消、已超期”等不同任务状态。五、华为云码道 CodeArts 代码智能体辅助开发过程本项目使用华为云码道 CodeArts 代码智能体完成了从规则文档、Skill 创建、规范设计、任务拆分、代码实现、调试验证到公网部署改造的对话式 AI coding 流程。5.1 先文档后编码：让智能体对齐项目边界项目没有一开始就让智能体“直接写完整系统”，而是先通过多轮对话确定功能边界，把选题背景、功能边界、角色权限、投稿规则、审稿人推荐规则、工作流规则、验收标准和测试数据先沉淀为项目文档，生成以下基础资料：docs/project-overview.mddocs/functional-scope.mddocs/roles-and-permissions.mddocs/journal-guidelines.mddocs/reviewer-matching-rules.mddocs/review-checklist.mddocs/workflow-rules.mddocs/notification-rules.mddocs/data-dictionary.mddocs/acceptance-criteria.mddocs/test-strategy.md这些文档起到了“开发协议”的作用。后续每一轮对话都要求智能体先阅读相关文档，再修改代码。这样可以减少 AI coding 常见的范围漂移问题，例如自动加入未计划的功能、把医疗/金融式高风险判断写进系统、或在前端页面中硬编码业务规则。同时，还生成了 sample-data/ 下的虚构用户、审稿人、稿件、审稿任务、审稿意见、通知、审计日志和预期结果数据，并通过脚本生成 DOCX 测试稿件。这样，后续实现预审、推荐和工作流时可以直接用样例数据验证规则是否一致。示例对话：你是“智能论文投稿与审稿助手”项目的需求分析和规则建模智能体。 项目背景： 本项目用于华为云码道训练营案例，原始选题为“期刊投稿管理系统”。 请将其改造为面向高校学报或小型期刊编辑部的智能投稿预审、 审稿人推荐与审稿辅助系统。 当前阶段只生成项目文档和虚构测试数据，不初始化前端项目， 不初始化后端项目，不编写业务代码。 请完成： 1. 创建 docs/project-overview.md，说明项目背景、目标用户、核心价值和项目假设； 2. 创建 docs/functional-scope.md，明确 V1 功能范围和不实现功能； 3. 创建 docs/roles-and-permissions.md，定义作者、编辑、审稿人的权限矩阵； 4. 创建 docs/journal-guidelines.md，定义可测试的投稿规范规则； 5. 创建 docs/reviewer-matching-rules.md，定义审稿人排除规则、评分规则和最低推荐阈值； 6. 创建 docs/review-checklist.md，定义审稿检查清单； 7. 创建 docs/workflow-rules.md，定义稿件状态、合法流转和非法流转； 8. 创建 docs/notification-rules.md，定义站内通知触发规则； 9. 创建 docs/data-dictionary.md，定义核心数据对象和字段； 10. 创建 docs/acceptance-criteria.md，使用 Given-When-Then 编写验收标准； 11. 创建 docs/test-strategy.md，定义后续单元测试、接口测试和端到端测试策略； 12. 创建 sample-data/ 下的虚构 JSON 数据和 expected-results.json； 13. 创建脚本生成 DOCX 测试稿件； 14. 验证所有 JSON 可解析、DOCX 可打开、预期结果与规则编号一致。 重要边界： - 预审只检查形式规范，不判断创新性、实验真实性或是否应录用； - 审稿人推荐只提供辅助建议，最终由编辑确认； - 不实现真正论文查重、自动录用、自动退稿、自动生成论文； - 不使用真实作者、真实单位、真实论文或真实审稿意见； - 所有规则必须明确、可测试，避免“适当”“合理”等模糊表述。文档和样例数据生成后，再通过第二轮对话让码道智能体进行自查和边界校准：请阅读刚生成的 docs/ 目录和 sample-data/ 目录。 本轮只审查，不编写业务代码。 请检查： 1. docs/project-overview.md、functional-scope.md 与 acceptance-criteria.md 是否范围一致； 2. journal-guidelines.md 中的规则是否都有编号、严重程度和可测试标准； 3. reviewer-matching-rules.md 是否明确 same_affiliation、 author_requested_exclusion、not_accepting_new_tasks、workload_limit_reached； 4. workflow-rules.md 中的状态流转是否覆盖作者投稿、编辑送审、 审稿人提交意见、编辑最终决定和作者提交修改稿； 5. sample-data 中的用户、稿件、审稿人、任务、通知和日志是否引用完整； 6. expected-results.json 是否能对应投稿预审、栏目推荐、审稿人推荐和工作流预期； 7. 是否出现了范围外功能，例如论文查重、自动录用、真实 SMTP、微服务或向量数据库； 8. 输出问题清单，按严重程度排序。不要修改文件，等待确认。经过这一阶段，项目从“期刊投稿管理系统”被明确收敛为“投稿预审、审稿人推荐与审稿辅助系统”。这些文档起到了“开发协议”的作用：后续创建 Skill、生成 spec/design/tasks、编写后端服务和前端页面时，都要求智能体先读取对应规则文档，再执行当前任务。这样可以减少 AI coding 常见的范围漂移问题，也能保证所有 AI 辅助结果只作为建议，不直接替代编辑或审稿人的决定。5.2 使用 skill-creator 创建项目级 Skill项目中通过对话码道智能体应用 skill-creator 创建了两个核心项目级 Skill：.codeartsdoer/skills/manuscript-precheck/.codeartsdoer/skills/reviewer-matcher/manuscript-precheck 用于指导智能体完成稿件投稿规范预审。它约束预审必须以 docs/journal-guidelines.md 为唯一规则来源，覆盖 M-001 至 M-014，不判断创新性、实验真实性或是否录用。reviewer-matcher 用于指导智能体完成审稿人推荐。它约束推荐过程必须先执行硬性排除，再计算研究方向、关键词、栏目、可用性、历史质量和工作负载得分；同时保留同一审稿人命中的多个排除原因。Skill 的价值不是把最终 Web 应用变成依赖 CodeArts 运行的插件，而是在开发阶段把领域知识固化为可复用的指导包。最终运行时代码则沉淀到：backend/app/domain/precheck_rules.pybackend/app/domain/reviewer_rules.pybackend/app/services/precheck_service.pybackend/app/services/reviewer_match_service.py也就是说，Skill 负责“指导如何开发和验证”，Web 应用负责“独立运行”。对话码道：使用 skill-creator，为当前项目创建项目级 Skill：manuscript-precheck。 Skill 目录必须创建在： .codeartsdoer/skills/manuscript-precheck/ 请先阅读以下文件，不要自行扩展项目范围： - AGENTS.md - docs/functional-scope.md - docs/journal-guidelines.md - docs/acceptance-criteria.md - docs/test-strategy.md - sample-data/expected-results.json - scripts/validate_sample_data.py 【Skill 用途】 该 Skill 用于检查 DOCX 或 PDF 稿件是否符合投稿规范，并输出结构化预审结果。DOCX 支持完整预审，PDF 仅支持文本内容检查，不做精确版式检查。 【触发场景】 当用户要求检查论文格式、投稿规范、稿件完整性、摘要、关键词、章节、参考文献、匿名要求或预审报告时，应使用该 Skill。 【输入】 - 稿件文件路径 - docs/journal-guidelines.md - 可选：sample-data/expected-results.json 【必须遵守的规则】 1. 投稿规范以 docs/journal-guidelines.md 为唯一规则来源。 2. 检查规则必须覆盖 M-001 至 M-014。 3. 输出必须包含严重问题、一般问题、提示、修改建议和总体结论。 4. 总体结论只能说明形式规范是否满足投稿要求。 5. 不判断创新性、实验真实性、学术价值或是否应录用。 6. 不执行论文查重。 7. 不自动修改原始稿件。 8. 不生成或改写论文正文。 9. 不使用真实个人数据。 10. 发现文件损坏、格式不支持或字段缺失时，必须返回可解释错误。 【资源结构要求】 请创建： - SKILL.md - references/journal-guidelines.md - templates/precheck-report.md - scripts/check_manuscript.py 其中 references/journal-guidelines.md 不要复制一套冲突规则，应明确指向项目根目录 docs/journal-guidelines.md 作为来源。若需要摘录，只能摘录规则编号和用途，并声明以 docs 为准。 scripts/check_manuscript.py 应实现可测试的确定性检查，至少支持读取 DOCX 并识别标题、摘要、英文摘要、关键词、必要章节、参考文献和匿名信息暴露。 【验证要求】 创建完成后不要继续开发后端或前端。请只输出： 1. 创建的文件树； 2. SKILL.md 内容摘要； 3. 该 Skill 引用的 docs 文件； 4. 是否存在重复规则或冲突规则； 5. 如何用 sample-data/manuscripts/*.docx 验证； 6. 后续需要人工确认的问题。使用 skill-creator，为当前项目创建项目级 Skill：reviewer-matcher。 Skill 目录必须创建在： .codeartsdoer/skills/reviewer-matcher/ 请先阅读以下文件，不要自行扩展项目范围： - AGENTS.md - docs/functional-scope.md - docs/reviewer-matching-rules.md - docs/roles-and-permissions.md - docs/acceptance-criteria.md - docs/test-strategy.md - sample-data/reviewers.json - sample-data/manuscripts.json - sample-data/expected-results.json - scripts/validate_sample_data.py 【Skill 用途】 该 Skill 用于根据稿件标题、摘要、关键词、目标栏目、作者单位和作者指定回避名单，推荐最多 3 位审稿人，并输出排除原因、分项得分、综合得分、推荐理由和风险提示。 【触发场景】 当用户要求推荐审稿人、解释审稿人匹配度、排除利益冲突审稿人、分析审稿人负载或生成审稿人推荐报告时，应使用该 Skill。 【输入】 - 稿件结构化信息 - 审稿人列表 - docs/reviewer-matching-rules.md 【必须遵守的规则】 1. 审稿人推荐规则以 docs/reviewer-matching-rules.md 为唯一规则来源。 2. 必须先执行硬性排除，再计算得分。 3. 必须排除同单位审稿人。 4. 必须排除作者指定回避审稿人。 5. 必须排除不接收新任务的审稿人。 6. 必须排除达到最大工作负载的审稿人。 7. 同一审稿人命中多个排除条件时，必须保留全部排除原因。 8. 若只能返回一个主排除原因，必须使用 docs/reviewer-matching-rules.md 中定义的优先级。 9. 推荐结果最多返回 3 人。 10. 推荐结果必须包含综合得分、分项得分、推荐理由、排除原因和风险提示。 11. 不得根据性别、年龄、民族、婚育情况等无关属性评分。 12. 不得自动分配审稿任务。 13. 不得虚构审稿人信息。 【资源结构要求】 请创建： - SKILL.md - references/reviewer-matching-rules.md - templates/reviewer-recommendation.json - scripts/match_reviewers.py references/reviewer-matching-rules.md 不要复制一套冲突规则，应明确指向项目根目录 docs/reviewer-matching-rules.md 作为来源。 scripts/match_reviewers.py 应实现确定性评分和排序，可使用 sample-data/reviewers.json 与 sample-data/manuscripts.json 进行本地验证。 【验证要求】 创建完成后不要继续开发后端或前端。请只输出： 1. 创建的文件树； 2. SKILL.md 内容摘要； 3. 该 Skill 引用的 docs 文件； 4. 排除规则与 docs/reviewer-matching-rules.md 是否一致； 5. sample-data/expected-results.json 中每篇稿件的预期审稿人顺序是否可验证； 6. 后续需要人工确认的问题。5.3 通过 spec / design / tasks 进行规范驱动开发在业务规则和 Skill 之后，继续通过码道智能体生成三类关键工程文档：docs/spec.md：需求规格说明，定义功能范围、角色权限、业务流程、验收标准。docs/design.md：技术设计，定义前后端目录、模块职责、数据模型、API、服务层、领域层。docs/tasks.md：编码任务规划，将系统拆分为 T001 至 T060 等可验证任务。对话码道：/sdd-new 请进入“智能论文投稿与审稿助手”的需求规格阶段，只生成 docs/spec.md，不编写前后端代码。 开始前请阅读： - AGENTS.md - docs/project-overview.md - docs/functional-scope.md - docs/roles-and-permissions.md - docs/journal-guidelines.md - docs/reviewer-matching-rules.md - docs/review-checklist.md - docs/workflow-rules.md - docs/notification-rules.md - docs/data-dictionary.md - docs/acceptance-criteria.md - docs/test-strategy.md - sample-data/expected-results.json - .codeartsdoer/skills/manuscript-precheck/SKILL.md - .codeartsdoer/skills/reviewer-matcher/SKILL.md 请生成 docs/spec.md，内容必须包括： 1. 项目目标和用户角色； 2. 完整 V1 功能范围； 3. 明确不实现的功能； 4. 角色权限矩阵； 5. 核心业务流程； 6. 稿件上传、解析、预审、栏目推荐、审稿人推荐、审稿任务、审稿辅助、意见汇总、通知、统计看板、相似稿件检索的需求； 7. 每个核心功能的 Given-When-Then 验收标准； 8. 异常场景和错误响应； 9. 安全边界； 10. 与 sample-data 和 expected-results.json 对应的测试场景。 要求： - 使用中文 Markdown； - 不得扩大 AGENTS.md 和 docs/functional-scope.md 中定义的范围； - 不得加入真实论文查重、自动录用、自动退稿、真实 SMTP、微服务、Redis、消息队列、向量数据库或云服务依赖； - 推荐结果必须包含分项得分、综合得分、推荐理由、排除原因和风险提示； - 当前阶段不要生成代码。/sdd-design 请基于 docs/spec.md 生成 docs/design.md，只做技术设计，不编写代码。 设计必须遵守： - 前端 Vue 3 + TypeScript + Vite + Element Plus； - 后端 FastAPI + SQLAlchemy + Pydantic + SQLite； - 文档解析使用 python-docx，PDF 仅做文本提取； - 业务逻辑放在 services/domain 层，不写在路由函数中； - 后端必须真实校验角色权限； - Web 应用运行时不能依赖码道 Skill 目录，Skill 规则需要沉淀为 backend/app/services 中的应用代码。 docs/design.md 必须包括： 1. 总体架构； 2. 前后端目录结构； 3. 后端模块划分； 4. 数据库表设计； 5. API 设计； 6. 权限校验设计； 7. 文件上传安全设计； 8. 稿件预审服务设计； 9. 审稿人推荐服务设计； 10. 审稿辅助和意见汇总设计； 11. 通知、统计、相似稿件检索设计； 12. 错误处理和事务边界； 13. 测试策略； 14. Skill 规则如何迁移到应用运行时服务。/sdd-tasks 请基于 docs/spec.md 和 docs/design.md 生成 docs/tasks.md，不编写代码。 任务拆分要求： 1. 每个任务必须可独立验证； 2. 每个任务写明输入文件、输出文件、验收命令； 3. 后端任务、前端任务、测试任务、文档任务分组； 4. 每个业务功能都必须有测试； 5. 优先后端领域逻辑和测试，再做前端页面； 6. 不要把任务写成“完成前端”“完成后端”这种大块； 7. 不要加入范围外功能。通过规范驱动的上下文组织方式，后续每次对话都可以围绕一个明确任务展开，例如：请执行 tasks.md 中的 T013：实现预审服务。 开始前阅读 spec.md、design.md 和 journal-guidelines.md。 先补充测试，再实现服务逻辑，最后运行相关测试。 不要修改 T013 以外的业务模块。5.4 多轮编码与调试闭环实际开发中，码道智能体按模块推进，通过多轮编码构建完善系统：后端基础结构和 ORM 模型。领域规则：预审规则、栏目规则、审稿人规则、工作流规则、通知规则。服务层：文件上传、解析、预审、推荐、审稿、通知、统计、相似检索。API 路由：认证、稿件、预审、栏目、审稿人、审稿任务、审稿意见、通知、统计、日志。前端基础：Vite、路由、API service、Pinia store。前端页面：作者、编辑、审稿人各角色页面。测试：pytest、Vitest、Playwright。UI 优化：登录页和注册页改造。部署改造：Docker Compose、Nginx、环境变量、华为云部署文档。每一轮对话基本遵循如下闭环：读取规则文档 → 明确本轮修改范围 → 编写或补充测试 → 实现代码 → 运行测试或构建 → 根据报错修复 → 提交 Git 记录六、核心解决方案6.1 投稿预审方案投稿预审是本项目最核心的智能辅助能力之一。系统将预审拆分为“文件规则”和“稿件内容规则”两部分。文件规则包括：支持 DOCX 和 PDF。校验 MIME 类型。文件大小不超过 10MB。DOCX 执行完整预审。PDF 仅做文本检查，不做精确版式检查。稿件内容规则覆盖 M-001 至 M-014：中文标题必填。中文标题不超过 30 个汉字。中文摘要必填。中文摘要 200 至 500 字。英文摘要必填。关键词 3 至 5 个。正文包含引言、研究方法、结果分析和结论。参考文献章节必填。参考文献不少于 5 条。参考文献编号连续。参考文献不得明显重复。参考文献不得明显缺少年份。匿名稿件不得暴露作者姓名、单位、邮箱或联系电话。不得存在明显空白章节。预审结果分为严重问题、一般问题、提示和修改建议。总体结论只描述形式规范是否满足投稿要求，不判断论文是否创新、实验是否真实或是否应录用。在代码实现上，文档解析由 ParseService 负责，规则判断由 domain/precheck_rules.py 负责，流程编排由 PrecheckService 负责。这样的拆分使得 M-001 至 M-014 可以单独测试，也便于后续调整投稿规范。6.2 栏目推荐方案栏目推荐基于标题、摘要和关键词，将稿件匹配到四个栏目：工学版理学版文科版生物医学版系统不会自动决定最终栏目，而是给编辑提供推荐栏目、备选栏目和推荐理由。编辑可以结合预审报告和实际稿件内容进行确认。这种设计避免了“模型黑箱分类”的问题。即使推荐结果不是最终结论，也能节省编辑初步判断的时间。6.3 审稿人推荐方案审稿人推荐采用“硬性排除 + 分项评分 + 阈值过滤 + 可解释输出”的流程。硬性排除规则包括：审稿人与作者单位相同。审稿人在作者指定回避名单中。审稿人当前不接收新任务。审稿人当前待审数量达到最大工作负载。对未排除的审稿人，系统计算：研究方向语义匹配，满分 40。关键词匹配，满分 25。栏目匹配，满分 15。当前可用性，满分 10。历史审稿质量，满分 10。当前待审任务扣分，每个待审任务扣 5 分。综合得分低于 30 分的审稿人不会被推荐。这样做的原因是，系统不应为了“凑够 3 人”而推荐明显不相关的人选。对于无合适审稿人的情况，系统返回风险提示，建议编辑扩大审稿人池或人工复核。同一审稿人可能同时命中多个排除原因。例如某审稿人既在作者回避名单中，又不接收新任务。系统会保留全部原因，并按规则选择主原因。这能帮助编辑理解完整风险，而不是只看到一个简化标签。6.4 审稿辅助与意见汇总方案审稿辅助主要面向审稿人，提供：研究目标提取。研究方法提取。主要结论提取。审稿检查清单。审稿笔记整理。这里的重点是“辅助草稿”，不是“自动审稿”。系统会根据稿件内容和审稿人笔记生成可编辑草稿，但正式意见必须由审稿人确认后提交。多审稿意见汇总主要面向编辑，提供：共同意见。意见分歧。主要问题。次要问题。来源审稿意见追溯。当审稿意见不足两份时，系统只输出单份摘要，不声称存在共同意见。这一规则看似细小，但能避免系统制造不存在的共识。七、核心技术难点与解决思路7.1 难点一：将自然语言业务规则转为可测试代码论文投稿规范很容易写成自然语言，例如“摘要长度适当”“参考文献格式规范”。但这种表达无法直接测试，也会让智能体实现时产生歧义。解决思路是将业务规则编号化、结构化、可测试化。例如：M-004：中文摘要为 200 至 500 字。M-006：关键词数量为 3 至 5 个。M-010：参考文献编号从 1 开始连续递增。M-013：匿名稿件不得包含作者姓名、单位、邮箱或联系电话。每条规则都有编号、严重程度和可测试标准。这样后端领域函数可以直接对应规则编号，测试用例也可以断言实际触发的问题是否与 expected-results.json 一致。7.2 难点二：审稿人推荐既要可解释又要避免误推荐审稿人推荐不是简单排序问题。系统必须兼顾匹配度、可用性、工作负载和利益冲突。若只根据关键词相似度推荐，可能出现同单位冲突；若只按可用性推荐，又可能推荐研究方向不相关的人。解决方案是建立两段式策略：先执行硬性排除，排除同单位、回避、不接收任务、满载审稿人。再对剩余审稿人计算分项得分，并设置最低相关性阈值。同时，推荐结果必须展示：为什么推荐。每项得分是多少。为什么排除某些审稿人。是否存在推荐不足的风险。这种方式让编辑可以复核推荐逻辑，而不是被动接受一个不可解释的名单。7.3 难点三：公网部署中的网络和依赖问题在部署到华为云服务器时，遇到了一些非常真实的工程问题：服务器默认 apt 源中找不到 docker-compose-plugin。解决方法是添加 Docker CE 源或使用华为云推荐的 Docker 安装方式。Docker 构建时拉取 node:20-alpine、python:3.12-slim、nginx:1.27-alpine 超时。解决方法是配置华为云 SWR 镜像加速器，避免直接访问 Docker Hub。后端 Dockerfile 中 apt-get update 访问 deb.debian.org 过慢。解决方法是删除不必要的 build-essential 安装步骤，优先使用 Python 预编译 wheel。pip 安装依赖时找不到 sqlalchemy>=2.0.0。该问题不是 SQLAlchemy 不存在，而是 pip 无法连接到可用 PyPI 源。解决方法是在 Dockerfile 中配置华为云 PyPI 镜像：ENV PIP_INDEX_URL=https://repo.huaweicloud.com/repository/pypi/simple ENV PIP_TRUSTED_HOST=repo.huaweicloud.com ENV PIP_DEFAULT_TIMEOUT=120 这些问题的处理过程体现了 AI coding 的另一个价值：智能体不仅能写业务代码，也能在部署阶段根据错误日志定位问题来源，并给出最小修改方案。八、测试与验证项目构建过程中持续使用自动化测试和构建命令验证结果。后端测试覆盖：预审规则。审稿人推荐规则。栏目推荐规则。工作流规则。通知规则。文件上传与解析。认证与权限。服务层逻辑。API 集成。数据完整性。前端验证包括：TypeScript 类型检查。Vite 生产构建。Vitest 组件单元测试。Playwright 端到端测试脚本。在部署改造阶段，本地曾执行完整后端测试，结果为：398 passed, 3 warnings前端生产构建也通过：npm run build九、公网部署方案本项目针对华为云 ECS 实例进行了公网演示部署改造。部署采用 Docker Compose 单机方案：frontend 容器：构建 Vue 前端，使用 Nginx 托管静态资源。backend 容器：运行 FastAPI 服务。backend-data 数据卷：保存 SQLite 数据库和上传文件。Nginx：监听 80 端口，将 /api/v1/、/docs、/health 等请求代理到后端。所开放的服务器安全组如下：端口协议来源用途22TCP管理员固定公网 IPSSH 登录80TCP0.0.0.0/0公网访问演示系统443TCP0.0.0.0/0可选 HTTPS十、局限性与可拓展内容当前系统已经能支撑训练营案例展示，但仍有一些局限：预审规则主要是确定性规则，无法覆盖复杂排版细节。PDF 仅做文本提取，不支持扫描件 OCR。审稿人推荐使用本地规则与词表，研究方向扩展后需要维护词表和测试数据。相似稿件检索只在本系统已有稿件中执行，不是论文查重。当前部署采用 SQLite 和单机 Docker Compose，更适合演示环境，不是高并发生产架构。系统未接入真实邮件、短信、统一身份认证和学术数据库。后续可以考虑：增加更精细的参考文献格式检查。支持更多期刊模板。引入可配置的投稿规范管理页面。将研究方向词表改为可维护配置。增加 HTTPS 域名访问。增强 Playwright 公网端到端演示脚本。在保持伦理边界的前提下接入文献元数据查询接口。

完整案例链接地址（附案例全部代码以及系统演示视频，可根据readme.md进行复现）：cid:link_0一、概述1.1 案例介绍本案例基于华为云码道（CodeArts）代码智能体，从零构建"校园资源一体化智能借用系统"。系统融合教室/会议室借用与运动场馆预约，核心创新点包括：半小时粒度可视化预约看板、智能冲突检测与可解释推荐引擎、拥挤度预测与错峰建议、运营决策看板等。全流程使用码道代码智能体完成需求分析、架构设计、编码开发、测试验证，充分展示AI辅助开发的高效实践。1.2 适用对象高校学生及教师团体1.3 案例时间本案例总时长预计180分钟。1.4 案例流程说明：1. 使用码道代码智能体完成需求分析与规格设计（spec.md），定义"做什么"2. 使用码道代码智能体完成架构设计与技术方案（design.md），定义"怎么做"3. 使用码道代码智能体生成编码任务清单（tasks.md），拆解为可执行的开发任务4. 逐步执行编码任务：后端Spring Boot工程搭建、数据库DDL与初始化、RESTful API开发、前端Vue3页面开发5. 使用码道Skill进行代码审查，使用Playwright MCP进行前端自动化测试，使用JUnit 5进行后端单元测试6. 迭代优化：修复数据一致性问题、对系统进一步完善、增强用户交互体验、添加创新功能1.5 资源总览本案例预计花费50元（使用专业版资源）。完成后请及时释放资源，避免产生多余的费用。资源名称规格价格（元）华为云码道（CodeArts）代码智能体通用专业版139元/6000万tokens(套餐)开发者本地环境JDK 17 + Node.js 20 + MySQL 8.4免费Playwright MCPChromium浏览器自动化免费二、环境和资源准备2.1 安装基础开发环境本案例需要以下本地开发环境：工具版本用途JDK17后端Spring Boot运行环境Maven3.9+后端项目构建Node.js20.x前端Vue3运行环境MySQL8.4关系型数据库Git2.x版本控制JDK 17安装验证：java -versionNode.js安装验证：node -vMySQL安装与初始化：mysql -u root -p2.2 配置华为云码道（CodeArts）代码智能体1. 登录华为云码道，开通代码智能体服务2. 在IDE中安装CodeArts插件，配置MCP连接（本案例使用Playwright MCP进行前端自动化测试）3. 创建项目仓库，初始化Git2.3 配置Playwright MCPPlaywright MCP用于前端自动化测试，配置步骤：1. 安装Node.js依赖：npm install -g @anthropic-ai/mcp-server-playwright2. 在.codeartsdoer/mcp/mcp_settings.json中配置MCP：{"mcpServers": {"playwright": {"command": "npx","args": ["@anthropic-ai/mcp-server-playwright"],"env": {}}}}三、构建校园资源智能借用系统3.1 使用码道代码智能体完成需求与设计3.1.1 需求规格设计在码道代码智能体中输入项目描述，自动生成spec.md需求规格文档："开发校园资源一体化智能借用系统，融合教室/会议室借用与运动场馆预约，支持智能冲突检测、可解释推荐引擎、可视化排班看板"码道代码智能体自动生成包含以下内容的需求规格：用户角色定义（学生、教师、管理员）核心功能需求（资源管理、借用申请、冲突检测、推荐引擎、预约看板、数据看板等等）非功能需求（安全性、性能、可用性）接口规范（6组22个RESTful API）3.1.2 架构设计码道代码智能体根据需求规格自动生成design.md技术设计文档：技术栈选型：层次技术选型后端框架Spring Boot 3.2.5 + Spring Security + JWT数据库MySQL 8.4 + JPA/Hibernate缓存Redis（降级为本地锁）前端框架Vue 3 + Vite + Element Plus + ECharts状态管理PiniaHTTP客户端Axios测试框架JUnit 5 + MockMvc + Playwright系统架构：├── campus-booking-server/ // 后端Spring Boot工程│ ├── src/main/java/com/campus/booking/│ │ ├── controller/ // 5个REST控制器│ │ ├── service/impl/ // 9个业务服务│ │ ├── repository/ // 6个JPA仓库│ │ ├── model/ // 实体类+枚举+DTO│ │ └── infrastructure/ // 安全配置+JWT+异常处理│ ├── src/main/resources/│ │ └── application.yml // 应用配置│ ├── sql/ // DDL与初始化数据脚本│ └── docs/ // OpenAPI 3.0接口文档├── campus-booking-web/ // 前端Vue3工程│ ├── src/│ │ ├── views/ // 6个页面组件│ │ ├── api/ // API请求模块│ │ ├── stores/ // Pinia状态管理│ │ ├── router/ // 路由配置│ │ └── utils/ // 工具函数（Axios封装等）│ └── vite.config.js // Vite配置└── .codeartsdoer/ // 码道配置├── specs/ // SDD规格文档└── mcp/ // MCP配置3.1.3 编码任务规划码道代码智能体自动将设计拆解为tasks.md任务清单，按优先级执行：阶段任务说明T0项目初始化Git仓库、DDL脚本、OpenAPI文档T1后端核心Spring Boot工程、实体类、Repository、Service、ControllerT2前端核心Vue3工程、6个页面、路由守卫、API模块T3测试Playwright前端测试、JUnit后端测试T4优化Bug修复、创新功能、用户体验增强3.2 后端开发3.2.1 数据库设计码道代码智能体生成6张核心表+10个索引的DDL脚本：表名用途核心索引设计要点user用户信息uk_username角色分STUDENT/TEACHER/ADMIN，密码用bcrypt哈希resource场地资源idx_type_status统一管理教室/会议室/场馆，equipment_tags存JSON数组fixed_schedule固定占用idx_resource_dow_time按星期几+时段存储课表，与借用冲突检测共用索引booking借用单idx_resource_status_time状态机PENDING→APPROVED/REJECTED→CANCELLED，核心业务表 -- 核心表结构CREATE TABLE resource (...); -- 资源表（教室/会议室/场馆）CREATE TABLE booking (...); -- 借用申请表CREATE TABLE fixed_schedule (...); -- 固定课程占用表CREATE TABLE user_account (...); -- 用户表CREATE TABLE equipment_tag (...); -- 设备标签表CREATE TABLE resource_equipment (...); -- 资源-设备关联表索引设计要点：idx_resource_status_time是冲突检测的核心索引，查询"某资源在某时段是否有活跃借用"时可直接命中索引，避免全表扫描。idx_resource_dow_time同理，用于固定占用冲突查询。这两个索引是系统在大量数据下仍能快速响应的关键。初始化数据包含8个用户、20个资源（13教室+3会议室+3场馆）、13条固定课程占用。3.2.2 核心Service实现3.2.2.1 冲突检测服务（ConflictCheckService）：冲突检测是本系统最核心的算法，需要同时检查固定占用（课表等周期性占用）和临时借用两种冲突来源。以下是核心实现逻辑：//冲突检测核心：时间区间重叠判断// 数学条件：start1 < end2 AND end1 > start2// 即两个时间段只要有任何重叠，就判定为冲突public Map<String, Object> checkConflict(Long resourceId,LocalDateTime startTime, LocalDateTime endTime) {List<Map<String, Object>> conflicts = new ArrayList<>();// 第一步：检查固定占用冲突（课表等周期性占用）// 将日期转为星期几，与fixed_schedule的day_of_week匹配conflicts.addAll(checkFixedScheduleConflict(resourceId, startTime, endTime));// 第二步：检查临时借用冲突（PENDING和APPROVED状态的借用）conflicts.addAll(checkBookingConflict(resourceId, startTime, endTime));return Map.of("hasConflict", !conflicts.isEmpty(), "conflicts", conflicts);}算法解析：冲突检测的核心是时间区间重叠判断，数学条件为start1 < end2 AND end1 > start2。这个条件的含义是：如果时段A的开始时间在时段B结束之前，且时段A的结束时间在时段B开始之后，则两个时段存在重叠。两个数据源（固定占用和临时借用）统一使用相同的重叠判断逻辑，确保看板展示、可用查询、提交校验三者口径一致，这是解决"占用+可用≠总数"Bug的根本方法。为什么用分钟级精度而非小时级：如果只取整点小时来判断，"10:30-11:30"的借用会被错误地匹配到"10:00-11:00"和"11:00-12:00"两个整点时段，导致误判。分钟级精度将所有时间统一转换为"从0点开始的分钟数"（如10:30=630分钟），再做区间比较，精确反映实际占用情况。3.2.2.2 推荐引擎（RecommendService）：当借用冲突时，推荐引擎基于4个维度加权评分推荐替代场地。以下是评分计算的核心逻辑： // 4维度加权评分：容量(40%) + 设备(30%) + 时段可用(20%) + 楼栋(10%) // 权重通过application.yml外部化配置，便于调优 // 容量评分：刚好满足得高分，过大则扣分（避免浪费资源） double capacityScore = candidate.getCapacity() >= attendeeCount ? 1.0 - (double)(candidate.getCapacity() - attendeeCount) / candidate.getCapacity() : 0.0; // 容量不足直接0分 // 设备评分：需求设备在候选场地中的匹配比例 double equipmentScore = (double) matchCount / requiredEquipment.size(); // 加权求总分 double totalScore = capacityScore * 0.4 + equipmentScore * 0.3+ availabilityScore * 0.2 + buildingScore * 0.1; // 评分分解：每个维度包含原始分、权重、加权分、中文标签 breakdown.put("capacity", Map.of( "score", capacityScore, "weight", 0.4, "weighted", capacityScore * 0.4, "label", "容量匹配")); 推荐算法解析：容量评分采用"1 - 浪费比例"公式——如果场地容量刚好等于参会人数，得分接近1.0；如果场地容量远超需求（如200人场地只有10人使用），得分会显著降低。这样设计的目的是避免系统总是推荐最大的场地，造成资源浪费。评分分解中的weighted字段（原始分×权重）让前端可以直观展示每个维度的实际贡献，例如"容量匹配90%（权重40%，贡献36分）"，这就是"可解释推荐"的核心——用户不仅知道推荐了什么，还知道为什么推荐。3.2.2.3 统计服务（StatsService）：7日借用趋势（按本周周一至周日统计）拥挤度预测热力图（基于实际占用率计算，半小时粒度）错峰建议（拥挤度<20%的时段）审批SLA、资源闲置率等运营指标3.2.2.4 借用申请服务（并发安全）：借用申请是系统最关键的写操作，需要处理并发安全问题——同一资源同一时段可能被多人同时提交申请。以下是并发控制的核心逻辑：// 分布式锁：锁粒度 = resourceId + 日期 + 时段// 确保同一资源同一时段只能有一个借用请求成功String lockKey = "booking:" + resourceId + ":" + date + ":" + startHour + "-" + endHour;boolean locked = redissonLockHelper.tryLock(lockKey, 0, 10, TimeUnit.SECONDS);if (!locked) {throw new BusinessException(ErrorCode.SYSTEM_BUSY); // 获取锁失败，友好提示}try {// 在锁保护下执行冲突检测Map<String, Object> conflictResult = conflictCheckService.checkConflict(...);if (hasConflict) {// 冲突时自动触发推荐引擎，返回替代方案List<Map<String, Object>> recommendations = recommendService.recommend(...);return Map.of("hasConflict", true, "recommendations", recommendations);}// 教师在"允许直接预留"的场地上跳过审批BookingStatus status = (user.getRole() == TEACHER && resource.getAllowDirectReserve())? APPROVED : PENDING;bookingRepository.save(booking);} finally {redissonLockHelper.unlock(lockKey); // 必须在finally中释放锁}3.2.3 安全与认证采用JWT无状态认证方案，包含双Token机制（access Token + refresh Token）。整体认证流程如下：1. 用户登录成功后，后端签发两个Token：access Token（有效期2小时，包含用户ID、用户名、角色）和refresh Token（有效期7天，仅包含用户ID）2. 前端每次请求在Authorization头携带access Token，格式为Bearer <token>3. JwtAuthenticationFilter拦截每个请求，提取并验证Token，从Token中解析角色设置Spring Security上下文4. Spring Security根据SecurityConfig配置的路径规则进行权限校验：/api/v1/auth/**放行、/api/v1/admin/**需ADMIN角色、其余需认证5. 当access Token过期时，前端Axios拦截器自动使用refresh Token换取新的access Token，用户无感知为什么用双Token而非单Token：如果只有access Token且有效期很长，一旦泄露风险极大；如果有效期很短，用户需要频繁重新登录。双Token方案平衡了安全性和体验——access Token有效期短（2小时），即使泄露影响有限；refresh Token有效期长（7天），但只在续期时使用，不频繁传输，泄露风险低。3.2.4 半小时粒度占用率计算预约看板的核心数据来源，按半小时粒度计算每个格子的占用率。计算逻辑如下：1. 获取所有ACTIVE状态的资源（支持按类型过滤），作为占用率计算的分母2. 加载7天的固定占用和借用数据到内存3. 遍历7天×14小时×2个半小时 = 196个格子，对每个格子：将半小时时段转换为分钟数（如10:30=630分钟），用区间重叠判断统计该时段被占用的资源数4. 占用率 = 被占用资源数 / 活跃资源总数 × 100%为什么用半小时粒度而非整小时：校园场景中大量借用是非整点的，如"10:00-11:30"的课。如果按整小时粒度，11:00-11:30这个半小时会被错误地显示为空闲，导致用户预约后才发现冲突。半小时粒度可以精确反映"10:00-11:30"占用了10:00-10:30和10:30-11:00两个格子，11:00-11:30格子仍显示为空闲。占用率分母为什么只用ACTIVE资源：早期版本使用count()统计所有状态的资源作为分母，导致已下线（INACTIVE）的资源也被计入总数，占用率虚低。修复后改为countByStatus(ACTIVE)，确保占用率反映的是"在用资源中被占用的比例"。3.2.5 拥挤度预测与错峰建议基于本周实际借用+固定占用数据，预测7天×14时段的拥挤度。算法与占用率计算类似，但粒度为整小时（14个时段），适合宏观趋势展示。拥挤度计算完成后，自动筛选工作日（周一至周五）中拥挤度低于20%的时段作为错峰建议，最多返回10条。前端以ECharts热力图展示拥挤度分布，低峰时段以绿色标签突出显示，用户可直观选择空闲时段预约。3.2.6 关键Bug修复记录（系统调试）在开发过程中，码道代码智能体协助发现并修复了多个重要Bug：Bug根因修复方案看板日期错位1天前端使用toISOString()返回UTC日期，在UTC+8时区下日期会偏移改用本地时间格式化new Date(d).toLocaleDateString()占用率分母含INACTIVEcount()统计所有状态资源，已下线资源拉低占用率改为countByStatus(ACTIVE)只统计活跃资源占用+可用≠总数冲突检测只取整点小时，非整点借用被遗漏改为分钟级重叠判断，统一冲突检测口径借用描述显示错误findFirst()未过滤时段，显示了不相关时段的占用描述添加时段重叠过滤条件半小时格显示整小时数据后端按小时粒度返回，前端半小时格复用整点结果后端重构为半小时粒度返回3.3 前端开发3.3.1 预约看板（BookingBoardView）核心页面，功能包括：1. 半小时粒度可视化看板(见下面图一)：7天×28个时段格子，颜色梯度表示占用率（5级：空闲/低/中/较高/拥挤）2. 点击格子查看详情（见下面图二）：弹窗显示占用资源列表+可用场地列表，占用+可用=总数3. 智能预填申请表单（见下面图三）：点击格子后自动预填日期、时段，场地仅显示空闲资源4. 时段可调节：开始/结束时间下拉选择，结束时间受该资源下一个占用时段约束5. 常用场地快捷入口：看板顶部显示Top3常用场地标签6. 解释型推荐面板：冲突时显示4维度评分进度条+权重贡献说明7. 场地名称搜索：支持按名称模糊搜索过滤3.3.2  Token自动续期机制续期机制解析：使用isRefreshing标志位和pendingRequests队列解决了一个关键问题——当多个请求同时发现Token过期时，如果每个请求都独立发起刷新，会导致refresh Token被多次使用，可能触发后端的"Token已使用"安全校验。通过标志位确保只发起一次刷新请求，其他请求进入等待队列，刷新成功后统一用新Token重试。这样用户在任何操作中都不会因为Token过期而中断，实现了真正的"无感续期"。3.3.3 数据看板（DashboardView）管理员专属页面，功能包括：1. 6个核心指标卡片：总借用数、待审数、通过率、冲突率、审批SLA、资源闲置率2. 本周借用趋势图：ECharts折线图，X轴显示日期，Y轴动态调整3. 拥挤度热力图：7天×14时段的ECharts热力图，基于实际占用率计算4. 错峰建议标签：拥挤度<20%的时段以绿色标签展示 3.3.4 个人中心（ProfileView）个人中心（ProfileView）：借用历史表格支持状态筛选；状态时间线用el-steps三步展示（提交→审批→使用）；个人统计卡片展示本月借用数、最常使用场地、通过率。审批管理（ApprovalView）：待审批列表支持勾选+一键批量通过；查看已通过借用弹窗显示详细时间、场地、用途；驳回功能需输入驳回理由，确保审批可追溯。3.3.5 审批管理（ApprovalView）1. 待审批列表：勾选+一键批量通过2. 查看已通过借用：弹窗显示所有已通过借用的详细时间、场地、用途信息3. 驳回功能：需输入驳回理由3.4 创新功能实现3.4.1 解释型推荐2.0传统推荐系统只返回"推荐场地A"，用户无法理解推荐理由，信任度低。解释型推荐2.0让用户看到每个维度的评分和权重贡献，例如"容量匹配90%（权重40%，贡献36分）"，显著提升用户对推荐结果的信任度和采纳率。后端RecommendService暴露4维度评分分解（capacity/equipment/availability/building）+权重贡献+自然语言reason，前端推荐面板以进度条+贡献百分比直观展示。3.4.2 拥挤度预测与错峰建议用户可以直观看到哪些时段场地紧张（红色），哪些时段空闲（绿色），并直接获得错峰建议（拥挤度<20%的时段），避免"扎堆预约"现象。后端/stats/crowding-prediction API基于本周实际借用+固定占用数据计算7天×14时段拥挤度，前端以ECharts热力图+绿色错峰标签展示。3.4.3 运营决策看板增强管理员可量化评估审批效率和资源利用效率。审批SLA计算方式为所有已审批借用单的updatedAt - createdAt均值（小时），资源闲置率计算方式为(活跃资源数 - 近7天被借用资源数) / 活跃资源数 × 100%。这两个指标帮助管理员及时发现"审批瓶颈"和"僵尸场地"。3.4.4 半小时粒度预约看板相比整小时粒度，半小时粒度可以更精确地展示"10:00-11:30"这类非整点时段的占用情况，避免用户误判空闲时段。后端getSlotOccupancy按半小时粒度返回占用数据，活动跨越的半小时格子都会被标记为占用。截图请见3.3.1。3.5 测试验证3.5.1 后端单元测试使用JUnit 5编写22项单元测试，覆盖5个核心Service：测试类测试数覆盖内容ApprovalServiceTest3审批通过/驳回/状态校验AuthServiceTest4登录/注册/角色校验/重复注册BookingServiceTest5创建/取消/冲突检测/推荐ConflictCheckServiceTest5固定占用冲突/借用冲突/无冲突RecommendServiceTest5评分计算/维度权重/推荐排序运行测试： mvn test 3.5.2 前端自动化测试使用Playwright MCP进行前端自动化测试，覆盖18项功能：登录流程测试（正常登录/异常密码）预约看板交互（格子点击/申请提交）审批管理（通过/驳回）数据看板（图表渲染）3.5.3 数据一致性验证通过数据库直接查询验证看板数据与实际记录一致：-- 验证固定占用SELECT fs.id, r.name, fs.day_of_week, fs.start_time, fs.end_time, fs.descriptionFROM fixed_schedule fs JOIN resource r ON fs.resource_id = r.id;-- 验证活跃借用SELECT b.id, r.name, b.purpose, b.start_time, b.end_time, b.statusFROM booking b JOIN resource r ON b.resource_id = r.idWHERE b.status IN ('APPROVED','PENDING');3.6 码道代码智能体使用技巧3.6.1 Skill使用本案例使用了以下Skill：1. 创建SDD目录（creating-sdd-directory）：根据项目描述自动初始化spec.md/design.md/tasks.md目录结构2. 管理规格文档（managing-spec-document）：维护"做什么"的需求规格3. 管理设计文档（managing-design-document）：维护"怎么做"的技术设计4. 管理任务文档（managing-tasks-document）：维护可执行的任务清单3.6.2 MCP使用本案例配置并使用了Playwright MCP：1. 前端自动化冒烟测试：通过Playwright MCP控制Chromium浏览器，自动执行登录、页面导航、按钮点击等操作，验证前端功能可用性2. E2E功能验证：模拟完整用户路径（登录→申请→冲突→推荐→审批），验证前后端集成正确性3. 截图留证：使用Playwright的截图功能捕获页面状态，作为功能验证证据3.6.3 高效使用码道的经验1. 明确描述需求：越具体的需求描述，生成的代码质量越高2. 迭代修复：发现Bug后直接告诉码道具体现象，它能快速定位根因，不要一次性发完全部问题，逐步将问题发给码道，可以更好更快的解决3. 数据驱动验证：通过数据库查询验证前后端数据一致性4. 分阶段执行：先完成核心功能，再逐步添加创新点和优化以下图两个我实际开发过程中的问题为例来体现如何对话的过程：1）预约看板半小时粒度单元格数量不一致开发预约看板时，假设用户设定借用时间为9:30-11:00，理论上应占用3个半小时单元格（9:30-10:00、10:00-10:30、10:30-11:00），但看板上实际只显示了2个。我向码道描述了这一现象，码道分析后定位到后端StatsService.getSlotOccupancy中计算占用时的时间区间判断逻辑：原代码用slotStartMin < fsEndMin && slotEndMin > fsStartMin进行重叠判断，但半小时粒度的边界条件处理有误，导致结束时间恰好落在整点时少算一个格子。码道修正了边界判断逻辑，将slotEndMin > fsStartMin调整为slotEndMin >= fsStartMin，确保半点结束的占用也能被正确计入。修复后通过浏览器验证，9:30-11:00的占用准确显示为3个单元格。2）解释型推荐引擎前端无入口系统后端已实现解释型推荐引擎API，但前端预约看板只展示可用资源供用户选择，用户永远选不到冲突资源，导致推荐引擎无法被触发。我向码道反馈"推荐引擎在网页端怎么操作？系统已经屏蔽了冲突情况"，码道理解了问题的本质——不是代码Bug，而是功能入口缺失。码道提出方案：在时段详情弹窗中，将已占用资源从简单标签增强为卡片（显示占用类型和原因），每个旁边添加"找替代"按钮，点击后调用推荐引擎展示四维度评分；同时在弹窗顶部添加"智能推荐"快捷入口。我确认后码道立即实现，修改BookingBoardView.vue，通过浏览器验证推荐面板成功弹出，四维度评分进度条正常展示，推荐引擎真正可演示。四、释放资源4.1 清理本地开发环境如需释放本地资源：1. 停止后端服务：Ctrl+C终止Spring Boot进程2. 停止前端服务：Ctrl+C终止Vite开发服务器3. 可选：删除campus-booking-server/target目录释放构建缓存4.2 清理华为云资源如已部署至华为云，请释放以下资源：1. 删除ECS弹性云服务器2. 删除RDS MySQL实例3. 删除DCS Redis实例4. 释放弹性公网IP五、扩展资料说明华为云码道（CodeArts）官方文档：https://support.huaweicloud.com/codearts/index.htmlSpring Boot 3.x官方文档：https://spring.io/projects/spring-bootVue 3官方文档：https://vuejs.org/Element Plus组件库：https://element-plus.org/ECharts图表库：https://echarts.apache.org/Playwright自动化测试：https://playwright.dev/ 

【演示地址】http://120.46.70.181【测试账号】用户名 demo / 密码 demo123【代码仓库】cid:link_0【代码托管】华为云 CodeArts 代码智能体（.codeartsdoer/specs/hugbug/ 目录含 SDD 三阶段完整规范文档）【开发工具】华为云 CodeArts 代码智能体 + SDD 规范驱动开发【AI 通道】DeepSeek Chat API（云端）+ 华为云 CodeArts CLI（本地）+ 本地预设（降级） 一、项目介绍HugBug（"拥抱 Bug"）是一个面向计算机专业学生与初中级开发者的程序员成长陪伴系统，寓意"把编程中遇到的 Bug 从负担变为可复用的知识资产"。项目通过六大功能模块解决程序员学习中的痛点：学习任务管理、Bug 日志（含 AI 辅助分析）、每日打卡、AI 每日运势、桌宠 Widget、成长仪表盘。二、基于 SDD 的规范驱动开发本项目严格遵循华为云码道推荐的 Spec-Driven Development（SDD）流程，通过 spec-requirement、spec-design、spec-task 三个子智能体协作，从需求分析到实现方案再到编码任务规划一步到位：阶段一（spec.md）：需求规格 — 6 大功能模块 + 5 个领域对象 + 业务规则 + DFX 需求阶段二（design.md）：实现方案 — 三层架构 + 32 个 API 接口 + 5 个核心数据模型 + 关键流程图阶段三（tasks.md）：任务规划 — 12 个主任务、67 个子任务、依赖关系所有 SDD 文档保存在 .codeartsdoer/specs/hugbug/ 目录下。在后续增量需求（Bug AI 分析、AI 双通道、桌宠 UI 优化）中同样严格补充生成对应的 spec/design/tasks 三份文档。三、核心亮点：Bug AI 辅助分析传统 Bug 记录系统需要用户手动填写标题、报错信息、解决方案等所有字段，门槛过高。HugBug 改造后，用户只需粘贴报错文本，AI 会自动完成结构化分析：- 精准标题- 报错原文保留- 3-5 条排查建议- 2-4 个技术标签系统调用 AI 生成结构化记录，用户确认后即可入库，形成个人 Bug 知识库。前端 UI 通过 🤖 图标标识 AI 生成记录，紫色 badge "✨ AI 已为你分析" 提示 AI 参与。四、核心技术难点：AI 双通道 + 三级降级项目初始 AI 调用完全依赖本地 CodeArts CLI，部署阶段发现华为云 ECS 上无法安装 CLI。为此设计"双通道 + 三级降级"策略：第一优先级：DeepSeek Chat API（云端）— 从环境变量 DEEPSEEK_API_KEY 读取密钥，兼容 OpenAI Chat Completions 协议第二优先级：本地 CodeArts CLI — 通过 shutil.which 检测可执行文件是否存在第三优先级：本地预设 JSON — 前两个通道都失败时降级，保证系统不崩溃统一入口 ask_ai() 屏蔽三个通道的差异。同时解决 SSL 握手失败（trust_env=False + 3 次重试）和 Windows GBK 编码兼容（encoding='utf-8', errors='replace'）两个技术难点。五、华为云部署方案- 计算：ECS 2 vCPU / 4 GB RAM，Ubuntu 22.04- 网络：弹性公网 IP + Sys-WebServer 安全组（开放 80/8000）- 进程管理：systemd 编排 uvicorn，Restart=always 保证 7×24 后台常驻- 反向代理：Nginx 将公网 80 端口转发至内部 8000 端口- 演示地址：http://120.46.70.181六、部署踩坑记录- pip 官方源超时 → 换华为云 pip 镜像，安装时间从超时缩短到 1 分钟- FastAPI 版本不兼容 TemplateResponse → 锁定 fastapi==0.104.1 + starlette==0.27.0- SQLAlchemy 类型错误 .cast(func.Date) → 改为 func.date(X)，仪表盘三张图正常渲染- requirements.txt 桌面依赖污染 → 移除 PyQt5、Pillow七、VOD 建议结合本次实习中使用码道的实际体验，提出三条改进建议：建议一：AI IDE 应内置"开发者情绪感知模块"当前 AI IDE 聚焦编码效率，忽视了开发者心理状态。建议通过检测提交频率、Bug 反复模式、AI 对话语气变化等隐性信号，感知开发者情绪，在关键节点提供正反馈。HugBug 的桌宠 Widget 和运势模块是这一思路的应用层实现。建议二：AI IDE 应内置"错误学习闭环"当前码道能帮开发者定位 Bug，但缺少"错误知识沉淀"。同一开发者反复遇到同类 Bug 时，AI 只能重复给建议，无法基于历史学习提供针对性方案。建议增加"个人 Bug 知识库"能力。HugBug 的 Bug AI 分析模块是这一思路的应用层雏形。建议三：SDD 流程建议增加"页面 Mockup 可视化"当前 SDD design 阶段主要输出接口清单、数据模型等结构化文档，Web 应用缺少页面视觉呈现。建议在 design 阶段增加"Mockup 可视化"子步骤，基于需求文档自动生成低保真页面草图，让 UI 层决策更早介入。八、项目总结HugBug 从最初的"赛博玄学生成器" PyQt5 桌面桌宠创意，在意识到评审对可部署 Web 演示环境的硬性要求后果断转向 Web 应用，同时保留了"程序员情绪陪伴"核心创意与桌宠图片资源。整个开发过程严格遵循 SDD 规范流程，最终产物是一个部署在 http://120.46.70.181 的可交互 Web 应用。详细技术细节、架构图、SDD 三阶段完整文档、代码块示例，请下载附件《HugBug案例文档.docx》查看。

现在开源大模型发展迅速，不管是GLM5.2还是KIMI K3都非常强劲，但码道仍停留在GLM5.1，什么时候才能更新新的模型呢

一、概述1.1 案例介绍现代前端应用通常会经过 Webpack 等构建工具压缩、拆分和混淆，最终生成多个 JavaScript Bundle。打包后的代码往往缺少 Source Map，模块名称被替换为数字或短标识符，同时不同构建工具、版本和插件还会产生多种 Runtime 结构。这使开发者难以直接识别模块边界、恢复依赖关系，也难以追踪数据在本地存储、业务模块、网络请求和页面渲染之间的传播过程。传统依赖固定规则的分析工具，面对不同构建产物时通常需要人工修改解析逻辑，适配成本较高。为解决上述问题，本案例基于华为云码道（CodeArts）代码智能体开发 BundleScope JavaScript Bundle 自适应分析系统。系统通过真实大模型 Agent 读取 Bundle 的代表性代码片段，识别 Webpack Runtime、模块工厂和模块加载协议，并生成受结构约束的 Adapter 配置；随后由确定性静态分析引擎执行该配置，恢复模块依赖图，识别跨模块数据流，并将分析结果定位到原始 Bundle 文件和具体代码行。借助 Agent 理解不同构建方言、静态分析引擎保证结果可验证的协同方式，BundleScope 能够降低无 Source Map 构建产物的分析门槛，为前端故障排查、依赖审计、数据流分析和安全检查提供直观、可追溯的分析能力。视频demo:https://gitcode.com/HuaaweeiNB/BundleScope/blob/main/demo%E5%B1%95%E7%A4%BA.mp41.2 适用对象·企业开发者·个人开发者·高校学生本案例也适用于对以下方向感兴趣的开发者：·大模型 Agent 应用开发·JavaScript 前端工程化·程序静态分析·Web 应用安全分析·FastAPI 全栈应用开发1.3 案例时间本案例总时长预计12 小时，其中使用华为云码道（CodeArts）代码智能体开发SDD文档体系等约 2 小时，使用华为云码道（CodeArts）代码智能体进行项目开发、配置与运行约 9 小时，功能验证与结果分析约 1 小时。1.4 案例流程流程1说明：AI IDE华为云码道（CodeArts）代码智能体安装部署；配置码道devecoflow skill，并使用该skill部署配置码道开发生态skills；对话码道，使用dev-process-framework skill生成系统设计；对话码道，使用page-mockup skill生成前端页面设计；对话码道，使用test-designer skill生成测试设计文档；对话码道，使用function-detail skill整合系统设计和页面设计和测试设计，生成 AssetMgmt SDD（需求、设计和开发任务）。流程2配置华为云码道规则、skills，部署PC本地开发和测试环境；对话码道，使用 BundleScope SDD 逐项开发固定资产管理系统，并使用sdd-workflow、bug-fix-reporter - Bug等skills辅助记录开发进展、需求同步和修复报告生成；对话码道，使用 fullstack-testing skill 编写后端、前端、API集成以及E2E等测试用例；对话码道，执行测试用例并修复bug；对话码道，启动 BundlScope1.5 资源总览本案例预计花费240元。资源名称规格单价（元）华为云码道（CodeArts）代码智能体基础版39华为云码道（CodeArts）代码智能体按需计费200二、环境和资源准备2.1 安装华为云码道（CodeArts）代码智能体参考案例《AI IDE华为云码道（CodeArts）代码智能体安装部署》，完成 Windows 版 AI IDE 华为云码道（CodeArts）代码智能体的安装与登录。本案例采用以下开发配置：码道工作模式：智能体模式使用模型：GLM-5.1开发模式：探索模式（Vibe-Coding Mode）代码仓库：https://gitcode.com/HuaaweeiNB/BundleScope.git2.2 配置项目开发 Skills本案例在项目中配置并使用以下 Skills：Skill 名称主要用途dev-eco-setup下载并部署项目级开发 Skills，快速初始化项目开发生态dev-process-framework辅助完成需求细化、架构决策、任务拆分和代码质量检查page-mockup辅助设计 BundleScope 前端页面原型和交互流程function-detail根据项目需求和系统设计生成详细功能设计文档sdd-workflow管理需求、设计、任务和开发进度，保证开发过程可追溯bug-fix-reporter记录模块误识别、前端显示异常等问题的修复过程fullstack-testing辅助设计和执行后端接口测试、前端功能测试及集成测试frontend-design辅助生成 BundleScope 前端页面结构、组件和视觉样式creating-sdd-directory初始化规范驱动开发所需的 SDD 文档目录managing-spec-document管理需求规格文档 spec.mdmanaging-design-document管理系统设计文档 design.mdmanaging-tasks-document将项目开发内容拆分为可追踪的任务文档 tasks.md项目级 Skills 存放在以下目录：E:/BundleScope/.codeartsdoer/skills也可以通过码道的 设置 > 技能与规则 > 项目级技能 查看已经配置的 Skills。2.3 配置本地运行环境本案例采用 Windows 本地环境完成开发和运行，主要环境配置如下：环境或工具配置说明操作系统Windows 10 或 Windows 11PythonPython 3.11 或 Python 3.12后端框架FastAPIWeb 服务Uvicorn数据校验Pydantic大模型调用OpenAI 兼容 Python SDK前端技术HTML、CSS、原生 JavaScript代码管理Git、GitCode开发工具AI IDE 华为云码道（CodeArts）代码智能体浏览器Microsoft Edge 或 Google Chrome项目运行依赖统一记录在 src/requirements.txt 文件中。进入项目源码目录，创建 Python 虚拟环境：cd E:\BundleScope\src py -m venv .venv激活虚拟环境：.\.venv\Scripts\Activate.ps1升级 pip 并安装项目依赖：python -m pip install --upgrade pip python -m pip install -r requirements.txt虚拟环境创建完成后，后续重新运行项目时只需进入 src 目录并激活已有环境，不需要重复执行 py -m venv .venv。2.4 配置大模型 AgentBundleScope 强制使用真实大模型 Agent 完成 JavaScript Bundle Runtime 识别，不提供无 Agent 的固定规则分析模式。系统支持以下大模型 Provider：Provider示例模型API Base URLDeepSeekdeepseek-v4-flashhttps://api.deepseek.com智谱 GLMglm-5.1https://open.bigmodel.cn/api/paas/v4Kimikimi-k2.6https://api.moonshot.cn/v1启动系统后，需要在前端 Agent 配置窗口中填写以下内容：大模型 Provider；模型名称；API Key；API Base URL。系统会在保存配置前调用真实模型执行连接测试。只有连接测试成功后，才能上传 JavaScript Bundle 或运行演示样例。API Key 只保存在当前 FastAPI 进程的内存中，具有以下特点：不写入项目源码；不写入配置文件；不写入浏览器 localStorage；不提交到 GitCode 仓库；关闭后端服务后自动清除。2.5 配置 GitCode 代码仓库本案例使用 GitCode 管理 BundleScope 项目源码。代码仓库地址：https://gitcode.com/HuaaweeiNB/BundleScope.git本地项目根目录：E:/BundleScope项目实际源码目录：E:/BundleScope/src项目主要目录结构如下：BundleScope ├── .gitignore ├── README.md └── src ├── backend │ ├── __init__.py │ ├── agent.py │ ├── analyzer.py │ ├── main.py │ ├── provider_store.py │ └── schemas.py ├── frontend │ ├── index.html │ └── assets │ ├── app.js │ └── style.css ├── samples │ ├── app.js │ └── runtime.js └── requirements.txt为避免提交虚拟环境、缓存文件和敏感信息，在项目根目录的 .gitignore 中配置以下内容：.venv/ venv/ __pycache__/ *.py[cod] .env .env.* *.log .vscode/ .idea/ .pytest_cache/ .mypy_cache/ .ruff_cache/ 2.6 使用码道上下文选择功能在使用码道修改特定文件或目录时，可以在码道对话框中输入 #，通过上下文选择功能选择指定的 File 或 Folder。本案例开发过程中主要使用以下上下文：#src/backend #src/frontend #src/backend/agent.py #src/backend/analyzer.py #src/backend/main.py #src/frontend/index.html #src/frontend/assets/app.js #src/frontend/assets/style.css通过限定上下文，可以使码道优先分析指定文件或目录，减少无关内容干扰，提高需求分析、代码生成和问题修复的准确性。三、对话码道：BundleScope 项目设计3.1 项目背景与原始需求项目背景与原始需求是项目设计和开发的基础，用于明确系统需要解决的问题、核心用户、主要功能以及最终验收目标。JavaScript 应用经过 Webpack 等构建工具打包后，通常会形成经过压缩、混淆和模块拆分的 Bundle 文件。由于不同 Webpack 版本、插件和 Runtime 实现存在差异，打包产物中的模块编号、加载协议和导出方式并不统一。在缺少 Source Map 的情况下，开发者很难直接识别模块边界、恢复模块依赖关系，也难以追踪数据从浏览器存储、业务逻辑到网络请求和页面渲染的传播路径。BundleScope 项目希望构建一个面向无 Source Map JavaScript Bundle 的自适应分析系统。系统通过大模型 Agent 阅读 Bundle 的代表性代码片段，识别 Webpack Runtime 和模块加载协议，生成受约束的 Adapter 配置，再由确定性静态分析引擎恢复模块关系、分析调用关系和数据流，并将结果定位到原始 Bundle 文件和代码行。本案例使用华为云码道（CodeArts）代码智能体完成 BundleScope 项目的需求分析、架构设计、详细设计和任务拆分。项目原始需求主要包括：支持上传一个或多个 JavaScript Bundle 文件；强制使用真实大模型 Agent 分析 Bundle Runtime；支持 DeepSeek、智谱 GLM 和 Kimi 等 OpenAI 兼容模型；由 Agent 生成结构化、受约束的 Adapter 配置；由确定性静态分析引擎执行 Adapter；识别 JavaScript Bundle 中的模块边界；恢复模块之间的加载和依赖关系；分析模块导出、函数调用和事件关系；追踪本地存储、网络请求和 DOM 操作之间的数据流；展示模块关系图、数据流路径和 Agent 执行轨迹；支持点击模块或数据流节点定位原始代码；API Key 只保存在后端进程内存中，不写入源码或浏览器存储；Agent 分析失败时禁止回退到固定 Adapter；项目能够在 Windows 本地环境中运行。完整需求和设计内容保存在项目的 ProjectDocs 目录中。3.2 BundleScope 整体设计3.2.1 BundleScope 系统设计基于 BundleScope 项目背景与原始需求，使用 dev-process-framework Skill 对项目进行系统化分析和设计。在码道对话框中选择项目需求文件作为上下文，并输入以下 Prompt：#BundleScope项目背景与原始需求.md 请帮我完成以下工作： 第一阶段：需求分析与设计 1. 使用 dev-process-framework 方法论； 2. 进行需求细化和决策发现； 3. 识别关键决策点和项目风险； 4. 设计系统整体架构； 5. 设计 Agent 与 Adapter 工作机制； 6. 定义分析结果数据模型； 7. 设计后端 API 接口； 8. 设计前端页面和交互流程； 9. 制定项目实施计划。 第二阶段：文档输出 1. 生成需求细化与决策发现文档； 2. 生成架构设计文档； 3. 生成数据模型设计文档； 4. 生成 API 接口设计文档； 5. 生成实施计划文档； 6. 生成需求规格说明文档。 输出要求： 1. 文档格式 - 使用 Markdown 格式； - 使用中文编写； - 文档结构清晰； - 文档统一存放在 ProjectDocs/systemDesign 目录下。 2. 代码规范 - Python 代码遵循 PEP 8； - JavaScript 代码保持结构清晰； - 关键函数具有注释； - Python 代码使用类型提示； - API 数据结构使用 Pydantic 校验。 3. 系统要求 - 项目采用 FastAPI 后端和原生 HTML、CSS、JavaScript 前端； - 项目按前后端分层结构组织； - 系统强制使用真实大模型 Agent； - 支持 DeepSeek、GLM 和 Kimi； - Agent 只生成受约束 Adapter，不直接生成最终分析结果； - 静态分析引擎负责确定性执行 Adapter； - 不允许在 Agent 失败后回退到固定规则； - API Key 只保存在后端进程内存中； - 分析结果必须保留文件名和代码行号证据； - 项目根目录为 E:/BundleScope； - 项目源码位于 E:/BundleScope/src。 请系统化地完成 BundleScope 项目的规划和设计，确保文档完整、设计合理且具有可执行性。码道调用 dev-process-framework Skill，对项目需求进行分析，自主规划设计任务，并生成 BundleScope 项目的系统设计文档。由于本案例在实际操作过程中未保留完整的码道执行截图，因此本节主要通过实际生成的 Prompt、设计文档和目录结构说明码道的执行结果。设计文档生成完成后，继续使用码道对系统设计进行检查和优化：#ProjectDocs/systemDesign 请使用 dev-process-framework skill 的规则和方法，对 BundleScope 项目的全部系统设计文档进行综合检查。 重点检查以下内容： 1. 需求、架构、数据模型、API 和实施计划是否一致； 2. Agent 和确定性静态分析引擎的职责是否清晰； 3. 是否明确禁止无 Agent 分析和固定 Adapter 回退； 4. Adapter Schema 是否足够安全且可执行； 5. 是否完整设计模块识别、依赖恢复、调用关系和数据流分析； 6. 是否包含代码证据定位能力； 7. 是否存在功能遗漏、设计冲突或不可执行内容； 8. 是否符合 Windows 本地开发和运行环境。 如果发现问题，请直接对相关设计文档进行最优调整。为减少设计遗漏，本案例对整体设计进行了多轮检查和调整。3.2.2 BundleScope 前端页面设计在完成系统需求和总体架构设计后，使用 page-mockup 和 frontend-design Skills 设计 BundleScope 前端页面。对话码道：#ProjectDocs/systemDesign 请使用 page-mockup skill 完成 BundleScope 项目的前端页面设计。 设计过程中可以使用 frontend-design skill 优化页面风格。 前端页面至少包含： 1. Agent Provider 首次配置弹窗； 2. DeepSeek、GLM 和 Kimi Provider 选择； 3. Model、API Key 和 Base URL 配置； 4. Provider 连接测试结果； 5. Bundle 文件上传区域； 6. 分析结果总览； 7. Agent 执行轨迹页面； 8. Agent 生成的 Adapter JSON 展示； 9. Module Graph 模块关系图； 10. 模块详情面板； 11. 数据流追踪页面； 12. Source、Propagation 和 Sink 节点； 13. 原始 Bundle 代码查看器； 14. 代码行号和证据高亮； 15. 自然语言查询页面； 16. API Key 清除和重新配置入口。 页面风格要求： 1. 采用 PC Web 管理控制台布局； 2. 使用左侧导航栏和右侧工作区； 3. 风格简洁、专业； 4. 使用统一的卡片、按钮、状态标签和颜色规范； 5. 不使用 emoji 作为主要图标； 6. 代码查看器采用深色背景； 7. 分析结论必须能够跳转到代码证据； 8. 页面应适配常见桌面分辨率。页面设计完成后，继续使用码道检查页面设计：#ProjectDocs/systemDesign 请使用 page-mockup skill 和 frontend-design skill 的规则，对 BundleScope 页面设计进行检查。 重点检查： 1. 页面是否覆盖完整的 Agent 配置和 Bundle 分析流程； 2. Agent Trace 是否能够真实反映 Agent 调用过程； 3. 模块图、数据流和代码证据之间是否可以相互跳转； 4. 是否存在页面功能重复或布局不合理； 5. 是否能够清楚展示分析失败和验证失败状态； 6. 是否满足 PC Web 端演示要求； 7. 是否避免使用无实际功能的装饰性组件。 如果存在问题，请直接优化页面设计文档。3.2.3 BundleScope 测试设计系统设计和页面设计完成后，使用 fullstack-testing Skill 生成 BundleScope 测试设计文档。对话码道：#ProjectDocs/systemDesign 请使用 fullstack-testing skill 完成 BundleScope 项目的测试设计。 测试范围至少包括： 1. Provider 配置测试； 2. API Key 校验测试； 3. DeepSeek、GLM 和 Kimi 连接测试； 4. 未配置 Agent 时禁止分析的测试； 5. Agent 返回有效 Adapter JSON 的测试； 6. Agent 返回无效 JSON 的测试； 7. Adapter Schema 校验失败测试； 8. Agent 首轮分析失败后的修复流程测试； 9. 第二轮验证失败后终止分析的测试； 10. 禁止固定 Adapter 回退的测试； 11. JavaScript Bundle 文件上传测试； 12. 文件格式和文件大小限制测试； 13. Webpack Runtime 识别测试； 14. Module Factory 提取测试； 15. Require 和 Export 恢复测试； 16. 模块关系图生成测试； 17. Source 和 Sink 数据流分析测试； 18. 代码行号定位测试； 19. 前端 Agent 配置流程测试； 20. 模块图节点交互测试； 21. 数据流节点跳转代码测试； 22. Bundle 代码高亮测试； 23. 前后端集成测试； 24. Windows 本地运行测试。 输出测试设计、测试场景、测试用例、预期结果和验收标准。测试设计生成完成后，继续对话码道进行测试设计检查：#ProjectDocs/systemDesign 请使用 fullstack-testing skill 的规则，对 BundleScope 测试设计进行综合检查。 重点检查： 1. 测试是否覆盖正常流程和异常流程； 2. 是否验证必须使用真实 Agent； 3. 是否验证不存在规则模式回退； 4. 是否覆盖三种 Provider； 5. 是否覆盖 Adapter 生成、校验、执行和修复； 6. 是否覆盖模块识别误报和依赖误报； 7. 是否覆盖前端交互和代码证据跳转； 8. 每个重要需求是否至少有一个对应测试。 如果发现测试遗漏，请直接补充和优化测试设计文档。3.2.4 设计调整与整体优化在完成需求分析、系统设计、页面设计和测试设计后，对全部文档进行人工检查。检查过程中主要关注以下问题：项目是否明确强制使用真实大模型 Agent；Agent 是否只负责生成 Adapter，而不是直接生成分析结论；静态分析引擎是否负责确定性执行和结果验证；是否存在 Agent 失败后回退到固定规则的设计；Module 和普通函数是否可能发生误识别；普通函数调用和 CSS 选择器是否可能被误识别为模块依赖；模块图是否只展示已解析的 Module ID；是否完整设计 Agent Trace 和 Adapter JSON 展示；是否支持点击模块和数据流节点查看原始代码；API Key 是否存在泄露风险。对话码道：#ProjectDocs/systemDesign 请对 BundleScope 项目需求、架构、API、页面和测试设计进行以下调整： 1. 系统必须强制使用真实 LLM Agent，不提供规则分析模式； 2. 未配置 API Key 时，禁止上传 Bundle 和运行演示样例； 3. 支持 DeepSeek、智谱 GLM 和 Kimi 三种 Provider； 4. Agent 只返回受 Pydantic Schema 约束的 Adapter JSON； 5. 禁止 Agent 返回任意 Python、JavaScript 或正则表达式代码； 6. Agent 第一次生成的 Adapter 验证失败时，允许进行一次修复； 7. 第二次验证仍失败时，必须终止分析； 8. 不允许回退到默认 Webpack Adapter； 9. Module 提取必须避免将 push、send、render 等普通函数识别为模块； 10. Require 提取必须避免将 querySelector(".search-button") 等普通调用识别为模块加载； 11. Module Graph 只允许显示已经解析成功的 Module ID； 12. 所有模块和数据流分析结果必须包含文件名和代码行号； 13. 前端增加 Agent Trace 页面； 14. 前端增加 Agent 生成的 Adapter JSON 页面； 15. 前端增加 Bundle 原始代码查看器； 16. 支持点击模块和数据流节点定位并高亮代码； 17. API Key 只保存在后端进程内存中； 18. 项目仅在 Windows 本地环境运行，不设计云服务器和容器部署流程。 请同步修改所有受影响的设计文档，保证文档之间内容一致。调整后，再次要求码道进行整体合理性检查：#ProjectDocs/systemDesign 请从整体完整性、技术合理性和可执行性三个方面，综合检查 BundleScope 项目的全部设计文档。 重点检查： 1. 需求、设计、任务和测试之间是否一致； 2. Agent、Adapter 和静态分析引擎之间的职责是否清晰； 3. 是否存在功能遗漏或重复设计； 4. 是否符合当前 FastAPI 和原生前端实现； 5. 是否符合 Windows 本地运行环境； 6. 是否可以根据现有设计直接进入开发阶段。 如果存在问题，请进行最优调整，并同步修改相关文档。3.3 BundleScope 整体设计交付成果经过需求分析、系统设计、页面设计、测试设计和多轮优化，码道在 ProjectDocs/systemDesign 目录下生成了 BundleScope 项目的整体设计文档。主要设计文档包括：序号文档内容说明101-需求细化与决策发现.md对无 Source Map Bundle 分析需求进行细化，识别 Agent 强制接入、Adapter 约束、结果可追溯、API Key 安全等关键决策，并分析技术风险和实现边界。202-架构设计.md设计由前端交互层、FastAPI 服务层、LLM Agent 层、Adapter 执行层和静态分析层组成的系统架构，明确 Agent 与确定性分析引擎的职责分工。303-数据模型设计.md定义 Provider 配置、Agent Adapter、Module、Edge、Flow、CodeLocation、ValidationReport 和 AgentTrace 等核心数据结构。404-API接口设计.md设计 Provider 查询、连接测试、Provider 保存和清除、Bundle 上传分析、演示样例分析及健康检查等 RESTful API。505-实施计划.md将项目划分为环境准备、Agent 接入、静态分析引擎、前端可视化、测试与优化等阶段，并定义各阶段验收标准。606-需求规格说明.md记录 BundleScope 功能需求、非功能需求、约束条件、业务规则和验收标准。707-页面设计.md设计 Agent 配置弹窗、分析总览、Agent Trace、Adapter JSON、模块图谱、数据流追踪、代码证据和自然语言查询等页面。808-测试设计.md设计 Provider、Agent、Adapter、模块恢复、数据流、前端交互和异常处理等测试场景。9Agent与Adapter设计.md详细说明 Agent 输入采样、Prompt 约束、Adapter Schema、首轮生成、确定性验证、二次修复和失败终止机制。3.4 BundleScope SDD 设计3.4.1 初步生成 BundleScope SDD完成整体设计后，继续使用 function-detail Skill 生成 BundleScope 的 SDD 开发详细设计文档。在码道对话框中选择 ProjectDocs/systemDesign 目录作为上下文，并输入以下 Prompt：#ProjectDocs/systemDesign 请使用 function-detail skill 帮我生成 BundleScope 项目的 SDD 开发详细设计文档。 要求如下： 1. 每个设计和任务都必须关联明确的需求，并包含需求引用； 2. SDD 任务按照以下结构设计： 第一部分：基础环境准备与项目初始化 - Windows 本地开发环境准备； - Python 虚拟环境创建； - FastAPI 后端项目初始化； - 原生前端目录初始化； - requirements.txt 依赖配置； - Git 和 GitCode 仓库配置； - 基础 API 和数据模型骨架初始化。 第二部分：项目开发 - Provider 内存配置管理； - DeepSeek、GLM 和 Kimi 接入； - Provider 连接测试； - Bundle 代码采样； - Agent Prompt 设计； - Adapter Schema 设计； - Agent Adapter 生成； - Agent Adapter 修复； - JavaScript AST 或结构扫描； - Webpack Runtime 识别； - 模块边界提取； - 模块关系恢复； - Require 和 Export 分析； - 调用关系分析； - 事件关系分析； - 数据流分析； - 分析结果数据模型； - FastAPI 接口开发； - Agent 配置前端页面； - 分析总览页面； - Agent Trace 页面； - 模块图谱页面； - 数据流追踪页面； - Bundle 代码证据页面； - 自然语言查询页面。 第三部分：测试与优化 - Windows 本地测试环境准备； - 后端单元测试； - Agent 接口测试； - Adapter Schema 测试； - 静态分析测试； - API 集成测试； - 前端交互测试； - 模块误识别修复； - Require 误识别修复； - Agent 失败处理测试； - 性能和安全优化。 第四部分：项目发布 - 本地生产方式启动； - GitCode 代码提交； - README 编写； - 项目演示和验收； - API Key 清理； - 本地进程和资源释放。 3. SDD 设计必须包含对应任务要求，每个任务包括： - 需求引用； - 设计引用； - API 设计引用（如适用）； - 数据模型引用（如适用）； - 前序任务检查； - 实现要点； - 验收标准； - 具体测试要求。 4. 每个任务开始前需要提醒读取前序任务完成情况。 5. 任务颗粒度不能过大，需要充分考虑码道上下文长度，确保每个任务可以独立执行和验证。 6. 项目实际源码目录为 E:/BundleScope/src。 7. 项目只在 Windows 本地环境运行，不设计 ECS、CCE、EIP 或容器部署。 8. 文档统一输出到 ProjectDocs/specs_SDD 目录。码道加载 function-detail Skill，对已有需求和系统设计文档进行分析，并生成 BundleScope SDD 文档。3.4.2 人工核验与调整SDD 初步生成完成后，对 spec.md、design.md、tasks.md 和各详细设计文档进行人工检查。根据检查结果，对话码道进行以下调整：#ProjectDocs/specs_SDD 请检查 BundleScope SDD 设计，并完成以下调整： 1. 检查 Windows 本地开发环境部署任务是否包含完整步骤； 2. 检查 FastAPI 项目初始化任务是否包含完整目录结构、核心配置、API 骨架和 Pydantic 数据模型； 3. 检查 Agent Provider 配置是否包含 DeepSeek、GLM 和 Kimi； 4. 检查 Agent 输出是否使用严格 Adapter Schema 校验； 5. 检查是否明确禁止固定 Adapter 回退； 6. 检查 JavaScript 分析设计是否覆盖 AST、Runtime、模块关系、调用关系、事件关系和数据流； 7. 检查所有前端页面是否包含完整设计； 8. 检查代码查看器是否包含行号、定位和高亮设计； 9. 检查每一项任务是否具有明确的需求引用和设计引用； 10. 检查每一项任务是否具有可执行的验收标准； 11. 检查 tasks.md 中的任务颗粒度是否适合码道逐项执行； 12. 不得出现 ECS、CCE、EIP、Linux 或容器部署任务。 如果发现缺失，请直接补充对应文档。3.4.3 需求与设计一致性检查继续使用码道对 systemDesign 和 specs_SDD 两套文档进行一致性检查：#ProjectDocs/systemDesign #ProjectDocs/specs_SDD 请对比 BundleScope 的整体设计文档和 SDD 开发详细设计文档，确保两套文档内容一致且没有功能遗漏。 请重点检查： 1. 每个 SDD 设计和任务都有明确需求引用； 2. Agent 强制接入要求是否在 spec、design 和 tasks 中一致； 3. DeepSeek、GLM 和 Kimi 支持范围是否一致； 4. Agent、Adapter 和静态分析引擎的职责是否一致； 5. Adapter 首轮生成、验证、修复和终止流程是否一致； 6. Module、Edge、Flow、CodeLocation 和 AgentTrace 数据结构是否一致； 7. API 设计是否与实际前端功能一致； 8. 页面设计是否覆盖全部项目功能； 9. 测试任务是否覆盖全部验收标准； 10. 项目是否统一为 Windows 本地运行； 11. 是否存在整体设计中有功能，但 SDD 中没有对应任务的情况； 12. 是否存在 SDD 中新增功能，但需求中没有定义的情况。 如发现不一致，请同步修改相关文档。3.4.4 SDD 综合分析与优化完成前述调整后，对 BundleScope SDD 文档进行最终综合检查：#ProjectDocs/specs_SDD 请从完整性、一致性、合理性和可执行性四个方面，对 BundleScope SDD 开发详细设计进行最终检查。 重点检查： 1. spec.md 是否完整定义项目需求和验收标准； 2. design.md 是否完整定义系统架构和详细设计； 3. tasks.md 是否能够指导码道逐项完成项目开发； 4. 各专项设计文档是否覆盖全部模块； 5. 所有任务是否包含需求引用和设计引用； 6. API、数据模型、前端页面和测试设计是否相互一致； 7. 是否存在过大的任务，需要进一步拆分； 8. 是否存在重复任务或无实际价值的任务； 9. 是否符合项目当前 FastAPI 和原生前端技术栈； 10. 是否符合 Windows 本地开发和运行要求。 如发现问题，请直接完成最优调整。3.5 BundleScope SDD 交付成果经过初步生成、人工核验、一致性检查和综合优化后，码道在 ProjectDocs/specs_SDD 目录下生成了 BundleScope SDD 开发详细设计成果。目录结构如下：ProjectDocs └── specs_SDD ├── design │ ├── 01-JavaScript-AST分析.md │ ├── 02-Webpack-Runtime识别.md │ ├── 03-Adapter管理.md │ ├── 04-Agent调度.md │ ├── 05-模块关系恢复.md │ ├── 06-调用关系分析.md │ ├── 07-事件关系分析.md │ ├── 08-数据流分析.md │ ├── 09-分析结果展示.md │ ├── 10-数据模型详细设计.md │ ├── 11-API接口详细设计.md │ ├── 12-前端详细设计.md │ ├── 13-测试设计.md │ └── design.md ├── spec.md └── tasks.md主要 SDD 文档内容如下：序号文档核心内容1spec.md定义 BundleScope 项目目标、角色、功能需求、非功能需求、业务规则、约束条件、验收标准和需求追踪关系。2design.md定义 FastAPI 后端、原生前端、LLM Agent、Adapter 和静态分析引擎的整体架构，说明工程目录、技术选型、模块划分和本地运行方式。3tasks.md将项目拆分为环境准备、项目初始化、Agent 开发、静态分析开发、前端开发、测试优化和本地发布等可执行任务。401-JavaScript-AST分析.md设计 JavaScript Bundle 结构扫描、语法节点识别、模块工厂候选提取、花括号匹配和代码位置计算方法。502-Webpack-Runtime识别.md设计 Webpack Chunk 注册结构、Module Factory 形式、Runtime 参数角色和不同 Runtime 方言的识别方法。603-Adapter管理.md定义 Adapter 数据结构、Schema 校验、版本管理、执行约束、验证报告和失败处理机制。704-Agent调度.md设计 Bundle 代码采样、Agent Prompt、Provider 调用、JSON 解析、Schema 校验、首轮生成、二次修复和失败终止流程。805-模块关系恢复.md设计 Module ID 提取、Require 调用识别、Export 识别、已解析依赖边构建和未解析调用记录。906-调用关系分析.md设计模块内部函数、模块间调用、Runtime 调用和调用证据的分析与表示方式。1007-事件关系分析.md设计 DOM 事件注册、回调函数、事件触发关系和事件证据定位方法。1108-数据流分析.md设计 Source、Propagation、Sink 数据流模型，以及 Storage、Network、DOM 等典型数据流场景。1209-分析结果展示.md设计分析总览、Agent Trace、Module Graph、数据流路径、自然语言查询和代码证据展示方式。1310-数据模型详细设计.md定义 Provider、Adapter、Observation、Module、Edge、Flow、CodeLocation、Query、Validation 和 AgentTrace 等数据结构。1411-API接口详细设计.md定义健康检查、Provider 查询、连接测试、保存配置、清除配置、上传分析和样例分析等 API。1512-前端详细设计.md设计 Agent 配置弹窗、侧边导航、分析总览、轨迹页面、模块图、数据流、代码查看器和查询页面。1613-测试设计.md定义 Provider、Agent、Adapter、静态分析、API、前端交互、异常处理和本地运行的测试方案。以上文档均为本案例实际使用华为云码道（CodeArts）代码智能体生成并经过多轮检查和调整后的交付成果。由于开发过程中未完整保留码道执行截图，本案例通过 Prompt、实际文档目录和生成结果说明码道参与项目设计的过程。四、对话码道：构建 BundleScope 项目4.1 基础环境准备与项目初始化提示：为避免单次对话内容过长，影响 AI IDE 历史会话加载，建议在正式开发前新建一个码道对话，并先让码道加载当前项目规则、Skills 和 SDD 设计文档。在码道对话框中输入：请加载并激活当前项目的项目级规则和 Skills，同时读取 ProjectDocs/specs_SDD 目录下的 BundleScope SDD 设计文档。稍后我们将按照 tasks.md 开始项目开发。码道读取项目需求、设计和任务文档后，开始进行本地开发环境检查和工程初始化。继续对话码道：#ProjectDocs/specs_SDD #src 请按照 tasks.md 中第一部分“基础环境准备与项目初始化”的要求，检查当前 Windows 本地开发环境，并完成 BundleScope 项目初始化。 要求： 1. 检查 Python、pip 和 Git 是否可用； 2. 在 src 目录下初始化 FastAPI 后端工程； 3. 初始化原生 HTML、CSS、JavaScript 前端目录； 4. 创建 samples 演示 Bundle 目录； 5. 创建 requirements.txt； 6. 创建后端 API 骨架； 7. 创建 Pydantic 数据模型骨架； 8. 创建大模型 Provider 配置模块； 9. 创建 Agent 和静态分析器基础模块； 10. 确保项目可以通过 Uvicorn 在 Windows 本地启动。码道根据 SDD 设计创建了 BundleScope 的基础工程结构。项目主要目录如下：BundleScope ├── ProjectDocs │ ├── specs_SDD │ └── systemDesign ├── src │ ├── backend │ │ ├── __init__.py │ │ ├── agent.py │ │ ├── analyzer.py │ │ ├── main.py │ │ ├── provider_store.py │ │ └── schemas.py │ ├── frontend │ │ ├── index.html │ │ └── assets │ │ ├── app.js │ │ └── style.css │ ├── samples │ │ ├── app.js │ │ └── runtime.js │ └── requirements.txt ├── .gitignore └── README.md基础环境和项目初始化阶段完成了以下工作：建立 FastAPI 后端项目结构；建立原生前端项目结构；创建 Agent、Adapter、静态分析和 Provider 管理模块；创建演示用 JavaScript Bundle；创建依赖配置文件；配置 Git 和 GitCode 项目结构；验证项目可以在 Windows 本地启动。4.2 大模型 Provider 与 Agent 模块开发BundleScope 强制使用真实大模型 Agent，不提供无 Agent 的规则分析模式。对话码道：#src/backend #ProjectDocs/specs_SDD/design/03-Adapter管理.md #ProjectDocs/specs_SDD/design/04-Agent调度.md 请按照 SDD 设计完成 BundleScope 的大模型 Provider 和 Agent 模块开发。 要求： 1. 支持 DeepSeek、智谱 GLM 和 Kimi； 2. 使用 OpenAI 兼容 Python SDK 统一调用； 3. 前端必须先配置 Provider、Model 和 API Key； 4. 保存 Provider 配置前必须执行真实连接测试； 5. API Key 只保存在 FastAPI 当前进程内存中； 6. API Key 不得写入文件、数据库或浏览器 localStorage； 7. Agent 读取 Bundle 代表性片段； 8. Agent 只能返回受约束的 Adapter JSON； 9. 使用 Pydantic 校验 Agent 输出； 10. Agent 不得返回任意 Python、JavaScript 或正则代码； 11. 首轮 Adapter 验证失败时，允许 Agent 进行一次修复； 12. 第二轮仍未通过时终止分析； 13. 不允许回退到固定 Adapter。码道完成了以下核心模块：provider_store.py：保存当前 Provider 和 API Key；schemas.py：定义 Provider、Adapter 和 Agent 输出结构；agent.py：调用真实大模型并生成 Adapter；main.py：提供 Provider 配置和连接测试接口。系统支持以下 Provider：Provider示例模型API Base URLDeepSeekdeepseek-v4-flashhttps://api.deepseek.com智谱 GLMglm-5.1https://open.bigmodel.cn/api/paas/v4Kimikimi-k2.6https://api.moonshot.cn/v1Agent 执行流程如下：Bundle 文件输入 → 提取代表性代码片段 → 调用真实大模型 → 生成 Adapter JSON → Pydantic Schema 校验 → 确定性分析器执行 Adapter → 验证模块数量和依赖解析率 → 必要时调用 Agent 修复 → 返回分析结果4.3 JavaScript Bundle 静态分析模块开发完成 Agent 接入后，继续开发 JavaScript Bundle 静态分析模块。对话码道：#src/backend/analyzer.py #ProjectDocs/specs_SDD/design/01-JavaScript-AST分析.md #ProjectDocs/specs_SDD/design/02-Webpack-Runtime识别.md #ProjectDocs/specs_SDD/design/05-模块关系恢复.md 请按照 SDD 设计完成 BundleScope 的 JavaScript Bundle 静态分析模块。 要求： 1. 接收 Agent 生成并通过 Schema 校验的 Adapter； 2. 根据 Adapter 识别 Webpack Chunk 注册结构； 3. 提取 Module Factory； 4. 恢复 Module ID； 5. 识别 Runtime require 参数； 6. 提取模块加载关系； 7. 提取模块导出； 8. 构建 Module Graph； 9. 记录未解析 Runtime 调用； 10. 保存文件名、模块起止行和代码证据； 11. 禁止静态分析器自行选择默认 Adapter； 12. 禁止在 Agent 失败后使用固定规则继续分析。静态分析器完成了以下能力：提取 Webpack Chunk；识别数字 Module ID；提取模块起止位置；恢复模块依赖关系；提取模块导出；计算 Require 解析率；构建模块关系边；保存原始 Bundle 文件和行号证据。在初始实现中，曾出现普通函数被误识别为 Module 的问题，例如：push send render同时也出现过普通函数参数被误识别为 Module Require 的问题，例如：.search-button针对上述问题，对话码道进行修复：#src/backend/analyzer.py 请检查当前模块识别和 Require 识别逻辑，修复以下问题： 1. 不得将 push、send、render 等普通函数识别为 Module； 2. 不得将 querySelector(".search-button") 等普通函数调用识别为模块加载； 3. Module Factory 必须根据 Agent Adapter 指定的声明形式提取； 4. Require 必须只匹配 Runtime 参数调用； 5. 模块图中只展示目标 Module ID 已经存在的依赖边； 6. 保留未解析 Runtime 调用，但不得加入 Module Graph； 7. 修复后使用 samples 目录中的演示 Bundle 验证。修复后，演示样例能够正确识别以下 Module：413 645 821 900正确恢复以下依赖关系：413 → 645 413 → 8214.4 数据流分析模块开发模块关系恢复完成后，继续开发跨模块数据流分析功能。对话码道：#src/backend/analyzer.py #ProjectDocs/specs_SDD/design/06-调用关系分析.md #ProjectDocs/specs_SDD/design/07-事件关系分析.md #ProjectDocs/specs_SDD/design/08-数据流分析.md 请按照 SDD 设计完成 BundleScope 的调用关系、事件关系和数据流分析。 要求： 1. 定义 Source、Propagation 和 Sink 数据流节点； 2. 支持识别 localStorage.getItem； 3. 支持识别 fetch 网络请求； 4. 支持识别 DOM 输入； 5. 支持识别网络响应写入 DOM； 6. 数据流节点包含文件名、Module ID 和行号； 7. 数据流分析基于 Agent Adapter 恢复出的模块结构； 8. 分析结果必须能够跳转到原始代码； 9. 不允许由大模型直接编造最终数据流结论。BundleScope 内置了以下典型数据流场景：Storage → Network；DOM Input → Network；Network Response → DOM。演示样例中可以识别以下数据流：localStorage.getItem("token") → 模块间变量和调用传播 → fetch("/api/search", ...)每个数据流节点均保留：文件名；Module ID；代码行号；匹配到的代码片段。4.5 后端 API 开发完成 Agent 和静态分析模块后，继续开发 FastAPI 接口。对话码道：#src/backend/main.py #ProjectDocs/specs_SDD/design/11-API接口详细设计.md 请按照 API 详细设计完成 BundleScope 后端接口。 要求： 1. 提供健康检查接口； 2. 提供 Provider 列表查询接口； 3. 提供 Provider 当前状态查询接口； 4. 提供 Provider 连接测试接口； 5. 提供 Provider 配置保存接口； 6. 提供 API Key 清除接口； 7. 提供 Bundle 文件上传分析接口； 8. 提供演示样例分析接口； 9. 未配置 Provider 时，分析接口返回明确错误； 10. 上传文件只允许 JavaScript； 11. 限制单文件和总文件大小； 12. Agent 调用错误不得泄露 API Key； 13. Agent 两轮验证失败后返回分析终止信息； 14. 前端静态资源由 FastAPI 统一提供。主要 API 包括：GET /api/health GET /api/providers GET /api/provider POST /api/provider/test POST /api/provider DELETE /api/provider POST /api/analyze GET /api/sample其中：/api/provider/test 用于调用真实模型测试连接；/api/provider 用于验证并保存当前内存配置；/api/analyze 用于上传多个 Bundle 文件并执行 Agent 分析；/api/sample 用于分析项目内置演示样例。4.6 前端界面开发后端接口开发完成后，使用 frontend-design Skill 辅助完成 BundleScope 前端。对话码道：#src/frontend #ProjectDocs/specs_SDD/design/09-分析结果展示.md #ProjectDocs/specs_SDD/design/12-前端详细设计.md 请按照前端详细设计完成 BundleScope 前端页面。 要求： 1. 使用原生 HTML、CSS 和 JavaScript； 2. 页面采用左侧导航栏和右侧工作区布局； 3. 首次进入强制弹出 Agent Provider 配置窗口； 4. 未配置 Agent 时禁用上传和样例分析； 5. 支持选择 DeepSeek、GLM 和 Kimi； 6. 支持填写 Model、API Key 和 Base URL； 7. 显示 Provider 连接测试结果； 8. 显示分析总览； 9. 显示 Agent Trace； 10. 显示 Agent 生成的 Adapter JSON； 11. 使用 SVG 展示 Module Graph； 12. 支持点击 Module 查看详细信息； 13. 显示数据流路径； 14. 支持点击数据流节点跳转代码； 15. 增加 Bundle 原始代码查看器； 16. 显示代码行号； 17. 支持代码范围高亮； 18. 支持自然语言查询确定性分析结果； 19. 不允许前端伪造 Agent Trace。前端主要页面包括：分析总览；Agent Trace；Module Graph；数据流追踪；Bundle 代码证据；自然语言查询。首次打开页面时，系统要求配置真实大模型 Provider。配置成功后，用户才能上传 Bundle 或运行演示样例。4.7 代码证据查看器开发为了使分析结果可人工复核，在前端新增 Bundle 代码证据查看器。对话码道：#src/frontend/index.html #src/frontend/assets/app.js #src/frontend/assets/style.css 请在 BundleScope 前端增加代码证据查看器。 要求： 1. 支持切换不同 JavaScript 文件； 2. 显示完整 Bundle 原始代码； 3. 显示从 1 开始的代码行号； 4. 点击 Module 后定位模块起止行； 5. 点击 Source 或 Sink 后定位对应代码行； 6. 对目标代码范围进行高亮； 7. 对主证据行进行重点高亮； 8. 显示当前证据说明； 9. 支持清除高亮； 10. 不依赖第三方代码高亮库。开发过程中发现 JavaScript 正则表达式使用了不支持的多行写法和 /x 标志，导致前端代码标红。随后对话码道修复：#src/frontend/assets/app.js 请修复 highlightCode 函数中的 JavaScript 正则语法错误。 要求： 1. JavaScript 正则不得跨行直接编写； 2. 删除 JavaScript 不支持的 x 标志； 3. highlightCode 函数只能保留一份； 4. 保留关键词、字符串、数字和注释的基础高亮； 5. 确保浏览器控制台无语法错误。修复后，代码查看器能够正常展示并高亮 Bundle 代码。4.8 Agent 强制模式调整在早期页面中，系统曾使用“Agent 适配结果”等描述，但后端实际只执行固定静态规则，并没有调用真实大模型。经过检查后，对项目架构进行调整，改为强制真实 Agent 模式。对话码道：#src #ProjectDocs/specs_SDD 请将 BundleScope 调整为强制真实 LLM Agent 模式。 要求： 1. 删除无 Agent 的规则分析入口； 2. 未配置 API Key 时禁止分析； 3. Provider 连接测试失败时禁止保存； 4. LLM 调用失败时直接终止； 5. Agent 返回非 JSON 时直接终止； 6. Adapter Schema 校验失败时直接终止； 7. 首轮验证失败时调用 Agent 修复； 8. 第二轮验证失败时终止； 9. 禁止使用默认 Webpack Adapter 回退； 10. 前端增加真实 Agent Trace； 11. 前端显示模型实际生成的 Adapter JSON； 12. 支持 DeepSeek、GLM 和 Kimi； 13. API Key 仅保存在后端进程内存中。调整完成后，系统的真实工作方式为：真实 LLM Agent 识别 Runtime → 生成受约束 Adapter → Pydantic 校验 → 静态引擎确定性执行 → 验证模块和依赖恢复结果 → 必要时由 Agent 修复4.9 项目开发检验与补充主要功能开发完成后，使用码道对项目进行整体检查。对话码道：#src #ProjectDocs/specs_SDD/tasks.md 请深度检索 BundleScope 项目，检查 tasks.md 中项目开发阶段的任务是否全部完成。 重点检查： 1. Provider 配置是否完整； 2. DeepSeek、GLM 和 Kimi 是否全部支持； 3. Agent 是否真实调用； 4. 是否存在固定 Adapter 回退； 5. Adapter Schema 是否完整； 6. 模块识别是否存在误报； 7. Require 识别是否存在误报； 8. 数据流是否包含代码证据； 9. Agent Trace 是否来自真实后端结果； 10. 代码查看器是否可以定位 Module、Source 和 Sink； 11. API 是否与前端调用一致； 12. requirements.txt 是否包含全部依赖； 13. README 是否包含 Windows 本地运行方法。 如果存在未完成、冲突或错误，请直接补充和修复。项目检查过程中，主要完成了以下优化：修复普通函数被识别为 Module 的问题；修复 CSS 选择器被识别为 Require 的问题；修复前端 JavaScript 正则语法错误；增加 Agent Provider 强制配置；增加 Agent Trace；增加 Adapter JSON 展示；增加代码证据查看器；增加 API Key 清除功能；完善 Windows 本地启动说明；完善 .gitignore 和 GitCode 仓库配置。4.10 开发阶段成果总结4.10.1 后端架构BundleScope 后端基于 FastAPI 开发，主要包含以下模块：src/backend ├── main.py ├── agent.py ├── analyzer.py ├── schemas.py ├── provider_store.py └── __init__.py各模块职责如下：模块主要职责main.pyFastAPI 应用入口、Provider 接口、上传分析接口和前端静态资源服务agent.py调用 DeepSeek、GLM 或 Kimi，生成和修复 Adapteranalyzer.py执行 Agent Adapter，恢复模块关系和分析数据流schemas.py定义 Provider、Adapter 和分析结果数据结构provider_store.py在后端进程内存中保存 API Key 和模型配置__init__.py标记 backend 为 Python 包后端主要能力包括：Provider 配置和连接测试；Bundle 代码采样；真实 LLM Agent 调用；Adapter JSON 解析；Pydantic Schema 校验；Agent 二次修复；Webpack Runtime 分析；Module Factory 提取；Require 和 Export 恢复；Module Graph 构建；数据流路径检测；代码位置和证据输出。4.10.2 前端架构BundleScope 前端采用原生 HTML、CSS 和 JavaScript 实现。主要文件如下：src/frontend ├── index.html └── assets ├── app.js └── style.css前端主要功能包括：Agent Provider 配置弹窗；Provider 连接测试；Bundle 多文件上传；演示样例分析；分析指标总览；Agent Trace；Adapter JSON 查看；SVG Module Graph；模块详情；数据流路径；Bundle 原始代码查看；代码定位和高亮；基于静态分析结果的查询。4.10.3 Agent 与 Adapter 架构BundleScope 中 Agent 和静态分析引擎职责分离。Agent 负责：阅读 Bundle 代表性代码片段；判断 Webpack Runtime 类型；判断 Module Factory 声明形式；判断 Runtime 参数索引；判断 Require 和 Export 协议；输出受约束 Adapter；根据验证报告修复 Adapter。静态分析引擎负责：执行 Adapter；提取模块；恢复依赖；构建模块图；检测数据流；计算验证指标；输出文件名和代码行号证据。Agent 不直接输出最终 Module Graph 或数据流结论。4.10.4 演示样例分析结果系统内置两个演示 Bundle：src/samples/app.js src/samples/runtime.js正常分析时，可识别以下模块：413 645 821 900可恢复以下模块依赖：413 → 645 413 → 821可检测以下典型数据流：localStorage.getItem("token") → 模块调用传播 → fetch("/api/search", ...)用户可以从 Module Graph 或数据流页面直接跳转到原始 Bundle 代码位置，并查看对应代码高亮。4.10.5 本地运行方式进入项目源码目录：cd E:\BundleScope\src创建并激活虚拟环境：py -m venv .venv .\.venv\Scripts\Activate.ps1安装依赖：python -m pip install -r requirements.txt启动服务：python -m uvicorn backend.main:app --reload --port 8000 浏览器访问：http://127.0.0.1:8000进入系统后，需要先配置并验证 DeepSeek、GLM 或 Kimi API Key，才能执行 Bundle 分析。以上为使用华为云码道（CodeArts）代码智能体，按照 BundleScope SDD 设计逐步完成项目构建、检查和优化的主要过程。五、运行调试与功能验证5.1 启动后端服务BundleScope 前端静态资源由 FastAPI 统一提供，因此不需要单独启动前端开发服务器。打开 PowerShell，进入项目源码目录：cd E:\BundleScope\src激活 Python 虚拟环境：.\.venv\Scripts\Activate.ps1如果项目依赖尚未安装，执行：python -m pip install -r requirements.txt启动 FastAPI 服务：python -m uvicorn backend.main:app --reload --port 8000 终端出现类似以下内容，表示后端服务启动成功：INFO: Uvicorn running on http://127.0.0.1:8000 INFO: Started reloader process INFO: Application startup complete5.2 访问 BundleScope在浏览器中访问：http://127.0.0.1:8000首次打开系统时，BundleScope 会显示 Agent 配置窗口。在完成真实大模型 Provider 配置前，系统禁止上传 JavaScript Bundle 或运行演示分析。Agent 配置窗口包含以下内容：Provider；Model；API Key；Base URL；测试连接；验证并保存。5.3 配置并验证大模型 Agent在 Agent 配置窗口中选择一个可用的大模型 Provider。本案例支持：Provider模型示例DeepSeekdeepseek-v4-flash智谱 GLMglm-5.1Kimikimi-k2.6填写 API Key 后，点击“测试连接”。系统会通过后端真实调用所选模型。连接成功后，页面显示模型响应耗时。测试成功后，点击“验证并保存”。系统会再次执行真实连接验证，验证成功后将 Provider 配置保存在当前 FastAPI 进程内存中。5.4 运行演示样例分析完成 Agent 配置后，点击页面右上角的“Agent 分析演示样例”。系统依次执行以下流程：读取演示 Bundle → 提取代表性代码片段 → 调用真实大模型 Agent → 生成 Adapter JSON → 执行 Pydantic Schema 校验 → 确定性静态分析器执行 Adapter → 恢复模块和依赖关系 → 分析数据流和代码证据分析完成后进入分析总览页面。页面展示：文件数量；Chunk 数量；Module 数量；依赖边数量；Require 解析率；数据流数量；当前 Provider；当前模型；Agent 置信度；Adapter 验证状态；输入文件列表；Agent observations。5.5 查看 Agent 执行轨迹点击左侧导航栏中的“Agent Trace”。该页面展示本次分析中实际执行的 Agent 工作步骤，包括：Bundle 结构采样；LLM Runtime 勘察；Adapter 生成；确定性 Adapter 验证；必要时进行 Adapter 修复；分析完成。页面同时显示：Provider；Model；模型调用耗时；Adapter 生成轮次；模块数量；Require 解析率；验证状态。5.6 查看 Agent 生成的 Adapter在 Agent Trace 页面向下查看“Agent 生成的 Adapter JSON”。该 JSON 是大模型根据 Bundle 代表性片段生成，并经过 Pydantic Schema 校验后的实际 Adapter 配置。Adapter 中主要包含：构建工具类型；Runtime 类型；Agent 置信度；Chunk 注册结构；Module Factory 声明方式；Module ID 类型；Runtime 参数索引；Require 调用方式；Export Helper 方法；Agent observations。5.7 查看模块关系图点击左侧导航栏中的“模块图谱”。演示样例正常分析后，应识别以下 Module：413 645 821 900其中模块依赖关系为：413 → 645 413 → 821点击 Module 413，右侧模块详情显示：Module ID；所属文件；Chunk ID；起止行号；Requires；Unresolved；Exports；Evidence。正常情况下，Module 413 的 Requires 应为：645 821系统不应将以下普通函数或字符串识别为 Module 或 Require：push send render .search-button5.8 查看跨模块数据流点击左侧导航栏中的“数据流追踪”。演示样例中可以识别 Storage 到 Network 的数据流：localStorage.getItem("token") → 变量赋值与模块调用传播 → fetch("/api/search", ...)数据流节点包括：Source；Propagation；Sink。每个节点均展示：代码片段；文件名；Module ID；代码行号。5.9 查看原始代码证据在数据流页面点击 Source 节点或 Sink 节点，系统自动跳转到“代码证据”页面。代码证据页面支持：切换 app.js 和 runtime.js；显示完整 Bundle 原始代码；显示代码行号；自动滚动到目标代码；高亮 Module 范围；高亮 Source 或 Sink 所在行；显示当前证据说明。可以先点击 Source 节点，查看：localStorage.getItem("token") 再点击 Sink 节点，查看：fetch("/api/search", ...) 5.10 功能验证结果经过运行和验证，BundleScope 已完成以下功能：验证项验证结果Windows 本地启动通过Agent Provider 强制配置通过DeepSeek、GLM 或 Kimi 连接测试通过未配置 API Key 时禁止分析通过真实 LLM Agent 调用通过Adapter JSON 生成通过Pydantic Schema 校验通过Webpack Runtime 识别通过Module Factory 提取通过模块依赖恢复通过Require 解析率计算通过数据流路径识别通过Agent Trace 展示通过Adapter JSON 展示通过Module Graph 交互通过原始代码定位和高亮通过API Key 内存保存和清除通过Agent 失败后禁止规则回退通过演示样例的主要分析结果如下：文件数量：2 Module 数量：4 Module ID：413、645、821、900 依赖边数量：2 依赖关系： 413 → 645 413 → 821 Require 解析率：100%通过上述验证可以确认，BundleScope 已实现真实大模型 Agent 驱动的 JavaScript Bundle Runtime 自适应识别，并能够使用确定性静态分析引擎恢复模块关系、追踪数据流和展示原始代码证据。六、扩展资料说明通过本案例，开发者可以进一步了解华为云码道（CodeArts）代码智能体、FastAPI、Pydantic、JavaScript Bundle、Webpack Runtime 和大模型 Agent 等相关技术。6.1 华为云码道（CodeArts）代码智能体华为云码道（CodeArts）代码智能体是一款将 AI 能力集成到 IDE 中的智能编码工具，支持智能体对话、项目级代码生成、代码修改、研发知识问答、测试用例生成和规范驱动开发等能力。本案例使用码道完成了 BundleScope 的需求分析、系统设计、SDD 文档生成、任务拆分、代码开发和问题修复。相关资料：华为云码道（CodeArts）代码智能体产品介绍华为云码道（CodeArts）代码智能体快速启动华为云码道（CodeArts）代码智能体智能体对话SDD 开发模式标准工作流与斜杠命令实践6.2 FastAPIFastAPI 是一个基于 Python 类型提示构建 Web API 的现代框架，具有性能较高、开发效率高、自动数据校验和自动生成接口文档等特点。BundleScope 使用 FastAPI 提供以下能力：Provider 配置接口；大模型连接测试接口；JavaScript Bundle 上传接口；演示样例分析接口；前端静态资源服务；API 参数与返回结果校验。相关资料：https://fastapi.tiangolo.com/ https://fastapi.tiangolo.com/tutorial/ 启动 BundleScope 后，还可以通过以下地址查看 FastAPI 自动生成的 Swagger API 文档：http://127.0.0.1:8000/docs6.3 PydanticPydantic 是一个基于 Python 类型提示的数据校验库。本案例使用 Pydantic 对以下数据进行结构化定义和校验：Provider 配置；Agent 输出；Adapter 配置；Module Factory 参数；Require 和 Export 规则；Agent Observation；验证结果。通过 Pydantic Schema，可以限制大模型 Agent 只能输出系统允许的 Adapter 字段，避免模型返回任意代码或不符合要求的数据结构。相关资料：https://docs.pydantic.dev/ 6.4 JavaScript Bundle 与 Webpack Runtime现代 JavaScript 项目通常会经过 Webpack、Vite、Rollup 等构建工具进行模块打包、代码压缩和文件拆分。Webpack 打包产物通常包含：Chunk 注册结构；Module Factory；Module ID；Runtime Require；Export Helper；异步模块加载逻辑。BundleScope 主要针对缺少 Source Map 的 Webpack 构建产物，通过大模型 Agent 识别 Runtime 方言，再由确定性分析器恢复模块边界和模块关系。相关资料：https://webpack.js.org/concepts/ https://webpack.js.org/concepts/modules/ https://webpack.js.org/concepts/under-the-hood/ 6.5 大模型 Agent 与结构化输出BundleScope 中的大模型 Agent 不直接生成最终模块图和数据流结果，而是负责识别 Bundle Runtime，并生成受约束的 Adapter JSON。其基本流程如下：Bundle 代码采样 → 大模型理解 Runtime 结构 → 输出 Adapter JSON → Pydantic Schema 校验 → 确定性静态分析器执行 → 结果验证 → 必要时由 Agent 修复 Adapter这种设计将大模型的语义理解能力与传统静态分析的确定性结合起来，可以降低不同构建方言的适配成本，同时保留分析结果的可验证性。开发者可以进一步学习以下方向：Prompt 设计；JSON 结构化输出；Agent 工具调用；Agent 结果验证；Agent 自我修复；大模型幻觉控制；确定性工具与大模型协同。6.6 DeepSeek、智谱 GLM 与 KimiBundleScope 支持通过 OpenAI 兼容接口接入 DeepSeek、智谱 GLM 和 Kimi。使用相关模型前，需要在对应平台申请 API Key，并确认账号具有所选模型的调用权限。相关资料：https://api-docs.deepseek.com/ https://docs.bigmodel.cn/ https://platform.moonshot.cn/docs注意：模型名称、API 地址、计费方式和可用额度可能发生变化，实际使用时应以对应平台的最新文档和控制台信息为准。6.7 GitCode 项目仓库BundleScope 项目源码存放在 GitCode，开发者可以通过以下地址查看或克隆项目：https://gitcode.com/HuaaweeiNB/BundleScope\克隆命令如下：git clone https://gitcode.com/HuaaweeiNB/BundleScope.git项目实际源码位于：BundleScope/src6.8 项目后续扩展方向当前 BundleScope 已实现真实大模型 Agent 驱动的 Webpack Bundle 分析原型，后续可以从以下方向继续扩展：引入正式 JavaScript AST 解析器，替代部分文本结构扫描；支持更多 Webpack Runtime 版本；支持 Vite、Rollup、Parcel 等构建工具；支持字符串 Module ID 和混合 Module ID；支持异步 Chunk 加载关系恢复；增加完整函数调用图；增加事件注册和回调关系分析；增加跨函数污点传播分析；增加更多 Source 和 Sink 规则；支持分析结果导出；支持大型 Bundle 分片分析；增加 Adapter 缓存和版本管理；增加 Agent 评测和结果对比机制；增加自动化单元测试和端到端测试；支持多人和多项目的独立 API Key 管理。通过上述扩展，可以进一步提升 BundleScope 对真实生产构建产物的兼容性、分析精度和工程实用性。

一、概述1.1 案例介绍随着软件开发规模不断扩大，开发人员在编码过程中经常遇到大量异常问题，例如 Java 空指针异常、Spring Boot 启动失败、数据库连接异常、Python 类型错误等。传统解决方式通常依赖搜索引擎查询错误信息，开发者虽然能够快速找到解决方案，但往往无法理解错误产生原因，也难以形成长期可复用的知识积累。Bug 炼金工坊（BugAlchemy） 帮助开发者从“解决 Bug”进一步升级为“理解 Bug、沉淀 Bug”，将每一次程序错误视为可学习的数据资产，通过 AI 技术完成错误信息解析、异常原因解释、修复步骤生成、薄弱知识点归因、复习卡片生成、个人知识画像分析。本案例基于华为云码道（CodeArts）代码智能体，从需求设计、系统架构规划、前后端开发到功能调试，全流程辅助构建。代码仓库：cid:link_01.2 适用对象高校学生个人开发者企业开发者1.3 案例时间本案例总时长预计 60 分钟。1.4 案例流程说明：准备本地开发环境，创建项目目录；在 CodeArts 代码智能体中输入需求，智能体自动生成前后端完整代码；安装项目依赖，遇到原生模块编译问题时由智能体自动适配解决；启动前后端服务，验证系统核心功能。1.5 资源总览资源名称规格单价（元）华为云码道（CodeArts）代码智能体专业版优惠券覆盖范围 二、环境和资源准备2.1 准备云开发环境登录华为开发者空间，点击菜单 开发平台 > 云开发环境 > 容器，创建云开发环境容器版。2.2 安装基础工具在云开发环境中确认以下工具已安装：JDK 17+（java -version 验证）Node.js 18+（node -v 验证）MySQL 8.x（mysql --version 验证）Git（git --version 验证）2.3 下载项目源码通过 git 下载源码到本地：git clone cid:link_0 三、构建 BugAlchemy 应用3.1 项目结构说明项目采用前后端分离架构，目录结构如下：BugAlchemy/├── bugalchemy-frontend/         # 前端 Vue3 项目│   ├── src/│   │   ├── api/                 # API 接口层（diagnosis.js, auth.js, request.js）│   │   ├── components/           # 组件（BugInputPanel, ErrorHighlight, ReviewFlipCard, ScanProgress, WeaknessChart）│   │   ├── views/               # 页面视图（Home, DiagnosisResult, CardLibrary, KnowledgeProfile, WeeklyReport, Login）│   │   ├── router/               # Vue Router 路由配置│   │   ├── mock/                 # Mock 数据│   │   ├── style.css             # 全局暗色主题 CSS 变量│   │   ├── App.vue               # 根组件（导航栏）│   │   └── main.js               # 入口文件│   ├── vite.config.js           # Vite 配置（含 API 代理）│   └── package.json├── bugalchemy-backend/           # 后端 Spring Boot 项目│   ├── src/main/java/com/bugalchemy/│   │   ├── config/               # 配置类（CorsConfig, JwtAuthConfig, GlobalExceptionHandler, DataInitializer）│   │   ├── controller/           # 控制器（Diagnosis, ReviewCard, Profile, WeeklyReport, Auth, Health）│   │   ├── dto/                 # 数据传输对象│   │   ├── entity/               # 实体类│   │   ├── mapper/               # MyBatis Mapper│   │   ├── service/             # 服务接口与实现│   │   │   └── impl/             # 服务实现（含 MockAiDiagnosisService）│   │   └── utils/               # 工具类（ErrorParser, JwtUtil）│   ├── src/main/resources/│   │   ├── sql/                 # 建表 SQL + 初始化数据│   │   ├── application.properties       # 运行时配置（已加入 .gitignore）│   │   └── application-example.properties # 配置模板│   └── pom.xml└── deploy/                       # 部署配置（Nginx + 启动脚本）3.2 使用 CodeArts 生成 PRD 文档CodeArts 生成了完整的 PRD 文档，包括项目背景、用户痛点、创新点、8 大功能模块、用户操作流程、页面结构设计、系统架构设计、数据库表设计、API 接口设计。关键设计决策：炼金隐喻：将 Bug 诊断流程包装为"炼金工坊"体验——报错是原料、诊断是提纯、修复是冶炼、知识卡片是结晶、画像和周报是沉淀bug-diagnosis-skill 可替换架构：AI 诊断能力封装为独立 Skill 接口，当前用规则引擎实现，未来可无缝替换为真实大模型五步炼金流程：原料投入 → 线索提纯 → 修复冶炼 → 知识结晶 → 复习沉淀3.3 使用 CodeArts 生成前端项目CodeArts 的输出：一次性生成了完整的前端骨架，包括：5 个页面视图 + 5 个组件vue-router 路由配置Axios 封装 + 11 个 API 接口mock 数据（所有页面的兜底数据）深色科技风 CSS 变量体系（--bg-primary、--gold-primary 等）npm run build 一次通过关键代码讲解 — 暗色主题 CSS 变量体系：src/style.css 定义了完整的暗色主题变量，炼金主题金色作为强调色贯穿全局：:root {  --bg-primary: #0D1117;  --bg-secondary: #161B22;  --text-primary: #E6EDF3;  --text-secondary: #8B949E;  --gold-primary: #D4A843;  --gold-glow: rgba(212, 168, 67, 0.3);  --diagnosis-green: #3FB950;  --warning-orange: #D29922;  --error-red: #F85149;  --info-blue: #58A6FF;}关键代码讲解 — BugInputPanel 自动识别逻辑：src/components/BugInputPanel.vue 实现了编程语言自动识别，默认选项为"自动识别"，用户也可手动选择：const detectedLang = computed(() => { const text = errorText.value.toLowerCase() if (text.includes('java.lang.') || text.includes('.java:')) return 'JAVA' if (text.includes('traceback') || text.includes('importerror')) return 'PYTHON' if (text.includes('mysql') || text.includes('sql')) return 'SQL' if (text.includes('cannot find module') || text.includes('npm err')) return 'JAVASCRIPT' if (text.includes('error cs')) return 'CSHARP' if (text.includes('segmentation fault') || text.includes('gcc')) return 'C_CPP' if (text.includes('rustc') || text.includes('cargo')) return 'RUST' if (text.includes('goroutine') || text.includes('go.mod')) return 'GO' if (text.includes('spring') || text.includes('tomcat')) return 'SPRING_BOOT' return ''})​const effectiveLang = computed(() => { return selectedLang.value === 'auto' ? detectedLang.value : selectedLang.value})3.4 使用 CodeArts 生成后端项CodeArts 的输出：生成了完整的后端骨架，包括：7 个 Entity + 6 个 Mapper + 5 个 ServiceErrorParser 工具类（9 种语言报错解析）统一 Result<T> 响应格式CorsConfig + GlobalExceptionHandler + MyBatisConfig建表 SQL（7 张表）+ 初始化数据 SQLmvn compile 一次通过过程中发现的问题及 CodeArts 辅助修复：问题修复方式Spring Boot 4.x 不自动注册 ObjectMapper BeanJwtAuthConfig 中手动 new ObjectMapper()ErrorParser port 关键词大小写不匹配改为 text.toLowerCase().contains("port")DiagnosisServiceImpl.getDetail 未填充 reviewCard 字段补充 reviewCard 查询和填充，无卡片时兜底空对象init-data.sql 重复执行主键冲突改用 INSERT IGNOREElement Plus prefix-icon 不接受字符串改为 :prefix-icon="User" 组件引用关键代码讲解 — ErrorParser 多语言解析：ErrorParser 是 bug-diagnosis-skill 的规则引擎核心，通过 parse(errorText, language) 入口分发到不同语言的解析方法：public static ParseResult parse(String errorText, String language) {    String detectedLang = (language != null && !language.isBlank())         ? language : detectLanguage(errorText);    return switch (detectedLang.toUpperCase()) {        case "JAVA" -> parseJavaError(errorText);        case "SPRING_BOOT" -> parseSpringBootError(errorText);        case "PYTHON" -> parsePythonError(errorText);        case "SQL" -> parseSqlError(errorText);        case "JAVASCRIPT" -> parseJavaScriptError(errorText);        case "CSHARP" -> parseCSharpError(errorText);        case "C_CPP" -> parseCppError(errorText);        case "RUST" -> parseRustError(errorText);        case "GO" -> parseGoError(errorText);        default -> parseGenericError(errorText);    };}当前已覆盖 9 种编程语言、25+ 种异常类型的结构化解析：语言异常类型JavaNullPointerException、ClassNotFoundException、ClassCastException、通用 ExceptionSpring BootPortInUseException、BeanCreationExceptionPythonModuleNotFoundError、TypeError、IndexErrorSQLTable doesn't exist、Unknown column、Duplicate entryJavaScriptCannot find module、TypeError(undefined)、ECONNREFUSEDC#CS0234(命名空间)、CS1061(成员不存在)C/C++Segmentation Fault、Undefined ReferenceRustE0425(作用域)、E0308(类型不匹配)Godeclared but not used、runtime panic关键代码讲解 — AiDiagnosisService 可替换架构：public interface AiDiagnosisService {   DiagnosisResultDTO diagnose(DiagnosisRequestDTO request);}当前实现 MockAiDiagnosisService，替换为真实 AI 时只需新建实现类并切换 @Service 注解，零改动业务层和前端。3.5 使用 CodeArts 生成单元测试CodeArts 的输出：生成了 15 个测试用例，全部通过：语言测试场景JavaNullPointerException、ClassNotFoundException、ClassCastException、通用 ExceptionSpring Boot端口占用（含大小写 Port 8080）、BeanCreationExceptionPythonModuleNotFoundError、TypeError、IndexError、通用 Python 错误SQL表不存在、字段不存在、唯一键冲突、通用 SQL 错误边界空字符串、null 输入、自动语言检测Tests run: 15, Failures: 0, Errors: 0, Skipped: 0BUILD SUCCESS3.6 运行调试1）初始化数据库mysql -u root -p -e "CREATE DATABASE IF NOT EXISTS bugalchemy DEFAULT CHARSET utf8mb4;"mysql -u root -p bugalchemy < bugalchemy-backend/src/main/resources/sql/schema.sqlmysql -u root -p bugalchemy < bugalchemy-backend/src/main/resources/sql/init-data.sql2）配置后端复制配置模板并修改数据库密码：cp bugalchemy-backend/src/main/resources/application-example.properties bugalchemy-backend/src/main/resources/application.properties编辑 application.properties，将 YOUR_PASSWORD_HERE 替换为实际 MySQL 密码。3）启动后端cd bugalchemy-backendmvn spring-boot:run4）启动前端cd bugalchemy-frontendnpm installnpm run dev5）访问应用使用演示账号登录：字段值用户名demo密码1234566）测试诊断功能粘贴以下报错文本进行测试：样例输入预期异常类型Java NPEjava.lang.NullPointerException at com.example.Service.process(Service.java:42)NullPointerExceptionSpring 端口Web server failed to start. Port 8080 was already in use.PortInUseExceptionPython 模块ModuleNotFoundError: No module named 'flask'ModuleNotFoundErrorJS 模块Error: Cannot find module 'express'ModuleNotFoundErrorRust 作用域error[E0425]: cannot find value 'count' in this scopeE0425Go 未使用./main.go:5:2: count declared but not usedUnusedDeclError 四、系统架构设计4.1 整体架构4.2 技术栈层级技术说明前端Vue3 + Vite + Element Plus + ECharts深色科技风 + 炼金元素后端Spring Boot 4.x + MyBatisRESTful API，统一 Result<T> 响应数据库MySQL 8.x7 张业务表，JSON 字段存复杂结构AI 诊断bug-diagnosis-skill (MockAiDiagnosisService)当前规则引擎兜底，可替换为真实大模型鉴权JWT (jjwt) + BCrypt注册登录 + Token 校验 + 用户数据隔离4.3 数据库设计表结构总览表名说明关键字段t_user用户表username, password_hash, nicknamet_diagnosis_record诊断记录表user_id, error_text, exception_type, statust_knowledge_point知识点表name, category, descriptiont_diagnosis_knowledge_ref诊断-知识点关联表diagnosis_id, knowledge_id, severityt_knowledge_mastery知识掌握度表user_id, knowledge_id, error_count, fix_count, mastery_scoret_review_card复习卡片表user_id, diagnosis_id, front_content, back_content, mastery_level, next_review_att_weekly_report周报复盘表user_id, week_start, week_end, total_errors, fixed_errors 五、解决方案5.1 五步炼金流程BugAlchemy 将 Bug 诊断流程包装为"炼金工坊"体验，形成完整的知识闭环：步骤炼金隐喻对应功能说明1报错原料BugInputPanel用户粘贴原始报错文本，自动识别编程语言2线索提纯ErrorParser + ErrorHighlight从报错中提取异常类型、位置、端口等关键线索并高亮3修复冶炼诊断结果页生成人话解释和可执行修复步骤4知识结晶知识点归因 + ReviewFlipCard将报错映射到知识点，生成复习卡片5复习沉淀知识画像 + 周复盘间隔重复复习，统计薄弱趋势，沉淀为长期记忆5.2 功能模块炼金台（首页）报错输入面板（BugInputPanel）：支持粘贴多行报错文本，自动检测编程语言最近诊断记录：展示最近 10 条诊断历史待复习卡片提醒：显示今日到期需复习的卡片数量诊断结果原始报错高亮展示（ErrorHighlight）：片段级精准高亮，支持关键词匹配和偏移量匹配异常信息：类型 + 位置 + 简短描述人话根因解释：用初学者能懂的语言 + 生活比喻修复步骤：有序列表，每步含代码示例和验证方法知识点归因：标记严重程度（HIGH / MEDIUM / LOW）复习卡片预览：自动生成的问答卡片复习卡片库卡片列表：分页展示所有复习卡片3D 翻转卡片（ReviewFlipCard）：正面问题 / 背面答案标记掌握：更新 masteryLevel，影响下次复习时间间隔重复算法：masteryLevel 0→1天 / 1→3天 / 2→7天 / 3→14天薄弱知识画像雷达图：6 维知识维度（Java 核心 / Spring / SQL / Python / 异常处理 / 设计模式）薄弱知识点排行：按 errorCount 降序，展示 Top 107 天趋势图：每日诊断数 vs 复习数折线图周复盘本周诊断总数 / 修复数 / 修复率Top 5 错误类型分布及趋势最薄弱知识点及学习建议AI 学习建议摘要5.3 API 接口模块方法路径说明用户POST/api/auth/register用户注册用户POST/api/auth/login用户登录诊断POST/api/diagnosis/analyze提交报错诊断诊断GET/api/diagnosis/list获取诊断历史列表诊断GET/api/diagnosis/{id}获取诊断详情卡片GET/api/card/list获取复习卡片列表卡片PUT/api/card/{id}/mastery更新卡片掌握程度卡片GET/api/card/due获取待复习卡片画像GET/api/profile/radar获取知识维度雷达图数据画像GET/api/profile/weak-ranking获取薄弱知识点排行画像GET/api/profile/trend获取修复趋势数据周报GET/api/weekly/current获取本周复盘健康检查GET/api/health服务健康检查 六、核心技术难点与解决思路6.1 ErrorParser 多语言报错解析难点：不同编程语言的报错格式差异巨大——Java 用堆栈跟踪、Python 用 Traceback、SQL 用错误码、Rust 用 error[E0425] 格式。需要设计一个统一的解析框架，同时保持每种语言的解析精度。解决思路：先检测后分发：detectLanguage() 基于关键词自动识别语言，用户也可手动指定每种异常独立解析：NullPointerException 和 TypeError 有完全不同的修复步骤和知识点归因正则提取关键信息：如 at com.example.Service.process(Service.java:42) 提取出 Service.java:42兜底机制：每种语言都有 parseGeneric*Error 方法，确保未知异常也能给出基本诊断大小写兼容：Port 8080 和 port 8080 都能匹配6.2 ErrorHighlight 片段级精准高亮难点：后端返回的 startOffset/endOffset 偏移量可能与前端实际渲染位置不一致（尤其是换行符、空格处理差异），导致高亮位置偏移。解决思路：双模式高亮：value 模式（关键词匹配）和 offset 模式（偏移量匹配）互为补充自动模式提取：从报错文本中提取异常类型、文件行号、端口号、模块名、SQL 表名并自动高亮片段级处理：将报错文本按行拆分，逐片段匹配高亮，避免跨行偏移问题6.3 前后端字段不一致难点：后端 Java 命名习惯（topWeakPoints、frontContent）与前端期望（topErrors、front）不一致，直接导致前端 JS 报错或数据丢失。解决思路：后端 VO 层映射：WeeklyReportVO.convertToVO 中显式映射字段名前端 normalize 函数：对后端返回数据做兼容处理，确保关键字段存在且格式正确API 拦截器兜底：请求失败时回退到 mock 数据，保证页面可渲染6.4 Spring Boot 4.x 兼容性问题难点：Spring Boot 4.x 基于 Spring Framework 7，部分自动配置行为发生变化，如 ObjectMapper 不再自动注册为 Bean，导致 JwtAuthFilter 中 JSON 序列化失败。解决思路：手动实例化：在 JwtAuthConfig 中 new ObjectMapper() 替代自动注入统一异常处理：GlobalExceptionHandler 覆盖 MethodArgumentNotValidException 和 HttpMessageNotReadableException401 响应修复：JwtAuthFilter 返回 401 时 data 字段使用 EMPTY_MAP 而非字符串 "null"6.5 知识点归因与掌握度更新难点：诊断时需要自动将报错映射到知识点体系，并更新掌握度。涉及多表关联操作（知识点查找/创建、关联记录创建、掌握度更新），需要保证数据一致性。解决思路：遍历诊断结果中的 knowledgePoints，通过 knowledgePointMapper.selectByName 查找已有知识点，不存在则新建创建 DiagnosisKnowledgeRef 关联记录查找或创建 KnowledgeMastery 记录：首次出现：初始 mastery_score = 40，error_count = 1再次出现：error_count + 1，mastery_score - 5（最低为 0）复习卡片标记掌握时：fix_count + 1，mastery_score + 10（最高为 100）6.6 JWT 用户数据隔离难点：多用户场景下，每个用户只能看到自己的诊断记录、复习卡片和知识画像，需要确保数据隔离。解决思路：JwtAuthFilter 拦截所有非白名单请求，从 token 中提取 userId 存入 request attribute所有 Controller 统一 requireUserId() 方法获取 userId 并做空值检查Service 层所有查询都带 userId 条件，更新操作校验数据归属DiagnosisRequestDTO 移除 userId 字段，由 Controller 从 token 注入，防止伪造

CampusSpace - 校园场地智能预约管理系统应用构建案例一、概述1.1 案例介绍CampusSpace是一个基于Django框架开发的校园场地智能预约管理系统，旨在解决高校场地预约管理中的痛点问题。系统集成了智能推荐算法、冲突自动检测、批量审批等核心功能，支持教室、实验室、会议室等多种场地类型的预约管理，为校园场地资源的高效利用提供了一站式解决方案。本案例将指导开发者从零开始构建一个功能完整的校园场地预约系统，涵盖用户管理、场地管理、预约审批、智能推荐、数据统计等核心模块，并集成华为云OBS对象存储、Redis缓存等技术，提升系统性能和用户体验。1.2 适用对象高校学生（学习Web开发、系统设计）个人开发者（构建校园应用）企业开发者（了解Django框架、华为云服务集成）1.3 案例时间本案例总时长预计90分钟，包括环境准备（15分钟）、项目构建（50分钟）、测试验证（25分钟）。1.4 案例流程说明：本地安装华为云码道（CodeArts）代码智能体；通过码道开发校园场地智能预约管理系统，并在浏览器中体验。1.5 资源总览本案例预计花费0元（使用免费资源和开发环境）。体验完成后请及时释放资源，避免产生多余的费用。资源名称规格单价（元）华为云对象存储服务OBS标准存储 5GB免费（按需付费）Redis缓存服务本地Redis或云服务免费华为云码道（CodeArts）代码智能体体验版（专业版）免费（按需付费）二、环境和资源准备2.1 下载安装CodeArts代码智能体参考《AI IDE华为云码道（CodeArts）代码智能体安装部署》，下载安装IDE:2.2 开通华为云码道体验版访问专属开通链接，免费开通华为云码道（CodeArts）代码智能体体验版：2.2 登录CodeArts代码智能体安装完成之后，点击打开文件夹或新建项目，用于存放项目文件：登录CodeArts代码智能体：注意：如果已经登录华为账号，直接跳转至登录授权页面，否则，直接拉起华为账号登录界面。自动拉起华为账号登录界面，输入账号和密码：跳转至登录授权页面，点击确认授权：CodeArts代码智能体登录成功：登录成功之后，返回CodeArts代码智能体，即可体验使用。三、通过码道分阶段搭建校园场地智能预约管理系统3.1 需求规格设计在码道对话框输入以下提示词，让码道进行需求规格说明书的创建：你是一名资深产品经理、Django架构师和测试工程师。 我要开发 CampusSpace 智约——校园教室与会议室智能预约及冲突优化平台。 项目目标： 学生或教师输入使用时间、人数和设备需求，系统自动推荐合适场地； 支持固定课表、维修停用、临时预约、冲突检测、审批、取消和利用率统计。 用户角色： 1. 普通用户：查询场地、获取推荐、提交预约、查看和取消预约。 2. 管理员：管理场地、固定课表、维修时间、审批预约和查看统计。 技术栈： Python、Django、Bootstrap、FullCalendar、Chart.js。 本地使用SQLite，部署时可切换MySQL或PostgreSQL。 现在先不要写代码，请依次输出： 1. 需求规格说明书 2. 功能优先级P0/P1/P2 3. 用户故事与验收标准 4. 页面清单 5. 数据表设计 6. 预约状态机 7. 冲突检测规则 8. 推荐算法 9. 项目目录结构 10. 分阶段开发任务清单 请将结果分别保存到docs目录中的Markdown文件。 存在模糊或矛盾的业务规则时先列出问题，不要自行假设。此时，码道会根据步骤创建多个开发文档。这时，我们查看00-业务规则待确认问题.md，并确认业务规则，将修改后的文件发送给码道，码道会根据业务规则完善关键文档。3.2 生成项目结构和配置文件在码道对话框输入以下提示词，让码道生成项目结构和配置文件：请根据docs目录中的需求和设计文件，创建Django项目骨架。 本阶段只完成： 1. 项目初始化 2. 用户登录与退出 3. 管理员和普通用户权限 4. Building与Room数据模型 5. Django管理后台 6. 基础导航和首页 7. 初始化演示数据命令 8. README启动说明3.3 安装Python开发环境步骤1：安装Python 3.9访问Python官网下载并安装Python 3.9版本，确保pip包管理工具可用。步骤2：创建虚拟环境在项目目录下创建虚拟环境，隔离项目依赖：# Windows python -m venv CampusSpace CampusSpace\Scripts\activate # Linux/Mac python3 -m venv CampusSpace source CampusSpace/bin/activate步骤3：安装Django框架安装Django 3.2 LTS版本及项目依赖：pip install Django==3.2.* pip install django-crispy-forms==1.14.0 pip install crispy-bootstrap5==0.7 pip install Pillow==9.5.* pip install python-dateutil==2.8.*3.4 完善核心功能模块在码道对话框输入以下提示词，继续完善核心功能模块。接下来请根据docs目录中的需求和设计文件，实现： 1. 教学楼管理 2. 教室管理 3. 设备条件 4. 固定占用 5. 维修停用3.5 结合Skill实现预约系统3.5.1 实现预约功能在码道对话框输入以下提示词，继续完善核心功能模块。由于预约功能涉及规则较多，需要进行确认后再实现。请调用booking-domain Skill，实现预约核心功能。 要求： 1. 用户选择场地、日期、开始时间和结束时间。 2. 校验开始时间早于结束时间。 3. 校验人数不超过场地容量。 4. 校验设备要求。 5. 校验固定课表冲突。 6. 校验维修时间冲突。 7. 校验已批准预约冲突。 8. 校验同一用户的时间冲突。 9. 冲突时不写入预约数据。 10. 返回明确的冲突原因。 11. 无冲突时创建待审批预约。 12. 为所有规则编写单元测试。 请先说明实现方案和涉及文件，等待我确认后再修改代码。确认所有问题后，码道会根据完整的冲突检测规则实现预约功能。3.5.2 实现场地推荐功能在码道对话框输入以下提示词，加入场地推荐功能。在现有预约系统中实现可解释的场地推荐。 推荐流程： 1. 根据时间冲突、容量、设备和场地状态进行硬性筛选。 2. 对剩余场地计算100分推荐分。 3. 容量匹配35分、设备匹配25分、建筑偏好15分、 空闲连续性15分、节能匹配10分。 4. 返回排名前三的场地。 5. 每个结果必须提供推荐理由和扣分原因。 6. 无合适场地时，推荐最近的可用时间或替代场地。 7. 推荐逻辑与视图层分离。 8. 为排序、并列和无结果场景编写测试。3.5.3 实现审批流程和日历视图功能在码道对话框输入以下提示词，实现审批流程和日历视图功能。实现： - 管理员审批列表 - 同意和拒绝 - 拒绝原因 - 用户个人预约 - 取消预约 - 周日历和月日历 - 不同状态颜色显示3.5.4 实现统计分析功能在码道对话框输入以下提示词，采用服务层设计模式，实现统计分析功能。先生成 SQL/ORM 设计，再生成图表接口，避免统计逻辑散落在页面里。 并验证： - 没有数据时页面不报错 - 只有一条数据时图表正常 - 已取消预约不计入有效利用率 - 固定课表和临时预约是否分别统计3.6 添加华为云OBS和Redis集成3.6.1 配置华为云OBS服务步骤1：开通华为云OBS服务登录华为云控制台，开通对象存储服务OBS。步骤2：创建OBS桶在OBS控制台创建存储桶，用于存储系统上传的文件：桶名称：campusspace-files区域：华北-北京四存储类别：标准存储桶访问权限：公共读步骤3：获取访问密钥在"我的凭证"页面获取访问密钥（AK/SK），用于程序访问OBS服务：步骤4：安装OBS SDK安装华为云OBS Python SDK：pip install esdk-obs-python步骤5：配置环境变量设置OBS访问密钥环境变量：# Windows (PowerShell) $env:HUAWEI_ACCESS_KEY="你的AK" $env:HUAWEI_SECRET_KEY="你的SK" # Linux/Mac export HUAWEI_ACCESS_KEY="你的AK" export HUAWEI_SECRET_KEY="你的SK" 3.6.2 安装Redis缓存服务步骤1：安装RedisWindows用户下载Redis Windows版本，Linux/Mac用户使用包管理器安装：# Ubuntu/Debian sudo apt-get install redis-server # CentOS/RHEL sudo yum install redis # Mac brew install redis步骤2：启动Redis服务# Windows redis-server.exe # Linux/Mac redis-server步骤3：安装Django Redispip install django-redis==5.4.0 pip install redis==5.0.13.6.3 配置项目设置编辑config/settings.py，配置项目设置：# 华为云OBS配置 HUAWEI_OBS_CONFIG = { 'access_key': os.environ.get('HUAWEI_ACCESS_KEY'), 'secret_key': os.environ.get('HUAWEI_SECRET_KEY'), 'server': 'obs.cn-north-4.myhuaweicloud.com', 'bucket_name': 'campusspace-files' } # Redis缓存配置（开发环境使用本地内存） if DEBUG: CACHES = { 'default': { 'BACKEND': 'django.core.cache.backends.locmem.LocMemCache', 'LOCATION': 'unique-snowflake', } } else: CACHES = { 'default': { 'BACKEND': 'django_redis.cache.RedisCache', 'LOCATION': 'redis://127.0.0.1:6379/1', 'OPTIONS': { 'CLIENT_CLASS': 'django_redis.client.DefaultClient', }, 'KEY_PREFIX': 'campusspace', 'TIMEOUT': 300, } } 3.6.4 实现华为云 OBS 与 Redis 缓存功能在码道对话框输入以下提示词，实现技术提升。添加以下重要功能和技术提升： 使用华为云 OBS 添加 Redis 缓存 创建 API 文档四、启动项目并反馈可能出现的问题在编码任务完成后，根据启动说明启动项目，检查是否正常运行。注意：在启动项目中或项目运行中可能会出现一些错误，遇到问题的时候我们通过自然语言描述或者截图的方式把错误直接反馈给码道，让码道帮我们解决就可以了。也可以按照个人习惯增加其他的功能，比如批量审批、数据导出、站内消息等，让系统更加完善。注意：由于本应用是由AI创建，每次创建的结果可能不一致，如果想体验上图中的案例，可在本项目源码处下载并体验。五、反馈改进建议如您在案例实操过程中遇到问题或有改进建议，可以到开发者论坛评论区反馈，我们会及时响应处理，谢谢！六、附录项目地址 https://github.com/NanfengCC66/CampusSpace演示视频 https://github.com/NanfengCC66/CampusSpace/blob/main/演示视频.mp4