徐嘉琪：
一、学期回顾
1.1 回顾你对于软件工程课程的想象
通过学习软件工程的课程与完成课程实践作业，各方面都得到提升，但还存在不足。
（1）达到期待与目标的方面：
工程化思维的具体实践：以前完成一个项目或者作业，都是直接写代码，不断调试出最终需要的结果，在这个过程可能会遗漏部分要求，现在学会先画用例图、类图，思考模块划分和接口设计，形成先分析再设计的习惯。
团队协作流程：通过小组项目真正使用了Git的工作流（issue → branch → PR → review），体验了如何避免代码冲突、如何做code review。这比我预想的更有纪律性，也更有收获。
（2）存在的不足：
对于该课程还没有很深入的进一步学习，仅停留在课程讲解的部分内容；同时，在完成课程实践作业时，任务估算不准确，实际完成设计的时间比预估要长。原因：课程项目周期短，成员之间的时间分配不均匀以及课下时间不够充足。
1.2 回顾你在这门课程中的投入与产出
（1）在软工实践课程当中，徐嘉琪编写了202行代码，冯梓轩编写了321行代码
（2）在团队项目，两位成员均参与了AI校园失物招领助手的设计与开发。其中，冯梓轩负责前端开发与界面UI设计，徐嘉琪负责后端开发，共同调整与测试项目。
（3）软工实践的各次作业每名成员分别花费的时间：
| 作业 | 花费时间 |
|---|---|
| 第一次团队作业 | 两天 |
| 第二次团队作业 | 一周 |
| 第一次团队项目作业 | 一周 |
| 第二次团队项目作业 | 两周 |
| 第三次团队项目作业 | 两周 |
| 第四次团队项目作业 | 一周 |
| （3）在软件工程课程上花费的时间 | |
| 累计时间 | 实际周均时间 |
| ---- | ---- |
| 168 | 14 |
| 1.3 令你印象最深刻的是哪一次作业或哪一场答辩？为什么这次作业或这场答辩令你印象深刻？ | |
| 印象最深的作业是第二次团队项目作业，原因：第二次团队项目作业的内容是对项目进行系统开发的设计，基于前期成果，完成对项目的原型设计与概要设计，在这个过程中，我负责项目后端开发，通过使用coze，为项目部署智能体豆包2.0Pro。在这个过程中，我通过自学完成，把 Coze 的 API 接入后端、处理鉴权、异步回调、错误重试时，我发现实际运行时会存在较多的问题，比如：大模型的返回格式不稳定，必须用结构化输出（JSON Schema）约束；Coze 的免费额度有限，需要设计本地缓存策略。这次作业让我走出了课堂的知识舒适区，亲历了一个“从未知→自学→踩坑→解决→总结”的完整闭环。 | |
| 二、总结收获 | |
| 2.1 展开说说你的软工实践故事 | |
| 我们需要在失物招领页面中嵌入一个智能对话助手，用户可以语音描述丢失/拾到的物品，由AI提取关键信息。我们选择了Coze平台提供的“豆包2.0 Pro”智能体。 | |
| 出现以下问题：Coze SDK 的文档不全，初始调用时一直返回 401 错误，排查后发现是 access_token 刷新机制没处理好；智能体返回的JSON字段不固定，有时“物品类别”字段叫 category，有时叫 type，导致前端解析失败；语音输入需先转文字再传给AI，但浏览器原生语音识别在火狐下不兼容。 | |
| 我花了一整天阅读Coze社区帖子和抓包分析，最终在SDK初始化参数中添加了自动刷新token的钩子。在后端增加了一层适配器模式：无论AI返回什么字段，都映射成统一的对象结构。改用 SpeechRecognition API 加上降级方案（弹出文本框提示用户手动输入）。对于智能的的使用也许注意，部分智能体是没有拍照识别功能的，比如deepseek，初始部署的deepseek无法使用照片功能，需要改用豆包。上线微信小程序时，需要申请账号，测试号无法调用智能体，且智能体使用非常不稳定，容易超时。 | |
| 2.2 介绍学习到的新技术或生产力工具以及它们给你带来了哪方面的帮助？ | |
| Coze（扣子）智能体平台 和 豆包2.0 Pro：让我们在无AI训练经验的情况下，快速构建一个能理解失物招领场景的对话模型。通过配置提示词和知识库，实现了从自然语言中提取物品类别、特征、地点、时间的能力。 | |
| deepseek：可以帮助我们修改撰写的程序代码，自己撰写的代码总是会出现错误，在任务时间较短下，ai可以很快速的帮我们修改好代码。 | |
| GitHub Projects + 燃尽图：我们按照课程要求，根据实际更新燃尽图。PPT中展示的燃尽图真实反映了我们“前期乐观、中期踩坑、后期赶工”的曲线。 | |
| json-server：通过阅读其 REST API 规范，能够在前端明确约定请求与响应的字段格式，并基于它快速构造模拟数据进行页面联调。它帮助我们前后端分离开发成为可能，完成对后端开发的引入。 | |
| 2.3 技术之外，这门课程还给你带来了哪些方面的提升？ | |
| 程序开发的团队协作能力：由于成员之间的专业与时间不同，几乎都是线上交流，导致对于项目的前后端开发语言环境等存在不适配，但是项目的前后端是需要最终整合才能实现的，就导致最终整合后出现较多问题，通过这次作业，对于前后端开发需要提前明确开发环境包括语言版本、依赖管理器、启动命令等。 | |
| 2.4 如果还有什么想记录的或者想说的，就写在这儿吧！ | |
| 这个项目让我第一次体会到，做一个“有用的小东西”和“做一个能稳定运行的小东西”之间，隔着一整个软件工程的知识体系。以前觉得写代码就是全部，现在觉得写代码只是最后10%的工作。那90%是：理解用户到底要什么、预判技术风险、设计降级方案、写出不是“自己看得懂”而是“团队任何人能接手”的文档。 | |
| 三、致谢 | |
| 在本课程的学习过程中，我衷心感谢任课教师的悉心指导与另一位成员对我的帮助与包容。感谢老师为我们讲解软件工程相关的知识，通过这个课程，丰富了我对于现在的计算机技术的认识。同时，在提出AI校园失物招领助手项目时，感谢老师对项目的指导。同时，我要向本项目的另一位成员——冯梓轩同学，致以诚挚的谢意。我们分别来自环境生态工程与光电信息科学与工程专业，课程安排与作息时间差异显著，整个项目周期内几乎全部采用线上沟通方式。在项目第二阶段的一次环境配置问题。由于我的本地开发环境（Node.js 14.x）与后端所需版本（≥16.x）不一致，导致 json-server 无法运行，而次日即为内部演示节点。冯梓轩同学通过线上指导，逐项排查环境变量、版本差异与依赖安装，并协助我使用 nvm 完成Node版本切换。此后，他在项目根目录下补充了详细的 README.md，明确标注了环境要求（Node.js ≥16.0）、全局依赖安装命令（npm install -g json-server）以及统一的启动脚本（npm run server）。这一事件使我深刻认识到：分布式团队在编码开始前必须以书面形式约定统一的开发环境基线，并固化至项目文档中。在整个开发与测试过程中，冯梓轩同学始终以客观态度对待我提交的缺陷报告，从未将问题归因于个人，而是从系统设计层面寻求解决方案，针对AI返回字段不稳定的问题，他主动负责最后的修改。这种专业且协作的态度，显著提升了我们的整合效率与最终产品的稳定性。 |
冯梓轩：
一、学期回顾
1.1 回顾你对于软件工程课程的想象
经过一个学期的课程学习以及完整的团队实践作业后，我对于软件课程的认知得到提升，但仍有不足之处。
（1）达到期待与目标的方面：
通过这门课程，我在小组项目中严格按照约定的编码规范（命名、缩进、注释、函数长度限制）写代码，学会了写出可读性高的代码：用有意义的方法名拆分长函数，用常量代替魔法数字，用断言或早期返回来减少嵌套层次。
（2）存在的不足：
任务估算严重不准，实际耗时远超预期：我们小组在拆分任务时，我常常乐观地认为一个需求分析文档2小时就能写完，结果实际花了6小时——因为要反复核对歧义、补充异常场景。编码阶段同样如此，一个看起来简单的导出功能，预估半天，结果因为文件格式兼容性和中文编码问题，比预估的时间要长。这种估算偏差打乱了我们的整体计划，导致后期只能压缩测试时间。
1.2 回顾你在这门课程中的投入与产出
（1）在软工实践课程当中，徐嘉琪编写了202行代码，冯梓轩编写了321行代码
（2）在团队项目，两位成员均参与了AI校园失物招领助手的设计与开发。其中，冯梓轩负责前端开发与界面UI设计，徐嘉琪负责后端开发，共同调整与测试项目。
（3）软工实践的各次作业每名成员分别花费的时间：
| 作业 | 花费时间 |
|---|---|
| 第一次团队作业 | 两天 |
| 第二次团队作业 | 一周 |
| 第一次团队项目作业 | 一周 |
| 第二次团队项目作业 | 两周 |
| 第三次团队项目作业 | 两周 |
| 第四次团队项目作业 | 一周 |
| （3）在软件工程课程上花费的时间 | |
| 累计时间 | 实际周均时间 |
| ---- | ---- |
| 188 | 16 |
| 1.3 令你印象最深刻的是哪一次作业或哪一场答辩？为什么这次作业或这场答辩令你印象深刻？ | |
| 印象最深的作业是第二次团队项目作业，原因：第二次团队项目作业的内容是对项目进行系统开发的设计，基于前期成果，完成对项目的原型设计与概要设计，作为负责前端开发的团队成员，在真实且受限的条件下——跨专业、纯线上协作、后端仅以json-server模拟、AI智能体能力不确定等问题，让我完成了从前端“页面实现者”向“全链路稳定性设计者”的能力跃迁。在与队友环境不一致、Coze SDK在浏览器端出现认证与跨域问题、AI返回字段不稳定的情况下，我不得不跳出对教程和理想接口的依赖，系统性地学习如何阅读英文SDK文档，针对后端字段与AI返回结构不一致的问题，我主动与另外的成员协商，将功能降级为“AI提取结构化信息 + 前端一键填充表单”，最终成功整合前后端的开发内容，完成项目的初步设计。为了彻底解决线上协作中“代码能跑但别人跑不了”的困境，我撰写了详尽的环境配置文档、统一启动脚本，把前端环境固化为团队基线。这一系列经历让我深刻认识到：软件工程前端开发的真正能力，不是写出视觉上可展示的界面，而是在接口不稳定、队友环境各异、第三方能力受限的前提下，依然能通过规范的设计、容错策略和清晰的降级逻辑，交付稳定可用的交互产品。 | |
| 二、总结收获 | |
| 2.1 展开说说你的软工实践故事 | |
| 队友负责后端与测试，其本地 Node.js 版本为 14.x，而我使用的版本是 18.x，导致 json-server 和 Coze SDK 在队友机器上无法运行，第一次整合时直接报错。我们的解决方法是在项目根目录添加 .nvmrc 文件锁定版本为 18，并在 README.md 中明确写出环境要求、全局依赖安装命令以及统一的启动脚本（如 npm run server 和 live-server 的代理配置），将前端运行环境固化为团队基线。 | |
| 理想功能与现实约束存在差距：我们最初设想用户通过对话即可让 AI 自动调用后端完成失物登记，但发现 Coze 免费版的浏览器 SDK 无法安全地向本地 json-server 发起 HTTP 请求。于是我们与团队协商，将方案降级为“AI 只做信息提取并以结构化文本展示，前端提供一个‘一键填充表单’按钮，由用户确认后手动提交”。我在界面上增加了清晰的状态提示和备用的文字输入入口，并为每一条用户路径设计了异常分支（如网络超时、识别失败时的重试机制），从而在有限的技术条件下交付了可用且可靠的功能。 | |
| 2.2 介绍学习到的新技术或生产力工具以及它们给你带来了哪方面的帮助？ | |
| Coze（扣子）智能体平台及豆包 2.0 Pro：通过学习 Coze 的浏览器端 SDK 文档和 API 调用机制，我掌握了将大模型对话能力嵌入 Web 页面的完整流程。这一工具帮助我们在没有机器学习背景的前提下，快速实现了从自然语言中提取失物特征（类别、地点、时间等）的功能，极大降低了智能交互的开发门槛。 | |
| Git + .nvmrc 环境固化：虽然 Git 是课程基础工具，但在本次线上协作中，我进一步实践了分支管理并通过 .nvmrc 文件和详细的 README.md 将 Node.js 版本、依赖安装命令、启动脚本固化为项目基线。这些工具帮助团队彻底解决了“在我电脑上能跑”的环境不一致问题。 | |
| 2.3 技术之外，这门课程还给你带来了哪些方面的提升？ | |
| 由于团队专业不同、作息错位，所有沟通依赖线上工具。我主动承担了环境配置文档的撰写和启动脚本的标准化工作，并录制了演示视频。这使我意识到：在分布式团队中，个人的“额外一步”（如写清楚README、统一命令别名）直接影响整个团队的产出效率，责任感不再局限于自己的代码，而是覆盖到团队协作的每个触点。 | |
| 2.4 如果还有什么想记录的或者想说的，就写在这儿吧！ | |
| 通过这门课程，我最大的收获是完成了从“编写可用代码”到“交付可靠软件”的思维转变。在技术层面，我系统掌握了前端与第三方智能体（Coze SDK）的集成方法，学会了防御式数据映射、乐观更新、降级方案设计等工程实践，并熟练运用 .nvmrc、Live Server 代理等工具固化团队开发环境，显著提升了线上协作的稳定性。在团队协作上，跨专业、纯线上的项目经历让我意识到：统一的环境基线、清晰的接口契约、详尽的文档与启动脚本，这些“额外工作”恰恰是分布式团队高效运转的基石，而责任感必须覆盖到整个开发链路的每一个触点。 | |
| 三、致谢 | |
| 在本课程的学习过程中，我衷心感谢任课教师的悉心指导。老师系统讲解了软件工程的需求分析、概要设计、测试流程及团队协作规范，极大丰富了我对现代软件工程方法的理解。特别是在我们提出“AI校园失物招领助手”项目时，老师从需求可验证性、技术风险识别等角度给予了关键指导，帮助我们明确了项目的核心边界与可行性。 | |
| 同时，我想感谢团队的另一位成员，在项目冲刺阶段，由于我们前期任务估算偏差较大，压缩了测试时间。徐嘉琪主动承担了回归测试和缺陷记录工作，她整理了一份清晰的问题清单，每条都附上了复现步骤和截图，使得我在修复时能快速定位。她从未因我的前端代码出现问题而抱怨，反而总是说“我们先看流程上哪里可以改进”。这种客观、建设性的态度，让我们在高压下依然保持了高效的协作节奏。 |