backend/modules/prompt/
├── application/     # manage.go debug.go execute.go openapi.go tool_manage.go + wire.go/wire_gen.go
├── domain/
│   ├── entity/       # prompt.go prompt_detail.go label.go debug_context.go ...
│   ├── service/       # manage.go execute.go formatter.go snippet_parser.go ...
│   └── repo/          # manage.go label.go debug_log.go debug_context.go tool.go（全是接口）
├── infra/
│   ├── repo/mysql/    # DAO 实现
│   ├── repo/redis/    # 缓存 DAO 实现
│   ├── rpc/           # 调 foundation/llm 等其他模块（本地客户端）
│   └── conf/ collector/ metrics/
└── pkg/               # errno consts template（模块内部小工具）

backend/modules/prompt/domain/repo/manage.go 的 IManageRepo 接口是这条铁律最好的证据——它定义在 domain 层，却描述的是"存储"这件"infra 的事"：

// domain/repo/manage.go —— 接口定义在 domain 层
type IManageRepo interface {
	CreatePrompt(ctx context.Context, promptDO *entity.Prompt) (promptID int64, err error)
	GetPrompt(ctx context.Context, param GetPromptParam) (promptDO *entity.Prompt, err error)
	// ...
}

// infra/repo/manage.go —— 实现放在 infra 层，反向依赖 domain
type ManageRepoImpl struct { db db.Provider; idgen idgen.IIDGenerator; ... }
func (d *ManageRepoImpl) CreatePrompt(ctx context.Context, promptDO *entity.Prompt) (promptID int64, err error) { ... }

//go:build wireinject
package application

var (
	promptDomainSet = wire.NewSet(
		service.NewPromptFormatter, service.NewToolConfigProvider, service.NewPromptService,
		repo.NewManageRepo, repo.NewLabelRepo, repo.NewDebugLogRepo,
		mysql.NewPromptBasicDAO, mysql.NewPromptCommitDAO, mysql.NewPromptUserDraftDAO,
		rediscache.NewPromptBasicDAO, rediscache.NewPromptDAO,
		rpc.NewLLMRPCProvider, rpc.NewAuthRPCProvider, rpc.NewFileRPCProvider,
		// ... 共 20 余项
	)
	manageSet = wire.NewSet(NewPromptManageApplication, promptDomainSet)
)

func InitPromptManageApplication(idgen idgen.IIDGenerator, db db.Provider, redisCli redis.Cmdable, ...) (manage.PromptManageService, error) {
	wire.Build(manageSet)   // 只声明"用这些零件"，具体怎么拼装交给 wire 工具生成
	return nil, nil
}

执行 wire 命令后，真正参与编译的是同目录下的 wire_gen.go——它会分析每个构造函数需要什么参数、自动按正确顺序把它们一个个 new 出来：

// wire_gen.go（自动生成，勿手改）
func InitPromptManageApplication(idgen idgen2.IIDGenerator, db2 db.Provider, redisCli redis2.Cmdable, ...) (manage.PromptManageService, error) {
	promptBasicDAO := mysql.NewPromptBasicDAO(db2)
	promptCommitDAO := mysql.NewPromptCommitDAO(db2)
	manageRepo := repo.NewManageRepo(idgen, promptBasicDAO, promptCommitDAO, ...)
	authRPCProvider := rpc.NewAuthRPCProvider(authClient)
	promptService := service.NewPromptService(manageRepo, ...)
	promptManageApplicationImpl := NewPromptManageApplication(promptService, authRPCProvider, ...)
	return promptManageApplicationImpl, nil
}

把 Day 03 的 api.Init、Day 05 的 bindLocalCallClient、今天的 Wire 串起来，一次"新建 Prompt handler"的完整装配链路是：

回头看 Day 03 埋下的钩子：api.go:77-83 里 InitPromptHandler 接收的参数是包装过的接口：

promptHandler, err := apis.InitPromptHandler(ctx, ...,
	loruntime.NewLocalLLMRuntimeService(llmHandler.LLMRuntimeService),   // 不是直接传 llm 模块的 application 对象
	loauth.NewLocalAuthService(foundationHandler.AuthService),           // 而是先包一层 "本地 Kitex 客户端"
	lofile.NewLocalFileService(foundationHandler.FileService),
	louser.NewLocalUserService(foundationHandler.UserService),
	auditClient,
)

这些包装函数最终会流入 modules/prompt/infra/rpc/ 下的 NewAuthRPCProvider 等 Provider——prompt 模块拿到手的，永远只是 authservice.Client 这样一个 Kitex 生成的接口类型，完全看不到 foundation 模块内部 AuthApplicationImpl 的任何实现细节。

✋ 动手 5 分钟

# 1. 数一数 prompt 模块四层各有多少文件
for d in application domain/entity domain/service domain/repo infra; do
  echo "$(find backend/modules/prompt/$d -maxdepth 1 -name '*.go' 2>/dev/null | grep -v _test | wc -l) $d"
done

# 2. 看 wire.go 的零件清单
grep -n "wire.NewSet\|wire.Build" backend/modules/prompt/application/wire.go

# 3. 对比 wire_gen.go 是怎么真正装配的
grep -n "func InitPromptManageApplication" -A 15 backend/modules/prompt/application/wire_gen.go

# 4. 找到 IManageRepo 接口定义与实现分别在哪
grep -rn "type IManageRepo interface" backend/modules/prompt/domain/repo/
grep -rn "type ManageRepoImpl struct" backend/modules/prompt/infra/repo/