张誉怀-学期回顾：软件工程课程成果与收获

一、学期回顾

1.1 回顾你对于软件工程课程的想象

一、达到期待与目标的方面

  1. 团队协作流程落地

期待是掌握软件工程的团队协作模式，实际通过项目实践了Scrum迭代（每周站会、 Sprint 规划），用Git完成了代码分支管理与协同开发，从任务分工到模块整合的流程都跑通了，实现了“按软件工程规范协作”的目标。

  1. 项目全链路实践

期待是体验“需求-开发-测试-部署”的完整流程，实际参与了需求文档撰写、原型图设计、后端接口开发、单元测试编写，甚至跟着教程完成了项目的简易线上部署，覆盖了课程目标里的全链路环节。

  1. 工具链技能掌握

能够完成基本的硬件开发，编写硬件代码，完成硬件接线；参与到前端开发以及对后端开发加深了了解。

二、存在不足的方面

  1. 需求分析的精准度不足

没达到“深入挖掘用户真实需求”的期待，调研真实用户的环节略显草率，导致功能设计偏“完成任务”而非“匹配用户场景”，对需求优先级的判断也不够合理。

  1. 性能与健壮性设计缺失

没做到“优化项目性能、覆盖异常场景”的目标——课程重点在流程完整性，留给性能调优（比如接口响应慢）、异常处理（比如边界值报错）的时间和指导较少，项目只实现了基础功能，健壮性不足。

  1. 跨角色协同效率偏低

团队内开发与测试的协作节奏不顺畅（比如测试反馈滞后影响开发迭代），因为前期没建立固定的同步机制（比如每日测试小会），沟通成本没控制好，没达到“高效跨角色配合”的期待。

1.2 回顾你在这门课程中的投入与产出

  • 编写了1000行代码。

  • 承担了PM职责和硬件开发

  • 软工实践的各次作业分别花费的时间：

作业 花费时间
第一次团队作业 3 days
第二次团队作业 7 days
第一次团队项目作业 7 days
第二次团队项目作业 14 day
第三次团队项目作业 14 days
第四次团队项目作业 14 days
  • 在软件工程课程上花费的时间
累计时间 实际周均时间 预计周均时间
1416h 102h 90h

1.3 令你印象最深刻的是哪一次作业或哪一场答辩？为什么这次作业或这场答辩令你印象深刻？

印象最深刻的是最后一次答辩，通过这次答辩，老师让我们意识到我们项目所具有的巨大潜力。同时这次答辩过程相对来说“跌宕起伏”，因为在演示功能的过程中，项目出现了bug，但是我们也现场修好了bug。

二、总结收获

2.1 展开说说你的软工实践故事

硬件选型&传感器调试阶段（第二次项目实践）

  • 实例：调试阶段，我们选用的浊度传感器在静置水样中数据稳定，但放到流动的景观湖水中后，数据波动极大；另外，传感器采集数据的频率（1次/秒）与AI模型接收数据的频率（1次/5秒）不匹配，导致数据堆积，模型无法及时处理。

  • 经验总结：硬件选型前需做“实地环境适配测试”，优先选择抗干扰性强、适配目标水域工况的传感器（比如针对有悬浮物的水域，选带自清洁功能的传感器）；同时，提前同步“传感器硬件参数”与“AI模型数据要求”，明确数据采集频率、格式、传输协议，避免硬件与算法脱节。

2.2 介绍学习到的新技术或生产力工具以及它们给你带来了哪方面的帮助？

1. 传感器数据采集与可视化工具：Arduino IDE + Serial Plotter

  • 应用场景：调试水质传感器时，实时采集传感器输出数据，观察数据波动规律

  • 具体帮助：在发现“流动景观湖水数据波动大”的问题时，通过Serial Plotter实时绘制数据曲线，清晰对比出“静置水样”与“流动水样”的数据流差异（流动水样曲线波动幅度是静置的3倍），帮助我们快速定位问题核心——传感器抗水流干扰能力不足，而非硬件故障；同时通过该工具验证了“带自清洁功能传感器”的适配效果，确认其数据波动幅度降低60%，为硬件选型提供了直观数据支撑。

2. 数据协议调试与同步工具：MQTT X（物联网通信协议调试工具）

  • 应用场景：对接传感器硬件与AI模型的数据传输环节，调试数据采集频率、格式适配问题

  • 具体帮助：针对“传感器1次/秒采集频率与AI模型1次/5秒接收频率不匹配”的问题，通过MQTT X模拟数据传输过程，直观看到数据堆积的具体表现（30秒内堆积15条未处理数据）；同时借助工具的“数据节流配置”功能，测试出最优的中间层数据处理方案（每5条数据合并为1条有效数据传输），成功解决数据堆积问题，确保传感器与AI模型的通信链路顺畅，避免了算法模块因数据拥堵无法正常处理的情况。

3. 传感器校准与性能测试技术：标准溶液校准法 + 多工况模拟测试

  • 应用场景：传感器精度校准、不同环境（水流速度、悬浮物含量）下的性能测试

  • 具体帮助：在硬件选型前，用标准缓冲溶液对候选传感器进行校准，排除了2款校准后误差仍超±0.5的传感器；针对目标水域的浮萍、泥沙环境，用“清水+泥沙”“清水+浮萍”模拟不同悬浮物含量的水样，通过该测试技术筛选出抗悬浮物干扰能力最强的传感器（数据误差控制在±0.2内），直接规避了“实地测试数据失真”的风险，让硬件选型更贴合实际应用场景。

2.3 技术之外，这门课程还还给你带来了哪些方面的提升？

  1. 跨角色协同与高效沟通能力

  2. 项目涉及硬件调试、算法训练、数据传输3类不同分工，初期硬件团队和算法团队因“数据频率定义不一致”产生分歧，硬件按1次/秒采集，算法按1次/5秒接收，导致数据堆积。通过这次问题，我学会了用“技术对齐文档”替代口头沟通：把传感器参数、模型需求、传输协议整理成统一表格，每次参数变更都标注版本、同步全员，避免了“各做各的”的内耗。后续遇到传感器低温偏差问题时，硬件和算法同学能快速基于文档定位问题，共同设计温度补偿方案，沟通效率提升了70%。

  3. 复杂问题的拆解与根因定位能力

  4. 面对“流动水样数据波动大”的问题，我没有直接选择更换传感器，而是学会了分层拆解问题：先通过Serial Plotter对比“静置/流动”“有无悬浮物”等不同工况下的数据曲线，排除“硬件故障”的可能；再查阅传感器手册，发现是探头抗水流冲击能力不足。这种“现象观察→变量控制→根因定位”的思路，让我避免了“头痛医头”的盲目操作，后续解决低温数据偏差、设备短路等问题时，都能快速锁定核心矛盾。

  5. 从“实验室”到“真实场景”的落地思维

  6. 初期我们仅在实验室用标准溶液测试传感器，模型准确率达95%，但实地测试时准确率骤降。这次落差让我深刻理解：技术方案必须匹配真实应用场景。此后我养成了“先调研场景、再设计方案”的习惯，比如针对景观湖的浮萍、泥沙环境，主动设计“悬浮物干扰模拟测试”，筛选抗干扰传感器；针对物业运维人员的需求，增加“异常数据预警推送”功能，让项目从“技术原型”变成“能落地的实用产品”。

  7. 严谨的文档与参数管理习惯

  8. 答辩前因模型阈值变更未同步，导致演示失误的教训，让我意识到规范记录的重要性。此后我牵头建立了“项目变更日志”，记录每次硬件参数、模型阈值、代码逻辑的调整原因、影响范围，并同步给所有成员。这种习惯不仅避免了后续联调、测试的重复踩坑，也让项目交接和答辩复盘变得更清晰，同时也为课程报告积累了完整的过程性材料。

  9. 抗压与应急问题的处理能力

  10. 实地测试时突发传感器进水短路，导致测试中断，团队面临答辩前无法获取真实数据的压力。当时我快速牵头分工：一组排查硬件防水密封问题，更换接口密封圈；另一组整理实验室已有数据，补充工况分析说明。最终不仅修复了硬件，还通过“实验室数据+工况模拟分析”的组合方案，完成了答辩汇报。这次经历让我学会了在突发状况下冷静分工、优先解决核心问题，而不是陷入慌乱。

2.4 如果还有什么想记录的或者想说的，就写在这儿吧！

通过这门课，我找到了自己在计算机领域真正感兴趣的方向，上这门课之前自己一直对未来没什么规划，感觉对计算机也快没啥兴趣了。但通过这门课，我意识到自己对于可触可感的硬件产生浓厚的兴趣，很享受从零开始搭建创造的过程，进而确定了“具身智能”这一兴趣方向。

三、致谢

首先，我要衷心感谢我的团队伙伴们。还记得硬件调试阶段，我们为了攻克 “流动水样数据波动大” 的难题，一起在实验室熬夜对比传感器数据曲线，轮流守着 Serial Plotter 记录不同工况下的参数；算法模块陷入 “真实水样模型准确率骤降” 的困境时，是大家一起翻查文献、讨论数据增强方案，从实验室标准水样到实地采集的 100 多组水样，逐一标注、训练模型；更难忘实地测试时传感器突发进水短路，我们兵分两路，一组紧急排查防水密封问题，一组整理备用数据，硬是在答辩前一晚完成了修复和数据补充。没有大家的分工协作、互相补位，这个横跨硬件、算法、数据的项目，不可能顺利走到最后。谢谢你们，让我在协作中懂得了 “1+1>2” 的真正含义。
其次，我要感谢课程的指导老师。我是一个需要额外时间学习的人，课下也向老师问了很多问题，老师每次都非常耐心的解答，这真的给我很大的鼓励；到答辩时，您帮助我们意识到我们项目的巨大潜力以及未来的发展方向。每一次指导都精准点醒了陷入瓶颈的我们，让我们少走了很多弯路。您不仅教会了我们软件工程的方法，更让我们明白 “落地思维” 对项目的重要性。

吴飞龙-学期回顾

一、课程回顾

1.1 回顾对软件工程课程的想象

原本以为软件工程就是写代码、做产品，后来才明白前期的准备工作也很重要。作为需求组组长，这学期主要负责协调组内分工，参与需求分析和文档编写。虽然对整个流程有了初步了解，但在需求变更时应对不够灵活，主要是因为对技术实现细节了解还不够深入，需要多和技术同学沟通。

1.2 回顾课程中的投入与产出

代码编写：虽然作为需求组组长没有参与核心代码开发，但协助设计了部分前端页面布局，参与讨论了3个页面的功能实现方案，编写了少量配置脚本约150行。

项目参与：在"宿舍用水监测系统"项目中，负责需求组的日常协调工作，包括收集同学意见、整理需求文档、与前后端同学对接需求，完成了需求分析、需求文档及附属要求的编写。

各次作业花费时间：

作业 花费时间
第一次团队作业 8 小时
第二次团队作业 10 小时
第一次团队项目作业 25 小时
第二次团队项目作业 30 小时
第三次团队项目作业 22 小时
第四次团队项目作业 18 小时
在软件工程课程上花费的时间 累计时间 实际周 均时间 预计周 均时间
150h 12.5h 10h

1.3 印象最深刻的作业 / 答辩

让我印象最深的是第三次团队项目作业——需求分析文档定稿与答辩。当时为了整理文档，我们组反复修改了好几次，特别是和后端同学讨论接口格式时遇到了不少问题。记得有一次因为对"异常提醒"功能的理解不一致，我们专门开了两次线上会议才确定下来。答辩时老师指出我们的需求范围有点广，这个反馈让我们意识到做需求分析时既要全面又要抓住重点。

二、总结收获

2.1 软工实践 故事：经验与实例分析

  • 第一次团队项目：需求调研 ——"从用户中来，到用户中去"
    学到的经验：需求调研不能只看表面，要真正了解用户痛点。
    具体事例：项目初期我们通过问卷收集到"学生关注水质安全"的反馈，但后来发现大家更在意用水量统计和异常提醒功能。根据这些反馈，我们调整了需求优先级，把实时提醒功能放在了文档最前面。

  • 第二次团队项目：指标界定 ——"标准为基，场景为纲"
    学到的经验：关键指标需要结合实际情况来定。
    具体事例：在确定浊度监测精度时，我们参考了国家标准，但考虑到宿舍用水主要用于洗漱，最终将精度定为0.01NTU，既满足安全需求，又避免了过度设计。

  • 第三次团队项目：文档编写 ——"规范先行，协作无忧"
    学到的经验：写文档要细致，每个功能点都要说清楚。
    具体事例：在写"历史数据查询"功能时，我们一开始只写了"可以查看历史数据"，后来补充了"支持按天/周/月筛选""最多显示30天数据"等细节，这样开发同学就知道该怎么实现了。

  • 第四次团队项目：跨团队对接 ——"换位思考，精准同步"
    学到的经验：和开发同学沟通时，要主动确认他们是否理解需求。
    具体事例：在对接前端同学时，我们画了简单的流程图说明页面跳转逻辑，还建了个共享文档随时更新讨论结果，这样大家就不用反复问同样的问题了。

2.2 学习到的新技术 / 生产力工具及帮助

  • 规范写作：学会了按照标准格式写需求文档，知道每个章节应该怎么组织内容。
  • 协作工具：熟悉了在线文档的多人编辑功能，能用表格整理需求清单。
  • 沟通技巧：明白了在会议上如何表达需求重点，会做会议纪要记录讨论结果。

2.3 技术之外的提升

  • 需求整理能力：能把杂乱的意见分类整理，找出核心需求。
  • 团队配合意识：学会了及时同步需求进展，避免信息不对称。
  • 文档意识：养成了写文档时就考虑可读性的习惯，会用清晰的标题和分段。

2.4 自由发挥

这次项目让我发现自己对需求分析挺感兴趣的，打算以后多学习这方面的知识。建议学弟学妹们在做需求时多和技术同学交流，不要怕问问题。希望以后能有机会参与更多实际项目，把课堂上学到的方法应用到真实场景中。

三、致谢

这学期能顺利完成项目，首先要感谢404-Team Not Found的全体成员。每一个模块的推进，都离不开团队成员的通力配合，是大家的各司其职、互帮互助，才让"宿舍用水监测系统"项目从想法变成了现实。

感谢指导老师，每次答辩后都给了很实在的建议，特别是关于如何精简需求范围的建议让我受益匪浅。还要感谢参与调研的同学们，你们的真实反馈是我们改进需求的重要依据。这段经历让我学到了很多课堂之外的东西，也让我更明白了团队合作的重要性。

涂世为 - 软工实践学期总结

一、学期回顾

1.1 回顾你对于软件工程课程的想象

•回顾目前的所学所练所得：

在课程开始前，我以为软件工程的核心是“如何写出复杂的代码”或者“掌握最新的框架”。我曾天真地认为，只要技术够牛，产品自然就会好。但通过这学期的摸爬滚打，尤其是作为需求组的一员，我最大的收获是明白了“做正确的事”比“正确地做事”更重要。我学会了如何将用户口中模糊的“我想看水质好不好”，转化为开发能看懂的“Echarts折线图”和“阈值报警逻辑”。在需求调研、业务流程梳理以及原型设计方面，我达到了自己的预期，真正体验了一把“产品经理”的实操感。

1.2 回顾你在这门课程中的投入与产出

在团队项目《智感清浊 - 学生宿舍用水监测系统》的设计与开发中，我承担的核心角色是：需求分析师 / 业务流程设计 / 原型交互设计，全程负责需求挖掘、梳理、转化及原型输出，搭建起用户与开发团队之间的沟通桥梁。
软工实践各次作业花费时间统计：

作业 花费时间
第一次团队作业 6 小时
第二次团队作业 12 小时
第一次团队项目作业 30 小时
第二次团队项目作业 25 小时
第三次团队项目作业 18 小时
第四次团队项目作业 10 小时

软件工程课程整体时间投入统计：

累计时间 实际周均时间 预计周均时间
101 (h) 6.5 (h) 8 (h)

1.3 令你印象最深刻的是哪一次作业或哪一场答辩？为什么？

令我印象最深刻的是最后一次团队项目作业（Alpha版本冲刺与发布）。
原因：那是在需求文档历经无数次打磨修改后，我第一次看到抽象的需求逻辑转化为可交互的实体软件。当我在测试环境点击“水质详情”，页面跳转逻辑、报警弹窗触发时机完全贴合我绘制的流程图（Flowchart）时，那种“业务逻辑被代码完美复现”的成就感难以言喻。同时，这次作业也是组内争议最激烈的一次——为保障核心业务顺利上线，我提议砍掉“社交分享”功能，与开发组反复沟通博弈，最终达成共识。这次经历让我深刻理解了敏捷开发中“取舍”的艺术，也懂得了需求优先级排序对项目落地的关键作用。

二、总结收获

2.1 展开说说你的软工实践故事

• 故事一：拒绝“一句话需求”，精准拆解需求颗粒度
• 经验总结：用户（或指导老师）提出的需求往往偏向感性描述，需求分析师的核心职责，是将感性需求翻译成理性、无歧义的技术语言，为开发提供清晰指引。
• 实例分析：在定义“历史数据查询”功能时，我没有停留在“支持查询历史数据”的模糊描述上，而是将其拆解为三个具体的用例：1. 支持按“日/周/月”三个维度切换数据视图，适配不同用户查看习惯；2. 缺省数据用“-”补齐而非留白，保证页面展示统一性；3. 导出Excel文件时，文件名自动包含“设备编号+查询时间戳”，便于用户归档管理。同时，通过绘制详细的泳道图，明确用户点击按钮后，前端参数传递规则、后端数据查询范围及返回格式，彻底消除了开发过程中的理解歧义，大幅降低返工率。
• 故事二：应对需求蔓延，学会科学说“不”
• 经验总结：开发资源和项目周期始终有限，无节制接纳新增需求会导致核心功能弱化、项目进度失控，科学的范围管理是项目成功的关键。
• 实例分析：项目中期，组内有成员提议新增“多设备联动”功能，丰富产品体验。但当时距离Beta版本发布仅剩一周，核心的“单设备水质报警”功能仍需优化打磨。我依据MoSCoW原则，梳理剩余开发工时与核心功能优先级，将“多设备联动”标记为“Won't have for now”，并向团队说明取舍理由，最终说服大家集中精力攻坚核心功能，确保了版本按时上线且稳定性达标。这次经历让我学会了在压力下平衡需求与资源，掌握了科学的范围管理方法。

2.2 学习到的新技术或生产力工具及帮助

  1. Axure RP / 墨刀 (原型设计工具)：
    帮助：实现了需求表达从“口头描述”到“可视化原型”的升级。通过制作高保真原型，后端同学在编写接口前就能直观看到页面布局、交互逻辑及数据展示形式，提前预判需求细节，有效减少了“开发结果与需求预期不符”的返工问题，提升了跨团队协作效率。
  2. ProcessOn / Draw.io (UML建模工具)：
    帮助：深入掌握了状态机图（State Machine Diagram）的绘制与应用。在处理设备“离线-在线-报警-恢复正常”的状态流转逻辑时，一张清晰的状态机图能够精准呈现各状态的触发条件、流转路径及异常处理方式，比千言万语的文字描述更直观、更严谨，为开发团队提供了精准的逻辑依据。
  3. Apifox (接口文档协作工具)：
    帮助：虽不参与后端代码编写，但通过Apifox学会了阅读和校验接口文档。我能提前核对后端返回的数据结构、字段含义是否匹配前端展示及需求逻辑，及时发现接口设计与需求不符的问题并沟通调整，实现了“需求定义-开发实现-功能验证”的闭环管理。

2.3 技术之外的能力提升

  1. 逻辑闭环思维：从前思考问题多为线性逻辑，如今习惯以“前置条件-触发事件-核心流程-后置状态-异常处理”的完整链路思考功能设计，思维更缜密，能提前规避潜在漏洞。
  2. 跨角色沟通与同理心能力：作为需求组成员，我是连接“非技术用户”与“专注技术开发”团队的桥梁。在沟通中逐渐学会“对用户讲场景、对开发讲逻辑”，既能理解用户的潜在需求，也能体谅开发的技术边界，实现高效跨角色协作。
  3. 抗压与问题解决能力：面对项目 Deadline 逼近、突发 Bug 影响进度等情况，学会了摒弃抱怨情绪，优先聚焦“当下可落地的补救措施”，快速协调资源、调整方案，提升了应急处理能力。

2.4 补充寄语与遗憾

这门课或许是大学里最“折磨人”但也最贴近职场实际的课程——它没有标准答案，只有在需求、资源、进度之间不断权衡的最优解。
我想真诚叮嘱：不要轻视文档编写，也不要忽视需求打磨。代码写错了可以重构，但需求理解偏差可能导致整个架构推翻重来。在敲下第一行代码前，多花一小时在白板上梳理流程、验证逻辑，绝对是这学期性价比最高的投入。

三、致谢

一个学期的软工实践之旅，离不开团队每个人的付出，而我最想感谢的，是我们组的组长 张誉怀。作为团队的核心统筹者，他不仅要把控项目整体进度、协调各角色工作，还始终耐心包容需求组的反复调整，给予我很多宝贵的指导。

刘斌瑞-软工实践学期总结

一、学期回顾

1.1 回顾目标

最初期待这门课能掌握完整的项目开发流程。最开始是想学后端的开发，然而因为团队分工，我实际承担前端业务的开发。

达成的目标：

  • 在团队项目中，能从 0 开始搭建一个较完善的前端系统；
  • 能与后端接口完成相应的交互；
  • 掌握了页面模块化设计、全局状态管理、组件复用等工程化开发能力；
  • 能独立完成业务模块的 CRUD 实现；
  • 对用户体验也进行了优化；
  • 在课程专业知识方面，对软件生命周期、需求分析方法、UML 中比较重要的几种图表的绘制、DAO 设计模式、DTO 与 VO 设计等知识掌握得比较好，基本达成了自己的学习预期。

不足：

  • 对大型项目的架构分层理解较浅；
  • 对代码的标准化结构和团队合作有待提升；
  • 若交互比较复杂，实现起来可能与预期不符，需要较长时间修改才能成功，该能力有待提升；
  • 在课程内容学习方面，对于分层架构模式的理解不够深入；
  • 对于架构图的绘制不太熟练；
  • 对 MVC/MVP 模式、敏捷开发原则的理解不够深入，也与自己的实际开发经验太少有关；
  • 需要不断做项目、分析他人优秀项目来持续提升。

1.2 课程投入与产出

  • 编写代码量： 约 6000 行

    我在项目中承担了前端页面开发和主要功能的交互逻辑实现。

  • 各次作业花费时间：

    作业 花费时间
    第一次团队作业 4h
    第二次团队作业 3h
    第三次团队作业 30h
    第四次团队作业 10h

  • 课程总投入时间：

    累计时间 实际周均时间 预计周均时间
    70h 5h 6.5h

1.3 印象最深刻的答辩

最深刻的是最后一次答辩。本次需展示完整的系统功能，但在答辩前一天我们改动了一部分代码，相关接口未充分测试，导致答辩时出现了小事故。

当时确实比较慌张，好在问题处理不难——后端同学用了几分钟修改并重新部署，系统便恢复正常运行，最终结果也符合预期。

这次经历让我体会到：

  • 接口一定要全面测试，不能遗漏任何一个；
  • 测试时应重点覆盖特殊情况，以验证程序的健壮性。

二、总结收获

2.1 软件工程实践

经验 1：页面职责分离是效率基础
最初将水源数据的“列表展示”和“表单编辑”写在同一个页面，导致代码冗余、维护困难。
后来拆分为：

  • WaterSourceView.vue（列表）
  • WaterSourceForm.vue（表单组件）

后续新增“批量导出”功能时，仅需在列表页调用表单组件的参数，开发效率显著提升。

经验 2：抽象通用功能、标准化组件
通过抽象通用功能、实现标准化组件，达成代码复用与降低维护成本的目标：

  • 将 MainHeader.vue 抽象为全局通用导航组件，在多个页面复用，确保一致的导航体验；
  • 封装 WaterSourceForm.vue 组件，整合水源信息的增、删、改、查全流程操作；
  • 将设备配置单独封装为组件（因其相对独立），便于错误定位与修复。

2.2 学习到的新技术/工具

  • Axios 拦截器：统一管理请求/响应逻辑，减少重复代码，提升接口调用稳定性；
  • Vue 组件化封装：如 MainHeader.vue 等通用组件，实现风格统一，降低重复开发工作量；
  • 正则表达式：用于解决 Dify 报告格式混乱问题，实现内容自动化清洗，提升文档整理效率；

    虽然复杂，但非常重要，只能硬着头皮学习；

  • 千问、DeepSeek 等 AI 工具：
    • 帮助设计和优化项目框架结构（因自身经验不足）；
    • 辅助定位报错位置（尤其面对英文错误信息中的专业术语）；
    • 提高调试效率，加速问题解决。

2.3 技术之外的提升

  • 团队协作意识：
    学会按“职责模块”拆分任务，避免重复开发；理解“代码规范是团队协作的基础”。

  • 问题解决能力：
    面对格式混乱、交互 bug 等问题时，不再慌张，而是：

    • 查看控制台日志；
    • 打印调试日志；
    • 逐步排查定位问题。

    虽然调试繁琐，但意识到这是开发中不可或缺的能力。

  • 用户体验思维：
    从“实现功能”转变为“优化体验”：

    • 初期页面仅完成基本交互；
    • 后续通过自测发现不符合用户直觉的操作；
    • 优化措施包括：添加 loading 状态、hover 动画等，使系统更易用。

三、致谢

特别感谢团队的后端同学——
整个系统的最终部署上线，以及报告与 AI 工具流的交互逻辑均由他实现。

同时也感谢团队中每一位辛苦付出的成员！

林舒欣-学期回顾：软件工程课程成果与收获

一、学期回顾

1.1 回顾你对于软件工程课程的想象

一、达到期待与目标的方面

  1. 文档与成果整合体系落地 ：掌握软件工程中规范的文档管理与成果整合方法，实际通过项目实践，建立了从原始材料收集、分类整理到最终成果输出的完整流程，完成了项目各阶段报告、会议纪要等材料的系统性整合，同时形成了标准化的文档模板，实现了“文档可追溯、成果可呈现”的目标。
  2. 可视化成果输出实践落地 ：实际独立完成了项目各阶段汇报PPT制作（含需求分析、进度汇报、终期答辩等），并使用剪映制作了1条时长4分钟的项目实践vlog，完整记录项目关键环节，成功将vlog融入汇报答辩，覆盖了文档组与测试组核心的成果呈现与输出工作。
  3. 测试与成果呈现协同能力掌握： 能够独立设计测试用例，完成项目功能模块的测试效果验证并同步问题；熟练使用PowerPoint制作逻辑清晰、重点突出的汇报PPT，掌握剪映的视频剪辑技巧完成项目vlog制作。

二、存在不足的方面

  1. 材料整合的时效性不足： 部分阶段因各小组材料提交滞后，导致PPT内容更新不及时；同时对材料的筛选提炼不够精准，初期PPT存在文字冗余、重点不突出的问题，影响了汇报效率。
  2. 测试用例设计的全面性欠缺 ：没做到“全场景覆盖、规避潜在风险”的目标，课程实践中更侧重基础功能测试，对边界场景、异常工况的测试用例设计不足，导致部分隐藏问题未在测试阶段发现，项目质量把控存在疏漏。
  3. 跨小组信息同步衔接不顺畅 ：初期文档组与开发组、测试组的信息同步缺乏固定机制，开发组功能迭代后未及时同步更新，导致PPT汇报内容与项目实际进度存在偏差，vlog素材收集也出现短暂滞后，未达到“高效协同推进”的期待。

1.2 回顾你在这门课程中的投入与产出

  • 完成4份项目核心PPT制作（含需求汇报、中期进度、终期答辩等），均使用PowerPoint制作；整合项目材料共计2.5万余字；使用剪映制作1条时长4分钟的项目实践vlog，用于汇报答辩展示。
  • 承担文档组核心成员与测试组成员职责，负责全流程材料整合、PPT与vlog等成果制作、测试效果验证与问题反馈工作。
  • 软工实践的各次作业分别花费的时间：
    作业 花费时间
    第一次团队作业 3h
    第二次团队作业 15h
    第三次团队作业 24h
    第四次团队作业 10h
  • 在软件工程课程上花费的时间
累计时间 实际周均时间 预计周均时间
96h 8h 6.5h

1.3 令你印象最深刻的是哪一次作业或哪一场答辩？为什么这次作业或这场答辩令你印象深刻？

印象最深刻的是制作vlog的那次汇报答辩。为了将vlog完美融入汇报，从vlog的素材收集、内容筛选，到用剪映进行剪辑、配乐、加字幕，再到配合vlog调整PPT的汇报逻辑与节奏，整个过程需要与不同组员深度沟通。比如收集素材时，要和开发组、测试组的组员确认项目关键环节的拍摄节点；剪辑过程中，要和组员讨论vlog的呈现重点，确保内容贴合汇报主题；PPT与vlog衔接环节，大家一起反复打磨切换节奏，避免出现逻辑断层。这次经历彻底打破了组员之间此前相对独立的工作状态，极大增强了我们之间的交流与协作默契，让我深刻体会到团队协作中“充分沟通”的重要性，也让这次汇报答辩成为我们团队协作氛围提升的重要转折点。

二、总结收获

2.1 展开说说你的软工实践故事

vlog制作与汇报答辩筹备阶段（第三次项目实践）

  • 实例：筹备vlog相关汇报答辩时，初期遇到了诸多问题：
  1. vlog素材分散在不同组员手中，部分关键环节素材缺失，需要重新协调组员补拍；
  2. 用剪映剪辑时，对视频节奏把控不准，4分钟的时长内难以平衡“环节完整性”与“内容简洁性”；
  3. PPT与vlog的衔接逻辑不清晰，单纯播放vlog后直接讲解，导致汇报连贯性不足。
    针对这些问题，我们多次召开小组讨论会议，组员们分别从自身工作角度给出建议，开发组补充了功能开发关键节点的素材，测试组协助梳理了vlog需突出的测试核心环节，最终确定了“PPT引入-vlog展示-重点解读”的汇报逻辑，完成了vlog剪辑优化与PPT调整。
  • 经验总结：成果输出前需提前开展跨角色沟通，明确素材收集的范围、标准与时间节点，避免后期补拍浪费时间；使用剪映等工具制作视频时，应先梳理内容框架，根据汇报时长合理规划各环节时长，确保节奏流畅；可视化成果（PPT、vlog）融合汇报时，要建立清晰的逻辑衔接，让不同形式的成果相互补充，提升汇报效果；而充分的组员交流是解决这些问题的核心，能让成果制作更贴合团队共识与汇报需求。

2.2 介绍学习到的新技术或生产力工具以及它们给你带来了哪方面的帮助？

1. 汇报呈现核心工具：PowerPoint

  • 应用场景：项目各阶段汇报PPT制作，包括需求分析、进度汇报、vlog配套汇报答辩PPT等，重点实现内容逻辑梳理、数据可视化呈现、与vlog的节奏衔接设计。
  • 具体帮助：通过学习PowerPoint的版式设计、数据图表制作、动画切换等功能，解决了初期PPT文字冗余、重点不突出的问题。尤其是在vlog配套汇报PPT制作中，利用分栏布局设计了“vlog关键画面预览+核心内容解读”的页面，让观众能快速对应vlog内容理解汇报重点；借助动画切换功能，实现了PPT与vlog播放的平滑衔接，提升了汇报的连贯性与专业度，让汇报内容更易被理解和接受。

2. 视频制作工具：剪映

  • 应用场景：项目实践vlog制作，包括素材裁剪、转场特效添加、字幕制作、背景音乐搭配等，最终完成1条4分钟的汇报用vlog。
  • 具体帮助：剪映的可视化操作界面降低了视频制作的门槛，通过其素材裁剪功能，我能精准筛选出项目关键环节的素材，去除冗余内容；转场特效与背景音乐功能提升了vlog的观赏性，避免了单纯素材拼接的生硬感；字幕添加功能则确保了观众能清晰获取vlog中的关键信息。更重要的是，在剪辑过程中，我通过与组员沟通确定剪辑方向，借助剪映的实时预览功能，快速根据组员建议调整内容，高效完成了符合团队共识的vlog制作，为汇报答辩增添了生动的动态展示素材。

2.3 技术之外，这门课程还还给你带来了哪些方面的提升？

  1. 跨角色沟通与协作默契培养 ：初期开展工作时，我习惯独立完成材料整合与PPT制作，较少主动与其他组员沟通，导致成果与团队实际工作重点存在偏差。而vlog制作与相关汇报答辩的筹备过程，让我深刻意识到跨角色沟通的重要性。我学会了主动发起沟通、精准传递需求：比如向开发组明确vlog素材的拍摄要求，向测试组确认需突出的核心测试环节；同时也学会了倾听不同角色的建议，从团队整体汇报需求出发调整工作内容。这种沟通模式不仅让vlog制作与汇报顺利完成，也提升了后续所有工作的协作效率，让团队协作更具默契。
  2. 复杂任务的拆解与问题解决能力： 面对复杂任务，初期我不知从何入手，陷入了手忙脚乱的状态。通过组员间的讨论，我学会了将复杂任务拆解为可落地的子任务：先拆解为“素材收集、vlog剪辑、PPT制作、逻辑衔接优化”四个子任务，再明确每个子任务的负责人、完成时间与质量标准。针对剪辑节奏不准、逻辑衔接不顺畅等问题，通过多次小组彩排、逐环节优化，让我后续面对多任务工作时也能有条不紊地推进。
  3. 成果呈现的用户思维与细节把控能力： 初期制作vlog时，我仅关注素材的完整性，忽略了观众的观看体验，导致视频节奏拖沓、重点不突出。经组员提醒后，我开始删减冗余素材，突出项目关键环节；在PPT制作中，也注重细节打磨，比如统一字体格式、优化图表样式、精准匹配vlog节奏。这种用户思维与细节把控习惯，让最终的汇报成果获得了良好反馈，也让我明白，无论是文档、PPT还是vlog，只有兼顾完整性与可读性，才能真正发挥成果呈现的价值。
  4. 团队共识建立与问题协同解决能力： vlog制作与汇报筹备中遇到的素材缺失、节奏不顺畅等问题，都不是单一个人能解决的。通过多次小组讨论，逐步建立了团队共识。比如在调整vlog节奏时，有人提出保留开发环节细节，有人建议突出测试效果，最终我们协商确定了“兼顾核心环节、突出成果价值”的原则。这种协同解决问题的经历，让我学会了在团队中换位思考，理解不同角色的工作重点，通过达成共识推动工作高效推进，也提升了自身的团队协作素养。

2.4 如果还有什么想记录的或者想说的，就写在这儿吧！

这门软件工程课程最宝贵的收获，不仅是掌握了PPT制作、剪映剪辑等实用技能，更让我理解了“团队协作”的核心要义——充分的沟通与相互的理解。通过一次次沟通讨论，我们不仅完成了优质的汇报成果，更拉近了组员间的距离。也正是这次经历，让我明确了自己在团队中的定位，找到了工作的价值感。这门课让我明白，软件工程从来不是单个人的战斗，而是团队协同的成果，而良好的沟通则是协同的核心。

三、致谢

首先，我要衷心感谢我的团队伙伴们。特别感谢在vlog制作与相关汇报答辩筹备过程中，大家给予的全力支持与配合。还记得为了收集完整的vlog素材，开发组的伙伴们特意补拍了功能开发的关键环节；为了优化vlog内容，测试组的伙伴们耐心帮我梳理了需要突出的测试核心要点；在调整PPT与vlog的衔接节奏时，我和文档组的成员逐字逐句打磨汇报话术。正是这种毫无保留的交流与互相支持，我们才能顺利完成vlog制作与汇报，也让我们的团队协作更加默契。谢谢你们，让我在协作中感受到了团队的力量，也明白了充分沟通对于工作推进的重要意义。
其次，我要感谢课程的指导老师。您的指导不仅帮我们顺利完成了汇报，更让我学会了如何从受众角度优化成果呈现，提升了我的实践能力与思考维度。感谢您一学期以来的悉心指导，让我在软件工程领域收获了知识与成长。

李泽-学期回顾

一、学期回顾

1.1 回顾对软件工程课程的想象

  • 在课程开始前，我对软件工程的想象停留在 “系统学习编程技巧，掌握各类开发工具” 的层面，期待能通过课程将理论知识转化为实际项目开发能力，理解完整的项目流程。
    从实际收获来看，课程完全实现了我的核心期待：通过 “智感清浊 - 学生宿舍用水监测系统” 项目，我全程参与了需求调研、文档编写、需求拆解等关键环节，清晰掌握了从用户诉求到功能落地的全流程，理解了需求分析在整个项目中的 “地基” 作用。
    但仍存在不足：对项目风险预判能力不足，在需求变更时未能及时提出有效的应对方案，主要原因是缺乏跨模块协作的全局视野，对技术实现的复杂度认知不够。

1.2 回顾课程中的投入与产出

  • 代码编写：作为需求组成员，核心聚焦需求分析与文档编制，未直接参与核心代码开发，辅助编写需求相关配置脚本约 150 行。
    项目参与：全程参与 “智感清浊 - 学生宿舍用水监测系统” 的设计与开发，担任需求组成员，负责前期需求调研、指标界定、需求文档编写及跨团队需求对接工作。
    各次作业花费时间：
作业 花费时间
第一次团队作业 8 小时
第二次团队作业 10 小时
第一次团队项目作业 25 小时
第二次团队项目作业 30 小时
第三次团队项目作业 22 小时
第四次团队项目作业 18 小时
  • 在软件工程课程上花费的时间
累计时间 实际周均时间 预计周均时间
150h 12.5h 10h

1.3 印象最深刻的作业 / 答辩

  • 印象最深刻的是第三次团队项目作业 —— 需求分析文档定稿与答辩。这次作业令我难忘的核心原因有两点：一是文档编制过程的严谨性要求极高，需要严格遵循《软件需求规范》（GB/T 9385-2008）国标，从用户故事、功能需求到非功能需求，每一个模块都要反复核对，仅水源管理模块的交互逻辑就与前后端开发同学讨论了 3 次，最终形成了包含 20 个前端需求、18 个后端需求的完整文档；二是答辩时的质疑与反馈让我收获巨大，评审老师指出 “项目当前应用场景覆盖范围较广”，让我深刻体会到需求分析的 “精准性” 直接影响后续开发的顺畅度。

二、总结收获

2.1 软工实践故事：经验与实例分析

  • 第一次团队项目：需求调研 ——“从用户中来，到用户中去”
    经验总结：需求调研不能停留在表面，必须深入场景挖掘核心诉求。实例分析：项目初期，我们仅通过问卷收集到 “学生关注水质安全” 的笼统需求，缺乏针对性。随后在调研中发现，人工巡检存在 “每周仅 1 次、异常发现滞后 24 小时以上” 的痛点；再通过对 500 余名学生的细分调研，明确了 “实时查看浊度数据”“异常情况即时提醒”“历史数据可追溯” 三大核心诉求。基于这些调研结果，我们将 “异常响应时间缩短至 3 分钟内”“覆盖 500 + 宿舍监测点” 纳入业务目标，确保需求真正贴合实际场景。
  • 第二次团队项目：指标界定 ——“国标为基，场景为纲”
    经验总结：关键指标的界定需要兼顾行业规范与项目实际，不能盲目追求高标准。实例分析：在确定浊度监测精度指标时，我们参考了《生活饮用水卫生标准》（GB 5749-2022）中 1NTU 的限值要求，但考虑到宿舍用水主要用于洗漱、洗衣等场景，且传感器部署成本需控制，最终将系统监测精度界定为 0.01NTU，既满足安全需求，又避免了过度设计。同时，结合技术目标，明确了 “核心接口响应时间≤300ms”“数据存储可靠性 99.99%” 等指标，为开发提供了清晰的量化标准。
  • 第三次团队项目：文档编写 ——“规范先行，协作无忧”
    经验总结：规范的需求文档是跨团队协作的核心桥梁，需做到 “无歧义、可落地、可追溯”。实例分析：编写需求分析文档时，我们采用 “需求 ID + 模块 + 功能描述 + 技术实现点 + 交互逻辑 + 优先级” 的统一格式，例如前端登录功能（REQ-FE-001）明确了 “表单校验正则表达式”“调用 /api/auth/login 接口” 等细节。这份文档成为前端开发、后端开发、测试团队的统一基准，在后续开发中，前后端同学仅通过需求 ID 即可明确对接内容，减少了 80% 的沟通歧义，大幅提升了协作效率。
  • 第四次团队项目：跨团队对接 ——“换位思考，精准同步”
    经验总结：需求对接需站在对方视角思考，用对方能理解的语言传递核心信息。实例分析：在与 Dify 工作流负责人对接时，我们没有直接抛出需求文档，而是梳理了 “创建水源初始化会话”“生成报告调用 AI” 两个核心节点，明确了后端调用 Dify 接口的请求格式、输入变量及响应要求。这种方式让对方快速理解需求，仅用 2 次沟通就确定了接口规范，避免了因技术语言差异导致的对接延迟。

2.2 学习到的新技术 / 生产力工具及帮助

  • 国标规范与行业标准：深入学习《软件需求规范》（GB/T 9385-2008）、《生活饮用水卫生标准》（GB 5749-2022）等，学会了在项目中遵循规范进行需求界定和文档编写，确保项目的合规性与专业性。
    需求分析工具：掌握了思维导图、UML 类图设计方法，通过思维导图梳理 “总需求→功能需求→具体功能点→验收标准” 的核心逻辑，用类图明确前后端核心类及方法，让需求结构更清晰。
    协作工具：熟练使用在线文档协作平台、项目管理工具，实现需求文档的实时修订、项目进度的可视化跟踪，提升了团队协作的高效性。

2.3 技术之外的提升

  • 需求挖掘与分析能力：学会了通过 “问卷调研 + 座谈访谈 + 场景分析” 的多渠道方式收集需求，并用 “用户故事”“功能点拆解” 等方法将模糊需求转化为具体可落地的功能。
    跨团队沟通协作能力：掌握了与前后端开发、测试、硬件团队的沟通技巧，能够精准传递需求核心，倾听技术实现难点，在需求与技术之间寻找平衡点。
    文档编写与规范化意识：养成了 “无规范不文档” 的习惯，学会了编写结构清晰、内容严谨、可追溯的需求分析文档，理解了规范文档对项目质量的保障作用。
    问题解决与风险预判能力：在需求变更时，能够快速分析变更对现有功能的影响，提出合理的调整方案；在对接过程中，提前预判接口格式不统一、需求理解偏差等风险，主动制定应对措施。

2.4 自由发挥

  • 这门课程让我明确了自己对软件工程课程的兴趣，未来希望继续深耕这一领域，将所学的需求分析方法、协作技巧运用到更多实际项目中。最后，想对未来 Z 班的学弟学妹们说：软工实践的核心不是 “会写多少代码”，而是 “会解决多少问题”，珍惜团队协作的机会，多听、多问、多思考，你会收获远超技术本身的成长！

三、致谢

  • 一个学期的软工实践旅程，之所以能顺利走完并收获满满，离不开每一位伙伴的并肩同行与鼎力支持，在此，我想向所有参与其中的老师、同学致以最诚挚的感谢！
    首先要感谢我们 404-Team Not Found 的全体成员。每一个模块的推进，都离不开不同角色成员的通力配合，是大家的各司其职、互帮互助，才让 “智感清浊” 项目从想法变成了现实。
    还要感谢授课老师和评审老师们。课堂上，老师用生动的案例为我们讲解软件工程的核心理论与实践方法，为项目开展奠定了坚实的基础；答辩中，老师们提出的犀利问题和专业建议，帮助我们发现了需求文档中的漏洞与不足，让我们对 “严谨性” 有了更深刻的认知，也推动着我们不断完善项目。
    最后，感谢所有在项目中给予我们支持的人，是大家的积极配合让我们得以精准捕捉核心诉求。这段一起奋斗的时光，不仅让我收获了知识与技能，更感受到了团队协作的温暖与力量。愿我们未来都能带着这份收获与成长，在各自的道路上稳步前行！

林祺-学期回顾

一、课程回顾

1.1 回顾对软件工程课程的想象

原本我以为软件工程就是写代码、做产品，后来才明白前期的准备工作同样至关重要。作为文档组组员，这学期我主要负责文档撰写、PPT制作、后期测试，以及一条VLOG的剪辑。虽然我没有直接参与核心代码开发，但通过文档整理、测试验证和团队协作，我深刻理解了一个完整的软件项目是如何从需求到设计、从开发到测试、最终交付并持续迭代的全过程。这门课让我认识到，软件工程不仅是技术实现，更是系统化思考、规范协作和持续交付的工程实践。

达到期待的部分

  • 理解了软件开发的完整生命周期。
  • 学会了如何通过文档和测试保障项目质量。
  • 在团队协作中提升了沟通与协调能力。

仍感不足的部分

  • 对某些技术栈（如Spring Boot、Vue）的理解还不够深入。
  • 希望在未来的项目中能更多参与编码实践，加深对系统架构的理解。

1.2 回顾课程中的投入与产出

代码编写：虽然作为文档组组员没有参与核心代码开发，但协助参与了简单的脚本编写和测试代码，累计编写约300行代码。

项目参与：在“宿舍用水监测系统”项目中，我作为文档组的组员，主要负责：

  • 文档撰写与整理
  • PPT制作与答辩支持
  • VLOG拍摄与剪辑
  • 后期测试用例执行与Bug跟踪

各次作业花费时间：

作业 花费时间
第一次团队作业 2 小时
第二次团队作业 2 小时
第一次团队项目作业 3 小时
第二次团队项目作业 5 小时
第三次团队项目作业 20 小时
第四次团队项目作业 8 小时

在软件工程课程上花费的时间：

累计时间 实际周均时间 预计周均时间
40h 3.3h 3h

1.3 印象最深刻的作业 / 答辩

印象最深刻的是冲刺阶段的VLOG拍摄与剪辑任务。在这个过程中，我不仅锻炼了视频制作能力，更重要的是通过记录团队的开发日常、会议讨论、调试过程，更直观地理解了项目从无到有的完整脉络。这次经历让我意识到，记录与表达同样是项目管理中不可或缺的一环，它让团队的付出被看见，也让项目的成长有迹可循。

二、总结收获

2.1 软工实践故事：经验与实例分析

第一次团队项目：作为文档组成员，我负责整理需求文档和初期原型说明。在这个过程中，我学会了如何将模糊的需求转化为结构化的文档，也意识到清晰的需求表达对后续开发至关重要。

第二次团队项目：我参与了UML图的绘制与数据库设计说明的撰写。通过绘制ER图和关系模型，我理解了数据是如何在系统中流动和存储的，这为我后续参与测试打下了基础。

第三次团队项目：在冲刺阶段，我担任测试角色，执行功能测试和接口测试。一次发现前端图表展示与后端数据不一致的问题，通过日志追踪和与开发同学沟通，最终定位是数据格式解析问题。这次经历让我体会到测试不仅是找Bug，更是理解系统运行逻辑的过程。

第四次团队项目：：我负责整理测试报告和撰写用户操作手册。为了写出一份清晰易懂的手册，我反复操作系统的每个功能，记录每一步的注意事项。这个过程让我更加理解用户体验的重要性，也锻炼了我将技术语言转化为用户语言的能力。

2.2 学习到的新技术 / 生产力工具及帮助

测试工具：使用Postman进行接口测试，JMeter进行压力测试，让我对系统性能有了更直观的认识。

文档工具：Markdown + Git，实现了文档的版本管理与协作编写，大大提升了文档输出的效率与规范性。

PPT制作工具：Canva + PowerPoint，学会了如何制作简洁美观且内容扎实的答辩PPT。

视频剪辑工具：剪映 + Premiere，掌握了基础的视频剪辑与字幕添加技能，为项目宣传提供了支持。

协作工具：飞书文档 + GitHub，这些工具让团队协作变得高效透明，信息同步更加及时。

2.3 技术之外的提升

团队协作能力：学会了在多人项目中如何明确分工、及时同步、有效沟通。

问题定位与解决能力：通过测试和文档整理，锻炼了从现象到本质的逻辑推理能力。

时间管理与多任务处理能力：在完成文档、测试、剪辑等多类任务中，学会了合理安排时间与优先级。

2.4 自由发挥

最让我感到遗憾的是，由于时间与分工原因，我没能更深入地参与到某个功能模块的编码中。但我也明白，每个角色都在项目中发挥着不可替代的作用。未来如果有机会，我希望能在文档与测试的基础上，尝试参与一些前端或后端的具体实现，让我的技术视野更加全面。

三、致谢

这学期能顺利完成项目，首先要感谢404-Team Not Found 的全体成员。每一个模块的推进，都离不开团队成员的通力配合，是大家的各司其职、互帮互助，才让“宿舍用水监测系统”项目从想法变成了现实。

特别感谢张誉怀组长在项目推进中的统筹与协调，每次站会都让我们清晰方向；感谢林舒欣同学在文档规范上的指导，让我学会了如何写出结构清晰的技术文档；也感谢开发组的同学们，在测试过程中耐心解答我的每一个疑问。

感谢指导老师，每次答辩后都给了很实在的建议，特别是关于如何精简需求范围的建议让我受益匪浅。还要感谢参与调研的同学们，你们的真实反馈是我们改进需求的重要依据。

这段经历让我学到了很多课堂之外的东西，也让我更明白了团队合作的重要性。感谢所有人，这段旅程，因为你们而完整。

吴政君-学期回顾

一、学期回顾

1.1 回顾你对于软件工程课程的想象

在参与"智感清浊"水质监测系统的开发中，我对自己在这门课中的学习有了更清晰的认识。课程开始前，我的期待很明确：完整地参与一次团队项目的开发全流程，回顾整个学期，这个目标不仅实现了，还让我收获了更多意外的成长。

我主要负责Dify平台上AI工作流的搭建和配置。这个角色对我来说很新奇，以前从未了解过智能体这领域的知识，通过深入学习Dify平台，我掌握了如何将模糊的业务需求，如生成一份水质报告转化为可执行的工作流：设计节点逻辑、配置提示词、调试参数，并最终通过API让前后端能够调用。当测试时看到浊度数据经过我的工作流，变成结构清晰、建议具体的分析报告时，成就感特别强烈。

这次经历也让我对团队协作有了更深的理解。我们团队分工明确，从硬件传感器数据采集，到后端数据处理，再到前端界面展示，每个环节都紧密相连。这种为了同一个目标，互相支持、快速响应的感觉，让我体会到团队合作的真正价值。

当然，我也看到了自己的不足。我对项目中除了工作流之外的了解还不够深入，比如后端是如何设计项目框架的，前端是如何实现数据可视化的。这让我意识到，一个优秀的团队成员不仅要把自己的部分做好，还应该对整体技术栈有基本的了解，这样才能更好地协作，提出更落地的建议。同时，在复杂工作流的逻辑设计上，我还在学习和积累经验，希望能更游刃有余地处理各种边界情况。

总的来说，这门课让我真正体验了从需求分析、技术选型、开发实现到测试集成的完整项目周期。我不再只是一个功能的实现者，而是学会了如何在团队中定位自己的角色，如何用技术解决真实问题。这种将知识应用于实践、在协作中成长的过程，正是我最珍贵的收获。本学期的课程让我明白，软件工程不仅是写代码，更是关于沟通、协作和创造价值。

1.2 回顾你在这门课程中的投入与产出

代码编写量：
在软工实践课程中，我主要编写了约 1000 行代码（包括工作流配置脚本、接口调用代码及测试脚本等）。由于工作重心在于Dify平台的逻辑设计与配置，代码量相对较少，但在工作流架构和系统集成上投入了大量精力。

团队项目参与情况：

项目名称 担任角色 主要工作内容
智感清浊水质监测系统 AI工作流开发工程师 负责Dify平台AI工作流搭建

各次作业时间投入：

作业 花费时间
第一次团队作业 3
第二次团队作业 15
第一次团队项目作业 10
第二次团队项目作业 20
第三次团队项目作业 10
第四次团队项目作业 10
  • 在软件工程课程上花费的时间
累计时间 实际周均时间 预计周均时间
68 7 7

1.3 令你印象最深刻的是哪一次作业或哪一场答辩？为什么这次作业或这场答辩令你印象深刻？

令我最印象深刻的是第二次团队作业（原型设计+概要设计）。这一次作业由我主要负责了作业的计划开展以及团队任务的分工合作，面对复杂的原型与概要设计任务，我起初感到有些无从下手。为此，我首先系统地梳理了作业要求，并通过查阅资料学习了相关设计知识，最终形成了清晰的工作计划。有了大概思路之后，我将本次作业主要分成两个周期，第一周期主要是完成设计任务，第二周期的工作就是说明书的攥写以及查漏补缺等。确定了大体计划之后就开始线上会议跟小组成员们讨论交流，在此也非常感谢小组成员的积极配合，每个同学都十分优秀地完成了自己的分工安排。这次作业让我感受到了团队合作的凝聚力，令我印象深刻。

二、总结收获

2.1 展开说说你的软工实践故事

  1. 工作流开发实践：

在Dify平台上搭建AI工作流是我这次最主要的实践。说实话，开始的时候我对这个平台完全不熟悉，就是一边查阅相关资料一边测试。最大的挑战是怎么让AI理解我们的需求，不能直接给它一堆数据就让写报告，要告诉它报告应该包含哪些部分，前后文的输入输出变量如何连接，重点关注什么指标。我设计了固定的报告模板，包括数据回顾、现状评估、建议措施这几个模块，然后针对每个模块写详细的提示词。

和团队协作的过程也让我收获很多。我需要和后端同学确认数据格式，确保他们传过来的数据我的工作流能正确处理；也要和前端同学沟通报告要怎么展示。

  1. 概念模型设计：

在设计阶段，我负责绘制系统的用例图和活动图。一开始我觉得画这些图就是走个形式，但真正画起来才发现，这是一个把模糊想法变清晰的过程。比如画"生成水质报告"这个活动的流程图时，我需要想清楚用户点击按钮后，数据是怎么流动的，系统要经过哪些步骤，可能会遇到什么问题。这个过程让我学会了在动手做之前先把思路理清楚，也让我更能理解其他成员负责的部分在整体中是什么位置。

2.2 介绍学习到的新技术或生产力工具以及它们给你带来了哪方面的帮助？

GitHub 让我掌握了代码版本控制和团队协作的基本流程，养成了规范的开发习惯。

Dify平台 是我主要的技术实践，通过搭建工作流和配置智能体，我学会了如何将AI能力转化为具体的应用功能。

Draw.io 帮助我将设计思路可视化，绘制UML图的过程提升了我的系统思维能力。

Apifox 简化了API测试流程，让接口调试变得更高效。

墨刀原型工具 让我能直观理解产品交互，在设计工作流时更能从用户角度思考。

飞书 作为一体化协作平台，让团队沟通、文档管理和任务跟踪都变得井井有条。

2.3 技术之外，这门课程还给你带来了哪些方面的提升？

团队协作方面，我学会了如何在多人项目中找准自己的定位。在项目中，我需要在前后端之间做好衔接——既要理解后端传来的数据含义，又要考虑前端展示的需求。在与团队成员进行沟通时，我掌握了如何用清晰的语言同步进展、提出问题，这种跨角色沟通能力比技术本身更重要。

任务拆解与管理是我学到的宝贵经验。以前面对"实现智能报告生成"这样的大需求会感到无从下手。现在我学会了把它分解为：学习Dify平台、设计报告模板、配置工作流节点、调试API接口、编写测试用例等具体步骤，并为每个步骤设置合理的时间节点。这种化整为零的方法让复杂任务变得可控。

AI工具的使用，项目过程中使用了各种ai工具辅助解决技术问题，还学会了如何给AI清晰的指令来协助我设计提示词、优化文档结构。这让我认识到，在现代开发中，善用AI工具能成倍提升效率。

信息检索能力也显著提升。面对Dify平台的各种新概念（如MCP、智能体），我学会了快速查找官方文档、技术社区案例，并筛选出对我项目最有用的信息。这种主动学习、解决问题的能力，是课程带给我的隐形财富。

2.4 如果还有什么想记录的或者想说的，就写在这儿吧！

上完这门课，我最大的体会是：做项目比想象中难，但也比想象中有意思。以前总觉得软件工程就是写代码，现在才明白团队配合、沟通协调可能比技术本身更重要。

最遗憾的就是项目答辩那天正好碰上六级考试，没能去现场看看其他组的成果，也没能亲眼见证我们组的展示。虽然队友拍了视频，但感觉还是不太一样。

想对以后的学弟学妹说：别怕做得不好，先动手做起来，遇到问题多问多查，这门课会让你学到很多课本上没有的东西。

三、致谢

首先，真心感谢老师，这门课的安排和讲解都很扎实，课上讲的软件工程方法和项目管理经验对我们实际做项目帮助很大。

其次感谢我们组的所有同学，谢谢大家在项目里的积极配合和相互支持，每个人的努力都让我们的系统更完善了一点。

特别要感谢我们的组长。作为项目经理，他把整个团队安排得明明白白，从任务分配到进度跟进都做得特别到位。虽然项目期间我们各自都有压力，但他总能通过合理的计划和偶尔的团建活动让大家保持干劲，这种管理能力真的很让人佩服。

想对组长说：把团队带得这么稳，不容易。辛苦了。

林宏凯-学期回顾

一、学期回顾

1.1 回顾我对于软件工程课程的想象

在选修软件工程课程之前，我对软件工程课程的理解主要停留在“写代码”和“完成项目”层面，希望能够通过这门课程系统学习软件开发的基本流程，并体验真实的软件项目开发过程。

通过一个学期的学习与实践，我逐渐认识到软件工程并不仅仅是代码实现，更是一套完整的方法论，包括需求分析、系统设计、团队协作、版本管理以及持续迭代等内容。从课程目标来看，这门课在工程思维与实践能力培养方面基本达到了我的预期。

不足之处在于，由于课程周期较短，部分工程实践（如完整的软件测试流程、持续集成与自动化部署）未能进行深入展开，但整体学习体验仍然十分充实。

1.2 回顾我在这门课程中的投入与产出

  • 在软工实践课程当中，每名成员分别编写了 约 3500 行代码。
  • 在团队项目中，每名成员参与了 水资源监测系统 的设计与开发。
  • 我在项目中承担的角色是：前端开发（兼部分部署与文档整理）。

软工实践各次作业花费时间统计

作业 花费时间
第一次团队作业 4 小时
第二次团队作业 5 小时
第一次团队项目作业 8 小时
第二次团队项目作业 10 小时
第三次团队项目作业 9 小时
第四次团队项目作业 12 小时

软件工程课程总体时间投入

累计时间 实际周均时间 预计周均时间
48 小时 3 小时/周 3 小时/周

1.3 印象最深刻的一次作业或答辩

令我印象最深刻的是第三次团队项目作业的答辩。在答辩过程中，老师不仅关注系统功能是否完整，更关注系统设计的合理性、模块划分是否清晰以及项目是否具有可扩展性。这让我意识到软件工程的核心并不是功能堆砌，而是整体架构与工程质量。

二、总结收获

2.1 我的软工实践故事

在多次团队项目实践过程中，我逐渐体会到：

  • 需求沟通的重要性
    在项目初期，由于需求理解不够统一，导致部分功能在实现后需要调整。通过后续的需求讨论和文档补充，团队协作效率明显提升。

  • 合理分工与接口约定的价值
    在明确前后端接口与任务分工后，各成员可以并行推进开发，大幅减少了无效等待时间。

  • 工程规范意识的增强
    通过实践，我逐渐意识到代码规范、版本管理和技术文档对项目长期维护的重要性。

2.2 学习到的新技术或生产力工具

  • Vue.js + Element UI：用于构建前端页面，提升界面开发效率
  • Axios：实现前后端数据交互
  • Git / GitHub：进行团队协作和版本控制
  • Nginx：用于前端项目部署与反向代理
  • Docker：了解容器化部署的基本流程
  • Markdown：用于编写和维护项目文档

2.3 技术之外的提升

  • 团队沟通与协作能力的提升
  • 对项目进度与任务规划的理解
  • 面对问题时的分析与解决能力
  • 软件工程整体思维的形成

2.4 其他想记录的话

通过本学期的软件工程课程学习，我对软件开发过程有了更加全面的认识，也更加明确了自己未来在软件工程相关方向继续深入学习的意愿。

如果要说遗憾，那就是由于时间有限，项目还有不少可以进一步优化和扩展的空间。希望在今后的学习或实践中能够继续完善相关能力。

三、致谢

在本学期的软件工程课程中，我特别想感谢我的团队成员。在项目开发过程中，大家能够相互配合、共同解决问题，使项目得以顺利推进。

同时也感谢任课老师和助教在课程讲解与答辩反馈中给予的耐心指导和宝贵建议，让我在实践中不断反思和提升。

感谢这门课程带来的成长与收获。

杨佳峻-学期回顾

一、学期回顾

1.1 回顾你对于软件工程课程的想象

在课程开始前，我对软件工程的想象更偏向于“高级编程课”，期待学习如何编写更规范、更庞大的代码，以及一些流行的开发框架。我预想这会是一个充满个人技术挑战的课程。

达到甚至超出预期的方面：

  1. 工程化思维远超编码本身： 课程真正聚焦于“工程”——如何将一个模糊的需求，通过分析、设计、协作、测试、部署，最终变成一个可用的、有价值的软件产品。我所负责的Dify工作流搭建，就是这一过程的微观体现：思考数据流、模块解耦、异常处理、用户体验，这比单纯写代码复杂得多，也让我对“开发”有了全新的认知。

  2. 团队协作的真实体验： 课程的团队项目制完美模拟了真实工作场景。从最初的“组队-蜜月期”，到中期的“需求冲突-技术瓶颈”压力期，再到后期的“合力冲刺-收获成果”期，我完整地经历了一个产品团队可能遇到的所有情绪和挑战，这是独自 coding 无法获得的宝贵经验。

  3. “低代码”与AI应用的工程实践： 通过Dify平台，我直观地接触到了现代AI应用落地的快速路径。它让我明白，工程师的价值不仅是实现功能，更是选择合适的工具，高效、可靠地连接技术与需求。

存在的不足：
我个人在深入底层技术和架构设计方面感觉尚有欠缺。由于项目采用了Dify这样的高阶工具，虽然快速实现了核心业务逻辑，但也一定程度上“屏蔽”了底层服务编排、模型服务化等更硬核的后端知识。未来需要自主补充学习容器化、API网关、微服务等知识，以理解我们所搭建的应用其下层的完整技术栈。

1.2 回顾你在这门课程中的投入与产出

  • 承担角色： 在“水质浊度智能检测”项目中，我担任 后端/算法集成工程师，核心职责是：

    1. 设计并实现基于Dify的智能数据分析与报告生成工作流。

    2. 负责后端业务逻辑与AI模型服务的API对接与数据桥接。

    3. 参与系统架构讨论，确保工作流与前后端的数据流畅通。

软工实践各次作业花费时间统计

作业 花费时间
第一次团队作业 6小时
第二次团队作业 7小时
第一次团队项目作业 10小时
第二次团队项目作业 12小时
第三次团队项目作业 11小时
第四次团队项目作业 14小时

软件工程课程总体时间投入

累计时间 实际周均时间 预计周均时间
60小时 5小时/周 5小时/周

1.3 令你印象最深刻的是哪一次作业或哪一场答辩？

最深刻的是最终项目答辩。

原因在于，那是所有努力、焦虑、争论和突破的最终呈现。当屏幕上演示着从手机上传一张浑浊的水样图片，到系统自动分析、生成一份图文并茂的检测报告，整个过程在几十秒内流畅完成时，那种“我们真的把它做出来了” 的震撼和成就感是无与伦比的。答辩不仅是展示一个产品，更是讲述一个团队如何将一个想法，历经三个月，克服无数困难，最终变为现实的故事。评委的提问也让我们从自嗨中跳出，以更客观、更产品的视角审视自己的作品，这种反馈非常宝贵。

二、总结收获

2.1 展开说说你的软工实践故事

第一次团队项目（技术选型与架构）： 我们为“选用传统开发还是低代码平台”激烈讨论。我主张使用Dify快速验证核心AI工作流，这最终被采纳。经验： 技术选型必须紧密结合项目核心价值（我们的是“智能分析”而非“复杂交互”）和团队资源，追求“合适”而非“炫技”。

  • 实例： 我们用一周时间在Dify上搭建出可运行的分析流程原型，迅速验证了想法的可行性，极大地鼓舞了团队士气。

第二次团队项目（核心开发）： 我的核心挑战是让工作流稳定。曾遇到一个“幽灵Bug”：在特定图片格式下，工作流会随机失败。经验： 系统性调试比盲目尝试更重要。

  • 例证： 我通过逐节点检查输入输出日志，最终定位到是某个图像预处理节点对某些元数据处理不当。这让我学会了为关键节点增设详细的日志记录和输入验证，提升了系统的可观察性和健壮性。

第三次团队项目（测试与优化）： 压力测试下，工作流在高并发时出现超时。经验： 性能优化需要寻找瓶颈点。

  • 例证： 通过分析，发现瓶颈在于串行调用多个AI模型。我利用Dify的并行处理节点对独立任务进行重组，将整体响应时间降低了约40%。

第四次团队项目（部署与交付）： 将本地工作流部署到生产环境时，环境差异导致依赖出错。经验： “在我机器上能跑”是工程大忌。

  • 例证： 我们学习使用容器化（Docker）思想，将工作流及其依赖更清晰地定义，并编写了详细的部署手册，确保了交付的可靠性。

2.2 介绍学习到的新技术或生产力工具

  1. Dify等AI Agent开发平台： 革命性地改变了我构建AI应用的范式。它让我能聚焦于业务逻辑和流程设计，而非底层基础设施，极大提升了创意验证和原型开发的速度。

  2. API设计与管理工具（如Postman， Apifox）： 在与前后端、算法模块对接时，这些工具帮助我清晰定义接口契约、进行自动化测试，是团队协作的“润滑剂”。

  3. 协作工具深度使用（Git， 看板， 在线文档）： 不仅仅是“会用”，而是在实战中理解了如何通过分支策略、commit规范、任务拆解来管理一个迭代中的项目，这是现代软件开发的核心协作技能。

2.3 技术之外，这门课程还给你带来了哪些方面的提升？

  1. 心态的锤炼： 从“害怕出错”到“拥抱问题，解决问题”。我明白了在工程中，Bug和意外是常态，关键是如何沉着应对、系统分析、有效沟通。

  2. 沟通与协作能力： 学会了如何用技术语言与非技术成员沟通需求，如何在争论中理性表达观点并寻求共识，如何在同伴遇到困难时主动提供支持。

  3. 产品与用户思维： 不再只关心功能是否实现，开始思考 “这个功能为用户解决了什么真实问题？”、“交互流程是否自然？”、“报告的结果是否清晰易懂？”。这是一种思维视角的根本转变。

  4. 项目管理与时间感知： 通过记录时间投入和完成作业，我对估算任务耗时、制定合理计划、在压力下管理优先级有了切身体会。

2.4 如果还有什么想记录的或者想说的

最想说：请全身心投入这场“痛苦”但绝对值得的旅程。 软工实践就像一场为期三个月的“沉浸式剧本杀”，你拿到的是一个充满挑战的角色卡。过程中的每一次争吵、每一个通宵调试的夜晚、每一个看似无法逾越的鸿沟，都是这个角色成长的必经剧情。不要害怕暴露自己的无知，不要吝啬于分享你的想法，更不要轻易放弃。当答辩结束，你们共同创造的作品在屏幕上闪耀时，你会感谢那个曾经拼命努力的自己，也会无比珍惜这群一起“战斗”过的伙伴。这堂课，教的不仅是软件工程，更是如何与不确定性和解，如何与他人共创价值。

三、致谢

一个学期过去，我心中充满感激。

首先，最想感谢我的团队成员们。 感谢PM在最混乱的时候拉回节奏，感谢前端同学不厌其烦地配合我调整接口，感谢算法同学耐心解释模型的每一个输出细节。特别记得在调试那个“幽灵Bug”的凌晨两点，一位后端同学在线上陪我一起看日志，虽然问题在我的模块，但他没有丝毫抱怨。我想对你们说：“没有每个人的坚守与付出，就没有最终那个流畅的Demo。能与你们并肩作战，是我的幸运。”

其次，衷心感谢我们的TA和课程老师。 感谢TA在我们每次遇到方向性迷茫或技术深坑时，总能给出那“临门一脚”的关键指点。记得有一次我们困在技术细节里，TA反问我们：“用户真的关心这个技术是怎么实现的吗？还是更关心结果准不准、快不快？”这句话让我们瞬间回归正轨。我想对TA说：“您不仅是知识的传授者，更是我们工程思维的教练。您的鞭策与鼓励，是我们穿越迷雾时最重要的灯塔。”

最后，也感谢那个没有放弃的自己。 感谢你在想摆烂的时候多坚持了一下，在遇到难题时选择死磕到底。### 一、学期回顾

1.1 回顾你对于软件工程课程的想象

在课程开始前，我对软件工程的想象更偏向于“高级编程课”，期待学习如何编写更规范、更庞大的代码，以及一些流行的开发框架。我预想这会是一个充满个人技术挑战的课程。

达到甚至超出预期的方面：

  1. 工程化思维远超编码本身： 课程真正聚焦于“工程”——如何将一个模糊的需求，通过分析、设计、协作、测试、部署，最终变成一个可用的、有价值的软件产品。我所负责的Dify工作流搭建，就是这一过程的微观体现：思考数据流、模块解耦、异常处理、用户体验，这比单纯写代码复杂得多，也让我对“开发”有了全新的认知。

  2. 团队协作的真实体验： 课程的团队项目制完美模拟了真实工作场景。从最初的“组队-蜜月期”，到中期的“需求冲突-技术瓶颈”压力期，再到后期的“合力冲刺-收获成果”期，我完整地经历了一个产品团队可能遇到的所有情绪和挑战，这是独自 coding 无法获得的宝贵经验。

  3. “低代码”与AI应用的工程实践： 通过Dify平台，我直观地接触到了现代AI应用落地的快速路径。它让我明白，工程师的价值不仅是实现功能，更是选择合适的工具，高效、可靠地连接技术与需求。

存在的不足：
我个人在深入底层技术和架构设计方面感觉尚有欠缺。由于项目采用了Dify这样的高阶工具，虽然快速实现了核心业务逻辑，但也一定程度上“屏蔽”了底层服务编排、模型服务化等更硬核的后端知识。未来需要自主补充学习容器化、API网关、微服务等知识，以理解我们所搭建的应用其下层的完整技术栈。

1.2 回顾你在这门课程中的投入与产出

  • 承担角色： 在“水质浊度智能检测”项目中，我担任 后端/算法集成工程师，核心职责是：

    1. 设计并实现基于Dify的智能数据分析与报告生成工作流。

    2. 负责后端业务逻辑与AI模型服务的API对接与数据桥接。

    3. 参与系统架构讨论，确保工作流与前后端的数据流畅通。

软工实践各次作业花费时间统计

作业 花费时间
第一次团队作业 6小时
第二次团队作业 7小时
第一次团队项目作业 10小时
第二次团队项目作业 12小时
第三次团队项目作业 11小时
第四次团队项目作业 14小时

软件工程课程总体时间投入

累计时间 实际周均时间 预计周均时间
60小时 5小时/周 5小时/周

1.3 令你印象最深刻的是哪一次作业或哪一场答辩？

最深刻的是最终项目答辩。

原因在于，那是所有努力、焦虑、争论和突破的最终呈现。当屏幕上演示着从手机上传一张浑浊的水样图片，到系统自动分析、生成一份图文并茂的检测报告，整个过程在几十秒内流畅完成时，那种“我们真的把它做出来了” 的震撼和成就感是无与伦比的。答辩不仅是展示一个产品，更是讲述一个团队如何将一个想法，历经三个月，克服无数困难，最终变为现实的故事。评委的提问也让我们从自嗨中跳出，以更客观、更产品的视角审视自己的作品，这种反馈非常宝贵。

二、总结收获

2.1 展开说说你的软工实践故事

第一次团队项目（技术选型与架构）： 我们为“选用传统开发还是低代码平台”激烈讨论。我主张使用Dify快速验证核心AI工作流，这最终被采纳。经验： 技术选型必须紧密结合项目核心价值（我们的是“智能分析”而非“复杂交互”）和团队资源，追求“合适”而非“炫技”。

  • 实例： 我们用一周时间在Dify上搭建出可运行的分析流程原型，迅速验证了想法的可行性，极大地鼓舞了团队士气。

第二次团队项目（核心开发）： 我的核心挑战是让工作流稳定。曾遇到一个“幽灵Bug”：在特定图片格式下，工作流会随机失败。经验： 系统性调试比盲目尝试更重要。

  • 例证： 我通过逐节点检查输入输出日志，最终定位到是某个图像预处理节点对某些元数据处理不当。这让我学会了为关键节点增设详细的日志记录和输入验证，提升了系统的可观察性和健壮性。

第三次团队项目（测试与优化）： 压力测试下，工作流在高并发时出现超时。经验： 性能优化需要寻找瓶颈点。

  • 例证： 通过分析，发现瓶颈在于串行调用多个AI模型。我利用Dify的并行处理节点对独立任务进行重组，将整体响应时间降低了约40%。

第四次团队项目（部署与交付）： 将本地工作流部署到生产环境时，环境差异导致依赖出错。经验： “在我机器上能跑”是工程大忌。

  • 例证： 我们学习使用容器化（Docker）思想，将工作流及其依赖更清晰地定义，并编写了详细的部署手册，确保了交付的可靠性。

2.2 介绍学习到的新技术或生产力工具

  1. Dify等AI Agent开发平台： 革命性地改变了我构建AI应用的范式。它让我能聚焦于业务逻辑和流程设计，而非底层基础设施，极大提升了创意验证和原型开发的速度。

  2. API设计与管理工具（如Postman， Apifox）： 在与前后端、算法模块对接时，这些工具帮助我清晰定义接口契约、进行自动化测试，是团队协作的“润滑剂”。

  3. 协作工具深度使用（Git， 看板， 在线文档）： 不仅仅是“会用”，而是在实战中理解了如何通过分支策略、commit规范、任务拆解来管理一个迭代中的项目，这是现代软件开发的核心协作技能。

2.3 技术之外，这门课程还给你带来了哪些方面的提升？

  1. 心态的锤炼： 从“害怕出错”到“拥抱问题，解决问题”。我明白了在工程中，Bug和意外是常态，关键是如何沉着应对、系统分析、有效沟通。

  2. 沟通与协作能力： 学会了如何用技术语言与非技术成员沟通需求，如何在争论中理性表达观点并寻求共识，如何在同伴遇到困难时主动提供支持。

  3. 产品与用户思维： 不再只关心功能是否实现，开始思考 “这个功能为用户解决了什么真实问题？”、“交互流程是否自然？”、“报告的结果是否清晰易懂？”。这是一种思维视角的根本转变。

  4. 项目管理与时间感知： 通过记录时间投入和完成作业，我对估算任务耗时、制定合理计划、在压力下管理优先级有了切身体会。

2.4 如果还有什么想记录的或者想说的

最想说：请全身心投入这场“痛苦”但绝对值得的旅程。 软工实践就像一场为期三个月的“沉浸式剧本杀”，你拿到的是一个充满挑战的角色卡。过程中的每一次争吵、每一个通宵调试的夜晚、每一个看似无法逾越的鸿沟，都是这个角色成长的必经剧情。不要害怕暴露自己的无知，不要吝啬于分享你的想法，更不要轻易放弃。当答辩结束，你们共同创造的作品在屏幕上闪耀时，你会感谢那个曾经拼命努力的自己，也会无比珍惜这群一起“战斗”过的伙伴。这堂课，教的不仅是软件工程，更是如何与不确定性和解，如何与他人共创价值。

三、致谢

一个学期过去，我心中充满感激。

首先，最想感谢我的团队成员们。 感谢PM在最混乱的时候拉回节奏，感谢前端同学不厌其烦地配合我调整接口，感谢算法同学耐心解释模型的每一个输出细节。特别记得在调试那个“幽灵Bug”的凌晨两点，一位后端同学在线上陪我一起看日志，虽然问题在我的模块，但他没有丝毫抱怨。我想对你们说：“没有每个人的坚守与付出，就没有最终那个流畅的Demo。能与你们并肩作战，是我的幸运。”

其次，衷心感谢我们的TA和课程老师。 感谢TA在我们每次遇到方向性迷茫或技术深坑时，总能给出那“临门一脚”的关键指点。记得有一次我们困在技术细节里，TA反问我们：“用户真的关心这个技术是怎么实现的吗？还是更关心结果准不准、快不快？”这句话让我们瞬间回归正轨。我想对TA说：“您不仅是知识的传授者，更是我们工程思维的教练。您的鞭策与鼓励，是我们穿越迷雾时最重要的灯塔。”

最后，也感谢那个没有放弃的自己。 感谢你在想摆烂的时候多坚持了一下，在遇到难题时选择死磕到底。

林军-学期回顾

一、学期回顾

1.1 回顾你对于软件工程课程的想象

在选修《软件工程》这门课程之前，我对它的理解更多停留在“讲开发流程、写文档、做分组项目”的层面，甚至一度认为它可能会偏理论、偏形式化，实践部分只是对课堂内容的简单验证。但在完整经历了一个学期的课程与实践之后，我逐渐意识到这门课的重点并不在于“写了多少代码”，而在于如何在真实约束条件下完成一次可落地的软件开发过程。

从结果来看，课程在多个方面达到了我最初的期待，甚至超出了预期。首先是在团队协作与角色分工方面，从最初的需求讨论、技术选型，到后期的功能拆分、进度推进，每一步都需要在团队中不断沟通、协调，这让我真正体会到了软件工程中“人”的重要性。其次，本次课程明确要求项目与 AI 技术结合，我们组在实践中引入了 Dify 工作流，这让我第一次系统性地思考“如何将 AI 作为能力模块嵌入到传统 Web 应用中”，而不是停留在简单的 API 调用层面。

当然，也存在一些不足之处。一方面，由于团队成员背景和技术栈存在差异，在项目初期对系统架构的理解并不完全一致，导致前期返工成本较高；另一方面，在时间安排上，后期功能与部署任务相对集中，暴露出我们在进度评估和风险预判上的不足。这些问题的出现，也让我更加直观地理解了软件工程中计划、评估与迭代的重要性。

1.2 回顾你在这门课程中的投入与产出

  • 在软工实践课程我编写了6000+行代码。

  • 在团队项目我参与了智感清浊的设计与开发，在其中所承担:

    • 后端开发负责人：负责接口设计、业务逻辑实现、与 AI 工作流（Dify）的集成

    • 运维与部署负责人：负责服务器环境搭建、Docker 容器化部署、Nginx 配置及线上问题排查

  • 软工实践的各次作业我分别花费的时间：

作业 花费时间
第一次团队作业 2小时
第二次团队作业 2小时
第一次团队项目作业 2小时
第二次团队项目作业 4小时
第三次团队项目作业 24小时
第四次团队项目作业 8小时
  • 在软件工程课程上花费的时间
累计时间 实际周均时间 预计周均时间
42小时 3.5小时/周 3小时/周

1.3 令你印象最深刻的是哪一次作业或哪一场答辩？为什么这次作业或这场答辩令你印象深刻？

最后一次答辩，因为拿了一等奖。

二、总结收获

2.1 展开说说你的软工实践故事

在每一次团队实践中，我最深的体会是：技术问题往往不是最难的，难的是如何在团队中达成共识并高效推进。

例如在后端与 AI 工作流的集成阶段，我们曾对“AI 应该以什么形式介入业务流程”产生分歧。通过多次讨论与原型验证，最终采用了 Dify 工作流作为独立能力模块的方案，使得系统结构更加清晰，也方便后期扩展。这一过程让我意识到，软件工程中的“设计决策”本身就是一种重要产出。

2.2 介绍学习到的新技术或生产力工具以及它们给你带来了哪方面的帮助？

  • Dify 工作流：理解了 AI 能力编排与流程化调用的实际落地方式

  • Docker 容器化部署：提升了项目交付与环境一致性的能力

  • Nginx 反向代理与部署配置：加深了对 Web 应用上线流程的理解

  • 前后端分离协作模式：提升了接口设计与文档意识

2.3 技术之外，这门课程还给你带来了哪些方面的提升？

  • 团队沟通能力：学会用更清晰、工程化的方式表达想法

  • 任务拆分与时间管理能力：理解了合理规划的重要性

  • 责任意识：作为后端与运维负责人，需要对系统稳定性负责

  • 工程思维：从“写代码”转向“做系统”

2.4 如果还有什么想记录的或者想说的，就写在这儿吧！

这门课程让我第一次真正意识到：软件工程并不是写代码的附属，而是让代码真正产生价值的方式。

它也在一定程度上坚定了我未来继续向后端开发与系统工程方向深入学习的想法。

如果要给未来 Z 班的学弟学妹一句建议，那就是：尽量把课程项目当成一次真实开发机会，而不是一次作业。

github:https://github.com/Hannezs/404-Team-Not-Found
项目实际运行链接：https://github.com/Hannezs/404-Team-Not-Found/tree/智感清浊