第 12 章让产品值得信任：评估与数据飞轮

上一章结尾，我们停在一个微妙的位置上：你把 AI 接进了真实世界，给了它工具、系统、一双能碰真实数据的手，又用最小权限给它配了一把裁剪刚好的钥匙。但边界只回答了「它不能做什么」，还有一个更根本的问题悬着：它做的那些事，做得对不对？从接进真实世界那一刻起，它犯的每个错都是真的——回错的退款承诺是真的，发错的邮件是真的，改错的客户记录也是真的。那么，我想先问你一个不太客气的问题：它今天错了几次？错在哪类问题上？比上周多了还是少了？

答不上来的话，你不是在运营一个产品。你是在裸奔。

「造物」这一部走到这里是第三章。第 10 章把 Agent 搭了起来，第 11 章把它接进了真实系统，这一章解决下一个绕不过去的问题：怎么让它有据地变好，好到值得别人信任。照例，我先把这一章的核心判断立起来，再花整章去挣得它：「感觉还行」不是质量标准，是没有标准。

先看一个把「有据地变好」做到极致的场景。加州 101 高速，一辆特斯拉开着 FSD 在自动驾驶。前方匝道口被施工挡板切乱了车道线，车迟疑了半秒，司机的手按上方向盘，轻轻一带，接管了。整个动作不到两秒，司机大概转头就忘了。但车没忘。方向盘被人接管的那一瞬间，车载系统记下了完整现场：摄像头的画面、当时的车速、系统本来打算怎么开、人最后怎么开。这段数据被打包传回特斯拉，进入一个专门的队列。那个队列的名字翻译成人话就是：我们搞砸了的瞬间。

到 2023 年，特斯拉靠全球车队攒下超过 3 亿英里的 FSD 真实路测里程。这 3 亿英里里最值钱的部分，不是开得顺的那些，恰恰是每一次「司机看不下去了」的接管、每一个让系统发懵的边缘路况。它们被筛出来、标注好、喂回训练，新版本通过 OTA 一夜之间推给整个车队，然后新一轮里程接着滚。每一次失败都被接住，变成下一个版本的口粮。

这套机制有个名字，叫数据飞轮（Data Flywheel），它是本章后半段的主角。但在轮子转起来之前，得先解决一个更基础的问题：你连自己的产品好不好都说不清，拿什么去变好？

一、「感觉还行」这场病

为什么「感觉还行」四个字如此致命？因为它在传统软件时代是成立的，成立了太多年，成了肌肉记忆。

传统软件是确定性的：同样的输入必然得到同样的输出。你测一遍通过，就等于以后每一遍都通过，「感觉还行」背后有工程逻辑撑腰。但第 8 章讲过，AI 产品是模糊工程，概率性输出是它的天性。同一个问题问十遍，可能九遍答得漂亮，第十遍一本正经地胡说。你自己试了五次都对，只说明这五次都对；对接下来的一万次，它什么都没承诺。

更糟的是，你测的那几次，几乎注定是晴天。这种病值得有个名字，我叫它「晴天偏差」：演示的时候，你下意识会问它擅长的问题，用清楚的措辞，在它状态好的场景里。用户不会。用户会打错字，会把三个问题揉进一句话，会用你从没见过的说法表达，会在问题里夹着情绪和脏话。Demo 是你陪它在小区里遛弯，上线是把它一个人扔进春运的火车站。

我见过太多次同一个剧本。Demo 给老板看，惊艳，鼓掌，拍板上线，团队聚餐。两周后，客服群里开始出现用户发来的截图：AI 言之凿凿地承诺了一个不存在的优惠，或者把两个客户的信息张冠李戴。复盘会上所有人都很委屈：「我们测的时候明明好好的。」没人撒谎，他们测的时候确实好好的。问题出在「测」这个字上——他们做的那叫试用，不叫测试。

让我们把第 9 章那笔账再算一遍：一个直接面对客户的客服场景，5% 的错误率，乘以每月上万次对话，等于每个月几百次真实翻车。「感觉还行」的那个「感觉」，样本可能只有二十次，而且全是晴天样本。

还有一层，平时很少有人提：没有评估，你连「变好了」三个字都说不出口。你改了一版提示词，换了一个模型，新版本到底是好了还是坏了？好了多少？有没有把原来答对的题改错？没有测试集，这些问题的答案全靠嘴硬。团队会议上，「我觉得新版本顺多了」和「我怎么觉得不如上一版」吵成一团，谁也拿不出证据，产品就在这种来回横跳里原地打转。

这种横跳还有个更隐蔽的版本：按下葫芦浮起瓢。上周你嫌退款话术太生硬，在提示词里加了一段「语气要温和」，话术确实软了；这周用户开始投诉「查个订单绕半天弯子不给结果」。你以为是新冒出来的毛病，其实就是上周那一刀切出来的。改概率性系统就像捏一个气球，按这头，鼓那头，而你的手上没有任何仪器告诉你哪头鼓了。

在往下讲之前，先把这件事的分量说足。这本书一路都在劝你快：第 2 章算过三人小队比三百人快一百倍的账，上一章你又给 Agent 接上了真实世界的手脚。但快有一个前提——系统跑得越快，验证机制必须同步加快，否则每一分提速都在放大风险。刹车的意义从来不是让车慢下来，是让你敢把车开快。从这个角度看，评估和第 7 章的封装其实是同一对地基的两半：封装让你的能力可拆可换，评估让你每次改动都有据可依。这两样没立起来，前面学的所有「快」，都是在结冰的路上踩油门。

所以这一章要解决的就是两件事。第一，给你的产品立一把尺，让「好不好」有据可查，这是评估（Eval）。第二，让这把尺连上一条流水线，让产品有据地、持续地变好，这是数据飞轮。尺在前，轮在后——量不准的东西，转不起来。

二、三个维度，六个格子

斯坦福有堂课叫《Beyond LLM》，讲 Agentic 系统怎么落地，里面有一句分量很重的话：Eval 是 Production Agentic 系统的命脉。不是锦上添花，不是上线后再补的卫生工作，是命脉。

这堂课给出了一个三维度的评估框架。听起来抽象，我们拿第 8 章那个「改订单地址」的客服 Agent 当例子，一拆就明白。

第一个维度：整体看，还是拆开看（End-to-End vs Component）。整体评估问的是：用户的问题最后解决了吗？满意吗？这是端到端的成绩单。但光看整体不够——一条任务链上有五步：抽取订单号、查客户记录、查政策、起草回信、发邮件，整体失败时你得知道断在哪一步。所以还要按组件评：抽取那一步的准确率是多少，检索那一步找没找对政策条文。像驾照考试，科目二在场地里一项一项考倒车入库，科目三才上路考整体。两样都得考，缺一不可。

第二个维度：客观的，还是主观的（Objective vs Subjective）。写进数据库的订单 ID 对不对，是客观的，程序一比就知道。但回信的语气有没有同理心、解释得清不清楚，是主观的，没有唯一正确答案。客观的部分用代码自动判；主观的部分怎么规模化，下一节马上讲。

第三个维度：量化的，还是质化的（Quantitative vs Qualitative）。成功率、平均延迟，这是量化数字，适合挂在看板上盯趋势。但「幻觉具体发生在哪类问题上」「语气哪里让人不舒服」，数字给不了答案，得有人一条一条读真实对话。量化告诉你有没有问题，质化告诉你问题长什么样。

这三个维度不是让你三选一，是一张检查清单。一套像样的评估体系，六个格子都得有人管：整体和组件、客观和主观、数字和人眼。

怕你觉得抽象，我们把这张清单套到本章后面要细讲的保险条款问答上，过一遍。端到端：用户的问题答没答上、转人工率多高，这是整体成绩。组件：检索那一步召回的条款对不对、引用的页码准不准，这是单项体检。客观：页码对错，程序自动比。主观：那段大白话解释，普通投保人读不读得懂，得评。量化：每天的回答覆盖率、平均响应时长，挂看板。质化：每周抽一批真实对话，人工读，看 AI 在哪类条款上犯迷糊。你看，六个格子填完，这个产品「好不好」就从一句感觉，变成了一张可以逐项追问的表。

听起来工程量吓人，其实起步小得超乎你想象。往下看。

三、让 AI 当评审

主观评估有个天然矛盾：要人工一条条看才准，但人工看不过来量。一天一千条对话，谁看？

答案是让 AI 当评审（LLM-as-Judge）：用另一个模型，拿着一份明确的评分标准（Rubric），给你产品的输出打分。可以两两比较哪个版本答得更好，也可以按标准逐条打分。机器评审不知疲倦，一千条对话半小时跑完。

但这里有个顺序问题，搞反了整套体系就是空转：Rubric 从哪来？

不是从想象里来。斯坦福那堂课给的实操原则，我认为是整个 Eval 实践里最值钱的一句话：先人工抽出 20 条真实对话，一条条读，把扫出来的具体问题写下来，再把这些问题翻译成 Rubric。

注意，是 20 条，不是两千条。这个数字的妙处在于它小到让你没有借口。你不需要数据团队，不需要标注预算，你需要一个下午和一杯咖啡。读完 20 条真实对话，你对产品毛病的了解，会超过看一个月的数据看板。「回答太长」「用户问 A 它答 B」「引用的条款页码是错的」「道歉道得太油腻」——这些具体的毛病，就是 Rubric 的雏形。把它们一条条写成可判断的标准，交给评审模型，你的判断力就被复印了一万份。

「翻译成 Rubric」具体长什么样？拿刚才那几条毛病示范一下。「回答太长」翻译成：超过一百五十字扣分，除非用户明确要求详细解释。「引用页码错」翻译成：回答中出现的页码、条目号必须与原文一致，不一致直接判零分。「答非所问」翻译成：回答的第一句必须直接回应用户的最后一个问题。你发现规律了吗？好的 Rubric 条目都有一个共同点：一个不懂业务的人拿着它，也能做出和你一样的判断。模糊的感受被翻译成了可执行的标准，这一步做完，评审才能交给机器。

Rubric 来自人眼，机器只负责规模化。顺序反过来，先让 AI 凭空生成一套评分标准，你得到的就是一把谁也不知道在量什么的尺子。还有一个容易忘的角落：评审模型自己也会看走眼。所以定期从它判过的结果里抽一小撮，人工复核，看它的判分跟你的判断对不对得上。评审本身，也要被评。

有了尺子，改进就可以做 A/B 测试了。这里还有第二条铁律：模型和提示词，一次只能动一个变量。又换模型又改提示词，效果变好了，你不知道该谢谁；变差了，不知道该怪谁。这条纪律听着像废话，但我见过的团队十个里有八个犯过，理由出奇一致：反正都要改，一起改省事。我们自己也交过这份学费：有一次版本更新，模型和提示词一起换了，指标涨了一截，大家很高兴；两周后想把这次涨幅复现到另一个场景，拆不出功劳该记在哪一半头上，只好把两个变量重新分开、各跑一轮回归，等于把省掉的活加倍补了回来。省下的那点事，会在你想复现结果的那天，连本带利讨回去。

如果这套「测试集加回归」的逻辑听着耳熟，没错：第 5 章你给自己的 Prompt 建过 10 条测试集，改完重跑，防止改好了这处、改坏了那处。那是单兵版。现在只是把同一个逻辑升级成产品版：把你的专业判断标准外化成机器可以反复执行的测试。从 10 条到 20 条再到几百条，本质没变过。

小雯也给她的竞品 Agent 配上了这一套。她从过去一年的简报存档里挑了二十条「考题」：三条曾经混进简报的旧闻，两条来自那家改版过的博客，一条付费墙后的半截新闻，其余是各种正常动态——每条都配好判定标准：该剔除的有没有剔除，该标「未能核实」的有没有标。每次改完岗位说明书，先跑一遍这二十条，全绿才许它重新上岗。更妙的是测试集的长法：还记得她每个周一早上要改掉的那个判断吗？每改一次，那条对话就进考题——她的纠正没有一次白费，全变成了下周的关卡。一个人的产品，也可以有一条不断变长的及格线。

四、兜底四件套

评估能告诉你错误率是 3% 还是 8%，但它永远不会告诉你错误率是零，因为不会是零。概率性系统的错误压得再低，也只是低，不是无。于是真正的问题变成：错误发生的那一刻，用户付出什么代价？你的产品还剩几条命？

这就是兜底设计的领地。第 9 章我们见过那个保险条款问答的案例，当时只判了一件事：它落在大模型的不稳定区，严格事实准确、高合规行业、用户容错极低，却依然是真需求。当时按下没讲的是：凭什么？现在打开引擎盖。

先复习背景。一家中型财险公司，200 万张有效保单，条款平均一个产品 80 页，客服培训要 3 个月，客户因为理解错条款而被拒赔，投诉率一年涨 15%。让 AI 读条款、答客户问，需求是真的，风险也是真的：保险条款答错一个数字，不是体验问题，是赔偿问题。

这个产品敢上线，靠的是四件套兜底。

引用兜底。AI 的每个回答，末尾必须附上原文出处：第几页、第几条。用户能自己翻条款核对。这一件最不起眼，却最关键——它把「AI 错了没人知道」变成「AI 错了用户能发现」。错误从隐蔽变成透明，性质就全变了。

责任兜底。涉及理赔判断的回答，必须带一句「此回答仅供参考，具体理赔以核保人员判断为准」。这不是免责套话，是把法律责任的锚从 AI 挪回人类流程：AI 可以帮客户理解条款，但它说的话不构成承诺。

场景兜底。涉及金额计算的问题，不让 AI 算，直接转人工。注意这个设计的狠劲：不是算错了再补救，是高风险场景根本不让 AI 进门。把 AI 圈在它能稳定发挥的低风险区里，圈外一步都不许迈。

出口兜底。转人工按钮永远在。AI 答得再差，客户随时一键逃生，不会因为 AI 的失败而流失，信任也不会被一次糟糕的对话烧光。

第 8 章讲过工作流层面的兜底四件套，那是埋在流程内部的安全网；这四件长在产品体验上，接的是用户和公司的命。四件合起来，回答了四个问题：用户能不能自己发现错误？责任会不会转嫁到公司头上？损失可不可控？信任会不会被一次失败击穿？四问都答得上，不稳定区就被压成了可控区。

把四件套连起来，放进一个真实瞬间里看它们怎么接力。一位客户问：「我家水管爆了，泡坏了地板，能赔吗？」AI 基于条款回答，文末附上「见家庭财产损失险条款第 23 页第 4.2 条」，这是引用兜底在工作；回答末尾跟着那句「具体理赔以核保人员判断为准」，责任兜底站好了岗；客户追问「那能赔我多少钱」，触发场景兜底，对话直接转给人工核保；全程右上角那个「找客服」按钮一直亮着，这是出口兜底在托底。一次对话，四张网，每一张都在它该在的位置。用户感觉到的只是「这东西挺靠谱」，他不知道这份靠谱是设计出来的。

这套思路远不止保险能用。法律咨询产品，让 AI 给的每条意见都挂上法条原文，那是引用兜底；医疗问答，把涉及用药剂量的问题全部拦下转医生，那是场景兜底；财务工具，AI 起草报表、人签字确认，那是责任兜底。行业换了一个又一个，四个问题从来没变过。下次你评估任何一个「AI 做这事稳不稳」的方案，别急着看模型参数，先看它四问能答上几问。这正是第 9 章那笔账能算平的前提：AI 接走七成简单咨询，一年省下千万级的客服成本，投入一个月左右就回本——账面收益人人会算，敢把不稳的东西放进高合规行业，靠的是这四件套。

最后把兜底和评估接回一根线：兜底不是装上就完事。引用的页码准确率是多少？该转人工的问题有没有被漏放进来？这些兜底机制本身也是组件，也要进 Eval，也要被一条条测。护栏没人检修，和没有护栏是一回事。

五、新的交付物

讲到这里，你可能已经隐约感觉到：评估这件事，正在改写一个老牌职业的核心交付物。

过去 PM 的招牌产出是 PRD，一份描述「产品应该怎么样」的文档。写得再细，它本质上是愿望清单：开发照着做，测试照着验，最后离愿望多远，要等上线才知道。这套流程在确定性软件时代运转了二十年，没毛病。

但概率性系统的行为，文档锁不住。你在 PRD 里写「AI 应回答准确、语气友好」，等于什么都没写——准确到什么程度算准确？哪二十种刁钻问法必须答对？语气友不友好由谁判定？文字描述不了一个概率分布，只有测试集可以。

所以那个判断我完全认同：PM 的核心产出，正在从 PRD 转向「可运行原型 + Eval 测试集」。原型证明它能跑。这一半，前几章讲过的 Prompt MVP 已经把成本打到接近零，一句话就能生成能跑的东西。测试集证明它跑得对，以及更重要的，下次改完之后还对。

注意这个转变里真正值钱的部分。原型谁都能生成了，生成式工具一抓一把；但一套好的 Eval 测试集，藏着的全是专业判断：哪些问题是用户真的会问的？哪些边缘案例是真实世界真的会出现的？什么样的回答算对，什么样的算「看着对其实错了」？这些判断，模型给不了你，得从业务里长出来。

一条合格的测试用例长什么样？三样东西：一个真实输入，最好原封不动来自用户，错别字都别改；一个机器可执行的判定标准，就是前面说的 Rubric；一个标签，标明它是常规题、边缘题还是恶意题。最后这个标签别小看。常规题谁都会放，边缘题和恶意题才见功力：用户会问「帮我编个理由让理赔通过」，会粘贴一段乱码，会用反话试探。测试集里没有这些题，等于考试只考送分题，分数再高也不说明产品扛得住真实世界。你过去写 PRD 的那身功夫没有作废，只是换了存放形式：以前存在文档里给人读，现在存在测试集里给机器跑。给人读的文档会过时、会没人看；给机器跑的测试集，每天都在执行，每次发版都在把关。

这件事不只关 PM。设计师、运营、律师、医生，任何把专业判断交给 AI 执行的人，迟早都要回答同一个问题：你的判断标准，能不能写成机器可以反复检验的形式？能，你的专业就进了系统，成了资产；不能，它就还锁在你脑子里，跟着你一起加班。

顺带一提，这也在变成新的面试题。第 3 章讲过，招聘的尺子正在从履历换成 Token 消耗量这类硬指标。往深一步看，消耗量只证明你用得多，一套你亲手搭过、维护过的 Eval 测试集，证明的是你判断得准。前者说明你勤快，后者说明你专业。两者的市场价，不在一个量级。

六、把失败变成燃料

尺子立起来了，兜底装上了，产品安全上线了。但这只是及格线。开头那个特斯拉的故事，讲的是从及格到拉开差距的部分：数据飞轮。

把特斯拉那套机制拆开，是一个四步循环。第一步，真实使用产生数据：3 亿英里路测，每一英里都是真实世界出的考题。第二步，失败信号被定义和捕获：司机接管、紧急避让、系统犹豫，这些瞬间被自动识别、自动回传。第三步，失败被接回迭代：边缘案例被标注、进入训练，模型重训。第四步，改进推回全体用户：OTA 更新，一夜之间全车队升级，然后循环回第一步。

四步里藏着一个最容易被忽略的设计，我认为它是整个飞轮的轴心：失败信号的定义。

特斯拉聪明的地方，在于它没有给司机发问卷，没有弹窗求用户「请为本次自动驾驶打分」。它选了一个零成本、零打扰、还骗不了人的信号：接管。司机的手按上方向盘，这个动作本身就是一票否决，不需要任何人额外做任何事。失败的标注，是用户顺手完成的。

这个信号还带来一种规模优势：车队越大，罕见路况出现得越频繁。一个雪夜里逆行的三轮车、一面反光得像镜子的卡车货厢，单辆车可能十年遇不上一次，百万辆车每天都在替你收集。边缘案例没法凭空设计，只能从真实世界里捞，而捞的效率取决于你撒下去的网有多大。对手就算今天醒悟，也得用同样的里程一英里一英里追。

你的产品里，等价的信号是什么？用户点了「重试」，是一票。用户把 AI 生成的草稿大改一遍再用，改动的部分就是批注。用户中途放弃、直接点了转人工、回了一句「不是这个意思」——全是失败信号，全是免费的标注。它们每天在你的产品里大量产生，问题只在于：你有没有接住。

顺便说一句反例。很多团队的第一反应是加一个弹窗，请用户给本次回答打个星。省省吧。没人点，点的也是敷衍，而且它打扰了用户，违背了好信号的全部三条标准：零成本、零打扰、骗不了人。最诚实的反馈从来不在问卷里，在行为里。

接住了，循环就转起来：真实使用暴露失败，失败变成测试集里的新题目、迭代里的新依据，产品变准，更多人用，暴露更多失败。第 1 章讲过模型巨头层面的那个大飞轮，这里是同一个原理在你产品里的小号版本。用的人越多，产品越聪明；产品越聪明，越甩开后来者。每个用户动作都在为你攒复利，行业里管这个叫数据网络效应（Data Network Effect）。

这也是 AI 时代少有的真护城河。模型，人人都租得起，你能调用的，对手也能；提示词，迟早被扒走。但你的飞轮攒下的东西：几千条来自真实用户的失败案例、一套被反复打磨的测试集、一条逐月下行的错误率曲线——对手拿不走，也抄不动，因为这些只能用时间和真实用户去换。

七、第三个月的失速

听起来很美，但我必须泼一盆冷水：绝大多数 AI 产品的飞轮，从来没有真正转起来过。

2026 年有篇流传很广的工程复盘，标题就叫「反馈飞轮失速」，里面的观察狠得扎心：多数 AI 产品在上线第三个月后，就停止变好了。

为什么偏偏是第三个月？你对照一下自己的经历就懂。第一个月，团队自己就是最挑剔的用户，人人都在试，badcase 在群里飞，随手就修了。第二个月，反馈渠道正经建起来了，埋点上了，看板有了，曲线还在涨，大家很安心。第三个月，新需求挤进排期，没有人再抽对话来读，反馈表格越积越长，看板沦为周报里的装饰图。用户还在踩坑，坑还在上报，但上报的终点，是一张没人打开的表。

注意，飞轮断掉的几乎从来不是采集那一环——采集是工程活，装一次就一直在跑。断的是「接回迭代」那一环：反馈进了表格，表格没进排期。数据飞轮失速，十次有九次不是技术故障，是组织故障。

怎么防？说说我们自己的土办法。做 Agent 平台那段时间，我们立过一条死规矩：每周固定半天，雷打不动，团队轮流人工抽 20 条真实对话——对，就是前面那个 20 条，它不是一次性的启动动作，是每周的例行体检。按 Rubric 一条条过，扫出来的 badcase 上看板，而且每一条只许有三种去向：当周修掉；修不掉的，加兜底；暂时无解的，写进回归测试集留案底。不允许有第四种去向，尤其不允许「先记着」。

这个例会还有两个不成文的细节。一是轮流制不许豁免，写提示词的人必须亲眼看着自己的话术被用户掰断，那种体感是任何周报都替代不了的。二是开场先念 badcase，原文照念，不许转述，谁负责的模块谁当场认领。听起来像受刑，效果出奇地好：当失败被指名道姓地念出来，它就再也没法躺在表格里装死。

头几个星期，这个会开得很难受，看板上全是让人脸红的东西：答非所问的、引用张冠李戴的、把用户惹毛的。但坚持下来，你会看到一种特别踏实的变化：某一类错误，从每周必现，到偶尔冒头，再到整类从看板上消失；回归测试集从最初的几十条慢慢长到几百条，每一条背后都是用户替我们踩过的坑；新版本上线前跑一遍全量回归，绿灯亮完才许发。产品就是这样一格一格变好的，没有奇迹，全是台账。

你可能会说，那是有团队的玩法，我一个人做的小产品呢？一样转，而且更简单。你自己就是评审会：每周挑一个固定的时间，读 20 条用户对话，三种去向照旧——修掉、加兜底、进测试集。一个人没有组织故障，飞轮失速的唯一原因就是你偷懒。反过来说，超级个体在这件事上有个天然优势：从用户反馈到改完上线，中间一个审批都没有，特斯拉的循环要跑几个月，你的循环一晚上就能转完一圈。

所以别被「飞轮」这个词的气势唬住，它在日常里一点都不浪漫。它就是一个雷打不动的例会，加一条不许断的流水线：失败进来，迭代出去。特斯拉的版本烧的是几十亿美金和百万规模的车队，你的版本可能只是每周四下午的三个小时。转速不同，原理相同；而转着的和停了的，三个月后就是两个物种。

本章要点清单

「感觉还行」不是质量标准，是没有标准。你做的那叫试用，不叫测试；晴天样本对接下来的一万次，什么都没承诺。
刹车的意义不是让车慢下来，是让你敢把车开快。没有评估的提速，是在结冰的路上踩油门。
评估框架三个维度、六个格子：整体和组件、客观和主观、数字和人眼，每个格子都得有人管。
Rubric 来自人眼，机器只负责规模化。先读 20 条真实对话，再写评分标准；评审本身，也要被评。
模型和提示词，一次只能动一个变量。省下的那点事，会在你想复现结果的那天，连本带利讨回去。
兜底四件套：引用、责任、场景、出口。四问都答得上，不稳定区才压得成可控区；护栏没人检修，和没有护栏是一回事。
PM 的核心产出正在从 PRD 转向「可运行原型 + Eval 测试集」。判断标准写得成测试，专业就进了系统、成了资产；写不成，它就锁在你脑子里陪你加班。
好的失败信号零成本、零打扰、骗不了人。最诚实的反馈不在问卷里，在行为里。
飞轮失速十次有九次是组织故障：反馈进了表格，表格没进排期。badcase 只许有三种去向——修掉、加兜底、进测试集。
信任是攒出来的，不是演示出来的。

小结

回到开头那辆在匝道口被接管的车。那次接管本身毫不起眼，两秒钟，一个再普通不过的瞬间。特斯拉的全部秘密，只是没让这两秒白白蒸发：它被记录、被回传、被变成下一个版本的考题。3 亿英里就是这样一秒一秒攒出来的——它不是营销数字，是 3 亿英里的证据。这一章走的就是从「感觉」到「证据」的一条路：先立一把尺，用三个维度六个格子把「好不好」变成可逐项追问的表；再让 AI 当评审，把你的判断力从 20 条对话里提炼出来、复印一万份；给必然存在的错误配上四件套兜底，让失败发生时用户有出口、公司有护栏；然后把尺连上飞轮，让每一次失败都变成测试集里的新题、迭代里的新据——同时警惕第三个月，因为飞轮停转的原因几乎从来不是技术，是没人再把反馈接回排期。你的产品想让人信任，走的和特斯拉是同一条路：一套说得出口的评估体系，一组接得住失败的兜底，一个不失速的飞轮，一条肉眼可见、逐周下行的错误率曲线。「感觉还行」与「值得信任」之间，隔着的就是这一整套朴素的系统。

到这里，「造物」这一部的工程问题差不多过了一遍：判断真伪，搭起 Agent，接进真实世界，再用评估和飞轮让它有据地变好。但你可能注意到了，这一路我们回答的始终是同一类问题：它做得对不对。还有最后一关，和对错无关，却常常一票否决：人愿不愿意用它。多少 AI 产品死得冤枉——能力明明在线，却把用户挡在第一句话之外：不知道能对它说什么，看不懂它在干什么，不敢把真正要紧的事交给它。怎么让一个能干的系统，变成一个让人愿意靠近、敢于托付的产品？这是下一章的事。