说实话，我第一次翻到 Spring AI 的源码时，第一反应不是“好强大”，而是“好家伙，这自动配置居然藏了这么多层”。Spring AI 作为一套把大模型能力接入 Spring 生态的统一方案，它的自动配置架构几乎是整个框架的门面：你往项目里塞一个spring-ai-starter-model-xxx依赖，再加几行application.yml，然后就能在 Service 里直接注入ChatClient或ChatModel。中间发生了什么，很多人是一头雾水的。这篇文章想把这层迷雾拆开，从加载机制、条件装配、属性绑定到扩展钩子，把 Spring AI 自动配置架构的脉络完整过一遍。我的目标是让一个只写过 Spring Boot 业务代码的开发者，也能用自己的话解释清楚“为什么加个依赖就有 Bean 可用”。文章不牵扯到具体商业服务的接口差异，只关注框架层的工作原理，适合正在集成大模型、准备封装私有 AI 中间件，或者单纯被自动配置异常折磨过的同学。
1. 自动配置架构到底在解决什么问题
1.1 从手动搭建到自动装配的痛点迁移
先说一个背景。Spring AI 并不是第一个做“AI 客户端封装”的框架，但是在 Spring 系项目里，它确实把“接入大模型”的门槛降到了最低。早期接入一个模型服务商，通常要做这些事：先引入一个 HTTP 客户端库，然后手动写一个配置类，把 API Key 读进来，设置超时、代理、连接池，再自己封装请求参数、处理流式响应、处理 JSON 结构，最后还要把异常统一翻译成业务异常。这一步做完，只是拿到一个能调模型的底层客户端。等你要做 RAG，又要去接向量数据库；要做 Agent，又要接工具调用协议；要做链路追踪，还得手动埋点。每一层都是繁琐的样板代码，而且每个服务商的协议都略有差异，接口风格、Error Code、鉴权方式、流式格式各不相同，复用性极差。
Spring AI 自动配置架构的核心价值，就是把这些重复劳动做成了“约定优于配置”的标准流程。它不是简单地把 Bean 提前创建好，而是把整个生命周期管理起来：什么时候创建、什么时候不创建、需要哪些前置条件、属性从哪个配置文件读、怎么给使用者留出覆盖口子。这一整套机制，才是自动配置架构真正值得学习的地方。
我看很多人在调试 Spring AI 问题时，会跑去问“为什么我的配置没生效”“为什么换了服务商没反应”“为什么明明有 Key 却说没认证”。这些问题一大半不是模型服务商的问题，而是没搞懂 Spring Boot 自动配置的加载规则。Spring AI 的自动配置再特殊，它本质上也是 Spring Boot 自动配置体系里的一个成员，遵循的是一套已经存在了十几年的机制。所以这篇文章会稍微花些篇幅讲底层机制，再回到 Spring AI 本身的实现上，这样你排查问题就有了完整的知识地图。
1.2 自动配置在 Spring AI 里的定位
搞清楚定位很重要。Spring AI 做的不只是“帮你 new 一个客户端”，而是帮你维护了一套完整的模型接入抽象。自动配置在这套体系里承担四个职责：
第一，根据 classpath 里有没有对应依赖，决定要不要装配某个模块。这个对应的是 Spring Boot 里最常见的@ConditionalOnClass思路。你有spring-ai-starter-model-xxx的 jar，classpath 里就有那个服务商的 SDK 类，自动配置才会生效。
第二，把外部配置映射成结构化的属性对象。你写的spring.ai.xxx.api-key、spring.ai.xxx.chat.options.model这些配置，在自动配置启动时会被绑定到对应的配置属性类上，再传给客户端构造器。
第三，组装一条完整的 Bean 依赖链。比如聊天模型不只是底层 HTTP 客户端，它可能还牵扯到 RetryTemplate、ObservationRegistry、ToolCallingManager、模型选项解析等一大堆依赖。自动配置负责把这些组合成一个健壮可用的ChatModel。
第四，提供覆盖和扩展点。Spring Boot 的自动配置设计哲学是“可覆盖”，Spring AI 同样继承了这一点，比如通过@ConditionalOnMissingBean来保证你自定义的 Bean 优先于默认装配。
明白了这四个职责，你会发现后面所有架构细节都能对号入座。
2. 架构的五个关键层次
2.1 加载层：自动配置从哪里来
Spring AI 的自动配置加载机制，和标准 Spring Boot 自动配置是完全一致的。Spring Boot 在启动时有一个专门的加载阶段，会扫描META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports文件，把所有注册的自动配置类拉进候选列表。老版本也有用META-INF/spring.factories的，但新版都在迁移到AutoConfiguration.imports这种更清晰的方式。
这个文件里通常列着一串类名，比如你会看到：
com.xxx.spring.ai.autoconfigure.AiAutoConfiguration com.xxx.spring.ai.autoconfigure.ModelAutoConfiguration com.xxx.spring.ai.autoconfigure.RetryAutoConfiguration com.xxx.spring.ai.autoconfigure.ObservationAutoConfiguration这一层是入口，但不要以为加载了就会装配。加载只代表“进入候选池”，最终是否真的创建 Bean，还要由下一层的条件判断决定。这也解释了为什么你在 IDEA 里展开依赖，看到某个自动配置类存在，但运行时 ApplicationContext 里就是找不到对应的 Bean——大概率是条件不满足。
Spring AI 的 starter 依赖通常还会传递进来相应的自动配置模块，比如你把spring-ai-starter-model-xxx拉进来，它里面就包含spring-ai-autoconfigure-xxx。如果你在做二次封装，要注意别把这两个依赖搞混：starter 侧面对使用者，autoconfigure 侧才真正承载自动配置逻辑。
2.2 条件层：条件组合决定装配结果
这是自动配置架构最核心也是最容易出问题的地方。Spring Boot 提供了一系列@Conditional注解，Spring AI 大量使用它们来构建“如果满足某条件，则装配”的规则。常见的有：
@ConditionalOnClass：classpath 里存在指定类时生效。@ConditionalOnMissingClass：classpath 里不存在指定类时生效。@ConditionalOnBean：容器中存在指定 Bean 时才生效。@ConditionalOnMissingBean：容器中不存在指定 Bean 时才生效，这个通常用来给自定义实现留口子。@ConditionalOnProperty：配置项满足特定值时才生效。
组合规则很讲究。比如一个模型自动配置类会同时标注@ConditionalOnClass和@ConditionalOnProperty。前者保证“引入的依赖对得上”，后者保证“使用者确实在配置里声明了这个模型”。两个条件都满足，自动配置类才会执行。
这里有个容易踩坑的点：@ConditionalOnMissingBean判断的是“当前容器里还没有这个 Bean”，但自动配置类之间的执行顺序会影响判断结果。Spring AI 底层模块和上层模块的自动配置顺序如果不注意，可能导致本该被自定义 Bean 覆盖的配置又创建了一个默认 Bean。排查思路不是盯某一个注解，而是要把所有自动配置类的@AutoConfiguration顺序和条件组合放在一起看。
2.3 绑定层：外部化配置与属性对象映射
Spring AI 的自动配置能这么“听话”，很大程度依赖于 Spring Boot 的配置属性绑定。配置属性类一般长这样：
@ConfigurationProperties(prefix = "spring.ai.xxx") public class ModelProperties { private String apiKey; private ChatOptions options = new ChatOptions(); // getter / setter }Spring Boot 在启动时会扫描@ConfigurationProperties注解，把application.yml里对应前缀的属性值通过 setter 绑定进去。Spring AI 在这个基础上又做了一层封装，把不同模型类型的属性拆成ChatProperties、EmbeddingProperties、ImageProperties等若干个子项，每个子项里再包含模型名称、请求参数、代理设置等细分字段。
这个分层设计的价值在于：不同模型的配置虽然长得像，但细节字段天差地别。比如聊天模型关心temperature、topP、maxTokens，向量化模型更关心dimensions和batchSize。如果全部堆在一个大 Properties 类里，后期维护会非常痛苦。拆开放，每个自动配置类只消费它关心的属性子集，职责边界就清晰了。
绑定层还承担一个重要的安全职责：API Key 的加载。建议不要明文写在配置文件里，而是通过环境变量或密钥管理服务注入。Spring 的宽松绑定规则允许你在application.yml里写spring.ai.xxx.api-key: ${MODEL_API_KEY}，这样密钥只存在于运行环境中。
2.4 组装层：从客户端到高层抽象
加载、条件、绑定都完成之后，真正的组装逻辑在自动配置类的@Bean方法里。组装层做几件事：
第一，创建底层 HTTP 客户端。这个客户端不一定是你直接用的，它会被封装到服务商 SDK 里。比如某个服务商的 SDK 需要一个ApiClient，你需要在自动配置里把 API Key、超时、Base URL 传进去，构造一个可用的客户端实例。
第二，创建统一抽象的模型 Bean。Spring AI 抽象出ChatModel、EmbeddingModel、ImageModel等接口，自动配置会把刚才创建的底层 SDK 客户端包装成这些接口的实现。你业务代码里只依赖接口，不依赖具体 SDK。
第三，做增强组合。Spring AI 的模型 Bean 不是“裸”客户端，它会包上重试机制、可观测性、缓存等横切逻辑。这些横切组件可能是独立的 AutoConfiguration 提供的，因此自动配置类做组装时不能假设所有依赖都是默认存在的，要通过方法参数自动注入，或者结合ObjectProvider做可选依赖处理。
第四，把 Bean 注册进容器。这一步表面上只是个return，但实质上决定了 Bean 的类型、作用域和初始化时机。Spring AI 默认大部分 Bean 是单例，这对模型客户端这类重量级对象来说是很正确的设计——避免每次都创建连接池。
2.5 扩展层：留给使用者的钩子
很多框架的问题是“要么全自动，要么全手动”，缺少中间地带。Spring AI 自动配置架构在扩展性上做了不少努力，给你留下了几个层次的钩子：
配置文件级扩展：通过修改application.yml，覆盖模型参数、超时、代理等配置。这是最轻量的扩展。
自定义 Bean 覆盖：在某个@Configuration里定义同类型的 Bean，利用@ConditionalOnMissingBean让容器优先使用你的实现。比如你不想用默认的ChatClient，就自己声明一个ChatClient类型的 Bean，默认自动配置就会退让。
自定义自动配置类：如果你在封装公司内部的 AI 平台，可以在自己的 starter 里写一个自动配置类，通过AutoConfiguration.imports注册，然后定义你自己专有的模型 Bean。这个属于架构级扩展，前面的加载层、条件层、绑定层你都可以复用。
自定义属性项：Spring AI 也允许你在自己的配置类里追加自定义属性前缀，比如spring.ai.xxx.internal.timeout，通过配置属性类绑定后传给自己的 Bean。这样使用者还是只需要改配置文件，不需要动 Java 代码。
这五个层次串起来，才是一个完整的自动配置架构，缺一层的框架用起来都会感到明显的“别扭”。
3. 核心模块的自动配置细节
3.1 大模型对话能力：ChatModel 与 ChatClient
模型对话是最常用的能力，自动配置的粒度也最细。Spring AI 把对话能力拆成几个不同的接口：ChatModel是基础的非流式对话接口，StreamingChatModel处理流式返回，ChatClient则是一种更高层的、面向开发者的建造者式接口，它封装了 Prompt、消息历史、工具调用、参数覆盖等细节。
自动配置类会分别处理这些接口。基本流程是：先创建底层底层模型客户端，再创建ChatModel的实现，然后通过一个ChatClient.Builder来创建ChatClient。所以你在一个标准项目里注入了ChatClient，背后其实是依赖了一整条链：配置属性 -> 底层 SDK 客户端 ->ChatModel->ChatClient.Builder->ChatClient。
这里值得注意的细节是ChatModel和ChatClient是两种不同抽象。ChatModel更靠近模型本身，讲究的是“把请求发出去，拿到结果”；ChatClient更靠近开发者使用体验，讲究的是“我这个对话应该怎么组织”。自动配置里两者都给你装配好，就是为了不同场景各取所需。如果业务代码里到处直接注入ChatClient，而不理解它跟ChatModel的关系，后面做底层切换时容易糊涂。
自定义扩展时，我建议优先覆盖ChatModel，而不是ChatClient。因为ChatClient通常是通过 Builder 模式构建的，覆盖它会导致整个链路上的默认组装逻辑失效，你不得不自己把 Builder 再配一遍。而只覆盖ChatModel，Spring AI 默认的ChatClient自动配置仍会正常组装。
3.2 向量化与向量库：EmbeddingModel 与 VectorStore
RAG 场景下最核心的组件是EmbeddingModel，它负责把文本变成向量。Spring AI 自动配置同样会为它提供 Bean。向量化模型通常和聊天模型是两套服务，所以有独立的配置前缀、独立的模型名称、独立的底层客户端。我们在做配置时，不要想当然地认为“我配好了聊天模型的 Key，向量化也自动有了”。对应的 Key 和模型名都要单独配置，只不过接入的是同一个服务商时，API Key 往往可以复用。
VectorStore负责向量数据的存和检索。它不一定要单独配置，取决于你用的是内存实现还是外部向量数据库。Spring AI 默认提供一种简单的内存 VectorStore，适合本地验证，它通常不需要额外配置。但如果要接真正的向量数据库，就要引入对应 starter，并提供数据库连接参数。自动配置会在检测到相关依赖后，把EmbeddingModel注入到VectorStore实现里，形成一个完整链路。
组装链路上有个常见误操作：手动创建了一个EmbeddingModel的 Bean，却没有把它传给VectorStore，导致自动配置生成的VectorStore用了默认EmbeddingModel，检索效果对不上。出现这种问题时要先看 Bean 定义，而不是急着调参。
3.3 多模态与语音处理模块
Spring AI 的多模态能力也包括图像理解等模块。它们同样是独立的自动配置单元，接口侧抽象为ImageModel等。因为模型和协议不同，它们的配置属性、请求参数、响应结构都跟对话模型不在同一个属性命名空间下，同一套spring.ai.xxx.chat.options并不能复用。自动配置类会独立处理各自的属性绑定。
语音相关的模块，比如语音转文字、文字转语音，在 Spring AI 生态里也是按服务商模块拆分的。实现层的客户端构造方式与聊天模型几乎一样：读取配置，创建底层客户端，包一层抽象接口，注册为 Bean。多模态场景最复杂的往往不是 Bean 装配，而是 Bean 的区分。如果你的项目里同时用到了图像理解和对话模型，两者的 Bean 类型不同，不会冲突。但如果你接了两个服务商，并且都实现了同一个ChatModel接口，容器里就会存在多个同类型 Bean，自动配置的@ConditionalOnMissingBean就会失效，这时必须用@Qualifier明确指明要注入哪个。
我不建议用同一种类型接两个服务商，除非你做了应用层的主备或轮询策略。多模型共存更适合通过为每个服务商定义不同的Bean名称 + 自定义服务抽象来实现，让应用代码依赖你自己的服务接口，而不是直接依赖ChatModel。
3.4 可观测性、重试与缓存
这部分属于 Spring AI 自动配置架构里的“横切能力”，很容易被忽略，但真正出问题救你命的就是它们。
可观测性方面，Spring AI 借助了 Spring 的可观测设施，自动配置会注册观测注册表和对应的观测器。一旦生效，每次模型调用都会产生对应的 Span，你可以把它接入链路追踪系统。这样线上出问题时，就能看到每次请求调了哪个模型、耗时多少、Token 消耗多少。
重试机制则是通过重试模板实现的。自动配置会根据属性配置创建重试器，把它注入到模型客户端中。网络抖动、限流、临时故障是大模型服务的高发问题，没有重试机制，你的线上接口会时不时地冒出一堆超时异常。但重试也要小心，不能无限重试非幂等请求，否则可能造成重复扣费和重复写入。配置重试次数、退避策略时要结合业务场景。
缓存也是自动配置的一环。Spring AI 在自动配置中会为某些模型调用提供缓存支持，但默认不一定全开。如果你在做一个内容基本固定的问答系统，合理使用缓存能省下大量模型调用成本。注意缓存键的设计要包含模型名、参数、用户请求内容，否则容易串答案。
3.5 供应商切换和多模型共存
自动配置天然支持通过引入不同依赖来切换底层服务商，这一点是 Spring AI 干得比较聪明的地方。你不用改业务代码，只需要换 starter、改配置，Bean 的实现就会跟着变。因为业务代码依赖的是ChatModel、ChatClient这样的抽象接口，底层换了实现，上面的调用逻辑完全感受不到。
不过这句话要加个前提：你在业务代码里不能使用某个服务商特有的数据结构。比如把响应当成了某个 SDK 的专门类型，那底层一换，编译就过不去了。正确做法是一开始就只用 Spring AI 提供的通用类型，避免把细节泄漏出来。
多模型共存时，自动配置并不是为“同时挂两个服务商”设计的，它默认是“每个类型最多一个默认 Bean”。要同时用两家，就得老老实实自定义配置。一种比较省事的方案：只依赖其中一个服务商的 starter，另一个服务商通过手动定义 Bean 来接入，业务代码统一包装。这样既保留了自动配置的主通道，又能扩展出备选通道，不至于为了一个备选供应商把整套自动配置全关掉。
4. 组件装配与运行时的完整推演
4.1 启动阶段发生了什么
这里咱们做一次从应用启动到拿到ChatClient的完整推演。
第一步，SpringApplication 启动，Spring Boot 开始加载配置。环境对象（Environment）已经解析完application.yml，属性数据就绪，但还没有绑定到任何配置属性类上。
第二步，自动配置处理入口开始工作。Spring Boot 扫描AutoConfiguration.imports，找到 Spring AI 相关的所有自动配置类，并对它们做排序。排序不只是看类名，还会根据@AutoConfiguration上声明的依赖去决定先后。正因为有这一步，某些配置类才能感知到别的配置类创建的 Bean。
第三步，进入条件评估阶段。每个自动配置类上的条件注解被依次检查。以某个模型的自动配置为例，Spring Boot 会检查@ConditionalOnClass对应的 SDK 类是否存在，检查@ConditionalOnProperty对应的配置前缀是否匹配。如果失败了，这个类体内的所有@Bean方法都会被跳过，不会注册任何 Bean。
第四步，条件通过的配置类开始实例化。For example，模型自动配置类会先构造配置属性对象，然后加载 API Key，创建底层 HTTP 客户端，再创建模型实现，最后把实现注册到容器。如果配置类里依赖了重试器、观测注册表这些横切组件，它们会通过方法参数自动装配进来。
第五步，所有 Bean 创建完毕后，ApplicationContext刷新完成。此时你去Service里注入ChatClient，Spring 会直接从容器里查找对应 Bean 返回。如果ChatClient依赖ChatModel，Spring 会递归地完成依赖解析，确保整个对象图完整。
这五步描述看起来简单，但每一步背后都有非常多的判断逻辑，实际排查问题时的表现也会复杂得多。比如一个自动配置类表面上条件通过，但在创建 Bean 时抛了异常，Spring Boot 会把这个异常包装成启动失败信息。这时不要只看“Bean 创建失败”那一行，要去翻导致创建失败的根因，通常隐藏在 Caused by 里。
4.2 运行时依赖是怎么注入的
很多人对ObjectProvider这种方式不熟，它恰恰是 Spring AI 自动配置里非常常见的依赖注入技巧。试想一个自动配置类需要给模型客户端装上重试器，但重试器可不是必须存在的，如果使用者没有引入相关依赖，你总不能让它启动就报错。Spring AI 的做法是接收一个ObjectProvider<RetryTemplate>，然后在构造时判断“如果里面没有对象，我就用默认实现；如果有，就用用户自定义的”。
这招总共解决了两类问题：一是解决可选依赖的装配，二是解决自定义优先级。默认自动配置永远把“使用者有没有给”作为最高判断规范。你部署的时候会发现，覆盖一个 Spring AI 默认 Bean，不需要修改框架源码，更不需要修改依赖，只要在你的配置类里定义同类型 Bean。因为自动配置外层往往有@ConditionalOnMissingBean，看到容器里已经有该类型 Bean，它就会自动放弃注册。
但这里有一点特别容易犯迷糊：@ConditionalOnMissingBean的评估时机是在 Bean 定义注册阶段，而不是 Bean 实例化阶段。如果你的自定义 Bean 定义晚于自动配置类注册，自动配置可能就差那么一点点顺序。
4.3 为什么推荐把模型接入封装在应用层
Spring AI 已经帮你封装了模型接入，但我仍然建议在业务项目里再包一层服务接口。原因和自动配置架构本身关系不大，而是项目维护的问题。
想象一下你的订单服务、商品服务、客服机器人都要调模型。如果大家直接注入ChatClient，prompt 的组织逻辑、出场参数、缓存策略、异常处理散落在各个地方。换了新模型、调 prompt 模板、加统一审计时，你会非常痛苦。更好的做法是定义一个Assistant之类的应用服务，把 prompt 模板、会话历史、工具调用、模型参数组装都收拢到一个地方。Controller 和其他 Service 只依赖这个应用服务，完全不知道底层调的是什么模型。
这个封装还有一个隐藏好处：它让你的自动配置架构更容易升级。Spring AI 版本升级时，底层抽象可能做出微调，只要你应用层的封装没被穿透，升级风险就可控。
5. 自动配置的验证、排障与自定义拓展
5.1 学会读自动配置报告
遇到自动配置不生效，第一件事不是改代码，而是先看自动配置报告。Spring Boot 提供了两个很有用的方式：一个是启动时加--debug，另一个是在配置里开启日志级别，把自动配置相关的日志调到 DEBUG。启动日志里会输出一个“自动配置报告”，其中列出了每个自动配置类的状态：CONDITION EVALUATION DELTA、MATCHED、NOT MATCHED等。核心就是看看你的模型自动配置类到底是“匹配”了还是“未匹配”。
如果状态是NOT MATCHED，报告里通常还会给出没匹配的具体原因。比如@ConditionalOnClass找不到某个类，那大概率是缺依赖；@ConditionalOnProperty没匹配，那就是配置前缀写错了，或者配置值不对。
另外一个排查技巧是用 Actuator 的/actuator/beans端点直接查容器里有没有对应 Bean。如果你引入依赖时根本不产生任何 Bean，那问题通常出在条件匹配；如果 Bean 存在但使用时报错，问题大多出在参数配置或底层客户端连接。
5.2 常见踩坑点速查
总结一下我见过的高频问题，做成一张速查表：
| 现象 | 常见原因 | 排查方向 |
|---|---|---|
启动报找不到ChatModel类型的 Bean | 自动配置条件未满足，通常是依赖没引入或配置前缀不对 | 查自动配置报告，确认是哪个条件失败 |
| 配置了 API Key 但仍报鉴权失败 | API Key 没被正确绑定，或环境变量没注入 | 检查配置属性绑定是否成功，确认配置键名拼写 |
| 换模型服务商后原有配置不生效 | 新旧属性前缀不一致，部分属性残留导致误导 | 清理旧属性，比对目标服务商的属性文档 |
| 自定义 Bean 覆盖失败 | 还没有完全掌握自动配置顺序 | 确认自定义 Bean 的注册时机，必要时禁用默认自动配置 |
| 多个同类型模型 Bean 导致注入歧义 | 多服务商共存 | 使用@Qualifier，或做应用层封装隔离 |
| 流式接口调用超时频繁 | 重试和超时配置缺失 | 在配置项里补上连接超时、请求超时和重试策略 |
这个表覆盖的场景是我在团队里实际被问过较多的类型，很多问题看着千奇百怪，根因往往都落在自动配置那几个条件上。
5.3 怎么优雅地做自定义扩展
如果默认自动配置不能满足，你首先想的不应该是“把它禁用”，而是“在它之上加东西”。禁用一个自动配置类虽然直接，但你会失去整个默认组装链路。比如你只是想把某个底层 HTTP Client 的拦截器改一下，完全可以通过自定义一个BeanPostProcessor，在 Bean 实例化后做扩展，而不需要重写整套自动配置。
另一个更常用的自定义方式是覆盖属性来源。Spring Boot 支持配置文件的优先级，你可以把 AI 相关配置写在后加载的外部配置中心里，覆盖应用内置的默认值。这样环境之间切换时，只需要调整外部配置，应用代码和本地配置文件都没必要动。
如果确实需要写自己的自动配置类，我建议遵循这套模板：
@AutoConfiguration @ConditionalOnClass(name = "com.example.MyAIModule") @ConditionalOnProperty(prefix = "spring.ai.custom", name = "enabled", havingValue = "true") @EnableConfigurationProperties(CustomAIProperties.class) public class CustomAIAutoConfiguration { @Bean @ConditionalOnMissingBean public MyService myService(CustomAIProperties properties, ObjectProvider<SomeDependency> dependencyProvider) { SomeDependency dependency = dependencyProvider.getIfAvailable(SomeDependency::new); return new MyService(properties, dependency); } }这个模板的思路和 Spring AI 内部一致：条件判断、属性绑定、默认 Bean、可选依赖注入。写完以后，在META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports里登记一下类名，启动时它就会生效。
我个人在实际操作中的体会是：自定义自动配置最容易出错的反而不是代码逻辑，而是条件写得太宽或太窄。太宽会导致不应该装配的模块被装配，太窄又会导致条件永远不满足。条件注解的取值要结合项目实际使用场景，尽量贴合“你有某个依赖，并且开启了对应配置项”这种组合判断，而不是单纯依赖某一个条件。
最后再分享一个小技巧。当你排查 Spring AI 自动配置问题时，不要只盯异常堆栈，试着在启动日志里搜索Negative matches或Positive matches。这两个区块能帮你直接看到“Spring Boot 眼里你的项目状态”。看到某个自动配置类的条件差在哪里，你心里就有数了。Spring AI 的自动配置架构整体不复杂，复杂性只在于它把 Spring Boot 的机制用得比较充分。一旦你把加载、条件、绑定、组装、扩展这条链路打通，后面再看任何模型接入，都会觉得清晰得多。
智能人工双核分布式阅卷系统（各科通用版）V1.0)
