做出来已经不值钱了：AI 产品的真正分水岭在上线之后
一、为什么"做出来"不再是优势
能做出一个 AI 产品，在今天已经不是稀缺能力。Vibe Coding 把产品制作门槛拉低到一个周末：你能做的东西，大概率有十个人这周也在做。
但门槛消失，稀缺性不会跟着消失，它只会换一个位置。
打开收藏夹，那些"我用 Claude 一天做了个 TodoList 产品""上线第一天涨了 500 用户"的帖子，点进作者主页看下去，大部分人的下一条动态跟那个产品已经没有关系。域名还能打开，界面还是上线那天的样子，GitHub 上的 commit 曲线在上线那一周密密麻麻、之后一片空白。
发布即巅峰，这是 AI 产品最普遍的形态。
不是作者懒，也不是能力不行。他们缺的是：做出来之后，没有人告诉过他们接下来该干什么。
搜"AI 产品经理怎么做"，出来的全是需求分析、Prompt 工程、Agent 架构设计、评测体系、RAG 选型——全是上线之前的事。搜"AI 产品上线之后怎么迭代"，基本搜不到有用的东西。
所有内容都停在上线那一刻，而那一刻恰恰是 AI 产品真正开始的地方。
AI 产品和传统产品的根本区别，不在技术，在时间轴：
- 传统功能上线即定型，产品工作随之收敛；
- AI 功能上线那一刻，产品工作才真正展开。意图漂移要监控，Prompt 要持续迭代，模型升级会带来行为变化。功能的边界不再是固定的，而是每天在用户的真实使用中被重新塑造。
二、为什么 AI 产品必然没有止境
传统软件的行为是你写死的，AI 产品的行为是运行时被概率决定的。
你写了 if-else，它一万次都这么走；你写了 Prompt，它每一次都是在一个分布里采样。而这个分布会移动：用户的问法变了它会动，知识库变了它会动，模型供应商悄悄更新了它也会动。
所以功能的边界不是你设计出来的，是这个分布每天在用户那里被重新画出来的。你没法在上线前把它定死，只能持续地把它往回拉。
三、上线之后的三条线
把上线之后的工作拆成三条线——不是三个阶段，是三条同时在跑的线：
1. Case 线：把用户的真实使用变成你的资产
2. 迭代线：Prompt 和 Agent 框架什么时候改、改哪一层
3. 模型线：模型什么时候换、怎么换
这三条线有先后关系：Case 线是地基，没有它，后面两条全是拍脑袋。
1. Case 线：把用户行为变成资产
怎么收
传统产品收行为埋点：点了哪个按钮、停留多久、转化到哪一步。AI 产品这些还得收，但远远不够——AI 产品的失败不体现在点击流上，体现在用户说了什么、模型答了什么。你必须收原始对话。
第一个坑：绝大多数团队指望用户点踩。不要指望。真实的点踩率低到没有统计意义，用户不满意的第一反应不是点踩，是关掉。
真正有价值的信号全是被动的：
1. 重问：用户换个说法把同一件事又问了一遍。这是最强的失败信号，比点踩强十倍，因为它是无意识的。
2. 改写：用户把问题拆细了、加了限定词重新问，说明第一次的回答太泛。
3. 中途放弃：生成到一半关掉。
4. 复制行为：用户有没有把结果复制走。答案再漂亮，没人复制，就是没用。
> 用户不会告诉你答错了，但他的行为会。
再加一条人工抽检：每周固定抽一批，不看指标，就是人去读对话。这件事没法自动化，也不该自动化。
怎么分类
收上来之后，绝大多数团队卡在这一步：case 攒了几千条，成了一个没人打开的表格。原因是分类方式错了——大部分人按功能模块分，AI 产品的 case 要按失败原因分。
五类失败原因对应完全不同的修法，混在一起你就永远修不完。
其中"新需求信号"这一类最值钱：它不是缺陷，是用户在用他自己的方式告诉你，这个产品应该长什么样。传统产品的需求要靠调研挖，AI 产品的需求每天自己送上门，问题是你有没有接住。
怎么转化
这一步是分水岭，也是绝大多数人没做的一步：每一条有代表性的 case，必须落成一条可回归的测试样本：
1. 输入是什么
2. 期望的行为是什么
3. 判定标准是什么（能自动判的自动判，不能的写清人工判断依据）
做了这一步，case 才从聊天记录变成资产；不做这一步，你攒的是一堆截图。攒到几百条，你就有了一个别人拿不到的东西：你自己场景的私有评测集。后面两条线全靠它。
2. 迭代线：什么时候改，改哪一层
什么时候该改
最常见的死法：看到一个 case 改一次 Prompt。用户抱怨回答太长，加一句让它简洁一点；抱怨没引用来源，加一句必须标注出处；抱怨语气太冷，加一句语气要亲切。加到第 30 条，你的 Prompt 变成一个两千字的祖传文件，没人敢删任何一句，因为不知道哪句在起作用。
判断标准只有一个：这个 case 是孤例，还是一类。
- 孤例：进 case 库，不动 Prompt。
- 成类：同一个失败原因累积到一定数量，才动。
至于多少算一类，看你的量级。重点不是这个数字，是你必须有这个门槛，而不是凭手感。
改哪一层
改 Prompt 和改 Agent 框架，是两个完全不同层级的动作，动手之前先判断这是哪一类问题。
- Prompt 能解的**：表达方式、输出格式、语气风格、边界声明、少量示例。这些是模型知道怎么做，只是没按你要的方式做。
- Prompt 解不了的：需要新的工具、需要把一步拆成多步、需要接检索、需要人工兜底、需要状态记忆。这些是模型压根拿不到做这件事所需的信息或能力。
大部分人的错误，是把结构问题当 Prompt 问题修。于是 Prompt 越写越长，效果越来越不稳，改一处坏三处——你在用语言，去弥补一个能力上的缺口。
一个简单的自查：如果你为了解决一个问题，需要在 Prompt 里写一大段解释去教模型怎么推理，那这大概率是个结构问题。该做的是把那段推理拆成显式的步骤或工具调用，而不是让模型在一次生成里全扛下来。
怎么保证改了 A 不坏 B
每一次改，跑一遍回归集——就是 Case 线攒的那些。这句话听起来像废话，但现实是绝大多数团队没有回归集，改 Prompt 全靠体感，改完随便试两句觉得没问题就上了，一周后用户反馈另一个地方坏了，你完全不知道是哪次改动导致的。
没有回归集，就不要改 Prompt。你不是在迭代，你是在赌。
Prompt 必须进版本控制，每一版记三件事：改了什么、因为哪一类 case、回归结果如何。这个记录看起来是给团队看的，实际上它是你迭代速度的证明——三个月后回头看，你能清楚说出你的产品变好了多少、为什么变好。这个东西在汇报的时候、在融资的时候、在面试的时候，都是硬通货。
3. 模型线：换与不换
第三条线，也是最容易被忽略的一条。
先讲一件很多人不知道的事：你什么都不改，你的产品行为也会变。模型供应商的静默更新是常态——同一个模型名、同一套 Prompt，三个月前和现在的输出可能不一样。
所以回归集不只在你改东西的时候跑，它要定期空跑：什么都不改，就是跑一遍，用来发现那些不是你造成的变化。没有这一步，你会在某一天突然发现用户投诉变多了，然后花两周排查自己的代码，最后发现问题根本不在你这。
什么时候该换模型
不是有新模型就换。换模型的真实成本是全量回归加灰度加可能的回滚，不是改个配置那么简单。三个真正该换的信号：
1. 能力天花板：你已经确认这不是 Prompt 能解的、也不是结构能解的，就是模型做不到。
2. 成本压力：同样的效果新模型便宜一半，或者你可以把一批不需要强能力的调用降级。
3. 被动下线：旧模型要下线了。
换之前测什么
用你的私有回归集跑，不要看榜单。榜单测的是通用能力，你要的是你的场景里的表现——这两件事经常不一致。而且重点不是看新模型总分高不高，是看行为差异在哪：新模型可能整体更强，但恰好在你最关键的那类 case 上更差。这种情况比你想象的常见得多。
> 没有私有评测集，换模型就是拿用户当测试环境。
换之后怎么对账
灰度，不要全量切，先放一小部分流量。对账看什么？不是看模型的准确率，是看用户侧的行为指标：
1. 重问率有没有升
2. 中途放弃率有没有升
3. 人工介入率有没有升
4. 复制率、采纳率有没有降
模型指标可能全线上涨，用户指标却在恶化——以用户指标为准。还有一件必须做的事：留一个回滚开关，并且真的演练过。没演练过的回滚开关等于没有。
四、护城河：截图测试
AI 产品分成两个部分：能被截图的和不能被截图的。
能被截图的，全部能抄走：Prompt 能被套出来，这已经是公开的技巧；Agent 框架能被拆，你的产品用了几个步骤、调了哪些工具，一个懂行的人半天就能还原；模型谁都能调，同一个 API；UI，一天。
所以判断你有没有护城河，有一个很粗暴的办法：把你的产品截一张图，交给一个同行，他能复制走多少？能复制走的越多，你越危险。
大部分 Vibe Coding 出来的产品，这个测试的答案是：全部。
抄不走的，是不能被截图的那部分，只有两样：
第一样：你的 case 库。这是你的用户在你的业务场景里、用他们自己的说法问出来的东西，是场景特异的。别人可以抄走你的 Prompt，抄不走你三个月里攒的那几千条真实对话，也抄不走你从里面分出来的失败原因分布。更关键的是，case 库是时间的函数——他今天开始抄，也要三个月才能攒到你今天的量，而三个月后你在哪？
第二样：你的迭代速度。迭代速度不是勤奋，是机制。一个有三条线的团队和一个没有的团队，差的不是百分之几十，是量级。
没有 case 库的团队：发现问题靠用户投诉，判断问题靠拍脑袋，验证修复靠人工试两句，一个循环走完要一周，而且不知道有没有改对。有三条线的团队：问题是自己浮出来的，归因是有分类的，验证是自动跑的，一个循环可能是一天。
一周和一天，跑一年，差的是 50 倍的迭代次数。而且这个差距是复利——每一次迭代不只修好一个问题，还会往 case 库里加一条样本，让下一次迭代更快。
五、那大厂规则
讲到这里，一定有人要问：大厂人多钱多，模型还是自己的，迭代不是更快？这个问题很好，答案也不是精神胜利。
迭代速度的本质不是资源，是反馈环的长度。
大厂的迭代确实快，但它快在通用能力上：模型更强、工具更全、基础设施更好，这些是横向的。你的迭代快在你的场景里——你的用户会在你的业务里问出一些非常具体、非常怪、只有这个场景才会出现的问题，这些 case 大厂拿不到，因为那不是他们的用户，不是他们的业务。
再加上一件事：小团队的反馈环可以比大厂短一个量级。你从看到 case 到改完上线，可能是当天；大厂同样的动作要过评审、过灰度流程、过多个团队协作。
所以护城河不在于你比大厂强，在于你在你这一小块场景里，比任何人转得都快。这是小团队在 AI 时代唯一真实的优势，而且它只在你真的建了那三条线的时候才成立。
但别想着"反正要持续迭代，先随便上线，剩下的后面再说"——不行。三条线里的数据埋点、回归集的框架、失败原因的分类维度，这些是 0-1 阶段就要埋的，不是上线后再补。上线后再补，你会发现最宝贵的前三个月对话根本没留下来，或者留下来了但字段不全、没法用。你不能用 1-N 的名义，逃避 0-1 的责任。
六、对个人同样适用
上面讲的是产品，但这件事对人也一样。
在简历上写"我做过一个 AI 产品"，已经不是差异化了——人人都做过。Vibe Coding 之后，做出一个 demo 的门槛低到几乎不存在，面试官一天能看到十份这样的简历。
真正能分出高下的，是接下来那个问题：上线之后，你迭代了几版？每一版是因为什么？
这一个问题就能把人筛开。答不上来的，说明他的产品也是发布即巅峰。答得上来的，能说出：第三版是因为发现有一类用户总在重问同一件事，归因之后发现是检索没召回，加了一层查询改写，重问率从多少降到了多少。这两种人在市场上的价格，不是差一点。
为什么会这样？因为 0-1 的方法论已经被教烂了，所有课都在教需求分析、Prompt 工程、Agent 设计。这些是入场券，不是护城河。而 1-N 没人教，因为教的人自己也没走到。
还有一个反直觉的地方：你不需要一个很成功的产品，才能有 1-N 的经验。一个只有 100 个用户的产品，只要你真的追着这 100 个人的使用改了半年，你的经验密度远高于一个做了十个 demo 的人。
用户少不丢人，没有第二个版本才丢人。
写在最后
是门槛，它挡住的是别人，不是你。
别人问你做过什么产品，你答得上来。别人问你那个产品现在怎么样了，你答不答得上来？
你的产品有没有第二个版本，就是你有没有护城河。
*本文仅代表作者个人观点（仅供参考）*
来源：创客OPC原创整理