快速原型
Source: Dev.to
当我进行原型设计时，我的目标很简单：在我爱上它之前先证明这个想法可行。不是完美的代码——只需要足够学习一点东西。
从清晰开始
在打开编辑器之前，我会尝试用简洁的语言回答几个问题：
- 我在解决什么问题？
- 这针对谁？
- 这个应用必须出色完成的唯一任务是什么？
- 我该如何获取用户？
如果我不能用一两句话解释这个产品，我还没有准备好去构建。代码无法弥补思路不清。
我通常会写一个非常简短的 PRD：目标、主要用户流程以及如何判断它是否有效。这本身就能避免大量的浪费。
首先构建骨架
我不会先构建功能。我先构建结构。
这意味着：
- 路由
- 基础布局
- 数据流
- 文件夹结构
- 命名约定
暂时不写业务逻辑或抽象。这为项目提供了骨干。一旦搭建好，其他工作就会更快且更不混乱。
从引导模板开始
我已经很少从空白项目开始了。一个好的入门模板或起始项目已经把枯燥的部分做好了：
- 项目结构
- 认证或基础用户模型（即使未使用）
- linting、格式化、环境配置
- 路由和布局
- 基础配置
这可以在第一天节省数小时，并减少决策疲劳。关键是不要与模板硬碰硬：去掉不需要的，保留有帮助的，然后继续前进。我们关注的是速度，而不是优雅。如果你想快速构建，稍微有点主观的设置比无限制的自由更好。
使用 UI 库。永远。
我不再争论这个问题。按钮、输入框、模态框、表格……我不想去思考它们。一个好的 UI 库可以消除数百个在原型阶段毫无价值的细微决策。
“用户关心的是价值，而不是我的边框圆角是否独特。”
抵制像素完美的冲动
这是我最头疼的地方。我会先调整间距，然后是颜色，再是字体粗细，接着是响应式布局。结果不知不觉两个小时就过去了，却没有任何实质性的改变。
所以我现在强制执行一条规则：
- 这是否阻碍了用户的理解？立即修复。
- 这只是外观上的细节吗？忽略它。
像素完美应在验证之后进行，而不是之前。设计的打磨是对已证实需求的奖励。
不要一次性构建所有内容，为变化做好结构
我不会尝试在第一版中一次性交付所有可能的未来功能。相反，我会把项目结构设计成以后添加功能时不会感到痛苦。
我避免构建：
- plugin systems
- event buses
- heavy domain layers
我的做法是：
- keep boundaries clear between features
- name files and functions based on what they do, not what they might become
- keep functions small and replaceable
- avoid hard‑coded assumptions that lock me into one flow
- isolate parts that may change (auth, payments, integrations)
- leave short comments where future extensions are obvious
我希望能够在不进行重写的情况下，添加新功能、外部服务/提供商，甚至不同的工具。
Choose what you already know
Shiny tech is fun, but familiarity wins when speed matters. When I use tools I already understand:
- 我调试更快
- 我写的 bug 更少
- 我做出更好的决策
You can always rewrite. You can’t get back wasted time.
AI 实际帮助我的地方
AI 不是我的起点；它是我的加速器。一旦结构搭建完毕，AI 就变得非常有用：
- 起草 PRD（产品需求文档）
- 优化流程
- 生成样板代码
- 编写测试
- 发现错误
对我有效的工作流程：
- 使用单一工具来澄清想法和规格。
- 使用代码助手帮助更快实现各部分。
- 使用专注于 bug 的工具进行审查并捕获问题。
我还会保留：
- 规则
- 指南
- 项目上下文
- 文件夹结构文档
这使得 AI 的回复更准确，也不那么混乱。
文档即杠杆
轻量文档可以避免繁重的重构。我通常会保留：
- PRD（产品需求文档）
- 简单的流程图
- 结构文档（文件夹、API、契约）
- 假设列表
及早验证，然后决定
一旦原型端到端工作正常，我就停止构建。我把它放在用户面前，观察他们，并倾听。
只有在验证之后，我才决定：
- 完善 UI
- 重构架构
- 添加功能
- 或者终止这个想法
快速原型并不是关于草率；而是关于对时间保持诚实。构建能教会你真实东西的最小产品。其他的一切都是噪音。