瀑布与 V 模型：阶段基线和验收追踪
瀑布模型按需求、设计、实现、验证、交付组织生命周期。核心是阶段之间有明确的输入、产物和评审基线，适合交付范围、外部接口和验收程序已经比较明确的工作。阶段安排不能证明需求一定正确，也不能保证风险较低。
例如财务系统要接入一套确定的对账文件格式，外部机构明确给出字段、编码、签名和交付日期。这时先确认接口基线，再实现和验收，可以避免多方使用不同版本的格式。但如果财务自己还不清楚需要哪些数据，先冻结长篇规格反而会把猜测固化。
阶段如何推进
需求阶段不仅列“可以导出”，还要给出谁能导出、导出哪些记录、文件如何校验、失败怎样处理。设计阶段决定同步还是异步、文件如何存储、下载如何鉴权。实现阶段持续执行单元和集成测试，系统验证再检查端到端业务和外部接口。不能把所有测试都推迟到编码结束。
图中的回路表示基线可以改变，但必须分析影响。外部机构增加字段时，需要确认接口、数据来源、测试样本和交付日期是否随之变化。受控变更不是禁止返回前一阶段，而是使返工范围和责任可见。
| 阶段 | 必须留下的产物 | 放行判断 |
|---|---|---|
| 需求基线 | 字段、权限、验收场景和范围边界 | 业务与交付方对成功、失败的含义一致 |
| 设计基线 | 接口、状态、存储和恢复方案 | 关键依赖可用，主要风险有验证入口 |
| 实现与集成 | 代码、测试、可复现构建 | 实现符合基线，模块间能真实连接 |
| 系统与验收 | 场景结果、缺陷处置、兼容结论 | 阻断项已关闭，证据覆盖约定范围 |
| 交付与运行 | 制品、配置、运行说明、恢复入口 | 可以追溯版本，责任人能处理异常 |
V 模型如何补上验证关系
V 模型强调分解设计与相应验证层级的对应关系：业务需求对应验收测试，系统需求对应系统测试，组件与接口设计对应集成测试，详细设计对应单元测试。具体层级名称会因组织标准变化，但关键机制是设计阶段就考虑如何验证。
对订单导出，业务需求“财务只能导出所属租户”应对应验收场景；接口约定应对应状态码、字段和鉴权测试；字段转换函数应对应金额、日期和空值测试。这种追踪可以用一张轻量表完成，无需为每个私有方法写单独文档。
| 需求或设计项 | 对应验证 | 失败意味着什么 |
|---|---|---|
| 只允许所属租户导出 | 用不同租户账号请求并核对文件内容 | 权限或查询范围越界 |
| 请求返回任务标识，失败可查询 | 接口测试和真实任务状态检查 | 契约或状态处理不完整 |
| 金额按最小货币单位转换 | 确定输入与输出的单元测试 | 局部转换逻辑错误 |
怎样与迭代和 AI 结合
外层可以保留合同里程碑，内层用小批量迭代实现。第一批验证接口连通和样本文件，第二批验证权限与完整字段，第三批验证性能和恢复。每批都回到同一需求基线，而不是等所有模块写完才联调。
AI 可以辅助生成样本、字段映射和测试，也可以执行边界明确的任务。但模型生成的规格仍需业务确认，测试仍需核对预期。文档、实现、测试如果都从同一个误解生成，会形成一致但错误的结果。
适用边界和误区
固定格式、成熟技术、明确验收责任和外部审批依赖，是采用阶段基线的理由；“团队经验少”“属于金融行业”“项目很大”本身不是充分条件。受监管项目可以采用迭代，只是追溯、验证和审批要求必须满足。
常见失败是需求阶段仅写功能名称，验收才发现审计和隔离缺失。应在基线中补可观察行为和异常场景，再检查每项是否有验证证据。变更发生后只更新代码，也会让规格和验收保留旧规则；接口、测试和交付说明应同步更新。
完成检查应回答：当前基线是什么版本，变更影响哪些产物，验收覆盖哪些需求，仍有哪些阻断项。如果无法回答，阶段名称再完整也不能说明项目可交付。