vibe 项目的数据飞轮：把用户交互变成越用越强的资产

同样是 vibe coding 做出来的 AI 应用，为什么有的越用越聪明，有的上线半年还是"人工智障"？差距不在模型——2026 年大家调的都是同一批 API；不在 prompt——好 prompt 三天就被抄走。真正的差距在数据：前者把每一次用户交互都变成了下一次改进的燃料，后者让数据躺在日志里睡大觉。

这就是数据飞轮：用户用产品 → 交互沉淀为数据 → 数据被标注成资产 → 资产回流改进产品 → 产品更好用 → 更多用户来用。轮子每转一圈，产品就比上一圈更懂用户，而后来者想追，得从零开始攒第一圈的数据。这才是 vibe 项目为数不多的、不对称的竞争优势——模型是租来的，数据是自己的。

这篇指南的核心判断先摆出来：数据不是资产，标注过、回流进产品的数据才是资产。没经过标注和回流的数据，只是成本：存储成本、合规风险、以及"我有大数据"的幻觉。下面是从采集、标注、版本管理到四条回流路径的完整实战，给一人团队用的。

先划清边界：本文只管用户交互数据如何变成产品改进——采集什么、怎么标注、怎么回流。不管数据看板与业务分析（那是 vibe-project-analytics-guide 的地盘）、不管 AI 输出质量的评估体系（vibe-project-ai-evals-guide 管评估，本文只讲"生产数据如何长成 eval 集"这一节）、不管删除权合规流程（data-subject-request-dsr-guide 的地盘）。

一、飞轮的四个环节：先让轮子转起来

数据飞轮有四个环节，每个环节都有明确的交付物。很多团队的问题不是"不知道飞轮"，而是四个环节里断了两环，轮子根本转不起来。

环节一：用户交互。交付物是真实的使用行为。注意"真实"两个字：你自己点的测试数据、团队内部的试用，不算。飞轮的第一圈最难，因为产品还不好用、用户还很少——但恰恰是这时候的数据最珍贵，因为它们来自真实的需求和真实的失望。

环节二：数据沉淀。交付物是结构化的事件记录：谁、在什么时候、做了什么、输入是什么、AI 输出了什么、用户什么反应。沉淀的关键是"当时就记"——事后从日志里反推用户意图，成本高十倍，质量还差。

环节三：标注资产化。交付物是"能用的数据集"：清洗过、标注过、版本化的数据。这是整个飞轮里最重人工的一环，也是最容易被跳过的一环。跳过它，环节四就是无米之炊。

环节四：回流改进。交付物是产品或模型的真实变化：检索库多了一条知识、prompt 多了一个示例、模型做了一次微调、产品多了一条确定性规则。回流是飞轮的"做功"环节，前三环都是为了这一环。

一人团队的起步策略是最小闭环：只记 3 个关键事件（比如"AI 回答被点赞/点踩""用户重问了改写后的问题""用户放弃了当前任务"），每周花一小时人工看 50 条记录，每月根据看到的东西改一处产品。环虽小，但它是闭环——闭环转起来之后，再考虑扩大。

这里有个反直觉的结论：飞轮的启动质量比规模重要。100 条精心标注的"用户真实失望时刻"，比 10 万条未经标注的点击日志更有价值。因为前者直接指向产品改进，后者只指向存储账单。

二、采集设计：记什么，比怎么记重要十倍

埋点之前，先回答三个问题——能回流吗、能量化吗、敢用吗：

能回流吗：这条数据未来能变成哪种改进？如果答不上来，别记。"用户停留时长"听起来有用，但对 vibe 项目来说，它既不能变成检索知识，也不能变成训练样本——记了也是数字垃圾。相反，"用户对 AI 回答点了踩，并选择了'答非所问'"，可以直接变成 prompt 的反例、eval 集的用例、检索库的补充——这就是能回流的数据。

能量化吗：记录的是事实，还是感觉？"用户不满意"是感觉，"用户在看到回答后 10 秒内关闭了页面且没有复制任何内容"是事实。飞轮吃的是事实，不是感觉。事件 schema 设计时，每个字段都应该是"当时就能确定"的值：时间戳、用户 id（脱敏后）、输入文本、输出文本、用户行为（点赞/点踩/复制/重问/放弃）。

敢用吗：这条数据拿去做标注、做训练，隐私和合规上站得住吗？用户在产品里输入的身份证号、病历、商业机密，采集下来就是负债。采集设计的第一原则是最小必要：只记改进产品所必需的字段，敏感字段在入库前就脱敏或丢弃。隐私不是飞轮的刹车片，是飞轮的轴承——没有它，轮子转不远（详见 data-subject-request-dsr-guide 的合规要求，本文只讲采集侧的产品做法）。

埋点还有"三不"原则：不为飞轮牺牲首版体验（别为了采集数据多弹三个确认框）、不记推导出的结论只记原始事实（"用户不满意"是结论，"点了踩"是事实；结论会过时，事实不会）、不把采集逻辑和业务逻辑搅在一起（埋点代码独立一层，否则半年后没人敢动）。

三、标注管线：飞轮里最重的人工活

原始数据和数据资产之间，隔着"标注"这道墙。标注回答的是：这条交互里，什么是对的、什么是错的、什么是值得学的。一人团队做标注，靠的不是人力堆砌，而是三招：

第一招：模型预标注 + 人做裁判。用强模型先给每条数据打标（"这条回答错在哪""这条用户意图是什么"），人只负责"同意/纠正"。实践中，预标注能把人工成本压到原来的三分之一以下。但有个纪律：预标注的结论不许直接入库，必须经过人点一下头。未经人确认的模型标注，和没标注没有本质区别——你只是在用模型的偏见污染自己的数据集。

第二招：主动学习，专标"最值得"的。时间只够看 50 条，就别随机抽 50 条。优先看三类：模型最不确定的（置信度最低的输出）、用户反应最极端的（点踩、放弃任务）、和已有标注最不一样的（新 pattern）。这三类数据的"信息密度"最高，一条顶十条。这是小团队标注的杠杆。

第三招：标注指南，先写再标。哪怕只有你一个人，也要写半页纸的标注指南："什么算'答非所问'""用户重问时，第一次的回答标错还是标'不完整'"。没有指南的标注，标 100 条有 30 条是凭当天心情——这种数据集回流进产品，是在给产品喂噪声。标注指南是数据集的宪法，改指南要像改宪法一样谨慎，并记录每次修改。

标注的质量铁律：标注质量 > 标注数量，差一个数量级。100 条标准一致的标注，胜过 1000 条各说各话的标注。因为回流路径（第六节）吃的都是"标准一致"的信号，噪声数据只会让模型学到噪声。

四、数据版本与 eval 集：让生产数据长出"考试卷"

数据集和代码一样，需要版本管理。v1.2 的数据集、v1.3 的数据集，差了什么、为什么差，要能说清楚。做法不复杂：每次回流改进前，给数据集打个版本标签，记录"这一版新增了多少条、修正了多少条、依据是什么"。一人团队用 git LFS 或最简单的对象存储 + 版本清单文件就能跑。

版本化的最大价值是可回滚：某次微调后效果变差，能立刻回答"是数据的问题还是模型的问题"——切回上一个数据版本重跑一遍，答案就有了。没有版本的数据集，效果变差时只能靠猜。

生产数据还有一个高价值的去处：长成 eval 集。每次用户点踩、每次任务失败、每次你手动纠正的 bad case，顺手沉淀为一条 eval 用例。一年下来，你会拥有一个"全是真实用户失望时刻"的 eval 集——这是花钱也买不到的评估资产。vibe-project-ai-evals-guide 那篇讲的是评估体系怎么搭，这篇只讲"生产数据如何变成 eval 集的原材料"：标注时多打一个字段"是否入 eval 集"，坏 case 自动归档，eval 集就有了活水源头。

注意 eval 集的卫生：eval 集和训练集必须隔离。进了 eval 集的数据，不许再拿去微调——否则你量的不是能力，是记忆力。一人团队最容易犯这个错，因为数据本来就少，"废物利用"的心态很强。纪律就是纪律。

五、四条回流路径：按成本从低到高走

数据标注好了，怎么"回流"进产品？四条路，成本从低到高。铁律是：先走便宜的路，贵的那条留到数据量证明它值得时再走。

路径一：检索库更新（当天可上线）。把高频的好答案、纠正后的标准答法，沉淀为检索知识。有 RAG 的产品，这条路几乎零成本：一条新知识今天入库，明天用户就能检索到。适用信号：同一类问题被反复问、标准答案稳定。这是飞轮的"快车道"，一人团队应该让 80% 的回流走这条路。

路径二：Prompt 优化（零代码改动）。从失败案例里提炼示例和规则，写进系统 prompt。"用户问 X 时，不要做 Y，要先做 Z"——这种从真实 bad case 里长出来的规则，比拍脑袋写的 prompt 有效得多。适用信号：失败模式集中、可以用自然语言描述。注意 prompt 也有版本管理（vibe-project-prompt-version-control 那篇讲过），回流进 prompt 的每条规则都要注明来源数据。

路径三：产品规则沉淀（不依赖模型）。有些高频模式，根本不需要模型：用户每次都要"先看到结论"，那就写成确定性逻辑——回答生成后，程序自动把结论段提前。这是被严重低估的一条路：能用代码解决的，不要用模型解决。规则是确定性的、可测试的、零 token 成本的。适用信号：模式稳定、与模型能力无关。

路径四：微调 SFT（最贵最后走）。当前三条路都走到头、数据量攒到上千条高质量标注，才考虑微调。微调解决的是"模型的默认行为"问题：比如你的产品需要一种特殊的输出风格，prompt 里描述 500 字都不如微调 1000 条样本。适用信号：风格/格式/领域知识需要内化到模型权重里，且 prompt 工程已触及天花板。微调是飞轮的"重武器"，但重武器的问题是贵、慢、难回滚——不到万不得已不动。

四条路的共同纪律：每次回流都要记录"用了哪版数据、改了什么、效果变化"。这是飞轮的"实验日志"，没有它，飞轮转了也是糊涂账。

六、冷启动：没用户时，数据从哪来

"飞轮很好，但我现在只有 3 个用户，其中两个是我朋友。"这是最真实的问题。冷启动的数据有三个来源，按推荐度排序：

第一，创始人自产。你自己就是第一个重度用户。每天用自己的产品完成真实任务，把每一次"它没做好"记录下来。创始人自产的数据有一个巨大优势：你同时是用户和标注者，意图理解零损耗。很多 vibe 项目的第一批 200 条高质量标注，都是创始人自己"用"出来的。

第二，合成数据。用强模型批量生成"用户可能怎么问、标准答案是什么"。合成数据的价值是"把路铺宽"——覆盖你暂时没见过的问法和场景。但天花板也很清楚：合成数据只能放大已知，不能发现未知。真实用户的问法永远比你想象的野，合成数据永远带着生成模型的偏见。所以合成数据只能做"补充"，不能做"地基"——地基必须是真实交互。

第三，公开数据。领域相关的公开数据集、论坛问答、文档。价值是冷启动期的"知识底座"，但要注意两件事：版权与许可（ai-code-license-risks-guide 讲过数据合规的坑），以及公开数据和你的用户分布可能完全不同——拿通用数据训出来的"聪明"，不等于对你的用户"贴心"。

冷启动期的诚实原则：对数据的来源做标注。合成的就是合成的，自产的就是自产的。等真实用户数据多了，逐步替换掉合成数据的权重。一个不敢标注数据来源的飞轮，早晚会被自己的数据反噬。

七、反模式：飞轮是怎么转死的

1. 集而不标——埋点埋得很全，数据躺在仓库里长毛。数据不标注就是成本，不是资产。2. 标而不回——标了 2000 条，躺在标注平台里，没进过一次产品。标注的终点是回流，不是"标注完成率 100%"。3. 为飞轮牺牲首版体验——为了采集数据，给用户多加三道确认、多弹两个问卷。飞轮的第一环是"用户交互"，把用户赶跑了，轮子直接散架。4. 把用户隐私当燃料——采集了不该记的敏感数据，还拿去训练。一次隐私事故，飞轮连人带轮一起报废。5. 唯数据论——"数据量上去了，产品自然会好"。数据是必要条件，不是充分条件；没有标注质量、没有回流纪律，数据量只是虚荣指标。

八、收尾：一页纸的飞轮检查清单

最后，把整篇指南压缩成一人团队每周对照的一页纸：

□ 本周记了哪 3 个关键事件？（新增事件先过"三问"）
□ 本周人工看了 50 条记录吗？（优先看点踩、放弃、低置信）
□ 有没有一条数据变成了产品改进？（检索库/prompt/规则/微调，任选其一）
□ 本次回流记录了"数据版本+改动+效果"吗？
□ 有没有 bad case 沉淀进 eval 集？
□ 采集的字段里，有没有超出"最小必要"的？（有就删）
□ 合成数据和真实数据的比例，还在健康范围吗？

七个勾，一周一小时。这就是一人团队的数据飞轮——不大，但转得起来。

收尾回到开篇：模型是租来的，数据是自己的。当你的飞轮转起来，每一圈都在加深"你比竞品更懂你的用户"这道护城河。飞轮转起来的那一刻，竞争才真正开始不对称——因为对手可以抄你的 prompt、抄你的界面，但抄不走你三千个真实用户的失望、纠正和"原来如此"。那些，才是你的资产。