mvp-builder

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

MVP 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

仅创建或提供任务所需内容，最后附上：

所做的假设
未解决的问题
推荐的下一步行动