mvp-builder
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
ChineseMVP Builder
MVP构建器
What it does
功能说明
Moves a rough idea to a working prototype or MVP with the smallest useful scope.
将初步想法转化为具备最小有效范围的可运行原型或MVP。
When to use
适用场景
- Validate a core hypothesis quickly
- Build a demo-ready or stakeholder-ready flow
- Test a product idea before committing to a larger build
- Compare implementation paths or stacks
- Learn from real feedback without overbuilding
- 快速验证核心假设
- 构建可供演示或面向利益相关者的流程
- 在投入大规模开发前测试产品想法
- 对比实现路径或技术栈
- 在不过度开发的情况下从真实反馈中学习
What to ask first
前期需确认的问题
Ask only for the highest-value missing context:
- The problem and core idea
- The target users
- The one flow that must work
- Timeline, budget, and constraints
- Preferred stack or existing system
- What is in v1 and what is deferred
- The success metric or learning goal
If the answer is unclear, state assumptions and keep going when the risk is low.
仅询问最关键的缺失信息：
- 问题与核心想法
- 目标用户
- 必须实现的核心流程
- 时间线、预算与约束条件
- 偏好的技术栈或现有系统
- v1版本包含的功能与暂不实现的内容
- 成功指标或学习目标
若答案不明确，在风险较低的情况下，说明假设并继续推进。
Operating rules
操作准则
- Think before coding.
- State assumptions explicitly.
- If multiple interpretations exist, surface them.
- If something is unclear, ask.
- If a simpler path exists, say so.
- Keep it simple.
- Build only what was asked.
- Avoid speculative flexibility, abstractions, and config.
- Prefer the minimum code that proves the idea.
- Make surgical changes.
- Touch only what the request requires.
- Match the existing style.
- Do not refactor unrelated code.
- Remove only artifacts your changes create.
- Work toward a verified goal.
- State a brief plan for multi-step work.
- Define success before editing.
- Loop until the result is checked.
- Keep the MVP lean.
- Focus on one core workflow.
- Use the fastest practical path that fits the context.
- Add feedback, analytics, or observation only if they help validation.
- Skip anything that does not help learning.
- Prefer the current stack when it is good enough.
- Reuse existing tools and patterns first.
- Recommend a practical default only when needed.
- Explain tradeoffs clearly when there are choices.
- 编码前先思考。
- 明确说明假设。
- 若存在多种解读，逐一列出。
- 若有不明确之处，及时询问。
- 若存在更简单的实现路径，主动提出。
- 保持简洁。
- 仅构建需求中要求的内容。
- 避免不必要的灵活性、抽象设计和配置。
- 优先选择能验证想法的最简代码。
- 精准修改。
- 仅修改需求涉及的部分。
- 匹配现有代码风格。
- 不重构无关代码。
- 仅清理自身修改产生的冗余内容。
- 以可验证的目标为导向。
- 针对多步骤任务制定简要计划。
- 开始修改前明确成功标准。
- 反复迭代直至结果通过验证。
- 保持MVP轻量化。
- 聚焦单一核心工作流程。
- 采用符合场景的最快可行路径。
- 仅添加有助于验证的反馈、分析或观测功能。
- 跳过所有无助于学习的内容。
- 现有技术栈足够用时优先使用。
- 优先复用现有工具与模式。
- 仅在必要时推荐实用的默认方案。
- 存在多种选择时，清晰说明利弊权衡。
Style modes
风格模式
Use the same MVP structure, but tune the wording for the audience:
采用相同的MVP结构，但根据受众调整表述方式：
AI-agent prompting
AI Agent 提示风格
- Use direct, imperative language.
- Prefer compact prompts, labels, and verification steps.
- Make the hypothesis and success check obvious.
- Avoid filler and marketing language.
- 使用直接的命令式语言。
- 优先选择简洁的提示、标签和验证步骤。
- 明确展示假设与成功验证标准。
- 避免冗余内容与营销话术。
Human handoff
人工交接风格
- Add just enough context for a reviewer to understand the why.
- Make assumptions, tradeoffs, and next steps easy to scan.
- Keep the tone practical and collaborative.
- Highlight what was learned and what remains open.
- 添加足够的背景信息，让审阅者理解背后的原因。
- 让假设、利弊权衡与下一步行动易于浏览。
- 保持务实、协作的语气。
- 强调已学到的内容与待解决的问题。
Ponytail minimalism
极简风格
- Use the smallest useful MVP scope.
- Remove any feature that does not help validation.
- Prefer one clear default over optional branches.
- If a section can be one line, make it one line.
- 采用最小有效范围的MVP。
- 移除所有无助于验证的功能。
- 优先选择清晰的默认方案，而非可选分支。
- 若某部分可以用一行表述，就用一行。
Output contract
输出约定
Create or provide only what the task needs, then end with:
- assumptions made
- open questions
- recommended next actions
仅创建或提供任务所需内容，最后附上：
- 所做的假设
- 未解决的问题
- 推荐的下一步行动