文章总结： 本文基于复旦大学软件工程课程项目实践，探讨大模型时代软件工程的核心价值。通过分析ClaudeCode等AI工具在项目开发中的实际应用，总结出氛围编程、精确编程和启发式编程三种人机协作模式，并指出AI导致的代码复用性差、设计缺失等工程问题。文章提出坚持先设计后编码、配置统一Agent记忆、设置自动化质量检查等解决方案，强调专业工程师应通过架构设计和约束条件规范AI生成，用工程秩序对抗复杂性。 综合评分： 85 文章分类： 安全开发,AI安全,实战经验,安全建设,其他

AI时代软件工程的价值：学生视角的实践体验

CodeWisdom

2026年6月10日 18:34 上海

在小说阅读器读本章

去阅读

大模型时代软件工程的价值

基于软件工程（H）课程项目的实践与思考

吴嘉原 复旦大学计算与智能创新学院

近年来，大模型的能力突飞猛进，写代码似乎突然间变得门槛极低——只要输入自然语言，AI 就能迅速吐出成百上千行代码，写出来的程序又美观又好用。但事实果真如此吗？

在本学期彭鑫老师主讲的软件工程（H）课程实践项目中，我和另外 3 位同学组成了开发小组。我们在开发中深度使用了 Claude Code、Copilot、Cursor、Codex 等主流 AI 编程工具，并融合了部分“古法编程”的实践。 在经历了从设计、实现到测试、迭代的完整生命周期后，我们有了深刻的体会：AI 的发展并没有让软件工程成为历史。 任何工具的实际使用效果极大地受到使用者自身能力的影响。区别于非专业开发者，专业软件工程师懂得运用软件工程理论，通过充分的需求分析、良好的架构设计、成熟的编程规范、全面的软件测试，确保所构建的软件系统可靠、稳定、可持续。就目前 AI 的能力看来，这些效果是非专业开发者单纯依赖 AI 工具所无法取得的。 此外，随着系统复杂性的增加，单纯依赖 AI 会让项目逐渐脱离人的掌控，大大降低项目的可维护性。

AI 辅助软件开发的几种模式

在审视了团队成员与 AI 的对话记录后，我们总结了以下人机协作模式：

氛围编程 (Vibe Coding)

这是当前最“火”的 AI 辅助开发模式，根据人工介入程度不同，又可细分为三个子模式：

• 纯粹氛围编程 (Pure Vibe Coding)：用户仅提出模糊的功能需求，将设计、编码、基础测试全权委托给 AI，仅以“代码是否实现预期功能”作为唯一验收标准，可能有简单但不充分的代码质量检查。

Prompt

请实现团队模块的成员系统，要求支持成员管理。

纯粹氛围编程 (Pure Vibe Coding) 示例 Prompt

• 监督式氛围编程 (Supervised Vibe Coding)： 在 Pure Vibe Coding 的基础上，增强人工监督，一旦发现 AI 迭代方向偏离预期，立即打断并干预。在 AI 迭代完成后，加强对交付物的审查。

• 约束式氛围编程 (Vibe Coding with Constraints)： 在 Pure Vibe Coding 的基础上，在 Prompt 中内置详细的工程要求，作为对 AI 迭代过程的约束。

Prompt

请实现团队模块的成员系统，要求支持成员管理，要求如下：

1. 权限模型使用 RBAC，角色、权限点必须用数据库实体管理。
2. 接口遵循 docs/lab3/API_REFACTOR.md 中已定义的契约，路径与字段名保持一致。
3. 数据库变更必须通过 Flyway migration 提交，禁止直接改动既有表结构。
4. Controller 层只做参数校验与响应封装，业务逻辑下沉到 Service，Service 层采用接口 + impl 的结构。
5. …（更多约束）

约束式氛围编程 (Vibe Coding with Constraints) 示例 Prompt

精确编程 (Accurate Coding)

用户提出原子的需求，需求没有模糊地带，让 AI 进行小规模编辑，涉及文件数量少，编辑正确率高。

Prompt

Prompt 请在此页面的左上角增加 Element Plus 按钮，使用 primary 样式。

精确编程 (Accurate Coding) 示例 Prompt

启发式编程 (Inspired Coding)

启发式编程（Inspired Coding）的核心目标不在于获取最终形态的生产代码，而在于利用大模型极高的生成速度，为技术设计提供灵感。 在此模式下，用户提出模糊的需求，没有明确的实现方案，让 AI 迭代生成一个 Demo，随后根据此 Demo 理清思路，推翻或部分推翻此 Demo，重新设计并实现，工作流见下图：

图1：Inspired Coding 工作流

大模型引入的工程问题

在享受了开发初期的效率红利后，随着系统复杂度的提高，大模型“非工程化”的特性给项目带来了诸多技术问题：

1. 代码复用性差：大模型在生成代码时，缺乏全局视角，在不配置 memory、rule 的前提下，往往无法主动复用系统已有的全局导入、通用工具类等，导致项目中出现大量代码克隆。

2. 上下文记忆丢失：在不同的会话之间或较长的上下文窗口下，AI 会丢失记忆，导致此前代码检视中反复强调过的问题重复出现。

3. 缺乏设计性和可扩展性：这一问题在“纯粹氛围编程（Pure Vibe Coding）”模式下尤为严重。AI 为了快速跑通当前功能，倾向于选择最快捷的解决方案，极易引入硬编码等问题。以下是我们在代码检视阶段拦截的一例由 AI 自主生成的代码：

AI 自动生成的 RBAC 权限设计

客观来说，该设计确实能起到鉴权功能，却使得权限系统在运行时失去了动态扩展能力，用户若要加入新的角色，就必须直接修改代码。

4. 编码惯性思维：模型在处理特定业务逻辑时，往往会陷入其训练数据所带来的惯性思维和刻板套路中，难以根据本项目的特定技术栈约束（如特定的依赖版本或私有框架组件）进行灵活变通。

5. 无法证明生成的测试的正确性：虽然 AI 可以依据业务代码快速自动吐出单元测试，但人类开发者很难在逻辑上证明这些自动生成的测试用例本身是否完整、正确，甚至面临 AI 针对测试断言进行“作弊”的风险。

6. 开发者身份错位（Who is the real Agent?）： 这是一个极具讽刺意味的问题。在代码持续迭代的过程中，一旦生成的代码未通过检视，原始开发者往往因无法掌控庞大的生成代码，反向沦为了“传话者”——机械地在 Reviewer 与 AI 之间搬运、转述检视意见，无法独立完成代码修改。

图 2: 人沦为 AI 反馈回路中的传话工具

如何解决AI带来的挑战

解决 AI 带来的问题，核心策略不在于一刀切的排斥 AI，而是克制的、有监督的使用，以下是我们团队在实践中总结出的几条经验：

1.坚持先设计、后编码的策略：大模型在处理单点功能实现时非常高效，但它完全无法预料到未来的潜在需求演进，这种局限性导致它对增量开发极其不友好。如果前期缺乏人类的架构规划，后续的迭代很可能会引入大量技术债，甚至导致系统崩溃。

2. 集中配置团队统一的 Agent 记忆 (Memory)：针对跨会话记忆丢失、检视意见在不同对话中反复出现的严重问题，我们创建了统一的.agent 目录，将项目的架构文档、开发流程规范写入 AI 记忆，强迫大模型在迭代时遵循已有的规范。

3. 设置自动化质量检查流水线（CI）：对于静态代码问题，如未使用的冗余导入、已经失效的死代码、不符合规范的命名冲突，以及大模型由于缺乏全局感知引入的代码克隆，我们可以在 CI 流水线中嵌入自动化的静态代码扫描工具，提高代码检视效率和准确率。

需注意，AI 为了通过流水线极易产生针对测试用例“打表作弊”的现象，针对这一问题目前尚无完全非人工的解决方案，我们的解决方案是完善测试用例的设计，尽量避免出现可以钻空子的漏洞。

4. 明确人机协作的边界：见下一节。

我们对于 AI 辅助软件开发的思考

结合整个项目的实践过程，我们对大模型时代下的人机协同的边界以及开发范式进行了以下客观梳理：

4.1 适合使用氛围编程 (Vibe Coding) 的场景

尽管氛围编程存在风险，但在以下特定场景中，它依然能展现出生产力优势：

• 对技术栈不熟悉时：当开发者本身对当前项目的特定技术栈不是很熟悉时，Vibe Coding 能够越过繁琐的语法学习，快速搭建起一个达到“可运行状态”的基础脚

手架。

• 获取初期设计灵感：在架构设计的迷茫期，希望大模型提供启发时，通过大颗粒度的需求抛出，可以快速人类开发者开拓思路。

• 对系统可扩展性和鲁棒性要求不高时：对于一次性验证的临时 Demo、极短生命周期的辅助脚本或不需要后续维护的玩具项目，代码不需要经历长期的需求演进。此时， Vibe Coding 快速生成的效率优势能够被最大化，而其引入的缺陷并不会带来实质性的危害。

4.2 大模型时代下软件开发的最佳实践

• 设计阶段（人类主导）：需求的解构、软件架构的设计必须由人主导。在此阶段，可以适当使用启发式编程（Inspired Coding）获取原型灵感，但最终决定权归人所有。

• 实现阶段（人机协同）： 在实际编码过程中，推荐采用监督式氛围编程（Supervised Vibe Coding）与精确编程（Accurate Coding）相组合的方式，确保代码处于受控状态。

• 测试阶段（人工掌控）：自动化检查会面临投机风险，因此测试用例必须由人工主导制定，绝不能全部交给 AI 自我测试。

结语：不被 Vibe Coding 的表象迷惑

在人机协同开发的过程中，我们常常会陷入一种“Vibe Coding 极为高效”的幻觉。但我们之所以觉得大模型 Vibe 出来的代码又美观又好用，往往是因为缺乏对底层代码库的审查，只被其在极小样本下跑通的功能表象所迷惑。非专业开发者极易在系统初期的快速交付中迷失，而专业软件工程师明白，浮于水面之上的“功能跑通”往往只是冰山一角。

软件工程课程让我们深刻意识到：软件工程的价值在于高屋建瓴的设计，而非机械的代码实现。在大模型时代，“把代码写出来”的门槛和边际成本已经被极大地拉低，单纯的编码实现已经不再是核心壁垒。一个系统的生命力，并不取决于 AI 在几秒钟内吐出了多少行代码，而取决于最初的架构设计是否合理、技术栈选型是否理性、接口契约是否严密。专业工程师的核心价值，正是通过迭代式设计来框定核心功能的边界，用明确的约束条件去规范 AI 的随意生成，并用人工主导的严密测试用例去穿透功能表象、消除隐蔽的技术债。工程的本质，永远在于用极致的秩序去对抗现实世界的随机性与复杂性。

个人简介

吴嘉原，复旦大学计算与智能创新学院软件工程大二本科生，专注于大模型时代软件开发过程中人机协同范式的探索。

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：CodeWisdom 《AI时代软件工程的价值：学生视角的实践体验》