先完成一条小而完整的用户路径

以下示例与示意结果由本站编写，用于说明方法，不是模型实测结果。

使用场景

MVP 要接受请求、保存并显示状态，规格已明确一种 request-a 及输入错误反馈。你可以先交付这条端到端路径，避免先写所有模型和所有页面后才发现接口接不上。

具体做法

读取已锁定范围与共同架构决定，选一条窄但完整的用户路径，包含输入、保存、读取/展示和失败反馈。建立能演示与验证的验收，完成后核对集成再扩展下一类型。切片小不是删掉必要边界，而是限制当前业务路径数量。

反例

先实现所有请求模型，再写所有存储，再写全部页面，到最后才尝试一次提交；输入错误等其他问题暂时无检查。

改进写法

按教学规格先做 request-a 的提交→保存→状态页。定义输入契约，验证有效提交能读取同一请求状态、无效输入得到约定反馈，保存失败不显示假成功。保留共同架构决定与实际检查记录，首条路径可演示后再添加其他类型，不编造新产品行为。

为什么这样改

一个完整路径早期暴露层间契约和错误传播，比各层孤立完成更容易判断是否能使用。业务范围有限，必要状态仍完整，后续扩展有已验证的接点。

如何验证

示意验收分别覆盖有效、无效和保存失败，读取显示与原请求身份一致。没有真实检查不填写通过；只建出页面或只写表模型都不是端到端完成。

第二切片开始前，首切片产物和验证可找到。本篇未实现真实 MVP。

适用边界

切片服从已定规格，不把试跑当生产容量、隐私或部署保证。共享前置可能先需要准备，来源的评分阈值、GAN 工具和提交策略不是每个项目必需。