软工第一次作业周凯

软件工程入门实践：从大模型 API 到个人技术主页

本文按作业要求使用 Markdown 撰写，博客园后台已切换为 Markdown 编辑器（见文末附录截图）。

这个作业属于哪个课程	2026-01 软件工程与软件工程实践(FZU)
这个作业要求在哪里	作业要求
这个作业的目标	梳理自身技能与不足；体验大模型 API 调用与前端交互开发；搭建 GitHub 个人主页；借助 AI 生成软件工程学习指南并进行分析
学号	102402148 周凯

---

一、关于我：技能与不足

我是周凯，福州大学数据科学与大数据技术专业大三在读学生。

课余时间我喜欢健身、摄影，也喜欢折腾各种生产力工具。学习方面，我对数据与计算机相关领域比较感兴趣，习惯通过实际操作理解理论知识——比起"看懂"，我更在意"自己跑通一遍"。我希望能把课堂上学到的东西，真正用到能落地的问题上。

目前我正在系统学习 Python、SQL、数据结构与算法、数据库原理，也开始接触 Web 开发、大模型 API 与软件工程实践。

1.1 当前技能树与自我评估

以下评价按我实际动手完成过的任务来写，不把"用过某个工具"等同于"已经掌握"。

能力方向	已经掌握的知识与实践	仍需深入的部分
Python	能独立配置隔离环境（venv/pip），完成数据采集、数据清洗、脚本自动化；能调用大模型 API 完成简单 AI 应用	大规模工程化开发、代码规范、项目部署、MLOps
数据采集与处理	掌握 HTTP 请求（GET / POST / 混合）、网页数据解析与落盘，能用正则与 BeautifulSoup 提取结构化数据	大规模采集、增量同步、数据质量校验
Web 后端（Flask）	能写路由、解析 args/form/JSON 参数、返回 JSON 与静态资源，自建站点做端到端验证	蓝图与项目分层、鉴权、并发与性能优化
Web 前端	HTML/CSS/JavaScript 基础，能用 fetch 异步调后端、渲染结果、做参数面板与调用日志表	Vue/React 组件化、前端工程化、打包构建
数据分析	会用 pandas / NumPy 做去重、缺失值处理、聚合统计	数据建模、特征工程、业务指标设计与分析
数据库 / SQL	会基础 CRUD 与简单查询	多表关联、窗口函数、索引原理、事务与可靠性
大数据生态	已了解 Hadoop / Spark / Hive / Flink 的基本概念	全部待实战：搭集群、跑作业、分层建模（ODS/DWD/DWS）
Git / GitHub	已用 Git 管理代码，完成 GitHub 账号注册、Profile README 与 GitHub Pages 个人主页搭建	分支策略、多人协作、Pull Request、Code Review 完整流程
AI 应用开发	已完成大模型文生图 API 调用，并用 Flask + 原生前端搭出可交互的生成页面	更复杂的大模型应用、模型部署、AI 工程化
软件工程	了解基本概念，能按任务要求完成项目实践与文档输出	需求分析、系统设计、软件测试、项目管理、团队协作

1.2 最需要加强的能力

① 计算机底层基础

目前对底层原理理解不够深入。虽然能用很多工具和框架完成任务，但对计算机组成、操作系统、计算机网络这些"地基"还需要系统补课——否则遇到性能问题只能靠猜。

② 完整的软件工程实践能力

我的实践目前集中在课程作业层面，还缺少一个完整项目"从需求分析 → 系统设计 → 编码 → 测试 → 部署上线"的全流程经验。尤其是测试和团队协作，几乎为零。

③ 大数据专业核心栈的实战能力

作为数据科学与大数据技术专业的学生，我目前只做到了"会用 Python 采集和处理小规模数据"，还不会"用 Hadoop/Spark 处理大规模数据"。这是我专业方向上最大的短板，也是接下来两年的主线。

1.3 技术偏好与希望学习的方向

我比较感兴趣的方向是数据工程 / 大数据开发，以及AI 应用工程化。

我希望进一步学习：

• 大数据生态：Hadoop、HDFS、Spark / PySpark、Hive、Flink
• 数据仓库与建模：ODS/DWD/DWS 分层、指标体系建设
• 数据库进阶：SQL 优化、索引原理、事务
• AI 应用工程化：大模型 API 集成、Prompt 工程、模型部署
• 软件工程方法：UML、模块化设计、单元测试、Git 协作流程
• Linux 与部署：Docker、服务器部署、日志监控

我希望以后不仅能调用现成的 AI 工具，还能理解背后的原理，并独立完成一个较完整的、能交付的项目。

---

二、三年发展规划

为了让学习目标更明确，我根据目前的阶段制定了未来三年的规划。

我选择就业作为主线。理由很直接：我喜欢"做出能被别人用的东西"这个过程，想尽早进入真实工程环境，用真实项目的复杂度倒逼自己成长；同时我的算法与底层基础目前偏弱，直接冲考研的风险与收益不成正比。这不是放弃深造，而是先把工程能力扎稳——读研可以是以后的事，工程手感只能靠项目堆出来。

时间	主要目标	具体计划
第一年	夯实基础 + 专业栈入门	系统学习数据结构与算法（LeetCode 200+ 题）；学完数据库原理，能写多表关联与窗口函数；搭起 Hadoop/HDFS 伪分布式环境，用 PySpark 跑通批处理作业；用分支 + PR + Review 完整参与一个多人项目；期末代码量达到 15,000 行且带单元测试
第二年	走通数据全链路 + 找实习	交付 2 个数据全链路项目（采集 → 清洗 → 入仓 → 分析 → 可视化）；学 Hive 分层建模，能独立出一个主题域的指标体系；切入 Flink 做"批流一体"小项目；拿到第一份数据开发实习，走完需求评审 → 开发 → 联调 → 上线
第三年	秋招冲刺与沉淀	完成 3 轮系统性复盘（算法、大数据八股、项目）；拿到大数据开发 / 数据工程方向的校招 offer；毕业设计做一件自己真正想做的事

第一年：打地基，把专业栈立起来

第一年的核心是补短板。算法、数据库、Git 协作这三项是"学校不催但企业必问"的，必须靠自己主动补。

同时我要完成大数据生态的入门：先把单机伪分布式环境搭起来，能用 PySpark 跑通一个完整的批处理作业（读数据 → 转换 → 聚合 → 输出），理解 MapReduce 的思想，而不只是会调 API。

量化目标：期末代码量 15,000 行，且其中至少有 1 个项目带单元测试。

第二年：做深度，走通数据全链路

第二年要从"会写脚本"升级到"能交付项目"。

我希望完整交付 2 个能写进简历的项目，最好是数据全链路的：数据从采集进来，经过清洗入仓，最终变成可看的指标或看板。这个过程会逼我同时用上采集、SQL、数据仓库、调度和可视化的能力。

同时争取拿到第一份数据开发实习——课堂上学不到的"需求评审、联调、上线、踩坑复盘"，只有真实项目能给。

量化目标：累计代码量 30,000 行，参与 Code Review 30 次以上。

第三年：收成果，秋招与沉淀

第三年主要做三件事：复盘、拿 offer、做毕设。

秋招前我会完成三轮系统性复盘（算法刷题、大数据八股、项目亮点梳理），把前两年的积累整理成能讲清楚的东西。目标岗位是大数据开发 / 数据工程。

毕业设计我希望做一件自己真正想做的事，而不是"为了毕业而做"。

量化目标：累计代码量 50,000 行。

衡量标准不靠感觉，靠数字：代码行数、可运行项目数、算法题数、Code Review 参与次数。

---

三、代码量与本学期目标

目前我的累计代码量约为 3,500 行。其中本课程的实践产出约 2,500 行，主要来自 AI 图片生成系统、GitHub 个人主页，以及配套的自动化工具脚本。

项目	数量
目前累计代码量	约 3,500 行
本学期计划新增代码	11,500 行
课程结束总目标	约 15,000 行

代码量只是一个自我衡量的指标，我并不单纯追求行数。我更在意的是：这些代码里有多少是结构清晰、能被别人读懂的。

我希望通过本学期的软件工程课程，让自己的代码从"能够运行"逐渐转变成"结构清晰、容易维护、方便协作"，同时用 GitHub 把学习过程记录下来，让成长可追溯。

---

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

4.1 期待学习的知识

① 软件工程完整开发流程

希望系统了解需求分析、概要设计、详细设计、编码、软件测试、项目交付的完整流程，而不是拿到题目就直接写代码。

② 工程化开发规范

希望学习 UML、模块化设计、版本管理、单元测试、项目文档这些"让代码能被维护"的方法。

③ 团队软件开发

希望了解多人协作中的任务分工、代码管理、冲突解决与代码评审——这是我目前完全空白的一块。

④ 项目管理

希望学习如何对一个完整项目做任务划分、进度管理和质量控制。

4.2 希望获得的收获

通过本课程，我希望能够：

• 建立基本的软件工程思维；
• 不再只追求"代码能运行"，而是更关注代码的可维护性；
• 掌握规范的软件项目开发流程；
• 学会编写更规范的项目文档；
• 掌握 Git / GitHub 的基本协作方式；
• 能够独立完成一个小型软件项目的完整开发流程；
• 为以后参与更大型的项目和科研工作打下基础。

---

五、基于大模型 API 的 AI 图片生成系统

5.1 实验目的

本次实验的目标是学习大模型平台 API 的基本调用方法，并把 API 调用与前端页面结合起来，做成一个可交互的图片生成应用。

具体要求是：注册平台上账号并获取 API Token，调用 Flux 系列写实模型，根据用户输入的文字提示词生成图片；同时用 Flask + HTML/CSS/JavaScript 做一个 Web 页面，让用户可以输入 Prompt、点击按钮、看到生成结果。

通过本次实践，我学习了：

• API Token 的获取与安全配置（不写死在源码里）；
• Python 虚拟环境与依赖管理；
• 大模型推理 API 的调用方式（huggingface_hub / OpenAI 兼容接口）；
• Flask Web 框架与前后端数据交互；
• API 调用过程中的错误处理；
• Prompt 的设计与迭代优化。

5.2 实验环境

项目	环境
操作系统	Windows 11
编程语言	Python 3.13
Web 框架	Flask 3.1.3
前端技术	HTML / CSS / JavaScript（原生 fetch）
AI 平台	Hugging Face（标准调用代码）/ 硅基流动 SiliconFlow（实际跑通）
目标模型	XLabs-AI/flux-RealismLora（基于 FLUX.1-dev 的写实 LoRA）
实际使用模型	Kwai-Kolors/Kolors（同源写实文生图模型）
图片处理	Pillow（落盘与水印）
浏览器自动化	Playwright（截图与交互验证）

5.3 项目功能介绍

项目实现了一个 AI 图片生成网页，完整流程如下：

用户在网页输入 Prompt
        ↓
前端 JavaScript 收集参数（提示词 / 负向提示 / 步数 / 引导强度 / 尺寸 / 种子）
        ↓
POST /api/generate
        ↓
Flask 后端接收参数
        ↓
后端调用图像生成 API
        ↓
模型推理生成图片
        ↓
后端下载图片并落盘到 static/gen/，同时写入调用日志
        ↓
前端显示生成结果与耗时

页面功能包括：提示词输入框、负向提示词、参考提示词芯片（一键填入）、推理步数与引导强度滑块、画面尺寸选择、随机种子（可固定复现）、模型切换，以及一张实时刷新的 API 调用日志表。

📷 请上传截图：HF图像生成/shots/hf_home.png（前端首页）

5.4 API 调用过程与账号配置

第一步：注册账号并获取 Token。 在平台官网注册个人账号后，进入「API 密钥 / Access Tokens」页面创建一个只读权限的 Token。

第二步：安全保存 Token。 我没有把 Token 直接写在源码里，而是单独存到本地文件 sf_key.txt，代码运行时读取：

def load_api_key(path="sf_key.txt"):
    """从本地文件读取 API Key，避免硬编码在源码中"""
    return Path(path).read_text(encoding="utf-8").strip()

同理，Hugging Face 版本用的是环境变量方式：

from dotenv import load_dotenv
import os

load_dotenv()
HF_TOKEN = os.getenv("HF_TOKEN")

第三步：连通性测试。 调用前先用 curl 探测接口是否可达，并用一个最小请求验证 Token 是否有效：

# 探测接口可达性
curl -s -o /dev/null -w "%{http_code} %{time_total}s\n" \
  https://api-inference.huggingface.co/models/XLabs-AI/flux-RealismLora

# 验证 Token 是否有效（返回模型列表）
curl -s https://api.siliconflow.cn/v1/models -H "Authorization: Bearer $KEY"

5.5 项目目录结构

HF图像生成/
├── app.py                      Flask 后端（双通道：HF 官方 / 国内兼容）
├── hf_client.py                通道 A：Hugging Face 标准调用实现
├── sf_client.py                通道 B：OpenAI 兼容接口调用实现
├── templates/
│   └── index.html              前端页面（参数面板 + 结果区 + 调用日志表）
├── static/gen/                 生成图片自动落盘目录
├── logs/api_logs.jsonl         API 调用记录（每行一条 JSON）
├── prompt_iterations.json      三轮提示词迭代记录
└── sf_key.txt                  本地保存的 API Key（不入库、不外传）

文件	作用
app.py	Flask 后端，提供 / 页面与 /api/generate 接口
hf_client.py	Hugging Face InferenceClient 的标准调用实现
sf_client.py	国内兼容平台调用实现（实际跑通用）
templates/index.html	交互前端，含参数面板与日志表
logs/api_logs.jsonl	记录每次调用的时间、模型、耗时、种子、状态
prompt_iterations.json	记录 v1→v2→v3 三轮提示词与参数

5.6 API 调用实现

Hugging Face 官方调用方式（标准写法，保存在 hf_client.py）：

from huggingface_hub import InferenceClient

client = InferenceClient(provider="auto", api_key=HF_TOKEN)
MODEL_ID = "XLabs-AI/flux-RealismLora"

# 文本生成图片
image = client.text_to_image(
    prompt=prompt,
    model=MODEL_ID,
)
image.save("generated_image.png")

实际跑通的接口调用（sf_client.py）：

import requests

resp = requests.post(
    "https://api.siliconflow.cn/v1/images/generations",
    headers={"Authorization": f"Bearer {api_key}"},
    json={
        "model": "Kwai-Kolors/Kolors",
        "prompt": prompt,
        "negative_prompt": negative,
        "image_size": size,              # 如 768x1024
        "num_inference_steps": steps,    # 推理步数
        "guidance_scale": guidance,      # 引导强度
        "batch_size": 1,
    },
    timeout=120,
)
image_url = resp.json()["images"][0]["url"]

关于图片落盘与日志：生成后的图片 URL 是临时的，我写了一个函数把它下载到 static/gen/，按 模型名_时间戳_随机串.png 命名，同时追加一条调用记录到日志文件——这样每次调用都有据可查。

5.7 前后端交互

前端用原生 fetch 调用后端接口，不依赖任何框架：

async function generate() {
  const btn = document.getElementById('btn');
  btn.disabled = true;
  btn.textContent = '⏳ 调用中，模型生成通常 10~90 秒……';

  const body = {
    prompt:   document.getElementById('prompt').value,
    negative: document.getElementById('negative').value,
    steps:    +document.getElementById('steps').value,
    guidance: +document.getElementById('guidance').value,
    size:     document.getElementById('size').value,
    seed:     document.getElementById('seed').value
  };

  const t0 = Date.now();
  const r = await fetch('/api/generate', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify(body)
  });
  const j = await r.json();

  if (j.ok) {
    // 显示图片 + 耗时 + 模型 + 种子
    document.getElementById('result').innerHTML =
      `<img src="${j.image_url}" alt="生成图">`;
    document.getElementById('meta').textContent =
      `✅ 生成成功 · 耗时 ${((Date.now()-t0)/1000).toFixed(1)}s · 种子 ${j.seed}`;
  } else {
    document.getElementById('result').innerHTML =
      `<div style="color:#dc2626">❌ 生成失败：${j.message}</div>`;
  }
  btn.disabled = false;
  loadLogs();   // 刷新调用日志表
}

后端对应接口：

@app.route("/api/generate", methods=["POST"])
def api_generate():
    data = request.get_json()
    result = sf_client.generate(
        prompt=data["prompt"],
        negative=data.get("negative", ""),
        steps=int(data.get("steps", 20)),
        guidance=float(data.get("guidance", 5.0)),
        size=data.get("size", "1024x1024"),
        seed=data.get("seed", "random"),
    )
    # 下载图片到本地 + 写日志
    local_path = save_image(result["url"], model=data["model"])
    write_log(status="SUCCESS", model=data["model"],
              elapsed=result["elapsed"], seed=result["seed"])
    return jsonify(ok=True, image_url=local_path, seed=result["seed"],
                   elapsed=result["elapsed"])

这样整个系统形成了 文本输入 → API 请求 → 模型推理 → 图片生成 → 前端展示 的完整闭环。

5.8 Prompt 设计与优化

这是本次实验我收获最大的一部分。 我做了三轮提示词迭代，亲眼看到提示词从"大白话"变成"摄影参数"后，图片真实感的明显提升。

v1：中文大白话描述

一名中国男大学生坐在大学图书馆窗边看书，穿灰色卫衣，阳光照在脸上，真实照片

参数：步数 20，引导强度 5.0

结果：构图完整、氛围到位，但整体偏"网红滤镜风"，皮肤过于光滑，不像真实照片。

）

v2：改成结构化英文，补充场景与光线

Photorealistic portrait of a 20-year-old Chinese male college student with short black hair,
wearing a casual gray hoodie, sitting by a window in a university library, holding an open
textbook, soft warm afternoon sunlight on his face, blurred bookshelf background,
natural skin texture, candid moment

负向提示：cartoon, anime, illustration　参数：步数 24，引导强度 5.0

结果：背景虚化明显改善，皮肤质感自然了许多。但光线偏"戏剧化"，不够日常。

v3：加入摄影器材与光学参数（最终版）

Hyper-realistic DSLR photograph, close-up portrait of a 20-year-old Chinese male college
student, short black hair, gentle genuine smile, wearing a gray hoodie, sitting in a modern
university library near a large window, golden-hour rim light, bookshelves rendered as soft
bokeh, 85mm f/1.4 shallow depth of field, fine skin pores and individual hair strands,
high dynamic range, sharp focus on eyes

负向提示：cartoon, anime, illustration, painting, 3d render, low quality, blurry, deformed hands, extra fingers, oversaturated, fake

参数：步数 30，引导强度 6.0，固定种子 987654321

结果：头发丝清晰、眼神有高光、皮肤能看出毛孔、背景书架呈现自然光斑虚化——最贴近真实世界的一张。

版本	关键改动	生成耗时	效果评价
v1	中文大白话	3.56s	构图完整，但偏"网红滤镜"，质感假
v2	结构化英文 + 场景光线 + 负向提示	6.09s	虚化与皮肤质感改善，光线偏戏剧化
v3	摄影器材 + 光圈景深 + 细节词 + 完整负向 + 固定种子	6.29s	皮肤纹理、发丝、眼神光、光斑虚化最真实

📷 请上传截图：HF图像生成/shots/hf_compare.png（三版对比图）

我的总结：Prompt 不只是"描述想生成什么"，还可以进一步描述：

• 场景与环境（图书馆、窗边、书架）
• 人物特征（年龄、发型、服装、表情）
• 光照条件（golden-hour rim light 金色时刻轮廓光）
• 摄影器材与镜头（85mm f/1.4）
• 画面质感（fine skin pores / individual hair strands）
• 构图与景深（shallow depth of field）
• 整体风格（Hyper-realistic DSLR photograph）

我也意识到，"真实感"这件事和我的摄影爱好直接相关——正因为平时拍照，我能一眼看出生成图"假"在哪：皮肤没有毛孔、光线方向不一致、背景虚化不符合光学规律。这让我知道该往提示词里加什么。

5.9 实验结果与调用记录

最终成功实现了完整的端到端流程：用户输入 Prompt → 前端发请求 → Flask 调用大模型 API → 生成图片 → 返回前端展示。

logs/api_logs.jsonl 中记录了每一次真实调用（共 4 条 SUCCESS）：

2026-09-06 15:08:20 | SUCCESS | siliconflow/Kwai-Kolors/Kolors | 4.38s | seed=74774671
2026-09-06 15:08:44 | SUCCESS | siliconflow/Kwai-Kolors/Kolors | 3.56s | seed=1481642604
2026-09-06 15:08:49 | SUCCESS | siliconflow/Kwai-Kolors/Kolors | 6.09s | seed=2024308191
2026-09-06 15:08:57 | SUCCESS | siliconflow/Kwai-Kolors/Kolors | 6.29s | seed=987654321

关于模型的实际选择（如实说明）：作业要求调用 XLabs-AI/flux-RealismLora。我在实践时遇到两个客观情况：一是本机网络无法直连 Hugging Face 官方推理端点（多次 curl 超时）；二是国内平台上的 Flux 系模型恰好已下架（返回 Model disabled / Model does not exist）。

因此我采取了双通道设计：hf_client.py 保留 Hugging Face InferenceClient 的标准调用代码（作业要求的写法），sf_client.py 则在网络可达的国内平台上，用同源的写实文生图模型 Kwai-Kolors 完成了端到端的真实生成验证。这个"降级但不放弃"的过程，反而让我更理解了接口抽象的意义——只要接口形态一致，换平台只是换一个参数。

5.10 API 调用体验与心得

① 调用之前先做连通性测试，能省掉大量无效调试。

我最开始直接写业务代码，报错后分不清是"网络不通"还是"代码写错"。后来养成习惯——先用 curl 探一次接口可达性和 Token 有效性，确认链路通了再写业务逻辑。这一步只花两分钟，但避免了很多瞎猜。

② 提示词工程的收益远比想象中大。

同样是"生成一张写实人像"，v1 到 v3 的差别不是"好一点"，而是"一眼假"和"像真的"的差别。我原本以为 AI 生成图主要靠模型能力，做完才发现提示词是普通人能掌控的最大变量。而且这门手艺是可以迁移的——我现在写提示词会不自觉地按"主体 → 场景 → 光线 → 器材 → 质感"的结构来组织。

③ 把每次调用落成日志，是个很小但很值的好习惯。

一开始只是为了排查问题，后来发现 api_logs.jsonl 反过来成了我的"实验记录本"——时间、模型、耗时、种子一目了然。写这份作业时，日志直接成了佐证材料。种子（seed）尤其重要：固定种子后，同样的提示词能复现同样的图，这让"对比实验"真正成立。

④ 环境不完美时，降级方案体现的是工程能力，而不是妥协。

直连不通、目标模型下架，这两件事都不在我控制范围内。但我可以把接口层抽象出来，让"换平台"只改一个参数——这恰恰是软件工程里"面向接口编程"的朴素价值。

⑤ 我最想改掉的一个习惯：不要一次性把参数调到底。

最初我直接用了"步数 50 + 引导强度 9"，结果出图慢、画面过饱和。后来才明白参数要小步调整、逐项验证——这跟写代码时"一次只改一个变量"是同一个道理。

---

六、GitHub 个人主页

按作业要求，我在 GitHub 上完成了个人主页建设，两种方案都做了：

方案	地址	做法
个人资料自述文件	https://github.com/zkk123-dd	新建与 GitHub ID 同名的仓库（zkk123-dd/zkk123-dd），在根目录 README.md 里撰写个人介绍
GitHub Pages	https://zkk123-dd.github.io/	另建 zkk123-dd.github.io 仓库，用纯手写 HTML/CSS 搭了展示更完整的站点

主页包含的内容（对应作业要求的三项）：

• 介绍自己：兴趣爱好（健身、摄影）、想分享的经历（见第五章 5.9 的跨平台技术选型过程）；
• 成果、技能与实践经历 + 自我评估：课程项目卡片、技能树（已掌握 → 在学中 → 仍欠缺）、"我会什么 / 我不会什么"对照；
• 未来三年发展规划：与本文第二章一致。

搭建过程遇到两个值得一提的问题：一是「同名仓库」和「GitHub Pages 用户页」其实是两个不同的仓库（前者显示在 github.com/用户名，后者在 用户名.github.io），我一开始混为一谈，导致 Pages 构建状态变成 errored；二是本机 Git 客户端的 TLS 证书校验过不去，最后改用 GitHub REST API 提交文件才推送成功。

---

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

本部分按要求：我选择 DeepSeek（网页版） 作为 AI 工具，让它生成一份简要的《软件工程课程学习指南》。以下是指南内容与分析。

7.1 AI 生成的指南原文（DeepSeek 输出摘录）

《软件工程课程学习指南》

一、课程定位

软件工程是一门研究"如何用工程化方法开发和维护软件"的学科。它不只讲编程，更关注过程、规范、协作和质量。学习目标不是"会写代码"，而是"能交付可维护的软件"。

二、知识框架（建议学习顺序）

1. 软件工程概述：软件危机、软件生命周期、过程模型（瀑布 / 迭代 / 敏捷）
2. 需求分析：需求获取、需求规格说明书（SRS）、用例图
3. 软件设计：概要设计与详细设计、模块化与高内聚低耦合、UML 类图与顺序图、设计模式
4. 编码实现：编码规范、代码审查、版本控制（Git 分支策略）
5. 软件测试：单元测试、集成测试、系统测试、黑盒与白盒、测试用例设计
6. 项目管理：进度估算、任务分解（WBS）、风险管理、配置管理
7. 综合实践：以小组为单位完成一个完整项目，走完需求 → 设计 → 编码 → 测试 → 交付

三、学习方法建议

• 理论联系实践：每学一个概念，就在自己的小项目里用一次（比如学了用例图，就给它画一张）。
• 重视文档：软件工程的核心产出物之一是文档，学会写需求说明书、设计文档和测试报告。
• 拥抱工具：熟练使用 Git/GitHub、UML 建模工具、测试框架、项目管理工具。
• 参与团队项目：软件工程的能力很大程度在协作中体现，主动承担具体模块并参与代码评审。
• 建立质量意识：写完代码先自测，养成写单元测试和 Code Review 的习惯。

四、常见误区

• 把软件工程当成"理论课"，只听不练；
• 认为"代码能跑就行"，忽视可维护性；
• 忽视文档和沟通，导致团队返工；
• 追求功能数量，忽视质量和测试。

五、时间投入建议

每周至少投入 6 小时：2 小时听课与阅读、3 小时动手实践、1 小时总结与文档写作。

7.2 我的分析：是否合理？能否带来帮助

① 我认为合理的部分（✅）

• 知识框架的顺序是对的：从需求 → 设计 → 编码 → 测试 → 交付，这就是软件开发生命周期的正确展开方式，和课程安排也基本一致。
• "理论联系实践"这条建议非常中肯：软件工程如果只听课不练，很难真正理解"为什么要写文档""为什么要做评审"。而这恰好是我过去的问题——拿到题目就写代码。
• "常见误区"部分击中了我的要害：特别是"认为代码能跑就行"这一条。我回头看自己的代码，确实存在注释随意、没有测试、结构杂乱的问题。
• 工具建议具体可执行：Git/GitHub、UML 工具、测试框架，这些都是能立刻上手的。

② 我认为需要调整的部分（⚠️）

• 缺少量化目标：指南建议"每周 6 小时"，但没有说明"学到什么程度算学会了"。我更喜欢用可量化的方式衡量——比如"能独立画出某个模块的类图""能为核心函数写出单元测试"。
• 没有区分个人项目与团队项目：软件工程最核心的价值在协作，但指南把两者混在一起讲。对现在的我来说，先参与一次真实的多人协作（分支 + PR + Review） 比再学一个设计模式更重要。
• 对"敏捷"只提了名字：实际课程作业中如果要用迭代方式推进，还需要更具体的操作建议（如看板、每日站会、迭代评审）。

③ 我认为它遗漏的内容（❌）

• 没有强调数据类项目的特殊实践（数据清洗、去重、增量同步、数据合规与频率控制）——这与我的专业方向直接相关，我需要自己补充；
• 没有提如何与课程评分标准对齐（作业要求里的截图、随笔、表格等交付格式）——这些细节 AI 看不到我的课程页面，只能靠我自己读课程材料；
• 没有提技术债的概念：什么时候该重构、什么时候可以先欠着。

结论：这份指南作为通用骨架非常合格，能帮我建立软件工程学习的整体地图；但它不了解我的课程安排和专业背景，所以我会把它当作 checklist 而不是教材，按上面的增删建议剪裁后使用。

真正能立刻行动的一条是：给现有项目建 Git 仓库、补上 README 和提交规范、为核心函数补最基础的测试。

通过这次使用 AI 制定学习指南，我也认识到：AI 更适合帮我们整理思路、生成框架、补充盲区，而不是代替自己的思考和判断。

---

八、总结与学习体会

通过本次软件工程系列作业，我对自己的专业能力与不足有了更清晰的认识。

以前我学编程时，比较关注"代码能不能运行"；通过软件工程课程的学习，我开始意识到一个真正的项目还需要考虑需求分析、系统设计、代码规范、版本管理、测试和维护。这几样以前我都跳过了，现在才明白它们是"让代码能被别人接手"的前提。

三次作业串起来，其实是一条完整的成长线：

作业	学到的东西	最大的收获
AI 图片生成系统	API 调用、前后端交互、Prompt 工程	第一次完整走通"前端 → 后端 → AI 模型 → 展示"的链路
博客园技术随笔	Markdown 写作、自我评估、技术表达	学会了清晰地把自己的思考写出来
GitHub 个人主页	账号注册、Profile README、GitHub Pages	开始把学习成果沉淀成可展示的东西

三点最深的体会：

1. "跑通"和"做好"之间差着很远。我的代码都能运行，但结构、注释、测试都不合格。这是我下一步最需要改的。
2. 环境问题往往比代码问题更耗时间——网络不通、证书报错、依赖冲突。但解决这些问题的过程，恰恰最能锻炼排查能力。这次我就用"绕过 Git 客户端、直接调 API"的方式解决了推送失败。
3. 把目标写下来，执行率会明显变高。为了写这份作业，我第一次认真梳理了自己的技能边界和三年规划，也第一次给自己的代码量定了数字目标。

接下来我会立刻做的三件事：

• 把所有课程项目整理进 GitHub，补上 README 和提交规范；
• 给核心函数补上最基础的单元测试，学会用 Git 分支做开发；
• 开始系统补算法与数据库，并着手搭建第一个大数据实验环境。

未来我希望继续加强计算机基础和软件工程实践能力，在学习人工智能与大数据相关知识的同时，也逐渐提高自己的工程能力，争取能独立完成更加完整、规范的软件项目。

---

九、附：后台博文编辑页面截图

本截图为博客园随笔后台 Markdown 编辑页面。本次作业全文采用 Markdown 语法编写，使用博客园自带的 Markdown 编辑器完成内容撰写与排版，截图用于证明作业是在 Markdown 编辑模式下完成，满足作业提交的格式要求。