一段：诊断定界
用两周左右把业务链路、数据可得性、责任人与验收口径写成场景确认书，同时列出本轮明确不做什么。范围越小，原型阶段越容易判断可行性；三个场景同时开工，通常一个都收不了尾，还会互相拖累。
二段：原型验真
只做一条主路径，用真实样本跑通，建立最小评测集并记录基线。原型不追求界面完整，目标是证明任务可完成、错误可被识别、复核人愿意用。若发现数据拿不到，应立即回到定界，而不是靠加人硬做，那样只会更乱。
三段：开发与集成
补齐权限、日志、异常处理与系统对接，按周演示。这一阶段最容易被追加需求拖长，任何变更都要书面记录对范围、工期与验收的影响，由双方负责人确认后再排期，否则工期会在不知不觉中失控，验收也会被拖后。
四段：上线与移交
以客户团队独立运行一个完整业务周期为终点，交付代码、部署手册、字段字典、评测集与已知问题清单。只交文档不交运行，移交不算完成；遗留事项要写进确认单并约定责任期限、具体责任人与遗留缺陷的处理方式。
适用与不适用
适合谁
- 需要在季度内交付首个可用场景的业务团队
- 有明确项目负责人、能按周组织评审的企业
不适合谁
- 希望跳过原型直接开发全套系统的项目
典型场景
某装备企业的售后工单需要自动归类与派单建议。定界阶段确认字段与派单规则，原型阶段用历史工单验证分类效果并记录接管场景，开发阶段接入工单系统并补权限与日志记录，移交阶段由客服主管带两名坐席独立运行一个完整周期后签字。
可执行步骤
- 用一页纸写清场景、范围、明确不做什么以及验收口径，由双方负责人签字
- 从真实业务数据中抽取样本，建立最小评测集，并记录人工处理的当前基线
- 原型阶段只做一条主路径，跑通并经复核人确认之后，再讨论是否扩展其它路径
- 开发阶段每周演示一次可运行版本，所有变更走书面确认并同步调整里程碑
常见坑
- 里程碑只写日期不写交付物，到期就无法判断是否真的完成，评审会容易变成进度汇报，最后靠加班补。
- 原型被直接拿去当生产系统使用，权限、日志与异常处理都缺失，一旦出错既无法追溯也难回滚，只能整体重来。
- 系统对接放到最后才做，接口、权限或网络策略不通导致上线一再延期，前期进度大部分作废，只能压缩测试。
自检与验收清单
- 每个阶段是否有书面交付物、评审记录与签字人
- 原型是否在真实业务样本上验证过并记录失败案例
- 每次变更是否评估了对范围、工期与验收的影响
- 移交清单是否包含客户独立运行一个周期的验证结果
常见问题
四个阶段可以压缩吗？
可以压缩时长，不建议去掉阶段。定界与原型决定做不做，开发与移交决定能不能用。小场景可把定界和原型合并为一次冲刺，但仍要有范围说明和评测基线，否则后面无法判断效果。
原型要做多久？
取决于数据就绪程度，通常以能否跑通一条主路径为准，而不是固定天数。若两周内仍拿不到可用样本，应先解决数据问题，继续开发只会把风险推到上线前，返工更贵，也更容易伤信任。
客户不配合评审怎么办？
把评审写进里程碑与付款节点，明确缺席即视为默认确认或暂停计时。更根本的做法是让业务负责人成为签字人，评审从旁听变成决策，出席率会明显改善，也便于事后追责。