在 Angular 项目中使用 claude code 生成依赖注入代码的合理性

最近在给一个大型 Angular 项目做技术债治理，我统计了一下，整个代码库里光是 @Injectable() 修饰的服务类就有 440 多个，如果再算上工厂函数、InjectionToken、各种自定义 Provider，跟依赖注入直接相关的样板代码每周还在以 30-50 行的速度增涨。团队里有同事提议：这些机械性内容干脆交给 Claude Code 自动生成算了，PR 里还能少写几行。

我们真的这样试了一个迭代周期。结论不是简单的“好用”或“不好用”，而是Claude Code 在 Angular 依赖注入场景下的表现，恰恰暴露出目前 AI 辅助编码最容易忽略的“合理性边界”，看起来写得很对，但把服务悄悄地放到错误的注入器层级，或者在模块懒加载边界上破坏 Tree-shaking，这在 Code Review 时极难一眼发现。所以这篇文章不是一篇工具教程，而是把我自己踩过的坑、做过的对比，以及对“是否应该用 Claude Code 生成 DI 代码”这个问题的分层判断逻辑，完整地拆出来给你。

一、先给核心判断：Claude Code 不是一个“依赖注入架构师”

我先把我的整体判断放在最前面，因为很多团队在引入 AI 工具时，最大的问题是角色定位错误。

Claude Code（以及在它背后的大语言模型）在生成 Angular DI 代码这件事上，真正擅长的角色是“高效打字员”，而不是“架构决策者”。它可以准确完成以下工作：

1. 根据你给出的接口或类型定义，生成带有正确构造函数注入的 Service 骨架；
2. 按你指定的 providedIn 范围生成 @Injectable() 装饰器；
3. 生成符合 NgModule 规范的 provider 数组；
4. 在简单场景下生成 Factory Provider、Value Provider、Class Provider 的代码块。

但它不擅长的是：

• 判断一个服务到底该放在 root 注入器，还是放在某个 Feature 模块的 providers 里；
• 推断某个服务是否必须保持局部状态、不能单例化；
• 理解现有应用的注入器层次结构，并做出跨模块的注入安全决策；
• 判断 Factory Provider 里的初始化逻辑是否会导致不必要的副作用。

而偏偏在大型 Angular 项目中，DI 的真正难度从来不是写 constructor(private http: HttpClient) {} 那一行，而是上面这些“归属层级、作用域边界、副作用管理、Tree-shaking 兼容性”的架构决策。这就导致一个很隐蔽的风险：Claude Code 生成的代码在静态检查、单元测试里都能过，甚至在开发环境下跑得很正常，但一旦涉及到懒加载模块初始化、路由守卫与 Resolver 的生命周期、微前端子应用间的隔离，错误才会暴露出来，而这种错误往往是线上事故中最难排查的一类。

所以，如果你问我“在 Angular 项目中使用 Claude Code 生成依赖注入代码合不合理”，我的回答是：只有在你明确划清“哪些是机械性编码、哪些是架构决策”的前提下，它才合理。 否则，你会得到一堆乍看正确、细看有毒的“高效垃圾”。

二、我们项目的真实背景：为什么先尝试用 AI 接管 DI 代码生成？

我先交代一下我们团队为什么会走这一步，这很重要，因为每个团队的动机不同，对“合理性”的评价标准也会完全不同。

我们维护的是一个超过 3 年的企业级 Angular 应用，包括：

• 核心业务套件（CRM、订单管理、供应链协作）
• 多个微前端子应用（通过 Module Federation 集成）
• 每个子应用内部又拆分成若干个懒加载 Feature Module
• 大量共享的 CoreModule 和 SharedModule
• 采用了“Facade Service + State Management + Data Service”三层架构

在这种架构下，依赖注入的复杂度体现在几个地方：

1. 每个数据实体基本都会对应一组服务：比如 OrderDataService、OrderFacadeService、OrderStateService；
2. 为兼容遗留模块和旧版 API，存在大量 Factory Provider：需要根据不同的 Feature Flag 动态切换实现；
3. 跨子应用共享服务必须严格遵守单例范围：有些服务必须在 root 单例，有些则必须在特定子应用内单例，一旦弄错，全局状态就毁了；
4. 团队长期处于高交付压力下：新功能迭代周期短，工程师经常在 PR 里为了快速实现，把 DI 配置简化处理，导致技术债累积。

在 2024 年底，我们开始在部分项目中尝试使用 Claude Code 辅助编码，主要场景包括生成组件骨架、编写单元测试、生成接口定义等，效果还不错。于是我们很自然地就想到，是否可以进一步用它来接管新 Service 的整套依赖注入定义，包括装饰器、Provider 配置、工厂函数等，以减少手写样板代码带来的不一致性和时间开销。

我们设置的试验方式是这样的：

• 试验范围：选取两个新开发的 Feature 模块，一个为“合同管理”（ContractFeature），一个为“供应商协同”（SupplierCollaboration）；
• 工作流：工程师先用自然语言描述服务需求，包括服务职责、所需依赖、应放置在哪个注入器层级、是否为单例等，然后让 Claude Code 生成完整 DI 代码；
• 质量评估：由团队内两名资深 Angular 开发者对所有生成代码进行 Review，标注出任何不符合架构规范的代码，并分类统计问题类型；
• 对比基准：同时统计过去 3 个月由人工编写的同等规模服务的 DI 错误率（主要来自 PR Review 中发现的问题）。

试验的结果数据，我在后面的章节会详细给出，但现在可以先说一句：错误率并没有像我预想的那样大幅下降，反而在一些深层架构问题上暴露得更集中。 而这正好催生了这篇文章的主题，合理性到底在哪里。

三、拆解一个最容易犯的误区：以为“生成 DI 代码”只是“生成装饰器和构造函数”

在深入分析之前，我想先纠正一个几乎所有 AI 辅助编码倡导者都会踩的误区，那就是把 Angular 的依赖注入等同于 @Injectable() + constructor() 的语法组合。

我用一个具体例子来说明。

假设我们要新建一个 ContractPriceCalculator 服务，用于根据合同的条款、历史价格、客户等级计算最终报价。在需求文档里，它是这样描述的：

该服务需要依赖 TaxRateService（全局单例），DiscountPolicyService（合同模块内部单例，不同合同模块实例状态无关），以及通过 CONTRACT_API_ENDPOINT InjectionToken 提供的接口地址。并且，在特定的灰度用户下，该服务应被替换成 AdvancedContractPriceCalculator。

对于人类架构师来说，这个需求需要做以下决策：

1. ContractPriceCalculator 本身应该放在哪个注入器层级？因为 DiscountPolicyService 是合同模块内单例，所以 ContractPriceCalculator 也应该作用在同一个合同模块注入器下，不能是 root 单例，否则它会引用错误的 DiscountPolicyService 实例。
2. CONTRACT_API_ENDPOINT 应该在哪里提供？如果这个 token 只在合同模块内使用，最好在合同模块的 providers 里提供，而不是在 root 里污染全局。
3. 灰度替换逻辑的正确实现：不能在 ContractPriceCalculator 的构造函数里直接请求 AdvancedContractPriceCalculator，因为那会形成循环依赖。正确做法是使用 Factory Provider 根据外部条件动态实例化，或者使用 useExisting 或 useClass 配合注入令牌。
4. 必须考虑 Tree-shaking 兼容性：如果 AdvancedContractPriceCalculator 是通过 providedIn: 'root' 提供的，但只在灰度用户下才会被使用，它可能在任何情况下都被打包进去，需要调整为 module 级 provider。

现在，我把同样的需求描述用自然语言输入给 Claude Code，生成的典型代码如下（简化版）：

// claude-code 生成（错误示例，仅展示问题）
import { Injectable, InjectionToken } from '@angular/core';
import { TaxRateService } from './tax-rate.service';
import { DiscountPolicyService } from './discount-policy.service';

export const CONTRACT_API_ENDPOINT = new InjectionToken<string>('CONTRACT_API_ENDPOINT');

@Injectable({
  providedIn: 'root'  // ❌ 问题1：应该在合同模块内部
})
export class ContractPriceCalculator {
  constructor(
    private taxRateService: TaxRateService,
    private discountPolicy: DiscountPolicyService, // ❌ 问题2：此处注入的可能是错误的实例
    @Inject(CONTRACT_API_ENDPOINT) private apiEndpoint: string
  ) {}
}

// 灰度替换的生成代码（错误）
@Injectable({
  providedIn: 'root'
})
export class AdvancedContractPriceCalculator extends ContractPriceCalculator {
  // ...
}

这份代码的问题清单：

• 问题 1：providedIn: 'root'。Claude Code 默认几乎所有服务都设成 root，这是一种“安全”的策略（保证任何地方都能注入到），但对合同模块内服务来说，这会导致 DiscountPolicyService 的注入指向全局实例而不是模块实例，如果全局不存在该服务，应用甚至会直接报 NullInjectorError。
• 问题 2：没有处理灰度替换。Claude Code 只是生成了两个独立的服务类，没有提供动态替换的 Provider 配置，也没有利用 InjectionToken 抽象。
• 问题 3：InjectionToken 定义放在了服务文件中。这会导致模块导入链路混乱，并且破坏单一职责原则。
• 问题 4：AdvancedContractPriceCalculator 继承了 ContractPriceCalculator，这本身不是 DI 问题，但它通过 providedIn: 'root' 声明，意味着即使灰度用户只有 5%，它也会被打包进主 bundle。

这些问题在 Code Review 中如果不够细致，很容易被忽略，尤其是当 Reviewer 同时在审查业务逻辑时。而这并不是 Claude Code“不会写 Angular”，恰恰相反，它生成的语法完全正确，但它缺乏对项目上下文中“注入器层级树”和“部署打包策略”的理解。

通过这些数据可以看到，Claude Code 在“语法正确”层面的表现无可挑剔，但在“架构合理”层面，它暴露出了明显的薄弱点。所以我想强调的第一个关键结论是：如果你只是把“生成 DI 代码”理解为生成几行 TypeScript 装饰器，那你会严重低估 DI 的复杂性，也会高估 Claude Code 在此处的合理性。

四、合理场景一：把 Claude Code 当作“标准化模板生成器”

虽然前面我一直在说问题，但我不认为 Claude Code 在 DI 生成里毫无价值。恰恰相反，在特定的约束下，它确实能省钱、省时间、降低低级错误。我们先来看第一个合理场景。

在我们团队中，有一类 Service 极度标准化，称为“Data Service”。它们的普遍特征是：

• 依赖仅限于 HttpClient 和一个对应的 API 端点 InjectionToken；
• 方法列表为标准的 CRUD：getList、getById、create、update、delete；
• 每个实体一个 Data Service，其结构高度一致；
• 它们永远在 root 注入器提供（因为数据访问层不需要和 UI 状态耦合）；
• 不参与任何 Factory Provider 或动态替换逻辑。

这种场景下，Claude Code 的生成合理度非常高。我只需要给出实体名称和 API 端点路径，它就能够生成一个完整的、符合我们代码规范的 Data Service，包括：

• 正确使用 providedIn: 'root'；
• 完整的 TypeScript 泛型类型推导；
• 统一的错误处理格式；
• 自动导入 HttpClient 和正确的依赖注入写法。

举一个实际案例：我们需要为“供应商资质文件”实体创建 SupplierCertificationDataService。我输入给 Claude Code 的提示是：

请为我生成一个 Angular Data Service 用于供应商资质文件，API 端点路径是 /api/supplier-certifications，遵循项目现有的 Data Service 模式，使用 HttpClient，提供 CRUD 方法，返回类型为 SupplierCertification 或 SupplierCertification[]。该服务在 root 注入器提供。

生成的代码如下（直接可用，无需手工修改）：

import { Injectable } from '@angular/core';
import { HttpClient } from '@angular/common/http';
import { Observable } from 'rxjs';
import { SupplierCertification } from '../models/supplier-certification.model';

@Injectable({
  providedIn: 'root'
})
export class SupplierCertificationDataService {
  private readonly apiUrl = '/api/supplier-certifications';

  constructor(private http: HttpClient) {}

  getList(): Observable<SupplierCertification[]> {
    return this.http.get<SupplierCertification[]>(this.apiUrl);
  }

  getById(id: string): Observable<SupplierCertification> {
    return this.http.get<SupplierCertification>(`${this.apiUrl}/${id}`);
  }

  create(data: Omit<SupplierCertification, 'id'>): Observable<SupplierCertification> {
    return this.http.post<SupplierCertification>(this.apiUrl, data);
  }

  update(id: string, data: Partial<SupplierCertification>): Observable<SupplierCertification> {
    return this.http.put<SupplierCertification>(`${this.apiUrl}/${id}`, data);
  }

  delete(id: string): Observable<void> {
    return this.http.delete<void>(`${this.apiUrl}/${id}`);
  }
}

这 40 行代码如果人工写，可能需要 3-5 分钟，还要额外检查类型导入、RxJS 引入等容易遗漏的细节。Claude Code 生成只需要 10 秒钟，而且质量几乎 100% 可靠。为什么？因为这是一个高度受限的、无架构决策的纯模板化场景。所有的“合理性”前提，注入器层级、服务生命周期、依赖关系，都是确定的，不存在可变的架构选择。

合理性的第一个判断标准：当 DI 代码生成中，所有架构决策都已经被规范或约定先置确定，只剩下机械性拼装时，Claude Code 是极其合理的工具。

更进一步的，如果团队内部已经有一套成熟的 Service 模板（例如通过 Angular Schematics 自定义过），你可以把模板写入 Claude Code 的项目记忆（Project Memory）中，让它完全复刻这套模板，保证生成的代码和手工编写在使用风格上零差异。

五、合理场景二：在原型验证阶段，用 AI 快速拼装“假服务”来驱动 UI 开发

第二个合理场景是我个人非常推崇的一种用法，也是在多个项目里验证过的：在 Angular 前端原型期（或者独立 UI 组件开发环境，如 Storybook 中），用 Claude Code 快速生成“假数据服务”来替代尚未就绪的后端依赖。

传统上，我们会为每个真实服务手写一个 Mock Service，例如 MockOrderService、MockUserService，并在 providers 里替换掉真实服务。这本身就包含很多重复代码。Claude Code 可以读取真实服务的接口定义（或者我们定义好的抽象类/InjectionToken），然后快速生成一个完整的 Mock 实现，包含模拟延迟、返回假数据等。

以我们的合同模块为例，在早期 UI 开发时，后端 API 还没完全 ready，我们需要一个 ContractService 来为组件提供可交互的假数据。我给 Claude Code 提供了真实 ContractService 的抽象类，让它生成对应的 Mock：

// 抽象类定义（人工提供）
export abstract class ContractService {
  abstract getContractList(): Observable<Contract[]>;
  abstract getContractDetail(id: string): Observable<Contract>;
}

// Claude Code 生成的 Mock（部分展示）
@Injectable()
export class MockContractService implements ContractService {
  private contracts: Contract[] = [
    { id: '1', title: '2024年度采购框架协议', status: 'ACTIVE', ... },
    { id: '2', title: '物流服务合同', status: 'DRAFT', ... },
  ];

  getContractList(): Observable<Contract[]> {
    return of(this.contracts).pipe(delay(800)); // 模拟网络延迟
  }

  getContractDetail(id: string): Observable<Contract> {
    const contract = this.contracts.find(c => c.id === id);
    if (!contract) {
      return throwError(() => new Error('Contract not found'));
    }
    return of(contract).pipe(delay(500));
  }
}

然后我们在 providers 里这样使用：

// 在开发环境或 Storybook 中
import { ContractService } from './contract.service';
import { MockContractService } from './mock-contract.service';

@NgModule({
  providers: [
    { provide: ContractService, useClass: MockContractService }
  ]
})
export class ContractFeatureModuleDev {}

这种场景下，Claude Code 生成的代码完全合理，因为：

• 生命周期极短：Mock 服务不会进入生产环境，一旦真实 API 就绪就会被抛弃；
• 架构决策简单：Mock 服务不涉及复杂的注入器层级，通常就在组件级别的 providers 里，或者用 useClass 替换；
• 容错空间大：即使生成的假数据结构有问题，最坏情况是 UI 显示错误数据，不会导致生产事故；
• 节省大量机械编码：对于一些拥有 30+ 方法的接口，手写 Mock 非常耗时。

合理性的第二个判断标准：当生成的 DI 代码用于原型、测试和模拟环境，生命周期短、不进入生产主干、失效成本低时，Claude Code 是非常高效的选择。

六、危险模式一：跨模块的全局单例污染，看起来能跑，但正在埋雷

现在要进入我踩过的最深的坑，也是我认为在所有 Claude Code 生成的 DI 代码中最危险的模式：全局单例污染。

Angular 的 DI 是分层级的，不同模块、不同组件可以拥有自己的注入器实例。一个服务如果在 @Injectable() 中申明 providedIn: 'root'，它就在整个应用生命周期内保持单例；如果只在某个 @NgModule 的 providers 数组中声明，则该模块及其子注入器共享一个单例；如果在 @Component 的 providers 中声明，则每个组件实例拥有独立的服务实例。

Claude Code 的语言模型对“作用域”这一概念的自然语言理解能力，在面对 Angular 的注入器层级时，存在严重的“平面化”倾向。它倾向于把所有的服务都设为 root 单例，因为这对任何组件都是“最安全”的注入方式（不会出现 NullInjectorError）。但它完全忽视了一个事实：有的服务在语义上就不能是全局单例。

我举一个我们实际遇到的案例。

在我们的供应商协同模块中（SupplierCollaborationModule），有一个 CollaborationSessionService，它负责管理当前协同会话的状态：当前编辑的订单、正在沟通的消息列表、协同白板数据等。这个服务必须在模块级提供，因为每个供应商的协同会话是完全独立的，不能共享状态。

在开发新功能时，由于工程师没有在 Claude Code 的提示中明确指定注入器层级，Claude Code 自动生成了 providedIn: 'root'。这个错误在开发阶段完全没有暴露，因为当时只有一个用户（开发者）在测试。但是当我们部署到测试环境，同时打开两个不同供应商的协同会话时，灾难发生了：由于是全局单例，第二个会话的数据覆盖了第一个会话，导致页面显示混乱，甚至把供应商 A 的报价发送给了供应商 B。

这个 Bug 的排查难度极高，因为：

1. 错误不在代码逻辑里，而在注入器层级的设置上；
2. 错误是“环境触发”的，单用户测试无法复现；
3. 报错信息不直接指向根因，而是表现为“数据不正确”这种模糊症状。

最后我们是通过 Angular DevTools 的 Injector Tree 视图，才发现 CollaborationSessionService 竟然挂在了 root 注入器下，而不是模块注入器下。

从这个案例中，我提炼出了一个关键经验：对于任何涉及用户会话、工作流状态、多实例 UI 组件（如多个图表、多个编辑器）的服务，永远不要依赖 Claude Code 推断其注入器层级，必须在提示中显式指定，并且人工 Review 确认。 如果你没有把握，就老老实实地使用 NgModule 或 Component 级别的 providers 显式声明，而不要把命运交给 providedIn: 'root'。

七、危险模式二：Factory Provider 的动态逻辑被“静态化”

另一个极易出问题的地方是 Factory Provider。在 Angular 里，Factory Provider 允许我们根据运行时条件动态创建服务实例，比如根据环境变量、Feature Flag、用户权限等决定注入哪个实现。

Claude Code 在生成 Factory Provider 时，常常会出现两种偏差：

1. 把 Factory 函数写成了“伪动态”：在 Factory 函数中写死了条件判断，或者错误地依赖了在 Factory 执行时尚未初始化的外部状态。
2. 忽略了 deps 数组的正确配置：导致 Factory 函数的依赖注入失败。

举一个实例。我们有一个 PaymentGatewayService，需要根据当前租户的配置决定使用 StripePaymentService 还是 AlipayPaymentService。正确的写法是使用 InjectionToken + Factory Provider：

// 正确的人工实现
export const PAYMENT_GATEWAY = new InjectionToken<PaymentGateway>('PAYMENT_GATEWAY');

export function paymentGatewayFactory(
  tenantConfig: TenantConfigService,
  stripe: StripePaymentService,
  alipay: AlipayPaymentService
): PaymentGateway {
  return tenantConfig.gateway === 'stripe' ? stripe : alipay;
}

@NgModule({
  providers: [
    {
      provide: PAYMENT_GATEWAY,
      useFactory: paymentGatewayFactory,
      deps: [TenantConfigService, StripePaymentService, AlipayPaymentService]
    }
  ]
})
export class PaymentModule {}

而 Claude Code 的生成版本可能是这样的：

// Claude Code 生成（问题版本）
@Injectable({
  providedIn: 'root',
  useFactory: () => {
    // ❌ 在 factory 中直接读取了一个全局变量，而不是通过 DI 获取 TenantConfigService
    return window.__GATEWAY_TYPE === 'stripe' ? new StripePaymentService() : new AlipayPaymentService();
  }
})
export class PaymentGatewayService { }

这个错误非常隐蔽。它完全绕过了 Angular 的 DI 系统，直接使用全局变量和 new 关键字构造服务，导致 StripePaymentService 和 AlipayPaymentService 自身的依赖注入链条全部断裂。在这个案例中，由于这两个支付的 Service 又依赖了 HttpClient，所以应用在支付页面会直接抛出 HttpClient 未定义的错误，而报错堆栈指向的是运行时初始化，和 Claude Code 生成的代码隔着好几层。

另一个变体是，Claude Code 正确地写了 Factory 函数，但 deps 数组缺失或错位：

export function paymentGatewayFactory(
  tenantConfig: TenantConfigService,
  stripe: StripePaymentService,
  alipay: AlipayPaymentService
) { ... }

// deps 数组写成了 ['TenantConfigService', 'StripePaymentService', 'AlipayPaymentService'] 字符串
// 或者是错误的注入顺序： [StripePaymentService, TenantConfigService]

这里的教训是：Factory Provider 的生成必须有人工参与验证，绝不能直接采纳 Claude Code 的输出，因为它的训练数据里有大量错误示例，或者它对 Angular 的 deps 机制理解不完整。建议的实践是，让 Claude Code 生成 Factory 函数的骨架和返回值逻辑，但 Provider 声明（包括 provide、useFactory、deps）必须人工完成，或者在生成后对照 Angular 官方文档的检查清单逐项核对。

八、危险模式三：Tree-shaking 的默默失效

这是一个很多开发者自己不怎么会去查验，但足以让构建产物体积显著增加的暗坑。

Angular 的 Tree-shaking 依赖于注入器层级的明确声明。如果一个服务用 providedIn: 'root' 声明，Angular CLI 的构建优化器就能安全地将它标记为 tree-shakeable：如果一个服务在 root 提供了，但没有任何组件或其它服务在构造函数中注入它，它会在生产构建中被移除。

但如果一个服务在模块的 providers 数组中声明（且没有在 @Injectable() 中设置 providedIn），那么该服务的 tree-shakability 就会降低，因为它变成了模块的“附带品”，只要模块被导入，服务就可能被打包。

Claude Code 有时会“帮你做过多决策”：它可能会把你本应设为 providedIn: 'root' 的纯工具服务（如日期格式化、本地存储封装）错误地写在 NgModule 的 providers 里，从而导致这个服务无法被 tree-shake。或者反过来，它把一个本应限定在特定模块内的、带有状态的服务设为了 root，导致不仅 tree-shaking 失败，还造成了前述的全局单例污染。

我们曾遇到过一个极端的例子：一个只有 12 个方法的 UtilityService，被 Claude Code 写在了 SharedModule 的 providers 数组中，而这个 SharedModule 被主模块和多个懒加载模块同时导入。结果是，该服务在整个应用中被复制了多次（实际是多个实例），并且在 Webpack 的 Module Federation 场景下，甚至导致了子应用间的运行时冲突。最后我们把它改为 providedIn: 'root'，构建产物体积下降了约 3KB（gzip 后），虽然绝对值不大，但多个类似问题累积起来，总体积有将近 80KB 的冗余代码被识别和清理。

合理性的第三个判断标准：如果你无法确认 Claude Code 生成的 DI 代码对 Tree-shaking 的影响（尤其涉及懒加载和 Module Federation），最好不要直接用于生产。 人工需要做一次构建分析（如使用 webpack-bundle-analyzer）来验证是否有多余的模块被打包。

九、如何建立“AI 辅助 DI 代码生成的决策矩阵”？

到此，我已经展示了合理场景和三个最典型的危险模式。但如果只是列出一堆“能做”和“不能做”，对实际工作帮助有限，因为真实世界中的场景往往是灰色的。我们需要一个可以操作的决策框架，让团队成员在面对具体需求时，能够快速判断是否可以交给 Claude Code 生成 DI 代码，以及在什么条件下可以。

我根据我们团队的经验，设计了一个四维决策矩阵，一共包含四个判断维度：

这个矩阵的使用方法是：只有当一个服务在四个维度都得到“是”时，Claude Code 生成的 DI 代码才能直接合并到主分支。任何一项为“否”，都需要人工介入，介入的深度从“修改特定属性”到“完全重写 DI 配置”不等。

我们通过这个矩阵，在试验的后两周里，把 Claude Code 生成的 DI 代码的直接可用率从 30% 提升到了 70% 以上（因为工程师学会了只让它生成符合全部四个条件的服务，而其他场景放弃了 AI 生成）。

十、给不同角色的具体行动建议

不同的角色在 Angular 项目中使用 Claude Code 生成 DI 代码，关注点完全不同，我分开来讲。

1. 对于一线 Angular 开发者

• 不要迷信 AI 的“最佳实践”。它在没有上下文的条件下，会倾向于应用最普遍的实践（比如 providedIn: 'root'），但你的项目可能有完全相反的约定。
• 养成一个习惯：在向 Claude Code 描述需求时，明确写出注入器层级。例如：“请创建一个服务，它在 ContractFeatureModule 的 injector 中提供，不要使用 root。” 这能大大减少错误率。
• 每次收到生成的代码后，运行一个“注入器合理性检查清单”：

1. 这个服务是否需要在不同模块间保持状态隔离？如果是，它不能在 root 提供。
2. 它是否依赖了仅在特定模块内可用的其他服务？如果是，它必须在同层级提供。
3. 是否有任何 Factory Provider 的 deps 数组需要核对？
4. 是否在组件级别的 providers 中引用了这个服务？那会导致新实例的创建，这是预期的吗？

• 利用 Angular DevTools 的 Injector Tree 进行可视化验证，特别是对复杂模块。
• 在原型和单元测试中，大胆使用 Claude Code 生成 Mock Service。这能节省你 50% 以上的 Mock 编写时间。

2. 对于技术负责人/架构师

• 在你的团队编码规范中，明确列出哪些类型的服务允许使用 AI 生成 DI 代码，哪些禁止。不要只说“大家合理使用 AI”，这等于没说。例如在我的团队，我们规定了：“任何包含 @Injectable() 装饰器且 providedIn 不为 'root' 的服务，其 DI 配置必须经过人工编写或人工批准。”
• 在 CI/CD 流程中加入针对 DI 的静态检查。可以编写自定义 ESLint 规则，检查是否存在服务在非 root 层级但被意外设为 root 单例（需要结合项目文件结构进行判断）。虽然工具不能完全替代审核，但可以拦截到一部分低级错误。
• 定期进行 Bundle 分析，把 tree-shaking 健康度作为质量指标。如果发现某些服务没有按预期被 tree-shake，很可能是因为 AI 生成的 DI 配置破坏了摇树优化。
• 投资于团队对 Angular DI 原理的深度培训。AI 工具越普及，团队对底层原理的理解就越重要，因为你需要有能力去审核 AI 的输出。不要因为有了 Copilot 就弱化基础能力。

3. 对于工具链/DevOps 工程师

• 探索构建一个内部的 Claude Code 记忆库（Project Memory），把团队关于 DI 的约定（例如“所有 Feature 服务必须在 Feature Module 中提供”、“InjectionToken 统一放在 tokens 目录”等）写入，让 AI 在生成时能遵守这些规则。这相当于给 Claude Code 戴上了“组织约束”的镣铐，极大降低出错率。
• 设计一个 AI 生成代码的 Review 模板，专门针对 DI 部分，并集成到 PR 流程中。模板可以包括：“注入器层级是否明确？”、“生命周期是否匹配？”、“Tree-shaking 是否验证？” 等。

十一、一个完整的实操案例：如何把 Claude Code 从“雷区”改成“高效机器”

我想用一个完整的案例来收尾，展示在实践中如何把 Claude Code 从“效率陷阱”转变成真正能用的工具。

在供应商协同模块中，我们需要新增一个 SupplierMessageService，需求如下：

• 负责管理当前协同会话的消息流（接收、发送、标记已读）
• 依赖 WebSocketService（全局单例，管理 WebSocket 连接）、AuthService（全局单例）、MessageStore（模块级状态存储）
• 必须在供应商协同模块内保持单例，不可全局单例
• 需要支持在单元测试中用 Mock 替换
• 未来可能根据供应商类型替换为不同的消息服务实现

按照我们的决策矩阵，这个服务的 可变性（需要模块级注入）、复杂度（可能涉及 Factory Provider）、容错性（状态污染后果严重） 三项都是“否”，只有生命周期是生产环境，因此“全自动生成”是不合理的。但我们仍然可以分步使用 Claude Code 来加速部分机械性工作。

步骤一：由架构师决策并写出核心 DI 骨架（人工）

// 由人工定义 InjectionToken 和 Provider 骨架
import { InjectionToken } from '@angular/core';
import { SupplierMessageService } from './supplier-message.service';

export const SUPPLIER_MESSAGE_SERVICE = new InjectionToken<SupplierMessageService>('SUPPLIER_MESSAGE_SERVICE');

export function supplierMessageServiceFactory(
  webSocket: WebSocketService,
  auth: AuthService,
  store: MessageStore
): SupplierMessageService {
  // 未来可根据 auth 信息选择不同实现，这里先返回默认
  return new SupplierMessageService(webSocket, auth, store);
}

步骤二：把重复性的服务类实现交给 Claude Code（AI 生成）

我给 Claude Code 的这个提示包含了明确约束：

请生成 SupplierMessageService 类的实现，它实现了 IMessageService 接口。不要添加任何 @Injectable() 装饰器或 Provider 配置，那些会由人工提供。它需要包含 sendMessage、onMessage、markAsRead 方法，并正确使用通过构造函数传入的 WebSocketService、AuthService 和 MessageStore。使用 RxJS 管理消息流。

生成的代码我没有做任何修改，因为它只包含业务逻辑，不涉及 DI 配置。

步骤三：在模块的 providers 中手动组合

@NgModule({
  providers: [
    {
      provide: SUPPLIER_MESSAGE_SERVICE,
      useFactory: supplierMessageServiceFactory,
      deps: [WebSocketService, AuthService, MessageStore]
    }
  ]
})
export class SupplierCollaborationModule { }

步骤四：测试和验证

• 使用 Angular DevTools 确认 SupplierMessageService 实例正确挂载在 SupplierCollaborationModule 的注入器下。
• 在两个并发的协同会话中测试，确认状态隔离。
• 在 PR 中包含注入器层级的截图作为 Review 证据。

这个案例中，我们把 AI 的角色严格限定在“非 DI 部分的业务代码生成”和“重复的 Mock 生成”上，而把 DI 骨架的决策权完全保留在人工手里。结果是我们既获得了 AI 在 CRUD 和逻辑编写上的速度优势（节省了大约 40% 的开发时间），又避免了 DI 错误的风险。

总结成一条核心原则就是：让 AI 填充函数体，但不要让它决定函数怎么被注入。

十二、结论：告别笼统的“合理/不合理”，建立你自己的分层判断系统

如果读完这篇文章你只记住一句话，我希望是这一句：

在 Angular 项目中使用 Claude Code 生成依赖注入代码，不是一个“Yes or No”的问题，而是一个“Which Part and Under What Condition”的判断体系。

这个体系的核心，就是要把我们脑子里那些以往在下意识中完成的架构决策，显式地提取出来，变成检查清单、决策矩阵和团队规范。AI 可以帮你减轻“打字”的体力活，但它无法替你承担架构决策的责任。而依赖注入，恰恰是前端架构中最不能模糊处理的环节之一。

我现在的做法是：对于每一个新服务，我都在决定是否用 Claude Code 之前，先问自己四个问题，可变性、复杂度、容错性、生命周期。如果答案是肯定的，我就放手让 AI 去做；如果有一项否定，我就画出 DI 的骨架，让 AI 只填肉。

你也可以根据你自己项目的实际情况，去建立一套属于你们自己的判断标准。这套标准可能和我的不同，但只要你开始这样思考，你就已经超过了 90% 盲目使用 AI 的开发者。

下一步，我的建议是：

1. 打开你当前 Angular 项目的代码库，随机抽出 10 个由人工编写的服务，用我讲的四个维度逐一打分，看看它们分别属于“安全区”还是“危险区”；
2. 在下一个 Sprint 中，选一个简单的新服务，尝试用“分步协作”的方式去引入 Claude Code，并记录下实际节省的时间和遇到的问题；
3. 在下一次团队技术分享会上，把你记录的对比结果拿出来讨论，逐步形成你们自己的“AI 辅助 DI 代码生成规范”。

只有当越来越多的团队开始这样精细化地管理 AI 在代码生成中的角色，我们才能真正享受到 AI 带来的效率红利，而不是被它产出的“看起来正确”的代码反噬。