第四章: 软件开发方法论在 AI 时代的演进
← 上一章:项目开发全流程 | 返回目录 | 下一章:适用场景与边界 →
4. 软件开发方法论在 AI 时代的演进
4.1 敏捷开发:从 Sprints 到 Prompts
传统敏捷的挑战
Scrum 典型流程:Sprint Planning → Daily Standup → 开发(2 周) → Sprint Review → Retrospective
个人项目的问题:
- 正式会议流程对个人开发者过于繁重
- 2 周 Sprint 太长,不适合碎片化的个人时间
- 难以保持严格的流程纪律
AI 驱动的"微迭代"模式
Finance 项目的实际节奏:
- 迭代周期:1-3 天(而非传统的 2 周)
- 迭代粒度:单个功能模块
典型工作流程(总计 5.5 小时):
- 需求完善 - 明确功能边界和用户体验(30 分钟)
- 架构设计 - Planning Mode 设计数据库和接口(30 分钟)
- 快速迭代循环(3.5 小时,多次迭代):
- 单次开发:实现一个小功能(15-20 分钟)
- 立即优化:测试 + UI 调整 + Code Review(15-20 分钟)
- 重复循环:完成下一个小功能,再次优化
- 持续重构:发现架构问题时及时调整
- 集成发布 - PR 提交 + 部署 + 回归测试 + 文档更新(1 小时)
关键差异:
- 无需正式会议 - Planning Mode 和 Git 历史替代传统流程
- 快速反馈循环 - 当天开发,当晚测试
- 更多时间在迭代 - 60% 时间用于完善体验和代码质量
Shrivu 的启示:"Shoot and Forget"
引用 Shrivu Shankar 的经验:
"我的目标是'发射即忘'——设定目标和上下文,让 AI 自主工作,只验收最终 PR。"
在 Finance 项目中的应用:
低效方式(逐步指导):
You: 创建 ExpenseBudget 实体
Claude: [生成代码]
You: 现在添加 Repository
Claude: [生成代码]
...
→ 每一步都需要人工确认,效率低
高效方式("Shoot and Forget"):
You: 实现支出预算的月度预算设置功能(参考 expense-requirements.md 第3.1节),包括:
- 后端:BudgetSettings 相关的 Entity, Repository, Service, Controller
- 前端:BudgetSettingsForm.vue 组件
- 数据库:预算设置表的迁移脚本
- 测试:Service 层的单元测试
完成后运行测试,如果测试失败则自行修复。
不要每一步都问我,遇到技术问题自行决策。
注:expense-requirements.md 包含多个功能模块,每次只实现其中一个小功能,而非一次性实现全部
关键学习:
- ✅ 授权 AI 做决策 - 在架构设计指导下,让 AI 自主实现细节
- ✅ 提供充足上下文 - 参考文档 + 约束条件
- ✅ 小步功能迭代 - 不是一次性交付所有功能,而是按模块逐步完成
- ⚠️ 设定验收标准 - "测试通过" + 业务逻辑正确
4.2 测试驱动开发(TDD)的新形态
传统 TDD:Red-Green-Refactor
经典流程:写测试(Red) → 写实现(Green) → 重构(Refactor)
挑战:
- 写测试很枯燥(尤其是大量 mock)
- 重构时测试也要改(双倍工作)
AI 辅助的"契约驱动开发"
新模式流程:
- 定义契约(API 接口设计) - 人工完成
- 生成测试 - AI 根据接口自动生成测试用例
- 实现代码 - AI 实现通过测试的代码
- 人工 Review - 检查覆盖率和边界情况
优势:
- ✅ 测试先行,但不需要人写测试
- ✅ AI 同时维护测试和实现(重构时同步更新,效率更高)
- ✅ 契约清晰,减少沟通成本
现实情况:重构仍然需要修改测试,但 AI 能快速完成:
- 传统方式:人工修改实现(30 分钟) + 手动调整测试(30 分钟) = 1 小时
- AI 辅助:AI 重构实现 + 同步更新测试 = 10 分钟
真实案例:实现 ExchangeRateService.batchConvert() 时,Claude 自动生成了 8 个测试用例(正常转换、空输入、边界情况、异常处理等),发现并修复了 null 处理问题,最终测试全部通过。总耗时 20 分钟(传统 TDD 需要 1-2 小时)。
4.3 面向对象设计:AI 能理解设计模式吗?
设计模式的应用
实践证明:
- ✅ AI 能正确应用常见设计模式(策略、工厂、观察者等)
- ✅ AI 能识别明显的反模式(如 God Class、过度耦合)
- ✅ 在架构设计中明确指定使用某种模式,AI 可以很好地实现
推荐做法:
- 在 Planning Mode 的架构设计中,明确指出使用的设计模式
- 提供清晰的接口定义和职责划分
- AI 会正确应用设计模式,并遵循 SOLID 原则
案例:汇率转换的策略模式 - 在架构设计中指定使用策略模式支持多种汇率来源(固定汇率、API 获取、手动输入),Claude 正确实现了策略接口、多个策略实现类、以及基于优先级的策略选择逻辑,还主动使用了 Optional 和 Spring 依赖注入,符合 Java 最佳实践。
4.4 代码审查:人机协作的新平衡
传统 Code Review 的痛点
典型场景:提交 PR → 等待 Reviewer(1-2 天) → 收到意见 → 修改 → 再等待...
个人项目的困境:
- 没有 Reviewer(自己 review 自己很难发现问题)
- 容易引入 bug 和技术债
AI 作为第一轮 Reviewer
工作流程:
- Claude 生成代码 + 自我审查 - 检查代码规范、性能、安全、测试覆盖率
- Claude 提交改进建议 - 自动修复发现的问题
- 人工终审 - 快速扫描业务逻辑,检查 AI 的修复是否合理
效果对比:
| 环节 | 传统方式 | AI 辅助 |
|---|---|---|
| 第一轮审查 | 人工(1-2 天) | AI(5 分钟) |
| 常见问题发现率 | 70% | 90% |
| 修复时间 | 人工(1-2 小时) | AI(10 分钟) |
| 最终质量 | 良好 | 良好 |
关键洞察:
AI 擅长发现技术问题(性能、安全、测试),人类擅长发现设计问题(可维护性、可扩展性、业务理解)
4.5 构建与部署:自动化流程的简化
传统 CI/CD 的复杂性
个人项目的痛点:
- 需要记住多个命令和参数(Docker 构建、Git 提交、数据库迁移等)
- 配置文件过多,维护成本高
- 容易忘记某个环节(如推送镜像后忘记更新部署)
Finance 项目的自动化实践
核心理念:将复杂流程封装为简单的 Skills
常用 Skills:
/docker-build-push- 自动构建多架构镜像(amd64/arm64)并推送到 Docker Hub/git-commit-push- 自动 stage、commit(AI 生成消息)、push/mysql-exec- 自动加载数据库凭证并执行 SQL/setup-java- 配置 Java 环境并加载数据库凭证
效率对比:
| 任务 | 传统方式 | 使用 Skills |
|---|---|---|
| 构建+推送镜像 | 5 分钟(多个命令) | 30 秒(/docker-build-push) |
| 提交代码 | 2 分钟(3-4 个命令) | 10 秒(/git-commit-push) |
| 数据库迁移 | 1 分钟(查凭证+执行) | 5 秒(/mysql-exec) |
核心价值:
- ✅ 降低认知负担 - 不需要记住复杂命令
- ✅ 减少错误 - 自动处理凭证和环境配置
- ✅ 提高效率 - 多步操作变为一键执行
关键洞察:
好的自动化不是写更多脚本,而是让常见操作变得简单到"无需思考"
