业务和功能介绍
1、立项背景和目标
群接龙是社区团购领域广泛使用的订单管理工具，商家每天需要频繁调整商品库存——高峰时段某商品售罄需紧急补库存、发现库存设置错误需立即修正、运营人员需随时查看各商品剩余库存和已团数量以便安排补货。然而群接龙后台的库存管理存在明显痛点：修改库存需要人工在后台逐商品搜索、定位、修改、确认，操作路径长且效率低；运营人员需要在多个商品间频繁切换查看和修改，耗时耗力；传统的RPA脚本只能执行固定流程，无法理解自然语言指令，无法根据页面反馈动态调整策略。本项目的核心目标是构建一个基于大语言模型的AI Agent，用户只需用自然语言描述意图（如"把苹果的库存改成100"或"看看香蕉还剩多少"），Agent自动理解用户意图、调用浏览器工具完成操作、并根据页面反馈智能处理异常，实现库存管理的人机对话式交互。
2、软件功能、核心功能模块的介绍
工具涵盖以下核心模块：LLM Agent核心——基于OpenAI GPT-4o模型，通过System Prompt约束其扮演"群接龙库存管理助手"，理解用户自然语言指令并自动规划操作步骤；工具调用框架——将浏览器操作（导航、搜索商品、获取库存数据、修改库存、确认修改、关闭遮罩、获取错误信息等）封装为可被模型调用的工具函数，Agent根据用户指令自动选择合适的工具并按顺序调用；智能错误恢复——修改库存时若新库存小于已团数量，页面会报错，Agent自动调用get_error_text获取错误详情，然后自动将新库存调整为"已团数量+安全增量"，继续更新直到确认修改成功；术语精准区分——System Prompt强制Agent区分"新库存"（用户设定的总库存）和"剩余库存"（新库存-已团数量），回复中明确使用这两个术语避免歧义；上下文记忆——Agent维护完整的对话历史（用户消息、模型思考、工具调用结果），支持多轮连续操作，如"先看看苹果库存，再改成50"。
3、业务流程、功能路径描述
用户启动Agent程序 → 在终端输入自然语言指令（如"把苹果的库存改成100"）→ Agent将指令和上下文发送给GPT-4o → 模型分析用户意图，决定调用工具函数列表 → Agent按顺序执行：进入活动页面（navigate_to_activity）→ 搜索商品（search_product，返回当前库存、已团数量、新库存）→ 更新库存（update_stock，传入商品名和新库存数值）→ 若新库存小于已团数量，页面报错 → Agent调用get_error_text获取错误 → 自动调整新库存为"已团数量+1"或根据错误信息灵活调整 → 重新调用update_stock → 确认修改（confirm_modification）→ Agent向用户回复"苹果 新库存=100，剩余库存=85" → 用户可继续下达下一条指令。整个交互过
群接龙是社区团购领域广泛使用的订单管理工具，商家每天需要频繁调整商品库存——高峰时段某商品售罄需紧急补库存、发现库存设置错误需立即修正、运营人员需随时查看各商品剩余库存和已团数量以便安排补货。然而群接龙后台的库存管理存在明显痛点：修改库存需要人工在后台逐商品搜索、定位、修改、确认，操作路径长且效率低；运营人员需要在多个商品间频繁切换查看和修改，耗时耗力；传统的RPA脚本只能执行固定流程，无法理解自然语言指令，无法根据页面反馈动态调整策略。本项目的核心目标是构建一个基于大语言模型的AI Agent，用户只需用自然语言描述意图（如"把苹果的库存改成100"或"看看香蕉还剩多少"），Agent自动理解用户意图、调用浏览器工具完成操作、并根据页面反馈智能处理异常，实现库存管理的人机对话式交互。
2、软件功能、核心功能模块的介绍
工具涵盖以下核心模块：LLM Agent核心——基于OpenAI GPT-4o模型，通过System Prompt约束其扮演"群接龙库存管理助手"，理解用户自然语言指令并自动规划操作步骤；工具调用框架——将浏览器操作（导航、搜索商品、获取库存数据、修改库存、确认修改、关闭遮罩、获取错误信息等）封装为可被模型调用的工具函数，Agent根据用户指令自动选择合适的工具并按顺序调用；智能错误恢复——修改库存时若新库存小于已团数量，页面会报错，Agent自动调用get_error_text获取错误详情，然后自动将新库存调整为"已团数量+安全增量"，继续更新直到确认修改成功；术语精准区分——System Prompt强制Agent区分"新库存"（用户设定的总库存）和"剩余库存"（新库存-已团数量），回复中明确使用这两个术语避免歧义；上下文记忆——Agent维护完整的对话历史（用户消息、模型思考、工具调用结果），支持多轮连续操作，如"先看看苹果库存，再改成50"。
3、业务流程、功能路径描述
用户启动Agent程序 → 在终端输入自然语言指令（如"把苹果的库存改成100"）→ Agent将指令和上下文发送给GPT-4o → 模型分析用户意图，决定调用工具函数列表 → Agent按顺序执行：进入活动页面（navigate_to_activity）→ 搜索商品（search_product，返回当前库存、已团数量、新库存）→ 更新库存（update_stock，传入商品名和新库存数值）→ 若新库存小于已团数量，页面报错 → Agent调用get_error_text获取错误 → 自动调整新库存为"已团数量+1"或根据错误信息灵活调整 → 重新调用update_stock → 确认修改（confirm_modification）→ Agent向用户回复"苹果 新库存=100，剩余库存=85" → 用户可继续下达下一条指令。整个交互过
项目实现
1、整体架构和设计思路，不同模块使用的技术栈
项目采用分层架构设计，技术栈为Python 3 + OpenAI API + Playwright + 工具调用框架。Agent核心层：基于OpenAI的Chat Completions API，使用tool_choice="auto"模式让模型自主决定调用哪些工具；通过精心设计的System Prompt（约800字）约束Agent行为，包括术语定义（新库存/剩余库存）、操作原则（先导航后搜索再修改最后确认）、错误处理策略（自动重试调整）。工具封装层：将浏览器操作封装为带类型注解和文档字符串的Python函数，通过反射机制自动提取函数签名、参数类型和描述，动态生成OpenAI兼容的tools schema，实现"定义即文档"的零冗余设计。执行控制层：实现最大10轮迭代循环，每轮模型返回后解析tool_calls，按顺序执行工具函数并返回结果给模型，直到模型不再调用工具（返回最终文本）或达到轮次上限，支持完整的工具调用链式执行和错误传播。
2、"我"的负责模块和结果（尽可能量化）
（请根据实际情况替换） 本人独立完成该项目的全流程开发与测试，包括：Agent核心框架设计（约400行 Python代码）、System Prompt工程（约50行 精确指令设计）、工具调用Schema自动生成机制、6-8个 浏览器操作工具的封装与测试、3个 实际群接龙活动的端到端验证。项目实现了：用户指令理解准确率 90%以上 （测试场景涵盖查看库存、修改库存、批量修改、错误恢复等）；库存修改错误自动恢复成功率 95%以上 （主要测试场景为新库存小于已团数量时的自动调整）；单次库存修改操作从_手工约2分钟_ 压缩至 30-45秒 （含Agent推理+浏览器操作），单商品操作效率提升约_60%_。
3、"我"遇到的难点、坑，和解决方案
难点一：库存术语模糊导致模型回复不准确。 早期版本中用户说"库存"时，模型有时返回"剩余库存"，有时返回"新库存"，造成用户困惑。解决方案：在System Prompt开头用加粗格式明确定义"新库存=用户设定的总库存，剩余库存=新库存-已团数量"，并在操作原则中要求"所有回复必须明确区分新库存和剩余库存，不要使用模糊的'库存'"。同时在工具返回数据中同时包含current_stock、sold_count、new_stock三个字段，让模型有足够数据做出精准回复。
难点二：修改库存报错后模型不知道如何恢复。 当用户设置的"新库存"小于"已团数量"时，群接龙后台会报错"库存不能小于已团数量"，模型如果只是报告错误给用户，体验很差。解决方案：在System Prompt中明确策略——"如果新库存小于已团数量，页面会报错。此时调用get_error_text获取错误，然后自动将新库存调整为'已团数量
项目采用分层架构设计，技术栈为Python 3 + OpenAI API + Playwright + 工具调用框架。Agent核心层：基于OpenAI的Chat Completions API，使用tool_choice="auto"模式让模型自主决定调用哪些工具；通过精心设计的System Prompt（约800字）约束Agent行为，包括术语定义（新库存/剩余库存）、操作原则（先导航后搜索再修改最后确认）、错误处理策略（自动重试调整）。工具封装层：将浏览器操作封装为带类型注解和文档字符串的Python函数，通过反射机制自动提取函数签名、参数类型和描述，动态生成OpenAI兼容的tools schema，实现"定义即文档"的零冗余设计。执行控制层：实现最大10轮迭代循环，每轮模型返回后解析tool_calls，按顺序执行工具函数并返回结果给模型，直到模型不再调用工具（返回最终文本）或达到轮次上限，支持完整的工具调用链式执行和错误传播。
2、"我"的负责模块和结果（尽可能量化）
（请根据实际情况替换） 本人独立完成该项目的全流程开发与测试，包括：Agent核心框架设计（约400行 Python代码）、System Prompt工程（约50行 精确指令设计）、工具调用Schema自动生成机制、6-8个 浏览器操作工具的封装与测试、3个 实际群接龙活动的端到端验证。项目实现了：用户指令理解准确率 90%以上 （测试场景涵盖查看库存、修改库存、批量修改、错误恢复等）；库存修改错误自动恢复成功率 95%以上 （主要测试场景为新库存小于已团数量时的自动调整）；单次库存修改操作从_手工约2分钟_ 压缩至 30-45秒 （含Agent推理+浏览器操作），单商品操作效率提升约_60%_。
3、"我"遇到的难点、坑，和解决方案
难点一：库存术语模糊导致模型回复不准确。 早期版本中用户说"库存"时，模型有时返回"剩余库存"，有时返回"新库存"，造成用户困惑。解决方案：在System Prompt开头用加粗格式明确定义"新库存=用户设定的总库存，剩余库存=新库存-已团数量"，并在操作原则中要求"所有回复必须明确区分新库存和剩余库存，不要使用模糊的'库存'"。同时在工具返回数据中同时包含current_stock、sold_count、new_stock三个字段，让模型有足够数据做出精准回复。
难点二：修改库存报错后模型不知道如何恢复。 当用户设置的"新库存"小于"已团数量"时，群接龙后台会报错"库存不能小于已团数量"，模型如果只是报告错误给用户，体验很差。解决方案：在System Prompt中明确策略——"如果新库存小于已团数量，页面会报错。此时调用get_error_text获取错误，然后自动将新库存调整为'已团数量
示例图片视频
相似推荐
每日数据聚合展示平台
立项背景：为解决多平台公开数据（天气、汇率、热搜等）分散、获取效率低、缺乏可视化监控的问题，设计并实现了该数据聚合展示平台，将多源异构数据统一抓取、清洗并归档展示。
核心功能：包含四个数据源（天气、每日一句、汇率、百度热搜）的定时抓取，采用 Quartz 动态注册 4 个 Job 按 cron 调度。后端入库后，前端通过 ECharts 进行多维度可视化展示，包括温度趋势折线图、汇率柱状图、热搜标签饼图以及任务执行日志。
业务流程：定时任务触发抓取 -> 统一入库 -> 任务日志记录（耗时/成功失败） -> 前端仪表盘展示，形成完整的数据采集与监控闭环。
APP-金色财经
1. 负责《金色财经》APP项目的整体架构设计与实施，确保服务端的高性能与稳定运行。
2. 主导快讯与文章数据的抓取策略，通过go语言实现高效的数据采集与处理流程。
3. 利用gin框架搭建RESTful API服务，优化请求响应速度，提升用户体验。
4. 针对数据展示需求，设计并实现了与百度等平台数据小卡片的集成与刷新机制。
5. 管理并优化数据库交互，采用mysql与redis配合，保障数据存储的高效与准确。
6. 引入rocketmq消息队列，确保在高并发场景下系统的消息处理能力与稳定性。
视频去除字幕
1.快速去除字幕，简单背景偏纯色的时候使用时推荐，速度块
2.高清ai修复去字幕，复杂背景使用，使用本地大模型修复，视频无需上传到网络，私密性好，但是耗时比较长，cpu要求2核心以上，内存8g，大部分电脑可以跑
日历管理类App-芝麻日历
芝麻日历是一款面向家庭、多成员协同及日常生活管理场景的移动端应用，项目目标是将家庭事务、日程安排、任务执行、成员互动和设备协同等能力整合到同一套系统中，帮助用户以更低成本完成家庭日历管理和信息同步。系统围绕“家庭共用日历”这一核心目标展开，兼顾个人使用体验与多人共享需求，支持 Android、iOS 等移动端设备使用。
软件核心功能模块主要包括：账户登录注册与找回密码、动态通知与邀请处理、日历事项管理、任务管理、奖励与惩罚管理、餐食计划管理、相册管理、贺卡功能、设备管理、用户管理以及第三方日历同步等。其中，日历事项模块支持按月视图和周视图查看事项、新增编辑删除事项、设置参与成员及重复规则；任务模块支持新增任务、完成任务、筛选任务和配置显示规则；奖励与惩罚模块用于家庭成员积分激励；餐食模块用于一周餐食安排；相册和贺卡模块承担家庭内容留存与互动表达；设备管理和用户管理则用于完成家庭设备绑定、成员协作和权限管理。
在业务流程上，用户通常先完成注册登录，再进入首页查看动态、通知和主要功能入口；随后可根据需要创建日历事项、任务或奖励内容，并通过成员维度进行协同分配；在设备和成员接入后，系统还支持邀请处理、设备激活、用户管理和多端数据共享；对于有外部日历需求的用户，系统提供 Google、Outlook、iCloud、订阅链接等同步能力，用户可完成第三方账号绑定、日历选择、同步状态查看和结果确认，从而形成“注册登录 -> 家庭成员协同 -> 日历/任务/奖励等业务操作 -> 设备与同步扩展”的完整功能路径。
大文集团融媒体项目，报社核心系统策采编发系统，网站、APP显示
应技术发展升级采编、发布、网站系统，基于SpringBoot、ES、Mysql、MongoDB、Redis等技术升级
1、报题策划下达。
2、稿件编辑、发布。
3、发布系统，渠道、栏目、稿件管理。
4、网站:、：根据UI设计图使用H5、JS、swiper进行开发。
1、报题策划下达。
2、稿件编辑、发布。
3、发布系统，渠道、栏目、稿件管理。
4、网站:、：根据UI设计图使用H5、JS、swiper进行开发。
帮助文档
Copyright @ 2021-2024 程聚宝 | 浙ICP备2021014372号
人工客服