需求项通过准入、技术设计完成提交后，研发团队可以把本次要实现的内容组织为交付批次，再通过工作流推进开发、测试、业务验收和发布确认。
本篇沿用“会员活动目标人群筛选”示例，将“组合条件筛选”和“覆盖人数预估”一起交付，并以标准交付流程说明操作顺序。
页面中的 “生产实施”、“进入生产” 用于组织研发交付任务。正式环境发布在后续上线环节按项目的发布方式完成。
开始之前
由具备交付权限的成员操作，并确认：
- 本次需求项已通过准入，归属同一工作空间，尚未加入其他交付批次。
- 各需求项的技术设计已经审阅并提交；如设计正文再次更新，需要重新确认提交。
- 项目仓库、模型和执行环境可用，依赖、启动方式和测试方式明确。
- 本次交付范围、验收人员和验收标准已明确；涉及部署时，目标环境和发布方式已经确认。
设计尚未准备好时，先阅读审阅和修改规格、原型与设计。环境要求可参考开始前需要准备什么。
第一步：选择需求项，创建交付批次
在首页选择目标工作空间，进入 “生产实施”。也可以从已提交技术设计的页面进入对应入口。
页面会打开 “批量进入生产” 选择区域，列出当前工作空间中符合条件的需求项。可以按需求、优先级或关键词筛选，然后选择本次范围。
本例选择“组合条件筛选”和“覆盖人数预估”，核对已选数量与需求项内容后，点击 “进入生产”。系统创建交付批次，并打开批次详情。
页面中也会使用 Wave 或 波次 表示交付批次。创建成功后，记录其编号，便于团队查找同一次交付。
如果列表为空，先清除不必要的筛选条件，再检查需求项的准入、设计提交和已有批次关联状态。已经进入交付批次的需求项，应到原批次查看进度。
第二步：了解当前阶段和执行状态
进入批次详情后，先查看工作流的当前阶段、状态和待处理操作。标准预设包含：
提案确认 → 方案准备 → 生产与测试 → 业务验收 → 上线 → Spec 归档
工作流按实例创建时采用的已发布版本执行。具体项目可以使用其他流程，阶段名称、操作文案和推进条件以当前页面为准。
详情页主要包含：
- 阶段与状态：查看当前进行到哪里，是否正在执行、等待确认或需要处理问题。
- 阶段对话：在可参与的当前会话中补充说明、查看 AI 执行过程。
- 阶段工作台：检查本阶段的范围、文件、任务、验证结果或待确认内容。
窄屏下可以通过 “阶段对话” 打开会话。查看历史节点时，页面会提示内容只读；要继续操作，应回到当前阶段。
环境初始化需要一定时间。如果页面显示正在准备环境，先查看进度；出现失败提示时，按错误处理。已有批次应在原记录中继续跟踪。
第三步：确认本次提案与交付范围
在 “提案确认” 阶段，核对选中的需求项及其对应变更。页面可能使用 Change 表示一组具体变更，并展示它与需求的关系、涉及的规格和依赖。
本例重点检查：
- 本次包含筛选与人数预估两个需求项，范围与已确认材料一致。
- 条件组合、消费时间口径、人数去重和异常展示等关键规则都已纳入。
- 两项之间的数据与执行依赖得到合理安排。
如需调整，在当前阶段会话中指出具体问题。例如：
请核对本次交付包含“组合条件筛选”和“覆盖人数预估”。人数预估需要使用相同的筛选规则，并按会员去重。请检查两项的依赖及执行安排，更新本次提案供我确认。
材料更新后重新检查。当页面提供提案确认操作时，阅读待确认内容，再由有权限的成员完成确认。确认后的范围用于指导后续工作。
第四步：检查方案与实施安排
在 “方案准备” 阶段，结合已提交的需求项设计和当前项目情况，检查本批次的实施安排。
需求项的技术设计说明单项如何实现；批次中的方案准备还需要考虑本次多个变更之间的依赖与任务衔接。
研发人员应检查：
- 本次需要新增或修改哪些能力，是否覆盖全部选定需求项。
- 任务拆分和依赖顺序是否合理，能否完成开发、联调和验证。
- 已有代码、数据和服务能否支持方案，尚未解决的条件是否已说明。
- 业务规则对应哪些测试或验收场景。
例如，可以要求 AI 结合当前仓库核对会员查询与统计能力，说明复用方式，以及条件筛选和人数计算怎样保持一致。
当出现方案检查或 “进入生产” 确认时，先审阅当前方案，再执行确认。这里的“进入生产”表示从方案准备推进到实施阶段。
第五步：推进开发与测试
进入 “生产与测试” 后，通过阶段对话与工作台跟踪代码实现、任务进度和验证情况。团队可以补充约束、处理依赖问题，并检查实际变更。
工作台提供相应能力时，可以：
- 在 “开发实现” 中查看变更和任务进度。
- 通过 “查看代码与服务” 检查当前工作环境中的文件、代码和服务。
- 查看已执行测试的结果与报告，核对覆盖范围、失败原因和对应的代码状态。
AI 完成说明、任务进度和测试结果需要结合起来判断。研发人员还应检查当前仓库中的实现，以及约定的构建、运行和验证结果。
本例至少应验证：多个条件取交集、日期边界、会员去重、空结果和统计失败处理。可使用业务规则与验收标准示例中的固定数据核对结果。
核对代码合并与测试环境
当页面提供 “确认合并代码” 时，先核对显示的目标分支、本次变更和验证结果，再提交操作。操作后检查实际合并状态；如果代码随后又发生变化，需要重新检查当前版本的验证与合并情况。
接入独立测试环境的项目，还可能需要完成测试环境部署。出现 “部署到 TEST” 时，按当前流程操作，并检查部署结果与服务状态。沙箱中的运行检查和目标测试环境的验证分别反映各自环境中的结果。
具备提交条件后，通过页面提供的 “提交业务验收” 操作，将本次交付交给验收人员。具体可执行操作取决于当前工作流、项目接入方式和账号权限。
第六步：逐项完成业务验收
在 “业务验收” 阶段，验收人员使用约定的环境和数据，按照需求项的验收标准检查实际效果。
页面提供逐项验收表单时，记录验收人、验收意见和结论。当前表单包含 “通过”、“不通过”、“需要修复”；未通过的项目需要填写缺陷说明。
对于人群筛选，可以说明使用了哪些会员样例、输入了哪些条件、实际人数是否符合预期，并记录相关页面或操作证据。
发现问题时，明确需求项、复现步骤、预期结果和实际结果，再按当前流程提供的操作安排修复。修复后，对受影响的内容重新验证，并记录新一轮验收结论。
各需求项验收通过、满足当前阶段要求后，再由有权限的成员执行 “完成业务验收” 等阶段操作，按页面返回的结果确认是否进入下一阶段。
第七步：核实上线结果，完成规格归档
业务验收通过后，按项目约定的发布方式完成目标环境交付，并检查实际部署结果和应用运行情况。
标准预设中的“确认上线”记录人工对外部发布结果的确认，本身不执行部署。 操作前，应先核实实际发布的版本、目标环境和结果，再阅读当前确认内容并提交。
如果页面说明缺少外部上线证明，应区分已保存的人工确认与可核实的发布记录。应用是否已经上线，需要到实际目标环境和发布记录中确认。
进入 “Spec 归档” 后，查看本次待归档的规格及目标。页面准备好相应操作时，核对范围，再执行 “合并并归档 Spec” 及其确认操作。
操作完成后，检查当前工作流是否已经完成，并查看规格归档结果。对于采用其他流程的项目，以其配置的结束条件为准。
怎样判断这次交付完成
结束前，分别核对以下结果：
阶段报告、快照或历史记录不可用时，应结合错误说明与当前工作环境判断影响。历史记录缺失和业务操作失败需要分别处理；权限、人工决定及发布目标等必要条件仍需按实际要求满足。
遇到阻塞时
- 无法创建批次：检查需求项是否已准入、设计是否已提交、工作空间是否一致，以及是否已加入其他批次。
- 长期停在环境准备：查看初始化错误，联系管理员检查仓库访问、模型和执行环境。
- 没有可用的确认按钮：确认正在查看当前阶段，再核对待处理操作、账号权限和页面提示。
- 测试或部署失败：保留当前结果与日志，在对应工作环境中定位并修复，再执行受影响的检查。
- 操作结果不明确：先刷新当前批次，核对已有执行结果和外部系统状态，再使用页面提供的恢复或重试操作。
请求协助时，提供工作空间、批次编号、当前阶段、操作时间和错误说明，便于团队找到同一次执行。