Vibe Coding 假设与未知问题账本：防止 AI 把猜测写成事实

“用户应该愿意连接邮箱”“这个 API 大概支持批量请求”“先用 SQLite，之后迁移不难”。这些句子进入 Vibe Coding 会话后，很容易在下一轮变成确定前提：Agent 会据此生成授权流程、并发队列和数据模型，后来的测试只证明代码符合猜测。真正危险的不是未知很多，而是团队忘了哪些结论从未被证明。

假设与未知问题账本是一份独立于聊天记录的决策工件。它接收可验证的问题陈述里暂缺证据的判断，也约束MVP 垂直切片先验证什么。账本不追求把所有问题答完，而是让高风险未知无法在流畅的生成过程里隐身。

先区分四种陈述

把项目中的关键句分成四类：

• FACT：有可打开、带日期和适用范围的证据，例如供应商官方文档明确某端点的限制；
• ASSUMPTION：目前按真推进，但存在可描述的失败后果，例如“首批用户有可导出的 CSV”；
• UNKNOWN：连候选答案或测量方式都不充分，例如“真实文件中脏数据比例是多少”；
• DECISION：在已知证据和约束下作出的可逆或不可逆选择，例如“首片只接受 UTF-8 CSV”。

事实也有适用期。一次用户访谈、某版 API 文档或本机基准不能无限外推。记录 observedAt、scope、source 和 expiresAt；超期后回到待复核状态。决策必须引用它依赖的事实和假设，不能因为“已经做了”自动升级成事实。

推荐的最小字段如下：

id: A-014
statement: 首批目标用户能从现有工具导出包含时间和正文的 CSV
type: ASSUMPTION
impactIfFalse: 主路径入口不存在，当前导入切片不可用
probability: medium
evidence: []
nextTest: 招募 5 名符合筛选条件的用户，观察其导出最近一周数据
passRule: 至少 4 人无需管理员协助完成，且字段可映射
owner: product-owner
due: 2026-08-05
status: OPEN

样本数和阈值是这次决策的预注册规则，不是统计上的普遍结论。无法合理估概率时写 unknown，不要为了风险公式填一个主观的 70%。W3C PROV 的实体、活动和来源关系适合连接陈述、验证动作与证据；不必实现复杂图数据库，但要能从结论回到原始工件和产生它的过程。

按“错了有多贵”排序

账本最常见的失败是有几十行记录却没有行动。先按失败影响分四类：方向风险会让问题或用户不成立；可行性风险会让核心路径无法实现；生存风险涉及安全、法律、资金或不可逆数据；优化风险只影响局部体验。前三类优先于配色、命名和未来扩展性。

再看验证成本和可逆性。高影响、低成本的假设立即验证；高影响、高成本的假设设计一个能先排除最差情况的探针；低影响且可逆的假设可以明确采用默认值，设复核触发器。比如不知道供应商是否支持所需数据范围，先用最小授权账户调用官方沙箱；不要先完成整套同步 UI。英国政府服务手册对 alpha 阶段的建议同样强调测试最有风险的假设，而不是构建完整服务。

每项只能有一个 nextTest 和一个 owner。验证动作应产生可审阅工件：命令及输出摘要、脱敏样本、访谈记录、官方文档版本或实验结果。问一下 AI 不是证据；AI 可以帮助定位来源和设计实验，但回答必须回到一手资料或可复现运行。

在每次生成前后做差分

开始一个 Agent 任务时，只提供与当前切片相关的账本视图，并明确：哪些事实可依赖；哪些假设允许暂按真实现；哪些未知必须停下来提问；哪些决策已冻结。要求 Agent 在 plan 中列出它新增的前提。若它写“系统将使用用户的时区”，而账本没有时区来源，就新增一项，而不是默许。

生成后对 diff 做 assumption review：是否引入未声明的第三方服务、数据保留期、角色权限、容量、默认语言、失败重试或浏览器支持？测试 fixture 也会暗藏假设，例如所有标题都非空、请求永不重复、用户只有一个组织。数据模型与业务不变量会把已确认规则变成约束；在确认之前，fixture 不能替现实作决定。

状态转换保持简单：OPEN -> TESTING -> SUPPORTED / REFUTED / INCONCLUSIVE / EXPIRED。INCONCLUSIVE 不能被当作支持，REFUTED 必须触发依赖项查询：哪些切片、规格和代码建立在它之上？若 A-014 被推翻，导入路径应暂停并回到目标用户与主路径，而不是继续打磨 CSV 解析器。

定期清理，而不是永久记账

每个切片评审先看仍开放的最高影响项，再看新证据和过期事实。关闭项目时删除没有后续价值的低风险猜测；保留影响决策的链路。账本太大通常说明条目粒度过细，或团队把普通待办也塞了进来。只有“若结论错误会改变问题、范围、架构、合规或验收”的陈述值得登记。

与规格变更日志和重新验收联动时，某个已支持假设被新证据推翻，应创建规格变更而不是覆盖旧行。与Definition of Done 与交付边界联动时，仍开放的高影响项要么在交付前关闭，要么明确成为阻断项或被批准的限制，不能藏在“后续优化”。

Vibe Coding 的核心风险不是 AI 偶尔猜错，而是它能把猜测迅速扩散到许多相互一致的文件中。账本给不确定性稳定身份、证据和截止条件，使团队可以快速实现，同时清楚知道哪些地基仍需验证。保持诚实的 UNKNOWN，往往比一段看似完整的答案更能保护交付速度。