当 AI 能生成代码时，工程实践不仅没有过时，反而变得更加重要。
引言
AI 辅助开发正在经历一场深刻变革。Paul Duvall（CI/CD 经典著作《Continuous Integration》作者）在最近的 AI DevOps Podcast 中指出："工程实践在 AI 生成代码时变得更加重要。"
这看似矛盾的观点背后有着深刻的逻辑：AI 生成的代码量呈指数级增长，传统的人工审查模式已经无法适应。工程师需要新的方法来保证质量，这推动了 Agentic AI Patterns 的兴起。
一、为什么工程实践反而更重要？
1.1 现状：代码生成速度远超人类审查能力
传统模式：工程师写代码 → 代码审查 → 合并
AI 模式： AI 生成代码 → 自动化验证 → 合并
当 AI 能在一分钟内生成过去需要数小时才能完成的代码时，传统的代码审查变成了瓶颈。
1.2 核心矛盾
| 维度 | 传统开发 | AI 辅助开发 |
|---|---|---|
| 代码产出 | 人力驱动 | AI 驱动 |
| 变更频率 | 低 | 极高 |
| 审查覆盖 | 100% 可行 | 不可行 |
| 质量保障 | 人工审查 | 自动化验证 |
二、Agentic AI Patterns 核心模式
2.1 规范驱动开发（Specification-Driven Development）
核心理念：在让 AI 行动之前，先明确"做什么"和"做到什么程度"。
# 示例：AWS IAM 策略生成规范
spec:
intent: "创建最小权限的 S3 访问策略"
constraints:
- 只允许读取特定桶
- 不能删除对象
- 过期时间: 24小时
acceptance:
- 通过 IAM 模拟器验证
- 无过度权限
实践要点：
- 角色定义：明确 AI 的身份和职责
- 上下文提供：给出足够的背景信息
- 约束声明：明确禁止的操作
- 验收标准：定义"什么是对的结果"
"如果你没有完全描述意图，就会得到随机结果。" —— Paul Duvall
2.2 原子分解 + 并行代理（Atomic Decomposition）
核心理念：将复杂任务拆分为独立的小任务，用多个代理并行处理。
# 原子任务示例
tasks = [
"分析现有数据库 schema",
"设计 API 端点",
"实现用户认证",
"编写单元测试"
]
# 并行执行（每个任务一个代理）
results = await parallel_execute(agents, tasks)
优势：
| 优势 | 说明 |
|---|---|
| 降低复杂度 | 每个任务独立处理 |
| 加速执行 | 任务并行而非串行 |
| 便于验证 | 小任务更容易测试 |
| 错误隔离 | 单点故障不影响整体 |
2.3 编码规则（Codified Rules）
核心理念：将团队的编码规范、架构约束固化为 AI 可执行的规则。
# .ai-rules.yaml 示例
rules:
- id: "no-printf-in-prod"
description: "生产代码禁用 console.log"
action: "reject"
- id: "max-function-length"
limit: 50
action: "warn"
- id: "require-tests"
pattern: "src/**/*.ts"
require: "tests/**/*.spec.ts"
action: "reject"
实现方式：
- Agent Guard Rails：代理执行前的规则检查
- Self-Review：代理自我审查输出
- Validation Pipeline：自动化验证流程
2.4 可观测开发（Observable Development）
核心理念：不只是开发时验证，还要将反馈延伸到生产环境。
开发阶段 ←→ 测试阶段 ←→ 生产阶段
│ │ │
└────────────┴────────────┘
│
持续反馈循环
关键实践：
- 生产环境遥测数据反馈到开发流程
- AI 分析生产日志识别模式
- 提前发现问题（shift-left + shift-right）
"质量越来越通过自动化实现，而不是人工检查。" —— Paul Duvall
三、实践中的具体方法
3.1 测试驱动的 AI 工作流
Duvall 描述了他如何将 红-绿-重构 模式应用于 AI 开发：
1. Red（失败）: 定义验收标准，AI 生成初始代码
2. Green（通过）: AI 迭代直到满足标准
3. Refactor: AI 重构优化代码
这与 TDD 的核心理念一致，只是将"人工写测试"变成了"规范定义测试"。
3.2 架构约束前置
System Initiative 的 Paul Stack 提出了更激进的做法：
不接受 Pull Request
↓
必须通过 GitHub Issue 提出设计
↓
交互式评审 + 规范驱动开发
↓
代理按规范执行
理由：与其让 AI 生成代码后再审查，不如在生成前就确保意图正确。
3.3 "Remixing" 模式
Gergely Orosz（Pragmatic Engineer）描述了一种新模式：
贡献者提交 PR → 代理重建 → 符合项目标准
代理不是简单合并 PR，而是重新生成符合项目规范的代码。这确保了代码风格、架构的一致性。
四、关键模式对比
| 模式 | 核心思想 | 适用场景 |
|---|---|---|
| 规范驱动 | 先定义"做什么" | 复杂任务、多人协作 |
| 原子分解 | 拆分 + 并行 | 大型项目、需要加速 |
| 编码规则 | 自动化约束 | 质量把关、风格统一 |
| 可观测开发 | 全链路反馈 | 生产系统、持续改进 |
五、实施建议
5.1 从哪里开始？
- 定义清晰的规范：不要用模糊的指令驱动 AI
- 建立编码规则：将团队规范转换为 AI 可执行的规则
- 自动化验证：用测试替代人工审查
5.2 常见误区
| 误区 | 正确做法 |
|---|---|
| 给 AI 模糊的指令 | 提供详细的规范和约束 |
| 试图审查每一行代码 | 依赖自动化验证 |
| 只关注开发阶段 | 延伸到测试和生产 |
| 把 AI 当作全能工具 | 明确角色和边界 |
5.3 团队角色变化
过去：开发者 → 写代码 → 审查代码
现在：开发者 → 定义规范 → 验证结果 → 迭代优化
工程师的职责从"写代码"转变为"确保质量"——这是一个更高层次的角色。
六、工具与资源
推荐工具
| 工具 | 用途 |
|---|---|
| Claude Code Plan Mode | 执行前审查意图 |
| GitHub Actions | 自动化验证 |
| SWAMP | 基础设施自动化验证 |
参考资源
- Paul Duvall 的 Agentic AI Patterns 仓库
- AI DevOps Podcast
- InfoQ: Agentic AI Patterns Reinforce Engineering Discipline
总结
AI 辅助开发不是让工程实践过时，而是提升了工程实践的价值：
| 过去 | 现在 |
|---|---|
| 人工写代码 | AI 生成代码 |
| 人工审查 | 自动化验证 |
| 人工测试 | 规范定义 + 自动化 |
| 人工保障质量 | 系统保障质量 |
"编码只是我们工作的一部分，更重要的是培养更高层次的工程思维。" —— Gergely Orosz
