人机融合式软件开发系列 · 1 / 6
范式迁移 + AI-DLC + 3 种协作模式
软件工程正从"自动化"迈向"智能化 + 人机共生"——AI（Artificial Intelligence，人工智能）不再是附加工具，而是贯穿全生命周期的协作主体。 本页讲透 3 件事：范式本质（不是"AI 替代人"，是"AI 执行 + 人治理"）/ AI-DLC 4 大原则（重新构想 + 逆转对话 + 模糊阶段 + 必有人监督）/ 3 种可切换协作模式（Driver-Navigator / Review-First / Specialist）。
概览
1
范式迁移
4
AI-DLC 原则
3
协作模式
988
LLM4SE 综述论文
本系列 6 页速查
| # | 页 | 主题 |
|---|---|---|
| 1 | paradigm | 范式迁移 + AI-DLC + 3 种协作模式（本页） |
| 2 | requirements | 需求工程：4 类用例 + 质量评估 + 3 挑战 |
| 3 | design | 分析与设计：AKM + 组件生成 + ADD 引导 |
| 4 | implementation | 实现：3 层形态 + PDD + 5 数据点 |
| 5 | testing | 测试：Test Pyramid 2.0 + Agent 测试价值悖论 |
| 6 | maintenance | 维护 + 治理：APR + 新债型 + 责任框架 |
第一篇 · 范式迁移与协作模型
第 1 讲 · 1 范式 + 1 数据点
范式本质：不是"AI 替代人"，是"AI 执行 + 人治理"
Zhang 等（2026, SCIS，Science China Information Sciences《中国科学：信息科学》）对 2017–2024 年 988 篇 LLM4SE（LLM for Software Engineering，大语言模型用于软件工程）论文的系统综述：LLM（Large Language Model，大语言模型）已渗透需求、开发、测试、维护、管理五大阶段，但分布高度不均——开发与测试占 70%+，需求与设计相对薄弱。
3 句话讲清范式
- 从"以语言驱动代码"到"以代码塑造模型"——LLM 正在"理解"已有代码库，进化方向是双向的
- 人类保留：意图定义、架构决策、价值判断、质量审计
- AI 承担：代码生成、测试构造、缺陷定位、repetitive execution
核心结论（报告 §0）：人机融合不是"AI 替代人"，而是"AI 承担执行与自动化、人类负责设计与治理"的新型分工。最大收益在速度与覆盖，最大风险在质量稀释、技术债务累积与责任链断裂——必须以"信任但验证（trust but verify）"与"最小代理（least privilege）"原则加以约束。
第 1 讲 · 1 框架 + 4 原则
AI-DLC：AI 驱动的开发生命周期（IBM 2025）
AWS / IBM 的 Raja SP（2025）提出 AI-DLC（AI-Driven Development Lifecycle，AI 驱动的开发生命周期）——对传统 SDLC（Software Development Lifecycle，软件开发生命周期：需求→设计→实现→测试→部署的全流程）的"机器—人类协作为中心"增强。与传统 Agile/Scrum 的"在马车上加引擎"不同，AI-DLC 是重新设计车。
4 大原则（与方法论直接相关）
| # | 原则 | 含义 |
|---|---|---|
| 1 | 重新构想而非缝补 | AI 是核心参与者而非附加工具——不是把 AI 嵌进旧流程，是让 AI 重新定义流程 |
| 2 | 逆转对话方向 | 开发者描述意图，AI 用 agentic 能力主动规划、提问、执行、验证、寻求人类批准 |
| 3 | 模糊阶段边界 | 传统"规划—设计—实现—测试—部署"视为连续流，任务同时且非线性，缩短反馈环 |
| 4 | AI 不能 100% 自主 | 强调 human-in-the-loop 校验与监督——AI 提议，人定责 |
报告原话（§1.2）："AI-DLC 是比'在 Agile 上加 AI（更快的马）'更根本的进化。"——Agile 是流程框架，AI-DLC 是协作主体的根本变化。
第 1 讲 · 3 模式 + 1 分层
图 1 · 3 种协作模式按任务类型路由——关键任务人决策、规格任务 AI 起草、并行任务专家分工
3 种可切换协作模式 + 战略/战术层分工
Bitloops（2026）将人机协作归纳为可随任务切换的模式，而非一刀切：
3 种模式对比
| 模式 | 角色分工 | 适用场景 | 吞吐 vs 风险 |
|---|---|---|---|
| Driver–Navigator 驾驶员—领航员 |
人保留全部决策权，AI 执行并建议 | 关键组件、复杂领域、错误代价高的代码 | 架构一致高 / 人是瓶颈 |
| Review-First 先审后合 |
AI 从规格生成完整实现，人严格审查后批准或驳回重生成 | 规格清晰、模式既定的常规功能 | 2-3× 吞吐 / 依赖优秀规格 |
| Specialist 专家分工 |
不同 Agent 专精测试、重构、API 设计，按工作路由 | 多角色并行 | 并行 / 需清晰路由规则 |
战略层 vs 战术层（医学 + 工业共识）
| 层 | 人类职责 | AI 职责 |
|---|---|---|
| 战略层 规划与架构 |
目标、非功能需求、约束、价值判断 | 高速顾问合成方案与权衡 |
| 战术层 编码与实现 |
"信任但验证"做最终裁定 | 代码、测试、重构的实现者 |
3 种模式时序图（任务路由）
flowchart TB
Start[任务到达] --> Q{任务类型?}
Q -- "关键/复杂" --> D[Driver-Navigator
人决策 + AI 执行] Q -- "规格清晰" --> R[Review-First
AI 生成 + 人严格审] Q -- "可并行" --> S[Specialist
按路由分给多个 Agent] D --> Done[交付] R --> Done S --> Done
人决策 + AI 执行] Q -- "规格清晰" --> R[Review-First
AI 生成 + 人严格审] Q -- "可并行" --> S[Specialist
按路由分给多个 Agent] D --> Done[交付] R --> Done S --> Done
关键洞察（报告 §1.4）：这一"分层模型"与 AI-DLC 的"人类 supervisory 角色"互相印证，也是后续 5 张页面（需求→设计→实现→测试→维护）对比分析的统一框架——人类永远管"为什么做"，AI 管"怎么做"。