Vibe Coding：原型快速验证

Vibe Coding 适合处理还不确定的问题。比如后台是否需要订单导出，运营团队可能只是说：“每天对账前想拿到一份订单明细。”这时最重要的不是立刻设计完整导出系统，而是尽快做出一个能被试用的版本。

原型阶段可以很小：订单列表右上角出现“导出”按钮，弹出时间范围选择，点击后下载一份 CSV。运营同事拿着测试数据试一遍，就能发现很多真实问题：默认时间范围是不是合适，字段顺序是否符合对账习惯，导出入口是否容易找到，下载等待时是否需要进度提示。

原型要验证什么

Vibe Coding 的重点是反馈，不是完整性。订单导出原型应该围绕几个关键问题展开：

验证点	观察方式
入口是否自然	运营是否能在订单列表中找到导出动作
筛选是否够用	最近 7 天、支付状态、订单状态是否覆盖常用场景
文件是否可用	CSV 能否被表格软件打开，字段是否能直接对账
等待是否可接受	小批量导出是否有明确反馈，不让用户误以为页面卡住
方向是否值得继续	试用后是否确实减少人工复制和筛选工作

这些问题不需要一开始就建任务队列、权限矩阵和审计系统。原型只要能支撑判断，就完成了它的工作。

快速表达需求

在 Vibe 阶段，任务说明可以短，但不能空。比如：

在后台订单列表做一个导出原型。

用户可以选择最近 7 天、最近 30 天或自定义时间范围，点击导出后下载 CSV。
CSV 字段先包含订单号、支付时间、订单状态、支付金额和收货省份。
页面要有导出中、导出成功、导出失败三个状态。
先使用测试数据，不接真实权限和大批量异步任务。

这段说明把原型边界说清楚了：它要验证导出交互和文件可用性，不承担生产级权限、安全和性能目标。

反馈要落到行为上

原型试用后的反馈应尽量描述具体行为，而不是描述感觉。

模糊反馈	可执行反馈
导出有点奇怪	文件名需要包含时间范围，例如 orders-2026-05-01_2026-05-07.csv
页面不太顺	点击导出后按钮要进入 loading，避免重复点击
字段不够	增加“支付渠道”和“优惠金额”，暂时不导出手机号
失败体验不好	导出失败时保留筛选条件，并显示可重试按钮

反馈越具体，下一轮原型越稳定。两三轮之后，如果主要交互和字段选择都稳定下来，就应该停止在 Vibe 阶段继续堆功能，转入规格化。

原型阶段可以简化的内容

订单导出原型可以暂时不处理多租户权限、不接生产数据库、不做超大文件异步生成、不保存审计日志，也可以只支持 CSV。这样做不是忽视风险，而是明确原型的责任范围。

但有些底线不适合省略。即使是原型，也应该避免在示例数据里放真实手机号、地址、身份证号等敏感信息；导出失败不能静默无反馈；依赖包和启动命令要能被后来的人复现。

进入工程化的信号

当订单导出出现下面任意信号时，就不应继续只靠 Vibe Coding 推进：

• 运营准备在真实后台使用。
• 导出字段包含用户信息、金额、地址或内部备注。
• 单次导出可能超过几千行。
• 需要区分客服、财务、运营等不同角色的导出权限。
• 导出结果会用于对账、报税、客服处理或外部交付。
• 预计后续还会支持 Excel、异步任务、导出历史、失败重试。

这些信号意味着任务已经从“验证想法”变成“交付能力”。下一步需要写清楚规格，也就是进入 提示词工程。

最小验收标准

原型也需要验收，只是验收标准更轻。一个订单导出原型至少应该满足：

• 能从订单列表进入导出流程。
• 能选择时间范围并触发下载。
• 下载文件能被正常打开，字段含义清楚。
• 页面有导出中、成功、失败状态。
• 不使用真实敏感数据。
• 原型限制写在页面说明或任务记录里。

这组标准不会让原型变慢，却能避免“看起来差不多”造成误判。

总结

Vibe Coding 是把想法快速放到真实反馈中。它的价值在于尽早发现方向问题，而不是替代后续工程。

订单导出的原型完成后，真正重要的结论不是“按钮做出来了”，而是“哪些字段、流程和反馈被验证过，哪些风险还没有处理”。这些结论会成为后续规格、上下文和验证闭环的输入。

→ 下一步：提示词工程