软件工程第一次作业

zzl3141的第一次博客作业

这个作业属于哪个课程	H202601软件工程与软件工程实践
这个作业要求在哪里	2026秋软件工程个人作业 (第一次)
这个作业的目标	1.分析自己的技术能力 2.规划自己大学生涯的学习目标 3.学习github的基本用法 4.学习markdown语法和发布博客 5.学习大模型调用生成图像的功能
学号	102401231

一. 自我介绍(个人技能树梳理)和自我评估

(一) 已经具备的专业知识能力

1.基础C,C++,py语法
2.py简单数据分析,完成小型项目"BOSS直聘数据分析师职位","学生成绩表_理科","双十一用户下单数据分析"
3.简单AI调用,机器学习小型数据集训练区分蚂蚁和蜜蜂图片

(二) 个人技术兴趣方向

1.AI算法研发部门,基于现有模型做调优、数据处理、微调、Prompt、模型迭代
2.大数据、人工智能方向，计划未来考研深造深入学习。

(三) 目前欠缺的能力

1.工程化经验不足,只接触过一些小型玩具项目,并且知识积累也不足,只会基本编程语言的简单语法
2.缺少算法方面的训练,算法只会基本的排序,树和图之类的C++算法
3.缺少人工智能项目和相关算法学习经验

二. 当前代码量现状与本学期目标代码量

截至目前，本人累计编写有效代码量约 4000-5000 行，主要由Python数据分析、课程练习代码、AI调用实验代码、C++算法题目构成。
软件工程课程结束之后，计划累计有效代码量达到 10000 行，增加规范化、模块化的实战项目代码，减少零散练习代码。

三. 本门课期待学习到的知识和能力收获

期待的知识

1.软件开发流程：瀑布、迭代、敏捷（Scrum、看板）等模型，理解软件不是"一次性写完"，而是需求、设计、开发、测试、发布、维护不断循环的过程。
2.需求分析：怎么把用户模糊的想法变成清晰、可验证的需求，学会区分功能需求和非功能需求，以及需求变更为什么可怕。
3.设计与架构：模块划分、高内聚低耦合、常见架构风格、UML 图（用例图、类图、时序图）、设计原则和部分设计模式。这是从"实现功能"走向"设计系统"的分水岭。
4.编码与协作实践：代码规范、代码评审、版本控制（Git 的工作流）、文档怎么写。这些看起来"不是技术"，恰恰是团队项目里最实用的技能。

期待的能力收获

1.把大问题拆小的能力。面对一个模糊、庞大的目标，能一步步分解成可执行、可验证的小任务。这个能力任何工作都通用。
2.质量意识。不再写完就觉得"完成了"，而是会问：边界情况测了吗？别人能看懂吗？以后要加功能好改吗？
3.沟通表达能力。写需求文档、做设计汇报、评审别人代码，都需要把技术想法讲清楚。

四. 基于DeepSeek大模型生成的软件工程课程学习指南及合理性分析

学习指南

阶段一：打底子（第 1–3 周）——先有全局观

要做的事

• 搞懂软件工程解决什么问题：一个人写的是"程序"，一群人长期维护的才是"软件产品"；
• 对比瀑布与敏捷流程，理解各自适合什么场景；
• 配齐工具：Git + GitHub 账号、IDE、包管理器，练会 add / commit / push / pull / 分支；
• 挑一个常用的 App（外卖、记账等），反推它的开发流程，验证对软件生命周期的理解。

阶段产出

• 一张完整的"需求→设计→开发→测试→发布→维护"流程图；
• 第一次成功提交到 GitHub 的代码仓库。

过关标准

• 能向同学讲清楚：自己的小组项目为什么选敏捷而不是瀑布。

阶段二：想清楚（第 4–7 周）——只写文档，不写代码

要做的事

• 确定题目（例如"宿舍二手交易小程序"），先调研 3–5 个同类产品，整理它们的功能与槽点；
• 用"作为用户，我想要……，以便……"的格式写用户故事，并按 MoSCoW 法分级：必须有 / 应该有 / 可以有 / 这次不要；
• 为每条需求补充可验证的验收标准；
• 思考异常场景：重复提交、断网、恶意输入分别怎么处理；
• 做设计：划分模块、画用例图与类图、设计数据库表和核心接口；
• 用 SOLID 原则检查设计，并记录设计决策：为什么选这个方案、放弃了哪些备选方案。

阶段产出

• 一份需求文档；
• 一份设计文档；
• 项目仓库的基础目录结构。

过关标准

• 没参与项目的人光看文档，就能说出系统长什么样；
• 拿着需求清单能大致估算工作量。

阶段三：做出来（第 8–11 周）——动手协作开发

要做的事

• 把功能拆成 1–2 周的小迭代，每人认领模块，按 feature 分支开发，提交信息保持清晰简短；
• 边写功能边补单元测试（Java 用 JUnit、Python 用 pytest），优先覆盖核心逻辑；
• 至少尝试一次 TDD：先写一个会失败的测试，再写代码让它通过；
• 每周开站会，每人只讲三件事：完成了什么 / 下一步做什么 / 有什么卡住我的；
• 组织代码评审：关注命名、重复代码、边界情况，而不只是笼统地夸"写得好"；
• 主动经历一次合并冲突，理解分支策略为什么能减少冲突。

阶段产出

• 一个可运行的迭代版本；
• 测试通过的运行记录；
• 清晰的分支合并历史。

过关标准

• 新同学 clone 代码后能直接跑起来；
• 修改一个功能，不会破坏其他模块。

阶段四：交出去（第 12–16 周）——交付、展示与复盘

要做的事

• 收尾：修复遗留 bug，补充 README、用户文档与部署说明；
• 配置 CI：每次 push 自动执行构建与测试（如 GitHub Actions），有条件就把项目部署到免费平台；
• 准备演示：重点讲"需求怎么来 → 架构怎么设计 → 测试怎么保证"，而不是只演示一遍功能；
• 做项目复盘：对比当初的估时与实际工时，回顾哪些风险真的发生了、协作在哪一步最卡，写出 3 条改进建议；
• 整理交付物：可运行的链接或安装包、完整代码仓库、测试报告、复盘报告。

阶段产出

• 一个别人能装、能用的产品；
• 一套完整可读的项目文档。

过关标准

• 组外的人照着文档能把项目跑起来；
• 能解释清楚每个关键设计选择"为什么这么做"。

合理性分析

我咨询ai得出它生成这份指南合理性的核心在于：它把"知识"与"技能"分开训练，按依赖链排序，用实践与反馈保证能力转化，并为现实偏差预留了调整空间,只要保留项目实践与复盘这两个关键环节，无论课程长短，学习效果都能得到基本保证,个人觉得生成的学习指南节奏比较适中,知识点也基本涉及到了

五.Hugging-Face Flux和火山方舟Seedream 5.0模型API调用

(一)项目实现方案

前端:
纯 HTML/CSS/JS，无框架，只有一个页面。

• HTML：提供提示词输入框、“生成图片”按钮、结果展示区和历史记录区。
• CSS：定义页面布局和样式。
• JS（static/app.js）：
  ◦ 点击按钮后用 fetch 向本地后端发 POST /api/generate；
  ◦ 请求期间禁用按钮，避免重复提交；
  ◦ 成功后渲染返回图片，并通过 GET /api/status 刷新历史记录；
  ◦ 失败时展示后端返回的错误信息。
  前端只负责交互，不保存也不发送任何 API Key。

后端:
纯 Python 标准库（http.server + urllib），无第三方依赖。

• 启动时读取 .env 中的 ARK_API_KEY；
• 监听 127.0.0.1:8765，按路径路由：
  ◦ GET /、/style.css、/app.js → 返回前端资源；
  ◦ POST /api/generate → 接收提示词，调用火山方舟并下载图片；
  ◦ GET /api/status → 返回最近的调用记录；
  ◦ GET /images/xxx → 返回本地保存的图片；
• 调用前先生成记录 ID 并保存 submitted 状态，成功/失败后再更新记录；
• 把图片下载到本地 images/，因为火山方舟返回的临时图片 URL 会过期；
• 后端是唯一接触 API Key 的部分，是浏览器与云端模型之间的代理。

(二)提示词设计与成果展示

提示词是让ai生成的现实世界场景图,注意现实世界的质感,并且由于Flux是外国模型所以要使用英文提示词:
A photorealistic documentary street photograph in a small southern Chinese town right after rain in the early morning. Wet bluestone pavement reflects white-walled buildings, dark tile roofs, and warm paper lanterns. An elderly man pushes a bicycle through the alley entrance, with a folded umbrella and a bag of vegetables in the basket; in the distance, a breakfast stall releases soft white steam and an orange cat lies by the wall corner. Natural low morning sunlight, crisp realistic textures, natural fabric and skin tones, 35mm lens look, gentle depth of field, subtle film grain, candid unposed atmosphere, authentic real-world feel. No anime, no illustration, no CGI render, no text overlay

因为Flux的额度只有三次,所以我找了另一个国内生图模型火山方舟,下面是模型生成的图片,这个模型有50次免费额度

(三)AI调用心得

这次经历让我体会了前端+后端+API调用的路径,Flux的模型生图能力优秀,但是费用较高,延迟较大,国产模型火山方舟生图质感不输于Flux,并且延迟低,只是推理速度略低于Flux

六. github个人主页搭建

选择方案二,利用 Jekyll Theme和github pages,搭建个人博客我的博客链接