第五章：Claude Code 的适用场景与边界
← 上一章：软件开发方法论 | 返回目录 | 下一章：总结与展望 →
5. Claude Code 的适用场景与边界
5.1 最适合的场景
基于 Finance 项目的经验，Claude Code 在以下场景中表现优异：
1. 全新项目的快速原型
典型场景：
- 将现有工作流程（如 Excel/Spreadsheet）转化为 Web 应用
- 快速验证产品想法的可行性
- 探索新的开发模式（如 Vibe Coding）
Finance 项目验证：
- 背景：将 Spreadsheet 财务管理迁移到 Web 应用
- 技术栈：复用已有项目的技术选型（Spring Boot + Vue 3）
- 开发模式：首次尝试 Vibe Coding（完全新的开发体验）
- 从零到可运行的 MVP：2 天（传统方式需要 1-2 周）
- 基础功能完整度：85%
- 代码质量：可直接进入迭代阶段
关键成功因素：
- 技术栈是主流的（Spring Boot、Vue 3）
- 需求清晰（基于已有的 Spreadsheet 工作流）
- Vibe Coding 模式显著提升开发效率
2. 已有项目的功能扩展
典型场景：
- 在现有 CRM 系统中添加报表模块
- 给博客系统增加评论功能
- 扩展 API 支持新的数据格式
Finance 项目验证：
添加"支出预算管理"功能：
- 涉及：2 个新表、4 个 API、3 个前端页面
- 传统方式估算：3-5 天
- 实际耗时：8 小时（Claude Code 辅助）
- 代码复用率：70%（参考了现有的 expense 模块）
Claude Code 的优势：
- ✅ 理解现有代码风格（通过 CLAUDE.md）
- ✅ 复用已有组件（Service 层、DTO 模式）
- ✅ 保持一致性（命名、注释、测试）
3. 系统性重构
典型场景：
- 应用新的 UI 设计准则到现有页面
- 跨模块的功能增强（如多币种支持）
- 统一优化用户体验（如移动端适配）
Finance 项目验证：
任务 1：用支出分析的 UI 设计准则重构资产负债分析页面
- 涉及：6 个 Vue 组件的样式和布局重构
- 传统方式：2-3 天（需要反复对比和调整）
- Claude Code：6 小时
- 风格一致性：95%+
任务 2：全系统多币种支持
- 涉及：数据库迁移、后端 Service 层改造、前端组件更新
- 传统方式：1 周（跨层修改，容易遗漏）
- Claude Code：2 天
- AI 自动识别所有需要修改的位置
任务 3：优化所有 UI 的移动端体验
- 涉及：33 个 Vue 组件的响应式布局调整
- 传统方式：3-4 天
- Claude Code：1 天
- 统一应用 Tailwind 响应式类
4. 文档和测试编写
典型场景：
- 为复杂业务逻辑写单元测试
- 生成和同步项目文档
- 迭代后更新设计文档和数据库文档
Finance 项目验证：
| 任务 | 传统耗时 | AI 耗时 | 质量评价 |
|---|---|---|---|
| 单元测试（30 个 Service） | 8 小时 | 1.5 小时 | 覆盖率 85%+ |
| 需求文档同步（迭代后） | 3 小时 | 30 分钟 | 需人工审核 |
| 设计文档更新 | 2 小时 | 20 分钟 | 准确反映变更 |
| 数据库文档同步 | 2 小时 | 15 分钟 | 完整准确 |
| 架构图（Mermaid） | 1 小时 | 5 分钟 | 清晰准确 |
最大价值：
- 测试编写：AI 生成的测试用例覆盖了更多边界情况
- 文档同步：经过多次迭代后，文档差异很大，AI 能快速对齐代码和文档
- 效率提升：文档维护从"最讨厌的任务"变为"10分钟搞定"
5.2 不适合或需要谨慎的场景
1. 复杂的业务逻辑实现
案例：年度财务汇总算法（Finance 实际案例）
需求：跨账户、跨币种、跨时间的复杂聚合计算（使用存储过程实现）
实现过程（多次迭代）：
-
第一版：AI 生成基础聚合逻辑
- ❌ 没有考虑多币种转换
- ❌ 性能很差（15秒响应时间）
-
第二版：与 AI 讨论优化方案
- ✅ 添加币种转换逻辑
- ⚠️ 仍有性能问题
-
第三版：人工介入设计
- ✅ 重构为批量操作
- ✅ 优化到 0.8 秒
结论：
- ⚠️ AI 可以实现复杂逻辑，但需要多次迭代和人工指导
- ❌ 初版往往遗漏关键边界情况（如多币种、性能优化）
- 🎯 策略：分步实现 + 持续讨论 + 人工审查关键逻辑
2. 性能关键的底层代码
案例：大数据量的财务报表生成
需求：生成包含 50+ 账户 × 12 月 × 5 年 = 3000 条记录的趋势报表，响应时间要求 <1 秒
Claude 第一版（不合格）：
- 循环查询数据库（300 次查询）
- 响应时间：15 秒
人工优化（使用存储过程）：
- 一次性聚合所有数据
- 响应时间：0.8 秒
- 性能提升：18 倍
结论：
- ❌ AI 倾向于"能跑就行"的实现（忽略性能）
- ⚠️ 性能关键路径需要人工设计和 profiling
- ✅ AI 可以生成存储过程代码（给定明确需求）
5.3 团队协作场景的适用性
虽然 Finance 是个人项目，但基于 Shrivu 的企业经验和 Claude Code 的特性，可以推断团队场景的适用性：
适合的团队场景
1. 小型团队（2-5 人）
- ✅ 统一的 CLAUDE.md 可作为"代码宪法"
- ✅ Skills 可封装团队工具链（部署、测试、代码检查）
- ✅ Hooks 可强制代码规范（如预提交测试）
示例：某 3 人创业团队的实践
- 维护一个 13KB 的 CLAUDE.md（技术栈 + 编码规范）
- 5 个共享 Skills（部署、数据库、API 测试、文档生成、代码格式化）
- 2 个 Hooks（测试通过才能提交、敏感数据检查）
效果：
- 新成员上手时间：从 2 周 → 3 天
- 代码风格一致性：95%+
- 重复性工作减少：60%
2. 开源项目贡献
- ✅ CLAUDE.md 可作为贡献者指南
- ✅ AI 帮助新贡献者理解代码库
- ✅ AI 生成符合项目规范的 PR
推荐做法：在 CLAUDE.md 中说明开发工作流、常见陷阱、代码规范，帮助贡献者快速上手
不适合的团队场景
1. 大型企业（100+ 工程师）
- ❌ CLAUDE.md 难以涵盖所有团队的特殊需求
- ❌ 代码审查流程复杂（需要多级审批）
- ⚠️ 安全性和合规性问题（AI 访问敏感代码）
解决方案（Shrivu 的企业实践）：
- 每个产品线维护自己的 CLAUDE.md（继承公司级规范）
- 使用 Claude Code GHA（GitHub Actions）而非本地 CLI（更好的审计）
- 限制 AI 访问范围（只能访问特定代码库）
2. 高度监管的行业（金融、医疗）
- ❌ AI 生成的代码需要严格的合规审查
- ❌ 代码归属和责任问题（AI 写的 Bug 谁负责？）
- ⚠️ 数据隐私问题（代码中可能包含敏感信息）
建议：
- 仅在非核心、非敏感模块使用 AI
- 所有 AI 生成代码必须人工审查 + 法务/合规审批
- 使用私有部署的模型（如 Claude for Enterprise）
5.4 常见错误与效率陷阱
在 Finance 项目开发过程中，我犯过一些错误导致 Claude Code 效率大幅下降。这些经验教训值得分享：
错误 1：关键约束未固化到 CLAUDE.md 或 Skills
问题表现：
- Claude 不断犯同样的错误（如使用错误的数据库连接方式）
- 每次会话都要重复强调相同的规则
- 浪费大量 token 在纠正错误上
实际案例：
- 前 3 次会话，Claude 总是用
mvn而不是./mvnw - 多次忘记使用
TimeService.getCurrentTimestamp()导致时区问题 - 数据库操作总是直接写 SQL 而不是用
/mysql-execskill
解决方案：
- ✅ 将重复出现的规则写入 CLAUDE.md 的 "Critical Rules"
- ✅ 将常用操作封装为 Skills（如
/setup-java、/mysql-exec） - ✅ 使用 Hooks 强制验证关键约束
错误 2：CLAUDE.md 内容过多导致 Token 耗尽
问题表现：
- 每次会话很快就提示 token 不足
- 需要频繁
/clear重新开始 - 等待摘要生成的时间过长（1-2 分钟）
实际案例：
- 初期的 CLAUDE.md 包含了大量详细示例代码（20KB+）
- 每次读取消耗 15K+ tokens
- 5-6 轮对话后就需要重启会话
解决方案：
- ✅ 删除示例代码，只保留规则和原则
- ✅ 将详细文档移到外部文件（如
docs/api-design.md） - ✅ CLAUDE.md 控制在 5-10KB 以内
- ✅ 使用 "ALWAYS/NEVER" 格式的简洁规则
错误 3：需求步伐太大导致频繁的数据库变更
问题表现：
- 后期频繁修改数据库表结构
- 每次修改牵连前后端大量改动
- 数据迁移脚本越来越复杂
实际案例：
- 第一版支出管理没有考虑多币种，后期添加时修改了 5 个表
- 导致：10+ 个 API 需要修改，8 个前端组件需要更新，3 个存储过程需要重写
- 数据迁移脚本：300+ 行复杂 SQL（包含数据转换和验证逻辑）
- 另一个例子：Claude 初期设计了过多的表和字段（"可能会用到"的冗余设计）
- 后期清理工作：删除 4 个未使用的表，20+ 个冗余字段，耗时 2 天
解决方案：
- ✅ 使用 Planning Mode 充分设计数据模型
- ✅ 一次只实现一个小功能，充分测试后再扩展
- ✅ 重要字段（如币种）在第一版就考虑进去
- ✅ 参考已有模块的数据模型设计
错误 4：只测试功能不审查实现导致技术债
问题表现：
- 表面功能相同，但后台实现完全不同
- 后期重构时发现大量不一致的代码
- 难以维护和扩展
实际案例：
- 资产分析和支出分析页面看起来相似
- 但后台：一个用存储过程，一个用 Java Service 层
- 数据获取：一个实时查询，一个缓存结果
- 重构时发现无法统一优化
解决方案：
- ✅ 每个功能完成后，简要 Review 实现代码
- ✅ 检查是否遵循了已有的架构模式
- ✅ 相似功能应该用相似的实现方式
- ✅ 在 CLAUDE.md 中明确架构决策（如"聚合用存储过程"）
错误 5：.gitignore 配置不当导致敏感信息泄露
问题表现：
- 敏感信息（数据库密码、API 密钥）被提交到 Git
- Claude 在 commit message 中暴露敏感信息
- 需要用 git filter-branch 清理历史记录（复杂且危险）
实际案例：
- 初期没有配置
.gitignore，backend/.env文件被提交 - 文件包含：数据库密码、邮件服务器凭证
- Claude 生成的 commit message："Add database config with password mysql123"
- 发现后需要：删除历史提交、重新生成密钥、强制推送
解决方案：
- ✅ 项目初始化时立即配置
.gitignore - ✅ 在 CLAUDE.md 明确标注："NEVER commit backend/.env"
- ✅ 使用 pre-commit hook 检查敏感文件
- ✅ 定期审查 commit message，避免暴露敏感信息
- ✅ 使用
/git-commit-pushskill 自动生成 commit message（可人工审核）
核心教训：
Claude Code 的效率高度依赖于良好的项目管理习惯。懒惰的前期准备会在后期加倍偿还。
