2026 秋软件工程个人作业第一次

这个作业属于哪个课程	H202601 软件工程与软件工程实践
这个作业要求在哪里	2026 秋软件工程个人作业第一次
这个作业的目标	完成一次带前端交互的 Hugging Face 图像生成调用，完善 GitHub 个人主页，梳理自己的能力边界，并为本学期的软件工程学习确定目标
学号	102402127

一、准备情况

我的 GitHub 账号是 AiY0u，个人博客放在 aiy0u.github.io。这个站点从 2025 年开始记录学习过程，目前有 35 篇公开文章，主要内容是密码学、数学、Python 和 CTF Crypto。由于站点更新较早，它没有完整反映我最近的学习情况：目前我的主要方向是 CTF Web 与 Crypto，Web 方面已经学习 PHP 与 SQL 基础、HTTP 参数与会话处理、Burp Suite、SQL 注入、XSS、文件上传、文件包含、SSRF 和 XXE。

博客园账号已经实名加入 H202601 软件工程与软件工程实践班级，班级成员页显示学号为 102402127、实名为金若曦。个人博客也已经开通，地址是山冇木兮木有枝。我已经关注任课老师黄兆武和两位助教李怡涵、焦圣蒙，并在关注后重新打开三人的主页核对状态。

二、调用 Hugging Face API 生成写实图像

2.1 模型与实现思路

作业指定的 XLabs-AI/flux-RealismLora 是一个写实 LoRA，模型卡标注的基础模型为 black-forest-labs/FLUX.1-dev，任务类型为 text-to-image。它使用 FLUX.1 dev 的非商业许可证。本次生成只用于课程学习和作业展示。

我把程序分成浏览器和本地服务两个部分。浏览器负责收集提示词、负面提示词、分辨率与 Seed，再显示图片和调用记录。本地 Node 服务保存 Hugging Face Token，并向指定模型发送请求。这样处理以后，Token 不会出现在前端源码和浏览器网络请求里。

项目目录中的关键文件如下。

flux-lab/
├── public/
│   ├── index.html
│   ├── styles.css
│   └── app.js
├── .env.example
├── package.json
└── server.js

2.2 后端调用代码

下面是后端请求 Hugging Face 的主要代码。页面传来的参数会先经过长度、尺寸和 Seed 校验，随后才会进入生成请求。服务端设置了两分钟超时，也会把上游错误返回给前端，方便判断是 Token、模型权限、网络还是服务状态出了问题。

import { InferenceClient } from '@huggingface/inference';

const model = 'XLabs-AI/flux-RealismLora';
const provider = 'fal-ai';
const client = new InferenceClient(process.env.HF_TOKEN);

const imageBlob = await client.textToImage({
  model,
  provider,
  inputs: input.prompt,
  parameters: {
    width: input.width,
    height: input.height,
    num_inference_steps: 28,
    guidance_scale: 3.5,
    negative_prompt: input.negativePrompt,
    seed: input.seed
  }
}, {
  outputType: 'blob',
  retry_on_error: false,
  signal: AbortSignal.timeout(120000)
});

前端使用 fetch 请求本地接口。生成成功后，页面会显示图片、模型名称、请求编号和耗时，同时允许下载结果。

const response = await fetch('/api/generate', {
  method: 'POST',
  headers: { 'content-type': 'application/json' },
  body: JSON.stringify({
    prompt,
    negativePrompt,
    seed,
    width: size,
    height: size
  })
});

const result = await response.json();

2.3 操作步骤与调用记录

我先在 Hugging Face 创建只用于本次实验的 Token，随后确认基础模型许可，把 Token 写入本地 .env。这个文件已经加入 .gitignore，不会上传到 GitHub。

npm start

本次运行时使用 PORT=4175 npm start 启动服务，再访问 http://127.0.0.1:4175。后端会输出模型名称和 Token 配置状态，每次请求还会记录请求编号、图片大小和耗时，不输出 Token 内容。

最终请求返回 HTTP 200，请求编号是 flux-879ee7a2，推理提供商为 fal-ai。服务端收到 344922 字节的 JPEG 数据，接口返回的总耗时为 25246 ms。截图省略了 Token 和体积很大的 Base64 图像正文，只保留可核对的请求参数与响应摘要。

2.4 前端交互与最终结果

页面左侧是提示词和参数，右侧是图片结果。下方保留本次打开页面后的调用轨迹。错误也会出现在页面内，不需要只靠终端猜原因。

前端恢复并显示了同一次调用的结果，页面中的请求编号、模型名称、耗时和下方 200 OK 轨迹能与后端记录对应。请求参数填写的是 768 × 768，提供商最终返回的图片实际为 1024 × 768。这也提醒我，调用第三方推理服务时不能只相信请求参数，还要检查实际响应。

2.5 提示词的设计与修改

这次提示词围绕一个海边旧书店展开。目标是生成有现实摄影感的普通场景，避免画面只剩抽象的“高清”和“电影感”。下面三版是发送请求前的文字修改过程。免费生成次数有限，因此我只把最终版交给模型，没有把未运行的版本写成实际生成效果。

第一版只写主体和时间。

A quiet coastal bookshop at blue hour

这句话能确定地点与光线时段，场景细节仍然很少。第二版加入窗内暖光、旧木书架和门外自行车，让模型得到可以落到画面里的物件。

A quiet coastal bookshop at blue hour, warm light through the windows,
weathered wooden shelves, a bicycle parked outside

最终版补上摄影方式、材质、光影和镜头语言，并用负面提示词减少水印、文字和过饱和色彩。

A documentary-style photograph of a quiet coastal bookshop at blue hour,
warm light glowing through the windows, weathered wooden shelves,
a bicycle parked outside, realistic textures, natural shadows,
35mm lens, high detail

Negative prompt
text, watermark, logo, oversaturated colors, distorted geometry

最终图基本实现了预期。蓝调时刻、暖色橱窗、成排书架和门外自行车都出现在画面中，冷暖光线对比自然，整体接近街头摄影。局部书脊和封面上的小字仍然无法逐字辨认，这是结果中较明显的模型痕迹。负面提示词没有完全消除画面里的书封文字，但成图没有出现水印或独立 Logo。

2.6 这次调用带来的认识

这次调用让我确认，模型仓库、基础模型、许可协议和推理服务是四件相关但各自独立的东西。找到模型页面不代表接口一定可用，LoRA 也需要基础模型才能生成图像。我先获得 FLUX.1-dev 的访问许可，又给细粒度 Token 增加了受限公开仓库读取权限和 Inference Providers 调用权限，基础模型文件访问才从 403 变成 200。

网络问题同样不能只用“接口失败”概括。第一次正式请求已经进入推理流程，却在 SDK 下载结果图片时被本机代理中断。检查后发现，Hugging Face 域名需要代理，而 v3.fal.media 这类图片存储域名直连可用，走代理反而会被重置。我把请求按域名分流，只允许 Hugging Face 的幂等 GET 和 HEAD 请求做有限网络重试，生成图片的 POST 始终不自动重试。修正以后，请求成功返回，刷新前端也能恢复同一结果，不需要再次生成。

把 Token 留在服务端也很有必要。直接写进网页虽然省事，任何打开开发者工具的人都能看到它。本地服务只向前端返回生成结果和必要的诊断信息，.env 也被 .gitignore 排除。这个过程让我意识到，一次可复现的 API 调用不仅要“拿到图片”，还要处理权限、密钥、网络、错误记录和重复计费风险。

三、GitHub 个人主页

我选择使用已有的 GitHub Pages。原站已经有文章、分类和标签，这次在 /about/ 增加了一页完整的个人介绍，并把首页导航入口改到了该页面。

个人主页地址为 https://aiy0u.github.io/about/。页面包括个人兴趣、公开技术记录、技能自评、仍需补齐的能力和 2026 至 2029 年规划。技能说明尽量链接到能被打开核对的文章，没有用空泛的熟练度百分比代替作品。

未来三年我会继续深耕网络安全，并以升学为明确目标。2026 至 2027 年补齐软件工程和计算机基础，把 Web、Crypto 题目中零散使用的知识连成体系；2027 至 2028 年继续参加竞赛和安全实践，寻找更具体的研究兴趣，同时准备升学所需的专业课与英语；2028 至 2029 年根据自身条件选择保研或考研路径，围绕目标院校和安全方向集中准备。选择升学，是因为我希望继续深入安全问题背后的原理与研究方法，而不只停留在完成单道题目。

四、我的技能树和技术偏好

4.1 目前能够完成的事情

Web 安全基础与题目分析

我已经学习 PHP 与 SQL 基础，能够理解常见 Web 请求中的 GET、POST、Cookie、Session 与文件上传过程，并使用 Burp Suite 观察、修改和重放请求。我接触并练习过 SQL 注入、XSS、文件上传、文件包含、SSRF 和 XXE 等常见漏洞类型。做题时，我会先从参数入口、数据流和危险函数入手阅读代码，再通过构造请求和比较响应验证判断。与 Crypto 一样，这部分能力主要在 CTF 场景中积累，距离真实系统中的完整代码审计和漏洞治理还有差距。

密码学基础与题目分析

我已经系统接触过 XOR、AES、DES、RSA、Diffie-Hellman、ECC、ECDSA、ElGamal、Coppersmith、LLL、MOV 与 Pohlig-Hellman。现有博客保留了对应的概念整理和题目记录。我能根据已知条件寻找算法入口，再用脚本验证推导结果。

Python 与 CTF 解题脚本

我能使用 Python 完成算法验证、数据处理和 Crypto 题目求解，接触过 pwntools；在 Web 题目中也会编写请求、编码转换和自动化验证脚本。代码目前以解题和实验脚本居多，处理单一问题比较顺手。

技术资料整理

我能把一次学习过程整理成带公式、代码和步骤的博客文章。到目前为止，GitHub Pages 上有 35 篇公开记录。持续写作让我更容易发现推导中跳过的步骤，也方便以后重新检查。

4.2 感兴趣的方向

我目前的技术定位是 Web 手与密码手，最关注 Web 安全、现代密码学、CTF Web/Crypto 和安全研究。我希望继续理解漏洞与算法背后的原理，同时学习怎样把验证思路变成结构清楚、可以测试和长期维护的安全工具。AI 工具参与开发流程时的可靠性与安全边界，也是我希望继续观察的主题。

4.3 还欠缺的能力

我缺少完整团队项目经验。需求怎样拆分，接口怎样协商，分支冲突怎样处理，评审意见怎样落到代码中，这些都需要在真实协作里练习。

自动化测试和持续集成也是短板。以前的脚本通常以算出结果为结束条件，对异常输入、回归测试和环境复现考虑得不够。

前端与产品表达还在入门阶段。我需要继续练习响应式布局、可访问性、加载反馈和错误提示，让工具在功能之外也能让人顺利使用。

五、代码量与本学期目标

截至本次作业，我的累计代码量约为 10000 行。这些代码主要来自前期大量 CTF Web 与 Crypto 题目的解题脚本、算法验证、请求构造与数据处理代码，也包括近期完成的前后端练习。由于部分题目代码只保存在本地，较早的 GitHub Pages 也没有同步全部学习内容，这个数字按练习记录做近似统计。我没有把第三方依赖、Hexo 生成文件和直接复制的代码计入其中。

本学期结束时，我希望按同一口径累计达到 20000 行。新增代码不只来自 CTF 练习，也会包括课程团队项目、单元测试、接口实现和必要的工程脚本。代码行数只能说明练习规模，能否维护、测试和协作仍要通过项目过程判断。

六、我对这门课的期待

我最期待走完一次完整的软件开发过程。目前的代码大多围绕一个知识点或一道 CTF 题，输入和输出都比较明确。团队项目会带来更复杂的情况，需求会变化，接口会互相影响，交付还要考虑测试、部署与使用者反馈。

我希望课程结束时能留下一个持续迭代的项目，以及一套自己真正用过的工作方法。具体来说，我想学会写清需求，做出合理的模块划分，使用 Git 协作，给关键逻辑补测试，并在每轮迭代后根据事实调整计划。这些能力也能帮助我把 Web 与 Crypto 解题中积累的技术转化为更完整的安全项目，为后续升学和安全方向学习打基础。

七、ChatGPT 生成的软件工程学习指南

我使用 ChatGPT 生成了一份简要的软件工程课程学习指南，内容如下。

先理解软件工程解决的问题。学习软件生命周期、常见过程模型和敏捷开发，知道每种方法适合什么规模与约束。

从需求开始练习。把用户目标写成功能需求与非功能需求，使用用例、原型和验收标准减少理解偏差。

学会设计边界。练习模块划分、接口设计、数据建模和 UML，用高内聚、低耦合检查方案。

把质量活动放进开发过程。为关键逻辑编写单元测试，配合集成测试、代码评审和静态检查，持续处理缺陷。

使用 Git 支持协作。采用清楚的分支和提交习惯，通过 Issue、Pull Request 与评审记录工作过程。

用一个团队项目串联知识。每轮迭代都留下需求、设计、代码、测试和复盘，根据反馈调整下一轮计划。

谨慎使用 AI 工具。让 AI 帮助检索、解释、生成初稿和测试思路，提交前核对事实、许可证、安全风险与代码行为。

这份指南的范围比较合理。它把需求、设计、编码、测试和协作放在同一条学习线上，也提醒我保留每轮迭代的材料。对我最有帮助的是第二、第四和第六点。过去做题时，目标通常已经写在题面里，我很少自己澄清需求。脚本算出答案以后，测试和维护也就停止了。课程项目会迫使我处理这些缺口。

它仍然只是一份通用指南。课程的真实进度、团队分工和评分要求没有包含在里面，遇到需求冲突时怎样沟通也说得很少。我会把它当作检查表，实际安排以课堂、作业和团队约定为准。

八、Markdown 编辑记录

本篇随笔使用博客园 Markdown 编辑器编写，后台编辑页面截图如下。

posted @ 2026-09-12 00:07 山冇木兮木有枝阅读(8) 评论(0) 收藏举报

刷新页面返回顶部