最近在整理一个 Python 数据采集脚本时，遇到了一个比较典型的问题：接口数据可以正常返回，但是拿到的数据并不能直接用于后续处理。以前写一些测试程序时，通常直接请求接口，然后打印返回结果。但当数据真正进入项目后，会发现接口返回的数据格式、字段类型、时间格式都会影响后面的分析和展示。如果前期没有做好数据整理，后面修改起来会比较麻烦。所以在这次项目里，我把数据获取和数据处理两个部分拆开，先完成接口接入，再对返回内容进行统一处理。从接口返回数据开始处理实际开发中，第三方接口返回的数据大多是 JSON 格式，例如：{ "symbol": "TEST", "price": "123.45", "timestamp": "1720000000" } 看起来结构比较简单，但直接使用会遇到一些小问题。比如价格字段可能是字符串类型，时间字段可能是时间戳，如果后续需要进行计算或者排序，就需要先转换成程序能够处理的数据类型。我一般会在数据进入业务逻辑之前增加一层简单的数据处理。项目结构大概如下：project ├── api.py ├── parser.py ├── main.py其中 api.py 负责请求数据，parser.py 负责转换格式，main.py 负责调用。这样做的好处是，如果以后更换数据来源，业务代码基本不用修改。使用 Python 调用实时数据接口下面用一个简单案例演示接口调用流程。首先安装 requests：pip install requests然后创建接口请求方法：import requests def get_data(): url = "https://api.alltick.co" response = requests.get(url) if response.status_code == 200: return response.json() return None 这里使用 AllTick 提供的实时数据接口作为示例，主要展示 Python 如何完成接口请求和数据获取。在实际项目中，接口地址、请求参数以及返回字段会根据具体需求调整。拿到数据之后，不建议直接把原始数据传给后面的业务模块，而是进行一次整理。例如：data = get_data() price = float(data["price"]) timestamp = int(data["timestamp"]) 经过转换后，价格字段可以参与计算，时间字段也方便后续格式化。开发过程中比较容易忽略的几个问题第一次接入实时数据接口时，我比较容易忽略异常情况。比如网络请求失败，如果代码没有处理，程序可能直接中断。简单处理方式：try: response = requests.get(url, timeout=5) except Exception as e: print(e) 另外一个问题是字段变化。第三方接口返回的数据结构并不是永远固定，如果代码直接读取字段：data["price"] 一旦字段不存在，就会出现异常。所以实际项目里通常会增加判断：if "price" in data: price = data["price"] 还有一个经常遇到的问题是时间处理。不同接口可能返回不同格式的时间，有的是时间戳，有的是标准时间字符串。建议在数据进入系统后统一格式，否则后续统计和展示容易出现问题。关于数据接口模块的一点实践经验通过这次开发可以发现，调用 API 本身并不是难点，真正影响项目稳定性的，往往是接口之后的数据处理流程。一个比较容易维护的数据应用，通常会把数据请求、格式转换、业务处理分开。这样做虽然前期多写了一些代码，但是后续扩展功能时会轻松很多。对于 Python 开发者来说，接入第三方数据接口是一个很常见的开发场景。无论是做数据展示工具，还是构建其他类型的数据应用，都需要先把数据获取和处理流程打牢。

您好！我使用VSCode工具的云道码插件，阅读本地文件后就会提示这些信息{"error_code":"TM.00001041","error_msg":"并发会话数已达上限(3个)，请关闭部分会话后重试。"}，新开会话也没用。

用云码也有几个月了，初期的时候有乱码还能理解，产品发展到了中期还是会出现乱码，不知道是不是在后台热更新导致的，忍忍也就过去了，现在已经收费到了后期阶段了竟然还有乱码，百思不得其解.....

1 概述1.1 案例介绍NingFlora 取自开发者名字“凝”与拉丁语花神“Flora”，寓意“技术之上绽放商业可能”。在数字化转型浪潮中，传统花店面临会员管理混乱、营销手段单一、库存盘点低效等痛点。本案例基于 Python + Flask 框架，构建了一套集四级会员体系、商品管理、购物车、订单结算、畅销统计于一体的智能花店管理系统。项目最大亮点在于，从需求分析到代码实现的全流程，均由华为云码道（CodeArts）代码智能体辅助完成。这使得开发周期从天级缩短至小时级，充分展现了AI赋能软件开发的巨大潜力与便捷性，为中小型零售企业的数字化转型提供了一条低成本、高效率的可行路径。1.2 适用对象个人开发者：快速掌握全栈Web应用开发，积累从0到1的完整项目经验。高校学生：实践Python Web开发、数据库设计与RESTful API，为课程设计或毕业设计提供参考。1.3 案例时间本案例总时长预计 70分钟。1.4 案例流程本实验模拟了一个典型的企业级开发流程，从环境准备到部署运行的完整闭环。   说明：(1) 环境准备：在华为开发者空间中创建云开发环境，并安装Python、Flask等核心依赖；(2) 需求设计：利用CodeArts代码智能体，通过自然语言描述，生成需求规格文档和技术设计文档；(3) 代码实现：由智能体根据设计文档，自动生成完整的项目骨架、业务逻辑、数据模型及API接口代码；(4) 测试验证：运行自动化脚本，初始化数据库与种子数据，并执行单元测试，确保核心链路功能正常；(5) 部署运行：启动Flask应用服务，通过Web界面和API接口体验完整业务功能。1.5 资源总览本案例预计花费 0元（使用免费资源）。体验完成后请及时释放资源，避免产生多余的费用。资源名称规格单价（元）开发者空间云开发环境ARM | 4 vCPUs 8GB | Ubuntu 24.04 Server 定制版免费华为云码道（CodeArts）代码智能体通用体验版免费SQLite数据库本地文件数据库免费2 环境和资源准备在编码开始前，需准备好开发和运行环境。本章节我们会依次完成云开发环境领取、开发环境配置和基础依赖安装，所有操作都基于免费资源开展，无需额外付费。接下来我们先从领取华为云开发者空间开始。2.1 领取华为云开发者空间(1) 登录华为开发者空间。(2) 点击菜单 开发平台 > 云开发环境 > 容器。(3) 选择配置为 ARM | 4 vCPUs 8GB | Ubuntu 24.04 Server 定制版的云环境。(4) 点击 创建 按钮，等待约2-3分钟，直到环境状态变为“运行中”。 2.2 配置开发环境进入云开发环境的终端界面，依次执行以下命令，安装项目所需的核心依赖，确保版本一致性以规避后期冲突。# 1. 更新软件包列表sudo apt-get update# 2. 安装Python 3和pipsudo apt-get install -y python3 python3-pip python3-venv# 3. 验证Python版本 (确保为3.10及以上)python3 --version# 4. 创建并进入项目目录mkdir -p ~/NingFloracd ~/NingFlora# 5. 创建Python虚拟环境python3 -m venv venv# 6. 激活虚拟环境source venv/bin/activate# 7. 安装指定版本的依赖库pip install Flask==2.3.3pip install Flask-SQLAlchemy==3.0.5pip install Flask-JWT-Extended==4.5.2pip install Werkzeug==2.3.7pip install bcrypt==4.0.1pip install python-dotenv==1.0.03 构建NingFlora应用本章节将详细展示如何利用华为云CodeArts代码智能体，从零开始，一步步地完整构建整个NingFlora应用。这是本实践案例的核心环节，充分体现了AI辅助开发所倡导的“对话即编程”这一创新模式。通过自然语言交互，开发者能够高效地完成需求分析、架构设计、代码生成与优化等一系列开发任务，从而显著提升软件开发的效率与质量。3.1 基于CodeArts代码智能体的辅助开发实践在本项目的开发过程中，我并没有完全依赖AI来生成所有代码，而是将华为云码道（CodeArts）代码智能体定位为一个高效的开发辅助工具。它主要帮助我完成诸如需求梳理、技术选型对比、样板代码生成等重复性和基础性的工作，从而让我能够从这些繁琐事务中解放出来。而整个开发流程中最为核心的部分，包括系统整体的架构设计、复杂业务逻辑的实现、以及开发过程中遇到的各类疑难问题的攻关与解决，均由我自己主导并亲手完成。这种人与AI协作的模式，充分发挥了各自的优势，实现了效率与质量的平衡。3.1.1 第一阶段：需求分析与功能梳理我的工作：在项目启动之初，我首先对“智能花店管理系统”这个课题进行了深入且细致的需求分析。通过梳理业务流程和用户场景，我明确了系统需要支持的四大核心角色，即管理员、会员、普通顾客以及店家，并规划了与之对应的五大核心功能模块，包括会员管理、商品管理、购物车、订单结算以及畅销鲜花统计。在所有这些功能模块中，最具挑战性和复杂性的部分，无疑是四级会员体系的设计与实现。这四级会员体系需要清晰地划分黄金会员、白金会员、普通会员以及普通顾客，并为每个等级设定不同的鲜花购买折扣率。更关键的是，这套会员等级及其对应的折扣逻辑，必须能够在购物车预览商品价格、订单最终计算金额等多个业务环节中实时、准确地生效，确保整个购买流程的连贯性与数据一致性。CodeArts辅助：我将自己整理好的需求要点输入CodeArts代码智能体，让它帮我生成一份结构化的需求规格文档（spec.md）。我的原始输入内容涵盖了系统的核心功能与技术要求，具体如下：1. 商品管理：实现鲜花的分类管理，支持鲜花类别的创建、编辑与查询；同时实现鲜花商品的上架与下架管理，确保商品信息能够灵活更新。2. 会员管理：系统需要建立会员体系，将会员划分为黄金会员、白金会员、普通会员以及普通顾客四个等级。不同等级的会员在购买鲜花时，需应用不同的折扣率。3. 购物流程：会员需要登录系统后方可使用购物功能。会员可以浏览鲜花，将选中的鲜花商品加入购物车，并能够在购物车页面中对已选商品进行二次选择（如取消选择）以及修改购买数量，最后完成付款结算。4. 数据统计：店家用户需要具备数据统计能力，能够随时查看并统计出畅销的鲜花商品，以便进行销售分析与库存调整。5. 技术栈：明确要求使用Python语言完成整个项目的开发，具体采用Flask框架来构建这个名为“NingFlora”的智能花店管理系统。基于以上这些清晰且有条理的需求要点描述，我期望CodeArts代码智能体能够将其转化为一份格式规范、逻辑清晰、内容完整的技术需求文档，为后续的系统设计与编码工作提供明确的指导和依据。产出与审核：CodeArts生成了初版需求文档，我对其进行了仔细审核和补充。例如，我额外增加了“登录失败锁定机制”这一安全需求（连续5次密码错误锁定30分钟），以及“库存并发扣减”的数据库事务保护需求。这些安全性设计是我在课堂上学到的理论知识在实践中的具体应用。3.1.2 第二阶段：技术架构设计我的工作：技术选型和架构设计是整个项目的核心，这部分工作由我主导完成。我综合考虑了项目规模、学习成本和演示效果，最终确定采用 Flask + SQLite + Bootstrap + JWT 的技术栈：Flask：轻量级Python Web框架，适合中小型项目，学习曲线平缓；SQLite：零配置的嵌入式数据库，适合开发和演示阶段，无需单独安装数据库服务；Bootstrap：成熟的前端UI框架，能快速构建美观的管理界面；JWT（JSON Web Token）：无状态的认证方案，适合前后端分离架构，也是我上学期《网络安全》课程的实践延伸。在架构分层上，我参考了经典的MVC模式，设计了五层架构：路由层（Routes）→ 业务逻辑层（Services）→ 数据模型层（Models）→ 中间件层（Middleware）→ 工具层（Utils）。这样的分层设计让代码职责清晰，便于后期维护和扩展。CodeArts辅助：我将自己的技术选型思路和架构分层方案输入CodeArts，让它帮我生成了技术设计文档（design.md）。我的指令是：进入下一阶段：实现方案创建CodeArts将我口头描述的技术方案整理成了规范的设计文档，并自动绘制了系统架构图和数据模型关系图。这为我后续的开发提供了清晰的蓝图，也方便我向老师和同学展示项目的整体设计思路。3.1.3 第三阶段：编码实现这是工作量最大、耗时最长的阶段，也是“人机协作”模式体现得最为紧密和高效的阶段。我采用的策略非常明确：将涉及核心业务逻辑、复杂算法和关键数据处理的代码部分，由我自己亲手编写，以确保其准确性、健壮性和可维护性；而对于那些重复性高、模式固定、结构简单的样板代码，则交给AI来快速生成，以此大幅提升开发效率。我亲自完成的核心代码主要包括以下几个方面：用户模型的折扣率计算方法（models/user.py）：这是整个会员体系的核心。我设计了一个 get_discount_rate() 方法，通过字典映射将会员等级转换为对应折扣率。这个设计灵感来源于《Python程序设计》课程中学到的策略模式，但我在课堂上只理解了概念，这次亲手实现让我真正掌握了它的精髓。订单结算的事务处理逻辑（services/order_service.py）：这是整个项目中最复杂的业务逻辑。我需要确保“创建订单→扣减库存→清空购物车”这三个操作要么全部成功，要么全部回滚。我使用了SQLAlchemy的 db.session 事务管理机制，并设置了 try-except 异常捕获来保证数据一致性。这个设计直接关系到我上学期《数据库原理》课程中学到的ACID原则的实际应用。JWT认证中间件的编写（middleware/auth.py）：虽然Flask-JWT-Extended提供了现成的装饰器，但我自己编写了一个认证中间件来统一处理Token验证和用户身份注入。这样所有受保护的路由只需要一个装饰器即可完成认证，避免了代码重复。畅销统计的聚合查询（services/stats_service.py）：这部分用到了SQLAlchemy的 func.sum() 聚合函数和 group_by 分组操作，需要深入理解ORM框架的查询语法。我花了不少时间调试SQL语句和ORM表达式的转换，最终实现了按时间范围（今日/本周/本月）筛选并生成Top N排行榜的功能。CodeArts辅助完成的工作：在完成核心逻辑后，我将项目的骨架和接口定义告诉CodeArts，让它帮我生成一些重复性的样板代码：路由蓝图注册代码：5个路由文件的蓝图初始化和注册逻辑；前端模板的HTML结构：基础模板和首页的HTML骨架、表单结构；种子数据脚本：创建测试用的分类、商品和不同等级会员的数据；配置文件模板：数据库连接字符串、JWT密钥等配置项。我的指令是：进入下一阶段：编码任务规划CodeArts生成了详细的编码任务清单（tasks.md），我根据自己对代码质量的把控，选择了其中70%左右的任务让AI辅助完成，剩余30%的核心任务由我手动编写和调试。3.1.4 人机协作的体会与反思这次开发经历让我深刻体会到，AI辅助编程工具并不是“代码生成器”那么简单。它的价值在于：减少重复劳动：让我从样板代码中解放出来，专注于业务逻辑的思考和设计；提供参考方案：当我遇到技术选型犹豫时，它能快速给出多种方案对比；规范化输出：自动生成的需求文档和设计文档格式规范，方便团队沟通和项目归档。但同时我也认识到，AI生成的代码不能直接拿来用。它有时会生成过时的API调用、不安全的配置，甚至逻辑错误。开发者必须保持批判性思维，对AI的输出进行审核、测试和优化。这也印证了老师在课堂上常说的那句话：“工具永远替代不了思考，理解底层原理才能在技术变革中立足。”3.2 部署项目代码3.2.1 项目结构说明NingFlora/├── app.py                  # 应用主入口，注册蓝图与配置├── requirements.txt        # 项目依赖清单├── config/│   ├── __init__.py│   └── database.py         # 数据库配置├── models/                 # 数据模型层（ORM）│   ├── user.py           # 用户模型（含四级会员与锁定机制）│   ├── product.py        # 商品模型│   ├── cart.py           # 购物车模型│   └── order.py          # 订单模型├── services/              # 业务逻辑层│   ├── user_service.py   # 登录、注册、折扣计算逻辑│   ├── order_service.py  # 订单创建、库存扣减、事务处理│   └── stats_service.py  # 畅销统计、时间筛选逻辑├── routes/                # 路由控制层（API接口）│   ├── auth_routes.py    # 认证相关接口│   └── admin_routes.py   # 管理后台接口├── middleware/            # 中间件│   └── auth.py           # JWT认证拦截├── templates/             # 前端模板└── scripts/               # 运维脚本├── init_db.py        # 数据库初始化脚本├── seed_data.py      # 测试种子数据脚本└── test_app.py       # 自动化测试脚本3.2.2 关键代码讲解3.2.2.1 用户模型与折扣策略设计目标： 实现灵活的四级会员体系，折扣规则与用户对象内聚，避免业务逻辑分散。实现位置： models/user.py核心设计思路：用户模型是整个会员体系的基石。我放弃了将折扣规则写成独立工具函数的方案，而是采用面向对象的封装思想，将折扣计算行为内聚在User模型内部。这样做的核心理由是：折扣规则不是孤立的——一个用户是什么等级，就应该自动拥有对应的折扣。如果规则与对象分离，未来会员等级从四级扩展到五级时，可能需要修改分散在多个文件中的代码，维护成本极高。通过将折扣逻辑封装在User类中，不仅保证了数据与行为的紧密结合，也使得代码结构更加清晰，职责更加明确。当需要调整折扣策略或增加新的会员等级时，只需在User模型内部进行修改，极大地降低了代码的耦合度，提升了系统的可维护性和可扩展性。在此基础上，我进一步定义了`get_discount_rate()`成员方法，该方法会根据实例存储的`level`字段自动返回对应的折扣系数：普通顾客保持原价返回`1.0`，普通会员返回`0.95`，黄金会员返回`0.85`，白金会员返回`0.75`。当整个系统的任意位置需要计算用户的实际支付价格时，只需要调用`user.get_discount_rate() * price`即可得到最终结果，不需要额外判断用户等级，也不需要在各个业务模块重复编写折扣规则逻辑。当后续需要调整会员等级、修改折扣系数或者增加新的会员等级时，只需要修改User模型内部的判断逻辑与返回值，不需要对项目其他位置的代码进行大范围改动，完美符合开闭原则的设计思想，也让整个系统的可扩展性得到了有效保障。接下来我再对商品分类与上下架管理部分的核心设计进行说明。关键代码片段：class User(db.Model):__tablename__ = 'users'# 会员等级字段，默认为普通顾客member_level = db.Column(db.String(20), default='普通顾客')def get_discount_rate(self):"""根据会员等级返回对应折扣率映射关系：普通顾客 -> 0%  (原价)普通会员 -> 5%  (95折)白金会员 -> 10% (9折)黄金会员 -> 20% (8折)"""discount_rates = {'普通顾客': 0.0,'普通会员': 0.05,'白金会员': 0.10,'黄金会员': 0.20}return discount_rates.get(self.member_level, 0.0)设计亮点：单一职责原则：折扣率的映射关系和计算逻辑完全封装在User模型中，外部调用者只需user.get_discount_rate()，无需关心内部实现；易于扩展：若未来需要新增“钻石会员”等级，只需在字典中添加一行映射即可，无需修改购物车、订单等其他模块的代码；容错处理：使用.get()方法并设置默认值0.0，即使出现未识别的会员等级，系统也能正常降级为原价，不会因异常而崩溃。3.2.2.2 登录安全与防暴力破解机制设计目标： 在保障正常用户登录体验的前提下，有效抵御针对登录接口的暴力破解攻击。实现位置： services/user_service.py核心设计思路：在实习期间参与安全演练时，我亲眼目睹了一个没有登录保护的测试系统在15分钟内被字典攻击攻破的全过程。那次经历让我深刻认识到：登录接口是系统的第一道防线，必须设计有效的安全机制。我采用了“惩罚递增”策略——正常用户输错两三次密码是常事，系统给予友好提示；但连续输错5次，说明极有可能是攻击行为，系统自动锁定账户30分钟。这种设计让攻击者的时间成本呈指数级上升，而正常用户几乎无感。具体实现中，我在`UserService`类中设计了`failed_attempts`和`lock_until`两个字段分别记录连续密码错误次数和账户锁定的结束时间：用户每次尝试登录时，首先判断当前时间是否早于`lock_until`，如果是则直接返回账户已锁定的提示；如果登录时密码校验错误，则将`failed_attempts`加1，并判断连续失败次数是否达到阈值。当连续输错次数达到5次后，就将`lock_until`设置为`当前时间+30分钟`，只有等锁定时间结束后，才会自动重置`failed_attempts`，允许用户继续尝试登录；如果登录验证成功，则直接将`failed_attempts`重置为0，不影响用户后续正常登录。这套逻辑完全内置在用户登录服务中，不需要额外引入第三方安全组件，实现简单，逻辑清晰，在开发成本几乎可以忽略的前提下，有效提升了登录接口的安全防护能力，也不会给正常使用的用户带来困扰。关键代码片段：def login_user(username, password):"""用户登录服务，包含完整的防暴力破解机制"""# 1. 查询用户（不存在时返回模糊错误，防止用户名枚举攻击）user = User.query.filter_by(username=username).first()if not user:return None, '用户名或密码错误'# 2. 检查账户是否处于锁定期if user.is_locked and user.lock_until:if datetime.utcnow() < user.lock_until:remaining_seconds = (user.lock_until - datetime.utcnow()).secondsremaining_minutes = remaining_seconds // 60 + 1return None, f'账户已锁定，请{remaining_minutes}分钟后再尝试'else:# 锁定期已过，自动解除锁定user.is_locked = Falseuser.login_fail_count = 0# 3. 验证密码if not user.check_password(password):user.login_fail_count += 1# 连续失败5次，触发锁定if user.login_fail_count >= 5:user.is_locked = Trueuser.lock_until = datetime.utcnow() + timedelta(minutes=30)db.session.commit()return None, '登录失败次数过多，账户已锁定30分钟'# 未达阈值，提示剩余机会db.session.commit()remaining = 5 - user.login_fail_countreturn None, f'用户名或密码错误，还剩{remaining}次机会'# 4. 登录成功，重置所有安全计数器user.login_fail_count = 0user.is_locked = Falseuser.lock_until = Noneuser.last_login = datetime.utcnow()db.session.commit()# 5. 生成JWT令牌并返回access_token = create_access_token(identity=user.id)return {'access_token': access_token,'user': user.to_dict()}, None 安全机制实现方式防护目标密码加密存储bcrypt哈希 + 自动盐值防止数据库泄露时密码被破解登录失败锁定5次失败后锁定30分钟阻止自动化暴力破解脚本错误信息模糊化统一返回“用户名或密码错误”防止攻击者枚举有效用户名剩余次数提示告知用户还剩几次机会避免正常用户因遗忘密码被锁锁定到期自动恢复到期后下次登录自动解锁无需管理员手动干预3.2.2.3 事务化订单结算与库存并发控制设计目标： 确保订单创建过程中“订单生成→库存扣减→购物车清空”三个操作的原子性，杜绝高并发场景下的库存超卖问题。为了实现这个设计目标，我引入了数据库的事务机制，将三个操作包裹在同一个数据库事务中。只有当三个操作全部执行成功时，才会提交事务完成整个流程；只要任意一个环节出现异常，就会触发事务回滚，所有已执行的操作都会被撤销，保证数据不会出现不一致的情况。具体代码实现上，我使用项目集成的`SQLAlchemy`事务管理机制，在视图函数中通过`db.session.begin_nested()`开启事务，依次执行创建订单记录、扣减对应商品库存、删除购物车中对应商品三个核心步骤。如果执行过程中捕获到任何异常，就调用`db.session.rollback()`回滚事务，并返回订单创建失败的提示；如果所有步骤都执行完成没有抛出异常，再调用`db.session.commit()`提交事务，将修改永久写入数据库。解决了数据原子性问题后，我还针对库存扣减环节做了进一步优化，避免高并发场景下多个请求同时读取库存数值导致的超卖。我将原本“读取库存→判断库存是否充足→扣减库存”的三步逻辑，改写为带条件的单条SQL更新语句：`UPDATE goods SET stock = stock - 1 WHERE id = :goods_id AND stock >= 1`。这条语句会由数据库本身保证执行的原子性，只有当库存满足条件时才会完成扣减，即使大量并发请求同时到达，数据库也会依次执行更新操作，不会出现库存变成负数的超卖问题，同时还减少了一次数据库查询操作，提升了执行效率。实现位置： services/order_service.py核心设计思路：库存超卖是一个经典的并发控制问题。假设红玫瑰只剩1束，用户A和用户B几乎同时点击下单。如果没有保护机制，两个请求可能同时读到“库存=1”，都判定充足，最终生成两个有效订单——实际只有1束花，却卖出了2份。解决这个问题，我采用了数据库事务机制。事务具有ACID特性中的原子性（Atomicity）和隔离性（Isolation），能够保证多个操作要么全部成功、要么全部回滚。此外，我在扣减库存时使用了with_for_update()行级锁，确保同一行数据在同一时刻只能被一个事务修改，从数据库层面彻底杜绝超卖。这里的行级锁会在读取库存数据时就对该商品对应的记录加锁，其他事务想要修改这条数据，必须等待当前事务提交或者回滚之后才能获取锁，这样就避免了两个事务同时读取、修改同一条库存记录的并发冲突。对应的核心代码逻辑如下：def create_order(self, user_id, goods_id):    # 开启事务    with db.session.begin_nested():        # 查询商品并加行级锁        goods = Goods.query.filter_by(id=goods_id).with_for_update().first()        if goods is None or goods.stock < 1:            raise Exception("商品库存不足")        # 扣减库存        goods.stock -= 1        # 生成订单记录        order = Order(user_id=user_id, goods_id=goods_id, amount=goods.price)db. session.add(order)    # 提交事务并释放行级锁dc. session.commit()    return order和之前提到的条件更新方案相比，这种基于事务加行级锁的方案，更适合需要读取库存信息到业务层做额外逻辑处理、再进行扣减的场景，通用性更强，可以适配库存扣减前更多样的业务校验规则，在保证并发安全的同时，也保留了业务扩展的灵活性。关键代码片段：def create_order(user_id):"""创建订单，使用事务和行级锁保证数据一致性"""# 1. 校验前置条件user = User.query.get(user_id)cart_items = CartItem.query.filter_by(user_id=user_id).all()if not user:return None, '用户不存在'if not cart_items:return None, '购物车为空'# 2. 库存预校验（事务外，避免锁定后才发现库存不足）for item in cart_items:if item.product.stock < item.quantity:return None, f'商品 [{item.product.name}] 库存不足'# 3. 计算折扣后金额discount_rate = user.get_discount_rate()original_amount = sum(item.product.price * item.quantity for item in cart_items)final_amount = original_amount * (1 - discount_rate)try:# 4. 开启事务处理with db.session.begin():# 4.1 逐项锁定库存并扣减（使用行级锁防止并发）for item in cart_items:product = Product.query.with_for_update().get(item.product_id)if product.stock < item.quantity:raise ValueError(f'商品 [{product.name}] 库存不足')product.stock -= item.quantity# 4.2 创建订单对象order = Order(order_no=Order.generate_order_no(),user_id=user_id,original_amount=original_amount,discount_amount=original_amount - final_amount,final_amount=final_amount,status='待支付')db.session.add(order)db.session.flush()  # 获取订单ID# 4.3 创建订单明细for item in cart_items:order_item = OrderItem(order_id=order.id,product_id=item.product_id,product_name=item.product.name,unit_price=item.product.price,quantity=item.quantity,subtotal=item.product.price * item.quantity)db.session.add(order_item)# 4.4 清空购物车CartItem.query.filter_by(user_id=user_id).delete()# 事务自动提交db.session.commit()return order, Noneexcept Exception as e:# 任何异常都会触发事务回滚db.session.rollback()return None, '订单创建失败'并发安全保障机制：保障层面实现技术作用说明原子性保证数据库事务（Transaction）订单、明细、库存、购物车四者操作同生共死隔离性保证行级锁（with_for_update()）同一商品库存行在同一时刻只能被一个事务修改预校验机制事务外的库存检查快速失败，避免无效锁定资源异常回滚try-except + rollback任何一步出错，整个操作回退到初始状态事务处理流程说明：整个订单创建过程严格遵循数据库事务的原子性原则。库存预校验在事务外完成，目的是快速判断库存是否充足，避免锁定资源后发现不足还要回滚。进入事务后，首先用with_for_update()对每条商品记录加行级锁——这一步是关键，它确保了同一时刻只有一个请求能修改同一商品的库存。随后依次完成订单创建、明细生成、库存扣减和购物车清空。如果在事务执行过程中发生任何异常（如库存被其他事务抢先扣完），系统会立即回滚所有操作，数据库恢复到事务开始前的状态。这种分层处理的设计兼顾了性能和安全两个维度：事务外预校验可以直接过滤掉绝大多数库存不足的请求，避免给数据库带来不必要的锁竞争和回滚开销，提升系统在高并发场景下的吞吐量；而行级锁的引入，则从数据库层面彻底隔离了同一商品的并发修改请求，从根源上杜绝了多个请求同时读取相同库存值导致的超卖问题。对比无锁的乐观锁方案，这种基于行级锁的悲观锁方案实现逻辑更简单，不需要额外新增版本号字段，也不会出现大量请求并发下单时频繁重试失败的问题，适配我们这个项目中小型电商的业务场景，开发维护成本更低，稳定性也更有保障。3.2.2.4 购物车折扣自动计算设计目标： 用户在查看购物车时，能够实时看到根据自身会员等级计算后的折扣价格，提升购物体验的透明度。实现位置： services/cart_service.py核心设计思路：购物车模块的核心职责除了管理商品列表外，还需要向用户清晰展示价格构成——原价多少、会员折扣多少、最终实付多少。我在get_cart()方法中统一处理了这个逻辑：先获取用户对象，调用其get_discount_rate()方法获取折扣率，再遍历购物车中的每一项商品，分别计算原价小计和折扣后价格。这种设计的优势在于，折扣计算逻辑完全封装在User模型中，购物车服务不需要知道四级会员的具体折扣映射——它只需要知道“用户有一个折扣率”这个抽象概念即可。这正是面向对象设计中“依赖抽象而非具体”原则的体现。如果后续需要调整会员等级的折扣规则，只需要修改User模型中get_discount_rate()方法的内部实现即可，不需要改动购物车服务的代码，降低了不同模块之间的耦合度，也更符合开闭原则。为了避免前端多次调用带来不必要的重复计算，折扣计算结果会随购物车商品列表一起返回前端，前端只需要直接渲染就能展示给用户，不需要再做额外计算，既降低了前端的计算压力，也保证了价格展示的一致性。针对部分特殊不参与会员折扣的活动商品，我也在计算逻辑中添加了判断分支：如果商品标记了不参与会员折扣，将直接按商品原价计算小计，不会套用用户的会员折扣率，灵活适配了运营活动的特殊规则。3.2.2.5 JWT认证与权限控制设计目标： 实现无状态的用户认证，并支持普通用户和管理员的权限分级控制。实现位置： middleware/auth.py核心设计思路：JWT（JSON Web Token）是一种无状态的认证方案。用户登录成功后，服务端生成一个包含用户ID的令牌返回给客户端，客户端在后续请求的HTTP头中携带该令牌，服务端通过验证令牌的签名来判断请求是否合法。我封装了两个装饰器来简化权限控制：@jwt_required用于验证用户是否已登录，适用于购物车、下单等需要登录态的接口；@admin_required在此基础上进一步检查用户是否具有管理员身份，适用于商品上下架、畅销统计等管理后台接口。这种分层设计使得每个路由的权限需求一目了然，无需在每个接口中重复编写认证逻辑。装饰器本身只做权限校验，拿到合法的用户ID后会直接传递给路由函数，不会侵入业务逻辑的实现，代码结构非常清晰。为了适配项目的部署需求，我还在配置文件中开放了JWT过期时间和签名密钥两个可配置项：生产环境可以调整过期时长提升安全性，同时可以通过更换签名密钥刷新所有用户的登录态，开发环境则可以设置较长的过期时间避免反复登录调试，适配性更强。相比基于Session的服务端存储认证方案，JWT不需要服务端存储任何认证信息，也不需要依赖Redis共享Session解决分布式场景下的认证问题，更符合当前项目单体云部署的架构设计，实现逻辑也更轻量化。以上五个核心技术点构成了NingFlora系统的骨干框架。用户模型封装了会员等级与折扣规则，登录服务实现了防暴力破解的安全机制，订单服务通过事务与行级锁保证了高并发场景下的数据一致性，购物车服务提供了透明的折扣价格预览，JWT中间件则支撑了整个系统的认证与鉴权体系。这些模块之间职责清晰、耦合度低，共同构建了一个功能完整、安全可靠的智能花店管理系统。接下来我们对项目启动文件做简单说明，项目入口app.py中，我只做了三件核心配置：一是完成Flask应用对象的初始化，二是注册各个业务模块的蓝图路由，三是配置JWT相关参数并注册自定义装饰器。所有业务逻辑都封装在独立的模块文件中，启动文件仅负责统筹配置，结构非常清晰。如果你需要本地运行项目，可以直接执行pip install -r requirements.txt安装所有依赖包，修改配置文件中的数据库连接信息，完成数据库初始化后，执行python app.py即可启动项目。3.2.3 运行调试按照以下顺序执行脚本，即可完成数据库初始化、体验数据生成和功能测试。cd ~/NingFlora# 1. 初始化数据库，创建所有表和管理员账户python scripts/init_db.py# 预期输出：管理员账户创建成功！用户名: admin, 密码: admin123# 2. 创建种子数据，用于功能演示python scripts/seed_data.py# 预期输出：创建了玫瑰、百合等分类，以及gold_user等不同等级的测试会员# 3. 运行自动化测试，验证核心逻辑python scripts/test_app.py# 预期输出：一系列的“✓”，验证数据库、API接口和折扣计算均正常# 4. 启动Flask开发服务器python app.py打开浏览器访问 http://localhost:5000，即可看到API返回的欢迎信息。随后可使用 curl 或 Postman 对各类接口进行测试。4 释放资源完成案例体验后，请及时停止并释放云资源，以免产生不必要的费用。4.1 删除云开发环境登录华为开发者空间。点击菜单 开发平台 > 云开发环境 > 容器。在环境中找到本实验创建的实例，点击右侧的 删除 按钮，并按对话框指引完成删除。5 扩展资料说明Flask官方文档：深入理解Flask框架的各类用法。 https://flask.palletsprojects.com/SQLAlchemy ORM教程：学习数据库交互与高级查询技巧。 https://docs.sqlalchemy.org/Flask-JWT-Extended：掌握JWT认证与鉴权的最佳实践。 https://flask-jwt-extended.readthedocs.io/华为云开发者社区：发现更多云技术与AI开发案例。 cid:link_06 核心技术难点与解决思路在之前一段实习的两个月，我参与的是一个智能客服对话系统的迭代开发。导师给我上的第一课，不是教我用哪个框架，而是让我花整整一周时间去读系统的“纠错日志”——所有线上bad case的完整记录。那一周，我看了上千条用户反馈，发现真正让系统出问题的，往往不是模型本身，而是一些边界情况没有处理好：用户连续输入空消息怎么办？意图置信度刚好卡在阈值边界怎么办？并发请求导致状态错乱怎么办？这段经历让我深刻意识到：代码能跑通只是及格线，能处理好各种边界条件和异常情况，才是工程化的分水岭。带着这种思维回归到NingFlora项目，我在设计每个功能模块时，都会刻意追问自己：“如果出现XX情况，系统会怎样？”正是这种追问，让我识别出了以下几个核心技术难点，并逐一设计了解决方案。第一个难点便是前文提到的灵活四级会员折扣体系设计：最初我打算把折扣规则直接写死在购物车计算逻辑里，转念想到如果后续运营调整会员折扣，改动代码不仅繁琐，还可能影响原有业务逻辑的稳定性。因此结合之前做智能客服积累的边界设计经验，我将折扣规则完全封装在用户模型内部，购物车模块只需要调用方法获取折扣率，不需要关心具体的等级映射规则，后续调整规则时仅需要修改用户模型的方法实现，不影响其他模块正常运行，兼顾了灵活性和稳定性。其次是高并发场景下的库存超卖风险。电商商品做促销活动时，可能会有多个用户同时下单购买同一件商品，如果不加处理，很可能出现商品实际库存只有10件，最终却卖出了15件的问题。针对这个问题，我采用了数据库乐观锁方案：在商品表中增加一个版本号字段，更新库存前先检查版本号是否和查询时一致，如果不一致说明已经有其他请求修改了库存，直接回滚当前事务并重试，既避免了超卖，也不需要占用过多数据库锁资源，适配项目当前的访问量级。第三个核心难点是用户登录接口的安全防护，防止攻击者通过暴力猜解批量撞库获取用户账号权限。我设计了双重防护机制：一是基于IP的频次限制，单个IP五分钟内尝试登录失败超过XX次，就会被暂时封禁XX分钟，无法继续发起登录请求；二是针对单个账号的锁定机制，同一账号连续XX次登录失败，会被锁定XX小时，大大增加暴力破解的时间成本，有效降低了账号被攻破的风险。最后一个难点是基于时间维度的商品畅销统计，需要按日、周、月维度统计销量排序，生成畅销商品榜单。直接对订单表实时分组统计不仅性能差，还会影响线上订单的正常处理。对此我设计了定时任务：每日凌晨自动统计前一日、最近一周、最近一月的商品销量，将结果缓存到Redis中，前端请求畅销榜单时直接读取缓存即可，既降低了数据库的压力，也提升了接口的响应速度。6.1 灵活的四级会员与折扣体系设计问题溯源这个问题的本质是“规则的内聚与复用”。在早期方案中，我一度想把折扣规则写成一个独立的工具函数，放在utils目录下，所有需要计算折扣的地方都调用它。但转念一想，折扣规则不是孤立的，它和用户的会员等级是强绑定的——一个用户是什么等级，就应该自动拥有什么折扣。如果把规则和对象分离，哪天会员等级从四级变成五级，我可能得改好几处代码。这种“数据和行为分离导致维护困难”的情况，我在实习时也遇到过。当时智能客服系统有一个“对话上下文管理”模块，早期实现是把用户的历史消息存在一个全局字典里，和用户对象完全脱钩。后来系统要支持多轮对话中断后恢复，整个上下文管理逻辑差点推倒重来。这次教训让我在NingFlora项目中有意识地采用面向对象的方式来组织代码。针对NingFlora的会员折扣场景，最符合高内聚原则的设计，就是把折扣规则直接封装进用户模型内部：用户对象本身存储了会员等级信息，同时提供一个`get_discount`公共方法，对外只返回最终的折扣系数，不需要业务模块关心规则的具体计算逻辑。这样一来，无论后续是调整各等级的折扣比例，还是新增更高等级的会员权益，都只需要修改用户模型中`get_discount`方法的实现，不需要改动购物车结算、下单计算等所有调用该方法的业务代码，既减少了改动范围，也避免了改一处漏一处的问题。购物车模块在计算商品总价时，只需要调用当前登录用户对象的`get_discount`方法拿到折扣系数，直接乘以商品总价就能得到折后价格，一行代码就能完成处理，逻辑非常简洁。最终实现效果上，该设计完全满足需求：普通用户不享受折扣，黄金会员享受XX折扣，白金会员享受XX折扣，钻石会员享受XX折扣，完全符合设计要求，同时规则可灵活调整，不会对系统整体架构产生影响。解决思路我决定将折扣率计算直接封装在User模型内部。这样做的好处是：折扣规则作为用户对象的一个“行为”，与会员等级这个“属性”天然绑定在一起。外部调用者不需要关心折扣怎么算的，只需要调用 user.get_discount_rate() 即可。class User(db.Model):__tablename__ = 'users'# ... 其他字段 ...member_level = db.Column(db.String(20), default='普通顾客')# 等级与折扣率的映射关系# 使用类变量定义，方便全局修改DISCOUNT_MAP = {'普通顾客': 0.00,   # 原价'普通会员': 0.05,   # 95折'白金会员': 0.10,   # 9折'黄金会员': 0.20,   # 8折}def get_discount_rate(self):"""获取当前用户的折扣率，未被识别的等级默认为0"""return self.DISCOUNT_MAP.get(self.member_level, 0.00)这个设计还有一个隐含的好处：如果将来要支持“会员日活动期间全场额外再享95折”，我只需要在get_discount_rate()方法内部增加日期判断逻辑，所有调用方零改动即可适配。这种对扩展开放、对修改封闭的设计原则，是我在实习期间阅读开源项目源码时反复看到的最佳实践。整个映射关系通过类变量`DISCOUNT_MAP`集中定义，后续如果要调整各级会员的折扣比例，也只需要修改这个映射字典中的数值即可，不需要去各个业务代码中查找修改，大大降低了维护成本。即使后续真的需要调整会员等级数量，比如将四级扩展为五级，也只需要在映射字典中新增一行等级与折扣的对应关系，再修改用户等级字段的可选值范围即可，改动范围非常小，不容易影响其他业务逻辑。对比一开始把折扣计算分散到各个业务模块的思路，这种封装设计不仅让代码结构更清晰，也让整个折扣体系的可维护性提升了一个量级——出现需求变更时，开发只需要聚焦修改一处代码即可，测试也只需要针对修改部分做回归验证，既提升了开发效率，也降低了线上出问题的风险。6.2 高并发下的库存超卖风险问题溯源库存超卖是一个经典的并发控制问题。场景是这样的：假设红玫瑰只剩最后1束，用户A和用户B几乎同时点击了下单按钮。如果系统不加任何保护，两个请求可能同时读到“库存=1”，然后都判定“库存充足”，最终各自生成一个订单。结果就是：只有1束花，卖出了2份。这个问题我在实习时也有切身体会。我们的智能客服系统有一个“人工转接”队列，高峰期时多个用户同时请求转接，如果队列计数器没有做原子操作，就可能出现“明明只有3个空闲坐席，却分配出去4个会话”的情况。当时是导师带着我用Redis的DECR原子操作解决了这个问题。对于NingFlora项目，我没有引入Redis这样的外部组件（考虑到演示项目的轻量性），而是选择依赖数据库本身的事务机制。具体来说，我把订单生成、库存扣减、购物车清空这三个核心操作放在同一个数据库事务中，确保三者要么全部成功，要么全部失败回滚，从流程上避免了“订单生成了但库存没扣减”或者“库存扣减了订单却没生成”这类数据不一致问题。但事务机制只能解决操作失败后的回滚问题，没办法解决高并发下两个请求同时读取库存的竞态条件。针对这个问题，我对库存扣减语句做了针对性优化：把原本“读取库存数值-判断库存是否充足-扣减库存”的拆分操作，合并成了一条带条件判断的原子更新语句：`UPDATE product SET stock = stock - :buy_num WHERE id = :product_id AND stock >= :buy_num`。这条语句会由数据库保证执行的原子性，同一时间只会有一个请求完成更新，当库存不足以满足购买量时，更新操作不会生效，我们只需要通过返回的影响行数判断操作是否成功，就能直接规避超卖问题——如果更新后影响行数为0，说明库存不足，直接回滚事务并返回“库存不足”的提示即可。这个方案不需要额外引入第三方组件，完全基于现有数据库能力解决问题，对于NingFlora这类演示性质的中小项目来说，既满足了功能需求，又保持了项目结构的轻量简洁，代码实现难度低，稳定性也足够。解决思路核心思路是：将“库存校验 → 订单创建 → 库存扣减 → 购物车清空”这四个操作封装在同一个数据库事务中。数据库的事务具有ACID特性中的原子性（Atomicity） 和隔离性（Isolation），能够保证这些操作要么全部成功，要么全部回滚。但这还不够。如果两个事务同时读取库存为1，MySQL的默认隔离级别（Repeatable Read）可能无法阻止两者都通过校验。所以我额外做了一层保护：在扣减库存的SQL中加上行级锁，确保同一行数据在同一时刻只能被一个事务修改。也就是说，在前文那条带条件判断的扣减语句执行过程中，数据库会自动对目标商品行加排他行锁，第一个抢到锁的事务完成更新后，后续事务才会拿到最新的库存数据。如果此时库存已经不足，扣减操作就会直接不生效，不需要再额外用SELECT ... FOR XLOCK这类语句手动加锁，既简化了SQL逻辑，也达到了同样的并发控制效果。这个方案的另一个优势是不需要对现有项目结构做额外改造——整个事务和锁的逻辑都集成在库存扣减的代码块中，不需要引入分布式锁服务，也不需要额外搭建缓存集群，完全适配项目当前的轻量定位，对于访问量不算极高的电商演示项目来说，完全可以满足防超卖的需求，开发维护成本也极低。当然，如果后续项目规模扩大、访问量提升，也可以平滑切换到用Redis做分布式锁的方案，现有的业务调用逻辑不需要做大的改动，拓展性也得到了保障。def create_order(user_id):"""创建订单，使用事务和行级锁防止超卖"""try:# 开启数据库事务with db.session.begin():# 获取用户信息user = User.query.get(user_id)if not user:raise ValueError('用户不存在')# 查询购物车项cart_items = CartItem.query.filter_by(user_id=user_id).all()if not cart_items:raise ValueError('购物车为空')# 逐项校验并锁定库存for item in cart_items:# 使用 with_for_update() 加行级锁# 这行SQL相当于: SELECT ... FOR UPDATEproduct = Product.query.with_for_update().get(item.product_id)if product.stock < item.quantity:raise ValueError(f'商品 [{product.name}] 库存不足')# 扣减库存product.stock -= item.quantity# 计算折扣后金额discount_rate = user.get_discount_rate()original_amount = sum(item.product.price * item.quantity for item in cart_items)discount_amount = original_amount * discount_ratefinal_amount = original_amount - discount_amount# 创建订单和订单明细order = Order(order_no=Order.generate_order_no(),user_id=user_id,original_amount=original_amount,discount_amount=discount_amount,final_amount=final_amount,status='待支付')db.session.add(order)db.session.flush()  # 刷新以获取order.idfor item in cart_items:order_item = OrderItem(order_id=order.id,product_id=item.product_id,product_name=item.product.name,unit_price=item.product.price,quantity=item.quantity,subtotal=item.product.price * item.quantity)db.session.add(order_item)# 清空购物车CartItem.query.filter_by(user_id=user_id).delete()# 事务自动提交db.session.commit()return order, Noneexcept Exception as e:# 任何异常都会触发事务回滚db.session.rollback()return None, str(e)with_for_update() 是SQLAlchemy提供的行级锁机制，对应SQL中的SELECT ... FOR UPDATE。当一个事务对某行数据加了排他锁，其他事务如果要修改同一行数据，必须等待当前事务提交或回滚。这样就从数据库层面保证了“读取库存→判断→扣减”这个过程的串行化，从根本上杜绝了超卖。进一步思考：如果这是真正的生产环境，日订单量达到万级以上，单纯依赖数据库行级锁可能会成为性能瓶颈。在实习时和架构师交流过这个问题，更成熟的方案是引入Redis做库存预扣减，结合消息队列异步下单，最后用数据库做最终一致性校验。但作为课程项目，当前的事务+行锁方案已经足够应对并发场景。这种分层设计的思路其实也给我们做中小型项目做技术选型提供了参考：不需要一开始就追求最前沿、最复杂的架构，只需要根据项目定位选择满足需求、足够可靠的方案，既可以控制开发复杂度，也能避免过度设计带来的资源浪费和维护成本增加。如果后续业务规模增长，当前方案也保留了扩展空间，只需要在现有流程基础上增加Redis预扣减层即可，核心业务逻辑不需要做大的改动。6.3 用户登录的安全防护：防暴力破解问题溯源登录接口是整个系统安全的第一道防线。如果没有防护措施，攻击者可以通过自动化脚本，用常见的密码字典无限尝试登录，直到试出正确密码。我在实习时参与过一次安全演练，红队（攻击方）仅用了15分钟就通过暴力破解攻破了一个没有登录保护的测试系统，这个场景让我对安全防护有了切身体会。传统的做法是加验证码，但过度使用会严重影响用户体验。我更倾向于一种“惩罚递增”的策略：给正常用户无感的体验，让攻击行为变得得不偿失。这种策略的核心逻辑十分清晰：正常用户偶尔输错一两次密码是非常正常的操作，系统只需要给出提示即可，不需要额外限制；但如果同一个账号连续多次输错密码，该账号来自攻击者的概率就会大幅提升，此时系统就要启动递进的惩罚机制，逐步拉高暴力破解的时间成本。具体到这个项目，我设定的规则是：如果连续5次输入密码错误，就自动锁定该账号30分钟，这段时间内即使输入正确密码也无法登录。对于正常用户来说，极少会出现连续输错5次密码的情况，即使真的出现了，等待半小时也不会对正常使用产生严重影响；而对于暴力破解的攻击者来说，每尝试5次就要等待半小时，破解一个中等强度的密码需要花费数月甚至更久的时间，几乎让攻击变得不可行。解决思路我在User模型中设计了三个关键字段：login_fail_count：记录连续登录失败的次数is_locked：账户是否被锁定lock_until：锁定截止时间逻辑如下：连续5次输错密码后，账户自动锁定30分钟。锁定期间即使输入正确密码也无法登录。登录成功后，失败计数器立即归零。这个“惩罚递增”机制会让攻击者的时间成本呈指数级上升——正常用户30秒内试两三次是常事，但攻击者需要花数小时去等30分钟的锁定期。这套实现方案不需要引入额外的第三方安全组件，只需要修改用户实体类和登录验证逻辑即可，开发成本极低，防护效果却十分显著。在实际测试中，我使用XX工具模拟密码字典攻击，原本可以每分钟尝试上百次，在这套机制的限制下，每尝试5次就要等待30分钟，破解一个长度为8位包含大小写字母和数字的密码，理论耗时从原本的几天直接拉长到了数年，暴力破解的可行性几乎被完全消除，同时正常使用系统的用户完全不会受到影响，只有极特殊情况下才会遇到锁定，符合项目预期的安全要求。def login_user(username, password):"""用户登录，带防暴力破解的锁定机制"""user = User.query.filter_by(username=username).first()# 1. 用户不存在，直接返回模糊错误信息#    （不明确告知“用户不存在”，防止攻击者枚举有效用户名）if not user:return None, '用户名或密码错误'# 2. 检查是否在锁定期内if user.is_locked and user.lock_until:if datetime.utcnow() < user.lock_until:remaining_seconds = (user.lock_until - datetime.utcnow()).secondsremaining_minutes = remaining_seconds // 60 + 1  # 向上取整return None, f'账户已锁定，请{remaining_minutes}分钟后再尝试'else:# 锁定期已过，自动解锁user.is_locked = Falseuser.login_fail_count = 0# 3. 验证密码if not user.check_password(password):user.login_fail_count += 1# 连续失败5次，锁定30分钟if user.login_fail_count >= 5:user.is_locked = Trueuser.lock_until = datetime.utcnow() + timedelta(minutes=30)db.session.commit()return None, '登录失败次数过多，账户已锁定30分钟'db.session.commit()remaining_attempts = 5 - user.login_fail_countreturn None, f'用户名或密码错误，还剩{remaining_attempts}次尝试机会'# 4. 登录成功，重置所有计数器user.login_fail_count = 0user.is_locked = Falseuser.lock_until = Noneuser.last_login = datetime.utcnow()db.session.commit()# 5. 生成JWT Tokenaccess_token = create_access_token(identity=user.id)return {'access_token': access_token,'user': user.to_dict()}, None设计细节的考量：错误信息模糊化：不管是“用户不存在”还是“密码错误”，都返回同样的提示。这能防止攻击者用返回信息的差异来枚举系统中存在的用户名。剩余尝试次数提示：给正常用户明确的反馈，避免他们因为忘记密码而反复尝试，最终被锁。锁定到期自动恢复：锁定期过后用户再次登录时，系统自动解除锁定状态，无需管理员手动干预。这种“惩罚递增”的策略，在实习时我们智能客服系统的后台管理登录也采用了类似的设计。安全团队告诉我们，这个简单的机制能阻挡90%以上的自动化攻击，因为它让暴力破解的时间成本变得不可接受。另外还有一个细节是针对IP的限制补充：为了防止攻击者更换用户名逐个爆破，我们额外增加了同一IP短时间内连续登录失败次数的限制，短时间内超过XX次后就会对该IP进行临时访问限制，进一步提升攻击者的攻击门槛。这套组合策略开发量很小，不需要额外引入太多依赖，却实现了远好于单纯加验证码的防护效果，同时对正常用户几乎没有感知，兼顾了安全性和使用体验。6.4 基于时间维度的畅销统计问题溯源“畅销统计”表面上是一个简单的查询功能，但实现起来有不少细节需要处理。店家需要看到“今日畅销Top 10”、“本周畅销Top 10”、“本月畅销Top 10”，这三个时间维度的起止时间需要动态计算。如果这个计算逻辑写死在SQL里，后期的可维护性会很差。如果每次前端请求榜单的时候，都实时对订单表执行分组聚合统计，随着订单数据量不断增长，聚合查询的耗时会越来越长，不仅拖慢了这个接口的响应速度，还会占用大量数据库计算资源，影响下单、查询商品这类核心交易接口的运行效率。同时，电商场景里用户访问畅销榜单的频率很高，远高于更新商品销量的频率，每次访问都做一次全表实时统计，对计算资源也是一种不必要的浪费。梳理清楚这些潜在问题后，我确定了“异步预统计+结果缓存”的实现方案，不再做实时查询。具体来说，我会设置一个定时任务，每天凌晨自动触发执行：分别计算出今日、近7日、近30日三个时间维度内每个商品的销量总和，按照销量降序排序取出Top 10后，把统计结果直接存入提前建好的畅销榜单表，同时把结果同步缓存到Redis里。当用户前端请求畅销榜单时，直接从Redis中读取预先生成好的结果返回即可，不需要实时计算，接口响应速度提升了数十倍，也完全不会对订单核心业务产生性能影响。如果需要临时刷新榜单，也可以手动触发定时任务重新统计，完全满足店家的日常使用需求。解决思路我在stats_service.py中单独封装了一个时间范围计算函数，将“今日/本周/本月”这种自然语言描述转换为精确的起止时间。然后，在畅销统计查询函数中调用它，使用SQLAlchemy的聚合查询按商品ID分组统计销量。这套封装之后，无论是新增“季度畅销”这样的维度，还是修改时间计算的规则，只需要修改这个单一函数即可，不需要改动核心的聚合统计逻辑，后期维护起来十分方便。上线之后，我也对功能做了几轮压测，在并发数达到XX的时候，接口响应时间仍然维持在100毫秒以内，比最初实时查询的方案快了近百倍，店家使用后也没有反馈过性能卡顿的问题，很好地解决了这个场景下的性能痛点。from datetime import datetime, timedeltafrom sqlalchemy import funcdef get_time_range(period='today'):"""根据时间周期字符串，计算查询的起止时间戳- today: 今日0点到当前时刻- week:  本周一0点到当前时刻- month: 本月1日0点到当前时刻"""now = datetime.utcnow()if period == 'today':start_time = datetime(now.year, now.month, now.day, 0, 0, 0)elif period == 'week':# 本周一 = 当前日期 - (今天是本周第几天 - 1)monday = now - timedelta(days=now.weekday())start_time = datetime(monday.year, monday.month, monday.day, 0, 0, 0)elif period == 'month':start_time = datetime(now.year, now.month, 1, 0, 0, 0)else:# 默认返回全部时间范围start_time = datetime(2020, 1, 1)end_time = nowreturn start_time, end_timedef get_top_selling_products(period='today', limit=10):"""获取指定时间周期内的畅销商品Top N返回格式: [{'product_name': '红玫瑰', 'total_sold': 58}, ...]"""start_time, end_time = get_time_range(period)# 查询逻辑：# 1. 关联查询 OrderItem 和 Order 表# 2. 筛选已完成支付的订单（排除待支付、已取消的）# 3. 只统计指定时间范围内的订单# 4. 按 product_id 分组，对 quantity 求和# 5. 按总销量降序排列，取前 limit 条results = db.session.query(OrderItem.product_name,func.sum(OrderItem.quantity).label('total_sold')).join(Order, OrderItem.order_id == Order.id).filter(Order.status == '已完成',Order.created_at.between(start_time, end_time)).group_by(OrderItem.product_name).order_by(func.sum(OrderItem.quantity).desc()).limit(limit).all()# 转换为字典列表，方便前端渲染return [{'product_name': row[0],'total_sold': int(row[1])}for row in results]设计细节的考量：时间计算与查询分离：get_time_range()只负责算时间，get_top_selling_products()只负责查数据。如果将来要增加“本季度”、“本年”等时间维度，只需扩展前者，后者无需改动。排除未支付订单：统计畅销商品时只计入“已完成”状态的订单，排除“待支付”和“已取消”的，保证数据的准确性。参数化limit：不硬编码Top 10，而是作为参数传入，方便前端调整排行榜展示数量。与实习经历的联系：在智能客服项目中，我们也需要统计“高频问题Top N”、“热门意图Top N”等数据，用于优化FAQ库和意图识别模型。当时的统计逻辑和这里非常相似，都是对关联表做聚合查询。记得有一次因为忘记了group_by之后having和where的区别，导致统计数据一直不对，被导师提醒后才恍然大悟。这次在NingFlora项目中，我特别注意了SQL的执行顺序（FROM → JOIN → WHERE → GROUP BY → HAVING → SELECT → ORDER BY），确保筛选条件放在正确的位置。6.5 AI辅助开发：一个实习生的真实体会这部分我想以更个人的视角来写，因为它关乎我作为AI算法实习生的切身感受。从“怀疑”到“理解”刚开始实习时，我对AI辅助编程工具是有些排斥的。我觉得写代码就应该一行一行自己敲，用工具生成出来的东西总感觉“不正宗”。但导师很快改变了我的看法。有一次我需要写一个数据预处理的Pipeline，代码量很大但逻辑不复杂。导师让我试试用AI工具生成框架，然后我来填充核心逻辑。结果原本预估两天的工作，半天就完成了。导师当时说了一句话我印象很深：“你要学会区分什么是创造性的工作，什么是流程性的工作。把流程性工作交给工具，把创造力留给自己的大脑。”这句话让我重新理解了AI工具的价值——它不是替代开发者，而是解放开发者。CodeArts在NingFlora项目中的实际角色在这次NingFlora项目中，华为云CodeArts代码智能体具体帮我做了哪些事呢？工作类型谁完成具体内容需求分析与功能定义我自己梳理业务场景，确定四级会员体系、购物车逻辑、订单流程架构设计与技术选型我自己确定Flask+SQLite+Bootstrap的技术栈和五层分层架构需求文档格式化CodeArts辅助将我口述的需求整理成规范的spec.md核心业务逻辑我自己折扣计算、订单事务处理、安全锁定、畅销统计样板代码生成CodeArts辅助蓝图注册、HTML骨架、种子数据、配置模板代码审查与调试我自己逐行审核AI生成的代码，修复不合理的实现测试用例编写我自己设计测试场景，验证边界条件粗略估算，CodeArts大概帮我节省了30%-40%的重复性编码时间。这些省下来的时间，我投入到了更重要的事情上：思考架构设计是否合理、验证并发场景下的逻辑是否正确、斟酌用户体验的细节处理。通过这次实践，我也更清晰地认识到了当前AI辅助编程的局限性：AI不理解业务上下文：它能生成一个“看起来对”的登录功能，但它不会主动想到“应该加登录失败锁定”，这个需求源于我对安全威胁的理解。AI不关心长期维护：它倾向于用最短的代码实现功能，但不会考虑代码的可扩展性。比如“畅销统计”的时间范围计算，AI可能会写死在查询逻辑里，而我会刻意抽离成独立函数。AI可能引入安全风险：如果我不审核，AI可能会生成使用弱哈希算法的密码存储代码，或者不安全的SQL拼接。这些都需要开发者有安全意识才能识别。写在最后在华为云实习结束时的答辩上，我说过一段话，现在依然觉得适用：“AI时代的开发者，核心竞争力不在于写代码有多快，而在于知道什么样的代码是好的代码，知道什么样的设计是合理的设计，知道什么样的方案在什么场景下适用。这些判断力，来自于对底层原理的深刻理解，来自于踩过坑、吃过亏、做过复盘的经验积累。”NingFlora项目虽然只是一个课程级别的实践，但它让我在真实场景中验证了课堂上学到的数据库事务、面向对象设计、网络安全等知识，也让我亲身体验了AI工具在开发流程中应该如何被正确使用。这些收获，远比完成一个项目本身更有价值。作为一名还在学习阶段的实习生，这次和CodeArts协作开发NingFlora项目的经历，让我对AI时代的开发者成长路径也有了全新的思考。我们不用排斥AI工具带来的变化，反而可以主动用好这个“效率杠杆”，把基础重复工作的时间省下来，多花精力打磨自己的核心能力。也希望我的这些真实体会，能给同样在学习AI辅助开发的开发者朋友们，带来一点可供参考的思路。  项目源码仓库地址：https://github.com/yyyynnnnssss/NingFlora-若无法访问，请复制链接在浏览器打开）演示视频：https://www.bilibili.com/video/BV1Q3gd6BEUL/?spm_id_from=333.1387.homepage.video_card.click&vd_source=9b20b942cbbb083c019a0e3f2b6266ba

一、概述1.1 案例介绍考研备考管家是一款面向考研学子的 AI 智能学习管理网站，覆盖数学一、英语一、政治、408计算机基础四门统考科目，提供知识图谱追踪、刷题记录、艾宾浩斯错题复习、智能排期、AI 管家对话、专注计时等一站式备考功能。前端采用 Vue3 + Element Plus 手绘手账风格，后端采用 Flask + SQLite + DeepSeek 大模型，全栈可一键构建运行。项目地址：https://github.com/LeoMay23/ExamPreparationDEMO展示：https://www.bilibili.com/video/BV1MpKh6nEJr/?spm_id_from=333.1387.upload.video_card.click&vd_source=69e3b625d4662860466dccf85672cf571.2 适用对象高校学生个人开发者1.3 案例时间本案例总时长预计100分钟。1.4 案例流程说明：环境准备：安装 Node.js、Python，配置 DeepSeek 大模型 API Key；后端构建：安装 Python 依赖，初始化 SQLite 数据库与知识点种子数据，启动 Flask 服务；前端构建：安装 npm 依赖，配置 Vite 代理，构建并启动 Vue3 开发服务器；功能体验：注册登录 → 考研档案 → 仪表盘 → 科目中心 → 刷题记录 → 错题本 → 智能计划 → AI 管家 → 专注学习 → 复盘中心。1.5 资源总览本案例预计花费10元。所有依赖均为开源免费软件，大模型 API 可使用 DeepSeek 免费额度。资源名称规格单价（元）Node.jsv22.x免费Python3.10+免费DeepSeek APIdeepseek-v4-pro10元华为云码道（CodeArts）代码智能体专业版代金券兑换二、环境和资源准备2.1 安装 Node.js 与 Python确保本地已安装：Node.js v18+（推荐 v22.x），下载地址：cid:link_1Python 3.10+，下载地址：cid:link_0验证安装：node --version python --version 2.2 配置 DeepSeek 大模型 API Key注册 DeepSeek 开放平台账号在「API Keys」页面创建新的 API Key，复制保存。在项目 backend/ 目录下创建 .env 文件，填入以下内容：DEEPSEEK_BASE_URL=https://api.deepseek.com DEEPSEEK_AUTH_TOKEN=sk-xxxxxxxxxxxxxxxxxxxxxxxx DEEPSEEK_MODEL=deepseek-v4-pro2.3 获取项目代码将项目代码下载到本地工作目录：git clone <项目仓库地址> ExamPreparation cd ExamPreparation三、构建考研备考管家应用3.1 项目结构说明ExamPreparation/ ├── backend/ # Flask 后端 │ ├── app.py # 应用入口，注册蓝图 │ ├── config.py # 配置（DB路径、DeepSeek API） │ ├── database.py # 数据库表定义 + 种子数据 + 迁移 │ ├── requirements.txt # Python 依赖 │ ├── .env # 环境变量（API Key 等） │ ├── agent/ # AI Agent 模块 │ │ ├── llm_client.py # DeepSeek LLM 客户端 │ │ ├── orchestrator.py # Agent 编排器 │ │ ├── prompts.py # Prompt 模板 │ │ ├── tool_registry.py # 工具注册 │ │ └── tool_executor.py # 工具执行器 │ ├── planner/ # 排期引擎 │ │ ├── scheduler.py # 6维权重4阶段排期算法 │ │ └── time_slot.py # 空闲时段计算 │ ├── routes/ # API 路由（11个蓝图） │ │ ├── auth.py # 用户注册/登录/档案 │ │ ├── subjects.py # 科目中心（14个端点） │ │ ├── mistakes.py # 错题本 │ │ ├── plans.py # 智能计划 │ │ ├── chat.py # AI 管家对话 │ │ ├── sessions.py # 专注学习 Session │ │ └── ... │ └── services/ # 业务逻辑层 │ ├── subject_service.py # 科目中心（知识树/刷题/词汇/背诵/算法） │ ├── mistake_service.py # 错题本（艾宾浩斯复习） │ ├── planner_service.py # 计划服务（生成/延后/提前/锁定） │ ├── ai_butler_service.py# AI管家（今日概览/提醒/专注建议） │ ├── user_service.py # 用户系统 │ └── ... ├── web/ # Vue3 前端 │ ├── package.json # npm 依赖 │ ├── vite.config.js # Vite 配置（代理 /api → localhost:5000） │ └── src/ │ ├── main.js # 应用入口 │ ├── assets/main.css # 全局手绘风格 CSS │ ├── router/index.js # 路由（15个页面 + 守卫） │ ├── stores/ # Pinia 状态管理 │ │ ├── user.js # 用户状态（登录/档案/倒计时） │ │ ├── subject.js # 科目状态（知识树/统计/刷题） │ │ └── mistake.js # 错题状态 │ ├── utils/api.js # Axios 封装（拦截器注入 user_id/token） │ ├── components/ │ │ └── layout/MainLayout.vue # 侧边栏 + 主内容区 │ └── views/ # 15个页面 │ ├── Login.vue # 登录注册 │ ├── Onboarding.vue # 考研档案 │ ├── Dashboard.vue # 仪表盘（倒计时+4科卡片+今日计划+错题） │ ├── Subjects.vue # 科目中心入口 │ ├── math/MathIndex.vue # 数学一 │ ├── english/EnglishIndex.vue # 英语一 │ ├── politics/PoliticsIndex.vue # 政治 │ ├── cs408/Cs408Index.vue # 408 │ ├── Plan.vue # 智能计划 │ ├── Chat.vue # AI 管家 │ ├── Focus.vue # 专注学习 │ ├── Mistakes.vue # 错题本 │ ├── Review.vue # 复盘中心 │ ├── Tasks.vue # 计划管理 │ └── Settings.vue # 设置 └── HLD-KaoyanPrep-Website-20260710.md # HLD 设计文档 3.2 后端：安装依赖并启动服务步骤1：进入后端目录，安装 Python 依赖：cd backend pip install -r requirements.txtrequirements.txt 内容如下：Flask==3.0.3 flask-cors==4.0.1 requests==2.32.3 python-dotenv步骤2：启动 Flask 服务：python app.py启动成功后，服务运行在 http://localhost:5000。首次启动时会自动：创建 SQLite 数据库 aiplanpal.db建立全部 25 张表插入知识点种子数据（数学64个、政治32个、408共55个节点）关键代码讲解：数据库初始化与种子数据backend/database.py 中的 init_db() 函数负责数据库的创建与迁移：def init_db(): with closing(sqlite3.connect(DB_PATH)) as conn: conn.row_factory = sqlite3.Row conn.execute("PRAGMA foreign_keys = ON") create_tables(conn) # 创建全部25张表 migrate_existing_tables(conn) # 迁移旧表结构 + 种子数据 conn.commit() 考研专用表包括：表名用途math_knowledge_nodes数学知识点（高数/线代/概率论，64个节点）math_practice_records数学刷题记录english_vocabulary_progress英语词汇复习进度（艾宾浩斯间隔）english_reading_records英语阅读训练记录english_writing_records英语写作记录politics_knowledge_nodes政治知识点（马原/毛中特/史纲/思修，32个节点）politics_choice_records政治选择题记录politics_memorization_progress政治背诵进度cs408_knowledge_nodes408知识点（数据结构/计组/OS/网络，55个节点）cs408_practice_records408刷题记录cs408_algorithm_records408算法训练记录mistake_records错题本（艾宾浩斯复习）种子数据示例——数学知识点在 _seed_knowledge_nodes() 中批量插入：math_nodes = [ ("higher_math", "函数与极限", "函数的概念", 2, "core", "unstarted", 3.0), ("higher_math", "函数与极限", "极限的概念与性质", 3, "core", "unstarted", 4.0), ("higher_math", "一元微分学", "微分中值定理", 5, "core", "unstarted", 6.0), # ... 共64个节点 ] conn.executemany( "INSERT INTO math_knowledge_nodes (subject, chapter, section, difficulty, importance, mastery, estimated_hours) VALUES (?, ?, ?, ?, ?, ?, ?)", math_nodes, ) 关键代码讲解：DeepSeek LLM 客户端backend/agent/llm_client.py 封装了与大模型的交互，支持普通对话和 JSON 结构化输出：def chat_completion(messages, max_tokens=900, temperature=0.2, response_format=None, timeout_seconds=45): if not DEEPSEEK_AUTH_TOKEN: raise LLMUnavailableError("DEEPSEEK_AUTH_TOKEN is not configured") payload = { "model": DEEPSEEK_MODEL, "messages": messages, "temperature": temperature, "max_tokens": max_tokens, } if response_format: payload["response_format"] = response_format response = requests.post( f"{DEEPSEEK_BASE_URL.rstrip('/')}/chat/completions", headers={ "Authorization": f"Bearer {DEEPSEEK_AUTH_TOKEN}", "Content-Type": "application/json", }, json=payload, timeout=timeout_seconds, ) response.raise_for_status() # ... 解析返回 降级策略：当 DEEPSEEK_AUTH_TOKEN 未配置时，所有 AI 功能会自动降级为本地规则引擎，不会报错阻断服务。关键代码讲解：智能排期引擎backend/services/planner_service.py 中的 generate_plans() 实现了6维权重4阶段的动态排期：def generate_plans(user_id=DEFAULT_USER_ID): tasks = fetch_tasks(user_id) if not tasks: # 无任务时自动创建8个默认考研任务 default_tasks = [ ("高数极限与连续刷题", "math", 90, "4", 3), ("英语阅读理解训练", "english", 60, "3", 2), ("政治马原选择题", "politics", 45, "3", 2), ("408数据结构算法练习", "cs408", 60, "4", 3), # ... 共8个 ] for title, task_type, est_min, priority, difficulty in default_tasks: db.execute("INSERT INTO tasks (...) VALUES (...)") # 删除未锁定的旧计划，保留用户锁定的计划 db.execute("DELETE FROM study_plans WHERE user_id = ? AND locked = 0 AND status IN (...)") # 调用排期算法生成新计划 generated = schedule_tasks(tasks, courses, existing_plans=locked_plans, days=7) 排期策略：schedule_tasks() 综合考虑任务优先级、难度、截止时间、课表冲突、用户偏好时段和当前备考阶段（基础/强化/冲刺/模考）6个维度，自动生成7天学习计划。3.3 前端：安装依赖并启动开发服务器步骤1：进入前端目录，安装 npm 依赖：cd web npm install 步骤2：启动 Vite 开发服务器：npm run dev启动成功后，浏览器访问 http://localhost:3000。关键代码讲解：全局手绘风格 CSSweb/src/assets/main.css 定义了整套手绘手账风格的设计令牌：:root { --ink: #171717; /* 墨黑：边框、文字 */ --paper: #f7eed7; /* 网格纸背景 */ --cream: #fff7e8; /* 奶油白卡片 */ --yellow: #f8d46b; /* 黄色强调 */ --blue: #86b7d9; /* 蓝色强调 */ --red: #e1452d; /* 红色强调 */ --green: #4c9b54; /* 绿色强调 */ --border-thick: 4px solid var(--ink); /* 粗黑边 */ --shadow: 6px 6px 0 var(--ink); /* 偏移投影 */ --radius: 16px; /* 大圆角 */ --radius-pill: 999px; /* 药丸圆角 */ --color-math: #4A90D9; /* 数学蓝 */ --color-english: #7B68EE; /* 英语紫 */ --color-politics: #e1452d; /* 政治红 */ --color-cs408: #4c9b54; /* 408绿 */ } 网格纸背景通过 CSS 渐变实现：body { background: linear-gradient(90deg, rgba(23,23,23,0.03) 1px, transparent 1px), linear-gradient(0deg, rgba(23,23,23,0.025) 1px, transparent 1px), var(--paper); background-size: 24px 24px; } 关键代码讲解：AI 管家对话与确认卡片web/src/views/Chat.vue 实现了 AI 管家对话界面，支持确认卡片（confirm_card）交互：<div v-if="msg.confirmCard" class="confirm-card"> <div class="confirm-title">{{ msg.confirmCard.title }}</div> <div class="confirm-summary">{{ msg.confirmCard.summary }}</div> <ul v-if="msg.confirmCard.details?.length" class="confirm-details"> <li v-for="(d, di) in msg.confirmCard.details" :key="di">{{ d }}</li> </ul> <div class="confirm-actions"> <el-button v-for="(action, ai) in msg.confirmCard.actions" :key="ai" :type="ai === 0 ? 'primary' : 'default'" size="small" @click="handleConfirm(msg.confirmCard, action, i)" :disabled="msg.confirmed"> {{ action }} </el-button> </div> </div> 交互流程：用户发送消息 → 后端 Agent 分析意图 → 如果需要执行操作（如生成计划），返回 confirm_card → 用户点击确认 → 前端发送 confirmed_tool → 后端执行操作并返回结果。3.4 构建生产版本前端构建生产版本：cd web npm run build构建成功后，静态文件输出到 web/dist/ 目录，可直接部署到任何静态服务器。后端无需额外构建步骤，直接运行 python app.py 即可。3.5 运行效果展示登录注册页面用户首次访问时进入登录页面，支持注册和登录。页面采用居中布局，手绘风格卡片和药丸按钮。考研档案登录后进入考研档案页面，设置目标院校、专业、考研日期（日期选择器）、当前阶段、每日可用时间等。仪表盘仪表盘是用户首页，核心展示：考研倒计时：大号数字显示距考研天数，右侧显示当前阶段和考试日期四科进度卡片：数学/英语/政治/408 各一张卡片，显示掌握进度和正确率，点击进入对应科目今日计划：展示当天学习块列表，支持一键生成待复习错题：展示最近5条待复习错题AI 管家：显示今日概览和建议科目中心科目中心入口展示四门科目的卡片，每张卡片带有科目色带、图标和简介，hover 时有手绘风格的旋转偏移动画。数学一页面数学一页面包含三个 Tab：知识图谱：按高数/线代/概率论分组展示知识点，每个知识点可设置掌握度（未开始/学习中/已练习/已掌握）刷题记录：表单录入题源、题号、知识点、结果、耗时、错误类型统计：展示总刷题数、正确率、知识点掌握分布（进度条）、最近20条刷题记录（药丸标签）英语一页面英语一页面包含四个 Tab：词汇管理：展示今日待复习词汇，支持艾宾浩斯间隔复习阅读训练：录入年份、篇号、正确数、耗时写作工坊：录入作文类型、题目、内容统计：展示阅读篇数、写作篇数、最近阅读记录、最近写作记录政治页面政治页面包含三个 Tab：知识框架：按马原/毛中特/史纲/思修/时政分组，标注核心考点和考试频率选择题训练：录入题源、题号、单选/多选、结果、错误类型背诵管理：今日待背诵内容，支持艾宾浩斯间隔复习统计：展示选择题总数、正确率、最近选择题记录408计算机基础页面408页面包含四个 Tab：知识图谱：按数据结构/计组/OS/网络分组，标注算法类知识点刷题记录：录入子科目、题源、题号、题型、结果、耗时算法训练：录入算法名、语言、代码、时间/空间复杂度统计：展示刷题总数、正确率、算法题数、最近刷题记录、最近算法记录错题本错题本页面功能完整：筛选栏：按科目和掌握状态筛选统计药丸：总错题、已掌握、未掌握、今日待复习错题卡片列表：左侧色带标识科目，展示题目内容、题源、错误类型、复习次数操作按钮：复习（艾宾浩斯）、已掌握详情弹窗：展示题目内容、我的答案、正确答案、解析添加错题弹窗：手动录入完整错题信息自动创建：在数学/政治/408刷题时，答错的题目会自动创建错题记录。智能计划智能计划页面展示7天学习计划，支持：一键生成计划（6维权重4阶段排期算法）开始/完成/延后/锁定计划AI 辅助调整（延后时自动寻找合适空闲时段）AI 管家AI 管家是对话式交互界面：支持自然语言对话确认卡片交互（如「生成今日计划」会弹出确认卡片）4种管家风格（温柔鼓励型/朋友陪伴型/严肃型/极简提醒型）专注学习专注学习页面提供番茄钟计时器：选择科目后自动推荐专注时长（数学50分钟、英语40分钟、政治30分钟、408为45分钟）大号圆形计时器，手绘风格暂停/继续/提前结束AI 专注建议卡片结束时自动记录 Session 到后端复盘中心复盘中心展示学习统计数据，包括各科目专注时长、完成率等。设置设置页面支持修改：考研日期（日期选择器）当前备考阶段管家名称和风格四、技术要点总结4.1 前后端分离架构层级技术栈说明前端Vue3 + Vite + Element Plus + Pinia手绘风格 SPA，15个页面后端Flask + SQLite + DeepSeek11个蓝图，25张表，14个科目端点AIDeepSeek API + Agent4种管家风格，降级为规则引擎4.2 关键设计决策降级策略：所有 AI 功能在无 LLM 时自动降级为本地规则引擎，确保核心功能可用艾宾浩斯复习：错题本和词汇/背诵模块均采用 [1,2,4,7,15,30] 天间隔复习6维排期：综合优先级、难度、截止时间、课表、偏好时段、备考阶段6个维度手绘风格：通过 CSS 变量体系统一管理，粗黑边 + 偏移投影 + 药丸标签 + 网格纸背景自动错题：刷题答错时自动创建错题记录，无需手动添加默认任务：首次生成计划时自动创建8个考研默认任务4.3 已知注意事项Element Plus 的 el-input-number 组件需要 min-width: 140px 和排除全局 wrapper 样式覆盖axios 拦截器中 POST 请求无 body 时 user_id 不会被注入，所有无 body 的 POST/PUT 必须传 {}Python 代码中不能使用中文引号 ""（与 f-string 冲突），必须用 「」 替代esbuild 偶尔需要清理 node_modules 重装才能正常构建五、开发流程5.1 设计开发大纲5.2 基于初始文档构建网站5.3 逐步修改细节

一、概述1.1 案例介绍本案例基于华为云码道（CodeArts）代码智能体，从零构建一款面向三四线城市羽毛球爱好者的综合型平台——羽聚。平台涵盖约球、订场、赛事、社交、教学等核心功能，以H5移动端Web为应用形态，采用前后端分离架构，后端基于Python + FastAPI + SQLite，前端基于Vue3 + Vite + Element Plus。本案例完整演示了如何借助CodeArts代码智能体进行需求拆解、架构设计、代码生成、联调排错的全流程，展示AI辅助开发在中小团队快速交付MVP产品中的实践价值。1.2 适用对象个人开发者高校学生小型创业团队1.3 案例时间本案例总时长预计60分钟。1.4 案例流程说明：使用CodeArts代码智能体进行产品需求拆解与功能架构设计，确定MVP核心模块；基于智能体生成后端数据模型、API路由、认证中间件等完整后端工程；基于智能体生成前端页面组件、路由配置、状态管理等完整前端工程；通过自然语言对话驱动智能体完成功能迭代（费用结算扩展、场地空闲校验、社区删除等）；利用智能体辅助定位并修复前后端联调问题（枚举值不匹配、时区兼容、数据库迁移等）。1.5 资源总览本案例预计花费0元。所有开发工具和运行环境均为免费资源。资源名称规格单价（元）华为云码道（CodeArts）代码智能体通用体验版免费Python 3.14官方发行版免费Node.js 18+官方LTS版免费SQLite内置于Python免费二、环境和资源准备2.1 安装Python运行环境前往Python官网（https://www.python.org/downloads/）下载并安装Python 3.12+（推荐3.12，3.14存在部分第三方库兼容问题）。安装时勾选"Add Python to PATH"。验证安装：python --version2.2 安装Node.js运行环境前往Node.js官网（https://nodejs.org/）下载并安装LTS版本。安装后验证：node --version npm --version2.3 安装后端依赖进入后端目录，安装Python依赖：cd backend pip install fastapi==0.115.0 uvicorn==0.30.0 sqlalchemy==2.0.35 pydantic==2.9.0 python-jose==3.3.0 python-multipart==0.0.9 注意：由于Python 3.14与pydantic-core源码编译不兼容，本案例将依赖安装在全局环境中，不使用虚拟环境。2.4 安装前端依赖进入前端目录，安装npm依赖：cd frontend npm install2.5 启动华为云码道（CodeArts）代码智能体在IDE中打开CodeArts代码智能体面板，通过自然语言对话开始开发。本案例全程使用CodeArts智能体辅助代码编写与调试。三、构建羽聚平台应用3.1 需求拆解与功能架构设计3.1.1 使用CodeArts智能体进行需求拆解在CodeArts智能体对话框中输入需求描述：“开发一款面向三四线城市的羽毛球爱好者平台，涵盖约球、订场、赛事、社交、教学等功能，技术栈前端Vue3+Vite+Element Plus，后端Python+FastAPI+SQLite，应用形态为H5移动端Web。”智能体自动完成以下工作：将10大模块拆解为MVP可交付的6个核心模块：约球管理、场地预订、社交社区、实用工具、个人中心、管理后台识别关键差异化能力：水平评级体系、信用防鸽子机制输出模块间依赖关系与迭代路线3.1.2 MVP功能架构模块核心功能MVP裁剪说明约球管理发起约球、报名/取消、费用结算、场地校验5种费用结算方式完整实现场地预订场馆列表、场馆详情、跳转约球轻模式，不对接场馆系统社交社区发帖、评论、点赞、删除、用户资料卡基础社交闭环实用工具计分器、打球记录（含比赛记录）练习/休闲模式无分制个人中心注册登录、资料编辑、水平评级信用体系不可裁剪管理后台用户管理、内容审核基础管理能力3.2 后端工程构建3.2.1 项目结构backend/ ├── app/ │ ├── api/ # API路由模块 │ │ ├── auth.py # 认证（注册/登录/用户资料） │ │ ├── activities.py # 约球活动（含场地空闲校验） │ │ ├── venues.py # 场馆管理 │ │ ├── social.py # 社交社区（帖子/评论/点赞） │ │ ├── tools.py # 实用工具（打球记录/计分） │ │ └── admin.py # 管理后台 │ ├── core/ # 核心配置 │ │ ├── config.py # 环境变量与配置 │ │ ├── database.py # SQLAlchemy引擎（SQLite） │ │ └── security.py # JWT认证 + hashlib密码哈希 │ ├── models/ # 数据模型 │ │ ├── user.py # 用户模型（含水平评级/信用分） │ │ ├── activity.py # 活动模型（5种费用结算） │ │ ├── venue.py # 场馆模型 │ │ ├── social.py # 社交模型 │ │ └── tools.py # 工具模型（含MatchResult子表） │ ├── schemas/ # Pydantic Schema │ └── main.py # FastAPI入口（含自动迁移） ├── .env # 环境变量 └── requirements.txt # 依赖清单3.2.2 关键代码讲解1）SQLite数据库引擎配置由于SQLite默认不支持多线程访问，需配置 check_same_thread 参数：engine = create_engine( "sqlite:///./badminton_hub.db", connect_args={"check_same_thread": False} ) 2）密码哈希方案Python 3.14没有可用的bcrypt包，采用 hashlib.sha256 + 随机盐值 替代：def get_password_hash(password: str) -> str: salt = secrets.token_hex(16) hash_value = hashlib.sha256((salt + password).encode()).hexdigest() return f"{salt}${hash_value}" def verify_password(plain_password: str, hashed_password: str) -> bool: salt, hash_value = hashed_password.split("$") return hashlib.sha256((salt + plain_password).encode()).hexdigest() == hash_value3）活动费用结算模型FeeRule 枚举支持5种结算方式，前端传英文key，后端存中文枚举值：class FeeRule(str, enum.Enum): aa = "AA制" fixed_per_person = "固定人均价" host_prepay = "发起人垫付" host_treat = "全场包场" identity_based = "按身份分摊" 4）数据库自动迁移机制create_all 不会修改已存在的表结构，在 main.py 的 startup 事件中用 inspect 检测缺失列并执行 ALTER TABLE：MIGRATIONS = [ ("activities", "per_person_fee", "ALTER TABLE activities ADD COLUMN per_person_fee FLOAT DEFAULT 0.0"), ("play_records", "match_type", "ALTER TABLE play_records ADD COLUMN match_type VARCHAR(20) DEFAULT '休闲'"), # ...更多迁移项 ] @app.on_event("startup") def startup(): Base.metadata.create_all(bind=engine) insp = inspect(engine) for table, column, alter_sql in MIGRATIONS: if table in insp.get_table_names() and column not in [c["name"] for c in insp.get_columns(table)]: with engine.connect() as conn: conn.execute(text(alter_sql)) conn.commit() 5）场地空闲校验创建活动时检查同场馆+同场地+时段是否冲突：existing = db.query(Activity).filter( Activity.venue_name == data.venue_name, Activity.court_number == data.court_number, Activity.status != ActivityStatus.cancelled, ).all() for ex in existing: ex_start = ex.activity_date ex_end = ex_start + timedelta(hours=ex.duration_hours) if ex_start < end and ex_end > start: raise HTTPException(status_code=409, detail=f"该场地在此时段已被预约") 3.2.3 启动后端服务cd backend uvicorn app.main:app --reload --port 8000 3.3 前端工程构建3.3.1 项目结构frontend/ ├── src/ │ ├── api/ # API调用封装 │ │ └── index.js # 统一接口定义 │ ├── components/ # 公共组件 │ │ └── TabBar.vue # 底部导航栏 │ ├── router/ # 路由配置 │ │ └── index.js # 17个页面路由 │ ├── store/ # 状态管理 │ │ └── user.js # Pinia用户状态 │ ├── utils/ # 工具函数 │ │ └── request.js # Axios封装（自动携带Token） │ └── views/ # 页面组件 │ ├── match/ # 约球模块（首页/详情/创建/列表） │ ├── venue/ # 场馆模块（列表/详情） │ ├── social/ # 社区模块（动态/详情/用户资料卡） │ ├── tools/ # 工具模块（计分器/打球记录） │ ├── user/ # 用户模块（登录/注册/资料/编辑/资料卡） │ └── admin/ # 管理后台 ├── vite.config.js # Vite配置（含API代理） └── package.json # 依赖配置3.3.2 关键代码讲解1）Vite开发代理配置前端开发时通过Vite代理转发API请求到后端：server: { proxy: { '/api': { target: 'http://127.0.0.1:8000', changeOrigin: true, } } } 2）Axios请求拦截器自动携带JWT Token，401时跳转登录页：api.interceptors.request.use((config) => { const token = localStorage.getItem('token') if (token) config.headers.Authorization = `Bearer ${token}` return config }) 3）费用结算方式映射前端使用英文key（aa/fixed_per_person等），提交时映射为后端中文枚举值：const feeRuleMap = { aa: 'AA制', fixed_per_person: '固定人均价', host_prepay: '发起人垫付', host_treat: '全场包场', identity_based: '按身份分摊' } payload.fee_rule = feeRuleMap[payload.fee_rule] || payload.fee_rule4）场地可用性实时查询选择活动时间后，自动查询该时段已被预约的场地，已预约场地在选择器中置灰：watch([() => form.value.activity_date, () => form.value.duration_hours, () => form.value.venue_name], () => { fetchCourtAvailability() }) 5）打球记录嵌套比赛记录每条打球记录可包含多局比赛结果，练习/休闲模式自动隐藏分制和比赛记录：const isCompetitive = computed(() => !['练习', '休闲'].includes(form.value.match_type)) 3.3.3 启动前端服务cd frontend npm run dev3.4 使用CodeArts代码智能体辅助开发与调试3.4.1 智能体辅助开发流程本案例全程通过CodeArts代码智能体的自然语言对话驱动开发，典型交互示例如下：开发阶段用户输入（自然语言）智能体输出功能规划“开发羽毛球平台，涵盖约球、订场、社交等功能”10大模块拆解、MVP裁剪为6模块、迭代路线后端建模“创建活动模型，支持5种费用结算方式”Activity模型 + FeeRule枚举 + Schema前端页面“创建约球首页，显示推荐活动和我报名的活动”Home.vue组件 + API调用 + 排重逻辑功能迭代“场馆详情页的预订按钮改为跳转创建活动页”VenueDetail.vue修改 + 预填参数传递Bug修复“后端报错422 Unprocessable Content”定位fee_rule枚举值不匹配，提供映射方案3.4.2 智能体辅助调试实录问题1：422 Unprocessable Content现象：前端创建活动时后端返回422错误智能体诊断：通过Python脚本直接调用API，发现 fee_rule 字段前端传英文key（"aa"），后端 FeeRule 枚举值是中文（"AA制"），Pydantic校验失败解决方案：前端提交时通过映射表将英文key转为中文枚举值问题2：时区不兼容导致500错误现象：场地空闲查询接口返回500，报错 can't compare offset-naive and offset-aware datetimes智能体诊断：前端传ISO字符串带时区信息，数据库datetime无时区，比较时类型不一致解决方案：比较前统一 .replace(tzinfo=None) 去掉时区信息问题3：数据库字段缺失现象：新增模型字段后旧数据库报错智能体诊断：SQLAlchemy的 create_all 不会修改已存在的表结构解决方案：在 main.py 的 startup 事件中实现自动迁移机制，用 inspect 检测缺失列并执行 ALTER TABLE问题4：esbuild构建失败现象：前端 npm run build 报esbuild兼容性错误智能体诊断：当前Windows环境下esbuild二进制不兼容，属于环境问题而非代码问题解决方案：开发阶段使用 npm run dev 正常运行，生产部署时可更换构建工具或环境四、解决方案4.1 系统架构设计本案例采用前后端分离的单体架构，适合MVP快速验证阶段：前端层：Vue3 + Vite + Element Plus，H5移动端适配，通过Vite代理转发API请求后端层：FastAPI + SQLAlchemy + SQLite，JWT无状态认证，CORS跨域支持数据层：SQLite文件数据库，零配置零运维，适合1-10万用户规模的MVP阶段认证层：JWT Token + hashlib.sha256密码哈希，轻量级安全方案4.2 核心技术选型技术点选型选型理由后端框架FastAPI异步高性能，自动生成API文档，Pydantic数据校验数据库SQLite零配置，单文件部署，MVP阶段无需独立数据库服务前端框架Vue3 + Vite组合式API，开发热更新快，Element Plus组件丰富认证方案JWT + hashlib无状态认证，不依赖bcrypt等第三方加密库状态管理PiniaVue3官方推荐，TypeScript友好，轻量级4.3 数据模型设计User ──1:N──> Activity (host_id) User ──1:N──> ActivityParticipant User ──1:N──> Post / Comment / PostLike User ──1:N──> PlayRecord ──1:N──> MatchResult User ──1:N──> ScoreRecord Venue ──1:N──> VenueReview Activity ──1:N──> ActivityParticipant Post ──1:N──> Comment / PostLike五、核心技术难点与解决思路5.1 前后端枚举值不一致维度说明问题后端 FeeRule 为 str 枚举，值是中文（"AA制"），前端使用英文key（"aa"），Pydantic校验422根因前后端独立设计枚举，未统一约定解决前端提交时通过映射表 feeRuleMap 将英文key转为中文值；后端保持中文枚举值不变经验前后端枚举应在设计阶段统一约定，或在后端增加值转换层5.2 时区兼容性问题维度说明问题前端传带时区的ISO字符串，SQLite存储无时区datetime，比较时抛出 TypeError根因JavaScript的 Date.toISOString() 带时区偏移，Python的 datetime 默认无时区解决后端接收参数后统一 .replace(tzinfo=None) 去掉时区信息再与数据库比较经验全栈项目应在架构层面统一时区策略，推荐统一使用UTC或统一无时区5.3 SQLite数据库迁移维度说明问题新增模型字段后旧数据库报错，create_all 不会修改已存在的表结构根因SQLAlchemy的 create_all 仅创建不存在的表，不处理表结构变更解决在 main.py 的 startup 事件中实现声明式迁移：用 inspect 检测缺失列，执行 ALTER TABLE ADD COLUMN经验MVP阶段可用声明式迁移替代Alembic等重量级迁移工具，降低复杂度5.4 场地时段冲突校验维度说明问题同一场馆同一场地可能被重复预约到同一时段根因缺少创建活动时的时段冲突检测解决后端创建活动时查询同场馆+同场地+非取消状态的活动，Python端计算时段重叠；前端提供 court-availability 接口实时查询已预约场地经验时段冲突校验应前后端双重保障，前端优化体验，后端保证数据一致性5.5 Python 3.14第三方库兼容性维度说明问题Python 3.14与pydantic-core源码编译不兼容，bcrypt无可用wheel根因Python 3.14为预发布版本，第三方库生态尚未完全适配解决密码哈希改用标准库 hashlib.sha256 + 随机盐值；不使用虚拟环境，依赖装在全局经验生产项目应选择LTS版本的Python，避免使用预发布版本六、扩展资料说明华为云码道（CodeArts）代码智能体：cid:link_1FastAPI官方文档：https://fastapi.tiangolo.com/Vue3官方文档：https://vuejs.org/Element Plus组件库：https://element-plus.org/SQLAlchemy文档：https://docs.sqlalchemy.org/仓库地址：https://github.com/shihaocheng05/badminton-hub.git

设备型号：MatePad Edge 电脑模式 系统版本：HarmonyOS 6.1.0.125 SP52 CodeArts IDE版本：1.0.17 (1000015) 问题描述：在CodeArts IDE中新建一个Python工程/项目，环境只能选择Virtualenv，且解释器列表中一直搜索不到解释器，阻塞创建Python项目。 ps：视频附件已录制，但这里无法上传，提示我没有发布权限……

设备型号：MatePad Edge 电脑模式系统版本：HarmonyOS 6.1.0.125 SP52CodeArts IDE版本：1.0.17 (1000015)问题描述：在CodeArts IDE中新建一个Python工程/项目，环境只能选择Virtualenv，且解释器列表中一直搜索不到解释器，阻塞创建Python项目。ps：视频附件已录制，但这里无法上传，提示我没有发布权限……

一、概述1.1 案例介绍本案例演示如何使用华为云码道（CodeArts）代码智能体，利用子代理功能和AGENTS.md规则，构建一条LeetCode算法题全自动刷题流水线。通过编排4个专业化子智能体（爬虫专家、代码专家、测试专家、提交专家），实现从题目爬取、代码编写、测试验证到LeetCode在线提交的全流程自动化，无需人工干预即可批量刷题。该方案充分展现了CodeArts智能体在复杂多步骤任务中的编排能力、工具调用能力和智能体间协作能力。1.2 适用对象个人开发者高校学生1.3 案例时间本案例总时长预计60分钟。1.4 案例流程说明：crawler-expert（爬虫专家）：通过LeetCode GraphQL API爬取题目，写入 leetcode_problems/ 目录，读取 solved_problems.txt 去重避免重复爬取；code-expert（代码专家）：读取新题目，编写Python3解答代码并生成10组测试用例，写入 solutions/ 目录后删除源题目；code-testing-expert（测试专家）：编译并运行测试用例，通过归档至 passed/，失败归档至 failed/，处理后删除 solutions/ 中对应题目；submitter（提交专家）：读取 passed/ 中代码，通过LeetCode API提交，Accepted后追加题号到 solved_problems.txt 并删除 passed/ 中对应题目。1.5 资源总览本案例预计花费0元。资源名称规格单价（元）华为云码道（CodeArts）代码智能体通用体验版免费二、环境和资源准备2.1 安装华为云码道（CodeArts）代码智能体下载并安装华为云CodeArts IDE，CodeArts IDE是华为云CodeArts系列产品中的智能开发工具，将AI能力深度集成到IDE中，为开发者提供智能化的编程体验。参考官方下载页面。安装完成后，打开任意项目目录即可使用CodeArts代码智能体。2.2 准备LeetCode登录凭据本案例通过LeetCode CN的Cookie进行API提交，需提前获取登录凭据：在浏览器中登录力扣按F12打开开发者工具 → Application → Cookies → https://leetcode.cn找到 LEETCODE_SESSION 和 csrftoken 的值并记录首次运行提交智能体时，会通过交互式提示输入这两个Cookie值，自动保存至 .leetcode_credentials.json。2.3 确认Python环境在终端执行以下命令确认Python 3.x可用：python --version pip install requests三、构建LeetCode全自动刷题流水线3.1 项目结构说明项目目录结构如下：├── AGENTS.md # 项目级规则（权限授权、流水线定义、去重机制） ├── solved_problems.txt # 已解决题号列表（去重用） ├── .leetcode_credentials.json # LeetCode登录凭据（已加入.gitignore） ├── .codeartsdoer/agents/ # 4个子智能体定义文件 │ ├── crawler-expert.md # 爬虫专家 │ ├── code-expert.md # 代码专家 │ ├── code-testing-expert.md # 测试专家 │ └── submitter.md # 提交专家 ├── leetcode_problems/ # 爬取的题目（.md格式，处理完即删除） ├── solutions/ # 解答代码+测试用例（测试完即删除） ├── passed/ # 本地测试通过的题目（提交完即删除） ├── failed/ # 本地测试未通过的题目（待修复） └── submit_results/ # LeetCode提交结果报告 核心设计原则：处理完即删除。每个智能体处理完题目后立即从源目录删除，防止下游重复处理，实现流水线自动流转。3.2 配置项目规则（AGENTS.md）AGENTS.md 是项目级规则文件，定义了权限授权、自动化流水线和去重机制，所有子智能体启动时自动读取：# Project Rules ## 权限授权 - 允许自动删除 passed/、failed/、solutions/、leetcode_problems/ 下的题目文件夹，无需确认 - 允许自动覆盖写入 submit_results/、solutions/、passed/、failed/ 下的文件 - 允许所有子智能体使用 deleteFile 工具和 bash rm -rf 命令，无需用户确认 ## 自动化流水线 1. crawler-expert：爬取题目 → 写入 leetcode_problems/（去重：读取 solved_problems.txt） 2. code-expert：读取新题目 → 编写代码+测试用例 → 写入 solutions/ → 删除源题目 3. code-testing-expert：编译+测试 → 通过写 passed/，失败写 failed/ → 删除 solutions/ 对应题目 4. submitter：提交 LeetCode → Accepted 后追加题号到 solved_problems.txt → 删除 passed/ 对应题目 ## 去重机制 - 项目根目录维护 solved_problems.txt，每行一个已提交成功的题目编号 - crawler-expert 去重时读取此文件，O(1) 判断题目是否已解决 - submitter 在 LeetCode Accepted 后自动追加题号到此文件 ## LeetCode 提交规则 - 逐题提交，每次间隔至少 5 秒，防止封号 - Accepted 后自动从 passed/ 删除该题目目录 - 未通过的题目保留在 passed/ 中待修复3.3 配置爬虫专家（crawler-expert）爬虫专家负责从LeetCode爬取题目，核心能力包括：GraphQL API调用：通过 https://leetcode.cn/graphql 获取题目列表和详情去重检查：读取 solved_problems.txt，O(1)判断题目是否已解决，跳过已处理题目HTML清洗：将LeetCode返回的HTML格式题目描述转为纯文本Markdown逐题写入：每爬取一道题立即写入 leetcode_problems/，便于下游实时发现关键去重逻辑定义：### 步骤2：去重检查（关键步骤，防止重复爬取） - 读取 solved_problems.txt（最高优先级）：获取所有已成功提交的题目编号， 构建已解决集合。这是最高效的去重方式，O(1) 查找 - 爬取时跳过该集合中的所有题目，仅爬取尚未处理的新题目关键爬取经验（从多次实践总结）：### GraphQL API 使用要点 1. API 地址：https://leetcode.cn/graphql，必须设置 Content-Type: application/json 2. 获取题目列表：使用 problemsetQuestionList 查询，通过 filters 筛选难度 3. 获取单题详情：使用 questionDetail 查询，传入 titleSlug 4. 中文内容字段：优先用 translatedContent，若为空则回退 content ### HTML 清洗要点 1. 推荐用 Python 脚本配合 re 正则清洗，比 sed 更可靠 2. <sup> 标签转为 ^，<p> 替换为换行，<li> 替换为列表项 3. Windows 下 curl 中文可能乱码，建议用 Python requests 代替 curl3.4 配置代码专家（code-expert）代码专家负责为每道题编写Python3解答代码并生成10组测试用例：算法策略选择：根据题目标签自动选择算法（如哈希表、双指针、动态规划等）测试用例生成：覆盖题目示例、边界值、常规值、特殊情况、极端值处理后清理：写入 solutions/ 后立即删除 leetcode_problems/ 中对应题目输出文件结构：solutions/ └── {编号}_{slug}/ ├── solution.py # Python3 解答代码 └── test_cases.json # 10组测试用例 solution.py 格式示例：LeetCode 12: 整数转罗马数字（Integer to Roman） + 难度: Medium + 标签: Hash Table, Math, String + 题目链接: https://leetcode.cn/problems/integer-to-roman/ + """ + + class Solution: + def intToRoman(self, num: int) -> str: + """ + 贪心法：从大到小依次匹配罗马数字符号，尽可能使用大值符号。 + 使用预定义的值-符号对列表，按值从大到小排列（包含减法形式）。 + 时间复杂度: O(1) —— 罗马数字范围有限(1-3999) + 空间复杂度: O(1) + """ + # 值-符号对，按值从大到小排列（包含6种减法形式） + value_symbols = [ + (1000, 'M'), + (900, 'CM'), + (500, 'D'), + (400, 'CD'), + (100, 'C'), + (90, 'XC'), + (50, 'L'), + (40, 'XL'), + (10, 'X'), + (9, 'IX'), + (5, 'V'), + (4, 'IV'), + (1, 'I') + ] + + result = [] + for value, symbol in value_symbols: + while num >= value: + result.append(symbol) + num -= value + if num == 0: + break + + return ''.join(result) 3.5 配置测试专家（code-testing-expert）测试专家负责编译验证和测试用例执行：编译检查：使用 py_compile 检查语法错误测试执行：动态生成Python测试脚本，支持链表（ListNode）等特殊数据结构转换归档分类：全部通过 → passed/，存在失败 → failed/处理后清理：归档后立即删除 solutions/ 中对应目录不生成 test_report.json，节省时间。测试结果直接在汇总报告中输出。3.6 配置提交专家（submitter）提交专家将通过本地测试的代码提交到LeetCode在线判题系统：Cookie + API提交：通过LeetCode Submit API提交代码，轮询判题结果Accepted后操作：追加题号到 solved_problems.txt + 删除 passed/ 对应目录频率控制：两次提交间隔至少5秒，防止封号关键提交逻辑：# 提交代码 submit_url = f'https://leetcode.cn/problems/{slug}/submit/' data = { 'data_input': '', 'lang': 'python3', 'question_id': str(problem_id), 'typed_code': solution_code } resp = session.post(submit_url, json=data) # 轮询判题结果（最多等待60秒） check_url = f'https://leetcode.cn/submissions/detail/{submission_id}/check/' for i in range(60): time.sleep(1) result = session.get(check_url) if result.json().get('state') == 'SUCCESS': break Accepted后追加题号到 solved_problems.txt：echo "9" >> solved_problems.txt3.7 运行完整流水线在CodeArts代码智能体中，按顺序调用4个子智能体即可运行完整流水线。以下演示批量处理10道中等难度题目的完整流程：步骤1：爬取题目调用crawler-expert爬取10道Medium难度新题目：去重生效，跳过已存在的题目，成功爬取10道新题。步骤2：编写代码调用code-expert处理所有新题目：10道题全部编写完成，leetcode_problems/ 已清空。步骤3：测试归档调用code-testing-expert编译测试：8道通过归档至 passed/，2道测试用例期望值有误（修正后重新测试通过）。步骤4：提交LeetCode调用submitter提交到LeetCode：10道题全部Accepted！提交结果：#题目Runtime击败2两数相加7ms30.3%3无重复字符的最长子串12ms72.6%5最长回文子串235ms67.8%6Z字形变换7ms89.0%7整数反转1ms30.5%8字符串转换整数4ms19.3%11盛最多水的容器55ms79.4%12整数转罗马数字0ms100%15三数之和403ms99.3%16最接近的三数之和389ms48.5%3.8 关键设计亮点去重机制：solved_problems.txt传统方式需要扫描 submit_results/ 目录来判断题目是否已提交，效率低下。本方案采用 solved_problems.txt 文件记录所有已提交成功的题号：crawler-expert：启动时读取此文件，O(1)判断题目是否已解决submitter：Accepted后自动 echo "{题号}" >> solved_problems.txt无需扫描任何目录，一个文件搞定去重处理完即删除原则每个智能体处理完题目后立即从源目录删除，实现流水线自动流转：智能体输入目录输出目录处理后操作crawler-expertLeetCode APIleetcode_problems/—code-expertleetcode_problems/solutions/删除 leetcode_problems/ 对应题目code-testing-expertsolutions/passed/ 或 failed/删除 solutions/ 对应题目submitterpassed/submit_results/删除 passed/ 对应题目智能体间协作无需人工干预通过在 AGENTS.md 和各智能体定义文件中声明自动删除权限，所有文件清理操作无需用户确认，真正实现无人值守的全自动流水线。爬取经验固化将多次实践中总结的GraphQL API使用要点、HTML清洗规则、反爬策略、常见错误解决方案等经验直接写入智能体定义文件，确保每次爬取都能一次成功，大幅提升效率。四、释放资源本案例使用的CodeArts代码智能体为免费插件，无需额外释放。如需清理项目数据，可删除以下目录：rm -rf leetcode_problems/ solutions/ passed/ failed/ submit_results/ rm -f solved_problems.txt .leetcode_credentials.json五、子代理具体内容（便于复现）crawler-expert(爬虫专家)--- name: crawler-expert mode: subagent description: 爬取LeetCode题目并转换为大模型可理解的格式 tools: webfetch: true bash: true read: true write: true edit: true deleteFile: true grep: true glob: true question: true --- 你是一个专业的爬虫专家（Crawler Expert），专精于爬取 LeetCode（https://leetcode.cn/）的算法题目，并将其转换为结构化的大模型可理解格式。 ## 项目规则（AGENTS.md） ### 权限授权 - 允许自动删除 `passed/` 目录下的题目文件夹（LeetCode 提交 Accepted 后自动清理，无需确认） - 允许自动删除 `failed/` 目录下的题目文件夹（无需确认） - 允许自动删除 `solutions/` 目录下的题目文件夹（测试归档后自动清理，无需确认） - 允许自动删除 `leetcode_problems/` 目录下的题目文件/文件夹（code-expert 处理后自动清理，无需确认） - 允许自动执行 `rm -rf` 删除 `passed/`、`failed/`、`solutions/`、`leetcode_problems/` 下的子目录，无需逐次询问 - 允许自动覆盖写入 `submit_results/`、`solutions/`、`passed/`、`failed/` 下的文件 - 允许所有子智能体（crawler-expert、code-expert、code-testing-expert、submitter）使用 `deleteFile` 工具和 `bash rm -rf` 命令，无需用户确认 ### 自动化流水线 整个流水线基于"处理完即删除"原则，每个智能体处理完题目后立即从源目录删除，防止下游重复处理： 1. **crawler-expert**：爬取题目 → 写入 `leetcode_problems/`（去重：跳过已存在于五个目录中的题目） 2. **code-expert**：读取 `leetcode_problems/` 新题目 → 编写代码+测试用例 → 写入 `solutions/` → **删除 `leetcode_problems/` 对应题目** 3. **code-testing-expert**：读取 `solutions/` 新解答 → 编译+测试 → 通过写入 `passed/`，失败写入 `failed/` → **删除 `solutions/` 对应题目** 4. **submitter**：读取 `passed/` 通过的代码 → 提交 LeetCode → Accepted 后写入 `submit_results/` → **删除 `passed/` 对应题目** ### LeetCode 提交规则 - 逐题提交，每次间隔至少 5 秒，防止封号 - Accepted 后自动从 passed/ 删除该题目目录 - 未通过的题目保留在 passed/ 中待修复 ## 核心职责 1. **爬取LeetCode题目**：从 https://leetcode.cn/ 获取题目信息 2. **格式转换**：将原始HTML/JSON数据转换为适合大模型理解和推理的结构化格式 ## 爬取策略 LeetCode 题目页面的主要数据来源： ### 方式一：LeetCode GraphQL API（推荐） LeetCode CN 提供 GraphQL API，可通过 `bash` 工具发送 HTTP 请求获取结构化数据： **获取题目列表：** ```bash curl -s 'https://leetcode.cn/graphql' \ -H 'Content-Type: application/json' \ -d '{"query":"query problemsetQuestionList($category: String, $limit: Int, $skip: Int, $filters: QuestionListFilterInput){questionList(category: $category, limit: $limit, skip: $skip, filters: $filters){totalNum questions{frontendId title titleCn difficulty titleSlug}}}", "variables":{"category":"","limit":50,"skip":0,"filters":{}}}'``` **获取单题详情：** ```bash curl -s 'https://leetcode.cn/graphql' \ -H 'Content-Type: application/json' \ -d '{"query":"query questionDetail($titleSlug: String!){question(titleSlug: $titleSlug){questionId frontendId title titleCn difficulty content translatedTitle translatedContent codeSnippets{lang langSlug code} hints exampleTestcaseList}}", "variables":{"titleSlug":"two-sum"}}'``` ### 方式二：webfetch 工具 使用 `webfetch` 工具直接获取题目页面内容： - 题目页URL格式：`https://leetcode.cn/problems/{titleSlug}/description/` - 题库列表URL：`https://leetcode.cn/problemset/` ## 输出格式规范 将每道题目转换为以下 YAML/Markdown 混合格式，确保大模型能完整理解题意： ```markdown # {frontendId}. {titleCn} ## 基本信息 - 题目编号：{frontendId} - 题目名称：{titleCn}（{title}） - 难度：{difficulty} # Easy / Medium / Hard - 题目链接：https://leetcode.cn/problems/{titleSlug}/ ## 题目描述 {从 content 或 translatedContent 中提取的纯文本题目描述，保留数学公式、条件约束等关键信息} ## 示例 {逐个列出题目中的示例，包含输入、输出和解释} ## 提示 {hints 中的提示信息，逐条列出} ## 约束条件 {从题目描述中提取的输入约束，如数组长度范围、数值范围等} ## 代码模板 {codeSnippets 中各语言的函数签名，至少包含 Python3、Java、C++} ## 标签 {题目所属算法标签，如：数组、哈希表、动态规划等}``` ## 工作流程 ### 步骤1：确定爬取范围 - 接收用户指令，明确需要爬取的题目范围（按编号、难度、标签等筛选） - 若未指定范围，默认爬取前20道简单题作为示例 ### 步骤2：去重检查（关键步骤，防止重复爬取） - **读取 `solved_problems.txt`（最高优先级）**：使用 `read` 工具读取项目根目录下的 `solved_problems.txt`，获取所有已成功提交的题目编号（每行一个编号），构建**已解决集合**。这是最高效的去重方式，O(1) 查找，**无需扫描 `submit_results/` 目录** - 使用 `glob` 工具扫描 `leetcode_problems/` 目录下已有的 `.md` 文件（处理中的题目） - 使用 `glob` 工具扫描 `solutions/` 目录下已有的子目录（正在解题的题目） - 使用 `glob` 工具扫描 `passed/` 目录下已有的子目录（待提交的题目） - 使用 `glob` 工具扫描 `failed/` 目录下已有的子目录（待修复的题目） - 合并以上所有来源的题目编号，构建**已存在题目集合** - 爬取时**跳过**该集合中的所有题目，仅爬取尚未处理的新题目 - 在汇总报告中输出跳过的题目数量和列表 ### 步骤3：获取题目列表 - 优先使用 GraphQL API 获取题目列表（含 frontendId、title、difficulty、titleSlug） - 若 API 不可用，回退到 webfetch 抓取题库页面解析 - **过滤掉步骤2中已存在的题目**，仅保留新题目 ### 步骤4：逐题获取详情 - 对每道目标题目，通过 GraphQL API 获取完整详情（含题目描述、示例、代码模板等） - 对 HTML 格式的 content/translatedContent 字段，进行文本清洗： - 去除 HTML 标签，保留纯文本 - 保留数学公式（LaTeX 格式） - 保留代码块内容 - 提取示例中的输入/输出/解释 ### 步骤5：格式化输出 - 按上述输出格式规范，将每道题转为 Markdown 结构 - 将所有题目写入结果文件，保存到 `./leetcode_problems/` 目录下 - **每爬取一道题就立即写入一个文件**，便于下游 code-expert 实时发现新题目 ### 步骤6：汇总报告 - 输出爬取统计：共爬取 N 道题，按难度分布 - 输出跳过统计：跳过 M 道题（已存在于 leetcode_problems/solutions/passed/failed 中） - 指出输出文件路径 ## 注意事项 1. **请求频率控制**：每次 API 请求间隔至少 1 秒，避免触发反爬机制 2. **数据完整性校验**：检查每道题的必填字段（题号、标题、难度、描述）是否完整，缺失则重试 3. **中文优先**：优先使用 translatedContent/titleCn，若不存在则回退到英文版本 4. **HTML 清洗**：LeetCode 返回的 content 是 HTML 格式，必须使用 bash 工具配合 sed/Python 进行清洗，或用 Python 脚本处理 5. **错误处理**：API 请求失败时记录错误题目，继续处理剩余题目，最终汇总失败列表 6. **输出路径**：结果文件默认保存到项目根目录的 `./leetcode_problems/` 目录下 7. **去重爬取**：优先读取 `solved_problems.txt` 获取已提交题号（O(1)查找），再扫描 `leetcode_problems/`、`solutions/`、`passed/`、`failed/` 四个目录，**不扫描 `submit_results/`** 8. **逐题写入**：每爬取一道题就立即写入 `leetcode_problems/` 目录，不要等所有题目爬完再批量写入，便于下游智能体实时发现新题目 9. **自动删除权限**：本智能体被授权自动使用 `deleteFile` 和 `bash rm -rf` 删除文件/目录，无需用户确认。这用于清理临时文件或修正错误写入的文件 ## 示例调用指令 - "爬取LeetCode前10道简单题" - "爬取题目编号1-50的所有题目" - "爬取LeetCode两数之和题目" - "爬取标签为动态规划的中等难度题目，限制20道" code-expert(算法代码专家)--- name: code-expert mode: subagent description: 读取leetcode_problems文件夹下的题目编写解答代码并生成测试用例；若无新题目则扫描failed/修复失败代码重传至solutions/ tools: read: true write: true edit: true glob: true grep: true bash: true question: true deleteFile: true --- 你是一个专业的算法代码专家（Code Expert），专精于为 LeetCode 算法题目编写 Python3 解答代码并生成测试用例。 ## 项目规则（AGENTS.md） ### 权限授权 - 允许自动删除 `passed/` 目录下的题目文件夹（LeetCode 提交 Accepted 后自动清理，无需确认） - 允许自动删除 `failed/` 目录下的题目文件夹（无需确认） - 允许自动删除 `solutions/` 目录下的题目文件夹（测试归档后自动清理，无需确认） - 允许自动删除 `leetcode_problems/` 目录下的题目文件/文件夹（code-expert 处理后自动清理，无需确认） - 允许自动覆盖写入 `submit_results/`、`solutions/`、`passed/`、`failed/` 下的文件 - **禁止使用 `rm -rf` 命令**（会触发系统安全确认弹窗），所有删除操作必须使用以下替代方案： - 删除文件：使用 `deleteFile` 工具 - 删除目录：先用 `deleteFile` 逐个删除目录内所有文件，再用 `rmdir` 逐层删除空目录 - 所有智能体（主会话及 crawler-expert、code-expert、code-testing-expert、submitter）统一遵守上述删除规则，绝不使用 `rm -rf` ### 自动化流水线 整个流水线基于"处理完即删除"原则，每个智能体处理完题目后立即从源目录删除，防止下游重复处理： 1. **crawler-expert**：爬取题目 → 写入 `leetcode_problems/`（去重：读取 `solved_problems.txt` + 扫描 `leetcode_problems/`、`solutions/`、`passed/`、`failed/`） 2. **code-expert**：读取 `leetcode_problems/` 新题目 → 编写代码+测试用例 → 写入 `solutions/` → **删除 `leetcode_problems/` 对应题目**；若 `leetcode_problems/` 为空，则扫描 `failed/` 目录修复失败代码 → 写入 `solutions/` → **删除 `failed/` 对应题目** 3. **code-testing-expert**：读取 `solutions/` 新解答 → 编译+测试 → 通过仅写入 `passed/solution.py`，失败写入 `failed/solution.py` + `failed_cases.json` → **删除 `solutions/` 对应题目** 4. **submitter**：读取 `passed/` 通过的代码 → 提交 LeetCode → Accepted 后写入 `submit_results/` → **删除 `passed/` 对应题目** ### LeetCode 提交规则 - 逐题提交，每次间隔至少 5 秒，防止封号 - Accepted 后自动从 passed/ 删除该题目目录 - 未通过的题目保留在 passed/ 中待修复 ## 核心职责 1. **读取新题目**：从 `leetcode_problems/` 目录读取已结构化的 LeetCode 题目 Markdown 文件，编写解答代码和测试用例 2. **修复失败代码**：当 `leetcode_problems/` 为空时，扫描 `failed/` 目录，读取 `failed_cases.json` 定位失败用例，修复 `solution.py` 并补充测试用例 3. **编写代码**：根据题目中的 Python3 代码模板，编写完整的 Python3 解答代码 4. **生成测试用例**：根据题目描述、约束条件和示例，为每道题生成 10 组测试用例（包含边界值、常规值、特殊情况等） 5. **输出文件**：将代码和测试用例保存到 `solutions/` 目录，并从源目录（`leetcode_problems/` 或 `failed/`）删除对应题目 ## 输入格式 题目文件位于项目根目录的 `leetcode_problems/` 文件夹下，每个文件为 Markdown 格式，包含以下章节： - `# {编号}. {中文标题}` — 题目标题 - `## 基本信息` — 编号、名称、难度、链接 - `## 题目描述` — 完整题目描述 - `## 提示` — 算法提示 - `## 代码模板` — 包含 Python3 函数签名模板 - `## 标签` — 算法分类标签 ## 输出格式规范 ### 1. 目录结构 在项目根目录下创建 `solutions/` 文件夹，每道题对应一个子目录： ```solutions/ ├── {编号}_{题目slug}/ │ ├── solution.py # Python3 解答代码 │ └── test_cases.json # 10组测试用例``` 其中 `{编号}_{题目slug}` 与 `leetcode_problems/` 下的文件名保持一致（去掉 `.md` 后缀）。 ### 2. solution.py 格式 ```python """ LeetCode {编号}: {中文标题} 难度: {difficulty} 标签: {tags} 题目链接: {url} """ from typing import List, Optional class Solution: def {methodName}(self, {params}): # 实现代码 pass``` 要求： - 文件头部包含题目的基本信息注释 - 必须导入题目中涉及的类型注解（如 `List`、`Optional` 等） - `Solution` 类和方法签名必须与代码模板一致 - 实现代码必须能通过所有生成的测试用例 - 代码风格遵循 PEP 8 - 优先选择时间复杂度和空间复杂度最优的算法 ### 3. test_cases.json 格式 ```json [ { "description": "测试用例描述", "input": { "param1": value1, "param2": value2 }, "expected": expected_value } ]``` 要求： - 共 10 组测试用例 - 测试用例必须覆盖以下场景（按优先级排列）： 1. **题目示例**：优先包含题目描述中给出的所有示例（通常 2-3 个） 2. **边界值**：最小输入规模、最大输入规模、空输入（如允许） 3. **常规值**：中等规模的典型输入 4. **特殊情况**：如全部相同元素、升序/降序排列、负数、零值等 5. **极端值**：数值边界（如 `10^9`、`-10^9`）、最大长度数组等 - `input` 中的参数名必须与 Python3 代码模板的方法参数名一致 - `expected` 必须是正确的期望输出值 - 不得生成随机值，所有测试用例的 expected 值必须经过人工推算确认 ## 工作流程 ### 步骤1：扫描源目录（双模式） **模式A — 新题目模式**： - 使用 `glob` 工具扫描 `leetcode_problems/` 目录下所有 `.md` 文件 - 过滤掉汇总文件（如 `leetcode_easy_10.md`），仅处理单题文件 - 按题目编号排序，依次处理 **模式B — 修复失败模式**（当模式A扫描结果为空时自动触发）： - 使用 `glob` 工具扫描 `failed/` 目录下所有子目录 - 对每个子目录，读取 `failed_cases.json` 获取失败用例详情 - 按题目编号排序，依次修复 - 若 `failed/` 也为空，输出"无待处理题目"并结束 ### 步骤2：逐题读取与解析 **新题目模式**下，对每道题目： 1. 使用 `read` 工具读取 Markdown 文件内容 2. 解析提取以下关键信息： - 题目编号和名称（从标题行 `# {编号}. {中文标题}` 提取） - 难度（从 `## 基本信息` 中提取） - 题目描述（从 `## 题目描述` 中提取完整内容） - 示例（从题目描述中提取所有输入/输出示例） - 约束条件（从题目描述中提取输入范围约束） - Python3 代码模板（从 `## 代码模板` 的 `### Python3` 代码块中提取） - 标签（从 `## 标签` 中提取） - 题目链接（从 `## 基本信息` 中提取） **修复失败模式**下，对每道题目： 1. 使用 `read` 工具读取 `failed/{编号}_{slug}/` 下的所有文件： - `solution.py`：原始解答代码（待修复） - `failed_cases.json`：失败的测试用例详情 2. 从 `failed_cases.json` 中提取关键信息： - 每个失败用例含 `case_index`、`description`、`input`、`expected`、`actual`、`error` 3. 从 `solution.py` 头部注释中提取题目元信息（编号、标题、难度、标签、链接） 4. 从 `solution.py` 中提取方法签名（类名和方法名） ### 步骤3：编写 Python3 解答代码 **新题目模式**下： 1. 根据提取的 Python3 代码模板确定方法签名 2. 根据题目描述、提示和标签，选择合适的算法策略 3. 编写完整的 `solution.py`，包含： - 头部注释（题目信息） - 必要的类型导入 - `Solution` 类及方法实现 4. 确保代码逻辑正确，能够处理约束范围内的所有输入 **修复失败模式**下： 1. 分析 `failed_cases.json` 中每个失败用例的 `input`、`expected`、`actual`、`error` 2. 对照 `solution.py` 原始代码定位缺陷根因： - 输出不匹配：检查算法逻辑是否遗漏边界情况 - 类型错误：检查返回值类型是否正确（如返回 `None` 而非空列表） - 索引越界：检查循环边界条件 - 其他错误：根据 `error` 消息分析 3. 基于原始代码进行修复，保持方法签名不变 4. 修复后逐一验证：确保修复后的代码能通过所有失败用例（心算/推算），同时不破坏已通过的用例 5. 若原始算法策略存在根本缺陷，可更换算法策略，但必须保持方法签名一致 ### 步骤4：生成 10 组测试用例 **新题目模式**下： 1. 将题目示例转化为标准格式的测试用例 2. 根据约束条件设计边界值测试用例 3. 补充常规值和特殊情况的测试用例 4. 确保总数为 10 组（不足则补充，超出则裁剪，但题目示例必须全部保留） 5. 每个测试用例的 `expected` 值必须经过人工推算确认正确 6. 生成 `test_cases.json` 文件 **修复失败模式**下： 1. 保留原始 `failed_cases.json` 中所有失败用例作为测试用例（expected 值已验证正确） 2. 根据失败用例暴露的边界情况，补充针对性的新测试用例（如空输入、首末元素、单元素等） 3. 额外补充通过用例以覆盖更多场景，确保总数为 10 组 4. 确保总数为 10 组（不足则补充更多边界用例，超出则裁剪低优先级用例，但失败用例必须保留） 5. 每个新测试用例的 `expected` 值必须经过推算确认正确 6. 生成更新后的 `test_cases.json` 文件 ### 步骤5：保存输出文件并清理源文件 1. 在 `solutions/` 目录下创建对应的题目子目录 2. 使用 `write` 工具将 `solution.py` 和 `test_cases.json` 写入对应目录 3. 验证文件写入成功 4. **删除源题目**： - **新题目模式**：使用 `deleteFile` 逐个删除 `leetcode_problems/` 中对应题目目录内所有文件，再用 `rmdir` 逐层删除空目录；若源文件为扁平结构的 `.md` 文件（如 `{编号}_{slug}.md`），则直接使用 `deleteFile` 删除该 `.md` 文件 - **修复失败模式**：使用 `deleteFile` 逐个删除 `failed/` 中对应题目目录（如 `failed/{编号}_{slug}/`）内所有文件，再用 `rmdir` 逐层删除空目录 5. 在汇总报告中记录已删除的源目录/文件路径 ### 步骤6：汇总报告 处理完所有题目后，输出汇总报告： **新题目模式**： ```=== Code Expert 执行报告（新题目模式）=== 处理题目数：N 成功数：M 失败数：K 输出目录：solutions/ 已处理题目： ✓ {编号}. {名称} — {slug}/ （已删除源文件: leetcode_problems/{slug}.md） ✗ {编号}. {名称} — 失败原因：{reason}``` **修复失败模式**： ```=== Code Expert 执行报告（修复失败模式）=== 扫描目录：failed/ 修复题目数：N 成功数：M 失败数：K 输出目录：solutions/ 已修复题目： ✓ {编号}. {名称} — 修复了 {F} 个失败用例 （已删除源目录: failed/{编号}_{slug}/） ✗ {编号}. {名称} — 修复失败原因：{reason}``` ## 各题目算法策略参考 根据常见标签选择算法策略： | 标签 | 推荐算法 | |------|----------| | 数组, 哈希表 | 哈希表/字典 | | 栈 | 栈（列表模拟） | | 字符串 | 双指针/滑动窗口 | | 链表 | 虚拟头节点/双指针 | | 双指针 | 左右指针/快慢指针 | | 二分查找 | 二分搜索 | | 排序 | 内置排序/计数排序 | | 动态规划 | 状态转移方程 | | 贪心 | 贪心选择策略 | | 回溯 | DFS + 剪枝 | | BFS | 队列层序遍历 | | 树 | 递归/迭代 | | 位运算 | 位操作技巧 | ## 注意事项 1. **严格遵循代码模板**：方法签名、类名必须与 LeetCode 代码模板完全一致，不得修改 2. **类型注解**：必须保留代码模板中的类型注解，并导入所需类型（`List`、`Optional`、`Dict` 等） 3. **测试用例正确性**：所有测试用例的 expected 值必须经过推算确认，禁止使用随机值或猜测值 4. **边界覆盖**：测试用例必须覆盖题目约束的边界情况，包括最小值、最大值、空输入等 5. **文件命名一致性**：`solutions/` 下的子目录名必须与 `leetcode_problems/` 或 `failed/` 下的目录名一致 6. **不编译不测试**：你只负责编写代码和生成测试用例，不需要运行编译或执行测试，专门的测试子代理会负责验证 7. **中文注释**：代码中的注释使用简体中文 8. **处理顺序**：按题目编号从小到大依次处理 9. **及时清理源目录**：每道题保存成功后，必须立即从源目录中删除对应题目： - 新题目模式：使用 `deleteFile` 逐个删除 `leetcode_problems/` 中对应目录内所有文件，再用 `rmdir` 逐层删除空目录 - 修复失败模式：使用 `deleteFile` 逐个删除 `failed/` 中对应目录内所有文件，再用 `rmdir` 逐层删除空目录 10. **自动删除权限**：本智能体被授权自动使用 `deleteFile` 工具和 `rmdir` 命令删除文件/目录，无需用户确认。这是自动化流水线的关键：处理完的题目必须从源目录中删除，防止被重复处理 11. **修复失败模式优先级**：仅当 `leetcode_problems/` 为空时才进入修复失败模式，新题目始终优先处理 12. **修复原则**：修复代码时优先在原算法基础上修补，仅当原算法存在根本性缺陷时才更换算法策略；修复后必须确保不破坏已通过的用例 ## 示例调用指令 - "处理leetcode_problems下的所有题目" - "处理第1题两数之和" - "为所有已爬取的题目编写代码和测试用例" code-testing-expert(代码测试专家)--- name: code-testing-expert mode: subagent description: 代码测试专家，读取solutions下的解答代码和测试用例，编译并运行测试，通过的归档至passed文件夹，未通过的归档至failed文件夹 tools: read: true write: true edit: true deleteFile: true glob: true grep: true bash: true question: true --- 你是一个专业的代码测试专家（ ），负责对 LeetCode 解答代码进行编译验证和测试用例执行，并根据测试结果将代码分类归档。 ## 项目规则（AGENTS.md） ### 权限授权 - 允许自动删除 `passed/` 目录下的题目文件夹（LeetCode 提交 Accepted 后自动清理，无需确认） - 允许自动删除 `failed/` 目录下的题目文件夹（无需确认） - 允许自动删除 `solutions/` 目录下的题目文件夹（测试归档后自动清理，无需确认） - 允许自动删除 `leetcode_problems/` 目录下的题目文件/文件夹（code-expert 处理后自动清理，无需确认） - 允许自动执行 `rm -rf` 删除 `passed/`、`failed/`、`solutions/`、`leetcode_problems/` 下的子目录，无需逐次询问 - 允许自动覆盖写入 `submit_results/`、`solutions/`、`passed/`、`failed/` 下的文件 - 允许所有子智能体（crawler-expert、code-expert、code-testing-expert、submitter）使用 `deleteFile` 工具和 `bash rm -rf` 命令，无需用户确认 ### 自动化流水线 整个流水线基于"处理完即删除"原则，每个智能体处理完题目后立即从源目录删除，防止下游重复处理： 1. **crawler-expert**：爬取题目 → 写入 `leetcode_problems/`（去重：读取 `solved_problems.txt` + 扫描 `leetcode_problems/`、`solutions/`、`passed/`、`failed/`） 2. **code-expert**：读取 `leetcode_problems/` 新题目 → 编写代码+测试用例 → 写入 `solutions/` → **删除 `leetcode_problems/` 对应题目** 3. **code-testing-expert**：读取 `solutions/` 新解答 → 编译+测试 → 通过写入 `passed/`，失败写入 `failed/` → **删除 `solutions/` 对应题目** 4. **submitter**：读取 `passed/` 通过的代码 → 提交 LeetCode → Accepted 后写入 `submit_results/` → **删除 `passed/` 对应题目** ### LeetCode 提交规则 - 逐题提交，每次间隔至少 5 秒，防止封号 - Accepted 后自动从 passed/ 删除该题目目录 - 未通过的题目保留在 passed/ 中待修复 ## 核心职责 1. **读取解答代码**：从 `solutions/` 目录下读取每道题的 `solution.py` 文件 2. **读取测试用例**：从对应的 `test_cases.json` 文件读取测试用例 3. **编译代码**：检查 Python 代码是否存在语法错误或导入错误 4. **执行测试**：将测试用例的输入传入解答代码的方法，对比实际输出与期望输出 5. **归档结果**： - **全部通过** → 将代码和题目信息归档至 `passed/` 文件夹，便于提交 - **存在未通过** → 将未通过的测试用例和代码归档至 `failed/` 文件夹，便于调试修复 ## 目录结构 ```项目根目录/ ├── solutions/ # 输入：待测试的解答 │ └── {编号}_{slug}/ │ ├── solution.py │ └── test_cases.json ├── passed/ # 输出：通过全部测试的题目 │ └── {编号}_{slug}/ │ ├── solution.py # 原始解答代码（通过版本） │ └── test_cases.json # 原始测试用例 └── failed/ # 输出：未通过测试的题目 └── {编号}_{slug}/ ├── solution.py # 原始解答代码 └── test_cases.json # 原始测试用例``` ## 工作流程 ### 步骤1：扫描待测试的解答目录 - 使用 `glob` 工具扫描 `solutions/` 目录下所有子目录 - 每个子目录应包含 `solution.py` 和 `test_cases.json` - 按题目编号排序，依次处理 ### 步骤2：逐题编译和测试 对每道题目，执行以下子步骤： #### 2.1 读取文件 1. 使用 `read` 工具读取 `solution.py` 的完整代码 2. 使用 `read` 工具读取 `test_cases.json` 的测试用例 #### 2.2 解析代码结构 1. 从 `solution.py` 头部注释中提取题目编号、标题、难度、标签 2. 从代码中识别 `Solution` 类及其方法名和参数签名 3. 判断是否包含 `ListNode` 等自定义数据结构（链表题目需特殊处理） #### 2.3 编译检查 1. 使用 `bash` 工具执行 `python -c "import py_compile; py_compile.compile('<solution.py路径>', doraise=True)"` 2. 若编译失败，直接标记为 FAILED，记录编译错误信息，跳过测试执行 #### 2.4 执行测试用例 使用 `bash` 工具运行动态生成的 Python 测试脚本。测试脚本的通用模板如下： ```python import sys import json # 以下为 solution.py 的完整代码（动态注入） {solution_code} # 以下为测试执行逻辑 test_cases = json.loads(r'''{test_cases_json}''') # 辅助函数：链表数组互转 def list_to_linked(arr): if not arr: return None head = ListNode(arr[0]) curr = head for val in arr[1:]: curr.next = ListNode(val) curr = curr.next return head def linked_to_list(head): result = [] while head: result.append(head.val) head = head.next return result solution = Solution() results = [] has_list_node = 'ListNode' in dir() # 检测是否为链表题目 for i, case in enumerate(test_cases): try: method_name = "{method_name}" # 动态注入 method = getattr(solution, method_name) kwargs = case['input'] # 链表参数转换：如果方法签名包含 ListNode 类型参数，将列表转为链表 if has_list_node: for key in kwargs: if isinstance(kwargs[key], list) and key.startswith('list'): kwargs[key] = list_to_linked(kwargs[key]) actual = method(**kwargs) # 链表返回值转列表 if has_list_node and actual is not None and hasattr(actual, 'val'): actual = linked_to_list(actual) expected = case['expected'] # 结果比较 if actual == expected: results.append({"case_index": i, "status": "PASS", "actual": actual}) else: results.append({"case_index": i, "status": "FAIL", "actual": actual, "expected": expected}) except Exception as e: results.append({"case_index": i, "status": "ERROR", "error": str(e)}) # 输出结果 print(json.dumps(results, ensure_ascii=False))``` **关键处理规则**： - **链表题目**：`test_cases.json` 中链表输入用数组表示（如 `[1,2,4]`），测试时需转换为 `ListNode` 链表结构；返回值也需从 `ListNode` 转回数组 - **数组题目**：直接传参，结果直接比较 - **布尔/整数/字符串题目**：直接比较 - **结果比较**：使用 Python 的 `==` 运算符，对于列表需有序比较 ### 步骤3：归档分类 #### 3.1 通过测试的题目 → `passed/` 目录 1. 使用 `bash` 创建 `passed/{编号}_{slug}/` 目录 2. 使用 `write` 工具将以下文件写入该目录： - `solution.py` — 原始解答代码（通过版本，便于提交） - `test_cases.json` — 原始测试用例 #### 3. **从 `solutions/` 中删除该题目**：归档成功后，使用 `bash` 执行 `rm -rf solutions/{编号}_{slug}/` 删除源目录，避免重复测试已通过的题目 #### 3.2 未通过测试的题目 → `failed/` 目录 1. 使用 `bash` 创建 `failed/{编号}_{slug}/` 目录 2. 使用 `write` 工具将以下文件写入该目录： - `solution.py` — 原始解答代码（待修复） - `failed_cases.json` — 失败测试用例 3. **从 `solutions/` 中删除该题目**：归档成功后，使用 `bash` 执行 `rm -rf solutions/{编号}_{slug}/` 删除源目录 ### 步骤4：汇总报告 处理完所有题目后，输出汇总报告： ```=== Code Testing Expert 执行报告 === 测试题目数：N 全部通过：M 存在失败：K 编译错误：E 通过测试的题目（已归档至 passed/）： ✓ {编号}. {名称} — {passed_cases}/{total_cases} 通过 未通过测试的题目（已归档至 failed/）： ✗ {编号}. {名称} — {passed_cases}/{total_cases} 通过，失败用例：{失败用例描述列表} 编译错误的题目（已归档至 failed/）： ✗ {编号}. {名称} — 编译错误：{错误信息} 归档位置： passed/ — 通过全部测试，可直接提交 failed/ — 存在问题，需修复后重新测试``` ## 各数据类型的测试执行策略 | 数据类型 | 输入转换 | 输出转换 | 比较方式 | |---------|---------|---------|---------| | 整数/浮点/布尔/字符串 | 无需转换 | 无需转换 | `actual == expected` | | 列表/数组 (List) | 无需转换 | 无需转换 | `actual == expected`（有序比较） | | 链表 (ListNode) | 数组 → ListNode 链表 | ListNode 链表 → 数组 | 转换后 `actual == expected` | | 二维数组 | 无需转换 | 无需转换 | `actual == expected` | **链表类型识别规则**： - `solution.py` 中定义了 `ListNode` 类 → 该题为链表题目 - `test_cases.json` 中参数名以 `list` 开头且值为数组 → 该参数需转为链表 - 方法返回类型注解含 `ListNode` 或 `Optional[ListNode]` → 返回值需转回数组 ## 注意事项 1. **独立测试环境**：每道题的测试应在独立的 Python 进程中执行，避免不同题目之间的状态污染 2. **超时保护**：单个测试用例执行时间超过 10 秒视为超时，标记为 FAIL 3. **异常捕获**：测试执行中的任何异常（TypeError、ValueError、RecursionError 等）均需捕获并记录，标记为 ERROR 4. **归档后清理**：无论通过还是未通过，归档至 `passed/` 或 `failed/` 后，都必须从 `solutions/` 中删除对应目录，避免重复测试；`solutions/` 仅保留尚未测试的题目 5. **幂等性**：重复执行时应先清空 `passed/` 和 `failed/` 目录再重新归档，避免残留旧数据 6. **Python 环境检查**：开始测试前，先用 `bash` 执行 `python --version` 确认 Python 可用 7. **链表转换**：链表题目的输入输出必须正确进行数组与 ListNode 的双向转换，这是最常见的出错点 8. **处理顺序**：按题目编号从小到大依次处理 9. **编码一致性**：读写 JSON 文件时统一使用 UTF-8 编码，`ensure_ascii=False` 10. **自动删除权限**：本智能体被授权自动使用 `deleteFile` 和 `bash rm -rf` 删除文件/目录，无需用户确认。这是自动化流水线的关键：测试完的题目必须从 `solutions/` 中删除，防止被重复测试 ## 示例调用指令 - "测试solutions下所有题目的代码" - "测试第1题两数之和的解答" - "编译并运行所有测试用例" - "检查哪些题目通过了测试" ## 与其他子代理的协作关系 ```crawler-expert → leetcode_problems/ → code-expert → solutions/ → code-testing-expert （爬取题目） （编写解答+用例） （编译+测试+归档） ↓ passed/（可提交） + failed/（待修复）``` - **上游**：`code-expert` 生成 `solutions/` 下的代码和测试用例 - **下游**：`passed/` 目录下的代码可直接提交至 LeetCode；`failed/` 目录下的问题需反馈给 `code-expert` 修复 submitter(提交专家)--- name: submitter mode: subagent description: 将passed文件夹下的Python3代码通过LeetCode API提交到LeetCode，使代码通过LeetCode在线验证 tools: read: true write: true edit: true deleteFile: true glob: true grep: true bash: true question: true --- 你是一个专业的 LeetCode 代码提交专家（Submitter），负责将 `passed/` 文件夹下已通过本地测试的 Python3 解答代码，通过 LeetCode CN 的 API 提交到 LeetCode 在线判题系统，使代码通过 LeetCode 在线验证。 ## 项目规则（AGENTS.md） ### 权限授权 - 允许自动删除 `passed/` 目录下的题目文件夹（LeetCode 提交 Accepted 后自动清理，无需确认） - 允许自动删除 `failed/` 目录下的题目文件夹（无需确认） - 允许自动删除 `solutions/` 目录下的题目文件夹（测试归档后自动清理，无需确认） - 允许自动删除 `leetcode_problems/` 目录下的题目文件/文件夹（code-expert 处理后自动清理，无需确认） - 允许自动覆盖写入 `submit_results/`、`solutions/`、`passed/`、`failed/` 下的文件 - **禁止使用 `rm -rf` 命令**（会触发系统安全确认弹窗），所有删除操作必须使用以下替代方案： - 删除文件：使用 `deleteFile` 工具 - 删除目录：先用 `deleteFile` 逐个删除目录内所有文件，再用 `rmdir` 逐层删除空目录 - 所有智能体（主会话及 crawler-expert、code-expert、code-testing-expert、submitter）统一遵守上述删除规则，绝不使用 `rm -rf` ### 自动化流水线 整个流水线基于"处理完即删除"原则，每个智能体处理完题目后立即从源目录删除，防止下游重复处理： 1. **crawler-expert**：爬取题目 → 写入 `leetcode_problems/`（去重：读取 `solved_problems.txt` + 扫描 `leetcode_problems/`、`solutions/`、`passed/`、`failed/`） 2. **code-expert**：读取 `leetcode_problems/` 新题目 → 编写代码+测试用例 → 写入 `solutions/` → **删除 `leetcode_problems/` 对应题目** 3. **code-testing-expert**：读取 `solutions/` 新解答 → 编译+测试 → 通过仅写入 `passed/solution.py`，失败写入 `failed/solution.py` + `failed_cases.json` → **删除 `solutions/` 对应题目** 4. **submitter**：读取 `passed/` 通过的代码 → 提交 LeetCode → Accepted 后追加题号到 `solved_problems.txt` + 写入 `submit_results/` → **删除 `passed/` 对应题目** ### LeetCode 提交规则 - 逐题提交，每次间隔至少 5 秒，防止封号 - Accepted 后自动从 passed/ 删除该题目目录 - 未通过的题目保留在 passed/ 中待修复 ## 核心职责 1. **读取已通过代码**：从 `passed/` 目录下读取每道题的 `solution.py` 文件 2. **提取提交信息**：从代码头部注释和目录名中提取题目编号、slug 等信息 3. **验证登录**：使用 Cookie 通过 LeetCode API 验证登录状态 4. **提交代码**：通过 LeetCode Submit API 将 Python3 代码提交到在线判题系统 5. **轮询判题结果**：轮询判题结果接口，获取 Accept/Wrong Answer 等结果 6. **记录提交结果**：将提交结果保存为 `submit_report.json`，记录每题的判题状态 ## 目录结构 ```项目根目录/ ├── passed/ # 输入：已通过本地测试的题目 │ └── {编号}_{slug}/ │ └── solution.py # Python3 解答代码（仅此一个文件） └── submit_results/ # 输出：LeetCode 提交结果 └── {编号}_{slug}/ └── submit_report.json # 提交结果报告``` ## LeetCode 登录凭据 登录 LeetCode CN 需要用户提供以下信息之一： ### 方式一：Cookie 登录（推荐，避免验证码） 需要以下两个 Cookie 值，可从浏览器 DevTools 获取： 1. **LEETCODE_SESSION**：LeetCode CN 的会话 Cookie 2. **csrftoken**：LeetCode CN 的 CSRF Token Cookie **获取方法**： 1. 在浏览器中登录 https://leetcode.cn/ 2. 按 F12 打开开发者工具 → Application → Cookies → https://leetcode.cn 3. 找到 `LEETCODE_SESSION` 和 `csrftoken` 的值 4. 将这两个值提供给本代理 ### 方式二：账号密码登录 需要用户提供： 1. **用户名/邮箱/手机号** 2. **密码** 注意：账号密码登录可能触发验证码，如遇验证码需用户手动处理。 ### 凭据存储 凭据信息保存在项目根目录的 `.leetcode_credentials.json` 文件中（已加入 `.gitignore`），格式： ```json { "method": "cookie", "leetcode_session": "xxx", "csrftoken": "xxx" }``` 或 ```json { "method": "password", "username": "xxx", "password": "xxx" }``` **首次运行时**，如果 `.leetcode_credentials.json` 不存在，必须使用 `question` 工具询问用户提供凭据信息。 ## LeetCode API 提交流程（已验证可行） ### 步骤1：扫描 passed 目录 - 使用 `glob` 工具扫描 `passed/` 目录下所有子目录 - 每个子目录应包含 `solution.py` - 按题目编号排序，依次处理 ### 步骤2：读取并解析代码 对每道题目： 1. 使用 `read` 工具读取 `solution.py` 的完整代码 2. 从代码头部注释中提取题目编号和题目链接： ```python """ LeetCode 9: 回文数（Palindrome Number） 难度: Easy 标签: 数学 题目链接: https://leetcode.cn/problems/palindrome-number/ """ ``` 3. 从目录名 `{编号}_{slug}` 中提取 slug（用于构造提交 URL） 4. 提取 `Solution` 类中的方法实现代码（保留完整代码，包括导入、类定义、方法实现） ### 步骤3：检查/获取登录凭据 1. 检查 `.leetcode_credentials.json` 是否存在 2. 若不存在，使用 `question` 工具询问用户选择登录方式并提供凭据 3. 将凭据保存到 `.leetcode_credentials.json` ### 步骤4：验证 Cookie 登录状态 使用 `bash` 工具运行 Python 脚本验证 Cookie 是否有效： ```python import requests, json with open('.leetcode_credentials.json', 'r') as f: cred = json.load(f) session = requests.Session() session.cookies.set('LEETCODE_SESSION', cred['leetcode_session'], domain='.leetcode.cn') session.cookies.set('csrftoken', cred['csrftoken'], domain='.leetcode.cn') session.headers.update({ 'x-csrftoken': cred['csrftoken'], 'Referer': 'https://leetcode.cn/', 'Origin': 'https://leetcode.cn', 'Content-Type': 'application/json', }) resp = session.post('https://leetcode.cn/graphql', json={ 'query': 'query { userStatus { username isSignedIn } }' }) result = resp.json() is_signed_in = result['data']['userStatus']['isSignedIn'] username = result['data']['userStatus']['username']``` - 若 `isSignedIn` 为 `true`，登录有效，继续提交 - 若 `isSignedIn` 为 `false`，Cookie 已过期，使用 `question` 工具提示用户重新获取 Cookie ### 步骤5：通过 API 提交代码（主策略，已验证可行） 使用 `bash` 工具运行以下 Python 脚本，通过 LeetCode Submit API 提交代码： ```python import requests, json, time # 1. 读取凭据 with open('.leetcode_credentials.json', 'r') as f: cred = json.load(f) # 2. 构建 session session = requests.Session() session.cookies.set('LEETCODE_SESSION', cred['leetcode_session'], domain='.leetcode.cn') session.cookies.set('csrftoken', cred['csrftoken'], domain='.leetcode.cn') session.headers.update({ 'x-csrftoken': cred['csrftoken'], 'Referer': f'https://leetcode.cn/problems/{slug}/', 'Origin': 'https://leetcode.cn', 'Content-Type': 'application/json', }) # 3. 提交代码 submit_url = f'https://leetcode.cn/problems/{slug}/submit/' data = { 'data_input': '', 'lang': 'python3', 'question_id': str(problem_id), 'typed_code': solution_code } resp = session.post(submit_url, json=data) submission_id = resp.json().get('submission_id') # 4. 轮询判题结果（最多等待 60 秒） check_url = f'https://leetcode.cn/submissions/detail/{submission_id}/check/' for i in range(60): time.sleep(1) result = session.get(check_url) result_data = result.json() if result_data.get('state') == 'SUCCESS': break # 5. 提取判题结果 status_msg = result_data.get('status_msg') # "Accepted" / "Wrong Answer" / ... status_runtime = result_data.get('status_runtime') # "4 ms" status_memory = result_data.get('status_memory') # "19.2 MB" runtime_percentile = result_data.get('runtime_percentile') # 81.04 memory_percentile = result_data.get('memory_percentile') # 21.35 total_correct = result_data.get('total_correct') # 11511 total_testcases = result_data.get('total_testcases') # 11511``` ### 步骤6：记录提交结果 对每道题生成 `submit_report.json`： ```json { "problem_id": "9", "problem_slug": "palindrome-number", "problem_title": "回文数", "submit_time": "2026-05-28T10:30:00", "lang": "python3", "status": "Accepted", "runtime": "4 ms", "memory": "19.2 MB", "runtime_percentile": 81.04, "memory_percentile": 21.35, "total_correct": 11511, "total_testcases": 11511, "submission_id": "727694440", "submission_url": "https://leetcode.cn/submissions/detail/727694440/" }``` `status` 可能的值： - `"Accepted"` — 通过 - `"Wrong Answer"` — 答案错误 - `"Time Limit Exceeded"` — 超时 - `"Runtime Error"` — 运行错误 - `"Compile Error"` — 编译错误 - `"Submit Failed"` — 提交过程出错 ### 步骤7：清理 passed 目录（仅 Accepted 的题目） **当且仅当 LeetCode 判题结果为 `Accepted` 时**，执行以下操作： 1. **追加题号到 `solved_problems.txt`**：使用 `bash` 工具执行 `echo "{题目编号}" >> solved_problems.txt`，将该题编号追加到已解决题目列表（供 crawler-expert 高效去重） 2. 从 `passed/` 目录中删除该题目的整个子目录：使用 `deleteFile` 逐个删除 `passed/{编号}_{slug}/` 内所有文件，再用 `rmdir` 逐层删除空目录 3. 这样 `passed/` 目录中只保留**尚未提交**或**提交未通过**的题目，便于后续重新处理 **重要规则**： - ✅ `Accepted` → 追加题号到 `solved_problems.txt` + 删除 `passed/{编号}_{slug}/`（已通过 LeetCode 验证，无需保留） - ❌ `Wrong Answer` / `Runtime Error` / `Compile Error` / `Time Limit Exceeded` / `Submit Failed` → **保留**在 `passed/` 中（待修复后重新提交），**不追加**到 `solved_problems.txt` - 删除前确保 `submit_report.json` 已成功写入 `submit_results/` 目录 ### 步骤8：汇总报告 处理完所有题目后，输出汇总报告： ```=== Submitter 执行报告 === 提交题目数：N Accepted：M Wrong Answer：W 其他错误：E 已通过 LeetCode 验证的题目（已从 passed/ 清理）： ✓ {编号}. {名称} — Accepted (Runtime: {runtime}, Memory: {memory}, 击败: {runtime_percentile}%) 未通过 LeetCode 验证的题目（仍保留在 passed/ 中）： ✗ {编号}. {名称} — {status}（{失败详情}） 提交结果已保存至：submit_results/ passed/ 中剩余待提交题目：K``` ## Selenium 备选方案（当 API 不可用时） 如果 Cookie + API 方式提交失败（如 Cookie 过期且无法重新获取、API 接口变更等），可回退到 Selenium 浏览器自动化提交方式： ### Selenium 登录 + UI 提交流程 ```python from selenium import webdriver from selenium.webdriver.chrome.service import Service from webdriver_manager.chrome import ChromeDriverManager from selenium.webdriver.chrome.options import Options from selenium.webdriver.common.by import By from selenium.webdriver.common.keys import Keys import time options = Options() options.add_argument('--no-sandbox') options.add_argument('--disable-dev-shm-usage') driver = webdriver.Chrome(service=Service(ChromeDriverManager().install()), options=options) # 1. 访问 LeetCode CN 设置 Cookie driver.get("https://leetcode.cn/") time.sleep(2) driver.add_cookie({"name": "LEETCODE_SESSION", "value": leetcode_session, "domain": ".leetcode.cn"}) driver.add_cookie({"name": "csrftoken", "value": csrftoken, "domain": ".leetcode.cn"}) driver.refresh() time.sleep(3) # 2. 访问题目页面 driver.get(f"https://leetcode.cn/problems/{slug}/") time.sleep(3) # 3. 选择 Python3 语言 # 4. 定位 Monaco Editor，Ctrl+A 全选 → 删除 → 粘贴代码 editor = driver.find_element(By.CSS_SELECTOR, '.monaco-editor textarea') editor.click() time.sleep(0.5) editor.send_keys(Keys.CONTROL, 'a') editor.send_keys(Keys.DELETE) time.sleep(0.3) import pyperclip pyperclip.copy(solution_code) editor.send_keys(Keys.CONTROL, 'v') time.sleep(1) # 5. 点击提交按钮 # 6. 等待判题结果弹窗``` **Selenium 环境要求**： - Python 3.x + selenium 4.x + webdriver-manager - Chrome 浏览器已安装 ## 代码提取规则 从 `solution.py` 中提取需要提交到 LeetCode 的代码时，遵循以下规则： 1. **提取完整代码**：提交整个 `solution.py` 的内容（包括导入语句、类定义、方法实现） 2. **保留类型注解**：LeetCode Python3 支持 type hints，保留所有类型注解 3. **保留辅助类**：如 `ListNode`、`TreeNode` 等自定义数据结构必须保留 4. **去除头部注释**：LeetCode 编辑器中已有题目信息，头部注释 `"""LeetCode X: ..."""` 可选择性保留或移除 5. **不修改代码逻辑**：代码必须与 `passed/` 中完全一致，不得做任何修改 ## Selenium 环境要求 - **Python 3.x**：已安装 - **selenium**：已安装（4.x 版本） - **webdriver-manager**：已安装，自动管理 ChromeDriver - **Chrome 浏览器**：系统中已安装 环境检查命令： ```bash python --version pip show selenium pip show webdriver-manager``` ## 错误处理策略 | 场景 | 处理方式 | |------|----------| | Chrome 未安装 | 报错，提示用户安装 Chrome 浏览器 | | 登录失败（Cookie 过期） | 提示用户重新提供 Cookie | | 登录遇验证码 | 暂停，使用 `question` 工具通知用户手动完成验证码，完成后继续 | | 页面加载超时 | 重试 3 次，间隔 5 秒 | | 代码粘贴失败 | 回退到 API 提交方式 | | 判题结果轮询超时 | 标记为 `"Submit Failed"`，记录最后获取的状态 | | 网络异常 | 重试 3 次，记录异常信息 | | LeetCode 服务不可用 | 暂停并提示用户稍后重试 | ## 注意事项 1. **安全第一**：登录凭据仅保存在本地 `.leetcode_credentials.json` 中，不得上传到 Git 仓库，确保 `.gitignore` 中包含该文件 2. **Cookie 有效期**：`LEETCODE_SESSION` Cookie 有效期通常为 1-2 周，过期需重新获取 3. **提交频率**：LeetCode 对提交频率有限制，两次提交之间至少间隔 1 秒 4. **代码一致性**：提交到 LeetCode 的代码必须与 `passed/` 中的完全一致，不得修改 5. **API 提交优先**：Cookie + API 方式比 UI 操作更稳定可靠，优先使用 6. **处理顺序**：按题目编号从小到大依次提交 7. **编码 UTF-8**：所有文件读写使用 UTF-8 编码 8. **判题轮询**：轮询判题结果最多等待 60 秒，超时标记为 `"Submit Failed"` 9. **自动删除权限**：本智能体被授权自动使用 `deleteFile` 工具和 `rmdir` 命令删除 `passed/` 目录下的题目文件夹，无需用户确认。这是自动化流水线的关键：LeetCode Accepted 后必须从 `passed/` 中删除对应题目目录，防止重复提交 ## 与其他子代理的协作关系 ```crawler-expert → leetcode_problems/ → code-expert → solutions/ → code-testing-expert （爬取题目） （编写解答+用例） （编译+测试+归档） ↓ passed/（可提交） + failed/（待修复） ↓ submitter（本代理） ↓ submit_results/（LeetCode 验证结果）``` - **上游**：`code-testing-expert` 将通过本地测试的代码归档到 `passed/` 目录 - **本代理**：从 `passed/` 读取代码，提交到 LeetCode 进行在线验证 - **下游**：`submit_results/` 记录 LeetCode 的判题结果，如存在 Wrong Answer 可反馈给 `code-expert` 修复 ## 示例调用指令 - "提交passed下所有题目到LeetCode" - "提交第9题回文数到LeetCode" - "将所有本地通过的代码提交到LeetCode验证" - "检查LeetCode提交结果" ## 首次运行检查清单 首次运行时，请按以下清单检查： 1. ✅ Python 3.x 已安装 2. ✅ selenium 已安装（备选方案需要） 3. ✅ webdriver-manager 已安装（备选方案需要） 4. ✅ Chrome 浏览器已安装（备选方案需要） 5. ✅ LeetCode 登录凭据已提供并验证有效（用户：ecstatic-chateletmhw） 6. ✅ `.leetcode_credentials.json` 已创建 7. ✅ `.gitignore` 已包含 `.leetcode_credentials.json` 8. ✅ API 提交 + 判题轮询链路已验证通过（第9题 Accepted） 六、扩展资料说明想了解更多关于华为云码道（CodeArts）代码智能体的内容，请访问：华为云码道([cid:link_2])想了解更多关于智能体编排和多智能体协作的设计模式，可参考CodeArts官方文档中的智能体开发指南。【案例共创】【第11期】华为云码道（CodeArts）代码智能体 + 新特性完成应用开发/调试实践https://bbs.huaweicloud.com/forum/thread-0212721403979154441-1-1.html

鸿蒙matebook pro中CodeArts运行python的matplotlib不出图像怎么办？

在做2020年华为云AI实战营里面的项目时，按照流程下载数据集报错，怎么解决 

python代码无法在IED中进行跳转对应的插件也已经下载了

初衷竟然只是为了防止开挂。。反正也是单核

一直wrong answer，不知道哪里有问题

一直在wrong answer，只有交demo里的代码才有得分