Agentic AI 视角下的 SDLC 革命：从 SDD 到意图驱动IDD的软件工程

Ordiy Lv5
  2026-03-04 2026-03-04 Created   2026-03-04 2026-03-04 Updated    

Agentic AI 视角下的 SDLC 革命

软件开发史上，每一次范式迁移都伴随着「谁是生产主体」的根本性位移：

汇编时代 → 人是唯一生产者
IDE + 框架时代 → 人 + 工具
GitHub Copilot 时代 → 人驾驶，AI 辅助
Agentic AI 时代 → AI 执行，人审批

一、传统 SDLC 的本质是什么？

在回答"Agentic AI 改变了什么"之前，先追问一个更根本的问题：传统 SDLC 的本质是什么？

传统软件开发生命周期（SDLC）是一套信息转化与传递的流水线：

1
2
3
4
5
6
7
8
9
10
11
人类意图（模糊）
    ↓  [需求分析] 消除歧义，结构化表达
需求文档（PRD）
    ↓  [架构设计] 技术决策，分解问题
设计文档（HLD/LLD）
    ↓  [编码实现] 将逻辑转化为机器可执行的符号
代码
    ↓  [测试验证] 验证代码行为是否符合需求
通过的测试套件
    ↓  [部署运维] 将可执行产物推向用户
运行中的系统

每个阶段本质上是信息的降维翻译——从模糊的人类语言，逐步翻译为精确的机器指令。

这套流水线存在的根本原因，是在 AI 之前，只有人类能做这种"翻译"工作。

二、Agentic AI 对 SDLC 的七大颠覆

2.1 需求阶段：意图直达规格，歧义由 AI 消除

传统模式：需求分析师花 2~4 周与业务方反复沟通，产出 PRD，开发再花 1 周读 PRD 问问题。

Agentic AI 模式：

1
2
3
4
5
6
7
8
9
10
11
# Spec-kit + Cursor 的实际工作流（来自 maddevs.io 的实验）
specify-cli create \
  --intent "我需要一个监听 Telnet 端口、展示彩色 ASCII 艺术画的服务" \
  --short-name "telnet-art"

# AI 自动生成：
# ✅ 功能规格（含边界条件）
# ✅ 数据模型
# ✅ 协议契约（contracts/telnet-protocol.md）
# ✅ 验收标准
# ✅ 研究报告（技术选型理由）

最颠覆的洞察：AI 没有人类的「知识诅咒（Curse of Knowledge）」——它不会假设对方已经知道某个上下文，因此生成的规格比人写的更完整、边界条件更全面。

「将任务分配给人类同事时，我们常常留下隐含信息。模型没有这种偏见，所以生成的任务颗粒度极高，描述每一个细小步骤。」
— maddevs.io

革命程度：★★★★☆
需求阶段从"2~4周人工对齐"压缩到"小时级意图澄清"。

2.2 设计阶段：规格即设计，AI 是架构师

传统模式：架构师手工绘制架构图、设计数据模型、定义 API 契约——这些文档通常在项目结束时就已过时。

Agentic AI 模式（SDD 路线）：

1
2
3
/speckit.constitution  → 定义架构原则、技术栈约束
/speckit.plan          → AI 研究最优技术方案，生成执行计划
/speckit.tasks         → AI 分解为精确的可执行任务，含验收标准

规格文件（specs/ 目录）变成比代码更重要的源码——代码是可重新生成的产物，规格是真正的"源头"。

1
2
3
4
5
6
7
specs/
├── constitution.md      # 架构宪法：约束 AI 行为的边界
├── plan.md              # 技术选型 + 执行路线图
├── data-model.md        # 数据模型
├── research.md          # 技术调研结论
└── contracts/
    └── api-protocol.md  # 接口契约

最颠覆的洞察：设计文档第一次有机会与实现保持同步——因为代码是从规格生成的，而不是代码写完了再补文档。

革命程度：★★★★★
这是对"文档总是滞后于代码"这一几十年顽疾的根本性解决。

2.3 实现阶段：开发者从「写代码」变为「审查代码」

这是最直观也最容易被低估的转变。

传统模式：开发者 80% 时间写代码，20% 时间读代码（Code Review）。

Agentic AI 模式：

1
2
/speckit.implement  Phase 1 to Phase 3  # 一行命令，AI 生成多文件代码
claude -p "实现用户认证模块，参考 specs/contracts/auth-protocol.md"

开发者角色变成：

  • 意图工程师（Intent Engineer）：把模糊想法转化为清晰描述
  • 审查工程师（Review Engineer）：审查 AI 产出，判断方向是否正确
  • 约束工程师（Constraint Engineer）：维护 CLAUDE.md / .cursorrules 等 AI 行为边界

最颠覆的洞察：实现速度不再受限于「人类打字速度」，而是受限于「人类的意图清晰度和审查速度」。

革命程度：★★★★★
这是软件工程生产关系的根本变革，不亚于从汇编到高级语言的跃迁。

2.4 测试阶段：测试从"验证代码"变为"驱动生成"

传统 TDD：先写测试，再写代码，让测试驱动实现。

Agentic AI 下的演进（三种路线并行）：

1
2
3
4
5
6
7
8
9
10
11
路线 A：Agent 生成测试 + 生成代码（双轮生成）
路线 B：人写验收标准 → AI 生成测试 → AI 生成代码（意图→验收→实现）
路线 C：AI 生成代码 → AI 运行测试 → AI 自动修复（闭环自愈）

# 路线 C 的 GitHub Actions 示例
jobs:
  ai-fix-tests:
    steps:
      - run: mvn test || true
      - run: claude -p "分析测试失败，修复代码，不得修改测试本身" --allow-all-tools
      - run: mvn verify

最颠覆的洞察：测试失败不再是"需要人工介入"的信号，而是 AI Agent 的自动任务输入。CI/CD 流水线第一次有了内置的自愈能力。

革命程度：★★★★☆

2.5 部署阶段：意图直达生产环境

1
2
3
4
5
6
# Copilot CLI：一句话完成完整 PR 流程
copilot -p "
  将 feature/auth-refactor 分支的变更创建 PR，
  添加 changelog 条目，assign 给 @alice 审查，
  如果 CI 通过则自动合并到 main
" --allow-all-tools

最颠覆的洞察：部署流程的「最后一公里」——提交、PR、合并、发布——开始被 Agent 整体接管。

革命程度：★★★☆☆（工具链已成熟，普及还需时间）

2.6 维护阶段：从被动修复到主动巡检

传统维护是被动响应：报警 → 人工排查 → 修复。

Agentic AI 模式开始让维护变得主动：

1
2
3
4
5
6
# 定时任务：每周日凌晨 AI 自动巡检
claude -p "
  扫描过去一周的错误日志，
  识别高频异常，
  为 Top 3 问题生成 GitHub Issue 并附上初步根因分析
" --allow-all-tools

革命程度：★★★☆☆（仍在早期探索阶段）

2.7 【最深层颠覆】SDLC 各阶段边界的消融

传统 SDLC 是瀑布式或迭代式的时序结构——各阶段有明确分界。

Agentic AI 让这些边界开始消融：

1
2
3
4
5
6
7
意图描述
   ↓ AI 同时完成：
   ├── 生成规格（需求）
   ├── 生成架构设计
   ├── 生成实现代码
   ├── 生成测试用例
   └── 生成部署配置

换句话说，"从意图到运行"可以是一个连续的单步操作，而不是几个月的线性流程。

这不是某一个阶段的优化，而是对整个流程结构的重新定义。

革命程度：★★★★★（这才是真正的范式转移）

三、SDD vs Agentic AI：两种路线的效率地图

3.1 SDD（规格驱动开发）的工作流

基于 Cursor + Spec-kit 的实际流程：

1
2
3
4
5
6
7
8
9
10
11
人类意图（一句话描述）
    ↓
/speckit.specify    → AI 生成完整规格文档
    ↓ [人工 Review & 调整]
/speckit.plan       → AI 研究技术方案，生成执行计划
    ↓ [人工确认]
/speckit.tasks      → AI 分解为精确任务（含边界条件和验收标准）
    ↓ [人工验证任务列表]
/speckit.implement  → AI 按阶段生成代码
    ↓ [人工测试每个 Phase]
Working Product

本质：在人类意图和机器代码之间，插入一个结构化的中间表示层（规格文档），人类在这一层进行质量控制。

3.2 Agentic AI（直接任务执行）的工作流

1
2
3
4
5
6
7
8
9
人类意图（自然语言 Prompt）
    ↓
Agent 分析上下文（读取 CLAUDE.md / .cursorrules）
    ↓
Agent 规划（内部推理，不一定显式输出）
    ↓
Agent 执行（写文件、运行命令、测试）
    ↓ [人工审批关键步骤]
Working Product

本质：意图直接驱动执行，中间层是 AI 的内部推理，不显式暴露给人类。

3.3 效率对比矩阵

维度 SDD（规格驱动） Agentic AI（直接执行）
上手速度 慢（需学习规格体系） 快（自然语言即可）
意图保真度 高（规格是显式校验点） 中（依赖 Prompt 质量）
绿地项目（0→1） ✅ 最优（规格即文档） ✅ 够用，可能偏向）
存量大项目改造 ❌ 难（规格难以逆向） ✅ 更强（理解现有代码）
团队协作 ✅ 优（规格是沟通媒介） ⚠️ 依赖 CLAUDE.md 完整性
连续迭代 ⚠️ 规格更新成本高 ✅ 自然对话，随时调整
可审计性 ✅ 每个决策有文档可查 ⚠️ AI 推理过程是黑箱
错误定位 ✅ 归因到规格层 ⚠️ 需要人工追溯上下文
CI/CD 集成 ⚠️ 工具链尚不成熟 ✅ 三大工具均原生支持
时间效率（小项目） 中（规格生成有开销） 高（直接执行）
时间效率（大项目） 高（规格减少返工） 中（幻觉风险上升）

3.4 两种模式的本质差异

1
2
3
4
5
6
7
8
SDD：  [意图] → [显式规格] → [代码]
              ↑              ↑
          人工质控点      人工质控点

Agentic：[意图] ─────────────→ [代码]
                    ↑
              AI 内部推理（黑箱）
              人工审批执行动作

SDD 的赌注：如果规格正确，代码大概率正确。
Agentic AI 的赌注：如果模型够聪明，即使没有中间层也能正确理解意图。

目前，两个赌注都在被验证中，且都在特定场景下成立。

3.5 场景化选择建议

推荐 SDD 的场景：

  • 全新产品，需要向团队/投资人说明架构决策
  • 多人协作，规格作为"合同"减少沟通成本
  • 需要严格审计的行业（金融、医疗）
  • Vibe Coding 爱好者，不想陷入"反复 Prompt 调试"的泥潭

推荐 Agentic AI 的场景：

  • 向已有大型代码库添加功能
  • 复杂重构（AI 需要理解全局上下文）
  • 临时自动化脚本和工具
  • 已有清晰意图，追求极速交付

理想组合：

1
2
3
4
5
6
SDD（规格层）+ Agentic AI（执行层）

1. 用 Spec-kit / Kiro 生成规格文档 → 人工确认
2. 将规格写入 CLAUDE.md           → 成为 AI 长期记忆
3. 用 Claude Code / Cursor CLI    → 执行具体任务
4. CI/CD Agent 自动运行测试并修复  → 闭环自愈

四、AI 时代软件开发的最佳范式（个人判断）

经历了工具的持续演进和社区实践的沉淀，我认为最适合 AI 时代的开发范式是一个三层架构：

第一层：意图层（Intent Layer）

工具：自然语言 + Spec-kit / Kiro
产出：CLAUDE.md、specs/constitution.md、PRD

这一层的核心是把模糊意图转化为可执行约束。不是写代码，而是训练 AI 了解你的项目。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
# CLAUDE.md 示例（意图层产物）

## 项目定位
实时数据处理平台，读多写少，延迟 SLA < 100ms

## 架构约束
- 领域驱动设计（DDD），严禁 domain 层直接引用 infrastructure
- 所有外部依赖必须通过 Interface 抽象
- 禁止在 Service 层写 SQL

## 技术栈
Java 21 + Spring Boot 3.3 + PostgreSQL + Kafka

## 质量门控
- 单元测试覆盖率 > 80%
- 新增公共 API 必须有 OpenAPI 注解
- PR 合并前必须通过静态扫描（SonarQube）

第二层：协作层（Collaboration Layer）

工具：Cursor IDE / VS Code + AI Extension
产出：代码、测试、文档

这一层是传统意义上的"开发工作"，但人类的角色已经改变：

传统角色 AI 时代角色
编写实现代码 审查 AI 生成的代码（重点：逻辑边界、安全漏洞）
手写单元测试 定义验收标准，审查 AI 生成的测试
更新 API 文档 确认 AI 同步生成的 OpenAPI 注解正确
Debug 代码错误 向 AI 描述错误现象，审查修复方案

第三层：自动化层（Automation Layer）

工具：GitHub Actions / GitLab CI + Claude Code / Copilot CLI
产出：稳定运行的系统

1
2
3
4
5
6
7
8
9
10
11
12
13
14
# CI/CD Pipeline 的 AI 层
pipeline:
  stages:
    - build          # 传统：编译 + 静态分析
    - test           # 传统：单元 + 集成测试
    - ai-fix:        # 新增：AI 自动修复失败测试
        if: test_failed
        run: claude -p "修复失败的测试，不得改变测试意图" --allow-all-tools
    - ai-review:     # 新增：AI 代码审查
        run: copilot -p "检查本次 PR 变更，报告安全风险和性能隐患"
    - deploy         # 传统：部署
    - ai-monitor:    # 新增：AI 巡检
        schedule: weekly
        run: claude -p "分析本周日志，生成 Issue"

五、最终判断：哪些变化是真正不可逆的？

历史上，真正不可逆的技术变革有一个特征：它解决了一个此前被认为是"本质困难"而非"工程问题"的问题。

Agentic AI 正在解决的"本质困难"只有一个：

人类意图与机器指令之间的翻译成本。

这个翻译成本，驱动了过去 70 年软件工程所有的方法论创新——UML、设计模式、敏捷、TDD、微服务……本质上都是在降低"意图→代码"这条链路上的信息损耗。

当 AI 能够高质量地完成这个翻译，软件工程方法论将面临一次全面的重新推导。

目前最可能不可逆的变化：

  1. 规格优先于代码：未来的代码库中，specs/ 目录和 CLAUDE.md 会比 src/ 更重要
  2. 开发与测试的边界消失：AI 同步生成实现和测试，TDD 中"先写测试"的仪式感消失
  3. 文档滞后问题被永久解决：文档由 AI 按规格生成，与代码天然同步
  4. CI 从"检查"变为"修复"：流水线不再只报告问题，开始自主解决问题
  5. 软件从「资产」变为「燃料」：代码库不再是护城河，可按需重新生成；真正的资产是封装了领域知识的规格文档（见下节）

5.1 【延伸洞察】软件从「资产」变为「燃料」

这里有一个更深层的推论，值得单独点出：

大型软件系统，正在从「资产」（Asset）变为「生产力的燃料」（Fuel/Consumable）。

传统范式下，代码库是公司最重要的资产之一：

  • 需要几年、几十年持续积累
  • 需要小心翼翼地维护，避免「技术债」侵蚀资产价值
  • 代码的完整性和健康度是企业竞争力的护城河
  • 「从头重写」是高风险、高成本的最后手段

Agentic AI 范式下，这个逻辑开始反转：

  • 规格（Spec）才是资产——它封装了领域知识、架构决策、业务约束，是真正不可快速替代的东西
  • 代码只是规格被执行后的产物——更像是每次构建时生成的编译产物，可以随时丢弃再生成
  • 技术债不再是慢性病——如果一个模块腐化了，从规格重新生成即可，而不是在旧代码上反复打补丁
  • 「从头重写」变得廉价——只要规格存在，重新生成代码的成本趋近于零

类比历史上的类似转变：

1
2
3
4
5
6
7
印刷术之前：手抄书稿是珍贵资产（稀缺·不可复制）
印刷术之后：印版/底稿才是资产，印出的书是消耗品

软件工程前期：可执行的编译文件是资产（分发珍贵）
源代码时代：源代码是资产，编译输出是产物

Agentic AI 时代：规格/意图是资产，源代码是产物

这意味着软件行业的价值链将发生根本性重构：

过去的竞争壁垒 未来的竞争壁垒
亿行级别的精心积累的代码库 对行业领域的深刻理解，编码为规格
能写出高质量代码的工程师团队 能清晰表达意图和约束的「规格工程师」
难以复制的历史技术积累 难以复制的领域知识和 AI 协作工作流

推论：未来企业的核心数字资产，不是 git clone 下来的几百万行代码，而是那份精心维护的 CLAUDE.md 和 specs/ 目录——那里浓缩着无法被 AI 自动推断的领域知识和决策历史。

还不会改变的：

  • 需要人类做的系统级架构决策（至少在未来 3~5 年内）
  • 需要领域专家参与的需求澄清（AI 不了解特定行业的业务约束）
  • 最终的安全职责（AI 可以提议，人类必须审批）

六、对技术人员职业生涯的影响

如果代码是燃料、规格是资产，那么过去 30 年形成的技术职业价值评估体系，正在被全面重新定价。

6.1 压力最大的岗位

**初中级「代码执行者」**是受冲击最直接的群体：

岗位 受冲击原因
外包/外包平台 CRUD 开发 样板代码生成成本趋近于零
初级测试工程师（手动测试） 测试用例由 AI 生成，执行由 CI 自动化
文档工程师 文档与代码同步生成，无需专职维护
「翻译型」需求分析师 把 Word 文档翻译成代码的工作可被 SDD 工具替代

但需要补充：这不意味着这些岗位消失，而是岗位密度下降，同等输出需要的人更少。一个 Agentic AI 辅助的工程师可以完成过去 3~5 人的工作量——这是生产力提升，也是用工收缩。

6.2 价值上升的岗位

价值重构的逻辑来自「资产 → 燃料」的转变：越靠近规格（意图）端，价值越高；越靠近代码（执行）端，价值越低。

明确受益的角色：

① 领域专家（Domain Expert）

AI 能写任何语言的代码，但无法替代「某家医院的排班逻辑为什么不能按常识设计」这类深层领域知识。理解业务规则的深度，将是最不可替代的能力。

② 系统架构师（Architect）

技术债可以被 AI 重写，但「为什么当初选择微服务而非单体」「为什么这里用 Event Sourcing」这类架构决策的背景，只有人能记录、传承和演进。架构师的核心产出从「画图」变成「维护架构决策记录（ADR）」——这正是规格层最核心的内容。

③ 规格工程师 / AI 导向工程师（Spec Engineer / AI Orchestrator）

这是一个正在涌现的新职业角色——专职负责：

  • 将模糊需求转化为精确的 CLAUDE.md 和 Spec 文档
  • 设计 AI Agent 的工具权限边界和工作流
  • 审查 AI 产出，维护规格与代码的一致性
  • 构建组织级的 AI 协作工作流（Prompt 工程 + Agent 编排）

④ 安全工程师（Security Engineer）

Agentic AI 拥有运行 shell 命令、修改文件、调用外部 API 的能力。谁来审计 AI 的行为边界、设置最小权限原则、评估 Prompt Injection 风险？安全工程师的职责范围正在迅速扩展。

⑤ 平台工程师（Platform Engineer）

为 AI Agent 提供安全、可观测的运行环境——沙箱隔离、工具权限管理、审计日志、Agent 编排基础设施——这套「AI 运行时平台」需要专业维护。

6.3 职业转型的关键判断

这场变革与以往技术浪潮（互联网化、云化、移动化）有一个根本不同：

以往的技术浪潮创造了大量新的执行层岗位（PHP 开发、iOS 开发、云运维）。

这次 AI 浪潮压缩的恰恰是执行层，扩张的是意图层和判断层——而这些层级需要的不是「更多地敲键盘」，而是更深的领域理解和更强的系统判断力。

对个人职业路径的具体建议：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
如果你是初中级开发者：
  ✅ 尽快掌握 Agentic AI 工具（Cursor / Claude Code）
     → 用 AI 扩大自己的交付能力，而不是等待被替代
  ✅ 向领域深度发展，而不是追求技术栈宽度
     → 「懂某个行业的工程师」远比「懂 10 种框架的工程师」稀缺
  ✅ 学习规格写作和 AI 工作流设计
     → 这是新的核心工程能力

如果你是高级工程师/架构师：
  ✅ 把你的隐性架构知识显式化（写 ADR，维护 CLAUDE.md）
     → 这是你最不可替代的知识，也是最容易随着你离职而消失的知识
  ✅ 承担 AI 输出的最终裁决者角色
     → 审查 AI 代码的能力需要比写代码更深的理解
  ✅ 建立 AI-in-loop 的团队工作流
     → 能让 AI「乘数效应」发挥价值的工程师，将比「自己写」更有竞争力

如果你是工程管理者：
  ✅ 重新设计绩效评估体系
     → 不再以代码行数/PR 数量衡量，而是以意图清晰度和交付质量衡量
  ✅ 建立「规格资产」的组织治理
     → CLAUDE.md / specs/ 目录应该纳入知识管理体系，不能只存在于某个工程师的脑子里

6.4 一个值得警惕的陷阱：「AI 使用熟练度」本身不是护城河

目前很多工程师在努力学习「如何更好地 Prompt」「如何配置 MCP」，这当然是短期内必要的。

但需要清醒认识到：工具使用技能的半衰期在加速缩短。今天需要精心设计 Prompt 的任务，明年可能只需一句话。今天需要配置 MCP 的集成，后年可能已经内置。

真正长期保值的能力只有两类：

  1. 领域知识的深度——AI 无法替代你对某个具体行业、具体系统的深层理解
  2. 系统性判断力——在不确定条件下做出正确架构决策的能力，这需要大量失败经验积累

「会用 AI 工具」是入场券，不是护城河。在 AI 时代建立职业护城河，靠的是 AI 目前还做不到的事情：在复杂的、有约束的、有历史包袱的真实世界中做出正确判断。

七、推荐阅读

写于 2026-03-04 | 软件工程正在经历自高级语言发明以来最深刻的范式迁移，本文是一个持续更新中的思考快照。

  • Title: Agentic AI 视角下的 SDLC 革命：从 SDD 到意图驱动IDD的软件工程
  • Author: Ordiy
  • Created at : 2026-03-04 00:00:00
  • Updated at : 2026-03-04 00:00:00
  • Link: https://ordiy.github.io/posts/2026-03-04-agentic-ai-sdlc-revolution-sdd-comparison/
  • License: This work is licensed under CC BY-NC-SA 4.0.
Comments
On this page
Agentic AI 视角下的 SDLC 革命：从 SDD 到意图驱动IDD的软件工程
  1. Agentic AI 视角下的 SDLC 革命
    1. 一、传统 SDLC 的本质是什么？
    2. 二、Agentic AI 对 SDLC 的七大颠覆
      1. 2.1 需求阶段：意图直达规格，歧义由 AI 消除
      2. 2.2 设计阶段：规格即设计，AI 是架构师
      3. 2.3 实现阶段：开发者从「写代码」变为「审查代码」
      4. 2.4 测试阶段：测试从"验证代码"变为"驱动生成"
      5. 2.5 部署阶段：意图直达生产环境
      6. 2.6 维护阶段：从被动修复到主动巡检
      7. 2.7 【最深层颠覆】SDLC 各阶段边界的消融
    3. 三、SDD vs Agentic AI：两种路线的效率地图
      1. 3.1 SDD（规格驱动开发）的工作流
      2. 3.2 Agentic AI（直接任务执行）的工作流
      3. 3.3 效率对比矩阵
      4. 3.4 两种模式的本质差异
      5. 3.5 场景化选择建议
    4. 四、AI 时代软件开发的最佳范式（个人判断）
      1. 第一层：意图层（Intent Layer）
      2. 第二层：协作层（Collaboration Layer）
      3. 第三层：自动化层（Automation Layer）
    5. 五、最终判断：哪些变化是真正不可逆的？
      1. 5.1 【延伸洞察】软件从「资产」变为「燃料」
    6. 六、对技术人员职业生涯的影响
      1. 6.1 压力最大的岗位
      2. 6.2 价值上升的岗位
      3. 6.3 职业转型的关键判断
      4. 6.4 一个值得警惕的陷阱：「AI 使用熟练度」本身不是护城河
    7. 七、推荐阅读