第12部分：MVP
MVP阶段与常规功能阶段不同。在这里，你要求智能体实现的不是一个小片段，而是最小可行产品的剩余部分。这有风险。只有在项目规则、规范、测试和审查已经足够成熟时，才值得这样做。
MVP作为你规范的压力测试非常有用：如果智能体在阅读了宪法和功能规范后，构建的结果与你的预期不符，问题不仅仅在于智能体。很可能是规范给予了太多自由度，或者路线图不够清晰。
何时可以尝试MVP
合适的时机：
- 至少有两个功能已经完成完整周期；
mission.md、tech-stack.md、roadmap.md是最新的；- 有测试策略；
- 有变更日志；
- 你准备好审查大量变更；
- 路线图包含明确的MVP边界。
不合适的时机：
- 项目的第一个阶段；
- 没有测试；
- 路线图模糊不清；
- 智能体经常越界；
- 你无法抽出时间进行审查。
给Qwen Code的MVP请求
/clear
阅读 @QWEN.md、@specs/mission.md、@specs/tech-stack.md、@specs/roadmap.md
以及 @specs/ 中所有现有的功能规范。
我们正在考虑MVP分支。
暂时不要实现任何东西。
首先：
1. 找出路线图中MVP所需的最小剩余项目集；
2. 列出它们共同实现的风险；
3. 向我提出三组关于MVP边界、决策和审查的问题。得到回答后：
创建 specs/YYYY-MM-DD-mvp/requirements.md、plan.md 和 validation.md。
计划应该分组，以便我可以要求分部分实现。
暂时不要编写实现代码。MVP边界示例
# 需求 — MVP
## 边界
MVP应该让AgentClinic成为一个完整的小型演示：
- 主页；
- 智能体和疾病；
- 治疗方案；
- 预约请求表单；
- 管理面板摘要；
- 响应式样式；
- 关键路由的测试。
## 边界之外
- 认证。
- 支付。
- 邮件发送。
- 管理编辑界面。
- 外部部署。
## 决策
- 使用SQLite表和初始数据。
- 提交的表单本地保存。
- 所有内容服务器端渲染。
- 使用现有布局和CSS约定。MVP审查
对于MVP，审查应该比小功能更严格：
## 自动检查
- npm run typecheck 成功通过。
- npm test 成功通过。
- 路由测试覆盖 /、/agents、/ailments、/therapies 和 /appointments。
- 数据库测试覆盖迁移和初始数据。
## 手动检查
- 在全新克隆中可以运行 npm install、npm run seed 和 npm run dev。
- 主导航可以到达所有MVP页面。
- 预约表单处理有效和无效输入。
- 在375px移动宽度下布局不损坏。
- 变更日志描述MVP分支。
## 偏差检查
- 没有添加认证。
- 没有添加客户端框架。
- 不需要外部服务。按组实现MVP
即使MVP规范只有一个，实现也不一定一次完成。
只实现 @specs/2026-05-05-mvp/plan.md 中的第1组。
运行必要的检查。
停止并列出修改的文件。然后：
实现第2组。
除非检查要求，否则不要编辑第1组的文件。这样你可以保留方便检查的检查点。
何时停止：时间盒和回滚到最后一个绿色点
MVP分支容易膨胀。智能体实现了第1组，然后第2组，然后"顺便"开始调整第1组以适应第3组——一小时后，仓库状态就不清楚了。
提前确定两件事：时间预算和回滚点。
时间预算。 与自己（或团队）约定会话的时间盒。对于学习性质的MVP，这是2-4小时。当时间盒到期时，不是"再来一组"——而是停止、评估、决策。
回滚点。 在每组任务之前提交，即使是中间提交。提交后运行 npm run typecheck 并确认这个点是绿色的：
git commit -m "MVP group 1: agents page"
npm run typecheck
git tag mvp-green-1如果下一组破坏了所有内容，而在合理时间内你无法理解如何修复——回滚到最后一个绿色状态：
git reset --hard mvp-green-1这不是失败。这是一个信号，表明MVP规范对于特定组来说不够详细——应该用单独的小功能来完善，而不是在MVP分支中硬撑。
需要提前停止的迹象：
- 智能体连续两次回到同一组而无法完成它；
git diff --stat显示计划中任何组都没有的文件变更；- 某次实现后，之前通过的测试不再通过；
- 智能体开始问"我可以顺便……"——这意味着MVP边界对它造成了阻碍，应该修改规范，而不是移动边界。
MVP后询问规范中的空白
最好的问题之一：
根据MVP的实现，告诉我哪些是你自己推断出来的，因为没有明确指定。
列出规范中的空白，并建议更新 mission、tech-stack、roadmap 或MVP规范。
不要修改文件。如果智能体诚实地回答"我自己决定了X"，这是一份礼物。如果决定重要，就把X记录到规范中。
实践
- [ ] 在完成两个小阶段之前不要开始MVP。
- [ ] 请Qwen Code评估准备情况。
- [ ] 创建MVP规范。
- [ ] 确定会话时间盒和回滚点。
- [ ] 分部分实现MVP任务组，标记绿色点。
- [ ] 进行偏差检查。
- [ ] 更新项目规则和变更日志。
检查问题
- 为什么MVP是规范的"压力测试"？
- 大规模智能体实现之前需要满足哪些条件？
- 为什么MVP后需要询问智能体关于隐性推断？