保存之后，怎样才能发布？
广告创建、审核发布与草稿管理。把业务操作的条件，落实到前后端实现和异常提示里。
- 我的参与
- 梳理业务流程与验收条件，借助 AI 参与开发，通过 PR 接受团队审查。
- 关键判断
- 保存、审核和发布分开；草稿操作要检查版本、状态与账户范围。
- 实际交付
- Python 服务、前端表单与异常提示、草稿模型及数据库迁移。
- 验证依据
- 提交中包含版本、发布状态与账户范围的回归测试，按团队反馈修改。
保存、审核和发布，是三个动作
在广告工作流里，使用者需要知道，眼前的内容只是存下来了，还是已经会触发投放。请求失败或结果不明确时，也需要知道下一步怎么处理。
我参与的改进围绕这些操作展开：创建和审核怎样衔接，编辑后需要检查什么，哪些草稿可以删除，以及多人修改时怎样发现版本冲突。
- 保存草稿保留当前编辑内容。
- 核对与审核检查内容、条件与当前版本。
- 执行发布明确操作意图，再反馈结果。
通用流程示意，根据工作问题整理；不复现公司的完整产品或内部架构。
我把业务要求带进实现
我把操作中的要求整理成流程和验收条件，并借助 AI 参与实现。相关改动涉及 Python 服务、前端表单与状态提示，以及草稿的数据模型和数据库迁移。
例如，页面打开后草稿又被修改，原来的操作是否还有效；删除时无法确认最新状态，界面应该怎么提示。这些异常路径会影响用户能否判断一次操作的后果。
改动通过 PR 进入团队审查，我再根据反馈调整实现与测试。这是团队协作中的参与范围。
用一次草稿操作，说明检查条件
同一个按钮，在不同状态下不应该始终产生相同结果。下面把版本、发布状态和账户范围拆开，展示操作前的判断。
这份草稿，还能删除吗？
发布流程也改变草稿的可操作范围。这里选取其中一个边界：删除前，需要确认版本、发布状态和账户范围；这不是完整的广告发布演示。
合成场景 · 浏览器教学演示。没有真实广告、删除或发布操作。
选择一种情况，再运行检查。
本地提交中的测试覆盖了版本、发布状态和账户范围等条件。上面的演示是对这些条件的简化说明，不能替代产品本身的测试。
交付物与验证
相关工作形成了广告创建、审核发布与草稿管理的产品改动，配有前后端回归测试。交付中既有服务端条件，也有前端状态反馈，避免后台拒绝了操作，使用者却不知道发生了什么。
- 服务与数据
- Python 服务、草稿模型与数据库迁移。
- 前端交互
- 表单、状态提示及失败后的处理路径。
- 验证与协作
- 回归测试、PR 代码审查和后续修改。
这里展示的是已核对本地提交的工作范围，不公开公司代码，也不声称由我独立完成整个广告产品。本轮作品集整理没有重新运行完整产品测试。
做完以后，我更在意什么
“能点”只是一个开始。更重要的是，操作何时成立，失败后是否保留了可恢复的信息，使用者是否知道下一步。这些问题必须在流程、实现和验收里得到同一个答案。
相关工作与笔记
另一个产品改动：同一账户在展示、搜索与接口返回中，怎样保持一致。