第 5 章：产品验证与打磨：把 0→1 做成闭环

0→1 阶段最致命的幻觉，是以为“功能做出来了”就等于“产品成立了”。本章不谈“感觉”，只谈“闭环”：如何建立一套可裁决、可回滚、可留档的机制，让你在低流量下也能把产品修到稳定，而不是靠运气盲目精修。[4][6]

你将在本章面对一个冷酷的事实：绝大多数 0→1 产品不是死于功能太少，而是死于闭环太长、太脆、太不可预测。当闭环不稳定时，任何打磨都是在给危房贴壁纸；只有当闭环可预测时，打磨才能产生复利。

你将交付什么

• 一张断点地图 (Breakpoint Map)：标记用户流失点、恢复手段及其对应的日志点 (Evidence)。
• 一套迭代卡片 (Iteration Card)：包含假设、止损线、对比样本与回滚动作。
• 验证门禁脚本 (Validation Gate)：用自动化脚本判定实验是否达到"可发布"标准。

三层思考：验证与打磨的区别

第 1 层：论证链条

0→1 的验证逻辑必须是刚性的：

闭环定义 → 样本获取 → 指标口径 → 迭代卡片 → 小步改动 → 守门观察 → 裁决（保留/回滚）→ 归档

这里最脆弱的环节是样本质量（找了一堆不痛不痒的人）和裁决标准（没有事前定好门槛，事后强行解释）。[4]

第 3 层：落地与验收

不要追求虚荣指标（如 PV/UV），只看三个硬指标： - 复跑率：你是否能在一周内，让 5 个真实用户完整跑通闭环？ - 裁决力：你是否真的执行过一次“因为数据没达标而回滚”的操作？ - 留档率：你的每一次迭代决策，是否有对应的证据（日志/截图）留存？[6]

方法论：0→1 的三步闭环

1. 定义闭环（短而硬）：3 到 5 个动作，从进入到拿走价值。多一步都是风险。
2. 门槛决策（死线）：改动前定好“成功线”和“失败线”；改动后只看数据，不听故事。[6]
3. 补丁式打磨（可逆）：所有打磨都是补丁，必须可回滚。证据先入库，结论后补。

第一步：画出你的“断点地图”

不要写“用户体验流程图”，要写“断点地图”。你的闭环只有 3–5 步，每一步都可能断掉。

通用公式： 进入产品 → 注入上下文（数据/意图）→ 触发核心计算 → 获得结果 → 带走价值（保存/分享/支付）

闭环断点地图模板

步骤	用户动作	系统反馈 (Success)	常见断点 (Fail)	恢复入口 (Recovery)	证据点 (Evidence)
1. 启动	进入应用	引导/示例	不知从何下手	预置模板/Demo	session_start_null
2. 输入	注入数据/意图	格式校验	格式错/权限不足	洗数工具/权限申请	ingest_error_code
3. 计算	等待生成	进度/引用	等待焦虑/不可信	取消/中间态透传	p95_latency, retry_hit
4. 交付	采纳结果	保存/导出	格式不通/无法用	复制/格式转换	acceptance_rate

图 5-2 使用说明

这张图是你的作战地图： - 横轴：闭环的关键步骤。 - 下方标注：每一层的“断点”和“恢复手段”。 - 核心逻辑：只要用户还在断点流失，就不要去优化那些顺畅的环节。先止血，再造血。

首次闭环：不是做个引导页，而是帮用户赢一次

很多产品死在第一天，不是因为难用，而是用户第一次尝试就输了。

AI 产品的首次闭环设计，必须满足三个条件（缺一不可）： 1. 起步无脑：必须提供默认值、模板或示例。用户没有义务在这个阶段动脑子。 2. 过程透明：AI 是黑盒，你的界面不能是。显示进度、解释原因、展示引用。[71][72] 3. 结果可用：哪怕只是个 60 分的结果，也必须是可复制、可保存、可导出的。不能给一句“我无法回答”。

AI 特有门槛： - 纠错入口：用户必须能修正 AI 的错误（改 Prompt、改参数、改上下文）。如果只能重来，就是设计事故。[71] - 可信标识：如果不确定，标出来。不要用“自信的胡说八道”骗用户。

验收标准： - 首次任务完成率：≥ 基线 + 20%。 - 首次结果采纳率：≥ 60%（且无幻觉强答）。

如果只能做一件事：优化“起步”，让用户不用思考就能开始。

第二步：搞定样本（别靠运气冷启动）

不要把“没人用”当成产品问题，这通常是样本工程问题。

你需要 10–20 个活人，他们有真实痛点，且配合度高。找不到这 20 个人，不要写代码，先去扫楼、混群、发邮件。[4]

样本清单模板

ID	角色匹配度	数据就绪度	任务类型	频率	反馈渠道	闭环状态
U01	核心目标	有清洗好的 CSV	数据分析	日频	微信群	✅ 完成
U02	边缘用户	无数据，需 Demo	体验一下	一次性	邮件	❌ 放弃

样本合格标准： - 痛点真实：不是“看起来不错”，而是“我如果不解决这个问题就要加班”。 - 配合度高：愿意在你的指导下跑完流程，哪怕 bug 频出。 - 数据就绪：特别是 AI 产品（RAG/分析类），用户手里必须有能喂给 AI 的数据。

第三步：指标树与门槛（把“好用”量化）

不要看虚荣指标。0→1 阶段只看三层： 1. 北极星指标 (NSM)：用户真正获得价值的次数（如：每周成功生成的周报数）。[6] 2. 关键行为：闭环的必经之路（如：上传成功率、修改率、复制率）。 3. 守门指标 (Guardrails)：底线，破了就回滚（如：成本、延迟、幻觉率）。[6]

0→1 指标树模板

层级	指标名称	计算口径	目标门槛	失败判定
NSM	每周有效闭环数	成功导出/复制的会话数	≥ 50	连续 2 周 < 30
行为	导入/输入成功率	成功 Step 2 / 总尝试	≥ 80%	< 60%
行为	结果采纳率	结果被复制或保存 / 总生成	≥ 60%	< 40%
行为	纠错挽回率	纠错后采纳 / 总纠错	≥ 50%	连续下降
守门	幻觉率	无引用却给出事实性结论	≤ 1%	出现即 P0 级 Bug
守门	人工接管率	点击“转人工”或报错	≤ 10%	连续上升
守门	单次成本	Token 消耗 / 闭环	≤ $0.1	> $0.15
守门	P95 延迟	95% 请求的耗时	≤ 5s	> 8s

迭代卡片：拒绝“口头打磨”

每次改动，必须填卡片。没有卡片，不许改代码。这不是官僚主义，这是为了防止你骗自己。[4]

迭代卡片模板 (Copy This)

# 迭代卡片: ITR-2025-XX-XX

## 1. 假设 (Hypothesis)
- **改动点**：优化 RAG 检索后的重排序逻辑。
- **预期**：将提升“结果采纳率”。
- **理由**：目前 Top 3 结果相关性低，导致用户频繁重试。

## 2. 目标与门槛
- **主指标**：结果采纳率 ≥ 65% (当前 55%)。
- **守门指标**：P95 延迟 ≤ 3s (允许轻微上涨，但不能过线)。
- **失败判定**：采纳率无明显提升，或延迟 > 4s。

## 3. 验证方案
- **样本**：20 个历史失败 Query + 20 个随机 Query。
- **版本**：Prompt V2.1 + Re-ranker V1.0。
- **流量**：先离线跑测，通过后切 10% 流量。

## 4. 回滚策略
- **触发条件**：守门指标报警或 Error Rate > 1%。
- **动作**：一键切换回 Re-ranker V0.9。

## 5. 证据路径
- 对比表：`reports/itr-2025-xx-xx/compare.md`
- 日志：`logs/itr-2025-xx-xx/`

图 5-3 使用说明

• 左（卡片）：事前立据，防止事后画靶。
• 中（对比表）：事中记录，同口径才有说服力。
• 右（裁决）：事后决断，只有三个选项：保留、回滚、继续测。

解决 AI 的不确定性：场景脚本

AI 输出是不稳定的，怎么验证？ 答案：固定变量，多次复跑，统计概率。

不要手工测，写成脚本。

场景脚本模板

场景 ID：SCN-001-DATA-ANALYSIS
任务：用户上传财报并询问净利润趋势
输入：<sample_financial_report.pdf>
Prompt 变量：{question: "2024年Q3净利润同比增长多少？", style: "concise"}
期望输出：
  - 必须包含数字："+15%" 或 "15%"
  - 必须引用原文：Page 12 Table 3
  - 必须无拒答关键词："无法回答", "不知道"
失败判定：
  - 缺少引用
  - 数字错误
  - 响应时间 > 10s

可执行示例：使用 CLI 验证 Prompt

这是一个真实的验证脚本示例，你可以直接拿去改。

# gate_validation.py - 验证闭环哨兵
import sys
from pathlib import Path

def check_iteration_integrity(file_path):
    required_fields = {
        "止损线": "必须定义止损红线。严禁无限期实验。",
        "回滚动作": "必须定义回滚动作。确保系统可退避。",
        "对比表": "必须提供改动前后的数据对比。",
        "守门指标": "必须包含成本或延迟等约束指标。"
    }

    content = Path(file_path).read_text(encoding='utf-8')
    missing = [v for k, v in required_fields.items() if k not in content]

    if missing:
        print("❌ FAILED: 迭代验证不规范。缺失以下关键要素：")
        for m in missing:
            print(f"  - {m}")
        sys.exit(1)

    print(f"✅ PASS: {file_path} 验证通过。准许合并迭代补丁。")

if __name__ == "__main__":
    check_iteration_integrity(sys.argv[1])

关键点： 1. 固定输入：不要每次手敲，存成文件。 2. 自动化执行：用脚本跑，别用聊天框点点点。 3. 结果落盘：存下来，这是你的证据。

一周节拍：从“随性改”到“固定修”

把你的开发节奏锁死在周维度上。[6]

• 周一：选题。看数据，选 1 个 最痛的断点。写迭代卡片。
• 周二/三：开发。只修这个断点。别顺手改 UI，别顺手加功能。控制变量。
• 周四：验证。跑脚本，灰度发布，盯着守门指标。
• 周五：裁决。填好对比表，决定是保留还是回滚。归档证据。

优先级法则： 断点修复 > 收益放大 > 细节精修 先让用户走通（修断点），再让用户爽（放大收益），最后再搞那些花里胡哨的（精修）。

常见陷阱（不要踩）

1. “用户说不错”：那是客套话。看他是不是真的每周都来用。没数据就是没验证。[4]
2. “这周改了 10 个地方”：那你完了。指标变了你根本不知道是哪个改动造成的。每次只改一个变量。[6]
3. “指标涨了但成本爆了”：这就是没有守门指标的后果。任何不计成本的增长都是耍流氓。设置自动止损线。[6]

交付物清单

本章结束时，你应该有： - [ ] 核心闭环断点地图（含恢复入口）。 - [ ] 10-20 个真实样本清单（及他们的测试记录）。 - [ ] 指标树（含 NSM 和 守门指标）。 - [ ] 至少 3 张完整的迭代卡片（含裁决记录）。

下一章

验证通过，闭环跑通了，现在你的界面可能还像个半成品。下一章，我们将讨论如何把这些逻辑封装进一套可维护、可扩展的 UI 系统中，而不是堆砌控件。

前往下一章：06-ui.md。

参考

详见本书统一参考文献列表：references.md。