102300433袁昊软件工程实践总结——AI时代：可替代与不可替代

[102300433袁昊]

项目信息项	内容说明
这个作业属于哪个课程	202501福大-软件工程实践-W班
这个作业的要求在哪里	软件工程实践总结&个人技术博客
这个作业的目标	总结RBAC模型在冰鉴InsightNews中的应用
其他参考文献	《构建之法（第三版）》

---

目录

• 第一部分：课程回顾与总结
• 1. 曾深入思考的问题与解答
• 1.1 问题：如何构建一个真正稳定、高效、可扩展的生产级系统？
• 2. 五大阶段的收获
• 3. 项目理解与心得
• 4. 课程目标掌握程度评价
• 第二部分：个人技术总结
• 1. 个人总结
• 2. 技术博客链接与概述
• 第三部分：软件开发模式
• 1. 项目概述：InsightNews 后端与架构
• 2. 开发模式思考

---

第一部分：课程回顾与总结

1. 曾深入思考的问题与解答

1.1 问题：如何构建一个真正稳定、高效、可扩展的生产级系统？

• 最初的困惑：
  在学期初，我对“生产级”系统的理解仅停留在功能实现上。我认为只要代码跑得通、功能齐全就是好系统。对于高并发下的稳定性、系统的可扩展性以及如何将 AI 能力工程化（MLSys）感到迷茫，不知道理论与实践的鸿沟该如何填补。
• 理解过程：
  在“冰鉴 InsightNews”的开发中，我作为后端负责人，不得不面对多模态检测带来的性能挑战。
• 遇到的坑： 最初我们将 AI 检测逻辑直接嵌入 Web 主线程，导致请求响应时间过长，甚至阻塞了其他用户的操作。
• 解决思路： 被迫引入异步任务架构，利用消息队列将 AI 服务与 Web 服务解耦；引入 Redis 缓存热点数据；设计 RBAC 模型来规范权限。
• 思维转变： 我逐渐意识到，代码只是逻辑的载体，架构才是系统的骨架。生产级系统是由无数个“权衡（Trade-off）”堆出来的，是在一致性与可用性、成本与性能之间寻找最优解。

• 现在的认识：
  现在我明白，生产级系统 = 高内聚低耦合的架构 + 可观测性（日志/监控） + 自动化保障（测试/CI）。一个成熟的后端不仅要会写 CRUD，更要懂得如何设计异步流程来削峰填谷，如何利用缓存策略提升吞吐量。AI 能力的落地也不仅仅是调用 API，更是对模型服务的治理与质量监控。

2. 五大阶段的收获

阶段	收获
需求阶段	学会了做减法。利用 NABCD 模型分析发现，用户需要的不仅是“真伪检测工具”，更是“交流社区”。我们砍掉了花哨的边缘功能，聚焦于“检测+科普+社区”的闭环，明白了需求必须服务于核心价值。
设计阶段	深刻体会到接口文档先行的重要性。在前后端分离开发中，Swagger/OpenAPI 文档就是我们的“契约”。清晰的接口定义（入参、出参、错误码）极大地降低了沟通成本，避免了推倒重来。
实现阶段	掌握了关注点分离的设计美学。通过 AOP 实现权限控制，通过 Redis 实现缓存加速，将业务逻辑与基础设施代码解耦，让核心代码保持纯净和可维护性。
测试阶段	从“人工点点点”进化到自动化测试思维。在 AI 评测作业中，编写自动化脚本让模型互评；在后端开发中，坚持写单元测试。明白了测试不仅是找 Bug，更是对系统质量的量化评估。
发布阶段	体验了容器化部署的红利。Docker 让环境配置实现了标准化，解决了“在我机器上能跑”的玄学问题，保证了从开发环境到生产环境的一致性。

3. 项目理解与心得

在“冰鉴 InsightNews”项目中，作为组长（PM）兼后端架构师，我最大的体会是：技术决定下限，协作决定上限。

在此之前，我更习惯“单打独斗”，迷信个人的编码速度。但在这个项目中，面对多模态融合、三端（Android/Web/Backend）联调的复杂场景，个人的力量微不足道。我学会了制定Git Flow规范来管理代码，利用飞书异步站会来同步进度。

更重要的是，我意识到程序员的终极形态是“解决问题的人”。AI 可以帮我们生成代码片段，但无法帮我们做工程决策（比如选 Redis 还是 RabbitMQ）。未来的核心竞争力在于架构思维——即在有限资源下，通过技术选型和系统设计，构建出最符合业务需求的解决方案。

4. 课程目标掌握程度评价

目标	分值	说明
目标1	95分	在爬虫与 AI 使用中严格遵守了数据隐私规范和开源协议，具备良好的职业道德。
目标2	90分	熟练运用 NABCD 模型，从用户痛点出发产出了高质量的需求规格说明书。
目标3	92分	完成了标准的三层架构设计、ER 图及类图，实践了模块化设计思想。
目标4	95分	深入实践了敏捷开发、代码规范（Checkstyle）及版本控制（Git Flow）。
目标5	88分	团队协作紧密，作为 PM 有效推动了项目进度，但初期分工粒度还可以更细。
目标6	90分	文档编写能力提升明显，API 文档和架构文档成为团队协作的基石。
目标7	89分	能够有效管理代码版本，但在项目风险（如 AI 接口不稳定）的预案上略显不足。

---

第二部分：个人技术总结

1. 个人总结

本学期我完成了从“Java 学习者”到“后端开发者”的身份转变。
我不再满足于写简单的 Controller，而是开始关注高并发、高可用的技术栈。在项目中，我系统性地实践了 Spring Boot 生态，深入使用了 MyBatis-Plus 进行数据持久化，引入 Redis 解决性能瓶颈，并利用 Netty 思想理解异步通信。同时，通过大模型评测作业，我也初步窥探了 MLSys（机器学习系统）的门径，掌握了自动化评估大模型能力的脚本编写技巧。

2. 技术博客链接与概述

• 博客链接： 个人技术博客：基于 Spring AOP 与自定义注解实现 RBAC 动态权限控制
• 技术概述：
  在企业级应用中，权限管理是核心安全防线。本项目采用 RBAC（Role-Based Access Control） 模型，通过 Spring AOP 切面编程和 自定义注解 (@AuthCheck)，实现了权限校验逻辑与业务代码的完全解耦。同时，结合 Redis 缓存用户角色信息，解决了传统鉴权频繁查库导致的性能瓶颈，大幅降低鉴权耗时。

---

第三部分：软件开发模式

1. 项目概述：InsightNews 后端与架构

• 项目简介： “冰鉴 InsightNews”是一个集多模态新闻真伪检测、科普教育、社区互动于一体的综合平台。
• 我的职责： 担任 PM 及后端负责人，主导系统架构设计、API 开发及数据库设计。
• 技术栈：
• 后端核心： Java, Spring Boot, MyBatis-Plus
• 中间件： Redis (缓存/会话), MySQL (持久化)
• 架构设计： RBAC 权限模型, AOP 切面, 异步任务处理
• 工具链： Git, Docker, Swagger, Lark

• 关键决策：
• 异步解耦： 针对耗时的 AI 检测服务，不采用同步等待，而是设计了“提交-轮询/通知”的异步流程，保证了 Web 服务的吞吐量。
• 契约优先： 强制要求后端先出 API 文档（Swagger），前端再开发，杜绝了“猜参数”的低效协作。

• 挑战及解决方案：
• 挑战： 鉴权逻辑复杂，代码侵入性高。
• 解决： 引入 AOP 切面，将鉴权逻辑统一封装，业务方法只需加注解即可。
• 挑战： 多人协作代码冲突频繁。
• 解决： 严格执行 Git Flow，功能开发在 feature 分支，合并前必须 Pull Request 并通过 Review。

2. 开发模式思考

在团队中，我们采用的是 敏捷开发（Scrum） 的改良版。

• 我们的模式：
• 短周期迭代： 以两周为一个 Sprint，每个周期都有明确的可交付成果（如“完成鉴权模块”、“打通检测流程”）。
• 异步站会： 线下站会 + 飞书群内每日异步同步“进度、计划、困难”，更适合学生团队碎片化的时间。
• 看板管理： 利用飞书多维表格管理 Backlog，任务状态流转可视化。

• 优缺点分析：
• 优点： 响应变化极快。例如在发现“用例图过于复杂”的反馈后，我们迅速在下一个 Sprint 调整了架构设计，而非死守原有文档。
• 缺点： 在快速迭代中，文档维护有时会滞后于代码变更，导致短暂的信息不同步。

• 对比思考：
  相比于瀑布模型，敏捷模式更适合我们这种探索型项目。因为 AI 技术的不确定性很高，需求往往随着我们对模型能力的理解而变化（例如从单一文本检测扩展到多模态）。如果采用瀑布模型，可能在设计阶段就会卡死。
• 关于 AI 的反思：
  虽然我们使用了 AI 辅助编码，但我深刻体会到 AI 无法取代工程考量。AI 可以生成一段优美的代码，但无法告诉我在工期紧张时，应该选择“简单的单体架构”还是“完美的微服务架构”。工程的本质是约束条件下的最优解，这是人类架构师不可替代的价值。