我的知识库

Appearance

🚀 第1讲：拥抱 AI，重塑软件工程思维 ​

📌 【学习目标】

  1. 理解软件工程的基本概念与“软件危机”的演变。
  2. 转变开发思维：认识 AI 辅助编程的边界，学会用工程化规范去指导和约束 AI，而非完全依赖。
  3. 掌握 问题定义 的规范化要求与结构化提示词（Prompt）的编写方法。
  4. 熟悉本学期实战项目的业务背景，并初步学会在 Trae 中运用业务边界定义生成项目骨架。

1. 重新定位：AI 时代的“软件工程” ​

在正式步入本学期的实战之前，我们需要探讨一下当前软件开发模式的变革。对于我们专业的同学来说，这门课的学习方法将直接决定你们未来毕业设计（无论是本科还是专科水平）的质量，以及步入职场后的核心竞争力。

过去，大家将大量时间投入在基础语法的记忆和重复性代码的编写上。如今，借助 Trae 等 AI 编程 IDE，代码产出的速度得到了极大的提升。但这并不意味着传统的编程能力不再重要，更不意味着 AI 可以完全替代开发者。

1.1 真正的“软件危机”与 AI 的局限性 ​

在早期的软件发展阶段，行业爆发了传统的“软件危机”，表现为：成本高昂、进度失控、维护困难等。

引入 AI 工具后，如果我们放弃了软件工程的规范，盲目让 AI 生成代码，反而会引发新的“现代软件危机”：

  • 缺乏全局架构：AI 擅长编写单点功能（如某一个接口、某一个 Vue 组件的样式），但如果缺乏架构师的统筹，生成的代码往往耦合严重，难以扩展。
  • 业务逻辑黑盒：如果不加审查地拼接 AI 生成的代码片段，系统犹如“屎山”，一旦出现 Bug，开发者将无从下手排查。
  • 安全性缺失：AI 为了快速实现功能，往往会忽略复杂的边界条件和安全鉴权机制。

1.2 软工理论的全新价值 ​

软件工程的核心思想是：“用工程化原则来开发软件”。在 AI 时代，这一原则不仅不过时，反而变得前所未有的重要。

🖥️ 传统开发与 AI 辅助开发流程对比

在这个新流程中，软件工程的三要素（方法、工具和过程）被赋予了新的意义：

  • 数据字典与数据流图不再是单纯的期末作业，而是喂给 AI 最精准的上下文提示。
  • 你的身份必须从底层的 代码搬运工 升级为掌控全局的 系统架构师与代码审查员。

2. 实战项目引入与“灾难现场”演示 ​

本学期，我们将全程围绕一个真实且贴近校园生活的综合性项目——“校园综合商城与二手交易平台” 展开实战。掌握这个项目的全流程，你们不仅能顺利完成课程，还能直接为未来的毕业设计打下极其坚实的基础。

2.1 项目背景与核心业务模块拆解 ​

该项目旨在解决高校内部的物品流通问题，业务逻辑兼顾了电商的标准流程与校园社交的特殊性。

🖥️ 校园综合交易平台模块拓扑图

  • B2C 校园商城模块 标准化业务：适合训练严谨的事务处理和状态机流转。
  • C2C 二手闲置模块 非标交互：适合训练信息检索、防错设计与边界权限控制。
  • 平台后台管理系统 核心基座：一切业务流的终点，考验底层数据库关系设计。

2.2 演示：失去工程约束的 AI 对话 ​

为了直观感受需求分析的重要性，我们将演示一段缺乏软件工程思维的小白式 AI 对话。

假设我们直接打开 Trae，在左侧的 Chat 面板中输入以下模糊的指令：

❌ 反面教材（无效提示词）： “Trae，帮我用 Vue 和 Spring Boot 写一个校园二手交易平台，包含学生发布商品、浏览列表的功能，还有管理员后台。”

点击 Enter 后，Trae 会迅速生成前后端代码。但作为架构师进行代码走查时，你会发现严重的工程灾难：

  1. 数据关系断裂：AI 可能会把商品发布者的信息直接存为纯文本字段，而不是通过 user_id 关联用户表，导致完全无法查询“某个用户发布的所有商品”。
  2. 缺乏业务规则：商品发布接口没有对上传图片的格式和大小做任何限制，服务器极易被恶意文件撑爆。
  3. 功能过度发散：由于没有明确是“线下当面交易”，AI 擅自引入了一套极其复杂的在线支付回调和物流追踪依赖，导致项目结构极其臃肿，本地根本无法运行。

💡 【核心反思】

AI 具有极强的发散性。如果没有严谨的 问题定义，它生成的只是猜测出来的“样板代码”。必须明确告诉 AI：系统做什么，坚决不做什么。

2.3 互动体验：让 AI 成为你的软工导师 ​

在看完反面教材后，现在轮到大家亲自上手。不要急于让 Trae 帮你写页面，我们要发挥主观能动性——把 AI 当作你的 软件工程导师。

在面对一个庞大且未知的项目时，我们可以用探索型提示词，让 AI 帮我们梳理宏观的建设步骤。请大家在左侧 Chat 面板中，尝试输入以下指令：

✅ 启发式探索指令（请同学们跟随操作）：

“Trae，我希望开发一款‘校园综合商城与二手交易平台’。如果按照软件工程设计的思路，完整的开发流程应该是什么样的？ 注意：请先不要写任何代码，我的主要目的是学习软件工程的各种方法，你必须先和我讲清标准阶段和流程。”

按下 Enter 发送后，仔细阅读 AI 的答复。它会清晰地为你梳理出：问题定义、需求分析、系统设计、编码实现与软件测试等标准的软件生命周期阶段。

📌 【学习方法论】

这种“只聊需求和流程、拒绝生成代码”的沟通方式，是我们把控 AI 的第一步。针对 AI 给出的流程，大家可以继续追问。例如：“在‘结构化需求分析’阶段，我应该画哪些图？请结合我的二手交易模块给我举个具体例子。”

3. 降伏 AI：运用“问题定义”立规矩 ​

如何利用 AI 高效生成符合业务预期的初始工程？我们需要运用第2章的核心知识点：问题定义。

规范的问题定义必须明确系统的目标、规模、初步设想与边界约束。我们将这些内容转化为结构化的指令发给 Trae。

3.1 结构化 Prompt 模板构建 ​

在 Trae 中，我们重新组织语言，采用 “角色设定 + 核心目标 + 边界约束 + 技术规范” 的四步走框架，下达一条高级指令：

✅ 最佳实践（高级架构师指令）：

“Trae，你现在扮演高级架构师。我们将从零搭建‘校园综合商城与二手交易平台’。

1. 核心目标与业务拆分： 系统分为三个子系统：面向学生的移动端 H5（用于二手发布与浏览）、面向商家的 PC 端商城（含购物车订单流转）、面向管理员的 Web 后台（审核与管控）。

2. 当前阶段任务与边界： 本次对话仅聚焦于C2C 二手闲置模块的第一期建设。包含：基于 Token 的用户鉴权、图文商品发布（需限制最大上传 5 张图）、商品列表分页查询。明确排除在线支付功能，交易采用留言与线下撮合。

3. 技术栈与规范约束：

  • 前端：采用 Vue 3 + Vite 架构。
  • 后端：采用 Spring Boot 前后端分离架构，严格遵守 RESTful 接口设计，数据交互统一返回标准 JSON 封装格式（必须包含 code, message, data 字段）。

执行要求：请根据以上定义，为我输出该项目后端服务的 Markdown 格式技术架构说明与核心目录树。注意：当前仅需输出宏观规划，绝不要生成具体的业务逻辑代码。”

3.2 审查高质量输出与流程机制 ​

执行上述指令后，AI 的输出质量将发生质变。它会严格遵循 MVC 分层架构为你设计包结构（如 controller、service、mapper、entity），并且主动规避了冗余的支付依赖包。

🖥️ 架构师与 AI 交互生命周期

4. 随堂实操：团队组建与问题定义演练 ​

理论必须结合实践。接下来我们将进入第一次随堂演练，尝试用结构化的工程思维与 AI 进行深度沟通。

4.1 敏捷团队组建与分工 ​

  • 规模：全班分为若干小组，每组 3-4 人。
  • 协作方式：
    • 1名 项目经理（PM）：负责控制时间节奏，记录 AI 输出的关键有效信息。
    • 2-3名 需求分析师/架构师：负责讨论业务逻辑，梳理边界条件，撰写并优化提示词。

4.2 随堂任务：定义“后台审核模块”的边界 ​

请各小组打开 Trae，点击左侧面板上方的 + 号新建一个纯净的对话窗口（避免上下文污染）。针对实战项目中的 “平台后台管理系统 - 违规商品与用户审核模块”，完成以下实战任务：

操作步骤：

  1. 组内头脑风暴（5分钟）： 明确该模块的业务逻辑。思考：审核员的权限能大到什么程度？审核不通过时，系统需要触发什么后续动作？
  2. 撰写问题定义 Prompt（10分钟）： 在 Trae 的输入框中编写指令，你的提示词必须包含以下工程约束：
    • 权限边界：例如明确规定“审核员不能物理删除数据库记录，只能将商品状态字段 status 置为下架”。
    • 状态机流转：清晰描述商品从“待审核 -> 审核通过 / 审核驳回并系统站内信通知”的完整流转过程。
    • 输出要求：要求 AI 输出“该模块的初步接口设计清单”及“业务流程梳理”，禁止直接写代码。
  3. 发送与复盘（10分钟）： 按下 Enter 获取 AI 的回复。组内审查 AI 给出的接口清单是否涵盖了你们设定的所有状态和约束。
📖 【考核与评价标准】

本次随堂练习不以“谁生成的代码多”为评判标准。老师将检查各组提交的 Prompt 文本：

  1. 边界限制越清晰（知道系统不做什么），得分越高。
  2. 业务流程考虑越周全（如考虑到异常状态的流转），得分越高。
  3. 成功约束 AI 没有提前生成废话代码，说明你已经初步掌握了驾驭 AI 的方法。