AIGC标识 软件工程第一次作业

软件工程第一次个人作业

这个作业属于哪个课程 https://edu.cnblogs.com/campus/fzu/202601SofwareEngineering
这个作业要求在哪里 https://edu.cnblogs.com/campus/fzu/202601SofwareEngineering/homework/15712
这个作业的目标 完成 GitHub / 博客园账号注册与班级博客实名加入；调用 HuggingFace 的 Flux 模型并前后端交互生成贴近真实世界的图像；搭建 GitHub 个人主页；梳理个人技能树并制定三年规划
学号 102401418

一、准备工作

1.1 GitHub 账号

注册 GitHub 账号，完善头像、个人简介等信息。我的 GitHub 主页：https://github.com/Bari328

1.2 博客园账号

注册博客园账号，设置昵称（实名制）、头像，选择博客皮肤样式，并申请开通个人博客（审核约 15 分钟）。已加入班级博客 H202601 软件工程与软件工程实践，并在班级成员列表中确认实名加入成功。

1.3 关注老师与助教博客

已关注任课老师、助教 wqr999、助教 YoutuZ 的博客。

二、HuggingFace API 调用：Flux 模型 + 前端交互生成

2.1 任务目标

调用 Flux 模型（XLabs-AI/flux-RealismLora）生成一张最贴近真实世界的图像，并在调用模型的代码基础上结合前端接口，实现输入提示词即可交互生成图片。

2.2 操作步骤

  1. 在 HuggingFace 官网注册账号并完成邮箱验证。

  2. 点击右上角头像 → Settings → Access Tokens → Create new token，创建 Fine-grained 类型 Token（权限勾选调用推理相关选项），生成 hf_ 开头的密钥，仅显示一次，复制保存到项目 .env 文件中（不硬编码进代码，避免泄露）。
    4d0e90cf-aa17-4825-bd5e-9e51bbb18c64

    【图 1：HuggingFace Access Tokens 页面截图（token 已打码）】

  3. 项目结构如下：

softeng/

├─ app.py                # Flask 后端（含前端页面）

├─ .env                  # HF\_TOKEN=...

└─ static/outputs/       # 生成图片保存目录

  1. 安装依赖：pip install flask huggingface-hub python-dotenv pillow

  2. 运行 python ``app.py，浏览器打开 http://127.0.0.1:5000

  3. 在输入框填写提示词，点击「生成图像」：前端通过 fetch 将提示词 POST 到后端 /api/generate，后端调用 HuggingFace 的推理接口生成图片，返回图片地址，前端渲染展示。

2.3 核心代码

后端调用模型的核心逻辑（Flask 接口内）：

from huggingface\_hub import InferenceClient

import os

client = InferenceClient(api\_key=os.getenv("HF\_TOKEN"), timeout=120)

def generate\_image(prompt: str):

    image = client.text\_to\_image(

        prompt,

        model="XLabs-AI/flux-RealismLora",   # 作业指定模型

        num\_inference\_steps=28,

        guidance\_scale=3.5,

    )

    save\_path = os.path.join("static", "outputs", f"gen\_{int(time.time())}.png")

    image.save(save\_path)

    return f"/static/outputs/{os.path.basename(save\_path)}"

前端交互核心（HTML + JavaScript）：

async function submitGenerate(){

  const prompt = document.getElementById("prompt\_input").value;

  const resp = await fetch("/api/generate", {

    method: "POST",

    headers: { "Content-Type": "application/json" },

    body: JSON.stringify({ prompt: prompt })

  });

  const res = await resp.json();

  if (res.code === 200) {

    document.getElementById("result-img").src = res.image\_url;

  }

}

前端还设计了 4 个预设场景按钮（清晨上学路 / 作业原题 / 雨后傍晚街道 / 图书馆午后），以及历史记录面板，提升交互体验。

2.4 API 调用成功的记录

后端终端日志显示调用成功：

\[2026-09-11 20:59:56] 成功 | 提供方=huggingface\_hub(自动选择) HTTP=200 耗时=6.1s | InferenceClient.text\_to\_image(...)

生成成功：20260911-205956-386.png (提供方=huggingface\_hub，耗时=6.1s)

127.0.0.1 - - "POST /api/generate HTTP/1.1" 200

db083492-407b-4f72-9e29-69a5a426371e

【图 2：终端 API 调用成功日志截图】

c64a1931-3d76-4f75-821a-2e59caae5013
【图 3：前端页面最终生成图像截图（写实苹果）】

2.5 提示词设计思路与修改过程

版本 提示词 生成效果 问题分析
v1 室内桌面，白色圆盘，盘子上放一个红苹果，窗边柔和自然光
 日式山水插画风格（青山、圆月、鸟居） 中文提示词只描述了物体，模型自由发挥成插画风，与真实照片差距大
v2 v1 + 手机实拍照片，原生相机，无滤镜，浅景深
 国风插画（人物、圆月、书法印章） 中文写实词约束力弱，模型仍按"意境"出图
v3 室内木桌上，白色盘子，1个红苹果，窗边自然光，实拍照片，无滤镜
 中式庭院古风插画 仍非写实，说明仅靠中文加"实拍"字样无法控制风格
v4 Close-up shot, a red apple on a white plate, placed on a wooden table, soft natural light from the window, realistic fruit texture, DSLR raw photo, no filter, shallow depth of field, only desktop area in frame, subject centered
 逼真照片级：红苹果、白瓷盘、木桌、窗边自然光、浅景深全部符合 英文结构化提示词 + 镜头参数 + 质感词，约束力显著增强
设计思路总结：

  1. 写实提示词需要五要素：主体 + 场景 + 光线 + 镜头参数 + 质感词；

  2. 中文描述对模型风格约束弱，改用英文详细描述（DSLR raw photo、shallow depth of field、realistic texture）后真实感大幅提升；

  3. 明确画面边界（only desktop area in frame, subject centered）可避免多余元素；

  4. 通过多轮迭代对比，最终选定了 "最贴近真实世界" 的版本。

2.6 遇到的问题及解决方法

问题 原因 解决
生成结果偏插画风、与提示词不符 中文提示词约束力弱 改写为英文结构化提示词，加入镜头参数与质感词
API 请求偶尔超时 / 网络中断 境外推理服务、国内网络不稳定 设置 timeout=120 延长超时，必要时切换网络重试
图片保存路径报错 输出目录不存在 使用 os.makedirs(..., exist_ok=True) 自动创建目录

2.7 API 调用体验与心得

  1. API 调用门槛低：HuggingFace 把复杂模型封装成简单的 SDK 接口，几十行代码就能调用业界领先的图像生成模型，不需要本地 GPU，对个人开发者非常友好。

  2. 提示词工程是真正的门槛：同样的模型，中文简单描述得到的是插画，英文结构化描述得到的是逼真照片 ——"如何表达需求" 本身就是一种能力。

  3. 前端交互让 API 有了产品形态：把 API 调用封装成 Flask 接口，配合预设场景、历史记录等交互设计，几行代码的调用就变成了一个可用的工具，这让我体会到 "接口 + 前端 = 产品"。

  4. 工程细节很重要：密钥要放 .env 不硬编码、输出目录要自动创建、网络异常要兜底，这些细节决定程序能不能稳定跑起来。

  5. 云端推理有约束：免费额度有限、境外服务受网络影响，正式项目中需要关注计费与稳定性设计。

三、GitHub 个人主页搭建

采用方案一（个人资料自述文件）：新建与 GitHub ID 同名的仓库 Bari328，在根目录 README.md 撰写个人介绍，GitHub 会自动展示在个人主页。

README 包含内容：

  • 关于我：兴趣爱好（游戏：炉石传说酒馆战棋、饥荒联机、无畏契约；华语流行乐：周杰伦、陶喆、方大同；力量训练；养猫；理财；AI 创意编程）；想分享的经历（家教、AI 辅助创意编程等）

  • 技能与成果：编程语言、技术栈、项目经历、自我评估（已掌握 / 感兴趣方向 / 最希望学习）

  • 未来三年规划：考研方向的目标与理由
    47c461e9-5b7a-43c3-995d-f45d0dafe2ca

【图 4：GitHub 个人主页截图】

四、技能树梳理与自我评估

已具备的专业知识与能力

  • 能力 A：程序设计基础。熟练使用 C/C++ 与 Python，能阅读和编写中等规模程序；掌握常见数据结构与基本算法思想，具备一定的算法题解题能力。

  • 能力 B：Web 开发与 API 调用。了解 HTTP 协议与前后端交互流程，能用 Flask 搭建带接口的 Web 应用，编写 HTML/CSS/JavaScript 页面；本次作业完整实践了 "前端交互 → 后端接口 → 云端大模型 API" 的调用链路。

  • 能力 C：数据库基础。掌握 SQL 基本语法与 MySQL 的基本使用，能设计小型业务系统的表结构。

  • 能力 D：开发工具链。使用 Git/GitHub 进行版本管理，VS Code 高效编码，掌握 Linux 基础命令与服务器环境配置。

感兴趣的技术方向

AI 应用开发、Web 全栈、软件工程方法学（需求分析、设计模式、测试）。

尚欠缺的能力

  1. 工程化能力：大型项目的模块划分与架构设计经验不足，未接触过 CI/CD、容器化部署；

  2. 代码质量意识：单元测试、代码评审参与少，代码规范性与可维护性有待加强；

  3. 算法深度：动态规划、图论等高级算法不够熟练；

  4. 英文阅读：阅读英文技术文档速度慢，依赖翻译工具。

五、代码量统计与目标

  • 截至目前代码量：约 【5000】 行（主要来源：C/C++ 课程与数据结构作业约 2000 行、Java / 数据库课设约 1000 行、Python 脚本与本次软工作业约 1000 行、其他课程小项目约 1000 行）。

  • 本学期目标：完成软件工程课程项目（预计 5000+ 行），加上日常练习与工具脚本，总代码量达到 2 万行以上。

六、本课程最期待学习的知识与收获

  • 最期待学习的知识：软件需求分析方法（如何把模糊的想法变成可验收的规格说明）、团队协作流程（Git 协作规范、任务分工与进度管理）、测试与质量保障（单元测试、代码评审的实战）。

  • 希望获得的收获：完整经历一次 "从需求到上线" 的团队项目开发；建立工程化思维 —— 代码不仅要 "能跑"，更要 "可维护、可协作、可交付"；提升文档撰写与表达汇报能力。

七、AI 工具生成的软件工程学习指南及其分析

我使用 DeepSeek 生成了一份软件工程课程学习指南，原文如下：

软件工程课程学习指南（AI 生成）

  1. 理解软件生命周期：从需求分析、设计、编码、测试到维护，掌握每个阶段的核心活动与交付物。
  2. 掌握需求工程：学会用例图、用户故事等需求表达工具，多练习把口头需求转成可验证的规格。
  3. 重视设计模式与架构：掌握常用设计模式（工厂、观察者、单例等），了解 MVC、微服务等架构风格。
  4. 实践版本控制与协作：熟练使用 Git（分支策略、冲突解决），在团队中实践 PR 评审流程。
  5. 动手做项目，而不是只看书：软件工程是实践学科，建议以小组项目为主线贯穿学习。
  6. 学习测试与质量保障：单元测试、集成测试、代码覆盖率的基本概念与实践。
  7. 定期复盘与文档化：每个阶段写文档并复盘，训练表达与总结能力。

这份指南方向是对的，但每一条都停留在「要做什么」，没有回答「具体怎么做、做到什么程度算做到」。于是我又追问了一轮，让它给出可执行的步骤，并结合自己的情况整理成下面这份带交付物和验收标准的版本。

7.1 整体节奏：以小组项目为主线，一学期分四个阶段

软件工程是实践学科，所以我把所有学习动作都挂在一个真实的项目上（本学期就是课程小组项目），按 16 周切成四个阶段。每个阶段都必须有能拿出来的东西，避免"学了一学期但说不清做了什么"。

阶段 时间 重点 阶段交付物
一、需求与设计 第 1—4 周 把需求说清楚，把结构画出来 需求规格说明书（用户故事 + 验收标准 + 用例图）、模块图与时序图
二、实现与迭代 第 5—10 周 小步快跑，每两周一个可演示版本 可运行的 MVP、Git 分支与 PR 记录、迭代看板
三、测试与质量 第 11—14 周 让"能跑"变成"可靠" 单元测试与覆盖率报告、Bug 清单、CI 流水线
四、交付与复盘 第 15—16 周 把过程讲清楚 项目文档、演示 PPT、阶段复盘报告

7.2 七条指南的具体执行步骤

1. 理解软件生命周期

  • 第 1 周手绘一张生命周期图（需求 → 设计 → 编码 → 测试 → 维护），每个阶段标注三件事：输入什么、输出什么、谁验收。
  • 拿自己以前做过的课程项目反向对照，找出当时跳过了哪个阶段、造成了什么后果（比如需求没写清导致返工）。
  • 交付物：一页 A4 的《阶段—活动—交付物对照表》，作为课程笔记的第一页。
  • 验收标准：任意指一个阶段，我都能说清它的进入条件、核心活动和产出物。

2. 掌握需求工程

  • 拿到需求后先花 15 分钟写 5—8 条用户故事，格式统一为「作为……我希望……以便……」。
  • 每条用户故事补上验收标准（Given–When–Then），写不出验收标准的需求就说明还没想清楚。
  • 用 PlantUML 或 draw.io 画用例图，标出参与者和系统边界。
  • 找一位同学扮演用户，追问三个边界问题：空输入怎么办、两个人同时操作怎么办、没权限的用户能不能看见。
  • 交付物：需求规格说明书 v1（用户故事 + 验收标准 + 用例图）；学期中每次需求变更都记录在变更表里。
  • 验收标准：每条需求都能直接改写成一条可执行的测试用例。

3. 设计模式与架构

  • 每周精读 1 个设计模式，写一个不超过 100 行的最小可运行示例，比只画 UML 图有用得多。
  • 在自己的项目里找出至少一处可以应用的地方并真的重构（例如用策略模式替换长长的 if-else 分支）。
  • 画两张图：模块划分图（谁依赖谁）、核心流程的时序图（一次请求经过哪些对象）。
  • 交付物：模式笔记 + 一次带说明的重构提交，提交信息里写清楚"为什么重构"。
  • 验收标准：能讲明白"不这么设计会有什么问题"，而不只是背出模式定义。

4. 版本控制与协作

  • 第 1 周就和组员定好规则：main 分支保护、功能开发走 feature 分支、合并必须经过 PR。
  • 统一提交信息格式（feat / fix / docs / refactor / test + 简述），拒绝"update""修改一下"这类提交。
  • 每次 PR 至少一人评审，评审意见必须可执行：指出文件与行号，并给出建议改法。
  • 每周至少 3 次有效提交，把工作摊平到日常，避免最后一天集中提交。
  • 交付物：一个有真实 PR 记录和评审意见的仓库。
  • 验收标准：能独立处理三种冲突场景（同一文件不同分支修改、重命名冲突、合并时被覆盖的改动）。

5. 动手做项目，而不是只看书

  • 把课程项目当主线：每两周产出一个能演示的增量，先做最小可用版本（MVP），再逐步加功能。
  • 每次迭代结束跑一次"三分钟演示"：从零启动项目，在三分钟内给同学讲清这个版本能做什么。
  • 用 GitHub Projects 或 Trello 维护看板，需求先入池，再排进迭代，做完才移动到完成列。
  • 交付物：迭代计划表 + 至少三次可演示的版本记录。
  • 验收标准：不看代码也能说清每个版本新增了什么、还差什么。

6. 学习测试与质量保障

  • 从第 5 周开始，每个核心函数至少配一个单元测试，覆盖正常、边界、异常三类输入。
  • 用 pytest（或 JUnit）跑测试并统计覆盖率，本学期目标先定在 60% 以上，重点覆盖核心逻辑。
  • 提交前本地跑一遍测试；用 GitHub Actions 配置 CI，让每次 PR 自动跑测试并显示结果。
  • 维护一份 Bug 清单，每条记录现象、复现步骤、原因分析和修复方式。
  • 交付物：测试代码 + 覆盖率报告截图 + CI 运行记录。
  • 验收标准：改坏一处核心逻辑，测试能立刻失败并指出位置。

7. 定期复盘与文档化

  • 每周五留 30 分钟写周记：本周完成了什么、卡在哪里、下周做什么，三句话也写。
  • 每个阶段结束做一次复盘，格式固定为「3 个做得好的 + 2 个要改进的 + 1 个具体行动」。
  • 文档统一放在仓库 docs/ 目录，和代码同仓库维护，改代码时顺手改文档。
  • 交付物：一学期至少 10 篇周记 + 4 份阶段复盘。
  • 验收标准：翻看记录能还原出项目每一步是怎么决策的。

7.3 一周节奏参考

为了让上面的事真的发生，我给自己排了一个每周固定节奏：

时间 安排 时长
周一 梳理本周任务，拆进看板 20 分钟
周二—周四 项目开发，每次提交都写规范的提交信息 每天约 1 小时
周五 补测试、跑 CI、写周记 1 小时
周末 精读一个知识点（设计模式 / 架构 / 测试方法）并写笔记 1—2 小时

合计每周 5—6 小时，其中三分之二以上花在动手做，而不是看视频和收藏资料。

7.4 这份指南是否合理

合理的地方：方向踩得很准。它以项目为主线、强调测试与版本控制、要求定期复盘，这几条恰好对应软件工程"实践性极强"的特点，也符合老师在课上反复强调的"过程可追溯"。

不太合理或需要我自己补的地方：

  1. 太理想化，没考虑时间成本。 按原文同时推进七条，一学期根本做不完，所以我把它拆成分阶段推进，每个阶段只重点抓两条。
  2. 设计模式讲得太早。 对刚上手项目的人来说，先把命名、分层和可读性做好，比套用模式更重要，否则容易为了用模式而把代码写复杂。
  3. 没提需求变更管理。 真实项目里需求一定会变，所以我补了变更记录表，否则文档会迅速过期。
  4. 完全没提团队协作里的沟通问题。 分工不均、意见冲突、有人拖延，这些才是小组作业最容易翻车的地方，需要单独约定节奏和责任人。
  5. 缺少可验收的产出物。 原文只说"掌握""了解"，无法判断是否做到，所以我给每一条都补了交付物和验收标准。

7.5 对我的帮助

最大的帮助是把模糊的目标变成了具体动作。像"重视测试"这种话，我以前看完就过去了；现在变成了"每个核心函数配一个单元测试、覆盖率过 60%、PR 自动跑 CI"，是可以当天就开始做的事。

它也确实提醒了我两件容易忽略的事：一是把工作摊到平时（每周三次提交），二是每个阶段留一份可展示的产出。

但我也清楚它的边界：AI 给的是通用的、平均意义下的建议，它不知道我们小组的技术水平、项目类型和课程进度，所以不能照抄。我的用法是把它当成一份"检查清单"，逐条对照自己的实际情况做删改——保留能落地的，改掉不现实的，补上它没想到的。这样它才真的帮到我，而不是让我产生"收藏了就等于学会了"的错觉。

八、作业编写说明

  • 本随笔使用 Markdown 编辑器 编写（博客园「设置 → 编辑器」切换为 Markdown）。

  • 作业开头已按要求附上「课程信息表格」。
    image

【图 5：博客园后台博文编辑页面截图（Markdown 编辑器）】

posted @ 2026-09-11 23:54  Bari  阅读(5)  评论(0)    收藏  举报