AI时代软件工程的双轨变奏:SDLC与ADLC的融合,以及多模态LLM下的人机协作新范式

title: “AI时代软件工程的双轨变奏：SDLC与ADLC的融合，以及多模态LLM下的人机协作新范式”
author: “侘寂深圳人”
tags: [AI, 软件工程, SDLC, ADLC, 多模态LLM]
summary: “当传统软件开发生命周期遇见AI Agent开发范式，多模态LLM正在重塑每一个开发者的日常工作。这不是替代，而是融合——人机协作的软件工程3.0正在到来。”

上图：SDLC（左侧线性流程）与ADLC（右侧循环结构）的对比与融合趋势。图片来源：baoyu-imagine / Seedream。

软件工程正在经历一场静悄悄的革命。

过去三十年，我们谈论软件工程，几乎等同于SDLC（Software Development Lifecycle）——需求、设计、开发、测试、部署、维护，这条线性链条定义了整个行业的生产方式。

但今天，一个新的框架正在崛起。ADLC（Agent Development Lifecycle）——目标定义、Agent设计、提示词与工作流设计、工具集成、记忆、评估、护栏、部署、可观测性——这九个环节构成了AI Agent开发的新范式。

这不是一个替代另一个的故事。这是两条轨道如何交织、碰撞、最终融合的故事。

一、SDLC：从未消亡，但边界在模糊

SDLC的根基在于可预测性和可维护性。GitHub、Stripe、Notion、Slack——这些产品的每一行代码都诞生于SDLC的流水线上，需求文档、设计评审、代码审查、自动化测试、灰度发布，每一道工序都有章可循。

但SDLC有一个隐含假设：开发者对代码有完全的控制力。你写下的每一行代码，它的行为是可预期的。bug是可以复现的。回归测试是可靠的。

这个假设正在被打破。

当你的代码里嵌入了LLM调用——一个openai.chat.completions.create()——你就不再拥有对行为的完全控制权。同一个prompt，两次运行可能给出不同的结果。一个微小的措辞调整，可能改写了整个输出的质量。

传统SDLC无法回答一个问题：当你的软件里有一部分”不可预测”时，你如何保证可靠性？

这就引出了ADLC存在的理由。

二、ADLC：AI Agent的新工程框架

ADLC不是SDLC的替代品，而是对SDLC无法覆盖的部分的补充。

看ADLC的九个环节：

• 目标定义：Agent要完成什么任务？这个”目标”和SDLC的”需求”最大的区别在于——需求是精确的、可量化的、无歧义的；而目标的表达本身就是模糊的，”帮我管理日程”和”帮我订披萨”的抽象层级完全不同。
• Agent设计：你需要什么样的Agent架构？单Agent还是多Agent协作？ReAct还是Plan-and-Execute？
• 提示词与工作流设计：这是ADLC中最像”编程”的环节，但编程对象不是机器指令，而是自然语言界面。
• 工具集成：Agent需要调用哪些API、访问哪些数据库、读取哪些文件？
• 记忆：短期上下文窗口 vs 长期向量存储。Agent如何记住用户偏好？
• 评估：不是传统意义上的单元测试。你需要评估的是Agent的推理质量、工具调用准确性、目标达成率。
• 护栏：Agent不能做什么？如何在保证灵活性的同时设定安全边界？
• 部署：API端点、流式响应、长时任务的后台执行。
• 可观测性：Agent的推理路径是什么？它在哪一步做了错误的决策？

这些环节在传统SDLC中没有对应的概念。ADLC的出现不是因为有人发明了新流程，而是因为AI Agent的工程挑战本质上不同了。

Devin、Claude Code、Manus、Bug0、OpenAI Operator——这些产品每一个都在重新定义ADLC的实践。

但这里有一个更深层的问题：如果只有ADLC，我们依然无法回答”可靠软件如何构建”这一根本问题。

答案不在SDLC或ADLC中，而在它们的交叉点。

三、多模态LLM：撬动人机协作的关键变量

多模态LLM的出现，让软件工程的范式转变有了实质性的技术基础。它不仅改变了代码怎么写，更改变了谁在写、怎么写、用什么写。

视觉理解：从”看界面”到”生成代码”

传统的工作流是：设计师出设计稿 → 前端工程师看着设计稿写HTML/CSS/JS。这个链条中，设计意图在传递过程中必然会损失——设计师的”这里留白多一点”和工程师理解的”padding: 16px”之间永远有落差。

多模态LLM改变了这一点。一个截图 + 一句描述 → 代码输出。Figma设计稿直接导出为React组件已经成为现实。

更关键的是逆向能力：代码 → 视觉呈现的推理。开发者在PR review时，可以将代码变更截图发给LLM，获取UI变化的自然语言描述。这种”视觉-代码”的双向映射，正在模糊”设计师”和”开发者”之间的分界线。

语音交互：从”打字”到”对话”

VSCode中的语音编码插件、Cursor中的自然语言编辑——这些工具正在把一个原本需要”思考 → 打字 → 调试”的过程简化为”说出你想做什么”。

这不是简单的”解放双手”，而是改变了编程的认知模型。当你不在需要想着变量命名、语法结构、接口签名——当你只需要描述意图——你思考问题的方式就会从”如何实现”转向”想要什么结果”。

这对资深开发者意味着更高效的原型开发，对新手开发者意味着更低的入门门槛。

代码库级上下文理解：从”文件”到”系统”

SDLC中，工程师花费大量时间做的一件事是：阅读别人的代码，理解系统行为，找出修改的安全边界。

多模态LLM通过大上下文窗口（Claude的200K、Gemini的1M+ token）改变了这一局面。你可以把整个代码库的索引作为Agent的上下文，让它理解模块之间的依赖关系、数据流的走向、API契约的边界。

这意味着一个Agent可以像一个经验丰富的工程师一样，在修改一个函数时意识到它对五个模块的影响。 这不是代码补全的级别——这是系统级理解。

人机配合的新分工

但这不意味着AI将取代开发者。

看看历史规律：每一次工具革命，都伴随着分工的重新定义，而非岗位的消失。

• 汇编语言 → 高级语言：关注点从”管理内存”转移到”设计架构”
• 手动测试 → 自动化测试：关注点从”重复验证”转移到”测试策略”
• 单体架构 → 微服务：关注点从”应用内部”转移到”系统边界”
• SDLC → SDLC + ADLC：关注点从”写代码”转移到“指导AI写代码”

多模态LLM加持下的人机协作，形成了一个全新的分工图谱：

人类做的是”指导”和”判断”——AI做的是”执行”和”建议”。

四、SDLC × ADLC：融合的新工程范式

SDLC和ADLC不是你死我活的关系。它们是在不同抽象层级上解决问题的互补框架。

未来的软件工程，应该是这样的：

在宏观层面，遵循SDLC的节奏。
项目依然需要需求定义、架构设计、发布计划、质量门禁。这些工程管理的刚性需求不会消失——实际上，当代码生成变得更快更廉价时，架构评审和需求确认反而变得更加关键。

在微观层面，遵循ADLC的方法论。
每个功能模块的开发，不再是从零写代码，而是：定义目标 → 设计Agent工作流 → 迭代prompt → 评估输出质量 → 设置护栏 → 部署可观测。开发者变成一个”Agent教练”。

在多模态LLM的支持下，这两个层面之间有了实时的翻译层。
架构文档可以用自然语言描述，Agent将其转化为实现代码。UI设计稿直接导出发送端组件。代码变更自动生成影响分析报告。SDLC的”文档驱动”和ADLC的”交互驱动”之间的鸿沟，正在被多模态能力填平。

五、尾声：工程的新定义

当代码越来越像”一种AI能理解和生成的语言”时，软件工程是什么？

我的答案是：软件工程依然是管理复杂度、保证可靠性的学科。但管理的手段正在从”精确的指令”变成”明确的意图”。

你不需要告诉AI每一行的写法——你只需要告诉它你要什么、检查它给的结果、并在它跑偏时纠正方向。

这听起来很像在管理一个初级工程师。

——这不正是工程管理的终极形态吗？每一个开发者都有一个永不疲倦的实习生，而开发者的价值体现在判断力、系统思维、创造力这些AI暂时无法替代的能力上。

SDLC和ADLC不是选择题，是组合题。懂SDLC让你建得稳，懂ADLC让你建得快。两个都懂，你才能在AI时代不仅活着，还领先。

基于对SDLC与ADLC双轨范式的观察，结合多模态LLM技术趋势，探讨AI时代软件工程的新方向。