一、案例基本信息案例名称：智能论文投稿与审稿助手应用类型：面向高校学报、小型期刊编辑部的论文投稿预审、审稿人推荐与审稿辅助 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

套餐内额度太少了，一个开发者深度使用一天可能就是大几千万的tokens，能不能增加一下套餐内的配额

代码及视频demo所在仓库地址：https://gitcode.com/W20402001/madao基于华为云码道（CodeArts）的应用构建案例——校园场地智能预约系统一、概述1.1 案例介绍本案例采用华为云码道（CodeArts）代码智能体作为核心开发工具，从零构建一个校园场地智能预约管理系统。系统面向普通用户（USER）、管理员（ADMIN）、审批员（APPROVER）三类角色，实现了场地信息管理、智能查询推荐、预约申请与审批、时间冲突检测、签到核验、运营数据统计等核心功能。开发过程采用"V1快速原型→V2功能完善→V3界面升级"的三轮迭代模式，全程使用码道代码智能体辅助开发，充分展示了码道在项目骨架生成、代码续写、智能问答、系统性界面重构等场景下的实践应用。1.2 案例流程环境准备 → V1快速原型 → V2功能完善 → V3界面升级说明：环境准备：安装华为云码道（CodeArts）代码智能体、Node.js、JDK 17；V1快速原型：使用码道生成项目骨架，完成核心数据模型+基础CRUD+简单场地查询；V2功能完善：实现基于内存Token的三角色认证、智能推荐算法、时间冲突检测、预约状态机、审批流程、运营统计；V3界面升级：使用码道系统性重构前端界面，建立设计系统，统一布局与组件，优化交互体验。1.3 资源总览资源名称规格单价（元）华为云码道（CodeArts）代码智能体专业版代金券支付Node.jsv24.18.0（本案例实测）免费JDK17免费Apache Maven3.9.16（本案例实测）免费二、环境和资源准备2.1 安装华为云码道（CodeArts）代码智能体访问华为云码道下载页面，下载并安装码道代码智能体。安装完成后，使用华为云账号登录。2.2 安装Node.js开发环境访问Node.js官网下载并安装兼容版本。本案例实际使用Node.js v24.18.0、npm 11.16.0。安装完成后，在终端验证：node --version npm --version 2.3 安装JDK 17访问Oracle或Adoptium官网下载并安装JDK 17。安装完成后验证：java -version javac -version 本案例实际使用Eclipse Adoptium Temurin 17.0.19。2.4 安装Apache Maven后端使用Maven构建。本案例实际使用Apache Maven 3.9.16。安装后验证：mvn -version 2.5 完成码道CodeArts实战速成考试访问码道CodeArts实战速成考试，完成在线学习并通过考试，获取通过证书。2.6 本案例实际验证环境项目实际环境操作系统Windows 11 x64JDKEclipse Adoptium Temurin 17.0.19MavenApache Maven 3.9.16Node.jsv24.18.0npm11.16.0后端端口8080前端开发端口5173前端API代理/api → http://localhost:8080说明：开发工具需要在系统环境变量更新后重新启动，才能继承最新的JAVA_HOME和PATH。本案例验证时JDK安装于D:\tools\jdk17，Maven安装于D:\tools\maven\apache-maven-3.9.16，Node.js安装于D:\tools\nodejs。三、系统架构设计3.1 技术选型层级技术栈说明前端框架Vue 3 + TypeScript + Vite响应式组合式API，类型安全UI组件库Element Plus企业级Vue3组件库状态管理Pinia轻量级状态管理路由Vue Router 4支持路由守卫与角色权限HTTP客户端Axios请求拦截、Token注入后端框架Spring Boot 3.2.5Java 17，Maven构建认证方案内存Token + 拦截器Bearer Token仅保存在进程内存中，不是JWT数据存储内存RepositoryConcurrentHashMap模拟持久化定时任务Spring @Scheduled预约状态自动流转3.2 系统架构图3.3 数据模型设计系统核心数据模型如下：UserAccount (用户) ├── id, username, password, realName ├── role: USER | ADMIN | APPROVER └── status: ACTIVE | DISABLED Venue (场地) ├── id, code, name, building ├── type: CLASSROOM | MEETING_ROOM | SPORTS_FIELD ├── capacity, equipment[], openTime, closeTime └── status: ACTIVE | INACTIVE Booking (预约) ├── id, bookingNo, applicantId, venueId ├── purpose, attendeeCount, requiredEquipment[] ├── startAt, endAt ├── status: PENDING_APPROVAL → APPROVED → CHECKED_IN → COMPLETED │ ↘ REJECTED ↘ CANCELLED ↘ EXPIRED └── checkInCode, createdAt, updatedAt FixedSchedule (固定排课) ├── id, venueId, validFrom, validTo ├── dayOfWeek, startTime, endTime └── description ApprovalRecord (审批记录) ├── id, bookingId, approverId ├── action: APPROVE | REJECT └── comment, operatedAt3.4 预约状态流转3.5 项目结构campus-venue-booking/ ├── server/ # 后端（Spring Boot） │ ├── pom.xml # Maven依赖配置 │ └── src/main/java/com/example/venuebooking/ │ ├── VenueBookingApplication.java # 应用入口（@EnableScheduling） │ ├── config/ │ │ ├── WebConfig.java # 跨域+拦截器注册 │ │ └── MockDataInitializer.java # 初始化示例数据 │ ├── auth/ │ │ ├── AuthService.java # 登录/注册/Token管理 │ │ ├── AuthController.java # 认证接口 │ │ ├── AuthInterceptor.java # Token校验+当前用户注入 │ │ ├── SkipAuth.java # 跳过鉴权注解 │ │ └── CurrentUser.java # 当前用户注解 │ ├── venue/ │ │ ├── VenueController.java # 场地查询接口 │ │ ├── VenueService.java # 场地查询+日程 │ │ ├── VenueAdminController.java# 管理端场地接口 │ │ └── VenueAdminService.java # 场地CRUD+状态管理 │ ├── booking/ │ │ ├── BookingController.java # 预约接口 │ │ ├── BookingService.java # 预约核心逻辑 │ │ └── BookingStatusScheduler.java # 定时状态流转 │ ├── approval/ │ │ ├── ApprovalController.java # 审批接口 │ │ └── ApprovalService.java # 审批逻辑+签到码 │ ├── schedule/ │ │ ├── FixedScheduleController.java # 固定排课接口 │ │ └── FixedScheduleService.java # 固定排课管理 │ ├── statistics/ │ │ ├── StatisticsController.java # 统计接口 │ │ └── StatisticsService.java # 统计计算 │ ├── algorithm/ │ │ ├── VenueRecommendationService.java # 智能推荐算法 │ │ ├── VenueAvailabilityService.java # 可用性检测 │ │ ├── TimeConflictChecker.java # 时间冲突检测 │ │ ├── RecommendationScore.java # 推荐评分模型 │ │ └── ConflictResult.java # 冲突结果模型 │ ├── domain/ # 领域模型 │ │ ├── Venue.java, Booking.java, UserAccount.java │ │ ├── FixedSchedule.java, ApprovalRecord.java │ │ └── enums/ (BookingStatus, VenueType, UserRole等) │ ├── repository/ # 数据仓储接口 │ │ ├── VenueRepository.java, BookingRepository.java │ │ ├── UserRepository.java, FixedScheduleRepository.java │ │ ├── ApprovalRecordRepository.java │ │ └── memory/ # 内存实现 │ └── common/ # 通用组件 │ ├── ApiResponse.java, BusinessException.java │ ├── ErrorCode.java, GlobalExceptionHandler.java │ └── CustomErrorController.java │ └── web/ # 前端（Vue3 + Vite） ├── package.json ├── vite.config.ts # Vite配置+API代理 └── src/ ├── main.ts # Vue3入口 ├── App.vue # 根组件（路由过渡） ├── styles/ │ ├── variables.css # CSS设计变量系统 │ └── global.css # 全局通用样式 ├── types/index.ts # TypeScript类型定义 ├── utils/ │ ├── request.ts # Axios封装+Bearer Token注入 │ └── format.ts # 公共格式化函数 ├── composables/useClock.ts # 时钟Hook ├── api/ │ ├── auth.ts # 认证接口 │ ├── venue.ts # 场地接口 │ ├── booking.ts # 预约接口 │ ├── approval.ts # 审批接口 │ └── admin.ts # 管理端接口 ├── stores/user.ts # Pinia用户状态 ├── router/index.ts # 路由+权限守卫 ├── components/ # 公共组件 │ ├── AppLayout.vue # 统一布局（侧边栏+顶栏+内容） │ ├── AppPageHeader.vue # 页面标题 │ ├── AppStatCard.vue # 统计卡片 │ ├── AppSectionCard.vue # 内容卡片 │ ├── AppFilterBar.vue # 筛选栏 │ ├── BookingStatusTag.vue # 预约状态标签 │ ├── VenueTypeTag.vue # 场地类型标签 │ ├── VenueCard.vue # 场地卡片 │ ├── VenueTimeBar.vue # 时间条（可拖拽选择） │ ├── EmptyState.vue # 空状态 │ └── UserAvatarMenu.vue # 用户头像菜单 ├── layouts/ # 角色布局 │ ├── UserLayout.vue │ ├── AdminLayout.vue │ └── ApproverLayout.vue └── views/ # 页面视图 ├── Login.vue # 登录/注册 ├── 403.vue, 404.vue # 错误页 ├── user/ # 用户端6个页面 ├── admin/ # 管理端5个页面 └── approver/ # 审批端2个页面四、使用华为云码道（CodeArts）代码智能体辅助完成代码开发及调试4.1 V1快速原型：搭建核心链路4.1.1 使用码道创建项目骨架在码道IDE中，打开终端，创建项目目录并初始化后端：mkdir campus-venue-booking && cd campus-venue-booking mkdir server web cd server使用码道智能问答功能，输入项目要求文件和提示词：“我们要完成一个网页端的校园场地只能预约系统，这是初步的设计文件。首先请根据文件规划代码开发顺序，我们将逐步完成整个项目的代码开发工作。”码道会自动生成初步实现代码，我们在此基础上进行修改和完善。4.1.2 V1交付标准V1阶段实现：场地增删改查、用户登录注册、基础预约创建、简单场地列表查询。4.1.3 V1验证# 后端 cd server && mvn spring-boot:run # 前端 cd web && npm install && npm run dev4.2 V2功能完善：满足全部硬性要求4.2.1 内存Token三角色认证与权限隔离使用码道代码续写功能，快速实现认证中间件。系统定义三类角色：角色说明功能范围USER普通用户预约申请、我的预约、查询推荐ADMIN管理员场地管理、固定排课、用户管理、统计看板APPROVER审批员待审批列表、审批操作、审批历史后端通过AuthInterceptor拦截请求、校验Token并注入当前用户；具体角色权限由各Controller校验；前端通过路由守卫实现页面级权限控制：4.2.2 智能推荐算法使用码道辅助设计多维度加权推荐算法，核心评分逻辑如下：// 容量得分（满分50分）：人数越接近容量得分越高 capacityScore = 50.0 * attendeeCount / venue.getCapacity(); // 楼宇偏好得分（满分20分）：匹配偏好楼宇得20分 buildingScore = preferredBuilding.equals(venue.getBuilding()) ? 20.0 : 0.0; // 设备匹配得分（满分15分）：按可选设备匹配比例 equipmentScore = 15.0 * matchedCount / totalOptionalCount; // 负载均衡得分（满分15分）：利用率越低得分越高 balanceScore = 15.0 * (1 - utilization); totalScore = capacityScore + buildingScore + equipmentScore + balanceScore; 排序规则：按总分降序 → 容量升序（小场地优先） → 场地编码升序。4.2.3 时间冲突检测实现双层冲突检测：固定排课冲突 + 预约冲突：@Component public class TimeConflictChecker { public boolean overlaps(LocalDateTime startA, LocalDateTime endA, LocalDateTime startB, LocalDateTime endB) { return startA.isBefore(endB) && startB.isBefore(endA); } } 场地可用性判断需满足7个条件：状态ACTIVE、类型匹配、容量足够、设备齐全、在开放时间内、无固定排课冲突、无预约冲突。4.2.4 预约状态机与定时调度预约7种状态通过BookingStatusScheduler每60秒自动流转：@Scheduled(fixedRate = 60000) public void updateStatuses() { // APPROVED且开始时间已过15分钟 → EXPIRED（爽约） // CHECKED_IN且已过结束时间 → COMPLETED（已完成） } 4.2.5 V2验证V2交付标准：三角色内存Token认证与权限隔离、多维度智能推荐算法、时间冲突检测、预约7状态流转、审批流程+签到码、运营统计接口。4.3 V3界面升级：系统性前端重构V3阶段是本案例的核心亮点，使用码道代码智能体完成了一次系统性的前端界面升级。这一阶段充分展示了码道在大型重构任务中的能力——理解完整代码库、制定分阶段方案、逐模块实施并保证类型安全。4.3.1 使用码道进行全量代码分析向码道输入以下提示词：“请阅读 campus-venue-booking/web 下的全部前端代码，在保持现有业务功能、接口协议、路由结构和权限体系不变的前提下，对’校园场地智能预约系统’进行系统性的前端界面升级。”码道自动完成了以下分析工作：完整读取所有源文件：30+个Vue组件、5个API模块、类型定义、路由配置、Store、工具函数识别现有问题：统计值硬编码为0、大量行内样式、类型缺失、API封装不完整、状态映射重复等多项问题输出实施方案：设计系统定义、公共组件规划、修改文件清单、6阶段实施顺序4.3.2 建立设计系统使用码道一次性生成CSS设计变量体系，定义了完整的视觉规范：:root { --color-primary: #2563EB; /* 主色：校园科技蓝 */ --color-nav-bg: #172B4D; /* 深色导航 */ --color-accent: #14B8A6; /* 智能推荐强调色 */ --color-page-bg: #F5F7FA; /* 页面背景 */ --radius-md: 10px; /* 卡片圆角 */ --shadow-sm: 0 1px 2px rgba(0,0,0,0.05); /* 轻盈阴影 */ --sidebar-width: 240px; /* 侧边栏宽度 */ --transition-normal: 250ms; /* 过渡时长 */ } 4.3.3 提取11个公共组件通过码道代码续写功能，将各页面重复的样式和逻辑提取为11个可复用组件：组件用途替代的重复代码AppLayout统一三角色布局3套Layout的重复侧边栏+顶栏代码AppPageHeader页面标题+操作区每个页面重复的标题区AppStatCard统计数字卡片Dashboard和Home的统计卡片AppSectionCard统一内容卡片页面内容区的卡片标题与间距BookingStatusTag预约状态标签5个页面重复的statusTagType函数VenueTypeTag场地类型标签3个页面重复的类型映射AppFilterBar搜索筛选区域各列表页重复的筛选区样式VenueCard场地卡片场地列表的表格行样式VenueTimeBar场地日程与时段选择可视化占用时段并拖拽选择预约时间EmptyState无数据状态分散在各页面的空数据判断UserAvatarMenu用户头像菜单3套Layout重复的退出按钮同时将日期格式化、状态映射等公共逻辑提取到utils/format.ts，消除了6处重复的statusTagType、formatTime、venueTypeMap定义。4.3.4 统一三套Layout为AppLayout原来三套Layout存在大量重复代码，重构为一个AppLayout组件并通过props区分角色菜单；当前三个角色Layout文件分别约12～15行：<!-- UserLayout.vue - 当前约15行 --> <template> <AppLayout :menu-items="menuItems" role-key="USER" /> </template> <script setup lang="ts"> import AppLayout from '@/components/AppLayout.vue' const menuItems = [ { path: '/user/home', label: '首页', icon: 'HomeFilled' }, { path: '/user/venues', label: '场地列表', icon: 'OfficeBuilding' }, // ... ] </script> AppLayout实现了：侧边栏折叠/展开、窄屏抽屉式导航、面包屑导航、用户头像下拉菜单（含退出确认）。4.3.5 登录页重新设计使用码道生成左右分栏品牌登录页：左侧：深蓝渐变背景，展示系统名称、副标题和4个功能特性（智能查询推荐、冲突自动检测、便捷审批流程、数据统计分析）右侧：简洁登录/注册表单，演示账号卡片式快捷入口响应式：768px以下隐藏左侧装饰区4.3.6 用户首页接入真实数据原来首页三个统计卡片值硬编码为0，重构后从getMyBookings接口获取真实数据计算：const todayCount = computed(() => bookings.value.filter(b => b.startAt.startsWith(todayStr)).length) const pendingCount = computed(() => bookings.value.filter(b => b.status === 'PENDING_APPROVAL').length) const approvedCount = computed(() => bookings.value.filter(b => b.status === 'APPROVED').length) 新增欢迎区域（含问候语、快捷操作入口）和近期预约列表。4.3.7 查询推荐页评分可视化推荐结果从简单表格升级为卡片式布局，每个推荐卡片包含：排名标识（前3名使用强调色）分项评分进度条（容量/楼宇/设备/均衡四维度）推荐理由标签"立即预约"操作按钮4.3.8 管理端统计看板使用纯CSS柱状图替代固定比例模拟数据，基于接口返回数据动态计算：<div class="bar-fill" :style="{ width: maxDaily > 0 ? (item.count / maxDaily * 100) + '%' : '0%' }"></div> 新增"运营概览"和"需要关注"区域，展示开放场地占比、审批率和待处理事项。当前页面中开放场地占比的标签仍写作“场地利用率”，语义边界见“7.4 当前实现边界”。4.3.10 V3验证npm run build：执行vue-tsc -b && vite build，0错误通过2026-07-23复核构建：转换1730个模块，约0.73秒完成构建存在单个产物超过500 kB的性能提示，但不影响构建成功三角色路由、核心页面及主要接口均已实现当前已知接口和交互边界见“7.4 当前实现边界”4.4 码道核心使用场景总结使用场景具体操作效果项目骨架生成输入技术栈和模型描述，自动生成项目结构减少重复的初始化工作代码续写编写组件开头，码道自动补全模板和逻辑提高常规组件编码效率智能问答询问算法设计、状态机实现方案快速获得最佳实践全量代码分析一次读取30+文件，识别多项问题快速形成结构化改造清单系统性重构6阶段分步实施，保持核心业务与路由结构不变当前版本可通过前端构建类型修复识别未使用导入和缺失类型当前npm run build通过五、解决方案5.1 前端设计系统方案建立以CSS变量为核心的设计系统，覆盖颜色、圆角、阴影、间距、字体、动画6个维度，共定义40+个设计Token。所有组件和页面统一引用变量，实现全局一致的视觉风格。配色方案：用途色值说明主色#2563EB校园科技蓝，按钮/链接/激活态深色导航#172B4D侧边栏背景智能推荐#14B8A6推荐结果强调色页面背景#F5F7FA内容区背景卡片背景#FFFFFF卡片/弹窗背景主文字#1F2937标题/正文次要文字#64748B说明/辅助边框#E2E8F0分割线/卡片边框5.2 公共组件复用方案通过提取11个公共组件，并将状态、角色、设备及日期格式化逻辑集中到utils/format.ts，减少了各页面的重复实现和行内样式。组件设计遵循单一职责原则，并通过Props定义明确的接口类型。5.3 统一布局方案三套Layout合并为AppLayout组件，通过menuItems和roleKey两个props区分角色。布局支持：侧边栏折叠/展开（桌面端）抽屉式导航（移动端 < 768px）面包屑导航（自动根据路由生成）用户头像下拉菜单（含退出确认）5.4 智能推荐可视化方案推荐结果使用卡片式布局，每个推荐项包含分项评分进度条，直观展示容量、楼宇、设备、均衡四维匹配情况。推荐场地与普通可用场地区分展示，推荐区域使用强调色标识。5.5 管理端数据看板方案统计看板使用纯CSS实现轻量柱状图，不引入额外图表库。基于接口返回数据动态计算最大值和百分比，通过CSS过渡动画实现数据加载效果。新增"运营概览"和"需要关注"区域，帮助管理员快速掌握系统运营状态。其中当前“场地利用率”数值实际为开放场地数除以场地总数。六、核心技术难点与解决思路6.1 难点一：多维度场地推荐算法设计问题：如何从多个维度（容量、楼宇、设备、利用率）综合评估场地适配度，给出合理的推荐排序？解决思路：采用加权评分法，为每个维度分配权重：容量得分（50分）：参会人数与场地容量的比值，鼓励选择刚好够用的场地，避免浪费楼宇偏好（20分）：用户指定偏好楼宇时精确匹配设备匹配（15分）：按可选设备匹配比例计算，支持部分匹配负载均衡（15分）：利用率越低得分越高，鼓励分散使用场地排序时先按总分降序，同分时优先推荐小容量场地（更匹配需求），再按场地编码排序保证稳定性。6.2 难点二：双层时间冲突检测问题：场地预约需要同时检测固定排课冲突和已有预约冲突，且需考虑预约状态（仅PENDING_APPROVAL、APPROVED、CHECKED_IN状态占用场地）。解决思路：实现VenueAvailabilityService统一封装可用性判断，内部分两步检测：固定排课冲突：根据场地ID和预约时间，查询该场地在对应星期是否有固定排课与预约时段重叠预约冲突：查询该场地所有占用状态（PENDING_APPROVAL、APPROVED、CHECKED_IN）的预约，逐一判断时间重叠底层使用TimeConflictChecker的区间重叠算法：startA < endB && startB < endA。6.3 难点三：预约并发控制问题：多个用户可能同时预约同一场地的同一时段，如何防止超卖？解决思路：采用双重防护：请求幂等：前端提交时携带requestId（时间戳），后端使用ConcurrentHashMap.newKeySet()记录已处理的requestId，防止重复提交进程内互斥锁：BookingService使用synchronized(bookingLock)对创建预约操作加锁，确保当前应用进程内同一时刻只有一个预约创建请求进入临界区。这不是数据库乐观锁，也不适用于多实例部署private final Object bookingLock = new Object(); private final Set<String> processedRequestIds = ConcurrentHashMap.newKeySet(); public Booking createBooking(...) { if (requestId != null && !processedRequestIds.add(requestId)) { throw new BusinessException(ErrorCode.DUPLICATE_REQUEST); } synchronized (bookingLock) { // 在临界区内检查固定占用冲突和预约冲突 // 创建预约 } } 七、系统测试7.1 演示账号角色用户名密码功能范围普通用户user01123456首页、场地列表、查询推荐、预约申请、我的预约管理员admin01123456统计看板、场地管理、固定排课、全部预约、用户管理审批员approver01123456待审批、审批历史7.2 功能测试用例以下用例为人工验收清单，不等同于项目现有的自动化测试数量。编号测试功能操作步骤预期结果T01用户登录输入user01/123456，点击登录跳转到用户首页，显示欢迎信息和今日预约统计T02场地列表点击"场地列表"显示10个场地卡片，支持按名称/类型/状态筛选T03查看日程在场地卡片点击"查看日程"展开VenueTimeBar时间条，可拖拽选择时段T04智能查询点击"查询推荐"，设置条件后查询显示推荐卡片，含分项评分进度条和推荐理由T05预约申请选择场地，填写信息，提交提交成功，跳转到我的预约列表T06取消预约在我的预约中点击取消确认后预约状态变为已取消T07审批员登录输入approver01/123456跳转到待审批页面，显示待审批列表T08批准预约点击批准，填写审批意见预约状态变为已批准，生成签到码T09驳回预约点击驳回，输入原因预约状态变为已驳回T10管理员登录输入admin01/123456跳转到统计看板，显示6个统计卡片和柱状图T11场地管理新增/编辑/停用场地操作成功，列表刷新T12固定排课新增固定占用，选择场地下拉保存成功，星期显示中文T13用户管理停用/启用用户操作成功，不能操作自己的账号T14角色权限隔离用户账号尝试访问/admin路径跳转到/403，无权限页面不可访问T15响应式适配缩小浏览器窗口至768px以下侧边栏变为抽屉式导航，表格可横向滚动T16用户注册在登录页切换到注册页并提交合法信息注册成功、自动登录并按所选角色跳转7.4 当前实现边界注册角色由前端选择：当前注册接口允许传入USER、ADMIN或APPROVER。这便于案例演示，但生产系统应限制公开注册只能创建普通用户，并由管理员分配高权限角色。固定占用编辑尚未接入前端：后端已提供PUT /api/admin/fixed-schedules/{id}，当前管理页面只实现查询、新增和删除。统计看板跨角色入口需调整：“需要关注”区域中的“去审批”按钮跳转到/approver/pending，但管理员角色会被前端路由守卫转到/403。数据存储为内存实现：所有场地、预约、用户、固定占用和审批记录均保存在ConcurrentHashMap中，适合案例演示，不提供跨重启持久化和多实例一致性。推荐设备偏好尚未完全暴露到界面：后端推荐模型支持optionalEquipment并据此计算设备匹配分，当前查询页只提交requiredEquipment，未提供可选设备偏好的独立输入项。八、扩展资料说明华为云码道（CodeArts）代码智能体：https://codearts.huaweicloud.comVue3官方文档：https://cn.vuejs.orgElement Plus组件库：https://element-plus.org/zh-CNSpring Boot官方文档：https://spring.io/projects/spring-bootTypeScript官方文档：https://www.typescriptlang.orgVite构建工具：https://cn.vitejs.devPinia状态管理：https://pinia.vuejs.org/zh代码及视频demo所在仓库地址：https://gitcode.com/W20402001/madao

基于华为云码道（CodeArts）代码智能体的运动场馆管理系统1、案例介绍1.1 案例介绍校园运动场馆资源分散、借用流程混乱、时间冲突频发？本案例基于 Vue3 + Express 全栈架构，借助华为云码道（CodeArts）代码智能体，从零到一构建一套运动场馆智能管理系统。系统支持课表固定占用与临时借用双模式，提供基于时间段的可用场馆智能推荐，实现场馆资源的高效调度与零冲突管理。1.2 适用对象高校学生个人开发者企业开发者1.3 案例时间本案例总时长预计60分钟。1.4 案例流程┌──────────────┐ ┌──────────────────┐ ┌──────────────────┐ ┌──────────────┐ │ 1 本地环 │───▶│ 2.CodeArts智能体 │───▶│ 3.依赖安装与 │───▶│ 4.运行调试 │ │ 境准备 │ │ 生成代码 │ │ 环境适配 │ │ 与验证 │ └──────────────┘ └──────────────────┘ └──────────────────┘ └──────────────┘说明：准备本地开发环境，安装 Node.js，创建项目目录；在 CodeArts 代码智能体中输入需求，智能体自动生成前后端完整代码；安装项目依赖，遇到原生模块编译问题时由智能体自动适配解决；启动前后端服务，验证系统核心功能。1.5 资源总览本案例预计花费0元。资源名称规格单价（元）华为云码道（CodeArts）代码智能体通用体验版免费Node.jsv20+免费2、环境和资源准备2.1 安装 Node.js本案例前端和后端均基于 Node.js 运行，需提前安装 Node.js v20 及以上版本。下载地址：https://nodejs.org/安装完成后，在终端验证：node --version npm --version 2.2 开通华为云码道（CodeArts）代码智能体登录华为云控制台，搜索"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-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:3000 2）启动前端开发服务器再开一个终端窗口，执行：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 build构建成功输出：4、核心技术难点与解决思路难点一：时间段冲突检测的准确性问题： 场馆占用涉及课表（按星期循环）和借用（按具体日期）两种不同维度的时间表示，需准确判定冲突。解决思路：课表以 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，避免脏数据附录项目代码、文档及演示视频：项目代码及演示视频

1 、概述1.1 案例介绍企业日常会议产生大量记录文本，但缺乏高效的后续跟进手段：摘要靠人工整理、任务靠口头传达、风险靠经验判断。本案例将带你从零构建一款"会议智脑"应用——上传会议记录后，自动调用华为云 MaaS 大模型（DeepSeek V4 Flash）生成摘要、提取关键决策和任务清单，并通过可视化看板、甘特图、日历等多维度视图进行任务追踪与风险预警。1.2 适用对象企业开发者个人开发者1.3 案例时间  本案例总时长预计60分钟。1.4 案例流程  1. 领取华为云 MaaS 平台大模型 Tokens，获取 API Key 和模型接入地址；  2. 配置 .env 环境变量，将 MaaS API Key 等信息写入配置；  3. 初始化数据库并启动后端服务，验证 API 文档可访问；  4. 启动前端开发服务器，登录系统并上传会议记录，体验 AI 自动生成摘要与任务提取；  5. 在任务看板、甘特图、日历等视图中查看和管理提取的任务，触发风险检测。1.5 资源总览  本案例使用的华为云服务均为按需付费，预计花费不超过50元（MaaS Tokens 代金券可覆盖）。体验完成后请及时释放资源，避免产生多余的费用。资源名称规格单价（元）    华为云 MaaSDeepSeek V4 Flash 大模型推理服务代金券可覆盖华为云码道（CodeArts）代码智能体通用体验版免费2 、环境和资源准备2.1 领取华为云MaaS平台大模型Tokens福利   方式一： 登录华为开发者空间，参考案例《华为开发者空间 - ModelArts Studio大模型通用代金券领取使用指导》中的“二、 开通MaaS平台大模型”章节内容领取代金券，获取到模型的API地址、模型名称和API Key。   方式二： 登录华为开发者空间，参考案例《华为云MaaS平台大模型Tokens领取使用指导》中的“二、 领取MaaS平台大模型Tokens”章节内容，领取MaaS平台DeepSeek V3系列大模型Tokens代金券，购买ModelArts Studio DeepSeek Tokens套餐包，开通模型服务，最后获取到模型的API地址、模型名称和API Key。     2.2 安装本地开发环境本案例需要以下开发工具： 工具版本要求用途Python≥ 3.11后端运行时Node.js≥ 18.0前端构建npm≥ 9.0前端包管理Git≥ 2.30版本控制3 、构建会议智脑应用3.1 部署项目代码1）项目结构说明：ai-meeting/├── app/│   ├── core/                    # 核心基础设施│   │   ├── config.py            # Pydantic Settings 配置管理│   │   ├── database.py          # 异步数据库引擎 + 会话工厂│   │   ├── exceptions.py        # 统一异常处理器│   │   └── logging.py           # 日志配置│   ├── models/                  # SQLAlchemy ORM 模型│   │   ├── user.py              # 用户模型│   │   ├── meeting.py           # 会议模型│   │   ├── task.py              # 任务模型│   │   └── risk_alert.py        # 风险预警模型│   ├── schemas/                 # Pydantic 请求/响应 Schema│   ├── api/                     # FastAPI 路由│   │   ├── auth.py              # 认证 + 用户管理 API│   │   ├── meetings.py          # 会议 CRUD + 搜索 + 导出│   │   ├── tasks.py             # 任务列表 + 更新 + 排序│   │   └── skill.py             # 风险检测 API│   ├── services/                # 业务逻辑层│   │   ├── auth_service.py      # 注册/登录/JWT/密码哈希│   │   ├── meeting_service.py   # 会议业务逻辑│   │   ├── task_service.py      # 任务业务逻辑│   │   └── maas_service.py      # MaaS API + 本地摘要引擎│   └── main.py                  # FastAPI 应用入口├── frontend/│   ├── package.json             # 前端依赖│   ├── vite.config.js           # Vite 配置（API 代理）│   └── src/│       ├── main.js              # 入口（ElementPlus 中文 locale）│       ├── App.vue              # 布局（侧边栏 + 路由 + 登录状态）│       └── components/          # 12 个功能组件├── .env                         # 环境变量├── requirements.txt             # Python 依赖└── init_db.py                   # 数据库初始化脚本 2）下载源码         通过git下载源码到本地（含demo演示），代码仓地址：ai-meeting - AtomGitgit clone https://gitcode.com/ gcw_Xpooy7x3/ai-meeting.gitcd ai-meeting 3）关键代码讲解   3.1 配置管理——从 .env 加载 MaaS API Key        使用 Pydantic Settings 从 .env 文件加载配置，extra: "ignore" 允许旧变量不报错，@lru_cache 实现全局单例：from pydantic_settings import BaseSettingsfrom functools import lru_cacheclass AppSettings(BaseSettings):    DATABASE_URL: str = "sqlite+aiosqlite:///./ai_meeting.db"    REDIS_URL: str = "redis://localhost:6379/0"    MAAS_API_KEY: str = ""    MAAS_API_URL: str = "https://api.modelarts-maas.com/v2/chat/completions"    MAAS_MODEL: str = "deepseek-v4-flash"    APP_NAME: str = "会议智脑"    DEBUG: bool = False    JWT_SECRET: str = "change-me-in-production"    JWT_ALGORITHM: str = "HS256"    JWT_EXPIRE_MINUTES: int = 1440    model_config = {        "env_file": ".env",        "env_file_encoding": "utf-8",        "extra": "ignore",    }@lru_cache()def get_settings() -> AppSettings:    return AppSettings()         在项目根目录创建 .env 文件，将 MaaS 的 API Key、API 地址和模型名称填入：DATABASE_URL=sqlite+aiosqlite:///./ai_meeting.dbREDIS_URL=redis://localhost:6379/0MAAS_API_KEY=<你的华为云MaaS API Key>MAAS_API_URL=https://api.modelarts-maas.com/v2/chat/completionsMAAS_MODEL=deepseek-v4-flashAPP_NAME=会议智脑DEBUG=trueJWT_SECRET=meeting-brain-jwt-secret-2026   3.2 核心逻辑——调用华为云 MaaS 大模型生成摘要      这是本案例的核心代码。process_meeting 函数实现多级降级策略：优先调用 MaaS API，失败时降级到本地规则引擎。同时支持 Redis 缓存（可选，连接失败自动跳过）。         System Prompt 设计——明确指定英文字段名和 JSON 输出格式，避免模型返回中文键名：SYSTEM_PROMPT = """你是一个严谨的会议纪要专家。请处理输入的会议记录并输出JSON。规则：- summary：不超过150字，仅包含最终结论，不重复会议过程- key_decisions：只提取有明确结论或投票通过的事项，最多5条- tasks：仅当原文明确提及"某人负责某事"或"需要在某时间前完成"时才提取，严禁臆造- 日期格式统一为 YYYY-MM-DD，如果原文没有年份则默认为当前年份- 如果原文信息不足，对应字段返回空列表或空字符串，不要编造输出必须是合法JSON，严格使用以下英文字段名（禁止使用中文字段名）：{  "summary": "一句话摘要",  "key_decisions": ["决策1", "决策2"],  "tasks": [    {"description": "任务描述", "assignee": "责任人", "deadline": "YYYY-MM-DD", "priority": "high/mid/low"}  ]}"""         MaaS API 调用——使用 httpx.AsyncClient 异步调用，指数退避重试（最多3次，仅对超时/连接错误重试），超时时间90秒：async def _call_maas_api(record_text: str) -> dict:    settings = get_settings()    headers = {        "Authorization": f"Bearer {settings.MAAS_API_KEY}",        "Content-Type": "application/json",    }    body = _build_request_body(record_text)    for attempt in range(1, MAX_RETRIES + 1):        try:            async with httpx.AsyncClient(timeout=90) as client:                resp = await client.post(settings.MAAS_API_URL, headers=headers, json=body)            if resp.status_code != 200:                raise AppException(502, f"MaaS 接口返回错误码: {resp.status_code}")            content = resp.json()["choices"][0]["message"]["content"]            start, end = content.find("{"), content.rfind("}") + 1            parsed = json.loads(content[start:end])            # 兼容中文键名            if "摘要" in parsed and "summary" not in parsed:                parsed["summary"] = parsed.pop("摘要")            if "关键决策" in parsed and "key_decisions" not in parsed:                parsed["key_decisions"] = parsed.pop("关键决策")            if "任务清单" in parsed and "tasks" not in parsed:                parsed["tasks"] = parsed.pop("任务清单")            raw_tasks = parsed.get("tasks") or parsed.get("task_list") or parsed.get("action_items") or []            normalized_tasks = []            for t in raw_tasks:                if isinstance(t, dict):                    nt = {                        "description": t.get("description") or t.get("task") or t.get("任务") or "",                        "assignee": t.get("assignee") or t.get("person") or t.get("负责人") or "",                        "deadline": t.get("deadline") or t.get("due_date") or t.get("截止日期") or "",                        "priority": t.get("priority") or "mid",                    }                    normalized_tasks.append(nt)                elif isinstance(t, str):                    m = re.match(r"^([\u4e00-\u9fa5]{2,4})[：:]\s*(.+)$", t)                    if m:                        assignee, desc = m.group(1), m.group(2)                        normalized_tasks.append({"description": desc, "assignee": assignee, "deadline": "", "priority": "mid"})            parsed["tasks"] = normalized_tasks            return parsed        except (httpx.TimeoutException, httpx.ConnectError):            wait = 2 ** attempt            await asyncio.sleep(wait)    raise AppException(502, "MaaS 调用失败")         多级降级与缓存——完整的 process_meeting 流程：async def process_meeting(record_text: str) -> dict:    if not record_text or not record_text.strip():        return {"summary": "", "key_decisions": [], "tasks": []}    settings = get_settings()    if not settings.MAAS_API_KEY:        return _local_summarize(record_text)    redis_client = await _get_redis()    try:        if redis_client:            cached = await redis_client.get(_cache_key(record_text))            if cached:                return json.loads(cached)        try:            result = await _call_maas_api(record_text)        except Exception:            result = _fallback_result(record_text)        if redis_client:            await redis_client.set(_cache_key(record_text), json.dumps(result, ensure_ascii=False), ex=7*24*3600)        return result    finally:        if redis_client:            await redis_client.close()3.3 会议上传与 AI 处理联动   会议上传 API 在创建记录后，自动调用 process_meeting 进行 AI 处理，将生成的摘要、决策写入 Meeting 记录，并将提取的任务批量创建为 Task 记录：class MeetingService:    def __init__(self, db: AsyncSession):        self.db = db    async def upload_meeting(self, title, record_text, tags=None):        meeting = Meeting(title=title, record_text=record_text, status=MeetingStatus.pending, tags=tags)        self.db.add(meeting)        await self.db.flush()        if record_text and record_text.strip():            await self._process_meeting_content(meeting)        return meeting.id    async def _process_meeting_content(self, meeting):        try:            result = await process_meeting(meeting.record_text)            meeting.summary = result.get("summary", "")            meeting.key_decisions = result.get("key_decisions", [])            meeting.status = MeetingStatus.processed            for task_data in result.get("tasks", []):                task = Task(                    meeting_id=meeting.id,                    description=task_data.get("description", ""),                    assignee=task_data.get("assignee", ""),                    deadline=self._parse_date(task_data.get("deadline")),                    priority=self._parse_priority(task_data.get("priority")),                    status=TaskStatus.todo,                )                self.db.add(task)            await self.db.flush()        except Exception as exc:            logger.error(f"会议处理失败，保持pending状态: {exc}")3.4 数据库会话管理——SQLite 异步适配   SQLite 适配关键点：WAL 模式支持并发读、外键约束、不使用连接池。get_db() 通过 yield 实现请求级会话，自动 commit/rollback：from sqlalchemy.ext.asyncio import create_async_engine, async_sessionmaker, AsyncSessionfrom sqlalchemy import eventsettings = get_settings()_is_sqlite = settings.DATABASE_URL.startswith("sqlite")engine = create_async_engine(settings.DATABASE_URL, echo=settings.DEBUG)if _is_sqlite:    @event.listens_for(engine.sync_engine, "connect")    def _set_sqlite_pragma(dbapi_conn, connection_record):        cursor = dbapi_conn.cursor()        cursor.execute("PRAGMA journal_mode=WAL")        cursor.execute("PRAGMA foreign_keys=ON")        cursor.close()AsyncSessionLocal = async_sessionmaker(bind=engine, class_=AsyncSession, expire_on_commit=False)async def get_db() -> AsyncSession:    async with AsyncSessionLocal() as session:        try:            yield session            await session.commit()        except Exception:            await session.rollback()            raise3.5 前端 Vite 代理配置   开发环境将 /api 请求代理到后端 8000 端口：import { defineConfig } from 'vite'import vue from '@vitejs/plugin-vue'export default defineConfig({  plugins: [vue()],  server: {    proxy: {      '/api': { target: 'http://localhost:8000', changeOrigin: true },      '/health': { target: 'http://localhost:8000', changeOrigin: true },    },  },})4）运行调试   步骤1：安装后端依赖pip install -r requirements.txt   步骤2：安装前端依赖cd frontendnpm installcd ..   步骤3：初始化数据库python init_db.py   执行成功后输出：数据库表创建完成示例数据初始化完成！2个用户 + 3个会议 + 10项任务  管理员: admin / admin123  普通用户: demo / demo123     步骤4：启动后端服务uvicorn app.main:app --reload --port 8000   启动后访问 http://localhost:8000/docs 可查看自动生成的 OpenAPI 交互式文档：     步骤5：启动前端开发服务器cd frontendnpm run dev   启动后访问 http://localhost:5173，进入登录页面：     步骤6：登录并体验完整功能   使用 admin / admin123 登录，进入数据总览页面：     点击左侧菜单"上传会议"，粘贴会议记录文本，点击"提交会议记录"：     上传成功后点击"查看详情"，查看 AI 自动生成的摘要、关键决策和任务清单：     切换到"任务看板"页面，拖拽卡片切换任务状态：     切换到"任务甘特图"页面，查看任务时间线：     切换到"风险检测"页面，点击"立即检测"：  4 、释放资源本案例使用本地 SQLite 数据库和可选 Redis，不涉及华为云付费资源的持续占用。如需释放：• 删除本地 ai_meeting.db 文件即可清除所有数据• 如使用了华为云 MaaS Tokens 代金券，代金券到期后自动失效，无需手动释放5 、扩展资料说明• 想了解更多关于华为云 MaaS 大模型服务的可以访问：https://support.huaweicloud.com/productdesc-maas/maas_01_0001.html• 想了解更多关于 FastAPI 框架的可以访问：https://fastapi.tiangolo.com/• 想了解更多关于 Vue 3 组合式 API 的可以访问：https://cn.vuejs.org/guide/introduction.html• 想了解更多关于 Element Plus 组件库的可以访问：https://element-plus.org/zh-CN/ 

1 、概述1.1 案例介绍商品管理后台Web应用——GoodsManager。该系统采用 Python Flask + SQLite + Bootstrap 5 技术栈，实现了商品全生命周期管理、库存预警、分类管理、图片本地托管、操作记录追踪与防篡改、数据加密导入导出、撤回重做、首页仪表盘等核心功能，并采用毛玻璃主题设计，背景图动态提取主色调实现浅色/深色自适应。通过本案例，开发者将体验如何利用CodeArts代码智能体的Spec-Driven Development（规格驱动开发）工作流，从需求规格定义、实现方案设计、编码任务规划到代码实现的完整过程，高效交付一个功能完备、代码质量高、架构模块化的Web应用。1.2 适用对象个人开发者高校学生1.3 案例时间本案例总时长预计180分钟。1.4 案例流程 说明：1. AI IDE华为云码道（CodeArts）代码智能体安装部署；2.使用CodeArts代码智能体，通过自然语言描述需求，自动生成需求规格文档（spec.md）；3.基于需求规格文档，自动生成实现方案文档（design.md），包含架构设计、接口设计、数据模型等；4.基于实现方案文档，自动生成编码任务规划（tasks.md），将需求拆解为可执行的编码任务；5.根据编码任务规划，逐步实现各功能模块代码，包括用户认证、商品管理、分类管理、图片托管、操作记录、数据导入导出、撤回重做、仪表盘等；6.运行start.bat一键启动应用，在浏览器中验证所有功能。1.5 资源总览本案例预计花费240元。体验完成后请及时释放资源，避免产生多余的费用。实际实践过程中的费用可能较下表更少，示例费用是分多次对话、添加新功能以及多次修复bug所用的。资源名称描述/规格价格Python 3.11运行环境免费Flask / Flask-SQLAlchemy / WerkzeugPython Web框架及ORM免费华为云码道（CodeArts）代码智能体专业版139元/月华为云码道（CodeArts）代码智能体按需计费约100元 2 、环境和资源准备2.1 AI IDE华为云码道安装部署参考案例《AI IDE华为云码道（CodeArts）代码智能体安装部署》完成Windows版AI IDE华为云码道（CodeArts）代码智能体安装部署。打开CodeArts代码智能体（IDE内置的AI助手），准备开始通过自然语言描述需求来生成项目代码。 注：本案例中项目所创建的本地目录为E:/CodeArts/PGAMEGoodsManager；本案例使用码道智能体模式，模型选择GLM-5.1，开发模式为Spec-Driven Development（规范开发）。3 、构建商品管理应用3.1 描述项目需求在CodeArts代码智能体的对话框中，输入项目需求描述。本案例的需求描述如下：开发一个名为"PGAMEGoodsManager"（PGAME可以更换为其他名称）的游戏周边商品管理后台Web应用，使用Python Flask + SQLite + Bootstrap技术栈。要求：后端Python Flask + SQLite，前端HTML + CSS (Bootstrap 5) + JavaScript；代码必须模块化（Flask Blueprint），以便后续增加新功能；库存预警≤3红色，4-5黄色，≥6默认颜色；管理员账号只能由现有admin派发，禁止直接注册成管理员；折扣价与售价不同用灰色背景标出，相同用"-"占位；数据导入导出使用简单加密过的JSON，密钥写在文件开头；品牌名显示为"P-GAME"（同样可以更改），点击以跳转仪表盘；操作类型备注应自动检测（对比新旧数据），不要求手动选择；全站采用毛玻璃(glass)主题，背景图从backgrounds/目录读取，动态提取主色调。有部分具体要求在后续3.2-3.4有详细罗列。 CodeArts代码智能体将根据需求描述，自动创建项目目录结构并生成规格驱动开发（SDD）文档目录：.codeartsdoer/specs/pgame_goods_mgr/├── spec.md         # 需求规格文档├── design.md       # 实现方案文档└── tasks.md        # 编码任务规划3.2 审阅需求规格文档（spec.md）CodeArts代码智能体自动生成了需求规格文档spec.md，包含以下核心内容：•      组件定位：核心职责、核心输入/输出、职责边界•      领域术语：游戏周边商品、分类、成本、折扣价、库存预警、数据快照、加密JSON等•      角色与边界：admin管理员、普通用户、审计员•      核心能力（5.1-5.18）：用户认证、商品管理、分类管理、库存预警、图片托管、示例数据初始化、商品搜索、一键启动、操作记录、导航交互、数据导出与导入、首页仪表盘、商品详情页、撤回与重做、操作审计与防篡改、数据合并导入、主题色彩系统重构、其他Bug修复•      数据约束（6.1-6.15）：商品/分类/用户账号/商品图片/搜索条件/操作记录/排序/快照/导出文件/仪表盘统计/签名/审计日志/审计员账号/主题色彩字典 如图为spec.md部分内容，开发者可审阅spec.md内容，如有修改意见可告知CodeArts代码智能体进行修改。确认无误后，进入下一阶段。3.3 审阅实现方案文档（design.md）CodeArts代码智能体基于spec.md自动生成了实现方案文档design.md，包含以下核心内容：3.3.1 需求与存量功能关系分析design.md首先分析了需求功能与存量功能的关系，将功能分为三类：已实现功能、需要扩展的功能（需在现有代码上扩展）、需要新增的功能或接口（全新设计）。其中首次构建项目时后面的两点应该没有内容。3.3.2 实现模型包含上下文视图（单体Flask Web应用架构）、服务/组件总体架构（9个Blueprint模块）、实现设计文档（15个流程图，覆盖用户认证、商品操作、排序、详情页、分类删除、数据导出/导入/撤回、删除撤回/重做、管理员派发、仪表盘、操作记录、图片资源池管理、系统初始化、HMAC签名链、签名校验、审计日志、审计员权限控制、管理员权限撤回、数据合并导入、主题色彩系统重构、折扣价联动修复等）。3.3.3 接口设计 共设计了42个接口，分为认证接口组（5个）账号管理接口组（5个）商品管理接口组（8个）分类管理接口组（3个）操作记录接口组（3个）图片托管接口组（1个）数据管理接口组（3个）撤回重做接口组（2个）仪表盘接口组（1个）增量接口组（7个）合并导入接口组（1个）审计日志接口组（1个）其他Bug修复接口组（2个）3.3.4 数据模型定义了7个数据模型：User（含is_admin、is_auditor）、Category、Goods（含discount_price、updated_at）、OperationLog（含change_type、signature）、DataSnapshot、DeletedItem（含status、get_summary()）、AuditLog。开发者可审阅design.md内容，如有修改意见可告知CodeArts代码智能体进行修改。确认无误后，进入下一阶段。3.4 审阅编码任务规划（tasks.md）CodeArts代码智能体基于design.md自动生成了编码任务规划tasks.md，将整个项目拆解为22个编码/验证节：第1节：项目基础设施搭建（目录结构、依赖、数据库模型、Blueprint注册）第2节：用户认证功能实现（注册/登录/退出/装饰器/页面模板）第3节：图片托管功能实现（上传/展示/清理/替换/批量读写） 第4节：分类管理功能实现（列表/搜索/新增/删除/页面模板）第5节：商品管理功能实现（列表/搜索/排序/新增/编辑/删除/详情/页面模板第6节：账号管理功能实现（设置页/修改密码/删除账号/创建管理员）第7节：操作记录功能实现（自动记录/查看/删除/页面模板）第8节：数据导入导出功能实现（导出/导入/页面模板）第9节：撤回与重做功能实现（导入撤回/删除撤回/重做）第10节：首页仪表盘功能实现（统计/记录/快捷按钮）第11-13节：导航更新/系统初始化/一键启动第14节：集成测试与验证（20个子节覆盖所有功能验证）接下来的内容应当也是第一轮对话就写入的第15-16节：操作审计与防篡改功能实现与验证（增量）第17-18节：数据合并导入功能实现与验证（增量）第19-20节：主题色彩系统重构功能实现与验证（增量）第21-22节：其他Bug修复与优化功能实现与验证（增量）开发者可审阅tasks.md内容，如有修改意见可告知CodeArts代码智能体进行修改。确认无误后，进入下一阶段。3.5 代码实现确认tasks.md后，CodeArts代码智能体将根据编码任务规划逐步实现各功能模块代码。以下是各模块的实现要点：3.5.1 应用入口与数据库初始化（app.py）app.py是应用的核心入口，负责：•      创建Flask应用工厂函数create_app()，配置SECRET_KEY、SQLALCHEMY_DATABASE_URI等•      注册9个Blueprint（auth/account/goods/category/image/oplog/data/dashboard/undo/audit）•      数据库自动初始化：首次启动时创建表结构和示例数据（1个admin + 1个分类 + 1个商品）•      Schema迁移检测：通过inspect检测新增字段（signature/is_auditor等），缺失时触发数据库重建•      背景图主色调提取：extract_bg_colors()扫描backgrounds/目录，提取RGB平均值，计算亮度luma，预计算40个CSS颜色字符串•      全局context_processor：注入theme字典（40键）至所有模板•      背景图服务路由：/bg/<filename>提供图片服务，含Cache-Control: max-age=86400缓存头 3.5.2 数据模型层（models.py）定义了7个数据模型：模型关键字段说明Userid, username, password_hash, is_admin, is_auditor, created_at用户账号，支持三种角色Categoryid, name商品分类，名称唯一Goodsid, name, game, category_id, cost, price, discount_price, stock, image_path, created_at, updated_at商品，含折扣价和修改时间OperationLogid, operator, action, target_type, target_name, change_type, signature, detail, created_at操作记录，含HMAC签名DataSnapshotid, snapshot_type, snapshot_data, related_operation, created_at数据快照，支持撤回DeletedItemid, item_type, item_data, status(deleted/undone), created_at删除暂存，支持撤回/重做AuditLogid, audit_time, operator, operation_type, deleted_summary, deleted_count审计日志，不可修改/删除 3.5.3 用户认证模块（auth.py）实现了三个权限装饰器：•      login_required：检查Session中user_id，未登录重定向至登录页；•      admin_or_auditor_required：仅admin和审计员可访问（用于审计日志页面）；•      not_auditor_required：审计员禁止访问（用于商品/分类/数据管理路由）。注册路由禁止创建管理员（User默认is_admin=False）。登录成功后Session写入user_id、username、is_admin、is_auditor。 3.5.4 商品管理模块（goods.py）商品管理是系统的核心模块，实现了以下功能：•      商品列表：支持5种搜索条件（keyword/game/category_id/stock_status/sort）组合筛选，6种排序方式；  图：六种排序方式•      库存预警：≤3红色（danger）、4-5黄色（warning）、≥6默认颜色•      折扣价显示：≠售价时灰色背景+显示原售价，=售价时显示"-"占位符•      商品新增：折扣价默认等于售价，新增时修改售价折扣价自动联动（使用prevPrice变量追踪）•      商品编辑：折扣价独立不联动，系统自动检测change_type（对比新旧数据差异）•      商品删除：删除前保存数据到DeletedItem（status=deleted），不立即删除图片文件•      商品详情页：上方展示信息+最近5条修改记录+库存变动记录，下方编辑区 3.5.5 操作记录与防篡改模块（oplog.py）这是本案例最具特色的功能模块，实现了操作记录的HMAC-SHA256签名链防篡改机制：签名链生成：每条操作记录创建时，基于operator|action|target_type|target_name|change_type|created_at_str|prev_signature七个字段生成HMAC-SHA256签名。首条记录的prev_signature为预设常量"GENESIS"，后续记录依赖前一条记录的签名值，形成哈希链。  签名校验：每次访问操作记录页面时，按id升序遍历所有记录，使用hmac.compare_digest常量时间比较验证签名链完整性。校验通过显示绿色✓标记，校验失败显示红色✗"校验失败"警告。签名链重建：admin删除/清空操作记录后，自动调用_rebuild_signature_chain()按id升序重新生成所有记录的签名，保持签名链完整性。审计日志：admin删除操作记录时，自动将删除行为记录到AuditLog表（不可修改/删除），包含审计时间、操作账号、操作类型、被删除记录摘要、删除数量。 3.5.6 数据导入导出模块（data.py）数据导出：收集商品/分类/操作记录/用户账号/image_pool/图片文件 → 序列化为JSON → base64编码+密钥加密 → 生成下载文件（第1行密钥，第2行起加密数据）。数据导入（合并模式）：保留当前用户账号，分类按名称去重（建立旧ID→新ID映射），商品按name+game+category_id三元组去重更新，操作日志追加，图片增量导入。合并导入后自动重建签名链。 3.5.7 撤回重做模块（undo.py）删除撤回：从DeletedItem恢复被删除的数据，将status从deleted改为undone（而非删除记录），恢复时不强制指定原始id（让数据库自动分配）。删除重做：查找status=undone的最近记录，重新删除对应数据并删除图片文件，记录"重做删除"操作日志。重做按钮独立显示，显示将被重做的商品名称和成本。保留最近10次删除记录。 3.5.8 账号管理模块（account.py）修改密码：验证旧密码+确认新密码（两次输入一致），成功后清除Session要求重新登录。创建管理员/审计员：仅admin可创建，校验用户名唯一性和密码强度（≥6位）。撤回管理员权限：admin可将其他管理员降级为普通用户（不可撤回自身），撤回操作自动记录到操作日志。 3.5.9 毛玻璃主题与动态色调（base.html）系统启动时通过extract_bg_colors()提取背景图RGB主色调，计算亮度luma = 0.299*R + 0.587*G + 0.114*B。luma>140为浅色系（降低毛玻璃明度+黑色字体），≤140为深色系（提高毛玻璃明度+白色字体）。所有CSS颜色值在Python端预计算为完整rgba()字符串，通过CSS自定义属性传递（base.html中style#theme-vars块的:root仅此处使用Jinja2赋值CSS变量），主CSS只引用var(--xxx)，主CSS和JS中零Jinja2引用。提示框(.alert)字体始终黑色。粒子效果：35个粒子+连线动画，颜色通过HTML属性data-pr/data-pg/data-pb传递，降帧至30fps。导航滑块指示器与页面切换动画：sessionStorage存储上一页面位置，cubic-bezier缓动曲线0.3s平滑滑动。opacity+transform淡入淡出0.35s。 3.5.10 一键启动（start.bat）start.bat脚本自动完成以下操作：•      使用@echo off关闭命令回显；•      输出启动提示信息"正在启动 P-GAME GoodsManager..."；•      检查并创建Python虚拟环境（venv）；•      安装项目依赖（pip install -r requirements.txt）；•      启动Flask应用并等待3秒；•      自动打开默认浏览器访问。•      注意：不要显示默认管理员账号信息，防止敏感信息泄露3.6 运行调试3.6.1 使用一键启动脚本双击项目根目录下的start.bat文件，系统将自动创建Python虚拟环境、安装依赖、启动Flask应用并打开浏览器访问图中地址（localhost）   3.6.2 手动启动在项目根目录下打开终端，依次执行以下命令：python -m venv venvvenv\Scripts\activatepip install -r requirements.txtpython app.py 3.6.3 登录系统启动后在浏览器中访问 http://localhost:5000，使用默认管理员账号登录：•      用户名：admin•      密码：admin123  3.7 功能验证3.7.1 仪表盘验证登录成功后自动跳转至仪表盘页面，验证以下内容：•      4个统计卡片：总商品数、总分类数、总用户数、库存预警商品数•      最近5条操作记录（含操作时间、操作账号、操作内容、操作类型备注）•      4个快捷按钮：新增商品、新增分类、商品列表、数据管理3.7.2 商品管理验证点击"商品管理"页签，验证以下功能：•      搜索功能：输入商品名称关键词、所属游戏关键词、选择分类和库存状态•      排序功能：选择6种排序方式（最新创建升降序、最新修改升降序、售价升降序）•      库存预警：库存≤3显示红色，4-5显示黄色，≥6默认颜色•      折扣价显示：折扣价≠售价时灰色背景+显示原售价，=售价时显示"-"•      新增商品：填写完整信息，折扣价默认等于售价并联动•      编辑商品：修改信息后系统自动检测操作类型•      删除商品：确认后删除，显示撤回按钮•      商品详情：点击商品名称进入详情页，查看修改记录和库存变动  图：商品列表页面——搜索+排序+库存预警颜色+折扣价灰色背景  图：新增商品页面——竖向布局，折扣价联动  图：商品详情页面——上方信息+修改记录，下方编辑区 3.7.3 分类管理验证点击"分类管理"页签，验证以下功能：•      新增分类：填写分类名称创建•      搜索功能：输入分类名称关键词模糊搜索•      删除分类：无关联商品时可删除，有关联商品时拒绝•      删除撤回：删除后点击撤回恢复  图：分类管理页面——搜索+新增+删除+撤回按钮 3.7.4 数据导入导出验证点击"数据管理"页签，验证以下功能：•      数据导出：点击导出按钮，下载加密JSON文件（第1行密钥，第2行起加密数据）•      数据导入（合并模式）：上传加密JSON文件并输入密钥，合并导入数据（保留当前用户、合并分类/商品/日志/图片）•      导入撤回：点击撤回按钮恢复到导入前状态•      密钥错误：输入错误密钥，提示"密钥错误，无法解密数据"  图：数据管理页面——导出按钮+导入表单+撤回按钮 3.7.5 操作记录与签名校验验证点击"操作记录"页签，验证以下功能：•      签名校验列：所有记录显示✓绿色标记（校验通过）•      admin删除记录：删除后签名链自动重建，剩余记录校验仍全部通过•      审计日志：删除操作记录后，审计日志页面自动新增一条记录  图：操作记录页面——签名校验✓/✗标记  图：审计日志页面——删除操作记录的审计追踪 3.7.6 账号管理验证点击"账号设置"页签，验证以下功能：•      修改密码：输入旧密码和新密码（两次输入一致），成功后需重新登录•      创建管理员：admin可创建新管理员账号•      创建审计员：admin可创建审计员账号•      撤回管理员权限：admin可将其他管理员降级为普通用户    •      审计员登录：审计员导航仅显示仪表盘/操作记录/审计日志/账号设置   3.7.7 毛玻璃主题验证验证以下主题效果：•      背景图动态色调：系统根据背景图亮度自动切换浅色/深色主题•      浅色背景：毛玻璃明度降低，字体黑色，页面文字清晰可读•      深色背景：毛玻璃明度提高，字体白色，页面文字清晰可读•      提示框字体始终黑色•      粒子效果：35个粒子•      导航滑块：页签切换时滑块平滑滑动•      页面切换动画：内容区淡入淡出过渡 3.7.8 演示视频https://atomgit.com/MingMond/GoodsManagerDemo4 、释放资源本案例使用开发者空间资源，可以选择释放。如需清理项目文件，删除PGAMEGoodsManager目录即可。如需删除数据库文件，删除instance/目录下的goods.db文件即可。5 、扩展资料说明想了解更多关于华为云码道（CodeArts）代码智能体的可以访问：https://developer.huaweicloud.com/space/home

插件初始化遇到问题，部分功能可能受限。如插件不可用请联系技术支撑。错误细节：Error: Server process start failed with exit code 1, signal null, error output: Error: Unexpected error, check log file at c:\Users\Jason\.codeartsdoer\codearts-data\log\kernel-codeartsdoer-incognito-2026-07-23T102558-39932-0.log for more details Failed to start server on port 50870at L (c:\Program Files\CodeArts Agent\resources\app\extensions\vscode-codebot\out\extension.js:192:77)at async dQ0 (c:\Program Files\CodeArts Agent\resources\app\extensions\vscode-codebot\out\extension.js:192:5103)at async u.startServer (c:\Program Files\CodeArts Agent\resources\app\extensions\vscode-codebot\out\extension.js:9851:16628)at async c:\Program Files\CodeArts Agent\resources\app\extensions\vscode-codebot\out\extension.js:9851:8945at async u.retryAsync (c:\Program Files\CodeArts Agent\resources\app\extensions\vscode-codebot\out\extension.js:9851:6735)at async c:\Program Files\CodeArts Agent\resources\app\extensions\vscode-codebot\out\extension.js:9851:8874

在 idea 2026.2 中无法使用，啥时候能支持

一、概述1.1 案例介绍本案例展示了如何使用华为云码道（CodeArts）代码智能体快速开发一个完整的食堂菜品评价管理系统（FCEMS - Food Court Evaluation Management System）。通过自然语言对话方式，从需求分析、系统设计、代码生成到功能迭代，完整体验AI辅助开发的强大能力。系统包含：顾客端：浏览菜品、提交评价、修改/删除评价（3天内）管理端：菜品管理、评价管理、分类管理、用户管理后端API：完整的RESTful API数据库：MySQL数据库设计技术栈：后端：Node.js + Express + MySQL前端：原生HTML + CSS + JavaScript认证：JWT TokenAI辅助：华为云码道代码智能体代码仓库及demo演示视频：cid:link_31.2 适用对象个人开发者高校学生1.3 案例时间如：本案例总时长预计60分钟（包含环境准备、开发调试、功能测试）。1.4 案例流程说明：华为云码道（CodeArts）代码智能体安装部署生成项目 PRD 文档，明确系统需求和功能设计基于 PRD 文档，智能体生成完整的后端 API 和数据库设计智能体生成前端顾客端和管理端界面启动服务，测试系统功能，发现问题通过对话方式描述问题，智能体自动修复代码根据用户反馈，迭代优化系统功能1.5 资源总览本案例预计花费26.47元。体验完成后请及时释放资源，避免产生多余的费用。资源名称规格单价（元）华为云码道（CodeArts）代码智能体基础版26.47二、环境和资源准备2.1 开通华为云码道CodeArts登录华为云码道，开通CodeArts服务。在CodeArts中创建项目，进入代码智能体（CodeArts IDE）开发环境。2.2 本地开发环境要求在CodeArts IDE中开发时，需确保本地已安装以下工具：Node.js 18+MySQL 8.0+三、构建食堂菜品评价管理系统3.1 需求分析与系统设计在码道对话界面选择 氛围编程模式(Vibe-Coding)，发送下述请求。实现某食堂的菜品评价管理系统。用于顾客评价反馈食堂菜品，为食堂管理人员提供改进依据。实现菜品相关信息（品名、原材料、照片、价格等）管理。实现菜品的评价、打分、查询等功能。这是我的基础要求，请基于这个要求的基础上给出更加详细具体的项目设计报告。3.2 后端开发1）项目结构说明：使用CodeArts智能体生成的后端项目结构：fcems/backend/ ├── src/ │ ├── app.js # 主应用入口 │ ├── config/ │ │ └── database.js # 数据库配置 │ ├── middleware/ │ │ └── auth.js # 认证中间件 │ └── routes/ │ ├── auth.js # 认证路由 │ ├── dish.js # 菜品路由 │ ├── review.js # 评价路由 │ ├── category.js # 分类路由 │ ├── analytics.js # 数据分析路由 │ └── user.js # 用户路由 ├── database/ │ ├── init.js # 数据库初始化脚本 │ ├── add-test-data.js # 添加测试数据 │ └── add-reviews.js # 添加评价数据 ├── .env # 环境变量配置 ├── package.json # 依赖配置 └── package-lock.json根据项目设计报告开发完整的食堂菜品评价管理系统。2）数据库配置 (src/config/database.js)const mysql = require('mysql2/promise'); require('dotenv').config(); const dbConfig = { host: process.env.DB_HOST || 'localhost', user: process.env.DB_USER || 'root', password: process.env.DB_PASSWORD || '', database: process.env.DB_NAME || 'fcems', waitForConnections: true, connectionLimit: 10, queueLimit: 0 }; const pool = mysql.createPool(dbConfig); async function query(sql, params) { const [rows] = await pool.execute(sql, params); return rows; } module.exports = { query, transaction, pool }; 3）认证中间件 (src/middleware/auth.js)const jwt = require('jsonwebtoken'); const { query } = require('../config/database'); const auth = async (req, res, next) => { try { const token = req.header('Authorization')?.replace('Bearer ', ''); if (!token) { return res.status(401).json({ success: false, message: '请先登录' }); } const decoded = jwt.verify(token, process.env.JWT_SECRET); const users = await query('SELECT * FROM user WHERE id = ? AND status = 1', [decoded.userId]); if (users.length === 0) { return res.status(401).json({ success: false, message: '用户不存在或已被禁用' }); } req.user = users[0]; req.token = token; next(); } catch (error) { res.status(401).json({ success: false, message: '认证失败，请重新登录' }); } }; const requireRole = (...roles) => { return (req, res, next) => { if (!roles.includes(req.user.role)) { return res.status(403).json({ success: false, message: '权限不足' }); } next(); }; }; module.exports = { auth, requireRole }; 4）菜品路由 (src/routes/dish.js)关键功能：获取菜品列表、添加菜品、编辑菜品、上下架、删除// 获取菜品列表（支持状态筛选） router.get('/', async (req, res) => { try { const { page = 1, limit = 10, status, search } = req.query; let sql = ` SELECT d.*, c.name as category_name, (SELECT AVG(rating) FROM review WHERE dish_id = d.id AND status = 1) as avg_rating FROM dish d LEFT JOIN category c ON d.category_id = c.id WHERE d.deleted_at IS NULL `; if (status !== undefined) { sql += ' AND d.status = ?'; params.push(parseInt(status)); } // ... 其他筛选条件 const dishes = await query(sql, params); res.json({ success: true, data: { dishes, total, page, limit } }); } catch (error) { res.status(500).json({ success: false, message: '获取菜品列表失败' }); } }); // 添加菜品（检查名称重复） router.post('/', auth, requireRole(2, 3), async (req, res) => { const { name, category_id, price } = req.body; // 检查名称是否重复 const [existingDish] = await query( 'SELECT id FROM dish WHERE name = ? AND deleted_at IS NULL', [name] ); if (existingDish) { return res.status(400).json({ success: false, message: '菜品名称已存在，请使用其他名称' }); } // 插入新菜品 const result = await query( 'INSERT INTO dish (name, category_id, price, ...) VALUES (?, ?, ?, ...)', [name, category_id, price, ...] ); res.json({ success: true, message: '菜品添加成功', data: { id: result.insertId } }); }); 5）评价路由 (src/routes/review.js)关键功能：提交评价、修改评价（3天内）、删除评价（3天内）、管理员回复// 修改评价（3天内） router.put('/:id', auth, async (req, res) => { const { id } = req.params; const { rating, content } = req.body; const [review] = await query('SELECT * FROM review WHERE id = ?', [id]); if (review.user_id !== req.user.id) { return res.status(403).json({ success: false, message: '只能修改自己的评价' }); } // 检查是否在3天内 const reviewDate = new Date(review.created_at); const now = new Date(); const daysDiff = (now - reviewDate) / (1000 * 60 * 60 * 24); if (daysDiff > 3) { return res.status(403).json({ success: false, message: '评价提交超过3天，不允许修改' }); } // 更新评价 await query('UPDATE review SET rating = ?, content = ? WHERE id = ?', [rating, content, id]); res.json({ success: true, message: '评价修改成功' }); }); // 管理员回复评价 router.post('/:id/reply', auth, requireRole(2, 3), async (req, res) => { const { id } = req.params; const { reply } = req.body; await query('UPDATE review SET admin_reply = ? WHERE id = ?', [reply, id]); res.json({ success: true, message: '回复成功' }); }); 至此后端API路由创建完成后端代码文件列表3.3 前端代码生成生成的前端界面包括：顾客端：菜品浏览、评价提交、我的评价管理管理端：登录页、仪表盘、菜品管理、评价管理、分类管理、用户管理美观的UI设计，使用渐变色和现代风格1）顾客端菜品展示async function loadDishes(page = 1) { let url = `${API_BASE}/dishes?page=${page}&limit=12&status=1`; const res = await fetch(url); const data = await res.json(); if (data.success) { renderDishes(data.data.dishes); } } function renderDishes(dishes) { const container = document.getElementById('dishesGrid'); container.innerHTML = dishes.map(dish => ` <div class="dish-card" onclick="showDishDetail(${dish.id})"> <div class="dish-image-container"> <img src="${dish.images ? JSON.parse(dish.images)[0] : ''}" onerror="this.parentElement.style.background='linear-gradient(135deg, #667eea 0%, #764ba2 100%)'"> </div> <div class="dish-info"> <h3>${dish.name}</h3> <div class="dish-rating">★ ${parseFloat(dish.avg_rating || 0).toFixed(1)}</div> <div class="dish-price">¥${dish.price}</div> </div> </div> `).join(''); } 2）评价提交（含时间限制检查）async function submitReview() { const review = { dish_id: currentDish.id, rating: selectedRating, tags: selectedTags, content: document.getElementById('reviewContent').value, is_anonymous: document.getElementById('isAnonymous').checked }; const res = await fetch(`${API_BASE}/reviews`, { method: 'POST', headers: { 'Content-Type': 'application/json', 'Authorization': `Bearer ${localStorage.getItem('token')}` }, body: JSON.stringify(review) }); const data = await res.json(); if (data.success) { alert(`评价提交成功！获得${data.data.points_earned}积分`); loadReviews(currentDish.id); } else { alert(data.message); } } 3）管理端菜品管理async function loadDishesPage() { const res = await fetch(`${API_BASE}/dishes?limit=100`, { headers: getAuthHeaders() }); const data = await res.json(); // 显示所有未删除的菜品（包括上架和下架） document.getElementById('pageContent').innerHTML = ` <table class="table"> <thead> <tr> <th>菜品名称</th> <th>状态</th> <th>操作</th> </tr> </thead> <tbody> ${data.data.dishes.map(dish => ` <tr> <td>${dish.name}</td> <td> <span class="badge ${dish.status === 1 ? 'badge-success' : 'badge-danger'}"> ${dish.status === 1 ? '上架' : '下架'} </span> </td> <td> <button onclick="editDish(${dish.id})">编辑</button> <button onclick="toggleDishStatus(${dish.id}, ${dish.status})"> ${dish.status === 1 ? '下架' : '上架'} </button> <button onclick="deleteDish(${dish.id})">删除</button> </td> </tr> `).join('')} </tbody> </table> `; } 4）管理员回复评价async function replyReview(id) { // 获取评价详情，显示已有回复 const res = await fetch(`${API_BASE}/reviews/all?limit=100`, { headers: getAuthHeaders() }); const data = await res.json(); const review = data.data.reviews.find(r => r.id === id); const existingReply = review ? (review.admin_reply || '') : ''; document.getElementById('modalBody').innerHTML = ` <h2>${existingReply ? '修改回复' : '回复评价'}</h2> <textarea id="replyContent" rows="4">${existingReply}</textarea> <button onclick="submitReply(${id})">提交</button> `; document.getElementById('modal').classList.add('active'); } 至此前端界面开发完成3.4 功能测试与问题修复3.4.1 测试系统功能1）测试顾客端访问：fcems/frontend/customer/index.html测试步骤：注册/登录账号浏览菜品列表点击菜品查看详情提交评价在"我的评价"中修改/删除评价【注册/登录账号页面】【浏览菜品列表】【点击菜品查看详情】【提交评价】【在"我的评价"中修改/删除评价】2）测试管理端访问：fcems/frontend/admin/login.html登录账号：用户名：admin密码：admin123测试步骤：查看仪表盘数据进入菜品管理，测试添加、编辑、上下架、删除进入评价管理，测试审核、回复进入分类管理，测试添加、编辑、删除进入用户管理，查看用户列表【管理端登录页面】【管理端仪表盘页面】【管理端菜品管理页面:可以添加、编辑、上下架、删除菜品】【添加菜品】【编辑菜品】【下架菜品】【上架菜品】【删除菜品】【管理端评价管理页面：可以审核、回复评价】【驳回评价】【回复评价】【管理端分类管理页面：可以添加、编辑、删除菜品分类】【点击“添加分类”按键】【点击分类的“删除”按键】【管理端用户管理页面，查看用户列表】3.4.2 发现问题并修复问题1：管理端登录后提示"无法连接到服务器"问题描述：登录成功后，页面弹出提示框"无法连接到服务器，请检查后端服务是否启动"原因分析：showPage函数使用了event.target，但从checkAuth调用时没有event对象修复方法：在CodeArts对话框中描述问题：管理端登录后弹出"无法连接到服务器"提示，控制台错误："Cannot read properties of undefined (reading 'target')"请修复这个问题。CodeArts自动修复代码：// 修改前 function showPage(page) { event.target.closest('.menu-item').classList.add('active'); // ... } // 修改后 function showPage(page, event) { if (event && event.target) { event.target.closest('.menu-item').classList.add('active'); } // ... } 问题2：菜品编辑按钮无反应问题描述：管理端菜品管理中，点击"编辑"按钮没有反应原因分析：缺少editDish和updateDish函数修复方法：在CodeArts对话框中输入：菜品管理的编辑按钮点击无反应，请添加菜品编辑功能。CodeArts生成编辑功能代码：async function editDish(id) { const [dishRes, categoriesRes] = await Promise.all([ fetch(`${API_BASE}/dishes/${id}`, { headers: getAuthHeaders() }), fetch(`${API_BASE}/categories`, { headers: getAuthHeaders() }) ]); const dishData = await dishRes.json(); const categoriesData = await categoriesRes.json(); if (dishData.success) { const dish = dishData.data; // 显示编辑表单，填充已有数据 document.getElementById('modalBody').innerHTML = ` <h2>编辑菜品</h2> <form onsubmit="updateDish(event, ${id})"> <input id="editDishName" value="${dish.name}" required> <select id="editDishCategory"> ${categoriesData.data.map(c => `<option value="${c.id}" ${c.id === dish.category_id ? 'selected' : ''}>${c.name}</option>` ).join('')} </select> <input id="editDishPrice" value="${dish.price}" required> <button type="submit">保存</button> </form> `; document.getElementById('modal').classList.add('active'); } } async function updateDish(e, id) { e.preventDefault(); const dish = { name: document.getElementById('editDishName').value, category_id: parseInt(document.getElementById('editDishCategory').value), price: parseFloat(document.getElementById('editDishPrice').value) }; const res = await fetch(`${API_BASE}/dishes/${id}`, { method: 'PUT', headers: getAuthHeaders(), body: JSON.stringify(dish) }); if ((await res.json()).success) { closeModal(); loadDishesPage(); } } 问题3：下架菜品从列表中消失问题描述：菜品下架后，从管理端列表中消失，无法重新上架需求：下架菜品应保留在列表中显示"下架"状态标签提供"上架"按钮修复方法：在CodeArts对话框中输入：菜品管理应该显示所有未删除的菜品，包括下架的菜品。下架菜品应该保留编辑、删除、上架按钮。顾客端只显示上架的菜品。CodeArts修复：后端修改：// 修改查询条件，只过滤deleted_at，不过滤status let sql = ` SELECT d.*, c.name as category_name FROM dish d LEFT JOIN category c ON d.category_id = c.id WHERE d.deleted_at IS NULL`; // 添加status参数支持 if (status !== undefined) { sql += ' AND d.status = ?'; params.push(parseInt(status)); } 前端修改：// 顾客端：只获取上架的菜品 let url = `${API_BASE}/dishes?page=${page}&limit=12&status=1`; // 管理端：获取所有未删除的菜品 let url = `${API_BASE}/dishes?limit=100`; 问题4：添加菜品时名称可重复问题描述：可以添加同名菜品，导致数据混乱修复方法：在CodeArts对话框中输入：添加菜品时，新菜品名称不允许与已有菜品名称相同。CodeArts添加名称检查：router.post('/', auth, requireRole(2, 3), async (req, res) => { const { name } = req.body; // 检查名称是否重复 const [existingDish] = await query( 'SELECT id FROM dish WHERE name = ? AND deleted_at IS NULL', [name] ); if (existingDish) { return res.status(400).json({ success: false, message: '菜品名称已存在，请使用其他名称' }); } // 继续添加... }); 问题5：管理员回复无法保存和显示对评价的回复问题描述：回复内容没有被保存下次点击"回复"时无法修改回复内容没有显示在顾客端修复方法：在CodeArts对话框中输入：评价回复功能问题： 1. 回复内容应该被保存 2. 下次点击回复时可以修改上一次的回复 3. 回复内容应该显示在顾客端对应评价的下方CodeArts修复：管理端修改：async function replyReview(id) { // 获取评价详情，显示已有回复 const res = await fetch(`${API_BASE}/reviews/all?limit=100`); const data = await res.json(); const review = data.data.reviews.find(r => r.id === id); const existingReply = review ? (review.admin_reply || '') : ''; // 显示编辑表单，填充已有回复 document.getElementById('modalBody').innerHTML = ` <h2>${existingReply ? '修改回复' : '回复评价'}</h2> <textarea id="replyContent">${existingReply}</textarea> <button onclick="submitReply(${id})">提交</button> `; } 顾客端修改：// 在评价下方显示管理员回复 ${review.admin_reply ? ` <div class="admin-reply" style=" margin-top: 1rem; padding: 1rem; background: linear-gradient(135deg, #f8f9fa 0%, #e9ecef 100%); border-left: 4px solid #667eea;"> <div style="color: #667eea; font-weight: 600;"> <i class="fas fa-reply"></i> 管理员回复 </div> <div>${review.admin_reply}</div> </div>` : ''} 四、扩展资料说明华为云码道CodeArts实战速成：cid:link_0华为云开发者AI训练营：cid:link_2