AI编程企业级实战

本节：第1节：一个人的架构师，Claude Code是你的团队

下一节：第2节：规范驱动开发SDD，让AI永远在轨道上

我们先想清楚几个关键问题：产品需求由谁定义，架构设计由谁拍板，测试回归由谁兜底，部署运维由谁负责？

过去，这些事情通常由产品经理、架构师、测试团队和运维团队分别承担。现在，当我们有了 Claude Code，你就要成为这些工作的总负责人。

想把这个工具真正用好，第一步不是学更多提示词，而是先完成角色切换。不要把 Claude Code 当成一个“只会写代码”的工具，它也可以是架构师、产品经理、测试专家、运维专家。关键不在工具本身，而在于你能不能把它真正调动起来。

为什么同样的工具，有的人用得特别好？

刚拿到 Claude Code 时，很多人会直接让它“设计系统架构”。结果往往是拿到一个过度设计的微服务方案。

这不一定是 AI 的问题，更常见的原因是：我们没有给它足够的约束和上下文。

后来我花了一些时间，把产品边界、架构约束和技术规范都想清楚，整理进 CLAUDE.md，再喂给它。第二天，同样的任务，输出质量就完全不一样了。

原因很简单。你的描述一旦模糊，AI 就只能猜你想要什么架构、猜你真正的意图、猜你默认的标准。每多猜一次，就多一层偏差。

而当你给出的上下文足够清晰，它就不需要再猜，输出质量自然会发生质变。

所以，这里先建立第一个认知：你想得越清楚，它做得越准确；你越模糊，它越容易跑偏。真正的瓶颈，往往不在 AI 的能力上，而在你的思考质量上。

你做决策，它做执行

如果只用一句话来总结，那就是：

你是架构师，Claude Code 是你的工程团队。

一个架构师每天在做什么？

• 不一定亲自写业务代码，但要决定系统最终长什么样。

• 要定方向，明确什么该做，什么不该做。

• 要做取舍，面对分歧时拍板选 A 还是选 B。

• 要定标准，明确代码怎么写、接口怎么定义、出错后怎么处理。

• 要做验收，判断团队交付的结果是不是你真正想要的。

来看两个场景

场景 1

请帮我用 Spring Boot 实现一个模型提供商管理的 CRUD 接口。

场景 2

按照 CLAUDE.md 中的接口规范，实现提供商 CRUD 接口：

1. 使用 MyBatis-Plus。

2. 错误码按规范定义。

3. 连接性测试需要区分异常类型：2001 表示网络超时，2002 表示认证失败，2003 表示模型不存在。

4. 不需要使用工厂模式，尽量用最简单的方式编写。

同样是一个 AI，拿到这两套指令，输出质量却完全不是一回事。第二种方案给出的结果，结构更完整，错误码更明确，依赖管理更清晰，也考虑了连接性测试，这才更像一个成熟项目该有的样子。

当这个工作框架建立起来后，你的核心任务就不再只是“写代码”，而是做决策：决定什么该做，什么不该做；决定用什么方式做；决定做到什么标准，才算 Claude Code 交付合格。

这是不是意味着我们不需要懂技术了？

恰恰相反。

你越想把 Claude Code 用到位，越需要有足够的技术判断力。因为你必须能够判断它给出的结果到底是好是坏，知道哪些方案靠谱，哪些只是“看起来能跑”。

如果你不了解技术细节，就很难提出精准的任务描述，也很难做出有效验收。技术能力，仍然是你扮演“架构师”这个角色的前提。

很多人谈 AI 提效，关注的是“写代码快了多少”。但更深的变化，其实不是速度，而是精力分配。

做一个系统时，大量时间并不花在创造新功能上，而是花在修低级 bug、反复 review、补测试、写文档这些又碎又重的工作上。AI 接手这部分之后，我们才能把更多精力真正集中到架构设计和关键决策上。

具体怎么分工？

可以把工作简单分成三层：

1. 必须由你负责的事。比如产品边界、架构决策、技术取舍、跨模块一致性。是否要做知识库，采用微服务还是单体，线程池参数怎么设，这些可以让 Claude Code 给出方案对比，但最后拍板的人必须是你。

2. 可以让 AI 完成、由你验收的事。比如业务代码、接口开发、前端页面、测试用例、文档编写。这部分通常工作量最大，但前提是你要把目标、约束和验收标准说清楚。

3. 可以交给 AI 直接处理的事。比如代码格式化、样板代码、简单重构、启动脚本。这些工作你只需要快速过一遍，确认没有问题即可。

还有一点很重要。

有时候，我们一开始并没有完整思路，比如在业务开发前，不确定该先准备哪些基础组件。这种情况下，也不必非得等自己全想明白再开始。你完全可以先让 Claude Code 帮你梳理思路、列出方案，再由你来判断和取舍。

实操：怎么检查 Claude Code 写出来的代码？

假设你让 Claude Code 实现“删除模型提供商”的接口，你给出的指令是：

实现删除模型提供商的接口，路径 DELETE /api/v1/providers/{id}，删除前检查是否有 Agent 正在使用该提供商，如果有则拒绝删除。

Claude Code 很快就给了代码。核心思路通常只有三步：查是否存在、查是否被引用、执行删除，BizException 再由 GlobalExceptionHandler 统一拦截并返回对应错误码。

这时候，我们可以用一个很实用的“三步检查法”。

第一步：查意图

先看它做的是不是你真正让它做的。

你打开代码，发现它确实实现了删除接口和关联检查，但又额外做了两件事：加了一个软删除机制，也就是不做物理删除，而是标记 deleted=true；还补了一个操作日志记录。

软删除是不是合理？也许合理。操作日志要不要？也许也有价值。

但问题在于，这不是你当前的要求。它擅自扩大了实现范围。这次看起来可能还好，下次它也可能“顺手”加进一些并不合适的设计。

所以第一步的结论很简单：如果功能做多了，就要么删掉，要么先确认，再决定是否保留。

第二步：查质量

再看风格、规范和一致性。

比如你会发现，检查关联的方法被命名为 checkProviderUsage，但项目里其他类似方法都叫 validateXxxBeforeDelete。又比如，其他接口都返回 Result，它这里却直接返回了 ResponseEntity。

这类问题不一定是 bug，功能本身也许没有错，但它会破坏整个项目的风格统一。时间一长，每个模块一套写法，维护成本就会越来越高。

第三步：查边界

最后看错误处理、异常分支和潜在风险。

例如，它虽然实现了“有 Agent 在使用就拒绝删除”，但没有考虑并发场景：如果检查通过后、真正删除前，刚好有新的 Agent 绑定了这个提供商怎么办？

再比如，传入的 id 不存在时，它抛出的可能是 500，而不是更合理的 404。

这些问题，往往不是主流程里最显眼的部分，但恰恰最容易在真实项目中埋雷。

好消息是，这类边界排查其实也很适合继续交给 Claude Code 去做。你完全可以让它基于现有实现，继续自查异常分支、并发问题和一致性风险。它在这类细节检查上，往往比人更稳定，也不会因为疲劳而漏项。

说到底，Claude Code 不是来替你少思考的，而是来放大你的判断力和执行力。你越像一个架构师去使用它，它就越像一个真正的团队为你工作。