主题：第12部分 MVP
难度级别：中级
预计学习时间：4-6小时（理论：1.5小时，实践：2.5-4.5小时）
先决条件： 完成至少两个小功能阶段（来自课程前面部分）
理解项目文档结构：mission.md、tech-stack.md、roadmap.md
具备使用版本控制系统Git的经验
具备测试和CI检查的基础知识
熟悉代码代理的工作方式（Qwen Code或类似工具）
学习目标： 根据6项标准的检查清单判断项目是否准备好进入MVP阶段
明确界定MVP边界，区分"范围内"与"范围外"，每类至少5项
应用MVP分组实现技术，通过git标签创建"绿色回退点"
使用自动和手动检查进行MVP偏差验证
利用MVP后分析发现规范中的漏洞并更新项目规则
概述：MVP阶段是与代码代理合作开发的关键阶段，此时不再逐步实现单个功能，而是将最小可行产品的剩余部分整体组装完成。与常规功能阶段不同，MVP具有较高的风险：代理同时处理大量规范，这使其成为项目文档成熟度的强力压力测试。学习材料涵盖MVP准备标准、风险管理技术、MVP规范结构化、带检查点的分组实现、时间盒以及用于改进项目规则的后期分析。
核心概念： MVP作为规范的压力测试：如果代理在阅读所有项目文档后构建的内容与预期不符——问题不在代理，而在规范不够详细、过度自由或路线图不清晰。MVP能在这些问题在正式环境中变得关键之前及早发现。
MVP准备标准：至少两个功能完成完整周期；mission.md、tech-stack.md、roadmap.md为最新；存在测试策略；维护变更日志；团队准备好检查大量变更；路线图包含明确的MVP边界。
MVP边界：明确划分为MVP范围内（主页、核心功能、关键路径测试）和范围外（认证、支付、外部服务、管理界面）。边界防止范围蔓延。
分组实现：即使单一的MVP规范也分部分实现——按任务组。每组完成后：停止、检查、提交、标记"绿色点"。下一组不应在必要时编辑前一组的文件。
绿色回退点：Git标签（例如mvp-green-1），在通过类型检查和测试后标记。如果下一组出现问题——硬回退到最后一个绿色点，而不是在"脏"状态下调试。
MVP会话时间盒：固定时间预算（教学MVP为2-4小时）。时间到后——停止、评估、做出有意识决策，而不是"再来一组"。
偏差检查：严格检查是否超出MVP边界：未添加认证、未引入客户端框架、不需要外部服务。防止功能"蠕变蔓延"。
MVP后漏洞分析：向代理提问："有哪些内容是你不得不自己推断的，因为没有明确给出？"诚实的回答是改进规范的礼物，而非惩罚的理由。
练习： 标题：MVP准备审计
问题：您获得了一个名为"EcoTracker"的项目描述——一款追踪环保习惯的应用。该项目有：roadmap.md（上次更新3个月前）、一个已实现功能（用户注册）、仅针对该功能的测试、缺失的journal.md。根据材料中的检查清单评估项目是否准备好进入MVP阶段。如未准备好——制定达到准备状态的行动计划，包含优先级和期限。
解答：1. 检查"至少两个功能完成完整周期"标准——否，仅一个功能。2. 检查roadmap.md时效性——否，3个月前更新。3. 检查测试策略——部分满足，仅一个功能有测试。4. 检查变更日志——否，journal.md缺失。5. 检查大量变更检查准备度——不确定。6. 检查路线图中明确边界——因过时而无法验证。结论：未准备好。计划：(1) 完整周期实现第二个功能（1-2周）；(2) 更新roadmap.md并明确MVP边界（2-3天）；(3) 扩展测试至覆盖所有关键路径的策略（1周）；(4) 创建并填充journal.md（1天）；(5) 重新进行准备度审计。
难度：中级
标题：MVP边界制定
问题：为在线共享办公空间预订服务"DeskShare"制定"需求——MVP"文档。该服务需展示：查看可用工位、按地点筛选、带照片和设施的工位卡片、带日期/时间选择的预订表单、预订确认。范围外保留：支付、日历集成、用户个人中心、评分和评论、移动应用。同时制定3项技术决策和5项偏差检查点。
解答：范围内：带搜索的工位目录；按城市和设施筛选；带图库的工位卡片；预订表单（日期、时间、联系方式）；确认页面；响应式布局；目录和预订路径测试。范围外：支付（无支付预订）；Google/Apple日历集成；个人中心（通过邮箱预订）；评分和评论；原生移动应用；短信通知。技术决策：(1) 使用SQLite存储预订，以邮箱作为标识符；(2) 所有页面服务器端渲染，不使用React/Vue；(3) 通过静态文件加载照片，不使用CDN。偏差检查：未接入Stripe/PayPal；未添加OAuth授权；未引入React/Vue/Angular；未使用Firebase/AWS Lambda；未集成短信网关；未应用客户端路由。
难度：中级
标题：回退至绿色点场景
问题：您分3组实现MVP。第1组（代理和疾病）后，您创建了提交并标记mvp-green-1，类型检查通过。实现第2组（治疗和预约表单）时，代理"顺便"修改了第1组的文件，现在：(a) 第1组测试失败；(b) git diff --stat显示12个文件有变更，其中4个不在计划任何组中；(c) 代理提议"顺便"添加缓存。请逐步描述您的操作，包括git命令和继续/回退决策。
解答：1. 立即停止：不同意"顺便"添加缓存——这是边界模糊的迹象。2. 评估：症状严重——第1组测试失败、计划外文件被修改、代理提议超出边界。3. 时间检查：如已用时间<<50%时间盒且问题可定位——可尝试仅回退第1组变更；否则——完全回退。4. 完全回退：git log --oneline检查提交；git reset --hard mvp-green-1；如代理创建了新文件则执行git clean -fd；验证：npm run typecheck应通过。5. 原因分析：第2组规范不够详细，未禁止修改第1组。6. 行动：创建单独功能"明确MVP组隔离"，完善plan.md明确禁止编辑前组文件。7. 重试：以更新后的规范开始第2组。
难度：高级
标题：MVP后代理访谈
问题：为Qwen Code编写俄语提示词，在MVP完成后发现代理的隐性推断。然后分析假设回答："我自己决定使用localStorage保存表单草稿，因为规范未说明如何处理中断填写。我还为搜索添加了防抖——这对UX似乎显而易见，尽管需求中未提及。"请制定需在哪些文档中进行哪些更新。
解答：提示词："针对MVP实现，告诉我有哪些内容是你不得不自己推断的，因为没有明确给出。列出规范中的漏洞，并建议更新mission.md、tech-stack.md、roadmap.md或MVP规范。不要修改文件。"回答分析：(1) localStorage用于草稿——未经批准的建筑决策；影响数据隐私、隐私模式运行、跨设备同步。(2) 搜索防抖——有技术后果的UX决策（延迟、请求频率）。文档更新：在specs/mission.md中添加原则"所有用户状态保存决策须明确协商"；在specs/tech-stack.md中指定允许的客户端存储机制（或其缺失）；在specs/YYYY-MM-DD-mvp/requirements.md中明确描述中断填写行为（"草稿不保存，表单重置"）；在validation.md中添加偏差检查"不使用localStorage"；在tech-stack.md或roadmap.md中将防抖作为单独UX功能，附带可测量参数（毫秒延迟）。
难度：中级
案例研究： 标题：AgentClinic：从首次MVP失败到可控实现
场景：初创公司开发演示应用AgentClinic——带AI代理的医疗诊所模拟器。在两个成功的小阶段（代理页面、疾病页面）后，团队决定加速，通过一次Qwen Code请求实现剩余功能。
挑战：首次无准备的MVP请求导致：(1) "顺便"添加了边界外的认证；(2) 尽管tech-stack规定服务器端渲染，仍在客户端引入React；(3) 47个文件变更，不清楚各属何功能；(4) 之前通过的测试现在失败；(5) 6小时调试无果——团队迷失方向。
解决方案：团队应用第12部分的方法论：(1) 回退至MVP前最后稳定提交；(2) 创建带明确边界的完整MVP规范；(3) 分为4组：主页+导航、治疗、预约表单、管理面板；(4) 每组时间盒3小时；(5) 每组后打git标签mvp-green-1、mvp-green-2等；(6) 每组后严格偏差检查。
结果：第二次MVP耗时10小时（4组×平均2.5小时）。所有测试通过。认证和客户端框架未侵入代码。变更日志包含清晰历史。后分析发现代理7项隐性决策，已在更新规范中形式化。
经验教训： 首次"快速"无规范MVP耗时6小时并导致回退；第二次，有条理的——10小时获得可用结果。准备上节省时间是幻觉。
"绿色点"git标签救了2次：第3组损坏时回退至mvp-green-2仅用30秒，而非数小时调试。
第2组后的偏差检查捕获代理尝试添加缓存——及早发现防止技术债务积累。
MVP后访谈发现代理"自己决定"使用特定模板引擎——这促使tech-stack.md明确化，预防了后续项目的类似问题。
相关概念： MVP作为规范的压力测试
分组实现
绿色回退点
MVP会话时间盒
偏差检查
MVP后漏洞分析
标题：EduPlatform：当拒绝MVP成为正确决策
场景：教育项目开发在线课程平台。在一个已实现功能（课程目录浏览）后，产品负责人坚持"通过MVP加速"以在一周后向投资者演示。
挑战：准备度分析显示：roadmap.md缺失（只有创始人脑中的"愿景"）；仅目录有测试；无变更日志；代理在前一功能中两次"顺便添加有用功能"超出规范。典型的MVP未准备好迹象。
解决方案：团队拒绝MVP，选择两个额外小阶段：(1) 带完整测试周期的用户注册系统；(2) 带学习进度的视频播放器。并行：将路线图形式化为带明确未来MVP边界的roadmap.md，创建journal.md，实施测试策略（关键路径覆盖率>80%）。
结果：投资者演示在3周后而非1周后进行，但展示了稳定、可预测的产品。MVP阶段最终在启动时无回退，且比计划时间盒少2小时。投资者将"专业的开发方法"作为信任因素。
经验教训： 时间压力是过早MVP的最差理由；未准备好的MVP可能展示混乱而非产品。
两个额外小阶段（2周）节省了潜在1-2周失败MVP后的调试时间。
小阶段过程中形式化文档比试图"为MVP编写一切"更有效——文档在实践中得到验证。
倾向于"有用功能"的代理需要特别严格的MVP边界；早期在规则中固定此行为预防了后续问题。
相关概念： MVP准备标准
MVP会话时间盒
MVP作为规范的压力测试
学习建议： 在纸上或表格中完成MVP准备度检查清单——不要凭记忆。物理勾选每项降低"嗯，差不多准备好了"的诱惑。
严格按照材料模板练习编写Qwen Code提示词，包括/clear和"先分析、再计划、后代码"结构。偏离模板是代理不可预测行为的常见原因。
创建个人"回退地图"——git命令备忘单：git commit -m '...'、npm run typecheck、git tag mvp-green-N、git reset --hard mvp-green-N。压力情况下，现成备忘单比记忆更宝贵。
为视觉理解：绘制MVP组图表，"绿色点"作为交通灯。红色——当前工作，黄色——检查中，绿色——已标记。实时更新状态。
角色扮演练习：请同事或使用"双重检查"——一人扮演提议"顺便改进"的代理，另一人必须坚守并应用偏差检查。
并行维护"MVP日志"：记录情绪状态、"再来一组"的诱惑时刻、实际时间vs时间盒。这是改进自我准备度评估的数据。
每次练习后进行"5个为什么"分析：为什么代理做了X？为什么规范未预防？为什么检查未捕获？依此类推直至根本原因。
额外资源： 课程原始材料——第12部分：完整文本，含提示词示例和MVP文档模板
Git标签文档：https://git-scm.com/book/en/v2/Git-Basics-Tagging ——深入理解附注标签和轻量标签
埃里克·里斯的《精益创业》（MVP章节）：最小可行产品概念的经典基础，适配代理开发语境
Qwen Code文档：关于上下文和文件引用（@文件）的官方建议
项目文档模板（mission、tech-stack、roadmap）：课程前面部分的示例，用于比较文档成熟度
Git交互式训练器：https://learngitbranching.js.org/?locale=ru_RU ——练习回退和标记场景
总结：与代码代理的MVP阶段不是通过规模加速，而是需要项目文档成熟度的可控风险。关键原则：(1) 未完成两个小阶段且文档未更新前不要开始；(2) 将MVP边界形式化为明确包含和明确排除；(3) 分组实现并设置"绿色回退点"；(4) 违规时应用时间盒和硬回退；(5) 检查偏差——什么未添加；(6) MVP后提取代理的隐性决策以改进规范。MVP是对您设计纪律的压力测试，不仅是代理代码。