新的软件开发生命周期 (SDLC)
传统 SDLC 已经历一次转变
过去二十年：瀑布 → Agile → DevOps → 快速发布
AI 压缩 SDLC：不均匀但剧烈
白皮书指出：
“AI compresses this cycle dramatically, but unevenly: implementation that once took weeks can now be done in hours, while requirements, architecture, and verification remain stubbornly human-paced.”
翻译：AI 剧烈但不均匀地压缩这个周期：实现几小时（过去几周），而需求、架构、验证仍然人类节奏。
结果：不是旧 SDLC 的更快版本，而是不同的工作流。
六个阶段的转变
1. Requirements & Planning（需求与规划）
| 传统方式 | AI 方式 |
|---|---|
| 业务需求 → 技术规范手动翻译 | AI 直接参与需求细化 |
| 错误率高、文档持久差距 | 生成用户故事、识别边界情况、生成 API schema、生成原型 |
| 需求是文档交接 | 需求是人与 AI 的对话，同时产生规范和实现 |
| 需求到原型反馈循环慢 | 反馈循环接近零 |
2. Design & Architecture（设计与架构）
为什么保持人类中心？
白皮书解释：
“Architectural decisions are fundamentally about trade-offs: consistency vs. availability, complexity vs. flexibility, build vs. buy. These trade-offs depend on business context, organisational constraints, and long-term strategic considerations that AI cannot fully grasp.”
翻译：架构决策本质是权衡：一致性 vs 可用性、复杂度 vs 灵活性、自建 vs 购买。这些权衡依赖业务上下文、组织约束、长期战略考量，AI 无法完全理解。
| 开发者角色 | AI 角色 |
|---|---|
| 做出并文档化结构决策 | 架构决策后优秀地实现 |
| 从编写样板代码转变 | scaffold 整个应用、跨模块生成一致模式、确保符合约定 |
3. Implementation（实现）
生产力数据： - 行业调查：25-39% 生产力改进 - METR 研究：有经验开发者某些任务慢 19%（验证、调试、纠正 AI 输出的时间）
白皮书总结:
“AI does not eliminate implementation work so much as transform it from writing to reviewing, guiding, and verifying.”
翻译：AI 不是消除实现工作，而是将其从编写转变为审查、指导和验证。
4. Testing & QA（测试与质量保证）
双重评估：
| 评估类型 | 检查什么 | 为什么必要 |
|---|---|---|
| Output Evaluation | 代码编译？测试通过？ | 表面验证 |
| Trajectory Evaluation | 工具调用序列、中间推理 | 深层验证 |
为什么两者都需要？
“Both are necessary because a fluent output that skipped its verification steps is a more dangerous failure than one with a visible error.”
翻译：流畅输出如果跳过验证步骤，比有可见错误的输出更危险。
Continuous Quality Flywheel（持续质量飞轮）:
评估基准套件
↓ 诊断失败（聚类根本原因）
↓ 优化 prompt/tools
↓ 验证修复（回归套件）
↓ 监控生产流量（新失败模式）
↓ 重复（复合增长）5. Code Review & Deployment（代码审查与部署）
| 角色 | AI 角色 | 人类角色 |
|---|---|---|
| 首次审查 | AI 作为第一轮审查者：识别 bug、样式违规、安全漏洞、性能问题 | 上下文依赖决策（设计、可维护性、战略对齐） |
| 部署管道 | AI 监控部署健康、自动回滚、预测风险 | AI-powered observability 创建反馈循环 |
6. Maintenance & Evolution（维护与演化）
最被低估的转变：
| 过去 | 现在 |
|---|---|
| 留代码库对新团队不可理解 | AI Agent 能阅读、理解、导航、修改遗留代码 |
| “太风险不敢触碰”的代码无人敢改 | AI 能安全重构、现代化、扩展 |
| 框架迁移、API 更新、测试现代化太乏味和风险 | AI 系统性完成这些任务 |
Factory Model（工厂模型）
核心观念：
“In this model, the developer’s primary output is not code - it’s the system that produces code.”
翻译：开发者的主要产出不是代码——而是生产代码的系统。
系统组成：
┌─────────────────────────────────────────────────────┐
│ Specifications and Context │
│ → 定义需要构建什么 │
├─────────────────────────────────────────────────────┤
│ Agents │
│ → 将规范转化为实现 │
├─────────────────────────────────────────────────────┤
│ Tests and Quality Gates │
│ → 验证正确性 │
├─────────────────────────────────────────────────────┤
│ Feedback Loops │
│ → 将失败路由回 Agent 纠正 │
├─────────────────────────────────────────────────────┤
│ Guardrails │
│ → 约束 Agent 到安全、可预测行为 │
└─────────────────────────────────────────────────────┘类比：工厂经理不手工组装每个产品，他们设计装配线并确保质量控制。
成功秘诀：
“Success comes from giving agents success criteria rather than step-by-step instructions, then letting them iterate.”
翻译：成功来自给 Agent 成功标准而非逐步指令，然后让它们迭代。