软件工程第二次团队作业
| 这个作业属于哪个课程 | https://edu.cnblogs.com/campus/fzu/202501SoftwareEngineering/ |
|---|---|
| 这个作业要求在哪里 | https://edu.cnblogs.com/campus/fzu/202501SoftwareEngineering/homework/13559 |
| 这个作业的目标 | 使用现代 AI 工具构建一个具备 语言交互(会说) 和 行动执行(会做) 能力的智能体(Agent)。智能体应能够在指定场景中接收自然语言输入、理解任务意图,并自动完成相应操作。 |
| 学号 | 172309055张誉怀 022301121林军 092300124杨佳峻 102301120吴政君 102301122吴飞龙 102301123魏星 102301125涂世为 102301134李泽 102301403林舒欣 102301404林祺 152301204林宏凯 162304118刘斌瑞 |
随着人们生活水平的提高和消费观念的转变,旅游已成为人们生活中不可或缺的一部分。旅游市场规模持续扩大,消费者对于旅游体验的要求也日益多样化和个性化。传统的旅游服务模式难以满足游客在行程规划、信息查询、预订管理等方面的复杂需求,在此背景下,旅游模型 Agent 应运而生。本研究旨在深入了解用户对于旅游模型 Agent 的需求,通过对大量用户的调研分析,明确旅游模型 Agent 应具备的核心功能、用户体验要求等,为旅游模型 Agent 的开发和优化提供有力依据,推动旅游行业智能化、个性化服务的发展。
我们发放了300份问卷,内容围绕旅游模型 Agent 的核心功能需求和用户体验需求展开,涵盖旅游行程规划、信息查询、预订管理、多模态智能交互、境外旅行场景适配、应急保障等多个方面。根据问卷结果生成的饼状图如下:

一、需求描述
(一)核心功能需求
1.1 个性化行程定制
行程时长分级规划
- 支持短途(1-3天)、中途(4-7天)及长途(7天以上)的差异化行程规划;
- 根据旅行时长提供相应的景点安排与活动建议。
预算适配与住宿推荐
- 按每日酒店预算推荐对应类型:经济型(100-300元)、舒适型(300-800元)、豪华型(800元以上);
- 基于行程规划生成多份距离适配的酒店榜单供用户选择。
主题场景推荐
根据人员组成推荐匹配的休闲场景,可针对不同主题优化餐饮和活动安排,例如:
- 亲子游:儿童乐园、科技馆、浅滩沙滩等低风险场所;
- 情侣浪漫游:日落观景地、情侣SPA、小众咖啡馆、景观餐厅等。
餐饮与景点整合
- 构建当地早、中、晚餐特色美食榜单;
- 提供十大高评价餐厅信息,包括推荐菜品、人均消费与排队情况。
行程灵活调整
- 支持用户拖拽调整景点游玩顺序;
- 设置避雷项:错峰游玩建议、客流高峰时段提示、避开特定设施等;
- 系统自动同步更新交通路线和用餐地点。
1.2 实时信息查询与更新
动态天气与着装建议
- 提供未来多天旅程的精准天气预报,按早、中、晚时段细分;
- 包含温度、降水概率、风力等级等关键指标;
- 提供场景化穿衣建议,如登山、海边、古城等不同场景的着装推荐。
智能交通规划
- 实时查询城市内地铁/公交到站时间;
- 监控景区周边拥堵情况及停车位状态;
- 提供3条备选路线及预估路程时间。
景点信息服务
- 同步景点开放时间(区分工作日与节假日);
- 提供多类型票价信息及优惠政策适用条件;
- 集成官方预约渠道,支持小程序/APP直接跳转。
1.3 智能预订与管理
多平台比价系统
- 机票:对比3家以上平台价格,标注退改政策、行李额度;
- 酒店:按距离、评分、设施筛选,支持“免费取消”、“延迟退房”标签;
- 门票:区分线上优惠与线下原价,提醒提前预订优惠。
官方直连与安全保障
- 一键跳转官方平台预订,避免第三方溢价;
- 跳转前显示平台资质认证信息,确保安全可靠。
(二)用户体验需求
2.1 多模态智能交互
多样化输入支持
- 文字输入:智能识别关键词,提取行程需求;
- 语音输入:支持15种方言(如四川话、广东话)识别,自动提取时长、目的地、人群需求;
- 图片识别:上传景点图片可识别地点,推荐周边路线和住宿。
2.2 境外旅行场景适配
实用工具集成
- 多语言实时翻译,支持语音转换和语速调节;
- 货币换算功能;
- 按国家区分的小费指南。
2.3 全方位应急保障
紧急联系服务
- 提供目的地紧急联系方式(当地大使馆、急救、景区救援等)。
个人应急管理
- 一键生成应急卡片,包含个人信息、过敏史、紧急联系人、基础病史;
- 支持保存至手机相册,突发情况时可快速出示。
二、业务流描述和实现说明
以下是基于Dify平台和高德地图MCP服务搭建智能旅行规划助手工作流的详细说明文档。该助手能够为用户提供景点推荐、美食搜索、出行规划、预算建议、攻略生成和注意事项提醒等全方位服务。
(一)工作流概述
1.目标
借助Dify的Agent模式集成高德地图MCP服务,打造一款能理解用户自然语言需求,并自动调用工具生成个性化旅行方案的智能助手。
2.核心能力
- 多工具协同:整合高德地图的路径规划、天气查询、周边搜索等多项MCP服务,实现功能互补。
- 结构化输入:利用Dify的变量功能规范用户输入(如目的地、天数、预算),有效提升意图识别的准确性。
- ReAct推理模式:Agent通过“推理-行动-观察”的循环逻辑动态调用工具,例如先查询目的地天气,再根据天气情况调整行程安排。
(二)环境准备
1. 基础环境
- Dify部署:采用Docker Compose快速部署Dify服务,部署前需确保服务器满足最低配置要求(4GB内存、20GB磁盘空间)。
- 高德开发者账号:注册高德开放平台账号,创建应用后获取Web服务类型的API Key,用于后续服务调用。
2. 关键插件安装
- MCP SSE插件:在Dify插件市场中安装该插件,它将作为Dify与高德MCP服务之间的通信桥梁,保障数据传输顺畅。
- Agent策略插件:可选安装“MCP Agent Strategy”插件,安装后可增强Agent的自主决策能力,优化服务响应效果。
3. MCP服务配置
- 在高德MCP Server配置中填入以下JSON(需将“你的API_KEY”替换为实际获取的API Key):
json
{
"amap-maps": {
"url": "https://mcp.amap.com/sse?key=你的API_KEY",
"headers": {},
"timeout": 60,
"sse_read_timeout": 300
}
}
- 配置完成且验证成功后,Dify Agent即可调用高德地图的搜索、路径规划、天气查询等工具。
(三)工作流搭建步骤
1. 创建Agent应用
- 在Dify平台内操作:先选择“创建空白应用”,再切换至“chatflow模式”。
- 模型选择:推荐选用支持工具调用的强推理模型,如GPT-4、Qwen3或DeepSeek-V3,以确保服务的推理与响应能力。
2. 设计提示词(Prompt)
提示词需清晰定义Agent的角色定位、核心能力及服务约束,示例如下:
你是一名专业旅行顾问,需依据用户需求调用相关工具,提供完整且贴合需求的旅行方案。
- 技能:使用高德地图工具查询景点、路线及天气信息;结合用户预算推荐适配的美食与住宿;以Markdown格式输出结构化行程。
- 约束:仅回复与旅行相关的话题,坚决避免涉及敏感内容。
- 工作流程:
1. 解析用户输入中的目的地、行程天数、预算等关键信息;
2. 调用天气工具查询目的地天气,判断适宜开展的活动;
3. 依据路径规划工具优化行程顺序,提升出行效率;
4. 整合所有信息,生成包含费用估算的旅行攻略。
提示词中可嵌入变量(如"{{destination}}"、"{{budget}}"),实现动态参数传递,适配不同用户需求。
3. 配置输入变量
在Dify的“输入表单”功能中,添加以下变量以规范用户输入,确保信息收集准确:
- 变量Key 类型 说明
- "destination" 文本 旅行目的地
- "days" 数字 行程天数
- "budget" 下拉选择 经济型/舒适型
4. 工具链编排
核心工具:启用高德MCP服务中的以下功能,构建完善的工具支撑体系:
- 关键词搜索:用于精准查找目的地的景点和餐厅;
- 路径规划:支持驾车、步行、公交等多种出行方式的路线规划;
- 天气查询:根据实时及预报天气,调整室内外活动安排;
- 周边搜索:推荐目的地周边的酒店及各类便利设施。
5. 工作流节点设计
通过Dify的ChatFlow功能,以可视化方式编排执行逻辑,具体流程如下:
用户输入 → Agent节点(ReAct模式) → 调用工具 → 数据清洗 → LLM生成回复 → 输出Markdown方案
- Agent节点:配置ReAct策略,让Agent能够自主判断工具调用顺序,例如先查询天气再规划路线,确保行程合理性;
- 模板转换节点:将高德服务返回的JSON数据转换为LLM可读取的文本格式,便于后续处理;
- LLM节点:对原始数据进行优化整理,生成用户易读、实用的行程表。
(四)测试与输出事例
测试用例
用户输入:“北京3天经济型行程”
Agent执行流程
1. 解析输入参数,识别出目的地为“北京”、行程天数为“3天”、预算类型为“经济型”;
2. 调用高德天气工具,查询北京未来3天的天气情况;
3. 根据天气数据(如预测第二天有降雨)调整行程,将户外景点安排至晴天;
4. 调用路径规划工具,计算各景点间的最优路线;
5. 整合所有信息,生成结构化行程表。
输出内容结构
🗓️ 北京3日游行程(经济型)
每日预算:约600元/天(含住宿、餐饮、门票)
Day 1:历史文化之旅
- 08:00 天安门广场(晴,18°C)
- 10:30 故宫博物院(步行10分钟可达)
- 12:00 四季民福烤鸭(人均80元,距故宫800米)
Day 2:室内活动(预报有雨)
- 09:00 中国科技馆(地铁8号线直达)
- 14:00 王府井购物区(室内商场)
出行建议
- 交通:地铁日均支出20元,推荐购买三日通票;
- 注意事项:故宫需提前预约,雨天出行请备好雨具。
(注:以上数据基于高德MCP服务的实时信息生成)
(五)部署与优化
一键发布
在Dify平台中点击“发布”按钮,即可生成Web应用链接或API接口,链接可分享至手机端,也可嵌入网站供用户直接使用。
持续优化
- 结合用户反馈,增加个性化选项,如是否携带儿童、偏好的景点类型(自然景观/人文古迹等);
- 扩展工具链,接入酒店预订API、票价对比工具等,丰富服务功能;
- 新增记忆窗口与语音输入功能,提升用户使用便捷性。
(六)技术亮点
1. 低成本高效集成:通过MCP协议标准化对接高德服务,无需单独开发接口,降低开发成本,提升集成效率;
2. 动态决策能力:ReAct模式使Agent可根据实时数据(如天气变化、路况信息)动态调整旅行方案,保障行程实用性;
3. 可扩展性强:未来可快速接入更多MCP工具(如机票比价、多语言翻译工具),持续丰富助手功能,满足用户多样化需求。
通过以上工作流,旅行助手能够将分散的出行信息转化为一键生成的个性化方案,显著提升规划效率。如需进一步定制,可参考Dify官方文档调整工作流节点或提示词策略。
github链接:https://github.com/Hannezs/404-Team-Not-Found/tree/TeamWork_2
使用示例(功能演示)
懒人版
1. 开始页面
场景:用户初次打开页面,准备进行需求设置。
操作示例:
- 开始页面如下:
![image]()
2.需求设置示例
场景:用户输入跟旅游相关的信息,分为基本信息,预算与住宿,人群组成,特殊偏好,必去景点,避雷项目六个部分。
操作示例:
- 输入目的地为北京,旅游天数为3天,出发日期为2025/10/1
- 输入住宿预算为舒适型(¥300-800/晚),总预算为5000元
- 输入人群组成为亲子游和情侣游
- 输入特殊偏好为避开人群和避免高强度徒步
- 输入必去景点为北京故宫
- 输入避雷项目为北京天坛
![image]()
3.生成专属旅游计划
场景:用户已输入完成旅游相关的信息
操作示例:
- 点击生成专属旅游计划
![image]()
4.详细介绍AI生成计划
场景:用户已经生成好旅游计划
操作示例:
- 点击行程安排,景点安排,酒店推荐,美食推荐,实用信息五个部分,会出现相应的计划页面
![image]()
5.历史记录
场景:用户想要查看以往生成的计划
操作示例:
- 点击历史记录就会跳转至相关页面
![image]()
- 对于每个记录都有查看和删除选项
![image]()
- 如果想要清空历史记录,可以点击清空所有记录
![image]()
6.检查链接问题
场景:用户点击生成专属旅游计划后,未能成功生成(小概率发生)
操作示例:
- 点击测试连接
![image]()
- 等待测试完成后会显示连接失败原因,若连接成功则会显示连接成功,以及实现api秘钥,api地址的信息
![image]()
简易版

总结
通过以上示例,可以看出“智能旅游助手”系统支持从行程规划、数据管理到网络连接服务检查的全流程操作。同时,智能体具备多轮对话记忆功能、使用语音输入/输出功能、能与外部API或数据库交互功能、以及一个简洁的前端界面(网页或桌面端)。用户可根据实际需求灵活使用各模块,实现高效、个性化的旅游体验。
小组分工与职责细化方案
| 组别 | 人员配置 | 负责人 | 组员 | 核心职责 |
|---|---|---|---|---|
| 项目管理组 | 2人 | 张誉怀 | 李泽 | 进度把控、资源协调、仓库管理、会议组织 |
| 需求组 | 2人 | 吴飞龙 | 涂世为 | 智能体场景定义、需求挖掘与分析、需求文档撰写 |
| 开发组 | 6人 | 杨佳峻 | 林军、吴政君、魏星、林宏凯、刘斌瑞 | 系统全流程开发与测试,包括对话系统、意图识别、工具调用、API对接、功能测试与体验优化 |
| 文档与博客组 | 2人 | 林舒欣 | 林祺 | 说明文档、博客撰写、成果展示与材料整合 |
各小组具体职责与交付物
1. 项目管理组
- 职责:
- 进度把控:制定项目里程碑计划,跟踪各小组进度,及时识别并预警延期风险。
- 资源协调:协调小组间的依赖关系与资源冲突,确保信息流畅。
- 仓库管理:管理GitHub等协作仓库,制定代码/文档提交规范,维护版本。
- 会议组织:组织日常站会及周会,同步项目进度,收集并推动解决跨组问题。
- 交付物:
- 《项目进度跟踪表》
- 《GitHub仓库管理规范》
- 《会议纪要》
2. 需求组
- 职责:
- 场景与需求分析:确定智能体的具体应用场景与核心功能,深入挖掘用户需求。
- 需求文档化:撰写详尽的《需求文档》,内容需涵盖核心功能模块(如行程定制、实时查询、智能预订)、用户体验需求及技术实现约束,为开发提供明确依据。
- 交付物:
- 《智能体需求文档》
3. 开发组
- 职责:
- 自然语言交互模块:实现对话系统,包括意图识别、上下文管理、自然语言生成。
- 工具调用与执行模块:将用户指令转化为具体动作,完成工具函数封装、API对接、操作执行及异常处理。
- 系统测试与优化:进行全面的功能测试与用户体验测试,输出测试报告,并持续进行问题迭代与体验优化。
- 交付物:
- 《自然语言交互模块代码》
- 《工具调用模块代码》
- 《智能体测试报告》 与 《优化需求清单》
4. 文档与博客组
- 职责:
- 技术文档撰写:整合并撰写清晰的Agent说明文档,涵盖需求、流程、实现说明与使用示例。
- 博客与宣传:撰写技术博客、项目随笔,以Markdown等形式进行成果展示和宣传。
- 过程材料整理:收集各组素材,整理小组分工说明与成员心得,汇总项目全过程材料。
- 交付物:
- 《Agent说明文档》
- 《博客园Markdown随笔》
- 《小组分工与心得汇总》
成员心得
成员:张誉怀(Hannes's)
本次作业中,我担任的是项目PM一职,在团队中隶属于管理组,
主要职责:
- 进度把控:制定项目里程碑计划,跟踪各小组进度,及时识别并预警延期风险。
- 资源协调:协调小组间的依赖关系与资源冲突,确保信息流畅。
- 仓库管理:管理GitHub等协作仓库,制定代码/文档提交规范,维护版本。
- 会议组织:组织日常站会及周会,同步项目进度,收集并推动解决跨组问题。
交付物:
- 《项目进度跟踪表》
- 《GitHub仓库管理规范》
- 《会议纪要》
这次作业我们提交的作业是一个基于Dify平台和高德地图MCP服务搭建智能旅行规划助手Agent,该助手能够为用户提供景点推荐、美食搜索、出行规划、预算建议、攻略生成和注意事项提醒等全方位服务。
在完成这次作业过程中,我参与了工作流搭建和管理团队的工作。同时,全方位、全流程了解和学习了基于Dify平台开发智能体,以及管理团队按时完成开发的方法。我们团队本次开发使用了瀑布模型,在多次迭代中让我们的Agent达到最完美的效果。这给我带来了全新的体验和自信,也开始接触到开发的魅力。
最后,很感谢我们组每一位成员,大家相互配合、主动担责、听分配、跟指挥,都能按时按量完成阶段性任务,虽然总难免熬夜赶工,但还是很值得,最后的结果也很完美,对得起我们的努力。
成员:杨佳峻(reasomn)
作为本次“AI旅游助手”项目的开发组组长,我从拆分需求定义、实现技术验证到工作流搭建与团队协同的全过程。项目基于高德 MCP 服务,融合地理信息查询能力,最终实现了一个能“查景点、看天气、荐酒店”的智能助手。在此,我想分享几点关键心得。
一、以工作流为中心,先定义逻辑,再对接前后端
过去我们习惯“前后端并行开发”,但面对 AI 原生应用,这种方式容易导致接口反复变更。本次我们采取了 ”先搭工作流,再供调用” 的新范式(原本的想法):
- 在 Dify 中完整搭建主工作流:从用户输入开始,依次集成高德 MCP 工具(POI 搜索、天气、周边酒店)、结构化数据处理、Stability AI 图片生成等节点;
- 通过测试用例验证端到端效果:确保输入“杭州西湖”能正确返回景点介绍 + 风景图;
- 最后开放 API 给前端调用:前端只需传入用户 query,即可获得结构化响应(含文本与图片 Base64)。
这种“工作流先行”的方式,大幅减少了联调成本,也让业务逻辑更集中、更可维护。
二、一个主 Agent 足矣:职责清晰,避免过度拆分
初期我们曾设想用多个子 Agent 分别处理景点、天气、酒店、图片等任务,但很快发现:
- 子 Agent 之间依赖强(如图片生成需依赖景点名称);
- 上下文传递复杂,调试困难;
- 实际用户意图往往是复合的(“推荐西湖附近人少的酒店,并生成风景图”)。
因此,我们果断收敛为单一主 Agent,在其内部通过工具链编排**实现多功能协同:
- 用高德 MCP 一次性获取 POI、天气、周边酒店;
- 用 Code Node 提取关键字段并生成 AI 绘图 Prompt;
- 动态决定是否调用 Stability AI(如用户明确要求“看看图片”)。
这种设计既保持了灵活性,又避免了架构冗余。在图片生成方面,我们考虑了用StabilityAI图片生成还是http请求图片,但是由于时间的紧迫,我们在Stability方面的图片生成和http请求图片的过程中遇到了工具不调用,agent无法直接访问,和http的url参数提取等问题,我们不得不暂时放弃这部分的内容。
三、高德 MCP 的正确打开方式:工具化,而非接口化
我们曾误将 MCP 当作普通 HTTP API 调用,导致 405 错误频发。后来才理解:MCP 的核心价值在于“工具注册”。
在 Dify 中,我们将高德能力封装为标准工具(如 amap_poi_search),由主 Agent 根据上下文自主调用。这不仅符合 LLM 的推理习惯,也让后续扩展(如加入路线规划)变得极其简单——只需注册新工具,无需改写流程。
四、作为组长:聚焦集成与标准,而非细节实现
我的角色逐渐从“写代码的人”转变为“搭骨架的人”:
- 定义工作流的数据契约(如输出必须包含
name,introduction,image_base64); - 推动团队使用统一的 Prompt 模板,确保图片风格一致;
- 协调后端提供 MCP 配置支持,前端适配图文混合展示。
当工作流在 Dify 中跑通后,前后端只需按约定对接,开发效率显著提升。
结语
这次项目让我们验证了 “AI 工作流即产品核心” 的理念。高德 MCP 提供了强大的地理智能,而 Dify 让我们能快速将其与生成式 AI 融合。未来,我们将继续以工作流为中枢,逐步接入更多服务(如票务、人流预测),打造真正懂旅行的 AI 助手。
成员:吴政君
关于「智能旅游助手」项目的个人心得体会
在本次「智能旅游助手」项目的开发中,我主要负责基于 Dify 平台上 Chatflow 模型的智能工作流搭建。Chatflow 是一种支持记忆的复杂多轮对话工作流,这让我们能够打造出真正理解用户上下文、具备连续对话能力的 AI 助手。
一、技术收获:从工具使用到思维转变
1. Chatflow 工作流开发:构建具备记忆的复杂对话系统
本次项目的核心是使用 Dify Chatflow 来构建旅游助手。与普通工作流不同,Chatflow 的核心优势在于支持记忆和多轮对话。
2. Agent 配置:赋予工作流决策与执行能力
在 Chatflow 中,我集成了具备 ReAct 推理能力的 Agent,并配置了包括稳定扩散图片生成在内的多种工具。这使得我们的旅游助手不再是简单的问答机器人,而是一个能够自主规划、决策和执行的"虚拟旅行顾问"。它会自动判断何时需要查询天气、调用地图 API、或是为用户生成景点图片,真正实现了智能化的任务处理。
3. MCP 框架应用:无缝扩展助手能力边界
通过 MCP 框架,我为 Chatflow 接入了高德地图等服务,实现了天气查询、地理位置检索等实时功能。这让我深刻体会到,一个强大的对话系统不仅需要良好的记忆和推理能力,更需要与外部世界连接的能力,这样才能为用户提供实时、准确的服务。
4. Dify API 调用:将智能对话能力赋能全团队
我负责将通过 Chatflow 实现的复杂对话能力,通过 Dify API 封装成标准服务供前端调用。这确保了用户在任何对话轮次中都能获得连贯、个性化的体验,同时也为团队协作奠定了坚实的技术基础。
二、团队协作:基于能力封装的高效合作
本次项目采用了一种高效的协作模式:我专注于 Chatflow 智能对话能力的实现,而前端同学则负责用户体验的优化。我们通过清晰的 API 接口约定,完美地将智能对话引擎与用户界面相结合。这种基于能力封装的协作方式,让我们各展所长,最终交付了一个既智能又易用的旅游助手产品。
成员:林舒欣
关于「智能旅游助手」项目的个人心得体会
在本次「智能旅游助手」项目开发中,我作为文档组负责人,主要统筹并完成三项核心工作:撰写 Agent 说明文档、创作技术博客与宣传内容、整理项目过程材料。这三项任务贯穿项目全程,让我在技术梳理、团队统筹与价值传递中收获显著。
一、技术收获:从内容整合到价值传递
1. Agent 说明文档撰写:搭建清晰技术参考
为确保文档实用性,我牵头与开发组、需求组深度沟通,明确 Agent 作为 “用户需求与服务枢纽” 的核心定位,梳理其旅游咨询、行程规划等核心能力。
通过绘制饼状图,将 Agent文档中的调查文结果直观的呈现出来;实现说明部分聚焦核心模块设计,结合技术方案阐述意图识别、任务规划逻辑;同时设计 “七日游行程查询”“亲子景点推荐” 等典型场景示例,标注操作步骤与注意事项,为团队使用和后续维护提供清晰参考。
2. 技术博客与宣传创作:让成果更易传播
撰写时以 “用户视角 + 技术亮点” 为核心,从 “Agent 如何提升旅游体验” 切入,结合实际场景讲解优势 —— 例如对比传统工具,突出 Agent 能按用户时间、预算动态调整行程,并同步实时信息。
采用 Markdown 优化排版,通过分级标题、流程图呈现关键内容;项目随笔则记录开发挑战(如 Agent 意图识别准确率问题)、解决思路(优化训练数据)与团队故事,让内容既有技术感又有人文温度。相关内容发布后,有效提升项目曝光度,为行业同类项目提供参考。
3. 过程材料整理:构建可追溯 “记忆库”
- 项目初期,我制定统一的材料收集标准,明确素材类型(需求文档、设计稿、测试报告等)、格式与提交节点,统筹推进各组材料收集;
- 项目推进中,定期跟进提交进度,对素材分类归档(如设计类分 UI 稿 / 原型图、开发类分技术文档);
- 整理分工说明时,结合任务拆解表记录成员职责与交付成果;通过 “问卷 + 一对一沟通” 收集成员心得,汇总成完整经验总结。最终搭建的结构化材料库,既支撑项目验收,也为后续复盘复用奠定基础。
二、团队协作:以 “桥梁” 角色促高效协同
作为文档组负责人,我的工作需串联多团队协同:
- 撰写文档时,对接开发团队确认技术细节,结合产品团队调研数据调整需求描述;
- 宣传创作时,联合设计团队获取视觉素材,与市场团队明确宣传重点;
- 材料整理时,协调各组按时提交,指导规范修改。
这种跨团队统筹协作,让我成为项目 “信息枢纽”,既避免信息壁垒、推动项目高效推进,也让我在统筹中学习产品思维、设计逻辑,进一步拓宽了能力边界。
结语
作为文档组负责人,我不仅完成了内容整合与传递的核心工作,更深刻体会到:文档与宣传是项目落地的基石,而跨团队协同则是项目成功的纽带。这次经历为我后续处理类似工作积累了宝贵经验,也让我更清晰地认识到自身在团队中的价值,未来将继续优化工作方法,为团队项目贡献更高效的支持。
成员:林祺
关于「智能旅游助手」项目的个人心得体会
在“智能旅游助手”项目中,我作为文档与博客组成员,虽未直接参与代码开发,但深度介入了从需求梳理到成果展示的全流程。我的角色是项目的“翻译官”与“连接器”,负责将技术逻辑、用户诉求与团队成果转化为清晰、易传播的内容。这段经历让我深刻体会到,在AI技术驱动的项目中,高质量的文档与系统化材料管理,是项目成功的关键支撑。
一、核心职责:构建结构化知识体系
我的工作聚焦于三个方面:辅助撰写需求与技术文档、创作技术博客与宣传内容、系统整理项目全过程资料。
需求转化与文档结构化
在项目初期,我协同需求组整合了300份问卷数据与业务构想,共同完成《Agent说明文档》的撰写。这一过程不仅是记录,更是深度“需求转化”:
-
数据可视化呈现:将用户对“个性化行程定制”“实时信息查询”等功能的偏好,转化为饼状图等直观形式,为开发提供明确方向。
-
功能描述清晰化:通过反复沟通,确保文档中“ReAct推理模式”“高德MCP服务集成”等技术概念准确易懂。例如,将用户“拖拽调整景点顺序”的需求,与Dify工作流中“节点灵活编排”的实现关联起来,使文档成为连接设想与落地的桥梁。
技术传播与成果展示
作为项目的“宣传窗口”,我通过技术博客与随笔,突出技术价值与团队协作:
-
用户视角叙事:以旅行者规划行程的真实场景切入,对比传统APP与AI Agent在效率上的差异,例如规划“北京3日经济型行程”的案例,直观展现项目创新点。
-
凸显技术亮点:重点描述基于Dify平台集成高德MCP服务的“低成本、高集成”开发模式,并记录团队从“多子Agent设想”到“单一主Agent”的决策过程,体现技术选型的思考与成长。
过程材料系统化整理
我负责汇总各小组的交付物,构建项目的“集体记忆”:
-
标准化归档:制定统一模板,规范《项目进度跟踪表》《测试报告》等文件的格式与内容。
-
提炼团队智慧:通过梳理开发组“工作流先行”、项目管理组资源协调等经验,将分散的个体思考整合为团队资产,为复盘与未来工作提供参考。
二、心得感悟:文档即协作的基石
-
文档是“导航图”:清晰的需求文档为开发指明方向,技术说明文档则为后续维护提供指南。我的职责正是确保这份“地图”的准确与易用。
-
“翻译”能力是关键:文档工作需将技术语言转化为产品、用户可理解的内容,同时将模糊需求转化为开发所需的明确输入。频繁的跨组沟通使我的这项能力显著提升。
-
全局视角深化认知:接触全环节材料让我建立起对项目的整体理解。例如,明晰高德MCP服务在工具调用上的优势后,我能更精准地描述其技术价值。
三、总结
作为文档组成员,我虽未编写代码,但通过系统化梳理与传播,确保了团队成果能够清晰呈现。我深感自豪能以文档为桥,连接技术智慧与用户需求。此次经历让我坚信,在技术快速迭代的时代,精准沟通与知识管理,与技术创新同等重要。未来,我将持续精进此项能力,为团队创造更多价值。
成员:李泽
关于「智能旅游助手」项目的个人心得体会
在本次「智能旅游助手」项目的开发中,我们团队基于 Dify 平台与高德地图 MCP 服务,开发了集景点推荐、美食搜索、出行规划等全方位服务于一体的智能旅行规划助手 Agent。作为项目管理组一员,我全方位了解并学习了 Dify 平台智能体开发流程,我的职责围绕进度把控、资源协调与仓库管理展开,这三项工作环环相扣,共同支撑着项目从启动到推进的平稳运转,也让我在实践中积累了宝贵的经验。
一、核心职责:统筹协同保障项目高效推进
1.资源协调:打破壁垒,主动联动破解协作瓶颈
资源协调让我学会了 “打破壁垒,主动联动”。项目推进中,小组间的依赖关系与资源冲突是常见问题,若不及时协调,很容易导致整体进度卡顿。
2.进度把控:计划先行,动态调整筑牢推进根基
在进度把控工作中,我深刻体会到 “计划先行,动态调整” 的重要性。制定项目里程碑计划时,不能仅凭主观判断划分节点,而是需要结合各小组的实际能力以及任务复杂度,确保里程碑既具有挑战性,又具备可实现性。
3.仓库管理:规范为基,定期维护提升协作效率
仓库管理是协作的基础,它直接关系到项目的协作效率与版本安全性。管理GitHub等协作仓库时,我意识到“规范是基础,维护是关键”
二、总结
这次经历让我体会到,项目管理的核心是 “技术认知 + 流程把控” 的结合。通过本次项目的参与,我不仅了解了 Dify 智能体的开发逻辑,更让我真切感受到了团队协作的重要性。这份经历既让我收获了满满的自信,也真切感受到了开发与团队协作结合的独特魅力,为后续项目的参与积累了宝贵经验。
成员:吴飞龙
关于「智能旅游助手」项目的个人心得体会
在本次「智能旅游助手」项目的实践过程中,我有幸参与需求组的工作,主要负责职能体场景的初步定义、用户需求的收集与整理,以及协助撰写需求文档。作为一名学习者,我在团队协作中不断摸索前行,深刻体会到需求分析不仅是功能的罗列,更是连接用户真实需求与技术实现的重要桥梁。
一、实践内容:在参与中学习,在协作中成长
1. 职能体场景定义:理解AI角色的“行为边界”
项目初期,我对“智能体”这一概念还比较模糊。在队友的指导下,我尝试从用户旅行的实际流程出发,梳理出“行前规划—行中应对—行后反馈”三个阶段,并思考智能助手在每个阶段应该扮演什么样的角色。例如,在行前阶段,它是否能理解用户说的“想带孩子去一个轻松好玩的地方”这样的模糊表达?在行中阶段,能否根据实时天气调整行程建议?这些思考让我逐渐意识到,定义场景不是凭空想象,而是要基于真实用户的使用逻辑,为AI的能力设定清晰的“行为边界”。
2. 需求挖掘与分析:学会倾听用户的声音
为了更真实地了解用户需求,我参与了问卷设计、用户访谈和竞品功能梳理等工作。在整理300份问卷结果时,我发现“个性化行程定制”是用户最关心的功能,这让我意识到,用户并不只是想要一个信息查询工具,而是希望获得真正贴合自己兴趣、预算和时间的行程建议。同时,在与几位经常出游的同学交流中,我听到他们提到“最怕临时改行程后整个安排都乱了”,这促使我们在需求中加入了“支持拖拽调整、自动同步路线”的灵活性要求。这些经历让我明白,好的需求来源于对用户真实困境的耐心倾听。
3. 需求文档撰写:从零散想法到结构化表达
在撰写《旅游模型需求清单》的过程中,我最初只是把想到的功能点一条条列出来,显得杂乱无章。在团队讨论中,大家建议我按照“核心功能—用户体验—应急保障”进行分类,并细化每项功能的具体要求。例如,将“推荐餐厅”细化为“提供人均消费、排队情况、推荐菜品”等可落地的描述。这个过程让我学会了如何把模糊的想法转化为清晰、可执行的需求说明,也让我体会到文档不仅是记录,更是团队沟通的共同语言。
二、总结:在实践中收获成长
回顾整个项目,我最大的收获不是完成了某项任务,而是在实践中学会了如何从用户的角度思考问题,如何将零散的信息整理成有逻辑的结构,以及如何在团队中有效沟通与协作。我深知自己在需求分析的深度和系统性上还有很多不足,但这次经历为我打开了一扇门,让我看到了产品设计背后的人文关怀与技术逻辑的融合之美。未来,我希望能继续积累经验,以更扎实的能力参与更多有意义的项目。
成员:涂世为
关于「智能旅游助手」项目的个人心得体会
在「智能旅游助手」项目中,我作为需求组核心成员,聚焦问卷数据深度分析、用户隐性需求挖掘、需求与技术可行性匹配三大任务。这段实践让我跳出理论局限,真切理解需求工作 "懂用户、懂技术" 的双重逻辑,也在跨团队协作中找到需求落地的最优路径。
一、问卷分析:从 "统计" 到 "归因",精准定位用户诉求
最初整理 300 份问卷时,我仅统计出 "个性化行程定制(85%)、实时信息查询(78%)" 需求最高。但复盘后发现,这种单一分析无法解释需求本质。于是我按 "旅行人群、时长、预算" 搭建多维度框架,发现亲子用户对 "儿童友好景点" 需求达 92%,中老年用户更关注 "无障碍设施"(83%),长途用户重视 "多平台比价"(76%),短途用户则在意 "交通拥堵查询"(81%)。
为避免数据偏差,我还通过 "交叉验证" 完善需求:比如针对 "预算适配住宿",结合目的地数据发现,一线城市用户关注 "酒店距地铁距离"(82%),景区用户优先 "周边餐饮"(79%);再结合问卷留言中 23 条 "避开网红溢价酒店" 的反馈,补充 "高性价比酒店筛选" 功能,有效规避伪需求。
二、隐性需求挖掘:从 "表述" 到 "推演",补全场景缺口
用户访谈中,一位独自旅行者 "怕找不到本地人常去餐厅" 的表述,让我意识到其隐性需求是 "避开游客陷阱"。由此推演独自旅行全场景,梳理出 "小众出入口查询""深夜安全路线推荐""24 小时药店定位" 等需求,纳入 "独自旅行专属服务" 模块,成为产品亮点。
同时,通过梳理 "旅行痛点清单",发现 "行程临时变更" 存在缺口:如酒店取消后难寻 "免费取消且退款快" 的替代选项、雨天无室内活动推荐。为此我牵头设计 "应急行程调整" 模块,要求系统 "10 分钟内生成 3 套替代方案" 并同步取消原预订,覆盖用户未主动提及的核心诉求。
三、需求与技术匹配:从 "理想" 到 "落地",平衡期待与边界
面对 28 项需求,我设计 "优先级评估矩阵",从 "用户痛点、技术难度、开发周期" 打分,划分 "核心必做、次要优化、远期规划" 三类。例如 "多语言实时翻译" 因 "痛点分 5 分、难度 3 分、周期 1 周" 列为核心;"AI 生成旅行 Vlog" 因 "难度 5 分、周期 4 周" 归入远期。
为避免需求与技术脱节,我与开发组共建 "需求技术说明书":明确 "实时天气查询" 需调用高德 API、1 小时更新一次;"景点开放时间" 需区分工作日 / 节假日。针对 "景点数据实时更新难" 的问题,共同优化为 "每日凌晨批量更新 + 紧急通知推送",提升落地效率 40%,避免 3 次返工。
四、跨团队协作:以需求为枢纽,打通协同链路
配合项目管理组,我设计 "需求进度看板",标注每项需求的进度、负责人及风险点。如 "应急保障需求" 遇 "数据存储合规问题",我及时标注并协调法务组解决,保障进度。
针对文档组 "不理解需求逻辑" 的问题,我整理 "需求背景解读手册",补充每项需求的痛点来源与功能关联。如 "应急卡片生成" 需说明 "基于突发疾病信息传递痛点,与紧急联系服务联动",让文档用户理解度提升 60%。
五、总结:成长与方向
此次项目让我实现三重成长:从 "关注功能" 到 "关注场景",从 "不懂技术" 到 "理解边界",从 "被动协作" 到 "主动联动"。但也存在不足,如对 "Agent 调用 API 触发条件" 理解欠缺,后续需加强 AI 技术学习。
未来,我计划深化 "需求全生命周期管理",延伸至上线后效果验证;探索 "需求可视化设计",用流程图让需求传递更直观。这次经历让我坚信,需求工作是产品核心竞争力,也让我在 "懂用户、懂技术、懂协作" 的路上更扎实。
成员:林军
关于「智能旅游助手」项目的个人心得体会
一、项目概述
本项目基于 SpringBoot 框架集成 Dify AI 平台,实现了一个具备用户管理与智能对话功能的系统。项目从传统Web开发扩展到AI应用开发,提升了系统智能化程度与用户体验。
二、技术架构
- 后端技术栈:SpringBoot、Spring Security(JWT认证)、MyBatis、MySQL、Redis、WebFlux、Swagger
- AI集成:通过Dify平台API + WebClient实现AI对话能力
三、核心功能
- 用户体系:支持注册、登录、登出,每位用户绑定独立的 Dify API Key,确保数据隔离与安全。
- AI对话模块:基于 WebClient 调用 Dify 接口,实现非阻塞异步通信。
四、主要收获
- 响应式编程实践:WebFlux 实现异步非阻塞调用,提升系统并发性能。
- API标准化:通过 Swagger 实现接口文档自动生成,促进团队协作。
- 安全设计:采用 JWT 无状态认证与权限控制,增强系统安全性。
- DTO模式应用:数据传输与业务逻辑分离,代码结构更清晰、可维护。
五、问题与解决
- 跨域:使用
@CrossOrigin快速解决。 - 文件上传限制:增加文件大小校验。
- 异常统一处理:自定义异常与全局异常拦截器。
- 配置管理:敏感信息外置化配置,便于环境切换。
六、项目亮点
- 模块化分层(Controller / Service / Mapper / Config / Utils)
- 完善的Swagger文档
- 安全防护:密码加密、Token认证、SQL防注入
七、技术感悟
- Dify 提供标准 REST API,AI 能力集成简单高效。
- SpringBoot 生态完善,大幅降低开发与配置成本。
- 工具(Lombok、Swagger)与规范化架构显著提升开发效率与代码质量。
八、未来优化
- 性能:数据库连接池、缓存、接口限流
- 功能:流式响应、对话记录、多模态支持
- 运维:日志监控、健康检查、APM接入
- 测试:单元与集成测试完善
九、总结
本项目让我深入理解了 AI与Web融合的开发模式。合理的架构设计、统一的异常处理与清晰的接口规范,是项目成功的关键。AI集成让系统更智能,也让开发更具创造性。
作为开发者,应持续学习、优化架构,积极探索AI时代的最佳实践。
成员:魏星
关于「智能旅游助手」项目的个人心得体会
在完成这个智能旅游助手项目后,我对于如何构建一个功能完整、用户体验良好的AI应用有了更深刻的理解。
一、核心技术实现
1. AI集成与数据处理
- 设计了结构化的提示词模板,将复杂的旅行需求转化为AI可理解的格式
- 实现了
extractAnswerContent()函数处理AI返回数据,有效过滤思考过程标签 - 使用
marked.js库解析Markdown格式,让AI生成的内容美观展示
2. 前端状态管理
- 基于
localStorage实现了完整的历史记录功能(增删改查) - 设计了
saveToHistory()和displayHistory()等核心函数 - 通过Tab标签页组织复杂的旅行计划内容,提升用户体验
3. 健壮性保障
- 集成了详细的错误处理机制和
DEBUG_MODE调试模式 - 实现了
testAPIConnection()连接测试功能 - 编写了完整的故障排除指南文档
二、项目架构亮点
模块化设计:将功能拆分为独立的函数模块,便于维护和测试
响应式界面:使用CSS Grid和Flexbox实现跨设备兼容
实时交互反馈:加载动画、操作提示等增强用户体验
三、总结收获
通过这个项目,我掌握了将AI能力产品化的完整流程:从需求分析、技术选型、编码实现到错误处理和文档编写。最大的体会是,优秀的产品需要在强大的技术实现与优雅的用户体验之间找到完美平衡。
技术栈应用:HTML5 + CSS3 + JavaScript + LocalStorage + Markdown解析 + RESTful API
项目规模:约1000行核心代码,包含20+功能函数,5个主要功能模块
成员:刘斌瑞
关于「智能旅游助手」项目的个人心得体会
一、工作内容与进展
- 担任后端开发角色,负责旅游规划功能模块
- 完成首个需求:根据目的地、旅游天数、出游人关系、每日预算等参数生成旅游日程规划
- 经过20+次调试和优化,成功通过Postman测试,返回规范的JSON数据格式
- 后续因项目技术路线调整,工作重点转向工作流和前端搭建
- 在环境配置环节遇到插件安装问题,暂时未能完全融入新的开发流程
二、遇到的挑战与收获
技术挑战
- 客户需求复杂度远超预期,实际业务逻辑比学习项目复杂得多
- 实现"每日行程不重复"功能耗费大量调试时间
- 工作流环境搭建遇到技术障碍,暴露了环境配置方面的知识盲区
成长收获
- 深入理解了增量测试的重要性:部分完成即测试 vs 全部完成再调试
- 掌握了旅游规划业务的核心算法设计和实现
- 认识到实际项目开发与个人练习在复杂度上的显著差异
三、经验总结与反思
开发方法论
- 测试策略:采用分阶段测试,避免集中调试导致的错误定位困难
- 学习方式:亲手编码远比阅读或复制代码更能提升技术水平
- 问题定位:学会通过报错信息快速定位和解决问题
后续规划
- 继续学习后端开发新技术,弥补知识缺口
- 重点攻克环境配置和工作流相关技能
- 为后续项目贡献做好技术储备,争取发挥更大价值
成员:林宏凯
关于「智能旅游助手」项目的个人心得体会
在「智能旅游助手」项目中,我作为开发组成员,参与了《使用实例文档》的编写工作。该文档旨在通过具体场景和操作示例,向开发团队、测试团队及用户清晰传达系统的功能逻辑和交互流程。编写过程中,我聚焦用户场景的细化、功能操作的直观描述以及文档结构的优化,不仅加深了对需求分析的理解,也在跨团队协作中提升了沟通效率。以下从编写过程、关键收获、挑战与优化及未来方向四个方面,分享我的心得体会。
一、编写使用实例文档的过程
编写《使用实例文档》是一个从用户需求到功能落地的桥梁构建过程,我采用了以下步骤:
1.场景化需求梳理:
基于前期 300 份问卷分析和用户访谈,提取核心场景,如“初次打开页面”“输入旅游信息”“生成专属计划”等。
针对不同用户群体(如亲子游、情侣游)细分场景需求。例如,亲子游用户关注“儿童友好景点”(92%),需在文档中体现“人群组成”输入功能;预算敏感用户关注“高性价比酒店”(82%),需明确“预算与住宿”设置的操作示例。
2.结构化文档设计:
每节使用实例遵循统一结构:场景描述(用户上下文)、操作示例(具体步骤)、预期结果(系统响应)。例如,“需求设置示例”明确了输入目的地、预算、人群等六部分的详细操作步骤。
融入交互细节,如“点击生成专属旅游计划”后等待 AI 分析,或“点击重新生成”以优化不满意的计划,确保文档覆盖用户全流程体验。
3.技术与用户语言平衡:
为确保开发团队理解,我在描述如“检查连接问题”时,明确了技术细节(如显示 API 密钥和地址),但用简洁语言避免技术门槛。例如,“等待测试完成后会显示连接失败原因”便于非技术用户理解。
二、关键收获
1.从用户视角到功能实现的转化:
编写使用实例让我学会从用户痛点出发,设计直观的操作流程。例如,“避雷项目”输入功能响应了用户“避开网红溢价景点”(23 条反馈)的需求,文档通过“输入北京天坛”示例清晰传达了这一功能。
通过场景化描述(如“用户对计划不满意,点击重新生成”),我更深刻理解了用户体验设计的闭环逻辑,确保功能覆盖“试错与优化”场景。
2.结构化思维的提升:
采用“场景-操作-结果”的结构化框架,让我学会将复杂需求拆解为清晰步骤。例如,“生成专属旅游计划”拆分为“点击生成”“等待分析”“查看计划”,每步都与用户目标和技术响应挂钩。
设计“优先级评估矩阵”辅助文档内容筛选,确保核心功能(如“需求设置”)优先描述,次要功能(如“分享计划”)简洁呈现,优化文档可读性。
三、总结与未来方向
通过编写《使用实例文档》,我深刻体会到需求文档在产品开发中的核心作用:它不仅是功能的记录,更是用户场景与技术实现的桥梁。我从“关注功能描述”成长为“关注用户场景”,从“被动编写”转变为“主动优化沟通”,并在结构化思维和跨团队协作中获得显著提升。
不足与改进:
对 AI 技术细节(如 Agent 调用 API 的触发条件)理解不足,导致“生成专属旅游计划”示例中未充分描述算法响应时间的技术约束。未来需加强 AI 相关知识学习。
文档的可视化程度有待提高,如“行程安排”示例可加入流程图或交互界面截图,提升直观性。
未来方向:
深化“需求全生命周期管理”,延伸至上线后用户反馈验证,确保使用实例与实际体验一致。
探索“需求可视化设计”,通过流程图、交互原型等工具,让使用实例更直观,提升开发和测试效率。
学习用户体验设计(UX)方法,结合 A/B 测试优化文档中的场景描述,确保覆盖更多边缘案例。
此次项目让我认识到,优秀的文档不仅是技术输出的载体,更是用户需求与产品价值的连接点。我将在未来需求工作中,继续以用户为中心,精进文档编写与协作能力,为打造高效、贴心的智能应用贡献力量。










浙公网安备 33010602011771号