一次循环只做一个可体验的 v1 能力

更新于 2026-08-09

**0-1 产品的一次迭代循环，范围应是「用户能真正体验到的、最小的完整 v1 能力」——不是一个微小补丁，也不是一段多周路线图；而循环能不能启动，取决于证据门槛和能力地图是否够新。**

一、范围判定：一个 loop = 一个连贯的 v1 能力

太小（补丁）→ 用户感受不到变化
刚好（v1 能力）→ 端到端可体验，允许跨多个文件/模块
太大（路线图）→ 不是一次循环，是无法验证的赌注

关键取舍：允许为「端到端可体验」而跨模块改动，但不允许扩张成「一次做完整个路线图」。 v2/v3 只记录不执行 —— 记录是为了不丢，不执行是为了能验证。

二、能力地图：按用户能力组织，不按代码模块

维护一份当前的能力边界地图（历史日志 ≠ 地图，地图 ≠ 当前证据，三者互不替代）。

维度要求
组织方式用户能力（代码路径只是某条能力下的证据）
每条能力记录状态、新鲜度、上次核查日期、证据、边界、明确的 non-goals、可见缺口
新鲜度取值只有三个：confirmed / stale / unknown
使用规则只有 confirmed 的边界才能作为推荐依据

「按用户能力组织」是这份地图最容易被做错的地方 —— 一旦按模块/页面/实现层来分，它就退化成代码结构图，回答不了「用户现在到底能做什么」。

三、证据门槛：证据不足时不许发明方向

推荐之前必须先看够证据（最近几次循环日志、能力地图、产品契约、相关代码路径、当前 git 状态、涉及 UX 时必须看真实渲染态）。

  • 涉及 UX / 产品流的推荐，必须看真实产品表面（浏览器、真机、截图、日志），不能用 mock 替代；真看不到就明说。
  • 若关键产品表面无法查看 → 把这些能力标为 unknown，并声明本轮证据受限，在决策依赖它们时停下或提问。
  • 证据太薄时，问一个聚焦的产品上下文问题，而不是编一个方向。

门槛通过的标准：主推荐能引用具体观察 + 相关能力条目都有明确新鲜度 + 备选方案都能给出「为什么可以推迟」的理由。

四、每个 loop 都必须命名一个北极星指标

指标要写全：名称、为什么对 0-1 重要、当前基线（及基线来源）、v1 的目标、怎么检查、以及不可回退的护栏（构建健康、无障碍、无可见溢出、无 console 错误、持久化不被破坏、数据契约不变、用户数据不丢）。

没有指标，就没有这一轮循环。 指标选什么见 北极星指标要量价值闭环。

五、批准闸门：产品代码改动前必须明确批准

先给出「产品推荐 + 实施方案」，等明确批准后才动产品代码；只有用户已经批准过那一份具体方案时才可以跳过。 遇到会改变产品行为、有数据丢失风险、暴露密钥或使验证无法完成的阻塞项 —— 停下报告，不要猜。

相关