Vibe Coding 项目起点：把模糊想法改写成可验证的问题陈述

“做一个 AI 帮我管理发票的应用”不是问题陈述，而是把技术和一个宽泛名词拼在了一起。把这句话交给编程 Agent，它可以在一小时内生成登录、仪表盘、上传按钮和聊天框；这些代码全部能运行，也仍然可能没有值得解决的问题。Vibe Coding 降低了实现成本，却会放大错误方向的产量，因此第一份工件不应是 Prompt 或线框图，而应是一段允许被现实推翻的问题陈述。

Spec 驱动开发介绍怎样写实现规格；本文处理更早的一步：在尚不确定是否该做时，如何形成可验证的问题。后续的目标用户与主路径会把问题落到具体用户旅程，假设与未知问题账本则保存目前还没有证据的部分。

先写观察，不要急着写功能

从一个真实发生过的时刻开始，依次记录五件事：谁在什么条件下遇到阻碍；他原本要完成什么结果；现在怎样应对；应对带来什么可观察损失；你拥有什么证据。英国政府服务手册强调先理解用户需要，而不是从组织想提供的方案出发。这里的“谁”必须能被观察条件识别，例如“每月向五个以上客户开票、没有专职财务的自由职业设计师”，不能只写“中小企业用户”。

不要把访谈者的愿望直接当事实。“我想要自动催款”是方案偏好；“过去三个月有四张发票逾期，用户每周五人工翻表格确认并逐封发邮件”才是行为证据。证据可以是脱敏账单、日历记录、屏幕观察或支持工单。没有证据时就标为待验证假设，不要用“通常”“大家都”把空白藏起来。

可采用下面的单句结构：

当【可识别用户】处于【触发场景】时，他需要完成【结果】，但当前【替代行为或约束】导致【可观察损失】。我们已从【证据及样本边界】观察到此现象；若【反证条件】出现，则停止或改写问题。

例如：“当每月向五个以上客户开票的自由职业者在付款截止日前核对回款时，他们需要找出该提醒的客户，但当前要跨银行流水、表格和邮箱比对，最近观察的 6 人中有 4 人至少漏过一次提醒。若后续招募的 12 名同类用户都能在十分钟内用现有工具完成且没有遗漏，则不继续做自动催款产品。”样本数字只是这个研究计划的判定门，不代表市场事实。

给每个词配一个验证动作

把句子拆成 actor、trigger、desiredOutcome、currentWorkaround、cost、evidence、disconfirm 七个字段。然后问：一个没有参加讨论的人，能否仅凭字段找到样本、复现任务并判断结果？“效率低”无法判断，应改成“从打开第一份记录到列出所有逾期客户所需时间”和“遗漏条目数”；“体验差”应落到放弃、求助、重复操作或错误恢复等行为。

验证不一定要先写软件。让目标用户带着自己的脱敏资料完成一次现有流程，记录开始条件、步骤、耗时、错误和中断；再让他解释最近一次真实事件，而不是想象未来会不会使用。若数据敏感，可以让用户自己操作、研究者只记事件，不收集原始内容。英国政府服务手册的用户故事指南要求以用户和需要为中心，并用验收条件补充细节；但任何模板都不能替代对具体上下文的取证。

为避免只寻找支持材料，预先写下三类结果：CONFIRMED 表示问题达到继续探索门槛；REFUTED 表示核心观察不成立；INCONCLUSIVE 表示样本、权限或测量不足。第三类不能自动算通过。把样本来源、招募筛选、原始记录位置和判断人一并登记，防止 Agent 在总结时把“2 人提过”润色成“用户普遍需要”。

从问题到第一轮可丢弃实验

问题成立也不等于某个方案成立。为每条核心损失选择最便宜、最可逆的实验：若不确定用户能否准确识别逾期项，先用人工整理的只读清单；若不确定提醒文案是否可接受，先演示三种经过脱敏的样例；若不确定能否取得银行数据，先验证授权和数据字段，而不是先造完整仪表盘。这些实验结果进入账本，不能被漂亮 Demo 覆盖。

只有问题证据达到预设门槛，才进入 MVP 垂直切片。此时把问题陈述原文放进任务上下文，并要求 Agent 先复述：服务谁、触发时刻是什么、成功结果是什么、哪些结论仍未知、什么情况必须停止。复述不一致就先修工件，不让它用代码替你做产品决策。

问题陈述还要有版本和日期。用户群、约束或损失发生变化时，追加新版本和变更理由；旧证据保留，避免只留下最终故事。实现期间若有人提出新功能，先判断它是否服务同一个问题和主路径，不是就进入候选清单。最终怎样判断一次实现完成，由 Definition of Done 与交付边界负责，不能倒过来用“代码已写完”证明问题值得解决。

做一次不带方案的交叉评审

把品牌名、AI、自动化、App 等方案词全部遮掉，只把问题句、证据边界和反证条件交给没有参与构思的人。请对方复述目标用户、最近一次触发、当前损失和下一次验证；若复述仍需要你解释“其实我们想做的是……”，说明陈述依赖脑内方案，应继续改写。再让评审者提出一个竞争解释，例如遗漏提醒也许来自合同争议，而不是缺少工具，并写出区分两种解释所需的观察。这个步骤能防止团队只围绕偏爱的方案搜集支持材料。

评审通过的标准不是“听起来有市场”，而是不同成员能用同一条件招募样本、执行同一观察，并在出现反证时得出相同的停止决定。把评审日期、参与角色和未解决异议附在版本旁；异议不必强行共识，但必须进入下一轮验证，不能由 Agent 在总结中抹平。

一个合格的起点不会承诺产品必然成功。它只让团队清楚知道目前观察到了什么、尚未知道什么、下一步如何以最低成本学习，以及在什么证据面前愿意停止。对 Vibe Coding 来说，这种可否证性比更长的 Prompt 更重要：代码生成得越快，越需要在第一行代码之前为错误方向安装刹车。