为什么批量创建是一个工作流

一次投放会涉及广告主、计划、广告组、创意、素材、标题、预算和定向等对象。把一个表单放进循环，并不能解决命名、分配、局部失败和再次提交的问题。

我在团队项目中参与快手、B站、广点通等媒体的批创，以及头条相关素材关系完善。自己的提交从实体与接口扩展到预览、提交、批量任务查询、素材处理和后续修复，形成了持续迭代的负责范围。

先预览，再执行外部动作

预览阶段把配置展开成本地草稿，处理名称、素材、标题和定向的分配，再让页面展示将要创建的对象。提交阶段才调用媒体接口。

这个边界的价值是让用户在产生外部副作用前看清结果，也让预览和提交共享同一批业务对象。比如广告主数量、计划数和广告组数共同决定展开规模，分配规则又决定哪些素材和标题落在哪个对象上。这些都需要先写清业务含义，再让 AI 实现。

让失败可以继续处理

广点通相关提交补充了“提交中”状态，并优化创意重新提交。素材上传失败还需要能定位到具体素材，媒体错误则需要保留可读原因。

我会沿着“用户看到什么状态、后端记录了什么、媒体实际创建了什么”检查流程。局部失败不能只剩一个总的失败提示，重新提交也应围绕已记录的结果处理。

小修复暴露出的工程边界

提交历史中有一类问题是事务内异常详情没有正确展示。对应修复调整了事务注解和异常处理，说明多数据源事务与 Spring 本地事务的上下文并不能直接混用。一个看似普通的 catch，也可能让真正的失败原因被另一层异常盖住。

还有素材封面压缩、视频上传重试、小游戏试玩页与标题分配等细节。它们不适合笼统归为“对接接口”，更考验对媒体规则和业务组合的理解。

我在项目里积累的能力

• 流程建模：明确预览、提交、处理中、结果查询和重提的边界。
• 规则拆解：把素材、标题、命名和组件分配表达成可校验的规则。
• 问题定位：从具体媒体错误、事务上下文和素材对象追到失败原因。

AI 可以生成大量接口和分支，我需要判断这些分支是否对应真实业务，并用部分成功、重复操作、上传失败等场景验证结果。